• Total bugs open: 552
• Total bugs opened: 298
• Total bugs closed: 218

Some specific changes of note:

• APIs added for payment status and users permissions (868030 and 868252)
• API to allow the setup of payments for apps (869572)
• Allow a submission flow that checks app permissions (858306)
• Enable the German and Polish translations (868888 and 868594)
• Signing in after logging out fixed (869664)
• Submitting reviews multiple times fixed (871871)
• Webfighter demo gained payments (858289)
• Forced issuers for payments re-enabled (867729)
• Senior Themes reviewer group created (868053)
• Move from pyes to pyelasticsearch (857156)
• Scroll positions preserved between tabs in the marketplace (868249)
• Stop Marketplace reverting to US after a phone reboot (865132)

The new Marketplace consumer user interface was pushed. The Marketplace is now a packaged app that uses the REST API to populate the app. This was a huge change and makes the site faster and more awesome. To checkout the packaged app see the Fireplace app on github.

The Marketplace was also moved out of Aurora status.

Avoid code duplication and reusing code is always an admirable goal. However, in some occasions, it’s not a bad idea to duplicate a little bit of code in order to make your software better.

An Example

When writing a Node app, accessing a directory listing is fairly simple: the fs.readdir command provides a list of objects in a directory, and a call to fs.stat will tell you whether each object is a directory or a file.

That’s fairly straightforward, but recursing (especially when using callbacks) can require some mental yoga. Each directory needs to keep track of how many subdirectories it expects to receive callbacks for and results need to be aggregated in pieces rather than sequentially.

When I needed a recursive directory listing this past week, I was tempted to use a library: why solve a solved problem? The glob library provides this functionality with very little effort:

Why would you use anything else? Here’s what I saw when I did an npm install glob:

• glob
  • minimatch
  • lru-cache
• sigmund
• grafeful-fs
• inherits

Simply by adding glob to my project, I’ve added a total of six modules. That’s not unexpected, though, since glob does a whole lot more than I need it to do. In the end, I ended up simply writing my own, and including it in the single file that requires the functionality:

Why are dependencies not good?

First, and most importantly, is the security of those packages. If the SSH keys of the developer of those packages are compromised, an attacker could provide an “updated” version of the library which includes malicious code. At Mozilla, we use internal mirrors of PyPi and NPM to make sure we’re not installing arbitrary modules. Avoiding dependencies helps to avoid requiring a solution.

Second, there’s a performance hit for libraries. If you’re building a one-off fix for a simple problem, using a library increases the overhead of your app’s load and use. If you’re building a web app on Node or Django, you might use an auto-reloader to restart your local server when script files change. In many projects, this takes an imperceptibly small amount of time to reload. As your codebase and dependency list grows, your auto-reloader can take precious seconds to run (we have projects that take almost five seconds to reboot).

Each dependency increases the time it will take to install your application. Zamboni (the code behind addons.mozilla.org and marketplace.firefox.com), for instance, takes 12 minutes to install libraries and dependencies. What starts out as a small number of libraries can very quickly grow out of control and become a serious nuisance. time npm install glob, to reference my earlier example, tells me that glob adds four seconds to my install time. Some simple and unscientific benchmarks from popular node libraries:

• socket.io: 33s
• mongoose: 9.5s
• connect: 5.7s
• jade: 5.3s
• express: 4.4s
• glob: 3.9s

And some from popular Python libraries (run with time pip install <module>):

• numpy: 110s
• django: 96s
• pycrypto: 18s
• flask: 14s

Third, you’re taking the gamble that the libraries that you depend on don’t have conflicting versions. A great example of this can be illustrated by a web app that I was building: the HTTP requests that I was creating with Python’s requests library didn’t have a .json property, as the docs state. An hour of hair-tearing later, I discovered that another library that I was using had already installed a much older version of requests which lacked the property. Unfortunately, the library wasn’t compatible with the latest version of requests and I had to settle for the old version.

The consequences could have been much worse, and this is a not-well-solved problem (for the Python community, at least).

Last, if your project is used as a library, including dependencies decreases the re-usability of your code. If your code uses a third-party library when it could have taken advantage of some slightly-gnarly standard library tools, all of the above reasons make it that much more difficult for a developer to justify using your tool.

Now hold on just a minute.

Does this mean you should never use an external library? Not at all! You should use libraries whenever it’s appropriate. Sometimes the effort required to perform a task correctly and thoroughly (or at all) is simply too much work to do on your own. OAuth? You’ll probably want a library. Database work or ORM? Use a library. But what if you need to serve a single static HTML file over HTTP? You can probably use Node’s http or Python’s SimpleHTTPServer without too much heartache.

Sometimes it’s just irresponsible to write code yourself: would you trust a developer’s one-off method or a mature ORM’s SQL sanitization code? What about code to generate secure random numbers for encrypting sensitive data? Or code that protects against XSS attacks? There are a lot of instances where it’s in your users’ best interest to use a trusted solution rather than your own solution.

A double-edged sword.

Another reason for choosing libraries is the community: if there are bug fixes to a third-party library, dependents can relatively easily update to the latest version of the library and take advantage of the improvements immediately.

That can be a good thing and a bad thing, though. Libraries without a community around them can contain bugs that don’t get patched in a timely manner. Fixes may be difficult or impossible to upstream.

TL;DR

1. If you can easily get by without a dependency, you don’t need the dependency.
2. If you’re building a library, you should avoid dependencies.
3. Don’t avoid dependencies if it means potentially putting your users at risk.

• Total bugs open: 538
• Total bugs opened last two weeks: 237
• Total bugs closed last week: 159

Payments testing was conducted in the field and that caused a large number of bugs to be filed.

Some specific changes of note:

• API for the simulator to create app receipts (865498)
• Users languages are now persisted for Marketplace and AMO so emails can be localized (833049)
• API now works correctly with geo location (863775)
• App locale listings improved in the developer pages (866287)
• A whole bunch of payment fixes from Bango.
• Product icon API makes payment pages so much prettier (864451)
• Fireplace shows new apps (867272)
• Review queue for themes improved (841185)
• A parser for the new app feature detection (862459)
• New design for the details page (860384
• If users abort during PIN, make them start again (867727

Payments with an icon:

Web activities are coming to the Marketplace.

Check out the documentation for more.

A Beer and Tell is an event web developers at Mozilla hold every third Friday of the month. We share emotional and uplifting stories about projects we’re hacking on to the group. Usually open source projects. Likely with a reasonable license. Today your Beer and Tell post is written by Edna Piranha of Noodle Industries fame.

Last Friday, we experienced the following dramatic and exciting worlds:

• Michael Kelly’s text-based adventures in JavaScript!
• Absent Erik Rose’s clickable traceback stack frames in Python!
• James Long’s scalable cloth simulation in LLJS/asm.js!
• Chris Van’s “because my original project name was taken on Github” project GltHub!
• Edna Piranha’s (that’s me!) interactive fiction game engine thing!
• Matt Basta’s graphicsBC!

Text-based adventures in JavaScript

Reporting from hills surrounding a Martian colony, Michael Kelly shares his latest project – an ode to the time when we were young children (or possibly still unborn) – text-based adventure games in JavaScript. You can play a demo, as long as you promise to avoid viewing the source and cheating.

Text adventures in JavaScript

Clickable traceback stack frames in Python

While we weren’t looking, Erik Rose’s body was replaced by Mike Cooper and he presented in Erik’s voice about nose-progressive. You can click your stack frames to open your editor – view a demo or call your local representative!

Scalable cloth simulation in LLJS/asm.js

Like a hawk from the night sky, James Long swooshes into the Mountain View office through a wormhole and opens his high-performance laptop. He presses the space bar and an open source browser opens with a cloth simulation. He plays Gary Wright’s “Dreamweaver” while we are slowly possessed by the silky smooth cloth simulation. You too, can be possessed by the dance of the cloth.

cloth simulation

GltHub (a.k.a. because my original project name was taken)

Chris Van takes us on a spaceship to Jupiter and tells us about GltHub, a site that reminds you of the guilt you should feel for not closing bugs fast enough. If you want to contribute more guilt, check out the rocket engine that made this.

GltHub

General Store

Edna Piranha (wait, I’m talking about myself in the third person – weird) presents an interactive fiction game engine called General Store that causes post-post-post modern, post-deconstructed encounters with the fourth kind – absurdist fiction. Also known as Lovecraft meets Kafka. Do not attempt to adjust your television, just click around and breathe slowly.

General Store

graphicsBC

We finally land back on planet Earth and sit comfortably in a circle around a campfire. With a flashlight under his chin pointing upwards and him staring straight at us, Matt Basta talks about graphicsBC, a microscript for code golfers and hobbyists to create graphics. Suddenly, Tofumatt shows up in a flying motorcycle and throws his helmet into the fire.

And that’s it for now! See you again next month.

MDN workflow was a formless void

When I first joined Mozilla there was no workflow for MDN; in fact, there were no full-time developers for MDN! To push my first bug fix to the site, I had to negotiate a mess of mdn bugs, wiki pages, and IT bugs, strung together with email. It took a couple weeks to get a simple fix into production, and worst of all – I had to interrupt at least 3 other peoples’ regular workflows.

Let there be Scrum

I had done Scrum for a few years at SourceForge so I naturally started to work in some “scrummy” things for MDN – first I added some agile/scrum features to the Bugzilla JS addon. Then we got another couple of developers on the team and we used more agile practices in our MDN workflow. So we did user stories, standups, retrospectives, planning poker, and sprints on top of Bugzilla with Paul McLanahan’s fantastic ScrumBugs tool. We used it to run our sprints for over a year; to migrate MDN from MindTouch to Django. Sprints helped us prioritize, plan, and commit to release batches of bug-fixes, enhancements, and features at regular intervals.

Continuous Deployment

On our new Django platform, James and Jake hooked chief up to give us continuous deployment to MDN; our “regular intervals” went from weeks to hours. Our flexibility and adaptability with continuous deployment is awesome. Pushing frequently caused a series of effects on our workflow, though:

1. We naturally prioritized things by hours or days. So, during our sprints, we would
2. remove and add items between planning meetings. This had knock-on effects like
3. making it hard to see what we’re actually working on between meetings, and
4. making our sprint-based estimates totally inaccurate.

A ban came, it’s name was Kan

Around this time, I read Kanban, by David Anderson and some of Kanban and Scrum. A couple things stood out to me:

• Kanban visualizes existing workflow
• Kanban favors Evidence-Based Scheduling over estimates

The Kanban feature I most liked was lead time – i.e., the clock time between when a request is made and delivered – and cycle times – i.e., the clock time between when a cycle of work begins and ends. These clock times seem more valuable to plan and prioritize than fuzzy estimations. Because really – who doesn’t like data and numbers, right? So, of course, I wrote code – kanbugs – to help visualize our MDN workflow and calculate our lead and cycle times.

Kanbugs

Kanbugs used data from our bugzilla product and our GitHub pull requests to visualize our workflow. In general, the workflow was:

1. We select a bug and add ‘p=<estimate>’ to the whiteboard
2. We implement a bug and submit a GitHub pull request with “fix bug <id>” in the commit message
3. We review a bug and merge it to master, which automatically marks the bug ‘RESOLVED:FIXED’ in bugzilla
4. WebQA tests the bug on the MDN dev integration server
5. We release the code to production, and WebQA marks the bug “VERIFIED:FIXED” in bugzilla

By visualizing the workflow and calculating both lead and cycle times we learned a couple interesting things. Most prominently, of our 39-day lead-time, 19 days were spent in triage and 14 days were spent waiting for testing! 85% of our lead-time was happening outside the development team. This kind of data helps us more effectively improve our workflow. E.g., rather than improve our estimates, we worked with WebQA to change from mandatory to as-needed exploratory testing.

Kanbugs was good for passive, read-only visualization and calculation, but (like Scrumbu.gs before) it wasn’t made for active management. It lacks:

• Quick visual scanning for action items – who’s blocked? who’s too busy? what should I work on next?
• Work-in-Progress limits – Kanban enforces small batch sizes by setting limits on how many things can be in the board at a time

Kanbanery

Kanbanery is good for these features. So, a couple months ago, we started an MDN board on Kanbanery. Kanbanery’s visualization is great. On a typical morning, I check emails and then

1. quickly scan the board for any cards with green check-marks that I can pull to the next step of development.
2. quickly scan the work-in-progress limits to see if I can help un-block cards that are piling up at a certain step
3. quickly scan the board for my cards to resume my main dev task(s)

Of course, now that we’ve used Kanbanery for a couple months, we’ve hit drawbacks:

• Yet Another Tracking Tool – we already have to keep up with email, bugzilla, and github. Scrumbugs had the same drawback, but Scrumbugs doesn’t micro-track through the sprint, and it automatically marks bugs fixed using bugzilla data.
• How to incorporate contributors – we don’t want to make contributors use Yet Another Tracking Tool, so we don’t include them in the board. That means the board doesn’t show contributors’ work, which can be considerable.
• General process churn – we went from no process through multiple forms of agile and scrum practices to Kanban in the space of about 18 months. I really like to continuously improve dev practices, but even I’m getting tired of changing things.

What’s next – maybe Kanbuggery?

Rather than change things up again, what I’d really like to do is automate Kanbanery – to update the board based on bugzilla and github actions, like we had done with Kanbugs. Then Kanbanery could give us its great visual features without needing active care and attention. Kanbanery has what looks like a fully-featured API, but I haven’t had time to explore it. Has anyone else?

How are other Mozilla, open-source, or website teams using Kanban for development?

• Total bugs open: 485
• Total bugs opened last two weeks: 150
• Total bugs closed last week: 110

The API documentation has moved and is now separate from the rest of the marketplace code. The marketplace has adopted the status code 451 to describe an app we can’t display.

The migration over to the Add-ons site is now complete. Go check out themes.

Some specific changes of note:

• OAuth has been turned on for all internal services between marketplace, solitude and webpay (858813)
• Changes to the receipt specification to allow different kinds of receipts (858610)
• Three legged OAuth has landed for the API (827948)
• API submission is now throttled, but you can apply for access to submit more apps (848869)
• Did we mention themes are migrated, oh yeah (858276)
• Fireplace now has a featured page (860410)
• Receipt verifying now checks the verifying service URL (770666) and type of receipt
• Fireplace now has abuse pages (857685)
• Unit tests galore (851582) and more for Fireplace
• Apps filtered on adult and child flags (852567)
• PIN user interface awesomeness (842861)
• Charts, charts and more charts using monolith (843046)
• Where in the world is Carmen Sandiego? I don’t know but our new geo location might tell you (851192)

And finally… odd add-on of the day whimsy.

• Total bugs open: 464
• Total bugs opened last two weeks: 232
• Total bugs closed last two weeks: 233

Most of the changes revolve around the API. There are endpoints added for the homepage, login, ratings and more. For more information on the Marketplace API, please check out the documentation.

The primary consumer of the API right now is fireplace the packaged app for the Marketplace. There have been a lot of changes in fireplace including search results, ratings and more.

We are currently migrating the existing Get Personas site over to the Add-ons site. For more information read our blog post.

What do you do at Mozilla?

I’m the Engineering Manager for the Firefox Marketplace and Add-ons. I spend most of my day trying to remove roadblocks for developers and coordinating with other teams to make sure there is a steady stream of work. The spice must flow!

Other parts of my job are day-to-day team operations (HR questions, career development, etc.), spec reviews, architectural design input, any shady negotiations for project priority, and crisis management in the rare case when something goes pear shaped.

Any fun side projects you’re working on?

I’m a hobbyist photographer these days and have started experimenting with writing short (fiction) stories to go along with the pictures. Something that is still in its infancy for sure.

How did you get started in web development or programming?

I took a C class in high school and thought it was fun, then I suffered through Java in college and started doing PHP work part time for the university. I flipped to python a few years ago and have enjoyed it although my coding these days is mostly minor tweaks to other peoples’ code.

How did you get involved with Mozilla?

Mike Morgan and I worked in the same place while I was in college. He was doing volunteer work with Mozilla and it looked like he was having a good time so I started volunteering too. At that time we were maintaining Add-ons which was a mix of hard-coded add-ons and smarty templates. It wasn’t pretty.

What’s a funny fail or mistake story you can share?

We used to maintain mozilla.com in SVN as a bunch of static files in a hierarchy. I may have gotten a little carried away with the flat files – we had about a dozen files we duplicated for every version of Firefox (at the time we had 4 levels, eg. version 2.0.0.1) and for every locale (about 60 locales). That, combined with the locale specific CSS and images added up to a ton of files on disk and SVN would soak up all the disk I/O trying to do an update or a commit.

Anyway, when we launched Firefox 3 we were aiming for the Guinness World Record and we put on a big show of it to get lots of downloads including having people talking live on Air Mozilla about how awesome the new browser was. Due to the high traffic everything was responding slower than usual, but we were in decent shape, except that I had to push one last thing to SVN and I did an `svn up` first and it was just sitting there thrashing and – SVN doesn’t have any output when it’s parsing through your directory tree – I just had to sit there and wait. It ended up taking about 20-30 minutes which wasn’t unusual (sadly enough), but not being able to give an estimate was rough. I remember watching Mike Beltzner talking about random things on Air Mozilla trying to fill time and he’d ask me on IRC for an update every couple minutes and I’d reply with “real soon now.” I felt bad for him.

So, I contributed to us being late to launch in a high-profile kind of way, but we still made the record and I was happy about that.

What’s something you’re particularly proud of?

When the Marketplace team gets in its groove it blows productivity estimates out of the water. We work so well together I’m just proud of my whole team. The entire Firefox Marketplace was just an idea a year ago and look where we are now.

What’s coming up that you’re excited about?

We’re going to be merging Get Personas into Add-ons. For real. We’ve been talking about it for, like, 2 years and every time it comes up it gets bumped for something higher priority but it’s finally close enough that we’re just going for it.

What question do you wish you’d been asked?

Q: If I typed “youtube” into your awesomebar would you be embarrassed at what showed up?

A: Nope! First hit: Macklemore’s Thrift Shop. Second hit: LMFAO’s Sexy and I know it. Third hit: I clicked it and it says it has been removed because it violated Youtube’s TOS. So, that one might have been embarrassing, I’m not sure.

Favourite city that’s not Portland?

The easy answer is wherever my friends are, but as I’m staring outside at the cold wind and the looming rain I’d say somewhere warm like some anonymous fishing town in Mexico.

• Total bugs open: 476
• Total bugs opened last two weeks: 213
• Total bugs closed last week: 138

A few of the many changes:

• Anonymous installs, app creation and user registration being recorded for metrics (bug 836586 and more).
• If an app is public the API will return details to anonymous users bug 827986).
• App validator API no longer requires authentication (bug 826835).
• Ratings API added (bug 841199).
• Mobile review pages added for reviewers (839543).
• Multiple improvements to the devhub documentation.
• Simulated in-app payments can now be done (839652).
• Marketplace locked to portrait orientation (844186).

The Firefox Marketplace is building a packaged app which allow the browsing and installing of apps. Fireplace is the start of that. To allow the packagead app to communicate with the marketplace we are rapidly expanding the API.

DXR is a code navigation and static analysis tool for the Firefox codebase. It consists of two parts:

• A Flask app which runs under Apache via mod_wsgi
• An offline build process which generates a syntax-highlighted version of every Firefox source file as HTML and lays them down on disk

These generated files are the ones served by RewriteRules in production:

However, for convenience during development, we also have a trivial Python routine to serve those files:

I pitted the RewriteRules against the Python controller on a local VM, so keep in mind that all the standard caveats of complex systems apply. That said, let’s see what happened!

Having heard complaints about NFS-based VirtualBox shared directories (where my generated files lived), I expected both solutions to be bottlenecked on IO. To my surprise, I saw a pronounced difference between them.

The RewriteRules serve static pages in an average of 6 ms at a concurrency of 10. This is a representative test run of ab. The tables at the bottom are the most important parts:

(py27)[15:16:12 ~/Checkouts/dxr]% ab -c 10 -n 1000 http://33.33.33.77/code/README.mkd
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 33.33.33.77 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache/2.2.22
Server Hostname:        33.33.33.77
Server Port:            80

Document Path:          /code/README.mkd
Document Length:        7348 bytes

Concurrency Level:      10
Time taken for tests:   0.573 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      7635628 bytes
HTML transferred:       7355348 bytes
Requests per second:    1744.93 [#/sec] (mean)
Time per request:       5.731 [ms] (mean)
Time per request:       0.573 [ms] (mean, across all concurrent requests)
Transfer rate:          13011.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.4      2       4
Processing:     1    4   4.9      4     124
Waiting:        1    4   3.1      4      99
Total:          2    6   4.9      5     124

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      6
  75%      6
  80%      6
  90%      6
  95%      7
  98%      7
  99%      8
 100%    124 (longest request)

Routing the requests through Python instead drives the mean up to 14 ms:

 50%     14
 66%     15
 75%     16
 80%     17
 90%     19
 95%     21
 98%     23
 99%     25
100%     32 (longest request)

This is with WSGIDaemonProcess example.com processes=2 threads=2, which, after a little experimentation, I determined is close to optimal for my 4-CPU VM. It makes some intuitive sense: one thread for each logical core. The host box has 4 physical cores with hyperthreading, so there are plenty to go around.

Turning the concurrency down to 2 had surprising results: Python actually got slightly faster than Apache: 3 ms avg. This could be measurement noise.

 50%      3
 66%      3
 75%      4
 80%      4
 90%      4
 95%      5
 98%      7
 99%      8
100%    222 (longest request)

-c 4 yields 6 ms:

 50%      6
 66%      7
 75%      8
 80%      8
 90%     10
 95%     11
 98%     12
 99%     12
100%     14 (longest request)

And, more generally, there is a linear performance trailoff as concurrency increases:

This was a surprise, as I expected more of a cliff when I exceeded the complement of 4 WSGI threads.

When we keep our concurrency down, it turns out that Apache doesn’t necessarily run the RewriteRules any faster than Python executes browse(). However, at high concurrency, Apache does pull ahead of Python, presumably because it has more threads to go around. That will probably hold true in production, since raw Apache processes eat less RAM than WSGI children and will thus have their threads capped less stringently.

Is a gain of twenty-some milliseconds for likely concurrency levels worth the added complexity—and logic duplication—of the RewriteRules? I think not. To get an idea of what 20 ms feels like, the human audio wetware juuuust begins to recognize two adjacent sounds as distinct when they are 20 ms apart: any closer, and they blend into a continuous tone. (Some sources go as low as 12Hz.) There are some usability studies that estimate a 1% dropoff in conversion rate for every extra 100 ms a page takes to load, but no one bothers to measure very fast-loading pages, and I would expect to reach a “fast enough” plateau eventually. Even if the linear relationship were overturned on real hardware, real hardware should be faster, making the latency differences (within reasonable concurrencies) even less than 20 ms. The “go ahead and use Python” conclusion should hold.

Finally, it’s worth mentioning that I’m still serving what are classically in the category of “static resources”—CSS, JS, images, and the like—with Apache, because we can do so in one simple Alias directive. What’s to lose?

Obviously, this is a boisterously multidimensional search space, comprising virtualization, threads, hardware, and IO abstraction, and I had ab running on the same physical box, so take these exact results as a single data point. However, they do establish a nice ceiling that lets us stop worrying about wringing every last drop out of the web server.