Mac OS X has a nice command-line utility called powermetrics that can perform a range of power-related measurements. Does anybody know if the source code is available for it? I’ve looked on Apple’s Open Source site but couldn’t find it. (In contrast, I did find the source code for top, which has some much simpler power measurements.)

I’d also love to see source code for the Activity Monitor, but given that it’s a graphical application rather than a command-line application, it seems less likely it will be available.

https://blog.mozilla.org/nnethercote/2015/08/06/source-code-for-powermetrics/

At Mozilla Weekend Berlin Andr'e talks about the current state of Firefox OS and where it will be going in the future. This includes very...

https://air.mozilla.org/andre-fiedler-firefox-os-current-state-and-the-future/

I am excited to announce that we're now shipping WiFi debugging for Firefox for Android! It's available in Firefox for Android 42 with Firefox Nightly on desktop.

The rest of this post will sound quite similar to the previous announcement for Firefox OS support.

WiFi debugging allows WebIDE to connect to Firefox for Android via your local WiFi network instead of a USB cable.

The connection experience is generally more straightforward (especially after connecting to a device the first time) than with USB and also more convenient to use since you're no longer tied down by a cable.

Security

A large portion of this project has gone towards making the debugging connection secure, so that you can use it safely on shared network, such as an office or coffee shop.

We use TLS for encryption and authentication. The computer and device both create self-signed certificates. When you connect, a QR code is scanned to verify that the certificates can be trusted. During the connection process, you can choose to remember this information and connect immediately in the future if desired.

How to Use

You'll need to assemble the following bits and bobs:

• Firefox 42
• Firefox for Android 42
• Barcode Scanner Android app by ZXing Team (for QR code scanning)

On your Android device:

1. Install the Barcode Scanner Android app by ZXing Team
2. Open Firefox for Android
3. Go to Developer Tools Settings on device (Settings -> Developer Tools)
4. Enable Remote Debugging via Wi-Fi

To connect from Firefox Desktop:

1. Open WebIDE in Firefox Nightly (Tools -> Web Developer -> WebIDE)
2. Click "Select Runtime" to open the runtimes panel
3. Your Firefox for Android device should show up in the "WiFi Devices" section
4. A connection prompt will appear on device, choose "Scan" or "Scan and Remember"
5. Scan the QR code displayed in WebIDE

After scanning the QR code, the QR display should disappear and the "device" icon in WebIDE will turn blue for "connected".

You can then access all of your remote browser tabs just as you can today over USB.

Technical Aside

This process does not use ADB at all on the device, so if you find ADB inconvenient while debugging or would rather not install ADB at all, then WiFi debugging is the way to go.

By skipping ADB, we don't have to worry about driver confusion, especially on Windows and Linux.

Supported Devices

This feature should be supported on any Firefox for Android device. So far, I've tested it on the LG G2.

Acknowledgments

Thanks to all who helped via advice and reviews while working on Android support, including (in semi-random order):

• Margaret Leibovic
• Karim Benhmida

And from the larger WiFi debugging effort:

• Brian Warner
• Trevor Perrin
• David Keeler
• Honza Bambas
• Patrick McManus
• Jason Duell
• Panos Astithas
• Jan Keromnes
• Alexandre Poirot
• Paul Rouget
• Paul Theriault

I am probably forgetting others as well, so I apologize if you were omitted.

What's Next

If there are features you'd like to see added, file bugs or contact the team via various channels.

http://convolv.es/blog/2015/08/05/wifi-debug-fennec/

This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

https://air.mozilla.org/quality-team-qa-public-meeting-20150805/

At Mozilla Weekend Berlin Michael Kohler answers the questions "What's new in Firefox?" and "What are the most interesting features that have been implemented in...

https://air.mozilla.org/michael-kohler-whats-new-in-firefox/

At Mozilla Weekend Berlin Michael goes through the manifesto and explains what Mozilla's mission is.

https://air.mozilla.org/michael-kohler-a-quick-introduction-to-mozilla/

Duration: 10 minutes This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order...

https://air.mozilla.org/product-coordination-meeting-20150805/

Watch mconley livehack on Firefox Desktop bugs!

https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-24/

Compare and contrast: a Wall Street Journal article linked directly, and one reached via Google (click the top link in the search results). The former leads to a preview and a paywall (or, at least, a signupwall), the latter does not.

The press are so concerned about the dominance of Google, at least in Europe, that they are making various (also foot-shooting) moves to try and bring in ancillary copyright. So why, I wonder, is the WSJ enhancing that dominance by privileging Google users over other users in terms of access to their content?

http://feedproxy.google.com/~r/HackingForChrist/~3/muflnRrnRQI/

People like dichotomies and they will do everything to have their story fits the imaginary gap.

There was a strong debate the last couple of days created by an article posted by Peter Paul Koch on Web innovations and where to drive them. I have not yet made completely my mind about it. I will probably never do.

Bruce Lawson has published a kind of answer about this article. An excerpt:

But the point here is that users do want such things, because they’ve now become used to experiences available in native apps. And we know that consumers love the app experience; in April 2014, the mobile analytics firm Flurry reported

And to further his point, he cited a report from April 2014:

Apps continued to cement their lead, and commanded 86% of the average US mobile consumer’s time, or 2 hrs and 19 minutes per day. Time spent on the mobile web continued to decline and averaged just 14% of the US mobile consumer’s time, or 22 minutes per day.

A couple of things in this small paragraph.

• average mobile consumer: For this kind of things, we all know that average doesn't mean anything. People working at Opera knows that more than anyone else. Tune the market share song.
• USA: An important market but not the world.

Time spent on mobile and in apps are expressed, but my main question was "yes, but doing what?". What people are actually doing on each of them. Because Bruce likes this source. Let's take another recent article.

Messaging and social apps are clearly the leading apps used by Mobile Addicts. In fact, Mobile Addicts use Messaging apps 6.56 times (an over-index of 556%) more than an average mobile consumer. This validates many of our analyses this year that messaging has become mobile’s killer application.

Note that this excerpt is no better than the one given by Bruce. Let's create my own narrative with fluffy unicorns.

Some people spend a lot of time on messaging and social apps on mobile. And it is perfectly fine. I personally do not want to use a Web browser for accessing my mail or messaging my friend. I do want a Web browser for reading, linking, sharing links.

I'm living in Japan. The train is king. People do mainly three things in the train: reading (a paper book), sleeping and using their mobile device. On this 3rd category, they basically do:

• Checking and messaging on social networks (Line, Facebook, etc.)
• Watching TV programs and movies
• Playing games

These are all time consuming activities. Another phenomenon I see it's what I called "filling the bored time", we fire our mobile and starts an app, the exact same way people are starting their TV at home.

The Web is not endangered by this usage. They can continue to be native. All these games are fad. It's part of their business models. The new game will be replaced by another one. I can still link to articles of the New-York Times—December 8, 1993. I'd rather spend time on making the Web more robust, resilient, profitable and performant than having the Web run after the latest Apptorialist du jour.

"I realized that if everyone had the same information as me, my life would be easier," Mr. Berners-Lee said. New-York Times. December 8, 1993

Otsukare!

http://www.otsukare.info/2015/08/05/native-mobile-wrong-debate

Saying I’m excited about the Participation Team’s goals for the remainder of the year would be an understatement.  And I’m especially excited about the emphasis on community leaders and the development of leadership curriculum that I’m working on. I thought I would write a quick post to provide insight into the work I’m starting this heartbeat, as well as some cool opportunities to get involved.

Goal: Launch the basics of a refreshed leadership program.

Participation at Mozilla has always been an opportunity to ‘learn by doing’, and ‘learning to lead’ is no exception .  Being a part of Mozilla Reps program for a number of years now, it’s been incredible to see the transformation of  people who arrive with ideas, and through the program’s empowerment, transform into leaders.  These are people who’ve had (and continue to have) real impact, not only on Mozilla’s mission, but on their own personal goals for success. That last part is important to the theory I’m working with:  when the personal development goals of a volunteer align with outcomes needed by Mozilla , there is a greater likelihood for sustainable impact; a base for scalable momentum.

So, when do we start being more deliberate about leadership development at Mozilla?  Right now ! Our Heartbeat started this week, and you can follow the leadership tag for Github issues in coming months.  I’m starting on the research phase for a Foundation of Mozilla curriculum will be the first step to connecting motivated, creative and goal-oriented individuals with events that can shape the future for Mozilla.  As part of this, we’ll also be developing a standard for community education curriculum, which includes a centralized way to both find, and plug-in community education opportunities.

Both links (in the previous paragraph) point to Github tasks that can help you follow our progress, find planning documents and get involved.  You’ll see that the curriculum task also links to ‘volunteer’ sub-tasks,should you want to get more involved in  researching, developing curriculum standards, or bringing the Community Education Portal to Mozilla Design standards.  I’m also looking for nominations of  people who you think would be valuable to consult during this research phase – on which skills, attitude and knowledge should be built into this curriculum. You can nominate people here.

‘Arrow’ credit: Daniel Kulinski / Foter / CC BY-NC-SA

http://tiptoes.ca/foundations-of-mozilla/

Sometime last week we enabled a new API on hg.mozilla.org: json-mozbuildinfo. This endpoint will return JSON describing moz.build-derived metadata about the files that changed in a commit.

Example. Docs.

We plan to eventually leverage this API to do cool things like have MozReview automatically file bugs in the appropriate component and assign appropriate reviewers given the set of changed files in a commit.

The API is currently only available on mozilla-central. And, we have very conservative resource limits in place. So large commits may cause it to error out. As such, the API is considered experimental. Also, performance is not as optimal as it could be. You have to start somewhere.

I'd like to thank Guillaume Destuynder (kang) for his help with the security side of things. When I started on this project, I didn't think I'd be writing C code for spawning secure processes, but here we are. In the not so distant future, I'll likely be adding seccomp(2) into the mix, which will make the execution environment as or more secure than the Firefox content process sandbox, depending on how it is implemented. The rabbit holes we find ourselves in to implement proper security...

http://gregoryszorc.com/blog/2015/08/04/moz.build-metadata-on-hg.mozilla.org

I recently completed my yearly performance review. It was a great chance to step back and think about my goals from now to the end of the year.  I’m publishing them here, in case you have ideas that can help, or are working on something similar. Got something helpful I can read? An example or case study of how other orgs are doing these things well? Let’s chat.

What do I do?

Impact: I strengthen how we plan — yearly, quarterly and each Heartbeat.

My goal is: to make MoFo more transparent, focused and collaborative. I want to measure that through: clarity, velocity and happiness.

• Clarity — what’s the plan? what are our goals? what percentage of staff and community know where / how to find them?
• Velocity — how quickly can we ship quality work?
•  Happiness — how engaged is our team? are we a happy pirate ship of productive MoFos? are people freed from administrivia, confusion and baloney, so they can focus on what matters?

My goals for Q3 / Q4

1) Rock 2016 planning 

“How are we putting the Mozilla Learning plan into action?” Work in the open to create more shared ownership with all staff and community. Apply what we learned from last year’s process.

2) Strengthen our quarterly planning 

“What did we learn last quarter? What are our goals for this one?” Iterate our Program Review process to make it more transparent, relevant to more staff and community, and focused on follow-up items.

3) Sharpen the Heartbeat process

“How are we deploying resources for the next two weeks? How do we make that smarter?”  Create ways to measure (and increase) our velocity and happiness.

4) Ship “build.mofo.org”

“How do I do x? Where do I find y?” Expand and improve build.webmaker.org. Create a single planning dashboard,  on-boarding platform, and point of truth for all MoFo. Consolidate build, plan and handbook into one thing.

5) Strengthen our PM muscle

“How do we achieve better results with less work?” Have Product Managers, Program Managers and Project Managers work more closely together. Bring product thinking into everything we do. Learn from MoCo.

Success criteria and testing: for each of these, I’ve listed some potential success criteria below. Meaning: how could we *test* to see whether these things are actually working or not?

rock 2016 planning

Apply what we learned in 2015 to make 2016 planning process better. Specifically:

• More and earlier participation from specific players.
• Broader socialization and ownership from distributed leaders and staff.
• Smarter process for setting and socializing our goals and KPIs.

Success criteria:

• Teams are ready to work / start executing on Jan 1. With Q1 goals that are already well fleshed out.
• Distributed leaders understand and use a shared planning vocabulary. (e.g., goal, KPI, program, key initiative, impact statements, etc.)
• Better integration for our support teams into the overall plan.

Strengthen quarterly planning

The Program Review process has become a big part of how we do emergent planning each quarter. We can improve it by increasing transparency and co-ownership for all staff in that process. Specifically:

• Better follow up on key issues raised in the review. Feels like we get to the finish line, then drop and move on.
• More transparency and participation for all staff. This is key. There’s good stuff in those reviews — we want everyone to know what’s in there, and play a role in it.
• Increased harmony with the board slide process. Apply what we learned in Q1 and Q2 to increase efficiencies.

Success criteria:

•  VPs, Directors and Program Managers report that Program Review is making their work better.
• Program Reviews produce concrete changes to the program’s plan of record.
• Staff feel like they’re well-included.
• People no longer complain about templates.

Ship “build.mofo.org”

Consolidate and expand MoFo’s organizational dashboard.

• Evolve build.webmaker.org into something for the whole org.
• Single point of truth. A single view for all MoFo goals, programs, metrics and plans of record, through a simple interface.
• Package and consolidate a bunch of what we shipped already this year (handbooks, shared roadmaps, etc.) into one thing.

Why? Better on-boarding for MoFo across the board. Less document confusion and chaos. More visibility and longer-term planning. Streamlined workflow and documentation.

Success criteria: a new hire can go there and understand WTF is going on.

sharpen our Heartbeat process

We’ve made great strides here, but we can still sharpen the axe. The role of production work vs. non-production work (e.g., stuff that requires designers and engineers vs. not) is still unclear to many. There’s also a request to strengthen the inputs and outputs between the Heartbeat process and our senior management team.

Success criteria:

• Increased velocity. A better way for us to measure velocty together.
• Happiness metric? We could also consider integrating Scrum.inc’s “happiness metric” here.

Strengthen OUR PM muscle

By that I mean: Program Managers, Product Managers and Project Managers working more closely and sharing tips with each other. It doesn’t make sense for our Program Managers to work in a vacuum — they should work more closely with Product Managers, and with people who don’t necessarily have “project manager” in their job title, but that do a lot of this each heartbeat. We also need to learn more from Program Managers at MoCo. I think this is the next step in the evolution of how we should do Program Management at MoFo.

Success criteria:

• Evidence that we’re translating best practices / success templates across MoFo programs and key intitatives
• Applying at least one insight or best practice from MoCo at MoFo
• MoFo PMs start regularly attending MoCo Program Reviews

http://openmatt.org/2015/08/04/goals/

MozReview will soon be using Bugzilla’s new OAuth-like¹ API keys and auth delegation. This is long overdue, and, in addition to providing security benefits, will eliminate all those confusing session-expired errors (e.g. bug 1178814).

After we deploy the change, all users will need to log back into MozReview’s Review Board² instance. This time, rather than entering your Bugzilla credentials directly into Review Board, when you go to the “Log In” page, you’ll be redirected to BMO. If you don’t have a current BMO session, you’ll have to log into BMO. After you log in, or immediately after being redirected to BMO if you do have a session, you’ll be redirected back to Review Board and logged in. This is because, unlike most third-party apps, MozReview’s Review Board is a trusted app that is tightly integrated to BMO, so you won’t be confronted with the standard “Auth Delegation Request” intermediate page.

This is the first stage of conversion to API keys. For pushing review requests with Mercurial, you will still have to have either your Bugzilla username and password or your cookies in your .hgrc file or enter them on the command line at push time. However, Review Board will no longer store cookies; the username/password or login cookies will only be passed to BMO for verification and then discarded. We’ll be moving to API key usage on the command line in a subsequent patch.

Through API keys, Review Board will only have access to the specific BMO APIs required by MozReview. Those actions are mainly restricted to creating and updating attachments and posting comments; however, it will also need access to the login API until we support API keys on the command line. As noted, this will be used solely for identification, and no login tokens will be stored in MozReview.

Another big benefit of API keys is the elimination of those annoying and confusing expired-session errors. The BMO cookies used by MozReview have a limited lifespan, but API keys are good until explicitly revoked by the user. You can see the API key that is transferred to MozReview, as well as any other API keys you’ve manually or automatically created, in the API Keys tab in your BMO preferences. Revoking the API key won’t automatically log you out of Review Board, but you won’t be able to do any actions that interact with BMO (most actions) unless you log out and back in again (thus generating a new key).

You can follow along progress in bug 993233.

1. No, it’s not exactly OAuth, but it’s based on similar ideas. We haven’t found a good OAuth 2 library for use with BMO, but we’re looking around.

2. A note about names: MozReview generally refers to the full code-review system, which is primarily an hg server and a Review Board installation with extensions that we’ve developed. It also includes BMO, Autoland, Pulse, LDAP, and little things like code-review bots. When we say “Review Board”, we are referring specifically to the web app, which is the primary user interface to MozReview.

https://mrcote.info/blog/2015/08/04/mozreview-auth-changes/

Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on.

https://air.mozilla.org/webdev-extravaganza-august-2015/

Reuni'on bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos.

https://air.mozilla.org/martes-mozilleros-20150804/

Please join us in congratulating Mohamed Hafez for being selected as Mozilla Rep of the Month for July 2015.

Mohamed Hafez is an incredible Rep with great capabilities from Egypt, he has being part of the big Mozilla tour in Egypt to spread the Mozilla love and mission all over his region.
His latest big event was Mozilla Egypt Iftar (Arabic:

https://blog.mozilla.org/mozillareps/2015/08/04/rep-of-the-month-july-2015/

The WebDriver specification is now officially a living standard. Practically this means that all changes are automatically published to http://www.w3.org/TR/webdriver/.

This brings an end to the era of forever outdated (two years in our case!) technical reports. It also helps bridge the disconnect many readers were having when they looked for information on our specification.

This is made possible with the Echidna tool that has recently been developed at the W3C. It integrates with Github and Travis, and lets you trigger the publishing steps when changes land on a specific branch in your source repository.

A possible future enhancement is abandoning the now superfluous master branch in favour of making the autopublishing gh-pages the default. The two-step landing process seems more tuned towards a levelled Editor’s Draft-to-Working Draft model.

Thanks to tripu and Michael[tm] Smith for doing the legwork.

http://sny.no/2015/08/living

I got this neat t-shirt in the mail yesterday. 3scale runs a sort of marketing campaign right now and they give away this shirt to the ones who participate, and they were kind enough to send one to me!

http://daniel.haxx.se/blog/2015/08/04/curl-me-if-you-can/

the following changes have been pushed to bugzilla.mozilla.org:

• [1189075] keyboard shortcut for going into edit mode conflicts with Firefox’s tab groups feature
• [1188339] Increase length of all tokens value for greater security
• [1185856] Tabbing out of the keyword field should not select the first available keyword
• [1189172] remove link to ‘release notes’ from index page, and point ‘help’ to bmo.readthedocs.org
• [1188561] Pre-populate form.fxos.feature fields with GET parameters
• [1189362] Fix memory leak in Bugzilla::Bug->comments
• [1190255] modal UI is used immediately after bug creation when using a non-standard form, even if preferenced off

discuss these changes on mozilla.tools.bmo.

https://globau.wordpress.com/2015/08/04/happy-bmo-push-day-153/