BNCC x GO-JEK Boot Camp (Day 2: Introduction to Ruby on Rails)
On the second tech session with GO-JEK, all the members of BNCC had the opportunity to learn Ruby on Rails with Mr Iqbal, one of the engineers in GO-JEK. Since none of us had actually experienced Ruby, we were given a brief introduction.
Firstly, the Driving-a-Car philosophy. Mr Iqbal said that learning Ruby is like driving a car. In the beginning, you don’t really want to know what’s under the hood. You first want to learn how to drive from point A to B. Only after you that, you become interested in knowing what’s under the hood. Knowing in depth might help you in case the car breaks down, right?
Enough about philosophy, we then jumped straight to experimenting Ruby by using the console, or Terminal. For our first app, we made a web app similar to GO-FOOD. Step-by-step from the scratch to being able to access our app in localhost:3000.
In this session, not only we learned how to make our first app, but also learned how to play with Git. To some of us who have never used this, this is a very simple yet useful task. We then learned how to make our first commit, usually known as Initial Commit. Before proceeding, we had to make a repository first and we used GitHub. After making the repository and committing, we then pushed it into our GitHub repository. When you access your GitHub repository, you will be able to see your Rails application that you have just pushed.
The Architecture of Rails Application
Using Rails, we had to be familiar with the term MVC. The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller.
Models are responsible for maintaining the state of the application. It could be few interactions with the user, it could be permanent and stored outside of the application, often in a database. In Rails, Models are Ruby classes. Models talk to database. It performs business logic, validates, and stores data to the database.
Views are responsible for generating a user interface. Rails support multiple format of Views. You can choose to output your data in the form of HTML, complete with the CSS and JavaScript, XML, JSON, or even some downloadable formats like XLS, CSV, or PDF.
Controllers orchestrate the interaction between Views and Models. They receive events from user, interact with the model, and call the appropriate view to display the result to the user. Controllers are also responsible for parsing requests and handling data submissions, cookies, and sessions.
This is a diagram of how MVC works in a typical Rails application:
Rails provides us with Object-Relational Mapping (ORM) libraries that map databases tables to Ruby classes. For instance, if we have a table called “foods”, our Rails app will have a class named “Food”. The default ORM provided by Rails is called ActiveRecord. It provides us with class-level methods to perform table-level operations. More of ActiveRecord, check out: this link.
Moving on, we were taught to make our first controller. By executing a command, it automatically generated a bunch of files. Some may end with “.rb”, meaning Ruby files, and some other files with other extensions. When we make changes in the code, do not forget to commit. Committing your current progress and push it to your repository is like saving your files somewhere else. If you work in teams, other members can also see your work progress.
In Ruby, you can also modify your application using HTML with “.erb” extension, meaning “Embedded Ruby”. So, we played with the code and learned how to execute Ruby code in HTML templates.
The Simplified GO-FOOD Web App (Iteration 1)
The first thing we need for a GO-FOOD web application to work is some basic feature that enables us to store foods data and view it to the users. For this, we did a simple scaffold.
rails generate scaffold Food name:string description:text image_url:string price:decimal
Remember when I said Rails generated a lot of files for us? Then it’s time to redefine the migration. After redefining, don’t forget to apply the migration. Play a bit with the code and take a look at the form.
When you scaffold the whole MVC, Rails actually provided you with a lot of template views, which means you can also experiment with it, even by adding some styles using the stylesheet provided, the “.scss” file. Not only style, but also layout, take a look at some of the Rails Helper methods that we used.
- To help alternating style between odd rows and even rows in HTML table, use “cycle” method.
- To display only the first n-characters from our food’s description, use “truncate” method.
- To remove all HTML tags from our food’s description, use “strip_tags” method.
- To show a confirmation pop up whenever user clicks “Destroy” link, we use “link_to” method with “data: { confirm: ‘Are you sure?’ }”.
The Rails Doctrine
After experimenting with the code, we then jumped again into the more theoretical one. In Ruby, there is a principle, or a belief, called The Rails Doctrine. What is it and what is it for?
1. Optimise for Programmer Happiness
As Ruby was built with programmer happiness as priority, Rails inherits this principle too. Like Ruby, Rails also presents a programming language that seems simple, clear, and beautiful to our mind’s eye. For example, Rails understands enough English language to know that when you create a model class named “Person”, Rails will know that the plural form of it is “People” and therefore can map your “Person” class to “PeopleController” class.
2. Convention over Configuration
Rails is full of conventions, such as:
All models should be named in singular form (Person)
All controllers should be named in plural form (PeopleController)
Primary key should be named as just “id”
Foreign key should be named like “person_id”, etc
3. The Menu is Omakase
Omakase means “I’ll leave it up to you”, or you just trust the chef for the recommended meals because you will know it’s good. For programming, letting others assemble your stack, is similar to the previous principle. But, Omakase is more concerned with how we best use which frameworks and how they fit together. Unlike Convention over Configuration that focuses more on the individual framework.
4. No One Paradigm
Rails isn’t ideologically a single, perfect cut of cloth. It’s a composite of many different ideas and even paradigms.
5. Exalt Beautiful Code
Ruby language is written in plain simple English. Even if you don’t understand it, you can still read the code. Beautiful code is not just about aesthetically pleasing block of codes, it is about simplicity and understandability.
6. Provide Sharp Knives
Do you know that we can replace existing methods of core Ruby class? It is considered a dangerous practice but it gives a lot of these sharp knives. Ruby on Rails is an environment for chefs and those who wish to become chefs. You might start out doing the dishes, but you can work your way up to running the kitchen.
7. Value Integrated System
Rails was developed to build a full stack application. It does everything from how the front-end is served with CSS and JavaScript, to how the database is integrated from one another. But Rails can also be used as a back-end only application that provides APIs for different front-end application.
8. Progress over Stability
Rails value progress over stability, to give us the strength to debug the busted, figure it out, and move with the times. As changes are made to progress, even if it involves breaking the things that used to work.
9. Push Up a Big Tent
As the “No Single Paradigm” principle stated, Rails accepts different paradigm and ideology. Rather than trying to make everyone agree on everything, Rails welcome disagreement and diversity of thought. The creator even hates RSPec, but the community continues to flourish and widely uses it.
The day ended with us, learning the basic of Ruby on Rails, the architecture of Rails application, as well as the Rails Doctrine. Hopefully, we will create more useful or perhaps impactful application in the future.
