Week 08c - Thu 11/19 -

What is is that is due today?

  • Today is the last day that you can submit new PRs to be reviewed by staff.
  • By today, PRs need to be already in a mergeable state
    • Passing all CI/CD checks
    • Meeting all of the criteria in the PR checklist
    • Already reviewed/approved by a team member

After today’s class ends, any PRs that are not mergeable are subject to being closed without further review by the staff.

Over the weekend, and as we approach Tuesday of week 9, we will continue to review PRs that are already in the queue, with the goal of having all of the PR queues empty by the end of class on Tuesday, so that you can start on the release notes and final videos.

What to work on after last PR is merged

  • Release Notes
  • Videos
  • Fixes to get the final “summary” PR green on CI.

You can read more about those below.

But first

  • If your team still has open PRs, get them mergable!
  • If your team is done with PRs: Your “prod” site is linked in the table here in the Dokku Prod column.
  • Make sure that all of the features work!
  • Look for bugs. If you find bugs, create issues for them, and make new PRs to fix them. Bug fix PRs may be submitted at any time, and might be reviewed and merged by the staff.
  • This is not a loophole to add new features. These are only bug fixes, and they do not earn additional points for the team. They just help you present a better user experience in your video and release notes.
  • Please create the qa dokku instance if your team hasn’t done that yet; those are linked in the Dokku qa column below.
  • We will be using both the dokku prod and the dokku qa instances during the final product reviews.
Team
Links to Slack		 Project
Links to Legacy Repo		 Team Repo PRs Github Pages Kanban Dokku Prod Dokku qa
f26-01 courses team repo PRs github pages kanban dokku prod dokku qa
f26-02 courses team repo PRs github pages kanban dokku prod dokku qa
f26-03 courses team repo PRs github pages kanban dokku prod dokku qa
f26-04 courses team repo PRs github pages kanban dokku prod dokku qa
f26-05 dining team repo PRs github pages kanban dokku prod dokku qa
f26-06 dining team repo PRs github pages kanban dokku prod dokku qa
f26-07 dining team repo PRs github pages kanban dokku prod dokku qa
f26-08 dining team repo PRs github pages kanban dokku prod dokku qa
f26-09 frontiers team repo PRs github pages kanban dokku prod dokku qa
f26-10 frontiers team repo PRs github pages kanban dokku prod dokku qa
f26-11 frontiers team repo PRs github pages kanban dokku prod dokku qa
f26-12 frontiers team repo PRs github pages kanban dokku prod dokku qa
f26-13 happycows team repo PRs github pages kanban dokku prod dokku qa
f26-14 happycows team repo PRs github pages kanban dokku prod dokku qa
f26-15 happycows team repo PRs github pages kanban dokku prod dokku qa
f26-16 happycows team repo PRs github pages kanban dokku prod dokku qa

Clarifications about the PR end game

  • 11:59 Thursday of week 8 was the last day that you can submit new PRs to be reviewed by staff.
  • By today, PRs need to be already in a mergeable state
    • Passing all CI/CD checks
    • Meeting all of the criteria in the PR checklist
    • Already reviewed/approved by a team member

Any PRs that are were not in a reviewable/mergable state by the end of office hours last Thursday (7:15pm) were subject to being closed without further review by the staff.

We will continue to work with merge candidates already in the queue to get the merged.

NOTE that even previously approved merge candidates sometimes end up with merge conflicts or failing tests after earlier PRs are merged.

If you want those merged *you are responsible for monitoring the Slack messages of your team and staying in touch.

If we try for 72 hours to contact you or someone from your team and no one replies, we will consider the PR abandoned, and simply close it without further the review. Note that this is a 72 hour period so that you can take off a day (e.g. for Thanksgiving) without worry, but you do need to check in at least every third day, regardless of holidays and weekends.

We will continue to review PRs that are already in the queue, with the goal of having all of the PR queues empty as soon as possible; preferably before Thanksgiving, but at the latest, before Tuesday’s class during week 10.

team04 and final summary PR

As part of your team04 grade, you’l be responsible for:

  • Making sure that your prod deployment is configured properly and up to date
  • Making sure that your qa deployment is configured properly and up to date
  • Making sure that the final summary PR for your team is green on CI.

The final summary PR is one that will take all of the changes you’ve made and request that those be merged into one of the four legacy repos:

You’ll be notified by the staff when the PR from your team is ready.

You’ll need to look and see whether the PR is green on CI. If it isn’t, then you’ll be responsible for addressing what’s wrong:

  • Failing tests
  • Merge conflicts
  • etc.

If your main branch is not green, that’s a bad sign, so work on that first.

Final Class Meeting

Notes about the final class meeting (During Assigned Final Exam Slot)

Final Class Meeting

The final class meeting will take place during the scheduled final exam slot for the course, which is:

  • TODO: Insert date/time of final exam here

Synchronous participation is required, however partcipation over zoom is fine.

During the final course meeting, we typically complete an in-class assignment involving reviewing the videos, release notes, and implementations of the other teams in the course.

The reason we do this synchonrously is so that members of the various teams are available to consult with about the choices they made in their implementations, as well as available to fix any problems that may arise with the dokku deployments, etc.

So please be available on your slack channel, and either in person, or on zoom that day.

Release Notes

Release notes

Release Notes

You are required to prepare a set of release notes as a team.

Please prepare these as a Google Drive document in the same folder where you do your retros.

Please call the file f26-xx-release-notes.

Please include the name of your team and a link to your repo at the top of the page, along with the names of the members of your team.

What goes in the release notes

The release notes should summarize:

  • For the actual users of the application, a summary of what changes they notice from the way the app was at the start of the course to now.
  • In a separate, shorter section: for the developers of the application, a summary of any additional changes devs may need to be aware of.
  • It does not have to be every single last detail of every change; it should focus on the big picture of things users/developers would need or want to know.
  • Before and after screenshots can be helpful.

Samples

You can find samples of release notes at these links:

We do not have any samples for Frontiers since this is the first quarter that CS156 teams have worked on proj-frontiers.

How to submit

Work colletively on this as a team. When finished, submit a link to either your Google Drive doc on Canvas under the assignment ReleaseNotes

For the due date, refer to the Release Notes assignment on Canvas.

Final Presentation

Notes about the final presentation

Notes about the final presentation

The final presentation should be a team effort, and should highlight all of the PRs that got merged into the main branch.

Make a video of between 5-8 minutes (see guidelines below) and submit the link on Gauchospace.

Limit your presentation to 5-8 minutes. 8 minutes is a hard upper limit.

Highlight the work from an end user perspective first.

That is:

  • The best thing is to show how an end user would use the feature
  • The next best thing is to show either a front or backend component in isolation, for example:
    • If there is a front end component that is not active in the app yet, you can show it in Storybook
    • If there is a backend API, but the functionality isn’t available in the user interface yet, you can demo it in Swagger.
  • Show internals of code only after explaining the user facing functions, and even then, only if you have left over time.

Instructions for your video:

Here’s a tutorial video on making demo videos from CS48 S20 (Video inception)

Based on the experience of CS48 students, pre-recording is strongly recommended. You will know for sure in advance whether the demo is successful, and whether or not you’ve hit the target length of 5-8 minutes.

Your video should be 5 to 8 minutes long, and cover these points:

  • First, mention the names of the members of the team, and introduce the person narrating the video.
    • It is ok if all the team members appear in the video. It is also ok if only one person narrates the video on behalf of the team.
  • Second, go through each of the features that your team worked on that were merged into main
    • Only demo the features that were merged into main
    • Focus in this part of the video on demoing the features from a user perspective, not on the technical details of how they were implemented.
  • Next, if there is time remaining to reach the 5-10 minute mark, you may briefly cover any technical and/or non-technical challenges your team faced
    • You don’t have to cover everything.
    • You don’t really even have to include this part if your demo already hits the 5-10 minute range.
    • If you do include this part, focus on the items that you think would be interesting to the audience (fellow students in CS156, the staff of CS156, and potential users of the software you worked on).
    • Possible items to include
      • Particularly interesting technical details of what you had to write in the code
      • Challenges in testing
      • Challenges in team communication and organization, and what you did to overcome those
  • Optional: at the end, if you like, you may thank anyone that was particularly helpful to the team from the staff (TAs and LAs, or students from other teams).
    • Please don’t include thanks to me (Prof. Conrad) in the video; I don’t want this to be an exercise in brown-nosing.
    • If you do want to express gratitude, feel free to share your thoughts with me on the Slack, by email, etc.

Please then also poll your team members and come to a consensus about the privacy of your final video. Include this in your submission on Canvas.

  • (a) We give permission only for course staff, and the students in CS156 this quarter to see this video
  • (b) We give permission for this video to be shared with current and future CS156 students only.
  • (c) Anyone may see this video (a link to it may be posted on the public course website)

Example Videos

Example Videos (these teams gave me permission to share them publicly)

Note that Spring 2025 is the first quarter for Frontiers, so no example videos for frontiers are available.

Fall 2024

Spring 2024

Fall 2023

Summer 2023

Fall 2022

Spring 2022

Winter 2022

Final Exam

Notes about the final exam

Notes about the final exam

The final exam will be an online take home exam, and will be mainly high level questions about the process of software development that you learned in team01, team02, team03 and the legacy code project.

There may be questions about any of the following. If you’ve been paying attention all along, you shouldn’t really need to “cram”. The answers should be pretty much in your knowledge base already.

  • Agile processes, e.g. standups, retrospectives, the role of a product owner/manager
  • GitHub tools and their interaction with Agile processes: using feature branches, issues, Kanban board, Pull requests, code review
  • General Web Development concepts, e.g.: Backend vs. Frontend
  • Some Spring Boot specifics: controllers, services, use of Swagger
  • Some React specifics: components, use of Storybook
  • Testing in general: unit testing, test coverage, mutation testing
  • Spring Boot Testing: Role of JUnit, Jacoco, Pitest, Mocking and Stubbing
  • React Testing: role of jest, and Stryker
  • Using third party APIs and representing data with JSON (as we did in team01, and later phases as well.)

I’ll be asking questions about these topics that I think are the type you might be asked as a job interview. So if you study, study the way you would for a job interview.

Please do not collaborate on your exam answers.

  • Identical text is unlikely to occur if each of you is working indepenently and writing in your own words.

  • If you are copying/pasting text from an online source (e.g. to explain what a retrospective is) be sure that you use “quotation marks” around direct quotations, and cite your source.

    Otherwise, you are liable to end up triggering the suspicion of academic dishonesty because of the similarity of your text to someone else that happens to be using the same source.

    Also: relying too much on direct quotes rather than putting things in your own words may result in lower grades; if you have to quote others too much, it suggests that you have not really internalized the content, but have to rely on others understanding. So use direct quotes sparingly, if at all; try instead to answer in your own words.

Academic integrity investigations are unpleasant for everyone, and they don’t help anyone learn.

I really dont want to spend my time on those, so please don’t create conditions where I have to do that.

Work independently, and let your learning speak for itself.

Clarity and consiseness counts

  • Small grammar / spelling errors may or may not be penalized; if an interviewer would be confused by the answer, or have some doubt as to your understanding, then they count. If there is no doubt about your understanding, I’m liable to be more lenient.
  • Make sure your answers are clear and understandable.
  • Do not just do an information dump of everything you know about the topic, or everything you can possibly find online about the topic. An employer wants someone to answer
  • their question, and they also want someone that makes good use of their time. Don’t waste the interviewer’s time.