roqua / physiqual Goto Github PK

in
./spec/lib/physiqual/exporters/exporter_spec.rb:11

{"errors":[{"errorType":"invalid_grant","message":"Refresh token invalid:. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}

Currently the fitbit service provides active calories expended, whereas google provides the active + inactive calories (or the other way around). This should be the same for both services. I suggest using active calories only, if that is indeed an option.

We moeten een pagina hebben waar mensen hun persoonlijke data kunnen aanvullen of bijwerken (of ophalen van google+ / fitbit)

• Leeftijd
• Gewicht
• Lengte
• Geslacht

• Email not found
• Service gebruiken die niet bestaat (google / fitbit / iets anders)

Currently Physiqual only supports re-imputing the missing values of an imputed array, but does not offer a way to use the average imputed values of various imputers. This would be much better.

I.e, currently the imputation is sequential (missings from one imputer are imputed using a second imputer). It would be better if this were parallel, where the imputed values are averaged.

Currently Physiqual only supports equidistant measurement intervals. Many researchers however, perform completely randomly scheduled EMA studies. In order to support these studies, we should have a means for the researcher to add a list of measurement moments for each individual participant.

Currently the data where physiqual retrieves its data from is not shown by design. It could, however, be of interest to the researcher to know which datasource the data came from. Add a route / function that returns the list of ID's with the respective token location.

readme schrijven met een mwe, en hoe je het simpel op kunt zetten

in
./spec/shared_examples_for_data_services.rb:74

We could allow users to upload their (for example) roqua data in some sort of pre-specified csv format, and automatically add our own columns to the data set (automatically add the data for each of the participant).

Mailchimp has a pretty fancy CSV import tool, perhaps we could look at that for inspiration.

DEPRECATION WARNING: Passing the use_route option in functional tests are deprecated. Support for this option in the process method (and the related get, head, post, patch, put and delete helpers) will be removed in the next version without replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the process method. Previously the engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the @routes variable in the test case with Foo::Engine.routes. See the updated engines guide for details. (called from process_action at /Users/ando/repos/physiqual/spec/support/engine_controller_patch.rb:29

Currently, all calls to the external services are done sequentially. If a user would have both a fitbit and a google fit account, this can easily result into 8 calls to the two services. It could be much faster if these calls could be done asynchronously, e.g.

Thread.new do
    data[:activities] = data_aggregator.activities(from, to)
end

although using a library for this is preferred (e.g. sidekiq)

Er zijn verschillende use-cases die we moeten afhandelen:

• Een sensor geeft 0, de ander geeft waarden (selecteer de hoogste)
• Beide sensoren geven data (niet 0) (selecteer het gemiddelde)
  • Wat als er heel veel verschil tussen de uitgelezen waarden zit (i.e., 1 sensor heb je om, is min of meer normaal, en de ander geeft vaak 0, maar soms 3 a 4 (je hebt hem niet om maar hij viel van de tafel).

Op dit moment wordt altijd de uitvoer van de exporter getoond. We moeten onderscheid maken tussen de verschillende formats die mee gegeven kunnen worden (e.g. csv, json, html)

Op dit moment wordt heartrate nog as-is van de api gereturned. Implementeer histrogram sampling om de meestvoorkomende heartrate te samplen van een persoon. Het histogram zoals we besproken hebben is niet een traditioneel histogram, maar een soort soft histogram implementatie, waarbij niet alleen de frequentie in de huidige bucket wordt berekend, maar ook de n omliggende buckets worden verhoogd. I.e., als n = 2, en er wordt een hartslag van 70 gemeten, dan wordt bucket 70 verhoogd, maar ook bucket 68, 69, 71 en 72.

We zouden nog een weight hieraan kunnen toevoegen, i.e.,

1 - (x-i) / n

waarbij x het geselecteerde bucket is (70), en i een van de omliggende buckets.

Implement gemnasium toolbox

    # TODO: MOET NOG!
    def failure
      redirect_to new_session_url,
                  flash: { error: 'Sorry, there was something wrong with your login attempt. Please try again.' }
    end

Is this ever called? Do we need to do anything different in this case?

Currently physiqual only offers support for protocols where the measurements are a given distance apart. We could also introduce either:

• Random measurement moments, where the scheduling moments are given using a json file (for example)
• Non equidistance measurement points, that is, one at 10, one at 11, one at 5 and one at 12 (every day the same)

https://github.com/roqua/physiqual/blob/master/lib/physiqual/omniauth/strategies.rb contains hardcoded routes, (/physiqual/auth). These should be generated from the engine's URL

We moeten een pagina hebben waar mensen hun persoonlijke data kunnen aanvullen of bijwerken (of ophalen van google+ / fitbit)

• Leeftijd
• Gewicht
• Lengte
• Geslacht

From csv_exporter_spec.rb

Op dit moment zijn er nog veel hardcoded variabelen die uit de code gehaald moeten worden, en apart gezet moeten worden. Hieronder een lijst:

• use_night: wel of geen nacht gebruiken voor de export
• imputer []: welke imputatie moet er gebruikt worden
• measurements-per-day: het aantal metingen per dag
• interval: de tijd tussen de metingen

For HGI we used the middle measurement of the day. The day this measurement was on was considered the date of the diary study.

It should be possible to retrieve a collection of the data in CSV, JSON or other format. Export functionality needs to be added to the application.

This should be figured out, how does it work to have a decorator pattern where one of the classes also receives some other things during initialization

from summarized_data_service_spec.rb

The caching currently implemented is quite basic and needs some updates. Test whether the current approach works well enough, and implement better caching if it doesn't (cached_data_service.rb)

Currently, when we have a draw in heart-rate peeks (if they are evenly close to the mean), we select the highest of the two. The complete heart-rate selection method will be as follows:

1. Select the peek after applying top-hat smoothing (if #peeks > 1, go to step 2)
2. Select the peek closest to the average of all peeks (if there are multiple 'winner' peeks, go to step 3)
3. Select the average of the two peeks closest two the average.

The reason for selecting the hear-rate using the top-hat kernel methods is because we'd like to know what happened the most often in the past measurement interval. Taking a simple average does not suffice, and taking the mode will yield invalid results if the heart-rates are distributed in a strange way.

Currently there is a small difference between elske's export and ours.

https://developers.google.com/fit/rest/v1/performance

• Also test whether this influences the fitbit behavior.

All others have a .flatten, except for this one.

In order to only allow the use of one token per participant, the following needs to change:

• Change the has_many in Physiqual::User to has_one
• Add a uniqueness constraint to the database for physiqual_user_id in the physiqual_tokens table

Furthermore, we need to remove the code where the data from multiple tokens gets merged and where data is retrieved from multiple sensor provider services.

Currently we have a number of .flattens in the code which perform magic. Check whether the flatten is really needed or if it can be removed for efficiency.

http://human.co/

Currently we have

s.add_dependency 'active_interaction', '~> 2.1.2'

This does not match the latest version, which is 3.0.0. Gemnasium marks this as a yellow alert. Can we simply upgrade to active_interaction 3 or does this cause conflicts?

Make a route to export the collection of user codes in combination with the csrf-key of the token used.

I.e.,
Name, Source
Frank, google
Ando, fitbit

Although we are able to generate a schedule which is not equidistant, it is not possible to use these buckets in the current clustering method. This method should be improved so it only depends on the data provided to it, instead of assuming equidistance.

in
./spec/shared_examples_for_data_services.rb:78

from views/physiqual/exports/index.html.erb

Load the data for the previews using AJAX instead of hardcoding it in the .js file.