I've been traveling quite a lot this year. I always make sure to have enough to keep myself busy while waiting at airports or flying. Last Monday I flew to one of our clients in Eugene, OR, and found interesting what my actions were from living the house until getting to the client.

• Drive from home to the airport (that's a 25-minute drive): turned on my MP3 player and listened to Podcast (.NET Rocks).
• Left the car at the economic parking, and took the shuttle to the airport (about a 15-minute ride, since it had to stop at two terminals before the one I was going to): kept listening to the podcast.
• Went through security and direct to the boarding gate (another 10 minutes): still listening to the podcast.
• Waiting at the boarding gate, boarding, and then waiting for the aircraft's cabin to be closed (about 20 minutes): that was about time for the podcast to finish.
• After the cabin was closed, all electronic devices must be turned off, so I picked up one of the books I'm currently reading, and read it for about 15 minutes until we were airborne. I'm really enjoying that book, by the way; I'll have a full blog about it once I'm finished reading.
• Once airborne, I turned on my laptop, and started working on a building a little "memory game" in VS 2008. I wanted to do this just to practice more TDD, OOD, VS 2008, C# 3.0, and all that fun stuff (plus, whenever I'm done with it, my daughter is going to have a new game to play on the computer).
• After an hour my laptop's battery was totally out, and I still had an hour on the plane. I picked up my PocketPC and started watching a movie (I watched 300 again...).
• Eventually I had to turn off electronic devices when we were preparing for landing, so I put out my PocketPC, and picked up my book again, which I read until we were ready to get off the plane.
• I had a connection in Salt Lake City, so I walked to the right boarding gate, sat there until the time when boarding started. During this time I was listening to another episode of .NET Rocks. I also took the time to plug my laptop to a power outlet and left it there recharging the battery.
• Once onboard, I basically followed the same ritual: listen to Podcast until they say you have to turn electronic devices off, then read a book until we're airborne, then use the computer until the battery runs out, then watch a movie on the PocketPC, then go back to reading book until we're off the plane, and then listen to podcast on the way from the airport to the client's office.

Summing up: I did some programming, learned something from reading and from listening to podcasts, and watched a movie. And on top of that, didn't get too bored while traveling. Not too bad.  :)

I'm typing this blog entry on the plane, flying back. I followed pretty much the same ritual on the way back, except that I watched a different movie (Stealth, a pretty lame movie, if you ask me). And while my laptop's battery lasted, I've caught up on my emails and read some interesting blog posts.

As for the rest of the week, the whole days are pretty much occupied by working with our clients, and that's usually pretty fun, since I'm always facing different challenges, so the days fly by.

On the evenings I usually do some work, but I try to watch a movie or two. You know, I need to tune out a little bit to make sure I'm as productive on the next day. For my next trips, I'll have two new gadgets with me to keep me sane on the evenings:

• Traveler Speedster Guitar: a great guitar that I can take with me when I'm traveling, since it's small enough to carry it on the plane, but still big enough to feel like a regular guitar.

• TASCAM MP-GT1 Portable MP3 Guitar Trainer: very cool. I can plug the guitar and headphone into this thing and play! This will help me a lot keeping my chops up, and with the songwriting as well.

I'm very excited about these two new toys. I hate being away from playing for weeks in a row, but now I'm going to be able to practice even when I'm on the road. I'm even considering taking these toys to the office every day and practice for 30 minutes on my lunch breaks. This will be fun!

If you've been following this blog, you probably know I'm big into using the right tools to be more productive. A few weeks back I got a copy of the following book:

Windows Developer Power Tools: Turbocharge Windows development with more than 170 free and open source tools (Power Tools) by James Avery, Jim Holmes Read more about this title...

This is a great book. It lists a bunch of tools to improve developers' productivity in many fronts. Many of the tools listed on the book I've also blogged about here (and I'll continue doing so, putting my own spin as to why I like the whatever tool). I was happy to see that a bunch of the tools I use are listed in the book.

This is a big book (1308 pages), but it is not the kind of book you read from cover to cover, or in any specific order. One should pick it up, flip through the pages, see what's there, and dig into the topics of interest.

I certainly recommend any developer should look into this book. There's nothing like using the right tool for each kind of job (even though one can put a nail on the wall by using a screwdriver, the best tool for the task is a hammer, right?). Of course, there is a boat load of tools available out there in the wild, and it's hard to decide which one could be useful for us, and this book does a great job at pointing us out to what's worth checking out.

Here are some of the tools listed in the book that I already use:

• Test-Driven.NET
• NUnit
• GhostDoc
• CR_Metrics
• NDepend
• .NET Reflector
• SlickRun
• SysInternal tools (Process Explorer, AutoRuns, ZoomIt, FileMon, ...)
• MSBuild Community Tasks

That's just to name a few. I'll also be going through the book to check out what other tools I should definitely be using.

I've been doing a lot of reading about how to fight code smells and how to write more cohesive code. One of the tools that I use to help me finding out code smells is DevExpress' Metrics window (it comes with RefactorPro, but I know they also provide that plug-in for free).

I always have that window open in VS, and as I work through source code I can "see" the smell whenever I notice the graph bars going into the yellow or red areas.

Inspired by the modern amusement parks, I've been thinking about developing a device to push that experience even further. You know when we go to those movie theaters where they try to make you really get into the movie, and they do so by spraying water on you and things like that?

So, I'm thinking about creating this device that one attaches to the computer, and as the developer "walks" into smelly code, a bad smell pours out of the device, right into the developer's face. Wouldn't that be a nice 3-D experience? Of course we could also have the device sprays some nice fragrance in case the code smells right.  :)

I'm thinking about naming this device as Smell# (pronounced Smell Sharp):

Imagine people getting used to the other developers' bad smell: "Hey, I'm pretty sure Joe has been here... this code smells bad just like him", or "look, this can only be Tina's code; I could smell that perfume from miles away!".

Of course, some people would get really upset about having to feel somebody else's bad smell. However, this should eventually help with pushing everybody into taking care of their smells. Nobody would like to go into a meeting with other developers and hear something like "hey dude, what have you been eating? Nobody can stand you smell... everybody avoids your code just like we're avoiding a plague...".

Ok, that's the idea. I haven't put a patent on it yet, so if you decide to go ahead and build this, please make sure mail me the checks. Thanks.  :)

All joking aside, I remember working on this project years ago where I was maintaining somebody else's code. The guy used to use to name his variables after bad words. Oh boy, you could find some real nasty variable names in there. Imagine the user getting an error message that reads something like "Penis not found" (I'm keep it mild so to not get this post categorized as PG-13 or something...).

I mean, the days when developers would use some cryptic names for variables, methods, properties, classes, etc., are (or should be) long gone. Applications are not a black box anymore, where the end-users wouldn't ever see the underlying code for it. Nowadays, programming is much less of a black art, and most of the time the customer you're building an application for will be looking at your code, so you better write it as professionally as you can. No bad words, no in-house funny remarks, nothing like that is allowed.

I feel like this is a topic I'll be posting more about it, just because I've been feeling really strong about it.