I Met The Walrus
September 18, 2008
Watch it. Think. Act. It is as simple and as difficult as that. There is no other way.
Lovely piece of animation too ;-)
What the social web can learn from Lehman Brothers: social systems architecture
September 16, 2008
We did a car boot sale on the weekend.. and amongst the pile of books that we keep trying to sell but never do was one I bought a couple of years ago. The topic of that book was how to price various kinds of exotic derivative contracts, as used in a range of complex ways to buy, sell, spread and mitigate risk and make loads on money for investment bankers.
Derivatives start out as nice simple ideas, but before you know it, things get very complex. And if you trade lots of derivatives with lots of other parties, you end coupled to your trading parties in lots of weird ways.
So, what started out as a possibly sensible risk management exercise becomes so complex and you end up so tied to everybody else’s success that you’ve got a Lehman-sized problem.
The trouble here is:
Complexity: it gets too hard for humans to understand what is going on. Everybody kind of pretends they do, but nobody really does.
Coupling: it gets very hard to work out how to untangle the knot of relationships you’ve created.
Trouble. So the investment bank solution was to create more and varied derivatives to cover all of that, making it worse. Pass the coke and let’s do some business.
What has this got to do with the social web? Lots.
If we layer API on top of API, and couple all our social web services together without a lot of thought about systems architecture we run the risk of making something complex, over-coupled, and utterly unstable.
And when we start building businesses on top of all of that, things get risky for those businesses indeed. And if we start relying on complex, over coupled web services, what happens when something’s business model fails and it goes into the deadpool. Could the whole lot fall over and be hard to get working again?
So, I’m thinking we need to start thinking about the discipline of social systems architecture, where we manage and look at the interconnected web as we do large distributed systems, taking note of single points of failure, instability, reliability, complexity and coupling.
Sure, we can integrate lots of social web stuff, but we need to keep a systems engineering mind while doing it. Otherwise it is a bit like running your billion dollar derivative contracts out of an Excel spreadsheet.
Google Chrome’s chrome is on the inside
September 8, 2008
There’s been a bunch of speculation as to just why Google has taken on the browser market with Chrome. Everybody has a good idea as to why. Now it is my turn. And while I’m at it, I want to give a quick review of the features of Chrome and why they might be important. We don’t get a new browser to play with every day of the week, and this one is different.
Okay, so what is Chrome all about? Why?
My take is this: The important features are not in the UI. Chrome usually refers to pretty UI stuff that isn’t important. Google’s being ironic here. Chrome looks ok but is nothing startling or beautiful. It is low key. Few menus, calm UI features. As if the served page matters more than the browser. Yup.
Basically, Chrome is the first browser that is designed from the ground up to serve web applications fast and seamlessly. Engineering-led Google has built something to serve Gmail, Google reader, Gears, and other web apps without getting in the way. In fact, accelerating these applications and all other web applications to make them snappy.
Why?
Beacuse Google’s web app developers have been telling the bosses that what they need is speed, proper memory allocation, decent security and proper multitasking to deliver web apps that really work. They’ve got a long way with the existing toyish javascript implementations but the limits are clear. All the other browsers developments were off in user chrome land. Adding more features and menus and gradually getting faster javascript execution but not quickly enough to keep new applications coming forwards.
And once you’ve got a good, fast, secure engine in the browser, then you can implement all the chrome you like in javascript in the browser, not in the menus and in the browser executable. Hooray.
Strategy: Raising the Bar and Elevating Best Practice
My take on Google’s strategy is to elevate best practice in all browsers so web apps can succeed. That’s why all the components are open source. We all win (and Google wins more) if we have quick, secure browsers. So changing the game, raising the bar, and setting a new technical standard for browser best practice is the way to do this. Packaging it all up in a browser shows it off and gets the early-adopters along for the ride, but I’d guess that Google can handle having the V8 javascript engine and other features show up in Mozilla and elsewhere.
Oh, and it has to nicely unnerve Microsoft. Always a good thing.
Chrome is fast and tidy and usable, and that’s using it on a Mac using Parallels to run it under Windows XP. Can’t wait to see a native OS X version. It ought to fly. Best feature for me, apart from the Internals, is the ability to turn any web app into a single-window application. We’ve been messing with this in OS X a bit and it is a nice idea, but Chrome makes it easy.
Neat little browser. But don’t forget the real chrome is on the inside.
Comic explains Google Chrome
September 2, 2008
We’re just back from August holidays, and have arrived back to find a comic from Google explaining the why and how for their new open source browser called ‘Google Chrome’.
Nice idea. The comic introduces the Google team working on the product, and then they talk their way through explaining what they are up to with the browser. The team become characters in the story and get in and interact with the new features of the browser, at their scale, playing with it. It is a long comic but the way it explains some quite technical concepts is very clear. Worth a read. Much, much better than a boring FAQ or press release.
Chrome, they say, will be released tomorrow. We’ll have a bit of a go and see what it means to the web. I’m hoping for a bit of a revolution as I’m feeling that the browser metaphor is a bit stuck and is holding us back from making and using fully on-the-web applications.



Recent Comments