Most read posts this month



Feb 15th 2010 × Creating a wrapper namespace for the FireBug console.log function for IE and other browsers

Most web application/AJAX development takes place within the confines of either FireFox + Firebug or Webkit browsers and their consoles (firebug is now available on chrome?). However, other browsers (such as IE) lack console functionality and this presents a problem.

When in a hurry / under pressure, I have been known to forget to take out a console reference out of code that sneaks it’s way into the production environment. If not immediately noticeable, tucked away behind a loop / if statement, you’d never know about it… That is, until the error reports start flooding in.

Not wanting to find myself in such position again, I decided to write a little wrapper that can cater for nearly all of firebug’s console methods. The most common ones, such as console.log, console.info, console.clear and console.count are pre-defined but you can use the model and add others into the singleton. Check this fine firebug cheatsheet for more ideas on other methods you may want to port.

var $C = {
    // console wrapper by D. Christoff @ http://fragged.org/
    _version: 2.1.3,
    debug: true, // global debug on|off
    quietDismiss: false, // may want to just drop, or alert instead,
    method: "log",
    _hasConsole: function(_method) {
        var _method = _method || "log";
        return typeof(console) == 'object' && typeof(console[_method]) != "undefined";
    },
    _consoleMethod: function() {
        if (!this.debug) return false;

        if (this._hasConsole(this.method)) {
            try {
                console[this.method].apply(this, arguments);
            } catch(e) {
                // safari console may not accept scope like so
                for (var i = 0, l = arguments.length; i < l; i++)
                    console[this.method](arguments[i]);
            }
        } else if(!this.quietDismiss && arguments.length) {
            var result = "";
            for (var i = 0, l = arguments.length; i < l; i++)
                result += arguments[i] + " ("+typeof arguments[i]+") ";

            alert(result);

        }
    },
    log: function() {
        this.method = "log";
        this._consoleMethod.apply(this, arguments);
    },
    info: function() {
        this.method = "info";
        this._consoleMethod.apply(this, arguments);
    },
    clear: function() {
        this.method = "clear";
        this._consoleMethod.apply(this);
    },
    count: function() {
        this.method = "count";
        this._consoleMethod.apply(this, arguments);
    },
    debug: function() {
        this.method = "debug";
        this._consoleMethod.apply(this);
    }
}; // end console wrapper.

// example data and object
$C.clear();
var foo = "foo", bar = document.getElementById("divImage");
$C.log(foo, bar);
$C.count("loop");
$C.info("we are inside a loop!");
$C.count("loop");

The interface is simple, just use the "$C" namespace (name it what you like) instead of "console" will have the preserved functionality / results within FireFox, whereas IE users can either see an alert pop-up dialogue or nothing at all (if $C.quietDismiss = true).

// To disable the alerts in IE, do
$C.quietDimiss = true;
// To disable debug completely:
$C.debug = false;

I hope somebody finds this useful...

update history

*update* thanks to divide by zero for the improvement - in this post.

*update again* this is a fix from the previous update, seems that safari's console cannot accept scoping through apply so I added a try {} catch {} block where it reverts to the old loop

*update again (15/02/10)* modded to support any possible console method with ease


Oct 19th 2008 × YSlow and mod_rewrite: helping in site speed profiling and optimisation

I have been looking around a fair bit recently in a bid to improve performance on a number of sites… And naturally came upon YSlow for FireBug. This is a plugin that does website component profiling based on analysing the performance of all elements loaded into DOM. It examines headers, compression, size, response time, content types and can produce an accurate depiction of your worst performing scripts, stylesheets or images.

It also has a great advisory feature that uses YUI’s best practices in website optimisation (such as, gzipping components, using CDNs, marginalising background images, minimizing requests, to name but a few). It measures and ranks your site and makes you want to tweak it and improve…

I had a long play with various ways of improving but eventually came get to the best results (as speed and size gains) via some mod_rewrite .htaccess trickey:

## enable gzip page compression!
php_flag zlib.output_compression On
php_value zlib.output_compression_level 5

# compress all text & html:
AddOutputFilterByType DEFLATE text/html text/plain text/xml

<Files *.js>
SetOutputFilter DEFLATE
</Files>

<Files *.css>
SetOutputFilter DEFLATE
</Files>

# set clientside cache per element type
# 1 YEAR
<FilesMatch "\.(ico|pdf|flv)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
# 1 WEEK
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
# 2 DAYS
<FilesMatch "\.(xml|txt|css|js)$">
Header set Cache-Control "max-age=172800, proxy-revalidate"
</FilesMatch>

This is a combination between cache controls and compression that you can tweak and deploy as needed. If you have relatively static .html or .php files, you can also try adding |html|php or whatever other extension you may see fit. Have fun.

no