Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A routine gem update ended up creating $73k worth of subscriptions

serpapi.com

Post reply on HN
Print view View original

191–200 of 336 posts

Re: A routine gem update ended up creating $73k worth of subscriptions

#191

Post by Aeolun »

hyperhopper wrote: post #40
munificent wrote: post #33

Earlier quoted context omitted.

> seems cool about it, too. How people blog and how they feel aren't always the same thing. Professionals tend to be a lot more tactful in public communication.

I would be fuming if I were an engineer depending on that, but obviously in a public communication like that, where you are explaining to clients why you charged them erroneously, just pointing a finger and acting mad makes you look like you don't have control of your own software.

A little bit of passive aggressive comments would have been appropriate I think.

Re: A routine gem update ended up creating $73k worth of subscriptions

#192

Post by lmeyerov »

asdfasgasdgasdg wrote: post #128
lmeyerov wrote: post #102

Earlier quoted context omitted.

It's the users who need to audit, the social contract of OSS is just not to be sneaky/sloppy about it (when posing as a serious project). Semvar is beautiful bc it lets you be explicit. Likewise, end users can judge "wow major version 27 in as many months, maybe not so good for us." We had a gov customer today upfront about needing slow updates, and same deal -- maybe our SaaS and OSS libs are too fast moving, so the…

I am a toil/backwards incompatibility hawk. I don't like to impose them on my customers. It's extremely rare that the balance of equities favors making a change like this, where a function that filters data and will necessarily impact correctness is changed , and not in subtle edge cases but in its primary behavior. In fact, I've never seen a case in my career where it ended up being worth it. I'm a big fan of Linus'…

I agree - we probably err too long on avoiding breaking legacy code: we are about to do our first deprecation in years as the old protocols are getting too unconscionably insecure + costly to maintain relative to our new ones.

But that's company code we get paid to be stable on. Very diff story for OSS we at most contribute to, we don't assume that's part of the social contract.

Re: A routine gem update ended up creating $73k worth of subscriptions

#193

Post by potamic »

compiler-guy wrote: post #94

This change gives me new respect for Denis Ritchie's decision not to mess with a wart in operator precedence in C. Even though we still live with this wart 30 years later. It was exactly this type of failure he sought to prevent. He refused to fix it because, "After all, we had several hundred kilobytes of source code, and maybe 3 installations...." https://www.lysator.liu.se/c/dmr-on-or.html

Add Torvalds to the list too - SHUT THE FUCK UP. WE DO NOT BREAK USERSPACE!

https://lkml.org/lkml/2012/12/23/75

This style is indeed controversial but honestly, these kind of situations seem apt for such a chewing out. Backwards compatibility seems to be one of those things that people regularly compromise despite it repeatedly hitting back. For a database driver of one of the most popular databases in the world, it should not be taken casually. I wish more tools adopted the first rule of kernel maintenance - "If a change results in user programs breaking, it's a bug in the library. Never EVER blame user programs." (pp)

Re: A routine gem update ended up creating $73k worth of subscriptions

#194

Post by stouset »

emodendroket wrote: post #182
Gigachad wrote: post #177

Earlier quoted context omitted.

Tbh when you work with ruby to have to assume everything could break with any update and just unit test the shit out of everything. Of course it’s easy to miss something, but unit tests could have caught this issue. It's still just really bad work from the gem developers though. Ideally you shouldn't ever drastically change the behavior of a method. Just introduce it again with a new name and remove the old one. Yeah…

Ultimately this is why I don't like to work in Ruby. You can just never trust any line of code between the gem updates, the unhelpful signatures, the overreliance on hashes everywhere, and a million different levels of mix-ins and indirection. Yeah, it's expressive, but how much time are you really saving once you consider all these maintenance headaches?

This exact problem could have happened in any language. Literally zero of it has to do with Ruby or the ecosystem.

Re: A routine gem update ended up creating $73k worth of subscriptions

#195

Post by hu3 »

sam_lowry_ wrote: post #175
radicality wrote: post #143

Earlier quoted context omitted.

Could you comment on why you recommend Postgres (vs say mysql)? I know mysql well but haven’t had much exposure to Postgres.

Postgres implements the SQL standards however awful they are. MySQL is a bunch of different engines that share a meaningful subset of SQL. Somehow, Postgres got more popular lately, probably because it makes migrating from Oracle easier.

just a nitpick: MySQL comes with the same default engine (InnoDB) for at least 10 years now. It is recommended by docs and it is what everyone uses unless they go out of their way to install some very specialized storage engine.

In my years of consulting I have yet to see someone not using just InnoDB in MySQL.

Re: A routine gem update ended up creating $73k worth of subscriptions

#196

Post by f311a »

sam_lowry_ wrote: post #175
radicality wrote: post #143

Earlier quoted context omitted.

Could you comment on why you recommend Postgres (vs say mysql)? I know mysql well but haven’t had much exposure to Postgres.

Postgres implements the SQL standards however awful they are. MySQL is a bunch of different engines that share a meaningful subset of SQL. Somehow, Postgres got more popular lately, probably because it makes migrating from Oracle easier.

Yeah, MySQL is well known for weird behavior when it comes to SQL queries that don’t follow SQL standards.

Re: A routine gem update ended up creating $73k worth of subscriptions

#198

Post by nottorp »

kurtbuilds wrote: post #138

Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.

> 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL.

In my experience using any ORM will bite you sooner or later and you'll end up bypassing it and writing SQL manually. Last case we had were a couple queries that went from double digit seconds to instant as we rewrote them natively.

Re: A routine gem update ended up creating $73k worth of subscriptions

#199

Post by cpursley »

999900000999 wrote: post #171
kurtbuilds wrote: post #138

Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.

Even though I hate SQL with a passion, I agree with this 100%. Mongo is a nightmare when things get more complex, document based DBs don't work well. It's hard to say why, but strange things tend to happen Ether use something like Firebase which manages everything for you, I use Firebase extensively for almost all of my side projects. It's basically magic. I'm so hooked I ended up using Firebase even though I needed…

Supabase is a good option these days.

Re: A routine gem update ended up creating $73k worth of subscriptions

#200

Post by cpursley »

kevingadd wrote: post #141
kurtbuilds wrote: post #138

Three easy lessons: 1. Don't use MongoDB. 2. Don't use high level ORMs. Stay (reasonably) close to SQL. And yes, it should be SQL. Almost certainly Postgres. 3. Especially don't use Mongoid.

If Postgres feels too heavy, don't worry! Just use SQLite, and swap in Postgres later once you need to.

I guess this is a Rails thing where people treat the db as a just dumb store.
Post reply on HN