Freecodecamp: La séquence est encore inexacte pour de nombreux campeurs

Ma première fois avec des contributions open source, mais j'aimerais voir si je suis prêt pour la tâche.

C'est toujours un problème sur lequel nous recevons beaucoup de plaintes.

@QuincyLarson Je suis intéressé pour aider

@sorlovsky Génial ! Votre aide nous intéresse ! Voyez si vous pouvez écrire des tests autour de cela qui couvrent divers cas limites. Cela semble fonctionner 99,9% du temps, mais il y a des situations où cela ne fonctionne pas et je ne sais pas trop pourquoi.

J'ai examiné un peu cela et cela peut être dû au fait qu'il compte les séquences actuelles de défis et non les autres activités (projets ou algorithmes). Il est également possible qu'il s'agisse de fuseaux horaires comme indiqué ci-dessus. Je vais examiner le problème et voir si je peux faire des relations publiques si personne d'autre n'y parvient.

Quelqu'un peut-il me faire savoir s'il me manque quelque chose ici.

jours constEntre = 1,5 ; peut être mis à jour en const daysBetween = 2; parce que la logique dans les fonctions suivantes indique toujours moins de daysBetween et pas moins ou égal à daysBetween. Cela signifie qu'il y aura une couverture de 00:00:00 un jour jusqu'à 23:59:59 le lendemain. La logique du fuseau horaire devrait également rester la même.

Changer daysBetween à 2 signifie que deux tests s'interrompent, ce qui peut être corrigé, mais je devrais d'abord apprendre un peu comment fonctionnent les tests.

L'option alternative serait de définir daysBetween à 1,99 pour que tous les tests réussissent, mais vous auriez une possibilité de rater la séquence de 7 minutes et 12 secondes.

@donofriov s'il vous plaît allez-y, je n'ai pas pu comprendre pourquoi cela n'a pas fonctionné

@donofriov merci beaucoup pour l'analyse, et c'est super d'apprendre que vous êtes intéressé à étudier cela. Voici un autre problème connexe https://github.com/freeCodeCamp/freeCodeCamp/issues/7468 (a à voir avec l'état de connexion de l'utilisateur)

Si vous avez besoin d'aide, contactez-nous sur la salle de discussion.

Il faudrait que j'apprenne un peu comment fonctionnent les tests d'abord.

Les tests sont à
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

Eh bien, c'est une structuration un peu compliquée que d'habitude. Je serai là si tu as besoin de comprendre.

Bonne réparation !

@donofriov Oui - si vous pensez que cela daysBetween à 2 et mettez à jour les tests pour qu'ils réussissent.

Si vous en êtes capable, veuillez voir si vous pouvez ajouter une couverture de test supplémentaire pour vous assurer que cela résout les différents cas de coin qui se sont produits (il existe plusieurs problèmes liés aux séquences).

Merci pour votre temps et votre attention à cela. Cela a été un problème majeur pendant des mois et est une source de nombreuses plaintes, donc résoudre ce problème sera énorme :)

Le problème est que le calcul d'un streak dépend du fuseau horaire. Dans un fuseau horaire, disons que mes trois soumissions sont [Aug 5, Aug 6, Aug 7] . Dans un autre fuseau horaire, ces mêmes envois peuvent avoir lieu le [Aug 5, Aug 5, Aug 6] . La carte thermique du calendrier dépend également du fuseau horaire, et la carte thermique utilise toujours le fuseau horaire du client qui consulte la page dans le navigateur. Donc, si nous voulons que le streaks corresponde à la carte thermique, nous devons utiliser le fuseau horaire du client dans le calcul. C'est essentiellement ce que @LenaBarinova a fait lorsque ce problème a été résolu en janvier 2016 avec #6333. La solution consistait à demander au navigateur d'envoyer le fuseau horaire de l'utilisateur chaque fois qu'un défi était soumis. Le serveur stockerait le fuseau horaire et l'utiliserait pour calculer les séquences. Mais en janvier 2017, il y a eu une grande refactorisation qui a changé la façon dont les défis sont soumis, et le correctif a été supprimé . La logique côté serveur est toujours là, c'est juste que le navigateur n'envoie plus le fuseau horaire.

@Motardo Merci d'avoir enquêté là- correctif de

@QuincyLarson Après avoir jeté un autre coup d'œil et dormi dessus, voici mes réflexions :

Planifier un
Je pense que l'ancienne solution n'était pas idéale. Cela nécessitait qu'un utilisateur soit connecté pour afficher correctement son propre profil et afficherait toujours des incohérences lors de l'affichage des profils d'autres utilisateurs dans d'autres fuseaux horaires.

Plan B (simple et direct, bonne solution temporaire)
Je pense qu'une solution plus simple et plus robuste consiste à envoyer le fuseau horaire du client avec toute demande d'affichage du profil de n'importe quel utilisateur, et le serveur pourrait calculer les séquences en fonction de ce fuseau horaire. Peu importe alors si le client est connecté ou si le profil a été consulté. Les séquences et le calendrier seraient toujours synchronisés.

Plan C (refactorisation compliquée, future feuille de route possible)
La meilleure solution serait probablement de ne pas du tout calculer les stries sur le serveur. Le serveur doit envoyer les horodatages bruts au client et laisser le client décider à quel jour appartient chaque horodatage et combien de temps les séquences sont basées sur le fuseau horaire local. C'est exactement ce que nous faisons avec les données de la carte thermique du calendrier afin qu'elles soient toujours cohérentes.

Je suis complètement nouveau pour réagir et rxjs, et je pense que le plan C est hors de ma portée, mais je serais heureux de faire un patch pour le plan B, et j'aimerais entendre d'autres idées et suggestions.

@Motardo Je suis tout à fait d'accord pour dire que le plan C est le plus logique.

Étant donné que cela fait 15 jours que vous avez posté ceci, vous êtes-vous beaucoup amélioré avec React et RXJS ? Cela pourrait être un bon défi pour repousser les limites de vos capacités de script côté client au niveau supérieur 😉

Salut. #16071

Ce que j'ai fait:
J'ai d'abord modifié le calcul de la séquence pour utiliser 24 heures entre au lieu de 1,5 jours entre. Ensuite, j'ai pris la différence d'heures de startOf('day') de l'horodatage précédent et de l'horodatage actuel et l'ai comparée à hoursBetween pour tenir compte des travaux qui ont été effectués au cours des dernières 24 heures au lieu du dernier jour. (Ça a l'air pareil mais ça vaut probablement le coup d'essayer)

Une meilleure solution serait probablement si vous permettez à l'utilisateur de définir son propre fuseau horaire dans les paramètres et que tout est calculé/défini à l'aide de ce fuseau horaire.

Edit : est-ce que quelqu'un sait comment utiliser/produire des comptes factices dans localhost qui ont différents ensembles de séquences ?

Edit : peu importe tout ça.

J'ai essayé de creuser plus profondément, j'ai découvert que les incohérences entre la carte thermique et les traînées étaient peut-être causées par la carte thermique. https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicay Je pense que nous devrions laisser les utilisateurs stocker leurs fuseaux horaires (avec quelques valeurs par défaut intelligentes) principalement parce que nous prévoyons de garder la logique côté serveur agnostique du front-end, car nous prévoyons de rendre le front-end de plus en plus hébergé de manière statique.

@raisedadead Je pense qu'il doit y avoir un moyen plus simple de gérer cela plutôt que de compter sur les utilisateurs pour définir leurs fuseaux horaires. Beaucoup d'entre eux utilisent des VPN et voyagent.

Pouvons-nous intégrer suffisamment d'affordance pour que la séquence ne soit pas interrompue lorsque quelqu'un change de fuseau horaire ? Je pense qu'actuellement, nous maintenons la séquence tant que c'est dans une fenêtre de 36 heures.

@QuincyLarson Je

Comment obtenons-nous le req.user.timezone ? Parce que le mannequin n'a pas de fuseau horaire comme propriété, donc const timezone = user && user.timezone ? user.timezone : 'UTC'; par défaut est toujours UTC. Le définissons-nous en fonction de l'emplacement de l'utilisateur ?

Si nous avons user.timezone, les stries seraient cohérentes avec user.timezone mais la carte thermique ne serait toujours cohérente qu'avec le fuseau horaire du client.

Différents scénarios avec la configuration actuelle

si le fuseau horaire de l'utilisateur correspond au fuseau horaire du client

• Les stries et la carte thermique seraient à la fois précises et cohérentes.

si le fuseau horaire de l'utilisateur ne correspond pas au fuseau horaire du client (par exemple, VPN, mauvais emplacement/fuseau horaire)

• Les stries seraient précises avec user.timezone mais la carte thermique ne le sera probablement pas.

si user.timezone n'est pas défini (l'utilisateur n'est pas connecté ou n'a pas défini son emplacement/fuseau horaire)

• Les stries seraient inexactes, mais la carte thermique sera toujours précise avec le fuseau horaire du client à moins qu'il n'utilise un VPN. Je pense que ce que nous pourrions faire ici, c'est qu'au lieu d'utiliser l'UTC par défaut, nous pourrions également utiliser le fuseau horaire du client pour faire correspondre la carte thermique.

_PS: Je peux me tromper alors n'hésitez pas à me corriger._

@Kenneth-LJS J'avais l'impression que nous avions accordé 12 heures de latitude supplémentaires, mais cela a peut-être changé. Si vous avez regardé de près le code, je ferais confiance à votre compréhension de la façon dont il s'intègre.

Concernant vos scénarios, il est normal que le calendrier soit légèrement décalé. Très peu de campeurs l'ont remarqué ou s'en sont plaints. Les campeurs ne s'en soucieront pas beaucoup. Mais il n'est pas acceptable que la séquence soit interrompue - c'est ce qui a poussé tant de campeurs à écrire pour se plaindre de ce bogue.

Donc, mon argument serait plutôt que d'essayer de comprendre les fuseaux horaires et de les synchroniser, nous normalisons simplement l'heure à l'EST - où vivent la plupart des Américains - et ajoutons une marge de 12 à 24 heures pour réduire la probabilité que quelqu'un mette fin par inadvertance à son séquence lorsque vous voyagez.

Salut, j'écris parce que j'ai vu @QuincyLarson commenter ce post .

Je suis un nouveau campeur et j'ai une "série de 5 jours" avec des activités reconnues sur :
18 janvier - 5 articles
Jan19 - 24 articles
20 janvier - 16 articles
21 janvier - 2 articles
22 janvier - 7 articles

Je vois d'après la lecture ci-dessus qu'il y a une attente que les dates du "calendrier terminé" soient décalées, mais ma séquence ne montre qu'un jour.

===
Note latérale - merci pour le travail impressionnant. C'est ma 5ème tentative d'apprentissage du codage mais je pense que ce programme est celui qui me fera passer le cap !

@kennethlumalicay S'il problème de

@ApeCogs savez-vous à quelle heure vous avez relevé chaque défi les 21 et 22

@kennethlumalicay - Le 21 janvier aurait été vers 22h30 - 23h30 HNE. Le 22 janvier aurait été de 09h00 à 10h00 HNE. J'utilise parfois un VPN mais c'est pour le travail et la région ne change pas (est).

J'ai le problème. Cela se produit généralement lorsque je fais un défi vers 22h00 CST - 24h00 CST. Bien que j'aie perdu ma séquence lorsque je l'ai fait dimanche vers 19h00 CST - 20h00 CST. Cela se produirait également généralement lorsque je suis sur une séquence de 7 à 8 jours. Ne pas utiliser de VPN. S'il y a quelque chose que je peux faire plus pour vous aider, faites-le moi savoir.

@ApeCogs J'ai utilisé des données factices mais je n'arrive pas à les reproduire.

horodatages :

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)

J'ai utilisé 24 et 25 au lieu de 21 et 22 pour recréer votre "aujourd'hui" et "hier".

résultat:

@mriel, tu as aussi perdu ta séquence actuelle ? Pourriez-vous fournir une capture d'écran plus grande contenant la carte thermique et les stries ?

Réouverture, en raison de la discussion en cours

@kennethlumalicay voici une capture d'écran :

La plupart du temps, mes séquences précédentes duraient 7 à 8 jours. Le lendemain, je ferai une leçon la nuit entre 18h00 CST et 22h00 CST. Le lendemain, il dira que ma séquence actuelle est de 1 jour.

J'ai commencé à tenir un journal de la séquence actuelle, du jour, de l'heure et du défi.

Ici, il est dit que vous avez fait quelque chose le 20.

Mais ici, il n'y a rien sur 20.

Je suppose donc que vos horodatages sont affichés avec le mauvais fuseau horaire.

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

Donc, si vous n'êtes pas connecté, l'utilisateur serait nul et le fuseau horaire serait « EST ».
Même si vous êtes connecté, je ne suis pas vraiment sûr que user.timezone existe réellement car il n'existe pas sur les données factices de ma base de données locale. Idk si la base de données de fcc est différente, mais comme vous obtenez toujours le mauvais fuseau horaire, vous obtenez probablement toujours « EST ».
Je suppose que cela va toujours à 'EST' par défaut.

~ J'ai donc soumis un correctif possible en changeant 'EST' en moment.tz.guess() .~

Je viens de faire un défi. Voici mon statut :
25/01/2018 20:41 PM CST Tableaux inversés avec .reverse

J'ai observé comment les défis sont enregistrés au cours de la semaine dernière et j'ai essentiellement vu les dates et les séquences de défi passer par UTC et la carte thermique utilise l'EST. Cela signifie que moi et d'autres personnes de CST devons faire des défis avant 18 heures pour être compté pour le même jour sur toutes les pièces. Et si je fais des défis le matin un jour et le soir le lendemain, adieu la séquence.

Juste une pensée, les programmes d'apprentissage des langues que j'utilise ont un compte à rebours restant visible à côté des informations sur la séquence. Avoir une note disant « terminez les leçons en… pour maintenir la séquence ». serait tout aussi utile. J'appellerais obtenir des heures cohérentes la première priorité pour le problème des séquences, mais informer les gens de leur date limite pour la journée serait plus utile que de s'inquiéter d'ajuster TZ pour les voyages ou d'autoriser des heures de grâce (aussi agréables que ces choses semblent).

Un bug qui rend inutile l'incroyable défi 100DaysOfCode

Voici mon profil : https://www.freecodecamp.org/dardandmr

Mes 69 jours de séquence sont brisés sans raison

@QuincyLarson s'il vous plaît mon frère, qu'est-ce que c'est, et pouvons-nous inverser cela ?!
J'ai soumis le travail deux heures après minuit, je ne pense pas qu'il s'agisse d'une erreur de fuseau horaire, même si c'est comment est-il possible que tant de personnes ici à FCC n'aient pas corrigé cette erreur ?

Je suis vraiment déçu, j'étais tellement motivé avec ce défi 100DaysOfCode, et j'ai terminé tous les projets front-end et tout le reste, je n'ai que 4 algorithmes avancés à résoudre pour réclamer mon certificat front-end, je suis resté tellement d'heures sans dormir juste pour continuer la séquence...

Capture d'écran

100DaysOfCode Challenge, si un tel bug persiste, cela ne ferait que nous ruiner le moral.

@JohnnyCheung1989 regarde mes progrès depuis que le bug a ruiné ma séquence :(

Il semble que les défis vidéo ne soient pas non plus comptabilisés dans les séquences, mais comptés dans la carte thermique.

Je suis un débutant surtout avec le code de production. Je ne sais pas si cet algo créerait trop de frais généraux ... Mais puisque la carte thermique semble fonctionner correctement, pourquoi l'algo pour les séquences ne peut-il pas simplement vérifier la carte thermique pour les jours colorés en vert ou aller dans l'autre sens et vérifier les lacunes grises et revenir une valeur comme vérifier si l'élément est '#cccc' etc.. si oui, cassez la séquence
Supprimez tous les fuseaux horaires et mathématiques de la logique de séquence actuelle et vérifiez simplement la carte thermique d'une manière ou d'une autre pour la couleur de l'élément ...
Si ! strie grise++ si strie d'arrêt grise alors vérifier si strie plus longue que la plus longue strie ?

Excusez-moi si cela a déjà été évoqué.

Je n'ai jamais vu la carte thermique inexacte mais mes stries sont bien... pas tellement.

Ou d'une manière ou d'une autre, mettez un indicateur dans le code de la carte thermique et les sorties de séquence ne peuvent pas le vérifier et le mettre à jour ?

@dverdin83
Je viens de regarder brièvement le code. Heatmap est un plugin, donc la modification du code de la heatmap ne doit pas être effectuée car il se brisera s'il est mis à jour. En ce qui concerne le comptage du vert, il semble que le plugin crée la couleur à la volée, vous devrez donc ajouter un rappel pour retarder le calcul.

Il vaudrait mieux vérifier la même chose que la carte thermique , c'est ce qui a été suggéré par

Clôture de ce problème en faveur de https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

Est-ce que quelqu'un sait quel fuseau horaire est utilisé par le compteur de séquences et la carte thermique ? Je viens de perdre une séquence de 74 jours même si j'ai terminé un défi à 15h45 KST (UTC +0900). La séquence ne montre qu'un jour, mais le carré d'aujourd'hui sur la carte thermique est de couleur verte, et sur la chronologie, le défi est enregistré comme étant terminé aujourd'hui également. Il semble que le compteur de séquences utilise un fuseau horaire, tandis que la carte thermique et la chronologie utilisent un deuxième fuseau horaire. Quelqu'un peut-il confirmer s'il vous plaît? C'est vraiment démoralisant car j'étais fier de voir le nombre augmenter chaque jour et de pouvoir le partager avec mes amis, ma famille et des employeurs potentiels.

Je comprends que ce n'est peut-être pas une priorité élevée à corriger, donc au moins connaître les règles de la séquence m'aiderait vraiment à comprendre et à ajuster mon codage en conséquence.

Cité de @sgrayme https://github.com/freeCodeCamp/freeCodeCamp/issues/7925#issuecomment -361716788

J'ai observé comment les défis sont enregistrés au cours de la semaine dernière et j'ai essentiellement vu les dates et les séquences de défi passer par UTC et la carte thermique utilise l'EST ...