ongoing by Tim Bray

ongoing fragmented essay by Tim Bray

FaviconFun With Semiotics 17 Mar 2019, 3:00 pm

I just finished reading The Seventh Function of Language by Laurent Binet; it’s impossibly erudite and also hilarious. If you remember the Eighties and if have some idea why Foucault, Giscard, Nastase, and Eco were interesting, you might really enjoy it, especially if you’re also entertained by sex, violence, and conspiracy theory.

The Seventh Function of Language

I was in the library looking at travel guides for an upcoming vacation, and as I was coming down the escalator the book’s garish cover grabbed my attention sufficiently that I had to go look at it, and then took it home. There’s a story in here about signs and signals and that sort of stuff.

It’s a whodunnit basically, although the author chats away in his own voice, the protagonist keeps wondering if he’s in a novel, the story shamelessly mixes real things that happened to real people with things that definitely didn’t happen and others might be true but nobody will ever know.

Things that did happen in 1980-81.

  1. Roland Barthes was hit by a laundry van after having lunch with Mitterrand; the papers he was carrying were stolen, and he died a month later of his injuries.

  2. Louis Althusser strangled his wife in what the courts consider an episode of insanity.

  3. Right-wing terrorists bombed Bologna’s central train station, killing 85 people.

  4. Mitterrand won the first of several elections as President of France.

Things that didn’t:

  1. Jacques Derrida was not killed by attack dogs unleashed on Cornell University campus by John Searle.

  2. Philippe Sollers was not castrated as a consequence of losing a semioticians’ fight-club debate with Umberto Eco.

Things we’ll never know:

  1. How did Mitterrand hang on to office for so long?

  2. What happened to Barthes’ papers?

Fun as in fun

Seriously, I kept laughing out loud. While there’s deep thinking here about language and meaning, there are fabulous chase scenes, appalling violence, sexual fireworks on a dissecting table, mysterious Japanese ninjas, and a whole lot of sex & drugs & rock-n-roll. And tennis.

And name-dropping; the whole book is one big name-drop, and a lot of the names are portrayed having inappropriate sex and taking inappropriate drugs. But he does it so well that you can’t help but be amused. Well, except for some of those portrayed are still very alive and might not be; can you sue someone for the way they portray you in a work of fiction? For example, I wonder if a certain prominent female American gender theorist will object to having been portrayed as sodomizing a burly French policeman in a threesome including a prominent female French poststructuralist?

Anyhow, by now you probably know whether you’re a candidate to enjoy this one.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconPink Floyd Dad Jokes 13 Mar 2019, 3:00 pm

I took my 12-year-old and 19-year-old to see Nick Mason’s Saucerful of Secrets tour (Lauren had choir practice). The band was grizzled, grey, and genial; when Nick closed by saying “We hope you had as much fun as we did” we felt he meant it. Their stage banter was that of well-bred Englishmen, dry and mild.

Nick’s opening remarks: Hi there. This isn’t The Australian Roger Waters or The Danish Dave Gilmours.

For context: Nick Mason is the only drummer Pink Floyd ever had. The concept is that, since the various Floyd incarnations mostly perform numbers starting with Dark Side of the Moon but there was a lot of good pre-Dark Side Floyd, that’s what Nick and the boys are playing. A Saucerful of Secrets, from 1968, was Floyd’s second album, but its songs don’t dominate.

Nick Mason’s Saucerful of Secrets Stage at Nick Mason’s Saucerful of Secrets

Here are the songs they played ( is remarkable). I knew maybe half, where by “knew” means they’re buried in my hindbrain from unimaginably long ago.

Nick: Hi Vancouver, nice to be back. Last time I was here was… 1970. Anyone here remember 1970? Neither do I.

Wikipedia says: “The band includes long-time Pink Floyd and David Gilmour bass player Guy Pratt; Blockheads guitarist Lee Harris; Spandau Ballet’s Gary Kemp on guitar and vocals; and producer/composer Dom Beken on keyboards.”

Nick: Let me introduce the Saucers.

We were down near the stage, so got too much guitar and not enough drums/voice - on Set the Controls, Nick's epic tom-tom rhythm was sadly dim. The sound would have been guitar-heavy wherever you sat, but (once the sound guys had a chance to settle things down in the early minutes) pretty clean. Well, except for where the band wanted a chaotic noise crescendo.

Nick, introducing Set The Controls for the Heart of the Sun: Looking forward to this one. I spent years touring with a fellow - nice guy, wonderful writer — but he was greedy about hitting the gong. Tonight I get my chance!

The highlights were just what you’d expect: Astronomy Domine, Fearless, If, Set the Controls, One of These Days. Then there was this other tune, not that loud, no vocals, and a lovely familiar bass line, but I couldn’t place it. The setlist gave it away: Atom Heart Mother! Of course, when you take away the string section, the horn section, the choir chanting in Basque (or maybe Swahili or Ojibway?), and the lyric soprano, it can't be quite the same.

Guy Pratt, before Nile Song: Let’s play some dumbass rock&roll! After: We were setting up for a David Gilmour tour, and he asked us for song suggestions. I suggested Nile Song, and he suggested I find another band. So I have!

There was a nice tribute to Syd Barrett by way of a performance of Vegetable Man, never performed live by anyone before this tour.

Nick: That sounds unfinished, maybe Sid came to an end before the song did. But none of this would’ve happened if it hadn’t been for him, you know.

Both my kids were rockin’ and rollin’ in their seats, particularly on the closing charge through One of these Days, which works really well live with a lot of heavy guitar. That made me smile.

Gary Kemp: I went and saw Pink Floyd at Wembley Stadium when I was (sorry, Nick) only fourteen, they were playing Dark Side, and I found that I couldn’t stop looking at Nick drumming. Well, to be fair, he was the only person in the room who was moving.

I’ve always loved Set the Controls and I loved hearing it live; the performance wasn’t like any of the recordings I’ve heard, and no, I wouldn’t say it was better than either the UmmaGumma or Live at Pompeii takes, but it was different and fresh and that tune, it’ll be going through my head for weeks.

But what hit me the hardest was If (“If I were a swan, I’d be gone”) which they dressed up with a big high-drama middle-section instrumental. And its closing line speaks directly to me. As I edge into old age, speech becomes more effortful. The inside of my head is a comfy albeit cluttered place to be, and a lot of the things I might want to say would require too much explanation to be easy. But silence is; too easy.

If I were a good man
I’d talk with you
more often than I do.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconGraying Out 11 Mar 2019, 3:00 pm

For many years I’ve interacted with my fellow humans, I think perhaps more than any other way, via the medium of Internet chat. But in my chat window, they’re fading, one by one. This problem is technical and personal and I felt it ought not to go unrecognized.


Since forever I’ve used a chat client called Adium; it’s open-source, has a good, polished, flexible UX, and is self-updating. The people I talked to, some of them were on AIM, ICQ, on various flavors of Jabber and XMPP and then, in latter years, Google+. What’s happening is, they’re going away. The chat connections I mean, although many of those underlying services are winking out too, one by one.

(That’s the Adium mascot, “Adiumy”, on the right.)

For those to whom those terms “Jabber” and “XMPP” are new, they represented the idea that any chat service should be able to talk to any other chat service, so you could use whichever you liked best, and hang with your friends wherever on the Net they hung their chatty hats.

There was a time when commercial chat services supported XMPP because it was felt to be the right thing to do. But that was old-school hippie thinking, because if chatterers can just go ahead and talk to anyone anywhere, then your service probably won’t go viral and how are you going to monetize? You can simultaneously think markets are a useful civic tool and recognize obvious, egregious failures. So the links were severed and a whole lot of services just died.

At one point, my Adium typically listed literally hundreds of people I might choose to talk with, with a red or green “available” glyph; they were grayed-out of they weren’t signed in.

These days, more and more are always grayed out, because they were on some other service that’s no longer connected. It makes me sad, because I can no longer say “Hey, qq?” when I want to. So I thought I’d cut and paste some of those people. The world being what it is, chances are there are lots that I’ll never chat with again.

So I’m going to tour through maybe 1% of the names in my chat window, for its own sake and to say I haven’t forgotten.

The top of the Adium window just now, only two people currently showing logged-in and available.

Phipps and Sharpe

Simon, long time open-source maven, is an important figure in my life. In 2004, when I ejected from a failing startup and was wondering what to do, Simon reached out and said “How about coming to work for Sun? You’re interesting because you’re a blogger.” I haven’t the vaguest how my life would have turned out if he hadn’t. Bruce’s life and mine have run roughly parallel since 1973 or so; we were students at the University of Guelph; I was a little ahead and marked his papers. Then he got mixed up in technology and markup and eventually XML and hired my wife, and now we hang out together a bit in the Vancouver Electric Vehicle Association. Life is weird.

Let’s move into the territory of people who are still signed on, but not in chat mode. On current trends, they’ll be graying out soon.

Nottingham, O’Grady, Yugui

Mark is a pillar of the net, has done as much as any other human to keep HTTP’s design and specification coherent over the last couple of decades. Steve is an analyst with a baseball cap, and knows really a lot about the Internet biz. Yugui I hardly know —  for a long time she was the Ruby release manager, and has her fingerprints all over the language’s ecosystem.

Gregorio, Hardt, Rohit, Markes, Meier, Mueller

Now there’s a list. Joe is a technologist and evangelist. Dick was a long-time pillar of the Vancouver tech scene, I worked for him as a consultant once and dueled with him over hiring talent on others, now he’s a fellow Amazonian. Rohit is one of the most social humans on the planet and at one point the FoRK (Friends of) list was a force to be reckoned with in the Valley. I went to his wedding. Kevin has fought many standards crusades, most notably microformats; a person who cares deeply about keeping the Net working. Reto preceded me on the Android DevRel team at Google, and taught me a whole lot about advocacy, how to do it with integrity and sanity. Diane, whom I’ve known along multiple axes, lives in a nice part of the world and wears a red hat these days.

Cooper, Enebo

Ahh, Danese, she was doing Internet advocacy almost before there was an Internet. As a Microsoftie, she had to file a special ticket to get a specialized team to get her set up so she could get real Internet Mail, and nobody else there could understand why anybody would want such a thing.

Tom is a Rubyist, we hired him and Charles Nutter at Sun in the mid-two-thousands. He takes good pictures too.

Now we’re moving into the grayed-out territory, and I’ll take a quick tour through the alphabet; I manage to hit almost every letter. You might recognize some of the names.


She was close to my ex-wife decades ago, then a development manager at the University of Waterloo; I liked her a lot but we’ve kind of lost touch.


You might have heard of this guy. Back in my W3C days, we drank like Churchill; not heavily but steadily. Tim’s always been on the right side of the important issues. He and I (and Jobs and Gates) were all born in the same year.


Taught me a whole lot about how the people who build kernels and filesystems think about them. He’s exhibited a regrettable tendency to JavaScript at certain times, but builds wonderful things. I think we’re competitors now.


Chris sat for many years at the heart of Google’s culture and was a voice for sanity in a place that needed a whole lot more of it. Maybe he still is.


My nephew! Got his Ph.D. at ETH in Zürich in some scary combination of medicine and technology and is now making a living with it, still in Switzerland.

Faulkner, Ferraioli

Sally’s a dear friend, does hospitality in Melbourne, we see her every other year, more or less. Julia’s been in Google DevRel, exhibiting courage and grace while she’s fought an endless struggle with the kind of health issue that renders the medical profession alternately helpless and counterproductive; I admire her immensely.


There was a time when Frank was maybe the single most influential person in the world of publishing technology. I think he’s still working on it. I was briefly editor of The Gilbane Report; I still remember a huge lifesaving lunch he bought me when a series of travel/schedule breakages meant that I’d not managed a square meal in two successive days.

Hackborn, Hanley

Dianne is maybe the most accomplished software engineer the world has never heard of, buried in the bowels of Google. She was super helpful when I was trying to figure out how to be a voice for Android at Google. Dervala is a lovely person whose writing I worship, even though she only blogs annually these days. Stop what you’re doing and go read The Wishing Chair, 2018; you’ll thank me.


This one frosts my socks; I’ve worked with Paul quite a bit and like him a lot and our chat linkage is irremediably broken behind some fucking XMPP SNAFU that I’m not smart enough to figure out and fix. He helps build the Internet.


Stephen invented the various Devoxx-related conferences and has done a fine job, contributing to the structure of the software commmunity.

Kilmer, Kimber

Rich is yet another Rubyist, lots of them in this episode; I miss being part of the Ruby family, it’s a fine place. Eliot was one of the original XML posse; we disagreed about almost every issue in the design of XML, but I never doubted his integrity or intelligence.


We hired Ted at Sun as another smart tech blogger; we also have photography in common. I got to know him and his family pretty well in the first blog-centric social-media surge, and thought a lot of them; I hope that family is still intact and hanging in.


Here’s another long parallel path. Phil was one of the inventors of SVG so I first met him in a standards context. Then our sons were on the same soccer teams (they still hang out sometimes) and our families became friends. But geography has intervened and we hardly see them any more.


Gavin was doing magic with XML before there was XML. An eclectic and determined guy, I miss him. LinkedIn suggests he’s still in tech.


Another name you might recognize; deserves credit for some of the nicer flavors you find in geek culture. The second O in “FOO” stands for O’Reilly.


There was a time when Mark was maybe the most interesting person on the Internet. He disconnected with a bang, which decreased the value of the Net but may have saved his life.


“The Barefoot Programmer” and that’s not just figurative, I’ve seen him shoeless in situations that most reasonable people would consider unreasonable. Always on the right side of the issues.


I hardly know Michael but we hung out a bit when he was head librarian at the University of Guelph and I was re-acquainting myself with the place; he never failed to charm me.

Schonbrun, Schwartz, Scoble

Bill and I gave it our best shot at a startup but didn’t quite make it. I went to his wedding and miss him, although last time we spoke, he had the misfortune of being an Oracle employee. Randal Schwartz is a geek’s geek, just type his name into any search engine and prepare to be entertained. We’ve been on a cruise ship together, twice! And then there’s the Scobleizer, perhaps the canonical example of a life lived online. You can’t imagine what it was like in 2004-2005 when he was Microsoft’s Blogger and I was Sun’s and every word we wrote mattered. And did we ever write a lot.


This is of course PragDave; I don’t know anybody in the world more accomplished at writing about software.


Jon, another master of the life online, has spotted a whole lot of technology trends before anyone; it’s never wrong to read what he writes.

Waite, Wardley, Weinberger

Mandy is special to me because she represents the first time, as a member of a Google hiring committee, that I got to be part of hiring a Googler. Great fun online, and you just can’t get any more eclectic. Simon’s presence online is massive and he seems to be right about everything even if I never quite grasped his mapping method. David and I go back to 1990 or so, and he taught me how best to use stories in a business context; this blog certainly wouldn’t exist without his influence.


Fumi is a delightful person, the very model of a modern advocate, bridging the Pacific between Tokyo and Mountain View without apparent effort. Never boring.

Zawodny, Zeldman

Another couple of pioneers of the medium which you are now consuming; Jeremy was blogging way before blogging was cool. Jeffrey was designing websites before almost anyone knew what they were; he and I had way too much fun back in the days of the Web Standards Project, saying unspeakable things in public, but they were necessary things too.

Not blaming the Net

The fact that I’ve lost touch with so many of these people isn’t a technology problem, it’s me, me and the times we live in. Among the clear and present dangers to our way of life, once you get past Global Warming and deranged chiefs of state, the atomization of the social fabric is high, high on the list. I haven’t fought hard enough to stay connected (not alone in that). And time grows short.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon2019’s Crocuses 3 Mar 2019, 3:00 pm

They come early, purple and gold harbingers of spring. Traditionally I have celebrated them in this blog space. But that nearly didn’t happen this year, for reasons that are obvious in the picture.

2019 Crocuses

They’d just come up when we got snow, which then in mid-February kicked off an extended cold snap, many nights hitting -5°C or below, and the daytime highs rarely topping +5°. So those little guys are survivors. They’ve lived under snow, with more shoveled on top (they grow by the sidewalk), and they’re still here. I had to pick and choose my photos because lots are kinda beat-up looking.

The traditional season for Thanksgiving is fall; of having harvested and being ready for winter. I’ll be honest, my gratitude peaks right about now with the first flowers’ arrival. The meteorologists say the Arctic air mass is breaking up and pretty soon the garden’s color palette will expand.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconLP Log 23 Feb 2019, 3:00 pm

What happened was, Lauren said “My friend Leonard from choir has a friend whose husband died, and she’s wondering what to do with his record collection.” I said “If she doesn’t want to try to sell them, I’ll have a look at them.” Then I took off on a business trip. When I got back, Lauren said “You need to bring the records in from the van.” There turned out to be 900. This is the start of a story of musical discovery.

They turn out to be almost all classical, where the exceptions are cheesy-looking pre-Rock pop music. I think this piece will anchor an “LP Log” blog series in which I touch on the LPs’ payloads as I (slowly) work through the vinyl backlog. Also, as the picture below makes clear, I may have to do a bit of furniture shopping because it’s not as though I have enough shelf space for more than a small fraction of these.

Cat walking around on 900 used LPs

Cat for scale.

Just a couple of weeks before, I’d noticed that the old Linn cartridge on my lovely Simon Yorke “Series 9” had crapped out. I can’t complain, it had served me well and it was at least fifteen years old. So I needed a new one and, since I was staring at 900 probably-not-that-pristine records in the face, something to restore & rejuvenate them.

Record cleaner

A survey of the audiophile press suggests that the cleaners from VPI offer a good price/quality combination. The VPI HW 16.5 looked good but hard to buy in Canada, until I visited eBay, where they seem to appear regularly. It’s at least a decade since I bought anything at eBay; they seem to be getting along without me. I missed out on a couple of auctions but eventually scored, probably paying a little too much, jumping the bid by $50 in the closing seconds.

VPI HW 16.5

Cleaning LPs with the machine is just massively cool. First you screw the record down, spin up the turntable, and slather it with cleaning solution (20% isopropyl). Then you hit the vacuum switch and a hollow cylindrical arm with velvety brushes comes down on the disc and sucks the fluid right back in. Two revolutions of the turntable are plenty. It’s pretty remarkable to see an LP go on looking grungy and dim, and come off gleaming.

There are lots of videos on YouTube, but in most of them the actual action shot is embedded in a lengthy “review”. This one is blurry and shaky but gets right to the point.

The guy in the video uses a specialized record-cleaning brush. I didn’t have one in that style, so used a standard super-soft-bristle paintbrush and that works fine.

The cartridge

High-end audio is bloody expensive, and I have never previously purchased a component without listening to it, playing music of my own that I know and love. With the exception of cartridges; dealers are understandably reluctant to keep lots of tiny fragile objects in stock and let customers drop them on their own crappy vinyl. So it was a matter of reading reviews. Boy, are there ever a lot of cartridges out there. One decent survey is the long-running Recommended Components published twice yearly by Stereophile magazine. Check out the Fall-2018 Turntables, Tonearms, and Cartridges section.

Ordering high-end online doesn’t seem to be much of a thing so I got a local retailer, Vancouver’s Hi-Fi Centre, to order it in. The store is really a super pleasant place to visit.

The Hi-Fi Centre in Vancouver

My conversation with the guy there was a little sad. It’s a nice place, they seem to be doing well, but their customers are mostly over 50. I may be among the last generations to care enough about audio quality to do this sort of this stuff. For most people these days, a Sonos or an Amazon Echo or whatever that brings tunes to where they are will do the job. Me, I hope to spend a few more years of evenings sitting up late in a comfy chair with a small adult beverage, spinning the discs and listening, really listening, to them.

After a lot of grinding back and forth and looking for second opinions on the net, I settled on the Dynavector DV-20X2 (low-output option), made (by hand, they say) in Japan. My reasons: The price was within the bounds of sanity. It’s been described as easy to set up. Relative to many other good cartridges, it has relatively high “compliance”, which means it should be easier on the records, most of which are totally irreplaceable. Finally, a couple of reviewers said it did a great job on rock & roll. Yes, I know I have 900 classical records to consider, but I also know where my heart lives. Here it is, in action.

Dynavector DV-20X2 Low on a Simon Yorke Series Nine Dynavector DV-20X2 Low on a Simon Yorke Series Nine

Getting it set up was a major pain in the ass. I couldn’t turn up the original turntable documentation, but fortunately, it’s a major enough issue that there were two different places out on the net that talked through the process. It doesn’t help that I have shaky hands and am at best modestly dextrous. If Simon Yorke comes to read this (he’s retired but I think still living): It’s a great turntable, Simon, but getting the vertical tracking angle right is awful! If Lauren hadn’t helped I never would have managed.

Dusty in Memphis


Finally, it was all tightened down and the wires plugged in. For the turntable’s first outing, I put on a pristine copy of Dusty in Memphis that I’d bought but never played after discovering that my cartridge was busted.

Oh. My. God. Should have upgraded the cartridge years ago. If you haven’t heard good vinyl on good hardware I really don’t have any words that I think will convey the experience. I mean, it helps that at that moment in 1969 Dusty had cosmic mojo, fabulous producers, and took on a list of classics. I guess the most famous would be Windmills of Your Mind, but there are plenty more jewels.

Also, it’s a production triumph. The arrangements are cool, the musicians are razor-sharp, and the recording is just slightly on the dirty side of pristine, which is exactly what you want; it really does that thing that vinyl is (in my mind) a little better at than digital — creating the illusion of a bunch of musicians down at that end of the room.

     When you knew that it was over, you were suddenly aware
     that the autumn leaves were turning to the color of his hair.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconTech Office Sketches 15 Feb 2019, 3:00 pm

Herewith notes from the white-hot center of the Internet software profession. Maybe the reality these reflect prevails across other technology territories, but I wouldn’t know. In no particular order:


Generally it sucks. There’s Skype ’n’ TeamViewer ’n’ Zoom ’n’ Webex ’n’ our own Chime ’n’ GoToMeeting ’n’ and they all suck in their own unlovable idiosyncratic ways. The visual glitches I can tolerate, but the audio problems make me want to scream; dropouts, static, echoes, the noise of hands softly leafing through a document drowning out any non-booming voice.

In my decades-long career, I’ve used one videoconferencing system that was reliable and almost always Just Worked. It was by Polycom, but then the infrastructure people said “super old school” and replaced it with something modern that often doesn’t. I suspect darkly that the technology is passable but a bean-counter somewhere has refused to buy enough bandwidth to make it sing? Blecch.


The amount of screen real-estate per geek grows monotonically. Dual-27" screens plus your laptop’s own screen are table stakes, and I’m seeing the occasional massive 50"-plus 4K screen. I asked one guy “How can you use all that space?” He said “I can’t of course, all the stuff I’m actively working on is in the middle third, bottom half. But having everything else within visible reach is such a win.” OK then.

I have to admit that I’m becoming increasingly conscious that the pixels on my curved 34" Dell U3415W are in fact visible, and the contrast between that and my Retina laptop screens is a perceptible irritant. #FirstWorldProblem.


The proportion that are motorized is higher every quarter. I’d find it hard to live without mine. The mix of people standing and sitting makes the otherwise-dreary rows of software-engineer desks a little easier on the eye, which welcomes disorderly human distributions.

Office space

Since I mentioned it: All the high-tech companies I’ve worked for have resolutely ignored the research I hear about that seems to say putting expensive engineers out on the floor with no separating walls leads to grievous productivity losses. Isn’t this biz supposed to be data-driven?


We do work on the problem, but the gender ratios are still not good.

If you can get past that (I can’t) there are grounds for good cheer. Here in Vancouver we draw from the very considerable Canadian talent pool, but our immigration law lets us hire major distributed-systems talent from almost anywhere in the world. The resulting mix actually makes me feel optimistic about humanity; the AWS Service groups that surround me offer visible in-the-flesh proof that there’s plenty of software talent in any ethnic, linguistic, or geographic slice across the membership of Homo sapiens.

I’m amused that when chance lands two engineers on a problem who happen to share a native tongue, they immediately drop out of English and into Polish or some south-central Han dialect or whatever it is Nigerian geeks speak to each other. There’s this one group near me that has three guys named Muhammad; one them is called by his actual name, then there’s “Mo” and “Momo”. It seems to work, and by the way Momo seems to be the leading expert on AWS Region Build Automation, which is a big freaking hairy deal around here. Protip to the industry: If you’re not recruiting out of West Africa, you’re missing out on major engineering talent.


I’m talking about screens. What with the advent of Mojave, light text on a dark background has officially re-entered the GUI mainstream. But more or less all the younger engineers had already switched their IDEs over to light-on-dark. My white-background IntelliJ and Goland screens mark me as a dinosaur.

I’ve cared deeply about typography and presentation for a long time and the issues here are interesting. I freely acknowledge that my preference for dark-on-light is probably an artifact of my having tuned my brain, in my youth, to ink-on-paper. Since screens are, at the end of the day, light-displaying devices, there’s an argument that the natural on-screen design language for typography and information display is light-on-dark. I wonder if there’s quantitative research in the space?

Speaking of IDEs

I guess the big story is the decline of Eclipse from “more or less everybody’s default” to “there are still people using it”. VS Code has momentum but IntelliJ has a plenty of loyalists, and then the front-end tribe are often in Atom and Sublime. I’m happy to report that neither Vim nor Emacs have gone away. But recently our license server was having problems and I couldn’t use Goland and found the Emacs go-mode story pretty weak.

Speaking of languages

It’s no secret that the Internet still runs, more than anything else, on Java. Could be worse, I remember when it all ran on PHP and Perl. And I don’t want to diss Java too much. The tooling story is exceptional, and once your JVM gets properly warmed up, there’s nothing that runs usefully faster. And these days, for new stuff you should spell Java “Kotlin”. Especially since if you let those young pups who won’t get off my lawn use Java, they’ll emit all this Java 8+ stream/lambda stuff that is easy to make indecipherable.

What’s happening out on the front-end frontier, the Cambrian explosion of JS-based technologies, makes me happy that I mostly don’t go there.

On the back end where I live, we’ve got Go and Rust creeping in big-time. I’m no longer surprised when I pull up some package buried deep in our serverless infrastructure and it turns out to be in Go. Well, and for serverless code too, if only because of the fast startup.

If you live in the world of ML or data science, you’re using Python; you don’t have a choice and it’s not terrible.

Then Rust, for when you get close to the metal. There was an internal new-languages thread where someone said “If you can’t tolerate GC, use Rust. Otherwise use Go.” Sounds reasonable. A few zealots are saying everything new should be in Rust because otherwise you’re being wilfullly unsafe. But I like having the runtime manage memory for me, whenever I can get away with it.

Inside the software

REST is still a really good way to piece pieces of the software world together. Of course, what with the rise of HTTP/2 and QUIC, what the programmer thinks of as RESTful requests are something quite other, out on the wire. This feels about like us thinking we’re using x86 instructions on our silicon even though what the circuits are doing is really totally different.

To the extent that interfaces aren’t REST, they’re mostly event streams of one kind or another. Where by “Event” I mean “JSON blob”; by and large good enough. This is the area I’m working on this year, lots of opportunities for improvement.

The good news: Each generation of devs that comes along is a little more test-infected than its predecessors. I still run across islands of ignorance where they think it’s OK to ship code now and do the unit tests later (as if that ever happens), but less and less each year.

Which computers?

Still more Macs than anything else, although there’s an undeniable Windows renaissance. Having said that, even the smart people with the coolest Surface devices are often bitching about problems with things called “drivers” — what are those for, anyhow? — and lockups, and saying “Sorry, just a moment while I get my computer going”.

If I were a little less aged and cynical, I’d be boiling over with anger at Apple’s inexcusable stewardship of the Mac franchise; Gruber’s “D” grade is maybe even generous. This is a product that used to feature instant wake-up (gone), MagSafe (gone), lots of useful I/O ports including SD card readers (gone), a good built-in photo editor (gone), and the world’s best keyboards (gone). It absolutely shocks me that a company can get away with making its product successively worse and then worse again, year after year. Among other things it speaks to how good the core design of MacOS is.

But maybe 2020 is the year of Linux on the desktop?

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconD&I Soundbites 9 Feb 2019, 3:00 pm

I went to a two-day “D&I workshop for leaders”. Many in biz will know what that stands for: Diversity and Inclusion. The people facilitating were WMFDP, which stands for “White Men as Full Diversity Partners”. Having said that, only one of the two was a white man, and the audience was more gender-diverse than the high-tech norm. Everyone was senior, there were lots of VPs in the room. It had a strong effect on me.


In the technology space, we suck at diversity. We’re broadly better than average at LGBTQ, probably not far off the mainstream at Under-Represented Minorities, and terrible at gender. Tech leadership is by and large aware of the problem, takes it seriously, and would be very happy if there were a lever they could pull to fix it. They are investing considerable energy, including a nontrivial amount of leadership time, a very scarce resource.


I’ve been trying for weeks to figure out my take on the workshop, turn it into a nice narrative with a story arc and Big Lessons. That hasn’t worked. But when I went back to review my notes I found a few really resonated. So what the hell, here are the ones I think worth reading. Draw your own conclusions.

Some of these are what the facilitators were saying. Some of them are quotes from other people. Some are me talking to myself. They start out pretty business-y but get personal.

  1. We were trying to close a $100M deal, and the customer wanted to see our D&I numbers, including diversity among our suppliers.

  2. In hiring, look for “Returnees”, people who’ve taken a break and want to come back to work. In practical terms, these are almost all women who’ve been doing family caregiving.

  3. Shortening the list of qualifications in job postings can be useful, because of men’s propensity to be aspirational in describing their qualifications.

  4. When we get women into the interview process, we hire them at the same rate as men. So we need to interview more.

  5. I am the tech business. I’ve had all the jobs, done all the things. If a diverse population doesn’t want to join it, I’m what they don’t want to join.

  6. If you look at the Fortune 500’s diversity programs, they’re basically all led by women. So we’re asking the outsider group to do all the work of fixing the discrimination against them. A few white guys running some of these things might not be a terrible thing. There’s a parallel with husbands who say they’re happy to help at home but ask their wives to do all the hard emotional/logistical work.

  7. The evidence of bias and anti-diversity prejudice is statistically overwhelming, no matter how many individual leaders deny having it.

  8. Men will remain indifferent unless they perceive they will benefit from D&I.

  9. In tech, the bias is present and measurable, but is rarely explicit or intentional, and the people who empirically must be responsible will hotly deny being part of the problem. (But maybe less so based on attendance at this exercise?)

  10. People don’t know how to talk about it. Talking about it is difficult, and that’s OK.

  11. Short meetings are a form of discrimination — shy people don’t get words in.

  12. This black guy in the sales organization, super senior and successful, says “I haven’t told anybody, but I’ve been keeping count, in meetings, of black people among the customers at my level. Still haven’t got to ten.”

  13. “Insider culture” — individualism — low tolerance for uncertainty — action vs reflection — rationality over emotion — time is linear and future-focused — status and rank win over correctness.

  14. The ultimate privilege is being listened to.

  15. When I mentor people, should I encourage them to be more like me?

  16. Who should be teaching about male privilege? Ideally not always women.

  17. Women say they have to do a lot more thinking before they get their clothes on and walk out the door.

  18. So disappointed at the times I’ve heard “I’m used to it.”

  19. Insiders are identified as individuals, not as members of a group.

  20. It’s totally reasonable for outsiders to see me as “just another white guy”.

  21. It’s not my fault but I’m responsible.

A conversation

In one of the exercises, we were in smallish groups and were asked: “Everyone look inside themselves and find a dimension along which you’re an outsider. Say a few words on what that is and how you feel about it.” Well… I came up empty, and said so. I’m white, male, live in the nation where I was born, straight, able-bodied, well-paid, lucky, and have mainstream tastes.

There was a short uneasy silence. Then this smart, polished, accomplished, person who unlike me is not an insider-on-every-axis looked me in the eye and said “So, why are you here?” The honest truth is I’m really freaking sick of spending all my time in rooms full of men, so I said that but it felt unsatisfactory. I looked for something deeper to say but came up empty.

My crazy idea

I think we in big tech companies should publicly face down our problems, starting with the worst ones. To start with, I’d like us to disclose the actual gender-diversity numbers in our engineering organizations and take a public goal of changing them, say by 5% over a couple of years, and then disclose the results.

Because here’s the thing: The people in the management ranks in big tech are, by and large, pretty smart and resourceful. Tell them they’re going to be judged on any given number, and they’ll figure out a way to move that number in the right direction.

“It’s not my fault but I’m responsible.”

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 9: Google Mapocalypse 23 Jan 2019, 3:00 pm

2019 is definitely the year of Linux on… the dashboard. This Jaguar is the first car I’ve owned with a serious infotainment system, and it’s opened my eyes to a few things, one of which might be a real Google vulnerability: serious competition in the map space.

That’s the main story here, but I’ll tack on a few random observations about the infotainment system for the Jaguar-obsessed that have been reading this series.

About those maps…

At breakfast on my recent road trip, I got some crud in the socket on my Pixel 2 so Android Auto wouldn’t connect, and I was looking for a place in Seattle I’d never been. So I pulled over and puzzled my way through the Jag’s navigation system; this required, among other things, setting up a account; This is harder than it should be. Since I guess the software is mostly’s, I’m going to call these the Here maps. is an interesting story; the old Navteq, they spent some time in the Nokia portfolio, are now owned by a consortium of car companies and Intel, and now appear in German cars, in Garmin, and at Bing.

Once I got going, I really liked the Here maps. The presentation is way prettier than Google via Android auto, with nicely-rendered geography highlights like buildings and parks. Also, it keeps your position at the bottom of the screen with the area you’re going in front of you. I’m going to guess that there’s a way to switch Android Auto maps away from the default mode where North is at the top and much of the map is filled with area you’ve already traversed, but I’ve not found it.

The Here maps also make terrific use of the fact they’re on two screens. Most times, the little screen behind the steering wheel shows an intelligently-selected subset of the main screen, but then when you’re coming up to a tricky multi-lane corner or freeway exit, the small screen has a picture showing you which lane you need to be in, or a picture of what the freeway exit sign looks like.

Jaguar I-Pace map display

Pardon the low-res picture; trying to shoot the dashboard while navigating, at night, is not exactly recommended practice. Note the lane-choice detail behind the steering wheel. In this case, the detail readout is also echoed on the main screen, but sometimes the displays are completely disjoint.

As for accuracy, in my small sample size it was fine; there were a couple of odd-feeling routings, but I got where I was going. Any other criticisms? The keyboard for entering destinations is sluggish; but then I haven’t tried the voice search, which apparently is available. Speaking of slow, the nav system is really slow to boot up; you’ll need to wait fifteen seconds or more after turning the car on before it’s ready to take and give directions.

But when I’d cleaned out my phone’s USB (Protip: toothbrush) and Android Auto was working again, I didn’t go back, I stayed with Here. I wonder which of Google and Here has better information about where the traffic jams are?

There’s a widespread perception that Google Maps are unbeatably far ahead; for example check out Justin O’Beirne’s masterful not to say exaustingly exhaustive drill-downs on the relative merits of Google and Apple maps. But, maybe not.

News flash

In the last couple of months I’ve switched from Google to DuckDuckGo for my everyday searching, and from Google to Here for auto navigation. I’m wondering if I’m looking at cracks in the armor.

The rest of the stuff

The Jaguar infotainment software has been panned by several reviewers, who say Tesla and Audi are the gold standard. I’m thinking those guys must be pretty good, because there are a lot of things I like about the I-Pace UX.

  1. Multi-screen is good. As I mentioned, you can put the big-screen maps on the little screen, but then you can also put the big screen audio readout on the little climate-control screen, leaving the big screen free, for maps I guess.

  2. That audio readout is pretty nice. I may have abandoned Android Auto maps, but I’m still spinning tunes through Google Music, for reasons I described in 2015.

    It turns out you don’t have to switch over to the Android Auto screens to do that. The Jag infotainment system recognizes Android Auto as another music source, and will show you what you’re listening to, along with album art, in a visually-pleasing display, way nicer than Google’s.

  3. Jaguar I-Pace music display
  4. The reviewers particularly griped about the system being laggy. Yeah, but it just doesn’t bother me. There are one or two corners that are really slow, but they’re fripperies I don’t need. One thing I do is switch from high-regen for city streets to low-regen on the highway. There are a couple of routes to get there, involving both swipes and taps. But neither of them adds up to more than two or three seconds, and glancing at the road between the steps makes me feel safer.

  5. There’s a “favorite” button you can assign loads of different functions to (I picked pause/restart audio) and quite a few other opportunities for customization.

  6. There’s actually a built-in Web browser. It does a great job of displaying ongoing, so it must be OK. There’s also some canned news and financial applications, what I believe on a computer we’d call “bloatware”.

That I-Pace cabin, it’s the nicest car interior I’ve ever spent time in. And it’s not close.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 8: Road Trip! 22 Jan 2019, 3:00 pm

Today I drove the new I-Pace 290.3 mostly highway kilometers. In the best online I-Pace community, the top topic, with 1,115 posts as I write, is I-Pace range. Because when you come to electric cars, range anxiety is a thing. Today’s road-trip report will cover the general highway experience but, since it’s the hot topic, will zero in on range. Spoiler: You can almost always go 300km without trying too hard.

Here’s the trip.

290.3 km of travel

It was a three-leg trip, from Seattle’s downtown to one of its western neighborhoods, then to SeaTac airport, then home to Vancouver; only the last (longest) leg is illustrated. This picture is from the JLR “Incontrol” app, which runs on your mobile and is also a Web site.

What it feels like

The I-Pace is a dream on the big highway. To be fair, this is largely due to it being a well-built modern car with modern features.

  1. I think I already mentioned the seats are fabulous, but it’s worth saying again: really great.

  2. The weather was lousy, between 5°C and 8°C pretty well the whole way, alternating between drizzle and lashing rain. The climate control is actually not as vanishingly perfect as our old 2003 Audi’s, as in sometimes you notice the fans are blowing a little harder than you’d like on your torso or thighs; easy to correct though.

  3. The automatic setting on the wipers did the job, shifting from extra-slow intermittent in the drizzle to bangin’ ’em hard in a tractor-trailer’s wake in a downpour.

  4. The assisted-cruise-control is a treat. You set a maximum cruising speed and when there’s someone in front of you (i.e. almost all the time) it follows them automatically; the default follow distance gives you exactly the two-second gap recommended in safety tips.

    By the way, I am not remotely interested in any “self-driving” capability that falls short of “Tim can open up his laptop and do a code review.” Seriously, what’s the point?

    But I think the assisted-cruise makes the highways globally safer at a level related to the number of people using it.

    I read at least one reviewer who said the Jag’s assisted-cruise implementation wasn’t up there with the best. I can believe it; when a slowpoke pulls out in front of you, the Jag deploys the heavy regen and it can be kind of shocking. And when you get out from behind someone who’s going a whole lot slower than you’ve set the cruise, the Jag decides it’s on a drag-strip.

  5. On the subject of raw power: I drove conservatively, assuming that this lurid-blue lightning bolt would be a cop magnet. But there were a few occasions when I booted it, for example when asshats tried to dart into my two-second gap, and on one occasion when I realized that I was about to be seriously in the way of three cars trying to merge from an on-ramp I hadn’t noticed, and there was no room to move over. Well, tee-hee-hee, there are very few cars in the world that can rocket-launch forward from a starting speed well over 100km/h the way this does.

  6. The car’s whisper-quiet around town (so nice) but when you’re doing 70+mph on rough asphalt in a driving rainstorm, it’s not dramatically quieter than a decent modern fossil car; the tires and all the air and water hitting the car can get in the way if you’re playing soft music.

Bottom line: I’ve driven this route too many times, in a variety of automobiles, my own and rented. The I-Pace got me home feeling a really a lot less stressed and wasted than anything else I’ve done the trip in.

Now, about range

The wisest thing I’ve seen on the subject is on the site in a post by DougTheMac. It’s worth reading in full, but here are a couple of excerpts. This point, on how to think about range, is crucial:

I think there’s a big difference between the required behaviour on a longer-than-usual trip and a very-long-trip. The difference is because on a road trip, you are reluctant to let the SoC get below maybe 20% in case the charger you are relying on isn’t available and you have to divert. Also, on a road trip, you probably only want to recharge up to 80% because the last 20% is very slow. So, the distance between recharging stops on a very long trip is perhaps 60% of the actual achievable range.

But if you start from home with a full charge and pre-conditioned, and your destination at the end of the day is either home again or a destination with 100% certainty of an overnight charge, then you can use 95%+ of the battery capacity with reasonable confidence.

Explanatory note on “conditioning”. You can tell the car what time you plan to depart, and on schedule it’ll get the cabin all pre-heated for you, and if it’s plugged in, also boost the battery to the correct operating temperature. This is said to increase range, but I have no idea how much.

Here are his conclusions (for those of us in metric-land, his breakpoints of 100M, 150M, and 190M are around, respectively, 160km, 240km, and 300km):

  • Trip distance <100M: Charge to 80% (! q.v.), pre-condition, drive to have fun.

  • Trip distance <150M: Charge to 100%, pre-condition, drive to have fun.

  • Trip distance <190M: Charge to 100%, pre-condition, drive a bit more gently, monitor, but expect to get to destination without a charge en route, albeit perhaps down to <5% on arrival.

  • Trip distance 190-310M: Plan for a single en-route charge, ideally from c20% SoC (to give the safety margin required in case the planned charger is unavailable) but only up to the SoC required to get to the final destination with a minimal SoC (5%?). A single 20%-80% charge should add 120M (80%-20%=60%x200M), hence 190+120=310M with 5% on arrival at the “safe” destination. But if you only need an extra 50M, you only put in the required amount to just get you to your safe destination.

Like I said at the top: You can go 300km, assuming you’re sure of having a place to charge when you get there. The road to Seattle is 230km with lots of hills, and there are long stretches where the speed limit is 70mph and everyone cruises at 80. So while a chilly day like today isn’t the North American worst case — that would be something like Canada’s Rogers Pass in midwinter — it’s worse than average.

I used the car’s “comfort mode” both ways; it’s got an “eco mode” which could probably have done better. On the trip down I still had 90km of advertised range when I pulled up to a charger in the basement of an Amazon building, which suggests a total of 320km. Today I went 290.3km at an average speed of 87km/h and had 8% charge when I got home. The car said it had 26km of range left; do the math.


After I unloaded, I headed over to the handy neighborhood fast-charger, where by “fast” I mean 50kW. This is about as close to a “full charge” as the Jag is ever likely to get: 78.174 kWh in 2 hours.


Modern battery-electric cars are just fine for medium-long road trips.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 7: I-Pace Over 100 15 Jan 2019, 3:00 pm

That’s over a hundred kilometers of course, which it took three days to achieve.

  1. I’m enjoying learning how to deploy that electric-Jag power gracefully. Yeah, you can floor it, which is shocking if brutish fun and might damage your neck vertebrae. But you know what’s way sweeter? Coming out of a corner, or around a slower car, and easing the accelerator down, and then further and further down, smoothly. You can’t do this for more than a few seconds without being in seriously unlawful territory anywhere this side of the Autobahn, but oh my goodness those are really very pleasing seconds; the pool of acceleration is bottomless.

  2. I’ve had two charging experiences so far (haven’t needed any, just trying to learn the ropes), both from ChargePoint, both perfectly smooth. You plug in the big heavy connector, fire up the app, hold your phone up to the machine, and away it goes.

    But I’m glad I’m going to have my own charger before the month is over, because the “fast” chargers like the one illustrated here are in demand and not well maintained; of the two in the picture, one is out of order and apparently has been for a couple of months

  3. I-Pace at fast charger I-Pace, fast charger and its infrastructure

    Above, charging in progress; below, another angle. The black box at the right below is supporting infrastructure; the label on the side says 80A worth of 3-cycle power.

  4. There’ve been stories of people having trouble getting their I-Paces to connect to one charger model or another, but I’ve had none on two out of two experiences. The “fast charger” took me from 86% to 96% full in a half-hour. (That’s 11.26 kWh, or almost exactly one Canadian dollar’s worth at residential rates.) This is not as lame as it sounds, because the charging speed declines as the battery fills up, notably slowing down past 80%. Thus, when on a road trip, it’s considered to be smart and courteous, at a roadside fast-charger, to unplug and go at 80%.

  5. The turning radius is large, bigger than our old Honda van’s. Maybe something to do with the wheels being pushed out to the corners? This is particularly annoying because any fool can get into the rhythm of jamming a shift-stick back and forth between Drive/1st and R while three-pointing on a narrow street, but my fingers are nowhere near learning how to hit the Jag’s D and R buttons without looking.

  6. I-Pace car seat adjustments
  7. I’m dealing with angst about the seat position; it’s a paradox-of-choice problem, there are just too many controls. I may have to go all engineer and take a systematic approach, making one change at a time on one lever at a time. I should be clear that it’s a fabulously comfortable seat, it’s just that I can’t prove it couldn’t be better.

  8. The “Park Assist” feature, which has two dedicated buttons, doesn’t work. It’s not just me, I asked my peers and everyone agrees that yeah, it’s just broken. Shame on Jaguar, other modern cars get this right. I wonder if it can be fixed in software?

  9. In fact, it’s a good thing that the I-Pace is so much fun to drive, because it’s generally a pain in the ass to park. The visibility through the tiny dim near-horizontal back window is laughable, the rear-view camera is a little laggy (great picture though), and the car is wide. I’m sure I’ll figure out a way to curve into place, reasonably close to and parallel to the curb, but I haven’t yet.

  10. Driving my fossil car to work was dumb and this one being electric doesn’t change that. Parking is still expensive, as are the L2 chargers in Vancouver office-building basements.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 6: I-Pace Day Two 14 Jan 2019, 3:00 pm

No highways were harmed in the preparing of this blog fragment; our new I-Pace is for the moment an urban runabout. In town, it doesn’t get you anywhere faster than a Honda Fit or 20-year old Ford Focus would. But those burn fossil fuels and we should all try to stop doing that.

[Yes, I said I was going to do live updates to Sunday’s Green Light piece, but that turns out to be annoying. Sorry.]

Jaguar projection

The door handles are flush when parked, but slide out when you unlock. When you unlock at night they glow and project, absurdly albeit with decent kerning, on the adjacent pavement.

  1. I originally wanted to get white paint because I unhealthily loved the red-leather-seats option and thought the white/red combo was cool. And I still think so, but I’m glad Lauren convinced me to go for Caesium Blue. It’s a lovely color, lighter than it seems in online pictures.

    I was afraid the blue/red would look kind of garish but now that I’ve seen it I don’t care. If I worried about that kind of thing I wouldn’t buy a Jaaag, right? I do wish they offered a nice forest green though.

  2. It’s dead cool to pull out your phone, pop open the car’s remote-control app, and set the internal climate to 20°C ten minutes before you go out to drive somewhere on a Canadian winter night.

  3. The headlights have autonomic voodoo; they click into high-beam mode when they think nobody’s in front of you (correctly, so far) and apparently try to point away from the eyes of drivers in oncoming lanes.

  4. Yeah, the infotainment screen navigation is kinda klunky and slow, and the menu tree isn’t the most intuitive thing. But it’s not that big.

    I found that within a day, I had perfected a leisurely wave gesture, somewhat in the style of a Tai Chi master or opium smoker, and achieved menu mastery.

  5. When I plugged in my Pixel 2, Android Auto initially coughed and belched, but the kinks worked themselves out and it’s now a first-class citizen of the big middle screen. It’s kind of cool having Google maps on the big screen and Jag’s own maps, which are more eyecandyful, up on the “instrument panel” screen behind the steering wheel.

  6. Jaguar I-Pace screens including Google Play

    Aesthetics by Jaguar on the left, by Google on the right.

  7. Prior to buying the car, I’d blown off negative comments on its infotainment app by saying “who cares, I’m going to use software from a software company.” But I have to say that the general presentation of the Jag software on Jag’s screens is prettier than Android manages. There’s been attention to typography, there are tonal gradients in the background, and so on.

    Having said that, it doesn’t have my 13,096 songs in the cloud like Google does, and doesn’t know what “OK Google, text Lauren” means, nor “OK Google, Calgary weather.”

    I’m not actually sure what outcome I’d like to see on this one.

  8. The user manual is available as a mobile app; the Android version gets horrible reviews mostly because it only covers a couple of Jaguar models. It’s actually not bad, with a search function and visual guide and rich hyperlinking. There’s also a PDF version online at, and then when you get the car there’s a hefty slab of dead trees in the glovebox.

    However, all of these are sadly incomplete in their coverage. For example: The car comes with a feature where you can have it play whooshy spaceship crescendos as you accelerate, to help petrol-heads who are missing that fossil-combustion roar. No form of the manual told me where in the menus it was hiding. OK, I was trying to impress a 12-year-old, but still.

    Also, I wanted to fool with the instrument panel display, which has many modes. The manual is full of English sentences that have subjects and verbs and objects but somehow failed to map, in my mind, to what I was seeing on the car’s screens. I appreciated the advice I’d picked up in the online Jaguar community, which is that this wisdom is best consumed with the help of a couple of glasses of the Famous Grouse. So I went and bought some, but there are lots better Scotches and it didn’t help that much.

  9. Oh right, online communities. The best for my money is at although, as the name suggests, it’s Euro-heavy. There’s also (note the hyphen) but it’s not as good. On Reddit there’s r/jaguar and the still-embryonic r/ipace.

  10. I’ve signed the car into the home WiFi network and turned mobile data on. It came with an AT&T Canada SIM and despite several pleading emails from AT&T, I have no idea what that does. It was already network-connected somehow because the remote-control app tells me where it is and how charged it is and lets me do things like turn on the heating inside.

    I also turned network updates on, and noticed that the software is a couple releases behind the latest. More investigation is definitely required.

  11. Speaking of apps and suchlike, someone is building a Python library to talk to the I-Pace’s API, and making good progress. There are lots of interesting APIs, many of which Jaguar’s remote-control app doesn’t use. Hmmm…

[Life lesson: A really good time to write about something is while you’re learning about it. I learned this from Mark Pilgrim and if you’ve never heard of him that’s OK (if sad).]

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 5: The Green Light 13 Jan 2019, 3:00 pm

I picked up the new family wheels, a 2019 Jaguar I-Pace, on January 12th. Current plans are for this blog fragment to get updates for the next couple of weeks, through a planned road trip, per the “diary” part of the series title.

The wait

I’d reserved a spot in March and ordered the car in July, so it’s been a wait, and I’ve been in a sort of Gatsby-and-the-green-light mode. It’s not as simple as expectations being high, although the car’s won loads of awards; the early shipments have not been problem-free, and the car has picked up a legion of haters — chiefly $TSLA longs, but still.

JLR fail

During the 5-month wait for the car, the number of times Jaguar contacted me: zero. The number of status updates they gave me: zero. The typical delay when I emailed asking what was up: Days. Mind you, I was dealing with salespeople and, from their point of view, the sale was already made.

Maybe I’m just dealing with a particularly lame salesperson or dealership, but in the event that I want to consider another JLR product, you can bet I am not going back to Jaguar Vancouver and I wouldn’t particularly recommend them.

In fairness, they handled the Big Day processes of paperwork shuffling, insurance coverage, taking my money, getting the remote-control app set up, and explaining the car’s workings, with perfect competence.

Jaguar I-Pace close-up

About as expected

First important finding: If you’ve been tracking the online traffic about the I-Pace, which I summarized in Jag Diary 3: What We Know, getting in the car and driving it around won’t present that many surprises. It is more or less what it says on the box, and what the Internet said about the box.

So I’m going to try to restrict myself in this space to findings that are new or refreshing or surprising, which probably means of specific relevance to those who are some combination of Pacific Northwesterners, Internet geeks, urban dwellers, environmentalists, and parents of teenagers.

Journey 1

Day 1 impressions

We picked up the car in the morning, then drove from Vancouver down to Steveston for lunch, then back home with stops for photography and shopping. To the right, the Journey graphic from the I-Pace remote app, which gets scathing reviews on Google Play.

  1. It’s smaller than you’d think. My carport’s still under construction so the Jag’s parked on the street in front of the house, and it’s not one of the larger cars along the block. The contrast between small outside and spacious inside is shocking.

  2. It’s nimble! That electric-motor acceleration is awesome; Unless you’ve stomped the accelerator in a Tesla or I-Pace you just can’t imagine what it feels like. But in practice, it means that if you’re trying to get out of the supermarket parking lot across a couple lanes of oncoming traffic you can Just Do It, it feels like teleportation.

  3. The seats are just awesomely comfortable — I sprung for the upscale-but-not-racing level, with some huge number of adjustments, and it feels like I’m being cradled by a huge warm benevolent being.

  4. The Meridian audio, at first listen, is underwhelming, the bass sounding unnaturally light to my ears. Will report back after further adjustment.

  5. The regen braking is fun, but when Lauren was driving and I was passenging, I found it a little uncomfortable. Perhaps a combination of us developing better one-pedal driving skills and passengers just getting used to it will change this finding. But in the online I-Pace forums, a lot of people are recommending low-regen for comfort, especially on the highway.

  6. Lauren, who’s 5’5" with a light build, found the driving position perfectly comfortable and loved the handling. She’s right — this car loves to warp around a corner at speed.

  7. Parking takes some getting used to. It has lots of sensors and alarms which moan piteously if you get anywhere near the curb or cars fore and aft. My first attempt left it halfway out in the street, and crooked.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconOil Fail 6 Jan 2019, 3:00 pm

Today I learned things that I think every environmentalist and investment manager should know: A coherent argument that we are more or less at Peak Oil. Not the Nineties version, which worried that we might be running out of fossil fuels, but rather that global human petroleum demand is about at its all-time peak and about to start drifting down. Some of the key data points involve electric cars, which I care a lot about, and China, which is always interesting.

The effects are likely not enough to avert the oncoming global-warming disaster, but there are grounds for optimism about reducing its devastation. However, this will very likely tear the guts out of the global petroleum business.

Tweet thread

What happened was, I ran across an interesting Twitter thread starting with the bold claim that the internal combustion engine’s future had been killed and that the coming energy transition would pay for itself. It was compelling and I gave it a retweet, noting that people who live in an environmentalist-green bubble (for example, me) need to be skeptical about things that we’d like to be true. And so we should.

But I was intrigued enough to buy a 105-page PDF called Oil Fall; you can too, for $9, from its author Gregor Macdonald. If you care about these subjects, you should. I sure enjoyed it.

(If you buy it: While you can read it on a Kindle, don’t try, the type’s too small. It might be OK on an iPad. Or you can just pop it open in Preview on a Mac or whatever the Windows equivalent is. It’s nicely typeset and illustrated; the print isn’t dense and the 105 pages go by fast.)

Oil Fall by Gregor Macdonald

The larger stories — of the increasingly-threatening specter of climate change, and the growing viability of renewable energy — aren’t new at all. But there’s one piece of new news: The shocking surge of Electric Vehicles (hereinafter EVs) in China in 2018, concurrent with a decline in overall vehicle sales there. Probably 1.2 million or so EVs were sold, surging to comprise 7% of all sales toward the end of the year. Here are a couple of instructive links: CleanTechnica and

The argument in Oil Fall spends a lot of time on electric cars, since they are at a point of surprisingly high leverage in the global energy economy.

I’m not going to replicate the Oil Fall narrative, but here’s a quick sort-of outline.

  1. Los Angeles as a case study in EV adoption. It’s not the US leader (that’d be the Bay Area) but it’s got huge leverage.

  2. The politics and economics of renewable energy in California and across the US.

  3. The special leverage of the EV on the energy economy.

  4. The structure of China’s (historically coal-dominated) energy economy.

  5. Why China is crucial to the future price of fossil fuel

  6. The timing of the peak in global oil demand.

  7. Efficiencies and inefficiencies in fossil and renewable energy sources.

  8. The issue of energy storage.

  9. Economic cost of transition to renewables; estimates have been around 2% of GDP, but Macdonald thinks it’ll be closer to zero, or even negative. That’s what Alexandria Ocasio-Cortez and the young US progressives are arguing with their “Green New Deal” proposal.

  10. Global-warming prospects.

On the writing

I don’t know much about Macdonald. His resume sounds respectable, and I quote: “He has written for Nature, The Economist Intelligence Unit, The Financial Times of London, The Harvard Business Review, Atlantic Media’s Route Fifty, The Petroleum Economist, and Talking Points Memo.”

The text is well-supplied with numbers and supporting infographics. He is careful to address, for each key point, the objections to his reasoning and alternative scenarios that arise in the case that he’s wrong. I didn’t check his numbers exhaustively, but every one of those that I did try to verify checked out.

The style is that of a professional journalist: Not colorful but extremely clear, readable, and full of named real-world examples illustrating his arguments.

I’m going to dig a little deeper into a couple of points that were new to me and resonated.

On EVs and storage

Anybody who’s a renewable-energy fan needs to have thought a lot about energy storage. The sun only shines during the daytime and sometimes even prevailing winds don’t blow. Macdonald goes deep on the subject, and offered a pretty compelling argument that there are plausible market-driven solutions to meet storage needs.

One part of the argument involves electric cars, and is obvious once you think of it. Planet-wide, we are now building millions per year, and every one is built around a battery ranging in capacity between 20 and 90KWh. Do some multiplication and you get a damn big energy-storage capability, made up of a huge number of independently-owned consumer products. They aren’t terribly fussy what time of day you charge them, they are network-connected, and managing the network to charge them when the capacity is most available feels like a straightforward application of the sort that I work on every day.

On EVs and negawatts

That term “negawatt” was coined way back in 1985 by Amory Lovins, one of the original big energy-policy thinkers. He did the math and showed that the cheapest way to get more power while doing less damage was simply to cut waste. And it’s worked: Our houses are better insulated now, our cars get more mileage, and our appliances run cooler and smarter.

But the global energy-efficiency picture is still terrible. The whole fossil-combustion ecosystem wastes something in the neighborhood of 50% of the available energy. It’s not uniform: For example, a modern natural-gas based generator wastes less. But internal-combustion vehicles waste a lot more, even today the figure is in the 70%-wasted range.

EVs, on the other hand, turn electrons into kilometers at an efficiency well over 90%. Of course, that doesn’t help if you’re using electricity that was generated in a fossil-fueled plant; but traveling in a renewable-fed EV is a rich source of negawatts.

To quote Macdonald: “But, the loss is quite a bit worse with every gallon of petrol poured into an internal combustion engine. Indeed, if your goal was to waste as much energy as possible, you could do no better than to feed gasoline into a billion vehicles, each with their own separate engine, with multiple surfaces from which heat can rise.”

Is oil over?

Of course not, don’t be silly. Everyone agrees that coal is “over” and yet its usage hasn’t plummeted, it’s just been drifting down for a long time, with a temporary spike as China industrialized. Petroleum remains useful in a huge number of industrial chemical processes, and in certain particularly energy-intensive transportation applications, like heavy trucks and probably almost all aviation. We don’t need to stamp out oil to save the planet, just burn less.

My own particular guess is that natural gas is going to be strategic. It’s relatively energy-dense, straightforward to extract and transport, and carbon-light; it feels like a good fit for filling in renewable-energy gaps.

On investing

There’s a trend where “ethical investors” try to steer capital away from the petroleum industries, and I broadly approve, mostly due to fear of climate change. But if Macdonald is right (and he’s pretty convincing) this is also a good way to remove a major source of risk from your portfolio.

Don’t say I didn’t warn you.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconSF-5: Serverless Bills? 30 Dec 2018, 3:00 pm

One of the best reasons to go serverless is that you might save a lot of money. This is especially true when your load is peaky and has quiet times; because when your infrastructure isn’t working, you’re not paying. But, not all loads are peaky. And here’s a quote from an AWS internal mailing list: “For every compute load, there’s some level of TPS where Lambda is going to be more expensive than servers.” So, when is that? And how much should you care?

[This is part of the Serverlessness series.]

Saving money with servers

The answer, of course, like always, is “it depends”. But let’s just jump straight to what strikes me as the canonical example of someone for whom serverless didn’t work out financially. To learn about it, check out this blog piece by Cory O’Daniel, From $erverless to Elixir.

Tl;dr: No, wait, I don’t want to do a Tl;dr! The piece is funny and wise and instructive and if you care about this stuff, you should just go read it. Go ahead, I’ll wait and be here when you get back.

There’s no doubt at all that they saved a lot of money. The key lessons I took away from O’Daniel’s piece:

  1. They were smart to start up serverless, the app was running fine and requiring no management.

  2. It was hard to get the serverful version running; they saw success on the third attempt, and ended up needing to know a whole lot about the inner workings of the Erlang ecosystem.

  3. As Cory says, “Mind that we already have an ops team and we already have a Kubernetes cluster running.”

  4. Elixir is massively cool. I want to use it for something before I give up on computers.

And of course, Cory’s closing soundbite (most highlighted on Medium) is worth reproducing:

So, should everyone go and rewrite their Serverless services in Elixir? Roll out Kubernetes? Get a nose piercing? Absolutely not … What everyone should do is think about where your service is going, and can you afford those costs when you get there. If you don’t have a team of ops people and you aren’t familiar with serverful stuff, spending $30k/mo on HTTP requests might be cheaper than an ops team.

Do I agree?

Mostly, I think. Although if Cory worked for me I probably would have been sort of pushy about making absolutely sure that there was no way to keep the current system around and still save some money, rather than toss-and-replace (on the third attempt). I note that a lot of their charges were API Gateway, and there are other ways to get data into the system. The data was on Kinesis, which is fine, but there are cases where something like SQS or Kafka can be cheaper. But in the last analysis, it’s not written in letters of gold on stone that serverless will always be cheaper.

Cheaper serverless

To get a feel for the kind of thing I’d look for, let’s head over to another blog piece, How We Massively Reduced Our AWS Lambda Bill With Go, by Sam Bashton of, a nifty-looking monitoring/troubleshooting service. His narrative sort of echoes Cory’s, off the top: A popular Lambda-based app started running up some big bills, to the point where it was becoming painful.

This particular Lambda (like Cory’s) didn’t do much more than pull some data in over the network and persist it. What was hurting is that they were running the function for each customer, for each AWS region, every five minutes. And since business was good the number of customers was increasing fast; well, you do the math.

Rather than retreating to servers, what they did was smash all those functions together into one, and bring the magic of the Go language Lambda runtime to bear. Let me quote Sam:

In a single morning we refactored the code to use a single Lambda invocation every minute, operating on 20% of the customer base each time. This Lambda spawns a Goroutine per customer, which spawns a Goroutine per region, which spawns a Goroutine per AWS service. The Lambda execution time hasn’t increased significantly, because as before we’re mainly waiting on network I/O - we’re just waiting on a lot more responses at the same time in a single Lambda function. Cost per customer is now much more manageable however, becoming lower and lower with every sign up.

Isn’t that nice? And no throwaway code, either.

Closing thoughts

My opinion hasn’t changed at all: For building software, use serverless where you can. Obviously, “where you can” depends a lot on the specifics of your app and your budget and your sensitivities.

And when you’re working out the costs of serverless vs serverful, ask yourself: How much is it worth to you to not have to manage hosts, or containers, or capacities, or Kubernetes? I don’t know the number, but I’m pretty sure it’s not zero.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconChristian Practice 26 Dec 2018, 3:00 pm

I’m in Regina, Saskatchewan with family for the holidays. Someone said “Let’s go to a Christmas Eve carol service” and five of us did that. We went to Lakeview United, where “United” signifies the United Church of Canada, the biggest Protestant denomination up here. It was uplifting and pleasant and sort of sad. Disclosure: I’m not Christian at all; but still.

Carol Service at Lakeview United

As you can see, the congregation (for the 8PM December 24th service) was sparse and elderly. The statistics are remorseless: Christianity is in decline. The proportion of Canadians who attend church weekly is not far from 10%.

This surprises me, if only because the Church’s tools are still very strong. The voices raised in Christmas hymns were breathtaking (the crowd, while small, sang well), the Gospel’s words telling the Christmas story were beautiful, and Sue Breisch, the Minister, was eloquent and welcoming, broadcasting love and empathy. Here are some of her sermons.

The building is really fine in a Sixties kind of way, its main hall comfortable, with big comfy rocking chairs and coffee tables at the back.

Maybe it’s as simple as this: Even if you don’t actively disbelieve (as I do) the Christian narrative, religion has lost its urgency, and as lives are increasingly filled by the Net and the pressures of late capitalism, there are ways to fill Sunday mornings that feel more important.

Having said that, I enjoyed the words and music intensely — lack of faith didn’t get in the way — and recommend doing this sort of thing from time to time. I also think it might be good for you. And maybe I’m wrong, maybe Jesus is the Way, the Truth, and the Light, and you’ll end up saving your soul from eternal torment.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconSF-4: Serverless Latency? 14 Dec 2018, 3:00 pm

Suppose we like the idea of going serverless (we do). What should we worry about when we make that bet? What I hear when I talk to people thinking about it, mostly, is latency. Can a run-on-demand function respond as quickly as a warmed-up Web server sitting there in memory waiting for incoming work? The answer, unsurprisingly, is “it depends”.

[This is part of the Serverlessness series.]

What we talk about when we talk about latency

First of all, in this context, latency conversations are almost all about compute latency; in the AWS context, that means Lambda functions and Fargate containers. For serverless messaging services like SQS and databases like DynamoDB, the answer is generally “fast enough to not worry about”.

There’s this anti-pattern that still happens sometimes: I’m talking to someone about this subject, and they say “I have a hard latency requirement of 120ms”. (For those who aren’t in this culture, “ms” stands for milliseconds and is the common currency of latency discussions. So in this case, a little over a tenth of a second.)

Inside AWS, a claim like that would be met with a blank stare, because latency is way, way more than just a number. To steal from an old joke: Latency is more complicated than you think, even when you think it’s more complicated than you think. Let’s start with a graph:

Latency Graph

To start with, nobody should ever talk about latency without a P-number. P50 means a time such that latency is less than that 50% of the time, P90 such that latency is less 90% of the time, and so on into P99, P99.9; and then P100 is the longest latency observed in some measurement interval.

Looking at that graph, you can see that half the queries completed in about a quarter of a second, 90% in under a second, 99% in under five seconds, and there were a few trailers out there in twenty-something second territory. (If you’re wondering, this is a real graph of one of the microservices inside EC2 Auto Scaling, some control-plane call. The variation is because most Auto Scaling Groups have a single-digit handful of instances in them, but some have hundreds and a very few have tens of thousands.)

Now, let’s make it more complicated.

Running hot and cold

The time it takes to launch a function depends on how recently you’ve launched the function. Because if you’ve run it reasonably recently, we’ve probably got it loaded on a host and ready to go, it’s just a matter of routing the event to the right place. If not, we have to go find an empty host, find your function in storage, pull it out, and install it before we fire it up. The latter scenario is referred to as a “Cold Start”, and with any luck will only show up at some high P-number, like P90 or higher. The latency difference can be surprising.

It turns out that there are a variety of tricks you can use to remediate cold-start effects; ask your favorite search engine. And that’s all I’m going to say on the subject, because while the techniques work, they’re annoying and it’s also annoying that people have to use them; this is a problem that we need to just do away with.

warming up a lambda

Photo: Ryan Mahle from Sherman Oaks, CA, USA -

Polyglot latency

Once the triggering event is routed to your function, your function gets to start computing. Unfortunately, that doesn’t mean it always starts doing useful work right away; and that depends on the language it’s written in. If it’s a NodeJS or Python program, it might have to load and compile some source code. If it’s Java or .NET, it may have to get a VM running. If it’s Go or C++ or Rust, you drop straight into binary code.

And because this is latency, it’s even more complicated than that. Because some of the language runtime initialization happens only on cold starts and some even on warm starts.

It’s worth saying a few words about Java here. There is no computer language that, for practical purposes, runs usefully faster on general-purpose server-side code than Java. That is to say, Java after your program is all initialized and the VM warmed up. There has been a more-or-less conscious culture, stretching back over the decades of Java’s life, of buying runtime performance and being willing to sacrifice startup performance.

And of course it’s not all Java’s fault; a lot of app code starts up slow because of massive dependency-injection frameworks like Spring and Guice; these tend to prioritize flurries of calls through the Java reflection APIs over handling that first request. Now, Java needn’t have sluggish startup; if you must have dependency injection, check out Dagger, which tries to do it at compile time.

The Go language gopher mascot

The take-away, though, is that mainstream Java is slow to start and you need to do extra work to get around that. My reaction is “Maybe don’t use Java then.” There are multiple other runtimes whose cold-start behavior doesn’t feature those ugly P90 numbers. One example would be NodeJS, and you could use that but I wouldn’t, because I have no patience for the NPM dependency labyrinth and also don’t like JavaScript. Another would be Python, which is not only a decent choice but almost compulsory if you’re in Scientific Computing or Machine Learning.

But my personal favorite choice for serverless compute is the Go programming language. It’s got great, clean, fast, tooling, it produces static binaries, it’s got superb concurrency primitives that make it easy to avoid the kind of race conditions that plague anyone who goes near java.lang.Thread, and finally, it is exceedingly readable, a criterion that weighs more heavily with me as each year passes. Plus the Go Lambda runtime is freaking excellent.

State hydration

It’s easy to think about startup latency problems as part of the infrastructure, whether it’s the service or the runtime, but lots of times, latency problems are right there in your own code. It’s not hard to see why; services like Lambda are built around stateless functions, but sometimes, when an event arrives at the front door, you need some state to deal with it. I call this process “state hydration”.

Here’s an extreme example of that: A startup I was talking to that had a growing customer base and also growing AWS bills. Their load was super peaky and they were (reasonably) grumpy about paying for computers to not do anything. I said “Serverless?” and they said “Yeah, no, not going to happen” and I said “Why not?” and they said “Drupal”. Drupal is a PHP-based Web framework that probably still drives a substantial portion of the Internet, but it’s very database-centric, and this particular app needed to run like eight PostgreSQL queries to recover enough context to do any useful work. So a Lambda function wasn’t really an option.

Here’s an extreme example of the opposite, that I presented in a session at re:Invent 2017. Thomson Reuters is a well-known news organization that has to deal with loads of incoming videos; the process includes transcoding and reformatting. This tends to be linear in the size of the video with a multiplier not far off 1, so a half-hour video clip could take a half-hour to process.

They came up with this ultra-clever scheme where they used FFmpeg to chop the video up into half-second-ish segments, then threw them into an S3 bucket which they’d set up to fire a Lambda for each new object. Those Lambdas processed the segments in parallel, FFmpeg glued them back together, and all of a sudden they were processing a half-hour video in a handful of seconds. State hydration? No such thing, the only thing the Lambda needed to know was the S3 object name.

Another nice thing about the serverless approach here is that doing this in the traditional style would have required staging a big enough fleet, which (since this is a news publisher) would have meant predicting when news would happen, and how telegenic it would be. Which would obviously be impossible. So this app has SERVERLESS written on it in letters of fire 500 meters high.

Database or not

The conventional approach to state hydration is to load your context out of a database. And that’s not necessarily terrible, it doesn’t mean you have to get stuck in a corner like those Drupal-dependent people. For example:

  1. You could use something like Redis or Memcache (maybe via Elasticache); those things are fast.

  2. You could use a key/value optimized NoSQL database like DynamoDB or Cassandra or Mongo.

  3. You could use something that supports GraphQL (like AppSync), a protocol specifically designed to turn a flurry of RESTful fetches into a single optimized HTTP round trip.

  4. You could package up your events with a whole lot more context so that the code processing them doesn’t have to do much work to get its bearings. The SQS-to-Lambda capability we announced earlier this year is getting a whole lot of use, and I bet most of those reader functions start up pretty damn quick.

Latency and affinity

There’s been this widely-held belief for years that the only way to get good latency in handling events or requests is to have state in memory. Thus we have things like session affinity and “sticky sessions” in conventional Web-facing apps, where you try to route strongly-related queries to the same server in a load-balanced fleet.

This can help with latency (we’ve used it in AWS services), but comes with its own set of problems. Most obviously, what happens when you lose that host, either because it fails or because you need to bounce it to patch the OS? First, you have to notice that it’s gone (harder than you’d think to do reliably), then you have to adjust the affinity routing, then you have to refresh the context in the replacement server. And what happens when you lose a whole Availability Zone, say a third of your fleet?

If you can possibly figure out a way to do state hydration fast, then you don’t have to have those session affinity struggles; just spray your requests or events across your fleet, trying to stress all the hosts evenly (still nontrivial, but tractable) and have a much simpler management task.

And once you’ve done that, you can probably just go serverless, let Lambda handle smoothing out the load, and don’t write any code that isn’t pure value-adding application logic.

How to talk about it

To start with, don’t just say “I need 120ms.” Try something more like “This has to be in Python, the data’s in Cassandra, and I need the P50 down under a fifth of a second, except I can tolerate 5-second latency if it doesn’t happen more than once an hour.” And in most mainstream applications, you should be able to get there with serverless. If you plan for it.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconSF-3: Serverless Everything? 11 Dec 2018, 3:00 pm

Sometimes we fans get a little over-excited and declaim that everything should be serverless. After all, we’re pretty convinced that owning data centers and computers is becoming a thing of the past. Well then, how could configuring your own hosts and paying for them even when they’re not working ever be a good idea? Let’s try to be moderate and pragmatic: Serverless, where possible.

[This is part of the Serverlessness series.]

But what does “Where possible” mean? Here’s a nice concrete example from inside AWS: the Amazon MQ service, which is a managed version of the excellent Apache ActiveMQ open-source message broker.

How Amazon MQ works

To make this usable by AWS customers, we had to write a bunch of software to create, deploy, configure, start, stop, and delete message brokers. In this sort of scenario, ActiveMQ itself is called the “data plane” and the management software we wrote is called the “control plane”. The control plane’s APIs are RESTful and, in Amazon MQ, its implementation is entirely serverless, based on Lambda, API Gateway, and DynamoDB.

I’m pretty convinced, and pretty sure this belief is shared widely inside AWS, that for this sort of control-plane stuff, serverless is the right way to go, and any other way is probably a wrong way. Amazon MQ is a popular service, but how often do you need to wind up a new broker, or reconfigure one? It’d be just nuts to have old-school servers sitting there humming away all the time just waiting for someone to do that. Environmentally nuts and economically nuts. So, don’t do that.

The data plane, ActiveMQ, is a big Java program that you run on an EC2 instance the control plane sets up for you. Client programs connect to it by nailing up TCP/IP connections and shooting bytes back and forth. MQ and its clients take care of the message framing with a variety of protocols: STOMP, MQTT, AMQP, and JMS/OpenWire. This is obviously not RESTful.

Because of the permanent connection (unlike an HTTP API that sets them up and tears them down for each request) the messaging latency can be really, really low. Of course, the downside of that that the scaling is limited to whatever a single broker instance can handle.

Anyhow, the data plane is absolutely not serverless. Is this OK? I’m going to say that it’s just fine. Among other things, at the moment we don’t have a good serverless way to simultaneously use nailed-up TCP/IP connections and dispatch serverless functions; you can imagine such a thing, but we don’t have it now.

Because it’s not serverless its scalability is limited, and you’re going to be paying for it to turn electricity into heat 24/7/365 whether you’re doing any messaging or not. But for a lot of customers who just want somebody else to manage their MQ instances, or who have to integrate with legacy apps that talk JMS or AMQP or whatever, it’s still super useful.

Global weather

Let me give you another example. I was recently talking to a large public-sector weather service that maintains a model of the global weather picture. This needs to be updated all the time, and the update needs to complete in 43 minutes. The actual software is a vast, sprawling thing built up over decades and substantially in FORTRAN. To get acceptable performance, they have to buy insanely expensive supercomputers and run them flat out.

Would serverless be a good idea? Well maybe, but they don’t know to decompose the model into small enough pieces to fit into serverless functions. “Are you looking at that?” I asked. “We’d love to,” was the answer “but anyone who can figure it out will probably get a Nobel Prize. Want to try?”

I think that, since weather forecasting is pretty important to civic well-being, we can all agree that this is another scenario where being serverful is OK. (Well, until someone wins that Nobel Prize.)

Back to the mainstream

Now, let’s stipulate that most customers are writing neither real-time message brokers nor models of the global atmosphere. Most are running something with a Web front end and a database back-end and straightforward application logic in between. These days, it’d be unsurprising if there were events streaming in from dumb machines or user clickstreams or whatever. Why shouldn’t all of this be serverless? I think it usually should be, but there are things that reasonable people worry about and deserve consideration. That’s next.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconServerlessness 9 Dec 2018, 3:00 pm

I work in AWS’s Serverless group, and in the process of pulling together my presentation at re:Invent, discovered that I have a lot of opinions on the subject and, while they may well be wrong, are at least well-informed. You can watch that YouTube, but who’s got an hour to spare? And anyhow, blogging’s really my favorite medium, so here we go. If I tried to glom them all together into one mega-essay it’d be brutally long, so let’s go short-form.

The Serverless Fragments

“Serverless Fragment” has five syllables and ongoing doesn’t have that much room at the top of the page for the title, so let’s say “SF”.

  1. SF 1: What is serverless? Tl;dr: It’s when you don’t have to reserve capacity before you start. But it’s not a binary condition.

  2. SF 2: Why serverless? Tl;dr: Frugality, Security, Elasticity. That part’s a no-brainer, but will you also get better software?

  3. SF 3: Serverless everything? Tl;dr: Nope, serverless where possible. To start with, think about control planes and data planes.

  4. SF 4: Serverless latency? Tl;dr: It’s complicated. And, there are things to do about it.

  5. SF 5: Serverless bills? Tl;dr: Not always lower. But it depends how you count it.

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconJag Diary 3: What We Know 7 Jul 2018, 3:00 pm

Between June 4th, when the first wave of reviews of the New Jag hit (offically the I-PACE, what a dumb name) and the time the salesman called me saying “Time to sign the order if you want to be in the first wave”, I had to decide whether to spend a lot of money on a car I’d never seen or touched. So I paid damn close attention to those reviews. I’m a critical reader, and suspicious about the motives of product reviewers, and I think the picture that emerges is pretty clear. This post is to enumerate what I think it’s possible to know for sure about the car without having owned or even driven one. [Updated based on hands-on experience.]

I’ll throw in a bunch of links down at the bottom to reviews that I think are particularly useful.


  • The story starts in 2014, when Jag leadership decided to go all-in on a from-scratch electric model. They put an integrated development team all in one room at the University of Warwick — not exactly traditional auto-biz practice — and eventually brought the new car from nothing to market in “only” four years, which is considered very good in that industry.

  • It has two motors, one wrapped round each axle, with the space between full of battery, then the cabin perched on top. At moderate speeds, only the back wheels drive.

  • It’s almost all aluminium and, despite that, is still super-heavy (2100kg), mostly because of the battery.

  • I’m not going to recite horsepower and torque numbers that I don’t understand, but people who do understand them sound impressed.

  • I don’t understand charging issues well enough to have an intelligent opinion, but Seth Weintraub does, and his review is full of useful detail. Tl;dr: The range is competitive with other high-end electrics.

  • It doesn’t have gears as such, just buttons: P, N, R, D. The North American edition comes only with air suspension, and has a thing where you can elevate the car for a tricky driveway or rutted gravel, and it settles down automatically at high speeds. I gather the Euro model can be bought with springs.

  • Another difference: The Euro model comes with either a standard or glass roof; in the New World it’s all-glass all the time. Personally, I’d prefer a layer of metal between me and the sun, but they claim it’s sufficiently shaded and UV-impervious.

  • Electrics are super quiet inside so, if you want, the Jag will play you a spaceship-y acceleration sound that changes with the speed. Fortunately it’s optional; although one of the journos who took it out on the racetrack said he found it useful in situations where you don’t have time to look at the speedometer.

  • There’s a screen behind the steering wheel where you can display speed and charge and maps and so on. Front center, there’s a biggish (but not Tesla size) screen above for Infotainment, and a smaller one below for climate control. On the subject of climate control, the console has a couple of actual physical knobs for that.

Black interior White interior
  • It’s got a fair-size trunk at the back (the back seats fold down 60/40) and a tiny one under the front hood; someone suggested it was just big enough to carry your cat.

  • As with most electrics, you can do one-pedal driving, where easing off the accelerator goes into regeneration mode and provides enough breaking for all but exceptional circumstances.

  • You can actually take it off-road, up and down stupidly steep hills, through really deep puddles, and so on: The “LR” part of JLR is Land Rover, and that part of the company knows something about those things.

  • There’s plenty of room inside for four big adults. The person in the middle of the back seat should be on the small side.

  • Nobody has seen either Apple CarPlay or Android Auto at work, but the company claims that both will be supported. My own Jag dealer said he’d heard that they’d done the technology work were just doing licensing and payment. [Hands-on: It works fine!]

  • It has a SIM slot and over-the-air software update.

  • You can equip it with a tow-bar and bike-rack and roof-rack.

  • It’s built, not by JLR themselves, but by Magna Steyr, a contract manufacturer in Graz, Austria, that also builds the Mercedes G-Class and BMW 5 Series.

Things that are good

  • Everyone agrees that it’s a blast to drive. What’s interesting is that the most common comment was “feels just like a Tesla”. The Top Gear scribe pointed out, in a melancholy tone, that apparently all electric motors feel more or less like all others. This is a big change from the days of internal-combustion engines, which have all sorts of personality. It’s fast, maneuverable, and comfortable. [Hands-on: Oh yeah!]

  • The one-pedal driving mode takes a bit of getting used to but all the journos ended up loving it, and assuming that pretty everyone would use it all the time.

  • The seats are said to be super-comfortable. [Hands-on: Yup.]

  • It has all the bells and whistles and technology gadgets anyone could want.

  • The cabin has all sorts of storage space in bins here and there and under the back seats and so on.

  • It has more than enough range for people who drive around town and then occasionally go 200+ km for business.

Things that are not so good

  • If you’re a road warrior, Jag doesn’t have anything to compete with Tesla’s supercharger network. I’ve started poking around PlugShare and ChargePoint and so on, and I think you could manage road trips, but it’s not going to be as slick as with a Tesla. Perhaps this situation will improve?

    Me, I have a carport on the back alley and I’ll put in a charger and I should be fine.

  • The infotainment system is slow and laggy, and some important settings are deeply nested into the menus. Android Auto is my answer to that. [Hands-on: The lag is not really an irritant once you get into the system’s rhythm but yeah, the menus could be better-organized.]

  • The storage space isn’t that well-organized and it’s not obvious where to stow the charging cables.

  • The fifth person in the car is going to be kind of cramped.

  • Visibility out the back window is lousy, with big rear posts getting in the way. [Hands-on: The window is tiny, nearly horizontal, and shaded, so the view is ludicrously bad. There’s a back-up camera to help with parking though.]

  • The brake pedal tries to combine regenerative and friction braking and as a result is said to feel soft and weird. [Hands-on: Don’t know what was bothering them, my leg likes it fine.]

  • The air-suspension ride has been reported as feeling a bit jittery and unstable at low/moderate speeds. [Hands-on: Nope, but I’ve found the regen braking can be a bit quease-inducing for passengers while driving in traffic.]

  • The center console crowds the driver’s leg a bit; more of a problem in left-hand drive vehicles, obviously. [Hands-on: Not at all, there’s plenty of room for my legs, and I’m 5’11".]

My conclusion

What happened was, when the first buzz of publicity hit in March I was interested enough to drop by Vancouver Jaguar and talk to Caleb Kwok, the sales manager. He’s a plausible guy, responsive to email, and anyhow, he convinced me to put down a refundable deposit, buying me a place near the front of the line at the time actual orders would open up. Which turned out to be last week.

By which time I’d read all the material summarized in this piece. On balance, I liked what I heard; the pluses were pretty big and none of the minuses bothered me that much. Remember, the longest trip I normally take is 230km to Seattle, where I park for a couple of days then drive home.

So I signed on the dotted line, and my deposit is no longer refundable.

The big worry, of course, is reliability and manufacturing quality. Jaguar, at various times in its history, has had a miserable reputation. Of one famous model, they used to say “It’s a great car, so buy two, because one will always be in the shop.” It’s worse than that; Jag at one point had a particularly stinky track record around electrical systems.

But there are stats suggesting Jag’s doing better in recent years. And then there’s the fact that it’s being built in a plant where they also make Mercedes and BMW. Granted, I’m taking a chance here.

Helpful reviews

Blinklist Blogmarks Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Page processed in 0.753 seconds.

Powered by SimplePie 1.0.1, Build 20070719221955. Run the SimplePie Compatibility Test. SimplePie is © 2004–2019, Ryan Parman and Geoffrey Sneddon, and licensed under the BSD License.