mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

David Rajchenbach Teller: The Battle of Session Restore – Season 1 Episode 3 – All With Measure

Mozilla planet - do, 17/07/2014 - 14:34

Plot For the second time, our heroes prepared for battle. The startup of Firefox was too slow and Session Restore was one of the battle fields.

When Firefox starts, Session Restore is in charge of restoring the browser to its previous state, in case of a crash, a restart, or for the users who have configured Firefox to resume from its previous state. This entails numerous activities during startup:

  1. read sessionstore.js from disk, decode it and parse it (recall that the file is potentially several Mb large), handling errors;
  2. backup sessionstore.js in case of startup crash.
  3. create windows, tabs, frames;
  4. populate history, scroll position, forms, session cookies, session storage, etc.

It is common wisdom that Session Restore must have a large impact on Firefox startup. But before we could minimize this impact, we needed to measure it.

Benchmarking is not easy

When we first set foot on Session Restore territory, the contribution of that module to startup duration was uncharted. This was unsurprising, as this aspect of the Firefox performance effort was still quite young. To this day, we have not finished chartering startup or even Session Restore’s startup.

So how do we measure the impact of Session Restore on startup?

A first tool we use is Timeline Events, which let us determine how long it takes to reach a specific point of startup. Session Restore has had events `sessionRestoreInitialized` and `sessionRestored` for years. Unfortunately, these events did not tell us much about Session Restore itself.

The first serious attempt at measuring the impact of Session Restore on startup Performance was actually not due to the Performance team but rather to the metrics team. Indeed, data obtained through Firefox Health Report participants indicated that something wrong had happened.

Oops, something is going wrong

Indicator `d2` in the graph measures the duration between `firstPaint` (which is the instant at which we start displaying content in our windows) and `sessionRestored` (which is the instant at which we are satisfied that Session Restore has opened its first tab). While this measure is imperfect, the dip was worrying – indeed, it represented startups that lasted several seconds longer than usual.

Upon further investigation, we concluded that the performance regression was indeed due to Session Restore. While we had not planned to start optimizing the startup component of Session Restore, this battle was forced upon us. We had to recover from that regression and we had to start monitoring startup much better.

A second tool is Telemetry Histograms for measuring duration of individual operations, such as reading sessionstore.js or parsing it. We progressively added measures for most of the operations of Session Restore. While these measures are quite helpful, they are also unfortunately very unstable in real-world conditions, as they are affected both by scheduling (the operations are asynchronous), by the work load of the machine, by the actual contents of sessionstore.js, etc.

The following graph displays the average duration of reading and decoding sessionstore.js among Telemetry participants: Telemetry 4

Difference in colors represent successive versions of Firefox. As we can see, this graph is quite noisy, certainly due to the factors mentioned above (the spikes don’t correspond to any meaningful change in Firefox or Session Restore). Also, we can see a considerable increase in the duration of the read operation. This was quite surprising for us, given that this increase corresponds to the introduction of a much faster, off the main thread, reading and decoding primitive. At the time, we were stymied by this change, which did not correspond to our experience. We have now concluded that by changing the asynchronous operation used to read the file, we have simply changed the scheduling, which makes the operation appear longer, while in practice it simply does not block the rest of the startup from taking place on another thread.

One major tool was missing for our arsenal: a stable benchmark, always executed on the same machine, with the same contents of sessionstore.js, and that would let us determine more exactly (almost daily, actually) the impact of our patches upon Session Restore:Session Restore Talos

This test, based on our Talos benchmark suite, has proved both to be very stable, and to react quickly to patches that affected its performance. It measures the duration between the instant at which we start initializing Session Restore (a new event `sessionRestoreInit`) and the instant at which we start displaying the results (event `sessionRestored`).

With these measures at hand, we are now in a much better position to detect performance regressions (or improvements) to Session Restore startup, and to start actually working on optimizing it – we are now preparing to using this suite to experiment with “what if” situations to determine which levers would be most useful for such an optimization work.

Evolution of startup duration

Our first benchmark measures the time elapsed between start and stop of Session Restore if the user has requested all windows to be reopened automatically

restoreAs we can see, the performance on Linux 32 bits, Windows XP and Mac OS 10.6 is rather decreasing, while the performance on Linux 64 bits, Windows 7 and 8 and MacOS 10.8 is improving. Since the algorithm used by Session Restore upon startup is exactly the same for all platforms, and since “modern” platforms are speeding up while “old” platforms are slowing down, this suggests that the performance changes are not due to changes inside Session Restore. The origin of these changes is unclear. I suspect the influence of newer versions of the compilers or some of the external libraries we use, or perhaps new and improved (for some platforms) gfx.

Still, seeing the modern platforms speed up is good news. As of Firefox 31, any change we make that causes a slowdown of Session Restore will cause an immediate alert so that we can react immediately.

Our second benchmark measures the time elapsed if the user does not wish windows to be reopened automatically. We still need to read and parse sessionstore.js to find whether it is valid, so as to decide whether we can show the “Restore” button on about:home.

norestoreWe see peaks in Firefox 27 and Firefox 28, as well as a slight decrease of performance on Windows XP and Linux. Again, in the future, we will be able to react better to such regressions.

The influence of factors upon startup

With the help of our benchmarks, we were able to run “what if” scenarios to find out which of the data manipulated by Session Restore contributed to startup duration. We did this in a setting in which we restore windows:size-restore

and in a setting in which we do not:

size-norestore

Interestingly, increasing the size of sessionstore.js has apparently no influence on startup duration. Therefore, we do not need to optimize reading and parsing sessionstore.js. Similarly, optimizing history, cookies or form data would not gain us anything.

The single largest most expensive piece of data is the set of open windows – interestingly, this is the case even when we do not restore windows. More precisely, any optimization should target, by order of priority:

  1. the cost of opening/restoring windows;
  2. the cost of opening/restoring tabs;
  3. the cost of dealing with windows data, even when we do not restore them.
What’s next?

Now that we have information on which parts of Session Restore startup need to be optimized, the next step is to actually optimize them. Stay tuned!


Categorieën: Mozilla-nl planet

Beyond Firefox: 10 Mozilla projects fueling the open Web - InfoWorld

Nieuws verzameld via Google - do, 17/07/2014 - 12:03

Beyond Firefox: 10 Mozilla projects fueling the open Web
InfoWorld
Firefox reinvented the old-school Netscape browser, in a defining moment for Mozilla as an advocate for open Web technologies. Today, market share for Mozilla's most noteworthy project is slumping, and the luster of Firefox appears to be fading, no ...

Categorieën: Mozilla-nl planet

Mozilla krikt prestaties JPEG-format op - Automatisering Gids

Nieuws verzameld via Google - do, 17/07/2014 - 11:28

Automatisering Gids

Mozilla krikt prestaties JPEG-format op
Automatisering Gids
Mozilla wil een einde aan de zoektocht naar nieuwe formats om afbeeldingen goed over internet te sturen. De organisatie stelt een verbeterde versie van .jpg voor. Er bestaan inmiddels heel wat formats om afbeeldingen op te slaan en te transporteren.

Categorieën: Mozilla-nl planet

Marco Zehe: Quick tip: Add someone to circles on Google Plus using a screen reader

Mozilla planet - do, 17/07/2014 - 08:39

In my “WAI-ARIA for screen reader users” post in early May, I was asked by Donna to talk a bit about Google Plus. Especially, she asked how to add someone to circles. Google Plus has learned a thing or two about screen reader accessibility recently, but the fact that there is no official documentation on the Google Accessibility entry page yet suggests that people inside Google are not satisfied with the quality of Google Plus accessibility yet, or not placing a high enough priority on it. That quality, however, has improved, so adding someone to one or more circles using a screen reader is not that difficult any more.

Note that I tested the below steps with Firefox 31 Beta (out July 22) and NVDA 2014.2. Other screen reader/browser combos may vary in the way they output stuff or switch between their virtual cursor and focus/forms modes.

Here are the steps:

  1. Log into Google Plus. If you already have a profile, just go ahead and find someone. If not, create a profile and add people.
  2. The easiest way to find people is to go to the People tab. Note that these currently have no “selected” state yet, but they do have the word “active” as part of the link text.
  3. Once you found someone in the list of suggestions, find the “Add to circles” menu button, and press the Space Bar. Note that it is very important that you press Space here, not Enter!
  4. NVDA now automatically switches to focus mode. What happened is that a popup menu opened that has a list of current circles, and an item at the bottom that allows you to create a new circle on the fly. The circles themselves are checkable menu items. Use the up and down arrows to select a circle, for example Friends or Acquaintances, and press the Space Bar to add the person. The number of people in that circle will dynamically increase by one, and the state will be changing to “checked”. Likewise, if you want to remove a person from a particular circle, press Space Bar just the same. These all act like regular check boxes, and the menu stays active so you can shuffle that person around your circles as you please.
  5. At the bottom, there is a non-checkable menu item called “Add new circle”. Here, you have to press Enter. If you do this, a panel opens inside the menu, and focus lands on a text field where you can enter the name of a new circle, for example Web Developers. Press Tab to reach the Create Circle button and press Space Bar. The new circle will be added, the person you’re adding to circles will automatically be added to that circle, and you’re back in the menu of circle checkboxes.
  6. Once you’re done, press Escape twice. The first will end NVDA’s focus mode, the second will close the Add to Circles menu. Focus will land back on the button for that person, but the label will change to the name of a single circle, if you added the person to only one circle, or the label “x Circles”, where x is the number of circles you just put that person into.

The above steps also work on the menu button that you find if you opened the profile page of an individual person, not just in the list of suggested people, or any other list of people. The interaction is exactly the same.

Hope this helps you get around in Google Plus a bit more efficiently!

Categorieën: Mozilla-nl planet

Kent James: Following Wikipedia, Thunderbird Could Raise $1,600,000 in annual donations

Mozilla planet - do, 17/07/2014 - 08:31

What will it take to keep Thunderbird stable and vibrant? Although there is a dedicated, hard-working team of volunteers trying hard to keep Thunderbird alive, there has been very little progress on improvements since Mozilla drastically reduced their funding. I’ve been an advocate for some time that Thunderbird needs income to fulfill its potential, and that the best way to generate that income would be to appeal directly to its users for donations.

One internet organization that has done this successfully has been Wikipedia. How much income could Thunderbird generate if they received the same income per user as Wikipedia? Surely our users, who rely on Thunderbird for critical daily communications, are at least as willing to donate as Wikipedia users.

Estimates of income from Wikipedia’s annual fund raising drive to users are around $20,000,000 per year. Recently Wikipedia is reporting 11824 M pageviews per month and 5 pageviews per user. That results in a daily user count of 78 million users. Thunderbird by contrast has about 6 million daily users (using hits per day to update checks), or about 8% of the daily users of Wikipedia.

If Thunderbird were willing to directly engage users asking for donations, at the same rate per user as Wikipedia, there is a potential to raise $1,600,000 per year. That would certainly be enough income to maintain a serious team to move forward.

Wikipedia’s donation requests were fairly intrusive, with large banners at the top of all Wikipedia pages. When Firefox did a direct appeal to users early this year, the appeal was very subtle (did you even notice it?). I tried to scale the Firefox results to Thunderbird, and estimated that a similar subtle appeal might raise $50,000 – $100,000 per year in Thunderbird. That is not sufficient to make a significant impact. We would have to be willing to be a little intrusive, like Wikipedia, it we are going to be successful. This will generate pushback, as has Wikipedia’s campaign, so we would have to be willing to live with the pushback.

But is it really in the best interest of our users to spare them an annual, slightly intrusive appeal for donations, while letting the product that they depend on each day slowly wither away? I believe that if we truly care about our users, we will take the necessary steps to insure that we give them the best product possible, including undertaking fundraising to keep the product stable and vibrant.

Categorieën: Mozilla-nl planet

Kent James: Following Wikipedia, Thunderbird Could Raise $1,600,000 in annual donations

Thunderbird - do, 17/07/2014 - 08:31

What will it take to keep Thunderbird stable and vibrant? Although there is a dedicated, hard-working team of volunteers trying hard to keep Thunderbird alive, there has been very little progress on improvements since Mozilla drastically reduced their funding. I’ve been an advocate for some time that Thunderbird needs income to fulfill its potential, and that the best way to generate that income would be to appeal directly to its users for donations.

One internet organization that has done this successfully has been Wikipedia. How much income could Thunderbird generate if they received the same income per user as Wikipedia? Surely our users, who rely on Thunderbird for critical daily communications, are at least as willing to donate as Wikipedia users.

Estimates of income from Wikipedia’s annual fund raising drive to users are around $20,000,000 per year. Recently Wikipedia is reporting 11824 M pageviews per month and 5 pageviews per user. That results in a daily user count of 78 million users. Thunderbird by contrast has about 6 million daily users (using hits per day to update checks), or about 8% of the daily users of Wikipedia.

If Thunderbird were willing to directly engage users asking for donations, at the same rate per user as Wikipedia, there is a potential to raise $1,600,000 per year. That would certainly be enough income to maintain a serious team to move forward.

Wikipedia’s donation requests were fairly intrusive, with large banners at the top of all Wikipedia pages. When Firefox did a direct appeal to users early this year, the appeal was very subtle (did you even notice it?). I tried to scale the Firefox results to Thunderbird, and estimated that a similar subtle appeal might raise $50,000 – $100,000 per year in Thunderbird. That is not sufficient to make a significant impact. We would have to be willing to be a little intrusive, like Wikipedia, it we are going to be successful. This will generate pushback, as has Wikipedia’s campaign, so we would have to be willing to live with the pushback.

But is it really in the best interest of our users to spare them an annual, slightly intrusive appeal for donations, while letting the product that they depend on each day slowly wither away? I believe that if we truly care about our users, we will take the necessary steps to insure that we give them the best product possible, including undertaking fundraising to keep the product stable and vibrant.

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 9: destructuring pt2 - match and borrowing

Mozilla planet - do, 17/07/2014 - 03:19
(Continuing from part 8, destructuring).

When destructuring there are some surprises in store where borrowing is concerned. Hopefully, nothing surprising once you understand borrowed references really well, but worth discussing (it took me a while to figure out, that's for sure).

Imagine you have some `&Enum` variable `x` (where `Enum` is some enum type). You have two choices: you can match `*x` and list all the variants (`Variant1 => ...`, etc.) or you can match `x` and list reference to variant patterns (`&Variant1 => ...`, etc.). (As a matter of style, prefer the first form where possible since there is less syntactic noise). `x` is a borrowed reference and there are strict rules for how a borrowed reference can be dereferenced, these interact with match expressions in surprising ways (at least surprising to me), especially when you a modifying an existing enum in a seemingly innocuous way and then the compiler explodes on a match somewhere.

Before we get into the details of the match expression, lets recap Rust's rules for value passing. In C++, when assigning a value into a variable or passing it to a function there are two choices - pass-by-value and pass-by-reference. The former is the default case and means a value is copied either using a copy constructor or a bitwise copy. If you annotate the destination of the parameter pass or assignment with `&`, then the value is passed by reference - only a pointer to the value is copied and when you operate on the new variable, you are also operating on the old value.

Rust has the pass-by-reference option, although in Rust the source as well as the destination must be annotated with `&`. For pass-by-value in Rust, there are two further choices - copy or move. A copy is the same as C++'s semantics (except that there are no copy constructors in Rust). A move copies the value but destroys the old value - Rust's type system ensures you can no longer access the old value. As examples, `int` has copy semantics and `Box<int>` has move semantics:

fn foo() {
    let x = 7i;
    let y = x;                // x is copied
    println!("x is {}", x);   // Ok

    let x = box 7i;
    let y = x;                // x is moved
    //println!("x is {}", x); // error: use of moved value: `x`
}
Rust determines if an object has move or copy semantics by looking for destructors. Destructors probably need a post of their own, but for now, an object in Rust has a destructor if it implements the `Drop` trait. Just like C++, the destructor is executed just before an object is destroyed. If an object has a destructor then it has move semantics. If it does not, then all of its fields are examined and if any of those do then the whole object has move semantics. And so on down the object structure. If no destructors are found anywhere in an object, then it has copy semantics.

Now, it is important that a borrowed object is not moved, otherwise you would have a reference to the old object which is no longer valid. This is equivalent to holding a reference to an object which has been destroyed after going out of scope - it is a kind of dangling pointer. If you have a pointer to an object, there could be other references to it. So if an object has move semantics and you have a pointer to it, it is unsafe to dereference that pointer. (If the object has copy semantics, dereferencing creates a copy and the old object will still exist, so other references will be fine).

OK, back to match expressions. As I said earlier, if you want to match some `x` with type `&T` you can dereference once in the match clause or match the reference in every arm of the match expression. Example:

enum Enum1 {
    Var1,
    Var2,
    Var3
}

fn foo(x: &Enum1) {
    match *x {  // Option 1: deref here.
        Var1 => {}
        Var2 => {}
        Var3 => {}
    }

    match x {
        // Option 2: 'deref' in every arm.
        &Var1 => {}
        &Var2 => {}
        &Var3 => {}
    }
}
In this case you can take either approach because `Enum1` has copy semantics. Let's take a closer look at each approach: in the first approach we first dereference `x` to a temporary variable with type `Enum1` (which copies the value in `x`) and then do a match against the three variants of `Enum1`. This is a 'one level' match because we don't go deep into the value's type. In the second approach there is no dereferencing. We match a value with type `&Enum1` against a reference to each variant. This match goes two levels deep - it matches the type (always a reference) and looks inside the type to match the referred type (which is `Enum1`).

If we are matching a reference with move semantics, then the first approach is not an option. That is because `match *x` would move the enum value out of `*x` (rather than copy it). Any other references to the enum value would then be invalid. Option 2 is allowed, but that is not the end of the story. We have to be careful that any data nested in the enum is also not moved (well, the compiler has to be careful). That is to prevent an object being partially moved whilst someone else has a reference to it - this other referrer assumes the object is wholly immutable. For example,

enum Enum2 {
    // Box has a destructor so Enum2 has move semantics.
    Var1(Box<int>),
    Var2,
    Var3
}

fn foo(x: &Enum2) {
    // *x is no longer allowed.
    match x {
        // We're ignoring nested data, so this is OK
        &Var1(..) => {}
        // No change to the other arms.
        &Var2 => {}
        &Var3 => {}
    }
}
But what about if we want to use the data in `Var1`? We can't write:

    match x {
        &Var1(y) => {}
        _ => {}
    }

because that would mean moving part of `x` into `y`. We can use the 'ref' keyword to get a reference to the data in `Var1`: `&Var1(ref y) => {}`.That is OK, because now we are not dereferencing anywhere and thus not moving any part of `x`. Instead we are creating a pointer which points into the interior of `x`.

Alternatively, we could destructure the Box (this match is going three levels deep): `&Var1(box y) => {}`. This is Ok because `int` has copy semantics and `y` is a copy of the `int` inside the `Box` inside `Var1` (which is 'inside' a borrowed reference). Since `int` has copy semantics, we don't need to move any part of `x`. We could also create a reference to the int rather than copy it: `&Var1(box ref y) => {}`. Again, this is OK, because we don't do any dereferencing and thus don't need to move any part of `x`. If the contents of the Box had move semantics, then we could not write `&Var1(box y) => {}`, we would be forced to use the reference version.

If you do end up only being able to get a reference to some data and you need the value itself, you have no option except to copy that data. Usually that means using `clone()`. If the data doesn't implement clone, you're going to have to further destructure to make a manual copy or implement clone yourself.
Categorieën: Mozilla-nl planet

Kevin Ngo: More Happiness for Your Buck

Mozilla planet - do, 17/07/2014 - 02:00
Disney is the happiest places on Earth, but one of the most expensive. But it might be well worth the wallet hit.

With increasing assets, I have been thinking lately about what to purchase next, home purchasing, vacation planning, investment. You know, personal finances. Then I wonder how we spend in order to make ourselves happier. How can we use our money most efficiently to make ourselves happiest?

We have fine choices betweem 65" 3D plasma TVs, media-integrated BMWs and Audis, Tudor-style houses on the tree-lined avenue. Although we're all aware of the American Dream and although we might even consciously scoff at it, is it really ingrained in our heads enough to affect our purchases? Despite being aware of materialism, we still spend on items such as an Apple product upgrades or matching furniture sets. But really, compared to what we could potentially be allocating our money towards, are they really worth it?. Buck by buck, there are happier things to spend money on and happier ways to spend it.

Experiences Trumps Stuff

The happiness attained from a new toy is fleeting. When I buy a gadget, I get really excited about it for a couple weeks, and then it's just another item on the shelf. Once in freshman year, I dropped $70 on an HD camcorder. "Think about all the cool life experiences I could record!", I thought. After playing around with it for a bit, it got stowed away, just as Woody had when Buzz came to town. It wasn't the actual camcorder that I really wanted, it was thinking about the future experiences I could have.

Thinking back, the best things I have ever spent my money on were experiences. Trips around the world, places like the cultural streets of Beijing, the serenity of Oahu, or the cold isolation of Alaska. They bring back warm (or perhaps cold) memories and instill a rush of nostalgia. It brought about happiness in a way that those $100 beat-up sneakers or that now-stolen iPod touch ever did.

It's changed my thoughts on getting a nice house or car. Why spend to be stuck at a mundane home or spend to be stuck in traffic (just in cushier seats)? I'd rather use the money saved from not splurging $400K on a house to see the world. Spend money to be with people, go to places, attend shows, try new things. You won't forget it.

Instant Gratification is a Drag

It's not only what we spend on that makes us happy, it's how we spend. When we spend in a way such that we attain instant gratification, such as an in-store purchase on credit of that new fridge or getting that candy bar now, it destroys the whole fun of the waiting game. Have you ever eagerly awaited a package to come for weeks? Thinking about all the future possibilites, all the things you can do, all the fun you will have once that package comes. We are happier when we await something eagerly in anticipation. It's about the journey and not the destination.

Just yesterday, I booked my flight and hotel to Florida to visit my girlfriend working at Disney. It's almost two months out. But every day, I'll be thinking about how much fun we'll have watching the Fantasmic fireworks, how relaxing it will be staying at a 1940s Atlantic-city themed Disney inn, all the delicious food at the Flying Fish. With the date marked on my calendar, it makes me happier every day just eagerly anticipating it.

When you spend on something now, and defer the actual consumption or experience for later, you will much more gratified. Try pre-ordering something you enjoy, plan trips out months ahead, or purchasing online. By practicing patience, you'll probably even save a bit of cash.

Make It Scarce

Experiencing something too frequently makes it less of an experience. If you drink a frothy mocha cappucino every day, you become more and more desensitized to its creamy joys. By making something scarce by not buying or experiencing it too often, it becomes more of a treat. So if you're eating out for lunch every day at nice restaurants, you might want to think about only eating out once a week. Or only get expensive coffees on Fridays. It'll make those times you do go out that much more satisfying, and your wallet will thank you.

Time Trumps Money

Don't dwell too much on wasting your time to pinch some money. So Starbucks is giving out free 12oz coffees today? Free sounds enticing but is it really worth the gas, time in dreadful traffic, and waiting in line? View time as happiness. If you have more time, you can do more of the things you want to do. If you just feel like you have a lot of time, you feel much more free.

With that in mind, you should consider how purchases will affect your future time. Ask "will this really make me happier next week?". If you are contemplating a new TV, you might think it'll make you happier. Have so many friends over to play FIFA on the so-much-HD. But television doesn't make you happier or any less stressed. It's a numbing time-sink. Or perhaps think when you are debating between two similar products such as a Nexus 5 or an HTC One. Sure, when placed side-by-side, those extra megapixels and megahertz might seem like a huge advantage. But think about the product in isolation and see if it will really benefit your future time.

Give it Away

Warren Buffett pledged to give away 99% of his wealth, whether in his lifetime or posthumously. Giving away, passing it forward, being charitable makes people happy. Even happier had they splurged on themselves.

Helping others in need makes it feel like you have a lot of extra free time to give away. And feeling like you have a lot of free time is less of a boulder on your back. So invest in others and invest in relationships. We're inherently social creatures although sometimes selfish. It works against us. Donate to a charity where you know exactly where your money is going to, or buy something nice for a family member or friend without pressure. It's money happily spent.

Categorieën: Mozilla-nl planet

Mark Surman: How do we get depth *and* scale?

Mozilla planet - wo, 16/07/2014 - 22:20

We want millions of people learning about the web everyday with Mozilla. The ‘why’ is simple: web literacy is quickly becoming just as important as reading, writing and math. By 2024, there will be more than 5 billion people on the web. And, by then, the web will shape our everyday lives even more than it does today. Understanding how the it works, how to build it and how to make it your own will be essential for nearly everyone.

Maker Party Uganda

The tougher question is ‘how’ — how do we teach the web with both the depth *and* scale that’s needed? Most people who tackle a big learning challenge pick one path of the other. For example, the educators in our Hive Learning Networks are focused on depth of learning. Everything the do is high touch, hands-on and focused on innovating so learning happens in a deep way. On the flip side, MOOCs have quickly shown what scale looks like, but they almost universally have high drop out rates and limited learning impact for all but the most motivated learners. We rarely see depth and scale go together. Yet, as the web grows, we need both. Urgently.

I’m actually quite hopeful. I’m hopeful because the Mozilla community is deeply focused on tackling this challenge head on, with people rolling up their sleeves to help people learn by making and organizing themselves in new ways that could massively grow the number of people teaching the web. We’re seeing the seeds of both depth and scale emerge.

This snapped into focus for me at MozFest East Africa in Kampala a few days ago. Borrowing from the MozFest London model, the event showcased a variety of open tech efforts by Mozilla and others: FirefoxOS app development; open data tools from a local org called Mountabatten; Mozilla localization; Firefox Desktop engineering; the work of the Ugandan National Information Technology Agency. It also included a huge Maker Party, with 200 young Ugandans showing up to learn and hack with Webmaker tools.

Maker Party Uganda

The Maker Party itself was impressive — pulled off well despite rain and limited connectivity. But what was more impressive was seeing how the Mozilla community is stepping up to plant the seeds of teaching the web at depth and scale, which I’d call out as:

Mentors: IMHO, a key to depth is humans connecting face to face to learn. We’ve set up a Webmaker Mentors program in the last year to encourage this kind of learning. The question has been: will people step up to do this kind of teaching and mentoring, and do it well? MozFest EA was promising start: 30 motivated mentors showed up prepared, enthusiastic and ready to help the 200 young people at the event learn the web.

Curriculum: one of the hard parts of scaling a volunteer-based mentor program is getting people to focus their teaching on the most important web literacy skills. We released a new collection of open source web literacy curriculum over the past couple of months designed to solve this problem. We weren’t sure how things would work out, I’d say MozFestEA is early evidence that curriculum can do a good job of helping people quickly understand what and how to teach. Here, each of the mentors was confidently and articulately teaching a piece of the web literacy framework using Webmaker tools.

Making as learning: another challenge is getting people to teach / learn deeply based on written curriculum. Mozilla focuses on ‘making by learning’ as a way past this — putting hands-on, project based learning at the heart of most of our Webmaker teaching kits. For example, the basic remix teaching kit gets learners quickly hacking and personalizing their favourite big brand web site, which almost always gets people excited and curious. More importantly: this ‘making as learning’ approach lets mentors adapt the experience to a learner’s interests and local context in real time. It was exciting to see the Ugandan mentors having students work on web pages focused on local school tasks and local music stars, which worked well in making the standard teaching kits come to life.

Clubs: mentors + curriculum + making can likely get us to our 2014 goal of 10,000 people around the world teaching web literacy with Mozilla. But the bigger question is how do we keep the depth while scaling to a much bigger level? One answer is to create more ’nodes’ in the Webmaker network and get them teaching all year round. At MozFest EA, there was a session on Webmaker Clubs — after school web literacy clubs run by students and teachers. This is an idea that floated up from the Mozilla community in Uganda and Canada. In Uganda, the clubs are starting to form. For me, this is exciting. Right now we have 30 contributors working on Webmaker in Uganda. If we opened up clubs in schools, we could imagine 100s or even 1000s. I think clubs like this is a key next step towards scale.

Community leadership: the thing that most impressed me at MozFestEA was the leadership from the community. San Emmanuel James and Lawrence Kisuuki have grown the Mozilla community in Uganda in a major way over the last couple of years. More importantly, they have invested in building more community leaders. As one example, they organized a Webmaker train the trainer event a few weeks before MozFestEA. The result was what I described above: confident mentors showing up ready to teach, including people other than San and Lawrence taking leadership within the Maker Party side of the event. I was impressed.This is key to both depth and scale: building more and better Mozilla community leaders around the world.

Of course, MozFestEA was just one event for one weekend. But, as I said, it gave me hope: it made be feel that the Mozilla community is taking the core building blocks of Webmaker shaping them into something that could have a big impact.

IMG_20140716_185205

With Maker Party kicking off this week, I suspect we’ll see more of this in coming months. We’ll see more people rolling up their sleeves to help people learn by making. And more people organizing themselves in new ways that could massively grow the number of people teaching the web. If we can make happen this summer, much bigger things lay on the path ahead.


Filed under: education, mozilla, webmakers
Categorieën: Mozilla-nl planet

Gregory Szorc: Updates to firefoxtree Mercurial extension

Mozilla planet - wo, 16/07/2014 - 21:55

My Please Stop Using MQ post, has been generating a lot of interest for bookmark-based workflows at Mozilla. To make adoption easier, I quickly authored an extension to add remote refs of Firefox repositories to Mercurial.

There was still a bit of confusion and gripes about workflows that I thought it would be best to update the extension to make things more pleasant.

Automatic tree names

People wanted an ability to easy pull/aggregate the various Firefox trees without additional configuration to an hgrc file.

With firefoxtree, you can now hg pull central or hg pull inbound or hg pull aurora and it just works.

Pushing with aliases doesn't yet work. It is slightly harder to do in the Mercurial API. I have a solution, but I'm validating some code paths to ensure it is safe. This feature will likely appear soon.

fxheads commands

Once people adopted unified repositories with heads from multiple repositories, they asked how they could quickly identify the heads of the pulled Firefox repositories.

firefoxtree now provides a hg fxheads command that prints a concise output of the commits constituting the heads of the Firefox repos. e.g.

$ hg fxheads 224969:0ec0b9ac39f0 aurora (sort of) bug 898554 - raise expected hazard count for b2g to 4 until they are fixed, a=bustage+hazbuild-only 224290:6befadcaa685 beta Tagging /src/mdauto/build/mozilla-beta 1772e55568e4 with FIREFOX_RELEASE_31_BASE a=release CLOSED TREE 224848:8e8f3ba64655 central Merge inbound to m-c a=merge 225035:ec7f2245280c fx-team fx-team/default Merge m-c to fx-team 224877:63c52b7ddc28 inbound Bug 1039197 - Always build js engine with zlib. r=luke 225044:1560f67f4f93 release release/default tip Automated checkin: version bump for firefox 31.0 release. DONTBUILD CLOSED TREE a=release

Please note that the output is based upon local-only knowledge.

Reject pushing multiple heads

People were complaining that bookmark-based workflows resulted in Mercurial trying to push multiple heads to a remote. This complaint stems from the fact that Mercurial's default push behavior is to find all commits missing from the remote and push them. This behavior is extremely frustrating for Firefox development because the Firefox repos only have a single head and pushing multiple heads will only result in a server hook rejecting the push (after wasting a lot of time transferring that commit data).

firefoxtree now will refuse to push multiple heads to a known Firefox repo before any commit data is sent. In other words, we fail fast so your time is saved.

firefoxtree also changes the default behavior of hg push when pushing to a Firefox repo. If no -r argument is specified, hg push to a Firefox repo will automatically remap to hg push -r .. In other words, we attempt to push the working copy's commit by default. This change establishes sensible default and likely working behavior when typing just hg push.

Installing firefoxtree

Within the next 48 hours, mach mercurial-setup should prompt to install firefoxtree. Until then, clone https://hg.mozilla.org/hgcustom/version-control-tools and ensure your ~/hgrc file has the following:

[extensions] firefoxtree = /path/to/version-control-tools/hgext/firefoxtree

You likely already have a copy of version-control-tools in ~/.mozbuild/version-control-tools.

It is completely safe to install firefoxtree globally: the extension will only modify behavior of repositories that are clones of Firefox repositories.

Categorieën: Mozilla-nl planet

Mozilla's new Mozjpeg 2.0 image encoder improves JPEG compression - TechSpot

Nieuws verzameld via Google - wo, 16/07/2014 - 20:49

TechSpot

Mozilla's new Mozjpeg 2.0 image encoder improves JPEG compression
TechSpot
Mozilla yesterday announced the launch of an updated version of its JPEG compression tool Mozjpeg. The latest version (2.0) snips down file sizes by 5 percent on average compared to the widely used libjpeg-turbo. Although that might look like a small ...

Google Nieuws
Categorieën: Mozilla-nl planet

Pete Moore: Weekly review 2014-07-16

Mozilla planet - wo, 16/07/2014 - 16:37

Highlights

Last week build duty, therefore much less to report this week. I think we’ll have plenty to talk about though (wink wink).

l10n vcs sync was done by aki, and i posted my responses, and am writing up a patch which I hope to land in the next 24 hours. That will be l10n done.

I’ve been busy traiging queues too, and inviting people to meetings that I don’t attend myself, and cleaning up a lot of bugs (not just the triaging, but in general).

Today’s major incident was fallout from panda train 3 move - finally resolved now (yay). Basically, devices.json was out-of-date on the foopies. Disappointingly I thought to check devices.json, but did not consider it would be out-of-date on foopies, as I knew we’d been having lots of reconfigs every day. But for other reasons, the foopy updates were not performed (hanging ssh sessions when updating them) - so it took a while until this was discovered (by dustin!). In the meantime had to disable and enable > 250 pandas.

Other than that, working ferociously on finishing off vcs sync.

I think I probably updated 200 bugs this week! Was quite a clean up.

Categorieën: Mozilla-nl planet

Frédéric Harper: Community Evangelist: Firefox OS developer outreach at MozCamp India

Mozilla planet - wo, 16/07/2014 - 16:10
//j.mp/1jIYxWb (click to enlarge)

Copyright Ratnadeep Debnath
http://j.mp/1jIYxWb (click to enlarge)

At the end of June, I was in India to do a train the trainer session at MozCamp India. The purpose of the session Janet Swisher (first time we worked together, and I think we got a winning combo), and I delivered was to help Mozillians to become Community Evangelists. Our goal was to help them become part of our Technical Evangelist team: helping us inspiring and enabling developers in India to be successful with Firefox OS (we are starting with this technology because of the upcoming launch).

We would have been able to do a full day or more about developer outreach, but we only had three hours in which we shown the attendees how they can contribute, did a fun speaker idol and worked on their project plan. The contribution can be done at many levels, like public speaking, helping developers to build Firefox OS application, answering questions on StackOverflow, and more.

Since we had parallel tracks during our session, we gave it twice to give them the chance to assist to more than one track. For those who were there in the Saturday session, the following slides are the one we used:

Developer Outreach for Firefox OS – Mozcamp India – 2014-06-21 from Frédéric Harper

I also recorded the session for those of you that would like to refresh your memory:

For the session on Sunday, we fixed some slides, and adapted our session to give us more time for the speaker idol as the project plan. Here are the slides:

Developer Outreach for Firefox OS – Mozcamp India – 2014-06-22 from Frédéric Harper

If you were not there, I would suggest you to follow the slides as the video of the second day, as it’s an improve version of the first one (not that the first one was not good, but it was the first time we gave this session);

From the feedback we got, it was a pretty good session, and we were happy so see the excitement of the Indian community about this community evangelist role. I can’t wait to see what the Mozilla community in India will do! If you too, Mozillian or not, have any interest about evangelizing the open web, you should join the Mozilla Evangelism mailing list.

 


--
Community Evangelist: Firefox OS developer outreach at MozCamp India is a post on Out of Comfort Zone from Frédéric Harper

Related posts:

  1. Firefox OS love in Toronto Yesterday, I was in Toronto to share some Firefox OS...
  2. Working your magic with Firefox OS – Playing mp4 Everything you are looking for, about Firefox OS development, is...
  3. One month as a Firefox OS Technical Evangelist Time flies; I thought I started at Mozilla last week,...
Categorieën: Mozilla-nl planet

Mozilla launches improved JPEG EncoderPublish Date: Jul 16, 2014 - New Vision

Nieuws verzameld via Google - wo, 16/07/2014 - 14:19

New Vision

Mozilla launches improved JPEG EncoderPublish Date: Jul 16, 2014
New Vision
MOZILLA announced the launch of the latest version of its mozjpeg image encoder for JPEG files. The new version is already being tested on facebook.com, and Facebook donated $60,000 to Mozilla to continue its work on this project. When it comes to ...
Facebook joins Mozilla to give Web's image makeoverCNET
Mozilla and Facebook snip a further five per cent from all JPEGsRegister
Mozilla's JPEG compression slims down file sizesInfoWorld
TechRadar UK
alle 27 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozjpeg 2.0: Facebook unterstützt JPEG-Encoder von Mozilla - Golem.de

Nieuws verzameld via Google - wo, 16/07/2014 - 14:00

WinFuture

Mozjpeg 2.0: Facebook unterstützt JPEG-Encoder von Mozilla
Golem.de
Im März dieses Jahres hatte Mozilla einen JPEG-Encoder vorgestellt, der eine bessere Kompression des Dateiformats ermöglichen soll. Die nun veröffentlichte Version 2.0 des Projekts Mozjpeg wolle Facebook testen, um in seinem sozialen Netzwerk Bilder ...
Mozilla mozjpeg 2.0 soll Bilder kleiner machenSoftware und jede Menge Tipps & Tricks
JPEGs werden durch den Einsatz von Mozilla noch einmal kleinerWinFuture
Mozilla will mit Facebook-Hilfe JPEGs verkleinernFuturezone
Heise Newsticker -Ad-Hoc-News (Pressemitteilung) -PC-Welt
alle 8 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla's JPEG compression slims down file sizes - Computerworld

Nieuws verzameld via Google - wo, 16/07/2014 - 12:31

Mozilla's JPEG compression slims down file sizes
Computerworld
IDG News Service - Mozilla has released an updated version of its JPEG compression tool that shaves down file sizes by 5%, a small figure but one that is significant for image-intensive Web services such as Facebook. The tool, called mozjpeg 2.0, will ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla's $50 Firefox OS smartphones reportedly launching in India this month - Firstpost

Nieuws verzameld via Google - wo, 16/07/2014 - 12:08

Firstpost

Mozilla's $50 Firefox OS smartphones reportedly launching in India this month
Firstpost
Mozilla could partner with only one or two telecom operators in these countries which brought a relatively lukewarm response towards these ultra-cheap smartphones. However, it expects to meet a different fate in India as Mozilla is seeking cooperation ...
Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This JulyGizbot
Firefox smartphones to be launched in India in July, says Mozilla COODigitimes
Mozilla to launch Firefox smartphones in India in JulyTelecompaper (subscription)
KpopStarz -MotoringCrunch
alle 11 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This July - Gizbot

Nieuws verzameld via Google - wo, 16/07/2014 - 11:23

Gizbot

Mozilla To Launch World's Cheapest Firefox OS Smartphones in India This July
Gizbot
In a latest report by Digitimes, Mozilla Taiwan CEO and company COO Gong Li has confirmed that the company will launch inexpensive smartphones in India at a price of around $50 (Rs 3,000 approx.). As per the report, Gong Li also added that in India ...
Mozilla's $50 Firefox OS smartphones reportedly launching in India this monthFirstpost
Firefox smartphones to be launched in India in July, says Mozilla COODigitimes
Mozilla to launch Firefox smartphones in India in JulyTelecompaper (subscription)
KpopStarz -MotoringCrunch
alle 10 nieuwsartikelen »
Categorieën: Mozilla-nl planet

New Mozilla JPEG Encoder Trims File Size - Headlines & Global News

Nieuws verzameld via Google - wo, 16/07/2014 - 11:18

Headlines & Global News

New Mozilla JPEG Encoder Trims File Size
Headlines & Global News
"Facebook supports the work Mozilla has done in building a JPEG encoder that can create smaller JPEGs without compromising the visual quality of photos," Stacy Kerkela, software engineering manager at Facebook, said in a press statement. "We look ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla's advanced JPG encoder cuts file sizes by five per cent - HEXUS

Nieuws verzameld via Google - wo, 16/07/2014 - 11:16

HEXUS

Mozilla's advanced JPG encoder cuts file sizes by five per cent
HEXUS
Mozilla has announced the availability of mozjpeg 2.0 via its research blog. We previously heard about this project to refine a "production-quality JPEG encoder" to offer better optimised images in March this year. Now the v2.0 fruits of that labour ...

Google Nieuws
Categorieën: Mozilla-nl planet

Pagina's