The key thing that changes is the ethernet MAC address of the machine. This is the low level network identity which is used prior to getting a proper TCP/IP address for use on the internet. They are (I think) unique per machine and so they are used as a key for all sorts of things. Two I have found so far are Time Machine and MobileMe syncing.

Neither of these services warns you, they just stop working, which is quite irritating. To fix Time Machine you need to reselect the drive you are backing up to, this should work, but didn't for me.

For MobileMe you need to go to the Sync tab in the MobileMe preferences and tell it that the old machine name is really the same as the new one. Then you'll get to merge the data.

It is a pity that macosx doesn't recognise that it has a new motherboard and offer to fix these for you, but hopefully this list will help you one the right path to getting things back to normal.

"the evolving world, the world of hidden persuaders, of the communications landscape developing, of mass tourism, of the vast conformist suburbs dominated by television – that was a form of science fiction, and it was already here".

Just as relevant today, quote taken from The Guardian obituary, itself taken from a longer interview with JG Ballard from last summer.

A few months back I was very tempted by a netbook, running Ubuntu as a hackintosh, but the combination of my MacBook Pro, my iPhone and an ebook reader feels like it would be enough. I don't want to have to deal with syncing my working environments. I have a MacBook Pro which I use for everything, it is my work machine and my personal machine. This means I have no context switching to deal with and something is never on the other machine.

The weight aspect of the netbooks does appeal, the 2-3Kgs of a 15" laptop becomes wearing after a while. However I realised that I can cope with a 5-6kg bag, it is the paper books that drive the weight to over 10kgs. So being able to carry more than one book around would be a real boon. Stanza on my iPhone is good for fiction, but not so good for technical books.

I'm going to try out a Sony PRS 505 for a few days to see if I like the idea. The lack of touchscreen is already annoying me. I'm trying calibre and Docudesk PRS as library management apps.

Interestingly the ebook readers are about the same price as a netbook, at around 250-300 pounds. The netbook offers a lot more for the money, but small and light costs more I guess. Computer, book and phone appeals more than computer, netbook and phone.

UPDATE: 6th May 2009. I want a Kindle DX
, native PDF support and text book sized, but only available in the USA at the minute.

The new platform Y (planning application pdf), which is the cause of the recent demolition, will run along the old cab access road, shown in this photo taken in 2006. To the left in this photo is the current platform 1.

There is much change at Kings Cross, some of it I think is positive, if they can make it as nice as the St Pancras station, that would be great. The access issue is frustrating. My morning walk out of Kings Cross in the sunshine up York Way is not exactly unpleasant. A bridge over the platforms would be appreciated and route a large number of people away from the front of the station and thronging up York Way.

• Identity is bound in, other people’s identity and interests become the focus of your site
• Linking, tagging and content reuse are important
• Asymmetric follow makes for tricky scaling issues
• Privacy complicates implementation
• Polymorphic nature of relationships between people, content and metadata, even functionality
• Small is good, let your community shape what you build, rather than launching a big app
• Rapidly evolving protocols and standards

• Preference for agile development approaches,
• flexible development a month at a time is better than rigid multi-month plans, ie release early and often.

• Retaining flexibility
• Importance of source control and the shift to distributed models like git or hg
• Dev, test, staging and production machines, continuous integration and TDD
• Conditional releases - one site different versions depending on who you are, tags and flags
• Alpha users (set list, or tagged groups)
• Tagged features available to certain tagged users (dopplr model and others)
• Testing with high loads and real data is hard, apache bench etc
• Rolling restarts for no downtime eg haproxy and mongrels
• Puppet and capistrano, managing collections of machines and code deploys.

• Design is how it works
• Use cases for developers, understanding the whole picture vs implementing a feature
• The app has a point of view, understanding what fits and what fails as a feature
• How code review helps
• Linking the designed for activities to implementation
• REST approaches compared to RPC / CGI approaches,
• better urls, relying on the verbs in HTTP properly, not everything is a GET
• Feeds and APIs from your app

• Failing gracefully is a strong capability for your site
• What makes a website tick (good error recovery)
• Accessibility is important, unobtrusive javascript is a great approach. (Not a tick list)
• Using the console for code level prototyping of ideas
• Templates and CSS vs application code and database schemas

• UTF-8 and not ascii for data storage everywhere.
• Understanding internationalization and when to do it

• SQL injections, cross site scripting, escape everything, only unescape content you know you really want to display.
• Let them use html and filter approach is doomed, whitelisting is best approach, CSS has similar vulnerabilities
• Cross site request forgery
• Google web accelerator means every link can get processed
• Ensure that form interactions really do come from your own site, use a token to prove this, unique per user and tied to session, this token is now extremely valuable
• Invisible iframes and click jacking
• Flash and browser plugins complicate the whole situation and web browser javascript and quirks mode means they are black boxes

• Forget WS-* unless you really need it for integration
• http://www.37signals.com/svn/posts/1509-mr-moore-gets-to-punt-on-sharding
• http://www.new.facebook.com/notes.php?id=9445547199
• http://highscalability.com/amazon-architecture
• Not about optimisation, architecture more important
• Load balancers, proxies and caching
• Realtime vs non-realtime
• XMPP etc and see http://www.loiclemeur.com/english/2008/12/xmpp-pubsub-aka.html
• NOT just XMPP, the importance of caching
• The qualitative argument for asynchronous development.
• From the SXSW Scaling Boot camp 
• "Design for parallel steps and use queuing as much as possible
• http://www.slideshare.net/rabble/beyond-rest-building-data-services-with-xmpp-pubsub

• URLS should be as far as possible
• Short, meaningful, canonical, permanent and hackable, plus opaque if needed eg amazon asins
• Pagination and url structures, what was on &page=3 is a recurring problem for aggregation pages, providing date based aggregation alongside simple pagination can help. Imagine Twitter with yyyy/mm/dd aggregation pages too.

• Search is critical to your site, but often left to the end.
• Understand what needs to be searchable and under what context
• Searchable items can grow, eg photos by place on Flickr
• Search can be provided by a third party eg summize and twitter
• Build your search based on the content you store, it is not enough to return simple text matches.
• Finding a photo means returning the picture and metadata, similarly for an event.

• REGISTRATION patterns
• Standard email address, password and screen name approach
• Deleted accounts and how to handle them
• Need for separate admin accounts alongside normal user accounts
• Staff will have admin account and user accounts with different capabilities

• Why do they exist
• How to implement them and what impact they will have
• Relative importance of OAuth, balance between identity and access to data, selective permissions
• Portable contacts POCO and what it solves
• OpenSocial, plus the various connect products
• OAuth address book access

• Distributed systems linked via common protocols and data formats
• Not yet mainstream, but an important direction
• Ma.gnolia M2
• Identi.ca (openmicroblogging)
• http://www.jaiku.com/blog/2009/01/15/were-going-open-source/
• http://www.zengestrom.com/blog/2008/12/foreign-friends-from-a-servicecentric-to-an-objectcentric-social-web.html
• Activity Streams and DISO work

• What to build and how.
• Data to base reputation upon
• How to aggregation and modify raw data
• Avoiding being gamed
• Bryce Glass and Yahoo pattern library.
• Managing and understanding your community

• When to build them
• What to put inside them
• How to maintain them loosely tied to TDD (no admin, no feature)
• Balance with just enough admin to get job done

• Will your community want stats
• How to build a personal stats tool
• Granularity, fine is expensive
• Simple overviews eg favouited content etc
• Stats for your own use
• Collect and timestamp everything
• Avoid monthly reporting focus, allow for real time reporting
• Think too monthly and you’ll just get monthly stats
• Good metrics are vital

• Recommendation systems
• Machine learning
• Classifiers and filtering tools
• Starting simple and figuring out what data to start with
• Person, location and content are all valid places to build upon

• Average costs per person
• Optimisation of HTML and CSS etc
• Server side optomisation, caching etc
• Flickr ops data graphs and notes
• YSlow and energy efficiency
• Speed = less energy used in general.

The cover for my book, you can pre-order it from Amazon UK and Amazon US.
I'm fondly calling it the spiders book.

Working on the API chapter and feeling like I'm being watched...

• The front page needs to communicate in seconds what your app is about
• 20 words and a picture, a compelling use case.
• Offer a demo, but words are better
• Aim is to get people to signup, but gradual engagement leading to signup is also desirable
Launching in "beta"
• The private alpha (non-public) early and often is a good approach to launching,
• start small and iterate it until you are ready for strangers
• Launch when you have something useful, not every feature on the wishlist
• Small applications are easier to understand and for other people to talk about, it does X
• Invite tickets risks / benefits
• Allow limited numbers of people into see your new app
• Can create an echo chamber and thus skew feedback
• Arriving with social context
• Dopplr
• Twitter
• Contact import APIs and their importance in bootstrapping context
• Tools and services for launching and support
• Getsatisfaction
• Twitter for comments and visibility
• Twitter inside getsatisfaction
• A blog
• Mailing lists
• Nurturing the first few hundred people
• Link to me (digg, reddit, del.icio.us)
• Face to face meetups
• Speaking at conferences and barcamps
• Nounification and verbification twittering, flickring etc
• importance of making the community self supporting or sustaining, they should surprise you
• Feature request vs bug management
• Adding functionality
• Watching for demand from the community
• Keeping up with the competition (or not)
• Listening
• Feature led development (featuritis)
• Making useful products (experience led)
• Staying focused and coherent
• supporting emerging activities
• determining what is next
• BIG changes vs features vs maintenance, eg Flickr localization
• Marketing approaches examples
• Word of mouth
• Being responsive on twitter etc
• Eat your own dog food, use your own product from day one
• Dopplr personal report using Obama
• Flickr blog - connect with your community
I'll of course credit any contributions I use. many thanks, Gavin]]> http://takeoneonion.org/archives/2009/03/launching-and-evolving--.html http://takeoneonion.org/archives/2009/03/launching-and-evolving--.html bswa building social web applications Thu, 19 Mar 2009 23:17:01 +0000 zzgavin on twitter.
• On the internet vs part of the internet
• Amazon and google vs most publishers
• New York Times and The Guardian
• Seeing the wider internet
• Integrating with the wider internet
• Building an API
• Why make an API?
• People and objects, the stuff of social applications
• Collections, tags, places and time as containers for objects via API calls
• Services not sites, programmatic access to data, not page generation
• Interoperability and Snowflake APIs (your data is not that unique)
• API traffic volume to twitter / flickr
• Supporting activities, not implementing features
• Using your own public API to make your stuff
• Microformats and RSS (read only apis)
• Where appropriate, bulk usage better via api, so that data only can be sent, not images and css along for the ride
• HTML badges
• Your data on someone else’s site, simple and easy to use
• Writable APIs
• Authentication required
• Security and OAuth
• Latency
• Examples Flickr / Twitter / MovableType and blog apis
• Sticking with standards
• Identica and other apps mimicing the twitter API
• RSS, Atom and AtomPub
• API scaling issues
• XMPP
• queues
• Real time vs near realtime
• NY TIMES, Flickr panda bears
• Privacy and security around APIs, commercial aspects
• Developer community management (wikis, mailing lists etc)
• Integrating existing or competing projects (whatever the route)
• Multiapp integration
• Registration SSO - OpenID and OAuth
• User management
• Data migration headaches and how to avoid them
• Having one of everything, not duplicates
• Email notifications - managing your output from multiple applications
• Internal integration (message queuing)
• On the cheap polling RSS
• Database calls, fast and brittle
• Queues and message passing
• Dealing with multiple claims of authority
• Family of identifiers better than one?
• Search
• Single search databases (big solutions like MarkLogic)
• Cooperative approaches (polling multiple databases and integrating)
• Multiple content sources with a single search interface is a hard problem, common for many publishers
• Community and published content, blog vs publishing workflow tools, who wrote this?
• Integration with other people’s APIs
• Functionality for free from others FTW
• How to manage external dependancies on others APIs
• Understanding provider and consumer relationships for your application
I'll of course credit any contributions I use. many thanks, Gavin ]]> http://takeoneonion.org/archives/2009/03/extending-the-application.html http://takeoneonion.org/archives/2009/03/extending-the-application.html bookinbeta bswa Building Social Web Applications Thu, 12 Mar 2009 00:48:19 +0000 I've mentioned before that I'm writing a book for O'Reilly, entitled Building Social Web Applications. It should be published this August. I've written quite a lot of it based on a mixture of interviews and conversations with people at conferences and in London. I'm now writing the more technical chapters and I need your help. I'm an interaction designer and product manager with a good head for technical detail, but being honest I don't write code daily. So it would be great if I can get your input into these three chapters.
• Writing the application
• Extending the application, APIs and integration
• Launching and evolving

The earlier chapters cover the questions of why are you building a social application and look at how people behave and interact with one another online. These three chapters cover how to implement and extend the application. The intent is not to give a lot of technical detail and reams of code, but to explore how social applications differ. They are not the same as building a content publishing system or an online shop. I've created some outlines to give a framework for what I think should be in the chapters, but please let me know what is missing.

I'm not interested in recommending a particular language or framework, nor one particular approach to scaling. I'm also interested in your opinions on centralisation vs distribution and federation. Examples that you can share and suggestions of content to include are most welcome. Dopplr, Flickr, Twitter and sites like LinkedIn or Facebook are the kinds of things I've been featuring, but I've also been looking at adding social features to newspapers, magazine and product companies.

I'm going to put the API and integration chapter up first, the other two, tomorrow. I want to start writing the chapters on the 23rd of March, so about ten days or so from now, so please let me know what you think. I'm zzgavin on twitter and I'll be talking about the book there too.

]]> http://takeoneonion.org/archives/2009/03/help-me-improve-building.html http://takeoneonion.org/archives/2009/03/help-me-improve-building.html bookinbeta writing bookinbeta bswa building social web applications o'reilly Thu, 12 Mar 2009 00:44:46 +0000 Ever since we got burgled in 2005 I've intended to replace the video camera that got stolen. We bought a Canon 20D SLR with the insurance money instead. Today I was looking at older pages on backpack and found the feature list I thought was essential about a year or so ago.

16:9 native
manual focus
firewire i/o
manual white balance / exposure
head phone
microphone
stills capture whilst recording
image stabalisation (preferably optical)
c. 500g
all features on the camera, no dock

Lucy got me a Kodak Zi6 recently and whilst it is 16:9, it has little else on the spec sheet. What it does have is pocketability and near instant on. A lesson to me in getting over involved in the features and not the activity. Of course, I'd want a slightly wider angle lens and better low light, but then it wouldn't have been about 100 pounds. I'll probably get a video camera at some point, but for long photo use, especially of my sons the Zi6 is perfect.

]]> http://takeoneonion.org/archives/2009/03/video-cameras-and-feature.html http://takeoneonion.org/archives/2009/03/video-cameras-and-feature.html photography Tue, 03 Mar 2009 12:22:28 +0000 Last night Paul Mison, Chris Heathcote and myself talked about the Barcamp London 6 ticket debacle. The alleged 55 first round tickets were snapped up in 40 odd seconds. This meant that unless you were sitting primed at 3pm exactly you stood no chance of getting a ticket. Luckily I'd had sufficient warning and was ready, but a few seconds later and I'd still be waiting for a chance to get a ticket.

I'm not sure what this process will lead to in terms of a conference, but I know it has led to various upset people over the process. So, on my train ride home last night I started thinking about the advantages of foo over bar camps and vice versa. Foo has a roster of great people, it is hard not to have an interesting conversation at a foocamp, I'll admit bias as I've been a couple of times. Barcamp can be a great experience too, they are open lively events and give a real freedom to talk about something that interests you. However the ticketing process has become worse than first day of the christmas sales, particularly for the London event.

I believe the selection model has some benefits and that there is space for another model for un-conferences alongside the completely open barcamp and the private invite foocamp. There are many other models for normal programme based conferences, of course. The programme committee choosing the programme from submissions, or inviting speakers are both popular models for paid conferences.

Drawing on all of that, I propose the seed16 model for unconferences. The basis is a seed invite list, like a traditional programme committee. Each of these people can invite three attendees, each of these attendees can invite two people, each of these can invite a further one person. Each seed person leads to a total of sixteen people, three directly and a further 12 indirectly invites, plus themselves.

seed invites	3 who can invite	2 who can invite	1 each
		2	1
	3	2	1
		2	1
	3	2	1
		2	1
seed +	3 +	6 +	6 +
Equals 16 per seed

It offers much of the benefits of the barcamp model and some of the selection inherent in a foocamp, but distributes the invites amongst the participants. Nearly two thirds (62.5%) of the participants get to nominate someone to attend, which feels pretty inclusive.

It would need a simple application to manage the invite process, so that someone did not get multiple invites. Invites should time out too, so that a full leaf of 16 can get invited, should people not respond to the invite. Linking to a service like eventbrite or similar for actual ticketing would make sense.

Managing the conference in blocks (a leaf) of 16 means that it is possible to grow the conference by increasing the size of the seed pool. Also it should be possible to bring in different communities by asking different people to start. Four ruby on rails programmers will result in a technical conference, a mix of web designers and developers would give a broader mix. You get the idea. Taking a theme for the conference helps give it focus, I'd also expect these to be small close knit events for 30-160 people or so. I can imagine seed16 London or seed16 UX NYC, both regional and subject based events or even a mix.

The change here is purely in the setup of the participants, by getting the participants to largely select themselves you will get a cohesive group of people if you start with mutual friends, but by starting with a more dispersed set of people you'd get plenty of scope for serendipity. From there it would run as a normal unconference with people nominating themselves for sessions. The reboot model of voting up sessions appeals too and would be easy to add.

I'd be interested in trying this idea out later in the year with four or five seed people (64 or 80 attendees) and see how it works in practice. Fixing a date and a venue upfront would be important and to make the event self supporting I'd suggest charging an admission fee of say 10 pounds, with any spare money going to a post event bar tab. No date and venue as yet, probably in the summer when it is a bit warmer.

I'm sure seed16 has plenty of issues with the model, but running fast and cheap single day conferences should be easier than it is. Interesting and similar events show it is possible to run single day conferences successfully. I think the spreading invite model will avoid the zero day rush for tickets and the invite a friend model means it is less exclusive than the foocamp model. Distributing the invites also lessens the burden on the conference organisers.

Interested?

]]> http://takeoneonion.org/archives/2009/02/seed16-a-new-model-for-co.html http://takeoneonion.org/archives/2009/02/seed16-a-new-model-for-co.html conferences barcamp bcl6 conferences foocamp Tue, 17 Feb 2009 16:32:49 +0000

I spoke today at TOC09, about how to assess the activities that spring from having read a book and how to build an application that harnesses the content that flows from this activity. My slides are on slideshare Long tail needs community, Chad Capellman wrote some great summary notes about the talk.

I think the talk went quite well. My goal was moving the focus for publisher from encouraging reaction to the book to encouraging the reaction and activity that stems from actually reading the book. Anecdotal feedback shows that I got that message across.

]]> http://takeoneonion.org/archives/2009/02/making-services-not-just.html http://takeoneonion.org/archives/2009/02/making-services-not-just.html conferences toc toc09 Wed, 11 Feb 2009 20:39:38 +0000

That is me in the centre, we had fun, thanks Suhky for photo.

]]> http://takeoneonion.org/archives/2009/02/snowball-fight.html http://takeoneonion.org/archives/2009/02/snowball-fight.html London Mon, 02 Feb 2009 13:00:23 +0000