Tuesday, 23 September 2008

Neil Bartlett's OSGi book

Just found Neil Bartlett's OSGi book project:

"OSGi in Practice"

Looking good so far, but I've only skimmed the first couple of chapters.  I plan to read and contribute to the comments and bug-tracker. 

I don't think there is another good OSGi book out there yet, so this is potentially important. Great that Neil has decided to license the book under Creative Commons, too.  Like most folk, if the book is good then I'll buy a paper copy.



,

Friday, 19 September 2008

Ubiquity, and Contrasting Cultures

This is interesting: Mozilla Labs » Blog Archive » Introducing Ubiquity

Watch the video demonstration.  What a great idea, and I'm impressed by how well this appears to work even at the prototype stage. I'm going to install and try it.

But even if it turns out not to be so great an experience for me (demos always work perfectly, don't they?), that's not the point: what matters is that some bright people are doing interesting and worthwhile things and freely sharing the outcome with us, while Microsoft apparently spends its time (and some of its money mountain) on stuff like this.

Links to these two articles were close to each other (can't recall where) and I was so struck by the contrast and what it reveals of the cultural differences that I felt compelled to write this.

Monday, 15 September 2008

Rick Wright

BBC NEWS | Entertainment | Floyd founder Wright dies at 65

Such a shock to see this BBC news headline.  Like many of my generation (40-something), I regard The Dark Side of the Moon as the key soundtrack of my early life.  As a teenager I knew every word and every note of every song (probably still do) from an album I listened to endlessly back then, and have listened to on-and-off ever since. 

The first copy I had was a copy of a school-mate's album, on a C90 cassette.  I borrowed a typewriter to write out the lyrics.  Somewhere, in the bottom of a box, I probably still have those sheets of paper.  I wore out that tape.  Eventually I'd saved enough for my own copy, but (would you believe it) I lent the album to someone and never got it back.  But I'm sure I've got the posters, probably in the bottom of that same box, wherever it is.  It's just impossible to explain how important that music was.  It still affects me, even now.  It will always be my favourite album.  Bar none. Nothing can displace it, ever.

"I am not frightened of dying.
Anytime will do, I don't mind.
Why should I be frightened of dying?
There's no reason for it,
You've got to go sometime..."
(from The Great Gig in the Sky.  Rick Wright / Clare Torrey)

Google Protocol Buffers

The Protocol Buffers (PB) idea is obviously good from a performance point of view, but with so much messaging already defined in XSD, I want a tool which will generate the .proto file for a given XSD.  Does such a thing exist yet?  If not, it would make an interesting project. The obvious twin would be a library (linked to the generated .proto code) which accepts a DOM or a SAX stream and generates PB data - a kind of PB-adapter.

The value of protocol buffers is mostly in creating more compact representations on the wire, and speed in parsing/unparsing. But there's a lot of code out there already using XSD/XML internally which nobody wants to rewrite just to use PBs.  Would the cost of conversion to/from an in-memory DOM cancel-out the gains?

Friday, 12 September 2008

Generating PDF from XML with XSL-FO

One of the healthcare solutions I'm working on has to generate diagnostic report documents in a form we can distribute directly (e.g. secure email) to clinical staff. The diagnostic report text plus the usual patient demographics and such, arrives in a custom XML message from the integration engine. The solution uses HL7 v2 elsewhere, but the PAS messaging is exclusively via custom XML (not HL7 v3 XML).

The legacy document-generation subsystem used Word to create the document: a template was created to get the layout and formatting right, and simple placeholders used to mark the locations of the data we would substitute, taken from the XML data. This approach actually loads Word into memory (on the server!) to do the work - it's slow, memory-hungry and just generally clumsy and ugly. Plus you end up with a Word document, so the clinician needs Word (or the reader) to view it.

PDF is a more acceptable format, in my view. We can secure and digitally sign the document when we generate it to prevent subsequent changes. Recipients can view PDF on any platform with a free viewer. The problem for me was how to generate the PDF programmatically, from the XML data. There are probably several ways to do this, but I chose XSL-FO and the Apache FOP project mainly because I wanted to avoid using a proprietary PDF generator product (there are lots out there), but also since XSL-FO can do more than just generate PDF.

First problem: how do you create the FO which is the 'shape' of the generated document? Of course, you could simply read through all the manuals and write one from scratch. Well, I'm just plain lazy, you see, and I don't want to do all that. I want to take my nice OpenOffice document, or even Word document, and have a tool create an XSL-FO for that document. And I'd like the tool to be free (there are commercial tools of course, but I'm cheap). Does such a thing exist?

It does! Amazingly, precisely this facility exists in Abiword: not my favourite word-processor by a long, long way, but a good solution for this particular problem. OpenOffice should be really good at doing this, as it stores documents natively as XML and already uses FO internally for some style information. But, despite some promising hints, there is no mature support for this. This is a real shame: this is just the sort of thing OOo should be capable of, especially as it's apparently half way there already.

Here's what I managed to find on the OOo site:
Important to mention also that Microsoft does have an XSLT which you can apply to Word documents to generate XSL-FO. It's freely downloadable from this download page. I tried this, and it works, but the resulting FO is much messier than Abiword's.

Once you have the FO, the obvious step is to embed it in an XSL, add xsl:value-of elements in the appropriate places and use a transform to populate the template. This is the approach I took for the proof-of-concept and it worked well. The resulting PDF looks almost right - with a small amount of FO-tweaking, we should have something very usable.

But using XSL means loading up and running the (trivial) transform which I think may be very inefficient for such a simple case, plus it requires the FO to be edited. I've decided to use a simpler approach (using StringTemplate) which I hope will be more efficient, and requires less FO editing (just the addition of $fieldName$ placeholders). All we need is a list of (fieldname, XPath) pairs for our XML message, in order to drive this template.  Of course, most other applications will need the power of XSL (e.g. to deal with tables of entries): I'm only avoiding it here because the data is so simple.

This is something we're bound to want to do again, in different contexts, so I'm using this project and the prototype to build a tool-chain and utilities for this, so we can use the same approach more easily next time.

Sunday, 7 September 2008

Google Chrome, Part 2

Mmmm. It all looked so good in the cartoon. The reality isn't quite there yet, but you can see where this is heading, and overall I'm optimistic. Here's a summary:
  • Windows only at the moment. Understandable, given the market share stats, but what a pity I can't run it on this LinuxMint laptop. Wondering what underlying runtime they're using: surely one of the key features of Chrome is that it will become a client-side platform. They need to be able to run multiple processes (presumably native processes) to get one process per tab.
  • On Windows XP, I found Chrome simply ate CPU cycles. The memory (working set) story wasn't as bad as I had expected (no worse than Firefox, anyway) but the CPU cost meant I was experiencing significant interruptions in other applications. I did experiment a bit, but so far I haven't been able to characterise the circumstances under which I see this.
  • Loved the ability to drag a tab out of the frame to create a standalone 'application', e.g. Google Documents or GMail. That works very well.
  • Rendering speed seemed higher than Firefox.
  • Plugins for sound and video worked for me (e.g. BBC news) but I really didn't set out to test this with different formats.
  • The lack of my Firefox add-ins took a little adjusting to! I'm sure this will eventually come.
  • The UI is quite bare, but you get used to it. The downloads bar (at the bottom of the screen) is actually rather good - better than FF.
  • The search/address bar (can't recall what they call it) is excellent - I found it worked very well for me.
  • The fact that Chrome imports history etc. from FF if you want it to (I did) means it does very nearly allow you to pick up from where you left off in FF.
On the whole, very impressive. But I'm not ready to replace FF just yet.

Tuesday, 2 September 2008

Google Chrome

I must have missed the Chrome story, as I've only just seen a pointer to it from Darren Waters BBC blog piece. Having just read quickly through the Google Chrome storybook, this looks like a potentially important and exciting development. The storybook format is really excellent, too: what a contrast with the way other software companies (e.g. Microsoft) introduce a product!

Technically, this looks like a winner to me. Using a process instead of a thread per tab is a sound idea in principle, with lots of benefits (explained in the cartoon) which you pay for with a slightly higher initial resource footprint. I've little doubt that this will be a worthwhile price to pay, though: almost all of us have machines with enough CPU and memory to accept this.

It seems to me that the most important thing Google has done is to recognize that the nature of the browser has changed utterly, from what was simply a way to view HTML through to something which is trying to be a complete application platform. With Google Mail, Google Apps and Gears, plus a handful of add-ins, Firefox is currently central to the way I work, but because the underlying architecture is still anchored in the past, Firefox isn't going to be stable or performant (or secure) enough to cut-it, for much longer.

This seems to be Chrome's architectural starting point, and the team have sensibly decided to start with a clean sheet of paper, rather than simply build just another branded browser on top of old-world technology. In some ways, I wish the Mozilla engineers had gone down this route. Firefox has been a great success, but if Chrome is as good as the comic-strip suggests, I think Mozilla will need to raise their game significantly.

Monday, 1 September 2008

Climbing in Great Langdale

On Friday, Becca and I had a wonderful day climbing and abseiling, in Langdale. We're both beginners with some experience of climbing walls but none so far on real rock. I managed to get a day's climbing instruction with Adam Marcinowicz of Adventure Peaks, via the Destination Cumbria agency. I can recommend both Destination Cumbria and Adventure Peaks: within hours of my initial enquiry, Lindsay Gibson had located three good options for us, and once we'd chosen AP it was all arranged quickly and efficiently. Great service.
Me on Lower Scout Crag
We met Adam and colleagues at the Adventure Peaks store in Ambleside. AP is in the business of organising and running real expeditions to challenging places - the shop is full of serious (and expensive) equipment - so our little day out is really small-beer.

We spent the morning climbing on Lower Scout Crag, in Great Langdale. This is a beautiful place, but somewhat busy. It wasn't long after we got started that two other groups arrived and began setting up. We tackled two routes, Cub's Wall and Cub's Crack.

The first is relatively easy, but the crack is far harder: the initial moves required to reach good handholds completely defeated me! This was due to a combination of lack of experience / poor technique, and my hands and forearms being weak and out of condition. Becca finally made it up this route, after hanging on the rope and persevering.

We had a brief lunch stop on the pass between Great and Little Langdale, looking out over the valley to Gimmer Crag - beautiful scenery, but we were plagued by flying ants!

Then Adam took us to Cathedral Quarry, to do an abseil down the 30m quarry face. The walk from the car takes you through attractive country, and eventually into the quarry tunnel which leads into the cathedral cavern. Becca and me in Cathedral Cavern.

There are other tunnels leading back through the rock to the approach path - we took a wander through these, too. They are at a constant (low) temperature and pitch dark: climbing helmet or torch (or both) recommended, as I was glad of the helmet on one or two occasions!

The climb up to the abseil point is a scramble up some steep and wet paths - you need to take care here as you're more likely to get hurt on the way up here than on the way down the rope.

The abseil is around 30m, and sheer. About two thirds of the way down the rock face ends and you lower yourself down past the cavern mouth. At the top (quite unprotected and with no warning signs!) I was initially somewhat nervous. Like most folk, I don't like edges at height, so I prepared myself mentally for something I knew I was going to find challenging. I concentrated on two things: (1) treating it as exactly the same as coming back down from a climb up, and (2) trusting the equipment. It worked! By the time I was attaching myself to the rope, I was ready.

As I leaned back, put load onto the rope and stepped onto the face, I felt OK, though my heart-rate was a good bit above resting! It was really only that initial step over the edge which was hard - once I was comfortably into the abseil, I didn't really think about the height.

I ended up doing the descent twice, the second time with a different (and better) belay device which made it more comfortable. Becca managed three descents!

Someone has posted a YouTube video of their descent, which (if it's still there) gives you some idea of the location. I think their estimate of the height (140 feet) is a little on the high side, though: Adam thought 30 meters or so, which is nearer 100 feet.

We had a fantastic day, achieving more than I had expected, all thanks to Adam who was patient with us, and worked hard to give us the best possible experience.