Remember: these are first-year students in a Freshman Seminar who have not declared their course of study. Despite that, they’re diving into IRC, wikis, blogs, mailing lists, and sprints as they rapidly come up to speed on contributing to the Fedora project. I don’t think they have any idea just how big a jump this is for some people. And because they don’t know it’s a big jump, they’re just jumping.
Give em’ some props. (Or, leave the props here, and I’ll pass them on.)
Allegheny College has a Freshman Seminar series where students engage in writing and speaking exercises that explore a subject in the context of the liberal arts. Darren Miller (Art faculty) and I linked our seminars (mine is titled Technology and Activism, his is Art and Activism) so that we would come together as a large group on a regular basis, while breaking apart into smaller sections for discussion and debate on related but different themes.
The role of openness plays a critical role in my course. Every text I required was Creative Commons licensed, and we will be talking about the Commons (as well as notions of openness in software) throughout the course. This is, in part, because contributing work to the Commons is a kind of activism. Further, we wanted to introduce our students to the tools that open communities use to communicate and enact change in the world. The first tool we introduced them to was the weblog.
I was surprised at how few students were familiar with weblogs. Clearly, an assumption on my part that all of my students today have at least five blogs and seventeen Twitter accounts. Who knew? So, there are now 40 new bloggers in the world. (They also learned what an RSS reader is.)
To do this, though, we didn’t use private blogs in Sakai. Instead, I set up a WordPress-mu instance, and created accounts for them. The best part?
I’ll write more later, but I’m leave with the teaser that I’m very excited about our tie-in that we managed with Mel Chua, one of my POSSE wranglers last summer, now member of the RH Community Architecture team. She’ll be visiting later this term, and we’re going to do some Great Awesome with the students. At least, that’s our intent. Forty students will be introduced to the goodness of Fedora, but not in the way that you’d expect…
I am excited to announce the release of Plumbing, software and documentation to support artists and makers in the programming of low-cost, open-hardware
platforms like the Arduino. The Plumbing libraries are a collection of parallel components written in occam-pi , a small language with a long history.
Last summer, we decided that it was time to bring six years of work regarding runtimes for parallel languages to the Arduino, a popular open platform for exploring the of art, electronics, and computing. In doing so, we decided that documentation would be critical in this effort. Documentation became a focus because we decided as a team that users matter. In designing and documenting Plumbing, we kept our focus on the students, artists, and makers who might do something amazing with our tools.
I think we’ve taken some substantial risks. Many people have contributed many thousands of hours of development time in our software (to say nothing of the years invested in occam-pi), and we will soon be releasing hardware as part of this effort as well. For me, the most substantial is the commitment to publishing our book, Plumbing for the Arduino, under a Creative Commons BY-SA license. That means that anyone can modify, distribute, and sell our work, as long as you give us credit.
Giving our book away is substantial because publishing is part of how academics are evaluated and keep their jobs. By giving away our book, we must now convince our respective institutions that publishing under the Creative Commons will force us to produce a better product (on an ongoing basis) than editorial review would, as well as reach more readers than if we found a publisher (who would then claim copyright over our creation). Or, we must find a publisher who is interested in helping develop and market our text while allowing it to continue to be available under a free and open license. (If you know one, please have them drop me a note to me at matt at concurrency dot cc.)
concurrency.cc and the materials made available from that site have been in development for years. I’m glad to finally see everything settling in place so people can easily download and explore the tools we have spent so many years working on. If you do, let me know how things go. (We’ll have mailing lists up soon, I promise… but for now my job as a professor calls, and it’s going to be a busy few days…)
Thanks to Dave Humphrey, GDK, and the rest of the POSSE crew. For months the encouragement to just release! has been kicking around my head. That message helped keep us on track as we reworked build systems, wrote text, built websites, and generally did all that stuff that no one thinks about when bringing a project together.
And we’ll get a Fedora RPM done as soon as we can. (In the meantime, you can build from source like the rest of us.)
Greg Wilson recently posted about student learning, specifically with respect to studying from their own lecture notes. He received some advice from Brock MacDonald at the Writing Centre at Woodsworth College. Brock gave Greg some very bad advice about qualitative research, based on what Greg passed on in his blog (emphasis mine). Here’s some of Brock’s advice:
Empirical evidence for the value of students writing their own assignment specs is harder to come by, because it’s less amenable to direct testing (like most aspects of teaching writing)–the support is more qualitative than quantitative, hence more open to question.
…
both Elbow and Bean refer to quite a bit of supporting research, though as I said it’s mainly qualitative.
Let me set the record straight here: qualitative methods are excellent research tools. They can be applied correctly or incorrectly in any given situation, and the analysis of a qualitative study can be carried out poorly or it can be performed with skill. Qualitative methods give us access to the why of social settings things in a way that statistical methods are hard pressed to do with any rigor whatsoever. Put simply, qualitative and quantitative methods both have a place in research, and we should no more dismiss one than the other.
For Brock to say that a piece of research is “open to question” simply because of the methodology used demonstrates a lack of understanding of the methods involved. We do not evaluate research simply based on the methods used, unless the method employed is inappropriate to the question being asked. We do not consider either qualitative or quantitative research to be flawed unless the method was inappropriately applied or analyzed. And that is not what Brock said in his note to Greg. He just implied (strongly) that the research was questionable simply because it employed qualitative methods.
Peer reviewed qualitative research is not “open to question” as a general rule. (Or, it is always to be challenged… but that is ideally a challenge issued by experts through another research study.) Qualitative research has rigor, and clearly addresses the questions asked in the context they were asked. Unless you’re going to develop expertise enough to evaluate the research in question, accept it as having been executed by people with expertise, undergone peer review by experts, and see for yourself what the research says to you about your specific educational context.
That is a concurrency.cc Arduino-compatible board fired up and ready to go. As you can see, the vias aren’t really lined up that well, which may account for some intermittent USB-to-serial weirdness that he is chasing down at the moment.
Awesome job, Omer! If all goes well, I think we’ll have around 40 to 50 students at Allegheny building their own computers next semester in courses I’m teaching or co-teaching, another handful at Kent, and who knows… perhaps I’ll find another place to bring these into my students’ experience next term.
I remain hopeful that our final boards will be purple, and that the ability to expressly direct parallel code for an affordable embedded platform like the Arduino will be of use to many. One step at a time, though: we need to get revisions done on our existing book chapters, write the next five we have outlined, get Windows and Linux distributions done… it seems like a lot, but we’ll get there.
I’ll have to write a longer reflection at some point, but the long and short is that I’m very excited to see our project coming together on multiple fronts for distribution: robust software, source-to-binary builds, hardware that showcases our tools, and a text that provides structure and guidance for non-programmers to get into hardware exploration one small step at a time. When you start a project like this, you want all of these things from the start… but sometimes, it takes lots of small steps, side explorations, and unsure starts to get you to where you want to go.
For years, my colleagues and I have been working on lightweight runtimes for parallel languages. To put our work in context, we’ve often targeted small robotics platforms like the LEGO Mindstorms for demonstrating the power of a parallel-safe language for real-time systems. This summer, we realized that the Arduino was a marvelous, open-source platform with an energetic community of developers and users, so we ported our language and tools to the Atmega328.
We have a Mac environment done, are working on Windows, and will have a Linux release by January. This, however, is quite exciting:
Omer (Vimeo, Twitter), a PhD student at the University of Kent and our resident hardware guru, did a modified Arduino design that includes more LEDs (along with a few other nice changes, like a mini-USB connector and a lower-profile power jack that will easily work with LiPoly batteries). The extra LEDs are important, because we wanted a board that made it easy to demonstrate the power of a parallel runtime right from the start without any additional/external components.
I’m especially excited about being able to buy these in bulk and sell them to students at cost for use in classes. Next semester, students in Programming Languages as well as my second-semester first-year seminar titled “Technology and Activism” will build and program their own computers. It will be awesome.
We currently have placeholder material up at concurrency.cc, but soon we’ll have binaries of all of the tools and documentation up that let you start writing parallel programs for your Arduino!
Operation: Stick Figure Army is a project that will provide tools for converting 2D imagery (as typically found in many introductory computing texts) into 2.5D representations: physical tiles with raised and textured surfaces that represent one or more diagrams from a text. This lets us explore, as a group, image processing, 3D printing, and the process of creating usable software for a target class of user.
The project is being carried out by two students at Allegheny and one student at TCNJ. Sara and Stephanie (Allegheny) have spent this semester learning Python and basics of image manipulation, recently posted their experiences while exploring Blender’s Python API (so we can automate the process of 3D object generation), and are beginning construction of their Cupcake CNC 3D printer. Cory (TCNJ) has also begun looking at Python, and is (at the moment) providing critical reflections on what it is like to be a blind student of computing.
His most recent post on the project blog, How to cope with the design phase?, explores the notion of visual representations in computing. I found his reflections interesting for two reasons. First, it reminded me of a paper by Marian Petre and Alan Blackwell titled Mental Imagery in Program Design and Visual Programming (PDF) (International Journal of Human-Computer Studies, 1999 (51) p7-30). They explore the role of visualization and visual language in expert programmers, and while the paper is too rich to summarize concisely, I’ll pull most of a paragraph from the conclusion here:
There has been a great deal of confusion in the visual languages community about the relationship between mental representations of a design and the programming notation. As noted by Green, Petre & Bellamy (1991), the superlativist position (claiming that visual languages always improve performance in programming tasks) is not justified by experimental evidence. Blackwell (1996a) has analysed the variety of beliefs among visual language researchers about the cognitive effects of using different notations. These tend to range far beyond the practical benefits of the notation or the programming paradigm, but their statements about mental representations bear little resemblance to our findings in the present studies.
Put simply, we tend to get all hot and bothered about visual tools, but research doesn’t imply that this is always a Good Thing.
The second aspect of Cory’s post that I thought was important to reflect back was the importance of verbal communication in software design and development. Whether it is aural or written, being able to express ideas about the design and implementation of software is critical to students of computing today. In some circles, this comes out in the context effective communication and collaboration in teams (Begel/Simon, Struggles of new college graduates in their first software development job (PDF), ACM SIGCSE 2008). Regardless of whether it is a software team at Microsoft or a distributed, community-driven effort surrounding open source software, the overwhelming majority of our communication and collaboration regarding software developing is written/verbal, not visual. That is, we’re not shipping pictures back-and-forth 24/7—we’re chatting on mailing lists, IRC, and blogs to get things done.
I think these ideas say a lot about where we are failing in terms of computing education today, but that will have to be the subject of another post. For now, I found Cory’s words thought-provoking, and wanted to reflect a little bit on what he had to say.
RedHat has kicked off another POSSE, this one on the other side of a continent and an ocean from where I live. (The faculty have come together in Singapore… I hope my travels take me that way someday!) I’m looking forward to seeing what they have to say, and what their experiences are like. Their blogs are online, and I’ll be doing my best to keep an eye on them over the coming days, weeks, and months ahead.
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)
So, your professor has said those awful, fateful words: “You should have a project blog.” While all the cool kids are tweeting their thoughts, you’ve been shouldered with this ponderous blog; worse, you have no idea what to write in it, or who is going to read it.
Fear not! This quick guide (written primarily for students at Allegheny College who have been encouraged to blog as part of project work in the Department of Computer Science) will give you some context for:
Why blog?
What to blog?
When to blog?
Who will read your blog?
How to blog?
A quick search of the ‘net did not turn up a similar guide for students, so it is my hope that this is a useful resource. If you’re a student getting started blogging and are looking for a few pointers, read on.
Why blog?
Your professor suggested you maintain a blog for all the reasons mentioned in this document, plus a few relating to the fact that your professor is lazy. First off, your professor would like to know what you’re up to, and would most like to see those notes come by in their RSS reader (wiki). Second, your prof wants other people around the world to be able to keep track of the awesome projects you’re working on, and RSS is the little XML file that makes it all possible. You’ll want to use an RSS reader, too, but all in good time. This is a guide to writing blogs, not reading blogs.
Second, your prof wants your work to be visible to the world. This is because your prof is a marketing genius. Using an RSS aggregator (wiki), your professor is going to link your writing in with other students, and tell all his/her friends about what awesome stuff you’re doing.
Now, you can probably infer how this blogging thing is good for you. The most important thing is that your blog provides a way for you to capture your thoughts, link to inspirational/informational resources, and get feedback from others in your community of practice (wiki). It’s like a lab notebook, but you can embed images and video really easily, and other people can help fill in the blanks when you get stuck.
What to blog?
You can write anything you want in your blog, but you should probably think about the fact that Google and the Internet Archive have long memories. Also, someday, a potential employer might read what you have to write.
HOLYCOWWHATDIDTHECRAZYPROFGETMEINTOTHISTIME?!?!
Your blog is your space. You can write about your cats, or other people’s cats, or even repost awesome videos about cats from YouTube. For example, I’m a fan of Keyboard Cat:
You might write about politics, the media, music, food, or any number of other things on your weblog. You should probably sneak the occasional post in about your project, though. With regards to your project, you should write about your brainstorms, your explorations and experiments, any reading that you do, responses to other people’s posts, and successes you have along the way along with mistakes and dead-ends that you explore.
Throughout all of this, don’t be afraid of the hyperlink! When you read something useful, link to it! When you are inspired by someone else’s blog, link to it! This will be valuable to you later (when you go looking back at your own writing), as well as help your reader gain valuable context. Linklinklink!
To help your prof keep track of what you’re writing about any given day, you’ll want to use the tagging feature of your blogging software to make sure that you keep videos of Keyboard Cat in their place. For example, you might tag posts about cats as “lolz”. When you’re brainstorming new ideas, you might tag new ideas as “brainstorms”. When you’re writing about things that tripped you up, that you don’t want other people to discover the hard way, you might tag mistakes as “oops”. And you can give lots of tags to a single post, so one post might end up in several categories. For example, when I write a post about using the Arduino and the Transterpreter, I end up tagging it as “computing,plumbing,opensource,arduino,transterpreter”. Sometimes I mix in other tags… I’m not very consistent, really, but I try.
Ultimately, if your blog is specifically about a project, then keeping it “on message” will probably make the people reading it happier. However, it is your blog, and you should use that space however you see fit.
When to blog?
You should update your blog when you have things to say. If you’ve finished reading a blog post, web page, article, paragraph, chapter, or book that inspired you in some way, capture your thoughts! They might not be refined, but you can say that in your post:
“I just finished reading One Fish, Two Fish, and I realized that Dr. Seuss was totally talking about power management for embedded devices! These ideas are a bit raw, but here we go…”
In short, use your blog to capture thoughts that are in-progress, or perhaps to capture things you’ve been mulling over for some time.
But also remember: your blog is more than text! Capture images, video, and other media about your work whenever you can. Human beings are highly visual creatures, and the more pictures and video you can work in about your work, the better. Drawing diagrams forces you to organize your thoughts… sketch them on paper and scan them in! Or, just snap a picture with your cell phone camera. In short, don’t get hung up on things being perfect—just get the idea out there.
Oh, and remember: if you’re over 21, and you consume beverages of an adult nature, don’t blog when you’re drunk. It’s always a bad idea. Especially in light of the question…
Who will read your blog?
Your prof is going to ask you to designate one of your tags as the tag that gets fed into the aggregator. If you’re blogging a senior comprehensive project, then you might use the tag “comp” for everything that is related to your comp. These posts will get pulled into an aggregator, and potentially be read by your classmates, other faculty at your College, and possibly people around the world.
If your work uses tools that are part of a larger, open community (for example, if it uses the Arduino, or involves working with open source software like the Mozilla Project), then it is possible that people in that community will be following your work. This is a great, great thing! When a community starts paying attention, it means people think what you’re doing is interesting, and they might even begin suggesting new ideas that you had never considered. Never underestimate the power of an engaged community.
Thinking forward, potential employers may find what you’re writing. They might find it after you’re done with your project (perhaps because you included mention of your blog in your resume), or they might find your writing before you’ve even met them! Perhaps, because your work is awesome, they decide that they need to hire you. Mind you, this isn’t exactly common (I’m selling bridges in Brooklyn over on my own weblog if you’re interested), but the fact remains: you’re demonstrating your ability to communicate in a concrete, public way.
How to blog?
Some people (like me) use a native application for blogging. For example, on the Mac I use Ecto. Under Windows, I’ve used w.bloggar in the past. Some people use the web-based interface that comes as part of their blog (eg. the Javascript-based editor in WordPress). At the end of the day, you should choose the tools that work for you, and let you get the text out as easily as possible.
That’s it!
There is either nothing more to say, or everything to say. In the case of the former, I should stop writing, and you should start. In the case of the latter, you should start writing. So, either way, its time to get started. Write what you think, in your own voice, and you’ll be part of creating a more informative, interesting World Wide Web.
Now go!
Last Update
Suggestions for improving this post are always welcome. This post was last updated on July 27, 2009, 17:23 GMT-5.
