ruby

Migrations

Eric on Rails

Rails has an extremely interesting idea for keeping a database up to date, no matter where it is (development, staging, production, etc.). Its called Migrations.

I’ve dabbled in this idea before – there is an open source project out there called dbdeploy.net, which is based on the java project dbdeploy. What it does is run all of your database update scripts in sequence, and theoretically allow you the capability to roll back to a previous version. I used it a part of our build process to keep our unit test database (there’s an anti-pattern we feel for) up to date. It worked fairly well, but wasn’t perfect.

What happens with Migrations is you write Ruby code that tells how you want to transform your database, and it will get handled no matter what kind of supported database you have. Its completely SQL syntax agnostic. It also is easier to create the rollback aspect, because it is just another method you have to write. And numbering is made easier because Rails takes care of numbering them for you.

The first thing I wanted to do when I saw this concept was port it to .Net. Yeah, except its been around for a long time, so of course someone beat me to it. Actually, a couple of people did.

So, I figured I’d do the next best thing and maybe write a post about how to use one of these ports. But Justin Etheredge beat me to it (long ago, in internet time). So, if you don’t know anything about Migrations or you do but you didn’t know you could use them from .Net, head on over to Justin’s post now.

Advertisement

Eric on Rails

Eric on Rails

As I mentioned previously, I am actually going to really learn a new language or two this year. I played around with Ruby probably 6 years ago, but just a bit of dabbling while I was on the bench (I was in consulting at the time). I retained almost nothing.

Other than a brief diversion into PeopleSoft on Unix platforms with an Oracle database for two lost years of my life back in the mid-90’s, I’ve been almost exclusively working with Microsoft development tools. I don’t see that changing for me in a professional sense in the foreseeable future, but I know I need to become more diverse as I spend more time pretending to be an architect. There are other schools of thought out there I can learn from.

I have in general spent most of my reading and studying time with non-Microsoft things – I have spent a lot of time with agile project management techniques (mostly Scrum) and agile “engineering” techniques. I have embraced a lot of non-Microsoft technologies in the .Net space (NHibernate probably being the most notable one). So clearly I can no longer be called a Microsoft fanboy (I once used to get that a lot Smile). So this isn’t about Microsoft or any particular technology vendor. Its about making myself a better software development professional.

As I stated in this blog before, the innovation these days seems to come most heavily from the Rails world. I hate the idea that I’m following the cool kids – I never have cared a lot about doing the popular thing, but in this case, I think they might be on to something. Don’t get me wrong – there are lots of things that are suddenly innovative about Microsoft. The phone is a significant advancement of the state of the art, even if I doubt it will catch on. WebMatrix seems to help ease web development without the soul crushing abstractions of Access or LightSwitch. And F# is a good gateway/compromise solution to functional programming on the .Net platform (someday I hope to spend a fair bit of time with that animal).

But the next leg of the future is paved with things prominent in the Ruby world. They could have come from anywhere (and in the past seem to have most often come from Java, but I posted about that already). But right now the cutting edge of ideas like dynamic languages, lightweight web development, behavior driven development, automated acceptance testing, etc. seems to firmly reside in Ruby world. And I like the promises that those ideas bring to help enable us to build better software with higher quality faster.

My interest is not, as I said above, to switch my day job from C# and the .Net world to Ruby and Rails. There are still really cool things going on in .Net. I still believe in “thick/fat/smart” clients. No toolset does a better job for building such things than .Net. WPF and Silverlight still have a future.

Instead, I think that by spending my free time playing with Ruby and Rails will help me discover ways to be a better C# developer. Its time for me to leave my comfort zone in hopes of learning valuable new lessons (this is my initial guide, but I know there will be other resources – I’ll post about this book and those resources as I can). I plan to blog about my discoveries. Many of them will probably be things you already knew. Some of it may be things I already know, but not as deeply. It should be a fun ride.