Profile cover photo
Profile photo
Rob Searles
50 followers
50 followers
About
Rob's posts

Post has shared content

Post has attachment
Just finished reading a wonderful blog post[1]. Reminded me very much like the The Little Schemer[2], which gives your brain a good clean.

[1] http://stevelosh.com/blog/2013/03/list-out-of-lambda/
[2] http://www.amazon.co.uk/Little-Schemer-Daniel-P-Friedman/dp/0262560992

Post has attachment
Ok, totally had it with winter now!
Photo

Post has attachment
Just seen a great talk on Perl by  +Paul FenwickPaul Fenwick (pjf): The Perl Renaissance

I started out my career with Perl but sadly I haven't used it much at all over the past few years. After this talk I am itching to dive back into it. Some of the stuff that's been going since I last used it looks fantastic.

Great talk! 

Post has attachment
Donate to a really worth while project: http://www.indiegogo.com/projects/sonar-project/x/1765104

Jonathan Nadeau is building a flavour of Linux with the goal to be as accessible as possible for people who are blind, partially sighted and those with oth
er disabilities.  Technology and computers in particular are a true democratiser (if that is a word?!). They help level the playing field between all types of people, and what Jonathan is doing helping to level that playing field just a little bit further.

It would be great if you too could contribute to the Sonar Project:
https://www.indiegogo.com/projects/sonar-project/contributions/new

Thanks

Post has attachment
Keeping out of the freezing Berlin weather in the Technology Museum, in which Lua and I found this huge model ship. And yes, it is made out of Lego!
Photo

Post has attachment
The future is almost here! Another post about using the iPad and "cloud" as development platform. I am convinced we are beginning to see the end of the laptop.

Post has attachment
I just listened to a really interesting episode of the FLOSS podcast. Episode number 39: http://twit.tv/floss39. It was an old episode interviewing +Simon Phipps, who at the time was the Chief Open Source Offices at Sun (this is in the days before it was bought out by Oracle). It is a really fascinating interview about why and how Sun moved towards open source, and at times it was quite philosophical. The main gist of the interview was that with the invention of the internet and pervasive presence of it, the topology of society is gradually changing. Society, Phipps argued, was going from being Hub-Spoke based to a more meshed approach. In this kind of society, transparency is the key and reputation is the currency. I'm listening to it again as it was one of the best podcasts I've listened to in a very long time.

More information about Simon Phipps can be found on his blog: http://webmink.com/.

Kudos to +Fabio Cevasco for one of his blog posts which lead me to the show: http://www.h3rald.com/articles/randal-schwartz/

Went to the StackOverflow Careers Berlin launch at Betahaus tonight - mainly for the beer. Was pretty good, but there was a talk about the localisation of the SO Careers site and tips learned, which was curious as I can imagine that 99% of the (European) audience have had more experience with localisation than the (American) presenter. Good beer though!

Post has shared content
I recently wrote the following in an e-mail, but it seems suitable for a wider audience. tl;dr: I think it's more important for specs to be technically sound than it is to get consensus on them.

Consensus (also known as "design by committee") is a terrible way to design a language or platform. Committee design dilutes responsibility and blame (everyone just starts saying things like "yeah, I didn't like it, but we had to do that to get consensus") while letting everyone take credit for everything (since their ok is necessary to get consensus), which makes it an attractive proposition for people who want to further their careers without really doing any work. You also end up with people who arbitrarily disagree with things just so their voice is heard, you get political decisions ("I'll agree to your pet feature if you agree to mine"), you get specifications that feel like they've been written by fifteen people all with different styles, in short, you end up with a technology that doesn't know what it is and doesn't do anything well.

You get much better results by putting all the blame on one person, who then feels extremely motivated to not design something that sucks, while diluting the credit to all the people who are contributing solid technical information. This model pushes the people who don't want to do real work away, improves the quality of the final product, and provides an environment where if there are multiple completely divergent viewpoints, they can compete rather than being forced to ruin each other.

The other problem with "consensus" is the question of consensus among whom? In practice in specification working groups it ends up being consensus amongst those who bothered to show up, but this is almost always a non-representational group. For example, in some groups (e.g. W3C's WebApps group) implementors tend to be over-represented while authors and users are virtually absent. In others (e.g. IETF's hybi group) implementors of one conformance class (in this case servers) tend to completely outweigh implementors of another whose buy-in is actually more critical to the success of the technology (in this case browsers — WebSockets would have gone nowhere if none of the browsers implemented it, but would still have been a roaring success if only a fraction of server vendors cared to support it, since anyone can implement the server side). I've been in situations, e.g. the sXBL fiasco, where I've represented all the browser vendors in a group consisting of a dozen or more people, and if everyone agreed to something but me it was considered that we had consensus, even though in reality it meant none of the implementors were on board.

This is why "consensus" isn't a value I hold highly. Specs shouldn't be designed to consensus, they should be designed so that they end up solving real problems.

(Note that this does mean that there are certain stakeholders who need to be on board -- e.g. a majority of implementors for the key conformance class. So for example, for HTML, I need to make sure that whatever I spec is something that the bulk of implementors want to implement, otherwise it goes nowhere. But that's not consensus, it's just that "we won't implement that" is highly relevant technical feedback.)
Wait while more posts are being loaded