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.

Ativando Syntax Highlighting no VIM

Recentemente participei de algumas discussões nas listas que participo que abordaram ambiente de desenvolvimento e, consequentemente, editores e IDEs. A escolha do editor ou da IDE é algo completamente particular e extremamente pessoal, e depois que alguém adota alguma ferramenta, não adianta alfinetar ou empalar com uma lança, as opiniões dificilmente mudarão, não importa quais ou quantos argumentos forem usados. Até mesmo por isso não quero falar sobre melhor ou pior aqui.

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:

picture-2

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.

1º Workshop do PHP-ES

Este mês, um final de semana depois do Falando em Java, o pessoal do PHP-ES vai realizar o 1º Workshop PHP do Espírito Santo. O evento será no dia 30 de maio no Anfiteatro da UVV, e é gratuito.

banner_phpes
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!

Palestra: Testes de Unidade com JUnit

Hoje tivemos mais um encontro do ESJUG. Desta vez eu fiz uma apresentação sobre Testes de Unidade com JUnit. A idéia principal da apresentação foram os exemplos, mas os slides ficaram legais, por isso estou compartilhando.


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.