mozilla

by Alessio Placitelli on Mozilla

Extending Glean: build re-usable types for new use-cases

(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. You can find an index of all TWiG posts online.)

The last blog post:This Week in Glean: Cargo features – an investigation by Jan-Erik.

The philosophy of Glean has always been to offer higher-level metric types that map semantically to what developers want to measure: a Timespan metric type, for instance, will require developers to declare the resolution they want the time measured in. It is more than just a number. The build-time generated APIs will then offer a set of operations, start() and stop(), to allow developers to take the measurements without caring about the implementation details or about the consistency of times across platforms. By design, a Timespan will record time consistently and predictably on iOS, Android and even desktop. This also empowers the rest of the Glean ecosystem, especially pipeline and tooling, to know about the quality guarantees of the types, their format and, potentially, ways to aggregate and visualize them.

… →
 
by Alessio Placitelli on Mozilla

GeckoView + Glean = Fenix performance metrics

(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean. The previous post of the series lives here.)

This week in Glean we tell a tale of components, design, performance and ponies (I promise!): how to bridge different telemetry worlds, with different semantics and principles? How can we get the data to answer the question “is Fenix loading pages faster or slower compared to Fennec”?

… →
 
by Alessio Placitelli on Mozilla

Add-on recommendations for Firefox users: a prototype recommender system leveraging existing data sources

By: Alessio Placitelli, Ben Miroglio, Jason Thomas, Shell Escalante and Martin Lopatka.
With special recognition of the development efforts of Roberto Vitillo who kickstarted this project, Mauro Doglio for massive contributions to the code base during his time at Mozilla, Florian Hartmann, who contributed efforts towards prototyping the ensemble linear combiner, Stuart Colville for coordinating integration with AMO. Last, but not least, to Anthony Miyaguchi who helped shaping the current code thanks to his reviewing efforts.

What’s TAAR?
Firefox has a robust ecosystem of add-ons that can enhance the browsing experience, but all users are different and not all add-ons are right for everyone. The TAAR project (Telemetry Aware Addon Recommender) is an experimental product developed over the course of 2017 to provide a personalized experience for Firefox users seeking to install add-ons based on available information already in Mozilla’s telemetry data. Our aim is to provide potentially interesting add-ons or useful replacements to add-ons built on legacy technology, without the need for additional data collection. Add-ons created with the new standard (after legacy) are safer, more secure, and won’t break in new Firefox releases.
Unlike conventional recommender systems, we designed TAAR to provide interesting add-on recommendations based on the Telemetry data Firefox collects in accordance to Mozilla’s Data Privacy Principles and privacy policy. The data contains, among other things, browser performance data and an hardware overview. This information is collected from Firefox desktop and can be disabled if users choose to do so. Retrofitting an existing data source to a new application is no easy task, but we are really happy with TAAR’s functionality in leveraging different information sources based on availability to provide a personalized add-on recommendation list.

… →