The Messy Notebook

My girlfriend is really pleased about something: I’ve become amazingly dilligent at housework during the last few years. The reason is simple:

My mp3 player of choice is the iPod Touch, which I’m very happy with so far. I carry this thing around with me almost everywhere, every day - and the iPod “killer app” for me is podcasts. I listen to approx 2hrs of audio every day (to and from work, during housework, before going to sleep).

The two main benefits of podcasts for me are A) they let you take in knowledge while you’re doing other stuff, and B) the format is a good delivery mechanism for smaller nuggets of information than provided by, say, the written book.

Given my appreciation of the format, I often recommend podcasts to friends and collagues. I am however getting a little tired of compiling and emailing podcast recommendations, so in the future I’ll just reference this blog post instead.  So without further ado, some of my favourite podcasts:

TedTalks is a collection of speeches from the TED conference, which is held every year in California. The conference features a wide range of excellent speakers on varied topics; science, arts, design, politics, culture, business, global issues, technology, you name it. Each speech (or performance) is anywhere from 5 to 30 minutes long, and most of them are quite interesting. Kudos to Johannes for helping me discover this one!

Big Ideas has a similar theme; interesting speeches on varied subjects. The format is somewhat different, however; the featured material consists of more typical lectures, ie. standard length of between 45 and 90 minutes.

In Our Time is a weekly BBC radio program which focuses on “the history of ideas”, as their BBC web page puts it. Every episode highlights some distinct event, idea, period or person in history, which the studio participants then proceed to discuss for around 45 minutes. Melvyn Bragg, the host, creates an atmosphere in which the guests (usually british academics) really enjoy themselves while talking about their fields of expertise.

Entrepeneurial Thought Leaders is a series of lectures from Stanford, dedicated to business, innovation and entrepeneurship. The speakers are usually founders, leaders and venture capitalists from well known american companies/firms. The lectures provide thoughts on starting, growing and running high tech companies. Personally I’ve found this podcast very useful as a way to get my head into the “entrepeneurial headspace” after I started working at a relatively small and young company last year.

Moving along to podcasts on software development, we have DrunkAndRetired. Charles and Cote have discussed, joked, enthused and commiserated about software development for several years now. I like (and usually agree with) their opinions on our industry, and the tone is usually loose and entertaining; the main topic might be programming but expect lots of funny digressions.

Here’s another one based on the “two friends chatting” format. Joel Spolsky (of Joel on Software fame) and Jeff Atwood (of Coding Horror fame) are currently building a developer community site called Stack Overflow. Stack Overflow is also the name of their podcast - they are located on opposite coasts of the United States, so they collaborate over the phone. Every week they record a conversation and publish it as a podcast, with plenty of insight on both business and technology.

Hanselminutes is produced by Scott Hanselmann, a well known online personality in software development. He’s employed by Microsoft, so the specific technologies discussed are usually .Net and Windows based. His discussions with the guest do, however, usually unearth useful tech-agnostic ideas as well.

Software Engineering Radio is somewhat similar to Hanselminutes - ie. a series of interviews, sometimes with well known members of the software development community. The subjects discussed are things like programming languages, development methods, architectural approaches. Be aware that the producers and hosts are german, which means that while everything is spoken in english, at least one side of the interview often sounds somewhat accented. This isn’t a problem for me, but YMMV.

Moving along to video games, 1Up Yours is one of the better podcasts out there. It’s produced weekly by the staff of 1up.com, one of the bigger commercial gaming websites. The discussions cover things like impressions of new games, industry news, and interviews with game developers. I follow this podcast mainly to keep myself updated on cool new games, but I also find I really enjoy their gossip about what is happening in the games industry.

The Gamers With Jobs conference call is another weekly roundtable discussion on games. The hosts are active writers in the video game press, and (much like 1up Yours) they discuss game releases and industry news.

One of the reasons I really dig The Totally Rad Show is that I can identify with the hosts. They’re around my age, and they’ve grown up enjoying the same nerdy bits of pop culture as me and many of my friends. Every week they sit down in front of a green-screen and talk about “everything rad” - cool new movies, video games, tv shows, comics… you name it. The tone is informal but the episodes are released as quite professionally produced video episodes.

Escape Pod is a weekly podcast featuring science fiction short stories. Most of the featured authors are widely published authors, and the narrators are usually very engaging. Highly recommended if you enjoy the science fiction genre.

All of the podcasts above are searchable and available for free in the iTunes music store. Go on, run along and fill up your iPod.

Yay! It’s free untill tomorrow (sunday 20th of july), after that you have to either wait for the DVD or purchase the series in the american iTunes music store.

Finally got my hands on GTA IV last week, yay. I’m about five hours into it so far. My initial impression of the game itself is very positive… and I still have trouble really enjoying it.

Why? Because I know that the chance of me completing the storyline of this game, ie “getting the whole experience”, is slim to none. Translation: I don’t have as much time as I’d like for this hobby any more. Boo hoo.

Part of the problem is that I can be a terrible neat-freak and completionist in some ways. So I really like finishing a good game. And on the flip side, I also hate not being able to finish said game.

This is of course is due to the whole “having a life” and “being a responsible adult” thing… which is a worthwhile tradeoff. But when I actually do find the time to turn on my Xbox, knowing that I probably won’t be able to get through the whole game ends up tainting the experience.

“Ahh, but Thomas, couldn’t you space it out a little? Pace yourself! Just finish the stupid game in X months instead of X days or weeks!” Yeah, that’s what I thought too. Unfortunately I find that I lose interest in most games after a certain point in time, especially after extended breaks. It’s akin to stopping in the middle of a massive novel; the threshold for getting back into it rises as time passes.

Good for me, then, that the entire games industry seems to be changing to suit my lifestyle.

Case study A: Portal. Innovative and thoughtful gameplay, at times brilliantly funny, and above all perfectly sized. 3-4 hours total gameplay (unless you’re a little slow). It was exactly what it needed to be - no more, no less.

Case study B: Call of Duty 4. Great first person shooter with a single player component only 5-6 hours long; basically a solid rollercoaster ride with very little artificial filler or padding along the way. Again, the amount of gameplay there was just right.

I find that I really appreciate these smaller, more contained games - even though they often cost as much as the ones with 5-10 times as much content. And interestingly, these shorter games seem to be examples of an ongoing shift in the games industry.

Producing big budget video games is growing increasingly expensive. It takes serious time and money to design, code and provide art/audio assets for these products. In the old days, you could stick a couple of programmers in a basement and possibly have a blockbuster hit a few months later. Today, you need literally hundreds of employees working for years, since the complexity and media production values of these games are so much higher than they used to be. This forces developers to cut the scope of their games before releasing them.

Meanwhile, the gamer demographic is changing. The average age of the customer is 33 and rising. Publishers and developers essentially have to adapt to a maturing audience which has less free time on their hands. People like me (and a lot of my friends).

So I probably won’t get through GTA IV. Big deal. My age group (kids over the age of thirty) has plenty of other cool stuff to look forward to. Can’t wait for Portal 2.

I should be doing a little functional programming in my spare time, but summer holiday has arrived and I’m entitled to relax. So now for something completely different.

I’m nurturing a growing interest in user interaction design and graphical user interfaces. This is largely due to my current workplace; at Favourite Systems we create a cool new user interface for mobile phones. So, our in-house technology is very visually oriented, and some of my past and present colleagues are quite talented in visual design.

I, however, am not. To put it this way: when I see an awful user interface like, say, your average Linux application GUI, I think: “That looks like something I could’ve created myself.” No, that’s not a complement.

I also like many of Apples products, specifically for their focus on strong product design.

Inspired by all this, I’ve started thinking more actively about visual design and user interaction design over the last year (in addition to design as applied to software engineering, which I have more experience with). So I recently bought Universal Principles of Design - mainly to do some light reading during the summer.

I quite enjoyed this book. Reading it was a pleasantly different experience from the sometimes dry and/or dreary CS textbooks I usually chew my way through.

The physical book itself is aesthetically very appealing. One principle is detailed per two page spread. The left page provides a textual summary, while the right page contains visual examples - sometimes strikingly interesting ones. The book is a case study in the principles it discusses; examples include Consistency (two pages for every principle), Golden Ratio (check out the cover depicted above), Legibility (every page has a nice clean feel), and Signal-To-Noise Ratio (very little of the material felt like “padding”).

The book introduces the reader to exactly one hundred general design principles. They are  discussed with examples drawn from a wide range of applications in architecture, graphical design and software GUIs.

Some principles seem applicable mainly to specific fields (Prospect-Refuge, to pick one, appears specific to architecture). Others are more obviously general across several fields (Redundancy, Prototyping and Flexibility-Usability Tradeoff are examples of principles used in both industrial design and software engineering).

I’m hardly the first to point out the overlap between design and craftsmanship in software engineering and other disciplines such as graphical arts. I do however find this interesting to think about, and this book helps you do exactly that.

Interestingly, though reading this book was prompted by thinking about software and user interface design, I now also find I want to attain at least a sliver of competency in graphical design. I actually really enjoyed drawing as a kid, both on paper and electronically. Unfortunately, I gave that up sometime before Deluxe Paint went out of fashion. I really should pick up that thread again sometime.

Stop me if you’ve heard this sentiment before: “Regex? You mean that archaic text matching stuff that Unix freaks use?”

Regular expressions (often abbreviated as ‘regex’) are surprisingly unpopular in the developer community (at least at the places that I’ve worked). Which is a shame. It’s a powerful tool, and something any professional programmer should have in his toolbox.

You may not need them very often if you just develop CRUD applications in a nice cosy web framework. But some day you may need to crunch some text files, manually export some data, or scrape a web page… and then you’ll have a much easier time of it if you’re able to quickly bang out a regular expression.

I’ve known “just enough to be dangerous” about regular expressions for years, but never got over that initial hump; every time I needed to use them I had to find a cheat sheet on the web and basically rediscover the syntax. This didn’t exactly make for a tool that I eagerly reached for. This also ties into my unfortunate weak knowledge of scripting languages.

So I needed to improve myself in this area. I started by forcing myself to do some nontrivial text crunching in Ruby; a web scraper, some text file processing, stuff like that. Unfortunately, language specific regex documentation usually sucks because it

A) is often very short (see the slim treatment of regular expressions in The Pickaxe)

B) uses lame, simplistic examples

and C), is often incomplete.

Incomplete in the sense that they leave nuances out, and only cover the specific flavor of regex of that specific programming language. If you switch to another language with another subset of regex functionality you have to spend time relearning things and discovering new quirks.

Which is why I went and bought this sucker:

Mastering Regular Expressions is an excruciatingly complete reference on regex. It starts with a basic overview of syntax and “pattern matching thinking”, then goes on to cover the superset of regex syntax across all the major languages and tools. It delves into how regular expressions work under the hood, discusses performance issues, and provides in depth discussion of how some of the major languages support it (Perl, Java, .Net, PHP). All in all, a very complete and well written reference. I highly recommend it.

No, of course I didn’t read the book cover to cover :). But I worked through the core chapters, and the big takeaways for me were:

• Appreciation of possibilities. I now have a lower threshold for using regular expressions since I know the syntax better and see more cases where it can be used to good effect.
• Appreciation of problems. There are plenty of common pitfalls to avoid in the general syntax, as well as gotchas in specific flavors of regex.

And finally: now I can use Regex Buddy with a clear conscience, yay! I have nothing against using GUI wrappers to speed up the work process. But I do strongly feel that one should, to a certain degree, understand and be able to use the underlying tools as well. It’s the difference between using a supporting tool as running shoes rather than a pair of crutches; the former makes you go even faster, the latter just saves you from being a cripple.

So I developed my first little Rails application recently.

Given how “RAD-y” and agile the development process feels in the Rails framework (at least compared to something like Spring MVC + Hibernate), I was expecting the actual deployment of the thing to be a breeze.

I was wrong.

Rails deployment is done using a tool or framework called Capistrano. Capistrano kinda resembles Rake; you define tasks and variables in a deploy script (like a Rakefile), hooking it directly to your SCM system of choice (Subversion in my case). Running the Capistrano deployment tasks then refreshes your Rails server environment with the latest and greatest version of your application, directly from the repository (Capistrano can be used for automating a bunch of other remote tasks too).

Actually making this process work as expected took me a whole evening, several cups of coffee and occasional copious swearing. I don’t recall every roadblock I encountered, but the following two were the big (ie. most time-consuming) gotchas for me:

• Capistrano is a little sensitive to Subversion repository url structure. Putting the root of your Rails app in applicationName\trunk\applicationName\ works. Putting your app root directly in applicationName\trunk\ does not; you get a “bad url” error thrown back at you by Capistrano (perhaps from the underlying ruby SVN wrapper).

• Printing anything to stdout can eff things up for the underlying webserver. I had some debug puts statements in my application. These were no problem when testing on localhost. In the server environment, however, they caused the pages to be served as plain text instead of html. Took me some googling to figure that one out.

What did I learn?

The Rails deployment process feels somewhat fragile and fiddly; so set up and test the deployment routine before seriously starting development on your application. The actual changes (of which the two above were just the most annoying ones) I had to make to my application and configuration were small. They would, however, have been a bigger pain to debug and implement late in a bigger project with some momentum.

Possible final disclaimer: disregarding PEBCAK on my part, some of the problems could be due to the Rails configuration on the shared host I’m using for my domain(s). Site 5 has been very good for me so far but I’ve read some rumblings about their Rails support in the support forums.

I’m a big fan of project automation. So it’s slightly embarrassing to admit that I really don’t have a proper scripting language in my toolbox.

What usually happens is that, depending on the task, I end up with a mixture of .bat files, command line tools, Ant build scripts and manual search-replace operations in Emacs. If I need to script anything that’s complex enough to make those tools inadequate (loops, conditionals, recursion, non-trivial state), I fall back on Java.

Hardly a complete toolbox, I know.

I’ve known this for a while, but recently I decided to actually do something about it. So, time to A) learn Ruby properly and B) brush up on scripting and data crunching in general.

I already had Programming Ruby (aka “The Pickaxe”) by Andy Hunt lying around, so I worked my way through that first to bone up on basic Ruby syntax. I won’t go into detail on this book, it’s already given a lot of praise in other places. Suffice to say, many consider it to be the standard reference book on Ruby.

Then I picked up Everyday Scripting in Ruby. While the target audience is actually testers and other “supporting, non-coder personell”, it works pretty well as a companion piece to the Pickaxe.

The Pickaxe uses a standard object oriented application development for its examples. Everyday Scripting on the other hand employs standard scripting tasks instead; ie. file system manipulation, data crunching, web scraping and the like. The material that teaches Ruby syntax and OOP in general is clearly intended for people without much serious programming experience and does feel overly verbose in some parts - but it worked well as a refresher and “double take” after reading The Pickaxe. Finally, the book goes into some syntax “rubyisms” that The Pickaxe glosses over.

Data Crunching is another book on scripting. This book is more language agnostic (examples are provided in Python and Java). Think of it as a cookbook of common data manipulation tasks. Topics range between plain text, xml, binary data, relation databases and more.

I particularly liked the section on regular expressions - it felt like one of the best introductions I’ve read on the subject. The examples are actually relevant (matching mail adresses, urls, phone numbers) as opposed to the standard silly pattern matching examples of “ab, abab, aab” (ad nauseum) that many other regex introductions opt for instead.

It’s not a thick book, but the material is compact. I also found I quite liked the authors’ dry sense of humor.

All of these books contain a fair amount of useful advice on programming in general. In other words, they feel very much in line with the other books in the “Pragmatic Bookshelf“. The authors regularly branch off into insightful advice on general methodology, techniques and tradeoffs related to the code and examples in the books.

In short, I feel like I’ve put some new tools in my automation toolbox, but I still need to practise them a lot more. I particularly need to work on my regex skills!

I’m nowhere near as good a programmer as I should be.

I’m not terrible - just a bit off from where I should be.

What actually made this hit home was, initially, some of the job interviews I went through last year. I did get offers from all the companies I interviewed at. Maybe this isn’t saying much given how crazy the IT job market has been for the last few years… or am I actually ahead of a bunch of really terrible programmers? Now there’s a scary thought for you!

Anyway, some of the more hardball interview questions did give me a clear sense of some areas I’m weak, rusty or just plain ignorant in. Later on I got an additional wakeup call from this blog post. Go on, go read it right now.

Some consider Steve Yegges idea of a phone screen (or job interview) somewhat harsh. However, you should know this stuff if you consider yourself a professional developer. The article painfully reminded me of all the stuff I’ve either A) forgotten or B) simply never bothered to learn.

So, resolution time. I’m going to pick a few areas that I need to improve in initially, and I’ll try to invest at least a few hours each week (outside of work). My current todo list:

• Learn Ruby properly. I never bothered to master a scripting language, though I’ve dabbled in Ruby and Perl before. And I should take the opportunity to become more proficient with regular expressions while I’m at it.
• Learn a functional programming language, at least enough to feel more familiar and comfortable with that paradigm. I’ve worked with people who are fond of Lisp, and it clearly showed in their Java code. In a good way.
• Brush up on my math skills. I was never a very inspired math student in school, but I’m continuing to find that I really should’ve focused more on that.

Time to polish the rust and sharpen the blade.

I looked forward to Mass Effect for years before its launch last november. Then it finally came out for the Xbox 360… and literally the next day our daughter was born. Fatherhood took scary & wonderful precedence, and the game ended up in my Pile O’Shame.

Recently, I had the apartment to myself for two weeks while my better half and our daughter took an extended holiday up north. Let’s just say I didn’t work much on my tan while they were away. “Time to play through Mass Effect!”

First off: this game is far from flawless.

The user interface ranges from functional to horrible. Inventory management basically amounts to a single flat list of items, without even the most rudimentary sort options. Prepare to scroll through pages and pages of text when you buy, sell and manage items.

Bioware opted for realtime, action-based combat with prominent cover and squad gameplay mechanics. Though competent enough, these action bits feel nowhere near as polished as the Rainbow Sixes or Gears of War.

Finally, side quests aren’t nearly as interesting as the main story missions. You quickly discover that most of the optional quests obviously recycle a limited set of mission objectives, art assets and room layouts.

However. All this is quickly forgotten when you’re a few missions into the main story.

Mass Effect is an astounding roleplaying game. While the narrative of the game may not be Nebula winning material, it still stands heads and shoulders above most narrative-driven video games.

The plot is fairly straight-forward; artificial, mechanical beings turn on their makers and then try taking over the galaxy. Sound familiar? Yeah, not the most original premise.

What makes the game so enjoyable is its mood. If you like classic science fiction movies, you will absolutely love this game. The music sounds like it fell straight out of an old Vangelis soundtrack. The universe of the game is detailed and feels well thought out. Voice acting is top notch throughout the game. The developers even added graphical grain filters to mimic those classic movies (well, most of them are probably digitally remastered and visually crystal clean these days, but you get the idea).

The story, while not very innovative in itself, builds to a very cool climax toward the end of the game; along the way I had plenty of “Wow!” moments. The game often nails that sense of wonder that good science fiction is so capable of evoking.

In short, if you are even the slightest bit interested in video games and science fiction, you should run out and buy this game. Just make sure you have a chunk of free time to play through it - it’ll take a solid 20-40 hours to finish.

I’m changing a few things about this blog.

First; new blogging software. The last setup had no spam protection of any sort, so I ended up with 50+ spam comments under every post within weeks. I ended up just trashing the old blog and installing a new one, powered by Wordpress. Will be interesting to see how effective the Akismet plugin is against spam comments…

Secondly; I’m adjusting the scope of my posts wee bit. Originally I wanted to use this blog exclusively for work and development-related stuff. That didn’t really work, for two reasons. At my last job I ended up writing most of my software development posts on the internal blog of my employer. I’ve also found that my enthusiasm for writing about strictly work-related stuff on my spare time isn’t constant, but rather waning and waxing over time.

So from now on I’ll use the blog to prattle on about things both work-related and otherwise. Hopefully this’ll motivate me to trickle out more regular posts… well, maybe. We’ll see.

Finally; I reposted the few posts that did make it into the old blog.