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.

Migrando do Netbeans para o Eclipse

Há alguma semanas comecei a usar o Netbeans profissionalmente num dos projetos aqui da empresa. Já comentei sobre isso algumas vezes aqui no blog: aqui, aqui e aqui. Experiências com ferramentas novas (às vezes nem tão novas, afinal eu já conhecia o Netbeans há muito tempo, só não usava no trabalho) é sempre algo que gosto muito pois sempre rola muito aprendizado, melhora nossa visão e criticidade sobre uma série de pontos, e por aí vai.

E com o Netbeans não foi diferente, aprendi um pouco mais sobre detalhes da IDE, alguns atalhos, algumas manhas, também vivenciei alguns dos problemas que eu já conhecia e acabei por descobrir e sofrer com alguns outros novos. Após migrarmos para a versão 6.1 alguns novos problemas foram cruciais para a decisão da migração, como os mais importantes:

  1. CVS
    Com muita freqüência (principalmente com JSPs) o Netbeans não mostra o que há de novo ou modificado no repositório. É muito comum alguém fazer um commit de uma nova JSP, por exemplo, outra pessoa fazer um Show Changes e está JSP não aparecer na lista para o update. Às vezes conseguimos resolver fazendo direto um Update no projeto inteiro, mas não é sempre que funciona. Mesmo quando funciona há o inconveniente de estar fazendo um update às cegas, sem saber ao certo o que está vindo do repositório. Quando não funciona eu tenho que procurar o cara que colocou a JSP no projeto, pedir pra ele remover e inserir de novo, até funcionar.
  2. Indexing
    Sabe aqueles problemas horríveis que só acontecem de vez em quando ou que só acontecem com uma pessoa X ou Y? Pois é, depois da atualização do Netbeans, algumas estações praticamente todas as estações começaram a ter um problema desta espécie. Ao abrir a IDE perdia-se em média 3 minutos aguardando a conclusão da indexação do conteúdo do projeto, e não, nosso projeto não é um mega projeto. E isso não acontecia com todas as pessoas da equipe, apenas com alguns sortudos contemplados.

Como estes problemas impactam diretamente no ambiente de desenvolvimento como um todo e na integração da equipe não tivemos outra alternativa que não fosse a migração, e obviamente a IDE escolhida não poderia ser diferente, optamos pelo Eclipse :D

O processo de migração em si foi bem simples e não houve nenhum tipo de trauma. Não utilizamos ferramentas ou kits de migração, nada disso, tudo correu de forma de simples e convencional, porém muito funcional e útil.

A migração

Nosso ambiente no Netbeans era composto por dois projetos, que chamarei pelo nome fantasia de jujuba. Este era o nosso projeto web. E também tínhamos o projeto jujuba-ejb.

Como os nomes dos projetos não refletiam bem o que deve ser o projeto real do cliente nós aproveitamos a migração para arrumar isso. Então criamos num Eclipse um Enterprise Application Project chamado doceria e nele dois módulos: doceria-web e doceria-ejb, simples assim.

O primeiro passo foi conferir todas as dependências. Nesta momento vale um ponto para o Netbeans, bastaria associar o projeto a dependência desejada (jersey, pra REST, por exemplo) e pronto, tudo é feito para que o projeto compile e a API fique a sua disposição e o mesmo é feito durante o build e deploy, empacotando todas as dependências. Mas fizemos no Eclipse, pega-se os JARs, copia no web-inf/lib para o projeto web e pega-se os outros JARs, coloque-os no projeto ejb e configure se estes deverão fazer parte do EAR ou do JAR do EJB. Pronto, agora estão configuradas as dependências.

O restante foi super simples. O deploy dos dois projeto é feito no JBoss, configurar isso no Eclipse é completamente normal, apenas criamos um novo servidor no Eclipse, utilizando a instalação local do JBoss, depois bastou associar o projeto doceria ao JBoss e tudo já estava funcionando, aliás, por enquanto ainda era nada, pois os fontes ainda não haviam sido migrados.

A migração dos fontes foi a parte mais antiquada, porém a mais fácil, bastou copiar diretamente no sistema de arquivos:

Para o projeto web:

  • cd /home/jeveaux/development/java/workspace/doceria-web/src
  • cp -r /home/jeveaux/development/java/workspace/jujuba/src/java/* .
  • cd ../WebContent
  • cp -r /home/jeveaux/development/java/workspace/jujuba/web .

E para o projeto EJB

  • cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule
  • cp -r /home/jeveaux/development/java/workspace/jujuba-ejb/src/java/* .
  • cd /home/jeveaux/development/java/workspace/doceria-ejb/ejbModule/META-INF
  • cp /home/jeveaux/development/java/workspace/jujuba-ejb/src/conf/ejb-jar.xml .

E pronto, foi isso, sem stress e sem complicações. Agora o projeto foi totalmente migrado para o Eclipse e está completamente funcional, igualzinho quando estávamos utilizando o Netbeans.

Mais (ainda) do mesmo

Já fazem alguns dias que foi lançada a versão do 6.1 do NetBeans, mas como andei sem tempo demorei um pouquinho pra atualizar meu (novo) ambiente de trabalho, como já comentei aqui e aqui, estou utilizando o NetBeans num dos projetos que participo.

Como ia baixar a nova versão, acabei optando pela versão full já interessado no suporte ao Ruby, coisa que ainda não testei no NetBeans pois o Aptana sempre foi legal pra mim, afinal é um Eclipse, certo? ;-) Ainda não tive tempo para testar o NetBeans com Ruby, mas farei isso ainda essa semana.

Logo de cara ao abrir os projetos no novo NetBeans o project.properties foi alterado e todos os endereços que antes eu havia mudado para caminhos relativos voltaram a ser caminhos absolutos, precisei acertar isso novamente. Todos os arquivos do projeto localizados no diretório nbproject foram alterados, não sei exatamente o motivo e nem se isso vai atrapalhar quando alguém com outra versão do NetBeans for utilizar o projeto, sinceramente fiquei um pouco preocupado.

Um novo problema que não acontecia passou a acontecer. Uma referência a um projeto com EJBs, apesar de não estar com a opção ‘Package‘ do NetBeans marcada, ou seja, o projeto referenciado não deveria ser empacotado junto com o WAR da Web Application. Mas isso não estava funcionando mais, precisei editar mais um arquivo manualmente, o build-impl.xml e retirar a tag copy-ear-war da referência problemática.

Fora os problemas, eu gostei que agora ao fazer o diff entre dois arquivos as diferenças já são abertas automaticamente, antes eu precisa mandar abrir o diff e depois clicar numa das tags exibidas. E a IDE em si também ficou mais rápida para aparecer, isso mesmo, só pra aparecer, pois pra abrir continua demorando o mesmo tempo de antes, só foi feita uma jogada pra nos tapiar. Os projetos e módulos que antes eram carregados ao iniciar a IDE agora são carregados depois que ela abre, ou seja, continua demorando do mesmo, só mudaram a demora de lugar.

No geral essa experiência está sendo muito legal, já estou bem menos reativo ao NetBeans.

Mais do mesmo: Netbeans

Nada como um bom final de semana trabalhando para lembrar e descobrir mais algumas façanhas no nosso amigo Netbeans. Vamos a listinha de novo.

Gostei:

  • Ainda vou descobrir alguma coisa.

Não gostei:

  • Set as Main Project. Isso é muito chato!
  • O ‘Fix Imports’ só funciona quando a classe não tem nenhum erro, ou seja, só depois de você acertar tudo que uma geral nos imports poderia fazer.
  • Ainda não descobri um atalho para o Quick&Fix. No Eclipse, CTRL+1.
  • Não dá pra você simplesmente matar, parar, *exterminar* com o serviço do servidor de aplicações que estiver utilizando. No meu caso tem sido péssimo, pois o servidor de aplicações roda localmente na minha estação, mas o banco de dados eu acesso o do escritório (lembre-se que eu trabalho em casa agora :D) via VPN e às vezes demora uns 10 minutos pra verificar todas as conexões. (Nota mental: não que eu queira largar conexões penduradas no banco sempre, mas neste caso seria melhor do que esperar 10 minutos, afinal, em menos de 10 minutos o oracle já iria matar as conexões mesmo).

No final de semana tem mais.

Netbeans!? Minhas impressões

Como muitos desenvolvedores, eu sou um eclipseiro de carteirinha. Uso o Eclipse profissionalmente desde mais ou menos a versão 2.0, passei pela 2.0.1, 2.0.2, 2.1 e por aí vai até a 3.3.2 de hoje, conhecida como Europa. Mas semana desde a semana passada eu estou utilizando o Netbeans, pois é, emprego novo, projeto em andamento e atrasado, corre corre, enfim, eu não consegui mudar para o Eclipse.

Por toda a minha carreira profissional, obviamente nem tudo foram flores, já utilizei outras IDEs e ferramentas, várias outras e por diversos motivos. Já passei por IntelliJ IDEA (essa é excepcional), JDeveloper (JDevil), JBuilder, BEA Weblogic Workshop (pífio, não estou falando da versão 10 que já é Eclipse, mas sim a 8 e anteriores) e até GEL e JCreator Pro, por mais estranho que pareça nunca havia usado o Netbeans num projeto de produção, pra valer mesmo e com uma equipe utilizando junto comigo.

Então eu nunca tinha usado o Netbeans? Claro que não! Eu adoro usar o Netbeans para fazer um showzinho no final das minha palestras e apresentações, sempre que sobra tempo. Principalmente nas apresentações sobre Introdução ao Java ME, aquele editor visual dele convence todos que ainda estavam em dúvida :D como dizem por aqui, é tiro e queda. Mas nunca foi muito além disso.

Então, hoje já completam duas semanas de uso do Netbeans 6.0.1, que é a última estável. Pois bem, vamos às minhas impressões neste tempo.

O que eu gostei:

  • As fontes da IDE são pequenas. Acho isso muito bom, poupa espaço na área visível para coisas mais importantes. O Eclipse (no windows vista e principalmente no gnome) deixa bastante a desejar nisso.
  • Não está demorando tanto para abrir. Mas ainda não é rápido :)

O que eu não gostei:

  • Não compila automagicamente (um viva ao JDT)
  • Os avisos de erro no projeto (aqueles ícones bonitinhos) ainda não funcionam direito.
  • O ‘Insert Code‘ não é nada sugestivo quando você pensa em gerar getters e setters ou sobrescrever algum método da classe pai.
  • CVS!? O suporte ao CVS é muito fraco. Com certeza é muito melhor que o do JDev e Weblogic Workshop, mas ainda assim é muito ruim, principalmente se você já usou o CVS no Eclipse antes. O merge seria mais legal se a IDE informasse que lado do código é o seu e qual é o remoto, mas isso você tem que adivinhar.
  • O gerenciamento de dependências não é dos melhores. Quando eu precisei adicionar um JAR ao projeto, a IDE me informava no Wizard o caminho completo do JAR no meu disco, apesar de eu ter deixado o JAR dentro do projeto, justamente para que o caminho não ficasse absoluto. Solução? Alterar o nbproject/project.properties na mão para que o caminho ficasse relativo ao projeto.
  • O consumo excessivo do heap ainda é um problema. Ao final de um dia inteiro de trabalho o heap da IDE já passou dos 500Mb fácil fácil.
  • Tinha mais alguma coisa que eu esqueci, assim que lembrar farei um novo relato.

Essas são as minhas impressões das duas primeiras semanas utilizando Netbeans. Um resumo para tudo? Que saudade do Eclipse.