sabat

The global lock is a feature of MRI that basically wraps a big mutex around all of your code. That's right, even if you're using multiple threads on a multi-core CPU, if your code is running on MRI it will not run in parallel.

You don't need to be in person, and many people would surprised how effective teams can be even when they're not in the same room. All it takes is good communication, and by that I mean: 1- good communication technology, like a good net connection and good chat software and good cameras, 2- good use of technology for communication (IM software is not sufficient), and 3- good communication practices (which amounts to: communicate early, communicate often).

Yes, one who knows how to communicate. But you wouldn't want an on-site employee who doesn't communicate, either.

So are on-site employees, who can screw off just as much as an off-site one.

if the remote employees are not providing enough value to justify that investment in remote workers

Then fire them. This kind of draconian move won't get Yahoo anything but an even bigger talent hemorrhage than it already has.

As Avdi Grimm says: and and or, despite an apparent similarity to && and ||, have very different roles.

It's worth using "and" and "or", especially considering that && and || bind too tightly for some purposes. I try to avoid && and || unless I'm doing a specific boolean operation (e.g. x = foo || bar). Not for flow control, though.

If you really can't grok the logic, use parens.

The and and or keywords are banned. It's just not worth it. Always use && and || instead.

If you find "and" and "or" not to be "worth it", it tells me that you don't understand the difference. The "&&" and "||" versions bind more tightly, and that is not always desirable. Perl has the same set of constructs, and the Perl monks have been using them correctly for years.

As you can see all the classes in a class hierarchy actually share one class variable.

Well, yeah. That's meant to be a feature of the language, not "nasty behavior". It's good advice to use class instance variables, sure. But let's not imply that Ruby is a badly designed language; it's quite well-designed. This isn't Javascript. :-)

edit: formatting