Repeat Until Keypressed

Mudança de Instalações

2008-02-16T19:46:00.000Z

O Repeat Until Keypressed mudou de instalações. O novo endereço http://mlopes.online.co.pt substituiu a versão antiga que estava alojada no blogger.

Apesar de ter importado os posts, a versão antiga do Repeat Until Keypressed vai-se manter online exclusivamente por motivos de histórico, com os comentários desactivados.

Com a nova casa vem uma tentativa de mudar o estilo de escrita. Não, não me vou por a comentar as mamas novas da Floribela nem sequer falar do rabo da Jennifer Lopez. A ideia é tentar ter posts mais elaborados com algum conteúdo criado no próprio blog em vez do simples comentário a links interessantes encontrados noutros sítios. Alguns dos posts antigos eram de facto muito maus como por exemplo a versão antiga do post "Cada qual no seu lugar" que foi alterado entretanto ou como o "Aqui não há novidades" que apesar de linkar para um artigo que acho interessante, não diz nada sobre o artigo para o qual link aponta, e já agora, também não diz nada sobre mais coisa nenhuma.A nova plataforma permite-me um controlo mais apurado de todo o interface do blog bem como do seu próprio funcionamento, dando-me uma liberdade que o blogger não dava. Está portanto na altura de começar esta nova etapa.Boas leituras, desejem-me sorte!

Cada qual no seu lugar

2008-02-15T14:10:00.003Z

Cada linguagem de programação tem a sua personalidade, e as práticas de programação devem ser adequadas a cada uma delas. Algumas linguagens terão personalidades mais semelhantes, outras mais distintas e quanto maior o distanciamento entre elas maior é a probabilidade da aproximação a um problema ser diferente.

Utilizar uma aproximação errada a um problema numa linguagem é em muito semelhante a atribuir a tarefa errada a um trabalhador. Não se coloca um programador de C a cortar HTML e não se coloca um web-designer a programar em C pois isso leva a insatisfação profissional, atrasos e erros na tarefa, enfim, um sem fim de consequências negativas.

Estruturado

A programação estruturada é aquela que mais "fora de moda" se encontra, apesar disso é a aquela que tem mais provas dadas. A grande maioria das aplicações que se vê por aí são feitas em C, praticamente tudo aquilo que utilizamos hoje em dia está assente em algo feito em C, como por exemplo muito do software que permite a existência da internet.

Dentro da programação estruturada há claro linguagens diferentes e as aproximações deverão também ser diferentes. Existem paradigmas distintos, tais como o imperativo e o funcional, existem as linguagens compiladas e interpretadas (conhecidas como linguagens de script).

Alguns do exemplos de linguagens estruturadas bastante populares são o C, o perl e o PHP. Logo aqui se nota a diferença entre as aproximações por linguagem. Não passa pela cabeça de ninguém resolver um problema da mesma maneira em PHP ou em C, a gestão de memória, o suporte para arrays dinâmicos, é tudo tão diferente que até sinto alguma dificuldade sequer em fazer uma comparação.

Objectos

Aqui entram algumas linguagens como por exemplo o python, o ruby , o Smalltalk e o IO language. Este é um paradigma mais geek e pouco utilizado, mesmo por alguns programadores de python e ruby que muitas vezes se desviam para a programação estruturada ou orientada a classes (muitas vezes chamada erradamente de orientada a objectos).

Aqui existem dois tipos de aproximação, o IO language, por exemplo, é prototipado, todos os objectos são criados clonando um objecto base e alterando depois o novo objecto. Nesta situação nem sequer existem classes.

Já em python por exemplo os objectos são criados a partir de classes, se bem que é possível criá-los copiando outros e depois alterando-os. Mas mesmo quando os objectos são criados a partir de classes na prática a diferença não é assim tão grande pois nas "new style classes" os objectos herdam todos implicitamente de um objecto base Object.

Neste tipo de linguagens a pureza de objectos da linguagem é um factor importante, pois é isso que permite a manipulação dos dados/código que caracterizam a aproximação ao problema utilizado normalmente neste tipo de linguagens. Closures e as funções e classes como first class citizens são também elementos importantes que condicionam a forma de utilizar a linguagem. É importante para quem não está familiarizado com o conceito de funções como first class citizens que isto não é um exemplo de passar funções como parâmetro ou devolver funções (as duas linhas são dois exemplos independentes):

func1(func2())
return func()

Este é o exemplo correcto:

func1(func2)
return func

No caso específico de python e ruby, quase tudo são objectos, mesmo as primitivas da linguagem, com excepção de uma mão cheia de keywords. No caso do ruby alguns operadores não são objectos (o == é mas o != não é, não sei bem porquê).

Classes

Neste tipo de linguagem inserem-se por exemplo o JAVA, o PHP e o C++, estes dois últimos só quando utilizados com classes em vez da forma estruturada. Este é actualmente o paradigma da moda. Regra geral as classes são utilizadas como contentores de funções que actuam sobre uma estrutura de dados comum. A diferença deste paradigma relativamente ao dos objectos é o facto de estas linguagens não serem puras de objectos, não terem closures nem funções e classes como first class citizens. A consequência disto é que a manipulação de código é muito reduzida e reflecte-se na aproximação ao problema.

Epilogo

Muitos dos programadores que experimentam uma linguagem com uma personalidade muito diferente daquilo a que estão habituados caem nos erros de fazer as coisas da forma errada para a linguagem que estão a usar. Por exemplo no How not to write Python code o autor enumera uma lista de coisas que ele considera que se deve ou não fazer em python.
Estranhamente o próprio autor cai num dos erros por ele referidos:

Python is Python, don’t try to emulate bad coding patterns from other languages

Ao fazer o seguinte:

A basic example: to check whether a function parameter is of a certain type, don’t use something like ‘arg.__class__ == MyClass’, use ‘isinstance(arg, MyClass)’.

Isto é claramente um erro pois o python é weak typed, não faz sentido o programador verificar tipos, pois isso é para linguagens strong typed e os compiladores/interpretadores serão com certeza mais eficientes a fazê-lo. No caso de haver de facto necessidade de verificar uma característica de um objecto, como por exemplo a existência de determinado método, vale mas verificar só mesmo essa característica. Ao fazer o que o autor diz no exemplo perdem-se as vantagens da pureza de objectos que permite fazer coisas como os file like objects. Este é o tipo de código típico de uma linguagem como o JAVA, mas... o próprio JAVA já faz isto pelo programador.

Outro exemplo que está bastante desviado da realidade do python é, ironicamente, o "Use Pythonesque coding pattern" que apresenta uma alternativa ao facto do python (tal como perl 5 por exemplo) não ter cases. Neste exemplo o erro é gritante porque o autor cria um código complicado para emular uma funcionalidade de outras linguagens, o facto de ele próprio falar nisto como uma alternativa ao case que não existe em python mostra o erro de estar a utilizar paradigmas de outras linguagens. A verdade é que nos últimos anos tenho programado muito em perl e python e nunca o meu código chegou a um ponto onde precisasse de um case.
O que me faz pensar que se estamos a tentar emular algo que não existe na linguagem... então estamos no caminho errado.

Um desvio à cultura vigente nas empresas

2008-02-11T12:07:00.000Z

Este post fala de um estudo feio em 2001 sobre como a cultura de uma empresa pode influenciar a criatividade numa empresa como entidade.
O princípio é bom, mas as ideias acabam por seguir o habitual dentro da cultura empresarial actual onde na prática nada é diferente do que era. Na prática o que sinto ao ler as conclusões é que não estaria satisfeito a trabalhar no tipo de ambiente descrito.
Vale pelo estudo, as conclusões parecem-me muito fracas.

Não te esqueças de fazer o TPC

2008-02-11T11:24:00.000Z

Alguns conselhos sobre formas de melhor conhecer o produto que está a desenvolver, de forma a poder planear prazos mais realistas. A validade destes conselhos está como sempre sujeita a discussão.

Aqui não há novidades

2008-02-07T12:27:00.000Z

Só aquilo que já se sabia, uns são bons, outros são maus... e a experiência de facto não os ajuda.

Não, não sou o único...

2008-02-07T11:59:00.000Z

MacBook Air Haters Suck My Dick, apesar do título agressivo, o conteúdo não o é tanto. Mas aparentemente não sou o único a ficar farto de passar a vida a tropeçar em comentários idiotas sobre o MacBook Air.
Já vi gente a queixar-se das coisas mais parvas, a reclamar que no MacBook Air não conseguem fazer <inserir coisa parva que nunca precisou de fazer>, a compará-lo com tijolos maiores que o meu desktop, etc...
A minha sugestão: já chega, se não gostam não comam mas poupem-nos ao ruído de vos ouvir choramingar.

O perfil do "entrepeneur"

2008-02-07T11:47:00.000Z

Um estudo chegou a algumas conclusões interessantes, mas não inesperadas, sobre o que leva alguém a ter um perfil de "entrepeneur" (e eu que não me lembro da palavra em português).

O GIT é mesmo bom!

2008-02-07T11:42:00.000Z

Há quem fique excessivamente fascinado com o git, mas de facto aquilo é bom. Eu só tenho pena de ainda não o dominar mais , mas já vou mexendo nuns repositórios e até tem corrido bem.
Deixo aqui um link para quem se quiser iniciar (eu comecei pelos tutoriais que estão na página oficial).

SDL para games.online

2008-02-01T14:07:00.002Z

Quem leu o post que aqui coloquei ontem e seguiu o link para o blog do games.online possivelmente reparou que está iminente o arranque do desenvolvimento de um jogo que ao contrário dos outros que lá estão não será online, mas sim para descarregar e instalar.
Aproveitando as possibilidades que isso nos dá, optámos por fazer o desenvolvimento em C utilizando SDL.

Assim chegamos ao objectivo deste post que é partilhar o link para o excelente tutorial que me tem ajudado a relembrar o C e a aprender a usar SDL. Sim, porque como diz no tutorial, eu ainda sou do tempo (e não fiz nada em C desde esses tempos) em que se fazia isto:

_asm {
    mov ax, 13h
    int 10h
}

First time

2008-01-31T15:13:00.001Z

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

Cuidado com as linguagens

2008-01-24T13:06:00.000Z

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

2008-01-23T14:46:00.000Z

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

2008-01-23T12:25:00.000Z

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

2008-01-23T12:01:00.000Z

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

2008-01-22T11:27:00.000Z

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]

2008-01-10T15:56:00.000Z

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?

2008-01-03T11:40:00.000Z

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

2007-12-29T16:22:00.000Z

Dei recentemente com este post:

Abbreviation, Accidental Complexity, and Abstraction

Que me levou a estes:

Este último sobre um dos ensaios do Paul Graham.

Still a git...

2007-12-19T11:02:00.000Z

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

2007-12-16T11:54:00.000Z

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

2007-12-09T12:55:00.000Z

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

2007-11-08T19:21:00.000Z

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?

2007-10-27T11:15:00.000+01:00

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

2007-10-16T10:29:00.000+01:00

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

2007-10-13T12:40:00.000+01:00

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.