Back to the Map Block

Dec 2, 2014

A month ago I had decided to take on creating a map “block” for Mozilla’s Webmaker app. I have since made two other contributions to Webmaker app and shelved the Map brick for a later date due to it’s complexity and time constraints. I’ve decided to take upon the brick as it is one of the most requested features by users and intend to deliver the Map brick in a simple method in order to allow more additions to the brick later on.

I have written the changes I had made to my previous “leafbrick” branch overtop of the newest version of Webmaker app and created a new branch “mapblock”.

Further, my addition to the Gitbook for Webmaker App Web IDE development can now be viewed here.

Study: Compiling Mozilla Firefox

Nov 30, 2014


Compiling a web browser is not a task programmers typically think of doing unless they are writing changes to it and directly involved in the development of the browser. However, compiling a web browser can be a very educational and interesting experience in what technologies, processes, and code base size is involved in compiling browser builds.

In this case, I will be compiling Firefox on OSX 10.10 (Yosemite) and documenting my process as well as the resources I used to achieve it the compilation.

Typically wget is used to retrieve the development environment. However, with the introduction of OSX 10.10 wget was removed in favour of curl so it needs to be installed.

Therefore, the first step is to install wget by installing the Xcode command line tools. These tools are important for any developer using OSX and you may already have them installed try typing $ wget into terminal. If it is not yet installed, you will need Xcode which requires a developer account to download. In my case, I already had Xcode installed so I installed the command line tools via terminal with $ xcode-select --install.

Once the build environment is downloaded and installed, I downloaded the Firefox git repository. This repo has over a million objects and takes some time to download. I prefer using git, so I download it with $ git clone This repo is called “gecko-dev” because the engine Firefox uses is the gecko engine originally used by Netscape.


Once downloaded, using terminal I navigated to the location I cloned the repository to. From this point, mach is used to build Firefox. This process can take several hours. In my case on a 2009 Macbook Pro 2.66GHz/8GB took approximately two hours to build.




To build Firefox, run $ ./mach build

Once built, I received the below message. To run the build, the command ./mach run opened the nightly build.

This process, although not complex, highlighted the enormity of Firefox’s repository and build processes. Gecko has existed since 1997 and has a big community of contributors who are constantly adding code and tweaking existing code. These additions mean Firefox is only growing larger and while it uses the Gecko engine, the compilation process will only grow more complex.

Simple Firefox Build
Linux and MacOS Preparation

{less} Case Study: Why Less is Releasing CSS From it’s Cage

Nov 10, 2014

Authoring in traditional CSS3 feels like a lion trapped in a cage situation. Among many different extensive and useful programming languages available for web development, styling the web has consistently been a difficult if not often frustrating task. CSS is void of many popular, useful, and frankly logical code paradigms that we are already used to. Throughout three iterations CSS has remained largely a game of playing with inheritance and mind-numbing repetition.

Enter less.js which is now the standard for most popular web projects. Less is a CSS pre-processor that extends the CSS language by adding many common programming paradigms. Essentially, Less transforms CSS into the full-fledged language it should be.


Client vs. Server

Less can be run on both the client and server side. This is an incredible ability to have and is generally a new  concept to the programming world. However, Less on client-side is to be used with great care despite being the most common learning practice for programming using it. Putting the extra processing requirement on a client is not recommended, and using this method is best done in the development stage. Ensure native CSS files processed from .less files are used in the production copy of a project. In order to make this easy for production builds, you can include a Less step in task automation. Using a tool like Grunt to automate the processing is easy to do, and is now common place for developers.

However, for small projects or development you can include less.js within your header along with your .less files to unleash it’s potential quickly and easily.

If you’re not using {less}, you’re creating more work for yourself.

Added features include:

  • Variables
  • Mixins
  • Nested rules
  • Media query bubbling / Nested media queries
  • Operations
  • Functions
  • Namespaces and accessors
  • Scope
  • Comments
  • Importing

Simple Usage

In order to use less, you simply need the less.js file, and a javascript enabled environment. less files have the extension .less rather than .css and are referenced in the header.

To begin, include these lines in the head of your html file

<link rel=”stylesheet/less” type=”text/css” href=”style.less” />
<script src=”less.js”></script>

Now in your aptly-named style.less file, you can start to program using less.js

Variables are as simple as

 @variablename: value;

For example, within style.less to create a variable for the colour of my text within the element “textbox”:

@crazy-yellow: #FFFF66;
#textbox {
      color: @crazy-yellow;

When my page loads, It will look identical to writing

#textbox {
      color: #FFFF66;

The one of many features of adding a variable is extremely important. This can make an entire layout themable (changing the colours of the layout easily by variable overrides), can make authoring and tracking palettes simple, and in short will greatly reduce the amount of times you check for syntax mistakes.

This is just one implication of using less, and you can already see the benefit it has to both beginner designers as well as large projects. This is used in many popular projects like Webmaker, and Atom.

Less is open source and uses an Apache 2 license which means you are able to include it in personal, company (both internal and external), and commercial goods. Yes, you can even include it in your own package. The only caveat? You must attribute (and rightfully so). So what’s stopping you?

Do yourself a favour, give Less a try.

Find out more about less including docs.

Fork / Star / Contribute on Github.

Download the powerpoint to go along with this case study.

Guide on using Firefox WebIDE to develop Mobile Webmaker

Nov 3, 2014

I’ve created a guide in order to help contributors better test their code using Firefox WebIDE.

Firefox WebIDE debugger

Firefox WebIDE runs a Firefox OS emulator which can help when developing to simulate how the application would function on a Firefox OS device. It also includes debugging tools which are helpful to developers.

The guide includes links to install Firefox nightly, screenshots to follow along with, and specific tips on installing the mobile webmaker app.

I am still waiting on approval, but you can view the pull request here. It is written using markdown and is best viewed as such.


Thoughts on Keynote Speakers at Seneca’s Free Software and Open Source Symposium

Oct 28, 2014

On Friday October 24th I attended Seneca’s Free Software and Open Source Symposium. Bob Young and Chris Aniszczyk were two keynote speakers for the symposium. Both speakers are industry experts who provide a great deal of insight into the world of open source in successful businesses.


Red Hat Linux Creator – Bob Young

Friday’s first keynote speaker is Bob Young, founder of Red Hat Linux, which is now a 1.5 million dollar revenue Company that creates a distribution of the Linux operating system. His talk focused on the idea of open source, and it’s development from his perspective over the past 16 years. Mr. Young started by creating ACC Corp, which sold books and disks for Linux and realized the potential of the public domain and open source. After this venture, Young decided to create Red Hat and risk his children’s education funds in order to pursue his dreams of an open source based business.

Young discussed how previous to the GPL there was no such thing as public domain in software. Programmers would have their work traditionally copy written and allow people to use it. This promissory method of sharing software is risky as a business, as they could pull its free status, legally, at any moment and dismantle a business or project that uses the technology.

GPL and open source represents a bartering system. For example, if you contribute 1MB of code at a couple hundred thousands of dollars as was the case with the developer of some of Linux’s early network drivers, in return you receive a full operating system for free created by likeminded individuals. By sharing, we share not only the wealth, but also our knowledge by writing code. This is why open source is not altruistic per-se. You gain more than the work you put into it, it’s just not monetary.

Bob Young, although not exactly active in the community anymore, provides insight into the history of open source and the ideals of why it began. Bob represents the beginning of a movement, and an achievement that few can find. His speech was a history lesson, which helps us define purpose, and a lesson for staying mindful of open source’s humble beginnings.


Head of Open Source at Twitter – Chris Aniszczyk

Chris Aniszczyk is head of Twitter’s open source department. He previously worked with Red Hat and porting Eclipse to Red Hat Linux.

At Twitter, Aniszczyk has seen large movements in how Twitter handles its development. At Twitter, they started a movement to always consider open source options before “reinventing the wheel” and proving creating a new method will be more viable. This has lead to Twitter using a large amount of open source libraries. In order to handle the large amount of traffic that Twitter sees, it has been important to segment from a monorail schema and separate responsibilities while maximizing use of resources through open source means.

Aniszczyk’s keynote speech punctuated something Twitter is famous for: acquihires. Often companies that acquire a company for the talent forget about the companies code because the actual project is not needed for the company. Open sourcing code obtained through acquihires and having that discussion with the creators can keep it alive, which may be important in the future and help people.

In addition to this discussion, the importance in contributing to existing projects and compounded the ideal that you truly gain more from open source than what you put into it. Publically publishing features or fixes helps better the product for others and you gain the value of many more people contributing in a like-minded fashion.

Chris suggested following what he calls the “open source craft”:

  • Use Open
  • Assume Open
  • Define Secret Sauce
  • Measure Everything
  • Default Github
  • Default to Permissive
  • Acquire and Open
  • Pay it Forward

These points are a valuable checklist to approach open source development within a business.

The one interesting point that seems to be maligned is “defining the secret sauce”. In terms of Twitter, the secret sauce is its code base that is not revealed to the public. However, this is the point in which a business gains its advantage and is able to compete in the industry.



The two keynote speakers revolved around the lack of altruism around open source development and the idea of open source likened to a bartering system. However, this is actually a positive aspect of open source.

Contributing to a project or open sourcing your own project provides you with much more return than the time you spend on the project. This is an interesting view on the open source directive, as it’s commonly viewed as an altruistic venture that benefits others.

Young focused on the beginnings of open source development and how it led into the creation of Red Hat. Aniszczyk discussed the modern day applications of open source and allowed us into the world of how companies, in his case a very large company, views and utilizes the open source paradigm.



The most resonating message from the speakers was the realization that open source truly is a bartering system, but one where you often receive more than the value of what you contribute. Throughout my time developing software, I have always enjoyed the extensive amount of open source software and libraries available on the Internet. They have helped me learn and grow my programming skills. The benefits I have gained far outweigh the contributions I have made to the community, as is the case with most developer. But by continuing to contribute, I can continue to add more to the value of bartering in open source.

Further, Aniszczyk’s “open source craft” is a valuable checklist for beginning development on a project and I will be considering it in my future projects in order to best align them with a modern companies views on approaching the open source paradigm.

Release 0.2

Oct 16, 2014

For release 0.2 I completed Issue #308 for Mobile Webmaker which is an implementation of checking to determine if a username is taken while signing up. From my previous blog post, I have changed the functionality to check as a user types.

Screen Shot 2014-10-16 at 7.31.50 PM

This issue was solved by using Vue’s functionality for listening inside an html element. Using the v-on directive listening for a key-up I am able to trigger a javascript function which uses a function in the Webmaker Authentication Client in order to determine if a username is taken or not then I display the result to the user in a less robotic way.

The pull request can be found here.

I also worked on implementing a map brick, however that will involve much more time to complete and is therefore for another release. Currently, the map is displaying correctly but the architecture for how the map brick should be implemented needs further work.

Fixing Issue #308 on Mobile Webmaker

Oct 15, 2014

Another bug I am working on is issue #308 for Mobile Webmaker. This issue is to add functionality to the sign-up form so users can see before they submit if a username is taken. In order to detect changed content, I’ve used v-on=”changed: ” directive within the HTML element. Once focus is taken away from the element and a change has been made to the content of the input, a method is triggered to check the authorization server via POST.

Alternatively, this functionality can be easily changed to check upon each key pressed, but may put a larger load than necessary on the device and authentication server to process the many POST requests.

Ultimately, the server responds with if the name is taken or not. Implementation for how this response will be displayed is still to be determined.

To see the code, you can view the branch here and learn about the webmaker authentication client here. Additionally information on Vue directives, which drive Mobile Webmaker’s visuals, can be read here.

Leaflet.js Woes

Oct 10, 2014

In continuation with my last post, I been developing the Map Brick for Mobile Webmaker. In order to allow many different types of Maps to be used, I have begun integrating Mobile Webmaker with Leaflet.js which is a javascript library that allows for easy, interactive, mobile friendly maps. There is a Node Package Manager installation which I have used but there exists little documentation on it’s usage.

Integrating the existing Mobile Webmaker with Leaflet has been challenging. Getting the map to display properly is clearly a lack of proper implementation of the Leaflet CSS and JS so I’m working on find out how to properly implement it.

Currently I am using OpenStreetMaps and getting a very fun result (Firefox Nightly Build).

Screen Shot 2014-10-10 at 12.00.04 PM

I will update with progress once the maps are properly displaying to show you the amazing maps that Leaflet.js in combination with a map API produces. You can follow my progress on implementing Leaflet here.

Mozilla’s Webmaker App – Building the Map Brick

Oct 7, 2014

I have proposed and assigned myself the task of developing a map brick for Mozilla’s Webmaker App project. I proposed the idea in this issue on the Github page.

I intend to use Google Map’s API in order to serve the maps to the web site creator. The user will be able to select a location on the map to give the location as well as include an address. The personas for this application are varied: a business giving the location of the store, a group giving a meeting location, an adventurer providing a geocaching co-ordinate, a host giving attendees of their party their house address, and more.

The published view will give a map with a marker on the location indicated by the editor. On the editor side, there will be a map in order to let the editor select a location for the marker(center of the map will be put into the attributes long and lat of the map brick). Further, a string will be available to set the readable address for the location.

For potential barriers, an agreement will need to be made with Google in order to provide this API service to a more scalable audience. Further, the map may need to be cached in order to provide a lower load on the mobile devices being used.

If you have any questions, comments, ideas, or want to get involved for the development of this issue, please comment on the issue page on Github.

Release 0.1

Sep 26, 2014

I have forked the Filer repository from Github in order to contribute to the project. Filer is a library which allows you to manage a filesystem within your browser.

Du is a unix command that is used to estimate disk usage by a file or directory on Unix. I have taken the task of working on Filer to implement this shell function in order to have basic functionality and present the directory and file sizes in bytes. The version I have produced will give, for a specified directory, the size of files within it and the size of the directories within it without providing more information about files within the specific directory.

Working with an asynchronous programming approach is a concept I wasn’t yet versed in upon starting this task. I made a large use of the Node API, async README and of course Filer README. Throughout the development I learned a lot about the function nesting and using modularity to make code more readable in order to achieve my goal. An asynchronous functions do not halt other tasks, but instead will continue on to the next lines of code and run the function in the background. This is common in Javascript and especially Node. Further, making use of callbacks once the code has been completed is key to passing values from functions was a lot of get used to.

However, once I started programming and testing, I slowly learned best practices and the workflow. I started by learning from code from other already implemented such as and command and exploring both the implementation and the test cases. Development was largely based on a test-first approach where I would write a test for the command, then program accordingly. This allowed me to easily check if what I had written is correct.

Finally, Grunt was an eye opener. Grunt is a javascript task runner and by using it to run tests, I learned how easy it can be to develop using it. Grunt can automate tasks that developers often run endlessly like minification, compilation, linting, and unit testing. Combined with the test-first approach, it makes sure you’re actually working on the coding, and not the process of compiling everything.

You can check the status of my Du command in Filer in this pull request.