The Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries.

By manipulating and building upon Ruby’s TestUnit framework, the EdgeCase developers have created a step-by-step process for teaching Ruby through the practice of “Red, Green, Refactor.” They’ve added some simple game mechanics too, by showing your systematic progression through the 270+ challenges (puzzles). Reaching enlightenment results in a pretty ASCII graphic, and a legitimate sense of achievement.

Before you start with the koans though you’ll need a working Ruby installation. I recommend you take a look at the excellent rvm project, which will allow you to install multiple rubies (1.8.7 and 1.9.2 for example, alongside each other) and multiple gemsets in your home directory. Former Frontiersmen and 2011 Ruby Hero Award winner Darcy Laycock was heavily involved in this project as part of the 2010 Ruby Summer of Code, so we really like rvm at TFG.

The GitHub repository even includes a handy Keynote presentation, which I used as the basis for my talk about Ruby Koans at last week’s Ruby on Rails Oceania Perth meetup.

Lastly, if you’d like to have a play with the koans before diving in too deep, they’re available online through your web browser at Ruby Koans Online. This is a no-risk way of trying out Ruby (hint: team them up with why’s Try Ruby project) in your browser.

Has Face is a neat little gem that uses the face.com API to ensure that an image contains a persons face. It’s very simple to use and can be easily integrated into an existing rails application.

To get started add the has_face gem to your Gemfile and run a bundle install

Can’t see this Gist? View it on Github!

Run the generator to copy over an initializer:

Can’t see this Gist? View it on Github!

The initializer should look something like this:

Can’t see this Gist? View it on Github!

Now we’ll need to make a face.com developer account. You can signup for a free account over at face.com. Once you have signed up, place your API key and API secret in the initializer config.

The last option in the initializer (skip_validation_on_error) will change the behavior of has_face when an error occurs. If set to true, when an error occurs a warning will be logged to the logfile with detailed information about the failure and face validation will be skipped. This can be useful if you want your application to function if the API service is not reachable. If the value is false then an exception will be raised when an API call fails, this will allow you to manually handle the exception yourself, please check the documentation for details on the errors raised.

Once the initializer settings are setup then we can add face validation to a model. In the example below I’m using carrierwave to attach the image to the model but other image attachment gems should also work fine (anything that correctly responds to `path` should be OK).

Can’t see this Gist? View it on Github!

That’s it, that’s all we need to have a functioning face validator. There are a few other options that I haven’t covered here in this short guide, please consult the readme for more detailed information.

It doesn’t handle character encodings though so I went about adding that. With the handy rchardet gem and IConv, detecting the character encoding of the incoming string and converting it to UTF-8 was pretty simple. I’ve created a pull request for the gem that will hopefully be accepted.

The essential code is below, and revolves mainly around the detection and conversion. Using //TRANSLIT causes IConv to try and convert the incoming character code to something that exists in the UTF8 character set, and then //IGNORE will ignore any characters that don’t exist in the UTF8 character set. Chaining //TRANSLIT and then //IGNORE will make IConv try a conversion first and then ignore anything it cannot convert.

I used this gem after the above changes to convert about 400,000 records of text data with ASCII, windows-1252, IBM866 and other character encodings from an old SQLite installation to a new postgres database without any issues.

After looking around for a little while I found this: https://github.com/rspec/rspec-core/issues/370

In short: the new RSpec has been broken up into modules a tad more, the one that we require for rspec to run correctly ‘autorun’ is not included by default, so to solve this simply add require ‘rspec/autorun’ to the top of your spec_helper.

Can’t see this Gist? View it on Github!

Sending push notifications directly from a Rails application can be slow and we probably don’t want to have the user waiting until the notification is sent, instead apn_sender can be setup to run a worker which is constantly connected to the apple push notification service. When there are new notifications to send, the notifications are queued up and sent through the always open connection that is maintained by the worker.

apn_sender uses redis as a message queue to keep track of the notifications waiting to be sent, you’ll need to install it before using the gem.

To add apn_sender in your Rails 3 application, just add the gem to your Gemfile. We’re going to need the daemons gem too so we’ll include that as well.

Can’t see this Gist? View it on Github!

Now we can create our daemon which we will be using for sending push notifications, this can be placed anywhere, I’ve put mine in script/apn_sender. Make sure to add execute permission to the file after creating so we can run it.

Can’t see this Gist? View it on Github!

Before the daemon can start running we’ll need to put our iOS push certificate into the application. Instructions for generating the certificates are available at the Apple Developer site. The certificates need to be placed inside of /config/certs and should be named apn_development.pem or apn_production.pem for production.

Once the certificates are in their correct locations, we can start up the daemon. The daemon does not know about the Rails environment so we need to specify this when starting it up. The daemon supports start, stop and restart commands. There is a verbose flag available to output more information (which can be helpful when debugging).

Can’t see this Gist? View it on Github!

Our application is now set up to send push notifications, this can now easily be performed by adding a new notification to the queue. The notify method on the APN class will take a push notification token and then our parameters, we can specify the alert message to show the user, whether or not we want sound as well as the number to display on the badge icon. Anything else we pass to notify will be sent as metadata in the push notification. Here’s an example of creating a notification.

Can’t see this Gist? View it on Github!

The worker should pick up the notification within a few seconds and send it off. The apn_sender has many other features that I haven’t covered, you can view the full documentation over at https://github.com/kdonovan/apn_sender.

After checking out the project the change was pretty simple but it highlighted an issue that I’ve seen in plenty of code where caching is done too broadly. In this case the cacheing (or memoization) was performed without taking into account the variable that was sent to establish the connection in the first place. The offending method looked like this :

Can’t see this Gist? View it on Github!

This was set on the class and as such @connection would never be created after the first call, whether the token was reset or not. I just changed it so that the connection is cached for each @token the system uses. For us it’s a small number or users, but in a larger context of course you’d need to implement some invalidation protocols to stop the following code from (slowly) swallowing the world :

Can’t see this Gist? View it on Github!

NoToken is just a class inheriting from StandardError that I chucked in there, the only thing that makes the gem now work properly come afterwards. I setup a hash and then store a new connection for each new incoming token, the connection is keyed by the token in the @connections hash. All pretty simple.

I’ve created a pull request that will hopefully be accepted soon, I think it fixes an unexpected problem with the gem.

One of the applications that we’re currently building has a requirement to resize and compress images to produce smaller file sizes, as well as stripping out any personal information that may be stored in the uploaded images.

Out of the box CarrierWave provides a consistent interface to process images using RMagick, MiniMagick or ImageScience. Resizing and cropping is supported for all three image processing engines but setting the quality or removing personal data is not supported. Thankfully, CarrierWave provides an easy way to extend the default functionality so we can do more.

For the examples I’ll be adding extra functionality to RMagick processing. If you’re using MiniMagick or ImageScience the methods will need to be altered to work correctly. We’ll start by adding a new initializer into our application.

Can’t see this Gist? View it on Github!

You may be wondering about the fix_exif_rotation method. Well, some modern cameras always take photos upright, in portrait. When you take a photo in landscape mode the photo is actually saved as a portrait, but the photo will contain some extra orientation metadata. When we remove the embedded data in the photo this value gets removed, so as a result we need to manually rotate the photo, which is what this method does.

The application server will need to be restarted before the new initializer can be used. Once restarted the new filters can be used in an uploader like so:

Can’t see this Gist? View it on Github!

That’s it! That’s all that’s needed to add extra quality and processing functionality to carrierwave.

To list the methods and procs registered with a particular callback, append _callback_chain to the callback name that you wish to list and send that to your class from the Rails console.

This used to work in Rails 2.3.x and I’d used it a few times before, however trying to use it in Rails 3 gave me problems :


HourEntry.before_save_callback_chain
NoMethodError: undefined method `before_save_callback_chain' for #


After some digging around ActiveRecord then ActiveModel and ActiveSupport I figured I could just access the _#{type}_callbacks method and then reject and select these arrays to get what was required. This is what I came up with to get the before_save callbacks that I was interested in.


HourEntry._save_callbacks.select { |callback| callback.kind.eql?(:before) }


This returns me the array of callback objects that are chained before I call save on the HourEntry model. If I want to check for a particular proc being in that chain then I can do :


HourEntry._save_callbacks.select { |callback| callback.kind.eql?(:after) }.collect(&:filter).include?(:archive_if_no_users)


It’s not optimal chaining a number of enumerable methods but I think it seems pretty readable.

I am hoping that the callback_chain methods return at some point (though I only used them sparingly) but more than that I’m hoping someone might be able to set me straight on how I’m going about getting around the callback chains on ActiveRecord and ActiveModel.

ree-1.8.7-2011.02 :132 > Story.joins(:hour_entries).this_week
NoMethodError: undefined method `this_week' for #

The problem was that the .this_week call was being sent to Story rather than to HourEntry. Here’s where Darcy chimed in with the scoped.merge call. It went a little something like this :

Story.scoped.merge HourEntry.this_week

This successfully merged the scope defined by Story with the scope defined by the HourEntry.this_week call and I get all the stories that have HourEntry objects that are returned by the .this_week scope.

The final stage for this call was :

Story.scoped.merge HourEntry.worked_on_by(user).this_week

This then returns all the stories you’ve worked on this week. Add a bit of grouping/distinct and it’s done and done. The additional nice part about this is composing these scopes will allow me to do a lot more in the future, very quickly.

Check it out here – Ruby on Rails Best Practices.