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.

Grading¶

The following is repeated from the project description:

You and your teammates will create an web application. It should have some cool features that demonstrate your mastery of the concepts and skills we've learned in this course:

• Displaying, searching, inserting, updating, and deleting data.
• Sessions — extended interactions with a user, providing context and state
• Logins and authentication, probably with different permissions for administrators versus ordinary users, and users from each other.
• File upload, whether pictures, MS Word files, or whatever.
• Ajax: to allow seamless and asynchronous updates.

Your project need not have all of these, but most projects will have most of these. I'm flexible, so if you have an idea, please talk to me about it.

An excellent project will typically either do an exceptionally good job on these core concepts and skills or go beyond them, adding extra features to their web application. There's no menu of such features, but recent projects have done things such as emailing users, setting up cron jobs for automatic tasks, authenticating with Facebook or OpenID logins, using JavaScript in the browser to reduce load on the server and improve the user experience, and having an exceptional user interface, whether through their own code or UI plugins. Eye candy is always nice.

Your code should work: no error traces to the browser, no broken links, no errors in the JavaScript console, and so forth.

As is true of all the homework assignments in the course, your code should also be clear and readable, well documented, and modular. Furthermore, it should not be vulerable to any of the web vulnerabilities we will discuss in this course. For example, I shouldn't be able to hack into your site by changing a cookie value or modifying the value of a hidden input in a form. Finally, if your project has file uploads, there are extra security considerations there (which is one reason I would like you to find a use for file uploads in your project).

This is not primarily a security course, but neither do I want you building insecure applications. Security is an important part of these projects. Our goal is to learn the basic skills so that we are prepared to learn more. Avoiding security holes is important, so in general I will deduct a full letter grade for a project that has one or more holes. So, I expect:

• No web vulnerabilities, such as XSS attacks
• No unauthorized operations. For example, only the user should be able to edit their profile and their posts and such.
• Password protection for file upload and insertion of data.
• The password protection should be something like bcrypt. The passwords should not be stored in plaintext, and they may not be emailed to the user.

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.