It's just gone midnight here in England (I'm in Exeter for the new year), so Happy New Year to all. Top weblog-related priority for 2006: upgrade this aging heap of badly written object-oriented PHP to something better. I'll try and get some good content flowing more regularly as well.
Best wishes and good luck for 2006!
I had the pleasure yesterday of seeing Douglas Crockford speak about JSON, the ultra-simple data interchange format he has been promoting as an alternative to XML. JSON is a subset of JavaScript, based around that language's array, string and object literal syntax.
As of today, JSON is supported as an alternative output format for nearly all of Yahoo!'s Web Service APIs. This is a Really Big Deal, because it makes Yahoo!'s APIs available to JavaScript running anywhere on the web without any of the normal problems caused by XMLHttpRequest's cross domain security policy.
Like JSON itself, the workaround is simple. You can append two arguments to a Yahoo! REST Web Service call:
&output=json&callback=myFunction
The page returned by the service will look like this:
myFunction({ JSON data here });
You just need to define myFunction in your code and it will be called when the script is loaded. To make cross-domain requests, just dynamically create your script tags using the DOM:
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = '...' + '&output=json&callback=myFunction';
document.getElementsByTagName('head')[0].appendChild(script);
In long running apps you'll want to work out some kind of cleanup system to remove script tags from the DOM once they have been executed. More on this technique here.
It should be noted that del.icio.us has had APIs like this for a while.
Sadly there's no Perl Advent Calendar this year, but the slack has been picked up by Drew McLellan's 24 ways to impress your friends - a neat web development tip every day until Christmas.
Lazyweb request: 24 ways is currently devoid of baubles, reindeer, animated doors and DHTML snowflakes. Someone needs to write a Greasemonkey script (now Firefox 1.5 compatible).
No such problem over at radiac.net, where Richard has outdone himself.
I'm pretty inexperienced as a public speaker, but somehow I landed two speaking gigs in as many weeks recently and learnt some useful lessons about presenting in the process.
I gave a talk at d.Construct in Brighton on the 11th, entitled "Ajax and the Flickr API". d.Construct was a Web 2.0 themed conference and you don't get much more Web 2.0 than Web Services and Ajax; as luck would have it, Flickr's Ajax implementation makes use of the site's public web service API to do its magic. The talk I gave described the basics of the API, showed some examples and described the basics of how the Ajax on the site works. The slides are available, as is an MP3 of the talk itself courtesy of Drew McLellan's skilfully compiled d.Construct podcast series.
d.Construct was a great event, and I'm proud to have been a part of it. There are a bunch of photos from the event on Flickr; pictures from my talk are here.
The second talk was "An Introduction to Django" at the London Web Frameworks Evening on the 17th (slides here). Unfortunately I was less well prepared for this one, which was a bit of a pain since there were 200 people there (as opposed to 100 for d.Construct)! I felt the slide bit of the talk was adequate but thankfully the demo went down a storm - when you're demonstrating www.lawrence.com it's hard not to put on a good show.
Here's what I learned about giving presentations:
I really enjoyed both events (both as a speaker and an attendee) and I'm looking forward to future opportunities to be enthusiastic in public.
I'm still trying to get my head around Google Base. Here's a brain-dump of my thinking so far. First, some links.
Base is a very interesting product for a whole bunch of reasons. The data model is surprisingly simple on the surface: all items have a title, description, (optional) external URL, a "type" and a set of labels (a.k.a. tags) and "attributes". Attributes are something for tag enthusiasts to get excited by - they're name/value pairs that are kind of like tags in that you can apply them to anything, but more structured and with a greater level of implied meaning.
Attributes instantly made me think of geotagging on Flickr, where tags are overloaded to store latitude and longitude values (example here). Having first class support for this kind of extensible data is a very powerful concept.
Another interesting problem that the Google Base data model could be used to tackle is Wikipedia's WikiProjects. If you look at any US Navy ship entry on Wikipedia (example) you'll see a table on the right hand side of standard attributes relating to that ship - things like Length, Displacement, Armament and so on. This data isn't really structured - it's just a wiki table, manually maintained by participants of the Ships WikiProject.
Obviously this data would be more valuable if it was structured in a way that allowed queries to be made against it. Base-like attributes provide a way of doing this.
There's definitely a trend towards this kind of loose data model at the moment. JotSpot allows all pages within a wiki to have as many extra name/value attribute pairs as you like (even the wiki body itself is internally implemented as a special attribute), and Ning works along similar lines.
Base currently allows bulk importing of data using tab delimited files, RSS or Atom. There are no outward bound APIs which is a notable omission - I wouldn't be at all surprised to see them added in the next few weeks.
I had a call on my mobile earlier today from a lady claiming to be from Orange (my phone service provider) who told me that my contract was about to expire. She asked me for my password.
Alarm bells instantly went off in my head, so I told her (truthfully as it happens) that I didn't know my password. Then she asked for my postcode instead.
At this point I was pretty sure this was a social engineering attack, so I started to quiz her about why she needed the information. She said it was for a "security check". I told her I was uncomfortable giving out information like this to a cold caller over the phone and she said it was nothing to worry about because it was all covered by "the data protection act".
I said that I would rather conduct my business in an Orange shop, and she told me that she would have to put a mark on my record that I had failed a security check. I interpreted this as a threat, which convinced me that the call was an attempted con. I asked for her name and ended the call.
I e-mailed Orange customer support via their website with details of the call and the number it came from (07973 100 194, which looked like a mobile number to me and had further fuelled my suspicions). I just received their reply - the call really was from them!
Banks and other online services have learnt to repeatedly tell their customers that they will never contact them and ask for their password. Orange are leaving themselves wide open to social engineering attacks. This incredible lack of attention to basic security has given me serious second thoughts about trusting them with my business at all.