With the final exam over with, it's finally time to reflect on this semester's offering of my version of our 'Introduction to Computer Science I' course for non-majors, taught in Processing. I wrote before about designing the course by
starting with learning objectives, and then using those to
come up with problems to study.
The general structure of the classes was to first show off a demo of the final product, start coding it, and learn concepts along the way. I also eventually added more toy examples to illustrate each concept, thanks in part to the anonymous midterm feedback I solicited. Here are main examples we looked at, and the skills we learned along the way.
Drawing Pictures with Processing
Creating a simple static drawing with code is a nice way to dive in without having to learn programming theory. We referred to function calls "commands" that draw shapes like ellipses, and talked about some basic drawing and colour theory.
Then, as our pictures became more complex, we learned about variables as a way to cut down on repetition of hard-coded numbers. We also saw that our drawing commands were a lot easier to follow and debug when we used meaningful variable names.
Interactive Painting with Processing
The logical progression has us move from static drawings to a simple interactive painting program. This allowed for the introduction of Processing's active mode, and thus an introduction to the idea of functions. We also used it as an opportunity to start seeing how to break a programming problem down into smaller pieces that could be solved more or less in isolation.
Jukebox
The next problem was a to make a working jukebox with three buttons/songs. You could click on a button to play its song (turning off any other song that might be playing). When a song plays, the corresponding button flashes. For example, in the picture below, the second song is playing.
This example allowed us to learn about how the draw() loop works in Processing, how to play sounds, and what a Boolean value is and how it can keep track of the play state of a song. We also learned about if-statements, and how to use them to determine which button a user clicks on.
Simple AI Character
I chose this problem based on the fact that many students in the class are in cognitive science. We built a very simple state machine that was used to decide how to draw a sheep. The sheep normally wanders around the screen toward the mouse. If the sheep gets close to the mouse, it stops and drinks tea. If the user then clicks while the sheep was stopped, a psychedelic ring of colours emanates from the sheep, as in the picture below.
While building this program, we learned about character movement and animation, tracking state with constant variable values, using if-statements and distance calculations to check how close the sheep was to the mouse, and writing functions that are self-contained (and thus could be reused in another sketch). When making the rings animation, we learned about arrays to store the colours and while loops to draw them.
Weather Visualization
This problem was split
into two parts, both based on real, local weather data
available from the Canadian government. For the first part, you would click on a time line and see the temperatures for the five closest dates. For the second part, you instead click on a thermometer and see the dates of the five closest temperatures. The goal was to get students thinking about how they can visualize their data in order to explore it more easily.
Part one of the example gave an opportunity to get more comfortable with arrays and get a brief insight into reading and processing data from a file. This also meant Strings could be formally introduced. We learned about searching algorithms as well, since some kind of search to find the 5 closest temperatures (or dates) is needed.
In part two, we learned basic sorting techniques so we could more easily find the 5 closest values relative to temperature instead of dates. We had been using the idea of "parallel arrays" for storing multiple pieces of information for the same entity up until now, but for sorting it is much easier to package all that information up into one variable. Thus, we learned about objects and classes.
Social Media Coverage / Set Cover Problem
The last problem we got to this term was
inspired by this post. The context was the following scenario, dreamed up by some of my creative friends. Suppose we have a set of social media sites, like MySpace, Facebook, Google+, Twitter, and LinkedIn. Each site reaches a different audience. For example, Facebook probably reaches more young people than Twitter or LinkedIn. Given the social media sites, and the corresponding audiences that each can reach, what is the minimum number of social media sites that still reach all audiences? (Minimizing this number means less work for the marketing team.) This is the
set cover problem.
The main concept introduced with this problem was the idea of storing objects in other objects, understanding how references work, and knowing when to share data versus make copies of it. In the image above, each social media site acts like a button, and when pressed, it lights up the audiences the site reaches. Site buttons should have references to the audiences, not their own copies of them.
_002.jpg)
