Live data from Hacker News

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

serpapi.com

221–230 of 336 posts

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

#221

Earlier quoted context omitted.

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.

You're right that the language isn't to blame as such.

But if a change like this doesn't cause some kind of uproar in the Ruby community, then the community has a problem.

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

#222
The biggest problem is not the lack of a Unit test - which likely wouldn't have caught this problem anyways - but the fact they are using a "joke database".

Mongodb is good for your high-school app or prototype demos not for production SaaS that debits credit cards.

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

#223
post #150

Earlier quoted context omitted.

Yeah, semver is great, except nobody follows it. The amount of times I have updated minor or even patch releases of packages with things breaking--I have pretty much determined everything in a project stays the same unless there's some pressing need. The worst part is that breakage is often far from obvious, and spending good time wondering why everything breaks when it shouldn't is really really infuriating and make…

> I have pretty much determined everything in a project stays the same unless there's some pressing need Unless you have a way to stay up to date with the security of each and every dependency you have, that seems dangerous. There are static security scanners out there which can parse your dependency tree and alert you, but often they have a high noise ratio ( e.g. npm audit), so that only helps so much.

The "easy" way to do this is to write your application using whatever is included in a stable Linux distribution.

You get free, trivially applied security updates and a much lower chance of breakage. Optionally you can pay for support to have them fix problems in dependencies.

Granted, It'll be difficult with languages like Javascript where many popular dependencies aren't likely to be packaged.

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

#224

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

It's interesting that we have procedural languages that enforce strict whitespace conventions, ostensibly to improve readability and eliminate common sources of errors, but none that require the use of parentheses in complex expressions.

When someone I work with writes something like that example:

    if (a==b & c==d)
... I tend to (want to) lose it.

I have decades of continuous C/C++ experience and I have no earthly idea what the relative precedence of & and == is. Don't know, don't care. Use parentheses whenever it looks even remotely like they'll help clarify the expression. They're free. (Floating-point precision shenanigans aside.)

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

#225
post #129
post #36

Earlier quoted context omitted.

I feel spoiled having most of my experience in js, react and node. They like, try really hard not to totally break shit.

You would feel spoiled if you were a ruby developer too. This type of library API breaking change on a minor version update basically never happens. And if it can happen in ruby land, it can happen in JS land too.

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

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

#226
post #212

Earlier quoted context omitted.

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.

Somewhat related to your points of music... There's an episode of "This is Pop!" on Netflix that explores why the Swedes write so many pop hits. One of the arguments presented is that they speak English well as a second/third language so they're less focused on the lyrics making sense and being grammatically correct, and are free to make lyrics that sound like they work but are non-sensical on reflection. It's just t…

The song “I want it that way” comes to mind, the song topped many charts including in the US, and the lyrics are very strange upon reflection. What does “I never wanna hear you say. I want it that way.” mean exactly? Apparently the Swedish songwriter barely spoke any English at all at the time.

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

#227
post #203

Earlier quoted context omitted.

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

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.

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

#228

Earlier quoted context omitted.

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.

It definitely has something to do with Ruby and Rails. Ruby and Rails introduces API changes on minor versions all the time, sometimes even without prior warnings, so people shouldn’t expect related gems to be any different.

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

#229

Earlier quoted context omitted.

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

You're right that the language isn't to blame as such. But if a change like this doesn't cause some kind of uproar in the Ruby community, then the community has a problem.

It won’t cause a uproar because Ruby/Rails changes APIs on minor versions all the time. Breaking changes are pushed at a yearly rate and everyone is just expected to cope with them.

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

#230
post #129

Earlier quoted context omitted.

You would feel spoiled if you were a ruby developer too. This type of library API breaking change on a minor version update basically never happens. And if it can happen in ruby land, it can happen in JS land too.

> 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 never was semver. Their yearly major-minor grand release always, always breaks API all around. It's inevitable. Any rails-only gem will as a result have a strong incentive not to follow several.
Post reply on HN