Easy project history with Conventional Changelog Ruby

Now and then we want to know the evolution of a software we are working on. For some time I thought the Git log of a project was enough, but the truth is there is much noise in there. In addition to the noise, depending of the project, sometimes some not no techie people need to read the product history and doing a git log is not an option for them. A solution many people found for these problems is to keep a changelog file.

For a long time, the problem with changelogs was that they were hard and expensive to maintain, too much time was needed. Fortunately, the AngularJS community created some Git commit message conventions. Definition is a step for automation and Node.js conventional-changelog was created. The main problem with the Node.js version of the conventional changelog is that it doesn’t have an executable and many of my projects are not in Node.js . There is also a Grunt version, but I don’t want to add a Gruntfile to many Ruby projects just to be able to generate a changelog. I thought about creating a pull request adding an executable to the Node.js version, but I also wanted to be able to generate changelogs by dates, not just versions, as until now I haven’t need to use versions in web applications and separating the changes by date seems more natural to me.

Conventional Changelog Ruby was born a tool to easily generate changelogs with Rubygems and Git as the only dependencies. A big addition over the other versions is that changelogs by date are also supported. For more and up to date info, please refer to the README.

https://github.com/dcrec1/conventional-changelog-ruby

Secure your Signal server with the Signal Authentication plugin

Signal doesn’t come with authentication support by default, but as it is a Rails application, is very easy to extend its functionality with a plugin.

We at Gonow started using Signal with Gitorious in a intranet and as we trust each other, authentication was not a problem. As time passed by, we changed Gitorious for Github, so we exposed our server to the internet and as some projects must stay secret, we needed a way to secure them and this way signal-auth was born.

As a Signal plugin is nothing more than a Rails plugin, the installation is like any other:

script/plugin install git://github.com/dcrec1/signal-auth.git

After this, you only need to customize config/signal-auth.yml with your desired user and password.

If you appreciate this work, please consider to recommend me at Working With Rails and to follow me on Twitter.

Signal playing nice with Bundler

When Signal changed to Bundler as the gem dependency manager, all the projects inside it that were also using Bundler started to break, as some gems were not being loaded. This behavior did also occur with other continuous integration tools that also use Bundler, like Integrity.

This problem happend because when Bundler is loaded it sets some environment variables like BUNDLE_GEMFILE and this environment variables were being read by the projects inside Signal.

Let’s suppose Signal is installed in /var/local/apps/signal. When Signal is started, it will load Bundler and Bundler will try to read the environment variable BUNDLE_GEMFILE to know where the Gemfile is. As BUNDLE_GEMFILE is empty, it will read the Gemfile in the application root path and set this path to BUNDLE_GEMFILE. At this moment, the value of BUNDLE_GEMFILE is /var/local/apps/signal/Gemfile.

Now lets imagine we have a project inside Signal called Panthers and that his build script is like this:

bundle install
rake spec

When this script is executed by Signal, it will load Bundler and again Bundler will try to read the environment variable BUNDLE_GEMFILE to know where the Gemfile is. The problem is that at this time BUNDLE_GEMFILE would be set to /var/local/apps/signal/Gemfile and because of this Bundler will load Signal‘s gems instead of Panther’s gems.

To resolve this, now when Signal executes a build script, it unsets some environment variables like BUNDLE_GEMFILE and RAILS_ENV, trying to simulate a “clean” environment.

If you know a better solution for this, please let me know.

Deploy your Rails 3 applications à la Heroku with Inploy

I’m not a fan of Heroku‘s deployment way, but I know that many people is and that many of them don’t know that with Inploy you can deploy your Rails 3 applications in a similar way.

Thomas Ritz contributed with Inploy creating a template called rails3_push. The template modifies Inploy so it creates a repository in the server on setup and pushes to it on every update, being followed by all the tasks that it executes by default on every deploy.

In order to use this template, like any other, you must specify it in the deploy.rb file:

template = :rails3_push
application = "tweerer"
hosts = %w(...)
...

After that, to setup your server and to deploy to it, you can execute respectively the following commands:

inploy setup
inploy

If you appreciate this work, please consider to recommend me at Working With Rails and to follow me on Twitter.

Test today your JavaScript code in a Rails 3 application with Blue Ridge

Case you want to test today your JavaScript code in a Rails 3 application in a simple way, Kristian Mandrup forked Blue Ridge and migrated the generators to the new interface. The commits haven’t been merged yet into the official repository and the code has some minor bugs, so I created another fork and fixed them.

Until all the commits got merged in both repositories, you can execute the following commands to get a configured environment:

git submodule add -b rails3 git://github.com/dcrec1/blue-ridge.git ./vendor/plugins/blue-ridge
rails g blue_ridge:skeleton
rails g blue_ridge:javascript_spec core
rake spec:javascripts

Case you don’t know Blue Ridge, Dr. Nic posted some time ago about the tool and he uploaded also a video from a presentation he gave at Rails Underground 2009.

If you appreciate this work, please consider to recommend me at Working With Rails.

Develop Rails 3 applications with your favorites gems without headaches

As today, starting developing a Rails 3 application using the default libraries is very easy, but when we want to use those tools that were great in Rails 2, some problems begin to appear.

These problems aren’t caused in any way due that Rails or the libraries are unstable. What happens is that a lot of plugins and gems had to update their integration with the framework and some chose to create pre-release versions, others to create branches and others just to bump to a new version, which means we have to hunt which version to use and from where in order to get compatible features.

To simplify the work of many people and to encourage the adoption of Rails 3, I decided to create a template that configures the gems I most use in my projects and installs them in the application, along with other tasks that can be easily followed in the script.

If you appreciate this work, please consider to recommend me at Working With Rails.

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:

@billing
Feature: Verify billing
 
  @important
  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:

@Resource
public class ShoppingCartController {
    ...
}
 
public class ProductsController {
    @Post
    @Path("/products")
    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;
 
  protected
  def eat; end;
  def flirt; end;
 
  private
  def sleep; end;
  def dream; end;
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
  deprecate
  def explode; end
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?
        end
      STRING
      @_proxy_method = false
    end
  end
 
  def admin_only
    @_admin_only = true
  end
end
 
class User
  def admin?
    [true, false][rand(2)]
  end
 
  admin_only
 
  def update_password
    puts "password updated"
  end
 
  def restart_server
    puts "server restarted"
  end
end

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:

Kilt

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:

curl -u USERNAME:PASSWORD -X GET https://www.pivotaltracker.com/services/v3/tokens/active

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:

kilt-app

Full text search in JRuby with ActiveLucene

ActiveLucene is a Lucene interface similar to the one used by ActiveRecord and ActiveModel.

This means that you can generate a scaffold in a Rails application, go to the model, replace ActiveRecord::Base with ActiveLucene::Document and everything should be still working with the difference that the model should be being saved in a Lucene index rather than in a relational database.

As the documents are now being saved in a Lucene index, we can find them using the Lucene query syntax, without forgetting that as ActiveLucene has a similar interface to ActiveRecord, we can also find them by an id, find the first, find the last, etc.

The base class of ActiveLucene is called Document because as the documents of another systems, it doesn’t have a defined structure and all the attributes are dynamic, so you do not have to worry about them.

ActiveLucene was extracted from Lunr, a not-enterprise search server from which I will speak in a future post, but as today, it can also be used in applications where having a relational database doesn’t make much sense and especially in the ones where you want to search documents by text.

The restriction of ActiveLucene is that it only works with JRuby, since Lucene is a Java library that runs on the JVM. Case this isn’t a problem, using ActiveLucene should be much simpler and lighter than using a solution such as Sphinx or Solr, depending of the case this may result in great benefits.

Lucene has a lot of features and ActiveLucene doesn’t support them all, but they will be added to the project as needed. As today, there is support for highlighting and a little for paging, as can be seen in the following video, along with a basic demonstration of the tool:

Full text search in JRuby with ActiveLucene from Diego Carrion on Vimeo.

If you appreciate this work, please consider to recommend me at Working With Rails.