Saturday, May 10th, 2008
Eu me empolguei com computadores na primeira vez em que ouvir falar sobre eles. A possibilidade de comandar uma máquina, fazê-la executar o que eu queria e isso muito mais rápido do que qualquer coisa que eu poderia fazer manualmente era uma coisa saída das páginas de um livro de ficção científica–que, é claro, eu sempre li aos montes.
Minha primeira linguagem foi o Pascal. Eu tive a sorte de pular o Basic e partir direto para um linguagem mais poderosa, mais estruturada. Eu ainda me lembro da sensação de completar um programa particularmente complexo que implementava não só sua própria funcionalidade (um espécie de Paint que era requerido para o trabalho final de programação), como também toda uma família de objetos para interface gráfica com um loop de processamento de mensagens, controle de hardware. Esse era um código que ainda queria ter.
Poucos anos mais tarde eu estava programando na versão mais evoluída do Pascal, o Delphi. Eu já passara então por C, C++, Visual Basic (que me empolgou pela parte visual, é claro, mas cuja linguagem conseguia me irritar nos mínimos detalhes), e já tivera o meu primeiro contato com o mítico Lisp. Foram bons anos com Delphi, dos quais, ironicamente, só saíram três aplicações puramente desktop. Todos os demais anos que eu gastei com o Delphi foram em desenvolvimento Web. Eu perdi a conta de quantos ORM implementei, de quantos frameworks Web, bibliotecas e serviços construí. Foi uma época de aprendizado enorme.
Desde então eu já passei por dezenas de linguagens. Algumas profissionalmente, outras pelo mero prazer de descobrir uma sintaxe nova e ver o que há de interessante. Eu ainda não encontrei uma linguagem que não possui uma característica que a redimisse. Mesmo em linguagens que eu jamais usaria hoje para implementar um projeto a menos que fosse um requisito obrigatório passado pelo cliente, eu encontrei algo de interessante. Pode ser que o resto da linguagem tenha sido descartável, mas alguma coisa sempre era suficiente para justificar a existência da linguagem.
Smalltalk foi a linguagem que mais me fascinou. Foram anos antes que eu publicasse alguma coisa real na mesma, mas eu sempre experimentei com o que havia de interessante. Seaside, no mundo Web, ainda representa para mim o ideal de um framework Web atual.
Linguagens são arte. E arte é algo inteiramente subjetivo no aspecto de gosto e preferências. Mas linguagens também são ferramentas. E para isso, nada melhor do que pragmatismo. Mas a combinação dos dois pode produzir resultados fascinantes.
Eu sustento minhas próprias escolhas, entretanto. Eu não preciso de validação externa para entender o que é interessante e o que deixa de ser interessante. Eu acolho novos pontos de vista, e gosto de entender o que os outros vêem. E em última instância, eu também tenho preferências. Elas mudarão e eu não me preocupo com isso. Há beleza em qualquer lugar–em última instância, programação também é religião.
Thursday, May 8th, 2008
Eu não escolheria Rails para escrever uma aplicação Web que consistisse, em sua maior parte, em processamento fora da interface com o usuário, ou cujo maior ponto fosse uma API;
Eu não escolheria Django para uma aplicação cujo domínio fosse extremamente complexo, com modelos dinâmicos, tabelas construídas on-the-fly, e funcionalidades similares;
Eu não escolheria Seaside para uma aplicação que consistisse em recursos individualizados, independentes e cujo referenciamento fosse essencial;
Eu não escolheria ASP.NET para um site inerentemente visual, cuja interface externa com o usuário fosse a parte essencial da aplicação;
Eu não escolheria Castle Monorail para aplicações de pequeno ou médio porte em que manutenção fosse mais importante do que o desenvolvimento de nova funcionalidade;
Eu não escolheria Ruby para aplicações de rede onde o potencial de instabilidade fosse maior do que o normal;
Eu não escolheria Python para um ORM ultra-adaptável;
Eu não escolheria ASP clássico ou PHP puro para coisa nenhuma.
Tuesday, May 6th, 2008
Há pouco mais de um mês e meio cheguei em São Paulo para o início de uma aventura. Foi uma mudança em todos os sentidos: de uma cidade grande para uma cidade enorme; de um mercado corporativo, fechado para um mercado genérico, aberto; de uma empresa pequena para uma empresa cujos alvos são muito maiores e mais amplos.
Ainda não concluí o processo de mudança, mas esse está sendo sem dúvida um dos períodos mais empolgantes da minha carreira. Trabalhar no Brasigo tem sido uma experiência fascinante em múltiplos níveis. Fazia tempo que a pergunta “e eu ainda sou pago para fazer isso?” não me ocorria.
Voltar a trabalhar em equipe foi uma das coisas que só percebi como tinha sentido falta até estar no meio da galera. Contribuir para um produto e aprender zilhões de coisas novas–não só profissionalmente, mas pessoalmente–é algo que só um ambiente muito bom pode proporcionar. Poder trabalhar e se divertir, em um local bacana de passar as horas de trabalho é algo que não tem preço. Tem o fato que a equipe não vê a hora em que vou soltar uma palavrão, mas isso é algo em que vai ter que rolar um desapontamento básico. 
Mas também, como não fica empolgado: Rails, Wii, Scrum, conversas cabeça no meio do trabalho, BDD, arquitetura de produtos legais, hard-core programming, experimentos malucos, chefe desencanado, e até mesmo a cidade que não para e onde sempre tem alguma coisa interessante para fazer.
Bem, deu para perceber que eu estou gostando da mudança, mesmo com as confusões de arrumar local para morar e trazer a família. E, para não perder a oportunidade, estamos procurando mais gente para a equipe. Gente boa é sempre bem-vinda.
Monday, May 5th, 2008
No que tange a metodologias ágeis, eu concordo com o poeta: disciplina é liberdade. Principalmente quando o ambiente é muito heterogêneo e a entropia começa a tender ao infinitivo. Dito isso, disciplina não é controle e metáforas misturadas são uma porcaria completa.
Monday, May 5th, 2008
Em The Mythical Man-Month, Frederick Brooks afirma que a década após a publicação do livro não traria nenhuma “silver bullet“, isto é, nenhuma mudança de uma ordem de magnitude no processo de desenvolvimento de software através de alguma tecnologia nova. A afirmação já se sustenta há mais de 30 anos.
Pergunta: quando a inexistência de uma silver bullet se tornará um impedimento para a produção de software? Em outras palavras, existe um limite para o desenvolvimento com as tecnologias, ciência e ferramentas que temos hoje?
Saturday, May 3rd, 2008
Em mais uma edição atrasada, a gangue assume que é completamente xiita e decide falar mal de todas as linguagens de programação, com exceção das eternas favoritas de cada um, é claro.
Divirtam-se!
Friday, May 2nd, 2008
Depois de ler The Long Tail fiquei pensando sobre as aplicações do assunto para o desenvolvimento de software. Não em termos de produtos que podem ser entregues, mas dentro da própria aplicação, em uma curva de distribuição de uso.
Uma coisa é você ter itens que podem ser comercializados, outra coisa é você ter características que podem ser usadas e que possuem um determinado valor para o usuário final. Eu não tenho certeza plena–não cheguei a uma conclusão final sobre o assunto–mas acho que existe também uma cauda longa para características em um software qualquer que podem ser exploradas indiretamente.
Existe muito escrito sobre aplicações de regras 80/20 (ou X/Y para valores quaisquer) em relação à funcionalidade que se deseja criar para um aplicação, mas ainda não encontrei nada sobre customização. E talvez essa seja a cauda longa de aplicações: não o que está e não está, mas o que o usuário pode construir com as peças básicas que lhe forem fornecidas.E isso não é somente flexiblização, mas a habilidade real de montar novas interfaces/fluxos sobre o que existe e criar seus próprios recursos.
Não é algo que toda aplicação precisa, mas é algo que certamente tem um potencial incrível em ferramentas que dependem de uma agregação diversificada.
Bem, preciso pensar mais sobre o assunto. E vocês, o que acham?
Thursday, May 1st, 2008
Se março eu li pouco por causa da mudança, em abril eu li menos ainda por causa da movimentação no trabalho. Eu estava convencido de que chegaria ao final do mês sem terminar nada de significativo. O primeiro livro que consegui terminar de ler foi no dia 20 e isso graças a uma boa espera no aeroporto e a subseqüente viagem.
De qualquer forma, o resultado do mês foi o seguinte:
- 4 livros
- 5 filmes
- 14 episódios de séries
O primeiro livro do mês foi The Mythical Man-Month, o trabalho seminal de Frederick Brooks. Publicado pela primeira vez em 1975, e revisado para seu aniversário de vinte anos, o livro permanece absolutamente atual e–mesmo as partes em que ele parece datado por causa da referência a tecnologias e práticas obsoletas contém material fascinante e absolutamente essencial para a compreensão do mundo em programadores operam. O livro, sobre o qual espero escrever mais futuramente, é uma coleção de ensaios que foi revisada e expandida em sua última edição. Dos ensaios, os dois mais famosos são o que dá nome ao livro e No Silver Bullet. Eu fiquei especialmente fascinado pelos pararelos entre Scrum e o livro.
De qualquer forma, esse é um livro que absolutamente todo programador (e de fato, toda e qualquer pessoa envolvida no meio de desenvolvimento) deveria ler. É um raro prazer encontrar um texto que permanece válido em todos os seus pontos essenciais depois de tanto tempo e conter tantos aspectos práticos para o dia-a-dia de desenvolvimento.
Na mesma linha, li em seguida The Long Tail, de Chris Anderson. O livro é uma expansão do seu famoso artigo na Wired e contém análises mais profundas do que o artigo oferecia. A essência do livro é que o mercado segue uma linha de distribuição em que a maioria das vendas são feitas no início da curva por razões de escassez, mas que existe toda uma cauda na curva (daí o título do livro/ensaio) que pode ser convertida em um enorme potencial de vendas e distribuição. O livro é uma fascinante exploração das razões e potencial de utilização da cauda longa e oferece muito mais do que uma simples expansão do artigo. Embora Anderson se limite a uns poucos mercados por razões de espaço, as explorações que o leitor pode fazer por conta própria são muitas. Esse é outro assunto que eu quero explorar aqui no futuro e estou especialmente interessado nas aplicações da cauda longa não para mercados mas no desenvolvimento de aplicativos e serviços em si.
Depois disso, Interface, por Neal Stephenson e George Jewsbury, que é um thriller político de primeira categoria. Embora seja de 1994 e ligeiramente datado em alguns aspectos, é ultrajante a capacidade que Stephenson tem de prever o futuro. Chega a ser estranha a forma como algumas partes do livro parecem refletir a realidade de 2008, não só nos Estados Unidos mas para o resto do mundo. Essencialmente, o livro é a estória de uma coalizão sombria que tenta manipular um candidato a presidente dos EUA implantando um chip em seu cérebro. A estória se converte em uma crítica seca e perspicaz do modelo político dos EUA, dos meandros do mecanismo de eleição e publicidade, e do próprio papel que as pessoas devem ter no mesmo. Vale cada palavra.
Para fechar o mês, li Sun of Suns de Karl Schroeder. Eu já tinha lido e gostado bastante de seu Postsingular e também gostei desse que é o primeiro livro em sua trilogia chamada Virga. O livro é sobre Virga e seus habitantes, um mundo sem gravidade, que na verdade é uma balão com cinco mil milhas de diâmetro orbitando uma estrela distante onde os habitantes desenvolveram uma cultura particular de cidades bizarras que são rodas gigantes gerando um pouco de gravidade e sóis artificiais sem os quais o “inverno” tomaria conta de tudo. Nesse ambiente, política, pirataria, e amor de misturam em um conto de vingança e–pelo menos parcialmente–rendenção. O final foi aberto demais, mas considerando que o livro é o primeiro de três, faz sentido. Bom o suficiente para me incentivar a ler os próximos livros pelo menos.
Nos filmes, destaque para Atonement, com Keira Knightley e James McAvoy, em uma bela estória sobre pequenos erros que se convertem em enormes problemas e que assombram pessoas até o último dia de suas vidas, Bela narração, bela fotografia e seqüências memoráveis.
Assisti também Cloverfield que me pareceu mais um exercício em futilidade. Ao contrário das resenhas sobre filme de terror/suspense da década, eu vi só um monte de correrias, e uma tentativa de esconder um monstro nada impressionante por trás de uma teia de diálogos vazios e superficiais.
Iron Man, se não foi profundo, foi pelos menos divertido o suficiente para valer a entrada. Robert Downey Jr. está mundo bem no papel de Tony Stark, conseguindo fazer o papel de herói e de playboy ao mesmo tempo sem perder o passo. Não conheço tanto da mitologia do personagem, mas a representação dele ao longo do filme foi muitoboa e completou muito bem as cenas de ação. Os outros atores também estão muito bem.
Nas séries, gostei bastante de Terminator: The Sarah Connor Chronicles. Vi todos os episódios já produzidos e acho que a série pode se converter em um bom adendo aos filmes desde que não caia em um círculo de estória. Mais detalhes na resenha que escrevi. As demais séries continuam como de usual.
Próximo mês, espero não chegar aqui e dizer que não li ou vi nada.
Wednesday, April 30th, 2008
Durante o FISL, eu tive a oportunidade de assistir a palestra sobre Seaside dada por Randal L. Schwartz, nome famoso nas comunidades livres, principalmente de Perl, e que agora está evangelizando Seaside e Smalltalk.
Perguntei se podíamos conversar um pouco e ele aceitou graciosamente. O resultado está abaixo, em uma tradução livre:
- Conte-nos um pouco sobre o seu background, como e quando você começou a programar e o que você está fazendo hoje
Eu aprendi a programar sozinho quando tinha nove anos. Quando cheguei aos quinze, já estava na frente de uma classe, ensinando meus colegas, e escrevendo código sob contrato durante os fins de semana e sendo pago de verdade.
Trabalhei para várias empresas ao longo de oito anos antes de criar a Stonehenge em 1985. A Stonehenge cresceu ao longo dos anos; nós hoje podemos contar 17 das empresas no Fortune 100 como nossos clientes.
Hoje eu gasto a maior parte do meu tempo dando palestras e escrevendo, mas ainda projeto, crio e revejo código também. Também respondo questões gratuitamente durante uma hora por dia nas dezenas de listas, blogs e comunidades Web das quais participo.
- Você é extremamente famoso na comunidade Perl, mas agora está advogando Smalltalk e Seaside. O que mudou? Quando você realmente começou a usar Smalltalk?
- Eu comecei a usar Smalltalk antes de Perl ser inventada, em 1982. Já escrevi sobre a história no meu blog.
- Quais são as vantagens de Smalltalk sobre outras linguagens tradicionais como Perl, Ruby ou Python, por exemplo?
Smalltalk tem uma sintaxe muito simples: eu posso ensinar a sintaxe completa a alguém em cerca de 20 minutos, e, de fato, a incluo em minhas palestras introduzindo as pessoas ao Seaside. As principais implementações Smalltalk (com exceção de GNU Smalltalk) também possuem IDEs maduros permitindo a fácil exploração do código, de modo que aprender as bibliotecas é somente uma questão de olhar a implementação e uso das mesmas
E isso também é um bônus: nós temos duas implementações comerciais (Cincom e GemStone/S) e duas abertas (Squeak e GNU Smalltalk), todas suportando Seaside. Isso permite que gerentes mais preocupados, que podem hesitar ao selecionar uma linguagem estritamente suportada por voluntários, escolherem entre dois provedores comerciais para suporte. Opções são sempre boas!
- Você acha que Smalltalk finalmente vai alcançar status mainstream, isto é, ganhar aceitação do mercado em geral?
Bem, Smalltalk tinha status mainstream no meio dos anos 90, logo antes de Java entrar na história, pelo menos do que tange a firmas grandes de Wall Street e outras instituições que desejavam desenvolvimento rápido de GUIs para ficar à frente da competição.
Mas sim, eu acredito que Smalltalk está posicionada para entrar o mercado novamente como um grande player. Para mais detalhes, veja meu artigo sobre O Ano do Smalltalk.
- Sua palestra tinha o título, “Seaside: Seu Próximo Framework Web”. O que há de tão interessante sobre o Seaside?
Eu gosto da forma como Seaside consegue abstrair tanto o fluxo de controle (ao longo de um eixo) e a representação (ao longo do outro eixo) com relativa facilidade. Seaside parece colocar as coisas certas relacionadas perto uma das outras. Eu também gosto do “depure uma página com erro dentro da própria página”: quando algum erro aconteceu, eu posso explorar a situação dentro do depurador normalmente, consertar o que está quebrado, limpar a bagunça, e continuar a execução da página como se nada houvesse acontecido.
Da mesm forma, a persistência tradicional em Rails é feita através do Active Record, que requer que objetos passem por um mapeador objeto-relacional para chegar em SQL. Seaside pode fazer a mesma coisa (via GLORP), mas possui soluções melhores pulando inteiramente o mapeamento, e usando coisas como Magma (OODBMS), que é aberto, ou algo como GemStone/S Virtual Machine, que é comercial. Quando você tira a camada ORM, voc&e ganha muita velocidade e um ambiente de programação bem mais confortável.
- O que você vê no futuro do Seaside, e como esse futuro se compara ao dos outros frameworks?
- A equipe do Seaside está agora no processo de refatorar e re-empacotar o Seaside para tornar a portabilidade ao longo de várias plataformas algo mais facilmente gerenciável e modular. Isso permitirá que cada desenvolvedor use somente as partes que desejar. Eu também estou vendo vários add-ons sendo criados, como o Pier CMS e várias APIs para coisas como Google Graphs e assim por diante.
- Você acha que o mercado está pronto para o Seaside?
- Sim. O Rails reabriu as discussões sobre o que fazer em um mundo após o Java, voltando para linguagens com late-binding como Perl, Python e Smalltalk. E Seaside é um framework maduro, ainda mais velho do que Rails. Somente não tão conhecido. Eu espero mudar isso.
- Você já colocou algo em produção com o Seaside? Se sim, quais foram os desafios?
- Eu estou trabalhando em alguns projetos agora, mas nada público. O desafio inicial foi a relativa falta de documentação, o que me forçou a gastar dois dias passando por todos os e-mails na lista de discussão. Fiquei mais informada, mas definitivamente com os olhos cansados. Eu espero devolver esse conhecimento escrevendo em meu blog e ajudando a responder questões no IRC e lista de discussão.
- Você agora é parte do Squeak Foundation Board. Quais são seus planos para a Squeak Foundation?
- Minha preocupação primária agora são questões de licenciamento, controle das releases e publicidade. Todas essas questões já estão sendo trabalhadas, é claro, mas todos somos voluntários e sempre estamos procurando mais voluntários para ajudar.
- A Squeak Foundation tem algum plano para Seaside?
- Nada formal, até onde eu sei. Entretanto, como Squeak é a plataforma primária para desenvolvimento do Seaside, eu tenho certeza de que Seaside será um componente principal nesse área.
- Quais são os planos mais interessantes dentro do mundo Smalltalk/Seaside atualmente?
- Bem, o que me envolve no momento é o GLASS (GemStone/Linux/Apache/Seaside/Squeak), uma solução da GemStone para que pessoas possam conseguir rodar Seaside rapidaemnte. Isso também envolve levar o pessoal da GemStone a criar uma solução comercial de custo zero, mas ainda funcional (mesmo que de forma mais limitada) do GemStone/S. Com essa versão gratuita, uma pessoa poderá construir um negócio, e quando o negócio exceder as capacidades da versão, migrar sem problemas para licenças maiores e ainda razoáveis. É um bela solução para uma VM Smalltalk sólida e comercialmente suportada com persistência e clustering já presentes.
- E sobre o próximo ano do FISL? Como você conseguiu três dias inteiros para Smalltalk?
- Bem, como eu disse, “tudo começou com algumas doses de caipirinhas…”
- Quais são os seus planos para esses três dias? Você tem a intenção de trazer outros Smalltalkers?
- Eu estou trabalhando com os organizadores do FISL e vários outros provedores de soluções e grupos dentro da comunidade Smalltalk para produzir uma mini-conferências. Espero ter treinamento inicial e avançado de Smalltalk, e vários tutoriais de Seaside. Expero que a conferência possa atrair um número significativo de desenvolvedores Smalltalk para o FISL pela primeira vez, e expor os demais participantes à linguagem, de modo que todos ganhem.
Muito obrigado, Randal, pela entrevista.
Monday, April 28th, 2008
O Lucas Húngaro me perguntou:
[Q]uais os benefícios que você está vendo no Scrum em relação à maneira que normalmente é usada pra desenvolver software? O impacto positivo na qualidade está sendo sensível?
Vocês usam também práticas do XP como integração contínua?
Eu estou longe de ser um especialista no assunto–quarta-feira agora termino o meu terceiro sprint–mas posso falar um pouco sobre a experiência que estamos tendo como equipe. Se eu falar besteira, a maioria da equipe tem blog e pode me corrigir (ou matar, dependendo da quantidade de besteira).
Apenas para esclarecimento, como já foi mencionado muitas vezes em material sobre o assunto, Scrum e XP são complementares no sentido de que um trata sobre o processo de desenvolvimento e o outro sobre o próprio desenvolvimento. Em outras palavras, um está mais na esfera gerencial enquanto o outro mais na esfera de produção.
O que eu vi no meu treinamento inicial e, obviamente, nesse três primeiros sprints me convenceu de duas coisas:
- O Scrum não é uma silver bullet
- O Scrum é apenas uma questão de bom senso
O primeiro fato é bem óbvio: se o Scrum fosse realmente uma silver bullet, sua adoção seria bem maior e os resultados seriam ganhos de produtividade tão imensos que estariam abalando a indústria nesse momento. O Scrum é muito bom, mas responde por somente uma das facetas de todo o processo de desenvolvimento.
Sobre o segundo fato, o Scrum é uma forma do velho acordo de cavalheiros, uma coisa que está cada vez mais distante de nosso realidade “moderna”. É uma proposta simples: o gerente diz o que precisa, os desenvolvedores dizem o que podem fazer–ambos sendo honestos entre si–e um acordo é feito sobre a produtividade dentro de um período. Nada mais e nada menos. Essencialmente, o Scrum é uma ferramenta que depende de uma comunicação honesta entre as duas partes envolvidas e que possui mecanismos para garantir que a comunicação continue honesta–ScrumMasters, taskboards, e burndown charts são só maneiras de garantir que a comunicação e o bom senso continuem sendo aplicados ao longo do sprint, o período convencionado para o desenvolvimento das características combinadas.
Nesse sentido, os benefícios, na minha opinião, são:
- Controle de expectativas
- Visibilidade de processo
- Comunicação facilitada
O impacto na produtividade e qualidade são medidos dentro desses três prismas e são bem interessantes. Obviamente, dentro do que o Scrum estabelece, há uma exigência de que todos comprem a idéia do mesmo. Uma equipe no processo caótico usual onde o gerente desconfia dos desenvolvedores, estabelece prazos irreais, e onde os desenvolvedores estão sempre dando estimativas incorretas por medo das conseqüências, não consegue, de forma alguma, usar o Scrum.
Quanto todos estão na mesma página–e 90% do Scrum é isso–a qualidade começa a aparecer porque o controle das expectativas é formalizado, o processo é transparente e todo mundo consegue acompanhar e resolver os problemas tão logo aparece, e a comunicação chega ao seu nível ideal.
Finalmente, em relação ao XP, estamos experimentando com o mesmo. No momento, estamos usando pair-programming e estamos bem satisfeitos com o incentivo que o mesmo está dando à equipe. A princípio, usar TDD e alocar duas pessoas em uma única tarefa parece contra-producente mas o efeito é realmente o contrário.
Estamos fazendo integração contínua e é fácil para todo mundo acompanhar o que está acontecendo. É claro que, como estamos relativamente no começo, há muita a evoluir. Mesmo assim, os resultados tem sido interessante.
Voltamos então à pergunta: compensa? Do que eu vi até agora, a resposta é sim. Quando se tem uma equipe e você precisa resolver os problemas Brookianos normais, Scrum é o que até agora me pareceu mais interessante. Provavelmente não se aplica em todas as situações, mas para o que estamos fazendo está funcionado muito bem.
Espero ter respondido à pergunta do Lucas.
