The concept of ‘Convention over Configuration’, at the time it was introduced, felt, viscerally, like a reaction to other frameworks. Despite being built within a Framework, many applications could vary wildly, depending on the knowledge and the personality of the creator. This made it much more likely that a developer would perhaps spend a lot of time learning the application. In some cases, the only way to work on an application was to edit it directly on a test server, severely limiting scalability of the development team. Rails attempted to free the developer from having to know very much, and to be able to easily develop their application in a local environment, by making a series of decisions for that developer, and ensuring that, in general, rails was agnostic to its environment. By forcing the developer down this path, it becomes more possible to create an environment where the application can scale with the knowledge of the developer. Rails has tried to remove itself as the bottleneck, by following conventions that can allow the developer to learn just the things that matter in a given moment, rather than having to understand the entire infrastructure before they can begin to add value to the application.

Over time, Rails has maintained that central goal; empowering a single developer, without much knowledge of servers, databases, CSS, JavaScript, or any number of other such tech, to be able to build a website, using all these tools, by relying on convention.

But can that really be done? As a new developer, with relatively little experience, it becomes very easy to take Rails off the .. well, off the Rails.

Train metaphors are cool.

So that’s what we’re talking about. The most dire, villainous traps that Rails lays out. The potholes that almost any developer will eventually stumble into, neatly snapping their metaphorical ankle. The goal of Rails for Villains is to create straightforward explanation, that delves into just enough Rails history and context, to pass on the hard-won experience most Rails developers have had to earn the hard way. Normally, the new Rails developer would learn about these pitfalls in their first job, where they would leave behind a trail of malformed Rails applications, which have become very difficult to work with. This is really possible; the market for junior developers is pretty high, but the market demand for a Rails developer with three or more years of experience is really high! It’s very easy to move on from the company where we make those beginner mistakes. The newbie Rails developer typically learns now not to paint themselves into a corner by painting themselves into a corner, then moving on to a new, clean house. My goal here is to maybe help people delay the day they end up doing that.