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:

  1. Why blog?
  2. What to blog?
  3. When to blog?
  4. Who will read your blog?
  5. 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.

333979587_3132877a00.jpg
Reindeer Cat

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.

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.

For some time, friends and I have been making a list of military pun names. Some of them are assigned to people already; some of them are not. Recently, we allowed royalty… we’ll see how that goes, though.

Taken

Major Disaster

General Knowledge

Colonel Panic

Private Parts

General Principle

Corporal Punishment

Seaman Stains

Free

General Consumption

Major Contribution

Major Corrections (or Major Revisions)

General Direction

General Discussion

Major Distraction

General Encouragement

General Enough

General Failure (as witnessed on a coffee machine)

General Fatigue

Major Growth

Dame High

General Ize (contributed by humph)

Colonel Package

General Practice

General Plan

General Protection Fault

General Readability

General Vicinity

Update 20090724

Major Highway

Update 20090726

General Issue

Building Mozilla Minefield took 60 minutes on my Fedora 11 VirtualBox VM. The VM lives on an external USB drive, so given the I/O and everything else, that’s not so bad.

20090722-minefield.png

By “not so bad” I mean “that’s rather slow,” but all things considered, it will make working with things this week far easier than running everything remotely on a VM on fedoraproject.org.

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.

Omer Kilic (twitter)is now a PhD student at the University of Kent; I had the pleasure of working with him while I was there doing my degree a few years back. (In fact, Omer’s excitement about embedded systems is part of the reason why I finally got over my own fears about real hardware and started playing with small systems like the Arduino.) Adam Sampson has hooked him up with our nascent Plumbing library for the Arduino, and he has some tasty-tasty blinkenlights going on:


Parallel Blinkenlights! from Omer Kilic on Vimeo.

I’ll try to get a website and some getting started information up on the web in the near future. Plumbing is a library for handling input and output on the Arduino in a parallel-safe way, using the occam-pi programming language. The code for the above example probably looks something like this:

PROC main ()
   PAR
    blink (13, 500)
    blink (10, 400)
    blink (7, 600)
    blink (4, 300)
:

How do you do that?

For a number of years, we’ve been working with a language that is fundamentally parallel in nature. More importantly, the Transterpreter was at the core of Christian Jacobsen‘s doctoral work. The Transterpreter (other than having a really cool name) make it possible to run occam-pi programs on really tiny devices. The Arduino is an example of what I mean by a “tiny” device.

While I don’t know exactly how fast Omer is blinking the lights, I know he is blinking them in parallel. This means that they are blinking at the same time. When programming in occam-pi, you pretend that it is possible to do things simultaneously by writing PAR, and then you let the tools take care of everything else for you. I only say “pretend” because the Arduino only has one processor—but, despite this, we write PARallel code in occam-pi and let the tools take care of things, regardless of whether we have one processor or one thousand.

As a result, blinking four LEDs is one of the easiest things in the world to do. As you can see, Omer is blinking four pins at different rates of speed, all underneath one PAR block.

Open-source is Awesome

Everything we work on is open source (GPL/LGPL), and we have the first few chapters of a book drafted to support people learning with these tools. We’ve aimed the book at artists and (people are assuming are) non-programmers. That doesn’t mean we’re talking down—it just means we’re writing lots of tiny chapters that expose just one thing at a time. I’ll work on getting some minimal website up for the materials, get some mailing lists set up, and see if we can’t get a few people playing with the fun stuff. I wasn’t planning on releasing things this soon, but it looks like we’re starting to see a bit of interest. That must mean… it’s time to release!

You see, right now I’m out in Raleigh, NC taking part in POSSE (Professors’ Open Source Software Experience), which is graciously being hosted by Red Hat through the auspices of gdk. As Dr. Panic points out in his blog post about packaging software, I chose to do something other than “Hello, World” yesterday. I decided I’d try and get all the tools we need for the Arduino packaged up as a Red Hat package, so RH users could download things and dive in. That took a long time, and I’m not done yet… but I’m making good progress! Sadly, I can’t run myself under a PAR block… I’d be able to get so much more done…

We’ll get stuff online, and others can join in the fun. That can be part of tonight’s homework… along with everything else the POSSE organizers have us doing.

Packaging software takes a long time.

Most of the afternoon and evening, my screen looked like this:

20090721-packaging.png

Now, I have a headache that won’t go away, and it still looks like this. I suspect it is a combination of things, so I’m probably going to crash out early and get up early to continue packaging.

I’d love to have a good package of our Arduino tools, but I don’t think I can stay up and haxor it. My head just hurts.

Ah! Unto us a package is born!

The firehose is tough to drink from.

Dave showed us Planet Mozilla. Chris is showing us Planet Fedora.

The volume of information available is huge. But, I’m particularly interested in the fact that students can quickly/easily begin joining a community on the periphery. Through IRC, mailing lists, and aggregators, students can get up to speed quickly on topics they’re interested in.

I’m especially interested in the fact that the Fedora project has an open PR project. The fact that students in a liberal arts context can engage widely across these projects is something I have to keep thinking about.

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.