Ruby on Rails
According to Mr. Rails himself, Amazon is getting in on the Rails fever.
UnSpun is a Rails application that relies heavily on the Amazon Mechanical Turk Web Services. It allows you to "see the community consensus on what's the best or the worst, the scariest or the funniest, the tastiest or the dumbest, UnSpun provides the right amount of structure to make that possible". Once a list is created, its sent to the Amazon Mechanical Turk which helps get the list populated with items, as well as the most relevant web links for the items.
Perhaps Amazon chose Rails because Ruby is the best programming language, or maybe because it's #5 on the Best Model View Controller Frameworks list, or maybe because its #194 on the Most Promising New Technologies list, or maybe because ActiveRecord is the Best ORM Layer?
Whatever the reason, it's interesting to see a company like Amazon embrace Rails. Maybe one of these days I'll get around to building something in Rails, brand it as Web 4.0 and rake in a cool billion?
When learning a new programming language or framework there is nothing more valuable that having someone there along side you to help show you "the way". You, of course, need to make sure that person themselves knows the way, but once that's been done a tremendous amount of learning can occur by just observing "the way". If you are doing Ruby on Rails development you should definitely checkout
The Rails Way.
Jamis Buck
and
Michael Koziarski, who are both on the Rails core team, have just started on a series of posts which focus on evaluating an existing Rails application, and pointing out how best to do things the "Rails Way".
While I still haven't come close to writing a "real" Rails application, I'm hopeful that one of these days I'll get around to building something.
tags:
rails
About 6 months ago I was on a pretty big Rails kick. I read lots of articles on Rails, got the Rails book, and installed all the bits necessary for running Rails on my PC and Mac. Since that time I’ve kept myself pretty busy with work related things as well as the obvious research into Linq, and ADO.NET Entities.
While my focus on Rails has gone by the wayside I’m still a big fan. Tonight as I was working in .NET land I fired up DHH’s RailsConf 2006 Keynote. As I was semi-listening to him I kept hearing a lot of the same themes that I read over and over again back when I was learning about Rails. DHH is all about opinionated software. Hist strong opinions are what makes Rails successful. DHH embraces constraints, keeps things simple, and does things his way…and he does so with amazing success.
One of the biggest mistakes that framework developers make is trying to satisfy everyone and everything. They get swayed by the users of their framework and end up compromising the simplicity of their framework for all the latest wizz-bang features that the community demands. Simply put they don’t have strong enough opinions on how things should be done. Rails has no such problems.
Is your software opinionated enough?
Coda Hale has a great post entitled Six Ground Rules for “Rails Sucks” Articles which was written in response to this lovely argument for why Rails sucks.
Although his six rules are targeted at “Rails Sucks” articles I think they can go for pretty much any technology. I can’t count how many times I’ve seen similar arguments for other technologies. Just because you don’t understand or fully grok something doesn’t mean it sucks. Until the System.Magic namespace is written by Microsoft don’t assume technology X is going to magically do everything you want and desire.
In my “Why all the hype over Ruby on Rails?” post I mentioned that one of my favorite features within Ruby on Rails is migrations. Since migrations seems to be one of the features within Rails that many of my .NET buddies don’t know about I figured I’d post about them to not only help expose people to what migrations are but also to help make sure I can explain them in a coherent way.
What’s a migration?
As we develop applications we continuously refactor our code and database to add new functionality as well as to clean up what is already in place. As we add features to our applications we modify the schema of the database that we use to house our data. I’ve used many different methods for managing this process with varying degrees of success.
When modifying a database schema developers often create SQL files that perform the necessary operations on their database. The SQL file is meant to take a previous version of a database up to a subsequent version. Since SQL files usually have keywords specific to a database platform they are not re-usable for other database platforms. If you support more then one database platform this can result in multiple SQL files for a single change. What ever happened to that DRY principle that the Pragmatic Programmers advocate?
One of the other problems that we face is the process is rolling out the changes we make to the other members of our team. At my old place of employment we used a DTS package to copy the current “checked-in” version of the database to each developers local machine. Although the process worked it wasn’t as smooth as one would hope.
Ruby on Rails migrations is meant to solve the problem of rolling out changes to your database. By defining the changes to your database schema in Ruby files development teams can ensure that all changes to the database are properly versioned. Additionally migrations help to ensure that rolling out changes to fellow developers as well as other servers (development, QA, production) is handled in a consistent and manageable fashion.
What are we migrating?
Before moving onto a definition of how migrations work I’d like to overview what types of changes we as developers make to our database.
- Adding a new table
- Removing a table
- Adding a column to an existing table
- Removing a column
- Renaming a column
- Renaming a table
- Adding an index
- Adding a primary key
- Adding a foreign key
Defining a change in Ruby
One of the nice things about Ruby is that it can feel very much like a domain specific language. By using ruby as a domain specific language we can define the changes we make to our database in a way that abstracts that change away from a single database platform. This allows the change to be applied to not only other databases but also to completely different database platforms. For example to create a new table using migrations you can create the following migration file:
class AddUserTable < ActiveRecord::Migration
def self.up
create_table :users do |table|
table.column :name, :string
table.column :login, :string
table.column :password, :string, :limit => 32
table.column :email, :string
end
end
def self.down
drop_table :users
end
end
As you can see the migration file above has two methods, up and down. Migrations not only support migrating a database from a previous version to the current version but it also supports rolling back database changes. So if I was currently on version 5 of our database and the above migration was to move to version 6 I could very easily roll back the version 6 change by saying “yo give me version 5 fool!”. When moving up a version the logic within the “up” method is called, and when rolling back to a previous version the “down” method is executed.
Migrations also support other changes such as:
class MakeAllKindsOfChanges < ActiveRecord::Migration
def self.up
add_column :users, :phone_number, :string, :limit => 20
remove_column :users, :email
change_column :users, :name, :limit => 10
drop_table :some_old_table
rename_column :users
rename_table :users, :myCoolUsersTable
end
def self.down
#undo all that stuff I just did above 
end
end
By utilizing migrations I can define every database change in an abstract fashion and then rely on the various connection adapters to convert my change into the SQL necessary for each database platform (MySQL, PostgreSQL, SQLite, SQL Server, and Oracle).
Applying a change
After I’ve defined all my changes in my migration files I can then update my database by using the “rake migrate” command. I can tell migrate to use a specific database and I can tell it what specific version I want my database migrated to by adding the VERSION option:
rake migrate VERSION=5
Summary
There is actually a lot more that could be said but this post is already longer then I wanted so let’s wrap up. Rails Migrations allow developers to define the changes to their database using a domain specific language that abstracts the change away from a single database platform. It tracks the changes using versions and allows for developers to migrate a database to any given version. Additionally migrations can be used to update both developers workstations as well as to apply changes to production databases.
Command reference:
dumps an existing database to a Rails schema file which allows you to port an application to different database platforms.
rake db_schema_import – imports the schema dumped using db_schema_dump
rake migrate – migrates a database to the current version
rake migrate VERSION={X} – migrates a database to a specific version
rake environment RAILS_ENV=production migrate – migrates the production database to the current version
rake schema_generator – products a .SQL file for each supported database platform (not everything is currently supported)
Over the last year I’ve become increasingly interested in Ruby on Rails. Although Rails has many technical reasons to peak my interests what interests me most is the passion that those using Rails have for it. Over the last couple weeks I’ve started experimenting with Rails. I have a small application that I’m planning on writing in Rails if I ever stop playing around. During my experimentation I’ve taken notice of the following things:
- The design of the domain model in Rails is right up my alley. The entity framework that I developed at my last company (as well as the one I wrote for my own projects/products) was based on the ActiveRecord pattern. Although the ActiveRecord pattern isn’t the purist approach I think it is very pragmatic. I like pragmatism.
- Rails validation is similar in concept to the attribute based validation I’ve implemented so again I’m a fan
- Built in support for AJAX is nice. Prototype and http://script.aculo.us/ (see demos) are very powerful javascript libraries that we could all benefit from learning and exploring.
- The focus on MVC for building Rails applications does a nice job of ensuring presentation logic is clearly seperated from business oriented logic. Nice.
- The implementation of views gives me bad flashbacks to my classic ASP days, yuck. Server controls in Rails would be sweet.
- Migrations in Rails is awesome. I’ve had a lot of frustrations with managing database migrations for applications and while migrations in Rails doesn’t solve them all it’s very nice to have something to use for managing this process.
- A lot of the common scenarios for domain objects have nice support. For example we have built in support for things such as tracking created on dates, treating a collection of objects as a list (or a tree), providing built-in support for tagging, and more.
I’m sure I could think of a lot more things that one could, or I should, dig within Rails, however that’s not really the point of this post. What has made Rails so successfull? Is it all these cool features? Is it cool editors like TextMate?
I think it’s the fact that Rails hasn’t tried to be everything to everybody. In desiging Rails David has embraced constraints. He didn’t set out to use every pattern in the book. He didn’t worry about trying to be a purist he focused on being pragmatic. Pragmatism is where it’s at.
A practical, matter-of-fact way of approaching or assessing situations or of solving problems.
Ruby on Rails has become very popular over the course of the last year. The popularity of Rails has meant very good things for TextMate which appears to be the text editor of choice for the members of the Rails core team. David (the guy who wrote Rails) recently posted on the release of version 1.5 of TextMate and encouraged those who haven’t yet converted to do so, even if it means picking up a Mac to run it on. As ridiculous as that sounds it looks like a lot of people have in fact decided to buy a Mac Mini so that they can do Rails on a Mac with TextMate. I don’t know about you but my favorite text editor isn’t quite worth the $500+ that is required to get a new Mac as well as a license for TextMate. Of course you could just get a Free Mac Mini instead.
PS: If your using TextMate checkout Jusitin’s Vibrant Ink theme.
Over my holiday break I've spent a little bit of time at the following sites. They provide a good baseline set of information for those interested in learning about Ruby.
I also came across a nice interactive site that lets you try Ruby from within your browser.
Try Ruby!
Thoughtworks just won an $800k Ruby on Rails bid. Maybe this Rails thing isn’t all hype after all?
I still need to find a little project to do some Ruby & Rails experimentation. If only there wasn’t so much Avalon (WPC) and Indigo (WCF) “stuff” to dig into I’d be in business.
As I mentioned in my previous post I’ve started reading up and playing with Ruby on Rails. One of the recent features which I stumbled upon is “migrations”. Migrations let you define the changes to your schema in ruby code rather then in SQL. This has the advantage of allowing the changes to be abstracted away from the actual SQL required for the change which allows for the changes to be scripted out for whatever database is currently in use. If one developer is using MySql and the other developer is using Postgres they can use the same migration files to get their databases in sync.
To read a little more about migrations check out the UnderstandingMigrations page on the Ruby on Rails wiki. While migrations in Rails are meant to be run directly against the database there is also a tool that Scott Laird created called the schema generator which uses the migrations files to create actual .sql files for various databases. The one negative of all the wonderful migration support in Rails as well as within the schema generator is that it doesn’t support all databases. Hopefully that will come in time. To get a flavor for what these migration files look like checkout the migrations for Typo.
As I was reading all the details of the migration support in Rails I started to think back to “my world” and some of the things that we’ve recently been trying to work through. The product we’re developing supports 3 databases. We’re trying to develop a process that allows us to have database changes defined in one place. We’re planning on then creating a tool that uses this data to generate scripts for each of the databases that we support (SQL Server, Oracle, Sybase). I actually downloaded Ruby + Rails to see if the migrations support in Rails could be used in our all .NET application. Well it turns out that migrations within Rails doesn’t support SQL Server or Sybase. The general idea still seems like a good one though.
Do you have a recommendation for a tool or process for managing schema changes? Does your tool or process handle defining the schame changes in a meta-language that can then be used to generate the specific SQL for various database providers? Does it handle column renames, indexes, new tables, versioning, and more?
If so let me know by leaving a comment!
Over the past couple months I’ve been drowning myself in all things WinFx. It all started when I took a new gig at a product company. We’re building a “next gen” product that if all goes well will launch in Q3 of next year. With that in mind we started looking at WinFX, more specifically Indigo, as a potential “foundation” to use in building our application. After discussing the possibility of using Indigo in our app we begun to create some prototypes. At this time I began working my way through “Programming Indigo”, as well as the slew of articles that started cropping up on MSDN. After a few weeks of reading up on most everything I could find Indigo related I felt pretty good about the basics of Indigo. I still have a long way to go before I fully “grok” the power of the layered channel model that Indigo provides but I’ve got the basics.
By this time it was PDC time. As news came pouring out of the blogosphere I tried to suck in as much as possible. I checked out the Indigo buzz and heard news of something new, Windows Workflow Foundation. At first I was pretty upset that I didn’t have a nice “code-name” for WWF but I got over it quickly as the channel 9 videos started showing yet another tool that would be a perfect fit for the some of the problems we’re trying to solve. It was time to transition from all things Indigo to all things WWF (seriously can we get a code name WWF isn’t doing it for me). I checked out the WWF articles on MSDN and ordered the Presenting Windows Workflow Foundation book from barnes and noble. A few days later the WWF book arrived which I started working my way through.
It was at about this time that I started to notice what a rut I was in. I had (and still do have) a couple side projects that I was trying to finish up. Each time I sat down to crank out the last bit of code necessary to finish the app I just looked at the screen with a wonderful blank stare. This went on for a couple days, which turned into a couple weeks. Just this past week I realized I needed a change. I needed something new, something fresh. Enter Ruby on Rails.
Over the last couple nights I’ve started working my way through Agile Web Development with Rails. The Rails community is quickly growing and based on what I’ve seen thus far it’s not surprising. Rails primary focus is on making the common scenarios that we face as developers easy. Rather then having to think about how to handle something we just look for the “Rails way”. Rather then thinking about how to lay out our project, how to map our model to our database, or how to setup all the necessary configuration we just start thinking about our application.
I’m certainly not leaving WinFx behind, just taking a brief break. When all is said and done I hope that I’ll learn some things through Rails that will help me in my platform of choice. It’s been a while since I learned a new programming language and I’m hoping doing so might help me get out of the funk I’ve been in.