Freecodecamp: Streak masih kurang akurat bagi banyak pekemah

Pertama kali saya dengan kontribusi open source, tetapi saya ingin melihat apakah saya siap untuk tugas itu.

Hal ini masih menjadi masalah yang banyak dikeluhkan.

@QuincyLarson saya tertarik untuk membantu

@sorlovsky Luar biasa! Kami tertarik dengan bantuan Anda! Lihat apakah Anda dapat menulis beberapa tes di sekitar ini yang mencakup berbagai kasus tepi. Tampaknya bekerja 99,9% dari waktu, tetapi ada beberapa situasi di mana tidak dan saya tidak yakin mengapa.

Saya melihat ke dalam ini sedikit dan mungkin disebabkan oleh fakta bahwa itu menghitung garis-garis Tantangan saat ini dan bukan kegiatan lain (Proyek atau Algoritma). Mungkin juga zona waktu seperti yang disebutkan di atas. Saya akan menyelidiki masalah ini dan melihat apakah saya dapat melakukan PR jika tidak ada orang lain yang melakukannya.

Dapatkah seseorang tolong beri tahu saya jika saya kehilangan sesuatu di sini.

const hariAntara = 1,5; dapat diperbarui ke const daysBetween = 2; karena logika dalam fungsi berikut selalu mengatakan kurang dari hariAntara dan tidak kurang dari atau sama dengan hariAntara. Ini berarti akan ada liputan dari 12:00:00 pada suatu hari hingga 11:59:59 pada hari berikutnya. Logika zona waktu semua harus tetap sama juga.

Mengubah hariBetween ke 2 berarti dua tes rusak, yang dapat diperbaiki tetapi saya harus belajar sedikit bagaimana tes bekerja terlebih dahulu.

Opsi alternatifnya adalah menyetel hari-hari Antara ke 1,99 sehingga semua tes lulus, tetapi Anda akan memiliki kemungkinan kehilangan garis selama 7 menit dan 12 detik.

@donofriov tolong lakukan itu. Saya tidak tahu mengapa itu tidak berhasil

@donofriov terima kasih banyak atas analisisnya, dan senang mendengar bahwa Anda tertarik untuk melihat ini. Berikut ini masalah terkait lainnya https://github.com/freeCodeCamp/freeCodeCamp/issues/7468 (berkaitan dengan status masuk pengguna)

Jika Anda memerlukan bantuan, hubungi kami di ruang obrolan.

Saya harus belajar sedikit bagaimana tes bekerja terlebih dahulu.

Ujian ada di
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

Nah ini adalah penataan yang agak rumit dari biasanya. Saya akan ada jika Anda perlu mencari tahu.

Selamat memperbaiki!

@donofriov Ya - jika menurut Anda itu akan memperbaikinya, bagus. Bump daysBetween ke 2 dan perbarui tes agar lulus.

Jika Anda bisa, silakan lihat apakah Anda dapat menambahkan beberapa cakupan pengujian tambahan untuk memastikan ini mengatasi berbagai kasus sudut yang muncul (ada beberapa masalah yang terkait dengan coretan).

Terima kasih atas waktu dan perhatiannya selama ini. Ini telah menjadi masalah besar selama berbulan-bulan dan merupakan sumber dari banyak keluhan, jadi memperbaikinya akan sangat besar :)

Masalahnya adalah bahwa perhitungan streak tergantung pada zona waktu. Dalam satu zona waktu, katakanlah tiga kiriman saya adalah [Aug 5, Aug 6, Aug 7] . Di zona waktu lain, kiriman yang sama mungkin ada di [Aug 5, Aug 5, Aug 6] . Peta panas kalender juga bergantung pada zona waktu, dan peta panas selalu menggunakan zona waktu klien yang melihat halaman di browser. Jadi jika kita ingin streaks cocok dengan peta panas, kita perlu menggunakan zona waktu klien dalam perhitungan. Pada dasarnya itulah yang dilakukan @LenaBarinova ketika masalah ini diperbaiki pada Januari 2016 dengan #6333. Solusinya adalah membuat browser mengirim zona waktu pengguna setiap kali tantangan diajukan. Server akan menyimpan zona waktu dan menggunakannya untuk menghitung coretan. Namun kemudian pada Januari 2017, ada refactoring besar yang mengubah cara pengajuan tantangan, dan perbaikannya dihapus . Logika sisi server masih ada, hanya saja browser tidak mengirim zona waktu lagi.

@Motardo Terima kasih telah menyelidiki ini. Apakah Anda tertarik dan memperbaiki ini agar perbaikan @LenaBarinova berfungsi kembali?

@QuincyLarson Setelah melihat lagi dan tidur di atasnya, inilah pemikiran saya:

Paket A
Saya pikir solusi lama tidak ideal. Itu mengharuskan pengguna untuk masuk untuk melihat profil mereka sendiri dengan benar dan masih akan menunjukkan inkonsistensi saat melihat profil pengguna lain di zona waktu lain.

Rencana B (sederhana dan lugas, perbaikan sementara yang baik)
Saya percaya bahwa solusi yang lebih sederhana dan lebih kuat adalah mengirim zona waktu klien dengan permintaan apa pun untuk melihat profil pengguna mana pun, dan server dapat menghitung coretan berdasarkan zona waktu itu. Maka tidak masalah jika klien masuk, atau profil siapa yang dilihat. Garis-garis dan kalender akan selalu sinkron.

Rencana C (refactor rumit, kemungkinan roadmap masa depan)
Mungkin solusi terbaik adalah tidak menghitung coretan di server sama sekali. Server harus mengirim stempel waktu mentah ke klien dan membiarkan klien memutuskan hari mana setiap stempel waktu itu berada dan berapa lama stempel waktu didasarkan pada zona waktu lokal. Inilah tepatnya yang kami lakukan dengan data peta panas kalender sehingga akan selalu konsisten.

Saya benar-benar baru untuk bereaksi dan rxjs, dan saya pikir Rencana C adalah di luar kedalaman saya, tapi saya akan senang untuk membuat patch untuk Rencana B, dan saya akan senang mendengar ide dan saran lainnya.

@Motardo Saya sangat setuju bahwa Rencana C paling masuk akal.

Mengingat sudah 15 hari sejak Anda memposting ini, apakah Anda telah meningkat pesat dengan React dan RXJS? Ini mungkin tantangan yang bagus untuk mendorong batas kemampuan skrip sisi klien Anda ke tingkat berikutnya

Hai. #16071

Apa yang saya lakukan:
Saya pertama kali mengubah perhitungan beruntun untuk menggunakan 24 jamAntara, bukan 1,5 hariAntara. Kemudian saya mengambil perbedaan jam startOf('day') dari timestamp sebelumnya dan timestamp saat ini dan membandingkannya dengan hoursBetween untuk memperhitungkan pekerjaan yang telah dilakukan dalam 24 jam terakhir, bukan hari yang lalu. (Kedengarannya sama tapi mungkin patut dicoba)

Mungkin perbaikan yang lebih baik adalah jika Anda mengizinkan pengguna untuk mengatur zona waktu mereka sendiri di pengaturan dan semuanya dihitung/diatur menggunakan zona waktu itu.

Sunting: Adakah yang tahu cara menggunakan/menghasilkan akun dummy di localhost yang memiliki rangkaian garis berbeda?

Sunting: Lupakan semua ini.

Mencoba menggali lebih dalam, menemukan ketidakkonsistenan antara peta panas dan garis-garis mungkin disebabkan oleh peta panas. https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicay Saya percaya kita harus membiarkan pengguna menyimpan zona waktu mereka (dengan beberapa default cerdas) terutama karena kami berencana untuk menjaga logika sisi server agnostik dari frontend karena kami berencana untuk membuat frontend lebih dan lebih dihosting secara statis.

@raisedadead Saya pikir pasti ada cara yang lebih sederhana untuk menangani ini daripada mengandalkan pengguna untuk mengatur zona waktu mereka. Banyak dari mereka menggunakan VPN dan bepergian.

Bisakah kita membangun cukup keterjangkauan sehingga garis tidak terputus ketika seseorang mengubah zona waktu? Saya pikir saat ini kami mempertahankan rekor tersebut selama itu dalam waktu 36 jam.

@QuincyLarson Saya bisa saja salah, tetapi saya rasa kami tidak akan mempertahankan rekor tersebut dalam waktu 36 jam. Afaik the prepUniqueDays membuat larik stempel waktu 24, 48 dan seterusnya jam antara dan kami membandingkannya dengan betweenDays yaitu 1,5 hari tetapi perbedaan antara nilai hari unik hanya bisa berupa bilangan bulat (1,2,...n) jadi itu tidak benar-benar memiliki desimal yang digunakan dalam perhitungan coretan.

Bagaimana kita mendapatkan req.user.timezone? Karena dummy tidak memiliki zona waktu sebagai properti jadi const timezone = user && user.timezone ? user.timezone : 'UTC'; selalu default ke UTC. Apakah kita mengaturnya sesuai dengan lokasi pengguna?

Jika kita memiliki user.timezone garis-garis akan konsisten dengan user.timezone tetapi peta panas hanya akan selalu konsisten dengan zona waktu klien.

Skenario yang berbeda dengan pengaturan saat ini

jika zona waktu pengguna cocok dengan zona waktu klien

• Garis-garis dan peta panas akan akurat dan konsisten.

jika zona waktu pengguna tidak cocok dengan zona waktu klien (mis. VPN, lokasi/zona waktu yang ditetapkan salah)

• Garis-garis akan akurat dengan user.timezone tetapi peta panas mungkin tidak.

jika user.timezone tidak ditentukan (Pengguna tidak masuk atau belum menetapkan lokasi/zona waktu mereka)

• Garis-garis akan tidak akurat tetapi peta panas akan tetap akurat dengan zona waktu klien kecuali mereka menggunakan VPN. Saya pikir apa yang bisa kita lakukan di sini adalah daripada menggunakan UTC sebagai default, kita bisa menggunakan zona waktu klien juga untuk mencocokkan peta panas.

_PS: Saya bisa salah jadi jangan ragu untuk mengoreksi saya._

@Kenneth-LJS Saya mendapat kesan bahwa kami mengizinkan 12 jam kelonggaran tambahan, tetapi itu mungkin telah berubah. Jika Anda telah melihat lebih dekat pada kode, saya akan mempercayai pemahaman Anda tentang bagaimana itu cocok bersama.

Mengenai skenario Anda, tidak apa-apa jika kalender sedikit diimbangi. Sangat sedikit pekemah yang memperhatikan hal ini atau mengeluhkannya. Campers tidak akan terlalu keberatan. Tetapi tidak baik jika garis itu dipatahkan - itulah yang menyebabkan begitu banyak pekemah menulis untuk mengeluh tentang bug ini.

Jadi argumen saya adalah daripada mencoba mencari tahu zona waktu dan menyinkronkannya, kami hanya menormalkan waktu ke EST - yang merupakan tempat tinggal sebagian besar orang Amerika - dan menambahkan 12 hingga 24 jam kelonggaran untuk mengurangi kemungkinan seseorang secara tidak sengaja mengakhiri mereka beruntun saat bepergian.

Hai, saya menulis karena saya melihat @QuincyLarson mengomentari posting ini.

Saya seorang kemping baru dan saya memiliki "5 hari beruntun" yang terjadi dengan aktivitas yang dikenali pada:
Jan18 - 5 item
Jan19 - 24 item
Jan20 - 16 item
Jan21 - 2 item
Jan22 - 7 item

Saya melihat dari bacaan di atas ada harapan tanggal "kalender selesai" untuk diimbangi, tetapi coretan saya hanya menunjukkan 1 hari.

===
Catatan tambahan - terima kasih untuk pekerjaan yang luar biasa. Ini adalah usaha saya yang ke-5 untuk belajar coding tapi saya pikir program ini adalah salah satu yang akan membawa saya melewati punuk!

@kennethlumalicay Silakan lihat ini. Adakah yang tahu apa yang mungkin menyebabkan masalah

@ApeCogs apakah Anda tahu waktu Anda melakukan setiap tantangan pada 21 dan 22 Januari? (bahkan perkiraan kasar) Apa zona waktu Anda? Apakah Anda juga menggunakan VPN?

@kennethlumalicay - 21 Januari sekitar pukul 22:30 - 23:30 EST. 22 Januari adalah pukul 09:00 - 10:00 EST. Saya kadang-kadang menggunakan VPN tetapi itu untuk bekerja dan wilayahnya tidak berubah (timur).

Saya mengalami masalah. Itu biasanya terjadi ketika saya melakukan tantangan sekitar pukul 22:00 CST - 24:00 CST. Padahal saya telah kehilangan streak saya ketika saya melakukannya pada hari Minggu sekitar 19:00 CST - 20:00 CST. Ini juga biasanya terjadi ketika saya berada di sekitar 7-8 hari beruntun. Tidak menggunakan VPN. Jika ada yang bisa saya lakukan lebih banyak untuk membantu, beri tahu saya.

@ApeCogs Saya menggunakan beberapa data dummy tetapi sepertinya saya tidak dapat mereproduksinya.

cap waktu:

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)

Saya menggunakan 24 dan 25 alih-alih 21 dan 22 untuk membuat ulang "hari ini" dan "kemarin" Anda.

hasil:

@mriel Anda juga kehilangan garis Anda saat ini? Bisakah Anda memberikan tangkapan layar yang lebih besar yang berisi peta panas dan coretan?

Pembukaan kembali, karena diskusi yang sedang berlangsung

@kennethlumalicay di sini adalah tangkapan layar saya:

Sebagian besar waktu goresan saya sebelumnya adalah 7-8 hari. Keesokan harinya saya akan melakukan satu pelajaran pada malam hari antara pukul 18:00 CST - 22:00 CST. Sehari setelahnya akan mengatakan bahwa coretan saya saat ini adalah 1 hari.

Saya sudah mulai mencatat rentetan saat ini, hari, waktu, dan tantangan apa.

Di sini dikatakan Anda melakukan sesuatu pada 20.

Tapi di sini tidak ada apa-apa di 20.

Jadi saya berasumsi stempel waktu Anda ditampilkan dengan zona waktu yang salah.

    // 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';

Jadi jika Anda tidak masuk, pengguna akan menjadi nol dan zona waktu akan menjadi 'EST'.
Bahkan jika Anda masuk, saya tidak begitu yakin apakah user.timezone benar-benar ada karena tidak ada pada data dummy di db lokal saya. Idk jika db fcc berbeda tetapi karena Anda masih mendapatkan zona waktu yang salah maka Anda mungkin masih mendapatkan 'EST'.
Saya berasumsi ini selalu masuk ke 'EST' secara default.

~Jadi saya mengirimkan kemungkinan perbaikan dengan mengubah 'EST' menjadi moment.tz.guess() .~

Saya baru saja melakukan tantangan. Inilah status saya:
25/01/2018 20:41 PM CST Reverse Array dengan .reverse

Saya mengamati bagaimana tantangan dicatat selama minggu lalu dan pada dasarnya melihat tanggal dan rentetan tantangan dilakukan oleh UTC dan peta panasnya menggunakan EST. Ini berarti saya dan orang lain di CST perlu melakukan tantangan sebelum jam 6 sore untuk dihitung pada hari yang sama di semua bagian. Dan jika saya melakukan tantangan di pagi hari dan sore hari berikutnya, selamat tinggal beruntun.

Hanya sebuah pemikiran, program pembelajaran bahasa yang saya gunakan memiliki hitungan mundur satu jam yang terlihat di sebelah informasi beruntun. Memiliki catatan yang mengatakan "menyelesaikan pelajaran dengan ... untuk mempertahankan garis." akan sama bermanfaatnya. Saya akan menyebut mendapatkan waktu yang konsisten sebagai prioritas pertama untuk masalah beruntun, tetapi memberi tahu orang-orang tenggat waktu mereka untuk hari itu akan lebih berguna daripada khawatir tentang menyesuaikan TZ untuk perjalanan atau mengizinkan jam tenggang (sebagus hal-hal itu terdengar).

Bug yang membuat Tantangan 100DaysOfCode yang menakjubkan menjadi tidak berguna

Ini profil saya: https://www.freecodecamp.org/dardandmr

69 Days of Streak saya rusak tanpa alasan

@QuincyLarson tolong bro, apa ini, dan bisakah kita membalikkan ini?!
Saya telah mengirimkan pekerjaan dua jam setelah pukul 24:00, saya tidak berpikir bahwa itu adalah kesalahan zona waktu, meskipun bagaimana mungkin begitu banyak orang di sini di FCC belum memperbaiki kesalahan ini?

Saya sangat kecewa, saya sangat termotivasi dengan Tantangan 100DaysOfCode ini, dan saya telah menyelesaikan semua Proyek Front-End dan yang lainnya, saya hanya memiliki 4 Algoritma Tingkat Lanjut untuk diselesaikan untuk mengklaim Sertifikat Front-End saya, tinggal berjam-jam tanpa tidur saja untuk menjaga alurnya...

Tangkapan layar

Tantangan 100DaysOfCode , jika bug seperti itu terus berlanjut , itu hanya akan merusak moral kita.

@JohnnyCheung1989 lihat kemajuan saya sejak bug merusak coretan saya :(

Tampaknya tantangan video juga tidak dihitung sebagai goresan, tetapi dihitung dalam peta panas.

Saya seorang pemula terutama dengan kode produksi. Tidak tahu apakah algo ini akan membuat terlalu banyak overhead ... Tapi karena peta panas tampaknya berfungsi dengan baik mengapa algo untuk beruntun tidak bisa memeriksa peta panas selama berhari-hari berwarna hijau atau pergi ke arah lain dan periksa celah abu-abu dan kembali nilai seperti periksa apakah elemennya '#cccc' dll. jika ya break streak
Hapus semua zona waktu dan matematika logika beruntun saat ini bersama-sama dan cukup periksa peta panas dengan cara tertentu untuk warna dalam elemen ...
jika ! garis abu-abu++ jika garis berhenti abu-abu lalu periksa apakah garis lebih panjang dari garis terpanjang?

Maafkan saya jika ini telah diangkat sebelumnya.

Saya belum pernah melihat peta panas tidak akurat tetapi coretan saya baik-baik saja ... tidak terlalu banyak.

Atau entah bagaimana meletakkan bendera di kode peta panas dan keluaran beruntun tidak dapat memeriksanya dan memperbaruinya?

@dverdin83
Saya hanya sebentar melihat kodenya. Heatmap adalah plugin, jadi mengedit kode heatmap tidak boleh dilakukan karena akan rusak jika diperbarui. Untuk menghitung warna hijau, sepertinya plugin membuat warna dengan cepat, jadi Anda perlu menambahkan panggilan balik untuk menunda penghitungan.

Akan lebih baik untuk memeriksa hal yang sama seperti yang dilakukan peta panas, itulah yang disarankan oleh Motardo _(lihat komentarnya pada 2 Sep 2017 - Rencana C)_.

Menutup masalah ini demi https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

Adakah yang tahu zona waktu mana yang digunakan oleh penghitung beruntun dan peta panas? Saya baru saja kehilangan 74 hari beruntun meskipun saya menyelesaikan tantangan pada 15:45 KST (UTC +0900). Garis tersebut hanya muncul 1 hari tetapi kotak hari ini di peta panas berwarna hijau, dan pada garis waktu tantangan tersebut dicatat selesai hari ini juga. Sepertinya penghitung beruntun menggunakan satu zona waktu, sedangkan peta panas dan garis waktu menggunakan zona waktu kedua. Bisakah seseorang tolong konfirmasi? Ini benar-benar melemahkan semangat saya karena saya bangga menyaksikan jumlah yang bertambah setiap hari dan dapat membaginya dengan teman, keluarga, dan calon pemberi kerja.

Saya mengerti bahwa itu mungkin bukan prioritas tinggi untuk diperbaiki, jadi setidaknya mengetahui aturan coretan akan sangat membantu saya memahami dan menyesuaikan pengkodean saya.

Dikutip dari @sgrayme https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment -361716788

Saya mengamati bagaimana tantangan dicatat selama minggu lalu dan pada dasarnya melihat tanggal dan rentetan tantangan dilakukan oleh UTC dan peta panas menggunakan EST...