After months of rumours it’s finally here, so what is Google+ like? My first thoughts are that it’s super slick and that Circles definitely makes it different, but I’m not sure better.
Limiting the distribution of shared information will likely also limit the growth of the network, something that’s not going to help Google+ grow to Facebook’s size. Will the limited sharing encourage more sharing? I’m not sure. There have certainly been a couple of times when I’ve held back from sharing inside Google Reader as I know not all of my Facebook friends will want to see it when it’s sent to my wall via FriendFeed but that doesn’t happen often.
When sharing inside Facebook directly I already have the choice of publishing to my friends via my wall, or to a particular group wall and I make that choice when I share. People have the choice of joining a group, or or adding me as a friend, or both. I choose where I publish when I publish and they choose what they subscribe to. Having to partition contacts up front, before I have anything to share, is harder. Maybe it will become more natural, but currently it feels weird. The sharing itself is also harder, feeling a lot more like composing an email, having to choose recipients than just a place to post.
Circles apart, Google+ definitely feels somewhat early and skeletal. Hangouts look like a nice group video chat feature, but it’s difficult to judge with so few people currently on the network. Sparks doesn’t look like it will ever be as useful as Google Reader to filter information on interests and, given the focus on social sharing, feels like a bootstrapping mechanism more than a long term feature. Mostly Google+ feels like a weird, empty, alternate reality version of Facebook with more primary colours, which is to be expected.
There’s a long way to go, but I’m glad Google has made a start. Google+ feels like it could be both a real competitor and alternative to Facebook, which is a good thing. One horse races are never very interesting to watch.
I’ve been morbidly fascinated by the Rich Internet Application technology blood bath for a while now: Whirled,Metaplace and others tried to stuff virtual worlds in to web pages using Flash, Second Life stuffed Flash in to virtual worlds via Webkit, Unity stuffed Mono in to a 3D engine and then took on the world and Silverlight and Moonlight stuffed the CLR in to web browsers and Erik Meijer stuffed a CIL interpreter straight in to Javascript.
All good fun and there are fortunes to be won and lost to be sure, but the smart money seemed to be on waiting for the dust to settle and then using the winning technology. Recently, however, amazing technologies like V8, Node.js and the resulting browser Javascript arms race have been adding weight to the Google viewpoint that all you need is Javascript: a philosophy made more pragmatic by Apple’s decree that all you get is Javascript.
A week or so ago I decided to test the hypothesis by building a drum machine using only HTML 5 and Javascript. My first discovery was that while the canvas element is perfectly capable, it’s a very low level API, even for building something as rudimentary as a step sequencer interface. After looking at a number of drawing libraries I settled on processing.js as a higher level drawing API, something I’ve been meaning to play with since we used it to build SLorpedo at Hack Day a few years ago. Processing.js is a neat hack, that despite an incomplete API and some subtleties around casting does a great job of running processing sketches within a browser without a plugin. It also uses a sloppy parser enabling you to drop arbitrary Javascript in to your processing sketch, which makes it easy to just create Audio() objects within the sketch to playback audio. Unfortunately while it was easy to add audio playback, the playback itself was pretty disappointing: Firefox just spluttered and belched sadly while Safari did a decent job of playing beats for a couple of minutes before its timing went to hell and then the browser crashed. The shiny future may yet be HTML 5 and Javascript, especially when the experimental extensions to Firefox become widely supported, but we’re not there yet.
To experiment for yourself, click on the squares on the grid below to add beats to the sequence. To see the code, view source.
A video of my FOSDEM talk about Mono in Second Life and our plans for the future of scripting is now online (the slides are also available here ):
Watching back, I was surprised to hear myself say “Hooray!”, “Shit” and “Crap” quite so often…
While you’re catching up on FOSDEM talks, I recommend Miguel, Jeremie and Alan‘s talks from the Mono track. Unfortunately it doesn’t look like the very interesting talks on the XMPP track are available online, but I’m going to be catching up on lots of the talks I missed out on, including the key note talks on Saturday morning which I missed due to the very enjoyable beer event on Friday evening…
On Friday I jumped on the train to London to attend the first scalecampuk, an unconference about scalability, at the Guardian offices.
The sessions were all very interesting and mostly very relevant. I learned new things about XSS and CSRF and Django’s defences against them from Simon Willison, new things about messaging, pubsub, queues and data stores (process 1 message at a time, use message hospitals, send URLs to unavailable data that can be polled for with JavaScript and that just check memcache entries) lots about Varnish ) and it’s use at Wikia from Artur Bergman (Wikia runs off 18 apaches and 8 varnishes with 60GB of RAM and SSDs to serve 25 million pages and 950Mbps at peak, Varnish is generally better than squid ), but you need a modern kernel).
Lots of the talks were about moving storage, caching and queuing out of the application and just writing a small piece of business logic to tie them together. Against this background Alex Evans’ talk about the back end for Media Molecule’s Little Big Planet stood out like a sore thumb. Having not enjoyed using a Java web stack, Alex has just rewritten the whole of the back end as proprietary technology as a single binary in order to know the code from end to end. While it may be true that having custom physics or rendering middleware might distinguish Little Big Planet from other games, I can’t believe that custom technology to serve HTTP requests is going to be a competitive advantage. I hope Alex’s good ideas become Redis contributions rather than a maintenance nightmare and barrier to agility.
The lightning talks were also very good. Simon’s “ScaleFail” talk about the Guardian MP expenses app was hilarious (lesson: do load testing) and Gareth’s talk about Dumbo (a Python Hadoop client) was very useful.
At times it felt like the talks were suited to an ops audience, but “Dev’s should know about this!” was a regular refrain. Don’t worry: I listened and learned a lot. Thanks to everyone who made it a great day.