Mike Hewner's Homepage

I’m a big believer in practice when it comes to learning programming techniques. Although this seems obvious, it tends to go against the grain for most developer/teachers (like me) who love cool projects. What’s the best way to learn (say) scheduling? Write a scheduler! Our students did write a scheduler in OS, but they probably spend 90% of their time dealing with weird C mistakes and about 10% actually thinking about scheduling. More importantly, they only wrote 1 scheduling algorithm. If you really care, they have to write 10 scheduling algorithms. I didn’t care that much about them being able to code schedulers, but I did care about them being able to use semaphores. So I needed a bunch of tiny semaphore assignments. I’m sure I’m not the first teacher to do so, but I couldn’t find ones online when I looked.

So here’s a bunch of small problems that use semaphores. Some of these I used as 2 semaphore homework assignments, some of these I used as semaphore exam questions. If I were to try and arrange them easy-to-hard, it would be: threeAndTwo, abcd, hammerAndSaw, littleRedHen, balloon, printerQueue, producerConsumer, pair. Solutions are available too, if you email me.

Thanks to Ian Ludden who write littleRedHen and balloon for me. Also, a shout out to Allen B. Downey who’s awesome free book The Little Book of Semaphores is maybe the best treatment of the topic I’ve seen. I would love to go through that entire book in my class, but there’s not enough time in the current incarnation.

If you have any problems of your own, please send them my way! My students could use the practice!

(Contains 10 attachments.)

This spring I decided to try something I’ve been mulling over for a long time – a 1-credit course in GIT. 1-credit CSSE classes at Rose tend to be minor affairs…generally just for student fun and not affecting graduation. Of course, we already use git in many classes at Rose-Hulman, but you usually can’t cover anything in more detail than basic checking-in, checking-out, and conflict resolution.

10 classes was a bit on the longish side…I think you definitely could have done the topics in 7ish-classes if you wanted to compress, and the curriculum will always tighten with time. I do think that it’s wishful thinking to expect students to be good at git with just a lecture or two and some sort of highly structured tutorial.

The design of the course also was a challenge. Lecturing about command line tools is not usually effective – you have to use it to get good. I toyed with the idea of making a series of broken repo states that the students would have to fix/debug, but decided it would be too much work (if anybody would like to help me by make a library of 45 or so….feel free to get in contact with me, I still think that could be good). What I decided on was lectures, supplemented by a textbook (Git Pro), followed by weekly programming assignments were students had to write scripts that used git commands (and parsed the output). This was a course for moderately senior students who had used the basics of git and could pick up a new scripting language easily.

Git homework assignments:

• Plumbing 1 – grep for strings in particular trees (apparently git grep does this automatically but no matter)
• Plumbing 2 – make a commit history from a series of SHAs
• Reset and Stash – 3 little scripts involving the commands
• Merging – automatically merge two branches in a crude way
• Rebase – rebase but show what commits change shas
• History Rewriting – a simple interactive rebase and a use of filter branch
• Branches and Push/Pull – pull all local branches to a remote
• .gitconfig – write your own gitconfig

(solutions are available if you email me)

Overall, I thought it worked pretty well. I’d like to maybe refine a few of the assignments and maybe get some more in class activities. I’d even like to do an “exam” – probably not for student credit, but just so I can assess how well this is all working.

The students also generally seemed to enjoy the class (well, I had a few drop out because they didn’t want to do the homework, but that didn’t stress me out particularly much). I’ll know a little more when student evals come back in a few weeks.

My complete lecture notes are here, if you’d like to use them for something.

Anything I missed that you would cover in your 1-credit git class? Any great ideas for assignments (they should be easy to code, and exercise the commands under question well)? Comments welcome!

So I haven’t had much opportunity to post about my classes at Duke, but it has been very cool. I’ve found students at Duke to be very conscientious and smart, and my office hours have been very busy which is always fun. Of course there’s still plenty of the usual student foibles to contend with – but if students were virtuous and self-motivated all the time, I’d probably be out of a job.

This semester I’m co-instructing CS100 – a data structures course that occurs as the second course in a CS major but also accommodates a good number of non-majors. One of the perks of this job has been the opportunity to observe my co-instructor Owen Astrachan’s lectures. Owen definitely has one of the most refined lecture styles of anyone I’ve worked with – he’s got a whole repertoire of jokes, dances, and asides to keep students engaged. Not only do these little diversions keep interest in what can be a fairly lengthy 80 minute lecture, but I think it sets the tone of the course as much more relaxed and fun than what you get just looking at the webpage alone. I definitely have some work to do in getting myself to Owen’s level, lecture-wise.

But in my own lectures, I’ve been very self-conscious about designing each class myself. I take my cue from Owen on the content covered, but I have my own ideas about how to convey them best. My experience suggests that you’re much better off designing your own class and making your own mistakes. Standing up in front of the room holding some other professors notes (no matter how brilliant) is gonna guarantee a medicore class at best. If you design the lecture with a modicum of care yourself, even if it goes completely off the rails you’re likely to do better.

Of course, once you get out of that “off the rails” class, you might take a few hints from the experts and change your style appropriately.

But, after a semester of this, I think I’ve got a structure I’m happy with for this large lecture style class. Here’s how I do it:

1. Prep work. Because most of the lectures I teach are officially considered 160-person, lecture-style ‘recitations’ I’ve been able to get away with requiring students to do a 1-hour-ish prep for each class (which I always collect and check for participation). This is just as awesome as you’d expect. Sometimes I use this as a review of topics covered elsewhere I don’t have time to do in class, sometimes I use it give students an example of the kind of problem we’ll be doing more of in class, and sometimes it’s an introductory problem that I’ll build off in class.
2. As you sit down. I always give students something to do as they sit down and get ready for class, which I put on the powerpoint as they arrive. Students are somewhat blase about actually doing it (bad)…but I still like it insofar as it sets the expectation that you are already in your chairs and working the minute class begins.
3. Running slides that convey the learning objectives. I know a lot of older professors scoff at the idea of learning objects that you spec-out in class, but I love ’em. Mostly, it focuses me when I’m planning the lecture to decide exactly what I want to cover, keeping in mind that if students learn more than 2-3 things in class it’s a miracle. But I also like making it explicit to the students what my plan is: we’re not just having a chat, if you have finished class and you don’t know 1 2 3 then at least you know what you ought to be looking up. My slides always look like “After class today you will be able to … 1 provide the definition of words a b c 2 code programming problems of type d 3 explain why the efficiency of e is f. Then at the appropriate points in the lecture I have sides that are like “At this point in the lecture you should 1 know the definitions of a b c *next up is* coding programming problems”.
4. Active learning regularly. Wherever there’s a concept that’s important and they won’t grasp it immediately, I have some on-slide multiple choice. If I feel like it would be better served in some other way, I’m also willing to have a worksheet students fill out in class. But usually multiple choice with hands works. Only trouble – not every student participates in the in-class multiple choice, and it’s often hard to know when we are done and we can begin discussion. I’m considering clickers for next semester.
5. In-class coding. For a class like this which coding is a large part of the final goal, I like to have at least 1 in class programming exercise that the students submit (Duke has a great system that makes submission very easy). For one thing, it breaks up the 60-minute-doldrums…I feel like I pretty much have to move out of the lecture mode and force students to work on a problem that takes at least 10 minutes without my direct intervention. For another, it clarifies how what we just talked about will relate to the actually nitty-gritty of their assignments tests and projects. The key difficulty here is difficulty…students are very willing to stare blankly at the screen, not asking for help for 10 minutes. I’ve had some luck with providing a range problems…implement 1 function where you only have to write 1 line in my pre-written code, another where you basically copy the first and change a couple things, and a third that’s a new variation.

So yeah, nothing fancy but it has been working well for me. If you’re curious in practice, here’s a video of my class on trees:

(Contains 3 attachments.)

The second class I taught at GHP was Theory of Computation (entitled “Does Not Compute”). We approached the problem of machine equivalence. This class was a lot of fun and students seemed to enjoy it. You can , if you’re curious.
Continue reading ‘GHP Theory of Computation Class Summary’ »

Ok, so my good intentions to blog weekly about my teaching at GHP didn’t quite happen. It really is amazing exactly how intense teaching at GHP is, at least for your first year. Between majors, minors, all the various side projects, helping students after hours, and then prepping classes you are basically working every minute 7am-11pm (or later). After a while, it got to where I started daydreaming about taking naps. But I really don’t want to sound like I’m complaining…GHP is definitely one of the coolest teaching things I’ve ever done. But not a lot of blogging time.

So, here’s what I did in my fractals class:

Continue reading ‘GHP Fractals Class Summary’ »

Mark recently asked me to teach a guest lecture in his Media Computation data structures class.  The lecture was an introduction to the Simulation engine Greenfoot.  The goal was to introduce the idea of simulation, toss out a few key bits of terminology to prep students for later classes, and get students playing with the Greenfoot engine.  The course was 50 minutes for a class of 25 (though, in practice only about 15 or so showed).

Mark gave me some slides, I made a few modifications:

• I moved a few of the definitions to the end of the lecture.  Mark said the main goal was to get them playing with Greenfoot, so I figured I’d get to them if we had time.
• I turned a few question slides into concrete student activities.  Mark may have intended that…I adjusted them to my taste (mostly putting them in a multiple choice format so it was clear to students that would be accountable for the answers
• Cut a few slides, replaced some of the code heavy slides with live coding…once again could very much have been the intentio

What Went Well

Students responded well to the activities.  They also quickly warmed up to me, responded to my jokes, seemed to pay attention.  Reintroducing humor into my lessons has been a goal of mine, so I was happy with that.

What Went Poorly

We ran well over time, didn’t even finish the main coding activity (got to a chunk of it).  What made me feel especially dumb was that I wasn’t keeping close tabs like I should so I didn’t even adjust properly.  I was really glad I moved the less key slides to the end.

Part of the problem was I wasted time on the code reading activity.  The other issue was keeping the students in sync with me as we went through Greenfoot took a lot of time.  Very often I had to go back because somebody didn’t see how I added walls to the simulation or whatever.  In retrospect, I think I would have taken a page from Just in Time Teaching here…get the students ready to rock with a small tutorial assignment beforehand, so you can dive right to the interesting stuff in class.

But, excuses aside, letting class time get away from me was really bad and there’s really no reason it should have happened.

Tidbit

As is my custom, I had students fill out feedback forms.  This time though, I included a few content level questions on my forms:

1. Why do Computer Scientists think building simulations is a skill almost anyone could benefit from?
2. What is the difference between continuous and discrete simulations

I handed out these forms at the beginning of class.  I was curious to see if the students would answer them as they went or do it at the end.  The result was they did both, but I think either way it caused the students to pay more attention to what was going on in the definition part of the class.

Feedback

.

My Slides

My slides.  I made it to slide 25.

So today I taught a database class in the Rapid Prototyping course I normally TA. This class is three hours long and when the schedule calls for a lecture it is brutal. This being my second time at the podium, I was somewhat prepared. I structured the class into lectures interspersed with various activities: a semi-multiple choice worksheet thing, some group work on a DB schema design, a fairly long section of independent/group coding on some SQL challenges, and then a live coding section with me at the helm (and them, at least in theory, coding along with me).

Overall, I think the lecture was good although my jokes fell sort of flat. I’m not sure if it was me, or the time in the semester, or what. I think I need to work harder at the onset to establish that there will be jokes, so that people know it’s OK to laugh. As it is, I worry they may be a little stunned and not sure what’s humor and what’s not sometimes. With activities, jokes aren’t as necessary to keep people conscious, but I’d still like to integrate them better into my style.

I think the activities worked well to break up the lecture and as usual they got almost universal positive feedback. I actually asked the students to install software (RazorSQL) on their laptops before class: I was actually gratified to see almost everyone did. It made me think that large scale coding exercises can really work, which is good news because I think it’s easy to let syntax wash over you if you don’t have to fight the compiler and think about it carefully.

As part of my prep for the class, I built a demo app. Basically we talked about 4 different ways to store data (flat file, pickle, XML, and DB) and I wanted them to have example code for each of them, even though we really only went into detail on the DB code. I’m not sure the time I put into that app was well spent; I really underestimated how long it would take to get it written. I sort of hope Keith uses it next year because I think it is a neat reference, even if we really don’t have time to walk students through it. The detailed work I had to do building the database part of it was extremely valuable though; I was able to discover all sorts of funky bugs and discuss them in class.

Stuff:

I’m acting as an unofficial TA for an unusual course this semester: “Rapid Prototyping”. This is a course for students with non-CS background: the goal is to get them up to speed with the basics of quickly building UIs and other apps for research. It’s not a gentle introduction to programming; after half a class on loops, objects, data structures, etc the class move quickly into building Java (Jython UIs and a variety of other fairly tricky topics).

I got the opportunity to teach that “recap of all CS1 (in a different language you don’t know) + building UIs” course. Three hours to cover a great array of topics, going off slides that the main professor prepared. Even just keeping the students semi-conscious for 3 hours is definitely a bit of a challenge (thought these are all graduate students so it’s better).

What I did:

Part 1: Language Intro: The main things I thought about was trying to reach lower skilled students and keep everybody interested for the whole time.

I supplemented the existing sides with 8 exercises designed to highlight what I thought were tricky things. I used my usual “ghetto clicker” technique of having students hold up fingers to indicate solution 1 2 3 etc.

Pros. The initial activities did well: most students had to think a little but in the end most got them right. Plus after the questions I would tend to get a little flurry of questions to help clarify understandings even from the people who did get it. Coding ones seemed to work given the talking and the fact that we could contrast the syntax between correct and what they wrote. This (as usual) also got good feedback in the mini-surveys I passed out. Plus, just helped to break up the lessons a bit.

Cons. Questions about finding bugs proved a bit problematical – I think I need to make it concrete by labeling the lines and asking to pick which one has the bug. Also a problem was knowing when students are done…need a way to figure that out even with the ghetto clickers.

Part 2: Java UI basics: I wanted to keep things practical so I opted for live-coded examples + the original slides.

Pros: Generally this went pretty well and I could hear a little flurry of typing whenever I started so people seemed to be keeping up to type as I did. Might be possible to leverage this into a more hands on activity where not everything needs to be coming from me. Got one enthusiastic respond from my surveys.

Cons: Obviously took some time but I think it was well spent. Major issue here was just exhaustion on my part – 2.5 hours is a long lecture. I think I need to plan more carefully at the end…I tend to plan beginning to end which leaves the end a little weaker. Maybe the other way would be better.

Part 3: Random stuff and talking about the assignment: I followed the notes with this, but it was difficult because it was unclear exactly how things fit together, which stuff was more important. Maybe rushed a bit. I think we could easily have taken the “learn about the assignment stuff” offline…and gotten more time. But what would we have done? If I had to do this again I might have tried to put some longer coding thing in the middle so that both the students and myself would not be so tired at the endpoint.

My Slides!

So working here at GHP, one of the things I get to do is teach seminars. Seminars happen outside of the usual classtime…they tend to be fun special-interest type things. I’m planning on doing a couple but I decided to do the first one on the Unix Command Line. Many of my students have installed Linux. Many even have feelings about which distro is better. But yet most of them have never used the command line. This is very nostalgic for me: ah for the halcyon days of my youth! I made it my business to install every distro yet basically had no clue what one would actually do with a distro once installed. Of course in those days just getting X to work was considered a major achievement.

So anyways I figured they should at least have exposure to some of the cool things you can do with the command line.

I organized it as a “scavenger hunt”. Basically I divided my students into 4 teams and then gave them . The rule was that everyone on the team had to be able to do everything for the team to get credit…when teams called me over I would quiz random team members. This was necessary because we had extremely varied levels of experience…I didn’t want the experienced people just going off and leaving new members to get frustrated.

Basically the whole thing worked like a charm once everybody started working (getting everybody started and on the same page was a bit of a pain). I never cease to be amazed by how much more intense student focus is when they’re working on concrete activities rather than listening to me lecture.

By the end, even students who basically had never worked with Unix before thought the whole thing was pretty cool. The teams basically only got through item 10, but when I asked them who wanted to continue the scavenger hunt next week everybody raised their hands. When I asked them if they wanted to just come back and continue from where we left off or research stuff outside on their own, two of my no-linux-experience girls argued that they just couldn’t wait till the next seminar without playing with it some more.

Funniest thing: a couple of students told me confidentially that they completely understood playing around with the command line for fun, but they weren’t completely convinced that it could actually do anything useful. I found this neat because it seems like normally people feel like command line stuff could be useful, but don’t want to actually go through the bother of learning. That said, I want to provide some persuasive examples next time about how command line stuff can be useful for real.

So unixy friends, here would be two helpful hints I could use from you:

1. What are some simple and concrete things you can do with the command line that even high school students could understand is awesome
2. I could use a few more items for . I compromised with the girls: I asked everybody not to research stuff before the seminar so that all the teams could start on the same footing. But I said that I would make an auxiliary list of challenges for people who just couldn’t wait to play with in the meantime.

So I had a very nice leisurely lecture prepared that talked about the stack, buffer overflow attacks, and C varargs functions. We were going to do a few different activities and maybe even a live coding exercise which I’ve been wanting to try. Then I get an email from my practicum professor saying he wants to cover the stack, C I/O, Buffer overflow attacks, varargs functions, and malloc all in one class session – less than a day before I’m scheduled to speak. That’s over 50 unplanned slides worth of material, jammed into a 90 minute session that already felt a bit disjointed.

I was not feeling the love at that moment.

But what the heck. I figured this would be the sort of real world teaching experience I had been warned about.

Here’s what I did:

• Eliminated some of my more time-intensive exercises, or replaced them with quicker versions
• Cut a variety of content that I felt was less important, and distributed it as handouts + an instruction to read the book
• Created my “exploding kitten” exercise, designed to let me move through the malloc material slight faster. Basically I labeled certain slides with numbered kittens, and as I moved through the students had to record what deadly malloc error each kitten referred to. The idea here was that students would pay extra attention when they saw a kitten, and would know if they missed something so I could go back to it.

All this and I still had to end only 1/3 of the way through malloc.

So looking over my video after the fact, I felt confident that I had completely screwed everything up. But , everything was pretty positive. Most common negative feedback: too much material and too fast. I can’t say I disagree.

Here’s the handouts, the powerpoint for the first part, the powerpoint for the second part.

You can watch me here: (part 1) (part 2) if you’re curious.