Archive for July, 2006

SimpleViewer update - FlickrViewer needs an update!

Just to let you know that SimpleViewer has been updated, and version 1.8 is now out.

FlickrViewer has only been tested with version 1.7 of SimpleViewer, so until I check out any compatability problems with this new version, you should stick to using the older version combination:

I’ll check out FlickrViewer when I get a chance, but at the moment I’m a bit too busy with other things…

Tags: , , , , ,

Point and Shoot Photojournalist

Came across an interesting article on Rob Galbraith about Alex Majoli. Alex is a photojournalist that uses point and shoot digital cameras instead of large DSLRs, and has won several awards for his work. Makes you think - especially as I’m about to renew my insurance for my camera gear which has a value more than 3 times what I paid for my car! (Admittedly, it’s a rather cheap car…) Anyway, I’d never really considered the depth of field argument - it’s usually something I want to limit - but then there are other times when I just can’t get enough given the light etc.

I’ve been hunting around for a good point and shoot for a couple of years now, and am wondering if the new cameras from Panasonic will finally do the job. I want a wide angle lens, good low light operation (so high, noise-free-ish ISO rating), with good quality lens. The Ricoh GR Digital looked good, but at 400 quid is rather over the top. It’ll be interesting to see what the reviews of these new Panasonics say when they finally hit the streets.

Tags: , , , , ,

Dragon Fly (Darter) Photo


IMG_1538, uploaded by Mark Sweeting.

Went for a stroll in the Cheddar George (in Somerset) on Sunday and spotted this Darter. Really need to start carying a tripod with me (or at least a monopod), but it was so hot, and I was a tad hung over. I just couldn’t face it!

The colours seem a bit dull on this screen since I converted it to JPEG. Really need to sort out my colour profiles and things.

Tags: , , ,

Too busy to blog


IMG_1323, uploaded by Mark Sweeting.

So here’s a nice picture for you.

Undefined property: etag in rss_fetch.inc

Been playing with MagpieRSS (Version 0.72, which has come on loads since I last looked at it), and seem to have come across a bug. Anyway, I’ve been using the caching (which seems to work quite nicely), but get the folowing error from time to time:

Notice:  Undefined property:  etag in /…/rss_fetch.inc on line 156

Did a quick Google and found the following solution by Mark McIntyre:

I made the following modification to rss_fetch.inc which fixes the problem:

Change the following line (156):

if( $rss and $rss->etag and $rss->last_modified) {

To the following:

if ( $rss and array_key_exists("etag", get_object_vars($rss)) and
array_key_exists("last_modified", get_object_vars($rss)) ) {

This will prevent the notice output if etag or last_modified keys don’t exist.

Time will tell if it works, but it looks like a sensible solution. My googling threw up loads of pages suffering from the problem but only this one solution, so hopefully others will find this useful.

Tags: , , ,

Second BritBlog server installed

I took this afternoon off work today and deposited BritBlog’s second web server up at Sovereign House in London’s Docklands. The journey in the car was a bit of a nightmare (with four hours of driving) but it’s good to finally get that done. It will take a bit of time to get the box ready for use, but it’ll make life a lot easier over there.

I don’t know what it is about the drivers in London, but driving up there feels like a constant battle. You have to drive right up the backside of the car in front or else someone will try and push into the gap. In fact, people will just try and push in anyway. And what really pi**ed me off was when an ambulance was trying to get through some traffic, and other drivers saw it as an excuse to gain a car’s length in the traffic — with absolutely no regard for the ambulance truing to get though. Unbelievable! Still maybe these drivers will one day die in a car accident while waiting for an ambulance stuck in traffic to get to them. OK, that’s a bit harsh, so maybe they should just come very close to death so that they realise what obstructing an ambulance can do :)

France are into the finals, so I know at least one person who will be pretty happy, and I’m totally zonked, so think I’ll go to bed!

Night night!

Tags: , , , ,

Wankr: A flickr API project

Wankr logo I’ve been playing with web service APIs quite a lot lately, especially the amazon and flickr ones. Anyway, my current tinkering lead to … wait for it … wankr.co.uk.

It’s a pretty simple site: it displays recent photos tagged with the word ‘wankr’. However, the important thing for me was building a workable caching mechanism. The main advantage of web services is also be their biggest problem: they typically run on remote web servers. This means that (if you want to incorporate results from a web service call into a web page), there can be a noticeable delay for the user of your web site while they wait for the page to be compiled (server-side) and returned to them.

wankr.co.uk screenshotSo as I said, the caching mechanism was the important thing for me on this one, and so far it works quite well I think (famous last words…). The main cause for delay here is getting the tag details for each photo that is displayed. You have to run a seperate query against each image, so in this particular example that is 1 query to get the list of images, plus 36 queries to get the tag details for each of the photos.

That’s a lot of queries, and as you can see in the graph below (at 12:46:05), it takes quite a while. (The data start time shows how long it takes for the first byte of data to come back from the web server once the request has been made. This typically is the time taken for the web server to generate the page, pulling in content from sources like databases, and in this case, remote web services.)

The caching I’ve implemented stores tag details for each photo indefinitely. I’m guessing that photo tags won’t be updated that frequently — at least in the time they’re displayed on the wankr homepage — so this shouldn’t cause a problem. The remaining task here is to write a process to clean up old cache files.

In terms of the main API call (the one that gets all the photos tagged with ‘wankr’), this is effectively cached for 5 minutes. I actually cache the rendered HTML for five minutes, so the response in the event of cache validity is quite good. On the graph below, the results at 12:46:42 show cached image tag data (so no need to make those 36 queries to flickr) and a re-query of the flickr API (to look for any new photos). Finally, the results at 12:47:19 show totally cached HTML (so no web service queries), and as you can see a nice quick data start (the yellow) time!

Effect of caching web service calls

The cache model isn’t perfect (for example there is no file locking implemented), so things could get a bit messy if there were a few users on the site at once. I’ve added some cache-friendly HTTP headers too, which may improve the performance for some frequent visitors…

Anyway, the site is just a bit of an experiment at the moment, but feel free to mention it to others ;-) It’s got a tag cloud, so does that make it a Web 2.0 project?!

Tags: , , , ,