Sub Ubi

Continuing on from my previous post, I continue to wonder about conversational (or dialogic) forms of course evaluation. A cursory search of a few online databases doesn’t yield anything in this area, which means a more serious, systematic literature search is required. While it is true I’ve never seen anyone take a conversational approach to course evaluation, that doesn’t mean that it hasn’t been done or investigated.

Some papers I’d like to investigate, however:

• A Longitudinal Study of Student Feedback: Self-Assessment, Course Evaluation and Teacher Evaluation
• Evidence for a Student-Centered Course Evaluation Form
• A Student-Centered Course Evaluation Form (same authors as previous)
• From Feedback to Reciprocity
• Student centered evaluation (webpage)

What is interesting was how enriching and valuable a conversational approach to course evaluation turned out to be. And, after receiving the college-issued anonymous course evals, I cannot even begin to imagine how I could evolve and refine my course based on the (blunt) instrument they employ. As I investigate these ideas further, I’ll make note of them on this blag.

This past autumn I taught Software Design at Olin College. It was an excellent experience, and I enjoyed myself a great deal. As I was experimenting with a number of things (a transition from material found in HtDP to an OO introduction to GUI programming, pair programming, the use of version control with novice programmers, extended projects in a first programming course, etc.), I was very interested in getting good feedback regarding how the course went. Translated, I mean “better feedback than a bog-standard feedback form would yield.”

I often close my courses with a discussion as to how the course went. This year, I took the results of the 45 minute discussion that the students and I had, and reflected on how I might evolve the course the next time I teach it. I then pushed those reflections (4 pages of summary and 10 pages of reflection) back to the students, asking for them to verify whether they felt my proposed changes captured the spirit of their comments and criticisms. Of the 20 in the class, 6 came back to me with their thoughts.

I have now consolidated my proposed changes and the student comments into one document. I’ve titled it Feedback as a conversation (PDF, 5MB), and have made it available online (if you are interested… mostly, this is so I can point students and colleagues at it). Based on a quick poke around the literature, I’m curious whether the notion of “feedback as conversations” (in the spirit of the Cluetrain Manifesto) has made its way into the academic discourse. I may try and dig through this literature, as I have never actually seen anyone go through this kind of iterative, reflective process with their students before. Certainly, it is outside my experience at Kenyon, Indiana, and Kent.

The last post on this blog was in October. Since then, things have been busy. Over the next few posts, I’ll try and catch up a bit.

For the last three months, we’ve been working hard on the new Blackfin Surveyor SRV-1.

Blackfin SRV-1, image stolen from the Surveyor webpages

We first encountered the Surveyor at AAAI 2007. When Howard “Surveyor Daddy” Gordon updated the Surveyor from a 60MHz ARM with a few KB of RAM to a 500MHz Blackfin with 32MB of RAM, we took notice. And, even better, when it sprouted that oh-so-excellent WiFi tail, we really took notice. (It is so much easier to work with WiFi than the ZigBee radio that was there. At least for us it is.)

This semester, I’m co-teaching ENGR 3390: Robotics with Dave Barrett at Olin College, and we’re using the Surveyor as the platform for the mobile portion of the course. We’ll be using the Surveyor as a platform as a demonstrator where we can introduce students to architectures for cognition on robotic platforms in a parallel-safe way using the Transterpreter and occam-pi. And what we realized very quickly is that the SRV-1 looks like it is just begging to be beaten all to hell in the classroom.

See that processor on top, all nice and exposed? After a team of students shuffles in from the dry, Boston winter—BZZAPT!. No more Blackfin. One good static discharge, and the processor or RAM are gone. Or, those little laser diode wires? Oops! A careless gesture, and they’re yanked out. Or what about a drop from the counter-top? I’m not confident the board would handle the fall very gracefully.

Dave threw together a quick Solidworks model, and dumped it out to Olin’s rapid prototyping machine. This thing is incredible: it prints in 3D in ABS plastic. Send the model, step back, and 12 hours later you have this:

That is a battle-ready SRV-1. The laser mount was removed, and the diodes inserted into the body, which was simply printed with the diode mounts in the right place. The camera hole is oversize, and easily gives the camera a full field of view.

As you can see, the rapid prototyping machine has enough resolution to render depressed text in the body of the bot. This one clearly declares itself as property of Olin’s ENGR 3390: Robotics course.

What you may or may not be able to tell is that the entire top of the box has mounting holes at 1/2″ spacing perforating it; it is amazing what the RP machine can do. This means we can easily screw-mount sensor towers or anything else we might like to the top of the bot quickly and easily, running wires straight down through the body to the SRV-1 board.

Generally, the pictures are low quality because they were taken with the webcam built into my Macbook. I’ll get better pictures at a later point.

The first thing we’re going to have the students in the course do is take the basic Solidworks model and design bodies for their team’s bots. This way, each bot will have a unique body, and the students will have some ownership of the process. However, we already have a few things we want to improve in the basic body before we turn them loose:

• The body doesn’t have anywhere to grab on to in the back; as you can see, it is just resting on the SRV-1’s aluminum body. Our plan is to wrap around inside of the treads, where there is just enough clearance for us to sneak the body down. This way, we provide more protection for the boards from grit and the like, and can attach across the base of the bot on the underside.
• We need blinkenlight mounting holes build into the body. This way, you can just push an LED up from underneath, and it will sit flush with the housing. We can wire them into the GPIO pins inside, and have all the wires hidden from view, and safe from snags on obstacles.
• A view hole needs to be left for viewing the state of the three LEDs on the Blackfin’s motherboard.
• A mounting point for a header board could be built into the body, so sensors could be attached and detached outside; this depends on whether we expect to be doing much of this kind of prototyping with different sensors or not.
• Mount points flush with the body wall for IR and other sensors on the front/back/sides could be very useful. We have a number of interesting sensors for the students to characterize and use, and mounting them safely inside the body would be a good idea.
• The antenna should probably be above the ground plane; we could run a cable from the current point, under the body, and up to the top, where we could easily grow an antenna mount.
• We have blue and yellow plastic coming in, which will produce a lasting color. Otherwise, we have to paint, which is less durable and a mess to work with. (Well, as messy as spray paint ever is, anyway.)
• I want my robot’s body covered in dimples (and maybe some through mounting holes) that are compatible with a certain plastic building toy that rhymes with Tierra del Fuego.

Those were the immediate improvements that we saw could be made.

We’re really excited about the course, and I think both Dave and I are pretty excited about how cool the bodies for the Surveyorcould be. What’s really awesome is that they are printed in ABS plastic, and have a wall thickness of roughly 3/16″ of an inch. (I haven’t measured; that’s just my eyeball estimate from memory.) I pounded on it with my fist (off the Surveyor), and I hurt my knuckles. In short, the body is tough. The ultimate goal is to make it possible for a student, in their excitement, to give the Surveyor a kick on the field of combat (or drive it off a table), and have the bot be in a good condition to survive the fall.

Over the next two weeks, this body will evolve a lot. We’re going to be playing with it, and then 24 of Olin’s energetic, creative engineers-to-be are going to rapid-fire evolve it to their hearts content. I think we’ll end up with something very, very cool. I’ll post pictures and Solidworks models as the body evolves.

I don’t usually impulse buy. In fact, I just plain don’t buy many things, full stop. Generally, I want less stuff laying around. But there have been two recent acquisitions around the house that may help reduce the general stress level by introducing a bit more—vegetation and play, perhaps.

After months of being back in the US, we finally got a TV. The entertainment center was $30 from a guy down the street (hooray Craigslist), and the TV from someone across town for $40. So, $70 picked up a reasonable piece of furniture and a 27″ TV so we can watch movies. I think that was a good deal, all told.

This next one, though, I’m quite pleased with. I will admit that it was an impulse buy. I just finished finding a CC-licensed photo of some LEGO that I needed for a document I’m writing. (I’m working on a tutorial for the Robotics class, which is based on the LEGO Mindstorms.) After finding that picture, I was inspired to do some poking around on eBay, because I wanted a brief break from writing… and look at this!

That’s a 400+ piece DUPLO collection! Yes, that is awesum!

Check out all of those DUPLO minifigs!

And look at those two hip cats takin’ a ride in the DUPLO choo-choo! That thing freaking rocks my socks.

And yes, I have the DUPLO MAN. The LEGO police can go around putting the hurt on anyone they need to.

I have a lot of LEGO; I am still wandering around with approximately 12 LEGO Mindstorms RCXs, plus a lot of other bits. Basically, I have many, many LEGO pieces in my collection. Oddly, I have no DUPLO. So, when I saw this eBay auction, I snagged it for $50, which I think is a very good deal. A box of 100 DUPLO pieces from LEGO costs $45, so I think this was a steal.

It’s a frivolous impulse buy, but I was brought up to love LEGO. And I’ll end up using it with students in the classroom, so this was a good buy all around. And, most importantly, I NOW HAVE 400 DUPLO PIECES! MINE! ALL MINE! BWAHAHAHAH!

OK. I’ll calm down. Back to writing.

PS. Ron, if you’re reading this, don’t tell the kids. They’ll be jealous, and I’m not sure I’m ready to share yet. Or, for that matter, cart 400 DUPLO pieces down south so William can get his build on…

To keep a weblog like this on the Internet requires a computer to be running, somewhere, 24 hours a day, seven days a week. My weblog, in short, consumes natural resources so that my blather can be read by a handful of wonderful, beautiful people.

In truth, there is much more running on this machine than just this weblog; services that provide support for collaboration on software development, writing, and research run on the same host. So, the environment is not being destroyed purely for my own vanity. And furthermore, the “machine” this weblog lives only consumes part of the resources of a real machine: the blog lives on a “virtual computer,” one of many running on a single, physical computer in a datacenter somewhere in England.

But that physical computer is resource hungry; it probably has seven to ten fans, a large power supply, and multiple hard drives. It draws a substantial current and generates a non-trivial amount of heat. That heat is death to a data center, and must be moved; this implies some kind of air conditioning or environmental control. All of this, ultimately, adds up to a lot of resources to keep computers running all day and all night, every day of the year.

There are such things as green hosting facilities. The Green Data Center is one. They run on 100% renewable energy with a 100% uptime service level agreement. Now, please keep in mind that I am currently in love with our current hosting provider, Bytemark Hosting. They are professional, responsive, and excellent providers. I’ve never worked with anyone else, but I find it hard to imagine anyone providing a better service. Equivalent, perhaps, but not better.

Running a colocation facility on wind power is one way to go green. Another is to reduce the resources involved in running a colocation facility. Specifically, can we provide good hosting opportunities to customers that draw fewer resources while providing suitable amounts of computational power and storage?

Going virtual

One way to achieve this is to virtualize—to run multiple, virtual computers on one physical computer. Lets consider the Apple Xserve; this beast has 8 processing cores, and contains either one or two 650W power supplies. That wattage, one way or another, is turned into heat. With 8 cores and a maximum of 32GB of RAM, I could run a lot of virtual machines. In fact, let’s play pretend, and get specific: an Xserve with 8 cores, 8GB of RAM, and a pair of (fast) 300GB drives with hardware support for three years costs roughly $8000.

If I assume a 3-to-1 ratio of virtual machines to processor cores, I have 24 virtual computers running on this one physical host. I can allocate roughly 250MB of RAM to each VM (leaving 2GB for the host), and 10GB of disk for each. If we assume that these 24 virtual machines keep the server running reasonably hard all the time, then we might estimate that each virtual machine is responsible for drawing 25W. If I want to attach a cost to these virtual machines, they cost me $330 each in my initial cash outlay. (I have no idea if these numbers are at all indicative of how hosting providers provision machines in the real world.)

Conclusion: Each virtual machine draws 25W, has 160MB of RAM, 10GB of disk, and roughly 800MHz of processing power. (Because these are shared values, and I’m unsure about the performance penalties of this kind of virtualization, we’ll have to take all these numbers with a grain of salt. And my power guestimate is just that… a brute-force division of 650W by 8 VMs on the host.)

Going small

What struck me today was that we could also go small. One might be to build systems on something like the pico-ITX standard. VIA makes the only motherboard in this class right now. The motherboard can easily be configured with a 1GHz processor, 1GB of RAM, and compact flash for storage. The motherboard costs $230, RAM around $20, and a large flash card (say 16GB for the OS) runs around $90. A power supply will add another $50, which puts us at approximately $390 for a dedicated host. The neat thing is that, running flat out, a pico-ITX-based system like this is likely to draw less than 15W (based on this review at mini-itx.com). At idle, I expect that number to be even lower.

Conclusion: A pico-ITX based computer draws 2/3rds the power, has 4x the RAM, and roughly the same processing power as my proposed virtual machines, at roughly the same cost/machine.

Apples and oranges?

No pun intended, really. Is this comparing apples and oranges? It is certainly the case that, per machine, a host based on a tiny motherboard and flash-based memory is going to draw less power and dissipate less heat—there are no moving parts. (Hard drives are, I believe, a substantial source of heat generation in colocation facilities… and also prone to failure.) Whether flash-based storage is (one) more reliable and (two) faster or slower than a shared system built on a 15K RPM disk is something I’m not interested in figuring out right now, so I leave those as questions.

While a small machine like this has a higher initial cost, they can be bought piecemeal (unlike Apple Xserves). This means that a hosting provision based on it can be grown with limited capital over time. Each machine is dedicated to a single customer, who enjoys more RAM and processor power than if they were on a shared host. Special configurations can easily be offered; for example, we might want to run RAID1 on a pair of flash drives. And, it is possible that environmental control would be easier with racks of smaller machines (generating less heat) as opposed to racks with fewer, larger machines. Certainly, 8x machines of this class must draw far less power when idling than an Xserve ever will. Unless, that is, the entire Xserve idles somewhere around 40W.

Is this just wild fancy?

It is possible I’ve wandered off into a land that I shouldn’t, and this is all just wild speculation. Perhaps my gustimations about power consumption of these little computers is way off, and it would be far more inefficient than virtualization. The TCO of many small machines may be much, much higher than maintaining one big one. At the same time, there is something appealing about a colocation facility that uses small, low-power, dedicated machines to support common hosting tasks. Or, perhaps we’re all going to be using Amazon EC2 instances in the future? Who knows.

However, I’d really like to get my hands on such a system and find a colo facility that would let me experiment with it in a production environment. Perhaps I’ll write Bytemark, and see if they’re interested in taking part in an experiment…

Using the Mozy backup service has turned out to be a horrible choice on my part.

In near the start of 2007, I purchased a new MacBook to replace my Powerbook that had been stolen. I suffered a hard drive failure, but had good backups. When the drive was replaced, I went ahead and subscribed to Mozy, which provided an automatic means to backup all of my pictures and other important data.

In October of 2007, my hard drive failed again. I had 30GB of data backed up on Mozy.

I tried using their desktop client to restore my data; somewhere in the middle of a 600MB test recovery (just one (large) folder), it said that one or more files were corrupted, and could not be restored. Mozy’s software neither 1. told me which files were corrupted, nor 2. was capable of restoring everything except those files. Either of these things would have been useful.

I had several very unsuccessful rounds with incredibly poor support from Mozy. One person did tell me the names of the five (!!!!) files that were corrupt in that one 600MB folder. That’s five files out of several tens of thousands of files. If that sounds like a small number to you, consider that some of those files were part of the Google TechTalk that I presented last April. (I have other archives of this, but my point is that a single metadata file inside of the presentation archive corrupts the whole presentation.)

I then tried using the WWW restore. It took a long time to download 30GB of data. I then started to decrypt it using their decryption utility. Again, somewhere in my archive are “corrupt files” that cannot be decrypted. The decryption tool fails, and refuses to go further.

I’d like to point out that I have bazillions of files in those 30GB. I have no idea which files are corrupt. Nor does Mozy’s software seem willing to report this information to me (a feature that would be very, very usable to me). Furthermore, I have no idea why those files are corrupt in the first place. For them to be corrupt implies to me that Mozy’s software corrupted them at the time of backup. How could their software completely fail to do robust checksums on backup, I’ll never know… because it did it silently, and any logs of its transgressions were lost with the death of the hard drive.

Either way, I currently have 30GB of data that I cannot decrypt because of some unknown number of bad files within the millions contained in the restore. Mozy has failed to provide me with instructions (despite multiple requests) on how to decrypt my data using tools other than theirs. Given that the data is encrypted using a 448-bit Blowfish cypher, I assume I can use OpenSSL or similar to do the decryption… but this should not be necessary. And, given that it is necessary, it should at least be possible, and ideally, documented.

Am I near-ranting-frothing? Yes, and no. This is now months past; I’ve given up on the data. It is gone. (I still have the 30GB restoration images, but I have no way of doing anything sensible with them.) I put my faith in a crap backup solution. Mozy provided a completely worthless service for which I paid $5/month for a number of months, and now that money, like the data, is gone. I cannot recommend Mozy to anyone, and have no reason to believe that their tools work in a robust and reliable way. Additionally, I have no way of decrypting my own data except through their closed-source, proprietary tools. Until I figure out how to do that through some other mechanism, it means that data backed up using Mozy’s software is not only suspect (because Mozy will clearly silently corrupt data while backing up), but it is also a hostage situation, because only their software can decrypt your data.

My hope is that there are enough keywords in this weblog post so that people will find it when researching Mozy, see my rant, and say “Maybe there is some other way I could back my data up that doesn’t involve giving it to a company that writes buggy software and then provides poor support for such a mission-critical application.” I had hoped that it was an affordable, easy, reliable backup solution. I was wrong, and given the things I’ve been reading lately, I should have known better.

In short, Mozy is buggy software that is unsafe and cannot be trusted for the backup of your data. Use anything else. My next experiment is with Amazon S3 via JungleDisk.

653 miles, 11.5 hours. Our little Echo got almost spot-on book values the whole way at 34 miles per gallon. And the MacBook did well, too: on battery, I roughed in 19 pages of a paper I’ve been trying to write in fits and starts since this summer. (Mind, I did over half the driving, so that wasn’t 12 hours of battery.)

	I received 70 credits on The Sci Fi Sounds Quiz How much of a Sci-Fi geek are you?
Take the Sci-Fi Movie Quiz Canon S5

And then I got home and took this sound-effect quiz. Why? I don’t know. I missed a few, which disappointed me. Clearly, my sound-effect-fu is wanting.

There’s a great deal to reflect upon from this past semester, but I think I’ll start by looking forward.

For the last two years, I have been delving deeper into the world of embedded systems. By this, I mean computational devices that exist in the world around us. Your microwave is an example. Mobile phones. The LEGO Mindstorms. Cars. Toys. Gadgets.

All of these things have little computers in them, and they all interact with the world in one or more ways. Sometimes they have buttons, sometimes displays, sometimes a multitude of sensors, or perhaps various kinds of radios for doing wireless communications: WiFi, or Bluetooth, or GSM (which is what many mobile phones use). I’ve learned how to program these devices, and have been thinking hard about how to make programming them easier and more robust.

But what I don’t have is good mastery over how you design and build these little devices. I can program them, but I can’t create them. It is all fine and good that I can write programs on my laptop that do interesting things with all kinds of data, whether that data lives on my hard drive and from the Internet-at-large. But when it comes to embedded systems, I feel like there is a great deal of power to be had from being able to combine the components—the processors, the radios, and the sensors—to create devices of my own design.

This semester, a group of five Olin students have agreed to help me tackle this learning challenge. Together, we’re going to explore the basics of digital design, and build a small device that is capable of doing something interesting. Ideally, I’d like it if the device was human powered—perhaps by a clockwork spring or similar. But to start, we’ll see what we can do in terms of reading documentation, drawing schematics, and assembling our own, tiny computational device that can interact with the world around it.