Last updated on Saturday, January 03, 2026

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

Some of you required a deadline extension for the unguided lab proposal. We extended the deadline from today to Sunday. Remember that you submit by pushing your README to main. If you don’t manage to push, make sure that you are using the right repo: ul2025appN.
We have made it possible to push directly to the main branch of your repos (initially, main was “protected”, meaning that could not push directly to it). Don’t let the ability to push directly to main discourage you from creating pull requests!

Interesting Ed questions

Pathfinder
- Pathfinder: Can we have many shortest paths to a goal?
Webapp
Lectures and exercises

Unguided lab updates

The webapp-rps lab is the last regular lab of the semester. From now until the end of the year, we’ll be working on the unguided lab! The following resources are available:

Detailed policies, which highlight what you’ll be graded on and what constitutes an acceptable topic.
A handout for the unguided lab. It shows step by step how to build your app.
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.

Battleship is a bad idea

At least fifteen of the groups we talked to in the proposal review session suggested battleship. Building this won’t lead to a good app.

There are many issues with battleship:

The initial set up (picking the ship locations) is annoying to implement: you will have many events for trivial actions, like rotating or moving a ship, selecting the next one, etc.
There is not meaningful interactions. The interactive part in the real world is saying “hit” or “miss”, but in a webapp… the server can compute that response automatically! In essence, the players don’t really play together, they play the same game in parallel.
The state transitions are trivial: they are similar to RPS, are much simpler than memory, both of which are small.

Double-check the policies if you have doubts.

Since many people asked: yes, Uno and connect-4 could work, but:

Don’t steal copyrighted assets: don’t reuse visuals or rule text directly from Uno.
Don’t steal code: make sure that you’re able to explain how your implementation differs from other implementations available online.
Scope your work: a plain connect-4 implementation is in the order of complexity of RPS, so unsuitable for a group of three or four over multiple weeks.

Our advice for next week

Once that you know what you’re going to build, it will be time to start working on the implementation. Next 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.