Right vs. Right

Somewhere, deep in the bowels of a florescent-lit cubical farm, a battle wages on. A battle that has been fought since the dawn of computer programming. A battle of..."right vs. right"?

This sums up the approach that Michael Lopp, better known as "Rands" in the blogosphere, takes to software engineering. In his book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, the battle he describes is one of Incrementalists vs. Completionists--those who want to get things done quickly verses those who want to get things done correctly. Both mindsets are equally "right" in Lopp's eyes. It's the balanced combination of the two that makes for a solid software team.

Lopp takes this even-handed, "ying/yang" approach throughout his book, which is mostly made up of posts from his blog, Rands in Repose. As with the incrementalists and completionlists, his characterizations of office personality types are colorful, insightful, and even-handed. In the chapter entitled Meeting Creatures, Lopp takes you on a wild safari, describing the different kinds of people you'll encounter around the conference table at work. These meetings, he describes, are a rich ecosystem made up of unique, but interdependent personalities. You never have any idea what a "Curveball Kurt" is talking about, for example, which is why you need a "Translator Tim" to help out.

In regards to writing style, each one of the short, thirty-four chapters are written in a light, conversational tone that's easy to digest. Being a collection of blog posts, it's easy to pick up and put down without getting involved like you might with a novel.

So, the book is great, but it should be noted that people may find it hard to relate to some of Lopp's stories. Lopp works in the fast-paced, high-energy Silicon Valley, where startups come and go like contestants on American Idol. This can make for some quite stressful times. He talks, for example, about The Monday Freakout which describes the deluge of yelling and screaming that comes pouring out of a project lead after a weekend spent worrying about the project. I think it's safe to say that not everyone works in an atmosphere like this. Many readers may have a job that, while engaging, doesn't keep them stressing over the weekend.

But the bottom line is that no matter where you work, if your job is somehow related to software development, you can learn something from this book. Read on! It's the "right" thing to do.

ThumbThru released

I just recently finished putting together a small utility I had written a while ago for some websites I had designed during college. I spent a few days cleaning it up and turning it into something generic that anyone could download and start using right away. I've called it...**drumroll**

ThumbThru

It's a simple photo gallery utility coded entirely in Javascript and written in such a way so that it takes as little time as possible to get up and running. It's a lot like the galleries you'll find on the In Pictures section of the BBC News website--in fact, you could say that's where I got my "inspiration".

Some things I learned when writing this:

• How to create a Javascript class


• The difference between the GPL and the LGPL (I've licensed it under the LGPL, btw)


• The fact that Ant can create ZIP files (pretty cool!)

All future blog posts perhaps...?

Anyway, feel free to download ThumbThru and give it a try! Or at least check out the live demo!

I understand you

So, I go to check my Gmail account like I do on a regular basis. But when I logged in, I noticed something different.

There was this red bar above my inbox:



It turns out that I did indeed have Firebug (a Firefox extension) enabled! And I wouldn't have known it otherwise. Google probably decided to include this feature after getting complaints from users who didn't realize that it was their own stupid fault their mail was loading slowly. Or maybe Google decided to include it out of the kindness of their hearts. Either way, it's pretty cool to see a huge corporation that certainly doesn't need do something like this, take the time to do it. They could have buried the issue somewhere deep inside a FAQ page and left it at that.

In the short-term, spending time to include something that only benefits a small minority of users a small minority of the time is a waste of money. Some developer might have spent a day designing this feature. Google's stock price certainly won't rise the next day because of it. He should have been working on Adsense or something!

But it's the longer term impact that is affected by small enhancements like this. What this is saying isn't "turn off Firebug". It's saying "I know you want to get to your email quickly and Firebug may interfere with that." Or more simply:

"I understand you."

When another product of equal or better quality comes around, if you've been regularly reminding your users that you understand them, they'll be more likely to stick with you during tough times.

Music from the Amazon

For the longest time, the iTunes music store has pretty much dominated the music download market. Apple's service has a gigantic selection of music to choose from and they make it super easy to find that song you want to hear. But there's one downside to all this: most of the songs are protected by digital rights management or DRM. This puts limits on things like on what devices the songs will play and how many times a song can be copied. A song without these limitations is certainly a better deal for the customer, who can instead copy the song to as many devices as he desires and play the song on all of them.

Amazon, traditionally the book-selling behemoth of the interwebs, fairly recently started providing music for download. While it doesn't have the extensive selection iTunes is known for, all of Amazon's music is DRM free and encoded in the generic MP3 file format, giving you more freedom over how you can use the music you paid for.

Just today, I downloaded my first album off of this service. It was a pretty painless procedure, though there's a few things you should be aware of:

One - If you want to purchase an entire album, you've got to download this special "Amazon MP3 Downloader" software. It's always annoying when you have to install an entire application to do something as simple as downloading a couple of files. But one feature that takes the edge off of this inconvenience is that it automatically puts a copy of your songs in either your iTunes or Media Player (depending on your OS) library, saving you the small, but sometimes tedious, step of organizing your music by hand.

Two - They have no refund policy. Once your credit card is charged, there's no way to get your money back. Makes sense, since the product you're paying for can't get damaged the way it could if sent through the mail.

Three - You can only download your songs once. If your hard drive decides to stop working one day, that's it, they're gone. You can't download them again without paying a second time. While it doesn't take much effort on your part to make a backup, this still seems like a silly policy. Because the music is DRM-free and can be copied ad infinitum, it seems that what you're really paying for is permission to play the music, as opposed to the music itself.

This is what I like to think of Valve's Steam doing. Steam charges for downloadable content just like Amazon and iTunes does, only instead of charging for downloadable music, it charges for downloadable computer games. Since Steam lets you download the games you've paid for as many times as you want, it's charging you for permission to play the game--not necessarily the game itself. I don't see why Amazon couldn't implement a scheme like this as well.

In conclusion, despite the software it forces down your throat and the one time download limitation, I do indeed recommend Amazon's music download service. Its policy of providing DRM-free music for purchase is something that would be nice see amongst the larger music sellers. Always search Amazon for that song you want before looking anywhere else. DRM-free is the way to be!

Upgrading Drupal

In light of the up and coming (at the time) Pennsylvania Democratic primaries, I was asked by my alma mater's student Democrat organization to create a website for their group. I thought this would be a great opportunity to give an open source CMS (content management system) a try. I ended up choosing Drupal and was able to get it up and running with relative ease. To my surprise (and frustration), only a week later, the Drupal developers released a new version, compelling me to upgrade. In this post, I'm going to talk a bit about the Drupal upgrade process and upgrade processes in general.

Upgrading Drupal, or any application for that matter, is often much harder than performing an installation from scratch. Two major hurtles come to mind.

(1) Compatibility. Will all your stuff still work with the new version?

When Microsoft releases a new version of their Office suite, for example, you want to know that *all* your Word documents created by previous versions can still be opened.

Drupal, unfortunately, doesn't make things that convenient. In the cosmic balance between the software pragmatists and the software idealists, the Drupal team, unlike Microsoft, fights for the idealists. Any time they release a new "major" version (that is, 5.x to 6.0, for example), they pretty much guarantee that all existing custom themes or modules will *not* work. This is because they are very much willing to throw away a large part of the codebase if they think there's a better way of doing something.

These compatibility issues, however, are not an issue with "minor" upgrades (such moving from 5.4 to 5.5). This is because minor upgrades usually deal with security fixes and implementation details that your custom modules and themes don't care much about. Luckily, the upgrade I wanted to perform, 6.1 to 6.2, was a minor upgrade, so I knew with a high degree of confidence that all my custom themes and modules would still work (and they do).

(2) Data preservation. Will any of your data be lost in the upgrade process?

Of course, you want this answer to be a resounding "NO WAY!". For example, if you upgrade to a new version of Firefox, you don't want to load up your new version, only to find that all your bookmarks are gone.

In Drupal's case, this means not loosing your custom themes, custom modules, site content, and files your users uploaded. What makes this a bit complicated when upgrading Drupal is that the Drupal team recommends you completely remove all files from your existing Drupal installation and then do a fresh copy of all the files from the new version (as opposed to just overwriting everything). This means that you must be aware of all the ways in which your Drupal installation differs from the "base" or "initial" installation. That is, you must know about your custom themes, custom modules, etc. so you can put them back after you've copied over the new version.

I find it helpful to maintain a list of all of these differences. That way, whenever I have to upgrade, I know exactly what files to put back into the new version to keep my site running smoothly.

Now that you've got an overview of what to expect from your Drupal upgrade, you might want to do some reading on the Drupal website for more of the technical details. Good luck!