This pages contains general syllabus components for all of my
classes.
Individual class pages specify particular details for each class.
For class related queries, please only 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 :)
**** is
your course catalog number)How do I get help in this class?
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!
The professor and class helpers:
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.
Pro-tip:
We are really happy to help.
Some to get assistance early ;)
All office hours start the second week of class,
and do NOT occur on the same schedule during finals week.
Where:
CS building, 2nd floor lounge and Linux lab, room 212/213.
If I’m not there, then check my office, CS322.
When:
Monday, Wednesday, 4:00pm-5:00pm
Friday, 2:00-2:50pm (some days 4:00pm-5:00pm, but not all)
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!
**** is
your course catalog number)This is a common question:
The two main contenders people use at MST in CS are:
Discord
Canvas
“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.
Weighting calculation
Grade computation
Grade ranges
A: [90.00 - 100] %
B: [80.00 - 90) %
C: [70.00 - 80) %
D: [60.00 - 70) %
F: < 60 %
Rounding
We “take attendance” via:
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.
Save snow days… #savesnowdays
https://www.youtube.com/watch?v=-FBwZtuJtMw
python3
not python2, gcc-c++ not MS-visual-studio
C++)Programming is mostly thinking:
https:/agileotter.blogspot.com/2014/09/programming-is-mostly-thinking.html
Give me six hours to chop down a tree,
and I will spend the first four sharpening the ax.
- Abraham Lincoln
To prepare for submitting assignments
1. Log into https://git-classes.mst.edu with your S&T
login
2. Watch the videos here:
https://git-scm.com/videos
4. Read Appendix E - Submitting homework with Git, in the Data
Structures Lab manual:
../DataStructuresLab/Content/tools-for-computer-scientists.pdf
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
Note:
Always include the requested or required files in the base / root
directory of the repository,
not in a sub-folder, unless otherwise specified.
Check your Gitlab CI/CD!
On the sidebar for your repository, click on
Build -> Jobs
or
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).
Danger:
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).
Pre-check and fix warnings where needed:
$ shellcheck yourscript.sh
Pre-format
$ shfmt -i 4 yourscript.sh
Run code as:
$ bash yourscript.sh
without the need for a shebang, or
$ . yourscript.sh
or
$ ./yourscript.sh
where this is at the top of your file:
#!/bin/bash
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.
#!/bin/sh
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
or
bashdb yourscript.sh args if any
Pre-check your code, and fix all warnings:
$ mypy --strict --disallow-any-explicit myscript.py
Pre-format your code:
$ black myscript.py
Run:
$ python3 myscript.py
or
$ ipython3 myscript.py
Put this at the top of your scripts:
#!/usr/bin/python3
not this:
#!/usr/bin/python
#!/usr/bin/env python3
etc…
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
or
$ pudb3 mycode.py arg1 arg2 argn
-std=c++14 or
-std=c++11Pre-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 -Wextra -Wpedantic -pedantic-errors *.cpp -o yourbinexe
To run:
./a.out
For example, run with:
$ ./a.out
or
$ ./a.out <"sample_input.txt"
or
$ ./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
or
(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
or
(gdb) start arg1 arg2 argn <stdinfile >stdoutfile
A breath of fresh air:
cargo run
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
or
$ python3 yourcode.py <sample_input.txt >your_output.txt
or
$ bash yourcode.sh <sample_input.txt >your_output.txt
then
$ 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
Points / scoring
Environment
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
fixed sample input we give you, for example by using a randomized unit
test (which you can still see). 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 or random unit tests; 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 manually try some
failing test cases yourself, that have input and output, perhaps
different or which exemplify some edge case.
Style
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.
Normalization
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”?
filename.txt) files can be opened in
your text editor or choice, and comma separated value (csv) files (e.g.,
filename.csv) can be opened with:
ITextras/ComputerRecommendations.html
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.
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.
See this repository for more information:
https://git.mst.edu/os/container
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.
General details on class VMs:
Classes/DataStructuresLab/Content/00-VirtualMachines.html
Classes/DataStructuresLab/Content/01-02-LinuxBash.html
I recommend and support Fedora for all class assignments:
Classes/DataStructuresLab/Content/01-02-LinuxBash/Fedora.html
I also offer some configuration scripts and dotfiles for
Fedora:
https://git.mst.edu/os/linux_config
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.
Campus currently offers three options for Linux environments.
To make sure the autograder runs perfectly,
you may need to use the class container image within the campus Linux
machines.
In addition to HPC batch-job processing capabilities,
the Mill offers a full virtual desktop running Linux (Fedora/Red-Hat)
with the XFCE desktop,
available from within the web browser, either on or off campus.
In general, to use the Mill as a student, you can request access
here:
https://itrss.mst.edu/cluster/mill/
If you are in a class that uses the Mill,
which has submitted your account information,
then use your campus Single Sign-On (SSO) to authenticate:
https://mill-classes.mst.edu/
For a full login here to be sucessful, you need to both:
1. Be part of a netgroup for a particuar class using mill-classes.
2. Have an account setup at mill-classes by requesting access.
If when logging in, you get a:
400 error, your authentication might be stale
(either open an incognito browser instance or restart your browser,
etc.).
500 error, your account might not be setup and attached to a
course
(verify with your instructor that you have been added to a Mill Classes
Netgroup).
You can easily run Singularity/Apptainer/Docker/Podman/OCI containers
using this interface.
See this link for details:
https://git.mst.edu/os/container
The room in the CS building,
CS212/3 has a number of physical Linux machines (Xubuntu) on the North
wall of the room.
Thus, the base login will work for tinkering around,
though the autograder is only supported if you run the above container
within this environment.
Campus also has remotely accessible virtual Linux machines.
https://itrss.mst.edu/linux/clc/
https://it.mst.edu/services/linux/
https://it.mst.edu/services/linux/hostnames/
These machines run an Ubuntu variant (Debian derivative).
Thus, the base login will work for tinkering around,
though the autograder is only supported if you run the above container
within this environment.
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.:
Where:
<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:
https://it.mst.edu/services/remote-desktop-connection/install-putty/
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://github.com/terminals-Origin/Terminals
https://mremoteng.org/
https://github.com/jimradford/superputty
https://puttytray.goeswhere.com/
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:
https://it.mst.edu/services/virtual-private-network/
The above link covers Windows/Mac
This one covers Linux: ITextras/LinuxCampusNetwork.html
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.
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.
https://www.reddit.com/r/Professors/comments/trvsdk/why_are_some_professors_so_against_recording/
Unauthorized use of artificially generated content violates
University Student Academic Standards without consent of the instructor.
For more resources visit:
https://teaching.missouri.edu/blog/teaching-time-ai
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:
https://www.nytimes.com/2020/04/08/well/live/coronavirus-face-mask-mistakes.html
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.
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/
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/.
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.
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.
For all in-person instruction, faculty should explain where the
classroom emergency exits are located. Classroom egress maps are posted
at:
http://designconstruction.mst.edu/floorplan/