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.

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.

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.

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.