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 features working, even if some of the HTML pages and forms need some polishing. Don't spend a lot of effort on error handling.

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, re-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 (XSS, cookies)
  4. 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. avoid duplicated code
  6. avoid duplicated HTML/CSS (use partials and shared CSS files)
  7. avoid inefficiencies, such as unnecessary database queries

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 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.

How to Submit it

New Spring 2024

It's easy for you to submit a collection of code files to Gradescope from Github. It's easy for me to comment on your code using Gradescope. People don't always remember to share their Google Doc with me, and Google is fond of hiding shared documents from me. Those are compelling arguments to use Github + Gradescope exclusively for submitting project work.

But, how will I know the status of your project, how to run things, what's working and what's not, and so forth? I propose that we use the README.md file. That's an especially good choice because that's the purpose of a README.md file. Anyone else that you choose to share your project with (such as potential employers) will expect an informative and well-written README.md file. Furthermore, like Google Docs, the README.md file can be written collaboratively by your team.

I'll write more later, but for now, the README.md file should have:

  • an informative title
  • a brief overview of the project
  • the authors/creators/programmers
  • the status of the project
  • directions for use

What to turn in

Go to Gradescope, find the P4 Alpha Version Gradescope item, submit all your files from Github. Make sure all teammates are listed in the group. This should be quite easy; just a few clicks.

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, data, collections, 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.