Today was the first time when I used @AmpCode as part of our „AI-native Rails” training arkency.com/ai-native-rails/

my new ProcessManager gem - finally, the most important DDD building block is simpler to create blog.arkency.com/3-example-p…

Rails Event Store 3.0 is out — a cleanup release: every API deprecated in 2.x is gone. Plus two new tools. 3.0: blog.arkency.com/whats-new-i… res CLI: blog.arkency.com/res-cli res-mcp: blog.arkency.com/res-mcp-ser…

I strongly agree with Weaver's "Callbacks Are Not Invariants": callbacks can't keep their promise, writes go through one door. The ingress doesn't own the invariant. The aggregate does. And the persisted fact, not the outbox, makes effects recoverable. blog.arkency.com/ingress-is-…

Szymon shows us how mutation testing and Mutant gem can help increase confidence in a code base we’re less and less confident in. #RBQConf

Meet @szymonfiedler at the @rbqconf! Szymon will show how Mutant reveals blind spots in test coverage by introducing bugs into your code. If your tests still pass, that’s a signal worth paying attention to. Expect real code, real mutations, and real insights.

Your tests are🟢 Would they catch a flipped condition? I'm speaking at @rbqconf in Texas 2026: "Would Your Tests Catch This Bug? A Mutation Testing Story" Real Ruby code. Real mutations. Uncomfortable results.

There would be no wroclove.rb without our amazing supporters💫 @Arkency has been with us since the very first edition, and we’re extremely grateful to have them on board again this year - thank you for making our conference possible since day one! (1/3) arkency.com

Tip for #RailsEventStore: use `in_stream("stream_name")` in your event assertions: `expect { ... }.to publish(an_event(X)).in_stream("orders")` Super helpful once you start using mutation testing (which runs your tests in parallel)

deja-vu moment in 2007 a nontechnical client sent me an app which he just needed to deploy because he vibe coded it on his own (this is a story how @arkency started btw because he suggested this name) today in 2026 a nontechnical client sent me an app which he thinks is ready to be deployed because he vibe coded it in 2007 the equivalent of vibe coding was Rails of course at none of this case it was only about deployment, the apps need some fixing fun times again 😎

Ruby 3.4 warnings led me to refactor 100+ Slack message methods. What started as a frozen string literal fix ended with a 20-line class that sparked joy. Sometimes the simplest abstractions are the most satisfying. blog.arkency.com/the-joy-of-…

Pessimistic architecture - that was my thought when reading this book. Non-functional requirements are often ignored by architects and programmers. Yet, it's them which can kill your app and your business. Residuality is a concept described by Barry O'Reilly, a very intriguing set of heuristics to help build an architecture that can survive many "stressors". Looking forward to find stressors and build the matrix for our current projects. If you need a challenge to your current architectual status quo - this might be the book to read. I recommend to read it in the form of a book reading club, as we did at @arkency - the concepts are not so easy to digest alone.

Multi tenant applications with horizontal sharding and Rails Event Store - a practical guide: 🔗 blog.arkency.com/multi-tenan…

Pretty happy with my narration for the Rewrite vs Modernize webinar In most cases modernization is a better option. But why? How to convince the management? What are the best techniques you should know if you need to do the modernization? See you there? arkency.com/webinars/rescuin…

If you have problems with your monolithic architecture then you have problem with one app. Once you switch to microservices you might improve the overall state or.. end up with same problem across multiple apps. Or even worse. We faced the worse. Turns out...

Interesting story from @porrbass about how an unusual #RubyOnRails application setup caused outages.

There are couple of drawbacks of keeping the logic outside of the model. Might be interesting for you if you follow Service Object (anti?)pattern Disclaimer: I am not fan of fat model either The drawbacks are: - Business logic has to be kept in sync between services (ie. empty order cannot be submitted). If the logic is not the same in every service then the system can be put into an invalid state. If you keep the business logic in the model then you don't have to deal with that. Objects should have behaviours. - Business (domain) logic is mixed with application level logic - Unit tests are harder to write, so you either end up with higher-level tests that run with database (slower) or you mock dependencies (lame) - It's harder to test important aspects of the class - assume you don't have time to get to 100% code coverage. Having the logic in the model class allows you to test the most important business rules that must be fulfilled and make sure that those are respected.

Debugging a problem after a batch of commits has been pushed into production can be challenging. I bet you have git installed on your machine. It is not obvious to everyone that you can use git's bisect feature to find the change that caused the bug faster. 1. Find the commit without the problem you are debugging and save the hash. 2. Run `git bisect start'. 3. Mark the HEAD as "bad 4. Mark working commit as "good 5. Run your test (whether manual or automatic) 6. Mark the hash as good or bad To mark as good or bad, type `git bisect good | bad'. #RubyOnRails #debugging