D B General

I don't want you to get too jealous, but this baby's moored about 50 yards from my office right now: D.B. General: 700 Ton Floating Crane

The D B General is no ordinary crane, having been recently used in the Bay Bridge construction project, as well as other local large-scale projects.

You can tell it's a special crane, because it's listed in Wild Crane Photos, no. 16:

This is the DB General picking a Manitowoc 222 from a barge and setting in on the deck of the new Benicia Bridge in California. The General is a Clyde 52

That's nothing for the D B General, though, once known as The largest derrick barge on the West Coast

It was a surreal scene for onlookers standing on the shore at Shine Tidelands State Park, many who waited all day to see the lift that, by engineering standards, was no big deal considering the DB General's 700-ton lift capacity.

Once the 280-foot-long, 70-foot-wide and 40-foot-tall truss was in the air -- almost a million pounds of steel hanging there like a toy -- tugs gently pulled the DB General directly backward. Two other tugs then nudged another barge into perfect alignment under the truss.

Although the General was once the largest barge crane on the West Coast, it is now of course dwarfed by the Left Coast Lifter.

Here at home, we didn't need the Left Coast Lifter today; the trusty D B General is onsite to complete the task of raising the sunken tugboat "Respect".

Where'd You Go, Bernadette? : a very short review

Maria Semple's Where'd You Go, Bernadette? is sort of the fiction equivalent of Beaujolais Noveau, Strawberries at Wimbledon, or a bouquet of roses: it is not meant to be placed on a shelf, stored for later enjoyment; it needs to be consumed and enjoyed now, or it will spoil.

This is not to say that Where'd You Go, Bernadette is an inferior pleasure. It is a comic delight, bubbly and energetic, vivid and captivating. It's just to note that a book which is so thoroughly stylish and au courant runs the risk of being simply baffling to readers just a few years later.

After all, Semple weaves references such as Daniel's Broiler, TED talks, the Microsoft Connector, the Tuba Man, and even Cliff Mass, the blogging weatherman into the book, which is told primarily as a series of emails, tweets, and blog posts.

But underneath all the pop culture references is an engaging story populated with a delightful cast of characters, told with a light touch, a wink, and a smile.

I suspect this story will particularly appeal to the bit jockeys of the world, those who can instantly appreciate a passage such as

Mr. Branch's administrator knocked and asked if Mr. Branch had reviewed a code fix. Mr. Branch looked at his cell phone and shuddered. Apparently, forty-five emails had come in while we were talking. He said, "If Bernadette doesn't kill me, Reply All will." He scrolled through the emails and barked some code talk about submitting a change list, which his administrator furiously copied down before dashing out.

But even if you've never submitted a change list in your life, I think you'll enjoy Where'd You Go, Bernadette?. The holidays are busy times for everyone, but if you have a bit of downtime, and you're looking for something to brighten up your afternoon, and drive away those winter grays, give Where'd You Go, Bernadette? a try.

Europa Universalis IV: a very short review

Have you played Europa Universalis IV?

No?

Well, let me tell you how it's going to go.

First, you'll download the game and install it. When you start it up, you'll gape at the beauty of the screen.

You'll work your way through the tutorials, getting an understanding for how the interface works, and what the various screens and dialogs are trying to tell you.

All too soon, you'll be finished with the tutorial, and you'll be invited to play a game. "Pick a country!", the computer says, "and let's get going."

So you do.

And you are immediately lost, baffled, overwhelmed.

But you'll persevere. You'll take some time to read the manual, which Paradox have so thoughtfully made available for all.

You'll spend time reading about the game on the Internet, considering the various advice, strategies, and tips that people discuss.

And you'll keep trying to play.

After a while, you'll learn how to pause the game, and how to slow the game speed way down, so that you can see what's happening.

And at some point, when you least expect it, you'll find that you suddenly can't stop thinking about the game.

"France needs to ally with Aragon," you'll think to yourself, "so what would make that happen?" Should you investigate a Royal Marriage? Send a diplomat to improve relations? Offer a bribe? Eventually, you learn enough about the game to discern that Aragon's reluctance is due to the active war that France is prosecuting with England.

And so you wonder if sueing for peace with England, to your north, will actually aid in relations elsewhere on the continent? How will you manage to unite the various dukedoms, and form a unified France?

Meanwhile, you've got troops to lead, an economy to run, diplomatic enquiries from all fronts, and a trading empire to build.

Each time you play, you'll realize how crude your previous attempts were, and how horribly you've mis-managed affairs, and so you'll start anew again, and again, and again.

Before you know it, Steam will tell you that you've been playing a total of 74 hours so far, and you still feel like such a rank amateur.

Will you enjoy it? I don't know. This is a vast and complex game, like nothing you've played before.

But if you think you might enjoy it, I encourage you to give it a try, as the game is truly a work of art, and enormously repays the time you devote to it.

Some good long-form writing

I'm not sure if it's because the days are cold and dark, so everyone is staying inside and reading and writing, or because there is some sort of harmonic convergence, or perhaps I just got lucky, but I've been reading some very interesting longer-form CS writing recently.

Here's a few examples:

• Carlos Bueno: The Mature Optimization Handbook

  Bueno's e-book is a clear, compact, well-organized treatment of performance optimization. The title is a riff on Don Knuth's 40 year old tongue in cheek sound bite, which sadly is all that many computer professionals ever learn about performance observation.

  If you want to go further, start with Bueno's superb book: he points you in the right direction, saves you from several basic pitfalls, arms you with a collection of useful tools and techniques, and points at resources to help you move further once you've grown comfortable with the basics. I particularly like the fact that Bueno links to some of Richard Cook's, as I think Cook has some fascinating ideas and deserves more attention.

  And I just love this hard-won advice:

  Your instrumentation should cover the important use cases in production. Make all the measurements you want in the lab, but nothing substitutes continuous real-world data. Think about it this way: optimizing based on measurements you take in a lab environment is itself a falsifiable theory, ie, that lab conditions are sufficiently similar to production. The only way to test that theory is to collect measurements in production too.

• Michael Nielsen: How the Bitcoin protocol actually works.

  I've read, oh, approximately 8 trillion articles about Bitcoin; these days, writing a "here, let me explain Bitcoin to you" article seems to be one of the rites of passage.

  Most of them are rubbish.

  But Nielsen's exposition is clear, nicely paced, compactly worded without being dense, and somehow hits just the right level of explanation for me. As I read it, I was reminded of another great document that, while wildly different, is still very similar in approach and technique: Bill Bryant's Designing an Authentication System: a Dialogue in Four Scenes. In both documents, the approach is to start with a solution that seems like it should work, identify the problems with that solution, and evolve from there:

  My strategy in the post is to build Bitcoin up in stages. I’ll begin by explaining a very simple digital currency, based on ideas that are almost obvious. We’ll call that currency Infocoin, to distinguish it from Bitcoin. Of course, our first version of Infocoin will have many deficiencies, and so we’ll go through several iterations of Infocoin, with each iteration introducing just one or two simple new ideas. After several such iterations, we’ll arrive at the full Bitcoin protocol. We will have reinvented Bitcoin!

  This strategy is slower than if I explained the entire Bitcoin protocol in one shot. But while you can understand the mechanics of Bitcoin through such a one-shot explanation, it would be difficult to understand why Bitcoin is designed the way it is. The advantage of the slower iterative explanation is that it gives us a much sharper understanding of each element of Bitcoin.

• Ralph Langner: To Kill a Centrifuge : A Technical Analysis of What Stuxnet’s Creators Tried to Achieve.

  Langer has devoted 6 years of his life to studying, analyzing, deconstructing, and, most importantly, explaining Stuxnet, the most sophisticated and fascinating piece of malware yet unleashed upon the world.

  Although Langer is not the most natural of writers (in his defense, I suspect English was not his first language), he more than makes up for his dry prose with the amazing depth of detail and knowledge that he includes in this work.

  The attack continues until the attackers decide that enough is enough, based on monitoring centrifuge status, most likely vibration sensors, which suggests a mission abort before the matter hits the fan. If the idea was catastrophic destruction, one would simply have to sit and wait. But causing a solidification of process gas would have resulted in simultaneous destruction of hundreds of centrifuges per infected controller. While at first glance this may sound like a goal worthwhile achieving, it would also have blown cover since its cause would have been detected fairly easily by Iranian engineers in post mortem analysis. The implementation of the attack with its extremely close monitoring of pressures and centrifuge status suggests that the attackers instead took great care to avoid catastrophic damage. The intent of the overpressure attack was more likely to increase rotor stress, thereby causing rotors to break early – but not necessarily during the attack run.

  If there is something you want to know about Stuxnet, you will find it here.

  Much of what Langner writes remains controversial, and certainly this story is far from complete. But Langner has done the world a tremendous service by sharing his deep and broad knowledge of Stuxnet widely and openly. Read it. Think about it. Understand just that little bit more about the strange new world we occupy.

So if, wherever you should be, the days are short and the nights are cold, pull up a comfy chair, grab your reading device, and sink your brain into some deep thoughts. Enjoy!

Inoreader looks like a good alternative to Feedly

I've been using Feedly for six months, since Google Reader vanished, and overall I'm quite happy with Feedly.

For some reason, the other day, I decided to give Inoreader a try: http://inoreader.com.

After only a little bit of use, my early reaction is that Inoreader is quite good, and is a worthy alternative to Feedly.

It's nice to have two solid alternatives out there.

World Cup 2014: may the complaining begin!

The draw is complete!

Here's how the groups shake out:

• Group A:
  • Brazil
  • Croatia
  • Mexico
  • Cameroon
• Group B:
  • Spain
  • Netherlands
  • Chile
  • Australia
• Group C:
  • Colombia
  • Greece
  • Ivory Coast
  • Japan
• Group D:
  • Uruguay
  • Costa Rica
  • England
  • Italy
• Group E:
  • Switzerland
  • Ecuador
  • France
  • Honduras
• Group F:
  • Argentina
  • Bosnia-Herzegovina
  • Iran
  • Nigeria
• Group G:
  • Germany
  • Ghana
  • United States
  • Portugal
• Group H:
  • Belgium
  • Russia
  • Algeria
  • South Korea

I'm no expert, but it seems to me that Brazil, Argentina, and Columbia must count themselves pleased, while Germany, Spain, and Uruguay have to steel themselves for stiff competition. Switzerland and Belgium fell somewhere in the middle, I think.

Both England and the U.S. were destined to have hard schedules, and certainly both now have their work cut out for them.

Can't wait for next summer!

Masters of Doom: a very short review

Once again, I'm late to the party, in this case an entire decade late, having only recently stumbled across Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture.

Masters of Doom is the well-written and engaging story of two guys named John (John Carmack and John Romero), who came together and in a few brief and intense months completely re-invented the entire computer gaming world, inspiring all sorts of critical innovations along the way, and then burst apart, in a collision event that captivated the (relatively) large world centered around them.

I knew much of the outlines of the story of Carmack and Romero, but there were just oodles and oodles of details that I had never been aware of, and Masters of Doom was full of surprises and things that fascinated me:

• I had absolutely no idea that Carmack and Romero first met and started working together in Shreveport, Louisiana. Masters of Doom is polite and generous about this, but, really: Shreveport? Even in 1989 there were identifiable centers of software activity: Boston; San Francisco; North Carolina's Research Triangle; Redmond, Washington. But Shreveport? How unlikely it was that even one of the Johns would end up in Shreveport, and how spectacularly unlikely it was that the two of them ended up there at the same time. The description of this completely accidental happenstance was, by itself, worth reading the book for. Of course, once they all got together, it wasn't long before they created the classic hacker's house, in a way that could happen anywhere, whether it was in Shreveport, Louisiana or on the face of the moon:

  Carmack, Lane, Jay, and an Apple II programmer at Softdisk named Jason Blochowiak had scored an enviable coup not long before when they found a four-bedroom house for rent right along these shores. Jay had bought a cheap boat, which they docked there and used for frequent outings of kneeboarding and skiing. In the large backyard was a swimming pool and a barbecue, with which Jay, a cooking enthusiast, grilled up Flintstonian slabs of ribs. The house itself had plenty of windows looking out on the scene, a large living room, even a big tiled bathroom with a deep earth-tone-tiled Jacuzzi tub. Jay had installed a beer keg in the fridge. It was a perfect place to make games.

• I never knew the origin of the name "id Software". I thought it was some sort of psychology reference, but in fact it was a shortened and merged amalgam of the company originally formed by John Romero and Lane Roathe:

  While in New Hampshire, the two even decided to merge their one-man-band companies -- Romero's Capitol Ideas and Lane's Blue Mountain Micro -- under one roof as Ideas from the Deep.

  ...

  When the guys christened their company, they shortened the Ideas from the Deep initialism and simply called themselves id, for "in demand". They also didn't mind that, as Tom pointed out, id has another meaning: "the part of the brain that behaves by the pleasure principle."

• I was fascinated by the description of the special synergy that Romero and Carmack found, each one's strengths complementing the other's. You can't plan for this sort of thing; you can't cause it to be; it just happens, or it doesn't.

  Romero and Carmack were now in a perfect groove, with Carmack improving the new Keen engine -- the code that made the graphics -- while Romero worked on the editor and tools -- the software used to create the game elements. Nothing could distract them.

  ...

  Carmack and Romero had developed another aspect of their collaboration. Though Carmack was gifted at creating game graphics, he had little interest in keeping up with the gaming world. He was never a player, really, he only made the games, just as he was the Dungeon Master but not a player of D&D. Romero, by contrast, kept up with everything, all the new games and developers.

  ...

  Romero immediately saw the potential in Carmack's technology, potential that Carmack was, by his own admission, not capable of envisioning himself. And because Romero was a programmer, he could speak to Carmack in a language he understood, translating his own artistic vision ino the code Carmack would employ to help bring it to life.

  ...

  He played around with rooms that flashed strobe light, with walls that soared and receded at different heights. Every decision he made was based on how he could best show off Carmack's technology. Carmack couldn't have been happier; what more could someone want, after all, than to be both appreciated and celebrated? Romero was just as energized; with Carmack's innovations, he too could reach new heights.

• I loved the bit of back-story about how Carmack and Romero found themselves inventing the approach of having an extensible gaming engine, with level editing tools that allowed others to create new levels and build entire new games:

  The Right Thing was programming Doom in such a way that willing players could more easily create something like this: StarDoom, a modification, or mod, of their original game.

  ...

  For Doom, Carmack organized the data so players could replace sound and graphics in a nondestructive manner. He created a subsystem that separated the media data, called WADs (an acronym suggested by Tom Hall, it stood for Where's All the Data?), from the main program. Every time someone booted up the game, the program would look for the WAD file of sounds and images to load in. This way, someone could simply point the main program to a different WAD without damaging the original contents. Carmack would also upload the source code for the Doom level-editing and utilities program so that the hackers could have the proper tools with which to create new stuff for the game.

• The best, and most important, part of the book, in my opinion, is the long and detailed retelling of the split of the Johns, as the intense worldwide pressure to follow-up Doom with Quake drove immense tension between them, culminating in the days following the release of Quake to the world.

  The chasm between Carmack and Romero was too wide. Both of them had their veiws of what it meant to make games and how games should be made. Carmack thought Romero had lost touch with being a programmer. Romero thought Carmack had lost touch as a gamer. Carmack wanted to stay small, Romero wanted to get big. The two visions that had once forged this company were irreparably tearing it apart.

There are many other fine parts to this book. I was amazed how the hours just flew by, reading about all the vivid personalities, wild escapades, and spurts of undeniably brilliant creativity.

Perhaps surprisingly, the world of software engineering has been fairly free from the "celebrity biography" genre of reporting. Most of the external coverage of the software industry has focused on the CEOs and entrepeneurs (Bill Gates, Larry Ellison, Michael Dell, Steve Jobs, etc.). I suppose these people are interestnig, although to me their stories always feel dull and uninteresting.

And when there is a book about the people in the trenches, it often involves coverage of an entire project, built by a team, like Tracy Kidder's The Soul of A New Machine, or Katie Hafner's Where Wizards Stay Up Late: The Origins Of The Internet, or Pascal Zachary's Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft, or Andy Hertzfeld's Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, or any of a number of Steven Levy's books.

I think there is an important reason for this: nearly all world-changing software isn't written by a single person, it's written by a team of people, working together, bringing all sorts of different talents, personalities, and approaches to the project.

Things were different 50 years ago, when you could be Tony Hoare, and with a single burst of inspiration completely alter an entire area of the industry; nowadays, however, things are rather different: GTA 5 dev team size more than 1000, manpower dependent on game detail.

They were casually talking about how a large team is required in the range of 1000 to create games with minute details, and when the question popped up about GTA 5 team’s size, Benzies revealed that it’s much, much more than 1000.

Yes, you read that right: more than 1000 people worked together on GTA V. According to Masters of Doom, the Wolfenstein 3D team was rather smaller:

They had finally fired Jason, narrowing the group to Carmack, Romero, Adrian, and Tom.

Perhaps there's no going back to the days when Carmack and Romero could sit side-by-side in a single room, building breakthrough games and tools like never before.

But just because things are different now, doesn't mean they are worse. I wasn't programming computers in Tony Hoare's day, but after 3 1/2 decades of programming, I've seen lots of approaches, lots of techniques, and lots of personalities.

I've been part of small teams, and part of immense efforts. I've seen solitary geniuses, and engaging, extroverted, and inspirational team builders.

And it's all great.

May there be many more years of programming ahead of us all.

And may there be more books like Masters of Doom, to share the excitement, thrills, and drama with us all.