Flow|State has an excellent semi-rant about how poor the user experience is when using OpenID – both signing up and logging in. In particularly the question of what happens to all your accounts when your OpenID provider disappears is a particularly good one. It so happens that I was looking into this just today since I needed a user friendly but secure authentication mechanism. OpenID seemed like a natural choice since I was effectively starting from scratch anyway, why not use a standard?

I have to agree with “Jon”, Gruber (John with a h) does have a habit of linking to sites that link to him regardless of how good they are. For instance, this link list entry was a complete waste of time… I wonder if there’s any limit to it?

I’ve struggled with Lucene before and failed to configure it properly resulting in absolutely horrendous search results so a recent need to implement search functionality wasn’t something I particularly wanted to take on. In fact, I was prepared to do almost anything to avoid delving back into Lucene filters and parsers and tokenizers and “stuff”. This tends to be problematic given that Lucene is the dominate search library – so popular in fact that it’s been ported to other languages.

Alex Iskold has an interesting article “Rethinking ‘Crossing The Casm’” which asks how to maintain the interest of early adopters in the face of such an overwhelming number of new products: According to Wikipedia in 2006, Tom Byers, Faculty Director of Stanford Technology Ventures Program, described “Crossing the Chasm” as “still the bible for entrepreneurial marketing 15 years later.” It is certainly a powerful and proven theory, but it does need to be adjusted.

There’s this myth that’s existed ever since the beginning of OS X – that Cocoa apps are automatically better than any other type of application. They use less RAM, run faster and are just all round better – you can’t dispute it. If you take a lousy carbon app and rewrite it in Cocoa it will become amazing and all it’s problems will be solved. This is of course, complete and utter bull.

I’ve been setting up a site for my wife and I to help us keep in touch when we move over to the UK next year and to let us share photos with friends and family etc. Of course this leads to the fun of picking a domain name that makes sense for us and is easy to remember. Going through the list of names we thought up, “thesuttons” was the only one that we liked and was available – but only in a few TLDs.

Just as I’m catching up on Amazon’s web services, they introduce another one – this time aimed at payment processing. My first impression though is pretty underwhelming. The one thing that FPS seems to have going for it is that it is extremely flexible. Most processing systems focus on moving a specific amount of money from a credit card to the sellers account. FPS provides options for combining micro-payments, direct debit (and proprietary Amazon funds) as well as recurring payments etc.

I’ve done a fair bit more investigation into using EC2 for web hosting and it seems to be something that people do with a fair bit of success. In addition to Geert who commented on my last post and who’s site rifers.org is hosted directly on EC2, there’s also hanzoweb.com and www.gumiyo.com all of which just have their DNS pointing at an EC2 instance. I still wish Amazon had a preconfigured solution that acted as the web front end and load balancer with a static IP, but it appears that it’s quite feasible to just point your DNS at EC2 and your server seems to stay put.

The Ephox Weblog pointed me to James Robertson’s comments on Seth Gottlieb’s article, “Homebrew CMS” all of which is good reading. The key part for me is: Editing environment. If the authors can’t easily and efficiently get their words onto the site, you’re toast. There’s a huge amount that goes into a good editing tool, including table support, CSS, images, spell checking, and clean cut-and-pasting from Word. Even if you chose to use one of the commercial editing tools (a good idea!

One of the common first steps for scaling up an application is to move the database off to a dedicated server – often followed by having multiple application server instances to handle requests. With a standard SQL database that’s pretty straight forward, with data stored in Amazon S3 that’s not always as simple. S3 obviously provides a network API, but it doesn’t necessarily provide all the functionality you need from your data layer.

I like the idea of resources being addressable by a simple URL, but I’m having some difficulty reconciling that with resources that are versioned. Getting at and working with the latest version of a document with REST APIs is all pretty straight forward, but how do you retrieve the document history or a specific version of the document? I’m sure this is something that people have already worked out, but all my searching for discussions of it leads to people talking about versioning the API so that things don’t break when you change what operations are available or the data format returned, rather than versioning the resources themselves.

If you have a massive set of documents that you’re using Solr to search (let’s say a few million HTML pages) how much should you worry about losing the search index? It is of course always possible to reindex the original documents, but that would take a fair while, so should you keep a backup of the search index? If you restored the backup, how would you identify which documents needed updating?