alexis

Last week's article, Super Fast Rails, received many funny reactions. But for some people, that was too much.

Most of the time, optimizing a Rails application requires repeating the same techniques. For example, at the database layer, it's about creating the proper indexes, preventing 1+N queries, etc. Could we do that automatically?

Protect Rails applications against bots and brute force attacks without annoying humans.

Here are the techniques I've acquired over more than 10 years of regular load testing.

Delve into best practices for HTTP, Ruby on Rails, and databases, and discover when to adhere to the rules or when breaking them could set your code apart.

I got this idea after reading the Reflections on GoodJob for Solid Queue from Ben Sheldon, who is the author of the excellent GoodJob.

Initially underestimating the importance of some pages designed solely for search engine indexing, it caused some server congestion. By creating efficient Plain Old Ruby Objects (POROs) to load essential data and addressing the N+1 query problem by caching categories, we finally sped up those pages. The surprising lesson? Sometimes, doing less leads to more significant improvements.

Comments are often a tell that the code could be more explicit. Every time I write a comment, I refactor my code to be understandable without it. Write the code the way you would like to read it in the future.

Performances & exceptions monitoring for Ruby on Rails applications