lab01 : Getting Started

num ready? description assigned due
lab01 true Getting Started Fri 01/12 01:00PM Fri 01/19 11:59PM
https://ucsb-cs148.github.io/w24/lab/lab01/
Points

Announcements

Step 0: Find your assigned seat and meet your mentors

We have 14 teams set up:

Table # 1pm 2pm 3pm  
1 pj01-universityclothing (mentor(s) TBD) pj04-courserecs (mentor(s) TBD) pj05-codegrow (mentor(s) TBD)  
2 pj02-travelplanner (mentor(s) TBD) pj06-foundit (mentor(s) TBD) pj07-datingalgorithm (mentor(s) TBD)  
3 pj03-intelligrocery (mentor(s) TBD) pj10-spotifai (mentor(s) TBD) pj08-reccen (mentor(s) TBD)  
4 pj11-songrater (mentor(s) TBD) pj13-researchhelper (mentor(s) TBD) pj09-liveordie (mentor(s) TBD)  
5 pj12-appblocker (mentor(s) TBD)      
6 pj14-ucsbcoral (mentor(s) TBD)      

Teams: Let’s start meeting at the table numbers listed in the above table. We can decide later to spread out more if that is preferred.

Please check in with any team members who are not in the classroom via your team channel in Slack right away!

This lab has two components. One part to complete ASAP (Step 1 to Step 4 below, to be completed mostly today in Section or as soon as possible afterwards) and one graded part that is due by the end of next Friday, Jan. 19th 2024. One week is the typical time period for lab assignments. In each lab starting with next week, you should make sure as a team that you have completed all lab deliverables from the previous week.

Graded: (20 pts) You earn these points if/only if:

  • your group reached Milestone 1 described below in Step 2, on top of which every member branched the team repo and did a pull request to submit a file named after themselves in the teams folder from their own branch, and the team together created a NORMS.md file. This is the goal for Section today.

——— Over the coming week: —————————————–

Graded: (20 pts) You earn these points if/only if:

  • your group logged your first Scrum meetings (including lec02.md and at least one of lab01.md,lab02.md) in the sprint01 subfolder.
  • you took accurate attendance, accounting for all members of your group (See the teams page for a list of group members)
  • the meeting notes the scribe took are added to the above files. For future meetings, you will replace lab01 with the respective meeting time denominator (e.g. lec05 or 10-17-2pm)

Graded: (20 pts) You earn these points if/only if:

  • your group produced a problem scenario in the form of a github file ‘./team/problem_scenario.md’, and
  • a user journey documentation in the format of your choice. Summarize what you came up with in a file ‘./team/user_journey.md’

Graded (lab01-I): (20 pts) towards (lab01-I) is your individual grade for lab01. Your mentor will check with each of the team members to see if they got a Hello World app running. These reviews can be as simple as pointing the mentor to a deployed web app, or it could involve the team member demoing an app to the mentor. Your TA or instructor will then do an independent assessment, informed by the mentors review, and assign a grade. If you are unsure about your code/project following good practice, you are encouraged to complete it early and meet with your mentor, your TA, or another mentor/TA during arranged meeting time or office hours to go over it in advance. The components of this grade are listed below. These points cover the basic functionality and code of your Hello World app on the basis of the app review. The remaining points cover mechanics of the release process (issues, version control, deployment/demos).

Graded (lab01-T): (20 pts) (lab01-T) is your Team grade for lab01. As part of this grade, each team member should have contributed to a hello world assignment as an individual or as part of a group by the due date/time of this lab, i.e. (Fri, Jan 19 at 11:59PM)

For teams of 6, this part of your grade is 5 points per team member. For teams of 7, it is 4.28 points, for the team of 8 it is 3.75 Those points are all or nothing; if you’ve made a reasonable attempt, even if you didn’t earn 100% on lab01, your team will earn the points for your contribution towards the whole.

This component of your team grade is designed to encourage each team member to reach out to all the other members of the team, and be aware of the progress they are making towards the goal of having every team member complete a hello world assignment as an individual or as part of a pair. The most important learning goal of the course is to learn to work as a team, supporting one another.

Step 1: Create a CoE account if you don’t have one already

You could do all the necessary work this quarter on your own computer, but very likely it will be convenient for you to test things with your team on a computer in one of the Computer Science Labs.

To log on to the machines in the Computer Science labs, or to connect remotely, you will need a College of Engineering account. You can create an account online at https://accounts.engr.ucsb.edu/create.

If you are enrolled in any CoE course this quarter (including CS148), you should be able to create your account immediately.

If you are not able to do so, you will need to contact the ECI Help Desk at help@engineering.ucsb.edu.

Step 2: Get setup with github and add yourself to our organization

We will be using github.com in this course. We have created an organization called on github.com where you can create repositories (repos) for your assignments in this course.

The advantage of creating private repos under this organization is that the course staff (your instructors and TAs) will be able to see your code and provide you with help, without you having to do anything special.

To join this organization, you need to do three things.

  1. If you don’t already have a github.com account, create one on the “free” plan. Visit https://github.com/

  2. If you don’t already have your @umail.ucsb.edu email address associated with your github.com account. go to “settings”, add that email, and confirm that email address.

  3. Visit our Github Sign Up Tool at https://ucsb-cs-github-linker.herokuapp.com/. Navigate to https://ucsb-cs-github-linker.herokuapp.com/. Login with your github.com account. Click “Home”, find this course (CS148, W24), and click the “Join course button”. That will automatically send you an invitation to join the course organization on github.

  4. There should be a link to the invitation for the GitHub organization for this course (https://github.com/). Click on the invitation link and accept it. You can also go straight to https://github.com/ and see the invitation there (if you’re logged in). Accept the invitation that appears in your browser (from step 3) or log into your account on https://github.com/ to accept the invitation.

Milestone 1: Once all your team members have successfully joined the organization, send a message in your Slack team channel that states “Milestone 1 completed!”. This is important, because we will run a program to automatically create GitHub repositories for your teams once all the teams in this Section have completed this milestone.

Step 2a: Decide where you will work

Your first step here is to decide whether you are going to work:

Here are some of the pros and cons:

Location Pros Cons
Your own machine Less likely to run out of disk space Must install software
CSIL No need to install software May run out of disk space, especially for Next.js

Notes for running locally

Note for running on CSIL

Step 2b: Install Git

Skip this step if you are working on CSIL; git comes pre-installed.

If you decide to work locally, you’ll need at least git on your local machine.

When you can type git --version at the command prompt on your system, and it shows a version rather than an error such as command not found, you are ready to proceed.

Step 2c: Configure git

You may skip this step if you’ve already configured git on the machine where you are working.

Step 2d: Configure name and email

When you use git to add commits to a project, it attaches your name and email to the commit as part of the metadata.

To configure this, type the following commands, substituting in your name in place of Your Name and your email in place of you@example.com.

git config --global user.name "Your Name"
git config --global user.email you@example.com

Step 2e: Configure ssh keys

Configuring ssh keys for GitHub allows us to allows us to avoid having to type in our git password many times per session. So while not strictly required, it is highly recommended. All further instructions in the course will assume you have done this step; if you don’t, you’ll need to adjust the instructions to use https based urls instead of the SSH based ones that start with git@github.com:.

To configure your SSH keys for GitHub, follow these instructions.

Notes:

Step 2f: Clone your repo

For this step, please wait until you get the ok from the instructors that your project group repos have been generated.

Then, on your computer of choice, cd in the directory where you plan to do your work for this course (e.g. perhaps ~/cs148), type this command to clone your empty repo into that directory. In place of repo-url-goes-here, copy the URL for the new repo you created. That will be, for example: git@github.com:ucsb-cs148-w24/cgaucho_lab00.git but with cgaucho replaced with your GitHub id.

git clone repo-url-goes-here

That should create a new empty directory (well, almost empty) called lab00-cgaucho. Use cd lab00-gaucho to put yourself in that directory.

If you then type ls -a you’ll see that the directory is not completely empty. It contains a .git subdirectory, which is how you know that this is a git repo rather than an ordinary directory.

Step 3: Each of you INDIVIDUALLY now makes a branch of the repo

The next step is done as an individual

Step 3a: Inside your branch of the repo, create a file called team/your_first_name.md

In your branch, NOT on the main branch of the main repo, please do the following:

Make a directory called team. Inside this, create a markdown file named your_first_name.md containing a brief description of you and of your ideas for the project.

Each team member should do this individually. Note that this will be publicly displayed on the course site.

Step 3b: Do a pull request from your branch that has your file called team/your_first_name.md.

Do a pull request from your branch to the main branch of the repo. Each team member should have done at least one pull request from their github id.

Step 4: Create your team/NORMS.md file

This is a list of ideal team behaviors, e.g. everyone arrives to meetings on time or everyone starts things tasks early. You should write this as a team. Only one student needs to submit a pull request containing this file, however it is ok if there are multiple pull requests for this file. You should be careful, however to avoid merge conflicts!

The team/NORMS.md file should contain all of the team norms. It is ok to “suggest” team norms in your individual team/first-name.md files, but the team, ultimately, should consolidate all of these into one team/NORMS.md file.

Graded: (20) You earn these points if/only if:

  • your group reached Milestone 1 described in Step 2, on top of which every member branched the team repo and did a pull request to submit a file named after themselves in the teams folder from their own branch, and the team together created a NORMS.md file.

To be completed over the coming week:

Step 5: Document your meetings

During lec02, you will have first practiced logging meetings in GitHub. Make sure to log any standup and other team meetings as well, and capture it as lab01.md and\or lab02.md in the sprint01 folder you created in lecture. Reminder: In your github repository, you structure the documentation of your meetings into ‘sprints’ (which are week-long unless you as a team decide on a different interval).

Graded: (20) You earn these points if/only if:

  • your group logged lec02.md and at least one of lab01.md lab02.md meetings in the sprint01 subfolder.
  • you took accurate attendance, accounting for all members of your group (See the teams page for a list of group members)
  • the meeting notes the scribe took are added to the above files. For future meetings, you will replace lab01 with the respective meeting time denominator (e.g. lec05 or 10-17-2pm)

From now on, please document all your meetings in the github repository in this way.

Step 6: Discuss the User Journey

As a team, discuss the “user journey” for your proposed application.

That is, try to describe all of the events that lead someone to seek out your product and have an interaction with it, or perhaps a series of interactions.

There should be a beginning, a middle and an end, where value is exchanged:

Identify:

Discuss this with your group, and capture (perhaps in a Google Doc?) whatever comes to mind.

The beginning of your user journey is a Problem Scenario as discussed in class, which is basically a short story, involving a subset of the concrete Personas you came up with in assignment h02 and expressing what the people eventually will want to achieve with your product and what the problem is with current solutions.

Beyond the problem scenario, you can document the design of your user journey in free form.

At this stage, it is important to get the ideas flowing. There is no specific “right or wrong” way to get your ideas down on paper (or, rather, eventually, a GitHub markdown file). Just write something that captures the group consensus, or the candidate proposals, for the “user journey”.

It can take any form: a list, or pictures, a collection of As a ** I can ** so that __ type stories, or any combination of those. Don’t get bogged down on what form it takes. Just get something down.

NOTE: Try to keep your description VERY HIGH LEVEL, avoiding specific implementation details.

You don’t have to do this “perfectly” the first time. You may need to first get it all out as “brain dump” that contains too much detail, and then move to a higher level. But get to the higher level as soon as you can.

Don’t move on to the next step until you have the “spine” of your customer journey captured in some fashion.

You’ll know you have it, and you are ready for this step when:

Graded: (20) You earn these points if/only if:

  • your group produced a problem scenario in the form of a github file ‘./team/problem_scenario.md’, and
  • a user journey documentation in the format of your choice. Summarize what you came up with in a file ‘./team/user_journey.md’

Step 7: Move towards minimum viable product (MVP)

(This step is not graded, per se, but you can’t meaningfully accomplish later stages if you try to skip it.)

At the moment, you have an idea and scenarios for your application.

At this stage, the story you have might have gone in one of two directions:

It’s likely that each of our teams will be somewhere on the spectrum between these two extremes. Discuss where you think your team is on that spectrum.

Assuming that your team is somewhere closer to GV than to MVP, you’ll now want to set aside the description of your GV for the moment. Use it as a reference to inform your efforts to redo the exercise, but focusing on an MVP.

Maybe you can draw on top of your GV description, and highlight the parts that you think might be part of your MVP.

The big question to keep in mind is:

How can we make “this” possible for the user with less complexity, less code, less time

Here, “this” is the goal/need/desire.

Development deliverables for lab01

As the Agile Methodology strives to get to a working live software as quickly as possible (to be improved constantly thereupon), it is now also time to experiment with potential technology stacks, so that your team has a good basis for choosing a particular implementation platform and framework in an informed fashion!

By the due date of this assignment (i.e. Fri, Jan 19 at 11:59PM), every team member (either individually or as part of a group of team members all following the same steps on their own host computers) should have created a simple running Hello World app on a platform and with a technology stack of each person’s choice. Variety among your team members w.r.t. the tried technologies will help you gather valuable information about the pros and cons of different choices, but it is not required that you all do something different. It is also ok to do this as a group experience or in breakout groups of 2 or 3 people.

A Hello World app demonstration includes all of the following:

More on this below, and on how we’ll be assessing this for both a team and an individual grade.

Graded (lab01-I): (30) towards (lab01-I) is your individual grade for lab01. Your mentor will check with each of the team members to see if they got a Hello World app running. These reviews can be as simple as pointing the mentor to a deployed web app, or it could involve the team member demoing an app to the mentor via Zoom. Your TA or instructor will then do an independent assessment, informed by the mentors review, and assign a grade. If you are unsure about your code/project following good practice, you are encouraged to complete it early and meet with your mentor, your TA, or another mentor/TA during arranged meeting time or office hours to go over it in advance. The components of this grade are listed below. These points cover the basic functionality and code of your Hello World app on the basis of the app review. The remaining points cover mechanics of the release process (issues, version control, deployment/demos).

Graded (lab01-T): (30) (lab01-T) is your Team grade for lab01. As part of this grade, each team member should have contributed to a hello world assignment as an individual or as part of a group by the due date/time of this lab, i.e. (Fri, Jan 19 at 11:59PM)

For teams of 4, this part of your grade is 7.5 points per team member. For teams of 7, it is 4.28 points. Those points are all or nothing; if you’ve made a reasonable attempt, even if you didn’t earn 100% on lab01, your team will earn 7.5 or 4.28 points for your contribution towards the whole.

This component of your team grade is designed to encourage each team member to reach out to all the other members of the team, and be aware of the progress they are making towards the goal of having every team member complete a hello world assignment as an individual or as part of a pair. The most important learning goal of the course is to learn to work as a team, supporting one another.

What each “Hello World” branch/pull-request must contain for full credit.

Each webapp “Hello, World” branch/pull-request should be deployed

If your app is being deployed as a webapp: you should have have DEPLOYED it so that it runs on a service such as Heroku, Google App Engine, Amazon Web Services, etc. at a stable URL. The easiest platform on which to do this for Java Spring Boot, and Python Flask is Heroku. If you don’t know how to go about it, ask on the slack channel (well in advance, not at the last minute), and mentors and other students can point you to the resources to get started with this.

Put the URL of your running app in the README in your branch.

Each non-webapp “Hello, World” branch/pull-request should be demoed

If you are NOT doing a webapp, you must set up a time with your mentor, or your TA, to demo your app to them. Mobile apps should be demoed deployed on a physical device through Zoom. You need to do the demonstration BEFORE the lab next Friday. The TAs hold office hours and you can arrange meeting times with your mentors during which you can schedule this demo. The last opportunity to do this demo is right after or just before lab on the due date for this assignment, if you can grab your mentor or TA, but it may not be possible to fit all of those in, and in that case, regrettably, you may lose the opportunity to do so (and earn the points.) Please coordinate with your team to get as many of these demos done before lab on the due date of this assignment.

If working in a pair/sub-group, each member of the pair should demo the app, to show that they understand how to run it.

NOTE: If you cannot schedule with your own mentor, you may coordinate on slack between your mentor and another mentor/TA holding open lab hours that better fit your schedule. Please use the slack to coordinate this.

Some starting points for selected platforms:

Vincent Tieu has put together a Github repository with starter code for React and Google Authentication The README.md and an accompanying YouTube video also cover how to use the Google Developer Console and how to host the application on Heroku.

Christopher Chang has put together a list of technologies for inspiration. Feel free to take a look at it and use it as a starting point for deciding what technologies you may want to use.

If you are using Heroku for hosting a web app, you may also find these instructions from CS48 some time ago helpful.