I’ve been focusing more and more on my port of Ling-to-Objects, Jsoq the past few weeks. It’s still in really early stages and I’m not quite sure about it’s actual usefulness but I’m learning a lot about JavaScript and having a ton of fun along the way!

Jsoq deals with arrays a lot. About 95% of it’s use cases involve either looping through, altering, or creating arrays. Having a ton of for loops in my code just seems so… not right. For loops have always seemed dirty to me. They just aren’t elegant enough.

Here is your normal, average, everyday for loop in Javascript.

var array = "1,2,3,4,5,6,7,8,9,10".split(',');

for(var i = -1, l = array.length; ++i < l;) {
    alert(array[i]);
}

This works. It’s reliable and gets the message across. But what if we needed to loop over an array and get all the items that matched a condition? Using a for loop the code could look something like:

var array = [ 1, 2, 3, 4, 5, 1, 2, 3, 4 ];
var results = [];
var condition = function(i) { return i%2 == 0; };

for(var itt = -1, len = array.length; ++itt < len;) {
	if( condition(array[itt]) ) {
		results.push(array[itt]);
	}
}

This does work, I’ve written code like this many times before, and while technically there isn’t anything wrong with it I think there is still room for improvement.

Jsoq is going to be handling arrays all over the place so the solution to this problem needs to be simple.

Here’s what I need:

• to loop over an entire collection and perform an action on each item.
• If that action produces a result, the item is to be pushed into an array and returned to after the loop is done

.

• Also: it needs to be readable, someone else coming along should be able to determine what this thing is doing without too much difficulty. So I had my work cut out for me.

A few hours later I had a decent function that I could use to replace a lot of the for loops I had. After some more refactoring I was able to wipe them all out and replace them with calls to enumerateOver(). Here is the latest version from source control:

function enumerateOver(collection, work) {
	var result = [], val = [];

	if (isArray(collection)) {
		try {
			for (var i = -1, l = collection.length; ++i < l;) {
				result = work(collection[i], i);
				if (typeof result !== "undefined" && result != null) {
					val.push(result);
				}
			}
		}catch (e) {
			if (e != jsoq.$break) throw(e);
		}

		if (val.length > 0) {
			return val;
		}
	}else {
		try {
			val = work(collection, 0);
		}
		catch (e) {
			if (e != jsoq.$break) throw(e);
		}
		if (typeof val !== 'undefined') {
			return val;
		}
	}
	return result == null ? [] : result;
}

And here is the code to replace the for loops above, re-written to use enumerateOver()

var results2 = enumerateOver(array, function(i, c) {
     return i%2 == 0;
});

So by implmenting this function I was able to come up with a more readable, testable and streamlined codebase. Is this suitable for everyone? Definitely not, but I did it for a few reasons:

1. Like I mentioned before. I’ve never been at ease with for loops and being able to replace them all with calls to a single function was a huge win for me
2. The normal use-case didn’t fit right. I needed to not only iterate over arrays but also return the results of work performed on those items. Doing this the “regular” way just wouldn’t work (see previous reason)
3. I thought this was a fun problem to solve

If you have any feedback, good, bad, or indifferent add a comment!

I coded up this jQuery extension method which will return a jQuery-wrapped DOM instance for any of the matched IFrames.

(function($) {
    $.fn.extend({
        dom: function () {
            var $this = $(this);
            var getDom = function(o) {
                if( !o || (!o.contentWindow && !o.contentDocument) ) {
                    return null;
                }

                var doc = (o.contentWindow || o.contentDocument);

                return doc.document || doc;
            };

            var dom = getDom($this[0]);

            return dom === null ? $this : $(dom);
        }
    });
})(jQuery);

So with this, getting the styles for a child IFrame is as easy as:

$('iframe').dom().find('head link').each(function(index, item) {
    alert(item.href);
});

Unfortunately, this code will only work if your IFrame is hosting content that is on the same domain as its parent.

And then you get an email one day:

“Everything is broken. We’ve kidnapped your dog. Fix our site or you’ll never see Spartacus again.”

And before you have time to wonder why you ever named your dog “Spartacus” to begin with (i mean come. on.), you’re off in debug hell. You load the site and see all sorts of weird errors:

“$().ready is not a function”

“$(document) doesn’t support this property or method”

Or my personal favorite:

“null is null or not an object”

You open up FireFox, activate FireBug, load the console, and type “alert($)”, press run, and instead of seeing the expected jQuery function:

function (E, F) {
    return new (o.fn.init)(E, F);
}

You instead get:

function $(element) {
    if (arguments.length > 1) {
        for (var i = 0, elements = [], length = arguments.length; i < length; i++) {
            elements.push($(arguments[i]));
        }
        return elements;
    }
    if (Object.isString(element)) {
        element = document.getElementById(element);
    }
    return Element.extend(element);
}

Or even:

function $(id) {
    return document.getElementById(id);
}

DOH! Looks like another javascript library has been loaded and has overwritten the $() shortcut for jQuery. Woe is I. Why can’t we all just get along?!?

Well, we can’t stop people from including their favorite javascript libraries, but what we can do is prevent our code from suffering as a result. We’ll need a nice, big beefy, bodyguard to make sure our code isn’t messed with while it’s out clubbing with Prototype, Scriptaculous or even MooTools (who invited him??!?).

Here’s what our bodyguard function will look like

( function($) {

} ) ( jQuery );

So what this does is call our anonymous function and pass the jQuery object. This will scope ‘$’ to within our little function so we won’t step on anyone else’s toes (and they won’t bump into us while we’re on the dance floor and spill our drink everywhere). Okay, I think I've taken the clubbing metaphor far enough.

Basically this will allow our code to run and use the $ shortcut for JQuery as if it were loaded without any of these other libraries on the page.

Here is what the completed code would look like:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js" type="text/javascript">
</script>

<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.1.0/prototype.js" type="text/javascript">
</script>
<script src="http://ajax.googleapis.com/ajax/libs/scriptaculous/1.8.3/scriptaculous.js" type="text/javascript">
</script>

<script type="text/javascript">
( function($) {
    // we can now rely on $ within the safety of our “bodyguard” function
    $(document).ready( function() { alert("nyah nyah! I’m able to use '$'!!!!");  } );
} ) ( jQuery );

//this will fail
$(document).ready( function() { alert('fail?'); } );
</script>

I love using this simple self-calling anonymous function style when working with jQuery because it saves me from typing jQuery(), which really does look a lot more ugly than using the $() shortcut. It also protects my code from any scoping issues and lets the code function normally when jQuery is put into no conflict mode.

My opinion, if you're doing work in jQuery on sites that you don't control 100%, you should be using this method to protect your code and your clients.

Updated: changed link for jquery to use 1.4.1 at the google CDN (tsk, tsk, tsk I was using the googlecode.com link)

So I did pretty much the same thing Jeff did and here is what I found:

* System specs: Windows 7 64-bit on a Dual-Core 2.53ghz CPU with 4gb of RAM with no browser extensions

1. Chrome kicks some serious butt over everyone else with the entire test suite running to completion in under 1 second!!
2. FireFox 3.5 has some serious improvements coming in at just over 1.5 seconds total, which is about 1/10 the time it took FireFox 2.0
3. Internet Explorer 8 and Internet Explorer 7 (compat mode) are still bringing up the rear but they had a better showing than the 20+ seconds IE7 took when Jeff ran the test

Surprises?
The only thing I found surprising about the results was that if you removed the string test from both IE runs then IE8 in compatibility mode beats IE8 running normally. That doesn’t seem right to me and I seriously hope JavaScript performance is something that gets addressed in IE9. And by “addressed” I mean “fixed by replacing Trident with WebKit”.

So, what do these results actually mean? Well I guess it depends. If you use your browser to read blogs and check your gmail then you shouldn’t really care about these numbers. However, if you’re a web developer you should be paying strong attention to these numbers and how far they’ve come in just 2 years.

Here we are with another excellent installment in the “Works On My Machine” series where I post some code, some thoughts and hopefully show you something interesting/cool/new.

Today I’m going to talk briefly about Project Euler problem #3. Problem 3 asks you to find the largest prime factor of the number 600,851,475,143.

My solution is pretty simple but it works:

var getLargestPrimeFactor = function(num)
{
    var factors = [];
    for ( var f = 2; f < num; f++ )
    {
        if( num%f == 0 )
        {
            factors.push(f);
            num = num /f;
        }
    }
    factors.push(num);
    return factors[factors.length-1];
};

alert( getLargestPrimeFactor(600851475143));

Try this code!

You may have noticed that there isn’t a check for a factors optimus primeness anywhere in there.

Thats because the getLargestPrimeFactor() function is dividing the number by it’s smallest factor, and the smallest factor for any number is always prime so when we run out of factors we’ve got the largest prime factor. Yeah, that’s pretth cool IMO.

I read the discussion threads for problem 3 after I solved it and I was surprised that hardly anyone removed the prime checks from their code.

So, problem 3 is in the bag and I feel pretty good about coming up with the prime check optimization (or lack thereof). A small bit of proof that I know what I’m doing. Sometimes :D

I built the initial JSOQ Console (which is still included with the JSOQ source code) in about 20 minutes and it increased my productivity by 10x.

It was much faster to test JSOQ functions with the JSOQ Console than it had been with unit-tests. As a result I was able to prototype new functionality in about 1/2 the time.

I’ve finally moved v0.2 of the Jsoq Console to my blog here so you can use it to quickly test out your own JavaScript code!

How it works is pretty straight forward. If you’ve got a snippet of JavaScript, be it jQuery (for the moment jQuery is the only external library that is supported but that will change soon), JSOQ or any other javascript code, you can run it with the JSOQ Console.

Just navigate to http://tinyurl.com/jsoqconsole or http://codeimpossible.com/jsoq for those of you that like to type, paste your code into the textarea at the top of the page, press “Run” and your code will run!

So enjoy! If you get confused there are also samples that will show you how to use the more “advanced” features. Also, drop a comment or share the console with others if you thought it was useful!

Project Euler is an awesome website that I found out about a while back via this question on StackOverflow. Basically, it’s a website that poses a ton of programmer related challenges and it keeps track of the problems that you solve.

The problems start out relatively easy (Add all the natural numbers below one thousand that are multiples of 3 or 5.) and progress all the way to insane (Caradano Triplets and Covex Holes).

I’m on the easy side, I just started working through them tonight and thought it would be cool to post how I build the solution to each problem as I complete them.

Problem 2 is pretty easy:

“Find the sum of all the even-valued terms in the Fibonacci sequence which do not exceed four million.”

So first things first, I’ll need to pick a language to use to solve this. I chose javascript simply because it was something I knew I could get running pretty quickly.

Next I’ll need some variables. (note: if you’re not familiar with Fibonacci numbers Wikipedia has an awesome article on them.)

var start = 1, end = 4000000, current = 1, previous = 1, sum = 0, temp = 0;

That should do. I’ve got my start variable (dropping the 0 in favor of more readable code), my end counter, and my “where-am-i” variables: current, previous, temp and my sum variable.

Obviously we’ll need some kind of loop. How about a while loop?

while( current <= end )
{

}

Cool. Now when the loop is running I'll need a way to keep track of the current value, the previous value and I need to add the current value to the sum. So....

while( current <= end )
{
    temp = current;
    current = current + previous;
    sum += current;
    previous = temp;
}

And there we hav... Oh Wait!

I overlooked a pretty important part of the problem description: "sum of all the even-valued terms"!!!

So given this new(ish) piece of info my solution end sup being:

var start = 1, end = 4000000, current = 1, previous = 1, sum = 0, temp = 0;

while( current <= end )
{
	temp = current;
	current = current + previous;

	if( current%2 == 0 )
		sum += current;

	previous = temp;
}

alert(sum);

So, yeah I originally started writing this article back in september when I was about mid-way through JSOQ. Some things have changed since then and I’ve tried to keep the post up-to-date. Enjoy!

Also, another similar library has come out recently: JSINQ which is a really feature-rich LINQ to Object implementation in Javascript. Really bad-ass stuff.

The Elevator Pitch:

JSOQ is an open-source pet project of mine that lets you easily access the data that you need from large collections in JavaScript. It was developed over a two week period in September of 2008 and is currently at version 1.1.

Everyone probably just shrugged and said “so??” Well let me show you. 

Lets assume that you have the following JSON string from another web application like, say twitter search results for example:

{"results":[
{
"text":"Just another day at the office",
"to_user_id":null,
"from_user":"codeimpossible",
"id":1194587890,
"from_user_id":1316793,
"iso_language_code":"en",
"profile_image_url":"www.path.to.image.us",
"created_at":"Tue, 10 Feb 2009 05:47:33 +0000"
},
{
"text":"@spolsky thats easy! http:\/\/tinyurl.com\/2z42bs",
"to_user_id":1357501,
"to_user":"spolsky",
"from_user":"codeimpossible",
"id":1194582705,
"from_user_id":1316793,
"iso_language_code":"en",
"profile_image_url":"www.path.to.image.us",
"created_at":"Tue, 10 Feb 2009 05:44:51 +0000"
}
]} 

In the sample above we only have two results but JSOQ has been tested to work with collections of tens of thousands of items.

The JSON object we have here is perfectly fine if we watned to show a whole bunch of data to the end user, but what if I only wanted to show the search results after a certain date? Or what if I only wanted the text from each message that was typed to this “spolsky” character?

To accomplish this in “straight” javascript I’d be looking at writing a lot of loops and if/else code and then I would still have all these extra properties that I don’t even need.

JSOQ allows me to query a javascript object or collection of objects using a specified criteria and return only the properties/methods I want.

So lets go with the second option. Let’s get all the .text members from all the messages that were sent to the “spolsky” user.

var search_results = eval(our_json_result);
var result = null;
with(jsoq) {
    result = From(search_results.results)
                .query('text')
                .where(function(i) {
                    return i.to_user === "spolsky";
                });
}

And now our result object is filled with a bunch of other objects that would look something like:

{
    text: "@spolsky thats easy! http:\/\/tinyurl.com\/2z42bs"
}

Pretty simple eh? For more information on JSOQ please check back here in the near future or contribute to the google code repository.

EDIT: ok, so Chrome is fast. Really fast. I loaded Oliver Hunt’s JavaScript Ray Tracer in FireFox 3.0.3 and it took 30.393 seconds to complete a render. Under Chrome the render took less than 6.5 seconds.