Marco Mendes´s Blog

Europa foi uma das várias mulheres de Zeus (Júpíter) na mitologia greco-romana. Em homenagem ao planeta, a segunda maior lua de Júpiter foi batizada de Europa.

Europa também é o nome do novo projeto Eclipse, assim como Callisto (outra lua de Júpiter e outra de suas mulheres), compilação de uma linha de base com 11 projetos no Eclipse 3.2.

Seguindo a idéia do projeto Callisto, o Eclipse continua em um processo de coordenação de múltiplos projetos em um linha de base cada vez mais madura e profissional. Neste lançamento, temos 21 projetos compilados em uma linha de base sobre o Eclipse 3.3.

Os projetos são:

• AspectJ Development Tools (AJDT) 1.5
• Business Intelligence and Reporting Tools (BIRT) 2.2.0
• Buckminster 0.1.0
• C/C++ Development Tools (CDT) 4.0
• Data Tools Platform (DTP) 1.5
• Device Software Development Platform - Device Debugging (DSDP.DD) 0.9
• Device Software Development Platform - Target Management (DSDP.TM) 2.0
• Dynamic Languages Toolkit (DLTK) 1.0
• Dash (Eclipse Monkey) 1.0
• Eclipse Communication Framework (ECF) 1.0.0
• Eclipse Platform, JDT, PDE and Equinox 3.3
• Eclipse Modeling Framework (EMF) 2.3
• Eclipse Modeling Framework - Query, Transaction, Validation (MQ, MT, VF) 1.1
• Graphical Editing Framework (GEF) 3.3
• Graphical Modeling Framework (GMF) 2.0
• Model Development Tools (MDT) 1.0
• Model to Text (M2T) - JET 0.8
• Mylyn 2.0
• SOA Tools Platform (STP)
• Test and Performance Tools Platform (TPTP) 4.4
• Web Tools Platform (WTP) 2.0

Sem dúvida, a grande vedete deste lançamento é o WTP 2.0 (Web Tools Platform), que traz importantes ferramentas visuais para suporte a JPA , JSF e projetos completos Java EE 5.0. Temos, por exemplo, um editor visual drag and drop para JSF.

Apesar disto, faço minhas apostas em outros projetos que ainda não tem tanta expressão, mas que prometem bastante.

• STP - SOA Tools Platform - Embora ainda em processo de maturação (0.6), este projeto irá ofertar uma infra-estrutura para o desenvolvimento de projetos de arquiteturas orientadas por serviço. Esta versão inicial traz já uma amostra do potencial do Eclipse para suporte a SOA.
• MyLyn - Um projeto simples, mas excepcionalmente interessante. O MyLyn é uma ferramenta para micro-gerência de projetos e sucede o projeto Mylar, do qual escrevi um blog aqui há algum tempo. O MyLyn permite que uma pessoa controle o tempo gasto nas suas tarefas ou nas tarefas do seu time, bem como fazer o controle de ciclo de vida de atividades, defeitos, melhorias e outros tipos de ocorrências, integrado ou não a itens de configuração do Eclipse (códigos, arquivos, modelos e outros elementos de projetos). O MyLyn deve permitir que desenvolvedores, líderes técnicos e mesmo gerentes consigam implementar conceitos de gerência e agile management de forma bastante transparente e não intrusiva.
• ECF - O Eclipse Communications Framework traz para o Eclipse ferramentas colaborativas, mensagens e comunicação ponto a ponto. Ele segue uma tendência da tecnologia Jazz, que promete revolucionar a forma como times colaboram para desenvolver projetos. Mais informações sobre o ECF podem ser achadas aqui, embora esta tecnologia ainda deve se tornar mais estável (assim como o STP) na versão Eclipse 2008, chamada Ganimedes.

Mais informações sobre o Europa podem ser achadas aqui:

• Página principal: http://www.eclipse.org/europa
• Revisões: http://www.eclipse.org/europa/europareviews.php
• Personalização do Europa: http://www.eclipse.org/downloads/moreinfo/custom.php

Quem é Ganimedes? Mais uma mulher de Zeus? Em verdade, Ganimedes era um cara, mas Zeus não perdoava ninguém e se apaixonou por ele (Wiki-Ganimedes). Em tempo, Ganimedes também é mais uma lua de Júpiter. Em 2008 escrevo um blog sobre ele!

Publiquei no site da Amazon uma lista de livros para o desenvolvedor que queira aprender sobre Java SE e EE. Adicionei para cada livro alguns comentários e observações da nossa experiência de sala de aula e do mundo real sobre como estudantes e profissionais aprendem Java.

A lista completa está aqui:

• Livros comentados sobre Java SE

• Livros comentados sobre Java EE

Primeiro artigo da série: PSP para Leigos

Você chega para trabalhar as 8:30. Examina a sua lista de tarefas do seu projeto alvo, cujo número está em cinco tarefas abertas. De forma entusiástica, você começa a examinar a primeira tarefa.

As 8:45, o telefone toca. Você é chamado para uma reunião sobre um problema residual de um outro projeto. Você fica nesta reunião até as 10:00.

Às 10:10, o seu colega do lado o chama para resolver um complicado problema de depuração. Mais vinte minutos se passam sem que você se dê conta.

Você consegue retornar para o seu projeto, mas somente até 11:00. Neste momento um cliente telefona e interage com você por mais quinze minutos.

Às 11:15, você para ler apenas 3 ou 4 emails - afinal, ninguém é de ferro. Infelizmente você precisa responder dois deles e gasta mais vinte minutos.
…
As 18:00, você está estressado e cansado. A sua lista de tarefas ainda está com 4 tarefas em aberto, e o seu tempo foi dragado por vilões invisíveis. Infelizmente você apropria no seu timesheet 8 horas no seu projeto original, vai para casa desaminado e pensa: “Para onde foi o meu tempo?”.

Se você já viveu o sintoma acima, você realmente trabalha com desenvolvimento de software. Neste trabalho, o volume de interrupções é enorme e se não tivermos ferramentas para gerenciar o nosso tempo, não temos ciência sobre a nossa real produtividade.

Um dos objetivos do PSP é aumentar a nossa produtividade. Isso somente é possível através de medição. A primeira lei da gerência é: “Não se gerencia o que não se mede”. O PSP, então, trabalha fortemente a auto-gerência do tempo, i.e, mecanismos onde você irá vigiar o seu tempo rigorosamente para saber o que você faz durante um típico dia de trabalho.

O Mylar, plugin gratuito para o Eclipse, permite que você faça este controle exigido pelo PSP. Isso é realizado através do conceito de tarefas pessoais (Personal Task). Dentro do Eclipse com este plugin já instalado, você tem a possibilidade de criar uma lista de tarefas, como mostrado na figura abaixo:

Um característica interessante deste plugin é que voce pode ativar uma tarefa. Basta clicar com o botão direito em uma tarefa e clicar “Activate”. Ao realizar este processo, o Mylar usa o mecanismo de instrumentação do Eclipse e começa a contar (em minutos e segundos), quanto tempo você está gastando naquela tarefa. Se um telefone tocou, se você parou para lanchar, se você foi interrompido por outro evento, você apenas precisa se lembrar em clicar sobre a tarefa com o botão direito novamente e clicar em “Deactivate”. A contagem é interrompida e você pode retomá-la a qualquer instante ou ativar uma outra tarefa.

Em qualquer instante, você pode examinar quanto tempo você ainda possui em uma tarefa ou quantos minutos já foram decorridos. No exemplo acima, 2:34 minutos já foram gastos da tarefa “Implementar Tela - Cadastro de Correntista”.

Um uso não intrusivo do Mylar, para quem nunca trabalhou com o paradigma de programação focada em tarefas, é usá-lo apenas para os eventos maiores de um dia (ex: Almoços e Reuniões). Um efeito interessante, em médio prazo, é perceber que o seu dia típico de trabalho não possui 8 horas (o que é senso comum). Você talvez descubra que o seu dia típico no seu projeto seja de 7, 6 ou mesmo 5 horas. Este número é rico e deve ser reportado à sua gerência para a criação de cronogramas mais realistas.

Estudiosos de medições de projetos, como por exemplo Capers Jones, já realizaram estatísticas no mercado Brasileiro e constataram que uma pessoa de TI tipicamente trabalha 132 horas por mês. Se considerarmos que temos 22 dias úteis em um mês, chegamos ao valor de 6 horas por dia. Interessantemente, conheço empresas de grande porte no Brasil que tem como norma em seus cronogramas de projeto não alocar pessoas em projetos mais de 6 horas por dia. Sábia decisão!

O efeito subliminar de medir o próprio desempenho é muito interessante. Talvez você descubra na primeira semana que você somente está trabalhando no seu projeto 60% ou 65% do seu tempo útil.
Com esta informação em mãos, você reage quase que por instinto aos vilões de tempo.

O PSP (Personal Software Planning) é uma disciplina (ou método de trabalho) que permite que desenvolvedores se tornem altamente eficientes. Independente se o seu time ou organização tenham já um processo definido (ex: RUP, Cascata, XP) ou ainda não tenham um processo definido (ex: Conserta e Remenda), o grande benefício do PSP é permitir que indivíduos melhorem continuamente em suas práticas de desenvolvimento de software.

Conceitualmente, o PSP foi derivado a partir das áreas de processos do CMM/ e adequados para o trabalho individual com eficiência e a premissa de pouca burocracia.

Os benefícios primários do PSP para cada pessoa são:

O Eclipse cresce, a cada dia, em popularidade e funcionalidades dentro da comunidade de desenvolvedores e em particular na comunidade Java. Uma pergunta intrigante neste meio é: “Quais as funcionalidades mais usadas pelos desenvolvedores Java no uso do Eclipse?”.

A resposta parcial a esta pergunta foi respondida a partir de um trabalho de pesquisa muito interessante, realizada por pesquisadores da Universidade de British Columbia, no Canadá. O artigo mostra as funcionalidades mais usadas pelos desenvolvedores e é extremamente útil para que instrutores e líderes técnicos possam focar seus ensinamentos para as equipe Java nas funcionalidades mais populares em seus cursos ou tutorias.

Do ponto de vista de engenharia de requisitos e engenharia de usabilidade, o artigo apresenta evidências que usuários tendem a usar apenas um pequeno sub-conjunto de funcionalidades de um software complexo.

Leia aqui o paper: How Are Java Software Developers Using the Eclipse IDE?

Na astronomia, Calisto é a quarta maior lua de Júpiter. Na mitologia romana, Calisto foi uma das mulheres de Jupiter (Zeus, na mitologia grega). Na informática, Callisto nao é menos importante. Callisto é um importante projeto do grupo Eclipse, destinado ao aumento da produtividade sobre a plataforma Eclipse. Este projeto lida com a coordenação e geração de linhas de base estáveis para os seguintes projetos:

• Business Intelligence and Reporting Tools (BIRT) Project
• C/C++ IDE (CDT)
• Data Tools Platform (DTP)
• Eclipse Modeling Framework (EMF)
• Graphical Editing Framework (GEF)
• Graphical Modeling Framework (GMF)
• Eclipse Project (3.2+)
• Eclipse Test and Performance Tools Platform Project (TPTP) - Hyades
• Eclipse Web Tools Platform Project (WTP)
• Visual Editor (VE)

A grande vantagem do projeto Callisto é que uma vez que ele seja instalado sobre o seu Eclipse, ele gerencia automaticamente as instalações dos produtos acima, evitando conflitos indesejáveis de plugins.

Você pode se iniciar no Callisto seguindo este link. Vários vídeos estão disponíveis neste link para você montar seu ambiente de hiper-produtividade em C++, Web, Java/J2EE, testes, relatórios e outras tecnologias suportadas pelo projeto Eclipse. Para um download resumido das funcionalidades J2EE em um único bundle, acesse o seguinte site http://www-128.ibm.com/developerworks/eclipse/downloads/.

Várias empresas no nosso mercado tem produtos (desenvolvidos em casa ou comprados) que são mantidos dentro de suas próprias TIs. Neste processo de manutenção, estes produtos são evoluídos para incorporar gradativamente novas funcionalidades. Infelizmente, entretanto, estas evoluções são conduzidas com pouco ou nenhum processo. Estes remendos são repetidos dezenas ou centenas de vezes ao longo de vários meses ou anos. A aplicação sistemática do que chamamos de processo conserta e remenda gera, na grande maioria dos casos, sistemas completamente instáveis como um baralho de cartas.

Cito como exemplo dois casos que observei no último ano, em dois sistemas com código PL-SQL e C, respectivamente. No primeiro, observei algumas funcionalidades com milhares de linhas de código e um funcionalidade com mais de 10.000 linhas de código! No segundo sistema, em código C, observei o mesmo sintoma: algumas funções com milhares de linhas de código e várias outras com centenas de linhas de código.

Qual o problema, pode perguntar o leitor mais cético? Um código com funções deste porte leva frequentemente a produção de efeitos colaterais em suas manutenções devido a sua inerente complexidade e instabilidade. No sistema PL-SQL supracitado, um erro somente detectado em produção gerou um prejuízo (enorme!) na totalização mensal de seus processos de negócio. Após muito stress, acionamento de especialistas e muita confusão, o erro foi encontrado e sanado.

Técnicas para reduzir estas instabilidades existem há um bom tempo dentro da engenharia de software . Nos últimos dez anos, entretanto, vimos a formalização destas técnicas de melhoria de código e o surgimento de ferramentas de toda sorte para a análise e refatoração de código. A refatoração é a técnica de melhorar o desenho interno de um código ou produto de trabalho sem afetar as suas interfaces externas.

Sugiro dois sites primários para entender a arte da refatoração:

• Refactoring - Site mantido por Martin Fowler com um catálogo de boas práticas de refatoração de código e ferramentas de apoio a este processo.
• Database Refactoring: Site mantido pelo Scott Ambler com técnicas de refatoração de banco de dados para evitar que sucessivos remendos nos esquemas dos bancos em produção tornem os mesmos instáveis.

Sugiro, também, três livros chaves para trabalhar profissionalmente com refatoração:

• Refactoring - Improving the Design of Existing Code, Martin Fowler, Addison-Wesley 2004. (disponível em português)

• Refactoring Databases : Evolutionary Database Design, Scott Ambler, Addison-Wesley 2006.

• Working Effectively with Legacy Code, Michael Feathers, Object Mentor, 2005.

O último livro, aliás, é ideal para quem trabalha com manutenções adaptativas, corretivas e evolutivas no seu dia a dia.

Se você não quer ganhar códigos com milhares de linhas de código que ninguém consegue manter, considere praticar a refatoração como escovar os dentes ou tomar banho. Todo dia, faça chuva ou faça sol. Sessões de refatoração mantém o código limpo, saudável e sem os sintomas típicos que observo em várias empresas do nosso mercado: código duplicado espalhado pelos sistemas, código espaguete com alta complexidade ciclomática, acoplamentos desnecessários e baixa coesão entre funcionalidades e dados associados.

Cito, para terminar este pequeno artigo, um música sobre Refactoring, adaptada da música Hey Jude dos Beatles. (Mais músicas Nerds estão no site http://www.iconixsw.com/songsoftheextremos.html)

“hey dude” (c) Lyrics by Doug and Rob Rosenberg, ICONIX

hey dude
your code smells bad
go refactor and make it better
remember
that tests are requirements
then you can begin
to make it smell better

and if you say you need design
hey dude
don’t whine
make sure you don’t put in
any comments

just code what you need today
then go
and play
remember the schedule
is the customer’s problem

la la la la la, la la la laaaaaaa

hey dude
your code smells bad
go refactor and make it better
remember
that tests are requirements
then you can begin
to make it smell better