Barry Peddycord III

I recently read the book 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 (called 10 PRINT for short and pronouncability), which is a unique piece of work written by a host of authors including Mark Sample and Ian Bogost, that talks about a simple one-line program in BASIC that loops infinitely, drawing a maze of forward and back slashes on the screen until interrupted by a user. This book talks about the program, how the program was shared, and how it looks when it’s ported to different platforms and languages. It looks at programs as texts, and observes how the program conveys information in different ways across different machines.

I recently attended the Qualifying Examination of a fellow Ph.D. student on the topic of Microsoft TouchDevelop, a language that allows smartphone owners to write their own applications using a language and IDE optimized for writing applications on the smartphone itself. I could talk at length about the technical aspects of this language, but I’d rather focus on the cultural future that it seems to want to be a part of.

Often, when we think of programming, we think of people who make a career out of writing large, grandoise applications that they then sell to millions of people for millions of dollars. But the sci-fi movies told us the future would look differently. They told us that we would be able to say “Computer - play me a song I haven’t heard before”, and that it would do it.

We were told that we, the end-users, would write the programs.

When we think of the Commodore 64 and Apple ], nothing is more iconic than the BASIC interpreters that came with the device. We didn’t just expect programmers to write code, we expected that writing code would be part of the standard way that computers would be used. Computer enthusiast magazines often included one-liners and variants like 10 PRINT to encourage people to try out clever things and write useful programs for themselves to get basic jobs done. After all, when I write a program like

f = file("text.txt")
count = 0
for l in f:
    if "word" in l:
        count += 1
print count

all I’m doing is telling the computer, in its own language, “tell me how many lines in the file ‘text.txt’ contain the word ‘word’“. It might not be marketable, but it’s useful, and it’s easy enough for me to write it myself that I don’t need to find another tool to do it for me. In many ways, scripting languages like Python fill the role of these programming languages designed for end-users.

The problem is that they never took off. After all, when the GUI came into being, the text-based UNIX machines became the nostalgic memories of crusty old nerds who couldn’t get with the times. Instead of people telling the computer exactly what they need, they learn how to use monolithic applications that were designed with all of the possible situations it would be needed for that the developers could conceive. If there’s any end-user programming that we actually see these days, it’s the formulas in spreadsheets… why is that comfortable while using a Python interpreter is scary?

I don’t think TouchDevelop will make that future into a reality, but its creation shows that the idea of such a future is still in the minds of our technologists.

I’m currently wrapping up my final project for my English 890 course at Duke University on 21st Century Digital Literacies. This course has been tremendously interesting, and one of the reasons why is that we are collaboratively writing an e-book together to talk about what this class was all about. While I could write any number of things about this course, I’d actually like to talk about something I discovered during the writing process of this chapter.

In English classes, they always taught us that a “proper” paper begins by introducing a thesis, and then goes on to explain and justify it. Every piece of writing should come with a main point, and that’s something that can be seen in the way I blog. I generally have something I’m trying to convey, and I usually get to it within 500-800 words. However, this isn’t the way I always wrote. Sometimes I only had a vague idea about what I wanted to discuss, and then started writing in the hopes that something more profound would arrive while I put words on the screen.

The Duke class was an experiment. An experiment for me taking something completely outside of my comfort zone, working in a class with no clear expectations of what would be done, and pushing me to write in a medium I’ve never taken part in. I had no idea what to write for this chapter. So my colleague Elizabeth and I started writing with the idea that maybe something would emerge from it.

This style of writing is very much like writing a diary entry, where the creation of the artifact is done for the purpose of focusing the thoughts in the author’s mind and expressing what he or she is trying to say. The prose forces the author to linearize the decidedly non-linear structure of the mind, since forcing this realignment has the side effect of making one think consciously about the thoughts in the back of the head. This allows old ideas to be refreshed, mixed with newer ones, and left to simmer again.

The thesis then comes at the end, as though I finally figured out what on earth I was trying to say. The reader becomes a guest as they take that ride - learning as much about me as they do about the topic I’m writing about. In a blog, this is the perfect way to write, since the subject of the blog that I am trying to convey through my work is me.

I’ve been working on #8bitmooc for about 3 months now, and the process by which I develop it has been raising some interesting questions about my development habits. I’ve been teaching our Junior-level Software Engineering class lab section for the past year, and part of what we preach is how important test-driven development is. We give students a mostly strong set of requirements that they are to code to, then they compose acceptance tests to ensure that when their coding is done, it does what we asked them to do.

For #8bitmooc, I really wanted to use some of the practices I’ve been preaching to my students for the past year. I really wanted to use version control, proper testing, and so forth. But there’s one big difference between CSC326 and #8bitmooc: I had no idea what I wanted #8bitmooc to be.

In game development, the key thing that’s discussed is rapid prototyping: getting a user interface that has minimal functionality working as quickly as possible so that you can see if you like the way everything fits together. The design or structure may change multiple times, but that’s OK, because the “ideal” project will emerge after enough tests. For highly interactive projects like games, rapid prototyping is essential since there’s no way to tell what’s fun or works well until you have it on the screen and you start playing with it. A good game isn’t made after months of planning and requirements specifications, it emerges naturally as prototypes are played and tested with human beings.

Test driven development requires you to know what you need before you start making it, and that’s a luxury I don’t have with this project. As such, while I do make tests, those are often surface-level tests that are designed to let me know if something that I change breaks something that used to work. They exist for regression, which makes them a bit on the weak side (since I’m able to make pretty large commits without breaking tests, telling me that my testing suite needs some improvements).

I suppose the proper thing is to do it in a scientific way: figure our what you want to make, decide which files are going to be changed, and start writing tests for those files. That way, I ensure that the tests are always there. The worst tests are the ones you don’t write, and as we start approaching prime time, I’m getting a little nervous about how things are going to fit together.

Bootstrap is God’s gift to people who need to do rapid prototyping for websites. Heck, this blog and my teaching portfolio are basically rapid prototypes of a website that I’ll end up designing later. They have all the essential information, which makes them good enough for me. I love making web apps in Django, too, since the testing is super-easy to do and working with the database doesn’t take any effort at all thanks to Django’s ORM. Python itself, with its interactive shell, is also a rapid-prototyping must-have.

Hello, world! Welcome to my new blog, powered by the magic of GitHub pages and Jekyll. This marks the second time I’ve switched blogging platforms this year, but I think I like this best of all, even if the website looks terribly hideous at the moment.

In February, I left my Wordpress blog after two years of writing. It was a hard move, since I started that blog on the very first day of Graduate school. Things were crazy back then, since I didn’t really know what I wanted to do at the time. The blog served as an artifact to help me develop my identity as a scholar. After finding a research direction, an advisor, and figuring out what I wanted to do for my dissertation, I didn’t really need that blog any more. That blog was personal, it was for me. Now I need to develop a blog for the world that’s about me… and most importantly… about my research.

After packing things up, I decided to try Tumblr for a change of scenery. I have to say, I really love the Tumblr ethos. The culture of asking and reblogging is something that I really wanted to be able to participate in, and following blogs in a centralized dashboard made reading much more enjoyable than trying to read through posts in Google Reader (which is slated to be discontinued this summer, to my great disappointment). It was lots of fun, but when I realized that my blog was full of Les Miserables animated GIFs, I started to think that maybe I didn’t exactly want the first impression of folks who find me online to be that… informal. :)

So now I’ve set up a Github website, which is awesome for a number of reasons. First of all, I feel like if I’m not using all of the functionality of a system I use, then I’m wasting it. This is an extremely bad habit of mine, but in this case, I’ve managed to justify it. I always preach about being open and about the Github and forking model of developing code to be the best thing in the world, yet I haven’t done any of my work in the open until I started working on #8bitmooc. By putting my website on Github, this will encourage me to be in the Github environment more often, and (optimistically) my productivity will improve.

But wait - there’s more! As someone who dreams about becoming a professor one day in the future, part of that dream involves me building my very own research lab full of Grad Student minions. For the longest time, I’ve always struggled trying to think of how to maintain an online presence for a research lab. While I was originally thinking a Wiki would be a good idea, it makes much more sense to just do our work and maintain our image in the same environment: Github! By setting up a Github organization for my future research lab, it would be possible to maintain project repositories, set up an internal research wiki, assign tasks via the issue tracker, and keep a lab blog. The ideal work environment allows us to manage our internal and external workflows with minimal overhead, and whether I decide to be a Computer Science or Digital Humanities professor, Git (or whatever version control happens to exist ten years from now) will be a required literacy for all of my future students.

However, that’s a bit down the road. For now, I’ve set up two new Github projects to maintain my Teaching and Research portfolios. The especially cool part about having a teaching portfolio in Github is that the website serves as a polished presentation format for the portfolio, but has the option to download the complete portfolio (maintained in its project repository) as an archive. My old teaching portfolio was hosted on my Wordpress site, but I feel like moving it to Github would not only be more efficient, but would be an excellent way to make mine stand out from others.

So here’s to a long, productive life with Github. Now to do something about this ugly bootstrap theme.