Skip to content

Index

cherry picking git commits

I've been a little bit slow to learn git. I put that down to it being my fourth version control system (after rcs, cvs and svn). Like a fourth child[1] it brought with it less novelty and I've got less free time to get to know it. That being said, git is a revolutionary advance over subversion and is worth committing the effort to learn.

A little while ago I imported my deployment library 'deprec' to github. This week I discovered a feature that shows me what changes other open source developers have been making on their forks of the deprec codebase.

Github network feature

Clicking on that link shows us a diff for that commit and today Pete Yandell was kind enough to show me how to cherry pick a commit and apply it to my repository.

#First we create a branch and pull thewoolleyman's code into it
git checkout -b thewoolleyman
git remote add thewoolleyman git://github.com/thewoolleyman/deprec.git
git pull thewoolleyman master

# Next we find a commit that interests us
# I chose 09dca130c2826339f3cacff937acee4ef26c6d6c
git log

# Compare this changeset with the previous version
# Note that you can use github for this and the previous step.
diff 09dca130c2826339f3cacff937acee4ef26c6d6c 09dca130c2826339f3cacff937acee4ef26c6d6c^

# Change back to our master branch
git checkout master
git cherry-pick 09dca130c2826339f3cacff937acee4ef26c6d6c

# Push the changes to our remote repo (in this case - github)
git push

I'm pretty excited at how simple it is to see what other people have done with my code and merge it into deprec. Github have provided a feature that I think will really aid in the development of open source. Well done guys!

[1] I don't have kids (yet) but if and when I do I hope they realize this was said in jest!

How to use deprec-1 when deprec-2 gem is released

[2013-12-19 I've not done any work on deprec in the past few years]

deprec-2 preview has been available at www.deprec.org for a while now and is quite stable. When I release it as a new version of the deprec gem it's going to cause users of deprec-1 to see errors. I recommend using deprec-2 for new installations but understand that some people will want to continue using deprec-1 for legacy systems. In preparation for release of deprec-2.0.0 I've some minor modifications so that deprec1 and deprec2 co-exist on the same machine.

To continue using deprec-1.x, install deprec-1.9.3:

$ sudo gem install --version 1.9.3 deprec

Update your projects deploy.rb:

require 'rubygems'
gem 'deprec', '< 1.99'
require 'deprec'

Adding the following to your .caprc will load the correct version of deprec based on the version of Capistrano you're using:

require 'rubygems'
gem 'deprec', '< 1.99' unless respond_to?(:namespace)
gem 'deprec', '>= 2.0.0' if respond_to?(:namespace)
require 'deprec'

You can call capistrano 1 with the command:

cap _1.4.2_ show_tasks

or create an alias by putting the following in your .profile:

alias cap1="`which cap` _1.4.2_"

This will allow you to use the following:

cap1 show_tasks

If everything's working you'll see the deprec tasks listed.

Getting monit to restart mongrel after a crash

An annoying aspect of the Mongrel webserver is that it refuses to start if it detects a stale pidfile. This causes real problems when you're trying to use something like Monit to automatically restart mongrel after a crash.

Most daemons check whether the process_id in the pidfile is running. Ezra has indicated that a future release of mongrel will do this but in the meantime, we can use mongrel_cluster with the --clean option to remove stale pidfiles before starting mongrel.

Update /etc/init.d/mongrel_cluster to include the --clean option in the start and restart commands.

  start)
    # Create pid directory
    mkdir -p $PID_DIR
    # chown $USER:$USER $PID_DIR

    mongrel_cluster_ctl start --clean -c $CONF_DIR
    RETVAL=$?
;;
  stop)
    mongrel_cluster_ctl stop -c $CONF_DIR
    RETVAL=$?
;;
  restart)
    mongrel_cluster_ctl restart --clean -c $CONF_DIR
    RETVAL=$?

Update your monit config to use mongrel_cluster. Note that monit sets a restricted path (PATH=/bin:/usr/bin:/sbin:/usr/sbin) and the internals of the mongrel_cluster gem call mongrel_rails without specifying the path. mongrel maintainers [http://mongrel.rubyforge.org/ticket/31#comment:1 suggest] using env in the monit command and said this is already fixed in a svn. I've found creating a symlink from /usr/local/bin/mongrel_rails to /usr/bin/mongrel_rails does the trick. Then update your monit config to look something like this:

check process mongrel-8010 with pidfile /var/www/apps/tubemarks/shared/pids/mongrel.8010.pid
group mongrel
start program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails cluster::start --only 8010 -C /etc/mongrel_cluster/tubemarks.yml"
start program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails cluster::stop --only 8010 -C /etc/mongrel_cluster/tubemarks.yml"

The nice part here is the --only option which allows you to restrict the command to a single mongrel process (as defined in the config file).

I've deprec-1.99.16 has been updated to use mongrel_cluster as described above to clean up stale pidfiles before starting mongrel. As a side note, I was glad to see mongrel has a new website and is being fed and cared for by it's new owners.

OmniFocus - GTD for OSX

Being a fan of Dave Allen's personal productivity book "Getting Things Done", I was excited to hear that The Omni Group are working on a tool I can use to implement this work-life management method.

The author of kGTD (a GTD template for OmniOutliner Pro) has produced a fine introductory screencast to OmniFocus. This really explained what I needed to know to use the software.

To preview alpha versions of OmniFocus you need to sign up to their mailing list. A day after doing so I got an email inviting me to test the software.

The application is still under heavy development but it looks great. I have used kGTD in the past and liked it but found it a little clunky.

Capistrano and Rake

Last night I read the chapter on automation in Tom Limoncelli's book, Time Management for System Administrators. He spent a lot of time extolling the virtues of Make and how useful it can be in automating sysadmin tasks. Rails makes good use of Rake (think 'ruby-make') to specify administrative tasks. Make/Rake let you specify dependencies in your tasks and by checking file timestamps you can avoid running tasks unnecessarily. This has given me an idea for a change to the way deprec works.

It would be nice if I could restart mongrel on the server using the same command as I use in Capistrano. I'm not suggesting using Rake from my workstation but rather to have many of deprecs cap tasks call a Rake task on the server. So 'cap deprec:mongrel:restart' would call 'rake deprec:mongrel:restart' on the server(s).

There would be two main benefits to this.

Firstly, all deprec tasks would be available from the command line on the target host (obviously some bootstrapping would be required to install Rake, Ruby, etc initially). While I prefer not to have to log in manually to each of the servers in a cluster, there are times when I'm logged in and would like to be able to run tasks locally.

A second benefit is that we could take advantage of dependencies. Compiling PHP, after Apache has already been installed, will no longer cause Apache to be recompiled. Installing Subversion, when Apache has not already been installed, will cause it to be installed. This will reduce the amount of time tasks take to run (which is non-trivial when it involves compiling the likes of openssl!)

Back in May 2007, Bradley Taylor of Railsmachine released a nice gem called Machinify. It's a set of Rake tasks that will install a Rails stack on Ubuntu. It's very nicely written and quite readable. I considered whether I should make deprec dependent on Machinify but as it lacks some of the tasks I want (install, nginx, postgres, etc) I think it would be better for deprec come with its own Rake tasks.

So, it's very tempting to re-architect deprec2 but another thing to consider is this: would we be better off with a working deprec2 next week or a re-designed deprec2 at some later point? I think working code is a better result than ideas that won't get implemented in the available timeframe.

One issue with calling remote rake tasks via Cap is dealing with interactive dialogs. deprec currently deals with this by listening for certain output from the remote call. I can't see why deprec couldn't simply call the remote rake task and listen for the same output. This would allow deprec tasks to be extracted into rake tasks.

So my current thinking is to press on with deprec2 development and then extract the tasks into Rake tasks at some future point.

Using rails-1.2.3 with Rails 2.0 Preview release installed

Rails 2.0 Preview has been released, along with a great summary of changes it includes:

http://weblog.rubyonrails.org/2007/9/30/rails-2-0-0-preview-release

While I was excited to install the gem (gem install rails --source http://gems.rubyonrails.org) this caused problems went I got back to developing an existing app even though I had rails-1.2.3 specified in my environment.rb.

It turns out that the preview release is version 1.2.3.7707 and Rails considers that to be the most appropriate version to use when I specify 1.2.3. Not what I was expecting!

A quick fix so your existing apps will still use 1.2.3 is to change this line in their config/boot.rb.

-rails_gem = Gem.cache.search('rails', "~>#{version}.0").sort_by { |g| g.version.version }.last
+rails_gem = Gem.cache.search('rails', "#{version}.0").sort_by { |g| g.version.version }.last`

Update 2007-10-05 This morning the very entertaining new Rails Envy Podcast informed me about r2check, a script that checks your existing Rails app and let's you know what you need to do to make it Rails2.0 ready. It worked for me. Thanks to Mislav Marohnić for saving me time. :-)

Simply Jestful

Update: I'm using jester.js version 1.3.

Jester is basically ActiveResource for javascript. It's amazing. I love it! With almost no changes to my scaffold_resource generated controllers I was able to work on my models via javascript in my web browser.

All I had to do was download the javascript and put it in public/javascripts/

I put this in my layout: <%= javascript_include_tag 'jester.js' %>

Then I was able to do this in Firebug:

>>> Base.model('User')
>>> Base.model('Comment')
>>> c = Comment.create({comment: 'i love jester'})
POST http://localhost:3000/comments.xml (381ms)prototype.js (line 866)
Object _name=Comment _format=xml _singular=comment
>>> c.id
12
>>> c.user
Object _name=User _format=xml _singular=user _plural=users
>>> c.user.display_name
"Mike"

Use XML, not JSON. The Rails implementation of .to_json() is not as fully featured as .to_xml().

This patch was accepted into core in June. I used it to patch my rails-1.2.3 installation. It stops the following from failing:

format.xml  { render :xml => @post.to_xml(:include => :comments, :methods => [:obfuscated_email]) }

Jester is documented in a series of release announcement blog posts. I recommend reading them in order.