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. In other words, FPS provides a ready made billing department rather than just an order processing system.

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!), it still needs to be tightly integrated into the CMS.

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. For instance if you need to update search indexes you need a central server to track the changes and update the indexes. You may also need synchronization above what S3 provides etc. Whatever the reason, you need to provide a server to handle those data layer tasks and then pass the storage off to S3.

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?

We need to move our company wiki and JIRA instance to a server with more RAM and CPU to spare as they’re pretty slow on the current overloaded virtual server, so we’ve been looking at a few different options. One that came up was using Amazon’s EC2 and S3 services. We knew straight off that we didn’t need the scalability they offered but getting some experience using them could be beneficial and we really didn’t know anything about what they actually offered so it was worth a quick look.

You might have noticed a distinct lack of posts recently, that’s because I’ve finally followed through on the whole engagement thing that happened a couple of years ago. I took the opportunity to have three weeks off work and detechify (detox for techies) so didn’t wind up blogging while I was away. I must admit it was quite nice to spend the week away on honeymoon without even mobile phone reception on a tropical island. Next time we’ll try not to do it in the middle of winter.

I play with OSs a bit, so a when I get my new MacBook, I obviously installed Windows via bootcamp. Later, Apple released something under NDA which also required a dedicated disk partition (for arguments sake, let’s call it Leopard), so I installed it over the top of my bootcamp partition.

Of course, one you reformat a bootcamp partition, Bootcamp assistent refuses to do anything with your system making it impossible to reinstall Windows. You can however fix this quite easily with the diskutil command line utility, without needing to repartition. Just reformat the drive as MS-DOS FAT32.

$ unzip ~ephox/vmware-debian-etch-r0-mini.zip

bash: unzip: command not found

Might have been just a little bit picky when I first installed that box….

So we’ve got a new internal system that we’ve built on top of JCR. Currently we’re using Jackrabbit as the repository, but eventually it will be ported over to something like IBM Portal or something like that. Unfortunately, right now we’re deploying the app to a pretty limited server – both in terms of CPU and RAM.

It turns out that using Jackrabbit with the Derby persistence manager in that kind of situation is a horrible, horrible idea. Everything works great on systems with modest amounts of CPU and RAM but once we deploy to that poor little virtual server in the sky page load times skyrocket and the whole thing becomes unusable.

Ken Coar complains about some of the changes in FireFox 2.0 and mentions:

My basic plaint is as usual: when changing the user interface, don’t violate the Principle of Least Astonishment and force the change on the user. Make it the default, perhaps, but always provide a preference option that lets the user keep the old UI behaviour. The user should be in charge of changing his work habits, not the software.