mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 3 uur 43 min geleden

Mark Finkle: Firefox for Android: Collecting and Using Telemetry

8 uur 7 min geleden

Firefox 31 for Android is the first release where we collect telemetry data on user interactions. We created a simple “event” and “session” system, built on top of the current telemetry system that has been shipping in Firefox for many releases. The existing telemetry system is focused more on the platform features and tracking how various components are behaving in the wild. The new system is really focused on how people are interacting with the application itself.

Collecting Data

The basic system consists of two types of telemetry probes:

  • Events: A telemetry probe triggered when the users takes an action. Examples include tapping a menu, loading a URL, sharing content or saving content for later. An Event is also tagged with a Method (how was the Event triggered) and an optional Extra tag (extra context for the Event).
  • Sessions: A telemetry probe triggered when the application starts a short-lived scope or situation. Examples include showing a Home panel, opening the awesomebar or starting a reading viewer. Each Event is stamped with zero or more Sessions that were active when the Event was triggered.

We add the probes into any part of the application that we want to study, which is most of the application.

Visualizing Data

The raw telemetry data is processed into summaries, one for Events and one for Sessions. In order to visualize the telemetry data, we created a simple dashboard (source code). It’s built using a great little library called PivotTable.js, which makes it easy to slice and dice the summary data. The dashboard has several predefined tables so you can start digging into various aspects of the data quickly. You can drag and drop the fields into the column or row headers to reorganize the table. You can also add filters to any of the fields, even those not used in the row/column headers. It’s a pretty slick library.

uitelemetry-screenshot-crop

Acting on Data

Now that we are collecting and studying the data, the goal is to find patterns that are unexpected or might warrant a closer inspection. Here are a few of the discoveries:

Page Reload: Even in our Nightly channel, people seem to be reloading the page quite a bit. Way more than we expected. It’s one of the Top 2 actions. Our current thinking includes several possibilities:

  1. Page gets stuck during a load and a Reload gets it going again
  2. Networking error of some kind, with a “Try again” button on the page. If the button does not solve the problem, a Reload might be attempted.
  3. Weather or some other update-able page where a Reload show the current information.

We have started projects to explore the first two issues. The third issue might be fine as-is, or maybe we could add a feature to make updating pages easier? You can still see high uses of Reload (reload) on the dashboard.

Remove from Home Pages: The History, primarily, and Top Sites pages see high uses of Remove (home_remove) to delete browsing information from the Home pages. People do this a lot, again it’s one of the Top 2 actions. People will do this repeatably, over and over as well, clearing the entire list in a manual fashion. Firefox has a Clear History feature, but it must not be very discoverable. We also see people asking for easier ways of clearing history in our feedback too, but it wasn’t until we saw the telemetry data for us to understand how badly this was needed. This led us to add some features:

  1. Since the History page was the predominant source of the Removes, we added a Clear History button right on the page itself.
  2. We added a way to Clear History when quitting the application. This was a bit tricky since Android doesn’t really promote “Quitting” applications, but if a person wants to enable this feature, we add a Quit menu item to make the action explicit and in their control.
  3. With so many people wanting to clear their browsing history, we assumed they didn’t know that Private Browsing existed. No history is saved when using Private Browsing, so we’re adding some contextual hinting about the feature.

These features are included in Nightly and Aurora versions of Firefox. Telemetry is showing a marked decrease in Remove usage, which is great. We hope to see the trend continue into Beta next week.

External URLs: People open a lot of URLs from external applications, like Twitter, into Firefox. This wasn’t totally unexpected, it’s a common pattern on Android, but the degree to which it happened versus opening the browser directly was somewhat unexpected. Close to 50% of the URLs loaded into Firefox are from external applications. Less so in Nightly, Aurora and Beta, but even those channels are almost 30%. We have started looking into ideas for making the process of opening URLs into Firefox a better experience.

Saving Images: An unexpected discovery was how often people save images from web content (web_save_image). We haven’t spent much time considering this one. We think we are doing the “right thing” with the images as far as Android conventions are concerned, but there might be new features waiting to be implemented here as well.

Take a look at the data. What patterns do you see?

Here is the obligatory UI heatmap, also available from the dashboard:
uitelemetry-heatmap

Categorieën: Mozilla-nl planet

Gregory Szorc: Repository-Centric Development

do, 24/07/2014 - 22:23

I was editing a wiki page yesterday and I think I coined a new term which I'd like to enter the common nomenclature: repository-centric development. The term refers to development/version control workflows that place repositories - not patches - first.

When collaborating on version controlled code with modern tools like Git and Mercurial, you essentially have two choices on how to share version control data: patches or repositories.

Patches have been around since the dawn of version control. Everyone knows how they work: your version control system has a copy of the canonical data and it can export a view of a specific change into what's called a patch. A patch is essentially a diff with extra metadata.

When distributed version control systems came along, they brought with them an alternative to patch-centric development: repository-centric development. You could still exchange patches if you wanted, but distributed version control allowed you to pull changes directly from multiple repositories. You weren't limited to a single master server (that's what the distributed in distributed version control means). You also didn't have to go through an intermediate transport such as email to exchange patches: you communicate directly with a peer repository instance.

Repository-centric development eliminates the middle man required for patch exchange: instead of exchanging derived data, you exchange the actual data, speaking the repository's native language.

One advantage of repository-centric development is it eliminates the problem of patch non-uniformity. Patches come in many different flavors. You have plain diffs. You have diffs with metadata. You have Git style metadata. You have Mercurial style metadata. You can produce patches with various lines of context in the diff. There are different methods for handling binary content. There are different ways to express file adds, removals, and renames. It's all a hot mess. Any system that consumes patches needs to deal with the non-uniformity. Do you think this isn't a problem in the real world? Think again. If you are involved with an open source project that collects patches via email or by uploading patches to a bug tracker, have you ever seen someone accidentally upload a patch in the wrong format? That's patch non-uniformity. New contributors to Firefox do this all the time. I also see it in the Mercurial project. With repository-centric development, patches never enter the picture, so patch non-uniformity is a non-issue. (Don't confuse the superficial formatting of patches with the content, such as an incorrect commit message format.)

Another advantage of repository-centric development is it makes the act of exchanging data easier. Just have two repositories talk to each other. This used to be difficult, but hosting services like GitHub and Bitbucket make this easy. Contrast with patches, which require hooking your version control tool up to wherever those patches are located. The Linux Kernel, like so many other projects, uses email for contributing changes. So now Git, Mercurial, etc all fulfill Zawinski's law. This means your version control tool is talking to your inbox to send and receive code. Firefox development uses Bugzilla to hold patches as attachments. So now your version control tool needs to talk to your issue tracker. (Not the worst idea in the world I will concede.) While, yes, the tools around using email or uploading patches to issue trackers or whatever else you are using to exchange patches exist and can work pretty well, the grim reality is that these tools are all reinventing the wheel of repository exchange and are solving a problem that has already been solved by git push, git fetch, hg pull, hg push, etc. Personally, I would rather hg push to a remote and have tools like issue trackers and mailing lists pull directly from repositories. At least that way they have a direct line into the source of truth and are guaranteed a consistent output format.

Another area where direct exchange is huge is multi-patch commits (branches in Git parlance) or where commit data is fragmented. When pushing patches to email, you need to insert metadata saying which patch comes after which. Then the email import tool needs to reassemble things in the proper order (remember that the typical convention is one email per patch and email can be delivered out of order). Not the most difficult problem in the world to solve. But seriously, it's been solved already by git fetch and hg pull! Things are worse for Bugzilla. There is no bullet-proof way to order patches there. The convention at Mozilla is to add Part N strings to commit messages and have the Bugzilla import tool do a sort (I assume it does that). But what if you have a logical commit series spread across multiple bugs? How do you reassemble everything into a linear series of commits? You don't, sadly. Just today I wanted to apply a somewhat complicated series of patches to the Firefox build system I was asked to review so I could jump into a debugger and see what was going on so I could conduct a more thorough review. There were 4 or 5 patches spread over 3 or 4 bugs. Bugzilla and its patch-centric workflow prevented me from importing the patches. Fortunately, this patch series was pushed to Mozilla's Try server, so I could pull from there. But I haven't always been so fortunate. This limitation means developers have to make sacrifices such as writing fewer, larger patches (this makes code review harder) or involving unrelated parties in the same bug and/or review. In other words, deficient tools are imposing limited workflows. No bueno.

It is a fair criticism to say that not everyone can host a server or that permissions and authorization are hard. Although I think concerns about impact are overblown. If you are a small project, just create a GitHub or Bitbucket account. If you are a larger project, realize that people time is one of your largest expenses and invest in tools like proper and efficient repository hosting (often this can be GitHub) to reduce this waste and keep your developers happier and more efficient.

One of the clearest examples of repository-centric development is GitHub. There are no patches in GitHub. Instead, you git push and git fetch. Want to apply someone else's work? Just add a remote and git fetch! Contrast with first locating patches, hooking up Git to consume them (this part was always confusing to me - do you need to retroactively have them sent to your email inbox so you can import them from there), and finally actually importing them. Just give me a URL to a repository already. But the benefits of repository-centric development with GitHub don't stop at pushing and pulling. GitHub has built code review functionality into pushes. They call these pull requests. While I have significant issues with GitHub's implemention of pull requests (I need to blog about those some day), I can't deny the utility of the repository-centric workflow and all the benefits around it. Once you switch to GitHub and its repository-centric workflow, you more clearly see how lacking patch-centric development is and quickly lose your desire to go back to the 1990's state-of-the-art methods for software development.

I hope you now know what repository-centric development is and will join me in championing it over patch-based development.

Mozillians reading this will be very happy to learn that work is under way to shift Firefox's development workflow to a more repository-centric world. Stay tuned.

Categorieën: Mozilla-nl planet

Sean Bolton: Why Do People Join and Stay Part Of a Community (and How to Support Them)

do, 24/07/2014 - 21:58

[This post is inspired by notes from a talk by Douglas Atkin (currently at AirBnB) about his work with cults, brands and community.]

We all go through life feeling like we are different. When you find people that are different the same way you are, that’s when you decide to join.

As humans, we each have a unique self narrative: “we tell ourselves a story about who we are, what others are like, how the world works, and therefore how one does (or does not) belong in order to maximize self.” We join a community to become more of ourselves – to exist in a place where we feel we don’t have to self-edit as much to fit in.

A community must have a clear ideology – a set of beliefs about what it stands for – a vision of the world as it should be rather than how it is, that aligns with what we believe. Communities form around certain ways of thinking first, not around products. At Mozilla, this is often called “the web we want” or ‘the web as it should be.’

When joining a community people ask two questions: 1) Are they like me? and 2) Will they like me? The answer to these two fundamental human questions determine whether a person will become and stay part of a community. In designing a community it is important to support potential members in answering these questions – be clear about what you stand for and make people feel welcome. The welcoming portion requires extra work in the beginning to ensure that a new member forms relationships with people in the community. These relationships keep people part of a community. For example, I don’t go to a book club purely for the book, I go for my friends Jake and Michelle. Initially, the idea of a book club attracted me but as I became friends with Jake and Michelle, that friendship continually motivated me to show up. This is important because as the daily challenges of life show up, social bonds become our places of belonging where we can recharge.

 Douglas Atkin, The Glue Projecy

Source: Douglas Atkin, The Glue Project

These social ties must be mixed with doing significant stuff together. In designing how community members participate, a very helpful tool is the community commitment curve. This curve describes how a new member can invest in low barrier, easy tasks that build commitment momentum so the member can perform more challenging tasks and take on more responsibility. For example, you would not ask a new member to spend 12 hours setting up a development environment just to make their first contribution. This ask is too much for a new person because they are still trying to figure out ‘are the like me?’ and ‘will they like me?’ In addition, their sense of contribution momentum has not been built – 12 hours is a lot when your previous task is 0 but 12 is not so much when your previous was 10.

The community commitment curve is a powerful tool for community builders because it forces you to design the small steps new members can take to get involved and shows structure to how members take on more complex tasks/roles – it takes some of the mystery out! As new members invest small amounts of time, their commitment grows, which encourages them to invest larger amounts of time, continually growing both time and commitment, creating a fulfilling experience for the community and the member. I made a template for you to hack your own community commitment curve.

Social ties combined with a well designed commitment curve, for a clearly defined purpose, is powerful combination in supporting a community.


Categorieën: Mozilla-nl planet

Marco Bonardo: Unified Complete coming to Firefox 34

do, 24/07/2014 - 18:23

The awesomebar in Firefox Desktop has been so far driven by two autocomplete searches implemented by the Places component:

  1. history: managing switch-to-tab, adaptive and browsing history, bookmarks, keywords and tags
  2. urlinline: managing autoFill results

Moving on, we plan to improve the awesomebar contents making them even more awesome and personal, but the current architecture complicates things.

Some of the possible improvements suggested include:

  • Better identify searches among the results
  • Allow the user to easily find favorite search engine
  • Always show the action performed by Enter/Go
  • Separate searches from history
  • Improve the styling to make each part more distinguishable

When working on these changes we don't want to spend time fighting with outdated architecture choices:

  • Having concurrent searches makes hard to insert new entries and ensure the order is appropriate
  • Having the first popup entry disagree with the autoFill entry makes hard to guess the expected action
  • There's quite some duplicate code and logic
  • All of this code predates nice stuff like Sqlite.jsm, Task.jsm, Preferences.js
  • The existing code is scary to work with and sometimes obscure

Due to these reasons, we decided to merge the existing components into a single new component called UnifiedComplete (toolkit/components/places/UnifiedComplete.js), that will take care of both autoFill and popup results. While the component has been rewritten from scratch, we were able to re-use most of the old logic that was well tested and appreciated. We were also able to retain all of the unit tests, that have been also rewritten, making them use a single harness (you can find them in toolkit/components/places/tests/unifiedcomplete/).

So, the actual question is: which differences should I expect from this change?

  • The autoFill result will now always cope with the first popup entry. Though note the behavior didn't change, we will still autoFill up to the first '/'. This means a new popup entry is inserted as the top match.
  • All initialization is now asynchronous, so the UI should not lag anymore at the first awesomebar search
  • The searches are serialized differently, responsiveness timing may differ, usually improve
  • Installed search engines will be suggested along with other matches to improve their discoverability

The component is currently disabled, but I will shortly push a patch to flip the pref that enables it. The preference to control whether to use new or old components is browser.urlbar.unifiedcomplete, you can already set it to true into your current Nightly build to enable it.

This also means old components will shortly be deprecated and won't be maintained anymore. That won't happen until we are completely satisfied with the new component, but you should start looking at the new one if you use autocomplete in your project. Regardless we'll add console warnings at least 2 versions before complete removal.

If you notice anything wrong with the new awesomebar behavior please file a bug in Toolkit/Places and make it block Bug UnifiedComplete so we are notified of it and can improve the handling before we reach the first Release.

Categorieën: Mozilla-nl planet

Christian Heilmann: [Video]: The web is dead? – My talk at TEDx Thessaloniki

do, 24/07/2014 - 18:18

Today the good folks at TEDx Thessaloniki released the recording of my talk “The web is dead“.

Christian Heilmann at TEDx

I’ve given you the slides and notes earlier here on this blog but here’s another recap of what I talked about:

  • The excitement for the web is waning – instead apps are the cool thing
  • At first glance, the reason for this is that apps deliver much better on a mobile form factor and have a better, high fidelity interaction patterns
  • If you scratch the surface of this message though you find a few disturbing points:
    • Everything in apps is a number game – the marketplaces with the most apps win, the apps with the most users are the ones that will get more users as those are the most promoted ones
    • The form factor of an app was not really a technical necessity. Instead it makes software and services a consumable. The full control of the interface and the content of the app lies with the app provider, not the users. On the web you can change the display of content to your needs, you can even translate and have content spoken out for you. In apps, you get what the provider allows you to get
    • The web allowed anyone to be a creator. The curb to mount from reader to writer was incredibly low. In the apps world, it becomes much harder to become a creator of functionality.
    • Content creation is easy in apps. If you create the content the app makers wants you to. The question is who the owner of that content is, who is allowed to use it and if you have the right to stop app providers from analysing and re-using your content in ways you don’t want them to. Likes and upvotes/downvotes aren’t really content creation. They are easy to do, don’t mean much but make sure the app creator has traffic and interaction on their app – something that VCs like to see.
    • Apps are just another form factor to control software for the benefit of the publisher. Much like movies on DVDs are great, because when you scratch them you need to buy a new one, publishers can now make software services become outdated, broken and change, forcing you to buy a new one instead of enjoying new features cropping up automatically.
    • Apps lack the data interoperability of the web. If you want your app to succeed, you need to keep the users locked into yours and not go off and look at others. That way most apps are created to be highly addictive with constant stimulation and calls to action to do more with them. In essence, the business models of apps these days force developers to create needy, bullying tamagotchi and call them innovation

Categorieën: Mozilla-nl planet

Jennie Rose Halperin: Video about Open Source and Community

do, 24/07/2014 - 14:30

Building and Leveraging an Open Source Developer Community.

this talk by Jade Wang is really great. Thanks to Adam Lofting for turning me onto it!

 

Categorieën: Mozilla-nl planet

Monica Chew: Download files more safely with Firefox 31

do, 24/07/2014 - 02:54

Did you know that the estimated cost of malware is hundreds of billions of dollars per year? Even without data loss or identity theft, the time and annoyance spent dealing with infected machines is a significant cost.

Firefox 31 offers improved malware detection. Firefox has integrated Google’s Safe Browsing API for detecting phishing and malware sites since Firefox 2. In 2012 Google expanded their malware detection to include downloaded files and made it available to other browsers. I am happy to report that improved malware detection has landed in Firefox 31, and will have expanded coverage in Firefox 32.

In preliminary testing, this feature cuts the amount of undetected malware by half. That’s a significant user benefit.
What happens when you download malware? Firefox checks URLs associated with the download against a local Safe Browsing blocklist. If the binary is signed, Firefox checks the verified signature against a local allowlist of known good publishers. If no match is found, Firefox 32 and later queries the Safe Browsing service with download metadata (NB: this happens only on Windows, because signature verification APIs to suppress remote lookups are only available on Windows). In case malware is detected, the Download Manager will block access to the downloaded file and remove it from disk, displaying an error in the Downloads Panel below.


How can I turn this feature off? This feature respects the existing Safe Browsing preference for malware detection, so if you’ve already turned that off, there’s nothing further to do. Below is a screenshot of the new, beautiful in-content preferences (Preferences > Security) with all Safe Browsing integration turned off. I strongly recommend against turning off malware detection, but if you decide to do so, keep in mind that phishing detection also relies on Safe Browsing.
Many thanks to Gian-Carlo Pascutto and Paolo Amadini for reviews, and the Google Safe Browsing team for helping keep Firefox users safe and secure!
Categorieën: Mozilla-nl planet

Erik Vold: Mozilla University

do, 24/07/2014 - 02:00

When I was young I only cared about Math, math and math, but saw no support, no interesting future, no jobs (that I cared for), nor any respect for the field. In my last year of high school I started thinking about my future, so I sought out advice and suggestions from the adults that I respected. The only piece of advice that I cared for was from my father, he simply suggested that I start with statistics because there are good jobs available for a person with those skills and if I didn’t like it I would find something else. I had taken an intro class to statistics and it was pretty easy, so I decided to give it a try.

Statistics was easy, and boring, so I tried computer science because I had been making web sites for people on the side, off and on, since I was 16, and it was interesting, especially since the best application of statistics to my mind is computer learning. I enjoyed the comp sci classes most of all, and I took 5 years to get my bachelor’s degree in statistics and computer science. It was a great experience for me.

Slightly before I graduated I started working full time as a web developer, after a couple of years I started tinkering with creating add-ons, because I was spending 8+ hours a day using Firefox and I figured I could make it suite my needs a little more, and maybe others would enjoy my hacks too, so I started making userscripts, ubiquity commands, jetpacks, and add-ons.

It’s been 5 years now since I started hacking on projects in the Mozilla community, and these last five years have been just as valuable to me as the 5 years that I spent at UBC. I consider this to be my 2nd degree.

Now when I think about how to grow the community, how to educate the masses, how to reward people for their awesome contributions, I can think of no better way than a free Mozilla University.

We have webmaker today, and I thought it was interesting at first, so I contributed to the best of ability for the first 2 years, but I see some fundamental issues with it. For instance, how do we measure the success of webmaker? how do we know that we’ve affected people? how do we know whether or not these people have decided to continue their education or not? and if they decide to continue their webmaker education then how do we help them? finally, do we respect the skills we teach if do we not provide credentials?

I, for one, would like to see Open Badges and Webmaker become Mozilla University, a free, open source, peer-to-peer, distributed, and widely respected place to learn.

I feel that one of the most important parts of my job at Mozilla is to teach, but how many of us are really doing this? Mozilla University could also be a way to measure our progress.

Categorieën: Mozilla-nl planet

Nick Cameron: LibHoare - pre- and postconditions in Rust

wo, 23/07/2014 - 23:13
I wrote a small macro library for writing pre- and postconditions (design by contract style) in Rust. It is called LibHoare (named after the logic and in turn Tony Hoare) and is here (along with installation instructions). It should be easy to use in your Rust programs, especially if you use Cargo. If it isn't, please let me know by filing issues on GitHub.

The syntax is straightforward, you add `[#precond="predicate"]` annotations before a function where `predicate` is any Rust expression which will evaluate to a bool. You can use any variables which would be in scope where the function is defined and any arguments to the function. Preconditions are checked dynamically before a function is executed on every call to that function.

You can also write `[#postcond="predicate"]` which is checked on leaving a function and `[#invariant="predicate"]` which is checked before and after. You can write any combination of annotations too. In postconditions you can use the special variable `result` (soon to be renamed to `return`) to access the value returned by the function.

There are also `debug_*` versions of each annotation which are not checked in --ndebug builds.

The biggest limitation at the moment is that you can only write conditions on functions, not methods (even static ones). This is due to a restriction on where any annotation can be placed in the Rust compiler. That should be resolved at some point and then LibHoare should be pretty easy to update.

If you have ideas for improvement, please let me know! Contributions are very welcome.

# Implementation

The implementation of these syntax extensions is fairly simple. Where the old function used to be, we create a new function with the same signature and an empty body. Then we declare the old function inside the new function and call it with all the arguments (generating the list of arguments is the only interesting bit here because arguments in Rust can be arbitrary patterns). We then return the result of that function call as the result of the outer function. Preconditions are just an `assert!` inserted before calling the inner function and postconditions are an `assert!` inserted after the function call and before returning.
Categorieën: Mozilla-nl planet

Andrew Overholt: We held a Mozilla “bootcamp”. You won’t believe how it went!

wo, 23/07/2014 - 22:33

For a while now a number of Mozillians have been discussing the need for some sort of technical training on Gecko and other Mozilla codebases. A few months ago, Vlad and I and a few others came up with a plan to try out a “bootcamp”-like event. We initially thought we’d have non-core developers learn from more senior developers for 4 days and had a few goals:

  • teach people not developing Mozilla code daily about the development process
  • expose Mozillians to areas with which they’re not familiar
  • foster shared ownership of areas of code and tools
  • teach people where to look in the code when they encounter a bug and to more accurately file a bug (“teach someone how to fish”)

While working towards this we realized that there isn’t as much shared ownership as there could be within Mozilla codebases so we focused on 2 engineering teams teaching other engineers. The JavaScript and Graphics teams agreed to be mentors and we solicited participants from a few paid Mozillians to try this out. We intentionally limited the audience and hand-picked them for this first “beta” since we had no idea how it would go.

The event took place over 4 days in Toronto in early June. We ended up with 5 or 6 mentors (the Graphics team having a strong employee presence in Toronto helped with pulling in experts here and there) and 9 attendees from a variety of engineering teams (Firefox OS, Desktop, and Platform).

The week’s schedule was fairly loose to accommodate questions and make it more of a conversational atmosphere. We planned sessions in an order to give a high level overview followed by deeper dives. We also made sessions about complementary Gecko components happen in a logical order (ex. layout then graphics). You can see details about the schedule we settled upon here: https://etherpad.mozilla.org/bootcamp1plans.

We collaboratively took notes and recorded everything on video. We’re still in the process of creating usable short videos out of the raw feeds we recorded. Text notes were captured on this etherpad which had some real-time clarifications made by people not physically present (Ms2ger and others) which was great.

The week taught us a few things, some obvious, some not so obvious:

  • people really want time for learning. This was noted more than once and positive comments I received made me realize it could have been held in the rain and people would have been happy
  • having a few days set aside for professional development was very much appreciated so paid Mozillians incorporating this into their goals should be encouraged
  • people really want the opportunity to learn from and ask questions of more seasoned Mozilla hackers
  • hosting this in a MozSpace ensured reliable facilities, flexibility in terms of space, and the availability of others to give ad hoc talks and answer questions when necessary. It also allowed others who weren’t official attendees to listen in for a session or two. Having it in the office also let us use the existing video recording setup and let us lean on the ever-amazing Jonathan Lin for audio and video help. I think you could do this outside a MozSpace but you’d need to plan a bit more for A/V and wifi, etc.
  • background noise (HVAC, server fans, etc.) is very frustrating for conversations and audio recording (but we already knew this)
  • this type of event is unsuitable for brand new {employees|contributors} since it’s way too much information. It would be more applicable after someone’s been involved for a while (6 months, 1 year?).

In terms of lessons for the future, a few things come to mind:

  • interactive exercises were very well received (thanks, kats!) and cemented people’s learning as expected
  • we should perhaps define homework to be done in advance and strongly encourage completion of it; videos of previous talks may be good material
  • scheduling around 2 months in advance seemed to be best to balance “I have no idea what I’ll be doing then” and “I’m already busy that week”
  • keeping the ratio of attendees to “instructors” to around 2 or 3 to 1 worked well for interactivity and ensuring the right people were present who could answer questions
  • although very difficult, attempting to schedule around major deadlines is useful (this week didn’t work for a few of the Firefox OS teams)
  • having people wear lapel microphones instead of a hand-held one makes for much better and more natural audio
  • building a schedule, mentors, and attendee list based on common topics of interest would be an interesting experiment instead of the somewhat mixed bag of topics we had this time
  • using whiteboards and live coding/demos instead of “slides” worked very well

Vlad and I think we should do this again. He proposed chaining organizers so each organizer sets one up and helps the next person do it. Are you interested in being the next organizer?

I’m very interested in hearing other people’s thoughts about this so if you have any, leave a comment or email me or find me on IRC or send me a postcard c/o the Toronto office (that would be awesome).

Categorieën: Mozilla-nl planet

Swarnava Sengupta: Flashing Flame Devices with Firefox OS

wo, 23/07/2014 - 19:52
If you have a Flame reference device and wanna try out alternate versions of Firefox OS apart from the stock one, but not willing to build from source, then follow this mini-manual.
Get the buildYou can download the packages from the Nightly Build directories of Mozilla FTP. You specifically need the following two files:
  • b2g-XX.0a1.en-US.android-arm.tar.gz (XX is the version number)
  • gaia.zip

    Set up environmentOnce you have the build, decompress both of them in the same directory. Download the flash.sh file from this gist and put it into the same directory as well.
    N.B: You will have to set executable bit to the script file ($ chmod a+x flash.sh).
    Flashing the device
    1. Enable remote debugging in Device's Developer Settings
    2. Connect the device to the system over USB
    3. You will need to have have ADB installed 3.1. Run $ adb devices3.2. Check for Flame in the listed devices 3.3. If device is listed, proceed to step 4 (if not, troubleshoot)
    4. Run the script to initiate flashing $ ./flash.sh
    5. Follow the instructions to customize your flashing as per your need.
    6. If you face issues, try flashing with /data partition formatted when asked.
    7. Profit!
    UpdatesAfter you're done flashing, your device will be on the Nightly channel, receiving updates almost each day. Those updates will be over the air (OTA) download of ~60MB, and completely hassle free.

    Credit: Thanks to Deb. :) https://gist.github.com/debloper/e7d194ddb7c1011bbeda
    Categorieën: Mozilla-nl planet

    Doug Belshaw: Making the web simple, but not simplistic

    wo, 23/07/2014 - 16:49

    A couple of months ago, an experimental feature Google introduced in the ‘Canary’ build of its Chrome browser prompted a flurry of posts in the tech press. The change was to go one step further than displaying an ‘origin chip’ and do away with the URL entirely:

    Hidden URL

    I have to admit that when I first heard of this I was horrified – I assumed it was being done for the worst of reasons (i.e. driving more traffic to Google search). However, on reflection, I think it’s a nice example of progressive complexity. Clicking on the root name of the site reveals the URL. Otherwise, typing in the omnibox allows you to search the web:

    Google Chrome experiment

    Progressive complexity is something we should aspire to when designing tools for a wide range of users. It’s demonstrated well by my former Mozilla colleague Rob Hawkes in his work on ViziCities:

    progressive-complexity.png http://slidesha.re/1kbYyYU

    Using this approach means that those that are used to manipulating URLs are catered for – but the process is simplified for novice users.

    Something we forget is that URLs often depend on the file structures of web servers: http://server.com/directory/sub-directory/file.htm. There’s no particular reason why this should be the case.

    iCloud and Pages on OS X Pages on Mac OS X saving to iCloud

    google-drive.png Google Drive interface

    It’s worth noting that both Apple and Google here don’t presuppose you will create folders to organise your documents and digital artefacts. You can do so, or add tags, but it’s just as easy to dump them all in one place and search efficiently. It’s human-centred design.

    My guiding principle here from a web literacy point of view is whether simplification and progressive complexity is communicated to users. Is it clear that there’s more to this than what’s presented on the surface? With the examples I’ve given in this post, I feel that they are.

    Questions? Comments? I’m @dajbelshaw or you can email me at doug@mozillafoundation.org.

    Categorieën: Mozilla-nl planet

    Pete Moore: Weekly review 2014-07-23

    wo, 23/07/2014 - 16:33

    Highlights

    This week I rolled out the l10n changes, after a few more iterations of tweaks / improvements / nice-to-haves. I am coordinating with Hal about when we can cut over from legacy (as this will need his involvement) which depends a little bit on his availability - he has already proactively contacted me to let me know he is quite tied up at the moment, so it is unlikely we’ll be able to engage in roll out work together for the next couple of weeks until hg issues have stablised, and he has completed some work with fubar/bkero and the interns.

    I’ve had discussions with Aki about various vcs sync matters (both technical and business relationship-wise) and am confident I am in a good position to lead this going forward.

    I also rolled out changes to the email notifications, which unfortunately I had to roll back.

    Now l10n is done (apart from cutover) the last two parts are gecko.git and gecko-projects - which I anticipate as being relatively trouble-free.

    After that comes git-hg and git-git support (currently new vcs sync only supports hg-git).

    Other

    Looking forward to getting involved with release process (https://bugzilla.mozilla.org/show_bug.cgi?id=1042128)

    Categorieën: Mozilla-nl planet

    Dave Hunt: A new home for the gaiatest documentation

    wo, 23/07/2014 - 14:56

    The gaiatest python package provides a test framework and runner for testing Gaia (the user interface for Firefox OS). It also provides a handy command line tool and can be used as a dependency from other packages that need to interact with Firefox OS.

    Documentation for this package has now been moved to gaiatest.readthedocs.org, which is generated directly from the source code whenever there’s an update. In order to make this more useful we will continue to add documentation to the Python source code. If you’re interested in helping us out please get in touch by leaving a comment, or joining #ateam on irc.mozilla.org and letting us know.

    Categorieën: Mozilla-nl planet

    Francesca Ciceri: Adventures in Mozillaland #3

    wo, 23/07/2014 - 13:04

    Yet another update from my internship at Mozilla, as part of the OPW.

    A brief one, this time, sorry.

    Bugs, Bugs, Bugs, Bacon and Bugs

    I've continued with my triaging/verifying work and I feel now pretty confident when working on a bug.
    On the other hand, I think I've learned more or less what was to be learned here, so I must think (and ask my mentor) where to go from now on.
    Maybe focus on a specific Component?
    Or steadily work on a specific channel for both triaging/poking and verifying?
    Or try my hand at patches?
    Not sure, yet.

    Also, I'd like to point out that, while working on bug triaging, the developer's answers on the bug report are really important.
    Comments like this help me as a triager to learn something new, and be a better triager for that component.
    I do realize that developers cannot always take the time to put in comments basic information on how to better debug their component/product, but trust me: this will make you happy on the long run.
    A wiki page with basic information on how debug problems for your component is also a good idea, as long as that page is easy to find ;).

    So, big shout-out for MattN for a very useful comment!

    Community

    After much delaying, we finally managed to pick a date for the Bug Triage Workshop: it will be on July 25th. The workshop will be an online session focused on what is triaging, why is important, how to reproduce bugs and what information ask to the reporter to make a bug report the most complete and useful possible.
    We will do it in two different time slots, to accomodate various timezones, and it will be held on #testday on irc.mozilla.org.
    Take a look at the official announcement and subscribe on the event's etherpad!

    See you on Friday! :)

    Categorieën: Mozilla-nl planet

    Gervase Markham: Fraudulent Passport Price List

    wo, 23/07/2014 - 12:24

    This is a list (URL acquired from spam) of prices for fraudulent (but perhaps “genuine” in terms of the materials used, I don’t know) passports, driving licenses and ID cards. It is a fascinating insight into the relative security of the identification systems of a number of countries. Of course, the prices may also factor in the economic value of the passport, but it’s interesting that a Canadian passport is more expensive than a US one. That probably reflects difficulty of obtaining the passport rather than the greater desirability of Canada over the US. (Sorry, Canadians, I know you’d disagree! Still, you can be happy at the competence and lack of corruption in your passport service.)

    One interesting thing to note is that one of the joint lowest-price countries, Latvia (€900), is a member of the EU. A Latvian passport allows you to live and work in any EU country, even Germany, which has the most expensive passports (€5200). The right to live anywhere in the EU – yours for only €900…

    Also interesting is to sort by passport price and look if the other prices follow the same curve. A discrepancy may indicate particularly weak or strong security. So Russian ID cards are cheaper than one might expect, whereas Belgian ones are more expensive. Austrian and Belgian driver’s licenses also seem to be particularly hard to forge, but the prize there goes to the UK, which has the top-priced spot (€2000). I wonder if that’s related to the fact that the UK doesn’t have ID cards, so the driver’s license often functions as one?

    Here is the data in spreadsheet form (ODS), so you can sort and analyse, and just in case the original page disappears…

    Categorieën: Mozilla-nl planet

    Sylvestre Ledru: Auto-comment on the Release Management flags

    wo, 23/07/2014 - 12:03

    Implemented in bug 853108 by the bmo team, using the tracking flags will automatically updated the comment field with some templates.
    The goal is to reduce back and forth in Bugzilla on bug tracking. We also hope that is going to improve our response time.

    For example, for the tracking requests (tracking-firefoxNN, tracking-firefox-esrNN or blocking-b2g), the user will see the text added into the Bugzilla comment field:

    [Tracking Requested - why for this release]:

    With this change, we hope to simplify the decision process for the release team.

    For the relnotes-* flags:

    Release Note Request (optional, but appreciated)
    [Why is this notable]:
    [Suggested wording]:
    [Links (documentation, blog post, etc)]:

    This change aims to simplify the process of release notes writing. In some cases, it can be hard for release manager to translate a bug into a new feature description.

    Flags on which this option is enabled are:

    • relnote-firefox
    • relnote-b2g
    • tracking-firefoxNN
    • tracking-firefox-esrNN
    • blocking-b2g

    Finally, we reported bug 1041964 to discuss about a potential auto-focus on the comment area.

    Original post blogged on b2evolution.

    Categorieën: Mozilla-nl planet

    Manish Goregaokar: 200, and more!

    wo, 23/07/2014 - 05:55
    After my last post on my running GitHub streak, I've pretty much continued to contribute to the same projects, so I didn't see much of a point of posting about it again — the fun part about these posts is talking about all the new projects I've started or joined. However, this time an arbitrary base-ten milestone comes rather close to another development on the GitHub side which is way more awesome than a streak; hence the post.

    Firstly, a screenshot:
    I wish there was more dark green
    Now, let's have a look at the commit that made the streak reach 200. That's right, it's a merge commit to Servo — something which is created for the collaborator who merges the pull request1. Which is a great segue into the second half of this post:

    I now have commit/collaborator access to Servo. :D

    It happened around a week back. Ms2ger needed a reviewer, Lars mentioned he wanted to get me more involved, I said I didn't mind reviewing, and in a few minutes I was reviewing a pull request for the first time. A while later I had push access.

    This doesn't change my own workflow while contributing to Servo; since everyone still goes through pull requests and reviews. But it gives a much greater sense of belonging to a project. Which is saying something, since Mozilla projects already give one a sense of being "part of the team" rather early on, with the ability to attend meetings, take part in decision-making, and whatnot.

    I also now get to review others' code, which is a rather interesting exercise. I haven't done much reviewing before. Pull requests to my own repos don't count much since they're not too frequent and if there are small issues I tend to just merge and fix. I do give feedback for patches on Firefox (mostly for the ones I mentor or if asked on IRC), but in this situation I'm not saying that the code is worthy to be merged; I'm just pointing out any issues and/or saying "Looks good to me".

    With Servo, code I review and mark as OK is ready for merging. Which is a far bigger responsibility. I make mistakes (and style blunders) in my own code, so marking someone else's code as mistake free is a bit intimidating at first. Yes, everyone makes mistakes and yet we have code being reviewed properly, but right now I'm new to all this, so I'm allowed a little uncertainty ;) Hopefully in a few weeks I'll be able to review code without overthinking things too much.


    In other GitHub-ish news, a freshman of my department submitted a very useful pull request to one of my repos. This makes me happy for multiple reasons: I have a special fondness for student programmers who are not from CS (not that I don't like CS students), being one myself. Such students face an extra set of challenges of finding a community, learning the hard stuff without a professor, and juggling their hobby with normal coursework (though to be fair for most CS students their hobby programming rarely intersects with coursework either).

    Additionally, the culture of improving tools that you use is one that should be spread, and it's great that at least one of the new students is a part of this culture. Finally, it means that people use my code enough to want to add more features to it :)

    1. I probably won't count this as part of my streak and make more commits later today. Reviewing is hard, but it doesn't exactly take the place of writing actual code so I may not count merge commits as part of my personal commit streak rules.
    Categorieën: Mozilla-nl planet

    Julien Vehent: OpSec's public mailing list

    wo, 23/07/2014 - 03:14

    Mozilla's Operations Security team (OpSec) protects the networks, systems, services and data that power the Mozilla project. The nature of the job forces us to keep a lot of our activity behind closed doors. But we thrive to do as much as possible in the open, with projects like MIG, Mozdef, Cipherscan, OpenVPN-Netfilter, Duo-Unix or Audisp-Json.

    Opening up security discussions to the community, and to the public, has been a goal for some time, and today we are making a step forward with the OpSec mailing list at

    https://lists.mozilla.org/listinfo/opsec

    This mailing list is a public place for discussing general security matters among operational teams, such as public vulnerabilities, security news, best practices discussions and tools. We hope that people from inside and outside of Mozilla will join the discussions, and help us keep Mozilla secure.

    So join in, and post some cool stuff!

    Categorieën: Mozilla-nl planet

    Mike Shal: Moving Automation Steps in Tree

    wo, 23/07/2014 - 02:00
    In bug 978211, we're looking to move the logic for the automation build steps from buildbot into mozilla-central. Essentially, we're going to convert this: Into this:
    Categorieën: Mozilla-nl planet

    Pagina's