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

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Standup 2010.06.17 Bagel Thursday Edition

Ask for Help

“What are people using in Rails apps for authentication via Facebook Connect?”

  • Devise
  • Janrain if you want something that can use many different social websites authentication; it also hooks up sharing, etc.

“There seems to be a bias against Rails Observers. Anyone know why?”

I want to use them, but whenever I look around people seem to say they don’t like them any more. Anyone know why?

“Is Pivotal Tracker crashing for you in Safari??”

This is a known issue but we’re having a bear of a time reproducing. We’re accepting Safari stack traces over email, with bonus points for figuring out how to send us Session cookies post-crash.

Interesting Things

  • When using Passenger in spawn mode (to fork your workers), post-fork you MUST reopen any outbound sockets for things like Redis, Memcache, etc. Otherwise all your other connections will use the same socket. And you won’t notice it until oddness starts to happen when under load and processes get the wrong responses.

  • For some time now, Google Chrome has been happily giving stack traces when using Jasmine! Firefox has always done this. If you’re keeping score, only Safari refuses to give you stack traces in your failing Jasmine specs.

  1. Hmmm, github seems to think redis sockets are ok (at least under unicorn – the forking should be the same w/unicorn, no?):

    from :

    after_fork do |server, worker|
    # Redis and Memcached would go here but their connections are established
    # on demand, so the master never opens a socket

    We were having issues with mongo and mongo_mapper gems in our Gemfile even though they were never loaded as far as we could tell – had to comment them out entirely to fix it… Then we moved over to unicorn since we were still having weird issues, now things seem super stable (last 24 hours at least ;-)

  2. Sam Pierson says:

    Redis and memcache-client do indeed connect to their respective servers on first request. The question is, does this first request happen before you fork or after? If you boot the Rails stack before you fork, and your boot up process accesses memcache (ours does), you may experience this problem.

  3. On observers – at first they seem like a good idea, but as you have a larger code base, they are easy to overlook. Have the before/after save logic outside your model makes you forget that it’s even there. Also, enabling/disabling observers in config has also been very odd as well. I’d much rather prefer something on the ActiveModel class to say which class observers it. This might allow for more flexibility for common observers to share code.

Post a Comment

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

* Copy This Password *

* Type Or Paste Password Here *