Marc-André Cournoyer’s blog

Today I had interviews with a couple of candidats for a web developer job. That’s not my first interviews, but it was the first time I asked candidats to write code during the meeting. I was pleased with the results.

I had 1 coding question, 1 refactoring question, 1 design question, a couple of other technical questions to check the candidats level of interest on programming and a bunch of tipical HR questions to check if he won’t be running around killing everyone the next week we hired him.

My coding question was pretty simple: code a C# function that removes string containing “a” and ending with “z” from a given list. I was checking for reference/value parameter passing, InvalidOperationException and ultimatly regex usage.

I would have also accepted the cool ruby one-liner:
list.delete_if { |i| i ~= /a.*z$/ }

For the refactoring question I fired up Visual Studio, drop a couple of controls on a WebForm to list records from a database (using Castle for some time now, that nearly caused me nausea). I then asked the candidat to refactor the HTML and C# code. Expecting them to spot the SQL commands hanging in the middle of the HTML, or those color hex codes spread all around.

The design question was to draw a diagram of a web app to manage a DVD collection. The main point was to check if the candidat would ask me for more details before writing anything.

Then I asked about AJAX, doctype, .NET Attributes and how they keep up-to-date with new technologies.

Fairly interesting!

Since I released the Database Migrator for .NET, a lot of people have asked me if I’ve used it on real/large/live projects and how was my experience. Like any tools, it can be good and … it can be bad. Here’s a couple of guidelines or what some would call “Good Practices” (note my voluntary abstinence over the incorrect “Best Practices” term).

Coming from hand-written SQL script to beautifully manage database migrations is a big step towards programming nirvana. But like the use of any revision control tools you ought to follow some guidelines.

Tip #1 : Test your migrations

Like any code in your application you must test your migrations. Ups and downs code. Do it part of your continuous build process and test it on as many different databases and environment as you can.

Tip #2 : Never edit a released migration

Once your application is released you should never alter it. Doing so would permit that two different database schema have the same version number, which is purely evil and can lead to programming darkness.
A good way to enforce this practice is to allow modifications to the migrations as long as they are on a feature branch or on the trunk and not on a release branch.
I guess one could code a Subversion pre-commit hook for this.

Tip #3 : Keep them short and sweet

Don’t create one migration for version 1.0 of your app. Split it in as many migrations as possible (be logical here). Adding a table ? 001_CreateUserTable, Removing a column ? 002_RemoveSomeColumn. This is simple SoC.
It also ease-up debugging when a migration fails and you only have 3 lines of code in there.

Tip #4 : Be migration-driven

Stop using any GUI to alter the database. Code it!
As a coder you should find that writing:

generate migration AddPostNoteColumn
edit db/migrations/004_AddPostNoteColumn.cs
...
Database.AddColumn("Post", "Note", typeof(string));
CTRL+S
nant migrate

is a lot faster then:

1. Fire your database management app
2. Connect to the database server
3. Browse to the Post table
4. Click in the menu to edit table schema
5. Type : Note
6. Select : varchar
7. CTRL+S

.
Plus you have to write the migration code after anyway.

If you tough of some other tips let us know!