Skip to content

homework 0 - calibration & assignment turn in

Deploy and test your first web app

Quickstart: Accept the assignment by creating a personal private repository in GitHub using the homework0 template repository (click the “use this template” button). This repository is not automatically shared with the instructors, so if you want us to see your code and help when needed, please share it with kaytwo and nkgotcode. To complete this assignment, make the changes described below, ensure that your web application is available on the Internet, and then submit via Gradescope.

Due: Thursday, August 29, 2024 at 2:00:00 PM

By the end of this assignment you will have your own web app deployed on the web for all to see. The coding part is dead simple - you just have to change the text in a few files. The more important part is getting your tools set up for Continuous Integration and Continuous Deployment.

New this year: Unix-based development environment required

One of the awesome things about web development is that on the server side and the client side, it’s pretty cross-platform. However, once you get into more advanced topics, you’ll find that the vast majority of web servers are running Linux, and many developers are using Macs or Linux machines for local development.

If you’re on a Mac or Linux, you’re all set for the first couple assignments, local development will work as expected. If you’re on Windows, you have a few options:

  • You can use the Windows Subsystem for Linux to create a Linux environment on your Windows machine. VSCode has some great tools for working with WSL, but they aren’t required.
  • You can use a virtual machine to run a full Linux distribution. This is a bit more heavyweight than WSL, but it’s a good option if you want to get used to using Linux. If you’re on a new ARM Windows laptop, this might not work as expected, and I can’t provide support as I don’t have one to test with.
  • When developing in your repository in the ckanich-classrooms GitHub orgnaization, you have access to GitHub Codespaces, which provisions a web based IDE. This is especially helpful if you aren’t running Linux natively and have restricted RAM on your laptop - while it’s possible to use WSL and/or Docker with 8GB of RAM, it can get pretty tight. I’ve enabled Codespaces for this assignment, but haven’t tested it extensively. If you have issues, please let me know.

One tricky part is that most things will work on Windows, but many things will start breaking in unexpected ways. So unless you’re really intent on developing in Windows, I’d suggest using one of the options above for working on your assignments in this class.

Local development

After creating your own personal private repository using the template linked above, you can clone this repository in your development environment and open that directory in your favorite IDE. I recommend VS Code, as I will be using that for my demonstrations.

Installing Node.js

We will be using Node.js to build and run JavaScript applications. The easiest way to get started is to go to the Node.js download page and download the LTS version of Node.js for your laptop. This will allow you to use the node command to run JavaScript programs from the command line, and use the node package manager npm to download dependencies for your project, install additional packages, run package scripts, and more.

Running the template

Open your new project in your IDE, and in the console run npm install to download the code for all of the dependencies needed to fully run the project. You can then run the code in development mode by invoking the dev script by running the command npm run dev. This will run your app in a special mode where any updates to your source code are immediately pushed to the browser via a special plugin that isn’t included in your code when you actually build it for production.

Codespaces option

I’ve also enabled to the GitHub Codespaces feature. Codespaces creates a linux container in the cloud that allows you to run a fully featured Visual Studio Code, with access to all extensions and even extra linux containers for things like databases, without having to install anything on your local machine.

I haven’t tested it yet as a way to start working on this assignment specifically, but it should allow you to do every assignment for this class directly from your browser.

Getting the most out of your IDE

Modern programming makes extensive use of strong typing - the ability to declare (or infer) at build time what type any given symbol refers to. Importantly, this allows your IDE to understand your code as you type, and give you suggestions for which methods to call, what value an argument should take, or inform you when you’ve used something incorrectly.

To get full credit on this assignment, you must pass a formatting checker, a a type checker, and a lint checker.

Format checking

Formatting your code according to a standard makes it easy to look at code diffs, both by making the code easy to read, and by minimizing the chances that changes that don’t impact the functionality of your code (like whitespace and newlines) show up in the diffs at all. Your brain capacity is the limiting factor in good programming, and you should be using tools that minimize your mental effort whenever possible.

In this project, we use Prettier with the default settings. In VSCode, you can install the extension and turn on editor.formatOnSave and set Prettier as the default formatter, and your code will be formatted correctly automatically. The points you get for proper formatting should be the three easiest points you’ve ever gotten.

Type checking

TypeScript introduces strong typing to JavaScript through a superset of the language. The TypeScript compiler can confirm every use of a symbol against the types for those objects/functions/operators/etc, and ensure that they are being used correctly. Visual Studio Code performs type checking by default on TypeScript files, so you should see any type errors by default as red squiggles and in the “Problems” panel.

Lint checking

Linting checks for issues that will not necessarily cause your code to crash or even run incorrectly, but nonetheless are very usually errors. Take for instance the no-dupe-else-if rule, which states that you can’t use the same conditional more than once in the same set of else-if statements. So while this code is correct JavaScript that can execute:

if (a) {
foo();
} else if (b) {
bar();
} else if (b) {
baz();
}

The call to baz() will never happen, and it’s very likely there’s some programmer error happening here. Linters are designed with dozens of rules that help find issues like these for you.

How to “fix” the code

You only need to change two files in the repository: you need to edit student.json in the root of the repository to include your email address, and you need to change src/main.ts to include your own email address instead of ckanich@uic.edu. You’ll need to edit student.json again later, but that’s all for now.

How to look at your website

If you want to experiment with your website, you can run npm run dev and your email address should show up as soon as you save main.ts. As long as my email address doesn’t show up in the text of the site, and yours does as part of the string “website of youremail@uic.edu”, you can make it look as pretty or ugly or ridiculous as you want. Go nuts!

Local testing

Once you have edited those files, you can run the local tests by running npm run test script. This script will look through your repository for specially named files (in our case, files that end in .test.ts, of which there is only one), and run them in the testing environment. The tests in this assignment are all in src/main.test.ts and are worth taking a look at to understand.

Before getting to the Continuous Deployment section, you should be able to get the two “on the dev server” tests running for 10 points.

Remote testing

AKA Continuous Integration

When you’re the only person working on a repository, it makes sense to run the tests locally. But once you start working in larger teams on important software, it’s important that there’s one source of truth for whether the tests are passing or not. To simulate that, this repository is set up to use GitHub actions to do continuous integration testing. The file .github/workflows/ci.yaml describes the list of tests that are run; it simply installs all of the dependencies, then runs the three format, lint, and type check scripts, and fails if any of them fail. You can see the output of the CI runs in the Actions tab for your repository.

Continuous Deployment

So far, we’ve built and run our code locally, and on GitHub’s servers. Now for the fun part - deploying our web app. You must deploy your web app to the Internet for full credit on this assignment. There are many free places to do so, including Cloudflare Pages and Render. I recommend using one of those as they are the easiest to set up and have features we will use later on in class, but you can use Amazon, Vercel, Netlify, GitHub pages, or any other service as long as the web app can be deployed successfully and stays online (we may re-run the autograder at any time!). The one thing you may need to configure is the build command: we are using the vite build tool, so the command to build your code is npm run build and the files that should be served (the output of the build) are in dist/.

To get the next 10 points, you need to follow the instructions at any of those services and deploy your web page. They will give you a url that ends in pages.dev, onrender.sh respectively (sometimes they give you a random string, but you can customize it if you want). Replace http://domain.invalid in student.json with your new web app URL, and deploy your app. If you’ve correctly set up the deployment service, all you need to do to deploy your app is git push your edits, and the service will receive a notification from GitHub that your code changed, then it will pull the code, build the website, and push the built website out to the Internet.

If you’ve done all of this without introducing any type/format/lint errors, npm run test should all be passing and you are well on your way to 100% in the class. Great job! 🎉

Submitting your work

After you are confident that you are passing all of the tests, you can submit it via Gradescope. Check Piazza for the Gradescope invitation code. All the Gradescope autograder does is re-run the same tests again; if your tests are passing both on your local machine and on GitHub, it shouldn’t fail on Gradescope. If you have issues with the autograder, please contact us via Piazza ASAP.

Our deadlines in this class are firm, down to the millisecond. If there are any documented outages with Gradescope or GitHub during the 12 hours before the deadline, we’ll extend it by 24 hours. For any other exceptional situations, we drop the lowest homework assignment for every student to be fair to everyone whether they ask for an exception or not.

Note that extensions due to DRC LOA’s do not count toward this policy, please see the syllabus for more details.

Please keep in mind that technical issues while submitting your assignment is not an acceptable excuse for improper or late submissions.

Points

Each test is worth five points, each source check is worth three points, for a total of 23 points. Note that this implicitly tests your ability to download Node, install packages, edit files, upload to github, etc.

This is almost certainly the easiest assignment, so I recommend you aim for full points. Getting this done should take less than a half an hour, even if you’ve never used JavaScript before.