lindsaar.net - a different view

Rails Security Alert

2013-01-10T06:20:28+00:00

Rails has just had a rather nasty security alert, get your application upgraded now. If you know what you are doing, you can follow the instructions inside of the Security Alert notes, if you don’t, then you can get an fixed price upgrade service from reInteractive. But whatever you do, do it soon.

Encrypting Another Partition Using FileVault 2 on OSX Lion

2011-08-06T12:10:00+00:00

After installing a second drive with my home folder on it in my MacBook Pro, I noticed that FileVault 2 had only encrypted my main volume.

This was a problem, because most of the sensitive data is on the second volume, with my home folder. So it had to be fixed.

The solution is quite simple:

Log into (or create and log into) a secondary administrator account, I call mine “restore”
Make sure the second account has their home folder on the main internal OS drive (not out on the secondary drive where your home folder it)

Once logged in as the restore user, find the device name of the secondary drive using df, in my case it is /dev/disk0s2:



  $ df

  Filesystem    512-blocks      Used Available Capacity  Mounted on

  /dev/disk2     466560312 169368416 296679896    37%    /

  devfs                392       392         0   100%    /dev

  /dev/disk0s2   976101344 558685488 417415856    58%    /Volumes/data

  map -hosts             0         0         0   100%    /net

  map auto_home          0         0         0   100%    /home

Once logged in, run the following command from the shell:
```
sudo diskutil coreStorage convert /dev/disk0s2 -passphrase ‘password’
```
make sure you change ‘password’ to something you will never forget :)
The system will start encrypting your drive. Hopefully you have no open files on the secondary drive so that the system can dismount and mount your drive again and start encrypting.
Complete the steps below.

This works, however, there is a problem. With your home folder now on the second drive, it has to be unlocked BEFORE you can log in. As you need to log in to get access to your keychain, this presents a chicken and egg problem.

The solution is a great script created by Mr Ridgewell called unlock

Before you logout of the restore user (assuming you didn’t need to reboot to start the encryption process due to open files), run the following from the terminal:
```
$ bash <(curl -s https://raw.github.com/jridgewell/Unlock/master/install.sh)
```
This will prompt you with “Do you want to automatically unlock this drive at boot?” for each encrypted volume it detects other than the boot partition. If you say yes, you’ll need to enter the password for that drive.
Once this process is complete, restart your mac and boot up and log into your normal user account, you should be all good. Further, if you go into disk utility, you will see that the File System type has changed to “Mac OS Extended (Journaled, Encrypted)” for both your main internal and secondary volumes.

Obviously, this is only safe if your main boot partition is also protected via FileVault otherwise your unlock key for the secondary drive would be in plain text on the boot partition. However, I am assuming you have FileVault 2 turned on for the main boot partition.

blogLater

Mikel

Installing Home Folder on Second Drive on OSX Lion

2011-08-06T12:04:00+00:00

I have a 15" Macbook Pro, early 2010 model. It had a 500Gb Seagate 7200 RPM Momentus
drive in it, and had been serving me well over the past year but I wanted to give it
a speed boost, so I purchased a 240Gb SSD for the OS drive and new 500Gb Seagate Hybrid
drive with an OWC optical bay mounting kit for the data drive.

Installation was a bit of a pain as my user data was close to 250Gb alone, so it was
impossible to restore this completely to the OS drive.

To handle this I did the following:

Make sure you have a complete backup before you do this! I hope my instructions are correct, but this post has the standard MIT licence :)
Create a “restore” user with admin rights
Replace out the optical drive with the 500Gb Hybrid
Log in as the “restore” user
Format the new 500Gb drive as a single big partition calling it “data”
Make a /Users folder on the data drive
While logged in as the “restore” user, copy (just using Finder is fine) my home directory in the /Users folder from the internal drive and dump it into the data drive – this can take some time :)
Once the copy is complete open up System Preferences, accounts and right click on my user account and select “Advanced Options”, in there change the path to the home folder to the new folder on the data volume
Log out of the “restore” user and log in as your own user again, you should now have the home folder in the new location (the folder will have the home icon in finder)
Note, when logging back in as yourself, some applications might complain that they can’t find the old folder, Dropbox is one of these culprits as they use an absolute path, not a relative one. Just relink as needed.
Delete the old home folder in “/Users/yourloginname” (or move it to external storage for safe keeping if you are still in disbelief that everything worked)

Now we are ready to replace the internal OS drive. One thing I found though was that even after I deleted my home folder, the free space didn’t drop! It stayed stuck where it was. This made me think it was some sort of trash or recycle bin, but what I found is that there is a directory called /.MobileBackups on your drive that is like a mini portable time machine. So if you have time machine on, but you are not connected to it when it is time to backup, Lion will take a snapshot of your drive of changes. Neat, but in this case annoying.

So I had to do the following to replace the Internal drive:

Replace the internal OS drive with the new shiny SSD
Put the old internal drive into a USB enclosure
Connect USB enclosure to mac and restart into the recovery mode (Hold down Command-R until you see the apple logo)
Once in recovery mode, go into Disk Utility and note the name of your old Internal drive that is now connected via USB, it will be called something like “Macintosh HD” or some custom name if you have changed it.
Quit disk utility and go into the to terminal app.
Change to the folder where your USB drive is mounted, if your drive is called Macintosh HD then do: “cd /Volumes/Macintosh\ HD”
Check to see if the MobileBackups folder exists with “ls -al”
Forcibly delete the MobileBackups folder if it exists with “rm -rf .MobileBackups” – this can also take some time, in my case this folder had over 300gb in it
Once delete see how much space is left with “df -hi” It will show how many Gb have been used and what is available, make sure your old internal drive now has less used than is available on your new SSD drive.
Quit terminal and fire up Disk Utility
Click on your old internal drive connected via USB, and click the “Restore” tab. Then drag the new SSD drive from the sidebar into the Destination box. This will copy the contents of the old Internal drive onto your SSD drive.
Get this started (the confirmation box here is actually quite good and tells you what is going to happen clearly).
Come back in an hour or two.
Now that the SSD drive has everything your old internal drive had, the moment of truth has come, the reboot. Quit time machine, and then restart choosing your new SSD drive as the boot source, for added assurance, I disconnected my USB drive at this point.
Your mac should now restart on your new internal SSD drive a lot faster than before.

And that’s it!

blogLater

Mikel

undefined local variable or method `version_requirements'

2011-06-30T11:01:00+00:00

If you have a Rails 2.x app and hitting this, there is a simple fix while you wait to upgrade to Rails 3.

Edit your environment.rb file and inbetween the require ‘boot’ line and the Rails::Initializer line, insert the following Gem::VERSION if statement:

# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')

if Gem::VERSION >= "1.3.6"
  module Rails
    class GemDependency
      def requirement
        (super == Gem::Requirement.default) ? nil : super
      end
    end
  end
end

Rails::Initializer.run do |config|
# ....

It’s a hack, it might break with later and later releases of RubyGems. But it allowed me to get a 2.3.x Rails app running on a fairly current rubygems.

A New World of Resources

2011-05-23T22:04:00+00:00

Last year I attacked a long lost black sheep of the Rails family, ActionMailer. This was because I had a project that needed to use email and I found the current implementation, shall we say, somewhat lacking. This year, I’m turning my attention to really the only remaining black sheep left, ActiveResource.

ActiveResource needs to be upgraded to be a real citizen in the Rails 3 family, in fact, in the last few years there have only been very minor fixes to ActiveResource while the rest of the world moved forward.

So what do we have? Happily, working code.

ActiveResource, as it stands now, works for the simplest of cases. If you have a controller exposing a Rails REST based resource, and you point ActiveResource at it, you will be able to perform the basic CRUD operations you have come to know and love.

But if you want to go any further, you are on your own.

Associations with ActiveRecord objects don’t work, validations need attention, bulk updates and transactional support are missing entirely. The code is really as it was when it was first released.

With the world moving towards using rich clients that hit a back end API that abstracts the data layer, these things need to change. Having your front end client go to delete 100 records requiring 100 requests to complete is no fun, and a waste of time.

Sure you as a developer can dive in and create all these things. But that is the problem. With each developer rolling their own we end up with a mass of Rails apps that are all different, which increases the work load for all of us. ActiveResource must provide the same level of opinionated functionality as the rest of Rails. There needs to be a reasonable opinion on how to provide an API, a template that you can reasonably expect all Rails applications to follow.

The way I see it, there are two broad use cases for ActiveResource and the code that is exposed in the controllers. Firstly we have the “bolt on API”, this is the API that is simply added to existing controller code typically using respond_to and returning JSON or XML representations of objects.

The second type though is the pure API, these are the APIs that are built from the ground up only to talk to other systems, the API at rubygems.org is a good example of this. It is not a patch on existing functionality, but instead a core member of the entire application.

With the above in mind, I want to implement the following into ActiveResource:

Opinionated way to produce a “pure API” with Rails (think “rails generate api” for Rails applications that need to expose a separate, formal API for rich clients)
Support for bulk updates of objects to existing controllers (show_many, change_many, update_many and destroy_many) – see idea in David’s Gist
Transactional support for bulk operations
Support for multi type operations (for example, updating the post and the author at the same time) outlined in the Rails Conf talk by Yehuda Katz
Association support – providing connections through to local ORMs
Better validation handling and reliable ways to communicate error messages to client apps

The above is not an exhaustive list and I am interested in your comments. If you are interested in helping, send me an email or tweet to (@raasdnil)

I’ll be posting updates here and on my twitter feed as we move forward.

blogLater

Mikel

Rails Static Pages

2011-04-18T13:00:00+00:00

Static pages are one of those things that you have to get around to doing for every website. This is how we implemented them on StillAlive to make them maintainable and also cacheable.

On pretty much every website, you will have a bunch of pages that are just plain old static content. Good examples of these are Privacy Policies, Terms of Use, Contact Pages and the like. These generally contain content that rarely changes.

To make these simple static pages, we first add a catch all route at the bottom of config/routes.rb which looks like this:

  match ':page_name' => 'site/pages#show'

As this is a catchall route, you need to put this right at the bottom of your routes file. Basically it just catches anything that is not defined in the above routes and send it off to PagesController#show with the params[:page_name] set to the requested path.

So if the user navigates to http://stillalive.com/plans_and_pricing then the PagesController will have the show method called with plans_and_pricing set as the params[:page_name]

With the routing set, we then make a Pages controller that looks like this:

class PagesController < ApplicationController

  layout 'site'

  def show
    @page_name = params[:page_name].to_s.gsub(/\W/,'')
  end

end

Some key points here, firstly, we set the @page_name variable to be the value of the params[:page_name], call #to_s on this (which handles the case of params[:page_name] being nil) and then call #gsub on the string stripping out anything that is not a word character.

With that done, we then drop through to rendering pages/show.html.erb which looks like this:

<%= cache "site-page-#{@page_name}-#{App.git_revision}" do %>
  <%= render :partial => @page_name %>
<% end %>

So this just renders the partial with the page name requested.

So in the example above, we have a partial called pages/_plans_and_pricing.html.erb that gets rendered.

We also wrap it in a cache block. The cache block includes the page name, and also our git revision. We set the git revision so that every time we push new code to our server, all the prior cached pages get expired. This provides a no brainer way to make sure the latest code is showing on the site.

The App.git_revision call is using the App Config gem and is set by modifying config/app.rb to look like this:

class App < Configurable # :nodoc:
  # Settings in config/app/* take precedence over those specified here.
  config.name = Rails.application.class.parent.name

  config.git_revision = `git rev-parse HEAD 2>/dev/null`.to_s.strip
end

This sets the value git_revision on boot. Simple.

Now the above code is good, but what happens when someone requests a page that does not exist on our site, we’ll, we can’t handle this the simple way, as the MissingTemplate exception gets raised outside of our controller, inside the show view.

One solution would be to wrap the render :partial call in the show.html.erb template in a rescue block, rescue the ActionController::MissingTemplate exception and render a missing template instead, however, the problem with this is that the response code will still be 200 OK, where we really want it to return a 404 page not found status.

So we need a way to check to see if the partial is valid or not, before we render the show action. There is no simple way to do this, so the way we handle it is by creating a partial_exists? method in the controller which checks, like so:

class PagesController < ApplicationController

  layout 'site'

  def show
    @page_name = params[:page_name].to_s.gsub(/\W/,'')
    unless partial_exists?(@page_name)
      render 'missing', :status => 404
    end
  end

  private

  def partial_exists?(partial)
    ValidPartials.include?(partial)
  end

  def self.find_partials
    Dir.glob(Rails.root.join('app', 'views', 'site', 'pages', '_*.erb')).map do |file|
      file = Pathname.new(file).basename.to_s
      # Strip leading _ and then everything from the first . to the end of the name
      file.sub(/^_/, '').sub(/\..+$/, '')
    end
  end

  # Do this once on boot
  ValidPartials = Site::PagesController.find_partials

end

By using a constant at the bottom, we only run the Dir.glob once at boot time to reduce the overhead (instead of running it on every request). The find_partials method returns a list of partials that look like:

['about', 'plans_and_pricing', 'privacy_policy'...]

This way, every time we restart our server, we get a new list of partials in production mode, and every time we refresh in development mode, this list gets updated in any case.

Hope this helps :)

blogLater

Mikel

Twitter Replacing Rails? So?

2011-04-09T21:25:00+00:00

Twitter are reportedly moving away from Ruby on Rails. It’s on a lot of people’s tweets and on our Rails Oceania Mailing list. But the real question that should be asked is “So?”

Ruby on Rails is a tool for a job. I run a Ruby and Ruby on Rails consulting firm and we use Ruby and Rails to do one thing extremely well, that is rapid, highly customised, web application development. We can produce applications that fit very complex business models at break neck speed.

These same applications can then go on, with little or no modification mind, to serve more requests than ninety nine point lots of nines websites will ever need.

But one thing that Ruby is not suited to is highly concurrent, speed optimised computing. It’s not designed to. Ruby’s stated design goal by Matz (paraphrasing) is programmer happiness and help change the way us programmers think by providing a language that allows us to express our ideas and thoughts rapidly, elegantly and simply.

If you want something insanely fast, highly concurrent and optimised to the gills for speed, use something that is not Ruby, maybe Erlang, Scala, C, whatever.

If you need a web site developed that is on budget, has a really great development curve and delivers highly productive and successful web applications in the shortest possible times, use Rails.

I think the real surprise should not be “OMG, Twitter is moving their search feature away from Rails!” I think the point is “OMG, Rails has managed to run twitter’s search feature successfully for THIS LONG?!”

blogLater

Mikel

Engine Yard Cloud Backups Generating Zero Length Backups

2011-02-11T08:55:08+00:00

If your backups on EngineYard cloud are zero length, maybe it is a permissions problem.

We have a client that uses EngineYard cloud and has more than one application hitting the same database.

As part of this, he needs access, and it turns out that some of the views and tables were not owned by the deploy user.

This causes the eybackup to backup a file that is zero length and push it to the S3 backup but still return successfully. This is a problem because a cursory examination shows the backups are working all fine.

While EngineYard go about fixing this, the solution is simple, just make sure the owner of all the tables in the system belong to the deploy user, or alternatively make sure the deploy user can read all the tables in the database.

If you are using postgres you can do this with a simple SQL command:

psql> ALTER TABLE <table name> OWNER TO deploy;

MySQL has a similar simple command to handle this issue.

blogLater

Mikel

Our Rails Rumble Entry - StillAlive.com

2010-10-19T18:18:00+00:00

StillAlive.com is our RailsRumble entry, and I am quite happy with it!

StillAlive does app monitoring with a twist. Instead of just pinging your server, or checking for a string on a page, you can write cucumber like stories that interrogate your app and test that it is actually working.

For example, for TellThemWhen I have the following story:

When I go to http://tellthemwhen.com/
And I follow “Make a Time!”
Then I should see “Create Notification”
When I fill in “Time” with “Tomorrow”
And I fill in “Title” with “Test Notification”
And I fill in “Message” with “This is the message in the notification”
And I press “Create Notification”
Then I should see “Test Notification”
And I should see “This is the message in the notification”

StillAlive will then run that script every hour and email and SMS me if it fails….

And the awesome thing is, we did this in 48 hours… 4 guys… and we even slept some!

Ruby on Rails truly is an awesome development environment.

Please try it out and let me know what you think.

Mikel

Renaming a controller and redirection in Rails 3

2010-09-30T18:27:00+00:00

I had the situation where I wanted to rename a basic part of the TellThemWhen website, that is, changing the name of “instants” to “notifications”. As this was a major part of the whole website, I had to make sure existing URLs still resolved correctly, luckily in Rails 3, this couldn’t be simpler!

This was a fairly big issue, “Instants” were the name of the basic product of the site, that is, you could make an “instant” to share with other people. After a lot of varied feedback however, we decided that “notification” was a better name.

But all the URLs our clients have been distributing look like http://tellthemwhen.com/instants/a3s2… and people have been landing on our new instant page directly per our analytics data.

So I needed a solution which basically remapped /instants/ANYTHING to /notifications/ANYTHING. Happily, the Rails 3 router solves this.

First step is to make a redirector. This is a really simple rack app, I made mine like so and just put it at the top of my config/routes.rb file, it looks like this:

module TellThemWhen
  class InstantRedirector
    def self.call(env)
      destination  = "#{env['PATH_INFO']}".sub('instant', 'notification')
      destination << "?#{env['QUERY_STRING']}" unless env['QUERY_STRING'].empty?
      [301, {'Location' => destination}, ['Instants are now called notifications']] 
    end
  end
end

TellThemWhen::Application.routes.draw do
  # ...
end

This is a simple Rack application. It has a class method called “call” that the current environment as an attribute, then pulls the path data substituting the first occurrence of “instant” with “notification”, then adds all of the params data on the end, and sends back a 301 redirect to the client with this new URL

Then in the routes.rb I have:

TellThemWhen::Application.routes.draw do
  # ...
  # Catch old instant style URL and redirect to Notifications
  match '(/my)/instant(s)(/:id)' => TellThemWhen::InstantRedirector
end

Here I need to match both “/my/instant” and “/instant” as well as the plural form of instants, I also want to be sure I am only matching the URLs that have instant directly off the root, just in case in the future I have a URL that looks like “/notification/instant”.

Using the parentheses around (/my) and (s) and (/:id) make these optional to the match process.

This match statement simply calls the rack app, InstantRedirector which then runs the call class method, returning the redirection array sending the user back to the correct notifications path with a 301 permanent redirect.

Sweet.

blogLater

Mikel

Updating RailsPlugins.org to Rails 3 - Part 1

2010-09-24T00:11:00+00:00

RubyX are the maintainers for the RailsPlugins.org website with hosting kindly donated by EngineYard. As the site is all about compatibility with Rails 3, the irony was not lost on us that the site is running on Rails 2.3.5. I will do a series of posts which cover how we updated the site to Rails 3.

First off, RailsPlugins.org is a non trivial web application. It has OpenID authentication, API integration with RubyGems.org as well as a complex versioning, voting and commenting system that includes emails out to gem owners to encourage them to get their gems up to date with Rails 3.

The site currently hosts information for over 500 plugins and gems, tracking 1,500 versions with over 6,500 opinions from users and owners alike.

First off, it is good to work out a broad process on how you plan to upgrade a Rails 2.x app to Rails 3. At RubyX, this is one of our specialties, and so we have a documented path on how we go about it.

RubyX Rails 3 Upgrade Process from Rails 2.3.x

As I mentioned, RubyX have a codified path on how we update Rails 2.3 apps to Rails 3. If you are running a version of rails that is earlier than Rails 2.3, you really need to update to 2.3.x first before trying to go to Rails 3. It will save you a lot of pain.

Confirm all specs, tests and features are passing
Migrate the 2.3.x app over to using Bundler and a Gemfile
Remove all vendor’d gems and plugins that can be specified in the Gemfile
Audit any remaining vendor’d gems and plugins that have application specific modifications, and fork these changes into our own repositories and install them from here using the Gemfile
Review all gems and plugins in use by the app and ensure that Rails 3 versions are available.
For any remaining vendor’d gems and plugins that can not be Gemfile’d now but do have a Rails 3 version, leave them vendor’d for now and migrate to the gem version once we have updated t Rails 3.
For any gems that do not have a Rails 3 version, decide what to do. Contribute a Rails 3 version or replace.
Deploy this code to staging environment, for a sanity check.
Migrate the Rails app release by release up to Rails 2.3.9
Handle all deprecation warnings at each release
Migrate Gemfile and app to Rails 3
Update gem dependencies to ensure working with Rails 3
Do minimal modifications required to get all tests and specs passing
Review application code and take advantage of new Rails 3 idioms
Deploy to cloned production environment and test fully
Deploy to production environment with roll back plan
Test
Test
Test

Obviously the above gets run in a separate branch, it also gets done as rapidly as possible to avoid divergence with the production branch. There are several opportunities to merge back into production, at each update of Rails before 3.0 for example. However, this is not required.

A key point is step 6, making sure you have Rails 3 compatible versions of all gems you use in the app. This can obviously be done earlier, however, upgrading to Rails 2.3.9 is a good thing to do in any case and can be the first goal of your migration process.

You can use RailsPlugins.org to look up your gems and plugins to see what other users have found and authors have commented on in relation to Rails 3 compatibility.

So with the process codified. Lets get onto our first step, making sure the app has test coverage.

Confirm all specs, tests and features are passing

In doing this sort of upgrade you really can’t stress a good test suite enough. RailsPlugins has XXXX specs and XXXX features that exercise every part of the application, very thoroughly. So before we start changing code or files, lets run that suite:

$ rake spec
  .................... (...)
  Finished in 20.469918 seconds
  234 examples, 0 failures
$ rake cucumber
  .................... (...)
  126 scenarios (126 passed)
  1873 steps (1873 passed)
  1m7.546s

OK, it could be a lot faster, but we have the green light on all our specs and features. Time to migrate the app to use Bundler and a Gemfile.

Migrate the 2.3.x app to use Bundler and a Gemfile

Now that we have spec coverage for our changes, the next thing we need to do on a Rails 2.3 app is to create a config/preinitializer.rb file as well as update your config/boot.rb to boot using Bundler. This is well explained on the Bundler website. Just follow along there.

In the case of RailsPlugins.org, we were already used a Gemfile, of sorts. It was running a 0.9 release of bundler, and the Gemfile looked like this:

source :gemcutter

gem 'rails', '2.3.5'

gem 'mysql',                '2.8.1'
gem 'url_field',            '0.0.2'
gem 'ruby-openid'
gem 'hoptoad_notifier'
gem 'capistrano'
gem 'engineyard',           '1.1.3'
gem 'delayed_job',          '2.0.2'

group :plugins do
  gem 'authlogic-oid',       :require => 'authlogic_openid'
  gem 'authlogic',           '2.1.3'
  gem 'behavior',            '0.2.0'
  gem 'will_paginate',       '2.3.11'
  gem 'inherited_resources', '1.0.4'
end

group :test do
  gem 'highline',            '~> 1.5.2'
  gem 'machinist',           '>=1.0.3'
  gem 'cucumber',            '>=0.3.103'
  gem 'cucumber-rails',      '>=0.2.4'
  gem 'database_cleaner',    '>=0.4.3'
  gem 'webrat',              '>=0.6.0'
  gem 'rspec',               '>=1.3.0'
  gem 'rspec-rails',         '>=1.3.2'
  gem 'rspec',               '>=1.2.9'
  gem 'faker',               '~>0.3.1'
  gem 'nokogiri'
  gem 'ruby-debug'
  gem 'ZenTest'
end

The above Gemfile is not TOO bad, but there are some three glaring mistakes.

Firstly is the use of “>=” While this is limited to the test group, it is also just plain not a good idea as it means any equal to or higher version of the version specified. Using “~>” is much safer as it limits updates to point releases.

Secondly, is the use of the “:plugins” group. This group is there to make sure that Bundler will check the dependency requirements for this group when you bundle install, as all of these gems are in the plugins directory and without any mention in the Gemfile, Bundler would not be able to check for dependency conflicts.

Thirdly, several production gems requirements have no version attached. This is dangerous.

So, first thing to do is get version numbers on all of those gems. And the best way to do that is to log into the production environment and do a gem list.

Doing this found the following versions for the production gems we had no versions for:

  hoptoad_notifier (2.2.0)
  ruby-openid (2.1.2)

Additionally, we no longer use capistrano for deployment, instead relying on the nice EngineYard command line gem to handle this.

So we insert those version numbers, and delete capistrano and we get (without including the test group for now):

source :gemcutter

gem 'rails', '2.3.5'

gem 'mysql',                '2.8.1'
gem 'url_field',            '0.0.2'
gem 'ruby-openid',          '2.1.2'
gem 'hoptoad_notifier',     '~> 2.2.0'
gem 'engineyard',           '1.1.3'
gem 'delayed_job',          '2.0.2'

group :plugins do
  gem 'authlogic-oid',       :require => 'authlogic_openid'
  gem 'authlogic',           '2.1.3'
  gem 'behavior',            '0.2.0'
  gem 'will_paginate',       '2.3.11'
  gem 'inherited_resources', '1.0.4'
end

With this in place, we do a bundle install followed by running our test suite, to make sure that our changes don’t break anything.

With the specs and cukes green, we can commit the above work as the first step complete.

Remove all vendor’d gems and plugins that can be specified in the Gemfile

Next step is to get rid of that plugins group, and instead use gems or github sources directly.

Looking in the vendor/plugins directory of RailsPlugins.org, we see:

mikel@mikel.local ~/Code/railsplugins
 $ ls vendor/plugins/
   delayed_job
   formatted-dates
   high_voltage
   hubahuba
   open_id_authentication
   project_search
   timeline_fu
   url_field

Sharp eyes will note that we have some duplication between here and the Gemfile. Lets remove that.

Now doing this is time consuming. The steps are as follows:

Inspect the vendor/plugins/plugin directory and see if it has a gemspec.
If there is a gemspec, get the version and create an appropriate line in the Gemfile locked to that version
If no gemspec, search RailsPlugins.org, RubyGems.org or the appropriate plugin home page for the right gem version to use for a Rails 2.3 app and then put this in the Gemfile
If no gemspec and no gem released, skip and go to the next one.
Once the gemfile has the right version, remove the vendor/plugins directory entirely
Check the various environment.rb files (main, production, development, testing etc) and remove any config.gem line that relates to this gem. Use any information gleaned here to update the Gemfile line
Do a new bundle install
Run all specs or tests and cukes again and make sure you are still green
Handle any requirement errors or coding errors (if doing this has forced you onto a different incompatible gem version)
Once all specs and cukes are green, repeat with the next directory.

The above can take time.

In our case, we had a few situations.

a) We had a pluginized version of hubahuba, but in the entire app, this plugin was used ONCE. So instead, I removed the code we were using and made a lib/file that implemented the code we needed and just nuked the directory. Less code is good.

b) We were not using project_search any more. So this got the boot.

c) high_voltage is a gem, but that Gem only works on Rails 3. As I know that the Rails 3 version is available we will leave it vendor’d for now as there is no point doing anything else with it.

With all that done, our Gemfile looked like this:

source :rubygems

gem 'rails',                '2.3.5'

gem 'mysql',                '~> 2.8.1'
gem 'url_field',            '~> 0.0.2'
gem 'ruby-openid',          '~> 2.1.7'
gem 'rack-openid',          '~> 1.0.3'
gem 'hoptoad_notifier',     '~> 2.2.5'
gem 'engineyard'
gem 'will_paginate',        '~> 2.3.11'
gem 'delayed_job',          '~> 2.0.0'
gem 'authlogic',            '2.1.3'
gem 'behavior',             '~> 0.2.0'
gem 'inherited_resources',  '~> 1.0.4'
gem 'formatted-dates',      '~> 0.0.1'
gem 'timeline_fu',          '~> 0.3.0'

group :test do
  gem 'ZenTest'
  gem 'highline',           '~> 1.5.2'
  gem 'machinist',          '>=1.0.3'
  gem 'cucumber',           '>=0.3.103'
  gem 'cucumber-rails',     '>=0.2.4'
  gem 'database_cleaner',   '>=0.4.3'
  gem 'webrat',             '>=0.6.0'
  gem 'rspec',              '>=1.3.0'
  gem 'rspec-rails',        '>=1.3.2'
  gem 'faker',              '~>0.3.1'
  gem 'nokogiri'
  gem 'ruby-debug'
end

With only high_voltage left in vendor/plugins from the original bunch.

However, I needed to add in open_id_authentication and a fork of authlogic_openid to get OpenID working again. Looking through the various codes, it looks like authlogic has some issues with OpenID at the moment, so part of the Rails 3 update may be converting to Devise.

Note also how I changed the requirements to be “~>” instead of locked at a version. If you do this, run bundle update once and run all your specs again to make sure everything passes. Then commit your Gemfile.lock to your source control so the same version gets deployed on your production environment.

Deploy this code to staging environment, for a sanity check.

Next step is to deploy our new Gemfile based Rails app to a staging environment. On EngineYard this is painfully easy to do, simply snapshot your production environment, and then clone it to a new name (staging). Once done, boot up your app and do an ey deploy -e staging. For other hosts, I am sure you will know how to do this as well.

We ran into a problem in doing this. Our production RubyGems.org was still running on 1.8.6 and there was a gem requiring Ruby 1.8.7 as a minimum. So we updated our Ruby version to 1.8.7 and tried again. Due to this we now know that we will have to update our production environment to 1.8.7, so I scheduled a time to do this on the website, which gave me a good opportunity to use the new sites feature from tellthemwhen.com

This is what our command line deploy looks like:

 $ ey deploy -e staging
Beginning deploy for 'railsplugins' in 'staging' on server...
Successfully installed engineyard-serverside-1.3.3
1 gem installed
~> Deploying revision e94f047... Removing project_search, don't need that
~> Pushing code to all servers
~> Starting full deploy
~> Copying to /data/railsplugins/releases/20100923133736
~> Ensuring proper ownership
~> Gemfile detected, bundling gems
~> Symlinking configs
~> Migrating: cd /data/railsplugins/releases/20100923133736 && PATH=/data/railsplugins/releases/20100923133736/ey_bundler_binstubs:$PATH RAILS_ENV=production RACK_ENV=production MERB_ENV=production rake db:migrate --trace
~> Symlinking code
~> Restarting app servers
~> Cleaning up old releases
Deploy complete

Now the staging environment deployed and tested OK, it’s time to update the production site during the scheduled maintenance window and then move onto the next step, Migrate the Rails app release by release up to Rails 2.3.9.

For that, I will leave until the next post.

blogLater

Mikel Lindsaar

A new protocol for social interaction

2010-09-19T01:31:00+00:00

In my last post I discussed the bubbling up horrors of having our online identity controlled by faceless mega-corporations. But it didn’t really provide any useful direction. This is my attempt to fill that gap. Specifically, how should we go about sharing our thoughts and emotions online, without having to give up the ownership of our data to a centralised body? These are my thoughts.

I think there are four central tenants which any information sharing protocol should subscribe to.

These are;

Ownership of data should belong to those the data is of.
Authenticity of data should be ascribed by the owners of data.
Durability of data should be as long as the owners please.
Sharing of data should not circumvent the first three principles.

When a protocol for information sharing be developed that guarantees the above four rules, then we will have social networks without an ever present demon of profitability and balance sheets hovering over us.

But let me take a moment to explain what the above four rules would mean.

1. Ownership of Data

Your information is yours. This is where Diaspora are generally on target, despite any other failings. You should be able to post information to some location, somewhere in the world, and have complete control over that data. At no time should it be possible for someone (or something) else to claim rights to your data.

This flies in the face of the Facebook privacy agreement. Go read it if you haven’t yet. At least skim through it. The only place where they mention ownership of your data is the last paragraph of section 6, specifically that they reserve the right to sell your data to whom ever buys them.

Awesome.

Google’s privacy policy also has very little to say about ownership. In fact, it has nothing to say about how much of your data you own. Which means you have nothing to say about it using your data in whatever way it pleases.

The Apple’s iTunes privacy policy, that’s right, the one you click through every time there is an update to iTunes, also has a glaring, sun-flare type lack of information ownership.

The crazy thing is, we all don’t care. Or at least we have been conditioned to not care.

With the seemingly endless stream of platitudes coming from the mega-corporations murmuring that they will look after us, our information is safe, they will only use it to help us; it is no wonder that all of us don’t care. But go back and have a look at all of those “privacy policies”. None of them say they will look after your data. In fact ALL of them explicitly state that if they screw up and release all your data, that you waive them of any liability.

So Ownership of data is king. And the only way to ensure ownership is, well, have possession of it! There is a great old legal saying, harking back to the early 1700s that states “Possession is nine points of the law”. Over the centuries since this has become “Ownership is nine tenths of the law” and it is true!

So for you and me, the key would be for us is ownership data. Have control of our own micro information nodes that store, backup but most importantly, own our data.

Achieving this would be relatively simple, at least in the scale of the other three items in my proposal. We would all own a micro server which had our information crown jewels locked up some how. Each one of these little islands of personal information would then hand out tidbits of information to those that came, offering as much or as little as we wanted, while at the same time stamping each byte of data with it’s stamp of authenticity.

2. Authenticity of Data

The next key point would be the owner’s ability to say “Yes, this data about me is correct”. Maybe the second most important thing would be preventing any one else from saying “This bit of data about that person is authentic” without the owner agreeing.

Being able to authenticate that data belongs to you, grants you the ability to revoke that authentication, but why is this important?

I touched on it in my last post, the ability (and natural right) of a human to reinvent themselves, to start over, to become more than they ever were. Without the ability to say “That is what I did before, sure, but that is not me now. Now I am this.” then I am not quite sure what you or I are bothering to live for? As human beings we all have the intrinsic ability to start a new life, turn over a new leaf and spin up any number of clichés that allow us to change our demeanour.

But the current social networks don’t allow that. USA President Obama stated to a group of kids that they should be careful what you post on Facebook. And he couldn’t be more correct. Because once you post that, then Facebook are the ones who are stating that information is true about you. Not you.

Is it really fair to say that taking a video of someone being stupid at age 17, and then posting this on Youtube, should then define that person for the rest of their lives? No. Of course not. But you and I can see it. It is there. In video. So it MUST be TRUE!

Says who?

Have you seen a hollywood movie lately? Avatar anyone? Can you seriously tell me that if I took a clip from Avatar and decreased the resolution to Internet standards, that you would be able to prove to me that it was not live footage of an actual planet? No. Of course you couldn’t. And that is the point.

If we are to live in a sane and free world, then you and I should be able to stamp information about ourselves as true. And other information not. Then the viewer of that information could then (at their discretion) validate that data with your server, getting a confirmation.

Now before you go off at me about the possible legal consequences of people covering up their crimes by “deauthenticating data”. Remember people, we are talking about social networks. If the police want to collect a file about your actions and prove that it was you who robbed the bank, then fine, they can do that and the whole beyond reasonable doubt thing.

But remember in the old days, if you really screwed up your life, you could get up and move town and START AGAIN. This is the whole point. You should be able to revoke information and start over. Information about yourself should only exist for as long as you allow it to.

3. Durability of Data.

Go do a google search of your name. Don’t do it as an ego trip, just do it to be shocked (like I was). You will find information about you posting to mailing lists that have stopped sending mail almost a decade ago. You will find all sorts of information that you never thought would be there. And maybe you find something that you don’t want to be there.

This data exists as long as Google feels like persisting it. Not a minute more. And more importantly, not a minute less.

Sure, you MIGHT be able to get hold of them and delete information from caches and data stores. But they have no legal obligation to do as you ask. And even if they wanted to, what profit is there in doing so? None. Without keeping information about you and your actions, they have nothing to offer any customer, period. Their whole business model is defined by who did what when and allowing you to find out about it.

Now, don’t get me wrong. Google has a place. It provides an incredible research tool for our generation. When I was at school you actually had to go to the library and lookup encyclopaedia if you wanted to see information about a famous discovery. Now you can just google it. It is incredible and provides us with unparalleled expansion of knowledge.

However, research data, and what you had for lunch, are two very opposite ends of the information super highway. An information sharing protocol should allow the owner of data to decide when data is no long deemed necessary to be kept, and so allow it to be destroyed. Not made “anonymous”. Not “archived”. Simply nuked.

If you want to keep some information around for the future generations, print it out and store it in a air tight safe. If you want to start a new life, format your information node, and start a new one.

Or, if you are happy with your life and what you are doing, keep it online, and share it with your friends.

4. Sharing of Data.

The last point is probably the hardest to get right. Ownership can be handled by having your own private server. Authenticity could be resolved with todays public/private key authentication. Durability can be handled with a combination of ownership and invalidating the authenticity of data. But sharing, now that is tough.

Because the problem presents itself, whom do you share data with? And why?

Does Facebook really need to know how old you are? I mean, sure, they need to know you are of legal age to prostitute your personal life to the Facebook gods, but do they need to know that in March I will be celebrating yet another year of being on the far wrong side of 30? No. Don’t think so.

What about iTunes? Asking your date of birth “For security reasons”… O.o

Right.

Being able to share your data would take concepts like OAuth to their logical conclusion. Instead of allowing Google et al to be our authentication “proxy”, we would delegate this to our information nodes, each allowing anyone to say “Hey Joe, this character is claiming to be you, is he?” and get a definitive “yes” or “no”.

The same information node could provide things like “Yes, my owner is over 18” or “You want his postal address? One sec, I’ll check.”

There is little to no need for Facebook, iTunes or many other companies to know where I personally live. They already have my credit card data, what more do they need? They might need my postal address to send me an invoice, sure. But anything else? Nope.

Providing a smart way to share data would provide us with the opportunity to be so granular with our information sharing that the existing corporate efforts would just be a proverbial bull in a china shop.

And it would scare the life out of them.

Imagine if you will, Facebook trying to drum up more business when it could not sell targeted ads, down to a suburb, for goods and services? Imagine google only being able to shoot gun advertise? Imagine the empowerment we would gain as a human collective, together, breaking free of the psycho targeted marketing campaigns that assault us daily?

Nice thoughts aren’t they?

So being able to share data in a controlled and defined manner is just as important as the other three combined.

Summary

So these are my thoughts and my views of a future social information sharing protocol. What do you think?

I hope I have delineated them sufficiently.

If you feel strongly about it, please spread the word. This sort of discussion needs more voices than mine. I intend to work on such a protocol, I have no idea how or where such work will take me, but I really think that personal information needs to be under the above four tenets; Ownership, Authentication, Durability and Sharing.

Simple really.

blogLater

Mikel Lindsaar

What is a distributed social network?

2010-09-17T02:16:52+00:00

I’ve been reflecting on the future of the “social networks” and contemplating on how modern solutions have gotten it wrong. These are my musings.

Corporatization of our social interactions will become the swan song of our current society. It’s not a matter of if some big centralised body is going to screw you over with regards to the information you hold with them, but just a matter of when.

The problem is that we live in an age where the balance sheet is king. I’m by no means the first person to illuminate this well known fact, many have come before me. But it is true that unless we as a society act, and fast, then there will be no privacy, no where to run and definitely no where to hide.

Harking back just a short 6 years ago, before Facebook decided to open its online doors to the world, you and I could still share photos with each other, we could send an email asking one another out to dinner, and, we could even stoop as low as calling someone on the phone, or, heavens forbid, drop in unannounced on a friend “just to say hi”.

But now the world has changed. I talk to friends who tell me that not being active on Facebook is social suicide, that not tweeting your innermost thoughts relegates you to the digital backwater and that refusing to post your most intimate family pics on Flickr means you must be a pervert. But really, where is our world going?

In the last year I have seen Google buzz fizz and while it is too early to call, Ping is probably just another bad smell floating around. While Facebook continues to grow and generate profits and revenue at the expense of your privacy. Why is that?

Why is it that we spend our lives trying to amass “friends” in our social network, yet, look around our room, alone, and wonder where they all are?

Daily we are bombarded with tweets and photos of all the “cool kids” doing this, or commenting on that, and wonder why we can’t be like them. We yearn for someone to retweet a post or follow our thoughts. We are conditioned to gaze in wonder at someone’s friend or follower count and wonder how it is.

And then we wonder where is the social interaction in all this?

Who own’s your information on Facebook?

Who own’s the information you post on Twitter?

Who own’s the comment you may be compelled to leave at the bottom of this post?

And in the end, who cares?

It’s an interesting question. Who does care? Or more importantly, should you?

It can be argued that you willingly put information online, therefore you are willing for other people to use that information. To a degree, this is true. I post on this blog, you can learn an awful lot about me from this blog. But there is a difference. I can decide that this blog no longer represents who I am, or who I want to be, and thus change or remove it all together.

Sure, there would be ghosts of the content hanging around the internet in caches and my tweets online, but after a few months or a year or so, the Google juice would run out and in the end, become irrelevant. Why? Because this blog is controlled by no one other than myself.

Not by Mark. Not by Larry or Sergey. Not by Biz or Evan. Not even by Steve or Bill. This blog is mine and I’ll do what I like with it thank you very much.

And that is a key point. Unlike other social mediums out there, I can choose to exercise my right as an individual human being and redefine whom I am.

Start afresh and step out into the world yelling “G’Day!”

However, your digital finger print is actually doing to you what many corporate bodies and government institutions have been trying to do to you throughout the ages, categorise and segregate you into an powerless individual defined by your past actions and held back from the future.

It could be said that an individuals sanity can be measured by how far into the future they can base their decisions on. An insane person would be someone who could only think about the past and what has happened to them, a relatively sane person could look around in the present and make some rational decisions about their actions and how they would impact on the now. A very sane person can look into the future and see how their actions will impact all of society.

Our current online social systems are turning us into past living neurotics. We are worried about what is online about what we did. We want to make sure the historical record of who we are accurately depicts what we are. In short, we are getting trapped by the very social framework that was meant to free us.

Fine.

But what is the solution?

Not sure.

I have taken a look at Diaspora. Diaspora was born through four self proclaimed geeks who thought “information should be distributed and private”. Nobel goals (pun intended). But in looking at the “open source” code released, there was a really major flaw. There was a licensing model, and even a contributors agreement that one had to digitally sign in order to be part of the movement.

Excuse me?

Not only that, but looking through the posts, there is one major Achilles heel. One, gigantic, insurmountable flaw in their structure. The business model.

You see, that’s the point.

We can’t have our social networks dictated by a business model.

As soon as you dictate a business model, then any humanity is lost to the balance sheet. Any right to privacy is balanced against the profitability of maintaining that privacy. And in that battle, we all know what wins.

It is not a matter of Mark and the gang being “good” or “evil”. It is not a matter of them developing a bullet proof privacy policy or 101 ways to click your way to not sharing anything. It is the matter of, we are a race of individuals who gain their strength and meaning from our social interactions, and unless we are willing to stand up for those interactions, someone, somewhere is going to put a dollar figure on those interactions and suddenly they become as hollow as the “cha-ching” of a cash register.

It matters that you have friends.

It matters that you have someone to talk to.

And, damn it, it matters that the mega companies of the world don’t profit off the fact that I call you my friend.

blogLater

Mikel

Bundler and Public Git Sources

2010-09-16T17:58:00+00:00

If you have a public git source in your production Gemfile, then you are doing it wrong.

Bundler rocks. It lets us point our Gemfile source at almost anything, a path, a git source and of course RubyGems.org.

But if you are using production code, and you have something like this in it:

gem "mail", :git => 'git://github.com/mikel/mail.git'

Then you are most likely doing it wrong.

Why? Well, you have no guarantee that I will keep that repository around. I (or any github user) could just deleted it tomorrow. And then your deploy is broken.

Not only that, the reason you are pointing to a git source is because there is some production critical feature that you need from the git source. Otherwise, you would just be specifying the gem version in your Gemfile.

So this is a recipe for disaster.

I recently took over a project (Rails 2.2.2) that had over 13 gems specified in the environment.rb file using the Rails 2.x style config.gem commands that were pointing to explicit gems inside of Github. My first action was to go in and Fork those gems into the client’s public git repository and depend on THOSE versions, ones that are under our control.

Of course, the next step is to go through and remove any git dependency from the Gemfile, one by one and just revert to normal gems from somewhere like RubyGems. But this has to be done incrementally and will happen over the coming weeks.

So, go through your production code, and if you are pointing at someone else’s github tree, just go in and fork it and point at your own. It is cheap insurance.

blogLater

Mikel

Getting Heroku, memcached and Rails 3 working

2010-09-13T02:41:29+00:00

The docs for Heroku and memecached do not cover Rails 3. So here is the short version:

In your Gemfile:

group :production do
  gem "memcache-client"
  gem 'memcached-northscale', :require => 'memcached'
end

In your environment.rb:

config.cache_store = :mem_cache_store, Memcached::Rails.new

Told you it was short.

Oh, and remember to install the memcached add on to your app:

heroku addons:add memcache:5mb

Told you it was short.

blogLater

Mikel

Why Bundler?

2010-09-10T03:22:37+00:00

I have moved all of my Rails applications, and every client application I am consulting for over to Bundler and using Gemfiles, and you should too.

All of my Rails 3 AND Rails 2.x applications are now running on Bundler. Even a Rails 2.1 app that we are in the process of upgrading is running on Bundler, or at least using bundler for dependency management and configuration.

Bundler is NOT some “Rails 3 thing” and if you have this misconception, it is time you wrapped that up into a small scruntchy ball and tossed it into the circular file.

But some people try to install Bundler and report back to me “It’s too hard” or “It doesn’t work” and “It broke my app”. Of course, in many cases, you have to configure your code correctly, but the GemBundler site is full of information to do that.

But once your application or ruby code is configured to use Bundler, the crazy thing is that about 9 times out of 10, any further problems is because Bundler has found a problem with your gem dependencies that you didn’t even know you had.

I have had many many people talk to me about Bundler, in good and bad ways, and usually, any negative comments come from a lack of understanding on why bundler, and why it is needed.

Luckily, Yehuda was recently at EuRuKo in Karkow, and did this talk on Why Bundler? If you haven’t watched it yet, it is very well worth your time to sit through. Many things will become clear.

Oh, and a parting tip, if you are trying to get Rails 2.1 running with bundler, just configure bundler as if it was not a Rails Framework app. Treat it like the Sinatra app examples on the Gembundler website.

blogLater

Mikel

Rails Commit Access

2010-09-10T02:58:41+00:00

Hi all, I’m really happy to announce that I am the first Australian to have been invited into the commit team for Ruby on Rails!

About 48 hours ago, I was pleasantly surprised to read in the Rails Core campfire chat that David, Jeremy and Yehuda all decided that I should be put into the Rails commit team.

While this does not mean I am part of the “Core Team” yet, it does mean I can help move Rails forward at a rapid rate, and also means Australia now has a local who has commit access to the Rails Organisation repositories

Mostly, this was due to my work with the Action Mailer 3 updates with Mail, but I plan to extend this to other areas like Active Resource.

I am honoured to be given this access and hope to carry the torch for all Rubyists, especially those in Australia, for a long time!

So you will be seeing me a lot more in the commit logs from me and I’ll definitely be helping out on Rails in between my consulting work as the founder of RubyX

blogLater

Mikel Lindsaar

Introducing TellThemWhen

2010-09-09T15:44:00+00:00

I have had a scratch I have wanted to itch for a long time, and that is about how to share times online. TellThemWhen is my solution to this problem.

The problem TellThemWhen is trying to solve is one of “How do I tell Bob over in another time zone, what time I want them to do something”. Now, in many cases, Bob might be a person you deal with all the time, and you know he is 9 hours behind you, tomorrow, so all you have to do is the mental arithmetic once. Simple (yeah, right).

But what about when you have a Maintenance window coming up? What do you tell all your customers? Probably, like many sites out there, you go: “Hi there, we will be doing maintenance at 1am EST for 15 minutes”, but what is EST? If you are in Australia, it means time on the East Coast, if you are in the USA, it means something totally different.

Some sites solve this by linking to the world clock. Which is all well and good, but, honestly, a bit rude. Why are you making me hunt around a massive page of time zones to find the one I am closest to?

So what was needed was a simple way for anyone to make an instant in time, and then share that with the world. TellThemWhen does this.

The above maintenance window could include a link to TellThemWhen for the downtime, and now your users, in whatever time zone they are in, will get the time, for them, in their timezone.

Neat.

Over the weeks I’ll be blogging about some of the technology behind TellThemWhen. Handling multiple timezones is sometimes a challenge and TellThemWhen handles it in some interesting ways. Checking on up to three different sources for the timezone data, and then also verifying with your local computer that what we guessed is correct.

So anyway, check it out. It was fun making it with my designer, David Cruikshank (@thedav3 on twitter) and stay tuned for more features to come!

blogLater

Mikel

rake RSpec & Cucumber uninitialized constant Rails::Boot::Bundler

2010-08-29T23:27:06+00:00

You might run into this problem if you are bringing a Rails 2.3 app onto Bundler, specifically, when you try and run “rake cucumber” or just “rake” for RSpec you get an error about uninitialized constant Rails::Boot::Bundler.

The situation is most likely that (like me) you put the preinitializer.rb file into the config/initializers directory instead of just in the config/ directory.

So double check the location as per the bundler guide

blogLater

Mikel

This Relationship is Worth Nothing

2010-06-13T10:50:10+00:00

Today was the last day I had booked in my hotel room. I had won this room through an Internet bidding service at a heavy discount of $85 per night. However, I needed to extend my stay in the hotel another two days and that is where this relationship went to hell.

I called the front desk of this hotel and asked “I’d like to extend my stay another couple of nights, how much would that be?”

“Well, we can not give you the same rate you are on now, so it will be $200 a night to extend”.

“K, thanks, bye”.

So, what did I do? Tried Priceline again, and what should happen? We win another bid for two nights for $85 AT THE SAME HOTEL.

Calling the front desk resulted in “Oh, ok, come down to reception and change your key then, all good”…

O.o

So what is the difference between me calling up to extend, and me calling up with a winning bid?

Nothing, except one teeny tiny thing… I am an existing customer. I have already chosen this hotel (sure based on price, but I am here none the less) and so, they have an opportunity to create a strong relationship.

Which they shot in the foot.

This attitude just pushes the idea that my custom, is worth nothing, zero, squat and that my relationship with the hotel is worth nothing.

What did it gain the hotel? Well, the only thing it gained them is that now I know that I can “cheat” their “system” which just means contempt.

If the hotel was booked out, extending my stay at a low rate would not be good business sense. Sure. But it wasn’t. The hotel is half empty, and they are still offering the same price I paid through the internet.

Your existing customers are your most valuable resource. That is not to say you can’t entice new customers with “special offers”, that is fine, but remember that it is your existing customers who are paying your bills and feeding your cat.

This hotel in San Francisco would have won my stay for several more nights, but now I know that I can get a similar or cheaper price on the internet, which means my custom at this hotel is purely up to the gods.

And that is not good business sense.

blogLater

Mikel

Thank YOU...

2010-06-11T14:50:46+00:00

In his recent keynote to RailsConf 2010, Gary Vaynerchuk gave a wonderful talk about the power of “thank you”. Something we all intrinsically understand, yet not enough of us practice.

“Say Thank You” was drummed into me from a very early age, my parents always encouraged me to respect those around me, from the lowest socialite I met to the highest janitor I had the pleasure of talking shop with, I always learnt that the opportunity to create a relationship with those around me was something to be cherished and grasped tightly.

After Gary’s Keynote, he asked for questions, I posed the question of what his experience was with big corporates trying to “manage” customer complaints instead of treating them as the true gift of solid gold that they are. Gary mentioned that he has not seen much change, and this makes me sad, but reaffirmed what I already knew from my own experiences.

But some might be wondering what I am referring to. Surely customer complaints are something that should be managed; less complaints equates to better customer service – surely?!

No.

If you are running a business of more than one or two people, and you are not receiving any complaints, I would argue that you are doing something terribly, terribly wrong.

But you might need to broaden your idea of what a complaint is.

A complaint does not have to generate from bad service. A complaint per the dictionary is “a statement that a situation is unsatisfactory or unacceptable”. But there lies the rub. A complaint is a statement, and a statement by definition is something voiced. Your client has to gather the courage to contact you, go to the effort to find an avenue, and say or type “hey, what you just did wasn’t what I was expecting, and that’s not cool”.

“What?” you say. “Courage? Effort? I told my web design team to make sure there is a ‘contact us’ menu item in the footer of every web page on our site”.

Yeah, awesome. You mean that 10pt link right next to the “Terms of Service” which unsimply says “We legally don’t give a shit?”, that rocks, awesome positioning.

How many times have you called a company to complain and been turned away? How many times have you sent an email and been told “The system says… and I can’t change it”? How many times have you picked up the phone to complain, stopped mid dial and just hung up again in the knowing frustration that your voice is going to be cheerily greeted by some autonomous string of 1’s and 0’s for 10 minutes before you get told that the customer service desk is closed and that you can’t leave a message, doofus.

Well, your client is the same. If you don’t make it insanely simple for them to contact you, if you don’t encourage that call; 9 times out of 10, they just won’t do it. Then you my friend have lost an awesome opportunity. Because that single call could make or break your organisation.

Let me give you a personal example. I purchased a service from a domain name hosting company. This company claimed that their system would provide a “comprehensive” tool to edit and update domain names. It cost $12 for the year. I decided to purchase it as an option for one of my domain names. On getting this service, I found that it did nothing like what I expected, it was a simple interface with minimal functionality. After 5 minutes of purchasing the service, I decided that it wasn’t what I needed and immediately sent a very polite email off to their support staff asking to please cancel and refund the $12.

Simple request. I mentioned politely that the advertising had promised an advanced service, and pointed out the features it did not support. I felt very justified in my complaint and believed that shortly there after I would receive an email saying “very sorry sir, we have refunded your card, thank you very much for your custom and we trust we can assist you in the future.”

Instead I received a blunt email saying asking for a refund was outside the terms of service, that the money had already been charged and that if I wanted, I could receive a $12 credit towards other services they offered.

Not only that, but the reply to email address on the support email was a “do-not-reply@company”!

Long story short, I found the support email address, also mentioned their reply address was broken, asserted my right to the refund and spent another 8 emails back and forth trying to get my point across.

All for $12!

I didn’t give a toss about the $12. But this was just wrong.

Finally contacting the head of accounting (O.o), I got my refund of $12 and a somewhat guarded apology. The very next thing I did was move 15 domain names off that company to another, went and spoke to three friends of mine that used them and they are all migrating as well.

All in all, customer service fail.

In an alternate universe the same scenario might have gone a little like this:

“Hi, it seems the service I just bought doesn’t do feature X which your marketing pages say it should do, I would like a refund please”.

“Thank you very much Mr Lindsaar for contacting us about this problem. I have alerted marketing to get this issue resolved and have already passed your details to our accounting department to credit your card, your refund should appear within 3-4 working days. As you took the time to alert us to this problem, I am also pleased to pass on a $10 credit for any other service we can provide you and have already applied this to your account. Thank you for using our company.”

I tell you, if they did that, they would have won me as a customer for life. And being a web application developer, that would be a not insignificant amount of business.

And how much would have that token of gratitude cost them?

Zero.

That’s right. Nada.

In fact, it would have cost them LESS than it cost to go the other way. Remember, they had to pay that “support” person to sit there writing me those invalidative emails, they had to pay his senior to review each email, they had to pay (I assume) the head of accounting to take the time to read and refund my card.

And they also lost all my future business.

Stupid. Stupid. Stupid.

So what do we have to do to bring about this alternate universe? One where relationships take precedence over the bottom line. Remember, the relationships will generate for you more bottom line than any discount or “loyalty program” will.

Get into communication with your clients.

Call them. Send them an email. Do a random survey. Make sure that every time a customer interacts with your organisation your staff are drilled on finding out if the client has had an unsatisfactory experience with your work. Get to know your clients, establish those relationships.

Because if you establish those relationships, then the client (just like your best friend) won’t be afraid to tell you that your fly is unzipped before you walk out in front of a packed audience and make a total fool of yourself.

And thank YOU for taking the time to read this. I appreciate it.

Mikel

Inline Attachments for ActionMailer

2010-06-07T23:40:00+00:00

ActionMailer’s support for inline attachments sucks. Totally. Until now.

If you have ever tried to get an inline attachment working in Rails 2.x or even Rails 3 more recently, you were faced with an uphill battle that really did not deserve to be there.

For those not in the know, an Inline attachment in an email is simply an attachment that has a Content-Disposition of “inline” and allows you to reference it by using an HTML image tag with its source attribute pointing to cid:conent-id-of-image-part.

This allows you to put logos in your emails, header images etc. All embedded within the email itself.

So enough talk, this is how you do it, say you have a welcome message in your Action Mailer class, and in this welcome message you want to embed your company logo, which is conveniently located in your Rails root “public/images” directory.

First in your mailer, you would do:

class Notifier < ActionMailer::Base

  def welcome
    data = File.read(Rails.root.join('public/images/logo.png'))
    attachments.inline['logo.png'] = data
    mail
  end
  
end

Notice the inline call to attachments? What this does is tells Mail to mark this file with a content disposition of “inline” instead of the usual “attachment”.

Then in your view you would do:

<h1>Thank you for choosing ErnCorp!</h1>
<p><%= image_tag attachments['logo.png'].url -%></p>

Here, we are just interrogating the mail.attachments hash for the attachment with the filename “logo.png” and then calling url on the attachment we fine. This generates a standard email content ID resource locator (cid tag) that looks something like: cid:4c0da20e13de6@mikel.local.mail

And that is it!

Now the cool thing about this is that when you send this email, ActionMailer looks through your attachments list finding any inline attachments, if it finds some, then it changes your email to a multipart/related content type and then makes these attachments available to the view through the attachments helper.

Anyway, this is now pushed. Enjoy and have fun!

blogLater

Mikel

Upgrading RailsPlugins.org to Rails 3 - Part 1

2010-05-18T04:34:07+00:00

Note, this post has been recreated now that Rails 3 has been released. Please see: Updating Railsplugins.org to Rails 3

New version available

Please see the above new version, the below is old content and not really usable any more

Old content:

I am going to do a series of blog posts covering the upgrade of RailsPlugins.org to Rails 3. You can follow along as we go and comments or suggestions are welcome!

This upgrade was done using at least Rails 3 beta3. If try it on anything earlier, it will most likely go boom.

Process

Going about upgrading a non trivial site like RailsPlugins.org requires a process to make sure it works:

Confirm the gems and plugins you are using either work with Rails 3, there are alternatives you can use, or you are interested in helping upgrade them – this is the most important step in terms of scope and time required to get the job done.
Run all specs and features or tests and make sure they pass – if you don’t have any, then now would be a good time to install Cucumber and write at least features covering all the main user stories of your site.
Run the rails_upgrade plugin to highlight areas of concern
Upgrade the application to Rails 3
Fix all concerns within your application itself, ignoring plugins for now
Go through each plugin and gem, either installing newer versions that are Rails 3 compatible, or replacing / fixing them
Run all specs and features and tests and make sure they pass
Boot up and play around in your development environment
Deploy on a staging environment to confirm your upgrade
Deploy live and watch like a hawk.

I am going to document all these steps as part of upgrading the RailsPlugins.org site.

Confirm the gems and plugins you are using

Going through all the plugins and gems we use on the RailsPlugins.org site, showed up that most of them have Rails 3 versions available or listed as “Maybe”. I guess I’ll be helping people get it done! :)

Run all specs and features

I have good coverage on RailsPlugins.org and it is all green… so onward and upwards.

Run the upgrade plugin

The rails_upgrade plugin is hosted on github and up to date with all the latest bells and whistles of Rails 3, so we’ll use that:

$ script/plugin install git://github.com/rails/rails_upgrade.git

And then once installed, we do:

$ rake rails:upgrade:check

Which gives us pages of output, simplified down to:

Deprecated constant(s)
Constants like RAILS_ENV, RAILS_ROOT, and RAILS_DEFAULT_LOGGER are now deprecated.
More information: http://litanyagainstfear.com/blog/2010/02/03/the-rails-module/
...

Deprecated session secret setting
Previously, session secret was set directly on ActionController::Base; it's now config.secret_token.
More information: http://weblog.rubyonrails.org/
...

Old session store setting
Previously, session store was set directly on ActionController::Base; it's now config.session_store :whatever.
More information: http://weblog.rubyonrails.org/
...

Deprecated ActionMailer API
You're using the old ActionMailer API to send e-mails in a controller, model, or observer.
More information: http://lindsaar.net/2010/1/26/new-actionmailer-api-in-rails-3
...

Old ActionMailer class API
You're using the old API in a mailer class.
More information: http://lindsaar.net/2010/1/26/new-actionmailer-api-in-rails-3
...

Soon-to-be-deprecated ActiveRecord calls
Methods such as find(:all), find(:first), finds with conditions, and the :joins option will soon be deprecated.
More information: http://m.onkey.org/2010/1/22/active-record-query-interface
...

named_scope is now just scope
The named_scope method has been renamed to just scope.
More information: http://github.com/rails/rails/commit/d60bb0a9e4be2ac0a9de9a69041a4ddc2e0cc914
...

Old Rails generator API
A plugin in the app is using the old generator API (a new one may be available at http://github.com/trydionel/rails3-generators).
More information: http://blog.plataformatec.com.br/2010/01/discovering-rails-3-generators/
...

Old router API
The router API has totally changed.
More information: http://yehudakatz.com/2009/12/26/the-rails-3-router-rack-it-up/
...

Deprecated ERb helper calls
Block helpers that use concat (e.g., form_for) should use <%= instead of <%. The current form will continue to work for now, but you will get deprecation warnings since this form will go away in the future.
More information: http://weblog.rubyonrails.org/
...

New file needed: config/application.rb
You need to add a config/application.rb.
More information: http://omgbloglol.com/post/353978923/the-path-to-rails-3-approaching-the-upgrade
...

OK, so this might be too long for a single blog post, let’s take it in sections then.

Deprecated constant(s)

This section produced the following output:

Deprecated constant(s)
Constants like RAILS_ENV, RAILS_ROOT, and RAILS_DEFAULT_LOGGER are now deprecated.
More information: http://litanyagainstfear.com/blog/2010/02/03/the-rails-module/

The culprits: 
  - /Users/mikel/Code/railsplugins/lib/tasks/environments.rake
  - /Users/mikel/Code/railsplugins/lib/tasks/cucumber.rake
  - /Users/mikel/Code/railsplugins/lib/tasks/hoptoad_notifier_tasks.rake
  - /Users/mikel/Code/railsplugins/lib/tasks/rspec.rake

Which doesn’t seem too bad. I only really have one file in my application that is to blame, environments.rake, the other three are part of plugins that RailsPlugins.org uses, and I trust that the Rails 3 versions of these which we will update to later, should handle themselves.

Opening up environments.rake we see:

# Sets environments as needed for rake tasks
%w[development production staging].each do |env|
  desc "Runs the following task in the #{env} environment" 
  task env do
    RAILS_ENV = ENV['RAILS_ENV'] = env
  end
end

task :testing do
  Rake::Task["test"].invoke
end

task :dev do
  Rake::Task["development"].invoke
end

task :prod do
  Rake::Task["production"].invoke
end

This is a custom rake file we use to easily set environments for rake tasks. However, setting RAILS_ENV is deprecated in Rails 3. In Rails 3, you can set Rails.env directly with an assignment. So changing this rake task to be Rails 3 compatible would be:

# Sets environments as needed for rake tasks
%w[development production staging].each do |env|
  desc "Runs the following task in the #{env} environment" 
  task env do
    Rails.env = env
  end
end

task :testing do
  Rake::Task["test"].invoke
end

task :dev do
  Rake::Task["development"].invoke
end

task :prod do
  Rake::Task["production"].invoke
end

OK good. As I mentioned above, we are going to eave the cucumber, rspec and hoptoad files to be updated by their respective gems as we move along.

Deprecated session secret setting

The rails_upgrade plugin has pointed out the following:

Deprecated session secret setting
Previously, session secret was set directly on ActionController::Base; it's now config.secret_token.
More information: http://weblog.rubyonrails.org/

The culprits: 
	- /Users/mikel/Code/railsplugins/config/initializers/session_store.rb

Old session store setting
Previously, session store was set directly on ActionController::Base; it's now config.session_store :whatever.
More information: http://weblog.rubyonrails.org/

The culprits: 
  - /Users/mikel/Code/railsplugins/config/initializers/session_store.rb

Which looks like this:

config/initializers/session_store.rb



ActionController::Base.session = {

  :key         => ‘_plugins_session’,

  :secret      => ‘somereallylongrandomkey’

}

In Rails 3, this process was changed quite significantly, with this commit, the upgrade though is very straight forward. First, you reduce session_store.rb to the following:

Rails.application.config.session_store :cookie_store, :key => "_my_app_name_session"

And then, because we now need somewhere to store the secret, you create a new file called config/initializers/cookie_verification_secret.rb and put inside of it:

Rails.application.config.cookie_secret = 'somereallylongrandomkey'

If instead of using cookies, you were using active record as the store, then you obviously wouldn’t need the cookie_verification_secret.rb file and instead would insert any other config you needed into its own file inside of initializers.

This gives us the added bonus of being able to exclude cookie secrets from source control systems.

In the next instalment, we’ll cover getting the RailsPlugins.org site actually up and running on Rails 3.

blogLater

Mikel

Stripping dollar signs and commas from a string

2010-05-14T02:07:33+00:00

It is moments like these that you realise why it is you love Ruby so much…

Today was one of those moments with the String class’s :delete method.

I have used this method many, many times in the past.. and this is nothing new for me… but it was one of those moments where I just went “Gee, I love coding in Ruby…” and I wanted to share :)

If you ever need to convert, say $12,345.12 into a single float number like 12345.12 a Ruby newbie, might do something like this:

"$12,345.12".gsub("$",'').gsub(",",'') #=> "12345.12"

But hark! Look into the string class and you shall find the :delete method, which lets you do this:

"$12,345.12".delete("$,") #=> "12345.12"

Ahhh… pure Ruby bliss.

blogLater

Mikel

Getting Rails 3 Edge with jQuery, RSpec and Cucumber using RVM

2010-05-09T22:08:27+00:00

Here are the simple (?) steps to get Rails 3 running with the above technologies.

Install Rails

You know, this is pretty obvious, but before you get into any other hoo ha you are going to have to get a version of Rails installed into your system gems so that you will have access to the rails command.

So:

$ gem install rails --version "3.0.0.beta3"
Successfully installed i18n-0.3.7
Successfully installed tzinfo-0.3.20
Successfully installed builder-2.1.2
Successfully installed memcache-client-1.8.3
Successfully installed activesupport-3.0.0.beta3
Successfully installed activemodel-3.0.0.beta3
....

Should do the trick.

Setup the Rails app

Now we have Rails install our app using the standard rails g command.

$ rails my_app -JT
     create  
     create  README
     create  .gitignore
     create  Rakefile
     create  config.ru
     create  Gemfile
     ....

The -J parameter, tells Rails not to install the Prototype Javascript libraries. The -T tells it to skip generating the Test::Unit files, together they order Cheese Royals

Setting up RVM

Now change into the my_app directory and add the line rvm ruby-1.8.7@my_app to the .rvmrc file

$ echo "rvm ruby-1.8.7@my_app" > .rvmrc

This will make a clean gemset for our Rails app to play in.

But we need to create the gemset first:

$ rvm gemset create 'my_app'
Gemset 'my_app' created.

Nice.

Now whenever we cd into the my_app directory, RVM will auto detect the .rvmrc file and switch our gemset to the my_app Gemset.

Or we can do it manually:

$ rvm ruby-1.8.7@my_app
$ gem list

*** LOCAL GEMS ***

rake (0.8.7)

Awesome.

House Keeping

$ cd my_app/
$ rm public/index.html
$ rm public/images/rails.png

Notice I deleted the index.html and rails.png above. You don’t have to do this right now, if you want to see the nice happy message telling you that daisies are going to bloom and butterflies are fluttering about because your Rails App is now working, please don’t remove it yet, wait and fire up your rails app with rails s and browse to http://127.0.0.1:3000 and bask in your RailsFuNess…

But for the rest of us, nuke it.

Getting jQuery installed

Next, we need to install jQuery. Just go to the website and download it and place it into your javascripts directory. For cut and fiends out there, this curl command should handle it as well:

$ mkdir public/javascripts/jquery
$ curl http://code.jquery.com/jquery-1.4.2.min.js > public/javascripts/jquery/jquery-1.4.2.min.js

Note I have put this into a jQuery folder. I have done this so that the javascript_include_tag :all command I will use further down does not pickup the jQuery source files.

Getting the Rails jQuery Driver

Now that we have destroyed prototype, we need to replace it with jQuery, two steps to this.

First, download the jQuery driver and over write your rails.js file that lives in public/javascripts/, I usually do this by going to the Rails jQuery-UJS page and clicking raw and cut and pasting it into the public/javascripts/rails.js file. Feel free to use a submodule if you wish, or

$ curl http://github.com/rails/jquery-ujs/raw/59dd91d945570391f905b1e40444e5921dbc2b8f/src/rails.js > public/javascripts/rails.js

Will do it as well… note, this will most likely not be the most recent version in the future. To get the latest, go to the Rails jQuery-UJS page and click on the RAW link to the right of the source code div.

Wiring up jQuery and the Rails driver

Now that we have jQuery and the Rails jQuery UJS drivers installed, we need to wire them up to the app, so open up app/views/layouts/application.html.erb make it look like the following:

<!DOCTYPE html>
<html>
<head>
  <title>MyApp</title>
  <%= stylesheet_link_tag :all %>
  <%= csrf_meta_tag %>
</head>
<body>

<%= yield %>

<%= javascript_include_tag 'jquery/jquery-1.4.2.min' %>
<%= javascript_include_tag :all, :cache => true %>
</body>
</html>

OK, couple of things here. Firstly, we remove the javascript_include_tag :all from the header. Then we put the two tags at the bottom of the document.

Why do we separate out the jquery/jquery-1.4.2.min from the javascript_include_tag :all line? This is because the :all directive will just grab all the javascript files in the order it finds them and bundle them all together, which means that your javascript files, may be trying to init javascript classes from your jQuery library that do not exist yet.

So we get around this by loading jQuery first.

OK. So that is jQuery sorted, now onto the specifications side.

Installing RSpec & Friends

Best way to go about this, is to modify your Gemfile and make it look something like this:

source 'http://rubygems.org'

## Bundle edge rails:
gem "rails",  :git => "git://github.com/rails/rails.git"
gem "sqlite3-ruby"

group :test do
  gem "rspec"
  gem "rspec-rails",      ">= 2.0.0.beta"
  gem "machinist",        :git => "git://github.com/notahat/machinist.git"
  gem "faker"
  gem "ZenTest"
  gem "autotest"
  gem "autotest-rails"
  gem "cucumber",         :git => "git://github.com/aslakhellesoy/cucumber.git"
  gem "database_cleaner", :git => 'git://github.com/bmabey/database_cleaner.git'
  gem "cucumber-rails",   :git => "git://github.com/aslakhellesoy/cucumber-rails.git"
  gem "capybara"
  gem "capybara-envjs"
  gem "launchy"
  gem "ruby-debug"
end

This is going to install everything you need to get RSpec, Cucumber, Machinist, autotest and even throwing in the Ruby Debugger at the bottom.

Save this, and then we need to install it. But remember, we are on a clean gemset, so we need to install bundler first:

 $ gem install bundler
Successfully installed bundler-0.9.25
1 gem installed
Installing ri documentation for bundler-0.9.25...
Installing RDoc documentation for bundler-0.9.25...

mikel@baci.lindsaar.net ~/Code/my_app
 $ gem list

*** LOCAL GEMS ***

bundler (0.9.25)
rake (0.8.7)

Good to go, so now we are just a bundle install away from launching:

 $ bundle install
Fetching source index from http://rubygems.org/
Using rake (0.8.7) from system gems 
Installing abstract (1.0.0) from .gem files at /Users/mikel/.rvm/gems/ruby-1.8.7-p249@my_app/cache 
...

And we are away!

Initializing RSpec and Cucumber

Now that we have all our dependencies done, we need to tell RSpec and Cucumber to get a move on:

$ rails g rspec:install
      exist  lib
     create  lib/tasks/rspec.rake
      exist  config/initializers
     create  config/initializers/rspec_generator.rb
     create  spec
     create  spec/spec_helper.rb
     create  autotest
     create  autotest/discover.rb

And then for cucumber, we will use capybara (because we installed it in the Gemfile above) and pass —rspec because I like being complete!

$ rails g cucumber:skeleton --capybara --rspec
     create  config/cucumber.yml
     create  script/cucumber
      chmod  script/cucumber
     create  features/step_definitions
     create  features/step_definitions/web_steps.rb
     create  features/support
     create  features/support/paths.rb
     create  features/support/env.rb
      exist  lib/tasks
     create  lib/tasks/cucumber.rake
       gsub  config/database.yml
       gsub  config/database.yml
      force  config/database.yml

OK good.. so that is our skeleton app.

One last thing, we are using Rails with sqlite, so it will expect our databases to exist before it will run any tests, so let’s make them:

$ rake db:create

Getting our first feature to run

Now that we have our app installed and everything wired up, we should be able to get an initial feature working, so go ahead and make a features/the_home_page.feature file, and whack something like this in it:

Feature: Manage app_should_boots
  In order to see what my app is about
  a user
  wants to be able to land on a home page
  
  Scenario: Visiting the site for the first time
    Given I am on the home page
    Then I should see "Welcome" within "h1"

This should fail:

Using the default profile...
.F

(::) failed steps (::)

scope '//h1' not found on page (Capybara::ElementNotFound)
./features/step_definitions/web_steps.rb:14:in `with_scope'
./features/step_definitions/web_steps.rb:108:in `/^(?:|I )should see "([^\"]*)"(?: within "([^\"]*)")?$/'
features/the_home_page.feature:8:in `Then I should see "Welcome" within "h1"'

Failing Scenarios:
cucumber features/the_home_page.feature:6 # Scenario: Visiting the site for the first time

Which is saying that the default rails “Not Found” page does not have “Welcome” within a “h1” tag… which I guess is true!

Lets fix this:

First we’ll generate the welcome controller:

$ rails g controller welcome
     create  app/controllers/welcome_controller.rb
     invoke  erb
     create    app/views/welcome
     invoke  rspec
     create    spec/controllers/welcome_controller_spec.rb
     create    spec/views/welcome
     invoke  helper
     create    app/helpers/welcome_helper.rb
     invoke    rspec

Then we’ll edit the config/routes.rb file to wire up the root url to the welcome controllers index action:

MyApp::Application.routes.draw do |map|
  root :to => "welcome#index"
end

Note, if you haven’t already deleted the public/index.html file, now is a good time to do it!

Now we make an app/views/welcome/index.html.erb file and put in it our welcome message:

<h1>Welcome</h1>

And now we will re-run our cucumber feature and all should be good:

 $ rake cucumber
Using the default profile...
..

1 scenario (1 passed)
2 steps (2 passed)
0m0.214s

Cool! We are now on the Rails with Cucumber and everything else that is good in the world.

Enjoy!

blogLater

Mikel

Action Mailer, go Proc thyself

2010-05-03T10:11:00+00:00

On my recent Rails Dispatch screen cast, I had a seemingly innocent example of a default header, using Time.now to insert a time stamp.

It was an innocent thing, and truthfully, I had it there more as an example than something I would do in production.

Nevertheless, good Ruby aficionados will recognise the mistake from a thousand miles away, the default hash inside of Action Mailer gets read, parsed and evaluated at compile time, not on a per message basis… which makes it basically useless as a Time stamp.

Rick DeNatale pointed this out in a question to me at RailsDispatch, he also asked if Action Mailer supports Proc objects inside of the default hash.

Sadly, the answer was no.

But then a few hours later it was yes!

So now you can pass in Proc objects to your Action Mailer class default method, like so:

class Notifier < ActionMailer::Base
  default :to => 'system@test.lindsaar.net',
          :subject => Proc.new { give_a_greeting }

  def welcome
    mail
  end
  
  private
  
  def give_a_greeting
    "This is a greeting at #{Time.now}"
  end
end

Which would then call the give_a_greeting method on your Mailer instance to create a value to assign to the subject field.

Enjoy!

blogLater

Mikel

The Real News Donation Drive

2010-04-30T10:33:35+00:00

If you haven’t checked out the The Real News Network, now is the time.

The Real News are not supported by corporate or government funding, they don’t have to report to anyone except you and me, people who fund them for the only real independent news agency in the world.

They are on a fundraising drive right now to raise $500,000 in 24 hours to fund the next six months worth or programming. It is worth your money to go and make your donation.

I just pledged my monthly donation to this worthy cause. No where else can you get unbiased views. If you want an independent news feed that is not bought by the corporate masses, go and give them a small or large donation, better yet, sign up for $10 per month like I did to help fund it on an ongoing basis!

I don’t know about you, but I am sick of the mass media, calm the masses, issue dodging drivel that spews from our poor excuses for news media. It is obviously bought out by vested interests… but people power can win!

blogLater

Mikel

ActionMailer ScreenCast and Article

2010-04-24T04:43:14+00:00

I was asked by the guys at EngineYard (who have created RailsDispatch) to host this week’s topic, ActionMailer.

Of course I agreed, and the result is now online. There is a shortish (10 minute) screen cast as well as a very detailed article.

The article really goes into depth on ActionMailer, I tried to cover all the major points and walk through all the parts that I felt were important. The screen cast shows you just how easy it is to setup email now.

Please feel free to let me know what you think in the comments here!

blogLater

Mikel

Installing RSpec for Rails 3

2010-04-14T20:48:06+00:00

Installing RSpec for Rails 3 was quite simple, here is a short guide to make sure you can also do it :)

For a Rails 3 app, simply edit the Gemfile and put this into the test section:

group :test do
  gem "rspec-rails",      ">= 2.0.0.beta"
  gem "autotest"
  gem "autotest-rails"
end

Then from your Rails root do:

$ bundle install

Once installed, you will need to tell RSpec to install itself:

 $ script/rails g rspec:install
       exist  lib
      create  lib/tasks/rspec.rake
       exist  config/initializers
      create  config/initializers/rspec_generator.rb
       exist  spec
      create  spec/spec_helper.rb
      create  autotest
      create  autotest/discover.rb

Then you should just be able to run Autotest:

 $ autotest
loading autotest/rails_rspec2
style: RailsRspec2
/Users/mikel/.rvm/rubies/ruby-1.8.7-p249/bin/ruby <snip>
........

Finished in 0.30205 seconds
8 examples, 0 failures

Nice.

blogLater

Mikel

I am speaking at RailsConf 2010

2010-04-12T05:51:17+00:00

If you visit my website, you can see the badge, and it is true, this Aussie munchkin is making the trek to the US of A to talk to a bunch of people about a little section of Rails.

The talk is called “Itch Scratching the ActionMailer API” and I am going to discuss how it all happened, from starting with TMail, why I got fed up with it, why I started Mail, how I went about coding it including spec examples and my workflow, and then onto integrating Mail into ActionMailer and then onto rewriting the ActionMailer API.

I hope it will be an interesting talk, I’ll also be going over Mail and how to use it and some of the lesser known features that you can take advantage of in Rails.

Hope to see you there! If you have any suggestions or things you would like me to include, hit me up in the comments, or via Twitter or through my email address.

See you soon!

blogLater

Mikel

Rails 3 Session Secret and Session Store

2010-04-07T20:30:00+00:00

In Rails 3 the location and way you declare the session secret and session store have changed.

Rails 3 Session Secret and Session Store

In Rails 3 the location and way you declare the session secret and session store have changed.

Previously (in 2.3.x) you would have one file:

config/initializers/session_store.rb



ActionController::Base.session = {

  :key         => ‘_my_app_name_session’,

  :secret      => ‘somereallylongrandomkey’

}

In Rails 3, you reduce session_store.rb to the following:

Rails.application.config.session_store :cookie_store, :key => "_my_app_name_session"

And then, because we now need somewhere to store the secret, you create a new file called config/initializers/cookie_verification_secret.rb and put inside of it:

Rails.application.config.cookie_secret = 'somereallylongrandomkey'

This gives us the added bonus of being able to exclude cookie secrets from source control systems.

blogLater

Mikel

If you're lazy and you know it write your specs!

2010-04-04T04:43:28+00:00

You need to sing that title along to this tune but it struck me as a great idea for a post.

As you probably all know, I code the Mail library for Ruby. When I announced my intentions to the TMail mailing list last year, I had a bunch of people say “Don’t bother, it’s too big a job” or “just wrap the libmime library”. But I decided to try it out, I mean, how hard could it be?

Hard.

No really. It’s a real pain covering all the edge cases. Email is probably one of the most abused specifications out there, actually. No. I think it is THE most abused specification out there. Even the worst HTML pages are better put together than your average spam email. And there are millions of spam emails.

But when I started on Mail, I made a conscious decision to spec first the entire library, and as it stands today, there are over 1300 specs in Mail.

The first spec I wrote was actually this one (which is still in the library):

describe "mail" do
  it "should be able to be instantiated" do
    doing { Mail }.should_not raise_error
  end
end

One of the more narly ones is:

it "should handle |Pete(A wonderful ) chap) <pete(his account)@silly.test(his host)>|" do
  address = Mail::Address.new('Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>')
  address.should break_down_to({
      :name         => 'Pete',
      :display_name => 'Pete',
      :address      => 'pete(his account)@silly.test',
      :comments     => ['A wonderful \\) chap', 'his account', 'his host'],
      :domain       => 'silly.test',
      :local        => 'pete(his account)',
      :format       => 'Pete <pete(his account)@silly.test> (A wonderful \\) chap his account his host)',
      :raw          => 'Pete(A wonderful \\) chap) <pete(his account)@silly.test(his host)>'})
end

What has this got to do with being lazy? Easy, if you have a full spec (or test) suite and you change something, you can track the impact there is on the entire library.

So when I get an email that breaks mail, I load it into the spec suite, and run it, get a failure, then go ahead and change code with aplomb, each time running the specs.

There is a huge sense of security knowing you have thorough spec coverage.

I have another application, consisting of over 50,000 lines of code (combined specs, features and code itself) which I wrote for a client. I had to go back to it 7 months after I wrote it (having basically not touched it for this time) and add a new feature.

The first thing I did was make sure the spec suite was running. It was, mostly, another coder had made some changes and not updated the specs and features, so there were a few failures. So I got to work and got it green.

Then making the change was trivial, I didn’t have to worry too much about unintended consequences as I know the spec and feature set was very thorough. The client is also rewarded with a highly maintainable application that is mostly error free and has been running happily along.

The point is, that if you are not thorough writing test / specs / features with your Rails app. Then you are not doing your job in a professional manner, simple as that.

But the good point is, if you like being lazy (and not having to spend HOURS trying to debug the latest problem with your code), write your specs and features as you go. You will save yourself (and your client / boss / life) countless hours of frustration.

blogLater

Mikel

Bundler - uninitialized constant ActionController

2010-04-01T17:01:30+00:00

If you are switching over a Rails 2.3 app to Bundler with a Rails App, or you are setting up a new one, you might run into this error when you try to boot rails or run a rake task, thankfully the solution is simple.

The problem is that in your Gemfile, you are trying to load a gem that requires the Rails stack to be in place. If you check out the Bundler docs for Rails 2.3 you will see a :plugins group option. This group provides a way to load up gem plugins that require the Rails stack.

If you are not sure which gem is requiring the Rails stack before Rails is loaded and thus blowing out bundler, you can run rake -T as usual, you will get something like this:

 $ rake -T --trace
(in /Users/mikel/Code/railsplugins)
rake aborted!
uninitialized constant ActionController
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:443:in `load_missing_constant'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:80:in `const_missing'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/activesupport-2.3.5/lib/active_support/dependencies.rb:92:in `const_missing'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/behavior-0.2.0/lib/behavior.rb:80
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:45:in `require'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:45:in `require'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:40:in `each'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:40:in `require'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:39:in `each'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler/runtime.rb:39:in `require'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/bundler-0.9.14/lib/bundler.rb:75:in `require'
/Users/mikel/Code/railsplugins/config/../config/preinitializer.rb:20
/Users/mikel/Code/railsplugins/config/boot.rb:28:in `load'
/Users/mikel/Code/railsplugins/config/boot.rb:28:in `preinitialize'
/Users/mikel/Code/railsplugins/config/boot.rb:10:in `boot!'
/Users/mikel/Code/railsplugins/config/boot.rb:128
/Users/mikel/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
/Users/mikel/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
/Users/mikel/Code/railsplugins/Rakefile:4
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/gems/rake-0.8.7/bin/rake:31
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/bin/rake:19:in `load'
/Users/mikel/.rvm/gems/ruby-1.8.7-p249@global/bin/rake:19

Now, inside of that trace is a single line:

/Users/mikel/.rvm/gems/ruby-1.8.7-p249@railsplugins/gems/behavior-0.2.0/lib/behavior.rb:80

And there is your clue, moving the gem requirement for behavior into the :plugins group like this:

# Gemfile

source :gemcutter

gem 'rails', '2.3.5'

gem 'mysql',            '2.8.1'

group :plugins do
  gem 'behavior',       '0.2.0'
end

Save and re run the rake task, if you are like me and had two or three of these lurking, you will have to work out which ones to put into the :plugins group yourself, the type of plugin is usually pretty obvious.

blogLater

Mikel

Bundle Me Some Sanity

2010-03-31T21:40:44+00:00

You know, there are these two guys working in broad daylight on Bundler, Yehuda and Carl (he’s the one in the sidecar), but I don’t think people have really grasped the importance of what they are doing.

Bundler is just as mind blowing a development for Rails 3 as any other change in the Rails framework. As the wycats states; “Bundler manages an application’s dependencies through it’s entire life across many machines systematically and repeatably”.

To me, bundler takes the guess work out of dependency management, it simply provides you with a way to know what gems you are distributing with your application, we (as a Ruby community) have never had such a comprehensive solution to gem management before.

But like any new tool, it is going to go through some growing pains. To my surprise, (and the credit of the authors) the growing pains have been short and sharp, rapidly fixed as bundler grows to whole new levels of reliability.

And also like any new tool, it is optimised for certain environments, in bundler’s case, USE RVM! If you are not using RVM and you are running multiple rubies with Bundler, honestly, you’re mad. Do yourself a favour, download RVM and use it. You can then specify sand boxes of gem sets for each ruby or application you have, goodbye incompatible gems conflicting with each other.

To give you a taste of just how awesome the Bundle RVM marriage is, check this out:

After you install RVM, go into the directory of each app you want to have their own private gem sets and create a file called .rvmrc and put in there:

rvm ruby-1.8.7@railsplugins

Which is what I have on my RailsPlugins.org repository.

Then change into the directory, and RVM will tell you it doesn’t know about the gemset:

$ cd railsplugins
Gemset 'railsplugins' does not exist, rvm gemset create 'railsplugins' first.

OK, so go ahead and create the gemset and have a look at what gems you have installed:

$ rvm gemset create 'railsplugins'
Gemset 'railsplugins' created.
$ gem list

*** LOCAL GEMS ***

$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10.2.0]

Good… see? A clean ruby 1.8.7, as if you just bought the computer.

Now go ahead and install bundler for this clean gemset:

$ gem install --no-rdoc --no-ri bundler
Successfully installed bundler-0.9.14
1 gem installed

Cool, now all that we have left is to give bundler the reins and tell it to do what it does best:

$ bundle install
<lots of output>

Now when you gem list for that directory you will get all the gems in your gem file, and when you move to a different directory (with a different .rvmrc) all your gems get magically switched out for the new set.

Honestly, with the number of different clients I am coding for and the number of libraries I am working on, I can’t imagine being any where near as productive without the RVM and bundler team.

Yehuda has made a fairly comprehensive guide to bundler at the Gem Bundler site which you should read through and understand, and I have only brushed the surface of RVM, you should check it out as well at the RVM site

blogLater

Mikel

How to use Mail / ActionMailer 3 with GMail SMTP

2010-03-15T16:29:34+00:00

Getting Mail (and therefore ActionMailer 3) working with GMail SMTP is crazy simple, if you know how.

The secret is actually in the Mail RDoc, but to save you looking, here you are:

Mail allows you to send emails using SMTP. This is done by wrapping Net::SMTP in
an easy to use manner.

Sending via SMTP server on Localhost

Sending locally (to a postfix or sendmail server running on localhost) requires
no special setup. Just do

Mail.deliver do
       to 'mikel@test.lindsaar.net'
     from 'ada@test.lindsaar.net'
  subject 'testing sendmail'
     body 'testing sendmail'
end

# Or:

mail = Mail.new do
       to 'mikel@test.lindsaar.net'
     from 'ada@test.lindsaar.net'
  subject 'testing sendmail'
     body 'testing sendmail'
end

mail.deliver

And your email will be fired off to your localhost SMTP server.

Sending via GMail

To send out via GMail, you need to configure the Mail::SMTP class to have the correct values, so to try this out, open up IRB and type the following:

require 'mail'
options = { :address              => "smtp.gmail.com",
            :port                 => 587,
            :domain               => 'your.host.name',
            :user_name            => '<username>',
            :password             => '<password>',
            :authentication       => 'plain',
            :enable_starttls_auto => true  }
            
Mail.defaults do
  delivery_method :smtp, options
end

The last block calls Mail.defaults which allows us to set the global delivery method for all mail objects that get created from now on. Power user tip, you don’t have to use the global method, you can define the delivery_method directly on any individual Mail::Message object and have different delivery agents per email, this is useful if you are building an application that has multiple users with different servers handling their email.

Delivering the email

Once you have the settings right, sending the email is done the same way as you would for a local host delivery default:

Mail.deliver do
       to 'mikel@test.lindsaar.net'
     from 'ada@test.lindsaar.net'
  subject 'testing sendmail'
     body 'testing sendmail'
end

Or by calling deliver on a Mail message

mail = Mail.new do
       to 'mikel@test.lindsaar.net'
     from 'ada@test.lindsaar.net'
  subject 'testing sendmail'
     body 'testing sendmail'
end

mail.deliver

Combining this with ActionMailer 3

So as ActionMailer 3 uses Mail as it’s email transport agent, all you have to do is pass the same options Hash into ActionMailer:

ActionMailer::Base.smtp_settings = {
  :address              => "smtp.gmail.com",
  :port                 => 587,
  :domain               => 'your.host.name',
  :user_name            => '<username>',
  :password             => '<password>',
  :authentication       => 'plain',
  :enable_starttls_auto => true  }
}

Hope that helps!

blogLater

Mikel

Put your mailer where the action is!

2010-03-02T04:28:20+00:00

Recently I was pointed at an article by Robby on Rails which discussed where mailers belong. Well, after reading the amazingly long discussion, I feel the solution is quite simple.

Put it in the controller if the primary action depends on sending email.
Put it in a callback if the email is a byproduct.

But first a little history. ActionMailer has been rewritten, almost from the ground up. It now inherits from AbstractController, and is the same sort of beast as one of your view controllers. In fact, it uses the same render calls that your average controller does and as far as Rails is concerned, it is just another controller, except it renders email instead of web pages.

Controllers when they are processing a request from a user, control the action. They decide what models get queries, what files or images get sent and what access the users can and can’t have. This is all decided in the controller.

ActionMailer is just another controller, it is much more a controller than a model. So if it is just a controller, we should treat it as one!

But what do I mean above by “a primary action”? Well, take a new user signing up and needing to click on an registration link, the controller should be responsible for getting the email sent:

class UsersController < ActionController::Base
  def create
    # ...
    if @user.save
      Notifier.deliver_verification_email
      flash[:notice] = "Please check your inbox..."
      redirect_to home_path
    else
    # ...
  end
end

Here the primary action of this user is to get a new account, and part of that is the verification email, in fact, a big part of that. So much so that if they don’t get that email, then they don’t get an account.

What about another primary action? Well, password reset is a perfect example:

class PasswordsController < ActionController::Base
  def destroy
    user = User.find_by_email(params[:email])
    Notifier.deliver_password_reset(user)
    flash[:notice] = "Please check your inbox..."
    redirect_to home_path
    # ...
  end
end

Again, here we have a controller who is handling a request from a user who wants to receive an email. The primary purpose here is to deliver that email. Why make a whole complex call back? The logic is simple, clear and easy to follow.

But by-product emails are another thing.

At RailsPlugins.org, we have it hooked up to RubyGems.org so that if you push a new gem version to RubyGems, and you have that same gem listed and ‘linked’ in RailsPlugins, then that new version will be automatically created for you on RailsPlugins with all the previous version’s compatibility matrix, oh, and by the way, the RailsPlugins app will send you an email to let you know.

That is the key phrase though, to let you know.

If the email doesn’t get sent, it’s not the end of the world. It is not a primary action. It will not destroy the integrity of your database. In fact, it may not even be noticed if it was missing. So putting this into the model, or as a call back is perfectly valid.

Another by-product email would be notifications to everyone watching a comment thread. Again, this is dependent on the model being saved, the comment being valid, and, oh, we’ll send out a notification to all our users. The email is not the primary part of the app, and would be clutter in the controller. Another perfect example of a mailer that can go into an observer, call back or the model itself.

The bottom line is, it is not a religious war, put your mailers where they make sense.

But with ActionMailer now effectively just another controller, use it as one!

blogLater

Mikel

Why Force a Choice?

2010-02-20T17:48:58+00:00

Recently I have been reading a bit from the Python crowd, and I realised a key point on why Rails is successful, you are not forced to choose.

You have all heard the “Convention over Configuration” mantra, and, if you use Rails, you most likely subscribe to this war cry, and why not? It enables the average developer to get up of the ground fast with an application that works, while simultaneously allowing your non average developer to do whatever the hell they want and extend the system in new and interesting ways.

This mantra provides the Rails Community with probably the second biggest advantage over any other web development framework out there, the first advantage is of course Ruby itself.

But while reading the installation manual from our DeeJayAngo friends, I kept hitting spots where the author was asking the reader to make decisions, mod_wsgi or mod_python, Apache or Nginx, threaded or prefork, the list goes on.

Now assumedly, the audience that article was written to was a crowd of developers who do not already know how to install a Python based web server, so asking them to make decisions on the capacity, style, environment and resources of a web app is a bit premature.

Of course, I am making an example of that one article, but I keep seeing this in various instruction manuals and frameworks. If that article was entitled “Django Installation Reference for the Experienced Developer” then fine, but it isn’t.

This reminds me of a saying from my philosophy of choice, “To decide, one must first understand”, and this holds very true in all of our web development circles, not just programming and installation guides.

Rails is opinionated, this is another way of saying that the developers of Rails (who do understand) makes decisions on behalf of the new user (who has relatively no clue) on how the system should behave. Then, step by step the user expands their knowledge up to a point where they understand the system themselves, and then, can make their own decisions, like change a javascript library, or write your own style scaffold, or whatever you choose.

But you as a Rails developer need to also keep this nugget of philosophy in mind when you are developing your Rails app. Your new customer has no idea how your system works, if the first thing you do is require them to make decisions, then chances are you are going to lose customers.

Each step of your site should have, as much as possible, ONE action that the customer should do to proceed to the next step.

Customer comes to your site for the first time, good, offer them the trial account, obviously and clearly. They don’t understand your service, they don’t really need to beyond “Will this service solve my problem at a realistic price?”. Making them decide to buy plan A or plan B, when they don’t even know what it is you do is just asking for disaster.

Customer logs into their newly purchased account, good, tell them what to do as a first action. Then, preferably, tell them what the second standard action is. Of course, don’t force them to do what you think is the best next step, but these User Interface guides can drastically improve your site’s usability.

The other thing that this forces you to do as a developer is simplify your site design and change the way you think. Of course you want the user to have many options, but if you keep this idea in mind of “Does the user at this point understand enough to be able to make a decision?” then you will find your product will become more and more successful.

blogLater

Mikel

How to make an RSS feed in Rails

2010-02-12T22:12:05+00:00

Easy. Don’t. Use an ATOM feed instead. Rails is opinionated software, it has an opinion on feeds, there is an atom_feed helper, but no rss_feed helper? Omission? Nup.

I added the ATOM feed to Rails Plugins website very simply, by using the Rails atom_feed helper. It was a simple case of creating a FeedsController with just a single index action, which collected up all the time line events that needed to go onto the feed and assigned them to the view in an @events ivar.

So the controller looks like this:

class FeedsController < ApplicationController
  
  layout false
  
  def index
    @events = TimelineEvent.for_feed
    @title = "Rails Plugins Feed"
    @updated = @events.first.created_at unless @events.empty?
  end
end

Then in the view file app/views/feeds/index.atom.builder looks like this:

atom_feed do |feed|
  feed.title(@title)

  feed.updated(@updated)

  @events.each do |event|
    feed.entry(event) do |entry|

      entry.title(h(event.title))
      entry.summary(truncate(strip_tags(event.description), :length => 100))

      entry.author do |author|
        author.name(event.author_name)
      end
    end
  end
end

And then the route to wire it up:

# config/routes.rb (Rails 2.0)
ActionController::Routing::Routes.draw do |map|
  map :resources :feeds, :only => [:index]
end

And finally the auto_discovery_link_tag in the application.html.erb:

<%= auto_discovery_link_tag(:atom, "/feeds.atom") %>

Now this was all well and good, and I thought, why not add an RSS feed as well?

I started down on this path and the first thing that struck me was, there was no rss_feed helper in Rails, why? Seemed like an ommission…

Then I was looking around the web and found many examples on how to do an RSS feed in Rails, but none of them mentioned this omission of the helper, why?

I didn’t puzzle over this long, and just went ahead and added an RSS feed, it wasn’t hard, you can find this out from your friend google.

But then I got this IM from Sam Ruby after I let him know the RSS feed for Rails Plugins was now online:

“Ewwwww”

Which was not really the answer I was expecting, so I stated:

“I never did get the ATOM v RSS debate”

To which he replied:

“I started the Atom vs RSS debate.”

And that started an interesting chat! Let me tell you!

Turns out that ATOM is actually defined, with RFC 4287 that covers all the basics of what you need to know.

Also turns out that any modern reader will handle ATOM, just as easily as RSS.

Also turns out that with ATOM you can define things like (gasp) language settings, Internationalization, content types and several other points which make the data a lot more consumable.

So, then I added the following to the Rails Plugins website:

class FeedsController < ApplicationController
  def index
    # ...
    respond_to do |wants|
      wants.rss do
        redirect_to feeds_path(:format => :atom),
                    :status=>:moved_permanently
      end
      wants.atom
    end
  end
end

And decided to sum up my gained knowledge with: We are Rails, we are opinionated, ta-ta RSS http://bit.ly/c9eyNL – KTHXBAI

blogLater

Mikel

Rails 3 Routing with Rack

2010-02-07T05:56:12+00:00

You probably all have heard that “Rails lets you route to Rack applications directly” and thought “Oh really?” well… bet you didn’t think it would be this simple.

Rails 3 really opens up a whole new world of pluggable awesomeness. This post expects you have already installed Rails 3 —prerelease, if not, follow the instructions in the Release Notes

The goal here is to make a Sinatra app run inside of Rails, taking routes it needs directly using the new Rails routing features.

Code is better at talking than me, so first make a new app:

$ rails app

Let rails do its thing. Then we want to make a simple Sinatra app, let’s make it marginally useful and have it hit Twitter.

Make a directory lib/twitter and in there make a new file called twitter_app.rb, inside of it put:

class TwitterApp < Sinatra::Base
  set :root, File.dirname(__FILE__)

  get '/twitter' do
    @user = 'raasdnil'
    t = Twitter::Search.new(@user).fetch
    @tweets = t.results
    erb :twitter
  end

end

This is a basic Sinatra app, it first sets its root directory to be the directory of the current file (needed because using the Rails root will not work) and then responds to one url /twitter that uses the Twitter gem to do the heavy lifting on searching for all the tweets by some weirdo (me).

It then assigns all the tweets to an instance variable and renders the template twitter.erb.

We have to make this template, so create another folder lib/twitter/views and make a file in there called twitter.erb and put in the following:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Tweets mentioning <%= @user %></title>
  </head>
  <style type="text/css" media="screen">
    div.tweet { border: 1px solid gray;
                height: 50px;
                width: 600px;
                padding: 5px;
                margin-bottom: 10px; }
    img.icon { float: left; padding-right: 10px; }
    div.text { font-family: verdana, sans-serif; }
    div.<%= @user %> { background: #F4F4FF; }
  </style>
  <body>
    <% @tweets.each do |tweet| %>
    <div class="tweet  <%= tweet.from_user %>" id="<%= tweet.id %>">
      <img class="icon" src="<%= tweet.profile_image_url %>" />
      <div class="text" >
        <%= tweet.text %>
      </div>
    </div>
    <% end %>
  </body>
</html>

OK, our Sinatra app is ready to fire. Now hooking it up is simple.

First, we need to make sure we require the needed gems, so open up your Gemfile in Rails root and add the following:

## Bundle the gems you use:
gem "sinatra", "0.9.2"
gem "twitter", "0.8.3"

Then do a bundle check to make sure we have the gems we need:

$ bundle check
The Gemfile's dependencies are satisfied

All good (if that gave you an error, just run bundle install).

Now the final step is to wire up the Rails Router.

Open up config/routes.rb and add a require for your twitter app as well as a route to match ‘/twitter’ and send to your Sinatra App, something like this:

require 'twitter/twitter_app'

RackTest::Application.routes.draw do |map|

  match '/twitter', :to => TwitterApp

end

And that’s it!

Fire up your Rails app with rails s as you normally would, and browse to http://127.0.0.1:3000/twitter and proove it to yourself… this stuff works.

Almost too simple.

blogLater

Mikel

Bundle me some Rails

2010-02-06T00:42:17+00:00

Bundler rocks, but you need to think differently about how to start and run your Rails app.

The Bundler Way

You should realise that Bundler is a library management tool. This has to be in your mind when you are getting a Rails application running on version 3.0.

For example, I had a new Rails application that I want to run with PostgreSQL, so I go in and change database.yml to look at my PostgreSQL database instead of the Sqlite3 database, fairly standard, straight forward opperation.

Then starting the application console however, I got a bit of a shock:

 $ rails c
/Users/mikel/.gem/ruby/1.8/gems/activerecord-3.0.0.beta/lib/active_record/connection_adapters/abstract/connection_specification.rb:76:in `establish_connection':
Please install the postgresql adapter: `gem install activerecord-postgresql-adapter`
(no such file to load -- pg) (RuntimeError)
  from /Users/mikel/.gem/ruby/1.8/gems/activerecord-3.0.0.beta/lib/active_record/connection_adapters/abstract/connection_specification.rb:60:in
`establish_connection'
  from /Users/mikel/.gem/ruby/1.8/gems/activerecord-3.0.0.beta/lib/active_record/connection_adapters/abstract/connection_specification.rb:55:in 
`establish_connection'
  from /Users/mikel/.gem/ruby/1.8/gems/activerecord-3.0.0.beta/lib/active_record/railtie.rb:45
...

This confused me for a second, I was sure that the pg gem was installed on my system, and the following confirmed it for me:

mikel@baci.lindsaar.net ~
 $ gem list pg

*** LOCAL GEMS ***

pg (0.8.0)

OK, but the rails app was complaining that it couldn’t find it. At this point, I did a bit of a double take, then a “D’Uh” moment hit me, bundler does not equal rubygems.

This is an important datum, Bundler is a library management tool, and it allows you to totally bypass the rubygems on your system.

So, first things first, bundler gives you some tools:

 $ bundle
Tasks:
  bundle check        # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
  bundle exec         # Run the command in context of the bundle
  bundle help [TASK]  # Describe available tasks or one specific task
  bundle init         # Generates a Gemfile into the current working directory
  bundle install      # Install the current environment to the system
  bundle lock         # Locks the bundle to the current set of dependencies, including all child dependencies.
  bundle pack         # Packs all the gems to vendor/cache
  bundle show         # Shows all gems that are part of the bundle.
  bundle unlock       # Unlock the bundle. This allows gem versions to be changed

So “bundle check” should see if my dependencies are satisfied:

 $ bundle check
The Gemfile's dependencies are satisfied

OK, so that’s not the problem, so what gems does bundler say I have installed then?

 $ bundle show
Gems included by the bundle:
  * abstract (1.0.0)
  * actionmailer (3.0.0.beta)
  * actionpack (3.0.0.beta)
  * activemodel (3.0.0.beta)
  * activerecord (3.0.0.beta)
  * activeresource (3.0.0.beta)
  * activesupport (3.0.0.beta)
  * arel (0.2.1)
  * builder (2.1.2)
  * bundler (0.9.2)
  * erubis (2.6.5)
  * i18n (0.3.3)
  * mail (2.1.2)
  * memcache-client (1.7.8)
  * mime-types (1.16)
  * rack (1.1.0)
  * rack-mount (0.4.5)
  * rack-test (0.5.3)
  * rails (3.0.0.beta)
  * railties (3.0.0.beta)
  * rake (0.8.7)
  * sqlite3-ruby (1.2.5)
  * text-format (1.0.0)
  * text-hyphen (1.0.0)
  * thor (0.13.0)
  * tzinfo (0.3.16)

And there the light turns on, no “pg” listed, which I am using inside my Rails app.

So that must mean that my Gemfile is not listing pg as a dependency, let’s check:

# Edit this Gemfile to bundle your application's dependencies.
source :gemcutter

gem "rails", "3.0.0.beta"

## Bundle edge rails:
# gem "rails", :git => "git://github.com/rails/rails.git"

# ActiveRecord requires a database adapter. By default,
# Rails has selected sqlite3.
gem "sqlite3-ruby"

## Bundle the gems you use:
# gem "bj"
# gem "hpricot", "0.6"
# gem "sqlite3-ruby", :require_as => "sqlite3"
# gem "aws-s3", :require_as => "aws/s3"

## Bundle gems used only in certain environments:
# gem "rspec", :only => :test
# only :test do
#   gem "webrat"
# end

Notice, no mention of pg? Easy, I add pg like so:

# ...
## Bundle the gems you use:
gem "pg"
# gem "hpricot", "0.6"
# gem "sqlite3-ruby", :require_as => "sqlite3"
# gem "aws-s3", :require_as => "aws/s3"
# ...

And now another check:

 $ bundle check
The Gemfile's dependencies are satisfied

All good, we can also check to see if bundle is now looking for the pg gem now:

 $ bundle show
Gems included by the bundle:
  * abstract (1.0.0)
  * actionmailer (3.0.0.beta)
  * actionpack (3.0.0.beta)
  * activemodel (3.0.0.beta)
  * activerecord (3.0.0.beta)
  * activeresource (3.0.0.beta)
  * activesupport (3.0.0.beta)
  * arel (0.2.1)
  * builder (2.1.2)
  * bundler (0.9.2)
  * erubis (2.6.5)
  * i18n (0.3.3)
  * mail (2.1.2)
  * memcache-client (1.7.8)
  * mime-types (1.16)
  * pg (0.8.0)
  * rack (1.1.0)
  * rack-mount (0.4.5)
  * rack-test (0.5.3)
  * rails (3.0.0.beta)
  * railties (3.0.0.beta)
  * rake (0.8.7)
  * sqlite3-ruby (1.2.5)
  * text-format (1.0.0)
  * text-hyphen (1.0.0)
  * thor (0.13.0)
  * tzinfo (0.3.16)

All good, there is the pg gem listed, so now that all dependencies are met, and I have the PostgreSQL database all setup, I should now be able to start the application console:

 $ rails c
Loading development environment (Rails 3.0.0.beta)
>>

And voila, we are up and running.

Packing it Up

The cool thing about bundler that sets is apart from any other library management system, is its ability to pack and lock your gem files.

Say you want to now give your Rails app to some other developer, you don’t know what versions of what gems they have running on their system, so instead, you just pack away all the gems that are working for you and then send them the whole Rails application directory, this will ship your app and all its dependencies to your co-developer, who then can just run the app as is without any other hoops.

First step is to pack your gems:

 $ bundle pack
Copying .gem files into vendor/cache
  * builder-2.1.2.gem
  * text-hyphen-1.0.0.gem
  * i18n-0.3.3.gem
  * bundler-0.9.2.gem
  * arel-0.2.1.gem
  * activemodel-3.0.0.beta.gem
  * rack-mount-0.4.5.gem
  * mime-types-1.16.gem
  * mail-2.1.2.gem
  * abstract-1.0.0.gem
  * erubis-2.6.5.gem
  * thor-0.13.0.gem
  * memcache-client-1.7.8.gem
  * rack-1.1.0.gem
  * rack-test-0.5.3.gem
  * actionpack-3.0.0.beta.gem
  * rake-0.8.7.gem
  * railties-3.0.0.beta.gem
  * sqlite3-ruby-1.2.5.gem
  * activerecord-3.0.0.beta.gem
  * text-format-1.0.0.gem
  * actionmailer-3.0.0.beta.gem
  * tzinfo-0.3.16.gem
  * activesupport-3.0.0.beta.gem
  * activeresource-3.0.0.beta.gem
  * rails-3.0.0.beta.gem

This now has put every gem that my rails app depends on into the vendor/gems directory, you can confirm this by checking out vendor/cache which shows all the gem files listed.

You can then simply zip up the whole package and send it to your co-developer (or use Git or whatever means you love), your opposite number then unpacks the entire directory, goes to the root of it and types:

 $ bundle install
Installing abstract (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing actionmailer (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing actionpack (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activemodel (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activerecord (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activeresource (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activesupport (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing arel (0.2.1) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing builder (2.1.2) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing bundler (0.9.3) from system gems 
Installing erubis (2.6.5) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing i18n (0.3.3) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing mail (2.1.2) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing memcache-client (1.7.8) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing mime-types (1.16) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rack (1.1.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rack-mount (0.4.5) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rack-test (0.5.3) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rails (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing railties (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rake (0.8.7) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing sqlite3-ruby (1.2.5) from .gem files at /Users/mikel/Code/app/vendor/cache with native extensions 
Installing text-format (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing text-hyphen (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing thor (0.13.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing tzinfo (0.3.16) from .gem files at /Users/mikel/Code/app/vendor/cache 
Your bundle is complete!

Now your co-developer has installed every gem they need to start your Rails application on their system, all sitting right within the Rails app.

Simply, this rocks.

Lock ‘n’ Load

But you would have noticed that when we specified the pg gem above, we did not specify a version, bundler helpfully grabbed the most recent one we had installed and shipped that.

But when you are delopying an application to a production server, you don’t want approximates on Gem versions, you want what works. You don’t want “Well, gem xyz is now version 0.9, it was working on 0.8.2, so it should be ok.”

Bundler handles this problem as well, by locking.

Again, standing in the root of your app, just run bundle lock:

 $ bundle lock
The bundle is now locked. Use `bundle show` to list the gems in the environment.

What this command does is make a Gemfile.lock file in your application’s root directory which looks like this:

--- 
dependencies: 
- rails: = 3.0.0.beta
- sqlite3-ruby: ">= 0"
- pg: ">= 0"
specs: 
- text-hyphen: 
    version: 1.0.0
- builder: 
    version: 2.1.2
- i18n: 
    version: 0.3.3
- bundler: 
    version: 0.9.3
- arel: 
    version: 0.2.1
- activemodel: 
    version: 3.0.0.beta
- rack-mount: 
    version: 0.4.5
- abstract: 
    version: 1.0.0
- erubis: 
    version: 2.6.5
- mime-types: 
    version: "1.16"
- mail: 
    version: 2.1.2
- thor: 
    version: 0.13.0
- memcache-client: 
    version: 1.7.8
- rack: 
    version: 1.1.0
- rack-test: 
    version: 0.5.3
- actionpack: 
    version: 3.0.0.beta
- rake: 
    version: 0.8.7
- railties: 
    version: 3.0.0.beta
- sqlite3-ruby: 
    version: 1.2.5
- text-format: 
    version: 1.0.0
- actionmailer: 
    version: 3.0.0.beta
- activerecord: 
    version: 3.0.0.beta
- pg: 
    version: 0.8.0
- activeresource: 
    version: 3.0.0.beta
- rails: 
    version: 3.0.0.beta
- tzinfo: 
    version: 0.3.16
- activesupport: 
    version: 3.0.0.beta
hash: b75772b5511703b25aded771d7ca687836679fef
sources: 
- Rubygems: 
    uri: http://gemcutter.org
- Path: 
    glob: "{*/,}*.gemspec"
    path: /Users/mikel/rails_programs/rails

A couple of things to notice about this, see that the pg gem has now been locked to version 0.8.0? This means that your application will now ONLY start if it has access to this version, of course, if the target platform does not have version 0.8.0 installed, a simple bundle install will fix this.

The Gemfile.lock also has a hash in it, this is a SHA of your Gemfile, this is there so that if you change your Gemfile to add a new gem, say hpricot, then bundler will complain (rightly so) as follows:

 $ bundle check
You changed your Gemfile after locking. Please relock using `bundle lock`

OK, so we run bundle lock again:

 $ bundle lock
The bundle is already locked, relocking.
Could not find gem 'hpricot (= 0.6, runtime)' in any of the sources.
Run `bundle install` to install missing gems

Well, good, I like being lead by the hand…

 $ bundle install
Fetching source index from http://gemcutter.org
Resolving dependencies
Installing abstract (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing actionmailer (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing actionpack (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activemodel (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activerecord (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activeresource (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing activesupport (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing arel (0.2.1) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing builder (2.1.2) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing bundler (0.9.3) from system gems 
Installing erubis (2.6.5) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing hpricot (0.6) from rubygems repository at http://gemcutter.org with native extensions 
Installing i18n (0.3.3) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing mail (2.1.2) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing memcache-client (1.7.8) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing mime-types (1.16) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing pg (0.8.0) from system gems 
Installing rack (1.1.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rack-mount (0.4.5) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rack-test (0.5.3) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rails (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing railties (3.0.0.beta) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing rake (0.8.7) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing sqlite3-ruby (1.2.5) from .gem files at /Users/mikel/Code/app/vendor/cache with native extensions 
Installing text-format (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing text-hyphen (1.0.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing thor (0.13.0) from .gem files at /Users/mikel/Code/app/vendor/cache 
Installing tzinfo (0.3.16) from .gem files at /Users/mikel/Code/app/vendor/cache 
Your bundle is complete!

Good, see bundler did what it was meant to and grabbed the hpricot gem for us. Mow that we have installed, lets bundle check again:

 $ bundle check
The Gemfile's dependencies are satisfied

All good, so now we can bundle pack (which is optional as you can just lock off the system gems installed):

 $ bundle pack
Copying .gem files into vendor/cache
  * text-hyphen-1.0.0.gem
  * hpricot-0.6.gem
  * builder-2.1.2.gem
  * i18n-0.3.3.gem
  * bundler-0.9.3.gem
  * arel-0.2.1.gem
  * activemodel-3.0.0.beta.gem
  * mime-types-1.16.gem
  * mail-2.1.2.gem
  * abstract-1.0.0.gem
  * erubis-2.6.5.gem
  * thor-0.13.0.gem
  * sqlite3-ruby-1.2.5.gem
  * rake-0.8.7.gem
  * railties-3.0.0.beta.gem
  * memcache-client-1.7.8.gem
  * rack-1.1.0.gem
  * rack-test-0.5.3.gem
  * rack-mount-0.4.5.gem
  * actionpack-3.0.0.beta.gem
  * pg-0.8.0.gem
  * activerecord-3.0.0.beta.gem
  * text-format-1.0.0.gem
  * actionmailer-3.0.0.beta.gem
  * activeresource-3.0.0.beta.gem
  * rails-3.0.0.beta.gem
  * tzinfo-0.3.16.gem
  * activesupport-3.0.0.beta.gem

Awesome, hpricot was packed. Now we can bundle lock:

 $ bundle lock
The bundle is now locked. Use `bundle show` to list the gems in the environment.

The app is now all good and ready to deploy again.

If you look at the Gemfile.lock file, you will find the hash has changed from before:

# Was before:
hash: b75772b5511703b25aded771d7ca687836679fef
#
# Is now:
hash: 613e95d88b2b3e09185c89572cff3291ecaa45cf

Summary

One thing you should remember is that packing and locking your gems with bundler are optional. You don’t have to pack your gems to lock, and you don’t have to lock to install. The point of packing and locking is that your application becomes a self contained repository of all the gems you need to run your application.

I hope the above gives you a good introduction to this awesome library manager.

blogLater

Mikel

Helping out in Haiti

2010-02-05T15:03:33+00:00

Lots of people are flying to Haiti to help out from all walks of life, good to see some Scientologists getting in there as well.

Found this video today on MSNBC, shows some of our Volunteer ministers from America down in Haiti.

Another one of our members from Australia just flew out to Haiti as well.

We have a volunteer minister program all over the world, it’s actually the largest independent relief force in the world, something you don’t hear a lot in the news, but we do a lot of good around the world.

blogLater

Mikel

Watch your self

2010-02-05T02:36:49+00:00

Blocks and closures are probably the most powerful, and least understood part of the Ruby programming language, combined instance_eval, it can create some unintuitive bugs.

Background

In my Mail library for Ruby, I have made use of instance_eval to provide a domain specific language for email, this allows me to offer the following as valid Ruby code:

m = Mail.new do
       to 'mikel@test.lindsaar.net'
     from 'you@test.lindsaar.net'
  subject 'This is a valid email'
     body "When this block closes it will " +
          "return an email message."
end

This bit of code is calling the #new method on the Mail module, which accepts a block. This which creates a new Mail::Message, passing the block of ruby code which in turn calls instance_eval on itself, passing the Ruby code that is inside the block of code that we wrote between the do and end keywords.

The newly created Mail::Message now runs that block on itself, calling the to(), from(), subject() and body() methods in turn, passing the strings we gave it.

Once done, the Mail module then calls deliver on the Mail::Message and the email is sent on its way.

The code that makes the above happen is inside the Mail library:

module Mail

  class Message
    def initialize
      # ... initialization
      if block_given?
        instance_eval(&block)
      end
    end
  end
  
  def Mail.new(*args, &block)
    Mail::Message.new(args, &block)
  end

end

Gotcha

All of the above is pretty straight forward and it works pretty much as you would expect, but there is one use case that will trip you up.

Suppose you don’t want to pass in strings to your Mail object? Suppose you want to pass in instance variables instead? Something like this:

@text = "When this block closes it will " +
        "return an email message."
@to   = 'mikel@test.lindsaar.net'
@subject = "This is a valid email"

Mail.new do
       to @to
     from 'you@test.lindsaar.net'
  subject @subject
     body @text_body
end

This ruby code will run successfully, but it will not return what you think. This is because the instance variables you pass into the block are evaluated within the scope of the Mail::Message and inside the Mail::Message, text</tt>, <tt>to and @subject all evaluate to nil.

This is where you need to watch your self. Inside of the Mail.new do.. end block, self effectively becomes the Mail::Message, and the mail message has not defined the instance variables you are passing in.

Solutions

To get around this, you can do a number of things.

First, you can use methods instead of instance variables:

def body_text
  "When this block closes it will " +
  "return an email message."
end

def to_address
  'mikel@test.lindsaar.net'
end

def default_subject
  "This is a valid email"
end

Mail.new do
       to to_address
     from 'you@test.lindsaar.net'
  subject default_subject
     body body_text
end

This is obviously a lot more code, but in practice you usually have the to, subject and body text already being generated by methods inside your code, so it can work.

The other solution is a lot more simple, don’t use a block:

@text = "When this block closes it will " +
        "return an email message."
@to   = 'mikel@test.lindsaar.net'
@subject = "This is a valid email"

m = Mail.new
m.to @to
m.from 'you@test.lindsaar.net'
m.subject @subject
m.body @text

Which is arguably less pretty, but you are not going to get caught out.

blogLater

Mikel

Is Rails 3.0 a Game Changer?

2010-02-04T00:38:07+00:00

With Rails 3 on its way to release, and all it is bringing in terms of features and refactorization, some might be wondering, is it a “game changer”?

Well, the simple answer to that is, “Who cares?”

The important question is not “will Rails 3 revolutionise the web development industry?” but a much more pragmatic one of “what does Rails 3 offer that will help me?”.

Or more importantly “Will upgrading my site to Rails 3 be worth it!?”

And I feel the honest answer to that last question is – yes.

But here is the pinch, the benefit you and your site will gain from upgrading will not be realised from the improvements in the latest way to validate a model, or the new query syntax, because, let’s be real here, if you are upgrading, then whatever you have right now is most likely working, so even though Rails 3 gives you another three or four ways to skin the problem, the problem will just be skinned as it was before, regardless of elegance.

Sure there are gains to be had from cleaning up horrid old find methods and migrating to a chain-able relation syntax. Or cleaner, more usable, mailers from the new ActionMailer syntax. But all of these are marginal improvements, they help, sure, but for an existing operational site, don’t give a huge amount of benefit.

The real benefit I think your site will gain from Rails 3 comes down to just three killer features; HTML 5, Modularity and speed.

Let me explain myself here before you all go OMGWTFKTHXBAI!?!

HTML 5

HTML 5 is the new black.

There, I’ve said it.

There are lots of ideas but nothing really concrete on how HTML 5 is going to change the web screen-scape, there is definitely movement at the station, but the word is not quite around yet and there are still a lot of people still looking at each other going “hmmm”.

The latest release from Apple show them positioning their products to take full advantage of HTML 5, and a lot can be done with this new standard, it may well become the flash killer many people are hoping.

The real exciting thing about HTML 5 though is its capabilities in the mobile device world. HTML 5 and mobile devices are made for each other, literally, and this works NOW. It’s not something that might work when the browsers get around to it, it is a feature that you can leverage instantly.

For us Rails developers, the cool thing is v3 has now moved in this direction. With its HTML 5 support now baked into Action Pack helpers and a HTML 5 viewpoint on how to present web pages, it is gearing up for the future, whatever that may be.

Getting your app updated to version 3 will not suddenly make the sky open up with the HTML 5 Gods shining down at you and driving more traffic at your site, but it will place you in a very good position to take advantage, quickly, of whatever will happen, and leverage the mobile market like never before.

Modularity

Rails 3 provides a modular framework that is, wait for it, extensible. All of the internals in Rails received a massive clean out turning them into, essentially, the same type of object as any other Rails plugin. Calling Action Mailer or Active Record “plugins”, isn’t really fair considering how functional they are, but really, when you get down to it, that’s all they are. They are just parts of the Rails framework, that can be swapped out with other plugins.

You have already seen alternatives for Active Record (Datamapper, Sequel, Mongomapper et al) but traditionally, getting these sorts of plugins working in Rails has been a sparring match with Action Pack and this pain was the motivation behind creating Active Model, the first step on modularising the Rails framework.

But think about it for a second, with a complete Plugin API, documented, showing all the hooks, features and methods your new plugin can take advantage of, and with that API having full, defined access to the entire Rails stack from boot to shutdown, your opportunities to create or take advantage of something incredible in this space have just increased several thousand fold.

Want to make a killer admin interface? Want to create a “plug in” blog? Need a forum feature in your Rails app? You now have defined tools to make that happen.

And that is reason enough to upgrade to Rails 3. If your app is not on Rails 3, you can’t take advantage of the community of functionality that is going to grow up around this platform as we move forward documenting and establishing this community.

But if you are already on Rails 3, and someone releases a new gem that provides you a new and amazing way to zig when everyone else is zagging, then, you will be in a position to implement rapidly.

Speed

I am not talking about how fast a Rails app can serve up a page of HTML here, although, Rails has had a ton of improvements in that area, I am talking about how fast you and your application can react to the changes occurring on the web today.

HTML 5 support and Modularity bring you agility and speed. You will be able to react to a changing web rapidly, and being able to move fast without baggage holding you down translates into $$ in your pocket.

Now that I have written the above, don’t get me wrong, I am not downplaying the massive amount of work done to improve Rails as a framework, and I am developing an application on Rails 3 right now that has been an absolute dream compared with developing on Rails 2.×.

But I do think, at the end of all this, you too should be able to answer the question of “Will upgrading my site to Rails 3 be worth it!?” with just one word.

Yes.

blogLater

Mikel

Where did the scripts go?

2010-02-03T19:46:00+00:00

The recent commit removing the contents of the script directory streamlines rails somewhat. But there were a lot of files in that directory, this is a quick cheat sheet on what replaces what…

The script directory used to contain

Old Script File	How to use now	Shortcut Command
`about`	rake about
`server`	rails server	rails s
`console`	rails console	rails c
`dbconsole`	rails dbconsole	rails db
`generate`	rails generate	rails g
`destroy`	rails destroy
`performance/benchmark`	rails benchmark
`performance/profiler`	rails profiler
`plugin`	rails plugin
`runner`	rails runner

As you can see from the above, the server, console, dbconsole and generate parameters also have shortcut aliases.

When you run the rails command from within a Rails application directory, the above commands work, however, if you run the rails command from outside a Rails application directory, then the usual Rails initialization command works in the format of rails/railties/bin/rails APP_PATH [options]

Note with the new 3.0 rails command, the APP_NAME has been changed to an APP_PATH and any options now come at the end, not before. APP_PATH allows you to initialise a new Rails application at some other path name and uses the last part of the path name for your application.

One word of warning, if you are running the Rails 3.0 Beta using the —dev flag from a clone of the Rails source tree, then be sure to call script/rails otherwise the rails binary that is run will be from your system gems, and you will end up initialising a new Rails application inside your new Rails 3 app directory.

blogLater

Mikel

validates :rails_3, :awesome => true

2010-01-31T12:17:00+00:00

The new validation methods in Rails 3.0 have been extracted out to Active Model, but in the process have been sprinkled with DRY goodness…

As you would know from Yehuda’s post on Active Model abstraction, in Rails 3.0, Active Record now mixes in many aspects of Active Model, including the validates modules.

Before we get started though, your old friends still exist:

validates_acceptance_of
validates_associated
validates_confirmation_of
validates_each
validates_exclusion_of
validates_format_of
validates_inclusion_of
validates_length_of
validates_numericality_of
validates_presence_of
validates_size_of
validates_uniqueness_of

Are still around and not going anywhere, but Rails version 3 offers you some cool, nay, awesome alternatives:

Introducing the validates method

The Validates method accepts an attribute, followed by a hash of validation options.

Which means you can type something like:

class Person < ActiveRecord::Base
  validates :email, :presence => true
end

The options you can pass in to validates are:

:acceptance => Boolean
:confirmation => Boolean
:exclusion => { :in => Ennumerable }
:inclusion => { :in => Ennumerable }
:format => { :with => Regexp }
:length => { :minimum => Fixnum, maximum => Fixnum, }
:numericality => Boolean
:presence => Boolean
:uniqueness => Boolean

Which gives you a huge range of easily usable, succinct options for your attributes and allows you to place your validations for each attribute in one place.

So for example, if you had to validate name and email, you might do something like this:

# app/models/person.rb
class User < ActiveRecord::Base
  validates :name,  :presence => true, 
                    :length => {:minimum => 1, :maximum => 254}
                   
  validates :email, :presence => true, 
                    :length => {:minimum => 3, :maximum => 254},
                    :uniqueness => true,
                    :format => {:with => /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i}
  
end

This allows us to be able to look at a model and easily see the validations in one spot for each attribute, win for code readability!

Extracting Common Use Cases

However, the :format => {:with => EmailRegexp} is a bit of a drag to retype everywhere, and definitely fits the idea of a reusable validation that we might want to use in other models.

And what if you wanted to use a really impressive Regular Expression that takes more than a few characters to type to show that you know how to Google?

Well, validations can also except a custom validation.

To use this, we first make an email_validator.rb file in Rails.root’s lib directory:

# lib/email_validator.rb
class EmailValidator < ActiveModel::EachValidator

  EmailAddress = begin
    qtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]'
    dtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]'
    atom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-' +
      '\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+'
    quoted_pair = '\\x5c[\\x00-\\x7f]'
    domain_literal = "\\x5b(?:#{dtext}|#{quoted_pair})*\\x5d"
    quoted_string = "\\x22(?:#{qtext}|#{quoted_pair})*\\x22"
    domain_ref = atom
    sub_domain = "(?:#{domain_ref}|#{domain_literal})"
    word = "(?:#{atom}|#{quoted_string})"
    domain = "#{sub_domain}(?:\\x2e#{sub_domain})*"
    local_part = "#{word}(?:\\x2e#{word})*"
    addr_spec = "#{local_part}\\x40#{domain}"
    pattern = /\A#{addr_spec}\z/
  end

  def validate_each(record, attribute, value)
    unless value =~ EmailAddress
      record.errors[attribute] << (options[:message] || "is not valid") 
    end
  end
  
end

As each file in the lib directory gets loaded automatically by Rails, and as our class inherits from ActiveModel::EachValidator the class name is used to create a dynamic validator that you can then use in any object that makes use of the ActiveModel::Validations mix in, such as Active Record objects.

The name of the dynamic validation option is based on whatever is to the left of “Validator” down-cased and underscorized.

So now in our User class we can simply change it to:

# app/models/person.rb
class User < ActiveRecord::Base
  validates :name,  :presence => true, 
                    :length => {:minimum => 1, :maximum => 254}
                   
  validates :email, :presence => true, 
                    :length => {:minimum => 3, :maximum => 254},
                    :uniqueness => true,
                    :email => true
  
end

Notice the :email => true call? This is much cleaner and simple, and more importantly, reusable.

Now in our console, we will see something like:

 $ ./script/console 
Loading development environment (Rails 3.0.pre)
?> u = User.new(:name => 'Mikel', :email => 'bob')
=> #<User id: nil, name: "Mikel", email: "bob", created_at: nil, updated_at: nil>
>> u.valid?
=> false
>> u.errors
=> #<OrderedHash {:email=>["is not valid"]}>

With our custom error message “is not valid” showing up in the email.

Class Wide Validations

But what if you had, say, three different models, users, visitors and customers, all of which shared some common validations, but were different enough that you had to separate them out?

Well, you could use another custom validator, but pass it to your models as a validates_with call:

# app/models/person.rb
class User < ActiveRecord::Base
  validates_with HumanValidator
end

# app/models/person.rb
class Visitor < ActiveRecord::Base
  validates_with HumanValidator
end

# app/models/person.rb
class Customer < ActiveRecord::Base
  validates_with HumanValidator
end

You could then make a file in your lib directory like so:

class HumanValidator < ActiveModel::Validator

  def validate(record)
    record.errors[:base] << "This person is dead" unless check(human)
  end

  private

    def check(record)
      (record.age < 200) && (record.age > 0)
    end
  
end

Which is an obviously contrived example, but would produce this result in our console:

$ ./script/console 
Loading development environment (Rails 3.0.pre)
>> u = User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil>
>> u.valid?
=> false
>> u.errors
=> #<OrderedHash {:base=>["This person is dead"]}>

Trigger times

As you would expect, any validates method can have the following sub options added to them:

:on
:if
:unless
:allow_blank
:allow_nil

Each of these can take a call to a method on the record itself. So we could have:

class Person < ActiveRecord::Base
  
  validates :post_code, :presence => true, :unless => :no_postcodes?

  def no_postcodes?
    ['TW'].include?(country_iso)
  end
  
end

I think you can see this gives you a huge amount of flexibility.

Credits

Kudos to Jamie Hill, José Valim and Joshua Peek for getting the patch in.

New Rails Version 3.0 Guides Online

2010-01-29T16:53:00+00:00

I am going through and updating a lot of the guides for Rails. As I do each one, I will update this post.

Rails 3 has a lot of changes. Don’t be fooled, the core team has been hard at work for the last year ever since the Merb and Rails announcement.

You can think of Rails 3 as a massive refactoring and extraction project. The amount of spring cleaning is, to put it bluntly, phenomenal.

So as I go through each guide and update it, and it gets published, I’ll link to it here, so you can all follow along :) I would also like all the feed back in can get on these. You can email me, send me a tweet or comment here.

Getting Started with Rails

Getting started with Rails was, appropriately, the first guide that was updated. This was different enough that the version 2 guide simply did not work on Rails 3. You can also find all the code for the getting started guide at my Getting Started Code github repository.

Layouts and Rendering in Rails

Layouts and Rendering in Rails was the next guide updated. Again, a lot of changes in Rails 3, highlights on the HTML 5 implementation, handling of the new video_tag and audio_tag helper methods and a big gotcha on partial rendering (you’ll have to read the guide for all the juicy bits, but enough to say that a lot LESS local variables get magically defined in partials now.

Next Up

I am mid way the Action Mailer guide now that the code has been updated to the new API. Check back soon.

blogLater

Mikel

New ActionMailer API in Rails 3.0

2010-01-26T12:13:00+00:00

Action Mailer has long been the black sheep of the Rails family. Somehow, through many arguments, you get it doing exactly what you want. But it takes work! Well, we just fixed that.

Action Mailer now has a new API.

But why? Well, I had an itch to scratch, I am the maintainer for TMail, but found it very hard to use well, so I sat down and wrote a really Ruby Mail library, called, imaginatively enough, Mail

But Action Mailer was still using TMail, so then I replaced out TMail with Mail in Action Mailer

And now, with all the flexibility that Mail gives us, we all thought it would be a good idea to re-write the Action Mailer DSL. So with a lot of ideas thrown about between David, Yehuda and myself, we came up with a great DSL.

I then grabbed José Valim to pair program together (with him in Poland to me in Sydney!) on ripping out the guts of Action Mailer and replacing it with a lean, mean mailing machine.

This was merged today.

So what does this all mean? Well, code speaks louder than words, so:

Creating Email Messages:

Instead of this:

 class Notifier < ActionMailer::Base
   def signup_notification(recipient)
     recipients      recipient.email_address_with_name
     subject         "New account information"
     from            "system@example.com"
     content_type    "multipart/alternative"
     body            :account => recipient

     part :content_type => "text/html",
       :data => render_message("signup-as-html")

     part "text/plain" do |p|
       p.body = render_message("signup-as-plain")
       p.content_transfer_encoding = "base64"
     end
     
     attachment "application/pdf" do |a|
       a.body = generate_your_pdf_here()
     end

     attachment :content_type => "image/jpeg",
       :body => File.read("an-image.jpg")
     
   end
 end

You can do this:

class Notifier < ActionMailer::Base
  default :from => "system@example.com"
  
  def signup_notification(recipient)
    @account = recipient

    attachments['an-image.jp'] = File.read("an-image.jpg")
    attachments['terms.pdf'] = {:content => generate_your_pdf_here() }

    mail(:to => recipient.email_address_with_name,
         :subject => "New account information")
  end
end

Which I like a lot more :)

Any instance variables you define in the method become available in the email templates, just like it does with Action Controller, so all of the templates will have access to the @account instance var which has the recipient in it.

The mail method above also accepts a block so that you can do something like this:

def hello_email
  mail(:to => recipient.email_address_with_name) do |format|
    format.text { render :text => "This is text!" }
    format.html { render :text => "<h1>This is HTML</h1>" }
  end
end

In the same style that a respond_to block works in Action Controller.

Sending Email Messages:

Additionally, sending messages has been simplified as well. A Mail::Message object knows how to deliver itself, so all of the delivery code in Action Mailer was simply removed and responsibility given to the Mail::Message.

Instead of having magic methods called deliver_* and create_* we just call the method which returns a Mail::Message object, and you just call deliver on that:

So this:

Notifier.deliver_signup_notification(recipient)

Becomes this:

Notifier.signup_notification(recipient).deliver

And this:

message = Notifier.create_signup_notification(recipient)
Notifier.deliver(message)

Becomes this:

message = Notifier.signup_notification(recipient)
message.deliver

You still have access to all the usual types of delivery agents though, :smtp, :sendmail, :file and :test, these all work as they did with the prior version of ActionMailer.

Receiving Emails

This has not changed, except now you get a Mail::Message object instead of a TMail object.

Mail::Message will be getting a :reply method soon which will automatically map the Reply related fields properly. Once this is done, we will re-vamp receiving emails as well to simplify.

Old API

And… of course, if you still “like the old way”, the new Action Mailer still supports the old API and all the old tests still pass. We have moved everything relating to the old API into deprecated_api.rb and this will be removed in a future release of Rails.

Summary

With Mail and this refactor, Action Mailer has now finally become just a DSL wrapper between Mail and Action Controller.

blogLater

Mikel

Mail gem version 2 released

2010-01-23T17:05:00+00:00

The past month has seen a flurry in activity on the Mail gem but I just pushed 2.0.3 to GemCutter, it is quite a release!

If you haven’t heard of mail, you can get some background here, here, here and here

Mail is a very Ruby way to handle emails.

Version 2.0.3 is the first gem release I have in the last couple of weeks, this is because I went through and (in good BDD style) refactored major parts of the Mail gem so it handles better.

Some of the major things were:

SMTP Delivery Agent revamped

I went through the SMTP delivery agent and cleaned it up, also adding examples for how you use Mail with GMail and MobileMe so there is no more guess work here.

Delivery agents are now instance based

This means that each mail object that you instantiate can have its own delivery method. Why is this important?

Well, say you are writing a web based email client for multiple users, but each user has their own SMTP hosts, when you make a mail object for that user, you could assign the delivery method for that user to that mail object, then delivery is just calling .deliver! on the mail object, and away it goes.

There is still default class wide settings for all the major delivery agents (SMTP, Sendmail and File) however, you can now over ride these.

mail1 = Mail.new
mail1.delivery_method #=> #<Mail::SMTP:0x101381c18 @setting
mail2 = Mail.new
mail2.delivery_method :sendmail
mail2.delivery_method #=> #<Mail::Sendmail:0x101381c18 @setting
mail1.delivery_method #=> #<Mail::SMTP:0x101381c18 @setting

Attachments are now just parts

Before, an Attachment had its own object type in Mail. This was nice and all, but was just added cruft that got in there during the BDD cycle. I ripped out the entire attachment class, and an attachment is now just a plain old Mail::Part. This makes the code simpler, which is good for everyone.

Mail also now has a very cool attachments API:

mail = Mail.new
mail.attachments #=> []
mail.attachments['filename.jpg'] = File.read('filename.jpg')
mail.attachments['file.pdf'] = {:content_type => 'application/x-pdf',
                                :content => File.read('file')
mail.attachments.length #=> 2
mail.attachments[0].filename #=> 'filename.jpg'
mail.attachments['filename.jpg'] #=> <# Mail::Part, filename = 'filename.jpg' ...>

Yes, that is an ArrayHashThingy™ class, and, it rocks :) It is actually an AttachmentsList object that inherits from Array and implements a custom [] class.

Thanks to David and Yehuda who were brainstorming on the new ActionMailer 3.0 API with me, which I used for inspiration for this implementation. (more on the ActionMailer 3.0 API that I am pair programming with José later :)

Mail returns default values for fields, that can be modified

Mail returns an array of address specs when you call mail.to and would re-initialize that array with new values when you called mail.to=.

However, this array object was just a result of a method, it was not a representation of the addresses within the address field, so then doing mail.to << value would seem to work (no error) but the address would get lost, for example:

# Old (unintuitive method)
mail = Mail.new("To: mikel@test.lindsaar.net")
mail.to #=> ['mikel@test.lindsaar.net']
mail.to << 'ada@test.lindsaar.net'
mail.to #=> ['mikel@test.lindsaar.net']

This now works on all Address fields that can take more than one address, so

# New (intuitive) method
mail = Mail.new("To: mikel@test.lindsaar.net")
mail.to #=> ['mikel@test.lindsaar.net']
mail.to << 'ada@test.lindsaar.net'
mail.to #=> ['mikel@test.lindsaar.net', 'ada@test.lindsaar.net']

Thanks to Sam for suggesting this feature.

Access returned to the Address objects

When you call mail.to you get a list of address spec strings (‘mikel@test.lindsaar.net’ for example), but it will not give you the display name, or formatted address etc.

To handle this, you can now call mail[:to] to get the actual ToField object, and then you can call #display_names, #formatted, and #addrs, the last of which will give you the actual Address objects in an array (the original behaviour of Mail), like so:

mail = Mail.new("To: Mikel Lindsaar <mikel@test.lindsaar.net>")
mail.to #=> ['mikel@test.lindsaar.net']
to = mail[:to]  #=> #<Mail::Field:0x10137c718...
to.addrs #=> [#<Mail::Address:2165620900 Address: |mikel@test.lindsaar.net| >]
to.addrs.each do |addr|
  puts "Formatted: #{addr.format}"
  puts "Display:   #{addr.display_name}"
  puts "Address:   #{addr.address}"
end
# Produces:
Formatted: Mikel Lindsaar <mikel@test.lindsaar.net>
Display:   Mikel Lindsaar
Address:   mikel@test.lindsaar.net
=> [#<Mail::Address:2165518560 Address: |Mikel Lindsaar <mikel@test.lindsaar.net>| >]

Thanks to Karl for suggesting this would be handy :)

More methods added to address fields

You can also access an array of the formatted, display_names or addresses directly from address fields:

mail = Mail.new("To: Mikel Lindsaar <mikel@test.lindsaar.net>")
mail[:to].addresses   
#=> ["mikel@test.lindsaar.net"]
mail[:to].formatted
#=> ["Mikel Lindsaar <mikel@test.lindsaar.net>"]
mail[:to].display_names
#=> ["Mikel Lindsaar"]

Remaining Stuff

There are a lot of other small bug fixes, parts now get sorted recursively on encode, body objects will accept an array of strings and call join on them, and many other small things that are in the commit and change logs. Check it out.

As always, tickets (and patches) are always welcome, I use GitHub’s Tracker for this. Or you can talk to us on the Mail Google Group

Happy Mailing!

blogLater

Mikel

How to rename a Rails 3 Application

2010-01-19T14:01:00+00:00

Renaming a Rails 3 application is something you have to think about now. No, really… :)

When you create a new Rails 3.0 app with “rails app_name” Rails will create the application for you like before, but with a major difference.

It will Classify your “app_name” and use this as the Ruby name space for your application.

So if you do:

rails new app_name

Then your Rails application will have sprinklings of AppName throughout the tree.

If you later decide that your application should be called something more specific than “AppName” you need to replace out AppName from the following files:

config/application.rb
config/environment.rb
config/environments/development.rb
config/environments/test.rb
config/environments/production.rb
config/routes.rb
config.ru
initializers/secret_token.rb
initializers/session_store.rb

Of course, if you are using TextMate, a simple Project wide search and replace for AppName with your new name, should do the trick. But it is something to be aware of.

blogLater

Mikel

Edited 21 Sept 2010: to update per reader comments below.

Rails 3.0 Examples

2010-01-19T13:38:00+00:00

Rails 3.0 has a lot of new features. Getting to understand them can be a challenge. I made a Rails 3.0 repository on github to help everyone get to know some of the new ActiveModel API…

It is at git://github.com/mikel/rails-examples/ and has instructions on how to download it and get it running.

It is actually an entire Rails 3.0 App, ready to run. So you just need to clone it, follow the four steps given in the README and you will have Rails 3.0 running on your system.

The models directory contains a bunch of “_person” models that show off each main module of the ActiveModel API piece by piece. The implementations are minimal on purpose to show you what you need to get the thing working… The instant gratification thing :)

Please check it out and let me know what you think, or improvements we can make.

One note, you should update the bundler gem if you are on a bundler version 0.7 or below.

blogLater

Mikel