Simple, Repeatable, Powerful

In software, simple is better.

As developers, we spend much more time trying to understand code than we do writing it. It’s going to be a lot easier for your collegues to understand what you meant by a method nameddoesUserExist() than everybodyWangChungTonight().

Tracking down obscure bugs is insanely frustrating. It’s even more frustrating when you have to struggle to grasp a shred of meaning from the code that is supposedly buggy. Imagine what your college professors must have gone through.

Dr. Brekke: I’m sorry I picked random animal names for variable names on that assignment. It was late and OperationHerdCats() seemed hilarious at the time.

There. That feels better.

Similarly, if you have to jump through an arbitrary number of hoops to perform some action at work, be it kick off an integration build, generate a report, or make a new pot of coffee, it’s going to be hard to talk anyone in to taking over or sharing in those duties.

I’ve been gradually working my way though The Pragmatic Programmer over the last few weeks. Some things are old hat (thanks Dr. Walker), while others are less obvious, but insanely practical. One of the ideas was that everything you do should be easily reproducible with simple steps. This falls right in line with #2 of The Joel Test.

The Power of Simple.

In building the template that this blog used to use, I ran into a few minor hiccups. I’m currently hosting the site on GoDaddy shared hosting, so I’m limited to using FTP for transferring files. That, by itself, is not a huge deal. I’d prefer rsync, but I can make do.

While chatting with a friend one night, I mentioned that I’d just updated a bunch of stylesheet rules. He replied that it looked the same as it did the previous week, which was odd since I had made several minor updates since then. It turned out to be a simple CSS caching error, caused by me forgetting to update the version number following the script HREF in the HTML. Previously, the link looked like this in the template:

In this example, 4815162342 is just an arbitrary number that gets incremented to trick the browser into thinking the file might have changed by using a simple GET request. It’s a simple way to let the browser cache the stylesheet, but still force it to get a new one whenever necessary by simply changing the number. Rails does something similar, but it appends the last-modified timestamp of the external CSS or JavaScript file in place of the arbitrary numbers I’ve used.

I thought for a little while, but then I realized that what I really ~~wanted~~ needed was a 1-click (err, command) Build Process that did the following:

Create a dist directory to allow for an uncontaminated base point for a release
Copy all of the image files to the dist directory (I really need to get ambitious and make some sprites)
Copy all of the relevant PHP files to the dist directory
Minify the external CSS and JavaScript files and put them in the new directory
Update my arbitrary number in the header.php file so I don’t have to ever think about it again.

Using Ant, this ended up being a simple, yet valuable introduction to the Java Build world. The only thing I really needed to sub out was to a really trivial shell script on my desktop that took care of the minification using the YUI Compressor. My build process went from actually more steps than what I laid out before to the following:

Simple, Repeatable, Powerful

The Power of Simple.

Comments

Recent Posts

Categories

Archives