The Wayback Machine - https://web.archive.org/all/20061016081933/http://simon.incutio.com/
I'm a big fan of JSON, and it's great to see it turning up as an output option for so many Web APIs. Unfortunately, many of these APIs are getting the details slightly wrong and in doing so are producing invalid JSON.
JSON isn't just the object-literal syntax of JavaScript; it's a very tightly defined subset of that syntax. The site has a spec (illustrated with pretty state machine diagrams) and there's an RFC as well.
By far the most common error I've encountered relates to object keys. In JSON (unlike in JavaScript) these MUST be double-quoted strings. In fact, ALL strings in JSON must be enclosed in double quotes (JavaScript also allows single quotes; JSON does not).
Valid:
{ "name": "Simon" }
Invalid:
{ name: "Simon" }
{ 'name': "Simon" }
{ "name": 'Simon' }
It's worth reviewing the other key differences between JSON and JavaScript. Remember, all valid JSON is valid JavaScript but the opposite is not true; JSON is a subset.
This stuff matters. Python's excellent simplejson module is a strict parser; it refuses to consume invalid JSON. If you're building a JSON API it's worth taking the time to ensure you are valid - I suggest installing Python and simplejson and trying the following:
$ python
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
>>> import urllib, simplejson
>>> url = "http://your-api.org/your-api/json"
>>> simplejson.load(urllib.urlopen(url))
Try it against a few JSON supporting sites. You might be surprised at the amount of invalid JSON out there.
As with outputting XML, the best way to avoid these problems is to use a pre-existing JSON generation library rather than rolling your own. I've had good experiences with simplejson for Python and php-json for PHP.
Wow, I've had a really busy month. I've attended (and spoken at) BarCamp London, Media in Transition, d.Construct, RailsConf Europe, Euro Foo and EuroOSCON. All were excellent, and each one nicely complemented the others. I'm exhausted. I think my brain is full.
My favourite question to ask new people I meet at conferences is "what are you excited about?". It's better than "what do you do?" (their job might not be as exciting as what they do in their spare time) and often gets a really interesting reply. People often ask me the same back, so here are three things that have been catching my attention recently.
OpenID. It's criminal that so few people are playing with this. I gave talks about it at both BarCamp and Euro Foo - it's decentralised single sign-on that works, and it's trivial to implement thanks to really solid libraries for most programming languages. There's also a $5,000 bounty to help spur adoption. I'll be writing a lot more about this in the future.
Virtualization. This was a common thread at several conferences, and the recent popularity of Parallels for browser testing barely scratches the surface. Virtual servers have a bunch of advantages over physical servers: you can clone them instantly, you can migrate them between machines (while they are still running if you're using Xen) and Amazon's EC2 offers utility computing on an enormous scale.
Dynamic languages on virtual machines. IronPython 1.0 is out, Sun have hired the JRuby guys. It looks like dynamic languages are finally being taken seriously as useful and powerful alternatives to C# and Java. Programmers on those VMs get more productive languages, while users of those languages gain access to enormous existing class libraries, not to mention the promise of significant performance boosts.
Finally, since I've blogged the last two releases of Python I can't resist saying a few things about the new Python 2.5. It's all good, but the stuff that really stands out is the addition of sqlite3, ElementTree and ctypes to the standard library. Batteries included!
I recently had the opportunity to put together the Python Developer Center for the Yahoo! Developer Network. YDN is one of my favourite parts of Yahoo! so I jumped at the chance, and the resulting mini-site is now online (YDN blog post here).
The bulk of the content is the HOWTOs, which discuss ways of accessing Yahoo! APIs using Python:
I had a lot of fun playing around with different ways of accessing the APIs and working out which ones were the most natural fit. The HOWTOs use urllib, urllib2 and xml.dom.minidom from the standard library, but also discuss httplib2, ElementTree and simplejson as third party libraries that are worth investigating. Naturally, feedparser is the recommended tool for accessing Yahoo!'s multitude of RSS feeds.
Python really is a fantastic language for exploring web service APIs. All of the example code for the HOWTOs was first written in an interactive prompt and then copied to a file once it was working. Test-first development is certainly an important technique, but the power of interactive development should never be underestimated.
It's been a month and a half since I started using Opera 9, with a promise to report back later. I'm still using it, although some of the things I liked initially have faded while others have emerged.
Firstly, the ability to browse cached documents offline turned out to be a dud. The behaviour I was observing (where I could view pages from my cache while disconnected) was due to the following setting, in Preferences -> Advanced -> History:
As someone whose work involves making websites the idea of seeing stale documents for five hours is pretty horrifying, so I changed that to "check documents never" as soon as I saw it (I'm pretty confident that doesn't affect conditional-GET, which should work regardless). As soon as I did that I lost the ability to browse offline. Browser vendors take note: you can still be the first modern browser to implement a proper offline mode!
The disadvantage of changing those setting is that they can break JavaScript image preloaders, leading to an unsettling flicker when you mouse over some links. That's why I've left my image setting above to check every five minutes.
Despite losing offline browsing, other features have popped up that have kept me happy:
Opera is the only Mac browser I've used that includes a working full-screen mode; great for presentations.
Hitting space moves you down the height of the viewport, as with other browsers. Hitting space at the bottom of the page takes you to the next page in the 'sequence', if there is one. My first guess was that this used <link rel="next">, but it also works on Yahoo!, Technorati and Google search results pages which don't have those links. I suppose it's looking for any link on the page with 'Next' as the link text. Whatever it's doing, it works surprisingly well.
Site compatibility really is excellent; I run in to sites that don't work in Opera about as often as I do sites that don't work in Firefox. Part of that might be due to Opera's ingenious browser.js file, which includes Greasemonkey-style site-specific fixes and automatically updates itself once a week. Clever, but a bit scary at the same time.
The built-in IRC client is good as well - if it wasn't for Colloquy it would be my first choice for IRCing on the Mac.
Finally, Opera's low memory footprint continues to keep me from switching back to Safari or Firefox. My Mac (a two and a half year old PowerBook) is noticeably less sluggish now that those two applications have been relegated to JavaScript hacking (gotta love FireBug) and the occasional misbehaving site.
I haven't even touched Opera Mail yet, and the gadget support is something I played with once and never used again (but then I don't use Dashboard that much either).
Overall I'm extremely happy with Opera 9 and I'd recommend giving it a go - especially if you've tried and disliked an older version.
I attended two grassroots technology events in the past two weeks: LUG Radio Live 2006 and London Ask Later (previously known as Techa Kucha night, name changed after some emails from the holders of the UK Pecha Kucha trademark). Both were excellent events in their own right, and great examples of event organisation done on a small to non-existent budget.
LUG Radio Live
LUG Radio Live was held in Wolverhampton for the second year running, this time hosted by the Student Union. The event was twice the size of last year and will probably have to move to Birmingham in the future as Wolverhampton is running out of large enough venues.
This year there were around 400 attendees and the event was stretched out over two days. The venue was almost ideal: a good main stage, two separate rooms for "lightning talk" tracks (probably the wrong name for sessions that were generally half an hour long) and of course a well-stocked bar.
The event had a great speaker line-up, with keynotes from Mark Shuttleworth and Simon Phipps and talks from a varied assortment of free software hackers and tech enthusiasts. My personal highlights included Matthew Somerville's MySociety talk, which combined an overview of the team's projects (such as TheyWorkForYou and PledgeBank) with some behind-the-scene's anecdotes, and the Hour of Power which featured a sequence of cool lightning-talk style demos.
I gave a talk about Django, trying to concentrate on the open source community aspects as opposed to diving deep in to the code. I fluffed the timing a bit, but the talk seemed to go over well. A number of people I talked to were using Django for real-world projects, some of which should be showing up on DjangoPoweredSites in the near future.
The event cost just five pounds for both days, but despite the small budget nothing that mattered had been missed - the AV worked brilliantly and the talks ran almost precisely to schedule. The low-tech wiki (a hand-constructed blackboard) certainly brought out the creativity in the crowd. Definitely the best value conference with the most grassroots atmosphere that I've ever been to. I can't wait for next year.
Ask Later
Ask Later was a very different sort of event. It took place on a Tuesday evening at the New Cavendish campus of the University of Westminster (also the venue for the London Web Frameworks and JavaScript evenings) and consisted of a series of 6 minute 40 second presentations, each prepared in advance with 20 slides and 20 seconds for each slide. The slides were on automatic, so the presenters had to be able to time their talk precisely to match up with their slides.
Tom Carden has a list of the talks that were presented. The biggest crowd-pleaser was Matt Westcott, who described his attempt at writing a Sudoku solver in Ruby to tackle the Times' online competition. The solver itself was pretty straight foward; the hand-rolled OCR routine to deal with the Times' dodgy scanned JPEG a little less so. All of Matt's work ended up in vane when the Times stopped publishing the puzzle online just after his system started working.
Tom Armitage's talk was about how software should help people tell stories. It reminded me very much of Tabblo, the Django-powered photo sharing application that Ned Batchelder has been working on.
There was also a talk about levels of indirection from Jon Crowcroft, a lecturer at Cambridge. He mentioned in passing that two of his PHd students have written a full SSH implementation in OCaml, which is smaller and faster than the standard C version and is also provably correct. OCaml is a pure functional programming language with type inference, an object system and a strong collection of libraries. Another thing to keep an eye on.
The other talks covered a wide range of topics, and the standard was uniformly high. My own talk attempted to explain functional programming (including closures) in JavaScript. It went OK, but I really should have spent more time getting the slides right. Joel Spolksy's Can Your Programming Language Do This? is more of the kind of thing I was aiming for.
The only disappointment was the size of the audience. The talks really deserved to be seen by more people; if you weren't there you missed out on a treat. I imagine the main problem was the heat - sitting in a stuffy lecture theatre on a night like Tuesday's wasn't a hugely attractive proposition, but the talks were more than worth it.
The organisers have promised to run more events in the future, and hopefully positive word-of-mouth plus cooler weather will improve attendance for next time. You'd be crazy to miss it.
@media 2006 was a blast. Great talks, great people and some of the highest production values I've ever seen at a conference (check out the bags!).
I sat on the JavaScript Libraries: Friend or Foe? panel, with PPK, Dan Webb, Stuart Langridge and Cameron Adams chairing. It was my first participation in a panel and I really enjoyed it - I've always liked the Q&A bit of giving talks. JavaScript Libraries are an enormous topic but I felt we did them justice considering the time available. For the record, here are the key points that I wanted to get across:
Large JavaScript applications need some kind of library - even if it's one built especially for that application. There are a number of problems in JavaScript (most of them originating with browser incompatibilities) that any moderately complex application will need to deal with - things like normalised event handling, DOM node selection, sane animation or drag and drop. Solve these problems once so you can get on to the interesting task of building the application. If you can find a library that solves them for you so much the better!
The big four. Dojo, MochiKit, Prototype/Scriptaculous and the Yahoo! UI Library are the top of the pile as far as I'm concerned. They cover the bases effectively and each one offers something interesting that makes it worth studying in its own right. If you plan to evaluate some existing libraries these make an excellent starting point.
Leaky abstractions. Joel Spolsky's essay The Law of Leaky Abstractions is my favourite of all of his online articles. It's basic tenet is that abstractions that are designed to save the programmer time inevitably leak, and if they leak at a lower level of abstraction than the programmer is familiar with they prove almost impossible to debug. Paradoxically, the more time saving abstractions you are using the more you actually have to know.
JavaScript is possibly the leakiest abstraction of them all, thanks to the many different browser environments it runs in. If you rely on a library to abstract away the browser bugs from you you are certain to run in to a bug that you can't fix sooner or later. Don't use libraries as crutches; if you're not prepared to figure out what the library is doing for you you'll end up in a world of pain further down the line.
Community and documentation matter. As with all open-source software, it's a good idea to get a feel for the amount of community activity around a project before you commit to building on it. The big four all have active communities, which means less bugs, more support and a faster rate of improvement. Likewise, good documentation is invaluable.
Libraries should play well with others. Reusable code that excludes other code from being reused has severely limited long-term value. In JavaScript, that means that libraries that mess with Object.prototype or pollute global namespaces should be treated with caution. The Prototype library was a major culprit here, but thankfully has cleaned up its act (at least with regards to altering Object.prototype) in recent releases. It's all very well saying that you'll always be using code built with your core language modifications in mind, but you may well change your tune when you try to incorporate Yahoo! or Google Maps and everything breaks.
Go with the grain. If you take the time to learn it properly, JavaScript is a powerful and surprisingly elegant language. Good JavaScript code takes advantage of its dynamic, functional nature. Libraries that promise to take the pain out of JavaScript by writing the code for you probably aren't as smart as they seem. Abstractions leak.
Dan Webb has a good comparison of the big four on SitePoint, although he did overlook YUI's Animation library which I consider a highlight.
For more accurate coverage of the @media panel itself, take a look at my co-worker Paul Hammond's detailed notes.
