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.
I think its probably fair to say that we as individual developers are always going to push for the thing we are most familiar and comfortable with. Almost nothing is "complicated" or "bloated" if you are really productive with it and know all the pain points to avoid. My experience with Java is that the language is great, but the ecosystem and tooling is where the bloat and complexity comes in. If I were really accustomed to this ecosystem then I probably wouldn't hold this opinion.
Yeah, just run away from Spring or JBoss. I'd probably jump to something else too if forced to wait 3 minutes for something to even compile.
Kind of difficult as you will always see those kids trying all kinds of magic with a language instead of razor sharp focus on the problem itself to be solved.
Anyways, I guess everyone passes through those phases of growth. Also unreasonable to remain like a dinosaur refusing to learn what else new is coming up.
I started in PHP land 20+ years ago, moved into Ruby for the next 10, and now am firmly in JS/Node land. I have used Postgres nearly the entire time. It's my experience that you will never go wrong picking Postgres as your primary data store. Love that DB.
