Tamanho vs Complexidade

Dei recentemente com este post:

Abbreviation, Accidental Complexity, and Abstraction

Que me levou a estes:

• Economizing can be penny-wise and pound foolish
• Finding the Signal-to-Noise Ratio in the Never-Ending Language Debate
• Are we Blub programmers?

Este último sobre um dos ensaios do Paul Graham.

Still a git...

Continuo com o git, andei a ver várias páginas no site do bazaar que não conhecia (o mercurial já conhecia) e tomei conhecimento a partir de um comentário no post anterior sobre o git, houve coisas que me afastaram do bazaar, por exemplo na página de comparação com o git diz "Directories are branches, not branch containers", uma das coisas que me agrada muito no git, o facto do bazaar ser feito em python que apesar de ser uma linguagem que me agrada bastante e que lhe permite um crescimento rápido em comparação com o git (se bem que pelos vistos numa direcção que não é a que mais me agrada) mas que digam o que disserem não terá a performance de uma aplicação em C.

Nos servidores como uso o gentoo basta fazer o emerge para ter uma versão 1.5.3.x do git, mas no meu desktop ubuntu ainda só está disponível a versão 1.5.2.x, como o git é uma aplicação em forte desenvolvimento, existem algumas features importantes na versão 1.5.3 que não estão disponíveis na 1.5.2, e como a documentação está bastante actualizada ao contrário do que pensei inicialmente (regra geral a documentação anda sempre umas versões atrás) estava sempre a esbarram em coisas que não funcionavam como descrito. Quando me apercebi do motivo fui tentar ver o que encontrava para ter a versão 1.5.3 no ubuntu e descobri esta página que explica como o fazer. No entanto a versão que é usada já não se encontra no servidor (http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.3.5-1.dsc). Por isso fui à directoria confirmar as versões disponíveis e descobri que a mais recente é a git-core_1.5.4~rc0-1.dsc mas esta falhou a compilação porque parece que necessita de um patch para conseguir passar um dos testes. Depois tentei a versão git-core_1.5.3.7-1.dsc que também falhou com um erro pouco explícito e sobre o qual não consegui descobrir muita coisa. Finalmente acabei por conseguir com a versão git-core_1.5.3.6-1.1.dsc, para aqueles que não precisem de integração com o SVN aconselho a usar a flag NO_SVN_TESTS pois estes testes demoram algum tempo (e num dos computadores onde compilei falhou um destes testes):

NO_SVN_TESTS=1 sudo dpkg-buildpackage -rfakeroot -us -uc

Já agora relembro que apesar de nos exemplos não haver "sudo"s pelo menos os passos 1, 4 e 5 precisam dele (no meu caso o passo 2 precisou pois estava a escrever em /usr/local/src).
No final é só instalar os .deb que são gerados.

Já agora aqui fica o vídeo da palestra que o Linus deu no google tech talk sobre o git:

You'r a... git

Já tentei várias vezes, todas elas sem grande sucesso utilizar algum sistema de controlo de versões. Existem vários motivos que levaram a que essas tentativas não tenham tido sucesso.
Primeiro tentei implementar o CVS, não só os meus conhecimentos do CVS contribuiram para que nunca chegasse a bom porto, como a resistência daqueles que "não têm tempo" acabou por enterrar de vez a ideia.
Mais tarde, quando ouvi falar pela primeira vez de um fork do CVS chamado Subversion voltei à carga, de novo foi um falhanço pelos mesmos motivos do anterior.
Desta vez estou a tentar o git, já consegui com algum sucesso colocar um repositório em funcionamento, para a minha maneira de ver as coisas, parece-me mais intuitivo e foi mais fácil perceber a lógica por trás daquilo. Já consegui colocar isto em andamento num dos projectos em que estou envolvido, vamos a ver se nos outros a tal "resistência" não leva a melhor.

Para compreender e conhecer este git, alguma documentação deu uma grande ajuda, por exemplo este tutorial muito sucinto e straight to the point. O Git in a Nutshell é um pouco mais extenso mas também deu uma grande ajuda.
Agora vou ver como é que o emacs se porta com o git mode.

mod_python

Tenho estado a fazer experiências com o mod_python e uma das dificuldades com que me deparei foi em apanhar raw posts. O problema no mod_python começa por aquilo não ter como objectivo criar uma maneira simples de programar para web mas sim integrar o interpretador no apache e assim não ter as perdas de tempo do system call que é o cgi.
Inicialmente é uma confusão de handlers e formas diferentes de o utilizar, o que afasta os mais fracos e explica a fraca aderência.
O grande mal do mod_python é exactamente não ter sido feito exclusivamente para programadores, para usar mod_python é preciso saber mexer nas configurações do apache e mais especificamente aquelas que o próprio mod_python implementa, e exige portanto conhecimentos de administração de sistemas.

Quanto ao problema que tive era o seguinte: quando chegava ao meu script e fazia um req.read() que é suposto devolver o raw post, este devolvia uma string vazia. O req.form trazia o POST e o GET processados (o POST todo mal processado já que o POST não vinha num formato que podesse ser decomposto em variáveis) o que dava a ideia que o próprio mod_python já tinha consumido o que havia para ler. A configuração que estava a utilizar era a seguinte:


<Directory /var/www/test>
AllowOverride AuthConfig
Order allow,deny
Allow from all

DirectoryIndex index.py
SetHandler mod_python
PythonHandler mod_python.publisher
PythonDebug On
</Directory>


Tentei ainda a seguinte configuração sem resultados:


<Directory /var/www/test>
AllowOverride AuthConfig
Order allow,deny
Allow from all

AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonDebug On
</Directory>


Depois de enviar um mail para a mailling list do mod_python fiquei a saber que utilizando o publisher handler não é possível apanhar raw posts e que devia definir para os ficheiros que precisem de o fazer um handler básico de mod_python, no meu caso isto não ajuda muito pois tenho um index.py que faz a gestão dos pedidos e não um ficheiro por página por isso criei uma subdirectoria chamada "comm", permiti o override na configuração do apache:


AllowOverride AuthConfig FileInfo


Dentro da directoria coloquei um ficheiro .htaccess com o seguinte:


SetHandler mod_python
PythonHandler index
PythonDebug On


Assim tenho um ficheiro index.py que controla todos os pedidos para esta directoria e no qual já consegui apanhar o raw post, este handler básico deixa uma série de coisas à responsabilidade do programador, tais como o content-type e o código de resposta.
Desta forma consegui construir uma estrutura onde um handler mais avançado controla as páginas mais básicas e um handler mais básico controla as páginas que precisem de comunicar com o exterior através da recepção de dados por POST, como por exemplo SOAP ou a recepção de um binário por POST (não confundir com o upload de um ficheiro num form).