Enso 2015-07-04/01

Enso 2015-07-04/01 was created in Photoshop using a Mac Book Pro track pad. Photoshop is not just about airbrushing products and models.

Credit Card Details Storage

Avoid liability: why not  encrypt them and have the client store them for latest display and stateless use of the serer?

Probably because all forms of local storage are an out-of-sync mess (no pun intended).

Perhaps Mozilla’s localforage is the answer? Though not through its messed-up Backbone ‘driver’.


Over the weekend I had a go at three.js and Conway’s Game Of Life — I’m sure I can get it to make music somehow, but am disappointed to learn that the shapes appear not to be photosensitive, and ray tracking in JS is not fast.

Three.js is great for someone like me, who has never programmed 3D graphics — the shader language looks interesting.

Used require.js again — this time set up with Yo and Bower — the wiring of require took about five minutes. Nice workflow, I’m sticking with it. Tests were in Qunit, sadly, but maybe I’ll write a Yo generator for requirejs, bower, and mocha.

Word of the Day: “Reification”

Today’s word is ‘reification’ — suggested by Sid Arthur of Northern India, via the Marxists’ use of the German word Verdinglichung: ‘thing making.’

This concept is at the hub of Western civilisation, Capitalism, and those mechanisms visible within Capitalist states to repel threats from within the system by subsuming those threats, commercialising them, removing their thorns, and flogging artificially-sweetened, carefully-smoothed, mass-produced versions (cf. Walter Benjamin’s The Work of Art in The Age of Mechanical Reproduction).

Naturally — we all do this, all the time, of course: the ability to conceptualise, codify, nominate have for centuries been the measure of both a society, and its individual members.

A reified thing is a thing made at once more of a thing, and less of a thing: it becomes an exemplar of the superset the reification ascribes it, a chain in a link of concepts, a neuron linked to the network of neurons that represent that concept in the brain. In so doing, the uniqueness of the reified thing becomes less relevant — in naming the thing, we use distinct attributes to define it, and inevitably use those attributes to spot further exemplars.

There are thousands of well-written accounts of reification and the materialisation of abstract ideals, usually for the detriment of those ideals, and although many of these reports, investigations, and experiments have themselves been subsumed by the system which they observed, it seems to me that the internet is bringing to the mainstream media the story of those who attempt to avoid reification, partially, temporarily, for a short time each day, or every day as the core of their life.


In a way, the ancient practices and teachings of Judaism are living on through the Vipassana, Mindfulness, Buddhist stuff of the past few years — but that’s just collected reification.

Reification of women by a male-dominated society that perceived the gender difference as a threat to their material, intellectual, and philosophical equilibrium. Viz, The Sex Symbol.

Other favourites, to cf with Focault’s description of ‘reverse discourse’: The Jew, The Homo, The Black, The Paki, The Scotsman, The Taff, The City Gent.

See also: objectification.

How to welcome new staff

I’ve worked at more than 15 companies in the past 15 years — I enjoy the variety and the choice of ‘holiday’ time to spend with my little kids.  From these 15+ companies, I can certainly say without the slimmest doubt, that there is a right way and a wrong way to welcome new staff, even if only a contractor. I’ll keep with the

Know when your new member of staff is arriving, and meet them at reception. Sounds obvious, but I’ve had to wait for thirty minutes for an interview with a chap at the one place.

Show them around the office. Offer a cup of tea, coffee, water as you show them the facilities.

Show them the fire exists — you are legally obliged to do so, at least in the EU.

Please have their personal computer ready, with monitors, and any licence keys. Again, this may sound obvious, but most companies do have a computer for me when I join, even though their ‘policy’ prevents me using my own machine.

Please prepare an account for them on all relevant servers.

Give them something to read to help them settle in — your technical documentation is better than your corporate blurb.

Show them your product, show them your code. You are probably very busy, you probably have a sprint ending or a release due (which is probably why you got to hire a contractor), but to leave the new member of the team alone, unattached to a team, without but SCM access, is a false economy — more efficient is to pair the newbie with a senior dev for a day and a bit.

Show them around, set up what needs to be set up, introduce them to who they will need to know, and let them join the sprint as it starts.

Next time, a guide on starting a new contract (in short: expect nothing, and be polite!).

Architechting Distributed Systems: the bleedin’ obvious

Distributed systems were a big deal when I was reading Intelligent Systems at the graduate research centre for cognitive science at the University of Sussex — there were tutorials, seminars, lectures, books: I would not be surprised if there were courses devoted to it, there was certainly active research devoted to it.

I remember thinking that would be a great way to spend time — making computers interact in an intelligent manner — and so I am grateful that although I could not afford to live on a research grant, I have made my living helping computers inter-communicate.

Of course I would be much happier if I and my family could live comfortably whilst I research the interaction of sensitive, independent agents creating music, but I would not know where to start getting the funding.

I find it strange that distributed systems are still, in 2014, 14 years after my MSc, distributed systems are still so rare: and that’s also 14 years after Fielding’s seminal Architectural Styles and the Design of Network-based Software Architectures.

The way I learnt it, the way that seems most natural to me, and the way I practice, is to have every agent (in the academic language of 14 years ago), every component system, be a sub-class of one base class, one prototype that implements (specifically: hosts implementations of) basic needs, or requirements — such as transport protocols, generic data-description languages, and basic engineering such as self-installation of all required software dependencies, libraries, headers, binaries, update management/version control.

This is not an academic point, nor a nicety that can be dispensed with in favour of ‘the interesting work’ — on the contrary, the base-class is clichéd kick start, the fabled boostraps by which your work will metaphorically raise  itself.

Knowing which components to use — which version of which flavour of which OS, which virtual machine provisioner, which indexing strategy to use, which thread technique to use in processing massive archives —  these things can come from either study/research, experience/practice, or as an evolution of other practices. With relation to the latter case, study will show has experience already has, that clinging to legacy technology is no more productive than clinging to a past life, but that’s a whole different post, and probably for FaceTube.

Angular Mixer

A coupe of years ago, whilst working away from home, I started writing a sound mixer in MooTools. All went went, until I hit looping bug in Firefox and then my l-system project caught my eye again…

Now I’m looking for something to work on with Angular, shortly after being handed a bunch of mp3 tracks split from a Logic session, so …

Why Angular?

In 1997 I wrote a clone of PacMan for Netscape Navigator, moving DIV elements with CSS. Although I have largely earned my living as a server-side developer since then, I have written many JavaScript applications, using MooTools, jQuery, and avoiding libraries altogether: at every hand-over meeting, I have had to spend hours explaining what have become to me fundamental concepts in JS, borrowed from my server-side work, such a views, bindings, injection, controllers, routes — and to those who are familiar with these concepts, I have had to explain my own implementations of these. I’m actually quite proud of my own implementations: they’re clean and efficient, but repeatedly explaining them is a bit of a drag. A library that can do the same things, and more, as well as offering reasonable documentation and community support, removes from me the burden of general documentation and education, as well saving a lot of start-up time.

Where to start

My last, and first, Angular project was a single-page application to add subtitles to video files. It took a couple of half-days to write, and served as a great introduction to the way Angular works. But it rook me hours to find a clean entrance, and the chosen Angular seed on GitHub modularised in a way I didn’t find constructive for my project, being functional rather than conceptual, rather at odds with the OO approach I prefer.

When recently spent some time updating some code for Symbox in the UK, I came across a Backbone project that used grunt and bbb. Since the last release of bbb was some years ago, I brought the project’s gruntfile up to date, which negated the need for bbb, but did show me that Yeoman had finally taken off. So this time, I’ll start with Yeoman.


From the Yeoman homepage, set-up looks quite straight forward:

npm install -g generator-angular  # install generator
yo angular                        # scaffold out a AngularJS project
grunt test                        # test your app
grunt serve                       # preview your app (formerly `grunt server`)

Looks like we get bonus HTML5 boiler plate, and a reasonable staring point in js files. Now I can think about my application.

Application Requirements

Other than being testable, package-able, and easy to read, the application needs to:

  • play multiple audio files
  • play local or remote audio
  • start and stop playing individual tracks at discrete points
  • loop specific points in tracks for specific periods
  • muting of tracks
  • changes to pan
  • changes to volume
  • recording and playback of mute/pan/volume events

In Agile style, best to start simple, with an object representing a single audio track.

In my previous attempt, I had a container for tracks that visually represented time, but found — as in any sequencer — milliseconds an unnatural unit for music. So this time, I’ll work in units based on the size of audio files, placing the burden of timing on the creator of the audio files. After all, the intention is to remix existing multi-track recordings.