Been doing some visualisations of Formula1 timing charts, based on the work of Tony Hirst.

Published a short piece on his f1datajunkie blog here with the results

My webapp uses various API's and in particular it pulls in things like Twitter's widget.js - which doesn't have a github home or similar (unlike, say, underscore.js that I can track from its source repository).

I could save my own copy and have my webapp always use that, but that's not such a great idea as when twitter change their API, they also change widget.js to compensate.

So my webapp always pulls in the master authoritative copy, but then I tend not to notice when it changes - and sometimes this breaks my assumptions about how it works (also, changes in widget.js are a good way to track changes to certain API details that I access outside of the widget.js library itself).

So, as there's also no RSS feed about updates or similar, I instead store widget.js in my source repository, even tho my app doesn't use the copy I've stored, and in my development workspace I regularly regularly fetch the latest widget.js (for me, this is in the script to restart my personal development environment, launch the webserver etc but you could do it in a cron job)

   wget -O js/3rd/widget.js http://twitter.com/javascripts/widgets/widget.js

And thanks to the wonders of distributed source code control systems and their "no check out required" model (I use bzr, the same is true of git and others) then if the authoritative version hasn't changed, then this has no effect, but when it does change, I suddenly see the file as modified in my "modified files" report ("bzr status"), and I can diff the new against the old and see if I need to react accordingly.

It's more of a hack than anything else, but works surprisingly well, and has stopped me being caught out (especially with "silent" changes where there's no official communications about such things).

I've been adding some features to UglifyJS - a rather nice JavaScript parser / compressor / beautifier that is itself written in JavaScript.

It implements a JavaScript 1.5 parser, and then has various routines to walk the AST doing things like renaming variables and collapsing selected expressions.

I've added the ability to safely replace selected global symbols with constant values (which can then allow the minifier to collapse entire sections, like #ifdef in C++) which has been pulled into the main tree, and the ability to spot and shortcut constant expressions involving &&, ||, and ?: (ie eliminate the RHS when a true constant value on the LHS means that the RHS will never be evaluated).

I've also added the ability to mangle selected object property names, which obviously needs some care, but is great for obfuscating internals and can shorten long method names etc. This change is only in my fork for now - https://github.com/schmerg/UglifyJS (see the mangleprops branch)

I also toyed with the idea of extending the parser to understand some features of later versions of javascript (eg the very useful let statement of 1.7) and have an option to compile them down to javascript 1.5, so that

   var x = 1, y =2;
    if (something) {
        let x = x+y; 
    console.log("X is now "+x+" and y is "+y);
  }
  console.log("X ends with value "+x);
 

would be re-written as 

   var x = 1, y =2;
  if (something) {
    (function(x) {
     console.log("X is now "+x+" and y is "+y);
   }(x+y);
  }
  console.log("X ends with value "+x); 
 

Yeah, I know about things like coffee-script, but I don't want to be debugging something too far away from my original source, and I hope eventually javascript 1.7 will be supported in more browsers (in which case I can stop using this conversion)

And I'm also thinking about inlining selected methods - I know javascript engines do this internally, but there are sometimes big wins to be had from inlining trivial functions (which you've coded a such to avoid repeating the same expression endlessly). Again this is a bit like the pre-processor in C++, but because it would be done as part of the proper parse process (rather than limited text substitution) then I think it could be done much more safely.

Anyway - I'll post things to github as I go...

 

I wrote a couple of small extensions for Google Chrome, aimed particularly at small annoyances for developers.

It's a great web browser for developers, and there's the Web Developer extension amongst others, but these are two extensions that I can't find elsewhere

• JsError is a minimal extension to flag errors in a page (typically in the javascript) without the need to open the developer tools (which may trigger breakpoints and the like) within Google Chrome™.
• ForceReload is hard reloads the current tab to overcome caching issues when using Developer Tools for Google Chrome™

I should put the code up on github (it's only a few lines) but there are the links anyway.