A couple of weeks ago, our friends at Europtimum responded to our horse gesture (timeline) with the delivery of a most excellent Totoro. For those of you unfamiliar with Totoro, my understanding is that it is a 1980?s Japanese animated cat. This particular manifestation is a cat like box, which the lovely people over at Europtimum made themselves and filled with an end of week snack consisting of candy necklaces, rockets and super balls. (Despite at least one person having never previously seen a superball, no one ate the superballs.) Needless to say, fun for the whole office.

Mozilla and Europtimum have been having a fair amount of fun. However, our initial connection was simply location based – their office is on the fifth floor in the adjacent building. A small act of kindness to brighten the day of our neighbours has resulted in a wonderful series of back and forth with them that has brought smiles to both of our offices.

This latest bout of kindness got me thinking that it’s time to take horseplay on the road – that is, to spread the fun to others.

Here’s my challenge. Take a look out of your window and pick an office. Figure out who’s over there and then, quite out of the blue, send them a horse related product. (Bonus points for doing it in person!) Let’s see what sort of new relationships will form simply by taking a few minutes out of your day to do something nice for a group of strangers. The horse head that we sent is available on Amazon. Some other fun products might be a lucky horseshoe, a plush animal, or mane and tail.

To kick things off and break the international border, the Mozilla Toronto office has sent a horse head to our Mozilla colleagues in France to celebrate their new Paris office.

A bonne chance!

Tagged: fun, horseplay, mozilla, toronto

One of the new features introduced in Firebug 1.12 alpha 5 is a filter for DOM event logs (issue 229).

Logging of DOM events has been available in Firebug for a long time and the filter should make it more useful and effective in daily usage.

The problem is that we are unsure whether UI/UX of the filter is implemented properly.

So, if you are using this handy feature please read further and let us know what you think (leave a comment below).

Previous Implementation

See the next screenshot, it shows a menu item that represents the Log DOM events feature.

• Log Events feature can be just switched on or off.
• There is no way to pick, which events should be logged for selected node. All events for the node are logged in the Console panel.
• So, there might be a lot of logs in the Console (especially those for mousemove events)

New Implementation

This screenshot shows the new implementation. There is a new submenu that allows to pick what events should be actually logged.

• You can still click the top level Log Events menu to log all events just like before.
• You can also open the submenu and pick only the category of events you are interested at.
• There is a tooltip listing all events in the selected category.
• The tooltip also shows an example of how to use the feature from Firebug's command line.

Questions

• But, is the submenu with event-categories actually needed? Isn't the submenu too long and hard to use?
• Wouldn't it be simpler to keep the feature as it was before and just not log mousemove events? Is anyone actually interested in logging mousemove events?
• Or is there any other and better solution?

What do you think?

You have probably already heard of generators and iterators coming to a browser near you. They have been available in Firefox for a long time and are used extensively all over the Mozilla code base. The V8 team will implement iterators and generators once ES6 has been finalized.

This post describes the current implementation in SpiderMonkey and tries to include the current state of the ES6 draft and discussions.

A simple generator

Let us take a look at a simple example of a generator function that represents an infinite sequence containing all the numbers from 0 to Number.MAX_VALUE. Once it reaches MAX_VALUE it will not increase any further but always return the same number.

function myInfiniteGenerator() { var i = 0; while (true) { yield i++; } } var iter = myInfiniteGenerator(); while (true) { console.log(iter.next()); }

Any object of the following shape is an iterator:

{ next: function() -> any }

The next() method simply returns the item next in the sequence.

Finite sequences

As you surely noticed the generator of the first example produces iterators that will never run out of items. The next example shows an iterator representing a finite sequence:

function MyFiniteIterator(max) { this.cur = 0; this.max = max; } MyFiniteIterator.prototype.next = function () { if (this.cur < this.max) { return this.cur++; } throw StopIteration; };

The given code implements a custom iterator without writing a generator function. Note that it throws StopIteration as soon as it reaches the maximum value to signal that the sequence is exhausted. It is a lot more elegant to implement the same sequence using a generator function:

function myFiniteGenerator(max) { var i = 0; while (i < max) { yield i++; } }

Generator functions will automatically throw StopIteration when terminating. So how should one consume iterators with finite sequences?

Consuming sequences

In Java for example, you would check iter.hasNext() and stop when it returns false. In JavaScript however you need to use a try…catch statement to catch StopIteration when it is being thrown.

var iter = myFiniteGenerator(10); while (true) { try { console.log(iter.next()); } catch (e if e === StopIteration) { break; } }

You might wonder if there is a better way to do this and indeed there is. Using for…in or for…of you do not have to catch StopIteration yourself, the JavaScript engine will do it for you. As soon as the sequence is exhausted the loop will terminate normally without the exception being propagated:

var iter = myFiniteGenerator(10); for (var i in iter) { console.log(i); } StopIteration is special

StopIteration actually is a standard variable that is bound to an object of class StopIteration. It is an ordinary object with no properties of its own and it is not a constructor function.

try { throw StopIteration; } catch (e if e instanceof StopIteration) { // This works because: StopIteration instanceof StopIteration === true; }

As StopIteration is a singleton of type StopIteration you can also catch it by checking for equality:

try { throw StopIteration; } catch (e if e === StopIteration) { // ... handle exception } StopIteration is mutable

You should be aware that StopIteration is a mutable global. Just like undefined it can be modified to hold any other value. If you write a library and want to shield against modifications from outside you can use this neat little trick I found on Dave Herman’s blog:

(function(){try{(function(){true||(yield)})().next()}catch(e){return e}})()

The inner function is a generator that terminates immediately and therefore will throw a StopIteration. The outer function simply catches and returns it.

StopIteration may become a constructor

The current iterator strawman states that StopIteration will become a constructor to maintain compatibility with generator functions returning values.

Iter.prototype.next = function () { if (this.cur < this.max) { return this.cur++; } var stop = new StopIteration(); stop.value = "sequence exhausted"; throw stop; };

The equality check from above would not work anymore so it might be better to just use instanceof.

StopIteration may not be part of ES6

The Python way of throwing to denote the end of a sequence is backwards compatible with old ECMAScript versions but there seem to be people not happy with the current proposal. While I can’t tell whether StopIteration is really to be removed a couple of alternative suggestions have been made:

Introduce a keyword to end a frame

To not misuse exceptions for normal control flow ES6 could introduce a stopiteration or endframe keyword that would end the current frame with an optional return value. The obvious downside is that it is probably not backwards compatible.

Iter.prototype.next = function () { if (this.cur < this.max) { return this.cur++; } stopiteration [reason]; // or endframe [reason]; }; Add an iterator.hasNext() method

Just like Java the iterator API could consist of the two methods next() and hasNext(). The client would then need to check hasNext() every time before calling next().

Iter.prototype = { hasNext: function () { return this.cur < this.max; }, next: function () { if (this.hasNext()) { return this.cur++; } throw new Error("sequence exhausted"); } }; Let next() always return an object

Custom iterators would be required to implement a single method but would not need to throw. Instead they would return an object with the property done set to true to indicate that the sequence has ended. The value property would be used to store values passed to yield or return in a generator function.

{ next() -> { done: false , value: any } | { done: true[, value: any] } } Food for thought

This is in no way a complete list of possibilities or proposals that were brought up on es-discuss so please make up your own mind about the current iterators implementation and the suggested improvements.

The future is bright

Whether or not StopIteration will end up in ES6, generators and iterators are great and you should make sure to be prepared when they become available in modern browsers as well as on Node.js.

I concentrated particularly on StopIteration but there are lots of great posts out there that go way more into depth about generators and their usage. Make sure to also take a look at libraries like Task.js that combines generators with promises to cooperative tasks.

It’s been a month since Felipe and I started coding on the add-on manager conversion, and we’ve made quite a bit of progress. The core code for both modules has been converted to load and save in JSON format; we’re now cleaning up corner cases like upgrading from previous database formats.

By far the biggest headache for me has been debugging test failures in the xpcshell test suite. The test suite for Addon Manager is extremely thorough, which is great because it gives me quite a bit of confidence that the new version will work correctly if we get all the tests to pass. The down side is that almost all of the tests are written as end-to-end scenarios where a number of add-ons are installed, updated, uninstalled, etc. and the (simulated) browser environment is started, stopped, upgraded, etc. When a test fails, there is usually an extended debugging session necessary to find the cause.

Unfortunately, all our spiffy new JavaScript debugging tools don’t work in the xpcshell environment; we really need to make progress on Bug 809561 so that we aren’t stuck with putting dump() statements all over the code to find problems. I did put together one patch for the asynchronous test harness to print function names as asynchronous test cases start and end, to at least make it easier to diagnose hanging async tests; that’s in bug 863311.

 

See Bug 853388 and Bug 853389 for work-in-progress patches and discussion of some of the other issues that have come up.

In a previous post, I talked about add-on scopes. One of the things that was most problematic about add-on scopes was where the extensions.autoDisableScopes preference could be set. In my original testing, I thought I was unable to set it in an autoconfig file. I've retested everything in the ESR 17 as well as the current Firefox, and to my surprise, this value can be set fine in an autoconfig file (although not if it is remote).

In addition, for files in the defaults/preference directory, there were issues with JS files only working if the filename started with a letter less than f. That problem appears to not be there anymore either.

So to summarize, you can set extensions.autoDisableScopes via autoconfig (and you should) and it doesn't matter what your JS file in defaults/preferences is named.

Some updates on the MathML Acid Tests... First the patch for bug 717546 landed in Nightly and thus Gecko is now the first layout engine to pass the MathML Acid2 test. Here is a screenshot that should look familiar:

As you know, Google developers forked Webkit and decided to remove from Blink all the code (including MathML) on which they don't plan to work in the short term. As a comparison, here is how the MathML Acid2 test looks like in Chrome Canary:

Next, someone reported that Firefox Mac got more errors in the MathML Acid3 test. I was already aware of some shortcomings anyway and thus took the opportunity to rewrite the tests with a better error tolerance. The changes also fixed some measurement issues with auto resizing on mobile platforms or when the zoom level is not set to the default. I also made the tests for stretchy operators more reliable and as a consequence, Gecko lost two points: the new score is 60/100. I still need to review and describe the tests and hope I won't find more mistakes.

Finally, I also added a MathML Acid1 test. It does not really look like the "classical" Acid1 test and is not "automated", in the sense that a reader must carefully (and in a subjective way) check the basic requirements. But at least it provides a small test in the spirit of CSS Acid 1: all 100%-conformant HTML 5 agents should be able to render these very elementary MathML expressions. Note that the formulas in the MathML Acid1 test are supposed to express mathematical properties of boxes from the CSS Acid1 test.

Much like we gain knowledge about the behavior of the physical universe via the scientific method, we gain knowledge about the behavior of our software via a system of assertion, observation, and experimentation called “testing.”

There are many things one could desire to know about a software system. It seems that most often we want to know if it actually behaves like we intended it to behave. That is, we wrote some code with a particular intention in mind, does it actually do that when we run it?

In a sense, testing software is the reverse of the traditional scientific method, where you test the universe and then use the results of that experiment to refine your hypothesis. Instead, with software, if our “experiments” (tests) don’t prove out our hypothesis (the assertions the test is making), we change the system we are testing. That is, if a test fails, it hopefully means that our software needs to be changed, not that our test needs to be changed. Sometimes we do also need to change our tests in order to properly reflect the current state of our software, though. It can seem like a frustrating and useless waste of time to do such test adjustment, but in reality it’s a natural part of this two-way scientific method–sometimes we’re learning that our tests are wrong, and sometimes our tests are telling us that our system is out of whack and needs to be repaired.

This tells us a few things about testing:

1. The purpose of a test is to deliver us knowledge about the system, and knowledge has different levels of value. For example, testing that 1 + 1 still equals two no matter what time of day it is doesn’t give us valuable knowledge. However, knowing that my code still works despite possible breaking changes in APIs I depend on could be very useful, depending on the context. In general, one must know what knowledge one desires before one can create an effective and useful test, and then must judge the value of that information appropriately to understand where to put time and effort into testing.
2. Given that we want to know something, in order for a test to be a test, it must be asserting something and then informing us about that assertion. Human testers can make qualitative assertions, such as whether or not a color is attractive. But automated tests must make assertions that computers can reliably make, which usually means asserting that some specific quantitative statement is true or false. We are trying to learn something about the system by running the test–whether the assertion is true or false is the knowledge we are gaining. A test without an assertion is not a test.
3. Every test has certain boundaries as an inherent part of its definition. Much like you couldn’t design a single experiment to prove all the theories and laws of physics, it would be prohibitively difficult to design a single test that actually validated all the behaviors of any complex software system at once. If it seems that you have made such a test, most likely you’ve combined many tests into one and those tests should be split apart. When designing a test, you should know what it is actually testing and what it is not testing.
4. Every test has a set of assumptions built into it, which it relies on in order to be effective within its boundaries. For example, if you are testing something that relies on access to a database, your test might make the assumption that the database is up and running (because some other test has already checked that that part of the code works). If the database is not up and running, then the test neither passes nor fails–it instead provides you no knowledge at all. This tells us that all tests have at least three results–pass, fail, and unknown. Tests with an “unknown” result must not say that they failed–otherwise they are claiming to give us knowledge when in fact they are not.
5. Because of these boundaries and assumptions, we need to design our suite of tests in such a way that the full set, when combined, actually gives us all of the knowledge we want to gain. That is, each individual test only gives us knowledge within its boundaries and assumptions, so how do we overlap those boundaries so that they reliably inform us about the real behavior of the entire system? The answer to this question may also affect the design of the software system being tested, as some designs are harder to completely test than others.

This last point leads us into the many methods of testing being practiced today, in particular end to end testing, integration testing, and unit testing.

End to End Testing

“End to end” testing is where you make an assertion that involves one complete “path” through the logic of the system. That is, you start up the whole system, perform some action at the entry point of user input, and check the result that the system produces. You don’t care how things work internally to accomplish this goal, you just care about the input and result. That is generally true for all tests, but here we’re testing at the outermost point of input into the system and checking the outermost result that it produces, only.

An example end to end test for creating a user account in a typical web application would be to start up a web server, a database, and a web browser, and use the web browser to actually load the account creation web page, fill it in, and submit it. Then you would assert that the resulting page somehow tells us the account was created successfully.

The idea behind end to end testing is that we gain fully accurate knowledge about our assertions because we are testing a system that is as close to “real” and “complete” as possible. All of its interactions and all of its complexity along the path we are testing are covered by the test.

The problem of using only end to end testing is that it makes it very difficult to actually get all of the knowledge about the system that we might desire. In any complex software system, the number of interacting components and the combinatorial explosion of paths through the code make it difficult or impossible to actually cover all the paths and make all the assertions we want to make.

It can also be difficult to maintain end to end tests, as small changes in the system’s internals lead to many changes in the tests.

End to end tests are valuable, particularly as an initial stopgap for a system that entirely lacks tests. They are also good as sanity checks that your whole system behaves properly when put together. They have an important place in a test suite, but they are not, by themselves, a good long-term solution for gaining full knowledge of a complex system.

If a system is designed in such a way that it can only be tested via end-to-end tests, that is a symptom of broad architectural problems in the code. These issues should be addressed through refactoring until one of the other testing methods can be used.

Integration Testing

This is where you take two or more full “components” of a system and specifically test how they behave when “put together.” A component could be a code module, a library that your system depends on, a remote service that provides you data–essentially any part of the system that can be conceptually isolated from the rest of the system.

For example, in a web application where creating an account sends the new user an email, one might have a test that runs the account creation code (without going through a web page, just exercising the code directly) and checks that an email was sent. Or one might have a test that checks that account creation succeeds when one is using a real database–that “integrates” account creation and the database. Basically this is any test that is explicitly checking that two or more components behave properly when used together.

Compared to end to end testing, integration testing involves a bit more isolation of components as opposed to just running a test on the whole system as a “black box.”

Integration testing doesn’t suffer as badly from the combinatorial explosion of test paths that end to end testing faces, particularly when the components being tested are simple and thus their interactions are simple. If two components are hard to integration test due to the complexity of their interactions, this indicates that perhaps one or both of them should be refactored for simplicity.

Integration testing is also usually not a sufficient testing methodology on its own, as doing an analysis of an entire system purely through the interactions of components means that one must test a very large number of interactions in order to have a full picture of the system’s behavior. There is also a maintenance burden with integration testing similar to end to end testing, though not as bad–when one makes a small change in one component’s behavior, one might have to then update the tests for all the other components that interact with it.

Unit Testing

This is where you take one component alone and test that it behaves properly. In our account creation example, we could have a series of unit tests for the account creation code, a separate series of unit tests for the email sending code, a separate series of unit tests for the web page where users fill in their account information, and so on.

Unit testing is most valuable when you have a component that presents strong guarantees to the world outside of itself and you want to validate those guarantees. For example, a function’s documentation says that it will return the number “1? if passed the parameter “0.” A unit test would pass this function the parameter “0? and assert that it returned the number “1.” It would not check how the code inside of the component behaved–it would only check that the function’s guarantees were met.

Usually, a unit test is testing one behavior of one function in one class/module. One creates a set of unit tests for a class/module that, when you run them all, cover all behavior that you want to verify in that module. This almost always means testing only the public API of the system, though–unit tests should be testing the behavior of the component, not its implementation.

Theoretically, if all components of the system fully define their behavior in documentation, then by testing that each component is living up to its documented behavior, you are in fact testing all possible behaviors of the entire system. When you change the behavior of one component, you only have to update a minimal set of tests around that component.

Obviously, unit testing works best when the system’s components are reasonably separate and are simple enough that it’s possible to fully define their behavior.

It is often true that if you cannot fully unit test a system, but instead have to do integration testing or end to end testing to verify behavior, some design change to the system is needed. (For example, components of the system may be too entangled and may need more isolation from each other.) Theoretically, if a system were well-isolated and had guarantees for all of the behavior of every function in the system, then no integration testing or end to end testing would be necessary. Reality is often a little different, though.

Reality

In reality, there is a scale of testing that has infinite stages between Unit Testing and End to End testing. Sometimes you’re a bit between unit testing and integration testing. Sometimes your test falls somewhere between an integration test and an end to end test. Real systems usually require all sorts of tests along this scale in order to understand their behavior reliably.

For example, sometimes you’re testing only one part of the system but its internals depend on other parts of the system, so you’re implicitly testing those too. This doesn’t make your test an Integration Test, it just makes it a unit test that is also testing other internal components implicitly–slightly larger than a unit test, and slightly smaller than an integration test. In fact, this is the sort of testing that is often the most effective.

Fakes

Some people believe that in order to do true “unit testing” you must write code in your tests that isolates the component you are testing from every other component in the system–even that component’s internal dependencies. Some even believe that this “true unit testing” is the holy grail that all testing should aspire to. This approach is often misguided, for the following reasons:

• One advantage of having tests for individual components is that when the system changes, you have to update fewer unit tests than you have to update with integration tests or end to end tests. If you make your tests more complex in order to isolate the component under test, that complexity could defeat this advantage, because you’re adding more test code that has to be kept up to date anyway.

  For example, imagine you want to test an email sending module that takes an object representing a user of the system, and an sends email to that user. You could invent a “fake” user object–a completely separate class–just for your test, out of the belief that you should be “just testing the email sending code and not the user code.” But then when the real User class changes its behavior, you have to update the behavior of the fake User class–and a developer might even forget to do this, making your email sending test now invalid because its assumptions (the behavior of the User object) are invalid.

• The relationships between a component and its internal dependencies are often complex, and if you’re not testing its real dependencies, you might not be testing its real behavior. This sometimes happens when developers fail to keep “fake” objects in sync with real objects, but it can also happen via failing to make a “fake” object as genuinely complex and full-featured as the “real” object.

  For example, in our email sending example above, what if real users could have seven different formats of username but the fake object only had one format, and this affected the way email sending worked? (Or worse, what if this didn’t affect email sending behavior when the test was originally written, but it did affect email sending behavior a year later and nobody noticed that they had to update the test?) Sure, you could update the fake object to have equal complexity, but then you’re adding even more of a maintenance burden for the fake object.

• Having to add too many “fake” objects to a test indicates that there is a design problem with the system that should be addressed in the code of the system instead of being “worked around” in the tests. For example, it could be that components are too entangled–the rules of “what is allowed to depend on what” or “what are the layers of the system” might not be well-defined enough.

In general, it is not bad to have “overlap” between tests. That is, you have a test for the public APIs of the User code, and you have a test for the public APIs of the email sending code. The email sending code uses real User objects and thus also does a small bit of implicit “testing” on the User objects, but that overlap is okay. It’s better to have overlap than to miss areas that you want to test.

Isolation via “fakes” is sometimes useful, though. One has to make a judgment call and be aware of the trade-offs above, attempting to mitigate them as much as possible via the design of your “fake” instances. In particular, fakes are worthwhile to add two properties to a test–determinism and speed.

Determinism

If nothing about the system or its environment changes, then the result of a test should not change. If a test is passing on my system today but failing tomorrow even though I haven’t changed the system, then that test is unreliable. In fact, it is invalid as a test because its “failures” are not really failures–they’re an “unknown” result disguised as knowledge. We say that such tests are “flaky” or “non-deterministic.”

Some aspects of a system are genuinely non-deterministic. For example, you might generate a random string based on the time of day, and then show that string on a web page. In order to test this reliably, you would need two tests:

1. A test that uses the random-string generation code over and over to make sure that it properly generates random strings.
2. A test for the web page that uses a fake random-string generator that always returns the same string, so that the web page test is deterministic.

Of course, you would only need the fake in that second test if verifying the exact string in the web page was an important assertion. It’s not that everything about a test needs to be deterministic–it’s that the assertions it is making need to always be true or always be false if the system itself hasn’t changed. If you weren’t asserting anything about the string, the size of the web page, etc. then you would not need to make the string generation deterministic.

Speed

One of the most important uses of tests is that developers run them while they are editing code, to see if the new code they’ve written is actually working. As tests become slower, they become less and less useful for this purpose. Or developers continue to use them but start writing code more and more slowly because they keep having to wait for the tests to finish.

In general, a test suite should not take so long that a developer becomes distracted from their work and loses focus while they wait for it to complete. Existing research indicates this takes somewhere between 2 and 30 seconds for most developers. Thus, a test suite used by developers during code editing should take roughly that length of time to run. It might be okay for it to take a few minutes, but that wouldn’t be ideal. It would definitely not be okay for it to take ten minutes, under most circumstances.

There are other reasons to have fast tests beyond just the developer’s code editing cycle. At the extreme, slow tests can become completely useless if they only deliver their result after it is needed. For example, imagine a test that took so long, you only got the result after you had already released the product to users. Slow tests affect lots of processes in a software engineering organization–it’s simplest for them just to be fast.

Sometimes there is some behavior that is inherently slow in a test. For example, reading a large file off of a disk. It can be okay to make a test “fake” out this slow behavior–for example, by having the large file in memory instead of on the disk. Like with all fakes, it is important to understand how this affects the validity of your test and how you will maintain this fake behavior properly over time.

It is sometimes also useful to have an extra suite of “slow” tests that aren’t run by developers while they edit code, but are run by an automated system after code has been checked in to the version control system, or run by a developer right before they check in their code. That way you get the advantage of a fast test suite that developers can use while editing, but also the more-complete testing of real system behavior even if testing that behavior is slow.

Coverage

There are tools that run a test suite and then tell you which lines of system code actually got run by the tests. They say that this tells you the “test coverage” of the system. These can be useful tools, but it is important to remember that they don’t tell you if those lines were actually tested, they only tell you that those lines of code were run. If there is no assertion about the behavior of that code, then it was never actually tested.

Overall

There are many ways to gain knowledge about a system, and testing is just one of them. We could also read its code, look at its documentation, talk to its developers, etc., and each of these would give us a belief about how the system behaves. However, testing validates our beliefs, and thus is particularly important out of all of these methods.

The overall goal of testing is to gain valid knowledge about the system. This goal overrides all other principles of testing–any testing method is valid as long as it produces that result. However, some testing methods are more efficient–they make it easier to create and maintain tests which produce all the information we desire. These methods should be understood and used appropriately, as your judgment dictates and as they apply to the specific system you’re testing.

-Max

Comments: 1

Today we officially kicked off #teachtheweb, a massive open online course (“MOOC”) dedicated to helping people teach the web. It’s convening nearly 3,000 participants to share their practice, teaching materials and to learn and hack on the way.

A huge shout-out goes to Laura Hilliger, fellow MOOC conspirator, for her leadership and savvy to pull this together! And to the Webmaker Mentor team for the wisdom and support.

Here are a few lessons from the course worth highlighting so far.

The Makes

We’re firm believers that you learn best by making.

That’s why there’s no formal instruction or lecturing in this course. Instead, each week we share a prompt that you can respond to with a “make”.

To start, we invited participants to:

Introduce yourself Webmaker style by using Popcorn Maker, Thimble or the X-Ray Goggles and share your make with #teachtheweb.

Already there are loads of great hacks from the community. And in this way, people both learn how to use the tools and mess around with code, and they can also express themselves creatively while getting to know one another.

Check out some of them:

The Study Groups

The other thing about MOOCs is that they are massive. And fire-hose-y. There’s a lot of information on a lot of channels with a lot of people.

So one way we’re mitigating that is with study groups.

Groups are formed based on:

• interests: like toymaking, libraries, or mobile HTML
• language: like French, German and Spanish
• geography: like Webmakers in the UK, Indonesia, and the Balkans.

We also encourage people to organize physical meet-ups, so they can connect with fellow learners and build a local network.

And if they don’t see a group on a topic they care about, it’s all hackable. So they can go in and add one!

The Chatter

The communication channels of the MOOC can be quite overwhelming. We’re trying to meet people where they are, while also playing to the strengths of different tools.

So far, the most important channels are:

• the Google Plus community
• the #teachtheweb hashtag on Twitter
• and the Teach the Web website itself

We made this diagram to help explain how the channels work together and definitely welcome feedback on how to improve them!

The Super Mentors

The people that really make this course run are the Webmaker Super Mentors.

These are passionate people experienced in teaching the web, running events and/or creating teaching materials.

The Super Mentors are:

• shaping the course each week by developing and giving feedback on the curriculum
• leading study groups and surfacing great makes and conversations for the larger group
• providing tech support
• and in general being warm and friendly faces in the course

It’s been so inspiring working with these 90+ Super Mentors so far. It feels like they’re really the heart and soul of Webmaker.

Keep Learning

As a MOOC facilitator, I’m really learning a lot about helping people online and encouraging learning & making. Simplification is key, as is emphasizing how the experience is flexible and adaptable to participants’ needs.

I’m also keen to learn from legendary MOOC facilitators like Philipp Schmidt and Mitch Resnick from MIT’s Learning Creative Learning and other online learning experiences like #etmooc.

If you’re interested in joining the #teachtheweb experiment, hop onto our G+ community and follow the #teachtheweb hashtag!

• Understanding a DDoS attack with Pong — Vice Magazine’s Motherboard helps you visualize a denial of service attack works. Interesting visual analogies of how the web works.
• new Art, Copy & Code film– great example of “web-made movies” / “web-native cinema” / “social video.” It gathers data like time, location, weather and what’s happening on the web — then weaves them into a video that’s unique every time.

• “Reading the New York Times and Responding in Code” — this NYT education blog post walks educators how to use Webmaker tools for creative writing and media literacy.
• Chad Sansing’s “#teachtheweb: on becoming a webmaker” –  a Virginia teacher and leader with the National Writing Project’s journey with coding, teaching and Webmaker.
• “Why I Code”: A young student’s perspective on why coding helps him relax, and the pride and pleasure of problem-solving.

Coding. It’s a new language that opens many windows. Coding is the ability to manipulate electronic and invisible things to do what you want them to do. It is the equivalent to communication with a friend.  –Amir

• Here is Today — Simple and beautiful data visualization, putting your day into epic context. Like Powers of Ten for time.
• The Build — Great personal storytelling. These bike-makers make the transition from website into film totally seamless.
• Churnalism – Spot plagiarism or questionable sources in your media diet. Just plug in text or a URL, and this checker will look to see how much of the article is ripped from another source — and what source it’s ripped from.

• Meta-piracy inception. What happens when pirates play a game development simulator and then go bankrupt because of piracy?
  
• Boards of Canada code puzzle. Like an easter egg math or code puzzle. More context and latest developments here.
• Is it worth the time? This handy chart helps you decide.

• Red Panda Gymnast – Red Pandas are also known as “Firefoxes,” so we have a soft spot for them. This one does 300 pull-ups a day.
• The lost city of Heracleion — the discovery of an entire city sunk beneath the waves. Doesn’t have much to do with the web, but the photos are amazing.

I had an opportunity to be a reviewer of a new book about Firebug written by Chandan Luthra. This is actually the second book dedicated to Firebug and so, you might also be interested in the first one.


The book is labeled Instant Firebug Starter
Monitor, edit, and debug any web page in real time with this handy practical guide.

Instant Firebug Starter is a practical, hands-on guide that provides you with a number of clear step-by-step exercises to help you take advantage of the full power that Firebug offers. This book will give you a great grounding in using Firebug to debug, fix, and optimize your web pages.

The book starts with an introduction to the Firebug world, explaining what the tool is for and continues with a description how to successfully install Firebug into your browser. All you need to know if you want to get started with Firebug and tune your web site to perfection.

The next part of the book explains basics of Firebug user interface and gives you an overview of all the panels in Firebug. This is great even for those who have basic understanding of web development and Firebug.

The last part of the book is the most interesting and I believe useful even for advanced web developers and Firebug users. It covers top 17 features you'll want to know about. This is great place to learn some tips & tricks about HTML inspection, editing as well as AJAX debugging or page load performance monitoring.

If you are just starting out with web development and looking to improve your site with Firebug, then this guide is for you. If you have a basic understanding of web development then this guide is easy to follow and will benefit your site no end.

If it sounds interesting, just go ahead and learn new stuff !

1 year ago, I started a spreadsheet. For 9 months we’d been rewriting Firefox for Android from the ground up, and on May 16, 2012 we released the first beta version to the Android market. I started a spreadsheet to track our star rating. I was nervous.

9 months of rewrite. In web time— in mobile web time— that’s years. Rewrites are almost always the wrong call. You get to throw away bad code, but you throw away good code, too. Hard won, battle-hardened fixes are expensive to throw away, and the code is never cleanly labelled “baby” and “bathwater.” The decision to rewrite Firefox was one of the loudest weeks I’ve had. Even once we’d decided, my hand hovered over the send key for a long time.

3.5 stars. We didn’t pull the old version from the market during the rewrite. We wanted to keep those users safe with regular security updates; that meant keeping the product online. It meant taking black eyes every day from users who tried us, who loved us for our desktop product, and who were disappointed. And because the Android rating system rounds, our already painful 3.7-star rating rounded down to 3.5. We were dead last.

7:1. If you want to maintain a 4.5 star rating, it takes seven 5-star reviews to counteract each 1-star review. Star ratings are deeply flawed for all kinds of reasons: selection bias, survivorship bias, false dilemmas, unidimensionality, reporting bias, et cetera. I know this. And still I watched them. When you try to reach people through an app store, your star rating is the first assessment of your product they’ll see. And when you try to make something great, reviews are real pieces of feedback from real human beings and they are painful and they are frustrating and they are golden.

1181 reviews in the first week. 588 of them were 5-stars. 105 of them were 1-star. I argued with my screen over 1-star comments about bugs we had already fixed. I swooned at 5-star reviews that said they were reversing earlier 1-star reviews.

6 weeks after beta, we pushed to release. By this point beta had climbed to 3.8, which rounds to 4 stars. Fists were pumped. Release sat at 3.6.

Time passed.

200,000 reviews and 6 releases later, this week, today, Firefox and Beta both show 4.5 (rounded) stars in the market and the team is still going strong. I’m immensely proud of the work they’ve done. It’s made me reflective and maybe a bit wordy. I want to have some profound and pithy lesson to separate then and now. Something that I can package up and hand to you. We certainly learned lessons, profound lessons, but in repeating them they sound trite:

Listen. Care about what people think. Be hungry for feedback. Don’t work forward from the tech you have to the product you can build; work backward from the product your users deserve to the tech you’ll need to get there. Ask for help, and accept it even when it hurts to admit that you need it. Don’t throw things away lightly, but be able to throw them away in those rare cases where it’s necessary. Surround yourself with the most excellent people you can find. That one helps a lot.

The haters will say I over-focus on star ratings. There are certainly lots of other good things to measure, and lots of bad things to say about stars. But the stars abide. They are inescapable. They sit front and center in your primary distribution channel. Those five little stars. And I believe they do say something about what we’ve built.

Building good things is hard and my hat is off to anyone who earnestly tries. If the good thing you build reaches people through an app store, I want you to know that I know how you feel. And I’m rooting for you.

[I posted a version of this post on Medium, because it's fun to try new things.]

Slashdot.org is featuring an interview I did with the Slashdot TV folks at LinuxFest Northwest 2013 where I had an opportunity to discuss Firefox OS and why it has a great chance at slapping down the mobile duopoly that’s currently got mobile users trapped. You can read the post and watch the video right here.

One common question I was asked at LFNW was what I thought of Ubuntu Touch and how will is stack up to Firefox OS. I simply think that Firefox OS will be good for a certain audience and that Ubuntu Touch also has the potential to cater to its own audience much like iOS and Android currently do. More open source platforms are always good especially when it means disrupting a tightly held market like mobile.

You may recall a month and a half ago I posted Notes on the Cross-Platform Availability of Header Files and then promptly had to take most of it down because it was insufficiently researched. Well, the research is ongoing, but I’ve got a shiny new set of results, some high-level conclusions, and several ways Viewers Like You can help!

First, the high-level conclusions:

• Except perhaps in deeply-embedded environments, all of C89’s library is universally available.
• Code not intended to run on Windows can also assume most of C99 and much of POSIX. The less-ubiquitous headers from these categories are also the less-useful headers.
• Code that is intended to run on Windows should only use C89 headers and <stdint.h>. If MSVC 2008 support is required, not even <stdint.h> can be used. (Windows compilers do provide a small handful of POSIX headers, but they do not contain the expected set of declarations!)
• Many different Unix variants ship a similar set of nonstandard headers. We don’t yet know whether the contents of these headers are reliable cross-platform.
• There is a large set of obsolete headers that are still widespread but should not be used in new code. This is underdocumented.

The full results may be seen here: http://hacks.owlfolio.org/header-survey/
The raw data is here: https://github.com/zackw/header-survey/

If you want to help, we need more inventories (especially for OSes further from the beaten path), and I’m also very interested in improvements to the giant generated HTML table. Y’all on Planet Mozilla can probably tell I’m not a Web designer. If you are an old beard, there are also places where I’m not entirely sure of my methodology – see the README in the source repo.

I’ve noticed that most Mozilla developers are using recent laptops with fast SSDs for their work. This observation shouldn’t be surprising, as developers tend to be tech enthusiasts with higher requirements, but I wonder if these fast machines could also be masking some of the performance problems in the code we write?

We’ve known for a while that I/O operations on the main thread are a major source of Firefox jank, but I think we sometimes under-estimate the urgency of refactoring the remaining sources of main-thread I/O. While Firefox might feel fast on powerful hardware, I believe a significant share of our users are still using relatively old hardware. For example Firefox Health Report data shows that 73.5% of our more-technically-inclined Beta users (Release channel data not yet available) are on a computer with 1 or 2 cores, including hyper-threaded cores.

Even when users are on modern machines, their storage systems might be slow because of hardware problems, I/O contention, data fragmentation, Firefox profiles/binaries being accessed over a network share, power-saving settings, slow laptop hard-drives, and so on. I think it would be beneficial to test certain types of code changes against slow storage by running Firefox from a network share, an SD card, or some other consistently slow I/O device.

The Experiment

As an experiment to see what it’s like to run Firefox when I/O is consistently slow, I decided to create a Firefox profile on an SD card and surfed the web for a couple of hours, capturing profiles of jank along the way. I used an SD card which advertised maximum transfer rates of 20MB/s for  reads and 15MB/s for writes, although in practice, large transfers to and from the card peaked around 10MB/s. For reference, my mechanical hard drive performs the same operations an order of magnitude faster. I left the Firefox binaries on my hard drive — I was more interested in the impact of I/O operations that could be re-factored than the impact of Firefox code size.

As I visited pages to set up the new Firefox profile with my usual customizations (extensions, pinned tabs, etc), I observed regular severe jank at every step. After entering the URL of a new site and hitting Enter, Firefox would become unresponsive and Windows would mark it as “Not Responding”. After about 5 seconds, it would start handling events again. Profiles showed that the network cache (currently being re-designed) was the most common source of these hangs. I also hit noticeable jank from other I/O bottlenecks when I performed common actions such as entering data into forms, logging into sites, downloading files, bookmarking pages, etc. Most of these issues are being worked on already, and I’m hopeful that this experiment will produce very different results in 6 months.

This is a screen recording of a simple 5-minute browsing session. The janks shown in the video are usually absent when the profile is stored on my hard drive instead. You’ll need to listen to the audio to get all the details.

Observations

The following is a selection of some of the I/O bottlenecks I encountered during my brief & unrepresentative browsing sessions with this profile.

1) Initializing a new profile takes a very long time. After first launch, even with the application binaries in the disk cache, Firefox did not paint anything for 20 seconds. It took an additional 5 seconds to show the “Welcome to Firefox” page. The “Slow SQL” section of about:telemetry showed ~40 SQL statements creating tables, indexes and views, with many taking multiple seconds each. To the best of my knowledge, there hasn’t been much research into improving profile-creation time recently. We discussed packing pre-generated databases into omni.jar a year ago (bug 699615).

2) Installing extensions is janky. The new extension’s data is inserted into the addons.sqlite and extensions.sqlite DBs on the main thread. An equal amount of time is spent storing the downloaded XPI in the HTTP cache. See profile here. Surprisingly, the URL classifier also calls into the HTTP cache, triggering jank.

3) The AwesomeBar is pretty janky at first. It seems the Places DB gets cloned several times on the main thread.

4) Unsurprisingly, startup & shutdown are slower, especially if the Add-on Manager has to update extension DBs or if extensions need to do extra initialization or cleanup. For example, AdBlock triggers main-thread I/O shortly after startup by loading the AdBlock icon from its XPI into the browser toolbar.

5) New bugs/bugs needing attention:

• The URL classifier opens/writes/closes “urlclassifierkey3.txt” on the main thread. Filed bug 867776
• The cookie DB is closed on the main-thread after being read into memory. Filed bug 867798
• The startupCache file might be another good candidate for read-ahead. Filed bug 867804
• bug 818725: localStore.rdf is fsync’ed on the main thread during GC . Not completely new, but this bug could use some attention
• bug 789945: Preferences are flushed & fsynced on the main thread several times during a session and they can cause noticeable jank. They also show up frequently in chrome hangs.
• bug 833545: Telemetry eagerly loads saved pings on the main thread

6) Known issues observed during browsing:

• Network cache creates a ton of jank when storage is slow/contended
• Password Manager, Form History, Places and Download Manager do main-thread I/O
• SQLite DBs cause jank when opened on the main-thread
• Font loading causes jank

At the 2013 Game Developers’ Conference, Alon and I from Mozilla and Josh Adams from Epic Games presented a talk called “Fast and Awesome HTML5 Games”. We surprised people by showing off Unreal Engine 3 running in Firefox — compiled from C++ source with Emscripten, running smoothly and efficiently. Today, Epic is making the Epic Citadel demo available, so that you can try it out for yourself.

For best results, it needs a recent Firefox Nightly (Firefox 23 or better). However, because the core technologies are just standard web technologies, it will run in Firefox 20 (the current released version) — but with some performance degradation and a lack of Web Audio-dependant audio effects. We’ve had success in running it in other browsers, but it’s somewhat hit and miss – it heavily depends on the quality of the WebGL implementation, memory management, and JavaScript engine. Now that the demo is available, we expect that they will fix any remaining issues quickly.

Here’s a video (1080p!) of both the Epic Citadel demo, as well as some gameplay footage from the unreleased “Sanctuary” demo:

Goals

Working with Epic helped us prove that the Emscripten approach was viable even for large, performance-intensive codebases. We also wanted to demonstrate that with Emscripten, the web becomes just another porting and build target that integrates nicely in existing frameworks. During the week working with Epic to build the demo, we went from things failing to compile to shooting bots in a UT3 level. Having an early build of an asm.js-enabled Firefox (with Odinmonkey) got us the performance boost we needed to hit great frame rates and a very playable experience.

Technical and Porting Details

The engine is compiled down to 60MB of minified asm.js-flavoured JavaScript. This is a large chunk of JS for browsers to digest. Initially, our parse and compile time was close to 40-45s, which is not a great experience. Thanks to some efforts by Nick Nethercote, Sean Stangl, and others, that’s down to around 10s currently. (less on some hardware, highly dependant on CPU speed.) The work to improve parsing and compilation of this large codebase also translated into gains on more normal JS workloads as well. We have plans in progress to reduce this further by doing a custom parser for asm.js, as well as enable compilation caching in IndexedDB.

On the platform side, this was the first big test of our new Web Audio implementation. Ehsan wrote an OpenAL-compatible wrapper that mapped to Web Audio, and this worked very well with the existing OpenAL code that was in UE. The Sanctuary demo was enhanced by adding non-full-screen pointer lock support — a web page can request pointer lock independent from fullscreen, making games that want to lock the mousepossible as part of web pages instead of needing to enter a full screen mode.

The experience really reinforced the main porting strategy that we suggest to others for getting existing content on the Web using Emscripten: make it work natively first using the same libraries that Emscripten is mapping. If you can launch the application direct from the command line, using SDL and OpenGL ES 2.0 for video, OpenAL for audio, and otherwise using pure C libraries, you should see quick results on the Web.

The Web Is The Platform

With Emscripten, the web is just another platform to target. It can be targetted alongside other platforms, with the additional development cost similar to porting to another OS. No longer does choosing to deploy on the web mean rewriting in JavaScript, and worse, continuing to maintain that JavaScript version in parallel with the native version.

Personally, it’s really exciting to get to this point a short two years since the the first WebGL specification was introduced at GDC 2011. With WebGL, Emscripten, and asm.js, the pieces really fell into place to make this possible. It’s even more exciting to be able to do this with high profile engine, known for its quality and performance. Seeing the web get to this point is pretty amazing, and I look forward to seeing what the industry does with it.

More Information

For more information, please check out the slides from our talk:

Vladimir Vuki?evi? – The Web Is Your Next Platform
Josh Adams – Unreal Engine 3 in JavaScript
Alon Zakai – Compiling C/C++ to JavaScript

Also, please visit the new Mozilla Developer’s Network Games landing page, which we’ll be expanding in the coming weeks. The Emscripten project and information about asm.js are also useful if you’d like to take a look at what it would take to port your own games or other apps.

Back in November my colleague Robert Nyman wrote about a word that annoys him. I like that. I think our day to day online conversations are full of little misunderstandings and knowing what ticks someone off or brings up weird connotations is a good thing. So I thought I should quickly write this bit here.

There is a pretty bullet-proof way to make me feel uncomfortable and not react to requests that you have and that is by calling me “Bro”. There are two people on this planet that can call me “Bro” and that is my sister and my brother and both call me “Christian”.

I don’t like “Bro”. I understand that for some this is a very normal way to talk to each other but I don’t get it.

First of all, it assumes a relationship that we just don’t have. I have quite a lot of friends and I have some very good friends (you know the ones that helped you when you were sick or show up without any questions when there are things to be done like moving flat). Friendship is something that grows, that gets earned. A bond that would warrant calling someone else a brother (or sister for that matter) that is not related to some religious lingo is something that so does not happen by using the same social media channel or commenting on the same pull request thread. Someone calling me “Bro” out of the blue makes me twitch and reminds me of the fake friendliness the bazaar salesperson shows when asking you to “want to look at my carpets, friend?”.

Secondly when I hear “Bro”, I have in my head the caricature of a beercan-on-forehead-crushing frat boy jock who is boisterously shouting about how awesome all his bros are and that they come “before hos”. I never went through university and the mere concept of fraternities and sororities is beyond me. It seems so fake and artificial and with its initiation and hazing rituals flat out creepy. Where I grew up we used to have (and still have) student organisations that have sword-fighting as the initiation rites and you might have seen old German men of power with scars in their faces. That is where that came from. All of these smack of nationalism and old-school class systems, all of which things I don’t get and that make me feel uncomfortable.

So in short, every time someone calls me “Bro”, I lose a bit of respect – subconsciously. Maybe that is something I should work on. But seriously, I think the whole “Bro” culture is outdated and seeing the effects of it in mainstream media scandals and “Brogrammer culture” is something we shouldn’t support but actually move away from. So, sorry, but #nobro from me.

True story: I recently wanted to return an order from Zappos and found myself using their web-based online chat to sort out some details. Upon verifying my shipping address (which is ? Mozilla) the Zappos employee mentioned to me that she loves Mozilla, that she's using Firefox essentially forever and that we just rule!

I thought it was a wonderful example of how Mozilla, through our technology and who we are, what we stand for and how we show up for your users, are truly unique in the world of technology.

<3

At LinuxFest Northwest last weekend I had an opportunity to sit down with a number of folks and do interviews and talk about everything from Firefox OS to Ubuntu Touch. I have grown really fond of Linux Action Show and it was great to sit down with these guys and talk shop.

If you are viewing this post from a Planet please click here to watch on YouTube and don’t forget to subscribe to their show here.

My colleague Matt Thompson wrote an update on the Hackable Kits. Go check it out: http://openmatt.org/2013/04/30/hackable_kits/This work has been evolving for a while. Check out these actually related articles: Related articles

• Hacktivity Kits != Event Agenda, but they sure are close...
• 1-Pagers and Contributing
• Hacktivity Kits and Modular Curriculum
• All the posts where I use the word "hacktivity"

It has been a while since we did not give news about what was going on in the French speaking Mozilla community. Simply because so many things happened and because of that I did not have the time to write!

But don’t worry, I am not going into the details for everything (this is actually coming during the next months), I will give you a glance at what we were working on since January.

Then I know that some of you could – during these 3 months – follow the continuous news around Mozilla via these streams:

-        Identica: http://identi.ca/mozillazinefr

-        Twitter: http://twitter.com/MozillaZineFr

From www.MozillaZine-fr.org, thanks to the fantastical and relentless Pierre (Mozinet) who is the best for gathering every single piece of information from everywhere! Our preciouss

Since I have the chance now, please find again its essential retrospective of 2012: http://www.mozillazine-fr.org/archive.phtml?article=28569f

 

• So, what’s new?

First of all: welcome to Jesus, Nigel, Darkkow, Marmoute, AxelR, Cédric Valmary, Rémi Caillot, Maxime Ronceray, Benjamin Bernard, Sphinx,  angezanetti,  Macadam, Sadouanouan, Idriss, Abdelsan and every one else I am sure to forget! (Apologies, I will catch up next month!)

And, hold tight: two countries just joined the French speaking community

-        The Burkina Faso: Sadouanouan Malo and Idriss Tinto contacted us and are more than motivated to create one Mozilla community in this beautiful country. Sadouanouan is a professor and is currently working with Yoric to determine some bugs which he will be able to give to his students. Idriss is a computer science engineer, he is also in touch with Clarista and gerard-majax – our mediator here, thanks to him, a new community is being born. Together, they are thinking about how to set up a first event to found the community. Now, they already got their Mozillian’s profiles:  https://mozillians.org/en-US/u/sadouanouan/ and https://mozillians.org/en-US/u/titinto/ .

-        The Chad: thanks to Chahrawoods, we are now communicating with Abdelsalam Safi, a member of the ADIL (www.adil.td) whose goal is to promote the use of free software in Chad and thinks about creating the first Mozilla community in its country. What a good idea! We are teaming up with Chahrawoods and without any doubt, you will hear from us very soon. First things first: Abdelsalam is also officially a Mozillian: https://mozillians.org/en-US/u/abdelsalam.safi/ . Of course, both Burkina Faso and Chad can count on our indispensable Camara, leader for the Mozilla Senegal community and coordinator for the whole French speaking Western Africa to help and support.

Another event: Firefox is now localized in a new language! Cédric Valmary, newcomer, is working relentlessly so that our favorite browser works in occitan -a mailing list has actually been created for this specific topic:  http://mozfr.org/mailman/listinfo/occitan ).

 

• The events of the last quarter
  

• You will have notice that, in January, the entire world celebrated Firefox OS with some hackathons. French speaking Mozilla has, of course, done the same.

Mozilla Sénégal has been the first ones to past the post on the 19th of January in Dakar: https://reps.mozilla.org/e/dakar-firefoxos-appday/  and http://www.osiris.sn/Dakar-Firefox-OS-APP-Day-19.html  . One particularity was that, in addition to create apps and accompany developers, Niang did a Firefox Clinic on Thunderbird: his speciality.

In Paris  (https://reps.mozilla.org/e/paris-firefoxos-hackathon/), the hackathon took place during the week-end of the 26th of January. The Gaia team from Paris made several conferences during Saturday’s morning to explain to the numerous developers that were here what were the basics to create web apps for Firefox OS (performances, design with the very convenient Building Blocks (http://buildingfirefoxos.com/ ), responsive design, which web API were ready to be used starting from now, etc.). Not to forget Tristan who motivated everyone and reminded the interest of applications using open web technologies. During the afternoon, after having eaten well among geeks, participants created groups in rooms to start the real thing: intensive programming for everyone, with the help of the Gaia developers if needed. (A lot of questions were especially about the systemXHR API and the web activities.) The real good atmosphere was rewarding and no more than 36 applications for Firefox OS were created in Paris this day.

If these days were successfull, it was largely thanks to Anne-Marie Bourcier, who put all of her energy and experience in organizing the event. She was our fairy godmother and we will all be eternally grateful for this.

I would also invite you to read the proceedings of Kinouchou: http://kinouchou.org/dotcl/index.php?post/2013/01/28/Firefox-OS-App-Days and http://kinouchou.org/dotcl/index.php?post/2013-01-15-Firefox-OS

And here are the pictures that Tristan took: http://www.flickr.com/photos/nitot/sets/72157632623533104/with/8427177048/

One should also note that, in order to prepare this day, Pierre-Louis, FredB and Clochix added French subtitles on the videos about FirefoxOS. You can find these videos and all the useful links about FxOS on this Wiki page : http://wiki.mozfr.org/Paris_FirefoxOS_App_Days.

Still talking about Firefox, Geekshadow translated a FAQ on Firefox OS that was initiated by Mozilla. He then added this FAQ in our Wiki page for « frequent questions »: http://wiki.mozfr.org/Questions_fr%C3%A9quentes. Thanks Antoine!

• In February, like every year since 2003, Mozilla took part in Fosdem. The Fosdem (for Free and Open Source Software Developers’ European Meeting) is simply one of the best event about FOSS in Europe: this is the place to be to know everything about FOSS development, to meet experts… and have fun!

Thus, the Fosdem took place during the first week-end of February in Brussels (Belgium), and amazing city with the best French fries of the world. Concerning Mozilla, this is Benoît, leader of the Belgian community, who took care of the event. Brilliant organiser, with an extreme patience, he made a marvel of this event.  He was helped by Brian King, Ioana Chiorean, Axel Hecht, Ziggy Maes, Monique Brunel, Gervase and Teoli.

Overall, Mozilla excelled with speakers from everywhere, selling out meetings in Mozilla’s room but not only. Concerning the French speaking Mozilla community, Mozilla Belgium and Mozilla France were joined by Mozilla Senegal, represented by Camara, Mozilla Algeria, represented by Majda. However, it was a great disapointment and we cannot help but curse the things that stopped Melek, Sofien and Alexandre from Mozilla Tunisia to get their visas!

You can find the slides, videos, photos and proceedings here: https://wiki.mozilla.org/Fosdem:2013:Aftermath

• On the 9th of February, Mozilla Quebec organised a Docsprint  (https://reps.mozilla.org/e/mozilla-quebec-documentation-sprint/  ) in Montreal. FredB and Fredy were pleased to welcome Eric Shepherd (a.k.a. sheppy) from MDN who is an guarantee of success! Find the photos here: http://www.flickr.com/photos/fredericbourgeon/sets/72157632736602134/ .

Canada also had two presentations of Persona in March: http://montrealpython.org/fr/2013/03/mp36/ and http://www.meetup.com/HTML5mtl/events/109129482/.

• Let’s go back to February when Mozilla Maurice followed its route and organised a new Webmaker event for the children. Ganesh and Paméla are wonderful teachers and are already thinking about going in some other schools to launch a tournament.

• On the 16th of February, the first among many events was the MozHack Install Party that Mozilla Ivory Coast organised: https://reps.mozilla.org/e/mozhack-install-party/

• On the 27th of February, Mozilla Tunisia once again showed that they have lots of good, original and really nice ideas and initiatives. Manel, part of the A-team of Womoz, gave news of its program of Webmaker Training for young handicapped:  http://mozilla-tunisia.org/programme-special-formations-webmaker-pour-des-jeunes-handicapes/ (but also : http://www.womoz.org/blog/teaching-new-web-technologies-to-children-in-a-tunisian-medico-social-educational-center/ ). This article and this program are simply wonderful. Congratulations Manel!!!

• From the 1st to the 6th March, French speaking Mozilla was proud to see Flore, Ibrahima and Ganesh taking part in the Webmaker training days in Athens: http://popcorn.webmadecontent.org/tif

They are now our Webmaker mentors and will soon be able to teach every other French speaking Reps who are willing to!

• Also on the 1st of March: strong coming back of Mozilla Ivory Coast and its enthusiast leader, Bacely Yorobi who went to EDHEC, a management school in Abidjan to present the different technologies of Mozilla.

• On the 17th of March, as part of a program named BeGeek and launched by the Mozilla Tunisia community (http://mozilla-tunisia.org/begeek-nouveau-projet-et-de-nouvelles-voies-a-explorer/  ), several members of the community went to Mjez El Beb to host a day of teaching about Web technologies. Here are the minutes: http://mozilla-tunisia.org/html5-essential-training-day/

• 23rd of March: Kinou, Nigel and Chahrawoods went to the event « Libre en fête » (http://www.libre-en-fete.net/  ) in L’Haÿ-les-Roses (yes, a place with such a name exists) to represent Mozilla. Our trio ran a stand among numerous French associations for Free Software. (http://www.parinux.org/event/2013-03-23?mini=event%2F2013-03 )

• Still on the 23rd of March, as part of a tour of schools, Mozilla Senegal stopped off in the ESTM, a computer science school in Dakar: http://wiki.mozfr.org/MozFR:Actualit%C3%A9s#UAHB_Meetup_Dakar

• The month of March ended with the celebration of the 15th birthday of Mozilla by the Ivory Coast Mozilla Community.

• Do not forget Flaburgan, who became one of our main speakers, who participates regularly at the Human Talks in Grenoble, France, to present a new Mozilla tool. The last one: Persona (http://humantalks.com/talks/64-introduction-a-persona ), and Firefox OS (http://humantalks.com/talks/111-introduction-a-firefox-os).

 

• Some noteworthy articles:
  

-        The translation of the article « An introduction to Firefox OS  for mobile developers: Q&A with Andreas Gal, Mozilla » which became « Toutes les questions sur Firefox OS… Les réponses d’Andreas Gal » thanks to Clochix, Pandark, Kazé, Goofy, Tchevalier: http://blog.mozfr.org/post/2013/02/FirefoxOS-questions-et-reponses-d-Andreas-Gal

-        The translation of the blog post from Ron Piovesan (http://ronpiovesan.com/2013/02/20/firefoxos-and-the-battle-for-the-bronze/ ), which became « FirefoxOS : en piste pour la médaille de bronze ! » from Lissyx, Kazé, Clochix, Goofy: http://blog.mozfr.org/post/2013/02/FirefoxOS-pour-la-medaille-de-bronze

-        The translation of the blog post of Andreas Gal (http://andreasgal.com/2013/01/08/why-the-web-is-going-to-win-mobile/ ), which became « Pourquoi c’est le Web qui va gagner la partie sur les mobiles » with Alice, Maxime, Goofy: http://blog.mozfr.org/post/2013/01/Pourquoi-c-est-le-Web-qui-va-gagner-la-partie-sur-les-mobiles

-        The proceedings of Mozcamp Europe 2012 in Poland from GeekShadow (better late than never!) : http://blog.geekshadow.com/lang/fr/2012/11/25/mozcamp-2012/

-        The blog post of Clarista who enjoyed her vacations in Burma, with vingtetun and seized the opportunity to meet supporters of the Free Software and who is appealing to our help now: https://claristamozilla.wordpress.com/2013/03/29/its-time-to-go-to-myanmar/

-        The translation of a blog post now entitled « Pourquoi je  retourne à Firefox » by Jeff_, biglittledragoon, Agnes, MFolschette,  Plop, Tom, Pouhiou, quack1, jtanguy, Rudloff and anonymous of Framasoft: http://www.framablog.org/index.php/post/2013/03/13/firefox-le-retour

-        The translation of the blog post of Luke Wagner (https://blog.mozilla.org/luke/2012/10/02/optimizing-javascript-variable-access/ ), which became « Optimiser les accès de variables JavaScript » with Nicolas Pierron: http://tech.mozfr.org/post/2013/02/03/Optimiser-les-acces-de-variables-JavaScript

-        The translation of the blog post of Brendan Eich (https://brendaneich.com/2013/03/mwc-2013-firefox-os-and-more-web-api-evolution/ ) which became « Firefox OS et l’évolution des API Web » thanks to Goofy: http://tech.mozfr.org/post/2013/03/11/Firefox-OS-et-les-API-Web-par-Brendan-Eich

-        An article brought to our attention by Benoît Leseul on « Les opportunités  manquées du libre, la série complète. Et pourquoi Mozilla est une  exception » of Lionel Dricot: https://plus.google.com/u/0/102072273880684402148/posts/QYtsVU6o8Gd

 

• What else?
  

« parrains Mozfr » : http://wiki.mozfr.org/ParrainsMozfr is a new system that has recently been implemented for new members. To tell you the truth, the system is still in its setting up phase and needs to be improved. We are still working on it and we shall let you know about further development. Do not hesitate to sign up!

Lastly, Transvision has not stopped its impulsive evolution from Pascal (changes by versions have been described at this page: http://transvision.mozfr.org/news/#v2.5 ), and as from now and onwards from Jesus! He has been inspired by the official theme of Mozilla to change the theme of Transvision, but the display of results has also been improved by creating an alert message for translations which seems to be abnormally long or short as compared to the original where the possibility of restoring a combination of languages/which is deposited by default via a cookie,etc.etc. Within a few months, Jesus showed himself to be indispensable to the community by providing several technical support (we need this!). In addition, he’s a cute boy! Thus, we are nominating him the Francophone Mozillian of this quarter! Jesus, you are most welcome among us! Thank you!

See you soon!

Clarista