Saturday, December 15, 2012

You’re an idiot if you don’t think gun laws need to be reformed

Sorry, but you are.

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 beenno 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 Amendmentsare 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.

Sunday, November 25, 2012

Kindle Fire: probably good enough



Since Dave Patterson and I have signed up to offer the first 5 weeks of Berkeley’s CS169 Software Engineering class as  a free online course using Stanford’s ClassX, I feel the pressure ratcheted up to finish the textbook we’ve been preparing for use with this course.


We’ve always intended to deliver it primarily as an e-book, and while we have a very promising prototype of a highly interactive tablet version, we recognize that in the near term the mass market for e-books will be the Kindle format.


We‘ve been assuming many (most?) people will use the free Kindle Cloud Reader since it displays color and can take advantage of a larger screen than the Kindle hardware devices.  So we were excited when the Kindle Fire was announced—a color e-book reader that doubles as an Android tablet at an attractive price point ($199) might be something that gets real student uptake.  We ordered a couple to evaluate internally.


First, people are invariably going to compare it to the iPad.  I’d say there’s no comparison.  Besides Fire’s smaller size, its user experience is downright clunky compared to iOS.  (I’m new to Android, but if this is representative of the gap between iOS and Android, they’re two different products.)  Using the tablet is far from intuitive.  Not all of my books appear under the Books tab; some appear only under the Home tab.  And the Home tab is different from the Apps tab.  In trying to review the apps I have, there’s a bunch on there I don’t even understand (hidden apps that came with the device but aren’t visible on the Apps screen), and I can’t imagine how a nontechnical user could figure out what to do with them.  Frequently, dialogs will pop up that require typing, yet the on-screen blind-up keyboard will cover some of the fields, so that it’s impossible to see what you’re typing except by repeatedly hiding and re-showing the keyboard.  There are ever-present buttons along the bottom of the screen for Back, Home, and Search, but these buttons don’t work the same way (or at all) in every app.  For example, I downloaded a YouTube viewer app and was puzzled when the Search button didn’t present a search bar. Turns out the app had its own Search function that doesn’t use the Android-standard everpresent search button.  Big lose.


I didn’t try the media-consumption features (watching TV/movies, downloading songs, etc.), but they’ve gotten .


The touch interface is flawed.  The multitouch hardware is fine, and the build quality of the device feels solid, but the sensitivity to actual gestures is badly off.  It’s nearly impossible to open a book from the “carousel view” without flipping past it.  Page turns are oversensitive, and you can’t hold the device in just one hand because every part of the screen responds to touch and you end up turning pages without meaning to.  (The original Kindle had this problem with button placement.  It’s amazing they didn’t learn from that experience.)  The page turning animation is jerky rather than smooth, and if you balk partway through the page-turning gesture, it’s quite hard to detect whether the page was actually turned or not except by actually re-parsing the words—big lose.


So it’s not an iPad—is it a better Kindle?  Maybe.  I have 3 other black-and-white Kindles (1st gen, DX, and graphite-colored 3rd gen), and my position has always been that those devices are one-trick ponies, but it’s a really good trick.  The 3G in particular is ultralight, can be read in bright sunlight, can be easily held in one hand, is no strain on the eyes, has a battery that lasts for days or weeks, etc.  In contrast, the Fire is too bright to read in a dark bedroom, even at the lowest brightness setting; eyestrain sets in quickly.  You can’t hold it in one hand, not only because of the misdesigned UI that results in gratuitous page turns, but because it’s just too heavy to hold comfortably despite its small size.  Its battery life is a few hours—by the end of my playing around with it on the first day for a couple of hours, it was down to 60% charge.  It seems to combine the disadvantages of the iPad with the disadvantages of a smaller screen (about 7”, or only slightly larger than the 6” screen on the 3G).


What about the rendering of actual Kindle books on the Fire?  It seems to be identical to the rendering in Kindle Cloud Reader, which isn’t great news since the layout possibilities are extremely limited.  (They would be on a small screen anyway, even with more powerful layout facilities.)  The Kindle Format 8 is supposed to improve on this, but I’ve been on their mailinglist since the preannounce and nothing has been announced to developers on what new formatting is possible in KF8.  For the moment, though, the device I’ll always throw in my bag is still the less-expensive black & white Kindle 3G.


Having said all that, the Fire will probably sell well.  Android phones have sold well even though the user experience is clunky compared to the iPhone.  Windows killed Apple on the desktop even though its user experience is a far cry from Mac OS X (or for that matter Mac OS 1 through 9).  Both sold because they were cheaper and because they looked good enough from afar, until you try to really get intimate with them.  As some technology columnist recently wrote, the Fire doesn’t have to be better than the iPad—it just has to be good enough.


I miss Steve Jobs.



Sunday, August 12, 2012

GINAHPTO (Goldstar Is Not A Half-Price Ticket Outlet)

It's interesting (and not always fun) to be working with a theater where I know the budget intimately (because I've been on its Board of Directors) and where I work with performers a lot.

For example, at Altarena, where I do a lot of work and have been serving on the Board until recently, we just learned (it was announced at the theater's 75th Anniversary Gala last night) that our recent production of RENT was the highest grossing show in the theater's history, quite a compliment to its cast and crew.

Now, we don't do AEA contracts, our actors are not paid except for a tiny stipend, our musicians and production staff stipends are near the bottom of the market range even for "nonprofessional" performers, and we rely on volunteers for some functions like ushering.  So, does "highest grossing show ever" mean that the theater's leadership is cackling with glee as they sit on a pile of money that is not being disbursed to performers, whose passion the board is counting on to overlook the extra money?

No.

It means the theater is that much more likely to finish the year in the black.  It means we can afford to replace sound and lighting equipment that costs thousands of dollars and without which shows like RENT wouldn't be possible.  It means we can do the necessary building maintenance so that a 60-year-old non-seismically-designed building can continue to host plays and musicals without water leaking onto people and with the comfort of air conditioning in summer and heat in the winter.  It means we can produce nice-looking postcards, posters, vinyl banners, oversize posters, and programs to promote the show.  It means we can continue to offer cookies and snacks at intermission on a donation basis, rather than charging for them, which would require us to obtain a separate retail license and do a fair amount of tax related paperwork to document retail operations, separately from our 501(c)(3) tax paperwork.  It means we can actually hire employees on salary (with the attendant mandatory benefits, such as unemployment, workers' comp, and so on) to do jobs like managing the box office and front of house, rather than relying exclusively on a corps of volunteers (who'd have to be managed by someone anyway) to do those jobs.  It means we can have a sound insurance policy that would be in place to cover expenses if a performer or patron had an accident on the premises.  It means we are in good financial health overall, which is, ironically, important when trying to raise money from foundations and other grants: they are more likely to support theaters that are on reasonably firm ground and have demonstrated the ability to manage their finances responsibly, rather than theaters on the brink of extinction where the perception is that good money would be thrown after bad.

I can understand why actors don't always see this.  When a show is not selling well, actors see empty seats and wonder we don't give out more comps or sell more half-price tickets.  ([intlink id="36" type="post"]This is why[/intlink].)  When a show is selling really well, they wonder why we don't offer performers more money. When a show is selling moderately well, the same performers who wish we could offer them more money will tell their friends to "go on Goldstar to get half price tickets".

Many shows lose money, especially musicals with large casts.  Yes, they can sell well, but even if the actors are working basically free, expenses such as costumes and cast comps are proportional to the number of performers, and the house holds exactly the same number of paying customers whether the show's expenses cover a cast of 2 or a cast of 20.

Let's do the math.  The estimated production budget for RENT was $29,315.  While our base ticket price is $23, the average revenue we realize per seat is a good deal lower, when you include comps, subscribers (whose per-show cost is around $16), and so on. Let's be generous and say we make $20 per seat, which I can assure you is an over-estimate.  RENT was performed in-the-round, a configuration that accommodates about 150 patrons.  Doing the arithmetic, we need to sell out ten performances just to break even, assuming the show doesn't go over budget in any way.  (The books aren't closed yet, so I don't know if it went over budget.)

So "highest grossing show ever" does not mean the theater's flush with cash.  It means the show did not lose money, it made a modest amount over budgeted expenses, and will make it possible for the theater to finish the year in the black and not in the red.

It'd be great if more performers understood that equation, but given how many small theaters have shut down in last few years because of bankruptcy or poorly-managed finances, and how many more teeter for years on the brink of extinction, maybe this is the most that board members can ask for these days.  I encourage actors and directors who've never tried their hand at the business of show business to get themselves invited to sit in on a couple of board meetings to understand why it's kind of a thankless job.

Tuesday, July 17, 2012

For four years I learned to be a toucan

For four years, I got a brief glimpse into the life of a toucan, by learning to be one.

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.

Thursday, June 14, 2012

My Web 2.0-enabled weekend

I did an impromptu trip to Washington DC this past weekend to see a spectacular production ofFollies, and I was struck by how differently I managed logistics compared to doing a similar trip just 10 years ago.

Instead of shopping for a hotel room, I used AirBnB to find an inexpensive place to stay (and made a new friend).  Instead of picking up a Metro map, I relied on the DCMate iPhone app to navigate DC public transit and estimate arrival/departure trip times.  Instead of a Metro farecard, I used a contactless SmarTrip card (like Clipper in the Bay Area), which I’m going to hold onto for my next trip. Instead of picking up exhibit maps at the Smithsonian museums, most of them now have mobile-friendly online exhibition guides.  I had planned a trip to the historic Civil War battlefields near Manassas (which ultimately didn’t happen because the incompetent United Airlines had aircraft maintenance problems and moved me to an earlier flight), and rather than rent a car I was all set with Zipcar to grab one for a couple of hours.  (Having our lab’s Verizon Mifi unit really helped—I was like a walking access point.) And if I’d had another half-day to bike around DC, rather than renting a bike from a bike shop I could’ve used Capitol Bikeshare—borrow and return bikes by the hour at hundreds of bikestations, which you can find using an iPhone app.

The only thing that worked poorly was United, which cancelled both my outgoing and my return flights due to “aircraft maintenance issues” (apparently they were unable to resolve those issues even at two of their hub airports).  At least they’re advance enough to have SMS notification of these problems.

Thursday, May 31, 2012

Should you self-publish? Should anybody?

Many colleagues have asked us about the experience of self-publishing our textbook.  In a previous post I talked about the DIY technology I harnessed to produce the actual artifacts (both the printed book and the ebook).  In this post I’ll talk about being self-sufficient and doing the other things publishers presumably do for you.


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  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.

Tuesday, May 29, 2012

How to visit San Francisco

If you’re staying in an urban area (SF, Berkeley, Oakland) don’t rent a car while you’re here.  If you’re staying in outlying areas, you might use a car to get to and park at a BART station, but parking and traffic in SF is a headache you don’t need.

Instead:

1.  Get a Clipper card, a debit farecard that works on almost all transit systems in the Bay Area.  Ideally, order one onlineto be mailed to you (takes 5-7 business days), and you can immediately set up Autoload, which reloads your card from a credit card or bank account so you can “set and forget”.  Unused value never expires (though you cannot get it back as cash).  If you don’t have 5-7 days of lead time, you can buy this card at Walgreens drugstores anywhere in the Bay Area, or at the Muni vending machines in the underground stations at Embarcadero, Montgomery, Powell or Civic Center.  Unfortunately you can’t yet buy them at the airports.  Once you have the card, put some money on it at any Add Value machine in the underground stations or at any Walgreens.  Both methods let you use credit cards or cash.  When your trip is over, keep the card for your next visit.  (You’ll surely want to come back.)

Various separate agencies run Bay Area transit, but the Clipper card works on all of them.  BART runs fast trains that connect San Francisco, Oakland, Berkeley, and the outlying suburbs.  Muni runs the buses, trolleys, and “Metro” streetcar/subways in SF.  Other agencies run buses in other counties.  Caltrain runs a commuter rail system from downtown SF (station is adjacent to AT&T Park, the baseball stadium) to San Jose which stops all along the Peninsula.

2.  If you have a smart phone (iPhone, Android, …) bookmark NextBus.com, which provides real-time bus arrivals for most Bay Area agencies based on transceivers mounted in the buses.  It uses GPS to detect where you are and give you departures of nearby buses, or you can select a specific route, stop and direction.  You also may want the Embark iBART app, which has both schedule info and real-time arrivals for BART trains.

3.  Use Google Maps (or the built-in Maps app on the iPhone) to get public transit directions between any two points.  The route and connection info is accurate, but the specific connection times often aren’t because buses may be delayed during peak hours, etc.  The ideal app would combine the directions from Google Maps with bus departure times from NextBus, but as far as I know that app doesn’t exist yet.

4.  Become a member of Zipcar or CityCarShare, both of which have rent-by-the-hour stations all over the Bay Area.  If you’re already a member, everything should just work.  Zipcar has way more vehicles and pickup spots.

Tips on seeing specific things:


The best way to see the Golden Gate Bridge is to bike across, and take the ferry back from Sausalito or Tiburon.  Bike rentals are available next to the Hyatt Embarcadero Center hotel at the Embarcadero BART station and various locations along the Embarcadero between the Ferry Building and Fishermans Wharf.  The rentals include helmets, locks, and excellent maps.  If you don’t want to bike the bridge, the next best way to see it is to get to the bridge plaza on Golden Gate Transit bus10 or 70, which is a lot faster than getting there on Muni since the GG Transit buses make very few stops in SF.

The Ferry Building (just outside Embaracadero BART station) was beautifully restored in the early 2000s and now hosts an urban-agriculture farmers market several days/evenings a week, at which all products must originate within 150 miles of the building.  It is well worth a visit.  Ferries do still sail from here; if the weather is nice, you can joyride the Alameda-Oakland Ferry, which makes a stop at Oakland Jack London Square and another in Alameda before returning to the Ferry Building (whole trip takes about an hour and you get great views of the Bay Bridge and the lay of the land).  A nice “triangle schlep route”  is to take the ferry from the Ferry Building to Alameda/Oakland, end up at Pier 39, walk over to Ghirardelli Square and cable-car back downtown from there.

The Castro is famous for being the gay epicenter of SF, but it's also just a terrifically vibrant neighborhood with some of the best-preserved examples of Victorian architecture, with many houses dating to before the turn of the 20th century.  Get there by taking Muni Metro lines J, K, L, M.

SF has the US’s largest Chinatown, highlights of which include Waverly Place (Tin How temple dates back to Gold Rush days), Ross Alley (home of the tiny Golden Gate Fortune Cookie factory, where you can see them being handmade and eat them right off the production line), and the Vital Tea tasting room (sample a  huge variety of traditional teas that will change your idea of what tea is).

Haight/Ashbury was the epicenter of the 1969 "Summer of Love" and still a neighborhood whose beatnik/hippie roots are very prominent.  Get there by taking Muni bus #6 from downtown/Market Street.

Some of the best views of the city (in the late morning/early afternoon, before the fog rolls in) can be had from Diamond Heights/Twin Peaks and Lands End/the Cliff House out on the beach.

Have an outdoor lunch on nice day at The Ramp (about a mile south of AT&T Park) or Gordon Biersch (on the Embarcadero, under the Bay Bridge).

Locals tend to steer clear of Fishermans’ Wharf, but it does have those fascinating sea lions, and other things in its general vicinity are worth visiting, like the Musée Mécanique containing hundreds of really old (some from early 1900s) mechanical amusement devices, the USS Pampanito submarine, Fort Mason Park, the Maritime Museum, the recently-restored Crissy Field, and the Municipal Pier.  Traffic is awful around there, so either bike there from the bike rental at Embarcadero, walk there from the Embarcadero BART (~20 minutes), or take the F-Market aboveground streetcar from in front of the Ferry Building.

There’s a fascinating collection of restored old ships and interpretive outdoor exhibits of SF’s maritime history at the Hyde Street Pier (just beyond Fishermans Wharf along the Embarcadero).  You can also get there on Muni bus 19-Polk or 45-Stockton.  Nearby is the lovely curving Municipal Pier (at the foot of Fort Mason Park, which has excellent views of the Golden Gate and Alcatraz).  A further hike along the length of Crissy Field will take you right to the foot of the Golden Gate Bridge south anchorage and historic Fort Point, now open to the public, a fort/lookout that guarded the Golden Gate before invaders were able to drive into San Francisco over the bridge.

Outside of SF, Berkeley is well worth a visit, for both the campus and the vaguely funky Telegraph Avenue area just south of the campus’s Sather Gate.  The best way to get there is to take BART to Downtown Berkeley station.

The best way to visit Golden Gate Park is Muni Metro N-Judah from downtown (runs along southern edge of park) or 44-O’Shaughnessy bus from our neighborhood (stops next to the Citibank right across from BART).

Dolores Park/Mission Dolores is the oldest original construction still standing in SF.  You can reach it via Muni Metro J-Church or walking a few blocks from the 16th St./Mission BART station.

Thursday, May 24, 2012

Thanks, Mr. Ambani, for thwarting free online education in India

Given our efforts to provide free education in Software Engineering—an area where India is known to be a strong player—it was particularly disconcerting to read that numerous Web sites including Vimeo and Pastebin have been blocked in India at the ISP level due to a court order.

According to articles in the New York Times and the Wall Street Journal, it sounds like you should make your displeasure known to Reliance Entertainment, a media company largely controlled by media mogul Anil Ambani.

Other news sources report that some ISPs are still allowing Vimeo and Pastebin through, and that proxies and VPNs can be used to circumvent the blockage.

We don’t plan to move our content, and we’re confident the world’s largest democracy will respond appropriately to what amounts to censorship, as we said in our SaaS TV Chat this week.

$5 Amazon gift card if you recommend a printer that doesn’t suck

I’m trying to buy a replacement all-in-one printer for my mom and dad (they have G4 & G5 Macs, an iPad, and two iPhone 4s), and all the ones I’ve investigated (including those sold by Apple in their retail stores, which I take as an endorsement) have had one or more of the following problems:

  • Wifi advertised as a connectivity option, but doesn’t work, works flakily, or works for printing but not scanning (and you can’t activate both wifi and USB at once without redoing factory setup)

  • Gobbles ink, perhaps deliberately, and/or refuses to print or do ANYTHING when ANY of the ink cartridges is low; and increasingly, they can’t be refilled because they are chipped

  • Printing quality sucks


I’m looking for an all-in-one that has the following properties.  If I end up buying the one you recommend, I’ll send you a $5 Amazon gift card.

MUST HAVE features:

  • Works seamlessly with a Mac, without having to install obtrusive vendor software, which is usually among the worst quality software out there (we have 3rd-party scanning software such as VueScan already)

  • Can function with OS 10.5.x (doesn’t require ?10.6)

  • Ink consumption isn’t deliberately rapacious and eco-hostile (can’t refill cartridges, can’t print at all when printer decides cartridges are low)

  • Decent print quality for photos—consumer grade is fine


HIGHLY DESIRABLE but not dealbreaker if absent:

  • Wifi connectivity that actually works and can be setup by mere mortals

  • AirPrint (print photos directly from iOS devices)

Friday, May 11, 2012

latex2ebook now on GitHub: make PDF & ebooks from same sources

I finally got around to extracting the complex toolchain used to create our textbook into a separate project.

You can check it out on GitHub as armandofox/latex2ebook

It’s far from complete, has many restrictions on what you can and cannot do, has many quirks arising from both LaTeX weirdnesses and the limitations of current ebook formats, and is scantily documented (I’ll add more docs as time permits).  Still, it should do what it advertises—allow you to create both a printable PDF and a .mobi format (Kindle, Sony and many other readers) ebook from the same set of LaTeX sources, if you follow some careful rules.

Next task is to add support for epub output.  Anyone point me to succinct documentation for the epub format, and/or an open-source tool that takes the various epub assets and wraps them up into the .epub distribution file?

Thursday, May 10, 2012

About UC Berkeley CS169 “Software Engineering”



Since I find myself periodically explaining our “reinvented” CS169 to my colleagues, and since ourSaaS MOOC is based on it, I thought I’d write up this short description.  (The official link to the Berkeley course homepage is here, but it changes each semester depending who is teaching it.)


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.





























CS 98/198 Spring ‘0725
CS 194 Fall ‘0835
CS 194 Fall ‘0950
CS 169 Fall ‘1075
CS 169 Spring ‘12115
CS 169 Fall ‘12180

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  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 donot 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).   is now in its beta draft, and we expect the First Edition to be ready by Spring 2013.



Sunday, May 6, 2012

Does Amazon KDP want to engage authors or commoditize them?

We just released a new version of  on May 1, 2012.


As we promised our alpha-edition buyers, we fixed hundreds of errata and added two new chapters.


(UPDATE: we’ve deleted the spreadsheet rows corresponding to the fixed errata, which numbered over 200.  So if you look at this list now you’ll find only newer errata reported in last couple of weeks.  You can use Google Spreadsheets’ versioning feature to see an older version of the spreadsheet showing all the errata we fixed.)


Amazon Kindle Direct Publishing (KDP) had told us that when we did this, all we had to do was:


(a) email Amazon and have them notify readers of the changes, and that they could receive a free re-download


(b) email our readers (if we knew who they were) and tell them to contact Amazon customer support and request a free re-download


We have done (b), so Amazon can expect to hear from a lot of readers, especially given that I tried to do (a) two days ago and finally got a robot response from KDP saying “Send us a detailed list of your changes. If we agree they’re major, we’ll notify people.  If they cause formatting issues, we’ll pull your ebook” (as they did without telling us in January).


I tried to reply to this email, as instructed, with a description of the changes and a link to the errata page on which the problems were reported.  Indeed, Amazon itself emailed us a number of haphazard complaints about content (some of which were factually wrong or themselves contained speling errerrs) about the ebook during the 3 months since it was first released.


My reply email bounced.


If I was an Amazon customer having this experience trying to buy a book, someone would likely get fired.  Yet the only reason our previous author problems got any attention is because we used out-of-band research relationships to escalate it through an organization that until then had shown not the slightest sign of giving a shit about the concerns of authors.


Perhaps Amazon will become one more faceless channel for companies like BookLocker or Vook, competing against Google Books and iBooks in a race-to-the-bottom business.  Publishers may take 85 cents on the dollar, but at least they don’t respond with robot emails.  Amazon KDP should decide if it wants to positively engage authors, or commoditize them.  It can’t do both.


Look for  on Google Books in the next week or so.

Wednesday, April 25, 2012

Needed: ebook authoring tools

I’ve been writing a self-published textbook that is sold in hardcopy, Kindle format, and an iOS app.  I firmly believe that ebooks are the future of textbooks, though unfortunately today’s e-textbooks are inferior versions of their print counterparts.  To that end, my co-author Dave Patterson and I took many steps to make the ebook version the preferred version of our book—not by crippling the print version, but by exploiting ebook features that you can’t do in print.

Our original vision was to make the richest version an iOS/Android version, in which we could use extensive CSS and JavaScript to make the book experience interactive in ways that the Kindle ebook format doesn’t support.  We originally tried using PhoneGap for this work, but it wasn’t stable because apparently it wasn’t designed to deal with such large assets (hundreds of KB per HTML “page”, plus many MB of images, plus GB of embedded screencast videos).  When Apple released iBooks Author, we realized we’d have to switch to that, since doing a “native” Android or iOS app was beyond our resources.  We ended up with much of what we wanted—better navigation both within and across chapters, embedded screencasts, and even interactive “check your understanding” question widgets that don’t reveal the answer until you try to answer the question.  But it came at great cost and pain: as we describe below, iBooks Author doesn’t import any useful markup format, even though it generates ePub.

Our experience with doing our own layout and publishing for the print and Kindle editions suggests that the majority of self-publishers and ebook authors may well want to work with a publisher.  The self-publishing process even even for simple hardcopy books is not trivial, but a process that can produce multiple formats with radically different output requirements from a single set of source files is definitely not for the faint of heart.  I described ina n earlier post how we generally did it for our book, concluding that  LaTeX is the worst way to prepare an ebook, except for all the others.

So what do we need?  A better unified authoring environment is a must.  What would my ideal authoring environment support?



  • Device-independent table specification: LaTeX’s table support is painful, but the real problem is that the aesthetics of table layout vary greatly per-platform.  A better platform-independent way of specifying table layout constraints is needed.

  • Tie-in to online resources:  we used Pastebin for code examples and Vimeo for screencasts to augment the content.  The RESTful APIs of these services allow high automation in cross-referencing the content—for example, since we agreed to put each code excerpt into its own file, I made a script that posts each code excerpt to Pastebin, notes the Pastebin URI, and modifies the book source (.tex files) in place to include the link.  I did the same with screencasts.  This could be automated in an authoring environment.

  • It seems likely most ebooks will use an XML-based format of some kind; exporting and importing such a format is essential.  Please, please, please don’t make me use a WYSIWYG editor.  When writing, I want to focus on the logicalstructure of the book and arrange the input the way it makes sense to me.  LaTeX is great for this. In fact, modulo table support, LaTeX isn’t a bad choice as a language, especially since it lets you use macros to define your own book elements, as we did with sidebars, chapter heads, sidebar graphics, pitfalls/fallacies, and soon.  (Though the way it interprets markup is highly user-unfriendly when an error occurs.)  It’d be great, of course, to have WYSIWYGpreviewers for the various output targets, and some people might even like a GUI front-end, but don’t make that the only way to edit!



If you’re thinking of self-publishing, be aware that you’ll have to take care of a lot of “little” typographic things that the publisher usually does, including but not limited to: getting “straight quotes” and “smart quotes”’ right; getting em-dashes and en-dashes rather than ’—’ and ‘–’; inserting © and ™ rather than typing ‘(C)’ or ‘(tm)’; dealing with ligatures (TeX does this for you, but most word processors don’t).  But the biggest one is going to be the hardest for Word users: getting accustomed to automating everything using macros so that changes are easy to make.  If you are used to manually styling your text (changing font size, applying indentation, etc.) rather than rigorously using styles, you’re sunk before you start, and so is your publisher (well, they’re not sunk; they’ll just charge you a lot of money for doing a labor-intensive manual job).

Here’s a list of our original “blue sky” desiderata for a software engineering ebook, and how we did on each one.



  • social networking for group annotations: not done, and we should wait to see how reader platforms’ feature wars about this feature shake out.

  • Code should be “live” — clicking it has effect of (eg) starting the app and dropping into a debugger on this function.  This is hard to do in general, since no current ebook platforms have the programmability to also act as a developer sandbox.  But our code snippets are all linked to Pastebin, allowing 1-click copy and paste into a terminal window or editor if you’re reading the ebook on a computer, and can even be pasted into and run on an Amazon EC2 instance.

  • Markup for code examples should be obvious.  Both the PDF and ebook outputs treat code specially.  The ebook version links each excerpt to 1-click-copyable source code on Pastebin, which has nice  syntax highlighting.

  • Figures should be  animatable (short movies): we currently have no animated figures, but we do have several screencasts sprinkled throughout; they’re hosted on Vimeo and ebook links are live, and in the iBooks Edition the content is bundled so they’re just embedded directly in the book.

  • “Where am I” (Web-style nav indentation) along side column or bottom of page:  iBooks Author does a nice job of this; Kindle doesn’t, even though we create the .ncx file that lists the names and location numbers of all the interesting “navigation points” in the book.

  • Margin notes (sidebars) in print  book are popups/hidden until tapped in ebook: Kindle format doesn’t support this, at least not yet.

  • “Pinning” figures or popups so they don’t go away while you flip  text underneath: Not done yet, but on the drawing board



I’ve been writing a self-published textbook that is sold in hardcopy, Kindle format, and an iOS app.  I firmly believe that ebooks are the future of textbooks, though unfortunately today’s e-textbooks are inferior versions of their print counterparts.  To that end, my co-author Dave Patterson and I took many steps to make the ebook version the preferred version of our book—not by crippling the print version, but by exploiting ebook features that you can’t do in print.If you’re thinking of self-publishing, be aware that you’ll have to take care of a lot of “little” typographic things that the publisher usually does, including but not limited to: getting “straight quotes” and “smart quotes”’ right; getting em-dashes and en-dashes rather than ’—’ and ‘–’; inserting © and ™ rather than typing ‘(C)’ or ‘(tm)’; dealing with ligatures (TeX does this for you, but most word processors don’t).  But the biggest one is going to be the hardest for Word users: getting accustomed to automating everything using macros so that changes are easy to make.  If you are used to manually styling your text (changing font size, applying indentation, etc.) rather than rigorously using styles, you’re sunk before you start, and so is your publisher (well, they’re not sunk; they’ll just charge you a lot of money for doing a labor-intensive manual job).Here’s a list of our original “blue sky” desiderata for a software engineering ebook, and how we did on each one.

  • social networking for group annotations: not done, and we should wait to see how reader platforms’ feature wars about this feature shake out.

  • Code should be “live” — clicking it has effect of (eg) starting the app and dropping into a debugger on this function.  This is hard to do in general, since no current ebook platforms have the programmability to also act as a developer sandbox.  But our code snippets are all linked to Pastebin, allowing 1-click copy and paste into a terminal window or editor if you’re reading the ebook on a computer, and can even be pasted into and run on an Amazon EC2 instance.

  • Markup for code examples should be obvious.  Both the PDF and ebook outputs treat code specially.  The ebook version links each excerpt to 1-click-copyable source code on Pastebin, which has nice  syntax highlighting.

  • Figures should be  animatable (short movies): we currently have no animated figures, but we do have several screencasts sprinkled throughout; they’re hosted on Vimeo and ebook links are live, and in the iBooks Edition the content is bundled so they’re just embedded directly in the book.

  • “Where am I” (Web-style nav indentation) along side column or bottom of page:  iBooks Author does a nice job of this; Kindle doesn’t, even though we create the .ncx file that lists the names and location numbers of all the interesting “navigation points” in the book.

  • Margin notes (sidebars) in print  book are popups/hidden until tapped in ebook: Kindle format doesn’t support this, at least not yet.

  • “Pinning” figures or popups so they don’t go away while you flip  text underneath: Not done yet, but on the drawing board

Monday, April 23, 2012

Crossing the software education chasm



Dave Patterson and I wrote an extended op-ed piece that appears in this month’s Communications of the ACM talking about how and why we reinvented UC Berkeley’s undergraduate software engineering course to bring it more in line with modern development methodologies.


Although at the time of writing we didn’t even know we were going to offer this content in an online course, as it turns out, the same reasons we believe the course worked well at Berkeley also allowed us to offer it as a MOOC.


What are your thoughts?

 Are you doing something similar at your institution?  Have suggestions for us?  Leave comments here or on the CACM article!




Tuesday, April 10, 2012

The UI on Amazon’s Kindle Fire is an embarrassing abject failure

I don’t get it.

Amazon’s mission is to be the world’s most customer-focused company, or something like that.

Did they even try to test out the Kindle Fire UI on any of their customers before inflicting it on us?

I’m really, really trying to like this device (our lab bought a couple to test out).  I’m a committed ebook fan and Kindle owner: I already own three Kindle hardware devices, not counting the Kindle Reader apps I have on my Macbook Air, iPad, and iPhone.  So I am predisposed to want to like this device.

If I download (buy) a book from the Kindle store, it shows up under Books.  If I sideload or download a PDF book, it shows up under Docs.  If I sideload or download a true ebook (.mobi file) notpurchased on Kindle store (e.g., purchased through Pragmatic Programmers, SitePoint, or any other of a number of technical publishers that distribute their ebooks directly off their site), it shows up in Docs.

When I go to Apps, my choices are “device” or “cloud”.  OK, I want to search for a new type of app, so I tap Cloud, and then Search.  No results.  Oh, I see, I have to go to the “store” to search for new apps.  That’s different from “cloud”.  In fact, the Search button seems to do something different and inconsistent in every context in which it’s available.

I have not found a decent free app for Google Maps, Google Calendar, Google News, Google Reader, or Gmail.  Weird given that Google is the company behind Android, the Fire’s OS.  (I know it’s an “Amazon adaptation” of Android, but it’s almost like they went out of their way to make it even moreclunky and unusable on the Fire than on other Android tablets.)  Yes, I can use the Web versions of those apps, but they don’t work particularly well on the Fire’s smaller screen.

The popup keyboard is unusable.  It’s too hard to describe why; try using it and you’ll see.  Auto-correction doesn’t work.  Different softkeys pop up at different times, so the softkey that was a left-parenthesis a second ago is now some random other thing, because you mistyped a word.  The key that means “shift” sometimes turns into the key that means “make the keyboard immediately disappear with no obvious way to bring it back.”  I have an iPhone and use the autocorrect all the time, and it’s graceful enough to give up and not correct your word if you “mistype” it twice in a row.  Fire’s autocorrect will correct your “wrong” word the same way again, and again, and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again,and again, until you just want to punch the device’s GorillaGlass screen.

The reading experience isn’t good.  I talked about this already in an earlier post.

The one and only thing this device has going for it—and the only reason I still try to use it at all: when reading in bed, its backlight means I don’t have to turn on a reading lamp.  This is important for my spouse, who doesn’t read in bed.  If it were up to me, I’d use my black & white Kindle 3G or Kindle DX exclusively.

I never thought I’d say this, but someone has come up with a mobile device experience that is worse than any version of Windows Mobile I’ve used, and I’ve used Windows Mobile since back when they were competing against the original PalmOS.

Apparently the Kindle Fire UI was designed by the same team that designed the unusable “Manage Your Kindle” page on Amazon.  In an era where Google and others have shown how tasteful use of JavaScript can make for a responsive and compelling UI, Amazon has figured out a way to make JavaScript so obtrusive that it makes the UI worse than if only HTML and Web 1.0 technniques were involved.  Don’t take my word for it; try it yourself.  I have about 140 items in my Kindle library, and “managing” them on Amazon’s site is just a joke.  It’s unusable.  There are bugs that cause random popup div’s with raw JSON to appear; the page is slow, and you can’t click on anything until it finishes loading because everything is re-rendering out from under you; no matter how many titles you own, you can never view more than 10 at a time, cannot filter the view, and cannot select multiple titles to perform a batch action (say, batch delete); you cannot manage “collections” and have them sync to your Kindle devices, as you can do with playlists in iTunes; I could go on.  If this UI was a class project at Berkeley it would get a C.

Thank heavens for Calibre.  It’s not perfect, but it’s by far the best overall ebook management app out there now.  And it’s free.  I couldn’t help myself, I sent a few tens of dollars as a donation to the author.  You should too, if only to get him on Amazon’s radar.  Amazon: buy this person, throw away all of your horrendous ebook “management” pages, and replace it with Calibre somehow.  Heck, rebrand and redistribute it and make the author rich.  He deserves it.

I know it’s possible to buy 2 Kindle Fires for the price of one iPad, but it’s also possible to buy two cans of dog food for the price of one sandwich—I’ll still take the sandwich.  Holy crap, does this device suck.  Too bad, because it would be good for customers if the iPad had some serious competition.  This device could have been that, but isn’t.

Monday, March 26, 2012

The little known Golden Gate Transit buses

For reasons I don’t understand, Google Maps doesn’t seem to know about the Golden Gate Transitbuses, even though there’s a whole bunch of them and they are by far the fastest way to get from downtown SF to the Cow Hollow/Fillmore/Presidio area on transit.

There’s a whole mess of bus routes, but the most interesting for SF residents who don’t need to commute to Marin County are the 10, 70/80/81, and 101/101X.  These run from the Financial District (1st & Mission/Transbay Terminal) to Civic Center, then up Van Ness and west on Lombard.  Because they make limited stops, they’re fairly fast (though at $3.75, more expensive than Muni).  For example, from my neighborhood of Glen Park it would take over 45 minutes to get to the Cow Hollow area on BART+Muni (on the 22-Fillmore), but only around 25 minutes on GG Transit, which is competitive with driving once you factor out the time needed to try to find parking in Cow Hollow (good luck).

And if you have friends in town who want to see or walk across the Golden Gate Bridge without the hassle of driving there, taking these buses from downtown SF is an easy way to do it.

They run pretty late, although outside of commute hours they run infrequently (once an hour for most routes), so you  have to plan ahead a bit.

Downsides: they don’t appear to be on Google Maps, so you can’t get transit trip planning that includes them (511.org has a trip planner that does include them, but it’s horrible and inaccurate); they don’t appear to be on NextBus, so if there’s traffic you won’t have a way to tell how delayed they are.

Still, it’s better than taking the 22-Fillmore all the way out there, and certainly better than trying to park in Cow Hollow.

Friday, March 23, 2012

Made it to Spring Break, things still holding together!

We made it to spring break without the online course imploding!  Woohoo!

We were concerned (especially after Homework 2, which we knew was tough) that we were just going to lose everybody.  But no—over 5,000 people are still with us, comparable to Prof. Jennifer Widom’s database course, which I hold as the benchmark.

Dave and I are impressed with the perseverance of the online students, especially given that most have full time jobs.  The next time around we will probably expand the course by a week or two in order to space out the deadlines a bit.  (We just extended most of the homework deadlines by a week for the online course.)  We are also hiring local help (Berkeley students!) to help further debug the homeworks, improve the autograders, create new assignments and quizzes, monitor the forums more regularly, and fix the A/V quality (we know, we know).

We definitely plan to offer this course for free at least a couple of more times over the summer.  Beyond that it’s unclear what will happen–it’s no secret that Coursera is a for-profit company, and we don’t know how long they will make courses available for free.  However, we’re excited enough about this that we will make sure to find some way to keep getting the material out there, and if we can do so for free, we will.  We’ll even get a chance to meet a few of the online students in person—they formed a study group that meets at a Starbucks close to UC Berkeley!

A big thanks to those who had faith in us and have continued to persevere through the course!  And especially those who bought the book—we have 2 new chapters just about ready to go and they’ll be available as a free upgrade around two weeks from now.  As promised, anyone who bought the Kindle edition will continue to get free updates until the book is content-complete.

So…as we get close to the end of the first iteration…

To those who hung on until the end despite the problems: THANK YOU for your patience, for the constructive feedback you provided via the forums, personal emails, comments on these blog posts, and however else you reached out to us.  You’ve made it worthwhile for us by letting us know you were getting something out of the course!

To Instructors: if you’d like to beta test this material in your classrooms, we’ll even offer to run the autograders for you.  See our beta program description if you might be interested.

To Griefers who tried to poison the forum atmosphere early on: see ya, and don’t let the door hit your a** on the way out.  The smart money says that a whole bunch of companies besides Coursera are about to start trying to monetize courses like this (you can read about it in the latest Wired, in the NY Times, and elsewhere), so next time you’ll at least be paying for the right to complain.

And now…Spriiiing Breeeeaaaaak!!!  Wooooo!!! (For the next week I can work from home instead of going to campus.)

P.S.: I had some technical video difficulties with “SaaS TV #2? (salesforce.com) but it should be posted by tomorrow.  SaaS TV #3 (with GitHub) should be available by April 4.  It’s must-see TV.

UPDATE:  I got an unexpected opportunity to speak with Raffi Krikorian, Director of Engineering at Twitter!  That conversation is the basis of the just-posted SaaS TV #3. Next week we hope to post #4 (with Zach Holman of GitHub) and, hopefully, #5 (Dan Webb of Twitter talking about the present and future of JavaScript)!

Monday, March 19, 2012

Crisis Averted: What If You Have to Cancel a Show?

Well, that was exciting.

Because of a problem with Alameda Power & Telecom’s equipment, Altarena had to suddenly cancel tonight’s Of Mice & Men performance.

Happily, the cast agreed to stage a “make-up” performance tomorrow night at 6pm, after the matinee.  Tonight’s customers were told they could either come to that performance, exchange the ticket for any other performance of the season, or get a refund.

But how to “roll over” tonight’s will-call list?

As it turned out, it was pretty simple.  We simply edited the “time and date of this performance” info in Audience1st to reflect the rescheduled time.  Presto-change-o: all patrons who had reservations for tonight now “automatically” have reservations for tomorrow (it even shows up in their online account), plus we can even sell tickets to the added performance to make up for those patrons who prefer a refund or can’t come tomorrow.  Indeed, it’s already listed as an added performance on our Store page—it just happens to be an added performance to which we’ve already sold a lot of tickets.

I hate when unexpected situations like this result in having to cancel a show, but at least the software makes the administrative part of it pretty painless.  So—crisis averted.  Can your ticketing system do that?  :-)

Thursday, March 8, 2012

The downside of online education

In the 90s, the joke was “On the Internet, nobody knows you’re a dog.”  The anonymity of online interaction allowed you to reinvent yourself.

One aspect of offering the online course has been to remind me that “On the Internet, nobody can confront you for being an a**hole.”

I just have to copy-and-paste (verbatim) a recent posting from a student [sic] in the online course forums, because paraphrasing just won’t do it justice:
As you don’t take care of us, the students, due the quality of the course I decide to quit this one

If you (the organizers) realize how important is our time and you decide to take this course seriously then perhaps I will return

Do you (the organizers) realize how many courses like this one are there? Do you realize how serious are them (see udacity for example) and how they care about us?

Is this the quality of the whole university? I now understand why stanford or others are more reputated than cal tech: because they take care about what they are doing but not you, you are making a fudge here and I have no time for fudges

…it goes on for awhile like this.  I don’t even know who this person is—he or she posts as “Garito” with no other information.

I’ve dealt with whiny students before, but this level of entitlement is, frankly, stunning.  Besides the fact that “Garito” provides no actual suggestions and confuses UC Berkeley with Cal Tech, what gets me is the downright nasty and ad hominem assertion:  You don’t care about what you’re doing, or about the students.

We’ve already acknowledged a number of technical glitches that have slowed things down and that we’re working to fix, but “Garito’s” statement is just injurious and insulting.

Perhaps I shouldn’t be surprised.  I volunteer at a nonprofit community theater, and for years it’s been our consistent experience that the worst customers are the ones who got free tickets.  As a group, they complain more, are more likely to cancel at the last minute or walk out of the performance, write the nastiest reviews, and rarely turn into repeat customers even when they said they loved the show.  That is, they’re more motivated by getting a ticket for free than by the product offered.  (That’s also why our theater doesn’t do deals with GroupOn and similar outfits.)

I strongly suspect that online education purveyors will reach a similar conclusion, and hopefully that’ll happen before instructors get sufficiently turned off by attitudes like these that they decide to stop donating hundreds of uncompensated extra work hours for the “Garitos” of the world.

I know it’s human nature, when you’re trying to do a good job at something, to focus disproportionately on negative feedback; very few students, even those with legitimate grievances, have been anything like “Garito” and many more have been very positive in their comments. So in this case, sorry, “Garito”, but all I can really say, to use your own terminology, is “fudge you.”

Monday, March 5, 2012

Week 3: no disasters yet

Our free online SaaS course is now entering its third week, with no major disasters to report!

Our autograder technology is working, thanks to heroic efforts by our on-campus graduate student instructors (i.e. TA’s), especially Richard Xia’s strong Ruby chops, and to Amazon Web Services’ generous donation of EC2 credits to run the autograder processes.  No doubt we will further improve, streamline and fortify the autograders for future course offerings, but without Richard’s efforts we couldn’t have had them running in time.  The autograders give detailed feedback on which tests passed and failed in the homework submission, and we allow students to resubmit homework to improve their scores based on the autograder’s feedback right up until the deadline.

The students are about to submit HW#1, completion of which entitles each of them to a $10 Amazon AWS credit and 90-day GitHub Micro account (thanks to Jinesh Varia at AWS and Kami Lott at GitHub for these very generous donations!).  In fact, based on the activity in the autograder processes (another big thanks to AWS for donating EC2 credits that we can use to run autograders for 39,000 students), thousands of students have already submitted it.

We’ve been humbled by the number of countries represented, including many where , or in some cases cannot easily complete a financial transaction to the US.  We’ve made separate arrangements with many of these students so they can continue the course, but obviously we’ll have to find a sustainable and scalable solution to the distribution problem for next time.  We’ve even had a couple of generous offers from students willing to subsidize the book purchase for others who are in financial hardship.  We’ve fielded emails about this issue from the Gaza Strip, Tunisia, Nepal, Bangladesh, Pakistan, Saudi Arabia, Iran, Turkey, Nigeria, Georgia, Indonesia, Macedonia, Malaysia, Serbia, and Singapore, in no particular order.

Last but certainly not least, we’ve seen a handful of VERY positive and gracious emails and forum posts from people who are clearly appreciative of our efforts and feel they are getting a lot out of the course, despite its imperfections and the inevitable glitches that happen on a first offering.  To those who reached out to us in that way—you know who you are—thank you for both your gratitude and your understanding that this is a brand-new experience for us and that problems will happen despite our best efforts.  I’m spending most of my waking hours focused on this course, and hearing from people like you renews my energy to improve it further.  Originally I was excited about being able to reach 35,000 students, but the truth is that the real reward is hearing from the few hundred for whom the opportunity has had such a positive impact.

Our free online SaaS course is now entering its third week, with no major disasters to report!Our autograder technology is working, thanks to heroic efforts by our on-campus graduate student instructors (i.e. TA’s), especially Richard Xia’s strong Ruby chops, and to Amazon Web Services’ generous donation of EC2 credits to run the autograder processes.  No doubt we will further improve, streamline and fortify the autograders for future course offerings, but without Richard’s efforts we couldn’t have had them running in time.  The autograders give detailed feedback on which tests passed and failed in the homework submission, and we allow students to resubmit homework to improve their scores based on the autograder’s feedback right up until the deadline.We’ve been humbled by the number of countries represented, including many where , or in some cases cannot easily complete a financial transaction to the US.  We’ve made separate arrangements with many of these students so they can continue the course, but obviously we’ll have to find a sustainable and scalable solution to the distribution problem for next time.  We’ve even had a couple of generous offers from students willing to subsidize the book purchase for others who are in financial hardship.  We’ve fielded emails about this issue from the Gaza Strip, Tunisia, Nepal, Bangladesh, Pakistan, Saudi Arabia, Iran, Turkey, Nigeria, Georgia, Indonesia, Macedonia, Malaysia, Serbia, and Singapore, in no particular order.Last but certainly not least, we’ve seen a handful of VERY positive and gracious emails and forum posts from people who are clearly appreciative of our efforts and feel they are getting a lot out of the course, despite its imperfections and the inevitable glitches that happen on a first offering.  To those who reached out to us in that way—you know who you are—thank you for both your gratitude and your understanding that this is a brand-new experience for us and that problems will happen despite our best efforts.  I’m spending most of my waking hours focused on this course, and hearing from people like you renews my energy to improve it further.  Originally I was excited about being able to reach 35,000 students, but the truth is that the real reward is hearing from the few hundred for whom the opportunity has had such a positive impact.

Tuesday, February 21, 2012

Apprehensive, but inspired by Jennifer Widom’s blog. (And no, the book isn’t free.)

So our online SaaS class launched yesterday, with 62k students and counting.

Not having done this before, of course I’m apprehensive.  Will people “get” the material the way we explain it?  Will the book be useful (to those who are buying it)?  Will our autograders (which go far beyond the multiple-choice autograders used in previous courses on Coursera) scale?  Will the material appeal to most of the people taking the course, whose educational profile is pretty different from that of the Berkeley undergraduates for whom the course was originally designed?

The good news is that the course at Berkeley is going quite well, even with lots of new material since any previous offering and even dry-running some of the technologies that will be used for the online version.

And I’m also inspired by Prof. Jennifer Widom’s blog post “from 100 students to 100,000” about her recent experience teaching her Intro to Databases course at this scale.  I found myself mentally saying “+1? to a lot of her statements, such as “Creating these [multiple-choice but nontrivial] exams, at just the right level, turned out to be one of the most challenging tasks of the entire endeavor”; “having 60,000 students is the need for absolute perfection: not one tiny flaw or ambiguity goes unnoticed”; and the emails from students who were “unabashedly, genuinely, deeplyappreciative” (her emphasis).

We’ve received a few nice emails like that too, although like Prof. Widom, we’ve also (already!) got a handful of complainers.  So far, because there isn’t much actual content to complain about yet (the course just launched yesterday), most of those have been either about the fact that the book is not readily available in their country (to which I’m sympathetic) or the fact that it isn’t free (to which I’m not).  One person was wondering why we aren’t paying them to give us feedback on this early version.  (I guess this person doesn’t post reviews on Amazon or Yelp either, unless those companies have a payola system I don’t know about.)

The problem of the book not being available in some places is vexing.  Most of these complaints have come from students in the Middle East.  I hope they realize that we don’t control where Amazon does business and that we are actively looking at options for wider distribution, though I don’t know that we will solve this problem in time for the current offering of the class.  But we really do want to make the book available to as many people as possible.

That said, some people are apparently multiplying 60,000 by $10 (the price of the ebook) and assuming we (the authors) are cackling to ourselves while sleeping on a big pile of money, or expressing some level of indignation that we’re not giving the book away.  The facts are more modest—fewer than 5% of enrolled students have bought the book, we don’t receive anywhere near100% of the price of each copy sold, we haven’t seen a penny of revenue yet (it takes over 60 days to actually get paid, and the book wasn’t available til mid-January), and it’s cost roughly $20,000 of our own money so far (not Berkeley’s money) and thousands of additional hours of our own time (in addition to our regular duties at Berkeley, so it comes out of our weekends and vacations) to create.  That’s not counting the extra time (also our own) to adapt the course materials, develop autograders that (we hope) will provide meaningful feedback on programming assignments, and so on—work that we wouldn’t have done for the on-campus version and was undertaken specifically to do the best job we could with the online version.  It’s great that ebooks make the cost of distribution  nearly zero, but that doesn’t mean the cost of designing and creating the content is also zero. (Just ask my spouse if you don’t believe me!)

So that’s why the book isn’t free, and relax, we are not doing this in order to quit our day jobs.  Indeed, one might conclude that we actually like our day jobs quite a bit if we are willing to do all the extra work (for no extra compensation) of repurposing the course to reach 60,000 students within the constraints of Coursera’s infrastructure, despite the fact there is an active thread on the course forums about “how can I get a copy for free.”

So, to those of you who’ve expressed gratitude and well-wishes, we thank you deeply, and remind you that attitudes like yours are one of the reasons we LIKE teaching and were foolhardy enough to try this project.  We really and truly hope you will get something positive out of the course and that you’ll be motivated to give us constructive criticism on how to improve it, and when the inevitable infrastructure issues do occur, we hope you will be patient as we try to work them out.  We’re trying all kinds of stuff that even other courses on Coursera haven’t tried yet, especially where autograding is concerned.

And to those of you who believe we are doing this as a secret plot to cash out early, or who believe it is your right to get the book for free for whatever reason, sorry to disappoint you but I’m afraid we are just not as cynical as you.  We hope you get something out of the course anyway, and respectfully ask that you respect our work and our effort.

(Personally, like most people I believe that eventually these courses will have to charge some kind of tuition or find an underwriting model, since the expenses are nontrivial: we’ve used our connections with Amazon, Google, Microsoft and GitHub, among others, to secure donations of free products and services to support the class, but probably not everyone can do that.  My hunch is that if direct tuition were involved, even if it was only $10, a lot of these complaints would go away.  I spend a lot of volunteer time helping to run a small theater, and one thing we’ve learned is that if you give product away, some people conclude that it has no value, and they are the ones who tend to complain the most loudly.  The ones who pay usually say “I can’t believe you don’t charge more.”  It’ll be interesting to see how this plays out for online courses.)