For this phase, you'll complete your web application. You will produce a
functioning website based on your API, providing people convenient and pleasant-to-use
access to a variety of ways to search and view your chosen database.
Components of the final product
Your webapp should be left running at your assigned port on thacker. The / route
(i.e. http://thacker.mathcs.carleton.edu:YOURPORT/) should return your site's
home page.
Your cs257 repository, tagged with "webapp4", should contain the following.
- Your cs257/webapp/api.py flask application. All of your API calls will continue to
be processed through flask routes as in phase 3. Additionally, api.py will
have new routes to support the user interface. See the
@app.route('/') route in my books web app
for an elementary example. If you used your /-route for something else already,
rethink your use of that route (and let me know if you need help, of course).
- Any template files in cs257/webapp/templates/ and static files
in cs257/webapp/static/ required to support your app.
- Your data, either in csv form (one file per database table) or as a .sql
dump file produced via pg_dump.
- Leave the cs257/webapp/contributors.txt and cs257/webapp/phase2.txt files
intact.
Grading rubric
Phase 4 grading will be graded as follows:
25 points = 5 (runs with nontrivial actions without crashing)
+ 5 (appropriate breadth of features)
+ 5 (usability)
+ 7 (code organization and style)
+ 2 (extra awesomeness)
Code review
On Wednesday, May 11, we'll have code reviews during class. You can use the feedback you
receive during this session to do some final polishing of your project.
You should prepare for the code review session like so:
- Important: Make sure everyone at your table knows what
thacker port to look at so they'll be looking the right project. Also, share
your bitbucket repository with everybody at your table.
- Each team should bring a laptop containing their own source code so they can project it
on screen. (Alternatively, if your table agrees, you can have a single person have all
the source code on their laptop, and then share the laptop from team to team during the
code review session. This method has the benefit of avoiding the time waste of switching
laptops for projection on your table's screen.)
- Read each group's code carefully. Once you have read the other groups'
code, apply the same type of reading to your own group's code.
For each group you are working with at the code review, write down:
- A short list (2 or 3 items) of the things you like best about their code.
- A short list of questions, if any, you have about the code. These questions can
be of various types. For example, "how does that work?" is different from "why did you decide to
do X instead of Y?"
- A short list (1 to 3 items) of the most important suggestions you can offer for
the improvement of their code.
For each other team at your table, bring two copies of your comments to class.
You'll give one copy to the team in question, and one copy to me.
Make sure to write your comments in a way you would be willing to hand over to the other
group. In particular, make sure your notes are constructive and polite.
Thorough testing isn't the point of this exercise, but you'll want to try running
the programs a little bit.
During your code review session:
- Each team takes a turn being in the spotlight. Plan for about 10 minutes per team (with
the likelihood that some discussions will spill over to 15).
- At the start of each team's turn, one of that team's members should show their code
on screen and be prepared to scroll to requested portions of the code. (e.g. somebody might
ask "can we look for a minute at the main() function?").
- When it's your team's turn in the spotlight, your job is to listen and answer questions.
Resist the urge to give explanations for why you did X or Y unless explanations are requested.
You'll get a chance to revise and explain in your final product.
- When you are providing feedback to another team, your goal is to provide useful feedback.
Feedback tends to be more useful if it is presented in a tone that doesn't make the recipient defensive,
so be nice. (This is actually pretty easy. It's a simple, day-to-day application of the golden
rule, and all of you know how to be nice people.)
- Sometimes, you might not have a lot of ideas for improvement of the code (maybe
the other team's code is better than yours...that happens often). In such cases, just giving
a clear idea of what you found easy to understand and what you found confusing would be helpful.
- When the session is over, the team giving feedback should hand their written notes to
the team being reviewed.
Other notes
You should, of course, use your original mockups and user stories / feature lists
as a rough guide, but don't feel overly constrained by them. It's natural for your understanding of a project to evolve as
you work on it, so you should feel free to diverge from your original conception if you
have better ideas now.
Read the first five sections of Don't Make Me Think! right away--it will help you think about
good UI design.
I have set the due date late enough that you have lots of time for this phase, but don't wait
to get started on it. Spend the time to make the pieces fit together and think about how to make
your app a good experience for you users.
We'll practice the bits and pieces over the next three class days (HTML, CSS, flask/jinja2 templates,
Javascript, and AJAX).
Have fun!