Tuesday, July 02, 2013

New haiku and the ups/downs of modular flows

My seasonally-regenerated book of haiku chaos, Butterflies & Sand, has just had its summer edition released here.

If you've not seen it before, B&S is a randomised collection of all my haiku ever on Twitter - a PHP script (github here) was scraping the tweets from poeet.com, a haiku site which is currently sadly defunct. The script then picks a random largeish word for chapter titles, and adds in random images from a selection made since the previous edition. It's been running quietly along for a few months now (ie. somehow I manage to find the time to run the script and publish the results.)

The whole thing was intended to be an exercise in 2 things:

1. A slightly-surrealist approach to re-mixing and re-playing content which is developing in a fragmented way over time. I got fascinated by the idea that haiku came from somewhere - moments of strange clarity, interspersed among busy daily life. Tying the moments back together again seemed like a natural thing to do.

2. A technical experiment in modular delivery - the production of B&S depends on several interwoven services all built by others, and all available for free. Twitter, Dropbox, poeet.com and Leanpub are all tied together through some fairly simply (and admittedly badly-written) PHP code. I still think it's cool that badly written code can make an actual e-book.

poeet.com disappeared about 3 months ago, just after the last edition was published. I've actually been meaning to take it over and run it on my own server, and may still do so. But it highlighted the second point above - that modules are both annoying, but also great.

On the one hand, relying on several different services makes it more likely that a single one will break/disappear. How the rest of the flow reacts to that depends on its position in the system - for B&S, for example, the flow of information is pretty unidirectional (Twitter > poeet.com > PHP > Dropbox > Leanpub) so there's not much resilience when one of these drops out.

But on the other hand, poeet.com wasn't the only way to get hold of my haiku. After an evening's hacking, I had a separate PHP function to parse the download of my Twitter archive. (Fortunately I'd got hold of the code behind poeet.com so could replicate a lot of the text processing.) There was a natural split in the code between getting haiku, and randomising them. Extending the code to use other sources would now be a lot easier.

I'll be coming back to this sense of modularity in future posts, totally unrelated to haiku. It's a perspective that's working its way into my daily life more and more - the idea of small components that can interact, may break, but that can be easily updated or replaced, like replacing the switch on a vacuum cleaner instead of the whole thing.

Thinking about life as a system - as components and flow - should lead to more resilience, and possibly even more automation alongside. But more, as they say, to come.

2 comments:

phil jones said...

Great post.

Naturally resilience should come from redundancy. You should always make sure you have multiple sources in your supply-chain.

(Not sure quite how to do that in your case, but it should become a feature of the internet ecosystem.)

Scribe said...

Hi Phil, meant to reply sooner... Redundancy is a really interesting topic. I remember back in floppy disc days, the suggested advice was to take backups of your software, and then use the backups, not the originals. Of course, this assumes that there is a _value_ difference between the paths you can take - i.e. not all redundancy paths are equal. Sometimes maybe they are.

In my case, there is an 'inherent' resilience in that none of the modules _specifically_ depend on the others - they're used because they're there, but I'm already thinking about extending the code to take in other fragments of text, for example. Similarly, it'd be annoying if leanpub went away, but I suspect there are other ways of turning Markdown into PDFs, for instance.

So there's a difference between "replacable" modules - i.e. simulacra you can "drop in" if the main one goes down - and modules that change the output, but achieve basically the same thing - a flexible redundancy.

I have this suspicion other people have already mapped all this out. Time to get the reading lists geared up again...