Category Archives: Software

Install to ADB: installing packaged Firefox OS apps to USB connected phones (using ADB)

I abhor repetition, so I’m always looking for opportunities to improve my processes. Spending a bit of time early on can save you so much time on the long run!

If you’re trying to build something that can only run in devices (for example, apps that use WiFi direct), pushing updates gets boring really quickly: with WebIDE you have to select each USB device manually and then initiate the push.

So I decided I would optimise this because I wanted to focus on writing software, not clicking on dropdowns and etc.

And thus after a bit of research I can finally show install-to-adb:

In the video you can see how I’m pushing the same app to two Flame phones, both of them connected with USB to my laptop. The whole process is a node.js script (and a bunch of modules!).
Continue reading

webpack vs browserify

I saw a project yesterday that was built using webpack, and I started to wonder what makes webpack better than Browserify? The website didn’t really explain to me, so I asked in Twitter because I was sure there would be a bunch of webpack experts ready to tell me—and I wasn’t wrong! ;-)


Webpack comes with “batteries included” and preconfigured, so you get more “out of the box”, it’s easier to get started, and the default outputs are really decent. Whereas with browserify you need to choose the modules you want to use, and essentially assemble the whole thing together: it’s slower to learn, but way more configurable.
Continue reading

How to keep contributors when they are not even contributors yet

Today I wrote this post describing my difficulties in getting started with Ember.js, a quite well known open source project.

Normally, when I find small issues in an existing project, I try to help by sending a PR–some things are just faster to describe by coding them than by writing a bug report. But the case here was something that requires way more involvement than me filing a trivial bug. I tried to offer constructive feedback, and do that in as much detail as possible so that the authors could understand what happens in somebody else’s mind when they approach their project. From a usability and information design perspective, this is great information to have!

Shortly after, Tom Dale contacted me and thanked me for the feedback, and said they were working on improving all these aspects. That was great.

What is not great is when other people insta-ask you to send PRs or file bugs:

Look, I already gave you A FULL LIST OF BUGS in excruciating detail. At this stage my involvement with the project is timid and almost insignificant, but I cared enough to give you good actionable feedback instead of just declaring that your project sucks in a ranty tweet.

The way you handle these initial interactions is crucial as to whether someone decides to stay and get more engaged in your community, or run away from you as fast as they can.

A response like Tom’s is good. He recognises I have more things to do, but offers to listen to me if I have feedback after they fix these issues. I can’t be sure I will work more with Ember in the future, but now I might check it out from time to time. The potential is still there! Everyone’s happy.

An entitled response that doesn’t acknowledge the time I’ve already invested and demands even more time from me is definitely bad. Don’t do this. Ever. What you should do instead is act on my feedback. Go through it and file bugs for the issues I mentioned. Give me the bug numbers and I might even subscribe to them to stay in the loop. I might even offer more feedback! You might even need more input! Everyone wins!

This is the same approach I use when someone who might not necessarily be acquainted with Bugzilla or Firefox tells me they have an issue with Firefox. I don’t just straight tell them to “FILE A BUG… OR ELSE” (unless they’re my friends in which case, yes, go file a bug!).

What I do is try to lead by example: I gather as much information from them as I can, then file the bug, and send them the bug URL. Sometimes this also involves building a test case, or extracting a reduced test case from their own failing code. This is work, but it is work that pays off.

These reporters have gone off to build more tests and even file bugs by themselves later on, not only because they saw which steps to follow, but also because they felt respected and valued from the beginning.

So next time someone gives you feedback… think twice before answering with a “PATCHES WELCOME” sort of answer—you might be scaring contributors away! :-)

The bumpy road to learning Ember.js

I’m doing some interoperability research lately and one of the things I’m investigating is Ember.js.

I had never used it before, but heard raving comments about it, so I guess I was expecting a smooth paved way lined with flowers and what not… and what I found was a lot of mental dissonances and mismatches between what I expected to find and what Ember wants me to do.

In the interests of reproducibility, this was my way of “learning Ember.js”:

On Ember’s website

I went to Ember’s website and clicked on /about. It just highlights separate features but doesn’t show me a complete one-page kind of quick start snippet. It also is pointing me to download a JS file which is weird to me as I might have got (badly used) to be able to npm install modern JS packages / libraries using npm.

To npm

So I opened in a new tab and searched for ‘ember’. The results seem odd to me. The ember package seems to be legit, as it has Yehuda Katz as one of the maintainers, but it’s at version 1.0.0-pre2 and was last published two years ago. Well, that doesn’t seem very useful. It’s probably missing functionalities compared to whatever the current documentation in their website mention, yet still people are downloading it: 1104 downloads last week, which might have got a bunch of them confused like me too. So…

… back to Ember’s website

I go back to Ember’s website, and click on Guides. Maybe I will find everything there!

I am greeted with a 30 minute screencast.

I am not sure if I can skip it without missing something essential–perhaps a note saying that it’s OK to head straight to the “getting started” section would be nice. And users can always go back to it if they want.

In the end, I decided not to watch it, because as a non native English speaker I find videos where I can’t see the speaker’s lips really hard to follow—I’d rather just read text, as there’s no risk of misunderstandings.

So I click on getting started on the left.

Getting started

The guide wants to show you how to rebuild TodoMVC. I am not interested in learning that, but I want to know how to get a basic Ember structure up and running, so I skim over the first two steps: Planning and Creating a mockup and jump to the third step titled Obtaining Ember and dependencies.

It enumerates dependencies and then tells me to add four script tags before the end of the body tag.

This is not even “sole fighting Ember’s convention over configuration” yet—it’s me thinking “this is 2015. I should be able to require() away instead of embedding script tags on a file, and what kind of manual dependency management is this?”

Searching away

Of course I won’t accept defeat this easily. Someone must have figured this out already! This is not an obscure library that someone wrote in a basement, right? I search around using various combinations of terms:

  • npm ember
  • gulp ember
  • browserify ember
  • require ember
  • … and etc

The results of my searches are mostly fruitless–I only find half baked attempts that “work kind of OK” for the person that posted them, but seem really fragile according to commenters.

A compromise with gulp-bower

I don’t know what it is in Ember’s architecture that makes it not play nice with Browserify, but I don’t want to fix it myself.

I keep reading and find this other section titled Getting Ember. It links to the builds section which is a page from where you can download JS files (not what I want) but it also says that you can install Ember with Bower.

It’s not ideal, but it can be scripted, which makes it better than manually downloading JS files, so I decide to opt for an intermediate solution in which I will sort of cave in and use Bower, but via gulp, using gulp-bower.

Of course in order to use Bower you better know which dependencies and which versions of the dependencies to use, so you can build a bower.json file that Bower/gulp-bower can read to install packages.

Ember’s website suggests using this:

    "name": "your-app",
    "dependencies": {
        "ember": "~1.6",
        "ember-data": "~1.0.0-beta.8"

I believe this is outdated (Ember is at 1.10, the builds page say). I adjust it as best as I can and run my magic gulp-bower sorcery. The packages are downloaded as expected, and I can reference them in my html, with script tags.

But what to include…?

I start by adding bower_components/ember/ember.js. A message in the console invites me to include ember.debug.js instead, which I do. A bit after I find that I might indeed need jQuery (#sorrynotsorry for the pun). I also find that I need to include a template engine thanks to another error message. None of these were mentioned on the section that refers to using Bower.

I remember to go back to the Getting Started guide and look for the bunch of script tags that I need to include:

<script src="js/libs/jquery-1.11.2.min.js"></script>
<script src="js/libs/handlebars-v1.3.0.js"></script>
<script src="js/libs/ember.js"></script>
<script src="js/libs/ember-data.js"></script>

I manually add the missing libraries to bower.json, change the script tags to use the actual bower_components/ paths my app is using, guess which script file it actually to use, and hope for the best.


It works! I can finally follow the actual tutorials!

Which I do, yet even if I’m feeling weird that they invite you to stick things on the Window global object:

window.Todos = Ember.Application.create();

Later I get stuck on the Modeling data section. It mentions some DS object which I have no idea where it comes from–perhaps DataSomething? I don’t know. The API page doesn’t show any module starting with a D.

So I skip that and jump to playing with components and templates. I find how to do two way binding, which is nice, when it works, and it’s good to find cases in which things do not work because that’s the point of my research. I also see the potential in using the MVC archetype, and the API seems reasonably readable…

But at this point, I’m really tired.

All this going back and forth for satisfying the minimum requirements could have been solved from the start if Ember used a dependency manager.

People tell me in Twitter that Ember wants you to use ember-cli to solve all these issues. But I don’t want to use their CLI: I like using my existing tools. Also, perhaps Twitter should not be the right place to learn about this. If Ember wants their users to use the CLI, it should probably be in the documentation.

In 2015, again, I assume that JS developers are good developer-citizens (developzens?), and will make it easy to compose different pieces together without interfering with other people’s setups.

Yet Ember feels a bit like this weird assembly of pieces and techniques of years past, and that makes adopting it into your existing workflow way more complex than it should be.


With thanks to Brittany Storoz for proofreading this post and making it way, way better than it would have been otherwise.

Publishing a Firefox add-on without using

A couple of days ago Tom Dale published a post detailing the issues the Ember team are having with getting the Ember Inspector add-on reviewed and approved.

It left me wondering if there would not be any other way to publish add-ons on a different site. Knowing Mozilla, it would be very weird if add-ons were “hardcoded” and tied only and exclusively to a property.

So I asked. And I got answers. The answer is: yes, you can publish your add-on anywhere, and yes your add-on can get the benefit of automatic updates too. There are a couple of things you need to do, but it is entirely feasible.

First, you need to host your add-on using HTTPS or “all sorts of problems will happen”.

Second: the manifest inside the add-on must have a field pointing to an update file. This field is called the updateURL, and here’s an example from the very own Firefox OS simulator source code. Snippet for posterity:


You could have some sort of “template” file to generate the actual manifest at build time–you already have some build step that creates the xpi file for the add-on anyway, so it’s a matter of creating this little file.

And you also have to create the update.rdf file which is what the browser will be looking at somewhat periodically to see if there’s an update. Think of that as an RSS feed that the browser subscribes to ;-)

Here’s, again, an example of how an update.rdf file looks like, taken from one of the Firefox OS simulators:

<?xml version="1.0" encoding="utf-8"?>
<RDF xmlns="" xmlns:em="">
<Description about="">

And again this file could be generated at build time and perhaps checked in the repo along with the xpi file containing the add-on itself, and served using github pages which do allow serving https.

The Firefox OS simulators are a fine example of add-ons that you can install, get automatic updates for, and are not hosted in

Hope this helps.

Thanks to Ryan Stinnett and Alex Poirot for their information-rich answers to my questions–they made this post possible!