I posted previously at how much I really like their album. I just wanted to say that nothing has changed and infact, I probably like it that little bit more!

Gameplay have always guaranteed that if you order in time they will get you a game on day of release. This is cool as it means you a) get a better price, b) get the game delivered to you c) you don’t need to wait until after work to go fetch it. Sometimes however the games will arrive a little earlier (especially if you pay for first class delivery). Super Mario Galaxy did exactly that. Release? Tomorrow. Arrived? Today! Get in!

I’d put this under “It’s funny. Laugh.” but I think it is better suited under “Oh Christ. This is the actual society I live in.” category.

The Register Reports.

At the moment with work I am refactoring webframework to provide a better layer to, in turn, upgrade and re-engineer an existing platform. Part of this work is to provide an AJAX layer because everyone loves AJAX. The advantage of the approach I am using is that it becomes very easy to use AJAX with components and custom scripted actions. The details are for another day, but I did stumble across an odd behaviour which I wanted to detail here.

This concerns ordering of code, the submission of an AJAX request and the way AJAX responses are handled.

My code was originally structured as follows (and works correctly in Safari):

function doAJAXRequest() {
    Setup AJAX Request
    Post AJAX Request
    Setup Callbacks Relating To Request
    Setup visual indicators
}

The effect is that the request is built, sent and whilst waiting for a response I setup some parts that would be needed upon return of the request as well as a visual indicator that a request had been sent. This works with Safari but not Firefox on fast connections. If the request is processed quickly, the response is processed within the onchange handler for the AJAX object before the visual indicator has been shown, or some extra callbacks setup, which in turns causes all manner of errors. I think this is because the onchange can be called at anytime in Firefox (it will interrupt a running function), whereas Safari waits until the runtime has returned to its event loop (it wont interrupt a running function).

This difference in processing is subtle, and with carefully structured code should not arise on a common basis. I found the differences between the Javascript runtimes of Firefox and Safari different enough to warrant noting it on my site.

11:36 ctr: Hurrah
11:37 ctr: My new jacket arrived
11:39 ctr: It is a good thing that
11:39 ctr: I can now listen to music without fear of missing the postman
11:42 zuran_: good stuff… did you install a postman sensor at your door?
11:44 ctr: Yes, it is called a door bell.