Bikes and Code

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.

I’m not the world’s fasted bicycle racer. In fact, the opposite to that is fairly close to the truth. My general goal is to not come dead last and thus far I have generally succeeded, though tenacity counts for much of that. More than once avoiding the dreaded DFL has come down to mechanical incidents by competitors. This is especially true with cyclocross where nationally ranked riders are in the same category as me.

Generally, a cyclocross race starts out very fast and then disintegrates into a bunch of individual time trials for all competitors. As the speeds are generally quite low, drafting does not play much of a part. In that respects, ‘cross racing is much closer to mountain bike racing than road racing. With all this in mind, my strategy in most races for the past two seasons has been pretty simple. Go as hard as I can for as long as I can when the inevitable happens, just keep going at the limit until the race is over.

The major downside to this strategy is that it tends to mean that after the first ten minutes of the race, I am pretty much useless. From then on, I generally just slowly get passed and drift towards the back. This week’s race, I took a different approach. I would start hard as normal, but make a more concerted effort to stay within my own abilities and try to avoid blowing up too badly.

It worked, sort of. On the one hand, I placed in pretty much the same place I always do, around the same group of riders. On the other hand, I actually felt like I was a part of the race with a couple of attacks and clawing my way back up to these riders when they attacked. I don’t know what to make of it yet. My splits were also nice and tight. The first lap was my fastest, but even between it and my slowest was only 30 seconds. Not counting the first lap, the rest were within 6 seconds. I even managed to finish strong, nearly closing a 20m gap on a pair of riders in the closing half lap.

All in all, productive. Hopefully with a couple of good workouts this week, next week in Almonte, I can actually move up a couple of places. On the other hand, Almonte also has several climbs of doom, which are often my undoing.