How to generate a 1 pixel GIF with dataURL in JavaScript

I recently wanted to use single pixel dataURL images in a project, but on doing some research (http://sveinbjorn.org/dataurls_css) I discovered I would have to create the images first and then convert them to base64, using tools like DataURL.net or http://boazsender.github.com/datauri/

I thought this was somewhat inefficient.

After a little more research, I found a good post on the subject of generating dataURL images for LESS, but it was incomplete, as although there is a jsFiddle, it never actually generates the data and it turns out there are a few bugs.

Time for a quick bit of work.... drum roll please...

Presenting: Single Pixel GIF dataURL Generator (edit)

Basically, I fixed the bugs, and added some UI to make it more useful.
Credit to Michel Jansen, as without his work, this would have been a lot more painful.

How to debug in Visual Web Developer 2010 Express

This is pretty simple really.

1. download and install Visual Web Developer 2010 Express.
2. start a new Web Application Project
2a. make sure configuration at the top is set to DEBUG
3. right click on your project in Solutions Explorer (RHS)
3a. Select Properties from the Drop Down
4. Select Web tab
5. Select Start URL in the radio icons, and enter a URL
6. change default browser to IE. (change browse with in VWD)
7. Click Start Debugging (Green play icon)

That should start IE with Visual Studio watching it for bugs.
or if you use a DEBUGGER call in your code.

Visual Web Developer 2010 Express - Browse with...

Just a quick note to myself really.

The "Browse with..." functionality has moved from solutions explorer into the File Menu.

So to change the default browser in a project, just goto File->Browse With... and change the default browser to the one you want.

Speed Testing Chrome for List Processing

What are we testing?

As Rich Internet Application development progresses, more and more developers are moving towards the functional programming capabilities of JavaScript.

First Order Functions, Closures, Macros and Lists are becoming a mainstream method of development.

When you can tell the computer how to do it, rather that listing what it needs to do, it becomes much easier to write a program and needs a lot less code.

Think recipe instead of precise instructions.

So how does Chrome compare to the other browsers when doing this?

What did we test?

I used JSTR to create a re-usable test of basic Functional programming.

The test creates a list(array) from a DOM collection, runs a filter on the list to identify the required elements, then performs an action on those elements remaining.

Follow this LINK to run the test for yourself.
Paste the link into another browser to test it on different systems.

The test is pretty basic, but it provide a nice demonstration of the capabilites of Chrome.

So how did they do?

Testing 1000 loops on a windows XP machine with 2Gb ram:
Testing used 10 repetitions for averaging.

Conclusions

It looks like the more modern browsers (FF3, Chrome, Safari) are now concentrating a great deal on Javascript performance. A very good piece of news for anyone developing Rich Internet Applications.

I must admit I was surprised by the performance of Safari on WindowsXP but it is nice to get surprises like this.

I had expected Chrome to out perform everything else and was a little disappointed to see otherwise. However, it is definetely a top notch Javascript system and I look forward to watching it develop.

This test does raise the issue that older versions of any browser will have significant differences in run-time speed for your application.

It looks like we will soon be back to the days of specifying a minumim compatible browser version, and the list will be quite short.

Request for Comments

If you have a different operating system or browser... can you please let me know how it performs in this test?

1. Use the link above to launch JSTR, pre-loaded with the test..
2. Clear the Console
3. Press RUN

If you can leave a comment with the output, I will add it to the data collected.

Performance Testing in JavaScript

Fast pages and quick load times are key factors to keeping visitors on your site.
If you make them wait, they will leave.

So the speed of your JavaScript applications is crucial.

Fortunately, it turns out that JavaScript applications are ripe for performance optimization.

This requires a strong testing framework... enter JSTR.

String Concatenation Performance

A simple example of the type of benefit available from performance testing can come from testing String concatenation.

Javascript allows the use of "+" to concatenate Strings, but it turns out to be rather inefficient if you are building a very big string, eg: dynamically building HTML from AJAX.

Instead, the use of a Array (wrapped to provide a StringBuffer object) provides a huge boost in performance.

[cc lang="javascript" tab_size="2" lines="40"]
function StringBuffer() {
this.buffer = [];
}

StringBuffer.prototype.append = function append(string) {
this.buffer.push(string);
return this;
};

StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
};

var buf = new StringBuffer();
buf.append("this is being added");
alert(buf.toString());
[/cc]

To test this against a normal concatenation:
Copy the String below, and then paste it into the IMPORT function in JSTR.

[cc lang="javascript" tab_size="2" lines="40"] jstr_StringBuffer=KHtuYW1lOiJTdHJpbmdCdWZmZXIiLCBkZXNjOiJUaGlzIHRlc3QgY29tcGFyZXMgdGhlIHNwZWVkIG9mIGJ1aWxkaW5nIGEgbGFyZ2Ugc3RyaW5nIGJ5IGNvbmNhdGVuYXRpbmcgc3RyaW5ncyBvciB1c2luZyBhIFN0cmluZ0J1ZmZlcihhIHdyYXBwZWQgYXJyYXkpLlxuQ29tcGFyZXMgYm90aCBsb25nIGFuZCBzaG9ydCBzdHJpbmcgYnVpbGRpbmcuXG4iLCBsb29wczoiMjAwMCIsIGl0ZXJhdGU6IjUiLCB0ZXN0czpbe25hbWU6InNob3J0U1RSIGNvbmNhdCIsIHNldHVwOiJhU3RyaW5nID0gXCJhZGRpbmcgXCI7XG5iU3RyaW5nID0gXCJTdGFydCBcIjsiLCBjb2RlOiJiU3RyaW5nICs9IGFTdHJpbmc7IiwgaW5jOnRydWV9LCB7bmFtZToibG9uZ1N0ciBjb25jYXQiLCBzZXR1cDoiY1N0cmluZyA9IFwiIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkIGFkZGVkICBMT05HXCI7XG5kU3RyaW5nID0gXCJTdGFydCBcIjsiLCBjb2RlOiJkU3RyaW5nICs9IGNTdHJpbmc7IiwgaW5jOnRydWV9LCB7bmFtZToic2hvcnRTdHIgU3RyaW5nQnVmZmVyIiwgc2V0dXA6ImVTdHJpbmcgPSBcIiBNb3JlXCI7XG5mU3RyaW5nID0gXCJTdGFydCBcIjtcblxuU3RyaW5nQnVmZmVyID0gZnVuY3Rpb24gKCkgeyBcbiAgIHRoaXMuYnVmZmVyID0gW107IFxuIH0gXG5cbiBTdHJpbmdCdWZmZXIucHJvdG90eXBlLmFwcGVuZCA9IGZ1bmN0aW9uIGFwcGVuZChzdHJpbmcpIHsgXG4gICB0aGlzLmJ1ZmZlci5wdXNoKHN0cmluZyk7IFxuICAgcmV0dXJuIHRoaXM7IFxuIH07IFxuXG4gU3RyaW5nQnVmZmVyLnByb3RvdHlwZS50b1N0cmluZyA9IGZ1bmN0aW9uIHRvU3RyaW5nKCkgeyBcbiAgIHJldHVybiB0aGlzLmJ1ZmZlci5qb2luKFwiXCIpOyBcbiB9OyBcblxuYnVmID0gbmV3IFN0cmluZ0J1ZmZlcigpO1xuYnVmLmFwcGVuZChmU3RyaW5nKTsiLCBjb2RlOiIgYnVmLmFwcGVuZChlU3RyaW5nKTtcblxuIiwgaW5jOnRydWV9LCB7bmFtZToibG9uZ1N0ciBTdHJpbmdCdWZmZXIiLCBzZXR1cDoiXG5oU3RyaW5nID0gXCJTdGFydCBcIjtcblxuYnVmMiA9IG5ldyBTdHJpbmdCdWZmZXIoKTtcbmJ1ZjIuYXBwZW5kKGhTdHJpbmcpOyIsIGNvZGU6ImJ1Zi5hcHBlbmQoY1N0cmluZyk7XG5cbiIsIGluYzp0cnVlfV0sIHZlcnNpb246MX0p [/cc]

Just to give you an idea...
StringBuffer is just faster for short strings
and about 50 times faster for long strings...!

My thanks to Pavel Simakov for this.

A 'foolish' new tool for Javascript

I have been dying to shout about this...

instead I have been waiting very patiently...

BUT now it is time to SHOUT!

JSTR(Jester) is out of the box!

JSTR is the first 'Browser based' (ie:Cross-browser ):

• Testing


• Benchmarking


• Optimization

tool for javascript.

With both import & export of Test-Sets, as well as auto-generated URLs, JSTR lets you easily share your code with everyone else, so they can try it for themselves.

Now, when you write about your new discovery, put a link to the test-set in your blog and let everyone else actually try it.

Find out about the new funny man for JavaScript.

Watch the video to learn more

Timing is everything

Here for your delight.

A simple way to track timing in Javascript.

[cc lang="php" tab_size="2" lines="40"]
// TIMESTAMP Function
function timestamp(){return (new Date()).valueOf();}

// TIMER Function, wraps timing arround function call
function timer(f){
var t1 = timestamp();
for(var i = 0; i < 1000; i++){
f();
}
var t2 = timestamp();
return t2-t1;
}

// The function to test
var testFunc = function(){
var v = (window["DoYouBelieveInSpeedReading"])?true,false;
}
// Now call the timer
alert("time taken="+(timer(testFunc)/1000) + " seconds" );
[/cc]

The core is converting a date object into milliseconds: date.getValueOf(). This will give you a Long of the number of millseconds since 1970.

so var t1 = timestamp(); will store the start time.

Then do the thing you want to test... I would suggest a very large number of times... I needed to make it 100,000 for the Regex below.

and var t2 = timestamp(); becomes the end time.

Now totalTimeTaken = t2 -t1; in millseconds.

Finally time = totalTimeTaken/1000; to get the number of seconds that the function took.

I wrapped it all up in a function timer...

which can be called by
alert("time taken="+timer(myFunc)/1000);

I recently used this to test String matching functions, to find that indexOf is blisteringly fast, followed closely by pattern.test, and then way behind that String.match .

For 100,000 repetitions:
String.match: 1300ms
pattern.test: 360ms
String.indexOf: 180ms

So the moral of todays story is...

• 
  
  use indexOf if you can


• 
  
  pattern.test if you must have REGEX or more than one match


• 
  
  and AVOID String.match if you can

Just remember that premature optimization is a bad thing...

Happy Testing...!

Setting an Exclusion Cookie for Google Analytics with a Bookmarklet

I have been doing a lot of work on my reading software website recently. This has played havoc with my Google Analytics reports.

So I set about looking for a way to block my own hits from the results. Having done a good search for up to date techniques, it seems that a cookie and a filter in analytics are still the current standard.

I came across loads of articles explaining all this, but none were really clear, so I thought I might cover the subject again. Partly for those who follow after me, and partly so I never need to research this again.

So for posterity here’s how to go about it.

Creating the Exclude Filter

I have written a seperate post on how to add an Exclusion Filter to Analytics in 10 easy steps with loads of screenshots.

How to add an Exclusion Filter to Analytics in 10 steps



Creating the Cookie

Rather than go down the route of having to install something onto my website, I decided to create a BookMarkLet to generate the exclusion cookie.

This means I can use it for any site, it is quick and simple to use and most importantly there is no need to install anything on the website itself.

Another benefit is that I can get anyone working on or reviewing my site to use it as well, without too much trouble. All in all, a win-win solution to the problem.

Get the BookMarkLet: Drag this link to your browser bar (add it to your bookmarks)
GA IgnoreMyHits

Then to put the cookie in place:

• Go to the site you want to stop recording hits on
• Click on the bookmarklet(above) you have stored
  
  • let it add the exclusion cookie to your browser.

First : choose you exclusion cookie name...

 Then: Make sure it all worked. It will recognise your analytics install and tell you which one it detected.

If, like me, you use differant browsers for testing, make sure you do this with all of your browser,s rather than just your main one. This will ensure that your analytics results are totally accurate.

The only thing you must ensure is that you use the same name for both the cookie and the exclusion filter in analytics.



So there you go a nice quick simple solution for clearing up your Analytics results.

I would like to thank, Justin Cutroni , as his blog was the first clear explanation I encountered.



A shameless plug..

Bring the benefits of over 15 years experience in internet technologies, from programming through to usability & design, persuasive copy-writing and site speed optimizations.
Check out my consulting company, Technical Magic.

onDOMLoad: Faster javascript for faster pages with a cross browser version of DOMContentLoaded

I have been quite entertained by all the recent talk about page loading speeds, optimization and profiling (eg: YSlow), so I decided to wrap up one of my functions into a usable form for you to dissect.

I call it, onDOMLoad.

Go and have a look at the demo of onDOMLoad.

onDOMLoad is a wrapper to the code suggested by Dean Edwards,Matthias Miller & John Resig. It is cross-browser capable and I hope pretty easy to understand.

Download

The Javascript is available to download here and here in minified form.

I have fully documented the uncompressed version

I like easily readable code, as I will often come back to it 6 months or a year later, and I hate spending hours working out how my own code runs.

Why use my version

onDOMLoad does vary from the few other solutions out there. It is very small, 1K minified. It works nicely in co-operation with the window.onload function. But most importantly, onDOMLoad allows multiple functions to be specified.

Future stuff

I have seen some great possible improvements, like Hedger Wangs implementation of Diego Perinis IE readyState check. I will post more updates here when I think they are ready.