arkency

We rescue, modernize & scale Rails applications.

[arkency @arkency]

https://t.co/4q11KGm8h0

[arkency @arkency]

🚀RailsEventStore 2.19.1 is out.

Starting 🔫 for 3.0 — big deprecation wave: old Projection API, apply_* convention, class subscribers, RailsEventStore:: aliases, AggregateRoot::Configuration and more.

Also: functional index for as_of queries. Grab .1, not .0.

Details below👇

[RBQ Conf @rbqconf]

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

[arkency @arkency]

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.

[Szymon Fiedler 🇵🇱 @szymonfiedler]

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.

[wroclove.rb @wrocloverb]

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)

https://t.co/8QU3p5Jl9A

[Lukasz Reszke @lreszke]

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)

[Andrzej Krzywda @andrzejkrzywda]

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 😎

[Szymon Fiedler 🇵🇱 @szymonfiedler]

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.

https://t.co/2XLpdQZ0pu

[Andrzej Krzywda @andrzejkrzywda]

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.

[arkency @arkency]

Multi tenant applications with horizontal sharding and Rails Event Store - a practical guide: 🔗 https://t.co/KPhxLiSKhm

[Lukasz Reszke @lreszke]

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?
https://t.co/pooGej0f27

[Lukasz Reszke @lreszke]

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...

[arkency @arkency]

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

[Piotr @porrbass]

I've just published my first blog post https://t.co/PlSks4Etnr on the Arkency blog. Click through and read about our journey to stabilize a Rails application for our client. It was an almost 10 year old app with a microservices pattern applied in a sub-optimal way.

[Lukasz Reszke @lreszke]

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.

[Lukasz Reszke @lreszke]

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

[Lukasz Reszke @lreszke]

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.

[Lukasz Reszke @lreszke]

🔨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

[Lukasz Reszke @lreszke]

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: https://t.co/xVwdmrj0SX

#RubyOnRails #Rails #Ruby @arkency

[Lukasz Reszke @lreszke]

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 https://t.co/xVwdmrj0SX