Hey, hey, hey! Welcome back, I’m happy you decided to join us again. Last week, I hit the bottom of the emotional cycle of change. It’s a scary place down here but I don’t intend to stay for much longer. Let’s dive in.
Day 1: Sinatra & REST
So, we’ve been building Ruby apps in the Command Line and collecting data in Postgres but how in the world do we bring our apps to the browser? Enter, Sinatra.
Sinatra is a framework for quickly creating web applications in Ruby with minimal effort. Other ways include Rails, Express / Node.js, Django, PHP, etc.
Sinatra isn’t nearly as popular for a Ruby framework as Rails, but has a use case when building smaller scale apps because it’s minimalistic and lightweight as opposed to the “heaviness” of Rails, which is more apt for a larger production site.
So, we spent the first hour building our first Sinatra app together as a class. And the last hour building our own app.
REST: 2.5 hours:
Browsers have different “ways of talking” to servers. These are called methods. REST, or REpresentational State Transfer, is a convention for what these methods should be to standardize all the communication between browsers and servers.
Knowing REST is important because the vast majority of web developers have agreed to follow this same convention.
We spent a good chunk of the day building our CRUD and RESTful paths functionality into our Sinatra app. Most of the lesson we followed along with the instructor. Next, we were given a different project to build while applying what we’ve learn into our local app.
Feeling good about the day, I left school right after class, feeling optimistic once again!
Confidence level (1-5): 4 Optimistic level: High
Day 2: Outcomes, Sinatra and ActiveRecord
Outcomes: 1.5 Hours
On Tuesday mornings we meet with Outcomes. Outcomes assist students with the ‘after life’ of General Assembly. This week we went on a studio tour to iStrategy Labs to get an insider look into the life of a web developer. It was great to get away from campus and network with folks in my industry.
Sinatra and ActiveRecord: 2.5 Hours
After our tour and lunch, we headed back into the classroom.
Sinatra helps us build simple web applications quickly. We do not, however, have any way to persist data. ActiveRecord, on the other hand, lets us store data in a database easily but has no native web interface - only the command line. Put the two together, and we can build an app with a web interface that is backed by a database.
We spent the rest of the afternoon walking through building out a full CRUD Tunr app using Sinatra and ActiveRecord. A quick run down of this:
- Sketch out our ERD diagram
- Define our Schema
- Setup app.rb to load files using require and require_relative
- Made our Views - index, show, new views using .erb (embedded ruby file)
- Created forms for entering and editing data
- Deployed full CRUD!
Day 3: All Day Sinatra Lab
Pokenatra was the name of the lab and I knew it was going to be a good day. I’m a bit obsessed with Pokemon and this lab was all about creating a fully functional CRUD on a Pokemon model (i.e., you can read, create, update and delete a Pokemon). It was basically creating my own Pokedex. You can check out my poke github, if interested.
Writing code is definitely easier when you’re really into the topic. That was my biggest takeaway from this lab. I’m keeping that top of mind for industry searching on job market.
Confidence level (1-5): 5 Optimistic level: High
Day 4: Intro to Rails && Models and Migrations
Checkpoint: 1 hour
We had a quiz/checkpoint the very beginning of the day. All quizzes happen right at 9am and we have a hour to complete the quiz. It’s open note/open Google so it’s not your typical quiz - this is mostly for yourself to see how comfortable you are with the material.
Intro to Rails/MVC: 1.5 Hours
Yes. We have arrived. It’s finally the moment I’ve been waiting for… Ruby on Rails. Or just Rails. Apparently, you sound like a n00b if you say the full name. Anyway, Rails is a web application development framework written in the Ruby language.
Rails follows the MVC pattern. MVC is all about separating your code into separate sections…
- Models: they represent the data in our application and handle “business logic” using model methods
- Views: they describe how to present your data in a way that the user can see in the browser
- Controllers: they are responsible for responding to user requests, interacting with models and loading views
And because Rails is for web apps, there’s one additional component it adds to MVC: a router. Take a look at this picture below:
The rest of the class was setting up our first Rails app! Very exciting times. Check this lovely confirmation page:
Speaking of confirmation pages, one of the best features of Rails is its error pages! Crazy, right? Rails provides detailed, understandable errors that provide guidance when building an application. The error pages even come with a command line at the bottom for easy debugging!
Love it.
Speaking of error messages, our instructors let us in on a little secret that was too good not to tweet..
Rails Models and Migrations: 2.5 Hours
Mostly in this class, we followed the instructors along while we created our Models and Migrations into our Rails app.
Because we mostly created migrations to fix common errors in rails, not much else to say for this class!
Confidence level (1-5): 5 Optimistic level: High
Day 5: Slips, Rails Views and Controllers && Rails Routing and Resources
Slips: 1 Hour
Digital flashcards. This time we broke into small groups of 4 and individually answered questions. I’m still on the fence to whether or not I like this format better. The hour feels longer because you’re answering more questions but on the other hand, you aren’t standing up in front of the entire class.
Views and Controllers: 1.5 Hours
In this class, we built out our Rails Controllers and it’s associated Views using .erb and .rb files. The learning objectives of this class was as follows:
- Explain how the router directs requests to a specific controller and action
- Explain how controller actions map to specific views
- Describe the role of instance variables in sharing information between an action and its view
- Describe the Rails convention for implicitly rendering a view from an action
- Differentiate between redirect and render
- Use strong_params to limit what attributes can be modified
By the end of this class, we built our first full rails CRUD app! Homework was assigned and we were on our way to lunch.
Rails Routing and Resources: 2.5 Hours
This was another class that we mostly followed along with the instructor and coded with a partner. We chatted a lot about a rails developer’s best friend: $ rails routes command. The simple CLI line that gives you back so much more:
We finished out the lesson coding our RESTful Routes, and lastly, created Nested Resources.
Alright! Another solid week in the books. I really enjoyed this week and I’m feel right back at the top of my emotional cycle. Whew! Feels good to be back.
Confidence level (1-5): 5 Optimistic level: High
Thanks again for reading! General Assembly’s (free) Happy Hour is calling… Until next time!
