Humans are continuously making decisions about their personal and professional life. Decisions are made based on previous experiences, other people's help or coach, books you read, audios you hear, people you know and trust etc. 

As engineers all the time we’re making decisions and questioning ourselves. For instance: which technology to study next?What's the focus I want to keep during my career?, should I do a Class or a simple method?. Should I study front or back-end? Where do I feel better with these technologies? What kind of skills are companies needing? Where are the best salaries? Do I want to build something from scratch? Do I want to launch a startup or idea?

As you can see we all are exposed to these kinds of decisions almost on a daily basis, and you have to be smart or at least choose the kind of things that make you happy. Probably I’m not the best person to guide you on this decision, because I’m full in Ruby on Rails, so I’m skewed to this technology. But what I can do is to tell you my story in a couple of sentences

I started studying PHP in college. It was good for me at that time. I even built an e-commerce site from scratch, without any framework, we got customers, employees, and investors. Investors ask for a technology change, something that could scale and have better practices. We started searching for something: that was 2016. The Best thing we found was Ruby on Rails, so we started building the ecommerce on top of it. The experience was faster, happier and amazing than other things we tried before. I fell in love of Ruby and since then I’ve been building Rails. But what were the key points for us to keep working on Rails even in today’s Javascript world?

As I mentioned before, we as engineers need to make choices all the time (technical and non-technical) and knowing the fact that there are things well established, we don’t have to reinvent the wheel each time we want to build something. The Model-View-Controller pattern gives you the right structure to start and with a good skeleton in place, we can think in other business related differentiators and start working on it as features. It doesn’t have any sense to think on how to boot a server or structure a project folders when we have all of that included in a framework

I won’t lie to you. I have studied Javascript and React many times, but I don’t get it. I don’t like it. In my point of view is so disorganized, you have to build everything from scratch, frameworks are a mess, node_modules are insanely huge, everybody does everything different, there are no consensus, there are so many fancy new things you don’t know if it will become standar or not, and is so wordy, so much verbiage. Is the complete opposite to simple and organized. I use it, I understand the basics but I don’t want to go deeper in something that doesn't make me happy, but frustrated. In my opinion Ruby is simple, organized, standard, clean, wordless, and makes me happy. Same thing with Rails.  It’s a personal opinion, it is my personal happiness. 

Quick comment here: I’m not the radical Ruby advocate who hates everything else, I actually learned Data Science with Python stack (which I also love) and during my career I’ve learned a lot of different technologies. If you’re just starting be always open minded and learn new things, but finally dedicate you efforts to just one thing, because its simple: if you focus on just one thing you’ll get a competitive advantage

Ruby on Rails, or Rails, is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller (MVC) framework, providing default structures for a database, a web service, and web pages. It encourages and facilitates the use of web standards such as JSON or XML for data transfer and HTML, CSS and JavaScript for user interfacing. In addition to MVC, Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don't repeat yourself (DRY), and the active record pattern.

Ruby on Rails' emergence in 2005 greatly influenced web app development, through innovative features such as seamless database table creations, migrations, and scaffolding of views to enable rapid application development. Ruby on Rails' influence on other web frameworks remains apparent today, with many frameworks in other languages borrowing its ideas, including Django in Python; Catalyst in Perl; Laravel, CakePHP and Yii in PHP; Grails in Groovy; Phoenix in Elixir; Play in Scala; and Sails.js in Node.js.

Official page: https://rubyonrails.org/

The model–view–controller (MVC) pattern is the fundamental structure to organize application programming.

Personally when I explain the concept of MVC I always add another component to the image, called Routes, so we can talk about MVC/R. Let’s see the following diagram

The Rails router recognizes URLs and dispatches them to a controller's action, or to a Rack application. It can also generate paths and URLs, avoiding the need to hardcode strings in your views. Rails encourages developers to use RESTful routes, which include actions such as create, new, edit, update, destroy, show, and index. These mappings of incoming requests/routes to controller actions can be easily set up in the routes.rb configuration file.

A controller is a server-side component of Rails that responds to external requests from the web server to the application, by determining which view file to render. The controller may also have to query one or more models for information and pass these on to the view. 

For example, in a subscription system, a controller implementing a subscription-search function would need to query a model representing individual subscriptions to find subscriptions matching the search, and might also need to query models representing users and magazines to find related secondary data. 

The controller might then pass some subset of the subscription data to the corresponding view, which would contain a mixture of static HTML and logic that use the subscription data to create an HTML document containing a table with one row per subscription. 

A controller may provide one or more actions. In Ruby on Rails, an action is typically a basic unit that describes how to respond to a specific external web-browser request. Also, note that the controller/action will be accessible for external web requests only if a corresponding route is mapped to it. 

In a default configuration, a model in the Ruby on Rails framework maps to a table in a database and to a Ruby file. For example, a model class Product will usually be defined in the file product.rb' in the app/models directory, and linked to the table products in the database. While developers are free to ignore this convention and choose different names for their models, files, and database tables, this is not common practice and is usually discouraged in accordance with the "convention-over-configuration" philosophy.

A view in the default configuration of Rails is an erb file, which is evaluated and converted to HTML at run-time. Alternatively, many other templating systems can be used for views.

Ruby on Rails includes tools that make common development tasks easier "out-of-the-box", such as scaffolding that can automatically construct some of the models and views needed for a basic website. Also included are WEBrick, a simple Ruby web server that is distributed with Ruby, and Rake, a build system, distributed as a gem. Together with Ruby on Rails, these tools provide a basic development environment.

Ruby on Rails is separated into various packages, namely ActiveRecord (an object-relational mapping system for database access), Action Pack, Active Support and Action Mailer. Prior to version 2.0, Ruby on Rails also included the Action Web Service package that is now replaced by Active Resource. Apart from standard packages, developers can make plugins to extend existing packages. Earlier Rails supported plugins within their own custom framework; version 3.2 deprecates these in favor of standard Ruby "gems".

Before you continue, please read the rails Doctrine, and you’ll get a better idea about why so many people choose Rails: https://rubyonrails.org/doctrine

As you can see we have a lot of things to learn and practice here, so next posts will be following this very same order: Routes, Controllers, Models and Views. We’ll be talking about each component in detail and we’ll be doing an example application

I hope you learned a lot

Thanks for reading

Daniel Morales