First time

Aí está a minha primeira experiência com o Wordpress.

Cuidado com as linguagens

Sim, as linguagens são importantes

A propósito deste evento running a startup on Scheme, lembrei-me de algo que li há uns tempos (e que não deixo link porque já não sei dele) sobre os perigos de utilizar tecnologias que não sejam mainstream numa empresa.
Uma empresa que tenha a sua existência baseada em software e que desenvolva esse software em Lisp vai ter sempre um enorme problema quando precisar de aumentar o seu staff de programadores. Posso dizer por experiência própria que, num mercado pequeno como o português, e ajudado pelo sistema de ensino, até para arranjar programadores de python é difícil, imagine-se então Lisp.

Python

Apesar disso, a minha escolha continua a recair sobre o python porque sendo uma linguagem que segue os paradigmas a que a grande maioria dos programadores estão habituados permite "apanhar" bons programadores mesmo que estes não estejam familiarizados com a linguagem. Um bom programador consegue num período de uma ou duas semanas estar a produzir em python. O mesmo não acontece com Lisp onde um bom programador não habituado ao paradigma pode demorar meses a conseguir tornar-se produtivo.

Ruby

Uma linguagem que está com uma grande popularidade actualmente, embora já tenha tido mais popularidade (a verdade é que no último ano até perdeu utilizadores) é o ruby.
Ao ruby aplica-se tudo o que foi dito sobre o python com duas desvantagens, a primeira o facto de não ser tão fácil de aprender como o python, e introduzir alguns conceitos "estranhos" para quem vem da programação estruturada (OO incluído). No caso do python, são raros os exemplos em que um programador, mesmo não familiarizado com a linguagem não consiga perceber. No ruby isto não acontece e mesmo já tendo algum conhecimento básico de ruby não é raro tropeçar em sintaxe que não faço ideia do que faça.
A outra desvantagem é a maturidade da linguagem, não tive oportunidade (nem vontade) de ver como está a versão 1.9, mas até à versão 1.8 o interpretador era bastante ineficiente.
Poderia ainda apontar a legibilidade como mais um ponto contra o ruby, mas o JAVA e o PHP são o que são e continuam a ser as linguagens mais usadas

Alhos e Bugalhos

Há quem ache que que não há grandes programadores, outros acham que o código é que pode ser bom.
Acredito que há bons e maus programadores, e pessoalmente já conheci uns poucos bons e muitos dos maus, alguns são piores do que maus. O número de maus programadores não pára de aumentar, e de quem é a culpa não restam muitas dúvidas.
Também é verdade que o código, e até as próprias linguagens influenciam e muito a productividade dos programadores. Eu mesmo já passei por essa experiência, e o que retirei daí é que, não é só o próprio custo em termos do tempo perdido com mau código ou má arquitectura que retira a productividade ao programador. Aliás, este nem sequer me parece o factor mais importante. Na minha opinião o factor importante aqui é a moral, um bom programador perde motivação quando o trabalho que está a fazer é repetitivo e não tem inovação e por esse motivo dedica menos do seu tempo a fazer trabalho efectivo.

A shift in the Schwartz

Ultimamente este blog tem estado um pouco "ensonado", consequência de várias coisas. Uma delas, como não podia deixar de ser, não fosse a minha nacionalidade Portuguesa, é a falta de tempo (leia-se o mau aproveitamento deste).
A verdade é que analisando bem o motivo dessa inactividade no blog, ver-se-á que tem mais a ver com uma mudança de interesses em relação aos tempos em que o criei. O Repeat Until Keypressed surgiu numa altura em que influênciado pelo uso do Mac OS X, pela leitura de sites como o 43folders, o Life Hacker, etc..., estava bastante interessado em organização pessoal, workflows, tudo o que me pudesse levar a produzir mais fazendo menos.
Claro que estou e estarei sempre interessado nisso, mas a verdade é que actualmente tenho andado a ler mais sobre startups, sobre gestão de projectos e sobre alguns conceitos de programação mais invulgares.
Ao fazer o post anterior, onde publico um comentário meu a um artigo no blog do Mário Gamito, sobre um assunto que é bastante debatido por quem está envolvido na criação de startups, como encontrar a pessoa certa para uma determinada vaga e não um "falso programador" (programador no caso específico do post do Mário Gamito), percebi que se calhar a forma de não deixar morrer o blog será passar a falar mais sobre o que vou aprendendo sobre estes temas.
Olhando para os últimos posts publicados neste blog, vai-se de facto notando o afastamento do tema original, há meses que não há um link para o 43folders ou lifehackers, uma referência ao GTD, etc..., por esse motivo, espera-se nos próximos tempos, novos posts, falando sobre "algo completamente diferente".

1 shot de absinto

Deixei 1 shot de absinto no blog do Mário Gamito que me pareceu pertinente colocar aqui:

Este é um dos motivos porque é tão importante perceber o que um candidato a um determinado cargo realmente sabe, não basta olhar para os cursos que o candidato têm.
Este é um dos problemas que aflige e prejudica bastante algumas empresas, especialmente as grandes empresas onde os departamentos de RH regra geral não têm capacidade para confirmar se determinada entrada no curriculum corresponde a conhecimentos reais.

Hate is int the Air

Aparentemente um sinal da crescente popularidade da Apple, é o facto de esta cada vez ter mais haters, algo que até aqui era quase um exclusivo da Microsoft.
Um dos alvos preferidos desta nova espécie tem sido o Macbook Air que, a fazer lembrar a indignação dos utilizadores de PC quando a Apple deixou de colocar leitores de disquete nos computadores novos, aponta agora o desaparecimento da drive óptica mas desta vez com extra-raiva.

A questão que se coloca aqui é que o facto de o Air só suportar leitores ópticos externos não é grande novidade, já vários computadores portáteis fizeram o mesmo, alguns já há muitos anos como por exemplo a Toshiba com o portegé. Não podia, claro está, deixar passar esta oportunidade de dizer as esses novos Apple haters, vamos lá todos então odiar a Toshiba.

Em relação à possibilidade de desaparecimento das drives ópticas dos computadores num futuro próximo, só tenho a dizer que já é raro usar qualquer das minhas. No caso específico da Apple cada vez faz mais sentido poupar o espaço e o custo desse tipo de drives já que a própria Apple Store disponibiliza músicas, séries televisivas e filmes para venda e aluguer. Só sobra assim o software para ser transportado em meios ópticos. Nada que não se resolva! Eu próprio já comprei softwares que são descarregados da internet e que nunca chegam a passar por nenhum meio físico entretanto.
Para juntar à festa, as flash memory estão cada vez maiores, mais baratas e são mais fáceis de gravar e regravar do que os suportes ópticos.
E tendo em conta que até o SO eu já instalei a partir de um iPod (quem diz iPod pode dizer uma flash com uns quantos gigabytes) só tenho a dizer que não me parece que vá sentir muita falta das drives ópticas... especialmente quanto for pagar menos €500 para não ter blue ray.

Onde está o gil? [actualizado]

Afinal ainda não foi desta, foi só um downtime, aparentemente ainda há alguém a cuidar do gildot.


Hoje lembrei-me de verificar o estado do gildot e dei com ele em baixo.
Connection to 194.38.131.34 Failed
É sabido que o gildot estava mais para lá do que para cá, mas será que acabou de vez?

Repetição!?!? Qual repetição?

Segundo o mais futebol, Carlos paredes não apareceu, não apareceu, não apareceu, não apareceu, não apareceu, não apareceu, não apareceu...

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).

Gutsy

Já o tinha instalado no computador do trabalho, mas por upgrade ao 7.4, ontem instalei em casa, mas de raiz. O gutsy gibbon parece-me a melhor versão do ubuntu até agora. O CD de arranque é rápido e a instalação durou a 2ª parte do jogo do Sporting. As aplicações que tive oportunidade de experimentar, como por exemplo o firefox e o totem, este último normalmente identificado como "movie player", têm uma excelente integração com o sistema, utilizando inclusive o synaptic para instalar coisas como o plugin de flash ou codecs em falta.

Everybody Else Is Doing It, So Why Can't We?

E é assim que começo a falar também do google pagerank. Em junho deste ano, coloquei online um site para um cliente (Pharmastore), cerca de um mês depois de registado o domínio e no dia seguinte ao ser ter sido colocado online, resolvi verificar o PR da homepage deste site. Qual não é a minha surpresa ao descobrir que esta tinha PR 5. Como o site não tinha conteúdos relevantes, era só um catálogo de produtos, contactei o dono do site para tentar perceber o que tinha acontecido. A conclusão a que chegamos é que provavelmente teria sido por ele ter começado uma campanha no AdWords.
Para tornar mais enigmática esta situação, um mês mais tarde coloquei online outro site, muito no mesmo género. Desta vez o Estética Online, este com um pouco mais de conteúdos mas também ele principalmente um catálogo online. O tempo ia passando e o site continuava sem PR atribuído. Para piorar as proporções da minha teoria da conspiração este não tinha feito campanhas no AdWords.

Agora com estas alterações estou convencido que o PR exagerado do primeiro site terá sido um bug do algoritmo de PR do google e que a demora de atribuição de PR ao Estética Online, bem como a outros sites que coloquei online depois, se deveu à actualização que o google estaria já a preparar.
Actualmente ambos os sites têm PR 3, e o Repeat Until Keypressed que tinha um PR 4 também baixou para 3.
O Games Online continua sem PR atribuído, o que acaba por ser positivo já que o site ainda está muito nu de conteúdos e se o PR demorar quase seis meses a actualizar como parece ter acontecido desta vez mais vale não estar classificado do que ter um 0, digo eu.

O baldinho

Foi, é ou vai ser uma iniciativa que incita a que os blogs escrevem um post relacionado com ecologia, pelo menos parece porque tenho visto vários blogs a falar do tema com um bannerzinho a dizer "blog action day" no final do post.

Por isso mesmo aproveito e falo de uma coisa que faço e que me parece ter uns resultados interessantes. Actualmente utilizo um balde onde recolho a água que sai do chuveiro antes de esta aquecer. Num dia, guardando essa água que sai fria antes de começar a tomar banho, em minha casa, duas pessoas, conseguimos recolher cerca de 10 litros de água. Essa água pode ser utilizada para regar plantas, descarregar autoclismos, lavar embalagens de iogurte para reciclar, ser colocada no recipiente de água para limpar os vidros do carro, etc...
Ao fim de um ano conseguiremos gastar menos cerca de 3600 litros de água, e junta-se o útil ao agradável poupa-se os € que iriam para a companhia das águas em troca de ter água a escorrer para o ralo enquanto olhamos para ela à espera que aqueça.

Questão aos leitores

O jogo que desenvolvi em forma de applet JAVA terá alguns bugs que conheço e outros que não conheço e na sua maioria tenho uma ideia do que fazer para os corrigir, sendo que alguns são mesmo só questões de usabilidade ou coisas que não foram ainda implementadas por opção (como por exemplo os highscores).

Mas...há um "bug" que já testei em 3 computadores diferentes e browsers diferentes e que acontece sempre e que não tenho a certeza se será meu ou da própria classe Applet. Este tipo de coisas costuma ser culpa do programador, mas o código em questão é tão simples que até fico em dúvida.

A questão é a seguinte, se eu colocar o seguinte código na minha aplicação:

private Font myfont;

...

myfont = new Font("Arial",Font.BOLD, 22);
gBuffer.setFont(myfont);
gBuffer.drawString("Hello World", 10, 10);

A primeira vez que executar este código a applet fica cerca de 20 segundos parada e só depois faz alguma coisa. Isto pode ser visto se depois de iniciar o jogo se entrar nos créditos (estes são feitos com um drawString) ou na área de jogo (os pontos e o tempo são feitos com drawString).
Já experimentei mudar a fonte e o resultado é o mesmo.

Será que alguém já se deparou com esta situação e tem alguma dica que possa partilhar?
Desde já agradeço.

Os Jogos

Já coloquei online o primeiro jogo que desenvolvi nos últimos anos e que é também o primeiro programa que alguma vez desenvolvi em JAVA. O jogo foi compilado com o JAVA 1.5, quem tiver versões mais antigas não o vai conseguir ver. Entretanto pode ser que um dia eu consiga colocar as duas versões a funcionar no meu computador, actualmente a 1.4 que tenho foi instalada numa tentativa vã de fazer o tomcat funcionar, o que nunca se concretizou, por outro lado se invocar o compilador da versão 1.4 tenho erros que me parecem causados por o compilador estar à procura das libs nativas e encontrar as da versão 1.5 em vez das libs da versão 1.4.

Problemas do JAVA aparte, convém dizer alguma coisa acerca do site dos jogos. O site parece e de facto está incompleto e isso tem a ver com os objectivos e filosofia por detrás do site.
A ideia é eu e o tal amigo que referi e que também está envolvido no projecto como programador como se pode ver pelo blog dele, vamos desenvolvendo jogos por diversão. Para que os jogos não vão sendo abandonados a meio do desenvolvimento vamos-los publicando assim que eles estão minimamente jogáveis.
A área de notícias "news", deverá ter os anúncios dos projectos que vamos fazendo e também detalhes sobre o que falta fazer nesses projectos. As notícias mais recentes sobre cada jogo deverão aparecer na página do jogo. Essa área não funciona ainda porque o programador que está a fazer essa parte foi de férias e não chegou a terminar o software.
Algo parecido se passa com as notícias externas, mas desta vez tem a ver com o suporte python por parte do alojamento.

Em relação à área de jogos flash é possível que desapareça... ou não, já que outro amigo nosso, desta vez alguém com jeito para o desenho e com conhecimentos de flash se junto a nós como pode ser visto nos créditos do jogo que publiquei.

A filosofia do site segue a filosofia dos jogos, ou seja "não está pronto? não faz mal, publica-se à mesma e vai-se logando o desenvolvimento." para evitar o síndroma das coisas que ficam por fazer ad eternum. Neste momento como a secção de notícias ainda não funciona é difícil passar esta ideia, mas assim que funcionar todos os desenvolvimentos serão lá registados.

Common People

Para quem acha que sempre que o William Shatner abre a boca sai asneira, aqui fica um vídeo da magnífica versão que ele fez do Common People dos Pulp.

Post Mix II

Desde que há uns anos o Scott Adams publicou este cartoon que frequentemente alguém mo faz voltar à memoria ao tentar "envenenar-me" expondo-me a um dos interfaces ali satirizados. Admito que os meus se enquadram nesta categoria, mas tenho tentado fazer por alterar esta situação. Hoje li um artigo sobre escolha de cores que me parece uma boa ajuda para minimizar os casos de envenenamento por exposição aos UI's feitos por mim.

Num tópico totalmente diferente, e para aqueles que estão mais interessados em tornar os seus UI's ainda mais tóxicos, podem sempre aprender uma nova linguagem ou melhorar os conhecimentos numa que já conheçam por alto.

Andava à procura de uns screenshots do Tetris original para PC, que é, para quem não se lembra, feito em modo texto, e encontrei uma página sobre o tetris orginal onde se pode fazer o download dessa mesma versão.

Scribes

Tenho andado a usar o emacs nos últimos tempos e acho-o simplesmente espectacular. Mas hoje descobri um editor que é descrito como o "textmate" para python em Linux, o Scribes. Ainda não o experimentei mas este post é sobre a instalação e não sobre o editor em si.
Assim que comecei a tentar compilar em ubuntu tive um erro que já não é novidade, já me apareceu antes e é o seguinte:

$ sudo make
Making all in po
make[1]: Entering directory `/usr/local/src/scribes-0.3.2.9/po'
file=`echo de | sed 's,.*/,,'`.gmo \
&& rm -f $file && -o $file de.po
/bin/sh: -o: not found
make[1]: *** [de.gmo] Error 127
make[1]: Leaving directory `/usr/local/src/scribes-0.3.2.9/po'
make: *** [all-recursive] Error 1

Como se pode ver nos fóruns do ubuntu, a solução passa por instalar o gettext e voltar a fazer o:
$./configure
Mas... o erro continuava, muitos já terão percebido porquê, eis a solução:

$ make clean
Making clean in SCRIBES
...

$ ./configure

Neste ponto pode-se retomar as instruções normais de instalação.