Turing School of Software Design: Module 2, Weeks 1

Build a Robot World

I have started Module 2 at the Turing School of Software Design where we expand upon our fundamental Ruby skills by building database-backed web applications in Sinatra and Rails. The first week covered topics including Sinatra, Bootstrap, Create Read Update Delete (CRUD) with Sinatra, model testing, feature testing, and SQL. To apply these learnings we were tasked with creating our own Sinatra app from scratch called Robot World.

Robot World

Robot World is a directory of robots. A robot has a name, city, state, avatar, birthdate, date hired, and a department. We needed to program the CRUD functionality for the robots so that a user can see all robots, see one specific robot, edit a robot, create a robot and delete a robot. We also had to add a dashboard with some basic statistical data about the directory such as average robot age and how many robots are in each department.

Within Robot World, we use an architectural pattern known as the model, view controller (MVC). The MVC structure is about splitting out functionality into three non-overlapping sections of a project. First there is the model, or the data that undergirds the application. In Robot World our model is how we connect to our database and the methods we use to manipulate the data.

def raw_robots
  database.execute("SELECT * FROM robots;")

def all
  raw_robots.map { |data| Robot.new(data) }

The above two methods are examples of functions that belong in the model. The method raw_robots method executes a database SQL query that returns all of the raw robot data contained in the database. The all method iterates over the raw data and creates Robot Ruby Objects with their own behaviors and attributes.

The view, as the name suggests, is how the user sees the data. In Robot World, we use Bootstrap,  to quickly add a professional sheen to our applications. Bootstrap is a popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. Below, I have the HTML and CSS rendered in my browser to show the view for how a user might go about editing a single robot. All of the styling is done by applying classes to basic HTML elements. For example I use the class "control-label" to stylize the field labels "Name," "City," etc. The Bootstrap theme I use knows how HTML elements with the class "control-label" need to be styled and then applies that style.

And here is the code for the name field of the form. Take note of the non-html "<%= %>" tag, which denotes a Ruby interpolation. In other words the text contained within these tags is actual Ruby that gets evaluated and then rendered as HTML. In this way we can populate static HTML documents with dynamic content.

<div class="form-group">
  <label for="inputName" class="col-md-2 control-label">Name</label>
  <div class="col-md-10">
    <input type="text" class="form-control" id="inputName" name='robot[name]' value="<%= @robot.name %>">

The controller is like the conductor of the web application and connects the view to the model. When the user clicks on a robot (which happens in the view), the controller asks the model for the data needed to properly render a view of that robot. Below is the code in the controller file that is called when a user clicks the edit icon when looking at a particular robot. The code says that when a user goes to the /robots/:id/edit route, where :id is the id of the robot, get the data for that robot and then render the edit view using that data.

get '/robots/:id/edit' do
  @robot = robot_world.find(params[:id].to_i)
  erb :edit

Keeping all of these methods separate from each other in their own directories means that I can change one without it affecting the others. For example, in the initial implementation of Robot World, we used a YAML file as the database containing our robot data. Mid week, we stripped out the YAML and replaced it with a SQL database. This required changes in the Model files, but did not require any changes in the view or controller files. Later on, I could decide to completely change the way the web app looks. I can do that without touching the database or the controller.

How the Internet Works

This small step from Ruby development to Web development also included a lesson by Turing School Founder, Jeff Casimir, called "How the Internet Works." As the title suggests, this class was amazing. Casimir posed and then answered the question, what happens when a user types "www.google.com" into their browser. 

My understanding is that first, the browser needs to convert the domain name "www.google.com" to an Internet Protocol (IP) address. IP addresses have rules that ensure that every device on a network has a unique address. To go from domain name to IP address, the web browser consults a Name Server which is a store of domain name and IP address pairs. Once the domain name is turned into an IP address, the browser initiates a Request Response Loop. A Request Response Loop is when the client browser makes an HTTP request to the computer server that the IP address is pointing to. That computer is likely in a server rack in a giant data center in some remote geography. Based on the request, the server next sends a response which contains data packets. In the case of the request to see www.google.com, the response packets are the html that make up the lovably minimalistic Google landing page. The request and response are basically sent over wires (or wifi), travel at the speed of light, and therefore take milliseconds to complete. We live in the future.


As a recovering educator, I appreciate the structure of the Turing Module 2 curriculum. It is incredibly well scaffolded, which means that complexity is introduced slowly and supports are removed gradually. Module 2 Lead Instructor Casey followed an "I do, We do, You do" structure at every step so that it always felt like we were making progress and learning new things, but I also never felt lost.

Rather than building our first web application, Robot World in Rails, we started with Sinatra, which, as I understand it, is a simpler framework that requires some manual setup that Rails does automatically. Requiring that we manually set up our project structure is a lot like teaching multiplication facts before allowing students to use calculators. By learning on Sinatra we are apparently understanding what Rails will eventually do for us. The same is true in a number of different areas of study this Module such as using SQL right now in our model. Eventually we will use active record. I appreciate this pedagogical choice.

Turing does a good job of gradual release - the idea of I do, we do, you do. As pre-work for this module we walked through a tutorial that had us build a "Task Manager" app. This is very similar to the Robot World app, but instead of robots our Task Manager stored tasks. Throughout the week the instructors demonstrated new concepts (I do) on their own Task Managers. Then together we worked on implementing the upgrade in our own Task Managers (We do). And then on our own (You do) we incorporated the features into Robot World. This thoughtful approach is indicative of the education pedigree a number of Turing staff have and reinforces for me that I am in a place that thinks seriously about pedagogy.