homework 2: Sessions, State, and Interpolation

This assignment is due Feb 12, 2020, 23:59 CST.

Now that we’ve written a collection of failing tests, we’re going to make our app work.

At a high level, most web applications need to:

  • Authenticate users to allow them to maintain their relationship with your app
  • Keep track of user sessions while they browse the app
  • Update state on the server side based on the business logic of the application in question
  • Render the website using information visible to/relevant to any given user.

What you need to add

In short, you need to add everything necessary to make your tests pass. At a minimum, this will be:

  • A view engine: rather than manually concatenating strings as I mentioned in class, you can create static template files, and pass in variables to the res.render() function which will be interpolated with server side data to render the response that’s been customized for the current user. My personal pick for “easy to learn” templating language is Handlebars (docs tutorial).
  • Storage of local state: for this assignment, the easiest way to keep track of the state of the entire application is to simply keep it in app.locals. For instance, you could pre-populate the website database with an admin user, or testing users, or both.
  • Session management: you should be able to get the entirety of session management for this assignment out of express-session and its MemoryStore default storage. These sessions will only exist for the life of the Node server - as soon as it exits, all client state will be lost.

Restrictions

Instructor reviews worked very well for the last assignment. This time, we’ll be doing the same thing, but kicking it up a notch: one review by instructor per team per 48 hours. We will only provide a review if there is already an existing approved review. Please don’t send the instructor review request until the approved review already exists, as I won’t be checking notifications later if I don’t see the approved review when it first pops up.

Academic integrity

You are encouraged to use your google skills to streamline finishing this assignment. However, lifting a solution without understanding what it does is both a bad idea, and an academic integrity violation.

You can reuse code from these sources without penalty, as long as you link to where you found it:

Note regarding the MDN Express tutorial - the app they build in that tutorial is about 100x more complicated than a full credit implementation needs to be for this assignment. I would suggest taking a look at it only if you need to get an idea of how to get started on something.

If you use any other code from the web, you must:

  • Include a link to where you found it in a comment directly above that code
  • If it’s longer than 20 characters, ask yourself if you really understand what it does. If you don’t, you probably shouldn’t use it.
  • I reserve the right to consider any code reuse over 20 characters an integrity violation. If you want to use something you found online but you’re not sure whether you should, make a post on Piazza explaining what you are trying to do, and why/how this code you found achieves that. The better the explanation, the more likely I’ll allow you to use it.

In addition to adding links to places you directly pull code, if your solution is inspired by anything you’ve read online, you must put it in a SOURCES.md in the root of your repository.

New features

  • eslint. I’ve set up eslint in the skeleton code to require adherence to the airbnb style guide. Linters can be incredibly annoying but once you embrace them, 99% of the time they are incredibly useful because they are able to catch very many errors that you make, and with an IDE, usually as soon as you type them.

  • code coverage. I’ve also added a code coverage tool, which will run your tests on an instrumented version of your code and determine which lines get used and which don’t. I installed this extension to show in my editor which lines were being hit by the tests and which weren’t
    • a great way to determine whether your new code is actually being hit by your tests or not!

  • GitHub actions. I’ve turned on the GitHub CI pipeline to run the linter and code coverage tool every time you submit a pull request. This is the beginning of setting up a full CI/CD pipeline for our app. This isn’t much different than just running npm run coverage or npm run style at the command line, but because we’re running it within the code pipeline rather than just locally, we can do some more powerful things, like prevent code from being merged if it has linter errors.

  • assist mode: if you were happy with your tests from homework 1, feel free to merge them into your code here. If you would like to use my tests instead, you can pull them into your repository by merging in the instructor-tests branch of swad-hw2-helper-skeleton. I will add additional code that I write in class/as a result of Piazza questions to that repository, but for style points/learning points, I recommend only using code that you’ve written yourself.git

Because part of this assignment and class is to learn good software engineering habits, each team’s master branch will be protected, and require code review and no linter errors on pull requests. You’ll need to create a new branch, make all of your changes, push that branch to GitHub, and then use a pull request with a code review to successfully merge something into master. We will only be grading the master branch. If you are not comfortable with using git or the linter, get started early. Your code review can be from me/the TA using the grading oracle, but the typical code review should come from someone else in your team.

Note that the GitHub actions perform both the linter check and the coverage check, but I only require that the linter checks pass to be allowed to merge. It’s OK if your code coverage is low enough to get a ❌, this is a check for your benefit and not for grading.

Grading

UPDATE: to give everyone a level playing field and solid feedback, grading will be done using the instructor tests. If you would prefer to use your own tests instead, contact me and I’ll make a decision. If you’d like to program using your own tests for style points, please do. I have not finished testing my tests, so if they are buggy I will continue to fix them over the week.

The rubric will be 10 points per lowest level describe block, i.e. 10 for registration, 10 for login, etc. An additional 20 points will be given for eslint clean code and 20 points will be given for reasonably descriptive code reviews on all commits to master.

Contribution requirements

This assignment will not have individual contribution requirements. Your group grade will be shared unless there are exceptional situations, and if there is a severe imbalance in work distribution I reserve the right to give individual grades.

Standard mode vs. assist mode

The standard difficulty of this assignment is:

  • Use your own tests.
  • You cannot merge without a code review.
  • You cannot merge without a clean linter report.

However, assist mode exists to make the assignment easier, but with a potential cost to points on the assignment. I am willing to turn off the merge restrictions if your team requests them (private Piazza post with a link to your team repo is sufficient, however it may take me up to 24 hours to turn them off, so request them early if you think you want them). Requesting that I turn the restrictions off will not cost you any points, but allows you to not achieve those points. However, leaving the restrictions on allows you to complete the assignment the way it was intended, which is meant to enforce good habits that should pay off in the real world.

Things that can earn you style points this time around

  • Rather than using MemoryStore for your session storage or app.locals for session state, use something like redis or mongodb.
  • If you’re interested in getting started with client side frameworks (Vue/Angular/React), you can get a jump start by using react templates via express-react-views or Vue templates via express-vue. I’m not up to speed on these, so you’re on your own for this one.
  • Add an action that sends annotations to GitHub based on test failures, as in this example
  • 100% code coverage
  • Abstracted data model from router logic

Submitting your code

Your final commit to master on GitHub will be saved for us to grade.

You can accept the assignment at this link.