Arquivo para a categoria 'meus projetos'

Blog novo

Quem costuma acompanhar este blog já deve ter notado que de vez em quando cito Ruby em um exemplo ou outro e às vezes analiso algum aspecto da linguagem. Porém nunca dediquei muito tempo à linguagem, bibliotecas associadas e nem a frameworks interessantes. Nunca escrevi nenhum tutorial, fiz resenha de nenhuma biblioteca nem publiquei novidades sobre Ruby por aqui.

Para estas e outras coisas relacionadas a Ruby vai servir o Minerama. Este novo blog foi uma idéia do João Paulo Lins e estou entrando junto com ele nessa com o objetivo de criar mais um ambiente colaborativo para aprendizado de Ruby (como se já não houvesse milhares). Por “colaborativo” quero dizer que vamos aceitar textos assinados por outros autores. Este é um blog verdadeiramente multi-autor e espero conseguir algumas colaborações bastante interessantes. Por enquanto só há um texto introduzindo os objetivos do projeto, mas não vai demorar para começar a aparecer novidades.

Por fim, não, eu não abandonei nem pretendo abandonar o Mergulhando tão cedo. Apesar de um mês e meio ser um bocado de tempo sem textos novos, pretendo voltar a publicar dentro de uma semana no máximo. Quem preferir pode “ficar no aguardo”, mas fico feliz se você só esperar um pouco. (Notaram como ninguém mais “aguarda” ou “espera”? Todo mundo agora só “fica no aguardo.” Parece que o corporativês vai dominar o mundo mesmo.)

Alguém tem um Mac por aí?

Então parece que a Apple está preparando uma versão do seu navegador Safari para Windows. Parece também que o bicho está disponível como beta e, como tenho acesso a uma máquina Windows XP no trabalho, achei que não faria mal a ninguém testar o navegador que há algum tempo atrás era exclusividade de usuários Mac. Claro que o primeiro site que testei foi o do projeto Motiro e o resultado não foi muito animador:

Motiro no Safari 3 Beta em Windows XP

Os trechos de texto com alguma modificação de estilo (títulos, negrito, cores personalizadas) não foram exibidos e houve alguns problemas de perda de alinhamento em alguns elementos. Isso tornou o site totalmente inútil para qualquer pessoa com um mínimo de juízo (como não sou uma dessas pessoas, ainda tentei abrir algumas páginas da wiki e parece que os problemas continuam em todas as páginas).

Há algum tempo venho usando o BrowsrCamp.com para ver algumas fotos de como o Motiro aparece no Safari. Obviamente que ver fotos estáticas do seu site não é uma opção tão boa quanto vê-lo ao vivo, mas é melhor do que nada. A versão que eles usam não é este beta do Safari 3, mas um Safari 2 que presumo ser estável. Nele o Motiro aparece bem mais apresentável:

Motiro no Safari 2.0.4 em Mac OS X

Será que o Safari mudou tanto do 2 para o 3 que passou a renderizar sites de modo completamente diferente? Ou este é um comportamento apenas da versão Windows do Safari 3? Se alguém tiver um Mac por aí e puder fazer estes testes com o Motiro, eu agradeceria muito. Depois dessa estou pensando seriamente em concentrar os esforços completamente nos aspectos de compatibilidade com navegadores para o release 0.6.7.

Encontro de usuários Ruby em Recife

Estávamos pensando em organizar um encontro de usuários Ruby em Recife e depois do ótimo artigo da Kathy Sierra ressaltando a importância do contato cara-a-cara não podemos mais deixar para depois. A idéia é que depois dessa pequena reunião inicial possamos começar a formar um grupo de usuários local para estudarmos juntos, organizar palestras e fazer começar aquele negócio que falam tanto por aí chamado de comunidade. Com um encontro presencial nos fortalecemos e juntos podemos ajudar melhor quem está querendo aprender.

O encontro será na próxima quarta-feira (dia 21) à noite no bar Recanto Paraibano no Parnamirim. Precisamos saber mais ou menos quantas pessoas vão aparecer para dimensionarmos o local. Quem for de Recife e estiver interessado em participar, pode me responder em particular (meu e-mail fica no GMail: thiago ponto arrais) para nos organizarmos. Dependendo da participação, talvez precisemos alugar o Chevrolet Hall ou coisa do tipo. :-)

Motiro disponível como Ruby Gem

Acabei de publicar a versão 0.6.3 do Motiro, uma ferramenta de acompanhamento de projetos na qual venho trabalhando há algum tempo. A maior modificação desta versão foi a publicação do pacote como Ruby Gem. Isso deve permitir que qualquer um com o sistema devidamente configurado (basicamente Ruby com Gems instalado) possa instalar o Motiro com dois comandos simples:

$ gem install motiro --include-dependencies
$ motiro install <um local no sistema de arquivos>

Há algumas formas de instalação alternativas para quem estiver interessado. Além disso, às vezes as coisas não correm tão bem quanto gostaríamos. Para todos os casos há mais detalhes na página de instalação do Motiro.

EclipseFP fazendo história

Na última quinta-feira (dia 25) foi divulgada a versão final do artigo A History of Haskell: being lazy with class de Simon Peyton Jones, Paul Hudak, John Hughes e Philip Wadler. O artigo vai ser publicado na terceira Conferência de História das Linguagens de Programação (History of Programming Languages Conference – HOPL-III), a ser realizada em Junho de 2007. Os autores estão mais do que habilitados para contar a história da linguagem. Todos eles tiveram papéis importantes em vários eventos. Hudak, por exemplo, ficou responsável por pedir permissão à viúva do matemático Haskell B. Curry para que o nome dele fosse usado para batizar a linguagem.

Há mais curiosidades como esta no artigo. Ele está muito bem escrito (como era de se esperar destes gigantes) e é uma ótima leitura, apesar do tamanho (55 páginas). Altamente indicado para quem quer conhecer a linguagem e sua história. Não é todo dia que podemos ouvir história diretamente de quem fez história. Recomendo atenção especial para a seção de ferramentas. Eles foram suficientemente gentis para lembrar do EclipseFP.

Veteranos e novatos

Este é o último artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Muita inovação acontece nas margens do sistema, pelas mãos de quem ainda não faz (ou nunca vai fazer) parte das panelinhas que todo mundo presta atenção.

Quem está em destaque tem uma certa obrigação oculta de continuar fazendo sucesso. Isto não está escrito em lugar nenhum, mas eles se sentem pressionados mesmo assim. Por causa dessa pressão invisível é que eles tendem a se concentrar em atividades de baixo risco. Uma das práticas de baixo risco mais comuns é repetir seu primeiro grande feito à exaustão. Se você já descobriu algo que faz sucesso, porque arriscar? Veja Dan Brown, por exemplo. Depois que ele escreveu O Código Da Vinci e o livro apareceu em listas de mais vendidos do mundo inteiro, ele já o reescreveu algumas vezes. Claro que o título e o enredo mudam toda vez, mas a estória é essencialmente a mesma. Ele faz isso porque dá certo. As pessoas compram os livros dele porque sabem o que esperar.

Repetição não é ruim. Repetição é um dos elementos fundamentais da evolução. Quando os animais se reproduzem eles basicamente se repetem, fazem cópias de si mesmos. Se essa repetição fosse exata, o que chamamos de clonagem, não haveria evolução porque não haveria mudança. Mas na vida real o que acontece é que a estrutura básica é repetida e mudam-se alguns detalhes menores como a cor dos olhos, a espessura dos pêlos e a estatura. A partir destas pequenas diferenças é que ocorre a evolução. O mesmo ocorre com as idéias de sucesso. Sua estrutura principal é repetida e alguns detalhes são modificados. De acordo com a receptividade, estes detalhes são novamente modificados e novas mutações são testadas.

Os veteranos em todos os ramos são muito bons nesse tipo de evolução experimental, eles podem mudar pequenas coisas de modo a gerar coisas novas mas extremamente parecidas com as antigas. Este processo é lento por natureza. Para chegar a um novo produto desse modo é necessário fazer várias modificações e cada uma das modificações precisa ser testada para a aceitação do público. Isto leva tempo.

Mas às vezes o que precisamos não é de evolução lenta. Às vezes precisamos de saltos evolucionários para não ficarmos presos em máximos locais. Para isso é necessário introduzir um elemento inesperado, uma fonte de aleatoriedade qualquer. Na natureza, a reprodução sexuada vem cumprindo muito bem esse papel e nos negócios sangue novo também é muito bom para isso. Os novatos não tiveram as idéias influenciadas pelas limitações atuais do mercado e da tecnologia, por isso têm facilidade para pensar em coisas completamente novas.

Essas limitações podem ser um grande problema. As idéias novas parecem preferir as cabeças mais frescas. Quando se está no meio da selva matando um leão por dia, fica difícil achar tempo para ter grandes idéias e pensar no futuro. Muita gente acaba queimando a língua por causa disso.

Há controvérsias, mas algumas fontes relatam que Thomas Watson, então presidente da IBM, disse em 1943 que talvez houvesse no mundo inteiro mercado para cinco computadores. Era a época da Segunda Guerra Mundial. Os computadores eram usados principalmente para quebrar códigos de mensagens militares e eram grandes a ponto de ocupar várias salas. Naquela época não havia a sala dos computadores, mas as salas do computador.

Nessa situação é fácil imaginar que o mundo teria poucos computadores. Era preciso ter muitos recursos para isso e as únicas entidades com recursos e interesse suficientes para obter um eram uma meia-dúzia de governos.

Já a revista Popular Mechanics, em uma edição de 1949 acertou em cheio. Eles publicaram que “no futuro, os computadores pesarão não mais do que uma tonelada e meia.” Algumas décadas depois realmente é difícil achar um computador com uma tonelada e meia. Mas é fácil encontrar um com alguns gramas no bolso de qualquer adolescente.

Em 1977, quando a Apple lançava seu computador pessoal Apple II, Ken Olsen, fundador da Digital Equipment disse que não via razão para alguém querer um computador em casa. A DEC produzia o que eles chamavam de mini-computadores que eram usados principalmente para pesquisa científica. Realmente, ninguém iria querer um desses em casa, mas hoje muita gente não sabe como iria viver sem um computador pessoal.

Os produtos realmente inovadores são surpreendentes porque ninguém acha que precisa deles antes de existirem. Ninguém precisava do computador pessoal antes dele existir. Ninguém precisava de celulares. Ninguém precisava de câmeras digitais. Ninguém precisava de mouses. Mas hoje tem muita gente que não sabe como vivia antes deles.

Todas estas pérolas são de gente que já estava envolvida em seus respectivos nichos há um certo tempo. Eles simplesmente não conseguiam ver os saltos evolucionários. Eles estavam muito ocupados resolvendo os problemas de hoje e não tinham tempo para pensar nos de amanhã.

Os novatos não têm essas limitações ainda. Eles não foram tão expostos à situação atual como os veteranos. O problema deles é outro: recursos.

Semana passada eu li sobre como as telecom estão querendo estratificar a Internet para cobrar direitos de transmissão sobre os meios de alta velocidade. Na ponta dos links da Internet estão os roteadores e eles têm uma fila interna. A idéia é que se você pagar mais, seus pacotes (suas mensagens) tenham prioridade de transmissão. Atualmente, a fila é mais ou menos justa: se você chegar primeiro, você é atendido primeiro. O que eles querem é que algumas pessoas possam furar a fila.

Se elas conseguirem fazer isso (e eu não tenho certeza de que seja possível), vai ser um grande golpe para a inovação. Muitas das idéias inovadoras de hoje saem das cabeças das pessoas comuns e elas não têm os recursos que as grandes corporações têm. Se as filas de transmissão não fossem igualitárias, não seria possível que um programador de São Francisco inventasse e testasse o BitTorrent. Se os grandes provedores de conteúdo tivessem preferência de tráfego, ele não poderia fazer suas experiências usando sua conexão residencial comum. Os pacotes dele teriam prioridade extremamente baixa e ficariam um bom tempo presos no congestionamento. Seria preciso convencer algum investidor com bom poder de fogo a financiar o projeto. E os investidores podem não ser muito receptivos à inovação.

Inovar é arriscado e quando você é velho e famoso, não pode se dar ao luxo de fazer papel de idiota. Mas se você é jovem e desconhecido, ninguém vai ficar sabendo do seu fiasco. Você pode ousar mais quando não tem medo de bancar o idiota.

Aprender, praticar (e aprender um pouco mais)

Este é o segundo artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Prática certamente é uma Boa Coisa™. Eu até acredito que tem algumas coisas que não dá para aprender sem praticar. Para estas (e elas são muitas) é mais interessante estudar um pouco, praticar um pouco, depois estudar mais um pouco e repetir o ciclo eternamente. Você não pode dizer que sabe sobre alguma coisa antes de usá-la de verdade. Mas conhecimento prático somente, não é suficiente.

Se eu quiser programar, por exemplo, não basta que eu devore o manual de alguma linguagem de programação e comece a escrever meus próprios programas. Eu até posso fazer isso, se eu quiser só programar. Mas se eu quiser fazer bem, é preciso estudar como quem já está nessa há mais tempo faz as coisas. Se eu simplesmente me trancar no meu quarto de madrugada para programar, a excelência vai ser um objetivo distante. Alcançável, mas bastante distante. É preciso ler código dos outros, procurar por construções comuns em vários programas e identificar boas práticas.

Mas isto não é o bastante. Se eu quiser mesmo ser Bom com ‘B’ maiúsculo, vou precisar estudar algumas coisas que aparentemente não têm nada a ver com o ofício da programação. Coisas como teoria dos grafos, protocolos de comunicação entre computadores e inteligência artificial. Mesmo que eu ache que não vá usar diretamente nada disso, é bom me expor pelo menos um pouco a estes assuntos.

Estudar tudo isso vai alargar meus horizontes de conhecimento. Eu não vou saber nenhum desses assuntos a fundo, mas vou saber que há outros mares para explorar, novas possibilidades. Assim podemos traçar paralelos e estabelecer analogias que podem levar a idéias geniais. Não é preciso mais do que uma breve exposição para isso.

Ter uma noção de cada assunto é ter conhecimento horizontal. É o conhecimento usado para chegar a uma dessas analogias que fazem a maior diferença. Também é o conhecimento usado para impressionar os outros. Você não precisa saber muito de comunicação de computadores para falar em rotedores, pacotes e protocolos.

Se tudo que você quer é ter assunto para conversar, conhecimento horizontal é o que você precisa. Para resolver problemas interessantes, é preciso conhecimento vertical. É preciso se aprofundar em algum nicho, se especializar.

Muitas tecnologias populares começam em pequenos nichos. São usadas por muito pouca gente no início, mas um dia alguém com visão resolve aplicá-las em um contexto diferente e a coisa explode. A Internet é um exemplo disso. Ela começou como forma de comunicação entre centros universitários e era usada também para troca de dados militares. No final da década de 80 e início dos anos 90, foi desenvolvida a base para a Web moderna e a partir daí a coisa explodiu. Claro que isso é uma simplificação da realidade (e o que não é?), mas ilustra o ponto de que um especialista que estuda um assunto a fundo pode ver oportunidades que os demais nunca vão imaginar.

Mas especialização demais também pode ser uma armadilha. Ela começa a ser perigosa à medida que se desiste do conhecimento horizontal pelo vertical. Fazer isso é desistir de idéias brilhantes ligando um campo do conhecimento ao outro. Especialização demais pode estreitar a visão a ponto de só permitir enxergar o próprio nariz.

Como (tentar) prever a criatividade

Este é o primeiro artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.


Previsibilidade é quase o oposto de criatividade. À primeira vista, podemos colocar criatividade e previsibilidade em dois extremos do mesmo eixo. Para aumentar uma, é preciso diminuir a outra.No extremo da previsibilidade temos organizações que têm somente capacidade de repetição. Suas atividades são facilmente gerenciadas por serem extremamente previsíveis. Uma forma de alcançar este grau de previsibilidade é inventar sempre a mesma coisa. O problema é que repetir a mesma coisa várias vezes não é inventar. Por isso que esses lugares altamente previsíveis são extremamente chatos para se trabalhar. Você está sempre fazendo as mesmas coisas. Escrevendo o mesmo relatório para o mesmo gerente.

No lado extremo da previsibilidade, temos fábricas tradicionais, com linhas de montagem e tudo mais, como as que Henry Ford projetou. Nestas fábricas tudo é extremamente previsível. Se colocarmos uma peça no começo da linha, podemos saber com uma boa precisão quando ela passará por cada um dos estágios. Essa previsibilidade é alcançada através de muita padronização e repetição.

No outro extremo estão as organizações que escolheram abandonar totalmente a previsibilidade em favor da criatividade. Essas inventam coisas maravilhosamente interessantes, mas não se pode confiar muito nelas para estabelecer prazos. Você sabe que dali vai sair alguma coisa surpreendente, mas ninguém sabe dizer quando. Estes lugares também são muito chatos para se trabalhar, porque parece que nunca vão acabar de construir nada. Sempre há um último retoque para ser feito. Sempre aparece um novo projeto interessantíssimo para deixar o anterior inacabado.

É deste lado que ficam alguns artistas, como Leonardo da Vinci. Ele era conhecido por atrasar as encomendas e tem gente que diz que às vezes ele até colocava alguns significados ocultos nas telas. Fazer uma encomenda a ele era receita certa para uma boa dor de cabeça. Ele não ia entregar no prazo e no final o que ele entregasse podia não ser muito bem aquilo que você tinha pedido. No entanto, ninguém pode dizer que ele não era criativo. O cara era a inovação em pessoa, inclusive foi pioneiro em muitas áreas de pintura, engenharia e anatomia.

É natural perguntar quantos carros uma fábrica pode produzir por dia. Mas não faz sentido nenhum perguntar a nenhum pintor que se preze quantos quadros ele pode fazer por mês. Cada quadro é uma obra única e o tempo de produção pode variar demais para que estimativa seja minimamente precisa.

Nenhum dos dois extremos é bom. A boa notícia é que não precisamos escolher entre preto ou branco. Há vários tons de cinza entre eles que podemos explorar.

Ao contrário do que possa parecer, não precisamos escolher entre uma e outra. Previsibilidade e criatividade não estão no mesmo eixo. As duas são ortogonais. Não precisamos necessariamente diminuir uma para aumentar a outra. Não é preciso ser imprevisível para ser criativo. Talvez as variáveis não sejam tão independentes como queiramos, mas também não são tão intrincadas que não dê para separá-las um pouco.

A menos que você esteja querendo reconstruir alguma coisa que já tenha construído, desenvolver software é um processo criativo. Só que nem todo programador pode se dar ao luxo de fazer como Da Vinci e desrespeitar prazos e demandas. É preciso ter algum grau de previsibilidade para agradar os clientes.

Para lidar com este problema é que foi inventada a iteratividade. O segredo é projetar o software em ciclos curtos chamados de iterações. No início de cada iteração, a equipe combina com o cliente o que deverá ser produzido durante um certo período de tempo e ao final deste período o cliente recebe um sistema funcional que pode ser testado. Pode ser que o sistema seja bem pequeno, minúsculo. Mas ele evoluirá ao longo do tempo até chegar uma hora que o cliente diga ‘está bom, era isso que eu queria’ e os programadores possam procurar um novo projeto.

Uma boa forma de se enganar é não entregar software rodando ao final da iteração. Você pode, no lugar disso, entregar um calhamaço de documentos, só para provar que não ficou parado o tempo todo. A idéia é que quem quer que esteja pagando pela sua empreitada possa validar esses documentos e dizer ‘continue, você está no rumo certo’ ou ‘não é bem por aqui, acho que devemos mudar de estratégia’.

Quando se usa um documento para esse tipo de comunicação, uma de três situações pode ocorrer. A primeira é o cliente validar seu documento e assinar embaixo, só que ele estava pensando em uma coisa quando leu e você estava pensando em outra bem diferente quando escreveu. A segunda é ele não concordar com o que você escreveu e implicar com as menores coisas para ter certeza que você entende o que ele está querendo. Essa segunda situação pode facilmente descambar para um fluxo eterno de remendos ao documento que impede que a coisa de verdade seja construída. A terceira possibilidade é que ele valide o que você escreveu e esteja pensando no mesmo que você. Mas é mais fácil ganhar na loteria do que isso acontencer.

Esse problema não acontece com software rodando. Quando o produto está vivo na frente do cliente, não há espaço para interpretações erradas. O sistema faz exatamente aquilo que está fazendo ali, ao vivo, na frente dele. Se algo estiver errado ou puder ser melhorado, o produto é um objeto concreto para servir de instrumento na discussão. Ninguém vai precisar adivinhar o que o outro está pensando.

A chave para o equilíbrio entre previsibilidade e criatividade através de iterações está em achar um tempo de iteração que seja pequeno o suficiente para que as estimativas não fiquem muito distorcidas e grande o suficiente para permitir que alguma coisa de útil seja feita. Tudo isto ainda permitindo que a equipe possa exercitar sua criatividade.

EclipseFP 0.10 disponível

Demorou mas saiu. A versão 0.10 do ambiente de desenvolvimento Haskell EclipseFP está disponível para download desde a última sexta-feira (dia 30 de junho). O modo mais fácil de instalar o plugin (na minha opinião, claro) é utilizar o gerenciador de atualizações do Eclipse. Mais detalhes sobre download e instalação na página de downloads do projeto.

Para este release eu estive trabalhando principalmente em complementação de código, uma funcionalidade que tem sido muito requisitada desde a 0.9.1. Outro destaque é o editor para arquivos Cabal, contribuído por Leif Frenzel, que deve ser muito util para o próximo release, que deve incluir suporte para montagem e empacotamento com Cabal.

Esta versão exige uma plataforma Eclipse versão 3.2, diferentemente da versão anterior que rodava sobre Eclipse 3.1. É necessário atualizar sua plataforma para obter todos os benefícios do plugin. Isso não deve ser grande sacrifício, afinal você já deveria querer atualizar sua plataforma para aproveitar as correções de bugs e novas funcionalidades do Eclipse.

Impressões do E-SOL/CEFET-PE

Para quem está perdido, E-SOL/CEFET-PE significa Encontro de Software Livre do CEFET-PE. Mais detalhes no post anterior.

Agora que estamos esclarecidos, minhas impressões sobre o evento.

O evento foi um sucesso. O pessoal da organização do CEFET-PE e de todos os grupos locais que ajudaram fizeram um ótimo trabalho. Confesso que fiquei assustado quando fiquei sabendo que havia mais de 700 inscritos. Era minha primeira apresentação para público externo e por um momento cheguei a ficar preocupado de encarar a possibilidade de uma platéia lotada.

Mas no final deu tudo certo. Tive uma ótima impressão da comunidade de software livre de Pernambuco. A participação do pessoal, por exemplo, esteve em alta durante todo o evento. Na sexta-feira, só consegui ir à noite e tinha gente que estava lá desde a manhã. Na verdade, a maioria do pessoal tinha chegado cedo. O auditório estava bem cheio para as palestras sobre PHP e as experiências do SERPRO com software livre. Não tinha só aquela meia-dúzia de gatos pingados que seria de se esperar ao final do dia.

Novamente, parabéns para a organização e obrigado pelo espaço que me foi cedido.

Próxima Página »


a