The Mars Volta
Recently, I've been on a Mars Volta kick listening to all of their albums again (and waiting for the new one. Noctourniquet, showing up on March 27). My first exposure to them was through Amputechture (the one with "The Street Fighter" cover as Pitchfork so eloquently put it) which I bought on a whim. The initial reaction I had was WTF I have no clue what is going on here. But, the more I listened to it more the more I was able to follow the jams and the music and really liked it. I then began to pick up all the older albums, starting with Deloused in the Comatorium, then Frances the Mute, followed by The Bedlam in Goliath, Octahedron, and finally Tremulant. I still need to get the Frances the Mute single, but I just haven't yet.
After listening to them a whole heck of a lot, I've decided the best way to introduce someone to The Mars Volta through their full length albums is Deloused in the Comatorium. Followed by Frances the Mute, The Bedlam in Goliath, Octahedron, and finally Amputecture. Deloused and Frances both provide a more coherent story than the other albums in my opinion. The Bedlam in Goliath is very heavy and Octohedron is the ying to Goliath's yang so they go together in my mind as a full album. Finally, Amputechture is an album where they really go all over their map in their musical experimentation which could really turn some people off if it is the first thing you hear of theirs (at least from what I've heard and seen). As a nice list I'd get their albums in this order:
- Deloused in the Comatorium
- Frances the Mute
- The Bedlam in Goliath
- Octahedron
- Amputechture
If you've never heard of The Mars Volta, hopefully this little primer will give you the power to jump into the wild and fun world of their music without wondering WTF is going on. And if you are already a Mars Volta fan, you'll give me some feedback on what your favorite Mars Volta albums are.
Get Lamp
Get Lamp is a documentary about the text adventure / interactive fiction games such as Adventure, Zork, and the like. It discusses the past, present, and future of the text adventure. As one review mentioned, there is an awful lot of focus on ex-Infocom employees and not too much on the other companies. I'd say it was bad that most of the people interviewed were ex-Infocom, but at the same time, if you've got a limited amount of time and need to get a good feel of the history, go to them. I enjoyed listening to all of the people, however, to me, the best stuff is on the second disk - especially Chris Crawford's discussion on interactivity which I think a lot of game designers should be forced to watch. One thing I wish that was added was information and interviews related to interactive drama. Interactive drama in my opinion is where the merging of the interactive fiction and games are headed and it would have been nice to have some interviews with those in the field (although it is mainly academic right now).
I really loved it and can't wait to actually see the other documentary I bought from the director on BBSes.
1/16/12: Reworded some sentences since it could be read that I hated the film, but also liked it. For the record: I loved it and found it very interesting.
Year End Retrospectives / What good are New Years Resolutions if you don’t follow through…
It's funny that the older you get, the faster the years seem to move. I often wonder if it is the routines that you fall into that cause the days to just fly by or it is that you become cynical and bitter and lose that wonderment that you had as a child? Or, if you're like me, it's that you've got so much on your plate that you never seem to get anything done, yet at the same time, you do get a lot done -- it just never feels like it. And like that, we're at the end of this year and waiting a new year to show up so we can write a list of things we want to do, look at what he didn't accomplish and push it to the next year and try at it again.
It's the year-end retrospective; and it feels like you're at a job. You're always doing these retrospectives, be it every month, every week, every product delivery, whatever. The reason these work retrospectives work is that you're sitting back figuring things out, really analyzing what went wrong, what went right, what you can do to improve. Unfortunately, we don't hold ourselves to the same standards we do at work. We write the new year resolutions, tell ourselves we're going to do it and then a week or two later fall down on the job and not do any of them. We make excuses as to why we couldn't do it. I say, forget that. Hold yourself accountable. Set goals, set high goals. Set goals that seem impossible to achieve -- that is the only way you'll get better. To strive for something, to push yourself to the edge and complete it. I know this sounds like a bunch of self-help schlock (and it probably is) but you've got to do something to push yourself forward.
Now, off from from that little derivation, the one thing that happen with retrospectives is that they occur at regular intervals to make sure you're on target. I think this is the one thing many people don't do with their resolutions -- don't follow through and don't take stock of how far they've gone in completing the resolution. I suggest that what needs to be done is to do retrospectives each month on the resolutions.
Of course, now, what good would I be if I didn't objectively talk about how I did on my resolutions for this year. My main goal was to propose my PhD topic this year. However, I didn't get this goal like I had hoped -- I got much closer, however -- which was nice. So you know I'm going to be putting this high on my list for the coming year (and once achieving it, putting completing my PhD up there as a high priority). The other goals I had, some failed, some I succeeded on and others I still put in the improving range. So come January 1st, I want to list out my new goals and do a once a month check-up on them to prioritize and update my progress on each of the goals I have.
Now that I've talked about how I intend to follow through on my New Year Resolutions, what are some ways you handle your resolutions? Not make them at all? Do more of the same (not a good idea unless you're constantly improving at something).
Swing Your Sword by Mike Leach
Now, I know this book has been out a while; but, I just now got around to reading (and finishing it in a day). First off, I think Mike Leach has brought a lot of good to college football: from an innovative offense to actually making his players graduate and even though I'm a Texas grad, I always loved watching Tech play (and occasionally beat Texas and our stale offense powered by Greg Davis' patented low-powered East-West offense). It's a shame that they fired Leach because I used to know the game with Tech would be a great game.. now, it just stinks (even with Texas being terrible, it still isn't a good game).
The book starts out with Leach talking about his upbringing and he throws in stories here and there and it rambles around; much like I imagine any conversation with Mike Leach would go (which isn't necessarily a bad thing). He then talks about all his college coaching jobs and his various offensive philosophies and how to best run a football program. Then, he also goes into detail about the whole Adam James scandal and you can probably figure out which side of the fence I fall on for that.
I can't remember quite how long the book was other than the fact it took me one night to read it, so I'm going to say about 250 pages. I found it well worth the time spent reading it, and it is an interesting book written by an interesting coach who is probably more interesting than the most interesting man in the world.
Overfactoring: Taking Refactoring to the Extreme
I think refactoring is a great process that every programmer should be aware of and practice it judiciously. The benefits of clean code are numerous and if you can't figure out why you'd want to refactor, then don't bother reading the rest of this post. 
However, like anything else in this world, there is always too much of a good thing. Eat too much candy, you get sick to your stomach, throw up, whatever (you at least don't eat already been chewed candy). Refactor too much and what do you get?
There is a sweet spot between completely sloppy code and code that has been refactored too much that you can't make heads or tails of what is going on. The sweet spot is where the code has been made better; it needs to have the right amount of abstraction and coupling to all the other classes associated with it. Remember, this is subjective and it comes down to experience to know what is too much or too little -- the more you program the more you'll know what that sweet spot is. I'll say the best way to know when to stop is when you're no longer applying it for a purpose and you're just applying refactoring for the sake of refactoring. Or, if you want something more definitive on when to stop refactoring, this page has some pretty good guidelines.
Of course, you can always remember the golden rule of coding: always leave the codebase in a little better shape than when you entered.
Java, what I’d like to see in a future version
Almost all of my coding for work is done in Java; so I stick pretty close to that all the time (although it isn't to say I don't dislike coding some C and C++ every once-in-a-while . However, it does limit the amount of time I have to look at other languages and the large amount of alternative JVM languages such as Scala, Fantom, and a large amount of other ones I can't recall.
The thing about all these alternative languages is they work on solving problems where Java has just fallen down on the job trying to solve. Two things that were shown to me by a co-worker who has been playing with Fantom really were great ideas and seem like they'd be easy to pull into Java. They were fully immutable classes and variables specified by the const keyword (in Fantom) and the ability to specify if a class could be null when used as a method parameter.
At first, I wasn't too sold on them being special since I have no problem writing code that is immutable by the fact that I can write it as such in Java (preventing setters, providing builders, etc) and then nullability issues can just be taken care of by defensive coding on inputs into the system. Of course, I was thinking about this just from my perspective. I don't need these features.. but when you're working on a team -- these features make a lot of sense. Not everyone programs on the same level. There is always some variability on how good people are at things. This is where these features are really nice.
If you don't want someone to modify the class or variables inside of a class, that const keyword takes care of it. It guarantees that the values of the class and the variable cannot be changed. Hence, it gives you guaranteed immutability which is a very nice thing when doing concurrent programming. The second point, on having the compiler catch parameters that can be null or not was initially in C# but brought into Fantom would hopefully stop all these NullPointerExceptions from being thrown (of course, it still can't stop you from sending in something as null -- but at least it'll stop someone from doing it programmatically).
Now, I don't see myself programming in Fantom professionally (but you never know, it could change) but I think all these alternative JVM languages have a lot of good ideas that should be pulled into the Java Language Specification or through JSRs, helping make Java a stronger, more robust language.