I was very pleased to release the latest version of RikMigrations on Friday, this 0.3 Release can be downloaded here.

The latest release has the below new features

• MSBuild Task
• Generics
• Inserting Default Data
• View Generation
• Improved help with Command Line Arguments

Hope everyone who uses this library finds these useful.

As of this morning I'm now onboard of my first open source project, which is all very exciting I've been look for an alternative to ruby migrations for quite sometime and have recently bumped into RikMigrations.

So from this point onwards all i-nnovate projects will be using RikMigration as there database management system, which should add a new dimension to everything. I certainly wont miss constantly writing sql to modify the database.

Recently at i-nnovate we've been dog fooding our micro-isv app task|mate for our consultancy work to see what feature's we're missing and what bugs need fixing. Here are a few things we've learnt so far from the experience.

• Always plan a little bit before you start.
• Don't try and write a production application in a language your learning.

When we first started task|mate our aim was to make managing our projects and teams simpler and more efficient. So far I think we've made great strides along that direction, however since the majority of our early code was done on an experimental basis some parts of the application don't live up our normal high standard and really need redoing before launch.

Anyone who's done there micro-isv research know's that everyone is writing there applications in Ruby on Rails, so naturally we investigated it and found that it did indeed increase our productivity and although to create web 2.0 app's with ease to start with. However we also ran across a couple of unforeseen problems, basically when your learning a new language you tend to do things the newbie way, now thats fine but then sections of your system start to develop a bit of a smell.

So know we have these code smell's around the code base, what do we do about them? We'll we've decided to throw the prototype away, and rewrite the system using monorail and C#, this way we can use all our existing knowledge to make the application truly brilliant and not fall for the same problems we had previously. Follow the blog to see what features we implement over the coming months.

In the software development world, staying pragmatic is one of the hardest things to achieve. If you look back historically at the IT over the last 50 years or so there's always been two competing factors, Unix or windows, apple or PC, Firefox or Internet Explorer the list goes on.

So over the last couple of months I've looked seriously over changing my development language of choice (C#/.net)(this is something I do every 12/18 months to stay on the ball). Well for the first time since starting .net I came upon a worthy rival in Ruby and probably more importantly Ruby on Rails. In all the emotions of finding a new fun choice, you start to get a bit carried away and start thinking about changing everything especially when Ruby doesn't play too nicely with Windows.

However when you consider the business side of things, I don't believe the productivity improvements of Ruby hold as a big enough argument, as it would take about a year of cross training to Ruby to become as competent a Ruby developer as I am a C# developer. During this cross training process my customers wouldn't be getting the best value for money, so for the moment I'll be staying where I am and taking all the things I've learned from the Ruby world back to .net with me.

Don't take this as Ruby is rubbish, it's just that at this point in time I don't believe there is a valid reason to convert from .net, although I'll be keeping an eye on the language over the coming years just incase that changes.