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.
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’.
Ported the core of my L-system work to user Browserify through CommonJS — much nicer API than AMD/requirejs. Not sure I’m keen on exposing node_modules, though.
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.
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.
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!).
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.
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 …
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.
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.