Netbeans growing stronger

maio 12, 2008

Atenção, este blog foi migrado para:

During several years I’ve been a pretty happy Eclipse user, rarely feeling the need to use anything else. We know there are plugins for many many things, and a lot of development tools are Eclipse-based right now. The editor is awesome, and so are the refactoring tools. The support for web app development is also very nice. Eclipse supports a wide set of frameworks and technologies, and it’s not only aimed at Java development.

Why would someone even look at anything else, having such a great tool? Well, it turns out that our field is evolving really fast, and it’s very hard to follow this current pace, even for the most dedicated and passionate ones. Currently there are several technologies evolving very fast, and they are meaningful to a lot of enterprise developers. The rise of the JVM’s dynamic languages is crystal clear. Strong is also the growth of RESTFul web services. I’m personally very interested in both fields.

I’m currently using REST (lately with Jersey) for a lot of integrations between applications. The power it gives me is really nice, and I’m improving my developments each new month. I have also studied Groovy/Grails recently and really liked it. I wanna try JRuby on Rails sometime in the next weeks, to see what it offers and check how it compares to Grails. If you’re a Java enterprise developer, I’m sure you’re following the growth of these nitty things.

But where does Netbeans enter this talk? Well, Netbeans is doing a great job supporting these new technologies, and it’s way ahead of Eclipse in this field right now. Have you seen how easily you can develop RESTFul web services with Netbeans 6.1? Jersey support is great, very productive. The support for JRuby on Rails and Grails is also present, in a much more advanced state than Eclipse’s. Netbeans is doing a much better job than Eclipse regarding Web Services and JVM languages right now.

Swing development in Netbeans is very nice since version 5.0 (with the release of Matisse), and developing for mobile devices is also easier in Netbeans. Currently I don’t develop swing nor mobile applications, so this doesn’t really affect me.

However, I develop many RESTFul web services. And I wanna use more and more the JVM’s dynamic languages. Ignoring Netbeans is not a clever idea right now.

I still find Eclipse’s interface and editor much better than Netbeans’s. I also know a lot of Eclipse’s shortcuts and know very few in Netbeans. SWT is also faster than Swing, so Eclipse is faster than Netbeans. But considering what I said, I’m leaning towards the use of both IDEs at the same time. Since our machines are now much better equipped with RAM, I can have them open at the same time and also a couple of servers, with no memory shortage.

My Eclipse days are definitely not over, but now he’s gonna divide my attention with Netbeans 🙂 I hope I can become as productive with Netbeans as I am with Eclipse, even if it takes a few weeks. My first wish would be the Eclipse’s Quick Fix (Ctrl + 1) avaiable in Netbeans. Even without it, I’m sure my usage of Netbeans will certainly grow, and think this competition between the IDEs is very good for us. Let Eclipse Ganymede come!


Melhorando a aparência do Eclipse no Linux

janeiro 18, 2008

Atenção, este blog foi migrado para:

Eu já há um bom tempo utilizo o Linux como ambiente de trabalho em casa, e felizmente, há mais de 6 meses já tenho o prazer de usar Linux aqui na também. Uma das coisas que me incomodava um pouco quando comecei a usar o Eclipse no Linux era a aparência do mesmo. O Eclipse por default no Linux não fica com uma interface muito legal, dependendo das fontes que você esteja usando no seu ambiente gráfico.Já há bastante tempo eu utilizo como a Tahoma tamanho 9 como fonte principal no KDE e também no Eclipse. Esta fonte me agrada bastante e com ela eu considero bem mais agradável o uso do Eclipse, comparando com as fontes padrão que vêm configuradas no Linux. Esta semana saiu um post no Planet Eclipse falando deste mesmo assunto, e eles mostraram uma configuração de fonte que o pessoal do JBoss utiliza para trabalhar.

Eu baixei as fontes Liberation que eles usam e fiz um teste aqui para ver se gostava ou não da aparência. Realmente essa fonte que eles usam é bem legal, e eu cheguei a ficar em dúvida se mantinha a Tahoma ou se mudava para Liberation. Claro que esta é uma decisão de gosto pessoal, cada um tem suas preferências, e eu por enquanto estou mantendo Tahoma, pois já estou bastante acostumado e satisfeito com ela.

Para que vocês possam ver a diferença, seguem abaixo dois screenshots do Eclipse rodando aqui no Kubuntu, o primeiro delas com o uso da Tahoma 9 como fonte do Eclipse e fonte do editor Java e o segundo com o uso da Liberation Sans tamanho 10 (o tamanho 9 aqui estava com a largura estranha para algumas letras).

Eclipse com fontes Tahoma 9

Eclipse com fontes Liberation Sans 10

E aí, de qual vocês gostaram mais?? Eu não consigo me decidir sobre qual fica mais interessante pra mim, então estou mantendo o time vencedor com Tahoma. 🙂

OBS: A renderização das fontes varia de um sistema operacional pro outro, e no Eclipse no Windows eu não gosto da aparência da fonte Tahoma, e mantenho as configurações de fontes padrão do Eclipse no Windows, pois elas são satisfatórias pra mim (e afinal de contas, eu quase não uso Windows, não faz muita diferença… hehehe).

Update: Para melhorar MUITO o espaçamento das linhas no package explorer, navigator e outras views estilo Árvore, recomendo a criação do arquivo .gtkrc-2.0 no seu diretório home, com o seguinte conteúdo (experimente este conteúdo primeiro, e então modifique o que achar interessante) :

style "gtkcompact" {
font_name="Sans 8"
class "GtkWidget" style "gtkcompact"
style "gtkcompactextra" {
class "GtkButton" style "gtkcompactextra"
class "GtkToolbar" style "gtkcompactextra"
class "GtkPaned" style "gtkcompactextra"

Java Server Faces x Wicket: great framework of old paradigm vs new paradigm

janeiro 16, 2008

Atenção, este blog foi migrado para:

Just beginning 2008, I went to a new area, new team at There are several promising projects for this year, and this team switch will make it easier for me to properly evaluate and judge what I consider the 2 leading Java web frameworks nowadays.Like I said here, on my spare time I (try to) develop a lawyer application which uses Apache Wicket as its web framework. One of the projects I’m now working at uses Java Server Faces. This should be a great opportunity to finally go deeply on both frameworks and see in which cases each one is better than the other. Based on what i have already studied and used of both, i do have some opinions that may or may not change several months from now.

First, a little background. When i was studying to pass the SCWCD exam, I saw enough of tag libraries to get really sick of them 🙂 JSTL, Struts 1.x Taglib, Expression Language, etc etc etc. Every new taglib was a new syntax to learn, and the result of using taglibs to implement complex web pages is the famous tag soup. Not being a purist, although I don’t like scriptlets in general, I do think that in some cases they produce much cleaner code than the heavy use of taglibs.

Having said that, let’s start talking about JSF. Being a standard technology backed by Sun, and present on Java EE 5 specifications, you know that you’re gonna find plenty of support by development tools, many examples on the web and an already mature community of users to help you. JSF offers a huge set of components ready to use, and many of them are very pretty and easy to use. In my case, we’re using JBoss Tools + Rich Faces, and the Eclipse plugins avaiable here are just awesome.

Most of the web applications I have worked until now used Struts 1.x, and although Struts is by far the most successful Java web framework til now, developing with JSF is reasonably easier and more pleasant. However, even considering the clear evolution of JSF over Struts 1.x, I still qualify both within the same paradigm. That is, both have a massive dose of non-markup code in their views, and if you’re gonna work with them, you better have your spoon ready to dig into the tag soup 🙂 Ok, ok, JSF offers very nice components and manages a lot of the work that was left to the developer in the old times, such as managing the application state and offering a beautiful presentation layer without requiring the direct manipulation of javascript. But you’re still going to have your view layer full of taglibs, coding in a special syntax (the custom tags syntax) that will make it tough to track for problems when they happen within the tag soup. You better have a magical spoon to manipulate it 😉

Rather new in the Java web frameworks field is the very innovative Apache Wicket project. Wicket allows Java programmers to focus on what they do best: write Java code. No taglibs, how refreshing! 🙂 Wicket also uses componentized development, and it isolates the view from your model in the best manner I have seen til now in Java frameworks. It does not seem so intuitive in the beginning, because you code for a web application in a similar way as you would code a Swing application. Specifically the component’s event handling code in Wicket reminds me a lot of the approach used in Swing applications.

Being a new framework that went out of the Apache incubation just several months ago, you can’t expect great tooling support at this point. Drag and drop tools to design screens? Forget about it! Component options similar to JSF ones? You’re not gonna find it either. However, Wicket has a very active community and it’s evolving fast. The second book on Wicket will be avaiable in a few months and the number of users and successful implementations is growing steadily. The set of avaiable components is growing and it’s becoming much easier to find support in their forums.

As I said, I’m far from an expert in both frameworks, and I hope this year I’ll have a long enough exposure to them and probably in a few months I’ll have more valuable opinions. Something I think about is that perhaps knowing Wicket and JSF well can be really useful, because it doesn’t seem like we have a “one size fits all” choice here. Wicket seems great for a company to base its developments and have good and maintainable code that will be easy to build over for several years. JSF certainly can offer that too, but i find it tough to consider taglib code as easy to maintain. However, JSF offers such great components that even a Java developer like me with no talent to create good looking pages is able to generate a very decent user interface.

I’ll confess I have a natural preference for Wicket since the beginning, but I promise I’ll try to evaluate these 2 options without any passion during this year and later this year I’ll post again telling my conclusions (if any) 😉

Mylyn Trac Connector: accessing web task editor on Linux

janeiro 13, 2008

Atenção, este blog foi migrado para:

My friend Bairos provides me a Subversion repository and a Trac server, and I use both for personal projects.In my job, our issue tracker is JIRA, and I’m using it with Mylyn for several months. However, just recently i started using Mylyn with Trac, in a project I’m developing at home. The Trac server I’m using doesn’t have the XmlRpc plugin, so I’m not able to use Mylyn’s rich task editor with this server, and I faced some problems using the web task editor inside Eclipse on Linux.

Every time i tried to open the task editor, i was getting the following error message: “Could not create Browser page: XPCOM error -2147221164”. I’m not going to detail my analysis of this error, but I was able to fix it installing the packages xulrunner and xulrunner-gnome-support (I’m not sure if both are needed, though).

From my google searches, I could see that this error happens with a lot of applications on Linux, so probably several people using the Trac Connector with the web task editor on Linux faced the same problem. I hope this tip can help.

Just for the records, my environment here is: MEPIS Linux 7.0, Eclipse 3.3.1 with WTP, JDK 1.6.0_03 32 bits, Mylyn 2.2 and Trac 0.10.4

Problema de acesso ao Subversion resolvido

janeiro 13, 2008

Atenção, este blog foi migrado para:

Eu estava com um problema bem chato aqui no meu notebook. Eu utilizo em projetos pessoais o servidor Subversion do Bairos, e eu não estava conseguindo conectar lá a partir do note. Nas primeiras vezes em que isto ocorreu, era um fim de semana e eu achei que o servidor dele estava fora do ar, pois as tentativas de conexão estavam dando timeout.Após verificar com ele que o servidor estava ligado direto, cheguei a pensar que meu plugin do SVN no Eclipse (Subclipse) estava com algum problema. Tentei reinstalar o plugin e fiz até testes com o Subversive também. Nada funcionava. Eu estava achando muito estranho, pois do trabalho eu estava conseguindo acessar o servidor normalmente, com as mesmas configurações do plugin.

Hoje por sorte eu instalei o Limewire aqui no note, e apareceu uma mensagem dizendo que o software havia detectado um firewall na minha rede. Pronto, desconfiei na hora que este era o problema do meu acesso ao servidor. Como estou usando o MEPIS no note em vez do habitual Kubuntu, logo imaginei que as configurações padrão do firewall são diferentes entre as 2 distribuições.

O MEPIS oferece um software chamado Guarddog para gerenciar as regras do iptables, e acessando o mesmo eu pude ver que o tráfego TCP pela porta 81 (utilizada pelo servidor SVN do Bairos) não estava liberado. Criei uma nova regra, liberando explicitamente o tráfego TCP pela porta 81 e pronto, imediatamente consegui me conectar ao Subversion 🙂

Segue abaixo a imagem com a interface do Guarddog, que utilizei para definir a minha nova regra do firewall.


Como eu havia falado: nova distribuição, novos aprendizados. Agora já conheço um software bem amigável para gerenciar o iptables 😉

Entrevista com Robert Elves, do projeto Mylyn

janeiro 7, 2008

Atenção, este blog foi migrado para:

Nesta entrevista, falarei com Robert Elves, um dos principais committers do projeto Mylyn. Robert é uma peça chave no desenvolvimento do Mylyn e do Tasktop, e nós falaremos sobre estes projetos, Eclipse, processo de desenvolvimento de software e open source software. Vamos começar!

Bruno Pereira: Robert, como começou o seu envolvimento com o projeto Mylyn? Você tinha alguma experiência prévia com desenvolvimento de plugins do Eclipse?

Robert Elves: Meu caminho no Mylyn começou como um estudante de graduação no laboratório CHISEL na Universidade de Victoria. Eu estava pesquisando sobre locomoção em espaços de informação com foco em ajudar desenvolvedores de software. Durante este período eu desenvolvi o protótipo de um plugin para o Eclipse chamado NavTracks que utilizava o histórico de navegação de um editor para recomendar arquivos relacionados com o arquivo atualmente sendo editado.

Por volta desta época eu conheci Gail Murphy e Mik Kersten e aprendi o que era então o projeto Mylar, atualmente Mylyn. Logo após a graduação eu me juntei a eles no Laboratório de Práticas de Software na Universidade da Columbia Britânica para trabalhar no Mylyn.

BP: O Mylyn 1.0 foi lançado independentemente de outros projetos. Entretanto, a versão 2.0 foi parte do enorme lançamento do Eclipse Europa. Você poderia descrever esta experiência? Como este processo foi coordenado de forma que fosse possível que múltiplos projetos lançassem novas versões ao mesmo tempo e tudo se mantivesse compatível?

RE: Com o lançamento da versão 1.0 do Mylyn nós já podíamos ver as estatísticas de download crescer na ordem de dezenas de milhares por mês, e uma forte comunidade de usuários se formando em torno do projeto. Centenas de notificações de bugs nos ajudaram a amadurecer o Mylyn até um ponto em que ficou fácil o bastante para programadores que utilizam o Eclipse adotarem esta nova maneira de trabalhar com foco em tarefas. Nesta mesma época, o projeto de empacotamento do Eclipse nos contactou pedindo que incluíssemos o Mylyn nos downloads padrão do Eclipse.

Nós decidimos que a tecnologia estava pronta, concordamos com o pedido e desde então o Mylyn está disponível para todos os desenvolvedores que baixem o Eclipse Europa. Para participar da versão Europa, os projetos devem atender alguns padrões de maturidade. Por exemplo, nós tivemos que nos provar capazes de gerenciar um site de atualizações, lidar com a agenda de lançamentos e manter um contrato de API. Os requisitos para a próxima versão do Eclipse (chamada Ganymede) estão descritas aqui.

Mik liderou o projeto Mylyn para o cumprimento destes requisitos na versão Europa. Nós adotamos a disciplina necessária para atender aos marcos de lançamento simultâneos trabalhando ao mesmo tempo em ritmo frenético para atingir os objetivos de performance e usabilidade. Neste mesmo período, conseguimos realizar a mudança de nome do projeto de Mylar para Mylyn (que implicou na mudança de nome de todos os pacotes Java do projeto) e revisamos e aceitamos numerosos patches contribuídos pela comunidade. Os projetos foram coordenados com muita comunicação através de wiki e listas de discussão inter-projetos. Para resumir, esta experiência foi como estar dentro de um redemoinho e nós estamos ansiosos para mais diversões na versão Ganymede!

BP: De tempos em tempos eu fico impressionado com o aumento do alcance e escopo do Eclipse. Eu considero o projeto Eclipse um fantástico exemplo de como construir software. Com seu excelente modelo de componentes, ele oferece uma plataforma muito boa para se construir em cima. Como o Mylyn faz ótimo uso deste modelo de componentes, eu gostaria de saber das suas opiniões sobre isto.

RE: Na minha opinião, e tenho certeza de que o Mik concorda, Equinox e OSGi facilitam que desenvolvedores construam melhores sistemas de software. O framework nos dá um mecanismo de explicitamente separar o domínio do problema em plugins flexíveis que colaboram entre si. Você ganha deployment e carregamento sob demanda dos seus componentes praticamente de graça! Sem esta flexibilidade e plugabilidade, o Mylyn não existiria, pois não poderíamos plugar ao núcleo do Eclipse as funcionalidades que a interface focada em tarefas precisa estender. O Mylyn contribui e usa alguns pontos de extensão que permitem que muitas das visões padrão do Eclipse como Package Explorer e Synchronize passem a utilizar foco. Eu ainda não vi uma plataforma de ferramentas tão flexível como o Eclipse, e o Equinox/OSGi tem sido um incrível framework para se trabalhar.

BP: O Mylyn tem crescido e visto sua adoção por parte dos usuários do Eclipse aumentar constantemente. Junto com esta adoção, muitos bugs e solicitações de melhorias foram abertos e solucionados. Como vocês selecionam entre estas requisições o que vai entrar em cada versão?

RE: Desde a versão Europa, nós temos verificado crescente atividade na comunidade do Mylyn, incluindo mais notificações de bugs e solicitações de melhorias. Cada notificação de bug é revisada por um committer do Mylyn. É importante para nós responder em um tempo curto, pois cada solicitação representa uma aresta a ser aparada ou uma nova melhoria. Tendo dito isto, são apenas 4 committers no projeto, então nós precisamos fazer uma triagem com base nos pedidos da comunidade e também analisando como cada requisição se encaixa no plano geral (ver plano do Mylyn 3.0 aqui).

BP: Aqui no Brasil estamos vendo mais e mais empresas começando a abraçar metodologias e práticas ágeis de desenvolvimento, provavelmente com o Scrum liderando estas iniciativas. Eu gostaria que você descrevesse o processo de desenvolvimento de vocês e quão desafiador é fazer com que isso funcione tendo um time distribuído.

RE: Ágil é certamente como eu descreveria o nosso time, embora nós não adotemos nenhuma metodologia em particular. Nós temos reuniões de planejamento semanais e constantemente re-priorizamos solicitações com base nos pedidos da comunidade de uma forma que seja transparente para os usuários. O próprio Mylyn é uma de nossas ferramentas chave para uma colaboração de sucesso. Ele permite o compartilhamento do contexto das tarefas e a funcionalidade de notificação de novos pedidos realmente ajuda a minimizar a sobrecarga das caixas de e-mail, ao mesmo tempo em que aumenta a ciência do time sobre o que está ocorrendo. Nós tentamos manter todas as discussões de projeto nos reportes de bugs (em vez de utilizar Skype ou algum IM) para que as decisões de projeto fiquem disponíveis para que outros membros dos time e pessoas interessadas possam revisá-las assincronamente. Este sistema certamente não é perfeito e nós estamos sempre procurando maneiras de melhorar e otimizar o processo.

BP: O Mylyn foi integrado com algumas ferramentas de controle de tarefas, está disponível em um amplo conjunto de distribuições do Eclipse e está sendo constantemente refinado por solicitações de usuários e feedback dos mesmos. Eu recentemente soube que vocês estão trabalhando em uma nova ferramenta chamada Tasktop, que é relacionada ao Mylyn. Você poderia dar uma visão do futuro do projeto Mylyn e dizer o que o Tasktop trará aos usuários?

RE: Mylyn continuará evoluindo tanto como uma ferramenta quanto como um framework para interface focada. A Tasktop Technologies lidera e suporta o projeto Mylyn. Alguns dos commiters do Mylyn são nossos contratados e cada um de nossos desenvolvedores contribui regularmente com patches no Mylyn.

No ciclo da versão 3.0 você pode esperar a mesma taxa de melhorias de usabilidade, integração e performance mantida entre as versões 2.0 e 2.2, lançada recentemente. Para oferecer aos usuários estas muitas melhorias, nós ofereceremos versões finais a cada trimestre. Alguns pontos-chave para se acompanhar nas futuras versões 2.3 e 3.0 são as grandes evoluções no editor de tarefas (que é um ponto focal de interação dos desenvolvedores com o Mylyn) e a adição de um leve workflow de integração para reduzir a quantidade de cliques exigida dos usuários.

O produto Tasktop estende o alcance do Mylyn para além do workspace do Eclipse e atinge o sistema operacional (atualmente apenas o Windows, mas o Mac será suportado ainda no primeiro trimestre de 2008). Com o Tasktop, o tempo gasto em outras aplicações como o Word ou Excel é capturado como sendo parte da tarefa atual. Janelas externas de aplicações são gerenciadas de forma semelhante ao que é feito com editores dentro do Eclipse. Além disso, o Tasktop é capaz de sincronizar com os calendários do Outlook e do Google, dando aos usuários uma visão geral do cronograma de suas tarefas dentro das suas aplicações nativas de calendários. Mas a melhor parte é que o Tasktop foca toda a sua navegação na internet. Agora eu posso navegar e utilizar aplicações na web dentro da área de trabalho do Eclipse com o mesmo foco que o Mylyn traz para as minhas atividades de programação. Confira o site para obter a versão beta.

BP: Mensagem final…

RE: É ótimo saber do interesse no Mylyn vindo da comunidade de desenvolvedores do Brasil. Eu encorajo nossos leitores a tentar usar a ferramenta caso ainda não o tenham feito. Além disso, sintam-se à vontade para ajudar a colaborar com o Mylyn submetendo notificações de bugs ou contribuindo com patches. Nós somos bastante abertos à contribuição da comunidade!

The Mylyn’s missing feature that would make me advocate it instead of just suggesting it

novembro 24, 2007

Atenção, este blog foi migrado para:

First a little disclaimer: I really like Mylyn and find it one of the most useful and certainly one of the most innovative development tools ever. I am using it for quite some time and started using its version 2.x since the JIRA Connector started working correctly with ISO-8859-1 againHowever, there is something in the use of Mylyn that I would really like to be customizable. I thought that maybe I would get used to the default plugin behavior after some time using it, but unfortunately it didn’t happen for me and for most of my working mates.

I would like to be able to configure Mylyn’s task context management so that files are added to the task context only when saving them, instead of adding at the time the file is opened.

For example, very frequently when developing some new feature I open some files that are not related to the current task just to see how something was implemented on some other class or file. I don’t want to have this file I just opened added to the context. I want to be able to add to the context only the files I actually changed during the task activity.

As I don’t know if this is a common desire among Mylyn’s users in general, the ideal solution would be to have the configuration option of adding files to task context at opening or only when saving the files.

As i said I can’t speak for Mylyn’s users in general, but at least here at (where we have 100-200 Java developers) most of the guys who used Mylyn had the same opinion.

I have already requested this enhancement at Mylyn’s Bugzilla, and I would really appreciate having a nice feedback on that, telling if this could be done in the future, if it’s too complicated, if it’s just a misuse of the tool, et cetera.

I have previously talked directly to Mik and Eugene regarding the JIRA Connector and their response exceeded the best expectations I could have. So, in this humble space of mine, I would like to receive some feedback on this new feature I am requesting. I can assure that it would take my Mylyn satisfaction to an even higher level and it would turn a reasonable bunch of users into very happy advocates of this great tool, starting with me 😉