Project for UCLA Computer Science 35L

[IMPORTANT!!!] Please refer to Piazza@684 for updated instructions if conflict with below.

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 persists (saves) the data to the server’s file system. This data can be as simple as strings or numbers that you save to a text file, or files that the user uploads such as images.
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% – Weekly status reports. Each report should summarize what you did that week, and (except for the last report) should briefly say what you expect to do next week. Reports should be about half a page, and no more than one page.

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

You will present and demo your project during the course.

One team member must submit a compressed tarball of your GitHub repository to Bruin Learn. This should contain all your group’s work, including any documentation, presentations, 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 (adding their names to your .gitignore file can help you avoid submitting them by mistake). You should be able to obtain such a tarball directly from GitHub. Name the file UID-project.tar.gz, where UID is your student ID.

In addition, each group member must submit a final report to Bruin Learn individually. Ensure that your report is in PDF format and is named UID-report.pdf.

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.