Category: rails

Run guard-jasmine-headless-webkit without X server

You write specs for your javascript, right? If not, you really should.

jasmine-headless-webkit really helps with that. guard-jasmine-headless-webkit makes it all even more enjoyable, although there’s one caveat – it’s not so easy to set it all up.

There is a great guide for that, but it lacks some important details on running guard-jasmine-headless-webkit without graphical interface (X server).

Assuming you already have Xvfb installed, execute this command to run Xvfb in the background:

Xvfb :0 -screen 0 1024x768x24 > /dev/null 2>&1 &

And then you need to setup the DISPLAY shell variable in order for guard-jasmine-headless-webkit to automatically connect to our virtual frame buffer. Here’s the excerpt from my .bash_profile (it first checks if there is Xvfb running on display :0 and only then sets the DISPLAY variable):

xdpyinfo -display :0 &>/dev/null && export DISPLAY=:0

hookup is the shit!

This is simply amazing:

$ g pull
Already up-to-date.

$ g co edge
Switched to branch 'edge'
==  AddFileTypeToSong: migrating ==============================================
-- add_column(:songs, :file_type, :string)
   -> 0.0048s
==  AddFileTypeToSong: migrated (0.1380s) =====================================

$ g rebase master
Current branch edge is up to date.

$ g co master
Switched to branch 'master'
==  AddFileTypeToSong: reverting ==============================================
-- remove_column(:songs, :file_type)
   -> 0.1674s
==  AddFileTypeToSong: reverted (0.1679s) =========================

Oh, and it will bundle automatically for you as well, so don’t hesitate and hookup your Rails project!

On Heroku

While Heroku is nice and all, it suffers from the same disease as every other hosted-for-you solution:

$ git push heroku
(...)
-----> Gemfile detected, running Bundler version 1.0.7
(...)

$ bundle --version
Bundler version 1.0.10

It’s a whole three patch versions behind! Now I don’t really know (and maybe don’t even really want to know) what has changed between .7 and .10, but I can easily imagine things braking precisely because those minor inconsistencies in Bundler versions.

And sure, I could downgrade to .7, but to do that just because of Heroku? Thank you, but no. I want to ride the latest.

Mocha. The stubbing library

This example (shortened here):

class Order
  def shipping_cost
    total_weight * 5 + 10
  end
end

require 'test/unit'
require 'rubygems'
require 'mocha'

class OrderTest < Test::Unit::TestCase
  # illustrates stubbing instance method
  def test_should_calculate_shipping_cost_based_on_total_weight
    order = Order.new
    order.stubs(:total_weight).returns(10)
    assert_equal 60, order.shipping_cost
  end
end

and this snippet (emphasis mine):

The more interesting discussion deals with whether to mock or stub your database-backed model. One upside is speed: This test case will not hit the database at all. Another is independence. I completely isolate the code under test to the controller layer.

convinced me that there just might be some treasure to be found beyond the Test::Unit. And I know that it’s just the tip of the iceberg.

Rails and Merb together

Or putting it in another words: Merb will be merged into Rails to become Rails 3.0. Is it 1st April just way too soon or what? – was my first thought the moment I’ve read it on the Ezra’s blog. But then I’ve read the official announcement and… it kind of turned out to be true. Surprised I was, definitely. I haven’t really jumped on the whole Merb bandwagon. Sure, I was planning to try out Merb in the (rather distant) future. Now it seems I won’t have to. Merb supposedly did lots of things better than Rails (modularity, less dependencies, more lightweight, faster) and those things are to be incorporated into Rails. Will see how this pans out.

Exciting times. Definitely exciting. Nice Xmas gift.

Rails helpers. Rediscovered

Normally, you’d use partials to manage some common functionality in a single file. For example like this:

Somewhere in your view:

<%= render :partial => 'ads/ad', :locals => {:placement => 'frontpage-banner1'} %>

It’s quite concise, but how about making it even less verbose? Helpers to the rescue:

module AdsHelper
  def ad(placement)
    render :partial => 'ads/ad', :locals => {:placement => placement}
  end
end

And now you can write this in your view:

<%= ad 'frontpage-banner1' %>

Nice! I believe it’s as short as it gets. Sure, if you render this partial only a few times it might not be worth it, but what if you render it 20 or 30 times?

content_tag FTW!

About those one-liners… How about turning this:

<% if logged_in? %>
  <p><%= link_to 'Edit', document_edit_path(@document) %></p>
<% end %>

into this:

<%= content_tag 'p', link_to('Edit', document_edit_path(@document)) if logged_in? %>

I don’t know about you, but to say that I’m impressed would be not enough. Available from Rails 2.0 upwards.

Mongrel_cluster not starting after hard reboot

Does the following error sound familiar?

** !!! PID file log/mongrel.pid already exists.  Mongrel could be running already.  Check your log/mongrel.log for errors.
** !!! Exiting with error.  You must stop mongrel and clear the .pid before I'll attempt a start.

It usually happens when the server crashes. After that you need to ssh into it, remove the mongrel pid files and start the cluster manually. No more.

I assume you have mongrel_cluster setup properly, ie: project’s config file is in /etc/mongrel_cluster and the mongrel_cluster script has been copied from:
/usr/lib/ruby/gems/1.8/gems/mongrel_cluster-*/resources/
to the /etc/init.d directory. You need to edit the /etc/init.d/mongrel_cluster file:

Change this two bits:

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

  mongrel_cluster_ctl start -c $CONF_DIR
  RETVAL=$?
;;

and

restart)
  mongrel_cluster_ctl restart -c $CONF_DIR
  RETVAL=$?
;;

to

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

  mongrel_cluster_ctl start --clean -c $CONF_DIR
  RETVAL=$?
;;

and

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

respectively.

Adding the --clean option makes the mongrel_cluster_ctl script first check whether mongrel_rails processes are running and if not, checks for existing pid files and deletes them before proceeding.

You must be using the mongrel_cluster version 1.0.5+ for it to work as advertised (previous versions were buggy). To upgrade do:

gem install mongrel_cluster
gem cleanup mongrel_cluster

Here’s the related mongrel_cluster changeset.

TylkoZyczenia.pl – My third rails app available to the public

TylkoZyczenia.pl – my new Rails website is now live. It’s Polish language only and it will probably stay this way. Basically, it’s a site with collections of wishes for various occasions, like Christmas, New Year, birthdays and so on. At the moment it’s not very different from other, similar websites (and there are lots of them in Poland) apart from the fact that my design, in my humble opinion, is leaner and much more clearer/simple than the others (aka simplicity all the way). I have some ideas to make this site different (read: better) from the others, though. Stay tuned.

It took me about 2 months of intensive, after-hours work. It’s the first version, which is usable to be online (meaning that basic stuff, like registering and adding new wishes work. The TODO list is quite big…). Enjoy!

Tylko życzenia!

Late night capistrano

Excerpt from my current Capistrano cheat sheet:

cap deploy_with_migrations
- will deploy normally and then run 'rake db:migrate' (SCARY!)
- 'cap disable_web' (FIRST!)
- WILL NOT RUN ANY :after_deploy methods (FUCK!)

Now don’t get me wrong, I really love Capistrano (now at 1.4) as it makes my development life a lot easier. It’s just those little bits that bite you in the ass in the most unexpected moment.

Oh, and I’m sure there’s a reasonable explanation for this behaviour.

UPDATE: It has its own ticket now.