Monthly Archives: November 2007

I am currently reading Zen and the Art of Motorcycle Maintenance by Robert Pirsig and it has been chock-full of philosophical insights. One passage in particular jumped out at me due to its simple, but powerful, message:

The material object of observation, the bicycle or rotisserie, can't be right or wrong. Molecules are molecules. They don't have any ethical codes to follow except those people give them. The test of the machine is the satisfaction it gives you. There isn't any other test. If the machine produces tranquility it's right. If it disturbs you it's wrong until either the machine or your mind is changed.The test of the machine's always your own mind. There isn't any other test.

This quote from the book could relate to almost any field involving technology, but it strikes a particular chord with me in regards to software design and development.

One way this quote can be looked at is an explanation of why a software engineer chooses and, almost more importantly, not chooses a tool for a particular task. We've all seen the flame wars that erupt on blogs and message boards about Tool A vs Tool B. Usually each of these pieces of software was developed to fill a specific need for a particular person whose needs were either not fulfilled by existing tools or the existing tools didn't fit their world view. These original creators were creating “tranquility” for themselves.

When software is created for the reason of creating peace of mind in the developer, the result is often that a tool that doesn't feel right to them is getting replaced. An example of this is the new web frameworks that have sprouted up over the past few years, mainly Django and Rails. The creators of these pieces of software dreaded the ordeal of writing yet another website or web app in Java or PHP because to them these methods didn't produce tranquility and just felt wrong for the task at hand. So these developers wrote something that felt “right”.

Since both Rails and Django ultimately were fulfilling the same purpose, other developers that wanted to go down the path of rapid web development had to choose between these two. On the web, whenever there is no clear advantage of one technology over another, conflict arises. You have people entrenched on both sides of the debate of which technology is better. What is not seen is that neither side is inherently right or wrong. Rightness is only determined by what creates tranquility in the person using the tool.

If you like Ruby and the Rails way of doing things, go that way. If you enjoy Python and the Django method, go with that. The main goal is not to choose some arbitrarily correct right tool, because what may be the bee's knees to one developer may be chopped liver to another. It's usually not that extreme, but the point is that often arguing over particular technologies is like arguing over favorites colors. The only winners are the ones that choose the tools that suit themselves the best.

This is not good at all. And just as Microsoft was gaining some amount of respect as being a secure platform.

I've decided that I want to balance out the technical side of brain with something more artistic so I've decided to learn how to draw.

I spend the majority of the day programming in PHP and fixing Javascript bugs so I think it would be great to be able  to express myself in other ways. I bought A Natural Way to Draw. It seemed to get good reviews on Amazon and it doesn't seem to be one of those books that say “here is how to draw a duck” and “here is how to draw a person.” I want to really learn how to draw so I'm trying to avoid the get-there-quick books.

One motivation to learn to draw comes from my current work environment. Most of the non-software guys at work went to RISD so they all have some kind of talent in the arts. It's impressive some of the stuff they do and understand when it comes to art and design and I'd like to learn a little more about that.

My admiration for artistic talent definitely comes from my dad. My father has always had an artistic side of him as he use to work in advertising. He actually designed the Bojangles and Biscuitville logos, and in church he used to turn out these quick little pen sketches of people around that were really good. One of those quick sketches was of my mom's now-deceased father and it was good enough to warrant a framing and hanging in my parent's hallway. It's always been a skill I wish I had.

I don't think I have any of his natural talent, but I've always enjoyed drawing even though I've never known what I was doing. I would have enjoyed to have taken an art class or two in college, but between switching majors of two fairly time-intensive sciences, I could never manage to find the time for one. Even if I never get “good” (whatever that means), it would be a nice way to balance out the always-on, analytical portion of my brain.

At work, I have been working on somewhat complex site with a lot of Javascript going on in the form of some ajax calls and Google Maps. We noticed that the site had an almost painful load time, approximately 8 seconds for a fresh pull of the home page. This was too much.

The first thing I did was profile it using Firebug's Net tab. Of all the tools in my web developer's tool chest, Firebug is far-and-away my favorite, my oft-used, and my most recommended app. Not only does it give you a super nice DOM browser and a great Javascript debugger, but it also has a nice download profiler under its Net tab. It gives you every single element that the browser requests for your page with its HTTP headers and, even more importantly, the time to complete each transaction.

The profiling introduced a few things instantly. First, there were a lot of images and some were rather hefty. Since I was building the site from somebody else's design files, and that is definitely not my domain, there was not much I could do about that.

The second thing was the Google Maps calls. I put the Google request calls at the end so the rest of the page could load before them. Doing just this took about a second and a half off a fresh homepage load. It was a marked improvement, but still nothing spectacular.

The final thing brings me to the topic of this post. Our standard JS library at work is Dojo. Dojo is great when you are trying to create a RIA interface with all the bells and whistles, such as tabs, number spinners, rich text editors, grids, and trees. Its widget library, dijit, is quite impressive. An early complaint of dojo was that it was a big download. If I remember correctly it was something like 100kb. The Dojo team fixed this 0.9 with a more modular dependency download structure. Say you needed to only use widget A. You'd make the Dojo call in your page for the widget and Dojo would then only download the bits of JS it needed to get that widget on the page. The problem with this is that if you are only using a small subset of the library, you had an exorbitant overhead, not in download weight, but in HTTP requests.

For example, I was only using Dojo to do some absolute positioning stuff for some help tip bubbles and a few simple Ajax calls. This was like going squirrel hunting with a Scud missile. Even with just using core Dojo (no widgets), I made about a dozen HTTP requests just to get the pieces of JS I needed. In total, it took a little over 2 seconds just to load the JS library, even though it only equated to about 60Kb of total file size.

These small tasks almost bordered on something that I could do myself, but since I can be a lazy programmer, I figured a small lightweight JS library that people much smarter than myself have written and tested would be the ticket. I noticed that jQuery was being mentioned more and more in a good way around the web, so I figured this would be the perfect trial to test it out. I can definitely say 'mission accomplished' with jQuery.

I used the non-gzipped packed version which had a weight of 47Kb. This took around 50ms to download and even better it all came in one HTTP request, with no just-in-time loading. The Ajax API between Dojo and jQuery was similar enough that it took very little modification to port it over and I even minimized some of my Javascript to use the awesome syntax of jQuery. By simply switching to jQuery, I shaved a little over 2 seconds from the page load time with no loss of functionality. Nice.

After all the profiling and modifying, I managed to cut the page load from a little over 8 seconds to a little over 4 seconds.

As a side benefit, it was actually fun to write Javascript. With jQuery's well-document API and function list (something that Dojo definitely lacks last checking), I spent more time Getting Things Done than tinkering and experimenting. I was actually trying to do things to improve the visual effects of the site because jQuery made it simple to do so. It was almost completely painless.

This is not a slam on Dojo at all, because if you need some advanced UI features, I'd definitely go down the path towards Dojo. This was simply using the best tool for the job.

I am now looking for more excuses to use the tiny, tidy little jQuery library in other spots. jQuery brought joy to Javascript development, something I wouldn't really have thought possible.

This music video is great. You'd honestly believe you were watching some band perform on some American Bandstand type show in the early 60's.

Wilco is going to be on Austin City Limits tomorrow night.

I'm pumped.