In Ruby, we often want to rename methods or attributes for clarity, to extend functionality and for compatibility. However, there are three different tools for this, each with its own use case and behavior: alias, alias_method and alias_attribute.

In this post we’ll go over each one of them, what they actually do and when to use them.

Many times, when looking at applications we have written or that we see around in repositories throughout the internet, we get this feeling that whatever we’re reading has a certain complexity too it. Sometimes this complexity is manegeable and expected. Sometime it’s not. Actually, very frequently, code can be difficult to understand and we usually describe such code as being overcomplicated, for example.

But it’s not just our understanding of written code that suffers. As expected, if code is more complex, it will also require more effort on the part of the computer to execute. And while efficient code might not necessarily be easy to understand, there is indeed such a possibility as code that is hard for humans to read and hard for hardware to compute.

However, in order to try to make things simpler and, especially, in order to coordinate within teams what is acceptable and what isn’t in terms of complexity, we need something that can help us measure complexity.

There are, of course, many metrics that can be used. In this article we’ll talk about cyclomatic complexity.

In a previous article, we listed down common culprits that led to a sub-optimal performance in Rails applications. One of the culprits was missing or incorrect indexes.

Therefore we thought it would be very useful to have a handy reference to the different kinds of indexes, when you should use them and maybe even when not to use them.

Here at FastRuby.io we always try to have our own applications in such a state that they can always be pointed to as models in terms of performance and accessibility.

One of the tools we use to achieve that is our CDN. After all, considering we have clients everywhere from the US to New Zealand, we want anyone perusing our websites to have good loading times for the pages and, especially, the assets.

However, no matter how thorough, one always misses a spot or two.

Recently, Robby Russel posted posted on Twitter asking for Heroku alternatives for small Rails apps. Since it got quite a bit of traction, I decided to explore some options and post my experiences as blog posts.

For my first post, I’ll go for one that I’ve already used in the past and liked it very much: Fly.io

I like them because they’re dead simple and have great docs. The dashboard is pretty good too, but since I’m not one to have too many requirements around my apps, the simplicity of use is what I like the most.