Git e a dificuldade em renomear um arquivo

Um problema que sempre acontece um dia quando a gente usa o git.

Anúncios

Quem trabalha com Git ou usa ele em casa, provavelmente já teve esse problema.

Quer dizer, existe alguns requisitos pra isso acontecer… Primeiro você não pode usar linux (não me odeie, eu uso linux em casa!) ou seja, isso só costuma acontecer no Mac (Eu uso no trabalho) e no Windows.

O problema é relativamente simples, você renomeia um arquivo, mas você só altera as letras maiúsculas e minúsculas, por exemplo, você pega o seu arquivo QuitacaoParcialDECompras.java e altera para QuitacaoParcialdECompras.java

Pronto! Ai você comita e segue a vida. Você não vai ter nenhum problema até que baixe esse projeto novamente ou que outra pessoa de um pull na  máquina dela.

“Angeliski, se tá bricando né? Porque isso daria problema?”

O que acontece é que o git por padrão tem uma configuração de case insensitive… Isso quer dizer que pra ele TESTE.java, teste.java, TesTe.java, TEsTe.java são a mesma coisa. E isso é um problema, porque quando você altera o nome do arquivo ele não salva essa alteração… O que resulta num problema no próximo pull que for dado, já que você tem um arquivo com o nome errado e acha que ele está certo. Normalmente em projetos Java isso dá problema, por conta da estrutura de pacotes que a linguagem usa (Porque isso se aplica a nome de pastas também).

 “Mas como eu resolvo isso? Tem algum jeito?” 

A primeira vez que eu me deparei com esse problema eu resolvi da maneira mais porca simples que se possa imaginar. Mudei o nome do arquivo para uma coisa aleatória como A.java, fiz um commit, depois alterei o nome do arquivo para o que eu realmente queria, QuitacaoParcialdECompras.java. Só que isso sempre me incomodou, parece uma solução extremamente gambiarrenta grosseira. Depois de umas pesquisas, achei na documentação do git a solução:

core.ignoreCase

If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds “makefile” when Git expects “Makefile”, Git will assume it is really the same file, and continue to remember it as “Makefile”.

The default is false, except git-clone(1) or git-init(1) will probe and set core.ignoreCase true if appropriate when the repository is created.

 Nem preciso dizer que eu chorei pulei de alegria não? O que acontece é simples, apesar da propriedade core.ignoreCase ser false por padão o git-clone faz o favor de colocar ela como padrão quando é executado. Isso ai atrapalha tudo! Mas uma vez que a gente sabe qual é o problema é simples de resolver:
git config --global core.ignorecase false

 

Duvidas? gostou? Me acha um idiota?

Comenta ai!!

Angeliski

As mentiras que você conta para não testar

Um texto sobre as desculpas mais frequentes para não testar.

Hoje o post vai ser sobre testes, uma das coisas mais importantes de todas quando estamos falando de software funcionando.

Eu mudei só uma coisinha

A primeira mentira que a gente sempre conta é a da alteração pequena.

“Poxa vida Angeliski,eu só tirei aquele if que estava errado”

O ponto é exatamente esse. Você realiza uma alteração no código normalmente por dois motivos: ou porque tinha um bug, ou porque a regra de negócio mudou. Qualquer que seja o caso, quando você deixa de fazer o teste cria um brecha para falha não rastreada. O que garante que seu if vai continuar funcionando quando o Fulano do lado  fizer uma alteração?

Seu teste! Não importa o quão pequena seja a alteração que você fez, faça um teste que garanta que o que você mudou está e vai continuar funcionando.

A funcionalidade que eu fiz é pequena, não precisa disso

“Mas o meu botão só faz X

Você gastou uma hora fazendo uma funcionalidade, apenas um botão que faz X (Insira aqui a sua funcionalidade). Você quer garantir que o Fulano do lado (esse cara é terrivel né?) não quebre tudo? Se você fez o teste pode ir pra casa tranquilo, mas se não fez… Não importa o quão pequena uma funcionalidade (ou a correção de um bug) é a unica maneira que você garante o funcionamento dela é fazendo o teste. Se não houvesse a necessidade dela estar sempre funcionando, não teria porque desenvolver ela também.

Depois eu faço esse teste

“Deixa eu acabar isso aqui que eu já escrevo esse teste”

Muitas explicações podem ser dadas sobre porque o TDD melhora o código, a qualidade e tudo mais. Mas ele sem dúvida faz uma coisa que melhora tudo, ele “obriga” você a escrever o teste antes. Porque quando você deixa ele pra depois fica mais dificil. Hoje em dia os testes ainda não são vistos como uma entrega de valor (não é sempre assim, na Bluesoft por exemplo testes tem valor de negócio. Isso faz parte da cultura da empresa) e por não ter valor, quando aparece uma outra coisa o teste é deixado pra trás. E isso acaba deixando aquele código sem ser testado.

Esse código é muito difícil de testar

“Tá complicado de testar isso aqui”

Essa é simples: refatore. Um teste que te dá trabalho pra testar está te passando uma mensagem bem clara, o design dele poderia ser melhor. Quando você faz testes antes você consegue elaborar melhor o design (desde que você conhece design pra poder aplicar isso) mas se você faz seu teste depois precisa escutar o que o teste está dizendo, se ele tem uma complexidade muito grande para testar o feedback é sobre o design ruim do seu código.

Código legado não precisa testar

“O negocio tá ai faz dez anos e eu vou testar agora?”

Não é por estar a dez anos em produção que ele não precisa ser testado. Dois motivos podem ser vistos logo de cara,primeiro porque você continua desenvolvendo junto do código legado, então se ele não tem teste, cedo ou tarde um bug vai ser inserido. Segundo que ele estar lá a dez anos não significa que não haja bugs, só que ninguém pegou um bug ainda. Terceiro (Eu pensei em mais um agora) que quando você desenvolve um teste para o código legado precisa entender o que acontece ali, assim aprende mais sobre a funcionalidade melhorando sua skill sobre o negócio e sobre a capacidade de manutação. Eu sei que testar código legado é uma verdadeira batalha (em alguns casos), seja pelo alto acoplamento, seja pela complexidade da regra, mas é uma tarefa que resulta em ótimos ganhos.

Não fui eu que desenvolvi isso aqui

“Agora eu vou testar o código do Fulano do lado?”

Time. Equipe. Conjunto. Você pode chamar do que quiser, mas não muda o fato de que vocês todos estão com um mesmo propósito: tomar café construir software de qualidade. Não é porque o cara esqueceu do teste (ou não quis fazer) que você vai deixar a oportunidade de cubrir essa brecha passar. Não importa quem fez o furo no casco do navio, se você não tapar, todo mundo vai se afogar.


A ideia desse artigo é mostar que existem muitas coisas que pensamos que podem ser evitadas. Testar é bom, mas também é um hábito. É como correr, no começo você tem que se esforçar muito para correr poucos quilometros. Mas depois de um tempo praticando, corre muito em pouco tempo além de ser muito bom.

Duvidas? gostou? Me acha um idiota?

Comenta ai!!

Angeliski

O que a Programação Funcional pode fazer por você?

Uma visão simplificada de porque a programação funcional pode ser boa para a sua carreira.

Um dos tópicos da programação que se tem falando muito é a Programação Funcional… Algum de vocês devem estar se perguntando, que diabos é isso? Vamos começar esclarecendo algumas coisas então!

No meio da programação existem três paradigmas mais conhecidos, o primeiro comumente chamado de Programação estruturada. Isso se deve ao fluxo do programa, seguindo um fluxo continuo e ESTRUTURADO. O nosso amigo Cobol é um grande exemplo desse paradigma.
Temos também a Programação Orientada a Objetos (POO) que tem como sua premissa a criação de objetos, que contém propriedades (variáveis) e funções (métodos). O funcionamento do programa se dá com base nas iterações entre objetos, que vão chamando e interagindo entre si. O grande representante desse paradigma com certeza é o Java.
E não menos importante temos a Programação Funcional. A ideia desse paradigma é trabalhar principalmente com funções. Tudo se resume a funções que podem ser agrupadas ou combinadas para produzir um resultado. Ela se vale de muitos principios matematicos, o que as vezes pode ser complicado de entender. Como exemplo podemos citar o Haskell.

Essa é uma explicação muito simplificada dos paradigmas, visando mostrar a ideia principal por trás deles, cada um tem um conjunto maior de características e regras que definem ele como um todo. Dito isso podemos voltar ao nosso tópico principal, que é a Programação Funcional!

Porque ela tem sido tão falada ultimamente?

Acontece que cada vez mais os hardwares que temos hoje estão se limitando e a evolução está tomando um caminho de multi processamento, ou seja, os computadores cada vez mais estão sendo feitos com múltiplos núcleos de processamento para realizar muitas operações em paralelo. Só que gerenciar esses multi processamentos, também conhecidos como processamento multithread, exige um esforços cada vez maior e é ai que as linguagens funcionais se destacam no cenário atual.
Você ganha o processamento multithread de graça!

“Nossa Angeliski, que mágica é essa?”

Calma, não é mágica.

Acontece que muitos dos conceitos que estão definidos dentro do Paradigma Funcional permitem que as linguagens funcionais tenham um comportamento multithread sem muito esforço. Vamos a um exemplo, a Imutabilidade. Um dos conceitos que existe dentro do paradigma funcional é a imutabilidade, ou seja, um dado é criado e nunca mais será mudado até o fim da sua vida, ele é imutável.

“Mas como pode isso? Eu não posso mudar nada?”

É um pouco mais complexo que isso, além de existir algumas exceções….

Pausa Dramática no Texto


Sim, eu sei que existem muitas lacunas nas coisas que eu estou te dizendo, mas se você é alguém que não entende do que eu estou falando é está lendo isso, explicar essas lacunas vai te deixar completamente perdido. Se você entende, as lacunas já estão preenchidas. Então vamos por partes, eu vou explicar algumas coisas nesse texto e outras mais pra frente, em outros textos.


Fim da Pausa Dramática

Voltando a imutabilidade, suponha que você criou uma variável idade com o valor 10. Para todo o sempre a variável idade terá o valor 10. Mas e se eu quiser incrementar esse valor? Então uma nova variável, que pode ter o mesmo nome (para simplificar as coisas), será criada, com o valor 11 por exemplo. A imutabilidade garante que você pode usar essa variável em milhões de processamentos paralelos e que o valor será imutável. Se fosse no Java por exemplo, você teria que usar mecanismos de sincronização para que essa variável pudesse ser compartilhada em muitas threads sem nenhum problemas. Consegue enxergar a vantagem? Como a imutabilidade já faz parte do paradigma funcional você não precisa se preocupar com nada disso. Maravilha né?

Além disso, uma das coisas boas sobre aprender o paradigma funcional é a chance de pensar fora da caixa. Quando você aprende um novo paradigma, seja ele estruturado, orientado a objetos ou qualquer outra coisa, sua mente precisa pensar de uma maneira completamente diferente para resolver os mesmos problemas. Isso te permite crescer e aprender novas estratégias para resolução de problemas, novas ferramentas. Como programador você deve deixar de lado a bala de prata, cada caso tem uma solução mais adequada, hoje pode ser estruturada (Cobol vive até hoje nos bancos), amanhã pode ser programação funcional (Clojure é a linguagem principal da Nubank).

Você deve estar se perguntando se eu domino a Programação Funcional e a resposta é… não.

“O.o Mas como pode? Se faz maior propagando do negocio e não entende?”

Eu disse que não domino. Atualmente estou estudando sobre o assunto e por isso vim compartilhar a minha visão do porque aprender isso, mais pra frente vou tentar trazer alguns exemplos práticos.

Duvidas? gostou? Me acha um idiota?

Comenta ai!!

Angeliski