Start Writing Your Blog

Do you have a website? Do you have a blog? I’d totally love to read it.

The thing is though, that it takes a while for it to get good. I started with STRd6 almost two years ago, and it’s still not good. On the plus side though it adds incentive to keep cranking out the content. Each new article adds a new layer of better content to cover up the old.

So what are you waiting for? If you want a really high class blog then you’ll definitely need to start today. I bet you even have some ideas for blog posts saved up. You could easily write four in the first month.

So go ahead and do it already. You don’t need to worry about being better than the blogs that are already out there, just as good as they were when they started. I’m not even going to link back to my early posts… too embarrassing. And only 20 posts in 2008? You can totally beat that.

Add your new blog in the comments. I’ll check it out in a few years when it’s good.

JavaScript Three Equals

Even though == is called the equality operator it is not an equivalence relation on the set of JavaScript objects. It fails to partition each object into exactly one disjoint subset. This is because in JavaScript the == operator lacks transitivity. Observe:

a = '';
b = 0;
c = '0';
a == b; // => true
b == c; // => true
a == c; // => false

The reason this is the case is that the == operator perform type coercion on the objects being operated on, usually converting them to strings. This can lead to subtle bugs in code, and JavaScript doesn’t always make the source of errors obvious. Tools like JSLint issue a warning if you use == to compare values with 0 or null because a lot of strange things may pass that comparison.

A good rule of thumb is to always use === when doing comparisons, especially when 0 or null is involved. It will save you lots of headaches.

3 == '3' // => true
// And to play us out...
false == [[[[[[[[[[['']]]]]]]]]]] // => true

New Version Of Pixie

Check out the recently released update of Pixie: The Online Pixel Editor. Still here and not checking it out yet? Then let me hit you with the new feature checklist:

  • Undo/Redo
  • Layers
  • Positioning with arrow keys (up, down, left, right)
  • Clone Stamp (shift click to choose clone source)
  • Larger Brush
  • Extensible Tool Architecture

Check out the code linked code samples if you are interested in creating your own tools. I don’t have a full tutorial present, but there are big secret plans in the works. Also, you’ll probably need the source if you want to develop your own tools; get it from github.

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…