Grails – ótima ferramenta para alguns projetos

abril 19, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 🙂

Anúncios

Scrum Master x Líder Técnico: nova faceta de um fenômeno recorrente

abril 7, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 😉


Elixir of productivity boost

janeiro 20, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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!


Interview with Robert Elves, from Mylyn Project

janeiro 7, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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!


Entrevista com Robert Elves, do projeto Mylyn

janeiro 7, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 Power of One

dezembro 18, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

O título deste post é o nome de uma música do Sonata Arctica, uma das minhas bandas de metal preferidas. Entretanto, não é sobre música que vou falar agora.Este título significa também o poder de um indivíduo. Sendo um engenheiro eletrônico e de computação, e atualmente um profissional de software, eu já estudei e me deparei com diversas obras científicas fabulosas. Ao estudar química pude me fascinar com o legado de Rutherford e Bohr. Ao estudar física clássica, impossível não se impressionar com o trabalho de Isaac Newton. E claro, ao falar de Newton, precisamos falar de seu predecessor, Galileu Galilei. Nas matérias do ciclo básico de engenharia, um desenvolvimento matemático incrível por James Maxwell. Neste mesmo contexto, o trabalho de Lorentz se somou ao de Maxwell na preparação dos fundamentos teóricos e dos questionamentos que seriam respondidos por Einstein durante a sua absolutamente brilhante carreira. Bom lembrar, Einstein fez boa parte de suas formulações mais importantes como “experiências de pensamento”. Ele chegou a conclusões impressionantes e altamente revolucionárias em sua época fazendo experiências de pensamento. Claro, depois isto foi ter comprovação experimental, caso contrário ele não teria se tornado o mito que se tornou.

Pois bem, Einstein no ano de 1905 publicou 4 obras de suma importância na história da ciência. Talvez as 2 mais relevantes sejam a do efeito foto-elétrico e a lei da relatividade especial. Não vou entrar em maiores detalhes sobre nenhuma das 2, mas eu até lembro-me razoavelmente bem disso, pois essa era uma das cadeiras mais difíceis do curso. Em 1905 Einstein fez 26 anos. Dia 30 de outubro de 2007 eu completei 26 anos. Claro, não vou cair na asneira de querer comparar nada do que eu faço com a obra dele, senão eu não chegaria a conclusões muito boas a meu respeito 🙂 Porém, uma coisa é importante de se pensar. Aos 26 anos este sujeito publicou 4 obras das mais relevantes na história da física. E nesta época ele ainda era um belo ninguém. Estava longe do prestígio que viria alcançar posteriormente.

Da mesma forma que na área da engenharia e outras ciências exatas, a história da computação também teve já seus fenômenos. Peguemos a obra de Linus Torvalds. Criou em seu tempo vago o que hoje é o Linux que muita gente já conhece. No começo da história do Linux um camarada chamado Alan Cox implementou boa parte da camada de rede do sistema operacional. É simplesmente chocante constatar a produção destes 2. Passemos ao Roy Fielding. O cara foi o principal líder da especificação do HTTP,propôs em sua tese de doutorado o Representational State Transfer (REST, estilo de arquitetura de web services) e foi um dos fundadores da Apache Software Foundation. Shawn Fanning, um moleque de 19 anos criou o Napster no começo de seu curso de computação. Erich Gamma e Kent Beck produziram o Eclipse e são verdadeiros mitos em desenvolvimento de software. Não é possível listar todos os exemplos, pois são inúmeros.

Em comum dentre todos estes exemplos citados está a diferença que um indivíduo fez. Um indivíduo que poderia ter se recolhido à sua insignificância e ter tido uma carreira de sucesso mas sem brilho. Entretanto, estas pessoas citadas tiveram iniciativa e acreditaram no seu poder de causar impacto, realizar mudanças e estabelecer uma obra.

Isto é algo que me fascina, e que me faz refletir com freqüência. Ok, eu posso estar longe da capacidade intelectual dessa turma. Estamos falando de verdadeiros gênios. Porém, será que eu não sou capaz de deixar uma obra também, um legado interessante? Este questionamento incendeia a minha mente. Vendo a beleza e perfeição de algumas obras como estas, me contentarei em apenas fazer o que qualquer outro poderia fazer?? Não! Posso não conseguir chegar a lugar algum de destaque, mas o que há de inquietação científica e de paixão por software aqui dentro de mim não me deixará jamais me contentar em fazer feijão com arroz e me limitar a o que não pode deixar a minha marca registrada.

Hei de tentar! Hei de lutar bravamente e perseguir o que a minha inquietação me mandar buscar! Um fator importantíssimo é acreditar que cada um de nós, um indivíduo sozinho, tem poder de mudar muito. Tem poder de revolucionar. Basta não se calar e tentar com seu melhor esforço! De uns tempos para cá, venho acreditando cada vez mais no poder que temos individualmente, e sabendo disso, não ficarei satisfeito em pensar que não saí do lugar-comum, que não fiz nada que deixasse a minha marca pessoal.

Eu tentarei com todas as minhas forças responder aos meus questionamentos interiores e alcançar um patamar do qual eu venha a me orgulhar no final da minha estrada! Não tenho absolutamente nada contra chefs de feijão com arroz. Respeito muito as individualidades e crenças de cada um, afinal a busca pela felicidade tem um caminho específico para cada indivíduo. Entretanto, a minha história terá que ser traçada com desafios intelectuais e atividades que fascinem a minha mente. Não consigo me deparar com tantos tópicos estimulantes e deixá-los passar. Eu quero participar, viver desafios e conquistar vitórias e aprender com fracassos, mas sempre ciente de que participei com o melhor que tenho!

That’s the fuel that feeds the fire inside me. What’s the fuel burning inside thee? Is it burning at all?? Don’t let your fire fade away!


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: http://brunopereira.org

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 Globo.com (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 😉