The first thing you need to do is to set up your server and install the proper libraries, so fire up a terminal window and SSH into your server, after you have done this you will need to execute a few commands.

Configuring the server

Once you’re done configuring your server you need to install Ruby, for this you can either use RVM or rbenv, but I’m going to leave this choice to you.

Uploading to github

Next we’re going to upload our app to github. Head on over to the github and create a new repository.  Once you’ve done this, fire up a terminal on your local machine and “cd” into the root of your rails app.  Now, I’m going to assume you already have some experience with git commands.  If not, never fear, we’ve got this covered.  Once you’re in the root of your rails app run the following commands:

git init
git add .
git commit -m "<message>"
git remote add origin git@github.com:<username>/<git repo>.git
git push origin master

What we’ve done here is initialize an empty git repository inside the root of your rails app and add all your files to the git repo (If you need to ignore files you can edit the .gitignore file.) Next, we provided a message to the commit and added the remote origin, which will track our local development. Finally, we pushed the changes in our master branch to github.

Installing Capistrano

We’re almost there! It”s time to setup Capistrano for deployment, and the first step is too add it to the Gemfile:

gem 'capistrano'

Save the Gemfile and run the

bundle

command to install the gem. Next we’re going to capify our project, on a terminal window run:

capify .

This will create 2 files: one is the Cap file which will be placed in your root folder. By the way, if you’re using the rails asset pipeline, you will need to uncomment the line -load ‘deploy/assets’-. The second file is the deploy.rb file which will be placed inside the config folder of your rails app, In deploy.rb you will configure all the commands capistrano will be running on our remote server. You can copy and paste the example provided here:

require "bundler/capistrano"

# Define your server here
server "<server>", :web, :app, :db, primary: true

# Set application settings
set :application, "<app_name>"
set :user, "<deployment_user>" # As defined on your server
set :deploy_to, "/home/#{user}/apps/#{application}" # Directory in which the deployment will take place
set :deploy_via, :remote_cache
set :use_sudo, false

set :scm, "git"
set :repository, "git@github.com:<git_user>/#{application}.git"
set :branch, "master"

default_run_options[:pty] = true
ssh_options[:forward_agent] = true

after "deploy", "deploy:cleanup" # keep only the last 5 releases

namespace :deploy do
  %w[start stop restart].each do |command|
    desc "#{command} unicorn server"
    task command, roles: :app, except: {no_release: true} do
      run "/etc/init.d/unicorn_#{application} #{command}" # Using unicorn as the app server
    end
  end

  task :setup_config, roles: :app do
    sudo "ln -nfs #{current_path}/config/nginx.conf /etc/nginx/sites-enabled/#{application}"
    sudo "ln -nfs #{current_path}/config/unicorn_ini.sh /etc/init.d/unicorn_#{application}"
    run "mkdir -p #{shared_path}/config"
    put File.read("config/database.yml"), "#{shared_path}/config/database.yml"
    puts "Now edit the config files in #{shared_path}."
  end
  after "deploy:setup", "deploy:setup_config"

  task :symlink_config, roles: :app do
    run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
  end
  after "deploy:finalize_update", "deploy:symlink_config"

  desc "Make sure local git is in sync with remote."
  task :check_revision, roles: :web do
    unless `git rev-parse HEAD` == `git rev-parse origin/master`
      puts "WARNING: HEAD is not the same as origin/master"
      puts "Run `git push` to sync changes."
      exit
    end
  end
  before "deploy", "deploy:check_revision"
end

As you can see, this deploy file uses unicorn as the server (which I recommend because of its stability, but you can use the server of your choice.) After you are finished setting up your deploy file with your custom configuration, create two files under your config folder: one named nginx.conf, and another one named unicorn.rb. Feel free to use the examples provided here:

Nginx.conf

upstream unicorn {
  server unix:/tmp/unicorn.<app_name>.sock fail_timeout=0;
}

server {
	listen 80 default deferred;
	server_name <your_servername>;
	if ($host = '<your_servername>' ) {
		rewrite ^/(.*)$ http://<your_servername>/$1 permanent;
	}
  root /home/deployer/apps/<app_name>/current/public;

  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
  }

  try_files $uri/index.html $uri @unicorn;
  
  location @unicorn {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://unicorn;
  }

  error_page 500 502 503 504 /500.html;
  client_max_body_size 4G;
  keepalive_timeout 10;
}

Unicorn.rb

# Define your root directory
root = "/home/deployer/apps/gifroll/current"

# Define worker directory for Unicorn
working_directory root

# Location of PID file
pid "#{root}/tmp/pids/unicorn.pid"

# Define Log paths
stderr_path "#{root}/log/unicorn.log"
stdout_path "#{root}/log/unicorn.log"

# Listen on a UNIX data socket
listen "/tmp/unicorn.gifroll.sock"

# 16 worker processes for production environment
worker_processes 16

# Load rails before forking workers for better worker spawn time
preload_app true

# Restart workes hangin' out for more than 240 secs
timeout 240

Final Steps

Create one final file under your config folder called unicorn_ini.sh edit the file and copy and paste the following code:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          unicorn
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Manage unicorn server
# Description:       Start, stop, restart unicorn server for a specific application.
### END INIT INFO
set -e

# Feel free to change any of the following variables for your app:
TIMEOUT=${TIMEOUT-60}
APP_ROOT=/home/deployer/apps/<app_name>/current
PID=$APP_ROOT/tmp/pids/unicorn.pid
CMD="cd $APP_ROOT; bundle exec unicorn -D -c $APP_ROOT/config/unicorn.rb -E production"
AS_USER=<user>
set -u

OLD_PIN="$PID.oldbin"

sig () {
  test -s "$PID" && kill -$1 `cat $PID`
}

oldsig () {
  test -s $OLD_PIN && kill -$1 `cat $OLD_PIN`
}

run () {
  if [ "$(id -un)" = "$AS_USER" ]; then
    eval $1
  else
    su -c "$1" - $AS_USER
  fi
}

case "$1" in
start)
  sig 0 && echo >&2 "Already running" && exit 0
  run "$CMD"
  ;;
stop)
  sig QUIT && exit 0
  echo >&2 "Not running"
  ;;
force-stop)
  sig TERM && exit 0
  echo >&2 "Not running"
  ;;
restart|reload)
  sig HUP && echo reloaded OK && exit 0
  echo >&2 "Couldn't reload, starting '$CMD' instead"
  run "$CMD"
  ;;
upgrade)
  if sig USR2 && sleep 2 && sig 0 && oldsig QUIT
  then
    n=$TIMEOUT
    while test -s $OLD_PIN && test $n -ge 0
    do
      printf '.' && sleep 1 && n=$(( $n - 1 ))
    done
    echo

    if test $n -lt 0 && test -s $OLD_PIN
    then
      echo >&2 "$OLD_PIN still exists after $TIMEOUT seconds"
      exit 1
    fi
    exit 0
  fi
  echo >&2 "Couldn't upgrade, starting '$CMD' instead"
  run "$CMD"
  ;;
reopen-logs)
  sig USR1
  ;;
*)
  echo >&2 "Usage: $0 <start|stop|restart|upgrade|force-stop|reopen-logs>"
  exit 1
  ;;
esac

We have all the files we need, so let’s setup the server to deploy our app.  Push the latest changes to github and after that run the following command:

cap deploy:setup

This will create 2 folders under the /<user>/apps/<app_name> on your server. as well as some links for the unicorn and nginx configration files to place them in the proper location. After the setup is complete “cd” into the /<user>/apps/<app_name>/shared/config and edit the database.yml file to work with your database.

Once you’ve done this, give the server access to the git repository by running the following command on our development machine:

ssh-add

Now we’re all setup and ready to deploy. Let’s try this out by running:

cap deploy:cold

And watch it go.  A “cold” deploy will run the migrations and do a server start and restart.  In my experience, it will rarely work the first time you will usually get some errors here and there.  The errors will usually point you in the right direction.

If everything went OK, congratulations!  You just deployed your app using unicorn, nginx and capistrano. Hope you liked it!

Redis is a key-value store that stands out from others, like memcached, in that it has built-in support for data structures like lists, sets, and hashes, and that it can persist data to disk. As such, it is quite useful as both a cache store and as a full-fledged, NoSQL data store. In this article, we will walk through a basic usage example in order to learn how to use Redis within a Rails application.

A Basic Example

Imagine that we have written a simple blogging platform in Rails. We use MySQL as our main database, which is where we store all post content, comments, and user accounts. Let’s say it’s hosted at myrailsblog.com. We get regular traffic directly to posts, thanks to our game-changing social media strategy. There are direct links to these posts all over the internet.

The one thing we’re not crazy about is that a URL to a post looks like this: http://myrailsblog.com/321. Aside from the fact that it’s a little ugly and exposes internal ids, we could get better search engine rankings if we implemented slugs for post URLs. We would like the URL to look like this instead: http://myrailsblog.com/using-redis-with-rails.

So we decide that from now on, posts are going to have slugs which are auto-generated from the title. We will find posts by slug rather than by id. When a new post is created, it will generate a slug which gets stored in a new column of our posts table. However, our platform allows editing of post titles, and furthermore, we would like authors to be able to customize the slug in case the auto-generated one turns out to be undesirable for any reason. This means that a post URL can change after it has been published. What happens when someone follows an old URL? Rather than awkwardly spitting back a 404, our platform should find the correct post from the old slug. This means that all old slugs need to continue to reference the post.

Our natural approach as Rails developers to finding a post by its slug would be to implement something like this:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  
  before_filter :find_post
  
  protected
    
    def find_post
      unless @post = Post.where(:slug => params[:id]).first
        # what do we do here?
      end
    end
end

# app/models/post.rb
class Post < ActiveRecord::Base
  def to_param
    self.slug
  end
end

The questions start flying when we think about the “what do we do here?” bit. Conceptually, we need to check the :id parameter against the post’s old slugs to see if any of them match. One possible approach would be to create a Slug model, and set Posts to have_many :slugs.

However, we can solve this problem a little more elegantly with Redis by mapping slugs to post ids. We can utilize the hash data type to store all slugs under one main key. We will get O(1) lookup time, and we won’t need to migrate the database. In the end, finding a post will look like this instead:

# app/controllers/post_controller.rb
class PostsController < ApplicationController
  
  before_filter :find_post
  
  protected
    
    def find_post
      @post = Post.find(Slug[params[:id]])
    rescue ActiveRecord::RecordNotFound
      redirect_to root_path  
    end
end

Adding Redis

Getting up and running with Redis is as simple as compiling the server, running it, and connecting to it. Downloading and installing Redis is outside the scope of this article, but there are detailed instructions here. Once it has been successfully installed, it can be run by opening a new terminal window and typing redis-server.

Now that the server is running, we need to let our app talk to it. First, we need to install the redis gem. With bundler, this is as simple as adding the following to the Gemfile, and running bundle install:

gem 'redis'
gem 'redis-namespace'

We then need to connect to the server and store that connection as a global resource. Additionally, we are going to use the “redis-namespace” gem to organize everything under one application-wide namespace. This will help enormously down the road when multiple apps use the same Redis server. Create a file called “redis.rb” in your config/initializers folder with the following:

$redis = Redis::Namespace.new("my_app", :redis => Redis.new)

That’s it. We may now issue Redis commands directly to the $redis global variable. Let’s test it out by opening a Rails console and executing the following commands:

> $redis.set("foo", "bar")
 => "OK" 
> $redis.get("foo")
 => "bar" 
> $redis.get("baz")
 => nil
> $redis.del("foo")
=> 1 
> $redis.get("foo")
 => nil 
>

Cool. We can see that the instance methods of the Redis class are the same as the the Redis commands, found here. For simple get/set operations, we can also use array notation:

> $redis["foo"] = "bar"
 => "bar" 
> $redis["foo"]
 => "bar" 
> $redis["baz"]
 => nil 
> $redis.del("foo")
 => 1 
> $redis["foo"]
 => nil 
>

Now we are ready to dig a little deeper.

The Slug Model

Fetching

The Slug model has one main purpose: to turn a slug into a post id. We are going to utilize the hash data type in order to avoid polluting the key space with a bunch of slugs. As such, all slugs will reside under the single key, “slugs.” Our first pass at app/models/slug.rb looks like this:

class Slug
  class << self
    
    def [](slug)
      redis.hget(hash, slug)
    end

    private
    
      def redis
        $redis
      end

      def hash
        "post_ids"
      end
  end
end

We simply fetch the value of a specific slug within the hash “slugs.” If the key doesn’t exist, Redis returns nil, which will cause our PostsController to redirect to the root path. Fetching is easy, but we need to be able to store slug/id mappings for this to have any effect.

Storing

Storing values is simple enough as well. We can add a PostObserver to our app with the following code:

class PostObserver
  def after_save(post)
    Slug[post.slug] = post.id.to_s
    return true
  end
end

Then, we can modify our Slug model to allow for mapping a slug to a post id:

class Slug
  class << self
    
    def [](slug)
      redis.hget(hash, slug)
    end
    
    def []=(slug, id)
      redis.hset(hash, slug, id)
    end
    
    private
    
      def redis
        $redis
      end

      def hash
        "post_ids"
      end
  end
end

Deleting

The last thing we’ll need to handle is clearing out unused slugs when a post is destroyed. This is because we will need to validate slug uniqueness against all slugs. If a slug points to a post that no longer exists, it will be unusable for future posts. We will revisit this a bit later.

As it turns out, deleting slugs presents an interesting problem: how do we know which slugs reference a particular post id? As we have seen, we can easily find a post id given a slug, but we don’t have an easy way to find all slugs that reference a given post id. With our current implementation, we would have to search every slug in the hash and select only those which map to a given post id. It would be a linear-time operation over the total number of slugs, and this is way too slow. This problem is also a good excuse to introduce Redis’s “set” data type.

The change is just a bit of simple bookkeeping. Every post id will have an associated set whose members are the slugs which map to that post id. That is, whenever we map a slug to a post id, we will also add that slug to the set of slugs associated with that post id. Moreover, as it is possible to update a slug to point to a different post id, we will first need to remove that slug from the set of slugs for the old post id.
Here’s the change:

class Slug
  class << self
    
    def [](slug)
      redis.hget(hash, slug)
    end
    
    def []=(slug, id)
      if old = self[slug]
        redis.srem(set(old), slug)
      end
      redis.hset(hash, slug, id)
      redis.sadd(set(id), slug)
    end
    
    private
    
      def redis
        $redis
      end

      def hash
        "post_ids"
      end

      def set(id)
        "post_slugs_#{id}"
      end
  end
end

Now that we have an efficient way to fetch all slugs for a given post id, we are ready to implement the destroy method:

class Slug
  class << self
    
    def [](slug)
      redis.hget(hash, slug)
    end
    
    def []=(slug, id)
      if old = self[slug]
        redis.srem(set(old), slug)
      end
      redis.hset(hash, slug, id)
      redis.sadd(set(id), slug)
    end
    
    def destroy(id)
      redis.smembers(set(id)).each { |slug| redis.hdel(hash, slug) }
      redis.del(set(id))
    end
    
    private
    
      def redis
        $redis
      end

      def hash
        "post_ids"
      end

      def set(id)
        "post_slugs_#{id}"
      end
  end
end

We will destroy the mapping from the PostObserver:

class PostObserver
  def after_save(post)
    Slug[post.slug] = post.id
    return true
  end
  
  def after_destroy(post)
    Slug.delete(post.id)
    return true
  end
end

Uniqueness

As mentioned above, another important aspect of our slug implementation is making sure that a post never has a slug that is mapped to another. In our Post model, we must implement a validation that ensures there is a slug, and that it either does not point to a post id, or it points to the same post we’re currently saving (in the case of an update):

# app/models/post.rb
class Post < ActiveRecord::Base
  
  validate :ensure_slug_uniqueness
  
  protected
  
    # validate
    def ensure_slug_uniqueness
      
      # we also want to ensure the slug is not blank
      if self.slug.blank?
        errors.add(:slug, "can't be blank")
      end
      
      # if this is a new post, the id is nil
      # otherwise, the slug should point to this post's id
      unless Slug[self.slug].nil? || Slug[self.slug] == self.id.to_s
        errors.add(:slug, "is already taken")
      end
    end
end

Note that this means that slug auto-generation needs to take place before validation.

Save Post IDs as Slugs

The last little bit of bookkeeping involves mapping post ids to themselves in Redis. As mentioned above, there are links all over the internet in this format: http://myrailsblog.com/321. After we launch our slug implementation, when someone visits a post URL, we will look for “321″ in Redis to see if it maps to a post id. Unless we want all of these old URLs to redirect to the homepage, we’ll need to run a simple script:

Post.find_each { |post| Slug[post.id.to_s] = post.id.to_s }

Of course, the other option is to modify the PostController to also find Posts by id in the event that Redis has no mapping, but this is slightly less efficient:

# app/controller/posts_controller.rb
class PostsController < ApplicationController
  
  before_filter :find_post
  
  protected
    
    def find_post
      if id = Slug[params[:id]]
         @post = Post.find(id)
      else
        @post = Post.find(params[:id])
      end
    rescue ActiveRecord::RecordNotFound
      redirect_to root_url
    end
end

All Done

With that, we have successfully implemented slugs for our blogging platform. Even if an old post URL is followed, our platform will still find the correct post. Moreover, we did all of this without needing to modify the database schema, and we get the benefits of the speedy lookup time of Redis.

I hope you have found this example useful, and continue to find creative ways to use Redis on your own.

Mark's latest book was just
published by Addison-Wesley

I’d heard second hand for a long time that Mark Bates was a great public speaker, but it wasn’t until the March meeting of Boston.rb that I had a chance to find out for myself. He gave a great presentation called Testing Rich Client Side Apps with Jasmine, about how to use Jasmine and other tools to test web applications that use CoffeeScript on the client. It was informative, entertaining and thought provoking. Despite being an experienced Ruby developer I’d never taken the time to learn how to use CoffeeScript properly in my applications. But listening to Mark and seeing his examples inspired me; I thought to myself: “This is something I need to learn and use as soon as possible.”

I was excited a few weeks later when I had a chance to interview Mark myself – what better way to get started learning CoffeeScript! First I took the time to read his book, Programming in CoffeeScript, which was fantastic and very helpful. Then we spent about an hour talking about CoffeeScript: how it was invented, what other languages inspired and influenced CoffeeScript, how a Ruby developer should start to learn it, testing and more… I’ve typed in the highlights of our conversation here. If you’re a Ruby developer interested in learning more about CoffeeScript here’s your chance to hear from a well known developer, author and thought leader about how to get started.

Who Is Mark Bates?

Mark Bates

Mark Bates is founder and chief architect of the Boston-based development and consulting company, Meta42 Labs. He has developed web applications since 1996. Since discovering CoffeeScript, he has become a leader in its programming community, presenting to user groups and speaking at high profile conferences around the world, such as RubyConf, RailsConf, and jQueryConf. He is the author of the books Distributed Programming with Ruby and Programming in CoffeeScript.

Q: Hi Mark – thanks for talking with me this morning…

You’re lucky I’m awake! I accidentally took a few Tylenol PM this morning, the fact that I’m sitting upright right now is amazing…

RailsConf

Q: I heard you did a great presentation CoffeeScript for the Rubyist at RailsConf on April 23rd. How did it go? How was the conference in general?

The talk went great, excellent reception. It helped that I had an excellent time slot, morning of the first day, most people were still sober, of course being drunk probably would’ve helped my presentation! Judging by the people who came up to me during the conference, and on even on the plane ride home, I must’ve done something right, because I’m sure I made a few converts.

The conference overall was really good. The theme that DHH put forth was progress. Keep looking towards the future, learn the new technologies, keep growing as a developer. CoffeeScript got quite a high profile mention during the keynote and it was mentioned, a lot, throughout a lot of the other talks I saw. I would say that I heard more people discussing CoffeeScript, Backbone, and Ember more than Rails itself. Really showed where people are heading with their development.

Should you even use CoffeeScript?

Q: There are some people out there who prefer the “pure” JavaScript syntax and don’t like this idea of precompiling it. Is it even a good idea to use CoffeeScript?

To them honestly I would say: “fine, if you want to keep writing it that way it’s up to you.” I look at it as very similar to why I moved to Ruby from Java. Ruby obviously has some features that Java doesn’t have, and Java has some features that Ruby doesn’t have – all languages do. I can write a web app in Java, just as well in I can in Ruby…

Q: We all used to do that…

But I prefer writing it in Ruby because I can write a lot less code to do the same thing. That’s the way I feel about CoffeeScript.

Q: Is there also something about the beauty or elegance of the CoffeeScript code?

Oh yea – again, the same thing with Java to Ruby. I can write a lot less code; it’s much cleaner and easier to read; it’s easier to maintain. I get a lot of people saying that they hate the fact that CoffeeScript is whitespace significant. To them I always say: “Well, how are you formatting your JavaScript?” You should be doing that anyway – you should be formatting your code nicely. At that point the whitespace significance really becomes insignificant whitespace, as you’re doing that already.

Should you learn CoffeeScript first, or JavaScript?

Q: Should I learn JavaScript first, before CoffeeScript? I remember Wyatt Greene at that Boston.rb meeting did another great talk right before you, From Ruby to JavaScript. One of the things he said was that he wanted to learn JavaScript thoroughly first, before starting to learn CoffeeScript. Do you think that’s a good idea?

I think it’s a must-have idea. In my book, there are numerous places where I actually recommend to the reader: “Put the book down – go read something on JavaScript first and then come back again” if they don’t know it. It is very important that you know what it is doing. You will learn some really interesting things about JavaScript from CoffeeScript; I certainly did. It’s made me a better JavaScript developer, but I was a JavaScript developer first.

Q: Is it OK to be a casual JavaScript developer? Or do you really need to thoroughly understand it before trying to learn CoffeeScript?

You should be at least an intermediate JavaScript developer, because some of those concepts get a little hairy and CoffeeScript takes some of that stuff away from you. If you’re beginning and you don’t really understand what makes a function a function or how callbacks work or how prototypes work, you should brush up on all of that first.

Q: …because CoffeeScript might make it harder to understand?

Not harder, but it abstracts it all away. Knowing what JavaScript can do, and how to it, means you can really take more advantage of what CoffeeScript has to offer.

Q: It makes it easier not to learn JavaScript thoroughly, I guess.

Exactly. I can see people easily jumping into CoffeeScript and generating some pretty cool code without knowing what it’s really generating. The minute it generates something they don’t understand it’s going to really bite them in the ass, you know? When they don’t understand why the scope is not correct. Or, why something is not equal to another thing their lack of JavaScript is really going to hurt them.

How would you go about learning CoffeeScript?

Q: If you’re a Rails developer or a Ruby developer of some sort, what’s the right way to learn CoffeeScript?

I hope reading my book, Programming in CoffeeScript would be a great way to learn it. For Rubyists, there’s a little bit of Ruby in the book, but I wanted to make it accessible to everybody, not just Rubyists. I used Node.js to build the sample application in the last three chapters for a couple of reasons:

1. Because Node.js and CoffeeScript are quite commonly linked together and you see a lot of Node apps being written in CoffeeScript.
2. Because I could write the back end in CoffeeScript. It was a great way to just delve into the language and to see real examples of the language being used.

Q: I thought that was really cool! I kept thinking to myself: “I can’t believe I’m writing a server in CoffeeScript!”

Yea! It’s pretty cool. In the book we write the server and the front end in the same language, in CoffeeScript, which I thought was actually kind of fun and kind of cool. But if I had done it in Rails, then I would have alienated PHP people, Python people, Java people, and there was no need to write it in a different language because I could write it in the language of the book, which was a really fun exercise.

For Rails people, it’s pretty straightforward. You fire up Rails and the support for CoffeeScript is just there. Just start using it.

Q: I think that’s where I am: I’m a Rails developer but I’m not a CoffeeScript expert. I use it here or there; it just sort of works. Again, it’s almost too easy – you don’t really need to spend the time to learn it deeply.

It is easy with Rails to just start using CoffeeScript and get to a point where you think you know it and know it well. It’s not a horribly large language; it’s actually pretty simple. But there are a lot of really cool little hidden things in this language.

Q: If I’m a Rails developer, should I just install Node.js and learn it the way you present in the book? Or is it ok just to use it inside the Asset Pipeline?

I think it’s ok just to use it inside the asset pipeline. Using it is more important than playing with it. That’s the way I feel about any language. I don’t learn a language by building tinker toy little apps, I learn by using it for an actual app. That’s how I learn: sink or swim. If you’ve got an application you’re building and you need JavaScript, just start using CoffeeScript! You can mix and mingle regular JavaScript and CoffeeScript files in the same application. You’ll learn more about CoffeeScript, or any language, by using it for real than you ever would just by creating a little “to do” app. You starting saying: “I really need to learn how to do X, Y and Z to solve this problem.”

Q: And so you have to learn about X, Y, and Z.

Exactly; it’s not a contrived problem. Your business is barking for this feature and you’ve got to learn how to do it.

Origins of CoffeeScript

Q: What inspired CoffeeScript? Was it inspired Ruby? Or by Python? Where are its roots?

It was inspired by both, and Lisp, Smalltalk, whatever excited Jeremy Ashkenas. Which is why if you look at it, it looks like a bunch of different languages. It’s got the significant whitespace of Python, and some things like the @ symbol and class definitions that are very Rubyesque. Jeremy wrote it originally because he had read How To Create Your Own Freaking Awesome Programming Language by Marc-André Cournoyer. He read this book and started tinkering with it. The original implementation of CoffeeScript was in Ruby – the original compiler.

Q: Is it all in C code now, or something?

No, it’s all written in CoffeeScript!

Q: It’s written in CoffeeScript itself? Sounds like Rubinius….

Yea. Exactly. It’s one of those things that always blows my mind. Rubinius blows my mind in that it’s a Ruby implementation written in Ruby that runs on Ruby. How the world doesn’t implode when someone starts up a Rubinius server I will never know.

With something like a compiler it’s a little easier because you write the first compiler in something else, and then you have the language to use to write the next compiler. The first compiler was written in Ruby. But then he took version X which was written in Ruby and then wrote the CoffeeScript compiler in version X of CoffeeScript. If you go to github, it’s all in CoffeeScript!

Q: With Rubinius it’s great how if you’re not sure how something works, e.g. “How does the String.slice method work?” – you can just go and look at the Ruby source code.

Yea with CoffeeScript it’s all in CoffeeScript. If you want to know how class support works in CoffeeScript – you just go read the CoffeeScript source code and you’ll see it right there. It’s actually pretty readable source code. It much more approachable than, for example, the Ruby source code.

Ember.js vs. Backbone.js

Q: I wanted to ask you about Ember.js vs. Backbone.js. I don’t know if that’s a controversy or not; they’re sort of just different things. You’ve said you use Backbone a lot – I’m curious why? And have you tried Ember? What’s the difference between them?

In some respects they are wildly different. I think a better comparison would be Backbone.js vs. Spine or Knockout. I like Backbone a lot – I find it incredibly simple, easy to use and easy to understand. It makes a lot of sense to me. Backbone let’s you create models, collections and views to manage your HTML, and deal with the events that happen on these models and collections, dynamically call functions to, say, re-render that once it’s been updated.

Ember takes a different approach and says that you have to mark up your HTML in a certain way. And if you do that, then auto-updating of attributes will happen automatically. If I mark up my <h1> correctly that has the name of a user, and in my User object I change the name of that user then that <h1> tag will get updated without me having to do anything else.

Q: So in Backbone you need to do that updating yourself?

Exactly. But I think Ember’s updating is simultaneously both slick and dangerous.

Q: Because it might be happening when you don’t expect it to?

There might be times when you don’t want to update elements on the page, for whatever reason. I’m also anti-adding-extra-markup to my pages, if I don’t need it, which is one of the reasons why I don’t like Knockout. Knockout works almost entirely by adding extra data elements to your HTML. If down the line you want to change something you end up with all of this extra cruft.

One of the things I like about Backbone is that it cuts down the amount of markup I have to put in there. I don’t need IDs so much any more or even class names, just so I can find a particular element. They all get scoped to views. If you write your views correctly you can do a generic search for a list element; you don’t need to worry about making sure it’s the right set of list elements.

I’m actually going to be writing a new Backbone eBook soon.

Q: Fantastic! By the way, how did you get your start writing books? It’s very impressive you’ve already published two…

I got started writing by getting Obie Fernandez drunk in a hot tub! Obie had seen me talk at RubyConf 2008 about distributed programming and we were in the hot tub hanging out with the Hashrocket folks, we were having a few drinks, and I mentioned to them that a couple people had asked me after my talk about where to get more information on distributed programming. Then Obie told me he was the Ruby series editor at Addison-Wesley and that distributed programming would be a great book topic… and it went from there.

Testing CoffeeScript

Q: And do you want to tell readers about the presentation I saw at Boston.rb in March? I was struck how even Boston.rb members didn’t do much JavaScript testing…

At that talk, there were 100 people there, and I asked the room: “How many people test their Ruby code?” and 100 people raised their hand. And that’s very indicative of the Ruby community. And then I asked the room: “How many people write JavaScript code?” And again everybody raised their hand. Then I asked “How many people test their JavaScript code?” And just 6 people raised their hand.

Q: And I was not one of them, trust me.

That’s just an awful number. Only 6% of the Ruby developers in that room test their JavaScript? And they all write JavaScript! So why is it ok to test Ruby and not JavaScript?

Q: I think the reason why, in my opinion, is that JavaScript is the stunted little stepson of the family and no one really takes it seriously. And in the past few years most people did not write much JavaScript; there were just a few lines here or their for validation, a little Ajax, etc. So I’m answering your question – you’re supposed to be answering the questions! But now suddenly people realize: “I can write big apps just with JavaScript.”

I also think there’s a fear that JavaScript would be too difficult to test. If it needs to run in a browser, how am I going to do that? How am I going to test DOM interaction? How am I going to test AJAX?

Q: For Rubyists who have this fear… what should people do to learn how to test their JavaScript?

That’s a great question! There’s a lot of great resources out there: look at Jasmine, look at Mocha, look at Chai. There are a lot of really great libraries that resemble the libraries you’re already using to test Ruby.

Q: Yea in your presentation I was struck how much Jasmine looks like RSpec.

Exactly. And same thing with Mocha and Chai: they look very much like RSpec.

One of the things that I’m very surprised at, to the point where if I had the time and the inclination I’d probably sit down and try to write a big pull request for Rails 4, is how Rails doesn’t include testing tools for JavaScript.

When they introduced the asset pipeline and CoffeeScript in Rails 3.1 – and I think CoffeeScript lowers the barrier to entry for testing in JavaScript because it feels so much more natural like you’re writing Ruby – why didn’t they include testing tools? That weighs in my mind. From very early on in Rails, there was a test framework right there and there was so much emphasis on: “Look how easy it is to test your code.”

Q: To be honest, that’s a big reason why it caught on – because it was there in the first place.

… and because it was easy to do. Rails made it super easy to do. I’ll be honest – in all my years of writing Java, ask me how many Java unit tests I wrote! It was not a lot; I’m not going to lie to you! And Rails came along, and wow there was Test::Unit, which I was not a fan of, but it was right there, baked right in and I could start testing easily.

So why the team never put in testing tools for JavaScript blows my mind. What I demonstrated at Boston.rb should have been in the framework. And every time Rails generates one of these .coffee files for you, it should generate a test for you.

Thanks!

Q: Thanks for all your time, Mark!

Sure thing, thanks Pat.

In Part 1, I talked about using the layered architecture for tackling domain complexity. I showed a few typical violations of the layered architecture and gave some advice on how to fix them.

In Part 2, I started talking about the building blocks of Domain Driven Design. I wrote about an important distinction between Entities and Value Objects. I also gave some advice on how to implement Value Objects in Rails.

Aggregates

This time I’d like to go into another building block of Domain Driven Design. I’d like to talk about Aggregates.

We’ve all experienced this situation before:

You start with nicely designed groups of objects. All the objects have clear responsibilities, and all interactions among them are explicit. Then, you have to consider additional requirements, such as transactions, integration with external systems, event generation. Satisfying all of them and not making all the objects interconnected is a nontrivial task. What usually happens is database hooks, conditional validations, and remote calls are added on an ad hoc basis. The result is more connections among objects. Hence, the boundaries of object groups become fuzzy and enforcing invariants becomes harder. Remember all the cases when you were thinking, “Maybe I need to reload this object?” It indicates that your objects are interconnected, and you cannot reason about your code with confidence. Instead, you just guess.

Defining Aggregates is a good remedy for the described situation.

• “An Aggregate is a cluster of associated objects that are treated as a unit for the purpose of data changes.” (see Resources)
• An Aggregate consists of a few Entities and Value Objects, one of which is chosen to be the root of the Aggregate.
• All external references are restricted to the root. Objects outside the Aggregate can hold references to the root only.
• Accessing other members of the Aggregate happens through the root. Therefore, nobody (outside the Aggregate) should hold references to those objects.
• As all external objects can hold reference only to the root, enforcing invariants becomes easier.
• Aggregates help to reduce the number of bidirectional associations among objects in the system because you are allowed to store references only to the root. That significantly simplifies the design and reduces the number of blindsided changes in the object graph.

Example

It may sound too abstract, so I’d like to show you an example. I’m going to model an online bookstore. The main responsibility of the model will be selling and shipping books. Hopefully the example will bring some clarity to the definition of Aggregates and will demonstrate how they can be implemented in Rails.

Sketch

This is a sketch illustrating all the classes that will form the model.

As you can see, I have:

• Entities: Order, Item, User, Book, Payment
• Value Objects: Address
• Services: ShipmentService, PaymentService
• View: OrderPresenter

Defining Aggregate Boundaries

Now, after I am done with sketching, I can establish Aggregate boundaries and choose roots.

There are a few rules of thumb to use:

• Entities forming the parent-child relationship, most likely, should form an Aggregate. In this case, the parent class becomes the root.
• Entities that are semantically close to each other are good candidates for forming an Aggregate as well. For instance, Book and Payment have no obvious connections with each other. Having them inside an Aggregate is awkward. On the other hand, Order and Item are closely related. Thus, we should consider putting them inside an Aggregate.
• If two Entities have to be modified inside a transaction, they should be parts of the same Aggregate.

Note:
These rules should just help you get started. After your first sketch you should look at all the invariants that need to be maintained and finalize your Aggregate boundaries based on them.

As you may have already guessed, Order and Item form an Aggregate. What other Entities should we include? Including Book does not make much sense because I can easily imagine clients using Book without Order (e.g. you may need to display the list of all available books in the store).
Including User into the same Aggregate with Order is not the best idea either. Just imagine if User becomes the root, you will have to access all the orders of a user through the user itself. Furthermore, updating two orders of the same user simultaneously will be tricky. Clearly neither Book nor User should be a part of the Aggregate.

The situation with the Payment class is different. Conceptually, Payment is an important part of Order. Also, you cannot simultaneously pay for an Order and modify it. It’s decided, Payment becomes a part of the Aggregate.

An updated sketch with the defined boundary:

Implementation

Let’s get started with the code. First, let’s define the Book and User classes:

class Book
  include DataMapper::Resource

  property :id, Serial
  property :title, String
  property :author, String
  property :price, Decimal
end

class User
  include DataMapper::Resource

  property :id, Serial
  property :name, String

  property :address_country, String
  property :address_city, String

  validates_presence_of :name

  def address= address
    self.address_country = address.country
    self.address_city = address.city
  end

  def address
    Address.new(address_country, address_city)
  end
end

class Address < Struct.new(:country, :city)
end

There is nothing really interesting here. There are two Entities (Book and User) and one Value Object (Address). It gets interesting when we implement the Order and Item classes:

class Order
  include DataMapper::Resource

  property :id, Serial, key: true
  property :status, Enum[:new, :ready, :paid, :shipped, :closed, :canceled]

  belongs_to :buyer, 'User'
  has n, :items
  has 1, :payment

  property :shipping_address_country, String
  property :shipping_address_city, String

  def shipping_address= address
    self.shipping_address_country = address.country
    self.shipping_address_city = address.city
  end

  def shipping_address
    Address.new(shipping_address_country, shipping_address_city)
  end


  def self.make buyer
    create buyer: buyer, shipping_address: buyer.address, status: :new
  end

  def self.get buyer, id
    #...
  end

  def self.all_orders buyer
    #...
  end

  def self.active_orders buyer
    #...
  end


  def make_item book, quantity
    ensure_status :new

    amount = book.price * quantity
    items.create book: book, quantity: quantity, amount: amount
  end

  def make_payment masked_card
    ensure_status :ready

    self.payment = Payment.new(masked_card: masked_card, amount: total_amount)
    self.status = :paid
    save
  end

  def mark_as_ready
    #...
  end

  def mark_as_shipped
    #...
  end

  def total_amount
    #...
  end

  private

  def ensure_status required_status
    raise InvalidOrderStatus.new(self) if status != required_status
  end
end

class Item
  include DataMapper::Resource

  property :id, Serial
  belongs_to :book

  property :quantity, Integer
  property :amount, Decimal
end

class Payment
  include DataMapper::Resource

  property :id, Serial
  property :masked_card, String
  property :amount, Decimal

  property :created_at, DateTime
  property :updated_at, DateTime
end

That is how the creation of an order may look like:

buyer = current_user
order = Order.make buyer

#At this moment: 
#order.shipping_address == buyers_address
#order.status == :new

order.make_item book1, 2
order.make_item book2, 3
order.mark_as_ready

Reading the same order from the database may look like this:

order = Order.get(buyer, params[:id])

There are a few important things I’d like to point out:

• All items and payments are created through an instance of Order.
• I don’t update attributes of an Order directly.
• I don’t use DataMapper methods directly. I wrote a few methods to decouple our model from DataMapper as much as possible.
• There are no bidirectional associations. Every order knows about its items, but the items don’t have any references to their orders. Why? Because they don’t need to. Order is the root; therefore, any client can get an item only through its order. This means that an item’s order will always be known. * Bidirectional associations are a bad practice established in the Rails community. If you can avoid it, please, do it. *
• A user does not know about its orders. Apart from the fact that it’s an unnecessary bidirectional association, it also makes testing much harder.

Don’t believe me? Take a look at this line of code:

@all_orders = current_user.orders.active

It looks so simple. Some people might even say that it’s nicer than this one:

@all_orders = Order.active_orders(user)

However, if you try to stub it in your test you may write something similar to this:

order = ...
stub(orders = Object.new).active {[order]}
stub(user = Object.new).orders {orders}
stub(UserSession).current_user {user}

Now, compare it with the stubbing of Order.active_orders(user):

order = ...
stub(UserSession).current_user {user}
stub(Order).active_orders(user){[order]}

The second test is much easier to read and understand. In addition, in large applications such models as User tend to grow. In a few years, you may get the User class having many orders, promotions, friends, wish lists etc.

Accessing Our Model in View

Please, don’t be mistaken. The fact that Order is the root of the Aggregate does not mean I cannot access its payment or items. Of course, I can. The only rule is not to store references to those objects. For instance, I’d probably need a presenter. As presenters store references to the objects they present, creating ItemPresenter or PaymentPresenter is a violation of the Aggregate boundary. Instead, we can create OrderPresenter and pass an instance of Order to it. OrderPresenter can access the order’s items or payment through the order itself.

class OrderPresenter < Struct.new(:order)
  def render_items
    order.items.map do |item|
      item_row item
    end.join("")
  end

  private

  def item_row item
    "<div>#{item.book.title} - #{item.quantity} - #{item.amount}</div>"
  end
end

Invariants

Remember that Aggregates are not only about access restriction. They also define the boundaries of invariants and transactions. There is a common opinion that those invariants must be enforced by the root. It’s also common to make the root responsible for managing all transactions. Although sometimes it may make perfect sense, there are lots of situations when it does not. Just to give you an example, let’s take a look at the PaymentService class:

module PaymentService
  def self.process order, credit_card
    with_transaction do
      order.make_payment mask_card(credit_card)
      make_remote_call credit_card, order.payment
    end
  end

  ...
end

PaymentService has several responsibilities. First, it masks the credit card. Next, it updates the database to mark the order as paid. After that, it makes a remote call to some external service that processes credit card transactions. Also, it wraps everything into a transaction. PaymentService ensures an important invariant that updating the status of the order and making the remote call must be done together. An alternative would be to make Order responsible for calling external services. The result would be a violation of Single Responsibility Principle and a few nasty dependencies of Order on external payment systems.

Wrapping Up

Sometimes invariants need to be applied not to discrete objects, but to clusters of objects. Defining Aggregates and restricting access to Aggregate members is an arrangement that makes enforcing all the invariants possible.

Resources

* Aggregate | Domain-Driven Design Community

Image courtesy of Shutterstock

A couple of months ago, I wrote an article about how I rapidly built my personal site using Sinatra. While I was building the site I started thinking about the best way to add JavaScript files to the pages. After playing with it for a while, I ended up using some custom helper methods to add JavaScript files to any page.

It’s actually very easy to add javascript files to pages in Sinatra using the layout file. For example, if you want to include JQuery and a custom JavaScript file (called application.js) on all pages, then all you need to do is put the following lines of code in your layout file:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="/javascripts/application.js"></script>

(This assumes that the Javascript files are in the public folder).

Putting this code in the layout file means that they will be included on every page. However, some JavaScript files might only be needed on certain pages. For example, you might only want the file email.js to be loaded on the contact page. It turns out that there’s a simple way to add things dynamically to layout files – instance variables. These can be set in the routes and then refererred to in the views. I use the instance variable @js to add a custom JavaScript file to a route:

get '/' do
  @js = "custom.js"
  slim :index
end

I can then add an extra line to my layout file that will include the relevant script tag if the @js variable has been set.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="/application.js"></script>
<%= "<script src="/#{@js}"></script>" if @js %>

This is a big improvement. It means that you can add a javascript file on a route-by-route basis. The only problem is that you can only add one file per route. To get round this, you can change the instance variable to an array of JavaScript files:

get '/' do
  @js = ["custom.js","sorter.js","colorpicker.js"]
  slim :index
end

This also requires the line in the layout file to be changed so that it iterates through each string in the array and adds a script tag for each JavaScript file:

<% if @js %>
  <% @js.each do |script| %>
    <%= "<script src="/javascripts/#{script}.js"></script>" %>
  <% end %>
<% end %>

So far, so good – we are now able inject custom JavaScript files into the layout of individual routes. Since we’re looping through all of the custom JavaScript files in the @js array, why not just add scripts that will appear on all pages (application.js and JQuery) to the array as well? This can be achieved by creating another array, using Sinatra’s settings method, called settings.javascripts. This array can be placed anywhere in your ruby file (I like to keep it near the top) and contains all the JavaScript files that are to be included on all the pages:

settings.javascripts = [ "https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", "application.js" ]

These two arrays need to be added together to create one big array to iterate over. The uniq method is used to avoid any repetition in case a file gets added to the @js array that has already been placed in the settings.javascripts array:

<% javascripts = (@js ? @js + settings.javascripts : settings.javascripts).uniq %>
<% javascripts.each do |script| %>
  <%= "<script src="/javascripts/#{script}.js"></script>" %>
<% end %>

This amount of logic in a view looks messy, which is always a bad sign. The best way to deal with lots of view logic is to abstract it into a helper method. Helpers are easy to set up in Sinatra, you simply open up a block and place the methods inside. These methods are then available inside routes and views. Here’s a helper that can be used to clean up the layout:

helpers do
  def javascripts
    javascripts = (@js ? @js + settings.javascripts : settings.javascripts).uniq
    javascripts.each do |script|
      html << "<script src="/#{script}"></script>"
    end.join
  end
end

Now all that’s needed in the layout file is this line:

<%= javascripts %>

Much cleaner.

Since we’re now using a helper method, why not allow it to have arguments? This would allow us to add JavaScript files from within the layout file like before. This doesn’t take too much extra effort – adding an asterix before the name of the method’s parameter allows the method to take as many arguments as required. This means that we can add as many JavaScript files as we need for each route. Each argument forms part of the args array, which can now simply be added to the big array of JavaScript files that is iterated over in the layout (a bonus here is that we don’t have to check if it exists as it defaults to an empty array if no arguments are given):

helpers do
  def javascripts *scripts
    javascripts = (@js ? @js + settings.javascripts + args : settings.javascripts + args).uniq
    javascripts.each do |script|
      html << "<script src="/#{script}"></script>"
    end.join    
  end
end

Now we have three ways to add JavaScript files to a page:

1. In the settings (this is for JavaScript files that are global to the whole site)
2. In the layout file using the javascripts helper. This is used for JavaScript files that are common to all pages using this layout.
3. In the handler using the @js instance variable. This is used to add JavaScript files on a route by route basis.

It may seem at first that methods 1 and 2 are virtually the same thing – a way to add global JavaScript files. But it is not uncommon to have different layouts for a site and it may be likely that each layout will require specific JavaScript files. The settings.javascripts array should only be used for truly global JavaScript that are used throughout the site. The javascripts helper can be used to add JavaScript files on a layout by layout basis.

We can improve on this further by using a helper method to set the @js instansce method. Rather than setting it directly in the handler, we can use a helper method called js that could be used to add any custom js files that are required for that route. This is also a good opportunity to clean up the javascripts helper method as it’s looking a bit brittle (it assumes that settings.javascripts exists at the moment).

helpers do
  def js *scripts
    @js ||= []
    @js = args
  end

  def javascripts(*args)
    js = []
    js << settings.javascripts if settings.respond_to?('javascripts')
    js << args
    js << @js if @js
    js.flatten.uniq.map do |script| 
      "<script src="#{path_to script}"></script>"
    end.join
  end
end

Our new js helper method means that things look a bit neater when called in the handler. This is especially true since the files are no longer required to be placed inside an array:

get '/' do
  js "custom.js","sorter.js","colorpicker.js"
  slim :index
end

To finish off, let’s make it easier to add JQuery and other popular libraries when they’re required. This involves writing another helper method that uses shortcut symbols in place of the full url:

helpers do
  def js *scripts
    @js ||= []
    @js = args
  end

  def javascripts(*args)
    js = []
    js << settings.javascripts if settings.respond_to?('javascripts')
    js << args
    js << @js if @js
    js.flatten.uniq.map do |script| 
      "<script src="#{path_to script}"></script>"
    end.join
  end

  def path_to script
    case script
      when :jquery then 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'
      when :rightjs then 'http://cdn.rightjs.org/right-2.3.0.js'
      when :backbone then 'http://cdnjs.cloudflare.com/ajax/libs/backbone.js/0.9.0/backbone-min.js'
      when :underscore then 'http://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.3.1/underscore-min.js'
      else script.to_s + '.js'
    end
  end
end

Now if you want to add a specific library all you need is the following code inside a route handler:

get '/' do
  js :backbone, :custom
end

Notice that custom JavaScript files can now be entered as symbols and don’t need to have ‘.js’ appended to the end, as this is all done in the path_to helper method.

With the helper method working how we want, it’s time to go modular and move it into a separate file. We first need to create a file called javascripts.rb and save it in a folder called ‘sinatra’ in the root directory of the app. All of the code inside the helpers block is then placed inside a module called JavaScripts. This module is then placed inside a module called Sinatra (which is considered best practice when extending Sinatra with modules). The last thing to do is make sure to require Sinatra::Base at the top of the file.

require 'sinatra/base'

module Sinatra
  module JavaScripts
      def js *scripts
        @js ||= []
        @js = args
      end

      def javascripts(*args)
        js = []
        js << settings.javascripts if settings.respond_to?('javascripts')
        js << args
        js << @js if @js
        js.flatten.uniq.map do |script| 
          "<script src="#{path_to script}"></script>"
        end.join
      end

      def path_to script
        case script
          when :jquery then 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'
          when :rightjs then 'http://cdn.rightjs.org/right-2.3.0.js'
          when :backbone then 'http://cdnjs.cloudflare.com/ajax/libs/backbone.js/0.9.0/backbone-min.js'
          when :underscore then 'http://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.3.1/underscore-min.js'
          else script.to_s + '.js'
        end
      end
  end

  helpers JavaScripts
end

The line helpers JavaScripts right at the end of the Sinatra module registers the helper methods so that they are available for use in the application.

To use these helper methods, all you need is the following line of code in the main application file (main.rb):

require './sinatra/helpers'

We now have a convenient little helper that allows us to easily add JavaScript files exactly where they’re needed. A nice touch is that JavaScript files can also be added on a conditional basis in route handlers, like so:

get '/'
  js :backbone, :application
  js :admin if logged_in?
  slim :index
end

More Helper Methods

The method outlined above is not limited ot JavaScript files. A similar method could be used for adding CSS in a fine-grained way:

module Sinatra
  module JavaScripts
    def js *scripts
      @js ||= []
      @js = args
    end

    def javascripts(*args)
      js = []
      js << settings.javascripts if settings.respond_to?('javascripts')
      js << args
      js << @js if @js
      js.flatten.uniq.map do |script| 
        "<script src="#{path_to script}"></script>"
      end.join
    end

    def path_to script
      case script
        when :jquery then 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'
        when :rightjs then 'http://cdn.rightjs.org/right-2.3.0.js'
        when :backbone then 'http://cdnjs.cloudflare.com/ajax/libs/backbone.js/0.9.0/backbone-min.js'
        when :underscore then 'http://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.3.1/underscore-min.js'
        else script.to_s + '.js'
      end
    end
  end

  module StyleSheets
    def css *files
      @css ||= []
      @css = args
    end

    def styles(*args)
        css = []
        css << settings.css if settings.respond_to?('css')
        css << args
        css << @css if @css
        css.flatten.uniq.map do |stylesheet| 
          "<link href="/#{stylesheet}.css" media="screen, projection" rel="stylesheet" />"
        end.join    
    end
  end

  helpers JavaScripts, StyleSheets
end

I’ve taken the whole concept further and built a module called HeadCleaner that has a helper method for all the common items found inside the head of an html page such as meta, title, webfonts etc. This means that you can just use method calls to create a very minimal looking head section of the layout file such as the one shown below:

<head>
  <%= meta %>
  <%= title_tag %>
  <%= favicon %>
  <%= ie_shim %>
  <%= webfonts %>
  <%= javascripts %>
  <%= styles :mobile,:general,:ie %>
</head>

You can see the code here.

It’s by no means perfect and I’d appreciate any feedback or help in developing this further (fork the code on github!). Ideas that I have for developing this are:

• Allow users to set the path to javascripts
• Have a separate yaml file with the shortcuts to external libraries in it so that it can be easily edited
• Integrate with a JavaScript loader rather than having a separate script tag for each JavaScript file.

I hope these helpers are, well, helpful. If you’ve developed any helpers in your Sinatra development, do tell in the comments. Cheers!

(Main Image courtesy of Shutterstock)

In Part One of this series, I explained how to create a Rails application with a sign up form. This article concludes the process of user authentication

Authentication Method

As we can now save encrypted passwords in the database, it’s time to setup the authentication method that will take a username/email and password to find out if that matches a user in the database. We need a query to match username/email and, if found, encrypt the entered password and compare it with the encrypted password in the database.

Let’s write an authentication method in the user model

def self.authenticate(username_or_email="", login_password="")
	if  EMAIL_REGEX.match(username_or_email)    
		user = User.find_by_email(username_or_email)
	else
		user = User.find_by_username(username_or_email)
	end

	if user && user.match_password(login_password)
		return user
	else
		return false
	end
end   

def match_password(login_password="")
	encrypted_password == BCrypt::Engine.hash_secret(login_password, salt)
end

We see that if login_password matches, we return the user object. Otherwise, the method returns false.

Sessions Controller and Login form template

With our authentication method in place, let’s generate the sessions controller. The SessionsController will have create login, home, profile and setting actions.

$ rails g controller sessions login, home, profile, setting 

view raw generate_session_controller.sh This Gist is brought to you using Simple Gist Embed.

Let’s focus on the login template. The act of logging in consists of a form that accepts username/email and password, passing the values to the login_attempt action.

<% @page_title = "UserAuth | Login" -%>
<div class= "Sign_Form">
	<h1>Log in</h1>
	<%= form_tag(:action => 'login_attempt') do %>
		<p>Username or Email:</br> <%= text_field_tag(:username_or_email) %></p> 
		<p>Password:</br> <%= password_field_tag :login_password %></p> 
		<%= submit_tag("Log In") %>
	<% end %>
</div>

view raw login.html.erb This Gist is brought to you using Simple Gist Embed.

---

Creating `login_attempt` Action

The login_attempt action accepts params from the login form and passes it to the authentication method we created previously. If the user is found, we redirect to the home action. Otherwise, we’ll render the login template again.

class SessionsController < ApplicationController

				def login
					#Login Form
				end

				def login_attempt
					authorized_user = User.authenticate(params[:username_or_email],params[:login_password])
					if authorized_user
						flash[:notice] = "Wow Welcome again, you logged in as #{authorized_user.username}"
						redirect_to(:action => 'home')
					else
						flash[:notice] = "Invalid Username or Password"
						flash[:color]= "invalid"
						render "login"	
					end
				end

end

view raw sessions_controller.rb This Gist is brought to you using Simple Gist Embed.

There is something missing here. We need to save the logged-in state of the user. If we don’t, we’ll have to authenticate before each requested action, which is not DRY and can be expensive. We’ll use the session to keep track of the user state, checking it before every request from the user.

Let’s see how that is done.

---

cookies[:name]= "Azzurrio"

session[:name]= "Azzurrio"

def login_attempt
					authorized_user = User.authenticate(params[:username_or_email],params[:login_password])
					if authorized_user
						session[:user_id] = authorized_user.id
						flash[:notice] = "Wow Welcome again, you logged in as #{authorized_user.username}"
						redirect_to(:action => 'home')
					else
						flash[:notice] = "Invalid Username or Password"
						flash[:color]= "invalid"
						render "login"	
					end
end

Access Restriction

We need to check the session file every time the user requests some protected action. To do this, we are going use the before_filter method.

before_filter is a method to perform a function before the specific action is executed. It smells a lot like callbacks, but filters are for controllers while callbacks are for models.

The before_filter method takes the name of the method to run before the action. The second parameter is a list of actions that we want to filter. Let’s add it to our application.

In the ApplicationController, which is the superclass of all our controllers, add:

protected 
			def authenticate_user
				unless session[:user_id]
					redirect_to(:controller => 'sessions', :action => 'login')
					return false
				else
					# set current user object to @current_user object variable
					@current_user = User.find session[:user_id] 
					return true
				end
			end

			def save_login_state
				if session[:user_id]
					redirect_to(:controller => 'sessions', :action => 'home')
					return false
				else
					return true
				end
			end

view raw application_controller.rb This Gist is brought to you using Simple Gist Embed.

The authenticate_user method checks if the user_id session is available. If so, it assigns the user object to the @current_user instance variable and returns true, allowing the action to be executed. If not, return false and redirect the to the login page. The other method, called save_login_state, prevents the user from accessing the signup and login pages whilst logged in.

Add the before_filter calls to SessionsController

before_filter :authenticate_user, :only => [:home, :profile, :setting]
before_filter :save_login_state, :only => [:login, :login_attempt]

view raw sessions_controller.rb This Gist is brought to you using Simple Gist Embed.

and to UsersController

before_filter :save_login_state, :only => [:new, :create]

view raw users_controller.rb This Gist is brought to you using Simple Gist Embed.

The @current_user value can be used in the templates, now, to present information about the logged in user.

<h2 class='User_Header'> <%=@current_user.username%> Profile <h2>

view raw profile.html.erb This Gist is brought to you using Simple Gist Embed.

---

def logout
	session[:user_id] = nil
	redirect_to :action => 'login'
end

root :to => "sessions#login"
match "signup", :to => "users#new"
match "login", :to => "sessions#login"
match "logout", :to => "sessions#logout"
match "home", :to => "sessions#home"
match "profile", :to => "sessions#profile"
match "setting", :to => "sessions#setting"

Imagine you’re writing a Rails app to organize conferences. As soon as you know what the app can do, you have to start deciding who can do what. Who is allowed to:

• Decide who will speak at the conference?
• Edit the presenter schedule?
• Upload presentation slides?
• Comment on those slides?
• Create playlists of music?
• Make a personal schedule of which talks to see?

All these questions are about authorization: “what is this user authorized to do?” Obviously, it’s important to get this logic right: it needs to be correct, and it needs to be consistent. And it would be nice if that logic was grouped together, rather than scattered all over your app.

I’ve just released a gem to solve this problem cleanly. It’s called Authority (see Github and Rubygems).

Protecting Your Models

Before I show you how Authority works, let’s talk about some of the general ideas.

Authority’s notion of permissions in your Rails app is focused on your models; in the example above, these would be presenters, comments, playlists, etc. In some cases, the question is very simple: a conference attendee cannot make any changes to any presenter, period. You can think of that as a “class-level” rule: the Presenter model is read-only for anyone who isn’t a conference organizer. If an attendee tries to visit the page for editing a presenter’s bio, we don’t have to ask any questions about this particular presenter to know that the action is not allowed.

In other cases, the question is more nuanced: attendees can edit their own personal schedule, but not anyone else’s. You can think of that as an “instance-level” rule: to know whether a conference attendee can edit a schedule, you have to look at that schedule instance and see who it belongs to.

Using Authority, you’d use class methods, like def self.updatable_by?(user) to set class-level rules, and instance methods, like def deletable_by?(user) , to set instance-level rules.

But where should those methods be written?

Keeping Your Permissions DRY

Obviously, different models have different rules, so you might think that authorization methods should go on the models themselves.

But it’s likely that some of your models share rules: anyone who can edit a Presenter can also edit the PresenterSchedule. If that’s true, it would be nice to keep that DRY: let the Presenter model and the PresenterSchedule model use the same authorization logic.

Authority accomplishes this by having the model delegate any questions of authorization to a specified Authorizer class. Models with the same rules can point to the same Authorizer.

An Example

To take a simple example from the gem’s README, suppose you two have categories of resources in your app: some for regular users and some for administrators. Using Authority, you’d have two authorizer classes. You might call them BasicAuthorizer and AdminAuthorizer.

You could group your models like this:

BasicAuthorizer   AdminAuthorizer  
      +                +          
      +-+       +------+          
        +       +      +          
     Comment Article Edition

In this example, the Comment model’s authorization rules come from BasicAuthorizer, but Article and Edition get theirs from AdminAuthorizer. You’d call self.authorizer_name = on each model to set this up.

The AdminAuthorizer might have a method like this:

class AdminAuthorizer < Authority::Authorizer
  def self.creatable_by?(user)
    user.is_admin?
  end
end

Anytime a user tries to create an Article or an Edition, this method will be called. If the user isn’t an admin, it will return false and the action will be denied.

Any method that isn’t defined on an authorizer will be inherited from Authority::Authorizer, which will consult a configurable default_strategy proc. The built-in default strategy simply returns false. This is a whitelisting approach: any action you don’t explicitly allow will be forbidden. But you can supply your own default strategy to do something more nuanced.

So the full lookup chain looks like this:

        default_strategy          
               +                  
      +--------+-------+          
      +                +          
BasicAuthorizer   AdminAuthorizer  
      +                +          
      +-+       +------+          
        +       +      +          
     Comment Article Edition

Standard Ruby Classes And Methods

The nice thing about this structure is that it’s just regular object-oriented programming. Your authorizers are just classes, so you can modify them any way you like: include modules, change the parent class, metaprogram, etc.

In addition, the authorizer’s methods are just plain Ruby methods: there’s no new syntax to learn. Authority makes no assumptions about what logic you’ll need. You can consult a database or a file or a web service to make your decisions; if you use a database, you can use whatever ORM you like. All the logic is up to you; Authority just helps you keep it organized.

Syntactic Sugar for Users

So far we’ve seen our authorization methods in the passive voice: is this resource creatable by this user? But it’s nice to be able to say the same thing in an active voice: can this user create this resource?

Like several other popular authorization gems, Authority gives you this syntactic sugar. current_user.can_edit?(@article) is simply a pass-through to @article.editable_by?(current_user), which in turn would ask the AdminAuthorizer.

Since can_edit? and similar methods are defined on the user object, you can use them anywhere that object is available. A common case would be to show links only to users who should see them:

link_to new_article_path if current_user.can_create?(Article)

A Little Magic for Controllers

If you’re using the method shown above to hide links from unauthorized users, most people won’t try anything they shouldn’t be doing. But what if someone manually types the URL to edit a resource that’s forbidden for them?

At that point, your controller must intervene. Authority gives you a couple of methods for this: authorize_actions_for(ModelName), which checks class-level permissions and will stop the controller method from ever running, and authorize_action_for(@model_instance), which checks instance-level permissions from inside a controller method.

In either case, forbidden actions are handled by a controller method that you specify; the default one logs the user’s action and displays a warning.

Check it out

You can get more detail on everything discussed here by looking at the README on Github. I’d also encourage you to read the source code; Authority isn’t a large gem, and the source is well-commented. You may learn something, and of course, reading the code is the first step towards contributing.

Happy hacking!

Sinatra: Up and Running was published at the end of last year by O’Reilly Press and is the first book to be written exclusively about Sinatra. It is written by Alan Harris and Konstantin Haase. Konstantin is the current maintainer of Sinatra and probably knows more about it than anybody else (You can find out more about him in my interview). Alan has already written two books about Python, and is also an enthusiastic Rubyist and Sinatra user. I have been waiting for a book to be written about Sinatra for a long time and was really looking forward to this … and it didn’t disappoint.

The book is very thin and weighs in at just over 100 pages. But, like Sinatra, it packs a big punch into a small, lean package. It covers the latest version of Sinatra at the time of writing (1.3.1) and gets started quickly: The first chapter introduces Sinatra along with its design goals and philosophy. There’s also an interesting section on how learning Sinatra will help to develop transferable skills that can be used in other development environments. The first chapter concludes with a quick tutorial that uses Sinatra to build a complete web app. It’s a very basic rendition of the classic kid’s game Rock, Paper Scissors that perfectly emphasizes Sinatra’s credentials for rapid development. This chapter does dive straight in to some of the more advanced aspects of Sinatra, but it is more to whet the appetite for what is to follow, rather than a tutorial of how it works (and this is made clear in the text).

The second chapter is very referencey in nature as it goes through a large number of Sinatra’s methods and how they work. It begins by going through the basics of HTTP headers and verbs such as GET, POST, PUT, DELETE and the newly added PATCH, which helps develop an understanding of how Sinatra is essentially a wrapper on top of Rack for routing HTTP requests. In fact, this chapter illustrates the fact that Sinatra is really just a collection of helper methods that provide syntactic sugar for Rack’s methods. A Highlight in this chapter was the introduction of the new streaming API that allows you to keep the connection to the server open and do things like this:

get '/' do
  stream do |out|
    out << "3
    sleep 1
    out << "2 n"
    sleep 1
    out << "1n"
    sleep 1
    out << "BLAST OFF!!!"
  end
end
 

The chapter also covers useful stuff such as caching, error handling (particularly 404 and 500 Internal Server errors), before and after filters, and rendering views and sessions. A lot of this info can be found in the excellent ReadMe section of the Sinatra website, but it was nice to see it all written down in the same place.

Chapter 3 starts to get heavier and highlights the symbiotic relationship that Sinatra has with Rack – the foundation for its magic. For example, there is a nice explanation of how the ‘get’ method works. It also covers how to go about extending the functionality of Sinatra using extension methods and helpers. Generally, extensions are used configuration or routing, whereas helpers are used in view blocks and templates. The chapter then goes quite deep into Rack and has a great example of a mini-implementation of Sinatra using Rack, which shows a little of how Sinatra and Rack work together. The chapter finishes by discussing how to use Sinatra to create Rack middleware applications.

Chapter 4 shows how you can subclass Sinatra in order to build modular applications. This builds the foundations of the good practice of creating your own structured framework. This is done by subclassing Sinatra itself like so:

require 'sinatra/base'

class MyApp < Sinatra::Base
  ... code for your App goes here ...
end

It then goes on to explain how to use the run! command to get the server started. Settings are discussed next and, it turns out, they are actually just methods of the application class. It also covers subclassing these classes further and how the routes are inherited. The next section is really cool – it shows how you can very easily mimic Rails’ controller architecture by subclassing Sinatra::Base with an ApplicationController class and then subclassing your controllers from this, like so:

require 'sinatra/base'

class ApplicationController < Sinatra::Base
    ... general controller code goes here ...
end

class myController < ApplicationController
    ... specific controller code goes here ...
end

Things get even cooler as the authors demonstrate how to dynamically create applications on the fly using Sinatra.new. The chapter finishes off by showing how these subclasses fit into the Rack ecosystem as middleware and also how to use Extensions and Helpers in modular applications.

The last chapter in the book takes a more tutorial-led approach, going through the steps required to build a blog application that uses Git for versioning. There are some great nuggets in this chapter, including using the ostruct library to store the blog posts, using a hook to reload the app whenever there are any updates, and parsing the data for each article on the pages. It was also nice to see how the project folder was structured and some examples of views using erb, markdown, JavaScript and CSS. As a tutorial, it moves along at a fair pace – a lot of ground is covered in only a few pages – but it is easy to follow.

I was really impressed with this book. There isn’t much there, but what is there is worth it’s weight in gold and you can fly through it in a weekend (a plus point in my view). A word of warning though – it’s quite theoretical in places. Although you don’t need to know anything about Sinatra as a prerequisite, you will need a reasonable level of Ruby knowledge in order to follow along. You also need to be fairly confident at using the command line and installing gems as well as firing up a local server.

This shouldn’t put anybody off though – nothing is particularly difficult and since everything in Sinatra is just Ruby there are lots of places you can go to find out more information. I also found that the book really helped to improve my Ruby skills – it’s choc full of well-written snippets of ruby. It also encourages you to fire up an irb session and experiment with Sinatra in order to help further your understanding of how it works.

As the first book about Sinatra, I feel that this book is a success. The authors have done a great job of introducing Sinatra as well as giving the reader a thorough understanding of its inner-workings. Although the first and last chapter both contain example apps, they don’t really cover many use-cases. I feel that there is still a space for a more practical book that goes through building apps in more detail and design patterns that can be used for different types of applications. For example, database-driven apps are not featured at all in the book. If you want more practical advice then I can recommend Cloning Internet Applications in Ruby by Shau Seung.

The good news is that I hear there’s a follow up planned. Some things I’d like to see covered are:

• More examples of using the streaming API
• Testing … it’s not covered at all in the book
• How to structure a modular application (file structure etc)

In the meantime, I would recommend anybody with an interest in improving their Sinatra or Ruby skills, or finding out what all the Sinatra fuss is about to buy this book.

Rule one to metaprogramming: Don’t Panic!

Like many others, I have struggled with the term metaprogramming. For the purposes of this article I’ll be going broad with my working definition of metaprogramming to include:

Any code that significantly raises the level of abstraction and/or any code that creates code. -Me

This definition is wildly oversimplified. But in order to start learning to metaprogram you have to have something you can point to and say “That is metaprogramming.” I’m also intentionally side-stepping the “There is no metaprogramming, there is only programming” stance here. While I partially agree, this is not the place for such a philosophical debate. If you are interested in that debate, there is a great Ruby Rogues podcast about it where several prominent “Rubyists” discuss the definition of metaprogramming in much greater detail.[1]

To start with, metaprogramming is not magical. It will not solve all of your problems. Its usage will not make you a rock star. I’m also going to bypass the whole, “You really shouldn’t run with scissors,” warning and assume that you’ll apply sound logic in your application of metaprogramming. Caveats aside, it can be a wonderful addition to your toolbelt. Quite simply, it is a way to get your code to do a little bit more for you. If used properly, it will result in less repetitive, more easily tested, and cleaner code. It may be a little confusing to understand at first, but once you get the knack of it you can solve a host of problems that would be incredibly difficult otherwise. In Part One of the guide, I’m going to run through several class/module hooks. These hooks will allow you to improve the readability of your code. Sometimes it feels like magic, but it’s not.

If you get lost anywhere, just remember rule #1. Also, look to the end of the post for links to more resources/help.

The hooks

inherited

The first hook I’d like to discuss is #inherited. It is the hook that allows code like this to exist in Rails:

class Post < ActiveRecord::Base
  has_many :comments
end

The new developer sees this and either ignores it or infers a comment above class Posts that says something to the effect of #there be dragons here. Not true. The “magic” is in relying on the Ruby hook provided by #inherited. You won’t find #inherited on ruby-doc.org because it is a private method (which ruby-doc.org does not list). Instead of calling this method you simply define a method and name it ‘inherited.’ You can see more detail at apidoc.com (this is also true of some of the other methods listed below). If you head over there, you’ll see this short description:

Callback invoked whenever a subclass of the current class is created.

Warning: drastic oversimplification inbound!

Rails does some pretty slick stuff with regards to building the has_many method. But in the end ActiveRecord::Base defines #inherited, which includes has_many and other modules, like so[2]:

module ClassMethods
  def inherited(child_class) #:nodoc:
    child_class.initialize_generated_modules
    super
  end
  #etc
end

class Mammal
  def self.inherited(child_class)
    puts "Hey I'm going to be called when I'm inherited"
    super
  end

end

class Dog < Mammal
end
#

=> "Hey I'm going to be called when I'm inherited"

Pretty dern cool, imho. It is important to note that #inherited is called before subclass is fully defined, so any conditional logic that involves the subclass will not work. Also, calling super after is reccomended after executing your custom code.

included

Callback invoked whenever the receiver is included in another module or class.

Every Ruby developer is familiar with #include, which allows you to inject a module’s instance methods into a class. Similarly, to include a module’s class methods you’d use #extend. So, if you had a module that has both instance and class methods, you’d have to do something like the following to get the entire module into your class:

class MyClass
  include Mymodule # instance methods
  extend Mymodule # class methods
end

Which brings us to our next hook, which allows us to execute arbitrary code whenever a module is included into a class. It’s defined on Module, and there are some idioms associated with its use. To accomplish the preceding example, you could simply define #included:

module MyModule
  def self.included(base)
    base.extend(ClassMethods)
  end

  def hellofrominstance
    puts "hello from #{self}"
  end

  # Conventionally named ClassMethods
  module ClassMethods
    def hellofromclass
      puts "Hello from #{self}"
    end
  end
end

# including MyModule will call the hook (#included) which
# extends the class methods
class Blah
  include MyModule
end

pry(main)> Blah.hellofromclass
#=> "Hello from Blah"
pry(main)> Blah.new.hellofrominstance
#=> "hello from #"

This is just one use of #included. Any code could be executed in the included hook, but this is a common idiom that you will see. When we include MyModule into the Blah class, we saw the hook fire, which calls extend on ‘base’. In this case, the argument ‘base’ represents the current self which ends up being Blah at the time included is called (yikes, we’ll talk more about self in another post). Pretty Batman, right?.

extended

I won’t go into this at length due to its similarity to #included. It will fire arbitrary code when the module is extended. It is my opinion that doing the inverse of the above (included) idiom is less acceptable. However, I think this is still an amazing tool. A completely contrived example could look like this:

# execute this snippet

module MyModule
  def self.extended(base)
    puts "Howdy!"
  end
end

class Blah
  extend MyModule
end

=> Howdy!

=> Blah

If you execute the snippet above, you’ll see that #extended gets called when Blah extends it. Pretty neat. Movin’ on.

extend_object

Extends the specified object by adding this module’s constants and methods (which are added as singleton methods).

When you call Object#extend the extend_object, callback is fired. This is especially useful when you would like to extend an object, but only if it has certain characteristics.

module MyModule
  def self.extend_object(obj)
    puts "Hello from #{self}"
    super # important
  end

  def self.hello
    puts "Hello from #{self}"
  end
end

pry(main)> (myextendedstring = "blah").extend(MyModule)
#=> Hello from MyModule
#=> "blah"
pry(main)> s.hello
#=> "Hello from blah"

This will actually extend the variable my_extended_string, which happens to be the string “blah”, with MyModule.

const_missing

This is very similar to method_missing except it is called when a constant is missing or undefined. The example the docs give is pretty hairy, so I’ll make my own very contrived example of what you might use this for.

class MyCustomError < StandardError; end

# super terribad
def Object.const_missing(name)
  raise MyCustomError, "You attempted to use a constant that wasn't defined: #{name}"
end

pry(main)> WTF
#=> MyCustomError: You attempted to use a constant that wasn't defined: WTF from :3:in `const_missing'

Conclusions

These hooks are often used in some of the more clever pieces of Ruby code floating around. Utilizing them can help you write better code. Not only that, but using these methods will also help you solidify your understanding of how Ruby executes/loads/manages each program you write.

In a talk given back in 2007, @pragdave explained some of the reasons why extending Ruby through metaprogramming is one of the mainstays of the language. He spoke of how metaprogramming in Ruby raises the level of abstraction. Essentially, this means increasing the distance between machine/language and your code. This is good for a few reasons. For one thing, the code ends up looking much more readable to both coders and clients. Also, once the underlying code is laid, a new developer has to understand less to be able to contribute. This raised level of abstraction is an amazing part of Ruby, and is prominently featured in some of its largest projects (especially Rails). I hope you find yourself exploring the hooks mentioned above in your own code. I’m sure that if you do, you’ll begin to think of Ruby a little more fondly. Thanks for reading.

This is first edition of Hitchhiker’s Guide to Metaprogramming. The next edition will cover more of the fundamentals of metaprogramming in Ruby. Learn more about metaprogramming at my blog where I’ve posted several links I’ve found helpful while writing this post. ^_^