SyllabusGeneral

____________________________________________________

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

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 :)

Course websites

• Syllabus and all course content materials:

• Programming assignments and feedback are posted here:

• Threaded chat and help for the class:

• Grade recording, calendar, due dates:

Office hours and programming help

How do I get help in this class?

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!

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.

Pro-tip:
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.

Where:

When:

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!

Class forum

• https://cs****.zulipchat.com (where "****" is your course catalog number)
• There is also an invite link posted in Canvas.
• Use your @umsystem email to register an account with each course instance.
• Zulip is a better-designed alternative slack/discord/teams/etc, which is optimized for programming teams, and supports coding projects well.

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

This is a common question:

• Our goal is to optimize the help and community for students (we have your goals at heart).
• Thus, myself and my graders/GTAs, have experimented with many of the common team and student communication platforms, including: Discord, Slack, Teams, Rocketchat, Mattermost, GroupMe, etc.
• Zulip is clearly better designed for getting help and actually coordinating on content, rather than engaging in big streams of whining banter, where actual answers get lost in the drivel, and so questions get asked again and again...
• Zulip is just a great product for team cooperation and communication, and there is good reason that the core python developers themselves use it as their communication platform.
• It has a good privacy policy, is cross platform (most all platforms, including mobile), and open source.
• It has true topic threading, efficient chat, direct messages, group chats, code highlighting, file share, audio-video spin-off, etc.
• https://zulip.com/why-zulip/
• https://zulip.com/features/

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

Discord

• I have nothing against discord, and still use it for some things (I even visit the CS discord), it's just not as well-designed for content-based discussions and collaborations as Zulip.
• There is a department discord: https://discord.gg/f5KPWfw
  • You can join this, and there will likely be help channels for your course there.
  • But, it's less likely to get you substantial help than the course's Zulip chat.
• Discord has both single public rooms, and direct messages, but does not have true threading, and thus tends to make it difficult to find already-answered questions, as well as tending toward meaningless banter, skipped questions, off-topic discussions, etc.
• It is cross-platform.
• But, it is closed source, and the privacy policy is questionable at best, more likely a bit predatory.
• Discord has recently added audio chat spin-off.
• These platforms have been used for cheating in the past, and we do monitor them, to make sure it's not going on now.

Canvas

• Canvas forums do threading, which is nicer than one big chat room, but the post-based discussion forums are clunky and slow.
• Canvas does chat, but it's one single stream, and has no direct 1v1 or small group chat.
• University hosted, open source.
• No reasonable audio-video spin-off option.

Class/teaching evaluation and improvement

• Please let me know what you like about the class and how it can be improved!
• I usually do mid-semester feedback (in upper level classes), and use that feedback.

Educational goals

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.

Overall grading

• Your grade records and calculations are kept in Canvas.
• We grade using a weighted combination of the following categories:
  • Assignments
  • Daily quizzes
  • Random questions to students in class
  • In-class labs or activities (not in all classes yet)
  • Tests (programming tests; not in all classes yet)
  • May factor in points for attendance related performance, bonus, participation, or efforts demonstrated during office hours.

Weighting calculation

• Weighting between grade categories is available on Canvas.
• Weighting percentages for each category may change slightly toward the end of the semester, depending on student performance.
  • I occasionally try to re-weight to improve grand average scores.

Grade computation

• Your final grade = percent of possible points
• Your letter grade = standard S&T letter-percentile mapping:

Grade ranges

Rounding

• Though I would often like to, grades can not be fairly rounded without giving everyone a bonus.
• For example, if you have a 79.9, that is a C, unless the whole class has an opportunity for such a bonus.
• If >50% of the class fills out CET evaluations, I will round all decimal precision up, e.g., 79.1 becomes 80 / B.

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.

Inclement weather

Save snow days... #savesnowdays
https://www.youtube.com/watch?v=-FBwZtuJtMw

Late work, makeup, missing class

• If you have an unavoidable S&T-acceptable documented reason (i.e., death in the family, illness, etc) for missing in-class events, please talk to the professor to discuss potential re-scheduling or accommodation.
• Note that this does NOT include optional parties, such as:
  • vacations with family, weekend trips, weddings (voluntary parties), etc.
• Exceptionally few companies excuse for such things;
  • when your vacation time is out, that's it, if you don't show, you're fired!
• Late work is not accepted; it would be wise to plan ahead!

Quizzes / Daily questions

• Published experimental studies in the fields of research in cognitive psychology and education have shown that frequent (rather than sparse) recall, is both more effective for learning, retention, and synthesis, and also encourages frequent smaller bouts of studying, rather than cramming.
  • Thus, we have daily quizzes.
  • These are administered using a clicker-like system.
  • To avoid having to pay for a clicker, we use Canvas quiz questions with a custom application we wrote in-house (Cahoot named because it uses Canvas to do Kahoot...).
    • The front-end hack of our code: https://gitlab.com/classroomcode/cahoot
• The goal of these is to create incentives for the following actions:
  • Showing up to class!
  • Regular distributed studying and reading rather than batched cramming; the easy daily questions are on pre-class reading material being lectured that day.
  • Staying awake in class...
  • Reduced-stress assessment of your understanding of material: less painful grading
• You will need to have a web-capable device in class (Android phone/tablet, iPhone/iPad, laptop, CLC computer, ChromeBook, Pinebook, etc.). This is a fair expectation for the following reasons:
  • Most students have a smart-phone or laptop.
  • If you do not, classes already require students to pay for (or worse, rent...) a clicker (45+ USD), and one can obtain a web-capable Android smartphone (a.k.a. WiFi-capable prepaid "burner") for around 20 USD at local stores such as Kroger, Walmart, and most gas stations, without a service plan (you merely need WiFi, which is free on campus).

Quiz grading

• Our free web-based classroom response system (CRS) questions will be treated as daily quizzes.
• Grades are assigned based on correctness of responses given within the time-limit.
• If you miss class, you will miss the points for that day.
• I will usually drop numerous of these questions, in case the system had bugs, your finger slipped, you missed class for excused reasons or not, etc.
• There are several ways to do well on these quizzes:
  1. Come to class.
  2. Do the reading on the topic to be lecture, BEFORE CLASS.
  3. Come prepared with your web-capable device.

Technical and programming assignments

• You should expect around 1 significant technical assignment every 1-1.5 weeks

Coding Tips

• All of the functions in header files we provide must be completed as directed by the comments.
  • Changes to function names or parameters may mean we cannot properly grade that function, and you may not receive any points for it.
  • Do not edit any header files unless we say so explicitly!
  • If there is any doubt, do not edit the header files.
• Carefully read the comments of each member function, noting both return values and output statements (they are not the same!).
• Develop your classes and/or functions one at a time, starting from the simplest modules.
• Move to the next function only after the previous one has been tested.
• Trying to code the whole class and then remove the bugs afterwards will likely prove to be too big a task.
• Build your own simple test cases.
• Print plenty of status messages to track the progress of your algorithm (and remember to comment them out before submission)
• Using Windows or online web-based compilers can come back to bite you...
• Stick to local IDEs that are Linux compatible, for example within the class VM.
• Use the supported language and version (e.g., python3 not python2, gcc-c++ not MS-visual-studio C++)

• This is true in coding as in chopping.
• Resist the urge to start coding right away.
• Spend 90% of your time preparing, and 10% coding, and you will spend less net time!
• Attempt to spend 10% preparing, and 90% coding, and you may end up never understanding, and frustrating yourself, and wasting your time
• If I want to learn a new protocol, language, etc., I spend 90% of the allotted time on learning (studying), and 10% on producing the product (the assignment).
  • Time pressure can get to one's head, encouraging the opposite, trying to complete the product first, before learning.
  • Resist that urge!
  • The time to complete each of these typically takes 2-5 hours for a top-30% grade student, about 10-25 minutes for myself, and maybe 30 min-1 hour for my TAs.
  • Spend time on preparation not production!
  • Spend time enjoying learning the material, not anxiously getting through through the assignment!

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
   • Classes:DataStructuresLab:Content:03-VersionControl

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.

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

Execution of Bash programs

• We use bash, not dash, ksh, etc.
• Some other shells like zsh are nice, but bash is standard.
• All code for my classes must be auto-formatted by shfmt with the following arguments.

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

Execution of Python3 code

• All code for my classes must by type-hinted (Python 3.6+); this is enforced by mypy (below).
• All code for my classes must be auto-formatted by black.

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

Execution of C++ code

• We use C++ 11 and 14+ features.
• If you are using an old computer (campus machines), then you may need to specify a higher version: -std=c++14 or -std=c++11
• If you are using the class VM, you do not need to include version options at compile time.
• All code for my classes must be auto-formatted by clang-format using the following arguments.

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

Execution of Rust code

A breath of fresh air:
cargo run

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

• Identity (name) function included (if required).
• Files should be in UTF-8, Unix/Linux delimited (which if you used solely the class VM Linux environment without copy-pasting from your host OS, you should be fine)
• Make sure to download and use the sample input and output text files we gave, not the text copied into a new text file you made.
• Your program compiles and runs in the specified Linux environment
• Check that file names match requirements and/or have not been changed
• Are you testing your execution with unchanged header files if specified (by checking the file in an old commit), in case you edited for debugging purposes? You should almost never edit the header files!
• Did you check the program with more input / output test cases than we gave you by generating your own?
• Did you check that your functions all have the right inputs and outputs, even if they also have outputs to the screen?
• Did you push your latest commits and check you can see them online in the Gitlab git-classes interface?

Grading technical assignments

Points / scoring

• Assignments will be graded primarily on their correctness.
• Complete and correct output for every test input case is necessary for a full score.
• A non-compiling, non-running, or crashing (segmentation fault, core-dump, syntax error, etc.) program or script will receive a score of 0.
• We design unit tests so that one can crash and the rest can succeed, so that you can get more points.
• If a program compiles and/or runs, then points will be given for each incorrect test case or output.
• Points may be deducted for:
  • Missing name function (if required)
  • Incorrectly formatted output. (Presentation Error)
  • Memory Leaks
  • Specific types of inefficiency
  • File format issues
  • Any other errors that interfere with run-time our output.

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

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"?

• Correct student code (yours) is:
  • matching the desired outputs,
  • AND does not crash,
  • AND uses the desired mechanism (not just copy-pasting outputs, hard-coding outputs, or tricking auto-graders, which is blatant cheating).
• Correct auto-grading code (ours) is:
  • code that verifies that student output matches or does not match expected output (some of the autograding code is actually fairly shallow and easy).

Assignment feedback

• Feedback for programming assignments will be pushed to your repositories hosted at:
  • https://git-classes.mst.edu/
  • Feedback is often automatic upon push via CI/CD (above).
• Feedback will be pushed once for the first round of grading, and if and only if the assignment is auto-graded, then once after the second round of re-grading.
• Feedback comes in the form of correct/incorrect results for a variety of unit tests on your code.
• Feedback text (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:
  • https://www.libreoffice.org/

Working environment for technical assignments

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

ITextras:ComputerRecommendations

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:
https://en.wikipedia.org/wiki/Docker_(software)
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.

#!/bin/bash

# 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 
./docker_build.sh
# 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
./docker_run.sh
# 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.

Recommended virtual machine

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:
Classes:DataStructuresLab:Content:00-VirtualMachines

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:

• The class environment is likely similar enough.
• If you want to skip the VM (and are not in Security), you can do so.
• If it breaks an assignment grading, talk to me after, and we can fix your grade.

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

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

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.

University-wide statements

Statement about Copyright, FERPA, and Use of Recording of Audio/Video

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/

Artificial Intelligence

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

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:

https://www.nytimes.com/2020/04/08/well/live/coronavirus-face-mask-mistakes.html

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.

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/

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

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.

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.

Classroom Egress Maps

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/