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:
- All of the UI figured out (pages, menus, etc)
- Most core functions working
- No vulnerabilities (XSS, cookies)
- 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.
- HTML and CSS valid
- pages pass WAVE
- functions well documented
- lines not too long. Format long statements over multiple lines
- avoid duplicated code
- avoid duplicated HTML/CSS (use partials and shared CSS files)
- 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.