The first small steps

I am now well over a week into putting BiQ on Rails, and I’ve been having so much fun. The fact that I actually getting paid for writing code that’s pretty and well tested means so much to the enjoyment of my work.

Migrating the database

One of the more important decisions I had to make was wether I wanted to change my schema to fit the conventions of Rails. I weighted pros and cons, and ultimately I decided to not treat my schema as an untouchable ivory tower. I am confident that the benefits of doing so will far outweight the hassles of not doing so.

I am currently going through our entire model structure, taking a table at a time and renaming fields in it. At the same time I create a view that resembles the table I’ve just renamed. This is my backwards compatibility guarantee, making sure that all existing scripts should continue to work, but they’ll be querying views instead of tables – at least that’s the theory. If it turns out some scripts break, I figure they can be fixed by pretty much doing search and replace on the specific field names.

I take care to make sure that every migration is non-destructive, since I need to be able to roll back and have a database that structurally looks exactly like it did when I started.

After adding a new migration I run all migrations from version 0 followed by my test suite to make sure everything still works. Did I mention that migrations are frigging sweet?

Migrating the code

During my initial rewrites I took an approach that I didn’t want to continue. I basically translated VBScript code to Ruby code line for line, which led to ASP on Rails or something. It definitely didn’t have the niceness of proper Rails or Ruby code.

For the rewrite proper, I’ve taken a more behaviour driven approach. Until now I’ve been going through the existing lowerlevel libraries, which roughly resembles the Rails models. For each function in the VBScript library I’ve written unit tests, that test the behaviour I read from the VBScript code. When the tests are written, I start writing the Ruby code that satisfies those tests.

This decoupling is important as it allows me to mentally break free from the structure and decisions I made when building the VBScript application, and allows me to take advantage of Rails proper (especially callbacks have proven extremely useful).

It also has the nice side benefit, that I end up with a comprehensive test suite, which is definitely not a bad thing.


So far this is how the stats look:

| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
| Helpers              |   246 |   156 |       3 |      24 |   8 |     4 |
| Controllers          |   185 |   147 |       6 |      15 |   2 |     7 |
| Components           |     0 |     0 |       0 |       0 |   0 |     0 |
|   Functional tests   |    88 |    63 |       2 |      10 |   5 |     4 |
| Models               |   482 |   345 |      11 |      38 |   3 |     7 |
|   Unit tests         |   787 |   630 |      10 |      88 |   8 |     5 |
| Libraries            |   102 |    65 |       1 |       6 |   6 |     8 |
|   Integration tests  |     0 |     0 |       0 |       0 |   0 |     0 |
| Total                |  1890 |  1406 |      33 |     181 |   5 |     5 |
  Code LOC: 713     Test LOC: 693     Code to Test Ratio: 1:1.0

I don’t have a figure ready how many lines of ASP/VBScript code I’ve converted, so you’ll have to wait for another post for those.

Timewise, I am not quite on track, unfortunately. Primarily because there’s a lot of plumbing occuring at the moment – like the database migrations mentioned above. This is stuff that needs to be done only once, and later on I will hopefully be able to reap the benefits of those in form of meeting my milestones.

I am cautiously optimistic that I’ll meet my first deadline (24 days to go), and very excited that I am actually outputting code that I can be proud of for a living.