programando « Fragmental

Archive for the ‘programando’ Category

Domain-Driven Bolovo, Passando Conhecimento e etc.

Monday, January 18th, 2010

Segue uma seqüência ~~aleatória~~ quase coesa de pensamentos que me vieram a cabeça enquanto esperava meu vôo para Salvador.

Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.

Arquitetura Java em 2007 (Java Architecture in 2007)

View more documents from Phillip Calçado.

O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.

Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.

Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.

Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.

E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:

Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.

Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.

Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:

Expressive Design (in 20 minutes)

View more documents from Phillip Calçado.

E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.

Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.

É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.

Posted in arquitetura, brasil, comunidade, cursos, domain.driven.design, engenharia, fragmental, fragmental.tw, gerencia, negocios, orientacao.a.objetos, palestras, programando, thoughtworks | 4 Comments »

Preparações e Desculpas Esfarrapadas

Monday, October 26th, 2009

Para variar, a desculpa para não ter escrito mais frequentemente é a preparação requerida para a viagem ao Brasil. Eu sei que é uma desculpa esfarrapada mas infelizmente esta etapa envolve mais do que fechar malas e comprar canguru de pelúcia para as sobrinhas, meus últimos dois projetos requereram muita atenção e neste exato momento eu estou finalizando os últimos detalhes de um deles.

Isso fez com que meus planos se alterassem um pouco. Infelizmente não vou ter tanto tempo quanto gostaria para encontrar pessoas, especialmente fora do Rio. Ainda vou em alguns lugares mas nada perto do que tinha em mente antes.

Sobre o evento, acho difícil haver alguém que ainda não tenha esbarrado com um dos banners ou coisa parecida sobre o Caelum Day. A programação está bem interessante e promete ser um dia útil e divertido.

Minha apresentação vai focar no que eu mais tenho feito nestes últimos dois anos: fazer com que times de desenvolvimento saiam do marasmo e comecem a entregar. Não me venha com essa história de “minha metodologia não deixa”, “meu chefe é mau”, etc., todo lugar tem problemas e as coisas dependem de você. A apresentação possui dicas e fundamentos técnicos mas sem vontade nada vai pra frente.

E para, refletir de maneira bem realista o clima da indústria de desenvolvimento de software, este ano eu escolhi mais uma vez filmes de terror para servir de pano de fundo (e comic relief). Ao contrário do ano passado, entretanto, eu escolhi um filme em específico. O primeiro comentário quem acertar o filme baseado na capa da apresentação abaixo ganha… algo… que eu ainda vou decidir:

As inscrições ainda estão abertas aqui.

Para o workshop de Domain-Driven Design não há mais vagas –mas existe uma lista de espera.

Algumas pessoas ficaram curiosas porque escrevi no meu blog em inglês que acho o assunto (DDD) tedioso. Existe uma enorme demanda de cursos sobre o tema e o Paulo Silveira e eu decimnos que valia a pena realizar mais uma rodada dos cursos. Eu continuo usando Domain-Driven Design em meus projetos e textos, mas o assunto já está meio batido e mastigado.

Na minha opinião, DDD deveria ser parte de um curso maior sobre design em geral, um workshop específico tem relevância quando o assunto é novidade mas perde o apelo quando a técnica começa a ser utilizada por mais gente. Tenho lido mais sobre outras coisas e, se tudo der certo, vamos ver se em 2010 eu consigo aposentar o workshop de DDD e partir para estas novas coisas.

Bom, por enquanto é isso. Nos vemos semana que vem.

Posted in brasil, comunidade, cursos, domain.driven.design, engenharia, eventos, fragmental, fragmental.tw, gerencia, metodologias, negocios, palestras, programando, rio, testes | 5 Comments »

Projeto Brazil 2009 - Preenchendo Lacunas

Wednesday, July 22nd, 2009

Bom, com a passagem na mão e devidamente autorizado pelas autoridades competentes eu posso publicar aqui que este ano, mais uma vez, eu vou passar alguns dias no Brasil em uma clássica e manjada parceria com a Caelum.

O plano original é emendar tudo com o lançamento do livro -que eu, relapso que só, ainda não mencionei neste blog- mas este plano pode mudar. De qualquer maneira o esquema básico é o mesmo do ano passado: uma conferência e alguns workshops. Ainda não posso falar sobre nenhum deles porque nada foi decidido mas assim que eu tiver definições eu posto aqui.

Mas meu objetivo com este post é me colocar à disposição. A viagem deste ano é totalmente a trabalho -tirando alguns dias para a família e os amigos, claro- e eu pretendo visitar o maior número de grupos de usuários, empresas e comunidades de desenvolvimento de software que eu conseguir. Faz dois anos que estou na Austrália e apesar de meu contato diário com a comunidade brasileira uma coisa é falar de longe e outra é ver de perto.

Eu tenho algumas visitas já marcadas e, infelizmente, não muito tempo disponível então vou ter que priorizar as coisas. A minha idéia original é chegar no grupo de usuários/empresa/etc., fazer uma apresentação de uns 30 minutos e depois passar algum tempo pareando com as pessoas e atualizando minhas percepções sobre o mercado brasileiro em geral. Eu chego dia 31/10 e volto dia 15/11, estarei, a princípio, no Rio durante toda a viagem mas topo viagems próximas.

Topa? Me manda um email. Não sabe meu email? Se vira.

Posted in australia, brasil, comunidade, eventos, fragmental, guj, palestras, pessoal, programando, rio, riojug, thoughtworks | 10 Comments »

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.

Posted in .net, arquitetura, australia, bancos.de.dados, beyondjava, brasil, cbd, comunidade, domain.driven.design, domain.specific.languages, engenharia, foss, gerencia, guj, java, javascript, linux, lisp, livros, metodologias, microsoft, negocios, orientacao.a.objetos, php, plataformas, programacao.funcional, programando, rails, rest, ruby, sistemas.operacionais, soa, testes, thoughtworks, unix, você.pergunta, web, ws-*/soap | 9 Comments »

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://blog.fragmental.com.br/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.

Posted in brasil, cursos, domain.driven.design, domain.specific.languages, engenharia, eventos, fragmental, fragmental.tw, java, metodologias, orientacao.a.objetos, palestras, plataformas, programando, rio | 7 Comments »

Brazilian Tour 2008: Falando em Agile, Domain-Driven Design

Monday, September 1st, 2008

Outubro vai ser um mês bem interessante. Vou entregar um dos meus projetos mais importantes até agora (pelo menos é o que nossas previsões dizem) e vou passar 15 dias entre férias e eventos no Brasil.

O motivo principal é para realizar uma apresentação no Falando em Agile 2008, mais um evento da Caelum. As inscrições estão abertas e inscrevendo-se com antecedência você consegue desconto.

Minha palestra vai ser sobre um tema que venho desenvolvendo há algum tempo: como adoções ágeis que tinham tudo para dar certo afundam. Antes de entrar para a ThoughtWorks eu já tinha vivido esta situação pelo menos duas vezes, nestes nove meses trabalhando numa grande consultoria especializada eu já vi umas três. Todas tinham um grupo de sintomas bem parecidos o quais estou tentando estruturar. Não é lá muito fácil mas acho que o resultado tende a ser bom. Se você acha que Vovô viu a uva, a web somos nozes, arquitetura BOLOVO e amigos foram piadas infames e de mau-gosto mal podem esperar pela temática desta apresentação…

Uma das coisas mais interessantes sobre o FalandoEmAgile 2008 para mim vai ser a presença do Danilo Bardusco na grade. O Danilo foi meu gerente na Globo.com antes de assumir tudo-menos-webmedia, quando passei a responder diretamente ao Antônio Carlos. Naquele momento a empresa viva diversas histórias tristes com métodos baseados em Waterfall, micro-management e consultorias CMMI 5; apesar dele não acreditar que aquilo ia dar certo no início foi sua perseverança e abertura à inovação que possibilitou aquele trabalho inicial que hoje, graças ao trabalho de todos, é referencia. O grande defeito dele é aquela mania infeliz de usar Vi quando todo mundo sabe que emacs é o único editor de texto que deveria ser utilizado. Mas eu perdôo.

Como falei, são 15 dias no Brasil. Eu ainda não sei as datas do que vou fazer mas devo ter algumas outras apresentações de palestras no Rio (certamente no RioJUG) e em São Paulo.

Como eu já estava vindo para o Brasil, acabei fechando com a Caelum uma série de oficinas em Domain-Driven Design. A idéia é cobrir os principais aspectos desta filosofia de design de uma maneira descontraída mas substancial. O primeiro post que menciona Domain-Driven Design neste blog é de 2005, e foi importado do meu antigo blog no blogger.com. Nesta época quase ninguém havia ouvido falar do conceito. Hoje ainda é algo relativamente obscuro mas um pouco mais popular. Claro que com a popularidade vem os problemas. Muita gente no GUJ, em blogs e outros fóruns está simplesmente associando Domain-Driven Design com um bom design Orientado a Objetos, ou pior ainda: com qualquer design OO.

Ao contrario do recente mito popular, Domain-Driven Design não é “voltar para Orientação a Objetos”. Orientação a Objetos foi criada como uma maneira de gerenciar dependências e criar unidades coesas e atômicas de código, não necessariamente uma forma de modelar uma Camada de Negócios. O que Domain-Driven-Design traz de volta é a possibilidade de utilizar as vantagens da Orientação a Objetos para criamos um modelo que reflita o mundo real de maneira mais íntima. Você não precisa sequer de objetos para aplicar o coração de Domain-Driven Design, ou mesmo seus Patterns.

A parte do “substancial” que falei acima é exatamente esta: não misturar Orientação a Objetos com Domain-Driven Design e sim trabalhar a relação entre eles. A parte “descontraída” é na forma de passar este conhecimento. Após alguns anos ministrando treinamentos eu não tenho a fórmula ideal para passar este tipo de conteúdo (altamente abstrato e que requer conhecimento posterior) mas eu já aprendi por tentativa e erro diversas formas em que isso não dá certo –pelo menos não comigo. Duas delas são: aulas expositivas e laboratórios. Se você não entende porque aulas expositivas não servem para este tipo de coisa pense sobre todo o conteúdo que é quase que literalmente jogado em cima de alguém numa faculdade e quanto dele é entendido (e entender não é tirar 10 na prova). O problema de laboratórios é que sempre perde-se tempo com a máquina, ou a linguagem (este não é um workshop Java ou Ruby ou C#, é um workshop sobre objetos).

Eu não tenho as datas nem preços (já encheu o saco da Caelum hoje?) mas vamos ter sessões em outubro no Rio e São Paulo, a preços acessíveis.

Posted in arquitetura, brasil, comunidade, domain.driven.design, engenharia, gerencia, guj, metodologias, orientacao.a.objetos, plataformas, programando, rio, riojug, testes | 12 Comments »

Uh-Éme-Éle

Friday, July 25th, 2008

Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.

O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para “modelagem” não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).

Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?

Há algum tempo que eu me pergunto porque que se usa UML para “modelar”. Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.

Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.

O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus “implementadores” façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo?

Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como “programador júnior” porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu “analista” uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o “analista” sozinho cuide do serviço?

Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu “analista” usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.

Mas como assim? O “modelo lógico” é muito diferente do “modelo físico” e o “analista” não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:

Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus “analistas” sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.

Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.

Posted in arquitetura, comunidade, engenharia, metodologias, plataformas, programando, testes | 26 Comments »

Rastreabilidade em User Stories

Friday, July 18th, 2008

Pergunta na XP-Rio:

Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.

Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?

O XP permite isso? Como é feito?

Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)

- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)

A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.

Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.

Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.

Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:

História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:

O novo grupo criado deve possuir o usuário que o criou como seu administrador

O novo grupo não deve conter outros membros

O novo grupo não deve ser visível na listagem de grupos

Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:

[class, %]	[method, %]	[block, %]	[line, %]	[name]
25%  (1/4)!	25%  (3/12)!	40%  (3012/7446)!	25%  (3/12)!	com.sun.tools.javac.v8.resources
94%  (16/17)!	49%  (41/83)!	48%  (1111/2292)!	45%  (201.1/450)!	com.sun.tools.javac.v8
88%  (45/51)!	61%  (242/397)!	54%  (3070/5729)!	52%  (809.6/1563)!	com.sun.tools.javac.v8.tree

Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.

Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.

Posted in comunidade, gerencia, metodologias, programando, testes, você.pergunta | 14 Comments »

Ruby é JavaScript ao Avesso

Thursday, June 12th, 2008

O titulo é uma brincadeira mas é uma boa forma de lembrar algumas coisinhas sobre programação nestas linguagens. Cada vez mais lidamos no dia-a-dia com conceitos que estão presentes há décadas em linguagens mais esotéricas mas nunca deram as caras no mainstream, um deles é o uso de funções como abstração. Existe um conflito de termos aqui então só para deixar claro eu não estou falando de funções como em programação procedural mas sim de funções como vemos em closures.

Muita gente tem escrito sobre como devemos aprender programação funcional. Eu concordo mas não posso deixar de notar que quando alguém diz programação funcional geralmente ela quer dizer Higher-Order Functions.

E o que é isso? Bom, uma linguagem possui higher-order quando uma função pode receber como parâmetro outra função. O nome deriva do fato de que uma função que recebe outra é considerada de ordem 1, uma função que recebe outra que recebe outra é considerado 3 e assim em diante.

JavaScript possui higher-order programming. Funções são a abstração principal em javaScript e elas podem ser passadas à vontade pelo programa. Por exemplo, vamos supor que queremos comparar dois objetos de acordo com um critério arbitrário. Em JavaScript podemos fazer algo assim:

function melhorEntre(um, outro, criterio){
  if(criterio(um, outro)){
    return um;
  }
  else {
    return outro;
  }
}

sorvete1 = {sabor: 'morango'};
sorvete2 = {sabor: 'chocolate'};

prefiroChocolate = (function (s1, s2){
                                   return (s1.sabor === 'chocolate');
                            });

prefiroMorango = (function (s1, s2){
                                  return (s1.sabor === 'morango');
                            });

alert(melhorEntre(sorvete1, sorvete2, prefiroMorango).sabor);
alert(melhorEntre(sorvete1, sorvete2, prefiroChocolate).sabor);

Em Ruby o código ficaria um pouco diferente:

def melhor_entre(um, outro, criterio)
    if criterio.call(um, outro)
        um
    else
        outro
    end
end

sorvete_1 = { :sabor => 'chocolate' }
sorvete_2 = { :sabor => 'morango' }

prefiro_chocolate = lambda {|s1,s2| s1[:sabor] == 'chocolate'}
prefiro_morango = lambda {|s1,s2| s1[:sabor] == 'morango'}

puts melhor_entre(sorvete_1, sorvete_2, prefiro_morango)[:sabor]
puts melhor_entre(sorvete_1, sorvete_2, prefiro_chocolate)[:sabor]

Agora vamos pensar: as duas linguagens possuem higher-order programming? Não, só JavaScript possui. Em Ruby o que é passado não é uma função e sim um objeto, veja só:

prefiro_chocolate = lambda {|s1,s2| s1[:sabor] == 'chocolate'}
puts prefiro_chocolate
#=> #<Proc:0x00028a64@tmp/compara.rb:19>
puts prefiro_chocolate.class
#=> Proc

O principal divergente da solução em Ruby é que você deve passar a mensagem call para o objeto (ou usar a palavra-chave yield). Na pratica do dia-a-dia não tem tanta diferença e é comum falar em higher-order Ruby.

Em Ruby não precisamos de funções de verdade para termos higher-order programming, podemos usar objetos para modelar as funções. Em JavaScript não temos construções especiais para objetos, mas utilizamos funções:

function Sorveteiro(){
  this.numeroDeVendidos = 0;
  this.vender = function(){this.numeroDeVendidos++;};
};

s = new Sorveteiro();
alert(s.numeroDeVendidos);
s.vender();
alert(s.numeroDeVendidos);
s.vender();
s.vender();
alert(s.numeroDeVendidos);

Alguém me disse essa semana que uma das grandes vantaens em aprender higher-order programming (a pessoa falou em programação funcional mas não é bem isso que ela quis dizer) é que com ela você simula objetos mas o contrario não é verdade. Bom, não é assim. Nada impede de você ter higher-order programming em uma linguagem Orientada a Objetos (JavaScript é Orientada a Objetos!) e com objetos você pode facilmente modelar higher-order programming.

E qual a diferença disso tudo para programação funcional? Bom, programação funcional usa higher-order programming, mas não é isso que define uma linguagem funcional (JavaScript não é funcional).

Em 1984, John Hughes publicou um paper chamado “Why Functional Programming Matters”. Este paper é, até hoje, uma das obras mais importantes para o paradigma. Nele o autor descreve:

The special characteristics and advantages of functional programming are often summed up more or less as follows. Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a ma jor source of bugs, and also makes the order of execution irrelevant - since no side-efect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa - that is, programs are “referentially transparent”. This freedom helps make functional programs more tractable mathematically than their conventional counterparts.

Erik Meijer apresentou uma palestra no JAOO chamada “Why Functional Programming (still) Matters” onde ele afirma que nenhuma linguagem é realmente funcional, provando que se pode simular efeitos colaterais em Erlang, Haskell, F# e várias outras.

A conclusão do Erik -é claro que defendendo suas decisões ao criar o LINQ- é que os conceitos por trás das linguagens ditas funcionais são mais importantes do que ser uma linguagem puramente funcional ou não.

Isso significa que você deve aprender sobre programação funcional e aplicar suas técnicas sempre que necessário mas cuidado com o termo “funcional”. Na maioria das vezes você quis dizer Higher-Order Programming.

Update: Alguns dos comentários msotram uma confusão com funções javaScript e objetos. Não só o texto falou que em JavaScript funções são objetos bem como ele mostrou o exemplo do sorveteiro, mas tentando deixar ainda mais claro: