1.0 release with some updates to ensure that keyword arguments work properly. It drops support below ruby 2.7 because it uses argument forwarding (...)
This would probably be a great fit over at a more business-focused site, like barnacles!
didn’t know where to put this exactly but I’m surprised that lobste.rs doesn’t have a space for it. oh well!
One wonders why the author doesn’t just update their version of Ruby. If they have dependencies, they would be better spent spending those cycles submitting upstream patches than leaving weird hacks in place to ambush the next poor bastard to have to maintain the codebase.
You know what else offers similar features to Polyfill? The latest version of Ruby.
He’s building a library and wanted that library to support Ruby 1.9, not just 2.0+.
I probably wasn’t explicit enough in the article but it’s not uncommon to have a situation where just updating Ruby isn’t that simple.
Is this meant to be a parody of rails coders? Might need a tag.
I don’t think it’s a parody, and I believe that Jim has been thinking about this stuff for a while. I think his approach emphasises the object in OOP, and he adds behaviour directly to objects as and where required.
If anything, the idea of improving locality through organising code by features is intriguing. I’m not sure about the implementation, I haven’t looked at it closely. I also have misgivings about it because even in a regular OOP setup, everybody usually starts out by aligning classes closely with features, but it doesn’t last long because features interact, and the complexity of interaction between them starts to ripple through the code, leading to the situation described in the post where different parts of the code pertaining to a single feature are strewn through the code base.
Yup. Controlling locality has been the best thing I’ve done for my projects.
If a new developer jumps in, it is much easier to communicate about the features because the behavior necessary is in one place.
Because people typically align their data classes with all the behavior necessary for a feature, the implementation gets smeared across the application. Cleavage points between what belongs together and what does not becomes harder to understand.
So, I like the article, and I REALLY like the idea of making your code be so expressive that it reads almost like english.
I’d like to see more however about how this dovetails with creating effective teams, and maybe how this also interacts with team culture and the principles your team ‘live’ by.
Thanks! I plan to write more about this
The examples are all written against the Que library but using DelayedJob solves the problems you’re writing about without the need to write or rearrange any code.
I guess I just don’t understand why the ACID guarantees that Que provides make it the better choice in this case.
Que was just a library to do the work. There’s nothing in this related to ACID guarantees.
Decided to try to support my family (6 of us) as a sole breadwinner with my products. Lost lots of sleep over it but this weekend was great personally and for my business.
I’m trying to wrap up the final content for my recent product Ruby DSL Handbook and will be recording screencasts about building DSLs with Ruby. http://clean-ruby.com/dsl
Kids broke my microphone so I’ll be shipping with whatever audio quality I can get.
Wow, you’re able to make a living on a Ruby book? While wrangling children? Respect.
Nope. Not yet. But I’m trying so hard. Basically I’m lighting a fire to make it happen