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.

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.

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.

Cool tests in the Java Maven platform now possible with rspec-maven-plugin

I don’t like Maven at all but sometimes depending of the project and the people you need to use this. After playing with RSpec I stop considering any Java language framework acceptable for testing so for this project I’m working on right now I needed to find a solution that could integrate RSpec with Maven.

After googling I found this post from Bob McWhirter where he presented a official rspec-maven-plugin. I tried to use it but it wasn’t working so I forked it, fixed it and changed some things.

The forked version of rspec-maven-plugin is at GitHub and to use it you should:

install the plugin in the local repository (this is necessary only one time):

git clone git://github.com/dcrec1/rspec-maven-plugin.git
cd rspec-maven-plugin
mvn install

configure your project’s pom.xml adding this:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>rspec-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>spec</goal>
            </goals>
        </execution>
    </executions>
</plugin>

set the JRUBY_HOME system variable, for example:

export JRUBY_HOME=/opt/jruby-1.1.6/

The plugin will run in the test phase of the Maven build cycle.

Happy testing!