Project for UCLA Computer Science 35L

Features

Your app should:

Display dynamic data to the user. That is, some part of the webpage changes based on data received from the server.
Upload data from the client to the back-end, which saves the data to the server in a database. The server should guarantee ACID properties when storing the data.
Meaningfully search through server-side data.
- Examples of meaningful search include searching for certain file names, data content, upload dates, etc.
- These files could be ones that the user has uploaded, or could be ones that you have placed in the server directory yourself. For example, if you were making an informational app for prospective dog owners you might have a single file containing information about various dog breeds.
- The front-end must let the user enter a query conveniently.
Address security issues. For example, at least part of your application should require the user to authenticate.
Execute a significant amount of code, written by your team, on both client and server. For example, do not rely on Firebase to do all your server-side work.

In addition to the above functionality requirements, your web app should contain at least three more distinct features. For example, if you were implementing Instagram for the first time, the features might be:

Like and comment on photos
Visit user profiles that show name, bio, and the user’s uploaded photos
Follow other users.

If you were implementing the MyUCLA Class Planner, the features might be:

Add/remove classes from your current plan.
Enroll in classes.
List additional information about classes such as days, time, location, instructor, and units.

Other design ideas include fitness, social media, cooking, ride-sharing, messaging, music, banking, dating, productivity, vaccination tracking with privacy, etc. Don’t think about it too hard; you are being evaluated on the quality of your implementation, not the app idea itself! It’s totally okay to choose an app idea that already exists, though your implementation should of course be your own.

Though we do not expect your apps to be completely polished and visually aesthetic, we do expect them to be organized and easy to use.

Technology

Node.js and React.

You may use a different technology stack (i.e. build an iOS/Android app, use a different back-end framework such as Python/Django, etc.), provided you receive permission from an instructor by the end of Week 6. Your project is valid as long as it meets the requirements outlined above. Please note that choosing a different technology stack may limit the amount of help that instructors can provide you.

You must use Git and GitHub (or similar Git-based repository) to track the progress of your work. The project can receive a full grade only if the submission includes Git history no shorter than five commits from each group member. Commit history may be checked to ensure participation. “Participation” does not mean commits or lines of code, but rather the quality of work.

As is usual in this class, your work should be your own. Of course by using Node.js etc. you will be building on the work of others, and you will be working in a group project, but each of your own commits should be your own work. You should use a private repository (not visible to outsiders) to help ensure this; this can be done on GitHub. Eventually you will submit your repository to us so that we can evaluate your work.

Since you will submit your repository, it should also contain a README file (plaintext or Markdown) describing in detail how someone who cloned it can run your app. This should, of course, include any shell commands needed for setup.

Finally, each student must also submit a personal three-page final report that includes:

Your app’s purpose
A brief overview of your app’s architecture and the technologies you used
A description of the features supported by your app
A description of your individual contribution to the project
Any notable difficulties or challenges you and/or the team faced
Any improvements or additional features you’d make if you had more time. Improvements can include things that you would do differently if you had the opportunity to build this project again.

See the USENIX templates in Resources for written reports and oral presentations for good report formats.

Grading

Project grading will consist of the following components. All percentages below are percentages of the total project grade.

Group project components (one per group):

3% – 1- to 2-page project proposals.
3% – 1- to 2-page initial schedule and project plan. This should specify at least one (preferably two) intermediate milestones for the project. The point of the milestones is to have running code early, that implements some project features and can be demonstrated. For an example, see Lucy Deckard’s “Developing timelines and milestone charts for your proposal” although we don’t expect anything that fancy. Plus, we don’t expect the plan to be perfect! It’s just a plan, and will no doubt be adjusted as the project evolves.
4% – App can display dynamic data to the user.
4% – App can upload data from the client to the back-end.
4% – User can meaningfully search through server data.
21% – Three more distinct features. Points will be given according to how creative and useful the features are.
8% – Meaningful understanding of Git is exemplified through version control.
5% – Detailed README file that accurately and completely describes how to run the app locally.
5% – Project is generally visually pleasing and easy to navigate.
14% – Project presentations and demos (see Resources for advice about presentations).

Status reports (one set of reports per student):

10% – Five weekly status reports. Each report should summarize what you did that week. Reports should be about half a page, and no more than one page.
- Reports will start the week after the initial plan is due.
- Each report is due on Friday.
- The last report is due the week before the final report is due.
- For more, see Work involved.

Final report (one per student):

3% – Project description and overview is an accurate account of the project submitted.
10% – Report details individual contribution in a meaningful way, which can be verified by git history, and describes how the contribution interacts with the contributions of the rest of the group.
3% – Thoughtful reflections of difficulties faced, along with descriptions of how you overcame them.
3% – Discussion of improvements/things you would have done differently and additional features you would have liked to implement.

Submission

To let us know about your groups, please fill out this Google Form. Only one group member must submit. It's due at the same time as the proposal; for more, see Work involved.

Groups should have 3–5 members. We may allow exceptions on a case-by-case basis if you absolutely cannot find another group. Solo groups are discouraged since a large part of software construction is collaborative work.
We will only consider exceptions a week before the proposal is due. Do not email requesting an exception until then.
It's fine if members are in different sections, however:
- Choose the discussion in which most members are enrolled.
- If there is no majority, feel free to choose one of the discussions that a member is enrolled.
- However, make sure that every member can make it to the discussion you choose. (At least, make sure all can make it to the last discussion: Friday, tenth week.) If this is not possible, you must choose a different group.

We'll be using Gradescope to submit your project deliverables. For the project proposal and initial schedule/plan, please use the groups feature in Gradescope. Only one group member has to submit; this member adds the rest of the group. Make sure that your group is the same that was submitted to the Google Form.

Present your project in the last discussion (Friday, tenth week). You may present however you'd like (slides, demo, etc.), but you're limited to five minutes per group. This is a strict requirement; you will be cut off. There are no exact specifics to cover in the presentation, but try to cover some of the following:

the problem you're trying to solve,
your general solution to the problem,
a quick description of your tech stack,
a couple screenshots (or if time allots, a quick demo) of your solution, and
potential future work.

All group members must present. If you plan on presenting a slideshow, please do submit your slides to Gradescope before your presentation (also using the groups feature).

We'll be using Gradescope to submit a compressed tarball of your Git repository. This should contain all your group’s work, including any documentation, etc. The repository should not include generated files, only source code; the README file should explain how to generate any files (e.g., node modules) buildable from the source. Make sure to also include an environment file (typically named .env) if necessary. While this file should not be committed, it should be part of your tarball (so we can deploy your project locally).

In addition, each group member must submit weekly status reports and a final report to Gradescope individually. Ensure that your report is in PDF format.

Glossary

Front-end/Client:: Two terms that are often interchangeably used to refer to the user-facing part of your application, or everything that the user actual sees. In the context of web apps, this means the actual look of your website and all of its contents (buttons, tables, text, etc.).
Back-end/Server:: Two terms that are often interchangeably used to refer to the “behind-the-scenes” part of your application that handles business logic such as saving user data or generating the appropriate data to send back to the client. In the real world, servers typically run on their own dedicated hardware (really just another computer) and the client and server communicate via HTTP.
Dynamic:: Changing. In the context of web apps, dynamic content refers to anything (text, images, tables, etc.) that can change. That is, if you visit the website at different times or perform certain actions, the contents of the website may change. Dynamic is the opposite of static.
JavaScript:: The so-called “language of the Internet”. It is the language that virtually all websites use to perform things dynamically. Technically, it’s an interpreted language whose syntax borrows quite a few elements from C.
Node.js:: Node.js is a JavaScript run-time environment. In the same way that Bash allows you to execute shell commands, node.js is simply a program that allows you to execute JavaScript statements. node.js contains additional syntax and features that browsers do not have.
React:: React is a popular JavaScript framework for building user interfaces, and is maintained by Facebook alongside a group of individual contributors and developers. React provides you with a declarative way of creating user interface components (such as custom buttons, menus, etc.) and is written using JSX, which stands for JavaScript XML. JSX is an extension of JavaScript which incorporates HTML, and can be transpiled (converted) to regular JavaScript.