COMPSCI 326 Syllabus, Spring 2027

Spring 2027. This is the current syllabus, carried forward from Fall 2026. Staff, office hours, rooms, and the dated calendar for Spring 2027 are posted on Canvas when the term opens; where Canvas and this page differ, Canvas is the one to follow.

Number: COMPSCI 326
Title: Web Programming
Instructor: Tim Richards
Semester: Spring 2027
Mode: In-person
Scheduled Meetings: Lecture twice a week, plus one Friday lab section (enroll in one). Days, times, and rooms are on SPIRE.
Exams: There are no exams in this course
Groups: There is group work in this course
Credits: 4
Prerequisites: COMPSCI 220 with a grade of C or better, or INFO 248 and CICS 210 (or COMPSCI 187) with a grade of C or better. If you are from another academic institution or have unique circumstances, you must submit an override request to be considered for enrollment.

Description

The web is arguably today’s most important application platform. Web browsers run on practically every device, and even many phone applications are in fact web applications under the covers. This course covers a broad range of client-side web technologies, including HTTP itself, HTML5, CSS, and JavaScript; it additionally covers key concepts for the server side of web applications, including persistent storage and databases. This course is hands-on and heavily project-based; students will construct a substantial dynamic web application based on the concepts, technologies, and techniques presented in the knowledge units. This course satisfies the IE Requirement and an Elective for both the CS and INFORM Majors.

This course is concept-first and experiential. You will build a real running server early in the course and a complete full-stack application by the last. Each knowledge unit earns the next one, and the team project runs alongside the entire course, so the skills you practice each week go directly into something you are building.

Staff

Instructor: Tim Richards
Teaching assistants and undergraduate course assistants: listed on Canvas when the term opens.
Office hours: the full schedule, with rooms and Zoom links, is posted on Canvas in the first week. Your Friday lab is also staffed by a TA and a UCA, so it is a good place to bring something you are stuck on.

All course communication goes through the Canvas Inbox, not email. See the Communication section below for who to address a message to and what to include.

Learning Objectives

By the end of this course, students will be able to:

Configure and use a reproducible, containerized development environment for consistent, team-based software development.
Design and implement a server-side web application using a layered architecture that separates routing, request handling, and business logic.
Write modern JavaScript using modules, asynchronous control flow, and functional programming idioms.
Design semantic, accessible HTML and responsive CSS layouts.
Apply distributed version control and collaborative code review practices to manage a shared codebase.
Design and implement web APIs, and explain the request/response model underlying client-server communication.
Persist application data using both file-based storage and a database, and reason about the tradeoffs between persistence strategies.
Implement asynchronous client-server interactions that update a page without a full reload.
Write automated tests that verify business logic independent of the user interface.
Build accessible, responsive user interfaces using a modern, component-driven styling approach.
Implement authentication and role-based authorization to control access to application resources.
Plan, build, and present a complete full-stack web application as part of a team.

Time Commitment

Plan for roughly thirteen to fourteen hours a week, most of it self-paced around the scheduled meetings.

UMass Amherst defines course workload by a standard credit hour rule. For a four-credit course, the University expects at least 180 hours of total work across the term. Spread across the semester’s instructional weeks, that comes to roughly thirteen to fourteen hours a week. The course covers 18 knowledge units, 10 labs, and a full team project arc.

About two and a half of those hours each week are scheduled: the two weekly lectures (1 hour 15 minutes each) and the Friday lab section (50 minutes). The rest, roughly eleven to twelve hours, is self-paced knowledge-unit work, homework, and project time, distributed across the week around the scheduled meetings.

Because each unit builds directly on the one before, and because this is a systems course where one missing dependency or one broken route can block everything downstream, steady weekly engagement matters more than raw hours in any one sitting. If your situation makes steady weekly engagement difficult, send me a Canvas Inbox message early in the term so we can be honest about whether the timing works for you.

Course Structure Synopsis

Course Delivery

This course is in-person, blending scheduled meetings with the same hands-on, self-paced knowledge-unit work the course has always run on. Lecture is not where the material is delivered to you for the first time. You read the knowledge unit before the lecture on it, and we spend the time together clearing up what did not land and building something with it. The next section describes exactly how a meeting runs. The Friday lab section is dedicated time for that week’s Git lab, run in person. All course materials, including the full text of every knowledge unit, remain available on Canvas at any time; homework, quizzes, and project work are still completed on your own schedule within the posted deadlines. This course is designed to be experiential, meaning that you will learn by doing, and the course structure is built around active participation and hands-on activities, now including in-person ones.

What a Class Meeting Looks Like

Every lecture follows the same four-part shape, so you always know what is coming. The whole thing rests on one assumption: you have read the knowledge unit before you walk in. Seventy-five minutes is not enough time to both deliver a unit and do anything with it, so we use the time for the part that is genuinely hard to do alone.

Reading check, and what it showed, about 30 minutes. A handful of short questions on the unit, due at 8:00 AM on the morning of that unit’s lecture, so I can read your answers before class. It is graded on completion, not correctness, so an honest wrong answer is worth exactly as much as a right one. Every check ends by asking what did not make sense, and what you write there is what I open the class with. Guessing what I want to hear makes the class worse for you specifically.
In-class activity, about 30 minutes, in pairs. A small build with a real design decision in the middle of it, one where reasonable people disagree. You work in pairs, one driving and one navigating. See below for what is and is not expected here.
Discussion, about 10 minutes. We compare what different pairs decided and tie it back to the sprint your team is building.
Exit ticket, about 5 minutes. A few short questions submitted in Canvas before you leave. See below.

The in-class activity is not graded and nothing is submitted for it. The brief for each one is posted in Canvas under its unit, and it opens when that lecture starts. There is no submission box, no points, and no due date. It is there so you and your partner have the brief and the starter code in front of you while you work, and so you can go back to it afterwards. It is meant to be done during class, with a partner, not finished at home alone; the disagreement with your partner is the part that teaches you something, and you cannot have that by yourself later.

What you did in the activity is reported in the exit ticket. The exit ticket is a short set of questions that opens for the last fifteen minutes of class and closes five minutes after class ends, and it is where the activity actually gets recorded. It is deliberately not open before that, so that nobody spends the activity filling in the form instead of doing the work it asks about. It asks who your partner was, the word shown on the screen during class, a question about that day’s activity, and whether anything is still confusing, a question you did not get the chance to ask, or anything else you want me to know. Every answer to that last one is read before the next class. Everyone submits their own; it is not one per pair. It counts toward the Exit Tickets category, it is graded on completion rather than correctness, and because it can only be answered from inside the room it is also how attendance is taken.

Exit tickets cannot be made up, including if you forgot to press submit, unless you have a documented excused absence. If something comes up, message me through the Canvas Inbox rather than letting it pass.

Knowledge Units (KUs)

The primary way in which learning takes place is through knowledge units (KUs). Each KU is a self-contained module that includes preparatory reading, hands-on activities, and exercises. You are expected to complete each KU in order, as they build upon one another. The course is deliberately concept-first: most units ask you to build or observe something before the underlying pattern is named, so that the name lands on an experience you already have rather than on an abstraction. Each KU will have a set of activities that you must complete, including coding exercises.

Canvas

Canvas is where you will find links to all of the course material. The syllabus and schedule can be found on Canvas. All assignments will be posted on Canvas. Grades will be posted to Canvas. Announcements will be posted on Canvas. If in doubt, go to Canvas to find what you are looking for and follow links from there.

Gradescope

Homework assignments are submitted through Gradescope and graded automatically. When you submit, an autograder runs your code against a test suite and reports a score immediately; you do not have to wait for manual review to see how you did. If a test fails, the output includes enough information to diagnose and fix the issue before the deadline. You may resubmit as many times as you like before the deadline, and only your final submission is graded. Gradescope is accessible through Canvas.

Communication

All course communication happens through the Canvas Inbox. Do not send email directly to the instructor or to the course staff. Administrative questions go to the instructor alone. Questions about the course material go to the entire course staff, so that whoever is free first can answer. Answers worth the whole class seeing are posted to a Frequently Asked Questions page on Canvas and kept up to date. See the full Communication section below for how to address a message and what to put in it.

Spire

Final grades will be posted to Canvas before they are submitted to Spire. You are expected to check your grades in both places to ensure that everything adds up. You are responsible for ensuring that your grades are accurate and that you have received credit for all assignments that you submitted by the posted deadline. If you notice any discrepancies, send the instructor a Canvas Inbox message immediately.

Development Environment

This course uses development containers (devcontainers) to provide a consistent development environment for all students. Devcontainers are a way to package and distribute development environments using Docker containers. This allows you to have a consistent environment across different machines and operating systems, and ensures that you have all the necessary tools and dependencies installed.

You are not required to know much about Docker or devcontainers to begin, but you will need to have Docker installed on your machine, and over the course of the term you will come to understand containers as the production deployment model for modern web applications. You are required to use the devcontainer for all course-related work, including coding exercises, assignments, and the project.

The core software you will need to install is VS Code, Docker Desktop, and the VS Code Remote Containers extension. The devcontainer is configured to include all the necessary tools and dependencies for the course, including Node.js, npm, and any other libraries or frameworks that are required. You should not install this software right now, as you will be instructed on how to do so as part of the course setup unit.

Assignments

We use several different methods to scaffold your learning and assess your understanding of the material covered in this course. We outline the various methods and the kind of assessment below so you can better understand and plan your learning path. We categorize assignments as either being formative (F), summative (S), or a combination (FS). A purely formative assignment is designed to build your understanding, low stakes, and doesn’t have any or very little impact on your grade. A summative assignment is designed to measure your understanding of the material. A combination of formative/summative contains aspects of low stakes assessment with measurement.

		Assessment Type	Count	Weight
Exercises	Short activities built into each KU	F	many	0%
Participation	Small participatory tasks			4%
Exit Tickets	In-class work, one per lecture, lowest three dropped	F	26	8%
Lab Exit Tickets	In lab, one per lab section meeting, lowest three dropped	F	10	3%
Reading Checks	Before each lecture, lowest two dropped	F	18	5%
Quizzes				9%
	Quiz	F	6
Homework				22%
	Homework	FS	4
Labs				7%
	Lab	F	10
Sprints				23%
	Sprint 0: Team Formation	F	1
	Sprint 1: First Running Server	FS	1
	Sprint 2: First Feature, First Vertical Slice	FS	1
	Sprint 3: Database, Tests, and a Real Frontend	FS	1
	Sprint 4: Security, Authorization, and Pre-Demo Audit	FS	1
Project				19%
	GitHub Repository URL	S	1
	Recorded Video Demonstration	S	1
	Project Poster	S	1
	Reflection	S	1

Participation

Small, low-stakes tasks spread across the term that keep you engaged with the course and your peers.

Participation tasks appear throughout the weekly modules and take a variety of forms: discussion posts, short reflection forms, surveys, and other brief activities. They are not timed and not difficult; the expectation is simply that you show up and engage. Each task is graded on completion. Together, participation tasks make up four percent of your final grade. What counts as a participation task will be clearly labeled in each module on Canvas. Exit tickets are counted separately, in their own category. See below.

Exit tickets: eight percent. The exit ticket you submit at the end of each lecture is its own category, worth eight percent of your final grade. That is not a score for being in the room. It records the in-class work: who you paired with, and what your pair decided and why. Showing up and not doing that work does not earn it.

The lowest three are dropped automatically, for everyone, with no reason needed and nothing to request. That covers illness, an interview, a bad morning, and a phone that would not submit. Beyond three, each further absence costs about a third of one percent, so an occasional miss stays cheap. What it will not survive is not coming: a student who misses every lecture but does everything else perfectly finishes at 92, which is an A minus rather than an A. That is deliberate. This course is built around what happens in the room, and a grade that says you mastered it without ever being there would not be telling the truth.

Lab exit tickets: three percent. Friday lab has its own short exit ticket, in its own category, worth three percent. It works the same way as the lecture one and is graded the same way, on submitting it rather than on what it says. The window differs by section, because the two lab sections meet at different times: it opens fifteen minutes before your own section ends and closes five minutes after. The lowest three of the ten are dropped, automatically and for everyone, which is what covers an illness, a conflict, or a morning that simply went wrong. Missing lab does not put an A out of reach on its own, unlike missing lecture; the two together do.

Reading checks: five percent. The short check due at 8:00 AM before each lecture is also its own category, worth five percent. It is graded on completion, so an honest wrong answer scores exactly what a right one does, and the whole thing takes about five minutes. The lowest two are dropped automatically, same as the exit tickets and for the same reasons, so an overslept morning costs nothing. Beyond two, each further miss costs about a third of one percent.

These two categories are the two halves of the same bargain: prepare before class, do the work during it. Together they are thirteen percent of your grade, which is a deliberate statement about where the learning in this course actually happens. Unlike the exit tickets, never doing the reading checks does not by itself put an A out of reach, because the reading is a means rather than the thing being measured. It will cost you real points, and it will cost you far more than that in class.

Exercises

Practice embedded in every unit, not graded, but expected.

Exercises are short activities built into each knowledge unit. They are not submitted and they do not count toward your grade. The goal is practice: try something, get it wrong safely, and learn from it. You are expected to do the exercises; they exist to make the hands-on work in the knowledge units land, not to generate a score.

Quizzes

A timed, summative check on the preceding two weeks’ material, taken at your own pace in the days after that block closes.

Roughly every other week you complete a timed quiz covering the knowledge units and labs since the last one. Each quiz is multiple choice, and you have twenty minutes per attempt, so focus on answering the questions within that time. You may take each quiz up to three times; your highest score is recorded. The quiz for the final week is cumulative across the full course. Together the six quizzes make up nine percent of your final grade. Quizzes are available on Canvas.

Homework

Four hands-on assignments that build the skills the project depends on.

There are four homework assignments across the term, one every two weeks from Week 2 through Week 10. Each is a hands-on task that involves building real web software: a running Express server, styled HTML pages, a JSON API with file and database persistence, and a tested and styled full-stack application. Homework is submitted through Gradescope and graded automatically against a rubric; you will see your score as soon as the autograder runs. Together the four assignments make up twenty-two percent of your final grade. Your scores from Gradescope will be periodically synced to Canvas.

Homework is organized into four assignments:

Homework 1 (Units 01-03, Labs 01-02): Server running, routes, and HTML served from Express.
Homework 2 (Units 04-07, Labs 03-04): CSS layout, JSON API, and HTTP fundamentals.
Homework 3 (Units 08-11, Labs 05-06): Forms with fetch, modules and middleware, and CRUD against a file.
Homework 4 (Units 12-15, Labs 07-08): Real database with MongoDB and Mongoose, tests with Jest, HTMX interactions, and Tailwind styling.

Each homework is assigned the Friday its last prerequisite lab is done and gets a full two weeks, due the Thursday right before the next homework is assigned. Homework ends after Homework 4, in Week 10. Knowledge units finish in Week 10; the weeks after that are devoted entirely to the team project, with no new units, quizzes, or homework.

Labs

Ten Git workflow sessions, graded on completion and subject to the same late-work policy as Homework.

Git and GitHub are not supplementary tools in this course; they are the medium through which all work is done and reviewed. Every homework submission, every sprint milestone, and every line of project code lives in a repository. Employers read GitHub profiles the way they once read resumes. The ability to commit cleanly, branch deliberately, resolve conflicts without losing work, and navigate a project’s history is not a nice-to-have for a web programmer; it is a baseline expectation. This course treats Git as a first-class skill and the labs are where that skill is built.

Labs run alongside the knowledge units and build the Git and GitHub skills the project depends on. There are ten labs, one per week across Weeks 1 through 10, run during the scheduled Friday lab section, each designed to fit in the section’s fifty minutes. Each lab teaches one Git skill in sequence: committing and pushing, branching and pull requests, merging and conflict resolution, reading history, stashing, interactive rebase, bisect, tagging, cherry-pick, and working across branches with worktree. The skills compound: each lab assumes you can do everything from the previous ones.

Each lab has four sections: Context (why this lab belongs here and what sprint it feeds into), Setup (the exact repository and branch state to start from), Tasks (numbered steps, each with a specific command and an observable outcome), and Success Condition (a one or two sentence definition of done that can be verified by inspection).

Labs are submitted through Gradescope. An autograder inspects your repository and checks that you reached the success condition; your commit messages and branch names are not evaluated against a rubric. Labs are graded on completion, not correctness. Together the ten labs make up seven percent of your final grade.

Sprints

A real full-stack web application built incrementally: each sprint applies only what the units taught so far have covered.

The Sprints are the team project itself, carried forward in stages rather than assembled at the end. Each sprint is due once the knowledge units that inform it are covered, so the application grows in lockstep with the course material. You cannot design the full architecture at the start; you do not yet know the patterns. Instead the application is extended one layer at a time: Sprint 0 forms the team and stakes out a domain idea; Sprint 1 produces the first running server; Sprint 2 delivers the first complete feature as a vertical slice; Sprint 3 replaces file storage with a database and adds tests and a styled frontend; Sprint 4 secures the application; and Sprint 5 polishes, documents, and delivers the four capstone artifacts.

Sprints 0 and 1 are half-weight (each worth half a full sprint); Sprints 2, 3, and 4 are full-weight. Sprint 5 is graded as the Project (20%) rather than as part of the Sprints category.

Sprints introduce no new instruction. They are where you apply the current state of the knowledge units to the web application your team is building. Teams are assigned by the instructor and are 3 to 4 members. Because this course has a separate lab sequence, the professional workflow skills that labs carry, clean commits, pull requests, code review, conflict resolution, are practiced in labs and then applied directly inside the sprints. Team contribution is assessed against objective GitHub evidence: your commits, the pull requests you authored and reviewed, and the merge history. Impressions are not graded; the record is.

Sprint 0: Team Formation and Project Foundation, due early in Week 2

Week 1 covers setting up the development environment and GitHub. Sprint 0 is about getting organized as a team and staking out a project idea while that setup is still fresh. No architecture decisions are required yet.

Shared GitHub repository created with all team members added as collaborators
README with team roster and working agreement
A short paragraph describing the domain the team wants to build and a first guess at what makes it an interesting project from a Computing for the Common Good standpoint

Sprint 1: First Running Server, due end of Week 3

Weeks 1-2 cover the devcontainer, Express routing, and serving real HTML. Sprint 1 asks the team to apply that to the project. No database, no frontend polish; just a running server on main that the whole team can start.

Shared GitHub repository with all team members as collaborators and branch protection on main
A running Express server with at least two routes: a home page and one domain-relevant page
A README.md that explains the project and tells a new contributor how to run it

Sprint 2: First Feature, First Vertical Slice, due end of Week 7

Weeks 4-6 cover forms with fetch, modules and middleware, CRUD against a file, and the layered architecture. Sprint 2 is the first time the team writes feature code. The goal is one complete vertical slice: a user can complete the primary action of the application from form to response.

At least one feature implemented end-to-end: form in the browser, POST to the server, business logic in a service, persistence to a JSON file, response rendered on the page
Routes, controller, service, and repository in separate files
All team members have contributed commits and at least one merged pull request

Sprint 3: Database, Tests, and a Real Frontend, due end of Week 9

Weeks 6-8 cover the database swap, service-layer tests, HTMX, and Tailwind. Sprint 3 extends the existing application with all three.

File-based repository replaced with a MongoDB (Mongoose) repository; no other layer changed
Jest tests for every business rule in the service layer; tests must pass
At least one HTMX interaction replacing a full page reload
Visual design applied with Tailwind CSS; the application must be usable on mobile and desktop

Sprint 4: Security, Authorization, and Pre-Demo Audit, due end of Week 11

Weeks 8-10 cover accessibility, authentication, and authorization. Sprint 4 secures the application and runs an accessibility audit.

Session- or token-based authentication; at least two user roles
Authorization rules enforced in the service layer; role-based access on at least one resource
Accessibility audit completed: keyboard navigation works end-to-end, all form controls are labeled, color contrast meets WCAG AA on primary surfaces
Health check route (GET /health) returning JSON status

Sprint 5: Final Polish and Delivery, due at the end of the term

Knowledge units finish in Week 10. The weeks after that carry no new instruction: time for the team to finish the application, raise the floor on what is already built, and deliver the four capstone artifacts that together constitute the Project (20%). All deliverables are due by the course end date.

All tests passing; no console errors on startup
README.md complete: setup instructions, environment variables, how to seed the database, how to run tests
GitHub repository URL: the repository must be in a state a new contributor could clone and run with a single command
Recorded video demonstration (10 minutes or less): the application starting from a clean state, at least two authenticated user flows shown end-to-end, and an explanation of one design decision and its trade-off
Project poster: one page (PDF) covering the problem the application addresses, the architecture, the key patterns demonstrated, and the trade-offs the team made
Reflection: submitted individually by each team member (not as a group); three sections: what you contributed (with specific GitHub evidence: commit links and PR links), what you learned, and what you would do differently

Project

The capstone: a complete full-stack web application that demonstrates the design, engineering, and craft of the course.

The Project is the summative destination the entire course is aimed at. Working in a team, you choose a problem domain in the spirit of Computing for the Common Good and build an application that serves real users: real authentication, a real database, a real frontend built with HTMX and Tailwind. The application is not a simulation; it is a complete, working piece of software that runs on a single command and demonstrates every major pattern the course covers.

You submit four deliverables as part of Sprint 5: the source code in your shared GitHub repository, a recorded video walkthrough of the running application, a poster presenting the problem, the architecture, and the trade-offs you made, and an individual written reflection from each team member on their own contribution and what they learned. You are assessed on collaborative practice, on meeting the sprint deliverable deadlines that pace the project from Week 1, and on professional conduct throughout, with contribution read from objective GitHub evidence and the grade weighted across the term. Deployment to a public host is not required and is not taught here; the destination is a complete application running in the dev container and demonstrated on video.

Schedule

The course runs across the Spring 2027 semester. The dated week-by-week calendar, with every due date, is posted on Canvas when the term opens. The sequence below is the plan: two knowledge units a week to match the two weekly lectures, one Git lab each Friday, and a sprint due each time the units it needs are done.

All 18 units are covered by Week 10. The weeks after that carry no new units or quizzes: they are for the team project.

Markers: (A) assigned, the team or the individual assignment can start, since the units it needs are done; (D) due. Sprint 0 is the exception, assigned on day one before any unit content, since it is just team formation.

Week	Units	Lab	Assignments
1	01 Hello Web; 02 Routes and Responses	Lab 01 First Commit, First Push	Sprint 0 (A)
2	03 Serving HTML and Templates; 04 Designing with CSS	Lab 02 Branching and the Pull Request	Sprint 0 (D), Sprint 1 (A), Homework 1 (A)
3	05 JSON: Data’s Native Language; 06 HTTP: The Protocol Underneath	Lab 03 Pulling, Merging, and Resolving Conflicts	Sprint 1 (D)
4	07 Living with Asynchrony; 08 Forms and Fetch	Lab 04 Reading History with Log and Diff	Homework 1 (D), Homework 2 (A)
5	09 Modules and Middleware; 10 CRUD Against a File	Lab 05 Stashing Work and Switching Context
6	11 Routes, Controllers, Services, Repositories; 12 From File to Real Database	Lab 06 Cleaning History with Interactive Rebase	Sprint 2 (A), Homework 2 (D), Homework 3 (A)
7	13 Tests as Specifications; 14 Partial Reloads with HTMX	Lab 07 Finding Bugs with Bisect	Sprint 2 (D)
8	15 Designing with Tailwind; 16 Accessibility as a Default	Lab 08 Marking Stable Work with Tags	Sprint 3 (A), Homework 3 (D), Homework 4 (A)
9	17 Cookies, Sessions, and Tokens	Lab 09 Moving Targeted Commits with Cherry-Pick	Sprint 3 (D)
10	18 Authorization, Roles, and Rules	Lab 10 Working Across Branches with Worktree	Sprint 4 (A), Homework 4 (D)
11 to end	No new units, project work		Sprint 4 (D), Sprint 5 (A), then Sprint 5 (D) at the end of the term

Week 9 and Week 10 each have one lecture without a new unit, kept for review and help time. Spring holidays and recess are on the University academic calendar; the Canvas calendar accounts for them.

Grades

All grades will be recorded and available in the Canvas Gradebook. Make sure you check your grades on a regular basis to ensure that they are correct. Homework and labs are graded by Gradescope, which you reach through the assignment in Canvas. Those scores are transferred into the Canvas Gradebook, so Canvas stays the single place to check where you stand.

Grading Scale

The number you earn maps to a letter with no curve and no surprises.

Final grades are computed from the weighted categories in the Assignments section and converted to a letter using the scale below. Grades are not curved. Your final percentage is rounded to the nearest whole number once, at the end of the term, so an 89.5 becomes a 90 and an 89.4 does not.

Letter	Range	Letter	Range
A	93 to 100	C	73 to 76
A-	90 to 92	C-	70 to 72
B+	87 to 89	D+	67 to 69
B	83 to 86	D	60 to 66
B-	80 to 82	F	below 60
C+	77 to 79

This is a four-credit course, and the grade you earn carries the same weight toward your degree and your GPA as any other four-credit course. There is no extra credit.

Communication

One channel, the right recipients, enough detail to get a useful answer on the first reply.

All course communication happens through the Canvas Inbox, the messaging tool built into Canvas. Do not send email directly to the instructor or to any member of the course staff. The addresses in the Staff section are listed for the record; they are not the way to reach us about this course, and a message sent to them may go unanswered.

The reason is not preference. Canvas keeps every course conversation attached to this course and in one place, which means a question does not get buried under the rest of a working inbox, any of us can pick up a conversation the others have already seen, and there is a single record to check when a question about a deadline or a grade comes up later. Email does none of that.

Who to address the message to

This is the part that decides how fast you get an answer, so it is worth getting right.

Administrative questions go to the instructor alone. Deadlines and extensions, grades and rubrics, enrollment, teams, accommodations, illness, and anything personal or private belongs in a message addressed only to me.
Questions about the course material go to the entire course staff. Add me and every TA and UCA listed in the Staff section as recipients. The dev environment, Docker, Node.js, Git and GitHub, the knowledge units, lab and homework content, and debugging your own code all belong here. Addressing all of us is not noise; it means whoever is free first answers you, which is almost always sooner than waiting on any one person.
Questions about your team project’s code or repository go on GitHub. Open an issue or comment on the pull request and mention your team’s liaison by their GitHub username; problems within your team go to your liaison in a private Canvas message. The liaisons are announced on Canvas once teams are set.

If you are genuinely unsure which one a question is, send it to the whole staff. Nobody will mind, and I will move it if it turns out to be something private.

How to send one

Open Inbox from the global navigation on the left edge of Canvas, click the compose icon, and choose this course. To reach the whole staff at once, click the address book icon beside the To field and pick the Teachers and Teaching Assistants groups rather than typing names one at a time.

Turn on notifications so you see a reply. Under Account, then Notifications, set Conversation Message to notify you immediately. Canvas will then tell you when a reply arrives, which is the one piece of setup this whole arrangement depends on.

What to put in it

Give the message a specific subject line naming what it is about, for example Sprint 3 branch protection question or Unit 11 layered architecture question, rather than Question or Help. A specific subject line is also what makes a conversation findable weeks later, by you as much as by us.

In the body, name the deliverable exactly, Sprint 3 or Unit 11 rather than a vague reference. For questions about the material, your code, or a grade, paste direct links to your repository and to the specific pull request, commit, or failing run. Copy any error message verbatim rather than describing it, and tell us what you have already tried so we do not suggest it back to you. End with the precise question you want answered.

Here is what that looks like in practice, for the two shapes a question usually takes. Sprints, Labs, and the Project have a GitHub repository, so the message links to it. Exercises and Homework do not, so the message pastes the code in directly.

Example 1: a Sprint question, where there is a repository to link. This is a question about the material, so it goes to the whole staff rather than to me alone.

To: Teachers Teaching Assistants

Subject: Sprint 3 Mongoose connection refused in the dev container

Our team is stuck on the Sprint 3 repository swap, the one that replaces the file repository with a Mongoose one. The server starts, but every request to /entries hangs for about thirty seconds and then the terminal prints:

MongooseServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017

Repository: github.com/team-cactus/326-project
Failing commit: github.com/team-cactus/326-project/commit/8c41f2a

I have already checked that the Mongo container is running: dc-up mongo reports no errors and docker ps lists it. I also tried changing the connection string to mongodb://localhost:27017/devdb and got the identical error. Line 12 of server.js currently has the fallback exactly as the Unit 12 page gives it, mongodb://dev:devpassword@mongo:27017/devdb.

What I do not understand is why the error says 127.0.0.1 when our connection string says mongo. Does that mean MONGODB_URI is not being read at all, or is this a container networking problem we should be looking at instead?

That message names the deliverable, quotes the error instead of describing it, links the exact commit rather than the repository alone, rules out the two things we would otherwise have suggested first, and ends with one answerable question. It takes a few minutes to write and it can be answered in a single reply.

Compare it to our database is not working, any ideas? That version cannot be answered at all. The only honest reply is a request for everything in the message above, which costs you a day and gets you no further than you were.

Example 2: a Homework question, where there is no repository. Exercises and Homework submit through Gradescope, not GitHub, so instead of a link, paste the function itself, not the whole file, just the part that is actually in question.

To: Teachers Teaching Assistants

Subject: Homework 2 Part 2, POST /logs assigns a duplicate id after a delete

On Homework 2 Part 2, POST /logs works the first few times, but once I delete an entry and add a new one, the new entry gets an id that already belongs to another log. Here is the handler:

app.post('/logs', (req, res) => {
  const { siteId, action, quantity, unit } = req.body;
  if (!siteId || !action || !quantity || !unit) {
    return res.status(400).json({ error: 'siteId, action, quantity, and unit are required' });
  }
  const newLog = {
    id: logs.length + 1,
    siteId,
    action,
    quantity,
    unit,
  };
  logs.push(newLog);
  res.status(201).json(newLog);
});

To reproduce: start with the three seed logs (ids 1 through 3), DELETE /logs/2, then POST /logs a new entry. It comes back with id: 3, which collides with the log that already has id 3, since the array only has two entries left at that point.

The assignment says to assign the new entry an id one higher than the current highest id in logs, so I do not think logs.length + 1 is what it is asking for, but I am not sure what the right replacement looks like once ids and array positions can disagree after a delete.

Is the fix to compute the highest existing id directly, and if so, is there a cleaner way to do that than sorting the whole array on every POST?

This one pastes only the handler in question, not the whole file, states the exact steps that reproduce the bug, quotes what the assignment actually requires, and names the specific line the student suspects rather than asking us to find it. That is the difference a repository link makes when there is no repository: the code itself has to do the work the commit link did in the first example.

Answers the whole class needs

When a question turns out to be one that many of you have, the answer does not stay in a single conversation. It goes on the Frequently Asked Questions page on Canvas, which is updated regularly through the term. Check it before you write, especially in the days before a deadline: your question may already be answered there, and reading the answer beats waiting for one.

Timing

Reach out early. A message about a deadline, an accommodation, or a situation that may affect your work should arrive before the deadline passes, not after. The staff aim to respond within one business day on weekdays; do not expect responses on weekends or University holidays.

Course Policies

Engagement, late work, incompletes, and exemptions.

This course has scheduled meetings (lecture twice a week, lab on Friday), and attendance at both factors into your Participation grade. Attendance alone is not the whole picture, though: the course moves steadily across the semester, each week builds on the one before, and because this is a building course, one missing piece can block everything downstream. Your engagement is measured by showing up, by the on-time completion of quizzes and homework, and by steady, visible contribution to your team’s project in GitHub.

Late work is handled differently depending on what kind of work it is. Homework assignments and labs may be turned in late for up to two days past the due date, with a deduction of ten percent per day; after two days they are no longer accepted and are scored as zero. Sprint deliverables and the final project submission are hard deadlines and are not eligible for the late allowance, because your teammates and the staff depend on that work being in place on time and because the schedule has no slack to absorb a slipped milestone. If something is going to prevent you from meeting any deadline, send me a Canvas Inbox message requesting an extension before the deadline passes. Proactive communication is the rule in this course, not a courtesy.

Incomplete grades follow university policy. An Incomplete (INC) may be granted only when a student who has been in good standing and has completed a substantial portion of the coursework is prevented by serious circumstances beyond their control from finishing on time. An Incomplete is never a substitute for a low grade and must be arranged with the instructor through a written agreement before the end of the term that specifies the remaining work and the completion date.

There are no exemptions from individual assignments. Every student completes the same work, with the single exception of arrangements made through Disability Services or for documented religious observance, both of which are described in the sections below.

Academic Honesty and Collaboration

What honest work looks like here, what counts as collaboration, and how to disclose AI use.

This statement is required by the University and is reproduced verbatim. Since the integrity of the academic enterprise of any institution of higher education requires honesty in scholarship and research, academic honesty is required of all students at the University of Massachusetts Amherst. Academic dishonesty is prohibited in all programs of the University. Academic dishonesty includes but is not limited to: cheating, fabrication, plagiarism, and facilitating dishonesty. Appropriate sanctions may be imposed on any student who has committed an act of academic dishonesty. Since students are expected to be familiar with this policy and the commonly accepted standards of academic integrity, ignorance of such standards is not normally sufficient evidence of lack of intent. For more information on the process and resolution of complaints, contact the Academic Honesty Office, 511 Goodell, (413) 577-6767, honesty@umass.edu.

Because this course is built around a team project, it helps to be explicit about where collaboration is expected and where it is not. Within your own project team, collaboration is the point: you share a repository, you co-design, and you build together. Across teams, and on all individual work such as quizzes, homework, and the individual reflection, the work you submit must be your own. You may discuss concepts with classmates, but you may not copy another student’s code or homework submissions, and you may not share your own for copying. Submitting another person’s work as your own, or handing your work to someone else to submit, is facilitating dishonesty and is treated as a violation.

AI Statement

AI is a tool you may learn with. It is not a tool that does your work.

You are here to build real fluency with web programming. That fluency comes from writing code, reading error messages, tracing a problem to its source, and getting to a solution yourself. An AI that produces the work for you skips exactly that, and leaves you with something you cannot explain and a skill you did not build.

So the rule for this course is simple, and it holds everywhere:

No AI may write code, prose, or designs that are being evaluated. Not on homework, not on labs, not on your team project, not on the poster or the video or the reflection. Not if you retype it in your own words afterward. There is one exception, for parts of a project that no rubric line assesses, and it has its own section below.

Everything below is about what AI may do, which is more than you might expect.

The levels

Every assignment in this course is tagged Level 0, 1, or 2. The level tells you what an AI tool is allowed to contribute. Level 3 is not a tag on an assignment; it is a carve-out you can declare inside a sprint or the project, described further down.

Level	What AI may do	What it may never do
Level 0: No AI	Nothing. Do not use an AI tool on this.
Level 1: General questions	Answer general questions about JavaScript, Express, HTTP, Git, or any other topic the course covers.	See your code, your error output, or the assignment text.
Level 2: Show and critique	Look at work you already wrote and tell you what is wrong with it or how it could be better.	Tell you what to write.
Level 3: Unrestricted, on declared support work	Anything at all, including writing the code, but only on parts of a project that you have declared and that no rubric line assesses.	Touch anything a rubric assesses, or go undeclared.

This course never goes above Level 2 on anything being evaluated. Higher levels exist in the wider world, where AI writes code that ships. That is real professional practice and you will meet it. You are not going to meet it here, on the work that is assessed, because this course exists to build the judgment that makes that practice safe, and you cannot build it by skipping it. Level 3 is the deliberate exception and it is narrow: it applies only to parts of your project that are not being assessed at all.

Which level am I at?

Two questions. Ask them in order.

Did the AI produce anything specific to my assignment? Code, prose, a structure, a plan, a diagram. If yes, you are above Level 2 and above what this course permits, whether or not you typed it out yourself.
Did the AI look at my work, my error output, or the assignment? If yes, that is Level 2. If no, that is Level 1.

Question 1 is the one that matters. “Specific to my assignment” is the whole test.

Asking “how does an Express route handler work?” is general. Writing the canonical three lines afterward is fine, because there is only one way to write them and you now know it. Asking “write the route for my entries endpoint” is specific, and so is “give me the steps to build this assignment.” Typing out the answer yourself does not change that.

Where each level applies

Assignment	Level
Quizzes 1-6	Level 0
Homework 1 and 2	Level 1
Homework 3 and 4	Level 2
Labs 1-10	Level 1, plus the rule below
Sprints 0-5, including README and diagrams	Level 2
Project: repository, video, poster, reflection	Level 2
Reading checks, exit tickets, and the Team Formation Survey	Level 0
Discussions and Reflections	Level 2

Homework 1 and 2 are stricter on purpose. At that stage, reading an error message and working out what caused it is the skill being built. So on those two, describe your problem in your own words if you want to ask about it. Do not paste your code or your error output. That restriction lifts at Homework 3, once the work becomes integrating things rather than getting them to run at all.

Labs have their own rule. Use AI to understand what git bisect or an interactive rebase actually does, as much as you like. But the commits, branches, merges, and rebases in your repository have to be operations you actually performed.

Editor autocomplete

Turn it off for coursework. GitHub Copilot, Cursor’s tab completion, and anything like them write code directly into your file, which is above this course’s ceiling on every assignment.

This is the item most likely to catch you out, because these tools are on by default and easy to forget about. If you use one for work outside this course, disable it for this repository, or use a separate editor profile.

What you do not need to worry about

Some things are not covered by any of this:

Seed data, fixtures, sample content, boilerplate config, and code formatting. None of these build a skill this course assesses. Generating forty rows of plausible test data is fine. Generating the code that reads them is not.
AI answers that arrive without you asking, like search-result summaries or an AI-written answer on a forum. Treat them as ordinary sources. You do not need to disclose reading one, but see “Facts are yours” below.
Anything covered by an accommodation. See below.

Level 3: parts that are not being evaluated

Your project will end up containing things that make it work but that no rubric line asks about. Something that sends a mail. Something that turns an address into coordinates. A deploy configuration, a one-off script that imported your starting data, a scheduled job. These are real engineering, they are often the interesting part, and none of them is a skill this course measures.

On those parts you may use AI however you like, including having it write the whole thing. Ask it to design the integration, generate the client, explain the API, write the config. There is no restriction and no ceiling, and using it that way is never academic dishonesty here.

What makes this workable is the boundary, so the boundary is strict:

If a rubric criterion covers it, it is not Level 3. Every sprint and every project artifact publishes its rubric with the assignment, before you build. Read it. Your layered architecture, your repository and validation, your tests, your database work, your HTMX and styling, your authentication and authorization, your README and system diagram, your video and poster and reflection: all assessed, all capped at Level 2. Level 3 is what is left over.
You declare it, before it is graded, in writing. In your own ai-disclosure/ file, list each part: what it is, where it lives in the repository, what job it does, why no rubric line covers it, and what the AI did. Mark it in the code too, with a comment at the top of the file, so whoever reads it knows without cross-referencing.
It earns you nothing. It is not assessed, so there are no points in it. It does not count toward Individual Contribution Evidence, and it cannot be the decision you write up for Design Decision and Trade-off, because you did not make that decision. A sprint where your only contribution is Level 3 work is a sprint where you contributed nothing assessable.
It still has to work. Not being assessed is not the same as not mattering. If your evaluated feature depends on it and it is broken, the evaluated feature is broken.
You are still responsible for it. It is in your repository and running in your project. If it leaks a key, mishandles data, or does something you cannot explain, that is yours to answer for. Do not ship what you have not read.

Where the dishonesty actually lies. Using AI on declared support work is not dishonest, no matter how much of it AI wrote. Three things are: declaring something as support when a rubric line does cover it; presenting AI-written support code as your own work, in your reflection, your video, or a conversation with me; and not declaring it at all. The first is the one to be careful about, because it is the one you might do by accident. If you are not sure whether something falls inside a rubric line, ask before you build it, not after it is graded. Asking is free and I will answer the same day.

Level 3 applies to Sprints and the Project only. Homework, labs, quizzes, reading checks, and exit tickets have no unassessed parts; the whole artifact is the thing being measured, so there is nothing to declare. It is also narrower than the list in the previous section: seed data, fixtures, sample content, boilerplate config, and formatting need no declaration at all. Level 3 is for the parts big enough that someone reading your repository would otherwise reasonably assume you wrote them.

Disclosing what you used

Where it goes depends on what you are handing in. For anything submitted from a team repository, which is the sprints and the Project, add ai-disclosure/<your-name>.md, lowercase kebab case, for example ai-disclosure/tim-richards.md. One file per person, you write your own, and nobody has to merge with anybody. For anything you submit as your own archive, which is Homework, put one AI-DISCLOSURE.md at the root of the zip. Either way: one entry per thing you used AI for.

Level	What to write
Level 1	One sentence: what you asked about. No transcript.
Level 2	A few sentences: what you asked, what it said, what you changed and why. Include the exchange if you have it. If the tool does not produce a transcript, describe what it looked at.
Level 3	What the part is, where it lives in the repository, what job it does, why no rubric line covers it, and what the AI did. No transcript needed. Declare it before the work is graded, not after.

That is the whole requirement. Level 1 is deliberately cheap, because asking a general question is a normal part of learning and making you write a report about it would just stop you from disclosing it.

On a team repository, write your own section, covering your own commits. You are not responsible for disclosing what a teammate did, and you will not be penalized for a teammate’s omission that you could not reasonably have known about. Talk to each other when you merge.

Write it as you go and submit it with your work. On a team repository the file accumulates, it is not rewritten. It lives there all term, so put a heading for each sprint and write underneath it rather than replacing what is already there. Earlier sprints stay as a record; when a sprint is graded, only that sprint’s section is read.

You may be asked to explain your own work

Any week, in lecture or in your lab section, you may be asked to walk through a specific piece of something you submitted: what it does, why you wrote it that way, what you would have done instead.

This is low stakes. It is not a test and it is not an accusation. It is folded into that assignment’s existing grade and there is no separate studying for it, because the point is simply whether the work is yours to explain. If you did it, you will be fine.

You will not know in advance which piece. That is the whole design, and it is why the policy above can stay short: being able to explain your own work is the thing that actually matters, and it is much easier to check than anything else.

If a live conversation is a barrier for you, ask and we will find another format.

Facts are yours

This one applies at every level, including Level 0.

Any claim of fact in your work is yours. If an AI told you how sessions work, or what a trade-off costs, or gave you a source, and you did not check it, and it is wrong, that is your error.

This matters more than it sounds. When AI writes wrong code, the compiler or the test suite usually tells you within seconds. Nothing tells you when it writes wrong prose. A confident, incorrect sentence in a README, a reflection, a poster, or a video script will pass every automated check this course has and land in your grade. Check what you repeat.

Accommodations, and writing in another language

Accommodations arranged through Disability Services override every level above. You do not need to make a case to me, and you do not need to disclose accommodated use in your disclosure file. It is not a disclosure event and it will never come up in any review of your work. If the explain-your-work conversation is a barrier, tell me and we will use a different format.

If English is not your first language, help with grammar and phrasing is fine on the reflections, discussions, README prose, and the individual reflection. Those exist to assess your thinking and your account of your own work, not your command of English prose. The substance has to be yours; the polish does not have to be.

If something does not add up

If your disclosure and your work do not seem to match, the first thing that happens is that I ask you about it. That is a conversation, not an accusation, and nothing is decided before it. Most of the time the answer is that the policy was unclear or something got left out, and we fix it and move on.

Only two things escalate past that: a disclosure that actively contradicts your work, or refusing to engage with the question at all.

And if you realize you went over the line, tell me before I ask. If you disclose it yourself, honestly and unprompted, we handle it as an academic matter for that piece of work, which may mean reduced credit or redoing it. It does not become an academic honesty referral. I would much rather you tell me.

How I use AI in this course

AI tools were used in building some of this course’s materials, alongside my own writing, editing, and review. I direct that work, I check it, and I am accountable for what it produces. Where a tool gets something wrong, that is my error and not the tool’s.

I mention it because I am asking you to disclose your own use, and a rule that runs in only one direction is not one anyone should respect. The reason it is not a double standard is narrow and specific: your submission is an instrument for measuring what you can do, and my materials are not. Nobody is trying to determine, from a syllabus, whether I can write a syllabus unaided.

What I owe you in exchange is a straight answer. Ask me, about anything in this course, how I checked that a given claim was true, and you will get one. If something here is wrong, I want to hear about it.

Disability Accommodation Statement

Reasonable accommodations are available; the sooner you register, the sooner they apply.

The following statement is required by the University and is reproduced verbatim. The University of Massachusetts Amherst is committed to providing an equal educational opportunity for all students. If you have a documented physical, psychological, or learning disability on file with Disability Services (DS), you may be eligible for reasonable academic accommodations to help you succeed in this course. If you have a documented disability that requires an accommodation, please notify me within the first two weeks of the semester so that we may make appropriate arrangements. For more information, consult the Disability Services website.

Disability Services is located at 161 Whitmore Administration Building and can be reached at (413) 545-0892.

Diversity, Equity, and Inclusion

A learning environment that works only when everyone in it is respected.

The Manning College of Information and Computer Sciences and this course are committed to a learning environment in which every student is welcomed and respected regardless of race, ethnicity, national origin, gender identity or expression, sexual orientation, disability, age, religion, socioeconomic background, or veteran status. Computing is built by teams, and the best computing is built by teams whose members bring different experiences to the problem. The Computing for the Common Good framing of this course rests on that premise: the applications you build are meant to serve real communities, which requires taking seriously perspectives other than your own. I expect every interaction in this course, in your teams, in your reflections, and in any communication with the staff, to be conducted with that respect. If anything in this course, including its examples, its assignments, or the conduct of a classmate, makes you feel excluded or unwelcome, please send me a Canvas Inbox message so that I can address it.

Title IX Statement

A safe learning environment, and the resources that protect it.

The following statement is required by the University and is reproduced verbatim. In accordance with Title IX of the Education Amendments of 1972 that prohibits gender-based discrimination in educational settings that receive federal funds, the University of Massachusetts Amherst is committed to providing a safe learning environment for all students, free from all forms of discrimination, including sexual assault, sexual harassment, domestic violence, dating violence, stalking, and retaliation. This includes interactions in person or online through digital platforms and social media. Title IX also protects against discrimination on the basis of pregnancy, childbirth, false pregnancy, miscarriage, abortion, or related conditions, including recovery. There are resources here on campus to support you. A summary of the available Title IX resources, both confidential and non-confidential, can be found at the following link: https://www.umass.edu/titleix/resources.

Chosen Names and Pronouns

You tell us who you are, and we use it.

I want to address you by the name and pronouns you use. If your chosen name or pronouns differ from what appears on the official roster, please send me a Canvas Inbox message at the start of the term, and I will use them in all communication and feedback. UMass Amherst allows students to designate a chosen name and a pronoun in SPIRE, which then propagates to Canvas and class rosters, and I encourage you to set these if you have not already. If I ever get your name or pronouns wrong, a quick, private Canvas Inbox message is welcome and I will fix it.

Student Support Resources

The course is hard by design; you do not have to navigate it alone.

Help with the course material comes first from the course staff, through a Canvas Inbox message addressed to all of us, and from the CICS supplemental instruction and tutoring resources offered through the Manning College advising office, which you can find on the CICS undergraduate advising pages. Beyond the course, the University offers support for the rest of your life as a student. The Center for Counseling and Psychological Health (CCPH) provides confidential mental health support and can be reached at (413) 545-2337, with a counselor available at that number at any hour. The Dean of Students Office helps students navigate personal emergencies, illness, and other circumstances that disrupt coursework, and can advocate on your behalf with instructors. The Writing Center offers free help with written communication, useful for the project poster and the individual reflection. The W.E.B. Du Bois Library provides research and technical resources, and the University offers food, housing, and financial assistance for students facing insecurity through the Dean of Students Office. If you are struggling for any reason, academic or otherwise, reach out early, to me through the Canvas Inbox or to any of these offices directly. Asking for help in time is a strength, and it is what these resources exist for.