One of the things that I clearly am too worried about is how I interact with open source community in a meaningful way and how that is reflected in my evaluation as a member of the faculty.

I am evaluated on the excellence of my teaching and my research. At Allegheny, the former is considered more important, but it all matters. Writing code and contributing to an open community process is not something that is easy to evaluate and, further, not something that my colleagues in Computing even understand well. I can say that with some confidence, because I have learned so much in the short time we’ve been here at POSSE.

Clearly, though, this is one of the conversations I need to have with my colleagues and my Dean when I return to Allegheny. If I want to be in a position to help my students take part in the open source community, I need to serve (I believe) as a knowledgeable guide into the space. That means that I have a working understanding of the practices and cultures that they will be encountering. And the only way that will happen, to some degree, is if I am involved myself.

Perhaps I’m wrong in this—gregdek or another POSSE participant will correct me if I am—but digging in and playing in the sandbox matters. And if I am going to do that, it is going to take time to get involved, and I will want to sustain that activity over the coming 3-5 years at the least. Any project I do on that timeframe, that absorbs a significant amount of my energies, needs to be acknowledged by my institution as having value.

A disclaimer

It is true that I could just contribute. I could continue to teach without integrating open source, and do my research on things completely unrelated. I can strive to be an excellent husband and father, and … stop sleeping and eating. Ultimately, for me to take part in this, I suspect it must count towards my professional development at the College in a meaningful way.

I’ll let you know how/if/when I’m wrong. I probably in, somehow.

200907202124.jpg

This week I’m in Raleigh, North Carolina. The majority of my time here will be spent at Red Hat HQ taking part in POSSE 2009. POSSE is a gathering of faculty and open source practitioners where we are learning about and practicing the skills necessary to take part in open source communities. Our goal is to walk away prepared to begin introducing OSS into our classrooms and continue growing the community.

Today we covered a fair bit of ground, with conversation ranging broadly from technology to pedagogy. The people here who have worked to integrate their students into (large, production-quality) open source projects are, truly, inspiring. I look at the experiences that my students have in our classroom, and can’t help but want to provide them with opportunities like those I’m learning about. At some level, of course, that’s my job—to provide first-class learning opportunities for the students of computing at Allegheny, as well as students at the College as a whole. But there is more to it than that.

From the perspective of computing today, I can see why I want my students involved in open source software projects. On the surface, it provides them with incredible experience and resume fodder—it is a way for them to make real contributions to shipping products. (You’re probably reading this on Firefox, which is one of the projects we’ll be haxing on this week.) These large projects provide real-world experience for students that companies today are looking for. These kinds of projects have real users who provide real feedback. And to deliver working products to those users, students must learn to work with global teams, and how to learn the processes involved in managing a project in a distributed, sometimes decentralized manner.

Perhaps most importantly, however, is that students should feel empowered to dive in. The barrier to entry is low. And further, there are many ways for students to get involved. In fact, the students do not need to be studying of computing per se. The writing of documentation, maintaining wikis, testing software, localization (translation) are just a few of the ways that students can begin to engage an open source community.

Open Source @ Allegheny

One way to think about how I will integrate my experiences with POSSE into my local context is to think about the Computer Science Department and how I might bring my ideas to bear there. Or, I could think about how I might better serve a larger community—my College as a whole—as well as serve needs that are often overlooked in open source projects.

Allegheny has an excellent center for experiential learning that provides a home for cross-disciplinary courses with an outreach/experiential focus. Further, we have a strong English department, and a course in technical writing. I think it would be possible to discuss brining the technical writing course under the auspices of ACCEL, and begin integrating it with efforts like flossmanuals.net and writingopensource.com. This transforms technical writing from an academic exercise to one that provides high visibility for the students taking part, as well as visibility for Allegheny and its role in open/community-based projects.

This is a brainstorm at the moment, but I think it represents the most productive line of reasoning I have to date. Coupled with Allegheny’s Year of Social Change, this could be a good time to begin bootstrapping this kind of work in the liberal arts context.

Mel was musing on documentation in open projects recently.

In our recent code sprint on the Transterpreter project, we realized that for years we have had far too little documentation. Specifically, we’ve been lacking documentation on not just one front, but two.

First, we’ve lacked developer documentation. That didn’t change during our sprint. Someday, but not during this sprint.

200907181216.jpg

Instead, we focused on a new (user-centered) platform and end-user documentation. Given that we are working on a language and a runtime for that language, it becomes difficult to document things for people. “I downloaded it… now what do I do?!” Invariably, we say “write some programs!” That’s… less than ideal. We realized that if we want more people to explore parallel programming for embedded systems, we’re going to have to provide an easy path for engaged beginners to dive in and be successful from the start.

So, we brought our language and runtime to the Arduino. (There’s some cool videos over on the Transterpreter blog; check it out.)

200907181202.jpg

The Arduino is a piece of “open hardware,” meaning the design of the device is free and open. It is powered by the Atmel Atmega328, a 16MHz processor with 32K of flash and 2K of RAM. To many people, those are small numbers, but to us, they’re enough to write interesting parallel programs for controlling embedded microcontroller projects.

We have drafted the first 50 pages of a book that supports programming these affordable ($25 or less), open devices in one of the few parallel programming languages around. Our support library is called Plumbing, and we are excited about completing the first ten chapters and sharing them with a group of “alpha testers” who can help make sure our writing is appropriate for our target audience.

Who is our target audience? We have chosen the Student Artist as our target persona for the book. This is a notional college-age student who is studying art, has no significant programming experience, but wants to add interactivity and computation to their work. They don’t want to learn to program (per se), but instead want to achieve some end: a piece of art, an installation, or similar. The electronics and programming component is fascinating to them (and perhaps a touch daunting), but they’re willing and ready to learn what is necessary to make their art as successful as possible.

This persona, we believe, overlaps a great deal with the MAKE community, and even with many students of engineering and computing. However, we have explicitly forced ourselves to consider a target audience that is not studying programming. This forces us to think about what concepts we introduce when, focus on outcomes and results (as opposed to belaboring theory up-front), and do our best to support the artist/maker in fun and thought-provoking explorations from the start.

If you are interested in being part of the group who gets a look at the book early, please either drop me an email (matt at transterpreter dot org) or leave a note with contact information in the comments (a URL to your contact info, an email address, etc.). We’ll be finishing the drafting and revising that material over the coming weeks, and hope to have an initial release of the software (a simple IDE with Arduino support built-in) soon.

Commenting on my previous post, Mel points out something rather critical:

I was grinning when I read “Those other students are the competition.” Are we, really? How does it change things if you say instead “those other students are our future partners, and we’ve got to step up our game in order to be able to really tag-team with them”? Perhaps this is my conflict-aversion tendencies cropping up, but I’ve been far more motivated to do awesome things by “I want to be worthy to hang out with people I think are super-cool” than “I will beat X or he/she will beat me.”

I think Mel is exactly right. The traditional view is to say “There is limited resource, and better I have it than my competitors.” A collaborative world-view dictates that I instead say “Value is increased if I am the equal of my collaborators.” At the root of both is the notion of bettering oneself; in the case of the latter, it reinforces the fact that bettering yourself is not a zero-sum game.

And, a digression…

Put simply, a “zero-sum” game is one where every point I score means a loss for my opponent. Recently, I heard David Brin talk about this kind of world-view in terms of a simple question:

You may have one wish, and it will be visited double upon your worst enemy.

Someone who believes in positive-sum games (where things that benefit me benefit everyone, and visa-versa) would wish for whatever they want, knowing their enemy will receive twice as much. “I wish for enlightenment” is an example of a positivist wish that does no harm to either party. A zero-sum wish is harder to formulate—one that benefits me but benefits my enemy might be “I wish we had twins.” While I would have twins, my enemy would have quadruplets—a clear strain on their resources without explicitly being a bad thing. If I wanted to make a negative-sum wish, I might say “I wish I only had one eye.” Clearly, when visited double on your enemy, this wish is truly dire.

So, as Mel points out, putting educational outcomes in competitive, or zero-sum terms, is perhaps the wrong message to be broadcasting to our students. In fact, it is almost certainly the wrong message. Our students should be learning that they can learn from each-other, and that their apparent competition are actually/also future colleagues. Therefore, their excellence does improve their chances of getting a job/getting into grad school/etc., but bettering themselves also means that they are better positioned to collaborate with awesome people Out There that they haven’t met yet.

I may update the PDF to reflect this thinking, but I’ll do it as a footnote or appendix; I want the original text to stand to make clear how deeply engrained this kind of zero-sum thinking permeates our views regarding education. Put simply, we live in a country dominated by zero-sum education when it should be positive-sum education.

Very insightful.

During the Spring 2009 semester (my second semester at Allegheny College), I had the opportunity to teach Programming Languages. If there is something in the canon of computer science that I love, it is languages. Or, perhaps I just like writing compilers and VMs. Either way, I was excited to offer the course.

I struggled with the design: I had 25 students ranging from first- through fourth-year, and the only background I could count on was that they all had two semesters of Java. I considered a survey approach, but I couldn’t see how this could possibly compare to the writing of interpreters implementing a variety of language features. In the end, we ended up using Shriram Krishnamurthi’s CC-licensed Programming Languages: Application and Interpretation along with some materials I developed myself.

I think the course went over well, and the students (in my estimation) learned a great deal about naturally recursive data structures, software testing, and the interpretation of languages. There is work to be done to improve the course for its next offering, but I think I have established a good starting point for future revisions.

As in past semesters, I asked my students what they would keep, change, add, or throw away (KCAT). I have used this evaluation process for many courses over the years, and have only recently begun writing up the results of this conversation and sharing it back with my students (and the world, FWIW). Software Design at Olin (F2007) and Introduction to Computing at Allegheny (F2008) both received this treatment. To this collection, I add a reflection on the Spring 2009 offering of CMPSC 220: Programming Languages at Allegheny College (direct PDF link).

readscheme.org is back.

Wootness. Now I can assign Scheme readings to my PL class…

For your entertainment, the CES 2009 keynote about Microsoft’s Kodu game development environment, featuring “Sparrow,” an “actual 12-year-old-girl.”

This video is the most important video you can watch today if you are a computer science educator. Why? Because Sparrow might show up in your classroom someday. She’s 12 now. In five years, she’ll be looking at or applying to colleges. Now, it’s possible that she’ll become an English major, or perhaps she’ll join the newly formed Nanobiotechnology major that all the kids are excited to get into. But, it’s also possible that she’ll double-major in English and Computing, because she is excited about the role of story-telling in this new media. (Nod to Geoff there.)

Now, she shows up in a typical first-semester course in computing. Here, she might be introduced to the Linux command line, the Java programming language (or Python, or Scheme, or C… I don’t really care). And, do you know what? Sparrow won’t care either. Just how many weeks is she going to show up to your classroom, listen to you lecture about variables and objects and their location in memory, and actually want to show up? She’s been writing games using tools like Kudu for the past five years. And now, you’re the poor sap whose job it is to stand in front of the room and motivate her to print rectangles on the screen using System.out.print and a for-loop in Java?

**********
*        *
*        *
**********

That scene isn’t a hypothetical situation: it’s where we are today.No one really knows why students are less and less interested in computing as a major at the college level, but I’m prepared to claim that it has to do with the massive disconnect between (the vast majority of) the introductory course experience and what students see in the world of computing today. For example, we can pull one of the more popular computer science textbooks, Java Software Solutions by Lewis and Loftus, and find the problem I’ve just described in it. How popular is the text? It currently sits around 9000 in the Amazon sales rank (it was higher last week), meaning they sell around 10-20 copies per week right now. (This is probably a start-of-semester bloom, but still… it’s a popular text.) Not surprisingly, John Lewis has diversified his authoring portfolio, and along with colleague Peter DePasquale has written a book about programming in Alice. (All of these texts costs too much, but that’s another rant for another day.)

Environments like StarLogo:TNG and Alice, and now Kodu, are what our students will be familiar with. They’ll come to our classroom and expect to be able to do at least that much. When we throw them into introductory Java, or a first-year experience in Python, and it isn’t engaging in some way, they… well, they disengage. Why should they care? What motivation is there for deep learning, as opposed to doing enough to pass the course? My students today are accustomed to science-fiction-like technologies (the iPhone, iPod Touch, the PS3, Wii, and Nintendo DS, etc.), and we given them beige boxes with command lines?

This second video goes into a bit more detail regarding Kodu. When your students are accustomed to “writing” behavioral code for agents acting in a real-time, parallel environment… what do you teach them first when you get them in the classroom? All of the traditional assumptions—parallel is too hard, behavioral control is too hard, objects are too hard—go right out the window. If it is so hard, how come Microsoft turned it into a kids toy?

You tell me if this floats: “Hey kids, look at this triangle I just printed using a for loop and some asterisks! Isn’t that rad!?”

Er.

No.

Caution, meet wind. The times, they are a changin’.

I really believe that we should be putting programmable devices in the hands of students studying computing. Or, if you prefer “Why we’re still teaching programming for desktop-class devices?!?” The desktop is complex, uninteresting, and lacks relevance in a highly mobile and connected world.

I look at magazines like MAKE, or the Arduino project, or (especially) Bug Labs, and think that every undergraduate CS student should be doing projects on this kind of hardware. Ten years ago, there were no affordable and open options for doing cool stuff in computing. The Mindstorms RCX was the closest thing, and it certainly wasn’t “open”.

Today, $20 gets you a programmable, open-source embedded controller, a complete programming environment (and documentation), and an entire community of people to go with it. It is called the Arduino. The hardware is cheaper than a text book, and our students could be doing incredible things with it. Fortunately, to transform our students’ classroom experiences, all we have to do is overcome institutionalized resistance to change…

If you’re willing to spend a bit more money, the Bug Labs platform provides you with a $250, ARM-based, open-hardware Linux machine with a host of discrete, pluggable modules. This is really, really slick shiznit. This (CC licensed) video does a good job of explaining the base:


Modules that can be snapped into the base now include an LCD screen, a GPS unit, a 3G GSM module (yes, cellular connectivity!), WiFi/Bluetooth, and the von Hippel module, which provides connectivity and breakout over a wide variety of GPIO and serial protocols. While this is a more expensive way to get hardware into the classroom than an Arduino, it is open, looks robust, and is built on and using tools students will see for many years to come: Linux, Java, and Eclipse. (I wonder how hard it would be to integrate into BlueJ…)

It isn’t so much that I think students of computing should become “makers.” I do think that students of computing need to be engaging in authentic activities. I will claim that our students are most likely to encounter “interesting” problems in the realm of mobile embedded systems. Given the rapid proliferation of wireless devices (mobile phones, the iPod Touch, Android-powered devices, etc.), students of computing are almost certain to find themselves programming in these environments in the coming decade. (To this end, web services and distributed computing are also places where our students need exposure, given that the edge device is almost certainly going to interact with some kind of service.)

Perhaps I can get a BugBase and a student for a summer, and see what can be done with these toys. Finding a student who wanted to go exploring might be the harder part.

200901071727.jpg
The von Hippel module. I love the braille…

Last year, I worked on a project with some Olin students to explore building a “dummy GPS.” The idea was to have the simplest possible GPS unit—one where you simply said “I am here,” and then it points back to that location until a new waypoint is set.

Someone went and built one. And manufactured it. As a keyfob.

200812171435.jpg

Hammacher website

I think that’s funny.

UPDATE (20081229): This device is actually the Bushnell Backtrack. Above is just a link to a rebranded version that costs $30 more. If one were so inclined, Amazon has them for around $50. There were some comprehensive (fairly negative) reviews at Amazon that seemed to indicate that this is useless for mall parking lot navigation. However, I can still see this device as being useful to campers/hikers and the like. That, and there is more info at the Bushnell site.