The gem is called wirble. It has some nice defaults and allows you to configure the colors as you wish. To use it in your consoles, just add this lines to your ~/.irbrc file:

begin
  require 'rubygems'
  require 'wirble'
  Wirble.init
  Wirble.colorize
rescue LoadError => err
  warn "Couldn't load Wirble: #{err}"
end

Of course, you’ll need to install the gem. Just issue a gem install wirble and you’ll be good to go!

I Googled a bit and essentially I found out that the problem was with the Java GUI Toolkit rather than RubyMine, because the framework relies on a list of window managers to handle some things, and xmonad is not in that list.

So since I was not using OpenJDK, I opted for the setWMName option and added this final line into my xmonad.hs file:

    xmonad $ defaultConfig
      { terminal            = myTerminal
      , workspaces          = myWorkspaces
      , keys                = keys'
      , modMask             = modMask'
      , layoutHook          = layoutHook'
      , manageHook          = manageHook'
      , logHook             = myLogHook dzenLeftBar >> fadeInactiveLogHook 0xdddddddd
      , normalBorderColor   = colorNormalBorder
      , focusedBorderColor  = colorFocusedBorder
      , borderWidth         = 2
      , startupHook         = setWMName "LG3D"
}

Setting the window manager name to LG3D will trick the Java GUI Toolkit and the application will be painted correctly.

Enjoy your Java applications with the power of xmonad!

However, when you need some interaction between those shared models and the models of your specific application, like a has_many, :through association, some problems arise. The typical Many To Many association uses an intermediate database table that links the relation between two models, and allows you to add some extra information on that relation. When navigating through the association, Rails tries to make an SQL query that joins the model with this intermediate table. For example, imagine you have a Team model, which has many Players, but a player can also be on more than one team. We use an intermediate model TeamPlayers (and we can also use it to save the role of that player into that team, for example). You would have those three tables:

• teams
• players
• teams_players

When asking for the players of a given Team, Rails would do something similar to this:

SELECT "players".* FROM "players" INNER JOIN teams_players" ON "players".id = "teams_players".player_id WHERE "players".team_id = 1

Where 1 is the id of the team you asked for. This [obviously] works perfectly fine when everything is in the same database, and it’s as efficient as the SQL database manager you’re using. What happens, however, when we have the Player model in another database? It will miserably fail because Rails will try to join with a table that doesn’t exist.

Unfortunately, there’s no efficient way to solve this problem, that is, using SQL, as you can’t work with tables from different databases. However, there’s a rather elegant solution that Brian Doll cared to implement as a gem a while ago. As indicated in the GitHub readme, you just have to use a has_many_elsewhere relation instead of the usual one, and make sure that the model referenced has the connection established to the shared database. And that’s all.

The magic donde behind the scenes is pretty simple: this gem just replicates the same methods that the ActiveRecord::Base class does in the has_many method call, changing the failing unique SQL calls to double SQL calls, one for each database, fetching the intermediate models first, and then fetching the remote models using those ids.

This method is not perfect, as probably not all the goodness of the original association can be done with it, but for simple scenarios is more than enough.

Sometimes can be useful to create different managers. An example of this situation is when you want to run different kind of jobs in different circumstances.

Ubiquo Jobs provides a default manager which will get ActiveJob jobs depending on priorities and schedule times:

def self.get(runner)
  recovery(runner)
  candidate_jobs = job_class.all(
    :conditions => [
      'planified_at <= ? AND state = ?',
      Time.now.utc,
      UbiquoJobs::Jobs::Base::STATES[:waiting]
    ],
    :order => 'priority asc'
  )
  job = first_without_dependencies(candidate_jobs)
  job.update_attributes({
      :state => UbiquoJobs::Jobs::Base::STATES[:instantiated],
      :runner => runner
    }) if job
  job
end

The job_class variable defaults to UbiquoJobs::Jobs::ActiveJob. If you want to make your own manager to handle special jobs, or change the way the jobs are picked, the best way to do so is to implement your own manager. A nice rails-like way to do that is include them in the lib/ folder of your ubiquo project.
The class you should inherit from is UbiquoJobs::Managers::ActiveManager. If you wanted the manager to just pick up a specific subclass of ubiquo jobs, it would suffice to reimplement the self.job_class class method to return your own kind of job:

def self.job_class
  UbiquoJobs::Jobs::YourJobClass
end

However, there’s a better way to do this. For this special case, the default UbiquoJob class provides a special member which stores the job’s class name, allowing you to select all objects subclasses of ActiveJob by its classname. For example, imagine you have a kind of job for special tasks that you know for sure will take a long time to complete. Seems reasonable to have a different manager to handle those jobs. You would create a new job in the file app/jobs/very_long_job.rb:

class VeryLongJob < UbiquoJobs::Jobs::ActiveJob
  def do_job_work
    #Do what needs to be done here
    return 0
  end
end

Then you could create a manager that handles only those kind of jobs by implementing your own subclass of the UbiquoJobs::Managers::ActiveManager class:

module JobManagers
  class VeryLongJobManager < UbiquoJobs::Managers::ActiveManager
    def self.get(runner)
      recovery(runner)
      candidate_jobs = job_class.all(
        :conditions => [
          'planified_at <= ? AND state = ? AND type = ?', 
          Time.now.utc,
          UbiquoJobs::Jobs::Base::STATES[:waiting],
          'VeryLongJob'
        ],
        :order => 'priority asc'
      )
      job = first_without_dependencies(candidate_jobs)
      job.update_attributes({
          :state => UbiquoJobs::Jobs::Base::STATES[:instantiated],
          :runner => runner
        }) if job
      job
    end
  end
end

The code is exactly the same as the default ActiveManager class, but the finder will take an extra parameter, 'VeryLongJob', to indicate that only the ActiveJob objects that are of the subclass VerylongJob should be taken.

After that, you need to modify the task that calls the workers so it takes your manager, or create a new task that will run your manager. The default task that will
start a worker looks as this:

desc "Starts a new ubiquo worker"
task :start, [:name, :interval] => [:environment] do |t, args|
  options = {
    :sleep_time => args.interval.to_f
  }.delete_if { |k,v| v.blank? }
  UbiquoWorker.init(args.name, options)
end

This uses a special configuration parameter to determine the manager to use. This configuration option is stored in Ubiquo::Config.context(:ubiquo_jobs), the name of the configuration option is :job_manager_class, and takes the manager class as a value. So in order to create a task that will use your manager, you should create a new task like this one:

desc "Starts a new ubiquo worker"
task :start_very_long_jobs, [:name, :interval] => [:environment] do |t, args|
  options = {
    :sleep_time => args.interval.to_f
  }.delete_if { |k,v| v.blank? }
  Ubiquo::Config.context(:ubiquo_jobs).set(:job_manager_class, JobManagers::VeryLongJobManager)
  UbiquoWorker.init(args.name, options)
end

Your should call this task like this (assuming it’s on the same namespace as the default task):


rake ubiquo:worker:start_very_long_jobs[name,interval]


One of those useful methods I discovered the other day was each_slice. This method allows you to iterate over the collection, just as each does, but lets you do it changing how many elements of the collection you get on each iteration. This is the example you can get from the documentation page:

(1..10).each_slice(3) {|a| p a}
# outputs below
[1, 2, 3]
[4, 5, 6]
[7, 8, 9]
[10]

You can see that from the original array from 1 to 10, on every iteration Ruby prints the numbers in groups of three, and the last one alone since the collection is not a multiple of 3. Now think about having to do this manually: it’s not that hard, but its error prone and you have to do all that typical arithmetic logic that should be easy but never is. How handy that Ruby has already done that job for you.

This method is also pretty useful when working in Ruby on Rails. One simple example is when you have to manually implement some kind of pagination, or show a list of elements in columns or rows of fixed size: you have to simply iterate with each_slice and put the page/row/column logic on the block, and voilà.

I strongly suggest you take a look at the Enumerable module reference to take a look at all the other flavours of each methods it has and I’m sure you’ll find all of them pretty useful in lots of situations!

sample is a class method from the Array class that retrieves one or more random items from an array instance. It conveniently returns nil or an array lesser than the items requested if the original array has not enough items.

Since all ActiveRecord finds return an array, you can easily add the sample call at the end of a find call to get the random items you need from complex queries.

For example, imagine you have a Book model which has a published_at datetime attribute and you want to show, in your library home page, a random selection of 5 books that have been published. You can easily get those using this snippet:

def get_random_books_for_home_page
  find(:all).sample(5)
end

class User < ActiveRecord::Base
    serialize :preferences, Hash
  end

This way you can set and get the preferences attribute of the user without having to worry much about it:

User.first.preferences # => {:show_email => true, :allow_pm => :false, ...}
user = User.first
user.preferences = {:show_email => true, :allow_pm => :false}
user.save

In order to do that, at the database table for the User class, among the other fields you’ll need to add a text column for the preferences. After that, you can easily work with your model without too much of a hassle.

If you care to look at the rows of the model’s table, you’ll see that the serialized attribute is stored in YAML format:

sqlite> select preferences from users where id = 1;
--- 
:show_email: false
:allow_pm: false

Now, that if you need to add a fixture for your model that needs the preferences attribute to be set to a particular value? If you have to manually parse the value you want to put in there to be tested, it’ll be a pain in the ass. Even if you have a script that converts certain values to YAML so you can copy and paste the script output to the fixture, it’s not very comfortable. Hopefully, you have to remember that you can use some ERB magic in your fixtures So, here’s the deal if you need to add something to the serializable attribute:

one:
  preferences: <%= {:show_email => true, :allow_pm => :false}.to_yaml.inspect  %>

The to_yaml method converts the Hash into a YAML representation, and with inspect we convert that to a string. Using this technique, we can add whatever we want to a serialized field in our fixtures.

The tools I needed I got from those two websites: http://rubyrss.com/ for a RSS parser, and http://blogs.sitepoint.com/2006/10/05/json-p-output-with-rails/ on how to build a simple JSONP response on the server side.

Basically you have to start creating a new controller that will handle the JSONP requests. In my case I just added a ‘Feed’ controller:

$ script/generate controller Feed

Then you edit the app/controllers/feed_controller.rb file and start coding. We will assume that the request will come in this form: http://server/feed/get?callback=some_callback&url=the_url_of_the_feed. Having this information, the controller code is pretty straightforward.

class FeedController < ApplicationController
 
  require 'rss/1.0'
  require 'rss/2.0'
 
  def get
    begin
      url_contents = Net::HTTP.get(URI.parse(params[:url]))
      rss = RSS::Parser.parse(url_contents, false)
      json = { "error" => false, "feed" => rss }.to_json
    rescue
      json = { "error" => true }.to_json
    end
    respond_to do |format|
      format.js { render_json json }
    end
  end
 
  def render_json(json)
    callback = params[:callback]
    response = begin
      if callback
        "#{callback}(#{json});"
      else
        json
      end
    end
    render({:content_type => :js, :text => response})
  end
end

The first two lines are the requirements for the RSS module, which will allow us to parse a RSS feed. After that, we start with the get request. In there, we use the Net::HTTP.get() method, which will retrieve a URL content using a GET request and return its contents. To do so, we need to pass it an uri parameter, which we can get from the entire URL using the method URI.parse(). After this call, we have the XML of the RSS feed in url_contents. What we have to do now is build an RSS object with this XML. We’ll do that by calling RSS::Parser.parse(). If you wish to do some modifications to the RSS contents, now is your change. In this simple example we’ll simply bulk it all to the response.

To build the response, we need a JSON object. If everything went as expected, we can create a JSON object by simply creating a ruby associative array and calling the to_json method on it:

json = { "error" => false, "feed" => rss }.to_json

If, on the contrary, we got an error (bad URL, bad RSS, whatever), we simply return the same JSON object with the error property set to true (that’s done in the rescue clause).

After we have this JSON object built, we simply have to output the results. To do so, we use the help of a method called render_json which we have added to the controller code. In this method we simply output the JSON if we provide no callback (this means no JSONP), or either a padded JSON (hence the name JSONP) with the callback name followed by the JSON data. In either case we render the results as a js type.

For more detailed information on how JSONP works, check http://en.wikipedia.org/wiki/JSON#JSONP, but what you basically need to know is that when you do a JSONP request what you’re really doing is retrieve a chunk of javascript code that will be run on your client, so be aware of the security issues you can have here.

Imagine you are developing a rails application. Usually you have:

• a terminal with the server to see what petitions are received.
• a terminal with a tail of development.log to see what happens with the database.
• a terminal with a tail of test.log if you are testing something.

This are a lot of windows… And the other day one friends was very happy and after asking for a while I discovered that the reason was the simple line showed above… With only one Ctrl+C you can kill all this processes

script/server & tail -f log/development.log & tail -f log/test.log & tail -f ; jobs -p | awk '{print "kill -2 " $0}' | sh

While developing a Ruby on Rails application it’s good to use a system like Subversion. In this howto I’ll explain my experience subversioning my Rails app.

The first step is to create a subversion repository. Mine is created with a web interface in my hosting account, if you can control your subversion repositories and you don’t know how to create it the chapter Creating and Configuring your Repository from SVN book may be useful. My repository url is (for example) http://someaccount.somehosting/myapp.

For subversioning a rails app we need, of course, a rails app. We’ll create a dummy app for testing. After that we have to import this directory structure to our repository

jsegura@ibook:~/dev/rails $ rails demo
      create 
      create  app/controllers
      create  app/helpers
      create  app/models
      create  app/views/layouts
      create  config/environments
jsegura@ibook:~/dev/rails$ svn import demo http://someaccount.somehosting/demo -m "Rails import"

The next actions have to be done in a working copy, the directory demo is no longer necessary.

jsegura@ibook:~/dev/rails $ rm -rf demo
jsegura@ibook:~/dev/rails $

After obtaining the working copy we have to prepare our repository for developers usage. The steps are:

1. Removing temp files
2. Removing log files

To remove these files doesn’t mean “they are unnecessary”, only means “there is unnecessary for these files to stay in the repo” .

jsegura@ibook:~/dev/rails/demo$ svn remove log/<strong>
D         log/development.log
D         log/production.log
D         log/server.log
D         log/test.log
jsegura@ibook:~/dev/rails/demo$ svn propset svn:ignore "*.log" log/
property 'svn:ignore' set on 'log'
jsegura@ibook:~/dev/rails/demo svn
svn            svndumpfilter  svnserve       svnversion     
svnadmin       svnlook        svnsync       
jsegura@ibook:~/dev/rails/demo$ svn ci -m "Remove and ignore log files"
Sending        demo/log
Deleting       demo/log/development.log
Deleting       demo/log/production.log
Deleting       demo/log/server.log
Deleting       demo/log/test.log
 
Committed revision 3.

jsegura@ibook:~/dev/rails/demo$ svn remove tmp/</strong>
D         tmp/cache
D         tmp/pids
D         tmp/sessions
D         tmp/sockets
jsegura@ibook:~/dev/rails/demo svn propset svn:ignore "*" tmp/
property 'svn:ignore' set on 'tmp'
jsegura@ibook:~/dev/rails/demo$ svn ci -m "Remove and ignore temp files"
Sending        demo/tmp
Deleting       demo/tmp/cache
Deleting       demo/tmp/pids
Deleting       demo/tmp/sessions
Deleting       demo/tmp/sockets
 
Committed revision 4.

To end up, the only final step is not subversion the config for accessing the database.

jsegura@ibook:~/dev/rails/demo$ svn propset svn:ignore "database.yml" config/
property 'svn:ignore' set on 'config'
 
jsegura@ibook:~/dev/rails/cdemo$ svn ci -m "Ignoring database.yml"
Sending        demo/config
 
Committed revision 5.
jsegura@ibook:~/dev/rails/demo$