Grasp Ruby on Rails

Microsoft has just announced full FastCGI support for it's websever software - Internet Information Services (IIS). Though primarily a PHP announcement (the FastCGI Extension was developed by Microsoft in partnership with Zend), it does offer Ruby developers a glimmer of hope for running Ruby on Rails on Windows servers.

"By supporting the open standard, Microsoft has made it possible for PHP and other CGI compliant languages to be hosted efficiently and effectively on Windows Server 2003 and IIS."

The important part here for Rails developers is in the middle of that statement - and other CGI compliant languages. We find from reading the Using FastCGI to Host PHP Applications on IIS 6.0 and IIS 5.1 guide on the same website under the "What is FastCGI?" heading that:

"The IIS FastCGI support enables IIS to host normal CGI programs like PHP, or Ruby On Rails, using the FastCGI protocol, offering high-performance and stability for production deployment of such application frameworks."

This new FastCGI Extension will be available for webhosts to use on older versions of IIS 6 and 5.1, so there will be no excuse anymore for Windows hosts not to support Ruby on Rails.

"This FastCGI Extension release is supported on IIS 6 on Windows Server 2003 for a fully scalable production environment and on IIS 5.1 on Windows XP in order to support developers who build their Web applications on Windows client machines."

At the end of the article lies the true gem:

"Looking ahead, betas of Windows Server 2008, already include the FastCGI Extension as a completely integrated feature of Internet Information Services IIS 7.0 (IIS7)."

This means the capability to run Ruby and Ruby on Rails (via the FastCGI extension) will be available on IIS out of the box, in all future versions. May Ruby on Rails developers around the world rejoice.

I thought I’d mention this briefly as rspec is becoming a very popular way to test. I was manually running my tests until I was recently pointed in the direction of auto-test with spec_server. This significantly increases the feedback loop for when your tests pass and fail; increasing productivity exponentially. The steps are as follows:

Install ZenTest:

sudo gem install ZenTest

Install rspec for rails:

http://rspec.rubyforge.org/documentation/rails/install.html

Open up a terminal and open run script/spec_server from the root of your rails application. Then open up another terminal and run autotest -rails (also inside of the root of the rails application). Edit a spec to make it fail, save it and watch autotest tell you it failed! I know you can get this to work with growl (I’m on Ubuntu so I don’t use growl). If someone with OS X experience can comment on how to get growl integrated and perhaps provide an alternative for linux, I will post it up.

script/generate migration add_type_to_users

1
2
3
4
5
6
7
8
9

class AddTypeToUsers < ActiveRecord::Migration
  def self.up
    add_column :users, :type, :type, :null => :no?, :default => :maybe?
  end

  def self.down
    remove_column :users, :type
  end
end

Am I being n00b, or is this a new feature in edge rails? Does this work for columns not reserved for rails?

UPDATE:

On further inspection, this is a new thing in edge rails and it does work for other columns. While running the following:

script/generate migration add_name_to_users

1
2
3
4
5
6
7
8
9

class AddNameToUsers < ActiveRecord::Migration
  def self.up
    add_column :users, :name, :type, :null => :no?, :default => :maybe?
  end

  def self.down
    remove_column :users, :name
  end
end

script/generate migration add_name_string_to_users

1
2
3
4
5
6
7
8
9

class AddNameStringToUsers < ActiveRecord::Migration
  def self.up
    add_column :users, :name_string, :type, :null => :no?, :default => :maybe?
  end

  def self.down
    remove_column :users, :name_string
  end
end

script/generate migration add_name_and_date_to_users

class AddNameAndDateToUsers < ActiveRecord::Migration
  def self.up
    add_column :users, :name_and_date, :type, :null => :no?, :default => :maybe?
  end

  def self.down
    remove_column :users, :name_and_date
  end
end

It seems that the implementation is pretty primitive. Obviously I'm using a bad approach as I should be looking at the source to see if any additional implementation does exist without my knowing, but I was hoping that the most intuitive thing for me would implemented already. I think it would be cool to see this syntactic sugar get more advanced. Comments? Opinions?

NOTE: The code that is generated by the migration does not work automatically. You have to change the stubbed symbols placed inside the migration to whatever you need. It's more of a guide than a performance enhancer (which IMO think that it should be both).

1
2
3
4
5
6
7
8
9
10

def self.up
  @first_query = true
  sql_file = File.dirname(__FILE__) + "/../some_crazy_file.sql"
    
  IO.readlines(sql_file).join.split(/;\nINSERT INTO /).each do |q|
    q = "INSERT INTO " + q unless @first_query
    execute q
    @first_query = false
  end
end

UPDATE: My friend Brandon, who chose not to comment on this blog post (shame on him!) said that running the sql file in command line could work as a more elegant solution there. The only problem I have with this approach is whether or not the rake task fails if the operation fails. So you code would like like this:

1
2
3

def self.up
  result = `mysql db_name < some_crazy_file.sql`
end

The only thing left is to make sure that result returns a favorable result, and if it doesn't then fail the migration. I'm not exactly sure how to do this (to busy to investigate). Any takers?