Adapting to browserify

Over the past few days I have been working on fixing a small issue on Filer for release 0.5 for my open source class. I decided to take something tiny due to other course commitments and so that I can work on more fun issues for subsequent releases.

The issue I was working on was related a to an incomplete code port we did for Filer when we switched from using RequireJS to Browserify. With browserify, we should be able to use simple node.js syntax and it will convert the code to work appropriately in the browser. Most of this was done a while ago. However, some remnants of RequireJS remained.

When we run tests for Filer, a feature that was implemented in the RequireJS days was the ability to provide via the query string, the Storage Provider to use for the tests. Obviously this is only possible in the browser. I wrote the code which does this so that we can use node’s URL module to extract the needed info. Unfortunately it did not work. After some deep investigation, I found that browserify was not changing `global` to `window` for the browser build. That seemed strange and I spent hours going through browserify documentation to figure out why.

Turns out I was being silly. I didn’t look carefully enough at the file. Turns out, it was still using RequireJS syntax and the module was being passed `global` as a parameter which referenced the module itself so browserify considered each reference to the global inside that module, as a reference to the parameter that was passed in.

In short, to fix my main problem, I had to change:

(function(global) {
  // code
})(this);

to just

// code

r.gideonthomas@gmail.com / March 30, 2015 / Open Source / 0 Comments

Venturing into new territories

For our release 0.4 in our open source class, we decided to keep it short and abstract as a consequence of our unfortunate but inevitable decision to abandon (at least for now) our pursuit of embedding XMP metadata into images in Android. The goal of this release – to come up with a plan for the next few releases we have left for this class.

The task was surprisingly not easy. I initially intended to find a Java project on Github that I could contribute to so as to expand my Github repertoire with respect to programming languages. My efforts seemed to be futile. I searched for almost 4 days to find projects in Java that I possibly could contribute to…however, I came across many issues – either the project did not encourage contributors (many didn’t even have a CONTRIBUTING.md file) or the project had only a few bugs left (all assigned to core project personnel) or the issues were too complicated to qualify for beginner (or even intermediate imho) bugs or the project was and Android project (just NO!). Granted, I had a double agenda of contributing to high profile projects by companies like Facebook, Twitter, Google, etc., but I didn’t think it was going to be this challenging.

In the end, I was able to find issues for 2 of my 3 releases so far. For my first release, I decided to play it safe and work on a Filer issue. I still need to get permission from a fellow coworker of mine (who is currently assigned to fix the issue) to steal it from him. For my next release, I decided to choose something that was even more cutting edge. I will be working on sweet.js, a library by Mozilla, another high profile company. Sweet.js is a javascript library that allows you to make use of macros, a new feature introduced in ECMAScript 6. I will be working on this issue that seems to indicate that there is a problem with operator precedence in macro substitution. I already have been given the green light to work on this 🙂

I still hope to find a Java project for my final release…hopefully it won’t be too hard. I might just ask around for suggestions which might lead me in the right direction!

r.gideonthomas@gmail.com / March 23, 2015 / Open Source / 0 Comments