Erro chato usando Git no Windows

26.março.2009
De repente (bom, mais ou menos) meu git começou a exibir uma mensagem de erro ao dar commit:

You have some suspicious patch lines

WTF? Isso acontece depois de desabilitar a alteração de todas as quebras de linhas para CR-LF, tornando o fonte legível aos desenvolvedores que felizmente não estão usando Windows. Não sei porque o git passa a entender o sinal a mais de quebra de linha como sendo um espaço.

Depois de fuçar bastante, cheguei a um workaround para isso. Dentro do seu projeto, edite o arquivo .git/hooks/pre-commit e comente as linhas abaixo:

if (/\s$/) {
  bad_line("trailing whitespace", $_);
}

Pronto. Seja feliz e divirta-se, mesmo sendo um usuário de Windows cercado de Textpads por todos os lados.


Primeiros passos em Rails

16.fevereiro.2009
Ambiente devidamente configurado, fui eu meter as caras no Rails, framework para agilizar e divertir (???) o desenvolvedor, segundo informado no próprio site.

Algumas coisas me empurraram para o Rails, na ordem:

– Curiosidade: acredite, um programador sem curiosidade não é nada além de um repetidor de tarefas.
– Custo: desenvolvendo em Grails eu teria que contratar uma JVM dedicada para hospedar minha aplicação. Isso gerou um custo que deixou o cliente insatisfeito. Como quem manda é ele, fui obrigado a buscar uma solução mais econômica.
– Compatibilidade: Boa parte da aplicação já estava feita em Grails, então eu precisaria aproveitar o máximo possível. Devido ao fato do Grails ter sido criado usando o Rails como base, a migração teoricamente seria menos traumática.
– Produtividade: Esse é o ponto chave do Rails. Em termos de custo de hospedagem, pode ser comparado ao PHP, mas com certeza é uma ferramenta que provê muito mais recursos do que o dinossauro da Zend. Por exemplo, eu posso criar uma tela de cadastro no Rails utilizando poucas linhas de código, enquanto no PHP não existe nenhum suporte nativo a isso, apesar de ferramentas como PHPScaffold.

Tive alguns problemas chatos tentando utilizar o ActiveScaffold, mas esse é mais um projeto que sofre da clássica doença do “fiz, mas não testei”. Não funcionou de jeito nenhum com o Rails 2.2.2 que estou utilizando. Instalei o Streamlined e, por enquanto, tudo está caminhando tranquilamente.


O caso do byte perdido

14.janeiro.2009
Encontre o erro:

public class AnyInputStream extends InputStream {
  private byte getTheNextByteFromSomewhereElse(){
    // do something useful
  }

  public int read() {
    byte result = -1;
    if(!(hasAnyKindOfError() || wasTheLastByte())) {
      result = getTheNextByteFromSomewhereElse();
    }
    return result;
  }
}

A propósito, os nomes estranhos de métodos e da classe são meramente ilustrativos, para auxiliar na compreensão.

Qual o problema do fonte?

Quando você tem algum erro de leitura, ou chega ao final do conteúdo, recebe um -1 como resposta. Caso contrário, recebe o próximo byte e assim por diante. O problema ocorre quando você lê um byte de valor 255.

Se você jogar o valor 255 numa variável de typo byte, no Java, ele passa a ser -1, por questões de overflow e tamanho de variável. Ou seja: um byte válido passa a ser compreendido como final de arquivo ou erro de leitura.

Um simples teste teria pego esse erro ainda na mesa do programador e ele não teria chegado ao ambiente de produção.

Então eu pergunto:
– qual o problema em testar a droga da funcionalidade antes de entregar?
– qual o problema em gastar alguns segundos pensando antes de escrever?
– qual o problema em prestar atenção na merda que você, supondo que seja um desenvolvedor, está fazendo?

São essas coisas que me fazem achar que estou me preocupando em limpar os pés para entrar numa sala cheia de lama.