software-development
Risk management for engineers, without the vibes: use expected value to judge a rewrite, spot base rate neglect and sunk cost in tech choices, apply Bayesian thinking during outages, and price technical debt with a four-step calculation you can run today.
ai
AI agent architecture comes down to three strategies: single agent, sequential, and parallel. When one big prompt loses the plot, how sequential chains buy reliability, where parallel agents crush latency, and the pitfalls of each before you commit.
ruby-on-rails
Structured logging lands in Rails 8.1 with the Rails.event API. How the Structured Event Reporter replaces regex-parsed log lines with JSON events, plus tags, context, schemas, debug mode, and how to subscribe and test events in your own app.
Ruby::Box in Ruby 4.0 isolates monkey patches so one gem's core-class override stops breaking the rest of your process. How the isolation works, what problems with global state it ends, and the limitations to weigh before you rely on it.
Technical debt is not the real enemy: cognitive load is. Why messy abstractions hurt because of what they do to your brain, how the database quietly kills flow, and how to stop chasing code cleanliness for its own sake and start delivering again.
OpenAI serves over 800 million weekly ChatGPT users without database sharding. Inside the architecture: a single primary PostgreSQL, cascading read replicas, aggressive caching against thundering herds, and connection pooling pushed to its limits.
Snapshot databases only show the current mess, not who knocked over the chair. Event sourcing explained through an investigation lens: anatomy of an event, state recreation as time travel, why audit tables are a dead end, and the honest cost of eventual consistency.
Zanzibar is how Google authorises billions of shared resources across Drive, YouTube and Calendar. A look at its relationship-based data model, the new enemy problem that forces strict consistency, and the Leopard system that keeps checks fast.
Manager vs leader is not a job title question but five everyday behaviours: hoarding information vs sharing context, rules as weapons vs guardrails, handling mistakes and exits, radical honesty, and whether you want yes-men or constructive conflict.
Ruby modules often beat classes for service objects: why a shell class like PasswordResetInitiator is procedural code in disguise, using a module as a toolbox, mixins instead of artificial inheritance, and Data objects for tidy parameters.
Microservices promise independence and deliver network calls where method calls used to be. Why small and medium teams pay the highest price: chaos scaling instead of product scaling, lost shared context, operational overhead, and the way back to sanity.
Ruby 4.0 marks the language's 30th birthday with maturity instead of revolution: saner syntax for multiline conditions, faster boot with fewer requires, a maturing Ractor story, hidden performance gems, and protection against command injection.
Event sourcing meets GDPR the moment a user asks to be forgotten and your log is append-only. Crypto-shredding is the elegant answer: encrypt personal data per user, delete the key, and design system boundaries so backups and read models forget too.
Business archetypes prove your 'unique' domain is usually a store selling something unusual. Map complex requirements onto universal building blocks: product catalogue, orders, entitlements, inventory for services, party and billing, and stop reinventing the wheel.
Pseudo-modularity looks like clean folders and rots underneath: a change in Products breaks Inventory tests and blocks three teams. Why noun-driven modules and a shared database create facade modularity, and what real module boundaries look like.
Party archetype fixes the 120-column User god object: model people and companies as parties, roles as context instead of identity, and relationships as first-class entities, so a customer who becomes a B2B partner no longer needs an is_partner flag and prayer.
A distributed monolith is what you get when microservice boundaries are drawn wrong. How to design autonomous modules in three phases: business analysis for boundaries, tight communication contracts, and deployment decisions driven by real architectural drivers.
CUPID challenges SOLID with properties instead of rules: composable, Unix philosophy, predictable, idiomatic, domain-based. Where the decades-old principles show their age in the cloud era, what 'joyful software' means, and whether SOLID is really done.
SAFe explained without marketing slogans: why the Scaled Agile Framework exists, its four pillars, Agile Release Trains, the role architecture, PI Planning as the heart of the system, and the real risk of rigid agility when fifty teams try to move as one.
Race conditions in read models are the price of parallel event-driven systems. How to handle events arriving out of order: treat the read model as an anti-corruption layer, separate facts from rumours, and build projections that survive an effect arriving before its cause.
Module boundaries should come from simulation, not subdomain divination. An engineering method for DDD: optimise for modifiability, simulate realistic changes against candidate boundaries, prove the split with stable contracts, and explain it to the business.
Event-driven architecture with Kafka can still be a distributed monolith. The anti-patterns that get you there: CRUD sourcing, property sourcing, clickbait events, missing commands, and the fixes: rich events, outbox, internal vs external events, anti-corruption layers.
Not all events are equal: domain events, Event Carried State Transfer, notification events and the Claim Check pattern each serve a different job. A typology of what you are really sending, plus the event vs command distinction that prevents architectural chaos.