Archive for the ‘domain.specific.languages’ Category

Refletindo sobre Tendências

Friday, July 10th, 2009

Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.

Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.

O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.

Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.

O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.

Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.

Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).

As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.

O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.

Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).

Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.

Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:



Esta é a fila dos que faltam:


(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)

Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:

early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures

Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.

Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.

É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.

Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.

Domain-Driven Design & Agile: Fechando Malas

Wednesday, October 8th, 2008

Como falei algumas dezenas de vezes estou no fim de um projeto, na verdade na minha última semana neste instante. Foi um projeto muito interessante onde pudemos aplicar diversas técnicas como Domain-Specific Languages para testes e promoção de testes de aceitação. Também foi o primeiro projeto Java sem container que participei desde 2006, apenas PicoContainer, Hibernate, JMX e um cliente JMS -sem mesmo interface de usuário.

Outro ponto interessante sobre este projeto é que foi uma reescrita de um sistema com o qual estive envolvido antes. O cliente está passando por um programa que compreende diversos projetos e muitas fases. Há alguns meses nós fomos chamados para entregar, em algumas poucas semanas, uma versão deste sistema. Na nova fase do projeto eles resolveram investir mais na qualidade deste e tivemos uns bons 3 meses para reescrever tudo. Não só o sistema foi completamente reescrito bem como teve um time diferente (no anterior erámos eu e um colega ThoughtWorker, no atual somos 5 pares entre TWers, empregados do cliente e outros terceirizados).

O problema agora é a pressa. Não, o projeto não está com pressa, nossa entrega é em uma semana e faltam poucos cartões na parede. Eu que estou. Estou saindo deste projeto com muita coisa que eu queria fazer ainda meio-acabada e nesta última semana estou me dedicando basicamente a criar tracing bullets para o desenvolvimento futuro já que quem toma conta do sistema a partir da entrega de 15/10 é o cliente. Não é fácil com tão pouco tempo.

E esta lenga-lenga foi um mea-culpa para maiores informações sobre minha viagem ao Brasil. O press-release ficou assim:

Dia 23 e 24 de outubro ocorre em São Paulo o primeiro grande evento de Agile do Brasil:
http://www.falandoEmAgile.com.br/

Ouça as histórias de empresas que tem obtido sucesso com Scrum, entenda como estas práticas podem ser implantadas em ambientes tradicionais de projetos, veja o que a indústria tem falado e feito com Agile e descubra quais serão os próximos passos a serem dados nesse mundo. Conta com o palestrante internacional David Anderson, reconhecido líder na comunidade Ágil e autor do livro “Agile Management for Software Engineering”, e com o primeiro Certified Scrum Trainer da Scrum Alliance da América Latina, Alexandre Magno. De tópicos de Scrum e CMMI até estudos de caso com Agile na Austália, Inglaterra, Estados Unidos e Brasil.

Ocorrerão mais outros eventos próximos a essas datas:

O Zen of Agile, nos dias 21 e 22, um workshop com David Anderson:
http://www.heptagon.com.br/ws-zen-agile-mgmt

O Certified ScrumMaster, dias 27 e 28 de outubro:
http://www.caelum.com.br/treinamentos/csm-certified-scrum-master/

E por três vezes Phillip Calçado, conhecido aqui no GUJ, ministrará um workshop de Domain Driven Design de 8 horas, dia 21 de outubro no Rio de Janeiro, e dias 27 e 28 em São Paulo:
http://www.caelum.com.br/treinamentos/ws-46-domain-driven-design/
http://philcalcado.com/2008/09/01/brazilian…em-agile-domain-driven-design/

Está sendo divertido montar este workshop. É algo estranho porque é maior que uma palestra e menor que um curso -ao mesmo tempo é tempo demais e tempo de menos. Eu quero começar desmistificando alguns conceitos sobre objetos, trabalhando a idéia das decisões em três níveis e só depois entrar em Domain-Driven Design. É impressionante como fica mais claro falar sobre DDD depois de quebrar mitos, numa palestra nunca se tem tempo de fazer isso.

Como falei antes, para maiores informações basta ligar para a Caelum do Rio ou São Paulo.

E com a confirmação das datas eu muito provavelmente vou estar também no último dia do Rails Summit.

Testadores Ágeis

Monday, March 24th, 2008

Todo mundo sabe que agilidade é sobre testes. Muitos testes. Bem, mais ou menos. Geralmente quando falamos de testes em metodologias ágeis estamos falando de testes escritos pelo desenvolvedor enquanto escreve código, e estes têm dois objetivos: feedback e bom design.

Feedback se consegue ao executar os testes. Quando você escreve uma classe que quebra um teste você sabe que existe algo errado imediatamente. Bom design se dá porque nada alem do necessário é criado, alem de que as tecnologias atuais de testes exigem que seu código siga alguns bons princípios para que seja testável, como bom gerenciamento de dependências.

Existe, entretanto, outro tipo de teste, geralmente feito por um profissional especializado, que chamamos de QA (Quality Assurance). Este teste valida o software de um ponto de vista diferente. Muita gente se engana achando que testes de desenvolvedor são suficientes para validar um sistema. Obviamente que assim como nem todo sistema exige um web designer profissional especializado nem todo exige um profissional de testes, mas a maioria dos projetos que já participei tinham nisso um benefício.

Estava lendo o artigo do Jeff Paton, ex-colega ThoughtWorker, sobre isso e lembrei das minhas experiências com testadores em time ágeis. Mas primeiro talvez seja melhor contar sobre as experiências em times não-ágeis.

Eu trabalhei em uma empresa muito interessante mas com um processo muito estranho. A empresa tem orgulho de usar waterfall para desenvolver seus produtos, ninguém está autorizado a escrever uma linha de código sem escrever 8 documentos. Obviamente todos os projetos atrasam e obviamente o software tem uma qualidade deprimente, mas eles conseguem fazer dinheiro neste cenário –ainda que pagando um preço muito alto.

Teste é uma coisa séria nesta empresa. Os produtos estão sujeitos à regulamentação de telecomunicações de diversos paises, e cada funcionalidade tinha que ser testada de acordo. O fluxo de desenvolvimento era o típico de waterfall, nós desenvolvedores criávamos nossos sistemas (programas em C++ para plataformas UNIX diversas) e enviávamos uma tag do Subversion para a equipe de testes. O testador teoricamente já lera todas as especificações funcionai do produto e já tinha os casos de testes escritos e, talvez, implementados.

Era aí que a brincadeira começava. Na melhor das hipóteses o testador encontrava um bug, rejeitava o pacote (usando um maravilhoso sistema interno desenvolvido em Lótus Notes) e enviava de volta. O desenvolvedor corrigia e o pacote era retestado. Isso nunca acontecia. O que acontecia era:

  • O pacote era aprovado. O desenvolvedor, com o sistema já em produção, olhava o plano de testes por curiosidade e via que eles não testavam absolutamente nada de relevante, ninguém garantia a qualidade do treco
  • O pacote era rejeitado. O desenvolvedor olha ao motivo da rejeição e via que o que estava sendo testado nem de perto era o que o sistema deveria fazer. O testador Não entendeu o documento, muitas reuniões explicando tudo novamente e o pacote era retestado sem modificações
  • O pacote era recebido pelo testador com total surpresa. Era uma aplicação de linha de comando e o testador esperava uma aplicação com interface web, ou o testador esperava que o sistema usasse banco de dados e ele mantinha tudo em memória, ou…
  • O testador rejeitava o pacote porque não sabia como testa-lo. O desenvolvedor não pensava no testador, o testador não pensava no desenvolvedor.

Claro que todos os membros do escritório de projetos (já falei que tínhamos CMMI?) sabiam a solução para estes problemas e é claro que para eles a solução passava pela criação de mais documentos, de 1 a 5 dependendo de quem você perguntasse.

Nas equipes ágeis que trabalhei a coisa era diferente. O testador senta ao lado do desenvolvedor, e por vezes eles trabalham em pair programming (pair testing, provavelmente). O testador está envolvido em todas as tarefas, validando que o que o analista de negócios pede é entregue, que confirma com as premissas do projeto e etc.

Para fazer isso ele está envolvido na elaboração das user stories e, principalmente, dos critérios de aceite definidos nela. Seu trabalho é verificar que os critérios de aceite são obedecidos pela implementação e que eles fazem sentido em primeiro lugar.

Um profissional come site perfil não pode ser simplesmente um usuário. Ele tem que conhecer sobre metodologia de testes de software (um campo enorme por si só), sobre o domínio do sistema e sobre desenvolvimento. Idealmente o testador é um desenvolvedor e sabe criar suas ferramentas. Um testador deve ser capaz de escrever seu próprio programa usando Selenium RC, ou suas fixtures no Fit.

Infelizmente nem sempre isso acontece. Em muitas empresas o cargo de testador é delegado à pessoas que possuem um conhecimento técnico muito baixo e executam tarefas do tipo “aperte o botão e verifique se quebra o layout”. Neste caso os desenvolvedores podem prover as ferramentas para os testadores mas ainda assim eles devem ter capacidade de escrever os casos de testes usando a ferramenta sozinhos.

O papel do testador não é dizer que a aplicação está homologada, na maioria das vezes isso é apenas uma ilusão que gerentes gostam de cultivar. O papel do testador é garantir a qualidade dele submetendo à testes rígidos. Não é um aceite formal, o testador não é quem aprova o software –o analista de negócios ou seu equivalente aprova o software- ele faz parte do desenvolvimento deste.

Minha experiência diz que assim como trabalhar com testadores apertadores-de-botão não agrega nada ao produto alem de burocracia desnecessária, trabalhar com testadores de verdade no time é uma das melhores coisas que pode acontecer num projeto de software.

No meu projeto anterior os testadores chegaram ao time apenas como apertadores de parafusos. Eles clicavam na tela e verificavam que a informação correta era disponibilizada. Como nossa participação no projeto era facilitar a adoção de metodologias ágeis isso tinha que mudar. A primeira coisa foi a participação dos testadores na definição das histórias, eles trabalham junto com o analista de negócios e o usuário definindo critérios. Eles também participam do sign-off da história –quando ela é apresentada aos desenvolvedores que vão executa-la- e quando conclui a história o desenvolvedor az um walkthrough dela para o testador. Em todas as etapas eles agregam informação, questionam as praticas e, principalmente, garantem que o software final é testável.

Foi adicionado ao time de facilitadores um testador especialista em automação –um desenvolvedor exercendo função de QA, basicamente-, a função dele era disponibilizar ferramentas e disseminar seu uso. Com o tempo desenvolvemos uma Internal DSL em Ruby para controlar nossa ferramenta de teste, o Selenium RC. A ferramenta é utilizada por desenvolvedores nos nossos testes de aceitação que fazem parte do build e pelos testadores na hora de dizer que uma história está concluída.

Os resultados desta adoção são excelentes. Quando nossa parte no projeto –facilitar a adoção das praticas- acabou a pessoas estavam aptas à continuar o bom trabalho por si mesmas. Os desenvolvedores ainda criam as ferramentas mas a gerencia, vendo os benefícios, agendou cursos de Ruby e Selenium para a equipe de QA.

Sinal de Vida

Wednesday, March 12th, 2008

Nossa, tanta coisa que nem sei o que postar. Neste tempo que fiquei afastado –quase um mês!- juntei um bando de idéias para postas mas agora falta tempo.

Neste período terminei mais um projeto. Estou alocado no mesmo cliente e temos dezenas de pequenos projetos que fazem parte de um projeto maior que faz parte de um projeto tão gigantesco que toda semana tem uma festa para comemorar que alguém lá em Perth terminou uma parte que você nem sabia que existia. Segunda-feira devo ser movido para outra parte, desta vez é apenas para prestar ajudar um grupo de desenvolvedores do cliente que está com problemas num sistema baseado em mensagens assíncronas. Deve durar até Maio, creio.

Mas não é o trabalho que me tem afastado, pelo menos não é o maior causador. O problema é a minha pesquisa. Eu tenho dedicado boa parte do meu tempo livre a me aprofundar nos assuntos necessários para uma boa compreensão de Language-Oriented Programming e Domain-Specific Languages.

Infelizmente existe duas áreas de Ciência da Computação nas quais eu nunca me interessei muito: linguagens de programação e inteligência artificial. IA é algo que eu ainda não estudo mas para entender DSLs uma das coisas mais importantes é entender como as linguagens são criadas. Isso está me fazendo tentar aprender em um mês o que eu negligenciei por anos, incluindo a leitura capa-a-capa do SCIP. Eu sei um pouco de Common Lisp mas ainda que não soubesse não seria problema, o livro usa Scheme mas você não precisa saber Scheme ara começar a ler –bem no estilo de Bertrand Meyer que ensina Eiffel no seu livro de OO.

Depois disso vem o Concepts, Techniques, and Models of Computer Programming - que é uma recomendação do Rafael- e The Seasoned Schemer. For a as dezenas de papers da ACM que tenho pesquisado.

É trabalhoso, é complicado mas é uma das coisas que me fizeram vir ara a Austrália e mudar de emprego. Na ThoughtWorks eu tenho acesso a um material seleto sobre iniciativas no mundo real destas tecnologias, e acesso à pessoas com um conhecimento sobrenatural sobre este assunto. Apesar de eu adorar fazer parte de um time fixo desenvolvendo um produto e focado em melhoria, trabalhar como consultor me dá mais liberdade para focar no meu interesse atual, que em grande parte é essa pesquisa. Eu trabalho de 9 as 17h no cliente -sem hora extra- levanto da minha mesa e em 15 minutos estou no meu apartamento.

Antes que comecem as especulações entre meus três leitores não, eu não pretendo fazer nada de útil com o resultado da pesquisa. O resultado, na verdade, não importa, para mim importa o que eu aprender no caminho.

Se tudo der errado eu faço uma aplicação em Lisp pro Facebook e fico rico :)

Entrevista sobre Domain-Specific Languages

Tuesday, January 29th, 2008

O Laércio Queiroz me entrevistou sobre DSLs. O resultado você vê no blog dele.

Você Pergunta: RAD

Thursday, January 24th, 2008

Uma pessoa me escreveu um email sobre o tópico anterior. Novamente não vou citar nomes porque não pedi permissão (e não tenho motivos para expôr esta):

Shoes, beleza cara?

Então, lendo sobre a discussão sobre o Maker eu cheguei no seu blog e li sobre RAD.
Aquela ferramenta no NetBeansLixo pra fazer GUIs é um RAD? Ele desenvolve parte de um software, eu sei, não é um modelo de processo de desenvolvimento, né??

Enfim, acredito que existam mais algumas por aí como Maker e queria saber da sua opinião: todas essas ferramentas são RADs e todas elas cometem gafes? Onde quero chegar é na pergunta: Hoje em dia, SEMPRE teremos um desenvolvedor por trás da solução?

É que eu sou totalmente contra essas ferramentas de gerar códigos automáticos… não confio muito nessas coisas… prefiro eu mesmo fazer os códigos, mas tenho a dúvida: estou muito antiquado (no sentido de muito atrasado e não acompanhando as tecnologias que estão evoluindo hoje) ou estou no caminho correto?

Bom, se você respondeu que sim na primeira pergunta (do NetBeans sobre GUIs), a principal desvantagem das ferramentas RAD (se é isso que aquele Lixo é) é a manutenção e evolução, certo? Uma vez, fazendo um trabalho pra faculdade, tive que usar aquele NetBeans. Quando fui usar Refactoring… nossa cara, que coisa mais chata… tive que refazer praticamente toda a interface gráfica.

Abraço.

Apesar de usar, eu odeio o termo RAD. Ele significa um grupo enorme de coisas e ao mesmo tempo não significa nada. O livro Software Development: Building Reliable Systems define RAD:

For the last ten years, many software projects have incorporated the use of “Rapid Application Development” methodologies in an effort to decrease development times. RAD, as it is generally referred to, incorporates an umbrella of methodologies based on spiral, iterative development technologies. RAD techniques range from the simple use of GUI development tools to quickly build prototypes, to processes incorporating complete, cross-functional business analysis. [...]

Então vou considerar que você quer dizer por RAD “ferramentas geradoras de código” do contrario este post nunca vai acabar. Sim, o Matisse do Netbeans é uma ferramenta geradora de código.

Ferramentas geradoras, em geral, são úteis quando não querem dominar o mundo. Eu adoro quando o Hibernate ou o Rails gera meu DDL SQL e eu não tenho que escrever CREATE TABLE. Eu adoro quando o Eclipse gera meus getters e setters e coisa do tipo. O problema é que esses geradores não costumam sobreviver num projeto de verdade.

O grande problema do gerador de código padrão, como o citado, é que ele possui diversos vazamentos de abstração. O Joel Spolsky fala especificamente sobre geradores:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

Como pode-se perceber pelas discussões citadas o mercado destas ferramentas é… complicado. Um desenvolvedor que entende como a plataforma funciona (Java EE, no caso) dificilmente se encantaria pela ferramenta. Ele pode utilizar algo como um Spring IDE para gerar arquivos de configuração mas sabe que isso não é tão simples assim.

Os programadores mais recentes na plataforma Java podem não ter consciência disso mas uma ferramenta chamada xdoclet era muito usada quando sofríamos diariamente com EJBs 2.1. O que o xdoclet faz é gerar código, ele gerava todo o mapeamento do EJB (uns 3 arquivos XML diferentes, pelo menos) a partir de anotações JavaDoc (não existia Java 5 naquela época). O xdoclet era a salvação da lavoura, conseguia abstrair muitos problemas mas.. não era perfeito, nem pretendia.

Eu já trabalhei em projeto onde 50% do código era gerado pelo xdoclet e do restante ele não dava conta. A ferramenta não possui o tal do round-tripping então não dava para misturar código gerado com modificado. A solução foi optar por uma arquitetura que isolava as duas partes em módulos diferentes e só conseguimos chegar até ela porque –como disse o Joel- sabíamos como a ferramenta funcionada. Essa é uma ferramenta de automação, não de “geração automática de sistema”. Ela automatiza o trabalho que você teria, não te livra do fato de conhecer o que… bem… é sua profissão.

Acho que o Matisse se enquadra neste tipo.

O problema é que essas ferramentas –e seus persuasivos vendedores- dizem que irão abstrair todo o desenvolvimento. Para os cenários ideais elas podem fazer todo o prometido mas não houve até hoje uma ferramenta que conseguisse real sucesso fora dos casos mais simples e isso porque não é assim que construímos sistemas hoje. Nossos sistemas são uma salada de linguagens, conceitos, mapeamentos e configurações que uma ferramenta deste tipo não consegue acompanhar.

O que geralmente elas fazem é te prender à uma ou algumas arquiteturas genéricas que servem razoavelmente para alguns casos -geralmente sitezinhos CRUD de intranet- mas não para todos ou sequer para a maioria. Como arquitetura não é commodity não se pode simplesmente aplicar a mesma estrutura em todos os cenários.

Apos algum tempo em TI você começa a entender que o dia-a-dia desse mercado é um grande “mais do mesmo”. Você sempre está criando as mesmas coisas. Da última vez que contei eu já tinha criado uns sete gerenciadores de conteúdo web. Dá para utilizar a mesma arquitetura em todos? Não. Uns eram simples formulários, outros se integravam com back-ends complicados, outros era assíncronos, outros tinham integração com legado… cada um tinha uma história. Se há oito anos atrás eu comprasse uma ferramenta dessas e a tivesse aplicado nestes projetos eu teria que fazer personalização (i.e. sair do maravilhoso mundo do fluxograma) a cada projeto.

Mas eu estou falando de desenvolvimento de software de um tipo, não do mercado todo. Quando estive na faculdade pela última vez (antes da segunda fuga) estudei com uma pessoa de 43 anos que desde os anos 80 vive fazendo software em coisas como CLIPPER para lojinhas e boutiques. Ele não ganha mal. Pelo que entendo dos softwares deste tipo (já trabalhei neste ramo) a arquitetura é quase sempre a mesma. Talvez ele se favorecesse de algo assim nos seus negócios, apesar de que eu ainda acharia um risco desnecessário.

Então sim, hoje precisamos de desenvolvedores para projetar um sistema. Desenvolver sua arquitetura, seu design e verificar para que tudo seja eito da maneira mais adequada para o projeto (que nem sempre é a técnica mais adequada). Mas e o futuro?

O futuro prevê o uso de ferramentas de um nível mais alto, mas de maneira diferente. O ponto crucial é que essas ferramentas não são geradores de código Java (ou C#, ou Ruby ou o que for), elas mudam a visão sobre o código. Ferramentas como Domain-Specific Languages aumentam o nível da linguagem não tornando-a mais abstrata apenas mas sim levando para perto do negócio. Ferramentas de visualização criam pontos de vista diferenciado sobre o mesmo artefato, dependendo de com que olhos se enxerga.

Tudo indica que para desenvolver softwares no futuro o desenvolvedor não terá o mesmo papel que tem hoje. Ao invés de criar o código do sistema em si iremos criar as ferramentas que dão suporte à criação de sistemas pelos usuários.

Seja qual for o futuro ele não é sobre gerar código. Isso nós já fazemos à décadas e serve apenas como quebra-galho para nos livrar da complexidade que nós mesmo criamos.

Arquiteturas Simples Duram Mais

Wednesday, October 24th, 2007

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 é:

  1. O arquiteto tem liberdade para resolver seu problema da maneira mais adequada
  2. O novo sistema é compatível com o meio-ambiente

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.

Conexão Java 2007

Tuesday, October 23rd, 2007

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.

Adaptação de Linguagens

Thursday, October 18th, 2007

Mais um texto no philcalcado.com, 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.

Anotações sobre Language-Oriented Programming (LOP)

Friday, October 12th, 2007

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.