Web Databases Semester Project

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 not be emailed to the user.

As part of your project, you will also write a document describing your site, including a technical description of how it is implemented and the cool features that you are responsible for. Ideally, you would be able to show the document to a potential employer or graduate school to convince them of your knowledge of databases and web application programming.

My philosophy here is that a portfolio of projects and accomplishments is far more informative and convincing than a letter grade. The grade can bolster that information, essentially adding my judgment that this project was worth an A (or whatever) in this course. But your real goal here is to create something that you can be proud of and maybe add to your portfolio of computer science projects.

Description

The project will proceed in several phases. See the course schedule for exact due-dates.

  1. An idea, usually due around mid-semester after we've learned many of the core concepts. This will be done solo. It will just be a paragraph or so, submitted as a text file, suitable to be collected via "cat."
  2. A proposal, with a partner. The proposal will have a project/team name, a more detailed description of cool features, and some description of the data to be collected. About a page or two. Submitted as a Google Doc shared with your partner and me and as a PDF, dropped from your team account.
  3. A design and plan, with your partner. The design will include a fleshed-out idea, a description of your data with sample data. You will also have a plan for what features will be implemented in the draft, alpha and beta versions. About a page, with bullet lists of features for the three versions. Submitted as a Google Doc shared with your partner and me.
  4. A draft version, due several weeks before the end of classes, to show significant progess and allow you to get feedback. You will have a link to it on your project team page, and you will drop a copy of your tarfile.
  5. An alpha version, due on the last day of classes. Same submission requirements as the draft version. During reading period, we'll hold a demo day, where you and your partner will demo your project to visitors, to get suggestions and compliments from your fellow students.
  6. A beta version, due on the next to last day of exams. Same submission requirements as the draft version. This allows you almost the maximum time for enhancement and polishing.
  7. A paper, also due on the next to last day of exams. Don't let the paper slip your mind while you're working on your beta version! Being able to explain your work is as important as being able to do it. This will be submitted as a Google Doc shared with your partner and me.

Grading

As always, I expect that you will write code that works, is modular, has good style and is well-documented. In addition, I'll grade your project partly on how creative and impressive it is. I do want you to challenge yourselves and create something that you will be proud of, and those who truly excel should be rewarded. I'm looking for undertaking a challenge. Your project proposal should also make this clear. Feel free to consult with me on this.

I'm always very impressed by these projects. I'm looking forward to them!