Beta Version

The beta version is the final version of your course project. At this point, the site should be pretty well polished, with directions on the nice-looking web pages and forms, good feedback, and good error handling.

In many cases, the beta is slightly polished and improved from alpha, without new features and such. That's fine. I'm looking for these to be good not huge: to demonstrate skills, not to show them five times over.

What to turn in

Since this is the best version of your project, I think it's worthwhile to create a video demonstration of it (Project phase P6). That video can be shared with friends, family and potential employers. It can also be helpful to me in my grading, to see that the feature worked at least for you, if not for me. It's also something I can share with future CS 304 students. Therefore, I would like each team to create such a video and share it with me.

As with the alpha version, I will need some help in grading these, since everyone is doing something slightly or radically different. Therefore, your README.md file should have the following

  • an informative title
  • a brief overview of the project
  • the authors/creators/programmers
  • the status of the project
  • directions for use, if the app is not self-explanatory
  • It's helpful to note what things are new, so that I don't have to review and re-grade things I've seen before.

I also need a link to the demonstration video. You can put that in the README if you want, or you can email it to me. Make sure that I can actually view the video (sometimes, people forget to share it).

Checklist

For top marks, your app shouldn't be deficient in any of these. The occasional mistake is okay (no one is perfect) but minimize them.

  1. HTML and CSS valid
  2. pages pass WAVE
  3. functions well documented
  4. lines not too long. Format long statements over multiple lines
  5. avoid duplicated code
  6. avoid duplicated HTML/CSS (use partials and shared CSS files)
  7. avoid inefficiencies, such as unnecessary database queries

How to turn it in

Like our earlier phases, upload the code to Gradescope so I can comment on it. Only one submission per group, but remember to include all your group members on the submission.

How You Will Be Graded

The following is repeated from the project description:

You and your teammates will create an web application. It should have some cool features that demonstrate your mastery of the concepts and skills we've learned in this course:

  • Displaying, searching, inserting, updating, and deleting data.
  • Sessions — extended interactions with a user, providing context and state
  • Logins and authentication, probably with different permissions for administrators versus ordinary users, and users from each other.
  • File upload, whether pictures, MS Word files, or whatever.
  • Ajax: to allow seamless and asynchronous updates.

Your project need not have all of these, but most projects will have most of these. I'm flexible, so if you have an idea, please talk to me about it.

An excellent project will typically either do an exceptionally good job on these core concepts and skills or go beyond them, adding extra features to their web application. There's no menu of such features, but recent projects have done things such as emailing users, setting up cron jobs for automatic tasks, authenticating with Facebook or OpenID logins, using JavaScript in the browser to reduce load on the server and improve the user experience, and having an exceptional user interface, whether through their own code or UI plugins. Eye candy is always nice.

Your code should work: no error traces to the browser, no broken links, no errors in the JavaScript console, and so forth.

As is true of all the homework assignments in the course, your code should also be clear and readable, well documented, and modular. Furthermore, it should not be vulerable to any of the web vulnerabilities we will discuss in this course. For example, I shouldn't be able to hack into your site by changing a cookie value or modifying the value of a hidden input in a form. Finally, if your project has file uploads, there are extra security considerations there (which is one reason I would like you to find a use for file uploads in your project).

This is not primarily a security course, but neither do I want you building insecure applications. Our goal is to learn the basic skills so that we are prepared to learn more. Avoiding security holes is important, so in general I will deduct a full letter grade for a project that has one or more holes. So, I expect:

  • No web vulnerabilities
  • Password protection for file upload and insertion of data.
  • The password protection need not be state-of-the-art, but it should avoid obvious flaws. The passwords should not be stored in plaintext, and they may not be emailed to the user.

Final Words

Students typically do very well on the project; I'm not looking to grade harshly. I know you work very hard and the results are usually amazing.

However, I do take security vulnerabilities seriously, so you should be careful with that. It is easy to focus exclusively on functionality and aesthetics, and while that's understandable, avoiding vulnerabilities is necessary. Fortunately, that's typically not an issue with Express and MongoDB.

Please contact me if you have any questions or concerns.