I present to you a software development vignette. I know for a fact that many estimable developers read this (if you're reading this, you probably are one), and I would be interested to know at which point you consider this story to have gotten silly. Okay then? Onwards!
It started with a daft idea. I have the house to myself for the next week, and those of you who know me will know that I'm hardly the most domesticated person. Ready meals are consumed; unwashed dishes pile up; underwear goes unchanged. Perhaps inspired by the wealth of on-line statistic-gathering sites, such as Audioscrobbler (via Steven), I thought it would be jolly to have a little scoreboard at the side of my blog that keeps track of my progress as the week goes on:
Time since last dressed | 28 hours 7 minutes |
Ready meals consumed | 3 |
Clean crockery in house | 0 |
---|
You get the idea (and, presumably, you also realise that I would never deem this worthy of inclusion on the blog, despite all of the other oomska). It struck me that it would be quite nice to have a little always-on-top desktop app that I could use to maintain these statistics. Finally decided to put on a new pair of boxers: click "Reset", and it would be reflected on the web.
So I came up with an idea for a simple Java/Swing utility that would let me keep track of these things, create an HTML fragment, and upload it to my webserver via FTP when it changes. Obviously, there's no point in limiting the program to this ("No point at all," I can hear the wags opining), so why not make the fields configurable? Not a problem.
Of course, this could have applications beyond a simple list of key-value pairs. Perhaps the same software could be used to create a "Now Playing" sidebar. Or even something relatively static, like a blogroll. Each would require a different UI, so that could be made pluggable, each generating the appropriate HTML fragment.
Of course, there is no need for the system to limit itself to using FTP for transfer. There are a variety of equally-appropriate uploading methods, such as the Atom, Blogger and MetaWeblog APIs, or it might be preferable to send updates by email, for example. So the transfer code should also be pluggable!
At the moment, what do we have? Some abstract code that generates an HTML fragment, and passes it to some more abstract code that will somehow transfer that HTML to its final destination. Could. Do. Better.
Why should it only generate HTML? Take the above example of a blogroll. Based on the same underlying model, it might be desirable to generate HTML, OPML, JavaScript or even LaTeX. So, for each kind of data model, we could have classes that render the data in as many formats as desired. Suddenly, what started out as simple and concrete becomes complicated and abstract.
A fundamental limitation remains. All updates must be carried out via the GUI. We might want to allow plug-ins in different applications running on the same computer (such as iTunes or Winamp, for the currently-playing notification) to initiate an update directly, using inter-process communication. We might even want to be able to make updates over a network, which creates some interesting possibilities involving mobile devices. Why not, then, remove the UI altogether and replace it with a headless RMI server that maintains a mapping between particular data models and transfer instructions? Or go the whole hog and implement the system as a web service, with all communication using SOAP? And, once we consider web services, it might also be necessary to consider having a multiple-user system, with the attendant added complexity.
So, there's no question (thanks to an XML-based relative of Godwin's Law) that the final position was very silly indeed. But I'm curious as to your opinion: at which point in the above did I become an Architecture Astronaut?
Cheers,
Derek.
|