plans = {
1.month => {standard: 10, pro: 50, enterprise: 100},
1.year => {standard: 100, pro: 500, enterprise: 1000}
}
plans.each do |interval, details|
details.each do |name, amount|
Billing::Plan::Factory.find_or_create_by!(name: , interval:, amount:)
end
endFriendly attributes pattern in Ruby
31–40 of 78 posts
Re: Friendly attributes pattern in Ruby
#32Re: Friendly attributes pattern in Ruby
#33Earlier quoted context omitted.
The usual response to this complaint in the Ruby/Rails community is that optimizing for nanoseconds, or even milliseconds doesn't matter when the same operation also involves multiple database queries or API calls. Let's take this example from the article: Billing::Plan.find_or_create_all_by_attrs!( 1.month => {standard: 10, pro: 50, enterprise: 100}, 1.year => {standard: 100, pro: 500, enterprise: 1000} ) This ensur…
i find this structure a bit odd. i would have gone for the following pattern: Billing::Plan.find_or_create_all_by_attrs!( standard => {1.month: 10, 1.year: 100}, pro => {1.month: 50, 1.year: 500}, enterprise => {1.month: 100, 1.year: 1000} )
This is supported and would work with no implementation changes. The "Friendly Attributes" idea is very flexible.
Just a small Ruby syntax correction for your example:
Billing::Plan.find_or_create_all_by_attrs!(
standard: {1.month => 10, 1.year => 100},
...
)Re: Friendly attributes pattern in Ruby
#34When I say Ruby is inefficient it’s not just the language, it’s stuff like this. I don’t fault the author but this kind of stuff is endemic. This way of handling attributes is monumentally less efficient than just using keyword attributes, which are optimized by the runtime. Unfortunately you’ll find this is every Ruby code base: tiny readability improvements that are performing allocations and wasting cycles for no…
The usual response to this complaint in the Ruby/Rails community is that optimizing for nanoseconds, or even milliseconds doesn't matter when the same operation also involves multiple database queries or API calls. Let's take this example from the article: Billing::Plan.find_or_create_all_by_attrs!( 1.month => {standard: 10, pro: 50, enterprise: 100}, 1.year => {standard: 100, pro: 500, enterprise: 1000} ) This ensur…
This attitude towards wastefulness is how you have web apps that could run in a single machine but struggle to run in a server cluster.
And after a couple years even Postgres is struggling because the amount of queries is too massive because of abstractions that don’t lend themselves to optimization.
Also it’s how you have codebases that could be maintained by two or three suddenly needing dozens because the testing suite needs hours to run and people even celebrate when there’s no tests in sight.
Just anecdotal personal experience. But I saw this happening inside at least 4 successful companies that started with Rails but didn’t care about those problems, and ended up wanting/having to move to something else.
Re: Friendly attributes pattern in Ruby
#35Earlier quoted context omitted.
Yeah, this is honestly the sort of thing I grew to hate in Ruby. It looks cute, but all it does is create more cruft. Good ol’ boring keys are just fine, expressive enough, and are very unlikely to cause problems. This feels like it’s attempting to solve a problem that does not exist.
> this is honestly the sort of thing I grew to hate in Ruby But nobody forces you to use a DSL such as rails, so I am not sure why ruby should be hated for this when it is a rails dev who does that. The blog has much more to do with rails than ruby; such API design is really strange. I don't think this design causes problems as such, but it is too verbose and way too ugly. To me it seems that they are just shuffling…
Working in a team means you are kind of forced to use what the team wants.
Of course you can try to convince them otherwise, or just be an asshole and mass-refactor to remove the DSLs.
But this kind of code is part of Ruby’s culture now.
The simple answer for anyone that doesn’t like this style is to leave Rails and Ruby for people who enjoy it.
It’s fine to hate it and want to distance yourself from it.
Re: Friendly attributes pattern in Ruby
#36Earlier quoted context omitted.
Have you used it over the last few years? It has it been rapidly improving, mainly because Shopify put a team full time on it. It doesn’t take a lot of people to optimize a VM/interpreter it just has to be the right people. And the question is always “fast enough for what?” Different languages are more suitable for different types of projects. I wouldn’t code a rendering engine in Ruby but for web apps it’s amazing.
Yes, every web app I’ve worked on the past ~18 years has been with Rails. I’ve seen it all except an efficient app. Sure, Ruby and Rails never bankrupted these companies but they’d all have been better off with something else. Certain cloud bills would’ve been much smaller for sure. Those optimizations to the VM are just very workload specific and become less relevant today when you’re using containers and fractional…
Can you explain why you say they would be better off? What else would be a better choice and why?
Re: Friendly attributes pattern in Ruby
#37"This code should look less like it does what it's doing", that's the Ruby Way™.
Re: Friendly attributes pattern in Ruby
#38Off-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.)
As an end user, there's no way I'd pay $50/month for any SaaS.
Re: Friendly attributes pattern in Ruby
#39This 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 day', you can just write `1.day`!". I opened up a irb to try it out, and it didn't work. We were both confused for a bit until he figured out that it was a Rails thing, not a Ruby thing. That Rails globally punches date/time methods into integers, which he thought was cool, and I thought was abhorrent. I asked, "okay, if I came across this code, how would I be able to know that it came from Rails?" He said, there wasn't any way to really trace a method to its source definition, you just kinda have to know, and I decided this whole thing was too much of a conflict with my mental model for how humans and code and computers should work together.
Re: Friendly attributes pattern in Ruby
#40This 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.