Simon is a hands-on software architect who works within 
[Twitter] simonbrown: it's friday and I have a camera @chinposin update
[Coding the Architecture] Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London. 1. Coding the Architecture : From Developer to Architect The first is a re-run of our ...
It's my data
And I don't want it on the cloud
The recent release of Photoshop Express has got me thinking about the growing trend of web sites allowing users to upload their own content. Just think about any site like flickr, Facebook, etc that allow you to upload your own photos. I was initially intrigued by the release of Photoshop Express but, now that I've looked at the test drive, it doesn't really offer anything for me. There's no denying that it's an amazing piece of engineering and the UI looks fantastic, but I don't get the overall concept. It's software as a service (SaaS), but you need to upload your photos to the Adobe servers. And this is the part that I have an issue with.
Regardless of the bandwidth requirements (i.e. my upload speed is much slower than my download speed, although this will undoubtedly change in the future), I don't necessarily want to upload my private data to the cloud. And I don't see why I should; it's mine and I don't want anybody else to have access to it, particularly with the dodgy EULAs that some of these services and subjecting users to. Give me an AIR version of Express that I can use locally and I'll take a look, but only provided that I don't have to upload my data.
The thing I'm left wondering is how something like web-based e-mail is different. That's also my data and it sits on "the cloud". Perhaps the fundamental difference is that e-mail is "connected" and my photos aren't?
The 3 types of city developers
Or how business knowledge is deemed more important than technical knowledge
Despite the impending doom and gloom of a city recession (or just a few months of uncertainty, depending on your point of view), the recruitment agents are out in force at the moment. Most people I've spoken to recently have had a ton of cold calls and there's a worrying trend. But before I dive into that, let me summarise what I think are the three types of city developers.
QCon London 2008 - day 3
I have mixed feelings about day 3 at QCon, which started off with a brilliant session about the architectural principles behind eBay. Randy Shoup talked through the key principles, which are :
- Partition everything
- Async everywhere
- Automate everything
- Remember everything fails
I've said this before about some of the other sessions, but I really like it when we get to look behind the scenes at what other people are doing, particularly when you see that every system has it's own set of trade-offs and compromises.
The next session I attended was about the BBC website, primarily from the perspective of what the user sees. The speakers had literally been drafted in the day before and while I liked their actual presentation, I was left wanting more information about the architecture behind the website. They did go into some details about how many servers they had, etc but not much on technologies and the like. Hats off for pulling something together so quickly though!
After lunch I went to a session entitled "HTTP Multicast Routing, Scaling the Real-Time Web", which was about real-time data distribution with Comet. I've tried out Comet before and what really intrigued me about this session was the term "HTTP multicast". Unfortunately, this session was just an introduction to Comet and how it can be used to stream data across the web. I found Jonas' explanation of Comet very clear and easy to understand, but there was nothing new to me here. Myself and a few other people in the audience were expecting a talk about how they've managed to do proper IP multicast on the web, but this didn't turn out to be the case. In fact, half way through the session, Jonas said that the term "HTTP multicast" was a bit of a misnomer, so they don't use it. In summary then, this was a good overview of Comet, but the session title was misleading.
Following this was a session entitled "Tackling Code Debt", which basically focussed on why continuous refactoring is essential to maintain a high quality codebase. This seemed to be a rehash of some of the existing material around refactoring and agile development. Something that did strike a chord though was that somebody needs to take ownership of this whole process and motivate the team to refactor while they develop. I'd say that's part of the architect's role.
A closing panel wrapped up the conference, which was interesting but I can't think of any discussion topics that jumped out at me. I probably should have written this on Friday, but I was too tired. :-)
I was talking to a few people about the conference and their experience was the same as mine - Thursday was the best day and there were a couple of time slots where I wish I could have split myself into two. Overall it was another great event and I highly recommend it for anybody thinking about attending next year.