Onomatopoeia for Books (The Twitter Book by O’Reilly and Milstein)

An onomatopoeia is a word that sounds like what it means—for example, saying “hiccup” sounds like a hiccup. In the same vein, every once in a while I find a book that looks and feels like what it says. For example, Scott McCloud’s Understanding Comics is a comic book that explains the techniques behind comic books.

The Twitter Book by Tim O’Reilly and Sarah Milstein is another example. It’s a smart, friendly, and Twitteresque introduction to Twitter.

Wider than tall, the book presents a topic on each two-page spread: pictures on the left, text on the right. This bite-sizing of concepts and advice reflects the feel of Twitter without being gimmicky.

Although the book is about Twitter, it’s addressed to you. An example: “Twitter gives you two superhero strengths everyone wants: the power to read people’s thoughts and the ability to overhear conversations as if you were a fly on the wall.” If that sounds too breezy, ask yourself how much earnestness you really want from a Twitter how-to book.

Along with making the conceptual sell for Twitter’s goodness, the authors recommend specific things to do with Twitter and, more important, how to do them well. Of course, the Web is rife with Twitter how-to material, free for the clicking. With The Twitter Book you’re paying for a succinct version of the facts plus authoritative advice. It’s like learning the rules of the road from a driving instructor who also knows the coolest places to take your car.

Not to mention, you get that underlying—but not cloying—Twitterness of the book: The look, feel, and tone creatively and satisfyingly reflect the topic, as sure as “tweet” is an onomatopoeia. ; )

Well done, @timoreilly and @SarahM.

Review: Samantha Power’s Chasing the Flame

Samantha Power’s book Chasing the Flame is about an extraordinary man’s humanitarian service amid conflicts in Lebanon, Cambodia, Rwanda, Kosovo, East Timor, and Iraq. A Brazilian and career United Nations officer, Sergio Vieira de Mello was, in the words of a U.S. diplomat, “the personification of what the UN could be and should be but rarely is.”

Vieira de Mello lived to be in the field, mixing it up with peasants, soldiers, jungle rebels, and presidents alike. He had a knack for charming them all. He took risks to get things done. He was propelled by ideals but could be ruthlessly pragmatic. He was resilient against setbacks, adapting to whatever worked when theory and practice collided. He made mistakes, then learned from them.

Here is a sampling of Vieira de Mello’s assignments:

• You need to safely repatriate 400,000 Cambodians back into, among other places, land controlled by those responsible for The Killing Fields.
• You need to provide humanitarian relief in the former Yugoslavia while multiple sides are at war, and your own forces barely can defend themselves, much less the population.
• You need to create the government of East Timor—including the political system that elects the government—from the smoldering ruins of a brutal occupation.

These kinds of challenges, which no country would touch individually, are what UN humanitarian operations are for. However, UN actions are largely constrained by the funding and politics of donor countries. As Power quotes former Secretary-General Kofi Annan:

Our system for launching operations has sometimes been compared to a volunteer fire department. But that description is far too generous. Every time there is a fire, we must first find the fire engines and the funds to run them before we can start dousing the flames.

Even Annan’s correction is generous. It implies that resources are the only issue. He omitted the part about needing to get consensus from UN Security Council countries about how to fight the fire. That consensus was often lacking, so Vieira de Mello’s marching orders often came with a straightjacket that all but assured failure. Everyone would then blame the UN for being ineffective.

That said, the UN caused many of its own problems. Vieira de Mello was constantly at war with the UN bureaucracy, which had many of the foibles of “big government” without actually being a government. For example, Vieira de Mello could only use his budget for UN personnel and equipment; he could not pay a country’s civil servants or bankroll the repair of an electric grid. As Power notes, “In the economic sphere, these rules ensured that the large UN peacekeeping and political mission managed to distort local economies without being able to contribute to development.”

But for all the UN’s problems, Vieira de Mello loved the organization for its mission. He saw the UN as the main vehicle for nations to collectively do the right thing. Even if that happened infrequently and inefficiently, what exactly was the alternative when masses of people were dispossessed and dying?

Vieira de Mello was widely regarded as a future UN Secretary-General. That destiny died in 2003 when a truck bomb detonated into UN Iraq headquarters, killing Vieira de Mello and 21 others—a final tragedy in a life that swam upstream against torrents of human tragedy. He was 55 years old.

With Chasing the Flame, Power delivers a compelling biography, braided with deft analyses of what worked, what didn’t, and what can be learned from Vieira de Mello’s efforts on behalf of humanity.

Negative-Space Pumpkin

We were visiting Newport, RI, this weekend and stumbled on the 7th Annual Ballard Park Pumpkin Tour. Imagine a winding, wooded trail with jack-o-lanterns perched in trees, on stumps, along the ground, in clusters, everywhere. In total more than a thousand pumpkins loomed amid the gawking parade of people.

For creative design, my favorite was this negative-space pumpkin:

Below are a few more examples of the variety and quality on display. What a great job by the event’s organizers and the Newport community!

More pictures are on this page, where the main image changes every few seconds.

Our Greatest Animal Menace?

A new site, Book of Odds, has an entertaining piece about the relative likelihood of being killed by a shark versus being killed by a vending machine:

The odds a person will die from a vending machine accident in a year are 1 in 112,000,000, while the odds that a person will die from a shark attack in a year are 1 in 251,800,000. One can say with confidence that while vending machines crush an average of 2 to 3 unfortunate Americans every year, the number of recorded US shark fatalities is typically nil.

The author goes on to remind the reader that, despite these numbers, sharks are physically more dangerous than vending machines. So if people abused sharks as often as they abused vending machines, those numbers would be very different.

For comparison’s sake, I consulted the Center for Disease Control’s Compressed Mortality File and found that in 2006:

• Eight Americans died from “contact with venomous snakes and lizards.”
• 32 Americans died from “bitten or struck by dog.”
• 72 Americans died from “bitten or struck by other mammal.”

Thus, by the aggregate mortality numbers, our fellow mammals, especially “man’s best friend,” are our greatest menace (excluding ourselves) in the animal kingdom.

The Origin of Wealth by Eric Beinhocker

The best parts of Eric Beinhocker’s The Origin of Wealth are (1) an alternate history of economics that argues the foundation is cracking, and (2) a wide-ranging tour of new ideas that Beinhocker calls Complexity Economics. Here is his summary of the old versus the new.

If that table rings your bell, then The Origin of Wealth will be a carillon choir’s worth of bell-ringing for you. At many points, I found myself needing to put the book down to digest the richness of the ideas. (That’s a good thing.)

Less successful is Beinhocker’s attempt to unify the book around a theory of wealth creation—in brief: wealth comes from innovation, which in turn comes from evolutionary processes operating in an economy like Darwinian evolution operates in a biological ecosystem. While there’s a lot to like about this theory, it’s a subset of the Complexity Economics story. As such, it doesn’t really unify the book as much as it confounds itself with other, non-evolutionary aspects of Complexity Economics. Also, Beinhocker is so expansive in exploring Complexity Economics’ implications that he sometimes comes across as throwing stuff at the wall to see what sticks, as opposed to telling us what is sticking.

As a result, the totality of this 450-page book is less than the sum of its parts. However, so many of the parts are excellent that The Origin of Wealth is well worth recommending to those with an inclination toward the subject matter.

Here’s the link to the book at Amazon.

A Quick Spin with Google App Engine

Google App Engine (GAE) lets you build a Web app on your local machine, then deploy it to Google’s infrastructure. I played with GAE this weekend and was impressed.

The set-up and “hello world” experience was fast and painless. The tutorial and example code were excellent. Less than 30 minutes from downloading the software development kit, I felt like I understood the basics and could start doing my own stuff. It’s a great feeling to learn that quickly. Credit goes to the GAE developers and documenters, who went the extra mile to make things easy for new users like me. Thank you.

For the sake of doing something simple but practical, I wrote an app that automatically keeps my Twitter tweets backed up in the Google cloud. It uses the Twitter API to get my tweets, then stores them in GAE’s datastore so they can be queried and displayed by various fields. As examples of the possible outputs, I created a page that displays just the tweets’ content, and another that dumps every field of every tweet as tab-delimited text.

I got all the above done and deployed in three hours. The app is now running on Google’s infrastructure, checking for new tweets every 30 minutes and storing what it finds.

So, from my brief experience, a small Web app can be developed and deployed rapidly on GAE. Compared to other cloud platforms, which give you more flexibility at the cost of more configuration and administration, GAE seems particularly well suited to quick, small solutions. I suspect that the bigger your ambitions become, the more GAE’s simplifying aspects will become obstacles. However, depending on what you’re trying to do, there may be a lot of headroom until bigger becomes a problem. (In this context, bigger means more functionality, code, and dependencies, not more traffic. For the latter, if you do things the GAE way, your app will benefit from Google’s infrastructure and should handle as much traffic as you can attract.)

For the technically inclined, here are some additional notes:

I used GAE’s sandboxed version of Python. GAE has an equivalent for Java and other languages that run on the Java Virtual Machine.

Instead of having access to a file system or relational database, you use GAE’s datastore for the equivalent of local storage. At first, it feels like an object-relational mapping, where you define a Python class for each kind of entity you want to store. For example, you might define a class Person, with instance variables name, birthdate, and so on. If you create a Web form that allows someone to submit his or her name, birthdate, and other information, your app would take the input and instantiate a Person object, p. Storing it would be as simple as p.put().

However, GAE’s datastore is not relational, so if you go beyond retrieving all objects of type Person, you’ll need to learn some new ways of doing SQLish things. If I had gone deeper here, I’m sure I would have encountered a steeper part of the GAE learning curve. Considering this aspect of GAE is furthest from what most programmers know, it’s an area where the documentation and examples could benefit from being more extensive.

About the development process: You develop on your local machine, using the SDK’s app server and a simulated, local version of the datastore. When you make code changes, you just hit the URL you changed, and the new version will be called. When something breaks, you get prolific debugging info back.

Once you’ve deployed an app, the Web-based management dashboard is surprisingly good, especially the logging UI.

I only saw one inconsistency between the development version of my app running locally on my computer versus the deployed version on Google’s servers: The deployed version’s Twitter API requests were often denied by the Twitter server. This was not caused by the GAE technology. Rather, it was due to other GAE apps on the same IP(s) as my app, pounding Twitter hard enough to cause Twitter’s servers to rate-limit said IP(s). It was guilt by association, cloud-computing-style.

In theory, I could have authenticated my requests to Twitter, thus avoiding the IP limit. In practice, authenticating my requests would have required either including my Twitter password with requests (distastefully insecure) or implementing oAuth (distastefully complex for this little project). So, in the name of “good enough for now,” I decided to let some requests be denied. I found that if the script checked Twitter every 30 minutes, it succeeded often enough to stay reasonably current with any changes throughout the day.

The Arbitrary Precision of a Close Finish

Michael Phelps won his seventh gold medal at the 2008 Olympic Games by one-hundredth of a second—a fraction of an eye-blink, measurable only with precision instruments. In terms of distance, Phelps won by two millimeters.

Writing in Vanity Fair, Steve King uses this context when quoting an unnamed expert in the timing of sporting events:

“We take it for granted that the swimmers are all swimming the same length in the race, but they’re not. The very best construction specs will say, ‘This pool is 50 metres plus or minus one quarter of an inch’… Our ability to build things isn’t nearly as good as our ability to time them.” Consider the implications when Michael Phelps’s seventh gold medal in 2008 was won by two millimetres over a 100-metre race.

[from “End Game” in Vanity Fair, via @pkedrosky]