What I learned from 16 days on the AllAboard Bootcamp
Abstract: I will briefly summarize what I learned about Ruby on Rails on the fantastic free bootcamp run by John Crepezzi. In short, what I’ve learnt is that Ruby is a dynamically typed, high-level, object-oriented programming language that is used by the Rails framework. Rails follows an MVC architecture. It considered an “opinionated”, forcing the developer to be organized and logical in their code structure and naming conventions. There are strict rules that can’t be broken and this allows beginners to learn good software engineering practice right from the start of their learning pathway. I also found out that Rubyists are very passionate about Ruby and Rails! The framework/language combo allows for very fast development times and comes with security and scalability in mind. Ruby runs on the server and as such is really a backend language that renders html to the end points. I’ve only recently heard of server-side rendering in the JS world, but it seems as if you get the benefits of server-side rendering for free with RoR (along with much else). Having said that, JS is the only language that runs on the browser, so if you want to do fancy time-based user-interactions on your website, such as 3D games, you still need to know JS to a greater or lesser extent depending on the use-case.
In summary I’m going to present the MVC architecture, ORMs, and the basic structure of an RoR app.
MVC Architecture
MVC stands for model-view-controller. When I first heard this term it seemed impossible to grasp. However, after John’s explanation, I think it clicked. Let’s go through each term and what it means before exploring the entire concept. But first, let me share: I always have to think of a computer program fundamentally as a person with a blackboard pointer reading through instructions and then carrying out the instructions that the computer program has set out. If all the instructions were written in one long sentence, without paragraphs, chapters and sections, it would still be easy for the computer to execute, but it would be very hard for a human to follow and understand, much less, edit, update and maintain. So code is grouped into functions, classes, modules and so on. Furthermore, these collections of functions and classes are separated into larger contructs that interlink with one another. And this is what I learnt is the meaning of architecture in CS (coming from an actual Architecture background it was a mystery also for a long time). So in order to understand what is an MVC, let’s unpack it into its component parts.
Model — the model is the part of the software app that represents the data stored in the database. Most apps have a database or store of information which combines field names with values. This is where the data of the business is stored and represents the latest “state” of the app. The data can be collected into rows/records of a table or files in a folder. The model is then how that data is represented in computer memory in the form of classes. (cf ORMs section below) It is the conceptual model (or data model) that explains the relationships between the different tables or resources that together represent the real-world system. It is also the means by which the app (cf controller below) retrieves the data from the data store.
View — the view is the part of the app responsible for rendering what the end-user sees and hears on their device. This code is mostly written in HTML with the help of CSS and JS. It includes, the layout, look-and-feel of the app and all the instructions the computer needs to create a functional, useable and beautiful user interface and user experience (or UI/UX). In many cases it may ultimately also be composed of a hierarchy of classes or components under it’s own framework or api.
Controller — the controller is the main brain of the app, it is the glue that binds the data store to the user interface through the use of the data model. The controller is where all the code is written that determines which pieces of data need to be sent to the UI for rendering and when (also how and for whom). It is also linked closely to the endpoints (or routes). The backend computer (or server) looks at the router to see which actions to execute when a client machine (or front-end) browser hits a particular url. The actions are executed by the controller, which mostly include an instruction to render a particular view with specific data from the data store by way of the data model. In reverse, it also takes user inputs and issues updates to the data store.
Altogether these three parts of the code create clear and logical software layers that help the developer to separate and structure their code in a legible and maintainable way. Each layer communicates with the other layers to create a complete software application (or app). So instead of one person reading through a very long sentence with one pointing stick, it’s as if you have a team of football players passing the ball between themselves to keep the software running as expected. I look forward to learning about the other forms of software architecture used in web development.
ORMs
Now that we have seen what a model is and does, it should be easier to understand what is an ORM and what is its purpose. ORM stand for object relational mapper. I have found the following article to be really helpful in explaining what is an ORM and what are its advantages. TL;DR it is the model in the MVC architecture.
https://blog.bitsrc.io/what-is-an-orm-and-why-you-should-use-it-b2b6f75f5e2a
App Structure
So, the structure of a Rails app seems super complicated at first. After you first hit `$rails new` a bunch of files and folders are created that make up the structure of your app. However, armed with the knowledge of MVC, things get a little simpler. It also helps to know that there are only a handful of files and folders that a beginner developer needs to edit in order to create their app. They are as follows:
routes
migrations
models
controllers
views
css
javascript