For more awesomeness, check out my dotfiles repo called YADR (Yet Another Dotfiles Repo), featuring 100% clean vimrc with all custom keymapping done in well factored scripts inside vim/plugin/settings, and a list of plugins perfectly tailored for Rails development, currently in alpha preview.

Blazing fast way of finding references to the current partial you’re viewing using this simple script. Requires git-grep.vim. Bonus: at the bottom of the script I also define “K” to git grep the current word. Very handy for fast function reference finding.

Like this post? Here are some more you might enjoy:

• Five ways to get insane productivity boosts
• Colorful ruby tests and debugging

I was recently designing an application that needed to execute some long running requests against an external host. If you’ve ever tried doing something like this in Rails, you’ll find your mongrels will block up waiting for the request to complete, bringing the experience for all other users to a halt.

I wanted to dispatch my long running request, return to the user, and then poll for results using AJAX. There are many ways to do background tasks in Rails, most of which require running an out of process background server with which you will communicate over some sort of queue or memcached. There’s BackgroundRb, Bj, workling, and so on, but this seemed overkill for my problem.

After reading a post on using Ruby Threads, I decided to be brave and try this approach. I implemented a simple action which would spawn a thread and proceed to return the result whether it was ready or not. This action is polled via AJAX and on the next poll the result will be correct. The pseudocode looks something like

def long_running_action
  #spawn a thread
  precache_the_results

  # This action throws DataNotAvailableException
  # if file is missing/unreadable
  results = read_cached_results

rescue DataNotAvailableException
  # This tells me that when I load the page
  # I should invoke an ajax a couple seconds
  # later to check for results again
  flash[:update_right_away] = true
ensure
  respond_to do |wants|
    # render an RJS update with the results
  end
end

def precache_the_results
  Thread.new {
    expensive_action_outputs_to("file.txt")
  }
end

Because I didn’t join the Thread to the request thread, it lives on after the request completes, which is just what I needed. Since the code inside my Thread is a call to an external provider and doesn’t write to the database, I am not concerned with ActiveRecord threading issues.

The only problem with this approach is that in development mode, Rails likes to reload your classes on every request. But if your thread runs past the request lifetime, the class that’s running it may be unloaded while it’s running, wreaking all sorts of havoc. But Ruby allows us the power to be truly evil:. What if I just prevent Threads from doing what they want to in development mode? Turns out I can!

if ENV['RAILS_ENV'] == 'development'
  class Thread
    def initialize(&block)
      block.call
    end
  end
end

This code is defined in the class where I’m doing the magic. Do NOT just slap this into your environment.rb as you’ll horribly break the Rails startup logic. There’s probably a slightly smarter and safer way to do this by using a Factory pattern to create the threads and explicitly specifying the implementation you want. But this is my party and I’ll monkeypatch if I want to.

So..comments, suggestions, complaints? Is this going to die horribly in production? I guess we’ll have to see!

This code is written using the shoulda plugin which gives a slightly more verbose breakdown of the setup and the test, but it can be done with test/unit just as well.

context "orphan user migration" do
  setup do
    require "#{RAILS_ROOT}/db/migrate/163_create_orphan_owner"
    CreateOrphanOwner.up
  end
  should "create the orphan user" do
    assert orphan = User.orphan_owner
    assert orphan.role?(User::ORPHAN_OWNER)
  end
end

There are way too many tagging plugins for Rails. I’ve produced this post as an attempt to summarize the differences between them. Disclaimer: I didn’t actually try all the plugins but I did peruse their code when deciding which one I would use.

My criteria for choosing a plugin was:

• Important: Supports user-owned tagging
• Important: Supports tag cloud generation
• Less important: Code as clean as possible for extending
• Somewhat important: ability to contribute patches. I had been stuck with a heavily customized 2006 acts_as_taggable before and didn’t want the same thing with the new plugin.
• Not important: Related tags, and other complex tag searches

After reviewing the options, acts_as_taggable_redux seemed like the best candidate. I immediately had a couple contributions, which I first emailed to Wes, and later he moved the plugin to github and I am now a direct comitter.

I plan to continue to enhance this plugin, and possibly add some features to it from the other plugins, such as tag caching which becomes important for scalability. As it’s the most minimal of the plugins I feel it’s a good base to start with building clean code that doesn’t have a lot of legacy stuff from the 2006 plugin, which was the dark ages of Ruby coding with lots of ugly code produced :-)

Of course, only Enterprise Java scales, and we know this because the word Enterprise is right there in the name. Of course, the only platform you should consider is .NET because it has built in caching and hundreds of thousands of college graduates know it. Of course, you need to use PHP because Facebook is written in PHP and Facebook scales. The fallacy of these arguments should be painfully obvious, yet people are shouting these things as if they were gospel truth.

I’d like to offer here, the scalability manifesto. Please repeat these items aloud to yourself every time you want to say something about language X or framework Y not scaling.

The Scalability Manifesto

1. Scalability means the ability to handle increasing load by increasing resources.
2. Scalability does not mean being ‘fast’.
3. Choice of language does not guarantee scalability.
4. Hardware costs decrease exponentially, developer salaries do not.
5. Only you can make your system scale.

Trading performance for development time is generally not a good idea. It’s likely that by the time your application reaches serious traffic levels (if ever), hardware will cost half of what it did when you started. Now does spending twice as much dev time with a lower level language seem justified? Now this is not always the case, but my bet is if you do the math and realize your team of 4 Ruby hackers is doing what a team of 10 Java programmers used to do, you might conclude that linear performance gains due to language choice are not as relevant as hiring smart people who can get work done quickly, and design scalable systems.

There’s no such thing as a free lunch, and that includes scalability.

I’m really happy to see that the Rails team and 37 Signals are making this move because it will force Lighthouse to become an even better application as it meets demands of many projects that are sure to follow Rails.

Too many teams put up with products that have terrible usability like Bugzilla because many programmers tend not to think about usability as an important factor. We are used to command line interfaces and white text on black backgrounds. But believe it or not, using something like Lighthouse over say, Bugzilla, boosts your productivity because it is well designed and lets you get to the information you need more quickly and with less frustration. That said, Trac is still many levels above Bugzilla in usability and design so if you’re using an in-house product, I don’t know of many better ones.

I’ve been using git-svn to work on a local branch of our svn when I work on Planypus and have enjoyed the ability to do local commits on the go. I can’t say I’ve quite mastered all the ins and outs of it yet but working with git via git-svn is pretty smooth and it’s fun to see all the output that shows your changes being played back when you do ‘git svn rebase’. Other than that, working with git does require a bit of a paradigm shift because the primary entity is the changeset rather than the file. I hope to get a better handle on things like reverting in the near future and am watching the progress of GitHub and friends with great enthusiasm.


$LOAD_PATH.reject! { |e| e.include? 'TextMate' }