I’m astounded by the ideological rigidity that has apparently so immobilized some people—including some I normally think of as perceptive and intelligent—that prevents them from seeing what is obvious to so many of us: the US needs tighter gun control laws.

Disclaimer: Some of the following arguments are so intellectually vacuous that you might think they are “straw man” arguments designed to be shot down, but sadly, every one of them was proposed by someone personally known to me.  (Not all by the same person, though.  That would be tragic indeed.)

“If you ban guns because of mass shooters, you’d have to ban jet planes because of 9/11.” Don’t laugh, someone actually made this comparison through what I assume was a fog of ideology.  First, airplanes are primarily designed to transport people and things, but were tragically misused for an evil purpose; killing someone by beating them with a brick doesn’t mean we should ban bricks.  In contrast, killing someone is the sole purpose for which a gun is designed.  This is even more true of semiautomatic assault weapons, which are optimized to cause the maximum amount of damage with the minimum amount of time, effort and risk to the shooter.  Second, while 9/11 resulted in swift (and sometimes ill-advised) changes in airport security, at least there was a response.  In contrast, despite Columbine, Virginia Tech, Portland, and now Newtown, there’s been no change whatsoever in gun policy, and indeed there have been public officials whose first reaction is apparently to ensure that such events aren’t used as a pretext for making any such changes.  There was even legislation that just went into effect in Michigan allowing concealed weapons in schools, on the pretext that “armed teachers could have minimized the damage” in such a mass shooting.

“If you ban guns because of mass shooters, you’d have to ban cars because of drunk drivers.” Bzzzt, wrong.  Besides the fact that the same argument applies—drunk drivers are misusing a technology whose primary purpose is generally beneficent and completely unrelated to killing people—the rules for getting and keeping a drivers’ license are actually stricter than the gun laws in most states, including Connecticut, whose gun laws are considered among the toughest.  To operate a motor vehicle, you must take an eye exam, a written test, and a road test, and at least the first two must be repeated every few years.  In contrast, we don’t even have a national registry of gun ownership because of the patchwork of (largely permissive) state laws that often don’t require registration.

“You won’t eliminate guns by banning them.” True, but you will greatly reduce them.  And as the NIH and others have reported, gun homicide rates monotonically track gun ownership across the US already, with people in “high gun ownership” states being 2.5 times more likely to be homicide victims than those in “low gun ownership” states.  Similarly, tougher DUI laws and safety laws have not eliminated vehicular deaths, but they have reduced them by 90% (per mile driven) since the 1950s when no such laws were in place.

“You shouldn’t infringe on the right of law-abiding people to own a firearm of their choice.” Sorry, but yes you should.  Just because I am interested in, say, chemical weapons doesn’t mean I should be allowed to own them.  The Second Amendment is erroneously interpreted as enshrining all firearms past and future, when in fact it was written when the state-of-the-art firearm took nearly a minute to reload between shots rather than an automated technology designed for rapid and efficient mass slaughter.  And as everyone knows (or should), the Constitution and its Amendments are not absolute but rather subject to specific limitations.

“Guns don’t kill people, people kill people.” The statement “guns don’t kill people, people kill people” is false on both counts: guns do kill people—in fact that’s all they are designed to do—and people kill more people with the help of advanced killing technology than without it.

“We need to focus on the root problem of identifying and helping the mentally ill.” While I’m all in favor of helping the mentally ill, this statement is usually used as a dressed-up version of the previous tired cliché.  First, while the most horrific mass shootings recently have been committed by such people, these represent an insignificantly tiny fraction of all US gun homicides.  Second, in case we don’t identify someone’s mental illness in time or help him or her quickly enough, it should be really, really hard for them to get their hands on technology that amplifies their rage or illness.

“We tried banning alcohol during Prohibition, and it didn’t work.” Alcohol doesn’t give me the immediate means to mow down 20 kids in minutes with minimal physical risk to myself.

“If [teachers, citizens, etc.] armed themselves as is their right, they could mitigate the damage caused by [mass shooters, loonies, etc.]” This is the “mutual assured destruction” stance: in the limit, everyone is visibly armed to the teeth, so no one dares actually use their firearms for fear of immediate and devastating retaliation.  Setting aside the question of who would actually want to live in such a society, it doesn’t work: especially in the case of recent mass shootings and many assassinations, the killer frequently takes his own life or is taken down by law enforcement, after the damage has been done.  (The same people who talk about “helping the mentally ill” also trot out this argument, apparently not realizing they are barking up two mutually contradictory trees in so doing.  In the recent shootings, the mentally ill shooter didn’t  exactly give a lot of heads up before opening fire.)

But all of the legalistic arguments pale in comparison to a simple moral truth: automatic weapons designed solely to kill large numbers of people in short amounts of time simply have no fitting role in civilized society. If you don’t believe that, I’m afraid you are just on the wrong side of history.

Four years ago Tonia and I acquired Pogo, a not-yet-weaned keel-billed toucan.  We lost her yesterday in a freak accident, and it’s a bit too close and too painful to include a photo of her here, but she’s in my Facebook photo and she’s the GitHub avatar for the ’saasbook’ organization, so you’ve probably seen her even if you never met her in person.  (And if you had met her in person, you’d remember.)

In the four years she lived with us, we quickly learned that in order to steward a toucan you have to learn to be one, since toucans are not domesticated and haven’t developed the ability to tune in to human behaviors.  (She announced this the first morning we had her at home by pooping in our bed, a remarkable foreshadowing of much pooping to come and that we’d spend much of our time cleaning up after it.  Later that evening, in the TV room, she got nervous about something and tried to fly around, knocking over a glass of red wine.)

So we became toucans.  Through trial and error, we learned that passing food back and forth is an important social bonding ritual, at least as important as eating.  We learned that you can never turn your back on a toucan: Pogo was “always on”, and when she was awake she was constantly getting into everything, looking for trouble.  That’s the nature of the toucan, we learned: she was inquisitive and curious about everything all the time.  We learned that although she would wake at the crack of dawn and start croaking loudly, that was just her “contact call” trying to locate the flock; once we figured that out, we started bringing her into the dark bedroom in the morning to sleep in with us.  She would take a food pellet and hop into bed to perform the all-important exchange ritual to confirm she was with the right flock, then would doze with us for an hour or two or even three before becoming hyperactive again.  We learned that certain footwear sets off aggressive reactions, though we could never fully figure out why or what specific characteristics would trigger it, though it appeared to be related to jealousy.  We learned that by making a gesture with our fingers like a beak opening and closing, we got pecked less often because apparently she interpreted the gesture as an overture to social contact rather than as a threat.  As she learned her way around the house and we became more confident she wouldn’t do something foolish, we stopped trimming her flight feathers so she could be fully flighted around the house, and she learned many paths through the house and flew around with relish thereafter.

We got used to a repertoire of unusual sounds and behaviors. When we left the house to go to work, or had to put her in her house and got out of view, she would start her “contact call” (croak croak croak croak croak) for quite awhile to see if she could locate us.  If we had to intervene to stop an undesirable behavior—move her to a different perch, move her away from food she wasn’t supposed to be eating, or take something away from her that we were afraid she’d swallow—she’d point her beak up in the air and begin a defiant protest (CAW CAW CAW CAW CAW) to express her clear displeasure.  If one of us came home from work after the other of us had already gotten home and let her out, she would hear the front door and quickly hop down the few steps to the upper landing of our staircase, and stand there to see who was coming in.  (hop hop hop hop THUMP)  Sometimes, especially if it was me, her chosen “mate”, she would wait for me to sit on the steps, creating a cavity between my body and the wall; she would then gleefully hop down the rest of the stairs, slap her beak against the floor, and then try to wiggle into the cavity, purring excitedly.  (hop hop hop hop slap slap slap RATTLE RATTLE RATTLE)  If we came home after dark and she was already asleep on her perch in her house, she’d wake up and briefly ruffle her feathers,  often bonking her head on the eave of her house in the process (flap flap flap flap flap BONK flap flap flap) before settling back to sleep, curled up like a football with beak tucked against her back and tail flipped forward over her head.

Once in while, most commonly during the midmorning hours, she’d keep me company while I worked at home, sitting on the back of my chair and preening her feathers.  These morning constitutionals didn’t last long and usually devolved into hyperactivity shortly after, but during the hour or two that she was doing her personal grooming, it was fun to have her supervise my work and just sit close by.

And during very special (and rare) moments, when she was in just the right mood, she would allow us to help preen her feathers and rub her beak.  She would respond either enthusiastically with the same excited loud rattling, or sometimes, if she was very relaxed with me, with an almost intimate very low rattling.  On the latter occasions, she would partially or fully close her eyes while being petted, as I alternated between grooming her feathers, rubbing her beak and rubbing her blue feet.  Those episodes were rare but very special, as it was a moment of actual communing with a very different species.  Those moments remind us that however different we look, we all ultimately come from the same genetic stock and our primitive cerebrums share a common set of motivations: we all seek comfort and safety, we occupy social roles, we all want food and warmth and contentment and a sense of fulfillment in our social groups.  Amazingly, as maddeningly difficult as it often was to learn Pogo’s body language or behavior patterns, it was easy to identify when she felt safe and happy.

We will miss her very much, but her legacy will have been to remind us that although we might never have been ideal toucans, there are things deep in our shared DNA that let us build occasional bridges with the unlikeliest of species.  My wife has always known this, but Pogo was a particularly striking example.

Goodbye, bird love.  We both knew you wouldn’t last forever but we lost you before your time.  Yes, perhaps it wasn’t in your nature to be a “good bird”, but we know you tried as hard as you could, just as we tried as hard as we could to be effective toucan companions and to indulge “the essence of the toucan” whenever possible rather than trying to project our own expectations onto you.  Yes, you were pecky and exasperating at least as often as you were gentle and loving, but you were always amusing and you always found some trouble to get into that we’d never thought of—sorting the compost, learning to let yourself out of your house, eating things you really shouldn’t, or requiring us to rethink placement of food and other items in the kitchen to put them out of your reach, lest you attempt to sample them by beaking each one. When we wondered how such a creature could exist—not the fastest flyer, awkward on land, brightly colored, no natural defense mechanisms, impudent and inquisitive to the point of foolhardy—you reminded us that some creatures get to exist simply because there’s room for them in their ecosystem.

The flock is smaller by one today, but it’s still a good flock.  We will always remember you and we’re grateful to have had the opportunity, for a few years at least, to try to be part of your unusual world and to try to rise to the challenge of seeing it through your eyes and understanding your behaviors.

Advice: have a plan for proofreading and errata. I’ve never had a publisher, and I’m a stickler for writing, so proofreading with a fine tooth comb is something I do anyway. But if it’s not something you do, you won’t have a publisher to help with that.  Dozens of minor errata were reported by readers; we used a Google Form (HTML form backed up by a Google Docs spreadsheet) to collect them.  This has been challenging, because Amazon has their own mechanism that allows readers of Kindle books to report errors.  However, the information reported through that mechanism is relayed sporadically and not sanity-checked; factually incorrect “corrections” from readers are passed straight through, as are complaints from readers who aren’t sophisticated enough to operate their ebook reader devices.  However, those people are Amazon’s customers (and as an author, you are not), so we just have to learn to deal with this.

Advice: set your expectations for “service”. One thing a publisher normally handles is distribution. Amazon’s Kindle Direct Publishing handles that for the Kindle book, but until recently, their service & support for publishers was terrible. (Note that I don’t call it “customer service”. People who buy books are Amazon’s customers. Authors are not.) Recently, though, because of the highly visible success of our MOOC, which uses both the Kindle book and Amazon Web Services infrastructure, Amazon has become much more interested in speaking about strategic things with us, and has given us the level of support usually given to real publishers. We just made our book available on the Nook store and expect to sell it via Google Books starting next month; I’ll report back on whether they are any more responsive to indie authors.

Advice: tell your purchasers to follow you or otherwise let you notify them of updates. A key reason we wanted to do an ebook was the ability to get bug fixes and new content into readers’ hands quickly.  Each release of the book has a version number, starting from 0.8.0 in January 2012 up to 0.8.5 in May 2012.  We applied the errata fixes ourselves, using GitHub to track all book content and tagging the releases as we would with code, and every erratum has a corresponding version number.  Amazon initially told us they’d notify purchasers and allow them to re-download updated versions of the ebook, but they waffled.  (This is now fixed, but only by Amazon’s decision to give us special treatment.)  Without that support, I’m not sure we’d be able to get updates into readers’ hands.  Even so, while readers can now re-download updated versions of our book, it’s up to us (not Amazon) to notify readers when new versions are available.  We can use the MOOC registration email lists to hit many of those people, but others will have to find out for themselves.  We’re now encouraging readers to follow us on Twitter, and we’ll put that text into the next release of the book.

Advice: have a plan for spreading the word via professional forums.  We had already been spreading the word about our course—we had presented posters or talks at CSEET, SIGCSE and ICSE, wrote an op-ed for CACM espousing the teaching of software engineering using SaaS+Agile, and so on.  We’d been collecting names of people who might be interested in trying out our ideas, so naturally we told them about the book too, and offered most of them complimentary copies.  (Unlike with a publisher, the cost of the comp copies comes out of pocket for us, though the print-on-demand house we use, CreateSpace, allows authors to purchase author copies at a price lower than list.)

Advice: be prepared to do your own feet-on-the-ground marketing and publicity.  My marketing experience as a nonprofit theater Board member came in handy.  Following the pattern I’ve used in that world, we designed a postcard and had it printed and direct-mailed by PSPrint to a mailing list we purchased (~600 software engineering professors). The list was ad hoc and included few top-tier departments; in retrospect I’m not sure it was worth the roughly $500 we paid. Successful practice in arts marketing is to follow the postcard with an email reminder a week or two later, but the firm that sold  us the list wouldn’t sell us the corresponding email list, so we paid people to scrape the Web to get them manually (I know, we could’ve Turked it). Then we found out we couldn’t import those addresses into an email list manager such as the excellent MailChimp or ConstantContact, since due to CAN-SPAM laws you may only import email addresses of people who have directly opted in via your own website.  (There’s now an area on our book’s website where you can express interest in the beta program that uses the book.)  So we sent one-on-one emails to just about all those people (600 or so in all).  We also personally reached out to colleagues in top-25 departments with whom we had good personal relationships.  It wasn’t a huge amount of work but it was time not spent on writing.

Background. CS 169 is Berkeley’s upper-division (seniors and some juniors) software engineering course.  The way it’s taught varies widely depending on the instructor. This post describes how I teach it, often with the help of Dave Patterson and recently also Koushik Sen.  It’s not a required class in the major, but rather one of several classes that satisfies specific requirements such as a design project, technical communication, etc.

Prerequisites. This is the only undergrad course at Berkeley that claims to address the topic of Software Engineering.  As such, it’s ambitious and fast-paced, with 5 1-week programming assignments, 5 quizzes, and a significant team project with an external customer, all in a single 14-week semester.  Students should be comfortable with at least 1 other language and with basic programming concepts such as object orientation, classes and inheritance, recursion, and higher-order functions.  Prior to this course, Berkeley CS students take CS61A Structure & Interpretation of Computer Programs, which introduces the four major programming paradigms (until recently using Abelson & Sussman’s awesome “wizard book“,now using Python); CS61B Data Structures using Java; and (usually) CS61C Great Ideas in Computer Architecture (aka Machine Structures), using C, MIPS assembly, and more Java (for a Hadoop assignment).

History. While working on the RAD Lab project (2006-2011), we needed SaaS apps to show off our machine-learning-based technology for automating various aspects of cloud operations.  Since no Berkeley course taught SaaS, we created an informal seminar course in 2007 to bootstrap a cohort of undergraduates to create showcase apps using Rails.  It was so popular that we offered it again, increasing the focus on TDD and good software practices, when our colleague Paul Hilfinger observed that we were well on the way to teaching the basics of Software Engineering in a format that students were enthusiastic about, so why not go all-out and teach CS 169 this way?  We agreed, and we did a “dry run” of the beefed-up course in Fall 2009, debugged it, and offered the “SaaS version” of CS 169 for the first time in Fall 2010.  Enrollments have been increasing by nearly 50% per offering.

Practices taught and course format. The course teaches software engineering techniques based on the Software Engineering Body of Knowledge (SWEBOK) using SaaS+Agile+cloud as the vehicle and Rails as the framework.  A partial list of what we cover includes test-driven development, behavior-driven/user-centric design, design patterns, legacy code and refactoring, deployment (including “SaaS Performance & Security 101”), and working effectively as part of a small team (using version control with branches, estimating progress toward customer-driven goals, work planning, etc.)  Our recent CACM article explains why we believe these choices bridge the gap between what academics believe should be covered in software engineering courses and what industry wants to see in graduates of those programs.  (Contrary to what one might expect, leading software companies do not want us to become trade schools teaching specific tools, languages or frameworks; they want skills that transcend these, including dealing with legacy code and working in a team serving a nontechnical customer.)  We chose Rails because it has the best testing and code-grooming tools and its developer community places high value on beautiful code and thorough testing.  There are two lectures and one small-section meeting (~30-40 students) per week, weekly programming assignments, bi-weekly short-answer quizzes, no “big” midterm or final exam, and a 6 to 8 week course project.  We are experimenting with pair programming as well.

Course project. We work with on-campus organizations including The Berkeley Group to identify external customers—some nonprofits, some on-campus units, some others—whose needs could be addressed in part by a SaaS prototype.  ”Two-pizza” teams of 4-6 students bid on the projects they’re most interested in and we match them up.  During each of four 2-week iterations, students meet with their customer, use lo-fi mockups and user stories to agree on goals, use BDD and TDD to develop new functionality and tests, and deploy to the public cloud on Heroku.  Per-iteration design/progress reviews with course staff (TA’s) help identify problems and provide technical guidance where needed; we have found no substitute for this critical part of the software craftsmanship apprentice process.  (In Spring 2012, two full-time TA’s monitored 25 teams; we hope to improve this ratio in Fall 2012.)  Each team’s progress is publicly tracked and estimated (and visible to customer and course staff) using the free Pivotal Tracker throughout, and grading is based heavily on (a) demonstrated responsiveness to customer feedback on deployed functionality, (b) demonstrated improvement in ability to estimate how much work will be completed by end of iteration, (c) sound use of agile processes as demonstrated by BDD scenarios (which Cucumber turns into integration tests), good test coverage, and reasonable complexity and beauty metrics (cohesion, lack of code smells, etc.) on code, which is publicly accessible on GitHub for review by course staff at any time.  At the end of the course, students present their work in a poster/demo session attended by course staff, the external customers, and invited guests such as industry practitioners and VCs.  Many students reported that their customers were so delighted that they were trying to hire the students to continue the work over the summer.  Two projects from Spring’12 were already deployed in production with real users by the time the poster was presented.

We’ve started gathering screencasts and customer interviews highlighting representative projects; more are being added all the time.

(Coming soon: aggregate code statistics for Spring 2012 projects, including test coverage & code cleanliness metrics)

Scalable grading. Given the growth in popularity of the course and CS courses in general here, we had already been thinking of ways to scale the grading by repurposing testing and code grooming tools such as RSpec, Cucumber, Mechanize, reek, flog/flay, and Webdriver (Selenium) both to assess correctness of student code at a fine grain and give nontrivial feedback on code quality.  When we agreed to offer the first 5 weeks of the course as a massive open online course in Feb/Mar 2012, it forced the issue and made us sit down and write the autograders.  Of course, these are no substitute for actual interaction with an instructor; indeed, the autograders have freed up our teaching staff to focus on creating additional review material and holding design meetings.  (If you’re an instructor interested in participating in our in-classroom beta program, we’ll even run the autograders for you.)

Teaching assistant duties & prereqs. (Thanks to head TA Richard Xia for this info.)  The course is approximately split into two halves, with homeworks and quizzes dominating the first half and the project dominating the second half. During the first half, each TA runs a discussion sections of ~30 students (1-2 hours/week + 2-4 hours to prep and review material), holds office hours (2 hours/week), monitors the online question forums on Piazza (4-6 hours), and miscellaneous tasks such as individual emails and handling regrade requests (4 hours).  In addition, for the first offering of the course the content creation included not only homeworks, quizzes, and section material, but the grading rubrics for the autograders for each type of evaluation.   For the second half of the course, we converted most of the discussion sections into project meetings with the students in which we met with each group for about 10 minutes each week, so less time was spent preparing homework/quiz material and the section-prep time was replaced by evaluating project checkpoints.  A few additional hours per week were spent managing the online course, but as we fine-tune the material and autograder logistics, we expect that the online course can be managed by a single 10-hour-per-week TA, leaving the CS169 TAs free for for direct interactions with the students, especially during the project.

Book. Modern software touches many subsystems of different types, each of which has historically been the focus of some CS subspecialty.  For example, SaaS encompasses datacenter computing, databases, OO programming, network security and performance, and user-centric design, plus nontechnical topics such as how to work with nontechnical customers and deliver a user-centric design. While there are many great (and not-so-great) books and online resources on each of these topics, a reading list cobbled together from them is impractical, lacks a “through-narrative”, and is very hard to get students to take seriously.  We finally decided in early 2011 to create our own book that would introduce enough of each topic to function as a SaaS engineer and weave them together in a way that both made sense for a one-semester (or shorter) course. Our division of topics into largely-standalone subgroups allows instructors with less time or a less-sophisticated audience to select subsets of material appropriate for their needs.  We decided very early to self-publish to keep the price low (currently $10 ebook/$20 print book).  Engineering Long-Lasting Software: An Agile Approach Using SaaS & Cloud Computing is now in its beta draft, and we expect the First Edition to be ready by Spring 2013.

We’ve been busily debugging the homeworks, autograder and other technology at Berkeley, hoping it won’t melt down when lots more students take it.

But surprisingly, those aren’t the things that made my heart skip a few beats the last couple of weeks.

It turns out that when you have 60,000 people enrolled, if 0.1% of them experience a problem, you’ll immediately get 60 identical emails.  And these people are resourceful: they simply Googled the names of the instructors and sent email to our personal email accounts at Berkeley.  Here are some problems those people had in the last couple of weeks.

Fun event #1: Kindle ebook disappears from Amazon.com

About 2 weeks ago, the Kindle ebook mysteriously disappeared from the Kindle store, showing “currently unavailable” if you visited its page.

• We received no email warning before this happened.
• No further explanation was provided on the Author/Publisher dashboard as to why it occurred.  In fact, according to the dashboard, our ebook was “live” and available for sale.
• There was no way to appeal except by sending email via the Amazon KDP “author support” form; we had done this in the past and it takes 3-4 days to get a response to such requests.  No phone number is provided for author support.  (In contrast, CreateSpace, the print-on-demand company handling the print version that ironically is owned by Amazon now, has excellent telephone support.)
• Desperate, we used our academic connections to the highest levels of Amazon to get this looked at.
• We learned that there was a formatting issue with our ebook, and apparently when enough customers complain about that, the ebook is pulled.  Amazon’s system was supposed to have sent us an email notification of the problem to give us a chance to fix it, but due to a bug on their end, that email never got sent.
• Once the escalation occurred, everything was resolved within a day; but if we hadn’t had higher-up contacts at Amazon, we would have been screwed.

Fun event #2: saasbook.info mysteriously shut down for “terms of service violations”

Last week the book’s website, hosted on Google Sites, was mysteriously shut off by Google “for terms of service violations”.  This was puzzling and panicking, since we had just announced to 57,000 students that they could start perusing the book, and this site was where they were directed to go to get it.  Plus, having the students see “This site has been taken down for TOS violations” made it sound like we were fronting pornography or running a link redirector or something equally questionable.

The scenario was eerily similar to the Amazon problem:

• We received no email warning before this happened.
• No further explanation was provided on our Google Sites dashboard as to why it occurred.
• There was no way to appeal (except to click a single button that said “Appeal” with no other explanation).
• Desperate, we used our academic connections to the highest levels of Google to get this looked at.
• We learned that our site had been mistakenly manually misclassified as spam—which was puzzling for any number of reasons).
• Once the escalation occurred, everything was resolved within a day; but if we hadn’t had higher-up contacts at Google, we would have been screwed.

Fun event #3: courseware VM can’t be downloaded or uploaded

We had numerous complaints from people unable to download the courseware VM via our AppEngine front end, and our TA’s were having trouble uploading the image file. Apparently, there were two problems.  One is that Google’s blobstore sometimes sporadically throws an error that doesn’t occur till the end of the upload, i.e. after spending 10 minutes uploading a 1.7GB file.  The error occurs inside one of the wrappers for the BlobStore API, and doesn’t get logged or rescued, so even though we have tech support at Google for this, there’s no way to show them what error occurred.  We ultimately transmitted the VM image file to a colleague at Google who was able to upload it via Google’s intranet.  If we hadn’t had this higher-up contact at Google, we would have been screwed.  (See a pattern yet?)

The other problem seems to occur for people whose Internet service is anemic.  The downloads get throttled and take so long that their ISP’s time out their TCP connection. We’re going to recommend to these folks that they use a download manager; one of the users discovered by accident that deeplinking to the AppEngine app works just fine.

We’re also going to torrent the file, and we’ve  provided an alternative to downloading a VM image—we created an Amazon Machine Image that can be used on EC2.  (A shout out to Yarko Tymciurak in the Chicago area who got us started on this!)  However, for students who don’t want to pay for EC2 usage, the free “micro” tier is just barely adequate to do this work—the CPU pins right away when running tests or builds.

Fun event #4: Kindle ebook updating doesn’t quite work the way we were told

An early and influential factor in our decision to focus heavily on an ebook was that we were assured that if we made significant changes to the ebook, we’d be able to quickly push them out to students by notifying Kindle author support, which would then notify purchasers of the ebook that they had the option of re-downloading a newer version.

This is partly true.  We tried this process last week, since we did in fact fix a bunch of typos and formatting issues reported during the first 4 weeks of the Berkeley course.  It took 3 days for us to get a response from Kindle author support.  The response was that we should submit detailed information about what changes were made, and “within 2 weeks” they’d make a decision of how and whether to handle our request to push the update.  So much for instant update.  They seemed to imply, though, that there was a way they could enable students to request a re-download if we notified students that one was available, so we’re going to try to go that route.  I hope this works, since we expect at least one more rev of the ebook by the end of the online course and then another before the planned summer offering of the online course.

Fun event #5: our Kindle book price is apparently just a suggested price

We had various ebook purchasers complain that although our own Web site says the ebook costs US$9.99, Amazon was displaying a higher price for them, as much as 27% higher in some cases.

It turns out that Amazon can, at their discretion, charge more for your ebook in certain territories “where their operating costs are higher”.  So it was with chagrin that we read these emails, given that we had agonized over the price a fair amount and ultimately decided to keep it below $10.

It also turns out that Amazon can, at their discretion, charge less for your ebook if they’re doing it to price-match a competitor or for other promotional purposes.

But things are rolling along anyway

But the news isn’t all bad.  Kindle ebooks are outselling print books by more than 4 to 1.  We’ve even gotten complaints that people in Indonesia can’t buy the ebook (which is unfortunate, but it’s humbling that we have followers that far away).

We can’t tell how many people are buying both the print book and ebook, since we haven’t been able to work out bundling. (Though we are working on it.)  We also can’t tell how many additional people, if any, have downloaded the free Kindle sample (which roughly corresponds to the first chapter of the book, therefore the first week of class) and may be considering buying the full version later.

We have a very  nice iBooks version about to come out with interactive self-assessment questions and screencasts built right in, and we will probably do a Nook/ePub version for people with non-Kindle ebook devices (though that’s a lower priority).

Overall, it’s been a major learning experience so far trying to reach this many people.  Next week comes the real test…

Besides being one of the most poignant documentaries I’ve seen in some time, it drove home to me how ingrained is our instinct as a species to tell a story.  Here’s a group of people who, in general, have serious trouble driving a car, playing an instrument, writing poetry, doing athletics… yet they relish the opportunity to tell a story, and they rise to the challenge.

Tonia pointed out that two other behaviors we saw in the rehearsals—singing and laughing—also cut across levels of mental ability.

So there it is.  Telling a story, singing, and laughing—the universal constants.  I knew there was a reason I did this theater thing.

And if you harbor even the least bit of idealism about how theater can affect people, watching Yellow Brick Road will be an hour well spent.

“… and your little dog, too!”

The old Star Trek episodes are wonderful morality tales. And hey, it’s not their fault that special effects in the late 60’s weren’t very advanced, and the effects budget per episode was apparently about $50.

I smile at the cheesy effects and appreciate the storyline, but I can’t help but enumerate a few effects things that particularly tickle me as a computer scientist.  I’m blogging these so that someone blogging in 2020 can smile at my comments, and all while giving the original Star Trek the largest possible credit for couching great stories in something that the 60’s thought the future would look like (remember, the final Star Trek episodes were taped a full 2 years before the moon landing):

1. The analog dials on the ship’s computers
2. Computers with AI-complete speech recognition, but synthesized voices that sound terrible
3. Computers that actually emit smoke when they fail
4. Audio communications that fail as analog radio would (analog static and high-Q artifacts, not digital dropouts)
5. Video that fails by getting snow or loss of analog sync (I still can’t believe people used to do all this with analog signals.  That is some studly engineering.)
6. “Video” displays that are clearly posters
7. Mechanical switches for controlling solid-state devices, including the transporter and the “computer”
8. Printers that make mechanical noise when they print (like dot matrix and band printers)
9. The presence of physical books rather than ebooksat various official proceedings
10. Avionics that fail by bursting into flame, yet are apparently repairable at the board or component level

Note that a great many of these effects were actually accurate when viewed from the standpoint of the first computers in spaceflight—see Computers In Spaceflight: The NASA Experience for a most excellent overview and retrospective.

Amazon’s Kindle has a pretty good selection, and they’re at least priced intelligently (~50% of print edition), but you can’t view PDF documents on it. Yes, I know about the “converter”. It doesn’t process tables or figures, making it useless for any technical PDF’s, which for me is most PDF’s. The CyBook uses the Mobipocket DRM format, which is sold by dozens of half-assed retailers whose selection and reputation aren’t even a fraction of Amazon’s and whose pricing is stupid—the ebook costs the same as the print edition, and I can’t even donate it to my library when I’m done with it. But the CyBook does render PDF, so I could at least use it for geek books, technical articles, Gutenberg downloads, etc.

Some libraries have started ebook lending. But the NY Public Library, whose print collection exceeds 50 million volumes, has exactly 945 Fiction titles available in ebook form, most available as only one or the other of Mobipocket or Adobe eBook. Given that Adobe manages to crap on the user experience of every product they put out, and that Adobe Reader still holds my grand prize for crashing Firefox & Safari, I don’t even want to go near Adobe’s ebook format, which they popularized in part by distributing DRM’d versions of Gutenberg etexts—evil.

The book industry seems to be doing its very best to imitate the visionary RIAA and MPAA. I imagine at some point the book industry’s proctologist will call them to tell them that he’s found their head. Until then I’ll keep lugging dead trees around.

Download the free trial version: 750 MB.

The downloaded disk image contained a non-folder icon called “Adobe CS3″.  So I did what Mac users always do—I tried dragging it to my Applications folder. The Finder popped up a dialog that eventually stabilized at “Preparing to copy 109,775 items.”

Well, that’s going to take awhile. I stopped the copy and poked around and finally realized the non-folder icon is actually a folder—nice job, Adobe—inside of which I  found a Setup program.  Aha, I thought, the Setup installer should be faster than actually trying to copy 109,775 separate files.

Wrong. The installer took 45 minutes on a 1.5 GHz PowerPC G4 Mac.

Then I had to download a 58 MB software update to get the Flash Lite 3 functionality recommended for Chumby developers. Not including download time, the updater took 1 hour and 45 minutes to apply a 58MB “patch”.

During this time, you’re not allowed to open any Web browsers, as the updater insists on updating various browser plug-ins. (But it doesn’t tell you when during the 1 hour and 45 minutes this occurs, so you have to forgo Web browsing the whole time.)

This “free trial” download experience does not encourage me to shell out the $995 Adobe wants for the product. (Hell, at my consulting rate, it’s already cost 2/3 of that to install the damn product.)

Maybe Adobe is used to Windows users accepting this level of user insult. Their PDF reader plugins for Web browsers are spectacularly unstable (Mac Preview is far superior), and even after CS3 was installed, it takes 30 seconds just to start up.  Their Flash plugin for Safari and Firefox on Mac seems to be the most frequent cause of those programs crashing (according to the stack trace, anyway, the crash occurs inside the Flash plugin).

So it’s finally happened: I’ve found other desktop software that makes Microsoft Office a dream by comparison. How sad from the company that basically invented PC imaging and multimedia. If I can find an open-source toolchain for Chumby development, I’ll use it even if I can get an Adobe academic license for free. This product deserves to LOSE.