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.

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.

@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.

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:

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

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.

I decided then to take another look at Solr. Solr, differently from Sphinx, is an HTTP server and indexes data from posted XML documents. Each document can have a different structure, so it fits perfectly with the model of dynamic attributes.

Thiago Jackwin, aka RailsFreaks, created a plugin that integrates Rails with Solr called acts_as_solr. The plugin is very good, but Thiago disappeared from the map some time ago, he lost the domain, left GitHub and doesn’t answer emails any more. As a result of this, different forks and forks of forks have been created and the Git tree became a mess.

Annoyed with the situation of the project, I decided to fork the fork I liked the most and created a new repository called acts_as_solr_reloaded, with new features. This way, I hope the project gets easier to be found and that it gives more trust. I’m also compromising myself to keep the repository up to date and to pull contributions.

As today, the new features acts_as_solr_reloaded comes with are:

• support for dynamic attributes
• geo-localization or geo-spatial search
• integration with acts-as-taggable-on
• highlighting
• relevance ranking

To support geo-localization in Solr, it needed to be updated to the version 1.4 .

To make easier the experience of working with dynamic attributes and geo-localization, a few generators that setup the database were added to the project. You can use them like this:

script/generate dynamic_attributes_migration
script/generate local_migration

You can after define your model this way:

class Document < ActiveRecord::Base
  acts_as_solr :dynamic_attributes => true,
               :spatial => true,
               :taggable => true
end

Note that with :taggable => true you dont need to define your model as acts_as_taggable_on :tags, it’s done automatically.

To better demonstrate the new features in acts_as_solr_reloaded, I recorded a small video of five minutes showing the functionalities in action, hope you like it:

New features in ActsAsSolrReloaded from Diego Carrion on Vimeo.

Note that in the video I used acts_as_taggable_on :tags and :taggable => true, at the time of the recording this both declarations were necessary, not anymore.

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

First of all, I want to thank these people for the contributions:

Andy Shen
Carlos Brando
Douglas Campos
Erik Dahlstrand
Joris Troost
Josh Owens

If you upgrade Inploy today and do nothing else, the two features you will automatically earn out of the box are:

control of submodules

This functionality initializes/updates the Git submodules on each deploy, so that the code is always updated without the possibility of forgetting.

Hoptoad notification

For those who use Hoptoad, Inploy will notify the tool on every code update, sending the environment and the revision code.

Besides the new features mentioned, Inploy now also has the following optional settings, which can be specified in the deploy.rb file:

sudo

Case you want to run the commands in the server as sudo.

server (Unicorn support)

Inploy works now with Unicorn, too, being Passenger the default server.

environment

Inploy works with production environment as default, but now we can use another one, like staging.

branch

Such times we have a branch with the configurations of our deploy and we want to use it, we can do it with the branch option.

ssh_opts

If you want to connect to the server using some ssh parameter, we can specified it in this option.

Here’s an example of how to use the options mentioned:

if ENV['environment'].eql? 'staging'
  deploy.ssh_opts = '-A'
  deploy.server = :unicorn
  deploy.environment = :staging
else
  deploy.branch = :deploy
  deploy.sudo = true
end

Please consider to recommend me at Working With Rails.

I found the functionality very interesting and today, in order to integrate Signal with CCMenu (OS X) or CCTray (Windows), you just need to point to the URL http://host/projects/status.xml and select the desired project.

I recorded a short video (01:13 minutes) demonstrating how to configure the tool and how it works, hope you like it:

If you liked Signal, please consider to recommend at Working With Rails.

E99DUHF5W855

When I started working with Rails, the first continuous integration server I tried was CruiseControl.rb. The CC.rb was also written in Rails and what bothers me the most about it is that to add a project you have to connect to the server and execute:

./cruise add [project-name] -r [repository] -s [svn|git|hg|bzr]

After running the previous command you can open a YAML file and configure the recipient of the emails that are sent by the application when the build breaks. In the scaffolding land, this makes no sense to me. It’s much more simpler to have a page where any user can register a project without much difficulty, like Hudson, Integrity and Signal does.

Another thing that bothers me about CC.rb is that it creates a lot of cruise processes and sometimes they hang. For a while I thought the problem was only happening with me but after talking with some people I found it wasn’t so uncommon.

The third thing I’ll complain about CC.rb is that at the home page it shows the last five builds of each project. IMHO the last two builds is already too much information. To know that the old builds were broken or not doesn’t mean anything to me. The only thing I care about is to know if the project is in a good state or not, information that Integrity and Signal display very well.

Integrity does a lot of things in a cool way, but I don’t like the fact that to install it you have to download the gem and then execute a command. The worst thing is that depending of the server you want to use, the command takes different parameters. Before explaining why this installation method is a problem, let me confess that another thing I don’t like about Integrity is that it doesn’t come with email support. Besides this lack of support be ugly, to include it you have to download another gem and modify a file. It looks simple but didn’t work for me, apparently because the version of the plugin gem was not compatible with the version of the application gem. Now, how do you change the version of an application that was installed by executing a command from a gem? Would it only require to download the second version of the gem and delete the first? Would it require to reinstall the application? I don’t know, maybe I did something stupid but nothing worked for me and this is why I believe that this way of dealing with applications is a problem.

Signal tries to take advantage of Git. To install Signal you can run:

git clone git://github.com/dcrec1/signal.git
cd signal
rake inploy:local:setup

If you ever want to go back to an specific version you just can git reset –hard COMMIT; simple, and it can take advantage of history by knowing where we are and what we are undoing.

One characteristic CC.rb has and I miss in Integrity is to show the date of each build on the home page. Signal shows how long ago each project was built, so we can easily know when was the last build and if they are being created.

report_card is a project that integrates metric_fu with Integrity, but it’s necessary to install another application and run a few commands, what is very complicated to me. It’s for this reason I decided that Signal has native integration with metric_fu, RSpec and Cucumber.

Signal’s integration with RSpec, Cucumber and metric_fu is very simple. In each project page there are three links: specs, features, and metrics, which point to ROOT/docs/specs.html, ROOT/docs/features.html and ROOT/tmp/metric_fu/output/index.html, metric_fu’s default path. This means that if we are generating HTML specifications, they can be accessed from the project page.

Another integration that Signal has is with Inploy. If we want to deploy an application, we can do it from the project page by clicking on deploy, the rake task inploy:remote:update will be executed.

Hudson is an very good integration server, but I think Signal overcomes it by being a little more simpler to use and by being developed in Rails and being hosted on GitHub.

Being developed in Rails is an advantage because this type of projects usually have several plugins and Rails has native support to plugins. Almost every railer knows how to install a plugin and how do they work, so it will not be a problem to create them.

Being on GitHub is an advantage because it facilitates further collaboration with the project. As today, Signal has a lot of conventions, but if for some reason anyone need some special configuration, he can fork the project and start contributing. Since Signal was developed with Rails and it’s pretty simple, people will not have difficulties to understand how it works.

One of the conventions of Signal is that each build is created by running the rake task build, which depending of the project I have something like this:

task: build => ['db:migrate', :spec, :cucumber, 'metrics:all']

I recorded a short video of nearly three minutes demonstrating how easy it is to install and use Signal. In the video I download the application and install it using Inploy. Then I register a new project and create a new build. The build is not automatically created along with the project because sometimes we need to perform some actions before running it. Just for demonstration purposes, I chose a project in Ruby that has a very fast build, given it does not run the Cucumber features neither the metrics. After the first build, I do start delayed_job and create a build from the command line, like being in a Git hook. The video ends with me showing a build of the project Signal and how easily it is to view the specs, the stories and metrics from the project page.

Really easy integration with continuous Signal from Diego Carrion on Vimeo.

If you liked Signal, please consider to recommend at Working With Rails.

Before Capistrano fans crucify me, I wanted to let it clear that I don’t think Capistrano is a bad tool, just that it’s bad for my needs, which are much simpler than Capistrano can attend.

One of the things I don’t like about Capistrano is that it creates a lot of folders, one for each release. Some people argued with me that they are useful when you want to rollback a release, but that never happened to me, as never happened with most of the people I talked with. The rest of the people told me that in some circumstance they had to rollback a deploy, but the circumstance was that the deployed code broke the build.

Inploy uses Git, so in case we need to rollback our deploy to a version, we can use git reset. Of course this solution is more limited that the one that Capistrano uses, but it’s a solution to a problem that probably should never occur, a problem caused probably by bad practices in the development.

As a consequence of Capistrano strategies, they deploys are a little slow for my taste. I know there are some configurations that can speed up the process, but to configure is a thing I don’t want to do. I want to use a tool that works the best way by default and in most cases, the best way to a fast deploy is the simplest one: git clone in the setup and git pull in the update, the same that Inploy does.

Speaking about defaults, it’s very annoying to me having to define in Capistrano how to restart the server, how to clean the cache and what tasks it should rake, like more:parse and asset:packager:build_all. Inploy tries to solve this problems by executing common tasks by default, being smart enough to identify what tasks it should rake and in which order. The idea behind the plugin is that you shouldn’t worry about how to deploy that new tool you’re using, that things just work without the possibility of something going wrong.

Another advantage from Inploy over Capistrano for most cases is that it just have one way to deploy and its called update. This task updates the code, migrates the database, does some other tasks and restarts the server. It makes not sense to me to update the code without running migrations. In all teams I worked with, everyone could deploy the application and in most cases someone executed cap deploy instead of cap deploy:migrations. I know this is a human error but I prefer to use a tool that doesn’t let people make mistakes.

A need I had with deployment tools is that it could work both remotely and locally. I worked in a project that was delivered to a foreign client and the people responsible of updating the application in each release couldn’t do it otherwise that by connecting to a server and running a script. All of them used Windows and were used to work with Java systems that required them to access a machine, replace a war file and execute some commands. In that opportunity, the solution was to create a deploy.sh file in the root folder on the application. This file was executed by somebody from the client every time they needed to update the application.

The problem mentioned above doesn’t happen with Inploy, as it can be run both remotely or locally. When running remotely, the only only thing it does is to connect to a list of servers and run the tasks like being locally logged. It’s because of this that Inploy is delivered as a plugin, so it’s available in all environments.

As today, Inploy will only work for you if you’re working with Git and Passenger.

To install Inploy you can execute:

script/plugin install git://github.com/dcrec1/inploy.git

On installation, Inploy will write to a file in config/deploy.rb. This file is read by the plugin and it should be something like this:

deploy.application = "inploy"
deploy.repository = 'git://github.com/dcrec1/inploy.git'
deploy.user = 'dcrec1'
deploy.hosts = ['hooters', 'geni']
deploy.path = '/var/local/apps'

After that, we’re ready to execute the tasks that the plugin has:

rake inploy:local:setup
rake inploy:local:update
rake inploy:remote:setup
rake inploy:remote:update

I created a short video in which I demonstrate how to use the different tasks of the plugin. In the video I’m inside the Signal project, which already has Inploy installed and I remove it along with the configuration file to demonstrate how easily it is to install and configure it. After that I execute a remote setup and then a remote update. We can see in the video that the commands that Inploy runs are logged with the corresponding outputs and that config/*.sample files are renamed to config/*, another feature of Inploy. In the second part of the video a local update is ran and then deleted the repository, cloned and executed another setup, this time locally.

Deploy easily to Locaweb with Inploy from Diego Carrion on Vimeo.

More details about the plugin can be obtained in the official Inploy repository, where I’ll try to keep the README up-to-date. I hope it’s clear the way that Inploy works, but just in case, looking at the code is an option to eliminate doubts. The code is quite small (50 LoC moreless) and also self explanatory. Follows an snippet:

def local_setup
  copy_sample_files
  create_folders 'tmp/pids', 'db'
  run "./init.sh" if File.exists?("init.sh")
  after_update_code
end
 
def remote_update
  remote_run "cd #{application_path} && rake inploy:local:update"
end
 
def local_update
  run "git pull origin master"
  after_update_code
end
 
def after_update_code
  install_gems
  migrate_database
  run "rm -R -f public/cache"
  rake_if_included "more:parse"
  rake_if_included "asset:packager:build_all"
  run "touch tmp/restart.txt"
end

I wish this simple code motivates people to contribute with the project and make it smarter.

If this plugins helps you, please consider to recommend me at Working With Rails.