Freecodecamp: Streak ainda é impreciso para muitos campistas

Minha primeira vez com contribuições de código aberto, mas adoraria ver se estou pronto para a tarefa.

Este ainda é um problema sobre o qual recebemos muitas reclamações.

@QuincyLarson estou interessado em ajudar

@sorlovsky Awesome! Estamos interessados ​​na sua ajuda! Veja se você pode escrever alguns testes em torno disso que cobrem vários casos extremos. Parece funcionar 99,9% do tempo, mas há algumas situações em que não funciona e não tenho certeza do porquê.

Analisei um pouco isso e pode possivelmente ser causado pelo fato de que está contando sequências atuais de Desafios e não as outras atividades (Projetos ou Algoritmos). Também é possível que sejam os fusos horários indicados acima. Vou analisar o problema e ver se consigo fazer RP, se ninguém mais fizer isso.

Alguém pode me avisar se estiver faltando alguma coisa aqui.

dias constantes Entre = 1,5; pode ser atualizado para const daysBetween = 2; porque a lógica nas funções a seguir sempre diz menos que diasentre e não menor ou igual a diasentre. Isso significa que haverá cobertura das 12h00 de um dia até as 23h59:59 do dia seguinte. A lógica do fuso horário também deve permanecer a mesma.

Alterar dias entre para 2 significa que dois testes são interrompidos, o que pode ser consertado, mas eu teria que aprender um pouco como os testes funcionam primeiro.

A opção alternativa seria definir daysBetween para 1,99 para que todos os testes passassem, mas você teria a possibilidade de perder a sequência por 7 minutos e 12 segundos.

@donofriov vá em frente Eu não consegui descobrir por que não funcionou

@donofriov muito obrigado pela análise e ótimo saber que você está interessado em investigar isso. Aqui está outro problema relacionado https://github.com/freeCodeCamp/freeCodeCamp/issues/7468 (tem a ver com o estado de login do usuário)

Se precisar de ajuda, entre em contato conosco no chat.

Eu teria que aprender um pouco como os testes funcionam primeiro.

Os testes estão em
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/server/utils/user-stats.test.js

Bem, esta é uma estrutura um pouco complicada do que o normal. Estarei por perto se você precisar resolver algumas coisas.

Boa correção!

@donofriov Sim - se você acha que isso vai consertar, ótimo. Bata daysBetween para 2 e atualize os testes para que eles passem.

Se você puder, veja se você pode adicionar alguma cobertura de teste adicional para ter certeza de que está abordando os vários casos pontuais que surgiram (há vários problemas relacionados a listras).

Obrigado pelo seu tempo e atenção a isso. Este tem sido um grande problema por meses e é uma fonte de muitas reclamações, então consertar isso será muito importante :)

O problema é que o cálculo de streak depende do fuso horário. Em um fuso horário, digamos que meus três envios sejam [Aug 5, Aug 6, Aug 7] . Em outro fuso horário, esses mesmos envios podem ser em [Aug 5, Aug 5, Aug 6] . O mapa de calor do calendário também depende do fuso horário e sempre usa o fuso horário do cliente que visualiza a página no navegador. Portanto, se quisermos que streaks corresponda ao mapa de calor, precisamos usar o fuso horário do cliente no cálculo. Isso é basicamente o que @LenaBarinova fez quando esse problema foi corrigido em janeiro de 2016 com o # 6333. A solução era fazer com que o navegador enviasse o fuso horário do usuário sempre que um desafio fosse enviado. O servidor armazenaria o fuso horário e o usaria para calcular as faixas. Mas então, em janeiro de 2017, houve uma grande refatoração que mudou a forma como os desafios são enviados, e a correção foi removida . A lógica do lado do servidor ainda está lá, é só que o navegador não está mais enviando o fuso horário.

@Motardo Obrigado por investigar isso. Você estaria interessado em consertar isso para que a correção de @LenaBarinova funcione novamente?

@QuincyLarson Depois de dar outra olhada e dormir sobre isso, aqui estão meus pensamentos:

Plano A
Acho que a solução antiga não era a ideal. Exigia que um usuário estivesse logado para visualizar seu próprio perfil corretamente e ainda mostraria inconsistências ao visualizar perfis de outros usuários em outros fusos horários.

Plano B (simples e direto, boa correção temporária)
Acredito que uma solução mais simples e robusta seja enviar aos clientes o fuso horário com qualquer solicitação de visualização do perfil de algum usuário, e o servidor poderá calcular as raias com base nesse fuso horário. Assim, não importaria se o cliente estava logado ou cujo perfil foi visualizado. Os streaks e o calendário estariam sempre sincronizados.

Plano C (refatoração complicada, possível roteiro futuro)
Provavelmente, a melhor solução seria não calcular faixas no servidor. O servidor deve enviar os carimbos de data / hora brutos ao cliente e deixar que o cliente decida a qual dia cada carimbo de data / hora pertence e por quanto tempo as faixas são baseadas no fuso horário local. Isso é exatamente o que fazemos com os dados do mapa de calor do calendário para que sejam sempre consistentes.

Eu sou completamente novo para reagir e rxjs, e acho que o Plano C está fora do meu alcance, mas ficaria feliz em fazer um patch para o Plano B e adoraria ouvir outras idéias e sugestões.

@Motardo Eu definitivamente concordo que o Plano C faz mais sentido.

Considerando que já se passaram 15 dias desde que você postou isso, você melhorou muito com o React e o RXJS? Este pode ser um bom desafio para empurrar os limites de suas habilidades de script do lado do cliente para o próximo nível 😉

Oi. # 16071

O que eu fiz:
Primeiro mudei o cálculo de sequência para usar 24 horas entre em vez de 1,5 dias entre. Em seguida, peguei a diferença em horas de startOf ('day') do carimbo de data / hora anterior e atual e comparei-o com hoursBetween para contabilizar os trabalhos que foram feitos nas últimas 24 horas em vez do dia anterior. (Parece o mesmo, mas provavelmente vale a pena tentar)

Provavelmente, uma solução melhor seria permitir que o usuário defina seu próprio fuso horário nas configurações e tudo é calculado / definido usando esse fuso horário.

Edit: Alguém sabe como usar / produzir contas fictícias em localhost que tem diferentes conjuntos de faixas?

Edit: Esqueça tudo isso.

Tentei cavar mais fundo, descobri que as inconsistências entre o mapa de calor e as listras são possivelmente causadas pelo mapa de calor. https://github.com/wa0x6e/cal-heatmap/issues/122

@kennethlumalicay Acredito que devemos permitir que os usuários armazenem seus fusos horários (com alguns padrões inteligentes) principalmente porque planejamos manter a lógica do lado do servidor agnóstica do front-end, já que planejamos torná-lo cada vez mais hospedado estaticamente.

@raisedadead Acho que deve haver uma maneira mais simples de lidar com isso, em vez de depender dos usuários para definir seus fusos horários. Muitos deles usam VPNs e viagens.

Podemos construir recursos suficientes para que a seqüência não seja interrompida quando alguém muda de fuso horário? Acho que atualmente sustentamos a seqüência, contanto que esteja dentro de uma janela de 36 horas.

@QuincyLarson Posso estar errado, mas não acho que manteremos a seqüência dentro de uma janela de 36 horas. Afaik, o prepUniqueDays cria uma matriz de carimbos de data / hora que são 24, 48 e assim por diante entre as horas e comparamos com betweenDays, que é 1,5 dias, mas a diferença entre o valor único de dias só poderia ser números inteiros (1,2, ... n), portanto ele realmente não tem nenhum decimal que está sendo usado no cálculo de faixas.

Como obtemos req.user.timezone? Como a dummy não tem fuso horário como propriedade, const timezone = user && user.timezone ? user.timezone : 'UTC'; sempre padrão para UTC. Nós o configuramos de acordo com a localização do usuário?

Se tivermos user.timezone, os streaks seriam consistentes com user.timezone, mas o mapa de calor sempre seria consistente com o fuso horário do cliente.

Cenários diferentes com a configuração atual

se o fuso horário do usuário corresponde ao fuso horário do cliente

• As listras e o mapa de calor seriam precisos e consistentes.

se o fuso horário do usuário não corresponder ao fuso horário do cliente (por exemplo, VPN, local / fuso horário incorreto definido)

• As listras seriam precisas com user.timezone, mas o mapa de calor provavelmente não.

se user.timezone for indefinido (o usuário não está conectado ou não definiu sua localização / fuso horário)

• As listras seriam imprecisas, mas o mapa de calor ainda será preciso com o fuso horário do cliente, a menos que ele use uma VPN. Acho que o que poderíamos fazer aqui é, em vez de usar UTC como padrão, poderíamos usar o fuso horário do cliente também para corresponder ao mapa de calor.

_PS: Posso estar errado, sinta-se à vontade para me corrigir._

@Kenneth-LJS Fiquei com a impressão de que permitimos 12 horas extras de liberdade, mas isso pode ter mudado. Se você está examinando o código de perto, confio em sua compreensão de como ele se encaixa.

Em relação aos seus cenários, não há problema em que o calendário esteja ligeiramente deslocado. Muito poucos campistas notaram ou reclamaram disso. Os campistas não vão se importar muito. Mas não é certo que a seqüência seja interrompida - é isso que fez com que tantos campistas escrevessem reclamando sobre esse bug.

Portanto, meu argumento seria, em vez de tentar descobrir os fusos horários e sincronizá-los, apenas normalizamos o horário para EST - que é onde a maioria dos americanos vive - e adicionamos 12 a 24 horas de folga para reduzir a probabilidade de alguém encerrar inadvertidamente seu streak ao viajar.

Olá, estou escrevendo porque vi @QuincyLarson comentar neste post .

Sou um campista novo e tenho uma "sequência de 5 dias" em andamento, com atividades reconhecidas em:
18 de janeiro - 5 itens
19 a 24 itens
20 de janeiro - 16 itens
21 de janeiro - 2 itens
22 de janeiro - 7 itens

Vejo pela leitura acima que há uma expectativa de que as datas de "calendário concluído" sejam compensadas, mas minha seqüência mostra apenas 1 dia.

===
Nota lateral - obrigado pelo excelente trabalho. Esta é minha quinta tentativa de aprender a programar, mas acho que este programa é o que me ajudará a superar o obstáculo!

@kennethlumalicay Por favor, dê uma olhada nisso. Alguma ideia do que pode estar causando o problema do @ApeCogs ?

@ApeCogs você sabe a que horas você fez cada desafio nos dias 21 e 22 de janeiro? (Até estimativas aproximadas) Qual é o seu fuso horário? Você também usa VPN?

@kennethlumalicay - 21 de janeiro seria por volta das 22:30 - 23:30 EST. O dia 22 de janeiro seria das 9h às 10h EST. Eu uso VPN às vezes, mas é para trabalho e a região não muda (leste).

Estou tendo o problema. Geralmente acontece quando eu faço um desafio por volta das 22:00 CST - 24:00 CST. Embora eu tenha perdido minha seqüência quando fiz isso no domingo, por volta das 19:00 CST - 20:00 CST. Isso também costuma acontecer quando estou em torno de uma seqüência de 7 -8 dias. Não usando VPN. Se houver algo que eu possa fazer para ajudar, por favor me avise.

@ApeCogs Eu usei alguns dados fictícios, mas não consigo reproduzi-los.

timestamps:

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)

Usei 24 e 25 em vez de 21 e 22 para recriar seu "hoje" e "ontem".

resultado:

@mriel você perdeu sua

Reabertura, por causa de uma discussão em andamento

@kennethlumalicay aqui está uma minha captura de tela:

Na maioria das vezes, minhas sequências anteriores foram de 7 a 8 dias. No dia seguinte, farei uma aula à noite entre 18:00 CST e 22:00 CST. No dia seguinte, ele dirá que minha sequência atual é de 1 dia.

Comecei a manter um registro da seqüência atual, dia, hora e que desafio.

Aqui diz que você fez algo no dia 20.

Mas aqui não há nada no 20.

Portanto, estou assumindo que seus carimbos de data / hora estão sendo exibidos com o fuso horário errado.

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

Portanto, se você não estiver conectado, o usuário será nulo e o fuso horário será 'EST'.
Mesmo se você estiver conectado, não tenho certeza se user.timezone realmente existe porque não existe nos dados fictícios em meu banco de dados local. Identifique se o banco de dados da FCC é diferente, mas como você ainda está obtendo o fuso horário errado, provavelmente ainda está recebendo 'EST'.
Presumo que isso sempre vá para 'EST' por padrão.

~ Então, enviei uma possível correção alterando 'EST' para moment.tz.guess () . ~

Acabei de fazer um desafio. Este é o meu status:
25/01/2018 20:41 PM CST Reverse Arrays com .reverse

Observei como os desafios são registrados durante a última semana e basicamente vi que as datas dos desafios e as sequências estão passando pelo UTC e o mapa de calor está usando EST. Isso significa que eu e outras pessoas na CST precisamos fazer os desafios antes das 18h para serem contados para o mesmo dia em todas as peças. E se eu fizer desafios pela manhã em um dia e à noite no outro, adeus.

Só para pensar, os programas de aprendizado de idiomas que uso têm uma contagem regressiva de horas restantes visível ao lado das informações da seqüência. Tendo uma nota dizendo "complete as lições até ... para manter a seqüência." seria tão útil. Eu consideraria obter horários consistentes a primeira prioridade para o problema de seqüência, mas deixar as pessoas saberem o prazo final do dia seria mais útil do que se preocupar em ajustar o TZ para viagens ou permitir horas de tolerância (por mais legal que pareça).

Um bug que torna o incrível 100DaysOfCode Challange inútil

Aqui está meu perfil: https://www.freecodecamp.org/dardandmr

Meu 69 Dias de Sequência está quebrado sem motivo

@QuincyLarson por favor mano, o que é isso, podemos reverter isso ?!
Já submeti o trabalho duas horas depois das 24:00, não acho que seja um erro de Fuso Horário, mesmo que seja como é possível que tanta gente aqui no FCC não tenha corrigido este erro?

Estou muito desapontado, fiquei tão motivado com este Challange 100DaysOfCode, e terminei todos os projetos de front-end e tudo o mais, tenho apenas 4 algoritmos avançados para resolver para reivindicar meu certificado de front-end, fiquei tantas horas sem dormir apenas para manter a seqüência ...

Captura de tela

100DaysOfCode Challange, se esse bug persistir, isso apenas nos arruinaria de moral.

@ JohnnyCheung1989 veja meu progresso desde que o bug arruinou minha sequência :(

Parece que os desafios do vídeo também não são contados para sequências, mas são contados no mapa de calor.

Sou um iniciante principalmente com código de produção. Não sei se este algo criaria muita sobrecarga ... Mas já que o mapa de calor parece estar funcionando bem, por que o algoritmo para streak não pode apenas verificar o mapa de calor para dias de cor verde ou ir para o outro lado e verificar se há lacunas em cinza e retornar um valor como verificar se o elemento é '#cccc' etc.
Remova todo o fuso horário da lógica de sequência atual e matemática todos juntos e apenas verifique o mapa de calor de alguma forma para a cor no elemento ...
Se ! faixa cinza ++ se a faixa cinza parar, verifique se a faixa é mais longa do que a faixa mais longa?

Perdoe-me se isso já foi mencionado antes.

Nunca vi o mapa de calor impreciso, mas minhas listras estão boas ... nem tanto.

Ou de alguma forma coloque um sinalizador no código do mapa de calor e as saídas de sequência não podem verificá-lo e atualizá-lo?

@ dverdin83
Eu apenas olhei brevemente o código. O mapa de calor é um plugin, portanto, a edição do código do mapa de calor não deve ser feita, pois ele quebrará se for atualizado. Quanto à contagem do verde, parece que o plugin cria a cor na hora, então você precisaria adicionar um callback para atrasar o cálculo.

Seria melhor conferir a mesma coisa que o mapa de calor faz, é o que foi sugerido por Motardo _ (ver seu comentário em

Fechando este problema em favor de https://github.com/freeCodeCamp/freeCodeCamp/issues/17299

Alguém sabe qual fuso horário é usado pelo contador de sequência e o mapa de calor? Acabei de perder uma sequência de 74 dias, embora tenha terminado um desafio às 15:45 KST (UTC +0900). A seqüência mostra apenas 1 dia, mas o quadrado de hoje no mapa de calor é verde e na linha do tempo o desafio é registrado como concluído hoje também. Parece que o contador de sequência está usando um fuso horário, enquanto o mapa de calor e a linha do tempo estão usando um segundo fuso horário. Alguém pode confirmar? É realmente desmoralizante, pois eu estava orgulhoso de ver o número crescer a cada dia e de poder compartilhar isso com amigos, família e empregadores em potencial.

Eu entendo que pode não ser uma alta prioridade para corrigir, então pelo menos conhecer as regras da seqüência realmente me ajudaria a entender e ajustar minha codificação de acordo.

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

Observei como os desafios são registrados durante a última semana e basicamente vi que as datas dos desafios e as sequências estão passando pelo UTC e o mapa de calor está usando EST ...