Freecodecamp: لا يزال الخط غير دقيق بالنسبة للعديد من المعسكر

المرة الأولى لي مع مساهمات مفتوحة المصدر ، لكني أرغب في معرفة ما إذا كنت مستعدًا لهذه المهمة.

لا تزال هذه مشكلة نتلقى الكثير من الشكاوى بشأنها.

QuincyLarson أنا مهتم بالمساعدة

تضمين التغريدة نحن مهتمون بمساعدتك! تعرف على ما إذا كان يمكنك كتابة بعض الاختبارات حول هذا والتي تغطي حالات الحافة المختلفة. يبدو أنه يعمل بنسبة 99.9 ٪ من الوقت ، ولكن هناك بعض المواقف التي لا تعمل فيها ولست متأكدًا تمامًا من السبب.

لقد بحثت في هذا الأمر قليلاً وقد يكون سببه حقيقة أنه يحسب الخطوط الحالية من التحديات وليس الأنشطة الأخرى (المشاريع أو الخوارزميات). من الممكن أيضًا أن تكون هذه المناطق الزمنية كما هو مذكور أعلاه. سأبحث في المشكلة وأرى ما إذا كان بإمكاني العلاقات العامة إذا لم يتعامل معها أي شخص آخر.

هل يمكن لأحدهم إخباري إذا فاتني شيء هنا.

بين = 1.5 ؛ يمكن تحديثها إلى ثوابت أيام بين = 2 ؛ لأن المنطق في الوظائف التالية يقول دائمًا أقل من يوم بين وليس أقل من أو يساوي يومًا بين. هذا يعني أنه ستكون هناك تغطية من الساعة 12:00:00 صباحًا في يوم من الأيام حتى الساعة 11:59:59 مساءً في اليوم التالي. يجب أن يظل منطق المنطقة الزمنية كما هو أيضًا.

تغيير الأيام - ما بين إلى 2 يعني أن هناك كسران في الاختبار ، ويمكن إصلاحهما ولكن علي أن أتعلم قليلاً كيف تعمل الاختبارات أولاً.

سيكون الخيار البديل هو تعيين أيام ما بين 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 to 2 وقم بتحديث الاختبارات حتى تنجح.

إذا كنت قادرًا على ذلك ، فيرجى معرفة ما إذا كان يمكنك إضافة بعض تغطية الاختبار الإضافية للتأكد من أن هذا يعالج حالات الزاوية المختلفة التي ظهرت (هناك العديد من المشكلات المتعلقة بالخطوط).

شكرا لك على وقتك واهتمامك بهذا. لقد كانت هذه مشكلة كبيرة لعدة أشهر وهي مصدر للعديد من الشكاوى ، لذلك سيكون إصلاح ذلك ضخمًا :)

المشكلة هي أن حساب streak يعتمد على المنطقة الزمنية. في منطقة زمنية واحدة ، لنفترض أن عمليات الإرسال الثلاثة الخاصة بي هي [Aug 5, Aug 6, Aug 7] . في منطقة زمنية أخرى ، قد تكون عمليات الإرسال نفسها على [Aug 5, Aug 5, Aug 6] . تعتمد خريطة التمثيل اللوني للتقويم أيضًا على المنطقة الزمنية ، ودائمًا ما تستخدم خريطة التمثيل اللوني المنطقة الزمنية للعميل الذي يعرض الصفحة في المتصفح. لذلك إذا أردنا أن يتطابق streaks مع خريطة التمثيل اللوني ، فنحن بحاجة إلى استخدام المنطقة الزمنية للعميل في الحساب. هذا هو ما فعلته LenaBarinova عندما تم إصلاح هذه المشكلة مرة أخرى في يناير 2016 بالرقم # 6333. كان الحل هو جعل المتصفح يرسل المنطقة الزمنية للمستخدم كلما تم إرسال التحدي. سيخزن الخادم المنطقة الزمنية ويستخدمها لحساب الخطوط. ولكن في كانون الثاني (يناير) 2017 ، كانت هناك عملية إعادة هيكلة كبيرة غيرت طريقة تقديم التحديات ، وتمت إزالة الإصلاح . لا يزال منطق جانب الخادم موجودًا ، إنه فقط المتصفح لا يرسل المنطقة الزمنية بعد الآن.

Motardo شكرا على التحقيق في هذا. هل تهتم بهذا الأمر وتصلحه لإعادة إصلاح

QuincyLarson بعد إلقاء نظرة أخرى والنوم عليها ،

الخطة أ
أعتقد أن الحل القديم لم يكن مثالياً. تطلبت من المستخدم تسجيل الدخول لعرض ملف التعريف الخاص به بشكل صحيح وسيظل يظهر تناقضات عند عرض ملفات تعريف المستخدمين الآخرين في مناطق زمنية أخرى.

الخطة ب (حل مؤقت بسيط ومباشر وجيد)
أعتقد أن الحل الأبسط والأكثر قوة هو إرسال المنطقة الزمنية للعملاء مع أي طلب لعرض ملف تعريف أي مستخدم ، ويمكن للخادم حساب الخطوط بناءً على تلك المنطقة الزمنية. ثم لا يهم ما إذا كان العميل قد سجل الدخول ، أو تم عرض ملف التعريف الخاص به. ستتم مزامنة الخطوط والتقويم دائمًا.

الخطة ج (إعادة بناء معقدة ، خارطة طريق مستقبلية محتملة)
ربما يكون أفضل حل هو عدم حساب الخطوط على الخادم على الإطلاق. يجب على الخادم إرسال الطوابع الزمنية الأولية إلى العميل والسماح للعميل بتحديد اليوم الذي ينتمي إليه كل طابع زمني وطول المدة التي تستند فيها الخطوط إلى المنطقة الزمنية المحلية. هذا هو بالضبط ما نفعله ببيانات خريطة التمثيل اللوني للتقويم ، لذا ستكون دائمًا متسقة.

أنا جديد تمامًا للتفاعل و rxjs ، وأعتقد أن الخطة ج خارج عمقي ، ولكن سأكون سعيدًا بعمل تصحيح للخطة ب ، وأود أن أسمع أفكارًا واقتراحات أخرى.

Motardo أوافق بالتأكيد على أن الخطة C هي الأكثر منطقية.

بالنظر إلى مرور 15 يومًا على نشر هذا ، هل تحسنت كثيرًا باستخدام React و RXJS؟ قد يكون هذا تحديًا جيدًا لدفع حدود قدرات البرمجة النصية من جانب العميل إلى المستوى التالي

أهلا. # 16071

ماذا فعلت:
لقد غيرت حساب الخط أولاً لاستخدام 24 ساعة بين بدلاً من 1.5 يومًا بين. ثم أخذت الفرق في ساعات البدء ("اليوم") للطابع الزمني السابق والطابع الزمني الحالي وقارنته بالساعات بين لحساب الأعمال التي تم إنجازها خلال الـ 24 ساعة الماضية بدلاً من اليوم الماضي. (يبدو كما هو ولكن ربما يستحق المحاولة)

من المحتمل أن يكون الإصلاح الأفضل هو إذا سمحت للمستخدم بتعيين المنطقة الزمنية الخاصة به في الإعدادات ويتم حساب / تعيين كل شيء باستخدام تلك المنطقة الزمنية.

تحرير: هل يعرف أي شخص كيفية استخدام / إنتاج حسابات وهمية في المضيف المحلي الذي يحتوي على مجموعات مختلفة من الخطوط؟

تحرير: بغض النظر عن كل هذه.

حاولت التعمق أكثر ، اكتشفت أن التناقضات بين خريطة التمثيل اللوني والشرائط ربما تكون ناتجة عن خريطة الحرارة. https://github.com/wa0x6e/cal-heatmap/issues/122

@ kennethlumalicay أعتقد أننا يجب أن نسمح للمستخدمين بتخزين مناطقهم الزمنية (مع بعض الإعدادات الافتراضية الذكية) في الغالب لأننا نخطط للإبقاء على منطق جانب الخادم محايدًا للواجهة الأمامية حيث نخطط لجعل الواجهة الأمامية مستضافة أكثر وأكثر بشكل ثابت.

raisedadead أعتقد أنه يجب أن تكون هناك طريقة أبسط للتعامل مع هذا بدلاً من الاعتماد على المستخدمين لتعيين مناطقهم الزمنية. يستخدم الكثير منهم شبكات VPN ويسافرون.

هل يمكننا توفير تكلفة كافية بحيث لا يتم كسر الخط عندما يغير شخص ما المناطق الزمنية؟ أعتقد أننا حاليًا نحافظ على الخط طالما أنه في غضون 36 ساعة.

QuincyLarson قد أكون مخطئا ولكن لا أعتقد أننا نحافظ على الخط في غضون 36 ساعة. ينشئ Afaik the prepUniqueDays مجموعة من الطوابع الزمنية التي تتراوح بين 24 و 48 وما إلى ذلك من الساعات ونقارنها بـ betweenDays وهو 1.5 يومًا ولكن الفرق بين قيمة الأيام الفريدة يمكن أن يكون فقط أعداد صحيحة (1،2 ، ... ن) لذلك لا يحتوي حقًا على أي رقم عشري يتم استخدامه في حساب الخطوط.

كيف نحصل على 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 ساعة إضافية من الفسحة ، لكن ربما تغير ذلك. إذا كنت تبحث عن كثب في الشفرة ، فسأثق في فهمك لكيفية انسجامها معًا.

فيما يتعلق بالسيناريوهات الخاصة بك ، فلا بأس أن يتم تعويض التقويم قليلاً. قلة قليلة من المعسكر لاحظوا هذا أو اشتكوا منه. لن يمانع المعسكرون كثيرًا. لكن ليس من المقبول كسر الخط - وهذا ما تسبب في قيام العديد من المعسكر بالكتابة في الشكوى من هذا الخطأ.

لذا فإن حجتي ستكون بدلاً من محاولة معرفة المناطق الزمنية ومزامنتها ، فنحن فقط نطبيع الوقت إلى EST - حيث يعيش معظم الأمريكيين - ونضيف مهلة من 12 إلى 24 ساعة لتقليل احتمالية إنهاء شخص ما عن غير قصد له. خط عند السفر.

مرحبا، أنا أكتب لأنني رأيتQuincyLarson تعليق على هذه الوظيفة .

أنا عربة جديدة ولدي "خط 5 أيام" مستمر مع التعرف على الأنشطة في:
18 يناير - 5 عناصر
19 يناير - 24 مادة
20 يناير - 16 مادة
21 يناير - 2 عناصر
22 يناير - 7 عناصر

أرى من خلال القراءة أعلاه أن هناك توقعًا بأن يتم تعويض تواريخ "انتهاء التقويم" ، لكن خطي يظهر يومًا واحدًا فقط.

===
ملاحظة جانبية - شكرا على العمل الرائع. هذه هي محاولتي الخامسة لتعلم البرمجة ، لكنني أعتقد أن هذا البرنامج هو الذي سيساعدني في تجاوز الحدبة!

@ kennethlumalicay يرجى إلقاء نظرة على هذا. هل لديك أي فكرة عن سبب

ApeCogs هل تعرف الوقت الذي قمت فيه بكل تحدي في 21 و 22 يناير؟ (حتى تقديرات تقريبية) ما هي منطقتك الزمنية؟ هل تستخدم VPN أيضًا؟

@ kennethlumalicay - 21 يناير سيكون حوالي الساعة 22:30 - 23:30 بالتوقيت الشرقي. كان يوم 22 يناير 09:00 - 10:00 بالتوقيت الشرقي. أنا أستخدم VPN في بعض الأحيان ولكنه مخصص للعمل والمنطقة لا تتغير (شرقًا).

أواجه مشكلة. يحدث ذلك عادةً عندما أقوم بتحدي في حوالي الساعة 22:00 بتوقيت وسط أمريكا - 24:00 بتوقيت وسط أمريكا. على الرغم من أنني فقدت خطي عندما قمت بذلك يوم الأحد في حوالي الساعة 19:00 بتوقيت وسط الولايات المتحدة - 20:00 بتوقيت وسط أمريكا. سيحدث هذا أيضًا عادةً عندما أكون في حدود 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)

لقد استخدمت 24 و 25 بدلاً من 21 و 22 لإعادة إنشاء "اليوم" و "أمس".

نتيجة:

mriel هل فقدت

إعادة الافتتاح بسبب المناقشة الجارية

kennethlumalicay هنا لقطة شاشة خاصة بي:

معظم الوقت كانت خطوطي السابقة 7-8 أيام. في اليوم التالي سأحضر درسًا واحدًا في الليل بين 18:00 CST - 22:00 CST. في اليوم التالي سيقول أن خطي الحالي هو يوم واحد.

لقد بدأت في الاحتفاظ بسجل للخط الحالي واليوم والوقت والتحدي.

هنا تقول أنك فعلت شيئًا في 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';

لذلك إذا لم تقم بتسجيل الدخول ، فسيكون المستخدم فارغًا وستكون المنطقة الزمنية "EST".
حتى إذا قمت بتسجيل الدخول ، فأنا لست متأكدًا حقًا مما إذا كان user.timezone موجودًا بالفعل لأنه غير موجود في البيانات الوهمية على db المحلي. Idk إذا كان db الخاص بـ fcc مختلفًا ولكن نظرًا لأنك لا تزال تحصل على المنطقة الزمنية الخاطئة ، فمن المحتمل أنك لا تزال تحصل على "EST".
أفترض أن هذا ينتقل دائمًا إلى "EST" افتراضيًا.

~ لذلك قدمت إصلاحًا محتملاً عن طريق تغيير "EST" إلى moment.tz.guess () . ~

لقد قمت للتو بتحدي. هذا هو حالتي:
01/25/2018 20:41 مساءً CST المصفوفات العكسية ذات .reverse

لقد لاحظت كيف يتم تسجيل التحديات خلال الأسبوع الماضي ورأيت أساسًا تواريخ التحدي والخط الذي يتم إجراؤه بواسطة UTC والخريطة الحرارية تستخدم EST. هذا يعني أنني أنا والأشخاص الآخرين في CST بحاجة إلى القيام بتحديات قبل الساعة 6 مساءً ليتم احتسابها في نفس اليوم على جميع الأجزاء. وإذا كنت أقوم بالتحديات في الصباح في أحد الأيام وفي المساء في اليوم التالي ، فإن خط الوداع.

مجرد فكرة ، برامج تعلم اللغة التي أستخدمها لديها ساعات من العد التنازلي الأيسر مرئي بجوار معلومات الخط. الحصول على ملاحظة تقول "أكمل الدروس عن طريق ... للحفاظ على الخط." ستكون مفيدة بنفس القدر. أود أن أعتبر الحصول على أوقات متسقة هو الأولوية الأولى لمشكلة الخط ، لكن السماح للناس بمعرفة الموعد النهائي لليوم سيكون أكثر فائدة من القلق بشأن تعديل TZ للسفر أو السماح بساعات السماح (لطيفة مثل تلك الأشياء تبدو).

خطأ يجعل 100DaysOfCode المذهل Challange عديم الفائدة

هنا ملفي الشخصي: https://www.freecodecamp.org/dardandmr

لقد تم كسر 69 يومًا من الخط بلا سبب

QuincyLarson من فضلك
لقد قدمت العمل بعد ساعتين من الساعة 24:00 ، ولا أعتقد أنه خطأ في المنطقة الزمنية ، حتى لو كان الأمر كذلك كيف يمكن أن العديد من الأشخاص هنا في FCC لم يصلحوا هذا الخطأ؟

أشعر بخيبة أمل حقًا ، لقد كنت متحمسًا للغاية مع 100DaysOfCode Challange ، وقد أنهيت جميع مشاريع الواجهة الأمامية وكل شيء آخر ، لدي فقط 4 خوارزميات متقدمة لحلها للمطالبة بشهادة الواجهة الأمامية ، بقيت ساعات طويلة بدون نوم للحفاظ على الخط مستمرا ...

لقطة شاشة

100DaysOfCode Challange ، إذا استمر هذا الخطأ ، فسيخربنا معنوياتنا.

@ JohnnyCheung1989 انظر إلى تقدمي منذ أن دمر الخطأ

يبدو أن تحديات الفيديو لا يتم احتسابها ضمن الخطوط أيضًا ، ولكن يتم احتسابها في خريطة الحرارة.

أنا مبتدئ خاصة مع كود الإنتاج. لا تعرف ما إذا كانت هذه الخوارزمية ستخلق الكثير من النفقات العامة ... ولكن نظرًا لأن خريطة التمثيل اللوني تعمل بشكل جيد ، فلماذا لا يمكن للخطة الخاصة بالخطوط فقط التحقق من الخريطة الحرارية لأيام ملونة باللون الأخضر أو ​​الذهاب في الاتجاه الآخر وتحقق من وجود فجوات رمادية والعودة قيمة مثل التحقق مما إذا كان العنصر هو "#cccc" وما إلى ذلك .. إذا كانت الإجابة بنعم ، فاصل الخط
قم بإزالة كل المنطقة الزمنية المنطقية الحالية والرياضيات معًا وفقط تحقق من الخريطة الحرارية بطريقة ما للون في العنصر ...
إذا ! خط رمادي ++ إذا كان خط التوقف الرمادي ثم تحقق مما إذا كان الخط أطول من الخط الأطول؟

سامحني إذا كان هذا قد تم طرحه من قبل.

لم أر قط خريطة الحرارة غير دقيقة ولكن خطوطي جيدة ... ليس كثيرًا.

أو بطريقة ما ضع علمًا في رمز خريطة التمثيل اللوني ولا تستطيع مخرجات الخط التحقق منه وتحديثه؟

@ dverdin83
لقد نظرت بإيجاز إلى الكود. Heatmap هو مكون إضافي ، لذا لا ينبغي تحرير كود خريطة التمثيل اللوني لأنه سيتعطل إذا تم تحديثه. بالنسبة إلى حساب اللون الأخضر ، يبدو أن المكون الإضافي يبني اللون بشكل سريع ، لذلك ستحتاج إلى إضافة رد اتصال لتأخير الحساب.

سيكون من الأفضل التحقق من نفس الشيء الذي تفعله خريطة التمثيل اللوني ، وهذا ما اقترحه

إغلاق هذه المشكلة لصالح https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

هل يعرف أي شخص المنطقة الزمنية التي يستخدمها عداد الخطوط وخريطة الحرارة؟ لقد فقدت للتو خط 74 يومًا على الرغم من أنني أنهيت التحدي بحلول الساعة 15:45 مساءً بتوقيت كوريا (التوقيت العالمي المنسق +0900). يظهر الخط يومًا واحدًا فقط ولكن مربع اليوم على الخريطة الحرارية ملون باللون الأخضر ، وفي المخطط الزمني يتم تسجيل التحدي على أنه مكتمل اليوم أيضًا. يبدو أن عداد الخطوط يستخدم منطقة زمنية واحدة ، بينما تستخدم خريطة التمثيل اللوني والخط الزمني منطقة زمنية ثانية. هل يمكن لأحد أن يؤكد؟ إنه أمر محبط حقًا لأنني كنت أفخر بمشاهدة الرقم يزداد كل يوم والقدرة على مشاركته مع الأصدقاء والعائلة وأصحاب العمل المحتملين.

أفهم أنه قد لا يكون الإصلاح أولوية عالية ، لذا فإن معرفة قواعد الخط على الأقل سيساعدني حقًا في فهم الترميز وتعديله وفقًا لذلك.

مقتبس من sgrayme https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment -361716788

لقد لاحظت كيف يتم تسجيل التحديات خلال الأسبوع الماضي ورأيت أساسًا تواريخ التحدي والخط الذي يتم إجراؤه بواسطة UTC وخريطة الحرارة تستخدم EST ...