So the taskcluster client library in go is working, documented, running unit tests, and has a github pages site, for all the REST API endpoints:

http://petemoore.github.io/taskcluster-client-go/

http://godoc.org/github.com/petemoore/taskcluster-client-go/client

I’m now working on integrating the AMQP exchanges.

After this comes the generic worker, and also potential integration work for a TC-Buildbot bridge.

http://petemoore.tumblr.com/post/110725825013

This year at FOSDEM I talked about Firefox. I summarized the major changes that have been made to Firefox in 2014, and what our plans are for 2015.

Here are the slides of my FOSDEM presentation:

http://blog.queze.net/post/2015/02/11/FOSDEM-2015-slides-What-s-new-in-Firefox

Unlike beta 7, with Youtube proposing Flash to 36 users (instead of MSE), this beta is proposed to Windows users.

In this beta, we fixes some other crashes but also improved the search under Fennec.

• 31 changesets
• 51 files changed
• 769 insertions
• 465 deletions

Extension	Occurrences
js	19
cpp	13
py	5
java	3
jsm	2
h	2
build	2
xml	1
properties	1
ini	1
in	1

Module	Occurrences
toolkit	16
mobile	12
dom	9
browser	4
python	3
image	2
netwerk	1
modules	1
media	1
gfx	1

List of changesets:

Robert Strong	Bug 1129209 - Use a separate manifest for comctl32.dll. r=bbondy, a=abillings - e07bd3f1fd4b
Georg Fritzsche	Bug 1119281 - Fix missing telemetry client id in saved session pings. r=vladan,a=sledru - ced08a06e2d1
Patrick McManus	Bug 1110707 - dont assume seekable stream on sending_to http events r=valentin a=sylvestre - 222d4a9f7ed3
Mike Connor	Bug 1130246 - Treat general.useragent.locale as a localized pref in DirectoryProvider. r=rnewman a=sylvestre - 581876946dcf
Allison Naaktgeboren	Bug 1127237 - Text from history panel is not entirely displayed. r=liuche, a=lmandel - 6f3775d5c839
Seth Fowler	Bug 1124610 - Call PostHasTransparency for corrupt images that we treat as usable. r=jrmuizel, a=sledru - 3347b3531c98
David Major	Bug 1124892 - Increase Breakpad reserve size yet again. r=bsmedberg, a=sledru - 5a2b0dfc3832
Francesco Lodolo (:flod)	Bug 1128991 - [mobile] Update filter.py to ignore US specific keys in region.properties. r=mfinkle, a=sledru - 3bf30338bcbe
Doug Turner	Bug 1045229 - Beacons are not associated with windows. The current window based filtering that the network monitor does will skip requests that come from sendBeacon(). Here we explictly look to see if the network channel is from beacon by looking at the loadinfo. r=dcamp, a=sledru - 840987c23fc5
Maire Reavy	Bug 1126952 - tokbox.com added to screensharing whitelist. r=jesup, a=sledru - b5b3f7d712a9
Ethan Lin	Bug 1127405 - Remove the ForceRemove in CanvasClientSharedSurface to prevent crash. r=nical, a=sledru - 7a8703c465a7
Boris Zbarsky	Bug 1130259 - Make sure the integer overload of ScrollBy calls the double one, not itself. r=kip, a=sledru - 7733cfbb59a6
Seth Fowler	Bug 1128188 - Allow creation of animated frames that do not fit inside the bounds of their image. r=jrmuizel, a=sledru - f430d5f985d3
Ben Turner	Bug 1130541. r=janv, a=abillings - cb5d2bbf9234
Garvan Keeley	Bug 1130052 - Try avoid NPE, return from onHandleIntent if null intent. r=vng, a=sledru - 130e59d97b15
Mark Finkle	Bug 1117186 - fix geo-specific search defaults interaction with the defaultEngine getter/setter and use a helper for getting geo-specific prefs f=gavin,r=markh a=sylvestre - a9eec576bb2c
Mark Finkle	Bug 1129607 - Init the search service earlier so the country code is fetched before we attempt to get the engine list r=margaret a=sylvestre - c1578e681849
Mark Finkle	Bug 1117186 - fix geo-specific search default perferences r=margaret a=sylvestre l10n=aware - e1faea5d0942
Nick Alexander	Bug 1123980 - Part 1: Handle common prefixes in .properties lists and dicts. r=mshal a=sylvestre - 923404bb30ac
Nick Alexander	Bug 1123980 - Part 2: Write region-specific search settings into res/raw/browsersearch.json. r=mfinkle a=sylvestre - 05befa69d765
Felipe Gomes	Bug 1111960. r=gavin a=sylvestre - 5d37d11b64f2
Chris Pearce	Bug 1130311 - Disable MP4 decoder dormant heuristic for Fx36 on Windows. r=rillian, a=sledru - 8174cebcfbbd
Mark Hammond	Bug 1123974 - geoip result should not override users already with browser.search.isUS=true. r=florian, a=sledru - fafd3abc1d01
Mike de Boer	Bug 1091785 - Make sure the info panel anchors to the overflow chevron if needed. r=jaws, a=sledru - 2ad6015cdd1a
Olli Pettay	Bug 676470 - Ensure null-checking mCurrentTarget actually works. r=masayuki, a=sledru - d342ccaee6d5
Mark Finkle	Bug 1129576 - Fetch the country code in the Search Activity. r=margaret, f=rnewman, a=sledru - 8180eb5904de
Mark Finkle	Bug 1129576 - Rename the stumbler API key to the generic mozilla API key. r=nalexander, a=sledru - 8600a7b2e3a6
Steven Michaud	Bug 1129267 - Fix by backing out patch for Bug 1118615. r=mstange a=sledru - 1673712f9408
Paul Adenot	Bug 1127213 - Fix various issues with the device change notification in the WASAPI cubeb backend. r=kinetik, a=sledru - 9579b9ab68ca
Paul Adenot	Bug 1123768 - Backout Bug 1108455 to avoid truncating the end of audio streams on Vista+. r=kinetik, a=sledru - 9a36ec122aa5
Paul Adenot	Bug 1125804 - Remove the mixer callback when failing to open an audio stream when switching to an audio driver. r=jesup, a=sledru - 1584db7257a6

http://release.mozilla.org/statistics/36/2015/02/11/fx-36-b7-to-b8.html

As you may or may not know, I have been working on this project for quite some time, but actually really started the most critical parts a couple months ago. After having looked for (and chosen) a new name for what was a prototype project, it’s now time for a very first release.

So what is this all about?

Cinnabar is the common natural form in which mercury can be found on Earth. It contains mercury sulfide and its powder is used to make the vermillion pigment.

What does that have to do with git?

Hint: mercury.

Git-cinnabar is a git remote helper (you can think of that as a plugin) to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Numerous such tools already exist. Where git-cinnabar stands out is that it doesn’t use a local mercurial clone under the hood (unlike all the existing other such tools), and is close to an order of magnitude faster to clone a repository like mozilla-central than the git-remote-hg that used to be shipped as a contrib to git.

I won’t claim it is exempt of problems and limitations, which is why it’s not a 1.0. I’m however confident enough with its state to make the first “official” release.

Get it on github.

If you’ve been using the prototype, you can actually continue to use that clone and update it. Github conveniently keeps things working after a rename. You can update the remote url if you feel like it, though.

If you are a Gecko developer, you can take a look at a possible workflow.

http://glandium.org/blog/?p=3502

One thing I have tried to advocate for no matter what project it is I’m contributing to is good process and transparency. You would think that things like good process and transparency come naturally to open source projects but the thing is, no matter how old or new the project is there are always people coming and going who have varying depths of experience in doing work in the open and as a result open is not always the default in open source projects.

Most recently, I have been pushing for more transparency in some programs at Mozilla and specifically in the area that deals with community and not product. You might have thought that teams doing work around community at Mozilla are already operating transparently while the reality is in practice open is hard.

One thing I am trying to convince folks though is that working in the open is not so hard that we ignore the principles of working in the open and avoid trying to build a good foundation of open processes. One thing I am finding when I have these discussions though is people do not always feel empowered to speak out about working in the open. Simply put teams and organizations will get in these status quos where they put off this hard work and nobody really comes around often to challenge the status quo because often the debates that pursue of working in the open are filled with disagreement.

Have you ever been outspoken in a open source project about working in the open?

I would love to hear your thoughts in the comments and this will probably be a series of blog posts I write over the coming months on working in the open.

http://feedproxy.google.com/~r/BenjaminKerensaDotComMozilla/~3/r3dc85_0MVc/being-outspoken-on-open

You can tell the story of the computer industry --- in great detail --- through T-shirts. The rise and fall of companies, projects and entire technologies can be tracked through the T-shirts produced to commemorate them. I have a small but fine collection of vintage shirts, including

• PR1ME
• CMU Java Day 1996
• DEC SRC: "Turning theory into practice" (ironic, since they generally failed to do so)
• IBM: peace, love, Mozilla
• Mozilla 1.0 (dino head)

There are many classic shirts that I've seen or heard about, such as "The Apple engineer (unknown) has unexpectedly quit" from the inter-Jobsian era. I would love to see a T-shirt museum that captures these T-shirts for posterity and uses them to illustrate --- in a fun, visual way --- the progress of our industry. I'd be happy to donate any of my T-shirts. Why hasn't anyone done this?

http://robert.ocallahan.org/2015/02/computer-industry-t-shirt-museum.html

Regional communities have always been cornerstones at Mozilla. From the days when they sprung up around localisation to today when they are involved in activities across the board, our local communities have impact on our products and mission. Mark Surman’s recent post outlined the formation and goals of the new Participation team. The key point is that we want to create a virtuous circle where our volunteer community has direct impact on our products, while at the same time getting value in the personal and professional lives. While radical participation is being setup for exploration, the good news is we have programs and structures that work today. The Community Development Team will be focusing in a couple of main areas. One is volunteer community leadership driven by changes in the Reps program. The other one is working with product/functional teams at Mozilla to better align with their priorities and identify projects to work on with impact. Participation infrastructure, aka community tools, is the glue that holds everything together.

For more context, please read these other posts from some of my team members.

• David Tenser – Brace for impact (in a good way!)
• Emma Irwin- Mozilla Community Education in 2015

Where Does Regional Fit?

In a very broad sense, the Regional team will focus on the health of our local communities on the ground. Our communities, whether they be country-based (e.g. Mozilla Philippines) or a broader region (e.g. Mozilla Hispano) touch all parts of the globe. They range from small to large. While many Mozillians work individually and identify as part of a functional team, many more identify as part of a regional team. They are not mutually exclusive of course.

Why are they important?

• People: They enable people to connect from all walks of life behind a common mission. There is a sense of camaraderie, sharing, and fun.
• Language: l10n teams still have a crucial role in ensuring our products are localised, our product pages are translated, and our mission and the web ecosystem is understood by as many people on the planet as possible. There is still more work to do to make everything we do open to more languages.
• Culture: Understanding cultural norms is crucial for the organisation to adapt and apply our mission everywhere. Different cultures help shape and change Mozilla, for the better.
• Diversity: Input and opportunities for everyone give everything we do a rich foundation. It is reflected in our products, and in the way we work.

And there are more reasons. Regional communities have sprung up organically and are structured in many different ways. Mozilla India and Mozilla Hispano have working groups. In the Philippines, a Rep leads a functional area in the community such as localization, developer relations, FSA, education and women empowerment. Many have a strong online presence, with blogs, photo streams, social channels, and more. Some have community spaces for co-working and events. Find the community near you on our listings at mozilla.org.

Goals

The focus for 2015 and beyond will be:

• Support our communities to be set up for success. This is of course catch-all, but worth calling out explicitly. Community Health is the foundation from which everything else follows.
• Continue aligning communities towards product and functional impact. Today, our products such as Firefox and Firefox OS are our primary levers for carrying out our mission. They give us influence. I think in the last few years, via events such as Summits, brownbags, Mozillians email, and other channels we have done a good job of reminding people what work will make the biggest impact.
• Support functional teams: How can Mozillians be more embedded in teams in the organisation? One way is via a number of pilots we’ll be doing throughout the year, matching volunteers to projects that will help move things forward.
• Leadership: Not just in the sense of community leaders, but how can we empower all Mozillians to be leaders. This could mean a project leader, a functional lead, an events lead, a policy lead, a recruitment lead, and so on. Beyond Mozilla, how can we help Mozillians be leaders in other parts of their lives? The Reps program will be focusing on leadership this year and we will be working closely together.
• Support: How can help in structuring communities for optimal impact? What processes can we put in place to detect discord in communities earlier and act before it gets out of hand.
• Reconnect: Communications are crucial. We want to hear your ideas what you are doing, and we as regional community managers want to communicate plans, priorities and pointers with you.

The Team

Our regional sub-team is myself (EMEA), Gen Kanai (Asia), and Guillermo Movia (LATAM). If you live in other parts of the world, we have you covered as well. William Quiviger, who has substantial regional community building experience, will be providing guidance and support. As we proceed we will be evaluating the need for other resources.

How Can You Help?

You can help primarily by becoming more involved in your local community. Together we are stronger. Even if that means giving constructive criticism to help the community adapt and grow. As outlined above, some of our goals are not fully defined. Help us define them. Start conversations within your community on what they all mean to you. Coming very soon, we will be sending out a survey with a focus on finding out more about our regional communities. Please fill it out to help us get a better understanding of how we can support you.

http://brian.kingsonline.net/talk/2015/02/regional-communities-at-mozilla/

There are lots of organizations that use their own certificate authority to issue certificates for their internal servers. Unfortunately since Firefox does not use the Windows certificate store[1], these have to be manually added into Firefox. This post will cover how to get those CAs into Firefox.

CCK2

The easiest way to get your CAs into Firefox is to use CCK2. CCK2 allows certificate authorities and server certificates to be installed into the browser. It supports PEM, DER and text. It also allows you to designate certificate overrides (sites where certificate errors are ignored). Just go to the certificate page and point to either a URL or a local file where the certificate is contained.

AutoConfig via JavaScript

If you're using AutoConfig without CCK2, you can still use the API that the CCK2 uses to install certificate authorities. Here's what it looks like to install the cacert.org root certificate:

var certdb = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);
var certdb2 = certdb;
try {
  certdb2 = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB2);
} catch (e) {}
cert = "MIIHPT...zTMVD"; // This should be the certificate content with no line breaks at all.
certdb2.addCertFromBase64(cert, "C,C,C", "");

The three Cs mean to trust the certficate for servers, email and objects. The third parameter is the name, but it is ignored. If you want to install binary certificates, things get more complicated. In that case, I'd definitely recommend the CCK2.

PolicyPak

PolicyPak supports adding certificate authorites to Firefox via Group Policy.

Preload the certificate databases

Some people create a new profile in Firefox, install the certificates they need, and then distribute the various db files (cert8.db, key3.db and secmod.db) into new profiles using this method. I don't recommend this method (and it only works for new profiles).

certutil

If you're a real diehard, you can use certutil to update the Firefox certificate databases from the command line.

Hopefully one of these methods will work for you. Did I miss a method? Let me know in the comments.

[1] See: bug 432802 and bug 472113

http://mike.kaply.com/2015/02/10/installing-certificates-into-firefox/

About two months ago I wrote that the Service Worker Cache code was entering code review. Our thought at the time was to quickly transition all of the work that had been done on the maple project branch back into Nightly. The project branch wasn’t really needed any more and the code could more easily be tested by the community on Nightly.

Fast forward to today and, unfortunately, we are still working to make this transition. Much of the code from maple is still in review. Meanwhile, the project branch has languished and is not particularly useful any more. Obviously, this is a bad situation as it has made testing Service Workers with Firefox nearly impossible.

To address this we are going to begin posting periodic builds of Nightly with the relevant Service Worker code included. These builds can be found here:

Firefox Service Worker Builds

This page will be updated as code changes or migrates into Nightly.

We are all very excited to see Service Workers adopted on the web and are actively working to have it enabled in Firefox Nightly by the end of March. We hope that these builds will allow wider testing of our implementation to help us reach that goal.

Thank you for your patience and understanding as we work through the issues to get this feature landed and enabled in Nightly.

http://blog.wanderview.com/blog/2015/02/10/introducing-firefox-service-worker-builds/

The weekly Mozilla engineering meeting.

https://air.mozilla.org/engineering-meeting-20150210/

Good news for Add-on authors and front-end developers alike, who are working on e10s features: The JavaScript Shell that comes with the Developer Assistant add-on is now e10s-aware! With it, now you can set the scope of the JSShell to be of an anonymous framescript running in a remote tab, which allows you to run snippets of code in that context, and get the answers printed in the shell.

Here’s a screenshot of it in action:

I also created a screencast showing how to use the JSShell through the Developer Assistant add-on: http://screencast.com/t/uf5eEurN

Tab-autocomplete for remote tabs is not implemented, and I don’t have plans for implementing it anytime soon, but contributions are welcome. Even without autocomplete, hopefully this makes working with a e10s a tad bit easier!

https://felipe.wordpress.com/2015/02/10/e10sfied-developer-assistant/

As part of my ongoing work I’ve been measuring the size and depth of mozilla-central to extrapolate future repository size for scaling purposes. Part of this was figuring out some details such as average file size, distribution of types of files, and on-disk working copy size versus repository size.

When I posted a graph comparing the size of the mozilla-central repository by Firefox version my colleague gszorc was quick to point out that the 4k blocksize of the filesystem meant that the on-disk size of a working copy might not accurately reflect the true size of the repository. I considered this and compared the working copy size (with blocksize =1) to the typical 4k blocksize. This is the result.

 

As you can see the repository size is much smaller — about 72%. As of Firefox 5 the ratio of working copy size was about 73%. This went on a general downward trend to about 71% as of Firefox 38.

What this could mean is that 27-29% of files in the mozilla-central repository are below the 4 kilobytes in size. Most likely what it means is that 27-29% of the space used in a working copy of mozilla-central is padding smaller files until they are 4k in size, which roughly matches what I’ve found by calculating average file size in the repository.

Excluding some large binary files that are in the repository, the mean file size is 6306 bytes. This if offset by some very large source code files:

• 4.7M ./security/nss/lib/sqlite/sqlite3.c
• 4.8M ./js/src/octane/mandreel.js
• 5.3M ./db/sqlite3/src/sqlite3.c
• 8.6M ./js/src/jit-test/lib/mandelbrot-results.js

However, if we look at median filesize we come up to something much more plausible: 1173 bytes.

Here is the new working copy size in comparison with the source lines of code count from the original chart:

From this we can see a general upward trend in the amount of space used versus source line count. This can mean one of two things: more binary assets are being added compared to the amount of code added, or that more files below 4k in size are being added to the repository.

http://bke.ro/size-of-mozilla-central-compared/

Here follow some numbers extracted from my recent HTTP/2 presentation.

First: HTTP/2 is not finalized yet and it is not yet in RFC status, even though things are progressing nicely within the IETF. With some luck we reach RFC status within Q1 this year.

On January 13th 2015, Firefox 35 was released with HTTP/2 enabled by default. Firefox was already running it enabled before that in beta and development versions.

Chrome has also been sporting HTTP/2 support in development versions since many moths back where it could easily be manually enabled. Chrome 40 was the first main release shipped with HTTP/2 enabled by default, but it has so far only been enabled for a very small fraction of the user-base.

On January 28th 2015, Google reported to me by email that they saw HTTP/2 being used in 5% of their global traffic (que all relevant disclaimers that this is not statistically safe numbers). This, close after a shaky period with Google having had their HTTP/2 services disabled through parts of the Christmas holidays (due to bugs) – and as explained above, there’s been no time for any mainstream browser to use HTTP/2 by default for very long!

Further data points: Mozilla collects telemetry data from Firefox users who opted-in to it, and it collects numbers on “HTTP Protocol Version Used on Response”. On February 10, it reports that Firefox 35 users have got their responses to report HTTP/2 in 9% of all responses (out of more than 340 billion reported responses). The Telemetry for Firefox Nightly 38 even reports HTTP/2 in 14% of all responses (based on a much smaller sample collection), which I guess could very well be because users on such a bleeding edge version are more experimental by nature.

In these Firefox stats we see that recently, the number of HTTP/2 responses outnumber the HTTP/1.0 responses 9 to 1.

http://daniel.haxx.se/blog/2015/02/10/http2-is-at-5/

I haven’t been to the gym in a long time.

David Eaves, a person I have immense amounts of respect for, has been using a tag line related to this title/intro on his blog for quite a while, probably longer than I’ve known him.  And I honestly never gave much thought to the idea that writing really is a muscle until recently. I’ve taken a break from being a designer (or a programmer) to work as a product manager for over a year now. Designing and coding require a set of skills I’m very familiar with, code is an interpretive language that people use to communicate with each other about the details of commands they issue a computer. While design is a more visual language of storytelling, heavily using imagery and some text to convey the journey of a user to the team intent on correctly interacting with that user.  Both pursuits are about communication but each uses written language in a very different way.  As a product manager I’m forced to lean on my skills as a writer and I don’t think I had much in the way of skills previously but whatever bedridden muscles have been dormant are reawakening as I realize how young and foolish I really was to ignore this essential form of communication.

I’m hoping there is more to come, perhaps starting with some tech posts about recent projects while I try to grapple with this idea of writing more than a tweet.

http://clarkbw.net/blog/2015/02/09/if-writing-is-a-muscle/

the following changes have been pushed to bugzilla.mozilla.org:

• [1129291] Gear form is returning an error
• [1128969] ‘Clone this bug’ redirects to product selection instead of displaying context menu
• [1124255] Need a way to find only active versions and target milestones using the API
• [1129283] “suggested reviewers” missing, due to missing YAHOO.widget.Menu
• [1129183] 500 internal server error with duplicate mentor field
• [1129101] Custom integer field breaks “Change many bugs at once” functionality
• [813630] Last resolved time is displayed in server timezone not as per user preferences
• [1129915] Promote ‘Firefox for iOS’ to the main ‘file a bug’ page
• [1130895] Bugzilla comment tags suggestions/autocomplete isn’t working
• [1131036] BzAPI searches no longer working
• [1130885] change itrequest form from mozilla.org::Server Operations to Infrastructure & Operations :: MOC: Service Requests

discuss these changes on mozilla.tools.bmo.

Filed under: bmo, mozilla

https://globau.wordpress.com/2015/02/10/happy-bmo-push-day-126/

Mozilla takes privacy seriously – in our products, our policies, and our practices. As a result, we support draft legislation introduced today in the state of California to improve warrant requirements for electronic communications, also known as CalECPA reform (California … Continue reading

https://blog.mozilla.org/privacy/2015/02/09/making-progress-on-privacy-calecpa-reform/

https://blog.mozilla.org/netpolicy/2015/02/09/victory-for-net-neutrality-lets-take-it-across-the-finish-line/

This is the first of a few posts that I’m planning regarding discussion about how we implement and work on the desktop and standalone parts of Firefox Hello. We’ve been doing some things in different ways, which we have found to be advantageous. We know other teams are interested in what we do, so its time to share!

Content Processes

First, a little bit of architecture: The panels and conversation window run in content processes (just like regular web pages). The conversation window shares code with the link-clicker pages that are on hello.firefox.com.

Hence those parts run very much in a web-style, and for various reasons, we decided to create them in a web-style manner. As a result, we’ve ended up with using React and Flux to aid our development.

I’ll detail more about the architecture in future posts.

The Flux Pattern

Flux is a recommended pattern for use alongside React, although I think you could use it with other frameworks as well. I’ll detail here about how we use Flux specifically for Hello. As Flux is a pattern, there’s no one set standard and the methods of implementation vary.

Flux Overview

The main parts of a flux system are stores, components and actions. Some of this is a bit like an MVC system, but I find there’s better definition about what does what.
An action is effectively a result of an event, that changes the system. For example, in Loop, we use actions for user events, but we also use them for any data incoming from the server.

A store contains the business logic. It listens to actions, when it receives one, it does something based on the action and updates its state appropriately.

A component is a view. The view has a set of properties (passed in values) and/or state (the state is obtained from the store’s state). For a given set of properties and state, you always get the same layout. The components listen for updates to the state in the stores and update appropriately.

We also have a dispatcher. The dispatcher dispatches actions to interested stores. Only one action can be processed at any one time. If a new action comes in, then the dispatcher queues it.

Actions are always synchronous – if changes would happen due to external stimuli then these will be new actions. For example, this prevents actions from blocking other actions whilst waiting for a response from the server.

What advantages do we get?

For Hello, we find the flux pattern fits very nicely. Before, we used a traditional MVC model, however, we kept on getting in a mess with events being all over the place, and application logic being wrapped in amongst the views as well as the models.

Now, we have a much more defined structure:

• Components/views are a place for displaying, there’s some logic about what to display, but it isn’t business logic.
• The business logic exists in the stores, and is triggered by actions.
• You can follow an action through and find out which stores listen for it, and what they do.
• Actions themselves are well-defined with specified parameters.

React provides the component structure, it has defined ways of tracking state and properties, and the re-rendering on state change gives much automation. Since it encourages the separation of immutable properties, a whole class of inadvertent errors is eliminated.

There’s also many advantages with debugging – we have a flag that lets us watch all the actions going through the system, so its much easier to track what events are taking place and the data passed with them. This combined with the fact that actions have limited scope, helps with debugging the data flows.

Simple Unit Testing

For testing, we’re able to do unit testing in a much simpler fashion:

• Components/Views are tested by setting up their state and/or properties and ensuring the correct elements are displayed:

it("should render a muted local audio button", function() {
  var comp = TestUtils.renderIntoDocument(
    React.createElement(sharedViews.MediaControlButton, {
      scope: "local",
      type: "audio",
      action: function(){},
      enabled: false
    }));

  expect(comp.getDOMNode().classList.contains("muted")).eql(true);
});

• Stores are tested by setting an initial state, sending an action, and checking the resultant state:

it("should set the state to READY", function() {
  store.setupRoomInfo(new sharedActions.SetupRoomInfo(fakeRoomInfo));

  expect(store._storeState.roomState).eql(ROOM_STATES.READY);
});

We therefore have many tests written at the unit test level. Many times we’ve found and prevented issues whilst writing these tests, and yet, because these are all content based, we can run the tests in a few seconds. I’ll go more into testing in a future post.

References

Here’s a few references to some of the areas in our code base that are good example of our flux implementation. Note that behind the scenes, everything is known as Loop – the codename for the project.

• Dispatcher
• Actions
• A simple store
• A simple view

Conclusion and more coming…

We’ve found using the flux model is much more organised than we were with an MVC, possibly its just a better defined methodology, but it gave us the structure we badly missing. In future posts, I’ll discuss about our development facilities, more about the desktop architecture and whatever else comes up, so please do leave questions in the comments and I’ll try and answer them either direct or with more posts.

https://blog.mozilla.org/standard8/2015/02/09/firefox-hello-desktop-behind-the-scenes-flux-and-react/

“If you want to go fast, go alone. If you want to go far, go together.” (African proverb)

Jamie Allen reminded me that February 7th marked the two year anniversary of the Web Literacy community at Mozilla. We’ve achieved a fair bit in that time. Here’s a visual history of how we’ve got (nearly) to version 1.5 — inspired, in part by contributor Greg McVerry. There’s a list of all of the contributors so far at the end of this post and here.

2012

Mozilla’s web literacy work was actually kicked off by Michelle Levesque before I joined Mozilla. I helped with some suggestions and iterations — as you can see from her blog. To begin with, it was just a list of skills that I suggested she might want to put into graphical form. So she did:

There was a few months of overlap between me joining Mozilla as ‘Badges & Skills Lead’ and Michelle leaving. I took over development of the web literacy work and wrote a whitepaper.

2013

Erin Knight, Director of Learning at Mozilla at the time, suggested we might work towards a ‘Web Literacy Standard’. We hosted a kick-off call in February 2013 which was well-attended. This is when the community work started, iterating towards a v1.0.

The first draft (April 2013) looked like this:

The ‘release candidate’ in July actually had some design love (from Chris Appleton) rather than me messing about in Keynote. This was the ‘Request For Comments’ version from July 2013:

We’d decided to lock things down for September so that we could launch a version 1.0 at the Mozilla Festival the following month. We were still hoping for it to be a formal ‘standard’ so we called it a specification:

As you can see, it’s very similar to v1.1 and the upcoming v1.5 – as you’d expect.

2014

I’d moved teams in late 2013 to become ‘Web Literacy Lead’ at Mozilla. This meant that the Web Literacy Map was one of my main responsibilities. As a community we decided to transition away from ‘Standard’ as the term carries so much negative baggage in North America. After some discussion and debate, we settled on ‘Map’ — and took the opportunity to update it to v1.1.

Cassie McDaniel provided the visual refresh:

In April 2014 this was then used to underpin the Webmaker Resources section:

Clicking on one of the competencies takes you to a page listing the skills underpinning that particular competency. It was contains resources for teaching that particular area of the Web Literacy Map. This was curated by Kat Braybrooke.

In addition, nine of the ten points of the Mozilla manifesto link through to appropriate parts of the Web Literacy Map when you click on them for more information. For example under the ‘learn more’ section of Principle 2 it says Explore how to help keep the Web open. This links through to the Open Practices section of Webmaker resources.

2015

Towards the end of 2015 we began work as a community on scoping out what we originally called ‘version 2.0‘. There was a series of interviews, a community survey, and a small number of community calls in the run-up to Christmas deciding on what we should focus on in 2015.

Ultimately, we decided to re-scope to version 1.5 with the potential to go for a v2.0 later in the year. In the community calls we’ve held this year, we’ve already decided to combine ‘Web Mechanics’ and ‘Infrastructure’ to create a new, re-scoped Web Mechanics competency. At the same time, we’re separating out the two parts of ‘Design & Accessibility’ to create Designing for the Web and Accessibility.

We should have v1.5 ready by the end of March 2015.

Conclusion

This is a visual history, but behind the simplicity we’ve aimed for is so much debate, discussion and complexity. I’ve been in awe at times at the nuanced thinking of contributors to this project. Some have showed up since the beginning of the project, others have given their precious time for just a couple of sessions. But either way, we couldn’t have come this far without them.

If you want to get involved in this work, you’re very welcome! Here’s where to point your attention:

• Join the Webmaker mailing list
• Web Literacy Map v1.1
• Mozilla wiki page for the Web Literacy Map
• GitHub issues we’re working on

Community

Here’s the community, in alphabetical order by first name. They’re all rockstars:

• Alina Mierlus
• Andrew Sliwinski
• An-Me Chung
• Ani Martinez
• Alvar Maciel
• Ankit Gadgil
• An-Me Chung
• Atul Varma
• Audrey Watters
• Beth Ayer
• Bex Lewis
• Bobby Richter
• Bon Stewart
• Brendan Murphy
• Carla Casilli
• Cassie McDaniel
• Catherine Cronin
• Chad Sansing
• Chloe Varelidi
• Chris Appleton
• Chris Mills
• Chris Wilde
• Christian Briggs
• Christina Cantrill
• Clint Talbert
• Cynthia Lieberman
• Darren Alexander
• Dave Cormier
• Dave Crusoe
• Dave Steer
• David Ascher
• Diana Graber
• Doug Belshaw
• Dumitru Gherman
• Elizabeth E Charles
• Emil Ahangarzadeh
• Emily Goligoski
• Erica Sackin
• Erin Knight
• George Station
• Grant Russell
• Greg McVerry
• Gus Andrews
• Hannah Kane
• Honor Moorman
• Howard Rheingold
• Ian Cooper
• Ian O’Byrne
• Ibrahima Sarr
• James Buckingham
• Jamie Allen
• Jane Bozarth
• Janet Laane Effron
• Jen Moore
• Jess Klein
• Joerg Lohrer
• John Bevan
• John Martin
• Josie Fraser
• Joyce Seitzinger
• Justin Crawford
• Karen Smith
• Kat Braybrooke
• Kathryn Meisner
• Kevin Turner
• Kim Wilkens
• Larissa Shapiro
• Laura Hilliger
• Leah Gilliam
• Liesl Scheepers
• Lucy Harris
• Majda Nafissa Rahal
• Marc Lesser
• Marcius Herbert
• Marco Perez
• Mari Huertas
• Mark Power
• Matt Hannigan
• Matthew Willse
• Michael Greene
• Michelle Levesque
• Michelle Thorne
• Mikko Kontto
• Oliver Quinlan
• Paul Allison
• Paul Oh
• Pekka Ollikainen
• Roz Hussin
• Sara Carter
• Sarah Horrocks
• Shreyas Narayanan
• Simon Grant
• Srikar Ananthula
• Stephen Downes
• Stephen Judd
• Sunny Lee
• Terry Hodgson
• Thomas Farrow
• Tom Salmon
• Vicky Teinaki
• Will Barkis
• William Duyck

Have I missed your name? Apologies! Let me know.

Finally, there’s a few people I want to single out for their extraordinary help. I can’t overstate how important Carla Casilli was as a thought leader to the community from 2012 to 2014. Ian O’Byrne has stepped up time and time again and has led when I’ve been away. Greg McVerry has been a tireless champion of the Web Literacy Map. Laura Hilliger has been inspirational, knowledgeable and enthusiastic. Marc Lesser has been the voice of reason and wisdom. Gus Andrews has been thoughtful and questioning. Alvar Maciel has opened our eyes beyond the English-speaking world and been a indefatigable translator.

It’s been such an enjoyable couple of years. I can’t wait to get v1.5 ready and then move on to version 2.0!

http://dougbelshaw.com/blog/2015/02/09/two-years-of-weblitmap/

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20150209/