More book reviews
I’m ploughing through the book backlog at a decent pace, with three more finished this evening. They are:
- The Rain Before it Falls by Jonathan Coe
- The Artificial Silk Girl by Irmgard Kuen
- The Collected Tales of Nikolai Gogol
Just as I thought there was some order returning to my piles of books, there was a book sale at work today where I picked up seven paperbacks for a pound. Reading is never-ending (I hope).
Book backlog
I’ve been remiss recently in writing up my reviews for 26 Books. Tonight, I caught up on three that were waiting - The Carhullan Army by Sarah Hall, The Book of Laughter and Forgetting by Milan Kundera and Exit Ghost by Philip Roth, which still leaves me with five on the pile, plus the half-dozen I have on the go at the moment. If work would get out of the way, I might be in with a fighting chance to finish them before the end of the year.
REST links
I’ve been doing some research into REST and API design over the last couple of days for a client. In my travels, I collected a few really useful links and quotes.
The overriding feeling is that most APIs that claim to be REST APIs are in fact not. Most of them seem to be more RPC-style services. The pragmatic part of me says that you should just do whatever works, while the perfectionist in me admires the simplicity and cleanliness of a true RESTful style.
Anyway, here are the links and quotes, in no particular order:
There’s no way to get around platform differences when building distributed applications. The sooner people realize that, the better. – Dare Obasanjo
Mark Baker – Accidentally RESTful
Dare Obasanjo – Misunderstanding REST: A look at the Bloglines, del.icio.us and Flickr APIs
Joe Gregorio – How to Create a REST Protocol
Roy Fielding – Represetnational State Transfer (REST) - the original dissertation that coined the term REST.
Excellent concrete example of a RESTful API:
Instead of a “turnOnTheLightbulb?” request to a server object, we have a PUT “true” to the http://example.com/lightbulb/lit object supplied by the server. The http://example.com/lightbulb/lit object also responds to a GET request that returns true or false. POST is an “add information” request that doesn’t make sense for the lightbulb, nor does it really make sense to DELETE the lightbulb. So those requests would fail with a response indicating the fact. – from REST in plain English
Dare Obasanjo – WS-* is to REST as Theory is to Practice – read the comments too: they’re brilliant.
Steve Vinoski – The ESB Question includes a great quote:
Frankly, if I were an enterprise architect today, and I were genuinely concerned about development costs, agility, and extensibility, I’d be looking to solve everything I possibly could with dynamic languages and REST, and specifically the HTTP variety of REST. I’d avoid ESBs and the typical enterprise middleware frameworks unless I had a problem that really required them [...]. I’d also try to totally avoid SOAP and WS-*
The comments there are also a must.
From the archive: How to be a Brain in a Brainstorm
[The third in my series of posts that have disappeared with Interesource, but which I would like to keep available. This one was a look at how to be useful and polite in a brainstorm. It was originally published on 2nd April 2007.]
We often run brainstorms for clients here at Interesource. We have a group of experts, who we refer to as ‘brains’, that we call on to help us with these. They’re all expert in some area of the Internet and are all early adopters of the latest and shiniest stuff. You won’t need to explain to them what Twitter is or mashups are, or how Facebook is different from MySpace for example.
Of course this has its downside too: they’re all remarkably opinionated. Now, of course we love opinions because we’ve all got them and exposure to other opinions is the best way to challenge your preconceptions. That’s why clients pay for brainstorms, after all. The brains also tend to be too radical for most practical purposes, but that again is a benefit because ideas can always be toned down for the market they’re aimed at.
We usually mix in a few Interesource employees as ‘brains’ too. After all, we have experts a plenty on the staff. Recently I’ve been called on for two brainstorms. Here are my observations on what it takes to be useful in one.
You have to remember that you’re in the brainstorm for your opinions and expertise, so it’s OK to say things that are controversial and, in all likelihood, not fully formed or even at all practical.
The flip-side of this is that you’re not there to force your opinions or priorities on other people. You’ve been asked to tell people what you think, not suppress what other people think. You have to trust the people running the brainstorm to harvest the ideas and use the best ones. Just because you think it’s an awesome idea doesn’t mean that everyone else does. People who know me will recognise that this is the bit I really struggle with. Hopefully I’m getting better at it.
The two brainstorms I’ve been in recently have both been very positive and useful, but in both there was some behaviour that I felt was unhelpful. The first instance was one of the attendees telling the group ‘you haven’t come up with anything new’. Let’s deconstruct that.
First: you don’t *have* to come up with anything new in a brainstorm. They can be super-efficent ways of transferring knowledge, and that’s a great outcome. Second: a brainstorm group should behave as a team, not a series of individuals in competition with each other. If the brainstorm hasn’t produced anything new and it should have then the whole team has failed. It’s no good accusing the rest of the group of failure and trying to stand outside the failure.
This notion of it being teamwork is why brainstorms often start with trust games. Tim often runs brainstorms here and he usually makes people reveal an embarrassing hobby or fact about themselves to break the ice. This is great because it helps people to relax, lets everyone get some sense of the people they’re in a room with. After all, they may never have met several of the participants before.
I usually feel quite a lot of pressure before a brainstorm because I feel that there’s an expectation that I will say something brilliant or original and that’s difficult to do. You’re in a room with some very bright people and you don’t want to look stupid in front of them. But you have to remember that this is why there is no bad idea in a brainstorm - just say what you think.
You also have to submit to the moderator’s discipline. A good moderator will understand the client’s brief very well and will steer you away from topic areas that are not relevant. It’s important not to be offended by this; it doesn’t mean that the idea is bad, just that it’s better to move on to talk about something else. And for heaven’s sake, don’t keep trying to get your big idea back into the conversation if it’s moved on from there.
Running a good brainstorm is a tricky blend of finding people with egos and confidence who don’t mind shutting up when they’re told or listening to things they fundamentally disagree with without attacking it.
iPhone beats Windows Mobile in 5 short months.
Wow. The iPhone already has a greater share of the browser market than all Windows Mobile/CE devices combined. Windows CE is 10 years old, while the iPhone is just 5 months old.
(Via 9 to 5 Mac.)
Facebook and iPhoto
I’m probably the last person in the known universe to find out about this, but I’ve been very impressed recently with the Facebook iPhoto Exporter. It adds another tab to the Export dialog that lets you create albums, upload photos and tag your friends in them. Very slick.
Here’s what it looks like in practice (click for full-size):
What will 2020 look like?
I have no idea, but Shane Richmond asked me to guest blog for him while he was away on holiday. Here it is.
Basecamp pisses me off occasionally
We’ve been using 37 Signals’ Basecamp to write documents for the last couple of weeks at the Telegraph. All in all it’s a great product, but there are a few things that are really annoying.
For example, when someone writes a comment on a Writeboard that you created or contributed to you don’t get a notification by email, and there’s no way to subscribe to one either.
In fact, Writeboards are very much a second-class citizen in Basecamp. They’re hosted on another site, and because of the way the authentication works between them, the back button quite often ends up just redirecting you back to the same Writeboard again. The Writeboard itself has a URL, but that’s not the URL you should use to share it.
Writeboards are incredibly useful, don’t get me wrong, but they should definitely be better integrated. It would also be very useful if you could export them to PDF or Word format.
I’d probably not mention this, except that 37 Signals are really quite cocky about how usable their software is and how carefully they think things like this through. I wish they’d spend less time showing off, and more sorting issues like these out.
Not loving Stacks on Leopard?
Via Matt Legend Gemmell I found Quay - a way to have Tiger-style hierarchical folder menus in your dock, in case Leopard’s Stacks aren’t doing it for you. It’s shareware and costs only €7.
Leopard glitches
I’ve been using Leopard for a while now and, broadly, I like it. But there are one or two things that are really pissing me off.
- The PubSubAgent (used for .Mac bookmark synchronisation) craps itself all the time if you’re behind a proxy
- Disk images don’t always eject properly in the Finder sidebar
- As I mentioned before, AirPort Extreme discs don’t auto-mount or show up in the Finder properly
- iCal seems to have lost the event details panel and has replaced it with an annoying speech-bubble thing
- There are still too many apps with compatibility problems (Pukka and MySQL being the two that are affecting me at the moment)
