culture, tech, music, and code

I’m sure I’m not the only Rails developer who missed RailsConf 2009 due to a plethora of various reasons. Well, I didn’t let that hold me back from gaining as much information as possible from the Conference. Although these resources are pretty easy to find, I thought I would help you out by providing you with some links.

First is the official RailsConf site, hosted by O’Reilly. This would be an obvious first choice for people, but I am still going to restate that there is a great deal of free content available here. Most of the keynotes and speeches are now up in pretty high-quality video and slides are available in PDF form for both the keynotes and most of the tutorials.

Next, if you’re like most people, you might not have enough time to watch the hours of videos or sort through all the slideshows available over at the RailsConf site. Well, you’re still in a great position to learn from those keynotes, as Nick Quaranto attended a ton of events at RailsConf and took great notes, which he published here on his blog litany against fear. Some highlights include the David Heinemeier Hansson keynote on the future of Rails and the secret to being productive using Rails, some great keynotes about git and github, and a speech given about testing with Webrat. Definitely worth checking out.

The final resource I’m providing related to RailsConf is from Rails Magazine. They just published their second issue and it is a special edition for RailsConf. I really am trying my best to support this magazine because I think it would be great to see this magazine grow into something great (not that it isn’t already) and be avaialable at bookstores and news stands. The big article goes over what’s coming to Rails 3 and details about the Merb and Rails merge. Oh, did I mention this magazine is free in digital form?

And while I’m at it, I thought I’d also point you over to a very, very detailed article about the benefit of building websites for projects on github and how things should be documented. I think if this is more heavily adopted, it would make life easier for developers using a lot of various gems and plugins. But at the same time I understand that this does take effort to create and most people aren’t exactly overflowing with free time. Either way, a good read that I though I’d share. I hope these resources help you to understand what happened at RailsConf and hopefully taught you something new.

A migration is simply a Ruby source file in your application’s db/migrate directory. These files help to make small changes to the database extremely easy and quick. Want to add a table or rename a column? Write another migration and run rake db:migrate. With automatic versioning you are able to see the changes made to the model just by looking at the latest migration file. No more repetitive SQL queries. Now you can access your data in an understandable way right in your code. With that, let’s get coding!

First we can use either the rails generator to create a migration or use the model generator, which will also give us a migration file. Note: you could create these files by hand, but it is less error-prone and probably more efficient to use a built-in generator.

To create a migration with the model generator we would do something like this:

ruby script/generate model post
  exists app/models/
  exists test/unit/
  exists test/fixtures/
  create app/models/post.rb
  create test/unit/post_test.rb
  create test/fixtures/posts.yml
  create db/migrate
  create db/migrate/20090113055719_create_posts.rb

To create a migration on its own we would do something similar to this:

ruby script/generate migration add_category_column
exists db/migrate
create db/migrate/20090113055952_add_category_column.rb

To run the migration we use the db:migrate task

rake db:migrate

When running the db:migrate Rake task, a schema_migrations table is looked for to keep track of migration versions. If one isn’t found it will be created on the fly. After each migration is run a row in the schema_migration table is added.

You can also use the db:migrate Rake task to force the database to a specific version by supplying it with the Version= parameter.

rake db:migrate VERSION=20090113055719

To revert the database to it’s original state supply Version= paramter with 0.

rake db:migrate VERSION=0

If you run a migration whose version is higher than the version of the current database, the migration will be applied. Somewhat differently, if you run a migration whose version is lower than the version of the current database, Rails will look for the migration file whose number matches the database version and undo it.

I hope this tutorial has helped you to begin to understand ActiveRecord and how useful migrations can be. In the next article in this series we look at what makes up a migration in more detail.

Amy Hoy over at Slash7 has put together an amazing cheatsheet for RJS (ruby javascript) documents. It is 3 pages long and uses lots and lots of bright colors to illustrate clearly how rjs is interpretated.

She asks viewers to resist the urge of putting it on Digg yet, as her server is not ready to take another “Digging” quite yet.

View Amy’s post here

View the cheatsheet directly here

I would also like to mention a blog post I found today on Rails Forum which contains five tips to help beginners really get started with Ruby on Rails. Check it out here.

That’s it for now, but be sure to check back soon as there should be a tutorial on getting started with Adobe AIR up soon. I will then move onto more advanced topics and show you how to develop a basic twitter AIR app over the next few weeks. (or when mid-terms permit me to)