CHIPS (Programming assignments)
To complement the Content-Oriented Didactic (COD) materials such as the book and lectures, CHIPS (Coding & Hands-on Integrated Projects) provide hands-on skills practice and are keyed to specific sections in the book. This section describes how to use them with Codio. The book's website has other options if you don't wish to use Codio, but we have pretty extensive automated workflows that are optimized for Codio, for publishing both the book content itself and these CHIPS along with their autograders.
If you're using Codio, all you really need to know is how the CHIPS workβsee below. If you want to use the CHIPS outside of Codio, or contribute to their development, look at the README in the CHIPS repo (visible to registered instructors).
Here's a quick summary of the assignments, presented in the order in which they appear in the ESaaS textbook. Following the summary are details on how to edit and dry-run each assignment, and any noteworthy caveats. There are three types, as indicated in the table below:
(A)utograded using Codio: The single repo
saasbook/chips
includes everything needed to generate (a) student-facing starter code repo, (b) Codio autograder (including files that are hidden from students when they use Codio), (c) Codio "Guides" panels to walk the student through the assignments, (d) reference solution. That repo's README includes generic instructions for how to edit, test, and deploy Codio-autograder-based CHIPS. Some CHIPS also include files for manually configuring Gradescope-based autograding, but Gradescope is no longer officially supported, so use those files at your own risk.(P)rairieLearn autograding: The questions are done in the PrairieLearn assessment authoring system and have autograders there.
(S)elf-graded: CHIPS involves coding, but rather than an autograder, students run tests themselves that are included in the student-facing code repos. It's up to you if you want to verify that they've done so (e.g. by having them submit a screenshot, etc.)
(C)omprehension-based with some autograding: CHIPS involves minimal or no coding, but rather performing some tasks and answering self-check questions about them. The tasks can be performed in the Codio IDE's terminal window, and in some cases the questions are built into the Codio version of the assignment as unlimited-attempt selected-response/short-answer questions.
The relative effort of each CHIPS is indicated by one bullet (1-2 hours of effort), two bullets (2-3 hours), or three bullets (a potentially multi-day assignment). Here are the book sections in which the CHIPS occur, along with their effort ratings.
2.5
β’β’
3.3
C
β’
3.7
β’β’β’
4.3
S
β’
4.5
S
β’
4.7
C
β’β’
4.9
S
β’β’β’
5.3
β’β’β’
5.7
Associations and SSO/WebAuthn login (TBD: not finished yet)
6.9
AJAX Enhancements to RottenPotatoes (TBD: not finished yet)
7.7
β’β’β’
7.9
β’β’
BDD for New Feature: write scenarios and then backfill the code to make them pass, using BDD to drive the code for a new RottenPotatoes feature "Find movies with same director." Another goal is to achieve a threshold level of C1 coverage using SimpleCov.
8.5*
P
β’β’
10.5
A
!
Agile Iterations Two (or more) full iterations of Agile adding features to an existing (legacy) app. See the separate section on CHIPS 10.5.
12.8
β’β’
Optional additional CHIPS (not referenced in textbook)
Oracle of Bacon: Build a simple command-line app that uses external services in a SOA, including parsing XML responses.
Design Review: We use this in the project portion of the course. This is not a programming assignment but rather a 3-part scaffolded process for doing design reviews and technical presentations. (Each part can be used more or less independently.) It is intended to be used in conjunction with student teams doing their own open-ended projects, so no code is provided. In part 1 (Design Review), teams are paired up and each team evaluates the other's design and gives feedback on possible improvements. In part 2 (Presentation), teams give technical presentations about the design review; these are peer-evaluated (or instructor-evaluated) according to a provided rubric. In part 3 (Handoff), teams modify their repos as needed to ensure the project is easy for another team to pick up and continue working on.
Last updated