200910121702.jpg

How is a research group at a small, liberal arts college born? I think you get some students working on related things, and declare them a group. That, and have them over for dinner at least once.

Background (not so important)

My current research focuses on the behavior of novice programmers and the development of tools for parallel programming on small embedded systems. Long term, I am interested in the usability of programming languages—which lies at the intersection of my current lines of research inquiry.  

One reason I take a long view on my research because I am at the start of my career. Another is that I am committed to involving students at Allegheny College with diverse backgrounds in my research. For these reasons, I paint my research with a broad brush to better support more students with more interests. In doing so, I can productively move my research forward regardless of what interests my students might have in any given year. It also makes it easier to collaborate across disciplinary boundaries when you keep an open mind regarding where your work can be applied.

The Students (very important)

This semester, I am excited to be working with four students. Stephanie Cost and Sara Doan (both Allegheny ’11) have been learning the foundations of image manipulation using Python, with an eye towards image analysis and transformation. Their work is funded by the Collaborative Research Experiences for Undergraduates programme, and is titled Operation: Stick Figure Army. Their project explores the problem of transforming 2D images into 3D models suitable for printing on the Makerbot Cupcake CNC 3D printer (project overview). The goal is to produce an open source set of tools for supporting blind readers—images are the bane of a blind student’s existence, as they translate poorly using existing printing technologies. Our hope is that low-cost, personal fabrication technologies like the Cupcake CNC (along with usable, open software tools) will create new opportunities for blind readers in this space. Both Sara and Stephanie are doing excellent work, and I’m excited to have the entire year (both semesters plus the summer) to work with them on this project.

Although this is our Fall Break, I spent two hours today catching up with Radu Creanga (Allegheny ’11), who is helping our distributed group bring parallel programming to the Arduino platform. Using the occam-pi programming language and executing on the Transterpreter virtual machine, Radu has quickly learned the joys of checking out an open source project, cross-compiling it from source, and doing hardware-level additions to our library for safe, process-based parallel programming called Plumbing. You can follow his work online (project overview, more posts coming soon), and both his software and documentation will be part of our pending release at concurrency.cc.

Last, but not least, Drew Pirrone-Brusse (Allegheny ’10) is working on Verbing Stories. Drew is pursuing a self-designed major at the intersection of Communication Arts and Computer Science, and this semester we are exploring Kodu (and, time permitting, Scratch) as platforms for interactive storyboarding in the context of game design and creation. While Kodu is not an open platform, we hope that our work will provide inspiration for others interested in the use of novice programming environments for interactively exploring the role of story in game development.

In later posts, I’ll point out where some of our infrastructure (repositories, etc.) live. In the meantime, I wanted to introduce the exciting projects that these students are engaged in. If you’re so inclined, you can also follow their work at planet.baseplate.org; for lack of a better name, we’ve named ourselves the Open Group @ Allegheny College, because we’re open to working with students on a wide range of projects, and we strive to make our work open source wherever and whenever possible.

Blogs: Stephanie/Sara (Operation: Stick Figure Army), Radu (Plumbing for the Arduino), Drew (Verbing Stories)

Planet: planet.baseplate.org

I’ve managed to do an initial packaging for Fedora of the toolchain that we use for programming the Arduino (see post with cool video). This is a big step—it means I’ve learned something about packaging, and it means we’re closer to being able to provide a really cool educational tool to the Fedora community. There’s still plenty of work to be done, but I consider this pretty exciting.

From the IRC:

04:57 < jadudm> 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
04:58 <@mchua> jadudm: yay!
04:58 <@humph> jadudm: !!!
04:58 <@ctyler> jadudm: congrats!
04:58 < jadudm> tyty

This is sweet, sweet awesomeness. This is the first time I’ve seen a packaging process for our tools through this way… while I’m not done, getting to the point that rpmlint gives me zero warnings and zero errors on a compiler toolchain is (for me) a milestone. I now need to clean this up fully, write a script to automate it (eg. checkout from SVN, tarball, upload, generate .spec file, rpmbuild, rpmlint), and then modularize that process for the AVR version. So there’s a bit more work to do, but it’s well within striking distance now. ctylers, ianweller, and others have been a great help in this process.

I haven’t collected many autographs in my life. In high school, my quartet had a chance to sing the Blackbird Medley with the Acoustix; they signed a CD for us. In grad school, I had the opportunity to meet Steve Jackson, and spent half-a-day geeking out over LEGO Mindstorms robots and giving him a tour of Indiana’s virtual reality environment; I asked him to sign my copy of Car Wars. While presenting at USENIX a few weeks ago, David Brin gave the closing invited talk, and I asked him to sign my name badge. Those are, to the best of my (flawed) memory, the only signatures I’ve ever collected.

While I didn’t seek it out this new set of signatures, that doesn’t diminish the awesomeness of the gift. The POSSE organizers got OSS authors to sign a copy of Fogel’s Producing Open Source Software. And there are a lot of signatures.

signed-book.jpg

A critical lesson from today is that these projects are open, and we can take part. The barriers to entry are low. That said, I know what kind of effort goes into the little corners of the open source world that I’m part of (occam-pi and the Transterpreter, providing support for Untyped)—many of these people are associated with projects that I use to get things done on a daily basis. That’s really humbling.

Overall, very, very cool.

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.

For the next three weeks, I have to friends and colleagues here in town. We’re busy hacking away, laying some foundations for the “next steps” in the work that we do surrounding concurrent and parallel programming languages.

It does mean that we have a very full house, but on the flip side, we’re eating well (everyone likes to cook or bake) and getting good work done so far. That, I suspect, will continue.

Especially the eating well part.

Speaking of which, I’m no longer frying, but instead burning, the mushrooms I have in the pan…

Twenty years ago, CNC machining was a black art. CAD-driven solutions were expensive, and program-at-the-machine was just becoming available. My first experiences with this technology were with my father’s 1986 Hitachi Seiki CNC lathe with Fanuc 5T control. It had a punched tape reader, and editing (once a program was loaded into memory) was on a per-line basis using a 9-key numeric keypad.


What looks like a Hitachi Seiki 3NE CNC lathe

Today is a different world. It is possible to draw, using free/open-source software, a 2D part and have it sent out to be laser cut by companies like Ponoko. You can take 3D designs and have them printed, or you can have them produced (on-demand, one-off) by CNC. You can even have them turned into molds through the same process for short-run (10-1000) injection-molding. For that matter, you can build your own 3D printer from open-source designs, or buy a kit that gets you moving in the world of personal fabrication.

I am fascinated by this space, in part, because of my experiences in my father’s shop. It is also as a computer scientist, and in particular someone who is fascinated with languages and robotics, that I see a great deal of potential. As these tools become more affordable (for play and exploration), they become not just tools of manufacture, but of art and creativity. Likewise, I can begin to think about how I would create a mid-sized, affordable robotics platform for use in and out of the classroom—without being entirely constrained by what I can purchase off-the-shelf. That is, I can actually design, and have produced, low-cost bracketing specific to my needs, if necessary.

So many toys, so little time…

Very insightful.

I'm going to USENIX '09

In two weeks, I’ll be giving a talk (along with Christian Jacbosen) at USENIX ’09 entitled Towards Designing Usable Languages. We’re excited about the talk, and it should be very, very exciting.

I believe the talk will be on-line when we’re done, so I’ll make sure to point to it. If you’re in the San Diego area, and want to try and get together, drop a note—the schedule will be tight, however. We’re in-and-out like a burger.

I’m a day late.

As we enter the fifth day of Matthew’s life outside the womb, I’m finding I do not have the time to craft a particularly eloquent essay on the topic of women and computing—Carrie and I spent the majority of the last night awake, and we both have long days ahead of us. (I get off easy with classes and meetings throughout the day.) So, we’ll go for short and to-the-point.

I will simply say that I am grateful to my academic parents—my colleagues at the University of Kent—and specifically Sally Fincher, my PhD supervisor, for the absolutely world-class mentorship I received. Further, through her work on the Bootstrapping and Scaffolding projects, the Disciplinary Commons, and the founding of ICER, I know that many other people have benefited from her knowledge and insight when it comes to computer science education research.