sabat

I love how Jason Fried, the most self-important man in software (who can't code) is first on the list to diss the security patches. Fuck you, Jason. Learn to code. Then you can diss.

Well, plus, Austin, your weather sucks. And, you're in Texas. You're the best that Texas has, sure, but still, you're in Texas.

Not anymore. http://www.nytimes.com/2012/09/03/business/media/reddit-thri...

Ruby is not, in fact, slow. This myth has been debunked so many times that I'll just leave the googling to you as an exercise.

I have a friend who's an O'Reilly author. Granted, he's not the author of, say, the book on Bash, or Git, but it's a current book. He likes to joke around about how little money he makes on the book (now in second edition): "I make hundreds of dollars. Hundreds!"

Yeah, +1 on that idea. PDF would be really nice.

Not quite. He's saying that people who think Ruby is slow are often people who have no idea how to performance-tune it.

Yup. They're like any other tool. If you're not sure how to use and/or, then don't use them. Or, better yet, study up. Programming can benefit from nuance.

Not sure why someone chose to downvote this to 0, but here's how the OP put it:

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.

Due to the Global Interpreter Lock (GIL), your whole script is wrapped in one giant mutex. That means that you don't have code running in true parallel, so the data is not corrupted as it is in JRuby and Rubinius (which both implement real, true, parallel threads).

I guess it's a lot easier to try things like this than to update your business model. That might require thinking and work.

E.g. -- someone posted a link here to an article in which they describe using Google Hangouts for everything. There's a permanent one that everyone is on all damn day. There are special, throwaway hangouts for asides and meetings and anything else that might be needed.

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).

My own experience, anecdotal as it may be, is that this is entirely untrue. What matters is communication, not facetime.

They're wrong to equate being remote with not producing value. If people are not producing value for the company, sure, fire them. If they are doing well, then why force them to relocate? What's the business sense in that?

It isn't necessarily bad. But being about as good as AOL is not why Ms. Marissa was hired.

I think we'd need to see this research. Just in terms of avoiding drive-bys, working remotely is far more stable and efficient (ergo productive).

Yeah, and someone else's mom uses AOL for email. Yahoo: the new AOL.

It takes a very specific type of individual to work at home with the same efficiency as in an office

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

Remote employees are a commitment

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.

Your bias is showing.

Because when that one beefy server goes tits-up, you're out of business. Same with two.

You know, I've had this going on all four of my Gmail/Google accounts (!) for well over a year now, and I still think it's totally worth it. It's not really a pain, and I can sleep better because of it.

Man, I had this very idea a few months ago. :-)

My site is wildly faster with CloudFlare. As with everything, YMMV.

It's been a successful strategy for many companies, however perilous it might be.

In other news, this is not a headline from The Onion.

They're not synonyms; "and" is not a more readable version of "&&".

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.

I like what I've read, but with a couple of cavaets. Ruby is the way it is on purpose. Discouraging people from using features of the language because the OP (presumably) does not understand how to use them: that's an anti-pattern.

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

This isn't actually news. I think I knew about Apatosaurus (vs. Brontosaurus) in the 1970s.

Just waiting for the first person to announce that *BSD is dying, a la the ol' Slashdot trolls.