James Boelen
Software Developer
Bringing Thickbox Into The Present
May 11th
Yesterday I had to work with the Thickbox jquery plugin that has not been updated since 2007. Much to my dismay, the format and usage of the plugin was not what I’m used to or in the standard jQuery plugin form of $(element).plugin. Thickbox, in its original form, scours your page for special anchor tags and allows them to open a lightbox. The code that this was to be used in already had usage of this for links, but I wanted to add it to a table row, so I had to update the plugin without breaking existing functionality. What follows is a quick and dirty little snippet that can be dropped into the thickbox.js file to allow proper jQuery usage.
(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.
Nesting Files in Visual Studio
May 8th
Found a neat extension for Visual Studio that allows you to nest files in the solution explorer. NestIn written by José F. Romaniello, allows you to easily and quickly nest files from the context menu. I have found this very useful when grouping related resources to their parent files (like javascript to the parent user control).
Ice Cream Sandwich to Mac File Transfer
Apr 8th
So I recently updated my Samsung Galaxy S II and found that I could no longer connect it to my OSX Lion Mac. As it turns out, ICS now uses the MTP (Media Transfer Protocol) protocol which OSX does not support. Up until now, it has use the UMS (USB Mass Storage) protocol. Though this move is a step forward, it can be a bit confusing. Luckily, there’s a free fix from google. Android File Transfer is a free application that mac users can install to get MTP support on their Mac computer and continue to manage their files.
Android File Transfer is an application for Macintosh computers (running Mac OS X 10.5 or later) you can use to view and transfer files between your Mac and an Android device (running Android 3.0 or later).
Even though Android phones are a direct competitor to Apple’s iPhone, hopefully Apple will smarten up in the near future and build this in to their operating system. There are many other devices that use this protocol and to not include it would be plain silly.
Firefox Range Bug
Mar 13th
Today I came across an odd Firefox javascript bug. While trying to manipulate a range object, I ran into a wall that was preventing me from changing it a second time. On my page, I have a script that runs when a user selects text. I then delete the contents and replace it with the same text with a span tag around it. I noticed however, that if I brought up the range object again, it said it had no content. My syntax was simple:
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
Final Round – Fight!
Jan 9th
So I’ve been doing a bunch of processing tickets recently. Was able to complete tickets #1414, #1700, #1416, #1779, #1781. Thought I would have liked to have had a couple more completed, I feel like this was a pretty good chunk to accomplish. It’s funny, one of the first things I remember learning about open source is that you write one to throw away. This really struck true through this round of tickets as I often had to throw away my first idea of how to accomplish a ticket. This unfortunately made some last far longer than they should have, but I’m proud of the work that I submitted in the end. One thing I love to hate about doing some of these bug tickets is the sleuthing required to nail down the issue. Nothing gives me more pleasure than finding the cause of the bug and exterminating it. That being said, the process to find it makes me want to cry myself to sleep.
FSOSS 2011 – Tiki & Pi
Jan 9th
For my class in open source development, I was tasked with attending the Free Software and Open Source Symposium (FSOSS) conference in Toronto Canada, and reporting on 2 of the talks that I viewed. FSOSS is a collection of talks and workshops about new, upcoming, and current projects from members throughout the open technologies communities about how they are shaping the future of multimedia (including web, video and education), what projects they are currently working on, and other technologies.
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.
Adventures in Open Source
Dec 15th
For the past 4 months I have been working in open source development. My main focus was on Processing.js, but I also helped work on a firefox ticket to get mouselock in an working. This post will reflect on these past months, what I learnt, and how I’ve benefited from this time.
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.
That Holiday Rush
Dec 14th
Going to be working on some last minute Processing.js tickets today and a summary post of 4 months in the open source world so far. Look for more on those later today. I might even add some content to this post, who knows!
Frustrations in C minor
Nov 24th
Having been a coder for 12 years, I experienced something very new today. Often times, I have found myself working in code that I have never seen before. This usually happens when starting a new job, or even a new task at a job. When I started working on the firefox code the other day, I found something completely unanticipated. I couldn’t read the code. Now, saying that is a bit strong. Obviously, any programmer worth their weight in salt can read almost any new language or source code. But the paradigms I faced in the mozilla code were beyond completely foreign to me. It got pretty bad at one point where I questioned my own ability to code in cpp (something I have felt comfortable doing for a long time). It’s nice to know though, that my peers who are working on this with me and even my superiors have this issue at some point. Still, I dont like that feeling.
Mouselock for Firefox (Mac Edition)
Nov 17th
One of my tasks for the near future is to help get mouselock working in Firefox for mac. After seeing the code base and reading up on the objective, I’m ready to get this going. The style and paradigm of the mozilla firefox code is very new for me, and I’m excited to learn something new. Now that I have firefox compiling on my system, I’m ready to get going. To start, I’ll be building off the work started by my peers, R. Hung and D. Monteiro. They’ve both been laying down a lot of the ground work and got this project off to an awesome start. Since this is a group project, I’m hoping to now get my hands dirthy (read filthy) in the code and contribute a little something something.
I’ll be bloging my progress as I begin to get things rolling and throughout this evening (when I’m not distracted by reddit).
So without further ado, lets jump in!
