Lendo os ThoughtBlogs hoje achei uma ótima apresentação feita por John Johnston. A idéia é introduzir os conceitos de agilidade no ponto de vista de um analista de negócios.
O tópico já tem oito páginas. Acho que chega à 10. Por mais que minha mão coce para comentar lá eu não vou, simplesmente porque já tive problemas demais com o pessoal do Mentawai.
De qualquer forma sempre me preocupa a possibilidade de algum desenvolvedor ler o tópico e pensar “Poxa, se esses caras que fazem todos estes frameworks não usam testes por que eu vou usar?”.
Desenvolvedores profissionais escrevem testes. Simples assim.
Uma pessoa que não ganha milhões de dólares mas escreveu uma das obras mais clássicas deste ramo deixa bem claro em sua primeira aula que programar é gerenciar complexidade. Nós precisamos gerenciar complexidade o tempo todo, por isso criamos funções, objetos e tudo mais. Não adianta, mesmo Einstein teve que provar que suas fórmulas e execuções estavam corretas, que poderiam ser verificadas. Na faculdade aprende-se isso desde as cadeiras básicas (e o fato de ser esquecido como “coisa teórica inútil” me faz novamente perguntar sobre o valor do ensino formal).
Existe uma grande diferença entre fazer Test-Driven Development e testar. TDD é sobre modelagem de objetos e especificações, não sobre testes (tanto que Behaviour Driven Development está se consolidando como algo mais eficiente que TDD) apesar de que no final você acaba ganhando uma suíte de testes de graça.
É muito difícil achar um projeto open-source relevante que não tenha testes. Na verdade os projetos decentes só aceitam um relatório de bug ou um patch se vier acompanhando por um caso de testes. Imagine uma aplicação feita colaborativamente por diversas pessoas, como saber que o que eu acabei de fazer commit não vai quebrar o que você modificou ontem? Boas práticas de orientação a Objetos? Não se iludam, OO não foi feita para este tipo de verificação! Com boas práticas você consegue minimizar o impacto de mudanças diminuindo dependências mas você não vai ter certeza disso.
Eu sinceramente não sei que técnica é essa que faz programação defensiva evitar testes. Eu já li bastante sobre Orientação a Objetos e programação defensiva e não vi nada deste tipo, pelo menos não vindo de uma fonte com um mínimo de credibilidade. Um exemplo simples, imagine que o framework web imaginário Pagai possui um código parecido com este:
Acao acaoSendoExecutada = controladorPrincipal.acao(requisicao.acaoDesejada());
Simples, não? Agora imaginemos que o código do método acao(String) seja algo assim:
public Acao acao(String pathInvocado){
//verifica se acao possui o formato desejado, deve ter uma barra e deve ter dois itens separados por barra apenas
if((pathInvocado.indexOf("/") == -1) || (pathInvocado.split("/").size < 2)) throw new IllegalArgumentException("Path invocado ["+pathInvocado+"] nao possui o formato adequado (consulte a documentacao XYZ)");
//lógica...
}
Isso é programação defensiva: eu não estou aceitando o que me passam, eu verifico se é o que deveria e se for eu continuo, se não eu paro ali mesmo e deixo alguém tomar conta do problema, seja a classe em questão ou alguma outra mais acima.
Imagine que eu por engano commitei um código que utilize “” em vez de “/” nesta requisição. Se for numa parte central do código é bem possível que uns testezinhos peguem mas imagine que é utilizado apenas em um caso específico e que, por um acaso, eu baseei meu sistema de controle de jatinhos particulares 9meu chefe tem muitos jatinhos) nele. Quando eu fiz o comit não alertou. Quando eu fiz o build não alertou. Quando eu fiz meus testezinhos não alertou. Quando foi para a produção eu tive erro.
Ok, acontece. Programadores de qualquer tipo cometem erros. Eu vejo o problema muito rapidamente e o corrijo, temos uma versão beta em 15 minutos no ar, fantástico. Aí daqui há um mês outro programador comete o mesmo erro. Quando fizer o build não vai alertar. Quando fizer seus testezinhos não vai alertar. Quando for para a produção… Isso não é profissionalismo.
O que eu preciso é de uma suite de testes, unitários e de integração, que me digam que o sistema está incorreto já no processo de build, sem lançar jars beta, alfa ou gama.
Mas se tem um argumento nessa história toda que realmente me irrita é quando as pessoas dizem que “num mundo capitalizado não há tempo para testes” ou que “o cliente não quer saber como é feito, ele quer que funcione”. O cliente realmente não quer saber como funciona, ele quer que funcione. Mas ele também não vai querer saber que você alterou uma classe que usava barra para barra invertida e tudo parou de funcionar, ele quer que o problema não aconteça e se acontecer que seja corrigido rapidamente. Se seu sistema não tem qualidade -e testes fazem parte de qualidade- você não consegue isso. TI gasta fortuna das empresas reescrevendo sistemas simplesmente porque não foram feitos por profissionais, e profissionais se preocupam com a qualidade do que fazem. E isso inclui testes.
Não seja um amador.
Um amigo outro dia me perguntou que tipo de arquitetura eu usaria num caso bem peculiar. Basicamente ele foi encarregado de definir a arquitetura corporativa de um grande banco, ou seja: definir hoje a forma como aplicações serão construídas pelas próximas décadas. Basicamente ele vai se ro cara que vai ser xingado por algumas centenas de programadores nos próximos tempos, não importa que arquitetura escolha.
Há poucos dias atrás falamos aqui sobre arquiteturas de referência e seu efeito danoso. Geralmente quando alguém tem à frente um desafio desse ele logo pensa em um modelinho que mostra obriga o uso de uma meia dúzia de frameworks e padrões (clássico moderno: Struts/JSF e JPA, clássico vintage: Struts 1.1 e EJB/DAO). Para melhorar ainda é incorporado um conjunto de classes “utilitárias” feitas com práticas que talvez tenham servido para um projetinho piloto mas hoje em dia só atrapalham.
Ainda assim uma arquitetura corporativa é algo interessante. Quando empresas grandes não possuem uma macro-arquitetura acabam crescendo de maneira desordenada e criando dezenas de aplicações redundantes e gambiarras de integração entre sistemas. Note no entanto que uma arquitetura corporativa não é uma arquitetura de referência, a arquitetura corporativa não fala sobre como implementar aplicações mas sim provê guias sobre como integrá-las, define as relações previstas em no ecossistema que é uma grande empresa.
Quais são as melhores macro-arquiteturas que você conhece? Eu consigo pensar em algumas: Apache, UNIX, World Wide Web… Nestes ecossistemas aplicações novas surgem, são alteradas e morrem todos os dias há décadas, um sistema criado com a tecnologia mais recente de 2007 vai rodar tranqüilamente neste ambiente. Por quê?
Porque estas arquiteturas se baseiam em primitivas e contratos, não em especificações rígidas. Criar um módulo para o Apache , um programa para rodar em UNIX ou uma site é basicamente criar um programa de computador em uma das plataformas suportadas que obedeça a um contrato.
Uma boa arquitetura corporativa vai definir algumas políticas e contratos para a aplicação se relacionar com o meio-ambiente e só isso. No caso do banco, poderíamos definir que uma aplicação deve disponibilizar via uma interface POX/REST seus WebServices, que ela deve utilizar a API do Mogile FS para guardar dados em disco, que cache deve ser feito utilizando a API do memcached.
E se o arquiteto quiser sair do padrão? Ótimo, saia, mas ele deve oferecer compatibilidade com o ambiente.
E se eu já tiver comprado um sistema que faz WebServices via SOAP? Eu preciso criar um meio de disponibilizar estes serviços via POX/REST também. Pode ser uma adaptador simples, um ESB, o que quer que seja. É como quando você compra um equipamento eletrônico com tomada americana, você não vai mudar uma tomada na sua casa para o padrão exótico, vai é comprar o adaptador necessário para plugar ele nas tomadas do seu ambiente.
Mas e se não precisarmos de filesystem distribuído? E se já estivermos utilizando uma solução de cache que faz mais sentido nesta aplicação?
Ótimo, use. O uso de filesystem X, cache Y, banco de dados Z deve ser um guia. Toda vez que alguém precisar de uma solução de cache, filesystem, etc. ele olha o guia da empresa, se não servir ele usa algo que sirva. O que importa é que o uso fique encapsulado no sistema. Imagine que ao invés do Oracle 10g eu resolva usar um MySQL na minha aplicação. Está ótimo mas eu devo manter essa peculiaridade interna à minha aplicação. Os outros sistemas que vierem a se comunicar com o meu não devem precisar saber sobre a existência deste banco, eu não posso usar este banco para comunicação entre aplicações (o que já é uma coisa péssima para se fazer de qualquer forma).
O que importa é:
Para ser um bom arquiteto não é necessário ter tanta experiência assim, basta saber olhar os casos de sucesso e aproveitar o que funciona. Geralmente as técnicas utilizadas nestas arquiteturas são também catalogadas como Padrões Arquiteturais em livros. Um bom arquiteto tem que ser um ávido leitor de livros e de código.
Mais um ano vai, outro ano vem e o Conexão Java está aí. Este é certamente o evento mais descolado da comunidade Java do Brasil.
O CJ é um grande encontro entre as pessoas que participam em fóruns como o GUJ, o PortalJava e o RioJUG. O foco do evento são os mini-cursos que agem na formação de novos profissionais. Bem, formação não exatamente, ninguém sai de um curso de meioa dúzia de horas especialista em nada mas é uma boa oportunidade de ter contato mão-na-massa com algumas tecnologias e técnicas.
Este ano a estrela do evento é ninguém menos que Carlos Villela. Radicado em Londres pela ThoughtWorks há… bem, há alguns anos… o cv vem falar de algo bem atual: o declínio dos arquitetos monoglotas.
Também teremos algo um pouco diferente. Possivelmente deve haver um repeteco da minha palestra sobre arquitetura do JustJava 2007 (infelizmente sem o Paulo que vai estar de férias) mas enquanto isso é confirmado ficamos com mais uma atração: Oficina do Arquiteto.
Essa é uma idéia meio maluca que acabamos de fechar, vai funcionar mais ou menos assim: alguém traz uma arquitetura -seja de um projeto existente, livre ou de uma empresa, ou desenhado na hora- e nós debatemos esta. Na conversa vão sobrar padrões arquiteturais, guidelines e uma boa dose de bate-papo sobre o que nós, arquitetos, estamos fazendo por aí. Se você já tiver alguma idéia me adiante por email para organizar melhor as coisas, eu vou preparar algumas arquiteturas clássicas para usarmos quando não houver nenhuma na roda. A idéia é bem simples: debate, informação e diversão.
Mais um texto no fragmental.tw, desta vez algo mais genérico sobre modificações em linguagens. Eu ando lendo bastante sobre linguagens embutidas em outras (DSLs Internas) e outras formas de modificação de linguagem como Fluent Interfaces. É bem complicado chegar à qualquer conclusão em temas tão abstratos mas a experiência no uso destas técncias no dia-a-dia e no laboratório me mostraram que existem diferenças entre as formas de alterar uma linguagem. Em Language-Oriented Programming você cria linguagens, com Fluent Interfaces não.
Bom, mais sobre isso em Language Adaption.
Como alguns sabem eu tenho um blog em inglês onde o foco é na minha linha de pesquisa atual: Domain-Specific Languages e Language-Oriented Programming. Eu venho psotando sobre minhas experiências brincando com este “novo” paradigma e acabo de postar o rascunho de um primeiro artigo sobre o tema. Comentários são mais que bem-vindos.
Duas rapidinhas sobre Microsoft .Net:
Update: Enfim o Paulo publicou.
A palestra com o paulo foi sensacional. Muita gente me perguntou ao final da palestra qual minha relação com a Caelum, se sou instrutor de lá ou coisa do tipo. Bem, não :)
Além de ser amigo do pessoal da empresa eu acredito fortemente na proposta de trabalho da Caelum, mas não tenho nenhum vínculo empregatício, comercial ou que quer que seja com eles.
Eu simplesmente acredito que o nível de treinamento que alguém obtém lá é bem superior ao treinamento pasteurizado dado pelos centros de treinamento que eu conheço. A palestra em si foi prova disso, nós falamos sobre tecnologias e técnicas que não são vistas nos ‘cursos de arquitetura’ normais e sobre como as tecnologias que de fato fazem parte do programa destes cursos quase sempre é antiquada e/ou inadequada. É uma empresa que consegue sair do commodity que é treinamento Java hoje em dia e trazer algo de valor, geralmente por um preço muito mais acessível.
Os slides devem estar disponíveis no site da Caelum em breve.
Esse debate no GUJ me mostrou umas coisas engraçadas. Eu já tinha idéia de como as pessoas não têm noção das dificuldades em manter um portal no ar, porque eu mesmo não sabia e porque entrevistei algumas dezenas de pessoas neste meu ano no setor, mas não deixa de ser engraçado.
Quando eu trabalhava numa pequena agência web, lá pelos idos de 2000-2002, eu atendi a muitos grande clientes. Petroleiras internacionais, bancos de investimento, bancos convencionais, fundos de pensão… para todos eu participei do desenvolvimento de sistemas web às vezes muito simples, ás vezes muito complexos. Existia um padrão neste segmento de sites institucionais feitos por pequenas agências, não sei se é assim hoje em dia mas era:
Eu trabalhei com diversos CMS, na época todos os que prestavam eram pagos e caros. Para clientes pequenos usávamos o Publique!, para clientes maiorzinhos o Calandra, para clientes maiores o Vignette, para monstros que precisavam não de um portal mas de GED o Dcomentum e algumas vezes os caras pediam para trabalhar com Microsoft SharePoint. Minha opinião após algumas dezenas de projetos: Nenhum deles prestava (e duvido que prestem hoje).
Quando fui convidado para entrar para o mundo dos portais fiquei um pouco preocupado. Desde meus tempos na agência eu já havia trabalhado com sistemas de billing, telecom, logística, análise de risco e vários outros domínios complexos com sistema mega-complexos que de tão caros são cobrados em Euros e não dólares. Milhões de Euros, na verdade. Mas topei porque quem me fez a indicação é uma pessoa que sei que não me indicaria uma furada.
Veja só minha surpresa quando descobri que para um destes mega-portais de Internet um CMS não é opção. Ok, muitos deles até usam soluções dessas, meu empregador inclusive, mas apenas para uma parte muito pequena e repetitiva do trabalho. Para tudo que não puder ficar em cache o buraco é bem mais embaixo.
Mesmo para conteúdo cacheado, você acha que é simples manter uma página sendo acessada por milhões de pessoas num intervalo de tempo muito curto? Eu vejo quando uma pessoa na minha equipe evoluiu porque ela começa a ler sobre redes, gerenciamento de memória, etc. Outro dia um cara muito bom mas muito focado em Java que trabalha comigo recebeu uma reclamação de que a aplicação estava gerando um load muito alto nos servidores. Ele teve que se virar para entender o que é o load de um servidor e porque o CPU não fica em 100% mesmo quando o load atinge duas casa decimais. Daí a coisa evoluiu para entrar no servidor e ficar tirando thread dumps (que muitos nem sabem o que é) para analisar o sistema, depois olhar o fonte do java.util.HashMap e identificar um problema de loop infinito que acontecia nesta classe somente quando havia uma grande concorrência. É engraçado, o cara entra com aquela mentalidade de ‘analista/desenvolvedor JEE’ e sai como um profissional de verdade. Eu acho que todo mundo devia trabalhar num lugar assim, ou fazer estágio ao menos.
E aí as pessoas dizem que os nove sites citados lá pelo estudo são simplezinhos e por isso usam LAMP. Isso é muito protecionismo, meu Zahl…
Java é uma boa plataforma para vários casos, mas não para todos. O modelo de IPC pobre, o deployment caixa-preta e a falta de uma meta-programação de verdade afetam fortemente a plataforma mas não é nada que não se consiga viver com. O ponto é que as outras plataformas possuem também suas diversas vantagens em vários casos, entre eles sites como os citados. Cada vez mais os portais possuem maior lógica na Camada (Tier) de apresentação. Os sistemas que temos desenvolvido no meu dia-a-dia de portal geralmente são compostos por um site que possui lógica de aplicação e acessa vários serviços.
A lógica de aplicação eu sinceramente mudaria para Rails sem pensar meia vez. O único ponto que me faria ponderar a princípio seria performance, ironicamente Java é hoje uma das mais performáticas plataformas disponíveis, mas mesmo hoje performance é garantida através de outros meios como caches e hardware (nota: existem poucas coisas que deixam um sistema tão lento quanto construí-lo usando um CMS).
A parte de trás da aplicação, onde ficam os serviços, não seria tão simples. Alguns serviços podem ser migrados para plataformas leves sem pensar duas vezes (muitos deles já estão em PERL e PHP, na verdade) mas assim como faz o Flickr eu usaria Java em alguns deles (o flickr é em PHP e usa Java para upload).
O ponto não é usar ou não Java. O ponto não é Ruby on Rails ganhar de Java no caso XYZ. O ponto é usar ferramentas certas nos lugares certos. Devia fazer parte da ética profissional este tipo de coisa…
Esse post no GUJ me fez pensar sobre a melhor maneira de absorver algo como o Rails. Rails é uma plataforma de desenvolvimento altamente produtiva e boa parte da produtividade vem do fato de que não é preciso abstrair um domínio na linguagem.
Desenvolvimento de aplicações web é um domínio que inclui diversos conceitos e abstrações. Vejam por exemplo uma sessão web. Se uma pessoa ler sobre o protocolo HTTP em si vai perceber que não existem sessões, o protocolo não mantém estado entre as requisições. Para burlar este problema nós utilizamos cookies ou URIs especiais para informar ao servidor o ID da sessão do cliente. Este é um conceito.
Em Java (ou outra plataforma parecida) vamos abstrair a sessão em uma classe. É desta forma que trabalhamos em Java: criamos classes para representar os conceitos do domínio.
O problema é que até conhecer o suficiente para utilizar de maneira adequada esta abstração na forma de classe você precisa conhecer o que é uma classe e todos os conceitos derivados desta. Basicamente não se consegue criar algo razoável sem saber um mínimo de programação orientada a objetos.
E como Rails resolve isso? Rails abstrai boa parte destes conceitos na linguagem. Ruby é uma linguagem OO e é possível representar a sessão da mesma maneira que se faz em Java mas este não é o meio utilizado em Rails e esta forma de representar as coisas é seu maior diferencial.
Uma sessão em Rails está embutida implicitamente dentro do controlador. Trabalhar com elas é muito simples, para efeito de comapração é como se seu controlador em Java herdasse uma classe que possuísse o objeto que representa a session (que tem a mesma interface que um Map) como atributo protected. Exceto que o acoplamento gerado para acessar a session da classe-mãe em Ruby é muito fraco enquanto em Java seria enorme (na verdade provavelmente a melhor opção em Java seria um método e não um atributo. Em Ruby estes conceitos são bem mais flexíveis) é mais uma questão de filosofia do framework do que de linguagem utilizada em si.
Apesar da polêmica se é ou não uma Domain-Specific Language, Rails é um exemplo claro de Language-Oriented Programming. Neste paradigma de programação (praticado em Lisp desde…sempre!) a linguagem utilizada é modificada e estendida para acomodar os conceitos do domínio. No caso do Rails a linguagem Ruby ganha características que permitem ser estupidamente simples criar uma aplicação web.
E o que isso representa para quem está aprendendo? Eu diria que existem 2 tipos de pessoas que desenvolvem em Rails: desenvolvedores e desenvolvedores de aplicações web. Qual a diferença?
Desenvolvedores aos quais me refiro são desenvolvedores profissionais de software (analistas, programadores, hackers, o que quer que você queira chamar). São pessoas que se dedicam profissionalmente a entender as milhões de coisas que são importantes no desenvolvimento de projetos de software. Utilizar Rails para eles é apenas se beneficiar de uma boa ferramenta que implementa conceitos de MVC, ActiveRecord, LOP, Domain Model, Meta-Programação, convention over configuration, JavaScript, etc.
Para eles eu recomendo primeiro aprender Ruby. Rails sem Ruby é exotérico demais, você não vai entender como é possível que sua classe ganhe métodos conforme precisa deles e outras coisas estranhas (principalmente se você vem de Java ou C#).
O outro estereótipo, o desenvolvedor de aplicações web, geralmente é umc ara com menos conhecimento técnico, menos interesse em construção de software e habilidades em outras áreas. Pode ser o designer que quer fazer seus projetos com relativa independência de programadores, pode ser o cara que tem um estalo e uma brilhante idéia para uma aplicação Web 2.0 que o fará milionário… O ponto é que desenvolver software para este cara é só uma parte do processo, o meio, e não o fim. Este cara não precisa aprender tantos conceitos, ele pode se basear em receitas prontas e correr para um técnico quando precisar de algo mais heavy-metal. Para este cara eu recomendo aprender diretamente Rails, eventualmente ele pode melhorar Ruby e programação em geral com a evolução do seu projeto.
Interessante notar o conceito que funciona com Rails e com desenvolvimento baseado em Domain-Specific Languages (sendo Rails uma ou não): o usuário não vai desenvolver o software sozinho. Ele se baseia em algo construído para ele por um técnico (seja o framework Rails ou uma DSL) mas não consegue sair muito daquele escopo específico e limitado sem acompanhamento profissional. Este é o objetivo dos pesquisadores de DSLs neste momento.