Here’s an example:

Enter Validator.js.

Validator’s only dependency is on underscore.js from Document Cloud.

Validator has two usage forms: the first for very quick and simple one-off cases:

// Simple use:
var result
result = Validator.isEmail('not_an_email');
console.log(result); // false
result = Validator.isEmail('joe@example.com');
console.log(result); // true

I found this on its own quite a lot more flexible than most of the form-driven libraries out there. However, I also wanted to be able to create more complex sets of validations to run on a piece of data. For that case, you create an instance of Validator and use it’s add() method:

var result,
    myValidator

myValidator = new Validator();

myValidator.add('unique');
myValidator.add('minLength', 6);

result = myValidator.validate( [1, 2, 3, 4, 5, 6, 6] );
console.log(result); // false, the array is long enough but contains non-unique members

This got me a fair bit closer to what I wanted, but you don’t know which part failed, so it’s harder to give reasonable feedback. I added a set of error messages to validator instances which gets populated after a call to validate():

var result,
    myValidator

myValidator = new Validator();

myValidator.add('unique');
myValidator.add('minLength', 6);
myValidator.add('maxLength', 8);

result = myValidator.validate( [1, 2, 3, 4, 5, 6, 6, 8, 9, 10] );
console.log(result); // false, the array is long enough but contains non-unique members
console.log(myValidator.errors);
/*
myValidator.errors == [
    'The list must be made up of unique items',
    'The list is too long'
]
*/

Again, this is pretty good but even though Validator supports adding messages in any language you want and falling back (by default) to English (see the source code), default error messages still aren’t always what you need. I also added the ability to set a custom error message per “validation”.

var result,
    myValidator

myValidator = new Validator();

myValidator.add('unique').message('You are repeating yourself');
myValidator.add('minLength', 6).message('Too tiny!');
myValidator.add('maxLength', 8).message('Too bloated!');

result = myValidator.validate( [1, 2, 3, 4, 5, 6, 6, 8, 9, 10] );
console.log(result); // false, the array is long enough but contains non-unique members
console.log(myValidator.errors);
/*
myValidator.errors == [
    'You are repeating yourself',
    'Too bloated!'
]
*/

You can also chain calls to add() and message():

var result,
    myValidator

myValidator = new Validator();

myValidator.add('unique').message('You are repeating yourself')
    .add('minLength', 6).message('Too tiny!')
    .add('maxLength', 8).message('Too bloated!');

I’ve added some code which should make it easy to use this as a CommonJS AMD javascript module. In it’s default form you can just include it with a script tag.

If you’re interested in developing Validator itself, the project is tested with Jasmine and documented with JSDoc. Both of these can be run with Rake, and the easiest way to get setup is to use Bundler. Once you’ve got the dependencies you get three rake tasks:

# Start the jasmine server, and open http://localhost:8888/ to run the test suite:
$ rake jasmine
# Start the jasmine server and also run a browser through the tests automatically:
$ rake jasmine:ci
# Generate the docs
$ rake jsdoc

If you fork the project and add any more validations, please also add tests and docs.

https://gist.github.com/1139797

Next step … running the tests in parallel!

It’s not really infinite of course, I haven’t made any attempt to have a position greater than Number.MAX_VALUE. The real point is that it is possible to have a huge playing area, and only the living & possibly-living-next-round cells are taken into account.

I avoided using any ready-made frameworks, in part so that it could be transported to the server-side on top of something like NodeJS – I was imagining a multi-player game where each user could “paint” cells onto the canvas, and maybe even that next-generation cells would take an identifier from their parents, letting people “fight”. I haven’t really got the time for that at the moment, but it seemed a nice idea.

<ul>
  <li>
    <input id="r1" name="something" type="radio" value="basic" />
    <label for="r1">Basic</label>
  </li>
  <li>
    <input id="r2" name="something" type="radio" value="standard" />
    <label for="r2">Standard</label>
  </li>
  <li>
    <input id="r3" name="something" type="radio" value="advanced" />
    <label for="r3">Advanced</label>
  </li>
</ul>

<script>
$("input[name='inputName']").change(function(ev) {

});
</script>

Opera RTL Scrolly Text Indent Bug.

If your content is RTL and you are using the large text-indent CSS property on an input tag (so that you can use a background image, while keeping the text invisible to most users but still available to screen readers) you get a couple of odd behaviours in Opera:

1. The text is not indented. Well ok, that’s at least a “normal” kind of bug.
2. If you right-click on the button, and leave the menu open for a few seconds, the text magically starts scrolling out of the way.

I’ve submitted a bug report to Opera. I’d be interested if anyone else is seeing the same behaviour, or any related RTL weirdness.

EventEmitter on github

It’s fairly simple to use … something like this:

var MyKlass = function() {};
EventEmitter.augment(MyKlass.prototype);

/**
 * Show me
 *
 * @fires shown
 */
MyKlass.prototype.showMe = function() {
  this.trigger('shown', {'visible':true});
}

var myInstance = new MyKlass();
myInstance.on('shown', function(e) {
  console.log(e.visible);
}
myInstance.showMe();

This is really useful, since so many displays are widescreen these days, and it also means you can create a reasonable dashboard with screen. The patch has worked without a hitch for me so far.

Thanks Evan!

We have very high accessibility standards, and the current “{modal:true}” option for the dialog widget unfortunately wasn’t as good as we needed. Seeing that the team had identified the need for a standalone Modal widget, the team thought we could try and get the ball rolling.

You can see the work in progress here in the modal widget in my fork of jquery ui.

I’ve also been having a discssion about the modal widget with Scott Gonzalez of the jQuery UI team.

These are both fine for most cases, but what about a situation where you have a hard dependency on the css for the javascript to work correctly? You could take a best-guess at a wait time for the CSS to load, or even set the XHR to be synchronous – however both of these are very poor for both actual and perceived performance of your page (and the former may simply fail).

When might this be the case? Let’s say you have some asynchronously loaded javascript that is intended to create a widget on the page, something like this (which assumes you are using jQuery as your dom library):

function moveLargePanels() {
    // make a panel container for large panels
    $('<div id="largePanelContainer"></div>')
        .appendTo('body');
    $('.panel').each( function(i, panel) {
        if ( panel.outerWidth() > 300 ) {
            panel.appendTo('#largePanelContainer');
        }
    }
}

And some corresponding CSS:

.panel {
    border:1px solid #000;
    padding: 20px;
}

The idea here is that, since there is some interaction between the logic in the javascript (a test for the “outerWidth”) and the styling in the CSS (setting the padding) that the javascript can only work correctly once the CSS has been loaded and applied.

This should be fine right? Start the javascript and the css loading, and have events attached to the load of each letting you know when everything is ready and it’s safe to fire “moveLargePanels()”. Wrong, or at least tricky, and essentially impossible if the CSS is loaded from a different domain to the hosting webpage.

You can get James Burke’s excellent description of this problem here:
http://requirejs.org/docs/faq-advanced.html#css
And a first pass at solving this (in some browsers) here:
http://bugs.dojotoolkit.org/ticket/5402

Burke mentions a using a “well known” style rule to test whether the style is loaded. I suggest a standard pattern for the rule, and also a mechanism for dynamically setting it.

Enter CSSP

You may have heard of JsonP – a way of serving dynamically generated JSON which is padded with a method call (the method name is supplied in the query string of the URL), which allows for cross domain loading of javascript. The idea behind CSSP is similar – it defines a pattern for loading css cross domain. Instead of wrapping in a callback though, we can use the URL query string mechanism to supply the special “test rule” that we use.

Dynamic Rule Pattern

Given this url:

http://someserver.com/stylefile.css?cssp=123456

.panel { ... }
.largePanelsContainer { .. }

/* and the special rule: */
cssp { zIndex:123456; }

So, in whatever loader we want to build, we can add something like this (n.b. this isn’t tested code):

var cssp_counter = 0;
function loadCss(url, callback, className, zIndex) {
    // create a counter for special class names, so they are unique
    className = className || 'cssp' + (cssp_counter++);
    zIndex = zIndex || 123456;
    url = url + '?' + className + '=' + zIndex;
    $('<link>')
        .attr({
            rel: "stylesheet",
            type: "text/css",
            href: url
        .appendTo('head');
    // append a dummy div to the body for the test
    var div = $('<div></div>')
        .addClass(className)
        .appendTo('body');
    // now poll for the z-index value:
    var cssp_interval = setInterval( function() {
        // if the zIndex is applied, we know the css has loaded
        if ( div.css('zIndex') == zIndex ) {
            div.remove();
            // callback:
            callback();
            clearInterval( cssp_interval );
        }
    }, 100);

}

The code above to do the loading and fire a callback is very naive. It would be much better to have an event that can have listeners added, and to have some tests and some failure management like a maximum timeout.

Default Rule Pattern

This obviously presupposes that the CSS is dynamically generated to some degree, even just by adding the special rule to an otherwise static file. I think that an alternative to the performance-conscious would be a “default” special rule, based on the css filename. This needs some thought, and could well be tied to a build-step in your deployment process (you do have one, right?). The pattern comes in two parts:

• There is a standard zIndex that is always used.
• The filename includes the “special class name” that is used within.

For example:

Given the file: styles.fhddgso9j.css

.someclass { ... }
.otherclass { ... }

/* and the special rule */
.fhddgso9j { z-index: 123456; }

The javascript to go alone with this might look something like:

var cssp_counter = 0;
function loadCss(url, callback) {
    // create a counter for special class names, so they are unique
    className = getSpecialClassName(url);
    zIndex = 123456;
    $('<link>')
        .attr({
            rel: "stylesheet",
            type: "text/css",
            href: url
        .appendTo('head');
    // append a dummy div to the body for the test
    var div = $('<div></div>')
        .addClass(className)
        .appendTo('body');
    // now poll for the z-index value:
    var cssp_interval = setInterval( function() {
        // if the zIndex is applied, we know the css has loaded
        if ( div.css('zIndex') == zIndex ) {
            div.remove();
            // callback:
            callback();
            clearInterval( cssp_interval );
        }
    }, 100);
}
function getSpecialClassName(url) {
  // get just the filename, e.g. "styles.9ufosdfij.css"
  var filename = url.substring( url.lastIndexOf('/')+1, url.length);
  // split on the "." marks
  var parts = filename.split('.');
  // assume it will be the second-to-last part (since the last should be "css")
  var className = parts[ parts.length-2 ];
  return className;
}

As noted above, this naive, untested code.

Wrapping Up

Ideally I’d like any “css loader” to use actual browser events (or properties) where possible, and to fallback on this setup as a last resort.

If I get time I’ll implement this and put the code on github. Please do get in touch if you’d like to pair on this!

Dan is a usability expert and although says that while he prefers simplicity and what I would call “poignancy” in design, most purchases are not based on the premise of being “just right”. The article is a good read, but I think he misses a swathe of well selling products. He details various things like washing machines and other white goods (although lots of the same issues apply to software) but completely misses any discussion of personal electronics, and how long can one talk about design in that area without mentioning the ipod.

When the ipod first came out it was a very poor cousin to a great deal of its competitors in terms of features, let alone the number of controls. It could play fewer music formats, it stopped you from powerful management of your music, it didn’t even have a radio! Yet it sold incredibly well and very quickly got to the same point in the public consciousness that the Sony WalkMan did where a single product’s name became synonymous with a whole class of devices.

The ipod was not cheap. Nor, despite its simplicity, did it *look* cheap, which Dan seems to be suggesting is inevitable. It was excellently marketed, but it was also just a really good product with the entire user interface (what there was of it – not even a radio remember, let alone picture-viewing or other features that other mp3 players had at the time) being very simple to use.

Adding features is the “simple” way to try and boost the cost and sales of product (or a piece of software) but making “simplicity” the key feature that makes it worth more is pretty hard to beat in the long run.

Licensing for this product has stopped working.

After following every suggestion I could find in Adobe’s knowledge base and various online articles, I still couldn’t get any of the applications to start.

As a final act of complete desperation, after many rounds of removal-reboot-reinstall, I finally ran the installer and chose a product that I had not installed before (Contribute). Once that was done I started up the new app, and it asked me for my license key – which I entered and the app started. Then I tried Photoshop and it started up fine!

So – if you didn’t do a complete install int he first place, one of the easiest things could be to add a new app to your install, and get that to reset your licensing for you.

News networks giving a greater voice to viewers because the social web is so popular are like a chef on the Titanic who, seeing the looming iceberg and fleeing customers, figures ice is the future and starts making snow cones.

via XKCD.

Shopping

I think there are a few ways you could use a web of linked data to make online grocery shopping better – comparing prices across stores, create shopping lists from recipes, and get recipes from lists of goods.

Recruitment

With jobs and resumés available as linked data, recruitment could become much more machine-enabled, giving managers better abilities to find people themselves rather than relying on agents who don’t always understand their clients’ business or industry. It could also help people looking for work in a similar way. Types of skill, training and qualification could also be linked in, as could “linkedin” style personal recommendations.

E-Learning

Serious attempts have been made at making learning materials shareable and reusable. As part of the data web, finding and consuming these materials becomes easier but more than that we could build a development plan generator. Competency can be aligned to skills or training received, something that could be useful to government departments, schools, universities and business.

http://otaqui.com/code/bbc-fisheye/bbc-fisheye.user.js

// ==UserScript==
// @name           BBC FishEye
// @namespace      http://otaqui.com/code/bbc-fisheye
// @description    Make BBC's Fisheye look more like it should
// @include        https://fisheye.dev.bbc.co.uk/*
// ==/UserScript==
var elems = document.evaluate(
    '//select[@name="wbauthor"]',
    document,
    null,
    XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
    null
);
var i=0;
var sel;
while ( sel = elems.snapshotItem(i++) ) sel.style.width = '200px';

All my projects live under a single parent directory, and I prefer to share a single users digest file between them all – so ideally I wanted to share a single tracd to run all my projects. This is fairly straightforward on the command line:

tracd --hostname=webhost.com -p 9876 \
--auth="*,/path/projects/people.htdigest,Realm" \
/path/projects/p1 \
/path/projects/p2

That is ….
Line 1 – start tracd for a given hostname and port,
Line 2 – specify auth for all projects (*), the auth file and the “Realm” you specified when creating the file with apache’s htdigest command
Lines 3+ – specify as many projects as you want to run

This is ok with a couple of projects, but gets unwieldy quite quickly. What I needed was a little shell script to open up all projects under a given directory quickly. Here’s what I came up with:

#!/bin/bash

# make / truncate a temp file to store names:
temp=/tmp/tracdpaths
> $temp

# specify base directory:
base=/path/projects/

# output all subdirectories to temp file:
find $base -maxdepth 1 -mindepth 1 -type d \
-exec echo -n "{} " > $temp \;

# now start tracd
tracd --hostname=webhost.com -p 9876 \
--auth="*,/path/projects/people.htdigest,Realm" \
`cat $temp`

Essentially this script uses ‘find’ to get all of the directories exactly 1 level down from your projects directory, and will echo their paths to a temp file (suppressing the newlines). It will then run run tracd, appending the contents of this file to the end of the call.

If you’re using Mechanize through Webrat though, things are a little different. The nice thing though, is that you can do this in a step definition – allowing features to be based on different browser scenarios (this is great if you’re developing across devices).

First off there are two accessors of interest in mechanize, “user_agent” and “user_agent_alias”. The former is fairly self evident and lets you define the user agent at will, the latter gives you shortcut access to a list of common user agents baked into mechanize. You can see that list in the mechanize.rb source. It contains some desktop browsers, the iPhone and the default Mechanize UA strings.

If you’re happy with the default alias list, you can just write a step definition like this:

Given /^I am using the "(.*)" browser$/ do |browser|
  webrat.adapter.mechanize.user_agent_alias = browser
end

And then you can use this in your features:

Given I am using the "iPhone" browser
When I visit the home page
Then I should see "You are using an iPhone!"

If you want to be able to specify your own UA strings, and as I said this is especially likely if you are developing cross-device applications where capabilities are important, then you can just use your own hash instead, and set “user_agent” rather than “user_agent_alias”:

Given /^I am using the "(.*)" browser$/ do |browser|
  UA_ALIASES = {
    "Nokia N95" => "Mozilla/5.0 (SymbianOS/9.2; .....",
    "Palm Pre" => "Mozilla/5.0 (webOS/1.0; ....."
  }
  webrat.adapter.mechanize.user_agent = UA_ALIASES[browser]
end

With a little tweaking you could use both the included list and, if the string from your feature isn’t there, look in a custom list too.

Waha, a user on the chromeplugins.org site posted a much more complete list of URL schemes that Chrome uses. Waha was looking at the url_constants.cc source file, along with some other stuff, to work this list out.

I’ve ignored the virtually universal set of protocols that are in just about every browser: http, https, ftp, file, data, feed and javascript, and also the URLs that cannot be entered into the address bar (not using Chrome 5 on OS X Snow Leopard anyway).

Without further ado, here’s the list:

• about:blank – the empty page
• about:cache – disk and memory cache information
• about:net-internals – network information including Proxy, HostResolver, URLRequest, HTTPCache and SocketStream
• about:crash – the page shown when a tab process crashes
• about:credits – list of libraries and other code used in Chrome, with links
• about:hang – this seems to kill a tab for me (I haven’t linked for that reason – use at your own risk)
• about:memory – memory usage of the various processes
• about:shorthang – see about:hang above
• about:terms – Google Chrome Terms of Service
• about:inducebrowsercrashforrealz – not many lolz here
• chrome://extensions/ – installed extensions
• chrome://history/ – your browsing history
• chrome://newtab – the new tab page
• chrome://thumb/http://www.google.com/ – thumbnail for a page you’ve visited
• chrome://favicon/http://www.google.com/ – favicon for a page you’ve visited
• view-source:http://otaqui.com/blog/539/complete-list-of-special-google-chrome-urls – view the source of a web page