(“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.
(“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, 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.
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.