Nicholas Nethercote: Poor battery life on the Flame device? |
The new Firefox OS reference phone is called the Flame. I have one that I’m using as my day-to-day phone, and as soon as I got it I found that the battery life was terrible — I use my phone very lightly, but the battery was draining in only 24 hours or so.
It turns out this was because a kernel daemon called ksmd (kernel samepage merging daemon) was constantly running and using about 3–7% of CPU. I detected this by running the following command which prints CPU usage stats for all running processes every five seconds.
adb shell top -m 5
ksmd doesn’t seem very useful for a device such as the Flame, and Alexandre Lissy kindly built me a new kernel with it disabled, which improved my battery life by at least 3x. Details are in the relevant bug.
It seems that plenty of other Flame users are not having problems with ksmd, but if your Flame’s battery life is poor it would be worth checking if this is the cause.
https://blog.mozilla.org/nnethercote/2014/07/15/poor-battery-life-on-the-flame-device/
|
Amy Tsay: The AMO Reviewer Community Turns 10 |
A decade ago, Firefox introduced the world to a customizable web browser. For the first time, you could use add-ons to personalize your entire browsing experience—from the look and feel of buttons, to tab behaviors, to content filtering. Anyone with coding skills could create an add-on and submit it to addons.mozilla.org (AMO) for others to use. The idea that you could experience the web on your own terms was a powerful one, and today, add-ons have been downloaded close to 4 billion times.
Each add-on listed on AMO is thoroughly reviewed to ensure its privacy and safety, and volunteer reviewers have shouldered much of this effort. To properly inspect an add-on, a reviewer has to dig into the code—a taxing and often thankless chore. Nobody notices when an add-on works as expected, but everybody notices when an add-on with a security flaw gets through. These reviewers are truly unsung heroes.
From the beginning, volunteers recognized the importance of reviewing add-ons, and self-organized on wiki pages. As add-ons grew in popularity, it became necessary to hire a few people out of this community to keep it organized and nurtured. Ten years later, volunteers are still responsible for about half of all add-on reviews (about 150 per week). Our top volunteer reviewer is approaching 9,000 reviews.
As a community manager working with volunteer reviewers, I’m sometimes asked what the secret is behind this enduring and resilient community. The secret is there isn’t just one thing. Anyone who’s ever tried giving away free food and booze as their primary community-building strategy has learned how quickly the law of diminishing returns kicks in.
What’s In It For Me?
To understand why people get involved with reviewing add-ons, and why they stay involved, you only have to understand human nature. Altruism tells just part of the story. People are often surprised when I tell them that many reviewers began volunteering for selfish reasons. They are add-on developers themselves, and wanted their add-ons to be reviewed faster.
Some of these developers authored add-ons that are used by tens of thousands, sometimes millions of people, so it’s important to be able to push out updates quickly. Since reviewers are not allowed to review their own add-ons, the only way to speed things up is to help burn down the queue. (Reviewers can also request expedited reviews of their add-ons.) Also, they can learn how other people make add-ons, which in turn helps them improve their own.
Intrinsic Motivation
People who create add-ons are people who write code, so the code itself can be interesting and intrinsically motivating. In Drive: The Surprising Truth About What Motivates Us, Daniel Pink writes that self-motivated work tends to be creative, challenging, and non-routine, and add-on reviewing has it all: every piece of code is different (creative), security flaws can be cleverly concealed (challenging), and reviewers contribute at their own pace (non-routine).
Not Just Carrots and Sticks
A few years ago, we began awarding points for add-on reviews and introduced a leaderboard that lets reviewers see their progress against other reviewers. The points could also be redeemed for swag as part of an incentive program.
While this is admittedly a carrot-and-stick approach to engaging contributors, it serves a larger purpose. By devoting time and resources to sending handwritten notes and small tokens, we are also sending the message that reviewers are important and appreciated. When you open your mailbox and there’s a Fedex package containing a special-edition t-shirt in your size, you know your efforts haven’t gone unnoticed.
Community and Responsibility
AMO reviewers know that they play an important role in keeping Firefox extensible, and that their work directly impacts the experience people have installing add-ons. Since about half of the hundreds of millions of Firefox users have add-ons installed, that is no small feat. I’ve heard from reviewers that they stick around because they like being part of a community of awesome people who are responsible for keeping add-ons safe to use in Firefox.
The Magic Formula
Online communities are complex, their fabric woven from a mesh of intrinsic and extrinsic, selfish and altruistic motivations. A healthy, lasting community benefits from a combination of these factors, in varying proportions, some of them driven by the community and some by the attentive community-builders tasked with nurturing it. There isn’t a silver bullet; rather, it’s about finding your own magic formula and knowing that often, the secret ingredient is whatever it is that makes us human.
Happy 10th birthday, AMO reviewers.
|
Mark C^ot'e: BMO mid-2014 update |
Here’s your mid-year report from the offices, basements, and caverns of BMO!
This year we’re spending a lot of time on performance. As nearly everyone knows, Bugzilla’s an old Perl app from the early days of the Web, written way before all the technologies, processes, and standards of today were even dreamt of. Furthermore, Bugzilla (including BMO) has a very flexible extension framework, which makes broad optimizations difficult, since extensions can modify data at many points during the loading and transforming of data. Finally, Bugzilla has evolved a very fine-grained security system, crucial to an open organization like Mozilla that still has to have a few secrets, at least temporarily (for security and legal reasons, largely). This means lots of security checks when loading or modifying a bug—and, tangentially, it makes the business logic behind the UI pretty complex under the hood.
That said, we’ve made some really good progress, starting with retrofitting Bugzilla to use memcached, and then instrumenting the database and templating code to give of reams of data to analyze. Glob has lots of details in his post on BMO perf work; read it if you’re interested in the challenges of optimizing a legacy web app. The tl;dr is that BMO is faster than last year; our best progress has been on the server side of show_bug (the standard Bug view), which, for authenticated users, is about 15% faster on average than last year, with far fewer spikes.
Part of an effort to improve developer productivity, in June we rolled out a feature to give a new way for users to track changes to bugs. BMO now notes when you visit a bug you’re involved in (when you load it in the main Bugzilla UI or otherwise perform actions on it), and any changes to that bug which occur since you last visited it will show up in a table in My Dashboard. Read more.
Another improvement to developer productivity centred around notifications is the new bugmail filtering feature. Bugzilla sends out quite a lot of mail, and the controls for deciding when you want to receive a notification of a change to a bug have been pretty coarse-grained. This new feature is extremely customizable, so you can get only the notifications you really care about.
There have been several broad posts about this recently, but it’s worth repeating. The original Bugzilla REST API, known as BzAPI, is deprecated in favor of the new native REST API (on BMO at least; it isn’t yet available in any released version of the Bugzilla product). If possible, sites currently using BzAPI should be modified to use the new API (they are largely, but not entirely, compatible), but at a minimum they should be updated to use the new BzAPI compatibility layer, which is hosted directly on BMO and sits atop the new REST API. The compatibility layer should act almost exactly the same as BzAPI (the exceptions being that a few extra fields are returned in a small number of calls). At some point in the not-too-distant future, we’ll be (transparently) redirecting all requests to BzAPI to this layer and shutting down the BzAPI server, so it’s better to try to migrate now while the original BzAPI is still around, in case there are any lingering bugs in the compatibility layer.
As usual, you can see our current goals and high-priority items for the quarter on the BMO wiki page.
|
Doug Belshaw: Web Literacy 'maker' badges |
{cross-posted from the Webmaker blog)
To help with Maker Party (launching tomorrow!) we’ve been working on a series of Web Literacy ‘maker’ badges. These will be issued to those who can make digital artefacts related to one or more competencies on the Web Literacy Map.
The structure of each of the Webmaker resources page for each competency (e.g. Navigation) is:
We’re not currently badging the ‘Discover’ level, and the ‘Teach’ level is currently covered by the Webmaker Mentor badge. These new ‘Make’ badges are our first badges specifically for web literacy.
We’re planning to launch these badges at the end of July. Before we do so, we want to make sure the process works smoothly for everyone, for each badge. We’re also very much interested in your feedback on the whole process.
Here’s what to do. Go to the link below and follow the instructions. You’ll need to either make something related to one of the Web Literacy Map competencies, or link to something you’ve made before.
https://teach.etherpad.mozilla.org/weblit-make-badges-QA
Questions? Comments? I’m @dajbelshaw or you can email me at doug@mozillafoundation.org
|
Mark Surman: The Instagram Effect: can we make app making easy? |
Do you remember how hard digital photography used to be? I do. When my first son was born, I was still shooting film, scanning things in and manually creating web pages to show off a few choice pictures. By the time my second son was walking I had my first good digital camera. Things were better, but I still had to drag pictures onto a hard drive, bring them into Photoshop, painstakingly process them and then upload to Flickr. And then, seemingly overnight, we took a leap. Phones got good cameras. Photo processing right on the camera got dead simple. And Instagram happened. We rarely think about it, but: digital photography went from hard and expensive to cheap and ubiquitous in a very short period of time.
I want to make the same thing happen with mobile apps. Today: making a mobile app — or a complex interactive web page — is slow, hard and only for the brave and talented few. I want to make making a mobile app as easy as posting to Instagram.
At Mozilla, we’ve been talking about this for while now. At Mobile World Congress 2013 we floated the idea of making easy to make apps. And we’ve been prototyping a tool for making mobile apps in a desktop browser since last fall. We’ve built some momentum, but we have yet to solve two key problems: crafting a vision of app making that’s valuable to everyday people and making app making easy on a phone.
We came one step closer to solving these problems last week win London. In partnership with the GSMA, we organized a design workshop that asked: What if anyone could make a mobile app? What would this unlock for people? And, more interestingly, what kind of opportunity and imagination would is create in places where large numbers (billions) of people are coming online for the first time using affordable smartphones? These are the right questions to be asking if we want to create an Instagram Effect for apps.
The London design workshop created some interesting case studies of why and how people would create and remix their own apps on their phones. A DJ in Rio who wanted to gain fans and distribute her music. A dabbawalla in Mumbai who wants to grow and manage the list of customers he delivers food to. A teacher in Durban who wants to use her Google doc full on student records to recruit parents to combat truancy. All of these case studies pointed to problems that non-technical people could more easily solve for themselves if they could easily make their own mobile apps.
Over the next few months, Mozilla will start building on-device authoring for mobile phones and interactive web pages. The case studies we developed in London — and others we’ll be pulling together over the coming weeks — will go a long way towards helping us figure out what features and app templates to build first. As we get to some first prototypes, we’re going get the Mozilla community around the world to test out our thinking via Maker Parties and other events.
At the same time, we’re going to be working on a broader piece of research on the role of locally generated content in creating opportunity for people in places whee smartphones are just starting to take at off. At the London workshop, we dug into this question with people from organizations like Equity Bank, Telefonica, USAID, EcoNet Wireless, Caribou Digital, Orange, Dalberg, Vodaphone. Working with GSMA, we plan to research this local content question and field test easy app making with partners like these over next six months. I’ll post more soon about this partnership.
http://commonspace.wordpress.com/2014/07/14/the-instagram-effect-making-app-making-easy/
|
David Burns: WebDriver F2F - London 2014 |
Last week saw the latest face to face of the WebDriver Working Group held at Facebook. This meeting was important as this is hopefully the last face to face before we go to Last call allowing us to concentrate on issues that come up during last call.
This meeting was really useful as we were a number of discussions around the prose of the spec when it comes to conformance and usability of the spec, especially when given to implementors who have never worked on WebDriver.
The Agenda from the meeting can be found here
The notable items that were discussed are:
To read what was discussed you can see the notes for Monday and Tuesday.
http://www.theautomatedtester.co.uk/blog/2014/webdriver-f2f---london-2014.html
|
Mozilla Reps Community: Rep Of The Month : June 2014 – Shreyas Narayanan Kutty |
Shreyas Narayanan Kutty came to Reps as an already inspirational leader and role model in the Firefox Student Ambassadors program. In addition to organizing a number of successful MozCafes, Shreyas has led a charge to empower kids on the web through the Webmaker initiative ‘Kidzilla’ and a longer-term call to action in schools to start Webmaker Clubs.
Shreyas has inspired others in his community and across the world with blog posts and photos and a teaching kit which have been featured in Mozilla publications.
In addition to his FSA and Reps contribution, Shreyas has been a key participant in Hive India and most recently, Mozcamp Beta, where his Popcorn video ‘I am Mozillian’, featuring 19 different states of India stole the show.
https://blog.mozilla.org/mozillareps/2014/07/14/rotm-june-2014-shreyas/
|
David Burns: Bugsy 0.3.0 - Comments! |
I have just released the latest version of Bugsy. This allows you to get comments from Bugzilla and add new comments too. This API is still experimental so please send back some feedback since I may change it to real world usage.
I have updated the documentation to get you started.
>>> comments = bug.get_comments() >>> comment[0].text "I <3 Cheese" >>> bug.add_comment("And I love bacon")
You can see the Changelog for more details.
Please raise issues on GitHub
http://www.theautomatedtester.co.uk/blog/2014/bugsy-0.3.0-comments.html
|
Leo McArdle: Letter to my MP on DRIP |
What follows is a copy of the email I just sent to my MP about the Data Retention and Investigatory Powers Bill (DRIP). I urge you to send a similar email right now.
Dear Robin Walker,
I have no doubt that by now you will have heard of the Data Retention and Investigatory Powers Bill (DRIP) which your Government and the Opposition will try to rail-road through Parliament next week. I also have no doubt that you will have heard of the great deal of criticism surrounding this bill, both from your colleagues within Westminster hailing from all parties, such as David Davis MP and Tom Watson MP, and those outside of Westminster, such as Jim Killock of the Open Rights Group.
In April the European Court of Justice (ECJ) ruled that the Data Retention Directive (DRD) was incompatible with the Charter of Fundamental Rights of the European Union and therefore that the 2006 act enabling the DRD in the UK was a breach of Human Rights. This means what was, and still is, the status quo when it comes to forcing companies to store data on their customers is a breach of fundamental Human Rights. This is the same status quo which the Home Secretary has said that DRIP merely retains. I think it is clear to see why I, and others, have such a problem with DRIP.
The ECJ ruling outlined some very clear ways in which the DRD could be made compatible with Human Rights law, by saying that this cannot be done on a blanket basis and that someone independent must supervise police access. These fundamental points are missing from DRIP.
Furthermore, DRIP goes far further than just retaining the status quo. It makes sweeping amendments to the Regulation of Investigatory Powers Act (RIPA) including the expansion of what a communications service provider is, the extension of these powers to outside the UK and an open door to allow the Government to make new regulations about data retention at will, without the need to debate them fully in Parliament. I am sure you agree that such huge amendments to RIPA need to be subject to full Parliamentary scrutiny.
It is perfectly clear to everybody, including you, I am sure, Mr Walker, that the Government is using the ECJ ruling as a pretext to force through, at great speed, legislation which affects Human Rights, without proper scrutiny or deliberation. The ECJ ruling was in April, and many warned as far back as 2006 that the DRD was flawed. The UK Government has had years to prepare for the DRD being struck down. There is no reason for this emergency legislation, other than to try and sneak sweeping changes under the noses of MPs who have been allowed to go on holiday.
Wherever you stand on where the balance should be between State Security and Civil Liberties (and I would not be surprised if we stand on opposite ends of that balance), you must agree that five days in nowhere near enough time to properly debate and represent all the views on this issue.
It is for this reason that I urge you as my elected representative to vote against DRIP, and do everything you can to urge your colleagues to do the same. At the very least, could you please push for a highly amended bill, with all the sections amending RIPA removed, which serves purely as a stopgap, not for a period of two years, but for a maximum of six months. We need to have this debate now, and not pass the buck on to the next Government in 2016, who will surely pass the buck on again.
In 2015 I will get my first opportunity to vote in a General Election, and while I may feel that this Government has done devastating things to this country, you, Mr Walker, may be able to differentiate yourself from a sea of blue if you stand up for Civil Liberties and Human Rights.
Yours sincerely,
Leo McArdle
|
Nick Cameron: Rust for C++ programmers - part 8: destructuring |
fn foo(pair: (int, int)) {
let (x, y) = pair;
// we can now use x and y anywhere in foo
match pair {
(x, y) => {
// x and y can only be used in this scope
}
}
}
fn foo((x, y): (int, int)) {
}
struct St {
f1: int,
f2: f32
}
enum En {
Var1,
Var2,
Var3(int),
Var4(int, St, int)
}
fn foo(x: &En) {
match x {
&Var1 => println!("first variant"),
&Var3(5) => println!("third variant with number 5"),
&Var3(x) => println!("third variant with number {} (not 5)", x),
&Var4(3, St{ f1: 3, f2: x }, 45) => {
println!("destructuring an embedded struct, found {} in f2", x)
}
&Var4(_, x, _) => {
println!("Some other Var4 with {} in f1 and {} in f2", x.f1, x.f2)
}
_ => println!("other (Var2)")
}
}
fn foo(x: En) {
match x {
Var1 => println!("first variant"),
Var2 => println!("second variant"),
Var3(..) => println!("third variant"),
Var4(..) => println!("fourth variant")
}
}
struct Big {
field1: int,
field2: int,
field3: int,
field4: int,
field5: int,
field6: int,
field7: int,
field8: int,
field9: int,
}
fn foo(b: Big) {
let Big { field6: x, field3: y, ..} = b;
println!("pulled out {} and {}", x, y);
}
fn foo(b: Big) {
let Big { field6, field3, ..} = b;
println!("pulled out {} and {}", field3, field6);
}
struct Foo {
field: &'static int
}
fn foo(x: Foo) {
let Foo { field: &y } = x;
}
fn foo(b: Big) {
let Big { field3: ref x, ref field6, ..} = b;
println!("pulled out {} and {}", *x, *field6);
}
http://featherweightmusings.blogspot.com/2014/07/rust-for-c-programmers-part-8.html
|
Anthony Ricaud: Adopting Omnifocus and GTD |
I've tried to adopt the Getting Things Done method a few times already. Every time, it wasn't a success. I wasn't applying most principles and fell back to noting things down on a collection of small papers. This time, I had a huge advantage: at work, I'm sitting next to 'Etienne, a big proponent of GTD. He inspired me to try again and answered a lot of questions I had during my adoption.
This time, I chose Omnifocus for my GTD experimentation. It's a bit expensive to buy the three flavours but I was committed. I'll be talking about my experiences via Omnifocus but you should not focus too much on the software. You can adopt GTD with paper, with another software, whatever works for you.
In january, I started the capture part. That's when you note down in your GTD system everything you'd like to do. You need to create that habit and do it every time something pops in your head. I use three main methods to collect:
http://ricaud.me/blog/post/2014/06/Adopting-Omnifocus-and-GTD
|
Nigel Babu: Jinxed! |
A couple of weeks ago, I requested L3 access as part of my Sheriffing work and my request was granted. I think I’ve totally jinxed things since then ;)
The first Sunday afterward, we had a patch that was landed into aurora inadvertently causing massive spike in crashes. I saw it myself and suspect that my copy was corrupt and downloaded the latest! Of course, to no avail. I finally noticed the right bug and Kairo was looking for someone to back it out. I backed it out and triggered a rebuild which fixed the issue.
The next Saturday, we had mobile imaging failures. This one was fun fixing, I talked to Nick Thomas and Chris Cooper on the phone. All it needed was one command, but it took us some time to get there :-) But hey, it got me mentioned under Friends of Mozilla.
Having more access to fix things somehow makes me feel responsible!
|
Nigel Babu: Training in Tanzania |
On the last Monday of April, I found myself nervously standing in a room of about 15 people from the e-Government Agency and National Bureau of Statistics in Dar es Salaam. They were waiting for me to start training them in Python and CKAN. I’ve been programming in Python since 2011, but I’ve never actually trained people in Python. On the first day, I didn’t have any slides. All I had was one [PDF][pdf] from Wikibooks which I was using as material. I didn’t even cover the whole material. By the end of the day though, I could sense that it was sinking into the attendees a bit.
It all started with an email from my manager asking me if I was available to do a training in Tanzania in April. After lots of back and forth, we finalized on a date and a trainer to assist in the trainings, and I flew in. Dar es Salaam, strangely, reminded of growing up in Salalah. I got in a day early to prep for the week and settle in. The trainer looking groggy on a Monday does not bode well!
People who train often don’t tell you this - Trainings are exhausting. You’re most likely to be on your feet all day and walk around the room helping people who’re lagging behind. Looking back, the training was both fun and exhausting. I enjoyed talking about Python, though I feel like I need more practice to do it well. The CKAN training, I was pretty satisfied with the outcome, by the end of the week, the folks from e-Gov Agency went in and setup a server with CKAN!
Note to self: Write these posts immediately after the trip before I forget :-)
|
Armen Zambrano: Introducing Http authentication for Mozharness. |
|
Armen Zambrano: Using developer configs for Mozharness |
|
Kent James: The Thunderbird Tree is Green! |
For the first time in a while, the Thunderbird build tree is all green. That means that all platforms are building, and passing all tests:
Many thanks to Joshua Cranmer for all of his hard work to make it so!
|
Hub Figui`ere: Github tracks you by email. |
That's right. Github tracks you by email. Each Github notification email contains in the HTML part a beacon. Beacons are usually one pixel images with a unique URL to know who did view the email or not - triggered by the HTML rendered downloading the image to display.
Two safeguards against that tracking:
Now I complain over twitter and according to Github Zach Holman:
"It’s a pretty rad feature for a ton of our users; reading a notification in one should mark the web UI as read too. We dig it."*.
Sorry, but there is no optout to tracking. Holman also said:
"you can just disable images. It’s the same functionality in the email as on the web, though. We’re not spying on anything."*
and
"[...] It’s just in this case there’s zero additional information trading hands."*.
Note that recent events showed me I couldn't trust Github ethics anyway, so I'd rather have them not have the info that them claiming it never change hands.
This wouldn't be important if Mozilla didn't mostly require Github to contribute to certain projects including. I filed bug 1031899. While I can understand the feature, I believe user privacy should be paramount, therefor not being able to disable tracking is a serious ethics issue.
http://www.figuiere.net/hub/blog/?2014/07/11/850-github-tracks-you-by-email
|
Gervase Markham: Why Do Volunteers Work On Free Software Projects? |
Why do volunteers work on free software projects?
When asked, many claim they do it because they want to produce good software, or want to be personally involved in fixing the bugs that matter to them. But these reasons are usually not the whole story. After all, could you imagine a volunteer staying with a project even if no one ever said a word in appreciation of his work, or listened to him in discussions? Of course not. Clearly, people spend time on free software for reasons beyond just an abstract desire to produce good code. Understanding volunteers’ true motivations will help you arrange things so as to attract and keep them. The desire to produce good software may be among those motivations, along with the challenge and educational value of working on hard problems. But humans also have a built-in desire to work with other humans, and to give and earn respect through cooperative activities. Groups engaged in cooperative activities must evolve norms of behavior such that status is acquired and kept through actions that help the group’s goals.
– Karl Fogel, Producing Open Source Software
http://feedproxy.google.com/~r/HackingForChrist/~3/BT4WRFv36Zc/
|
Joel Maher: I invite you to join me in welcoming 3 new tests to Talos |
2 months ago, we added session restore tests to Talos, today I am pleased to announce 3 new tests:
Stay tuned in the coming weeks as we have 2 others tests in the works:
http://elvis314.wordpress.com/2014/07/11/i-invite-you-to-join-me-in-welcoming-3-new-tests-to-talos/
|
Bogomil Shopov: It’s live: Usersnap’s JavaScript error- and XHR log-recorder. |
I am so happy. Today we released our console recorder (JavaScript errors and XHR logs) and now every web developer can fight bugs like a superhero.
It’s so awesome!
http://talkweb.eu/its-live-usersnaps-javascript-error-and-xhr-log-recorder/
|