Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

09/25/12: It's about something


  • Where are my backtraces in specs for gems? (backtrace_silencer is off)

RubyMine uses a custom formatter.
Try rspec my_spec.rb -b on the command line.


  • If you new up a Rails Logger in your Unicorn after_fork, that is the logger you get

If you do something like this:
after_fork do |server, worker|
current_directory = File.expand_path(File.dirname(FILE))
log_path = “#{current_directory}/log/#{Rails.env}.#{}.log”
Rails.logger =
Rails.logger.level = Logger::INFO

… in order to have a different logfile for each unicorn worker, setting the log level in your environment file will not take affect.

  • any_instance doesn’t work with should_not_receive

It always passes.

The rspec folks haven’t decided what it should do. “Official” suggestion is to only use any_instance with stubbing instead of with expectations.

  • Capistrano doesn’t clean up that well

When you use the deploy:cleanup task it only looks at the FIRST server declared in deploy.rb to determine which releases to rm. You’d think that it would look at the primary server. But then you’d think that the task would be included by default, too. Which it doesn’t.

  • Enumerators, ActiveRecord Connections, and JRuby

We ran into what we thought was a quirk of Enumerators where inside the enumerator you are in a different thread from outside. This affects ActiveRecord because your connection is determined by Thread.current.object_id. So you’d end up with a new connection inside the Enumerator.

This turned out to only be true in JRuby. Under MRI, you have the same Thread object, however, you have a new Thread locals context. This makes it particularly hard to find someplace cross Ruby for Rails to store its connection id.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *