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.

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.

Prototype, Trains, Marketing

I was asked the other day if I’d ever used Prototype.js, and I completely forgot that I had used it in Train Game — the library is such a natural extension to JavaScript that its use did not stick in my mind. Although, having now looked again, I do wonder what it is doing with my error messages….

The reason I forgot Train Game is that I never got past the round of development. The idea is simple — allow a child to build a train track, with points, and watch the trains — this could keep a three- or four-year old boy amused for an hour, and it’s not hard to program, as it is all grid-based.

Thing is, I then thought about extending the game to allow varied size pieces of track, and selling the software to those who make the Thomas And Friends tracks. It’s a great idea — design your layout from track in their catalogue, and order online with a single click: so simple, a three- or four-year old child could do it.

But I have no idea how to sell this, where or how to raise capital: all I know is how to program, hire a and run a development team, apply graphics. I think I could even have a selected number of track pieces lay themselves out in a number of patterns dreamt up by the computer.

It would take six months to publication.


JavaScript Poster Text

A year or so ago, I wrote some client-side JavaScript to allow allow input text to flow around images — it worked perfectly, and was optimized through a server-side process that produced a mask map from the image, which could be sent as JSON with the choice of image being mapped. Whilst optimised, it was non-dynamic — there were no uploads of user-supplied images, nor any provision in the client to analayse such images, tough that would be only a few lines of code. The purpose of the project was to allow users to create their own type-wrapped postcards, and that worked perfectly.

The next version of the library will have a version that allows not the wrapping of text to an image, but the automated sizing of text such that every line is fully justified (flush from margin to margin), with lines of less characters generally using bigger font sizes to till the line.

The user will be able to enter text with or without manual line breaks, and real-time editing should be supported.

It should be easy to program all of this within a day, perhaps two. My only concern would be cross-platform DOM manipulation, because I have used MooTools, jQuery and such libraries for so long now, that my DOM API is rusty. Then again, there are few places where node creation is actually necessary, so it will not be long-winded enough to justify use of any library.

Day two

Cards - 2013-10-22_14.46.35This morning I managed to tweak the existing e-card code to automatically scale free text, preserving line breaks. This afternoon, I should break it away from the input UI.


My First Facebook Applicaiton

This Timeline Word Cloud is my first Facebook application, written in about 16 hours — most of which were spent dealing with horrendous problems within the Facebook JavaScript SDK.

On the whole, it is a pleasant SDK, with clear documentation and plenty of Stack Overflow examples (some ugly, some neat).

What did bugged me was that WebKit-based browsers get very upset when Facebook’s ‘Login’ button/dialogue inserts an IFRAME with an https scheme when its images are hosted on a server with an http scheme. This would have been less of an issue had OSX Chrome actually reported the issue.

(JPEG Image, 519 × 519 pixels)

After writing my own Facebook log-in routine, everything worked like a charm — up to converting the beautiful d3 word cloud SVG to PNG, when Chrome freaked out that I was manipulating Blob and Object URIs. I updated my use of the word cloud to render directly to a canvas from which I could gather pixels to create a URI for my image.

I would have liked to have written the app to use a Facebook ‘canvas’ — to appear within the Facebook site itself — but my host, Vision Internet, require a modest £50 a year for a usable SSL certificate, which this application really doesn’t justify, yet.

I was pleased enough with the results to use the Graph API to produce word clouds of friend lists activities, too — which took about two hours.

What’s the point?

I’ve learnt how to tie-in with Facebook, which was no big deal. I’ve learnt how tight Chrome is, which was news.

Can it pay? No, I doubt it — but when I was developing the first prototype (an hour’s code), I was using d3 bubble graphs, and it might be interesting to see those bubbles filled with images from a paying agency — particularly if the agency had a friend list of news providers: instant and up-to-date promotional posters for current affairs. That would be fun.

PHP Ain’t So Bad, and Paula’s New Homepage

Paula wanted to update her website last month, so I actually spent some money buying a photographer’s WordPress scheme — what a waste. There were no docs, and the implementation was as unintuitive as I could imagine, so I hand-coded her site single-page JS application.

I finally gave up on MooTools and used jQuery for DOM manipulation, and wrote the rest as a collection of ‘pure JS’ classes — slideshow, portfolio, news section, very straight-forward, and quite good fun.

One Interesting Thing

Paula’s quite good with the machine, but doesn’t like fiddling, so I wanted an easy way for her to upload and manage her images.

The simplest I could come up with was for her to title them in a human-readable, sensible manner, and produce 200px thumbnails with the same title, plus a suffix of ‘_thumb.’ She then FTPs the lot into a directory on the host, and adds a single empty div to the single HTML page of the app — specifying the images’ directory URI in a ‘data-‘ attribute.  Apache’s mod_autoindex directory index is then requested, parsed, and used to generate the portfolios and slideshows.

I’m very pleased with this simplicity.

The Other Interesting Thing

The other interesting thing was that I found it took only two hours to turn this code into a WordPress plugin, and that WordPress can be made to work with OO PHP — great news, considering how much PHP work there is out there. It is almost as ugly as Perl, and nowhere near as sweet as JavaScript can be, but still…


Angularjs Subtitles

I watch a lot of Scandinavian video files, which means a lot of subtitles. Being a fussy sort of a fellow, I do get irked by badly timed and badly typed subtitles, so for some months have been contemplating writing a subtitle editor. I’ve combined that urge with my curiosity about AngularJS. I have been irritated by JavaScript since version 1.0, and have so far been unimpressed with everything but MooTools. Yet the weight of Google, and its usually intelligent solutions, is encouraging.

Starting from scratch it took about eight hours to create an SRT viewer from scratch in ‘the Angular way.’  That has involved very little new ideas — a blurry MVC, more of an MVP; mustach-style templates that mix presentation, backbone views — but some nice dependency injection, and a huge pile of patterns to choose from (which will probably be a PITA, if the TMTOWTDI motto of Perl is anything to go by).

Eight hours to produce an SRT viewer, which is a task I’d usually accomplish in two hours.

I am hoping the investment in time will pay a return now that I set to work on the editing controls. Currently, Angular’s two-way data-binding allows me to edit subtitles — moving them as a mass, and adding new entries, is coming up.

One thing I do find encouraging is the community, which is very helpful, and not snooty like the Perl community, who seem to be slowly drifting away in the Perl6 pipe smoke. Angular’s API seems to change quite often (not a bad thing), and these changes are regularly pointed out on Stack Overflow.

One thing that really annoys me is the need to $scope.$apply — so hard to avoid.

What really pisses me off, though, is that the tutorial is not up to date with the tools. There is little more off-putting than starting a tutorial and having to reconfigure everything. Surely Google have the resources…?

What’s the alternative?

But the two libraries do things very differently. Ractive.js is designed to have as few surprises as possible – no mysterious $scope.$apply() or dependency injection minification headaches! You can master Ractive.js in an hour or two, just by following the interactive tutorials.

So claims Reactive.js — and it has to be worth a look.

JavaScript and Perl Object-orientation: a small comparison

I began programming Perl in 1997, as my university did not
run Netscape Live Server – the original server-side JavaScript –
and I wanted to access to a database.

So many years later, it looks as if JavaScript is back in
a serious way: despite limitations in the implimentations
of ECMA Script, the standard of which JS is now a subset,
the language is more powerful than the average Perl
developer is lead to believe.

Perl programmers tend to frown on JS as a toy language,
the way C++ devlopers look down on Perl developers.
Yet Perl and JavaScript have an awful lot in common:
both are easy to exten, bothd in their own syntax and
in the C; both are regularly extended with library
frameworks (Moose, MooTools).

Whilst both have a slightly unusual approach to OO,
the main conceptual difference is that JavaScript is
OO to a much great extent than Perl. For example, whereas
Perl has a length() function, JS objects have a length() method.
More interestingly, JavaScript’s object orientation is
prototype-based – there are no classes, only objects and
object instances, based on functions that operate upon a
built-in “this” variable, and which are used to generate
instances of custom objects when called with the “new” keyword.


This page contains JavaScript which
is documented, in comparison with Perl:
A comparison between
common OO features of Perl and JavaScript

The Problem with MooTools…

MooTools is without doubt the best JavaScript extension around, providing clean and simple object orientation features such as classes, inheritance, pseudo-events, and more. Yet advertised JS programming roles rarely require this skill, whereas the much more limited, and much less clear, jQuery is almost always required.

jQuery’s primacy is not because it is a ‘better’ system: it doesn’t even have a class model, and class-like features have to be hacked-together in a non-standard manner. jQuery sells because it looks good, and has a huge number of reliable plug-ins.

I recently had call to produce a live data grid, reflecting a database table, and allowing users to make updates to the database table by editing the table on the screen. I found a jQuery plugin within five minutes, and had the code up and running in 15: all credit to jQuery and the plug-in author.

Doing this in MooTools can take all day, though the code produced is easier to maintain and update with new features.

Part of the problem is that MooTools is more compartmentalised. A recent example I came across was trying to produce charts from tabulated data. The wonderful MilkChart library for MooTools,  by Brett Dixon, produces beautiful business-ready charts from HTML tables – but not from MooTool’s Table.Sort or Table.Paginate tables. It only took ten minute this morning to produce a GitHub fork of the project, updated to support these core MooTools features, but it seems curious that such elementary comparability has been over-looked for so long. Perhaps I can gauge the health of MooTools by the state of this fork’s pull request.