I have coded up a framework for simpler processing of Firefox Health Report data.
There is a @FHRMapper decorator that can be applied to the job's map(). When applied, it automagically JSON-decodes the payload into an instance of class. This class exposes some commonly used APIs, such as the ability to easily iterate over all days of data and to easily get at session times, etc. The goal is to have common logic in the class to reduce DRY violations.
The @FHRMapper decorator also exposes commonly-used filtering primitives so jobs don't have to reimplement these over and over. Again, more DRY defense.
Following that large commit are a set of scripts I have written. I have placed these in their own directory. Since jobs only query a single source of data, I think it makes sense to aggregate the jobs by the set of data they interface with.
I have coded up a framework for simpler processing of Firefox Health Report data.
There is a @FHRMapper decorator that can be applied to the job's map(). When applied, it automagically JSON-decodes the payload into an instance of class. This class exposes some commonly used APIs, such as the ability to easily iterate over all days of data and to easily get at session times, etc. The goal is to have common logic in the class to reduce DRY violations.
The @FHRMapper decorator also exposes commonly-used filtering primitives so jobs don't have to reimplement these over and over. Again, more DRY defense.
Following that large commit are a set of scripts I have written. I have placed these in their own directory. Since jobs only query a single source of data, I think it makes sense to aggregate the jobs by the set of data they interface with.