hakunin's blog

Dumb tester_elf

hakunin — Sun, 21 Jun 2009 20:23:40 +0000

This tester_elf script is very dumb, which is uncharacteristic of elves in general. Why did I name it tester_elf? Well, it’s a Santa’s little helper type of elf as opposed to an individual of Tolkien’s highly cultural race. I do crave some nice D&D RPG experience but there aren’t any good new games in that direction. Everything gets dumbed down nowadays.

Anyhow, here’s the gist of it.

It just runs a test file every time you save it. Stupid but useful when autotest is too bulky. Instructions are in the gist.

yui_compressor_fu

hakunin — Sat, 30 May 2009 06:08:30 +0000

Please welcome a new thingie I just released – yui_compressor_fu.

Point

yui_compressor_fu delicately minifies all your assets (linked with javascript_include_tag, stylesheet_link_tag helpers) with YUI Compressor. It abides Rails caching rules. All you have to do is install the plugin, and minifying will automatically kick-in when rails performs its normal caching routines.

Tale

Today I was having my usual cup of Earl Grey with lemon while trying to find some JS/CSS minifying solution. Nowadays Rails provides built-in concatenation and caching, but not compression. I wanted to find something that transparently adds some minifying to the mix. Well, not so fast.

After flipping through quite a few choices, I wasn’t impressed at all. Available plugins either require too much configuration (why do I have to list all my assets again, asset_packager?) or they use inferior compression algorithms (Packer/MinJS). According to my research (don’t quote me) – YUI Compressor kicks some major ass. A few minutes of fruitless digging later I decided to make this plugin instead.

Feel free to try it out and let me know of any issues you encounter.

Better in-memory associations with :inverse_of

hakunin — Tue, 05 May 2009 04:21:32 +0000

Today Rails gained a very interesting commit from h-lame. It’s the first major step towards making associations aware of their parent model while still in-memory. A few days ago I started this discussion which revealed to me that it had been a long time coming, just no one bothered.

Well, finally someone did. I would like to thank h-lame for making this commit happen. Here’s the excerpt from the commit message.

You can now add an :inverse_of option to has_one, has_many and belongs_to associations. This is best described with an example:
      class Man < ActiveRecord::Base
        has_one :face, :inverse_of => :man
      end
 
      class Face < ActiveRecord::Base
        belongs_to :man, :inverse_of => :face
      end
 
      m = Man.first
      f = m.face
 
Without :inverse_of m and f.man would be different instances of the same object (f.man being pulled from the database again).

Installing Sphinx with Postgres on Leopard

hakunin — Fri, 01 May 2009 07:12:48 +0000

I didn’t find a quick short guide to installing sphinx on Leopard with PostgreSQL, hence here goes (this assumes you already installed PostgreSQL).

Compile dependencies

These two libs are required by sphinx according to this blog post.

  ~% mkdir src
  ~% cd src
  ~% curl -O http://ftp.gnu.org/gnu/libiconv/libiconv-1.13.tar.gz
  ~% tar xzf libiconv-1.13.tar.gz
  ~% cd libiconv-1.13
  ~% ./configure --prefix=/usr/local
  ~% make
  ~% sudo make install
  ~% cd ..
 
  ~% curl -O http://internap.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
  ~% tar xzf expat-2.0.1.tar.gz
  ~% cd expat-2.0.1
  ~% ./configure --prefix=/usr/local
  ~% make
  ~% sudo make install
  ~% cd ..

Compile Sphinx

At this point latest stable release was 0.9.8.1.

  ~% curl -O http://www.sphinxsearch.com/downloads/sphinx-0.9.8.1.tar.gz
  ~% tar xzf sphinx-0.9.8.1.tar.gz
  ~% cd sphinx-0.9.8.1
  ~% export LDFLAGS="-L/usr/lib" 
  ~% ./configure --prefix=/usr/local --with-pgsql --without-mysql
  ~% make
  ~% sudo make install

You’re all set.

References

Shmacros

hakunin — Wed, 29 Apr 2009 08:28:04 +0000

I use shoulda constantly as it is my favorite testing framework. I figured the custom macros I write may prove useful to others, thus I released them as a plugin called shmacros. As of now it includes the following methods.

should_accept_nested_attributes_for
should_act_as_taggable_on
should_be
should_callback
should_delegate
~~should_have_attached_file~~ (removed in new revision)
should_validate_associated

It’s best to have Mocha installed as some of the macros rely on its presence.

  ~/dev/myapp% sudo gem install mocha
  ~/dev/myapp% script/plugin install git://github.com/maxim/shmacros.git

Give your :reject_if some sugar

hakunin — Thu, 09 Apr 2009 05:15:50 +0000

Tired of writing stuff like this?

accepts_nested_attributes_for :photo,
                              :allow_destroy => true, 
                              :reject_if => proc { |attrs| reject = %w(title picture).all?{|a| attrs[a].blank?} }

Throw this snippet into init.rb into a new plugin folder (I called it reject_if_missing).

module RejectIfMissing
  def missing_attrs?(*required_attrs)
    Proc.new { |attrs| required_attrs.all?{|a| attrs[a].blank?} }
  end
end
 
ActiveRecord::Base.send(:extend, RejectIfMissing)

Now you can do this instead.

accepts_nested_attributes_for :photo,
                              :allow_destroy  => true, 
                              :reject_if      => missing_attrs?('title', 'picture')

Teach models to stalk each other with Stalker

hakunin — Fri, 03 Apr 2009 14:33:17 +0000

I often come by a case where models need to talk to each other. ModelA sometimes needs to ask ModelB to do something after_save. Usually you'd just use a callback.

class ModelA < ActiveRecord::Base
  after_save :update_model_b
 
  def update_model_b
    ModelB.update!
  end
end

This is obvious coupling. ModelA needs to know what to call in ModelB. This isn't ModelA's concern. Ideally, ModelA should simply notify ModelB that it saved.

class ModelA < ActiveRecord::Base
  after_save :notify_model_b
 
  def notify_model_b
    ModelB.model_a_saved!(self)
  end
end
 
class ModelB < ActiveRecord::Base
  class << self
    def model_a_saved!(modela)
      self.do_something_about(modela)
    end
  end
end

This is a better way to do it since now ModelB is responsible for performing whatever it requires. Except, this is too verbose. Imagine you had to notify ModelC as well, it'd get ridiculous.

class ModelA < ActiveRecord::Base
  after_save :notify_model_b
  after_save :notify_model_c
 
  def notify_model_b
    ModelB.model_a_saved!(self)
  end
 
  def notify_model_c
    ModelC.model_a_saved!(self)
  end
end

This is too much work for each such notification. Instead, you may notice that this can be solved by observer pattern. Rails already provides Observers, but they are completely separate classes, and don't save us any work in this case, since they can't be part of an existing model. This is where Stalker comes in. Stalker allows you to have one model simply observe the other.

class ModelA < ActiveRecord::Base
  # nothing to do here
end
 
class ModelB < ActiveRecord::Base
  stalk ModelA
 
  class << self
    def after_model_a_save(modela)
      self.do_something_about(modela)
    end
  end
end

The above solves separation of concerns issue. ModelB is now fully responsible for watching ModelA, and can easily react to events by using callbacks such as after_[model_name]_save or before_[model_name]_create. In the parameter it will always automatically get the object which triggers the callback.

Just like with Rails observers, you have to ensure that the stalker models load before the stalked ones. You can use the same active_record config for that.

In your environment.rb have this line uncommented and make sure it includes the name of the stalker.

config.active_record.observers = [:model_b]

Under the hood.

Stalker is a micro-plugin with only 35 lines of code. It takes away most of the boilerplate work from setting up model-model observers. The stalked model receives a "notify" method for each possible callback, and this method calls the after_[my_name]_save on the stalker model, just like in the above example. The difference is that you don't have to maintain ModelA at all, stalker will do it automatically. In addition, since you get the same code as in the above example, you'll also be able to interrupt the callback chain by returning false from the stalker model.

Install

% script/plugin install git://github.com/maxim/stalker.git

Integer_fu: store and manipulate many boolean values in a single integer column, with convenience

hakunin — Tue, 24 Mar 2009 05:05:55 +0000

Link: http://github.com/maxim/integer_fu

I just finished the first version of a convenient plugin I've been writing for my own project. Integer_fu lets you map an integer attribute in your model to many possible boolean values, and then access them easily using hash-like syntax and some magical methods. Check it out down at Github. I tried to explain usage thoroughly in the readme (featuring Fluffy Horse).

W3C macros is now a Rails plugin on GitHub

hakunin — Mon, 16 Mar 2009 20:06:22 +0000

Feel free to grab it at github.com/maxim/should_pass_w3c_validation.

W3C validation in functional tests with shoulda macros

hakunin — Mon, 09 Mar 2009 18:03:28 +0000

Update: Added code explanation.

I found that the best place to put W3C validation tests would be among your controller tests. In your functionals you already walk across all your pages and deal with authentication, so why not put some more load on that donkey?

First thing - install w3c_validators gem.
sudo gem install w3c_validators

Now, throw the following gist into
test/shoulda_macros/should_pass_w3c_validation_macros.rb

Usage

Now you have a nice w3c validator macros which can be used simply, as part of your controller testing with shoulda.

context "on /index" do
  setup do
    get :index
  end
 
  should_respond_with :success
  should_assign_to    :assets
  should_render_with_layout
  should_pass_w3c_validation # <= Hehe, there you are!
end

What's happening in the code?

The main part of our macros code is validator itself - we instantiate it by calling MarkupValidator.new. It does all the validation work, but it takes a filename on input. Since we're actually in controller tests - we usually pull pages using methods like get "/path/to/page". I need to somehow get the full html of that page to give it to the validator, and I need it in a file, since validator only accepts filenames. One way is to create a Tempfile, and throw the @response.body in there. @response object exists in all controller tests, and contains response data which was returned upon calling get "/path/to/page". This is exactly what we need. @response.body holds all of html/js/css which server sends to your browser when you access a certain page in your controller test. All we need to do now is dump the response output into a tempfile so we can feed it to validator.

Looking into the code you can see that I write @response.body to tempfile and pass the path to that tempfile into the validator. What happens next? We get a nicely formatted array of warnings and errors, courtesy of the validator itself. It sends our file to W3C public service and returns with a bunch of errors/warnings. These messages are a perfect candidate for being displayed on test failure (the so-called 'fail_text') - since the mere fact that we got any of those messages means we failed. Thus by checking the sizes of both the warnings and the errors array I can tell if my test passed or not - they both have to be zero. If the test fails I display all of them. So what is that substitution that's happening? Why do I have to go over each warning/error and remove some piece of text? That's because message contains path to the file - and in our case the path is always to some arbitrary tempfile. Nobody needs that - it only pollutes the test output. So the latter part of the code removes those paths from messages. That's all.

The crappy part

Obviously, your tests will get very slow, as now they rely on some public service provider. You should definitely implement a switch for turning this type of tests on/off in different circumstances (like when you're on a Boeing 737 making your way from Antigua to Newark).