Substitute for Thinking

The 2008 European Ruby Conference is coming to Prague this weekend -- March 29-30 -- and I'll be there  The program says that we can expect talks on a wide range of subjects including programming, methodology, and infrastructure as well as an opening keynote from Matz himself.

If the e-shop gods smile upon me, I'll have a new (read: viable, holds more than 20 minutes worth of charge) battery for my laptop by the weekend, and I'll try to post an entry or two as the mood strikes me.

One of the first things that impresses a lot of developers when they first start using Rails is the almost complete lack of effort required to implement models using ActiveRecord.  Model objects are super simple to create thanks to the built-in generators, and assuming followed all the relevant naming conventions while designing your database, you’re up and running with a full-featured business object layer in no time flat.  If you’re used to another ORM framework that’s heavier in configuration – Hibernate, I’m looking in your direction! – the benefits of this way of doing things become apparent immediately.

I earned my chops developing two- and three-tiered applications that started with a database model that baked in most of the business requirements for the system as data entities, relationships and constraints.  Over that, you designed and implemented a business objects layer with all the necessary mappings to database objects (and woe unto you if there should be any major differences between the OO and relational models), and over that, you layered your user interface.  The applications often ended up looking like they were designed by a programmer – uninspired and mechanical, front-ends simply slapped onto databases – and you could expect a fun time if some damn user comes along with a requirement change that requires modification of the database.  The word for the process and the applications it produced, people, is B-R-I-T-T-L-E.  No one was happy about this state of affairs, but as developers, we passed the buck to the business stakeholders, blaming them for not being able to stick to their guns when it came to requirements.

For a long time, I didn’t really get why someone writing a serious application would ever want to use Rails migrations, and then I made a point to make a serious attempt at using them, mostly as an experiment.  I didn’t expect to find anything there that would be worth keeping up, but I thought it would be good to know something about it on the chance I ended up taking over a project that used them.  What I found, though, was a tool that has really changed the way I build applications for the better, and I use them from the very beginning of the project.  These are a few reasons why.

1. It puts more of your codebase in Ruby.  There are a few things that everyone out there calling him or herself a developer should know, and how to put together basic SQL queries and build scripts is one of them.  SQL forms the basis for our understanding of relational databases in much the same way that language forms the basis of our thought patterns, and since most business applications require a database of some kind, I’d say that makes it indispensable.  Having said all that though, it’s also a pain in the ass to write.  (Don’t believe me?  Look at all the tools and libraries developed over the years whose only purpose was to avoid having to write SQL code.)  So while it’s an important thing to know, it’s not necessary to practice it daily, and if you can find a way to eliminate the need to write and manage SQL code in your application, especially if you can replace it with code that’s as compact and expressive as that enabled by migrations, all the better.
2. You probably don’t need a graphical design tool.  I was hooked on these things for a long time to the point that I practically forgot how to form proper CREATE TABLE syntax.  I had convinced myself that these things were necessary in order to manage the complexity associated with the database model and to have a graphical model to use as a tool for communicating with business users.  The reality, though, was that I never showed a data model to a non-technical stakeholder and that the models I was working with were usually only a few dozen tables.  In fact though, I was really just trying to get around writing and maintaining SQL build scripts for each phase of development.  I don’t need to do that anymore because migrations builds the database out in parallel with the application.  Any complexity that was there before is now gone because I only need to focus on the parts of the database that I’m actively developing.
3. It promotes iterative development of application features.  Under the old-school, database-first methodology, you would first build out a new iteration of your database model in order to support a new batch of features, fix all the code that you may have just broken, and then extend the application- and presentation-layer code as needed in order to get the desired behavior.  It seemed reasonable at the time, but in practice, the volumes of changes that were being pushed through during a given development cycle made this method a lot closer to the much-derided waterfall model of development than it was to anything that could be called iterative.  The flexibility afforded by Rails migrations is that it’s just as easy to do small changes to the database as it is to do large ones, and all the database versioning is done for you automatically.  So there’s no additional cost associated with making a lot of small changes to the database instead of batching them into one confused mess.
4. Data can be loaded directly from your migrations.  There are a lot of different methods in use out there for inserting data directly into newly created database tables from a migration.  (You can find a good summary of the various possibilities with examples here.)  I use this a lot when I want to load reference data into lookup tables or when I need to insert a few rows into a table in order to bootstrap the application.  (Ex: if I need to have an Administrator account automatically inserted into a Users table in order to provide initial access to a protected application.)  If I’m only dealing with a few objects (3 or fewer) I’ll usually just create new model objects directly in the migration.  For larger collections, I’ll fall back on fixtures or data pulled from delimited text files with a few lines of custom code thrown into the mix to process the files.  Doing it this way allows business users to produce and edit the data files directly in Excel which requires very little in the way of explanation.
5. There are a lot of great plugins available to fill gaps in migrations.  You can probably guess what my initial complaint was about migrations: no foreign key support.  The good news, like most other things within Rails, is that if there’s something that’s bothering you, there’s a good chance that it’s already been bothering someone else, perhaps even enough to write a plugin to solve it.  In this case, you can install redhillonrails_core or sexy_migrations to provide foreign key support along with a number of other nice-to-have features.  The lack of FK support wasn’t a deal breaker for me, but it was nice to know that I could apply a simple fix and get the behavior I wanted.
6. Rake provides tasks that make it easy to manage your migrations.  I tend to use db:migrate:reset a lot during development to simply drop and recreate the database in its latest form.  In production environments, I usually use the more judicious db:migrate.  In both cases though, I find the whole process a helluva lot easier than when I was typing the database username and password, schema, and SQL script location into the command line.

Rails goes a long way toward closing the loop between application and database thanks to the object-relational integration provided by default in ActiveRecord.  Migrations really finishes the job by removing the separation between the two layers from the development process.  I started out looking at it just for the sake of completeness, and in the end, it really led to a massive improvement in my development process.

I just generated a mobile version of my blog using Wirenode, and I'm not exaggerating when I say that it was as easy as the WordPress 5-Minute Install: step 1 -- blah blah blah, step 2 -- blah blah blah, step 3 -- there is no step 3.  You should try it out if you have 30 seconds to spare.

My friend Tomáš Zeman has been working on building up this application for a few years now, and recently things have really started to pop for him.  He just released a new version of the application in January, and he won an award for the application and was written up in Lifehacker in February.  I've known him since I came to the Czech Republic in 2000, and I can attest to the fact that he's a smart guy who's got a great future ahead of him.  Gratuluju, Tomáši!

To those of you out there still checking in here, much appreciated. Much surprised, too. It's been a while since I've found the time to post anything which is, I suppose, a sign that things are going well within the scope of this whole new careerscape. Work and business opportunities have been trickling in, and I've had a chance to meet with many people (probably some of you) to discuss some exciting and potentially very interesting projects. So even though I don't feel all that brokenhearted that I've not posted in an unforgivably long time, I still have a little bit of a lingering unpleasant feeling from knowing that I have an orphaned blog out there somewhere.  He has my name, but still I've abandoned him, and the longer I avoid him, the more embarrassed and less motivated I am to try to reconcile with him.  Damn you, Guilt, why must you torment me so?!

Sorry, I had a little bit of a Charleton Heston moment there.

The point is that, at least intellectually, I think that blogging is a capital-G, capital-T Good Thing® and doubly so for someone who finds himself in shoes like mine.  (But not my actual shoes because, let's face it, the width is going to cause problems for you even if you can get used to the odor.)  It doesn't matter who you are, if you're trying to keep up a blog or any other habit, the inspiration dip is going to hit you too, and when it does, all the good intentions in the world aren't going to do a thing for you.  The difference between taking a couple of days away and having that thing perpetually stuck near the bottom of your to-do list is just a matter of knowing why you're doing it.  So with that in mind, I give you a few of my own reasons why I'm coming back to my blog.

1. Blogging is good for business.  You're about to say, "Well, duh!" but since I started writing this blog, I've heard from a lot of old friends, former co-workers, and past business contacts, and some of those conversations and e-mails have generated projects and leads.  I don't want you to feel that I'm underestimating your intelligence by stating the obvious here.  Rather, I'm stating the obvious so that the obvious doesn't become conspicuous by its absence and, thus, cast suspicion on the entire post.  Blogging is good for business just like giving lectures or writing a book or anything else that builds your public reputation, but if that's your complete list of reasons for writing a blog, you probably won't stick with it for very long.
2. Blogging keeps your writing skills sharp.  I've always been a decent writer, and I've found one thing to be true: good, coherent writing is indicative of a broader tendency toward clear, effective thinking. If someone is able to sit in a chair, think deeply about a given concept, decide what words and sentences are essential to describing that concept, and write it all down in a way that communicates to most other people, that's a person who can do just about any kind of knowledge work you can throw at him.  The guys from 37signals have this to say in their book Getting Real: "If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more."  I couldn't have said it any better myself.
3. Blogging lets you clarify your thoughts on a subject.  Some people pay a therapist, others get a blog, I guess.  While it's pretty unlikely that I would use this as a space for discussing confusion from my childhood or fishing for amateur interpretations of the dream I had last night, I think it can be pretty helpful as a means -- first, through the act of writing, and then, through feedback and revision -- for clarifying what I think and feel about certain subjects (within the scope of this blog's subject matter).
4. Blogging gives you a voice. When Sun announced that they were buying MySQL a couple of months back, I wrote a little bit about it a couple of days after the fact.  I remember feeling good writing that entry because here was this far-away, far-out deal that I had nothing to do with, but by virtue of having an internet connection and an opinion, I could say something about it and join the army of confused people who care about one or both companies, people who rely on their products to make a living, people who couldn't stand to see another screw-up like the one they really hoped they weren't just witnessing.  Moral to the story: you don't need to be an A-lister to have your say.
5. Blogging allows you to give away useful knowledge.  Internet culture is very much a gifting culture.  People open their free web browsers and expect to be able to access services without payment or restriction: news, reference information, applications, and so on and so on.  The open source community is even more about giving away your best work in exchange for fame and status, at least within that small segment of the population who cares. I always got the biggest thrill out of programming from knowing that someone out in the world somewhere might be using some code that I'd written.  They probably didn't even know my name, but they were getting some measure of value from the work I'd produced.  A blog is just another vehicle for that same impulse except that it's not as tightly constrained by syntax and structure as a programming language would be.