As a member of the faculty, it is often hard to justify spending time learning new technologies. This, to me, is a rather ugly Catch-22: to learn a new technology, I must justify it either with a publication or a clear, immediate application to my classrooms. If you’re driving towards a clear, concrete deliverable, it really isn’t exploratory learning… it’s work, under pressure, with a deadline. That’s why I’m excited about a project I’m undertaking this semester with one of our seniors.

The student was looking for a 2-credit independent study (this is roughly a 1/2 course load). We brainstormed a great deal, and in the end, the student thought they’d like to dig into some more Scheme programming, so we decided a compiler might be a good way to focus our efforts. However, I didn’t expect that it would end up being a project with so much potential.

At Indiana, I saw how we can write compilers front-to-back in the nanopass style. However, several grad students in the languages group insisted the right way to write a compiler was back-to-front. What does this mean?

First, you take your assembly language, and generate an executable.

In our case, we will be working with LLVM Compiler Infrastructure project. Specifically, we’ll begin by writing programs in LLVM assembly, and using the LLVM toolchain to turn that into a native executable.

Although our input language is not C, we might imagine starting with a simple program in our language LNOT (L0) that is nothing more than the number 8. A single expression. When compiled and executed, it should return the number 8. Expressed in C, this would look something like:

1
2
3
4
5
6
7
int main(int argc, char **argv) {
  int retval;
  /* Assign the result of our entire program to retval */
  /* In this case, the entire program is the constant 8. */
  retval = 8;
  printf("%d\n", retval);
}

The disassembled LLVM looks something like:

1
2
3
4
5
6
7
define i32 @main(i32 %argc, i8** nocapture %argv) nounwind {
entry:
  %0 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), i32 8) nounwind ;  [#uses=0]
  ret i32 undef
}
 
declare i32 @printf(i8* nocapture, ...) nounwind

As we are writing the compiler “back-to-front,” we now need to take one step backwards towards our input language. Because we are working in Scheme, we’ll represent our language in S-expressions (to minimize parsing effort). The first pass (or, the last pass, in front-to-back thinking) will be one that transforms an S-expression based syntax for LLVM assembly into actual LLVM assembly. Therefore, the input language to the penultimate pass might look something like:

1
2
3
4
5
6
7
8
(define (main i32)
  (args [i32 argc]
        [(i8** nocapture) argv])
  (entry
   (tail-call (printf (i32 (i8* ...)) ...))
   (ret (i32 undef))))
 
(declare (printf (i32 (i8* ...) ...)))

This elides many things, but my point is that we might take the ASM of LLVM and “lift” it into a syntax that can be easily pattern-matched in Scheme and manipulated. As we work from the back-end of the compiler to the front, our next step might be something trivial: for example, we might get rid of the entry form, because (with a very simple input language), we know we will only ever have one function, and therefore we can generate this automatically. Or, we might be more aggressive, and acknowledge that we don’t need to generate any of the wrapper code… so, we should only need to develop a language for statements that will proceed and/or live on the right-hand side of the retval assignment statement.

For me, it is exciting on a number of levels. I get to learn with a student, which happens less often than one would like. I don’t know LLVM, and am glad to be spending time getting to know it. Also, I haven’t ever written a compiler back-to-front, and evaluating this (both technically and pedagogically) has value — I’ll probably be teaching our compilers course next spring. And, I get to do some hacking, which I simply don’t get much time to do.

When we have a repository up, I’ll post a link to it, although it won’t be an “open” project, per se. We’re not doing this to engage in a new compiler authoring project so much as learn, but if you want to, you can watch us as we work.

This past year, I’ve been serving on a task force at my institution. Our charge is to investigate the intersection of technology and learning on campus, make recommendations regarding where we might focus our energy in the next five years, and (perhaps most importantly) recommend political structures that might then provide guidance and insight on an ongoing basis.

This post at CunchGear struck a chord. The author’s recommendations for new college students are (simplifying):

  1. Don’t buy a new laptop. Buy a used one.
  2. Install free software on it.
  3. If you want to play fancy games, use someone else’s fancy game machine.

Scott Merrill, the author, even addresses two major constituencies: engineering/computing-type students and liberal arts (literature, history, etc.) students:

  • [ COMPUTING ]
    No matter what you buy, you’ll probably have better facilities on campus. And networks are everywhere: remote into powerful machines.
  • [ LIBERAL ARTS ]
    You’re just typing papers and checking Facebook. You don’t need an expensive computer.

And do you know what? I think he’s right.

Sadly, institutions are slow to change. I would love to push for the following:

  • Install a free operating system on all public machines.
  • Offer a netbook/laptop programme that provides low-cost, robust laptops running open software. System76, for example, provides netbooks and laptops ready-to-go with Ubuntu. I’d love to have an EduBook to trial – my suspicion is that this little laptop would cut it for many students.
  • Establish a grassroots initiative to provide training and support for students. On my campus, we’re starting a learning/living community initiative, and I could see that new community structure playing a role in this way.

I might be able to go further in my recommendations, but that’s what comes to mind at the moment.

This re-statement/reflection on Scott’s piece was inspired by a post over at TeleRead. Chris at TeleRead closes with the following statement:

Perhaps the emphasis on college students having the latest and greatest technology should be reconsidered, at least from the perspective of giving them them the best ability to focus on the important thing—their education.

Now, making a bit of a 180º turn from what I was just saying, I’ll claim that this is a naive, sweeping statement that fails to take into account any of the realities or pressures I think many faculty feel in higher ed: students expect new media. Their world is made up of interaction and video, and we’re still giving them chalkboards. So when the sweeping claim is made that they should focus “on their education” (at the same time as you’re calling for new modes of interaction, collaboration, and problem solving), please consider what tools we’re currently working with, where the technology is headed, and how we might be leveraging that technology to improve our students’ learning experience. No one I know is considering technology for technology’s sake… but we’re pretty sure that there’s some really amazing learning we could be supporting… if we could just get the tools in the students’ hands.

The fact is, some of these devices do enable real-time, community-driven collaboration (many-to-many interactions) that simply were not possible a few years ago. Yes, I could photocopy a student’s paper and hand it out to everyone… but doing that with 20, 3-page papers means 60 x 60 pages (roughly 3600 pages). Using tools like iAnnotate allow students to comment on and mark up each-other’s papers instantly and digitally. And, perhaps more importantly, tools like that allow me to handle my digital workflow more easily. (I do not, at this time, own an iPad, but I’m reasonably confident that a lightweight tool designed for media creation, annotation, and consumption would be a boon on a day-to-day basis. Netbooks simply don’t cut it (for many reasons), and my 13″ MacBook is too big and has too short a battery to be practical.)

In my mind, we’re in a Catch-22 situation in higher ed: we can require our students buy tools that let them engage in distributed, real-time media creation and collaboration surrounding digital artifacts… but that implies that our pedagogic approach is going to change to support their purchase of those tools. Down that road lies a commitment to change when many think that we’re doing fine as it is. Or, we could adapt our pedagogy (which is fine as it is), but our students won’t have the tools to engage the way we want them to. How do you drive change in a system that is (at best) mildly elastic, but ultimately static and resistant to change?

I’m teaching a first-year seminar this year titled Creativity and Leadership. I’ll put the question to them. Perhaps they’ll come up with something.

This semester, we’ve introduced 40 students to the Fedora project . By “introduced,” I mean they have been introduced as contributors.

I want to point out that for me as a member of the faculty this is 1. hard, 2. a massive leap of faith, and 3. very, very exciting.

And, it is all of those things for our students as well. They’re blogging over at act.ivism.org, and I’ve written an introductory piece about their project on opensource.com. If you want to check out what they’re writing (and leave them some encouraging notes on their blogs), that would be awesome.

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.)

I admit it, I picked up a funny domain name.

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?

http://act.ivism.org/

OK, so it’s cheeze. But it’s some damn good cheeze.

I have aggregated all of their blogs at

http://act.ivism.org/planet.xml

which is managed through the magic of rawdog.

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 gave an introduction in Technology and Activism the other day to the Creative Commons. In that introduction, we (briefly) explored two thought problems:

[ music ] How long until you can own every song ever written? My first question had to do with music. If $60 buys a 500GB hard drive, you can put one year of non-repeating music on it. (I’m using the song Seasons of Love from the musical Rent to drive my calculation regarding the number of minutes in a year.) How long until hard drives can casually/affordably hold all music ever recorded? I put it to the students that they will likely see that day come within the next 10 years, at which point the way we consume music will certainly change.

The second though problem is much more interesting to me, however.

[ textbooks ] How much do you spend per semester on books? A quick poll of the class showed that the majority of the students spend between $250 and $300 per semester. Lets look at this picture:

201001280707.jpg

A publisher gives me a book for free. I like it. I assign it to all of my students. They then buy it, sometimes paying $120 or more for a single text (Physics, Math, Psychology, Biology, Chemistry, Computer Science… we all have runaway textbook prices that are crushing our students.) They send $300 every semester to the publishers. It is simple to see why publishers want DRM: they don’t want kill the cow that lays geese that lay golden eggs.

At a college of 2000 students, that means students are spending

$1,200,000

per semester on books. The college has no direct control over this cost, and there is no incentive for faculty to keep costs low for the students. I managed to offer both of my courses this semester using only Creative Commons licensed texts… but there aren’t a lot of those I can choose from.

The thought game became this: why haven’t small colleges come together and established a free press? They could hire an editor or two, some typesetters and indexers, and then commission books and short monographs and release them into the Creative Commons. Authors taking part could be rewarded better than any publisher could ever pay for this kind of material, and the impact on the educational world would be huge.

the ipad arrives

201001280716.jpg

The iPad isn’t a revolutionary game-changer, but no doubt Apple did some things right with its design. It does web and video well, and it is possible to pay on a month-by-month basis for connectivity to 3G networks. (Nice if you’re going on a trip and just want roaming wireless for a month.) And while $500 sounds expensive, think about it this way:

$500 is $50/semester for device and insurance.

If an institution commits to ebooks—meaning, all the faculty agree that they will commit to finding electronic texts to teach their subjects—we can slash student book fees drastically. We raise the floor, meaning they have a mandatory $50/semester technology fee. However, we then have 2000 students with a wireless slate that can display video, play audio, surf the web (campus WiFi), display PDF, Google Docs, read email… the list goes on and on. To me, it seems like a very compelling vision.

In terms of the device, I don’t really care if it is the Apple iPad or not. If Steve wants to send me one to use and evaluate, he’s welcome to. I’m a Mac owner, have a Touch, and think this could be an excellent device. But I also know that Mary Lou Jensen has developed some incredible technology at Pixel Qi, and an Android- or Linux-based device could do everything I’m suggesting just as well. So, put simply, it is currently an exciting time for devices that are bridging the gap from laptop to slate.

Peter Klein over at Organizations and Markets wonders aloud:

It’s easy to come up with examples of organizations run by jerks that failed, but do we have systematic empirical evidence that nice-guy firms finish first? Do the marginal costs of costs of placing rude, self-centered people in management positions outweigh the marginal benefits?

It is likely that Peter is already familiar with Robert Sutton’s The No Asshole Rule. If he isn’t, either 1. he’s forgotten what it is like to be a hazed and harassed junior member of the faculty, or 2. he hasn’t read it. In my experience, “assholes” (a technical term from Sutton’s text, which generally means what you think it means) are capable of slowing down a department or organization (by blocking forward progress on all manner of issues) and are happy to use their position to abuse or otherwise demean anyone who they view as less than themselves.

There is no value in an institution to people like this. His example of a “self-described Law school asshole,” drawn from Mendelsohn’s own reflection (PDF link) does not match Sutton’s definition:

University of Pennsylvania 3L Steve Mendelsohn (writing in 1990) tells his fellow students: “You know who we are. We’re the ones who always have our hands up in class volunteering to answer the professor’s questions, or ready to ask one of our own at seemingly any and every opportunity. Everytime you hear one of our names called, you groan and turn to the person next to you and slowly shake your head from side to side.”

This is not an asshole. This is an engaged student. Being passionate and engaged in ones subject of study is exactly what I want my students to do. I don’t want passive consumers of information in my classroom—which, it sounds like, is what the culture of law schools encourages. I want critical questions, I want debate, I want a room full of critical thinkers who use the time we have together in the classroom for more than consuming information that I pass on to them. When I want to do that, I create a video and point my students at it. It’s far more effective than giving lectures over and over.

People who are driven, who know there is a better way, and who work hard to achieve that even when it means shaking up the status quo—those people are not assholes. They’re innovators. Catalysts. Activists. They’re the people who make things happen in this world. The problem is, for someone who is passive, and just wants to leave well enough alone, the innovator is an asshole.

In short, I respectfully disagree with Klein’s terminology. Only in an industrial-age classroom, where the fount of all knowledge lives at the front, dictating from yellowing notes written before the beard was greying… only there can an engaged and passionate student be labeled an “asshole.”

Update, slightly later: Peter’s question is about organizations, not classrooms. I got distracted by his example. I doubt that “productivity,” “creativity,” or any other way of measuring the value of an employee necessarily correlates with whether they treat their colleagues poorly. (Highly productive people want to see others be the same; only assholes want to make sure that they are recognized as the local expert/value proposition within an organization.) I would be interested in seeing any research that demonstrates that middle managers or those throughout an organization who abuse their power, and therefore their colleagues (passively or actively), add substantial value to the workplace.

All boats rise with the tide. If my colleague is excellent, it makes my workplace better and my institution more successful, and I have a better chance of demonstrating my own excellence as well. Only those insecure in their person need to put others down or hold them back in order to define who they are.

In the preface to The Art of Computer Programming (1969), Knuth wrote the following:

100103-knuth-preface.png

I would posit that the vast majority of students who complete an introduction to Computer Science (often heavily focused on introducing the practice of programming) would not say that they felt they had been exposed to an aesthetic experience much like composing poetry or music.

This next term, I hope to work on developing a new course at Allegheny titled (tentatively) Digital Creativity. This course could serve as a pre-intro to the major, or introduce non-majors to the beauty of programming and computing, providing a collaborative, cross-disciplinary, and creative grounding in computational thinking using tangible, physical artifacts that students can relate to directly.

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.

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

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.