Mozilla Add-ons BlogSeptember Featured Add-ons

Pick of the Month: CoolPreviews

by The Cooliris Team

Browse faster—preview links and images without leaving your current page or tab. Just mouse over any link and a preview window appears to display the content.

“Everyone that I know that doesn’t have Firefox already, is switching to it, to be able to get this add-on. It is fantastic. I use it everyday and would be lost without it.”

CoolPreviews

Get CoolPreviews »

Also Featured

Font Finder by Ben Dodson, Eric Caron, Jake Smith, Andy Portmen
FontFinder is created for designers, developers and typographers. It allows a user to analyze the font information of any element on a page, copy any piece(s) of that information to the clipboard, and perform inline replacements to test new layouts.

Pray Times! by Hamid Zarrabi-Zadeh
Display daily Muslim prayer times.

Nominate your favorite add-ons!

Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months, so there’s always an opportunity to participate. If you’d like to join, keep an eye on this blog for the next application cycle.

If you’d like to nominate an add-on for featuring, please send it to amo-featured@mozilla.org for the board’s consideration. We welcome you to submit your own add-on!

Software CarpentryFall 2014 Bootcamps (So Far)

Our calendar for the fall is filling up pretty quickly: we've added the following bootcamps in the last couple of weeks, and have more on the way. If you'd like us to run one where you are, please fill in this form and we'll get the ball rolling.

Brazil Set 04-05
United-States Sep 11-12
Australia Sep 15, 18, 22 & 25
United-Kingdom Sep 16-17
United-States Sep 18-19
United-States September 24-25
Canada Sep 25-26
Canada Oct 6-7
United-States Oct 30-Nov 1

about:communityFirefox 32 New Contributors

With the upcoming release of Firefox 32, we are pleased to welcome the 68 developers who contributed their first code change to Firefox in this release, 53 of whom were brand new volunteers! Special thanks to Sezen Günes for compiling these statistics for this release. Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

SUMO BlogWhat’s up with SUMO – August 29th

Hey, everyone! Michał here. I’m not as good with cameras and videos as Michael Verdi (yet!), so for now you’ll have to read me. I’m pretty sure you don’t mind. Just read it in Morgan Freeman’s voice and imagine penguins running around, that should make it more fun ;-).

New SUMO members

We’re growing! Not quite at a million yet, but getting closer every day. Take a while to visit the introductions thread and say hello to:

The goings-on

Firefox OS launch in India

  • As you all know, Firefox OS officially launched this Monday in India. Our Indian friends have shown immense support from the very start, first by translating KB articles into the three Indian languages we display in SUMO, and then by helping out directly in the support forums. Huge thanks to you all! We could not have gotten this far without you.
  • If you’re wondering how to become a contributor with Mozilla India, take a look at the group’s Facebook page or visit the forums and say hi!
  • We’re still pushing to get to 100% with all help content for Hindi, Bengali (for India), and Tamil – if you’re interested in helping out, click the language link in this sentence and send the Locale Leaders a private message to get started.

The Buddy Program is back!

Firefox OS launch in Bangladesh

  • With India already using FF OS phones, it’s time for Bangladesh! We hope to get more users of Bengali in Bangladesh to join our localization drive for the Firefox OS help articles. Interested? Just click the link in this paragraph and contact the Locale Leaders through a Private Message for more information. You can also connect with Mozilla Bangladesh through their Facebook group.

SUMO at MozFest 2014!

  • centurion has put together a session proposal combining his interest for Webmaker and localization. We’ll keep you updated about SUMO’s presence during MozFest 2014. Big thanks to centurion for coming up with a great idea!

Last but not least, John99 found a couple of new friends for all of us ;-) Thanks, John99!

Would you like to read about something in particular here? Let us know in the forums.

QMOA New Era for Testdays

I’m writing today to announce the transition to a new era for testdays.

The Feedback is In

A while back I had written a post announcing that we were starting a process to retool testdays. We had admitted to ourselves that the current model wasn’t working for various reasons, not least of which was declining value for participants. We decided that the best way to reverse this tide was to begin with tearing down our preconceived notions of what testdays were and to begin brainstorming ideas for what testdays should be. And so we kicked off a cycle purely focused on collecting feedback from you, the community at large.

We believe its important for testdays to focus on providing contributors with the tools needed to contribute long-term and that getting help with testing is a natural side-effect of successful engagement. We believe in strengthening community relationships and broadening our outreach.

Several weeks ago we asked anyone and everyone to start giving us feedback about testdays by entering ideas into an etherpad. Each week we reviewed the feedback and integrated your ideas into the strategy. We’ve received a lot of great ideas that we’re excited to try out and given that the amount of incoming feedback has subsided, we think it’s a good time to shift gears.

Next Steps

We are now going to begin building a new type of testday modeled off some of the key themes that emerged from your feedback. Over the next few months we’ll be focused on experimenting with new ideas and analyzing the results of these experiments. Each and every experiment will be looked at as a teachable moment, even failed experiments will have a story to tell and a lesson to learn.

The first of these events will be focused on “mentorship”. The idea is to hold an event that focuses on engaging new contributors by teaching them the skills necessary to be effective testers within Mozilla, and to allow core contributors to engage as educators in their own right. We’re still in the planning stages for this event but intend to hold the event within the next few weeks.

I want to reiterate that this should be seen as a transitional period. We don’t want to stop all the great work that is currently happening with events like Testdays and Bugdays. If you’re currently involved with those events I encourage you to remain engaged in those events. However, you may see one or two of these events skipped over the next few weeks as we refocus some of our energies to our first “mentorship” testday. You may also see the frequency of these traditional events decline as we become more successful and seek to ramp up the new experimental events.

How Can You Help?

If you’d like to help us plan this event, it will be our top discussion item for the next several meetings. You can be involved by joining our meeting (details below).

When: Tuesday @ 1pm PDT (UTC -7)
Video conference: https://v.mozilla.com/flex.html?roomdirect.html&key=WBuu8ks3P4IZ
Vidyo room: Anthony Hughes (or click the link above ^)
Telephone: +1 (800) 707-2533 p369 x99007
IRC: irc.mozilla.org #qa

If you’re not able to attend the meeting then please add your ideas, questions, or concerns to this etherpad.

Of course, there are more ways to help:

  • Read our wiki, including the strategy linked within
  • Provide feedback on this new direction
  • Contribute ideas for experiments you think we should try
  • Participate in an upcoming bugday or testday

I’m looking forward to see what we can create by working together on this new era for testdays.

WebmakerQ&A with MakerBox

Maker Party partnerships are a great opportunity for us to get to know organizations who are doing awesome work making and teaching all year round. Based in Wellington, New Zealand, MakerBox is an organization that believes every child should have access to classes and equipment to learn about science, technology, engineering, mathematics and art. We had a chance to catch-up with Jess Weichler from MakerBox to learn more about this exciting organization, how they work, and what they are doing to celebrate Maker Party this year.

Makerbox

What is MakerBox and what do you do?

MakerBox hosts low­-cost classes and workshops along with free community events such as Maker Party. We offer everything from workshops on creating paper circuits to more advanced classes on video game programming and stop ­motion animation. Because we do not have a brick­ and­ mortar space we are able to easily travel to where we are needed and work with other organizations to supplement their programs.

What events will you be hosting or running during Maker Party?

We will be holding a community Maker Party at the Miramar Community Centre on September 13th along with other awesome New Zealand makers. Wellington Makerspace is bringing along their 3D printer, Raroa Normal Intermediate is going to show off some of the amazing projects they’ve been working on this term, and Fabriko is visiting us from Christchurch to share some hands­ on activities.

Why did you choose to get involved with Maker Party?

Maker Party is such a great way to connect with the community and celebrate learning through play and making. Learning should not be reserved for the classroom, nor should it stop once you finish school. Maker Party allows participants to try out new tech and learn skills that they may have never even considered in a safe, supportive space. It’s also heaps of fun!

Tell us what you are most excited for at the event?

I’m most excited to see what everyone is going to make and hoping that maybe I will learn some new things while teaching others!

Why is it important for youth and adults to make things with technology?

Even if someone never plans to become a web developer or an engineer, you can still pick up some amazing critical thinking skills by making. Having a unique way of approaching a problem can provide an edge in less technical careers. Making can also help provide a greater understanding of other subjects, such as learning variables through video game programming.

Why is it important for people and organizations to get involved in Maker Party?

Technology is not going away any time soon, it is imperative that both youth and adults have the skills needed to be good consumers and creators of tech. Maker Party helps to make the skills more accessible and technology less scary.

How can people get in touch with your organization?

Check out or website at www.MakerBox.org.nz or find us on Facebook.

The Mozilla BlogFirefox OS Smartphones Change The Mobile Landscape Across India

The launch of two Firefox OS phones in India in the same week marks an exciting moment in Mozilla’s mission to promote openness and innovation on the Web, and an opportunity to empower millions of Indians wanting to buy their … Continue reading

Software CarpentryThe New MATLAB Teaching Materials

When Software Carpentry started running bootcamps back in 2012, Python was used exclusively for the programming lessons. While these lessons were as language agnostic as possible (i.e. the materials focused on transferrable programming concepts as opposed to specifics of the Python language), people soon expressed an interest in running bootcamps using other languages. R very quickly established itself as a regular alternative to Python, but it wasn't until early 2014 that the first ever Matlab bootcamp was held (see here and here for blog posts about the event; the official event page is here).

Fortunately for the Software Carpentry community, the instructors from that event have subsequently written up their teaching materials and made them freely available via a CC-BY (Creative Commons - Attribution) license (there's been some issues with the FTP site where those materials are located, so in the meantime you can find a copy here at the Research Bazaar GitHub repo). There's still some debate as to whether the ongoing maintenance and development of these materials should be supported by Software Carpentry or MathWorks (because unlike Python and R, Matlab is proprietary software), but in the meantime demand has been so strong in Melbourne that we went ahead and organised a bootcamp as soon as we could get our hands on the teaching materials.

Our August bootcamp at the University of Melbourne filled the 45 seat room and had a further 25 on the waiting list. On the first day we taught the new Matlab lessons, while on the second we covered the standard Software Carpentry lessons on the shell and version control. In other words, Matlab was used to teach programming, while the shell and version control were pitched as tools to manage your code and data effectively.

What I've tried to do below is distill the main comments/feedback received from instructors, helpers and participants. For more detailed commentary, see the relevant GitHub issue. At times these comments may sound critical, but it should be kept in mind that these Matlab lessons are brand new. Unlike the current Python lessons, they haven't had the luxury of years of development using feedback from hundreds of bootcamps. At the end of the day, the participants at our bootcamp got the undivided attention of eight Matlab gurus for two whole days (thanks to all the helpers who came along). Such dedicated programming assistance is unheard of in the academic world, and consequently this unique learning experience was greatly appreciated by all who attended.

Comments:

  • The Matlab materials provide approximately two challenges for each of the four main lessons (see here). These challenges are very well documented (i.e. the relevant data files and answers are all conveniently contained in an Exercises directory), however their completion requires the participants to be familiar with all the content in the associated lesson. Since each lesson involves up to an hour of live coding/demonstration, the bootcamp involved very long periods of demonstration followed by challenges that also took a very long time to complete. This not only made it difficult for participants to maintain concentration, but it also meant that there were long periods where the helpers weren't really involved in the action.
    • There are shorter recommended activities scattered throughout the teaching notes, but these often ask the participants to do something they've never seen before (e.g. one of the recommended activities asks the participants to define a function, even though at that point the instructor hasn't even demonstrated the associated syntax and typical use cases). Our instructors therefore used those recommended activities as examples that they themselves could demonstrate to the audience.
  • Unlike the novice Python lessons, there's isn't a consistent data analysis story weaved throughout the four Matlab lessons. As a consequence, the data analysis examples seem a little disjointed.
  • The Matlab lessons and challenges escalate in complexity very quickly. In Software Carpentry terminology, they are definitely "intermediate" as opposed to "novice" level materials.
  • One useful feature of the Python lesson materials is that the instructor notes are essentially written as a verbatim script of what an instructor could/would say at each point of the bootcamp. This makes things much easier for new instructors, because there is no ambiguity about how the materials could/should be delivered. While the Matlab materials provide significant guidance (i.e. they're not far off), they cannot be used as a verbatim script.

Going forward, I think these Matlab materials should be designated as our current intermediate level lessons, with a view to addressing the comments above in the coming months/years (i.e. shorter and more regular challenges, a verbatim script to help new instructors, a consistent data analysis example throughout, and a number of other small fixes outlined in the GitHub issue). As a starting point for a set of novice level Matlab lessons, I would suggest we simply re-write the current Python lessons using Matlab. Isabell Kiral-Kornek (one of the instructors from our bootcamp) jumped in and made a start on this task right away (see here), and in the process of writing this post I was alerted to the fact that Ashwin Srinath has also made a start on precisely the same task (see his code and discussion). They've each taken a slightly different approach to the re-write (i.e. comparing and combining their materials will result in a better final product), however to avoid such duplication of effort in the future we've setup a Matlab mailing list in order to keep the community updated with our progress.

Once Ashwin and Isabell (and anyone else who'd like to get involved) have completed the re-write, the Software Carpentry Matlab materials will resemble the current state of the R materials: the novice lessons will be a clone of the Python lessons, while the intermediate lessons are an independent set. This development pattern seems reasonable in that similar lessons are appropriate for novice learners no matter the language, whereas the teaching of more complex topics quickly becomes more language specific.

If you would like to join the discussion about development of MATLAB materials, please add yourself to this mailing list.

Software CarpentrySoftware Carpentry at Cambridge University

At the beginning of this week Thomas Kluyver and I taught a Software Carpentry bootcamp at the University of Cambridge. We had around 35 learners of very different experience and took them through Bash, Git and Python over the course of two days.

First of all I want to thank everyone who helped organize and run the bootcamp this week, especially Thomas for sharing the teaching duties and our excellent helpers Jelena Aleksic and David Molnar. We also had a lot of help from our host Gabriella Rustici along with Paul Judge and David Judge. We held the bootcamp in a university teaching room, so we used a suite of desktop computers and had them all loaded with the Software Carpentry virtual machine, which eliminated much of the extra time spent solving setup issues on the first morning.

Since we also wanted people to go away with a working setup that they could use on their own, I sent round the standard bootcamp installation instructions to all the learners the week before the bootcamp and asked them to have a go installing all the software on their own machines. The idea was that we could then help people with individual installation issues during the coffee/lunch breaks if necessary. In the end, only two people came to us having had problems with installation, which probably reflects a mixture of improvements to the SWC windows installer, a relatively high number of more experienced learners and a number of people not attempting to install things before the bootcamp.

The pre-bootcamp questionnaire revealed a very wide spread of previous experience. We had a number of absolute beginners, but nearly one third of the group reported that they currently programmed once a week or more. Almost all of the respondants also indicated that they had already had some experience with the command line. In order not to frustrate those who had more advanced knowledge, we decided to add links to some of the intermediate Software Carpentry lessons on the bootcamp website. At the beginning of the first day we let everyone know that we were aware of the wide range in experience but we would be working at a pace suitable for novices, so anyone who felt comfortable with the material should feel free to work at their own pace and move on to the intermediate material if they finished early. Walking around during the challenges I had the impression that the vast majority of the class was working at the instructor's pace, but perhaps knowing that they weren't being forced to slow down helped the more advanced people not to get annoyed. Even so, we had a few pink stickies at the end of the day from people who felt that the Bash lessons were too slow for more experienced users, and that the course website had not been clear enough about the expected entry level.

Before the bootcamp I invested some time in organizing the files for the shell lessons. Since we were working from virtual machines, it made sense to have all the example files in a consistent file tree. I think this helped a lot with the lesson flow, and we had a few learners comment that the unix session was especially easy to follow. One person did say that we could have been clearer about which directory everyone was supposed to be in at the beginning of each new section. Thomas took the afternoon's Git session which seemed to go really well. Instead of having the learners collaborate from two repositories on their local machines, we had them pair up and work on each other's repositories. This approach seemed to motivate people really well and we got a lot of positive comments about that session at the end of the day.

Our biggest technical hurdle came on Wednesday morning, when it transpired that I had forgotten to check that the iPython notebook was installed on the virtual machines. After some copying and pasting of "sudo apt" commands, we got the notebook working only to find that numpy and matplotlib were not installed either. In the end it only took around 15 minutes to get everyone set up and people seemed quite quick to forgive me my oversight! Our audience were keen to learn about debugging and defensive programming, so Thomas and I decided to skip SQL in order to give ourselves enough time to cover everything. Despite having a whole day for python, we had still only gotten through the first three lessons by the afternoon coffee break and decided to skip over if/else to get to the material on assertions and test driven development. We got quite a few positive comments about this material at the end, but there was also a little frustration as some of the challenges in lesson five require if/else statements to solve.

One final thing I'd recommend for anyone planning to run a bootcamp in the future - I took a small notebook with me and wrote down lots of small issues that cropped up as we were going through the material. If I hadn't written these all down immediately I would have forgotten them by the end of the day, but I now have a little stockpile of material for issues and pull requests I can send back upstream, hopefully making things easier for myself (and everyone else) next time around!

Air MozillaTypeDevil: Dynamic Type Inconsistency Analysis for JavaScript

TypeDevil: Dynamic Type Inconsistency Analysis for JavaScript Dynamic languages, such as JavaScript, give programmers the freedom to ignore types, enabling them to write concise code in short time. Despite this freedom, many...

Air MozillaMozilla Docs: Version controlled open source design documents

Mozilla Docs: Version controlled open source design documents Valentin Tsatskin, "A guided tour through my design methodology which introduces version control and open source collaboration to design documents. A Mozilla Document is powered web technologies, github and beautiful aesthetic design."

The Bugzilla UpdateLandfill.bugzilla.org Disclosure

UPDATE: We have reset all passwords on all Landfill test Bugzilla systems. All users will be required to set a new password the next time they access the test Bugzilla systems.

One of our developers discovered that, starting on about May 4th, 2014, for a period of around 3 months, during the migration of our testing server for test builds of the Bugzilla software, database dump files containing email addresses and encrypted passwords of roughly 97,000 users of the test build were posted on a publicly accessible server.  As soon as we became aware, the database dump files were removed from the server immediately, and we’ve modified the testing process to not require database dumps.

Generally, developers who use our test builds have told us they understand that these builds are insecure and may break, so they do not use passwords they would reuse elsewhere.  However, because it is possible that some users could have reused their passwords on other websites or authentication systems, we’ve sent notices to the users who were affected by this disclosure and recommended that they change any similar passwords they may be using. It’s important to note that, unless users reused the password they used on landfill.bugzilla.org, this does not affect bugzilla.mozilla.org email addresses or passwords.

We are deeply sorry for any inconvenience or concern this incident may cause you.

Thanks,

Mark Côté

Assistant Project Lead, Bugzilla


Air MozillaCATs

CATs Mozilla Intern Gabriel Luong presents "CATs"

The Mozilla Blog74 Countries and Counting: Mozilla’s Maker Party Increases Web Literacy Across the Globe

Back in July we kicked-off Maker Party, our annual campaign to teach the web around the world. Throughout  this two-month campaign we have seen people on nearly every continent  increase their web literacy by writing their first line of code, … Continue reading

Products TeamUpdate on reviewing our data practices and Bugzilla development database disclosure

As we indicated in the post titled “MDN Disclosure”, we began several remediation measures, including a review of data practices surrounding user data. We have kicked off a larger project to better our practices around data, including with respect to the various non-Mozilla projects we support. We are implementing immediate fixes for any discovered issues across the organization, and are requiring each business unit to perform a review of their data practices and, if necessary, to implement additional protections based on that review.

As we proceed through our broader remediation program, we discovered an incident that occurred in the Bugzilla community, one of the community projects we support. A member of the Bugzilla community discovered that development database dump files containing email addresses and encrypted passwords were posted on a publicly accessible server. They were alerted to this incident by a security bug filed by a contributor. See the Bugzilla community blog post for more information.

While it is important to note that the disclosure of this development database does not affect bugzilla.mozilla.org, we continue to believe that the broader community would benefit from our increased focus on data practices and therefore will continue with our plan of including the Bugzilla project as well as other community projects in the data practices initiatives we’ve described above.

We are committed to continuing to improve our data practices to minimize the likelihood of these and other types of incidents.

Sincerely,

Mozilla Security

Air MozillaRustc, middle, trans

Rustc, middle, trans Luqman Aden, "Rust being a relatively new language presents the opportunity to improve on the code the compiler generates. This presentation will be about digging through compiler internals and other sorts of fun."

Air MozillaMinion just got friendlier!

Minion just got friendlier! Piyush Waradpande, "Minion is a security platform targeted towards developers. During my internship this summer, I had a chance to add some shiny new features to Minion and make it friendlier. In my presentation I would be talking about what Minion is and how I to added scan scheduling, visualizations and framework upgrade to it. I will also be talking about other side projects that I worked on during my summer."

Air MozillaMinion just got friendlier!

Minion just got friendlier! Piyush Waradpande, "Minion is a security platform targeted towards developers. During my internship this summer, I had a chance to add some shiny new features to Minion and make it friendlier. In my presentation I would be talking about what Minion is and how I to added scan scheduling, visualizations and framework upgrade to it. I will also be talking about other side projects that I worked on during my summer."

Air MozillaDefining the health of Firefox OS by breaking the new homescreen and tracking the smoketests.

Defining the health of Firefox OS by breaking the new homescreen and tracking the smoketests. Johan Lorenzo, "Blackbox testing the brand new vertical homescreen was it like testing any other new feature? Why did we need a dashboard for the smoketests bugs?"

Air MozillaProduct Coordination Meeting

Product Coordination Meeting Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

Air MozillaBugzilla Development Meeting

Bugzilla Development Meeting Help define, plan, design, and implement Bugzilla's future!

hacks.mozilla.orgBlack Box Driven Development in JavaScript

Sooner or later every developer finds the beauty of the design patterns. Also, sooner or later the developer finds that most of the patterns are not applicable in their pure format. Very often we use variations. We change the well-known definitions to fit in our use cases. I know that we (the programmers) like buzzwords. Here is a new one – Black Box Driven Development or simply BBDD. I started applying the concept before a couple of months, and I could say that the results are promising. After finishing several projects, I started seeing the good practices and formed three principles.

What is a black box?

Before to go with the principles of the BBDD let’s see what is meant by a black box. According to Wikipedia:

In science and engineering, a black box is a device, system or object which can be viewed in terms of its input, output and transfer characteristics without any knowledge of its internal workings.

In programming, every piece of code that accepts input, performs actions and returns an output could be considered as a black box. In JavaScript, we could apply the concept easily by using a function. For example:

var Box = function(a, b) {
    var result = a + b;
    return result;
}

This is the simplest version of a BBDD unit. It is a box that performs an operation and returns output immediately. However, very often we need something else. We need continuous interaction with the box. This is another kind of box that I use to call living black box.

var Box = function(a, b) {
    var api = {
        calculate: function() {
            return a + b;
        }
    };
    return api;
}

We have an API containing all the public functions of the box. It is identical to the revealing module pattern. The most important characteristic of this pattern is that it brings encapsulation. We have a clear separation of the public and private objects.

Now that we know what a black box is, let’s check out the three principles of BBDD.

Principle 1: Modulize everything

Every piece of logic should exist as an independent module. In other words – a black box. In the beginning of the development cycle it is a little bit difficult to recognize these pieces. Spending too much time in architecting the application without having even a line of code may not produce good results. The approach that works involves coding. We should sketch the application and even make part of it. Once we have something we could start thinking about black boxing it. It is also much easier to jump into the code and make something without thinking if it is wrong or right. The key is to refactor the implementation till you feel that it is good enough.

Let’s take the following example:

$(document).ready(function() {
    if(window.localStorage) {
        var products = window.localStorage.getItem('products') || [], content = '';
        for(var i=0; i<products.length; i++) {
            content += products[i].name + '<br />';
        }
        $('.content').html(content);
    } else {
        $('.error').css('display', 'block');
        $('.error').html('Error! Local storage is not supported.')
    }
});

We are getting an array called products from the local storage of the browser. If the browser does not support local storage, then we show a simple error message.

The code as it is, is fine, and it works. However, there are several responsibilities that are merged into a single function. The first optimization that we have to do is to form a good entry point of our code. Sending just a newly defined closure to the $(document).ready is not flexible. What if we want to delay the execution of our initial code or run it in a different way. The snippet above could be transformed to the following:

var App = function() {
    var api = {};
    api.init = function() {
        if(window.localStorage) {
            var products = window.localStorage.getItem('products') || [], content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            $('.content').html(content);
        } else {
            $('.error').css('display', 'block');
            $('.error').html('Error! Local storage is not supported.');
        }
        return api;
    }
    return api;
}
 
var application = App();
$(document).ready(application.init);

Now, we have better control over the bootstrapping.

The source of our data at the moment is the local storage of the browser. However, we may need to fetch the products from a database or simply use a mock-up. It makes sense to extract this part of the code:

var Storage = function() {
    var api = {};
    api.exists = function() {
        return !!window && !!window.localStorage;
    };
    api.get = function() {
        return window.localStorage.getItem('products') || [];
    }
    return api;
}

We have two other operations that could form another box – setting HTML content and show an element. Let’s create a module that will handle the DOM interaction.

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {
        if(!el) {
            el = $(selector);
            if(el.length == 0) {
                throw new Error('There is no element matching "' + selector + '".');
            }
        }
        return el;
    }
    api.content = function(html) {
        element().html(html);
        return api;
    }
    api.show = function() {
        element().css('display', 'block');
        return api;
    }
    return api;
}

The code is doing the same thing as in the first version. However, we have a test function element that checks if the passed selector matches anything in the DOM tree. We are also black boxing the jQuery element that makes our code much more flexible. Imagine that we decide to remove jQuery. The DOM operations are hidden in this module. It is worth nothing to edit it and start using vanilla JavaScript for example or some other library. If we stay with the old variant, we will probably go through the whole code base replacing code snippets.

Here is the transformed script. A new version that uses the modules that we’ve created above:

var App = function() {
    var api = {},
        storage = Storage(),
        c = DOM('.content'),
        e = DOM('.error');
    api.init = function() {
        if(storage.exists()) {
            var products = storage.get(), content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            c.content(content);
        } else {
            e.content('Error! Local storage is not supported.').show();
        }
        return api;
    }
    return api;
}

Notice that we have separation of responsibilities. We have objects that play roles. It is easier and much more interesting to work with such codebase.

Principle 2: Expose only public methods

What makes the black box valuable is the fact that it hides the complexity. The programmer should expose only methods (or properties) that are needed. All the other functions that are used for internal processes should be private.

Let’s get the DOM module above:

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {}
    api.content = function(html) {}
    api.show = function() {}
    return api;
}

When a developer uses our class, he is interested in two things – changing the content and showing a DOM element. He should not think about validations or change CSS properties. In our example, there are private variable el and private function element. They are hidden from the outside world.

Principle 3: Use composition over inheritance

One of the popular ways to inherit classes in JavaScript uses the prototype chain. In the following snippet, we have class A that is inherited by class C:

function A(){};
A.prototype.someMethod = function(){};
 
function C(){};
C.prototype = new A();
C.prototype.constructor = C;

However, if we use the revealing module pattern, it makes sense to use composition. It is because we are dealing with objects and not functions (* in fact the functions in JavaScript are also objects). Let’s say that we have a box that implements the observer pattern, and we want to extend it.

var Observer = function() {
    var api = {}, listeners = {};
    api.on = function(event, handler) {};
    api.off = function(event, handler) {};
    api.dispatch = function(event) {};
    return api;
}
 
var Logic = function() {
    var api = Observer();
    api.customMethod = function() {};
    return api;
}

We get the required functionality by assigning an initial value to the api variable. We should notice that every class that uses this technique receives a brand new observer object so there is no way to produce collisions.

Summary

Black box driven development is a nice way to architect your applications. It provides encapsulation and flexibility. BBDD comes with a simple module definition that helps organizing big projects (and teams). I saw how several developers worked on the same project, and they all built their black boxes independently.

WebmakerBarcelona, France, Seattle: A Maker Party Roundup (Week 6)

Maker Party By The Numbers:
Total events during Maker Party: 1,900+
Individuals attending Maker Party events:  85,000+
Number of cities hosting Maker Party events: 385+

In the last six weeks we have seen people all over the world taking a stand for web literacy by throwing Maker Party events. These events are happening across the globe and are teaching critical skills online or offline. If you have been teaching and sharing your skills don’t forget to claim your Skill Sharing Badge. Read more about the highlights from Maker Party this past week:

Net Neutrality Maker Party in Barcelona

Net Neutrality Maker Party in Barcelona

Here’s what happened last week:

MiniCamp -  Jaipur’14  – August 18th, India
MiniCamp was the perfect blend of community building, brainstorming, collaborative activities and hands on making by the Rajasthan community. The 50+ attendees spent the day learning how to develop apps, implement them into the marketplace, build webpages and much more. Read the full day blogpost here.

Net Neutrality Maker Party – August 20th, Barcelona
Datagroup.es hosted a Maker Party teaching the importance of Net Neutrality. Individuals were asked to consider an internet where information was not equal across providers and users, understand why we needed to protect Net Neutrality and how to take action. See the Thimble makes and pictures on the event page.

Geek Girls Carrots Maker Party Pop-Up! – August 21-22nd, Seattle
This collaborative event hosted by Geek Girls Carrots, Pacific Science Center and The Seattle Public Library was a party for all ages! Attendees not only learned the basics of web literacy and how to program with Python/JavaScript languages but also got the chance to improve the Django Carrots Tutorials and explore other programming languages. See a fantastic group GIF, pictures and more in the event report.

Mozilliarian Maker Party – August 21st, France
In conjunction with a ‘Connected Learning’ presentation at the IFLA congress, this event brought together librarians and library lovers for a fun collaborative learning experience based on Connected Learning principles.  See makes, pictures and more on the event page.

Hive Toronto Parapara and Maker Party! – August 18th, Toronto
Hive Toronto hosted a Maker Party with 50 youth from Kid’s Learning Code Design Camp, Regent Park Focus, and a youth media arts center. The used the very cool Parapara Animation, created Kumi mascots and did web mechanics speed dating. Read the full recap, see pictures and find the teaching kits in the event report.

Makes

Resources

  • Share your Maker Party events with this easy, quick and helpful event reporter (it’s also available in Spanish)
  • Make a KUMI papertoy at your next event. A fun activity for all ages

In the News

Get Involved 

Air MozillaService Authentication with Firefox Accounts

Service Authentication with Firefox Accounts Mozilla Intern Vlad Filippov presents: "Service Authentication with Firefox Accounts"

Air MozillaRobust automation: Structured logging in mochitest

Robust automation: Structured logging in mochitest Mozilla Intern Ahmed Kachkach presents "Robust automation: Structured logging in mochitest."

Air MozillaTowards High Entropy, Easy to Remember Passwords for FXA

Towards High Entropy, Easy to Remember Passwords for FXA Mozilla Intern Gregory A. Norcie presenting: "Towards High Entropy, Easy to Remember Passwords for FXA"

Mozilla ResearchJavaScript: Servo’s only garbage collector

by Josh Matthews and Keegan McAllister

A web browser’s purpose in life is to mediate interaction between a user and an application (which we somewhat anachronistically call a "document"). Users expect a browser to be fast and responsive, so the core layout and rendering algorithms are typically implemented in low-level native code. At the same time, JavaScript code in the document can perform complex modifications through the Document Object Model. This means the browser’s representation of a document in memory is a cross-language data structure, bridging the gap between low-level native code and the high-level, garbage-collected world of JavaScript.

We’re taking this as another opportunity in the Servo project to advance the state of the art. We have a new approach for DOM memory management, and we get to use some of the Rust language’s exciting features, like auto-generated trait implementations, lifetime checking, and custom static analysis plugins.

Memory management for the DOM

It’s essential that we never destroy a DOM object while it’s still reachable from either JavaScript or native code — such use-after-free bugs often produce exploitable security holes. To solve this problem, most existing browsers use reference counting to track the pointers between underlying low-level DOM objects. When JavaScript retrieves a DOM object (through getElementById for example), the browser builds a "reflector" object in the JavaScript VM that holds a reference to the underlying low-level object. If the JavaScript garbage collector determines that a reflector is no longer reachable, it destroys the reflector and decrements the reference count on the underlying object.

This solves the use-after-free issue. But to keep users happy, we also need to keep the browser’s memory footprint small. This means destroying objects as soon as they are no longer needed. Unfortunately, the cross-language "reflector" scheme introduces a major complication.

Consider a C++ Element object which holds a reference-counted pointer to an Event:

struct Element {
    RefPtr<Event> mEvent;
};

Now suppose we add an event handler to the element from JavaScript:

elem.addEventListener('load', function (event) {
    event.originalTarget = elem;
});

When the event fires, the handler adds a property on the Event which points back to the Element. We now have a cross-language reference cycle, with an Element pointing to an Event within C++, and an Event reflector pointing to the Element reflector in JavaScript. The C++ refcounting will never destroy a cycle, and the JavaScript garbage collector can’t trace through the C++ pointers, so these objects will never be freed.

Existing browsers resolve this problem in several ways. Some do nothing, and leak memory. Some try to manually break possible cycles, by nulling out mEvent for example. And some implement a cycle collection algorithm on top of reference counting.

None of these solutions are particularly satisfying, so we’re trying something new in Servo by choosing not to reference count DOM objects at all. Instead, we give the JavaScript garbage collector full responsibility for managing those native-code DOM objects. This requires a fairly complex interaction between Servo’s Rust code and the SpiderMonkey garbage collector, which is written in C++. Fortunately, Rust provides some cool features that let us build this in a way that’s fast, secure, and maintainable.

Auto-generating field traversals

How will the garbage collector find all the references between DOM objects? In Gecko‘s cycle collector this is done with a lot of hand-written annotations, e.g.:

NS_IMPL_CYCLE_COLLECTION(nsFrameLoader, mDocShell, mMessageManager)

This macro describes which members of a C++ class should be added to a graph of potential cycles. Forgetting an entry can produce a memory leak. In Servo the consequences would be even worse: if the garbage collector can’t see all references, it might free a node that is still in use. It’s essential for both security and programmer convenience that we get rid of this manual listing of fields.

Rust has a notion of traits, which are similar to type classes in Haskell or interfaces in many OO languages. A simple example is the Collection trait:

pub trait Collection {
    fn len(&self) -> uint;
}

Any type implementing the Collection trait will provide a method named len that takes a value of the type (by reference, hence &self) and returns an unsigned integer. In other words, the Collection trait describes any type which is a collection of elements, and the trait provides a way to get the collection’s length.

Now let’s look at the Encodable trait, used for serialization. Here’s a simplified version:

pub trait Encodable {
    fn encode<T: Encoder>(&self, encoder: &mut T);
}

Any type which can be serialized will provide an encode method. The encode method itself is generic; it takes as an argument any type T implementing the trait Encoder. The encode method visits the data type’s fields by calling Encoder methods such as emit_u32, emit_tuple, etc. The details of the particular serialization format (e.g. JSON) are handled by the Encoder implementation.

The Encodable trait is special, because the compiler can implement it for us! Although this mechanism was intended for painless serialization, it’s exactly what we need to implement garbage collector trace hooks without manually listing data fields.

Let’s look at Servo’s implementation of the DOM’s Document interface:

#[deriving(Encodable)]
pub struct Document {
    pub node: Node,
    pub window: JS<Window>,
    pub is_html_document: bool,
    ...
}

The deriving attribute asks the compiler to write an implementation of encode that recursively calls encode on node, window, etc. The compiler will complain if we add a field to Document that doesn’t implement Encodable, so we have compile-time assurance that we’re tracing all the fields of our objects.

Note the difference between the node and window fields above. In the object hierarchy of the DOM spec, every Document is also a Node. Rust doesn’t have inheritance for data types, so we implement this by storing a Node struct within a Document struct. As in C++, the fields of Node are included in-line with the fields of Document, without any pointer indirection, and the auto-generated encode method will visit them as well.

A Document also has an associated Window, but this is not a containing or "is-a" relationship. The Document just has a pointer to a Window, one of many pointers to that object, which can live in native DOM data structures or in JavaScript reflectors. These are precisely the pointers we need to tell the garbage collector about. We do this with a custom pointer type JS<T> (for example, the JS<Window> above). The implementation of encode for JS<T> is not auto-generated; this is where we actually call the SpiderMonkey trace hooks.

Lifetime checking for safe rooting

The Rust code in Servo needs to pass DOM object pointers as function arguments, store DOM object pointers in local variables, and so forth. We need to register these additional temporary references as roots in the garbage collector’s reachability analysis. If we touch an object from Rust when it’s not rooted, that could introduce a use-after-free vulnerability.

To make this happen, we need to expand our repertoire of GC-managed pointer types. We already talked about JS<T>, which represents a reference between two GC-managed DOM objects. These are not rooted; the garbage collector only knows about them when encode reaches one as part of the tracing process.

When we want to use a DOM object from Rust code, we call the root method on JS<T>. For example:

fn load_anchor_href(&self, href: DOMString) {
    let window = self.window.root();
    window.load_url(href);
}

The root method returns a Root<T>, which is stored in a stack-allocated local variable. When the Root<T> is destroyed at the end of the function, its destructor will un-root the DOM object. This is an example of the RAII idiom, which Rust inherits from C++.

Of course, a DOM object might make its way through many function calls and local variables before we’re done with it. We want to avoid the cost of telling SpiderMonkey about each and every step. Instead, we have another type JSRef<T>, which represents a pointer to a GC-managed object which is already rooted elsewhere. Unlike Root<T>, JSRef<T> can be copied at negligible cost.

We shouldn’t un-root an object if it’s still reachable through JSRef<T>, so it’s important that a JSRef<T> can’t outlive its originating Root<T>. Situations like this are common in C++ as well. No matter how smart your smart pointer is, you can take a bare reference to the contents and then erroneously use that reference past the lifetime of the smart pointer.

Rust solves this problem with a compile-time lifetime checker. The type of a reference includes the region of code over which it is valid. In most cases, lifetimes are inferred and don’t need to be written out in the source code. Inferred or not, the presence of lifetime information allows the compiler to reject use-after-free and other dangerous bugs.

Not only do lifetimes protect Rust’s built-in reference type, we can use them in our own data structures as well. JSRef is actually defined as

pub struct JSRef<'a, T> {
    ...

T is the familiar type variable, representing the type of DOM structure we’re pointing to, e.g. Window. The somewhat odd syntax 'a is a lifetime variable, representing the region of code in which that object is rooted. Crucially, this lets us write a method on Root with the following signature:

pub fn root_ref<'a>(&'a self) -> JSRef<'a, T> {
    ...

What this syntax means is:

  • <'a>: "for any lifetime 'a",
  • (&'a self): "take a reference to a Root which is valid over lifetime 'a",
  • -> JSRef<'a, T>: "return a JSRef whose lifetime parameter is set to 'a".

The final piece of the puzzle is that we put a marker in the JSRef type saying that it’s only valid for the lifetime corresponding to that parameter 'a. This is how we extend the lifetime system to enforce our application-specific property about garbage collector rooting. If we try to compile something like this:

fn bogus_get_window<'a>(&self) -> JSRef<'a, Window> {
    let window = self.window.root();
    window.root_ref()  // return the JSRef
}

we get an error:

document.rs:199:9: 199:15 error: `window` does not live long enough
document.rs:199     window.root_ref()
                    ^~~~~~
document.rs:197:57: 200:6 note: reference must be valid for
    the lifetime 'a as defined on the block at 197:56...
document.rs:197 fn bogus_get_window<'a>(&self) -> JSRef<'a, Window> {
document.rs:198     let window = self.window.root();
document.rs:199     window.root_ref()
document.rs:200 }
document.rs:197:57: 200:6 note: ...but borrowed value is only
    valid for the block at 197:56
document.rs:197 fn bogus_get_window<'a>(&self) -> JSRef<'a, Window> {
document.rs:198     let window = self.window.root();
document.rs:199     window.root_ref()
document.rs:200 }

We also implement the Deref trait for both Root<T> and JSRef<T>. This allows us to access fields of the underlying type T through a Root<T> or JSRef<T>. Because JS<T> does not implement Deref, we have to root an object before using it.

The DOM methods of Window (for example) are defined in a trait which is implemented for JSRef<Window>. This ensures that the self pointer is rooted for the duration of the method call, which would not be guaranteed if we implemented the methods on Window directly.

You can check out the Servo project wiki for more of the details that didn’t make it into this article.

Custom static analysis

To recap, the safety of our system depends on two major parts:

  • The auto-generated encode methods ensure that SpiderMonkey’s garbage collector can see all of the references between DOM objects.
  • The implementation of Root<T> and JSRef<T> guarantees that we can’t use a DOM object from Rust without telling SpiderMonkey about our temporary reference.

But there’s a hole in this scheme. We could copy an unrooted pointer — a JS<T> — to a local variable on the stack, and then at some later point, root it and use the DOM object. In the meantime, SpiderMonkey’s garbage collector won’t know about that JS<T> on the stack, so it might free the DOM object. To really be safe, we need to make sure that JS<T> only appears in traceable DOM structs, and never in local variables, function arguments, and so forth.

This rule doesn’t correspond to anything that already exists in Rust’s type system. Fortunately, the Rust compiler can load "lint plugins" providing custom static analysis. These basically take the form of new compiler warnings, although in this case we set the default severity to "error".

We have already implemented a plugin which simply forbids JS<T> from appearing at all. Because lint plugins are part of the usual warnings infrastructure, we can use the allow attribute in places where it’s okay to use JS<T>, like DOM struct definitions and the implementation of JS<T> itself.

Our plugin looks at every place where the code mentions a type. Remarkably, this adds only a fraction of a second to the compile time for Servo’s largest subcomponent, as Rust compile times are dominated by LLVM‘s back-end optimizations and code generation. The current version of the plugin is very simple and will miss some mistakes, like storing a struct containing JS<T> on the stack. However, lint plugins run at a late stage of compilation and have access to full compiler internals, including the results of type inference. So we can make the plugin incrementally more sophisticated in the future.

In the end, the plugin won’t necessarily catch every mistake. It’s hard to achieve full soundness with ad-hoc extensions to a type system. As the name "lint plugin" suggests, the idea is to catch common mistakes at a low cost to programmer productivity. By combining this with the lifetime checking built in to Rust’s type system, we hope to achieve a degree of security and reliability far beyond what’s feasible in C++. Additionally, since the checking is all done at compile time, there’s no penalty in the generated machine code.

It’s an open question how our garbage-collected DOM will perform compared to a traditional reference-counted DOM. The Blink team has performed similar experiments, but they don’t have Servo’s luxury of starting from a clean slate and using a cutting-edge language. We expect the biggest gains will come when we move to allocating DOM objects within the JavaScript reflectors themselves. Since the reflectors need to be traced no matter what, this will reduce the cost of managing native DOM structures to almost nothing.

If you find this stuff interesting, we’d love to have your help on Rust and Servo! Both are open-source projects with a large number of community contributors. Here are some resources for getting started:

hacks.mozilla.orgBuilding Interactive HTML5 Videos

The HTML5 <video> element makes embedding videos into your site as easy as embedding images. And since all major browsers support <video> since 2011, it’s also the most reliable way to get your moving pictures seen by people.

A more recent addition to the HTML5 family is the <track> element. It’s a sub-element of <video>, intended to make the video timeline more accessible. Its main use case is adding closed captions. These captions are loaded from a separate text file (a WebVTT file) and printed over the bottom of the video display. Ian Devlin has written an excellent article on the subject.

Beyond captions though, the <track> element can be used for any kind of interaction with the video timeline. This article explores 3 examples: chapter markers, preview thumbnails, and a timeline search. By the end, you will have sufficient understanding of the <track> element and its scripting API to build your own interactive video experiences.

Chapter Markers

Let’s start with an example made popular by DVD disks: chapter markers. These allow viewers to quickly jump to a specific section. It’s especially useful for longer movies like Sintel:

The chapter markers in this example reside in an external VTT file and are loaded on the page through a <track> element with a kind of **chapters. The track is set to load by default:

<video width="480" height="204" poster="assets/sintel.jpg" controls>
  <source src="assets/sintel.mp4" type="video/mp4">
  <track src="assets/chapters.vtt" kind="chapters" default>
</video>

Next, we use JavaScript to load the cues of the text track, format them, and print them in a controlbar below the video. Note we have to wait until the external VTT file is loaded:

track.addEventListener('load',function() {
    var c = video.textTracks[0].cues;
    for (var i=0; i<c.length; i++) {
      var s = document.createElement("span");
      s.innerHTML = c[i].text;
      s.setAttribute('data-start',c[i].startTime);
      s.addEventListener("click",seek);
      controlbar.appendChild(s);
    }
});

In above code block, we’re adding 2 properties to the list entries to hook up interactivity. First, we set a data attribute to store the start position of the chapter, and second we add a click handler for an external seek function. This function will jump the video to the start position. If the video is not (yet) playing, we’ll make that so:

function seek() {
  video.currentTime = this.getAttribute('data-start');
  if(video.paused){ video.play(); }
};

That’s it! You now have a visual chapter menu for your video, powered by a VTT track. Note the actual live Chapter Markers example has a little bit more logic than described, e.g. to toggle playback of the video on click, to update the controlbar with the video position, and to add some CSS styling.

Preview Thumbnails

This second example shows a cool feature made popular by Hulu and Netflix: preview thumbnails. When mousing over the controlbar (or dragging on mobile), a small preview of the position you’re about to seek to is displayed:

This example is also powered by an external VTT file, loaded in a metadata track. Instead of texts, the cues in this VTT file contain links to a separate JPG image. Each cue could link to a separate image, but in this case we opted to use a single JPG sprite – to keep latency low and management easy. The cues link to the correct section of the sprite by using Media Fragment URIs.Example:

http://example.com/assets/thumbs.jpg?xywh=0,0,160,90

Next, all important logic to get the right thumbnail and display it lives in a mousemove listener for the controlbar:

controlbar.addEventListener('mousemove',function(e) {
  // first we convert from mouse to time position ..
  var p = (e.pageX - controlbar.offsetLeft) * video.duration / 480;
 
  // ..then we find the matching cue..
  var c = video.textTracks[0].cues;
  for (var i=0; i<c.length; i++) {
      if(c[i].startTime <= p && c[i].endTime > p) {
          break;
      };
  }
 
  // ..next we unravel the JPG url and fragment query..
  var url =c[i].text.split('#')[0];
  var xywh = c[i].text.substr(c[i].text.indexOf("=")+1).split(',');
 
  // ..and last we style the thumbnail overlay
  thumbnail.style.backgroundImage = 'url('+c[i].text.split('#')[0]+')';
  thumbnail.style.backgroundPosition = '-'+xywh[0]+'px -'+xywh[1]+'px';
  thumbnail.style.left = e.pageX - xywh[2]/2+'px';
  thumbnail.style.top = controlbar.offsetTop - xywh[3]+8+'px';
  thumbnail.style.width = xywh[2]+'px';
  thumbnail.style.height = xywh[3]+'px';
});

All done! Again, the actual live Preview Thumbnails example contains some additional code. It includes the same logic for toggling playback and seeking, as well as logic to show/hide the thumbnail when mousing in/out of the controlbar.

Timeline Search

Our last example offers yet another way to unlock your content, this time though in-video search:

This example re-uses an existing captions VTT file, which is loaded into a captions track. Below the video and controlbar, we print a basic search form:

<form>
    <input type="search" />
    <button type="submit">Search</button>
</form>

Like with the thumbnails example, all key logic resides in a single function. This time, it’s the event handler for submitting the form:

form.addEventListener('submit',function(e) {
  // First we’ll prevent page reload and grab the cues/query..
  e.preventDefault();
  var c = video.textTracks[0].cues;
  var q = document.querySelector("input").value.toLowerCase();
 
  // ..then we find all matching cues..
  var a = [];
  for(var j=0; j<c.length; j++) {
    if(c[j].text.toLowerCase().indexOf(q) > -1) {
      a.push(c[j]);
    }
  }
 
  // ..and last we highlight matching cues on the controlbar.
  for (var i=0; i<a.length; i++) {
    var s = document.createElement("span");
    s.style.left = (a[i].startTime/video.duration*480-2)+"px";
    bar.appendChild(s);
  }
});

Three time’s a charm! Like with the other ones, the actual live Timeline Search example contains additional code for toggling playback and seeking, as well as a snippet to update the controlbar help text.

Wrapping Up

Above examples should provide you with enough knowledge to build your own interactive videos. For some more inspiration, see our experiments around clickable hot spots, interactive transcripts, or timeline interaction.

Overall, the HTML5 <track> element provides an easy to use, cross-platform way to add interactivity to your videos. And while it definitely takes time to author VTT files and build similar experiences, you will see higher accessibility of and engagement with your videos. Good luck!

Mozilla Korea인도 Intex社, 33달러 초저가 Firefox OS폰 CloudFx 출시

Mozilla의 Firefox OS 파트너인 인도 Intex사는 Rs 1,999(33달러)짜리 초저가 스마트폰인 Cloud Fx를 8월 25일 출시하였습니다. 3.5인치 HVGA 터치스크린에 GSM (2G/2.5G) 듀얼 SIM을 지원하고 2메가 픽셀 카메라 및  1GHz CPU에 128MB 내부 메모리에 4GB 사용자 메모리를 제공합니다.

intex_cloud_fix_all_sides

소개 동영상은 아래와 같습니다.

현재 Snapdeal.com 홈페이지에서 온라인으로 구매 가능하며, 1차로 인도 내 400여곳에서 판매도 개시한다고 합니다. 이후 판매 매장을 늘릴 계획을 가지고 있습니다. Intex는 인도 전역에 50,000개의 매장을 보유하고 있습니다. 또한, 현재 70%의 인도 국민들이 피처폰을 사용하고 있어 이들이 자연스럽게 스마트폰으로 옮겨가기 위한 최고의 제품이 될 것으로 기대하고 있습니다.

이와 더블어 인도의 Spice Mobile 역시 이번 주 금요일에 Spice Fire One Mi-FX1이라는 기종의 Rs2,299(38달러) 초저가 스마트폰을 출시 합니다. 이 스마트폰은 GSM (2G/2.5G) 듀얼 SIM, 1 Ghz 프로세서, 8.89cm 화면의 HVGA 및 2MP 카메라 및 1.3 MP 전면 카메라로서 가장 저렴한 경쟁 안드로이드폰은 Micromax Bolt A24 보다도 15% 저럼합니다.

cloud-fx-1

초저가 스마트폰은 올해 MWC에서 발표한 Spectrum의 칩셋 기술을 활용한 것으로 기존 중저가 안드로이드폰 보다 훨씬 저렴하고 유사한 성능을 내고 있습니다. 인도 구매자에게는 Airtel 통신사에서 1GB의 무료 데이터 용량을 2개월간 제공하고 운영체제에서 데이터 압축 과정을 통해 데이터 사용량도 줄일 수 있습니다.

Mozilla COO인 Li Gong은 “Intex Cloud FX를 시작으로 인도 및 아시아 지역에 첫 Firefox OS폰을 제공하게 되었으며, 소비자의 피드백을 받아 개방형 모바일 운영체제인 Firefox OS를 더 확대할 수 있게 되었으며, 초저가의 새로운 스마트폰 영역을 개척하여, 전 세계의 피처폰 사용자가 쉽게 모바일 웹 환경을 경험할 수 있게 되었다”고 밝혔습니다.

- 편집자주: 당 휴대폰은 국내에 GSM 및 2G/2.5G 환경이 제공되지 않으므로 한국내에서 전화 통화 및 데이터 이용이 불가합니다.

WebmakerNew Firefox start page invites millions to learn a little code

Interactive start page gives users a taste of coding and digital creativity

For the first time ever, Firefox users will be able to play around with the code that makes up the familiar Firefox start page. A new experience launching today lets users change the background color of the page, peeking under the hood to remix the code that makes the page — and the web — work.

We hope it will give millions of Firefox users a taste of what it’s like to be a creator, not just consumer, of the Web. It’s easy to start coding and creating online, in the spirit of Mozilla Webmaker and our global Maker Party campaign to teach and learn digital skills.

The Firefox start page is viewed about 20 million times each day in the United States. This is the first time we’ve opened it up to users like this. To try it for yourself, just open a new Firefox window and click on the link below the search bar. Don’t see it yet? Just click here: http://mzl.la/startpage

You can interact with the code that controls the page’s background color, watching the changes you make appear in real time. It’s a chance to learn a bit about HTML and CSS, the building blocks behind your favorite sites on the Web.

Of course, this is just a start — you can go further at Webmaker.org to explore more tools for building, remixing, teaching and playing with code.

Maker Party

This new interactive Firefox start page comes in the final weeks of our global Maker Party campaign. Running from June 15 to September 15, Maker Party promotes web literacy through more than 2,000 hands-on teaching and learning events hosted by Mozilla community members in 400 cities around the world.

Get involved

QMOFirefox Aurora 33 Testday results

Hello everyone!

On Friday, August 22nd, we held a new Testday, for Firefox 33 Aurora. Thank you all for your effort and involvement in test execution and bug triage. We’ve had multiple tests run in MozTrap, some triaged and a new bug filed in Bugzilla.

Detailed results about the work done can be found in this etherpad.

Special thanks are in order for: kenkon (Aurore), Patrakel, segumarc, Florin_, gaby2300, lizzard, and all our moderators! Your work is always greatly appreciated.

Software CarpentrySoftware Carpentry at Brazilian Open Science Conference

Last week, Raniere Silva and Alex Viana attended at Brazilian Open Science Conference where they ran a Git course for Software Carpentry and Alex gave a talk about Software Carpentry (like the one that Damien Irving gave at PyCon Australia). Our workshop was a great time and from the feedbacks every student like it. One of the students said:

Very didactic, the instructors showed much care, dedication and attention with the students.
and another one
Very good, from the basic to complex in a easy way.

This course was different from most all of previous Git lesson taught by Software Carpentry instructors because (1) we used Git GUI instead of the command line and (2) we teach git fetch and git merge instead of git pull. Related with the use of Git GUI we choose it because we won't have time to teach the shell lessons and all students hadn't an programmer background. I was a little afraid that the GUI will be difficult for students to follow but this didn't happen. About teach git fetch and git merge we do that as one experiment to get data from one of our internal discussion and look like that students didn't problem with that.

Most all the students complain about the short time for the lesson although we had three hours of class. In my opinion this complaints was due, in part, because of the fact that we start the lesson half one hour later since students are later and we need to end it on the scheduled time.

Other complains raised by the students was: have more exercises and explore the doors opened by this tool. I and Alex will try to address this in the others workshops here in Brazil and will be happy to get suggestions on how to do that.

WebmakerSharing: an essential part of web literacy

Papertoy

Introduction

In our recently-published whitepaper Why Mozilla cares about Web Literacy we talk about the importance of sharing on the web:

Mozilla believes that the use of the Webmaker tools and teaching kits within an online training environment helps facilitate participatory cultures where there are “relatively low barriers to artistic expression and civic engagement, strong support for creating and sharing creations, and some type of informal mentorship” (Jenkins, et al., 2009, p. xi).

One way in which we’re encouraging and recognising sharing is through the use of Open Badges. We recently launched three new Webmaker contribution badges to serve as entry points for people wanting to begin their web literacy journey and to get involved with Webmaker.

The Web Literacy Skill Sharer badge

One of the three new badges we’ve introduced is the Web Literacy Skill Sharer badge.

Web Literacy Skill Sharer badge

Earning this badge is an ideal way for community members to demonstrate their commitment to web literacy. It’s relatively easy to earn as it has a single criterion: “Teach someone else a web literacy skill and share your experience on the web.”

Here’s what to do:

  1. Explore the competencies listed in the Web Literacy Map
  2. Choose one of the 15 competencies that you feel especially passionate about
  3. Look at the list of skills underpinning that competency, and then share one of those with someone else – either using one of the suggested resources or by inventing your own way of teaching it
  4. Share a blog post, video or image online illustrating how you taught the web literacy skill
  5. Apply for the badge by clicking the ‘Apply’ button below

Earning this badge could take anywhere from around 10 minutes to one hour, depending on the complexity of what you share – and your current knowledge/skill level.

Note: you don’t have to use Webmaker tools and resources to provide evidence for this badge!

Going further: the WebLitMapper

WebLitMapper

Earlier this year we launched a prototype known as the Web Literacy Mapper – or WebLitMapper for short. This site allows community members to collate resources from around the web that correspond to particular parts of the Web Literacy Map. It works in a similar way that users of Delicious, Diigo and Pinterest would save links to those services. You may be interested to discover that using the WebLitMapper is mentioned in the criteria for the Webmaker Super Mentor badge.

It’s worth having the bookmarklet installed in your bookmarks bar in case you come across something of interest as you browse the web. If you discover a resource that you think is good enough to be featured on one of the competency pages (e.g. Privacy) you’ll find a method of doing that on the page itself (“Suggest your own links and resources to add”).

Maker Party

Maker Party

We’re currently in the second half of our yearly Maker Party campaign. Over the past few weeks our amazing community members have organised over 1,800 events in over 70 countries, teaching web literacy to their friends, families and communities. We’re delighted by this global effort and want to recognise the work that goes into teaching others through hands-on making and exploration.

Now is a perfect time to organise your Maker Party event. Using Maker Party resources, you can build on the success of previous events, remixing teaching kits and share your web literacy knowledge and skills. As an organiser of an event  you can request gear – which may include t-shirts! In addition, once you’ve run and documented your event, you can apply for the Web Literacy Skill Sharer badge (see above) as well as the Event Host and Teaching Kit Remixer badges:

Event Host badge   Teaching Kit Remixer badge

If you need guidance on how to apply for these badges, check out this post: HOWTO: apply for Webmaker badges.

Conclusion

Sharing is a fundamental part of web literacy; it’s how the web works. Show that sharing is caring by earning your Web Literacy Skill Sharer badge and hosting a Maker Party event. We’re looking forward to seeing your submissions!

 Main image CC BY-NC-SA DGuarch

Air MozillaJS support, moving to Elastic Search, and searching using types.

JS support, moving to Elastic Search, and searching using types. Marcell Vazquez-Chanlatte, "JS support, moving to Elastic Search, and searching using types."

Air MozillaNative Android Video Decoding in Fennec

Native Android Video Decoding in Fennec Andrew McDonough, "I will describe and demonstrate a new Platform Decoder Module I wrote that uses native Android APIs to decode H264 video and AAC audio. This brings HTML5 video to Android, and allows truly fragmented playback of MP4s"

Mozilla Web DevelopmentBeer and Tell – August 2014

Once a month, web developers from across the Mozilla Project get together to upvote stories on Hacker News from each of our blogs. While we’re together, we usually end up sharing a bit about our side projects over beers, which is why we call this meetup “Beer and Tell”.

There’s a wiki page available with a list of the presenters, as well as links to their presentation materials. There’s also a recording available courtesy of Air Mozilla.

Frederik Braun: Room Availability in the Berlin Office

freddyb shared (via a ghost presentation by yours truly) a small webapp he made that shows the current availability of meeting rooms in the Mozilla Berlin office. The app reads room availability from Zimbra, which Mozilla uses for calendaring and booking meeting rooms. It also uses moment.js for rendering relative dates to let you know when a room will be free.

The discussion following the presentation brought up a few similar apps that other Mozilla offices had made to show off their availability, such as the Vancouver office’s yvr-conf-free and the Toronto office’s yyz-conf-free.

Nigel Babu: hgstats

nigelb shared (via another ghost presentation, this time split between myself and laura) hgstats, which shows publicly-available graphs of the general health of Mozilla’s mercurial servers. This includes CPU usage, load, swap, and more. The main magic of the app is to load images from graphite, which are publicly visible, while graphite itself isn’t.

nigelb has offered a bounty of beer for anyone who reviews the app code for him.

Pomax: Inkcyclopedia

Pomax shared an early preview of Inkcyclopedia, an online encyclopedia of ink colors. Essentially, Pomax bought roughly 170 different kinds of ink, wrote down samples with all of them, photographed them, and then collected those images along with the kind of ink used for each. Once finished, the site will be able to accept user-submitted samples and analyze them to attempt to identify the color and associate it with the ink used. Unsurprisingly, the site is able to do this using the RGBAnalyse library that Pomax shared during the last Beer and Tell, in tandem with RgbQuant.js.

Sathya Gunasekaran: screen-share

gsathya shared a screencast showing off a project that has one browser window running a WebGL game and sharing its screen with another browser window via WebRTC. The demo currently uses Chrome’s desktopCapture API for recording the screen before sending it to the listener over WebRTC.


Alas, we were unable to beat Hacker News’s voting ring detection. But at least we had fun!

If you’re interested in attending the next Beer and Tell, sign up for the dev-webdev@lists.mozilla.org mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!

See you next month!

Open Policy & AdvocacyTrust should be the currency

At Mozilla, we champion a Web  that empowers people to reach their full potential and be in control of their online lives. In my role at Mozilla this means advocating for products, policies and practices that respect our users and create trusted online environments and experiences.  We believe trust is the most important currency on the Web – and when that trust is violated, the system fails.

I have been spending a lot of time with our Content Services team as they work on their new initiatives.  Their first challenge is tackling the online advertising ecosystem.  This is hard work but extremely important.  Our core values of trust, transparency and control are just as applicable to the advertising industry as to any other, but they aren’t widely adopted there.

Today, online advertising is rife with mistrust.  It is opaque for most users because the value exchange is not transparent.  While it should be trust, the prevailing Web currency is user data – much of the content is free because publishers and websites generate revenue through advertising.  At its core, this model is not new or unique, it is common in the media industry (e.g., broadcast television commercials and newspapers that are ad supported).  To improve monetization, online ads are now targeted based on a user’s browsing habits and intentions.  This isn’t a bad thing when done openly or done with consent.  The problem is that this “personalization” is not always transparent, leaving users in the dark about what they have traded for their content.  This breaks the system.

Our users and our community have told us – through surveys, comments and emails – that transparency and control matter most to them when it comes to online advertising.  They want to know what is happening with their data; they want to control what data is shared, understand how their data is used and what they get for that exchange.  They are willing to engage in the value exchange and allow their data to be used if they understand what happens next.  Our users want trust (and not their data) to be the prevailing currency.  We believe that without this shift in focus, users will limit access to their data and will block ads.

We want our users to not only trust us but to be able to trust the Web. We want to empower their choices and help them control their online experience. This is why we pioneered the Do Not Track (DNT) initiative.  DNT relies on advertisers, publishers and websites to respect a user’s preference. Unfortunately, many participants in the online advertising ecosystem do not modify their behavior in response to the DNT signal.  In this instance, user choice is not being respected.  So, we must do more for the user and continue to innovate.

We are doing this by working within the ecosystem to create change.  We are testing our new tiles feature in Firefox and working to ensure that it provides personalization with respect and transparency built in. We are building DNT and other user controls into the tiles experiments and working to establish these foundational elements with our partners.  We are providing users with more information about their Web presence through Lightbeam, and will be testing new privacy initiatives that give users more control over the flow of their data.  We want to bring relevant and personalized content to our users while empowering control that inspires trust.

We need to see a renewed focus of trust, transparency and control on the Web as a whole.  We can all do better.  We want to see more products and services (and not just in online advertising) developed with those ideals in mind.  For our part, we will continue to do more to innovate and create change so that we deserve your trust.

 

WebmakerMozFest 2014: session proposal deadline extended!

We’re very excited about this year’s Mozilla Festival (24-26 October, London). It really is true that you can arrive with an idea and leave with a community! You can get an flavour of some of what will be going on through the 11 tracks:

  • Build and Teach the Web – Keep the web wild through hands-on making with innovative tools and teaching the web as a community.
  • Open Web With Things – Escape the limitations of your computer and build the web using sensors, circuits and good old paper and scissors.
  • Web in Your Pocket – Explore opportunities in the booming world of the open web  on mobile. How can  we experiment & tinker to customize our own  experience on our phones?
  • Source Code for Journalism – Design next-generation web solutions to solve critical  issues facing news organizations and help journalism thrive on the open  web.
  • Open Science and the Web – Examine the potential of the open web to re-define how we experiment, analyze and share scientific knowledge.
  • Art and Culture of the Web – An exploration of the programs, practices and inspirations of open and networked digital art forms.
  • Open Badges Lab – Challenge  the conventional system of recognizing skills  and learning. Celebrate achievements from Open Badge creators and  issuers.
  • Hive Learning Networks - Join this lab for people working on building local city  learning networks (Hives) and how they can better globally connect to  share learning  experiences for youth and digital media.
  • Musicians and Music Creators on the Open Web – Play a role and explore what it takes to make music on the open web.
  • Policy & Advocacy – Privacy, Security, and Building the Movement to protect the free and open web.
  • Open Data – Uncover the data on the web and in our world that will help us better inform and organize our communities

If any of those sound like the kind of thing you’d like to run a practical, hands-on session about, we want to hear from you! For your proposal to be the best it can be, it’s worth bearing in mind that we’ll need to hear how you’re going to make your session inclusive, inspiring and inviting. We’ll need real examples as well as some detail on how you plan to structure your session.


Propose a MozFest 2014 session: http://2014.mozillafestival.org/propose


In order to get give people coming back from vacation time to submit session proposals, we’ve decided to extend the submission deadline to Friday 29th August. Those who have their proposals accepted will be notified soon afterwards.

Questions? Problems? Email: festival@mozilla.org

Software CarpentryThe Fifth ANGUS Course

Titus Brown recently blogged a summary of the fifth run of the Analyzing Next Generation Sequencing (ANGUS) course at Michigan State. It includes some interesting observations on what's working and what needs to be improved, and some thoughts on assessment—he'd welcome feedback.

Mozilla Add-ons BlogAdd-ons Update – Week of 2014/08/20

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

  • Most nominations for full review are taking less than 6 weeks to review.
  • 114 nominations in the queue awaiting review.
  • Most updates are being reviewed within 3 weeks.
  • 79 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 3 weeks.
  • 113 preliminary review submissions in the queue awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 32 Compatibility

The Firefox 32 compatibility blog post is up. The automatic compatibility validation will be run soon.

As always, we recommend that you test your add-ons on Beta and Aurora to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running each content tab in a different one. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the near future. We will also begin contacting developers about add-ons malfunctioning with e10s very soon.

Air MozillaAsynchronous transformation for Emscripten

Asynchronous transformation for Emscripten You might have learned that there is no sleep function in JavaScript, which is no longer true now with Emscripten.

Air MozillaGrowing the Community with First-Class Citizen Localization

Growing the Community with First-Class Citizen Localization Theo Chevalier, "I will give you an overview of why localization matters, what we can do to grow the community with localization, what YOU can do to help, and how we can ensure we ship high quality localization."

Air MozillaThe curious case of TLS revocation checks

The curious case of TLS revocation checks 1:00- Harsh Pathak, "The curious case of TLS revocation checks"

Air MozillaProduct Coordination Meeting

Product Coordination Meeting Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

Products Teammozilla::pkix ships in Firefox!

In April, we announced an upcoming certificate verification library designed from the ground up to be fast and secure. A few weeks ago, this new library – known as “mozilla::pkix” – shipped with Firefox and is enabled by default. Please see the original announcement for more details.
Along with using more verifiably secure coding practices, we took the opportunity to closely adhere to the X.509 certificate verification specifications for the Internet. For example, we prevent certificates from being misused in ways that legacy libraries often do not. This protects user data and promotes an overall more secure Web.
However, this sometimes comes at a compatibility cost. Some certificates issued by certificate authorities not in Mozilla’s Root CA program may no longer work in the same way. We are currently evaluating how we can best balance security with usability with regard to these certificates.
If you encounter compatibility issues, please read the Certificate Primer which contains information for creating a compatible certificate hierarchy.

hacks.mozilla.orgLaunching Open Web Apps feedback channels – help us make the web better!

About three months ago we launched a feedback channel for the Firefox Developer Tools, and since it was a great success, we’re happy announce a new one for Open Web Apps!

For Developer Tools, we have, and keep on getting, excellent suggestions at http://mzl.la/devtools, which has lead to features coming from ideas there being implemented in both Firefox 32 & 33 – the first ideas shipped in Firefox only 6 weeks after we launched the feedback channels!

Your feedback as developers is crucial to building better products and a better web, so we want to take this one step further.

A channel for Open Web Apps

We have now just opened another feedback channel on UserVoice about Open Web Apps, available at http://mzl.la/openwebapps

It is a place for constructive feedback around Open Web Apps with ideas and feature suggestions for how to make them more powerful and a first-class citizen on all platforms; desktop, mobile and more.

What we cover in the feedback channel is collecting all your ideas and also updating you on the different areas we are working on. In many cases these features are non-standard, yet: we are striving to standardize Apps, APIs, and features through the W3C/WHATWG – so expect these features to change as they are transitioned to become part of the Web platform.

If you want to learn more about the current state, there’s lots of documentation for Open Web Apps and WebAPIs on MDN.

Contributing is very easy!

If you have an idea for how you believe Open Web Apps should work, simply just go to the feedback channel, enter a name and an e-mail address (no need to create an account!) and you’re good to go!

In addition to that, you have 10 votes assigned which you can use to vote for other existing ideas there.

Just make sure that you have an idea that is constructive and with a limited scope, so it’s actionable; i.e. if you have a list of 10 things you are missing, enter them as a separate ideas so we can follow up on them individually.

We don’t want to hear “the web sucks” – we want you to let us know how you believe it should be to be amazing.

What do you want the web to be like?

With all the discussions about web vs. native, developers choosing iOS, Android or the web as their main target, PhoneGap as the enabler and much more:

Let us, and other companies building for the web, know what the web needs to be your primary developer choice. We want the web to be accessible and fantastic on all platforms, by all providers.

Share your ideas and help us shape the future of the web!

about:communityGrow Mozilla discussion this Thursday

If you’re interested in helping new people get involved with Mozilla, join us Thursday for an open community building forum.

WebmakerSlovenia, Tokyo, New York: A Maker Party Roundup (Week 5)

Maker Party By The Numbers:
Total events during Maker Party: 1,830+
Individuals attending Maker Party events:  77,550+
Number of cities hosting Maker Party events: 365+

All over the world we are seeing the awesome effect of people teaching the web with Maker Party. We want to recognize the hard-work of everyone who has been involved teaching web literacy skills, online or offline, so if you have been sharing your skills make sure you claim your Skill Sharing Badge . Let’s take a look at the Maker Party events that inspired us last week:

Pic from Maker Party in Tokyo

Web and Satellite workshop in Tokyo

Here’s what happened last week:

Brooklyn College Community Partnership Teen Makerspace Open House – August 4-14th, New York
This two week long event was the first drop-in teen makerspace in Brooklyn. It brought together 12 high school students, along with Brooklyn College students, BCCP staff, makers and others. Read all about the packed final day of making here or watch the 63 second video below.

India Day of Independence- August 15th, Global
On August 15th individuals everywhere celebrated India’s Day of Independence by participating in an online maker party to make, learn, teach and share the Indian culture, history, and diversity. Find out how it went here.

Web and Satellite Workshop  – August 15th, Tokyo
At this cool party attendees designed characters and stories for the Cansat satellite which was launched on August 15th by the Tokai University Satellite Project. The stories were based on sensor data from the satellite and the actual flight data from the satellite. Get more information here.

Maker Party – August 16th, Slovenia
A small and enthusiastic group gathered at the Center Si.mobil Ljubljana wanting to learn and develop new skills by using the many Webmaker tools. You can see some of what was made here.

Maker Party: Simple HTML for Nonprofits – August 14th, San Francisco
This Maker Party by included hands-on training by Aspiration Tech targeted at nonprofit staff and volunteers that are interested in a better understanding of how to craft effective HTML for Email Newsletters and familiarize themselves with how HTML works. Find out more information.

Makes

Resources

In the News

Get Involved 

about:communityQuality and Impact and the Future of the Grow Program

As you know, the Grow program was initially designed to to align with the “Enable Communities that have Impact” goal. The events were intended to mentor and train core contributors to help us bring our products to market and bolster our efforts to recruit new contributors in region.

Since then, we’ve received a lot of extremely helpful and direct feedback from participants, community members who did not attend and from a number of leaders within the Project. The sentiment, echoed on the Project call yesterday, was that the new focus was too much about increasing the size of our community, and not enough about the quality and impact of contribution.

Based on input from our community, and a lot of discussion last week during the community building team’s work week, we’ve made the very difficult decision to cancel all upcoming Grow events this year, including Tunisia, which was scheduled for this September. The decision was made so that the team can focus on launching a redesigned program aimed at providing more interesting and meaningful opportunities to contribute and innovate. This is very late notice, particularly for Mozillians who have spent time and energy completing applications for Tunisia, creating content, and helping with logistics and planning for the event. Know that we would never have made such a decision if we did not feel in our hearts it was the right one.

What’s next – refocus on quality and impact

We are really looking forward to seeing what opportunities we will have to come together as Mozillians in the near future. We know doing that (bringing communities together) is essential for individual, community and Project growth so planning around this isn’t going to stop – it just may look a little different. We’ve been thinking about things like smaller group meet-ups, either organized by Mozilla or as part of other, larger events like an upcoming open-source conference, where communities work together to provide solutions to very specific problems.

Now that we’ve made the tough decision about Grow, we can shift our focus towards a new program — one that focuses on the quality and impact of contributions and our community has a real, strategic, concerted impact on our goals this year.

We have some ideas already are we’re guessing you have some too so let’s start brainstorming! Here is the challenge we leave you with…

How might we design a program that results in contributions that are more fulfilling to our contributors and have a meaningful impact on our goals this year.

Please share your ideas here: https://etherpad.mozilla.org/grow14

- The Community Building Team

Meeting NotesSeaMonkey: 2014-08-19

Agenda

  • Who’s taking minutes? -> IanN

  • Nominees for Friends of the Fish Tank:
    • Adrian Kalla

Action Items

(who needs to do what that hasn’t been recorded in a bug)
We should assign people to the open items.

NEW

OPEN

  • http://weblogs.mozillazine.org/seamonkey/ has not been updated since November 2012, the last version listed is 2.14 (bug 956561); move blog to blog.mozilla.org if possible Assigned: mcsmurf.

    • blog account has been created in bug 973886

    • Callek has imported old blogs from mozillazine
    • some sprucing / branding needs to happen next
  • bug 998807 Sync account creation or device pairing fails with exception in BrowserIDManager
    • mcsmurf will look into this

CLOSED

Status of the SeaMonkey Buildbot Master and Tree

  • Buildmaster is up and running.

    • Due to the master having some mysql issues, Callek has put a halt on the mysql updates, which affects the tbpl. So nothing is showing in tbpl atm.
  • comm-* will be building out of mozilla-* (bug 648979 etc.). Jcrammer has completed the coding. The decision to merge c-c into m-c has been kicked down the road into the next quarter or two.
  • [19th August 2014 update]

    • All available linux64 machines are up and running buildbot (CentOS 6.5)

    • Current round of changes have been reviewed and landed.
    • One final round about to be reviewed.
      • The following are ‘old’ info being kept as a reference:

        • Migrating our Linux builders to CentOS 6 bug 795354. Puppetmaster has been updated. Ewong is able to login to these hosts and buildbot is installed. We still need to get everything setup for parity and do some slight tweaks to the puppet config, but we’re pretty close to useable.

        • In Progress: 2.28 beta and final will depend on build system working again for Gecko 31.0
        • bug 983536 libpango version >= 1.22.0 required on Linux.(should be fixed when bug 795354 is fixed).
        • bug 977676 SeaMonkey’s puppet broken due to requirement of ffxbld ldap password.
        • bug 943740 is tracking the progress (or lack of one) in building trunk and aurora on Linux & Mac from the downloading user’s POV.
        • bug 840426 tracks the buildbot-config and buildbotcustom code changes to support Mock on our linux* slaves.
        • bug 853720 tracks the builders not recognizing mozcrash. (Not exactly sure if it’s relevant still, since our builders have been so perma-red for some time; but putting this here just in case.)
    • We are perma-orange on comm-central, comm-aurora and comm-beta due to problems with tests
      • Windows en-US builds are being successfully compiled but tests are not working due to a dependency on python 2.7.3.
  • pymake has been discontinued. We need to install the latest Mozilla-build and tooltool on our windows builders (tracked by bug 1023644 )
  • No langpacks since 29th August 2013 on trunk. Needs investigating.
    • Windows and Mac trunk langpacks directories have been removed on the FTP server, maybe for lack of recent XPIs (later than 2.20a1). Latest Linux langpacks are dated 29 August. Callek told Tonymec on IRC he has a hunch about why but more pressing things to do first.

    • In Bug 902876 Comment 12 Mcsmurf is waiting for feedback from the build team on how to proceed.

Release Train

  • The plan will to concentrate on delivering 2.29 and potentially a security release for 2.26.

    • Beta based on Gecko 32 will hopefully be tagged tonight.

    • Since this is the first test of the new build code, the process for beta releasing might be a bit rocky to start with.
    • There will be at least two beta releases.
    • The final release will be about a week after the Firefox one, to ensure any major issues have been shaken out.
    • Callek / ewong will post / blog about it soon.
  • Useful Firefox Release Schedule link: Releases Scheduling

Extensions and Plugins Compatibility Tracking

  • Firefox & Thunderbird Add-on Converter for SeaMonkey

  • This tool goes a little further beyond simply modifying install.rdf – it also identifies a few more other things in the code that are Firefox or Thunderbird specific and attempts to change them. Of course, not all extensions can be ported so easily to SeaMonkey since there’s only so much an automated tool like that can do.

    Add-on Converter for SeaMonkey: http://addonconverter.fotokraina.com/

    • There is a long list of Firefox and Thunderbird extensions that have been successfully converted in the Mozillazine thread[1]. Can someone go through the thread and add the list of successful conversions to SeaMonkey/AddonCompat.
  • InvisibleSmiley has been working with the author of Nostalgy to make it work with recent TB/SM versions. The latest, fully compatible version is only available from his homepage though.
  • See Basics page. Please only list current changes here.
  • Addon Compatibility Listings
  • Ratty filed bug 957149 to push an updated version of DOMi to addons.mozilla.org to pick up the latest fixes. Depends on:
  • Our build team needs to automate DOMI branch selection rather than having to tweak the client.py every 6 weeks. bug 763506

2.x (Last, Current, Next)

  • [From a previous meeting:] There is a problem with the metrics server, so no current data is available

  • See Basics page for the usual reminders.
2.26

open tracking (0)
tracking requests (1)
targeted (0)
fixed (30)

2.28

open tracking (0)
tracking requests (1)
targeted (0)
fixed (16)

2.Next
  • Stalled. Needs a kick.

    • bug 937809 Add DuckDuckGo to the default search engines list.

    • bug 815954 Click-to-Play: Port bug 812562 (click-to-play blocklisted plugins: reshow urlbar notification as with normal click-to-play).
    • bug 476108 GetShortPathNameW fails under some NTFS junctions [patchlove].
  • Current breakages:
    • bug 998807 Sync account creation or device pairing fails with exception in BrowserIDManager needs an owner

    • bug 995737 adapt seamonkey for the ab remote content policy change; use permission manager instead of address book property.
  • Mozilla-central bugs that affect us:
    • Our front end Sync UI needs to be updated as the old backend is going away in Gecko/Firefox 31. See: New Firefox Sync has landed in Firefox Nightly. Tracked in:

      • bug 998807 Sync account creation or device pairing fails with exception in BrowserIDManager.

      • bug 1003434 Add support for about:sync-progress.
    • A lot of these bugs are due to mozilla-central switching from synchronous APIs to Asynchronous APIs.
    • bug 566746 (asyncFormHistory) Form history should use asynchronous storage API. Tracked in:
      • bug 912031 Use Asynchronous FormHistory.jsm in place of nsIFormHistory2 in Suite.
    • bug 769764 move proxy resolution to separate thread and remove sync api. Tracked in:
      • MailNews bug 791645 Rewrite calls to synchronous nsIProtocolProxyService::DeprecatedBlockingResolve with Async code before DeprecatedBlockingResolve disappears as well.
    • bug 793634 Force builds to be compatible with gtk 2.18/glib 2.22. Tracked in:
      • bug 795354 Migrate SeaMonkey Linux builders to CentOS 6.
    • bug 846635 Use asynchronous getCharsetForURI in getShortcutOrURI. bug 834543 Add asynchronous version of setCharsetForURI and getCharsetForURI. Tracked in:
      • bug 896947 Use asynchronous version of setCharsetForURI and getCharsetForURI in getShortcutOrURI and other places.
    • bug 825588 Asynchronous JavaScript API for downloads and bug 851471 Decommission nsIDownloadManager. Tracked in:
      • bug 888915 Move SeaMonkey to the new JavaScript API for downloads when nsIDownloadManager is decommissioned.

Feature List, Planning

Bug statistics for the last two (full) weeks: 25 new, 8 fixed, 6 triaged.

  • Low triaging effort.

Open reviews/flags:
30 review
6 super-review
1 ui-review
5 feedback

  • See Feature List page for major wanted/needed features.

  • TODO: We will need to update our Sync UI code due to the new Sync API. Also we need to check if we are allowed to create FX accounts from our UI Since the new Sync accounts are FX accounts.[IanN] I’m sure I saw a question about FX accounts and branding.

Roundtable – Personal Status Updates

Status Updates from developers – what are you working on, what’s the progress, any other comments? (feel free to add yourself to the list if your name is missing and you have interesting status).

IanN
  • Usual testing, reviewing and commenting.

  • Fixed for c-c:
  • Fixed for m-c:
    • bug 1047924 When building with ac_add_options –enable-extensions extensions are put expanded into the wrong location in dist/bin

    • bug 1053439 MOZ_APP_COMPONENT_MODULES and MOZ_APP_EXTRA_LIBS are no longer required
  • Fixed for m-i:
  • Pending check in:
  • Checked in pending review:
  • Waiting for feedback/review:
    • bug 882968 Clean up and move DEFINES and friends to moz.build in comm-central

    • bug 1049800 Package extensions into xpis
    • bug 1051642 Allow for flat chrome format when packaging extensions
    • bug 1052943 Move additions to C*FLAGS into moz.build and do not link against the static RTL
    • bug 1053444 Remove MOZ_APP_COMPONENT_MODULES from comm-central
    • bug 1054526 Move LDFLAGS / WIN32_EXE_LDFLAGS out of Makefiles for c-c
    • bug 1054536 Port *FLAG and related changes to config.mk
    • bug 1054727 TEST-UNEXPECTED-FAIL | check-sync-dirs.py | build file copies are not in sync, port mozconfig.cache and client.mk changes from m-c to c-c
  • Fixing review comments before checkin:
    • bug 757230 When using add button for permissions in Data Manager set a displayHost

    • bug 798147 Switch to correct pref pane if pref window already open
  • Working on:
    • bug 1047981 Port |bug 1047924 – When building with ac_add_options –enable-extensions extensions are put expanded into the wrong location in dist/bin| to comm-central

    • bug 943335 [TB] Update icons used in searchplugins (Yahoo, eBay, Wikipedia, Amazon, Bing, Twitter)
    • Various SM Council documents.
    • bug 606683 Allow customization of toolbar in Composer and MailNews Composition
    • bug 639690 [META] Re-arrange code between editor and editorOverlay
    • bug 773979 [META] Switch to new drag and drop api in SeaMonkey
    • bug 657234 Move pasteQuote and pasteNoFormatting into contentAreaContextOverlay
    • File/Folder selection in windows.
  • To Do:
    • bug 639395 Get cmd_fontSize to reflect current state of selected content / content at caret.

    • Prefs-in-a-tab.
    • Create FAQ for Friends of the Fish Tank.
    • Help get composer standalone builds working with –enable-tests.
Neil

Needs checkin (waiting for greener tree):

Needs checkin and aurora approval (waiting for greener tree):

Needs beta checkin:

  • bug 934492 Adjust the preference panes for the removal of the charset data source.

Needs beta backout (bug 933462 was backed out on Gecko 30):

Needs mozilla checkin:

  • bug 1053420 Improve new nsTArray rvalue reference methods.

Waiting for review:

  • bug 1051852 Web pages can’t add search engines.

  • bug 1048979 Search engine icons should be limited to 16px.

Waiting for review on fixed patch:

  • bug 1054289 Page does not scroll to anchor set by script.

Still waiting for review:

Any other business?

Discuss:

  • [Ratty] KaiRo reminded us that we need to grow our contributor community. Perhaps we can get some Engagement experts from Mozilla to give us some suggestions?

    • [IanN] might have a chat with some people and see if they can point me in the right direction.

SeaMonkey Meeting Details

Meeting NotesMozilla Platform: 2014-08-19

Need To Know

(Release and system issues that may impact engineering this week.)

Notices/Schedule (lmandel)

Next Merge: September 1, 2014 Next Release: September 2, 2014
Trains
Central: 34 Aurora: 33 Beta: 32 Release: 31
  • desktop beta8 ships today

  • mobile beta8 ships tomorrow
  • LAST BETA9 goes to build this Thu, Aug 21
  • MERGE DATE CHANGE: Next merge date will be TUE, SEP 2, 2014

Build Changes (gps)

(Build changes of which engineers should be aware.)

RelEng (catlee)

(Repo, test, and other information for engineers from the release engineering team.)

Upcoming Outages/Upgrades

(System outages/upgrades and tree closures that impact engineering.)

Quality Programs

(An opportunity to hear about status with the various quality programs that do not have a formal team structure.)

OrangeFactor (ryanvm)

<Read Only>

  • Past week’s OrangeFactor: N/A. Progress is being made on bug 1046162, things will hopefully be back to normal for next week’s meeting).

  • 25 intermittent failures fixed in the last week – List – Thanks!.
    • Thanks to Peter Moore for fixing a long-running pip install timeout that affected tests on all platforms.

    • Lots of crash and leak fixes this week!

MemShrink (njn)

  • Jon Coppeard landed the first parts of support for compacting GC. It only works for the JS shell, and it’s currently hidden behind the --enable-gccompacting configure flag. Still, progress! The bug for enabling it in the browser is here.

  • Peter Van der Beken fixed a bad leak affecting users who have the “keep until” setting for cookies set to “ask me every time”.

Stability (kairo/bsmedberg)

<Read Only>

Team Stand-ups

(In <2 mins, what did your team accomplish last week, on what is your team working on this week, and on what, if anything, is your team blocked? No questions during the stand-ups. All questions should be asked during the roundtable.)

A*Team (jgriffin)

App Tools (prouget)

<Read Only>

  • WebIDE preffed on, with memory monitor enabled

  • B2G main-process (chrome) is now debuggable
  • Profiler now works with FxOS 2.0, 2.1, and disabled in older version
  • $0 in WebConsole works

Electrolysis (e10s) (blassey)

  • Working on M2 milestone: https://wiki.mozilla.org/Electrolysis/Roadmap#M2.1_Milestone

    • bug 1030451 – Update spellchecker context menu suggestions for multiprocess

    • bug 1034212 – Enable devtools/webaudioeditor tests for e10s
    • and many other fixes
  • If you’d like to test e10s in Nightly, flip the “browser.tabs.remote.autostart” pref to true and restart Nightly.
    • Warning: e10s is a little rough this week due to some page loading bugs (like HTTP redirect bug 1050869).

Firefox Desktop (gavin)

Summary of Work In Progress
  • You can see the status of the current iteration (34.3) in progress here
Summary of Recent Landings
  • Team landed 62 bugs over the last week, to close out the 34.2 iteration.

  • Details of landings from the past week can be seen here

Firefox Mobile (snorp/blassey/mfinkle)

<Read Only>

Work In Progress

You can find more on upcoming feature plans in the[roadmap]

Landings from the past week
Nightly (34)
  • Large text on door-hanger for mixed content blocking on high DPI devices ( Bug 917970 )

  • Autophone – s1s2 – Regression in local “time to throbber stop” on 2014-05-11 ( Bug 1018463 )
  • Remove Cache directory from Android profiles ( Bug 1045886 )
  • testVideoDiscovery.js is going to start perma-failing when Aurora 33 is merged to Beta ( Bug 1046493 )
  • Zoom level changes on some mobile sites on pressing the back button ( Bug 1046631 )
  • Disable downloads and extension installs in guest mode ( Bug 1046941 )
  • Download cancel dialog shows undefinedYes and undefinedNo aa button values ( Bug 1048000 )
  • Search activity displays private browsing searches from browser ( Bug 1048444 )
  • Unable to use gesture typing in search activity ( Bug 1049282 )
  • Long pages have missing tiles and generally messed-up rendering ( Bug 1051592 )
  • Regression: tab counter is empty ( Bug 1052345 )

Firefox OS Connectivity (vchang)

<Read Only>

  1. https://wiki.mozilla.org/TPE_CONNECTIVITY_GROUP/2014-08-19

GFX (milan)

  • Lots of vacations.

  • Siggraph last week. Nice summary from :nical on dev-tech-gfx. Extremely short summary: VR/AR, next gen GL, other.
  • Firefox OS:
    • Some last minute blockers. The biggest recent graphics bug turned out to be an intermittent, low level network/ipc issue, usually only showing up during multi-day partner testing. Currently looking at a couple of canvas issues, related to the updated version of Skia (back in March.)
  • Desktop:
    • Will try to get to final stage/land desktop tiling the week of September 22nd – probably behind a pref until APZ on desktop is available, to avoid performance issues. The aim is to have it (the tiling) stick in 35, but we may need to test with that pref enabled, to avoid regressions while APZ work is being done.

    • Back on the Skia content work, we were derailed by the Firefox OS blocking bugs.

JS (naveed)

<Read Only>

  • Compiler (JIT)

    • bug 1041781: Landed native to bytecode mapping

    • bug 1054340: Landed post-native-to-bytecode-mapping fix to remove MPcOffset instructions
  • Garbage Collection

    • bug 650161: Landed first cut of compacting GC implementation (build with –enable-gccompacting to try it out)

    • bug 995284: Made GC behvaiour deterministic in shell builds
  • Front End and Other

    • bug 1052248: Tweak the goodAllocated heuristics for JS arrays

    • bug 1041688: acquired properties analysis working but has some regressions

Layout (jet/dbaron)

<Read Only>

  • caret cleanup landed (bug 1048752)

  • CSS transitions now work for style changes that trigger reframes (bug 625289)
  • initial CSS Ruby reflow code landed, but still more work to do on ruby

Media (mreavy)

<Read Only>

  • Continue to prep OpenH264 and Screensharing for Fx33.

    • Major UI redesign slated for Fx35

    • Window list rescan uplifted to 33
    • Talky.io is experimenting with ScreenSharing in their beta pages
  • Working a 2.0 blocker with QC
  • Firefox Desktop has been giving the Loop team a hand on front-end issues
  • GMP plugin sandboxing has landed

Necko (dougt/jduell)

<Read Only>

  • landed bug 820391: we’re finally getting DNS time-to-live (TTL) accurately (Windows-only for now).

  • HTTP cache v2: some last bugs before we release: mostly tests but also a few real bugs (bug 1042192, bug 1054425, bug 660749)
  • minor fixups for HTTP2: we’re close to being able to pref it on.

Performance (vladan)

  • bug 1045108: Please review your Telemetry probes and make sure they’re still useful. Also please set the expiry dates for your probes (e.g. “expires_in_version”: “never”, or “35″ for Firefox 35) — we’ll be automatically marking unclaimed probes for expiry in Firefox 40.

    • bug 1037494: Also provide email addresses for automatic regression notifications in the “alert_emails” field.

Shumway (tschneidereit)

Roundtable

(Comments and questions that arise during the course of the meeting or otherwise do not have a section.)

<Read only beyond this point>

Mailing List Threads

(Threads that are likely to be of interest to engineering from various mailing lists.)

Good Reads

(Links to blog posts, books, videos, etc. that you think will be of interest to others.)

irc #planning Log From This Meeting


Engineering Meeting Details

  • Tuesday 2014-08-1911:00 am Pacific Standard Time

  • Dial-in: conference# 98411
    • US/California/Mountain View: +1 650 903 0800, x92 Conf# 98411

    • US/California/San Francisco: +1 415 762 5700, x92 Conf# 98411
    • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 98411
    • CA/Vancouver: +1 778 785 1540, x92 Conf# 98411
    • CA/Toronto: +1 416 848 3114, x92 Conf# 98411
    • UK/London: +44 (0)207 855 3000, x92 Conf# 98411
    • FR/Paris: +33 1 44 79 34 80, x92 Conf# 98411
    • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 98411
  • Engineering Vidyo Room / Air Mozilla / MTV Alien Nation / TOR Finch / SFO Warfield / PDX Hair of the Dog
  • join irc.mozilla.org #planning for back channel

Mozilla Add-ons BlogAnnouncing Add-on SDK 1.17

I’m pleased to announce the immediate availability of Add-on SDK 1.17! You can download the SDK directly in either zip or tarball format. This is a maintenance release of the cfx tools to more easily support new apis added to Firefox in the future ( see bug 1032275 for more information ). The AMO validator tool has been updated to support extensions created with SDK 1.17 as of August 13th.

This will almost certainly be the last release of this tool; developers using the SDK are encouraged to try out the new JPM tool instead. JPM has some key advantages:

  • developers can create and use npm modules as dependencies in their add-ons.
  • installation via npm is much simpler: `npm install -g jpm`, particularly for developers already used to node.js.
  • cfx was a complex tool built for a time when sdk dependencies were packaged with each add-on. JPM removes a lot of this complexity and just does a few things well: running, packaging and running tests.

For more on migrating to JPM, please see Erik’s excellent post.

As always, we’d love to hear from you about your experiences with this release. You can contact us in a variety of ways:

post to our discussion group
chat with us on irc.mozilla.org #jetpack
report a bug
check out the source and contribute bug fixes, enhancements, or documentation

For more information on the Jetpack Project check out our wiki.

Air MozillaWarfare in the GELAM trenches

Warfare in the GELAM trenches Intern Alex Wissmann presents "Warfare in the GELAM trenches"

Air MozillaIt's All Rainbows and Unicorns

It's All Rainbows and Unicorns Intern Eli Kariv presents "It's All Rainbows and Unicorns"

Air MozillaDo we really want Clippy in Firefox?

Do we really want Clippy in Firefox? Kamyar Ardekani presents "Do we really want Clippy in Firefox?"

WebmakerCommunity Literacies #4: Happy dances, kitten rescuers and ed jams

Editor’s Note: Community Literacies is a series about Webmaker’s finest learning resources around the world, and the stories that bring them to life. Have something to share? Get in touch with Kat.

Three new educational creations from Maker Party

For a bit of inspiring reading over a cold smoothie by the pool, we bring you another round of amazing creations from learners and teachers! In the next two installments, we will explore some of the most inspiring teaching materials built for Maker Parties around the world.

This time, we start our adventure with Emma in South Africa by discussing a new remixable lesson plan made for girls at Code for Capetown. We’ll fly to London and meet Dee and Joe to learn about a game that teaches web design through saving kittens in a fantasy world. And we’ll finish our time together by traveling to the heart of Texas to speak to Julia and Karen and hear about their crazy open education party in San Antonio. Let’s get started!

Teaching girls how to hack happy dances in South Africa

Image thanks to Code4CT
teaching kit by Code4CT

In South Africa, the Code For Capetown project aims to help young girls consider careers in tech as exciting and viable options. The program runs over 3 weeks in the summer holidays, and introduces grade 10 and 11 girls in the region to the big world of web development for social impact. And this summer, the Code4CT girls have been learning how to become webmakers together for inspiring results.

“Code4CT girls had been having so much fun discovering how the web works, and actively participating in building web content,” says Director of New Initiatives Emma Dicks, “that we decided to share this with our friends by hosting our own Maker Party! We told each girl she could invite one friend, who she then helped teach basic HTML to using Codecademy, Made with Code and Webmaker resources.”

At the event, friends immediately set to work making memes and learning about HTML tags, and even learned the steps to Pharrell William’s dance Happy for the Hack the Happy Dance activity, followed by an activity by Creative Commons for Kids. “This lead to a great discussion on hacking,” adds Emma. “We asked the girls to talk about when they are allowed to take and change images, and when it is illegal because of copyright.”

What’s next for the Code4CT girls? “After putting together a teaching kit to share what we did at our Maker Party, we also built a full lesson plan to introduce human centered design to a group of young learners,” says Emma. “Both have worked excellently, and we would love to see others use these plans and remix them!” For feedback, makers are invited to share their experience and remixes with Emma on Twitter.

The Human Centered Design teaching kit will soon be available on Webmaker’s Design and Accessibility Literacy page.

Saving all the kittens with code and creativity in London

Image thanks to Erase All Kittens
teaching kit by Erase All Kittens

E.A.K. (Erase All Kittens) is an open source game that teaches kids to code and create on the web by saving kittens with HTML and CSS. Inspired by a teaching activity for the game put together by its creators Joe Dytrych, Dee Saigal and Leonie Van Der Linde at DrumrollHQ in the UK, we got in touch to find out more about all the kitten-saving happening in London.

“We created the activity so that kids can be taught basic coding skills by playing E.A.K. in code clubs, classrooms and at home,” explains Dee. “The pilot version of Erase All Kittens is free online and gives players an introduction to HTML and CSS skills, so we wanted to know more about what the Webmaker community thought of E.A.K, regardless of whether or not they’re already familiar with coding. We’re big fans of Mozilla, so it’s been really great to help out with Maker Party.”

We asked Dee about her experience working with the Thimble tool to create the teaching activity, and Dee told us she found it to be fairly simple. “I’d used similar methods to create a Cargo Collective website for my own portfolio,” she explains, “so while I didn’t understand some of the code, I was still able to make the teaching kit without experiencing too many problems!”

Because Erase All Kittens is open source, Dee and Joe are looking for others to get involved in the game’s code, too, by helping develop, translate and animate it together. “We are especially looking for help translating the game,” adds Dee, “so as many people as possible can play it! And we’re creating tools to help players build their own levels, which we’ll show off at this year’s Mozfest.” Dee and Joe encourage anyone interested in getting involved to get in touch and start saving those kittens.

The Erase All Kittens teaching activity is now available on Webmaker’s Coding and Scripting Literacy page.

Holding open education jams with Makey Makeys in Texas


teaching kit by Julia Vallera and Karen Smith

While a lot of great webmaking happens online (with kittens!), other great moments happen in-person with a group who has come together to make things for the first time. This summer in San Antonio, Texas, experienced webmakers Karen Smith and Julia Vallera hosted an interactive workshop for the software track at OpenEdJam.

From the beginning, the process was all about openness and sharing. “To prepare for the event, Karen created the kit and asked for collaboration from Mozilla’s #teachtheweb team,” explains Julia. “She also sent it to OpenEdJam as the proposal itself, which was brilliant. The kit is a working example of what participants can do with Webmaker tools, and how the remix function can create a truly open process.”

On the day of the Maker Party, all kinds of making were facilitated. Makey Makeys were brought out, memes were built (and tweeted!) and digital creations of all kinds were shared. When we asked Karen and Julia about their limitations for the event, the main issue was not having enough time to make everything.

“Kits can take a lot of time,” says Julia. “They have a lot of content, and are very well thought-out. 2-3 hours might not be enough to finish one.” Julia suggests creating teaching activities instead, or starting with a basic Thimble starter resource like Meme-Maker or Book Cover, and running with it. “The response to kits was great in San Antonio,” she adds. “Educators loved the Webmaker tools, and they were very excited to learn how easy they are to use.”

How can others get involved with this work? “We would love to see people remix the kit and make changes to it!” says Julia. Makers of all kinds are encouraged to get in touch with Julia and Karen on Twitter to share their own open educational jams.

A big thanks to our featured makers

We end this issue with many e-hugs and skydiving cat gifs for webmakers Emma, Dee, Joe, Karen and Julia for sharing their great educational creations with a Maker Party flavor. We hope this issue has left you feeling inspired to remix, reflect and create your own! Have a great piece of content you want us to feature? Get in touch. And stay tuned for Part 2 of Community Literacies: Maker Party edition to learn about three more Maker Party teaching activities, this time from India. We already look forward to the making yet to come…

Get involved!

hacks.mozilla.orgBrowserify and Gulp with React

The JS world moves quickly, and nowadays, there’re some new kids around the block. Today, we’ll explore Browserify, Gulp, and React and see whether they’d sound suitable for our projects. You might have heard of them but not have had the time to check them out. So we’ll look at the advantages and disadvantages of using Browserify, using Gulp, using React. Because it certainly doesn’t hurt to know our options.

Browserify: Bundling Node Modules for the Browser

Browserify is a development tool lets us write Node-style modules in the browser or include actual Node modules from npm. Modules are written in separate files, things can be exported, and modules pull in other modules through require. Browserify can then parse our main JS module, building a dependency tree, to bundle everything together.

One great thing is that the tens of thousands of modules on NPM are now available for our projects. Dependencies are defined in package.json, and if our project requires them, Browserify will bundle these dependencies with our JS. Take this package.json for example:

/* package.json */
{
  "name": "hipApp",
  "description": "Showing off hip stuff",
  "dependencies": {
    "browserify": "~3.44.x",
    "react": "0.11.x",
    "underscore": "*",
  }
}

Once we run npm install, we’ll have modules like React and Underscore available to use in our project. Now we just require them in our project:

/* app.js */
var React = require('react');
var myModule = require('./myModule');
// ...

Then we invoke Browserify:

browserify --debug app.js > bundle.js

And Browserify will include React from npm for us. Notice that it will even figure out which local modules to include. We included ./myModule which is another module in the same folder as app.js.

Let’s compare this style of dependency loading with technologies such as AMD ,which is prominently implemented by RequireJS. They are both JS module definition APIs but with different implementations. Browserify falls in line with CommonJS which is suited for the server, and RequireJS falls in line with AMD which is suited for the browser. However, either can be used in either environment.

What’s awesome about Browserify is that all NPM modules are available for our project, 86K and counting. Its modules also do not need to be wrapped in a define call.

Though Browserify requires all the modules up front, which means needing a build step. AMD is asynchronous so modules can be lazily-loaded, and all that is needed is a page refresh. Though we can automate the Browserify build step with Gulp.

Gulp: The Streaming Build System

Gulp is a JS build system, like Grunt, that makes use of “streams”, or pipelining, and focuses on code-over-configuration. Build systems are usually set up to watch for changes to projects, and then automatically handling common build steps such as bundling, pre-compilation, or minification. Both Gulp and Grunt have tons of plugins to help with these things. Browserify is one such plugin.

Let’s take a look at an example Gulpfile. It includes some facilities for React JSX files which we haven’t looked at yet, but it’ll come in handy later. Read the comments in the Gulpfile to follow along:

/* gulpfile.js */
 
// Load some modules which are installed through NPM.
var gulp = require('gulp');
var browserify = require('browserify');  // Bundles JS.
var del = require('del');  // Deletes files.
var reactify = require('reactify');  // Transforms React JSX to JS.
var source = require('vinyl-source-stream');
var stylus = require('gulp-stylus');  // To compile Stylus CSS.
 
// Define some paths.
var paths = {
  css: ['src/css/**/*.styl'],
  app_js: ['./src/js/app.jsx'],
  js: ['src/js/*.js'],
};
 
// An example of a dependency task, it will be run before the css/js tasks.
// Dependency tasks should call the callback to tell the parent task that
// they're done.
gulp.task('clean', function(done) {
  del(['build'], done);
});
 
// Our CSS task. It finds all our Stylus files and compiles them.
gulp.task('css', ['clean'], function() {
  return gulp.src(paths.css)
    .pipe(stylus())
    .pipe(gulp.dest('./src/css'));
});
 
// Our JS task. It will Browserify our code and compile React JSX files.
gulp.task('js', ['clean'], function() {
  // Browserify/bundle the JS.
  browserify(paths.app_js)
    .transform(reactify)
    .bundle()
    .pipe(source('bundle.js'))
    .pipe(gulp.dest('./src/'));
});
 
// Rerun tasks whenever a file changes.
gulp.task('watch', function() {
  gulp.watch(paths.css, ['css']);
  gulp.watch(paths.js, ['js']);
});
 
// The default task (called when we run `gulp` from cli)
gulp.task('default', ['watch', 'css', 'js']);

Just install the NPM dependencies, run ./node_modules/.bin/gulp, and it handles everything for us in the background. Our files are watched with gulp.watch, tasks are automatically run, and things are cleanly accomplished in streams and pipelines. Whenever we modify any JS/CSS, we can can refresh in the browser just as if we were using AMD.

Whether to use Grunt or Gulp is a matter of preference. Both have tons of modules available, though Gulp is a bit newer. Grunt is done more through configuration whereas Gulp is done more through code and streams. Though Gulp can be a bit faster as it does not require intermediary files to accomplish its tasks. So with our build system in place, let’s head to the big show: React.

React: Declarative and Reactive Components

React is a JS library from Facebook for building reusuable web components. It’s not a full MVC framework like AngularJS; React focuses on view rendering of components making no assumptions about framework, and it can plug in to most projects smoothly.

Facebook says React was made to build large applications with data that changes over time. Facebook wanted something that didn’t take over the whole application. They could mix in components that could be integrated with legacy components. If you’d like some convincing, Pete Hunt, one of the authors of React, wrote some arguments for React on Quora.

Rather than imperative one-way data binding as in traditional applications or two-way data binding as in Angular, React implements a one-way reactive data flow. Rather than manually registering listeners and handlers to update the DOM, or having to set up linking functions and data bindings, React’s components are declaratively defined and automatically re-render when its data changes. Like a function, data goes in, components come out.

For convenience, let’s take a look at an example based off of React’s homepage, which simply displays a name:

/** @jsx React.DOM */
var React = require('react');  // Browserify!
 
var HelloMessage = React.createClass({  // Create a component, HelloMessage.
  render: function() {
    return <div>Hello {this.props.name}</div>;  // Display a property.
  }
});
React.renderComponent(  // Render HelloMessage component at #name.
  <HelloMessage name="John" />,
  document.getElementById('name'));

You may have noticed, there’s some mark-up in our Javascript. React features syntatical sugar called JSX. It needs to be compiled into JS, which’ll automatically be done with our Gulpfile from earlier through the Reactify plugin. Though React also has a JSX compiler if we wanted it. Note that JSX is not required; React has normal JS APIs, but where’s the fun in that?

Components are created with createClass. Like functions, components can take in arguments during rendering in the form of props. In the above example name="John" is passed into the component and is then referenced by {this.props.name}. Note that components can be made up of only one Node. If we wish to have multiple DOM nodes, they must all be wrapped under a single root node.

Along with taking input data through props, a component can have an internal and mutable state as accessed through this.state. Here’s another example, this time of a timer, based off of React’s homepage:

/** @jsx React.DOM */
var React = require('react');
 
var Timer = React.createClass({
  getInitialState: function() {  // Like an initial constructor.
    return {
        seconds: 0
    };
  },
  incrementTimer: function() {  // A helper method for our Timer.
    this.setState({  // Use setState to modify state.
        seconds: this.state.seconds + 1  // Never modify state directly!
    });
  },
  componentDidMount: function() {  // A method run on initial rendering.
    setInterval(this.incrementTimer, 1000);
  },
  render: function() {
    return (
      <div>Seconds Elapsed: {this.state.seconds}</div>
    );
  }
});
 
React.renderComponent(<Timer />, document.getElementById('timer'));

We have a setInterval modifying our component’s state which triggers a refresh every 1000ms. Though in more practical applications, the state more likely be modified through user input or through data coming in via XHR rather than through a simple interval.

And those are some of the basics of React. If reusuable declarative components and reactive rendering hits you as something that would sound perfect in your project, you can head to Getting Started with React. Best of luck to your development. Whether you decide to use these tools or not, it is always advantageous to know your options.

Rumbling Edge - Thunderbird2014-08-18 Calendar builds

Common (excluding Website bugs)-specific: (17)

  • Fixed: 344561 – Day/Week view: Header boxes are misaligned if scrollbars are shown
  • Fixed: 680203 – Make Lightning tests work with packaged-tests
  • Fixed: 682109 – Today pane: Today’s date not automatically updated
  • Fixed: 998281 – Default status new event is available, should be busy
  • Fixed: 1000535 – Lightning frequently prompts for access to Google Calendar
  • Fixed: 1002024 – Sending separate invitations to attendees onlys send email for first invited person
  • Fixed: 1007040 – Autocomplete for event invitations: Use uppercase and lowercase of name like in addressbook card
  • Fixed: 1018120 – GMT Timezone with timezone information is assumed to be UTC / events move forward by 1 hour
  • Fixed: 1022113 – Today-pane: too many calls to the function “setCurrentEvent” when updating the attribute “current”
  • Fixed: 1022129 – In the calendar views the day marked as Today doesn’t update at midnight
  • Fixed: 1026623 – Set em:strictCompatibility to ensure the right Lightning version is used.
  • Fixed: 1031715 – Converting email to event shouldn’t fail when Thunderbird Conversations is installed
  • Fixed: 1041566 – Lightning 3.5 broken with 2014-07-21 update
  • Fixed: 1042125 – Make the CalDAV provider async safe
  • Fixed: 1042741 – No buttons on invitations or response to invitations [incompatibility between Thunderbird Conversations and Lightning]
  • Fixed: 1042849 – Remove Serbian [sr] from /calendar/locales/shipped-locales
  • Fixed: 1049201 – Nighly builds broken due to incorrect manifest paths

Sunbird will no longer be actively developed by the Calendar team.

Windows builds Official Windows

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds No binaries since July 23, 2014.

Rumbling Edge - Thunderbird2014-08-18 Thunderbird comm-central builds

Thunderbird-specific: (30)

  • Fixed: 273884 – Enclosing double quotes are shown in recipient column, messes up sorting of name/address
  • Fixed: 934875 – Thunderbird: No status bar accessible
  • Fixed: 964377 – Intermittent test-attachment-reminder.js | test-attachment-reminder.js::test_manual_automatic_attachment_reminder_interaction
  • Fixed: 967583 – Tooltip for ‘Get Mail for’ button says ‘nobody’ for Local Folders, Feed and News accounts, sometimes ends with comma
  • Fixed: 985641 – random orange: test-session-store.js | test-session-store.js::test_restore_single_3pane_persistence + test-session-store.js::test_restore_single_3pane_persistence_again + test-session-store.js::test_message_pane_height_persistence + test-session-store.j
  • Fixed: 1009469 – For recipient autocomplete matches other than {Name beginsWith}, [tab] no longer confirms suggested recipient (“foo >> somefoo <mail@asdf.com>” is retained as recipient). Suggestion becomes stale/unresponsive when TB loses focus.
  • Fixed: 1018241 – Customize option in Search Messages continues to be wonky
  • Fixed: 1018960 – Severe bug with empty junk can cause deletion of inbox (If selected folder at Folder Pane is changed while folder context menu of Junk is shown, “Empty Junk” clears wrong folder)
  • Fixed: 1020339 – Add UI for disabling and clearing Visited Link/Browsing History
  • Fixed: 1021684 – Update box.com Filelink implementation to new APIs
  • Fixed: 1024017 – Add ability to choose info shown in the desktop chat notifications
  • Fixed: 1024130 – Address book sorting not sticky
  • Fixed: 1024600 – Enable test-attachment-reminder.js mozmill tests on Windows again
  • Fixed: 1026608 – Delete button on main toolbar doesn’t always change to “Undelete” when toggled from keyboard or header pane
  • Fixed: 1034732 – comm-central build for win64 is not updated after 2014-06-13
  • Fixed: 1034818 – No gap between on toolbarbuttons icon and text in Icons beside Text mode
  • Fixed: 1035650 – Remove public destructors of NS_*_INLINE_* refcounted classes, Remove NS_HIDDEN, Fix dangerous public destructors. in mail/ and mailnews/
  • Fixed: 1037751 – Use white graphics for the phishing icon
  • Fixed: 1037795 – Port Bug 1034360 to TB – remove OCSP preference UI (or at least remove the unnecessary dialog window)
  • Fixed: 1038029 – Undefined symbols during |making ./libprldap60.dylib|
  • Fixed: 1038323 – Clear Recent History menuitem doesn’t have a keyboard shortcut
  • Fixed: 1038588 – DebuggerServer’s closeListener has been changed to closeAllListeners()
  • Fixed: 1038647 – perma orange: TEST-UNEXPECTED-FAIL | mozmill/utils/test-iteratorUtils.js | test-iteratorUtils.js::test_toArray_custom_content_iterator
  • Fixed: 1038745 – No builds for latest nightly localization of Thunderbird for win32
  • Fixed: 1038909 – Disable what’s new page for now
  • Fixed: 1039798 – perma-orange: test-message-header.js::test_address_book_switch_disabled_on_contact_in_mailing_list
  • Fixed: 1040831 – Daily 33.0a1 gives “Couldn’t load XPCOM” error and startup fails since updating this morning
  • Fixed: 1041475 – TEST-UNEXPECTED-FAIL | mozmill/content-tabs/test-install-xpi.js | test-install-xpi.js::test_install_corrupt_xpi + test-install-xpi.js::test_install_xpi_offer + test-install-xpi.js::test_xpinstall_disabled + test-install-xpi.js::test_xpinstall_actually_i
  • Fixed: 1045026 – Cannot use “thunderbird” as PROGRAM name, because it is already used in mail/components/search/mdimporter
  • Fixed: 1050363 – Thunderbird fails to compile nsldif32v60.dll: LINK : fatal error LNK1104: cannot open file ‘mozcrt.lib’

MailNews Core-specific: (34)

  • Fixed: 367011 – “Remove All Tags” does not do so for custom tags
  • Fixed: 553757 – SMTP server pref dialog: “Password, transmitted insecurely” doesn’t fit after switching from SSL to non-SSL
  • Fixed: 662907 – web site from RSS feed not rendered correctly (due to noscript tags)
  • Fixed: 960854 – Port |Bug 920353 – pymake native commands can’t easily use e.g. mozbuild modules| to c-c
  • Fixed: 966053 – Recipient area mishandles display names with commas in them (e.g. “LastName, FirstName”), during autocomplete creates dysfunctional extra “LastName” recipients without email address
  • Fixed: 992879 – Folders created with a colon (:) or star (*) in Tb24 on linux are duplicated with hash names on startup with Tb trunk or earlier, such local folders/feeds do no longer work
  • Fixed: 1013123 – Increase width of ‘Enter a tag prefix’ textbox for prefix of autotagged category names of feed articles
  • Fixed: 1015774 – errUtils.js::logException shows the same exception to Error console twice
  • Fixed: 1024053 – Modify test_quarantineFilterMove.js to use Promises
  • Fixed: 1024908 – If the focus is returned to filter action list and the previously focused item is no longer there, an exception is shown
  • Fixed: 1025548 – Preliminary perf/code org tweaks for Bug 257037
  • Fixed: 1033963 – Add mailnews.message_warning_size to prefs.
  • Fixed: 1034231 – Modify test_offlineCopy.js to use Promises.
  • Fixed: 1036619 – Implement 1035394 – Add dangerous public destructor detection to _INHERITED refcounting macros in comm-central
  • Fixed: 1037479 – Move LOCAL_INCLUDES to moz.build in c-c
  • Fixed: 1037482 – Move TESTING_JS_MODULES to moz.build in c-c
  • Fixed: 1037775 – Port |bug 1036864 – Remove EXPORT_LIBRARY| to MailNews
  • Fixed: 1037947 – Fix test_movemailDownload.js to work with maildir
  • Fixed: 1042294 – crash NS_ProxyRelease(nsIEventTarget*, nsISupports*, bool), typically during import
  • Fixed: 1043019 – Port |Bug 1036894 – Move in-tree library linkage information to moz.build| and |Bug 1041936 – Allow static library definitions to depend on shared libraries| to comm-central
  • Fixed: 1043040 – Port |Bug 1036694 – merge nsIMarkupDocumentViewer into nsIContentViewer| to comm-central
  • Fixed: 1044460 – Port relevant changes from Bug 1043344 for moving libraries and programs build to the compile tier
  • Fixed: 1044999 – No L10n builds for Thunderbird for aurora/central due to client.py not allowing –skip-venkman
  • Fixed: 1046638 – Port |Bug 1044162 – make install locations for EXTRA_{PP_,}JS_MODULES better| to comm-central
  • Fixed: 1046826 – Use m-c’s config/makefiles/debugmake.mk in c-c’s rules.mk
  • Fixed: 1048042 – Port |Bug 780159 – Remove obsolete REGCHROME| and |Bug 935387 – Remove non recursed install targets| to comm-central
  • Fixed: 1048561 – Fix up after landing of Bug 1043041 – Replace use of NSPR’s PRTime with a safer type in mozilla::pkix
  • Fixed: 1049935 – Port |Bug 1045783 – move OS_LIBS += $(call EXPAND_LIBNAME,…) calls to moz.build| to comm-central
  • Fixed: 1049936 – Port |Bug 1046784 – move -DNOMINMAX definitions to moz.build| to comm-central
  • Fixed: 1050086 – C-c needs a “port” of bug 1047267
  • Fixed: 1050708 – buildid no longer being set on Thunderbird comm-central builds (make upload and graph server posts fail)
  • Fixed: 1051619 – Port |Bug 914274 – Remove MODULE_NAME| to comm-central
  • Fixed: 1052602 – Fix various xpcshell issues in gloda land and others
  • Fixed: 1052985 – Fix windows manifest build issues

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds No binaries since July 23, 2014.

Meeting NotesMozilla Project: 2014-08-18

All-hands Status Meeting Agenda

Items in this section will be shared during the live all-hand status meeting.

Friends of Mozilla

Upcoming Events

Monday, 18 August
  • If you have any time-bound contribution activities for the Mozilla community, please email Jennie at jhalperin@mozilla.com. Your opportunities will be featured in the next issue of about:Mozilla!
Tuesday, 19 August
  • CBT meetup this week in MV
Wednesday, 20 August
Thursday, 21 August
  • 10:00 AM Pacific / 17:00 UTC: Grow Mozilla discussion — a forum for discussing community building at Mozilla

Project Status Updates (voice updates)

Firefox

Speaker Location: Toronto (johnath)

  • Go watch last week’s town hall if you missed it

  • Growth team comin’ atcha
Firefox for Android

Speaker Location: remote (mfinkle)

Firefox OS
  • Li Gong in Mountain View
Content Services
  • Darren Herman in New York

  • TILES
    • Town Hall!
  • UP
  • Subscribe to Web
Webmaker

Speaker Location:Brett Gaylor – Remote

  • Maker Party continues to roll out — going well

  • Big step forward with Mobile Appmaker last week
    • One of our goals with Webmaker this year is to add a focus on apps

    • As part of this, released Appmaker for Desktop in beta for Maker party
    • Over the last few weeks we’ve made progress on the next step: app made on a mobile device
    • At a workweek in Portland last week, the team settled on a product strategy for the next couple months
    • They are now sprinting towards the first prototype to be shown in Dhaka, Bangladesh next week
    • Note: brief presentation on this later in the meeting
Mozilla Communities

Speaker Location: Mark Surman Remote

  • Headline: we’re looking for new ways community can contribute to top line goals

    • This year, Mozilla has a goal to ‘enable communities that have impact’

    • https://wiki.mozilla.org/2014#Enable_Communities_that_have_Impact
      • Much of the focus so far has been on growth, and we’re making some progress
    • We need to shift our focus towards quality and impact that contributors can have
    • Over the coming weeks: community building teams are actively looking for new ways community can have an impact on top line goals
    • E.g. are there creative ways that community can help get Firefox on a growth trajectory?
    • Mark (MoFo), Mary Ellen (Engagement), Mitchell (chair) are helping the community teams with this
    • If you have ideas, reach out to David Boswell or one of the exec team working this
    • Expect more reports in coming weeks

Speakers

Presenter Title Topic Location Share? Media More Details
Who Are You? What Do You Do? What are you going to talk about? Where are you presenting from? (Moz Space, your house, space) Will you be sharing your screen? (yes/no, other info) Links to slides or images you want displayed on screen Link to where audience can find out more information
Andrew Sliwinski and Simon Wex WebMaker Mobile Appmaker work week Portland/Remote Yes Slides Import / Export API for Apps [1] // App for Import/Export of Apps via SD Card [2] // Device-to-Device App Transfer via NFC [3]
Andrea Wood Digital Fundraising & Advocacy (mofo) Community Indiegogo Campaigns // Maker Party Snippet My house (Oakland CA) No na Find Indiegogo campaign info here // Click here to preview and try out the Interactive Snippet – and you can read a blog post by the lead designer
Fred Wenzel Apps Engineering a set of framework+tools for writing awesome Firefox OS apps. remote no https://hacks.mozilla.org/2014/08/time-to-get-hacking-introducing-rec-room/ no. 1 on HN this morning: [4]. Recroom github repo for readme, issues, etc.
Robyn Chau Events Team BrazilJS 2014 remote yes http://bit.ly/1ldAfds BrazilJS Landing Page Wiki

Roundtable

Do you have a question about a Mozilla Project or initiative? Let us know by Friday- we’ll do our best to get you an answer.

Please note that we may not always be able to get to every item on this list, but we will try!

Who are you? Area of question Question
What’s your name? What do you work on? Is your question about policy, a product, a Foundation initiative, etc. What would you like to know?

Welcome!

Let’s say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.

Introducing New Volunteers

New Volunteer(s) Introduced by Speaker location New Volunteer location Will be working on
Who is the new volunteer(s)? Who will be introducing that person? Where is the introducer? Where is the new person based? What will the new person be doing?

Introducing New Hires

New Hire Introduced by Speaker location New Hire location Will be working on
Justin Terry Darren Herman New York Office New York Office Content Partnerships, Partner Success & Content Platform Operations

<meta>

Notes and non-voice status updates that aren’t part of the live meeting go here.

Status Updates By Team (*non-voice* updates)

DevEngage

You might know that we are using UserVoice to allow people to easily report ideas for the developer tools at http://ffdevtools.uservoice.com. We are now extending this to HTML5 Apps as a whole. This will go live soon, and it would be splendid if anyone of you who found things missing in the “web as the platform” to submit them there in order to pre-seed the channel before we announce it live: https://openwebapps.uservoice.com/forums/258478-open-web-apps

Automation & Tools
bugzilla.mozilla.org

Notable changes to bugzilla.mozilla.org during the last week:

  • bug 1041964 Added an indication that a comment is required when setting some tracking flag values

All changes.

Engagement
Apps & Marketplace
Mobile Partner Site
  • The Mobile Partner site (https://mobilepartners.mozilla.org/) is part of Mozilla’s initiative to scale the delivery of Firefox OS devices. The site is specifically targeted to provide self-serve support to the retail/open Market distribution channels and lower volume operators. The intent is to make everything the partner needs to create a Branded Powered by Firefox OS or Firefox OS Inside device available in a curated, guided site with complete and up to date information regarding our product. In order to distribute a Mozilla branded device, Partners must register on the site, accept the click through Prototype agreement, complete and pass Mozilla’s certification process and sign Branding Terms.

  • With the help of the Mozilla Beijing team we are in the process of translating the site to Chinese. We expect to have Chinese (in addition to English) available online by Sept 1.
  • If you are interested in understanding all the steps that a partner needs to undertake in order to bring a Firefox OS device to market, we invite you to visit the site. Its perfectly ok for you to register on the site and accept the prototype branding agreement so that you can have full access to the site – we just request that you use your Mozilla.com email address if you are on Mozilla staff or clearly identify yourself as a contributor so that our Bus Dev team can determine ‘real’ potential partners. We welcome your input and contribution to making it the best site possible!
  • Also we are planning a brown bag on Sept 4, so please plan to join Adam Rogers, Ben Sternthal and Karen Ward on Airmozilla on that date!

  • Dial-in: conference# 8600

    • US/California/Mountain View: +1 650 903 0800, x92 Conf# 8600

    • US/California/San Francisco: +1 415 762 5700, x92 Conf# 8600
    • US/Oregon/Portland: +1 971 544 8000, x92 Conf# 8600
    • CA/Vancouver: +1 778 785 1540, x92 Conf# 8600
    • CA/Toronto: +1 416 848 3114, x92 Conf# 8600
    • UK/London: +44 (0)207 855 3000, x92 Conf# 8600
    • FR/Paris: +33 1 44 79 34 80, x92 Conf# 8600
    • US/Toll-free: +1 800 707 2533, (pin 369) Conf# 8600

Firefox AppsSocial Media Marketing for App Developers

No matter where you are in your app development journey – from ideation to having an existing app in the marketplace – you can immediately benefit from real-time social media interactions. In a perfect world, social media marketing (as with building your app website & most other elements of a strong marketing plan) is best leveraged when you first start concepting your app. This seeds fan followings and enables you to gather and implement feedback early on in the process. For instance, Clear sold 350,000 copies of its app within nine days of its launch, thanks to marketing tactics fired well in advance. But don’t worry if you’re much further along on your roadmap – by thinking about marketing at all, you’re already ahead of most app developers.

Naturally, if you’re not already on Facebook and Twitter, you need to start here. Your personal accounts aren’t enough – create unique accounts for your app! Depending on the nature of your app, you might also consider niche social strategies using platforms like Reddit, Vine, and Instagram.

Build a following. If you already have large followings on your personal accounts, absolutely use them to promote your new app pages. Otherwise, find friends and people in your network with large followings and kindly request a shout out – or post directly to their page if you have to. Follow/like people and brands you share a target audience with, and comment in discussions where you can offer an perspective. More importantly, be sure to interact with your own followers!

Use hashtags – thoughtfully: Post content with appropriate hashtags so relevant people can discover you. As a general rule, hashtags should be general enough for people to search for them, but not so general that you’re buried under a thousand posts a minute. #dog is too general, #grumpyonetoothedbulldog is too narrow, and #spotteddog is just right.

Slingshot uses its Facebook page to excite users about new updates. User comments offer valuable information about user sentiment, plus the opportunity to directly respond in real time.

Slingshot uses its Facebook page to excite users about new updates. User comments offer valuable information about user sentiment, plus the opportunity to directly respond in real time.

Have a content strategy: Create a regular content cadence and tell your followers how often you post – daily, weekly, etc – and stick to it. Your posts should include interesting, relevant updates – not sales messages. Don’t post the same content on each channel. Some overlap is okay, but give users unique reasons to follow you on different platforms.  When you don’t have updates of your own, offer an insightful comment or link related to something else related to your industry that is relevant and valuable to your users. Consider services like Outbrain to accelerate your content distribution strategy. Startup Moon also offers a great content marketing guide for startups.

Get feedback: The most important thing to remember about social media is that it’s a two-way channel – not a podium where you do all the talking. Your social media marketing should be a source of intelligence to you. So stimulate relevant discussions. Ask questions, test and validate ideas. Learn who your influencers are. Early on, this can be a great form of market research. Once your social followings have achieved scale, research analytics tools (more on this in a future post) to help test content strategies, identify trends, and fine tune what works.

 

Note: This post is part of the Developer App Marketing Series, specifically designed to offer marketing tips and best practices for new app developers. The series is intended to begin by covering the basis before moving into more targeted app marketing tactics. Developers – is this content helpful, and if not, how can it be? Your feedback is as valued as it is welcome. Please share your thoughts in the comments section!

Mozilla IndiaMaker Party Pune

Maker Party 2014 was kick-started by President Obama at White House Maker Faire this June. From June 15 – Sept 15, Mozilla Foundation is hosting a Global Maker Party, with small to large Webmaking events happening everywhere. Mozilla India will be hosting/ be part of the flagship Maker Party World Tour.

Maker Party Pune

Maker Party Pune

Maker Party Pune is being held on the 6th of September 2014. The executive director of Mozilla Foundation, Mark Surman, is going to be personally present for this event. This event is an attempt to map and empower a community of educators and creative people who share a passion to innovate, evolve and change the learning landscape.

The event has a simple format called ‘Hive Pop-up’, it’s like a science fair, where facilitators are sharing cutting edge technologies, teach something new in a engaging way. This event is a platform to connect diverse organizations with learners and encourage connected learning.

We are asking organizations to host a learning station, i.e. a simple table-top activity,  based on their programs/ background, by planning hands-on activity that is easily understandable by any age group/ skill level.

The audience age group would be *13+ and above*, the attempt to target tweens, teens and adults is, we think it is the right time to tap their interest and get the ‘Maker‘ thinking right from the young age than being a ‘consumer’. i.e. Encourage the youth to change from ‘technology/web consumers’ to ‘technology/web makers‘.

If you would like to be a part of this event, please register using the form below:

Loading…

[ps: This is a free event. No registration fee will be required for this event. But if you are travelling from outside Pune, you will need to take care of your own travel and accomodation.]

hacks.mozilla.orgTime to get hacking – Introducing Rec Room

It’s no secret that the best frameworks and tools are extracted, not created out of thin air. Since launching Firefox OS, Mozilla has been approached by countless app developers and web developers with a simple question: “How do I make apps for Firefox OS?” The answer: “It’s the web; use existing web technologies.” was—and still is—a good answer.

But if you don’t already have an existing toolchain as a web developer, I’ve been working on extracting something out of the way I’ve been creating web apps at Mozilla that you can use to write your next web app. From project creation to templating to deployment, Mozilla’s Rec Room will help you create awesome web apps in less time with more ease.

Rec Room is a Node.js utility belt you can wear to build client side web apps. It includes:

  • Brick to add components like appbars and buttons to your UI.
  • Ember for your app’s controllers, models, and views.
  • Handlebars to write your app’s templates.
  • Grunt to run the tasks for your app, including building for production.
  • I18n.js to localize your app.
  • Mocha to test your app.
  • Stylus to write your CSS.
  • Yeoman to scaffold new code for your app’s models and templates.

In this post I’ll walk through how to create a simple world clock web app with Rec Room, how to deploy it, and how you can try out Rec Room for yourself.

Where Does Rec Room Come From?

Much of Rec Room came from a recent rewrite of the HTML5 podcast app. I started working on this app well over a year ago, but its original version wasn’t as easy to work on; it had a lot of global state and a lot of by-hand data-binding. I liked the look of Ember for app development, but back when I started it didn’t quite feel mature enough. These days it’s much better, and I’ve tweaked it in Rec Room to work perfectly without a server.

I tried to take the best from that system and extract it into a set of tools and documentation that anyone can use.

Create your own Rec Room app

Rec Room has just recently been extracted from my experiences with Podcasts; it hasn’t been tested by more than a handful of developers. That said: we’d love your help trying to build your own app for Firefox OS using these tools. They integrate well with tools you probably already know and use–like Node.js and Firefox’s own Web IDE.

To get started, install Rec Room using Node.js:

npm install -g recroom

Clock App

We’ll create a simple clock app with (minimal) time zone support for our example. The app will let you have a clock and compare it with a few time zones.

The recroom binary is your entry point to all of the cool things Rec Room can do for you. First, create your app using recroom new world-clock. This creates the basic app structure. To see the basic app skeleton that Rec Room creates we can now enter that directory and run our app: cd world-clock and then type recroom run. The app will open in your default browser.

First, we’ll add the current time to the main tab. Rec Room supports Ember’s MVC app structure, but also offers simple “pages” for a controller without a 1:1 relationship to a model. We’ll generate a new page that will show our actual clock:

recroom generate page Clock

We can edit its template by opening app/templates/clock.hbs. Let’s change clock.hbs to include the variable that will output our local time:

<h2>Local Time: {{localTime}}</h2>

That won’t do much yet, so let’s add that variable to our ClockController, in app/scripts/controllers/clock_controller.js:

WorldClock.ClockController = Ember.ObjectController.extend({
    localTime: new Date().toLocaleTimeString()
});

You can see that any property inside the controller is accessible inside that controller’s template. We define the 1ocalTime property and it gets carried into our template context.

Now our clock app will show the current local time when we navigate to http://localhost:9000/#clock. Of course, it just shows the time it was when the controller was initialized; there is no live updating of the time. We should update the time every second inside the controller:

WorldClock.ClockController = Ember.ObjectController.extend({
    init: function() {
        // Update the time.
        this.updateTime();
 
    // Run other controller setup.
        this._super();
    },
 
    updateTime: function() {
        var _this = this;
 
        // Update the time every second.
        Ember.run.later(function() {
            _this.set('localTime', new Date().toLocaleTimeString());
            _this.updateTime();
        }, 1000);
    },
 
    localTime: new Date().toLocaleTimeString()
});

Now we can go to our clock URL and see our clock automatically updates every second. This is thanks to Ember’s data-binding between controllers and templates; if we change a value in a controller, model, or view that’s wired up to a template, the template will automatically change that data for us.

Adding Timezones

Next, we want to add a few timezones that the user can add to their own collection of timezones to compare against local time. This will help them schedule their meetings with friends in San Francisco, Buenos Aires, and London.

We can create a timezone model (and accompanying controllers/routes/templates) with the same generate command, but this time we’ll generate a model:

recroom generate model Timezone

We want each timezone we’re to include in our app to have a name and an offset value, so we should add them as model attributes. We use Ember Data for this, inside app/scripts/models/timezone_model.js:

WorldClock.Timezone = DS.Model.extend({
    name: DS.attr('string'),
    offset: DS.attr('number')
});

Next we’ll want a list of all timezones to offer the user. For this we’ll grab a copy of Moment Timezone. It’s an awesome JavaScript library for dealing with dates and times in JavaScript. We’ll install it with bower:

bower install moment-timezone --save

And then add it to our app inside app/index.html:

<!-- build:js(app) scripts/components.js -->
<!-- [Other script tags] -->
<script src="bower_components/moment/moment.js"></script>
<script src="bower_components/moment-timezone/builds/moment-timezone-with-data-2010-2020.js"></script>
<!-- endbuild -->

Adding that tag will automatically add moment-timezone-with-data-2010-2020.js to our built app. We’ll add a tab to the page that lets us edit our timezones, on a different screen than the clocks. To add a tab, we just need to open app/templates/application.hbs and add a tab. While we’re there, we’ll change the main tab from the useless {{#linkTo 'index'}} and point it to {{#linkTo 'clock'}}. The new application.hbs should look like this:

<x-layout>
  <header>
    <x-appbar>
      <h1>{{t app.title}}</h1>
    </x-appbar>
  </header>
  <section>
    {{outlet}}
  </section>
  <footer>
    <x-tabbar>
      <x-tabbar-tab>
        {{#link-to 'clock'}}Clock{{/link-to}}
      </x-tabbar-tab>
      <x-tabbar-tab>
        {{#link-to 'timezones'}}Timezones{{/link-to}}
      </x-tabbar-tab>
    </x-tabbar>
  </footer>
</x-layout>

Side note: notice the root URL points to a useless welcome page? We probably want the default route to be our ClockController, so we can set the index route to redirect to it. Let’s do that now, in app/scripts/routes/application_route.js:

WorldClock.ApplicationRoute = Ember.Route.extend({
    redirect: function() {
        this.transitionTo('clock');
    }
});

Interacting with Timezone models

We’ll keep things simple for our example and allow users to select a timezone from a <select> tag and add it with a button. It will show up in their list of timezones, and they can delete it if they want from there. The clock tab will show all times. First, we’ll add our timezone data from Moment.js into our TimezonesController in app/scripts/controllers/timezones_controller.js. We’re also going to implement two actions: “add” and “remove”. These will be used in our template:

WorldClock.TimezonesController = Ember.ObjectController.extend({
    init: function() {
        var timezones = [];
 
        for (var i in moment.tz._zones) {
          timezones.push({
              name: moment.tz._zones[i].name,
              offset: moment.tz._zones[i].offset[0]
          });
      }
 
      this.set('timezones', timezones);
 
      this._super();
  },
 
  selectedTimezone: null,
 
  actions: {
      add: function() {
          var timezone = this.store.createRecord('timezone', {
              name: this.get('selectedTimezone').name,
              offset: this.get('selectedTimezone').offset
          });
 
          timezone.save();
      },
 
      remove: function(timezone) {
          timezone.destroyRecord();
      }
  }
});

So we create a list of all available timezones with offsets. Then we add methods that allow us to add or remove timezones from our offline data store. Next we modify the timezones template in app/templates/timezones.hbs to use the actions and variables we created. All we need to utilize these variables is the Ember SelectView and the {{action}} helper to call our add and remove methods:

<h2>Add Timezone</h2>
 
<p>{{view Ember.Select content=timezones selection=selectedTimezone
       optionValuePath='content.offset' optionLabelPath='content.name'}}</p>
 
<p><button {{action add}}>Add Timezone</button></p>
 
<h2>My Timezones</h2>
 
<ul>
  {{#each model}}
    <li>{{name}} <button {{action remove this}}>Delete</button></li>
  {{/each}}
</ul>

Now we have a Timezones tab that allows us to add and remove Timezones we want to track. This data persists between app refreshes. The last thing we need to do is show these times relative to our local time in our clock tab. To do this we need to load all the Timezone models in the ClockRoute. They’re automatically loaded in the TimezonesRoute, but it’s easy to add them in the ClockRoute (in app/scripts/routes/clock_route.js):

WorldClock.ClockRoute = Ember.Route.extend({
    model: function() {
        return this.get('store').find('timezone');
    }
});

Because of the way our Ember app is wired up, we load all our models in the route and they are sent to the controller once the data store has asynchonously loaded all of the models. The request to find('timezone') actually returns a Promise object, but Ember’s router handles the Promise resolving for us automatically so we don’t have to manage callbacks or Promises ourselves.

Now we have access to all the user’s Timezones in the ClockController, so we can make times in each timezone the user has requested and show them in a list. First we’ll add each Timezone’s current time to our ClockController in app/scripts/controllers/clock_controller.js using Moment.js:

WorldClock.ClockController = Ember.ObjectController.extend({
    updateTime: function() {
        var _this = this;
 
        // Update the time every second.
        Ember.run.later(function() {
            _this.set('localTime', moment().format('h:mm:ss a'));
 
            _this.get('model').forEach(function(model) {
                model.set('time',
                          moment().tz(model.get('name')).format('h:mm:ss a'));
            });
 
            _this.updateTime();
        }, 1000);
    }.on('init'),
 
    localTime: moment().format('h:mm:ss a')
});

Our final app/templates/clock.hbs should look like this:

<h2>Local Time: {{localTime}}</h2>
 
<p>
  {{#each model}}
    <h3>{{name}}: {{time}}</h3>
  {{/each}}
</p>

And that’s it! Now we have an offline app that shows us time zones in various places, saves the data offline, and updates every second without us having to do much work!

Command Line Tools

The old Podcasts app used a (rather awful) Makefile. It wasn’t very useful, and I don’t think it ran on Windows without some serious effort. The new build system uses Node so it runs comfortably on Windows, Mac, and Linux. Commands are proxied via the recroom binary, also written in Node, so you don’t have to worry about the underlying system if you don’t need to modify build steps. recroom new my-app creates a new app; recroom serve serves up your new app, and recroom generate model Podcast creates a new model for you.

To build your app, you just need to run recroom build and a version with minified CSS, JS, and even HTML will be created for you in the dist/ folder. This version is ready to be packaged into a packaged app or uploaded to a server as a hosted app. You can even run recroom deploy to deploy directory to your git repository’s GitHub pages branch, if applicable.

See the app in action!

This entire sample app is available at worldclock.tofumatt.com and the source code is available on GitHub.

Try Using Rec Room for Your Next Web App

You can try out Rec Room on Github. Right now some docs and tools are still being abstracted and built, but you can start building apps today using it and filing bugs for missing features. We’d really love it if you could give it a try and let us know what’s missing. Together we can build a cohesive and polished solution to the all-too-common question: “How do I build a web app?”

Software CarpentryConversations About Teaching

Over the last few days, there have been four related discussion threads on the Software Carpentry mailing lists about what we use, what we teach, and how we teach it. Together, they highlight what we're doing well and where we need to do better.

Stuart Rossiter did a great job of summarizing the first two of those (with some later follow-up):

There was discussion on:

  1. IDE vs. IPython Notebook vs. command-line/text editor for Python teaching
  2. IPython Notebook vs. Markdown for lecture notes (specifically for Python teaching but by implication could extend to teaching other topics)
  3. Tools themselves causing disruptive cognitive loads, related to whether how they work hides (or merges) too many "fundamental" concepts/levels, and the ever-present issue of how this relates to learner backgrounds (and how/whether you can tailor things for an audience, including how one could assess this empirically)

Notice that 1 is really a specific example of 3, i.e., what tool gets the best balance of power/familiarity/understanding fundamentals? However, it's interesting that all the responses (I think) to 1 were actually about what IDE worked best, and not about the types of tool.

2 is in many ways a flavour of 3, but where the learners/users are the SWC contributors. As such, people's backgrounds and the use cases for the tools obviously mean that things like diff handling become important (but, interestingly, most of the discussion was really about familiarity because that's the main barrier-to-entry).

1 and 2 also implicitly bring up the discussion as to whether we teach one consistent toolset. Here, there is a tension between SWC students getting mastery of a well defined tool and concept-set versus them understanding the landscape of tools and concepts.

This highlights three related tensions in many kinds of teaching (not just Software Carpentry):

  1. Fundamentals vs. authentic tasks. On the one hand, people need fundamental concepts in order to know how to use specific tools and practices properly. On the other hand, people come to classes like ours because they want to be able to actually do things, and the sooner they're able to accomplish authentic tasks, the more likely they are to learn and to continue learning.
  2. Foxes vs. hedgehogs. As the saying goes, "The fox knows how to do many things; the hedgehog knows how to do one thing well." If we concentrate on a handful of tasks with lots of reinforcement (as Bennet Fauber stressed), learners will leave knowing how to do a few things well—but only a few. A broad overview of the full landscape of tools and techniques may give them a better understanding of how things fit together, but may also just confuse them, and in either case they will leave having actually mastered fewer things.
  3. Necessary losses. Our teaching is necessarily less than perfect for any particular learner because we don't have the resources to customize each lesson individually, and even if we did, we can't know in advance what "perfect" would actually be. As David Martin said, there is no globally right tool for teaching: what's best depends on the students and the intended learning outcomes, and whatever we pick cannot be the best choice for people who have different backgrounds and want different outcomes.

Our lessons try to strike a balance between the practical and the conceptual by advertising the first and smuggling in the second. For example, our introduction to the Unix shell only covers 15 commands in three hours. Along the way, though, it shows people how a filesystem is organized, how to get the computer to repeat things so that they don't have to, and (hopefully) why lots of small single-purpose tools that work well together are better than one large tool that tries to do everything. Similarly, the real goal of our introduction to Python isn't really to teach people the syntax of Python: it's to convince them that they ought to write short, readable, testable, reusable functions, and that those are actually all the same thing.

Stuart goes on to ask whether the Software Carpentry brand consists of "just" our topics and teaching style, or is tied to the specific tools we use. I want to say it's the former, but in practice, you can't teach programming without picking a language and an editor. Since we don't have the resources to build and maintain lessons covering all combinations of all possibilities, we have to make choices, which effectively means we're advocating some things over others.

Meawhile, Tim McNamara re-raises the perennial question of assessment:

There seems to be be many statements that follow this format: "in my experience, X is better for learners". The problem is that for each X, not-X is also strongly supported. The key points for me is that we're making inferences about outcomes (e.g., learner growth/satisfaction) on the basis of anecdotal evidence (personal experience).

It strikes me that Software Carpentry is in a unique position to actually test and validate which tools work best. We run many bootcamps, have people who know experimental design and have increasingly strong tooling to support to enable experiments.

I couldn't agree more, but as Titus Brown said in reply:

we have had a hard time getting the necessary funding to do good assessments for Software Carpentry. I think we need to support someone trained, focused, and willing to engage long term (~2+ years) with this as their primary project.

We've learned the hard way that assessing the impact of the various things we're doing is neither easy nor cheap. We don't know how to measure the productivity of programmers, or the productivity of scientists, and the unknowns don't cancel out when you put the two together. Jory Schossau has done valuable service by analyzing survey data and interviewing bootcamp participants (see this pre-print for results to date), but if we want to get the right answer, we're going to have to find a backer.

As this discussion was going on, Ethan White tweeted:

Next time you think about getting involved in a debate about programming languages or text editors, go build something cool instead.

I think this thread shows that there's a useful third path. In it, a dozen instructors who have been teaching R compare notes about what they're doing and how it's working. I really enjoyed the exchange of specifics, and I think that more discussions like this will do a lot to strengthen our instructor community.

To wrap up, here are my take-aways from this past week:

  1. I need to do a much better job in the instructor training course of introducing people to our existing material, the tools we use, and the "why" behind both. This probably means adding at least one more two-week cycle to the training; I hope that's a cost potential instructors will be willing to bear.
  2. I need to foster more discussions like the one about how we teach R, and turn those discussions into training material so we don't have to repeat them every twelve months. To get started on that, I'm going to prod people who've taught this year to complete our post-bootcamp instructor survey, and try to get discussions going on the discussion list about how we all actually teach the shell, Python, and Git.
  3. We need to find resources to do assessment properly.
  4. I need to do a better job of monitoring the mailing list (and get someone else to keep an eye on it when I'm not available). Some of the discussion was less respectful than our code of conduct requires, and the onus is on us to make sure that everyone always feels welcome.

We've come a long way since our first workshop at Los Alamos sixteen years ago—if all goes well, we'll reach our ten thousandth learner some time in the next twelve months—but we've still got a lot to learn. We'd welcome your suggestions about what to try next.

Air MozillaWebdev Beer and Tell: August 2014

Webdev Beer and Tell: August 2014 Web developers across the Mozilla community get together (in person and virtually) to share what side projects or cool stuff we've been working on.