Here’s a screen capture of the MobileMe “Find my iPhone” page:

The fun starts around 4 mins in.

The key to how any protein works is its three-dimensional shape, determined by all the ways its atoms interact. Trying to push two atoms closer when they want to repel is like holding magnets together when they’re oriented the wrong way. You can force them, but nature prefers configurations that follow the path of least resistance. In a simple molecule, that path is pretty clear: Water—H₂O—is hydrogen-oxygen-hydrogen balanced perfectly in a V-shape at a 104.4-degree angle. This push and pull is inevitable. Physics is destiny.

The Challenge
The online game Foldit is designed to reveal the shortcuts nature uses to weave a tangle of amino acids, like the one shown here, into a protein. Players click to move pieces around until they fit.

But the bigger the molecule, the more complex these negotiations become. And proteins are colossal. Of course, there is another way to figure all this out: Shining x-rays through a crystallized lump of protein can help reveal the exact position of its folded-up atoms. But that takes time—just 50,000 protein structures have been cracked since the late 1950s, while the sequences of millions of protein-coding genes have been discovered in the past 10 years alone. To make headway in figuring out what all these proteins do, scientists need a faster approach.

Two of Baker’s PhD students, James Thompson and Robert Vernon, groggy from a sleepless night and months of relentless CASP work, finally arrived with the answer. After a brief wrestle with a laptop, they loaded their results. Of the 15 Foldit solutions that Baker submitted to CASP, seven had finished in the money—all of them folded by Poehlman and his teammates. One of their solutions even took first place. A band of gamer nonscientists had beaten the best biochemists.

Arguably, though, the real Foldit victory had come a few months earlier. The creators of the game invited the top players to Seattle, seeking their help in making the app better. Popović contacted Poehlman’s parents. The kid was shocked. ‘Aristides didn’t believe us until we showed him the email,’ his mother says. ‘The silent stare he gave us was priceless.’ Poehlman and his dad, Louis, flew into Seattle late; they played Foldit for hours in their hotel before going to bed—just like at home.

At UW’s computer lab, Popović and his grad students filmed the Poehlmans playing Foldit and interviewed them about their techniques. Louis was exacting in his analysis of how he approached each puzzle, supplying sophisticated justifications for his moves. But when they turned to Cheese and asked him how he knew the way to tweak the proteins—for example, by orienting hydrophobic sidechains toward the protein core—he shrugged and said, ‘It just looks right.’

And that is exactly what Baker was looking for. ‘When I said early on that I hoped Foldit would help me find protein-folding prodigies, it was hopeful speculation,’ he says. ‘It’s fantastic to see it come true.’

The next CASP is two years away, and Baker doesn’t want to lose Foldit‘s momentum. He and Popović have given the players a challenge: Design a new protein. Baker’s lab is developing targets for cancer, AIDS, and Alzheimer’s, and the folders’ task is to build a small protein drug with the right shape and binding properties. This isn’t just an intellectual exercise. Baker says he will synthesize the most promising structures and test them in his lab. These proteins could actually have therapeutic value in the real world, outside the game. And if they do, the Foldit players will share the credit. It might be the first time that a computer game’s high score is a Nobel Prize.

John Bohannon (gonzo@aaas.org) is a correspondent for Science based in Vienna, Austria.

“

(Via Wired News.)

(Via Wired News.)

High speed rail has been talked about for over a generation as a “Good Thing”, but the necessary political and financial conditions have never aligned as well as now. Go Obama!

A List Apart: Articles: Fluid Grids

Fluid Grids
by ETHAN MARCOTTE

Early last year, I worked on the redesign of a rather content-heavy website. Design requirements were fairly light: the client asked us to keep the organization’s existing logo and to improve the dense typography and increase legibility. So, early on in the design process, we spent a sizable amount of time planning a well-defined grid for a library of content modules.

Over the past few years, this sort of thinking has become more common. Thanks to the advocacy of Mark Boulton, Khoi Vinh, and others, we’ve seen a resurgence of interest in the typographic grid, and how to use it on the web. And frankly, the idea’s been a smash hit: a million CSS frameworks have bloomed, with sundry tools to complement them, each built to make grid-based design even more accessible to the average designer. And why not? Afte”

The Army, the Web, and the Case for Intentional Emergence: “

Lt. Gen. Sorenson, Army CIO, at Web 2.0 Summit

I didn’t make it to the Web 2.0 Summit in San Francisco in November last year so I didn’t get to see Army CIO Gen Sorenson present this Higher Order Bit talk in person. However, I thought it was cool that the Army made the agenda and luckily someone posted the video. I finally got a chance to go through it. If you didn’t see the talk, or don’t have the 20′ish minutes to watch it now, here’s a rough summary:

- Because of security and related concerns, it takes a very long time for the Army to take advantage of new generations of technology. We tend to deploy it widely about the time it’s becoming obsolete.

- However, we are now beginning to take some advantage of Web 2.0 technologies in, for example, Stryker Brigade collaboration, battle command information sharing, and command and control.

I don’t think that slow technology adoption is caused by fundamental first principles, so I don’t think it has to remain true. But that’s a long discussion for another time. In this post I’d like to focus on Army Battle Command, Web 2.0 and Gen Sorenson’s connecting the two. Specifically I’d like to talk about lost opportunity and how the same technologies can constitute a generative platform in one setting and window dressing on a temple to determinism in another.

The lost opportunity I’m thinking of isn’t whether Army Battle Command is Web 2.0 enough or not. It’s that enterprises tend to see web technologies as an add on to whatever they already have. Plus, they tend to focus on specific technologies rather than the combination of technology, process and policy that make a collection of technologies viable as a generative platform. ‘Let’s add some Web 2.0 to this system; we’ll use REST instead of SOAP.’ But the fundamental question that the web answers isn’t whether REST is better than SOAP, but whether emergence is more likely to create innovation than enterprise planning, and the answer to that question is yes.

General Sorenson says in the video that ‘CPOF brings in Web 2.0 capability, chat, video, etc…’ and then comments on ‘graphics, chat, use of tools…’ and stuff like that to reinforce the idea that Command Post of the Future (CPOF) and the Battle Command suite it is part of has Web 2.0 attributes. Like many enterprise technologists, General Sorenson appears to be focusing on rich user experience and collaboration as the attributes that give CPOF a Web 2.0 imprimatur. While that’s not unexpected, I think it leaves most of the benefits on the table and untapped.

Putting aside for the moment that CPOF isn’t primarily delivered through a browser, a first step toward webness, the reality is that CPOF and other systems like it neither leverage accessible platforms nor contribute to them. It is a standalone (though distributed) computing system with gee whiz collaboration and VoIP. And while it offers some enterprise-style data services, it has none of the features of a generative platform. If I’m in the field I can’t readily extend it or build on it to solve different problems, modify its proprietary underpinnings to suit my local needs, or quickly incorporate its information into other applications. If an important aspect of Web 2.0 is enabling the long tail, then this isn’t Web 2.0.

I should say, this isn’t a post about web 2.0 semantics. However, it’s important to understand that the web’s power derives from its evolution as a platform. Otherwise it’s hard to see what is being missed by the military’s IT enterprise (and many other large enterprises).

From the beginning the web has been generative. It wasn’t CompuServe. With some basic skills you could add to it, change it, extend it, etc. Jonathan Zittrain, in his excellent book The Future of the Internet – and How to Stop It, reflects on why the Internet has experienced such explosive innovation. He argues that it’s the powerful combination of user-programmable personal computers, ubiquitous networking with the IP protocol, and open platforms. Today, the emergence of open source infrastructure, ubiquitous and cheap hosting for LAMP-based sites, open API’s, and the intentional harnessing of crowd wisdom has ushered in the web 2.0 era. It’s an era of high-velocity low-cost idea trying that leverages the web itself as the platform for building world changing ideas and businesses.

The Internet hosts innovation like it does because it is an unconstrained complex system where complex patterns can grow out of easy to assemble simple things. Simple things are not only permitted, but they are encouraged, facilitated, and often can be funded with a credit card.

I’ve subscribed to the notion of Gall’s Law for longer than I knew it was a law:

‘A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.’

The upshot of Gall’s law isn’t directly stated, but it’s important. To get complex things, you have to be able to do simple things. It turns out that enabling simple things is what the web as a platform does exceptionally well and that enterprise systems like Army Battle Command don’t do well at all. In fact, the DoD enterprise tends to prohibit simple things through an unintended combination of policy, practice, acquisition rules, and organizational inertia.

In an environment that does permit or encourage simple things, many of them will go nowhere, but without those failures, complex successful things are impossible. So, if you want your enterprise to be innovative like the web, you have to resist the Soviet urge to five year plan everything, and instead make at least some room to facilitate emergence. If you agree, then the goal of your planning should be to plan the development of infrastructure, policy, and practices that support the emergence of things you haven’t thought of yet.

A while back I met Carlos Castillo and Paul Lin through this blog. I had written a post touching on some similar themes to this one and they commented about their experiences developing systems while in the Army. Later we got together and they told me the story of a system that they built, against all odds, while they were deployed with the California National Guard to Iraq. Called Combat Operations Interactive Network (COIN), it was a simple but very effective set of web applications that streamlined operational administrivia for the soldiers in their unit. Things like crew and equipment manifests for patrols, the status of routes, etc. Stuff that until then was being done in Excel spreadsheets and lots of running back and forth with USB thumb drives.

It was a great story of how, with sheer determination, two guys in the field took on layers of bureaucracy and after six months got a single Linux box authorized on the secure network. Then, using skills they brought with them from their civilian careers, they launched COIN within days.

The really interesting thing from my perspective was that once that box was on the network, it’s value as a generative node was obvious and they rapidly extended COIN to scratch all kinds of other itches. People were lining up to ask for enhancements and new apps. Simple as it was, it had become a platform, and it was valuable in ways that the CompuServe-like Battle Command couldn’t be. Within a short time elements of COIN were being used in General Petraeus’ daily situation briefings and it had become a fixture in command centers across the theater.

If one Linux box can enable that much emergent innovation, imagine what java-scripting (or Ruby wielding) sergeants could do with EC2, some simple application and mapping frameworks, and a lightweight REST-based API strategy implemented across the rest of the Army’s Battle Command suite.

I went to the Pentagon with Carlos and Paul and had the opportunity to introduce them to General Sorenson through members of his staff. It was great to see them get recognition for what they had achieved. Most people in their shoes would have faced that mighty bureaucracy and fled the field. However, today COIN is languishing because they’ve rotated home. Once again they are struggling with the bureaucracy to get back over there and further extend and maintain it.

I was thinking about all this as I watched General Sorenson’s video. I’d love to see the Army push less for the development of specific end solutions like CPOF and work instead to build general infrastructure to support emergent innovation. Traditional requirements documents are low band pass filters at best. They are too time and distance displaced from users, but emergent processes close to the problem can achieve high-fidelity solutions quickly. To take advantage of this Army Battle Command should expand its mission to build platform components and content API’s and consider themselves one part enterprise system, one part platform, and one part edge development facilitator.

The over-arching goal would be to bring, train, and develop more Carlos’ and Paul’s in forward-deployed units and then make sure they have what they need to innovate rapidly and in situ. I would expect to see a flurry of simple but valuable things emerge. Some of them might just grow up to be the next really important big complex thing. Plus, just think how cool it would be to have an enterprise metric called ‘number of serendipitous emergent solutions per brigade.’

“

(Via Clippings.)

The curse of any effective task management system is that you get really good at capturing, prioritizing, and executing tasks. To the point that you start to believe that merely completing a task is helping your career. After a solid decade of rampant task management, I realized I needed to augment tasks with a system that would strategically guide and remind me that my job was not to do things, but to remember the interesting words in my title: manager, engineering, and products. That’s what I do.

The solution to being buried in minutia he calls the Trickle List, and it looks like this:

(Via Rands In Repose.)

The only interesting way to design a demo is to make it a story. You have a protagonist, and the protagonist has a problem, and they use the software, and they… almost solve the problem, but not quite, and then everybody is in suspense, while you tell them some boring stuff that doesn’t fit anywhere else, but they’re still listening raptly because they’re waiting to hear the resolution to the suspenseful story, and then (ah!) you solve the protagonists last problem, and all is well. There is a reason people have been sitting around telling stories around campfires for the last million years or so: people like stories.

Kottke adds: As with all advice, Spolsky’s rules should be tuned to your purposes but the ideas are solid for anyone who talks to groups of people.

(Via kottke.org.)