Even though NetApp has a phenomenal reputation – at a technical seminar last year, a sales engineer said that no NetApp customer has ever lost data due to a hardware failure – I still don’t feel comfortable without access to the BMC.

Access to the BMC (on other NetApp devices the LOM controller is called a Remote Management Controller, or RMC) is via SSH, using naroot as the username. From here you can move “up the chain” to a system console, and use CTRL-G to move “down the chain” back to the BMC.

mlambie@prime:~$ ssh naroot@ilca-netapp-bmc
naroot@ilca-netapp-bmc's password:
=== OEMCLP v1.0.0 BMC v1.2 ===
bmc shell ->
bmc shell -> system console
Press ^G to enter BMC command shell
Data ONTAP (ilca-netapp.thefrontiergroup.net.au)
login: root
Password:
ilca-netapp> Mon Mar 12 11:40:27 WST [console_login_mgr:info]: root logged in from console
ilca-netapp> <ctrl g>
=== OEMCLP v1.0.0 BMC v1.2 ===
bmc shell ->

The filer also allows management via SSH directly, and not through the BMC. I used this shell to restart the BMC.

ilca-netapp> bmc help status
bmc status
- Display status for a Baseboard Managment Controller (BMC).
ilca-netapp> bmc help reboot
bmc reboot
- Reboot the Baseboard Managment Controller (BMC)
ilca-netapp> bmc reboot
ilca-netapp> The BMC rebooted successfully

It looks like the SSH daemon was simply hung (it had an uptime of 270+ days prior to the reboot) and restarting the BMC through the management console in this way corrected the issues the monitoring systems were reporting.

A sprint is the basic unit of development in Agile. Sprints tend to last between one week and one month and are a “timeboxed” development effort of a constant length.

Our sprint planning session is broken down as follows:

• Product owner – prioritise and explain highest priority items in the product backlog (we use Pivotal Tracker). The team can ask questions at this point.
• Product owner – set a sprint goal (what are we achieving this sprint).
• Team – select Pivotal Tracker stories you can commit to, to attain that goal.
• Team – demonstrate a solution to each story in the sprint and ensure no outstanding questions.

Our Friday afternoon review session:

• Product Owner and Team  - demo all completed stories.
• Team – Review estimates from the sprint and note down how you went and how you can improve (if target not met).
• Team – Review points missed from the sprint and why, and how you can improve on that for next sprint.

If you’re running sprints in your organisation do you do things a little differently? Drop us a line in the comments.

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.

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.

The solution is to reconfigure the keyboard by running the following command:

sudo dpkg-reconfigure console-setup

To navigate the setup program without the arrow keys, I pressed the first letter of the desired option (eg. “a” for Apple Laptop), then pressed the right command key to cycle downwards through the list.

The configuration options that I chose were:

Apple Laptop for keyboard
USA as origin of keyboard
USA as keyboard layout
No AltGr
No Compose key
Enter for the rest of the defaults.

The arrow keys work fine now.

Since then, the Ruby API has been used to build a couple of small projects and tools but it still maintains relatively undocumented.

Today, I’m going to introduce the basics of working with the Ruby API, starting by introducing the fundamental concepts you need to know and then going on to cover how the most common example of it’s use (rvm gemset support in passenger) works under the hood.

Getting started

First off, you’re going to want to make sure you actually have the Ruby API installed. If you have a remotely recent (e.g. newer than 6 or so months) copy of rvm, you’ll already have a copy – Otherwise, you’re going to need to update your rvm install using rvm update.

To load the API, open up irb and type the following:

# First, find where rvm is installed
rvm_path = File.expand_path(ENV['rvm_path'] || '~/.rvm')
# Secondly, add the ruby library to the load path
$LOAD_PATH.unshift File.join(rvm_path, 'lib')
# Finally, actually load rvm
require 'rvm'

Once said code has been executed, you should have access to RVM constant in your irb session. The method we use to require it means that it is loaded from the currently installed version of rvm so you don’t have to deal with issues related to different versions between rvm itself and the Ruby API.

The bare basics

The ruby api works on the concept of a rvm ‘environment’ – Essentially, you can think of them as the equivalent of a shell instance – They keep track of instance variables, have their own ruby / gemset selection and are sandboxed (for the most part) from other environments. Creating a new environment is as simple as doing the following in your ruby code:

env = RVM.environment 'ree'

Or, alternatively, you can pass a block and it will be called with the environment as an argument. Along side this, you have RVM.environments, which accepts multiple ruby names and calls the block with each environment.

For convenience sake, RVM exposes RVM.current, an environment that defaults to the currently loaded gemset (e.g. if you open irb in rbx@rails3, it will be an environment using rbx@rails3).

As an added bonus, when you call an undefined method on RVM, we automatically use method missing to call it on RVM.current – Hence, If RVM::Environment#some_instance_method exists, you can use RVM.some_instance_method to call it in the current environment object.

Working with environments

So, now that you know how to get environment object, you need to know how to use it. In the simplest form, the Ruby API mirrors the command line program by translating:

rvm command action arg1 arg2

Into:

env.command_action arg1, arg2

With the library automatically taking care of converting arguments (e.g. a hash as the last value will be converted to arguments to the program).

As an example, to call rvm list strings, One would use env.list_strings. Likewise, rvm use becomes env.use and so on and so forth. In these cases, use switches the environments ruby – not the running ruby itself.

One of the added features in the Ruby API is that use and gemset_use have alternatives with a bang (use! and gemset_use!) that will switch the currently loaded ruby’s gemset (by changing GEM_PATH and GEM_HOME and then telling rubygems about the change) - raising an exception if it’s for a different ruby installation. This switch makes it possibly to dynamically switch your ruby applications gemset whilst running.

Of course, dealing with a direct port of the API isn’t always nice when you’re writing a lot of code env.alias_list feels clunky compared to most ruby code and some of the tools are rough around the edges. With this in mind, the ruby api offers wrappers for situations where this becomes noticeable, e.g env.aliases will return a more ruby-like wrapper for the alias command that lets you do things such as env.alias.all, env.aliases.create and so on. In some cases (e.g. env.list_*), the wrappers add features (such as expanding strings) that aren’t found in the bash API via the wrapper.

A real world example

With that said and done, it’s time to look at a real world example. In this case, the most commonly-used example of the rvm ruby API – A use of passengers support for a config/setup_load_paths.rb file which lets passenger automatically load .rvmrc files. When a compatible ruby is detected, the file will automatically switch the gemset on the fly – In essence, letting passenger work with the one-gemset-per-application philosophy we advocate when dealing with rvm.

For references sake, the rvm portion of the code is:

if ENV['MY_RUBY_HOME'] && ENV['MY_RUBY_HOME'].include?('rvm')
  begin
    rvm_path     = File.dirname(File.dirname(ENV['MY_RUBY_HOME']))
    rvm_lib_path = File.join(rvm_path, 'lib')
    $LOAD_PATH.unshift rvm_lib_path
    require 'rvm'
    RVM.use_from_path! File.dirname(File.dirname(__FILE__))
  rescue LoadError
    # RVM is unavailable at this point.
    raise "RVM ruby lib is currently unavailable."
  end
end

Line by line, this code essentially:

1. Checks that we’re loading it in an RVM ruby – rvm always sets the MY_RUBY_HOME environment variable when using wrappers and we ensure that “rvm” is part of said variables value.
2. It begins a begin-rescue-end section of code to load rvm – Giving us a nice error message if rvm isn’t available.
3. Based on my ruby home, We find the location of your rvm install (as rvm_path may or may not be set at this point).
4. We add the rvm ruby lib directory to the load path
5. We require the API

Up until this point, it is almost exactly like our original example. Where it differs is the next line:

RVM.use_from_path! File.dirname(File.dirname(__FILE__))

Knowing what I wrote about earlier, we know this is the same as:

RVM.current.use_from_path! File.dirname(File.dirname(__FILE__))

Which, if we look under the hood, does:

RVM.current.use! RVM.current.tools.path_identifier(path)

Expanding this again using what we learnt earlier, we know that RVM.current.use! will take a given ruby string (e.g. ree@rails3) and attempt to switch out the gemset when the ruby versions match. Continuing on, we know RVM.current.tools.path_identifier is roughly the same as RVM.current.tools_path_identifier – a line which takes a path and, taking into account .rvmrc files, returns the identifier (e.g. ree@rails3) we’d get if we had changed into the given directory from the command line.

Putting it all together, the ruby api essentially just finds out which identifier the given path should use (by loading a projects .rvmrc in the given environment), checks they’re for the same ruby install (to avoid issues with binary gems) and finally switches out the GEM_HOME and GEM_PATH variables for the current process, letting your application use a different gemset.

In short, under the hood it simple finds out the gemset details and updates your application to switch them out similar to how rvm would from the command line.

More examples

We’ve only covered the basics of of the ruby api – For the most part, everything implemented in the bash API is supposed to be (except where it lags behind in terms of updates) exposed via the Ruby API in a simple, consistent manner. In practice, this has primarily been used for things like infinity_test and various CI-related work which make working with multiple rubies easier from ruby applications.

I’d ultimately love to see it used more for tools built around rvm – e.g. a web interface for managing a servers system wide install and exposing it over HTTP. Lastly, because it’s written in Ruby, if you’ve ever wanted to contribute to rvm but have felt apprehensive due to the fact it’s written in shell script, the rvm ruby API is a good place to start.