Yes. I simply hope the commenter reflects and doesn’t use a gender next time if there is no evidence of gender. That’s simply it. In 2025 I don’t feel it is appropriate for a commenter to use the pronoun “him” when there is no evidence of gender, and there isn’t at the time of comment.
Who cares about the gender pronoun, it's just a commenter online. The content is why we are reading. The author could be male, female or a bot. Not important, not relevant.
I was there a few years ago and will echo the fact that the folks I interacted with at the museum of computing were truly world class fantastic. When someone loves what they do and where they are it really shows.
I might be a bit biased (I wrote and maintain a similar gem), but I think this is a great pattern that solves a real problem that is encountered and does so in a very Ruby kinda way. I particularly like the mental model of stringing together multiple service objects into a "pipeline" and the semantics chosen for the API. Kudos to OP for putting this out there!
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.
I'd like to think this is kind of just the cost of discovering that 1 pattern out of many thousands that is actually useful. I am going to guess the Gang of Four didn't just sit down and bang out the entire catalog of design patterns in one extremely productive programming session. They likely battle tested hundreds of different patterns, most of them being thrown out as not useful or a bad abstraction before arriving at the set they published in the book.
It’s not an actual crime, but If it’s an online multiplayer game it is a violation of the terms of service. Add to that it tends to ruin other people’s enjoyment of the service, thus negating the main purpose of the service. I think people who cheat in online games are pretty sad, pathetic, and selfish.
It probably works ok for a solo project but IME with large scale codebases snapshot tests are awful. You update some implementation detail of a common shared component and suddenly 5000 tests break despite the look and behavior being unchanged.
Give me an example. Those components depend on this common shared component... if you do something that changes that shared component in such a way that it causes other snapshots to fail, I'd absolutely want to know about it. That's the whole point of dependency failures.
My dependency is on MUI, which is a massively used common shared component library. If MUI changes, and it breaks my snapshots, I'd absolutely want to know about it.
This has been my experience in the past with a heavily snapshot covered codebase. Class names can change, the structure of your HTML can change, the underlying CSS can even change and the end result is still the same because you were just refactoring. At a large enough scale it can be painful to have hundreds of snapshots break for a simple change - especially when you add required code review by others into the mix.
Currently figuring out a strategy for introducing testing into an already large codebase and being very cautious of snapshot tests because of this. Experimenting with visual regression testing but early indicators suggest it could get very expensive if we're not careful about what is covered.
