travis-ci/travis-worker — comment on commit dd066256825365e1a3dd5602f62c4016c0288109
File:  line 0
By michaelklishin:

@svenfuchs I will do 2 and 4, although I am not sure I understand how that is different. Lazy initialization is another name for race conditions and travis worker will have to deal with concurrency no matter what VM it runs on and whether it uses threads or something fancy. Connection is exactly what I've asked on IRC earlier today, initializing it lazily in the worker (it was the case in the 1st commit from today) would have to be synchronized and the only good way to do it even with JRuby is to use JDK atomic references. I figured moving it up to Application both removes the need for synchronization and makes more sense since it is a "top-level" class.

About #1, I disagree that worker deals with much of AMQP-specific logic. This is how AMQP applications work: entities that consumer or publish messages are given channels and the rest is up to them. Because worker ties together a bunch of other entities, it sets up some ground for them: opens channels and declares queues. This will be the case with other messaging protocols once you get past 2-3 entities that consumer or publish messages. Moreover, AMQP code in travis-support that I moved away from both did not allow me to implement what I implemented here and it had so much implicit state I had really hard time understanding how it works. So this is something I won't be changing.

About #3, wasn't there a talk about *not* indenting private and protected methods by some of the most famous people in the Ruby community? I don't get what the indenting gives you. No other programming languages I know of uses indentation for protected methods. No editors other than Textmate that I know of does that.