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.
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.
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.
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.
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.
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.
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
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.
I began programming Perl in 1997, as my university did not
and I wanted to access to a database.
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.
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,
OO to a much great extent than Perl. For example, whereas
Perl has a length() function, JS objects have a length() method.
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.
is documented, in comparison with Perl:
A comparison between
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.