During this course, over 5 assignments that build on each other, you will create an Internet-based application of your choice. This will be a laboratory for you to explore your own interests and how you might use the Internet to enable them. Along the way, you’ll make use of the many protocols and communication mechanisms we learn about during lectures, and you’ll learn to build a realistically sized application using the language of the Internet, JavaScript.
Given the broad collection of options you could choose to work on and our limited time during this semester, we’ll need to narrow the scope of an idea to make it workable for a sememster project. Never fear, though, as this is often the case in the professional world too. In many cases, given a huge, multi-year goal, you’ll be asked to implement a minimum viable application (MVA) that demonstrates that what you’re trying to do is possible. Once that’s done and working, you can continue improving it toward the larger goal. We’ll work that way in this course too. And if you still have more to do to reach your personal goal at the end of the course, you can continue to improve it on your own using what you learn this semester.
As with other work in this course, I will provide feedback as I see your work, but you will not receive a numeric grade for the assignments here. I encourage you to start early and submit early, so that I can provide feedback early, which you can then use to improve your work prior to the deadline.
The following 5 assignments, explained in detail below, constitute the course-connected portion of your project:
At the end of the course, during the final exam period on Tue, Dec 12, 2023, from 7:00 PM to 9:00 PM, we’ll celebrate our work together. This will be your chance to talk about your goal, show off your work, and discuss what you hope to do with it in the future.
In this first assignment, you’ll write a proposal for your project. This proposal will involve you selecting the big goal you want to tackle, and making a first attempt to define what the minimum viable application might look like that addresses this goal.
Your project should express something about yourself. It might:
The possibilities are endless. I look forward to seeing what you decide to work on.
| Introduction | Tue, Aug 22, 2023 |
| Office hours | By appointment |
| Assignment Due | Tue, Sep 5, 2023 |
Write a proposal for a project to be completed this semester. Your proposal should have:
The minimum viable application you define must be a web-based application involving at least a server component (usually where any business/operational/security logic happens) and a client component (the code that runs in your web browser that makes the user interface run).
You may use whatever software you wish to write your proposal. However, to submit it, you must submit a PDF format document.
Your proposal document must be submitted via the Canvas assignment, and must be submitted at least once before the deadline in order to be marked complete.
You will receive feedback as I receive your proposals. I will provide feedback as soon as possible, and at a minimum within 72 hours of submission.
Note that you can submit any assignment multiple times. If you submit an early draft well before the deadline, I will be able to provide feedback and work with you on your proposal, after which you can resubmit with changes based on our discussion.
Building on your proposal from the first assignment, you’ll break down the functional requirements of each component of your project in a project specification document.
| Introduction | Tue, Sep 19, 2023 |
| Office hours | By appointment |
| Assignment Due | Tue, Oct 3, 2023 |
Your specification should define the scope of the course-connected portion of your project and should contain a number of user stories that each identify the who, what, and why of each piece of functionality.
A user story is a requirement statement that identifies the basic characteristics of a piece of functionality: the role of a user with an activity or goal in mind, the desired action they would like to take, and their motivation for using that functionality.
A user story usually initially takes the form
As a
_________________(who: user role)I want to
_________________(what: capability/activity/goal)so that I can
_________________(why: motivation).
Once you’ve written a number of user stories, you can collect them into groups to identify the different user roles your application should support, the major types of activity your application should support, and the different types of motivations users bring to your application. You can add these categories to each of your user stories in order to identify themes you can focus on independently while working on the application. This will help you to focus your efforts and complete working software in small increments.
You can capture these user stories and organize them in many different ways, but often the easiest method is to write each story on a 3”x5” index card with a marker or thick pen. This way, you can easily read what’s on the card, and can easily shuffle them and re-shuffle them into categories and themes, noting their categorizations and themes with annotations in the margins or on the backs of the cards.
Once you’ve developed your collection of user stories and identified the categories and themes among them, you will want to prioritize those themes and decide which of them need to be part of your minimum viable application (MVA). You may decide that some themes can easily be split into multiple phases of implementation, allowing you to prioritize a portion of that theme for early development and other portions of that theme later.
Once prioritized, identify among the highest prioritized themes those that are important to include in the minimum viable application. Then, for those themes, identify whether each user story involves creating new capabilities in the browser-based client application, in the server application that supports it, or in both. If there are portions of the same user story that involve creating new capabilities in both applications, you will need to make a note on the story of what portion of the functionality belongs in the server and what portion belongs in the client.
These MVA-relevant themes and their user stories should then be captured in a project board in your project GitHub repository. You can find the project board feature under the Projects tab of your project repo. For more information on project boards, see the GitHub documentation here.
Your project board will serve as a guide for you during development of the next three assignments, so it’s very important that you create the relevant cards there.
Once all that is done, you will need to write a specification document identifying the goal and synopsis of the project based on your proposal and discussion with the instructor, the major user roles, themes, and other categorizations identified, and the portion of the work identified for the MVA with reasons for that prioritization.
Your specification document should reference your project board and should contain a link to the project repostory within the document.
The project board must be completed in your project GitHub repository.
Your proposal document can be written in whatever software you wish, but must be submitted as a PDF format document.
Your proposal document must be submitted via the Canvas assignment, and must be submitted at least once before the deadline (along with organizing and collecting your story themes relevant to the MVA in your GitHub repo) in order to be marked complete.
I will review and provide feedback on both the project board and the document.
You will receive feedback as I receive your proposals. I will provide feedback as soon as possible, and at a minimum within 72 hours of submission.
As before, if you submit early, you will receive feedback early, and may have the opportunity to act on feedback and resubmit a revised work prior to the deadline.
Once you have completed the project specification and project board, it’s time to start working on your application. To start, we’ll look at the browser-based, client side of the work.
| Introduction | Tue, Oct 17, 2023 |
| Discussion/Lab Class Period | Tue, Oct 17, 2023 |
| Discussion/Lab Class Period | Tue, Oct 24, 2023 |
| Office hours | By appointment |
| Assignment Due | Tue, Oct 31, 2023 |
To do this, we’ll use JavaScript with HTML and CSS, as you might expect, but we’ll also use three key JavaScript libraries and three infrastructure tools/services:
You will start by negotiating the set of requirements you will attempt to implement for this portion of the project with the instructor.
Once these are decided and you have committed to a specific set of user stories to work through, you will implement as many of them as you can before the deadline.
This assignment must be submitted as a link to your project board in the Canvas Assignment. (You may also submit a link to a filtered view of your project board containing only relevant user stories, if you wish.)
While working through your project board, I recommend you convert each user story card to an issue on the repo. Then, as you write code to implement the user story, you can do that on a new branch in the repo and submit that branch as a GitHub Pull Request. Your PR will provide a good mechanism for feedback on your work, and can be linked back to the issue to provide for easy tracking of what code changes implemented what features in your application.
If you don’t feel the code in your PR is ready, but still need early feedback, you have the option to create your PR in Draft mode, which will indicate to your reviewer(s) that you are requesting feedback at an early stage of implementation (as well as prevent accidental merging to the main branch of the repo).
I will review and provide feedback on Pull Requests (PRs) as requested throughout the assignment period. Before requesting feedback, be sure to identify the following in your PR description:
#24 would automatically create a link to GitHub Issue 24 on the same repo).To request feedback, you can tag me on the Pull Request either in the Reviews section at the top right of the PR screen, or by tagging my username in a comment on the PR. My GitHub username is @nihonjinrxs.
Starting with this assignment, it is imperative that you push your code to a remote branch on GitHub and create a PR as soon as possible, pushing code changes as you create them. This will allow for the most real-time feedback, and will support you in your learning and in accomplishing your goals for the project.
Once you have completed the project specification and project board, it’s time to start working on your application. To start, we’ll look at the browser-based, client side of the work.
| Introduction & In-class Demo | Tue, Oct 31, 2023 |
| Discussion/Lab Class Period | Tue, Nov 14, 2023 |
| Office hours | By appointment |
| Assignment Due | Tue, Nov 21, 2023 |
To do this, we’ll use JavaScript on the server through Node.js, along with three key JavaScript libraries and three infrastructure tools/services:
You will start by negotiating the set of requirements you will attempt to implement for this portion of the project with the instructor.
Once these are decided and you have committed to a specific set of user stories to work through, you will implement as many of them as you can before the deadline.
cURL or a similar generic non-browser web request interface.This assignment must be submitted as a link to your project board in the Canvas Assignment. (You may also submit a link to a filtered view of your project board containing only relevant user stories, if you wish.)
While working through your project board, I recommend you convert each user story card to an issue on the repo. Then, as you write code to implement the user story, you can do that on a new branch in the repo and submit that branch as a GitHub Pull Request. Your PR will provide a good mechanism for feedback on your work, and can be linked back to the issue to provide for easy tracking of what code changes implemented what features in your application.
If you don’t feel the code in your PR is ready, but still need early feedback, you have the option to create your PR in Draft mode, which will indicate to your reviewer(s) that you are requesting feedback at an early stage of implementation (as well as prevent accidental merging to the main branch of the repo).
I will review and provide feedback on Pull Requests (PRs) as requested throughout the assignment period. Before requesting feedback, be sure to identify the following in your PR description:
#24 would automatically create a link to GitHub Issue 24 on the same repo).To request feedback, you can tag me on the Pull Request either in the Reviews section at the top right of the PR screen, or by tagging my username in a comment on the PR. My GitHub username is @nihonjinrxs.
Starting with this assignment, it is imperative that you push your code to a remote branch on GitHub and create a PR as soon as possible, pushing code changes as you create them. This will allow for the most real-time feedback, and will support you in your learning and in accomplishing your goals for the project.
Once you have completed the project specification and project board, it’s time to start working on your application. To start, we’ll look at the browser-based, client side of the work.
| Introduction | Tue, Nov 21, 2023 |
| Thanksgiving Break | Nov 22—24, 2023 |
| Discussion/Lab Class Period | Tue, Nov 28, 2023 |
| Office hours | By appointment |
| Assignment Due | Tue, Dec 5, 2023 |
To do this, we’ll use JavaScript on the server through Node.js, along with three key JavaScript libraries and three infrastructure tools/services:
You will start by negotiating the set of requirements you will attempt to implement for this portion of the project with the instructor.
Once these are decided and you have committed to a specific set of user stories to work through, you will implement as many of them as you can before the deadline.
cURL or a similar generic non-browser web request interface.This assignment must be submitted as a link to your project board in the Canvas Assignment. (You may also submit a link to a filtered view of your project board containing only relevant user stories, if you wish.)
While working through your project board, I recommend you convert each user story card to an issue on the repo. Then, as you write code to implement the user story, you can do that on a new branch in the repo and submit that branch as a GitHub Pull Request. Your PR will provide a good mechanism for feedback on your work, and can be linked back to the issue to provide for easy tracking of what code changes implemented what features in your application.
If you don’t feel the code in your PR is ready, but still need early feedback, you have the option to create your PR in Draft mode, which will indicate to your reviewer(s) that you are requesting feedback at an early stage of implementation (as well as prevent accidental merging to the main branch of the repo).
I will review and provide feedback on Pull Requests (PRs) as requested throughout the assignment period. Before requesting feedback, be sure to identify the following in your PR description:
#24 would automatically create a link to GitHub Issue 24 on the same repo).To request feedback, you can tag me on the Pull Request either in the Reviews section at the top right of the PR screen, or by tagging my username in a comment on the PR. My GitHub username is @nihonjinrxs.
Starting with this assignment, it is imperative that you push your code to a remote branch on GitHub and create a PR as soon as possible, pushing code changes as you create them. This will allow for the most real-time feedback, and will support you in your learning and in accomplishing your goals for the project.
During the Final Exam period, rather than take an exam, we will use that time to celebrate our work together. We’ll show off our project work to our classmates.
Each person will have 6 to 8 minutes to present their work and discuss it. During your turn, you will want to briefly:
Please do not feel any pressure or anxiety about this. It is not a formal presentation, it is not a graded activity, and it is intended only to be a way to enjoy the shared excitement felt after successfully creating something you care about.
That said, if it helps you to create slides for your discussion points, even if they only have pictures on them and some speaker notes for you, please feel free to do so, but keep them informal. (All content should, of course, be appropriate for a classroom session.)
When you’re not presenting, you should be celebrating your classmates. Once they’ve finished speaking, feel free to clap, laugh, cheer, congratulate, or ask questions of your classmates.
As part of the celebration, please bring your favorite treat and non-alcoholic beverage to the video call to enjoy during the celebration.