codevader

My copy of The Ruby Programming Language has finally arrived and of course that I started reading it. One of my first findings about the language semantics has to do with mathematics, more specifically, division and modulo.

As a long time Java programmer, most of my expectations about math in programming languages come from this background, so some of the behaviors of mathematical functions in Ruby have really scared me. Let’s start with a simple example, a basic division, imagine that you have -7 and you want to divide it in 3, as we can’t divide -7 by 3 we have to reach an approximation.

During my math classes, I learned that to do this approximation I would have to use a multiplication, multiply 3 until I have a value as close as possible to -7. The closest one I can get is with -2, as -2 multiplied by 3 is -6 and I would have a remainder of -1 as -1 plus -6 is -7.

A lot of numbers, right?

Open irb on a command line and write:

-7/3

So, are you getting -2? No?

No, you are not. In Ruby, -7/3 is -3.

How the hell does this happens?

In Ruby, differently from C/C++ and Java, the result of the division between two integers where one of them is a negative number will yield a result as if it was a floating point division that rounded towards negative infinity. There is no explanation about why it is done this way (comment if you have any hints) but other languages like Python and Tcl behave in the same way.

Ideally, A divided by B with a result of C and a remainder of D is equivalent to ((C * B) + D), so this simple division would break the whole mathematical equivalence between multiplication and division, right?

Not so fast. The modulo (%) operator also behaves differently when dealing with a negative division. If you try to run (-7 % 3) you will receive 2 and ( (-3 * 3) + 2 ) is exactly -7. So, the operators keep their values equivalent, they just don’t behave the way I was expecting them to.

Another interesting thing is that if you want a modulo operator that works just like Java’s, you can call the remainder method as in:

-7.remainder(3)

This isn’t going to blow your mind or change your life forever, but it’s an interesting behavior that I didn’t have noticed yet.

PS: If you have any idea about why this happens, just drop a comment

Recently we switched from Subversion to Git, and the thing I missed the most was the post-commit notifications we had popping up in Campfire. So, I added this to the .git/hooks/post-commit file in the project I’m working on:

#!/usr/local/bin/ruby


require 'rubygems'

require 'tinder'

commit_author  = `git show --pretty=format:"%an" HEAD | sed q`.chomp
commit_log     = `git show --pretty=format:"%s" HEAD  | sed q`.chomp
commit_date    = `git show --pretty=format:"%aD" HEAD | sed q`.chomp
commit_changed = `git-diff-tree -r --name-status HEAD`

campfire = Tinder::Campfire.new 'your_account'
campfire.login 'your_username', 'your_password'
room = campfire.find_room_by_name('your_room_name')
room.paste %(Commit by #{commit_author}nDescription: #{commit_log}nnChanged Files:n#{commit_changed})

room.leave

You’ll need to install the tinder and hpricot gems too. And post-commit must be executable

chmod 744 .git/hooks/post-commit

Now this will send a notification to Campfire each time you complete a local commit.

[Thanks to this pastie for the right git commands] 

Disclaimer: This post is first about my experience writing a plugin and then about the plugin itself. If you just want to learn about the plugin scroll down to the “using the plugin” part.

Well, after a while documenting, updating and polishing here is our first Rails plugin (in fact it’s an ActiveRecord plugin =D ). It isn’t something big or something that you couldn’t live without, but it was something helpful on our last project and it doesn’t hurt to give something back to the community after everything that they gave us.

A little history

My last task was building a social community (yeah, another one, but this one is somewhat different than the others in their target audience) which I can’t talk about right now (once they have launched I promise to comment about it here), but one of the features was a moderation queue. The client wanted that every create/update/deletion were held for moderation, in the beginning of the project it looked good enough, we didn’t have a lot of models and I could write a simple moderation queue for those two or so objects.But it’s never as easy as it seems :).

Not too long later the client sent a document asking for a lot of other models (like jumping from two to a dozen) and I couldn’t just write a different moderation queue for every model, so, time to look for a plugin (search first, build later). I couldn’t find anything that worked like I wanted and the closest one needed a “clone” table to keep the models under moderation, so I thought it was too much for something as simple as a moderation queue. Afterall, this is Ruby, not Java =P

So, I couldn’t find anything that did what I wanted (and the way that I wanted).

On the shoulders of giants

Coming from my Java/C# background I was really expecting something “hard” or maybe “challenging” (I wrote a JavaServer Faces component last year, so all my sins are paid until 2010). First, I spent some time reading the “acts_as_taggable_on_steroids” and “attachment_fu” plugins.

After some time reading them I was starting to form an idea about how an acts_as plugin should behave. When you are building an acts_as plugin you have to imagine what new behaviour you will add to your models, my idea was that instead of saving/destroying the object, I could send it to the moderation queue, so, every model that acted as moderated would have a method called to_moderation that would send it to the moderation queue without touching it’s original state, only the moderation object should be saved here, not the moderated model itself.

So, I wrote the Moderation model containing the information that I needed, my idea was to keep it as simple and flexible as possible, I needed to store a lot of different models and I didn’t wanted a separate “clone” table for all of them, so the moderations table would have to store the model.But how could I do it without saving the model?There is an interesting feature on ActiveRecord that many people don’t know about that is the “serializable” attributes. You can “serialize” a complex object into a text column storing it in a YAML representation, so, instead of creating a new table for every model, I would serialize the attributes hash of every ActiveRecord model into the text column. Multiple tables problem solved

Going on with the development I noticed that it was really hard to test the plugin using RSpec and the way that plugins are packaged has always bothered me. In Java we did our builds using Ant or (lately) Maven and when you’re using Maven you define the version of your dependencies, so that whenever you have to switch to another machine (yep, I know this is coming in Rails 2.1), it was just a matter of installing Maven and telling it to download the dependencies again.When you’re using a Rails plugin you usually can’t find out which version it is, specially if you’re running on someone else’s code, and this isn’t really good when you just happen to fall on legacy code that you have to deal with.

Fortunately, I saw the “Plugin Patterns” e-book from Andrew Stewart and gave it a spin. Even if you are not planning to write a Rails plugin, you should absolutely check this book, there are great insights about how Rails works and you will figure out that building a plugin is as easy as anything in Ruby, it’s just a matter of knowing where to place your code.And Andrew’s book gave me the idea that was missing, bundle the plugin as a gem!

So, I set out to use Hoe (another nice tool from the Seattle.rb guys) to build my gem. Testing with RSpec became easier and I didn’t need to make crazy black magic to run my specs, it was just a spec file, a helper and a migration, “rake specs” and be done with it. Now, as I had a gem ready to go, I wrote the gem docs and also bundled a simple example application to help people figure out their way when trying to use the plugin.It wasn’t really easy because it was my first time doing it, but now that I’ve learned the quirks and have found plenty of documentation the next time it will be just another plugin.

If you find that something in your app could be moved out from it, take some of your time to move it out, you might learn a lot about your coding style and how to create reusable code in a simple and easy way.

Using the plugin

Enough talking!

Lets see how you can use this plugin to build your own moderation queue. First you have to install the gem (our Rubyforge account hasn’t been enabled yet, so you will have to get the gem here). After installing it you can start to use it in your own rails project or take a look at the example application that is available at the gem directory.Once your app is ready, you have to unpack the gem at your vendor/plugins dir, do it using the following command:

gem unpack acts_as_moderated

This should create an “acts_as_moderated-0.5.0”. After this you have to generate the moderations object migration, just type:

ruby script/generate acts_as_moderated_migration

A migration for the Moderation model object will be created. You can run your migrations to create the table:

rake db:migrations

With the table created, time to use it in your models. Imagine that you have an Article model that you want to be moderated, here’s what you have to do:

class Article
		acts_as_moderated
end

I hope you haven’t typed too much

With this call, instances of the Article class will now have two new methods added: to_moderation and to_moderation!. Both of these methods will create a new moderation object containing the current state of the moderated model (in this case, the Article object). The only difference is that the one ending with an exclamation sign will throw an exception if the moderation could not be created.The to_moderation object receives an options hash where you can pass complementary attributes to the moderation object. The default to actions in moderations is “save”, so, if you want to place a destroy action on the moderation queue, you will have to add it to the to_moderation method call, like this:

@article.to_moderation :action => 'destroy'

When this moderation is applied it will remove the moderated object. The only actions accepted right now are ‘save’ and ‘destroy’.And here comes some real world action, that’s how your new controller actions would look:

def create
        @article = Article.new( params[:article] )
	if @article.valid?
		@article.to_moderation # sends this object to the moderation queue
 		# the object attributes are saved with the moderation object
        flash[:notice] = 'Your change was received and placed on our moderation queue'
		redirect_to articles_path
	else
		render :action => 'new'
	end
end

And then you can “moderate” a change calling the moderate method on a Moderation object (try to say this fast!):

def moderate
	@moderation = Moderation.find( params[:id] )
	@moderation.moderate! #moderates the change, adding/updating/removing the moderated model
       	flash[:notice] = 'The changes have been applied'
	redirect_to moderations_path
end

Imagine now that you wanted to know which user tried to peform this change, how could you do that?The to_moderation method receives an array of attributes as a param and those attributes are sent to the Moderation object, so you could just create a new migration adding a new field to the Moderation model:

add_column :moderations, :user_id, :integer

And send the parameter to the to_moderation object, just like this:

@article.to_moderation( :user_id => current_user.id )

To enable this on your app, just create a file called moderation.rb on your app/models folder and add the belongs_to declaration (classes in Ruby are always open, remember?):

class Moderation
		belongs_to :user
end

And you’re done, you have your own moderation queue working for anything and you can even add the user who performed the change. Take a look at the sample app and readme that comes bundled with the gem to learn more about how to code (and even view a “diff” of the moderation object).

I’ve just returned from the excellent Scotland on Rails conference, held in Edinburgh over 2 days.

There was a good line-up of talks and the ones I attended were all interesting in one way or another. Some were nice and practical, and others were more abstract and esoteric.

Day 1:

• Michael Koziarski talked about beautiful code, by giving examples of not so beautiful code that is in Rails source. For someone that has never looked much at Rails source code, this was pretty interesting, particularly the good explanation of how alias_method_chain is used. He also mentioned this rule-of-thumb, which is something I also subscribe to:
  • First make it work
  • Then make it beautiful
  • Know when to stop
• Richie McMahon and Maria Gutierrez talked about integrating Rails with an existing suite of Java applications. Their experience covered using web services integration, message queuing and even sharing the database directly.
• Andy Stewart gave practical coverage of all the options for background processing with Rails, before settling on BackgroundJob as his preferred choice.
• Jim Weirich & Joe O’Brien did a 3-act play explaining the benefits of mocks and stubs in your tests, in particular with FlexMock.
• Giles Bowkett gave a great talk on meta-programming, based on the underlying premise of code=data and data=code. What could have been a really dry presentation was spiced up with random insertions of Jessica Alba and Darth Vader. Hilarious!
• Bruce Williams then explained the new features coming in Ruby 1.9. I must admit that I didn’t pay full attention, since its likely to be a while before these changes filter through to Rails.
• Day 1 was wrapped up by Gordon Guthrie introducing Erlang and how it supports parallelism right from the insides.

Day 2:

• David Black opened with an allegory comparing music with programming. Although it was interesting, I must say that the analogy didn’t quite work for me.
• Jonathan Weiss gave a very straightforward talk on common Rails patterns, which you could see he’d had proper experience with. These covered handling long running tasks, dealing with large files, when to use plugins, handling dependencies, and avoiding denial-of-service attacks
• Paul Dix did an interesting talk on collective intelligence. His example showed giving movie recommendations. Some very clever maths in use here.
• Jim Weirich talked on “Advanced Ruby Class Design”. His target audience for this one was Java programmers, showing how to accomplish things in the Ruby Way. But the message was universal.
• Joe O’Brien explained domain-specific languages. Not really from a technical point of view, but more from a philosophical angle.
• And the last talk was Charles Oliver Nutter and Thomas Enebo on JRuby. As someone who’d never had a proper look at JRuby before, this presentation was really eye-opening. They gave a good intro to all the reasons why one should consider JRuby, and there are many. JRuby is definitely something we will be having a serious look at.

All in all a great conference. The organisers did a fantastic job, I learned a heck of a lot, and met some cool people. I really hope to come again next year.

PS. For slides of the various presentations have a look here, and click on the slides links.

If you have ever deployed a Rails app, you have probably used a mongrel cluster running behind a proxy server (usually Apache, Lighttpd or, not so probably, Nginx) while this isn’t something painfully difficult, it makes Rails applications harder to deploy when compared to PHP, where you just send your file to the server, or Java, where you bundle your app in a .war file and place it on the server’s deployment folder.

The biggest problem with the mongrel cluster approach is that you have to take care of at least two processes. Although it was possible to have only an Apache server to deploy your Rails applications (using FCGI) this wasn’t a good approach as it will hurt your application performance.

But now, we have a true option to run our Rails applications using just an Apache server, and the option is called (tadá!) mod_rails!

mod_rails (or Passenger) is an Apache module that aims to enable seamless deployment of your Rails applications using only an Apache server. No proxies, no (visible) clusters, no other processes to handle, just copy your rails application to folder defined at the Apache’s virtual host configuration and be done with it.

But how does it works?

What mod_rails does is automatically manage a cluster of rails applications inside your Apache server, so you will have all functionalities and performance advantages of running a mongrel cluster without having to manage one. And something that really makes mod_rails special is that your rails applications are independent from the Apache server, if your application blows, the main server won’t go down the tubes. If you want to have a full architectural overview of how it works, take a look at their “Passenger architecture document”.

And now, enough of talking, let’s get our hands dirty and prepare the environment to deploy a rails application to mod_rails. First, this tutorial is aimed at preparing an Ubuntu 7.10, but it should probably work if you’re running 7.04 or maybe even a 6.x, but I can’t guarantee that.

If you don’t have Ruby yet…

If you’re going to do this in a brand new (aka. virgin) server, you will have to install some things (like Ruby ) first, login to the machine and start typing:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get autoremove

This will update your system and take the garbage away. Then you go:

sudo apt-get install build-essential –y

This will install the software needed to build other things (like your native gems). After installing this, it’s time to install your database (in our case, it’s MySQL, but you can take another one, I promise I won’t feel bad about it) and Ruby, you can do this typing:

sudo apt-get install mysql-server mysql-client libmysqlclient15-dev libmysql-ruby1.8 ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby irb1.8 libdbd-mysql-perl libdbi-perl libmysql-ruby1.8 libmysqlclient15-dev libmysqlclient15off libnet-daemon-perl libopenssl-ruby libopenssl-ruby1.8 libplrpc-perl libreadline-ruby1.8 libruby1.8 mysql-client mysql-client-5.0 mysql-common mysql-server mysql-server-5.0 rdoc1.8 ri1.8 ruby1.8 ruby1.8-dev zlib1g-dev

It’s possible that the ruby installer hasn’t added the symlinks, so, if typing “ruby”doesn’t work, try this:

sudo ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby
sudo ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc
sudo ln -s /usr/bin/ri1.8 /usr/local/bin/ri
sudo ln -s /usr/bin/irb1.8 /usr/local/bin/irb

With ruby installed, it’s time to install RubyGems. You can install RubyGems from apt, but it’s better to download it and perform a manual installation. There you go:

wget http://rubyforge.org/frs/download.php/35283/rubygems-1.1.1.tgz
tar xvzf rubygems-1.1.1.tgz
cd rubygems-1.1.1
sudo ruby setup.rb

After installing it, you also have to add a symlink:

sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Alfter all this typing, you must be really tired, so now comes the easy part..

As you’re planning to perform a Rails deployment, you are probably using Capistrano (why wouldn’t you use it?), so I have some recipes to make you type less, a LOT less. First, install the Apache 2 server, Apache’s development headers, the Apache Common Runtime, and finally the Rails and Passenger gems:

desc 'Installs apache 2 and development headers to compile passenger'
task :install, :roles => :web do
    puts 'Preparing the environment'
    puts 'Installing apache 2'
    sudo 'apt-get install apache2 apache2.2-common apache2-mpm-prefork apache2-utils libexpat1 ssl-cert libapr1 libapr1-dev   libaprutil1 libmagic1 libpcre3 libpq5 openssl apache2-prefork-dev -y'
    puts 'Installing needed gems'
    sudo 'gem install fastthread rake rails passenger'
end

This task will install the Apache 2 server (even if you already have Apache 2 installed, you should run this task to be sure that you also have the development libraries installed) and the required gems. After this, you’re almost there, login again to your server and type:

passenger-install-apache2-module

You will answer some questions (and probably you won’t need to install anything, as we have already installed all software needed) and when the script is done take note of what he’s saying, which means copy the values to your /etc/apache2/httpd.conf file, it should look like this:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/ext/apache2/mod_passenger.so
RailsSpawnServer /usr/lib/ruby/gems/1.8/gems/passenger-1.0.1/bin/passenger-spawn-server
RailsRuby /usr/bin/ruby1.8
RailsMaxPoolSize 2

On the first line, we are telling Apache to load the passenger_module (this is mod_rails), the next ones are mod_rails configurations. RailsSpawnServer is the path to the executable that starts the Rails servers, RailsRuby is where your ruby executable is and RailsMaxPoolSize is how many application instances (just like the mongrel instances) you want mod_rails to start. Don’t leave the RailsMaxPoolSize blank, as it’s default value is 20 (yeah, TWENTY) and you probably don’t have enough memory for all 20 rails applications.

And we’re done!

Well, almost

Now that you have apache configured and mod_rails (Passenger) being loaded, we have to tell Apache about our application, we do this using a virtual host configuration, but we are not going to write it with our own hands, oh no, so there is another task to do this for us:

desc 'Creates a virtual server configuration on apache to your application'
task :create_server_config, :roles => :web do	template = File.read( File.dirname(__FILE__) + '/vhost_config.erb' )
    buffer = ERB.new(template).result(binding)
    puts 'Rendering template file'
    put buffer, "#{shared_path}/#{application}-vhost"
    puts 'Copying virtual server config to apache folder'
    sudo "cp #{shared_path}/#{application}-vhost /etc/apache2/sites-available/#{application}-vhost"
    puts 'Enabling the site on apache'
    sudo "a2ensite #{application}-vhost"
end

This task uses an .erb file called vhost_config.erb that should be on the same directory of the file where this task is defined, here’s the template:

<VirtualHost <%= domain %>:80>

    ServerName <%= server_name %>

    DocumentRoot <%= deploy_to + '/current/public' %>

    <Directory "<%= deploy_to + '/current/public' %>">

        Options FollowSymLinks

        AllowOverride None

        Order allow,deny

        Allow from all

     </Directory>

</VirtualHost>

It uses our own configuration (from deploy.rb) to define the virtual server. When we call this task, it will not only generate this virtual host config, but also copy it to the sites-available and then call “a2ensite application-vhost” installing the application on apache.

Then, you can just restart apache with the following task:

task :restart_apache do
    puts 'Restarting the apache server'
    sudo 'apache2ctl restart'
end

And you’re done, your Ubuntu server is running your rails application without any mongrels or anything else to manage besides Apache. Once your application is running, you can restart it with the following task:

desc 'Restarting the application'
task :restart_app do
    puts 'Restarting the application'
    run "touch #{deploy_to}/current/tmp/restart.txt"
end

Whenever you want to restart you app without restarting apache, it’s just a matter of touching the “/tmp/restart.txt” file (you have to create this file manually under your “/tmp” folder, it’s just a blank text file).

After all this, when once you have another application to deploy to the same Apache server, you will just generate a new virtual host file for it and it will be running without any other configuration or anything to manage. Could this be any better?

So, what about the good old mongrels?

mod_rails isn’t going to replace Mongel all over the world, because it’s a Rails only solution (although it probably can be tweaked to run other frameworks). What the guys at mod_rails are doing is integrating the a rails cluster inside Apache itself, without the need to run a separate server cluster, but as this is a necessity generated by Rails’ mono-threaded model, other frameworks, like Merb, will keep on using mongrel as their application server.

Another reason not to just look at mod_rails is when you already have a cluster of rails applications running on many computers and proxied by a common HTTP server, as you really need to distribute the load through many machines using one as a load balancer, it will not be so easy as I’m showing here, but even with a proxy, using apache at the application servers might help the performance of static content delivery.

Acknowledgements and references

Most of the installation instructions that you found here where taken from the following post by Vince Wadhwani (Thanks Vince!).

If you are not going to install mod_rails in an Ubuntu machine, checkout the mod_rails documentation.

Last week we had an interesting message at the RSpec users list, the most interesting part of it is the following:

“I also had to go into specs on a project I’m not working on, and found an unholy hive of database-accessing specs. It’s disheartening. Basically, it’s cargo cult development practices - using the “bestpractice” without actually understanding it.”

You might have read this before, “/specs|tests/ that access the database are evil”, but have you ever asked yourself why?

Behavior Driven Development is the next step after Test Driven Development and it borrows many best practices found in the later. The two principles that interest us most in this conversation is test-first development and unit testing.

The idea behind test-first development is that before writing your code, you should write a test stating what you want you “future” code to do. By writing the test before the code you get to work on the public interface provided by your object, the test is the first client of your code, so, if your public interface is cumbersome or difficult to use, this test will be able to catch a bad idea before it’s materialized in your code.

And where is unit testing in all this? You should be doing test-first using unit tests, as unit tests will guarantee that the code you wrote for that single unit (a method, probably) works alone. If you have more objects that need to be used to test this specific behavior, you should use mock objects (fake objects) in their places, so you won’t be testing them in your unit test. Remember, unit tests should only test a unit of code, no more than that. We should do it this way so we don’t get distracted with the other objects implementation, we focus in testing our target, not it’s dependencies.

When we’re writing specs for our objects they should usually work as unit tests, they should only assert the behaviors of a single unit of code, everything else should be done using mocks and stubs. But I said usually.

As I said before, unit tests and your common specs, should only assert the behaviors of a unit of code without considering their relationships with the other objects on the system, but this only guarantees that they work as units. This will never guarantee that they will really work when in real contact with the other objects in the system, unit testing don’t guarantee that your system works, they surely help you to reach this goal, but they aren’t enough.

And what it has to do with that message, anyway?

That spec that access the database is just like an integration test, it asserts that the code being tested works fine when integrated with the database. So, the integration tests are the ones that really show you that your code works as a system, not only as a group of lonely objects.

I’m not saying that you should leave the unit tests behind, because they have a big importance to help you design your code and be sure that it works as a unit, but you shouldn’t rely only in them to test your system, a good suite of integration tests will give you the trust that everything works fine in conjunction.

And sometimes you can’t unit test a functionality, it’s all about integration. Let’s take the “validates_uniqueness_of” validation in ActiveRecord as an example, if you’re writing a spec for your ActiveRecord model, you should add one ‘it’ statement showing that this is needed (you’re specifying how your model behaves, remember?), so here’s how it could look:

it 'Should not be valid if there is another one with the same name' do

           @common_name = 'testuser'

           @user = User.create( :name => @common_name )

           @another_user = User.new( :name => @common_name )

           @another_user.should have(1).error_on(:name)

end 

How could you perform this spec without touching the database?

First, you could look ad the “validates_uniqueness_of” source code, figure out how it works and stub it to return what you want, but this is bad because if the framework code changes your specs would break. The other way would be changing the database adapter to a mocked one and send exactly the result you wanted, but this is basically overkill. So why don’t you just leave the “purism” behind, test it in your database and be happy that your code works fine?

One important thing to notice is that integration tests are also slower to run, so you wouldn’t like to wait for the full suit run before performing a commit, usually you would run the unit and integration tests that are most likely to break if you did something wrong, the ones related to what you’re doing now and just be done with it.

So, if you’re in a project that has database accessing specs or specs that are using many real objects (and not mocks), don’t feel bad, but be sure that who wrote it knows that he is doing and that everything that can be unit tested is being unit tested. Integration tests should be written after your functionality is implemented and tested with unit tests, they are not interchangeable, nor you will replace one with the other.

And be sure to never commit your code before running your tests

Our third meeting tonight. On the menu is:

• Jeremy Thurgood talking about “Pain in Ruby: Things that bit me and their workarounds.”
• Peepcode screencast - RSpec user stories

We also have give-aways from Joyent and Peepcode.

Although Ruby and Rails have fairly comprehensive reference docs at http://www.ruby-doc.org/core/ and http://api.rubyonrails.com/ respectively, they can both be a pain to navigate when looking for a specific command (Ruby docs especially).

Enter gotAPI (http://www.gotapi.com). These guys have built a site containing a great auto-complete search facility, with both Ruby and Rails docs bundled together, so they get searched simultaneously. Really cool.

Also on their site (amongst many others) - Prototype, Javascript, CSS and HTML.

The site I am currently working on requires dynamic subdomains.

Details on doing this can be found on the rails wiki here and the pages linking from there. As well as on this awesome post by Greg Willits, whch is the post that got me off the ground. The crux of the matter is adding a wildcard declaration to your apache virtual hosts setup like so:

ServerAdmin yourdomain.com ServerAlias *.yourdomain.com

Unfortunately you cant do that if you are running a mongrel server on your local machine. So, instead, as Greg shows us, you need to define the subdomains explicitly in your /etc/hosts file (or in the case of mac - /private/etc/hosts).

127.0.0.1 www.yourdomain.dev
127.0.0.1 subdomain.yourdomain.dev

This is a solution, but I wanted to have dynamic subdomains in my development environment.

At this point I would like to mention that I don’t know if this is the best way to do this, and I dont fully comprehend the degree to which this can turn your life upside down - it seems to work without problems on my setup: Kubuntu 7.10 and Rails 2.0 and Ruby 1.8.6

So, finally, the dynamic hosts in development.

I created a module called HostsEdit in my lib folder:

 def update_hosts
   puts "updating hosts"
  if ENV['RAILS_ENV'] == "development"
   the_hosts = []
    file_location = File.exist?("/private/etc/hosts") ? "/private/etc/hosts" : "/etc/hosts"
    File.open(file_location, 'r') do |f1|
      File.open("#{file_location}.backup","w+"){|f|f.write(f1.read)} unless File.exist?("#{file_location}.backup")
      the_hosts =  f1.read.split("n")
    end
    User.find(:all).each do |u|
      the_hosts << "127.0.0.1t#{u.login}.yourdomain.dev"
    end
    the_hosts << "127.0.0.1twww.yourdomain.dev"
    File.open(file_location,"w+"){|f|f.write(the_hosts.uniq.join("n"))}
  end
  puts "done updating hosts"
 end

What the update_hosts action does, is to create a backup of your hosts file (unless there already is one) then reads in the current hosts, adds a new host for each user (using the login as subdomain) before writing the hosts back to the hosts file.

I included the module at the bottom of my environment.rb file

include HostsEdit
HostsEdit.update_hosts

so each time my mongrel server starts, it writes all the required subdomains to my hosts file.

Two little things that I forgot about initially: You have to run your webserver as sudo (mac and ubuntu) and lastly, if you add a new user during a session, you need to add the new subdomain to the hosts file.

class User < ActiveRecord::Base
...
  def after_save
    if ENV['RAILS_ENV'] == "development"
      HostsEdit.update_hosts
    end
  end
...
end

This isn’t a major breakthrough or anything to clever, but it achieves what I want - to not have to edit my hosts file manually everytime I want to use a new subdomain while testing the development of my site. Hope it helps. Let me know if it works, or if it causes problems that future users can be warned about

We’re having our second meeting this Wednesday. Find out more at www.capetownrb.org.

We have 3 speakers so far, with Merb and Rspec being the confirmed topics at this stage.