arkency

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-a-s…

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-tenant-a…

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/rescu…

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

AI could kill your app, even if you don't use it. Since 2022 software development is no longer what it used to be. There's a new player in the game: the almighty (or scary?) LLM. Many companies have been early adopters of LLMs. Some of them are profiting from it. Some of them are selling cars for $1. I am not here to judge. Even if you haven't jumped on the LLM train yet, it may still affect your application. With the rapid growth of LLM services, there's also a rapid growth in the number of bots that crawl the data to feed them. Some of them follow internet etiquette. Some of them don't. One example is ClaudeBot. In one of our consulting jobs we were confronted with this problem. The application was dying once, or actually several times a day. Literally. One of the reasons was that ClaudeBot was scanning the application's product catalogue page, which happened to be slow. An obvious solution is to block ClaudeBot in robots.txt. But is that all? If you think about this situation, ClaudeBot, besides its greediness and fetching the data in an unpleasant way, generated a kind of stress test. And the application failed. Blocking it masked the problem. But during possible peaks (hello Black Friday), the same situation can occur. So what do you do? Well, improve the performance of the site. Slow performance is often caused by N+1 or by eagerly loading data that you don't even show.

🔨If you limit your toolbox to just hammer, then you have to use the hammer. #RailsWay is great way to quickly build a product. But when you feel that adding each new feature is painful it is time to broaden your horizons. #RubyOnRails #Rails #Ruby

You probably know the frustration when the application you are working on becomes difficult to maintain or introduce new features. This often leads to dissatisfaction among stakeholders, who may suggest decisions like changing the technology. Migrate to NodeJS, anyone? Why would that help, I have no idea. PS. This is not unique phenomenon. It exists outside of the Rails world as well. But we'll get to that. But the problem is not the technology itself. Even in 2025, I think Rails will still be a good choice and an excellent way to start building a business. Rails is fantastic for building applications. It doesn't limit you in any way. The same cannot be said for RailsWay. Common challenges with Rails include callbacks and performance issues when rendering pages. It's important to realize that the key is not the technology itself (Rails), but how we use it (e.g. with callbacks). Yes, yes... but we are already here in this... mud. If you have similar thoughts, I'd like to invite you to a webinar where I'll show you how to overcome typical Rails challenges. We will also explore whether Rails will still be a viable option in 2025. Then we'll have a Q&A session. It's all free. Does that resonate with you? Sign up for the webinar: products.arkency.com/lessons-from-a… #RubyOnRails #Rails #Ruby @arkency

Learn how to deal with problems typical for large #RubyOnRails apps Based on our experience with Rails applications, we've prepared 10 lessons that will help you avoid common problems and make your applications more maintainable and scalable. We will tell you how to deal with problems typical for Rails apps, such as: 👉 Callbacks hell 👉 Pages that take ages to render 👉 Fat models that contain few kLOC. And no. Concerns are not a good direction 👉 Hard and tedious to navigate code structure and many more! Sign up for free at products.arkency.com/lessons-from-a…

You should use this pattern whether if you follow the Rails Way or not Value Object is the pattern that you underuse So if you don't know how to implement eql? method correctly or what is shotgun surgery anti-pattern you should watch this video: youtu.be/WZlUUXv60v0

New to #EventSourcing and wondering where to get missing data for your projections? In this video we cover that topic and what to look for when you're working with projections and you need to get the data from external services. youtu.be/kBwnd3NC0eU #rubyonrails @arkency

#EventSourcing basics in #RubyOnRails (🤫 if you are not #rails developer, you can watch that too. It's transferable skill) youtu.be/lbJhvc2fIFQ

Confused by #Hotwire, #Turbo, Turbo Streaming or Turbo Frames? With @StolarczykT we got your back. In latest youtube episode on @arkency channel we explain the difference between aforementioned. youtu.be/C8I8l5nlWIk #ruby #rubyonrails #rails