…Moving on from the first part of the story, let’s continue…
The process
The course is divided into 5 phases, with their own stack of technologies.
These phases are composed by labs, which are exercises we have to solve using a coding editor of our choice. At first, I used the Learn IDE by default, created by the platform under the same name. Eventually, I decided to opt to VSCode, an IDE created by Microsoft, which contains more advanced features and it’s the most popular one these days.
After completing the labs of a given phase, we have to build a project involving all of the labs topics. A portfolio project, each one of them containing a set of requirements.
Speaking of them, I think these requirements are some of the most important parts of the whole program, when it comes to learning. It made me understand WHY I would have to apply determined features to them.
What’s also required, before or after submitting the project for review, is a video walkthrough of the application (on my case, I have used Nimbus Capture for recording and posted them on YouTube), a blog post about the process and the GitHub link that leads to it.
Phase 1
I would say that the hardest phase for me was the first one, which consists on building a CLI app that would scrape data or consume an API from a website of choice, and then display this data on the terminal. The concept of Object Oriented Programming was quite a challenge to comprehend at first, slowly becoming more natural.
Phase 2
This is when we move from the terminal to the browser, making use of the light Sinatra Ruby web framework. It was a quite a bit to grasp, by learning some obligatory web concepts, such as understanding HTTP requests and stored data in a website.
Although Sinatra is not a popular framework these days, I like that fact that it was introduced on the course right before Rails, which is was more complex and would be overwhelming to learn right when moving to a browser based project.
Sinatra keeps it simple and makes it a great entrance to the topic.
Phase 3
Ruby On Rails elevated the usage of Ruby to a whole new level. By using the Model View Controller architecture and HTML in Ruby syntax for the front-end, it’s the fastest way I’ve seen on building a full-stack web app. Let alone with used along with the appealing “scaffold” generator. This one NOT being allowed for its portfolio project, since abusing it would make students most likely skip some fundamentals.
This was the phase where I’ve build my largest application inside the course.
Phase 4
This time, we’re dealing with front-end logics for client interactions and consuming API’s, which on this case should be created from Scratch by using Rails. And yes, the scaffold generator is allowed this time around.
This was the second hardest phase for me, due to the fact that we have to learn a whole new programming language, the famous JavaScript.
It was a great intro to consuming API’s via HTTP requests, which made my simple project seem like a REAL full-stack application this time.
Phase 5
I was looking forward for this one, since React is a massively popular JavaScript library, which I tested several times even before getting into this module. Writing JS through React feels like building puzzle pieces and putting them together, except on a certain order to make it work.
Because of this hierarchical order called “component tree”, we’re also introduced to a state management JS library called Redux, which holds state in a source defined as “store”. It works like a database of states, which makes the components interact with each other regardless on their tree position.
In general, state management has simpler alternatives through React Hooks, while Redux is recommended for large scale applications due to its complexity.
For the backend of this project, the requirement is the same as the past project: a custom Rails API.
Conclusion
It was though, but that’s just the beginning! As a graduate, my next steps are diving deep into algorithms and data structure, as well as adding more projects to my personal portfolio.
My favorite part about the process was during the Portfolio Project reviews, since interacting with other developers for pair programming felt like real life experience.
More to come! Thank you for reading.
