7 ms·
Friendly attributes pattern in Ruby
- dudeinjapan 11mo agoYikes. This means that you’ll have 1000 micro-DSLs sprinkled all over your codebase, which will become unreadable and lead to confusion/accidents. Better to stick with good ol’ key-value labelling.
- rubyn00bie 11mo agoYeah, 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.
- onli 11mo agoThe advantage is the amount of code minimized and not using a generic factory pattern. But that probably can be achieved with a bit less magic...
- shevy-java 11mo ago> 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 data structures around; that could even be solved via yaml files.
- whstl 11mo agoWorking 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.
- molf 11mo agoThis is a philosophy. One which many people that write Ruby subscribe to. The fundamental idea is: create a DSL that makes it very easy to implement your application. It is what made Rails different when it was created: it is a DSL that makes expressing web applications easy. I don't know its history well enough, but it seems to originate from Lisp. PG wrote about it before [1]. It can result in code that is extremely easy to read and reason about. It can also be incredibly messy. I have seen lots of examples of both over the years. It is the polar opposite of Go's philosophy (be explicit & favour predictability across all codebases over expressiveness). [1]: https://paulgraham.com/progbot.html https://paulgraham.com/progbot.html
- dudeinjapan 11mo agoIf there is one DSL which is a central abstraction of one’s entire app, used in 100s of places—this is fine. If there is a DSL such as Rails’ URL routing, which will be the same in every app—this is also fine. When one makes 100s of micro-DSLs for object creation, that are only ever used in one or two places—this is pure madness.
- shevy-java 11mo agoI don't really like the API design. Perhaps in the rails-world this makes sense, but it looks really strange to me. Billing::Plan::Factory.find_or_create_by!( name: :pro, interval: 1.month, amount: 50 ) It is not only the verbosity or use of trailing '!' in a method for no real reason, IMO, but also things such as "1.month". I understand that rails thrives as a DSL, but to me having a method such as .month on an Integer, is simply wrong. Same with HashWithIndifferentAccess - I understand the point, to not have to care whether a key is a String or a Symbol, but it is simply the wrong way to think about this. People who use HashWithIndifferentAccess do not understand Symbols.
- byroot 11mo ago> I understand that rails thrives as a DSL, but to me having a method such as .month on an Integer, is simply wrong It's not that different from `1.times` or `90.chr` which are vanilla Ruby. > HashWithIndifferentAccess HashWithIndifferentAccess was an unfortunate necessity to avoid DOS attacks when Symbols used to be immortal. There's no longer a reason to use it today, except for backward compatibility.
- Lukas_Skywalker 11mo agoThe exclamation mark has a reason: if the newly created records fails validations, an exception is raised. Without the exclamation mark, the error is silenced (and the method returns a falsey value). This is a convention across Rails. Ruby itself mostly uses it for mutating methods (e.g. #gsub("a", "b") replaces the character a with b in a string and returns a new string, but #gsub!("a", "b") mutates the original.
- dagi3d 11mo agowhen *everything* is an object this kind of syntax makes absolutely sense and is quite convenient
- apsurd 11mo agomy first thought too, as a rubyist. Yes, "everything is an object" is an essential insight to understanding ruby.
- codesnik 11mo agothis is very unnecessary. Arrays and maps transformations are really easy and concise in core ruby already, one line of map, to_h or whatever.
- kburman 11mo agoThis is a perfect example of something that looks good in a demo but fails in a real product. Business logic and 'packages' are never this clean or simple. Putting this kind of type-based 'magic' in the code is a bad decision that will bite you very soon. It optimizes for being 'cute' rather than being clear and maintainable, and that's a trade-off that almost never pays off.
- nkrisc 11mo agoThey do say they use this in their real production code.
- brunosutic 11mo agoHi, I'm the author of the article and the software library. I confirm I actually do use the examples from the article in my code. Here's the example that runs in hundreds of integration tests: expect(billing_pricing_plans).to eq billing_plans( 1.month => [:free, :premium, :pro, :enterprise], 1.year => [:free, :premium, :pro, :enterprise] ) It asserts what plans the customers see on the pricing page.
- kburman 11mo agoThere's a massive gap between that pattern and the real-world complexity of billing. It's too much to cover in a comment, but this link explains the actual nightmare - https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers https://www.getlago.com/blog/why-billing-systems-are-a-night...
- stevoski 11mo agoOff-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.)
- anamexis 11mo agoThis 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.
- stevoski 11mo agoI'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.
- PufPufPuf 11mo agoAs an end user, there's no way I'd pay $50/month for any SaaS.
- stevoski 11mo agoLots of people feel the same. Which leads me to another piece of advice: don’t do B2C. Sell to businesses who will be far more willing to pay higher prices, will churn at a lower rate, and will - in general - require less support.
- dlisboa 11mo agoWhen 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 real reason other than looking better. I’ve certainly done that and it’s expected, efficient code looks “weird”. A regular “each” loop that looks complicated will be transformed into multiple array method chaining, allocating the same array many times. If you don’t do it someone else will.
- brunosutic 11mo agoThe 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 ensures six billing plans are created. That means 6 DB queries and 6 Stripe API queries, at a minimum.
- dlisboa 11mo ago> 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 The problem with that logic is that it’s pervasive: people have that same attitude everywhere even if no IO is being done. That’s how we get multi gigabyte processes. The whole language (and Rails) also pushes you towards a less efficient path. For instance you’re probably iterating over those six plans and inserting them individually in the DB. Another approach would’ve been to accumulate all of them in memory then build and perform a single query. That’s not something people really consider because it’s “micro” optimization and makes the code look worse. But if you miss out on hundreds of these micro optimizations then you get a worse system. In a general sense optimizing Ruby is indeed futile: any optimization is dwarfed by just choosing a different language. I say all this as someone who has worked with it for two decades, I like the language, it’s just laughably inefficient.
- some1else 11mo agoFeels odd that two feature-equivalent plans are segregated with neighboring duplicates into monthly and yearly branches. I would consider monthly Enterprise & yearly Enterprise the same plan, with modified cost & billing frequency.
- brunosutic 11mo ago> I would consider monthly Enterprise & yearly Enterprise the same plan, with modified cost & billing frequency. How would you then call the objects that store costs and billing frequency? :) Here's what Stripe uses: - Product: "describes the goods or services". This is where you define a (plan) name and features. - Price: defines the amount, currency, and (optional) billing interval. Since interval is optional, Prices can be used to define both recurring, and one-off purchases. Technically, using Prices for recurring, and one-off payments is a brilliant idea. The problem is, no one refers to recurring payments as "prices". Everyone calls a "$50 per year" option a "plan".
- sfgvvxsfccdd 11mo agoHaters gonna hate. My take: DSLs are a useful way to make code easier to read, and more importantly easier to write correctly. Exploring this space and sharing your learnings is useful and valuable.
- culi 11mo agoI wouldn't call this a DSL
- brunosutic 11mo agoArticle author here - thank you for putting it this way. This is exactly the attitude I wanted to convey: it's something I tried and really liked for this specific use case. I shared because I hope it might inspire others. "Friendly Attributes" is not the "new way", not to be used "everywhere now", does not "apply to all scenarios". If you like it, maybe you'll use it once in the next five years when the opportunity arises.
- AlphaSite 11mo agoRuby is a language that optimizes for the local maxima at the cost of the global maxima. Now every library, company or code base has its own pattern and you have to learn its pit falls. Better to learn once, cry once and just deal with it imo. As they say, good enough is the enemy of perfection.
- drzel 11mo agoplans = { 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 end
- bradly 11mo agoI think this is the pattern I would reach for as well, separating the data from the execution. Being declarative about the plans (either with a config file, db backend, or simply a PORO) allows the plans themselves to be agnostic to how they are used and leaves you room to write a clean API for their creation without mixing in their definition. Also ActiveSupport has Object#with_options which has a similar intent, but I rarely ever see it used in codebases.
- Footkerchief 11mo agoExactly. Use a fancy expressive structure if you want, but don't try to abstract away the mapping between that and the general-purpose code that it relies on. "Each domain has its own rules"? How would I even know where to look for those?
- PufPufPuf 11mo ago"This code should look less like it does what it's doing", that's the Ruby Way™.
- montroser 11mo agoThis 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.
- jaredcwhite 11mo ago1.method(:day).source_location <= your friend was wrong 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.
- montroser 11mo agoAh, 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.
- jaredcwhite 11mo agowhoa
- bradgessler 11mo agoQuite the plot twist there
- nvader 11mo agoI'll add another cautionary word in with everyone else who is panning this implementation. This is just using operator overloading to determine keywords, but it locks you out of ever using the same type twice in your signature. Notice that :usd turns into a name. What? This is cute, but has no place in a professional software interface.
- culi 11mo ago> but it locks you out of ever using the same type twice in your signature. I don't see how you drew that conclusion. It seems to me the author provided several examples of this not being the case. Care to elucidate?
- culi 11mo agoSo the underlying assumption is that there is always at least one attribute that serves as a "discriminator" between the billing plans, right? Is it possible to represent something like this then? ```rb [:red, 1.month, 10] [:red, 1.year, 120] [:blue, 1.month, 120] [:blue, 1.year, 300] ``` Every possible attribute (name, interval, amount) has at least two objects that share a value
- brunosutic 11mo agoYour input would work exactly as you wrote it if passed to `Billing::Plan.find_or_create_all_by_attrs!`, just add commas at the end of lines. If you want to make it even shorter, you have a few options - it really just comes down to preference: # Option 1. my personal favorite, follows structure of # intervals and plans on a pricing page. 1.month => {red: 10, blue: 120}, 1.year => {red: 120, blue: 300} # Option 2. this is fine too red: {1.month => 10, 1.year => 120}, blue: {1.month => 120, 1.year => 300} # Option 3. possible and works, but hurts my brain, NOT recommended 10 => {red: 1.month}, 120 => {red: 1.year, blue: 1.month}, 300 => {blue: 1.year} > there is always at least one attribute that serves as a "discriminator" between the billing plans, right Just a note: if you try to create two plans with the same attributes, that would error because of ActiveRecord uniqueness validations (and DB constraints). No point in having multiple identical plans.