Arquivos | Arquiteto RSS for this section

The Java EE Architect’s Handbook

downloadThis handbook is a concise guide to assuming the role of application architect for Java EE applications. This handbook will guide the application architect through the entire Java EE project including identifying business requirements, performing use-case analysis, object and data modeling, and guiding a development team during construction. This handbook will provide tips and techniques for communicating with project managers and management. This handbook will provide strategies for making your application easier and less costly to support. Whether you are about to architect your first Java EE application or are looking for ways to keep your projects on-time and on-budget, you will refer to this handbook again and again.

What you’ll learn:

You will discover how to:

  • Design Java EE applications so that they are robust, extensible, and easy to maintain.
  • Assume the role of application architect on Java EE projects.
  • Apply commonly used design patterns effectively.
  • Identify and address application architectural issues before they hinder the development team.
  • Document and communicate the application design so that the development team’s work is targeted.
  • Avoid common mistakes that derail project budgets and timelines.
  • Guide the development team through the design and construction process.
  • Setup effective procedures and guidelines that increase stability and decrease defect reports.
  • Avoid common mistakes that make Java EE applications overly complex and hard to support.
  • Effectively estimate needed resources and timelines.

Who this book is for:

  • Senior Java EE developers looking to assume an architect role.
  • Junior Java EE application architects looking to improve their skills.

“Cantai a Deus, salmodiai o seu nome; exaltai o que cavalga sobre as nuvens. SENHOR é o seu nome, exultai diante dele. Pai dos órfãos e juiz das viúvas é Deus em sua santa morada.” Salmos 68:4-5

Java Spring Architect

logo-spring-103x60Mesmo depois dos avançados da especificação do JEE 6, vemos que ela ainda esta muito longe de se igualar as opções oferecidas pela plataforma Spring. Vale a pena lembrar que da mesma forma que as especificações vão melhorando ao longo do tempo, o Spring também vai evoluindo em uma velocidade muito mais rápida, uma vez que não depende de nenhum tipo de votação comunitária.

Eu mesmo ao longo dos meus 14 anos de Java, sempre tive a cautela de preferir produtos JCP ao invés de proprietários, visando o grande ideal da portabilidade e a independência de vendor, mas hoje eu venho publicamente concluir que tenho percebido que ao longo do tempo tenho adotado os produtos Spring mais e mais. Motivo? O mesmo pelo qual o Spring foi criado: ser uma opção muito mais rápida, barata e leve de um lightweight container que ofereça serviços plugáveis de infraestrutura para soluções corporativas com a mesma qualidade.

Hoje a minha dica é sobre os principais livros de Spring atualizados para os interessados em se aprofundar nessa poderosa plataforma:

51nY36Dqo5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Spring in Action  é o livro mais básico que te ensina os pilares do uso de serviços no Spring. Nele você também aprendera os serviços e recursos mais básicos que ele proporciona.

415x7PWAe5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Just Spring Integration  é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para integração de soluções definidos pelo catalogo de patterns de integração conhecidos pelo EAI.

51RXnaly93L

Spring Data é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para persistência de dados relacionados com banco de dados relacionais e NoSQL.

Existem outros livros mais específicos de outros serviços que você também pode estar estudando como, por exemplo, Spring Bath in Action e Pro Spring Security

Uma vez que você domine todos estes serviços, você praticamente se tornara um “Arquiteto Java Spring”, dominando contextos de soluções mais modernos da atualidade e apto para projetar soluções corporativas de pequeno, médio e grande porte.

“Não retarda o Senhor a sua promessa, como alguns a julgam demorada; pelo contrário, ele é longânimo para convosco, não querendo que nenhum pereça, senão que todos cheguem ao arrependimento.” 2 Pedro 3:9

Como se tornar um arquiteto de software?

arquitetoVeja nessa palestra de 15 minutos de Kleber Xavier falando a respeito de como nasce, o que faz e como se tornar um arquiteto de software. A palestra confirma 100% o que nos da FOR-J temos ministrados na nossa grade de treinamentos para arquitetos:

Arquiteto de Software

AQT M1  Arquiteto Java – Planejamento Estratégico: Objetivo deste curso é introduzir o participante ao cenário atual das complexidades tecnológicas encontradas na produção de soluções corporativas, abordando de forma conceitual as atividades básicas desempenhadas por um arquiteto de software. O curso aborda as mudanças arquiteturais ocorridas nas ultimas décadas, cruzando com as tecnologias oferecidas pela plataforma Java, atividades básicas de um arquiteto de soluções e diversas estratégias de resolução de requisitos não funcionais.… + informações 

AQT M2  Arquiteto Java – Projeto e Design: Objetivo desse curso é oferecer aos participantes conhecimentos práticos relacionados à criação e design arquitetural da verdadeira essência orientada a objetos utilizando a plataforma Java. O curso aborda desenvolvimento guiado por testes conhecido por Test-Driven Design TDD e o desenvolvimento orientado a domínio conhecido por Domain Driven Design – DDD. O curso é finalizado com um estudo de caso completo.… + informações

“Amai-vos cordialmente uns aos outros com amor fraternal, preferindo-vos em honra uns aos outros.” Romanos 12:10

Programação – Item 55

Online_video_marketing_optimize_conversion_rates_tips_id35618561Otimize Criteriosamente

A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de gerador de perfil e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.

Para todas as informações, veja o post inicial.

“Tudo quanto, pois, quereis que os homens vos façam, assim fazei-o vós também a eles; porque esta é a Lei e os Profetas.” Mateus 7:12

Arquiteto de Software X Humildade

4_WorkHardA humildade não é uma característica muito comum nos profissionais arquitetos de software. Depois de ter trabalhado com alguns arquitetos terríveis e, recentemente, com um muito agradável,  Johannes Brodwall compilou algumas de suas experiências e compartilhou neste post Humble Architects.  Leitura obrigatória para os arquitetos de plantão.

“Diz ao SENHOR: Meu refúgio e meu baluarte, Deus meu, em quem confio.” Salmos 91:2

O primeiro RWD agente nunca esquece

20130814_163922

2013 é ano da Responsividade! Venho hoje compartilhar o nosso primeiro RWD - www.uniprimebr.com.br.

“porque todo o que é nascido de Deus vence o mundo; e esta é a vitória que vence o mundo: a nossa fé.” 1 João 5:4

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

100_qualityEm uma das empresas que eu atuo como consultor, eu acabei construindo uma classificação que define a 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. TDDo 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 ou gestores 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

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

Arquitetura da Soluções Web Mobile MVC

images“Pode-se criar uma interface rica para aplicações de forma nativa ou utilizando HTML5 e JavaScript. Aplicações nativas podem oferecer uma experiência mais rica para os usuários, mas podem levar mais tempo e ser mais caras de desenvolver para vários sistemas operacionais. As tecnologias HTML5 e JavaScript abrirão a porta para as interfaces independentes de dispositivo. Isso significa que as interfaces com o usuário podem ser criadas utilizando bibliotecas de componentes JavaScript que renderizam componentes visuais utilizando elementos do HTML5. O HTML5 traz novas funcionalidades que suportam a mobilidade e o desenvolvimento de interfaces ricas.

Este artigo apresenta frameworks e estruturas usadas para implementar o lado cliente das aplicações móveis com base em JavaScript e HTML5. A interface com o usuário e os elementos de navegação são todos componentes renderizados no navegador, enquanto os servidores de aplicações têm somente o papel de fornecer acesso aos dados JSON para a interface com o usuário. Como a intenção aqui é fornecer uma arquitetura de referência, o exemplo implementa apenas algumas funcionalidades básicas.Muitas abordagens para desenvolver aplicações para navegadores desktop podem ser utilizadas nas aplicações baseadas em navegadores móveis. No entanto, as aplicações móveis apresentam desafios não existentes nos navegadores para desktop.”

Veja o artigo completo no site da InfoQ.

“Filho meu, não te esqueças dos meus ensinos, e o teu coração guarde os meus mandamentos; porque eles aumentarão os teus dias e te acrescentarão anos de vida e paz.” Provérbios 3:1-2

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 653 outros seguidores