Se o servidor seu, porque o problema meu?

Quero comear este ano, em meu blog, falando um pouco sobre administrao em aplicativos e servidores Java, que serve tambm no geral para outros servios. Desde que assumi a gerncia da Integrator na parte de hospedagem, vejo e-mails que so direcionados ao suporte e recebo tambm, muitos pedidos que, sinceramente, no deveriam vir de um desenvolvedor Java. A critica que fao aqui construtiva e, de certa forma, um puxo 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 comea com a sua criao. Voc, profissional desenvolvedor, recebeu a rdua tarefa de criar aquele sistema maravilhoso que algum 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 mquina de desenvolvimento?
Do desenvolvimento at a produo

Muitos desenvolvedores se acostumaram com a automao das ferramentas de desenvolvimento e, claro, com tanta facilidade, parar e iniciar o servio Java ali simples. Entretanto, o desenvolvedor java no 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. No apenas o bsico de instalar, configurar, iniciar e parar. Tambm no vale dizer que sabe ler logs. Vai alm. O profissional Java precisa saber como o servidor Java, que escolheu usar, opera. Isso vai desde as suas caractersticas bsicas de configurao, at como ele pode ser modificado e otimizado para melhorar o desempenho do que desenvolveu. Est bem, voc vai dizer que no 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 vrias tarefas diferentes. E no seu caso, o servidor Java a extenso 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, no somente em sua mquina. Usar o framework XYZ no a etapa final do que criou. no momento que ele vai para produo, que onde aparecero os problemas.

O que mais vejo e escuto a frase: na minha mquina funciona. Ora, se voc desenvolve corretamente, sem nenhum problema oculto, nada personalizado especificamente para sua mquina, que causaria erros online, tambm funciona em qualquer lugar. Estes so os problemas mais comuns do desenvolvimento para a produo so: 1) Nome do banco de dados criar a conexo usando um nome local, onde na produo se modifica, bate o recorde em erros de acesso pelo usurio; 2) Nome do usurio do banco de dados segundo problema mais comum, o usurio diferente e gera erro de acesso negado; 3) Permisses de acesso em arquivos o terceiro mais comum, quem usa o Windows est muito acostumado a ter permisso para tudo. Mas online, servidores seguros tem permisses para escrita e execuo, que precisam ser dadas em arquivos e diretrios; 4) Erro no local onde est o banco de dados conhecer a regra de como acessar o banco de dados no servidor de produo o mnimo, vai desde do host at a porta. No sair colocando o que acha ser o correto. Na dvida, sempre perguntar a quem administra o sistema operacional para evitar erros e mudar, principalmente, no cdigo que foi compilado para colocar em produo; 5) Problemas de memria usar o framework XYZ porque ele foi indicado na comunidade como bacana timo. Mas saber o que ele consome de sua mquina melhor ainda. No adianta achar que sabe como usar o Tomcat, que localmente tudo funciona, que online no vai dar problemas, se voc nem sabe localmente o quanto o Tomcat necessita de memria para executar seu aplicativo. Mquina de desenvolvimento possuem vrios GIGAS de memria RAM e muitas vezes o desenvolvedor nem se preocupou em limitar o servio em um X de memria. Online, voc ter configurado uma limitao no servidor Java. importante saber se, dentro desta limitao, seu aplicativo executa com conforto; 6) Envio de email O SMTP tem regras em qualquer lugar. Saber a porta correta, parmetros bsicos mnimos necessrios importante para que, em produo, o envio seja feito sem erros. 7) Erro 404 O deploy no 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 produo. 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 produo. Algumas bibliotecas tambm costumam dar problema quando existem duas do mesmo tipo, mas com verses diferentes. 9) Localizao No deveria estar nesta lista, mas infelizmente, um erro tambm comum. possvel configurar o Locale em seu aplicativo ou diretamente no servidor Java. No porque na sua mquina o Locale em pt-br que online vai ser tambm.

Saber modificar isso no servidor Java que seja, no difcil e lhe salva de dores de cabea com uma configurao muito simples. 10) Erro na descompactao 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 lanar um erro na descompactao. 11) Assumir o problema , eu sei, isto no se trata de erro de produo. Mas pensar um ato importante para resolver problemas. Sair culpando outro, sendo que o problema seu, no faz parte do meio que escolheu como profisso. Se assumiu um cargo como desenvolvedor, assuma tambm que o que fizer, desenvolver, pode ter falhas e que elas so corrigveis. Assumir o problema o primeiro passo em direo da soluo.

Os logs so a chave para a soluo dos problemas

Todos os problemas, que relatei acima, sempre lanam excees. Claro que, muitas vezes, o desenvolvedor sai reclamando antes de pensar, que sua maior tarefa, do porque essas excees esto sendo lanadas. A grande vantagem do java que ele aponta o dedo para o problema. E de tantos que usam no mundo, muito fcil descobrir uma resposta para o problema. Mas fica mais difcil se quiser que resolvam o SEU problema para voc, acredite.

Indo alm dos servidores Java

Em produo, no basta apenas saber como operar um servidor Java. Voc desenvolveu o aplicativo e, como conhecedor do que fez, deve tambm 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 no caiu, deu um erro estranho em seu aplicativo ou aconteceu algo que no havia previsto, claro. Mas a culpa no sua, certo? Funcionava antes e no mexi em nada. Errado! Totalmente sua culpa. S de dar a resposta de que no mexeu em nada j implica que no est cuidando do que fez. Se no observar por um tempo o que desenvolveu, a evoluo do que fez, no vai ter correes e, como consequncia, erros. Saiba estes princpios bsicos no desenvolvimento: 1) Bibliotecas e frameworks mudam se mudam de verso, porque a anterior no era perfeita. Erros so reportados e precisam ser atualizados para evitar que no seu, uma hora ocorra o que outro j teve. 2) Servidores Java mudam mesma situao que citei acima, se mudou a verso do servidor Java, pode ser que, algum possvel bug pode causar problemas em seu aplicativo.

3) Profiler Usar um profiler vai lhe orientar como seu aplicativo se comporta e ver possveis picos de memria/CPU que possam lhe causar problemas, mais adiante, com muitos usurios acessando.
Atacando o problema de frente

Evidentemente muitas so as situaes que ocorrem em aplicativos. Nem todos os problemas so simples de serem solucionados. Mas alguns podem ser de simples resoluo se, de fato, voc realmente quiser resolver a situao. 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 tambm 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 no quer mexer no que estava funcionando bem nos primeiros 10.000 registros/acessos. Mas agora no est mais. Muita gente acessando, muitos erros sendo lanados, memria, velocidade. Precisa modificar o comportamento, voltar para a prancheta do desenvolvimento e replanejar. Se no 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 no estar dando conta do recado como outro daria. hora de conhecer novos servidores Java e testar, seja o Jetty, JBoss ou GlassFish. Algumas pequenas mudanas, como a troca de servidor Java, podem trazer benefcios 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, algum arrumou alguma soluo que fez melhorar o desempenho do aplicativo com aquela tecnologia XYZ que escolheu e deu a dica. Busque alternativas e dicas.

Empurro ou puxo de orelha?

Minha inteno dar a vocs, leitores deste blog, um empurro no sentido certo. Existem vrias etapas no desenvolvimento e todas envolvem o que criou. Vai desde o sistema operacional que ir trabalhar em produo, at o que acessado pelo seu aplicativo. Estes detalhes precisam ser todos analisados, mesmo que voc diga que apenas um mero desenvolvedor Java.