Freecodecamp: ストリークはまだ多くのキャンピングカーにとって不正確です

オープンソースの貢献は初めてですが、私がその仕事に取り掛かっているかどうかを確認したいと思います。

これはまだ多くの不満を持っている問題です。

@QuincyLarson私は

@sorlovsky素晴らしい！ 私たちはあなたの助けに興味があります！ さまざまなエッジケースをカバーする、これに関するいくつかのテストを作成できるかどうかを確認してください。 99.9％の確率で動作しているようですが、動作しない場合があり、その理由はよくわかりません。

これを少し調べたところ、他のアクティビティ（プロジェクトまたはアルゴリズム）ではなく、現在のチャレンジのストリークをカウントしていることが原因である可能性があります。 上記のタイムゾーンである可能性もあります。 この問題を調べて、他に誰も問題がない場合にPRできるかどうかを確認します。

ここで何かが足りない場合は、誰か教えてください。

const daysBetween = 1.5; const daysBetween = 2に更新できます。 次の関数のロジックは常にdaysBetween未満で、daysBetween以下であると言っているためです。 これは、ある日の午前12:00:00から次の午後11:59:59までのカバレッジがあることを意味します。 タイムゾーンロジックもすべて同じままである必要があります。

daysBetweenを2に変更すると、2つのテストが中断することになります。これは修正できますが、最初にテストがどのように機能するかを少し学ぶ必要があります。

別のオプションは、daysBetweenを1.99に設定してすべてのテストに合格することですが、7分12秒でストリークを見逃す可能性があります。

@donofriov頑張ってくださいなぜうまくいかなかったのか理解できませんでした

@donofriovは分析に感謝します、そしてあなたがこれを調べることに興味を持っていると聞いてhttps://github.com/freeCodeCamp/freeCodeCamp/issues/7468 （ユーザーのログイン状態と関係があります）

サポートが必要な場合は、チャットルームにアクセスしてください。

最初にテストがどのように機能するかを少し学ぶ必要があります。

テストは
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

さて、これは通常より少し複雑な構造化です。 あなたが物事を理解する必要があるならば、私は周りにいます。

ハッピーフィックス！

@donofriovはい-daysBetweenを2にバンプし、テストに合格するようにテストを更新します。

可能であれば、テストカバレッジを追加して、これが発生したさまざまなコーナーケースに対処していることを確認できるかどうかを確認してください（ストリークに関連するいくつかの問題があります）。

お手数をおかけしますが、よろしくお願いいたします。 これは何ヶ月もの間大きな問題であり、多くの苦情の原因であるため、これを修正することは非常に大きなものになります:)

問題は、 streakの計算がタイムゾーンに依存していることです。 1つのタイムゾーンで、私の3つの送信が[Aug 5, Aug 6, Aug 7]ます。 別のタイムゾーンでは、それらの同じ送信が[Aug 5, Aug 5, Aug 6]可能性があります。 カレンダーのヒートマップも同様にタイムゾーンに依存しており、ヒートマップは常にブラウザでページを表示しているクライアントのタイムゾーンを使用します。 したがって、 streaksをヒートマップと一致させたい場合は、計算でクライアントのタイムゾーンを使用する必要があります。 これは基本的に、この問題が2016年1月に＃6333で修正されたときに@LenaBarinovaが行ったことです。 解決策は、チャレンジが送信されるたびにブラウザにユーザーのタイムゾーンを送信させることでした。 サーバーはタイムゾーンを保存し、それを使用してストリークを計算します。 しかし、2017年1月に、チャレンジの送信方法を変更する大きなリファクタリングがあり、修正が削除されました。 サーバー側のロジックはまだ存在します。ブラウザがタイムゾーンを送信しなくなっただけです。

@Motardoこれを調査していただきありがとうございます。 @LenaBarinovaの修正が再び

@QuincyLarsonもう一度見て寝た後、私の考えは次のとおりです。

プランA
古い解決策は理想的ではなかったと思います。 自分のプロファイルを正しく表示するには、ユーザーがログインする必要がありましたが、他のタイムゾーンで他のユーザーのプロファイルを表示すると、依然として不整合が表示されます。

プランB （シンプルでわかりやすい、適切な一時的な修正）
よりシンプルで堅牢なソリューションは、ユーザーのプロファイルを表示するためのリクエストをクライアントのタイムゾーンに送信することであり、サーバーはそのタイムゾーンに基づいてストリークを計算できると思います。 その場合、クライアントがログインしているか、プロファイルが表示されているかは関係ありません。 縞とカレンダーは常に同期しています。

プランC （複雑なリファクタリング、将来のロードマップの可能性）
おそらく最善の解決策は、サーバー上のストリークをまったく計算しないことです。 サーバーは生のタイムスタンプをクライアントに送信し、各タイムスタンプが属する日と、ローカルタイムゾーンに基づいたストリークの長さをクライアントに決定させる必要があります。 これは、カレンダーのヒートマップデータで行うこととまったく同じであるため、常に一貫性があります。

私はreactとrxjsにまったく慣れておらず、プランCは私の深みから外れていると思いますが、プランBのパッチを作成したいと思います。また、他のアイデアや提案を聞いてみたいと思います。

@MotardoプランCが最も理にかなっていることに間違いなく同意します。

これを投稿してから15日が経ちましたが、ReactとRXJSで大幅に改善しましたか？ これは、クライアント側のスクリプト機能の限界を次のレベルに押し上げるための良い課題かもしれません😉

こんにちは。 ＃16071

私がしたこと：
最初にストリーク計算を変更して、1。5日間ではなく24時間間を使用しました。 次に、前のタイムスタンプと現在のタイムスタンプのstartOf（ 'day'）の時間の差を取り、それをhoursBetweenと比較して、過去1日ではなく過去24時間に行われた作業を考慮しました。 （同じように聞こえますが、おそらく試してみる価値があります）

おそらく、より良い修正は、ユーザーが設定で独自のタイムゾーンを設定できるようにし、すべてがそのタイムゾーンを使用して計算/設定される場合です。

編集：異なるストリークのセットを持つローカルホストでダミーアカウントを使用/作成する方法を知っている人はいますか？

編集：これらすべてを気にしないでください。

深く掘り下げてみたところ、ヒートマップとストリークの間の不一致はヒートマップが原因である可能性があることがわかりました。 https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicayフロントエンドをますます静的にホストすることを計画しているため、サーバー側のロジックをフロントエンドに依存しないようにすることを主な目的として、ユーザーがタイムゾーンを（いくつかのスマートなデフォルトで）保存できるようにする必要があると思います。

@raisedadeadタイムゾーンの設定をユーザーに頼るのではなく、これを処理するためのより簡単な方法が必要だと思います。 それらの多くはVPNを使用して旅行します。

誰かがタイムゾーンを変更したときにストリークが壊れないように、十分なアフォーダンスを組み込むことができますか？ 現在、36時間以内であれば、ストリークを維持していると思います。

@QuincyLarson私は間違っている可能性がありますが、36時間以内にストリークを維持できるとは思いません。 Afaik prepUniqueDaysは、24時間、48時間などのタイムスタンプの配列を作成し、1。5日であるbetweenDaysと比較しますが、一意の日の値の差は整数（1,2、... n）のみである可能性があります。ストリークの計算に使用されている小数は実際にはありません。

req.user.timezoneを取得するにはどうすればよいですか？ ダミーにはプロパティとしてタイムゾーンがないため、 const timezone = user && user.timezone ? user.timezone : 'UTC';常にデフォルトでUTCになります。 ユーザーの場所に応じて設定しますか？

user.timezoneがある場合、ストリークはuser.timezoneと一致しますが、ヒートマップは常にクライアントのタイムゾーンと一致するだけです。

現在の設定でのさまざまなシナリオ

ユーザーのタイムゾーンがクライアントのタイムゾーンと一致する場合

• 縞とヒートマップはどちらも正確で一貫性があります。

ユーザーのタイムゾーンがクライアントのタイムゾーンと一致しない場合（VPN、場所/タイムゾーンの設定が間違っているなど）

• ストリークはuser.timezoneで正確になりますが、ヒートマップはおそらく正確ではありません。

user.timezoneが定義されていない場合（ユーザーがログインしていないか、場所/タイムゾーンを設定していない）

• ストリークは不正確になりますが、VPNを使用しない限り、ヒートマップはクライアントのタイムゾーンで正確になります。 ここでできることは、デフォルトとしてUTCを使用する代わりに、クライアントのタイムゾーンを使用してヒートマップを一致させることもできると思います。

_PS：私は間違っている可能性があるので、遠慮なく訂正してください。_

@ Kenneth-LJS私は、さらに12時間の余裕を認めたという印象を受けましたが、それは変わった可能性があります。 あなたがコードを注意深く見ているなら、私はそれがどのように組み合わされるかについてのあなたの理解を信頼するでしょう。

シナリオに関しては、カレンダーがわずかにオフセットされていても問題ありません。 これに気づいたり不平を言ったりしたキャンピングカーはほとんどいません。 キャンピングカーはそれほど気にしません。 しかし、ストリークが壊れることはOKではありません-それが非常に多くのキャンピングカーがこのバグについて不平を言っている原因です。

したがって、私の主張は、タイムゾーンを把握して同期しようとするのではなく、ほとんどのアメリカ人が住んでいるESTに時間を正規化し、誰かが誤って終了する可能性を減らすために12〜24時間の余裕を追加することです。旅行中のストリーク。

こんにちは、私はこの投稿に@QuincyLarsonのコメントを見たので書いています。

私は新しいキャンピングカーで、次の日に認められた活動で「5日間のストリーク」が進行中です。
Jan18-5アイテム
1月19日-24アイテム
Jan20-16アイテム
Jan21-2アイテム
Jan22-7アイテム

上記を読むと、「カレンダーが完了した」日付が相殺されることが予想されますが、私のストリークは1日しか表示されません。

===
補足-素晴らしい仕事に感謝します。 コーディングを学ぶのはこれで5回目ですが、このプログラムは私をこぶを乗り越えるものだと思います。

@kennethlumalicayこれを見てください。 @ApeCogsの問題の原因は何でしょうか？

@ApeCogsは、1月21日と22日に各チャレンジを行った時間を知っていますか？（大まかな見積もりでも）あなたのタイムゾーンは何ですか？ また、VPNを使用していますか？

@ kennethlumalicay- 1月21日は東部標準時22：

問題が発生しています。 これは通常、22：00 CST〜24：00CST頃にチャレンジを行うときに発生します。 日曜日の19：00CST〜20：00 CST頃にやったとき、ストリークを失いましたが。 これは通常、私が7〜8日の連続でいるときにも発生します。 VPNを使用していません。 他にご不明な点がございましたら、お気軽にお問い合わせください。

@ApeCogsダミーデータを使用しましたが、再現できないようです。

タイムスタンプ：

Wed Jan 24 2018 22:30:00 GMT-0500 (Eastern Standard Time)
Wed Jan 24 2018 23:30:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:05:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:12:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:20:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:30:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:39:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:40:00 GMT-0500 (Eastern Standard Time)
Thu Jan 25 2018 09:43:00 GMT-0500 (Eastern Standard Time)

21と22ではなく24と25を使用して、「今日」と「昨日」を再現しました。

結果：

@mrielあなたも現在の連勝を失いましたか？ ヒートマップとストリークを含むより大きなスクリーンショットを提供できますか？

継続的な議論のため、再開

@kennethlumalicayは私のスクリーンショットです：

ほとんどの場合、私の以前の筋は7〜8日でした。 翌日、夜の18:00 CST〜22：00CSTの間に1つのレッスンを行います。 翌日、私の現在のストリークは1日と表示されます。

私は、現在のストリーク、曜日、時間、およびどのような課題のログを保持し始めました。

ここでは、20日に何かをしたと書かれています。

しかし、ここでは20には何もありません。

したがって、タイムスタンプが間違ったタイムゾーンで表示されていると想定しています。

    // timezone of signed-in account
    // to show all date related components
    // using signed-in account's timezone
    // not of the profile she is viewing
    const timezone = user && user.timezone ?
      user.timezone :
      'EST';

したがって、サインインしていない場合、ユーザーはnullになり、タイムゾーンは「EST」になります。
サインインしている場合でも、 user.timezone実際に存在するかどうかはわかりません。これは、ローカルデータベースのダミーデータには存在しないためです。 fccのdbが異なる場合は、Idkですが、まだ間違ったタイムゾーンを取得しているため、おそらく「EST」を取得しています。
これはデフォルトで常に「EST」になると思います。

〜「EST」をmoment.tz.guess（）に変更して、可能な修正を送信しました。〜

私はただ挑戦しました。 これが私のステータスです。
01/25/2018 20:41 PM.reverseを使用したCSTリバースアレイ

先週、チャレンジがどのように記録されているかを観察しました。基本的に、チャレンジの日付とストリークはUTCで行われ、ヒートマップはESTを使用しています。 つまり、私とCSTの他の人々は、すべての部分で同じ日にカウントされるために、午後6時までにチャレンジを行う必要があります。 そして、ある日の朝と次の夜に挑戦すると、さようならの筋。

考えてみれば、私が使用している語学学習プログラムでは、ストリーク情報の横に残り時間のカウントダウンが表示されています。 「ストリークを維持するために...による完全なレッスン」というメモを持っています。 同様に便利です。 ストリークの問題では、一貫した時間を取得することを最優先事項と呼びますが、旅行のTZを調整したり、猶予時間を許可したりすることを心配するよりも、その日の締め切りを人々に知らせる方が便利です。

驚くべき100DaysOfCodeChallangeを役に立たなくするバグ

これが私のプロフィールです： https ：

私の69日間のストリークは理由もなく壊れています

@QuincyLarsonお願いします、これは何ですか、これを元に戻すことはできますか？！
24:00の2時間後に作業を送信しましたが、タイムゾーンエラーではないと思います。FCCの多くの人がこのエラーを修正していない可能性があるとしても、どうしてですか。

私は本当にがっかりしました。この100DaysOfCodeChallangeにとてもやる気があり、すべてのフロントエンドプロジェクトとその他すべてを完了しました。フロントエンド証明書を要求するために解決する高度なアルゴリズムは4つしかなく、睡眠なしで何時間も滞在しました。ストリークを続けるために...

スクリーンショット

100DaysOfCode Challange、そのようなバグが続く場合、それは私たちの士気を台無しにするでしょう。

@ JohnnyCheung1989バグが私の筋を台無しにして以来、私の進歩を見てください:(

ビデオチャレンジもストリークにはカウントされないようですが、ヒートマップにはカウントされます。

私は特にプロダクションコードの初心者です。 このアルゴがオーバーヘッドを大きくしすぎるかどうかはわかりません...しかし、ヒートマップが正常に機能しているように見えるので、なぜストリークのアルゴが緑色のヒートマップをチェックするか、逆にグレーのギャップをチェックして戻ることができないのですか？要素が「#cccc」であるかどうかを確認するなどの値。
現在のストリークロジックのタイムゾーンと計算をすべて削除し、ヒートマップで要素の色を確認してください...
もし！ グレーストリーク++グレーストップストリークの場合は、ストリークが最長ストリークよりも長いかどうかを確認しますか？

これが以前に提起されたことがあるなら、私を許してください。

ヒートマップが不正確であることは一度も見たことがありませんが、私の筋は良好です...それほど多くはありません。

または、どういうわけかヒートマップコードにフラグを付けて、ストリーク出力がそれをチェックして更新できないのですか？

@ dverdin83
コードを簡単に見てみました。 ヒートマップはプラグインであるため、ヒートマップコードの編集は、更新すると破損するため、実行しないでください。 緑のカウントに関しては、プラグインがその場で色を作成しているように見えるので、計算を遅らせるためにコールバックを追加する必要があります。

ヒートマップと同じことを確認することをお勧めします。それは、Motardoによって提案されたものです_（2017年9月2日の彼のコメント-プランCを参照）_。

https://github.com/freeCodeCamp/freeCodeCamp/issues/17299を支持してこの問題をクローズ

ストリークカウンターとヒートマップで使用されているタイムゾーンを知っている人はいますか？ 15:45 PM KST（UTC +0900）までにチャレンジを終了したにもかかわらず、74日間の連勝を失いました。 ストリークは1日しか表示されませんが、ヒートマップの今日の正方形は緑色で表示され、タイムラインではチャレンジが今日も完了したと記録されます。 ストリークカウンターが1つのタイムゾーンを使用しているのに対し、ヒートマップとタイムラインは2番目のタイムゾーンを使用しているようです。 誰か確認してもらえますか？ 毎日その数が増えるのを見て、それを友人、家族、そして潜在的な雇用主と共有できることに誇りを持っていたので、それは本当に意気消沈しました。

修正することは優先度が高くないかもしれないことを理解しているので、少なくともストリークのルールを知っていると、それに応じてコーディングを理解し、調整するのに本当に役立ちます。

@sgraymeから引用https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment-361716788

先週、チャレンジがどのように記録されているかを観察しました。基本的に、チャレンジの日付とストリークはUTCで行われ、ヒートマップはESTを使用しています...