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

Friendly attributes pattern in Ruby

brunosutic.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Friendly attributes pattern in Ruby

#71

Post by [deleted] »

jaredcwhite wrote: post #40
montroser wrote: post #39

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic. I once was hackathoning with a colleague who was trying to get me excited about Rails, and he said, "look how great this is -- if you want the idea of…

1.method(:day).source_location shrug Look, I'm not a big fan of all of Rails' monkeypatching. That's why I don't use Rails anymore, I use other Ruby frameworks like Bridgetown, Roda, and Hanami. But there's definitely a way to dive into the "magic" and find out what's going on.

[deleted]

Re: Friendly attributes pattern in Ruby

#72

Post by ryandv »

jaredcwhite wrote: post #40
montroser wrote: post #39

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic. I once was hackathoning with a colleague who was trying to get me excited about Rails, and he said, "look how great this is -- if you want the idea of…

1.method(:day).source_location shrug Look, I'm not a big fan of all of Rails' monkeypatching. That's why I don't use Rails anymore, I use other Ruby frameworks like Bridgetown, Roda, and Hanami. But there's definitely a way to dive into the "magic" and find out what's going on.

[flagged]

Re: Friendly attributes pattern in Ruby

#73

Post by hoipaloi »

montroser wrote: post #42
jaredcwhite wrote: post #40

Earlier quoted context omitted.

1.method(:day).source_location shrug Look, I'm not a big fan of all of Rails' monkeypatching. That's why I don't use Rails anymore, I use other Ruby frameworks like Bridgetown, Roda, and Hanami. But there's definitely a way to dive into the "magic" and find out what's going on.

Ah, that's good to know! Yeah, he was wrong about a lot of stuff, so that adds up. He ended up in jail for a stint.

you monkeypatch over core methods like that they put you in jail right away no trial, no nothing. Metaprogrammers... we have a special jail for metaprogrammers. You're global variabling? Right to jail. You're using for loops instead of iterators? To jail right away. You're type checking by class... Jail. Abusing eval? Jail. You're using global variables like a drunken sailor? You right to Jail. You overuse class variables Jail. You underuse class variables believe it or not jail. You use too many tests also Jail, overuse underuse. You use define method and you could have created the methods explicitly? Believe it or not, jail right away. We have the best code monkeys in the world because of jail.

Re: Friendly attributes pattern in Ruby

#74

Post by whstl »

dlisboa wrote: post #68
radanskoric wrote: post #36

Earlier quoted context omitted.

Can you explain why you say they would be better off? What else would be a better choice and why?

Just want to reiterate what the sibling commenter said, it's dead on with my experience. Static typing would be the main thing teams would've been better off with. I was big on dynamic languages, love Clojure/LISPs and still work with Ruby and JS today, but you just can't trust 100 developers with it. Last company I worked for I ran the dev team and did some bug analysis: conservatively 60% of bugs were things a simp…

Yep.

The thing about "it's IO bound anyway so who cares" is that it forces you to scale the app much earlier.

At a company I worked, a single Golang instance (there was backup) was able to handle every single request by itself during peak hours, and do authentication, partial authorization, request enrichment, fraud detection, rate limiting and routing to the appropriate microservice. I'm not saying it was a good idea to have a custom Ingress/Proxy app but it's what we had.

By contrast, the mesh of Rails applications required a few hundred machines during peak time to serve the same number of requests, and none of it was CPU-heavy. It was DB heavy!

If it had been a Golang or JVM or Rust app it would require a much smaller fleet to serve.

Re: Friendly attributes pattern in Ruby

#75

Post by chucke »

dlisboa wrote: post #68
radanskoric wrote: post #36

Earlier quoted context omitted.

Can you explain why you say they would be better off? What else would be a better choice and why?

Just want to reiterate what the sibling commenter said, it's dead on with my experience. Static typing would be the main thing teams would've been better off with. I was big on dynamic languages, love Clojure/LISPs and still work with Ruby and JS today, but you just can't trust 100 developers with it. Last company I worked for I ran the dev team and did some bug analysis: conservatively 60% of bugs were things a simp…

Static typing has come, there's RBS, which has (finally) coalesced (after adding support for inlining in code) as the blessed type notation, supported by both steep and sorbet. Considering that big companies have adopted it, I'd say that the community agrees and has done something about it. But as you can imagine, many ruby apps have been stuck in legacy for years.

About performance, not sure how you think static typing could solve it, but considering the significant investment recently in JITs, in particular YJIT and ZJIT, again, the big apps seem to agree with you and have done something about it?

Even if you ditch CRuby for the JVM, you can still use JRuby, and still leverage the language while not being pulled down by the runtime.

It's not like you're without options.

Re: Friendly attributes pattern in Ruby

#76

Post by igouy »

isr wrote: post #60
montroser wrote: post #39

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic. I once was hackathoning with a colleague who was trying to get me excited about Rails, and he said, "look how great this is -- if you want the idea of…

That's one thing which ruby unfortunately did not adopt from Smalltalk. In Smalltalk (at least, in the dialects I'm familiar with), the "method categories" metadata is used to signal that we're adding new methods (or overwriting existing ones) to classes that are outside the scope of this package (ie: classes you didn't create as part of your app). That way, it's easy to trace, forwards (from package to all the metho…

> If you can't stop blowing your own foot off…

I can. It is, of course, those who worked on the project before me, that expressed their all-too-human over-confidence in their own abilities and judgement.

And then we would spend-a-weekend to rip-out the changes they'd made to Smalltalk system classes, that conflicted with the version upgrade.

(Something about the narcissism of small differences.)

Re: Friendly attributes pattern in Ruby

#77

Post by dragonwriter »

isr wrote: post #60
montroser wrote: post #39

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic. I once was hackathoning with a colleague who was trying to get me excited about Rails, and he said, "look how great this is -- if you want the idea of…

That's one thing which ruby unfortunately did not adopt from Smalltalk. In Smalltalk (at least, in the dialects I'm familiar with), the "method categories" metadata is used to signal that we're adding new methods (or overwriting existing ones) to classes that are outside the scope of this package (ie: classes you didn't create as part of your app). That way, it's easy to trace, forwards (from package to all the metho…

> That's one thing which ruby unfortunately did not adopt from Smalltalk. In Smalltalk (at least, in the dialects I'm familiar with), the "method categories" metadata is used to signal that we're adding new methods (or overwriting existing ones) to classes that are outside the scope of this package (ie: classes you didn't create as part of your app).

> That way, it's easy to trace, forwards (from package to all the methods it introduces) & backwards (from method to package), who introduced a method, where, and why.

Doesn't Method#source_location in Ruby provide a mechanism for this?

Though, in modern (>3.x) Ruby, its probably better to avoid monkey-patching unless you need to override behavior exposed to consumers that aren't opting in, and just use Refinements that consumers can opt-in to using.

Re: Friendly attributes pattern in Ruby

#78

Post by stevoski »

anamexis wrote: post #27
stevoski wrote: post #14

Off-topic, but unlike the example pricing plans, don’t make your SaaS’s “standard” plan $10/month. If you want a place to start, start with $50/month. Or, as Patrick McKenzie used to tell us over and over, “charge more”. (Yes, yes, I know some situations, customers, product, thinking, etc are different. But with broad brushstrokes, my advice is to not even entertain such a low price.)

This is such a broad generalization as to be useless. I use several pieces of software that are around $10/month which there’s no way in hell I would pay $50 for.

I'm not writing from the POV of a consumer of software. I'm writing from the POV of a seller of software.

If you are selling software, don't be the person charging $10/month. It's hard to make that business work.

Be the person charging $50/month. It's still hard - any business is - but it's much easier to make a software business financially viable if you charge decent money.

Post reply on HN