Publicado em 17/03/2016 17/03/2016 Autor Rafael Odon de AlencarCategorias devTags JAAS, java, jboss, ldap, login-module2 comentários em Integrando sua aplicação web com LDAP no JBoss EAP 6 através do JAAS	
Em um projeto que participo, há um conjunto de EJBs stateless reponsáveis por atender chamadas. Foi preciso disponibilizar para todas as camadas um contexto de mensagens cujo escopo é uma chamada ao serviço. Como não seria possível usufruir de um bean com escopo de Request, que exigiria trabalhar com beans stateful, simulei esse contexto através de ThreadLocal. Conforme a teoria, esse recurso “provides thread-local variables (…) each thread has its own, independently initialized copy of the variable.”
Por ser um ponto crítico do sistema, desejei criar um teste automatizado para garantir o comportamento ao longo das mudanças. Em linhas gerais, o teste deveria criar várias threads utilizando seus contextos de mensagens e certificar que eles não se sobrepusessem. Durante a prospecção soube que o framework TesteNG fornece a opção de testes com múltiplas threads, mas julguei que seria um teste muito simples para precisar de uma biblioteca adicional.
Um ponto interessante é introduzir algum grau de desordem no paralelismo, oque foi feito fazendo a thread dormir por um tempo aleatório antes de realizar o teste. Além disso, é primordial fazer join() das threads criadas ao fim do teste unitário para certificar que o JUnit não prosseguirá para outros testes enquanto ainda existem threads rodando do teste atual.
Publicado em 17/03/2016 17/03/2016 Autor Rafael Odon de AlencarCategorias devTags java, junit, teste, testeng, thread, threadlocalDeixe um comentário em Teste unitário com múltiplas threads no JUnit	
Em um projeto que participo surgiu a necessidade de utilizar um motor de regras de negócio para fornecer ao cliente a possibilidade de gerenciar as regras de um processo por conta própria. Como o sistema é em Java, o Drools, mais especificamente o sub-produto Drools Expert, se mostrou uma opção interessante, principalmente pela possibilidade de criar uma Linguagem Específica de Domínio (DSL).
Ao estudar a ferramenta na Web, percebi uma vasta gama de tutoriais, cada um com sua forma de criação e configuração do projeto, muitas vezes ainda apegado a versões inferiores a 6 da ferramenta.
Apresento aqui uma forma bem enxuta, usando o Eclipse como IDE e o Maven como gerenciador de dependências e builds:
2. No pom.xml do projeto, colocar como dependências o drools-compiler, bem como uma biblioteca de log compatível com SLF4J (sugiro a Logback), conforme o trecho abaixo:
3. Sugiro ainda que no pom.xml você determine como configuração de build a versão do Java desejada, aqui no caso a 1.7. Para isso faça conforme o trecho abaixo:
2. Acionar botão direito no projeto, Maven > Update Project para que o Eclipse perceba as novas configurações
6. Se desejar utilizar o plugin do Drools no Eclipse, que facilita algumas tarefas mas não é essencial, instale os artefatos desejados do update site:
No meu github coloquei um exemplo completo de Drools usando tanto DRL (linguagem de regra do Drools) e DSL (linguagem específica de domínio) para aplicar regras de negócio num exemplo de carrinho de compras com descontos no preço e no frete: https://github.com/rafaelodon/poc-drools
Publicado em 25/02/2016 06/03/2016 Autor Rafael Odon de AlencarCategorias devTags drools, dsl, eclipse, java, mavenDeixe um comentário em Configurando um projeto mínimo com Drools 6 no Maven	
Esses dias eu estava super cliché, meio crítico com o fato de surgir tanta tecnologia nova o tempo todo. Praticamente a cada 4 anos a gente precisa se renovar para não ter o aspecto técnico do currículo anulado nos 4 anos seguintes. Tudo bem que muitas dessas novidades advém de um movimento natural promovido pelas grandes inovações (desenvolvimento mobile por exemplo). Mas é comum assistir tecnologias morrendo e dando lugar a outras que produzem o mesmo resultado, sem justificativas convincentes.
Por um instante cheguei a formular a hipótese que na verdade isso era um fenômeno de procrastinação coletiva promovido pelo [in]consciente coletivo dos profissionais de TI, que acham super recompensador gastar seu tempo tendo que reaprender como fazer o mesmo de forma diferente. Talvez tenha um pouco disso também. Mas pensando melhor, percebo também um padrão de sabotagem que é descrito no ciclo abaixo:
#1 – The dawn of man: Surge uma Nova Tecnologia ®, ainda incipiente , mas que promete suprir uma deficiência do ferramental vigente.
#2 – O buzz: A Nova Tecnologia ® atrai a atenção de acadêmicos e entusiastas que se aproveitam do pioneirismo para surfar na crista da onda, publicando em revistas, palestrando em eventos, etc. Mas tudo se resume ao buzz. O mercado corporativo ainda olha com desconfiança.
#3 – Mordendo a maçã: Versões novas são lançadas, boas práticas são disseminadas, cursos, artigos, tutoriais, tópicos em fóruns, perguntas e respostas saturam a web. Convencidos pelos gurus, vai surgindo na manada de profissionais espectadores o desejo de adotar a Nova Tecnologia ®, tanto pelo prazer de aprender algo novo quanto pela necessidade de manter seus currículos atualizados.
#4 – As invasões bárbaras: Com o mercado de trabalho recheado de defensores da Nova Tecnologia ®, corporações de impacto passam a adotá-la em projetos relevantes que apresentam desafios reais, em escala real. E esses projetos introduzem um outro fator crucial: a pressão por prazo. Prazo leva à pressa que leva ao aumento de recursos. Nesse clima, uma manada de profissionais sub-qualificados e por vezes sub-remunerados, forçam pro-ativamente o uso indiscriminado da Nova Tecnologia ®. Tudo é resolvido da forma mais imediata o possível, com muita gambiarra, sem avaliar alternativas, sem conhecer recursos avançados, buscando resultados rápidos que salvem o projeto (e também seus empregos). Julgando-se produtivos e confortáveis com a Nova Tecnologia ®, está formado um batalhão de martelos que acha que tudo é prego.
#5 – Sodoma e Gomorra: Com o colapso de grandes projetos que adotaram a Nova Tecnologia ®, começam a sair cases de insucesso, artigos que condenam seu uso e o famoso anúncio: “a Nova Tecnologia ® morreu“. Por mais que os gurus afirmem que são os profissionais que usaram de forma errada, e que as novas versões incluam recursos que suprem as deficiências e introduzem melhorias, a tecnologia continua estigmatizada por suas restrições conceituais e efeitos colaterais do uso costumeiro.
Publicado em 10/12/2015 18/12/2015 Autor Rafael Odon de AlencarCategorias dev, txtTags desenvolvimento, tecnologiaDeixe um comentário em O Ciclo de Sabotagem das Tecnologias de Desenvolvimento de Software	
Sempre fui crítico com o rótulo arquiteto de software. Se a gente parar pra pensar, é um nome um tanto quanto mal escolhido. Na engenharia civil, o arquiteto é o desenhista do prédio, o artista do concreto. Oscar Niemeyer rabiscava formas modernistas no papel e pouco se importava em como aquilo viraria realidade, o que de fato seria um problema para os engenheiros.
Já na área de software, quem costuma imaginar coisas difíceis de por em prática é o cliente, o demandante. Para executar suas idéias mirabolantes há de se contar com super-heróis capazes de eleger plataformas, tecnologias, protocolos, padrões, componentes, topologias e de projetar como isso tudo vai conversar. O curioso é que o nome que se dá para esse super-herói é justamente arquiteto de software.
Eu particularmente acredito que essas atribuições sejam apenas a descrição de um bom desenvolvedor, ou para ser mais justo ao argumento, um bom engenheiro de software. O curioso é que quase não se vê o termo engenheiro de software circulando em vagas de emprego no mercado brasileiro. Acredito que isso se dê por alguns fatores.
O primeiro deles advém da própria distinção que os desenvolvedores gostam de ter em relação às demais engenharias. Há todo um brio envolvido no domínio da arte de desenvolvedor sistemas, principalmente quando você fica anos estudando muito além da programação. Talvez não queiramos ser confundidos com engenheiros civis ou mecânicos. Enquanto isso, na mão contrária do nosso ego, o mercado de trabalho acha ótimo que nos consideremos apenas desenvolvedores, uma vez que engenheiros tem conselho, piso salarial e algum respeito perante a sociedade. Engenheiros constroem prédios. Nós “mexemos” com informática.
Mas então, se formamos uma manada de desenvolvedores egocêntricos, quem são os famosos arquitetos de software? Pessoalmente ainda acho que um arquiteto é nada mais nada menos que um bom engenheiro de software, com experiência, senso crítico e visão micro e macro sobre a pilha de tecnologias envolvidas num sistema. O que percebo é que os que se dizem arquitetos buscam nesse rótulo uma distinção, não querem ser confundidos com meros programadores, uma atividade mais básica. Da mesma forma, os desenvolvedores também não querem se responsabilizar por decisões que irão assombrar o projeto pelo resto dos dias, podendo trazer impactos diretos na performance e disponibilidade do sistema. E é nesse contexto que a arquitetura de software vai se tornando ocultista e mística, fazendo com que os programadores se distanciem do que deveria ser o grande objetivo: se tornar um excelente profissional.