Posts da tag Eclipse

Usando Working Sets no Eclipse

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

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:

eclipse_ativar_working_sets

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.

eclipse_visualizando_working_sets

Crie, modifique ou remova qualquer working set.

eclipse_gerenciando_working_sets

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

eclipse_go_into_working_set

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.

Um exemplo completo com JAAS

Devido ao um dos últimos posts deste blog, sobre utilização de JAAS com JDBC Realm e a grande procura por exemplos mais completos, com login e logout, por exemplo, resolvi melhorar um pouco a aplicação e disponibiliza-la para download.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Autenticação e Autorização: JAAS com JDBC Realm

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

  • Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
  • Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

Leia o restante deste post »

Porque eu não compraria o IntelliJ IDEA

Não é nenhum segredo que eu gosto muito do Eclipse, já andei falando isso aqui no blog por algumas vezes. Também já fiz um retrospecto de como foi uma experiência trabalhando com Netbeans, a qual resultou numa migração para o Eclipse. Desta vez a experiência está sendo com alguns produtos da JetBrains, e como andei falando muito bem do TeamCity, muita gente já me pertubou dizendo que eu fui muito parcial, então agora vou falar um pouco sobre o Intellij IDEA, versão 7.

Eu tenho no meu computador pessoal o Intellij IDEA 8 devidamente licenciado e registrado graças a um programa da Jetbrains que presenteia JUG Learders com licenças de seus produtos. Apesar disso eu nunca dei tanta atenção a esta ferramenta além de um projetinho de brincadeira aqui ou outro ali.

Mas ultimamente estou trabalhando numa equipe onde o Intellij IDEA 7 é a IDE oficial, até então nada de mais, eu pensei: “Vou usar o Eclipse, não tem problema”. Mas esta equipe possui uma certa proximidade com a ferramenta e possuem até plugins desenvolvidos para o IDEA que facilitam o trabalho com os produtos criados e mantidos pela empresa. Então aproveitei para não criar mais empecilhos e topei a experiência.

Já li e ouvi comentários fervorosos sobre o IDEA, pessoas que realmente gostam muito desta ferramenta. Na maioria das vezes sempre elogiam: o editor, as formas diferentes de code completion que podem ser alteradas ao gosto do desenvolvedor, as opções de refactoring, dentre algumas outras.

O primeiro: suporte a code completion. Não achei que fosse um diferencial que pudesse justificar o preço a ser pago na ferramenta. Existem alguns recursos interessantes nesta parte, é fato. Por exemplo poder controlar se o case sensitive será aplicado somente na primeira letra do que estiver sendo digitado, em todas elas ou em nenhuma. Excluir determinados pacotes/classes/métodos do code completion eu também gostei.

No editor, o recurso como ele chama de Virtual Space eu não gostei nem de longe, basicamente o editor permite que o cursor possa ficar em qualquer lugar, mesmo dentro de um espaço de tabulação ou após o final da linha, ou seja, espaços que não existem – virtuais. Este recurso pode ser desabilitado, mas vem ativado por default e eu perdi uns bons dias para descobrir que podia ser desabilitado. Da mesma forma o limite de abas abertas, além de ser pequeno (por default, somente 10) ele não avisa que chegou no limite, simplesmente funciona como uma fila, os mais antigos são descartados em detrimento aos mais novos. Poder abrir os arquivos com apenas um clique também é legal, mas não ter um botão pra fechar a aba e ter que usar o botão direito pra isso não é muito legal.

As opções de refactory são boas, mas ainda sinto um pouco de dificuldade com os nomes diferentes, geralmente onde eu esperava encontrar um “Extract Method”, por exemplo, acabo encontrando um “Introduce Method”. Só que ainda não encontrei “Aquela” opção única de refactory que só exista no IDEA e que fosse muito boa.

Aproveitando que foi o post sobre TeamCity que me fez escrever este post, o plugin de integração entre o IDEA e o TeamCity é legal, mas o melhor recurso que o plugin trás, o Delayed Commit, também pode ser usado com o plugin para Eclipse ou Visual Studio, então, menos um ponto para se prender a uma IDE paga.

A comunidade desenvolvedora de plugins não me pareceu tão grande e ativa quanto a do Eclipse, e isso, pra mim é um grande diferencial. Considero e dou muito mais valor ao “suporte” da comunidade e das pessoas que lidam diariamente com uma ferramenta do que aquele suporte que você compra e paga.

Estou usando o IntelliJ IDEA há cerca de 6 ou 7 semanas, então eu posso ainda não ter descoberto as “maravilhas” que o façam valer o seu preço, mas enquanto não encontrei e ninguém da equipe me mostrou tais maravilhas, continuo pensando que não vale a pena devido ao preço e à altertivas como o Eclipse. Não considero o IntelliJ IDEA uma ferramenta ruim, apenas considero uma estratégia ruim uma empresa gastar seiscentos doláres por licensa numa ferramenta que, ao meu ver, não irá agregar um diferencial que justifique o seu preço.

Integração contínua é com TeamCity

Recentemente fui convidado a montar o ambiente de integração contínua de uma empresa. O trabalho inicial de verificação dos projetos, testes e builds existente foi feito como manda o figurino. Todos os projetos usavam maven2 e, felizmente, todos eles (inclusive os sub-projetos) possuíam pom’s bem configurados e completamente funcionais.

Os builds e processos internos (manuais) para builds da empresa estavam ok, verificados e funcionando. Feito isso fomos aos testes. Testes!? Ok, vamos ao próximo passo e esqueça os testes por enquanto. O controle de versão era feito com Subversion e os clientes usando Tortoise. A IDE utilizada por toda a organização era o IntelliJ IDEA, mesmo assim o cliente para o SVN era o Tortoise, ainda tento compreender isso até hoje.

wheresthebuild-smallA empresa estava em um momento de criação e manutenção de testes funcionais, então, algumas pessoas estavam trabalhando exclusivamente com Selenium. Era uma boa oportunidade, pois estes testes seriam todos automatizados no ambiente de integração contínua a ser preparado. Uma série de procedimentos foram realizados até chegarmos no ambiente de facto, mas vou pular isso para o post não ficar grande e chato de mais.

Comecei então com a preparação de alguns protótipos. Já trabalhei algumas vezes em ambientes de integração contínua com o CruiseControl e também com o CruiseControl.rb, logo pensei em utilizar um desses. Pesquisando e perguntando a conhecidos cheguei às indicações de: Hudson com muitas indicações, Continuum da Apache, TeamCity da JetBrains e Bamboo da Atlassian, sendo estes dois últimos privados e com custo para licença. Ainda assim estava considerando as duas alternativas pagas logo depois de alguma alternativa da família CC, isto porque a empresa possuía licenças do Jira e Confluence, logo o Bamboo poderia ser uma boa pedida devido a recursos de integração. E também possuíam licenças do IntelliJ IDEA, logo a integração com a IDE poderia ser um ponto positivo para o TeamCity.

Alguma coisa aconteceu comigo e na manhã seguinte eu resolvi começar pelas ferramentas que eu não conhecia. Comecei pelo Hudson, TeamCity e por último Continuum, resolvi parar por aqui pra não perder mais tempo, nesse momento já havia uma escolha muito clara e três dias já haviam se passado.

Leia o restante deste post »

Get Adobe Flash playerPlugin by wpburn.com wordpress themes