This is an excellent, and simple, analysisacrobat of the dangers of eVoting.

From the conclusion:

Electronic voting machines present an opportunity for fraud in the form of widespread subtle manipulations. The master copy of the voting machine software can be programmed to misrecord or misreport one or a few chosen ballots. Where an election saboteur formerly needed to individually alter thousands of ballots, he or she now only need introduce a small change in the master copy of the voting software, which will be deployed on all of the electronic voting machines. As Mercuri noted, “Whereas earlier technologies required that election fraud be perpetrated at one polling place or machine at a time, the proliferation of similarly programmed e-voting systems invites opportunities for large-scale manipulation of elections.”[5] Our analysis demonstrates that even a trivial example of this kind of fraud can be effective.

Dare I say it: should we be surprised if Bush wins on Diebold voting machines, where public review of the code running on them has not been allowed?

And they call the US a democracy. Bah. There is no democracy without an open, secure voting process and a healthy, vigorous media to keep the public informed. Instead, we have a closed, broken voting process and a corrupt, biased media content to spin.

Hopefully, my vote will count the way I intend it to count.

Found on transterpreter.org, via Cool Stuff in Computer Science:

We asked the students taking part in the Cool Stuff in Computer Science project if they would be willing to blog their experiences using occam on the LEGO Mindstorms. So far, I (Matt, slinker wrangler) have been writing about CSCS as it progresses this term on my own weblog. Another Matt (we have around 700 of them in CSCS this year) has started keeping track of things over at blog.qualityerrors.net. His first post is a back-fill for the last few weeks.

As we see more blogs on this topic, we’ll mention them here, and try and get a coherent page of links together (or perhaps a blogroll somewhere on the margins of this page).

Thanks, and welcome, Matt!

All right, this is a bit much; I’ve just replicated my own weblog post across three blogs, and yes, I feel dirty doing it. However, I am pleased that at least one of the students taking part in CSCS took us up on our request, and was willing to keep a weblog of their experiences using occam on the LEGO Mindstorms.

This is really kinda cool in a lot of ways, I think. We have me weblogging about our experiences running CSCS, there’s a variety of forms of information regarding the transterpreter (bug databases, weblog, papers), and now we have one (and hopefully more) students exploring their experiences with the technology as we work with it.

As someone helping develop the technology, as well as develop and present material related to it, it’s going to be nice to have a closed feedback loop, where we can go and see what’s going on from the student’s perspective. This kind of timely feedback can be invaluable both from an instructional point of view (“Was that clear? Did they get it?”), and from a technological standpoint (“Is the technology working? Do we need to think about evolving our libraries/APIs/etc.?”).

From a technological perspective, this is a slow, inefficient, distributed kind of API usability testing like the work carried out by Steven Clark and the rest of his colleagues at Microsoft. From an instructional perspective… certainly there’s some educators out there doing this already, no?

I’m completely unable to sleep tonight. I tried between the hours of … two and five AM to no avail.

So, in better news, the paper “Towards concrete concurrency: occam-pi on the LEGO Mindstorms” was accepted at SIGCSE 2005. The pedagogic philosophy presented in the paper is in keeping with Teamstormsacrobat, a theory of instruction I developed while at Indiana. Unlike previous descriptions of this approach, I think it was stated as succinctly as possible in the paper: learning should be authentic, constructive, and fun. Clearly, the Papertian and constructivist influences here are strong.

pmlab3.jpgThe technology Christian and I have developed to support this philosophy is called the transterpreter. The transterpreter is a run-time for the LEGO Mindstorms that lets students easily develop concurrent programs in occam for small robotics platforms. Why is this significant? Little robots, while they seem to be toys, have real problems in the real world. Having a language that lets you say simple things about concurrency simply (and even reasonably complex things quite simply) is critical.

We are exploring using this technology with the students in the Cool Stuff in Computer Science group this year. This exploration takes us boldly (foolhardily?) into the unknown, both with the technology and with the pedagogy. So far it has proven to be exciting, and we hope that our approach and tools prove valuable to the students, enabling them to achieve creative feats that might have been unattainable otherwise.

If your students don’t do their homework, you can’t move forward.

I had hoped that my students would have spent significant time this week wrestling with material, but that was not the case. <RANT>I must admit, the excuse I like least is “my computer isn’t working.” Personally, I don’t care: get it fixed. Work somewhere else. Buy a Mac. Anything that gets you moving on work for the class you signed up for.</RANT>

It’s one thing when I’m dealing with undergraduates in large quantities; I expect things to be a bit different with a small number of adults. Anyway. I’ll stop ranting.

I think the session was still valuable and productive; we stepped through the drill-and-practice tutorials slowly with respect to how the code the students are writing relates to their interactions with the BlueJ environment. I do think that this is one of the difficult things about teaching programming: learning to see source code as an expression of run-time behavior. When I look at a piece of code, I immediately have a sense for what it will do when the program is running. When my students (who are just learning to program) look at a piece of source code, I have no idea what they think. Clearly, they don’t immediately see what (for example) the constructor does, and the effect of each method (in isolation), as well as the state of the object’s fields depending on the order of method invocation.

In short, I have a machine model in my head, and I can run programs on that machine. By looking at the source code.

Do my students need to learn to do this to learn to program, and if so, how do I help them achieve that? Time to hit the ACM Digital Library on topics like “machine model,” “program tracing,” and “run-time comprehension.” I’m not optimistic about what I’ll find.

Only vaguely related to my work, but the authors are using the analysis of data collected re: student use of online discussion forums to inform pedagogy.

To be revisited.

From Rob’s weblog, a second-year participating in CSCS:

I’m waiting up to watch a potentially interesting episode of Horizon, about what killed the dinosaurs. I really like science-y type programmes but am out at CSCS on Thursdays and havn’t yet been able to make it home in time to watch any episodes of the new series of Horizon. We were planning to leg it down the hill last week but unfortunately the attraction of (to a greater extent) Lego and (to a lesser extent) Occam (just kidding) meant we stayed a bit longer.

Emphasis is mine.

That’s it, folks: CSCS is better than science-y type programs on television. I can retire happy now.

This Saturday, I spent the day down at Christian‘s prepping for Monday’s class. Around 5, Damian and I wandered up the hill to grab a table that we were going to bring down for his room.

Little did I know, I was walking up the hill to find nearly 40 people in the house. They all screamed “Surprise!” when I walked in… and, yes, I was surprised. I was particularly surprised to see Carrie there, as I didn’t expect I’d see her again for some weeks. As a result, I had the opportunity to spend Sunday walking around Canterbury with her and a good friend from Kenyon who is now doing a Masters up in Bangor.

It was an excellent party by all accounts; a chronicle of the newly acquired loot will be necessary. However, for the moment, I’ll leave you with the network diagram for the planning committee that put the event together put together by Mr. Green. Absolutely excellent.

network01.jpg

(The little picture of me in the upper-left is the look on my face when I walked in the door. I swear, I wasn’t that surprised, but… well, you decide. )

It’s an odd dichotomy; on Mondays, I’ve been doing very drill-and-practice style work with my students, and on Thursdays we’re doing extremely constructive and creative projects.

This evening was the third meeting of the intro to Java I’m teaching as part of the IT Cert at Kent. Unlike last term, I have a new tool to work with in the classroom: a series of tutorials I’ve developed that are embedded in the BlueJ programming environment. What has made these tutorials particularly useful is that they allow my students to wrestle with new concepts in a constrained space: constructs in the language are exposed to them individually, one-at-a-time. When they read their course text, I think they tend to get information overload (having never programmed before), and typically don’t associate terms and concepts effectively with the grammar and syntax of the Java programming language.

I have 12 tutorials right now that drill students on creating an empty class, adding fields (one at a time), adding accessors and mutators for each field, and adding one or more constructors. Because I wrote a tutorial generator for this kind of drill-and-practice tutorial, I can easily create more, and (over time) extend the tutorials to include additional, fundamental concepts.

While the term drill-and-practice carries many negative associations for me, it can be a very effective instructional method. In the context of introductory programming, I think the drill-and-practice work

  • Familiarizes students with the parts of a class
  • Acquaints them with common syntax errors
  • Builds confidence and familiarity with the IDE
  • Provides a conceptual base that I can work from
  • Reduces my in-class workload

In particular, having a tutorial system that can actually inspect the student’s code, as well as offer immediate and positive feedback is an essential part of the equation.

Because the students are asked to write fields individually (for example), they clearly see what a field is in separation from all the other parts of a class. Likewise, each part of a class (accessor/mutator methods and constructors) is added piecewise. When given the TicketMachine code from the second chapter of Objects First, they were easily able to recognize these parts of a class in the code given.

They are also learning the simplest of syntax errors, and most importantly, those errors are constrained to one or two lines of code. That is, the tutorials never ask them to write more than a few lines of code at a time (often only one or two). This means that syntax errors are “constrained” to the most recent thing they did, and therefore they aren’t wandering lost in 50 or more lines of code. The edit-compile cycle also encourages a certain familiarity with the BlueJ IDE, which isn’t a bad thing at this stage.

In terms of a common conceptual base, these tutorials provide something I can refer to time and again. For example, we wrestled with accessors and mutators this evening (“setters” and “getters”). What makes them “easy” is that they both follow a very clear formula; if you know the name of the field you’re working with, you can learn to write setters and getters by wrote. Given the field

private String lastName;

we can write the getter

public String getLastName() {
    return lastName;
}

Having written around a dozen of these in the first half of class, we were able to start dissecting this without it being horribly abstract. For example, when I showed them the accessor “pattern,” it didn’t really surprise them:

public type getfield-name() {
    return field-name;
}

And lastly, my workload in class is significantly reduced if I let the students spend the majority of the 3 hours of class having them work through a tutorial instead of me lecturing. Instead of trying to illustrate concepts with four colors of dry erase marker and a crap little whiteboard, I can instead spend my time going station-to-station looking over the students’ shoulders. When it’s clear they’re wandering, I can provide contextual help that is timely and tailored to the individual. Or, I can pull back and do a quick “mini-lecture” that is topical to a problem they all seem to be having. My advance prep gives me the ability to spend more class-time in 1-on-1 interactions–and the best part is, that advanced prep is reusable from term-to-term and is easily shared on the WWW.

If I’m going on-and-on, it’s because this has, for the last two weeks, been entirely too easy. I feel like the students are making very good progress, considering how fast this 8 week course is intended to go.

I need to spend a little bit of time getting the website up and running for distributing these tutorials; once that is tweaked, we’ll go live and let BlueJ users everywhere grab them. And then I’ll have support issues…

Last night was the third Cool Stuff in Computer Science session of the year. It was, by any metric I can think of, a miraculous success.

Last week, everyone sorted the LEGO bits into kits, so each group would have it’s own box of pieces to work with–this cuts down on traffic around a crowded room. This week, we had two goals:

  1. Build a robot capable of motivating itself (as well as possibly steering), and
  2. Program it in occam.

This may not seem like much, but it actually filled a 21/2 hour session. We started ten minutes late (people dribbling in, etc.), and then I provided a quick mini-lecture on the basics of what we were doing that day (31 minutes). This mini-lecture briefly introduced concurrency (as a concept), and the five occam language constructs the students would encounter today (indention, SEQ/PAR, local variable declaration, procedure calls, and sending data down a channel). The material (an extensive outline, at best), can be found on the Moodle site we’ve set up for managing the educational content of CSCS this term. The PDF of the notes should be accessible as a “Guest” user entering the course.

After the introductory material, we started to play. The students were turned loose with their Mindstorms kits and the IDE Christian built for the occam programming language. Actually, he wrote a plug-in for jEdit, a free/open-source text editor written in Java. The plug-in adds a few buttons to the interface, allowing the students to compile their code and then send it to the Mindstorms; soon, we hope to have our simulator fully tied in as well.

For the last week or two, we’ve been working hard and fast on a lot of things, and getting all the IDE and back-end interaction to work from jEdit was fairly tedious. However, CLJ came through, and for a solid two hours students banged away on the IDE, writing occam code, compiling it, and downloading their programs to the LEGO. At no point did the IDE fall over, and nothing untoward came from the Mindstorms: it was a flawless run, I think.

It was a real joy to see students engaged and excited; it felt like I was “back home” teaching A290 at Indiana Univeristy. While they were engaged in a variety of tasks (building, programming), at no point was anyone complaining about the fact that they were learning. When they couldn’t figure out why things didn’t work, they asked questions, either of us (and I’m no occam expert!), or of each other–CSCS has a good number of second-year students, all of whom are studying occam as part of their second-year course. So, we had a dynamic, interactive session going, all throughout students were engaged and, dare I say, having fun?

In a word, last night was excellent. People left the session wondering what we’re going to do next week–and that is what I think it is all about.

Which makes me wonder… what are we going to do next week…

For my (immediate) work:

For transterpreter-related work:

  • Emsoft
    ACM conference on embedded software.
  • International Parallel and Distributed Processing Symposium
    CFP: October
  • PLDI: Programming Language Design and Implementation
    November. Colocated with IVME (Interpreters, Virtual Machines and Emulators), LCTES (Languages, Compilers, and Tools for Embedded Systems), and PPoPP (Principles and Practice of Parallel Programmin, CFP: December)
  • A big list of related conferences (J.Roth)

I need to expand the former list; finding venues for CS-ED publishing takes effort (I think), as there is usually an “impedance mismatch” between the research methods I employ, and those typically used by the community I’m trying to publish into. I think, with some more material, and ECOOP or OOPSLA paper could be doable–but the deadline for ECOOP is tight.

(The DB&LP list of CS-related conferences.)