Pixie: A jQuery Plugin port of Pixie

That’s right, my idea of a great Saturday afternoon is porting my own code! I wanted to use Pixie in my new Dog Seeder game. It seemed easy enough.

At first I was thinking, “I shouldn’t have to rewrite this”. But then it actually turned out to be unusable. That’s right completely unusable. Well… un-reusable. The first problem was that the code tightly coupled with the specific page html. Referencing certain divs with certain ids. If I wanted to embed it into a new page I’d need to copy all that HTML over. Related to those specific divs the editor was all over the global namespace. There was one `canvas` object and that’s THE canvas, and THE canvas is div#canvas. Ouch…

This was also problematic for extending functionality and adding tools. Each tool was hardcoded into the page. The tools were in div#toolbox and had hardcoded onclick events to call things like `canvas.setTool(pencil)`. More globals… So the mission of extracting that to be useful in another page was too great. It was easier to just rewrite it all with all these good practices in mind, embedability, and extensibility. The long and short of it is that you, gentle reader, really lucked out because now Pixie is way, way better.

Let’s take a look at what’s needed to create a Pixie pixel editor on a new page:


And #pixie is just an empty div! Ok, you do need to include a couple javascript files and some image directories if you want it to work or look good, but nothing special in the HTML itself.

But what if I want to make a new save button that saves the image into Dog Seeder instead locally. I’d need to dig deep into the internals in the old Pixie, but not anymore!

      initializer: function(canvas) {
          name: "Save to Creature",
          perform: function(canvas) {
            images[$('#img_path').val()] = canvas.toDataURL();
            $.each(gameObjects, function() {

Wow, that sure was easy. Maybe I can challenge myself by adding a new tool instead:

            initializer: function(canvas) {
              var partyPaint = function() {
                this.color(this.canvas.color(rand(2) === 0));
                $.each(this.canvas.getNeighbors(this.x, this.y), function(i, neighbor) {
                  if(neighbor) {
                    neighbor.color(neighbor.canvas.color(rand(2) === 0));
                name: "Party Brush",
                hotkeys: ['Y'],
                mousedown: partyPaint,
                mouseenter: partyPaint

That was pretty easy too. Just to save everyone the shame of asking: “Yes, it’s all easy. Yes you can add as many tools and actions as you want. What, icons? Yes, that’s easy too.” Don’t worry, I’ll post some all the examples I have at the end of the post.

And don’t worry about having to muck with the internals, all the standard tools are written using the same API, so anything the pencil tool or clone stamp tool does you can do too. And a lot more. The opportunities are endless.

Speaking of the API, although I feel that it is pretty good, there may be room for improvement. This is a new release and there may be changes in the future. What I’m trying to say is don’t be afraid to suggest improvements and also don’t be surprised if the API changes in a future version.

So what are some of the amazing possibilities for tool extensions? Let’s take a look at what exists so far:

  var tools = {
    pencil: {
      name: "Pencil",
      hotkeys: ['P'],
      icon: imageDir + "pencil.png",
      cursor: "url(" + imageDir + "pencil.png) 4 14, default",
      mousedown: function(e, color) {
      mouseenter: function(e, color) {
    brush: {
      name: "Brush",
      hotkeys: ['B'],
      icon: imageDir + "paintbrush.png",
      cursor: "url(" + imageDir + "paintbrush.png) 4 14, default",
      mousedown: function(e, color) {
        $.each(this.canvas.getNeighbors(this.x, this.y), function(i, neighbor) {
          if(neighbor) {
      mouseenter: function(e, color) {
        $.each(this.canvas.getNeighbors(this.x, this.y), function(i, neighbor) {
          if(neighbor) {
    dropper: {
      name: "Dropper",
      hotkeys: ['I'],
      icon: imageDir + "dropper.png",
      cursor: "url(" + imageDir + "dropper.png) 13 13, default",
      mousedown: function() {
    eraser: {
      name: "Eraser",
      hotkeys: ['E'],
      icon: imageDir + "eraser.png",
      cursor: "url(" + imageDir + "eraser.png) 4 11, default",
      mousedown: function() {
      mouseenter: function() {
    fill: {
      name: "Fill",
      hotkeys: ['F'],
      icon: imageDir + "fill.png",
      cursor: "url(" + imageDir + "fill.png) 12 13, default",
      mousedown: function(e, newColor, pixel) {
        // Store original pixel's color here
        var originalColor = this.color();
        // Return if original color is same as currentColor
        if(newColor === originalColor) {
        var q = new Array();
        while(q.length > 0) {
          pixel = q.pop();
          // Add neighboring pixels to the queue
          var neighbors = this.canvas.getNeighbors(pixel.x, pixel.y);
          $.each(neighbors, function(index, neighbor) {
            if(neighbor && neighbor.css("backgroundColor") === originalColor) {

Most of these are pretty simple. Also notice how easy it is to set a hotkey and icon/cursor. The mousedown and mouseenter are the standard tool workhorse methods. They are called with `this` bound to the pixel that the event occurred in. The pixel object is an extended jQuery object, so methods like this.css(someprop, somevalue) also work. The extended part provides utilities like `x`, `y` and `canvas` properties, as well as a color() getter/setter shortcut. Take a look and if it’s not immediately obvious leave a comment so that I can fix my failure and make it clear.

We can also rock a closure to add advanced tools like a clone tool:

  var CloneTool = function() {
    var cloneX, cloneY, targetX, targetY;
    return {
      name: "Clone",
      hotkeys: ['C'],
      icon: imageDir + "clone.png",
      cursor: "url("+ imageDir +"clone.png) 0 0, default",
      mousedown: function(e) {
        if(e.shiftKey) {
          cloneX = this.x;
          cloneY = this.y;
        } else {
          targetX = this.x;
          targetY = this.y;
          var selection = this.canvas.getPixel(cloneX, cloneY);
          if(selection) {
      mouseenter: function(e) {
        var deltaX = this.x - targetX;
        var deltaY = this.y - targetY;
        var selection = this.canvas.getPixel(cloneX + deltaX, cloneY + deltaY);
        if(selection) {
  tools.clone = CloneTool();

The closure keeps track of the state of the tool with shared variables. This allows the source position to be set when shift is held and the mouse is clicked. Then remembered when the tool is used again at a distant location. Ideally we would also set some sort of marker on the source pixel so we can assist the user to see where we are cloning from. This can be done with setting some CSS properties on the pixels, but I will leave that for another day.

Let’s wrap this up with a heads up: there is going to be a contest to create the best tool for Pixie coming up, so it’s never too early to start preparing. The winning tools may even appear in the next version.

So until next time, stay pixelated.

Source on github.

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”.



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.


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.


  • 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);


  • “!”: “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.