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

261–270 of 336 posts

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

#261

Post by matwood »

Beltiras wrote: post #15
gqewogpdqa wrote: post #4

Earlier quoted context omitted.

Can you explain?

I can't explain for the other user but I'll tack on my own little horror story. I once got the task of porting something written for early nodejs that used MongoDB as a backend to Django. The app had been developed by a contractor and had many iterations of the data layer. I had to somehow make sense of how to make that all fit in a relational database. The changes made were not documented at all and I didn't have ti…

> I have this oldschool thing about data meeting invariant criteria and I dislike not using a RDBMS.

Same. As another 'old school' person, I've been around long enough to see that data outlives whatever the current application is of the day. This means that storing data in something that is standard, has good tooling, and can have some guarantees ends up critical.

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

#262

Post by matwood »

userbinator wrote: post #72

I wish more developers would abide by the old saying "don't fix it if it ain't broke." It's one thing to update because you know a newer version has fixed a bug you're experiencing, but if everything is already working as you'd expect, IMHO you're just asking for trouble. There's a reason a lot of the infrastructure systems that many people don't even know about --- until something breaks --- hasn't changed in litera…

> I wish more developers would abide by the old saying "don't fix it if it ain't broke."

This can work for internal software (see people still running old Windows and IE for some random internal app), but breaks down for software with public access. The problem is when a bug is found, and one will be found, the farther behind the current release you are, the harder it is likely to fix.

I prefer to update my dependencies every so often so that I'm never too far behind if I'm suddenly forced to update for some critical security issue.

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

#263

Post by astrowilson »

byroot wrote: post #249
astrowilson wrote: post #245

Earlier quoted context omitted.

That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is. The language and framework, by your own statement, are pushing breaking changes at a yearly rate. Tha…

No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite sized yearly changes to much bigger changes over longer periods. e.g. Ruby with this strategy never had the big divide Python 3 had with its much larger change.

You may not believe this, but there are other ways of versioning software beyond breaking things every year and doing whatever Python 3 did.

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

#264

Post by Beltiras »

GreenWatermelon wrote: post #207
jacquesm wrote: post #26

Earlier quoted context omitted.

RDBMS are the solution to many of the problems that these 'modern' systems have, but it isn't cool. Someone joked that the wave of the future will be SQL, and that those start-ups that use it will believe that they have superpowers over the ones that don't. Transactional integrity, complex queries, constraints, what's not to like?

This video should speak to you https://youtu.be/b2F-DItXtZs

I could find a single sentence from the noob that I could agree with. Redis is superior to memcached. Not due to being faster or scalable, I've just had less operational problems with it than memcached. It's on my list of supersoftwares that are first choices to solve a problem in it's domain (nginx, uwsgi, postgresql, redis).

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

#265

Post by jorams »

chucke wrote: post #227
gedy wrote: post #203

Earlier quoted context omitted.

No, this is particularly bad in Ruby. Many languages, esp. compiled do not have the same issues.

Java and log4j would like a word with you.

The problem with log4j is that they didn't introduce a breaking change, allowing vulnerable functionality the maintainers already considered problematic to stick around.

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

#266

Post by ay »

philwelch wrote: post #181
munificent wrote: post #32

Earlier quoted context omitted.

I'm guessing the sentence they wrote is just a consequence of English not being the author's primary language. I frequently see ESL speakers get adjective and adverb positions wrong in ways that unintentially change the meaning. Even skilled English speakers make mistakes here because English is both very permissive about word order, but also tends to give different shades of meaning to each other. "Only" is a pernic…

It’s kind of like the saying, “all that glitters is not gold”. Gold doesn’t glitter? That makes no sense. English syntax is not mathematical logic. The song, “I Can’t Get No Satisfaction” is not a song about someone who is forced to receive satisfaction.

It’s curious that a Russian version is much more precise:

“Not everything that glitters is gold”. (The truly 1:1 translation is “not everything is gold that glitters” but that word order felt very wrong and I believe the change doesn’t change the meaning, does it ?)

How does it sound for a native speaker ?

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

#267

Post by flubflub »

byroot wrote: post #234
astrowilson wrote: post #225

Earlier quoted context omitted.

> This type of library API breaking change on a minor version update basically never happens. Literally happens all the time with Rails. To the point they decided to call their versioning schema “shifted semver” to afford themselves API changes on minor versions: https://guides.rubyonrails.org/maintenance_policy.html Good luck if you are using Rails and ecosystem and you expect any sort of sensible versioning.

Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails must first emit deprecation warnings, so unless you are jumping one version, this kind of scenario shouldn't happen with Rails itself. Also note that Ruby (MRI) itself more or less…

I don't use Ruby.

Are packages that don't follow semver allowed to be released?

Haskell asks for PVP for example.

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

#268

Post by sorokod »

gingerlime wrote: post #253
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…

> Of course it’s easy to miss something, but unit tests could have caught this issue. Nitpick, but I don't think unit tests would have caught this. Integration or systems tests might have caught this however, but those can be much harder to create and maintain in practice, in this particular case.

Well, you get what you pay for. If integration tests are viewed as too expensive, then an occasional penalty is just the price of doing business.

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

#269

Post by flubflub »

zestyping wrote: post #216
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.

And another: 4. Don't design an API that mixes fluent style (methods are like infix operators) with conventional style (methods are like prefix operators). Fluent methods should never take multiple operands. It's a terrible, horrible, no-good, very bad idea.

I think the default should be named prefix operators. Then you can have infix operators that are aliases.

This is a problem in Haskell with infix operators being directly defined I would argue.

I disagree that infix and prefix should not be mixed. Although there is a special hell for people who use + with non-commutative operators.

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

#270

Post by cpatuzzo »

It's one thing to apologise, but there was no talk in the article about measures they're taking to prevent this happening again. I sincerely hope they're scrambling internally to put some safeguards in place. Yes, it's bad a minor version bump changed behaviour, but now they know this can happen, it's irresponsible not to mitigate this risk, e.g. by scrubbing the card details for expired subscriptions from Stripe.
Post reply on HN