Bikes and Code

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.

The object-relational impedance mismatch. Unquestionably one of the stickier problems that a developer working with a database backed system has to deal with today. Depending on exactly who you believe, it’s fairly safe to say that a significant percentage of developers have encountered this particular problem. I won’t go into extreme detail on the problem as this article covers the main points beautifully. I will give a brief outline of the problem, then discuss my thoughts on Hibernate and Ruby on Rails, two technologies which address some of the problems. Neither is perfect, but they both have merits.

Most software developed today is object oriented (OO). This isn’t news to anyone, it makes a developer’s life easier as it allows you to conveniently forget about big chunks of code, which means you can hold more of the system in your head at once. This is good all around. At the same time, a sizable percentage of development efforts store their data in a relational database. Databases allow someone working on a software project to ignore the issues of storing and retrieving data. Thus, in many of these projects, the world of objects meets the world of relational databases and that causes problems.

One of the ’solutions’ to the problem, quoted as they only address the actual software development aspect of the equation and not the political or infrastructural aspects, is Object-Relational Mapping (ORM) software. ORM software tries to take an object model and map it to a relational database or vice versa, depending on the system. The idea behind ORM is that if you manage to intelligently write something that maps from one to the other, you can keep your database and OO software distinct without having to deal with the messy logic that is required to go from one to another.

What I’m getting into here is more the ‘feel’ of the frameworks in question I am not passing judgement on either one as both of these frameworks provide significant benefits and drawbacks.  I’ve used both of these a fair bit in recent months and while by no means an expert, I can at least appreciate what they are trying to do. I should also note that there are likely errors, I am certainly overlooking aspects of Hibernate, my defence to that is poor, mainly that the framework is just too huge and knowing it all is at least a year long full time project. Few people other than full time Hibernate developers can afford that kind of investment.

If I had to use a single sentence to describe how a developer should approach the Hibernate framework, it would be, “The object model is god.” Hibernate is geared around using XML or annotations (what I actually used primarily) to mark up the object oriented Java code with hints, pointers and information on how an object should be written into the database. In practice, this means that in many cases until you actually go into production where other people start relying on the data, you may not even need to think about the database on anything more than a trivial level. You write your Java, add the hibernate hooks and let the framework do the rest.

With the ActiveRecord aspect of the Ruby on Rails framework, the equivalent statement would be, “The database is god.” In Rails, you create your database, set up all of the tables in some normalized fashion, following a naming convention and walk away. Rails then analyzes the actual database and generates objects which you then use in your application. You need to provide hints to the system when you start working with actual concrete relationships, but in general Rails does a decent job of generating objects which let you save and retrieve data.

I suppose it should not be a surprise that the Java based framework takes the approach that the objects are the key to the system and the database is a pesky, but important aspect that needs to be managed. Rails, a framework which is possibly THE case study in pragmatic programming, on the other hand, simply re-writes itself to match the database. Put another way, the feel I get from Hibernate is, “Write good OO code and we can map it onto a database.”  Rails, on the other hand appears to be simpler, “Well, you’re stuck with that database, here are the objects to manipulate it.”

The unsaid downside to Hibernate and the one problem I have with it is that you can go a long ways towards avoiding SQL and thinking directly about the database, until you need to refactor your code. Refactoring your code will likely mean needing to refactor the database to match your changes and in many organizations, this is simply not possible due to political reasons. (Accounting and sales have their own systems which use your data! You’ll break them if you change!)  At this point, SQL will start creeping into your code, while not a bad thing in and of itself, SQL that makes it into the system does start to mitigate the benefits of a full ORM system. Of course, this problem could be minimized by keeping an array of objects that do have accurate mappings and then putting an abstraction layer on top of that to massage the Hibernate equipped objects into actual system objects.

This is not to say that refactoring a Rails application would not end up with the same problems, however, your Rails code, by virtue of being generated from the database and not from the objects means that you have some sort of stability in terms of having a layer that does accurately map to the database, whether you like it or not.

The opposite approach that these two frameworks take is fairly interesting, especially when you work with them back to back. My gut feeling is that, all other things being equal which I should stress they are not right now, over the long term the Rails approach is going to be the more maintainable of the two. Unfortunately, for the foreseeable future, Rails simply will not be an option for political and business reasons, some valid, some not. (Valid: More good Java developers than Ruby developers right now. Not Valid: Scalability arguments, very, very few applications need to scale to millions of concurrent users, so for most of us, this isn’t even a concern.)

Anyhow, that’s it for now, it’s been on my mind for a while.