Course Information

This handout was adapted from Jerry Cain’s Spring 2018 offering.

Instructor: Ryan Eberhardt

Email: rebs (at) cs (dot) stanford

Office hours: TBA

Lectures: Monday/Wednesday/Friday 10-11:20am Pacific Time on Zoom

Units: 5 units. Only matriculated graduate students may register for fewer than five. The course requirements are the same for all students, including those who take the course for 3 or 4 units.

Course Assistants: Ayelet Drazen, Patrick Demichele, Sophie Decoppet, Thea Rossman

CS110 CAs attend lectures, lead discussion sections, hold office hours, evaluate homework submissions, monitor Piazza, and grade exams. Be glad they’re here, because all of them have either taken CS110 before, CA’ed CS110 before, or both, and they know the material so well they already know what your questions are going to be.

Prerequisites

Formally, the prerequisite for the course is CS 107. Less formally, you need to be familiar with the C and C++ programming languages, Unix/Linux, make, Makefiles, gcc/g++, valgrind, gdb, and have some experience with basic computer architecture (x86 as it’s taught in CS107, or exposure to some other architecture with the confidence and ability to pick up x86 as I reference it). If you have not taken CS 107, please email me at the beginning of the quarter to let me know.

We’ll be coding in a mixture of C and C++ throughout the quarter. We rely on C, because the libraries needed to interface with system resources are written in C. We rely on C++, because the projects become large enough that I prefer to go with a more mature language that supports encapsulation and generic programming better than C does. You should understand pointers, dynamic memory allocation (malloc/realloc/free), and C strings perfectly. You should understand C++ classes, methods, references, templates, and C++'s new and delete operators. There are many C++ features you’re not expected to know, but you should have enough programming maturity to pick those features up and search the web for reference materials as needed.

The CS 107 course website is still up and may be a good reference. If you have not taken CS 107 and find yourself struggling, get help as soon as possible! This class moves quickly, and you will not want to fall behind. Email me and I may be able to point you to helpful resources.

Readings

Readings are optional this quarter. I will post notes and slides with most lectures as reference material. However, if you would like additional readings to prepare for lecture or to reinforce concepts, I will list associated readings from the following textbooks:

Software

You will do most of your work on the myth machines (reachable over SSH at myth.stanford.edu), although I may occasionally reference the more powerful rice, wheat, and barley machines to clarify the impact that more processors and larger caches have on execution.

I recognize that you are probably used to working on your own machine and would prefer to complete your assignment on your computer before eventually copying it to the myths and submitting there. However, I strongly urge you to code, test, and debug directly on the myths via ssh. The myths provide us with a consistent execution environment, whereas if you develop on your machine, you may have problems with missing libraries, old compiler versions, or possibly even architectural differences that cause subtle differences in program behavior. (As an added bonus, you won’t lose your code from a catastrophic laptop failure if you develop on the myths.)

You should also spend some time getting to know your tools of choice (this includes gdb and valgrind, but also your terminal emulator and text editor). One important goal of CS 110 is to make you a stronger programmer in general, and part of this is learning your tools so you can be more efficient.

Student Forums

We’re using Edstem for the class forum. When you have a question that might be of interest to other students, please post it there for a speedy response. Please note that you should never include snippets of code directly from your own homework submissions, since that’s code sharing and a huge no-no.

We also have a Slack workspace for CS110. We’ll use Slack more as a social forum, as well as a space for your lab CA to communicate with you. As with Ed, you should never include snippets of code in any conversation – public or private – if that snippet is contributing to an assignment solution.

Grading

You can take the course for a letter grade, or CR/NC. The grade breakdown is:

One very large caveat: regardless of what your overall average is, you need a functionality score of 50% or higher on every single assignment in order to receiving a passing grade—that is, either a C- or a CR. Restated, if you get lower than a 50% on any single assignment, then that assignment counts for 100% of your grade.

This policy is in place to ensure you meet the post-conditions of the course by establishing fluency in all subjects. We’re specifically guarding against the scenario where you complete only as many assignments and self-assessments as needed to get a 70% to pass and then peace out ✌️✌️✌️✌️. If you end up getting below a 50% on an assignment, we’ll email you as soon as we realize it and we’ll allow you to resubmit it for re-evaluation. However, the most you can get on the resubmission is 50%.

Concept Checks

In an effort to keep you on pace to do well in the class, we are requiring that you complete concept checks after each lecture. These concept checks will be hosted on Gradescope and will exercise a basic understanding of material covered in each lecture.

Concept checks are always due by 10:00am on the day of the following lecture, though we’ll accept late submissions up to one week after that lecture for 50% of the points. All concept checks count the same, regardless of any point values displayed by Gradescope.

Programming Assignments

There will be 6 or 7 programming assignments this quarter (dates TBA). Assignments will require roughly 10-15 hours/week to complete and will help you become intimately familiar with some section of material from the class. We have tried to make each assignment as rewarding as possible; each assignment requires you to draw upon your systems knowledge to build something you yourself might encounter regularly, such as a shell, a proxy, or a debugging tracer (a la strace/dtrace).

Assignment grades have two components: functionality and style. Functionality is graded by a series of automated tests and is worth 5/6 of each assignment grade. Style is graded on a bucket system (solid, minor problems, or major problems) and is worth 1/6 of your grade. Style is quite important (and you may not arrive at a functional solution if your style is particularly bad), but in the end, we care most that your code works.

All programming assignments are due at the stroke of midnight unless otherwise stated, and you’ll always be given at least 7 days to complete any one of them. Please submit assignments on time. We understand everyone here is busy, but falling behind on assignments is bad for us (interferes with our ability to turn around grades quickly) and bad for you (the quarter moves so fast that you will quickly run into trouble). Unlike many other CS classes, we provide no late days, but you may still submit assignments late, subject to a cap on the maximum number of points you can earn:

I understand that life can be wild, especially in these times. If something comes up and you need an extension, come talk to me, and I’ll do what I can to make your life easier while being fair to everyone else.

Additionally, note that unlike previous CS classes, course staff will not look at your code in office hours or over email. In this class, the assignments become complicated enough that although a CA could debug your code, it would take a very long time and would be of little long-term benefit to you. (These systems are complicated enough that a CA might need to read and understand nearly all of your code before figuring out your bug.) Instead, we want to train you to code very carefully and test very frequently. Test your program every time you write a few lines of code to verify that it works as intended. If you write 500 lines of code before discovering your program is broken, it may very well be faster to start from scratch, even if a CA reads your code to debug it for you. With that in mind, to help you learn best and out of respect for your peers, CAs are instructed to not look at assignment code in office hours.

Self-assessments

The university has formally cancelled final exams for a variety of reasons, in part because they strongly oppose the idea of a high-stakes exam when everyone is hunkered down optimizing for health and safety. We’re taking this as an unofficial recommendation to remove all high-stakes exams, and we’re more than happy to embrace that interpretation.

At the moment, we’re planning to administer three self-assessments the weekends after Assignments 2, 4, and 6 are due. The self-assessments will be three hours long, so that once you start, you must complete and submit your responses (most likely via Gradescope) within three hours. However, the self-assessments will be posted by 12:00pm Stanford time on the corresponding Fridays, and you’re free to begin working on the timed self-assessment anytime during the next 72 hours. That means you can start on Friday at 5:15 pm and submit by 8:15pm if you’d like, or you can start at 9:00am on Monday and submit by 12:00pm, or you can start and finish during any three-hour window that weekend that works for your schedule. The latest we’ll accept submissions, however, will be at 12:00pm Stanford time the Monday after the self-assessment is released.

So we’re all clear, our only reason for mandating you take these self-assessments—we don’t even want to call them exams—is because we want you to be able to take a pulse on how well you’ve learned the material. Scores will be initially interpreted as a percentage out of 100%, but when computing final grades, we’ll take the square root of that percentage and multiply it by 10 to arrive at a different “percentage”. That means a 100% stays a 100%, 81% becomes 90%, and 64% becomes 80%, etc. We’re adopting this grading scheme so self-assessments can be as challenging and thought-provoking as on-campus exams generally are without the added pressure to get every single point. (It also means you’re not competing against each other and fighting to sit in the better half of the bell curve.)

Discussion Sections

This quarter, you’ll be expected to sign up for a weekly discussion section and tune in, participate, and submit a lab worksheet to demonstrate minimal fluency with the week’s material. Everyone is expected to choose a discussion section they can tune in to live, as we won’t be recording them for general consumption.

Sections will be a combination of written problems, coding exercises, and software engineering tips to ensure that you understand the material and are outfitted to complete the assignments with minimal drama. We recognize that enrolled students are living everywhere on earth, so we’ll offer a small number of early morning sessions (e.g. 7:30am Stanford time) and evening sessions (e.g. 7:30pm Stanford time) to appeal to those on opposite sides of the globe. Discussion sections will begin in Week 2.

Discussion section signups will go live on Monday, April 5th at 8:00am Stanford time, and everything is first-come, first-served. We don’t rely on Axess for discussion section signups, but rather host them on our own course website. You’ll soon notice an item called Labs within the left navigation column of the website, and you should drill though that to sign up once that page goes live.

Students with Documented Disabilities

Students who may need an academic accommodation based on the impact of a disability should initiate the request with the Office of Accessible Education (OAE). Professional staff will evaluate the request with required documentation, recommend reasonable accommodations, and prepare an Accommodation Letter for faculty. Unless the student has a temporary disability, accommodation letters are issued for the entire academic year. Students should contact the OAE as soon as possible since timely notice is needed to coordinate accommodations. The OAE is located at 563 Salvatierra Walk, and their website is located right here.

Honor Code

Although you are encouraged to discuss ideas with others, your programs are to be completed independently and should represent fully original work. Whenever you obtain help (from current or previous CS110 students, the CA’s, students in other classes, etc.) you should credit those who helped directly in your program, e.g. in a program comment, type “The idea to use a mutex-guarded linked list of file descriptors came from a discussion with my CS110 CA, Hemanth Kini”.

Any assistance that is not given proper citation is considered plagiarism, and a violation of the Stanford Honor Code. To be even more specific, you are not allowed to collaborate on the coding of your programs, nor are you allowed to copy programs or even minute snippets of programs from other students, past or present. The following activities are among the many I consider to be Honor Code violations:

  1. Looking at another student’s code.
  2. Showing another student your code.
  3. Discussing assignments in such detail that you duplicate a portion of someone else’s code in your own program.
  4. Uploading your code to a public repository (e.g. github.com or bitbucket.com) so that others can easily discover it via word of mouth or search engines. If you’d like to upload your code to a private repository, you can do so on github or some other hosting service that provides free-of-charge private hosting.

Unfortunately, the CS department sees more than its fair share of Honor Code violations. Because it’s important that all cases of academic dishonesty be identified for the sake of those playing by the rules, we exercise our right to use software tools to compare your submissions against those of all other current and past CS110 students, including any we might find online. While we certainly don’t want to create some Big Brother environment, we do need to be clear how far we’ll go to make sure the consistently honest feel that honesty is valued and respected.

If the thought of copying code has never crossed your mind, then you needn’t worry, because I’ve never seen a false accusation go beyond a single conversation. But if you’re ever tempted to share code – whether it’s because you don’t understand the material, or you do understand but just don’t have enough time to get the work done – then you need to remember these paragraphs are here.