Bruno Pereira

Com a minha mudança de alocação da Globo.com para a Globosat, continuo trabalhando bastante com integração de aplicações, mas agora com um ferramental e paradigmas diferentes.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

Algum tempo atrás o Fabiano me perguntou qual implementação de persistência em Java eu julgava a melhor opção. Na época conversamos um pouco sobre isso e eu estava para escrever sobre o assunto faz tempo.

Essa semana falei novamente sobre o assunto numa thread do CEJUG e então vou finalmente expôr algumas opiniões por aqui.

Provavelmente a implementação de persistência que está mais “na moda” atualmente é a Java Persistence Architecture (JPA) ou frameworks independentes com a mesma proposta, como o Hibernate e o Toplink. Realmente a proposta desta tecnologia é excelente. Quem programa usando orientação a objetos de verdade sempre prefere manipular classes de domínio ricas, e não gosta muito de lidar com as diferenças de paradigma que existem entre este modelo e o modelo relacional de bancos de dados.

A JPA aparentemente é bem fácil de usar, colocando anotações para mapear as classes e atributos em tabelas e colunas do banco de dados e colocando algumas anotações para declarar os relacionamentos entre as entidades. O problema que eu vejo é que as anotações de JPA são um tanto confusas. Em algumas situações você vê uma quantidade razoável de opções, e não fica tão óbvia a forma que você tem que usar as anotações.

Além disso, o esforço de analisar o comportamento da JPA é muitas vezes considerável. Você não escreve as queries, mas precisa acompanhar muito bem as queries que estão sendo geradas, se está sendo feito JOIN ou múltiplas queries, etc. Esse tipo de coisa a JPA abstrai da gente, mas muitas vezes os comportamentos não são triviais, e o esforço de monitorar isso não é desprezível. Uma anotação mal colocada pode te trazer problemas graves de performance e alguns dias de análise para otimização.

Eu gosto bastante da idéia de frameworks de mapeamento objeto-relacional. Quem trabalha verdadeiramente com orientação a objetos sempre quer ter a comodidade de usar este paradigma na aplicação toda. Entretanto, essas opções que temos em Java são complexas e muitas vezes não trazem ganhos de produtividade comparando com alternativas como o Ibatis por exemplo.

A parte mais chata da persistência em Java é escrever o código JDBC de gravação de objetos no BD e recuperação dos mesmos. Aqueles tratamentos altamente repetitivos e trabalhosos de conversão de colunas do BD de diferentes tipos para seus atributos das classes. Eu odeio escrever esse tipo de código, e o Ibatis ajuda demais nesse sentido, sem introduzir complexidade.

Uma coisa positiva que eu vejo no Ibatis é que ele é bem simples de usar e muito óbvio e previsível. Você manipula as coisas com o paradigma relacional, que embora tenha seus defeitos é amplamente conhecido de todo mundo e fácil de manipular. Usamos a DSL que é provavelmente a mais bem-sucedida até hoje (SQL).

A implementação de mapeamento objeto-relacional do Django (framework Python) por exemplo é excepcional, extremamente inteligente e produtiva. Muito dificilmente trocaria ela pelo Ibatis (assumindo que trocar fosse uma opção). Mas já há algum tempo eu estou desiludido com a JPA e vejo o Ibatis como uma opção com melhor custo-benefício.

Em situações em que o time todo domina plenamente JPA e já têm uma boa experiência com a mesma, é possível que o time ganhe um pouco de produtividade ao usá-la. Entretanto, em muitas situações o custo-benefício pode ser pior do que usar o Ibatis.

Já presenciei alguns casos em que a adoção de JPA em diferentes equipes prejudicou mais do que ajudou.  Os principais motivos para isso foram:

• Falta de experiência geral do time com a tecnologia
• Modelos legados de BD que não permitem um mapeamento de classes tão interessante
• Grande esforço de tunning

Eu e outros profissionais que eu respeito muito já passamos por esse tipo de situação, em que acabou prevalecendo o pragmatismo e a visão do que é valor para o negócio.

Eu li uma entrevista com o Carlos Ghosn (o brasileiro presidente da Renault e Nissan) na qual ele falou que a Nissan passou a ter bons resultados quando os engenheiros pararam de colocar ítens que eles achavam “bonitos” nos projetos, mas que os usuários nem percebiam. O argumento era mais ou menos esse: o usuário quer que o carro funcione bem, não importa para ele se o revestimento do motor vai ser de adamantium e resistente a criptonita

Decisões técnicas devem ser tomadas com foco no valor de negócio, em vez de focar na tecnologia que ficará mais bonita no currículo. Não esqueçam do exemplo do Carlos Ghosn

O InfoQ publicou uma discussão interessante sobre a escolha de perfis em um time ágil. Nesta discussão, alguns defendem que um time formado somente por especialistas seria mais performático do que um time formado somente por generalistas. Outros defendem a escolha de especialistas somente em último caso. Existem também os que defendem o meio termo.

Eu tenho uma opinião semelhante à do Scott Ambler:

One approach is to build a team with some people who are generalists and some who are specialists, the generalists provide the glue within the team and focus on the bigger picture whereas the specialists focus on the detailed complexities of your project. This works well because the strengths of generalists balance the weaknesses of specialists and vice versa, and it is often quite useful for a generalist to pair with a specialist because of this balance. A better approach would be to build a team comprised of people who are generalists with one or two specialties — generalizing specialists.

Eu acho que é legal ter um time equilibrado, onde os especialistas aos poucos vão melhorando habilidades diferentes de sua área principal. Não acho que necessariamente começar um time com especialistas seja uma má decisão, contanto que se estimule a versatilidade. Depois de algum tempo, especialistas multi-disciplinares podem aprender bastante uns com os outros e formar um time de excelente nível, com todos melhorando seu nível geral.

Eu particularmente estou numa fase em que estou tentando aprender bastante sobre áreas nas quais eu ainda não sou tão forte como gostaria (a área de client side por exemplo). Acredito que o mais importante é o sentimento de humildade quanto aos nossos conhecimentos e o desejo de sempre estar melhorando. A decisão de qual caminho traçar vai depender das estratégias e escolhas pessoais de cada um, mas a humildade e a busca pela melhora constante devem estar sempre presentes.

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto “fraco” do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos “Web 2.0″. O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de “Livros que quero ler quando tiver tempo”, mas já o movi para a lista de livros que li

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve

Essa semana eu troquei umas idéias com o Bairos sobre Scrum, e após acompanhar as discussões no post do Guilherme pensei ainda mais sobre o assunto deste post.

Eu já conheci inúmeros casos de profissionais que saíram da linha de desenvolvimento para assumir papéis gerenciais. Deixam de lidar diariamente com atividades técnicas para lidar com coisas mais ligadas à organização dos projetos, definição de estratégias, planejamento, etc. Em alguns casos as pessoas de fato desejavam esta mudança de atividades. Depois de desenvolver por alguns anos algumas realmente “enjoam” de atuar com desenvolvimento e preferem abraçar o caminho da gerência. Já em outros casos esta “escolha” na verdade não é um anseio autêntico do profissional, mas uma alternativa que ele inevitavelmente adota para poder continuar crescendo na carreira, ter mais responsabilidades, mais reconhecimento e mais grana.

Com a adoção do Scrum, freqüentemente o antigo líder técnico da equipe assume o papel de Scrum Master. Pela definição da metodologia a responsabilidade principal deste papel é a de eliminar impedimentos do time, e garantir que este tenha as melhores condições possíveis de trabalho para poder produzir bem. Isto acarreta numa mudança significativa para o líder técnico. Ele vai sair das “trincheiras” para ajudar o time a chegar da melhor forma possível ao final dos sprints. Seu contato com a arquitetura e desenvolvimento dos produtos inevitavelmente vai diminuir bastante, pois isto é responsabilidade do time.

O Scrum nos trouxe uma nova faceta para o fenômeno recorrente do profissional com alta capacidade técnica que muda seu perfil de atuação para atingir maiores objetivos de carreira e finanças. Sim, porque em todos os casos que já vi o Scrum Master é superior hierarquicamente na empresa que todos os integrantes do time, com raras exceções. Sendo assim, a escolha entre fazer parte do time ou ser o Scrum Master não tem muita margem para dúvida. Assumindo que a diferença financeira entre ser um membro sênior do time e ser o Scrum Master esteja na faixa de uns 30 a 40%, raros serão os indivíduos que irão decidir-se por continuar no time, se tiverem a opção de escolher. Certamente a grande maioria dos líderes técnicos é formada por profissionais que gostam muito de software, e renovam sempre seu interesse por novos desafios técnicos. Entretanto, todo mundo gosta e precisa de dinheiro, e isto obviamente pesa muito nas decisões.

Na teoria eu sou líder de equipe da Concrete, mas como atuo em tempo integral na Globo.com, sou parte de um time de Scrum. Isto quer dizer que provavelmente se eu estivesse alocado dentro da Concrete em um projeto com Scrum, eu seria o Scrum Master. Entretanto, na Globo.com eu faço parte de um time, e atuo bravamente nas trincheiras do desenvolvimento. Considerando essa dualidade da minha situação, eu penso bastante sobre estas questões do Scrum, e o que ele representa na carreira de um profissional de software.

Eu gosto muito de produzir software, e no horizonte que se apresenta à minha frente existem inúmeros desafios técnicos que eu ainda quero enfrentar. Estou longe de querer me afastar do contato técnico intenso que tenho a oportunidade de ter atualmente. Um exemplo que me vem à cabeça é o do Joshua Bloch. Eu nem sei qual é o processo de desenvolvimento que ele usa no Google e qual é o seu cargo oficial lá. Mas sei que ele é um dos caras mais sinistros que já trabalharam com Java e a experiência que ele acumulou em vários anos de desenvolvimento deve ser um ativo extremamente valioso para o Google. Tenho certeza que ele deve ganhar muito mais que a média dos gerentes de projeto de TI nos Estados Unidos. Ele é um fora de série, e é tratado como tal. Considerando um exemplo como o dele, será que vale mais para o Google deixá-lo intimamente ligado com desenvolvimento ou colocá-lo em funções talvez mais estratégicas? Será que os profissionais de ponta de tecnologia têm realmente espaço para continuar crescendo na área técnica ou é de fato inevitável uma mudança para papéis gerenciais em troca de mais responsabilidade e mais de L’Argent?

Considere um horizonte de vários projetos interessantes e desafiadores tecnicamente pela frente para você atuar. Suponha também que você vai poder escolher entre fazer parte do time que vai entregar estes produtos ou ser o Scrum Master dos projetos. E finalmente suponha que você vai ganhar exatamente a mesma coisa se escolher atuar no time ou atuar como Scrum Master. O que você escolhe?

Certamente eu posso e talvez mude de idéia no futuro, mas com o enorme tesão técnico que eu ainda tenho e com a quantidade enorme de desafios que eu ainda quero vencer “nas trincheiras”, pelo menos durante alguns anos eu faria parte do time. Tudo bem, eu ainda sou relativamente jovem (26 anos), ainda não sou casado (mas não falta muito) e não tenho filhos. Certamente a mudança das variáveis desta equação poderia mudar muito o meu ponto de vista. Mas por enquanto, considerando as suposições que eu falei, eu seria um orgulhoso combatente nas trincheiras, e continuaria me empenhando ao máximo para entregar software “do estado da arte”. Just my 2 cents

Since I returned from my trip to Argentina and Chile, I’ve been pretty busy at work and when I get home at night. I’m writing an article on web services (more on that in February…) and got a small freelance project to do.Sometimes it’s kinda hard to produce well at night after a tiresome day at work, but a long time ago I discovered my powerful elixir of productivity at night For those of you who do not know me personally, although I’m rather eclectic regarding music, I’m a brave heavy metal fan at heart
When I must start high octane mode at 9 PM, I usually start listening to a power metal set, composed mostly by some finnish bands I love. This year, I’ve been listening to Sonata Artica, Nightwish and Stratovarius most of the time. These bands have some very addictive songs, and the high speed drums combined with the talent of their singers (as for Nightwish, I’m refering to the Tarja Turunen epoch) give me my much needed energy.

Tony Kakko, Tarja Turunen and Timo Kotipelto are really great singers and exceptional live performers.Unfortunately, I never had the chance of going to a Sonata Arctica gig, but I went to Nightwish and Stratovarius gigs in the past and it was awesome. I really like to listen to their live performances, and fortunately You Tube offers a very rich collection of everything you want to listen, so I recently created a playlist there.

For those of you who want to make use of my powerful elixir of productivity boost, the playlist can be accessed here. Long live heavy/power metal! Have fun!

In this interview, i’ll be talking to Robert Elves, one of the main committers from Mylyn project. Robert is a key piece in both Mylyn and Tasktop developments, and we’ll talk about these projects, Eclipse, software development process and open source software. Let’s begin!

Bruno Pereira: Robert, how did you get involved with the project? Did you have any prior contact with Eclipse plugin development?

Robert Elves: My road to Mylyn started as a grad student in the CHISEL lab at the University of Victoria. I was researching locomotion in information spaces with a focus on helping software developers. During this time I developed a prototype plug-in for Eclipse called NavTracks that used past editor navigation to recommend files related to the current file being edited.

Around this time I met Gail Murphy and Mik Kersten and learned of what was then the Mylar project, now Mylyn. Shortly after graduation I joined them in the Software Practices Lab at the University of British Columbia to work on Mylyn.

BP: Mylyn 1.0 was released independently from other projects. However version 2.0 was part of the huge Eclipse Europa release. Could you describe this experience? How was this process coordinated in order to have multiple projects releasing new versions at the same time and keeping everything compatible?

RE: With the 1.0 release of Mylyn we were already starting to see increasing download stats in the order of tens of thousands a month, and a strong early adopter community forming around the project. Hundreds of bug reports helped us harden the Mylyn to the point where it became easy enough for many Eclipse-based programmers to adopt this new task-focused way of working. Around that same time, the Eclipse Packaging Project contacted us, asking to include Mylyn in the default Eclipse downloads.

We decided that the technology was ready, agreed, and since then Mylyn has been available to all developers downloading Europa. To participate in the Europa release, projects must meet a number of maturity standards. For example, we needed to prove capable of managing an update site, handling the release schedule, and maintaining an API contract. The requirements for the next simultaneous release, Ganymede, are outlined here.

Mik lead the Mylyn project through these ‘must dos’ to Europa. We adopted the discipline required to meet Europa release chain deliverables while working at a frenetic pace to implement performance and usability objectives. Concurrently we managed to do a complete rename of the project from Mylar to Mylyn and review and accept numerous patches contributed by the community. Projects were coordinated with a lot of communication via wiki and the cross projects mailing list. To sum it up it was a great whirlwind experience and we’re looking forward to more excitement with Ganymede!

BP: From time to time I’m amazed at how Eclipse is expanding its reach. I find the Eclipse project to be a fantastic example of how to build software. With its great component model, it provides a very good platform to build on. As Mylyn makes great use of this component model, I’d like to know your opinions on that.

RE: In my opinion, and I’m sure Mik would agree, Equinox and OSGi make it easier for developers to build better software systems. The framework gives us a mechanism for explicitly separating the concerns of the problem domain into flexible contributing plug-ins. You get runtime deployment and lazy loading of your components practically for free! Without this flexibility and plug-ability, Mylyn wouldn’t exist, because we could not plug into the core Eclipse facilities that the Task-Focused Interface needs to extend. Mylyn contributes and uses a number of extension points enabling the focusing of many of the standard views in Eclipse such as the Package Explorer and Synchronize view. I’ve yet to see a tool platform as extensible as Eclipse, and Equinox/OSGI has been an amazing framework to work with.

BP: Mylyn has been growing and seeing increased adoption by Eclipse users. Along with this adoption there have been many bugs and enhancement requests opened and resolved. How do you pick the bugs and decide what’s going to make it into each release?

RE: Since the Europa release, we’ve seen increased activity in the Mylyn community including more bug reports and enhancement requests. Each report is reviewed by a Mylyn committer. It is important to us to respond in a timely manner as each represents a rough edge or new enhancement request. That said there are only four committers so we carefully triage the bug reports with respect to number of votes from the community, severity, and how each bug fits into the overall plan (See Mylyn 3.0 plan here).

BP: Here in Brazil we are seeing more and more companies starting to embrace agile methodologies and practices, with Scrum probably leading the field. I’d like you to describe your development process, and how challenging is it to make it work having a distributed team.

RE: Agile is certainly how I would describe our team although we don’t strictly adhere to any one particular methodology. We do have weekly planning meetings and constantly re-prioritize bugs based on community feedback in a way that is transparent to our user community. Mylyn itself is one of our key tools to successful collaboration. It enables sharing of task context and the incoming notification on bug reports really helps minimize inbox overload while increasing team awareness. We try to keep all design discussion on bug reports (vs. Skype or other IM chat channels) so that design decisions are available for other team members and interested parties to review asynchronously. Our system is certainly not perfect and we are always looking for ways to improve and streamline our process.

BP: Mylyn has been integrated with a lot of issue trackers, is available on a wide set of Eclipse distributions and is constantly being enhanced by user requests and feedback. I recently heard that you guys are working on a new tool called Tasktop, which is related to Mylyn. Could you provide a vision of the future for the Mylyn project, and what Tasktop will bring to users?

RE: Mylyn will continue to evolve as both a tool and focused-ui framework. Tasktop Technologies leads and supports the Mylyn project. We employ a number of the Mylyn committers, and each of our developers regularly contribute patches to Mylyn.

In the 3.0 cycle you can expect to see the same rate of usability, integration, and performance improvements that we have maintained through the Mylyn 2.0 and into the recent 2.2 release. In order to make the many improvements that show up in our New & Noteworthy documents available to the Eclipse community as soon as possible, we provide GAs of Mylyn quarterly. Some key stuff to look out for in the upcoming Mylyn 2.3 and 3.0 is major improvements to the task editor, which is a focal point of interaction for developers using Mylyn, and addition of light-weight workflow integration to reduce developer click path.

The Tasktop product extends the reach of Mylyn beyond the workspace to the operating system (currently Windows only with Mac support 1st quarter 2008). With Tasktop, your time spent in other applications such as Word or Excel is captured as part of the active task. External application windows are managed similarly to how Mylyn can manage editors within Eclipse. Additionally Tasktop synchronizes with Outlook and Google Calendars giving users an overview of their task schedule from their native calendaring applications. But the best part is that Tasktop focuses all of your web browsing activity. I can now browse the web and use web based applications all from within the Eclipse workbench with the same focus that Mylyn brings to my programming activities. Check out the site to get the beta.

BP: Closing thoughts?

RE: It is great to hear of interest in Mylyn from the Brazilian developer community! I encourage your readers to try the tool if they haven’t already. Also, feel free to help evolve Mylyn by submitting bug reports or contributing patches. We are very open to community contribution!