Last updated on Friday, December 13, 2024

Week 10 Debrief: tips for the unguided lab

Congrats on completing your 10th week of CS-214! Here is a round-up of interesting questions, tips for exercises and labs, and general notes about the course.

Administrivia

We adjusted the exam’s grading policy for question 15.
We have answered all complaints related to the midterm; if your score hasn’t been updated but should have been, please let us know by creating a private post on Ed.
We have posted an additional example app, hotpotato, which makes use of the ClockDrivenStateMachine class.

Interesting Ed questions

Webapps
Scala
- A subtle interaction between ensuring and return, and a follow-up question.

Unguided lab updates

Congrats on completing the webapp-rps lab! This was the last regular lab of the semester. From now until the end of the year, we’ll be working on the unguided lab.
As a reminder, the following resources are available:
- Detailed policies, which highlight what you’ll be graded on.
- A writeup for the unguided lab.
- A transcript of the memory webapp lecture.
- Multiple example apps.
From now on, you’re on your own! You have all the tools you need to complete your webapp. Future lectures will explore advanced topics that are you may need on the final, but are not strictly necessary to complete your webapp.

Our advice for this week

Now that you know what you’re going to build, it’s time to start working on the implementation. This week, we recommend that:

You set up the repository;
You brainstorm the architecture and identify the smallest possible prototype that captures your idea;
You complete a minimal prototype.

Read on for why starting small matters.

Software engineering tips

Plan ahead, identify intermediate milestones, and start small!

The best way to be successful in the webapp lab is to apply two techniques:

Plan ahead: mistakes that force you to redo everything from scratch are very time consuming. Take the time, as a team, to talk through the implementation, which features you’re going to start with, what will be difficult, and what might take time.
Release early and often: planning in advance is good, but it’s very hard to plan a complete app and implement all of it in one go. Instead, you should start with a minimal working prototype: just the essence of your app, oversimplified, so that it takes just a few hours to get it to work. Once you have that, you can confidently add features one by one on a working base. This makes debugging very easy: any time you find a problem, it will be in the small component that you just added.

Avoid implementing all features together at all costs. Have a working, extremely simple prototype working as early as possible, and refine from there. Feel free to ask us (in person!) if you’re unsure how to choose a minimal working prototype.

Consider writing tests first

Your tests will be a mix of:

Integration tests (e.g. decode(encode(…)) = …, or tests that combine transitions with projections), which combine multiple parts of the code, and exercise only public APIs (wires, projections, transitions, events, views).
Unit tests, which focus on a single part of the code, and may exercise private APIs.

You can define integration tests even before you write the code: they won’t pass (of course) until you write the code, but they can help you define what your code should do.

For example, consider a tic-tac-toe app. Even if I don’t know what the state representation is, if I have a view that is either Finished(winner: UserId) or InProgress(…), I know that the sequence of events where user "a" plays at positions (0, 0), then (0, 1), then (0, 2) should lead to a state that once projected yields Finished(winner = "a"). Note that I don’t need to know anything about the State type to write such a test.

Consider pair-programming!

Early on in the project, it may be very useful to write some code in pairs — a practice called pair programming. If you do so, have one person code while the other looks over, comments, and suggests implementation choices or improvements, and switch roles regularly (every time a non-trivial function is complete, for example).

Remember: you may deviate from your proposal!

You will not be judged on whether your final product matches your proposal. You may be asked to explain why you deviated, but if you build something reasonable, we will not penalize you for adjusting your proposal.