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


posted May 16, 2019, 6:26 AM by Konstantinovich Samuel
Warning :
1. If you don't understand what any part of this means, you need to stop and discuss it with your partner or a neighbor.
2. If the prototypes are not sufficient, then you get to spend the weekend working on it instead of the project.

If you come to my class tomorrow:
-You can submit/resubmit prototypes in class.
If you will NOT see me tomorrow:
-You can submit/resubmit your prototype in my mailbox (teacher mailboxes by the office near the senior bar)
    today by 4pm if you want a response tonight,
    tomorrow by 8:40AM if you want a response before the weekend.
    (Both cases I will reply via email if the prototype is approved or not)

-Remaining Tests Distributed
-Time to discuss project / have prototypes reviewed.
-If your prototype is not sufficient, or has obvious issues, you will need to resubmit it before coding. If your prototype has minor issues not warranting a resubmit, you will be instructed to update your individual copies.
-After your prototypes are reviewed by me and I approve it, make a repo and fill out the form with your partner:

Additional Project Guidelines:

-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.