Previous Lecture Lecture 17 Next Lecture

Lecture 17, Wed 05/05

Wed Lecture: continue team03

First Peer Evaluation survey (participation grade P10), due Friday

Your peer ratings may be:

In cases where the spread is small, these peer ratings will not signficantly impact your grade. But, in cases where the performance is significantly higher or lower than the mean (measured by standard deviation), we may apply a multiplier to your grade that increases or decreases it.


Separately from how your teammates rate you:

I’d like this done by Friday so I can analyze result over the weekend, and share them before Monday’s class meeting.

Team02 update

Team03 update


Here’s the status as of 10am this morning:

When teams are done, the following Heroku applications should be up and running:

Section Team 1 Team 2 Team 3 Team 4
5pm App🔸Dashboard App🔸Dashboard App🔸Dashboard App🔸Dashboard
6pm App🔸Dashboard App🔸Dashboard App🔸Dashboard App🔸Dashboard
7pm App🔸Dashboard App🔸Dashboard App🔸Dashboard App🔸Dashboard

I’d like to see all of those as ✅ by the end of class today, so that you can start your next team activity: getting to know your legacy code app as an end user, and as an admin.

To be clear: the ❌ marks are all on pages that have not yet even attempted to deploy the app on Heroku. So let’s briefly go over is required to get the app up on Heroku:

What is a qa deployment of an app?

We speak of a deployment or instance of an app as a separate instance of the app running somewhere.

These app instances, one per team, are intended to be quality assurance (qa) deployments.

They are to be used for testing out changes to the app so that you can be “assured” that they improve the “quality”, before doing a pull request to merge them into the main branch.

Are these instances fully separate, or do they share any data in common?

Usually, these separate instances work from separate databases; this is necessary and appropriate when the app has read/write access to the databases.

In a few cases, they apps all share a common database; this is typically possible when the database is read only, and the database schema (the way in which the information is structured), is not changing much, or at all:

Here are the details:

Getting to know your team’s legacy code app

The team’s qa apps can also be used to get to know the app’s features, especially the admin only features.

You can get to know the legacy code apps as user to some extent, by using the three production versions:

However, each of the apps has “admin only” features that you need to be an administrator to access. We generally don’t give admin access on the production apps to students in the class, so to test admin features, you need to have your own instance of the app.

Deploying Apps on Heroku: Linking requires Admin access to the repo

To deploy an app on Heroku, the Heroku app needs to be linked to the repo by someone that has “admin” access to the repo. This is why we created these Heroku apps on behalf of each team.

Sometimes, teams may need an additional Heroku instance of their app.
Here are some workarounds:

In your breakout rooms:

Today’s first goal: Up and running

The first goal is to get your team’s app is up and running, i.e. so that when you click the “App” button, you see a home page similar to the ones shown below, and can use the login button to login:

proj-ucsb-courses-search proj-ucsb-cs-las proj-mapache-search  
proj-ucsb-courses-search-home-page proj-ucsb-cs-las-home-page   proj-mapache-search-home-page

Then, you should edit the variable that sets the initial admins, to include some from your team. That looks like this:

Those team members should then be able to see the admin menu. These admins are called “permanent admins”, because their admin status is hard coded into the environment variables. On the admin menu, they should be able to promote other users that have logged in to admins. For these users, their admin status is stored in the database.

Once your team’s app is up, then what?

If you haven’t done it yet, all members of your team should join slack channel for your teams app (i.e. one of #proj-ucsb-courses-search, #proj-ucsb-cs-las or #proj-mapache-search.)

Now, start exploring the features of the app, as individuals and as a team.

As you explore, make posts to your team’s slack channel. Also monitor the discussions, if any, on the project’s channel (i.e. one of #proj-ucsb-courses-search, #proj-ucsb-cs-las or #proj-mapache-search.)

Here are questions that should prompt some posts:

By Monday, each student is asked to please make at least two posts based on interacting with the app.