Overview

The project is intended to give you a chance to use all of the skills from the course, and to integrate them into a final result.

The topic of your project is up to you. Experience tells me that good projects are usually the result of people who are actually trying to solve a real problem, not just do something complicated enough to get some marks.

How “big” should the project be? Homework 9/10 will end up being worth about 3% of the final course grade, and the project is worth 45%. So you should target something about 15 times the size of that homework. As part of the the proposal, I'll give some feedback on what I think about the size of the project you have proposed.

Notes

You are expected to take the topics discussed in lectures (especially those in the first half of the semester) into account when implementing your project.
You can choose either Rails or Django to implement the project. If you would like to use a different technology, email and tell me why.
If you would like to work in groups of 2–3 people, that is okay. Email zju.webdev@gmail.com with a list of group members (and student numbers).
Your code must be in your Git repository. You must commit as you work, not only when you submit. If you're working in a group, each group member must commit their own work.
Marks of group members may be adjusted to reflect the level of individual contributions.

Proposal

Due May 27, 23:59.

Your proposal should be approximately a half to one page in length. It should describe your plans for the project, what will be implemented, and the framework you're using for the implementation.

I will provide some feedback as soon as possible, especially about the size of your project.

Submitting

Email your proposal to zju.webdev@gmail.com with the subject “Proposal”. Text in the body of the email is fine: I don't care about formatting.

Checkpoint Implementation

Due June 7, 23:59.

To make sure you're on the right track to finish your project on time, you will be required to submit a partial implementation. By this time, enough of your project should be working that you could do a small demonstration of your project and give us an idea of what will be done. (You don't have to actually do a demo, but you should have enough that you would be able to.) Obviously some things will be incomplete/missing/broken: that's okay.

Basically, we just want to see that you're making progress on the project.

Submitting

Email your student number (or repository name if you're in a group) and the path of your project code to zju.webdev@gmail.com with the subject “Checkpoint Implementation”.

If you want to say a few words about what is and isn't working in the code, you can but don't have to. If you would like to create a branch in your repository for the code, you can: just tell us which branch to look at.

Implementation

Due ~~June 21~~June 24, 23:59.

The final product should be a reasonably polished, usable web system. It is expected that the system will do a good job of solving the problem it is designed to tackle.

All aspects of the implementation will be marked, including:

Quality of the idea: does it solve a real problem that somebody might have? Does it do it well?
Amount implemented: quantity and quality of features.
Overall polish: Is it easy to use? Does it look nice?
Technical style: Well-structured code, good MVC separation, etc.
Security: any security holes will lower your mark.

We must be able to run your project. The code that is in your repository should be testable with a SQLite database after doing this (for Rails and Django, respectively):

rake db:create
rake db:migrate
rake db:seed
rails server

python manage.py syncdb
python manage.py migrate # if you're using South
python manage.py runserver

If there is an extra step, say so when you submit. If we can't test it, your mark will be significantly lower.

It would be helpful to have at least a little test data in your initial database (initial_data.json in Django, seeds in Rails).

Submitting

Email zju.webdev@gmail.com with the subject “Project Implementation”.

The URL of your Git repository (just to make sure we look at the right one).
The path within your repository to your code.
The branch we should be looking at in your repository (if you have created branches other than master).
Any extra instructions on how to get the code running for testing (if any).
Any usernames/passwords needed to log in and explore the system (if there are any defined in your initial data).