Project One: Due Monday, February 21, 2022

Shaping a Web System

Project Description

For this project, you will apply the approach and techniques outlined in Shape Up to shape and pitch a web system that integrates with other systems that are part of a business, governmental, or non-profit organization. In other words, what you’re shaping is not a complete, self-contained application (Facebook, for a bad example) but a system that fits into some broader, larger set of systems that makes up a business’s concerns. As a starting point, think about systems for billing, shipping, account management, internal communication, issue tracking, customer support, ticket- or seat-booking, and so on.

Deliverables and Deadlines

  1. Due by Thursday, February 10: Post draft deliverables to the Project One board on Basecamp. Your draft post should include:
    • Your name and Project Pitch as the post title (e.g., Scarlet Hawk: Project Pitch)
    • A link to a GitHub Gist with ideas of your Problem, Appetite, Solution, along with any clear Rabbit Holes and No Goes
    • Fat-marker sketches, diagrams, and illustrations embedded in your GitHub Gist.
    • Specific requests for feedback from the instructor and peers. Write this in the body of your Basecamp post
  2. Due by Thursday, February 10: Schedule a one-on-one consultation with the instructor. Sometime by the end of the day on Monday, February 14, you will have a one-on-on consultation with the instructor about your project draft. Watch for scheduling details on Basecamp.
  3. Due by Monday, February 14: Respond to at least 3 of your peers’ Draft Projects
  4. Due by Monday, February 21: Post final deliverables to the Project One board on Basecamp. Your final-deliverable post must include:
    • A link to a GitHub Gist of your written pitch, illustrated with fat-marker diagrams and sketches, outlining Problem, Appetite, Solution, Rabbit Holes, and No Goes.
    • A self-assessment, written in the text of the Basecamp post, of 250 words or so of your work on this project and your degree of confidence and satisfaction with your final pitch.

Project Requirements

Project Goals

  • Improve your ability to use rough sketches and brief, clear writing to describe and pitch a system design
  • Increase your skill in writing in GitHub-flavored Markdown syntax
  • Practice scoping and reducing a system to its core, essential components
Project Two: Due Thursday, March 31, 2022

Web System Alpha-Release Cycle

Project Description

In the first of three release cycles, you and your team will rapidly prototype and begin to design and construct a web-based, service-architected system. It will ingest data from one or more third-party APIs, accept user-input data via a web interface that you will provide written in HTML, CSS, and JavaScript, and deliver an outbound API serializing your system’s data for consumption elsewhere in an organization.

Plan to include unit, functional, and integration test coverage as early in your process as possible. Your work will proceed this cycle as a series of 0.x.x-alpha.x releases. And yes, you must use semantic versioning to number your releases.

Note that the requirements listed with this project are the overall system requirements for the final version to be delivered on Thursday, May 5. You and your team should choose which of these requirements to focus on at the alpha stage, and which to defer until the beta stage. For example, there is no requirement to deploy your system at the alpha stage, so your group might elect to defer deployment-oriented requirements until the beta stage (aka Project Three).

Deliverables and Deadlines

  1. Due by Thursday, February 24: Organize into teams on Basecamp. The class is small enough that there will be two teams of four people. Groups may not be smaller than four.
  2. Due by Monday, February 28: Pitch your team’s project to the instructor via Basecamp. You may opt to use as-is or refine any Project One pitch written by any of your team members. Alternatively, you may pitch an entirely new project idea. The instructor must sign off on your team’s pitch before you can proceed.
  3. Due by Monday, February 28: Schedule an early-cycle conference with the instructor. Sometime late in the week of February 28, you and your team will have a virtual chat of about thirty minutes with the instructor. Watch for scheduling details on Basecamp.
  4. Due weekly: Post team progress reports weekly on the class Basecamp. Aim to do these on Thursdays. Rotate responsibility among your team members for the weekly writeup of your progress and struggles. Reference your project’s repositories, commits, and release notes by URL as appropriate.
  5. Due by Thursday, March 10: Schedule a late-cycle conference with the instructor. Sometime during the week of March 21, you and your team will have a virtual chat of about thirty minutes with the instructor. Watch for scheduling details on Basecamp.
  6. Due by Thursday, March 31: Post your final alpha release project to Basecamp. Provide a team-authored report of your progress and challenges during the alpha cycle. Note the number and frequency of alpha releases you made during the cycle, and preview the work your team anticipates for the upcoming beta cycle.
  7. Due by Thursday, March 31: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project so far, and for each group member a 3–5-sentence assessment.

Project Requirements

  • You and your team must actively use some kind of communication hub for coordinating team work and communication (e.g., Slack, Discord, or a team-members-only Basecamp). It is up to your team whether to invite the instructor to participate. But that might be a good idea.
  • You and your team must use GitHub issue-tracking and code-reviews via pull requests to coordinate your team’s work and project progress.
  • You and your team must tag significant alpha releases according to the Semantic Versioning specification.
  • You and your team must publish release notes on GitHub to accompany all tagged releases, even at the alpha stage.
  • You and your team must write documentation for your system, both as a standalone file, such as a README.md, and as code-adjacent comments. You are encouraged to explore your options for generating documentation from inlined comments for the language you’re using (for example, JSDoc is a documentation generator for JavaScript).
  • Your system must ingest data from one or more third-party sources: either a data API or data that you scrape, maintain, and prepare in an API-like way.
  • Your system must implement at least one appropriate datastore. It’s possible that some parts of your system might rely on a database, and others on flat files, a hashed document store, or some other mechanism that persists data in the event of system restarts or crashes.
  • Your system must deliver error-free, standards-compliant HTML, CSS, and JavaScript to the browser. Your HTML must be valid and semantic; your CSS must be written in standalone stylesheets and rely on intelligent approaches to feature detection; and your JavaScript must be unobtrusive (that is, written leveraging event handlers and wholly avoiding deprecated JavaScript attributes in your HTML, such as onload).
  • Your system’s front end must deliver its core functionality to the browser even in the absence of JavaScript or CSS. CSS, JavaScript, and advanced front-end techniques—such as asynchronous requests, service workers, and web sockets—must be implemented in a progressively enhanced way.
  • Your system must provide a well-structured data API in an appropriate, error-free data-serialization format, such as JSON or XML, and it must feature sensible, developer-friendly data and endpoints. You and your team should include coverage of your API in your documentation.
  • Your system must include functional, unit, and integration tests on the back end, as appropriate, and visual regression-testing on the front end (e.g., BackstopJS).
  • Your system must limit its reliance on massive, all-in-one frameworks. You may choose either a front- or back-end framework, but not both. For example, if you opt to use Bootstrap (which, yuck), you will have to craft the back end of your system yourself. Choose wisely.
  • Your system should include one or more appropriate, leading-edge front-end development APIs. Options include local storage, service workers, web sockets, or any combination of elements that make up progressive web app architectures.
  • Your system should judiciously include feature-specific libraries, modules, or other packaged dependencies. Challenge yourselves as a group to develop the feature from scratch first (that is, using your language’s built-in APIs and standard library), and decide later whether to incur the technical debt and inherent risks of third-party dependencies. Consider also the technical debt and inherent risks of developing your own feature, of course.
  • Your system should support multiple runtime environments (e.g., development, testing, production). Your system’s configuration must be readily shareable among members of your team. A system that tucks its configuration into a MySQL database is almost certainly a non-starter.
  • Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.
  • Finally, like any temperamental client or manager, your instructor may amend, alter, or complicate the requirements and deliverables listed here at any time—but must provide you reasonable notice, via Basecamp, should that happen.

Project Goals

  • Analyze complex computing problems and apply principles of computing and other relevant disciplines to identify solutions
  • Assist in the creation, execution, and ongoing revision of an effective project plan
  • Design, implement, and evaluate a computing-based solution to meet a given set of computing requirements
  • Communicate effectively in a variety of professional contexts
  • Function effectively as a member or leader of a team engaged in activities appropriate to web-systems integration tasks
  • Identify and analyze user needs and take them into account in the selection, creation, evaluation and administration of computer-based systems
  • Apply security principles and practices to maintain operations in the presence of risks and threats
Project Three: Due Thursday, April 28, 2022

Web System Beta-Release Cycle

Project Description

In this second of three cycles, you and your team will push your system beyond its alpha stages to achieve greater stability and test coverage to produce and deploy a series of 0.x.x-beta.x releases.

Plan to include unit, functional, and integration test coverage as early in your process as possible. In fact, aim for 100% test coverage of your existing, alpha code before you move on to any other plans for your beta iterations.

Note that the requirements listed with this project are the overall system requirements for the final version to be delivered on Thursday, May 13. By the end of the beta cycle, you should have met all of these requirements. Be sure to take stock of them early in this cycle, and contact the instructor immediately if you’re concerned about any of them.

Deliverables and Deadlines

  1. Due weekly: Post team progress reports weekly on the class Basecamp. Aim to do these on Thursdays. Rotate responsibility among your team members for the weekly writeup of your progress and struggles. Reference your project’s repositories, commits, and release notes by URL as appropriate.
  2. Due by Thursday, April 28: Post your final beta release project to Basecamp. Provide a team-authored report of your progress and challenges during the beta cycle. Note the number and frequency of beta releases you made during the cycle, and preview the work your team anticipates for the upcoming public-release sprint.
  3. Due by Thursday, April 28: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project so far, and for each group member a 3–5-sentence assessment. Be sure to include links to your team repository as well as your individual fork of it.

Project Requirements

  • You and your team must actively use some kind of communication hub for coordinating team work and communication (e.g., Slack, Discord, or a team-members-only Basecamp). It is up to your team whether to invite the instructor to participate. But that might be a good idea.
  • You and your team must use GitHub issue-tracking and code-reviews via pull requests to coordinate your team’s work and project progress.
  • You and your team must tag significant alpha releases according to the Semantic Versioning specification.
  • You and your team must publish release notes on GitHub to accompany all tagged releases, even at the alpha stage.
  • You and your team must write documentation for your system, both as a standalone file, such as a README.md, and as code-adjacent comments. You are encouraged to explore your options for generating documentation from inlined comments for the language you’re using (for example, JSDoc is a documentation generator for JavaScript).
  • Your system must ingest data from one or more third-party sources: either a data API or data that you scrape, maintain, and prepare in an API-like way.
  • Your system must implement at least one appropriate datastore. It’s possible that some parts of your system might rely on a database, and others on flat files, a hashed document store, or some other mechanism that persists data in the event of system restarts or crashes.
  • Your system must deliver error-free, standards-compliant HTML, CSS, and JavaScript to the browser. Your HTML must be valid and semantic; your CSS must be written in standalone stylesheets and rely on intelligent approaches to feature detection; and your JavaScript must be unobtrusive (that is, written leveraging event handlers and wholly avoiding deprecated JavaScript attributes in your HTML, such as onload).
  • Your system’s front end must deliver its core functionality to the browser even in the absence of JavaScript or CSS. CSS, JavaScript, and advanced front-end techniques—such as asynchronous requests, service workers, and web sockets—must be implemented in a progressively enhanced way.
  • Your system must provide a well-structured data API in an appropriate, error-free data-serialization format, such as JSON or XML, and it must feature sensible, developer-friendly data and endpoints. You and your team should include coverage of your API in your documentation.
  • Your system must include functional, unit, and integration tests on the back end, as appropriate, and visual regression-testing on the front end (e.g., BackstopJS).
  • Your system must limit its reliance on massive, all-in-one frameworks. You may choose either a front- or back-end framework, but not both. For example, if you opt to use Bootstrap (which, yuck), you will have to craft the back end of your system yourself. Choose wisely.
  • Your system should include one or more appropriate, leading-edge front-end development APIs. Options include local storage, service workers, web sockets, or any combination of elements that make up progressive web app architectures.
  • Your system should judiciously include feature-specific libraries, modules, or other packaged dependencies. Challenge yourselves as a group to develop the feature from scratch first (that is, using your language’s built-in APIs and standard library), and decide later whether to incur the technical debt and inherent risks of third-party dependencies. Consider also the technical debt and inherent risks of developing your own feature, of course.
  • Your system should support multiple runtime environments (e.g., development, testing, production). Your system’s configuration must be readily shareable among members of your team. A system that tucks its configuration into a MySQL database is almost certainly a non-starter.
  • Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.
  • Finally, like any temperamental client or manager, your instructor may amend, alter, or complicate the requirements and deliverables listed here at any time—but must provide you reasonable notice, via Basecamp, should that happen.

Project Goals

  • Analyze complex computing problems and apply principles of computing and other relevant disciplines to identify solutions
  • Assist in the creation, execution, and ongoing revision of an effective project plan
  • Design, implement, and evaluate a computing-based solution to meet a given set of computing requirements
  • Communicate effectively in a variety of professional contexts
  • Function effectively as a member or leader of a team engaged in activities appropriate to web-systems integration tasks
  • Identify and analyze user needs and take them into account in the selection, creation, evaluation and administration of computer-based systems
  • Apply security principles and practices to maintain operations in the presence of risks and threats
Project Four: Due Thursday, May 5, 2022

Web System Public-Release Sprint

Project Description

Due to the semester’s time constraints (and an imagined impatient manager), this final cycle will deviate from the measured cycles for your system’s alpha and beta releases, and instead focus on a ten-day sprint to ship a 1.x.x version for public release.

Deliverables and Deadlines

  1. Due by Thursday, May 5: Post your final public release project to Basecamp. Provide a team-authored report of your progress and challenges during the short public-release cycle. Note the challenges you had operating on a much shorter development cycle, and preview the work your team would do next, were the project to live on beyond the current semester.
  2. Due by Thursday, May 5: Email self and group-member critique memo to the instructor. Write at least 5–7 sentences assessing your own work on the project this semester, and for each group member a 3–5-sentence assessment. Optionally, if you have suggestions for the instructor on how to improve this class in the future, please include those as well.

Project Requirements

  • Tag significant public releases, including release candidates, according to the Semantic Versioning specification
  • Your system must be deployed to a publicly available server, if you’ve not already done so.
  • Your deployment strategy must include the ability to roll back to an earlier, known stable version.
  • Once deployed, your system must be monitored by some type of lightweight monitoring software or process manager, such as PM2. Ideally, monitoring will be integrated to the extent possible with your deployment automation.

Project Goals

  • Quickly revise a system’s core functionality and features to ready an initial public release.
  • Monitor your system in production.
Project Five: Due Thursday, May 5, 2022

ITMD 567 Only: Academic Research in Web Development

Project Description

This project, required only of ITMD 567 students, will expose you to the academic research going on in relation web development. Each student will find ten topically related, peer-reviewed articles from ACM, IEEE, or other respected venues that publish academic research in computing, and then write and post to Basecamp an annotated bibliography of your chosen articles. Strive to find articles published within the last five years, and be sure you’re making use of the databases available through Galvin Library.

Deliverables and Deadlines

  1. Due by Thursday, March 10: Find and get instructor approval on a topic area within web development for your bibliography. Contact the instructor with your idea via email, or post it on Basecamp.
  2. Due by Thursday, April 14: Post draft bibliography to Basecamp, in its own thread. Be sure to include:
    • A link to your draft bibliography as a GitHub Gist
    • The full citation to each article, in ACM style
    • Your 150-word annotation of each article
  3. Due by Thursday, May 5: Post final bibliography to Basecamp, in a follow up reply to your original thread. Be sure to include:
    • The link to your complete, final bibliography as a GitHub Gist
    • The full citation to each article, in ACM style
    • Your 150-word annotation of each article

Project Requirements

  • Prepare your annotated bibliography as a GitHub Gist in Markdown format.
  • Your annotated bibliography must contain 10 sources.
  • You must format your 10 sources according to ACM reference style.
  • Your chosen articles should each be between 5 and 25 pages in length.
  • Your chosen articles should have been published within the last five years.
  • Your chosen articles must all be published in English.
  • Your annotation for each article in your bibliography should be as close to 150 words long as possible (neither substantially longer nor shorter).

Project Goals

  • Learn to search in the academic research surrounding web development.
  • Learn to build an academic bibliography.
  • Learn to read academic research effectively.
  • Learn to write concise but comprehensive summaries of academic research.

Course Information

Instructor