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.

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.

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.

ThinkingSphinx exits, enters ActsAsSolrReloaded

I used to work with ThinkingSphinx until the day I needed to index documents with dynamic attributes. As Sphinx indexes data from the result of an SQL query, the goal didn’t seem possible.

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.

Summary of new features in Inploy

After announcing Inploy 2 months ago, several people colaborated with it and now it has more features, the ones I will expose in this post.

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.

Really easy continuous integration with Signal

Signal is a continuous integration server written in Rails which I think takes the best features of similar systems and merges them in a very simple to use application.

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.

Rails deployment made easy with Inploy

After working in some systems made in Rails, Capistrano became one of the things that began to bother me more and more. I tried to find other alternatives, including Vlad, but none satisfied me, so I decided to create a solution and called it Inploy.

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.

Remarkable plugins for ActsAsTaggableOn, Paperclip and ThinkingSphinx

I created this three Remarkable plugins so they could help me in a project I’m working on:

Basically they let you write code like this:

describe User do
  should_act_as_taggable_on :categories
 
  should_have_attached_file :logo
 
  should_index 'addresses.city', :as => :address
  should_have_index_attribute :priority
end

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