Posts about Technology (old posts, page 2)

Airmail FTW

airmailFinally a thick-client email program that seems to have stuck. So far I am really liking Airmail.

For years I've flipped between various Mac fat clients and the GMail web interface. The web interface keeps winning:

  • Outstanding search
  • Great keyboard shortcuts (go Vi!)
  • Very good use of screen real estate

But the killer is the reliance on a rock-solid Internet connection, and GMail's own slowdowns. Even though there is an offline mode, it is such a downgrade it's not worth using. So if you need to use offline you're in bad shape; same if you're on a slow or lossy connection, or if GMail is having a bad day.  Sadly, that's pretty often these days.

Airmail is cheap ($1.99 in the App Store) and super featureful. It coexists well with GMail's paradigm (archive vs. delete, threading includes sent items, drafts). Great configuration options. Visually pleasing. Robust.

There are really only three places where it has fallen short for me:

  • I miss GMail's tabs. Those are still the best way to filter mail, and I was impressed with how well that feature worked and quickly became natural.
  • Search. Airmail's isn't bad, but nothing is as good at this as Google's own.
  • Gmail (with Chrome) has a great feature where you can drop in a picture and it is resized to look good.  Lacking that I now have to manually resize my giant retina-display screenshots.

So-long to Sparrow and Mail.app and Mailplane. Or until someone does really nails self-hosting.

K&R C Programming, Quantum Books, Cambridge, MA

IMG_4177

Today in a box I came across my old K&R. Probably the most valuable book I've owned. My copy has been heavily used.

But the unexpected, fun thing was finding an old label on the back cover.

There is a lot in there.

IMG_4179

  • January 1994. I had just graduated college, driven cross country with my friend Shig, and started my first post-college job. I would have been in that job four months or so and realized that I should just stop borrowing someone else's copy (probably Larry Claman's) and buy my own.
  • Purchased at Quantum Books, a great technical bookstore in the shadow of MIT in Cambridge, Massachusetts. It's no longer there. The bar that is there now (Meadhall) is a nice place, and I'm a big fan of beer, but it's not the same.
  • According to an inflation calculator, $35 in 1994 is $55 today. That's expensive for a little book, especially to the twenty-two year old me.
  • Note the email address: [email protected]. This was back when mom and pop dialup ISP's where what we all used, people and businesses alike. This particular one, Software Tool & Die, was my private email address at the time too. (Aside: they claim to be the first public dialup ISP, and I have no reason to doubt them)

It was fun being reminded of all this stuff. So the lesson of the story: it's still worth buying books, and when you do, don't remove the labels.

Launch Day

spaceshuttle

Today was launch day. It went really well.  I wanted to capture what a good launch feels like and contrast that with a more exciting launch, just five months ago.

Today we turned on our first class on Stanford's instance the open-source edX platform, what we're calling OpenEdX. The class is Statistics in Medicine, taught by Kristin Sainani of the Stanford School of Medicine. With over thirteen thousand students signed up it's a medium-sized MOOC (Massive Open Online Course).

We have launched MOOC's for Stanford before: two in Fall Quarter, and one in Winter. Even though the classes were huge success, but the launch days weren't so smooth. We had written that platform, Class2Go, from the ground up with a small team in a dozen weeks in Fall; in the weeks before the Winter launch we ripped out the whole evaluation system, about one-third of the code, and replaced it with a whole new engine. In both cases most of our code was fresh off the presses.

Those launches were rocky. I'll tell the story of the DB class launch in January. The first thing we do is a "soft launch," where you open the front door and some people find their way in. Those first visits give you a sense of how things will go.  Surprisingly, the servers were a bit busy.  But we wanted to keep going, so we scaled up capacity and moved on.

The thing that drives real traffic is the announcement email. That gets people to the site. The announcements started going out, students started coming in, and the site lit up. We were in hot water. Servers were overloaded, and most surprising, the database was getting hammered. This was scary and unexpected. We control-C'ed the mail job and quickly hacked additional caching into the site.  We had to trickle out announcements over the next twelve hours.  We made it, but it was a long, stressful day.

And then the days/weeks post-launch were spent watching graphs, triaging 500 errors (user-visible "we're sorry" pages), and installing daily hotfixes. But we got through it. The classes were a success and the team was proud.

So, contrast that to today's launch.  Totally different.

Everyone came in early as usual. I bought bagels. We turned on the class (soft-launch) and the servers hardly noticed. We sent the announcement mails, people came and took their pre-course survey and watched the intro video. Hardly any load. This chart shows the average CPU on our four appservers from 8:00 AM PDT / 15:00 UTC until 10:45 AM or so.

launch-app-cpu

Those are happy servers. Other charts we watched (db connections, load, etc.) told the same story. The most impressive thing was not a single user visible error, no 500's!

Those folks at edX made some solid software.  We're happy to be working with a strong group of engineers and a quality product.  We've had our hands on it only since April, and it was released open-source to the world on June 1.  I fully expect a lot of other universities and organizations are going to have a great time running classes on OpenEdX too.

I just turned off half the appservers since we're fine on capacity. Now off to bed with a good feeling.

Coding on a Flight

airplane

I'm surprised that that I like coding on flights. It's surprising because airplanes are generally hostile environments for most things, but I've found it a good place to code.

The obvious reason is the lack of interruptions and distractions. Usualy there is no wifi, or it is too spotty to count on. So no email or IRC or web. While I know that distractions kill flow, I never seem give myself license to unplug in normal life. I'm a manager, and being a manager means being interruptible.

But there's another reason. When I code unplugged, I code differently. I have to be self-sufficient. Instead of just looking things up on StackOverflow, I take 20% more time to figure it out myself. That's much more satisfying! It's just not that hard to rummage through the Django code or try things out in iPython.

Also it just sounds cool to say you coded something up on the flight.

But thre real question is should simulate "airplane mode" when grounded.  Hmm.