| Skills to Practice | https://skillstopractice.com |
| Bug Hunt : Volume 1 | https://bh-1.skillstopractice.com/START.html |
| Ruby + Rails : Distilled | https://ruby.social/@distilled |
One of the best exercises you can do in Ruby to expand your understanding of web development better is to try to build some small toy projects directly on top of Rack.
It may seem unapproachable at first, but you'd be surprised. Excellent practice for anyone at least comfortable at an intermediate level w. Rails or any other similar framework.
It reveals how much established patterns are not hard and fast rules or settled science, just the things we've gotten used to.
Pretty much every web framework I've ever used is not even remotely structured like a web, and I'm increasingly finding that weird.
In fact, they're not even web-focused in their architecture. They're organized around databases, assets, dependency management, etc.
A web framework should look and feel like a well built web app.
Complicated thought, but one I've been trying to build a mental model around.
I don't really think much these days about methodologies, whether it's Agile, Lean, or whatever.
Instead, I mostly follow some universal principles:
-- Cost of Delay
(Value and urgency over fixed costs and dates)
-- Pareto Efficiencies
(Asymmetric bets over micro-optimizations)
-- Kaizen
(Continuous process improvement over disruption)
-- Autonomation
(Data-informed human decisions over opaque algorithmic rigidity)
-- Validated Learning
(Build / Measure / Learn over Fortune Telling )
Sometimes it's easy to give yourself rules like "Don't use monkey patches" and then they become so rigid that you don't even think of the context.
No, a monkeypatch is not a reliable way to fix an issue in production code.
But as a way to inject logging and to explore what's going wrong in code you didn't write? It's so expedient!
Go to the source, copy-paste the one method, play around.
Sometimes the sharp knives of a language are exactly what you need to get something useful done.
Today I stumbled across a fun way to debug things when you may have come across a library or framework bug.
I usually assume problems are in my code, and they usually are. But in some cases, dependencies are indeed the source of bugs and I'll typically read their source to diagnose.
But then I don't want to bother building the full library to try out a fix or even just get better logging.
This is where monkey patching is actually an awesome feature!
Insert logging, tinker with a fix, etc.
#TIL hanami-router is usable standalone and on its own feels a bit like a mini version of Sinatra where every route is a Rack protocol compatible response.
This handles a lot of the use cases I would typically lean on Sinatra for.
S2P-2026-02
You'll break stuff (at any speed)
https://skillstopractice.com/posts/youll-break-stuff-at-any-speed
I recommend checking out Alpine.js even if you don't intend to use it in production. Just to see what a simple mental model it offers.
These are incredibly strong abstractions without sacrificing simplicity.
Hope sooner or later something like this is built into the browser.
By the end of 2026 I want to write at least 32 short essays on a range of topics... but mostly about how we build things and the human experience of building things.
I'll post each essay to this thread when it's ready to share.
