This is it, the culmination of an entire semester of hard work! Now it's time to show off what you've learned and create something from scratch.

Assignment Spec

The rubric can be found here: https://courses.grainger.illinois.edu/cs126/sp2020/assignments/final-project-rubric.pdf.

Goals:

• Understand C++ compiling and linking
• Learn how to use CMake for your project
• Learn the process of using external C++ libraries
• Understand the structure of your project
• Learn how to read documentation and references
• Create an awesome application!

Gradescope

You will need to submit your GitHub repository to Gradescope every week on Tuesday @ 11:59 PM CDT.

Please make sure to copy over your PROPOSAL.md file into your final project repository before submitting to Gradescope.

Part 0: Getting Started

Get your copy of the repository here: https://classroom.github.com/a/9ILw7VFZ.

This assignment will continue to use the Cinder framework from last week.

You will find the guide on CMake helpful.

Schedule for the Final Project

Week 0 (4/8 - 4/14)

Get Cinder set up and running. Show that you have some understanding and familiarity of the Cinder framework to prepare you for your project.

Week 1 (4/15 - 4/21)

Get your final project set up; demonstrate Cinder and your external library compiling and linking fine. This means that not only are you able to include your external library's header file, but you are also able to show a very minimal, trivial example of its usage. This example doesn't need to be much: it might just be one line of code!

The most important thing is to show that you have your IDE and build environment set up and working, so that you won't be stumped by build errors later on in development. Believe it or not, being able to link the external library to your application is ~50% of the battle.

Code reviews will still take place. You will be graded based on your progress on setting up your library.

Week 2 (4/22 - 4/28)

Continue to work on your final project. Maintain a log of your progress in your DEVELOPMENT.md file. Keep your proposal's README.md updated if your project changes.

Code reviews will still take place.

Week 3 (4/29 - 5/6)

Continue to work on your final project, with a special effort on finishing it up. Maintain a log of your progress in your DEVELOPMENT.md file. Don't forget to write the README.md!

There will be a code review the week of 4/29 - 5/3. This will be your last code review of the semester!

The final project is due May 6th @ 11:59 PM CDT on Gradescope.

Project Presentations

What good is a final project if you don't show off what you've made?

Some time after May 6th, every everyone will give a very short (5 minutes) presentation of their final project; you'll sign up for a timeslot and show the instructors and/or your moderator your final project. You don't have to show any code; just the working application by itself. (We'll get the timeslots sorted out in the near future, just know this is something you'll have to do to get a full grade.)

Grading and Deliverables

Each week, you must demonstrate that:

• You have put in work towards finishing your final project
• You are attempting to follow good style and design practices
• You are keeping your development log updated as you go

At the end of the semester, you must have:

• A finished final project
• A development log in DEVELOPMENT.md that shows the timeline of the work you put into the project
• A properly-formatted README.md

And you must give your very short presentation of the final product.

DEVELOPMENT.md

In your repo you'll find a DEVELOPMENT.md file. You should use this file to keep track of your progress on your project; it should be clear to a reader what functionality you accomplished and when.

Here's a short example of the kind of thing we're looking for:

 - **4/14/20** Wrote final project documentation
   - Still need to post an announcement on Piazza
   - ~~Need to spell check it~~

 - **4/15/20** Fixed typos in documentation, posted it on Piazza

 - **4/20/20** Need to complete the following:
   [x] Make Gradescope rubric
   [ ] Grade students

NOTE: This is not the same as a Git commit history! Git commits are more for describing changes made to a single text file; this development log is about describing the progress made on your entire project.

README.md

You'll also need to write a README.md so that other people who use your project know a) what the project is, and b) how to build and use it.

Here is an example of a good README.md: https://github.com/tsoding/nothing.

The more appealing your README.md is, the more likely it is that developers will want to use your application/library.

It's O.K. if your project isn't cross-platform, i.e "You must have Visual Studio 2017 on Microsoft Windows to build this project" is fine. Just make sure people know what libraries/tools they need in order to compile your program.

Your Project Proposal

If your moderator has requested changes made to your proposal, or if you change your mind on some details of your project, you should keep your proposal up-to-date (You shouldn't need to edit this file very often, if at all.). It's O.K. if the actual development deviates a bit from what you wrote out in your proposal; once "what you want to do" is in your proposal you don't have to edit it anymore.

FAQs

Can I work past the deadline on Tuesdays?

Yes! There is no deadline or late penalty for your commits each week, other than the final deadline for the entire project, which is at 11:59 PM on May 6th. You can add more commits to your project at any time prior to that final deadline.

From now until the last day of classes, you can commit whenever you want.

Do I need to follow the Google C++ Style Guide?

Please try your best to follow the Google Style Guide.

Do I need to write tests?

Yes, and no. We won't require testing for any GUI or graphics-related code from Cinder, but you should still strive to write your code so that most of it is testable. We expect to see a reasonable amount of effort put into testing. The code in the apps/ directory will not be able to be tested with the default project layout.

Don't neglect to write any unit tests, and don't wait until the very end to add them.

What are we doing in code reviews?

Code reviews are now about giving your group and moderator a status update on your project; you'll demonstrate the code and features you've written since the last time, and you'll receive feedback that can help you improve your code and steer you towards finishing your project.

Which libraries that we've used are acceptable to count as an "additional library"?

Here are the libraries that would count:

• nlohmann/json
• SQLiteModernCpp + SQLite3
• Any Cinder Block

Here are the libraries that would not count:

• Catch2
• gflags