( ? , qUeStIoNMaRk )

After being installed for the whopping amount of 42 times (yes, 42) SeekTube gets outdated by YouTube providing the same functionality. You can now postfix a YouTube link with #t=XmYYs (which differs from SeekTube links for an additional “t=”) and get the player start at that precise moment; actually the precision depends on the nearest available key-frame, which the player starts playing from.

As a plus, YouTube also implemented a functionality I was wondering to add to SeekTube: it now automatically detects when someone mentions a specific time and adds a link to that point in the video. If you write 01:18 in a comment, YouTube would enclose it in an anchor tag wth the onclick attribute set to the seekTo function, i.e. <a href=”#” onclick=”seekTo(01*60+18);return false;”>01:18</a>. The detection is performed server-side (although the conversion is completed on the client - is this by or design by accident?); this leaves a little room for (seektube-strikes-back) porting the detection fully on the client side (in a greasemonkey/ubiquity script) and having it available on every page linking or embedding a YouTube video.

Good Bye SeekTube,
So LongShort and Thanks
For All the Few FishLinks

It seems that a pragmatic approach to ending procrastination is focusing on “small things”, and getting them done. As part of this today I focused on a long-standing “issue” of mine… getting YouTube videos link-addressable. You know, it happens you want to link to a precise (topical) moment in a video - e.g “when the kitten can’t finally keep up with the ever speeding treadmill” - and what you are left with is a “at X minutes and Y seconds in the “.

That said, having previously spotted the YouTube JavaScript Player API providing a seekTo function, I managed to leverage it (through Greasemonkey) to come to a solution: SeekTube.

SeekTube is a Greasemonkey user script to enable the same “link within a video” feature provided by Google Video also on YouTube videos.
[…]
Well, SeekTube enables the same functionality: i.e. you can specify a permalink to a precise time in the video by appending an “#” followed by the time formatted as HhMmSs to the video url, where H, M, S are sequence of digits indicating hours, minutes and seconds respectively (none of them is mandatory); e.g. you can take a look at the BeOS nice long degradation curve under heavy load(multiple multimedia streams and 3D graphics, half computing power down), happening at 7 minutes and 50 seconds (http://www.youtube.com/watch?v=6VDYdaXApNk#7m50s) from the beginning of the video.

Note: it’s rather alpha stage, as I haven’t yet figured out a way to cope more gracefully with the security/sandboxing model of Greasemonkey/Firefox (see SeekTube page for details on the implementation).

As a note for the JavaScript-inclined, an interesting failing approach to get a working reference to the “player” object inside the Greasemonkey execution environment (without overloading the window.onYouTubePlayerReady function) is to wait for the player.seekTo function to be ready, i.e. defined, i.e no more undefined, which goes down to setting a recurring timeout until the player.seekTo is defined. This approach failed beacuse of Greasemonkey sandboxing; player.seekTo will be undefined forever. Here comes the code… (the GM_log() is GreaseMoney logger to JavaScript Console)

function seekOnPlayerReady(){
  player = document.getElementById(‘movie_player’);
  if(player.seekTo) {
    /* seek time retrieval from url */
    player.seekTo(seekTime,true);
  } else {
    GM_log(‘player not yet ready’);
    setTimeout(’seekOnPlayerReady()’, 500);
  }
}
setTimeout(‘’, 500);

PS: DiveIntoGreasemonkey, being not fully up to date, is yet a very nice introduction, js2mode (by Steve Yegge) for Emacs is great.

DISCLAIMER: quite long, programming related post.

A few days ago Marco Ramilli reviewed a useful password strength checker written in JavaScript. The JavaScript "score" function is (here without any DOM manipulation-"side effect"):

function passwordStrength(password)
{
   
    var desc = new Array();
        desc[0] = "Very Weak";
        desc[1] = "Weak";
        desc[2] = "Better";
        desc[3] = "Medium";
        desc[4] = "Strong";
        desc[5] = "Strongest";

        var score   = 0;

        //if password bigger than 6 give 1 point
        if (password.length > 6) score++;

        //if password has both lower and uppercase characters give 1 point     
        if ( ( password.match(/[a-z]/) ) && ( password.match(/[A-Z]/) ) ) score++;

        //if password has at least one number give 1 point
        if (password.match(/\d+/)) score++;

        //if password has at least one special caracther give 1 point
        if ( password.match(/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/) ) score++;

        //if password bigger than 12 give another 1 point
        if (password.length > 12) score++;

    return {"score": score, "desc": desc[score] } ;

}

This function can be written in a fairly more compact manner taking avdantage of some nice JavaScript programming fatures. (Remembering that JavaScript is the World’s Most Misunderstood Programming Language)

First you can declare the array with a single assignament:

var desc = ["Very Weak", "Weak", "Better", "Medium", "Strong", "Strongest"]

Second you can avoid repeating the "if (condition) score++" (if you are lazy like me you should hate writing the same code over and over), have the tests stored in an array and executed via "eval" in a "for (element in collection)" statement, this way you keep the tests separated from the score evaluation; this is no big deal in a so simple and short program, but it’s a good practice (and attitude) to have rules and rules engine logic separeted.

var tests = [
    "(password.length > 6)",
    "( ( password.match(/[a-z]/) ) && ( password.match(/[A-Z]/) ) )",
    "(password.match(/\d+/))",
    "password.match(/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/) )",
    "(password.length > 12)",
]

for (test in tests){
    if eval(test) {
        score++;
        }
}

Now the password strength checker function can be rewritten as:

function passwordStrength(password)
{
   
    var desc = ["Very Weak", "Weak", "Better", "Medium", "Strong", "Strongest"];
   
    var tests = [   
        "(password.length > 6)",
        "( ( password.match(/[a-z]/) ) && ( password.match(/[A-Z]/) ) )",
        "(password.match(/\d+/))",
        "password.match(/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/) )",
        "(password.length > 12)",
    ];
   
    var score = 0;
    //every passing test gets the score incremented of 1 point
    for (test in tests){
        if eval(test) {
            score++;
            }
        };
   
    return {"score": score,"desc": desc[score]};
   
}

This is a more compact formulation than the original one, which means less bytes down the tube which turns to less bandwidth consumption, and it is also more manageable (the initial disclaimer is always valid: the example is quite simple so you get no big savings, it’s more about the attitude).

A note on eval: (ab)use of eval is somewhat considered harmful and watched with despise in some circles, so you can easily substitute the expression eval(test), relying on a more explicit use of the "metaprogramming" facilities of the language, with:

(new Function("return " + test))()

Here you build an anonoymous Function whose body is made out of the return statement (otherwise, as no return statement is specified in the test body, the return type of the function would be undefined, kind of void for the Java-inclined) and the test body; the function is then called () and the test gets evaluated.

By having "rules engine" and rules separated you can further improve the code robustness: an implicit assumption is made on the number of tests and descriptions  you provide, i.e. you must provide N tests and N+1 descriptions. How can this become more flexible? You can broad the initial assumption by stating you can have an arbitrary number of tests (each one with a separate score) and an indipendent number of level descriptions. For example’s sake you have 4 descriptions (you throw away the "Better" and the "Strongest" ones), 6 tests and the last one gets you 2 points if passed.

First you have a simple design decision to make: how you relate the strength description to the score?

Opting for a simple design you can fully specify the mappings (defining the minimum score for each description), e.g. using a dictionary / hashmap like {0: "Very Weak" , 2: "Weak", 3: "Medium", 5: "Strong"} for the descriptions. Hence you have:

var desc = {0: "Very Weak" , 2: "Weak", 3: "Medium", 5: "Strong"}

The score for each test can be specified taking advantage of an hashmap in wich the body of the test is the key and the score the value.

var tests = {
    "(password.length > 6)": 1,
    "( ( password.match(/[a-z]/) ) && ( password.match(/[A-Z]/) ) )": 1,
    "(password.match(/\d+/))": 1,
    "password.match(/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/) )": 1,
    "(password.length > 12)": 2,
    }
   
To take into account the custom score for each test you also have to make a fairly trivial change to the "rules engine", instead of score++ you have:

score += tests[test];

Now that the score has been calculated you have to retrieve the description; descriptions are "indexed" in the hashmap by their minimum score level, so you have to retrieve the entry with the maximum possible key value less or equal than your actual score. This problem can  be solved by a helper function that starts with retrieving the entry for the actual score and in case of failure (i.e. desc[score] evaluates to undefined) it calls recursively itself with the score decremented by one unit, and so on until it eventually reaches a valid key. A note on  the ? operator and associative arrays in JavaScript, the test fails for the value undefined, to which the expression desc[score] evaluates if there is no entry for the key score.

function desc_f(score)
{
    return desc[score] ? desc[score] : desc_f(score-1);
}

Now you can substitute desc[score] with desc_f(score) in the return statement of passwordStrength and your’re done with satisfying the evolved requirements.

function passwordStrength(password)
{
    var desc = {0: "Very Weak" , 2: "Weak", 3: "Medium", 5: "Strong"};
       
    var tests = {
        "(password.length > 6)": 1,
        "( ( password.match(/[a-z]/) ) && ( password.match(/[A-Z]/) ) )": 1,
        "(password.match(/\d+/))": 1,
        "password.match(/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/) )": 1,
        "(password.length > 12)": 2,
        };
   
    var score = 0;
   
    for (test in tests){
        if eval(test) {
            score += tests[test];
            }
        };
       
    function desc_f(score)
    {
        return desc[score] ? desc[score] : desc_f(score-1);
    };
   
    return {"score": score,"desc": desc_f(score)};
   
}

If you  didn’t get overly bored you should have appreciated the power and simplicity offered by a "responsible use" of JavaScript. If you really didn’t get overly bored and you feel like expereminting something on your own, you can implement your own strategy for description-score mapping; there is plenty of room to introduce arbitrarly complex strategies.

These ramblings have been inspired by some (off|on)line chat with Giulio Piancastelli (who suggested me the Function() alternative to the "evil eval"), his Kata Four in JavaScript post and by these nice presentations on JavaScript Metaprogramming: @media Ajax by Dan Webb and  @Columbus Ruby Brigade by Adam McCrea.