APOD

January 31st, 2007 § 2 comments § permalink

Percebi hoje que eu sigo diariamente o Astronomy Picture of the Day há dez anos já, com exceção de alguns períodos em que eu mudava de máquina, perdia o bookmark e passava algum tempo antes que eu lembrasse do site. Hoje, com um feed cadastrado em um serviço externo, basicamente não me preocupo mais.

As fotografias são insanas: a de hoje, por exemplo, que na verdade é um vídeo, mostra a Cassini passando pelo plano dos anéis de Saturno. Simplesmente incrível.

Estilo de Código

January 30th, 2007 § 7 comments § permalink

Um dos editores do Artima, em um artigo hoje, pergunta sobre as práticas de estilo de codificação usadas pelos leitores. Mais especificamente: qual o nível em que o leitor pratica isso, e se o leitor notou uma correlação com produtividade.

Eu confesso que eu sou extremamente chato quanto a isso. Em todos os projetos que participo diretamente, principalmente quando estou na frente do mesmo, eu controle absolutamente todos os aspectos de estilo de código. E, pelo que eu pude observar nos últimos anos, há uma correlação imediata entre estilo e produtividade pelo simples fato de que um estilo de codificação bem pensado ajuda imensamente na legibilidade e, conseqüentemente, na compreensão do código.

Obviamente, estilo é uma questão um tanto ou quanto pessoal. Eu tenho duas birras que tem a ver com estilo, mas que podem ser uma fonte de conflito: um, eu sempre alinho chaves em um linguagem que as possua; dois, eu detesto o caractere sublinhado. Ironicamente, Ruby, uma das minhas linguagens favoritas, vai contra essas duas tendências.

Durante os últimos anos, entretanto, eu cheguei à conclusão que uma linguagem tende a ganhar quando favorece automaticamente um estilo de codificação. Python, com sua indentação baseada em espaços é um exemplo clássico. Smalltalk também favorece um estilo definido de codificação que produz código extremamente elegante. Haskell exige certas convenções gramaticais. Nessas três linguagens, essas convenções não só facilitam a vida do programador quanto tornam o código mais óbvio.

Eu acredito que isso tenha um pouco a ver com a mentalidade de programador. Como a programação é intrinsecamente matemática, a busca por elegância é um alvo natural. Convenções de código tem, em termos, o mesmo papel que a notação matemática fornecendo uma maneira unificada de expressar abstrações e atributos do código de uma maneira sucinta e elegante. A analogia falha um pouco quando preferência pessoal entra em questão, mas é interessante perceber como certos conceitos se tornam comuns, permeando qualquer linguagem.

Em última instância, o estilo se torna uma ferramenta tão integral quanto testes e análise porque é parte da maneira de expressar o código. E, sendo assim, sua importância não pode ser subestimada–o que, eu acredito, justifica minha chatice.

Arrogância

January 30th, 2007 § 2 comments § permalink

Navegando ao acaso, bati com esta entrada no Raw Socket: 10 Years Ago. É um vídeo mostrando o momento infame em que a Apple anunciou sua parceria com a Microsoft.

A arrogância do Steve Jobs é fenomenal: “Whatever Apple and Microsoft decide, it’s a standard”. Como a entrada do Raw Socket diz, temos que agradecer ao Linux e ao movimento de código aberto pelos últimos dez anos, por realmente pensar diferente.

Kansas City Shuffle

January 29th, 2007 § 5 comments § permalink

It’s a blindfold kickback-type of a game
called the Kansas City Shuffle,
whereas you look left and they fall right
into the Kansas City Shuffle.
It’s a they think, you think, you don’t know,
type of Kansas City hustle
where you take your time,
wait your turn and hang them up, and out to dry.

Assisti esses dias o filme Lucky Number Slevin, que aqui no Brasil foi chamado de Xeque-Mate. É um desses filmes despretensiosos no bom sentido, preocupado com a história e não com efeitos especiais ou coisas desse tipo. O elenco excelente é usado com maestria pelo diretor, resultando em filme em que os piores momentos de atuação estão muito acima da média do que normalmente é visto nesse tipo de filme. A cena entre Morgan Freeman e Ben Kingsley é surreal de tão bem feita.

A história começa com um premissa simples: um caso de identidade trocada que coloca um jovem contra dois chefões do crime. Aí entra a título desta entrada, o Kansas City Shuffe, um suposto golpe em que o alvo olha para esquerda quando deveria estar olhando para direita. E nesse caso, o alvo é o público. O diretor e o escritor admitem livremente isso e o resultado é mais uma vez um filme muito bom para se assistir.

A trilha sonora, por J. Ralph, é excelente e a música que leva o nome do golpe é muito divertida (no site do compositor, como não é possível um link direto, vá em Music, depois no álbum que leva o nome do filme, e escolha a música #19.

Como é óbvio, gostei muito e recomendo.

Google Reader vs. Bloglines

January 28th, 2007 § 6 comments § permalink

Depois de experimentar o Google Reader e o Newshutch como alternativas ao Bloglines, decidi ficar com o primeiro.

O Newshutch é um excelente leitor de feeds, mas é muito simplificado para o meu gosto. É bem rápido, não apresenta os problemas que eu mencionei anteriormente, mas também só serve para ler as entradas. Ironicamente, essa foi a mesma coisa que eu disse do Bloglines há mais de dois anos atrás (embora, na época, eu tenha concluído que leitores online não eram para mim).

Obviamente, o propósito principal de um leitor de feeds é, bem, ler feeds. Mas é sempre bom ter funcionalidade extra para ajudar a guardar entradas que você quer ler depois, ou marcar coisas sobre as quais você quer escrever e por aí vai.

A transição para o Google Reader foi bem tranqüila e, depois que eu me acostumei com o fluxo de leitura que ele favorece, comecei imediatamente a ver vantagens sobre o Bloglines.

A mudança principal é que a maneira mais fácil de ler as novas entradas no Google Reader é abrir todas e ir navegando usando o próprio teclado. Isso é exatamente o contrário do prático no Bloglines, já que, neste último, isso faria com que todas as entradas fossem marcadas como lida. Com o Bloglines, eu me acostumei a ir de feed em feed, lendo o que me interessava e, quando queria deixar algo para ler mais tarde, pedindo ao Bloglines que sempre deixasse aquilo como novo. No Google Reader, eu não preciso disso.

Uma outra grande vantagem do Google Reader é a possibilidade de marcar um item para posterior atenção via tags ou como um starred item. São duas maneiras práticas de controlar a leitura que ajudam bastante.

A navegação via teclado do Google Reader é muito mais refinada também–herança do Google Mail provavelmente.

Finalmente, o método de compartilhar links do Google Reader é mais prático, embora eu não tenha usado nem o do Google Reader nem o do Bloglines publicamente.

Concluindo, estou gostando bastante do Google Reader e vou aposentar a minha conta no Bloglines em breve.

Ponto de retorno seguro

January 27th, 2007 § 7 comments § permalink

Eu não tenho números, mas, pelo tempo que eu acompanho o assunto, eu diria que a vasta maioria dos projetos de código aberto ou livre são criados para resolver algum problema que o autor original do mesmo tinha. Muitos projetos que hoje tem um profile enorme, como é o caso do Apache e Firefox, começaram assim.

Considerando esse tipo de começo, eu me peguei pensando qual seria o ponto em que o criador original deve abrir mão de suas preferências e deixar que a comunidade escolha o modo através do qual o produto final deverá evoluir. Obviamente, não é uma escolha fácil. Aliás, considerando o aspecto meritocrático natural a esse tipo de projeto, conflitos são muito comuns, manifestados comumente por meio de forks. Um exemplo recente e notório é manifestado na divisão (1, 2, 3) entre os desenvolvedores do WordPress.

Projetos em que o mantenedor principal é um só provavelmente sofrem ainda mais com isso. Afinal de contas, se somente uma pessoa está disposta a trabalhar no código, seria justo considerar que ela é a maior interessada no mesmo e que tem direito de fazer as modificações que lhe atendem melhor. O problema é quando centenas de pessoas estão usufruindo desse código e esperando que próximas versões corrijam problemas mas não introduzam novas características por demais discordantes das versões anteriores. É uma posição realmente delicada.

No final das contas, é quase como se houvesse um ponto de retorno seguro. Até aquele ponto, o desenvolvedor pode se preocupar somente com o código. Do ponto em diante, ele precisa de preocupar com seus usuários também.

Para falar a verdade, eu não sei o que faria se estivesse nessa posição já que, atualmente, não sou responsável direto por nenhum projeto de código aberto. Como usuário, eu já abandonei o uso de certas ferramentas por mudanças radicais na linha de desenvolvimento. Para algumas, mais fáceis de manter, eu mantenho forks pessoais.

De qualquer forma, é uma questão interessante a ser considerar e uma que eu espero explorar mais um dia do outro lado da moeda.

Terceiro mandato?

January 26th, 2007 § 1 comment § permalink

Cruzes, deu até calafrio. A coluna Pensata na Folha de hoje comenta sobre a rejeição de Lula a uma alteração na Constituição para aceitar um possível terceiro mandato ao qual ele concorreria. No meio da coluna, o autor faz o seguinte comentário:

Ainda que Lula desejasse tal disparate, o Congresso não o aprovaria. Se os legisladores o fizessem, a sociedade não aceitaria. O Brasil não é a Venezuela. Ainda bem. E Lula sabe disso.

E eu fico pensando que a sociedade provavelmente aceitaria. Sem considerar o precedente perigoso que estaria abrindo. Não é nem questão de um terceiro mandato do Lula, mas de um terceiro mandato. A frase que me vêm à mente é: “aqueles que não aprendem com o passado, estão fadados a repetí-lo”. Eu só espero que o Brasil tenha realmente aprendida a lição.

Eu nasci muito depois de Getúlio e era muito pequeno mesmo no final da ditadura, mas não é preciso estudar muito a história do país, ou dos vizinhos em geral, para perceber que só o fato do assunto estar sendo discutido já é algo preocupante. Como eu disse, calafrios.

A rota para SOA

January 25th, 2007 § 6 comments § permalink

Convergência de aplicações distribuídas via SOA é uma das grandes “tendências” atuais. É claro que, para onde quer que se olhe, há mais problemas a serem resolvidos do que soluções, mas o mercado está seguindo uma direção razoavelmente consistente.

Hoje, durante uma conversa com um amigo no almoço, o assunto se desviou para aplicações desse tipo, aplicações que a empresa na qual ele trabalha está percebendo agora nessa arena. É sempre interessante conversar com uma pessoa de uma área completamente diferente–no caso dele, engenharia–porque a perspectiva distinta serve para balancear a sua própria. Trabalhando com Internet, como é o meu caso, tecnologias como Google Apps for Your Domains, S3, EC2 e muitas outras similares são conceitos naturais e, de certa forma, aceitas como naturalmente vantajosas a longo prazo.

A minha percepção atual está bem centrada na confiabilidade de tais serviços, não em relação ao uptime necessariamente, mas em relação a segurança a longo termo de informações necessariamente distribuídas. E minhas conversas tendem a confirmar esse ponto. É quase como se a indústria de informática tivesse um blind spot em relação a esse tipo de problema.

Quase no final da conversa, ele me perguntou qual o timeframe provável para aceitação de aplicações SOA de um modo geral. Eu ri, brincando que era uma resposta impossível sem uma máquina do tempo.

Depois, pensando no assunto, me ocorreu que provavelmente existe um ponto definido para a aceitação de tais aplicações. O principal problema por trás dessas aplicações está focada na disponibilidade de uma rota de acesso, que é mais importante do que banda–até porque a maioria dessas aplicações são naturalmente leves. Sendo assim, esse problema teria que ser resolvido por algo intrinsecamente ubíqüo.

Não vou arriscar uma previsão, mas acho que a chave para a aceitação dessas aplicações–seja daquelas hospedadas em server farms ou daquelas rodando nos próprios servidores de uma empresa–está na convergência da telefonia celular.

Não acredito que estamos a muitos anos da transformação definitiva do celular em outro aparelho que se tornará a ferramenta computacional básica de uma pessoa. É uma evolução que está em seu começo ainda, mas é certa. Um aparelho assim seria uma estação de trabalho permanente, um centro de mídia, e por aí vai. Lembra alguma coisa?

Somando isso com a expansão das redes já existentes, o maior problema do SOA fica resolvido. Reforçando o ponto, não é uma solução existente em termos gerais, mas já sabemos como a nossa indústria anda. É realmente só uma questão de tempo.

Faz sentido? Eu acho que sim.

SuperTux 0.3.0

January 24th, 2007 § 1 comment § permalink

Quanto mais eu jogo SuperTux, mais eu fico viciado. A nova versão, que está em beta, tem um monte de cenários e itens novos e não dá para resistir à tentação de passar mais uma fase entre uma tarefa e outra durante o dia. Tens alguns probleminhas aqui e ali, mas já é uma bela diversão para quem gosta de jogos simples também. Para quem usa Debian ou Ubuntu, o Mark Pilgrim fez uma entrada um tempo atrás sobre como compilar o beta.

Aliás, os jogos que já vem com qualquer distribuição Linux batem de dez a zero qualquer coisa oferecida pelos padrões do Windows. Minha mãe, como eu comentei aqui em outras ocasiões, é uma viciada nesses jogos. De vez em quando, eu acho que ela só usa o Linux por causa deles. :-)

WordPress 2.1

January 24th, 2007 § 10 comments § permalink

Instalei o dito cujo, mas não ficou um dia no servidor. Por algum motivo, era muito mais lento do que o anterior e alguns plugins que eu uso não era completamente compatíveis–embora todos tivessem o label 2.x.

Só espero que o retorno tenha funcionado sem problemas, já que aconteceram mudanças no banco. Em caso de qualquer problema, agradeço o aviso.

Where am I?

You are currently viewing the archives for January, 2007 at Superfície Reflexiva.