Queue & Cyclic Queue visualization with ProcessingJS

Previous posts:


I finished refactoring the code and loading all the scripts using requireJS.
RequireJS not only helped modularize the code but it also helped me find/fix a few bugs.

I knew about modular script loaders by working with nodeJS and commonJS
However, I had never used a script loader on the client side, and after playing with requireJS I can’t see myself not using anymore.
One of my last projects we didn’t anticipate the amount of client side code we would need to write, thus not planning and design a proper architecture. The code was mostly composed by event handlers and some logic needed to determine the flow of the app. It tried to mimic the functionality provided by BackboneJS and SpineJS
With that being said, once the app grew the event handling code started to get bloated and hard to maintain and some logic ended up being repeated across files.
RequireJS more than anything forces you to think in a modular way when creating web apps, and that helps maintain and also scale the app while it grows.

Here is an overview of the structure so far

The Element object is the tile that is used by the processing canvas to represent an element of a data structure
Since the Element can be reused between different data structures, it doesn’t contains any logic regarding how it should behave. It just knows where to position itself and to animate its entry and exit from the canvas.
That worked so far since all three data structures are some what similar. However, the idea is to have an abstract Element and derive separate elements for each data structure/algorithm. This would give more flexibility to each element once more examples are added.

Entry Point

RequireJS allows you to create an entry point for the application, where you can initialize any objects you need.


  function () {

    // Init Stack
    var Stack = require("./stack/stack");
    var stack = new Stack();

    // Init Queue
    var Queue = require("./queue/queue");
    var queue = new Queue();

    // Init CyclicQueue
    var CyclicQueue = require("./cyclic-queue/cyclic-queue");
    var cyclicQueue = new CyclicQueue();

The first argument passed to require is a list of scripts to load before running the code.
The second argument is the code that will run once all the scripts specified in the first argument are loaded.

In the example above, the stack, queue and cyclic-queue scripts are loaded, then after their instantiation they are initialized.
All the logic of how they need to be initialized and how they will interact with the browser events are define within themselves, so to add a new data structure/algorithm the only thing that needs to be added to the main.js is the instantiation and initialization of the new object.
**An option for a future iteration is to create a factory to instantiate different objects, moving the responsibility of creating objects away from the main.js

Processing canvas

Since each example has its own canvas, a different instance of processing needs to be created.
However, not only the specific code for each example needs a reference to the processing canvas, but also the Element object, and right now all examples use the same Element.
The Element object wasn’t referencing the right instance of processingJS

Use requireJS to modularize the instantiation of the processingJS objects

So all the Elements will always reference the right canvas, and its code can be reused between the examples.
*A factory would probably be useful here to centralize the instantiation of the processing objects.

Some screen-shots:

You can find the code here and a live examples here

What’s Next?

There still a bunch of stuff to be done and improved.
The next iteration I plan to create a visualization for Hash Tables
I also want to refactor the code a little bit more and use factories to create processingJS canvas and to initialize the examples



DPS911 Summary

I wanted to do a quick summary of what I did this semester on the DPS911 course and what are my plans for the future.

First, I want to talk about Firefox.
Last semester I had the opportunity to get started with Firefox developemnt.
The first bug I worked on was the PointerLock. We started hacking PointerLock last November, and I’m really happy to say that after 6 months of hard work it finally landed and it’s expected to ship on firefox 14. Thanks for everybody involved on the bug, it was an awesome experience 🙂
** You can find more info about the whole process of the PointerLock implementation here.
Now that it’s over, I realize how unique was this opportunity, and that was one of the reasons I kept pursuing it until the end. I learned so much and met so many smart people during the process that I’m glad to have chosen this path, and if I could I would do everything again.

Besides working on PointerLock, this semester for the DPS911 course I found some other bugs to hack.
This is a list of all the bugs I was involved during the semester:

  • Bug 581863 – gtk2/nsWindow::GetScreenBounds returns client window size instead of outer (frame) size
  • Bug 581866 – outerWidth / outerHeight features in window.openDialog do not include window manager decorations
  • Bug 633602 – Implement Pointer Lock (Mouse Lock) API
  • Bug 712225 – When element is in fullscreen mode, window.innerHeight is bigger than window.outerHeight
  • Bug 715141 – Using keyboard to switch zoom level when viewing images directly
  • Bug 718133 – Remove keyboard shortcuts for zooming to 1:1 scale when viewing standalone images
  • Bug 713383 – Directly viewed images should be printed with a transparent background on the body
  • Bug 713608 – HTML5 Video controls are missing in Fullscreen
  • Bug 714071 – The Show Statistics setting is not preserved when toggling the full screen mode
  • Bug 728893 – Allow mochitest iframe to go fullscreen
  • Bug 724108 – Exception is thrown when showing statistics on a loading video
  • Bug 735031 – Fullscreen API implementation assumes an HTML Element
  • Bug 739874 – Input type “password” doesn’t receive Focus event with a mouse click

Status of the Bugs:

From the list above, the following bugs were landed:

I’m still working on bugs:

and I filed bugs:

Blog posts related to Firefox development:

Creating my first Firefox patch
Synthesizing mouse events in a mochitest
DPS911 Update
Firefox Bug 714071
Bug 713608 Update
Updating PointerLock API – Callbacks, Events and Threads
PointerLock API Updates
Bug 728893 – Allow mochitest iframe to go fullscreen
Bug 735031 – Fullscreen API implementation assumes an HTML Element


Besides working on Firefox bugs, I worked on a bug on the mongooseJS library:

Ticket #718 – Add multiple validators to a Schema field

I wrote about the bug fix here:
MongooseJs Validators – Contributing to an open source project

Some other projects I worked during the semester:
Simple Drawing Application with ProcessingJS, part I

Visualizing algorithms using Processing.js

Visualizing algorithms using Processing.js , part II

What’s next?

  • Finish the bugs I have started
  • Find more bugs
  • Keep hacking 🙂

One of the areas I want to get involved in Firefox is the SpiderMonkey Javascript engine
I also want to keep working on bugs related to the DOM and Events in general.

**Two readings that I really recommend:
History of Mozilla’s DOM bindings
New DOM bindings

Visualizing algorithms using Processing.js , part II

A quick update on the project:

So far I’ve created examples for

  • Stack
  • Queue
  • Cyclic Queue

Before I move on to other algorithms I started refactoring the existing code and reviewing the logic.
One of the tools I started to use was: requireJS
I refactor and restructured the stack example to load all its dependencies with requireJS.
The idea is to reuse some code between all the examples, and requireJS will definitely help on that

You can check a live example here
GitHub Repo
What’s next?

  • Refactor Queue and Cyclic Queue
  • Use requireJS to load files for Queue and Cyclic Queue
  • Blog 🙂

Next ->

DPS911 Reflections

The DPS911 course is coming to an end and now it’s time to reflect on the whole semester.

Personally, I couldn’t be happier with the results.
I learned several things during the process, and most important, I was able to apply them in other courses as well.
For example:

  • Git
  • GitHub
  • Mercurial
  • IRC
  • Bugzilla
  • Blog
  • Twitter
  • Javascript
  • OpenSource


After being introduced to GitHub last semester on the DPS901 class, I was able to apply that knowledge and use github to contribute to some projects and to use on personal projects as well


One of the things I always here is that schools don’t teach students how to use version control systems, and that usually turns out to be a problem when looking for a job. Well, I’m very fortunate to say that I had an awesome introduction to GIT on DPS901 that showed me not only how to use the tools in a technical perspective, but also how to use to organize a project and optimize the development time.


Since Mozilla uses mercurial as its version control software I had to quickly learn how to use the tool. It wasn’t easy, but applying the concepts I learned last semester with GIT and with the help of the Mozilla community I was able to get started.


I still remember a few years ago when I first went to Bugzilla searching for a bug  and being totally overwhelmed. First I couldn’t understand how Buzilla worked and second every bug that I looked could have been from another world as far as I knew. Everything seemed so hard, to be honest not only there was a lack of knowledge on my side, but also a lack of confidence  knowing that I could contribute to a huge project like Firefox. The funny part is that now, if I look at other bug trackers for big systems, such as chromium, eclipse, fedora, etc. I’m not afraid anymore, even though I might not know how the project works I have the confidence that I can just dive in and start contributing.


Before I took the DPS901 course, I thought javascript was a language that validated forms in a web page, little I knew about how powerful javascript really is. I couldn’t have asked for a better introduction to the real power of javscript.
Thanks to the introduction to javascript last semester, this semester I was able to apply that knowledge in several different projects.
A few tools I used this semester:

  • NodeJS
  • MongoDB
  • Jquery
  • ProcessingJS
  • Mongoose
  • Other Node modules and client side javascript libs.


This semester I had to put a lot of things into perspective, one of them was Blogging. Before DPS901 and DPS911 I never stopped to think that writing about the work I did was really important, and I can see from talking with my peers at Seneca that they also think the same. However, after listening to David Humphrey lectures I realized that it doesn’t matter what work you do, if you are not able to talk about it and present to other people it’s almost as if you didn’t do it. Now a days living in a society that have such powerful communication tools it is a must to take fully usage of them. It is really helpful to have a place where you can go and see the work you did in the past, when I look back to my first blog posts I can see what I was working at that time and even use that as a reference for some work I might be currently doing, Plus the fact that if you recorded a problem/solution that you’ve faced, it could also be helpful to other people that are facing the same problem. How many times you didn’t search for something and ended up finding the solution in a blog?


Another social tool I was introduced last semester was Twitter. Even though I still haven’t put in my routine to tweet about things, I use twitter regularly to see the work other people are doing and get in touch with the news around the world.
Twitter is an awesome tool that allows you not only to share with other people the work you’re doing, but also to keep updated with what is going on around you.
One of my goals for the summer is to become more active on twitter and start tweeting more often

Open source

In 2009, my first year in college I went to the FSOSS hold here at Seneca College. Since then, I knew I wanted to get involved with open source development. I’m a big believer in the open source way, and that it can be applied not only on software but in other parts of our society as well, but that’s a topic for another post.

One of the things that really made me happy this semester was to see open source in action in one of the projects I’m working on.
At the beginning of the project, one of the group members, a .NET developer was really skeptical about using NodeJS and MongoDB (both open source tools) in the project we were starting. After some good conversations he agreed and we dived into the challenge. During the way we had several road blocks, but every time we faced one I kept telling him that since all the tools we were using it were open source we could go and check the source code, and if we find a bug we could go and fix it, or change the code to do what we wanted, and that’s exactly what we DID!
The first project we contributed to was MongooseJS.
We faced a situation where we wanted to validate a Schema passing multiple validators during its initialization. However the library didn’t support that feature. We had two options in our hands:

  • Move on and find another way to do it
  • Add the feature we wanted to Mongoose.

We decided it was worth a try and opened a ticket on their repo on github: ticket
The we submitted a pull request with a possible fix: pull request
The solution was merged in their repo and now we and everybody else can use that feature 🙂

It was also good to see my brother in law building Firefox and starting to get involved with the project, and seeing some friends file bugs on Bugzilla and contribute to other open source projects.
Overall, I’m really happy to see more people understanding and getting involved in OpenSource projects.

To finish, I want to thank all my peers in the DPS911 course this semester, it was really inspiring to see the awesome work they did fixing bugs on Firefox and Popcorn.js

  • Abhishek Bhatnagar (abhatnagar1)
  • Christopher De Cairos (cadecairos)
  • David Seifried (dseif)
  • Matthew Schranz (mjschranz)
  • Mohammed Buttu (mbuttu)
  • Raymond Hung (rhung)
  • Scott Downe (scott)
  • Steven Ching Wei Tseng (Anachid)

And of course, a Big thanks to David Humphrey.
I couldn’t have asked for a better teacher and a better introduction to OpenSource and Firefox development.

Sincerely, Thanks for everybody, and lets keep hacking 🙂

Bug 735031 – Fullscreen API implementation assumes an HTML Element

Bug 735031 was to update the Firefox fullscreen implementation to allow SVG elements to receive fullscreen mode.

An overview of the relationship between DOM Elements

This is not a complete diagram, there are a bunch more elements inheriting from nsIDOMHTML/SVG/XULElement. However, It gives a nice visual representation showing that not all DOMElements are HTMLElements.


Only HTML Elements were allowed to receive fullscreen mode.
SVG Elements didn’t know about mozRequestFullScreen since the implementation was done only for HTML Elements

Requesting mozFullScreen on a SVG element would give this error:

TypeError: svgElement.mozRequestFullScreen is not a function

The IDL declarion for mozRequestFullScreen was on:

dom/interface/ html /nsIDOMHTMLElement.idl

And MozRequestFullScreen was implemented on:



The solution was to move the declaration of mozRequestFullScreen to:


And the definition:


Now both HTML and SVG elements can request fullscreen mode.



Since this fix had to change some IDLs, their UUID had to be updated. However, in this case, because the base IDL for all DOMElements was changed, the UUIDS for all the IDLs inheriting from nsIDOMElement had to be updated as well. The problem is that there are around 150 IDLs inheriting from nsIDOMElement, and to update each one by hand would have been CRAZY!
Luckly, somebody must have faced this problem before and created a script to update the UUID of IDLs and all its children.


To run the script:

update-uuids . nsIDOMElement nsIDOMDocument

The output:

  nsIDOMElement because it was given on command line
    f561753a-1d4f-40c1-b147-ea955fc6fd94 -> a652db92-f8d4-47e0-bf8f-1ad72e6c083f
  nsIDOMDocument because it was given on command line
    d7cdd08e-1bfd-4bc3-9742-d66586781ee2 -> ff3125e0-b1b5-467f-84ad-1d1eeafed595
  nsIDOMHTMLElement because it inherits from nsIDOMElement
    3de9f8c1-5d76-4d2e-b6b9-334c6eb0c113 -> 5b703ce7-e551-41fa-b465-ff94aa3bdc66
  nsIDOMXULElement because it inherits from nsIDOMElement
    5e0a7c2c-fdb6-459d-a67b-549181218c31 -> 42e74ec0-75c7-422c-b564-f853e3cbbb8b
  nsIDOMSVGElement because it inherits from nsIDOMElement
    dbb1b49c-dce5-43fe-97ea-e249b5620aa2 -> d2900917-e0ce-4eb8-aaf9-7e021d45472a
  nsIDOMXMLDocument because it inherits from nsIDOMDocument
    b53a4bab-0065-468b-810a-4c4659a04f00 -> b76ca016-46e8-4ee2-be3d-5b08b29afb72

Updated ./dom/interfaces/svg/nsIDOMSVGLineElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGStopElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGGElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGPatternElement.idl with 1 changes
Updated ./dom/interfaces/svg/nsIDOMSVGForeignObjectElem.idl with 1 changes
Originals are in *.idlbak