Final Pull Requests for legacy code projects are due by 5pm today.

Each of those should be:

  • green on CI
  • code reviewed by a team member by 5pm today.

Any PRs not in that state by 5pm today might not be reviewed and merged by staff in time to count towards your project grade.

After 5pm today, typically the only work accepted for credit will be work necessary to get those remaining PRs merged (e.g. responding to peer and/or staff code reviews.)

  • Exceptions to this are usually initiated by the staff, i.e. a team is invited to submit something to either fix a problem, or address some unusual circumstance that may have created an inequity in the process.
  • Exceptions initiated by students are rarely approved; the default answer is to deny them, however they will be considered on a case-by-case basis.
  • A key consideration in all cases is whether the student and/or team involved shows a track record of serious committment to finishing on time, and ran into circumstances beyond their control they could not reasonably have anticipated.

If your team is already at 100 points

You can start on any of the following, which are your last three responsibilities as a team

  • your team’s Final Retro
  • your team’s Final Video Presentation
  • your team’s Release Notes

You can also read more about the:

  • written asynchronous take home final exam on Gradescope
  • final class meeting (which takes place during the scheduled final exam slot)

Note that synchronous participation in the final class meeting is required, but remote participation over zoom is totally fine.

Final Retro

If your team is already at or above 100 points, and is not currently involved in helping to get things merged, you could start your final retro today. See below for details.

Notes about the final retro

Final Retro

The instructions for the final retro are in the usual place on the Google Drive (gdrive link on your slack channel).

Please look there for the retro4 worksheet.

This retro is a little different from the rest, in the sense that it is a sort of “exit interview” for the team.

There is no further work ahead of the team, so instead of focusing on how the team can improve, it is focused more on what learnings from your time together you’ll take with you to future work on team software development projects.

Other than that, it’s like any other retro.

Submit on Canvas here:

Notes about the final retro

You have a choice when to schedule the Final Retro.

Your choices are:

  • During class on 05/30 (Week 9 Thursday)
  • During class on 06/04 (Week 10 Tuesday)
  • During class on 06/05 (Week 10 Wednesday)
  • During class on 06/06 (Week 10 Thursday)
  • Or outside of class on zoom any time between 2024-05-30 18:15:00 +0000 and 2024-06-06 17:00:00 +0000

If you choose the “outside of class option”, then the same conditions apply as for the previous out of class retro:

  • The team must make a unanimously choice, with no objection, documented in the team slack channel, with everyone participating in the decision, to hold the retro outside of class time over zoom.
  • You must post the date/time on the slack team channel, and everyone must agree to it.
  • Everyone must participates for the full length of the retro, which lasts at least 50 minutes
  • You must make a video recording of the retro and upload it to your team Google Drive folder (in addition to the normal document)
  • The out of class retro must take place between and be submitted on Canvas between 2024-05-30 18:15:00 +0000 and

Final Class Meeting

Notes about the final class meeting (Wednesday, June 12, 2024 7:30 PM - 10:30 PM)

Final Class Meeting

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

  • Wednesday, June 12, 2024 7:30 PM - 10:30 PM

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

Brief Discussion of “Release Notes”

At the end of the legacy code phase, each team will be required to submit “release notes” for all of the features they added to the main branch (i.e. the difference between their main branch, and the main branch of the starter code for the project.)

These serve at least two purposes:

  • Functional: These messages help them to be aware of, and use the new functionality. Customers can’t take advantage of new features if they don’t know about them.

  • Marketing: If you are running a software business, you are always concerned about “churn”, which is the business term for when a paying customer stops paying you, and starts giving money to your competitor instead. These messages need to convey to your customers that you have heard their concerns, and care about making their lives easier, more fun, less stressful—whatever the purpose of the app happens to be. As we move into the legacy code phase of the course over the next few days, your PR descriptions will be the source material for these release notes for either HappyCows or Gauchoride, so it’s important that they be written well. This is why we ask for screenshots, etc. and that the PR descriptions include a description of new features not just from the programmer/developer perspective, but from the end-user perspective.

Sample Release Notes

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

You may prepare these in one of two ways:

  • As a Google Drive document in your Drive folder called Release Notes (in the same folder where your retros go), OR
  • In Markdown format in a file /docs/release_notes/team-name.md (where team-name is, for example, s24-5pm-1) in a new branch of your repo called release_notes. If you choose this route, make a Pull Request for this change (the normal PR deadline doesn’t apply to this PR).

The choice is up to you: each method has its pros and cons; do whatever seems easiest to you.

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.

How to submit

Work colletively on this as a team. When finished, submit a link to either your Google Drive doc, or to your PR 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 M23, and the staff of CS156 M23, 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 publically)

These videos are available to CS156 students/staff only (restricted via Canvas login)

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.