Richard team taught the intro physics course I took my first year at Reed (where I learned that I was decent but not great at physics). On the strenuous recommendations of two good friends and physics majors (Peter Shirley and Neil Alexander) I later took the classroom part of second year physics from Richard. It was, as Peter had said, the best applied math course on campus, and Richard was a total genius with colored chalk, leaving the board covered with true works of art at the end of class. This was one of the most profound examples of the difficulty of capturing certain kinds of process in one’s notes, an issue I still struggle with as a teacher. Richard’s lectures were amazing to watch, but near impossible to wrestle into a notebook. I tried all sorts of things, including using colored pencils, to try to capture the glory of his board work, but it all failed. I suspect the only other person I had who’s lecturing was both as beautiful and as frustrating was Edsger Dijkstra.

More important than the classes I had with Richard, however, was his impact on me as a budding computer scientist. I’d taught myself BASIC in high school, but had never had any kind of instruction on programming or computing before my first semester at Reed, when we learned PASCAL in a series of labs in that intro physics course; labs which clearly owed their existence to Richard’s grasp of the growing importance of computation in math and science. Richard was friends with Steve Jobs, and it was through that connection and Jobs’ fond memories of his time as a quasi-student at Reed that Reed got an early Lisa, and then some of the first Macintosh computers. I remember playing with MacPaint on that clunky Lisa (I think with Peter Shirley again) and just being blown away – it was totally clear that we were seeing the future.

It was in significant part through Richard that I got to spend the summer of ’84 working at Reed designing fonts and programming for the earliest Macs. This was a very exciting opportunity, and I really felt like I was contributing to something. Probably my most notable achievement was the design of a bitmap math font (we’re just a little before PostScript here). Richard was very excited by the bitmap graphics on the Mac (taken for granted now, but still a novelty in the early 80’s), and as a scientist and mathematician he recognized the potential and value of not being tied to the ASCII character set that dominated computing at the time. So as a math nerd with computing interest and calligraphy experience (I was fortunate enough to take one of Robert Palladino’s last calligraphy courses at Reed in 1983), I was tasked with making a math font. This mostly consisted of designing a set of Greek characters, along with other common math symbols. It was hardly LaTeX (which would have been a nightmare to run on those boxes), but it was useful and widely used, and available for several years in big free font packs that you could get on a set of floppies from a fellow in (I think) Utah that had taken on the task of coordinating the distribution of free fonts. Those early bitmap fonts were, however, supplanted in short order by the much better PostScript fonts, and when I wrote my undergrad math thesis in MacWrite a year and a half later, I used the PostScript Symbol font instead of my own work. Sigh.

I also did some programming (I think I worked some on GriffinTerm, an early Mac terminal emulator), but my regret is that I didn’t make more of that opportunity. Richard was a strange guy who I at least found hard to read, but he was also clearly visionary and well connected. It’s hard to know what might have happened if I’d pushed myself more and made more of that opportunity. Sadly, I didn’t really understand the value of making things, and was mostly focused on “learning things” by taking courses and doing homework. I compare that to Thomas, who has done more extra-curricular “making” in his first year than I may have ever done at in my time at Reed, and it reminds me of why it’s so important to support our students at UMM in their “making”.

So farewell and thanks to Richard Crandall, a fellow who certainly made things, and who helped give me a great opportunity to make things.

StackSort connects to StackOverflow, searches for 'sort a list', and downloads and runs code snippets until the list is sorted.

Internet nerdom being fairly OCD, someone (Gregory Koberger) of course went and implemented this, and it works!

As Gregory says, this is potentially a security nightmare waiting to happen, so it’s not clear that you should actually run his code. Being a brave and foolish (and somewhat careful) soul, however, I’ve fallen on this sword so that you don’t have to, and I can confirm that it works. After trying several dozen StackOverflow pages (most of which yielded either “Could not extract a function to run” or “Contained potentially bad code”), it stumbled across a working version of Quicksort in JavaScript.

Ta Da!

The success of this approach, however, does suggest interesting things about how people approach certain kinds of problem solving these days. Where “old people” like me would have bought a book to learn something new, my students are much more prone to assemble a patchwork understanding from tons of Googling. While I think this often leads to a quite fragile and incomplete understanding of the topic at hand, it is often sufficient to get them through what is assigned. In other words, they’re very skilled at answering the question that was posed, which was itself often somewhat shallow because that’s what we all have time for. So while faculty would like to think that we’re creating experts (whatever that means) in certain topics, we rarely have the time to give them assignments and tasks that require a deep level of expertise.

In the land and time of books, we might have believed that everyone read and understood the 8 assigned chapters, but the assignments almost certainly didn’t strictly require that. In fact I’m willing to bet a whole lot skimming actually went on that was not so different from the Googling that happens now. The difference is that when I skimmed a book, there was a reasonably coherent thread connecting the dots that were touched on. “Skimming” the Internet, however, is a much less coherent experience. The authors, examples, and assumptions aren’t the same from search result to search result. Worse (in computing) the versions aren’t necessarily the same, so we often end up with inconsistent and downright contradictory results! A few years ago I taught a class that used Python 3, and it turned out that almost all Googling pointed us at Python 2 examples and answers, which lead to all manner of confusion amongst my students.

So call me old-fashioned, but I still like a book, even if it’s an e-book, when I’m learning something conceptually new, as I do really appreciate a coherent voice and structure. If I need to remind myself of a library function or piece of syntax, it’s to the Googles. If I’m learning something that’s very similar to something I already know, then I’m happy with on-line docs if they’re well written. If, however, I’m expanding my horizons in more significant ways, a book is still the thing.

The U.S. Department of Energy is featuring a small set of six U.S. colleges and universities that they feel are doing cool things to help us move into a more sustainable future. The second video to be “aired”? The University of Minnesota, Morris :-)

Our computing folks are getting involved in this by building tools that will help provide community members with current (hopefully nearly real-time) information on both energy consumption and production. Down the road we’re hoping to give people some predictive assistance, suggesting possible times when discretionary high-load jobs would take best advantage of things like our wind turbines.

Most (all?) of the photos from Fashion Trashion (about two minutes in) were also taken by yours truly. Thanks to Jess for inviting me to take photos at these extremely cool events.

It’s a true joy, and I’m really looking forward to being able to read the “finished” work. It’s a project oriented book, though, which means that to really learn from it we’re going to have to play along at home, programming, and experimenting, and analyzing. We’re all going to have to set aside some time for this when it does come out. But it’ll be worth it. And while the claim is that we’ll be learning about Generative Projects or Genetic Programming or whatever Bill decides to have GP stand for when he wraps this thing, we’re also going to learn a lot about software development and problem solving along the way, from someone who’s got a lot of great things to say on those important subjects. So we’d best buckle our seatbelts!

I do, however, have to take issue with a claim Bill makes in the introductory “About this book” section:

This is not a textbook. If your instructors try to use it as one, complain. If they argue, send them to me.

To be honest, it’s turning out a lot more like an anti-textbook. It will not improve your performance on tests. We’ll use “advanced” techniques before we discuss “basic” ones, ignore common practices to focus on more appropriate contingent solutions for specific problems, and may not even touch on techniques your instructors think you ought to know.

Remember, my goal is to support and extend your existing skills so you can productively explore further. Seek comprehensive knowledge and historical grounding in other books. They are full of it.

I can’t help but think he had me in mind when he wrote these lines, and I doubt he’ll be surprised to learn that I’m certainly seriously considering using it in my Evolutionary Computation and Artificial Intelligence course in the Spring. <snigger>

The issue, I suspect, is what one considers a “textbook” and what the point of such a thing is. Traditionally textbooks are big, fat things that provide a “coherent” overview of “everything you need to know about subject X”. I’ve got a bunch of these on my shelves with nice overviews of things like calculus and physics and chemistry. Old things, with a clear sense of what matters and what order it should be presented in.

In teaching computer science, however, things are typically much less clear. What’s “vital” in our field? What’s the “natural” or most pedagogically sensible order to present that material? There are lots of ideas out there, but hardly consensus. And that’s on the introductory material; my upper division electives usually focus on material where there’s even less agreement.

Starting in the late 90’s I started moving away from “traditional” textbooks when I could. I found that the most important part of most of my courses was process rather then content. Most computing textbooks I’ve seen are, unfortunately, much stronger on content than process. There are piles of books full of catalogues of algorithms, but they’re mostly presented like magic tricks, things Very Smart People dreamt up in some strange opium vision, inaccessible to the rest of us. The challenge in my experience is coming up with these visions, the process and the problem solving. So a book like Fowler’s wondrous Refactoring is far more educational in the long run, giving us skills for life instead of a box full of baubles.

The contrast between process and content has been made far more pronounced by the web and its many tools and collections. Young folks (and even this old guy) almost never reach for a book when they want to look something up; that’s what Google is for. The reference value of big encyclopedias of “facts” is greatly diminished when we can so easily find things on-line, but a well-written description of an important process is still a treasure.

Which brings us back to Bill’s book.

He claims it’s not a textbook because he doesn’t plan to cover “every” technique or concept or approach. He’s going to doing things in the “wrong” order. Foolishly, he’s not going to help improve our performance on tests, choosing to instead helping us develop skills that will help us for years to come.

Silly, silly man.

So, yeah, I do want to use Bill’s book in my class, and my students are more than welcome to complain to me or take it up with Bill. I doubt, however, that they will. The writing is opinionated and ornery and humble in all the right ways, and the emphasis on projects and problem solving are the sort of thing our students just eat up. I’m guessing that they’d happily line up behind something like this vs. a more traditional text.

As will I.

P.S. You should check out the book’s LeanPub site (https://leanpub.com/pragmaticGP) and sign up for notification. It’s a great way for people to help delude Bill into thinking that he’s not actually wasting his time.

Or something like that.

We then spent most of the day hanging around Portland together, including a visit to the mighty and wonderful Powell’s City of Books (one of the last, great independent book stores) and checking in at GECCO to get my registration stuff. Tom totally loved Powell’s (“I could get lost in here!”), and has in fact spent large amounts of my money and his time there this week while I was at the conference. We also went out and saw Toy Story 3 that night, which turned out to be every bit as good as everyone’s said it is – lots of fun and very well written.

Day 8 was our last college visit in this part of the world, as we headed up to Olympia, Washington (2 hours north of Portland) to visit Evergreen State College. This was a real eye opener for both of us. I knew Evergreen was cool (and another of the small number of public liberal arts colleges in the U.S.), but didn’t know a lot of the details, and I think we both found the unusual curriculum and environment really interesting and thought provoking.

I had arranged beforehand to meet some of the computing faculty at Evergreen so we could learn a little more about their program as part of a program review we’re doing at Morris, so after the information session and tour we met up with Sherri Shulman and then headed over to meet her husband and fellow CS faculty, Neal Nelson. When Neal walked in, there was this very weird moment where we both those we knew each other but weren’t sure why. Duh, duh, and double duh – Neal was my undergraduate thesis advisor at Reed! I’d lost track of him when he left Reed in 1988, and I somehow thought he’d gone into industry so I wasn’t even looking to find him anywhere in our travels. Given all that and the the fact that his name doesn’t particularly stand out (and that I’m really crap with names), I totally didn’t consider the possibility that I knew this Neal guy we were going to see. After recovering from that somewhat awkward start, Sherri, Neal, and I had a really excellent conversation that ran a couple of hours easy. Lots of catching up on old times, as well as discussing undergraduate computing curriculum with limited resources in a public school – many thanks to both of them for all their time!

After returning to Portland, we went to Papa Haydn’s, possibly the best source of wonderfully scrumptious and rich desserts that I know of in the U.S. I had a wonderful Autumn Meringue and it was just like being a college student again (without the metabolism of a 20 year old). We used to walk out to Papa Haydn’s from Reed (maybe a 30 minute walk) several times a year and indulge, and was so cool to go back and find that it really hadn’t changed much in all those years.

That night was the opening reception at GECCO, so Tom and I hung around for a few hours eating little snacky things and chatting with various folks. Tom had never met most of my EC friends and colleagues, and he was very cool at meeting a bunch of strangers that are, even worse, all science nerds to a very high degree. Luckily it’s a really cool group of people, and I think he actually enjoyed himself.

By Day 9 I’d actually skipped out on the bulk of the first two days at GECCO, so at this point I essentially abandoned my son to the wilds of downtown Portland and started pretending to be a scientist for a bit. He spent most of his time hanging at Powell’s and reading books, while I listened to people talk about their cool evolutionary computation research.

That night I did actually skip out on the last session, though, and went back to Reed to join a bunch of faculty that have a regular Friday beer and food gathering at Woodstock Wine and Deli up the hill from campus. Jim had invited me to join them, and it was a great chance to meet some people I knew that I’d missed before (like Ray Mayer) and a bunch of other faculty that are new to the college since I was a student there in the dim past.

I wasn’t the only one meeting up with old friends, as Tom met up with Perry Webster from Morris (currently attending the University of Portland) and hung with her and a family friend pretty much the whole evening, which was a neat chance for him to spend a little time with people more his age :-).

Day 10 was much the same, although I stayed at the conference pretty late because the poster session and associated reception was that evening.

Day 11 (today) was the end of the conference, including eating lunch in the hotel sports bar with a bunch of very enthusiastic Europeans watching the World Cup final! Eli Mayfield (UMM ’09, now a grad student at Carnegie Mellon studying natural language processing) gave a talk today, and did a really excellent job. Tom and I went out to Jake’s Famous Crawfish with Eli and Bill Tozier. Jake’s was a great seafood house back in the day, and they didn’t disappoint, providing us with excellent food to go with the fine conversation. That was a great way to end our time in Portland!

Now we’re off to bed, and tomorrow we drive south to Tule Lake and Lava Beds National Monument. With a little luck we may hook up with Wayne Manselle in Eugen on the way!

The cool part is that most of the photos are mine! This set on Flickr shows all the photos they used, although many of them actually look much better in the calendar. Their staff did a really great job of straightening, cropping, and adjusting the lighting on the shots that they used, and it really made the photos look really nice. Thanks to whoever did the excellent work! Christian Lindig informs me (see the comments) that the design work was done by Margot Behr. Thanks for the great work, Margot!

It was really weird when I first looked at the calendar, because I really wasn’t sure how many of the photos were mine. There were two or three that I immediately recognized as mine (like the image at the top), but there were quite a few indoor detail shots that seemed like the kind of thing that I’d take (like the dragon below), but which I didn’t really recognize. There were also several of buildings that could have been mine, but could have been taken by most anyone. Going through, them, though, I was able to determine that all but two were in fact mine. The cropping (and to a lesser degree the cleaning) that the Dagstuhl folks did often threw me as it sharpened the focus in cool ways that I hadn’t seen or thought of.

There are two photos in the calendar that aren’t mine, both taken in specific conditions that I’ve never been there for. One is a really cool panorama with a beautiful fresh coating of snow and the other is the grounds around the chapel in the summer.

• Models of Computing Systems
• Fuzzy logic and fuzzy sets
• Refactoring

I’ve taught Refactoring several times and have a pretty good handle on that. Fuzzy Logic I’ve taught once before and am pretty comfortable with. The Systems course, however, is one I’ve never taught before and am still struggling with on a number of levels, including the textbook.

Any suggestions and ideas on any of these would most certainly be appreciated. I’ll say a little more about each course below the fold for those who want all the gory details.

Models of Computing Systems This is one of our three core courses (the others being Algorithms and Computability, and Software Design and Development), is a 5 credit course (4 hours of lecture and a 2 hour lab each week), and is intended to expose students to computing systems using a layer model that includes as major topics

• Assembly language and a quickie overview of basic architecture
• Operating systems basics, with an emphasis on processes, process management, and threading/concurrancey
• Computer networks
• System administration, including the installation, configuration, and management of common tools like web servers

I’m planning to use x86 assembly for the first item, and the sysadmin work will happen on Linux boxes. I’m planning (still in a vague way at the moment) to try to use computer security issues to motivate/illustrate a number of key concepts in this course. Things like file system and disk structure can be pretty abstract, for example, but I’m thinking that doing a lab where we see how those decisions lead to lots of “erased” data being recoverable might make it seem more “real” and significant.

I realize that no book is going to cover all these things, and on-line resources plus lecture can provide the necessary background for several of these. This course has typically using a “standard” OS book like Silberschatz, et al, but this is large and expensive and really only addresses one of the four topics. If anyone knows of a good book that would touch meaningfully on more than one of these areas, though, that would be really helpful.

Fuzzy logic This is a 2 credit elective course, and should provide a reasonable background in the theoretical definitions and concepts in fuzzy logic, as well as giving the students a chance to apply those ideas. (My current plan is to write robot race car drivers using fuzzy notions of concepts like fast, slow, near, and straight.)

I’m probably more interested in solid coverage of the theoretical material than the applications side. The students will benefit from a good introduction and reference on the mathematical material, and I can probably handle the motivation and application side in class pretty well.

When I last taught this (Spring, 2006) I used An Introduction to Fuzzy Logic for Practical Applications by Kazuo Tanaka, translated by T. Niimura. That book actually worked quite decently. There were some predictable translation issues, but nothing that we couldn’t manage.

Refactoring This is also a 2 credit elective course. I’ve taught this course several times, and I’m likely to again use a combination of Fowler’s Refactoring and Kerievsky’s Refactoring to Patterns. Fowler is the “standard” in the field; the first five chapters of his book are absolutely classic material on the realities of software development and should be read by pretty much anyone who aspires to write good software. Kerievsky’s book builds on Fowler and does a really nice job of demystifying design patterns, converting them from magical insights codified by geniuses into things you could discover on your own through careful refactoring. When I last taught it I think I had Kerievsky as the required text and Fowler as the optional book. Given that together they still add up to less than $100, I’m tempted to require them both. We have lots of copies of Fowler in the lab, though, so I might just require Kerievsky again. Ideas/thoughts on this would definitely be appreciated.

One of the problems we’ve run into in this course in the past has been attempting refactorings on code with limited automated testing. Without good tests you lose your courage to refactor mercilessly, or you have false courage and end up breaking things without realizing it until (sometimes much) later. With only 2 credits to work with, however, you don’t want to spend two weeks writing unit tests for a system before you can start refactoring it, especially when you don’t really understand what the units are and what they’re supposed to be doing. This time I’m planning to use BDD tools like Cucumber, RSpec, and JBehave this time to more cheaply write high level acceptance/functional tests that exercise the key parts of the system in meaningful ways without getting bogged down in a bunch of poorly understood unit tests. We’ll see how that goes.

Wrap-up

So, there they be. Any thoughts, ideas, or suggestions would be greatly appreciated, especially on the Models of Computing Systems course.

As computation becomes smaller and cheaper and more powerful, the big question remains “What are we going to do with all that?”. Cell phones and iPhones are one answer to that question, but in some sense a boring one because they’re mostly just littler laptops. Siftables, on the other hand, are representative of some of the genuinely new possibilities that these technologies enable, and are therefore much, much cooler :-).

To be honest, it’s not the best talk in the world, and probably not as compelling demo of the possibilities as one might hope for. That said, I can definitely see these being a blast, especially as people come up with cool new ways to use them.

Also, many apologies for the silence here. I’ve been much more active on Twitter than here; things have been super busy, and the 140 character world of Twitter has been much more amenable to my life and schedule than thoughtful blogging here. Lame, perhaps, but the truth nonetheless. Figuring out the balance is going to be a challenge, but that’s not today’s activity.

I was debating whether to install this software (which in theory supports Mac OS X), so I did some Googling first. There wasn’t anything very concrete, but there were some suggestions that Apple had included this kind of software in OS X at some point, and that Apple’s was much better than APC’s.

So I plugged in the provided cable that ran from the battery backup to a USB port, and Lo! and Behold! it immediately recognized the battery backup and nifty new options appeared in the Energy Saver panel of System Preferences! I set it to shutdown when the battery was down to 95% of capacity, and unplugged the battery backup from the wall, and it shut down beautifully. Without APC’s software.

Problem solved!

Thanks to all those that contributed to the many technologies great and small that allowed me to figure this out quickly and without having to call people, or post questions, or any of those annoying things.

photo credit: hradcanska

Today I got an e-mail with the receipt. As an attachment. In “.MDI” format. Whatever the hell that is.

I was pretty sure we were going to find out that this was a M$ format before I’d even bothered looking, as it’s almost always people that have been sucked irretrievably into the M$ vortex that blithely send out files in annoying proprietary formats without considering the possibility that not everyone has sunk loads o’ dosh and a major organ into M$ software. I was right. It turns out that it’s Microsoft Document Imaging format, which apparently scans physical documents and converts them into TIFFs. But instead of then using the open, nigh on universally supported TIFF, they wrap (I’m guessing) that in their own goofy MDI format so people like me can’t open the documents.

Charmed. I’m sure.

Nothing I tried (and I tried quite a lot of things) would open this MDI file up, so I (nicely) wrote back and asked if he could re-send the file in an open format, like plain text or PDF. A model of restraint, I was. Really.

They promptly sent a second message with a new attachment in “.doc”. Good on the promptly. Less winning on the “.doc”, since that’s clearly not an open format. Happily, however, NeoOffice was able to open it up, sparing me a second round of e-mails with this nice person.

And what, after all this fun, did this remarkable M$ Word document contain?

A single, small image.

The image looks like a scan of a small bit of a spreadsheet. A small bit. No names (theirs or ours), dates, or any other standard “invoice” information. Just 10 lines of text, four of which are labels, four of which are actual entries (the rental amount, VAT, etc.), with the rest being sub-totals and totals.

In other words, a ton of machinery to obfuscate a quite small bit of information.

I just hate it when that happens…