UPDATE: The benchmarks have been updated for new versions of ruby, jruby, puma and unicorn

Previously I wrote about the difference in performance between using thin, puma and unicorn on heroku’s cedar stack. At the time, heroku’s recommendations where to use thin as a server. They now recommend unicorn for better performance and concurrency.

Additionally, I received some very valid criticism on the previous benchmark: Puma is designed to be used on a ruby implementation that does not have a Global Interpreter Lock: Namely Rubinius or jRuby. With that in mind, I decided to test again.

I follow a certain number of ruby-related blogs and have noticed regular of calls to use Vim as an editor, usually with claims of unbridled productivity to follow. One one hand, I see the appeal: I use a bunch of UNIX tools and scripts in my daily work-flow and it makes sense to use a editor that works inside my terminal. I have tried a few tutorials, screen casts and what not, but I have never felt really comfortable. Something has always been off. I always assumed it was due to the big learning curve others talk about.

On the other hand, when I switched from TextMate to Sublime Text, there was almost no drop in productivity. Part of it has to do with similar functionality being mapped to the same keys, like command-t. However, I believe that there is more to it.

I recently discovered that bundler has a feature to create binstubs, so I decided to redo my benchmarks of running a single pending spec (but including the complete spec_helper for my project).

To create rspec binstubs:

1

$ bundle binstubs rspec-core

Here are my findings:

It is still slower than I would like, but well worth the effort. Since I didn’t want to remember the specific invocation depending on what I have running, I have a script that will use binstubs, nailgun and/or spork if available:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#! /bin/bash

# Looking for binstubs
if [ -f ./bin/rspec ]; then
  RSPEC="bin/rspec"
else
  RSPEC="bundle exec rspec"
fi

NAILGUN_PORT=2113
SPORK_PORT=8989

# Looking for nailgun
lsof -i :$NAILGUN_PORT > /dev/null
if [ $? == 0 ]; then
  RSPEC="jruby --ng -S $RSPEC"
fi

# Looking for spork
lsof -i :$SPORK_PORT > /dev/null
if [ $? == 0 ]; then
  RSPEC="$RSPEC --drb"
fi

CMD="$RSPEC $@"
echo $CMD
$CMD

Recently, I have been working on moving some processes from the request-response web cycle to a MongoMapper-backed Delayed::Job. Everything seem to go smoothly, but it seemed that there was some slowness actually queuing the jobs. Here is how I got to the bottom of it.

Sandi Metz recently was a guest at a Ruby Rouges Podcast to discuss her book Practical Object Oriented Design In Ruby, which I reviewed. I encourage you to listen to the episode.

During the interview, she mentioned some rules that she had come up with to give when asked about design guidelines. She was clear that the rules could be broken, but once you understand why the rules are there in the first place.

Without further ado:

1. Your class can be no longer than 100 lines of code
2. Your methods can be no longer than 5 lines of code
3. You can pass no more than 4 parameters, and you can’t just make it one big hash
4. Your controller can only instantiate 1 object to do what needs to be done
5. Your view can only know about 1 instance variable