Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

Crie, modifique ou remova qualquer working set.

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Numa dessas discussões, inevitavelmente começaram a falar sobre o VIM e num determinado momento alguém exclamou que o VIM era tão ruim que nem Syntax Highlighting fazia. Mas oras, é claro que faz. Uma dica rápida.

1) Ativando Syntax Highlighting manualmente

Durante a edição de um arquivo, você pode ativar ou desativar a Syntax Highlighting quando quiser. Para ativar:

:syntax on

E para desativar:

:syntax off

2) Ativando Syntax Highlighting automaticamente

Se você quiser, pode deixar que o VIM faça isso automaticamente sempre que possível. Pra isso edite o arquivo vimrc e adicione o trecho abaixo. No Linux esse arquivo geralmente fica em /etc/vim/vimrc, enquanto no Mac OS X você o encontrará em /usr/share/vim/vimrc.

if has("syntax")
  syntax on
endif

E é isso. Feche e abra o próprio arquivo vimrc e veja as diferenças. No meu caso ele ficou assim:

Os arquivos de syntax ficam no diretório syntax dentro do diretório de instalação do vim, pro caso de você querer mudar alguma coisa.

A abertura do evento foi muito legal, o pessoal da Caelum mostrou uma série de novidades que eles estão trazendo para o mercado, dentre elas um livro de Arquitetura e Design de Software, curso de TV Digital com Ginga, curso de Flex e muito mais.

Logo depois uma apresentação do Jim Webber titulada “Guerilha SOA”, simplesmente fantástica. Além de dominar totalmente o assunto o Jim foi um exímio apresentador, soube brincar nas horas certas sem perder o timing das piadinhas.

O Paulo Silveira e o Rafael Cosentino fizeram uma apresentação sobre O Profissional Java Efetivo. A apresentação foi boa, mas poderia ter sido muito melhor se não tivessem perdido muito tempo nas piadinhas sobre o Nico.

A palestra do Kung e do Anderson foi fantástica, eles mostraram pontos e recursos super importantes da máquina virtual Java e como ela está voltando a ser dinâmica. O Kung falou do início da JVM, quando ela era utilizada para linguagens dinâmicas, explicou como e porque ela ficou tão “estática” e como as coisas estão voltando ao que eram, dinâmicas. É claro que ele também mostrou vários benefícios de termos linguagens dinâmicas usufruindo de todos os recursos e qualidades de uma plataforma como Java.

Todas as outras apresentações foram muitos legais, todos os palestrantes estão de parabéns. No geral, a minha opinião sobre o evento é que ele foi muito bom. O único ponto que não foi tão legal foram os excessos de brincadeiras e comparações com o mundo real nas apresentações, o que claramente causou perda de conteúdo útil e importante. Apresentações purpurinadas, apresentadores brincalhões e muita descontração nem sempre caem bem, na verdade são mais difíceis de dar certo e fazerem sucesso do que o conteúdo propriamente dito da apresentação.

Este ano o FJ teve mais de 500 participantes, quase o dobro em relação a última edição. O local do evento também foi outro, muito maior e chique moderno. E a organização e palestras, como sempre foram de altíssimo níveis, o FJ mostrou claramente o amadurecimento e crescimento da Caelum como empresa.

Pra mim estes dias em São Paulo significaram muito mais do que simplesmente o evento. Eu conheci o Paulo Silveira um pouco antes da Caelum existir, e de certa forma a vi nascendo, crescendo e evoluindo, mesmo que de longe. Pude ver várias fases de perto, até quando os irmãos Silveira davam a primeira aula de cada curso usando terno e gravata =P. Conhecer o novo escritório da Caelum, cheio de amigos e conhecidos da época de ouro do PortalJava e do GUJ, com dezenas (várias dezenas) de colaboradores pessoas trabalhando juntos, sincronizados, motivados e felizes foi indescritível, fiquei realmente muito feliz. Com certeza é uma empresa e trabalho que nos motiva muito e que servirá de exemplo para nós aqui na Giran.

Entre as apresentações teremos: Nadando em Dinheiro com AJAX e jQuery (Reinaldo de Souza “JuniorZ”), Desenvolvimento ágil com Smarty (Gerson Novais) e CakePHP: fazendo o primeiro bolo (Leonardo “Hackin” Freire).

Este evento é o primeiro com a participação oficial da Giran como patrocinadora, estamos muito contentes em poder colaborar. E também tem o Raj Léo Hackin, sócio da Giran que é um dos palestrantes e organizadores do evento, claro.

Então se você estiver aqui em Vitória não perca esta oportunidade, participe!

Estou preparando os códigos que foram feitos na apresentação junto com outros que foram preparados antes para demonstração. Depois que estiver ‘organizado’ vou subir para o github e disponibilizar aqui no blog.

O pior é que ultimamente com tanta mídia gratuita por aí eu tenho notado muita gente se empolgando e embarcando na onda de “crítico matador”, e simplesmente querendo fazer o papel do grande sábio e conhecedor de todos os assuntos, criticando a tudo e a todos sem o menor pudor – e na maioria das vezes, sem a menor autoridade para tal.

Alguns pensam que girando a metralhadora e disparando críticas para todos os lados serão mais respeitados, ou sair logo criticando com todas as forças algo novo e recém lançado é um grande negócio para auto-promoção e até mesmo que a crítica é a melhor forma de “falar que sabe tudo do assunto”.

Mas assim como a síndrome do seniorismo, onde muita gente se tornou consultor senior de negócios após 1 ano de estágio, a síndrome do criticismo está se alastrando rapidamente. Hoje em dia todo mundo acha bonito criticar, todo mundo acha bonito fala mal, chamar o código alheio de porcaria (adoraram fazer isso com o twitter, recentemente) e por aí vai. E o pior, o que está alimentando essa nova síndrome é o comportamento da maioria que tem respeitado e tem até sentido uma pontinha de medo de quem adora criticar tanto.

É muito fácil criticar, aliás, qualquer idiota pode criticar, condenar e queixar-se – e a maioria dos idiotas faz isso. Por vezes é muito mais simples e não requer esforço e nem conhecimento, basta disparar qualquer asneira e pronto. HEI! Pessoal, acordem!

Já do outro lado nem é preciso ser conhecedor do assunto criticado para entender a crítica, afinal, célebres frases como: “- Odeio o framework X”, “- A API de fulano é horrível, deplorável” e “- O serviço do João é cheio de bugs”, são muito fáceis de serem compreendidas e são ótimas para causar uma má interpretação do assunto. Mas eu me pergunto, por que a pessoa odeia o tal framework, será por algum motivo que justifique a crítica ou seria apenas porque antes da síndrome do criticismo esta pessoa já passou pela síndrome do seniorismo e agora além de não saber a ferramenta ainda a crítica. Ou por que a API do fulano de tal é tão ruim, não seria por que a API é REST e o crítico só sabe fazer integrações usando stored procedures? Ou quais seriam os tais bugs no serviço do João, será que existem de fato?

Eu não quero que este post seja visto como uma crítica aos críticos, não é. De certa forma estou usando este espaço e escrevendo sobre isso exatamente aqui no meu blog pois tenho visto que muitos amigos e pessoas próximas que mantenho contato estão sofrendo de tal síndrome do criticismo. E isso é muito mais do que simplesmente chato, é frustrante.

A intenção é dar uma dica: estudem; estudem, ESTUDEM SEMPRE! Saibam ser humildes, tenham respeito pelo próximo e aprendam a admirar o trabalhos dos outros. Você será verdadeiramente respeitado e admirado ao dizer “- Parabéns pela sua implementação, sua idéia para resolver aquele problema foi ótima” do que criticando sem conhecer por pura falta de vontade e empenho em aprender, criticar de forma irresponsável somente vai trazer respeito e admiração de outros irresponsáveis e alienados.

Um exemplo simples e clássico

Eu estudei por muitos anos (há muito tempo atrás) seguidos e tive cerca de 4 anos de experiência profissional com Struts 1.x e até hoje penso duas vezes antes de formular uma crítica a este velho conhecido e tão calejado framework. Tenho consciência que não sei sobre todos os detalhes do Struts e que posso ter compreendido ou até utilizado de forma errada um ou outro recurso, por isso sempre penso se sou a pessoa mais adequada para aquilo, principalmente quando estou inserido num cenário que sei que a minha opinião, por exemplo, poderá repercutir ou influenciar a opinião de outras pessoas. É preciso ter humildade para reconhecer que não se sabe tudo e responsabilidade para criticar.

Mas mesmo assim eu escuto/leio muita coisa ruim do Struts que vem de pessoas que estão começando a aprender JSF sem nunca ter tido qualquer experiência com outra ferramenta/framework antes, que credibilidade dar a pessoas assim? Que credibilidade dar a uma pessoa que desdenha do código alheio sem nunca te-lo visto?

Responsabilidade, humildade e maturidade devem estar sempre juntas para te ajudar a manter-se em seu lugar e saber quando e como expor a sua opinião.

Além das apresentações o FJ também é uma excelente oportunidade para rever alguns amigos antigos, fazer novos contatos, conhecer várias figurinhas dos fóruns, twitter e listas.

Desta vez irei com meu sócio o Rajesh Koothrappali Leo Hackin. Nos vemos por lá!

Está chegando o próximo encontro do ESJUG. Desta vez o encontro será realizado na UVV – Vila Velha e eu vou fazer uma apresentação sobre JUnit. Ainda não temos confirmação se será em laboratório ou auditório, mas ao menos ‘eu’ farei a parte de mão na massa, mesmo que sozinho – brincadeira, não sou tão egoísta assim. A apresentação será bem prática, mesmo que realizada no auditório.

Seguem mais informações:

• Onde: UVV (Vila Velha)
• Sala: Sala 32, Prédio Rosa
• Data: 09/05/2009 (próximo sábado)
• Horário: 09:00h
• Tema: Testes de Unidade com JUnit
• Palestrante: Paulo César M. Jeveaux - ESJUG JUG Leader

Neste encontro não haverá nenhuma taxa ou cobrança para inscrição, o evento é completamente gratuito e a inscrição é obrigatória.

Faça sua inscrição agora!

Observação importante: Os alunos da UVV e da Faesa poderão usar as horas deste encontro para descontar na carga horária de atividades complementares exigidas pelo currículo do curso. Aproveitem!

Configurando um servidor de desenvolvimento da Giran as novidades não foram grandes, a maioria das aplicações, serviços e preocupações foram as mesmas de um ambiente de desenvolvimento local. Já as experiências com a configuração do servidor de produção foram bem mais legais e algumas inéditas. Oracle, MySQL, SVN, Gitorious, Ruby Enterprise Edition + Passenger e claro, Apache 2 HTPP Server e Apache Tomcat.

Por hora vou escrever apenas sobre o mod_jk, que é a integração entre o Apache 2 HTPP Server e o Apache Tomcat. Eu já tive experiências anteriores com o mod_jk em ambientes de produção, em ambientes com redudância, com tomcat, com jboss e alguns mais, mas ainda não havia passado por uma situação onde eu iniciasse do zero e todas as responsabilidades estivessem comigo, e isso foi ótimo.

Um resumo do ambiente:

• Ubuntu Server 8.04
• Apache 2 HTTP Server 2.2.8
• Apache Tomcat 6.0.18
• JDK 1.6.0_13

O Apache

O Apache e o mod_jk foram instalados usando o próprio apt-get, então esta tarefa foi realmente muito fácil:

jeveaux@baium ~ $ sudo apt-get install apache2 libapache2-mod-jk

Uma série de pacotes e dependências virão junto com os dois pacotes acima, pode confirmar que tudo vai dar certo.

Esta instalação deixará o Apache em /etc/apache2, onde nós teremos (os principais arquivos):

• httpd.conf – Configuração geral do apache.
• conf.d – Configurações diversas, todos arquivos que estiverem nesse diretório serão carregados como configuração.
• mods-available – Arquivos de configuração e ativação dos módulos.
• mods-enabled – Módulos que estão ativados no apache, são links simbólicos para os arquivos do diretório mods-available.
• sites-available – Arquivos de configuração dos sites (VirtualHost).
• sites-enabled – Sites que estão ativados, são links simbólicos para os arquivos do diretório sites-available.

No httpd.conf poucas coisas precisam de intervenção, pessoalmente eu gosto muito deste esquema de organização e divisão de configurações utilizada pelo apache. Por exemplo, tudo que estiver no diretório APACHE2_HOME/mods-enabled será carregado automaticamente, primeiro todos os arquivo .load, que geralmente contém o LoadModule, e depois todos os arquivos .conf, que contém as configurações específicas do módulo, desta forma temos vários pares load+conf, um para cada módulo.

O JDK e o Tomcat

Apesar do servidor ser Ubuntu, desta vez eu não usei o apt-get. Eu sempre preferi instalar o JDK e algumas outras ferramentas de forma manual, não sei exatamente porque tenho essa mania, mas não consigo fugir.

O que importa é que o JAVA_HOME e o PATH estejam ajustados, se isso estiver correto tanto faz se você instalar usando o apt-get ou não. De qualquer forma, se você optar por usar o apt-get, basta seguir o comando abaixo:

jeveaux@baium ~ $ sudo apt-get install sun-java6-jdk tomcat5.5

Se não, se você for paranóico como eu, certifique-se de ter configurado o JAVA_HOME e o PATH manualmente no seu .bashrc:

export JAVA_HOME=/development/jdk1.6.0_13
export PATH=$JAVA_HOME/bin:$PATH

O mod_jk

O mod_jk já foi instalado anteriormente, então só precisamos certificar de que ele esteja ativado.

Caso você queira ativar ou desativar um módulo, existem duas maneiras: 1) usar os comandos a2enmod <mod> e a2dismod <mod> ou simplesmente criar ou remover os links simbólicos em APACHE2_HOME/mods-enabled.

1) Configurar os workers

A instalação foi tão simples que somente um arquivo nos interessa por enquanto: /etc/libapache2-mod-jk/workers.properties. Abaixo apenas as configurações mais importantes e algumas que precisaremos alterar:

workers.tomcat_home=/development/apache-tomcat-6.0.18
workers.java_home=<span>/</span>development<span>/</span>jdk1.6.0_13
worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1

No workers.properties temos o mapeamento do tomcat (workers.tomcat_home) e do JDK (workers.java_home). Há outra propriedade muito importante que é a worker.list, nela definimos todos “workers” que teremos. Para um único servidor teremos apenas um worker, mas em ambientes de cluster teremos vários. E temos para cada worker as suas configurações particulares: port, host e type, além de uma em particular, muito importante em ambiente de cluster e load balancer, a lbfactor, que indica a quantidade de trabalho do worker no conjunto, quanto menor o valor, menor o esforço do worker, ou seja, menos requisições serão despachadas para este worker.

2) Iniciar (ou montar) o JK

Mais uma vez temos dois caminhos a seguir aqui. Iniciar o JK no site principal ou em algum VirtualHost (sub-domínio) específico. O que vai mudar é onde você vai inserir o código a seguir.

Caso queira colocar o JK no seu site principal, você poderá inserir o código abaixo no seu httpd.conf – o que eu não recomendo – ou criar um arquivo jk.conf em APACHE2_HOME/mods-available, depois criar o link simbólico para este arquivo em APACHE2_HOME/mods-enabled.

Mas se você quiser ou precisar usar o JK somente em algum site e/ou sub-domínio específico, insira o código abaixo direto no arquivo do site em APACHE2_HOME/sites-enabled.

JkWorkersFile   /etc/libapache2-mod-jk/workers.properties
JkLogFile       /var/log/apache2/mod_jk.log
JkLogLevel      info
JkMount /*.jsp ajp13_worker
JkMount /teste/* ajp13_worker

Com essas configurações estamos escolhendo qual arquivo de workers vamos usar (JkWorkerFile), ou seja, qual o tomcat e JDK. Também definimos o arquivo de log e qual o tipo de log será gravado e, o ponto chave, quando o JK será usado. O JkMount pode ser repetido quantas vezes for preciso e é nele que definiremos todos os padrões de URL quanto forem precisos para que o JK seja usado.

É neste momento, configurando o JkMount, que podemos dividir o processamento de recursos dinâmicos (jsp, servlet) para o Tomcat e recursos estáticos para o Apache. Não vou entrar nesse ponto neste artigo, mas fica a dica.

Com o trecho acima estamos encaminhando para o tomcat – através do JK – tudo que terminar com .jsp ou tudo que estiver após /teste.

O Deployment

Aqui tudo correrá como qualquer aplicação Java, sem nenhuma diferença. Chamaremos nossa aplicação Java de “teste”. Após o deploy podemos acessa-la como de costume em http://localhost:8080/teste, mas agora com o JK podemos acessar também através da porta 80 (apache) em http://localhost/teste.

Está chegando o próximo encontro do ESJUG. Desta vez o encontro será realizado na Faesa (Campus I). Seguem mais informações:

• Onde: FAESA (Av Vitória)
• Sala: Sala 9, bloco 4
• Data: 18/04/2009 (próximo sábado)
• Horário: 09:00h
• Tema: Tutorial de Java Básico
• Palestrante: Roberto Vezzoni

Neste encontro não haverá nenhuma taxa ou cobrança para inscrição, o evento é completamente gratuito.

Faça sua inscrição agora!

Observação importante: Os alunos da UVV e da Faesa poderão usar as horas deste encontro para descontar na carga horária de atividades complementares exigidas pelo currículo do curso. Aproveitem!