The Jules Verne

The video of the re-entry of the cargo ship Jules Verne into the atmosphere is quite spectacular. (If you don't know, the Jules Verne took supplies up to a space station, stayed docked for a while, and was then packed full of rubbish and set off on a trajectory that ensured it would burn up during reentry thus disposing of both itself and all the rubbish.) It looked, of course, like a rather large meteorite burning up in the same manner. There's something very pretty about such fireworks, even if you know that it's "really" just incinerating rubbish. It's the distance I suppose.

What really interested me though was reading that the crew of the space station had found the Jules Verne, while it was docked, to be a nice, quiet place to go and spend some free time. Some of them even chose to sleep there.

Excuse me? They went to sleep in a vehicle that they knew was going to undock, blast off, fall hundreds of miles while burning up and finally explode in a million fiery pieces? I know that the moment I fell asleep there the nightmare would start. The clang of the airlock shutting, locking. The hiss and rattle of the couplings disconnecting. The roar of the engines that, curiously, wouldn't be enough to wake me up... Astronauts it seems, are made of sterner stuff.

The Hand that throws the dice :)

Reading Richard's latest post, I eventually stumble upon his reading list for the 9th September. A little way down I find Ian Stewart's Does God play Dice with its reference to Einstein's famous statement that he didn't believe that God played dice with the universe, and suddenly realise what's been troubling me about that remark ever since the first time I heard it.

Which is that, in classical mechanics at least, throwing dice gives you a perfectly causal and non-random result!

Interesting Google Reader behaviour

Quite a while back I decided to try to drum up some page rank for wow.gedsguides.com by creating a few blogs. Whenever one of my characters completed an interesting quest, or quest line, as well as updating gedsguides.com I would write about it in that character's blog. The end result of course, as any seasoned blogger could have told me, was four blogs that weren't updated frequently enough to be interesting, and that still didn't cover all the WoW characters I've got.

So I've decided to amalgamate all these blogs into one new blog — the hard way. Instead of spending a couple of hours tediously cutting and pasting from one window to another, and then fiddling with the settings of each post to faithfully reproduce the date of the original, I'm going to spend a couple of days writing a python script to do the same thing programmatically.

Of course, the real objective is to kill two birds with one stone and to improve my still extremely sketchy knowledge of Python. That will then feed back into useful skills should I eventually decide to Django-ise gedsguides.com, as I'm still thinking about doing, and also for anything I might do with Google App Engine.

Anyway, along the way, I saved the xml data feed that the script was getting back from the Blogger API, and looked at it in a browser. Lots of guff, lots of urls. One url being an Atom feed of the list of all (that is, all four of) the blogs belonging to the account that I set up to publish them.

So I rather naively took that url off to Google Reader and plugged it into the Add Subscription box. I suppose I vaguely thought that Google Reader might be clever enough to add the Atom or RSS feeds for all four of those blogs at once.

Instead, it simple-mindedly read the Atom feed, containing brief descriptions of the blogs taken from their settings, and presented that as its list of "new postings".

OK, so it wasn't as clever as I thought, and I reached for the Delete button to remove the feed. But wait! I'd been thinking of Google Reader as a blog / news reader. What it really is, is a vehicle for presenting any old Atom / RSS feed!

Well I knew that Google Calendar presents an XML feed, so I copied the feed url and tried adding it as a subscription in Google Reader. Success! Seconds later I was reading my calendar entries in Google Reader!

I wonder what else you could munge into an Atom publishing format and usefully view using Google Reader? I was thinking you could use it as a cheap workflow engine: someone could subscribe to an intranet url that gave them their to-do list for the day. Of course, the rather limited list of actions that you can do using Google Reader might not suit everything: you can jump to the posting's url or open it in a new tab or window, and you can mark the posting as read. Still...

If you could take an Atom feed from forum software, say for a partiular forum, or for a particular thread that you were interested in within that forum, then you could browse new postings in Google Reader.

A few years ago I worked with a crude kind of laboratory automation software at a pharmaceutical company. If you had a bioreactor chugging away, say, under program control, that program could expose an Atom feed with a new post every time it passed a particular milestone (sterilisation, cooling, adding medium, adding nutrients, adding organism) and you could check on the progress of your culture at the same time as browsing Slashdot :)))

Django - first data!

With Django installed it was a question of seeing if I could get data out of the wow.gedsguides.com database. So I munged the table definition parts of my database build (structure) script, create.sql, into a Django-style model definition in a new model.py. OK, so I only did two of the tables, but it's the thought that counts.

Then just a matter of validating the models using Django's built-in manage.py tool, and once I'd fixed a couple of newbie bugs I looked at the generated sql, and it was certainly close enough to the original DDL in create.sql for me to be confident that the Django models were going to work with the existing database just fine.

Then it was time to go into the webmin interface of the new (soon-to-be-migrated-to) virtual server running on a box in jsp-servlet.net's data centre somewhere in San Francisco and tell postgres to let my home PC connect to the database.

Then an SSH session into the same virtual server, to run the actual database creation script — my original create.sql, naturally. I wasn't going to run the Django one for the pretty obvious reason that other applications have to be able to work with this database, so Django just can't be the lord and master there.

Once that was all done I tested connection from my home PC to the remote database by running pgAdmin III and that was fine, so I edited my new Django app's settings to tell it how to connect up, and then it was time to go into manage.py's interactive shell and start instantiating database objects:

>>> from ggw.admin.models import Stages
>>> qs = Stages.objects.all()
>>> print [p.name for p in qs]
[u'Stub', u'Notes', u'Rough draft', u'Final draft', u'Complete']
>>> print [p.id for p in qs]
[10, 25, 50, 75, 99]

Tomorrow I'll look at what it's come up with in the way of an automatically generated admin interface, and at that point I'll know whether I want to proceed or not.

Some things do stand out though. The rather ad-hoc nature of Django's query filter language being one. I don't know, it may be modelled on some absolutely standard object query language (I don't like them either) but it seems to have had to replicate, in an amazingly clunky and obtuse way, what you get as a nice, clear syntax in SQL itself. For example, I don't know how anyone can think that a where-clause expressed like this:

Entry.objects.filter(pub_date__lte='2006-01-01')

is an improvement on one expressed like this:

SELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';

"Publication date less than or equal to equals some date" ... I don't know — how do you read that in a way that doesn't insult your linguistic sensibility? But obviously it's what you have to do when you have all that enormous object-relational machinery in the way. (It reminds me of the old saw about all applications evolving until they include a complete lisp interpreter, implemented very badly.)

---

Update: Sheesh, them thar interwebs are humbling things: no sooner do I write my half-baked objections in the last few paragraphs above, than I stumble — from a completely different direction — on someone making exactly the same point, a hundred times better, in a different-but-comparable context.

Moving to Django

Well wow.gedsguides.com needs a bit of t.l.c. — a facelift and some new functionality. And rather than plod through acres of Java code (and, IMHO, now that everything is supposed to be done via annotations it's actually more error-prone rather than less) I'm looking at Django to do the business.

Mostly I like what I see. The Django developers seem to be a pretty smart bunch, and if they've had to balance power, flexibility, economy and expressivity they seem to have got a very good bargain.

So there's just a few things I don't like. Number one (and I won't bother about the rest) is syncdb. I want to design my database first, and then have the ORM layer work with that. I don't want to design the object layer first and then have the database constructed from it automatically. I suppose I'm showing my age, swimming against the tide of history, etc. etc. And to a degree, it's a bit cheeky of me to expect to be able to use an ORM approach like Django's without having to pay the price.

Still, so far I've only installed Django and worked through the tutorial. I've yet to read the reference documentation for the models module(s). It may be that you can finesse the default behaviour, I hope so — and the flexibility and customisability I've seen in the rest of Django certainly gives me cause to hope; it would be a shame if it was completely hard wired in this one area.

I'll look at Djangoising the admin interface first. Since it's a completely separate application, I can do it in Django while leaving the public site still running with servlets/jsps. And I get the benefit that all I have to do is define the models and Django will generate an automatic admin interface for me — that's very attractive! (Subject to the proviso above, of course.)

And when and if the time comes to deploy it, I can even do it in baby steps, by simulating python/Django on the java server with the magic of jython: Deploying Django/Jython Projects on a J2EE App Server.

Google Chrome - what, no coffee?

Well it was here when they said it would be, and I downloaded it. It installed, and crashed at the last minute when the browser had just started up and was importing settings and bookmarks from IE and Firefox, and it looked like it was the bookmarks that were responsible.

But, just like it says on the box, only the tab that was doing the imports fell over, and I was able to carry on and start browsing the web immediately. Later, I went to the options menu and got it to load the bookmarks again, and this time it completed without incident. So score +1 for Chrome.

So what about this blazingly fast Javascript engine then? I've deliberately refrained from running any official tests, on account of being lazy, but just let's say that I'm once again impressed at just how important network and server latency are in the browser experience. That is to say, working with Gmail and Google Reader, sure it seemed a little bit faster at opening the pages, but even in these Javascript-heavy apps, it's the I/O that's the bottleneck.

I decided to look at plugin support. Flash/Flex is there as you might expect (what with having to support YouTube and all!) but, very surprisingly, Java was absent. I managed to find some pages with applets on by going to the Sun website (what a blast from the past!) and got a message saying "No plug-in available to display this content". Here's one of the pages I tried, see what you get.

At first I was a little staggered. Could the status of Java applets have fallen so low that Google weren't even going to bother supporting Java in the browser? (And see here for what I found out about current antipathy to Java in the browser.) Well yes it could, I suppose. Maybe Google have simply concluded that Java in the browser has had its day.

I expect though that the explanation is simpler: Chrome is a beta after all, and there's no compelling need for Google to support applets from day one in the same way that YouTube makes it necessary for them to support Flash. Also maybe something technical about the way the JRE integrates with the browser makes it harder to support than Flash? Maybe. But Safari 3.1.2 (as kindly downloaded for me by iTunes when I wasn't paying attention during a product update) seems to have managed it without any problem. Hmm, this smells kinda bad, kinda fishy...

Of course, Google have got a JVM of their own though, haven't they? Maybe instead of incorporating the Sun product, they'll simply port Dalvik to run inside Chrome? That would unify two of their platforms very nicely indeed, thank you. Android games running in Chrome tabs? I'll have some of that!

If I were Google though, I keep it very quiet if that was indeed my plan, since it would undoubtedly cause a massive outcry (assuming anyone still cares, which is moot, but I bet a lot of people who didn't really care would still enjoy complaining for its own sake). In fact, the best way to do it might be to release Chrome without any Java support at all, and wait for annoyed voices to demand it, and then say something like "Well licensing restrictions mean we can't support yer actual Sun Java in Chrome, but we got something 'ere that's just as good, honest guv'nor."

---

Update: OK, panic over, Chrome does support Java! You just have to have the absolute latest, bleeding edge development release, version 6 update 10. If you click on the toolbar menu and then on the Help submenu it'll take you to a page where you can search for Java support, and that'll take you to a page where they explain what's going on. Or just take my word for it and go to http://java.sun.com/javase/downloads/ea.jsp and download and install Java SE 6 Update 10. Phew!

Still think Android apps in Chrome would be a great idea though.

Google Chrome. OH. MY. GOD.

Apologies for the quality of this post. There's so much to say and my thought processes are just running all over the place as various connections are being made. I've just read about Google's new Chrome web browser tonight, it's all over the web.

My first reaction was, "How odd!" Why would Google want to bring out a new browser? There are new browsers appearing all the time, and it would be much more in keeping with G's modus operandi to date for them to simply help out with advice, code and a bit of cash here and there, rather than to up-end the whole apple-cart like this.

Then I read the 38-page cartoon that they sent out explaining things. And my second reaction was, "Oh. My. God."

It seems obvious now that development of current browsers was either not going in the right direction for Google, or just wasn't getting there fast enough. Things are scrappy. They're fragmented. Google have big plans for the browser, and it looks like they've decided to start bringing all the strands of their work together, so that we can begin to see the shape of what's coming.

Strands? Heck, let's change metaphor. It's like when the tide starts to come in on a nice warm beach. At first all you can see is tiny rivulets of water coming from all directions and going in all directions. It's only later you realise that THE SEA is on its way and your little spot in the sun is soon going to be under six feet of water (and yes, Microsoft, it is you on that towel).

So they've made all these little moves. And they looked a bit odd and a bit disconnected. Google Apps — a bit slow, a bit underpowered, but they would be see, 'cos they're running in a browser. GWT — what's the point of a development environment that has you writing web apps like they were desktop apps? Gmail — nice example of what you can do with Ajax, was it written using GWT? Android — what browser does it use?

But now Google are bringing out Chrome, whose intent seems to be to run applications as complicated as the most complicated ones that you run natively on your operating system, and to run them just as fast (or at least, in the same ball-park). Hmm, Google Apps, they're going to be a bit snappier now, aren't they? Hmm, I can see the point of a big-iron development environment based on a typed language now! And Android, currently sporting the browser that Chrome is based on, will likely be running Chrome or a Chrome-alike in the next release (after the one that we still haven't had yet).

That's enough hot air and pontificating. The rest of this post is specific reactions to things in the cartoon, which you may not understand unless you follow the link above and read the cartoon.

---

They are using the Webkit code base. Not Mozilla. By my reckoning that's now about a million billion important new browsers have been built on webkit, versus ... erm ... (I can't think of any) built on the Mozilla codebase. OK, so I'm using "important" in a very particular sense: "big", that is to say, backed by an organisation (probably a commercial company) and guaranteed a large user base. (And I know that there are lots of browsers based on Mozilla, but together they must have a user base approaching, what, 10,000 people?) [Yes, other than Mozilla itself and Firefox.]

Mozilla are #?*&ed! Now the flow of money from Google to the Mozilla foundation is not charity, it's a deal whereby Mozilla preferentially funnels its searches to Google. So that can stay in place. As long as Mozilla users search on Google, Mozilla can get money out of that deal, there's no sense in Google just killing it. So Mozilla is not #?*&ed immediately then, but stand by to see it lose market share vertiginously if Chrome is as good as Google thinks it's going to be.

Stand by also to see Microsoft scramble to match Chrome in terms of features. This comes at a particularly bad time for Microsoft, with IE 8 code very likely closed to new functionality, and the release only a few months away [GOOGLE SMACKS MICROSOFT, #1]. What do MS do now? Do they stick to the original release timeframe and release it as-is, and smart when nobody notices because Google released a better browser a few months back [and that's TOMORROW folks!] and everybody's using it? Or do they pull the release and desperately try to match Chrome, feature for feature?

Omnibox. I can see this running into trouble very quickly. This business of remembering what site-based search boxes you've used, and allowing you to reuse them by typing in a site identifier and then a tab and then your search terms? Think of the controversy caused by deep linking a few years back. This is an excellent way to cut a website's search page out of the loop. So now, instead of first going to Amazon's home page and having to skim over all the stuff they've kindly prioritised for you as your eye hunts for their search box, you'll go straight to their results page. Hmm. Site publishers are going to regard this as kidnapping their search boxes, and I would be surprised if there weren't a few legal challenges to it soon.

Interesting to see the places in the cartoon where they have obviously decided to put the wind up the competition. Some of them really made me chuckle.

On page 4 they say that each tab is a separate OS process. If memory serves, Unix/Linux processes used to be lighter weight than Windows ones. Assuming that's still the case, Chrome may be a bit sprightlier and more performant on Linux than on Windows [GOOGLE SMACKS MICROSOFT, #2] — just the thing for those Linux-powered net-tops that are springing up all over the place.

On page 5 they point out that this means that the sort of badly-behaved page that used to make your entire browser crash will now only affect the one tab. This must happen to me about once a day at least: four separate browser windows open, themed for work-related stuff (several pages of documentation from assorted sites), news (Google Reader for scanning, then I open up any interesting stories in their own tabs), mail, and one for anything else; that's twenty or thirty pages all open at once, some of them regularly updating in the background. When a bad page takes down that lot it's annoying and I thank heaven for Firefox's auto-reopen feature. When the bad page is really bad, and Firefox goes down again straight away as soon as it tries to reopen it, that's when I get annoyed.

Pages 9-11 must be putting the fear of God into Microsoft right now. Google are showing off how they can push automated Chrome testing out over their famous distributed server network, testing tens of thousands of web pages per hour [GOOGLE SMACKS MICROSOFT, #3] and making sure that they cover them in order of importance, as indicated by their very own page ranking alogrithm.

Page 13 is very interesting. They mention no names, but I immediately thought of Adobe's Tamarin VM for Javascript, now donated to Apache. Were they thinking of Tamarin? Did they look at it and reject it, or was it not open source back when they decided to write one themselves? I need to look at the timescale for that more carefully. One thing: Tamarin is built for the version of Javascript that didn't make it into the new standard, and work is apparently under way at Apache to convert it for the version that did. Good luck with that. Google probably thought it was better to start from scratch [GOOGLE SMACKS ADOBE]. And if the boys that did the new Javascript VM are more or less the same ones that did the Dalvik VM for Android, then Google probably thinks it can do a damn good job on its own, and rightly so.

Interesting also that they are seem to be JIT-compiling Javascript to machine code. That's been a perilous way to go in the past, partly because of what can happen with variables. Javascript variables are untyped, but the values that they hold do have types (number, string, object, ...). Now there's nothing to stop me coding a for-next loop where the value held in some variable used inside the loop changes type on each pass through, and in the past that's either killed efforts to compile Javascript or put serious constraints on the efficiency of the resulting code (by making it have to be too general).

In this context, it's especially interesting to look at the latest release of the Google Web Toolkit (GWT). GWT you will remember lets you write your web application in Java, a heavy-duty, strongly-typed language, which GWT then "compiles" to Javascript for actual execution in the web page. The release notes for the latest version of GWT noted that this "compilation" phase effectively throws away the valuable type information, in the transformation from typed Java to untyped Javascript, and that in previous releases this negatively impacted performance. But the current release takes advantage of the fact that any Javascript variable in a web page produced by GWT is guaranteed to have come from a typed Java variable! In other words, you can guarantee that that sort of type-bending naughtiness isn't going to happen in a respectable GWT application. So you can do type inference based on the first value of a variable that you see... And then the release notes said that that had led to sundry improvements that were beyond my understanding, because all I could think of was that Javascript was still untyped.

So what's the betting that GWT-produced web applications will run especially well in Chrome, because of the good behaviour of their variables (and, no doubt, for many other reasons way above my head)?

---

Michael Arrington at TechCrunch says:

Make no mistake. The cute comic book and the touchy-feely talk about user experience is little more than a coat of paint on top of a monumental hatred of Microsoft.

I hope this doesn't mean that MS have got so far under Google's skin that they are letting hatred guide their actions. That would be a colossal mistake. So far, Google have been the nimble players. They are the ones who, in every case [May not be true. I have a terrible memory!], have led the way with an unexpected paradigm-shift, leaving others scrambling to catch up. Letting Microsoft-hatred guide your actions is a mistake other companies have made in the past, and it's ruined them because it hands the initiative to MS, who are not slow to capitalise on the opportunity.

---

Update: Dave Methvin over at Information Week points to where Google may have got some of the technology they are using to sandbox Chrome tabs.