Andy Lindeman

My Assets Are No Longer Minified in Rails 4: HALP!

2013-05-08T00:00:00-07:00

Rails 4.0 and sprockets no longer heed the config.assets.compress directive. Instead, the JavaScript and CSS compressor must be specified explicitly with config.assets.js_compressor and config.assets.css_compressor, respectively.

No error or deprecation warning is raised: assets will simply not be minified if the Rails 3 config.assets.compress = true directive is left intact.

Unminified assets may cause pages to load more sluggishly.

When upgrading a Rails 3 application to Rails 4, make sure to adjust config/environments/production.rb as shown:

Widgets::Application.configure do
  # ...

  # Compress JavaScripts and CSS
  # config.assets.compress = true <- remove the Rails 3 setting
  config.assets.js_compressor  = :uglifier
  config.assets.css_compressor = :sass
end

Both Rails 3 and 4 use uglifier and sass-rails in the default Gemfile, so these compressors are available unless you have removed them.

With the new settings added, assets will again minify when compiled in production.

If you are interested in more upgrading steps and checklists, check out the handbook I am writing: Upgrading to Rails 4.

Upgrading Rails: Gems Extracted in Rails 4

2013-03-05T00:00:00-08:00

During the development of Rails 4, many features that were present in earlier versions of Rails were removed from Rails itself and extracted to gems.

Extracting features to gems slims down Rails itself, and allows Rails to take a different direction to solve certain problems. For example, strong_parameters in Rails 4 is recommended over attr_accessible and attr_protected from Rails 3 when an application needs to protect itself from mass-assignment vulnerabilities.

Furthermore, some of the extracted gems have new maintainers. These fresh maintainers might respond more quickly to bug and feature requests than the Rails core team feasibly can.

Unfortunately, existing applications that are upgraded to Rails 4 may need to pull in several new gems in order to perform properly. I have compiled a list of these extracted gems and the features they provide. If your application uses any of the listed features, you'll want to pull them into Gemfile while upgrading to Rails 4.

The book I'm writing, Upgrading to Rails 4, goes into more detail about these extractions as well as new features in Rails 4.

Gem	Description
protected_attributes	Because Rails 4 recommends strong_parameters for mass-assignment protection, attr_accessible and attr_protected have been extracted. I expect that most upgraded applications will need this gem, as the transition to strong_parameters can be tedious and error-prone.
activeresource	While the ActiveRecord-like abstraction over a RESTful API has always shipped as a gem, it is no longer included with Rails by default. Include it explicitly if your application requires it.
actionpack-action_caching actionpack-page_caching	Rails 4 includes many improvements to fragment caching, but action and page caching have been extracted. If your application uses action or page caching, be sure to pull these gems in explicitly.
activerecord-session_store	The ability to store session data in a database table has been extracted in Rails 4. If your application uses the ActiveRecord session store, include this gem.
rails-observers	Rails no longer encourages the use of observers, separate objects that can react to lifecycle events of ActiveRecord models. If your application uses observers, make sure to include this gem.
actionpack-xml_parser	Following security vulnerabilities involving inbound XML, Rails extracts the ability to accept XML input to a gem. If your application accepts XML in a request body (note: this is distinct from responding with XML), you will need to pull in this gem.
rails-perftest	Rails 4 extracts ActionDispatch::PerformanceTest. If your application includes performance tests (usually located in test/performance), add this gem to your bundle.
actionview-encoded_mail_to	Rails previously included a little-known feature to obfuscate email addresses in hyperlinks, either with HTML entities or JavaScript code. If your application uses the encode option with mail_to, include this gem.

If you're interested in more details about upgrading to Rails 4, please consider buying my Upgrading to Rails 4 handbook.

Decoding Rails Session Cookies

2013-02-18T00:00:00-08:00

An Upgrading to Rails 4 reader emailed me about this quote from the book:

Rails 3 uses digitally signed cookies as the default store for sessions. Digitally signed cookies cannot be easily tampered with, but users can read the data that is being saved.

He asked:

Would you say that's something trivial to do, or would it involve some decent amount of work? Just by accessing the Rails 3 cookies from my browser's inspector, I can't seem to find a way to read the content from them.

Great question! Let's try.

For this example, I setup a Rails application that sets a session key to a constant value:

class ApplicationController < ActionController::Base
  before_filter :add_value_to_session

  private

  def add_value_to_session
    session[:message] = "Hello World!"
  end
end

If I hit the Rails application with curl -i (include headers), I see:

$ curl -i http://localhost:3000/
HTTP/1.1 200 OK 
Set-Cookie: _railsapp_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJWYxZGNlMmNmYjFmYjBkODQ0NTc1ZWE3OTBjZmJmNTZkBjsAVEkiDG1lc3NhZ2UGOwBGSSIRSGVsbG8gV29ybGQhBjsARg%3D%3D--decd8e233744e2ba5a80481426e41d72a6685986; path=/; HttpOnly

The cookie data looks obfuscated, but in reality it's shrouded only by Base64 encoding.

Rack's session cookie methods can easily decode it:

# decode.rb
require 'rack'

puts Rack::Session::Cookie::Base64::Marshal.new.decode(ARGV[0])

Running decode.rb with the cookie's data results in:

$ ruby decode.rb BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJWYxZGNlMmNmYjFmYjBkODQ0NTc1ZWE3OTBjZmJmNTZkBjsAVEkiDG1lc3NhZ2UGOwBGSSIRSGVsbG8gV29ybGQhBjsARg%3D%3D--decd8e233744e2ba5a80481426e41d72a6685986
{"session_id"=>"f1dce2cfb1fb0d844575ea790cfbf56d", "message"=>"Hello World!"}

Our message, alongside a generated session identifier, is available without the Rails application's secret session token.

Attempting to tamper with the data, repackage it, and send it back to the server would fail because the digital signature would not check out, but the data is at least readable.

Rails 4 will feature an encrypted cookie store, where data is both digitally verified and unreadable to end users. I write about this (and more, of course!) in Upgrading to Rails 4.

In closing, remember:

The default Rails 3 session store (cookie store) allows users to read the contents of the session. They may not, however, change or tamper with the session data.
Do not store data in the session that would be sensitive even if the data were read by an end user or an attacker sniffing the traffic.
Switch to the encrypted cookie store when Rails 4 ships.

rspec-rails and capybara 2.0: what you need to know

2012-11-11T00:00:00-08:00

Background

Writing full-stack tests is important. I go into detail about this in my Acceptance Testing slide deck.

In a Rails application, RSpec request specs are often used for the task of writing full-stack tests. In capybara 1.x, request specs both wrap Rails' IntegrationTest framework and mix in capybara, a tool for driving web applications (often via headless web browsers).

Confusion

The fact that request specs both wrap a Rails IntegrationTest and have capybara methods mixed in is confusing. José Valim goes into depth about the problems in his blog post entitled "Improving the integration between capybara and RSpec".

If you've ever confused get (Rails) with visit (capybara) or response with page, or attempted to explain the difference to a newcomer, you know it is odd and often frustrating.

The RSpec and capybara teams worked together to alleviate the confusion in capybara 2.x.

Changes

Upon upgrading to capybara 2.0, capybara will not be available by default in RSpec request specs. Instead, a new type of spec--the feature spec--has been created for use with capybara.

To upgrade to capybara 2.0, you'll need to do a few things:

Upgrade rspec-rails to 2.12.0 or greater
Move any tests that use capybara from spec/requests to spec/features. Capybara tests use the visit method and usually assert against page.

Alternatively, you can keep using capybara in request specs, but you'll need to manually mix in the methods.

Examples and Recommendations

The rest of this piece has some of my opinions, but opinions I've had good success with in the applications I develop.

Use RSpec request specs to test interactions with your application as a HTTP API. To do so, use methods like get, post, put, delete and assert against response:

# spec/requests/widget_api_spec.rb
describe "widget API" do
  it "allows API clients to create widgets" do
    post widgets_url, widget: { name: "Awesome Widget" }, format: "json"

    expect(response.status).to eq(201) # "Created"
  end
end

Use RSpec feature specs (with capybara) to test your application as a user might interact with it. To do so, use methods like visit and assert against page. You may also use feature instead of describe and scenario instead of it to increase readability:

# spec/features/widget_management_spec.rb
feature "widget management" do
  scenario "creating a new widget" do
    visit root_url
    click_link "New Widget"

    fill_in "Name", with: "Awesome Widget"
    click_button "Create Widget"

    expect(page).to have_text("Widget was successfully created.")
  end
end

Shoutouts

The capybara team, especially Jonas Nicklas, were pivotal in making these changes happen. In fact, my own role was small comparatively. Thank you Jonas!

Thanks to Darren Coxall, Jim Hodgson, and David Chelimsky for reviewing this post.

Introducing rake-rails

2012-05-23T00:00:00-07:00

JRubyConf 2012 was a blast. Thanks Nick and all the others who made it happen.

I enjoyed many of the talks, including Adventures on the Golden Path by Jeff Casimir.

Admittedly, I do not agree with all of his ideas or his implementations, but one that struck me as a good idea and low hanging fruit was the confusion among the rails and rake commands:

Beginners and advanced users get tripped up by this one all the time.

So, I tried whipping up a gem that delegates rake generate, rake console, etc.. to their respective rails command.

It's called rake-rails:

# Gemfile
gem 'rake-rails'

Profit! You can now run ALL the things with rake.

$ rake generate migration add_name_to_users name:string
$ rake console staging
# ...

For efficiency freaks: it's still pretty fast and does not involve loading the Rails environment multiple times; it simply delegates to rails/cli as quickly as possible, just like the rails command does.

Try it out and let me know what you think! Everything is up on GitHub.

Callbacks and Background Jobs

2011-10-02T00:00:00-07:00

TL;DR: Don't use after_{create,update,save} to enqueue a background job; instead use after_commit because the database transaction will be committed.

Rails' callbacks are popular way to hook into the lifecycle of a model, and use these hooks to automatically perform tasks when a model changes.

For instance:

class Image < ActiveRecord::Base
  after_create :generate_thumbnail

  def generate_thumbnail
    # ...
  end
end

In this case, we are generating a thumbnail for an image after it is created.

Because it's likely that generating a thumbnail is an expensive operation that could easily bog down the web server and web requests, many folks would refactor it to enqueue a background job that generates the thumbnail at some time in the future:

class Image < ActiveRecord::Base
  after_create :enqueue_thumbnail_job

  def enqueue_thumbnail_job
    Resque.enqueue(ThumbnailJob, id)
  end
end

In this case, we are using a Resque job to do the heavy lifting. We avoid bogging down web requests with thumbnail generation.

Great, so imagine the Resque job looks something like:

class ThumbnailJob
  def self.perform(id)
    image = Image.find(id)
    image.generate_thumbnail
  end
end

The problem is that after_create (and most other Rails callbacks) are executed within the context of a transaction: other database sessions will not see the changes to the database until after the changes are committed.

If the background worker was incredibly fast at popping off a job, it is possible that Image.find(id) would fail because the database transaction had not yet completed. The row would not be visible to other database sessions yet.

Granted, it is unlikely that this will occur as there is a delay between the time a job is enqueued and when it is started by a worker process; however, it could happen in a small number of cases, and when it does, it would be very hard to debug and reproduce.

So, what's the solution?

The after_commit callback, introduced in Rails 3 and available as a plugin in Rails 2.

class Image < ActiveRecord::Base
  after_commit :enqueue_thumbnail_job

  def enqueue_thumbnail_job
    Resque.enqueue(ThumbnailJob, id) unless destroyed?
  end
end

NOTE: We also check to make sure the object is not destroyed, as after_commit is called upon destruction as well (thanks zimbatm).

Moral of the story: if you expect another process (e.g., background job) to see changes to the database, wait until the database transaction is completed (after_commit).

Testing Devise with RSpec Request Specs and Capybara

2011-09-25T00:00:00-07:00

Many questions about testing Devise come up regularly in the freenode/#rspec IRC channel. Often, folks ask how to use RSpec request specs to write integration level ("full stack") tests against Devise.

In integration tests, ideally nothing is mocked or stubbed. Using the recommended setup for controller tests, for instance, is not a good idea in request specs. We want to click links exactly as a user would, fill in forms exactly how a user would, etc...

This post assumes you have a Devise setup running already. If not, start with the Devise README.

First, RSpec request specs can use either Capybara or Webrat. I prefer Capybara. To install, add this line to your Gemfile and run bundle install:

gem 'capybara', :group => :test

Next, add require 'capybara/rspec' to spec/spec_helper.rb:

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rspec' ### ADD THIS LINE

Finally, RSpec request specs must be created in the spec/requests directory under your Rails root, so create that directory if it does not already exist.

Now you're ready to start writing specs! For example, here's a simple one I named spec/requests/user_registration_spec.rb:

require "spec_helper"

describe "user registration" do
  it "allows new users to register with an email address and password" do
    visit "/users/sign_up"

    fill_in "Email",                 :with => "alindeman@example.com"
    fill_in "Password",              :with => "ilovegrapes"
    fill_in "Password confirmation", :with => "ilovegrapes"

    click_button "Sign up"

    page.should have_content("Welcome! You have signed up successfully.")
  end
end

And here's one to test user sign in, named spec/requests/user_sign_in_spec.rb:

require "spec_helper"

describe "user sign in" do
  it "allows users to sign in after they have registered" do
    user = User.create(:email    => "alindeman@example.com",
                       :password => "ilovegrapes")

    visit "/users/sign_in"

    fill_in "Email",    :with => "alindeman@example.com"
    fill_in "Password", :with => "ilovegrapes"

    click_button "Sign in"

    page.should have_content("Signed in successfully.")
  end
end

Hopefully these serve as a good starting point for your tests.

As you move beyond these basic specs, check out these resources:

What's The First Release That Contains This Commit?

2011-09-12T00:00:00-07:00

If the project is using `git` and tags each release, it is really easy to ask `git` which tag is the first to contain a given commit.

For instance, take 58a46bf on Sunspot which added the `Sunspot.optimize` method:

$ cd /path/to/sunspot
$ git describe --contains 58a46bf
v1.2.0~22

In this case, `v1.2.0` was the first tag to contain the commit in its tree, and it was `22` commits away.

To use `Sunspot.optimize`, you’d need at least Sunspot v1.2.0.

ruby-debug and "Warning: saved frames may be incomplete"

2011-08-04T00:00:00-07:00

I like using ruby-debug (well, ruby-debug19 for Ruby 1.9), a command line debugger for Ruby.

Occasionally, though, I would run into an issue where the backtrace (bt) command did not give a useful stack trace.

(rdb:1) bt
--> #0 at line /.../config/initializers/omniauth.rb:11
Warning: saved frames may be incomplete; compare with caller(0).

Thanks to a StackOverflow question, though, I’ve found the solution: require “ruby-debug” and call Debugger.start as soon as possible in the application being debugged.

For a Rails project, this may look like adding the following to config/environments/development.rb:

require 'ruby-debug'
Debugger.start

Sweet, sweet backtraces return!

(rdb:1) bt
--> #0 OmniAuth::Strategy.fail!(message_key#Symbol)
       at line /.../lib/omniauth/strategy.rb:11
    #1 OmniAuth::Strategy.fail!(message_key#Symbol)
       at line /.../lib/omniauth/strategy.rb:224
    #2 OmniAuth::Strategies::OpenID.start
       at line /.../lib/omniauth/strategies/open_id.rb:71
    #3 OmniAuth::Strategies::OpenID.request_phase
       at line /.../lib/omniauth/strategies/open_id.rb:63
    ...

Optimistic Locking with MongoDB (and mongo_mapper)

2011-07-06T00:00:00-07:00

(cross posted on the Highgroove Blog)

At Highgroove (where I work), we build database-backed web applications. These days, there are many options when choosing a database backend. We normally start with relational database systems (e.g., PostgreSQL and MySQL) because they are very mature and feature niceties like ACID transactions and locks.

On the other hand, we also work with newer NoSQL database systems that often trade features like transactions, locks, and joins for higher performance and scalability. One popular option is a document-based store called MongoDB. By design, MongoDB does not support ACID transactions (though many operations are atomic) or traditional locks.

In many cases MongoDB, paired with an object-relational mapper like mongo_mapper is a great solution for Ruby and Rails applications. And after the break I explore a solution that allows a developer to “lock” a MongoDB document while still maintaining the high performance and other features MongoDB is known for.

mongo_mapper loads documents from MongoDB into memory as a Ruby object. Typically, a program then changes a few values and saves the record. Notably, saving the record actually resets every field in the document to the values in the Ruby object.

Unfortunately, data and work can be lost if multiple processes (e.g., different web server processes/threads or background workers) are interacting with the same documents at the same time.

For instance, in the code below if two processes execute post = BlogPost.find("4e13cda850b86112c9000001") at roughly the same time, one will end up overriding the other because the values in memory will be stale.

This problem is not unique to MongoDB or mongo_mapper, but the potential solutions are different from relational databases because MongoDB documents cannot be exclusively locked.

One way to solve the problem is to only interact with MongoDB through its atomic operations, but many of the conveniences of an object-relational mapper are lost for a problem that may only occur sporadically.

Another way is to use optimistic locking, a technique that reliably determines if a record has been updated by another process between the time it was initially loaded into memory and the time a save is attempted. If the record has been modified by another process, an error is raised and the object must be reloaded. If objects are not in high contention and retrying the operations is easily accomplished, optimistic locking is a good solution that keeps performance high in the average case.

If using optimistic locking with a background job, a reasonable response to a stale document error would be to reload the record, retry the operation, and attempt a save again. On the other hand, if two end users are in contention, the stale document could be presented to one of the users for manual conflict resolution.

We have written a small gem that implements optimistic locking with mongo_mapper called mm-optimistic_locking. It is very straightforward to use and we think it does its job well, but we definitely welcome feedback.

An example usage is shown below (basic mongo_mapper familiarity assumed):

More information is available in the README and its GitHub homepage.

Introduction to Solr and Sunspot

2011-04-14T00:00:00-07:00

For the April meeting of the Huntsville Ruby Meetup, I recorded a 5 minute lightning talk screencast giving a high level overview of setting up Solr and Sunspot.

Solr and Sunspot give you powerful full-text search within Ruby applications. The sunspot_rails gem plays really nicely with Rails.

More info:

Solr: http://lucene.apache.org/solr/
Sunspot: http://outoftime.github.com/sunspot/

Enjoy and give me feedback!

Remote Pair Programming

2011-03-05T00:00:00-08:00

I don’t think I’ve ever not learned something from talking to another developer. The world of developing software is simply too big for one person to grok completely: anyone can have insight or experiences that have value when shared.

Along those lines, pair programming is a technique that champions the benefits of two developers working on the same problem at the same time.

College was my first experience with pair programming; unfortunately the introductory lab for “Computer Science 101” was simply not the appropriate time to introduce it. That poor execution put a foul taste in my mouth for the technique.

However, as I moved into the software development industry, I heard more and more respected programmers tout the benefits.

Finally, I gave it another shot with Ashish Dixit earlier today. We even went a step further, doing remote pair programming as we were not physically located in the same place.

We hacked on a Kata that initially appeared simple, but ended up being complicated enough to spur some great discussion on design and testability.

We started by writing a failing test, then taking turns writing the code that would make the test pass. We discussed opportunities for refactoring along the way. Each of us had the ability to dive in whenever we saw room for improvement.

It was remarkably easy to get started. We used Skype to talk and TeamViewer for sharing a screen and allowing remote control.

I was really struck by how much I was invigorated by the experience. Ashish has previously blogged about his experiences as well.

I want to do this again! Any takers? Let’s hack on a Kata, Ruby Quiz, or an open-source project. Get in touch with me!

Beware of Ruby Sugar

2011-01-22T00:00:00-08:00

Yesterday, I posted a tip about iterating through time with Ruby and Rails/ActiveSupport.

Originally, I posted this code. This code is actually not valid in Ruby 1.9 anymore.

# Steps day-by-day from today until 5 days from now
Range.new(Time.now, 5.days.from_now).step(1.day) do |time|
  puts time
end

This code looks amazingly compact and incredibly idiomatic … right?

Well, not so “fast”. Take a look at the API documentation for Range#step:

Iterates over rng, passing each nth element to the block. If the range contains numbers, n is added for each iteration. Otherwise step invokes succ to iterate through range elements.

A Time instance is not a number, so Range#step is stuck calling Time#succ 86400 times (the number of seconds in a day) between steps. To add insult to injury, Time#succ creates a new Time instance: we create 86399 useless objects between steps!

Yeouch.

While it’s often reasonable to sacrifice a bit of performance for idiomatic, readable code, in this case, the price is certainly too high.

Lesson learned: Peel back at least one level of abstraction when writing any code that looks a bit magical.

In the end, I recommend this code:

now = DateTime.now

# Second argument defaults to 1, but shown for clarity
now.step(now + 5, 1) do |time|
  puts time
end

DateTime has its own #step instance method which can be much more specific about its implementation than Range#step which must operate correctly on nearly every type of enumerable object.

Final thought: Sometimes abstractions and duck typing are great things, but be especially careful with methods that accept any object that implements a very limited public API (in this case, Range with objects that respond to #succ). In many cases, using only this limited API results in very bad inefficiencies.

Iterating Through Time With Rails

2011-01-21T00:00:00-08:00

Be sure to read the follow up post where I analyze this a bit more and make better recommendations.

I just learned this neat trick from @rjspotter.

# Could also use Enumerable#map with Time.at
Range.new(Time.now.to_i, 5.days.from_now.to_i).step(1.day) do |seconds_since_epoch|
  time = Time.at(seconds_since_epoch)
  puts time
end

Right now, for instance, that outputs:

Fri Jan 21 15:25:32 -0600 2011
Sat Jan 22 15:25:32 -0600 2011
Sun Jan 23 15:25:32 -0600 2011
Mon Jan 24 15:25:32 -0600 2011
Tue Jan 25 15:25:32 -0600 2011
Wed Jan 26 15:25:32 -0600 2011

Replace days with hours, minutes, weeks, etc…

Notably, this uses Range#step from Ruby core and ActiveSupport’s monkey patching of Numeric from Rails.

While the #to_i calls look a bit unappealing, it’s important that Range#step is called over numbers, or else it would have to call #succ 86400 times between iterations!

P2PU: Introduction to Ruby and Rails (Signup Closed)

2011-01-19T00:00:00-08:00

As I mentioned previously, I’m organizing and facilitating a free (as in cost and content licensing) Peer 2 Peer University (P2PU) course called Introduction to Ruby and Rails.

The signups for P2PU were scheduled to close on 19 January and because of high demand, I interpreted that to mean the beginning of the day. I ended up having over 120 complete applications, and probably closer to 200 including people who expressed interest, but did not complete the sign up task.

To those 50 or so who I accepted to due obvious enthusiasm or otherwise interesting background, congratulations! I’m really looking forward to working with you to expand our knowledge of Ruby and Rails.

To those who I could not accept, all of the coursework will be open and freely available for you to lurk or otherwise follow along. We’ll be using:

A moderated Google Group for high latency mailing list communication
An unmoderated IRC channel for low latency, informal chat
Some sort of wiki/collaborative document editing platform (to be determined)
Weekly coursework with reading assignments and exercises

The course officially starts on 26 January, though I’ll aim to have the week 1 coursework finished and available by the beginning of that week.

Defining Methods Using Blocks in Ruby

2011-01-08T00:00:00-08:00

While chatting on irc.freenode.net#ruby this evening, I ran across someone attempting to define a singleton method using a block.

Quick reminder: singleton methods are those defined on a specific object. More information available from the Ruby User’s Guide.

While there are multiple ways to define a singleton method, he needed to use a block that made use of a local variable. His first try was using instance_eval. A simplified version of his code is shown below:

val = "123"

o = Object.new
o.instance_eval do
  def return_val
    val
  end
end

puts o.return_val # expecting "123" but instead raises error

Unfortunately, this code raises an error:

NameError: undefined local variable or method `val'

I was also initially puzzled as to why val in the block (a.k.a. closure) was not bound to the local variable val at the time of block creation.

Mon_Ouie from the IRC channel explains: “Once you use the def keyword, it’s not a closure anymore.”

To achieve the desired behavior while still using a block, something like this is required:

val = "123"

o = Object.new
o_singleton = class << o; self; end; # retrieve singleton class

o_singleton.send :define_method, :return_val do # must use send because define_method is not public
  val
end

puts o.return_val # prints "123" as expected

In Ruby 1.9.x, the define_singleton_method method can be used:

val = "123"

o = Object.new
o.define_singleton_method :return_val do
  val
end

puts o.return_val # prints "123" as expected

Lesson learned: to define a singleton method using a block able to access local variables, use Object#define_singleton_method (1.9 only) or Module#define_method (on the singleton class).

Object#define_singleton_method and Module#define_method do have other uses in Ruby metaprogramming beyond defining these sorts of singleton methods, but more on that in a later post.

P2PU: Introduction to Ruby and Rails

2011-01-07T00:00:00-08:00

A few months ago, as I was diving into learning Ruby on Rails, I saw a tweet by @johndbritton about a need for organizing an Introduction to Ruby and Rails course for Peer 2 Peer University (P2PU). I volunteered to organize and facilitate it.

A little background on P2PU:

The Peer 2 Peer University (P2PU) is an online community of open study groups for short university-level courses. Think of it as online book clubs for open educational resources. The P2PU helps you navigate the wealth of open education materials that are out there, creates small groups of motivated learners, and supports the design and facilitation of courses. Students and tutors get recognition for their work, and we are building pathways to formal credit as well.

P2PU courses do have a facilitator, but the learning mostly happens via interactions among those taking the course, as opposed to one professor-like figure doling out knowledge to students who do not necessarily learn much from one other.

Those who take the Introduction to Ruby and Rails course can expect to complete weekly reading assignments from freely available material, practice with programming assignments, and collaborate with others to explore Ruby, Rails, and the surrounding ecosystem .. as well work through any problems that will inevitably arise! I will also mentor and nudge as required.

The course is targeted at those who already have basic web design experience and basic programming knowledge (in any other language), but applicants certainly do not need to be an expert at either though.

If you are interested .. or know someone who may be interested, please see the course webpage on p2pu.org. Course applications will be accepted starting 12 January 2011, but motivated folks can feel free to complete the required sign-up task now.

Questions? Post a comment here or on the course page.

Weekend Project: GitHub Timeline Widget

2011-01-03T00:00:00-08:00

Over last weekend, I decided to embark on yet another “learn new technologies while creating something non-contrived along the way” project.

I came up with GitHub Timeline Widget, a jQuery plugin that places a widget/badge/sidebar item with your latest actions on GitHub on your website.

It is similar to Dr Nic’s GitHub Badge, but instead of displaying your projects, it shows a compact version of what you would see on the Your Actions tab on your GitHub dashboard.

It’s pretty easy to setup and you can try a live demo first.

For those interested, it’s written in CoffeeScript as a jQuery Plugin using Jasmine as a unit testing framework.

Try it out and give me feedback.

Access to Modified Closure in Ruby

2010-12-22T00:00:00-08:00

Ruby’s blocks are incredibly powerful language constructs and are used throughout idiomatic Ruby code.

More generally, Ruby’s blocks are (for the most part) closures. For instance, they take on the environment in which they were created (often called a binding).

For example, consider this snippet:

The output of this code is “1”

The key here is that while named the same, x in the execute method is different than x in the top level scope.

Since blocks are bound to the environment in which they were created, the x within the block always refers to the x in the top level scope. Setting x within the local scope of the execute method has no effect on the block.

Now, that doesn’t mean that the block is bound to the specific value of x at the time of creation. Consider:

The output of this code is “1” followed by “3”

Contrary to the first snippet, when x is reassigned to 3, it is reassigning the same x as in the environment that the block is bound to. Reassigning x in this case does affect the block.

I think this is enough background to get to the meat of my post: using blocks within looping constructs can (sometimes) produce odd/unintentional results.

Consider this code (that is intended) to produce an array of actions to print “1 2 3 4 5”

If run, though, it outputs “5 5 5 5 5” Huh?

The issue is that each block is bound to the same local variable i, which is reassigned as the loop progresses. When the loop ends, i is set to 5, so every block prints “5”

The reason this issue does not surface very often is that most Rubyists would have written the loop this way:

In this case, i is different variable each time the block passed to Array#each is invoked. Each block is bound to a different environment with a different i.

Again, this issue does not appear very often because the language looping constructs in Ruby (for, while, until) are not used nearly as often as in many other languages.

However, even if you never run a situation where this occurs, understanding why it can happen will increase your understanding of blocks and closures … in Ruby and in other languages.

Note: While in my examples I use the syntaxes interchangeably, there is some variation in the operation of blocks depending on how they are defined (Proc.new vs. lambda vs. unnamed block passed to method). I encourage you to read this paper for more details.

Recursive Reverse Array in Ruby

2010-12-15T00:00:00-08:00

Someone in irc.freenode.net#rubyonrails wanted help writing a function to reverse an array using recursion.

The assignment was obviously contrived simply to teach recursion, since Array#reverse exists in the core library.

Nevertheless, I thought the solution we came up with was pretty elegant and idiomatic Ruby.

def reverse(array)
  array.empty? ? array : [array.pop, *reverse(array)]
end

puts reverse([1, 2, 3, 4]).inspect

The base case is when the array is empty. If it is, stop the recursion and return that empty array.

Otherwise, pop off the last item, placing it at the first position in the new array. The rest of the resulting array comes from a recursive call, passing in array (which is now without its last element due to the Array#pop call).

The splat (*) argument produces a flattened array (without needing to explicitly call Array#flatten).

Thoughts on it? Any ways to make it even more elegant or idiomatic?

UPDATE 16 December 2010

Thanks to Chris Kelly and Matt Todd for commenting. Matt’s proposed solution is definitely more idiomatic and elegant than I proposed above.

class Array
  def recursive_reverse
    return self if empty?
    [pop, *recursive_reverse]
  end
end

puts [1,2,3,4].recursive_reverse.inspect

As Matt points out, this solution takes advantage of Ruby’s open classes. It also returns early to avoid the somewhat ugly ternary operator. Finally, since recursive_reverse is an instance method, the solution eliminates the need for passing the array as an argument.

This was fun! I may try it again in the future with other algorithms.

Rails Dilemma: HATEOAS in XML/JSON Responses

2010-11-13T00:00:00-08:00

One of the tenants of REST is HATEOAS. I understand this to mean that a RESTful response should, if applicable, contain links to the other actions that a client can perform.

Imagine that my Rails application has a Book resource. For the benefit of other applications that use my API, I want to include a purchase_url attribute, which is the link to the URL where the book can be purchased.

For instance (in JSON):

{
  "book": {
    "id":1,
    "name":"Ender's Game",
    "isbn":"0812550706",
    "purchase_url":"http://www.example.com/books/1/purchase"
  }
}

The problem is that generating an XML or JSON representation of the model (by default) resides within the model itself, which does not have access to the functions needed to generate URLs (which are only accessible in the controller and view).

My options, as my current research has uncovered, seem to be:

Instead of using the default rendering method (to_xml, to_json), render a view/partial that builds the XML and JSON exactly as I need. However, this pretty drastically increases the complexity and size of my code and requires constant maintenance as attributes are added or removed.
Mix in an ActionController module into my models to generate the URLs, as described in this Stack Overflow thread However, even Ryan Bates, who answered the question, notes how messy his proposed solution is.
Add a new attribute for the URL which is set by the controller (also mentioned in Ryan’s answer on Stack Overflow).

For now, I’m using the last option. For instance, here is the create method of my controller:

# POST /books
# POST /books.xml
# POST /books.json
def create
  @book = Book.new(params[:book])
  @book.save

  @book[:purchase_url] = purchase_book_url(@book)
  respond_with(@book)
end

I’m really not happy with it, though. First of all, I’m adding an attribute to a model simply to get it to serialize in a certain way. Secondly, this approach is not very DRY: every action of every controller that interacts with a Book model needs the code to set purchase_url. This might be somewhat manageable for one controller, but I imagine it quickly spiraling out of control if the model is ever nested in another resource.

Any thoughts on a better way?

Ignite-Style Talk: Ruby Version Manager

2010-11-09T00:00:00-08:00

I will be presenting at the North Alabama Web Developers Meetup tomorrow (10 Nov 2010).

The plan is to do Ignite style talks: 5 minutes, 20 slides that auto-advance every 15 seconds.

While many Ignite talks are non-technical, I chose to present about rvm (Ruby Version Manager).

If you’d like to follow along, comment, or found yourself here simply looking for an introduction to the tool, I’ve posted my slides below: