Courses‎ > ‎APCS - Term 1‎ > ‎Konstantinovich‎ > ‎

2019-05-29 Final Project reminders

posted May 29, 2019, 7:54 AM by Konstantinovich Samuel   [ updated May 29, 2019, 8:01 AM ]
5th Wednesday:
     Final Project Due [50], Demos begin[10] 
        General Project Requirements
        - Regular git commits over the ENTIRE project time.
        - Readme with description + development log.
        - In class demo (clearly prepared, demonstrating working features and communicating clearly the scope of the project)
        -The project itself must demonstrate an understanding of OOP, and minimally use at least one significant data structure / algorithm which you should highlight in the documentation.

June 5-13: Demos + Lectures on hashing/hashtables

14th Friday: Quiz[18] (Hashtables)

-3-4 minutes
-A well thought out demonstration of all of the features of your project.
    -If possible demonstrate a variety of applications of a given feature, how it works in different circumstances.
Do not show code but you can highlight algorithms (by demonstrating how they work)

Run through a mock presentation on a school computer with your final version before you present
For games:
    Adding cheat codes to help you present would be a good idea.
    Adding some "preset" levels to jump to would be a good idea. Do not just play the game and get to the last stage...


A SECOND prototype must be handed in on the 5th. This is to show the changes you made to the document. You may add new pages, but do NOT re-print the document, just make edits on the pages themselves. You may append additional pages if there are massive changes.

-Processing sketch folder should be INSIDE the repo. I will rename the repo when I clone it, so you cannot use the repo's outer folder as the processing sketch folder.
-You can make a directory in your repo called Experiments for code you want to test and mess around with but aren't included in your project directly. e.g. You want to figure out how you will use rotations but not break the rest of your project while learning it. This is how you can demonstrate learning something new but not including that code in the final version of the project.e
-README is required, make it look nice!

-You must commit multiple times per hour of coding. If you commit once per "work session" you will lose points.
-In a full period, you should typically commit 3-10 times (3 is only once per 15 minutes on average, which is barely sufficient for version tracking), this does depend on your level of productivity, finding a bug and testing code may leave you with fewer commits. At home you should have similar. If your commit is a single edit or similar minor change, that would not count towards this total. That should not be a commit at all unless it was a bug fix, in which case your commit message should reflect this.
    -Whenever you add a new feature that's worth commiting, commit.
    -You added a working method? Commit.
    -You fixed a bug? Commit.

README must include:
-Project description.
-Directions on how to run your project (start this about a week before it is due)
-Development log: Every DAY that you work on it, you summarize what you did. Note: This should be over multiple commits, and you can just summarize what was done.