Post número 200 :D

Esse é meu post número 200 aqui no blog...

isso é bom? não sei... mas é legal olhar pra trás e ver o quanto de coisa diferente que já fiz nesses quase 7 anos de blog... mas mais legal ainda é de tempos em tempos ler um comentário do tipo "Vaaaaleu cara! Tava o dia inteiro apanhando nesse bug, e teu post me salvou!"

Esse não é um blog "comercial" onde posto coisas querendo milhões de visualizações... simplesmente vou postando como resolvi alguns problemas que passei... e de vez em quando isso é útil para outras pessoas também... muitas vezes é útil pra mim, pra eu lembrar como fiz resolvi determinado problema hahah

Com certeza esse não é o melhor de todos os blogs... mas acredito que é o blog com o nome mais legal :D

S2 localhost8080.com.br S2

E bóra para mais 200 posts \o)

Abraço!
Adriano Schmidt

Uma martelada

Oi :)

Ouvir seu cliente falando "obrigado, agora eu durmo tranquilo" não tem preço :D





Quando eu era pequeno ouvia uma história do cara que cobrou 10 mil reais e ficou um mês consertando um navio.... mas não resolveu o problema!


Depois veio outro cara e cobrou 100 mil pra ficar uma semana mas também não consertou o navio!


Por fim veio um cara e resolveu o problema com uma martelada e cobrou 1 milhão... logo reclamaram:

Como 1 milhão por uma martelada? O outro ficou um mês e cobrou 10 mil

E a resposta foi

Cobro 1 real pela martelada e 999.999 por saber onde dar a martelada

Quando o cliente me falou "cara, a gnt não ia achar o problema, estávamos culpando tudo menos isso" eu lembrei dessa história...

a diferença é que não cobrei 1 milhão hahahah

#consultoria #homeoffice

Tunning de aplicações Java

Pessoal.. vou postar aqui alguns itens que sempre recomendo para melhorar o desempenho de uma aplicação Java.

Fazer testes de desempenho ou analisar as aplicações com JMeter, NewRelic, VisualVM, jConsole é o mundo ideal! Através disso é possível identificar os gargalos da aplicação! Os pontos que mais utilizam recursos computacionais como memória e processador por exemplo.

Configurar adequadamente a memória utilizada.. ou seja, estude xms, xmx, maxpermgen..
Uma dica é sempre colocar o xms e o xmx igual em ambiente de produção. E o ideal não é simplesmente colocar o valor mais alto possível, é preciso analisar qual é o valor ideal, e isso é descoberto através de testes e monitoramento, ou através do feeling e analisando com o tempo como a aplicação se comporta.

Recomendo utilizar a JRockit como JVM. Ela é mantida pela Oracle também e tem um gerenciamento de memória muito melhor que das outras JVMs, o garbage collector funciona bem melhor.
Mas só tem pra Java 6, mas em todos os clientes que atuo, sempre que possível, implanto a JRockit, é notável o ganho obtido no uso de recursos computacionais como memória.

Dá pra fazer tunning também de acordo com a tecnologia que você está usando.. JSF... JMS... pool de EJB... Banco de dados...

Dá pra monitorar a aplicação pelo jenkins também, fazer um job que checa a memória e qualquer avisa a equipe de infra ou até reinicia, dá pra usar o nagios...

Etc... Existem milhões de outras coisas que podem ser feitas, mas como escrevi esse texto para ajudar um amigo, resolvi postá-lo aqui para talvez ajudar outras pessoas também.

Abraços!
Adriano Schmidt

Cuidados ao entrar num projeto novo

Pessoal... queria dar algumas dicas para quando você for entrar um projeto novo...

1) Ctrl+Shift+F
Nunca dê um Ctrl+Shift+F no projeto inteiro.. nem na classe que você está alterando...

Um Ctrl+Shift+F atrapalha muito a realização de merges e de certa forma faz você perder o histórico de alterações no controle de versão, pois vai ser difícil comparar algo com uma versão antiga pois vai estar com uma formatação toda diferente.

Se você está criando uma classe nova, tudo bem, mas muito cuidado ao mexer em códigos já existentes.

Caso você crie um método novo, você pode selecionar esse método, e dar um Ctrl+Shif+F, pois vai formatar apenar o trecho de código selecionado, mantendo intacto o resto da classe.

Tem até como criar um xml de formatação no eclipse e depois as outras pessoas podem importar em seus eclipses, mas acho muito trabalhoso manter isso.

Caso seja decidido aplicar algo no projeto inteiro, isso deve ser bem pensado, nunca é só chegar e fazer.

2) Encoding no eclipse
Antes de salvar uma classe verifique se o encoding do projeto no seu eclipse está correto, veja se os acentos não vão virar caracteres estranhos..
Isso é muito comum quando uma equipe usa windows e entra alguém que usa linux ou vice-versa.
Para mudar o encoding do seu projeto no eclipse é só ir nas propriedades do projeto no eclipse.

Caso você ache que o encoding poderia ser outro, converse com a equipe, nunca chegue e mude por conta própria.

3) Encoding no maven
Nunca altere o encoding do projeto no maven colocando no pom a linha abaixo:
UTF-8

Se for fazer isso converse com alguém que já está no projeto ou então você deve saber o que está fazendo.. uma dica é, se for fazer, faça apenas local.

4) Não use acentos em comentários
O título é auto explicativo, a ideia é simples, se não tem acentos, diminui a probabilidade de problemas com encoding. Ah, e sempre é bom falar, em nome de variável também não se deve usar ç ou coisas assim.

Essas simples ações tornam o ambiente de trabalho melhor, faça o bem sem olhar a quem! :D

PS: Escrevi tudo isso e mandei para todos os desenvolvedores da empresa que trabalho depois de passar muitas horas (muitas mesmo) fazendo um merge de um projeto gigante e corrigindo caracteres especiais. Então, não falo por mal, falo para evitar que outras pessoas passem por esse sofrimento.

Abraços!
Adriano Schmidt

"A melhor tecnologia é a que eu domino!"

Hoje venho divagar sobre a questão: "Devo usar a tecnologia que domino mais ou o a mais adequada ao projeto?"

Essa é uma decisão difícil e alguns fatores devem ser considerados.

Cada tecnologia tem suas vantagens e desvantagens..
JSF tem as suas.. Flex tem as suas.. HTML5 tem as suas.. PHP tem as suas..
Cada tecnologia tem situações em que ela se encaixa melhor..

Muitas empresas decidem usar tecnologias com base na experiência dos desenvolvedores, é uma decisão comum e muitas vezes assertiva... mas algumas vezes isso não se conjectura como melhor escolha e é necessário tomar outra decisão...

Uma grande empresa que trabalhei desenvolveu muitos sistemas em Flex.. e agora está reescrevendo tudo... (Não quero julgar esse caso em específico, só estou dando um exemplo).

Nesta mesma empresa iríamos desenvolver um sistema de ponto eletrônico e controle de acesso (catracas)... na época estava surgindo o JSF2.. todo mundo falou pra usar o JSF 1.2 até porque haviam outros sistemas em JSF 1.2 na equipe.. eu contrariei o que as pessoas falaram e desenvolvi em JSF 2... recebi muitas críticas por isso, mas permaneci firme porque sabia que era o mais acertado.. esses outros sistemas já existentes usavam Spring e eu coloquei EJB/JPA no projeto mesmo que ninguém na equipe conhecia isso... Usei JBoss ao invés de Tomcat... Enfim, a arquitetura mudou bastante em relação aos projetos existentes.
Seis meses depois.. todos os sistemas desenvolvidos em JSF 1.2 e Spring foram reescritos em JSF 2 e EJB...

Em outra empresa, entrei em um cliente e começamos a usar o Git ao invés de SVN.. fui muito criticado por causa disso pelos desenvolvedores que apenas conheciam SVN... e hoje está mais que provado que foi a melhor escolha...

Em um projeto novo que está começando agora e estou envolvido surgiu a discussão HTML5xJSF... Queriam utilizar JSF pois a equipe atual domina mais esta tecnologia.. Caso seja escolhido HTML5 muita gente vai criticar, no primeiro problema que alguém tiver vai reclamar e vai falar "Se fosse JSF já estaria pronto", porém, com JSF também teríamos problemas..

Entendo que no início a produtividade seja mais baixa com HTML5, porém em pouco tempo isto mudará.

Neste projeto em específico acredito que não devemos usar JSF só por que conhecemos mais, não seria a melhor escolha para esse projeto pois JSF foi criado para sistemas corporativos.. enterprise... Para um número não muito grande de usuários simultâneos. Que não é o cenário do novo projeto.

Claro que outros fatores como prazo, orçamento, se os envolvidos querem pensar a curto ou longo prazo, abertura a assumir riscos, entre outros, vão influenciar na escolha também, mas escolher a tecnologia mais adequada deve pelo menos entrar nas discussões.

Enfim, a frase "A melhor tecnologia é a que eu domino" é muito comum, porém, nem sempre funciona.

JBoss x Tomcat

Por que usar JBoss ao invés de Tomcat?

Primeiramente é bom explicar que o Tomcat é um Web Container (contém engines para Servlet e JSP), já o JBoss é um Application Server (container para a plataforma JEE, contém um Web Container, porém tem um EJB container e outras engines).

Para aplicações simples você consegue utilizar um Web Container, para aplicações com mais tecnologias (EJB por exemplo), você até consegue usar um Web Container, porém, terá que adicionar muitas bibliotecas e configurações nele. Em um Application Server tudo é nativo.

Em 2010 por exemplo, fazia muito sentido utilizar apenas um Web Container para uma aplicação simples pois os Application Servers eram muito pesados, consumiam muitos recursos computacionais, demoravam para iniciar e eram difíceis de manter, porém os Application Servers em 2014 não tem mais estes problemas. A própria Apache, criadora do Tomcat, criou seu próprio Application Server chamado TomEE para ser usado no lugar do Tomcat. (http://tomee.apache.org/apache-tomee.html)

Os Application Servers trabalham com profiles, que define o que será carregado, o profile mais leve dos Application Servers é como um Web Container, por isso, não existe mais a necessidade de se trabalhar com Tomcat em projetos novos, a não ser que você queira manter padrão com outras aplicações da empresa ou algo assim, porém, essa decisão traria muitas outras dificuldades para o desenvolvimento e controle da infraestrutura de uma aplicação JEE.

Abraços!
Adriano Schmidt

Caixa de ferramentas do arquiteto Java

Gosto de uma definição antiga que pode ser usada até hoje:



Eu tenho trabalhado como consultor em muitos clientes e tenho que tomar diversas decisões arquiteturais sobre tecnologias e ferramentas e também sobre ALM (Application Lifecycle Management). Estou fazendo este post para falar de algumas ferramentas que temos à nossa disposição e que devemos conhecer.

Vale lembrar que a escolha das tecnologias e ferramentas sempre depende de inúmeras variáveis, é necessário entender a aplicação, requisitos, objetivos e limitações para tomar a melhor decisão.

E ferramentas, na verdade, são úteis apenas com a definição de técnicas e de processos de forma adequada.

Enfim, vamos lá! Separei algumas ferramentas por tópicos:

Análise de requisitos, arquitetura e design

O mais importante na análise de requisitos são as técnicas utilizadas, conseguir obter o máximo de informações e detalhá-las conforme necessidade.

Uma ferramenta bem robusta é o Enterprise Architect (EA), porém, gasta-se muito tempo para trabalhar com esta ferramenta.

Existe a possibilidade de trabalhar com arquivos de texto como o Word, porém, não são documentos vivos, uma ideia interessante é utilizar uma ferramenta de wiki, como o xwiki por exemplo. O Confluence da Atlassian é muito bom também para documentação e compartilhamento de conhecimentos.

É interessante o uso de ferramentas para criação de fluxos e diagramas como o Astah (antigo Jude) e o Bizagi.

Para criação de protótipos eu sempre utilizo o Balsamiq Mockups, ele é fantástico! Existem outras opções como o Axure, que é um mais robusto, mas o Balsamiq é mais simples e atente em quase todas as situações.

Gerenciamento de Projetos

O MS Project é ótimo para gerar e organizar cronogramas.

O Jira (ou RedMine, que é basicamente uma versão free do Jira) é muito bom para gerenciar as atividades de um projeto. Você cadastra um projeto, coloca as atividades e o número de horas, delega para os responsáveis, e tem um visão bem clara de tudo que está acontecendo. Estas ferramentas também servem para registrar bugs, é possível visualizar quantos erros aconteceram, de qual tipo, tem diversos gráficos e formas de visualização. Você também pode criar um workflow com todos os passos e responsáveis para cada atividade. Caso você vá usar RedMine, sugiro a instalação do plugin Monitoramento e Controle para melhor visualização das atividades.

Se você for trabalhar com Agile o GreenHopper é uma ótima opção. O Trello é um software de kanban muito eficiente em que você pode organizar seus projetos, atribuir responsáveis, entre outras funcionalidades.

Se você precisa de um produto que seja integrado com a folha de pagamento, que gera relatórios para enviar aos clientes, você pode procurar sistemas próprios para isso, porém, talvez exista a necessidade de customização.

Criação de código (IDE)

Sou adepto da ideia que cada desenvolvedor deve ser livre para escolher sua IDE.

Eu sempre trabalho com o Eclipse, ou com o JBoss Developer Studio (que é o Eclipse com diversos plugins da JBoss), mas caso o desenvolvedor queira usar NetBeans, ou alguma outra IDE (IntelliJ IDEA por exemplo), ou até mesmo um editor de textos qualquer ele deve poder! Para isso deve ser utilizado o Maven, que, entre outras coisas, organiza o projeto para que ele possa ser utilizado com qualquer IDE, ou sem nenhuma.

Repositório de fontes

Há muito tempo era utilizado o CVS, porém, com o surgimento do SVN ele não é mais recomendado.

O SVN é simples de usar e muito eficiente e eficaz.

Caso você tenha uma equipe entusiasta por tecnologia e que abrace a ideia, é uma excelente ideia utilizar o GIT. Ele é mais complexo e mais difícil de aprender, no entanto, traz inúmeras vantagens.

Outra opção é o TFS para versionamento de fontes, mas acredito que ele é extremamente eficiente para projetos com tecnologias Microsoft, mas não para projetos Java, mesmo as versões mais novas do TFS.

Existe ainda o Mercurial, este eu não conheço muito, não conheço muitas empresas que o utilizam.

Existem diversos padrões, utilizados mundialmente, para versionamentos, criação de tags e branches, é de extrema importância definir este processo.

Build automation e Integração contínua

Recomendo a utilização do Jenkins, nele você pode rodar compilação automática, rodar scripts de testes, de validação de código e atualizar ambientes.

O Jenkins é free e opensource, ele sempre me atendeu 100%. Outra opção é o Bamboo, da Atlassian.

Qualidade

Para garantir a qualidade, além dos testes manuais (abrir a tela e verificar se está funcionando) existem outras formas de manter a qualidade como validação de fontes, testes unitários e testes de interface.

Estes testes e validações podem ser rodados automaticamente na integração contínua através do Maven, dessa forma você pode verificar a cada commit se algum teste parou de funcionar ou se alguma política de validação de fonte foi desreipeitada. Caso isso ocorra é enviado um e-mail para quem fez o commit e para os responsáveis pelo projeto.

Para validação de fontes recomendo a utilização de PMD e Checkstyle. Essas ferramentas verificam vários problemas no código. Existem plugins para o eclipse para utilização destas ferramentas. E elas também são rodadas via Maven (ou seja, independem de IDE). Para uma melhor visualização de tudo isso deve ser utilizado o Sonar, que oferece uma tela web para visualização de todos os problemas de código.

Para testes unitários o Arquillian é excelente! É interessante utilizar uma ferramenta que verifica quantas e quais linhas do seu fonte estão sendo cobertas pelos testes, para isso pode ser utilizado o Sonar ou o EclEmma ou o Atlassian Clover ou ainda alguma outra ferramenta.

Se o sistema for SAAS (ou se tiver uma grande preocupação com performance), é importante também escrever testes de desempenho utilizando ferramentas como JMeter, NewRelic, VisualVM, jConsole, entre outras.

Para testes de interface eu já utilizei o Visual Studio para projetos Java Web, achei muito bom, porém, a licença é cara. Quem conhece Java não terá dificuldade para trabalhar com ele, é utilizado C# para escrever os testes de tela. Uma opção free e bem semelhante às ferramentas de teste da Microsoft é o Selenium.

O ideal é estabelecer um processo de desenvolvimento onde sempre se escrevem testes automatizados e uma política de PMD e Checkstyle. Então para liberar uma versão, todos os testes automatizados devem rodar sem erros e a política estabelecida de PMD e Checkstyle deve ser atendida. Com certeza também é importante sempre fazer testes manuais, os próprios desenvolvedores podem testar o que outros desenvolvedores testaram, ou pode ser criada uma equipe de qualidade ou definir uma pessoa para ser tester.

Criação de Help On-line

Com um código bem documentado, é bacana a geração e publicação do JavaDoc. Através das ferramentas de validação de código é possível verificar se os códigos estão ou não documentados.

Mas é possível criar um help on-line de outras formas também, o xwiki é uma opção bacana!

Para a criação de help por página sistema de forma automática talvez exista alguma ferramenta para isso. É possível criar um mecanismo de links, tive que fazer isso em um produto e criei eu mesmo uma estrutura de documentação seguindo alguns padrões que eu defini.

I18n

Pode-se utilizar arquivos de textos, que é a opção mais simples. Porém, já trabelhei salvando as traduções em um banco de dados, é possível trabalhar com cache para melhorar a performance e fica muito bom também. Existem outras estratégias para corrigir problemas de performance com traduções.

Existe ainda a possibilidade de trabalhar com as traduções na Cloud, com a ferramenta transifex por exemplo.

Existem diversos padrões para serem seguidos com relação a tradução, para evitar problemas de formatos de campos, documentos, entre outras coisas.

Conclusão

Primeiro temos que definir ideias, definir o que queremos e o que é preciso de verdade. Após isso deve-se pensar em ferramentas para atender as necessidades.

Temos à nossa disposição inúmeras ferramentas, mas temos que entender melhor cada situação para utilizarmos as ferramentas adequadas.

Um grande abraço!
Adriano Schmidt