Alpha Version

In the software industry, the "alpha" version is the one that is tested internally, to avoid embarrassment to the company. The "beta" version is released to "friends" of the company and to clients who want the very latest version, even at the price of unfixed bugs. (The beta version may have new features that the client has requested and such.) After beta version, the finished product is shipped to stores and offered to sale to the general public.

For the purposes of this project, the alpha version is the first release of your own project, as described in your proposal. The emphasis should be on functionality: trying to get the basic feature working, even if some of the HTML pages and forms need some polishing. Don't spend a lot of effort on error handling.

How to Submit it

Like our earlier phases, you'll write this as a Google Doc, shared with your partner and me. This will allow the two of you to easily co-author it, and allow me to comment on it.

The title of the document is very important, otherwise I will mis-place it and lose time finding it. The title of the document will be CS304-SEM-YYYY-alpha-TEAM where the SEM is the semester (Fall/Spring), the the YYYY is year, and the TEAM is name of your project or team account or your names.

Since Google often makes these documents hard to find (weird for a search company...), please submit the URL via this

URL submission Google Form

What to turn in

You'll turn in exactly the same kind of document that you did for the draft version:

  • The URLs of the web pages I need to look at
  • The sample usernames, items, and other inputs, so I can use the forms.
  • Directions on how to use your pages. That means telling me where to click, what data to enter, what usernames/passwords I need, and so forth. It's amazing how dumb I can be with someone's web app, so be really clear here.
  • Then copy/paste the code into the Google doc, so that I and your reviewers can read it and comment.

Expectations for Alpha version:

  • Most of the core features of the site are in place. For example, an e-bay knockoff would allow sellers to list an item for sale and allow buyers bid on items.
  • Less essential features might still be TBD. For example uploading pictures or some fancy Ajax feature.

Presentations

The presentation is a simple demo: show what works but you don't have to show everything – focus on what's interesting. Describe what you'll do next. Solicit suggestions.

Grading

Your alpha version should have:

  1. All of the UI figured out (pages, menus, etc)
  2. Most core functions working
  3. No vulnerabilities (SQL injection, XSS, cookies)
  4. Flask code must be thread-safe
  5. Good documentation and modularity

Also, this is very important: separate your code for each phase: have a folder for your alpha version that is separate from both draft and beta. See below in Software Versions.

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. use url_for() for all urls
  6. avoid duplicated code
  7. avoid duplicated HTML/CSS (use inheritance and shared CSS files)
  8. avoid inefficiencies, such as unnecessary database queries, or overly broad queries that are then filtered in Python

Thread Safety Checklist

This list is copied from our earlier lecture on threads

Now that we've learn about threads and the notion of code being thread safe, we can require that our Flask apps be thread-safe. What does that mean?

  1. Global variables are either read-only or have access properly controlled, using locks if necessary
  2. Each request gets its own database connection, so that different requests use different connections. That means that connection-specific functions like last_insert_id() will work correctly.
  3. Any request that does multiple SQL operations needs to consider whether those operations produce "race conditions". For example, the common pattern of (a) checking if something is in a table and (b) inserting it if it is not, is not thread-safe: two threads executing that sequence at once can cause problems.

Remember, not every global variable and every transaction needs a lock. But you should analyze your code and consider it. Leave a comment with your analysis and decision.

Software Version

You should also set aside a working copy of your code for my purposes in grading and also for your own benefit. Make sure the alpha version is properly quarantined in a folder of its own, so that when I un-tar the file you dropped, I can run that code without interfering with your development version or needing external resources. Using GIT should make this much easier.

In addition, if you're careful to always use relative URLs and pathnames such for links, this version of the code can be completely independent of other versions of the code, in particular your current version.

Note that the different versions will be connected because of the shared database, but that's it. It might be wise to dump a copy of the mysql database as of your P3_alpha version, in case something goes wrong. You can do that by

mysqldump db_name > P3_alpha_dump.sql

There is more explanation about this in the P2 document.

Deadline

To avoid last-minute modifications of your site, please create that version directory before the presentation.

What to present

You will present this version in class on the last day. Be prepared to not only show your site, but also to describe a little of the technical aspects:

  • The implementation: files, tables, scripts and forms. You might not have time for this at all.
  • What was hard, whether expected or unexpected.
  • What you learned (by this, I don't mean flattering me about how much you learned from the course, but what you learned on your own in doing your project).

You should aim for about 5 minutes of presentation. Yes, that's very short, but otherwise, we'll be here for many hours. A one-minute overview of your idea and goal, some hand-waving about the data you collected and the tables and such, then a brief demo. Ask for questions and suggestions, and you're done.