Por que você precisa (re)aprender linguagens funcionais?
Continuo investindo neste tema. Essa apresentação fiz em maio aqui no CESAR.
Café Ágil
Sábado passado (dia 15/05/2010) participei do evento Café Ágil promovido pela ThoughtWorks Brasil no Centro de Informática da UFPE. Neste evento eu apresentei o trabalho "TDD Direto das Trincheiras", mesmo trabalho que já havia apresentado no evento Agilidade na Prática em Novembro de 2009. Naquela oportunidade, deixei pra fazer a apresentação em cima da hora e ficou bem nojentinha (veja aqui), desta vez pedi ajuda a Jinmi Lee, que deu uma reformulada no ppt. Vejam a diferença:
Para uma comunicação eficiente é necessário que tanto o contéudo quanto a apresentação sejam bem feitos. Apenas com a união desses dois fatores será possível passar a mensagem de forma eficaz.
Voltando ao evento, as apresentações de Paulo Caroli e Jim Webber foram ótimas e a participação do público foi bem legal. Bastante interessante também a mesa redonda (a mesa era retangular mesmo), que além da minha presença e a do Paulo, ainda contou com a participação de Luciano Felix (Provider Sistemas), Cristine Gusmão (UFPE) e Alexandre de Vasconcelos (UFPE). Parabéns a todos pela organização e espero que tenha mais eventos desse nível por aqui.
Jogue fora sua IDE
Há algum tempo atrás, um amigo meu (Samuel) me disse que quando estava aprendendo algo novo (um framework ou uma nova linguagem) ele preferia usar o notepad ao invés de uma IDE. Naquele momento eu não dei muita importância, e ainda disse que era frescura, que usar uma IDE era bem melhor. Na hora eu não me dei conta, mas hoje vejo que eu já estava com IDE-dependência aguda.
Estou estudando Scala, e a primeira coisa que procurei para começar o estudo foi uma IDE para começar a dar meus primeiros passos. O problema é que não existe ainda nenhuma IDE que seja boa o suficiente para Scala. Primeiro tentei o Eclipse, mas o plugin está incrivelmente instável, não deveria ser nem disponibilizado para download. O Netbeans não está muito a frente e o IDEA é o melhorzinho, porém com muitos bugs também. Resultado, fiquei com o IDEA e comecei a trabalhar. Por conta dos problemas e dificuldades em pouco tempo eu travei. Perdi a paciência por usar uma ferramenta com tantos problemas e parei os meus estudos práticos.
E agora? Vou ter que esperar meses (ou anos) para que alguém desenvolva uma IDE boa o suficiente? E quando não existia ferramentas com esse nível de recursos? Como a gente se virava?
Quando eu comecei a trabalhar, usava Turbo C 2.0. Alguém se lembra? Não tinha syntax highlight, abria apenas um arquivo por vez e code assist nem pensar. Tinha copy and paste e lamba os beiços. E que saber? Era uma ferramenta muito boa. Era boa e produtiva pela simples razão que EU SABIA O QUE ESTAVA FAZENDO.
As ferramentas de hoje em dia são tão sofisticadas, tem tantos recursos e facilidades, que criaram uma geração de programadores que são absolutamente dependentes delas. Programadores que não são capazes de saber que método de uma determinada classe ele precisa chamar. Se não tiver um code assist eles simplesmente não sabem o que fazer (muitos não sabem nem com o uso do code assist).
Precisamos abandonar um pouco nossas IDEs. Precisamos (re)aprender as linguagens e frameworks sem o uso dessas facilidades. Só quando finalmente estivermos seguros sobre o nosso conhecimento é que estamos autorizados a usar as IDEs. Bye bye IDEA, seja bem vindo o Notepad. Agora finalmente vou APRENDER Scala. Depois de um momento de negação estou finalmente me curando da IDE-dependência. Samuel, você estava CERTO!
Porque linguagens funcionais são importantes
Dos 3 principais paradigmas de programação (funcional, imperativo e orientado a objetos), o funcional é o mais antigo. A primeira linguagem de programação funcional foi criada em 1955 (IPL) e a mais popular LISP foi criada em 1958. Apesar de surgirem um pouco depois (Fortran e COBOL foram criadas respectivamentes em 1956 e 1959), as linguagens imperativas tiveram maior popularidade. Mesmo sem ter alcançado o mainstream, o paradigma funcional continou recebendo investimentos ano após ano até meados dos anos 90, quando a turma das linguagens imperativas se fundiu definitivamente com o pessoal de orientação a objetos (C++ e principalmente Java são exemplos) enterrando as linguagens funcionais no lixo da história. Acabaram as esperanças desse paradigma se tornar parte do mainstream. Será?
O tempo passou e nos últimos anos alguns sinais começaram a aparecer. Erlang (linguagem funcional proprietária criada pela Ericsson) que foi banida e distribuida de forma open-source em 98, volta a ser utilizada pela Ericsson (e por muitos outros) em 2004. A Microsoft lança o F# (linguagem funcional para a plataforma .NET). O pessoal do Twitter reescreve seu back-end em Scala (linguagem funcional e OO para a plataforma Java). C# incorpora conceitos funcionais na sua linguagem para dar suporte ao LINQ. A Google publica artigos mostrando como utiliza o paradigma funcional para armazenar e recuperar dados. Porque esse interesse no paradigma funcional foi renovado? Qual o pulo do gato?
Devido a proximidade de limites técnicos e preocupação com consumo de energia, o pessoal de hardware está focando no desenvolvimento de novos processadores em soluções de múltiplos cores. Em breve teremos processadores com centenas de cores. Para se beneficiar deste panorama, temos que escrever softwares que executem de forma paralela. A boa notícia é que é muito mais fácil escrever código concorrente em liguagens funcionais do que em linguagens imperativas.
Não existe um único paradigma que seja indicado para resolver todos os tipos de problemas. Precisamos aprender (ou reaprender) o paradigma funcional, que foi abandonado por muito tempo. Precisamos de linguagens que incluam de forma coerente vários paradigmas, para que a gente possa escolher a melhor forma de resolver um determinado problema. Por fim, precisamos aprender Scala, que me parece a mais promissora nas novas linguagens multi-paradigma.
TDD direto das trincheiras
Essa foi a apresentação que fiz no evento "Agilidade na Prática" em 30/11/2009. Este evento foi promovido pelo SPIN Recife.
Sprint Planning Meeting II ou Sprint Design Meeting?
Qual o principal objetivo da reunião de Sprint Planning Meeting 2? 
Em muitos lugares você poderá encontrar uma resposta simplista para essa pergunta: O objetivo é dividir os itens do product backlog em tarefas de no máximo 8 horas (ou 16 em algumas fontes). Mas dividir como?
Durante a Sprint Planning Meeting 1, o time e o product owner selecionaram de comum acordo alguns itens para serem trabalhados durante o sprint em questão. Para chegar neste ponto, o time teve que discutir em mais detalhes cada item de backlog, tirar eventuais dúvidas e revisar algumas estimativas. Em função disso, podemos perceber claramente que se trata de uma reunião para discussão e esclarecimento dos requisitos. Até este momento estamos apenas trabalhando em cima do domínio do problema, ainda não entramos na solução.
No Sprint Planning Meeting 2 a cuíca muda o tom. Se pensarmos que o objetivo principal é apenas dividir os itens em tarefas, vamos estar na verdade apenas dividindo o problema, mas aqui precisamos na verdade é dividir a solução. Para chegar na solução o time vai ter que fazer design (análise & projeto), que é exatamente o objetivo desta reunião.
Agora, será que faz diferença? Será que dividir o problema é diferente de dividir a solução? Vejamos alguns exemplos:
Considere o item de backlog chamado Login do Usuário. Algumas possíveis tarefas para Sprint Planning Meeting 2 sem foco em design:
- Implementar tela de login
- Implementar serviço de autenticação
Muito bom, com esse conjunto de tarefas eu posso fazer o item de backlog, o problema é que agrega muito pouco e para efeito de planejamento é desastroso, afinal o time não sabe exatamente o que vai fazer em cada uma dessas tarefas. Tudo vai ser descoberto apenas na hora H. Neste cenário observamos que é muito comum a criação de diversas novas tarefas durante o sprint.
Vamos ver agora que tarefas eu poderia criar se tivesse realizado a reunião com foco em design:
- Criar tela de login
- Selecionar lib js para chamar serviço de autenticação via ajax (supondo que é ajax e uma lib ainda não foi selecionada)
- Criar serviço de autenticação
- Criar query com login=login e senha=senha
- Criar classe de Usuario (campos: login e senha)
- Criar método para criptografar a senha (escolher método)
- e por aí vai...
O que acontece no novo cenário é que a equipe se aprofundou na solução. Neste caso o time pôde definir melhor o escopo de cada tarefa, antecipar dúvidas e eliminar riscos. Mas afinal para que serve o planejamento?
Resumindo:
- Sprint Planning Meeting 1 = Requisitos
- Sprint Planning Meeting 2 = Design
E ainda assim: Sprint Planning Meetings = planejamento.
SQL ou NoSQL? Essa é a questão
Banco de dados relacionais fazem parte da nossa vida há muito tempo. SQL e abstrações (HQL por exemplo) fazem parte da rotina de qualquer desenvolvedor de sistemas de informação. Agora, será que o domínio dessa tecnologia vai continuar prevalecendo na era da Internet?
Gigantes da Internet como Google, Amazon, Facebook, entre outros, descobriram há um bom tempo que os bancos de dados relacionais não atendem suas necessidades, especialmente as relacionadas com escalabilidade. Essas empresas investiram em outro tipo de tecnologia para armazenamento e recuperação de dados. Hoje essas soluções são conhecida coletivamente como NoSQL.
Agora vem a grande questão, para onde eu vou: SQL ou NoSQL?
Cada opção tem sua aplicabilidade, não seja dogmático (muitos nas duas comunidades são) e aproveite o que cada tecnologia tem de melhor. A única coisa que quero alertar é que a opção por NoSQL é uma realidade viável. Claro que as soluções NoSQL ainda tem que comer muita farinha para chegar a maturidade, mas podemos enxergar nisso uma oportunidade de pioneirismo. Como desenvolvedores de software temos que estar preparados, então arregace as mangas e vá ESTUDAR!
Entenda os príncipios por trás das práticas
Como todo mundo já percebeu, Scrum virou moda. A maioria das empresas dizem que usam Scrum, porém poucas são REALMENTE ágeis. A principal razão pela qual isso acontece é porque as pessoas dessas empresas ainda não assimilaram os príncipios que estão por trás dos métodos ágeis. O entendimento e a adoção desses príncipios são fundamentais para ter sucesso com Scrum. Acredito que esse fenômeno aconteceu de forma similar com a adoção do RUP. Aqui está o material de uma apresentação que fiz sobre esse assunto.
Um Software de Qualidade
Eu vou falar um pouco mais sobre o WordPress porque acho que é um bom exemplo de um software de qualidade.
Vou começar pela instalação. Para instalar o WordPress, só é necessário verificar o "Famous 5-Minute Install". Pronto. Funciona de verdade. Na verdade não é você que instala o WordPress, ele se instala sozinho, você apenas manda ele se instalar. Não dá pra engolir softwares que só para instalar é preciso ler um livro cheio de procedimentos e depois acaba dando tudo errado e você ainda tem que ficar pesquisando na internet para ver ser descobre o que aconteceu.
Um dos procedimentos que ele faz na instalação é criar a estrutura do banco de dados. Hoje em dia não é difícil encontrar um framework que facilite isso (vide Hibernate), por então não fazemos isso sempre?
Outro exemplo que vi de como o WordPress é robusto foi quando eu resolvi mudar a configuração dos permalinks. Após alterar a configuração veja o que apareceu na tela:
Devido a minha escolha o wordpress precisava criar um arquivo .htaccess para atender minha necessidade, como ele sozinho descobriu que não tinha permissão de escrita no diretório, mostrou na tela as instruções detalhadas do procedimento que eu precisava fazer na mão para que os permalinks pudessem funcionar. Quantas vezes você já se deparou com algum erro desconhecido e teve que fuçar logs para descobrir qual o problema?
É verdade, Software Robusto demanda mais esforço mas devemos abrir mão da preguiça. Não podemos é abrir mão da qualidade dos softwares que escrevemos. Software frágeis acabam por consumir a falsa economia no desenvolvimento porque geram um imenso custo de suporte e manutenção. Siga o exemplo do Worpress.
Nova Infra
Resolvi abandonar o blogger.com e manter o blog por mim mesmo.
Fiz a opção de instalar o WordPress (que não conhecia) sem muita informação. Apenas achei que era o mais popular. E valeu mesmo a pena.
Estou realmente IMPRESSIONADO. O WordPress É MUITO BOM! A instalação foi muito fácil e a quantidade de opções que você pode customizar me chamaram a atenção. A quantidade de plugins disponíveis é quase ilimitada. Se você quiser montar um blog algum dia eu recomendo fortemente o WordPress.
Sobre o blog, por enquanto ainda não fiz muitas modificações, apenas escolhi um tema e algumas opções bastantes simples, mas penso que ao longo do tempo vou estudar um pouco mais e dar uma incrementada. Espero que gostem.