Ruby annotations

In the programming world, an annotation is a way to mark the code that is below it for many purposes. In Cucumber, the tags it uses are a kind of annotation to apply callbacks and classify some features and scenarios:

Feature: Verify billing
  Scenario: Missing product description
  Scenario: Several products

In the case of VRaptor, we can use annotations to specify a controller as a REST resource or to restrict the access method to an action:

public class ShoppingCartController {
public class ProductsController {
    public void add(Product product) {...}

In the Ruby language, two annotations that are very used are the methods protected and private, which without arguments restrict the visibility of the methods defined below them:

class User
  def jump; end;
  def eat; end;
  def flirt; end;
  def sleep; end;
  def dream; end;

In some situations we may want to annotate our code like this, for example to specify that a method is deprecated, functionality that is offered by the gem Canivete from Douglas Campos:

class Bomb
  def explode; end

In the previous code, when somebody calls Bomp#explode, the interpreter will effectively execute the method, but also will output: Warning: calling deprecated method Bomb.explode.

The key to this behavior is the method_added method which is present in all Ruby modules and which is called every time a method is defined, receiving the name of the method as the parameter.

We can use this method, for example, to create an annotation that specifies that the methods declared below it can only be called by an admin, something like this:

class Module
  def method_added(name)
    unless @_admin_only.nil? or @_proxy_method
      @_proxy_method = true
      alias_method "_admin_#{name}", name
      module_eval <<-STRING
        def #{name}(*args, &block)
          _admin_#{name}(*args, &block) if admin?
      @_proxy_method = false
  def admin_only
    @_admin_only = true
class User
  def admin?
    [true, false][rand(2)]
  def update_password
    puts "password updated"
  def restart_server
    puts "server restarted"

In the previous code, #admin? will randonmly return true or false and depending of the result the called method will be executed or not.

Following Pivotal Tracker projects with Kilt

I’m a big fan of Pivotal Tracker. When we used it at Gonow, the team I was part of did sit at a single table and that was very cool, because even when using the tool, it was very easy to tell everybody what task we were picking or delivering.

When I had the opportunity to work with Pivotal in a remote team, I did miss to know what was happening in real time, so I decided to create Kilt.

Kilt is a daemon created with Ruby that requests the updates of the projects an user is involved with and notifies about them:


With Kilt I can keep working and at the same time being informed of what is happening in the projects I’m working on.

To install Kilt you just need to download the gem and execute kilt-install with your token:

sudo gem install kilt
kilt-install TOKEN

In the case you don’t know your token, you can execute this:


The previous command will return a xml document with the token and id of the given user. Case you didn’t like the command, another ways of retrieving the token can be found in the Pivotal Tracker documentation.

Once installed Kilt, you can initialize it by executing:


The GemHub way to create RubyGems.

What is GemHub?

GemHub is a gem that creates a simple directory structure to build a gem which is gonna be tested with RSpec and hosted on GitHub.

Why not use NewGem or Sow?

If you’re writing a gem and you’re planning to host it in GitHub then NewGem may be not the best option, because it was created with RubyForge in mind and creates a lot of stuff that with GitHub you don’t really need, like a history, post-installation and manifest files, a task folder for putting your tasks, a doc folder for documentation and some scripts generators.

When thinking in GitHub you don’t need a history file because you got Git’s commit history with a click. Also, you can write all kind of instructions in a Readme.textile and that information will appear in the repository site. If you need more detailed documentation, you can write them in the wiki. Finally, when writing a not so complex gem is much probably that you will not need any other task that GemHub’s defaults.

Sow, being a much more simpler option, also generates a history and manifest files. It does also create a Readme file, but with txt extension, what means not cool formatting for GitHub. A bin folder is created by Sow, too. The intention of the bin folder is to put scripts that will be executed in a terminal, what mosts gems don’t need.

Finally, both NewGem and Sow creates tests using Test::Unit. Writing tests with lots of asserts is very ugly when compared to RSpec’s cool expectations, so GemHub uses RSpec as they testing framework.

Working with GemHub

When executed:

gemhub gem_name

GemHub will create a spec/gem_name.rb file to specify your gem’s behavior, a lib/gem_name.rb to implement your gem specification, a README.textile file (with an MIT license included) to write whatever you want and a Rakefile with common tasks. In this Rakefile there are also the details from your gem (name, version, platform, etc).

      create  lib
      create  spec
      create  lib/gem_name.rb
      create  spec/gem_name_spec.rb
      create  README.textile
      create  Rakefile

Anytime before you get ready to create your gemspec file, you should open the Rakefile file and edit the gem details. With your Rakefile edited, you can run rake make_spec to generate the gemspec file of your gem, rake gem to build a gem from your gemspec file and rake install to install the built gem locally. It’s a good practice that before you push your code to GitHub you execute also rake specs to verify that your code operates as expected and rake gem to verify that your gemspec is OK, so GitHub can build your gem without problems.