This 1-credit seminar is designed to teach the essentials of using a computer effectively for EECS students. While the target audience is CS/CE/DS students, any student wishing to learn how to use their computer much more effectively is encouraged to join. Topics covered include shells, environment, scripting, Makefiles, compilers, debugging tools, and version control. The last month of the course will be open to student input for remaining useful topics to cover.
Updates
Course Pre-Requisites
The only enforced pre-requisite for this course is ENGN 101/151 or EECS 182/183, however it is advised that students have either taken or are concurrently enrolled in EECS 280. A basic understanding of programming (if/else, for, while) and a passing familiarity with a compiler and command prompt is the only expected background.Syllabus & Essential Info
Course Staff
Pat Pannuto | Marcus Darden | Max Smith | David Snider | Waleed Khan | Matt Terwilliger | Alex Chojnacki | Mo Hussein |
Course Resources
Course Q&A / Forum – Piazza
Assignment Submission & Grades – Gradescope
To borrow a CSE laptop for the semester, contact Don Winsor at don@umich.edu.
For general issues, e-mail the course staff at c4cs-staff@umich.edu. For sensitive issues, please e-mail me directly at ppannuto@umich.edu.
Course Meeting Times and Locations
- Section 003
- 1571 GGBL, Friday 1:30-2:30
- Section 004
- 1571 GGBL, Friday 2:30-3:30
- Section 005
- 1013 DOW, Friday 11:00-12:00
In general, you may attend any section, however if the classrooms become overfull, we will have to ask that you attend the section you are officially registered for.
Syllabus
Topic | Lecture Materials | ||
---|---|---|---|
Week 1 | 1/8 | Welcome to Computing for Computer Scientists
|
Slides Video |
Week 2 | 1/15 |
Shells and environment, basic scripting
|
This week's lecture focused on “the job of a shell”, specifically how programs are launched. The lecture format is a bit of a “choose your own adventure” as students in class ask questions. The 11 and 1:30 lectures spent more time and detail on the window manager and 2:30 lecture went a little more in depth on the behavior of the shell and environment. Lecture (11a-12p) Lecture (1:30p-2:30p) Lecture (2:30p-3:30p) Note: The tool I used to capture my terminal input and output from the afternoon lectures was not the best, it is a little hard to read. I apologize for that, I will try to find something better for future weeks. |
|
|||
Week 3 | 1/22 |
Editors Lecture
Homework
Advanced
|
This week's lecture focused on “editors”. Lecture opened with an example of an editor most people do not often see or use, a hex editor, and demonstrated how we can edit compiled binaries directly to change their behavior. Then we played with one of the first text editors, ed. The homework explores how some of ed's interfaces live on today. From there we talked about the mental model of a software developer when editing software and how editors play into that. Finally, we closed lecture with a discussion on the distinction between text editors and source code editors, which of those are included in Integrated Development Environments (IDEs), and whether that is the right choice. The advanced homework explores how to bridge this gap in both directions, from source editor to IDE and from IDE with text editor to IDE with source editor. Lecture (11a-12p) Lecture (1:30p-2:30p) Lecture (2:30p-3:30p) I used two terminal windows to show things side-by-side during lecture. If you are reviewing the terminal output, I recommend opening both and scrolling in parallel. |
|
|||
Week 4 | 1/29 |
Revision Control Basics & Git Lecture
Homework
Advanced
|
This week we introduced version control. We talked a little about what it means to be a version control system, what the fundamental primitives of version control are, and showed at the very end the powerful constructs you can build on version control. We spent the bulk of lecture doing a deep dive on the basic operation git. We start by introducing the three major logical concepts in git, the working directory, the staging area, and the repository. Next we explore how the various commands move changesets or diffs between these three places. The major commands we covered were status, add, reset, commit, checkout, and diff. Lecture (11a-12p) Lecture (2:30p-3:30p) |
– – – |
|||
Week 5 | 2/5 |
Shells II, Unix Tools & Philosophy Lecture
Homework
Advanced
|
This week opened with a recap of commmand that have been encountered by the course thus far. Stay tuned for a post about that coming soon. The focus of lecture this week shifted a little to trying to learn how to learn about a new tool. Specifically, we started from the notion of, given that tr is a “cool command” that you should learn about, what are the effective ways to learn about how a tool behaves? At the end of lecture, we explored how we can chain together individually simple commands to build powerful constructs. The homework explores this topic is a guided manner as well. Lecture (11a-12p) Lecture (2:30p-3:30p) |
2/19: Minor corrections to the solutions. |
|||
Week 6 | 2/12 |
Build Systems Lecture
Homework
Advanced
|
This week we focused on build systems- which sound crazy complicated, but are actually built realized by simple concepts like graphs and variables. In lecture, we started off by asking "What is a build system? Why do they matter? What do they help us do?" In the simplest case, a build system allows you to save build or compilation commands to variable names like 'all_tests' or 'submit'. This saves us from trying to remember the gcc arguments for each type of executable or test we want to make or run. In class, we focused on the 'make' program, which is a build system everyone should be familiar with from 280 and 281. We talked about the syntax of 'make' in terms of targets, dependencies, and rules, and demonstrated it's behavior with a quick example composed of shell scripts. Lecture (11a-12p) Lecture (2:30p-3:30p) |
|
|||
Week 7 | 2/19 |
Debuggers I Lecture (lecture notes)
Homework
|
This week we talked about debuggers, specifically the gdb debugging utility. This lecture is a little different as early labs in other EECS classes have already introduced gdb, so everyone should already have at least a passing familiarity with gdb. What we try to go through in lecture then is to understand the primitives that gdb provides – the way that gdb lets us examine and modify machine state – and how to stitch those primitives together to debug. Said differently, recall that debugging is essentially a search problem: At the beginning you have a program starting to run with some inputs and at the end you have the final state with the incorrect outputs. Tracking down a bug requires finding when between a program's beginning and end things went from being correct to incorrect. A debugger, such as gdb, is a tool that lets you stop and examine any point in time between the beginning and end. It is up to you, however, to point the tool to the right points in time in order to identify where things went wrong. If you were unable to attend lecture this week and are watching online, I think the afternoon lecture was slightly smoother this week and recommend that one. Lecture (11a-12p) Lecture (2:30p-3:30p) |
|
|||
Week 8 | 2/26 |
Optional Lecture: Building Basic Continuous Integration Together as a group, we're going to do Advanced Exercise 5. The end result here is pretty awesome. Every time you commit some work, in the background, your code will automatically build, run all test cases, and run some static analysis (tools that help catch bugs without even writing tests!). When it's all done, it'll pop up a nice notification letting you know how things went. |
This lecture was a little more intimate, in honor of spring break. During class, we went through the thought process for how to approach and complete Advanced Exercise 5. Posted here is a cleaned up and commented version of the script we built in class. Lecture (1:30p-2:30p) |
No homework, enjoy break! | |||
Week 9 | 3/11 |
Using Git Effectively Lecture
Homework
Advanced
|
This lecture digs into git, trying to understand what's going on underneath the hood. We introduce the concept of branching and show how it affects history. Next we introduce merging, which bring branches back together. Then we introduce the concept of remotes and show how remote repositories are really just the same thing as branches. What we sadly did not quite have time to get to in class was the key git philosophy: commit everything and commit often. Some folks stuck around after the last lecture to go a little longer and talk through some of these ideas. The key thing is commit little pieces of progress. It is easy to get in a trap where you feel like you do not want to commit something until it is working. But if you only commit 1,000-line changes after you have everything, then you may as well not be using version control! In the supplemental lecture, we introduced the concept of feature branches. The idea is that when you start working on something new, you can create a new branch for that feature. Since this branch is not yet part of the offical history, you should not feel bad about making lots of little commits as you get little pieces working. Once you get all of the way there, you can re-write history! We also built up a small collection of tips and tricks to make working with git more enjoyable. Lecture (11a-12p) Lecture (2:30p-3:30p) Supplemental Lecture (3:40-4:20p) Preliminary Lecture Notes – Git Niceties |
|
|||
Week 10 | 3/18 |
Profiling Lecture
Homework
Advanced
|
A lighter week this week, we talked about profiling. Profilers are tools that help you understand where your code is spending its time. Profilers are not debugging tools. Your code needs to work and work as expected before a profiler will be useful. Profiling is the last step, optimization to help figure out how to improve your code. In lecture, we went through an understanding of how to build a basic profiler from scratch, showing the key concepts of operation. In practice, modern profilers do more (check out the advanced homework for some examples of this). We ended lecture looking at how to use the gprof tool, a real-world profiler. Lecture (11a-12p) Lecture (2:30p-3:30p) Preliminary Lecture Notes |
March 21, 5PM: Updated to Revsion 1.1 |
|||
Week 11 | 3/25 |
Scripting without bash “I'm too lazy to do all that by hand, so I just wrote a script to do it” – How??
|
This week we talked about Python. We used an RPN calculator as an example to work through during lecture. Grab a copy of the code here. In lecture, we started with Beyond what we able to present in lecutre, the repository includes
two more complete files, Lecture (11a-12p) Lecture (2:30p-3:30p) |
Advanced Exercise 11 Deadline Extended to Wed, 4/13 at 3PM |
|||
Week 12 | 4/1 |
How to best work on my machine?
|
Lecture this week starts from the idea of a local environment and what that really means. It is not just setting up your machine for “development”, it is setting it up for C++ development, for iOS development, for web development. Each of these environments are unique, and while there are some common threads (editors, version control), ultimately each has some things that make it unique. That idea brings us to the major topic, package managers. These are tools that help manage libraries, tools, building, distribution, or other things appropriate to the environment you are currently working in. Every environment has its own package management system. Ubuntu has apt, Python has pip, Ruby has gems, OS X has the App Store (it's a package manager, really!). In lecture we go over what a package manager has to do to achieve its goals and how it does it. Along the way we examine how package managers differ. As some closing thoughts, we look at how the philosophy of a development environment is changing from the older C/C++ model of a global system development environment to project-specific environments. We introduce the idea of virtual environments, their purpose, and how different tools manage these concepts. Finally we briefly discuss how tools such as Vagrant recapture this virtual environment principle for development ecosystems that do not have it built-in. Lecture (2:30p-3:30p) Preliminary Lecture Notes |
Homework 12 Deadline Extended to Wed, 4/13 at 3PM |
|||
Final Exam | Monday April 4 7:00-8:30 |
We have several exam rooms. Please be sure you go to the right room. Based on the first letter of your uniqname:
|
|
Week 13 | 4/8 |
Digging into IDEs
|
Lecture (2:30p-3:30p) |
|
|||
Week 14 | 4/15 |
11:00 – Mo: Security as a User
1:30 – Alex: VPS / Containers / Etc
2:30 – Matt: How does the Internet work?
|
The 1:30 lecture this week starts off with our very own Marcus Darden winning this year's HKN Best Professor Award. Congratulations Marcus!! Lecture (11:00a-12:00p) Lecture (1:30p-2:30p) Lecture (2:30p-3:30p) |
No homework, good luck on finals! |
Attendance, Grading, and Homework
This course is graded on a straight scale, it will not be curved. Each component is graded independently and then combined into a final grade.
Final Grades
A+ >4.0 |
A [3.67, 4.0] |
A- [3.33, 3.67) |
B+ [3.0, 3.33) |
B [2.67, 3.0) |
B- [2.33, 2.67) |
C+ [2.0, 2.33) |
C [1.67, 2.0) |
C- [1.33, 1.67) |
D+ [1.0, 1.33) |
D (0.0, 1.0) |
F 0.0 |
---|
As example, a student with 19 attendance points, 16 homework points, 3 advanced exercise points, and a 95% on the final exam would receive a final grade of (3.67+3.33+4.0+.95*4.0) / 4.0 = 3.7, 3.7 > 3.67 → A.
Attendance (25%)
Attendance is required for this course. Each lecture will begin with a question from last week’s material. A correct answer is worth 2 points, an incorrect answer is worth 1 point, and no answer is worth 0 points. The week before spring break is optional with no attendance taken. The maximum possible attendance score is thus 13 x 2 = 26.
A+ (4.33) | A (4.0) | A- (3.67) | B+ (3.33) | B (3.0) | B- (2.67) | C+ (2.33) | C (2.0) | C- (1.67) | D+ (1.33) | D (1.0) | F (0.0) | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Attendance Points | 24‑26 | 20‑23 | 18‑19 | 16‑17 | 14‑15 | 12‑13 | 10‑11 | 8‑9 | 6‑7 | 4‑5 | 2‑3 | 0‑1 |
Homeworks (25%)
There are 12 homeworks in the course. Homework is due by the beginning of the first lecture the week after it is assigned. Homeworks will be graded on a {0,1,2} scale:
- 0 points
- No / very little effort
- 1 point
- A solid effort, but not complete
- 2 points
- Completed successfully
This is a 1 credit course and the homeworks are designed to be commensurate with that. The goal of the homeworks is to reinforce concepts introduced in lecture and to give hands-on experience working with tools.
An A student will have at least 18 total homework points (e.g. 6 1's and 6 2's).
A+ (4.33) | A (4.0) | A- (3.67) | B+ (3.33) | B (3.0) | B- (2.67) | C+ (2.33) | C (2.0) | C- (1.67) | D+ (1.33) | D (1.0) | F (0.0) | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Homework Points | 22‑24 | 20‑21 | 18‑19 | 16‑17 | 14‑15 | 12‑13 | 10‑11 | 8‑9 | 6‑7 | 4‑5 | 2‑3 | 0‑1 |
Advanced Exercises (25%)
Each homework will have at least one advanced exercise option. The intention is to give a guided exploration of topics that people find most interesting. These advanced exercises will also be a little more time consuming, have a little less guidance, and require you to research and discover a little on your own. Over the course of the semester, you are expected to do at least three of the advanced exercises.
The advanced exercises are graded on a simple 0 or 1 system, either you did the whole thing or you did not. Some weeks may have multiple advanced exercise options, however you may only earn 1 advanced exercise point per week (though that shouldn’t stop you from doing more if you are interested!).
A+ (4.33) | A (4.0) | B (3.0) | C (2.0) | F (0.0) | |
---|---|---|---|---|---|
Advanced Exercises Points | 6+ | 3‑5 | 2 | 1 | 0 |
Final Exam (25%)
The final exam will be cumulative over all of the whole term. We have a 90-minute time slot for the exam. This is a very broad course. The exam is not designed to be “tricky” or test the esoteric corners of things presented in lecture. A student who attended every lecture and completed all the homeworks will likely need minimal studying for this exam.
Useful Links / Resources
- comp.lang.c FAQ: Next time you're bored, don't facebook, reddit, or google+; instead skim a section. It's really interesting material, presented in short, easy snippets
- Stack Overflow: Got a problem? Try searching here instead of Google. Odds favor this site will be the first result anyway, and it's answers are much more complete, readable, and useful