Yesterday I found out that Transport for Londonlifted all restrictions for commercial use of its data that it has made available for developers.

In lack of better imagination I decided to attack the Live Traffic Cameras data and whipped up this little app: tflcameras.peterbe.com

It basically shows a map of London and then shows all the spots where traffic cameras are installed so that you can click on them. The data is updated every 3 hours I think but I haven't checked that claim yet. Use this if you're a London commuter and want to check the traffic before you hit the road.

Oh, and this app uses the geo location stuff so that I know where to zoom in first. But if you're not based in London it zooms in over Trafalgar square by default.

I've learned a couple of things this week on deploying my first site to use a user friendly OpenID.

My first revelation was when I realized that Google and Yahoo! have solved the usability stumbling block that you can use them as providers without having to know a personally unique URL. For example, for Yahoo! it's just http://yahoo.com which means that you don't need to offer a cryptic URL form and you can just show it as a logo image.

The second thing is that Google's hybrid OpenID + OAuth isn't as complicated as it sounds. It's basically a light extension to the OpenID "protocol" whereby you say, "while you're at it, also give me a OAuth token please so that I can connect back into Google's services later". What's important to understand though is that if you use this you need to know the "scope". scope is a URL to a service. Google Docs is a service for example and you need to search the web to figure out what the scope URL is for that service.

The third revelation was when I understood the difference between Simple Registration Extension (SREG) and Attribute Exchange (AX). Basically, AX is a newer more modern alternative and SREG was the first one. AX is better but some OpenID providers don't yet support it. Google for example, only supports AX. Key to be able to support not just Google's OpenID but any OpenID is that you can request both AX and SREG and whichever one works will be returned.

The fourth thing that helped a lot to understand was the Google's OpenID has a bug in its implementation of Attribute Exchange. Actually, perhaps it's a deliberate design choice they've made but in my opinion a bad one. Unless you say you require email, firstname, lastname, country etc. it won't return it. If you use the if_available directive you won't get it. Another bug/bad design choice is that Google seems to not forward the country attribute. It can happily do first- and last name but not country even if the documentation claims so.

The fifth thing is that python-openid is a lot easier to work with than you think. You don't need to do any crazy network checks or callbacks. For initiating the challenge all you're effectively doing is creating a long URL. If you don't like the API methods python openid offers, just add your own with:

 redirect_url += '&openid.ax.mode=fetch_request' # etc.

After so many years since OpenID arrived, I'm only now excited about it. It's tonnes easier to implement than OAuth and now it's actually really pleasant to use as an end user.

I have a Zope web app that uses hand coded SQL (PostgreSQL) statements. Similar to the old PHP. My only excuse for not using an ORM was that this project started in 2005 and at the time SQLAlchemy seemed like a nerdy mess with more undocumented quirks than it was worth losing hair over.

Anyway, several statements use ILIKE to get around the problem of making things case insensitive. Something like the Django ORM uses UPPER to get around it. So I wonder how much the ILIKE statement slows down compared to UPPER and the indexed equal operator. Obviously, neither ILIKE or UPPER can use an index.

Long story short, here are the numbers for selecting on about 10,000 index records:

 # ONE
 EXPLAIN ANALYZE SELECT ... FROM ... WHERE name = 'Abbaye';
 Average: 0.14 milliseconds

 # TWO
 EXPLAIN ANALYZE SELECT ... FROM ... WHERE  UPPER(name::text) = UPPER('Abbaye');
 Average: 18.89 milliseconds

 # THREE
 EXPLAIN ANALYZE SELECT ... FROM ... WHERE  name ILIKE 'Abbaye';
 Average: 24.63 milliseconds

First of all, the conclusion is to use UPPER instead of ILIKE if you don't need to do regular expressions. Secondly, if at all possible try to use the equal operator first and foremost and only reside on the case insensitive one if you really need to.

Lastly, in PostgreSQL is there a quick and easy to use drop in alternative to make an equality operatorish thing for varchars that are case insensitive?

A friend of mine found a nice car she on www.enterprisecarsales.com so she copied the current URL from the address bar and emailed that to me. The URL was: http://www.enterprisecarsales.com/carsales/vehicleDetails.do?carIndex=1&vin=1GCHC24U36E112452 which by the look of it (notice the /vehicleDetails.do part of the URL) takes you to a page that says "Sorry, we are unable to complete your page request since the page you are trying to access no longer is available." How stupid is that? Come on, web developers made those kind of mistakes in 2001. Not 2010.

This means that people can't talk to each other about found matches on the site and this is something people want to do. Especially if you're going to spend $thousands on a car.

Come on Enterprise web team: install Django or something and give users what they want not your excuses.

Check out these all free icons

If you, like me, have various projects that do things like OAuth on Twitter or Google or you have a development site that goes to PayPal. So you're doing some Django development on http://localhost:8000/foo and click, for example, to do an OAuth on Twitter with an app you have there. Then Twitter will redirect you back to the live site with which you've set it up. But you're doing local development so you want to go back to http://localhost:8080/... instead.

Add this bookmarklet: to localhost:8000 to your browser Bookmarks toolbar and it does exactly that.

Here's its code in more verbose form:

Bruno Renié has written a nifty app:iPhone push notifications for Twitter with Prowl

With the power of Prowl it pushes a notification to your iPhone when someone mentions you on Twitter. You first need to install the Prowl app on your iPhone and then go to their website to get your notification key. Then, go to Bruno's site, sign in with your Twitter account (OAuth, so no password give-away) and badabing! you get instant notifications on your phone, for free, when someone mentions you.

If you're one of those people who use Twitter instead of instant messaging and have lots of mentions this might be excessive for you but if not it can be very useful if you are like me who is very slow to spot that someone has replied or mentioned your name.

Great work Bruno!

When you enable TinyMCE you can either choose theme="simple" or theme="advanced". If you go for the simple you get one lovely little bar of buttons but it's missing the link button which is more important than most other buttons altogether. When you enable "advanced" you get three rows of buttons that makes you dizzy. I mean, should really be editing advanced tables in a WYSIWYG editor or mathematical equations?

Here's a config that I think works great. It's all in one row and it's got the bare minimum in terms of additional plugins (no extra downloads required). It's in Python but translates quite easily into Javascript:

"SEO is not about creating a website sausage overstuffed with key words and phrases. It’s all about creating relevant and compelling content that transforms you into a thought leader who can become a trusted provider That is ultimately how you convert visitors into buyers"

I have now made the menu images on this site into a CSS sprite. Basically, instead of loading 6 different images totaling 10Kb it now only needs 1 image which is 7Kb! The difference in filesize isn't the big win here but the reduced number of requests is the big deal.

The number one tip from the Yahoo! Performance people is reducing the number of requests and this is what I've done.

To generate the sprite image I use the CSS Sprite Generator and then fiddled it a bit to make it work for this site. Thanks guys!

The major drawbacks of CSS Sprite images isn't really technical but it's just that it's an optimization hack. The next time I need to change any of the images I have to reapply the hack and there's a risk that by the time I need to get back into it I will have forgotten how to do it or where to go to do it. Anyway, I'm really pleased with the performance of this site now.

Uploadify is a great tool. I'm using it so that people can mass upload photos for a photo gallery app I'm working on. This afternoon I've spent about 3-4 hours trying to get it to work on Windows (IE, Chrome, Firefox). It wasn't easy but I think I got it working in the end.

Pitfall no 1 (easy)

The Javascript code that "wraps" the "uploader.swf" had a bug in how it calculated the installed Flash version in IE (only tested in IE6). So I fixed that and will shortly send a patch to the uploadify.com.

Pitfall no 2 (hard)

I've got nginx on the server passing requests to a Django daemon via FCGI. For some obscure reason, on Windows, if the file uploader.swf was served as a static file directly from nginx it wouldn't work and I would get 403 errors that are never explained in the nginx error log or anything. So I changed it to let Django serve up the uploader.swf file which obviously sets headers differently and then it worked.

Headers when served directly by nginx:

 HTTP/1.1 200 OK
 Server: nginx/0.6.34
 Date: Fri, 17 Jul 2009 17:01:09 GMT
 Content-Type: application/x-shockwave-flash
 Content-Length: 18659
 Last-Modified: Wed, 08 Jul 2009 12:29:52 GMT
 Connection: keep-alive
 Accept-Ranges: bytes

Headers when served from Django (django.views.static.serve):

 HTTP/1.1 200 OK
 Server: nginx/0.6.34
 Date: Fri, 17 Jul 2009 17:01:03 GMT
 Content-Type: application/x-shockwave-flash
 Connection: keep-alive
 Last-Modified: Wed, 08 Jul 2009 12:29:52 GMT
 Content-Length: 18659
 Vary: Cookie

Pitfall no 3 (super complex)

It was working in Firefox Linux, Safari Mac, Firefox Mac but not IE6 Windows, Firefox Windows or Chrome Windows. This despite having the latest (and same as Linux) version of Flash (10.0.22.x)!

Solution: In Internet Explorer, click on Options and delete the cookies, temporary Internet files and Clear History (for good measure). Now it works!!

It's been a hell of a journey but now it's crossed. Let's hope I can save some other poor sucker a couple of hours by making this blog available.

UPDATE

ow it's stopped working again. Works in Opera Windows but not IE 8 in windows 7. Grr...!

UPDATE 2

I've completely abandoned Uploadify now and instead gone for Swfupload which actually works really well.

My crossword solving website Crosstips now has a cute little chart in the lower right hand corner. It's a sparkline. The line indicates how many searches have been done in the current month. The screenshot was taken on the 28th of April so it's the searches done in April and it's near the right hand side which is the maximum.

These charts are made with Google Chart which is something I've never had the great opportunity to try before.

Making the chart was quite a pleasure actually. I had it up and running within minutes just my looking at some examples. The lib I used to make it happen was pygooglechart which was, despite its lack of documentation, really easy to use.

How useful this sparkline is to the people who try to get unstuck on their crosswords I really don't know but it sure looks cool.

I don't have any stats to back this up but if I look around the office almost a lot of people use Gmail or Hotmail or something web based. My family uses Gmail, Yahoo mail and Hotmail (and me on Gmail) for example. So it bugs me when websites use the mailto: thing. Especially if they rely on the Subject line.

Here for example, on the EDF Energy Contact us page, they have a long list of "Email us" links. They're almost all going to mailto:customer_correspondence@edfenergy.com but all with a different subject line:

 mailto:customer_correspondence@edfenergy.com?subject=Dual Fuel enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Dual Fuel sales enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Energy efficiency enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Priority Services enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Electricity prepayment enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Gas prepayment enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Home movers enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Green Tariff enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Meter Reading enquiry
 mailto:customer_correspondence@edfenergy.com?subject=Bill payment enquiry
 mailto:myaccount@edfenergy.com?subject=MyAccount query
 ...

Does that mean that I have to somehow copy the Subject line from each so that my email gets routed to the right department? I just don't know. Why can't they have different email address for each thing or a web form where I can email them there and then?

Using mailto: should be done very sparingly. Considering that most people (like my mom) don't know to right-click and select "Copy email address" I prefer this way to show an email address:

 <a href="mailto:more@userfriendly.com">more@userfriendly.com</a>

I've got a public ical at: http://m.fwckungfu.com/calendar.ics

This works in Google Calendar and in the iCalendar Validator but when I try to import this as a file in Apple iCal I get this message:

"Error subscribing to the calendar

Data downloaded from http://m.fwckungfu.com/calendar is not valid."

WTF? Who's ass have I not kissed to get this working in Apple iCal? Does anybody know any reason why Apple iCal is being so trixy?

I've now made a simple interface alternative (not AJAX) to Crosstips. This one doesn't do any fancy AJAX to look up works and you just type in the unknown letters as a space (or a _ or a . or a *) so you don't have to know how many letters it is.

Here's an example

It feels refreshing somehow to go back from AJAX back to plain old GET requests. The best thing about this is that it will work on a mobile phone too. The way I've wired the page is so that if you visit the site with a mobile device (not an iPhone though) it will load the extremely cut down version of the layout which is more suitable for mobile phones. This means that people will be able to get unstuck doing crosswords in bed.

I'm pretty damn sure I won't pay to see this movie in the cinema. I'm pretty sure I won't want to download it illegally and watch it either. But I have to admit this is a pretty awesome way to show the trailer.

Just watch it and you'll see what I mean.

My play site Crosstips.org is available in British English and American English. Obviously the difference is small but it's important.

What I've done is that if you're located in, say, France and visit the site it offers you the following language choices:

• Svenska [goes to krysstips.se]
• English (GB) [goes to en-gb.crosstips.org]
• English (US) [goes to en-us.crosstips.org]

But if you're located in, say, England it only offers you the following language choices:

• Svenska [goes to krysstips.se]
• English [goes to en-gb.crosstips.org]

And likewise, if you visit the site from US computer you just get two options and it uses the en-us.crosstips.org domain. As an American or a Brit why would you be interested in the other English? I think this is a really good usability trick. It reduces the noise by removing options.

There's a new restaurant on my street called The Albion. I went there for lunch today and had the steak and kidney pie with bread. It's a proper restaurant so including tip it came to £11 with tap water. Not cheap but the service was good and the food was really great. They've got a great delicatessen section with the usual tins of overly prices Italian olives and organic vegetables and yummy desserts.

Now, this blog is not a restaurant review blog but rather a (web) technical one. What strikes me is that these guys don't have a website! How can you not have that these days? Or perhaps they do but I just can't find it anywhere on Google. There's a Albion London advertising agency a stone throw from the restaurant and there's a The Albion in Islington but no Albion restaurant in Shoreditch London on Google.

If you're going to spend thousands of pounds on a nice chairs and lamps, like this restaurant clearly has done, then why not spend a couple of pennies on SEO and getting a decent website. Granted, it's a new restaurant but it only takes Google a couple of weeks to review its indexes. Come on my-new-favorite-restaurant-around-the-corner!

I actually don't mind a bit of adverts on websites but sometimes it just gets too much. On this page I couldn't even read the text since as I scroll down the huge ad over the text scrolls with the page.

Feels greedy like they've just thrown more and more ads in without thinking about the original design.

When V8 was announced to the world jointly with the launch of Google Chrome there was a lot of buzz about how fast it was.

Then, the guru of Javascript, John Resig couldn't hold back his announcement about Tracemonkey and how it was faster than V8

Now there's a third one that apparently beats them all: SquirrelFish Extreme

"As you can see, SquirrelFish Extreme is 36% faster than V8, and 55% faster than TraceMonkey."

Personally I take all of these things with a shovel of salt since what matters isn't how fast it can compute raw Javascript code but how well it all works together with the browser and the browser's graphic routines and stuff and most importantly how the DOM tree is updated by the Javascript instructions.

Closing note; the most important thing is that there's something happening and this will mean that Javascript becomes more and more reliable for web developers and not just reliable but also faster so apps like Google spreadsheet might one day become usable. To quote John Resig on his closing notes:

"I fully expect to see more, massive, projects being written in JavaScript. Projects that expect the performance gains that we're starting to see. Applications that are number-heavy (like image manipulation) or object-heavy (like relational object structures)."