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.

Ruby hoedown

August 29th, 2007

mmmm I love conferences. Below is a link to some (or all?) presentations at Ruby Hoedown.

http://rubyhoedown2007.confreaks.com/

I just ran
script/generate migration add_type_to_users
in my terminal and it automatically generated a migration with the code generated for me.
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
I got the following migration:
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
For a bit more experimentation I tried:
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
Unfortunately it seems you cannot specify type. I also tried to see if you could do multiple columns by trying:
script/generate migration add_name_and_date_to_users
and got the following:
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
Is there a better way? I have found that this is also very picky. Your insert queries must follow up the line right after. It would was fun to create this, but not fun to look at :-/. Maybe there is a plugin somewhere?

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?

Anvil is growing rapidly and keeps getting cooler everyday! It now has support for MVC architecture (models are missing right now, but will be implemented soon) and it boasts a cool new way to shuffle away some of the code in your application view to other views like partials in rails. From the example I posted in the previous post, you can now do:

app/views/application.rb
1
2
3
anvil "Hammer" do |app|
  app.frame "Hamr", :render => 'hamr', :title => "Hamr", :maximize => true
end
app/views/frames/hamr_frame.rb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Create Menu Bar
frame.menu_bar "Main" do |menu_bar|
  menu_bar.menu "&File", :render => 'file'
  menu_bar.menu "&Edit", :render => 'edit'
  menu_bar.menu "&Search", :render => 'search'
  menu_bar.menu "&Help", :render => 'help'
end
    
frame.text_control "Editor", 
  :size => { :width => 100, :height => 200 }, 
  :style => [ :multiline, :rich, :rich2 ]

frame.create_status_bar(2)
frame.set_status_text("Hamr World!", 0)
app/views/menus/file_menu.rb
1
2
3
4
5
6
7
8
9
10
item.add(:new)
item.add(:open)
item.separator
item.add(:save)
item.separator
item.add(:preview)
item.add(:print)
item.separator
item.add(:close)
item.add(:quit)
This new way makes your code much neater. Support for putting all of the code into your application.rb file is still there, but having the ability to shuffle it away is very nice. Anyway, check out the projects: anvil.rubyforge.org and hamr.rubyforge.org.
Anvil just announced its conception onto rubyforge yesterday as plans are being set to organize how the new gem is going to be created. The gem is going to be a framework that wraps around the Wx::Ruby project in a way that is more concise and ruby-esk. The concepts are inspired by ruby on rails and Shoes (a project for allowing you to create little applications that act like web browsers). Here is a sample of the some of the code from the sample application called Hammer, a ruby/anvil-based text editor included in the applications folder of the repository:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
anvil "Hammer" do |app|
  app.frame "Hammer", "Hammer", :maximize => true do |frame|
    
    # Create Menu Bar
    frame.menu_bar do |menu_bar|
      
      # File Menu
      menu_bar.menu "&File" do |item|
        item.add(:new)
        item.add(:open)
        item.separator
        item.add(:save)
        item.separator
        item.add(:preview)
        item.add(:print)
        item.separator
        item.add(:close)
        item.add(:quit)
      end
      
      # Edit Menu
      menu_bar.menu "&Edit" do |item|
        item.add(:undo)
        item.add(:redo)
        item.separator
        item.add(:cut)
        item.add(:copy)
        item.add(:paste)
        item.add(:delete)
        item.separator
        item.add(:selectall)
        item.separator
        item.add(:preferences)
      end
      
      # Search Menu
      menu_bar.menu "&Search" do |item|
        item.add(:find)
        item.add(:replace)
      end
      
      # Help Menu
      menu_bar.menu "&Help" do |item|
        item.add(:about)
      end
    end
    
    frame.text_control :size => { :width => 100, :height => 200 }
    
    frame.create_status_bar(2)
    frame.set_status_text("Hammer World!", 0)
    
  end
  
end
The project is in need of talented and eager individuals to help it get off of its feet. If you are interested in contributing, check it out!
Going backwards with RSpec is a pain. By backwards I mean, write the specs after the specifications (my application) already exist. It feels like I'm re-writing all the code I just wrote. I can see the value in writing the specifications as we bring more team members on board and now my mindset is such that I feel like I'm writing documentation to support them as we introduce them to the code base. The real pain started to set in when I had this small problem. The problem I'm having is that rspec is returning an error every time it encounters a method in the view that takes advantage of the polymorphic helpers AND does not pass the appropriate instance variables. Rails by default will allow you to call these methods without passing arguments to it. Here is the error:
1
2
3
4
5
6
7
8

ActionView::TemplateError in 'Edit Artist Page should render the edit artist form'
label_artist_url failed to generate from {:action=>"show", :controller=>"artists"} - you may have ambiguous routes, or you may need to supply additional parameters for this route.  content_url has the following required parameters: ["labels", :label_id, "artists", :id] - are they all satisfied?
On line #3 of app/views/artists/edit.rhtml

    1: <h1>Editing artist</h1>
    2: 
    3: <% form_tag label_artist_path, :method => :put do %>
By providing label_artist_path with its arguments this error goes away:

label_artist_path(@label, @artist)
This to me however adds unnecessary noise to the already easy clutter erb syntax and I would much rather just use this method without having to pass its arguments. There is also another option: stub out the label_artist_path method. My problem with this is that I feel like I'm not really testing my views fully and it will be hard to maintain considering I use these methods everywhere in my views. I could write a module that would include these methods, but this tends to be a big no-no in the rspec philosophy as you are hiding away some of the specifications. I'm thinking the best solution is to patch whatever the problem is in rspec, but I'm not sure where to start. I had a long discussion about this with David Chelimsky about this topic on the rspec mailing list and continued on the irc channel. I even posted a bug report on it here. We were trying to pinpoint where in rails these instance variables get sent to the helpers. He made the suggestion of adding the following code into my before method:

(class << @controller; self; end).send :include, ActionView::Helpers::UrlHelper
Which gives a completely different error:
1
2
3
4
5
6
7
8
9

ActionView::TemplateError in 'Edit Artist Page should render the edit artist form'
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.url_for
On line #3 of app/views/artists/edit.rhtml

    1: <h1>Editing artist</h1>
    2: 
    3: <% form_tag label_artist_path, :method => :put do %>
For some reason the controller is not being set and that is basically where we left off. If anyone has any solutions, please comment! I will keep this post updated.
Finally the much anticipated (by those few lucky enough to have heard about it) Grasp Ruby on Rails blog has arrived! The goal of this blog is to be like every other good Ruby on Rails related blog: complain about some problem we encountered and then describe the steps we took to solve them. We're in the process of collecting anyone who is proficient in enough rails to contribute to this blog. If you are interested, comment!