I then stumbled upon a stackoverflow question in which someone was having a similar issue.

Enter Visual Event 2. VE2 is an open source bookmarklet that, when loaded, will highlight all of the objects with events on a page and show you what scripts will be called when they are clicked. This thing is absolutely brilliant. I was instantly able to see what script was being called and found it in seconds. Better still, since it’s a bookmarklet, it should work in most modern browsers too!

This thing will permanently live in my developer toolbox. I highly suggest it for developers working on sites that are js intense.

Visual Event 2 Website

(function($){
  $.fn.thickbox = function( options ) {  
	  var settings = $.extend( {
		  'title' : '',
		  'href' : '',
		  'group' : false,
		}, options);
    return this.each(function() {
        if ($(this).hasClass('hasThickbox') == false) {
            var $elem = $(this);
            $elem.click(function () {
                var t = settings.title
                var a = settings.href;
                var g = settings.group;
                tb_show(t, a, g);
                this.blur();
                return false;
            });
            $elem.addClass('hasThickbox');
        }
    });
  };
})( jQuery );

I’ve kept it largely the same as it was in its original form so that others can easily see how it works and so that there aren’t too many modifications to the original logic. The function expects the options: Title, href, and group. All 3 work the same way as they did with the original plugin, and the options for Thickbox are still supplied as a query string through the href option value (see herefor an explanation of the query string options).

There are still many things that I’m not particularly fond of with Thickbox, but if you’re being forced to use it, this will at least provide you with a little bit less of a hassle.

range.deleteContents();
range.insertNode(newContents);

newContents was simply a span element with some text that I had created using the document.createElement method.

This code works exactly as expected in chrome. If I look into the range object, I  correctly have the new contents. In firefox however, the range object was missing all of its delicious contenty goodness. After doing a bit of re-working, I came up with the following solution:

range.deleteContents();
range.insertNode(newContents);
 
range = document.createRange();
range.selectNode(newContents);

The additional 2 lines make it work and it still functions properly in Chrome. Now when I bring up the range object, it has the new content for me to mess around with again.

Using firefox 10.0.2

The conference took place between October 27th and 29th of 2011 and the Seneca @ York and during that time I attended several of the talks, but the two that stood out for me was a presentation by Eben Upton on Raspberry Pi, a a new 25$ computer, and on by Neson Ko and Pascal St-Jean about TikiWiki, a robust and powerful wiki option for open source development.

For me, the main ideals that I hold for open technologies are access and collaboration. What I love most about open technologies is that anyone can use them. The traditional monetary obstacles that exist for software are not a problem because for the most part, it’s free. This puts everyone on the same playing field to use and learn about tools and methods for achieving their goals. If access is the heart of open technologies, collaboration is the soul. Seeing people from all over the world, come together and produce functional and high quality software is incredible. Not only do the solutions work, many of the people contributing to projects are doing it for free. In the busy world that we live in, it’s great to see people finding the time to help out and share with the global community.

Though I enjoyed all of the talks that I attended, the two aforementioned presentations stood out for me as I felt that they both hit home with the values I hold highest for open development.

“A Slice of Raspberry Pi” by Eben Upton was a fascinating talk about a new 25$ linux box. He noted that when he was a professor in computer science at Cambridge University, he found that the quality of applicants was steadily decreasing. Gone were the once adept students applying for entry, replaced by those with lackluster experience and little pre-existing knowledge of computer programming. Not only did applicants know less, they were dwindling in number. Though he and his colleagues had several ideas about why this was happening, they felt that their best efforts of helping curb this issue would be placed in trying to increase access to the hardware itself. Thus, the idea for Raspberry Pi was formed. A computer that was cheap and easy to produce that also had a decent amount of processing power.

What Raspberry Pi turned out to be holds a lot of potential. The hardware, about the same size as a credit card with the depth of about 1 inch, was able to run a full Linux distribution and even play HD video. It also boasted a somewhat powerful processor considering it’s size (similar to what is also being used in modern smartphones), ran at a low temperature, and required very little power.

With a small, lightweight computer that has a low initial cost and low upkeep costs, it opens a world of possibilities and creates a huge potential market. The current iteration of computers is quite expensive. With this technology, it opens the doors so that more computers are available in schools for students of all ages to learn on and use; enables those of lower income or underdeveloped countries to gain access to decent quality technology.

As I mentioned before, access is an integral pillar of open technology. Raspberry Pi has the potential to remove the monetary roadblock for a huge portion of the global population. This computer is a tenth of the cost of the tradition variety and could easily be bought or donated en masse to many different groups in need. In places with shared access, the number of available stations could increase so that individuals who want to use and learn more have the ability. Though the initial idea that started this project off may have been to increase enrollment at college and have more people interested with programming, the implications of this are far greater than merely that. The ever-expanding global village will be able to hugely benefit and allow access to many users that have never been able to enjoy the benefits of using a computer.

A lot of open development is focused on the software aspect and not nearly enough on the hardware aspect. Though there have been other efforts in creating accessible hardware for everyone, to the best of my knowledge, this is one of the cheapest options soon to be available. I can only image that this could have a big impact for the One Laptop Per Child mission. With even cheaper hardware, they would be able to donate even more laptops to underprivileged children throughout the world. With more access, kids and students will be able to have a hands-on approach to learning too. Instead of merely reading or seeing demonstrations, they themselves would be able to actively participate and hopefully gain an appreciation and interest of the hardware and software. Computer skills are necessary for almost any job. This technology will level the field for many, many people.

Philanthropic possibilities aside, this computer could even allow those with a general interest to explore subjects like hardware modification (since the unit is easily replaced) or distributed computing (as the units are cheap and can be bought in bulk). People will no longer need to use a specialized lab to learn and work with these paradigms.

Obviously there are other barriers to have nearly barrier free access to computers for everyone in the world. Hopefully though, this will start the ball rolling so that cheaply available computer systems (monitor, computer, peripherals) are easily available. Computers offer a huge advantage and affording everyone the opportunity to use and learn how to use and work with them will increase the quality of life around the globe.

“Tiki Wiki CMS Groupware – Software the Wiki Way” by Nelson Ko and Pascal St-Jean was an interesting presentation on the TikiWiki software and how their community functions. With 250 active developers, 1,000,000 lines of code and over 1000 features, they had to collaborate and work as a cohesive group. While there have been some negatives, the benefits of writing software in a wiki way have been far greater. Applying the wiki idea to creating software has ended up with one of the most successful open technologies for content management, wiki and groupware all in one product.

While the project does have certain priorities, it is mainly a “do-ocracy”. What this means is that you only have to work on the stuff you want to do or use. Much like a wiki, you can also edit or code on anything else that already exists. In many projects, there are owners to certain features. In the Tiki case, much like a wiki, anyone can edit anything and everyone can request access. Most of the people that are contributing are doing so because there is a need that they had and filled and wanted to share it back with the community. This is the main reason that they so many features. This methodology is manageable because all of the code is in one repository. With other systems that have thousands of features, the code is scattered and it’s hard to continue development on features that no longer have a developer. In the Tiki case, if a developer fails to maintain a feature that they created or if someone else wants to add some new sub features, they can do it on their own and not bother trying to request the original developer to do it or have to start their own completely new feature.

With so many people editing different parts of the code base, there needs to be a way to test to make sure that the features work properly and are bug free before the software is released. A process called “Dogfood” achieves this. The beauty of Tiki is that the contributors of the software are themselves using the software to contribute. This recursive system of software development means that any bugs or issues are quickly resolved and fixed. This also means that not only do you have end-users that can inform you of issues should they occur, but Tiki will themselves encounter the same issues because it is its own platform for development. This also increases the confidence that users have in the product because they are using it as a proof of concept.

I found this talk really interesting. Typically few people have access to the software repository when development occurs in the open source world. Normally, one person has access to the main repository and all code changes need to go through them (whether it’s patch files in Subversion or pull requests in Git). This successful shift in the fundamental way that the software is developed and how it grows is really amazing. With the wiki idea behind the development it also ensure that there is still accountability. While access to the repository is controlled, it’s still considerably open (considering 250 people have full read/write access). It’s also nice because no one has to wait for something to be fixed. If a developer fails to fix their code in a timely manner, someone else can do it. Sure this introduces other issues but for the most part it seems to have worked incredibly well for Tiki and many other projects could probably benefit from a similar system. I also found that Tiki using the software it’s developing to run itself very cool. It’s a very easy way to build confidence in the software when you can see the success that they’ve had. A lot of open technologies are built by people who use their own product, but have no real proof of concept to show others. Tiki is a huge stakeholder since it’s run off of its own software and has a development cycle that almost ensure that features will always have developers shows that it works incredibly well. The idea of having a collaborative effort akin to Wikipedia for building software would be a very hard sell, except that Tiki has already shown how well it works.

It’s hard to compare the two technologies because, for me, they both represent different parts of the open technologies community. Raspberry Pi deals with access and Tiki, collaboration. This being said, there are two things they are both doing extremely well. They are both challenging existing notions of how thing are or how they should be done and removing existing obstacles that were preventing people from achieving their goals.

Raspberry Pi is challenging the way that we thing about hardware and how access to it is controlled by large monetary blockades. What was once exclusively available to those who could afford it, can now be purchased by nearly anyone. Moreover, it allows institutions who allowed those who could not afford it, the ability to grant greater access by purchasing more units for the same amount of money. Places like libraries that only need computers to browse a catalogue, browse the Internet, or for simple word processing will find machines like this fantastic for this purpose.

Tiki on the other hand is challenging the way that we develop software in the open community. Until now, software has been typically developed in a way where very few people have write access to the code repository. Now we can see the great success that can be found in developing software the same way that Wikipedia built it’s gargantuan compendium of knowledge. It’s exciting to see the wiki method applied to software development because it has huge implications for future projects. As a developer, it’s interesting to see how the burden of effectively being a gatekeeper for a project can be lifted under the right circumstances. Volunteer open technology developers are almost exclusively made up of people who want to improve software. This completely removes the roadblocks that were preventing them from directly adding their contributions and completely opens open technology development.

I’m really glad that I attended these two talks. I love seeing existing notions challenged and shaken to the core. As a developer, these changes could prove to completely change the way we think about hardware and software. Both Tiki and Raspberry Pi are showing us that you can do things a new way and that nothing is set in stone. I’ve mentioned throughout this that my two central ideas in open technologies is providing access to as many people as possible, and collaborating to create something far greater than a single person could ever achieve. Both of these projects relate directly to that and I think it’s encouraging to see that developments are still being made to these central columns of what I think it means to be “open”.

I look forward to attending FSOSS again next year where I will hopefully get to see more about how the world of open technologies is being shaped and change. I enjoyed all the quality talks this year and encourage anyone else who enjoys and is active in open technologies to attend.

FSOSS

Tiki

Raspberry Pi

To start, lets return to the beginning. In September, I read a little article called “The Cathedral and the Bazaar” by Eric Raymond. Having been a developer in the past, I had always been of the Cathedral mind set. Planning out (usually as I went) and building from the ground up. I would create programs on my own at first, or eventually as part of a team in my first real jobs. Now, I won’t argue that my first “cathedrals” came out to something closer to an outhouse with no walls (read: hole in ground), but it was a learning process, and at the time, I thought it was beautiful (see image). Even now, once I’ve written something, until I have re-factored it, it looks like something I wrote after a bender. Things got better once I began working in teams. Seeing how others coded their solutions allowed me to think more critically about my own problems and how I would solve them using some of the more efficient and neat technique I had seen and now worked with. My personal code eventually took on the semblance of a quaint church that you might see over in the country side of whales; solid, functional, but still missing the beauty. When I produced code in teams, my alcove of the cathedral worked and functioned as part of the whole. Working off of some master architect’s blue prints, I was told what to do, and the time I had to do it. It was comfortable and I got used to it.

At the end of September, after learning all of the tools of the trade, I began to chip away at Processing.js. I set up my proverbial bazaar stall and began hawking my wares. People wanted my stuff! They liked it, they really liked it! That being said, they didn’t like the colour, shape, or smell of it. I gave it a new paint job, made it round instead of rectangular, and spritzed it with some eau du parfum. Now people were ready to take it home and use it! After my first patch was accepted from git hub, I was one happy camper! My work had paid off and I was well on my way. It was that easy. No one told me what to do or how to do it. They told me that it looked a little funky, but that’s because they wanted everything to look the same so that other developers, when stumbling across my code, wouldn’t curse me out. We all had bazaar stands and we were all friendly.

Firefox. As it turns out, processing.js was the shallow end of the pool. WIth a smaller base of coders working on it, it was easy to get things to work on and continue to get them put into the great machine. When I attempted to work on firefox with some of my peers, I found a harsh reality. People were going to do things wether you wanted to do them too or not. If you relaxed and got too comfortable (read: lazy), someone would come a long and beat you to the punch. No one was going to wait for you to do your part. My poor toes were getting stepped on! I eventually realized that, though in some bazaars everyone is happy and gives each other space, in others, other people are going to sell the same product, and if you weren’t on top of your game, they’d win out. It’s in this way, that progress is still made and the masses are given options. It’s a free market economy and if you aren’t providing the best, someone else will.

So. What did I take away? Here’s a list.

• Speed and Quality – Work quickly but be proud of what you produce. Being first isn’t everything; it’s gotta work too. Pumping out code as quickly as possible will result in failed peer reviews and halt your code from being included. Also, don’t dawdle or someone else will get there before you.
• It’s fun and rewarding! – Jumping in and adding code to something you’ve never worked on but have a vested interest in is fun! I got to improve things that I would use in the future. Cool programs that thousands or millions would also use. I can tell people that “Hey! I helped build that!”
• People are nice – Random people from all over the world were happy to help me with bugs and issues that I was having. If something wasn’t working as expected, I could ask for advice and pointers and those who would listen were more than happy to help me succeed.
• The bazaar style works – I was skeptical at first, but with enough regulation and rules (mainly with respect to appearance), everyone’s code works and melds together nicely!
• Collaborative efforts can existing within the same area  - I was amazed at how many people work working in parallel with each other on the mouse lock stuff for firefox. It was a beautiful mess of pull requests and branches.
• The bazaar is just as beautiful as the cathedral – They both function very differently, but both can achieve the same ends.
• People are passionate – If someone uses something everyday and has the drive to improve it for the community, they can in the open source community (and very easily no less!). This is one thing that the cathedral setting lacks.
• Passionate people work fast – If they enjoy and use something, they will find working on it invigorating, challenging, and fun. This drives them to work harder and longer on it.

At the end of the day, both are valid approaches – The open source way of doing things and the closed source way of doing things both work. They both are able to successfully build programs that are functional and are structurally sound. That being said, they both have their own valid approaches for various settings. Neither one is overall the best. They are just simply two methods to reach a goal.

As I move on, I hope to continue to improve and help out the processing community. I also plan on forking some new repos and sending a few pull requests.

I often find that when trying to learn a new code base, a bug that allows you to travel far and wide across the system, yet one simple enough to get that feeling of achievement, is the best approach.  With this, you get to see much of what you will be working with, and at the end, you should hopefully have something to show for your meander around.

“Once more unto the breach, dear friends, once more;” - William Shakespeare

Did you know that you are legally allowed to create a backup copy of Windows 7?  According to the Windows 7 Ultimate EULA

10. BACKUP COPY.

a. Media. If you acquired the software on a disc or other media, you may make one backup copy of the media. You may use it only to reinstall the software on the licensed computer.

b. Electronic Download. If you purchased and downloaded the software online, you may make one copy of the software on a disc or other media in order to install the software on a computer. You may also use it to reinstall the software on the licensed computer.

As far as I had known, copying the Windows 7 DVD was punishable only by death, but here we are learning that we need not fear personal body harm should we choose to do so!

But was this the only EULA I read my friends? No! I also perused the iTunes EULA. In section 2 of the iTunes EULA we find the following gem:

THE APPLE SOFTWARE IS NOT INTENDED FOR USE IN THE OPERATION
OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL SYSTEMS, LIFE SUPPORT MACHINES OR OTHER EQUIPMENT IN WHICH THE FAILURE OF
THE APPLE SOFTWARE COULD LEAD TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE.

I know others have mentioned this too (hear Richard Dreyfuss read some choice sections) but it’s still neat to see it for one’s self.

Today I’ve released the first version of what I’m calling the Processing Design Elements (a working title) on GitHub. Processing Design Elements is written in and for Processing and works in applications and on the web. Fundamentally, it’s a set of classes that enable easy creation of various form element controls like text boxes and buttons.

This current version is labeled 0.1 and is the first rough draft of what I hope to achieve by the end. The code is a bit messy and is lacking documentation, but it contains most of the ideas and concepts that I’m trying to implement. I hope that this collection will be able to help future developers easily retrieve user input and that someone finds this mildly interesting.

The current development plan is to work out some documentation and work on each of the different controls. The code is partially (read poorly) commented and I have not made any usage instructions outside of the test application that comes with the v0.1 release. I’m hoping to put documentation either in a wiki or make a website for it in the very near future. Ideally I’d like to refine and write the documentation for at least one control per week.

As I mentioned above, this is the first release. Though there is a lot I still need to get done for it, I’d greatly appreciate any comments or suggestions that people have. This is partially a learning experience for me and feedback will help me focus this project and get it to a point where other people find it useful.

Finally I’d like to thank the Processing team without whom, none of this would have been possible.

Demo Page
Git Hub Repository
Processing.org

There is a known bug with the textbox adding int values instead of character pressed.