The Magic of Rails
The Rails Project deliverable within Flatiron School’s Software Engineering Program is the culmination of a module spent deep diving into Rails. Anyone who has even slightly flirted with programming over the last ten to fifteen years has heard of Rails. Rails is a framework written in the Ruby language that both supports and enforces a model-view-controller (MVC) program and logic flow. It is a framework of convention. In addition to convention and standards, a lot of the strength and appeal of Rails is that it provides access to many ‘gems’. A gem is basically a program that accomplishes a very specific task — it could be password security, user authentication, different ways to retrieve and manipulate database data, building out a framework for an application. The variations are, quite literally, countless. The library of Rails gems expands daily. Gems allow developers to incorporate specific functionality into programs and projects without really having to know the details of how that functionality is achieved.
In addition to gems, Rails interacts with and wraps around ActiveRecord, which provides a structured approach to interacting with a database. It is through ActiveRecord that developers define how tables relate to each other. Those relationships provide ‘mining’, manipulation, and presentation of data, again, in countless ways.
As I worked through this project, I repeatedly encountered references to the ‘magic’ of Rails. Because of the gems that are available and the ActiveRecord functionality, Rails has a mystique to it, an expectation that it will magically perform functions and routines with minimal input or direction from either the developer or the user. As I searched for methods, helpers, or information on error messages throughout the project, I consistently encountered references to the ‘magic’ of Rails. Some posts or articles would end with ‘. . . and that’s it! Because of the magic of Rails — it takes care of everything!’ The most common perception seemed to be that this was a positive and powerful component — who doesn’t like a little magic in their life? Especially of the helpful variety?
What I found was, actually, just the opposite! I didn’t really realize it as I went through this process, but I came to believe that no one really understood what exactly Rails does or provides — it just does it and it’s wonderful! But it became significantly not wonderful when it didn’t perform as I expected it to or as I thought it should. To be quite dramatic, I started feeling like I had little agency when it came to Rails — it either performed for me or it didn’t — that’s how magic is. Late into the project, I felt defeated — the magic wasn’t working for me. As magic tends to be, it felt obscure, dubious, and always just out of reach. I felt like there was some secret that I had missed somehow in all of the labs, that I had yet to discover on the internet. Whatever and wherever it was, it was closely guarded. Obviously, it only unveiled itself to the most fortunate few — I was not among them.
I expressed my defeat to my instructor/cohort lead. Her reaction was a bit surprising. She asked me to walk her through my application, my data models and logic flow. She pointed out where I might consider restructuring my forms — redistributing some of the nested logic so I didn’t have three or more levels of ‘nestedness’ on one form. Basically, she was telling me to make it make sense. She dispelled the magic and I had my agency back. It was logical — there was no secret that I had to know the specific search terms for to unlock — there is only logic. It was a huge take-my-power-back moment for me (actually it was more like a day as opposed to a moment).
Rails isn’t magic. It is logic bundled in method wrappers that are there to allow us to get the most out of our programs and systems. When things aren’t working as we expect, there is always a logical reason. My huge take-away is to not look for the magic but always follow the logic.
