jqcolor: A jQuery Plugin port of jscolor

That’s right, my idea of a great Sunday afternoon is porting someone else’s code!

At first I was thinking, “I should email this guy and tell him to make a jQuery plugin”. But then I thought, “I’m the one who needs the jQuery plugin…” so I made it. Maybe now I’ll email him and say “I made a jQuery plugin for your color picker”.

Usage:

jQuery(‘input.color’).colorPicker();

This port is from the 1.0.9 version. jscolor was completely rewritten in 1.1.0 and looked like it had some regressions though it is at 1.2.3 now. The newer version is twice as big, still not a jQuery plugin, and also still missing hundreds of semi-colons, so I decided to stick to what I know and work on the smaller version.

So now it is a clunky jQuery plugin. There are still several spots where the syntax could be improved to take advantage of jQuery, but since there are no tests, and I don’t have a bunch of different browers to QA on, I decided to leave it alone as much as possible.

Source on github.

PriorityQueue.js

Ever need a simple priority queue? I sure as hell did. JavaScript doesn’t make sharing code easy, so I’m going the extra mile to bring you this: PriorityQueue.js.

Features:

  • Simple to use and understand.
  • Creates a single PriorityQueue constructor.
  • Instantiate via `PriorityQueue();` or `new PriorityQueue();`
  • Offers both highest first and lowest first ordering.
  • Test suite included.

The default is highest priority first, but when doing something like A* you want lowest priority first… it handles it: `queue = PriorityQueue({low: true});` Boom!

Code is on github.

BarCamp SD 5 Recap

Lots of amazing presentations at BarCamp.

I gave a presentation on using HotRuby and jQuery to allow you to use Ruby as a scripting language. It turned out pretty well. A lot of people were interested and no one walked out in disgust, so I’ll call it a success.

I was also coaxed into giving an intro to Ruby presentation by popular demand. I think that it helped a lot of people gain an understanding of Ruby. Give it a try: Try Ruby! (in your browser)

I really enjoyed attending the wide range of talks. Some of my favorites:

  • Meta-procedural Political Processes – Organization techniques to facilitate democratic decision making.
  • Improv! – A short interactive improv class. “Who let you in?”
  • People Hacking 2 – A brief overview of neuro-linguistic programming.
  • Communication – Tips on improving your speaking skills.
  • Emergence – How complex systems emerge from simple rules.
  • Ethnography – How to study the behavior and work flow of people.
  • Pictures that Think – How technology is affecting our use of imagery.
  • Intro to Python – I’ve always wanted to learn more Python.
  • Making music with SchemeImpromptu
  • Hadoop and BigTable style DBs

The surprise winner of the presentations was on BigTable and Hadoop style databases. It was actually a reverse presentation where the “presenter” put it on the wall to learn more. A couple people who attended had experience with that type of database and shared their experiences with the trade-offs involved with the group. It turned into an interesting discussion with questions from the attendees with less experience and learning the general principles from multiple experienced users in an open discussion. It was a really engaging way to learn!

Overall BarCamp was a great success. I’ll have to make a regular habit of attending.

June Readership Survey

Greetings readers, new and old. Now is the time for the STRd6 June Readership Survey!

What kind of articles are you interested in reading more of?

  • Technical articles about specific technologies.
  • General articles about programming practices.
  • Stories about programming.

What technologies are you most interested in reading about?

  • Ruby and Ruby on Rails
  • JavaScript

What applications and areas of programming are you interested in reading about?

  • Web programming
  • Game programming
  • Data structures and algorithms
  • Libraries and APIs

Please respond in the comments; I’m eager to see any other suggestions you have as well!

The Next Big Browser Language

A long time ago in a galaxy far far away… actually a couple years ago, in Japan, a man was toiling away on creating a Ruby VM completely written in JavaScript. The year was 2007, Ruby 1.9.0 was still new and the global economy was in full swing. Everything was looking great for Ruby VM’s, Flash, the browser? It’s all good. Benchmarks proclaimed amazing speed increases and the RSS feeds were abuzz with the news.

But then the months went by and not much happened. Then sometime in June 2008 the source got imported into github. Then another month went by and again, not much happened, although the HotRuby website did get a redesign. Then almost a year went by, nothing much happened. Not much news on any front…

And that about catches us up to last week. I was doing some deep digging into JavaScript. I was thinking about ways to implement more Rubyesque patterns like Modules and the like when I remembered reading about the HotRuby VM a while back. I wanted to know if I could sidestep this whole JavaScript issue by running Ruby as a scripting language in the browser.

JavaScript is the de facto language of the internet. It has a distinct terribleness to it, but also a grotesque beauty. It is a powerful, misunderstood language that grew up to fast, being robbed of it’s childhood during the great browser wars. And now, after a resurgence or two, it is really coming into its own. ECMAScript 5th Edition looks to be a beacon of hope, but will it really be as joyful as being able to program Ruby as a browser scripting language? JavaScript frameworks have shown strong improvement and make working with the DOM nearly pleasant. All this means that we can’t just sit around and wait for JavaScript to die. If we do we’d just get stuck with another compromised language anyway.

But something happened over the past year during which HotRuby was laying fallow. Many things happened. Google released a browser adding another horse to the current browser race. JavaScript implementations are racing to improve performance. In addition, this now makes two major players in the browser market open source browsers: patches can be submitted that provide support for scripting languages beyond JavaScript.

Ruby 1.9.1 was released and is slowly gaining steam. It’s matured significantly and now the opcodes will be less susceptible to change, good news for VM implementers. Ruby has also permeated all the major platforms with JRuby and IronRuby (and even BlueRuby!!). Developers may wish to use Ruby as a clientside scripting language as well, I sure as hell know that I do.

And that’s why I did it. That’s why I did what had to be done. I forked the github repository of HotRuby (github sure makes picking up where others left off easy!), I hammered and hammered until it “worked” with Ruby 1.9.1 (and broke it only a little). And I added jQuery. I thought that in order to get Ruby into the browser that I might have to implement an entire interface to the DOM, but that was misguided. Implementing an entire DOM manipulation package in Ruby would be a waste when jQuery brings an admirable elegance to JavaScript, such that you can almost forget JavaScript’s ugly dark secrets. Now that Ruby can run in the browser and easily access $native objects, jQuery fits in exactly where Ruby needed it.

So check it, the long term vision: JavaScript RubyVM (HotRuby) provides a way to script in Ruby on legacy browsers (IE). Ruby implemented natively as a clientside scripting language in all modern browsers (Chrome, Firefox). jQuery continues to rock the DOM. Everyone wins!

And the good news is that it’s not too far in the future…

JavaScript: Hitting Bottom #3 – The Crucible of Truthiness

Some programming languages judge truth by the nature of non-zero values (C); some by non-false, non-nil values (Ruby). JavaScript follows it’s gut. If it seems true it’s usually true, if it seems false it’s usually false… usually.

There are two kinds of truth in JavaScript, things that take the `if` branch in `if-else` expressions; and things that == false.

Let’s start with things that == false:

    test("false idols", function() {
      equals(0 == false, true);
      equals('' == false, true);
      equals(' ' == false, true);
      equals('0' == false, true);
      equals([] == false, true);
 
      equals(null == false, false, "!");
      equals(undefined == false, false, "!");
    });

The first thing to note is that empty strings and strings that can be converted to the integer zero are == to false. The second thing to note is that `null` and `undefined` are not == to false. A lot of things in JavaScript == false, actually infinitely many. A lot of different arrays for example:

    test("false Arrays", function() {
      equals([0] == false, true);
      equals([''] == false, true);
      equals([' '] == false, true);
      equals(['0'] == false, true);
      equals([[]] == false, true);
      equals([false] != false, true, "!!! The `toString()` is 'false'");
      equals([null] == false, true);
      equals([undefined] == false, true);
 
      // It goes on like that, the toString ends up as '0'
      equals([[[[[[[[[0]]]]]]]]] == false, true);
 
      // This adds weight to the toString hypothesis
      equals([{toString: function() {return '';}}] == false, true);
      equals([{toString: function() {return '0';}}] == false, true);
    });

Some Objects with particular `toString` methods also == false:

    test("Objects with toString methods defined that are equivalent to false", function() {
      equals({toString: function(){return false}} == false, true, "!!");
      equals({toString: function(){return null;}} == false, true, "!!");
      equals({toString: function(){return '';}} == false, true, "!!");
      equals({toString: function(){return '0'}} == false, true, "!!");
      equals({toString: function(){return 'false'}} != false, true, "!!");
      equals({toString: function(){return undefined}} != false, true, "!!");
    });

Also, as mentioned previously, any strings that convert to the number zero such as:

    test("false Strings", function() {
      equals('                        ' == false, true);
      equals('            0.          ' == false, true);
      equals('0.0000000000000000000000' == false, true);
    });

Sounds like it would be hard to keep track of everything that evaluates to false… but don’t worry it has no effect on if-else statements. For if-else statements only things that are cast to the primitive `false` by Boolean matter. Wouldn’t Boolean cast everything that == false to be `false`? Not on your life!

    test("Boolean Goolean", function() {
      equals(Boolean(false) == false, true);
      equals(Boolean(0) == false, true);
      equals(Boolean('') == false, true);
      equals(Boolean(null) == false, true, "!!");
      equals(Boolean(undefined) == false, true, "!!");
      equals(Boolean(NaN) == false, true, "!!");
      equals(Boolean(' ') != false, true, "!!");
      equals(Boolean('0') != false, true, "!!");
      equals(Boolean([]) != false, true, "!!");
      equals(Boolean(new Boolean(false)) == true, true, "!!!");
    });

The exclamations are included for the ones that == false is different for. The only six things that evaluate to false in an if expression are: false, 0, null, undefined, NaN, and ”. Few enough to count on one hand! Aside from Boolean casting things that == false to `true` and casting things that != false to `false`, the one big thing to watch out for is that all Boolean objects are cast to `true` especially `new Boolean(false)` so don’t use it in your if statements!

Here’s a long boring series of tests to illustrate that the if-else branching does indeed match how Boolean casts things and not whether or not they == false. Exclamations where it’ll getcha. I’ll leave it as an exercise for the reader to skim to the bottom, say “hmmm…..” and then start browsing Reddit (or Hacker News).

    test("if statements", function() {
      var x;
      var ifX;
 
      x = undefined;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!!");
 
      x = null;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!!");
 
      x = false;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
 
      x = true;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true)
 
      x = 0;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
 
      x = NaN;
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!!");
 
      x = '';
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, false);
 
      x = ' ';
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true);
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, false, "!!");
 
      x = '0';
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!");
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, false, "!!");
 
      x = [];
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!");
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, false, "!!");
 
      x = {};
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true);
 
      x = {toString: function(){return '';}};
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true);
 
      x = new Boolean(false);
      if(x) { ifX = true; } else { ifX = false; }
      equals(ifX, true, "!!!")
      if(x != false) { ifX = true; } else { ifX = false; }
      equals(ifX, false, "!")
    });

JavaScript: Hitting Bottom #2 – FUNdefined

What better way to understand a language than to understand the basic types? And what can be more basic than `undefined`?

    /**
     * Undefined is generally well behaved.
     */
    test("FUNdefined", function() {
      equals(undefined > 0, false);
      equals(undefined < 0, false);
      equals(undefined >= 0, false);
      equals(undefined <= 0, false);
      equals(undefined == 0, false);
      equals(undefined === 0, false);
 
      equals(undefined == null, true);
      equals(undefined == false, false);
      equals(undefined == true, false);
 
      equals(undefined === null, false);
      equals(undefined === false, false);
      equals(undefined === true, false);
 
      equals(undefined == undefined, true);
      equals(undefined >= undefined, false, "!");
      equals(undefined <= undefined, false, "!");
    });

Pretty much no surprises there. The only thing to watch out for is that `(undefined >= undefined) == false` which makes some sense mathematically, but it might make more sense for it to equal `undefined`.

But where’s the FUN? I wouldn’t have a reputation as a professional ranter about JavaScript if I didn’t rant about JavaScript…

    /**
     * null is pretty weird. It's almost like zero but not equal to false.
     */
    test("null", function() {
      equals(null > 0, false);
      equals(null < 0, false);
      equals(null == 0, false);
      equals(null >= 0, true, "!!!");
      equals(null <= 0, true, "!!!");
      equals(null === 0, false);
 
      equals(null == false, false, "!!");
      equals(null >= false, true, "!!!");
      equals(null <= false, true, "!!!");
 
      equals(null > true, false);
      equals(null < true, true, "!!!");
      equals(null == true, false);
      equals(null >= true, false);
      equals(null <= true, true, "!!!");
 
      equals(null == undefined, true);
      equals(null >= undefined, false, "!");
      equals(null <= undefined, false, "!");
 
      equals(null == null, true);
      equals(null >= null, true);
      equals(null <= null, true);
    });

Legend

  • “!”: “note this!”
  • “!!”: ‘hmm… strange.”
  • “!!!”: “WTF!?!?!”

This set of tests for the behavior of null has a ratio of 22/20 !s/line. That means that there is significant unexpected behavior around `null`. The `undefined` exploratory test only had 2/15 !s/line, much less crazy. Let me repeat the most insane part:

      equals(null == false, false, "!!");
      equals(null >= false, true, "!!!");
      equals(null <= false, true, "!!!");

I’ve basically given up on comprehension of this particular behavior and just settled for explanation and documentation instead.

So, what’s the point? Am I just picking on poor little old JavaScript? Partly, but my real aim is to document the myriad of strange and tantalizing (and infuriating) edge cases.

The moral of the story is to return `undefined` from methods where the result may be involved in a numeric comparison rather than null. Additionally `undefined` is the result returned by the empty function:

    equals((function(){})() === undefined, true);

so it’s more natural. The other recommendation is to always use the strict equality operator, it cuts out the most common weird edge cases. Tools like JSLint will point out situations where some subtle bugs can arise, use them!

The roller-coaster whirlwind-tour continues tomorrow with “The Crucible of Truthiness”. Stay tuned!

JavaScript: Hitting Bottom #1 – Constructors

Welcome to the first installment in an infinite series on JavaScript I like to call “Hitting Bottom”. JavaScript is an amazing language. Amazingly brutal and amazingly misunderstood. If you’re feeling “pretty confident” with your grasp on the JavaScript language then this series will destroy that confidence.

I was feeling pretty confident, I remembered feeling pretty confident about JavaScript a couple years ago too and having that confidence dashed upon learning more. Now that confidence is dashed again, but I’m building it up… slowly. And maybe I can bring you along with me this time, to spare you from waking up under an overpass on the information super highway, covered in CSS classes and your own vomit, pulling angle brackets out of your hair and scrounging around in your pocket for enough $() to purchase one more bottle of #B0053.

So, onwards.

Constructors, what are they? They are the functions that construct objects. Check it:

      equals({}.constructor, Object, "{}.constructor");
      equals([].constructor, Array, "[].constructor");
      equals(''.constructor, String, "''.constructor");
      equals(true.constructor, Boolean, "true.constructor");
      equals(false.constructor, Boolean, "false.constructor");
      equals((function(){}).constructor, Function, "anonymous function constructor");

Pretty cool. And if we were to make our own constructor JavaScript would be totally chill with that.

      function A() { }
      var a = new A();
      equals(a.constructor, A, "a.constructor");

That’s the wonderful thing about JavaScript, if you are doing regular things then everything works as expected.

      function B() { }
      var b = new B();
      equals(b.constructor, B, "b.constructor");
 
      B.prototype = new A();
      var b2 = new B();
 
      equals(b.constructor, B, "Constructor for existing object does not change after changing prototypes");
      equals(b2.constructor, A, "Constructor for new objects changes after changing prototypes");

So constructors are defined when the object is created, based on the prototype property inheritance chain. They don’t change for previously created objects when the prototype property changes, but newly created objects will have the new value for the constructor.

      function C() {}
      B.prototype = new C();
      var b3 = new B();
 
      equals(b3.constructor, C, "Constructor for new objects changes after changing prototypes again.");

It just keeps going deeper if you have more prototypes. Maybe there was like half a trick in there. Somehow I don’t think we’ve hit bottom yet.

JavaScript Hashtable for Objects

JavaScript…

there comes a time in every developer’s life when he wishes to be able to use a Hash in JavaScript like he can use a Hash in Ruby, you know, easily. This usually comes up when implementing A* or some other crazy graph search algorithm.

The problem: JavaScript objects make great Hashes for String and Number keys, but not for Object keys. Some QUnit tests highlight the problem readily.

    test("Hash sux?", function() {
      var x = {};
      var y = {name: "My Cool Object"};
      var barbazfoo = {name: "My Uncool Object"};
 
      x['a'] = true;
      x['b'] = true;
 
      equals(x['a'], true);
      equals(x['b'], true);
 
      x[y] = y.name;
      x[barbazfoo] = barbazfoo.name;
 
      equals(x[y], y.name); // Failed! y.toString == "[object Object]"
      equals(x[barbazfoo], barbazfoo.name);
    });

Now we have two options as I see it: download (or hand roll) our own Hashtable class that has even more akward syntax, worse performance and clocks in at 5k minified… or implement a toString() method that generates unique strings for each object (of types that we care about).

I opted for the second choice, after coming very close to choosing the first. Now if only there were some magical way to implement a unique toString method for all my objects that might want to end up as hash keys.

(function() {
    var id = 0;
 
    /*global GameObject */
    GameObject = function(game) {
      var self = {
        // Empty update by default
        update: function() {},
        click: function() {},
        objectId: '#Object:' + (id++),
        toString: function() {
          return self.objectId;
        }
      };
      return self;
    };
  })();

Gerta Rauss: So, we all agree that a closure is the best decision for all involved?

Juno MacGuff: SSHHIT! YES! Closure it up!

Now any GameObject can be used as a key to a hash, and as long as you aren’t going nuts and mixing and matching crazy strings as your keys you should have no collisions, or at least way fewer than 100%. Thanks a heap ‘[object Object]‘!.