u/keyslemur
-
18points
-
23points
Rails: The Sharp Parts. The Block Is Not the Transaction (baweaver.com) [Blog post]
-
102points
Beyond Senior - Creating Hope (baweaver.com)
-
1points
Tales of the Autistic Developer - Panic (baweaver.com) [Shutdown/Meltdowns]
-
3points
GemCP - MCP tools for RubyGems (github.com)
-
35points
-
23points
A Rubyist in Go Land: Your First Pokémon API Client (baweaver.com)
-
14points
Beyond Enumerable: Testing Membership with Bloom Filters (baweaver.com) [Blog post]
-
3points
Ozymandias on Rails. Cartography of a Ruin (baweaver.com)
-
7points
Ozymandias on Rails. Cartography of a Ruin (baweaver.com)
keyslemur
keyslemur
It was used heavily at Gusto when I was there, somewhat at OneMedical, and now a good deal at GitHub where I'm at now. All three are fairly large rails monoliths.
With AI agents it's been useful to make more explicit contracts especially when refactoring or planning larger moves which is a lot of the work I end up doing.
keyslemur
I'll give it a look.
keyslemur
That one was directly me.
keyslemur
....of course I didn't catch that in the title. I use AI to riff and scaffold but most things are either AIL 1 or 2, or rather 95%+ written by me. It's also something I have as a rule for Claude not to use language like that but I suppose it snuck in on the title.
keyslemur
Then keep reading in that section and see what you find there.
I'll give you a hint: Transactional outboxes and not using them for anything you need guaranteed, and a reference to an entire callbacks article that mentions those concerns.
keyslemur
In general double breasted coats are chancy for thin folks, height aside. As a tall thin a double swallows me where a single fits well.
That said unbuttoned with a good pair of brown boots would go well.
keyslemur
I get the intention, and I agree that a fork is likely not going to go anywhere like the last few, but I feel that the case being made here is very light and is not compelling on its own.
There would be more value here if instead you went into a few things that Hanami does better, what lessons it learned from, how specifically it does it better, and why the route is to start building it up as a viable competitor. There's a litany of more useful and detailed articles to be written on Hanami, and for me this one misses the mark. In the spirit of "put up or shut up" though I may start writing a few myself soon.
I also have an allergic reaction to words and phrases like woke and virtue signaling as pejoratives that provide little to no value, even when used ironically, to describe the substance of a disagreement. I'm also fairly onboard with Godwin's Second Law that folks using woke as a pejorative are not to be taken seriously (he uses stronger language.)
Disclaimer: I am a financial sponsor of Hanami, and have been for a few years, because I believe in the work they do.
keyslemur
Chat
keyslemur
Having seen engineers bikeshed about style on every single PR at a few past companies Rubocop or standardrb or rubyfmt are now effective requirements for any decently sized org. Not because ruby's flexibility is wrong, but because there are much more important things to argue about and solve than what particular quoting or indentation patterns someone prefers.
Phrased another way I've seen teams burn weeks on lint and style arguments when their SLOs for customers were redlining. Priorities are important and linters remove a contentious distraction early and effectively.
keyslemur
Yeah you and I agree on a lot here, and a lot of this series is trying to put that into words. Organizational ADHD and incentives are something I plan to cover in some detail, as I firmly believe that a significant number of problems are far more sociopolitical than they are code based.
It feels better to make the plan and rally the troops to the starting line than it does to actually run the marathon to see it done.
keyslemur
Feedback always welcome, sometimes I get on auto-pilot mode while writing and forget to step back and make a few of my terms clear.
keyslemur
Fair points, amended: https://github.com/baweaver/portfolio/commit/0291131aa4e839513cc2625487dc9615e558449e
keyslemur
As an amusing aside: One of my brothers' friends has a ringtone that's the PagerDuty alert sound, and he keeps volume on. After the third time or so of me jumping out of my skin when he got a text I'd thankfully convinced him to change it.
keyslemur
....how did I never make that connection before?
Interesting, I will have to give this some more thought later, but on an initial read I think you're scratching an itch I've had with Packwerk which is that it tends far more towards polite enforcement rather than hard boundaries.
The danger, though, is that by going all the way to isolation the rungs of the ladder you might have had with Packwerk to progressively isolate are sawed off. It's very all-of-nothing, which is the same weakness that Ruby::Box will have used in Rails apps. Having worked now in several of the largest Rails monoliths not having a progressive ladder is a surefire way to have something lose funding and effectiveness. Packwerk is not perfect at this, no, but it feels like the framework is at least somewhat guiding you rather than providing an end state.
Where I could see this going is potentially isolate deploys, hotswap restarts (ala Erlang / Elixir), tree shaking CI tests, substantially easier dead code identification, and done well with layering a way to break down the worst ActiveRecord entanglements by progressively isolating "data" from "domain".
Depending on your tolerances for AI you could also include a series of agent skills that make migrations towards this endstate substantially cheaper for folks.
Will give this some more thought and sit on it for a bit, but interesting start.