If you’ve worked with any deployment related stuff before, you know that it hardly ever goes as planned. With few machines involved, few processes, file/folder permissions and process permissions, there is bound to be things that will take longer. God is no different. And no wonder you will find wiki/forum posts from folks who’ve been thru it. I had my share of those and in the end I am happy with the config I found.

Here is a journey as it went:

Goal-1: Monitor delayed_job using god:

# run with: god -c /path/to/file.god -D
RAILS_ROOT = "/home/sjain/projects/pfa/omt"
 
# Watch for delayed_job
God.watch do |w|
 
  w.name = "delayed_job"
  w.interval = 30.seconds # default
  w.dir = RAILS_ROOT
  w.start = File.join(RAILS_ROOT, "script/delayed_job start")
  w.stop = File.join(RAILS_ROOT, "script/delayed_job stop")
  w.restart = File.join(RAILS_ROOT, "script/delayed_job restart")
  w.start_grace = 10.seconds
  w.restart_grace = 10.seconds
  w.pid_file = File.join(RAILS_ROOT, "tmp/pids/delayed_job.pid")
  w.log = File.join(RAILS_ROOT, 'log/god.log')
 
  w.behavior(:clean_pid_file)
 
  w.start_if do |on|
    on.condition(:process_running) do |c|
      c.interval = 5.seconds
      c.running = false
    end
  end
 
  # lifecycle stuff goes here ...
end

This is fairly standard from God’s website. The only interesting thing here is I kept RAILS_ROOT as a string constant at the top since I know I will have to make it configurable as part of my capistrano deploy script. With this, I could run following command and have god monitor my delayed job:

$ god -c /var/www/html/application/current/config/app.conf
# Verify with 'god status'

Goal-2: Monitor apache using god:

# Watch for apache
God.watch do |w|
 
  watch_name = "app_server"
  w.name = watch_name
  w.interval = 30.seconds # default
  w.dir = RAILS_ROOT
  w.start = File.join(RAILS_ROOT, "/etc/init.d/httpd start")
  w.stop = File.join(RAILS_ROOT, "/etc/init.d/httpd stop")
  w.restart = File.join(RAILS_ROOT, "/etc/init.d/httpd restart")
  w.start_grace = 10.seconds
  w.restart_grace = 10.seconds
 
  w.start_if do |on|
    on.condition(:http_response_code) do |c|
      c.host = 'localhost'
      c.port = 3000
      c.path = '/'
      c.code_is_not = 200
      c.timeout = 10.seconds
      c.times = [2, 5]
    end
  end
end

This was a straight modification from the delayed_job config, which didn’t work for a few reasons:

1) Since I was starting god under my account, it couldn’t execute the start/stop commands specified in the watch file. For those to work, I had to start god script under sudo permissions.

$ sudo god -c /var/www/html/application/current/config/app.conf
# Once you start god as sudo, all other commands for god need sudo as well ... 'sudo god status'

2) The other issue with the above apache monitoring config was that once I start god as sudo, I still need my apache process to run under restricted user on the destination machine. Since we use CentOS for our production environment, this use is ‘www-data’. So, updated my god config with following:

# Watch for apache
God.watch do |w|
  ...
  w.uid = 'www-data'
  w.gid = 'www-data'
  ...
end

Also, now that I am starting god as sudo, all watches now need to specify uid/gid. So, I had to go back and update my delayed_job watch with uid/gid to be that of my ‘railsdeploy’ user. My rails app gets deployed under ‘railsdeploy’ user account and delayed_job process runs under this user as well.

# Watch for delayed_job
USER = "railsdeploy"
GROUP = "railsdeploy"
 
God.watch do |w|
  ...
  w.uid = USER
  w.gid = GROUP
  ...
end

Notice, how we are not hard-coding user/group directly. We know that eventually our capistrano script will need to replace those variables with configurable values. I kept all such things at the top of my .god file. There is a few more to come.

3) No, that was not all. The next problem I ran into was related to user environment. Since I am starting my god under sudo now, it was not guaranteed that my environment variables are still the same under that user. I found this the hard way (another 1/2 hr.) and in my case the default PATH under sudo was setup to give access to a different ruby version that the one we use for our production environment. So, I had to update both of my watches to have few necessary environment variables.

RAILS_ROOT = "/var/www/html/application/current"
RAILS_ENV = "sandbox"
RUBY_PATH = "/opt/ruby-enterprise/bin"
 
God.watch do |w|
  ...
  w.dir = RAILS_ROOT
  w.env = {
    'RAILS_ROOT' => RAILS_ROOT,
    'RAILS_ENV' => RAILS_ENV,
    'PATH' => "#{RUBY_PATH}:/usr/bin:/bin"	
  }
  ...
end

A few tricks to remember when working with god is where to look for clues in case something doesn’t work. I found following things useful.

Adding log-level of debug when firing up god:

$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf
# with this god prints information each time it does a check on your monitored processes. These are big help to validate your frequency of poll and tweak your retry limits etc.

If you didn’t specify the log file location for god in command line, they go to system messages. This can be /var/log/messages on CentOS or /var/log/Syslog on Ubuntu (I guess). You can also specify log file in command line:

$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf -l /var/log/god.log

Or, during your test setup, you can run god in non-daemon mode to have it print all messages in console.

# -D option for non-daemon mode
$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf -D

So, with this, I have 2 processes being monitored and each with different user/group setting. So far, so good.

Goal-3: Monitor passenger using god (failed):

Since we run apache+passenger combo in our environments, I wanted to see if I can restart passenger also if http-response didn’t work as part of apache watch. So I attempted this:

# adding passenger to apache monitoring
God.watch do |w|
  ...
  apache_init = "/etc/init.d/httpd"
  passenger_restart = "touch #{RAILS_ENV}/tmp/restart.txt"
  w.start = "#{apache_init} start; #{passenger_restart}"
  w.stop = "#{apache_init} stop; #{passenger_restart}"
  w.restart = "#{apache_init} restart; #{passenger_restart}"
  ...
end

So, what I trying to do here is run 2 commands as part of one watch. Apparently, this doesn’t work. I believe, this has more to do with how god hands over those commands to under lying system that anything else. I couldn’t figure this one and I am not aware of the best way to monitor passenger outside of apache to I left it at that. My guess if the http-response is not working and I restart apache, it should technically restart passenger as well and fix the issue.

Goal-4: Leverage capistrano to help with god configuration:

Since I don’t even run apache locally for development (I run mongrel), I had to test all these things on a sandbox machine. I leveraged capistrano to help me out with deploying these god config files after I modified them each time locally. Here is what capistrano tasks looked like:

 namespace :god do
   task :start, :roles => :app do
     god_config_file = "#{latest_release}/config/omt.god"
     sudo "god --log-level debug -c #{god_config_file}"
   end
   task :stop, :roles => :app do
    sudo "god terminate" rescue nil
  end
  task :restart, :roles => :app do
    god.stop
    god.start
   end
   task :status, :roles => :app do
    sudo "god status"
   end
   task :log, :roles => :app do
    sudo "tail -f /var/log/messages"
   end
  task :deploy_config, :roles => :app do
     god_config_file = "#{latest_release}/config/omt.god"
     god_script_template = File.dirname(__FILE__) + "/deploy/templates/omt.god.erb.rb"
     data = ERB.new(IO.read(god_script_template)).result(binding)
     sudo "god load #{god_config_file}"
   end
   task :redeploy, :roles => :app do
     god.deploy_config
     god.load_config
   end
 end

Most tasks are straight forward with managing god itself (start/stop/restart/log). The deploy_config tasks worked great with the following config file in order to generate proper .god config file on the destination machine:

# run with: god -c /path/to/file.god -D
RAILS_ROOT = "<%= latest_release %>"
RAILS_ENV = "<%= rails_env %>"
USER = "<%= user %>"
GROUP = "<%= group %>"
RUBY_PATH = "<%= ruby_home %>/bin"
GOD_ENVIRONMENT = {
  'RAILS_ROOT' => RAILS_ROOT,
  'RAILS_ENV' => RAILS_ENV,
  'PATH' => "#{RUBY_PATH}:/usr/bin:/bin"
}
 
God.watch do |w|
  ...
  w.dir = RAILS_ROOT
  w.env = GOD_ENVIRONMENT
  w.uid = USER
  w.gid = GROUP
  ...
end

As you can see above, the constants defined at the top of .god.erb.rb template file picked values for variables from the capistrano script and replace them in template to generate the actual .god config file. Now, I could use this file to generate script for each environment and have it generate this with each god deploy. The god script once configured doesn’t change often but I still like to regenerate it with each capistrano deploy just as I would generate apache vhost file using capistrano with each deploy. This is debatable but I just like it that way.

Goal-5: Configure god as init script

Any monitoring solution isn’t complete until it takes care of starting/stopping itself automatically. God has to be configured to start automatically on server reboot. Now, it was time to create init script for god itself. After a few trial errors I ended up with following init script template:

#!/bin/bash
#
# God
#
# chkconfig: - 99 1
# description: start, stop, restart God (bet you feel powerful)
#
 
# source function library
. /etc/rc.d/init.d/functions
 
RUBY_PATH="<%= ruby_home %>/bin"
PATH=$RUBY_PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=$RUBY_PATH/god
PIDFILE=/var/run/god.pid
LOGFILE=/var/log/god.log
SCRIPTNAME=/etc/init.d/god
CONFIGFILEDIR=/etc/god
 
#DEBUG_OPTIONS="--log-level debug"
DEBUG_OPTIONS=""
 
# Gracefully exit if 'god' gem is not available.
test -x $DAEMON || exit 0
 
RETVAL=0
 
god_start() {
  start_cmd="$DAEMON -l $LOGFILE -P $PIDFILE $DEBUG_OPTIONS"
  #stop_cmd="kill -QUIT `cat $PIDFILE`"
  echo $start_cmd
  $start_cmd || echo -en "god already running"
  RETVAL=$?
  if [ "$RETVAL" == '0' ]; then
    sleep 2 # wait for server to load before loading config files
    if [ -d $CONFIGFILEDIR ]; then
      for file in `ls -1 $CONFIGFILEDIR/*.god`; do
        echo "god: loading $file ..."
        $DAEMON load $file
      done
    fi
  fi
  return $RETVAL
}
 
god_stop() {
  stop_cmd="god terminate"
  echo $stop_cmd
  $stop_cmd || echo -en "god not running"
}
 
case "$1" in
  start)
    god_start
    RETVAL=$?
    ;;
  stop)
    god_stop
    RETVAL=$?
    ;;
  restart)
    god_stop
    god_start
    RETVAL=$?
    ;;
  status)
    $DAEMON status
    RETVAL=$?
    ;;
  *)
    echo "Usage: god {start|stop|restart|status}"
    exit 1
    ;;
esac
 
exit $RETVAL

A few things to note here. If you look carefully at the god_start() function, it starts the god process as daemon and then loads any *.god files in /etc/god/ folder. This has several benefits. When the server reboots, god doesn’t need to hunt around for config files in various places. And whatever application needs to be monitored can have one of their config files installed here for god to pickup. The capistrano deploy can now be updated to deploy a .god file in this folder and then call “god load app.god” to have it loaded during each deploy. The next time machine/god restarts, it will pick up monitoring of configured apps automatically.

The capistrano task could look like:

namespace :god do
  task :deploy_config, :roles => :app do
    # deploy omt.god file
    god_config_file = "#{latest_release}/config/omt.god"
    god_script_template = File.dirname(__FILE__) + "/deploy/templates/omt.god.erb.rb"
    data = ERB.new(IO.read(god_script_template)).result(binding)
    put data, god_config_file
    sudo "mkdir -p /etc/god", :pty => true
    sudo "ln -sf #{god_config_file} /etc/god/omt.god", :pty => true
    # load file into god service (assumes god is already running)
    god_config_file = "#{latest_release}/config/omt.god"
    sudo "god load #{god_config_file}"
  end
end

Since each deployed environment (sandbox, staging, production) can have ruby-home in different folder location. I couldn’t use static init script file. I leveraged capistrano to use a template file (with ERB engine) to replace variables on the fly. The capistrano task for this looks as follows:

Even deploying god init script file could be done using capistrano:

namespace :god do
  task :deploy_init_script, :roles => :app do
    # Note: god gem (version >= 0.11.0) must be installed as system gem for this to work
    god_init_template = File.dirname(__FILE__) + "/deploy/templates/god.init.template.sh"
    data = ERB.new(IO.read(god_init_template)).result(binding)
    put(data, "/tmp/god_init_script", :via => :scp, :mode => "755") # put command doesn't support sudo, so we can't directly copy to /etc/init.d folder
    sudo "mv /tmp/god_init_script /etc/init.d/god"
    sudo "/sbin/chkconfig --level 35 god on" # enable run levels 3 and 5
  end
end

As you can see above, we copy the init script in /etc/init.d/god folder and then run chkconfig command to have it restart automatically in unix run-levels 3 and 5. Now, assuming god is already setup on your server to run as init script. We can modify our capistrano task for god start/stop/restart/status commands to leverage unix’s standard “service” command.

# capistrano tasks: god:start, god:stop, god:restart, god:status
namespace :god do
  ["start", "stop", "restart", "status"].each do |cmd|
    task cmd.to_sym, :roles => :app do
      sudo "service god #{cmd}"
    end
  end
end

There is still a few more things I have to left to do. For example, monitoring mysql database server. Since my database in production resides on a different server than app server, this will require installing a different script on mysql server machine or somehow monitor remotely from one of the app servers…

As I mentioned previously, deployment tasks never go as planned. There are always hiccups. But it is fun to see it all working at the end of the day!

Related posts:

1. Defining custom roles/servers in capistrano Capistrano works seamlessly for standard deployment where your app is...
2. Upgrading Ubuntu: from 9.04 to 9.10 So, after ignoring the new upgrade in my update-manager for...
3. Setting up Sphinx Search on remote server If you are using sphinx gem for search functionality in...

Related posts brought to you by Yet Another Related Posts Plugin.

• It is stable now and will solve your gem dependency conflicts better than rubygems require.
• You will be better prepared to migrate to rails3 when you are ready.

Instructions for using bundler with rails 2.3 will get you off to a good start. We use shoulda and mocha for our test suite. If you do too, you may run into an issue that Yehuda rightly blogged about here.

To fix this, here is what you need to do:

In config/boot.rb, replace:

    def load_gems
        @bundler_loaded ||= Bundler.require :default, Rails.env
    end

with:

      def load_gems
        @bundler_loaded ||= begin
          result = Bundler.require(:default)
          Bundler.require(Rails.env) unless Rails.env.test?
          result
        end
      end

And in your config/environments/test.rb, add following at the end:

require "shoulda"
Bundler.require(:test)

As Yehuda explains, Mocha adds a few features depending on weather shoulda is loaded or not. The trick is to ensure that shoulda is loaded and is available before mocha is loaded.

Besides, if you are using mocha version 0.9.8, and have a ‘require “mocha”‘ line at the bottom of your test/test_helper.rb (as required by mocha/README), you can probably remove that here. Bundler takes care of it properly.

Again, don’t forget that non-rails commands must be executed with bundle exec:

$ bundle exec cucumber

Enjoy!

Related posts:

1. Monitoring rails processes (apache, passenger, delayed_job) using god and capistrano When it comes to monitoring servers and processes in...

Related posts brought to you by Yet Another Related Posts Plugin.

Ever wondered how to login as two different users at the same time? The situation manifests in any project where you want to be able to test a workflow involving several actors with different roles. The problem is that browsers allow only one login for a given domain at any one time. So, you are required to logout as current_user before logging in as another. One of the solution people use is install multiple browsers.

Solution: Multiple Browsers

So, lets say your favorite browser is firefox. And you also have IE7 installed by default on your windows machine. And you have a google chrome installed just so you can try out the new and blazing contribution by google. Most developers, I assume, more than a single browser installed on their system. Given this, you can login as different user in each browser.

This works but here is another solution that, as you will quickly realize, is better.

Solution: Multiple names for your “localhost”

Just update your /etc/hosts file to add more names for your local machine. Lets take a concrete example:

So, on a project, realted to mortgage industry, I have several actors like borrower, realtor, loan officer, mortgage-broker. I updated my /etc/hosts file (on linux) from this line:

127.0.0.1 localhost

to this:

127.0.0.1 localhost r lo mb b

With this above line, I can access my local application using following URLs:

http://r:3000 (for realtor)
http://lo:3000 (for loan officer)
http://b:3000 (for borrower)
http://mb:3000 (for mortage broker)

Now, I can open 4 tabs in a browser each with different URL and login as different users. Coupled this with password saving feature of browser, I don’t even have to type username/password for each user as long as I am disciplined about not cross-logging in as realtor inside borrower url (b:3000). Go ahead, leave yourself logged in and never logout!

This simple trick is better than multiple browser solution since it doesn’t require as many browser and you can have as many unique URLs as you want. And you are not limited to using this trick for local testing. If you have a staging server at http://staging.project.com that resolves to an IP, say, 192.1.2.3, you can repeat the same process:

# my /etc/hosts file
127.0.0.1 localhost r lo mb b
192.1.2.3 staging.project.com sr slo smb sb
# Now I can
# http://sr (staging realtor)
# http://slo (staging loan officer)
# you get the drill ...

There you go. Happy testing!

Related posts:

1. Rails Email Unit Testing ActionMailer classes, for sending out emails, typically reside with...
2. Disabling form post in google chrome and safari So, I found this issue with google chrome and...
3. Reverse Tunneling and mysql Recently, I needed my app in staging to use my...

Related posts brought to you by Yet Another Related Posts Plugin.

In my rails app, I had to do this to work around this.

We use haml rendering engine for our project and my form looks like this:

- remote_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form'} do |form|

This generates a form like this:

  <form onsubmit="jQuery.ajax({data:jQuery.param(jQuery(this).serializeArray()) + '&amp;authenticity_token=' + encodeURIComponent('MlHm/z3dsdYtETKwtNnwQlojx1NIduLlWFMECbjntsM='), dataType:'script', type:'post', url:'/product_searches'}); return false;"
  method="post" id="product_search_form"
  class="product_search"
  action="/product_searches">

I was working with an ajax form but I believe the bug happens even with traditional form POST as reported by another user here.

So, I had to create an onSubmit javascript myself to fix the situation:

- semantic_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form', |
  :onsubmit => "return jQuery.productSearchOnSubmit();"} do |form| |

(function($){
  $.productSearchOnSubmit = function() {
    if ($('#product_search_submit').attr('disabled')) {
    // do nothing
    } else {
      jQuery.ajax(
      {
        data: jQuery.param(jQuery('#product_search_form').serializeArray()) + '&authenticity_token=' +
        encodeURIComponent(form_authenticity_token),
        dataType:'script',
        type:'post',
        url:'/product_searches'
      });
    }
    return false;
  }
})(jQuery);

I also had to add global javascript variable for form_authenticity_token to make it available for javascript when performing submit.

%html{ :xmlns => "http://www.w3.org/1999/xhtml", :lang => "en", "xml:lang" => "en"}
  %head
    :javascript
      var form_authenticity_token = '#{form_authenticity_token}';

If you think, this is a bug too, please vote for a fix.

Related posts:

1. Writing your Greasemonkey userscripts in jQuery I’ve played with greasemonkey and like them in concept. They...
2. Login as multiple users simultaneously for testing Ever wondered how to login as two different users...

Related posts brought to you by Yet Another Related Posts Plugin.

ActionMailer classes, for sending out emails, typically reside with models, inside app/models folder. Yet, they have traits that are similar to controllers. For example, each actionmailer class has a view folder inside app/views where email templates are defined. And testing support for email is provided as functional tests with assert_select macros such as assert_select_email.

In my current project, most of our email hooks are defined on model classes as after_filter. This is in line with recommendation to keep controllers thin and models fat. However, testing email body’s html format is a pain since assert_select_email support is only available in ActionController::TestCase hierarchy, and not in ActionMailer::TestCase hierarchy.

Consider following ActionMailer test:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  should "invite borrowers" do
    realtor, borrower = User.make, User.make
    response = MortgageBorrowerEmailer.deliver_invite_borrowers(realtor, borrower)
    # test from/to/subject works now :-)
    assert_same_elements([borrower.email], response.to)
    assert_equal([realtor.email], response.from)
    assert_equal("#{realtor.full_name} has invited you to manage your mortgage application in Lendable", response.subject)
    # testing body is still primitive :-(
    assert response.body.include?(realtor.full_name)
    assert response.body.include?("/account_preferences/#{borrower.perishable_token}/edit")
  end
end

ActionMailer::TestCase has decent support for intercepting mail delivery and hold onto mails for introspection. This allows us to assert smaller pieces like from, to, subject etc. However, what it doesn’t support is more fine grained assertion on email’s html body. it would be nice to be able to apply assert_select assertion on email’s response body for critical pieces of information that needs to be present in an email.

So, I dug into ActionController::TestCase’s assert_select_email to see how I can duplicate it for my unit test. Here is what the original method looks like:

# [rails]/actionpack/lib/action_controller/assertions/selector_assertions.rb
module ActionController::Assertions::SelectorAssertions
  def assert_select_email(&block)
    deliveries = ActionMailer::Base.deliveries
    assert !deliveries.empty?, "No e-mail in delivery list"
    for delivery in deliveries
      for part in delivery.parts
        if part["Content-Type"].to_s =~ /^text\/html\W/
          root = HTML::Document.new(part.body).root
          assert_select root, ":root", &block
        end
      end
    end
  end
end

As this implementation depicts, it is interesting to see how easy it is to take any html code snipped and create an HTML::Document out of it so that assert_select can be applied to it. Anyway, the default implementation for assert_select_email assumed multipart email with one or more parts in it. Since my email are simplistic text/html rendered as email body, I hacked to get what I needed. As follows:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  include ActionController::Assertions::SelectorAssertions
  def assert_select_with_string(html_text, &block)
    root = HTML::Document.new(html_text).root
    assert_select root, ":root", &block
  end
end

With this in place, I could now take my email response’s body and assert-select on it:

    should "share mortgage with existing client" do
      ...
      assert_select_with_string(response.body) do
        assert_select "h1", :text => "Greetings from Lendable"
        assert_select "tr#sender_identity td strong", :text => @realtor.full_name
        assert_select "tr#rate_search_criteria" do
          assert_select ".purchase_price"
          assert_select ".loan_amount"
        end
        assert_select "tr#rate_info td a[href=?]", "http://#{DEFAULT_HOST}/rate_selections/#{@rate_selection.id}",
          :text => "#{@rate.program.type_and_term} Mortgage at #{number_with_precision(@rate.rate, :precision => 3)}% from #{@rate.program.lender.name}"
      end
    end

As we can imagine, this assert_select_with_string() can be useful in testing helper methods that return html snippets. I am not sure what the downside is for testing email body format as unit test vs. funcational test but I am happy that I can test it in isolation as unit test.

Do you know of any?

Related posts:

1. Login as multiple users simultaneously for testing Ever wondered how to login as two different users...
2. Ruby Authlogic: lazy initialization based on defined?() call What is the difference between following two versions of code?...
3. Environment specific routing in rails For better application support, it is usually nice to build...

Related posts brought to you by Yet Another Related Posts Plugin.

I was at a recent social gathering where we started talking about how funny and bizzare it is that people use twitter to post messages like .. sh**, woke up late .. having lunch at Gino’s East … driving to work … my dog peed on my bed … . .. Oh ok, that last one is probably out of thin air but posting those kinds of messages probably don’t add much value for anybody, the author or the readers.

To test the waters, I created an account about 6 months ago. Very quickly I realized that twitter fills in a void that none of the other communication tools do.

Keep in touch, I mean real touch:
We don’t make it a point to write email to every single one on our list of 200 or 500 contacts every once in a while. Why? Because you will have to walk down the list, write to each person individually. We would have to come up with something to talk about that this person might be interested in. Too much work. But we still want to peek into their life and vice versa to find out if there is anything that interests both of us. Twitter fits the bill. You tweet (by definition, short) about anything that touches your life. If the other person is interested in you, he/she will follow you and vaguely peruse over your tweets. You do the same and follow him. Even if you no longer meet each other (because one of you has moved to different city or different job), you can talk to each other over this channel. If everybody in my group did this, I’d be fully aware of what happens with them on a day by day, hour by hour basis without actually calling them up. And vice versa.

Another great advantage that isn’t apparent at first is that twitter allows me to follow person who I am not associated with directly but what he does has a large impact on my life. Since I am programming in Ruby these days, I want to know what ruby gurus (@dhh, @wycats) are upto each day. If you are a java programmer, you may want to follow RodJohnson. These guys (I thank them) tweet few times a day and knowing that DHH and his team is upto each day is huge… it is gold mine!

Mass conversation:
Twittering is like sitting at a bar with folks that share your interests and talk about interesting things, just that it happens in a very loosely coupled way. All the same conversation rules apply. You want to be having light and funny yet intelligent conversation without having to invest the time to walk to a bar. And you can be in multiple bars at the same time. It doesn’t replace the bar meetups but it does make it easier to have more of those in our daily life, a good thing isn’t it.

You are never alone, even when you are alone:
We always had internet to keep us busy surfing and killing time when alone. One problem with plain vanilla internet surfing is that you have manually visit several websites to dig relevant pieces out that are important to you. Twitter makes it easier to subscribe to channels (people or companies or search tags) that are relevant and in very short message bursts gives you lots of superficial information. This is great for quickly perusing on channels and then dig deeper into stuff that interests you. With twitter account and a smartphone, those 5 minute wait at bus station, 10 minute wait at restaurant could be good investment in keeping in touch.

Books, Articles, Blogs and now Twitter:
We couldn’t write books every month, so we started writing articles. We couldn’t write articles each week, so we invented blogs. We can’t write blogs every day, so we have twitter. It is just a very low cost way to get the message across.

After using it for a while here are some things I learnt as far as twitter etiquettes are concerned:

Keep audience engaged:
My leg is hurting … nice weather … are boring tweets. They don’t initiate interesting conversation. Instead what I’ve found useful is to post an opinion on some news you just heard. Or some article, blog that you came across or commenting on a live TV cast of Presidents’ speech. Ask quick yes/no type questions although not always. Talk about pair programming .. how about twitting a quick question to you programmer colleague on how to solve a pesky problem? beat that!

Post often but not too often:
Posting 15, 20, 30 tweets a day on an account is good. Anything more is annoyance and you run the risk of loosing your followers. Posting less isn’t good either. It isn’t blog or article after all. Its purpose is to keep in touch … how about a tweet an hour on average.

Have separate accounts:
You need separate accounts to match each of your personalities. By personalities, I mean you are a professional at work, music rockstar in your school circle and lazy bum in your family circle. Sometimes the differences in these personalities are so stark that you don’t want to mix those. For example, my mom and sister will have no interest what so ever in my ruby programming tweets. However, my colleague at work aren’t really interested (much) in my hindi movie reviews and cricket fan club conversations. Having separate accounts keeps things simple.

All in all, the concept of twitting is here to stay!

Certainly, a great innovation. Does twitter.com hold a patent for this

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

acl9 is a an authorization library for rails applications. It is one of the widely used library if not the most widely used now. Our experience with acl9 shows that it might be heavy weight if your authorization needs are simpler (which most projects are) but could be useful for other projects.

If you’ve used acegi/spring-security for authorization in your java apps, you know that acl9 is very similar in principle and hence very powerful. In addition to primary roles, it provides object level permissions which are stored in a generic way separately from the objects being controlled, all without the need for handcoding/distributing your authorization columns in each authorization-object tables.

One place where acl9 differs from acegi is how it doesn’t differentiate between a role and a permission. Acegi signifies roles as global permission level which allows you to do certain things (some action on any object of a given class). Where as, a “permission” controls whether your can take that action on a certain object of a class or not. Acl9 calls them all “roles” (primary-roles and object-roles). As you can imagine, a given user may have a few roles in system but end up with lot and lots of permissions in system depending on how many objects user owns etc. This may seem like good idea at first but it presents a unique problem which is not apparent at first. Since roles and permissions are not conceptually separate in acl9 – and that a user can have lots of them (few roles and lots of permissions) – prevents us from loading and caching them in memory. Why do we need to keep them in memory? Because you are querying user’s primary roles most often in your rendering of pages.

For example, consider navigation-bar which is common in most applications. Different users are presented with different tabs in navigation-bar and this bar gets rendered on each request/response cycle. Whether to render a particular tab is conditional to whether a user has certain role (primary role in particular) or not. Since acl9 cannot keep all roles (and permissions) in memory, it has to perform database query every time it has to find whether a user has_role?(admin) or not. Given that there can be only a few primary-roles that the user will have in any system, it seems in-efficient to not cache them and go to database each time.

The solution would be to separate these primary-roles from permission-roles and cache them for each request. In acl9 this means overriding User.has_role? and user.has_role!.

class User
  def has_role?(role, object = nil)
    if object || !Role.primary?(role)
      super
    else
      primary_roles.collect(&:name).include?(role.to_s)
    end
  end
 
  def has_role!(role, object = nil)
    super
    @primary_roles = extract_primary_roles if(Role.primary?(role))
  end
 
  def primary_roles
    @primary_roles ||= extract_primary_roles
  end
 
  def extract_primary_roles
     self.role_objects.select { |r| r.primary? }
  end
  private :extract_primary_roles
end

That does it. You cache the primary-roles and leverage those for has_role? queries.

Related posts:

1. Defining custom roles/servers in capistrano Capistrano works seamlessly for standard deployment where your app is...

Related posts brought to you by Yet Another Related Posts Plugin.

render :update do |page|
  page << "alert('message');"
end

render :update do |page|
  page.call 'alert', "message"
end

render :js => "alert('message');"

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Here is a jquery userscript that I found simple to integrate:

var GM_JQ = document.createElement('script');
GM_JQ.src = 'http://jquery.com/src/jquery-latest.js';
GM_JQ.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(GM_JQ);
 
// Check if jQuery's loaded
function GM_wait() {
	if(typeof unsafeWindow.jQuery == 'undefined') { window.setTimeout(GM_wait,100); }
	else { $ = unsafeWindow.jQuery; letsJQuery(); }
}
GM_wait();
 
function letsJQuery() {
// All your custom GM code must be inside this function
}

I am not sure if we can put this in a separate JS file and import this in all our customer userscripts. But it is small enough to be copy/pasted (yuck! but necessary) into each file.

As an example, I visit NationalMortgageProfessional.com website often for mortgage related news these days. But I hate the flashing ads on the right bar. All I needed is to hide this bar. Of course, you can do this in 2 lines in javascript, but jQuery is so much better. Here is how I did it:

var GM_JQ = document.createElement('script');
GM_JQ.src = 'http://jquery.com/src/jquery-latest.js';
GM_JQ.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(GM_JQ);
 
// Check if jQuery's loaded
function GM_wait() {
	if(typeof unsafeWindow.jQuery == 'undefined') { window.setTimeout(GM_wait,100); }
	else { $ = unsafeWindow.jQuery; letsJQuery(); }
}
GM_wait();
 
function letsJQuery() {
  // hide the right sidebar with flashing ads
 $('#sidebar-right').hide();
}

And there I went.
Happy Reading!

Related posts:

1. Disabling form post in google chrome and safari So, I found this issue with google chrome and...

Related posts brought to you by Yet Another Related Posts Plugin.

I make an attempt that is less intrusive and uses just the git logs. Here is the rake task that does it:

task :timelog => [:environment] do
  require 'logger'
  require '/home/sjain/projects/gems/ruby-git/lib/git'
  require 'fastercsv'
  logger = Logger.new(STDOUT)
  logger.level = Logger::WARN
  g = Git.open(Rails.root.to_s, :log => logger)
  logs = g.log(1000)
  log_entries = logs.entries.reverse
  worklog = {}
  log_entries.each_with_index do |commit, index|
    author_date = commit.author_date.to_date
    daylog = worklog[author_date] || OpenStruct.new(:date => author_date, :duration => 0)
    daylog.message = "#{daylog.message} --- #{commit.message}"
    daylog.duration = daylog.duration + calc_duration(log_entries, index)
    worklog[author_date] = daylog
  end
  FasterCSV.open("time_report.csv", "w") do |csv|
    worklog.keys.sort.each do |date|
      duration_in_hours = (worklog[date].duration/1.hour).round(2)
      puts "#{date.to_s(:db)} #{duration_in_hours}"
      csv << [date.to_s(:db), duration_in_hours, worklog[date].message]
    end
  end
end
 
def calc_duration(log_entries, index)
  commit = log_entries[index]
  if index > 1
    previous_commit = log_entries[index-1]
    duration = commit.author_date - previous_commit.author_date
    # ASSUMPTION: if the gap between 2 commits is more than 3 hours, reduce it to 1-hour
    duration = 0.5.hour if duration > 3.hour
    return duration
  else
    # ASSUMPTION: first commit took 1/2 hour
    0.5.hour
  end
end

There are some sensible assumptions being made to account for that fact that you stopped working at night and continue next day. This script currently looks at all logs by everybody. On a typical project with several developers, we may want to select logs for particular authors. This script needs further enhancement in that sense.

What is nice about this script it doesn’t depend on any git commit hooks and can be run on any git repository, after the fact, to get an approximate hours count.

The more tiny commits you make, the more accurate the result is.
Enjoy!

Note: I used ruby-git for git api.

Related posts:

1. Rails monkeypatching to pin-point offending code Monkey-patching is generally a bad thing but it can help...

Related posts brought to you by Yet Another Related Posts Plugin.