Jeff Dean - Ruby on Rails Programmer

Serving a NodeJS coffee-script app with apache and forever

2012-03-17T06:47:22+00:00

NodeJS seems to be all the rage these days so I thought I'd try to test-drive an app, then deploy it on my CentOS server.

In this post I'll describe how I set the server up for a very simplistic deployment with Apache and Forever.

I should start by saying that I took all of this from these blog posts:

To start with, I installed node:

cd /tmp
GIT_SSL_NO_VERIFY=true sudo git clone --depth 1 https://github.com/joyent/node.git
cd node
git checkout v0.6.12
./configure --prefix=/usr/local
make
make install

Then I installed NPM, the node package manager:

cd /tmp
git clone git://github.com/isaacs/npm.git
cd npm

I wrote the app in CoffeeScript, so I decided to install that globally:

cd apps/myapp/current
npm install -d
sudo npm install -g coffee-script

I setup a VirtualHost to proxy the non-socket requests:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

<VirtualHost *:80>
  ServerName myapp.com
  ServerAlias www.myapp.com

  ProxyRequests off

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  <Location />
    ProxyPass http://localhost:8080/
    ProxyPassReverse http://localhost:8080/
  </Location>
</VirtualHost>

To get the node app started, and keep it running, I used Forever:

sudo npm install -g forever
NODE_ENV=production forever start -c coffee server.coffee

Once I restarted apache, voila! The app worked! However, since sockets wouldn't work, I had to configure the app to make the browser's sockets point directly to the port that node runs on. To do so, here's what my server.coffee looks like:

express = require 'express'
exports.app = app = express.createServer()
io = require('socket.io').listen(app)

host = null
port = null

app.configure ->
  app.set('views', __dirname + '/app/views')
  app.set('view engine', 'jade')
  app.use(express.bodyParser())
  app.use(express.methodOverride())
  app.use(express.static(__dirname + '/public'))

app.configure 'development', ->
  host = 'localhost'
  port = 3000
  # ...

app.configure 'test', ->
  host = 'localhost'
  port = 3000
  # ...

app.configure 'production', ->
  host = 'myapp.com'
  port = 8080
  # ...

app.get '/javascripts/dynamic/javascript-host.js', (req, res) ->
  res.header('Content-Type', 'text/javascript')
  res.send("window.SocketConfig = {host: '#{host}', port: #{port} };")

io.sockets.on 'connection', (socket) ->
  socket.on 'publish', (data) ->
    socket.broadcast.emit "someMessage", data

app.listen port

Note that I'm serving up a dynamic javascript file at /javascripts/dynamic/javascript-host.js which will supply the client with the correct host and port to listen on.

Then I included that js file like I would any other js file in jade:

script(type='text/javascript', src='/javascripts/dynamic/javascript-host.js')

The browser-side socket code looks like this (in CoffeeScript):

socket = io.connect("http://#{SocketConfig.host}:#{SocketConfig.port}")

socket.on "connect", ->
  #  do something

This configuration is nowhere near production ready. The biggest problem I see is that there is a single node process, so I'll have to add more, then figure out how to load balance on that port with something that understands sockets, like haproxy and also make sure that apache still proxies the other requests appropriately.

My overall first impression of deploying with node is that it's in it's infancy since so many people on the blogosphere recommend running node apps with screen or nohup. But setting up node with forever and apache was simple and fast for this toy app, and I was pleasantly surprised at how pain-free it was.

Setting up a simple, private gem server

2012-03-13T03:59:03+00:00

At Broadstripes we have a handful of gems that we use internally, but we don't want to publish them on a public site like RubyGems.org. In this post, I'll describe how I setup a simple, static gem server with basic auth and a simple capistrano recipe I added to our gems in order to publish them.

The basics of gem sources

When you install gems, it looks through all of your various gem sources. You can see the sources like so:

gem sources

*** CURRENT SOURCES ***

http://rubygems.org/

At it's simplest, a gem server is simply a directory with some static files that looks something like this:

.
|-- Marshal.4.8
|-- Marshal.4.8.Z
|-- gems
|   |-- my-custom-gem-0.5.1.gem
|-- latest_specs.4.8
|-- latest_specs.4.8.gz
|-- prerelease_specs.4.8
|-- prerelease_specs.4.8.gz
|-- quick
|   `-- Marshal.4.8
|       |-- my-custom-gem-0.5.1.gemspec.rz
|-- specs.4.8
`-- specs.4.8.gz

As long as that root directory is located at a URL accessible to a machine with rubygems installed, it can be used as a valid gem source.

Generating the index

Generating the files necessary for the gem server is very simple. Just put create a gems directory, add your gem, and call gem generate_index

mkdir -p /path/to/virtual/host/root
cd !$
mkdir gems
cp my-custom-gem-0.5.1.gem gems
gem generate_index

And that's all there is to creating the necessary files for the gem server. You can read more here

Making it private

I chose to use basic auth over HTTPS to protect our gems, since we needed to access them from a variety of servers that were not connected via VPN.

Here's what our nginx config looks like for the gem server:

server {
  listen [::]:443;
  ssl on;
  # ssl config etc....

  location / {
    auth_basic              "Gems Web Access";
    auth_basic_user_file    /opt/nginx/conf/gems.htpasswd;
  }
}

All pretty standard stuff - since basic auth uses clear-text crednetials, we use ssl to encrypt the transmission.

Referencing the private gem server

Basic auth allow you to add the credentials in the url itself, like so:

https://username:password@gems.mydomain.com

The downside to this is that the credentials have to be stored in clear text on the machine that has rubygems installed, but for us that wasn't an issue.

So to add that as a source, just run:

gem source https://username:password@gems.mydomain.com

Pushing gems

Since the gems are on a private server, commands like gem push will not work. So I created a quick capistrano task to push the gem up, and rebuild the index. It looks something like this:

set :user, "deploy"
set :deploy_to, "/home/deploy/rails_apps/gems/"
role :gem_server, "gems.myserver.com"

task :publish, :roles => :gem_server do
  latest_gem_path = Dir.glob("*.gem").sort.last
  gem_name = File.basename(latest_gem_path)
  upload("#{latest_gem_path}", "#{current_path}/public/gems/#{gem_name}")
  run "cd #{current_path}/public && gem generate_index"
end

This simple cap recipe assumes that you have run gem build mygem.gemspec, and it grabs the latest version of the gem, pushes it to the remote server and rebuilds the index.

While this is not appropriate if your gem server has highly sensitive gems, it's a fast and simple solution for situations where you'd like to host your own private gems.

Developing locally with Oracle and Ruby on a Mac

2012-03-13T02:09:53+00:00

In this post I'll describe how you can get setup to develop an app backed by an Oracle database using Ruby on a Mac. Specifically I'll cover:

How to install and configure a pre-built VM with Oracle running
How to install the Oracle instant client on OSX Lion
How to compile a 32-bit version of Ruby 1.9.2 w/ RVM
How to connect your Ruby app to the Oracle database using ruby-oci8

At a high level, you need to:

Install VirtualBox
Install an Oracle VM, configure it correctly and add a user
Install Oracle's instant client on your mac
Get a 32-bit version of ruby running on your mac
Setup the correct connection info

Install VirtualBox

Go to https://www.virtualbox.org/wiki/Downloads and download the _VirtualBox 4.1.8 for OS X hosts_ file

Install the Oracle Virtual Machine

Go to http://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-vm-161299.html

Download the _Oracle Developer Day.ova_ file and follow the instructions for importing it.

Configuring the Virtual Machine

Before starting, do the following:

Increase the video memory so you can get better resolution: Setting > Display > Video Memory
Add a CD Drive under Settings > Storage > (green plus sign) and set it to "Empty"
Enable network connectivity by going to Settings > Network > Adapter 1 and make sure you have the correct settings (see below)

The correct network settings will vary based on your configuration, but start out with:

Attached to: Bridged Adapter
Name: en0 Ethernet
Advanced: Cable Connected (checked)

Start the Virtual Machine, and login with:

username: oracle
password: oracle

Once logged in, you should have an IP address which will appear when the terminal opesn. If that doesn't work, try executing:

/sbin/ifconfig

Look for the en0 section. You should be able to ssh in to that address, like so:

ssh oracle@10.1.10.30

If you are working on a wireless connection, you will have to configure it slightly differently (using en1: airport) which you can read about here .

You may want to install Guest Additions from _Devices > Install Guest Additions_ (from the running virtual machine's menu) - that's why you needed to install the CD drive.

Setting up the Oracle Database

Start the program called "SQL Developer 3.0" and login with the following credentials:

username: sys
password: oracle
connection type: basic
role: sysdba
hostname: localhost.localdomain
port: 1521
sid: orcl

Once you've entered, create a new user, with the following attributes:

username: someuser
password: somepassword
roles: Grant All, Admin All, Default All
System Privileges: Grant All, Admin All

This is the user you'll use to connect from the Mac.

Using the Oracle Web Console

From the virtual machine, you can enter the virtual web console by issuing this command:

emctl start dbconsole

It takes an embarassingly long time to load, but once it does, you can open https://localhost.localdomain:1158/em

To login here, use these settings:

username: sys
password: oracle
connect as: sysdba

Installing Instant Client on the Mac

Go to http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html

Download and unzip the following files (NOTE: you want the 32-bit version - even if you have a 64-bit operating system):

instantclient-basiclite-10.2.0.4.0-macosx-x86.zip
instantclient-sqlplus-10.2.0.4.0-macosx-x86.zip
instantclient-sdk-10.2.0.4.0-macosx-x86.zip

On your mac, download the following libraries, then unzip them, then copy the contents of those directories into a single directory. Then move that directory to /usr/local. The resulting directory tree should look like this:

/usr/local/instantclient-10.2.0.4.0/
├── BASIC_README
├── SQLPLUS_README
├── classes12.jar
├── genezi
├── glogin.sql
├── libclntsh.dylib -> libclntsh.dylib.10.1
├── libclntsh.dylib.10.1
├── libnnz10.dylib
├── libocci.dylib.10.1
├── libociei.dylib
├── libocijdbc10.dylib
├── libocijdbc10.jnilib
├── libsqlplus.dylib
├── libsqlplusic.dylib
├── ojdbc14.jar
├── sdk
│   ├── SDK_README
│   ├── demo
│   │   ├── cdemo81.c
│   │   ├── demo.mk
│   │   ├── occidemo.sql
│   │   ├── occidemod.sql
│   │   ├── occidml.cpp
│   │   ├── occiobj.cpp
│   │   └── occiobj.typ
│   ├── include
│   │   ├── nzerror.h
│   │   ├── nzt.h
│   │   ├── occi.h
│   │   ├── occiAQ.h
│   │   ├── occiCommon.h
│   │   ├── occiControl.h
│   │   ├── occiData.h
│   │   ├── occiObjects.h
│   │   ├── oci.h
│   │   ├── oci1.h
│   │   ├── oci8dp.h
│   │   ├── ociap.h
│   │   ├── ociapr.h
│   │   ├── ocidef.h
│   │   ├── ocidem.h
│   │   ├── ocidfn.h
│   │   ├── ociextp.h
│   │   ├── ocikpr.h
│   │   ├── ocixmldb.h
│   │   ├── odci.h
│   │   ├── oratypes.h
│   │   ├── ori.h
│   │   ├── orid.h
│   │   ├── orl.h
│   │   ├── oro.h
│   │   ├── ort.h
│   │   └── xa.h
│   ├── ott
│   └── ottclasses.zip
└── sqlplus

Once that's in place, you have to run:

cd /usr/local/instantclient-10.2.0.4.0/
ln -s libclntsh.dylib.10.1 libclntsh.dylib

Now you have all the oracle-related things installed, and you have to get your Ruby setup correct. In order for ruby to see these files, you'll have to add them to your bash profile:

In ~/.bash_profile

export DYLD_LIBRARY_PATH=/usr/local/instantclient-10.2.0.4.0
export ORACLE_HOME=/usr/local/instantclient-10.2.0.4.0
export SQLPATH=$ORACLE_HOME
export NLS_LANG="AMERICAN_AMERICA.UTF8"

Install a 32-bit version of Ruby 1.9.2 on your machine

On command line, run the following (this assumes you have RVM - if not, go get it ):

rvm get stable
# close your shell and reopen - to be sure you are on the latest RVM
rvm cleanup all
rvm_archflags="-arch i386" CFLAGS="-arch i386" LDFLAGS="-arch i386" rvm install 1.9.2 --patch osx-arch-fix -n i386
rvm alias create i386 ruby-1.9.2-p290-i386

This will install a 32-bit version of ruby, aliased to i386, and your other versions of 1.9.2 will not been affected.

Modify the .rvmrc file in your project directory to look like this:

rvm i386@my-project-name --create

You can read more about this craziness here .

At this point it's probably worth closing your terminal windows and re-opening to make sure you have a clean RVM setup, then cd to your project directory.

You should now be able to install the ruby-oci8 gem and test it out:

gem install ruby-oci8
irb
> require 'rubygems'
> require 'oci8'
> connection = OCI8.new("someuser", "somepassword", "//10.1.10.30:1521/orcl")
When connecting to the Oracle database, you use the IP address (or hostname), port and instance name for the "database name".

Running commands with ruby-oci8

If you are using Rails, you can set your database connection to use a similar configuration to the one above.

If you are using plain-old-ruby, you can execute Oracle commands directly, like so:

require 'rubygems'
require 'oci8'
connection = OCI8.new("someuser", "somepassword", "//10.1.10.30:1521/orcl")
connection.exec("create table foo (bar varchar(20) not null)")

One gotcha I noticed was that sometimes OCI complains when you execute a statement that has a semi-colon at the end, like so:

connection.exec("create table foo (bar varchar(20) not null);")

And that's it! If you've gotten this far, you deserve some sort of mood-altering drug. Probably some sort of stimulant, since you are probably as depressed as I was having to go through that ridiculous setup.

Rolling your own Akismet client in Ruby

2011-11-29T06:46:25+00:00

I recently wanted to some blog comments through Akismet's spam filter. I noticed that there were a number of plugins and gems on Github, but it seemed to me that it was overkill to add a gem dependency to my app just to make a simple http call. In this post I'll describe how to interact with the Akismet api with a simple, home-rolled Ruby client.

The basic idea is to take every comment that a user submits, send it to Akismet to check for spam, and mark the comment appropriately. I chose to put this directly in a controller, but it could just as easily be added to a background job. Here's what the controller looks like:

  class CommentsController < ApplicationController
    def create
      @post = Post.find(params[:post_id])
      @comment = @post.comments.build(params[:comment])
      @comment.spammy = SpamValidator.spammy?(@comment, params[:permalink], request)
      @comment.save
    end
  end

Note that the SpamValidator takes a permalink param, which is supposed to be the full url to the blog post where the comment originated. Since HTTP_REFERER's are sometimes inaccurate or missing, I decided to pass that directly from comment form, like so:

= form_for [@post, @comment] do |f|
  = hidden_field_tag :permalink, request.protocol + request.host_with_port + request.fullpath
  = f.label :name
  = f.text_field :name, class: input_span

The SpamValidator is where the heavy-lifting happens. While Ruby comes with a built-in class for making HTTP requests (Net::HTTP), I find it a bit kludgy to use. Instead, I prefer to use Typhoeus. The Akismet api requires some post parameters and a User-Agent header, and returns a simple true or false. Here's a simplified Akismet client class:

class SpamValidator
  BASE_URL = "http://yourapikey.rest.akismet.com"
  USER_AGENT = "Your Blog/1.0 | Custom/1.0"
  COMMENT_CHECK_PATH = "/1.1/comment-check"

  def self.spammy?(comment, permalink, request)
    params = {
      blog: "http://www.yourblog.com/",
      user_ip: request.remote_ip,
      user_agent: request.env["HTTP_USER_AGENT"],
      referrer: request.env["HTTP_REFERER"],
      permalink: permalink,
      comment_type: "comment",
      comment_author: comment.name,
      comment_author_email: comment.email,
      comment_author_url: comment.url,
      comment_content: comment.body
    }

    response = Typhoeus::Request.post(
      "#{BASE_URL}#{COMMENT_CHECK_PATH}",
      :params => params,
      :headers => {"User-Agent" => USER_AGENT}
    )

    response.body == "true"
  end
end

The Typhoeus::Request takes a path, url params and headers and takes care of the rest.

Akismet recommends that you also implement methods to identify missed spam and false positives, so in a real-world application you would likely expand the SpamValidator class to include those other two API calls, but I'll leave that as an exercise for the reader.

Speed up your Ruby loops with hashes

2011-11-28T06:06:36+00:00

I recently wrote a background job that looped over thousands of ActiveRecord objects, and it took about 45 minutes to run. In this post I'll describe how I cut that down to 1 minute by using hash lookups.

The particular piece of code that was taking so long was trying to find possible duplicates by iterating over all people in the database, and comparing them to all other people in the database. The code looked something like this:

people = Person.all(:include => :phone_numbers)

people.each do |person1|
  people.each do |person2|
    next if person1 == person2
    ( person1.phone_numbers.map(&:number) & person2.phone_numbers.map(&:number) ).present?
  end
end

Let's say that there are 1,000 people, and each person has 3 phone numbers. That inner loop:

calls phone_numbers roughly 2 million times
calls map roughly 2 million times
calls number roughly 6 million times
calls present? roughly 1 million times

With 11 million method calls, it's understandable that this snippet of code would take a a long time to run. One solution to making the code more efficient is to reduce the number of method calls in the inside loop. This is easy with hashes:

people = Person.all(:include => :phone_numbers)

phone_numbers = people.inject({}) do |hash, person|
  hash[person.id] = person.phone_numbers.map(&:number)
  hash
end

people.each do |person1|
  people.each do |person2|
    next if person1 == person2
    ( phone_numbers[person1.id] & phone_numbers[person2.id] ).present?
  end
end

In the example above, the phone_numbers method is called 1,000 times, and the number method is called 3,000. Inside the loop, there are still roughly 1 million hash lookups, but in my case hash lookups ended up being much faster than method calls.

Using Haml filters to embed data in Haml templates

2011-11-26T11:02:00+00:00

I recently decided to revive this blog, but I didn't want to continue using Mephisto for my blogging platform. I wanted to be able to write my blog posts in markdown or Haml, and store all meta-data about the posts in the Haml template. In addition I wanted to have an ActiveRecord-esque interface for blog post meta-data. In this post, I'll describe how I used Haml filters and ActiveHash to create this blogging platform.

My requirements for this blog are simple - I'd like to be able to keep track of:

the title
the published date
tags

Here's an example of what the final Haml template looks like:

:yaml
  id: 24
  permalink: /2011/11/26/some-permalink
  title: "Here is some title"
  published_at: 2011-11-26T11:02:00+00:00
  tags: haml

:summary
  %p  Here is some summary text

%p My requirements for this blog are simple - I'd like to be able to keep track of:

The first step was to make sure that the :yaml fitler never shows it's content. This is pretty easy with a custom Haml filter that overrides the #render method

module Haml::Filters::Yaml
  include Haml::Filters::Base

  def render(text)
  end
end

The second step was to capture text in the :yaml section in order to be able to convert it to YAML later on. Haml has a largely undocumented #compile method that provides the perfect hook for grabbing the text provided in a filter. Here's the complete custom filter:

module Haml::Filters::Yaml
 include Haml::Filters::Base

 def compile(compiler, text)
   compiler.file_data = text if compiler.respond_to?(:file_data)
   super
 end

 def render(text)
 end
end

The filter above checks to see if the rendering engine (the "compiler") responds to a method called file_data and if so it appends the raw text from the template into the compiler's file_data accessor.

The default Haml engine doesn't have a file_data method, so that code will be ignored when the view is rendered. However, it's simple to create a new Haml renderer that does have a file_data method, like so:

class EngineWithData < Haml::Engine
  attr_accessor :file_data
end

haml_engine = EngineWithData.new(File.read(Rails.root.join("app", "views", "posts", "content", "_somepost.rb")))
haml_engine.render
YAML.load(haml_engine.file_data) # => this will contain a hash like {"title" => "Here is some title"....}

I'm accustomed to working with ActiveRecord objects in my views and controllers, so the next step for me was to go through all of the files in my blog posts directory, extract the meta-data and add it to an ActiveRecord-esque object. I chose to go with ActiveHash, since it was built exactly for that purpose. Here's what my Post class ended up looking like:

class Post < ActiveHash::Base
  fields :title, :published_at, :tags, :permalink, :filename, :partial_name

  class EngineWithData < Haml::Engine
    attr_accessor :file_data
  end

  Dir.glob(Rails.root.join("app", "views", "posts", "content", "*")).each do |path|
    haml_engine = EngineWithData.new(File.read(path))
    haml_engine.render

    data = YAML.load(haml_engine.file_data)

    create(
      id: data["id"],
      partial_name: File.basename(path).sub(/^_/, ""),
      title: data['title'],
      published_at: data['published_at'].to_time,
      tags: (data['tags'] || '').split(",").map(&:strip),
      permalink: data['permalink']
    )
  end
end

First, I declared the fields that the ActiveHash object would respond to (title, tags etc...). Next, I declared the new Haml renderer that has the file_data accessor. Finally, I looped through every file in my blog posts directory, rendered the contents, pulled the meta data out and created a Post with the given data.

Now, whenever the Rails app starts, it parses every file, creates a set of in-memory rows with post data that I can access in a way similar to ActiveRecord objects. For example, if I wanted to get posts with a given tag, I could do this:

Post.all.select{|post| post.tags.include?(tag)}

Rendering these posts is straightforward. My PostsController looks like any other normal Rails controller:

class PostsController < ApplicationController
  def show
    @post = Post.find_by_permalink(params[:id])
  end
end

The view is very similar as well. One difference is that instead of pulling the blog post's content from the database, I just render that Haml template as a partial.

- content_for :title, @post.title

%article
  %h1= @post.title
  %p= @post.published_at.to_date.to_s(:long)

  .content
    = render "/posts/content/#{@post.partial_name}"

With those simple steps, I can now write my blog posts in Haml (or markdown, or erb or any other filter that Haml understands), version my posts in Git and I'm no longer dependent on 3rd-party blogging software.

In a follow-up post, I'll describe how to use a similar technique to create summary text for blog posts.

Rails.cache: Memcached, development mode and offline cache invalidation

2008-07-05T02:11:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

Rails.cache rocks, but it can be tricky to set it up for development mode. For my purposes I need to:

Keep config.cache_classes to false so that I don't have to restart my server while I develop
Cache all kinds of objects, not just strings
Be able to invalidate the cache easily from cron scripts or other offline processes
Test caching locally before deploying

The first thing I did was check out the excellent railscast and I read through the blog posts mentioned there. However, I couldn't quite figure out how to get things to work - I kept getting strange errors where all of the methods were being stripped from my classes, rails was complaining that my classes didn't exist or I was getting dreadful "singleton can't be dumped" errors. After a lot of googling and experimentation, here is what finally worked for me:

Environment files

I like to develop quickly, test caching on my local and then deploy. To accomplish this I have 3 environments, setup like so:

# config/environments/development.rb
config.action_controller.perform_caching = false
config.cache_classes = false
config.cache_store = :mem_cache_store, '127.0.0.1:11211', {:namespace => "dev"}

# config/environments/dev_with_caching.rb
config.action_controller.perform_caching  = true
config.cache_classes = true
config.cache_store = :mem_cache_store, '127.0.0.1:11211', {:namespace => "dev_with_caching"}

# config/environments/production.rb
config.action_controller.perform_caching  = true
config.cache_classes = true
config.cache_store = :mem_cache_store, '127.0.0.1:11211', {:namespace => "production"}

Here are a few interesting points:

You don't need to have memcached installed to develop locally

If you run your app locally without memcached installed, or without memcached running, you will see entries like this in your log

MemCacheError (No connection to server): No connection to server
Cache miss: Post.all ({:force=>false})

However, your app will work just fine. Rails will always execute the contents of the fetch blocks, and will return nil for any reads.

If memcached is running, you need to set cache_classes to true

To run memcached locally, you need to install memcached. I develop on a mac and manage packages with macports, so for me it was as easy as:

sudo port install memcached

Once memcached is installed, you can start it with

memcached -m 500 -l 127.0.0.1 -p 11211 -vv

which will print verbose logging to STDERR, or you can start it as a daemon like so:

memcached -m 500 -l 127.0.0.1 -p 11211 -d

Either of these will start a memcached process running on port 11211, and it will allocate 500MB RAM (most apps can get by with 128MB, or so I've heard).

Once this is running, though, you need to set config.cache_classes to true - otherwise you're app will blow up.

Marshal.dump is finicky

Rails.cache calls Marshal.dump on any object you try to put in the cache. Marshal won't work on everything though - and you may need to write your own serialization script. I've had problems with classes that have lots of module_eval statements that create methods dynamically and similar meta-programming techniques. If you start getting errors like "singleton can't be dumped", check to see if you have any meta-programming going on. I've also had issues with REXML objects.

If you do have an issue with a class that Rails won't cache, you can easily bypass the built-in serialization by writing your own dump and load methods. See the ruby docs for more info.

Use a separate environment to test locally

I have a new environment named dev_with_caching that I use to test caching locally. I set up my database.yml file so that it points to the development database, but performs caching and in all other respects mirrors the production environment. To test locally with that environment, I use:

script/server -e dev_with_caching -p 3001

Clearing the cache

I mostly use Rails.cache to cache data - and mostly for arrays of objects - like Category.all. As such, it's to keep all of this in the model, but cache invalidation can be trickly to manage. Here's a pattern I've started to use a lot:

class Category < ActiveRecord::Base

  after_save      :reset_cache
  after_destroy :reset_cache

  def reset_cache
    self.class.reset_cache
  end

  class << self

    def reset_cache
      cached_all(true)
    end

    def cached_all(force = false)
      Rails.cache.fetch("Category.all", :force => force) do
        Category.find(:all, :conditions => {:active=>true}, :order=>'position')
      end
    end
  end
end

Here's what's happening:

The first time you call Category.cached_all it looks for the "Category.all" item in the cache. If it's not there, it executes the contents of the block, and adds it to the cache. When you save or destroy a record the cache is invalidated.

If you want to force a refresh of the cache, just specify Category.cached_all(true) and it will be reloaded from the database. Once this is in place, it's easy to write cache invalidation scripts that both clear the cache and reload it at the same time.

I've done this by adding a class method that reloads the data, which is triggered by after_save and after_destroy callbacks. I'm sure there are a number of plugins that will do all that and more, but for my purposes this simple pattern works for me most of the time.

Clearing the cache with cron

Finally, if you want to clear the cache at specified intervals you can do so easily with rake and cron. First, create a rake task that calls the model's reset_cache method - since I normally have several classes with caching behavior I normally create a loop like so:

namespace :cache do
  namespace :reset do
    %w{Category Forum Post}.each do |klass|
      desc "Clear the #{klass} cache"
      task klass.underscore.gsub("/","_").pluralize => :environment do
        klass.constantize.reset_cache
      end
    end
  end
end

Now you can run rake cache:reset:categories and your Category.reset_cache method will be called. To make this work with cron, you'll need a slightly different syntax. The following command is suitable to execute from a cron script, or manually from the command line:

RAILS_ENV=production rake -f /var/www/apps/yourapp/current/Rakefile cache:reset:categories

It might take a little while to grok Rails.cache - but once you do your apps will be faster and you'll quickly become a wild caching fiend!

Networking Mac and Windows with VMWare

2008-07-05T01:51:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I recently discovered how easy it is to view my local development websites on multiple OS's using VMWare. I use this primarily to see how awful my apps look in IE. Here's how you can do it too:

Step1: Get Setup (the expensive part)

Buy a mac
Buy VMWare Fusion
Buy Windows. Yes - if you want to run IE6 and IE7 you'll have to buy two licenses. Yes, it will take you several hours of frustration and several hours on the phone with MicroSoft to get your licenses installed with VMWare.
Download a few real OS's and add them as virtual machines

Step 2: Find your network address

When you installed VMWare, it configured all of the necessary IP addresses for you. To find out what they are, open Terminal and type:

ifconfig

You'll see something like:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
  inet 127.0.0.1 netmask 0xff000000
  inet6 ::1 prefixlen 128
  inet6 fdd3:5091:e6df:4c3d:21b:63ff:feab:d72e prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether 00:1b:63:ab:d7:2e
  media: autoselect status: inactive
  supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  inet6 fe80::21c:b3ff:fe7c:916e%en1 prefixlen 64 scopeid 0x5
  inet6 2002:4452:63ee::21c:b3ff:fe7c:916e prefixlen 64 autoconf
  inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255
  ether 00:1c:b3:7c:91:6e
  media: autoselect status: active
  supported media: autoselect
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
  lladdr 00:1d:4f:ff:fe:73:a1:ba
  media: autoselect <full-duplex> status: inactive
  supported media: autoselect <full-duplex>
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  inet 172.16.192.1 netmask 0xffffff00 broadcast 172.16.192.255
  ether 00:50:56:c0:00:08
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  inet 172.16.43.1 netmask 0xffffff00 broadcast 172.16.43.255
  ether 00:50:56:c0:00:01

Notice the last entry, vmnet1 - the inet address listed there is the address that all of your virtual machines can use to access your localhost. In my case, this is 172.16.43.1

Let's say you have a local rails app running on http://localhost:3000/ - to access that app from anywhere (your mac or any or your virtual machines) just type http://172.16.43.1:3000/ in your browser.

References

http://www.lunenburg.org/wade/articles/2007/12/11/theres-no-place-like-lo0/

Tutorial: Creating plugins in Rails

2008-05-29T21:38:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

You can see the most recent version of this post at http://guides.rubyonrails.org/plugins.html

There's a new effort underway to add tutorials to the Rails API documentation. Here's the first draft of a tutorial I just wrote describing how to create plugins.

Creating Plugin Basics

Pretend for a moment that you are an avid bird watcher. Your favorite bird is the Yaffle, and you want to create a plugin that allows other developers to share in the Yaffle goodness.

In this tutorial you will learn how to create a plugin that includes:

Core Extensions - extending String:

# Anywhere
"hello".squawk # => "squawk! hello! squawk!"

An acts_as_yaffle method for Active Record models that adds a "squawk" method:

class Hickwall < ActiveRecord::Base
  acts_as_yaffle :yaffle_text_field => :last_sang_at
end

Hickwall.new.squawk("Hello World")

A view helper that will print out squawking info:

squawk_info_for(@hickwall)

A generator that creates a migration to add squawk columns to a model:

script/generate yaffle hickwall

A custom generator command:

class YaffleGenerator < Rails::Generator::NamedBase
  def manifest
      m.yaffle_definition
    end
  end
end

A custom route method:

ActionController::Routing::Routes.draw do |map|
  map.yaffles
end

In addition you'll learn how to:

test your plugins
work with init.rb, how to store model, views, controllers, helpers and even other plugins in your plugins
create documentation for your plugin.

Create the basic app

In this tutorial we will create a basic rails application with 1 resource: bird. Start out by building the basic rails app:

The following instructions will work for sqlite3. For more detailed instructions on how to create a rails app for other databases see the API docs.

rails plugin_demo
cd plugin_demo
script/generate scaffold bird name:string
rake db:migrate
script/server

Then navigate to http://localhost:3000/birds. Make sure you have a functioning rails app before continuing.

Create the plugin

The built-in Rails plugin generator stubs out a new plugin. Pass the plugin name, either CamelCased or under_scored, as an argument. Pass --with-generator to add an example generator also.

This creates a plugin in vendor/plugins including an init.rb and README as well as standard lib, task, and test directories.

Examples:

./script/generate plugin BrowserFilters
./script/generate plugin BrowserFilters --with-generator

Later in the plugin we will create a generator, so go ahead and add the --with-generator option now:

script/generate plugin yaffle --with-generator

You should see the following output:

create  vendor/plugins/yaffle/lib
create  vendor/plugins/yaffle/tasks
create  vendor/plugins/yaffle/test
create  vendor/plugins/yaffle/README
create  vendor/plugins/yaffle/MIT-LICENSE
create  vendor/plugins/yaffle/Rakefile
create  vendor/plugins/yaffle/init.rb
create  vendor/plugins/yaffle/install.rb
create  vendor/plugins/yaffle/uninstall.rb
create  vendor/plugins/yaffle/lib/yaffle.rb
create  vendor/plugins/yaffle/tasks/yaffle_tasks.rake
create  vendor/plugins/yaffle/test/core_ext_test.rb
create  vendor/plugins/yaffle/generators
create  vendor/plugins/yaffle/generators/yaffle
create  vendor/plugins/yaffle/generators/yaffle/templates
create  vendor/plugins/yaffle/generators/yaffle/yaffle_generator.rb
create  vendor/plugins/yaffle/generators/yaffle/USAGE

For this plugin you won't need the file vendor/plugins/yaffle/lib/yaffle.rb so you can delete that.

rm vendor/plugins/yaffle/lib/yaffle.rb

Editor's note: many plugin authors prefer to keep this file, and add all of the require statements in it. That way, they only line in init.rb would be require "yaffle" If you are developing a plugin that has a lot of files in the lib directory, you may want to create a subdirectory like lib/yaffle and store your files in there. That way your init.rb file stays clean

Testing Setup

Testing plugins that use the entire Rails stack can be complex, and the generator doesn't offer any help. In this tutorial you will learn how to test your plugin against multiple different adapters using ActiveRecord. This tutorial will not cover how to use fixtures in plugin tests.

To setup your plugin to allow for easy testing you'll need to add 3 files:

A database.yml file with all of your connection strings
A schema.rb file with your table definitions
A test helper that sets up the database before your tests

For this plugin you'll need 2 tables/models, Hickwalls and Wickwalls, so add the following files:

# File: vendor/plugins/yaffle/test/database.yml

sqlite:
  :adapter: sqlite
  :dbfile: yaffle_plugin.sqlite.db
sqlite3:
  :adapter: sqlite3
  :dbfile: yaffle_plugin.sqlite3.db
postgresql:
  :adapter: postgresql
  :username: postgres
  :password: postgres
  :database: yaffle_plugin_test
  :min_messages: ERROR
mysql:
  :adapter: mysql
  :host: localhost
  :username: rails
  :password:
  :database: yaffle_plugin_test

# File: vendor/plugins/yaffle/test/test_helper.rb

ActiveRecord::Schema.define(:version => 0) do
  create_table :hickwalls, :force => true do |t|
    t.string :name
    t.string :last_squawk
    t.datetime :last_squawked_at
  end
  create_table :wickwalls, :force => true do |t|
    t.string :name
    t.string :last_tweet
    t.datetime :last_tweeted_at
  end
end

# File: vendor/plugins/yaffle/test/test_helper.rb

ENV['RAILS_ENV'] = 'test'
ENV['RAILS_ROOT'] ||= File.dirname(__FILE__) + '/../../../..'

require 'test/unit'
require File.expand_path(File.join(ENV['RAILS_ROOT'], 'config/environment.rb'))

config = YAML::load(IO.read(File.dirname(__FILE__) + '/database.yml'))
ActiveRecord::Base.logger = Logger.new(File.dirname(__FILE__) + "/debug.log")

db_adapter = ENV['DB']

# no db passed, try one of these fine config-free DBs before bombing.
db_adapter ||=
  begin
    require 'rubygems'
    require 'sqlite'
    'sqlite'
  rescue MissingSourceFile
    begin
      require 'sqlite3'
      'sqlite3'
    rescue MissingSourceFile
    end
  end

if db_adapter.nil?
  raise "No DB Adapter selected. Pass the DB= option to pick one, or install Sqlite or Sqlite3."
end

ActiveRecord::Base.establish_connection(config[db_adapter])

load(File.dirname(__FILE__) + "/schema.rb")

require File.dirname(__FILE__) + '/../init.rb'

class Hickwall < ActiveRecord::Base
  acts_as_yaffle
end

class Wickwall < ActiveRecord::Base
  acts_as_yaffle :yaffle_text_field => :last_tweet, :yaffle_date_field => :last_tweeted_at
end

Update a core class: Adding "to_squawk" to String

To update a core class you will have to:

Write tests for the desired functionality
Create a file for the code you wish to use
Require that file from your init.rb

Most plugins store their code classes in the plugin's lib directory. When you add a file to the lib directory, you must also require that file from init.rb. The file you are going to add for this tutorial is lib/core_ext.rb

First, you need to write the tests. Testing plugins is very similar to testing rails apps. The generated test file should look something like this:

# File: vendor/plugins/yaffle/test/core_ext_test.rb

require 'test/unit'

class CoreExtTest < Test::Unit::TestCase
  # Replace this with your real tests.
  def test_this_plugin
    flunk
  end
end

Start off by removing the default test, and adding a require statement for your test helper.

# File: vendor/plugins/yaffle/test/core_ext_test.rb

require 'test/unit'
require File.dirname(__FILE__) + '/test_helper.rb'

class CoreExtTest < Test::Unit::TestCase
end

Navigate to your plugin directory and run rake test

cd vendor/plugins/yaffle
rake test

Your test should fail with no such file to load -- ./test/../lib/core_ext.rb (LoadError) because we haven't created any file yet. Create the file lib/core_ext.rb and re-run the tests. You should see a different error message:

1.) Failure ...
No tests were specified

Great - now you are ready to start development. The first thing we'll do is to add a method to String called to_squawk which will prefix the string with the word "squawk! ". The test will look something like this:

# File: vendor/plugins/yaffle/init.rb

class CoreExtTest < Test::Unit::TestCase
  def test_string_should_respond_to_squawk
    assert_equal true, "".respond_to?(:to_squawk)
  end
  def test_string_prepend_empty_strings_with_the_word_squawk
    assert_equal "squawk!", "".to_squawk
  end
  def test_string_prepend_non_empty_strings_with_the_word_squawk
    assert_equal "squawk! Hello World", "Hello World".to_squawk
  end
end

# File: vendor/plugins/yaffle/init.rb

require "core_ext"

# File: vendor/plugins/yaffle/lib/core_ext.rb

class String
  # returns the current string, prefixed by "squawk!"
  def to_squawk
    "squawk! #{self}".strip
  end
end

To test that your method does what it says it does, run the unit tests. To make sure your code is picked up by

To test this, fire up a console and start squawking:

script/console
>> "Hello World".to_squawk
=> "squawk! Hello World"

If that worked, congratulations! You just created your first test-driven plugin that extends a core ruby class.

Adding an `acts_as_yaffle` method to ActiveRecord models

A common pattern in plugins is to add a method called acts_as_something to models. In this case, you want to write a method called acts_as_yaffle that adds a squawk method to your models.

To keep things clean, create a new test file called acts_as_yaffle_test.rb in your plugin's test directory and require your test helper.

# File: vendor/plugins/yaffle/test/acts_as_yaffle_test.rb

require File.dirname(__FILE__) + '/test_helper.rb'

class Hickwall < ActiveRecord::Base
  acts_as_yaffle
end

class ActsAsYaffleTest < Test::Unit::TestCase
end

# File: vendor/plugins/lib/acts_as_yaffle.rb

module Yaffle
end

One of the most common plugin patterns for acts_as_yaffle plugins is to structure your file like so:

module Yaffle
  def self.included(base)
    base.send :extend, ClassMethods
  end

  module ClassMethods
    # any method placed here will apply to classes, like Hickwall
    def acts_as_something
      send :include, InstanceMethods
    end
  end

  module InstanceMethods
    # any method placed here will apply to instaces, like @hickwall
  end
end

With structure you can easily separate the methods that will be used for the class (like Hickwall.some_method) and the instance (like @hickwell.some_method).

Let's add class method named acts_as_yaffle - testing it out first. You already defined the ActiveRecord models in your test helper, so if you run tests now they will fail.

Back in your acts\_as\_yaffle file, update ClassMethods like so:

module ClassMethods
  def acts_as_yaffle(options = {})
    send :include, InstanceMethods
  end
end

Now that test should pass. Since your plugin is going to work with field names, you need to allow people to define the field names, in case there is a naming conflict. You can write a few simple tests for this:

# File: vendor/plugins/yaffle/test/acts_as_yaffle_test.rb

require File.dirname(__FILE__) + '/test_helper.rb'

class ActsAsYaffleTest < Test::Unit::TestCase
  def test_a_hickwalls_yaffle_text_field_should_be_last_squawk
    assert_equal "last_squawk", Hickwall.yaffle_text_field
  end
  def test_a_hickwalls_yaffle_date_field_should_be_last_squawked_at
    assert_equal "last_squawked_at", Hickwall.yaffle_date_field
  end
  def test_a_wickwalls_yaffle_text_field_should_be_last_tweet
    assert_equal "last_tweet", Wickwall.yaffle_text_field
  end
  def test_a_wickwalls_yaffle_date_field_should_be_last_tweeted_at
    assert_equal "last_tweeted_at", Wickwall.yaffle_date_field
  end
end

To make these tests pass, you could modify your acts_as_yaffle file like so:

# File: vendor/plugins/yaffle/lib/acts_as_yaffle.rb

module Yaffle
  def self.included(base)
    base.send :extend, ClassMethods
  end

  module ClassMethods
    def acts_as_yaffle(options = {})
      cattr_accessor :yaffle_text_field, :yaffle_date_field
      self.yaffle_text_field = (options[:yaffle_text_field] || :last_squawk).to_s
      self.yaffle_date_field = (options[:yaffle_date_field] || :last_squawked_at).to_s
      send :include, InstanceMethods
    end
  end

  module InstanceMethods
  end
end

Now you can add tests for the instance methods, and the instance method itself:

# File: vendor/plugins/yaffle/test/acts_as_yaffle_test.rb

require File.dirname(__FILE__) + '/test_helper.rb'

class ActsAsYaffleTest < Test::Unit::TestCase

  def test_a_hickwalls_yaffle_text_field_should_be_last_squawk
    assert_equal "last_squawk", Hickwall.yaffle_text_field
  end
  def test_a_hickwalls_yaffle_date_field_should_be_last_squawked_at
    assert_equal "last_squawked_at", Hickwall.yaffle_date_field
  end

  def test_a_wickwalls_yaffle_text_field_should_be_last_squawk
    assert_equal "last_tweet", Wickwall.yaffle_text_field
  end
  def test_a_wickwalls_yaffle_date_field_should_be_last_squawked_at
    assert_equal "last_tweeted_at", Wickwall.yaffle_date_field
  end

  def test_hickwalls_squawk_should_populate_last_squawk
    hickwall = Hickwall.new
    hickwall.squawk("Hello World")
    assert_equal "squawk! Hello World", hickwall.last_squawk
  end
  def test_hickwalls_squawk_should_populate_last_squawked_at
    hickwall = Hickwall.new
    hickwall.squawk("Hello World")
    assert_equal Date.today, hickwall.last_squawked_at
  end

  def test_wickwalls_squawk_should_populate_last_tweet
    wickwall = Wickwall.new
    wickwall.squawk("Hello World")
    assert_equal "squawk! Hello World", wickwall.last_tweet
  end
  def test_wickwalls_squawk_should_populate_last_tweeted_at
    wickwall = Wickwall.new
    wickwall.squawk("Hello World")
    assert_equal Date.today, wickwall.last_tweeted_at
  end
end

# File: vendor/plugins/yaffle/lib/acts_as_yaffle.rb

module Yaffle
  def self.included(base)
    base.send :extend, ClassMethods
  end

  module ClassMethods
    def acts_as_yaffle(options = {})
      cattr_accessor :yaffle_text_field, :yaffle_date_field
      self.yaffle_text_field = (options[:yaffle_text_field] || :last_squawk).to_s
      self.yaffle_date_field = (options[:yaffle_date_field] || :last_squawked_at).to_s
      send :include, InstanceMethods
    end
  end

  module InstanceMethods
    def squawk(string)
      write_attribute(self.class.yaffle_text_field, string.to_squawk)
      write_attribute(self.class.yaffle_date_field, Date.today)
    end
  end
end

Note the use of write_attribute to write to the field in model.

Create a view helper

Creating a view helper is a 3-step process:

Add an appropriately named file to the lib directory
Require the file and hooks in init.rb
Write the tests

First, create the test to define the functionality you want:

# File: vendor/plugins/yaffle/test/view_helpers_test.rb

require File.dirname(__FILE__) + '/test_helper.rb'
include YaffleViewHelper

class ViewHelpersTest < Test::Unit::TestCase
  def test_squawk_info_for_should_return_the_text_and_date
    time = Time.now
    hickwall = Hickwall.new
    hickwall.last_squawk = "Hello World"
    hickwall.last_squawked_at = time
    assert_equal "Hello World, #{time.to_s}", squawk_info_for(hickwall)
  end
end

Then add the following statements to init.rb:

# File: vendor/plugins/yaffle/init.rb

require "view_helpers"
ActionView::Base.send :include, YaffleViewHelper

Then add the view helpers file and

# File: vendor/plugins/yaffle/lib/view_helpers.rb

module YaffleViewHelper
  def squawk_info_for(yaffle)
    returning "" do |result|
      result << yaffle.read_attribute(yaffle.class.yaffle_text_field)
      result << ", "
      result << yaffle.read_attribute(yaffle.class.yaffle_date_field).to_s
    end
  end
end

You can also test this in script/console by using the "helper" method:

script/console
>> helper.squawk_info_for(@some_yaffle_instance)

Create a migration generator

When you created the plugin above, you specified the --with-generator option, so you already have the generator stubs in your plugin.

We'll be relying on the built-in rails generate template for this tutorial. Going into the details of generators is beyond the scope of this tutorial.

Type:

script/generate

You should see the line:

Plugins (vendor/plugins): yaffle

When you run script/generate yaffle you should see the contents of your USAGE file. For this plugin, the USAGE file looks like this:

Description:
    Creates a migration that adds yaffle squawk fields to the given model

Example:
    ./script/generate yaffle hickwall

    This will create:
        db/migrate/TIMESTAMP_add_yaffle_fields_to_hickwall

Now you can add code to your generator:

# File: vendor/plugins/yaffle/generators/yaffle/yaffle_generator.rb

class YaffleGenerator < Rails::Generator::NamedBase
  def manifest
    record do |m|
      m.migration_template 'migration:migration.rb', "db/migrate", {:assigns => yaffle_local_assigns,
        :migration_file_name => "add_yaffle_fields_to_#{custom_file_name}"
      }
    end
  end

  private
    def custom_file_name
      custom_name = class_name.underscore.downcase
      custom_name = custom_name.pluralize if ActiveRecord::Base.pluralize_table_names
    end

    def yaffle_local_assigns
      returning(assigns = {}) do
        assigns[:migration_action] = "add"
        assigns[:class_name] = "add_yaffle_fields_to_#{custom_file_name}"
        assigns[:table_name] = custom_file_name
        assigns[:attributes] = [Rails::Generator::GeneratedAttribute.new("last_squawk", "string")]
        assigns[:attributes] << Rails::Generator::GeneratedAttribute.new("last_squawked_at", "datetime")
      end
    end
end

Note that you need to be aware of whether or not table names are pluralized.

This does a few things:

Reuses the built in rails migration_template method
Reuses the built-in rails migration template

When you run the generator like

script/generate yaffle bird

You will see a new file:

# File: db/migrate/20080529225649_add_yaffle_fields_to_birds.rb

class AddYaffleFieldsToBirds < ActiveRecord::Migration
  def self.up
    add_column :birds, :last_squawk, :string
    add_column :birds, :last_squawked_at, :datetime
  end

  def self.down
    remove_column :birds, :last_squawked_at
    remove_column :birds, :last_squawk
  end
end

Adding custom generator commands

You may have noticed above that you can used one of the built-in rails migration commands m.migration_template. You can create your own commands for these, using the following steps:

Add the require and hook statements to init.rb
Create the commands - creating 3 sets, Create, Destroy, List
Add the method to your generator

Working with the internals of generators is beyond the scope of this tutorial, but here is a basic example:

# File: vendor/plugins/yaffle/init.rb

require "commands"
Rails::Generator::Commands::Create.send   :include,  Yaffle::Generator::Commands::Create
Rails::Generator::Commands::Destroy.send  :include,  Yaffle::Generator::Commands::Destroy
Rails::Generator::Commands::List.send     :include,  Yaffle::Generator::Commands::List

# File: vendor/plugins/yaffle/lib/commands.rb

require 'rails_generator'
require 'rails_generator/commands'

module Yaffle #:nodoc:
  module Generator #:nodoc:
    module Commands #:nodoc:
      module Create
        def yaffle_definition
          file("definition.txt", "definition.txt")
        end
      end

      module Destroy
        def yaffle_definition
          file("definition.txt", "definition.txt")
        end
      end

      module List
        def yaffle_definition
          file("definition.txt", "definition.txt")
        end
      end
    end
  end
end

# File: vendor/plugins/yaffle/generators/yaffle/templates/definition.txt

Yaffle is a bird

# File: vendor/plugins/yaffle/generators/yaffle/yaffle_generator.rb

class YaffleGenerator < Rails::Generator::NamedBase
  def manifest
      m.yaffle_definition
    end
  end
end

This example just uses the built-in "file" method, but you could do anything that ruby allows.

Adding Routes

Testing routes in plugins can be complex, especially if the controllers are also in the plugin itself. Jamis Buck showed a great example of this in http://weblog.jamisbuck.org/2006/10/26/monkey-patching-rails-extending-routes-2

# File: vendor/plugins/yaffle/test/routing_test.rb

require "#{File.dirname(__FILE__)}/test_helper"

class RoutingTest < Test::Unit::TestCase

  def setup
    ActionController::Routing::Routes.draw do |map|
      map.yaffles
    end
  end

  def test_yaffles_route
    assert_recognition :get, "/yaffles", :controller => "yaffles_controller", :action => "index"
  end

  private

    # yes, I know about assert_recognizes, but it has proven problematic to
    # use in these tests, since it uses RouteSet#recognize (which actually
    # tries to instantiate the controller) and because it uses an awkward
    # parameter order.
    def assert_recognition(method, path, options)
      result = ActionController::Routing::Routes.recognize_path(path, :method => method)
      assert_equal options, result
    end
end

# File: vendor/plugins/yaffle/init.rb

require "routing"
ActionController::Routing::RouteSet::Mapper.send :include, Yaffle::Routing::MapperExtensions

# File: vendor/plugins/yaffle/lib/routing.rb

module Yaffle #:nodoc:
  module Routing #:nodoc:
    module MapperExtensions
      def yaffles
        @set.add_route("/yaffles", {:controller => "yaffles_controller", :action => "index"})
      end
    end
  end
end

# File: config/routes.rb

ActionController::Routing::Routes.draw do |map|
  ...
  map.yaffles
end

You can also see if your routes work by running rake routes from your app directory.

Generate RDoc Documentation

Once your plugin is stable, the tests pass on all database and you are ready to deploy do everyone else a favor and document it! Luckily, writing documentation for your plugin is easy.

The first step is to update the README file with detailed information about how to use your plugin. A few key things to include are:

Your name
How to install
How to add the functionality to the app (several examples of common use cases)
Warning, gotchas or tips that might help save users time

Once your README is solid, go through and add rdoc comments to all of the methods that developers will use.

Before you generate your documentation, be sure to go through and add nodoc comments to those modules and methods that are not important to your users.

Once your comments are good to go, navigate to your plugin directory and run

rake rdoc

Working with init.rb

The plugin initializer script init.rb is invoked via eval (not require) so it has slightly different behavior.

If you reopen any classes in init.rb itself your changes will potentially be made to the wrong module. There are 2 ways around this:

The first way is to explicitly define the top-level module space for all modules and classes, like ::Hash

# File: vendor/plugins/yaffle/init.rb

class ::Hash
  def is_a_special_hash?
    true
  end
end

OR you can use module_eval or class_eval

# File: vendor/plugins/yaffle/init.rb

Hash.class_eval do
  def is_a_special_hash?
    true
  end
end

Storing models, views, helpers, and controllers in your plugins

You can easily store models, views, helpers and controllers in plugins. Just create a folder for each in the lib folder, add them to the load path and remove them from the load once path:

# File: vendor/plugins/yaffle/init.rb

%w{ models controllers helpers }.each do |dir|
  path = File.join(directory, 'lib', dir)
  $LOAD_PATH << path
  Dependencies.load_paths << path
  Dependencies.load_once_paths.delete(path)
end

Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser.

Adding directories to the load once paths allow those changes to picked up as soon as you save the file - without having to restart the web server.

Storing plugins in alternate locations

You can store plugins wherever you want - you just have to add those plugins to the plugins path in environment.rb

Since the plugin is only loaded after the plugin paths are defined, you can't redefine this in your plugins - but it may be good to now.

You can even store plugins inside of other plugins for complete plugin madness!

config.plugin_paths << File.join(RAILS_ROOT,"vendor","plugins","yaffle","lib","plugins")

Plugin Loaders and Plugin Locators

If the built-in plugin behavior is inadequate, you can change almost every aspect of the location and loading process. You can write your own plugin locators and plugin loaders, but that's beyond the scope of this tutorial.

Custom Plugin Generators

If you are an RSpec fan, you can install the rspec_plugin_generator, which will generate the spec folder and database for you.

http://github.com/pat-maddox/rspec-plugin-generator/tree/master

References

Demo apps

2008-05-20T21:02:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I love demo apps. When coutenay came out with his rails demo app I learned a lot. I've since created a few feature-specific demo apps and I hope that others can learn something from them:

As I've built these, I've realized that it would be helpful if all of these demo apps had a similar structure, so I'm going to propose one here. If you have any thoughts, either fork one of those apps at the top and add them to your fork, or add comments here below. Here's my first round of thoughts:

There should be a demo app start kit

This starter kit would have a readme with a README.rdoc page with a few sections outlined already, like "Installation", "What this demonstrates" etc...

Another great feature for a starter kit would be a helper that reads source files and displays them, syntax highlighted, to the users so that while you are looking at a page in the app and you say "what does the controller look like for this page" you could just click "view the controller code" and have it appear.

Yet another feature that would be slick in a demo app would be a page that detects whether or not the database is installed, and if not, provides you with a simple database configuration form that allows you to specify the provider, username/password and optionally the timeout or the socket.

The idea for the starter kit would be to make it easy for developers to create a starter kit that "just works" by installing the app and running script/server.

Vendor everything

Rails makes this easy with the new gem dependencies, but I think all rails apps should have vendor/rails and all of the related gems vendored. I haven't been consistent about this with my demo apps, but I realize how this would be important.

Pre-populate the database

Whether you use the dataset plugin, custom rake tasks or sqlite3 databases prepopulated, every demo app should have an initial dataset so people can test the full range of the app without having to first add data - especially important for things like the complex forms demo, where the app shows how multiple models relate to each other.

Demos should ideally have specs

I haven't put meaninful specs into any of my demos, but as people download them and point out bugs I realize how helpful they would have been. I hope to add specs to these apps as time goes on and fix whatever bugs I find. If you do this, be sure to vendor your rspec/rspec-rails along with your vendor/rails.

Documentation should be redundant

Things that are in the README should also appear on the actual rendered pages, as well as in the source code. When developers first load up the app it should be obvious what's happening.

Again - I haven't done most of these in my demo apps, but I realize how important they would be, especially if more than 1 or 2 people are downloading the app. If someone is checking out your demo app, it probably means that don't know how to do whatever you are demonstrating, and a long or frustrating demo (or a buggy one) can be worse than none at all.

Have you built a demo app? Any other suggestions or anything I've missed?

Rails View Tips

2008-05-05T00:04:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

Here is a list of quick tips that I find helpful using Ruby and Rails, inspired by the Railscasts Contest

1. Access view helpers from the console

Sometimes I need a quick reminder of the syntax of view helpers - like is it truncate(length, text) or truncate(text, length)? When this happens I just fire up a script/console and use the "helper" method. For example:

helper.truncate "Big sentence", 5
=> "Bi..."

2. Word Wrap

Speaking of view helpers, you probably know about pluralize, truncate and simple_format, but did you know that rails can word wrap for you? Frequently I find that I have a column of text that just doesn't look good when some lines are a lot longer than others, and I need to have more fine-grained control over the output. Word wrap comes to the rescue. You can test this in script/console by doing the following:

text = "This is some very very long text that needs to be word wrapped"
helper.word_wrap text, 50
=> "This is some very very long text that needs to be\nword wrapped"

Notice that it inserts a newline, not a br element. If you want to convert that newline to an html br element, you can always use simple_format. What I particularly like about word_wrap is that it only breaks on whitespace characters, so you'll never end up with a half-word.

3. Partial Counter

Let's say you need to render a partial for a collection, and that you need to generate a sequential number that can't be inferred from the database, like "Post #0, Post #1, Post #2" etc. where the numbers will always start with 0 and always be sequential. To start you might try something like this:

@posts.each_with_index do |post, index|
  render :partial => "post", :object => post, :locals => {:index => index}
end

Then from your partial, you would reference it like:

Post #<%= index %>

However, if you render a partial from a collection, Rails keeps track of the index for you auto-magically, in a local variable named partial_counter (in this case it would be post_counter). Refactored, it would look like this:

render :partial => @posts

And from the partial itself:

Post #<%= post_counter %>

Remember that partial_counter is zero-based. For regular partials, called with just an object, it will return 0.

4. Keep selects and model validations in sync with constants

The problem: you have a field in your model that validates_inclusion_of some array of values. You want to provide a dropdown list in your UI that matches these values, but provides a human readable description beyond what "humanize" can provide.

The solution: Constants. Create a constant in your model that has a hash with the names and the descriptions like so:

class Page < ActiveRecord::Base
  VISIBILITIES = {"Anyone can see it"=>"public", "Nobody can see it"=>"private"}
  validates_inclusion_of :visibility, :in => VISIBILITIES.values
end

Notice how you can validate the inclusion of the field just in the values. Then in the view just add a select field helper and pass it the constant:

select :page, :visibility, Page::VISIBILITIES

This keeps the code simple, readable and DRY.

5. Safely render environment-specific content

I like to use google analytics to keep track of my client's site visitors. However, I don't want to track my development machine, or the staging version of the site - just the production site. Rails makes this easy by making the RAILS_ENV environmental variable available. So anywhere in your rails app you can execute code conditionally - like this snippet from a view:

<%- if "production" == RAILS_ENV -%>
some google analytics javascript...
<%- end -%>

If you're not careful, however, you can actually change the rails environment! Take this snippet of code, for example:

<%- if RAILS_ENV = "development" -%>
output some super-secret code trace...
<%- end -%>

Can you spot what's wrong? Notice the "=" instead of the "==" - when the view execute this code it will actually change the rails_env to development, potentially wreaking all kinds of havoc on your app. In script/console this outputs a warning, and I haven't tried it on production mode, but just to be safe always put the "production" part before the RAILS_ENV part - even if you forget an "=" it will just throw an error.

Another great use of this is creating a banner to alert users to what environment they are looking at. Since staging sites often look exactly like production sites, I like to output a banner at the top of my page to say "hey - you're on the staging site". In my application.html.erb file I often have the following snippet:

<%- unless 'production' == RAILS_ENV -%>
  <div style="padding:.5em;font-weight:bold;text-align:center;background:orange;">
    YOU ARE CURRENTLY ON THE <%= RAILS_ENV.upcase %> SITE
  </div>
<%- end -%>

In edge rails this is a little easier with the Rails object - stay tuned for more on that later.

6. Locals with default values in partials

You can pass locals to partials, making partials very flexible. But sometimes you want to be able to optionally pass a local variable to a partial. You can accomplish this a variety of ways, but my favorite is just to use a simple ||= block at the top. For example if you have an optional "author" local you want to pass in, you can just write:

<%- author ||= nil -%>
Written by <%= author %>

The added benefit of this method is that the partial is self documenting, since you see all of the optional locals you can pass into it right at the top. You can optionally add comments for the required locals as well - depending on how busy you like your partials to be.

Starting ferret at reboot using Capistrano

2008-05-04T14:37:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

Update: 11/26/2011 - Since writing this post I've completely discontinued the use of ferret in favor of Postgres's built-in full-text search

I like using Ferret and acts_as_ferret to add full-text search to my models in Rails in a database-independent way. I've had a very difficult time getting this to work smoothly with my deployment process because the ferret server needs to be run in a separate process.

Every time the server reboots, you need to start the ferret server, and everytime you deploy your app you need to restart the ferret server. You can go to the acts_as_ferret site to get more information about deployment strategies, but here's what's been working for me for a while now.

First, you need to create a startup script that can be run on boot. I've taken mine from the railsmachine tutorial, but you can also use the one from the acts_as_ferret tutorial. Mine looks like this:

# located in config/templates/ferret_ctl.erb
#!/bin/bash
#
# This script starts and stops the ferret DRb server
# chkconfig: 2345 89 36
# description: Ferret search engine for ruby apps.
#
# save the current directory
CURDIR=`pwd`
PATH=/usr/local/bin:$PATH

RORPATH="<%= current_path %>"

case "$1" in
  start)
     cd $RORPATH
     echo "Starting ferret DRb server."
     RAILS_ENV=<%= rails_env %> script/ferret_start
     ;;
  stop)
     cd $RORPATH
     echo "Stopping ferret DRb server."
     RAILS_ENV=<%= rails_env %> script/ferret_stop
    ;;
  *)
     echo $"Usage: $0 {start, stop}"
     exit 1
     ;;
esac

cd $CURDIR

Next, add the following capistrano tasks to your deploy.rb file:

# =============================================================================
# FERRET
# =============================================================================
set :ferret_script_name, "ferret_#{application}_ctl"
set :ferret_ctl, "/etc/init.d/#{ferret_script_name}"

namespace :ferret do
  desc "Uploads the ferret startup script"
  task :install, :roles => :app, :only => {:primary => true} do
    require 'erb'
    upload_path = "#{shared_path}/ferret"
    template = File.read("config/templates/ferret_ctl.erb")
    file = ERB.new(template).result(binding)
    put file, upload_path, :mode => 0755
    sudo "cp #{upload_path} #{ferret_ctl}"
    sudo "chmod +x #{ferret_ctl}"
    sudo "/sbin/chkconfig #{ferret_script_name} on"
  end

  desc "Starts the ferret server"
  task :start, :roles => :app, :only => {:primary => true} do
    sudo "#{ferret_ctl} start"
  end

  desc "Stops the ferret server"
  task :stop, :roles => :app, :only => {:primary => true} do
    sudo "#{ferret_ctl} stop"
  end

  desc "Restarts the ferret server"
  task :restart, :roles => :app, :only => {:primary => true} do
    ferret.stop
    ferret.start
  end

  desc "Deletes the ferret startup script"
  task :uninstall, :roles => :app, :only => {:primary => true} do
    sudo "/sbin/chkconfig #{ferret_script_name} off"
    sudo "rm -rf #{ferret_ctl}"
  end

end
after "deploy:symlink", "ferret:restart"

Now you are ready to deploy - just execute the following commands to get set up with your script:

cap ferret:install
cap deploy

The installation will:

Upload your startup script to /etc/init.d and set the correct permissions
When you deploy it will restart the drb servers before restarting mongrel

Thanks to the folks at Railsmachine for providing detailed instructions about chkconfig, and the acts_as_ferret folks for providing the drb server.

Adding patches to Rails now that it's on git

2008-05-01T05:15:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

It took me a while to figure out how to try to contribute to Rails now that it's on Lighthouse / Github. Here's what I do now, and it seems to work:

First, create a clone of the main git repository (not your fork of it - there's really no reason to fork unless you want others to pull your changes before core accepts them):

Setup your development directories

mkdir rails
cd rails
mkdir patches
git clone git://github.com/rails/rails.git source

Now you have:

rails
|--patches
`--source

Set up your dev branch

Then create a new branch where you'll store just the changes you make for this patch:

git checkout -b your_patch_name master

Create the patch

Make your test-driven changes and when you are ready to create the patch run:

git diff -p master > ../patches/your_patch_name.patch

Setup a throwaway test branch

If you want to test your change

create a new branch and apply the patch (this is useful if other commits have happened since you first created your patch)
run the tests and make sure that everything passes
clear your changes and delete the test branch

git checkout master git pull git checkout -b your_patch_name_test master git apply ../patches/your_patch_name.patch git stash ... git checkout master git stash clear git branch -D your_patch_name

Using git stash allows you to move back to the master branch without taking your changes with you - leaving you with a clean master branch. To learn more about git stash syntax, see the git documentation

Continue development

When it's time to update the code you put in the patch, you can just rebase from the master branch:

git co your_patch_name
git rebase master

Then you can fix whatever changes you need to fix and recreate your patch (or create a new one if your old changes were accepted).

Share you patch

The next step is to go to http://rails.lighthouseapp.com/ and create a ticket. Make sure that you

tag it with "patch" as well as whatever else it applies to
don't forget to upload the patch itself.

When you upload, it appear in the middle of the right-hand column as a blue link - it's hard to find, so look carefully. Then get as many people as possible to grab your changes and test them and add +1's where necessary.

Summary

When all is said and done you are left with a directory full of patches you can apply, a clean master working copy and individual branches for all of your patches that you can maintain over time. While this was possible with subversion, it's way cleaner with git. Contributing to rails is easier than ever!

References

New Rails Core Feature Proposal: Super Sexy Migrations

2008-04-29T07:42:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

If you are running Rails Edge from github, you can now get Super Sexy Migrations, like this:

change_table :videos do |t|
  t.timestamps
  t.belongs_to :goat
  t.string :name, :email, :limit => 20
  t.remove :name, :email # => that's right - remove finally takes an array!
end

Check out the railscast video for more details.

ActsAsStateMachine gets hippified

2008-04-29T01:29:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I was very pleased to learn earlier tonight that acts_as_state_machine has become infinitely hipper.

It's on github, making patches oh so easy to push
It works with any class, not just active record
The "state" column is renamed to aasm_state so that you can have a city, state and zip in your active record model (man that was a pain before)
It's a gem (in both senses of the word)
It's tested with specs, and there's decent coverage
The api is basically the same, making it easy to upgrade

It still has the same issues that the old subversion plugin had, so I incorporated my acts_as_state_machine_hacks plugin into my own fork of aasm on github, which you can check out at http://github.com/zilkey/aasm/wikis

I also published_at some rdocs for my fork at http://aasm.zilkey.com/

Thanks to Scott Barron for updating me on the latest changes, and for a killer gem.

To install my fork of the app:

git clone git://github.com/zilkey/aasm.git aasm
cd aasm
rake gem
sudo uninstall aasm # => if you already have a version installed
sudo gem install pkg/aasm-3.0.0.gem

Enjoy!

Extending Complex Forms: generate valid dom ids

2008-04-05T17:05:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

A few weeks ago I was hired to build a simple event registration form. The requirements were that users needed to be able to:

Register multiple attendees for the same organization in one step
Specify a meal preference for each attendee, using radio buttons

Since I had recently bought Advanced Rails Recipes and watched the Ryan Bates' excellent Railscast on complex forms I thought I was all set to go.

I followed Ryan's instructions exactly and within a few minutes I was up and running with the javascript additions, skinny controllers and fat models and life was good. I fired up my browser, added a few attendee subforms and went to set their meal preference with the radio button when, to my dismay, clicking on any attendee's meal preference set the meal preference for the first! Not good.

Whenever these things happen I run the page through the w3c html validator to make sure that I've got valid HTML. When I ran it through, it gave me several errors - I had lots of repeated ids. Why? If you follow the ARR/railscast example, all of the new subforms will have the same id. In reality, there are 2 things that need to happen:

when the page is loaded Rails needs to set an :index on all of the fields
when the form is added dynamically via javascript, the javascript needs to insert the correct id

Do your homework

ARR prohibits people from reproducing their code from their tutorials without permission (which I didn't obtain). So this blog post won't make much sense unless you read Advanced Rails Recipes and/or watch Railscast on complex forms - both of which I highly recommend. Once you have a working example of that, the rest of this post will make sense.

The setup

For this example, I'll use the following classes:

class Registration < ActiveRecord::Base
  has_many :attendees
end

class Attendee < ActiveRecord::Base
  belongs_to :registration
end

The javascript

So let's get started. First, we need to create a javascript method that will enable us to increment the index value every time - I decided to go with a generic one so that I could reuse it across my app, and have mutliple subfrms of different types on the same page but still be dry:

var Subform = Class.create({
  lineIndex: 1,
  parentElement: "",
  initialize: function(rawHTML, lineIndex, parentElement) {
    this.rawHTML        = rawHTML;
    this.lineIndex      = lineIndex;
    this.parentElement  = parentElement;
  },
  parsedHTML: function() {
    return this.rawHTML.replace(/INDEX/g, this.lineIndex++);
  },
  add: function() {
    new Insertion.Bottom($(this.parentElement), this.parsedHTML());
  }
});

Next, we need to set the index when the page loads. I accomplished that like so:

# /app/views/layouts/application.html.erb

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title><%= yield :title %></title>
    <%= javascript_include_tag :defaults, :cache => 'defaults' %>
    <%= yield :head %>
  </head>
  <body>
    <%= yield %>
  </body>
</html>

# /app/views/registrations/_form.html.erb

<%- content_for :head do -%>
  <script type="text/javascript" charset="utf-8">
    //<![CDATA[
    attendeeForm = new Subform('<%= escape_javascript(render(:partial => "attendee", :object => Attendee.new)) %>',<%= @registration.attendees.length %>,'attendees');
    //]]>
  </script>
<%- end -%>

In Ryan's original recipe he creates a rails helper to create the add link. Now that we've written the javscript ourselves we no longer need the helper - our "add" link now look like this:

<%= link_to_function 'Add Attendee', "attendeeForm.add()" %>

The partial

We need to add the index to all of the form helpers, which will require some work. In addition, we need to make sure that all of the radio buttons have unique ids and that all of the labels have ids that match up with the radio buttons. So here's what my partial looks like:

<div class="attendee"><%-
  index ||= "INDEX"
  new_or_existing = attendee.new_record? ? 'new' : 'existing'
  id_or_index = attendee.new_record? ? index : attendee.id
  prefix = "registration[#{new_or_existing}_attendee_attributes][]"
-%>

  <% fields_for prefix, attendee do |attendee_form| -%>
  <p><%= attendee_form.label :email, nil, :index => id_or_index %> <%= attendee_form.text_field :email, :index => id_or_index %> </p>

  <%- MealPreference.find(:all).each do |preference| -%>
    <p>
       <%- radio_id = "registration_#{new_or_existing}_attendee_attributes_#{id_or_index}_meal_preference_#{preference.name}" -%>
       <%= attendee_form.radio_button :meal_preference, preference.name, :id => radio_id, :index => id_or_index %>
       <%= content_tag :label, preference.name, :class => "radio", :for => radio_id %>
     </p>
  <%- end -%>
  <%= content_tag :p, link_to_function("Remove this attendee", "if(confirm('Are you sure?')){$(this).up('.attendee').remove()}") %>
  <% end -%>
</div>

What just happened? I added an index to every field. For existing records, this index will correspond to the attendee.id. For new records, it will be the string "INDEX". If you recall from the javascript above the parsedHTML function replaced the word INDEX with the correct numeric index.

NOTE: getting correct radio_button ids requires my label_with_index plugin if you are running gem rails, but it looks like radio buttons create correct ids in edge.

The form

This means, however, that you need to pass an index into the partial for existing records. In my form, I've got the following:

<h3>Attendees</h3>
<div id="attendees">
  <%- @registration.attendees.each_with_index do |attendee, index| -%>
    <%= render :partial => "attendee", :object => attendee, :locals => {:index => index} %>
  <%- end -%>
</div>
<p id="add-attendee">
<%= link_to_function 'Add Attendee', "attendeeForm.add()" %>
</p>

Note the use of each_with_index so that we can pass the correct index in. "But wait!" you say, "What if the attendee is an existing record? Won't that mess this up?" Fear not - in the partial we first check whether it's a new record, and only use the index if it's a new record.

The model

Making the changes in the model is trivial. The existing_attributes stay exactly the same - but we have to make one small change to the new attributes:

Old:

# app/models/registration.rb

# add all new attendees
def new_attendee_attributes=(attendee_attributes)
  attendee_attributes.each do |attributes|
    attendees.build(attributes)
  end
end

Changes to:

# app/models/registration.rb

# add all new attendees
def new_attendee_attributes=(attendee_attributes)
  attendee_attributes.each do |index, attributes|
    attendees.build(attributes)
  end
end

And voila! Correct dom ids and reusable javascript.

Credits

While I wrote the javascript in that example I reconstructed it from another javascript snippet I had seen (maybe on a railscast, or in the source code for some other rails app like Basecamp or Blinksale). If that looks like your javascript, please contact me at jeff at zilkey . com - I can't find the original source right now. Other credits include:

References

Introducing label_with_index: a simple rails plugin

2008-04-05T16:08:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

In this post I will describe a plugin that extends the functionality of Rails labels.

The problem

A while back Rails introduced the label helper, so you can can easily add labels to forms like so:

<%= label :user, :name %>
# => <label for="user_2_name">Name</label>

Unfortunately the person who committed that change neglected to add support for the auto index and :index options. For example, take the following code snippet:

<%= text_field :user, :name, :index => 1%>
# => <input id="user_1_name" name="user[1][name]" size="30" type="text" />

Following the principle of least surprise, you might assume that labels would work the same way, but they don't:

<%= label :user, :name, nil, :index => 1%>
# => <label for="user_name" index="1">Name</label>

The fix

I've just released a plugin called label_with_index that fixes this. Now label helpers take advantage of the autoindex feature and :index keys as you would expect:

<%= label :user, :name, nil, :index => 1%>
# => <label for="user_1_name">Name</label>

Fixing radio button ids

Rails has also had a bug for quite some time where it will by default emit radio button ids that will fail XHTML validation. To boot, they even advertise this in the docs. Here's what's written on http://api.rubyonrails.com/classes/ActionView/Helpers/FormHelper.html :

# Let's say that @post.category returns "rails":
radio_button("post", "category", "rails")
radio_button("post", "category", "java")
# => <input type="radio" id="post_category" name="post[category]" value="rails" checked="checked" />
#    <input type="radio" id="post_category" name="post[category]" value="java" />

See how those two radio buttons have the same id? Not only will that fail validation, but it can cause unexpected javascript behavior and will cause very odd label-clicking results (clicking the label will most likely highlight the first radio button, regardless of which label is clicked).

label_with_index also fixes this in two ways:

Makes the id unique (or at least, as unique as the option is)
Adds a :value option to the label helper that can match the radio button's value

Before:

radio_button("post", "category", "java")
label("post", "category")
 # => <input type="radio" id="post_category" name="post[category]" value="java" />
 # => <label for="post_category">Category</label>

After:

radio_button("post", "category", "java")
label("post", "category", nil, :value => "java")
 # => <input type="radio" id="post_category_java" name="post[category]" value="java" />
 # => <label for="post_category_java">Category</label>

So with this plugin the rails label helper, and the radio_button helper have support for creating valid ids out of the box.

Installation

git clone git://github.com/zilkey/label_with_index.git vendor/plugins/label_with_index

See the rdoc at http://label_with_index.zilkey.com/

To Do

Create a fork of rails on github and add this to core with tests

References

Notes:

It appears that the radio button id may have been fixed on edge rails - I haven't tested it out fully and I'm not sure if all of the svn patches are synced up on github, so I'll wait until things settle a bit and make changes as necessary.

Breaking the cycle of doom, Part 1: Understanding the cycle

2008-03-25T01:45:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I've seen it time and time again - it all starts with a 70-page RFP from a non-profit that wants donor-relation management, content management, events management, complete real-time integration with their legacy systems, web services integration with their partners, mass-email capabilities, online donations and an online store, real-time tracking of the work they are doing in the field updated from satellites. They want a quote, and they want it now. The cheaper the better.

Then the 60-page responses come flooding in as well - there's the Indian firm that promises all of that, plus several weeks of training for $15K - delivered in 6 weeks or less. There's the massive vendor that's throws in $125K as a starting point, vague about the timing and the custom programming costs but more than willing to put you in contact with one of their 50 sales representatives. There's the small firm that recommends using a few existing tools, using a few pre-built tools and offers an expensive but competitive bid.

Depending on what the non-profit chooses, one of a few things happen. The Indian firm ends up charging 3-4 times what they originally planned since nobody at the non-profit realized that for $15K the requirements gathering phase amounts to little more than reading the RFP again, so every piece of code that was written had to be re-written multiple times before it was adequate. That big vendor? Well, they forgot to mention the $1 per email fee, the $500/hour training fee, the $4,500 AS-400 integration fee and the fact that nobody actually knows how to download that data from the field to a GPS, so that feature was scrapped. Oh, did I mention the $2K per month hosting fee? Over at the smaller firm they are really making an effort - but staffing is an issue and their contractors are spread thinly across multiple projects and progress is very slow. As the requirements change, the small firm adapts quickly, but it means that lots of the core functionality keeps getting pushed off.

As bleak as those scenarios may seem, more often than not what I've observed in real life is that many non-profits experience most if not all of these in an almost cyclical way. Once burned by big vendors, they turn the projects in-house, but then have staffing problems and outsource again, each time around paying again and again for the same 90% of the functionality they already had and never really getting that last 10% that actually makes people's lives better. This is the cycle of doom.

I don't propose to have a solution to the cycle of doom but I am convinced that using Ruby on Rails and agile methodologies can be a big part of the solution. Over the next few weeks I'll be posting several non-technical posts for those in non-profits who are trying to figure out what they need as well as technical posts for developers who are trying to use Ruby on Rails to build their personal product-lines for non-profits.

Advanced acts_as_list scope with multiple columns

2008-03-23T21:57:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I just ran across a problem that I'm sure very few other people will encounter, but if I can help just one googler....

Scenario

You are using acts_as_list, and you want to scope your list by more than one column and one of the columns is a reserved word. You went to the rails documentation page for acts_as_list

class Element < ActiveRecord::Base
   belongs_to :page
   acts_as_list :scope => 'page_id = #{page_id} and `group` = \'#{group}\' '
end

Whoa - that's some ugly code. Let's see what's happening:

The string you pass in to :scope is used to dynamically create a method called "scope_condition" with the contents of the string
The :scope has to be in single quotes so that the contents of the #{} blocks don't get evaluated
The word "group" has to be in special quotes, otherwise it will throw a MYSQL error

There are a number of problems with the code above - namely:

The combination of single, double and angled quotes makes it very difficult to read
The angled-quotes will not work for every database adapter
The string contains #{} blocks, but they are not evaluated - instead they are evaluated later

The fix

Making the code database-independent is easy. Rails provides a method on every connection called "quote_column_name" which adds the correct quotes for whichever database adapter you are using. The connection object is a part of every Active Record instance, so the following line does the trick:

class Element < ActiveRecord::Base
  belongs_to :page
  acts_as_list :scope => 'page_id = #{page_id} AND #{connection.quote_column_name("group")} = \'#{group}\' '
end

Making the code easier to read is almost as simple - just define your own "scope_condition" method. The final code will look like this:

class Element < ActiveRecord::Base
  belongs_to :page
  acts_as_list

  # scope_condition for acts_as_list
  def scope_condition
    "page_id = #{page_id} AND #{connection.quote_column_name("group")} = #{quote_value(group)}"
  end
end

Now we're talkin'. The scope_condition is now database-independent, the quotes make sense and programs like TextMate will highlight the syntax appropriately.

References

Rendering will_paginate links without previous and next buttons

2008-03-16T15:59:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

I recently needed to build a page that had a paginated list of items. I immediately did what I always do for pagination and grabbed the will_paginate plugin (also released as a gem). 2 lines of code later and pagination was working.

Then I noticed that the design mockup I had been given did not include room for previous or next buttons, despite the fact that most pagination guides recommend using them. My first thought was to see if setting the :prev_label and :next_label to nil would work, but it still output the html tags and also output the current page number twice - not quite what I wanted.

My next thought was that I could patch the LinkRenderer - and then I realized that the folks over at err.the_blog already prepared for exactly this scenario by allowing others to write custom link renderers. Here's how it works:

In your view, add the following:

<%= will_paginate @items, :renderer => 'CustomPaginationRenderer' %>

Then, drop a file anywhere in your load path (config/initializers, lib directory, a plugin etc...) with the following code:

class CustomPaginationRenderer < WillPaginate::LinkRenderer
  def to_html
    links = @options[:page_links] ? windowed_links : []
    html = links.join(@options[:separator])
    @options[:container] ? @template.content_tag(:div, html, html_attributes) : html
  end
end

This creates a new link renderer that inherits from the default WillPaginate::LinkRenderer and overrides just one method: to_html. I just copied the to_html from the original renderer and removed the two lines that added the previous and next links.

Given the complexity of the logic behind rendering links and all of the subtle differences in the way links can be displayed, will_paginate could have been a much more complex plugin. Instead, it is simple and extremely easy to understand and extend. I highly recommend that plugin authors and paginators alike check it out.

Setting up and deploying a rails app to a remote git server

2008-03-10T19:34:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

(Updated on 3/31/08 with new "edge" branch checkout)

In a previous post I wrote about how to get git installed on CentOS. Now that git is installed it's time to actually set up a remote repository with git. In this tutorial I'll explain how to:

create a git user on the remote server and configure the new git user correctly
configure the deploy user correctly
create a rails app locally and push it to the remote git server
set up capistrano for deploying the app using git

Assumptions

you deploy under the user "deploy"
your domain name is example.com
you have installed git at /usr/local/bin/git
you have root access (otherwise it might have to skip the part about setting up the git user's shell)

Prepare the remote server

First, log into your server as deploy, create the git user and setup your ssh keys.

sudo adduser git
sudo passwd git
ssh-keygen -t rsa -f ~/.ssh/id_rsa -C "deploy@example.com"
ssh git@example.com 'mkdir ~/.ssh;chmod 700 ~/.ssh'
scp ~/.ssh/id_rsa.pub git@example.com:~/.ssh/authorized_keys
ssh git@example.com 'chmod 600 ~/.ssh/authorized_keys'

As a convenience, you may want to add your ssh key to the git user's authorized_keys. To do so, execute the following on your local machine:

cat ~/.ssh/id_rsa.pub | ssh git@example.com 'sh -c "cat - >>~/.ssh/authorized_keys"'

(you may have to change this to id_dsa.pub - or whatever your public key name is).

Back on the server, if you haven't already, you'll also want to set up your git config files for the deploy user:

git config --global user.name "Deploy"
git config --global user.email "deploy@example.com"

That name and username can be anything you want it to be.

Next, you'll have to add a shell to /etc/shells. To do so you'll need to be root:

su -
echo '/usr/local/bin/git-shell'>> /etc/shells
exit

To make sure this worked, you can type

cat /etc/shells

Now log in as the git user and set a few things up:

su - git
git config --global user.name "Git"
git config --global user.email "git@example.com"
chsh
[when prompted - enter /usr/local/bin/git-shell]
exit

Create the app

So now you have a git user with a slightly more secure git shell and your ssh keys are set up from both your local machine and your deploy user's account. It's time to create the rails app on your local machine. For this to work, you'll need to make sure that you have the capistrano and railsmachine gems installed. Next create a rails app, capify and railsmachinify it and type a few git commands.

sudo gem install capistrano railsmachine --no-ri --no-rdoc
rails git_import_test
cd git_import_test
capify .
railsmachine --apply-to . --name git_import_test --domain example.com

Now go into config/deploy.rb and add the following task to the bottom of the file (you can also add this to your ~/.caprc file to use it across all of your rails apps):

require 'fileutils'
Capistrano::Configuration.instance(:must_exist).load do

  namespace :git do
    desc "Setup directory structure and initialize git repository on remote server"
    task :setup, :roles => :scm do
      dir =  "#{deploy_to}/git"
      run    "mkdir -p #{dir}"
      sudo   "chown -R deploy:deploy #{dir}"
      run   "cd #{dir} && git --bare init"
      run   "chmod 770 #{dir}"
      sudo   "chown -R git:git #{dir}"
    end

    desc "Import code into remote git repository."
    task :import  do
      puts "Initializing local git repository"
      system  "git init"

      puts "Adding remote server pointing to #{repository}"
      system  "git remote add origin #{repository}"

      puts "Adding .gitignore file"
      system "echo 'log/*'>> .gitignore"
      system "echo 'tmp/*'>> .gitignore"
      system "echo '.DS_Store'>> .gitignore"
      system "echo 'public/cache/**/*'>> .gitignore"
      system "git add .gitignore"

      puts "Committing application locally"
      system "git add *"
      system 'git commit -a -v -m "initial import of site"'

      puts "Pushing application to the remote server.  The name of the branch is:"
      system  "git remote"
      system  "git push origin master"
      puts "Creating edge branch on remote"
      system "git push origin master:refs/heads/edge"
      puts "create a local tracking edge branch"
      system "git branch --track edge origin/edge"
      puts "checking out edge repository"
      system "git checkout edge"
      puts "git setup complete"
      puts "You can clone this repository with git clone #{repository}"
    end
  end
end

This will

Create the local repository
Add an ignore file
Add all files
Push to the master
Create a new edge branch on the local and remote
Switch the local branch to edge

Next, update your deploy.rb file to point to your new git repository and you'll be ready to deploy. Make sure your deploy.rb file has entries that look like:

set :repository,    "ssh://git@example.com#{deploy_to}/git"
set :scm,           :git

Deploy

To deploy you can use the tasks that come with the railsmachine gem, along with your new git capistrano task:

cap deploy:setup
cap git:setup
cap apache:configure
cap mongrel:cluster:configure
cap git:import

If you are using mysql, you will have to also run

cap mysql:setup

Now you can deploy, run migrations, start your mongrels and restart your web server with

cap deploy:cold

References:

This post heavily references:

http://jointheconversation.org/railsgit

Bootstrap your app: plug-in with sake

2008-03-08T03:40:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

This is the first in a series called "Bootstrap Your App" where I'll detail how I've set up my local development environment to get new rails sites up and running quickly using "sake":http://errtheblog.com/posts/60-sake-bomb and generators.

I'm a ruby on rails developer who focuses primarily on websites for small-businesses and non-profits, so I build lots of small rails apps from the ground up. Every time I start a site, I go through a few common tasks:

Install all of my favorite plugins
Run the generators from those plugins (like rspec and acts_as_authenticated)
Install the hacks, patches and recipes I've gathered along the way, but never bothered to put into plugins
Set the app's name as the prefix for the exception notifier

For some apps, I'll install and configure ssl, for others I might install and configure account_location. Some of my clients deploy to RailsMachine, and some to Slicehost. Some require email notification for user registrations, others don't. Some use SVN, others git.

When I started to think about all of the different configurations that a client might need, I quickly realized that approaches like Courtenay's sample rails apps didn't quite fit for me. I needed a way to quickly add features to a site, and have complete customization.

Grok Sake

After going through several different setups, I've settled into using rake tasks (through sake) and building generators. Sake and generators are both simple and portable and when used correctly can give you massive productivity gains.

If you haven't checked out sake do so immediately. Do not pass go. Do not collect $200. Sake allows you share rake tasks across different sites (and even different machines). Sake makes bootstrapping your apps very easy.

Plug-In

So the first task on my list above was to install common plugins. I went through my apps and identified the ones I used most commonly, and split them up into roughly four categories: common, speccing, ecommerce and cms (content management system) - your mileage will vary. Then I wrote a quick rake task that would install the plugins using the standard rails script/plugin install, or using piston import. The rake file looks like this:

namespace :zilkey do
  # A set of tasks that add plugins to the app either using script/plugin or piston
  namespace :plugins do
    desc "installs common plugins via piston or rails.  Options:\n  * set=[common|ecommerce|speccing|cms] (required)\n  * method=[piston|rails]\n  * pretend=[true|false]"
    task :install do
      sets = {
        :speccing => {
          :rspec => "svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec",
          :rspec_on_rails => "svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails",
          :spider_test => "svn://caboo.se/plugins/court3nay/spider_test",
        },
        :common => {
          :attachment_fu => "http://svn.techno-weenie.net/projects/plugins/attachment_fu/",
          :will_paginate => "svn://errtheblog.com/svn/plugins/will_paginate",
          :geokit =>"svn://rubyforge.org/var/svn/geokit/trunk",
          :annotate_models => "http://repo.pragprog.com/svn/Public/plugins/annotate_models/",
          :exception_notification => "http://dev.rubyonrails.org/svn/rails/plugins/exception_notification/",
          :tztime => "http://dev.rubyonrails.com/svn/rails/plugins/tztime/",
          :tzinfo_timezone => "http://dev.rubyonrails.org/svn/rails/plugins/tzinfo_timezone/",
          :atom_feed_helper => "http://svn.rubyonrails.org/rails/plugins/atom_feed_helper/",
          :action_mailer_tls => "http://svn.nanorails.com/plugins/action_mailer_tls/",
          :acts_as_authenticated => "http://svn.techno-weenie.net/projects/plugins/acts_as_authenticated/",
        },
        :ecommerce => {
          :active_merchant => "http://activemerchant.googlecode.com/svn/trunk/active_merchant",
          :ssl_requirement => "http://svn.rubyonrails.org/rails/plugins/ssl_requirement/",
        },
        :cms => {
          :fckeditor => "svn://rubyforge.org/var/svn/fckeditorp/trunk/fckeditor",
          :better_nested_set =>"svn://rubyforge.org/var/svn/betternestedset/trunk",
          :acts_as_ferret =>"svn://projects.jkraemer.net/acts_as_ferret/tags/stable/acts_as_ferret",
          :us_states =>"http://svn.techno-weenie.net/projects/plugins/us_states/",
        },
      }

      raise "You must specify set=[#{sets.keys.join(",")}]" unless sets.keys.map{|k|k.to_s}.include?(ENV['set'])

      set = sets[ENV['set'].to_sym]
      plugins = set.to_a.map
      text = set.to_a.map{|a|a.first}.join("\n  * ")
      run_method = ENV['pretend'] == "true" ? :p : :system
      install_method = (ENV['method'] || "rails").to_sym

      set.each do |name,url|
        if install_method == :piston
          send run_method, "svn up"
          send run_method, "piston import #{url} vendor/plugins/#{name}"
        elsif install_method == :external
          send run_method, "script/plugin install #{url} -x"
        else
          send run_method, "script/plugin install #{url} --force"
        end
      end
      p "don't forget to run svn commit -m \"Added #{text} plugins to vendor/plugins via piston\"" if run_method == :piston
    end
  end

end

It's not the most beautiful code I've ever written, but it works. The bulk of the task is just the hash that stores all of the names and urls of the plugins, grouped into the categories that I find most useful right now. To run it, I use commands like:

$rake zilkey:plugins:install set=common #=> installs using script/plugin install
$rake zilkey:plugins:install set=common method=external # => installas using script/plugin install -x
$rake zilkey:plugins:install set=common method=piston # => installs via piston import
$rake zilkey:plugins:install set=common pretend=true # => echos the commands to the screen, but doesn't execute them

Great - so the task is written and working. To get it up and running with sake I just typed:

$sake -i lib/tasks/zilkey.rake zilkey:plugins:install

Now I can install these plugins to any app on my machine (or any other machine, for that matter: Google sake for more info on how to share tasks). Let's try it out:

$rails newsite && cd newsite
$sake zilkey:plugins:install set=speccing
$ls vendor/plugins
rspec rspec_on_rails spider_test

There you have it - one common task down. In the next article I'll discuss how to take advantage of custom generators to productize your apps.

Installing Git on Railsmachine (CentOS 4.4)

2008-03-05T00:05:00+00:00

This blog post was written in 2008. Information and links in this post may be outdated.

[updated 03/09/2008]

[updated 03/21/2008 for Git 1.5.4.4]

[you can also follow the RailsMachine wiki instructions ]

Keeping up with the Joneses

A few days ago I read that mephisto 0.8 was released and that all of the cool kids were grabbing it from the git repository. I promptly got hip to git from John Nunemaker's post on git and github and grabbed the peepcode screencast to get started.

A few minutes later I was ready to deploy to my Rails Machine slice running CentOS 4.4.

Not so yummy

I dig package managers, and since git is really a collection of a few dozen executables it's the perfect candidate. So I naively typed

yum install git

thinking that it might "just work", but instead it completely blew up on me with errors such as:

Error: Missing Dependency: libaprutil-0.so.0 is needed by package subversion
Error: Missing Dependency: libapr-0.so.0 is needed by package subversion

After a few support emails with Rails Machine, it seemed like there might be some discrepancies with the rpms from the RailsMachine repo and the rpmforge repo. Not being familiar with yum, I had no idea what to do (and still don't), so I abandoned yum altogether.

Consider the source

Thanks to Rob over at Rails Machine and cactus over at the slicehost forum I got git installed from source on the slice. Here's what worked for me:

Follow the instructions from Dan Insley and setup the following repositories:

to follow the steps below and git will be installed in a snap:

$ sudo touch /etc/yum.repos.d/atrpms.repo /etc/yum.repos.d/dag.repo

[atrpms]
name=ATrpms for Enterprise Linux $releasever - $basearch
baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable
enabled=0
gpgcheck=1
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms

[dag]
name=Dag
enabled=0
baseurl=http://dag.freshrpms.net/redhat/el4/en/$basearch/dag
http://ftp.heanet.ie/pub/freshrpms/pub/dag/redhat/el4/en/i386/dag/
gpgcheck=1
gpgkey=http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt

sudo yum --enablerepo=dag --enablerepo=atrpms install asciidoc xmlto curl curl-devel
mkdir -p ~/sources
cd ~/sources
wget http://kernel.org/pub/software/scm/git/git-1.5.4.4.tar.gz
tar xvzf git-1.5.4.4.tar.gz
cd git-1.5.4.4
make configure
./configure --prefix=/usr/local
NO_TCLTK=yes make all doc
NO_TCLTK=yes sudo make install install-doc

You can also save yourself some time if you don't need the docs by changing those last 2 lines to:

NO_TCLTK=yes make all
NO_TCLTK=yes sudo make install

Depending on your setup, the "NO_TCLTK=yes" flag might not be necessary. You can always try it without first if you are unsure, but I've needed it on all of my RailsMachine slices.

Jeff Dean - Ruby on Rails Programmer

Serving a NodeJS coffee-script app with apache and forever

Setting up a simple, private gem server

The basics of gem sources

Generating the index

Making it private

Referencing the private gem server

Pushing gems

Developing locally with Oracle and Ruby on a Mac

Install VirtualBox

Install the Oracle Virtual Machine

Configuring the Virtual Machine

Setting up the Oracle Database

Using the Oracle Web Console

Installing Instant Client on the Mac

Install a 32-bit version of Ruby 1.9.2 on your machine

Running commands with ruby-oci8

Rolling your own Akismet client in Ruby

Speed up your Ruby loops with hashes

Using Haml filters to embed data in Haml templates

Rails.cache: Memcached, development mode and offline cache invalidation

Environment files

You don't need to have memcached installed to develop locally

If memcached is running, you need to set cache_classes to true

Marshal.dump is finicky

Use a separate environment to test locally

Clearing the cache

Clearing the cache with cron

Networking Mac and Windows with VMWare

Step1: Get Setup (the expensive part)

Step 2: Find your network address

References

Tutorial: Creating plugins in Rails

Creating Plugin Basics

Create the basic app

Create the plugin

Testing Setup

Update a core class: Adding "to_squawk" to String

Adding an acts_as_yaffle method to ActiveRecord models

Create a view helper

Create a migration generator

Adding custom generator commands

Adding Routes

Generate RDoc Documentation

Working with init.rb

Storing models, views, helpers, and controllers in your plugins

Storing plugins in alternate locations

Plugin Loaders and Plugin Locators

Custom Plugin Generators

References

Demo apps

There should be a demo app start kit

Vendor everything

Pre-populate the database

Demos should ideally have specs

Documentation should be redundant

Rails View Tips

1. Access view helpers from the console

2. Word Wrap

3. Partial Counter

4. Keep selects and model validations in sync with constants

5. Safely render environment-specific content

6. Locals with default values in partials

Starting ferret at reboot using Capistrano

Adding patches to Rails now that it's on git

Setup your development directories

Set up your dev branch

Create the patch

Setup a throwaway test branch

Continue development

Share you patch

Summary

References

New Rails Core Feature Proposal: Super Sexy Migrations

ActsAsStateMachine gets hippified

Extending Complex Forms: generate valid dom ids

Do your homework

The setup

The javascript

The partial

Adding an `acts_as_yaffle` method to ActiveRecord models