1 SyllabusGeneral

This pages contains general syllabus components for all of my classes.
Individual class pages specify particular details for each class.

1.1 Class communication procedures

For class related queries, please either ask during office hours,
or use the Zulip synchronous chat system (detailed below).
If you have random, non-class questions about computer science, etc.,
then feel free to email, chat, ask in person,
write a letter, send a carrier pigeon, or whatever :)

1.2 Course websites

1.3 Office hours and programming help

How do I get help in this class?

1.3.1 What to ask in your questions?

What kind of questions might you ask?
What do I type?
Why do I type that?
Why does it work that way?
How does this principle work?
Why does this principle work this way?

What should you be asking in office hours?
The first question above is not a good question…
Our goal is not to teach you typing, or “Karaoke coding”…
If you are asking questions that merely amount to:
“what do I type or do to fix my code?”,
then you should think about the problem with more curiosity.
Your goal should be to obtain at a deeper understanding,
by asking questions that inform the mental model you should be building!

1.3.2 Who

The professor and class helpers: Instructor

Please feel free to attend the professor’s office hours,
either during scheduled times or by appointment.
If you are having trouble, this can be very helpful!
If you can not make office hours times due to a consistent time conflict,
I will make every attempt to find a time to meet with you.

We are really happy to help.
Some to get assistance early ;) Instructor’s office hours

All office hours start the second week of class,
and do NOT occur on the same schedule during finals week.

CS building, 2nd floor lounge and Linux lab, room 212/213.
If I’m not there, then check my office, CS322.

Monday, Wednesday 2:00pm-3:00pm
Tuesday, Thursday 3:15pm-4:15pm Student helpers

See the detailed class-specific syllabus to see details for this option.
Student helpers may include:
LEAD, SSC tutors, paid graders, graduate teaching assistants, and more!

1.3.3 Class forum Why do we use Zulip (and A/V provider Jitsi)?

This is a common question:

The two main contenders people use at MST in CS are:



1.4 Class/teaching evaluation and improvement

1.4.1 Educational goals

“As gold which one cannot spend will make no person rich, so knowledge which one cannot apply will make no person wise.”
- Samuel Johnson.

As this quote suggests, my primary goal of courses is to provide you broad familiarity with theory and methods commonly employed both in many real-world applications, and also those which are used for more advanced methods. My secondary goal is to practice actually implementing these methods, both to assist understanding, and also to increase retention.

1.5 Overall grading

Weighting calculation

Grade computation

Grade ranges

A: [90.00 - 100] %
B: [80.00 - 90) %
C: [70.00 - 80) %
D: [60.00 - 70) %
F: < 60 %


1.6 Attendance and discussion questions

We “take attendance” via:

  1. Required daily web-quizzes using a classroom response system (CRS)
  2. We will also use stochastic sampling methods in class to take attendance, and learn names. I use a random name sampling program to sample someone from the roster, and then ask a question (only for bonus points).

Missing classes will greatly diminish your chances for getting a good grade in this class.
If you miss more than 5 classes, then we reserve the right to drop you from the class.

1.6.1 Inclement weather

Save snow days… #savesnowdays

1.7 Late work, makeup, missing class

1.8 Quizzes / Daily questions

1.8.1 Quiz grading

1.9 Technical and programming assignments

1.9.1 Coding Tips

Give me six hours to chop down a tree,
and I will spend the first four sharpening the ax.
- Abraham Lincoln

1.9.2 Submitting your assignments via Git

To prepare for submitting assignments
1. Log into https://git-classes.mst.edu with your S&T login
2. Watch the videos here:
4. Read Appendix E - Submitting homework with Git, in the Data Structures Lab manual:
5. Some optional extras include the full set of materials listed under the Version Control lab day here:
* Classes/DataStructuresLab/Content.html
* Classes/DataStructuresLab/Content/03-VersionControl.html

Submit using the repositories created for each assignment at: https://git-classes.mst.edu/
Execute once:
$ git clone https://url-for-your-repository

Execute as many times as you like from within the directory/repository you cloned to your hard drive (just an example):
$ git status
$ git add *.cpp *.h *.hpp *.txt *.py
$ git add SUBDIRECTORY/*
$ git commit -m "Informative description of the commit"
$ git push

Do not add:
Compiled or generated files like a.out, your executable files, etc.
Put the name of these files in a text file in the root of your repository, named: .gitignore

If you see your changes reflected on the git-classes site, you have submitted successfully.

If you work from different computers and want to synchronize, or we make changes to your repository:
$ git pull

Always include the requested or required files in the base / root directory of the repository,
not in a sub-folder, unless otherwise specified. How do I know whether my automatically graded tests passed or failed?

Check your Gitlab CI/CD!

On the sidebar for your repository, click on
Build -> Jobs
Build -> Pipelines

Then, in Jobs, click on either the red failed or green passed button.
Or, if you went with Pipelines, you must click on the pipeline,
then the individual job, to display the below result.
The above screen will show you that either all tests passed (green),
or if one failed, exactly which failed.
You can know which failed, because it will be the last one to have run,
and thus produced a “return code” of not 0 (1 or some other number).

You probably should not change the CI file we give you,
unless you’re adding tests of your own,
and should not change it in order to fake a pass
(it won’t work, and would be considered cheating).

1.9.3 Execution of Bash programs

Pre-check and fix warnings where needed:
$ shellcheck yourscript.sh

$ shfmt -i 4 yourscript.sh

Run code as:
$ bash yourscript.sh

without the need for a shebang, or
$ . yourscript.sh
$ ./yourscript.sh

where this is at the top of your file:

actually specifies un-ambiguously the use of bash, and the binary location. This is the one you should use.

#!/usr/bin/env bash
specifies ambiguously the use of bash, but not the binary location, thus opening a security vulnerability; env was not intended for this purpose, and it’s use here comes with a number of concrete disadvantages.

is the system’s default shell, and is ambiguous. This is like saying (by analogy), I scripted this, maybe in python2, maybe python3, or maybe even perl…and you’re supposed to guess blindly. It sometimes means a POSIX compatible shell, but not always.

Debug your code:
bash -x yourscript.sh args if any
bashdb yourscript.sh args if any

1.9.4 Execution of Python3 code

Pre-check your code, and fix all warnings:
$ mypy --strict --disallow-any-explicit myscript.py

Pre-format your code:
$ black myscript.py

$ python3 myscript.py
$ ipython3 myscript.py

Put this at the top of your scripts:

not this:
#!/usr/bin/env python3

I have also built a customized call-graph and control-flow-graph generator for python scripts. In the class VM, you can use it as follows:
$ py2cfg mycode.py

Note: the ipython3 interpreter and python3 interpreter do some things differently:
* ipython3 more liberally imports code in sub- and super-directories
* ipython3 includes some hidden junk characters at the beginning of std-out.
* ipython3 can mangle or interfere with argparse displaying its help.
* ipython3 is more colorful and nice looking.
* probably more things…

Debug your code by stepping through it:
$ pudb3 mycode.py
$ pudb3 mycode.py arg1 arg2 argn

1.9.5 Execution of C++ code

Pre-check with:
$ cppcheck yourcode.cpp
or more specifically:
$ cppcheck --enable=all --language=c++ ./*.cpp ./*.h ./*.hpp

Pre-format with:
$ clang-format.py -i --style=Microsoft ./*.cpp ./*.h ./*.hpp

Compile with debug flags:
$ g++ -g file1.cpp fileN.cpp -std=c++14

Compile with extra nagging (a good thing):
g++ -g -Wall -W -Wextra -Wpedantic -pedantic-errors *.cpp -o yourbinexe

To run:

For example, run with:
$ ./a.out
$ ./a.out <"sample_input.txt"
$ ./a.out <"sample_input.txt" >"your_output.txt"

Check for memory leaks with:
$ valgrind ./a.out <"sample_input_if_exists.txt"
or, for example:
$ valgrind --leak-check=full ./a.out <"sample_input_if_exists.txt"

Debug your code:
using cgdb
$ cgdb ./a.out
(gdb) start
(gdb) start <stdinfile >stdoutfile
(gdb) start arg1 arg2 argn <stdinfile >stdoutfile
or use gdb
$ gdb ./a.out
(gdb) layout next to show code
(gdb) start
(gdb) start arg1 arg2 argn <stdinfile >stdoutfile

1.9.6 Execution of Rust code

A breath of fresh air:
cargo run

1.9.7 Things you should check before you submit:

Compare your output to any given sample output to make sure they are the same,
including all newlines and spaces, via bash:
$ ./yourcode.out <sample_input.txt >your_output.txt
$ python3 yourcode.py <sample_input.txt >your_output.txt
$ bash yourcode.sh <sample_input.txt >your_output.txt
$ diff --color sample_output.txt your_output.txt
$ # or for two-column format (easier to see):
$ diff -y --color sample_output.txt your_output.txt
$ # or using vim:
$ vim -d sample_output.txt your_output.txt
$ # or in a GUI:
$ meld sample_output.txt your_output.txt

1.9.8 Grading technical assignments

Points / scoring

It is expected that all of your work runs correctly in the specified Linux environment we are working with in class, in the exact manner we specify in the assignment description. If you were contracted to write code for a job, and it ran on your computer, but not your employer’s as they needed, your work would be considered a failure. In that light, you are also responsible for submitting all text and source files such that they are compatible with our specified environment, e.g., encoded UTF-8, Unix delimited, etc.

Test cases
The test cases we will run for grading may be more extensive than any sample input we give you. It is possible, even likely, that if your program seemingly works perfectly, for example with an input file: sample_input.txt, that it may not work perfectly with our grading scripts; this is fair and reasonable challenge, since we describe the bounds of performance required generally; when coding in the real world for a job, you will be expected to anticipate edge cases, weird behavior, larger than expected data-sets, etc. Practicing this can help you train one of the more important skills of an industry programmer. You should make some test cases yourself, that have input and output, perhaps different or which exemplify some edge case.

Good programmers don’t always have good comments, but they almost always have clean, consistent, readable code style and formatting… Take pride in your code! For example, if your assignment is in Python, Bash, C++/C, or Rust, we grade your code using auto-formatters, black, shfmt, clang-format, or rustfmt respectively.

After grading any given assignment, if that assignment appeared to be too difficult for the class, I may choose to normalize to the top student’s performance (the student with the highest point rank will get a 100% / A). This can, by definition, only help your grade, but not hurt it. I won’t ever do the opposite (lower grades).

Precision unit testing
In the real world, and in industry, 99% of code is tested by code. When a networked program, or an operating systems program, or a web program, does not have perfectly spaced output, it does not work, at all... Computers are not flexible; they are rigid, and they need babying! Code that is merely run-able (playable, produces output, etc.) is NOT correct code! Getting workable code is the first half of the assignment. Getting your workable code to be correct in all the remaining needed details is the second half of the assignment.

What is “correct code”?

1.9.9 Assignment feedback

1.10 Working environment for technical assignments

1.10.1 What kind of computer should I buy/have for this class?


1.10.2 Class docker container

This is essentially guaranteed to work.

Typically, you are given a git repository for each assignment.
In that repository are some files for running a container using:
This system allows you to launch a working terminal.
It is a fully configured Linux environment to run your auto-grader, test, etc.
It shares a folder with the current directory (your repository).
This folder sharing allows you to edit in your host,
and actually execute tests and code in the container.


# Step 0: Install docker

# Mac: # https://docs.docker.com/get-docker/

# Windows:
# Open PowerShell and execute:
# $ wsl --install
# Reboot.
# Then install docker https://docs.docker.com/get-docker/

# Linux:
# sudo apt/dnf/zypper/etc install docker

# Step 1: Open one terminal
# (Mac use zsh, Windows use WSL, Unix/Linux use whatever)

#Step 3:
git clone https://your_repo

# Step 4:
cd your_repo/

# Step 5
# Note: Depending on how your system handles sudo,
# you may need to copy the command in this script without the `sudo`,
# and run it directly at your terminal.

# Step 6
# Note: Depending on how your system handles sudo,
# you may need to copy the command in this script without the `sudo`,
# and run it directly at your terminal.

# Now, you're ready to edit, code, and run tests.

This is essentially guaranteed to work,
though may take a bit more setup effort.

Develop, test, and submit your assignments using the class virtual machine.
We grade in this environment, and your code must run there.
Do not write your code on your Windows or Mac install,
unless you are willing to take accountability (risk) for not testing it on the class VM.
Details on class VMs:

1.10.4 Your own Linux installation

This will likely to work,
though may take a bit more setup effort.

If you are already running Linux on your own machine, bare metal:

Security note:
This exception does not apply for Security,
which you really should sometimes NOT execute our class scripts in your host;
they will break things.

1.10.5 Campus Linux machines

The room in the CS building,
CS212/3 has a number of physical Linux machines (Xubuntu) on the North wall of the room.

Campus also has remotely accessible virtual Linux machines.

These machines run an Ubuntu variant (Debian derivative).
Thus, the base login will work for tinkering around.

To make sure the autograder runs perfectly,
you may need to use the class container image within the campus Linux machines.

To do that, AFTER ssh’ing in, you would run something like:
$ singularity shell docker://git-docker-classes.mst.edu/containers/rust
Depending on what language the assignment was in. Remote Putty/SSH/Mosh/etc. access to campus Linux

Read Classes/DataStructuresLab/Content/tools-for-computer-scientists.pdf Appendix A and B

Remotely, ssh into the department’s IT Linux systems:
Where username is um-ad\yourssoid

If you are running Unix, Linux, BSD, MacOS, etc.:
<NN> = computer number (links above),
<username> = your username,
and quotation marks matter, type:
$ ssh "um-ad\<username>@rc<NN>xcs213.managed.mst.edu

or if you want to run a graphical application, add the -X flag:
$ ssh -X "um-ad\username@rcNNxcs213.managed.mst.edu"

If you are running MS-Windows:

Use https://putty.org to connect to the same address:

Putty has a portable binary ‘exe’,
that can be run without installation,
in case the campus machine you are on does not have it installed.

For graphical applications on Windows:
1. Run xming
2. Using https://putty.org enable X-forwarding under SSH menu:

If you find putty on Windows a bit cumbersome,
then use any of these as a alternative to putty:
https://vscodium.com/ + VSCode’s remote plugin for ssh
https://atom.io/ + remote plugin for ssh

If you’re off campus, for example at home,
then you need to create a VPN connection to campus,
before ssh’ing into the Linux machines:
The above link covers Windows/Mac
This one covers Linux: ITextras/LinuxCampusNetwork.html

1.11 Academic honesty

You should intend to learn, to better yourself, to train skills, knowledge, memory, and technical abilities! Cheating in class is like paying someone else to go to the gym and exercise for you… In this academic gym, I the instructor, am your trainer, but you have to show up and work hard. Aquiring knowledge and skills takes effort, dedication, and sacrifice, that you perform yourself. I can only show you how, and I hope to ascertain via in-class assessments whether your efforts were sincere and persistent, and thus effective.
Write all your work in your own words, and write your own code. Do not copy-paste (plagiarize) from any source. If you are not sure, err on the side of caution, and do your work independently. Occasional infrequent help from a friend when your are really stuck may be reasonable, though if that “help” is frequent enough that your collaboration results in almost identical code, it was too much collaboration for an assignment intended to be independent work (which all are unless explicitly assigned as group work). Cheating includes attempting to hard-code outputs to “fool” the auto-grader.
If you are found to be engaging in any form of academic dishonesty, the most severe penalties permitted by the university will be enacted. Incidences will typically result in grades of 0 for the respective course components, as well as notification of the student’s advisor, the student’s department chair, and the campus undergraduate studies office. Further academic sanctions may be imposed as well in accordance with university regulations (http://academicsupport.mst.edu/academicintegrity/). Those who allow others to copy their work are also committing plagiarism and will be subjected to the same procedures.

The Honor Code can be found at this link: http:_stuco.mst.edu/honor-code/. Page 30 of the Student Academic Regulations handbook describes the student standard of conduct relative to the University of Missouri System’s Collected Rules and Regulations section 200.010, and offers descriptions of academic dishonesty including cheating, plagiarism or sabotage (http:_registrar.mst.edu/academicregs/index.html). Also see: http://academicsupport.mst.edu/academicintegrity/studentresources-ai

We check your assignments against each other with software that is VERY good at detecting similarities and differences between any text files, including your source files. These methods are difficult to trick. Please do not try to copy-paste, share sources directly, or write all your code in a group or pair for individual assignments; you will not like the consequences!

Attempting to deceive attendance checking procedures is considered academic dishonesty for ALL parties involved. For example, do not give someone copies of your code, or submit someone else’s pre-lab or lab assignment for them because they are not attending class, or answer someone else’s daily CRS questions.

Important note:
For efficiency, I may cheat-check all your submitted assignments in only two batches all semester:
1. The first check will occur just before the last drop date, about halfway through the semester, for the first half of your assignments.
2. The second check will occur during final exams week, before grades are due, but after all your your assignments are turned in.
This includes checks against previous semesters if needed.

1.12 University-wide statements

It is vitally important that our classroom environment promote the respectful exchange of ideas. This entails being sensitive to the views and beliefs expressed during discussions whether in class or online. Please speak with the instructor before audio-recording or video-recording any class activity. It is a violation of University of Missouri policy to post, upload, or distribute such recordings without instructor authorization and the permission of others who are recorded. Do NOT record class activities yourself.

Further, classroom recording creates issues with student privacy, silencing discussion, dis-incentivizing attendance, calling of names (FERPA issues), etc.

1.12.2 Artificial Intelligence

Unauthorized use of artificially generated content violates University Student Academic Standards without consent of the instructor. For more resources visit:

1.12.3 Infectious disease hygiene procedures when on campus

Be considerate to your community,
it will likely come back to you at some point;
that’s what diseases do…
Not everyone is healthy,
and even healthy individuals may have family members who are not.
If you are sick, then stay home,
or wash your hands, and wear your mask when on campus.
This is not how you wear a mask:

1.12.4 Learning Enhancement Across Disciplines (LEAD)

http:_lead.mst.edu provides optional (not required) tutoring in a wide range of courses for students who wish to increase their understanding, improve their skills, and validate their mastery of concepts and content in order to achieve their full potential. LEAD assistance starts no later than the third week of classes. Check out the online schedule at http:_lead.mst.edu. Some courses have collaborative LEAD learning centers (bottom half of schedule) and/or Individualized LEAD tutoring (top half of the schedule). For more information, contact the Academic Support office at 341-7276 or email lead@mst.edu.

1.12.5 Student Success Center

SSC was developed as a campus-wide initiative to foster a sense of responsibility and self-directedness to all S&T students by providing peer mentors, caring staff, and approachable faculty and administrators who are student centered and supportive of student success. The Student Success Center in Toomey Hall was designed for students to visit and feel comfortable about utilizing the campus resources available. Visit the SSC at 198 Toomey Hall; 573-341-7596; success@mst.edu; Facebook:  https:_www.facebook.com/SandTssc; web: http:_studentsuccess.mst.edu/

1.12.6 Well-Being and UCARE

Any of us may experience strained relationships, increased anxiety, feeling down, alcohol/drug misuse, decreased motivation, challenges with housing and food insecurity, etc. When your mental well-being is negatively impacted, you may struggle academically and personally. If you feel overwhelmed or need support, please make use of S&T’s confidential mental health services at no charge. For a quick guide to campus resources that address specific issues please visit our Well-Being Referral Guide, available as a website at https:_minerwellness.mst.edu/well-being-referral-guide/. If you are concerned about a friend or would like to consult with a Care Manager, please make a UCARE referral for support and assistance. https:_stuaff.mst.edu/ucare/.

1.12.7 Accessibility and Accommodations

If you have a documented disability and would like accommodations in this course, please facilitate providing documentation to the professor as early as possible in the semester. Disability Support Services staff will need to send a letter to the professor specifying the accommodation you will need. It is the university’s goal that learning experiences be as accessible as possible. If you anticipate or experience physical or academic barriers based on disability, please contact Student Disability Services at (573) 341-6655, sdsmst@mst.edu, visit http://dss.mst.edu/ for information, or go to mineraccess.mst.edu to initiate the accommodation process. Please be aware that any accessible tables and chairs in this room should remain available for students who find that standard classroom seating is not usable.

1.12.8 Nondiscrimination, Equity, and Title IX

See https://equity.mst.edu/

Missouri University of Science and Technology is committed to the safety and well-being of all members of its community, and to creating an environment free from discrimination and harassment.

The University does not discriminate on the basis of race, color, national origin, ancestry, religion, sex, pregnancy, sexual orientation, gender identity, gender expression, age, disability, protected veteran status, and any other status protected by applicable state or federal law. As used in this policy, the word “sex” is also inclusive of the term “gender.”

Additionally, US Federal Law Title IX states that no member of the university community shall, on the basis of sex, be excluded from participation in, or be denied benefits of, or be subjected to discrimination under any education program or activity. Violations of this law include sexual harassment, sexual assault, dating/domestic violence, and stalking.

In accordance with The Collected Rules and Regulations University of Missouri, Missouri S&T requires that all faculty and staff members report, to the Missouri S&T Equity Officer, any notice of discrimination disclosed through communication including but not limited to direct conversation, email, social media, classroom papers and homework exercises.

Missouri S&T’s Equity Officer and Title IX Coordinator is Chief Diversity Officer Neil Outar. Contact him (naoutar@mst.edu; (573) 341-6038; 203 Centennial Hall) to report violations of the university’s nondiscrimination polices, including Title IX. To learn more about resources and reporting options (confidential and non-confidential) available to Missouri S&T students, staff, and faculty, please visit http://titleix.mst.edu.

1.12.9 Classroom Egress Maps

For all in-person instruction, faculty should explain where the classroom emergency exits are located. Classroom egress maps are posted at: