PREPARING YOUR APPLICATION

In your Gemfile, it may already look like it does below (specifically with the sqlite3 gem nested inside a group :development block and a pg gem nested inside a group :production block).  If not, delete gem "sqlite3", "~> 1.4" and add the following:

group :development, :test do
  gem "sqlite3", "~> 1.4"
  # note: keep other gems that were already in this group (e.g. "debug")
end

group :production do
  gem 'pg'
end

Note: there was likely already a group :development, :test block in your code. If so, keep that code and just add the sqlite3 gem to that group.  Don't delete any other gems in the group.  For example, your code may now look like this:

group :development, :test do
  gem "debug", platforms: %i[ mri mingw x64_mingw ]
  gem "sqlite3", "~> 1.4"
end

Once you've moved the sqlite3 gem and added the pg gem, execute the change in your Gemfile by running:

bundle install

These changes tell your Rails application to use the industrial-strength PostgreSQL database in production, instead of the sqlite3 database we've been using for development.  The database will behave the same for our purposes, but is ready for production-level traffic and future scalability.

Next, you'll need to update the config/database.yml file.  With the pg library installed for production, we also need to configure the app so that it knows where to find the production database.  Currently, it lives in a file in the db directory (db/development.sqlite3), but in production the database is managed separately.

If it's not already there, add the following to the config file:

production:
  <<: *default
  adapter: postgresql
  database: my_app_production
  username: my_app
  password: <%= ENV["MY_APP_DATABASE_PASSWORD"] %>

Replace my_app in the example with the name of your app - in this case tacogram_final would be appropriate.  Be sure that the database value still has production appended to it.  And MY_APP in the password should be TACOGRAM_FINAL in all caps.  As an example, it might look like this:

production:
  <<: *default
  adapter: postgresql
  database: tacogram_final_production
  username: tacogram_final
  password: <%= ENV["TACOGRAM_FINAL_DATABASE_PASSWORD"] %>

Last step is to commit these changes and push them to Github.

RENDER SETUP

Sign up for a Render account at render.com - use your Github credentials if possible.  You may have to enter payment info, but you'll be using the free tier.  During signup, you'll be asked several questions about how you will use Render - you can answer them however you'd like.  Once complete, you'll be on your Render dashboard.

You'll need to create 2 services - one for the database and one for the application.   Create the database service first.  Click "Create PostgreSQL" on your dashboard (or using the "New +" button in the top right).

In the form, enter a unique name for your new database - it's helpful to use your application name followed by "-db" to easily identify it later.  For example, it might be tacogram-final-db.

Ignore the other settings in the form until the Instance Type at the bottom.  Select the "Free" type and click "Create Database".  Note: Render only permits 1 free database service.  When you want to create a database for another application, you'll first need to suspend/delete this one (or upgrade to a paid plan).

On the next screen, wait for the database service to complete its setup.  Once it's available, scroll to the "Connections" section, find the "Internal Database URL" value and copy it - you'll need it in the next step.

Next, go back to your dashboard and click the "New +" button in the top right to create a new Web Service.

When asked "How would you like to deploy your web service?", choose "Build and deploy from a Git repository".  On the next screen, you'll be asked to "Connect a repository" - you should see your Github repository listed, but if not, click "Configure account" on the right to authorize access to your Github account.  Once you've found your application's repository in the list, click "Connect".

In the following form, the "Name" field will be pre-populated for you based on the name of your application.  However, this must be unique across all of Render, so you may need to change the name slightly (e.g. tacogram-final may already be taken).  You can leave the next few settings unchanged.  Then, in the "Build Command" field, enter the 2 commands that should run each time you deploy a new version of your application: bundle install; rails db:migrate (the semi-colon separates the 2 commands).

Next, change the "Start Command" field.  This is the command that will run to start your application server, just like you do in Gitpod: rails server

Then, choose the free Instance Type option.

The last change is adding environment variables needed to run the application - these are variables stored on the "server" instead of in our code and generally used to run the application or for sensitive data we don't want to store in our code (e.g. API keys).  The variables you'll need to add are:

• DATABASE_URL
• SECRET_KEY_BASE
• WEB_CONCURRENCY

The DATABASE_URL value should be the "Internal Database URL" value copied from the database service.  The SECRET_KEY_BASE value can be anything - your application name will work.  And, the WEB_CONCURRENCY value should be 2.

That's it.  You can click "Create Web Service" to complete the setup.  Render will pull your latest code from Github and begin to install all of the necessary libraries.  It will automatically run bundle install and rails db:migrate.  And then lastly, it will run rails server.  If all goes well, you'll see "Your service is live 🎉" in the logs.

From now on, each time you push new code from Gitpod to Github, it will be deployed to Render as well.  You can see any deployment events listed in the "Events" tab.

Congratulations!  Your app should now be live!  There's a link to visit your live production site towards the top.  Note the url for future reference - it will be something like my_app.onrender.com where "my_app" is the unique name you entered previously (e.g. tacogram-final-tues).

DEBUGGING

Render is really just a big, industrial Linux-based computer – just like Gitpod, but more powerful.  It's worth exploring the features of your Render services to discover what's possible.  One feature that's very useful is access to the logs (see the "Logs" tab just below the "Events" tab in Render.  As users interact with your application, you will see the output to the server log there.  Just as you did with the rails server log in Gitpod, reading these logs will be helpful when you inevitably find a bug in the live app.  You won't see the usual error message that you've seen in local development - that would be a bad user experience.  Instead you'll see a simple 404 error screen with no details about what went wrong.  

To see the actual error message, you'll need to look at the server log.  Render makes this especially easy by providing search and filter functionality for your logs.

CUSTOM DOMAINS

If you're interested in adding a custom domain to your application (e.g. tacogram-final.com instead of tacogram-final.onrender.com), you'll first need to purchase a domain (or use a domain you already own) at a domain registry provider like Namecheap.  Then follow Render's instructions to configure the domain to point to your server on Render.

It's Your World

The actual, physical world that is all around us is composed of many, many, billions of objects – living or not – each with their own behavior, attributes, and idiosyncrasies. It's the job of scientists and domain experts to study these objects and the ways in which they interact with each other, and to develop theories and laws to describe their observations, so that we can better understand the way the world works. It's all very complicated.

The world of the software we create is not nearly this complex. Everything that exists in this world is entirely up to us. We define what objects live in this world, their attributes and behaviors, and their relationships with one another. The result is a domain model of our own creation, and it can be as simple or as complex we need it to be.

From the Wikipedia article on domain modeling:

A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data. A domain model leverages natural language of the domain.

A domain model generally uses the vocabulary of the domain, thus allowing a representation of the model to be communicated to non-technical stakeholders.

Oof. That's a lot of words. Let's TL;DR this thing. A domain model:

• Is a real-world concept (aka domain) represented as software
• Contains only the data and rules involved in the domain
• Is described using the actual words (i.e. vocabulary) used by those working in the domain

It's important to note that a domain model doesn't need to include everything in the domain – only the pertinent bits we need right now in order to build our system. We can always add more later – it's just a CREATE TABLE statement, right? But how do we determine what is needed right now? Let's take a look at this through the lens of a startup.

Minimum Viable Product (MVP)

Popularized in the early 2000s, most notably by Eric Ries in his book The Lean Startup, the Minimum Viable Product (MVP) approach to building software products has become the de-facto standard in the startup community. There is plenty of in-depth reading and research we can do on the topic, both in-print and online; we're going to give you the highlight reel here.

In short, building an MVP means that, when building a new software product, we build only the features necessary (minimum) in order to get feedback from real users (viable). Build any more than those core features, and you're just wasting time and money building something that customers/users probably don't want anyway.

How do we begin to enumerate what those core features are, then? To get things started, it can be useful to create user stories.

User Stories

Our product's user stories is a written document that, in a regimented way, describes the core features in a user-centric style. How does a user of your system deal with their problem, perform their task, or otherwise receive value by interacting with it?

Let's begin by looking at the typical template for writing a user story:

As a [some user role], I want to [some goal], so I can [some value]

Pretty vague, right? Don't worry, it will make more sense once we look at a practical example.

Let's continue with the idea of a "school" system that we started building the database for in the last lesson. We'll begin with a top-level, overall vision for the system. Perhaps this is something that's written down, articulated in some way, or just something we're thinking about:

This will be a system used to manage our school. A student in our school can use the system to browse the available courses and enroll in them, based on the dates/times that best fit their schedule. Students are added to the system by teachers. So are the courses they teach.

From there, we can begin the process of transforming that general vision into the user story format. Let's look at a single story, one that we could argue is truly the core purpose of the system:

As a student, I want to browse available courses, seeing the course description and bio of the instructor, so I can decide if I want to enroll in it.

By going through this process, we've immediately transformed the somewhat loose, general vision into a concise story that clearly articulates what that part of the system is supposed to do from a user perspective, and the value it creates for the user. We can also see that we're using the language that's specific to this domain, that is, we're describing things in the vocabulary that would be typically used by the people using this system.

If you like, you can stop reading here, and see if you can come up with the rest of the stories.

Here's the list that we came up with:

• As a student, I want to browse available courses, seeing the course description and bio of the instructor, so I can decide if I want to enroll in it.
• As a student, I want to see the available sections (dates and times offered) and enroll in the section of my choosing, so that I can enroll in the course I want at the time that best works for my schedule.
• As a teacher, I want to be able to maintain (add, edit, and remove) a list of students at our school, so that we know who our students are, their contact information (email and phone number), and provide access to enroll in classes.
• As a teacher, I want to be able to maintain (add, edit, and remove) a list of teachers (including myself) at our school, so that we can manage teachers' bios and a list of classes they teach.
• As a teacher, I want to be able to maintain (add, edit, and remove) a list of courses and the sections of those courses, so that we can publish it for students to browse and enroll.

In the end, there may be more stories, or a need to make certain stories more specific, but this is certainly a good list to start. Again, all we've done is taken a rather general vision for our overall product and its purpose, and used the user story template to help us think about what the pieces are, and how to articulate them in a way that illuminates the value of each part of the system.

After getting these stories down on paper, it's time to evaluate. If we have too many stories, this process may help us decide how to shave the list down to only the parts of the system needed to create value and receive feedback. If we have too few stories, this helps us learn what we'd need to add to make this a valuable system for our potential users.

It's important to note that user stories are not meant to be some sort of formal document that gets etched in stone; rather, it's more of an iterative process that help us to continually think about what the system is really supposed to do and the value it creates.

Wireframing

Wireframes are another great tool for iterating on a system's design. Once we have our user stories on paper, we can then create a visual representation of the user's experience, i.e. what will the system look like to the user?

We can use practically any tools we're comfortable with to draw our wireframes. These tools might include:

• Pencil and paper
• A presentation tool like Powerpoint or Keynote
• Graphics/design apps like Figma, Sketch, Adobe XD or Photoshop
• Wireframing tools and services like Balsamiq Mockups, Justinmind, or wireframe.cc
• If you already know it, HTML and CSS

The tool doesn't matter. The goal is to transform our user stories into a visual of what the finished MVP might look like, so we can discover more detail than we knew before, or to iterate on what the needed functionality might be. It's very common to return to the user stories and make changes after wireframing.

Here's an example of a wireframe for our school enrollment app, created using Balsamiq. For the purposes of domain modeling, there are no specifications or formal process for wireframing; it's really all about helping to visualize what we've already articulated using our user stories.

Models

User stories and wireframes is a way to think about and discover all the entities in your world, as well as the relationships between them. We'll now shift that thinking to building our database. From now on, we'll call each real-world entity a model. And all of our models, together with all of their relationships, is called our domain model.

What are the real, tangible models we're dealing with in our school system? That is, things that really exist in the real world, outside the realm of software? From our user stories and wireframes, a couple of obvious ones might be:

• Student
• Teacher

Students and teachers do not exist in theory. They exist in the real, physical world. Students are the people who attend our school. Teachers are people who teach the courses.

But you may be wondering, why we don't we have a single model for People? After all, a student and a teacher are both people. This is a valid question and one that is quite nuanced in nature. It's because models are distinguished by their unique attributes. According to our user stories/wireframes, teachers have bios. Students do not. Students have contact information (email/phone number). Teachers do not. We might decide later that students need a bio, too – at which point, we'd go back and iterate on our user stories. But not right now.

Let's try to identify the attributes – the data needed for – these two models.

• Student – name (first/last), email, and phone number
• Teacher – name (first/last), bio

Database-Backed Models

If you've put 2+2 together, based on our last lesson on SQL, a model and its attributes can be neatly represented in a database table.

• Each column represents a particular model attribute
• Each row represents a unique model instance

Each model will need a different table, because the column definitions will be different for every model. The start of our domain model, along with some sample data, might look like this:

students

teachers

A decent start. Let's add the model for a Course. A course, while not necessarily a real, physical thing like a student or a teacher, is an entity that really exists that we need to retain data for – that is, it has attributes. We can also create instances of it, i.e. each row in the database table represents the data for each available course. Let's try and determine the attributes of a course. What data would we need to keep track of for every course, according to our user stories and wireframes?

• A course name
• A course description

And that's all for now:

courses

Relationships

At this point, you might be asking yourself... wait, is that all the data needed for a course? What about the sections – the dates and times the course is available? Or the teachers who teach the course?

Knowing the difference between what belongs as an attribute on a model and what should be separated into its own model... is one of the keys to being good at domain modeling.

Is it possible to add the dates/times and teacher of each course to the Course model? Sure, let's see what that would look like:

courses

Seems perfectly reasonable. But what happens when the demand for Taco-Making becomes so large that we add a third time? Or a fourth? Or a 10th? While we could, of course, continue to grow the courses table horizontally, it turns out that it's generally a much better idea to grow a database vertically. Exponential horizontal growth of a database table is an indicator that we should be doing something different.

What's we seeing here is a one-to-many relationship – one course can have many times it is available, each with a different possible teacher – i.e. Sections.

Remember a few paragraphs ago, when we defined what a domain model is? To refresh your memory:

... we'll call each real-world entity a model. And all of our models, together with all of their relationships, is called our domain model.

The Section model, in this particular case, is not so much a tangible, real-world thing. Rather, it's a model that's made necessary due to the relationships between our real-world entities.

It makes sense for Section to be its own model because:

• We don't know how many sections of a course there could be. It might be none, only one, or a million.
• A section has its own attributes, like the time it's offered, and the teacher who teaches it. This list of attributes could potentially change in the future, making it very difficult to manage if this data lived within the Courses model.

courses

sections

Aaaahhh! So much better. Now the Course model only holds information about the course itself, delegating the data about each section to the Section model. We can now support as many sections as needed without resorting to changes in our database design.

We can also see that, in order to create a one-to-many relationship in a domain model, we simply need to add a foreign key column on the "many" side of the equation. In this example, because one course has many sections, we add a course_id to sections and we're there.

And yes, there are two foreign keys on sections, because there are actually two one-to-many relationships where Section is involved.

Here we see the last piece of the puzzle:

Two one-to-many relationships = One many-to-many relationship

A course can have many teachers. A teacher can teach many courses. The relationship between our Course and Teacher models is a many-to-many relationship, and the Section model is known as their join model.

Naming Conventions

We've seen enough of domain modeling that it now makes sense to talk about the conventions we've been using. Although there is not a technical reason to adhere to these conventions, it is certainly a set of best practices that we will continue to follow for the remainder of this course.

• When talking about models like Course and Section, we write them in the singular form, and beginning with a capital letter – it will make sense why we do this later in the course.
• Database table names like courses and sections are always plural, and in all lower-case.
• Column names are always in lower-case, e.g. name or description.
• If a table or column name is made up of more than one word, we separate the words by underscores, e.g. first_name or teacher_id.

Lab

Begin with the template project on GitHub, create a new repo from the template, and open this repo in Codespaces.

• Modify the school.sql script to make the courses, teachers, and sections tables real (the statement that creates the students table is already there). Execute the script by running .read school.sql at the SQLite prompt, and execute the .schema command to ensure that everything went as expected.
• Design the model that allows students to sign up for classes – let's call it Enrollment – do it on paper, in Excel, or any other tool of your choice.
• Add the enrollments table you designed above by writing a CREATE TABLE statement in the school.sql script, and execute the script.  (For reference, you can find the SQL for adding tables here.)

A Customer Relationship Management (CRM) system is one that allows users (typically sales teams) to keep track of companies/contacts and the interactions (emails, sales calls, in-person meetings, etc.) the user has with each contact. If you've worked in sales before, chances are you've used some kind of CRM system – e.g. Salesforce, Zoho, Freshdesk, Pipedrive, or about 1000 others. In this case study, we're going to create the domain model for our own simple CRM.

Here are the user stories and wireframes:

• As a salesperson, I want to maintain a list of contacts (along with each contact's name, email address, and phone number), so I know how to reach each person.
• As a salesperson, I want to be able to log each activity (e.g. calls/emails, with a date/time it occurred and my notes.) I have with a contact, so I can keep a diary of all the communication I have with each person.
• As a salesperson, I want to manage a list of companies (name), so I know all the companies we sell to.
• As a salesperson, I want to associate contacts with a company, so that I can get a company-wide view of my sales team's communication with all the people at a company.
• As a salesperson, I want to maintain my own contact information (first/last name and email address), so that other members of the sales team know who I am.

What real-world entities are we dealing with? Once those are determined, what relationships or join models are needed to connect the dots?

Jot your thoughts down on paper or tool of your choice (sometimes visual is a better way to get started than a bunch of CREATE TABLE statements), then write the script to create the actual SQLite database.

Go Further

Once you've designed a database to support the initial user stories and wireframes, here's a challenge to flesh out our domain model.

Additional user stories:

• As a salesperson, I want to maintain a list of industries, so that I can see how my sales team is performing across the different industries we do business with.
• As a salesperson, I want to indicate a company's industries (1 or more), so I can categorize the companies we sell to by industry.

Updated wireframe:

Tacostagram will be all the rage when it launches. People from around the world will be able to create a constantly evolving feed of photos of their favorite tacos. People will be able to "like" photos of tacos and write comments about each photo. Eventually, we will sell it to technology behemoth MetaTaco for $1 billion.

• As a user, I want to create time-stamped posts of tacos, so that I can share them in a "feed" for the world to see.
• As a user, I want to be able to "like" another user's post, so the author of the post and others will know that I liked it.
• As a user, I want to be able to see how many likes a post has, so I can see how popular it is.
• As a user, I want to not be able to like a post more than once, so I cannot artificially inflate the popularity of a post.
• As a user, I want to be able to comment (and see other's comments) on a post, so I can engage in conversation with the author and others.
• As a user, I want to be able to "follow" another user, so that I can stay up-to-date on certain users' updates.
• As a user, I want to see only my followed users' posts in my feed, so I can only see posts that I'm interested in.
• As a user, I want to sign up with my username (screen name), real name, and location, so that other people will see that information when visiting my profile.

Note: we are going to ignore the mechanics of how a photo gets uploaded and stored, and simply use a filename for the time being, e.g. tacos.jpg.

As with the last exercise, jot down your domain model visually first, then move on to the physical creation of the SQLite database.

These are the entities we came up with, based on the current user stories/wireframes:

• Salesperson – the salesperson using the system
• Contact  – a person that I have sales interactions (activities) with
• Company – the company that a Contact works for
• Activity – the interaction (like a call or email) we have with a Contact
• Industry – the market (like "Consumer Electronics") a company can belong to

If we begin our data model design, it starts by looking something like this:

CREATE TABLE salespeople (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT
);

CREATE TABLE contacts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT,
  phone_number TEXT
);

CREATE TABLE companies (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

CREATE TABLE activities (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  occurred_at TEXT,
  notes TEXT
);

CREATE TABLE industries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

And we also have these relationships:

• A one-to-many relationship between Company and Contact; that is, a company can have many contacts, but a contact belongs to only one company
• A one-to-many relationship between Salesperson and Activities; that is, a salesperson can have many activities, but a single activity belongs to only one salesperson
• A one-to-many relationship between Contact and Activities; that is, a contact can have many activities, but a single activity belongs to only one contact
• A many-to-many relationship between Company and Industry; that is, a company can be categorized into multiple industries, and an industry can have many companies

As we learned in the last lesson, from an implementation perspective, a one-to-many relationship is built by adding a foreign key column to the "many" side of the equation:

CREATE TABLE salespeople (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT
);

CREATE TABLE contacts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT,
  phone_number TEXT,
  company_id INTEGER
);

CREATE TABLE companies (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

CREATE TABLE activities (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  occurred_at TEXT,
  notes TEXT,
  salesperson_id INTEGER,
  contact_id INTEGER
);

CREATE TABLE industries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

And, a many-to-many relationship is actually two one-to-many relationships put together with a join model; in this case:

• A Company has one-to-many Industries
• An Industry has one-to-many Companies

What should we call the join model?

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Many developers like to reference this quote – a lot. Naming things is indeed very hard. What's a word we can use to describe a company/industry combination? Turns out that there really isn't one – not one that the majority of people use and would understand right away and without much explanation. So we're simply going to refer to this as an Industry Membership. Our final domain model, implemented in SQL, looks like this:

CREATE TABLE salespeople (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT
);

CREATE TABLE contacts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  first_name TEXT,
  last_name TEXT,
  email TEXT,
  phone_number TEXT,
  company_id INTEGER
);

CREATE TABLE companies (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

CREATE TABLE activities (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  occurred_at TEXT,
  notes TEXT,
  salesperson_id INTEGER,
  contact_id INTEGER
);

CREATE TABLE industries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

CREATE TABLE industry_memberships (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  company_id INTEGER,
  industry_id INTEGER
);

This exercise is a good example of a domain modeling a more abstract concept. Our primary model – let's call it Post – doesn't line up precisely with a real-world thing, like Student or Teacher from the previous exercise. Rather, it's a digital analogy for something that could exist in the real world (like a Polaroid photo pinned to a physical cork-board, displayed for the world to see, for instance), and Post is something that only exists in your digital world.

Here are two main entities we came up with to start, based on the current user stories/wireframes:

• User – a person using the system
• Post – the taco image being posted, along with data that describes it, like the time it was posted and the user who posted it

As noted, we are going to ignore the mechanics of how a photo gets uploaded and stored, and simply use a filename for the time being, e.g. tacos.jpg.

CREATE TABLE users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_name TEXT,
  real_name TEXT,
  location TEXT
);

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  image_file TEXT,
  posted_at TEXT
);

The column names are going to vary based on what you thought they should be called, but generally, this is straightforward. The one thing to note is that there is a one-to-many relationship between User and Post, that is, a User may have one-to-many Posts. As we have learned, in SQL, a one-to-many relationship is built by adding a foreign key column to the "many" side of the equation – in this case, we have a user_id on the posts table.

Likes

Next, we need our domain model to support the ability for a user to "like" a post. This "like count" is then displayed on the post itself; for example, on the wireframe, our example post has 85 likes. Our instinct might be to say, the number of likes is simply an attribute of a post, and implement it by simply adding a column to the posts table:

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  image_file TEXT,
  posted_at TEXT,
  number_of_likes INTEGER
);

This certainly satisfies our requirement that a Post has likes, and is simply an integer that can be incremented based on the number of people who like the post. However, it does not work when considering the requirement in our fourth user story: As a user, I want to not be able to like a post more than once, so I cannot artificially inflate the popularity of a post.

At some point, we'd need to add some application-level logic that prevents a user from incrementing this number more than once – however, it's pretty difficult to do that unless we know whether or not a user has liked a post before. We can do this once we shift our domain model towards the idea that a like is the join model between a user and a post:

• A User has a many-to-many relationship with a Post
• A many-to-many relationship is actually two one-to-many relationships put together with a join model – in this case, a Like
• A user has one-to-many liked posts
• A post is liked by one-to-many users

CREATE TABLE users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_name TEXT,
  real_name TEXT,
  location TEXT
);

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  image_file TEXT,
  posted_at TEXT
);

CREATE TABLE likes (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  post_id INTEGER
);

This creates the many-to-many relationship between a user and a post, while also creating a way to track which users have liked which posts.

Comments

A Comment is very similar to a Like. It is another join model, representing the many-to-many relationship between a Post and a User.

• A User has a many-to-many relationship with a Post
• A many-to-many relationship is actually two one-to-many relationships put together with a join model – in this case, a Comment
• A user has one-to-many commented on posts
• A post is commented on by one-to-many users

CREATE TABLE comment (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  post_id INTEGER,
  body TEXT
);

The only difference between a Comment and a Like, in practice, is that we need to add an additional field – body – to hold the body of the comment itself.

Followers

There are a couple of concepts to discuss, in order to properly model one user following another user.

The first is that it's perfectly ok for a domain model relationship to be self-referential. That is, a model can have a relationship with itself, i.e. a user may followed by one-to-many users. This is not super-common, but it is sometimes necessary to do.

The second is that, while we've learned that a foreign key is, by convention, the singular name of a model followed by _id, it is occasionally necessary to break this convention to make the database design more clear. Let's look at the finished Follower model:

CREATE TABLE followers (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  followed_user_id INTEGER,
  follower_user_id INTEGER
);

In this particular case, it's more important to name our columns this way, to make a distinction between the user being followed and the user doing the following. Note that we're still using the word user_id in the names of these columns, to ensure that we continue to know that the foreign keys reference a primary key in the users table.

Here is our complete domain model, implemented using SQL:

CREATE TABLE users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_name TEXT,
  real_name TEXT,
  location TEXT
);

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  image_file TEXT,
  posted_at TEXT
);

CREATE TABLE likes (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  post_id INTEGER
);

CREATE TABLE comments (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER,
  post_id INTEGER,
  body TEXT
);

CREATE TABLE followers (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  followed_user_id INTEGER,
  follower_user_id INTEGER
);

Creating a Repo

Begin by creating a brand-new GitHub repository in your GitHub account. Call it shopping-list, and keep the repository public. Then, open the repository in Codespaces.

Open the Terminal in Codespaces – hamburger menu -> View -> Terminal. The current working directory should be /workspace/shopping-list, but if it isn't, you can cd into that directory. Create a new file called README.md by typing touch README.md at the prompt. You should see it appear in the Explorer in the left-hand sidebar. Click on the file in Explorer to open it.

Edit the README.md file and add a bulleted list of items to purchase. This can be a list of anything you want, with each item on its own line, and each line starting with a dash and a space. Like this:

- Bacon
- Eggs
- Xbox

Commit your changes using the Source Control pane on the left-hand side. Add a meaningful commit message, such as "adds initial list of items". Then, click on the three dots under Source Control, and choose "Push".

This will publish your initial code to GitHub. Head back over to the repository page on GitHub.com, and you should see your code there, complete with commit message and list of files (there should only be one). Because you named the file README.md, the contents of the file should appear on the repository's home page.

Push changes

Head back to Codespaces. Next, add a few items to your shopping list. Then, commit the changes (with a good commit message describing the work), and sync the changes to GitHub.

After syncing, go back to the repository page on GitHub.com, and refresh. Notice how the changes you've made have affected the repository. At this point, feel free to poke around and see how Git and GitHub track your changes. For example, click on your latest commit message to see how GitHub presents a visual of the changes you made in that commit.

Add files

Use the Explorer in Codespaces to upload an image file from your computer. Right-click in the Explorer and select Upload..., then select the file from your computer. The file will be uploaded and appear in your Explorer. Then, commit and sync your changes.

Head back to GitHub.com and see how those changes have affected the online repository.

Let's decide that images belong in a sub-directory called images. Head back to the Codespaces Terminal, and create the directory:

mkdir images

Then, move the image you uploaded into the newly created images directory. If the image you uploaded was called tacos.jpg, you would do:

mv tacos.jpg images

(Of course, we can do this using the mouse and the graphical interface within Codespaces; we just want practice using the command-line instead.)

Finally, commit and sync to GitHub, view the repository at GitHub.com, and verify how the repository contents have changed.

• Apple MacBook Pro (hardware) + Mac OS (operating system) + Atom (code editor)
• Apple iMac (hardware) + Mac OS (operating system) + XCode (code editor)
• Microsoft Windows Surface Pro (hardware) + Windows 11 (operating system) + Microsoft Visual Studio Code (code editor)
• Lenovo Thinkpad X1 Carbon (hardware) + Ubuntu Linux 20 (operating system) + Microsoft Visual Studio Code (code editor)

Of course, in addition to the hardware, OS, and code editor, we must add other job-specific tools, such as a web server (for web developers), device emulators (for mobile developers), and hardware development kits (for IoT developers). The possibilities are endless.

As mentioned previously, we are going to be working on building web applications in this course. We could spend a few hours installing the command-line interfaces, web servers, and other applications needed to build them, specific to the computer hardware and operating systems you might have, debugging and tweaking what we need along the way. Or, we could use a cloud-based development environment, which includes 100% of what we need, already packaged up and ready to go. This, of course, is the value proposition of Github Codespaces – an all-in-one (i.e. dedicated hardware, OS, application software, and code editor), cloud-based development environment that will put all the setup and infrastructure behind us, and get us to coding right away.

Getting Started

Assuming you already have a Github account, getting our development environment up-and-running is (mostly) a click away.

Head over to the hello-world repository you created in the last lesson. If you can't find it, head over to your Github home page and look on the left-hand side under Repositories. On the project page for the repository, click the button that says Code, select the Codespaces tab, then click the "Create codespace" button.

If everything goes smoothly, you should be launched into the Codespaces development environment, with a column of folders and files contained within your hello-world project on the left-hand side. You might see a Welcome page – feel free to close it.

Click on README.md on the left-hand side (the area known as the Explorer); you should see the editable contents of that file appear on the right (the Editor).

Editing, Committing, and Syncing Files in your Codespace

Go ahead and make a change – any change – to your README.md file. Changes are auto-saved automatically by default, so there's no need to worry about saving yourself. When you make a change, you'll immediately see the file you're working on change color in the Explorer.

Notice the funny icon (the one that looks like branches) now has a (1) next to it? That's letting you know that you've made 1 change since the last time this code was committed. If you click on that icon, you'll find yourself in the Source Control pane.

When you're ready to commit your changes, the process is essentially the same as when we did it using GitHub's web-based interface. The Message that it's asking for is the commit message, i.e. a description of this unit of work that you're about to commit. Enter a message and hit the check mark icon (✔️) to commit.

This being the first time you're committing changes, you'll be asked what you want to do:

You can either select Yes here, or Always, so you don't see this message again. At this point, you've successfully committed your changes to your local Git (i.e. the Git software that runs on the cloud-based computer that we're using), but you have not yet sent those changes back to GitHub. To do so, click the Sync Changes button.

Since it's the first time syncing (see a theme here?), you'll see this prompt:

Click OK, Don't Show Again. What we're saying here is, when you hit Sync Changes from now on, push my changes to GitHub, and also get changes from the GitHub-hosted repository, if there are any. Because we're not working in teams (yet), the pulling of commits will almost always do nothing.

Along the same lines, you'll also be asked:

Again, because we're not working in teams or otherwise won't have multiple contributors to the same online GitHub repository, this doesn't really matter – it's simply asking if you want to automatically pull changes from the hosted repository on GitHub every few minutes. You can safely click either option.

It's always a good idea to confirm that your commit made it to your GitHub repository by going to the project page.

How often should you commit and sync?

Now that you know how to edit code, commit, and sync, it begs the question: how often should you do it? After all, there's nothing to physically prevent you from writing 10,000 lines of code across 200 different code files, then commit and sync it all. (Spoiler alert – don't do that.)

The answer can vary based on the culture of the company/development team that a software developer works with, but in general, each commit should represent a single unit of work. Some examples of a unit of work might be:

• Built a feature
• Added a user-interface element
• Modified some documentation

Again, there's usually no hard-and-fast rule as to when to commit/sync, but broadly speaking, some good guidelines to follow are:

• Commit when you have something worth committing – e.g. a working feature or a big step toward a larger goal.
• Don't commit code that is broken – don't use commits to "save" your code to disk in the cloud, just for the sake of doing it.
• Commit as often as possible, BUT – it's based on the work, not the time. You could potentially commit 20 times in a day, or once in a week, based on your pace of work and what you've accomplished.

The Command-Line Interface (CLI) aka "Terminal"

One trait that is very common among professional software developers is that they are also power-users of the computer. When was the last time you saw a pro dev using the mouse pointer, double-clicking to slowly do things on their computer? No – you usually see their fingers moving lightning-fast over a text-based interface, heaps of text scrolling by as they fire off commands to have the computer do what they want. What they're doing is using the computer's command-line interface, or CLI for short.

The CLI is simply a way for you to tell your computer to do things by inputting text commands, instead of using the mouse. It's old-school. But it's also a way to do things much, much faster than clicking around all the time, so it's the preferred way for many professional developers to manage files and run software. We'll be using it a lot.

What can you do with it?

Almost anything you'd normally do with the mouse and keyboard. In this lesson, we'll focus on simple things, like how to traverse and browse the directory structure on your computer, move files around, and run programs.

Accessing the CLI

As mentioned, every computer has a command-line interface. On Mac OS, you could access it using the built-in Terminal application or maybe iTerm. On Windows, you'd use Command Prompt or perhaps Powershell. But since we're not using our own computers for development – we're using the cloud-based computer provided to us by Codespaces – we'll use the Codespaces Terminal, in this case.

Start with the main menu in Codespaces (the "hamburger" menu in the upper-left). Choose View -> Terminal.

A brand-new Terminal window will open, and is ready to accept your commands. Hit Return a few times. You'll notice that, each time you hit Return, you'll going to be presented with the same Terminal prompt – that is, some text followed by the $ symbol. That $ symbol is telling you that the Terminal is ready to accept your input. This is important to know, because sometimes you won't see it! When you don't see it, that's letting you know that you can't type commands, either because it's still doing something else, or that it's confused about what you want it to do next. Most of the time, you can hit Control-C to get back to the prompt. When in doubt, hit Control-C.

The Working Directory

The first thing you might notice about the prompt is that it always prints the current working directory. What's the working directory? It's the directory that where you're, well... working. Any commands you type are going to apply relative to the files and folders in this directory. To try it out, type ls and hit Return.

ls is the List command. It lists all the files in the working directory. You should see an output similar to:

code  images  LICENSE  README.md

This is a simple list of files in our working directory, and should be the same as the files you see in Explorer in the left sidebar.

You can also create a new directory. Try typing mkdir tacos and hitting Return.

mkdir stands for Make Directory. This command takes an argument, i.e. more words after the command name that are used as inputs to the mkdir command itself. Naturally, it makes a new directory – relative to the current working directory – with the new directory name provided as an argument. You should see a new tacos directory appear in the Explorer.

Traversing directories

Now that you have a new directory, let's make that directory the new working directory. Type cd tacos and hit Return. You'll see that the current working directory has now changed to /workspace/hello-world/tacos.

cd stands for Change Directory. cd accepts an argument of the directory you want to change to. This argument can either be a relative path – like you've done here, i.e. tacos is the name of the directory inside your current working directory – or it can be an absolute path – i.e. the full path to the directory on the computer.

Said a different way, cd tacos works because the working directory is /workspace/hello-world and tacos is a directory inside of it. If your working directory was somewhere else, and you wanted to change your working directory to the tacos directory, you'd have to provide the absolute path, i.e. cd /workspace/hello-world/tacos.

Ok, your current working directory is /workspace/hello-world/tacos – but now you want to change it back to the parent hello-world directory. You could use the absolute path:

cd /workspace/hello-world

And that would work perfectly fine. But there's also a shortcut to change the working directory to traverse up one level, to the parent directory:

cd ..

.. is simply shortcut syntax for "parent directory".

Ok, what now?

Here's just a quick cheat-sheet of other things you can do with files using the CLI.

Try creating a file in the current working directory:

touch hello.txt

You can have a look at its contents, if you want:

cat hello.txt

You can also copy it:

cp hello.txt hello2.txt

Or move (rename it):

mv hello2.txt hello3.txt

Or delete it:

rm hello3.txt

Bonus Level: Expert

There are a couple of ways you can move extra-fast through the CLI. If you've ever watched a pro developer work, this is how they make it seem like they can type at superhuman speeds. The first trick is using the tab key. The tab key is essentially "auto-complete" for the CLI. Type the first couple of letters of a command and hit tab – the command will be auto-completed for you. To try it, type mkd and hit tab – it will auto-complete to mkdir. Works on filenames and pathnames as well.

The other trick is using the arrow keys. ↑will repeat the previous command – and you can use ↑ and ↓to cycle through all recently used commands.

Running Programs

These commands you've been using like ls, mkdir, cd – these are all programs (applications) that are built-in to the operating system we're using (Linux). Of course, you can run our own programs too... let's try it! There's a program located in the code directory called hello.rb. This is a program written in the Ruby programming language, so you'll have to use the ruby command to execute it, i.e. ruby hello.rb. Try typing that now, and perhaps you'll get a message that looks like this:

/workspace/hello-world $ ruby hello.rb
Traceback (most recent call last):
ruby: No such file or directory -- hello.rb (LoadError)

This is an error message that is coming back from the ruby program. Why did you get this? Because you're in the wrong working directory! There's no program in the /workspace/hello-world directory – it lives in the code directory underneath it. So first change to that directory by typing cd code. Now that your working directory is /workspace/hello-world/code, you can try running ruby hello.rb again:

Hello, world!

Let's try running the other program in that directory – go ahead and type ruby infinite-tacos.rb.

Tacos!
Tacos!
Tacos!
Tacos!
Tacos!

What a useful program! It simply prints Tacos! forever. You'll notice, though, that you never get returned to the prompt, because the CLI is stuck in the execution of the program. When you want to halt the execution of the program and return to the prompt, Ctrl+C to the rescue - hold down the control key and press "C".

infinite-tacos.rb:2:in `write': Interrupt

The program will stop and you should be back at the prompt.

Working with Github Codespaces

As you've seen, Codespaces is simply a cloud-based computer, running the Linux operating system, with a nice code editor (which is actually Microsoft's Visual Studio Code – open source FTW!) and user interface running on top of it.

Everything we'll want to do in this course can be done from the user interface or from the Terminal command-line. But there are a few things which are less intuitive due to the nature of a cloud-based environment.

The first thing is getting files to/from Codespaces from your actual computer. You won't have to do this very often in this course, because almost everything will be provided to you via a GitHub repository. But occasionally you might want to upload your own image or CSV file, or download some output created. Fortunately, doing so is very straightforward. To download a file, simply right-click on it in Explorer and choose Download. To upload a file, right-click a folder in Explorer, and select Upload. Try it now – upload an image from your computer to the images sub-folder.

The other, and more important, thing to know about Codespaces is that your development environment is not permanent. Your workspace will time out and shut down if not used within 30 minutes. No big deal – you can start it back up. To do so, don't follow the same steps as before (Code > Codespaces tab > Create codespace) - that will create a new codespace which may not have all your recent work (and will reduce the available resources on your free plan).  Instead, go directly to your Codespaces dashboard and reopen the recent codespace from there - everything will be just as you left it.

That said, eventually an unused codespace  – ones that haven't been started up within a 1-2 weeks – are deleted. Don't fret though! There's a simple solution to always preserving your work... commit and sync any work you do in Codespaces back to GitHub... do it early and do it often. GitHub repositories are permanent – they (and the entire history of your work within them) remain in your account unless you explicitly choose to delete them.

First, let's define the two main ways in which software is built and brought to market:

• Closed-Source: The software you work on is typically a commercial product, or exists to serve a commercial interest. Every line of code written is only seen by those working on it. The code, and the intellectual property that goes along with it, is an asset of the individual or company that owns it. Most software that is sold, whether as packaged software or software-as-a-service, fits into this model.  The source code behind your favorite web-based service likely does as well. After all, if a company's "secret sauce" has anything to do with the software code, they probably don't want anyone else having access to it. Companies compete by recruiting the best developers to build the best software, and these assets are to be kept behind closed doors under lock-and-key.
• Open-Source: The code behind the software you work on, whether it is a commercial product or not, is available to the public.

You may be asking – what motivates a software developer or company to pour hours – in some cases, thousands of hours – of work into a software project, only to make the code free and fully available to the public? The answer may vary based on the specific situation, but few examples may include:

• Crowdsourcing. By releasing source code to the public, a developer may be hoping for suggestions on improvement or, better still, contributions of work to the code that make the project better over time.
• The idea of transparency and "knowing what's in your food". For example, the developers of Telegram, an open-source messenger app, publish the source code to prove that they're not using your personal data for anything malicious – something that other commercial products can't promise.
• Credibility and reputation. An individual developer may choose to make a portion of their work open-source, in order to showcase their abilities to potential employers or future partners.
• Recruiting. A company may make some of their work open-source to attract potential future employees with the cool stuff they're building.

These are all great reasons for a developer or company to contribute their work to the world of OSS. But the biggest reason is a science-based culture of sharing and "no need to reinvent the wheel". As renowned computer scientist and Stanford CS professor emeritus Donald Knuth once said, "People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones." Software, like most things, is better built in cooperation with other humans. This idea – even within the context of commercial enterprises – has largely prevailed in the last decade or so over the concept of closed-source, proprietary software.

Licensing

How open-source software is licensed is a big topic, with many licensing models and derivatives of each model. Generally though, there are two ways in which an open-source developer might decide to treat their software project when sharing it with others:

• You may use this code in your project, but if you modify it, you must license the new work under the same model – the code can be used unmodified without restriction (GNU General Public License and other "copyleft" licenses)
• You may use this code however you want – you can modify it, sell it commercially, or include it within another open-source project (Apache, MIT, and other "permissive" licensing models)

More information on choosing a software license can be found at https://choosealicense.com/. Regardless of the licensing model used, it is certainly possible to use OSS to augment, or as the basis for, commercial ventures.

Case Study: The Linux Family Tree

GitHub - torvalds/linux: Linux kernel source tree

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

GitHubtorvalds

Here we have the source code for the Linux operating system. The core functionality of Linux (the "kernel") has been utilized (aka "forked") many times for use in both other OSS projects and commercial projects. Developers have taken the open-source Linux kernel source code and created their own "flavors" or "forks" of Linux, such as Ubuntu Linux, Red Hat Linux, Fedora Linux, and so on. It's estimated that nearly 78% of the Internet runs on servers powered by some flavor of Linux (96% of the top 1 million).

Meanwhile, in 2008, a team at Google built another "flavor" of Linux – the Android operating system. Because the Linux kernel is being used to power Android without modification, Google is able to license Android under the Apache License – a less restrictive, permissive license that allows others to modify and/or build on top of it, even for commercial purposes.

Android Open Source Project

Android unites the world! Use the open source Android operating system to power your device. COPY

Android Open Source Project

Today, Android is, as most of us know, the #2 mobile phone operating system behind iOS. As mentioned, Android is permissively open-source, although Google and its partners do bundle commercial, closed-source products, like Google Chrome and Google Play Store, alongside Android on the mobile hardware they sell. This is a straightforward example of one way open-source can be used to power for-profit enterprises.

Because Android is licensed using the Apache licensing model, developers are free to incorporate, modify, and distribute Android as they wish, even in commercial ventures. As a result, many companies have now forked and transformed the Android OS into the basis for its own products, including manufacturers of tablets, set top entertainment devices, and many other types of hardware. For example, Amazon has its own commercial, closed-source fork of Android – Fire OS – that it uses on its Amazon Kindle Fire products. Facebook has built its own closed-source and proprietary Oculus VR product on top of Android, as has Peloton as the backbone for its home-based fitness devices. All of these ventures can find their roots in Android and ultimately, Linux.

Other Interesting Open-Source Projects

GitHub - chromium/chromium: The official GitHub mirror of the Chromium source

The official GitHub mirror of the Chromium source. Contribute to chromium/chromium development by creating an account on GitHub.

GitHubchromium

ethereum

ethereum has 265 repositories available. Follow their code on GitHub.

GitHub

Git and GitHub

Those trying to understand open-source software for the first time often experience a bit of naming confusion among all the products and companies in this particular niche of an industry, so here's just a quick overview:

• Git is source control software, used by developers to store, manage, version, and collaborate on source code. It was created by Linus Torvalds (the creator of Linux) and, naturally, Git is open-source software.  
• GitHub is a for-profit corporation (owned by Microsoft) that is in the business of providing Git-related products and services, including Git project hosting and open-source developer productivity tools. Although we will be using GitHub to consume and share source code in this course, there certainly are companies that offer similar services, such as GitLab and BitBucket.

Git/GitHub How-To

Code projects in Git are organized into repositories. Typically, a Git repository houses a single code project, like some of the examples that we've discussed thus far. One of the primary services provided by GitHub is Git repository hosting. A GitHub user or organization will have typically have several Git repositories housed within it. For instance, the Microsoft organization on GitHub contains many repositories, one of which is the source code for the popular Visual Studio Code code editor.

As a first time software developer and GitHub user, you're not going to have any repositories within your GitHub account. It's time to change that.

There are two primary ways to create our own repository in GitHub:

• Create a repository by clicking the New repository option – either start from scratch or from code you already have on your computer, or;
• Go to an existing repository and use it as a template to start your own repository. This is the option we'll begin with, and will be using quite a bit throughout this course.

Start by visiting https://github.com/entr451-spring2026/hello-world and clicking the Use this template button. You'll be directed to a Create a new repository page – for the Repository Name, type hello-world, set the repository to be Public and click the Create repository from template button. It should take just a few seconds to create the brand-new repository in your GitHub account. You did it – you created your first GitHub repository!

Have a look around – you'll see that a GitHub repository is nothing more than a folder filled with files and other folders. You'll find that you can add your files, as well as edit the files already there. Try editing the README.md file by clicking little "pencil" icon. Make any change you want, then scroll to the bottom, to the Commit Changes section. The first box, which is pre-filled with Update README.md, is known as the Commit Message. This message is used to make a note to yourself (and others), describing the change you've made. Type something in the commit message (e.g. Made the README more awesome) and click the Commit Changes button. This takes the work you've done – in this case, making an edit to the README.md file – and commits the work. That is, it takes the unit of work you've performed and uses it to affect a permanent change to your Git repository.

It's important to understand that code and other files that are part of a Git repository are always being watched by Git. Because this constant observation is taking place, Git is able to know the entire history of your code; that is, what files are added, modified, and deleted by you and other contributors over time. This is what gives Git and other version control systems powerful abilities, such as reporting on individuals' contributions to our code project (what was contributed and when), time-travel (the ability to view or revert to our code at a previous period in time), and branching (different versions of the same project that began at the same starting point). Professional software developers use these features (and more) to manage complex software projects each and every day.

Course Structure

There is a tremendous amount of material covered in this course – the end-goal is to take a student who has done little to no software development before, and give them the ability to ship a software-based product by the end of the 10 weeks. To achieve this goal in such a compressed timeline, each week of this course will be broken down into the following:

• 3 40-60 minute units, with a 5-10 minute break in-between
• A typical unit will consist of some lecture, some hands-on demonstrations, and some lab exercises
• Practice exercises or a graded assignment to work on at home between classes

Getting Started – AKA stuff to do before the first class

There are three primary tools we will need to set up before the first class session, so we can hit the ground running:

1. A Web Browser. We'll be using Google Chrome. We like Chrome for its fast and consistent performance, and its built-in Developer Tools.
2. Git and Github. Git is a technology that professional developers use to store their code and share it with others. GitHub is a company that provides a popular hosted Git service. If you are familiar with Dropbox, you can think of GitHub as "Dropbox for code files."
3. A Development Environment. The "development environment" is just a fancy way of saying "all the stuff needed to build software". In the context of this course, this means – a computer, operating system, command-line interface, and code editor (something to edit code files). Professional developers often have their own personalized setups for all of this, but in this class, we'll be doing it all in the cloud, with a tool called Github Codespaces.

Step 1: Download and Install Google Chrome

Maybe you're already using Chrome to watch cat videos. If not, go get it: https://www.google.com/chrome.

Step 2: GitHub

Sign up for a free GitHub account at the GitHub website. IMPORTANT: please use your Kellogg email address to sign-up.*  You'll be using your GitHub account for lots of things in class – including turning in your homework and doing lab work in class – so keep your account information handy at all times.

* If you already have a Github account with a different email address, you'll need to add your Kellogg email address in your Github settings, and then set it as your primary email.

Step 3: Github Codespaces

Go to the Codespaces website and click "Get started for free".

If you're not already logged in to your Github account, you'll first need to sign-in (you already created an account in Step 2).

Once you've authenticated, you'll see your Codespaces dashboard.

My hope is to keep you on a free tier for the entire quarter. But, depending on your usage, you may need to upgrade at some point - the paid tier (i.e. "Pro") costs $4/mo.  I will provide tips to avoid this, but access to Codespaces is required for the course, so be prepared to upgrade if needed.  Once the course is over, you can choose to downgrade/cancel at any time.

Course Resources

ENTR-451 on GitHub

Our course GitHub page will be the main resource for all the code we'll be writing in the course. Find it at github.com/entr451-spring2026.

You won't see anything there yet, but we'll begin most exercises and assignments on Github, so it's worth bookmarking.

Slack

We will be using Slack for all communication, inside and outside of class. In class, you'll use Slack to post questions and get help from Faculty Associates and Professors. Outside of class, we'll use Slack for collaborating on lab exercises and homework assignments, and general questions/conversation.

We have our own Slack channel (not part of Kellogg/Northwestern's Slack). Access it via:

https://entr451.slack.com/

Important: You will need to first create an account.  To do so, click the "Create an account" link in the top right and use your Kellogg email address to signup.  Once you signup and login, you'll be dropped into the default #spring-2026 channel. Say hi!

Canvas

Every week, links to resources, slides, and code will be posted to the course Canvas page.  You will find the content in the Announcements and Assignments tabs.

That's it! You're ready. See you in class!

Twilio is a SaaS (Software as a Service) platform offering programmable telephony services.  Twilio allows software developers to programmatically make and receive phone calls, send and receive text messages, and perform other communication functions using its web service APIs.

Initial Setup

First, you'll need to signup for a free Twilio account.  Go to twilio.com and click "Signup".  You'll enter your name, email, and password.  Afterwards, you will need to verify your email address and your cell phone number.

During verification, you will receive a text message with a 6-digit verification code (you can request a phone call instead).  Afterwards, you'll be asked a series of questions about how you intend to use Twilio, beginning with "Do you write code?" and in what language.  Yes, you code!!!  (And in Ruby).  There are a few additional questions, but feel free to click "Skip to Dashboard".

Ok, up next, you need to get a free trial number to send messages from.  You should be on your dashboard at this point.  Click "Get a Trial Number".

Twilio gives you a starting balance to play with, so the number will be free.  You'll see the number Twilio suggests to you.  You're able to change it to a number with a specific area code and/or numeric pattern.  But, for now, just click "Choose this Number" and then "Done".

If all goes well, you'll be back on your dashboard and see your new Twilio number. Finally, it's time to code!

Adding the Twilio Ruby Library

Twilio has a ruby library that makes the API integration really easy.  In order to use it, you add the following line of code into your Gemfile.

gem "twilio-ruby"

Be sure this is not inside of one of the development or test groups - this library is needed in all environments (especially production).

Once you've added that code, you'll need to tell your application to install this library by running bundle install from your terminal.

Twilio API Credentials

Next, you'll need your Twilio API credentials.  You can find your credentials on your dashboard.

You'll need to add those credentials as environment variables to Gitpod (and later to Heroku).  Follow these steps before moving on.

Once you've set up your API credentials per the steps above, whenever you need access to those credentials in your code, you can do so this way:

twilio_account_sid = ENV["TWILIO_ACCOUNT_SID"]
twilio_auth_token = ENV["TWILIO_AUTH_TOKEN"]

Ruby Code

Now that the setup is done, we can use the Twilio library and our API credentials to send a text message (along with other Twilio functionality).

You can trigger a text message from anywhere in your code - you just need to know the number you want to send it to.  For example, let's say we want to send a welcome text to a user when they successfully complete signup in our application.

There's probably a users_controller.rb with a create action that saves a new user to our database.  To send the user a text message, we'll need to know their cell phone, so let's assume the users table has a phone column and the users/new.html.erb form requires that field.  The controller code then looks something like this:

class UsersController < ApplicationController
  def new
  end

  def create
    @user = User.new
    @user["first_name"] = params["first_name"]
    @user["last_name"] = params["last_name"]
    @user["email"] = params["email"]
    @user["password"] = BCrypt::Password.create(params["password"])
    @user["phone"] = params["phone"]
    @user.save
    redirect_to "/posts"
  end
end

So between the save and the redirect, we want to send a text message.

For the first step, we'll use the Twilio credentials to connect to the Twilio API.

twilio_account_sid = ENV["TWILIO_ACCOUNT_SID"]
twilio_auth_token = ENV["TWILIO_AUTH_TOKEN"]
client = Twilio::REST::Client.new(twilio_account_sid, twilio_auth_token)

Twilio Free Trial

During your free trial with Twilio, you can only send messages to verified phone numbers.  For now, that's your cell phone that you signed up with.  If you'd like to verify additional numbers (like those of your teammates or friends who will be testing your application), you can do so here and click the "+" sign.

Once you the free trial period ends, you'll be able to text any user's number (not just verified numbers).  We'll see below how this impacts the code.

Sending a text message

In the following code, the from is your Twilio trial number (the one on your Twilio dashboard).  The to is the number that will receive the text.  And the body is the message being sent.

The from and to numbers should use the E.164 format (i.e. [+][country code][number with area code] without any spaces or punctuation).  There are many technical ways to ensure this format, but while you're getting things working, you can just assume the user has entered it correctly.

client.messages.create(
  from: "+11234567890",
  to: @user["phone"],
  body: "Hey, welcome to my application!"
)

The above code will send a message to the user's phone.  However, this is when the verified numbers during the free trial period come into play.  

Once everything is working and you're ready to start paying for real text messages to real users, you can use the above code.  However, during the trial period, you should hardcode this number to be your number (or any of the verified numbers you've added to Twilio) so that only you or your team receive this text.

client.messages.create(
  from: "+11234567890",
  to: "+15555555555",
  body: "Hey, welcome to my application!"
)

Also, note that during the trial period, whatever message body you send will be prepended with "Sent from your Twilio trial account -".

Completed Code

All together it looks like this:

class UsersController < ApplicationController
  def new
  end

  def create
    @user = User.new
    @user["first_name"] = params["first_name"]
    @user["last_name"] = params["last_name"]
    @user["email"] = params["email"]
    @user["password"] = BCrypt::Password.create(params["password"])
    @user["phone"] = params["phone"]
    @user.save
    
    twilio_account_sid = ENV["TWILIO_ACCOUNT_SID"]
    twilio_auth_token = ENV["TWILIO_AUTH_TOKEN"]
    client = Twilio::REST::Client.new(twilio_account_sid, twilio_auth_token)
    client.messages.create(
        from: "+11234567890",
        to: "+15555555555",
        body: "Hey, welcome to my application!"
    )


    redirect_to "/posts"
  end
end

Don't forget to replace the to value with the user's phone when it's time to send real texts to real users!

And that's it.

There's a lot more you can do with the Twilio API.  It's incredibly powerful.  And hopefully a reminder that your application's backend code can do so much more than just expose a webpage.

This example is sending a text message on signup, but that is likely not your desired use case.  So the last step is deciding where in your application a text message feature makes sense - and, therefore, where to put the code.  We leave that to you...

The Problem

When first working with an API, it's often easiest to include your API credentials in your code.

It might look something like this:

# put your API credentials here (usually found on your API dashboard)
account_sid = "YOUR_ACCOUNT_SID"
auth_token = "YOUR_AUTH_TOKEN"

Exposing your API credentials in a Github repository isn't the best idea, and it's a horrible idea if the repository is public!  A public Github repository is just that, public - anyone can access it.  And then they can use your API credentials as they wish.  It's like sharing your account password with the world.  #bad

It's so bad, in fact, that many API services (Google, Amazon, Twilio, etc) scan public repositories for their API keys and, if they recognize one, they immediately revoke it (making it unusable).  If you pushed your code to Github with an API key, you may have received an email explaining this.

But even if your repository is private, API credentials that are in your code are still exposed to more people than necessary - everyone with access to the repository.

The Solution

Note: the following solution is applicable for securing any API keys.  The example is for Twilio, but it's good practice to apply to all credentials that should not be viewable in your repository's code.

So the solution is to "hide" our API keys by storing them in "environment variables" - variables stored on the "server environment" instead of in our code.

Step 1 - Replace this code...

# put your API credentials here (found on your Twilio dashboard)
twilio_account_sid = "YOUR_TWILIO_ACCOUNT_SID"
twilio_auth_token = "YOUR_TWILIO_AUTH_TOKEN"

...with this code, where TWILIO_ACCOUNT_SID is whatever variable you want (it could be TACOS); and same for TWILIO_AUTH_TOKEN.

# put your API credentials here (found on your Twilio dashboard)
twilio_account_sid = ENV["TWILIO_ACCOUNT_SID"]
twilio_auth_token = ENV["TWILIO_AUTH_TOKEN"]

If you have not yet added your API credentials into your code, just note that this is how you will do so when needed and move on to the next step.

Step 2 - Configure the environment variables in Gitpod:

To do so, go to gitpod.io/workspaces and click on your avatar in the top right.  You'll see a dropdown.  Click "Environment Variables".

On the next screen, click "Add Variable".  In the new row, the Name is the variable name you used above (e.g. TWILIO_ACCOUNT_SID or TACOS); the Value is the actual API key from Twilio; and the last column, the Organization/Repository needs to be */*.  Then repeat for the TWILIO_AUTH_TOKEN.  When you're done, it should look something like this:

If you had your workspace running, you'll probably need to stop it and restart it so that your "environment" (i.e. workspace) recognizes these new environment variables.  But then it should work properly.

Step 3 - Configure the environment variables in Heroku (optional):

If you're deploying your code to Heroku, you'll need to configure the environment variables there as well.  Every "environment" needs to know about these variables.

Go to your Heroku dashboard and click on your application.  Then navigate to the Settings tab.  In the 2nd section, there's click "Reveal Config Vars".  You'll see a list of environment variables that are preset by Heroku to make your application work in production.  There should be an empty row at the bottom.  Fill it in with the same Name and Value that you entered in Gitpod and click "Add".  Repeat so that both Twilio API credentials are configured.  It should look something like this when you're done:

And that's it!

Storing files, however, isn't as simple.  We can't just store a file in the database - that's not what database software is built for and it would take up too much space. Instead, files get uploaded to a publicly available computer and the file's location on that computer is what we store in the database.  Sending file data over the internet is a complicated bit of technology, but as with many aspects of our software development journey, we don't need to solve a problem that's been already solved - we just need to know when and how to apply the solution.

For the following examples, we'll use this repository - a final version of our Tacogram application.

ActiveStorage

File attachments are so common that the rails framework comes built with a library to handle it called ActiveStorage.  If you're curious about the library, the code lives here in the rails codebase.  There's also a thorough description of it in the Rails Guides here.  However, we'll walk through all the steps below (spoiler alert, there aren't that many), so the documentation is only useful/relevant when you want to dig in or do something a little out of the ordinary.

Installation & Setup

The first step is to generate a few new tables that the library will need - just to reiterate, the files don't get stored in the database, but the location of the files do.  Stop your server if it was running.  Then, from the terminal prompt, run the following command:

rails active_storage:install

The output will show a migration file copied over from the library into your db/migrate directory.  The file name has the usual migration timestamp followed by _create_active_storage_tables.active_storage.rb.  This migration file will create a few tables, but, as with all migration files, they need to be executed to take effect.  So the next step is:

rails db:migrate

Now if you check the schema, you'll see 3 new tables:

• active_storage_attachments
• active_storage_blobs
• active_storage_variant_records

We won't really think much about these tables - the library will be responsible for using them - but it's good to know they exist.

Next, open the file config/storage.yml.  This is a file we provided, but it never really differs from this, so you can copy it into any future applications.  A .yml file is a list of key-value pairs that is most often used for application configuration details.  Here we have a :local storage configuration which will store files into the server's file system.

local:
  service: Disk
  root: <%= Rails.root.join("storage") %>

The last setup step is to use this storage configuration in each environment running our application.  In the config/environments directory, open the file development.rb.

Development is the name of the "environment" used when we're building an application.  It's our Gitpod workspace or your personal computer.  It's where we "develop".  Production is the name of the "environment" where our application lives on the internet so that users can use it.  It's the "live" version of our application.  This development.rb file includes the configuration decisions for your application when it runs in the development environment.

At the bottom of the file, just before the closing end, add this line of code to indicate that we'll use the :local storage option in development.

config.active_storage.service = :local

Open up the production.rb configuration file and add the same code just before the closing end.

The ActiveStorage setup is done.  Configuration files load once when your server starts, which is why we haven't started the server yet.  You can start your rails server now and run the application.  Next we need to use the library in our code.

File Attachments

In the Tacogram application, we've been storing a post's image as a url in the image column of the posts table.  Instead, we want to upload an image file, so we need to augment the Post model with the ability to do so (using the ActiveStorage library).  Open up the models/post.rb file and add this code:

class Post < ApplicationRecord
  has_one_attached :uploaded_image
end

The has_one_attached method is given to us by ActiveStorage as a way of adding this upload ability.  We can use any name we want to reference the attachment (similar to the name of a column in the table) - uploaded_image is descriptive, but name it whatever you want as long as it doesn't conflict with any column names in the posts table (e.g. "image" is already used as a column name).

Now that we've given a post the ability to store an uploaded_image file, we need to modify the form so that a user can do so.  In views/posts/new.html.erb, first make sure the <form> tag can support file uploading - update it with enctype="multipart/form-data" so that it looks like this, if it doesn't already:

<form action="/posts" method="post" enctype="multipart/form-data">

Then, add a new label and input for the uploaded_image:

<div class="mb-3">
  <label for="uploaded_image_input" class="form-label">Upload Image</label>
  <input type="file" name="uploaded_image" id="uploaded_image_input" class="form-control">
</div>

Note that the label and input name match the name we used in the model, uploaded_image.  Also note that the input type is not text, but instead file which tells the browser to display this form input differently.  Refresh your browser to see the new input.

If you click on "Choose File", you'll be given the opportunity to browse and select a file on your device to upload.  You may notice, however, that you can choose any file.  For this application, we only want the user to upload images.  We can narrow down the user's visible options by adding an option to the form field.

<div class="mb-3">
  <label for="uploaded_image_input" class="form-label">Upload Image</label>
  <input type="file" name="uploaded_image" id="uploaded_image_input" class="form-control" accept="image/png, image/jpg, image/jpeg, image/gif">
</div>

The accept attribute has a string value with the file types the user can select.  A clever user can modify the html (see the frontend CSS lesson) so this doesn't protect our application very well, but it does improve the user's experience so that they don't unintentionally make a mistake.  Here we've accepted several image file types.  If you're looking for others, read the MDN documentation or google for "list of mime types".

Now when you submit a new post and look at the server log, you'll see new params related to this uploaded_image field.  Our create action in the posts controller isn't currently handling these params.  Open up the controllers/posts_controller.rb file so that we can modify the code.  Instead of the code that assigns the url to the image column, use this code to attach the file

@post.uploaded_image.attach(params["uploaded_image"])

The full create action now looks like this:

def create
  @user = User.find_by({ "id" => session["user_id"] })
  if @user != nil
    @post = Post.new
    @post["body"] = params["body"]
    @post.uploaded_image.attach(params["uploaded_image"])
    @post["user_id"] = @user["id"]
    @post.save
  else
    flash["notice"] = "Login first."
  end
  redirect_to "/posts"
end

The @post.uploaded_image.attach() code is functionality we enabled when we added has_one_attached to the Post model.  The argument we're passing into the parentheses is the params data from the form which includes the file selected by the user.

Go back to the new post form and submit another post with an image file.  You'll notice the index view of the posts does not show the uploaded image.  That's because it's still trying to read the url from the image column in the table.  So this is the last bit of code we need to change.

Open the views/posts/index.html.erb file.  The code currently displaying images is an <img> html element with an src attribute value of the post's image column.

<img src="<%= post["image"] %>" class="img-fluid">

That's the old functionality.  We want to display images using the new functionality.  We could just modify this code, however, that won't account for any existing data that was created using the old way.  Instead, the code should handle data created the old way (aka "legacy data") and data created the new way.  Sounds like conditional logic.

The condition we'll check for is if the post has an attached uploaded_image:

<% if post.uploaded_image.attached? %>

The attached? method will return true or false and is more functionality enabled by that has_one_attached change we made to the model.

If it's attached, display it, otherwise, display the image column.

<% if post.uploaded_image.attached? %>
  ...display the attached image file
<% else %>
  <img src="<%= post["image"] %>" class="img-fluid">
<% end %>

It would be nice if it was as simple as post["uploaded_image"], but again remember that we're not reading a column from a table.  Instead, we need to find where this file exists on the server's computer (or anywhere on the internet for that matter) and then use that url.  The code is url_for(post.uploaded_image).  And the final code looks like this:

<% if post.uploaded_image.attached? %>
  <img src="<%= url_for(post.uploaded_image) %>" class="img-fluid">
<% else %>
  <img src="<%= post["image"] %>" class="img-fluid">
<% end %>

Refresh the browser and you should now see the uploaded image file.  If you inspect the html for each post, you'll notice that the src value for the old posts are the urls submitted via the form, but the src value for new posts are all uniform.

/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBCZz09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--0bb9db65c8a23883995f028cdb4bea3a68fde563/your_image.jpeg

They're stored on the Gitpod server's machine within a subdirectory of our rails app.

Technical Debt

This conditional logic is what we call "technical debt" - code that solves a problem but should be cleaned up eventually.  Since we're no longer supporting the feature of simple image urls for posts, it would be best to migrate the legacy data so that all records use the new behavior.  This will help with maintainability over time and avoid fragility in our code.  But modifying the legacy data is not a simple task and is not without risk.  We could deal with it now, but that would block this new feature.  So instead we decide to deal with it later, or "pay off that technical debt" later and use a simple fix for now.

Technical debt is a reality of any application as it evolves - it's not a bad thing, just a reality that we need to be aware of and make time for when possible.  

Authorization refers to what a user can do once they're authenticated.  It also can include what a user sees (and also what a non-user doesn't see).  Let's start with that.  Let's look at that navbar again and hide the login/signup links when a user is logged-in.  And similarly, we'll hide the current user's name if there is no current user.  Open the /app/views/layouts/application.html.erb file and add some conditional logic based on the condition if @current_user.

<p>
  <% if @current_user %>
    <%= @current_user["first_name"] %>
  <% else %>
    <a href="/sessions/new">Login</a> |
    <a href="/users/new">Signup</a>
  <% end %>
</p>

Refresh the browser and you should no longer see the login and signup links.

To test the else condition, we need to logout the current user.  To do that, let's add a destroy action to the sessions controller that will "delete" the current session.  Typically a destroy action will delete a row from a table, but in this case, we just want to "delete" the cookie so that the browser no longer "remembers" that a user is logged-in.  We can do this by adding the destroy action and then re-assigning the value of the cookie as nil which effectively will mean there is no current user.

def destroy
  flash["notice"] = "Goodbye."
  session["user_id"] = nil
  redirect_to "/sessions/new"
end

The url we would normally use to get to this path would look something like a DELETE request to /tacos/123where 123 is the id of the row we want to delete.  But with a session, there isn't an id, so this RESTful path doesn't really make sense.  Occasionally, when the REST pattern doesn't fit, we add a custom path and tell our app where to direct the request to.  Open up the routes file /config/routes.rb and add the following code at the bottom below the resources.

get("/logout", {:controller => "sessions", :action => "destroy"})

This code is registering the /logout path as a GET request.  When our application server receives that request, it will direct it to the destroy action within the sessions controller.  While we're at it, let's add a custom path for login as well, just to keep some nice naming consistency.

get("/login", {:controller => "sessions", :action => "new"})

The entire routes file now looks like this:

Rails.application.routes.draw do
  resources "companies"
  resources "contacts"
  resources "activities"
  resources "tasks"
  resources "users"

  resources "sessions"
  get("/login", {:controller => "sessions", :action => "new"})
  get("/logout", {:controller => "sessions", :action => "destroy"})

  # Landing page (aka root route)
  # get("/", {:controller => "", :action => ""})
end

Now that the application can receive this "/logout" request, let's add a logout link to the navbar.  We can also modify the login link there as well.

<p>
  <% if @current_user %>
    <%= @current_user["first_name"] %>
    <a href="/logout">Logout</a>
  <% else %>
    <a href="/login">Login</a> |
    <a href="/users/new">Signup</a>
  <% end %>
</p>

Refresh your browser and you should see the Logout link alongside the current user's name.  Click it and the sessions destroy action will reset the cookie so that the current user is "logged-out" and redirected to login.

Login again, and you'll be back at the companies index and see the current user's name and logout link.  We are now "authorizing" what a logged-in user can see vs a logged-out user (aka "visitor").

Activities

In our CRM domain model, there are companies and contacts and salespeople (i.e. users).  There are also activities which are related to both contacts and users.  This app came seeded with a couple rows in the activities table.  Navigate to the "Apple" show page and then the "Tim Cook" show page.  There you'll see a couple activities.

Firstly, if a user is not currently logged-in, they should not be able to see or add activities.  One could argue, they shouldn't be able to see contacts or companies either for that matter, but let's just focus on activities for now since activities are very explicitly user-related.  

So we should hide anything in this view that only logged-in users should be able to access.  Open up this file (/app/views/contacts/show.html.erb) and let's wrap the relevant code in an if @current_user conditional block.

<% if @current_user %>
  <p><a href="/contacts/<%= @contact["id"] %>/edit">Edit Contact</a></p>

  <form action="/contacts/<%= @contact["id"] %>" method="post">
    <input type="hidden" name="_method" value="delete">
    <button>Delete Contact</button>
  </form>

  <h3>Sales Activity</h3>

  <ul>
    <% for activity in @activities %>
      <li>
        <%= activity["activity_type"] %>
        <br>
        <%= activity["note"] %>
      </li>
    <% end %>
  </ul>

  <h4>Log Activity:</h4>

  <form action="/activities" method="post">
    <p>
      <select name="activity_type" id="activity_type_select">
        <option value="call">call</option>
        <option value="email">email</option>
        <option value="meeting">meeting</option>
      </select>
      with <%= @contact["first_name"] %> <%= @contact["last_name"] %>
    </p>

    <p>
      <label for="note_input">Note</label>
      <textarea name="note" id="note_input"></textarea>
    </p>

    <input type="hidden" name="contact_id" value="<%= @contact["id"] %>" id="contact_id_input">

    <button>Submit</button>
  </form>
<% end %>

Now the activity data and the new activity form will only appear for a logged-in user (and for good measure, we'll also hide the contact edit and delete links since non-users shouldn't be able to access those either).  If you haven't done so, logout and refresh the page to confirm this is working, and then login again.

This is an improvement.  But the activities we see here aren't our activities - as in, they're not the activities for this current user.

If you look at this data in the database, you'll notice that these activities are related to a contact (i.e. their contact_id column is the id for "Tim Cook"), but they are not related to a user (i.e. their user_id column is nil).  Add a new activity using the form and the same will be true - the activity does not know that it's related to the current user.

Now that we have awareness of a current user, when we create a new activity, it should be assigned to this user.  To make that change, we need to go to the code where the activity gets created.  We could add a hidden form input and add the current user's id there, but html is easily manipulated by anyone who knows how to view source.  So that wouldn't be very secure.  Instead, we'll do this in the backend code that only us developers can access.  The new activity gets created in the activities controller's create action.  Let's look at that code:

class ActivitiesController < ApplicationController
  def create
    @activity = Activity.new
    @activity["contact_id"] = params["contact_id"]
    @activity["activity_type"] = params["activity_type"]
    @activity["note"] = params["note"]
    @activity.save
    redirect_to "/contacts/#{@activity["contact_id"]}"
  end
end

All of the form data is being assigned properly, but there's another column in the activities table that's not being assigned: user_id.  So let's just add a line of code to assign that as the current user's id:

def create
  @activity = Activity.new
  @activity["contact_id"] = params["contact_id"]
  @activity["activity_type"] = params["activity_type"]
  @activity["note"] = params["note"]
  @activity["user_id"] = @current_user["id"]
  @activity.save
  redirect_to "/contacts/#{@activity["contact_id"]}"
end

That's it.  As you're seeing, with access to the @current_user record, we're able to build logic and add context throughout the application - it's really becoming a complete piece of software!

Go back to the activities form and submit another activity.  You'll see it displayed in the list of activities just as the other records are, but the data in the table has changed in a very meaningful way.  The previous rows have an empty value (i.e. nil) in the user_id column.  But this new row has the current user's id in it.  If you were to logout and login as another user, and then create another activity, that row would have a different value in its user_id column.  Activities are now related to both contacts and users.

There's one last improvement we can make.  Instead of displaying all of the activities here, we should only display the current user's activities.  The activities are displayed in a loop in the contact's show view (the same file we modified above with the if @current_user logic).

<ul>
  <% for activity in @activities %>
    <li>
      <%= activity["activity_type"] %>
      <br>
      <%= activity["note"] %>
    </li>
  <% end %>
</ul>

Since we're in the contact's show view, the @activities variable must be defined in the contacts controller's show action:

@activities = Activity.where({ "contact_id" => @contact["id"] })

This is querying the activities table for all rows where the contact_id column value is this contact's id (in the example above, that's Tim Cook's id).  We can refine the query to also filter by the current user's id so that only this user's activities are returned:

@activities = Activity.where({ "contact_id" => @contact["id"], "user_id" => @current_user["id"] })

Now the SQL query will filter by contact_id AND user_id.  Refresh the browser and you should only see the activity you created as this user.  You can also look at the server log to see the SQL that gets executed.

There's one possible problem.  If you logout and return to Tim Cook's page, previously we were hiding the sales activity and form, but you could still see Tim Cook's details.  However, now you'll see an error:

The bug is due to the fact that @current_user is nil when logged-out.  And you can't try to read the id column of nothing.  It's a possible problem because maybe a logged-out user shouldn't ever be able to get to this page in the first place.  We could conditionally check if @current_user in this action and simply redirect a logged-out user.  But, to maintain the functionality that we had before, let's just account for the possibility of a logged-out user.  The simplest way to do this is to instead use the value from the session hash which won't produce an error, but will simply be nil if there is no logged-in user.  Here's the modified code:

@activities = Activity.where({ "contact_id" => @contact["id"], "user_id" => session["user_id"] })

And now you can refresh the page and no more error.  Login again, and you'll only see the activities for this current user.  Success!

Besides the concept of @current_user and how it gets assigned in a before_action method, you may have noticed that the rest of this authorization code is really no different from anything we've done before - authorization at its core is just the use of conditionally logic, sql queries, and column assignment.  Look at the code we used to add user context to the application:

• if @current_user
• @activity["user_id"] = @current_user["id"]
• Activity.where({ "user_id" => session["user_id"] })

With those tools, you have almost infinite control over the authorization logic in your applications.  With that said, let's practice with a new resource: todos.

Todos

If the canonical first app in every language is "Hello, world", then the canonical second app is almost always a list of todos.  So let's check that box (pun intended) for you.

This repository already has some MVC (model-view-controller) architecture for a tasks resource - tasks/todos, tomato/tomahto.  There is a Task model and table - the tasks table has columns for id, description, and user_id.  The routes file is exposing the tasks resource.  There is a tasks_controller.rb file with index, create, and destroy actions - the destroy is used when a task is "completed".  And there is a tasks index.html.erb file which includes the new task form and a loop of @tasks.

Take a look through the code and then visit the /tasks path (i.e. the tasks index view) in the browser.

And try submitting a new task.

This is a weird todos app as-is.  New tasks don't have any context of a user, so if you were to ship this app, it would be a global/public todo app.  Maybe an interesting social experiment, but not really useful for personal productivity.  To fix this, implement the following user stories.  Since we're still in the same repository with all of the existing authentication code, you only need to focus on authorization logic.

Lab - User Stories

• As an anonymous user, I cannot create new tasks.
• As a signed-in user, I want to create new tasks.
• As a signed-in user, I want to see my tasks.
• As a signed-in user, I want to be able to complete my tasks.

The steps to complete these are below, but try to work through it yourself before looking.

Lab - Solution

First user story:

As an anonymous user, I cannot create new tasks.

Currently, anyone can submit the new task form even if logged-out.  We can change that by hiding the form in the index view file (/app/views/tasks/index.html.erb):

<% if @current_user %>
  <form action="/tasks" method="post">
    <input type="text" name="description">
    <button>Add new task</button>
  </form>
<% end %>

If we want to be helpful to the user, we can add an else condition that says something like "You must login to add todos".  That's up to you.  Reload the page and the form should now be hidden.  User story ✅ complete.

Second user story:

As a signed-in user, I want to create new tasks.

Login as a user and navigate back to the tasks index page.  The task form is there.  At first glance, this user story is already done.  However, this is where these user stories are a bit too vague.  A better user story would say something like:

"As a signed-in user, I want to create new tasks, so that I can keep track of things I need to do".

Thinking like a developer now, we can interpret a bit more clearly that these tasks will need to be related in the data to the current user.  To implement this, we need to go to the code where the task gets created, the tasks controller create action.

  def create
    @task = Task.new
    @task["description"] = params["description"]
    @task.save
    redirect_to "/tasks"
  end

Recall that a task has a description and a user_id column.  The former is assigned based on the submitted form data.  So we just need to assign the latter.

@task["user_id"] = @current_user["id"]

Now when the a new task gets created, it will be related to the current user so that the user can "keep track of the things [they] need to do".  User story ✅ complete.

Third user story:

As a signed-in user, I want to see my tasks.

Currently, all tasks are displayed in the view regardless of who is logged-in.  Good thing we implemented that second user story correctly.  Now that tasks are related to users, we can query for only the current user's tasks.  Since the view is the tasks index view, the code we want is in the tasks controller index action:

  def index
    @tasks = Task.all
    @task = Task.new
  end

Instead of Task.all, we'll modify it to query by the current user's id.

@tasks = Task.where({ "user_id" => @current_user["id"] })

Now if you refresh the page, you should only see tasks you created as this user.  If you don't see any tasks, you probably haven't created any yet as this user.  Try submitting a new task.  To test this out thoroughly, you can logout and login as another user, create a new task, and confirm that you only see that user's tasks as well.

However, if you logout and try to view this todo app as a logged-out user, you're going to run into that same bug from before because @current_user["id"] will raise an error when there is no current user.  There are plenty of fixes for this bug, but the simplest is to use the session cookie instead:

@tasks = Task.where({ "user_id" => session["user_id"] })

And now the error should go away.  User story ✅ complete.

Fourth user story:

As a signed-in user, I want to be able to complete my tasks.

Looking at the tasks index.html.erb code, the complete button is part of the @tasks loop:

<%= button_to "Complete", task, :method => "delete" %>

Since the @tasks loop is only showing the current user's tasks, then the "complete" button is only being displayed for this user's tasks.  So we can probably consider this user story done.  

However, putting on our security hats for a moment, what if we were to view the source code in the browser to see what's going on?

Here's the final html that our app is sending to the browser.

<form method="post" action="/tasks/3">
  <input type="hidden" name="_method" value="delete" autocomplete="off" />
  <button type="submit">Complete</button>
  <input type="hidden" name="authenticity_token" value="lfNjSdpeuV27vux8x9ChX1O-MIpwMZ1O-9pdz1aSRV2frkv__2zhAlt5ZzxjrXX6wI2Q0U81fuDbMLgCeXEHiQ" autocomplete="off" />
</form>

There's a lot of noise there and some helpful code that rails is building for us.  But the critical code is where this form submits to which is the action attribute of the <form> element: action="/tasks/3".  The path is to /tasks/3 where 3 is the id of the task row that we want to "complete".  As a clever internet user, you may know that you can actually edit that id by opening up the Chrome developer tools and inspecting the html.  If you change that action to /tasks/1 and click the "complete" button, the request will go to the tasks controller destroy action, query for Task.find_by({ "id" => params["id"] }) and find the row where the id is 1 (or any other value you change it to).  All of a sudden, a clever user can "complete" any task they want, even if it's not their user's task.  Bad.

We can protect against this type of malicious behavior fairly simply in our backend code.  Here's the destroy action as-is:

def destroy
  @task = Task.find_by({ "id" => params["id"] })
  @task.destroy
  redirect_to "/tasks"
end

Let's modify it slightly by wrapping the @task.destroy behavior in conditional logic that checks if this task is related to the current user.

def destroy
  @task = Task.find_by({ "id" => params["id"] })
  if @task["user_id"] == @current_user["id"]
    @task.destroy
  end
  redirect_to "/tasks"
end

The code @task["user_id"] == @current_user["id"] will only be true if this task's user_id column matches the logged-in user's id.  So even if a clever user tries to modify the html, nothing will happen unless the path finds a task that they created.  User story ✅ complete.

Test out the todos app now - it should behave as you'd expect as a user.