ismaelct

6 ms·

1.
Give It Time(ismaelcelis.com)
4 points by ismaelct 1y ago|0 comments
2.
The Decide, Evolve, React Pattern in Ruby(ismaelcelis.com)
6 points by ismaelct 2y ago|0 comments
3.
by ismaelct 2y ago
Very nice
4.
by ismaelct 2y ago
I understand the sentiment but I think it's highly dependent on context. Where you work at, who you work with, org size, what the problem is, the cost and benefits of each abstraction, etc etc. I think it's our job as developers t
5.
by ismaelct 2y ago
What do you think of Ruby's built-in function composition? https://ruby-doc.org/3.2.2/Proc.html#method-i-3E-3E
6.
by ismaelct 2y ago
To be clear this is not a library. I'm just describing a pattern and a bare-bones implementation.
7.
by ismaelct 2y ago
Well spotted. Fixed. Thank you!
8.
by ismaelct 2y ago
Nice. Yes the pattern I describe in the article supports any callable too. I should point out that this is not a specific library, just a very bare-bones pattern.
9.
by ismaelct 2y ago
> If all those steps in your pipeline are defined in the same codebase I find that rule a bit arbitrary. For example, I have data-import pipelines where some steps are unique to each task, but some others are shared across tasks. Why doe
10.
by ismaelct 2y ago
I just wanted to make the either/or pun.
11.
by ismaelct 2y ago
Thanks Mitchell (big fan, btw!). Indeed! https://github.com/hashicorp/vagrant/blob/main/lib/vagrant/a... Yes, it's not a new pattern by any means, and there's many ways to "halt&q
12.
by ismaelct 2y ago
Odd to see ROP and monads as an either/or problem (see what I did there?). Most ROP implementations I've seen rely on the result monad.
13.
by ismaelct 2y ago
I'm so going to steal this
14.
by ismaelct 2y ago
Good observations, thank you. I take the point about properly delimiting the boundaries of the orchestration layer in a system. I think you're right about how that line comes across, I'll try and improve it.
15.
by ismaelct 2y ago
I tried to keep this as idiomatic to Ruby as possible. No meta-programming, no FP machinery like monads, etc. Little more to it than an array of objects and a reduce function. All plain Ruby in my book. I wonder if just using "throw :h
16.
by ismaelct 2y ago
Thanks. Where can I find your library? I'd love to compare notes!
17.
by ismaelct 2y ago
I agree with the drawbacks listed here. I would add that "careful consideration" of any pattern we use is the job description. I would further add that we should extend that thoughtfulness to the opinionated frameworks many of us
18.
by ismaelct 2y ago
Very good article, thank you. I would add that the tagline says "when used thoughtlessly". For example, I agree that using Result objects to reinvent exceptions is a bad idea. There's a reason they're called "except
19.
by ismaelct 2y ago
Amazing.
20.
by ismaelct 2y ago
What do you think of the Rack interface? Or ActiveRecord's query chaining? ex. User.where(admin: true).joins(:account).order(id: :asc) It's all versions of the same approach. And yes all of the above _can_ complicate debugging, fo
21.
by ismaelct 2y ago
I would have thought that "senior" means assessing things in context instead of falling back to truisms. "over engineering" only makes sense relative to a concrete problem you want to solve.
22.
by ismaelct 2y ago
Good observation about stack traces and abstractions. Re. your question, the pattern itself is no different than, say, Rack middleware, so you'd see similar cost and benefits. In essence you're running one callable object after th
23.
by ismaelct 2y ago
Thanks for your feedback. Out of curiosity, when you say "plain Ruby code" what do you mean, exactly? Presumably you're still making use of _some_ patterns that you think are Ok.
24.
by ismaelct 2y ago
Perhaps I phrased this badly. I don't think the entire article boils down to inheritance vs composition. But in discussing these patterns elsewhere, some of the pushback has been that many Ruby devs prefer to decompose problems via sub
25.
Practical Railway-Oriented Pipelines in Ruby(ismaelcelis.com)
67 points by ismaelct 2y ago|66 comments