Mozilla Nederland LogoDe Nederlandse

Mozilla Reps Community: Council at Whistler Work Week

Mozilla planet - wo, 22/07/2015 - 17:15

From the 23rd to 26th of June the Reps Council attended the Mozilla Work Week in Whistler, British Columbia, Canada to discuss the future plans with the rest of the Participation team. Unfortunately Bob Reyes couldn’t attend due to delays in the Visa process.

Human centered design workshop

At the beginning of the week Emma introduced us to “Human centered design” where the overall goal is to find solutions to a problem while keeping the individual in the focus. We split up in groups of two to do the exercises. We tried to come up with individual solutions for the problem statement “How might we improve the gift giving experience?”.

At first we interviewed our partner to get to the root of the problem they currently have with gift giving. This might either be that they don’t have ideas on what to give to a person, or maybe the person doesn’t want to get a gift, or something entirely different. All in all, we came up with a lot of different root causes to analyze.

After talking intensively to the partner, we came up with individual solution proposals which we then discussed with the partner and improved based on their feedback.

We think this was a valuable workshop for the following sessions with the functional area teams.

Sessions with other functional areas

With this knowledge Council members, as part of the Participation team, attended more than 27 meetings with other functional teams from all across Mozilla. The goal was to invite these teams to a session, where we analyze their issues they have with Participation.

During these meetings we provided feedback to the team’s plans for bringing more participation and enabling more community members into their projects. We also received a lot of insights on what functional teams think about the community and how valuable is the work of volunteer to them. In every session the goal was to come up with a solid problem statement and then find possible solutions for it. Due to the Council being volunteers each of us could give valuable input and ideas.

Some problem statements we tackled during the week (of course this is just a selection):

  • How might we increase the Code contribution retention so people come back to us after doing a code contribution?
  • How might community approach organizations who already touch the “socially involved” audience to infiltrate their systems so Shape of the Web can touch people so that it can have a lasting impact?
  • How might we improve the SUMO retention ratio from 10% to 30% in the next 6 months?
  • How might we deliver operational capability to run suggested titles in German speaking countries by the end of the year?

Our plans (along with the Participation team) are to continue working with most of these teams and the community in order to accomplish our common plans for bringing more participation into these functional areas.

Council meetings & Leadership workshop

During the week we also held council meetings where we prioritised tasks and worked on the most important ones. Mentor’s selection criteria 2.0, new budget SOPs, Reps recognition and Reps selection criteria for important events are some of these tasks. After completing these important tasks we would like to focus on Reps as leadership platform and set our goals for the next (at least) one year.

On that direction, Rosana Ardila run a highly interesting workshop on Friday around volunteer leadership and the current Organisation model within Mozilla. In three hours we tried to think outside the box and come up with solutions to make volunteer leadership more effective. We haven’t started any plans to incorporate this with the community, but in the coming weeks we will look at this and figure out which parts might work for community as well.

Radical Participation session

On Wednesday evening, a lot of volunteers and staff come together for the “Radical Participation” session. Mozilla invited several external experts on Participation to give a lightning talk to inspire us.

After these lightning talks we evaluated what resonated with us the most for our job and for Mozilla in general. It was good to get an outside view and tips so we can move forward with our plans as best prepared as we can be.

At the end, Mark and Mitchell gave us an update on what they think about Radical Participation. We think we’re on a good way planning for impact, but there is still a lot to do!

Participation Planning

This was one of the most interesting sessions we had since we used a new and innovative post-it notes (more post-it notes!) method for framing the current status of Participation in Mozilla. Identifying in detail the current status and the structure of Participation, was the most important step towards having more impact within the project.

By re-ordering and evaluating the notes we managed to make statements on what we could change and come with a plan for the following months. We looked at an 18-month timeline. George Roter is currently in charge of getting the document which describes the 18-month plan in more detail finished. Stay tuned for this!

Unofficial meetings with other teams

During the social parts of the Work Week (arrival apero and dinners), we all had a chance to talk to other teams informally and discuss our pain points for projects we’re working on outside of Council. We had a lot of talks with different teams outside our Participation sessions, therefore we could move forward with several other, non-Reps related, projects as well. To give an example: Michael met Patrick Finch on Monday of the work week to discuss the Community Tile for the German-speaking community. Due to several talks during the week, the Community Tile went online around a week after the work week.


All in all it was crucial to sit together and work on future plans. We could get a good understand of what the Participation team has been working on and could share what we have been working on as a Council. We could set the next steps for future work. After a hard working Work Week we are all ready to tackle the next steps for Participation. Let’s help Mozilla move forward with Participation! You can find other blog posts from the Participation Team below.

More blog posts about the Work Week from the Participation Team

Participation at Whistler
Storify – Recap Participation at Whistler

Categorieën: Mozilla-nl planet

Armen Zambrano: Few mozci releases + reduced memory usage

Mozilla planet - wo, 22/07/2015 - 16:21
While I was away adusca released few releases of mozci.

From the latest release I want to highlight that we're replacing the standard json library for ijson since it solves some memory leak issues we were facing for pulse_actions (bug 1186232).

This was important to fix since our Heroku instance for pulse_actions has an upper limit of 1GB of RAM.

Here are the release notes and the highlights of them:

  • 0.9.0 - Re-factored and cleaned-up part of the modules to help external consumers
  • 0.10.0:
    • --existing-only flag prevents triggering builds that are needed to trigger test jobs
    • Support for pulse_actions functionality
  • 0.10.1 - Fixed KeyError when querying for the request_id
  • 0.11.0 - Added support for using ijson to load information, which decreases our memory usage

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Mozilla plans to change how Firefox ships in 2015 - gHacks Tech News - Ghacks Technology News

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

Mozilla plans to change how Firefox ships in 2015 - gHacks Tech News
Ghacks Technology News
There has been one major change in past years in regards to how the Firefox web browser is developed and shipped to its users. Mozilla changed to a rapid release cycle in 2011 and has been using the model ever since. While the organization does not ...

Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting

Mozilla planet - wo, 22/07/2015 - 16:00

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

Categorieën: Mozilla-nl planet

Botond Ballo: It’s official: the Concepts TS has been voted for publication!

Mozilla planet - wo, 22/07/2015 - 16:00

I mentioned in an earlier post that the C++ Concepts Technical Specification will come up for its final publication vote during a committee-wide teleconference on July 20.

That teleconference has taken place, and the outcome was to unanimously vote the TS for publication!

With this vote having passed, the final draft of the TS will be sent to the ISO head offices, which will complete the publication process within a couple of months.

With the TS published, the committee will be on the lookout for feedback from implementers and users, to see how the proposed design weathers real-world codebases and compiler architectures. This will allow the committee to determine whether any design changes need to be made before merging the contents of the TS into the C++ International Standard, thus making the feature all official (and hard to change the design of).

GCC has a substantially complete implementation of the Concepts TS in a branch; if you’re interested in concepts, I encourage you to try it out!

Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting

Mozilla planet - wo, 22/07/2015 - 16:00

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

Categorieën: Mozilla-nl planet

The Servo Blog: Servo developer tools overview

Mozilla planet - wo, 22/07/2015 - 14:00

Servo is a new web browser engine. It is one of the largest Rust-based projects, but the total Rust code is still dwarfed by the size of the code provided in native C and C++ libraries. This post is an overview of how we have structured our development environment in order to integrate the Cargo build system, with its “many small and distributed dependencies” model with our needs to provide many additional features not often found in smaller Rust-only projects.


Mach is a python driver program that provides a frontend to Servo’s development environment that both reduces the number of steps required and integrates our various tools into a single frontend harness. Similar to its purpose in the Firefox build, we use it to centralize and simplify the number of commands that a developer has to perform.

mach bootstrap

The steps that mach will handle before issuing a normal cargo build command are:

  • Downloading the correct versions of the cargo and rustc tools. Servo uses many unstable features in Rust, most problematically those that change pretty frequently. We also test the edges of feature compatibility and so are the first ones to notice many changes that did not at first seem as if they would break anyone. Further, we build a custom version of the tools that additionally supports cross-compilation targeting Android (and ARM in the near future). A random local install of the Rust toolchain is pretty unlikely to work with Servo.

  • Updating git submodules. Some of Servo’s dependencies cannot be downloaded as Cargo dependencies because they need to be directly referenced in the build process, and Cargo adds a hash that makes it difficult to locate those files. For such code, we add them as submodules.

mach build & run

The build itself also verifies that the user has explicitly requested either a dev or release build — the Servo dev build is debuggable but quite slow, and it’s not clear which build should be the default.

Additionally, there’s the question of which cargo build to run. Servo has three different “toplevel” Cargo.toml files.

  • components/servo/Cargo.toml is used to build an executable binary named servo and is used on Linux and OSX. There are also horrible linker hacks in place that will cause an Android-targeted build to instead produce a file named servo that is actually an APK file that can be loaded onto Android devices.

  • ports/gonk/Cargo.toml produces a binary that can run on the Firefox OS Boot2Gecko mobile platform.

  • ports/cef/Cargo.toml produces a shared library that can be loaded within the Chromium Embedding Framework to provide a hostable web rendering engine.

The presence of these three different toplevel binaries and the curious directory structure means that mach also provides a run command that will execute the correct binary with any provided arguments.

mach test

Servo has several testing tools that can be executed via mach.

  • mach tidy will verify that there are no trivial syntactic errors in source files. It checks for valid license headers in each file, no tab characters, no trailing whitespaces, etc.

  • mach test-ref will run the Servo-specific reference tests. These tests render a pair of web pages that implement the same final layout using different CSS features to images. If the images are not pixel-identically, the test fails.

  • mach test-wpt runs the cross-browser W3C Web Platform Tests, which primarily test DOM features.

  • mach test-css runs the cross-browser CSS WG reference tests, which are a version of the reference tests that are intended to work across many browsers.

  • mach test-unit runs the Rust unit tests embedded in Servo crates. We do not have many of these, except for basic tests of per-crate functionality, as we rely on the WPT and CSS tests for most of our coverage. Philosophically, we prefer to write and upstream a cross-browser test where one does not exist instead of writing a Servo-specific test.


While the code that we have written for Servo is primarily in Rust, we estimate that at least 2/3 of the code that will run inside of Servo will be written in C/C++, even when we ship. From the SpiderMonkey JavaScript engine to the Skia and Azure/Moz2D graphics pipeline to WebRTC, media extensions, and proprietary video codecs, there is a huge portion of the browser that is integrated and wrapped into Servo, rather than rewritten. For each of these projects, we have a crate that has a file that performs the custom build steps to produce a static library and then produce a Rust rlib file to link into Servo.

The rest of Servo is a significant amount of code (~150k lines of Rust; ~250k if you include autogenerated DOM bindings), but follows the standard conventions of Cargo and Rust as far as producing crates. For the many crates within the Servo repo, we simply have a Cargo.toml file next to a that defines the module structure. When we break them out into a separate GitHub repository, though, we follow the convention of a toplevel Cargo.toml file with a src directory that holds all of the Rust code.

Servo's dependency graph

Updating dependencies

Since there are three toplevel Cargo.toml files, there are correspondingly three Cargo.lock files. This configuration makes the already challenging updates of dependencies even moreso. We have added a command, mach update-cargo -p {package} --precise {version} to handle updates across all three of the lockfiles. While running this command without any arguments does attempt to upgrade all dependencies to the highest SemVer-compatible versions, in practice that operation is unlikely to work, due to a mixture of:

  • git-only dependencies, which do not have a version number

  • Dependencies with different version constraints on a common dependency, resulting in two copies of a library and conflicting types

  • Hidden Rust compiler version dependencies

Things we’d like to fix in the future

It would be great if there was a single Cargo.toml file and it was at the toplevel of the Servo repo. It’s confusing to people familiar with Rust projects, who go looking for a Cargo.toml file and can’t find them.

Cross-compilation to Android with linker hacks feels a bit awkward. We’d like to clean that up, remove the submodule that performs that linker hackery, and have a more clean/consistent feel to our cross-targeted builds.

Managing the dependencies — particularly if there is a cross-repo update like a Rust upgrade — is both a real pain and requires network access in order to clone the dependency that you would like to edit. The proposed cargo clone command would be a huge help here.

Categorieën: Mozilla-nl planet

Nick Fitzgerald: Proposal For Encoding Source-Level Environment Information Within Source Maps

Mozilla planet - wo, 22/07/2015 - 09:00

A month ago, I wrote about how source maps are an insufficient debugging format for the web. I tried to avoid too much gloom and doom, and focus on the positive aspect. We can extend the source map format with the environment information needed to provide a rich, source-level debugging experience for languages targeting JavaScript. We can do this while maintaining backwards compatibility.

Today, I'm happy to share that I have a draft proposal and a reference implementation for encoding source-level environment information within source maps. It's backwards compatible, compact, and future extensible. It enables JavaScript debuggers to rematerialize source-level scopes and bindings, and locate any given binding's value, even if that binding does not exist in the compiled JavaScript.

I look forward to the future of debugging languages that target JavaScript.

Interested in getting involved? Join the discussion.

Categorieën: Mozilla-nl planet

Taiwan remains R&D base for Firefox OS, says Mozilla - Digitimes

Nieuws verzameld via Google - wo, 22/07/2015 - 08:30

The Star Online

Taiwan remains R&D base for Firefox OS, says Mozilla
Mozilla on July 21 indicated that its team in Taiwan continues to play an important role for R&D of Firefox OS. Mozilla COO and Taiwan general manager Gong Li has resigned and set up a new company, recruiting about 30 engineers from the Firefox OS R&D ...
H5OS, an alternative to Android's OS, expected for 2016The Star Online

alle 2 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla:值得期待的FirefoxOS_Mozilla FireFox_cnBeta.COM - cnBeta

Nieuws verzameld via Google - wo, 22/07/2015 - 05:54


Mozilla:值得期待的FirefoxOS_Mozilla FireFox_cnBeta.COM
火狐移动操作系统Firefox OS是Mozilla移动端战略的重要组成部分,除此之外还有Firefox移动版和其他举措。Mozilla相信,建立一个开放的独立平台,替代现有厂商的封闭专有平台,对于未来健康的移动生态系统是至关重要的 ...
Mozilla揭示Firefox OS发展蓝图_IT新闻_博客园博客园 (博客)
Mozilla揭示Firefox OS发展蓝图- 集微网:老杳微信号laoyaoshow集微网
Mozilla公布Firefox OS发展蓝图,未来每6个月释出新版本- 我爱研发网 ...我爱研发网

alle 5 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Jordan Lund: Mozharness now lives in Gecko

Mozilla planet - wo, 22/07/2015 - 01:28
What's changed?

continuous-integration and release jobs that use Mozharness will now get Mozharness from the Gecko repo that the job is running against.


Whether the job is a build (requires a full gecko checkout) or a test (only requires a Firefox/Fennec/Thunderbird/B2G binary), automation will first grab a copy of Mozharness from the gecko tree, even before checking out the rest of the tree. Effectively minimizing changes to our current infra.

This is thanks to a new relengapi endpoint, Archiver, and's sub directory archiving abilities. Essentially Archiver will get a tar ball of Mozharness from within a target gecko repo, rev, and sub-repo-directory and upload it to Amazon's S3.

What's nice about Achiver is that it is not restricted to just grabbing Mozharness. You could, for example, put in the Gecko tree or, improving on our model, simply grab subdirectories from within the testing/* part of the tree and request them on a suite by suite basis.

What does this mean for you?

it depends. if you are...

1) developing on Mozharness

You will need to checkout gecko and patches will now land like any other gecko patch: 1) land on a development tree-branch (e.g. mozilla-inbound) 2) ride the trains. This now means:

  • we can have tree specific configs and even scripts
  • the Mozharness pinning abstraction layer is no longer needed
  • we have more deterministic builds and tests as the jobs are tied to a specific Gecko repo + rev
  • there is more transparency on how automation runs continuous integration jobs
  • there should be considerably less strain on as we no longer rm + clone mozharness jobs
  • development tree-branches (inbound, fx-team, etc) will behave like the Mozharness default branch while mozilla-central will act as production branch.

This also means:

  • Mozharness patches that require tree wide changes will need to be uplifted across trees
  • development on Mozharness will require a Gecko tree checkout
  • Github + Travis tests will not be run on each Mozharness change (mh tests will have to be run locally for now)
  • Mozharness changes will not be documented or visible (outside of diffing gecko revs)

2) just needing to deploy Mozharness or get a copy of it without gecko

Like the usage docs linked to Archiver above, you could hit the API directly. But I recommend using the client that buildbot uses. The client will wait until the api call is complete, download the archive from a response location, and unpack it to a specified destination.

Let's take a look at that in action: say you want to download and unpack a copy of mozharness based on mozilla-beta at 93c0c5e4ec30 to some destination.

python mozharness --repo releases/mozilla-beta --rev 93c0c5e4ec30 --destination /home/jlund/downloads/mozharness

Note: if that was the first time Archiver was polled for that repo + rev, it might take a few seconds as it has to download Mozharness from hgmo and then upload it to S3. Subsequent calls will happen near instantly

Note 2: if your --destination path already exists with a copy of Mozharness or something else, the client won't rm that path, it will merge (just like unpacking a tarball behaves)

3) a Release Engineering service that is still using

Not all Mozharness scripts are used for continuous integration / release jobs. There are a number of Releng services that are based on Mozharness: e.g. Bumper, vcs-sync, and merge_day. As these services transition to using Archiver, they will continue to use hgmo/build/mozharness as the Repository of Record (RoR).

If certain services that can not use gecko based Mozharness, then we can fork Mozharness and setup a separate repo. That will of course mean such services won't receive upstream changes from the gecko copy so we should avoid this if possible.

If you are an owner or major contributor to any of these releng services, we should meet and talk about such a transition. Archiver and its client should make deployments pretty painless in most cases.

Have something that may benefit from Archiver?

If you want to move something into a larger repository or be able to pull something out of such a repository for lightweight deployments, feel free to chat to me about Archiver and Relengapi.

As always, please leave your questions, comments, and concerns below

Categorieën: Mozilla-nl planet

QMO: Help us Triage Firefox Bugs – Introducing the Bug Triage tool

Mozilla planet - wo, 22/07/2015 - 01:09

Interested in helping with some Firefox Bug Triage?  We have a new experimental tool that makes it really easy to help on a daily basis.

Please visit our new triage tool and sign up to triage some bugs. If you can give us a few minutes of your day, you can help Mozilla move faster!

Categorieën: Mozilla-nl planet

Air Mozilla: July Privacy Lab - Crypto Wars with guest speakers from CDT and EFF

Mozilla planet - wo, 22/07/2015 - 01:00

July Privacy Lab - Crypto Wars with guest speakers from CDT and EFF July's Privacy Lab will include guest speakers from CDT and EFF to talk about backdoors and crypto wars.

Categorieën: Mozilla-nl planet

Air Mozilla: July Privacy Lab - Crypto Wars with guest speakers from CDT and EFF

Mozilla planet - wo, 22/07/2015 - 01:00

July Privacy Lab - Crypto Wars with guest speakers from CDT and EFF July's Privacy Lab will include guest speakers from CDT and EFF to talk about backdoors and crypto wars.

Categorieën: Mozilla-nl planet

Firefox 42: Mozilla verbessert Suche auf about:home und about:newtab -

Nieuws verzameld via Google - di, 21/07/2015 - 23:44

Firefox 42: Mozilla verbessert Suche auf about:home und about:newtab
Die Suche im Web dürfte mit zu den häufigsten Aufgaben gehören, welche von Benutzern im Browser durchgeführt werden. Nicht grundlos setzt Mozilla in den letzten Monaten einen starken Fokus auf die Suche in und mit Firefox. Mit Firefox 42 bringt Mozilla ...

Categorieën: Mozilla-nl planet

Ben Hearsum: Mozilla Software Release GPG Key Transition

Mozilla planet - di, 21/07/2015 - 20:45

Late last week we discovered the expiration of the GPG key that we use to sign Firefox, Fennec, and Thunderbird nightly builds and releases. We had been aware that this was coming up, but we unfortunately missed our deadline to renew it. This caused failures in many of our automated nightly builds, so it was quickly noticed and acted upon.

Our new GPG key is as follows, and available on keyservers such as and

pub 4096R/0x61B7B526D98F0353 2015-07-17 Key fingerprint = 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353 uid Mozilla Software Releases sub 4096R/0x1C69C4E55E9905DB 2015-07-17 [expires: 2017-07-16]

The new primary key is signed by many Mozillians, the old master key, as well as our OpSec team's GPG key. Nightlies and releases will now be signed with the subkey (0x1C69C4E55E9905DB), and a new one will be generated from the same primary key before this one expires. This means that you can validate Firefox releases with the primary public key in perpetuity.

We are investigating a few options to make sure key renewal happens without delay in the future.

Categorieën: Mozilla-nl planet

Mozilla IT & Operations: Troubleshooting the Internet

Mozilla planet - di, 21/07/2015 - 17:36

If you’re working from home, a coffee shop or even an office and are experiencing “issues with the Internet” this blogpost might be useful to you.
We’re going to go through some basic troubleshooting and tips to help solve your problem. At worse gather data so your support team can investigate.

Something to keep in mind while reading is that everything is packets. When downloading a webpage, image, email or video-conferencing, you have to imagine your computer splitting everything into tiny numbered packets and sending them to their destination through pipes, where they will be reassembled in order.
Network issues are those little packets not getting properly from A to Z, because of pipes full, bugs, overloaded computers, external perturbations and a LOT more possible reasons.

Easy tests

We can start by running some easy online tests, even if not 100% accurate, you can run them in a few clicks from your browser (or even phone) and can point toward the right direction.

Speedtest is a good example. Hit the big button and wait, don’t run any download or bandwidth heavy applications. The best is to know what a “normal” value is, so you can compare both.

As some sneaky providers can prioritize connections to the famous Speedtest, you can try another less known website like Start the download of a large file and check how fast it goes.

Note that the connection is shared between all the connected users. So one can easily monopolize the bandwidth and clog the pipe for everyone else. This is less likely to happen in our offices where we try to have pipes large enough for everyone, but can happen in public places. In this case there is nothing much you can do.

Next is a GREAT one: Netalyzr. You will need Java but it’s worth it (first time I have ever said that). There is also an Android app but it’s better to run it from the device experiencing the issue (but it’s also interesting to see how good your mobile/data “Internet” really is). Netalyzr will runs TONS of tests, DNS, blocked ports, latency, etc… And give you a report quite easy to understand or share with a helpdesk. See Mozilla’s Paris office.

Screenshot of Netalyzr resultSome ISPs start to roll out a new version of the Internet, called IPv6 (finally!). As it’s “new” for them, there can be some issues. To check that, run the test on Test-ipv6.

Basic connectivity

If the previous tests show that something is wrong or you still have a doubt, these tools are made to test basic connectivity to the Internet as well as checking the path and basic health of each network segments from you to a distant server.

“ping” will send probes each second to a target and will reports how much time it takes (round trip) to reach it. For an indication, a basic time between Europe and the US west coast is about ~160ms, US east to US west coast ~90ms, Taipei to Europe ~300ms. If it is higher than that you might indeed see some “laggish/slow Internet”.

Screenshot of pings to Wikipedia“traceroute” is a bit different; it does the same but shows you the intermediate hops in between source and destination.

The best in this domain is called “mtr” and is a great combination of the previous 2: for each hop, it runs a continuous ping. Add –report so you can easily copy and paste the result if you need to share it. Having some higher latency or packet loss for a hop or two is usually not an issue. This is because network devices are not made to reply to those tests, they just do it if they are not too busy with their main function, redirecting a packet in a direction or another. A good issue indicator is if many nodes (and especially your target) start showing packet loss or higher latency.

Screenshot of an mtr to www.mozilla.orgIf the numbers are high on the first hop this means something is wrong between your computer and your home/office/bar’s Internet gateway.

If the issues appear “around the middle” it’s an issue with your ISP or your ISP’s ISP and the only thing you can do is to call their support to complain or change ISP when possible. That is what happened with Netflix in the US.

If the numbers are high near the really end it’s probably an issue with the service you’re testing, try to contact them.


An easy one when possible. If you are on wireless try to switch to a wired network and re run the tests mentioned above. It might be surprising but wireless isn’t magic :)

Most of the home and small shops wifi routers (labeled “BGN” or 2.4Ghz) can only use 1 out of 3 frequencies/channels to talk to their clients, and clients have to wait for their turn to talk.
So imagine your neighbor’s wifi is on the same frequency. Even if your wifi distinguishes your packets from your neighbor’s, they will have to share the channel. If you have more than 2 neighbors (Wireless networks visible in the wifi list), you will have an non optimal wireless experience and this is exponential.

To solve/mitigate it you can use an app like “Wifi Analyzer” on Android. X are the frequencies, only 1, 6 and 11 are really usable as they don’t overlap. and Y is how noisy they are. Locate yours, then if a channel is less busy go in your wireless router’s settings and move to that one.

Screenshot of wifi analyserIf they are all busy, last option is to buy a router that supports more recent standard, labeled “ABGN” (even now “AC”) or 5Ghz. Most high end phones and laptop support it as well. That range has around 20 usable channels instead of 3.

Another common issue in public places is when some people can’t connect at all but other people don’t have any issue. This is usually due to a mechanism called DHCP that allocates an address (here you can see it as a slot) to your device. Default settings are made for small networks and remember slots for a long time even if they are not used anymore. It’s usually possible to reduce the “remember” time and/or enlarge the pool of slots in the router’s settings.


These are less complicated to troubleshot. You can start by unplugging everything else connected to your router and see if it’s better. If not the issue might come from that box. Also be careful not to create physical loops in your network (like plugging 2 cables between your router and a switch).

Categorieën: Mozilla-nl planet

Air Mozilla: Martes mozilleros

Mozilla planet - di, 21/07/2015 - 17:00

Martes mozilleros Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos.

Categorieën: Mozilla-nl planet

Air Mozilla: Martes mozilleros

Mozilla planet - di, 21/07/2015 - 17:00

Martes mozilleros Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos.

Categorieën: Mozilla-nl planet

About:Community: Hacking Tech Evangelism in Bangalore: Q & A With Kaustav Das Modak

Mozilla planet - di, 21/07/2015 - 16:38

Back in May, we completed the pilot run of a new program. Mozilla Tech Speakers is designed to empower and support technical evangelists around the world who are serving their communities as speakers and trainers, presenting Mozilla and open web technologies at conferences, workshops, and events. We’ve already posted about the first phase of the program and shared examples of talks and activities from our first cohort of participants.

Not long after that post went up, I learned that Mozilla Rep and Mozillian Tech Speaker Kaustav Das Modak was organizing a Tech Evangelism Workshop with a group of volunteers from Mozilla India’s Bangalore community. Their goal: Work together over a weekend to build confidence and communication skills for technical evangelism. Have each participant finish the weekend with a new presentation and accompanying blog post or article ready to go. The reported results were impressive.

Photo by Kaustav Das Modak

Photo by Kaustav Das Modak

I invited Kaustav to share his activity and its outcome with more Mozillians, who might want to replicate a version of this event in their own communities. The basics apply for all presenters, so you don’t have to be a technologist to find value. Here’s what I learned from Kaustav (in Q & A format):

1) Kaustav, tell us a little about who you are and the work you do as a Mozilla contributor and technical evangelist.

I’m currently working on my start-up, Applait, where we are building a unified layer for real-time communications over the internet.

I’ve been publicly involved with Mozilla a little over 2 years now. Meeting people all over the world and working on open technologies has been my motivation to volunteer with Mozilla.

I’ve always enjoyed sharing what I know with everyone else, since my childhood. My inspiration to pursue technical evangelism as a profession, and then as a passion, came from attending a workshop on technical evangelism conducted by Christian Heilmann, Robert Nyman and Ali Spivak in Bangalore in 2013.

Photo by Kaustav Das Modak.

Photo by Kaustav Das Modak.

I was involved with the Mobilizers team during the Firefox OS launch, and I try to coordinate community evangelism for Mozilla in India, whenever I can.

2) What inspired you to create this event?

I’ve been planning over a year to conduct workshops to help fellow Mozillians get more confident in presenting themselves. I have helped folks individually all along. But, the Tech Speakers pilot programme finally made me get over the lethargy and actually the start the event. I plan to make this into a series, generating a ton of useful content in the process.

3) Can you share your thinking about the agenda and how you designed it?

The core goal of the Tech Evangelism Workshop is to help participants get better at what they are already good at. Participants are asked to choose a topic in which they think they have sufficient knowledge. Then, through the rest of the workshop, they practice building content around that topic – they give 2 presentations, write a talk abstract and an article.

By the end of the workshop, they realize that they already had the capability within them. The true success of this workshop is to make participants realize that all they needed was to do quality research, better practice and letting go of the shyness within.

4) What advice would you offer for other Mozillians who would like to organize a training/workshop like this to prepare presentations and practice public speaking? Do you have specific advice for technical presenters?

One thing that has always helped is to do your homework. _Nothing_ beats a healthy research. Research your audience and respect cultural differences.

5) What are you planning next? What advice do you have for other Mozillians who want to organize a workshop focused on technical evangelism skills?

I’m already planning for a second run of this workshop. I’m also eager to help any Mozillian who needs help individually. It’s okay to ping me anytime on IRC, my nick is kaustavdm.

Categorieën: Mozilla-nl planet