Paul Dundon’s Weblog


A little cheese and a little whine

App to Sync Windows Playlists on Android

Windows Media Player 11 doesn’t recognise some Android phones as media devices. This means that when you synchronise playlists with your phone, it copies the media files but not the playlist itself.

I’ve written a Windows application, androsync, to get round this problem. Androsync copies WMP 11 playlists (.wpl format) to the phone along with the necessary media files, and modifies the playlist file to use the copied files rather than the originals.

It is now, and probably ever shall be, in beta. If you would like to try it (subject to all the usual caveats of it not being thoroughly tested, your not suing me etc) then please contact me at [paul at jimandpaul dot com].


Filed under: Tech

Defying Gravity

A comment (from John Z) on an earlier post highlights some interesting research on anti-gravity. Unfortunately, I can find nothing relating directly to the original research after 2000, although New Scientist reports some similar work from 2006.

Filed under: Maths, Tech

Google Wave

What is it?

To begin: Jabber is an open-source instant messaging protocol. Applications can use Jabber to communicate across the net in real time. For example, a text editor written in Jabber would allow multiple people to work on the same document and see each other make changes as they type. Given a suitable host environment, an application like this can save its state so that users could edit that document over many sessions; and the persistence mechanism could save not just the latest version of the document but all historical versions, allowing users to view the way in which the document has changed over time.

This is the basis of Wave. Documents managed by applications like this are called blips; a hierarchy of blips is a Wave. Google provides a text editing application like the one I have described, which provides default blip behaviour, so by default, a Wave is a hierarchy of documents which can be edited in real-time by many users. However, many other kinds of blip are supported through extensions, so for example, there are mapping applications, polling applications, chat applications and so on. This makes a Wave a sort of extensible workspace which can be bent to lots of collaborative tasks.

Google describes Wave as “what email would be like if it were invented today.” This is silly: if email were invented today, it would look like email, because it’s an automated version of a familiar manual process. Wave is, if anything, what NNTP would look like if it were invented today, and in fact, a very quick way to understand Wave is to think of it as NNTP where each post is a live chatroom. In relation to email, Wave is an attempt to solve the problems which arise when email is used for collaborative working, which are in fact exactly the same problems which arise using IRL mail for collaborative working.

Waves can be embedded in other web pages without loss of functionality.

Paradigm, Protocol or Product?

In trying to understand the impact of Wave it’s important to separate out three different levels of analysis. First, Wave could claim to offer a new paradigm for collaboration, that is, one could argue that Wave allows people to work together in novel ways. Second, since the Wave protocol is open, any number of different clients and servers could spring up to take advantage of the underlying concept. Third, Google will (presumably) offer Wave alongside GMail and GTalk and other services as a product people can use.

There is nothing particularly radical in the way Wave allows people to collaborate. Being able to see other users edit a document live is novel, but in no way useful. Wave brings together multiple modes of collaboration, and makes them slicker, but doesn’t, so far, offer anything new. This shouldn’t come as a surprise: there are limits to the way people can collaborate, and software to support those modes of collaboration has been around for a long time. As a paradigm, then, I don’t think Wave offers anything novel, although I think it will have an impact on collaborative working as a product, as I detail below.

Wave is both a protocol and an API and I think it’s fair to think of that API as a protocol in itself. The communications side of Wave is not particularly interesting, since most of the hard work is done by the underlying Jabber protocol. The API, however, is interesting in that it allows us to build both extensions (which are basically new sorts of blip) and robots (which can automate the interactions between blips). I haven’t looked at the API in detail yet but it seems likely that it will solve some interesting problems about how to stitch together a hierarchy of interactive applications.

The “open” nature of the Wave protocol means that people other than Google can set up Wave servers and offer Wave hosting. Again, I don’t have the technical detail but a key point in the success of these offerings will be whether extensions and robots built against one server implementation will be transparently portable to other server implementations, since any failure in this area would quickly fragment the market for Wave services and slow down adoption.

This leads us to the place where I think Wave will have the biggest impact. Wave provides a platform for collaborative applications with a low cost of entry for users, and thus a market for those applications rather akin to the market for mobile applications established by Android Market. Developers with ideas for collaborative working need now only build a Wave extension or robot and make it available, and users can make use of that idea without buying wholesale into a new collaboration platform.

I currently use CVS, MSN, Groove, Google Documents and email for different forms of collaboration on different projects. Each of these has had some level of adoption cost and the mixture of platforms is cumbersome. I would probably balk at adopting a further collaboration tool, even if it was a very good one. But, if my present position was that I used Wave and a few extensions to do all this collaboration, adding another extension to the list would not seem so onerous.

Adding Value (aka making money)

There are therefore two levels at which one can add value to Wave. First, there is the possibility of hosting a Wave server or perhaps providing Wave server software which would run behind a corporate firewall. Then, there is the possibility of providing extensions and robots for particular vertical applications. It is here that I think the most exciting possibilities lie. Medium to large scale websites in vertical markets often require collaboration platforms. For example, the UK Government is increasingly seeing the web as a way to share best practice across public, private and voluntary sector organisations.

Now of course, any group who wants to collaborate could simply log on to Wave, in the same way as they can use email now. However, the possibility of embedding wave into a site means that people can make use of it in a tightly located context which can bring together otherwise inaccessible waves (topically relevant, but created by other groups of people) along with non-wave reference material, so there is an opportunity to add “content value” here. Further, developers can add “functional value” by building extensions which help structure and navigate waves for particular applications, and which support particular specific collaboration tools (for example, a limited shared whiteboard for user groups who find a rich shared whiteboard confusing).


As a product, Wave is unlikely, I think, to supplant any of its competitors. It is quite the wrong model to replace most email, and overblown for IM. Unless you install Gears, it lacks the file system integration of Gears and even with Gears installed I’m skeptical that we’ll be seeing a Wave source code control system any time soon. For the enterprise, Lotus Notes has been doing very Wave-like things for a long time, and there’s no obvious benefit in migrating.

There are three ways in which Wave will succeed, though. First, as we’ve seen already, it will create a new ecosystem for collaborative applications, and thereby support more rapid evolution of those technologies. Second, it will make a certain style of flexible collaborative working available to a much wider audience, enhancing people’s understanding of collaborative processes and making collaboration more common and more efficient. To state it more simply: Wave will help more people work together more often. Third, and as a consequence of these two, Wave will support mashups in which a combination of new plugins, robots, and wave structures becomes a genuinely novel, or perhaps just highly efficient, way of collaborating.

So the value of wave, I believe, doesn’t lie in its core concept – which is basically sticking chat rooms onto NNTP – but in the fact that with a sponsor like Google, it will succeed in creating a new ecosystem within which a great many more people will have the opportunity to contribute to the development of collaborative technologies. This means that its ultimate contribution will depend on Google sustaining their support of it – not something they always do.

Filed under: Tech

Ruby on Rails

Filed under: Humour, Tech

Beautiful LINQ

I was playing hangman recently, and wondered how successful you would be playing it just by guessing letters in order of their frequency in the language. It struck me that there would be an elegant LINQ query which would calculate the number of guesses required for a given word. It turns out there is:

(Aggregate i In (From c As Char In word _
Select "etaionshrdlcumwfgypbvkjxqz".IndexOf(c)) Into Max(i)) + 1

Filed under: Tech

Five Reasons to Look at Lisp

As a programmer, I’ve met more than one colleague who’s recommended I learn Lisp. Lisp, they say, is the best language they’ve ever worked in. When pressed, however, they find it difficult to articulate why, saying I really have to learn the language to appreciate why it’s worth learning. Despite my appreciation of recursion, I’ve never found this position especially compelling.

Over the last few months I’ve been writing a lot of commodity web applications – basically front-ends to databases. Last weekend the boredom finally became too much and I decided I needed more of a challenge. So I started making my way through Practical Common Lisp and the lectures on Structure and Interpretation of Computer Programs.

As a result, I think I can articulate why Lisp is worth learning (and I have to say, it isn’t hard to master the basics). I’m only a beginner, and more experienced Lisp users will no doubt have a much better view. But for anyone who’s looking to understand quickly what all the fuss is about, here are a few pointers:

  1. Lisp syntax is very simple and very regular (if a bit befuddling at first). This means that the advanced features it shares with other relaxed-type languages like Javascript and Python are easier to use. For example, Lisp treats functions as first class citizens, allowing us to break programs into high-level strategies and low-level procedures. We can write functions which return functions, which might be curried versions of other functions (ie, versions with one or more parameters already bound). Other languages do this but Lisp’s syntax makes it natural and intuitive. Similarly, recursion feels much more natural in Lisp than in some other languages.

    As an example, consider the (inevitable) Fibonacci function, in Lisp:

    (defun fib (x)
    	(if (= x 1) 1
    		(if (= x 2) 2
    			(+ (fib (- x 1)) (fib (- x 2))))))

    Parentheses are used to enclose everything that needs to be evaluated, allowing a quick visual breakdown of the code; prefix notation (= x 1 rather than x=1) keeps the syntax regular; and defining if as a function rather than a control structure eliminates a lot of syntactic sugar.

  2. Lisp code can easily be represented as data. The .NET languages have this feature, but while CodeDom is an arcane art to all but the most dedicated, the simplicity and regularity of Lisp syntax means that it takes only a few minutes to understand the relationship between code and code-as-data. Lisp has a “macro” system which is in fact a code generator; a macro is a Lisp function which takes Lisp-like code and returns actual Lisp code. Macro “expansion” takes place before code execution and continues until no macros are left unexpanded (since macros can generate other macros). This makes it possible to define domain-specific languages (so long as they share the basic Lisp syntax) at least an order of magnitude more easily than in languages like VB or Java.
  3. Lisp typically runs in an interactive environment, allowing very rapid re-definition of functions, macros etc. Sitting in front of a Lisp prompt you can define, and progressively refine, a domain specific language for the class of problem you want to solve while at the same time using it to solve some specific problem(s).
  4. Object orientation in Lisp is based around a set of mechanisms which are more abstract and powerful than languages in the Smalltalk lineage. I have to confess that I haven’t fathomed these yet.
  5. Lisp’s exception handling mechanism includes the concept of a restart, which effectively names a block of code to be executed in a specific exception handler. We can bind the restart to a specific block of code in a higher level function than the exception is caught in. For example, if we write a library with a function which depends on opening a file part way through a much longer process, we might not want to unwind execution to the top of the stack (and the start of that process) if the file is missing; it might be better to prompt the user for another location for the file. However, we may want to run the code in context where a prompt is inappropriate. Restarts allow us to define these two different ways of handling the error and bind them, as we need, to the low-level exception handler.

Lisp doesn’t look particularly good for the sort of commodity web application where you take data off a form and shovel it into a database (although it’s no worse than, say, PHP for that purpose; and it would probably be fantastic for generating such applications from an abstract representation). It comes into its own when you’re solving a novel problem, typically a problem which revolves around complex transformations of data. It looks especially useful where you want to explore the consequences of using different transformations to solve a class of problems.

I’ve only spent a few days with Lisp; however, I think I can see already why people who love Lisp really love it. Lisp lets you do things naturally which in other languages feel like bolt-ons; it lets you do things easily which in other languages require arcane syntax or code patterns. The language gets out of the way when you’re doing things which are themselves conceptually demanding, where other languages make already complex tasks even more daunting because of the clumsiness of the syntax. All these features make it pragmatically very satisfying. These benefits emerge from the foundations of the language – they are side effects of the elegance of its syntax and approach. The ability to define domain specific languages isn’t an afterthought or even what looks like a design goal; it’s an emergent property of the language fundamentals. That adds a killer level of aesthetic satisfaction which makes one feel that Lisp isn’t just powerful, but fundamentally beautiful.

Filed under: Tech

My Bookshelf

The Golden Bough
The Value of Nothing
The Fire
A Wolf at the Table
Devil Bones

My links