Elevate: Elevateアプリへの年次進捗ローリングサムの移行

私はこれを2番目に、フィットネスのトレンドが大好きですが、30日間の移動平均は非常に貴重です！

私はこれだけを言うためにここに来ました！ 30日間の移動平均は、季節の量を比較するための最も有用な機能の1つでした。 また、昨年の距離は、マイルの蓄積に焦点を当てた人々にとって非常に洞察に満ちていました。

可能であれば、過去30日間と昨年の平均距離/時間/標高を追加すると非常に役立ちます。

また、この機会を利用して、トーマスの計り知れないプロジェクトに感謝​​します。

@ashdriver @ DCunnama @ fjavipm私はこのフィードバックを理解しています。 実際、このレガシー機能は他の誰かによってコーディングされていました（プルリクエストと彼のおかげで!!）。 多くのユーザーで多くのバグに遭遇し、レガシーコードで機能を維持することができませんでした。 そのため、古い機能を新しい機能に移動しました（または強制しました...）。

この機能を復活させ、緊急のフラグを立てます。 正直なところ、私は自分の目的のために30日間の移動平均と昨年の平均距離/時間/標高の概念を本当に理解していませんでした。 ですから、多くのユーザー（あなたを除く）がそれを適切に使用することができないだろうと想像することができます。 すべての人が機能にアクセスできる必要があることを覚えています。

では、 30日間の移動平均と昨年の平均距離/時間/標高の背後にある「必要性」、「ユースケース」、「問題の解決」について再説明して

古い機能を復活させたい場合でも、ここから古いビルドをダウンロードできます： https ： ブランチ：マスター、バージョン：6.8.1 ）

こんにちはトーマス、

ご回答、ご説明ありがとうございました。 私自身のニーズとこれの使用法を説明しますが、もしあれば他の人がもっと追加できることを願っています：

必要：
ある年から次の年までの最近のトレーニング負荷と延長されたトレーニング負荷（距離または高度で測定）を比較する方法。

使用事例：
ユーザーは、標高または距離の30日または365日のローリング平均（y軸に表示）、および1月1日から始まるx軸の日付のプロットを表示するように選択できます。毎年、利用可能なデータを異なる色でオーバーレイできます。理想的にはまた、特定の年を選択/選択解除して、それらを直接比較する機能もあります。

問題が解決しました：
これにより、1年の特定の時期の距離と高度で測定されたトレーニングの労力を前年と比較するための合理的に効果的な方法が得られます。 多くの場合、アスリートは毎年ほぼ同じ日に行われる特定の年次イベントのトレーニングを行います。30日（および程度は少ないが365日）の移動平均を簡単に比較できることは、そのようなイベントの準備を比較するための優れた方法です。

オプションの追加機能リクエスト：30日はかなり良い固定値だと思いますが、30日から365日の間/以下の移動平均ウィンドウを調整する機能も役立つ場合があります。 ウィンドウサイズを調整すると、毎年30日より長い（または短い）トレーニングブロックを比較するのに役立ちます。たとえば、マラソントレーニングプログラムは3か月にわたって設定されることがよくあります。

では、 30日間の移動平均と昨年の平均距離/時間/標高の背後にある「必要性」、「ユースケース」、「問題の解決」について再説明して

「過去30日間」は、特にスポーツによるトレーニング量の変化を理解するのに役立ちます。 持久力の長いスポーツでは、ボリュームと強度が成功の鍵です。 HRSSで取得できる強度を別にすると、ボリュームは方程式の最も単純な部分ですが、正しく理解するのが非常に難しいことがよくあります。 たとえば、過去30日間の機能は、ピークイベントの最後の6〜8週間につながるランプレートを取得するのに役立ちます。

ほんの少しの修正-私は30日と365日にわたって「移動平均」について話してきましたが、実際にはウィンドウ全体の累積距離/標高/時間の合計がおそらくより有用であり、この機能が以前に実装された方法です。

また、チャイムを鳴らして、30日と365日のローリング平均が実際にプラグインを使用する最大の理由であるとまで言いたかったので、プラグインを持ち帰ってください:)

有用性の質問に答えるために、移動平均は、ランナーが追跡するのが大好きな「ストリーク」のより合理的な測定値を持つための優れた方法です。 たとえば、私は1年以上（以下に示すように正確には424日）、足の移動平均が少なくとも3000マイルあることを知っています。 これらの計算は別のGoogleスプレッドシートで実行しますが、プラグインに含めるプロットに変換するのは簡単です。

しきい値| 週あたり| 兼。 マイル| 到達日| 何日も| 数ヶ月以上
-| -| -| -| -| -
1000 | 19 | 1006 | 2016/03/29 | 1044 | 34
1500 | 29 | 1516 | 2016/08/19 | 901 | 29
2000 | 38 | 2001 | 2016/10/21 | 838 | 27
2500 | 48 | 2505 | 2017/06/19 | 597 | 19
3000 | 58 | 3005 | 2017/12/09 | 424 | 13

これからはもっとはっきりします...私はそれを捕まえるために私の進行に長い分滞在しました。 私は以前に機能の間違ったvizualizationを持っていました...それは私を助けませんでした...しかし今から、それはロケット科学ではありません:)

だから私はこれらの2つのモードを提供します：

• 現在アプリに存在する「標準累積モード」
• そして「ローリングストリークモード」 =>正しいマーケティング表現のためにあなたの助けが必要です;）

「ローリングストリークモード」には、 1から365までのカスタマイズ可能なローリング日の値があります。 これを固定値に制限する必要がありますか？ 私は1週間、 2週間、 1ヶ月、 3ヶ月、.. 6ヶ月、 1年を意味します。 一部のユーザーは、どの日数が私が推測するのに最適かわからない場合があります。

「ローリングストリークモード」は、距離、時間、高度、カウントなど、すべての進行タイプに適用でき

表（右側）に何を表示できるかまだわかりませんか？ 年の間のローリングデルタ？ ターゲットはどうですか？

もちろん、私がここに書いたものは封印されていません。 あなたはあなたの提案、アイデア、警告を落とすことができます、...;）私はここにいくつかのビルドをリンクします。 したがって、機能をテストすることができます。 私は主にこれに取り組んでいきますが、他の機能は保留状態です。

Thomasに感謝します。また、これがプラグインの私のお気に入りの部分の1つであることに同意します。 個人的にはデフォルトで1ヶ月だと思いますが、ユーザーが手動で設定できるといいですね。

1か月と1年を頻繁に切り替えて、1年ごとの負荷を簡単に比較し、トレーニングがどのように行われているかを確認しました。主に、ランニング中のマラソンなど、トレーニング量が実際に多いイベントの場合です。疲労感などがよく見えます。

乾杯！

固定値は、1週間、2週間、1か月、3か月、6か月、1年の範囲に適していると思います。
たぶん2ヶ月も追加しますか？

テーブルの値と概要については、既存の進行テーブルと同じに保つと思います。つまり、ご提案のとおり、前年度と当年度のデルタです。

「ローリングストリークモード」は、私にとってはまともな名前のように思えます。少なくとも、これ以上のことは考えられません。

このプロジェクトにご尽力いただいた時間と専門知識に改めて感謝いたします。大変感謝しております。

• そして「ローリングストリークモード」 =>正しいマーケティング表現のためにあなたの助けが必要です;）

ストリークはランナーに固有の何かを意味し、それは連続した連日であるため、元の投稿では「ストリーク」という単語を引用符で囲んでいます。 一部のランナーはNDO（休日なし）を信じており、ストリークは休憩なしでどれだけ長く行けるかを示しています。 その意味で、それを「ローリングストリークモード」と呼ぶのは混乱を招くかもしれません。 「ローリング累積モード」や「ウィンドウ累積モード」のように、累積が行われる時間枠を意味するものを提案します。

「ローリングストリークモード」には、 1から365までのカスタマイズ可能なローリング日の値があります。 これを固定値に制限する必要がありますか？ 私は1週間、 2週間、 1ヶ月、 3ヶ月、.. 6ヶ月、 1年を意味します。 一部のユーザーは、どの日数が私が推測するのに最適かわからない場合があります。

単位（日、月、年）と数値のオプションを提供することをお勧めします。 たとえば、ランニングは長いゲームなので、2年間のローリング累積が欲しいです。 さらに、後者は前者のより「スムーズな」バージョンであるため、たとえば30日と1年など、2〜3の異なるパラメーターを重ね合わせるオプションを提供すると便利です。 もちろん、y軸が意味をなすためには、合計が大幅に異なるため、合計ではなく平均値をプロットする必要があります。 平均は、多くのランナーが追跡する1週間あたりの基準で表示できます。 したがって、私の表では、3000mi /年以上は58 /週に相当します。 したがって、30日と1年を重ねてプロットすると、58マイル/週の目標からどれだけ逸脱しているかがわかります。

「ローリングストリークモード」は、距離、時間、高度、カウントなど、すべての進行タイプに適用でき

いいですね、それは理にかなっています。

表（右側）に何を表示できるかまだわかりませんか？ 年の間のローリングデルタ？ ターゲットはどうですか？

上記の表にはこれを含めませんでしたが、あなたが言うように、次のしきい値またはデルタに到達するのにかかる時間も追跡します。 これは怪我/バーンアウトのレシピであるため、しきい値からしきい値への移動が速すぎないようにする必要があります。 ここで提供できるのは、しきい値を合計（1000、2000、3000miなど）または1週間（10、20、30miなど）でユーザー設定可能にしてから、何日または何ヶ月かを表示することです。毎日増加するものであるしきい値を超えています。

私はスレッドを監視し、この素晴らしい機能を再導入することをいとわないことに改めて感謝します！

• 現在アプリに存在する「標準累積モード」

また、標準モードで、年次オプションだけでなく月次オプションを追加することをお勧めします。 多くのランナーが毎年同じレースでレースをしているので、それが理にかなっている場合は、2019年1月の累積と2018年の累積がどのように積み重なっているかを比較するために、月ごとに「リセット」を行うとよいでしょう。 この時点では、これはすべてフィーチャークリープです:)ですから、以前の機能を元に戻せば幸いです:)

実際、単純な「ローリングサム」はどうですか？ 標準モードは、 「YTD Sum」 （

それで2日前に開発を始めました。

私は現時点でそれを使用しました：

export enum ProgressionMode {
    STANDARD_CUMULATIVE,
    ROLLING_CUMULATIVE
}

@mathin 「 RollingSum 」と「 YearToDate Sum」は、実にはるかに単純なようです。 これらをオンにする場合があります。 他の人はどう思いますか？

ここにいくつかの結果があります!! :)私はTDDを介して主流のロジックをコーディングし終えました。 そして、UIでいくつかのバイパスを行った後、次のような結果が得られます。

「30日ローリングサム」

「3か月のローリングサム」 ：

「1年間のローリングサム」 ：

関連する「年初来の合計」 ：

そして、 「30日間のローリングサム」と比較するためのレガシー「最後の30d距離

それは完璧に見えます、何かをとても早く実装することに取り掛かってくれてありがとう！

ここでユニットテストを使用して現在の動作を検証できます： https ：

そしてここでの方法： https ：

ここにいくつかの結果があります!! :)私はTDDを介して主流のロジックをコーディングし終えました。 そして、UIでいくつかのバイパスを行った後、次のような結果が得られます。

それは絶対に素晴らしいです！ どうもありがとうございました。新しい指標の使用を開始するのが待ちきれません。

1つの小さな質問/コメント。 従来の「最後の30d距離」と新しい「30日間のローリングサム」を（もちろん視覚的にのみ）比較すると、「ローリングサム」はより「ギザギザ」であるか、逆に従来の「最後の30d」よりも「ギザギザ」であるように見えます。もう少しスムーズに見えます。 これは単なるプロット関数のアーティファクトですか、それともレガシーコードで行われている追加のデータ平滑化がありますか？

再度、感謝します！！！

@mathinこれは私が使用しているd3curveLinearモードです： https ：

_curveNatural_を使用すると、次のようになります。

再び@mathin 。 あなたの要求について：

さらに、後者は前者のより「スムーズな」バージョンであるため、たとえば30日と1年など、2〜3の異なるパラメーターを重ね合わせるオプションを提供すると便利です。 もちろん、y軸が意味をなすためには、合計が大幅に異なるため、合計ではなく平均値をプロットする必要があります。 平均は、多くのランナーが追跡する1週間あたりの基準で表示できます。

それを「速く」行うのははるかに難しいようです。後で行われる新しい問題で追跡するかもしれません。

したがって、私の表では、3000mi /年以上は58 /週に相当します。 したがって、30日と1年を重ねてプロットすると、58マイル/週の目標からどれだけ逸脱しているかがわかります。

あなたは私を失った:)

いくつかのUIの更新と「6週間の標高ローリングサム」 ：

これはとても素敵で有望に見えます！
私は、30日/ 1か月で4週間、3か月で13週間のローリングサムを好みます。
ほとんどの人は通常、同じ曜日に運動します。
週のリズムを使用すると、日曜日の各旅行が日曜日のX-backの旅行に置き換わるため、ラインが非常にスムーズになり、ぐらつきが大幅に少なくなります。

私は、30日/ 1か月で4週間、3か月で13週間のローリングサムを好みます。
ほとんどの人は通常、同じ曜日に運動します。

それはとても素晴らしい点です。30日ではなく4週間のローリングサムも見たいです。 そしてところで、私はあなたが13ではなく12週間を書くつもりだったと思いますよね？

@ bkleingoldewijk @ mathin必要な期間を選択できます。 必要な数を掛けるだけです。

優秀な！

ボブ

私のiPhoneから送信された

Op 122月。 2019オム18時57 heeftトーマス・シャンパン< [email protected] [email protected] > HET volgende geschreven：

@bkleingoldewijk https://github.com/bkleingoldewijk @mathinhttps ：//github.com/mathin必要な期間を選択できます。 必要な数だけ倍数。

[画像] https://user-images.githubusercontent.com/151973/52657012-f395ee80-2ef7-11e9-81c4-5b43b4792c70.png

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/thomaschampagne/elevate/issues/760#issuecomment-462865891で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AtN0S2opo7- OK64kFII6bAM1C2Dc1tzRks5vMwCMgaJpZM4ako11 。

私は30日と365日のローリングの大ファンでもあります。 しかし、私は週に同じサイクリングパターンを持っている傾向があるので、4週間と52週間のローリングがより有益であることも2番目になります。 どうもありがとう。

色とコントラストに問題があります。 現在、私のグラフの2019は、非常に暗い背景に対して非常に暗い色を使用しています。 色の選択にはもっと注意する必要があります。または、パレットから選択するためのオプションがあります。

@jfhaugh 「ローリング」パレットはここで定義されています： https ：

あなたは私にあなたのリストを与えることができます;）？

（ライトテーマでも機能するはずです）

役立つかもしれません： https ：

これは、 Rolling＆Year todateの

v6.9.2_stable_2019-02-23-14-06.zip

注：新しい同期を回避するには、「公式」昇格のバックアップを使用して、そのビルドに復元できます。

もちろん、あなたの助けは大歓迎です：

• 一般的なケースやねじれたケースのバグを見つける
• 機能の理解を深めるためのアイデア/テキストを提供してください（特に、ほとんどのユーザーにとって確かに複雑なローリングプログレッション）。 「あなたはこれを書くべきボタンの下：」例えば、「ツールチップホバー*と表示* *を追加します」...
• ヘルパーダイアログの内容を教えてください（（？）ボタンをクリックすると表示されます）
• 私の英語を修正してください:)

あなたの助けとテストをありがとう:)

しばらくの間、ローリングメトリックを待っていました—素敵な@thomaschampagne

年の進行タブ

• 「年」の選択については、さらに良いでしょう。
  
  
  
  • すべて選択
  
  
  • すべての選択を解除
  
  
  • 選択を反転
  
  
  • 過去5年間（例）
    
    （注：私のデータベースは2003年にさかのぼりますが、過去にさかのぼるとデータはますますまばらになります。グラフに多くの注意散漫が生じます。また、ほぼ20年にわたってチェックボックスを選択または選択解除するのも面倒です）
  
  

• ローリング期間は、このソフトウェアの最も優れた機能の1つです。 お尻を蹴る。
  
  
  
  • カスタマイズ可能なスライディングタイムウィンドウは完璧でしょう
  
  
  • または、4週間または30日を含める
  
  

良い仕事を続けてください！

テキストの改善と英語をご覧いただければ、機能ヘルパーを更新しました

編集して投稿できるソースファイル： https ：

@thomaschampagneこの驚くべき新機能をリリースしてくれてありがとう！

報告すべき小さな問題があります。 先日、ローリング間隔を1日に設定してグラフを見ました。 私はウルトラガイではないので、30mi +の値がかなり奇妙に見えたのを見て驚いた。 私はマラソン（レース当日のみ）を超えて走ることはなく、レース前のウォームアップ（最大1マイル）を含めても、1日で最大27〜28マイルを超えることはなく、30マイルを超えることもありません。 さらに調べてみると、30マイルの日は22マイルのロングランを走ったときに発生し、前日は8マイルのイージーランを合計30マイル走ったときに発生したことがわかりました。

これにより、ローリング間隔が1時間ごとに実装される可能性があることに気付きました。 つまり、おそらく22miと8miの実行は、互いに24時間以内に発生したため（ただし、異なる日に）、同じ1日のローリング間隔でカウントされた可能性があります。 日数/週数などに関しては、すべてのローリング間隔に同じ原則が適用されているようです。これは実装する「正しい」機能のように聞こえますが、実際にはローリング間隔の「量子化」の方がおそらく使いやすいでしょう。

1つの提案は、深夜の間隔を量子化して、2日の間隔が、日内でローリングするのではなく、深夜から深夜までカウントされるようにすることです。 それが理にかなっていることを願っています。

改めて感謝いたします。ご意見、ご不明な点がございましたら、お気軽にお問い合わせください。

@mathinあなたはおそらく正しい。 それは日付から来る可能性があります。 この潜在的なバグの新しいチケットを作成できますか？ そして、問題が発生する可能性のある高架バックアップ+アクティビティID /日付をリンクしてください。

@mathinあなたはおそらく正しい。 それは日付から来る可能性があります。 この潜在的なバグの新しいチケットを作成できますか？ そして、問題が発生する可能性のある高架バックアップ+アクティビティID /日付をリンクしてください。

こんにちは@thomaschampagne 。 私はあなたが尋ねたことをしますが、方法がわかりません（バックアップ+ ID /日付など）。 すばらしい機能を修正する時間があれば、それはあなたのペットプロジェクトであると理解しているので、修正することは期待していません。 素晴らしい機能をありがとう！