O controle de versão é uma máquina do tempo que traduz retrospectiva comum em previsão valiosa

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


[Esteartigofoipublicadopelaprimeiravezem[Thisarticlewasfirstpublishedon R – Blog de vetor de vitória, e gentilmente contribuiu para os R-blogueiros]. (Você pode relatar um problema sobre o conteúdo desta página aqui)


Deseja compartilhar seu conteúdo com R-blogueiros? clique aqui se você tiver um blog ou aqui se não tiver.

Para projetos de ciência de dados, recomendo usar o controle de origem ou controle de versão e confirmar as alterações muito bom nível de granularidade. Isso significa verificar o código possivelmente quebrado e as mensagens de confirmação possivelmente fracas (portanto, ao trabalhar em um projeto compartilhado, você pode querer uma ramificação privada ou um segundo repositório de controle de origem).

Por favor, continue lendo para nossa justificativa.

O problema que estamos enfrentando é: Cerca de Chesterton

Na questão de reformar as coisas, distinto de deformar, existe um princípio claro e simples; um princípio que provavelmente será chamado de paradoxo. Existe nesse caso uma determinada instituição ou lei; digamos, por uma questão de simplicidade, uma cerca ou portão erguido em uma estrada. O tipo mais moderno de reformador avança alegremente e diz: “Não vejo o uso disso; vamos esclarecer tudo. Para o qual o tipo mais inteligente de reformador fará bem em responder: “Se você não vê o uso, certamente não vou deixar você esclarecer. Vá embora e pense. Então, quando você puder voltar e me dizer que vê o uso, posso permitir que você o destrua.

Como isso aparece nos projetos de software ou de ciência de dados é frequentemente: as etapas de “limpeza inofensiva” interrompem seu projeto e você não o detecta até muito mais tarde.

A parábola da cerca de Chesterton sempre me divertiu, pois não tem um exemplo real de consequências adversas (embora eu sempre me lembre dela como exemplo). Na verdade, ninguém que faz um trabalho real é cuidadoso o suficiente ou tem conhecimento suficiente para evitar sempre remover a cerca de Chesterton por uma questão de previsão. No entanto, em retrospectiva, muitas vezes você pode ver o problema. Felizmente: o controle de versão é uma máquina do tempo que traduz uma retrospectiva comum em uma previsão mais valiosa.

Leia Também  Privacidade de dados na era do COVID-19

Então, vamos adicionar um pequeno exemplo de ciência de dados.

Recentemente, estive brincando com um projeto Keras / Tensorflow, que provavelmente escreverei mais tarde. Em algum momento, eu “limpei” o código substituindo uma fatia desagradável do tensor do formulário x[:, (j-1):j] com uma indexação de aparência mais natural x[:, j-1]. O que negligenciei é que o Tensorflow usa os detalhes da classificação / forma do tensor para registrar a diferença entre uma única coluna de dados e um quadro de dados que contém uma única coluna de dados (uma pequena distinção que é muito importante manter em projetos de ciência de dados). Essa “limpeza” quebrou o código de maneira não sinalizadora, pois regras adicionais de remodelagem do Tensorflow permitiram que o cálculo avançasse com valores incorretos. Algumas mudanças depois, refiz a avaliação do projeto e o desempenho do modelo caiu vertiginosamente. Eu não tinha ideia de por que um modelo que recentemente teve um bom desempenho agora não funcionou.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

A graça salvadora foi: eu havia cometido uma granularidade muito fina, mesmo durante a “limpeza de código inofensivo” usando o controle de versão git. Exatamente o conjunto de confirmações que você teria vergonha de compartilhar. Esses compromissos “inúteis” me salvaram. Eu poderia rapidamente cortar a busca pelo envenenamento. O conceito é ilustrado no capítulo 11 da Practical Data Science com R (confira!) Da seguinte forma:

Githistory

Agora, o git é um pouco de “quando você anda com ele, não precisa ter medo de nenhum outro” protetor. No processo de encontrar a alteração final, eu acidentalmente fiz o check-out do repositório para uma determinada versão (em vez de um arquivo específico), causando o temido problema “git Detached HEAD” no meu repositório de controle de origem. Mas a vitória foi: esse era um problema comum de pesquisa com correções conhecidas. Fiquei feliz em trocar o meu mistério “por que isso parou de funcionar sem motivo” para a tarefa de manutenção de rotina de corrigir o repositório depois de encontrar a causa raiz.

Leia Também  Conferência EARL 2020 - Por que você deve enviar um resumo

E essa é a natureza do controle de origem ou controle de versão: são várias as considerações técnicas que acabam sendo um resultado positivo, pois podem evitar problemas piores.

Após a observação: uma parábola muito pior e mais memorável sobre o valor do controle de origem é a seguinte. Lembro-me de um mestrado em candidato a matemática na UC Berkeley perdendo um rascunho inteiro de sua dissertação ao digitar acidentalmente “rm * .log” ao invés de “rm *.log”Para limpar arquivos de efeito colateral em seu diretório de trabalho. O espaço extra permitiu ao comando remover remover arquivos importantes. Sem controle de origem, isso atrasava um mês.

Para uma boa palestra sobre a inevitabilidade dos erros (e, portanto, por que precisamos mitigá-los, pois eles não podem ser totalmente eliminados), recomendo a apresentação “Quem destruiu a ilha das três milhas” do desenvolvedor líder.



Se você chegou até aqui, por que não inscreva-se para atualizações do site? Escolha seu sabor: e-mail, Twitter, RSS ou facebook …



cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br