Rails Application: Planning and Implementation

Hi there! Here I am again writing about my learnings this past week.

We started the Sprint meeting with a recap of the previous week. We shared what went well and what could've gone better. We agreed as a team that we did superbly with communicating and splitting the tasks. We were there for each other, supporting and not blocking each other issues. 🥳

In reviewing of what could've gone better, we made a list of points that need to be clarified:

• Moving from Issues to Implementation (agreed on proper label use)
• Wireframes/Design ideas (how detailed we'd like to be)
• Speed of Development Process (doing well)
• Slack vs. GitHub discussions (link the discussions when necessary)

Then we moved to Planning part. Next week will be mostly about running migrations and generating models, views, and controllers. Let's briefly go over that.

What is Rails about? Rails is designed to make programming web applications easier by making assumptions about what every developer needs to get started, allowing you to write less code while accomplishing more than many other languages and frameworks.

Rails is opinionated software. It assumes that there is a "best" way to do things, and it's designed to encourage that way by having STRONG conventions. Coders tend to find this strict adherence to conventions either very helpful or very frustrating.

Rails is built around the concept of Model - View - Controller (MVC) Architecture. MVC is a pattern for the architecture of a software application. It separates an application into the following components:

• Models for handling data and logic
• Controllers for handling back-end application logic (requests and responses)
• Views for handling the user interface objects and front-end logic

This separation results in user requests being processed as follows:

• The browser (on the client) sends a request to a page to the controller on the server.
• The controller retrieves the data it needs from the model in order to respond to the request.
• The controller gives the retrieved data to the view.
• The view is rendered and sent back to the client for the browser to display.

Separating a software application into these three distinct components is a good idea for several reasons, including improved scalability, ease of maintenance, reusability.

Rails can either be built with views or built as a pure API without views (in which case the views would be handled by a separate front-end application, like a React app). It's still part of our discussion whether we should use React or Rails with views.

This week's task was to generate the Shifts table model, and for that, I used a Scaffold command. The Scaffold in Rails is a full set of model, database migration for that model, a controller to manipulate it, views to view and manipulate the data, and a test suite for each of the above.

I also researched how to add Bootstrap to the Rails application and apparently, there are two ways of doing that. One is using ruby gem and another is using yarn.

There is no week without GitHub learning when you collaborate with others. This week we set a guideline for branch's names.
It will help us to stay on point when it comes to reviewing each other work and approving pull requests.😁

Looking forward to more learning!

Thank you for reading!

Referencing https://www.sitepoint.com/model-view-controller-mvc-architecture-rails/
https://guides.rubyonrails.org/command_line.html
Photo by Markus Winkler on Unsplash