CS 112 Syllabus - Summer 2015

Our schedule can be found here.

1. An ability to use procedural programming language concepts including expressions, decision statements, simple data types, Boolean logic, input/output, loop constructs, and procedures.
2. An ability to combine programming techniques to solve problems of varying degrees of difficulty.
3. An ability to refine computer programs through testing and debugging to ensure proper operation.
4. An ability to find and understand programming language documentation to learn new information needed to solve programming problems.

C or better in MATH 104, 105, or 113 (or sufficient score on the math placement test). Corequisite: CS Majors must also be enrolled in CS 101 this semester.

• Required - Zyante online text.
  1. Sign up at Zyante.
  2. Enter zyBook code: GMUCS112Summer2015
  3. Subscribe

• Required - Top Hat registration. register here with the corresponding Join code:
  • Section B01: 963600
  • Section B02: 455582

• Quite Optional - The Practice of Computing Using Python, second edition. William Punch and Richard Enbody. This is for students who want extra reading resources. You might be able to view a copy at Fenwick Library.
• An eText version is available.
• readings will be suggested, but there will not be required problems from the book.
• an older version of the text uses Python 2.7.x, instead of Python 3.x. There are a few significant differences in syntax, but if you can keep track of these (and different page numbers), you might be able to use an old version of the book if you've already got access to it.

• Grades will be posted to Blackboard.
• All assignments will be submitted (per published deadlines) via Blackboard.

• All correspondence will go through Piazza. You can send private messages to the instructors (professors, GTAs, UTAs all) as well as post public questions visible to all students, collaborate on responses, and tag everything by topic.
• Course discussions will take place on Piazza. Go sign up now so you don't miss announcements.
• Documents such as GTA/UTA contacts, schedules, and lecture slides will be on piazza only.

Programming projects will be a primary focus of your experience, progress, and grade - each one should take multiple sessions of coding, with questions asked in between. This is the practice you need to learn, master, and internalize various concepts of the course.

All project grades will be averaged together evenly.

All lab assessment grades will be averaged together. Lab assessments will be weekly exercises, tasks, or quizzes, to be completed during lab. Time in lab will often be available to seek assistance on projects when you've completed the lab task.

Any missed lab assessment is simply missed, regardless of the reason why (travel, illness, work, traffic, receiving a major award, getting married, saving the universe, etc.)

We will drop the lowest two grades from this category.

If you choose to miss some early on, and later on have to miss for some understandable reason, that is too bad. Try to save the drops so you can actually throw out a bad grade, and not just hide a lazy zero.

• these tests will focus on performing programming.
• all students must have their GMU identification available on testing days
• if you miss a test, and a valid reason is verified with documentation (ER visit, traffic accident on the way to the test, etc.), we may elect to allow the final exam to count the extra amount to give you a sort of do-over. This policy is not automatic, however.
• the final exam is cumulative. If you perform better on the final exam than a previous test, we will replace the test grade with the final grade.
• if you miss the final, there is nothing we can do for you. Don't miss the final!
• the final will not be given early. You are starting the course with knowledge of the schedule.
• You must pass the final exam to pass the course. You also need to have a passing percentage grade of course, but failure on the final exam indicates a systemic lack of true progress. Generally, students who fail the final exam do not have a passing grade in the course anyways.
• there will only be a curve if specific questions end up being too ambiguous or otherwise obviously unfair.

• Given the percentages above, the allowed dropped lowest grades, you should always be able to calculate your semester grade at any point in the semester.
• There will be no make-up or extra-credit assignments at the end of the semester; your grade should be a measure of your semester-long progress.

Grades will be assessed on the following scale:

If you feel points have been incorrectly deducted, contact the grader. For all projects and lab work, that is your GTA who leads the lab section (never a UTA). For the tests and final exam, that is your professor.

If you have not initiated contact within a week of receiving the grade (on BlackBoard), it is too late. We cannot entertain a swarm of contested grades at the eleventh hour to try to maximize end-of-semester grades. Keep up with your grades throughout the semester.

We strive to grade each student's work fairly and uniformly, often through specific test cases, which might even be automated as part of the grading process. All GTAs coordinate together with a shared scoring breakdown and regularly communicate with each other before, during, and after the grading process to keep it fair.

• All students will abide by GMU's Honor Code.
• All work must be your own. If you are caught cheating, you and every other involved student will be turned in to the honor court.
• See the CS Honor Code Policies to understand better what constitutes cheating in the CS setting. It clarifies some scenarios that are unique to our sorts of assignments.
• See the CS Statement on Academic Integrity for more information.
• Understanding the Honor Code: here are my own thoughts about the purpose of the honor code in a computer science course.