barryvan

Category: Javascript

  • Web Directions 2014 Reflections

    I’ve just returned from Web Directions 2014 in Sydney. Overall, it was a great experience, with some valuable take-aways. I’ve jotted down a few of my thoughts around the conference — and a few specific sessions — below. These are my “notes from notes” — I’ve drawn ideas from the notes I took during the conference to consolidate my understandings of the presentations.

    This is very much non-exhaustive — I’ve elided a lot of stuff, skipped over whole talks (either because I want to ponder them further, or because I didn’t take notes or my notes are useless). I’ve focussed primarily on the technical talks, as I’ll use this post as a reference for myself on these areas at work. If I get a chance, I’ll write up my thoughts on the keynotes as well.

    Emily Nakashima: The Operable front-end

    @eanakashima

    Emily, who works at GitHub, outlined exactly what “operability” is, and outlined some ways of achieving it.

    Operability requires strategies for deployment, logging, monitoring, debugging, alerting, and scaling in production. That is, it’s the ability to detect, diagnose, and rectify problems, with the ability to push fixes into production. It’s important, therefore, to use dashboards and automation to ensure that everything that happens after a fix is ready to ship is as smooth and streamlined as possible.

    Aside: if you fix a bug, you should look for similar error reports from other users. You’re now the expert in that bug, and are best-placed to respond. This ties in well with SEQTA’s, and my own, philosophy that developers should always always always be in a position to talk to clients, and doing so should be a routine part of their job.

    JavaScript error monitoring is one of the most important pieces of the operability puzzle. A great idea is to add a listener for the error event on the window, which collects up various bits and pieces (URL, stack trace, time since load, event target — inc. xpath or CSS selector) and shoots them off to the server via AJAX. (Of course, you want to be careful not to try and send errors about your inability to send errors…) To make this really shine, stop swallowing errors (even though many frameworks advertise this as a “feature”) — in fact, make your own error classes and throw them!

    Performance metrics are another part of the jigsaw. They can be synthetic (that is, measured in a carefully-controlled environment), or RUM (real-user metrics). Synthetic metrics should be part of the CI infrastructure; they’re primary utility is to catch performance regressions. RUM are arguably more useful, and should be tied to monitoring and alerts. RUM can be collected using the shiny new navigation timing API — but for single page applications (like the SEQTA Suite), you’ll need to record your own metrics — window.performance.mark and window.performance.measure APIs come in useful. An API which hasn’t yet landed — but is coming soon! — is the frame-timing API, which will help to catch jank issues (jank is where the framerate drops below 60fps).

    Accessibility is often the “poor cousin”, often because it’s really hard to audit in tests or post-commit hooks etc. Emily has found that scanning the live DOM for accessibility issues, and throwing exceptions (to be caught in window.onerror) is a great way to check for these issues in live, dynamically-generated content. You’re looking for things like missing alt tags, or buttons without text content.

    Useful tools:

    • New Relic
    • Errorception
    • Raygun
    • LogNormal
    • Google Analytics
    • Circonus
    • Whatever ops is using 🙂

    Sarah Mei: Unpacking technical decisions

    @sarahmei

    Conway’s law:

    organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

    Eric Raymond’s retelling:

    If you have four groups working on a compiler, you’ll get a four-pass compiler.

    Takeaway: most of the data we look at when considering a project is social, not technical data.

    Mark Dalgleish: A state of change

    @markdalgleish

    Mark outlined the new Object.observe capabilities in ES6, which lets you track mutations on an object. The main thrust of his talk, though, was about mutability vs. immutability. Traditionally, functional languages have favoured immutable data-structures, as they’re easier to reason about and work with. Lots of JS frameworks are now moving towards representing the state of the application in a series of (immutable) objects; theoretically, this allows you to treat the DOM as a renderer doing its thing somewhere else — and therefore never actually pull anything out of it.

    I sent Mark a couple of tweets about using Object.observe to “fake” immutability (and avoid using massive chunks of memory and causing GC pauses), and caught up with him after the talk to discuss this a bit further. Mark noted that he’d also wondered this, but hadn’t yet had a road-to-Damascus epiphany. We chatted about the fact that if the browser (or the DOM) were to introduce truly immutable data-structures, it could then become the engine’s problem to optimise memory — and the engine could do this much more easily than could be done in JS, and more efficiently, too.

    Sarah Maddox: Bitrot in the documentation

    @sarahmaddox

    Technical documentation inevitably suffers from broken links, outdated information, pure fiction, and information overload — caused by changes to the environment, updates to the documentation platform, last-minute changes to the software being documented, and plain-old human error (which, strictly speaking, encompasses all of the above). Sarah outlined some ways of overcoming this:

    • Automated testing of code samples, to detect breakages in the samples, but also breaking changes in the API.
    • Doc reviews in the engineering team’s procedures — that is, making the definition of “done” include documentation. To facilitate this, use the same issue tracker, same review tools, and include the technical writers in the code reviews.
    • Collaborative spot testing sessions.

    Jeremiah Lee: Elements of API excellence

    @jeremiahlee

    The single most important point that Jeremiah made (in my view) was that APIs are built for human beings, and that they should therefore be treated as a UX problem. In other words, if you want to build good APIs, you need to understand the people who will use those APIs.

    An excellent API should therefore be:

    • Functional: it should do what it says on the tin;
    • Reliable: it should be available, scalable, stable, and secure;
    • Usable: it should be intuitive, testable, and provide corrective guidance; and
    • Pleasurable: the API should become the means by which great things can be done.

    To build excellent APIs that have, at their foundation, a really solid UX, we should make use of the same tools used by graphical UX work. One of these tools is the concept of “personas”. A persona is a descriptive representation of the people who will use the product — and the context in which they operate. By constructing personas, we make visible our assumptions about our users, and provide a frame of reference for the entire team. Personas should, of course, be validated and built around user interviews and surveys — that is, real people.

    There are some key aspects of the people who will use our APIs that need to play into the personas we build:

    • Their relationship with the product;
    • The platform and programming language they’re working in;
    • Their experience and skill level;
    • Their English proficiency;
    • The motivation behind the integration work they’re doing;
    • The resources they have available; and
    • Their role within their organisation.

    Ensuring that the APIs we build actually do work, and are usable, we need to undertake testing. We should test both passively and actively.

    Passive testing involves looking at pieces of data such as support requests, and answering questions like “where are users asking for help?”, “what concepts are frequently misunderstood?”, and “what errors are hit often?”. We should look at API usage during an integration, extracting data such as the time between app registration and first request, the first requests and errors encountered, and the time between start of integration and production. We should also look at API usage after integration to find out information about which endpoints are actually used, and how — this will help to answer questions around what the integration is trying to achieve. It also makes it easier to track down antipattern usage of the API.

    Active testing is, by its nature, going to be used more infrequently. For existing APIs, you can take the “dumb pair programmer” approach — basically, go sit with someone working against the API and silently observe what they’re doing. Look for things like interactions with their team (how do they talk about us?), how we fit into their application, how they approach the integration, what problems they encounter (and how they go about solving those), and how they test the integration.

    For new APIs, we can build throw-away prototypes, or a mock API (a simple façade over an existing API, or a fully-mocked API). In either case, there should be just enough functionality to be useful, and it should be fully-documented. Put together a well-defined project, ready for an integration, and get an outsider (who lacks insider assumptions) to build the project. You can go to the extent of recording their face and the screen as they work to see how they react; alternatively, or additionally, have them commit their work regularly (every 10m or so) so that it can be tracked. This allows you to then track emotional responses, and see how long tasks took to complete. It also helps to see where the process can be made more affirming, and how errors can better be handled.

    The secret to machines talking to machines is to speak human first.

    API versioning was brought up in the questions afterwards, and Jeremiah noted his repugnance for such schemes. A recommendation he had, though, was to maintain the two versions for a period of time, and allow developers to “opt in” to the new version when they’re ready: this is the approach taken by Facebook.

  • Determining a table cell’s x and y position/index

    When working with HTML tables, we often want to extract the column and row index for a particular cell. Easy enough, surely — just use row.rowIndex and cell.colIndex, right? Well, no.

    The spanner in the works

    …is the presence of cells that span rows or columns (apologies for the terrible pun). For example, in the following table:

    abcd
    efg
    hij
    klmn

    the column index of cell “g” is reported by the browser to be 2 — when in fact it should be 4!

    The solution

    Fortunately, there is a solution. The code below is based on this very old example by Matt Kruse. I updated it, tidied it up, and MooTools-ified it.

    Usage

    Simply call “getCellCoords” on the (header) cell you’re interested in. This will return an object containing “x” and “y” members — the column and row index, respectively.

    The code

  • TrackPerformer step-by-step

    I’ve had a request to put together a guide explaining exactly how to build a performance using TrackPerformer. This post will walk you through the process, from preparation to presentation.

    Please note that this guide assumes you are working with an Impulse Tracker or OpenMPT module; if you are not, you will have a bit more work to do.

    Ingredients

    To build your performance, you will need the following items:

    • The original module file (IT or MPTM format)
    • The exported audio file (preferably in OGG, MP3, and M4A formats, for maximum cross-browser compatibility)
    • A copy of the ModReader source (which you can download from GitHub)
    • A copy of the TrackPerformer source (which you can also download from GitHub)
    • A decent plain text editor (not Word) — I recommed Komodo IDE or Komodo Edit.
    • A recent and decent web browser — Firefox, Chrome, or Opera work best.

    With these in hand, you’re ready to get going!

    Method

    1. Set up

    If you haven’t already, extract TrackPerformer to the folder of your choice. When you do so, you’ll notice that there are several sub-directories: “Examples”, “Source”, and “Utilities”. Create a new directory, called “Performances”.

    Copy the file “template.html” from the “Examples” directory, renaming it to the name of your track.

    Next, copy your exported audio files into the “Performances” directory; ensure that they all have the same file name (bar the extension).

    Create a new, blank file, with a “.js” extension and named the same as your track. Load this file in your editor.

    Finally, load the HTML file in your editor, and add a <script> tag just before the closing </head> tag that references your JS file. For example, if your JS file was named “purple.js”, you would type:

    <script type="text/javascript" src="purple.js"></script>

     2. Conversion

    The next step is to convert your file into a format that TrackPerformer understands. This means noting down when every note is played, and by which instrument. It also means extracting information such as the tempo, time signature, and song title.Fortunately, if you’re using an IT or MPTM module, the ModReader utility is able to perform this (rather tedious) step for you.

    If you are not using a format that ModReader is able to convert, you will need to complete this step manually. If your file can be opened in OpenMPT, it is possible to use a JavaScript macro in Komodo IDE/Edit to facilitate this; otherwise, you will need to craft the entire lot by hand.

    If you have not already done so, extract the ModReader zip file to a suitable location. Then, in your web browser, load the “index.html” file from that location.

    Select the file you would like to convert. Note that ModReader does all of its processing on your computer — it doesn’t send your file anywhere, and won’t change its contents, either.

    All going according to plan, there should now be a lot more text on-screen. Copy everything between the dashed lines (not including the lines), and paste it into your performance’s JS file. This is the TrackPerformer-compatible version of your module,in a format known as JSON.

    3. Write some JavaScript

    As I said earlier, ModReader gives you a JSON representation of your track, which is great. However, we need to now pass this representation through to TrackPerformer. To do this, we need to write some JavaScript to go around this JSON representation. Edit your JS file so that it looks something like this:

    [sourcecode language=”javascript”]window.addEvent(‘domready’, function() {
    var controller = window.controller = new barryvan.tp.Controller({
    background: ‘rgba(230,230,230,0.5)’,
    meta: {
    colour: ‘rgba(0,0,0,0.5)’,
    visible: false
    }
    }, $(‘container’) || document.body);
    controller.perform({
    title: ‘Foo bar baz’
    /* the rest of the track… */
    });
    });[/sourcecode]

    What we’re doing here is creating a new Controller, and telling it to perform the track.

    4. Make some noise

    The next step is to point TrackPerformer at the MP3, OGG, and M4A exports of the music. To do this, find the line in your JS file that reads

    "audio": ""

    . In the empty quotes, put in the filename of your audio (without any extension). If your audio is on the web, put in the full URL (again, without the extension). Your JS file will now look something like this:

    [sourcecode language=”javascript”]{
    /* snip */
    “audio”: “mice”
    /* snip */
    }[/sourcecode]

    Now, load up your HTML file in your web browser. You should be able to listen to your track. Next up, we’ll add a performer.

    5. Add a performer

    Each instrument in your piece can have zero or more performers assigned to it. There are a variety of performers that you can use, each of which offers a unique visual representation of your music. Each performer has a variety of options which affect its function and appearance. These include colour, size, position, vitality, and many others.

    Each performer is defined in a code block that looks something like this:

    [sourcecode language=”javascript”]{
    performer: barryvan.tp.performer.Oscillator,
    options: {
    colour: ‘#f00’,
    stepSize: 10,
    sustain: true,
    middle: 58
    }
    }[/sourcecode]

    The block above means that we want an Oscillator (performer: barryvan.tp.performer.Oscillator). We have set some of its options (options: { … }) such that it is bright red (colour: ‘#f00’), that a semitone is 10 pixels in size (stepSize: 10), and that its middle note (vertically centred in the performance) is 58 (middle: 58), or A#4.

    If you look at your JS file, you should see a section labelled “instruments”, which will look something like this:

    [sourcecode language=”javascript”]”instruments”: [
    {
    “name”: “Melody”,
    “performers”: []
    }
    ][/sourcecode]

    Put the performer’s code block between the [], like so:

    [sourcecode language=”javascript”]”instruments”: [
    {
    “name”: “Melody”,
    “performers”: [{
    performer: barryvan.tp.performer.Oscillator,
    options: {
    colour: ‘#f00’,
    stepSize: 10,
    sustain: true,
    middle: 58
    }
    }]
    }
    ][/sourcecode]

    Now, if you reload your performance in your web browser, you should have something on-screen. You can add more performers to the other instruments in your piece in the same way. If you want more than one performer for the same instrument, you can simply place a comma after the closing brace of the performer block, and start the next one.

    6. Add some filters (optional)

    Filters can manipulate the entire presentation. They can, for example, shift pixels around, draw a grid, or simply calculate the framerate.

    Filters are applied to each frame of the animation, and can be applied before or after the performers have been processed. Filters that are processed at the start of each frame go under “prefilters”; those processed at the end of each frame are entered under “postfilters”.

    Let’s shift some pixels around using the “Pick” filter. Like performers, filters are defined in a block of code:

    [sourcecode language=”javascript”]{
    filter: barryvan.tp.filter.Pick,
    options: {
    fuzz: 2
    }
    }[/sourcecode]

    We’ll add this into the “prefilters” section:

    [sourcecode language=”javascript”]”prefilters”: [][/sourcecode]

    becomes

    [sourcecode language=”javascript”]”prefilters”: [{
    filter: barryvan.tp.filter.Pick,
    options: {
    fuzz: 2
    }
    }][/sourcecode]

    If you reload your performance in your web browser, things should look a little more fuzzy.

    Filters can have a huge impact on the overall “feel” of your performance. They can soften the performers’ hard edges, and give the entire performance a more natural appearance.

    7. Present

    Once you’ve added more performers, adjusted colours, and fiddled with the CSS on your HTML file, you’re ready to take to the stage. Simply upload the “Source” directory and your performance to your webserver (making sure to keep relative paths intact), and publish the URL. You don’t need to do anything on the server: TrackPerformer is entirely client-side.

    8. Ask questions

    If you run into problems, or have a question, don’t hesitate to leave a comment or raise an issue on GitHub. You’re also more than welcome to fork the project, and build your own performers and filters — if they’re pulled back into the main TrackPerformer tree, then everyone else can use them, too!

    Appendix

    A. Converting notes to numbers

    Notes are in the range C-0 to B-9, and are numbered from 0 to 119. To find the number for a particular note, use this formula: x = note + (octave * 12). In this formula, the note C is 0, C# is 1, D is 2, and so on.

    B. TrackPerformer Wiki: performers, formats, etc.

    The TrackPerformer Wiki has details on all of the performers, the performance format, the filters that are available, and the controller options.

  • TrackPerformer update

    I’ve added in some really exciting new features to my TrackPerformer project, as well as three new performances: We Three Kings, Carol of the Bells, and Joy to the World.

    Filters

    It’s now possible to add filters, or effects, into the processing chain. These filters can be applied before any performers (pre-filters) or after all performers (post-filters). At the moment, the included filters are:

    • FPS: Calculates the average framerate across the performance, optionally displaying it in a DOM element.
    • Grid: Draws a grid to the canvas. The grid may be a simple intersection grid (points), or lines. Both the X and Y axes may be independently configured.
    • Pick: Probably the most interesting (and processor-intensive) part of TrackPerformer. The Pick filter will randomly swap a pixel with one of its neighbours. It’s used at full intensity on both We three Kings and Joy to the World, and, when toned down a little for Carol of the Bells, provides a softening, organic effect.

    I’ve got some ideas for more filters down the track… The only difficulty is keeping performance acceptable: manipulation of the canvas pixel by pixel is quite slow in current browsers.

    Performers

    There are a couple of new performers, and some minor updates to some of the existing ones. The Oscillator performer, in particular, is rapidly becoming the most flexible and useful of the performers.

    • There’s a new ShimmerGrid performer, which is great for adding texture and movement to the entire canvas. You can see it in action particularly well on Joy to the World.
    • The Swarm performer can now draw its particles as knots (like the SignalTracker), as well as as dots.
    • The Oscillator now has the ability to draw sustained notes, and to increase the longevity of notes. Take a look at Carol of the Bells to see these new options in use.
    • Notes can now be filtered based not only on their pitch, but also their velocity (volume).

    There are a couple of other changes here and there, but these are the main ones.

    We Three Kings

    The three new example tracks are all taken from We Three Kings, my new Christmas remix album. Why not go and have a listen?

  • TrackPerformer

    TrackPerformer provides a visual stage for your music, using HTML5 canvas and audio. On that stage, performers “play” the instruments in the music visually. In other words, it’s a visualisation system for music, but based on the notation (the abstract) rather than the audio (the manifestation).

    Essentially, you take a piece of music, convert it into a format that TrackPerformer understands (JSON), describe how you want it to be performed, and then watch! You can, of course, write your own performers.

    Before going any further, let’s see it in action. The music is “Colony”, a new piece that I wrote about a week ago.

    Note: You won’t be able to view the performance linked above in Internet Explorer, due to its over-aggressive script-blocking: the scripts served from GitHub have the wrong mime-type, so IE won’t let them run.

    Take a look at the project on GitHub to see how it all fits together. TrackPerformer itself resides in the “Source” directory; in “Examples”, you’ll find the performance of Colony; in “Utilities”, there’s a JavaScript macro for Komodo IDE/Edit that will help you to translate copied-and-pasted OpenMPT pattern data into TrackPerformer’s JSON format.

    You can find more information on the TrackPerformer wiki, including an outline of the format, and some basic instructions for getting started. I’ll be adding more information to the wiki over the next few days, and I’ll post updates here too.

    Let me know what you think!

  • (Un)quoted HTML attributes

    In HTML, it’s perfectly valid to write something like this:

    [sourcecode language=”html”]

    Lorem ipsum dolor sit amet etc.

    [/sourcecode]

    Indeed, Internet Explorer 7 and 8 favour this approach. Whereas Firefox, for example, would return the above as

    [sourcecode language=”html”]

    Lorem ipsum dolor sit amet etc.

    [/sourcecode]

    when retrieving it using innerHTML, IE 7 & 8 only quotes attributes that satisfy certain criteria:

    • Any attributes that contain spaces;
    • Some magic set of standard attributes, such as href;
    • Any custom attributes you may have specified.

    Unfortunately, however, this doesn’t constitute well-formed XML. In the software I develop at work, we produce PDFs that can include user-generated HTML. To do this, we use XSL:FO — an XML-based system. You can see where this is going: the backend requires valid XML, but the frontend is sending through HTML. The simplest way to fix this is with a simple regex, like so:

    [sourcecode language=”javascript”]var s = ‘

    Lorem ipsum dolor sit amet etc.

    ‘;
    s = s.replace(/=([^”‘`>\s]+)/g, ‘=”$1″‘);
    // s === ‘

    Lorem ipsum dolor sit amet etc.

    ‘[/sourcecode]

    Bear in mind that this regex is by no means perfect. It will, for example, convert this:

    [sourcecode language=”html”]

    Lorem ipsum

    dolor sit=amet

    [/sourcecode]

    into this:

    [sourcecode language=”html”]

    Lorem ipsum

    dolor sit=”amet.[/sourcecode]

    …which is obviously not what we want. I spent a while trying to come up with a regex that would solve this problem, but I stopped pretty soon. What’s really needed here is a parser: something that can take in the tag soup that Internet Explorer produces, and produce valid XHTML (which is valid XML). A quick search reveals myriad implementations in various languages — Python, Java, even JavaScript.

    So, after all that, what’s the take-away from this post? Just this: web browsers (slightly older versions of Internet Explorer in particular) are imperfect. XML was borne out of HTML, and is much less forgiving; whether or not its strictness is a good thing is up for debate. I guess that it’s a bit like reading Shakespeare nowadays: you can pretty much understand it, but every now and then you have to reach for a dictionary to make sense of what’s going on. Of course, when you don’t understand something in Shakespeare, you don’t fall over in a heap, but let’s not stretch the analogy too far.

    In brief

    When retrieving the innerHTML of an element (or using contenteditable), Internet Explorer doesn’t always wrap attribute values in quotes. The solution to this is not a magnificently obtuse regex, but a tag-soup parser that can return valid XML.

  • Paired sort in JavaScript

    Sometimes, you’ll have two arrays of associated data, and you’ll need to sort them. You can’t just call sort() on both arrays, because that will potentially break the associations between them. What you need is a way to sort one of the arrays, and shuffle the elements of the second array to match. Here’s a simple MooTools function that does just that (using quicksort):

    [sourcecode language=”javascript”]Array.implement({
    pairedSort: function(other, reverse) {
    if (this.length === other.length) {
    for (var i = 0, len = this.length; i < len; i++) { var curr = this[i]; var currOth = other[i]; var j = i - 1; while ((j >= 0) && (this[j] > curr)) {
    this[j + 1] = this[j];
    other[j + 1] = other[j];
    j–;
    }
    this[j + 1] = curr;
    other[j + 1] = currOth;
    }
    }
    if (reverse) {
    this.reverse();
    other.reverse();
    }
    return this;
    }
    });[/sourcecode]

    Using this function is quite straightforward:

    [sourcecode language=”javascript”]var alpha = [3,2,1,6,5,4];
    var beta = [1,2,3,4,5,6];
    alpha.pairedSort(beta);
    // alpha == [1,2,3,4,5,6]
    // beta == [3,2,1,6,5,4][/sourcecode]

    When would this actually be useful? Let’s say you’ve got an object which maps numeric assessment scores to an alphabetic grade:
    [sourcecode language=”javascript”]var mapping = {
    ‘A’: 80,
    ‘B’: 60,
    ‘C’: 40,
    ‘D’: 20,
    ‘E’: 0
    }[/sourcecode]
    Unfortunately, objects in JavaScript have no intrinsic order on their keys — this is because they’re essentially just hashmaps. What we need to do to be able to make use of these data, then, is create an array of keys, and one of values, and then sort them. The pairedSort() function allows us to do this easily. (In fact, it’s for this exact application that I wrote the method!)

  • JS1K: Swarms

    In the spirit of the demoscene, the JS1K competition is designed to make people push their boundaries. The competition requires entrants to write an interesting, appealing demo in JavaScript, using no more than 1024 characters (hence the name).

    Of course, I had to have a shot at it. (See the result!) I decided to revisit one of my favourite toy projects: my swarms. What I came up with is this (linebreaks added for convenience):

    [sourcecode language=”javascript”]a=Math,b=a.random,c=[],j=document.getElementById(“c”),k=j.getContext(“2d”),m=window,n=(W=m.innerWidth)/2,q=(H=m.innerHeight)/2,r=M=1;function s(o,p,u,v){k.fillStyle=o;k.beginPath();k.arc(p,u,v,0,a.PI*2,0);k.closePath();k.fill()}function t(o,p){for(g=40;g–;)if(!c[g]){c[g]={x:o||n,y:p||q,d:o?b()*4-2:0,e:p?b()*4-2:0,b:1,a:0,c:b()>.5};return}}with(j.style){position=”fixed”;top=left=0}j.width=W;j.height=H;for(f=40;f–;)c[f]=0;for(f=9;f–;)t(); m.setInterval(function(){k.fillStyle=”rgba(9,9,9,.2)”;k.fillRect(0,0,W,H);for(f=40;f–;)if(d=c[f])if(d.a>1E3)c[f]=0;else{l=d.a/1E3;h=l*7;d.d+=b()*.1*(n-d.x>1?1:n-d.x<-1?-1:n-d.x);d.e+=b()*.1*(q-d.y>1?1:q-d.y<-1?-1:q-d.y);d.x+=d.d;d.y+=d.e;d.a++;i=d.c?"rgba(49,153,255,":"rgba(255,49,166,";h=1-l;s(i+h+")",d.x,d.y,1+l*12);s(i+h/2+")",d.x,d.y,1+l*16);d.b&&d.b--;if(d.b==0&&d.a>250&&d.a<750&&b()>.9)for(g=40;g–&&!d.b;)if((e=c[g])&&e!=d&&e.a>=d.a){i=a.sqrt(d.x-e.x,d.y-e.y);if(i>-5&&i<5&&d.c!=e.c){t(d.x, d.y);d.b=e.b=10}}}r=n>W||n<0?-r:r;M=q>H||q<0?-M:M;n+=r;q+=M},40);[/sourcecode]You can see the submission here: http://js1k.com/demo/270. To reduce the size, I first coded tightly, ran the uncompressed code through Google’s Closure Compiler, then hand-tweaked the result to save a few more bytes. I’m quite pleased with the result! For the curious, the full, uncompressed, commented source is below:

    [sourcecode language=”javascript”]/* SWARMS (v1.7)
    * by Barry van Oudtshoorn (www.barryvan.com.au)
    * A re-implementation of http://www.barryvan.com.au/demos/swarms/swarms.html,
    * which in turn is a reimplementation of a Processing script that I wrote.
    *
    * Male and female particles move around a central point, gradually aging.
    * When they reach maturity, they may interact with a particle of the opposite
    * sex to spawn a new particle. As they grow old, they become larger and slower
    * until they eventually die.
    *
    * Revisions (really, these version numbers are all but meaningless!)
    * 1.0 (1023B)
    * – Initial code.
    * 1.5 (1017B)
    * – Moved to Closure compiler to reduce size
    * – Some slight tweaks to particle movement
    * – Canvas now positioned to get rid of annoying border (try fullscreen!)
    * 1.7 (1011B)
    * – The swarm centre now moves around (simple bouncing). This allows the
    * particles to pick up a bit more speed, and move in more interesting ways;
    * where before they tended to just ‘bubble’ in the middle of the screen,
    * the swarm, as an entity, now appears more fluid and organic.
    * – Bugfix to spawning: particles now actually have to be near to each other
    * in BOTH axes to spawn, and both particles have to be of suitable age. This
    * prevents billions of particles from spawning from a single one.
    * – Reduced the total number of particles for aesthetic reasons
    * – Did some more “by-hand” optimisations after running it through the closure
    * compiler, like removing global variable declarations when I’m not
    * instantiating the variables there and then and removing the leading 0 on
    * decimal values to conserve precious bytes. With each revision, despite
    * adding functionality each time, the size is going down!
    *
    * Copyright 2010 Barry van Oudtshoorn.
    */

    var z = function(a, b, c) { // Normalise a to between b and c
    return (a / (c – b));
    },
    h = function(a, b, c) { // Limx a to between b and c
    return (a > b ? b : (a < c ? c : a)); }, // I strip out all of the uninitialised declarations after compilation; // they're globals anyway. I know it's not stylish, but it saves bytes! r,s, // Particles that we're currently interested in i,j, // Iterators u,d, // Working variables m = Math, // Alias v = m.random, // Alias p = [], // The particles e = document.getElementById('c'), // The canvas element t = e.getContext('2d'), // The context n, // The normalised age of a particle Q = window, // Alias X = (W = Q.innerWidth)/2, // The swarm's COG Y = (H = Q.innerHeight)/2, N = M = 1, // The components of the velocity of the swarm's COG q = function(a, b, c, f) { // Draw a blob t.fillStyle = a; t.beginPath(); t.arc(b, c, f, 0, m.PI*2, 0); t.closePath(); t.fill(); },x = function() { // Global iterator //t.globalCompositeOperation = 'source-over'; // This is prettier, but "globalCompositeOperation" takes too many bytes! t.fillStyle = 'rgba(9,9,9,.2)'; t.fillRect(0,0,W,H); //t.globalCompositeOperation = 'lighter'; for (i = 40; i--;) { // Loop over all of the particles if (r = p[i]) { if (r.a > 1E3) {
    p[i] = 0; // Kill off old particles; use 0 because it’s shorter than false, null, or using delete.
    } else {
    // Move the particle
    n = z(r.a, 0, 1E3);
    u = n * 7;
    r.X += v() * .1 * h(X – r.x, 1, -1); // Update the particle’s velocity.
    r.Y += v() * .1 * h(Y – r.y, 1, -1);
    r.x += r.X; // Update the particle’s coordinates based on its velocity.
    r.y += r.Y;
    r.a++; // Increment the particle’s age

    // Draw the particle

    d = r.s ? ‘rgba(49,153,255,’ : ‘rgba(255,49,166,’; // The colour of the particle
    u = 1 – n; // The opacity of the particle; n is the normalised age
    q(d + u + ‘)’, r.x, r.y, 1 + n * 12); // Draw the primary particle blob
    q(d + (u/2) + ‘)’, r.x, r.y, 1 + n * 16); // We draw a lighter, larger blob for a ‘glow’ effect

    r.f && r.f–; // If we’ve spawned, decrement the cooldown.

    if (r.f == 0 && r.a > 250 && r.a < 750 && v() > 0.9) { // If we’re the right age, check if we can spawn!
    for (j = 40; j– && !r.f;) { // We have to loop over the particles again, and see if we’re close enough to spawn.
    if ((s = p[j]) && s != r && s.a >= r.a) {
    d = m.sqrt(r.x – s.x, r.y – s.y); // Two if statements to avoid this calculation if possible
    if (d > -5 && d < 5 && r.s != s.s) { // Collision detection? What's that? y(r.x, r.y); // Spawn a new particle! r.f = s.f = 10; // Enforce the spawning cooldown } } } } } } } // Bounce the swarm's COG around the canvas N = (X > W || X < 0 ? -N : N); M = (Y > H || Y < 0 ? -M : M); X += N; Y += M; },// Spawn a new particle. If sx and sy are defined, they will be its initial // coordinates; otherwise, we just the COG. If sx and sy are defined, we also // give the particle a random velocity; this means that they're 'flung out' // from their parents; at startup, though, we want them all nicely bunched. y = function(sx,sy) { for (j = 40; j--;) { if (!p[j]) { p[j] = { x: sx || X, // The particle's coords y: sy || Y, X: sx ? v() * 4 - 2: 0, // The particles velocity Y: sy ? v() * 4 - 2 : 0, f: 1, // Cooldown after spawning a: 0, // The age of the particle s: v() > .5 // The sex of the particle
    }
    return;
    }
    }
    };

    // Make the canvas fill the entire screen
    with (e.style) {
    position = ‘fixed’;
    top = left = 0;
    }
    e.width = W; // Set the canvas width and height
    e.height = H;

    for (i = 40; i–;) p[i] = 0; // Populate initial particles
    for (i = 9; i–;) y(); // Spawn eight particles. A number < 10 saves a byte!Q.setInterval(x, 40); // Make it go. [/sourcecode]

  • Generative Music

    Continuing my HTML5 and canvas experiments, I’ve put together a generative music system. Essentially, a series of particles move across a field, occasionally triggering sounds — the sound triggered depends on their location in the field.

    There is, of course, a little bit more to it than that. Under the hood, I’ve got a series of HTML5 Audio objects that are used to provide polyphonic audio using a simple round-robin algorithm (I encoded the audio in OGG, so you’ll need to use an OGG-friendly browser, like Firefox). The particles are much simpler than those in my previous canvas dalliance, in that they don’t swarm, and their motion is more linear.


    Generative Audio Screenshot
    View (and hear!) it live

  • Canvas Swarms

    I’ve been meaning to start playing with the HTML5 <canvas> element for a while now, and yesterday I took the opportunity. I translated a Processing sketch I made a while ago into JavaScript (with a few minor enhancements).


    Swarms Screenshot
    View it live

    Essentially, 1 to 3 swarms of particles move around the canvas, reproducing when the conditions are just right, and dying of old age. Quite simple, but the patterns produced can be really quite pretty.

    One interesting thing that I discovered whilst doing this is that you can’t pass around a canvas’ context at the instantiation of a MooTools class — it complains about wrapped natives. That’s why, if you like in the source JavaScript, you’ll see me pass the actual context around to various functions. I’d be interested in hearing if anyone has a workaround for this, because this is, well, a bit clunky.

  • HTML: IE file submission

    I’ve been bumping up against an interesting bug in Internet Explorer recently, and, having just found the solution, thought I’d share it with you.

    The problem is that in Internet Explorer (tested 7 & 8), when your document is in quirks mode, uploading a file sometimes just sends through the file name, without the actual body of the request. Put the document into standards mode, and it all works. It should be noted that this is when you’re dynamically setting up the elements used with JavaScript.

    The cause? In quirks mode, the enctype attribute isn’t supported. So whilst setting “encType” on the form element to the correct “multipart/form-data” will indeed set this attribute, it won’t actually cause the upload to include the file. Instead, you need to set the encoding attribute to this value, too. It certainly doesn’t help that the MSDN article on the <input type=”file”> element tells you to set “enctype”, but makes no mention of “encoding”.

    I couldn’t find any reference to this problem on the intertubes (although maybe I just didn’t look hard enough), so hopefully this will help someone.

  • Javascript: Print a single element

    Sometimes, you’ll want to allow users the ability to print only a part of your page; for example, a table but not the various links around the page. It’s possible to use a printing stylesheet, but this can cause severe headaches when you need different parts printed at different times. Really, we want to be able to just say element.printElement(), and have it just work. That’s what the MooTools function below does. It’s loosely based around the concepts outlined at this website.

    [sourcecode language=”javascript”]Element.implement({
    printElement: function(docTitle) {
    var strName = ‘printer-‘ + (new Date()).getTime();
    var styles = [];
    $$(‘link[type=text/css]’).each(function(style) {
    styles.push(‘‘);
    });
    var title = docTitle || document.title;
    var that = this.getParent();
    var iframe = new IFrame({
    name: strName,
    styles: {
    width: 1,
    height: 1,
    position: ‘absolute’,
    left: -9999
    },
    events: {
    load: function() {
    var doc = window.frames[strName].document,
    win = window.frames[strName];
    var f = function() {
    if (!doc.head) {
    f.delay(10);
    return;
    }
    // We need to delay printing so that styles are applied.
    (function() {
    doc.title = title;
    // IE7 won’t let us adopt() here for some reason, and we can’t do anything to the head.
    doc.body.innerHTML = styles.join(”) + that.innerHTML;
    (function() {
    win.focus(); // IE needs the window to be focused.
    win.print();
    }).delay(100);
    }).delay(200);
    };
    f();
    }
    }
    }).inject($(document.body));
    (function() {
    iframe.dispose();
    }).delay(30000);
    }
    });[/sourcecode]