Bikes and Code

Once upon a time, the world wide web was invented. I’m not really going to talk about that. Later, something called the Hypertext Markup Language (HTML) was developed. It let you share nicely laid out documents over the web. And it was Awesome.

HTML had some limitations though, it was kind of verbose and you had to mix up your content, paragraphs and such, with code that was used to show how the thing should be laid out and look. At more or less the same time, there were two new pushes to make HTML better. Javascript (1995) was developed to allow a web site designer to make things change on a page. No longer would a web page be a simple static document like a magazine or newspaper article. Cascading Style Sheets (CSS – 1995-1996ish) was created to help a web designer keep the content, the article, online store, etc. distinct and in a different place from the stuff that was responsible for how that content actually looked on the page.

And this was Awesome, except, it wasn’t. At the time that these developments were happening, the First Browser War was underway. Netscape put some Javascript and CSS stuff into their browser. Microsoft put different things into theirs. Bit players in the browser wars did other things. The end result was that if you wanted to make a sufficiently sophisticated web page, you had to create two or three versions of the thing so that it actually worked in multiple browsers. Now, for a long while, this did not actually matter as Internet Explorer 6 held so much market share that you could target IE6 only and get away with it.

That is no longer the case. Arguably, it was never the case, but there were lots of so called ‘web developers’ who happily wrote sites that worked in IE6 and IE6 alone. There are several major browsers now. More importantly, there are several major devices now. Blackberries, cell phones and game consoles all have limited support for browsing the web in various forms. It’s probably a good idea to try to write your web code in such a way it works in as many platforms as possible. More specifically, at least the major platforms that your clients are using.

Approaches

Inevitably, however, some of the fancy dynamic content, crazy layouts or Javascript dancing puppies will not work on some platform that at least some of your customers are using. There are a couple of different strategies for dealing with this scenario: Progressive Enhancement and Graceful Degradation. Effectively, the end result of either of these strategies is the same thing. A website that functions properly under just about every browser platform. There is overlap between the two strategies, in that you can safely say a website built via a progressive enhancement strategy will degrade gracefully. That said, there is definitely a difference in the development process when building a web application in either of these manners.

Having worked on projects that focused on graceful degradation, I can offer my opinion that it is a route fraught with problems. My gut feeling is that if you are going this route, you’re almost better off writing off customers who don’t have your minimum supported browser.

Progressive Enhancement and HIJAX

I’m mostly going to talk about progressive enhancement now as my current project has gone that route. I mainly went that way as I was concerned with the smell of the code that I had written or worked on in the past that went the other way around. Taking a full featured, beautiful Web 2.0 application and trying to hack in static HTML support was difficult and led to some fragile functionality in places. Progressive enhancement seemed to solve that problem in that you started with a functional, solid HTML version and then began to add the flashy enhancements.

Google for HIJAX and read some of the blog posts you find, all are pretty short and give you an overview of the approach I am making with this particular application. There isn’t really a definitive definition of HIJAX, suffice it to say, the point of the thing is what I outlined above. Normal, old fashioned site first, then start writing the flash. The basic philosophy is “Plan for AJAX from the start. Implement AJAX at the end.”

Of course, there is no silver bullet.

While I truly do like the development process that follows with HIJAX, I cannot help but feel I have traded one type of code smell with another. Well, in this case, it isn’t really code smell, it’s more of a project management smell. The single biggest problem I have with the simple HIJAX philosophy is how simply it discounts the nature of web applications.

Implement AJAX at the end.

This is where it all falls apart. Anyone who has built web application that goes beyond the trivial knows that there is no end. Paul Graham talks about the advantages to web development in The Other Road Ahead. He has an entire section dedicated to releases and notes that in a web application, you really don’t have releases. You have features that you deploy one or two at a time.

So if there is no end, implementing AJAX at the end isn’t really possible. So the HIJAX philosophy migrates more into a “Plan for AJAX from the start. Implement AJAX in chunks as you go along.” This is notably still different from “Implement AJAX from the start”, but must be pointed out. The majority of articles and essays on this topic that I have read thus far do not take a high level perspective. They deal with specific implementation issues and provide an outline that works at the feature level. The naive philosophy will not work when applied to an entire project.

This is not to say that it is a lost cause and we should get back to writing rich applications that only work in specific versions of Firefox. Progressive enhancement is the way to go for a general purpose application on the Internet where you do not want to drive away any customers. HIJAX, on the other hand, is a nice buzzword for a simplified philosophy that I think will die out quickly as it becomes apparant that it is just a bit too simple.

For the past couple of weeks, between post start-up brain resting, job searching and cover letter writing, I have been working on a little scratch the itch project.

You know, the ones that we developers have all the time. “I really want something that does X, but everything currently out there kind of sucks.” Though, recently I’ve found most of the things that I want are already out there, but they are a pain to use. I’m not sure where I read it, most likely either Steve Yegge or Joel Spolsky, but the general gist of the thing was that you could probably make a decent living taking some decent products out there and simplifying them down so that any grandmother could use them.

At about this time of year, I start to get questions about what sorts of things I would be interested in for Christmas. I generally respond with blank stares as I really can’t come up with much that I need. That said, throughout the year, I will occasionally stumble across something that might be fun or practical, but I can’t really justify purchasing it myself. What I needed was a way to list those things somehow and let my family see it online.

I took a crack at doing a wishlist a couple of years ago as a trial Ruby on Rails project, but I was pretty busy with other things at the time and while it was technically functional, it wasn’t really any easier than what was already out there. This time around, I took a look at some other wishlists on the market and while a few were good, a few were okay, none really satisfied me. This is probably due to the fact that I had been itching for a new programming project for a bit. Anyhow, I took a look at what the other sites offered and started coding. I have just put a closed beta onto a live server for friends and family and should be ready for a wider audience shortly.

Currently it’s good old fashioned HTML, no rich Javascript features or any fancy AJAX yet. That’s coming, but my goal is to make the thing work well with a simple UI, then enhance it slowly. My past couple of projects focused on building a rich web user interface first, which was followed by a half hearted attempt to bolt on a simpler version for browsers that do not have full Javascript support. This time, I am taking the opposite approach, to make a user interface that can run on any browser under the sun, then start adding features to make it more dynamic. Is this a good approach? Possibly, possibly not but I am going to go with it this time around. The only way to really learn if a strategy is a good one is to attempt to use it.

So, this is a Ruby on Rails project. I am trying to do things the Rails way as much as possible. I am using an Apache web server to serve static content and load balance between what is currently a cluster of three mongrel servers. This is massive overkill, but was fun to setup. Deployment is done with capistrano and I am developing in Netbeans, which didn’t crash as much as Aptana RadRails, so I’m using it. Netbeans is a bit uglier, but what can you do… Naturally, everything is done in Linux. Subversion for source code and I’m trying out Mantis for bug tracking and such. All in all, configuration overhead probably ate up about two days learning everything and bashing my head against various walls.

Rails has been great to learn so far. I’m only getting faster at adding new features and cranking out more appropriate testing scenarios, which is good. Not only that, but I can see a lot of things that will improve my Java coding abilities as well. I suppose that’s why side projects are generally encouraged…

A very important part of continually improving as a software developer is reading. I do that a fair bit and following the suggestion buried somewhere deep in Code Complete, I try to read at least a few technical books per year. I generally average one every 1-2 months and will occasionally ruminate on some of the better ones.

I took a stab at making a Ruby on Rails application a couple of years ago and when the start-up fell apart, I felt that I should use my now existing free time to give it another shot. The technology seemed fairly interesting and while my first crack ended up being relegated to the dust bin of my back up hard drive, it made me want to learn more about the language and framework. The project I have been working on for the past couple of weeks will likely get launched to family and friends in the next week or so and I’ll likely open it up to the public assuming there aren’t any real problems.

One thing that I discovered with Ruby on Rails the first time around is that the framework seemed almost sinister in it’s ability to detect a Java programmer. You’d go through, doing things, never quite sure what you have to write and what the framework does for you. Eventually, you’d step on metaphorical toes of Rails and things would silently stop working. Even worse, you’d get an exception or error from deep in the framework’s stack. It was as if there was some special code in place to detect common patterns from curious Java developers and would blow up in our faces. Probably not, but that’s what it felt like.

I picked up Rails Recipes a couple of weeks ago now and am very glad I did. The book is laid out in a fairly similar manner to the Gang of Four’s Design Patterns, in that it is really a collection of fairly unrelated strategies to conquer various problems. There are sections on how to improve your Rails testing, how to better use the built in Rails support for the Prototype and script.aculo.us Javascript libraries, common ActiveRecord (Rails data abstraction layer for those who haven’t used rails), etc.

The book is well written and to the point. I read through most of the recipes which were relevant to me in less than a day. What was really nice was that there were several how to guides for things which appear in many real projects, but are a bit more sophisticated than what usually appears in the Rails tutorials found in the wild on the Internet. Things like self referential many to many relationships are common enough that you have to know that there is support for it built into Rails, but exactly which incantations are required to correctly set it up are not exactly clear.

Rails Recipes is excellent for things like this. Tasks that are common and are a part of the framework, but are just complicated enough that the basic tutorials do not cover them. I had found that there was a large gap in documentation online between the Rails newbie guides and Rails expert solutions. This book fills that gap nicely.

Many books specific to languages and frameworks, once you have advanced beyond a certain proficiency level they cease to be useful. Rails Recipes is not immune to this and while I am not there yet, I can see the day when I look at the topics covered and think, “How quaint.” That said, though, I definitely feel that this book will help me get to that point more quickly and efficiently than I would have done alone or with the help of the documentation that is currently published on the Internet.

For me, this was definitely worth the investment. If you are a Rails guru, maybe skim it in a bookstore first before buying, but if you are just getting over the rookie phase and looking for the next logical step to take to improve your abilities, this is a pretty good book to go with.