final project checkpoint 1 and 2: Final Project Proposal

This assignment is due Feb 24, 2020, 23:59 CST. You can accept the assignment at this link.

Now that we’ve written a very basic app, it’s time to throw it all out and start over. I’ll be the first to admit it - the favorite number app was super lame.

From here on out you’re going to be working on an app completely of your own design. For the rest of the semester, each homework assignment will serve as a checkpoint on the completion of your final project. Those checkpoints will be: (all due at 11:59pm Chicago time)

  1. Monday February 24th: Final project proposal due. This includes:
    • A description of the functionality of the final application in README.md
    • A description of the deliverables you will have done by checkpoint 2
    • A description of the deliverables you will have done by checkpoint 4
    • Boilerplate code for your application (something roughly equivalent to the output of the express application generator would work. It would also be a great idea to build off of your previous assignment’s source code, which is already set up to run tests and generate code coverage)
    • A collection of English-language test descriptions within a testing framework of your choice, ready to be run for ALL of the checkpoint 2 deliverables. This is equivalent to the first half of the deliverables for Homework 1.
    • A security evaluation of your proposed application. This should answer questions like:
    • What things would an attacker potentially want to do using our app that we wouldn’t want them to do?
    • What best practices will we follow security wise for this assignment?
      • How will we accomplish them?
    • A great way to structure your security evaluation is to follow the OWASP Top Ten, and go over how your app COULD be vulnerable, and mention how you will PREVENT it from being vulnerable.
  2. Monday March 2nd: Checkpoint 2 due. This checkpoint MUST:
    • implement some form of CRUD data manipulation
    • store the data in a backing store outside of the web app code itself (e.g. mongodb)
    • include a full test suite for the CRUD functionality that works via a GitHub Action
    • enumerate the deliverables for the 4th checkpoint
      Thursday March 5th: Midterm Exam in class
  3. Monday March 16th: UNNAMED SPOOKY SECURITY RELATED ASSIGNMENT
  4. Monday April 6th: Checkpoint 4 deliverables due. If you ran into any snags (feature X was way harder than you expected at the beginning), you can make your case for changing final deliverables.
  5. Monday April 20th: Final deliverable due.
  6. Week 15: POTENTIAL for in class final project presentations. I haven’t decided yet.

What your app should do

Literally anything. It should have some functionality beyond CRUD. You should have a group formed and a good idea of WHAT you want your app to do by Thursday February 20th at the latest. If you can’t think of anything you can contact me with the interests of the folks in your group and I can try to suggest something.

This is your opportunity to build WHATEVER you want. You can keep the repository after class is over and show it to prospective employers. You can turn it into a startup and make a billion dollars. You’re only limited by your imagination and hard work!

What your app must do

Beyond implementing the functionality mentioned above, your app must:

  • Have 100% code coverage for your app’s tests with all tests passing. Anything above 80% will receive a large amount of partial credit for this requirement.
  • Be deployable within a brand new environment by a new user. 50% of your grade will be determined by the app being run in a brand new environment by a brand new user (see Final deliverable below). This deliverable requires good documentation, and good adherence to the 12 factor app principles of keeping code, dependencies, environment, and configuration separate.
  • Integrate with the functionality of at least one external API. Just including the code as per the default settings in API’s demo documentation is insufficient, there needs to be some interesting transformation of the information / automation of the interaction with the API. The GitHub Student Developer Pack is a great place to look for services that you could potentially integrate into your app. Whatever service you integrate with, you’ll need to keep the deployment-specific parts separate so that when your app is tested by the instructor, they’ll be able to test its functionality.

Groups

Each group will be graded on the same “scale” regardless of their size. Thus the substance of the final project for a group of 2 will be graded the same as a group of 4. For this reason, I highly recommend that you merge smaller groups into one larger group.

If you want to complete the final project by yourself, you can. I will still hold you to the same standards as the groups of four. I do not recommend doing this, but if you would prefer it, I won’t stop you. If you do this as a “web programming novice,” I will grade you roughly as hard as I would grade myself.

Specializations

If you’re just getting your start in web development, building out a fully functioning webapp with a good test suite, a good security analysis, and a good set of beyond-CRUD features is more than enough for this assignment. However, if you aren’t a novice, OR you are particularly interested in learning a specific web-related technology, you can add a specialization to your group’s project.

When do I have to add a specialization? If you consider yourself a web programming novice, you do not need to add a specialization. However, you must add yourself to the group list in README.md as a “web programming novice.” Everyone else must add one specialization next to their name in README.md.

Do we need to have one specialization for every non-novice in our group? Yes.

Do specializations need to be completed only by the student that adds them? No, everyone can help out to add the specialization’s functionality.

What are some good specialization examples?

  • Performance: write load testers for your application, keep track of your application’s speed, and submit pull requests to the main code which (a) explain a performance bottleneck (b) fix the bottleneck (c) show the before & after performance difference.
  • Cloud: convert your entire app to be cloud-native: for instance if you’re currently using Node, Mongo, and Passport.js’s local strategy, swap it to Google App Engine or Cloud Functions, Cloud Firestore, and Firebase Authentication. Bonus points if you implement your app with both cloud and non-cloud options, and show the performance difference. Important: take a look at “final deliverable” below: if you build your app cloud-native, be sure to document how you set things up in excruciating detail.
  • Frontend: build your application using a front end framework like React, Vue.js, or Angular. For this to be a full specialization, you’ll need to describe and flesh out at least a few of the special features of such a framework, or justify its usage with a suitably complex application (see: You Might Not Need React).
  • DevOps: build out an entire deployment strategy for your application: spin up the VMs, start the Kubernetes cluster, pull the pre-built containers from your private container repository, install the secrets and secret keys from a secret store, and showcase a rolling code upgrade or failover.
  • Mobile: optimize your webapp to work on mobile. A native mobile app is beyond the scope of this class, but you can still build a progressive web application, configure your app to work with Google AMP, and make your app reactive (i.e. it looks decent on both desktop and mobile).
  • Analytics/SEO: deploy your site to the real Internet, optimize it for SEO, launch a few ads (~$10 worth or so, over at least 48 hours: if you’ve got everything ready to go and you don’t have a “first $X free” coupon, I’ll pay for your ads). Perform an AB test on the users that click through the ads. Report what information you know about your audience and how know it/how who sold you that information got it.
  • Security: introduce some non-trivial risky feature to your application. This could be something like allowing users to run their own JavaScript within your domain. How does this change your security analysis? How will you prevent it from causing danger for your app? Additionally, fully lock down the permissions in both your dev environments and your production environments: custom IAM roles within GCP, keep all secrets in secret stores, require u2f authentication for user login to your site, configure and lock down LetsEncrypt to protect your TLS certs. If you choose this specialization I will pen-test your app as part of grading, but will NOT give any security feedback after checkpoint 1.

Grading

For checkpoint 1, we will grade your turning manually. Points will be given for:

  • 15% for final functionality description. Points will be given for clarity and sufficiency.
  • 15% for checkpoint 2 deliverable description. 10% will be for clarity and 5% will be for realism. Feel free to send a review request if you want feedback before the deadline.
  • 0% for checkpoint 4 deliverable description - it’s probably a good idea to think this out now, but the deliverable description for checkpoint 4 will be graded at checkpoint 2.
  • 15% for boilerplate code (simply its existence)
  • 20% for English-language test descriptions, in the right place and runnable via npm test. This will be hand-graded.
  • 35% for the security evaluation.

Grading Oracle

Because so much of the grading here is “what does the instructor think,” each group can send 2 review requests, TOTAL, any time before Midnight, Friday, February 21st. Within 24 hours (best effort) I will review what is in the PR and only what is in the PR, and give you a spot opinion of what I would/would not count off for if I were grading it that moment. Thus if you finish the whole thing and send a PR review for the whole thing, I will grade the whole thing, and give you the option of fixing whatever you got counted off for.

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.

Extra credit: hack for hire

After checkpoint 2, all repositories will be made writeable to all students. Extra credit will be given in the following amounts (which will be added to your raw final exam grade):

  • 1%: filing a non-trivial well-written issue on another group’s repository
  • 2%: fixing a non-trivial well-written issue on another group’s repository
  • 2%: filing a non-trivial well-written security issue on another group’s repository
  • 4%: fixing a non-trivial well-written security issue on another group’s repository

While you don’t get credit for it, this means that filing issues against your own repository is a good idea. This will increase the quality of your final project, and give others the opportunity to gain extra credit in the class.

If your group would like to opt out of the extra credit opportunity, let me know and I will keep your repository private. If you do this you will not be eligible for extra credit.

Mention @kaytwo on GitHub when you submit an issue or PR so that I can evaluate and give the extra credit. “non-trivial and well written” are up to my discretion, but I will give you one retry if the first attempt isn’t sufficient.

There is a 40% cap on extra credit, earned by any combination of the different types. Your final exam grade will not be capped at 100%. Your raw grade on the final exam will be the amount used for overwriting any missed participation or quizzes (not raw + EC).

Branch protections

When I make the repositories class-writeable, I will protect the master branch to only be writeable by your group. I will not add any other protections, but I will be basing part of your final grade on your software engineering hygiene. If you’d like to have admin rights on your repository, contact me and I’ll give them to you, HOWEVER, you’re taking your fate into your own hands. If someone force-pushes the wrong code 2 days before the deadline, that’s your problem. If you turn off commit protection on master and another student wipes out your repo, that’s your problem (they’d be in even more trouble than you though).

If you’d rather not have full admin on your repository, I can turn on/add any specific repository settings/functionalities (you can explore them through any repositories that you own) that you’d like.

Final deliverable

The final deliverable will be graded in two phases. One will be “you deployed” - you can run your app wherever/however you want and show me the intended functionality, either remote or in person. The other will be “I deployed” - I will take the role of “random person who saw your github repo linked on Hacker News” and try to spin up the app myself, within my own environment (note that if you’re using cloud resources, that includes linking the app to my own cloud resources), based on the installation instructions in your README.md. This means that good documentation is necessary, and periodically testing your app in a clean environment is necessary. Half of your final grade will come from the “I deployed” portion. Pro-tip: ask other groups to “clean demo” your app, and do the same for them.

Deployment

The fully functional “you deployed” app should be running someplace besides your own machine with green lock HTTPS. If you own a domain name of your own, feel free to use that for your app. If you’d like me to point a hostname at an IP address for you, I can do that.

I would highly recommend you deploy your site to GCP using the free $50 that I posted on Piazza. The easiest most direct way to do this is with a Compute Engine VM: this will be roughly equivalent to a linux box under your desk, and you can set it up with an external static IP that you resolve via a DNS hostname.

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.