Freecodecamp: La racha sigue siendo inexacta para muchos campistas

Mi primera vez con contribuciones de código abierto, pero me encantaría ver si estoy preparado para la tarea.

Este sigue siendo un problema sobre el que recibimos muchas quejas.

@QuincyLarson Estoy interesado en ayudar

@sorlovsky ¡Impresionante! ¡Estamos interesados ​​en tu ayuda! Vea si puede escribir algunas pruebas alrededor de esto que cubran varios casos extremos. Parece funcionar el 99,9% del tiempo, pero hay algunas situaciones en las que no funciona y no estoy muy seguro de por qué.

Analicé esto un poco y posiblemente se deba al hecho de que está contando las rachas actuales de Desafíos y no las otras actividades (Proyectos o Algoritmos). También es posible que sean zonas horarias como se indicó anteriormente. Voy a investigar el problema y ver si puedo hacer relaciones públicas si nadie más lo logra.

¿Puede alguien avisarme si me falta algo aquí?

const daysBetween = 1.5; se puede actualizar a const daysBetween = 2; porque la lógica en las siguientes funciones siempre dice menor que daysBetween y no menor o igual que daysBetween. Esto significa que habrá cobertura desde las 12:00:00 a. M. Un día hasta las 11:59:59 p. M. Del siguiente. La lógica de la zona horaria también debería ser la misma.

Cambiar de día entre a 2 significa que se rompen dos pruebas, lo cual se puede arreglar pero primero tendría que aprender un poco cómo funcionan las pruebas.

La opción alternativa sería establecer daysBetween en 1.99 para que todas las pruebas pasen, pero tendría la posibilidad de perder la racha por 7 minutos y 12 segundos.

@donofriov, por favor, adelante. No pude entender por qué no funcionó.

@donofriov muchas gracias por el análisis, y es bueno saber que está interesado en investigar esto. Aquí hay otro problema relacionado https://github.com/freeCodeCamp/freeCodeCamp/issues/7468 (tiene que ver con el estado de inicio de sesión del usuario)

Si necesita ayuda, contáctenos en la sala de chat.

Primero tendría que aprender un poco cómo funcionan las pruebas.

Las pruebas estan en
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

Bueno, esta estructura es un poco complicada de lo habitual. Estaré por aquí si necesitas resolver las cosas.

¡Feliz arreglo!

@donofriov Sí, si crees que eso lo solucionará, genial. Aumente daysBetween a 2 y actualice las pruebas para que pasen.

Si puede, vea si puede agregar alguna cobertura de prueba adicional para asegurarse de que esto aborde los diversos casos de esquina que han surgido (hay varios problemas relacionados con las rachas).

Gracias por su tiempo y atención a esto. Este ha sido un problema importante durante meses y es una fuente de muchas quejas, por lo que solucionarlo será enorme :)

El problema es que el cálculo de streak depende de la zona horaria. En una zona horaria, digamos que mis tres presentaciones son [Aug 5, Aug 6, Aug 7] . En otra zona horaria, esos mismos envíos podrían estar en [Aug 5, Aug 5, Aug 6] . El mapa de calor del calendario también depende de la zona horaria, y el mapa de calor siempre utiliza la zona horaria del cliente que ve la página en el navegador. Entonces, si queremos que streaks coincida con el mapa de calor, debemos usar la zona horaria del cliente en el cálculo. Eso es básicamente lo que hizo @LenaBarinova cuando este problema se solucionó en enero de 2016 con el número 6333. La solución fue que el navegador enviara la zona horaria del usuario cada vez que se presentaba un desafío. El servidor almacenaría la zona horaria y la usaría para calcular las rachas. Pero luego, en enero de 2017, hubo una gran refactorización que cambió la forma en que se envían los desafíos y la solución se eliminó . La lógica del lado del servidor todavía está ahí, es solo que el navegador ya no envía la zona horaria.

@Motardo Gracias por investigar esto. ¿ Estaría interesado en arreglar esto para que el @LenaBarinova vuelva a funcionar?

@QuincyLarson Después de echar otro vistazo y dormir, aquí están mis pensamientos:

Plan A
Creo que la vieja solución no era la ideal. Se requería que un usuario iniciara sesión para ver su propio perfil correctamente y aún mostraría inconsistencias al ver los perfiles de otros usuarios en otras zonas horarias.

Plan B (simple y directo, buena solución temporal)
Creo que una solución más simple y robusta es enviar a los clientes la zona horaria con cualquier solicitud para ver el perfil de cualquier usuario, y el servidor podría calcular las rachas en función de esa zona horaria. Entonces no importaría si el cliente inició sesión o cuyo perfil fue visto. Las rachas y el calendario siempre estarían sincronizados.

Plan C (refactorización complicada, posible hoja de ruta futura)
Probablemente la mejor solución sería no calcular las rachas en el servidor en absoluto. El servidor debe enviar las marcas de tiempo sin procesar al cliente y dejar que el cliente decida a qué día pertenece cada marca de tiempo y la duración de las rachas en función de la zona horaria local. Esto es exactamente lo que hacemos con los datos del mapa de calor del calendario para que siempre sea coherente.

Soy completamente nuevo en reaccionar y rxjs, y creo que el Plan C está fuera de mi alcance, pero estaría feliz de hacer un parche para el Plan B, y me encantaría escuchar otras ideas y sugerencias.

@Motardo Definitivamente estoy de acuerdo en que el Plan C tiene más sentido.

Dado que han pasado 15 días desde que publicaste esto, ¿has mejorado mucho con React y RXJS? Este podría ser un buen desafío para llevar los límites de sus habilidades de scripting del lado del cliente al siguiente nivel 😉

Hola. N.º 16071

Lo que hice:
Primero cambié el cálculo de la racha para usar 24 horas entre en lugar de 1,5 días entre. Luego tomé la diferencia en horas de startOf ('día') de la marca de tiempo anterior y la marca de tiempo actual y la comparé con hoursBetween para tener en cuenta los trabajos que se han realizado las últimas 24 horas en lugar del día anterior. (Suena igual pero probablemente valga la pena intentarlo)

Probablemente una mejor solución sería si permites al usuario establecer su propia zona horaria en la configuración y todo se calcula / configura utilizando esa zona horaria.

Editar: ¿Alguien sabe cómo usar / producir cuentas ficticias en localhost que tiene diferentes conjuntos de rachas?

Editar: No importa todo esto.

Intenté profundizar, descubrí que las inconsistencias entre el mapa de calor y las rayas posiblemente sean causadas por el mapa de calor. https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicay Creo que deberíamos permitir que los usuarios almacenen sus zonas horarias (con algunos valores predeterminados inteligentes) principalmente porque planeamos mantener la lógica del lado del servidor independiente de la interfaz, ya que planeamos hacer que la interfaz esté cada vez más alojada estáticamente.

@raisedadead Creo que debe haber una forma más sencilla de manejar esto en lugar de depender de los usuarios para establecer sus zonas horarias. Muchos de ellos usan VPN y viajan.

¿Podemos incorporar suficiente capacidad para que la racha no se rompa cuando alguien cambia de zona horaria? Creo que actualmente mantenemos la racha siempre que esté dentro de una ventana de 36 horas.

@QuincyLarson Podría estar equivocado, pero no creo que mantengamos la racha dentro de la ventana de 36 horas. Afaik the prepUniqueDays crea una matriz de marcas de tiempo que son 24, 48 y así sucesivamente entre horas y lo comparamos con betweenDays, que es de 1,5 días, pero la diferencia entre el valor de días únicos solo podría ser números enteros (1,2, ... n) por lo que realmente no tiene ningún decimal que se esté utilizando en el cálculo de rayas.

¿Cómo obtenemos req.user.timezone? Debido a que el maniquí no tiene la zona horaria como propiedad, const timezone = user && user.timezone ? user.timezone : 'UTC'; siempre está predeterminado en UTC. ¿Lo configuramos de acuerdo con la ubicación del usuario?

Si tenemos user.timezone, las rayas serían consistentes con user.timezone pero el mapa de calor solo siempre sería consistente con la zona horaria del cliente.

Diferentes escenarios con la configuración actual

si la zona horaria del usuario coincide con la zona horaria del cliente

• Las rayas y el mapa de calor serían precisos y consistentes.

si la zona horaria del usuario no coincide con la zona horaria del cliente (por ejemplo, VPN, ubicación / zona horaria incorrecta)

• Las rayas serían precisas con user.timezone, pero el mapa de calor probablemente no lo hará.

si user.timezone no está definido (el usuario no ha iniciado sesión o no ha establecido su ubicación / zona horaria)

• Las rachas serían inexactas, pero el mapa de calor seguirá siendo preciso con la zona horaria del cliente a menos que use una VPN. Creo que lo que podríamos hacer aquí es en lugar de usar UTC como predeterminado, también podríamos usar la zona horaria del cliente para hacer coincidir el mapa de calor.

_PS: Podría estar equivocado, así que siéntete libre de corregirme_

@ Kenneth-LJS Tenía la impresión de que permitimos 12 horas adicionales de margen de maniobra, pero eso puede haber cambiado. Si ha estado mirando detenidamente el código, confiaría en su comprensión de cómo encaja.

Con respecto a sus escenarios, está bien que el calendario esté ligeramente compensado. Muy pocos campistas han notado esto o se han quejado de ello. A los campistas no les importará mucho. Pero no está bien que se rompa la racha, eso es lo que ha provocado que tantos campistas escriban quejándose de este error.

Entonces, mi argumento sería en lugar de tratar de averiguar las zonas horarias y sincronizarlas, simplemente normalizamos el tiempo a EST, que es donde vive la mayoría de los estadounidenses, y agregamos un margen de 12 a 24 horas para reducir la probabilidad de que alguien termine inadvertidamente su tiempo. racha al viajar.

Hola, te escribo porque vi a @QuincyLarson comentar en esta publicación .

Soy un campista nuevo y tengo una "racha de 5 días" con actividades reconocidas en:
Ene18 - 5 artículos
Ene19 - 24 artículos
Ene20 - 16 artículos
Ene21 - 2 artículos
Ene22 - 7 artículos

Veo en la lectura anterior que hay una expectativa de que las fechas de "calendario completado" se compensen, pero mi racha muestra solo 1 día.

===
Nota al margen: gracias por el increíble trabajo. Este es mi quinto intento de aprender a codificar, ¡pero creo que este programa es el que me ayudará a superar el problema!

@kennethlumalicay Por favor, mire esto. ¿Alguna idea de qué podría estar causando el problema de @ApeCogs ?

@ApeCogs , ¿sabe a qué hora hizo cada desafío el 21 y 22 de enero? (Incluso estimaciones aproximadas) ¿Cuál es su zona horaria? ¿También usas VPN?

@kennethlumalicay - El 21 de enero habría sido alrededor de las 22:30 - 23:30 EST. El 22 de enero habría sido de 09:00 a 10:00 EST. A veces uso una VPN, pero es para trabajar y la región no cambia (este).

Tengo el problema. Por lo general, sucede cuando hago un desafío alrededor de las 22:00 CST - 24:00 CST. Aunque he perdido mi racha cuando lo hice el domingo alrededor de las 19:00 CST - 20:00 CST. Esto también suele suceder cuando tengo una racha de 7-8 días. No usar una VPN. Si hay algo que pueda hacer más para ayudar, hágamelo saber.

@ApeCogs Usé algunos datos ficticios pero parece que no puedo reproducirlos.

marcas de tiempo:

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)

Usé 24 y 25 en lugar de 21 y 22 para recrear tu "hoy" y "ayer".

resultado:

@mriel, ¿también perdiste tu racha actual? ¿Podría proporcionar una captura de pantalla más grande que contenga el mapa de calor y las rayas?

Reapertura, debido a la discusión en curso

@kennethlumalicay aquí está mi captura de pantalla:

La mayoría de las veces mis rachas anteriores han sido de 7-8 días. Al día siguiente haré una lección por la noche entre las 18:00 CST y las 22:00 CST. El día siguiente dirá que mi racha actual es de 1 día.

Comencé a llevar un registro de la racha actual, el día, la hora y qué desafío.

Aquí dice que hiciste algo el 20.

Pero aquí no hay nada en el 20.

Así que supongo que sus marcas de tiempo se muestran con la zona horaria incorrecta.

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

Entonces, si no ha iniciado sesión, el usuario sería nulo y la zona horaria sería 'EST'.
Incluso si ha iniciado sesión, no estoy realmente seguro de si user.timezone realmente existe porque no existe en los datos ficticios en mi base de datos local. Idk si la base de datos de fcc es diferente, pero como todavía está obteniendo la zona horaria incorrecta, es probable que todavía esté obteniendo 'EST'.
Supongo que esto siempre va a 'EST' de forma predeterminada.

~ Así que envié una posible solución cambiando 'EST' a

Acabo de hacer un desafío. Este es mi estado:
25/01/2018 20:41 PM CST Matrices inversas con .reverse

Observé cómo se registran los desafíos durante la última semana y básicamente vi que las fechas de los desafíos y la racha van por UTC y el mapa de calor está usando EST. Esto significa que otras personas en CST y yo debemos hacer los desafíos antes de las 6 p.m. para que se cuenten para el mismo día en todas las partes. Y si hago desafíos por la mañana un día y por la noche al día siguiente, adiós racha.

Solo un pensamiento, los programas de aprendizaje de idiomas que uso tienen una cuenta regresiva de horas restante visible junto a la información de la racha. Tener una nota que diga "completar las lecciones por ... para mantener la racha". sería igual de útil. Yo diría que obtener tiempos consistentes es la primera prioridad para el problema de la racha, pero informar a las personas sobre su fecha límite para el día sería más útil que preocuparse por ajustar TZ para viajar o permitir horas de gracia (tan bien como suenan esas cosas).

Un error que inutiliza el increíble 100DaysOfCode Challange

Aquí está mi perfil: https://www.freecodecamp.org/dardandmr

Mi racha de 69 días se ha roto sin motivo

@QuincyLarson por favor hermano, ¿qué es esto y podemos revertir esto?
He enviado el trabajo dos horas después de las 24:00, no creo que sea un error de zona horaria, aunque ¿cómo es posible que tanta gente aquí en FCC no haya solucionado este error?

Estoy realmente decepcionado, estaba tan motivado con este desafío de 100DaysOfCode, y he terminado todos los proyectos de front-end y todo lo demás, solo tengo 4 algoritmos avanzados para resolver para reclamar mi certificado de front-end, me quedé tantas horas sin dormir solo para mantener la racha ...

Captura de pantalla

100DaysOfCode Challange, si tal error persiste, nos arruinaría la moral.

@ JohnnyCheung1989 mira mi progreso desde que el error arruinó mi racha :(

Parece que los desafíos de video tampoco se cuentan para las rayas, sino que se cuentan en el mapa de calor.

Soy un principiante, especialmente con el código de producción. No sé si este algoritmo crearía demasiada sobrecarga ... Pero dado que el mapa de calor parece estar funcionando bien, ¿por qué no puede el algoritmo para la racha simplemente verificar el mapa de calor para los días de color verde o ir al revés y verificar si hay espacios grises y regresar? un valor como comprobar si el elemento es '#cccc', etc. si es así, romper la racha
Elimine toda la zona horaria y las matemáticas de la lógica de racha actual y solo verifique el mapa de calor de alguna manera para ver el color en el elemento ...
Si ! racha gris ++ si la racha gris se detiene, verifique si la racha es más larga que la racha más larga?

Perdóname si esto se ha mencionado antes.

Nunca he visto que el mapa de calor sea inexacto, pero mis rayas están bien ... no tanto.

¿O de alguna manera poner una bandera en el código del mapa de calor y las salidas de la racha no pueden verificarlo y actualizarlo?

@ dverdin83
Solo miré brevemente el código. Heatmap es un complemento, por lo que no se debe editar el código del mapa de calor, ya que se romperá si se actualiza. En cuanto a contar el verde, parece que el complemento crea el color sobre la marcha, por lo que deberá agregar una devolución de llamada para retrasar el cálculo.

Sería mejor verificar lo mismo que hace el mapa de calor, eso es lo que sugirió Motardo _ (ver su comentario del 2 de septiembre de 2017 - Plan C) _.

Cerrando este problema a favor de https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

¿Alguien sabe qué zona horaria utiliza el contador de rachas y el mapa de calor? Acabo de perder una racha de 74 días a pesar de que terminé un desafío a las 15:45 PM KST (UTC +0900). La racha muestra solo 1 día, pero el cuadrado de hoy en el mapa de calor es de color verde, y en la línea de tiempo el desafío también se registra como completado hoy. Parece que el contador de rachas está usando una zona horaria, mientras que el mapa de calor y la línea de tiempo están usando una segunda zona horaria. ¿Alguien puede confirmar? Es realmente desmoralizador ya que me enorgullecía ver crecer el número todos los días y poder compartirlo con amigos, familiares y empleadores potenciales.

Entiendo que puede que no sea una alta prioridad corregirlo, por lo que al menos conocer las reglas de la racha realmente me ayudaría a comprender y ajustar mi codificación en consecuencia.

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

Observé cómo se registran los desafíos durante la última semana y básicamente vi que las fechas de los desafíos y la racha van por UTC y el mapa de calor usa EST ...