Friday, January 27, 2006

RadRails 0.5.3

In the rails community it would appear that the majority of developers use Macs and the text editor TextMate. (What is it about Rails that seems to attract so many Mac people? I'm not arguing, I'm a Mac guy too, but it's an interesting question to ponder) But coming from a Java background I've grown fairly accustomed to Eclipse and so the RadRails and RDT Eclipse plugin projects caught my attention. But they each have their own strengths that made me wish I could take the best of both worlds. Well version 0.5.3 of RadRails shows the benefits of those two teams collaborating. RadRails is now using RDT for editing Ruby. It also means you get all the other nice features of RDT like a visual Test::Unit runner, the RI view, etc. I'm also pretty excited to hear where the developers of RadRails want to take RadRails. In short:
The focus of RadRails is going to move towards achieving dynamic content assist.
Rails development gets better all the time and the future looks bright.

Tuesday, January 17, 2006

Snakes and Rubies

Over on the Django website you can find a video of presentations made in Chicago on December 3rd, 2005 by two leaders in web application development. Adrian Holovaty, one of the Django creators, and David Heinemeier Hansson, the creator of Ruby on Rails, present their respective frameworks and then take some questions from the audience. Naturally I was curious about the Ruby on Rails presentation. David quotes Richad Feynman:
You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right.
and then goes on to make the assertion:
Beauty leads to happiness, happiness leads to productivty, thus Beauty leads to productivity.
and that Ruby on Rails is part of his search for beauty. He may be on to something. It's also fun to hear him curse out Windows a few times, "this is ugliness" :-)

Sunday, January 15, 2006

Rewrites

System rewrites must be extraordinarily popular because I've worked on my fair share of them throughout my career. And usually the story is the same...

Poorly-trained developers in an IT department or startup slowly build a system over the course of a few years and then eventually come to the realization that the system needs a rewrite. Here are some of the most common reasons:
  1. The database design is bad (Usually it's atrocious. It's very rare to find good data models)
  2. The code for the business logic or UI is a hopeless tangle of procedural code (You'd be lucky if thy UI and business logic are separate. I've even seen one implementation of a web application where data access, business logic, and even HTML markup was generated by Oracle stored procedures.)
  3. Performance issues have cropped up (Most applications are bound by the performance of the data access code. Good data model design is crucial in this respect, but bad queries (easier to make with object relational tools btw) are the usual culrits and are a good place to start.)
  4. The technology is obsolete. (Unfortunately this is a fact of life in IT and it is common for this old code to be the only "documentation". Keep the developers of the future in mind when writing your code and make it readable.)
  5. It's just so fragile that implementing new functionality takes way too long. (If you see gigantic nested if-then statements, run away now before you run away screaming later.)
  6. The new IT manager doesn't like his/her predecessor's legacy (It's sad but true. The "wiping out all vestiges of that 'bad' manager who was the harbinger of all things evil" is a bit of a spectator sport among developers.)
  7. It's a combination of some of the above. (And if you've really arrived at the precipice and are gaping into the abyss it'll be all of the above.)
Eventually the decision to rewrite is approved and someone must make the decision about how to redevelop the system. People usually see these two paths:
  1. They can redevelop the entire thing, affectionately dubbed the "big-bang approach"
  2. They can incrementally replace the subsystems one at a time.
Usually the incremental approach is the most attractive because it's seen as having less risk. And of course managers who like their jobs like less risk. But this "lower-risk" decision usually comes with one very difficult problem: "How do you integrate the new code with the old and keep them both running at the same time?" Well the typical decision is to just leave the database alone and build the new application on top of it. While this seems to be an easy choice (look at all the stuff you can reuse and no data migration activities to endure), this is one of the worst things you can do.

No matter how good the database may appear at first glance and no matter how much faith you have in your object relational mapping (ORM) tool's ability to "abstract away the ugly parts", you are always going to compromise your object model. It is extraordinarily difficult to design the best domain model you can without repeating the design decisions made in the database. It's like trying to hum a tune while listening to another song on the radio, you inevitably end up singing the song on the radio.

For several years I believed that ORM really gave me an abstraction from the physical database, that the two were independent and it was meta data that glued them together. But after some real experience, I learned the hard way that was a fantasy. If you want to be productive and want to work with an object oriented domain model that you can easily refactor you really need to be able to change the data model just as easily. I now consider the domain model and the relational data model to be two perspectives on the same thing. If you don't believe me, I ask you to consider the following trends:

  • In EJB3, the relational view of the domain model is becoming part of the domain model through Java 5 annotations. The main reason for this is practicality. It embraces the DRY principle (Don't Repeat Yourself): every piece of knowledge should have a single, authoratitive, and unambiguous representation in a system. It's an acknowledgment that the attribute oriented programming model advocated by XDoclet so many years ago is a good one. I suggest that you should even generate your database from this metadata, keep it DRY.
  • In Ruby on Rails, much of the domain model is generated at runtime by querying the database meta data. The database can't express everything in a object model so the rest of the picture exists in the Ruby domain classes. This practical approach that intrinsically marries relational and object views is one of the many features of Ruby on Rails that make its supporters claim such high productivity benefits.
You may also want to consider what data warehousing people have been doing for years. They always treat the transactional databases as sources of data but they always stage that data somewhere else and "cleanse" it before making it part of their warehouse. So while they're dependent on that data model for ongoing feeds they have a real abstraction from it and none of their cubes or reports are impacted by a change in the data source.

Rewrites appear to be inevitable. Even if the reasons for doing it are dubious you'll probably find yourself in one of these projects sooner or later. But if you going to get involved, make sure it's a complete rewrite. Don't take shortcuts. The most successful rewrite project I worked on created a new domain model and new data model for the new application and used database technologies to keep the new and old data model synchronized. We got the productivity of not being bound by the old (and very scary database) and we kept everything else that was dependent on that old database running by keeping the old database alive. The most aggravating projects have been the ones that tie you down by saying "leave the database alone". Then there are the ones that say "leave the UI alone" too. Ugh! But that can be the subject of another article...

Thursday, January 12, 2006

Checkboxes

Ever since I started developing Windows applications I've consistently seen other developers use two radio buttons for a boolean option with ridiculous labels like "YES"/"NO" or "TRUE"/"FALSE". And just today I'm redeveloping a page with 3 of these things. Why on earth don't people use a checkbox? It was made for this! On or Off! For crying out loud! Arghhh!

Thursday, January 05, 2006

Déjà vu

On this date one year ago the Canadian junior hockey team beat the Russians in a gold medal match. This time they were one of the underdogs in the tournament but still came out on top. Congratulations again!

Wednesday, January 04, 2006

RoR & Foos update

Tonight I decided to stop tinkering with the object/data model and start building the simplest ladder web app that would work. In pretty short order I was able to display a sports ladder (e.g., foosball) with names and positions. But a display-only ladder application isn't teribly useful so I figured the "easiest thing that works" was to allow a user to swap the positions of two teams on the ladder by selecting a couple checkboxes and clicking on a button labelled "swap positions".

After a couple hours work I had something that was minimally useful! :-) Then I decided that I really wanted to be able to support multiple ladders at the same time for both singles and doubles play (after all my overly-analyzed object model already supported it). And fortunately as I refactored the code I learned a bit more about Ruby on Rails' layouts and partials features. But one of the better ideas I had was adding a signup method to my ladder class that looks like this:

def signup( players, screen_name = 'undefined' )
[...]
end


It can be used like this:

singles_ladder.signup([joe])
doubles_ladder.signup([bob, doug], 'Hosers')


Certainly a lot simpler than the code I had before that created a team, added the players to the team and then added the team to the ladder. For some reason it just felt more Ruby-like to do it this way.

Monday, January 02, 2006

2005 Redux

In 2005 I think I met my Pragmatic-Programmer-inspired goal to learn a variety of programming languages e.g.,
One thread that seemed to permeate many of these technologies was object-relational-mapping. There's EJB3 and Hibernate for Java, ActiveRecord for Ruby, Core Data for Cocoa, and even LINQ for C#. While the implementations all vary, the basic principles apply to all. It seems like all that time I spent with TopLink in 2001 was well spent because ORM has become the norm.

It also looks like dynamic languages are becoming more popular. I'm glad I spent some time looking at Objective-C before getting on the Ruby bandwagon. A mature framework like Cocoa helped me appreciate the power of a dynamic language. Rails will undoubtedly continue to occupy me for at least a little while in 2006.

But not everything I did in 2005 was related to programming. I also spent some time with:
  • A family trip to Maui
  • Video Editing
  • Looking into my family history
  • Playing foosball
  • Digital Photography
Travelling has always been something I've enjoyed doing since I met my wife. But when we had kids our amount of travel significantly declined. But now that they're getting old enough, it's nice to be getting back into it. In 2004 we made it to Disneyland, last year it was Maui. Who knows what 2006 will bring...

At the end of 2005 I finally burned a custom DVD. I made a slideshow out of the pictures I took at Christmas, added some videos I edited a few years ago and put them all together with some music and some fancy menus. With the exception of GarageBand and some help from Final Cut Express, I used all the other pieces of iLife for my grand DVD opus.

There's only one thing I wish I'd done more of in 2005, and that's art. I suppose the video/editing/photography thing could be considered somewhat artistic but I'm talking traditional oil-on-canvas kind of art. My son recently complimented me on a painting I'd made a few years ago. Maybe that'll inspire me to finally break out the paints... Here's looking forward to the new year. :-)