Conheci o Sr. Hudson no início do ano passado com o pessoal da Zilics. Por motivos óbvios me amarrei logo de cara. Ele tem pelo menos duas das qualidades mais “nobres” que uma ferramenta de “apoio ao desenvolvimento de softwares” deve ter: é simples e útil!

Segundo um tal de Martin Fowler :

Faz Sentido. Integrar sempre não diminui a quantidade de bugs que irão aparecer. Além disso, não reduz o tempo/esforço de refactorings e não melhora a qualidade do código do seu software. Entretanto, reduz drasticamente os riscos inerentes à esses fatores ao mostrar, na hora e “na lata”, quais bugs apareceram (onde, como e quando. Geralmente o “quando” é agora!), o que quebrou ou vai quebrar com o seu refactoring, quais trechos de códigos tornaram a sua build instável e assim por diante.

Mas ainda estou falando da prática. E não da ferramenta. Quero dizer que, infelizmente, o Hudson não faz mágica. Antes de colocar uma ferramenta de integração contínua para funcionar no projeto, sua equipe já pode e deve estar integrando continuamente.

Este vídeo roubado na cara de pau do blog do Chapiewski é uma história verídica sobre como uma Grande Figurão se deu mal por não “Integrar Contínuamente”:

Único repositório de fontes?
Independente de SVN, GIT, CVS, ClearCase, SourceSafe, StarTeam ou seja lá qual SCM seja, TUDO (menos dependências, VIVA O MAVEN !) deveria estar no repositório. A idéia é que qualquer um a qualquer momento, inclusive o Hudson, possa montar um ambiente de desenvolvimento ou gerar um “instalável” a partir do repositório. Claro que existem exceções, mas nada que o nebuloso “bom senso” não resolva.


Build Automatizado, testes executados no processo de build?
Mais uma vez viva o Maven! Se não for o caso, pelo menos um Ant, .sh, .bat, ou qualquer outra coisa que resolva o problema. Até pouco tempo eu via muita gente rodando testes dentro do main de uma classe e fazendo control+C e control+V de arquivos, zipando pasta e renomeando pra .war. Assim não dá, assim não pode…


Todo mundo comita todo dia?
Se não comitou é porque ficou o dia todo no Orkut, ou porque “não quer comitar algo que possa quebrar a build antes de avaliar direito e blá blá blá…”. Mas ora bolas, a idéia é justamente essa! Se chegar a comitar e quebrar, pelo menos todos verão ao mesmo tempo o porquê de tudo isso. Ficar uma semana para comitar um componente de 300 classes para depois ficar mais três semanas fazendo merge e tentando descobrir o que quebrou, na minha opinião, é algo um pouco pior. Além disso, é capaz de lascar com a vida do seu parceiro que estava comitando todo dia, código que usava aquele componente antigo. Todos os testes passavam lindamente e de repente: WTF!?

Comitou, gerou build?
Este está diretamente relacionado ao tópico anterior. A idéia é gerar uma build estável executando todos os testes logo após o commit. Eu acredito que o ideal seja trabalhar rodando os testes que cobrem o que você está fazendo. Rodar TODOS os testes a cada mudança individual pode ser um processo lento e chato. Mas, isso deve ser feito pelo menos a cada commit. Dessa forma você garante que a build que estava estável continue estável. Automatizar esse processo é o ideal, mas isso é um trabalho para o Hudson!


O processo de build é rápido o suficiente, testes em ambiente de produção?
Alguns projetos (como o que vou citar mais a frente, para exemplificar o uso do Hudson) podem ser um pouco mais xaropes de serem instalados em ambiente de produção. Bancos com massas de dados muito complexas, webservices não disponíveis através de servidores de testes e dependências com hardware, em geral, dificultam a execução dos testes em ambientes ao menos similares aos da produção. Mesmo quando possível, a reprodução do ambiente de produção pode tornar a geração da build consideravelmente mais lenta. Uma prática (boa ou não) é manter uma suíte de testes com mocks para estas interfaces mais “complexas”. Esta suíte de testes é executada frequentemente pelos desenvolvedores e pela ferramenta de integração em cada commit. Uma outra suíte que reproduza o ambiente de produção também pode ser executada em nightly builds, por exemplo. Mas ambas são executadas sempre, a partir da última versão do MESMO repositório.


Tá fácil de pegar a última versão estável?
As pessoas, em geral, tendem a achar pequenos erros ou correções em uma funcionalidade já testada e usada com muito mais facilidade, do que assimilar novas funcionalidades agregadas. Uma boa dica é tirar proveito disso tanto nas apresentações como no dia a dia. Fica bem mais fácil quando se sabe exatamente como e onde buscar versões da aplicação. Seja para testar e apresentar correções e evoluções ou simplesmente para ver o que rolou ao longo da última semana. Todos deveriam ter “direito” à isso, principalmente quem está bancando o projeto.

Todo mundo vê o que está acontecendo?
09:52: Martin Fowler - I Love Continuous Integration says:
Integração Contínua tem tudo a ver com comunicação, de modo que você quer garantir que todos podem ver o estado do sistema e as mudanças que foram feitas a ele. :)

As pessoas envolvidas no projeto só vão “tomar ações” quando souberem que existe uma ação à ser tomada. Nada melhor do que uma luz vermelha gigante, piscando ao lado do número e data da última build que quebrou. Até mesmo saber se existe uma build em andamento e quais testes estão quebrados ou foram consertados. Tudo de fácil acesso.

No próximo post vamos trocar umas idéias sobre como o Hudson pode ajudar em todas estas tarefas citadas acima!

To be continued…

Na quarta-feira do apagão, 11 de março, eu e Bruno realizamos no Grupo NT uma tarde de apresentações e discussões sobre metodologias ágeis.

Foi um encontro assaz produtivo, tivemos várias discussões e trocamos idéias muito interessantes. As pessoas participaram bastante. Só pra vocês terem idéia, uma de nossas apresentações que leva normalmente uma hora, levou quase duas!

Infelizmente algumas questões e dificuldades permanecem sem resposta, ou sem solução fácil. Mesmo assim, muito já pode ser melhorado. Estamos ganhando cada vez mais aliados na luta contra a 666! :)

Tivemos um desafio extra que foi apresentar Scrum sem luz! Bravamente todos ficaram em sala no escuro e com calor, e agora podem até dizer que sabem fazer Scrum de olhos fechados! (Não tô nem um pouco ansioso para a versão “com os pés nas costas”…).

Novamente reforçamos o convite: se alguém mais quiser marcar uma apresentação onde trabalha sobre Metodologias Ágeis, XP, Scrum, estamos à disposição! Basta mandar email para bruno (ponto) pedroso ou renato (ponto) willi arroba seatecnologia ponto com ponto br e combinar!

Os usuários são a última barreira de uma aplicação web, não adianta você se esforçar para montar uma boa arquitetura, ter um código de qualidade e etc, se quando o usuário encontra um botão com o nome “realizar transação” ele clica de forma desesperada! Ninguém vai querer que isso aconteça! Então como podemos resolver esse problema com o struts 2? Nós temos duas formas de fazer, com um token a cada chamada ou um token na sessão, vejamos as duas:

O framework possui uma tag chamada s:token que gera automaticamente um token e o adiciona em um hidden Field no formulário.

Devemos criar agora um interceptor, uma classe que irá interceptar a chamada ao método da action. Este interceptor irá verificar se aquela requisição com aquele token já não está em processamento. O framework já possui implementações de interceptTokens por isso iremos apenas configurá-los, dessa forma:

Note o interceptor token antes da pilha padrão do framework. No caso de uma duplicação de requisição o interceptToken irá retornar o result invalid.token. Por isso devemos configurar esse result para página que apresentará o erro ao usuário, no meu caso, eu apenas redirecionei o usuário para página índex.

Com isso temos uma proteção para requisições duplicadas. O struts 2 possui outro interceptador de tokens, o tokenSession que herda de token e acrescenta uma lógica mais elaborada ao processo.

A configuração é a mesma, porém quando ele encontra uma requisição duplicada apenas ignora essa requisição, ao invés de retornar um resultado que irá resultar em outra chamada de action ou redirecionamento para página, essa é uma solução mais transparente.

Você ainda pode configurar quais métodos você quer interceptar ou/e quais métodos você não quer.

Beleza, agora temos tudo configurado! Mas e se a requisição demorar? Vamos dar um feedback para o usuário, usando wait Pages.

Para isso iremos precisar do execAndWait interceptor. Precisamos configurar o execAndWait como o último interceptor na pilha, pois ele para a execução de interceptors, apenas a action é executada depois de sua chamada.

Devemos configurar o result wait, que indicará qual página será chamada, dessa forma:

Para sairmos da página de espera devemos utilizar alguns artifícios do próprio HTML, por exemplo o meta. Na página de espera coloque dentro da tag head:

Pronto! Depois de 1 segundo a página será recarregada, se a requisição tiver sido concluída seremos redirecionados para página de resultado, se não voltaremos para página de espera e ficaremos aguardando mais 1 segundo.

Com esse conjunto de recursos conseguimos diminuir o número de requisições desnecessárias ao servidor e melhoramos a interação com o usuário. Até a próxima.

o/

Passamos umas três semanas offline em razão de um problema esquisito que deu no Typo, nosso engine de blog. Mas, como devem ter percebido, desde a última semana, estamos de volta!

Continuando o papo de SOA,  minha primeira manifestação aqui no blog sobre o assunto foi uma discussão filosófica que se resume da seguinte forma:

Daí, descrevi minha percepção sobre a visão moderna do assunto, que definiria SOA, em primeiro lugar, como um ESTILO de arquitetura que busca primordialmente maior LUCRATIVIDADE para o negócio do cliente através da preocupação constante com o ROI, fazendo o REAPROVEITAMENTO máximo dos ATIVOS existentes de forma ÁGIL, não necessariamente visando a rapidez, mas a EFETIVIDADE dos resultados.

Então, na prática ocorre o seguinte:

Empresas privadas e órgãos públicos possuem hoje um grande parque de legados de software que se constituem em ativos imateriais nos quais muito investimento já foi realizado e cujo redesenvolvimento poderia não ser a estratégia mais inteligente em termos de ROI.

Em se tratando de um conjunto estático e estável de sistemas legados, o reaproveitamento de seus serviços em novas soluções é facilmente resolvido com algum esforço pontual de desenvolvimento para externalização de funcionalidades através de alguma interface compreensível por todos os interessados.

Contudo, considerando que, neste conjunto, novos elementos podem surgir dinamicamente, decorrentes de parcerias entre Órgãos, disponibilização pública de sistemas na Internet ou aquisição de produtos tecnologicamente heterogêneos, a implementação manual de cada necessidade de integração pode não ser  a decisão mais efetiva, e daí surge a questão: como garantir o mínimo de dinâmica na integração de legados para potencializar meus lucros?

Simplificadamente, eu vejo duas formas básicas de integração de serviços.


Ou a integração se dá ponto-a-ponto, ou numa topologia de estrela.

A integração ponto-a-ponto interliga dois serviços de forma direta, através de tecnologias bastante conhecidas pela comunidade desenvolvedora. Neste modelo, cada serviço acopla-se diretamente a outro, sem possibilidade de muita dinâmica na colaboração.


Já na integração estrela, os serviços não interagem entre si de forma direta, mas de forma desacoplada, através de algum elemento intermediário que intercepta todas as mensagens e as reencaminha a seus destinatários. Este man-in-the-middle já recebeu vários nomes ao longo da história, mas chega atualmente sendo chamado de Barramento Corporativo de Serviços (ou Barramento de Serviços Corporativos, sei lá) ou, da sigla em inglês, ESB.

Há uma baita discussão sobre ESB. Há os que o defende como produtos e os que garantem se tratar não mais que um modelo arquitetural. Independente do mérito, é ao seu redor que orbitam todas as grandes plataformas SOA de mercado.

Em síntese, num ESB, vários serviços se conectam ao barramento e, quando da necessidade de comunicação de um serviço S1 qualquer com outro S5, por exemplo, ocorrem os seguintes passos:

1. S1 produz a mensagem a ser enviada a S5
2. S1 posta a mensagem no barramento (por enquanto, não se preocupe em como isso é feito)
3. O barramento (ESB) transmite a mensagem ao serviço de destino S5
4. S5 lê e processa a mensagem recebida

No mundo JBoss, esta estrutura é implementada no projeto JBoss ESB.



Entretanto, na vida real, nem sempre os cenários são tão simples quanto o exemplo apresentado. Por exemplo, nem sempre o formato de mensagem produzida pelo serviço S1 é compatível com o formato de mensagem compreendida pelo serviço S5, o que gera a necessidade de conversão da mensagem durante sua passagem pelo barramento.

Outro complicador da vida real é que nem sempre o destino da mensagem é previamente conhecido por seu emissor, ficando esta decisão por conta do próprio barramento.

Transformação e roteamento dinâmico de mensagem são apenas 2 exemplos de funcionalidades normalmente disponíveis nos principais ESBs de mercado. Outros  problemas comuns da integração de serviços são também resolvidos nesses produtos. E, sendo a tecnologia Java uma das principais protagonistas deste mundo de integração de serviços corporativos, há sempre as alternativas programática e declarativa para uso dos serviços nativos dos middlewares ESB.

 Mas, os problemas não páram por aí.

A medida que a integração entre serviços se torna prática estabelecida (e amadurecida), é natural que as estruturas de relacionamento entre sistemas fiquem cada vez mais complexas, envolvendo cada vez mais serviços (e até pessoas), em cenários cada vez mais heterogêneos. Uma mensagem que nos primeiros projetos de ‘SOA’ era simplesmente produzida por um serviço X e consumida por outro Y, com necessidades exporádicas de conversão e/ou roteamento, é, em arquiteturas mais avançadas e complexas, consumida e transformada por vários atores, que a processam em fluxos específicos e, por que não, dinâmicos.

Fui apresentado ao spring pelo Bruno Pedroso, não sabia muito bem com o que estava mexendo, mas utilizei na época o spring apenas para injetar alguns beans e etc. Continuei com o spring por vários projetos, alguns pessoais, outros da empresa, e hoje posso dizer que se tiver alguma solução para o meu problema que se integre ao spring ou que já exista nele eu não penso duas vezes em utilizar.

Nessa próxima sprint do eplamtax precisaremos de alguns recursos de segurança, e o que iremos utilizar? Spring security é claro!

O Spring security (SS) é um framework Java que provê avançados recursos de autenticação e autorização, além de outras coisas. Muitas pessoas desconhecem mas esse projeto começou em 2003 com o Acegi Security, mas o projeto foi incorporado ao spring e teve seu nome mudado.

Este será um blog técnico, vejamos então como configurar o spring security, para isso já devemos estar com o spring configurado. Para quem utiliza maven devemos configurar o pom.xml com as seguintes dependências:

Feito isso devemos configurar o filtro do spring security (SS) no web.xml. Lembrando que os filtros são executados na ordem em que estão configurados no Deployment Descriptor(DD), logo para que você consiga interceptar todos os requests é necessário colocar o filtro do SS como o 1° filtro.

O spring é totalmente configurável, criamos os beans e etc no arquivo application-Context.xml, mas para manter as coisas organizadas geralmente separamos em vários arquivos. Então vamos criar um arquivo application-Context-security.xml e importá-lo no application-Context.

Vamos utilizar o auto-config do SS, para isso devemos utilizar a seguinte tag no application-context-security:

Para que o SS tenha acesso aos dados do usuário nós iremos criar uma ponte entre o framework e nossa base de dados, o SS possui as interfaces UserDetail e UserDetailService que deveremos implementar em nossos beans. Vejamos como ficaria um bean que implementasse UserDetail:

A interface UserDetail possui as seguintes assinaturas:

Note que nosso objeto não possui atributo username nem authorities, pois esses dados estão em outra base de dados da qual Pessoa é carregada. O método getAuthorities retorna um array de GrantedAuthority, esta interface possui apenas um método, getAuthority, que retorna uma string. Uma GrantedAuthority, como o nome bem diz, é uma autorização concedida aquele usuário.

O framework possui uma classe GrantedAuthorityImpl, que possui um construtor com uma String, veja nossa implementação do método getAuthorities:

Depois de criada a classe que implementa UserDetais devemos implementar a UserDetailService:

A interface UserDetailService possui apenas um método:

Esse método será utilizado para carregar seu objeto de usuário pelo SS. Devemos informar ao Spring Security (SS) a classe que implementa o UserDetaiService, as configurações no application-Context-security ficaram da seguinte forma:

Com isso nós já temos o SS instalado e configurado. Para utilizar as taglibs do framework devemos adicionar mais uma dependência no pom.xml:

E depois:

Nosso application-context-security:

O SS permite que a autenticação seja feita pelo LDAP e permite customizações em toda a sua arquitetura, é um framework bem flexível, mas isso já é assunto para outro blog.

o/

Nessa Quarta vamos por o TDD em ação!

 

 

SEArenses, vamos comparecer ao DOJO, por nossas habilidades a prova, ver como filosofias simples realmente fazem diferença ao se desenvolver software, aprender um pouco mais sobre TDD e comer um lanche bacana! Inscrições Abertas! ;-)

 

 

Esse sábado realizamos a primeira turma do minicurso XP na prática.

Gostaríamos de agradecer mais uma vez o interesse de todos! Foi muito legal a participação de todos, o resultado final do código que produzimos, e a ótima discussão que tivemos na retrospectiva do curso, após nossa release !!!

O curso foi mais rápido do que gostaríamos, mas vale dizer que são apenas as primeiras iniciativas. Pela procura que tivemos nessa primeira edição, já pintaram oportunidades de fazer mais duas turmas aqui em Brasília no mês que vem (se vc mandou email, já faz parte dessa segunda leva). Apareceram também oportunidades de realizarmos o curso em Goiânia e no Rio, e é provável que montemos mais alguma(s) turma(s) em algumas empresas e órgãos públicos. Além disso, apareceram outras oportunidades e é bem provável que no segundo semestre organizemos um curso mais completo, com uma carga horária mais apropriada para tratarmos o assunto (que é bem extenso) com mais calma.

No próximo sábado realizaremos a segunda turma, conforme havíamos combinados, e com isso nossa viajem para Salvador está garantida (valeu moçada!!!).

Alô, alô, gente boa. É com prazer que anunciamos a realização do nosso primeiro curso de Extreme Programming!

Acontecerá no dia 07 de março, sábado, logo após o carnaval. Terá a duração de 8h (sim, o dia todo) e tem o objetivo de explicar teoricamente (pouco) e experimentar na prática (muito) uma pequena release em um projeto XP real.

A intenção é conduzir duas iterações, envolvendo levantamento das histórias, planejamento, programação, etc.. Iremos envolver 4 pessoas na realização do curso: um coach (eu), um product-owner (o Willi) e dois monitores (Túlio e Carol) para ajudar o pessoal com TDD.

O curso está sendo realizado para arrecadar fundos para que possamos pagar as passagens do Tulio e da Carol para Salvador, já que vamos realizar o mesmo curso lá, durante o Maré de Agilidade - swell Salvador. (Leia lá a descrição do curso, como a publicamos para o evento.)

O valor das inscrições… vai depender da quantidade de pessoas inscritas. :-) Em outras palavras, iremos ratear o custo de duas passagens (ida e volta) por todos aqueles que participarem do curso.

Estimamos que na nossa sala (ilha de bali) cabem confortavelmente 12 pessoas, além de nós 4. Então, a princípio, se essa turma encher, montamos outra para o dia 14/03 - o fim de semana seguinte. Se fecharmos apenas uma turma de 12 pessoas, o preço será de R$100. (preço de banana!) Se conseguirmos encher as duas turmas, o curso sai a R$50 pra cada (nem banana se compra com isso).

Então, vale ressaltar: se vc chamar seu amigo pra fazer o curso, o preço diminui pra todo mundo :-)

Entregaremos certificados e serviremos um lanchinho simples.

Reserve logo sua vaga, mandando um email para bruno ponto pedroso arroba sea tecnologia ponto com ponto br, com o seguinte assunto “inscrição curso XP”. Levaremos em conta a ordem de chegada das mensagens, então apresse-se!

Vamos pra Bahia?



No tabuleiro do Maré tem…

Scrum, Olodum

XP, TDD, FDD, DDD e Dendê

Acarajé, Vatapá e programação em Par

Caruru e Kanban

Pelô, Lean e muita história pra contar.

Ô Bixinho, você não pode perder!



Mais informações: http://www.maredeagilidade.com.br/

Oxi!

PS: Gostou mas não pode ir? O Maré de Agilidade agora é nosso Road Show oficial. Se quiser que ele aconteça na sua cidade, entre em contato conosco!

PPS: Quer colocar banners no seu site ou blog? Entre aqui.

O ágil em sua forma mais simples é aquele sentimento que todo desenvolvedor tem: uma equipe que trabalhe de forma cooperativa, não ter retrabalho, etc.

Tudo gira em torno da qualidade de vida e do trabalho em equipe, e quando falamos em equipe nos referimos inclusive ao cliente, que deve participar de todo processo de desenvolvimento, que deve receber versões semanais para testes e contribuir com a construção de seu próprio produto.

Estamos na era da colaboração, como foi dito no evento maré de agilidade ano passado (2008), devemos interagir mais com o cliente, levantar requisitos por demanda, refatorar o código, etc. Considero a maior interação com o cliente e equipes multidisciplinares como o “trunfo” das práticas ágeis, com esses dois pilares conseguimos adaptar o modelo e obter sucesso no desenvolvimento de sistemas, e não pense que são apenas sistemas pequenos!

Por fim, para que isso dê certo devemos ter uma equipe colaborativa, ela deve ser pró-ativa como um todo, devemos tomar cuidado, pois uma só engrenagem fora do lugar e condenamos todo o sistema. Equipes colaborativas homogenizam o conhecimento e se tornam auto gerenciáveis, aumentando sua eficiência e reduzindo suas falhas.