abr 11 2012

Se o servidor é seu, porque o problema é meu?

Category: Off-Topic,Servidores JavaEdson Gonçalves @ 15:43

Quero começar este ano, em meu blog, falando um pouco sobre administração em aplicativos e servidores Java, que serve também no geral para outros serviços.
Desde que assumi a gerência da Integrator na parte de hospedagem, vejo e-mails que são direcionados ao suporte e recebo também, muitos pedidos que, sinceramente, não deveriam vir de um desenvolvedor Java.

A critica que faço aqui é construtiva e, de certa forma, um puxão de orelha, para que os profissionais que trabalham com desenvolvimento, comecem a se preocupar mais com o que criaram e assumam o problema.

Criei meu aplicativo e agora?

Tudo começa com a sua criação. Você, profissional desenvolvedor, recebeu a árdua tarefa de criar aquele sistema “maravilhoso“ que alguém idealizou ou, por motivos pessoais, quis aprender algo ou desenvolver o sistema de seus sonhos.

Depois de muita luta, você desenvolveu e foi aprovado por seu cliente, a diretoria da empresa onde trabalha ou por você.

Mas e agora? Como executar isto fora de minha máquina de desenvolvimento?

Do desenvolvimento até a produção

Muitos desenvolvedores se acostumaram com a automação das ferramentas de desenvolvimento e, claro, com tanta facilidade, parar e iniciar o serviço Java ali é simples.  Entretanto, o desenvolvedor java não pode apenas saber como operar uma ferramenta de desenvolvimento.

O profissional de Java precisa, na realidade necessita, conhecer o servidor Java que executa seus aplicativos. Não é apenas o básico de instalar, configurar, iniciar e parar. Também não vale dizer que sabe ler logs. Vai além. O profissional Java precisa saber como o servidor Java, que escolheu usar, opera.  Isso vai desde as suas características básicas de configuração, até como ele pode ser modificado e otimizado para melhorar o desempenho do que desenvolveu.

Está bem, você vai dizer que não quer ser administrador, mas sim é um desenvolvedor, certo? Errado! Isto é comum no governo, onde um carimba e outro coloca a folha. Se olhar para fora, verá que muitos fazem várias tarefas diferentes. E no seu caso, o servidor Java é a extensão do seu aplicativo.

O aplicativo precisa funcionar em qualquer lugar

Se você é o desenvolvedor, logo, é importante saber como fazer para que o seu aplicativo funcione em qualquer lugar, não somente em sua máquina. Usar o framework XYZ não é a etapa final do que criou. É no momento que ele vai para produção, que é onde aparecerão os problemas.

O que mais vejo e escuto é a frase: na minha máquina funciona. Ora, se você desenvolve corretamente, sem nenhum problema oculto, nada personalizado especificamente para sua máquina, que causaria erros online, também funciona em qualquer lugar.

Estes são os problemas mais comuns  do desenvolvimento para a produção são:

1)    Nome do banco de dados – criar a conexão usando um nome local, onde na produção se modifica, bate o recorde em erros de acesso pelo usuário;

2)    Nome do usuário do banco de dados – segundo problema mais comum, o usuário é diferente e gera erro de acesso negado;

3)    Permissões de acesso em arquivos – o terceiro mais comum, quem usa o Windows está muito acostumado a ter permissão para tudo. Mas online, servidores seguros tem permissões para escrita e execução, que precisam ser dadas em arquivos e diretórios;

4)    Erro no local onde está o banco de dados – conhecer a regra de como acessar o banco de dados no servidor de produção é o mínimo, vai desde do host até a porta. Não sair colocando o que “acha” ser o correto. Na dúvida, sempre perguntar a quem administra o sistema operacional para evitar erros e mudar, principalmente, no código que foi compilado para colocar em produção;

5)    Problemas de memória – usar o framework XYZ porque ele foi indicado na comunidade como bacana é ótimo. Mas saber o que ele consome de sua máquina é melhor ainda. Não adianta achar que sabe como usar o Tomcat, que localmente tudo funciona, que online não vai dar problemas, se você nem sabe localmente o quanto o Tomcat necessita de memória para executar seu aplicativo. Máquina de desenvolvimento possuem vários GIGAS de memória RAM e muitas vezes o desenvolvedor nem se preocupou em limitar o serviço em um X de memória. Online, você terá configurado uma limitação no servidor Java. É importante saber se, dentro desta limitação, seu aplicativo executa com conforto;

6)    Envio de email – O SMTP tem regras em qualquer lugar. Saber a porta correta, parâmetros básicos mínimos necessários é importante para que, em produção, o envio seja feito sem erros.

7)    Erro 404 – O deploy não funcionou, logo, tem algo de errado e precisa ver nos logs o que está ocorrendo;

8)    Bibliotecas – As bibliotecas que usa no desenvolvimento precisam estar em produção. Se exportou o WAR file, EAR file, e nenhum está com as bibliotecas, ou falta alguma, porque foram colocadas diretamente no servidor Java, precisa fazer o mesmo em produção. Algumas bibliotecas também costumam dar problema quando existem duas do mesmo tipo, mas com versões diferentes.

9)    Localização – Não deveria estar nesta lista, mas infelizmente, é um erro também comum. É possível configurar o Locale em seu aplicativo ou diretamente no servidor Java. Não é porque na sua máquina o Locale é em pt-br que online vai ser também. Saber modificar isso no servidor Java que seja, não é difícil e lhe salva de dores de cabeça com uma configuração muito simples.

10)  Erro na descompactação do arquivo WAR – Probleminha comum quando você sobe por FTP o aplicativo com o Tomcat ligado, por exemplo, causando um hot deploy sem o arquivo ter finalizado totalmente o seu envio. Alternativamente, ocorreu alguma queda de pacote no envio e ocorreu uma falha, deixando o  arquivo impossibilitado de ser operado e, consequentemente, o servidor Java lançará um erro na descompactação.

11) Assumir o problema – É, eu sei, isto não se trata de erro de produção. Mas pensar é um ato importante para resolver problemas. Sair culpando outro, sendo que o problema é seu, não faz parte do meio que escolheu como profissão. Se assumiu um cargo como desenvolvedor, assuma também que o que fizer, desenvolver, pode ter falhas e que elas são corrigíveis. Assumir o problema é o primeiro passo em direção da solução.

 

Os logs são a chave para a solução dos problemas

Todos os problemas, que relatei acima, sempre lançam exceções. Claro que, muitas vezes, o desenvolvedor sai reclamando antes de pensar, que é sua maior tarefa, do porque essas exceções estão sendo lançadas. A grande vantagem do java é que ele aponta o dedo para o problema. E de tantos que usam no mundo, é muito fácil descobrir uma resposta para o problema. Mas fica mais difícil se quiser que resolvam o SEU problema para você, acredite.

 

Indo além dos servidores Java

Em produção, não basta apenas saber como operar um servidor Java. Você desenvolveu o aplicativo e, como conhecedor do que fez, deve também saber que o seu uso pode crescer. Mas, muitas vezes, se esqueceu de que o comportamento com 10 pessoas testando é um e com centenas online, é outro.

Um belo dia, seu servidor Java caiu, se não caiu, deu um erro estranho em seu aplicativo ou aconteceu algo que não havia previsto, claro.  Mas a culpa não é sua, certo? Funcionava antes e não mexi em nada. Errado! Totalmente sua culpa. Só de dar a resposta de que não mexeu em nada já implica que não está cuidando do que fez. Se não observar por um tempo o que desenvolveu, a evolução do que fez, não vai ter correções e, como consequência, erros. Saiba estes princípios básicos no desenvolvimento:

1)    Bibliotecas e frameworks mudam – se mudam de versão, é porque a anterior não era perfeita. Erros são reportados e precisam ser atualizados para evitar que no seu, uma hora ocorra o que outro já teve.

2)    Servidores Java mudam – mesma situação que citei acima, se mudou a versão do servidor Java, pode ser que, algum possível bug pode causar problemas em seu aplicativo.

3)    Profiler – Usar um profiler vai lhe orientar como seu aplicativo se comporta e ver possíveis picos de memória/CPU que possam lhe causar problemas, mais adiante, com muitos usuários acessando.

Atacando o problema de frente

Evidentemente muitas são as situações que ocorrem em aplicativos. Nem todos os problemas são simples de serem solucionados. Mas alguns podem ser de simples resolução se, de fato, você realmente quiser resolver a situação. Vale citar alguns:

1)    Otimize o banco de dados – Conhecer queries lindas com subqueries é muito bom. Mas saber o que elas causam, ao serem chamadas em bancos de dados, com muitos dados, é melhor ainda. Otimizar queries é importante para melhorar o desempenho.  Claro que, em meio a isto, entram também saber otimizar a estrutura das tabelas, criar índices corretos e até mesmo criar caches de queries de pesquisas, as mais comuns, para melhorar o seu desempenho no acesso ao aplicativo.

2)    Modificar o comportamento falho do aplicativo – Sim, sei que você não quer mexer no que estava funcionando bem nos primeiros 10.000 registros/acessos. Mas agora não está mais. Muita gente acessando, muitos erros sendo lançados, memória, velocidade. Precisa modificar o comportamento, voltar para a “prancheta” do desenvolvimento e replanejar. Se não fizer isto, seu projeto vai falhar, mais dia ou menos dia.

3)    Mude de servidor Java – Sei que você aprendeu agora, e muito bem, aquele servidor chamado Apache Tomcat. Mas ele pode não estar dando conta do recado como outro daria. É hora de conhecer novos servidores Java e testar, seja o Jetty, JBoss ou GlassFish. Algumas pequenas mudanças, como a troca de servidor Java, podem trazer benefícios ao que desenvolveu, mesmo que isto lhe traga de volta ao “be a bá” de como tudo funciona.

4)    Buscar alternativas – Sempre , em algum lugar deste planeta imenso do desenvolvimento, alguém arrumou alguma solução que  fez melhorar o desempenho do aplicativo com aquela tecnologia XYZ que escolheu e deu a dica. Busque alternativas e dicas.

 

Empurrão ou puxão de orelha?

Minha intenção é dar a vocês, leitores deste blog, um empurrão no sentido certo. Existem várias etapas no desenvolvimento e todas envolvem o que criou. Vai desde o sistema operacional que irá trabalhar em produção, até o que é acessado pelo seu aplicativo.  Estes detalhes precisam ser todos analisados, mesmo que você diga que é apenas um mero desenvolvedor Java.

Tags: , , ,


set 22 2011

O que estou fazendo no momento

Category: Off-TopicEdson Gonçalves @ 21:46

Olá Pessoal, tudo bom? Como vão vocês?

Sei que estou sumido do blog. Muitos leitores estão, nestes meses, me mandando comentários pedindo  a continuação de alguns artigos, de séries, que comecei e ainda não terminei. Quero informar a todos que, neste momento, estou renovando meus livros, por isso parei um pouco de postar no blog.

Muitas pessoas já sabem, outras nem fazem muita ideia, mas escrever toma muito tempo. Quem possui pouco tempo livre, como eu, no caso, é deixar os finais de semana com a família e  o descanso das noites, para nos dedicar a escrita.

Os escritores que sempre apoio em meu blog, até mesmo outros que desejarem aparecer no mural, só entrar em contato comigo. Sei o quanto é difícil divulgar um livro e ter um pouco de reconhecimento. Muita gente acha que ganhamos dinheiro com livros, que ficamos ricos, mas estou aqui para desmentir. Na área de informática, quem escreve é para ter o prazer de ajudar aqueles que estão com as mesmas dificuldades que, com certeza, passamos um dia.

Quero deixar aqui os meus sinceros agradecimentos a todos aqueles que postam comentários elogiando, criticando e pedindo mais tutoriais no blog. Para aqueles que não liberei os comentários, fiquem tranquilos que eu os li. Só não os liberei, muitas vezes, porque não tive tempo ou, por serem pedidos e perguntas relacionadas diretamente a mim, sobre o assunto, não me permiti o tempo necessário para responde-los.

Assim que terminar o meu primeiro objetivo, que é a completa reformulação e atualização, do livro “Desenvolvendo Aplicações Web com JSP, SERVLETS, JAVASERVER FACES, HIBERNATE, EJB 3 PERSISTENCE E AJAX”, voltarei a postar os diversos tutoriais, que já os tenho quase prontos, no blog.

Deixo aqui o espaço aberto, neste tópico, para que comentem o que acham interessante de estar neste livro que estou trabalhando. Já garanto que muitas criticas e pedidos, vindos de algumas centenas de leitores, não serão ignorados. Professores de universidades, faculdades e escolas técnicas do Brasil e alguns países de língua portuguesa, que também me procuraram para deixar seus pedidos e criticas, quero manter meu compromisso de que todos serão levados em consideração.

Agradeço a compreensão de todos.

Bons códigos!

Tags: , , , , , , , , , , , , ,


ago 05 2011

Novo Livro do Camilo Lopes

Category: Off-TopicEdson Gonçalves @ 2:01

Pessoal,

 

Sei que estou sumido do meu blog e prometo que estou preparando surpresas. Mas isto não significa que eu deixaria de prestigiar o lançamento do novo livro do Camilo Lopes.

Novo Livro do Camilo Lopes

 

 

 

Sem mais delongas, vejam o que ele fala a respeito em seu blog:

http://blog.camilolopes.com.br/livrojeeframeworks/

 


jan 28 2011

Gerando relatórios JasperReports na Web com Fontes embebidas

Category: iReport,JasperReportsEdson Gonçalves @ 5:43

Olá Pessoal, tudo bom? Como vão vocês?

Em 2011 quero começar com um artigo ensinando uma dúvida muito frequente aos usuários de hospedagem da Integrator Host: embeber as fontes desktop no relatório JasperReports para serem usadas no aplicativo Web.

No geral, relatórios são criados no desktop, onde usamos uma ferramenta visual, arrastando,  modificando e, claro, gerando uma aparência agradável. Se a aparência então for feita por um Designer, este pouco se importa onde vai ser gerado tal relatório, o importante é o VISUAL. É neste momento que começa o problema.

Um relatório pode usar fontes desktop que não estão disponíveis no servidor online. Pior, se o seu aplicativo roda em um servidor compartilhado, raramente uma empresa de hospedagem vai ficar instalando suas fontes desktop na máquina servidora, toda vez que você estiver com um relatório “enfeitadinho”. Se instalar, também não será na hora. O que fazer neste caso então? Como obter independência?

Pensando nesta questão, a equipe de desenvolvimento do JasperReports incluiu a capacidade de adicionar as fontes desktop em seu aplicativo, para que estejam disponíveis quando aquele seu belo relatório for gerado para o cliente.

O que veremos neste artigo é como executar tal tarefa, partindo de um relatório já gerado no iReport.

Para acompanhar este artigo

Criei um banco de dados simples, com uma tabela chamada produtos, contendo os campos selecionados como mostra a Figura 1.

Figura 1 – A tabela usada

O relatório foi criado usando o assistente do iReport 4, onde o resultado final, após minhas pequenas alterações, é o que mostra a Figura 2.

Figura 2 – Relatório gerado pelo assistente com pequenas modificações

Tenham em mente que este artigo não vai ensiná-los a criar relatórios e sim como contornar um problema comum entre os desenvolvedores Java. Caso queiram dominar a arte de desenvolver relatórios JasperReports com o iReport, vejam a minha seção de livros clicando aqui.

Trabalhando com fontes personalizadas no relatório

Após desenhar o relatório, chega o momento de finalizar a “arte” com alguns toques e, em meio as mudanças, eis que surge a ideia de personalizar a fonte também do texto contido no relatório.

No exemplo que fiz, os textos fixos foram todos personalizados com uma fonte que possuo em minha máquina, chamada Impact.

Figura 3 – A fonte escolhida para o texto estático Produtos do relatório

Embora esta fonte seja importante para o design do meu relatório, não tenho garantias que ela exista no servidor onde hospedo meus aplicativos.  Logo, o que parece simples, pode se tornar um pesadelo se não for eu o responsável pela administração do sistema operacional.

Adicionando a fonte ao aplicativo

Graças ao problema de ausência de fontes em servidores de hospedagem, muitos desenvolvedores não podiam depender da empresa ou administrador que fornece a máquina onde disponibilizam se encontram aplicativos, principalmente quando se trata de uma hospedagem compartilhada.  É nisto que o JasperReports inclui a  possibilidade de ter todas as fontes que usou em seu relatório em produção.

Adicionando e exportando a fonte no iReport

Vá no menu Tools >Options (menu iReport>Preferences no Mac OS X) e, na janela Options, em iReport, selecionem a aba Fonts.

Através do botão Install Font selecionamos as fontes que desejamos importar no iReport. Depois de importadas, podemos selecionar todas elas e exportá-las através do botão Export as extension.

Figura 4 – A fonte escolhida e usada no relatório pronta para ser exportada

No exemplo que explico, chamei o arquivo que exportei de font.jar. É justamente este arquivo que vou adicionar em meu projeto.

A fonte como uma biblioteca no seu aplicativo Web pelo Eclipse IDE

No Eclipse, basta clicar com o direito do mouse sobre o projeto, selecionar o item Properties. Na caixa de diálogo Properties, vamos em Java Build Path, na aba Libraries. Para adicionarmos a biblioteca font.jar, vamos no botão Add External JARs.

Figura 5 – O JAR font.jar adicionado nas bibliotecas do meu projeto

Claro que eu não poderia deixar de comentar uma particularidade do Eclipse IDE na versão Helios. Para projetos Java EE. Nesta versão, temos um item de nome diferente para adicionarmos as bibliotecas do projeto no aplicativo Web. Este item está na janela Properties, em  Deployment Assembly. É neste local que determinamos quais bibliotecas serão exportadas ao executarmos o servidor Java.

Figura 6 – Adicionando os arquivos JARs do projeto no aplicativo Web

Ao clicarmos no botão Add, a caixa de diálogo New Assembly Directive surge. Esta caixa de diálogo é a responsável por selecionarmos as bibliotecas do projeto em Java Build Path Entries.

Figura 7 – Obtendo os arquivos JARs de Java Build Path

Ao clicarmos em Next, veremos todas as bibliotecas que dispomos em Java Build Path. Selecionem todas – as bibliotecas para executar o relatório JasperReports devem estar presentes – finalizando no botão Finish.

Figura 8 – Arquivos JARs selecionados

Retornando ao diálogo Properties, no item Deployment Assembly, temos todas as bibliotecas que serão adicionadas ao diretório lib do projeto, incluindo font.jar.

Figura 9 – As bibliotecas que serão exportadas para o diretório /lib do projeto Web

A fonte como uma biblioteca no seu aplicativo Web pelo NetBeans IDE

No NetBeans IDE, basta adicionar em Libraries, clicando com o direito do mouse e selecionando, no menu de contexto, o item Add JAR / Folder.

Figura 10 – As bibliotecas que serão exportadas para o diretório /lib do projeto Web

Antes e depois da fonte adicionada ao projeto

Para satisfazer a curiosidade do que será visto, temos a Figura 11 que mostra um relatório gerado, em formato PDF, sem a fonte no diretório lib do projeto. Note a diferença com a Figura 12 em relação ao formato da fonte, principalmente do título “Produtos”.

Figura 11 – Arquivo PDF gerado como relatório sem a fonte no diretório lib do projeto

Figura 12 – Arquivo PDF gerado como relatório com a fonte no diretório lib do projeto


O projeto para download

Clique aqui para baixar o projeto e alterá-lo como desejar.

Tags: , , , , ,


Próxima Página »