Deliverable 1: Drop in a feature

Due Friday 25 September, 18:00 · individual · submit on GitHub and PrairieLearn

This is a deliberately open deliverable. In particular, there is no prescribed procedure for how you should approach making the changes. The goal is to experience first hand what it costs to change an existing system, and to build some intuition about why change can be hard.

Before you start

Be sure to read the Project Overview first! Instructions for getting your environment configured are provided in the first part of Lab 1, and you should complete it before changing any code. As a reminder, you must be connected to the UBC VPN to successfully run the tests since they invoke code that calls a geocoder web service hosted at UBC.

Request 1: Adding campus

Buildings currently have an id, a name, an address, and coordinates. Your job is to add one more: an optional campus field. This requires you to modify three parts of the existing codebase:

1. Update how the POST /api/v2/datasets endpoint handles parsing of uploaded facilities datasets so that it extracts the campus name when processing each building's .htm file. The value should come from the page's header, if present (in the the campus.zip dataset the value is always "vancouver campus").
2. Support modifying each building's campus field via the PUT /api/v2/buildings/:buildingId endpoint.
3. Allow users to search by campus via the POST /api/v2/search endpoint.

Finally, you must add tests that specifically test each of the three features.

Implementing these requirements completely means that campus appears and can be used just like any other existing building field, except that it is optional instead of required. Additionally, you must update openapi.yml documentation to the Building schema and all the above endpoints, and ensure that all existing tests still pass.

Read the questions in the reflection section before you touch the code. Question 3 in particular asks about the process you used to identify the locations in your code that you had to change.

Request 2: Implementing aggregation

The previous team almooooooost finished the aggregation implementation of the POST /api/v2/search querying endpoint. They finished the validation and tests for validation, but ran out of time before they could finish the actual aggregation code implementation and its tests. Your task here is to implement aggregation so it satisfies the spec as described in the openapi.yml specification for POST /api/v2/search. You will want to test that your implementation works as specified. Hint: there is one specific method you will need to implement!

Design Analysis

Answer the following questions on PrairieLearn in DELIV1 Design Analsyis before the deadline:

1. How did you represent "no campus"? When a building has no campus set, does your response omit the key, send it as null, or something else? What is the behaviour of a PUT request when it modifies a building with a campus but the request omits campus? Say what you chose and why, and how it affected the other features of Request 1.

2. A trace of one request. Follow PUT /api/v2/buildings/:buildingId from the route registration to the point where data is written to disk, naming each part it passes through. A numbered list is fine.

3. For your changes to the PUT /api/v2/buildings/:buildingId, identify each class and function you touched, and how you found each one. Searching for keywords? Following a call chain? Running it and reading the error? Guessing? (or even, gasps, AI?). You can also include the places you changed something and then had to change it back.

4. Write a short reflection on the changes you had to make to the PUT /api/v2/buildings/:buildingId endpoint. Describe what aspects of the existing code made these changes harder than they should have been. Say what had to agree with what, what surprised you, and why that made each feature more work than the initial change would have suggested. Compare those changes with the ones you had to make for request 2. Were they easier or harder to implement? Why or why not?

Grading

This deliverable has both autograded and manully graded components, each worth 50% of your grade.

• The code you submit for Request 1 and 2 will be autograded. Every commit you push to the main branch of your repo is automatically graded, and you highest scoring commit before the deadline is used as your final grade.
• Your analysis will be manually grdaed by the TAs on PrairieLearn after the deadline.