I think the responses here, and especially this blog post, are completely out of line. Yes, he's a community leader, but he still has the right to write lazy code to solve problems quickly. It's not like he published it as a gem, blogged about it, and tried to convince a bunch of people to use it. It was just a tweet about a fun hack.
The blog post reads as, "I have some pet issue that I am not important enough to solve; so someone more important than me should solve my pet issue for me". Well, sorry. The world doesn't work like that.
(Maybe you would become a leader if you didn't spend hours of your day thinking about how one-off scripts could be hacked by a malicious server?)
One of Rails' biggest influences on the Ruby community (aside from making you feel like a jerk if you don't write tests) is that there is one "best" way to do common things and you should only deviate from the convention when necessary.
This is great most of the time, because it allows people to jump right into code they've never seen before (or haven't looked at in a while) and know exactly what's going on without having to follow a bunch of code paths and random classes. Having trouble with a poorly documented gem? Just jump into the code because all gems are laid out the exact same way.
However, often when you know something is pretty standard functionality (like doing an SSL request with net/http), you know it's been solved many times before and just find the first article on Google about it and do it that way. And you're about 100 times more likely to just blindly copy and paste the code when it comes from the guy who wrote the most popular Ruby HTML parser.
I see the same thing all the time in iOS development. Everyone just uses the same patterns that Apple puts in their documentation, which is why Joe Hewitt's Three20 framework was such a big deal.
He didn't write a tutorial based on this methodology and I definitely don't see it pimped around anyway. gist is a pastebin, after all.
Three20 wasn't a big deal because it was different from Apple. The noise behind Three20 is that it was (and still is, to a large degree) a cluttered mess of a framework that made it near impossible to use one part without importing the whole thing. I believe that Joe Hewitt has basically said as much on Twitter as well.
If you were to instead point out Apple's template code as a good example of code that is widely-used and not very good, you would have a much better analogy..
Matt Gallagher has also done a good job of deconstructing the Apple Way and try new approaches: http://cocoawithlove.com/2009/03/recreating-uitableviewcontr...
Although, I think this link is better:
See also: http://enfranchisedmind.com/blog/posts/fyi-my-open-source-us...
If you give away toilets for free, it's your responsibility to make sure they aren't lined with sodium and will blow up after the first flush. If you give away a toilet for free, you are an asshole if you know it has a huge hidden hole and you don't warn takers about it. If you write a piece of software that claims to be doing something, but it actually contains malware, then you are violating the law (as much as when you give me a nice statue that contains a spy camera).
It has never been possible or allowed to give just anything you want away for free, without you being liable in any way. That hasn't changed with software and no license in the world can exempt you from certain basic responsibilities concerning your 'gift'.
Now my point is not that this is the case here or that such cases are common or even important. The point is that the blanket statement of my parent is plainly false.
Of course, IANAL, but you don't need to be a lawyer to understand jurisprudence. There are plenty of known cases where people intentionally harmed others and tried to plead guilty based on not actually performing the action that lead to the damage. It doesn't fly.
It shows different ways of providing Net::HTTP with verification certificates.
The reason the VERIFY_NONE fix got so popular is that, by default, if you turn on SSL support in Net::HTTP in an otherwise working codebase, your calls fail with certificate errors. The docs (http://www.ruby-doc.org/stdlib/libdoc/net/http/rdoc/index.ht...) have absolutely no helpful information except for mentioning the default of VERIFY_PEER. If you're noodling around on your own you'll discover VERIFY_NONE works well before you discover how certificate stores work.
And really, if it's crappy code and lasts forever... Isn't that good enough? If you never have to touch it again, then it was as perfect as it needed to be. If you DO have to touch it, it was broken and will get fixed.
I'm not advocating writing crappy code. I'm just saying that you have to draw a line somewhere. I've met amazing coders that will fiddle with the code forever and never finish because they just keep making it better, more readable, prettier, more extensible, or some other thing forever.
Wrest (http://github.com/kaiwren/wrest) would be a good-fit here: it defaults to VERIFY_PEER for SSL connections, has client-side caching support, comes with a fluent API, redirect support, callbacks, patron (curl) back-end etc. etc.
The project is being actively maintained, and we're working to add async support using EM for now.
That's harder, of course when the library has unreasonable defaults.
Those small utilities you wrote a decade ago in perl when your company was tiny, over a couple of days that end up a staple of daily use in a company 10 years later and any attempt to re-factor or replace them 10 years way is met with extreme resistance? What do we call that - Crappy-enough software? (I say this as the author)
(Actually, going back and looking at said code, it's not badly written at all, it's entirely readable, a few perl scripts, no spaghetti, and it's clear how they interoperate just by reading them. So it's not crappy or badly written - it's just overly simplistic.)
There's a vast graveyard of game companies which can attest to it.
It is as meaningless as if you quoted Feynman saying "think about a problem long enough and you'll solve it".
The implicit assumption in either case is one of an underlying quality process and that is one helluva an assumption to make.
And how can you get upset with someone with that twitter pic?