Publicado em Arquiteto

Arquitetura – Ten Coding Guidelines in Practice.

Real_World_Maintainable_Software_frontA indústria de desenvolvimento de software esta cada vez mais percebendo que o sucesso de um projeto depende da viabilidade a longo prazo. Para ajudar nesse esforço, a SIG identificou dez orientações para a entrega de código que é fácil de manter e adaptar-se ao longo do tempo. Veja nesse e-book grátis! Gostaria de aprender  mais sobre esse assunto? Veja nosso curso de AQT M1 – Introdução a Arquitetura de Software e saiba como criar um projeto sustentável.

“Tu és o meu esconderijo e o meu escudo; eu ponho a minha esperança na tua promessa.” Salmos 119:114

Publicado em Arquiteto

DBeaver – Conecte em todos os seus bancos de dados relacionais e nosql

beaver-headVocê já ficou cansado de entupir e estragar sua maquina por ter que instalar 1 ferramenta de administração para cada banco de dados diferente? SQLServer + MySQL + MongoDB? Eu já fiquei e muito ainda!!!

Resolva seu problema com usando o DBeaver – http://dbeaver.jkiss.org, ferramenta simples, de graça, feita em java, baseada no eclipse, usa maven para baixar os driver e muito fácil de usar. Ufaaaaa……acabou o terror!

Free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports all popular databases: MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, Teradata, MongoDB, Cassandra, Redis, etc.

“A luz brilha na escuridão, e a escuridão não conseguiu apagá-la.” João 1:5

Publicado em Arquiteto

Livro Grátis – Software Architecture Patterns

catO sucesso de qualquer desenvolvimento de software depende também de um bom padrão de arquitetura. Ao descrever as características gerais da arquitetura, esses padrões não só orientam os designers e desenvolvedores sobre como componentes, mas também determinar as maneiras pelas quais esses componentes devem interagir. Veja nesse livro um mergulho profundo em muitos padrões de arquitetura de software comum. Cada padrão inclui uma explicação completa de como ele funciona, explica os benefícios, considerações do padrão, e descreve as circunstâncias e condições que se destinava a resolver. O livro também inclui uma análise e scorecard para cada padrão com base em vários arquitetura de software e atributos de qualidade de desenvolvimento. O livro é grátis e pode ser baixado nesse link. Bons estudos:) !

“Assim já não sou eu quem vive, mas Cristo é quem vive em mim. E esta vida que vivo agora, eu a vivo pela fé no Filho de Deus, que me amou e se deu a si mesmo por mim.” Gálatas 2:20

Publicado em Arquiteto

Plano de Evolução – Nível de Qualidade Equipe Java

imagesEm uma das empresas que eu atuo como consultor, eu acabei construindo uma classificação que define o nível de qualidade da solução produzida por uma equipe de desenvolvimento Java. Esse plano foi utilizado para conscientizar qual era a real situação da qualidade do código produzido pela corporação e principalmente para traçar um plano de evolução para cada programador da equipem utilizado no conceito “de pronto” do Scrum. Hoje eu gostaria de publicar o plano com objetivo de receber sugestões sobre o assunto. Segue abaixo:

Nível 0

É classificada como “nível 0” uma equipe de desenvolvimento que codifica suas soluções Java sem nenhuma práticas, diretrizes ou patamar qualidade estabelecido, deixando o fato de livre decisão a cada desenvolvedor.

Nível 1

É classificada como “nível 1” uma equipe de desenvolvimento que consegue codificar suas soluções Java compatível com as seguintes práticas:

  1. Java Code Convention – o código da solução é escrito seguindo o padrão mundial de organização e nomeação dos elementos de programação.
  2. Java Doc – o design da solução é 100% documentada ao mesmo tempo em que é desenvolvida.

Nível 2

É classificada como “nível 2” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1”, acrescidas simultaneamente das novas seguintes práticas:

  1. Java Efetivo – o código da solução contempla o uso correto dos idiomas de programação Java descrito pelo Joshua Bloch em seu livro Java Effective.

Nível 3

É classificada como “nível 3” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2”, acrescidas simultaneamente das novas seguintes práticas:

  1. TDD – o código da solução é escrito seguindo o a filosofia baseada em testes, criando na solução algum nível de cobertura de testes automatizados.

Nível 4

É classificada como “nível 4” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3”, acrescidas simultaneamente das novas seguintes práticas:

  1. Princípios OOP – o código da solução contempla o uso de princípios básicos e elementares da programação orientado a objetos.
  2. Padrões de Projeto – o código da solução contempla o uso correto de padrões de projeto.

Nível 5

É classificada como “nível 5” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4”, acrescidas simultaneamente das novas seguintes práticas:

  1. Refatoração – o código da solução contempla o uso correto dos princípios de refatoração de programação Java descrito pelo Martin Folwer.
  2. Programação pareada – o código da solução é aperfeiçoada com a refatoração utilizando a pratica de programação em par.

Nível 6

É classificada como “nível 6” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4 + 5”, acrescidas simultaneamente das novas seguintes práticas:

  1. Desenvolvedor Oracle Certified OCA e OCP – o código da solução contempla o uso adequado dos recursos básicos de programação e API JSE resultantes do conhecimento adquirido pela processo de certificação oficial Java.

Dicas

Scrum Masters, gerentes XP ou GP responsáveis pelas equipes podem utilizar estes níveis de qualidade para propor uma plano de evolução individual a cada membro desenvolvedor. Vale lembrar que os níveis são cronologicamente evoluídos. Desafie sua equipe e veja como eles podem construir uma solução Java com o mais alto padrão de qualidade. Só que já passou por isso é que pode realmente saber da diferença da entrega e manutenção de uma solução baseado no nível da equipe. E você? Em que nível você se encontra?

Disse Jesus: “Nem ele nem seus pais pecaram, mas isto aconteceu para que a obra de Deus se manifestasse na vida dele”. João 9:3

Publicado em Arquiteto

Microservices = Sistemas grandes e complexos

virgula-mulher-duvidaA arquitetura monolítica é um padrão comumente usado para o desenvolvimento de aplicações corporativas. Esse padrão funciona razoavelmente bem para pequenas aplicações, pois o desenvolvimento, testes e implantação de pequenas aplicações monolíticas é relativamente simples. No entanto, para aplicações GRANNNNDESSS E COMPLEXAAASSSSSSSSS, a arquitetura monolítica torna-se um obstáculo ao desenvolvimento e implantação, dificulta a utilização de uma entrega contínua, além de limitar a adoção de novas tecnologias. Para grandes aplicações, faz mais sentido usar uma arquitetura de microservices, que divide a aplicação em um conjunto de serviços.

Acho que tem gente que ainda não entendeu o x dessa questão. Eu ando vendo por ai gente fazendo microservices com meia duzia de classes, entrando em um buraco tão grande problemas resultantes dessa nova abordagem sem nenhuma necessidade. Quando você usa microservices sem precisar, você acaba ganhando de brinde tantos problemas extras, que tem gente passando mais tempo resolvendo eles do que usufruindo dos benefícios dessa nova abordagem arquitetural. Mais uma vez, o modismo e os artigos das revistas tem influênciado os leitores erradamente.

“Eu lhes dou este novo mandamento: amem uns aos outros. Assim como eu os amei, amem também uns aos outros.” João 13:34

Publicado em Arquiteto

Diagramação

2image02

Draw.io é uma ferramenta de diagramação gratuita disponível para desktop como um plugin para o navegador da Google Chrome ou para uso de forma online desenvolvido pela JGraph. Com o draw.io é possível, de forma simples e rápida, criar uma grande variedade de diagramas, como por exemplo: diagramas de fluxo de dados, diagramas de rede, diagramas UML, mapas mentais, diagramas de BPMN entre outros. Outra facilidade que esta ferramenta possui é a de integração com Dropbox, OneDrive e Google Drive, para armazenamento dos diagramas criados. Além disso, o draw.io pode ser integrado com as ferramentas da Atlassian como Jira e Confluence. Existem vários tutoriais no site do draw.io para os primeiros passos. Até a próxima!

“Eu afirmo a vocês que isto é verdade: quem ouve as minhas palavras e crê naquele que me enviou tem a vida eterna e não será julgado, mas já passou da morte para a vida.” João 5:24

Publicado em Arquiteto, Frameworks Effective

Saia do Java Boilerplate

DontRepeatYourself

Você já se cansou de fazer get’s, set’s, equals, hashCode, toString e objetos imutáveis para suas classes Java? Eu já! Segue aqui algumas opções de frameworks que resolvem essas repetições:

Outra opção é mudar de linguagem, eu mesmo uso Groovy. Bons estudos para todos!

“Portanto, deixem todo costume imoral e toda má conduta. Aceitem com humildade a mensagem que Deus planta no coração de vocês, a qual pode salvá-los.” Tiago 1:21

Publicado em Arquiteto, JEE

DWR – Direct Web Remoting

dwr-logo-200DWR – Direct Web Remoting é um framework proprietário em Java que permite Java no servidor e JavaScript em um navegador interajam via AJAX tão simples quanto possível. Alem de ser usado para fazer AJAX, DWR pode ser utilizado como protocolo de integração entre clientes AJAX de outras plataformas ! Ótimo produto para algumas boas situações. Bons estudos pessoal:) .

“Ó SENHOR Deus, quando senti que poderia morrer, o teu amor me amparou. Quando estou aflito e preocupado,” Salmos 94:18-19 

Publicado em Arquiteto, JSE

Aprendendo a usar o escopo Thread-Local Java

Dentro da programação de uma solução usando a tecnologia Java, os desenvolvedores tem a responsabilidade diária de escolher corretamente em qual escopo de ciclo de vida seus objetos existiram. Em minhas consultorias em geral venho percebendo que a maioria dos profissionais Java desconhecem completamente um dos escopos mais interessantes e muito eficiente chamado de Thread-Local. A falta de uso desse escopo em uma solução pode gerar complicadores agravantes na arquitetura, levando a implementação na maioria das vezes para o caminho da complexidade e inflexibilidade. Diante esse cenário, hoje eu gostaria de apresentar o conceito e prática desse escopo, fazendo com que programadores e projetistas Java possam se equipar com mais esse poderoso recurso do JSE.

O que é Thread-Local?

Thread-local é considerado como mais um “escopo de acesso” como outros muitos existentes dentro do Java utilizado para definir o ciclo de vida dos objetos existentes durante a execução de um programa orientado a objetos. O grande diferencial desse escopo seja talvez pelo fato dele ser completamente baseado em conceitos de programação concorrente, fazendo com ele fique um pouco mais complicado de se entender e usar.

Como funciona?

O escopo Thread-Local possui dois tipos de comportamento distintos que lhe diferencia drasticamente dos outros. Poderíamos chamá-los de global e local.

  • Global – todos os objetos armazenados em uma Thread-Local são globais para a thread corrente de execução. Isso que dizer que os métodos de quaisquer objetos sendo executados dentro de uma mesma thread terão visibilidade para este escopo.
  • Local – todos os objetos armazenados em uma Thread-Local estarão restritos somente para objetos sendo executado dentro da determinada thread. Isso que dizer que os métodos de quaisquer objetos sendo executados em outras threads não terão visibilidade para este escopo.

O ponto de referencia para se assimilar a brincadeira é se conscientizar que quem executa um método de um objeto dentro de um programa Java é justamente algum objeto Thread, sendo ele criando manualmente ou não. Dentro de cada thread existe então um lugar especial que pode ser usado para armazenar objetos pertencentes especificamente a thread. Todos as chamadas de objetos que forem empilhados naquela thread terão visibilidade transparente para esse escopo, podendo então usa-lo para os mais diferentes propósitos.

Para tentar clarear mais as idéias, eu poderia dizer que o escopo Thread-Local funciona basicamente da mesma forma que o famoso e velho de guerra escopo estático. Todos os objetos colocados como estáticos no Java são criados apenas uma vez e ficam na memória até o termino da JVM. A única diferença é que os objetos colocados na Thread-Local ficam na memória até o termino da execução da determinada thread corrente. O escopo acaba, quando a Thread terminar de ser executada.

A figura abaixo apresenta um gráfico que ilustra a escopo estático:

Temos na figura acima dois objetos do tipo thread invocando concorrentemente métodos de alguns objetos compartilhados e outros objetos não compartilhados. Tudo que é colocado como estático é globalmente compartilhado para todas as threads e todos os objetos sendo executados dentro de cada thread.

Já na próxima figura temos a representação que ilustra o escopo Thread-Local:

Temos na ultima figura dois objetos do tipo thread invocando concorrentemente os mesmo objetos da primeira figura. Nesse caso em especifico, o escopo Thread-Local age como um compartimento opcional colocado dentro da cada thread, no qual todos os métodos invocados dentro daquela determinada thread tem acesso transparente, podendo usá-lo para qualquer fim necessário.

Quando usar Thread-Local

Use em qualquer lugar que necessite compartilhar objetos em nível de execução de Thread. Alguns possíveis exemplos seriam – parâmetros de sistema, parâmetros de usuários, parâmetros de autenticação e autorização e até parâmetros de processos. Um caso clássico de Thread-Local é a propagação de objetos de transação JDBC com chamadas recursivas. Objetos do padrão DAO poderiam usar este escopo para compartilhar a transação corrente, adicionando varias instruções SQL de diferentes objetos DAO. Frameworks que oferecem serviços transacionais para camadas de persistência como Spring utilizam-se dessa abordagem, podendo também ser facilmente implementada sem nenhum framework de terceiro.

A escopo Thread-Local é disponibilizado no Java usando a classe java.lang.ThreadLocal. Para todas as informações dessa classe, veja o JavaDoc.

Prática

Segue abaixo a implementação de um exemplo bem simples de Thread-Local.

A primeira classe chamada de ClasseThreadLocal foi utilizada para implementar a escopo Thread-Local. A segunda classe chamada de Regra foi utilizado para implementar o objeto que será executando concorrentemente dentro de varias threads. Veja que o método gravar() apenas acessa o valor dentro do escopo Thread-Local. Já a classe ProcessoThread  foi utilizado para implementar as threads que serão executadas em paralelo. Veja que o método run() armazena um objeto do tipo String dentro do escopo Thread-Local que será posteriormente acessível dentro do objeto implementado pela classe Regra. Por fim vemos a classe Exemplo implementando a método main() que faz toda a brincadeira acontecer. Veja que ele cria apenas um objeto Regra e quatro objeto ProcessoThread. Resumidamente, cada objeto thread executa concorrentemente o mesmo objeto Regra que transparentemente e separadamente acessa cada um valor diferente pertencente a sua própria thread de execução.

Observação

Existe uma certa situação em usar Thread-Local dentro de containers JEE, uma vez que a maioria deles otimizam gatos com a criação de objetos threads usando abordagem de pool. Por isso, os objetos colocados dentro do escopo Thread-Local em execuções dentro de containers JEE podem ficar não elegíveis para o GC após a execução, uma vez a thread volta para o pool e fica disponível para a próxima invocação. A forma correta de tratar isso é limpar o escopo Thread-Local no final de cada execução, chamando o método ThreadLocal.remove(). Eu fico por aqui e espero que o artigo te ajude a usar esse incrível escopo. Aquele abraço😉 .

“Porque, se perdoardes aos homens as suas ofensas, também vosso Pai celestial vos perdoará a vós”. Mateus 6:14

Publicado em Arquiteto

Intenções de Padrões de Projeto

Hoje eu gostaria de abordar uma situação problemática que eu percebo acontecer repetitivamente com profissionais Java relacionado com o uso de padrões de projeto. Qualquer ser humano normal que já investiu tempo estudando diversos livros e materiais relacionados com catálogos de padrões de projeto, praticamente tem a tendência natural de esquecer a grande parte do conteúdo depois de um certo tempo. Partindo da idéia central de que um padrão simplesmente acontece em uma arquitetura, posso claramente afirmar que existe uma grande chance do profissional então não visualizar um determinado cenário favorável para a aplicação de um padrão. Por mais escancarado que uma situação arquitetural aponte para um padrão, se o profissional não estiver com as características daquele padrão injetado na memória, ele fatalmente não ira se beneficiar dos objetivos motivadores da existência de um padrão, enviando possivelmente sua arquitetura para o penoso caminho da inflexibilidade.

Mas como podemos então evitar tudo isso? A resposta é simples:

O profissional precisa apenas se preocupar em memorizar somente a “intenção central” de um padrão para que quando o cenário arquitetural aparecer, ele possa facilmente identificar o caso de aplicabilidade.

Com o objetivo de ajudar os desenvolvedores eu gostaria de publicar o meu resumo de intenções do catalogo de padrões GOF que utilizei para fazer esse mapeamento mental. Segue abaixo:

Padrões de Criação

As motivações dos padrões de criação esta centralizado em como os objetos são criados. Ou seja, eles são usados para capturar intenções focalizadas na criação de objetos.

Factory Method – sua intenção é definir um ponto de criação para um tipo de objeto no qual não se tem conhecimento do tipo concreto a ser usado.

Abstract Factory – sua intenção é definir um ponto de criação para uma família de objetos relacionados ou dependentes no qual não se tem conhecimento dos tipos concretos de todos estes objetos a serem usados. O Abstract Factory é basicamente uma “extensão em massa” do padrão Factory Method.

Prototype – sua intenção é definir um ponto de criação de objetos que precisam ser instanciados usando como base a cópia outro objeto molde denominado de “protótipo”. Todos os objetos criados passam a existir contendo valores copiados desse suposto objeto protótipo.

Singleton – sua intenção é definir um ponto de criação de objetos que necessitem ser instanciado somente uma vez durante todo o ciclo de execução da solução e oferecer um ponto único de acesso para essa referencia.

Builder – sua intenção é definir um ponto de criação de um objeto complexo de sua representação de forma com que esse ponto de construção possa ser parametrizado para construir diferentes variações desse mesmo objeto.

Padrões Estruturais

As motivações dos padrões estruturais esta centralizado na organização e composição de classes e seus objetos. Ou seja, eles são usados para capturar intenções focalizadas na composição estrutural dos objetos.

Adapter – sua intenção é converter a interface de uma classe para outra interface requerida, definindo um ponto intermediário de ligação com o objetivo de promover comunicação entre duas interfaces incompatíveis.

Bridge – sua intenção é separar a abstração de uma ação de suas diferentes implementações, de forma que ambas possam ser flexivelmente intercambiais.

Composite – sua intenção é fazer com que um objeto possa ser genericamente operado de forma que represente uma estrutura dinâmica hierárquica de composições de objetos.

Decorator – sua intenção é definir um meio alternativo a herança de adicionar responsabilidades ao um objeto de forma flexível e dinâmica em tempo de execução.

Facade – sua intenção é definir uma interface fácil, simples e unificada para um ou mais conjuntos de operações relacionados a subsistemas internos.

Flyweight – sua intenção é definir um ponto de compartilhamento eficiente que suporte um grande numero de manipulações de objetos de granulação fina reutilizáveis.

Proxy – sua intenção é definir um objeto-substituto para um objeto-real, de forma com que o objeto-substituto possa transparentemente intermediar as interações para esse objeto-real.

Padrões Comportamentais

As motivações dos padrões comportamentais esta centralizado nas responsabilidades e relacionamentos dos objetos. Ou seja, eles são usados para capturar intenções focalizadas no que um objeto pode fazer e como ele se relaciona com os outros.

Chain of Responsability – sua intenção é desacoplar o objeto-enviador de um pedido dos supostos objetos-receptores, possibilitando com que múltiplos objetos-receptores possam ser dinamicamente enfileirados para manipular o pedido transparentemente.

Command – sua intenção é fazer com uma requisição de um comando possa ser encapsulado como um objeto uniforme, permitindo com que objetos-clientes possam ser parametrizados flexivelmente com diferentes objetos-comandos intercambiais.

Interpreter – sua intenção é definir objetos que possam representar e interpretar intercambialmente uma determinada gramática textual qualquer.

Iterator – sua intenção é definir uma forma com que objetos agregados dentro de um objeto possam ser seqüencialmente acessados por outros objetos sem expor os detalhes internos de seus relacionamentos e implementações.

Mediator – sua intenção é definir um objeto utilizado para encapsular o relacionamento entre dois outros objetos, fazendo com que o determinado relacionamento destes dois objetos alvo possam ser implementado de forma indireta, flexível e intercambial.

Memento – sua intenção é definir uma forma de capturar e armazenar o estado de um objeto de forma com que essa objeto possa ser restaurada para o estado original anterior.

Observer – sua intenção é definir uma forma que possibilite um objeto agregador notificar e atualizar automaticamente outros objetos agregados dependentes quando ocorrer uma alteração no estado no objeto agregador.

State – sua intenção é definir uma forma que possibilite um objeto variar intercambialmente seus comportamentos quando mudanças internas no seu estado acontecerem.

Strategy – sua intenção é definir um objeto que possua determinados comportamentos que sofram variações intercambiais dependendo de outros objetos clientes que os manipulam.

Template Method – sua intenção é definir objetos que implemente um algoritmo previamente formatado dentro de um comportamento, fazendo com que outros objetos possam intercambialmente substituir partes das funcionalidades desse algoritmo.

Visitor – sua intenção é definir uma forma que possibilite que diversas operações possam ser dinamicamente aplicadas para um objeto, sem a necessidade alterar sua estrutura de definição.

Dicas

Se porventura você é um desenvolvedor que deseje não perder nem uma oportunidade de aplicar um padrão GOF, deve obrigatoriamente entender e decorar cada um dessas motivações. A dica principal é que o candidato primeiro precisa entender a motivação do padrão para depois memorizar sua intenção. Caso existe algum padrão GOF que você não tenha compreendido, separe um tempo de qualidade para estudá-lo para que posteriormente você tenha condições de memorizar sua motivação. Vale lembrar também que a dica serve para ser aplicada para outros catálogos.

“Olhem para o Senhor e para a sua força; busquem sempre a sua face.” 1 Crônicas 16:11