MashLogic

I'm taking a few moments' refuge from the growing absence of furniture in my echoing soon-to-be former home in Sweden (as my household and me are finally moving to the California Bay Area now -- after about two years more or less stuck in that ghastly red tape/inertia land), to join the little crowd of my coworkers at MashLogic, that are just cheerfully lifting the veil off our Firefox/Flock extension of the same name: MashLogic sets sail!

Update: TechCrunch liked us too. Yay! :-)

A close sibling of Greasemonkey's, we try to shift how the web works, from the walled gardens we have today (where a feature you like would stay within the confines of a particular web site, or, at best, group of web sites) -- towards working more like how communicating vessels or a sea of information would: add a feature you like once, and have it propagate across the entire sea, wherever you may roam.

Let's say you love how some web site offers explanations of the difficult words it uses, or even links advanced concepts to their Wikipedia article counterparts. While that is a neat feature, the rest of the web remains stuck on its now annoying lower evolutionary notch, devoid of it.

We think such features should not be implemented in server side logic, once per site, to give you the benefit of it only on a small fraction of the web: they should be part of your browser's toolbox and normal web browsing experience, and subject to your own control and choices.

That is what we have browser extensions for in the free software world. The extension user experience in Firefox isn't without its flaws, though; easy toggling of functions you might want or not is not is always subject to whether the extension implements its own such toggle, and if they do, they all end up having Yet Another User Interface, yet another icon or menu entry somewhere, and so on. And while you can disable any extension, you have to restart the browser to be rid of it, and for reversing the operation, restart yet again. There is a very distinct lack of convenience there.

Greasemonkey improved that picture a lot -- Greasemonkey user scripts all show up the same way in the monkey menu, and you have both an effective off switch for them all in one go, and each individually by checking or unchecking them, at the less insane cost of just reloading the page. MashLogic lets you toggle them and have them apply or undo their effects in real time instead, thus letting you play even comfier still, without even reloading the page, and much less restarting the browser.


It is some rather boring menial labour doing much of the text crunching that goes into a user script or extension that scurries through document node trees too, if you were to make one doing things like the above -- or perhaps an automated currency converter that translates weird foreign price tags, or articles or blog posts naming amounts in foreign currencies, into your own currency of choice.

The lion's share of the work isn't in mashing up that currency conversion web API you bookmarked the other day with data for it, or even in the challenge of recognizing free form mentions of amount + currency, but in hacking up a little document crawler that finds the stuff and then changes it (without completely locking up the browser). And by the time you realize that, it's not very fun hackery any longer.

We sort of wanted to address that too, making it more like plugging in your regexp, or a little dictionary, in a polished crawler that already does that boring job for you, so you don't end up reinventing those icky wheels over and over again client side too.


The particular examples above are, unsurprisingly, stuff we already provide, among a handful of other features. There is plenty of room to grow in still, even in features available to Greasemonkey users already (for instance, we lack the provisions for installing new mashes, which is what we call the separate MashLogic features), but we'll mature over time, as any tech worth having does.


I'm eager to get back to the hackery again soon, but you would not believe how long this whole real-worldly stuff of moving from one country to another is taking me; it's almost as if this world of physical matter of ours is immune to my wizardry skills. It just does not compute. I think it's broken somewhere. Where do we file tickets on it?

Fun with Greasemonkey: @require

After the release of Greasemonkey 0.8, the door is open for @require helper libraries, the user script take on Ruby's require, or the C family's #include pre-processor directive. For security reasons, the required library is downloaded a single time at script installation time, and from a functional perspective, is equivalent to pasting the script or scripts referenced at the top of your script, in the order of the @require lines listed. (==UserScript== headers in the referenced files are presently ignored, so a library may not yet use @require or @resource lines of its own.)

@require in practice makes user scripting scale down better, which is essentially to lower the threshold towards getting a job done, to a level where implementation cost to scratch an itch is so low that rather than feeling that mild annoyance with something twice, you address the issue once, and never see it happen again -- on that site, or the web at large. We are still far from there (in as much as "getting there" would ever happen -- that threshold can always be chipped off further, I assure you) -- but @require is healthy progress.

This is what the feature can look like in an example script of mine which adds image captions to online comics, by default Dinosaur Comics and xkcd (expect another upcoming post about $x and $X):

// ==UserScript==
// @name      Image title captions
// @namespace http://code.google.com/p/ecmanaut/
// @require   http://ecmanaut.googlecode.com/svn/trunk/lib/gm/$x$X.js
// ==/UserScript==

I'll be sharing some of my own helpers here, in a little series of "Fun with Greasemonkey" posts. I encourage you to write, and share, your own, on your blog, as well. User script authorship is a very social form of software, especially when you share your results on userscripts.org, and your best practices, for instance by way of blogging.

Javascript books

I just received two javascript books I recently ordered from Amazon (the US branch, for once, since the dirt cheap dollar made shipping across the Atlantic notably favourable to shipping across the English Channel): John Resig's Pro javascript techniques and Douglas Crockford's Javascript: the good parts.

I had for the longest time (since the nineties) been of the opinion that the only javascript book worth getting was David Flanagan's Javascript: the definitive guide, which I at the time found excellent in it's third edition and still good (and much updated) in its fourth (by my cursory looks and used for reference, at least), but as two of my favourite authors on the subject of javascript (the last being Dean Edwards, whose primarily means of expression on the subject, so far, at least, is terse, solid code) have been published since then, it was time to challenge that assumption. And I'm quite glad to say that both were up to par.

Pro javascript techniques really shows Resig's experience in library writing, and shares lots of useful input and practices, and provides an enjoyable and rather useful walk-through of the popular javascript libraries of its day, which manages to still be fairly relevant, in spite of the evolution they have seen since its publication. Much the same applies to the bits and details it shares on browsers and the tool-chain, but that is to be expected. (I am really looking forward to its successor, Secrets of the javascript ninja, much of which can already be read online.) Particularly enjoyably and usefully, he shows off strengths of each library without much fuss.

As for Crockford's Javascript: the good parts, it follows his usual seasoned narrative which has earned him nicknames such as "the Yoda of javascript", and keeps a close focus on the more timeless parts of the core language itself, devoid of all the clutter and temporally challenged aspects of the document and browser object models. It follows a clean-slate approach to describing the beautiful parts of the language most worth learning, while warning about the pitfalls of some of its worst warts, and is just as enlightening as the rest of Doug's work. It's something of a feel-good book for javascript buffs wanting to meditate over their use of the language -- or at least it is for myself.

Great companions for a season where the weather merits some good outdoors rather than indoors geekery. ;-)