Final Project Proposal: Submit to TigerFile | Final Project: Submit to TigerFile

The final project is due on Dean’s Date at 5pm. You may not use late days on any part of the final project. We will not accept any work after Dean’s Date without a Dean’s recommendation.

For inspiration, see some projects from Spring 2022 and Fall 2021!

Introduction

The goal of your final project is to develop your own Java program on a topic of your choosing. It’s an opportunity to synthesize the knowledge you’ve learned over the course of the semester. The project is specifically designed to be open-ended to allow for creative project choices. You are welcome and encouraged to go beyond the scope of the course (e.g., use external libraries, novel data structures, etc.) You may work individually or in a pair; however, we strongly recommend partner projects. The course staff will provide opportunities for feedback, debugging help, and tutorials. This project is meant to be a fun opportunity to challenge yourself and highlight the variety of neat applications of computer science!

Project Outline

Overview

In your final project you will implement one Java program, which may contain several .java files. Regardless of group size, a final project should be roughly two assignments’ worth of work in terms of time and effort. Each project should have one unique clear goal. To ensure proper scope, all projects must be approved by a preceptor and any major project changes must be approved as well.

You should try to be creative and innovative, try to create something personal that you would actually like to use. This course is all about interdisciplinarity, so try to create something that involves other academic areas (especially if your concentration isn’t Computer Science.)

The course preceptors will guide you in your efforts to plan and execute your project. Each project will have a project advisor (that doesn’t have to be the preceptor from your section). The project advisor is responsible for approving your project ideas, providing feedback, approving any major changes you might wish to introduce, and ultimately they are responsible for grading your project (more on grading later.)

Each project should implement at least three features. A feature specifies substantive functionality that your program supports. At least one of your features should be user-facing (i.e., a user can tell whether or not it’s been implemented by running your program; no code review is necessary.) You can implement as many features as you would like, but you will only get credit for three of them. See the features section for more information, including how they will be graded.

You will submit a completed project proposal report in which you will describe various aspects of your proposed project (e.g., project name, description, features, etc.) The proposal is an opportunity for you to flesh out your project idea and receive feedback on it from course staff. Your proposal will either be approved or require some updates before it can be approved. Your project advisor is responsible for approving your project. Any submitted projects that were not approved may not receive credit. Given the time-sensitive nature of approving proposals, late proposals will not be accepted for a grade.

Five days before Dean’s Date, you will submit a short status update to your project advisor on your progress thus far. This update is a great opportunity for you to also assess the state of your project and what needs to be done in the last week.

Once you complete the implementation of your project, you will have to create three more deliverables: a report, a video presentation, and a readme file. The report should fully and clearly answer questions about your project, which are detailed in a template we provide you. The video should be a YouTube video (a private unlisted video you should upload) in which you explain and demo your program. Your video can make use of slides, screenshots, and/or voiceover effects but must include a live demo of your project. The duration of the video should not exceed two minutes. The readme file will contain all the metadata of your project and should follow the exact template we provide.

The final project is due on Dean’s Date. Extensions will not be granted except with a Dean’s recommendation.

After you submit your final project COS 126 Fest will start. This will be an online event to showcase all of the amazing projects you will create, where you will be able to watch all the presentations, have discussions with your classmates, and provide feedback to some of the projects.

Timeline

Here is a timeline of important deadlines (required activities in bold).

• Thu 11/17: Class meeting (McCosh 50) - Final project introduction & spec walkthrough
• Mon 11/21: COS 126 Workshop - Ideation meet
• Tue 11/22: Project proposals due at 11:59pm *
• Mon 11/28 – Sat 12/3: Proposal review meetings
• Tue 12/6: Proposal revisions (if required) due at 8pm
• Sun 12/11: Status update due at 11:59pm
• Fri 12/16: Dean’s Date; final project due at 5pm
• Mon 12/19: COS 126 Fest starts

* We will give everyone a free grace period of five (5) days to submit the proposals, so you have until Sunday 11/27 at 8pm to submit.

Grading

The final project is worth 10% of your final course grade, but you can earn some extra credit.

Your project will be assigned a point grade out of 100 plus 10 points of extra credit. So, a score of 100 points earns the full 10% on the final course grade, a score of 110 earns the full 10% on the final course grade plus an extra 1%. Note that you can theoretically obtain a score greater than 110 points, but your final score will be capped at 110 (it’s as if we did: score = Math.min(score, 110)).

We will detail the scores of each component below, but here is an overview of the breakdown:

• Up to 15 points: Presentation grade, based on the video presentation
• Up to 105 points: Implementation grade, based on the three implemented features
• Up to 12 points: Extra credit items

Technical Requirements

General Requirements

Here is a list of general requirements your project should satisfy.

• Your program should compile! If your program contains any compilation errors it will be assigned a score of 0. If your program requires any special commands to compile you must specify them in the project report.
• Input: Your program should accept user input (e.g., command line arguments, data from standard input, input data read from a file, keypresses, mouse clicks, etc.).
• Output: Your program should produce output based on user input (e.g., print to the terminal, draw something, produce a sound, write to a file, etc.).
• .java files: Your project should include at least two .java files that are primarily developed by your project group and that are well-organized. We recommend that you use one .java file as a client (e.g., ImageClassifier.java) that calls methods implemented in your other .java files; your other .java files can implement abstract data types (ADTs) (e.g., Perceptron.java and MultiPerceptron.java) and/or libraries (e.g., Transform2D.java).
• Custom methods: Your project should include at least two custom methods that are written by you or your group. These can include static methods or instance methods. Methods should help achieve modularity in your code: Your custom methods should have a clear, describable purpose. Instead of using hard-coded values, they should accept input parameters. Lastly, these methods should not be trivial and should aid in achieving your project’s desired functionality.

Feature Requirements

Each project should implement at least three features. A feature specifies substantive functionality that your program supports. The three features should be clearly distinct, that is, each should involve a reasonable amount of unique code. The features can interact or even build on each other (e.g., one feature could be implementing an efficient data structure and another feature could be using that data structure to compute something.) More concretely, a feature can be a class, a collection of methods, a client, a single method or even just part of a method.

We will bucket each feature into one of three types, which are worth different points:

• Standard (25 points): A standard feature is any feature that only uses the content covered in COS126 (e.g., from lectures, labs, precepts, and readings).
• Sprinkle (30 points): A sprinkle feature builds on and goes a small amount beyond COS126 content. This includes things like using extra features of the libraries mentioned in class, extending/improving the data structures or algorithms taught in class, etc.
• Sparkle (35 points): A sparkle feature needs a significant amount beyond COS126 content. This includes using an external library (e.g., Stanford’s CoreNLP library, the Java Swing framework, etc.), creating or implementing your own data structures or algorithms, or incorporating computer science material beyond the scope of this course (e.g., concepts in algorithms, machine learning, natural language processing, computer vision, systems, cyber security, etc.). Note that if you use an external library it should enhance your project, not replace the essence of the project.

Note that you can get 100 points on your final project with one standard feature and two sprinkles (with a full score on the video component). When deciding on your project and the features you want to implement, keep in mind that there is a tradeoff between picking standard/sprinkle/sparkle features: a completely well implemented standard feature could be worth more points than a partially implemented sparkle feature (for example, if tests are missing or if the implementation doesn’t satisfy the order of growth that was promised.)

You will specify the category of each feature in your project proposal, but they will have to be approved by your project advisor, who might decide to recategorize some of your features.

In addition to the actual feature implementation, each feature should also contain a set of tests to check for correctness and/or efficiency, with comments explaining the expected result of each test. Your tests should be able to be run from the command-line (e.g., via command-line arguments) and should not be commented out. A test can attest the correctness of a method, a client, a class, etc. A test can check a method typically by calling that method with specific values and checking that the returned value matches the expected behavior of that method. For void methods (e.g., methods that don’t return anything), there is flexibility in how to test such methods (e.g., check how a method call changes the state of the program and that the change matches expectations.) You are free to test a client as you see fit, for example you can create a collection of inputs and intended outputs, you can add extra methods that throw exceptions if an error is found, etc. You are also allowed to add extra java files specifically for testing, if needed. Tests differ from one another typically by changing arguments or variables in a way to test different corner cases (e.g., does a method work on a 0-length array, on positive, negative, and 0 values, etc.) Even if a feature works and has no implementation bugs, if you don’t provide a set of tests points will be deducted.

Style requirements

The style requirements consist of all the expectations outlined in the course’s style guide (link) and assessed on the programming assignments. You might be deducted points if you don’t follow the style requirements that we outline. As a non-exhaustive summary, here are the main categories that fall under style:

• Formatting: All code should be well formatted using whitespace. Code should be easy to read and follow. Line lengths should be restricted to no more than 87 characters.
• Comments: Each of the following should have a comment that is meaningful, descriptive, and concise.
  • Java file (new requirement): A multi-line comment at the top of the file that describes what this file does.
  • Function (private, public, and constructors): A 1-2 line comment that describes what the function does, including the input parameters it accepts and the effect and/or return value of the function. For functions that mutate an argument, explicitly state the side effects in the function comment.
  • Instance variables: A short comment on the same line or on the preceding line that describes its purpose of what its value represents.
• Naming:
  • Variables should be well-named, except for temporary variables with small scope (e.g., loop counters).
  • Variables should be written using camelCase or CAPS_SNAKE_CASE for constants.
• Maintainability:
  • Use private helper functions to avoid repeating code.
  • Use defensive copies when functions are not designed to mutate arguments.
  • All instance variables and helper functions should be private.
  • Instance variables that should not change should be final.
  • No hard-coded values: Define constants, or use input parameters.
• Efficiency:
  • Avoid unnecessary intermediate variables and data structures.
  • Use efficient data structures when data structures are necessary.
  • Avoid recomputing identical values (i.e., in a loop).
  • Avoid deadstore variables.
• Concision: Code should be as concise and logical as possible without sacrificing on readability.
  • Variables should be declared and initialized on the same line.

Extra Credit Items

The following items will earn you extra credit:

• Having a project partner (2 points). We want to encourage people to work in groups, so if you partner up with someone you will get 2 extra points for free.
• Order of growth analysis (1 point). For each feature where you implement some algorithm or data structure, if you provide an order of growth analysis you will get an extra point. Note that this analysis should be accompanied by a justification (sketch of a proof).
• Experimental performance analysis (1 point). For each feature where you show a thorough experimental analysis (for example, using the doubling method) of its performance you will get an extra point.
• Version control (1 point). If you use any version control tools in your project (look up tools like git and websites like GitHub) you will get an extra point.
• Creating an executable .jar (1 point). If you create a .jar file to run your program you will get one extra point.
• Creating your own dataset (2 points). If you create your own dataset from scratch (either by collecting data, or creating sound/image/video samples) you will get 2 extra points.

You should mention in your project report which extra credit items you accomplished.

Video Presentation

In addition to your program, you should create a short video to present your work, the duration of which must not exceed two minutes. You should then upload the video to YouTube as an unlisted video (which means only people with the link to the video can watch it). Your video can make use of slides, screenshots, and/or voiceover effects but must include a live demo of your project. Your video should not include or discuss any code (e.g., no screen recordings of code). You may show the Intellij IDE (e.g., to run commands on the terminal) only if no .java files are open.

The target audience of your video are your classmates, since the video will be available for all the members of the course to watch. Your main goal should be not only to describe the main goal of your project, but also to convince your fellow classmates that your project is interesting, innovative and technically challenging. Feel free to edit the video as much as you want to make it visually appealing, but you are not allowed to edit the footage of your demo to make it seem like it implements more features than it actually does. Don’t falsely advertise your project, be honest in your video.

Your video will be graded (up to 15 points) by the project advisors on clarity, visual aesthetics of the slides/video and organization/flow.

COS 126 Fest

The COS 126 Fest is an online event that will start on Monday, December 19. On the first day we will send everyone a link to a website that will showcase all of the projects of all the groups in the class. This platform is going to be private to members of the course.

This platform will contain a page per project, containing the video presentation, the whole program and some meta information about the project (authors, project title, a short abstract, etc) taken from the readme file. Each project page will also contain a discussion board, where students may ask questions and post comments to the project authors.

Each student will also be able to provide feedback to some of the other groups. To do so, each student will be able to award badges of two types:

• A creativity/innovation badge should be assigned to the projects you think showed the most originality (in your opinion).
• A technical badge should be assigned to the projects you think seemed the most technically challenging (in your opinion).

Each student will have two badges of each type to award to different projects.

We will provide more details about COS 126 Fest as we get closer to the end of the semester.

Deadlines

There are three (3) activities with deadlines for the final project. Submitting on time and/or showing up to each of these activities on time is part of your final project grade. For each activity we describe three things: submission, that is, the link you should use to submit their work; deliverables, that is, files that you should produce and submit to the submission link; actionables, that is, what extra actions you should take, besides submitting the deliverables.

1. Project Proposal (due Tuesday, November 22 at 11:59pm)*

(* We will give everyone a free grace period of five (5) days to submit the proposals, so you have until Sunday 11/27 at 8pm to submit)

Submission:

Submit to TigerFile

Deliverables:

A single PDF file. It should follow this template (link). Also, for a sample project proposal of a Sudoku game see here.

Actionables:

After you submit your project proposal, your group should sign up for a single 10-min appointment slot with a preceptor to discuss your group’s proposal (we will post the sign up link on ed and update this page.) These proposal review meetings will take place at various times Monday November 28 through Saturday December 3 and attendance is mandatory for the whole project group.

The preceptor you meet with will be your designated project advisor, and you are encouraged to choose a group member’s preceptor, but not required to. You are still welcome to ask other preceptors for help during office hours. If your proposal is approved, your group and the advisor will discuss next steps for your project.

If your proposal is not approved (e.g., its scope is too small or too large, etc.), your group and the advisor will discuss changes to ensure that your proposal meets the project requirements. Most groups will be able to revise their proposals to meet the project requirements during their review meeting. However, in the case that your group is not able to revise your proposal sufficiently during the review meeting, you will need to submit proposal revisions or a new project proposal by 8pm on Tuesday, December 6 and must receive approval from the project advisor before working on the project (you will lose points for submitting unapproved projects).

Finally, your project advisor must approve any major changes to your project (e.g., changes in feature list, etc.) your group would like to make after the review meeting. Approval of modifications may be done over email but may require a virtual or in-person meeting as needed.

2. Status Update (due Sunday, December 11 at 11:59pm)

Submission:

Through a Google Form (we will post the link on ed and update this page).

Deliverables:

None.

Actionables:

Form submission.

3. Project Submission (due Friday, December 16 at 5:00pm)

Submission:

Submit to TigerFile

Deliverables:

You are required to submit exactly these files:

1. Program implementation

You should upload a project.zip file that compresses all your project files (e.g., .java files, any input/output data files, any .jar files for external libraries, etc.) Please preserve the file structure in your project folder and double check that your compile and run commands work for your .zip file. There is a 50Mb size limit per file on TigerFile; make sure your .zip file is under that limit (if it’s over the file limit, see if there are any optional data files that can be excluded; for instance, only include 2 audio samples instead of 12 in the .zip file).

You also need to upload all the .java files in your project .zip file directly to TigerFile (so they can be directly viewable in codePost), please upload them under the “Additional Files” heading.

2. Project report

You should upload a single PDF file. It should follow this template (we will post the link on ed and update this page).

3. Readme file

You should also submit a completed readme file. Your video presentation YouTube link will be included in this file. It should exactly follow this template (we will post the link on ed and update this page), note that if you don’t, there might be an issue when uploading your project to the COS 126 Fest platform.

4. Acknowledgments file

You should also submit an acknowledgments.txt file, just like in each assignment.

Actionables:

After you submit your final project will also need to complete and submit a Google Form (we will post the link on ed and update this page). This form will be used primarily to collect information for creating an online gallery of final projects for future semesters to see what students from previous semesters created (see the gallery from Spring 2022) and solicit feedback on the final project experience.

Academic Integrity

Given the open-ended nature of the final project, we recognize that resources external to COS126 course materials may be helpful for aspects of your project that go beyond the scope of COS126. Thus, you may consult external resources within the following framework:

• External resources should be used to debug small, non-unique problems, i.e., issues that are not specific to your project (e.g., how do I use function X from library Y). They should not be used to build a large portion of your specific project (e.g., a tutorial on building project Z).
• External resources that are used to debug small problems that lie outside the scope of COS126 (e.g., using an external library, implementing a graphical user interface, reading data from input files other than .txt files, researching advanced computer science algorithms, etc.). For issues within the scope of COS126, you are limited to COS126 resources (lectures, readings, labs, precepts, office hours, lab TAs, Ed, former COS126 students), as is the case for programming assignments.
• All resources (including COS126 materials and resources) consulted must be cited properly.

Citing Resources. Specifically, your group must first compile and maintain a list (i.e., bibliography) of every resource you looked at, which will be included in your project’s readme.txt file. For a resource that informs your code in some way, you must cite that resource at that line of code and explain how you used that resource).

Snippets of code. You may use and adapt small snippets of code from other resources, provided that they are cited properly and are used to solve small, non-unique (i.e., not specific to your project), outside-of-COS126 problems. It should be extremely clear what small snippets of code are adapted from an external resource and which parts of code were written by your group. That said, the essence of your project implementation and the aspects that satisfy the scope and technical requirements must originate from and be written by your group. As a negative example, it is not acceptable to submit a project that is effectively an amalgamation of copy-and-paste snippets from different sources. As a positive example, when using an external library, you may look at and adapt small snippets of code (with citation) from any of the following: library documentation, example code snippets that show how to use library’s functions, example programs that are different from your project that use the library’s functions, StackOverflow questions about debugging incorrect uses of the library’s functions.

Here is some more guidance for what you can and cannot do as it pertains to specific project themes (see “Themes” for more details): If you plan to implement a well-known game, algorithm, and/or library, you should not look at existing implementations similar to what you are planning to implement. For libraries, you may search up the API of an existing library similar to the one you are implementing and/or examples of using that library’s functions (but not the implementation of those functions). For algorithm projects, you may read pseudo-code or textbook descriptions of algorithms similar to the one you are implementing.

Code explanations. You should be able to explain each part of your implementation, including the parts you adapted from external code snippets.

When in doubt: If you are unsure about an action and whether it fits within the above framework for academic integrity, ask your project preceptor before proceeding with said action.

Important Links

Here are links to all other final project documents:

• Proposal template: link.
• Sample proposal: Sudoku
• Link to sign up for 10-min proposal review meeting: we will post the link on ed and update this page
• Report template: we will post the link on ed and update this page
• Readme template: we will post the link on ed and update this page
• COS126 style guide: Google doc
• COS126 Past Semesters Project Gallery: link

Resources and Tutorials

Project Ideas

Input & Output

When considering your program’s potential input(s) and output(s), here are some ideas:

• Text-based (standard): Your program accepts input from the command line and/or from input files and produces output by printing to the terminal and/or writing to an output file.
• Graphical and/or auditory output (standard): Your program produces graphical output using the StdDraw API and/or auditory output using the StdAudio API.
• Simple Graphical User Interface [GUI](sprinkle): Your program handles basic user input (e.g., mouse and key events) using the StdDraw, Draw, and/or the DrawListener APIs (see booksite Section 3.6).
• Complex GUI (sparkle): Your program uses the Java Swing framework and/or other libraries to create a complex GUI with buttons etc.

Prohibited Projects

The following projects are not allowed in their basic form because they are either too easy or have been introduced in the course material. That said, variants of the following projects are welcomed (a few are included below):

• Tic-Tac-Toe (too easy)
• Rock-Paper-Scissors (too easy)
• Blackjack (too easy) - variants welcome
• Hangman (too easy) - variant welcome (e.g., Evil Hangman)
• Wordle (introduced in PE1 S22) - variants welcome (e.g., Aburdle, Quordle, Semantle, Hard Mode)
• Any project that is effectively the same as a program introduced in the textbook and/or booksite

Themes

When considering possible project ideas, here is a list of non-exhaustive themes (e.g., categories) of projects to consider:

• Games: Your program creates a new game or re-implements an existing game and allows humans and/or basic AIs to play. You can implement a simplified and/or partial version of an existing game. You should not look up implementations of a game you are planning to implement.
  • Standard: Checkers, Sudoku, Oregon Trail
  • Sprinkle: Poker, Snake, 2D role-playing games, Sokoban
  • Sparkle: Chess, Go, Tetris, Minesweeper, Brickbreaker
• Data analysis and/or visualization: Your program analyzes some data (e.g., from a dataset) and produces either text-based output and/or graphical output (e.g., using the StdDraw API). See the Datasets section for pointers to potential datasets.
  • Standard: compute statistics (e.g., averages, quantiles, correlations, etc.) on and/or generate simple graphs based on an existing dataset (e.g., on educational outcomes, policing, genetics, environment, social, etc.)
  • Sprinkle/Sparkle: create more custom visualizations based on data analysis using StdDraw, apply intermediate and/or advanced machine learning/statistical analysis techniques on a dataset
• Libraries: Your project implements a simple library that future COS126 students may find useful. The key to implementing a library is keeping it simple; there are numerous industry-level libraries that are simply too complex for COS126 student usage. When implementing a library, you may look at the APIs of similar libraries, examples of using those libraries, but not the implementation of those libraries’ functions.
  • StdRemix (standard/sprinkle): implement a library that supports advanced sound effects for remixing audio files.
  • StdTurtle (standard/sprinkle): implement a turtle graphics library (see Python’s turtle API; a simple implementation is provided in the textbook on pg. 394-6 / booksite Section 3.2, so this library would need to be a substantial extension of that).
  • SimpleCSV (standard/sprinkle): implement a simple library that supports reading and writing to .csv files (similar libraries can also be developed for other kinds of file types, such as .json or .xml).
  • StdDownload (sprinkle/sparkle): supports downloading files from the internet
  • StdPlot (sprinkle/sparkle): implement a simple plotting library (see matplotlib’s API; StdPlot should significantly extend the plotting functions provided in StdStats).
  • Extend an existing standard library (sprinkle/sparkle): implement a significant extension of an existing COS126 standard library.
• Algorithms and applications (sprinkle/sparkle): Your program implements and/or adapts an algorithm from a computer science field (e.g., machine learning, computer vision and/or natural language processing). You may consult pseudocode/textbook descriptions of algorithms but not existing implementations for the algorithm(s) you are planning to implement. You may use external libraries for non-essential parts of your project (e.g., processing input data).
  • Implementation-oriented
    • computer vision: multi-layer neural networks, image features (e.g., histogram of oriented gradients)
    • natural language processing: topic models, word embeddings, etc.
    • misc: cellular automata
  • Application-oriented:
    • graphics: implement complex, SnapChat-like image filters (these should go significantly beyond the image filters covered in lab and precept)
• Extensions of existing assignments (standard/sprinkle/sparkle): Your project implements a significant extension of a COS 126 assignment. The scope of the extension alone must meet our scope and technical requirements. This type of project overlaps with those outlined in Library and Algorithms and applications themes.
  • Conjunction Function (standard/sprinkle): implement a library (e.g., StdRemix) that supports advanced sound effects (see Library theme)
  • Classifier (sprinkle/sparkle): develop novel image features or implement existing, advanced image features to use beyond pixel values, implement a more advanced model (e.g., multi-layer neural network) for classifying images (see Algorithms and applications theme)
  • Guitar Hero (sprinkle/sparkle): synthesize additional instruments (see Enrichment section of assignment spec and Algorithms and applications theme)
  • Markov Model (sprinkle/sparkle): adapt and apply Markov models for a different application beyond text generation (see Algorithms and applications theme)
• Study Tools: Your program implements a study tool that can be used by COS126 students (or other Princeton students).
  • Example: Program to practice number system conversions (e.g., one that shows work for converting between different number systems)

Libraries

Here are a few libraries you may find useful to your project. Recall that libraries should only be used to enhance your project; they should not make up the essence of your project. Additionally, you may not consult implementations of libraries or algorithms that you hope to implement yourself as an essential part of your project. Note that most course staff likely are not familiar with these libraries.

• COS126 standard libraries
• For simple graphical user interface, see Draw.java and DrawListener.java and booksite Section 3.6 on inheritance
• PennDraw: expands upon Princeton’s StdDraw
• CoreNLP: library for natural language processing
• JavaML: library that implements machine learning algorithms
• Weka: another machine learning library
• OpenCV: library that implements various computer vision algorithms
• Tablesaw: library for organizing, manipulating, and visualizing data

Datasets

Here are a few collections of datasets you may be interested in analyzing, visualizing, or using in some way (you are also welcome to use other datasets):

• COS126 booksite dataset list (all .txt and .csv files)
• Humanities Datasets (curated by Princeton HC3)
• Intro Digital Humanities dataset list (humanities-oriented datasets)
• Kaggle datasets (wide range of datasets and different kinds of data, like images; note that data quality can vary)
• FiveThirtyEight datasets (mostly sports and politics datasets)
• data.gov (open datasets from the U.S. government)
• NYC OpenData (open datasets from NYC government)
• IEEE DataPort datasets (another repository, managed the IEEE)

Starter Code, Tutorials, and Course Materials

We have developed several tutorials, most with accompanying project .zip files and/or video walkthroughs, for getting started with certain kinds of projects.

Note: Some of these project .zip files and videos are from Fall 2021; they may not fully reflect the final project specification this semester.

Starter project (i.e., empty project .zip file)

If you would like an empty project .zip file configured to include the COS126 libraries, use the following file [.zip]. If you are not using any of the below project .zip files, you should use this one.

Analysis tutorial

If you are interested in developing a project that involves parsing .csv files (i.e., for a data analysis and/or visualization project), see this tutorial [.zip] [video], whose project .zip file also includes the 3 CDH datasets.

Database tutorial

If you are interested in developing a project that involves using a database, see this tutorial on how to use SQLite and JDBC [.zip]

Calculator tutorial

For a tutorial on any of the following topics (many of which are particularly relevant for game projects), see our Calculator tutorial [.zip] [Calculator video]

• command-line flags
• testing functions with multiple function calls
• handling exceptions using a try-catch pattern (out of scope for COS126)
• use StdIn to accept user input in the terminal
• using a game loop
• using the Stopwatch class to time elements of a game

ColorMap tutorial

If you would like to create a visualization that uses a color map (e.g., a heatmap or color-coded visualization), see our ColorMap tutorial [.zip]

GUI tutorials

If you are interested in creating a graphical user interface (GUI) that responds to key presses and/or mouse actions in real-time, here are the following options (in rough order of complexity):

1. Use and/or adapt Keyboard.java from GuitarHero
2. Use StdDraw’s or Draw’s keyboard and mouse methods (Draw is an object-oriented version of StdDraw)
3. Use DrawListener [documentation] [booksite sec 3.6]
   • Outside-of-COS126 knowledge: requires knowing how to implement an interface
4. Use Java’s Swing library to add buttons and other UI elements

We provide the following tutorials for using StdDraw (option 2), Java’s Swing library (option 4), and Draw (option 2) and DrawListener (option 3).

XOXOStdDraw tutorial

Our XOXOStdDraw tutorial [.zip] [video] covers how to implement a simple Tic-Tac-Toe-like interface using StdDraw’s keyboard and mouse methods: isMousePressed(), mouseX(), mouseY(), hasNextKeyTyped(), nextKeyTyped(), isKeyPressed()

XOXO tutorial

Our XOXO tutorial covers how to implement a simple Tic-Tac-Toe-like interface using Java’s Swing library [.zip] [video].

Board and ClickBoard tutorial

Our Board and ClickBoard tutorial covers how to use an object-oriented version of the Board API that was originally introduced in Spring 2022’s PE1 for drawing the boards of different games (e.g., Checkers, Scrabble, Wordle). The ClickBoard API demonstrates how to detect mouse clicks on the board. This tutorial is recommended for game projects [.zip].

Project planning with UML diagrams tutorial

If you are interested in using UML (Unified Modeling Language) diagrams to help you plan your project before jumping straight into programming, see our UML tutorial [video].

Here are links to project .zip files (+ video walkthroughs) for…

• parsing .csv files (also includes the three CDH datasets) [link] [video]
• developing projects that utilize SQLite and JDBC [link]
• developing general Java projects (e.g., empty project .zip file) [link]
• tutorial on project planning and using UML (Unified Modeling Language) diagrams [video]
• example code highlighting using concepts for COS126 projects [link] [Calculator video], in particular, see the following tutorials on creating a GUI (graphical user interface) using…
• StdDraw (e.g., StdDraw methods like isMousePressed(), mouseX(), mouseY()) [link] [XOXOStdDraw video]
• Java’s Swing library [link] [XOXO video]

Acknowledgements

Thank you Harvard’s CS50 and UC Berkeley’s CS10 courses for discussion, feedback, and inspiration. The design of our final project was in part based on their courses’ final project designs. Also, thank you Alfredo Velasco for developing tutorial content.

The final project was originally designed and introduced into COS 126 by Ruth Fong.