Narrative on Week’s Goals

Monday’s Encryption and Steganography lecture was one of the high points of the term, a big finish.

Calendar Entries for the Tenth Week

Lec 7 March: The lecture introduces encryption, briefly touching on the Caesar cipher, Private Key Encryption and an overview of Public Key Encryption, and then moves on to Steganography. Motivated by an example mentioned by Owen Astrachan, the material is taught by example wherein a photo, the guest is embedded into a host photograph to hide it. Because it is a way to ship pictures under the noses of repressive governments, I use a photo of a jubilant crowd in Cairo’s Tahrir Square as a guest photo,

and a tranquil photo of two men fishing on a foggy morning

as a host. After the process is explained, it is implemented and embedded picture is compared with the original. Then the class lines up for a class photo, which becomes the guest for another embedding.

Lab 8 March: Lab 08 is a simple XML styling exercise using XSL. The point is to solidify the ideas of using XSL as a styling agent for XML in order to support the final assignment. One student came to office hours afterwards to get help, but generally they had no difficulty with it, and most finished quickly.

Lec 9 March: This is not a lecture, but rather a walkthrough review of the second half of the term in preparation for the final.

Lab 10 March: No formal lab exercise is planned, but Brandon is on hand to help with the assignment.

Lec 11 March: Canceled due to the teaching staff attending the SIGCSE’s Symposium on Computer Science Education.

And How Did It Turn Out?

Monday’s encryption/steganography lecture was a terrific success. Students were skeptical when I said I would hide a photo in another. The idea of first restricting the photo to two bits per color per pixel worked well, leading to a discussion of the differences. Then, after the embedding the two images were compared – there is no apparent difference. But, because the original used jpeg representation, but and the embedded copy used png representation (to avoid the lossy compresson) there seemed to be a slight shading difference. I’m guessing that the difference tricked one student into claiming that there was a visible difference. This made the tineye.com searches for the host and the embedded photo, which come out the same, a compelling experiment to do. There was a reluctance to come up for a class photo (everyone’s wearing their “finals week” sweats), but in the photo the class is smiling, so I assume it wasn’t too “elementary school”. We embedded the class photo, and extracted it! With a little bit of time left, I passed out the student evaluation forms for them to critique the class.

After class I sent everyone the embedded class photo and told them how to extract it.

Tuesday’s lab apparently achieved its goals, because on Wednesday the students clearly understood the task.

Wednesday’s review, like its counterpart at the end of the first half, left the class in a grim frame of mind. It’s been a long time since I’ve had to explicitly take a test, but this seems odd. I would think it would be positive, because I mentioned lots of stuff that wouldn’t be on the exam, but apparently, I left too much stuff on the list that might be on it.

Thursday’s lab time turned into office hours for Brandon and a few students sought help.

Friday was a free day, though they still had to do the AIS.

The class ended with a bang rather than a whimper. Steganography being so impressive, it was a good way to remind them that they had learned a lot, and that the magic of computers and networks had been revealed, only to be replaced with a more fundamental kind of magic. The public doesn’t even know about recursion or steganography, but they do. Perhaps they seem magical to them, too.

Narrative on Week’s Goals

AI would normally have been taught later in the term, mostly as a “pick up” topic, as it seems somewhat secondary to the big ideas. Moving it was effective.

Calendar Entries for the Seventh Week

Lecture 14 Feb: I augment what I think of as a “standard” introductory AI lecture with Watson-related material. Having chatted with non-techies over the weekend and found that most people don’t see it as a big deal, I decide to give an explanation of why chess is easier than understanding a pun.

Lab 15 Feb: It was an opportunity to work on pair programming with assistance available. Most teams had already been checked off, and so they started work. I check off two more in lab, but still, not every pair has been approved.

Lecture 16 Feb: The topic was the Internet, IP, Ethernet and related matters. The goal, like all of the technology lectures, is to remove the “magic” of networking, and show it as a completely practical and understandable process. The analogies – Cerf’s, IP is like sending a novel by postcards, Ethernet is like a conversation at a cocktail party – make these concepts accessible.

Lab 17 Feb: More time for pair programming with Brandon available.

Lecture 18 Feb: The topic is how the Domain Name System translates domain names like spiff.cs.washington.edu to 128.208.3.136. This is also a chance to talk about physical and logical forms of a phenomenon such as computer names. Finally, it is important to discuss the design issues that arise in creating the DNS, such as robustness, fault tolerance, redundancy, and other systems design concepts. I also include “thinking at scale.”

And How Did It Work Out?

Overall, the excitement about Watson was shared by only a couple of students in class. Generally, most saw it as just a publicity stunt.

Monday’s AI lecture was fine, but I think I failed – and the prep material failed – to persuade the class that what Watson was doing was amazing. Chess still seems to be tougher than puns in their minds. The topic of AI is always engaging; they immediately landed on emotions as a stumper topic for the Turing Test. The creativity part of the lecture was less effective than in previous classes I think, possibly because they had struggled enough with Albers that it had become a painful topic. I don’t know.

Tuesday’s pair programming engendered a lot of apparent enjoyment in lab. The teammates appeared to be more “equal” when they were the same sex, probably an obvious observation.

Wednesday’s Internet lecture also held the class’ interest. There were questions about interacting with ISPs unrelated to the lecture. The analogies worked, as usual, and everyone seemed to get them.

On Thursday, another day of pair programming … the excitement has evaporated, and now the hard programming and debugging have consumed the students. In conversation, they are definitely positive about it, though.

Friday’s lecture was my first try at an introductory DNS lecture, and I pronounce it a complete success. I had originally thought that I was belaboring the “problem,” since I seemed to be saying it in three different ways. But in reality, it was probably right: They understood what the problem was, and one student essentially figured out the process based only on the underlying mechanisms. The next slide showed that her guess was correct. Indeed, the setup problem that was going to promote more discussion — how can I log in from Miami to my computer in Seattle — kind of flopped, because the class had already gotten the idea, and why belabor it?

My cartoons of the idealized authoritative name servers – one for a domain of machines and one for a domain of domains – seemed to be easily comprehended.

Diagrams of the two extreme cases for authoritative name servers.

On balance it was a very positive week. The pair programming is getting rave reviews from virtually the whole class (apparently, one pair are dissenters). And the pace is more civilized, too.

But, without a doubt the best part of the week was that I got a lot of face time with the students. First, they had to come in in pairs to discuss their project. This was fun because they only had to explain it, and it was fun to joke around about what they are doing.

Also, they came in one at a time to correct their mid-term tests. (At Susan’s suggestion, they were allowed to work out the solutions to the problems they missed, come in with the correct answers, explain them to me and get (up to) half credit restored.) Though I was initially skeptical, this turned out to be a tremendous benefit in terms of finding out first hand what they understood, and what they didn’t. Also, in a couple of cases where they still couldn’t do a problem (usually the function for figuring total money in dollars from a bunch of coins), I would step through the process with each one. This exercise (which was really valuable) showed me that I need to emphasize still more that thinking of the computation from the code’s point of view is essential. I doubt it can be over-emphasized.

Narrative on Week’s Goals

The weekly calendar shows that Monday was the midterm exam, and students got Tuesday off, since they have been working so hard.

Calendar Entries for the Sixth Week

Midterm 7 Feb: Being at an ACM Education Council meeting over the weekend, I’d selected this day for the mid-term. The exam was mostly short answer and a few multiple choice questions tossed in. I had allowed each student to bring a single, handwritten sheet of notes to the exam to thwart the anxiety of “memorizing” stuff.

Lab 8 Feb: Class canceled.

Lecture 9 Feb: The topic was Algorithms, and I believe it is now generally less intimidating than it was a decade ago. Students have apparently heard it a lot. I gave the standard Knuthian definition, and then moved on to recursion. My goal was simply to explain it without making it into any sort of big deal. (There had been a request for everyone to return to the Lightbot recursion problems as a refresher.) Standards like fact( ), fib( ), sierpinski( ) are given. The scoping of formal parameters is explained in order to show how recursive functions are executed. Finally as an antidote to the orderliness of sierpinski( ) I show a Processing Reference Library program for recursive random circles. The first three levels are easy to see.

Recursive random circle program from the Processing reference library.

Assignment 14: The assignment is to use a program for a recursive enumeration as the basis for a different recursive enumeration. The purpose is to work from a closely related program as a guideline.

Lab 10 Feb: Time to work on the recursive enumeration with Brandon’s help.

Lecture 11 Feb: The lecture asks the question, how do you know that your program computes what you think it does. This is a “correctness” lecture, and I use sorting for the purpose. The main point is emphasized by noticing the comparison patterns of Exchange sort and Bubble sort; they are different, but each is the basis for arguing that it works as claimed.

With twenty minutes of lecture left, Susan takes over to present the concept of Pair Programming, and to introduce an assignment that uses the methodology. Using the responses from a survey collected in the previous lecture, she assigns pairs based first on matching their abilities, and secondly on finding compatible schedules so the teams could meet.

Assignment 15: Pair Programming. Develop a game using processing. Any game is OK provided it isn’t beyond the team’s programming skills. First the game has to be developed on paper, and treat the following topics: rules, description of play, clear way to win, clear way to lose, and how the game can be restarted without being rerun. The plan must be approved by someone on the teaching staff. The teams can only work on the computation when they are together, and only one of them is allowed to type. Goals include learning how to describe computation to a colleague.

And How Did It Work Out?

Monday’s midterm exam showed that students had acquired a good understanding of factual material, could write a standard Processing program (essentially, a portion of their second lab on Processing), and are still struggling some with details of functions, such as using void when there is a return value. Among the remarkable-to-me results was that all students got all points on the binary addition question, implying that I don’t have to ask that one again. (More analysis of the exam when it’s in.) The single sheet of notes worked well.

Wednesday’s recursion lecture was reportedly engaging by a substantial portion of the class, which was my assessment, too. The goal of presenting recursion without making it so important that it becomes something to panic about seems to have been achieved. It was a waste to explain the formal parameter scoping needed to explain why recursive programs “work”. No one was interested in it. I won’t do it again.

(In this class especially considering that the material is (to me) fascinating, and deep, there is always the issue of when to “quit”. I believe explaining parameter scoping is not the first time I’ve crossed over the line this term, and a postmortem would be indicated to find other instances.)

Thursday’s lab was frustrating for Brandon because the students were supposed to use strange UTF-8 characters () and there are apparently bugs in Processing’s ability to include these in a computation. Most students got it to work, but that complication coupled with the student’s habit of not reading the instructions, kept it from being the “programming by analogy” success I was hoping for.

Friday’s lecture was extremely satisfying. The students followed along well, and I was able to make the “know why your code’s correct” point without the dreadful detail used in, for example, the Fluency with Information Technology book, Ch. 10. The key was to use schematics of the traces of the binary comparisons.

Comparison Patterns for a 5-element Exchange sort (l) and 5-element Bubble Sort (r); time goes down.

I believe these two diagrams effectively made the point that algorithms operate differently, but there is an abstraction for any one of them that can be used to reason why it is does what’s claimed for it, i.e. sort.

OK, so students were following along, and I was making my points. But when Susan took over to do pair programming, the whole behavior of the class changed: they straightened up, paid close attention, answered and asked questions. They became the definition of engaged!

Thanks to her, the week ended on a high note. We entered a new regime with more time for assignments, more discussion, and more variation in what we do. It’s more relaxed. This has been greeted with approval.

Narrative on Week’s Goals

The weekly calendar shows that Friday’s assignment received a 1-day extension, and the other two assignments this week got the same treatment.

Calendar Entries for the Fifth Week

Lecture 31 Jan: The first part of the lecture continued the coverage of functions from last week, including why one would use them and the details of parameters, arguments

and the “formal/actual correspondence” relating the two. This had to be added to the plan because of having forgotten to handle the parameter details on Friday.

The listed topic was the fundamental principle of information, which I call, “The Bias-free Universal Medium Principle.” It says that bits are sufficient to represent all digital information. We have covered content relevant to this principle in several lectures, so mostly the lecture summarized that content.

Assignment 12: Students create a GUI with two buttons (Pal and Clear) plus a line where text is displayed. They are to accept text input and when the user clicks the Pal button, the text is to reverse, so they can see if it reads backwards as a palindrome. This is an exercise to learn about text input (more complex in Processing than graphics), and the three data types, char, String and String[], which will all be needed for the next assignment.

Lab 1 Feb: Students work through a lab in which they write a series of value-returning functions based on 13^th Century wine merchant measures noted by Knuth: http://www.burtonmackenzie.com/2008/01/legend-of-binary-wine-merchants.html They compute the metric weight of a liquid measure by computing the weight of it’s defining measures and adding it to itself; the basis is a gill at 118 g. Brandon then explains how the function calls are executed.

Lecture 2 Feb: Realizing just before class that everyone seemed to be struggling with Assignment 12, I decide at the last minute to begin with a chalk-talk about how the computation works, and a summary of the properties of the data types: char, String and String[]. The lecture is on computational complexity. The lecture begins with linear time and ends with the halting problem; exchange sort is a concrete example of a polynomial computation.

Assignment 13: The computation shows a pond in which a turtle can be programmed to swim around, avoiding the whirlpools and going for the sunny rock. This assignment is a primitive version of the LightBot problem used on the first day. Friday (the due date) is the last day of the first half of the term, meaning that the students will have gone from users of the game to implementers. If it isn’t too hard!

Lab 3 Feb: Students have lab time to work on the turtle assignment, with Brandon’s assistance.

Lecture 4 Feb: Realizing that the turtle is at the screaming edge of the class’ ability, I decide to begin lecture with a review the logic of the turtle computation. After that the Halting problem, which spilled from Wednesday, follows. And finally, I review the high points of the course to this point in preparation for Monday’s midterm exam.

And How Did It Turn Out?

Overall, the week was our first tough one. The students are busy with other classes – freshman chemistry was having a midterm, and the relentless pace of the class was beginning to show on everyone, including me.

Monday’s lecture began covering parameter passing to recover from having omitted it with the revised presentation Friday. Susan had also recommended that I explain more directly the point of functions, which seemed curious since Friday we’d built a timer and the students had just built the Sudoku GUI using functions. It was a good thing to do, however. Parameters were received curiously – the class seemed uninterested in them. I figure that students are in one of two camps: those who had figured them out on their own, and those who were not far enough along to understand what they were doing; I can identify specific students in each group. Nevertheless they have all used them extensively now, so operationally, they know what to do.

Regarding the “bits are the thing” main lecture content, I had the sense students were thinking, “Duh,” given that most of the components of the principles came from earlier lectures. We need to state the principle, but it won’t need as much buildup next time.

Tuesday’s lab was successful, reinforcing the value-returning functions and parameters using the binary wine measures, gallon down to gill. Brandon explained how functions suspend the execution of the present function and eventually return to continue its execution using this diagram, where red is gill, purple is gallon, and time moves to the right

Wednesday’s lecture started out with a chalk talk on the homework. This turned out to be quite a success in an odd way. I was determined not to solve the homework for them, so I only explained it at a high level. The students paid attention, and then right after class, most of them turned in the homework. What I liked is that my high level description implied a decent understanding of the material we’ve been covering.

The lecture was on complexity: linear time to the halting problem. Given the prevailing exhaustion and stress, I thought students paid attention well enough. But I note that in the summary statistics from the After Image Survey, no student mentioned this lecture as engaging. It is a dry topic for most people, and the amazing aspects of it – NP-completeness, undecidibility – are not so important for beginners. I’m sure it is possible to have a sexier lecture on the topic, but it’s eluded me for quite a few years so far.

Thursday’s lab was time to work on the turtle assignment. I had forgotten to mention a detail about testing equality of strings, which caused a small bump, but only for the better students. One problem with the recent assignments – basically 11-13 – is the unwillingness of students to read the assignment through before starting. Brandon was frustrated, writing to me after lab,

Honestly, I think the students would do a lot better if they would just read the assignment start to finish instead of greedily completing tasks as presented to them.  For example, [two top students] started programming their own logic for interpreting the Turtle commands instead of looking at the flow chart (which contained almost exactly what code to use) [on the last page].

As one of my colleagues remarked, “Not reading the assignment often saves 10-15 minutes at the cost of hours of frustration.”

Friday’s lecture also started with a chalk talk on the homework. This one was not as satisfying as Wednesday’s, partly due to the fact that it wasn’t as well organized, though both were impromptu. After that, the lecture reviewed the content to date. Students were engaged, but not by how cool was the content as they were looking for hints as to how Monday’s test would go.

It was definitely the midterm slump. Despite the tough week, students still found material that they could be positive about in the After Image Survey. Susan’s summary reported few negative comments, but perhaps she is being selective [later, she wasn’t].

My recent plan to be more informal about the class structure, and to open up with more conversation is getting tested as I scramble to explain what is written in the assignment. Am I abetting their habit of not reading the assignments if I go over what I wrote out in the first place?

Narrative on Week’s Goals

The weekly calendar shows that Monday’s assignment was a week of “unconstrained programming,”

Calendar Entries for the Fourth Week

Lecture 24 Jan: The lecture began by cleaning up a few details about Processing syntax and execution. Then we returned to the Albers in a Click topic to explain why I had assigned it. (It was by now a program of the past, and whatever frustration might have been engendered while programming it was gone now.) Besides being a cool application, it was making the point that computational artifacts can raise questions in other fields, this one being art. (It’s not an art class, so we were not going to answer the questions.) An example was, “If programs can create work similar to Mondrian, Pollack and Albers – famous artists of the 20^th century – using random numbers, what role did the actual production of the art by these men play in their work?” “Would they have done different work if they could have experimented this easily?”

After that, the main lecture content was a firm technical foundation for RGB color, including explaining the mystery of why yellow is the combination of Red and Green. Then the task of turning “husky purple” redder became a pretext for introducing binary arithmetic, as we added intensity to Red in several steps.

Assignment 09: The assignment – it was divided into two parts – was to create four programs in Processing that would display something on the screen that would hold a person’s interest for a few moments. Four examples were given with the assignment; see the class examples page, http://www.cs.washington.edu/education/courses/cse120/11wi/classexamples.html. Two programs were to be turned in Wednesday, and two turned in on Friday.

Lab 25 Jan: The lab practiced binary addition, per the preceding lecture. Then, in the free time, students worked on their assignments. This had the benefit that they could ask Brandon for help.

Lecture 26 Jan: The lecture opened with a short description of how to print text on the screen in Processing; (it’s a graphics language, text is harder, figures are easier). Then we moved on to the fetch/execute cycle and the components of a computer. We worked through the standard content, including instruction interpretation. A full example was illustrated.

In the last five minutes, the lecture finished with an explanation of the operation of an nMOS transistor; this was motivated by the ALU evaluation of

AND <operand>, <operand>, <operand>.

I told the class that this was for their own interest and would not be on any test.

Assignment 10: It is a continuation of the last assignment.

Lab 27 Jan: This was time to work on the assignment. All but one student was present and worked steadily.

Lecture 28 Jan: The lecture began by introducing the basics of functions, including parameters and the Processing syntax and semantics. This was followed by a demo in which a timer was developed in several layers (6) of abstraction. The base layer drew the hexagonal element and it built from there. The top level ran the image at the frameRate(10), allowing the time to count “1” with each image refresh.

Timer used In Demonstrating Layered Software Development

Assignment 11: The assignment was to apply the ideas of functional abstraction exhibited in the lecture to the creation of the Sudoku GUI. The solution probably “requires” one less layer of abstraction, but it is plenty challenging for the students.

And How Did It Work?

Nearly all of the students rated the “free programming” assignments of the week as the best part, the most fun and engaging. They appreciated the flexibility of managing their time better according to the After Image survey. I adopted the new-assignment-every-two-days approach to bring the class up to speed with the programming, but now I think we can be much more flexible in the last half of the term.

The results of the “free programming” were quite variable, but most students did something quite ingenious even with their limited knowledge of programming. Several of them tried new things on their own out of the reference materials. Only the few who are really not getting the concepts failed to express themselves through programming.

Monday’s lecture was more relaxed, as planned. It was curious in two ways. First, the miracle of colored light, and the differences it has with our usual experience with pigment seemed to hold the students’ attention, but they didn’t seem to be much interested in it. We then pushed on to do binary addition, and curiously, they were interested in that.

Then, in Tuesday’s lab, Brandon practiced with them on doing addition. Later, in the After Image Survey, someone complained that they only learned about how to do binary arithmetic, but didn’t actually use it. (I thought that was what computers were for!) The bottom line: binary, interesting; light, uninteresting.

Wednesday’s lecture continued the more informal style, which went well. The informal chatter at the start concerned printing on the screen, and everyone seemed attentive; later I heard that several students had tried it successfully. The topic of how a computer works was of interest, and the indirect reference to data through the memory seemed to go across easily. Good. In the “Department of Surprises”: when I finished up with how an nMOS transistor works in silicon – a true miracle of the universe – exactly three people seemed to be interested. The rest of them, having been told that it wouldn’t be on the test – simply packed up their papers and waited for me to quit talking.

Thursday’s lab had students work on their “free programming” assignment. I’d expected Brandon would have to deal with fairly exotic problems as the students’ dreams outpaced their capabilities, but his report was contrary. There were only a modest number of questions, and most students just worked diligently on the assignments.

Friday’s lecture, which I’d looked forward to as a great chance to program in class and guide students through functions went well, but it wasn’t as much fun (for me) as I’d hoped. At the last minute I decided not to actually do the typing real time – the code was already in the slides so we could just go through it – and this meant that we did get all the way through the material. I did show off the app running. My best idea was to create a listing of the code for the students and to distribute it. This meant that students could follow along despite the fact that the displayed program text is necessarily tiny, and about 1/3 of it is too low to view beyond the second row of seats. So, in the end the decision not to develop the code in real time was probably right, but where’s the fun???

When the lecture was over, a student came forward with a question about “formal-actual correspondence,” which is the property that arguments to a function must correspond 1-to-1 to the parameters. I’d left that out. It’s a danger of the first time through, and probably would have come in the patter had I actually done the programming. So, I hurriedly made two slides and revised the posted version of the slides to include that material. I appreciated her question; it saved a lot of confusion.

From the student perspective, it was a great week. They had a chance to program, pretty much unconstrained by anything other than the computer itself. And I got them to see computers as a place where “human intent” can be expressed.

Narrative on Week’s Goals

The content of the week is summarized by the calendar:

Calendar for Week 3

Lab 18 Jan: The lab exercise was to move a colored box across the Processing canvas as a simple exercise in using variables, declarations, assignments and expressions. Most students finished the task within the allotted time; three did not, but they completed it shortly after class.

Lecture 19 Jan: The lecture was a programming demonstration, designed to work with a new language feature (arcs) that required study of the documentation. The point was to illustrate incremental program development, to introduce of the mod (%) operator, and to emphasize programming as a directed process implementing human intent. The task was to program Pacman (yes, the ancient video game) to move across the screen eating pills.

Pacman Lecture Exercise

Assignment 07: Construct the Blinky ghost from the Pacman game, and using variables and expressions make its eyes move; this is preparation for the next assignment that uses mouse motions to control the ghost.

Lab 20 Jan: The lab returned to the myCSP.html Web page that the students posted in their second lab. Now with Processing capable of generating an applet to display in a browser, this lab was devoted to explaining how to modify their portfolio page, transfer the files and link them in to their page.

Lecture 21 Jan: The lecture introduced if-statements and for-statements, but also reviewed the other features of Processing that we’ve had previously in order that all of the material be in one place. There was emphasis on other resources that could be consulted.

Assignment 08: Building on the Blinky ghost code from the last assignment, make the ghost move left or right depending on whether the mouse is left or right of the ghost; make the eyes adjust to the direction of motion, and toggle color (between red and yellow) on mouse clicks.

And How Did It Work?

Student interest in Processing continued to be “strongly engaged”, despite the not-infrequent stumbles in getting it right.

On separate mornings this week two women came in to chat. To my astonishment both made the same two points: The were not technical majors (Communications, I think in both cases) and didn’t expect to like this class – but they do – and further, not being technically inclined, they didn’t expect to do well in the class – but are. This is exactly the end state of this effort, so with any luck we can carry this through and have it apply to everyone.

At the other end of the spectrum, I asked another student to come by to discuss her homework. (One benefit of this study is that we are watching students carefully, and when they don’t deliver, we know immediately.) She seemed not to be investing the time required to actually learn the material in the assignments, and so continued days later not to understand the basics. I explained that it was an accumulating class and that in the future she would have to use material she was studying today. It was a friendly enough conversation, but it contrasted amazingly with the two others.

Tuesday’s lab was very successful. It was an easy assignment, and the students knew what they needed to know to be successful. It was definitely confidence builder.

Wednesday’s lecture engendered some discussion, and in a couple of cases some very clever suggestions – the students are thinking. The mod operator was new and they grasped both the operation and use. However, I felt that the lecture did grub around in very low-level details – antialiasing for instance was mentioned to redraw the image cleanly – that just didn’t need to be covered. In the After Image survey, one student complained that it was a boring lecture, but was out-voted by five others that thought it was engaging. I’m of mixed mind on it.

Thursday’s lab was a hit. Students were happy to get their work out in a publicly available form. This also served to solidify the value of mycsp.html.

Friday’s lecture was the laundry list of facilities that we are using in this month’s programming in order to have it one place. The things that I had already taught were reviewed, to good effect, I think. It definitely took more time than I had planned for. And I got through the rest of the material, but not the last application of mod, which I’d planned to reinforce Wednesday’s lecture.

The “Blinky Assignments” (Wednesday and Friday) were very well received by 80% of the students, though again the After Image included one student thinking it was boring. (Who is this person???) I think the value of this one was that students were pretty much in control of the whole process and though it presented plenty of challenges, they were challenges that they could over come. In office hours students comment about the great feeling of “getting it”!

The students continue to be engaged and to like programming. The After Image Survey continues to reveal that they are most interested in it, as opposed to the “principles part” of the course. Given that the class was advertised as NOT turning them into programmers (and it won’t), they seem very eager to head in that direction.

With the completion of the third week, I have decided that I need to reduce the formality of the class, and make it more chalk-talky. The students like the class; I like the students … let’s try to make it more casual. I’ll start that Monday.

Narrative on Week’s Goals

The week’s plan, as described on the class Web site’s calendar page, is:

Week 2 Calendar Entries

The overall goals were a continuation of the first week’s, namely to show an interesting, diverse and substantive class. The first week had built a cohesive group of students; the second week solidified it further. Specifically,

Lecture 10 Jan: A Social Contract The lecture mostly focuses on privacy and ways online behavior – chiefly invasion of privacy – is harmful. It opens with the word “offensensitivity” — a word invented in the Bloom County cartoon, referring to being overly sensitive to offense — and covers how it applies to online discussion groups. (No one in class had ever heard of Bloom County.) Classic Web memes – Star Wars Kid, Numa Numa Guy, and others – led to the definition of privacy and an analysis of online behavior, ending with five things to avoid posting on social network pages.

Assignment 04: Write an essay on the topic, “Is it ever right to post surreptitiously acquired digital content?” where “surreptitiously acquired” was defined to mean gotten without the creator’s knowledge. The essay was to be two pages minimum and received a due-day extension.

Lab 11 Jan: The lab, continuing the binary theme of the previous Friday, introduced counting in binary, number representation, counting in hexadecimal and converting back and forth between them (and decimal).

Lecture 12 Jan: This was the first Processing lecture. The focus was to familiarize students with the Processing language, and to demonstrate writing a few simple programs. These are available on the Class Examples Web page: http://www.cs.washington.edu/education/courses/cse120/11wi/classexamples.html.

Assignment 05: The students were given the code for the cute robot from Reas and Fry’s Getting Started with Processing, and asked to color it in their own style – coloring it was part of the previous lecture – and then make it move across the screen. This was simply to give practice using the system’s IDE.

Lab 13 Jan: This lab was devoted entirely to helping the students with the details of programming in Processing. Both Brandon and Susan attended to help students.

Lecture 14 Jan: Having represented numbers in binary on Tuesday, this lecture was devoted to representing letters in binary. It covered ASCII, UTF-8 and alternative forms of communication. It also treated meta-data briefly, making the point that meta-data uses the same character encoding as the content characters, but was identified by reserved characters, namely < >.

Assignment 06: Students were asked to scan paintings by Piet Mondrian, and then play with a “Mondrian In A Click” site. Next they were to scan paintings by Jackson Pollack, and then play with a “Pollack In A Click” site. Finally, they were to scan paintings by Josef Albers, and then program an “Albers In A Click” site. See the Class Examples Web page.

Screen Shot of Albers In A Click Solution

Assignment 06.1 Extra Credit: To give more practice using the IDE, students were asked to fill in a closed region with space-filling color.

Email 15 Jan: Students were sent a brief email message in binary based on the ASCII encoding of Friday’s lecture.

And How Did It Work?

Again, it was a good week. The class is very cohesive at this point; attendance essentially perfect and students tell me in advance of their absences.

Monday’s lecture on privacy was somewhat surprising in that when asked about various Web memes, only about half of the class was familiar with them. One has the feeling that they are universally known, but apparently not. The discussion was lighter than what one might have expected on such a familiar topic; privacy seemed not to be a burning issue.

Tuesday’s lab ended up stressing conversion between binary and decimal, and less on conversion between binary and hexadecimal, the emphasis that I would prefer. The dynamics in every class are different.

Wednesday’s lecture on Processing gripped the class. They were interested from the start, and stayed interested. There were some questions, but mostly they paid close attention to what I did. I believe they quickly acquired the operational details of setting up a program, highlighted keywords, entering code, testing it, etc. Less effective – naturally – was their acquisition of details of the commands. Another benefit of the early treatment of functions in connection with Lightbot is that there was a general familiarity with appending parentheses to everything. It’s a fun language and they got that right away.

First Processing Assignment: (a) full credit, correct [FN]; (b) on beyond: beam follows cursor, moves right, or left when mouse pressed [RDH].

Thursday’s lab largely confirmed the quick acquisition of Processing basics. Except for a couple of students, everyone completed Assignment 05 by the end of the lab, and were successful. It wasn’t a monumental program, but they’d definitely personalized it. One student pushed well beyond the assignment to add several clever embellishments.

Friday’s lecture held student interest well, though compared to the last two Wednesdays (functional abstraction and Processing) it wasn’t as captivating. They did understand the content based on a few students replying to my weekend binary email with return binary email.

Not all students were successful with the “Albers In A Click” homework. To its credit it is easy to see what is intended. However, as often happens with early programming assignments, students needed to understand several concepts – variables, declarations, random numbers, colors – to be successful at the assignment. I estimate that half did, and most of the rest got some random colors, but didn’t actually get the logic to assign the colors properly. Because it is nearly impossible to gradually introduce  programming concepts AND produce interesting assignments right along, based only on the few concepts available, I am still undecided about whether this assignment stays in the curriculum or goes.

The class is rolling and the students seem to be enjoying it. Reportedly, the After Image Survey revealed that the students really enjoyed the Processing material, both class and lab. The fact that it is a fun language has more to do with their liking it than the quality of the classes, I’m sure. Still, you learn more when you like what you’re doing, so I am optimistic that we’ll be able to cover a lot more content as a result. Although the other pilots have chosen to use either Alice or Scratch to teach programming as a “fun” activity, I will continue to advocate for Processing. I am certain that my students see Processing as fun; I conjecture none of them sees it as childish.

How will next week go when the programming gets more challenging?

Narrative on Week’s Goals

The week’s plan, as described on the class Web site’s calendar page, is:

Week 1 Calendar: Lectures, Assignments, Due Dates

My over-riding goals for the first week were to set behaviors, to attract interest, and to demonstrate the spread of activities that will characterize the whole class. Specifically,

Lecture 3 Jan: A standard overview lecture in which the course is described, including the fact that most of the information is on the Web page, http://www.cs.washington.edu/education/courses/cse120/11wi/. In terms of setting behaviors, I emphasized my responsibilities to the students and theirs to me.

Assignment 01: “Play” (== program) Lightbot 2.0 through the introductory exercises http://armorgames.com/play/6061/light-bot-20 and the first 3-4 recursion exercises.

Lab 4 Jan: This first lab had two very different goals. The first was for the students to write an essay on “Their Values and Why They’re Important”. The motivation for doing this comes from an article in Discovery Magazine about results from a University of Colorado study on raising women’s scores in introductory physics classes:

http://blogs.discovermagazine.com/notrocketscience/2010/11/25/15-minute-writing-exercise-closes-the-gender-gap-in-university-level-physics/

(Thanks to co-piloter Beth Simon for calling attention to this article!) Having no idea if it would contribute to a successful class, but not seeing any way in which it could be harmful, I assigned this as the first activity in the first lab. The other part was to learn about FTP and file servers in the .washington.edu domain.

Lecture 5 Jan: Having played Lightbot 2.0 the class was ready for a lecture on what programming is. Many features of programming – you’re commanding an agent and you must think from its point of view – are evident from the experience and are easily highlighted as a result. The crescendo of the lecture was a discussion of functional abstraction, a topic that I regard as “hard to get across” in the Fluency class, but building on Lightbot, it was now straightforward to introduce. We’ll be back to it in the future.

Assignment 02: Revise the Lightbot game to use symbolic instructions rather than icons, and solve a few new problems. This is an off-line exercise and required the students to examine the correctness issues by hand.

Lab 6 Jan: The plan for this lab was to review FTP (a notoriously difficult concept in my experience) and to practice using FTP by posting a prepared Web page. The Web page, which was XHTML, is set up to be a portfolio of their class work. We don’t do HTML, but I wanted to make the point that there is nothing mysterious about computing and even things you have no real knowledge of can make a certain amount of sense if you just take a look and use your head. Students modified the page to reflect their persona, rather than my example persona.

Lecture 7 Jan: “The glorious story of the triumph of 0 and 1” was the topic, and it emphasized digitization going back to Hollerith. Using the technology as the theme, the lecture covered “game changing” milestones in computing: machines processing digital information, computers, transistors and ICs created with photolithography, personal computers, Internet, WWW. At the end we discussed various manifestations of digital information, ranging from “sidewalk memory” to the encoding of a CD ROM.

Assignment 3: Continuing the symbolic form of the Lightbot game, students developed named functions (Lightbot 2.0 has only two functions F1 and F2) to solve (off-line again) small problems. The end goal was to solve one of the exercises from the first assignment, but directing the Lightbot to do a Moonwalk after completing each intermediate goal. [As TA Brandon pointed out, Michael Jackson’s Moonwalk is not part of the life experience of these students.]

And How Did It Work?

Overall, I believe the first week went great! Starting with Lightbot 2.0 was extremely successful (co-Piloter Jody Paul also used it to good effect)! The students universally like it, and said how enjoyable it was in their end-of-the-week After Image survey. For me it is convenient way to get students into programming quickly. In terms of setting behaviors, I think we did fine there, though we stumbled on Thursday.

Monday’s lecture was an unplanned chalk talk, and in retrospect, I think that may have been better. It allowed a much more informal discussion of the course. We introduced ourselves, saying a few words including a favorite food. (I got my first laugh when I said I liked fresh anchovies on potato chips, which wasn’t a joke, but the truth; the closest anyone came to eating anchovies was one woman [HAC] who liked Caesar salad dressing … I’ve got a lot to teach!) One caveat about the chalk talk style is that I don’t think the verbal presentation was sufficient for the two slides: My Responsibilities To You, and Your Responsibilities To Me.

The first assignment’s Lightbot 2.0 contributed to teaching computational thinking in one unexpected way. If computational thinking is summarized as the habits of mind of computational thinkers, then one habit must be a confidence and willingness to figure things out on your own. Lightbot was assigned without introduction. Many students reported in the reflective survey afterward of having been very confused initially, then figured things out thanks to the tutorial nature of the game, stumbled in some places, but pushed forward, completing all of the requested work and finding it enjoyable; nearly all did at least 3 recursion problems. What a fun setting to be successful at figuring things out. Though I didn’t recognize this feature quickly enough to reinforce it, I would next time.

Tuesday’s 15 minute, “My values and why they are important” writing exercise produced a few unexpectedly thoughtful essays, which were fun to read. Whether the exercise will affect the students in any way is unknowable. Curiously, all students included (and usually started off with) the importance of family. When I (verbally) introduced the assignment, I mentioned that value first, though I mentioned a couple of others. Family is important for most people, of course, but its universality and first place setting caused me to wonder if somehow giving the assignment had affected the result.

Wednesday’s lecture on the basics of computing, including remarks on functional abstraction, was rewarding to give, and held the students full attention. Apparently many mentioned it positively in the After Image survey.

Thursday’s lab, which was to be a review of FTP followed by students using FTP to post a pre-written “portfolio” Web page (which they customized for themselves), was not that successful. My original intent – to get them to deal with code they didn’t understand much about, but by looking at it closely, be successful at modifying it for their purposes – was not the problem. They all did that.

The problem was that many students got lost in the weeds – the problem had too many components. I had them modify the page using a text editor (Notepad++) rather than WYSIWYG facilities, they were to import a picture to use on the page, they needed to make 4-6 modifications to the page, and (it was an FTP exercise) there was the usual confusion about where is the file I’m looking at. Add to this an unknown “gotcha” involving how UW allocates Web space to “plain” students vs “employee” students, and you have a mess. None of this was beyond them, and more than 3/4 of the students were successful, but I want to avoid chaos so early in the term. It’s still a good lab (I’ll do it again), but it’s probably the wrong day for it.

Friday’s lecture was strong, though after Wednesday, my expectations were too high. Students were for the most part engaged. On impulse I picked apart the information content in the “one if by land, two if by sea” signaling mechanism used in Paul Revere’s ride, and quickly realized not all students are familiar with it. (It’s still a good example, but the point arises one week later, so I won’t do it again.)

The week ends with students filling out the After Image survey in which they report on the material they found most engaging and interesting, what was difficult or frustrating, and any other comments that they want to make about the class. These have been structured to be anonymous to me, but Susan reads them and gives me an anonymized summary. Like me, the students enjoyed the first week.

AP CS Principles Background

What Is It? AP Computer Science Principles (will one day be) a high school course covering the principles of the field known in the US as Computer Science. The course will also be preparation for an Advanced Placement exam developed and administered by College Board (CB, hereafter) and taken by graduates of the class in order to receive course credit or placement for the material in college. An Advanced Placement test already exists in Computer Science for students who have studied the Java programming language (AP CS Java, hereafter); that course and exam will remain as is. AP CS Principles is targeted at all students, not just those who are self-motivated enough to study a programming language.

Why Do It? The public discussion of AP CS Principles has identified a long list of motivations for its creation. Find them at http://csprinciples.cs.washington.edu.

Personally, two motivations have driven my participation. First, I think computation is fascinating (and in many instances beautiful), and it seems that more people should take pleasure from it. I am always eager to explain computers and computation, geeky as that may sound.

Second, I have believed since the NRC’s Fluency Report came out that the best way to present our field to the world – both to techies and non-techies alike – is for it to be taught as a high school science class. CS is rarely taught in high school; the courses called “computer science” are usually not part of the science curriculum at all, but are career development classes: Apps courses that are peers of Shop not Physics. (Most are so “non academic” that the NCAA doesn’t accept them for sports eligibility.) Because many students, having received their first exposure to “serious science” in a high school class, go on to further study in the field, it seemed that a Fluency-grade CS class could be an attractor. And it might eliminate the “nerds only” stigma that seems to taint AP CS Java. The AP CS Principles course presents exactly the right opportunity.

The Process. The project to create a computer science course for general students began in 2008 (http://csprinciples.org). The name adopted for the course by the project investigators was Computer Science Principles (CSP, here after). Seven big ideas and six computing practices were developed as defining goals for the course. The big ideas and practices were vetted in several iterations with the CS community. From these guiding principles, a document called Claims and Evidence (C&E here after) was developed that more specifically defines the intended content of CSP. At the time of this writing, refinement of the C&E document is continuing.

In Spring 2010 five schools were chosen to pilot a course implementing the content during the academic year 2010/2011. Each instructor was to develop a curriculum based on the guiding documents that is illustrative of a college course teaching Computer Science Principles and appropriate for their campus.  The schools and the instructors are:

• University of North Carolina at Charlotte, Tiffany Barnes
• University of California, Berkeley, Daniel Garcia
• Metropolitan State College of Denver, Jody Paul
• University of California, San Diego, Beth Simon
• University of Washington, Larry Snyder

Because of local conditions, the courses were not offered simultaneously: MSCD, UCB and UCSD offered the course in the fall term; UW and UCSD are offering it in Winter quarter, and UNCC is offering it in Spring semester.

This blog describes the experiences of the UW offering.

Next Steps. There are two threads that proceed from the completion of the pilots: an academic “next steps”, and an adoption “next steps”.

Academically, the plan is for high schools to pilot the class during the 2011/2012 academic year; each of the current piloters is working with one or more high school teachers. Additionally, more colleges and universities will pilot the class next year as well. During the 2012/2013 academic year additional pilots, both high school and college are planned. After the curriculum has stabilized, the CB will begin developing pilot exams. The expectation is that the first AP CS Principles exam will be offered in 2014 or 2015.

The “adoption” thread concerns commitments by North American computer science departments to endorse the AP CS Principles course, and to commit to giving students who pass the exam either credit or placement at their institution. The process of adoption has two parts. First, the guiding documents of the project (Seven Big Ideas, Six Computing Practices and C&E) will be circulated to CS department chairs early in 2011 to get their feedback and input regarding the content. This ensures that the planned content reflects a broad consensus of the field. Second, following the content review, CS department chairs will be asked to send (an electronic) letter attesting to their endorsement of the effort and stating that their institution will give successful test takers credit and/or placement. The current status of the adoption thread can be found at http://csprinciples.cs.washington.edu

Preparations for UW’s Class

Creating a class that is specified only by “guiding principles” is both exhilarating and challenging. I did it one other time, just prior to the publication of the “Fluency Report” in Spring quarter 1999. The National Research Council’s report, Being Fluent with Information Technology (National Academy Press, 1999 and available at http://www.nap.edu/openbook.php?isbn=030906399X) was requested by Bill Wulf when he was Assistant Director for CISE at the National Science Foundation. Known widely as the “FIT Report” (for Fluency with IT), the study’s recommendations were the first attempt to specify the “computer science content that the general public should know?” It continues to be the guiding document underpinning a large number of college FITness courses for general students.

The UW Fluency course overlaps with the CS Principles at about the 80% level, but they have different emphases. When I describe the difference, I label Fluency as “Computing for the Citizen” and CS Principles as “Computing as a Science.” They share many concepts like data representation and many capabilities like programming, but the former emphasizes practical issues like how to manage the security on your computer, while the later goes more deeply into computation to cover, for example, recursion. The bottom line is that when the AP CS Principles course is fully developed and the exam exists, students that pass it should be excused from a standard Fluency course.

Although the overlap is substantial between the two courses, I chose not to use Fluency as a basis for CSP, choosing instead to develop it from first principles (NPI).

CS Principles Course. The class didn’t get approved until a few days prior to the start of the term, but when it finally emerged, it could be described by the following catalog entry:

Course Number: CSE 120

Course Title: Computer Science Principles

Offering [pilot]: Winter, 2011

Lectures [50 minutes]: Monday, Wednesday, Friday 12:30-1:20, LOW 216

Labs [closed, 50 minutes]: Tuesday, Thursday 12:30-1:20; MGH 044

Credit Hours: 5

Fulfills Requirements: Quantitative and Symbolic Reasoning

Pre-requisites: None

Description: Fundamentals of computer science essential for educated people living in the 21st C, taught with two concurrent themes. Creativity Theme topics: Computing as a creative activity, processing of data creates knowledge, abstraction, levels of abstraction, managing complexity, , computational thinking, programming (in the Processing language) debugging. Principles Theme topics: Data and information, algorithms, basic ideas behind technologies including computers, networks, search engines, and multimedia. Social uses and abuses of information, and the foundations of privacy are also included.

The programming languages had initially been Processing and Python, but eventually it seemed that all of the necessary programming concepts were available in Processing.

Finding Students. So, who takes an unapproved, single-offering experimental course? No one unless there is some effort made to solicit students. The key property is the “experimental” aspect, because it requires that the class include a good representation of women and under-represented minorities. (A major goal of the project is to present a class engaging enough to under represented groups to attract them to the field.) Listing the class among UW’s course offerings permits no selectivity – any student with the pre-requisites (there are none) can take the class, possibility filling it with a biased population. (The first Fluency offering was “rich” in seniors because they registered first in the term it was offered, and the course quickly filled up.) So, we used a “by permission of the instructor” approach.

Since qualified students cannot be denied access, the way to “improve” the representation in class is to advertise appropriately. We used the following channels:

• We contacted the advising staffs for appropriate campus units (Freshman Advising, Office of Minority Affairs and Diversity Advising, etc.), providing a Web site explaining the course to the advisors, a flier, a link to an electronic version of the flier (http://www.cs.washington.edu/homes/snyder/pilot/CSPflyer.html), and an application.
• Two weeks of advertising on the “Puzzles Page” of the Student Newspaper, the “Daily.”
• Email requests to campus organizations (e.g. Society of Hispanic Engineers) asking that the membership be made aware of the flier and application.
• Development of a short “pitch” on why to take this class, http://www.cs.washington.edu/education/courses/cse120/11wi/story.html
• Redirection from the Fluency Course (CSE/Info 100) when it filled up.

By whatever means, these mechanisms attracted about 70 applicants.

Not all applicants were qualified for the class. Students were not admitted if they had taken or were concurrently taking a CSE course in which programming is taught, nor if they were graduate students (really, 3 applied!). All other students were admitted, though not all of them ultimately registered. The result was a first day class of 22 students. It’s an ideal class size. (Despite the small size, the curriculum is designed to scale.)

Diversity. The advertising effort seems to have paid off. Of course, we are not allowed to know the race or ethnicity of specific students, but the summary statistics for the class are available. Of the 22 students

• 11 are women
• 9 are Caucasian, 1 “not indicated,” meaning the rest are students of color
• 5 official Under-Represented Minorities, 1 American-Indian (apparently not an official URM), 4 Asian + 2 presumably Asian international students
• All but 4 are freshmen or sophomores

(“Asian” is not considered to be an under-represented population for purposes of this study, or at Washington, for that matter.)

Teaching Staff: By being a pilot course, the class enjoys substantial teaching support. The Teaching Assistant is Brandon Blakeley, a UW CSE Graduate Student. In addition, I am working with Susan Evans, a high school teacher working at the Technology Access Foundation where she is focused on STEM education and teacher training. (In the summer I also worked on course development with Hélène Martin.)

Course Design. As I read the materials that guide our curricula, I decided that the course needed two threads: One could be called the creativity theme, the other called the principles theme. (These correspond roughly to capabilities and concepts, respectively, in the Fluency world.) Weaving the two threads together presents a significant challenge, and as the first day of class approached, it continued to be unclear how best to do so.

In addition to the two threads, a major criterion for “success” with the course is the degree to which it engages all students. What constitutes “engaging” is obviously a very personal matter. Making the class fun is desirable, of course, and likely to contribute to the goal, but I believe it is just as important to be interesting and appropriately challenging.

How these components manifest themselves in the course is the subject for future posts.