Reminder: "Broken gets fixed, but shitty lasts forever"

Yes, maybe. But a fun-hack with the addition "should make it generic".

A quick ack VERIFY_NONE above an out-of-the-box install of a gem-loaded shopping framework reveals 6 instances of VERIFY_NONE, one of which in a function called aply_ssl_options ...

The interesting part of the OP in my opinion, is more about the copy-paste technique which makes this kind of "just use gem-install" code into back doors. [edit: deleted double post... xmonad's surprising short cuts are a blessing]

While true, it has to be balanced with the fact that you are tasked with creating a product to earn (or save, etc) the company money. Perfection can never be reached, and you have to say 'Good Enough!' at some point and just ship.

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.

Using sensible wrappers around Net::HTTP would resolve the issues with the unreasonable defaults.

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.

DO we have a term for this in the small?

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

If James Golick considers this to be important enough to criticize other people and even write a blog post about it, why does he write a fix?