Last week I published a post to the Addons blog announcing the 2013 Add-on SDK roadmap. I sweated over it for a few days, finally pushed the publish button in Wordpress on Tuesday afternoon, then waited for it to pop up on PMO.

…and waited.

…and waited.

After some investigation I found this bug from last September logged by my fellow AMO blogger Jorge Villalobos: Bug 790033 - Mozilla Add-ons Blog missing from Planet

Clearly I completely missed the boat on when the move of the addons blog off of PMO happened, and that’s a bit embarrassing. I’m also a little disappointed because I feel like we’ve lost something for the Addons blog by not being aggregated on PMO. I think for even the brief few seconds when PMO readers scan the posts, there is a value to having our posts in there and visible - that there is an ambient awareness created in the community about what we’re doing even if you don’t read every post.

Anyway, this all happened months ago so there is nothing to be done except to say, if you feel like you’ve been missing out on the state of add-ons at Mozilla, please either subscribe directly to our feed, or optionally to the PMO projects sub-feed. This projects feed is particularly convenient if you care about other things like the Webdev blog, Hacks, Bonjour Mozilla, etc.

I should mention as an aside that I’m betting this realization about PMO will change my blogging habits, and I expect I’ll be using this blog for more work-related posts from now on if what I’m writing about is intended for the PMO audience. I guess the upside of that is I’ll end up blogging more, without even having made a NY resolution for that. I suppose that means I should look into enabling comments as well.

Based on the advice of a friend I upgraded 3 laptops to Mountain Lion last night. Once I downloaded the installer and restored the ESD to a USB key, everything really smoothly. I only have 1 major compatibility issue - my Focusrite VRM box is not yet supported.

I of course spent a goodly amount of time poking around the new OS ( as you do… ). I was particularly interested to see how notification center works. Notifications on OS X have been a cluster… er, not ideal for a long time, depending on the possible presence of 3rd part app Growl to work at all. In the Jetpack apis we currently fail hard and silent on OS X when Growl isn’t installed, so add-on developers really can’t rely notifications working and develop add-on features around them. There are some workarounds, but the whole thing is a bit ugly and hacky.

If you are running Firefox on 10.8, any notifications will be sent to Notification Center instead of Growl even if Growl is present and running. For add-ons that use Jetpack’s apis, this makes things 33% worse, as there are now 3 behaviours that could occur when notify is called:

• if OS X is < 10.8 and Growl isn’t installed, the notification is printed to the JS log.
• if OS X is < 10.8 and Growl is installed, we see Growl which, give how configurable Growl is, could mean almost anything.
• on 10.8 notifications from Firefox are handled by Notification Center, which only displays a notification on-screen if Firefox isn’t focused.

This is a mess. Add-on developers ( and html5 app developers! ) need a reliable, predictable way to show the user notifications that work consistently across platforms. The behaviour needs to be both helpful but also unobtrusive for users, with the right balance of features. In my mind the essential requirements are:

• if the user allows notifications, display notifications regardless of whether the app ( Firefox ) is focused or not. If I have written a chat application, for example, I’d love to be able to get the user’s attention if the tab my app is loaded into isn’t visiable, regardless of OS-level application visibility.
• provide a decent api for notification ‘flair’ - images, titles and text feel essential to me. For example, if I my chat app displaying notifications, it would be great to show the avatar image of the user sending the message that the notification was triggered by.
• provide a way for the app or add-on to react to the click event by accepting a callback - again with my chat app, clicking the notification should be able to change focus to the window and tab where the notification originated from.
• notifications should disappear after $some_low_number of seconds if there is no user action.

Frustratingly, Notifications on OS X fail in all of these cases:

• notifications aren’t visible at all if Firefox is focused - they ust get stacked up in the Notifications UI with no visible indicator that anything has happened.
• there is now way to use a custom image in a notification.
• we don’t fire the onClick handler for the notification, because clicking on the notification bubble only focuses the notifying app.

The most important use case I see is that any add-on or any app running in any tab should be able to request the ability to display notifications, and those notifications should be able to trigger a callback so that the developer can react to the click. The real-time web is upon us and I see this notification gap as being a real drag on what developers can do with social communications using WebSockets. Apple’s solution simply isn’t webby enough to help.

I am cautiously optimistic that a Mozilla implementation of the w3c notifications spec. I’m a bit worried though, as the feeling seems to be that if an OS implements notifications we should always use that instead of a generic implementation. Notification center is too weird and limited to really be useful, so I would argue against using it. For Jetpack in particular, my preference would be to use our implementation regardless of OS version so we can provide add-on developers with a reasonable feature set they can rely on.

Last week/end I was fortunate to be able to travel to Berlin and attend JSConf EU 2012 and it’s sibling conference, Reject.JS. To say I had a great time is a huge understatement. JSConf events ( I’ve only beem to the European variant, but I assume this applies to other flavours as well ) are intense, informative, challenging, expensive, even exclusive to a certain degree, but above all they’re fun. Sure, the cost is formidable, but it is clear to see that all of the tickets sales and sponsorship funds go into the production. As somone who has occasionally organized tech events, the level of production value is pretty astonishing!

I could wax poetic for this entire post about how well run JSConf was, but there is nothing really new to report - it was just as well run last year ( although I forget if last year had the frozen yoghurt truck ). The truly great innovation this year was hosting the B track in an inflatable transparent plastic bubble out in the courtyard:

JSConf is fun, but it’s also a conference for programmers; this year’s edition had an incredibly wide scope. Starting with RejectJS and then continueing through the weekend, we saw JS powering all manner of things:

• a strongly typed, class-based JS superset, from Microsoft.
• an AR Drone that charged at red flags like a bull at a Matador
• any number of other sorts of robots and gadgets.
• a guitar pedal implemented in a browser, distorting live input from a real electric guitar!
• a programming language intended for children, but tested on aging parents

Watching these talks I really got this sense of JS spreading at break-neck speed in all possible directions at once. Binary data? Check. Transpiling? Old news, sucka. Robots? Of course! And underlying it all, a burgeoning community that loves JS as it is - with a very bright future ahead of us.

I’m sitting at the airport, feeling like I’ve put in an entire week of work in two days. This is Mozcamp, I’ve come to realize - all the energy, the great conversations, re-connecting with friends & colleagues from all over the project and the world. It’s amazing once you’re there, and then you collapse from exhaustion once you’re out of it.

For those that didn’t make my talk due to some dubious excuse ( bwinton, lmandel, I’m look over in your direction ) here are the minimal slides I used:

https://dl.dropbox.com/u/44296964/addons-navbar-mozcamp/index.html

( They’re on github as well. ).

These slide are just background though - you can get the gist but I think I’ll need to make a more complete blog post about the Jetpack team’s work on improving Firefox UX for add-ons in a subsequent post, once I get back from a week & a bit of vacation. Unfortunately, I know it wasn’t recorded because I had to unplug the mic at the beginning toget rid of some space-dub echo effect coming from the back of the room.

To sum up Mozcamp itself, it’s just amazing to me how much energy there is over here in Europe, and I was again impressed not just by the big communities like our Polish hosts, Mozilla Hispano, etc, but also by tiny contingents of people from places like Estonia or Latvia, or very new communities like Tunisia and Kenya. It also really feels like a lot of progress has been made since just last November and Berlin, and I think the MozReps program and all the hard work being done by staff and reps is really paying off.

More than that, Warsaw is the farthest east I’ve ever travelled ( until you hit Asia ) and it was humbling and impressive at the same time. I saw what I think of as three distinct Warsaws: the shining new towers and bustling city life in the center, the blocky and imposing Soviet-era buildings that are being renewed and repurposed by Poland’s economy, and hints and shreds of what remains from before 1945.

While I didn’t directly discuss this with any Poles, I did read up on some of the history and am a bit floored, at first by the horrifying tragedy, but also by the Poland I saw right in front of me, revitalized, full of web hackers, inventing the future alongside the rest of us. It’s really hard to connect these threads together, and a credit to the people of Poland that they’re thriving just 25 years after the Warsaw Pact unravelled. I’d really like to return some time when I have more than 72 hours to spend!

This past week the Jetpack team gathered at Mozilla’s brilliant new offices on St. Martin’s Lane in London for a much needed work week. It’s been a great week so far, and we’ve gotten a lot done in terms of both high-level discussions on the direction of the project as well as actual code.

Why was this week necessary? For starters, the Jetpack team is one of the more distributed teams in Mozilla, with team members spread from California and the west coast of Canada to Hungary. In particular, there is no city or Mozilla office in the world with more than 2 members - we’re spread out! If you also take into account that there are just a few hours of the day when the entire team is awake and working, it becomes even more critical that we gather periodically and work together in the same room.

Another reason why we needed to get together and sync up is that the Jetpack project is at an inflection point, as we are currently working on three key goals:

1. The first goal is to finish our work to offer complete support in the SDK for Firefox on Android. While not all SDK apis make sense to support on mobile, it should be possible to create SDK-based mobile add-ons easily, and also create add-ons that target both desktop and mobile. The tracking bug for this work is bug 787718.
2. The second goal is that we are actively working on landing add-ons user experience improvements in Firefox that we think will dramatically improve the ability for add-ons to integrate easily with the Desktop Firefox UI. You can follow this work by subscribing to bug 695913.
3. Finally and perhaps most importantly, we continue to execute on our plan to land the SDK apis in Firefox. If you’re interested in tracking this work, the tracking bug is bug 731779. This move will have several positive impacts:
   • developers will no longer have to re-pack add-ons to maintain compatibility with newer Firefox versions.
   • SDK api implementations will only need to target a specific version of Firefox - our work to support multiple Firefox versions currently complicates our code in places.
   • Add-on developers and Firefox developers will be able to use the SDK’s apis with confidence, knowing these apis will be stable and included in Firefox itself.

We talked a lot about these three goals during the week and are currently planning how we work with the rest of the Firefox team to achieve them in the right order and with help from key Mozillians so that we have the best chance for success for each goal, one goal at a time.

Another big change is that our current Product Manger David Mason is moving on to greater responsibilities working with the Mozilla platform team. I’m very pleased to have the opportunity to step into this role in his place, but I know I speak for everyone on the team that we will all miss Dave’s prescence in the project and that we are all grateful for all of Dave and Myk’s hard work building the Jetpack team over the last couple of years.

During the week we also got a lot of code written, tested and reviewed, in fact we closed 16 SDK bugs including 7 P1 bugs. Some specific achievements included:

• thanks to Eddy, direct proxies are now in Firefox; this new platform capability will make a lot of Jetpack’s code simpler and more performant because we currently use content proxies extensively.
• Eddy also gave an excellent talk on Spidermonkey internals and how they work, including performance tips! Everyone thought this was really interesting ( and at times terrifying ).
• Alex implemented preference localization, landed some dramatic PageMod improvements, and fixed some leaks in url.js.
• Eric completed and has almost landed tabs api support for Firefox on Android.
• Irakli investigated implementing an asynchronous file access api, a module for registering chrome uris in SDK add-ons, IndexedDB support, and also continued work on restructuring the SDK’s modules into the packageless layout we need in order to land in Firefox.
• Matteo made great progress on implementing changes to Firefox’s navigation toolbar to support the navigation capabilities we are working on, and also landed module metadata to indicated module stability access.
• Gabor landed support for expanded principals, and made progress on a new platform method to apply dynamic css changes to docuemnts.
• Irakli, Will & I hashed out an approach to how we deprecate older low-level apis and introduce news ones, including how we indicate in documentation or via a module’s behaviour whether it is experimental, supported or deprecated. This is critical as we continue to improve how the SDK is implemented, especially when other developers are using these lower-level modules.
• Dave Townsend, Wes & I dug into bug lists and infrastructure issues, working to make sure that we’re communicating well with the resources in Mozilla we need to get our work done.
• Dave Mason helped me lead a brain-storming session with the team in a side-project to come up with dramatically different / advanced add-on concepts. More on that later.
• I’m sure I forgot some stuff!

Stepping back I’m amazed at all the work we’ve been doing, and particularly excited about the three key goals I mentioned earlier. It is my belief that a year from now we will look back on these goals and see that they were a turning point not just for the Jetpack project, but for the notion of extensibility in Firefox in general. The Jetpack team is the team at Mozilla that works exclusively on Firefox extensibility; as Dave Townsend reminded us this week this means we must always be thinking about how to improve the add-on experience for Firefox users and add-on developers.

My gaia-rocking tool has been an interesting project, but also somewhat frustrating. Gaia is currently undergoing a high rate of change, and until recently QA at Mozilla was not testing the combination of B2G desktop builds ( which are a very recent thing ) and Gaia.

This culminated in my attempts to get people going with app development using my system to test with at an apps hack day at FISL 13 in Brazil. Not surprisingly, the 3 main challenges I encountered were:

1. the latest revision of Gaia did not work at all with the current desktop build. To fix this I temporarily fixed both versions at a level that ( mostly ) worked.
2. Gaia’s github repo is gigantic, and we were on a slow connection.
3. Gaia unfortunately has a dependency on xulrunner and xulrunner-sdk, and the latter is a rather large download that occurs when make is run for the first time.

The last two problems we mostly mitigated through the judicious use of USB keys. We also ran into Linux distro compatibility issues, and I was reminded once again that writing software on OS X and expecting it to ‘just work’ elsewhere is a fool’s errand. I think I need to work more on Windows and/or Linux so I can feel the unique pains of those platforms.

After returning from Brazil, I’ve participated in a few email threads about an effort to make this all a lot easier to use. There are two distinct use cases:

1. Apps developers should have some easy way of creating an app and then running B2G desktop to test it.

2. The Gaia project itself needs a way to make sure that the latest stuff works with the other latest stuff, without necessarily having to muck about with a phone.

You’d think these two aims would be aligned closely, but I’ve come to realize that they are not. Apps developers should have a small-as-possible download of B2G and Gaia that ‘Just Works™’ and includes a simple workflow for testing their own apps. The Gaia team wants the latest of everything, including ALL THE BROKEN THINGS.

Today I pushed some updates to Gaia-rocking that fix things for the Gaia team use case. As it happens in the current state it is also not a bad way to create and test apps, but there are no gurantees that this will stay the same. There is now daily smoke tests of gaia with the dekstop app though, so when things break they will be reported and fixed sooner.

As a slight nod to any apps developers using this, I also added support in the Makefile to create your own local.mk that can contain an override for the location of the Gaia source directory. So this alternate directory could be anywhere, and might contain a known-working version or your own development fork. If I were going to go about hacking on an app, here is what I would do:

1
2
3
4
5
6
7
8
9
10
11
12

1. grab my own Gaia directory with a specific revision:
curl -o gaia.zip https://github.com/mozilla-b2g/gaia/zipball/master
// ...or whatever revision you want

2. unzip gaia, create a 'my_apps' subdirectory, then copy the template app into the my_apps subdirectory:
unzip gaia.zip && cd mozilla-b2g-gaia-* && mkdir my_apps && cp -r ./test_apps/template ./my_apps/appname

3. create local.mk in the gaia directory so that the Gaia make command includes your apps:
echo 'GAIA_APP_SRCDIRS?=apps test_apps showcase_apps my_apps' > ./local.mk

4. in the gaia-rocking directory, also create a local.mk file that sets the Gaia source directory to wherever you unzipped your Gaia from
echo 'GAIA_SRC=/path/to/new/gaia/directory'

This should get you set up to run B2G Desktop with Gaia in a custom directory, and load your new app into the appcache along with the rest of Gaia’s apps:

This is too many steps, I agree. But, once this setup is done, all you need to do is hack one your app and run ‘make run’ in the gaia-rocking directory to test in the Gaia environment.

Click on the image to view some more photos.

I just got back from 2 weeks in Brazil and wanted to share some of my mistakes & observations in the hope that you, my fellow Mozillians will learn from my foolishness. Most of this info has to do specifically with booking flights and other sorts of transport so if you’re looking for a crazy Sao Paulo bar-hopping story, it ain’t here.

Booking flights ( for Canadians )

The good news for Canadian Mozillians is that there is a direct, daily flight from Toronto to Sao Paulo - AC 090 / 091. You should be aware this flight is a code-share with TAM and seems to be difficult to book via Egencia as an AC flight unless you book well in advance.

Booking as a TAM flight instead introduces various problems:

• you cannot do seat selection via AC or Egencia
• you cannot apply for upgrades until you check in at the Airport
• this flight is on a Boeing 767 ( http://is.gd/JsjNEp )
• other legs of the flight ( Toronto -> Vancouver ) were booked as Tango class, and could not be upgraded.

Lesson: code-shares are evil! Book early! Be flexible on dates!

Cautionary note: on the return flight I was not able to upgrade, but was assured that I had a ‘really good seat in an exit row’. The seat they had assigned me to was, instead, the worst airline seat I’ve ever gotten. Row 18 on a 767 is exit row, sure, but the seat does not recline, does not seem to have appreciably more legroom, and is right next to the galley. I got zero sleep, and had the added bonus of being able to smell all the wonderful food being served for dinner in 1st class as it was being prepared.

Lesson: Always check seatguru.com!

If I was to do this all over again, I should have tried juggling my travel dates to get the AC flight instead of accepting egencia’s TAM code-share.

Cash

You will need some cash! But not too much! There are a number of bank machines near the outside doors at arrivals in Guarulhos, including an HSBC ATM that worked well for me. Get 100BRL to start, and try not to carry too much at any one time.

Transport to the city

There is a pre-paid voucher you can get from a kiosk near the arrivals door - use this, and get in one of the white cabs queued nearby. Make sure that between you, the kiosk people and the dirver there is a good shared understanding of where your hotel is. Sao Paulo is huge and there can be several hotels for a given hotel chain.

Sim cards

The Vivo SIM card I used in Brazil worked quite well, all things considered. Internet access in generl in Brazil is slower than you’re used to, but it can be incredibly useful to have access to google maps on a smart phone, provided you’re careful about public phone use. Which leads me to…

Phones

People routinely get mugged in Sao Paulo for their mobile phones, which are probably much cheaper and crappier than the Galaxy Nexus or SII you’re carrying around. Don’t take out your phone in public unless necessary, and be very aware of your surroundings. While I was in Brazil, Mozillian Luca Toledo was mugged and had her phone stolen in Guarulhos Airport!

Transport around the city

We took a ton of taxi rides, sometimes for fairly short distances. We were cautioned by local contacts to do this to ensure our safety, and we were unwilling to take chances even though the area around our hotel felt very affluent. The taxis we rode in all preferred cash, often drove insanely fast, and universally were fuelled with natural gas tanks. Personally, the constant faint smell of natural gas exhaust made me quite naseous on longer rides!

Mozilla Brazil community!

I cannot overstate how great it is and how much easier this past trip was on me because I was able to rely on the help and guidance of Mozillians in Brazil. All of our community members were great, but I’d like to particularly call out Luca Toledo, Fabio Magnoni, Sergio Oliveira, and Clauber Stipkovic for all the help, translation, mascot-wearing, introductions, insights and inspiring passion. I was reminded yet again how fortunate I are to be a part of the Mozilla project - we have this unique force multiplier that makes anything we do in a place like Brazil not just easier, but more effective as well. Moz BR rocks!

Last Thursday we staged a hugely successful Apps Hack Day in the Mozilla room at FISL 13. Was it well attended? We had a massive line-up at 10AM and had to expand to an extra room! Was it well-recieved? Definitely, yes. FISL attracts FOSS enthusiasts from all over Brazil ( and especially students ) and the interest in Mozilla in general and Firefox OS in particular is very, very high.

As usual, we started out with a few quick talks to get people up to speed, and then spent the rest of the day helping out and answering questions. My Portuguese is non-existent, so I was very happy that we had Mozillians Fabio Magnoni ( from the Brazilian community ) and Artur Adib ( labs engineer ) to give talks in Portuguese. I gave a quick lightning talk in English on how to run B2G desktop to test html5 apps in Firefox OS’ environment.

Here’s the video:

Here are the notes from my lightning talk:

# Testing HTML5 Apps on B2G Desktop
    -> Jeff Griffiths, Mozilla

Online: https://etherpad.mozilla.org/jeffg-gaia-desktop-hacking
    1. get desktop build
        -> http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/
    2. get gaia
        -> https://github.com/mozilla-b2g/gaia **
        -> make # run make once to trigger the xulrunner download
        -> git checkout -b working 07edca0 # a working revision of gaia
    3. create local.mk
        -> add 'GAIA_APP_SRCDIRS?=apps test_apps showcase_apps my_apps'
    4. create 'my_apps' directory
    5. cp -r test_apps/template ./my_apps/
    7. mv my_apps/template my_apps/$some_cool_name
    6. HACK!!
    7. TEST!!

Resources:

    1. Linux: http://informationisart.com/11/
    2. Windows: https://github.com/sihorton/b2g-desktop-profile-installer/
    3. Mac: https://github.com/canuckistani/gaia-rocking
    4. https://developer.mozilla.org/en/Apps 
    5. twitter: @mozhacks @canuckistani

One thing that has become very apparent to me while working on gaia-rocking, preparing for this talk, and trying to get people going with B2G Desktop during the rest of the day is that the experience can be very rough. The B2G and Gaia teams are focused on one thing only right now, and that is shipping basecamp. This means that Gaia changes all the time, and B2G desktop is not yet well-tested.

Through various conversations with Dietrich and other team members though, I expect this to change and I am hopeful that once the hurricane of basecamp passes we’ll see all sorts of cool ideas come to fruition, including better use of Firefox’s devtools, and easier set-up of Gaia and desktop builds.

[[UPDATE: if you have trouble running Gaia with this tool ( or, at all ), you may need to run using ‘sudo’.]]

A week or so ago Hernan Colmeiro blogged about using B2G Desktop to run Gaia on a desktop computer, amongst other things. Running Gaia in this way is compelling as a way to test & preview apps in the Gaia environment: you get the correct display size as well as the correct app launch & dismissal behaviour.

But… it is a little awkward to get going. instructions for manually setting this up are of course on the wiki, but there is still a lot of setup and implied foreknowledge about terminals, etc. I created the gaia-rocking repo to help this ( and Hernan kindly linked to it! ) but gaia-rocking doesn’t quite rock, and currently it doesn’t rock at all on Linux or Windows. It needs help!

A short list of things I need to do this week:

• Windows and Linux support. Just running on Macs is clearly not good enough.
• some way of easily pushing a single app into Gaia for testing
• maybe an embedded web server that serves up apps the right way? Sort of Marketplace-lite.
• Mortar integration ( unsure completely what that means… )
• I’m thinking of porting the Makefile to coffeescript, just for fun.

Pull requests welcome!

I posted recently about the sudden move over to Octopress. The slightly frustrating thing about using Octopress is the ruby angle, at least in the sense that it took a while to get a workable install going. This is probably mostly my fault, somewhat Apple’s fault, and maybe a little bit about ruby. Some of it was also Jekyl though, and the workflow in Jekly / Octo is also a little awkward.

The most irritating bit is this:

1

rake new_post["some title here"]

I’m whining, sure, but this is just more punctuation than I really need. So because I’m a hacker first, I decided to fix this. What did I do? I didn’t go off to learn rake, fork Octopress and make a pull request - it’s even more stupid than that. I learned ( bits of ) coffeescript so I could hack on a Cakefile to wrap the Rakefile. I know, idiotic, but fun nonetheless:

1
2
3
4
5
6
7
8
9
10
11
12

{spawn, exec} = require 'child_process'
{ ask } = require 'ask'

task 'new', 'create a new blog post', ->
  # get stdin here...
  ask 'New post title: ', /.+/, (name) ->
      exec 'rake new_post["'+name+'"]', (err, stdout, stderr) ->
          throw err if err
          s = /^.+\: (.+)\n$/.exec(stdout)
          path = s[s.length - 1]
          forked = exec "subl #{path}"
          process.exit 0

The key bits are:

• the wrapper task removes the punctuation
• as an added bonus, the callback opens the new markdown file in my editor!

This was also the first non-demo / hello-world-ish code I’ve written in Coffeescript, and it’s not bad! There are things that definitely feel a bit awkward ( chaining methods, how callbacks work, etc ) but I think that is mostly just JS muscle memory I need to get over.

Another inspiration for trying on Coffeescript for size was this recent post by Rob Conery called ’Try it quiet’, and the accompanying video on Vimeo:

All of the Mocha tests are written in Coffeescript, and the cleaner syntax really clarifies the tests and expectations. It’s worth watching and even hacking along to if you’re unfamiliar with the bits of node he’s showing off. I was particularly charmed with how he runs mocha -w in a terminal and, as he implements things, more and more tests pass. Of course, you can’t beat Daft Punk live for a soundtrack either! :D