Here’s the next instalment in our Intermoos series: we sit and talk with Ryan Florence, one of the most extraordinary and well respected coders, the man behind moo4q, SlideShow, mooDocs and the MooTools magazine. I thought he was Italian (or at least French) for a long time. I was wrong…

Is that your ostridge there? Thanks for your time!

Another day, another “intermoo”. I really wanted to get Justin Bieber to comment on MooTools today but seeing as he refused to commit to answering my questions, I got the next best thing: the chance to ketchup[1] with Christoph Pojer from the MooTools core team.

When you meet with Chris, there’s something endearing about him, and it’s not just the way he says ‘mutuulz’ (you can watch this talk on mootools Chris gave earlier this year and see what I mean). We try to find out what drives him on today.

Right now I am doing lots of probability theory, object oriented analysis, data structures and algorithms, software architecture and information security related stuff. That, of course, doesn’t have anything to do with MooTools but during the semester I don’t have time for anything else really. But fear not, in the web assignments I am of course making use of MooTools (and PowerTools! ). Recently I did some experiments with DeviceOrientation and DeviceMotion on iOS 4.2 (see http://twitter.com/#!/cpojer/status/7485711225716736).

The goal of PowerTools! is not to make MooTools mobile compliant – MooTools works great on mobile devices already. One part of PowerTools! is the mootools-mobile project, which brings custom gestures and more for your mobile web app. PowerTools! is about providing low-level MooTools extensions or HTML5 related plugins that help you speed up the development process or to make your code more maintainable. As far as mobile is concerned, yes – mobile browsers have a lot of catching up to do, but we will get there. The mobile web is definitely important. PowerTools! is currently standalone and there are no plans to officially include it with MooTools. I don’t want to bloat our beloved library

MooTools 2.0 of course! The whole thing will blow your mind, once its done of course

I don’t usually have one. If you want to learn MooTools then go to David Walsh’s (FTW) website http://davidwalsh.name/ – also, the site is awesome for using the hover-effect on links which I created Some people claim David stole them, I refuse to believe that.

Thank you for your time!

Hello and welcome to our new series: “Intermoos“. What it is, is a series of interviews with members of the MooTools team and community that have the time to spare. We ask them a few annoying questions, we get a few interesting answers, you get the idea.

And what better way than to start it all off with a one-to-one with none other than David Walsh, the extraordinary blogger and MooTools contributor (also famous for being Arsenal’s only American supporter). Without further adieu, here is what he had to tell us…

Thank you for your time!

I tend to get annoyed about URL baiting that takes place over social networks – you really don’t know what’s behind a shortened URL until you click it. Or… until you run a URL resolver that can help. In building my Twitter Trend Aggregator, I came to explore this and found an invaluable service through the API of longurl.org that can uncrunch almost any shortened URL to its original.

Here is the extended Class (http://www.jsfiddle.net/dimitar/3Ntnr/)

Request.longURL = new Class({
    // decode a long url
    Extends: Request.JSONP,
    options: {
        log: !true,
        url: "http://api.longurl.org/v2/expand",
        data: {
            url: "",
            format: "json"
        }
    },
    initialize: function(loc, options) {
        this.parent(options);
        this.options.data.url = loc;
    },
    success: function(data, script) {
        this.parent(data, script);
    }
});
// example usage
var urls = [
    "http://bit.ly/b5Ukzp",
    "http://tinyurl.com/33wz7sv",
    "http://is.gd/e7S7R",
    "http://post.ly/r49y",
    "http://www.google.com/" // won't do anything to it.
];

var output = document.id("output");
urls.each(function(url) {
    new Request.longURL(url, {
        onSuccess: function(data) {
            new Element("a", {
                href: data["long-url"],
                text: url + " -> " + data["long-url"]
            }).inject(output);
        }
    }).send();
});

For a better example of this, visit the Twitter Trends Thingie I wrote and mouseover any encoded URL (or press the ‘Unshorten Tiny URLs’ link in the top right bar).

If you want to just deal with the good old bit.ly, then you can go to them direct like so:

// get all links on page that are bit.ly and decode them
document.getElements("a[href^=http://bit.ly]").each(function(el) {
    var url = el.get("href");
    new Request.JSONP({
        url: 'http://api.bit.ly/v3/expand',
        data: {
            shortUrl: url,
            apiKey: 'R_e744c730bdde44a7eacc88cb892074e7', // change
            login: 'webtogs2' //change this
        },
        onComplete: function(response) {
            el.set({
                href: response.data.expand[0].long_url,
                text: response.data.expand[0].long_url
            });
        }
    }).send();
});

Happy social networking

Just a quick post, really. I wrote a little pseudo twitter client that archives hash-trends and allows for post rating and filtering of spammers within different followed trends. click here to see the moootools archive.

In this early beta version, I am also archiving various e-commerce trends for the purposes of statistics on trends and twitter applications but soon it will just follow webdev ones like #javascript #seo #php #css etc. Feedback welcome.

Under the hood: Powered by PHP and mootools 1.3beta (for now), there’s a known problem in IE7 event delegation for mouseout:relay(), similar to the mouseenter workaround that needs refactoring but I have left that for another time. More to come soon…

This is an interesting one. Basically, there’s a school of thought in SEO that says, you should not apply a display: none CSS property to elements without a valid reason. By valid, it is understood that the hidden content it is somehow interacting with the user based upon events. For example, flyout / foldout menu systems, mouse tips and so forth are acceptable. Hidden text for the purposes of increasing keyword density and SEO relevance is NOT ok.

There are some sites that claim to check what is detectable and what is not but the bottom line is, only one thing will give you a 100% guarantee and control over what your page is hiding and that is reading it from the DOM directly.

I wrote a little snippet through mootools (as all my sites use mootools) that uses a pseudo selector to search for particular style settings.

*UPDATE* if you found this through some SEO tag/search, you should know that this will only work on pages that utilise the mootools javascript framework (link is on the right handside) and in a browser with a console (chrome, safari or firefox with the firebug plugin). With my “usual” type of readers being web developers, I tend to take this for granted.

// for mootools 1.2
Selectors.Pseudo.style = function(key) {
    var styles = key.split("=");
    return styles.length == 2 && this.getStyle(styles[0]) == styles[1];
};

// output all elements with display: none to console
$(document.body).getElements(":style(display=none)");

Just open your page, open up firebug and the larger command line console and paste (or make a bookmarklet).

Neat or not? You can also look for visibility: hidden or other tricks you can think of (positioning and so forth may need some changes to the code).

note: for mootools 1.3 and slick (still in beta), you need to change this to:

Slick.definePseudo('style', function(key) {
    var styles = key.split("=");
    return styles.length == 2 && this.getStyle(styles[0]) == styles[1];
});

I hope it helps you – it’s a useful trick anyway, you can use this to select all elements with color: red, for example.

This is a bit of a sore topic as it is often being asked by people on forums and sites like Stack Overflow. Essentially, javascript does not offer a meaningful way to protect methods from being called directly. Come to think of it, neither does mootools–at least not officially.

However, there is a private API (meaning, not supported) that allows you to do it – its via .protect()

Here is a simple ninja class that shows how we can prevent our ninja from being killed directly without receiving damage first:

var ninja = new Class({
    Implements: [Options,Events],
    options: {
        startHealth: 10,
        name: "Bruce",
        surname: "Lee"
    },
    initialize: function(options) {
        this.setOptions(options);
        this.health = this.options.startHealth;
        this.alive = true;
    },
    heal: function(points) {
        if (!this.alive)
            return;

        this.health += points || 1;
    },
    hurt: function(points) {
        if (!this.alive)
            return;

        this.health -= points || 1;
        if (this.health <= 0)
            this.die();
    },
    die: function() {
        this.alive = false;
        this.fireEvent("death", this); // let everyone know
    }.protect() // protected method
});

var bruce = new ninja({
    onDeath: function() {
        // default handler when death occurs
        alert(this.options.name + " " + this.options.surname + " has passed away.");
    }
});

bruce.hurt(5);
try {
    // not allowed to kill ninja directly, need to hurt it instead
    bruce.die();
}
catch(e) {
    alert("the ninja lives!");
    alert(e);
}

// now hurt it more so it dies anyway
bruce.hurt(5);

The .protect() will cause any attempts to call .die on the instance directly to throw an exception and fail. Once again - although this works with mootools 1.2.4 and on mootools 1.3 nightly build, it's not documented and is unsupported - don't rely on this too much (may disappear in mootools 2.0, perhaps). Still, a nice feature to have at hand, certainly

Check the jsfiddle to play with it some more: http://www.jsfiddle.net/dimitar/jQW5q/

I was writing my own re-tweet class and found that I need to crunch URLs on the fly to make them fit within the 140 character limit on Twitter. Come bit.ly and their API, easily accessible via REST and with a JSONP callback interface, just the job for extending Request.JSONP:

Request.bitly = new Class({
    // shorten urls via bit.ly
    Extends: Request.JSONP,
    options: {
        log: !true,
        bitly: {
            api: "R_e744c730bdde44a7eacc88cb892074e7", // GET YOUR OWN API KEY
            login: "webtogs2" // GET YOUR OWN LOGIN
        },
        url: "http://api.bit.ly/v3/shorten?login={login}&apiKey={api}&longUrl={longUrl}&format=json"
    },
    initialize: function(loc, options) {
        this.parent(options);
        this.options.bitly.longUrl = loc;
        this.options.url = this.options.url.substitute(this.options.bitly);
    },
    success: function(data, script) {
        this.parent(data, script);
    }
});

This is the class, now for the example uses, this will convert all links from the page into bit.ly URLs (if they are shorter than the original)

document.getElements("a").each(function(el) {
    new Request.bitly(el.get("href"), {
        onSuccess: function(data) {
            if (data && data.data && data.status_code == 200) {
                var orig = data.data.long_url, hash = data.data.url, difference = orig.length - hash.length;

                if (difference > 0) {
                    el.set({
                        href: hash,
                        title: hash + " - saved " + difference + " chars"
                    }).addClass("shortened");
                }
                else {
                    var error = "ERROR:\n your bit.ly hash '" + hash + "' is longer than the original '" + orig + "'";
                    el.set("html", el.get("html") + error);
                }
            }
        }
    }).send();

});

See it all in action on the little jsfilddle here: http://www.jsfiddle.net/dimitar/xVtZy/

I never like having iframes in production sites source codes so when management decided to add the ‘facebook like’ widget thing, I decided to move it outside of the source and into a javascript abstraction. Easiest and most convenient way to do so is via extending the Element prototype in mootools (via Element.implement()):

Element.implement({
    facebookLike: function(url, options) {
        var options = $merge({
            show_faces: "false",
            layout: "standard",
            width: 450,
            action: "like",
            font: "lucida grande",
            colorscheme: "light",
            height: 30,
            href: url
        }, options);

        var src= "http://www.facebook.com/plugins/like.php?href={href}&layout={layout}&show_faces={show_faces}&width={width}&action={action}&font={font}&colorscheme={colorscheme}&height={height}".substitute(options);
        return this.adopt(new Element("iframe", {
            styles: {
                border: "none",
                overflow: "hidden",
                width: options.width,
                height: options.height
            },
            id: "FBFrame",
            frameborder: 0,
            allowTransparency: "true",
            scrolling: "no",
            src: src
        }));
    }
});

// exmaple use:
document.id("like").facebookLike("http://fragged.org/", {
    width: 400,
    height: 30
});

Why would you want to do that instead of the default interface? Because it will speed up page load and abstract this into domready / onload events. It also allows you to produce multiples very easily via a a selector, eg,

// if in your markup you have a number of
anchor text

// then target them, get the link's href and apply the like button instead
document.getElements("div.like").each(function(el) {
    var urlToLike = el.getFirst().get("href");
    el.empty().faceboookLike(urlToLike);
});

All of the facebook options like button plugin are “supported” – you can find the list here

Finally, here’s what it looks like:

Play with it some more on the jsfiddle: click here

This came as a complete shock to me: due to the Google Mayday update, I have been monitoring how the bot accesses our sites in a futile search for clues as to the page rankings changes. Very surprised to discover googlebot fetching URLs that are _strictly_ available through Ajax only.

Here is a sample request from earlier today that fetched a small worker thread that produces additional product images:

66.249.65.25 - - [03/Jun/2010:11:25:43 +0100] "GET /angles.php?id=102257&version=Brown HTTP/1.1" 200 801 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

We have all spoken of Google’s increased capability of following and deciphering javascript logic but it goes beyond the scope of reasonable effort, in my opinion. Is the scraping done based upon URLs detected in the javascript blocks or does it actually evaluate, run and monitor the calls? If the scraping works based upon regex that catches URLs, would obfuscation / base64 encoding help? Does googlebot support XHR via POST or only via GET? Too many questions without an answer at this point, I will update this post as more info becomes available to me.

Such fetches can often be undesirable–certain AJAX calls we do are tied in with sessions and can cause errors / notifications when being requested w/o due cause, session or event. I am currently trying to find if there is a plausible way to apply a “nofollow” to such calls at all that does not involve a lot of editing and blocking of googlebot from any scripts that it has no place reading. If it comes to it, I will revert all ajax handling to a /xhr/ folder and disallow it in robots.txt, wonder what the best practice is…

As for the Mayday Update, the less said about it, the better. I have never seen Google SERPs get things so very wrong – for instance, ranking disabled products with 0 links anywhere on the net that redirect their traffic instead of what used to be the landing pages. Longtail relevance? With 2k organic in-links to the landing page, PR4 and quality content built over 2 years, this is not bizarre enough…