Enabling a full roundtrip between EA, Jira and Excel

Fim de ano chegando, e meus projetos Open Source se arrastam.

Mas não ficam parados.

Hoje, voltando de ônibus para Porto Alegre, entre um choro de criança e uma velha gorda (nada contra, apenas a situação) coloquei um Trance no Sony Ericson e abri o note com o Eclipse para voltar ao problema de não conseguir rodar o projeto treelayer-ea em plataforma 64 bits.

JRE 32 e sem JUnit

Conforme o post que eu tinha colocado lá no fórum da Sparxsystems, consegui contornar o problema de erro na DLL do EA (o pessoal da Sparxsystems não gosta que a chamameos assim, mas todo mundo a conhece dessa forma, e não sou eu que vou chamá-la de forma diferente) quando usamos um Sistema Operacional Win64.

A solução é simples (e tosca): usar uma JRE 32 bits!

PS. Digo tosca porque, conforme arquitetura projetada para este plugin, ele deve rodar uma parte (justamente a que invoca a DLL) em uma plataforma 64 bits Linux, servindo clientes via REST, e por isso forçar uma plataforma 32 bits aqui vai me levar a fragmentar esse elemento em duas partes... mas falo disso num futuro...

O problema número 2 é mais tosco ainda, e simplesmente se resume a isso: não consegui fazer rodar JUnit4 para testes unitários no projeto.

Usar o JUnit3 está fora de questão, e nem tentei ele para ver se funciona. Então, o mais simples foi tirar JUnit da jogada (para quem sabe tentar um TestNG ou sei lá o que depois) e fazer um TestCase manual, com as boas e velhas classes TestX.

Rumo à Integração Contínua

Uma das promessas para 2010 é deixar de trabalhar à noite para a empresa e retornar aos meus projetos comunitários.

Tomara!

Um dos itens da lista é colocar o treelayer-ea dentro do Atlassian Bamboo, e usar integração contínua para ele, habilitando builds e pacotes de releases estáveis.

Por hora, o foco está na montagem e definição da arquitetura.

Semana que vem tenho reunião na PUC com o F., para ver como o plugin treelayer-jira deve se integrar com esse cara para, então, termos um full roundrip entre o EA (ops, Enterprise Architect) e o Atlassian Jira, sincronizando automaticamente o EA, o Jira e eventuais, famigeradas e sempre onipresentes planilhas do Excel.

Outro dia explico mais como funcionará tudo isso...

Sim, sao as empresas que criam estes monstros verdes

Conhece aquela historia do mostro verde que mora embaixo da cama?

É tipo assim; aquele monstro que durante o dia a gente procura, procura e não acha, e à noite, sempre na calada, ele parece à espreita de nos pegar quando menos esperamos...

Pois é, nossos Arquitetos Megalomaníacos são assim.

Para encontrar estes seres extraordinários, ironicamente, corremos e choramos. Às vezes, imploramos. Outras, ainda, até penitenciamos. Mas ei que enfim, os achamos em algum lugar.

Mas são caros! E como são caros!

A culpa das próprias empresas

Mas a culpa disso não é deles. A culpa é das próprias empresas que os contratam. E os criam.

Óbvio! Sim, são elas que fomentam estes seres extraordinários, alimentado-os com títulos e cargos pomposos.

Não obstante, salários espetaculares são entregues à recursos nem, hum, um tanto valiosos (no bom sentido da palavra e para para não usar um termo que o M. me mataria) ou, pior, com pouca experiência (ou dor, como diria o A.)

E isso é um círculo vicioso, devido, muitas vezes, resquícios de bolhas inflacionárias no mercado...que se origiraram devido outras empresas planejarem pessimamente seus projetos...onde existiam... bingo: maus arquitetos no comando (vide nota).

Enfim, deixo aqui um post de uma empresa que está começando a criar cinco destes monstrinhos:


Detalhe: Observe a "larga" experiência exigida para os cargos.

NOTA: PS. "Tiro o dos" gerentes fora nesse caso, pois embora eles tenham a responsabilidade, é muito frequente eles não tê-la desejada, e sim sê-la imposta entranhas abaixo... ou então "não tiro tanto deles", visto que eles poderiam negá-la ou, pelo menos, deixar de confiar nas estimativas dos monstrinhos verdes debaixo da cama.

Usando o Atlassian Jira para controlar prospeccoes de negocio - PARTE 2

Continuando, antes de almocar...

Abaixo, um preview dos resultados parciais no uso do Jira como ferramenta CRM aqui na empresa onde trabalho.

Posso fazer buscas filtrando por tipo de negocio e obter resultados di

versos, como: Status da prospeccao; volume financeiro, gerente de contas envolvido, e por ai vai... (o ceu eh o limite, e vai depender dos campos que eu quiser colocar na issue relacionada).

Deixo um screenshot de um find basico, onde alem dos resultados, posso ter os graficos de desempenho, nas mais variadas situacoes.

Aqui mostro uma prospeccao de negocio na area da parceria nossa da LM2 Consulting com a Atlassian e uma prospeccao que envolve trabalhos na area de produtos, mentoria e consultoria ao mesmo tempo.

Um bom projeto, eu diria.

T+

Usando o Atlassian Jira para controlar prospeccoes de negocio

Esse fala bem rápido de como usar o Jira para gerenciar prospecções de negócio (entre outras milhares de coisa que dá pra fazer com ele, claro!).

Bem, estou, conforme possível, incrementando nosso esquema de gerenciamento de issues. No caso, issues para prospecção de negócios na empresa.

Semana passada criei uma issue desse tipo, só para eu poder ter campos e telas customizadas, de forma que eu possa ter um mini CRM implementado pelo jira (tipo, gerentes comeciais envolvidos, equipe de pré-venda, produtos/serviços/parceiros envolvidos no negócio, volume financeiro estimado, etc.)

PS. Embora nosso comercial já use um CRM para isso, a tendencia é centralizarmos cada vez mais todo o core do nosso negócio na plataforma Atlassian Jira + Confluence.

Já tinhamos várias desses coisas usando os "componentes" do jira, mas agora com uma issue específica, as oportunidades se abrem.

Workflows

Esbocei no excelente Enterprise Architect nosso fluxo operacional de controle de prospecções de negócio, e mapeei então os 8 status que uma oportunidade/prospeção de negócio pode estar.

Então, fui para o Jira para criar o Workflow relacionado e vinculá-lo ao novo tipo de issue, a de prospecção.

Devido usarmos o Kaamelot (ainda a versão antiga), me aconteceu um terrível ClassCastException ao definir uma simples transição no Workflow:

cannot be cast to com.atlassian.jira.event.type.ExtendedEventTypeManager

Sim, terrível, pois qualque erro nesses componentes são coisas muito ruins para qualquer um...

Felizmente, uma busca no branquelo me apontou a solução do problema, bem aqui.

Desativei então o "fire" de eventos do Kaamelot (e sei lá o que mais isso implica) e então defini as transições com sucesso. Bingo!

Agora é madrugada, e então espero este fim de semana mapear as issues de prospecção para os workflows e então ter, com o auxílio do Greenhopper, um quadro Kanban (ou Task Board), como a figura abaixo:

Legal é?!

Ah, claro, as "corezinhas" aí podem indicar várias coisas, conforme configurarmos no Greenhopper, como tipos de projetos, volumes financeiros, prioridades, etc. Vai do gosto do freguês.

T+

Arquitetos ou Megalomaníacos

Não sei se posto esta mensagem meio rancorosa porque meus últimos exames de saúde não foram aquilo que eu esperava, ou se é devido aquilo que o J. me passou pelo MSN há pouco.

Enfim, o fato é que posições como os - famosos - arquitetos de software despertam o âmago do ego humano.

Sim, arquitetos de software, e principalmente aqueles que trabalham com a plataforma Java EE se acham deuses, como tal, esperam merecerem contratações astronômicas.

Que piada.

Tenho certos pré-conceitos (no bom sentido, e ainda sem saber se vai ou não hífen nisso com esta nova - e maluca - gramática portuguesa) a respeito de vagas para arquitetos, que são (vou falar do mundo Java, que é o que conheco):

Para mim (ou seria eu?), um arquiteto precisaria, no mínimo:

ALGUNS (MINIMOS) REQUISITOS PARA ARQUITETOS

Ter dez anos de experiência em Java, visto que ele precisa ter passado pelas dores das plataformas 1.1, 1.2, 1.3, 1.4, 1.5 e, claro, a 1.6 e 1.7; caso contrário, que referências um cara desse teria?

Conhecer pelo menos 2 servidores de aplicação Java EE, e isso não significa apenas instalar e configurar (o que qualquer tutorial na web mostra), mas sim realizar slimming e tunning das mais diversas categorias de componentes e protocolos que existem lá dentro (jms, ejb, ws, jaas, scritps, conectores http/s, jca, jndi, iiop, jmx...)

Ter nível superior completo, e isso é o mínimo que eu espero. Pessoas contra vão dizer que pouco adianta, mas isso é como certificacação, mostra caráter, força de vontade, dedicação, persuação e visão de alto nível sobre os bits e bytes que norteiam a vida dos informatas. A Alegoria da Caverna de Sócrates é um tema filosófico mas, não pasmem, ela é aplicada em qualquer empresa da atualidade, seja ou não seja de TI.

Um mestrado ou doutorado vai bem, obrigado. E aqueles que não o tem, que não levantem a mão para questionar, pois só quem já pesquisou (e muito) vai saber que aquela sua idéia mirabolante e maluca já teve, com certeza quase absoluta, dezenas ou mais de pessoas que já a exauriram em alternativas e implementações. Que o diga minha idéia do Merlin, com seus mais de 46 projetos similares ao longo dos últimos 25 anos de história!

Inglês para leitura, escrita, conversação e - claro - oratória. Ler e escrever nem se fala, isso deveria ser a nossa base desde o primário. Conversar, bem, isso deveria ser o básico na adolecência nossa e, falar ao público, bem, isso todo arquiteto que se preze tem que saber. É fato que a oratória está para o mundo da TI assim como para o do marketing. Não basta termos projetos arquietônicos maravilhosos se nossa equipe de TI não souber vendê-los. Então, duas coisas: Primeira, em um mundo globalizado, o que vale é a língua padrão de fato. E, segundo, quem melhor do que o arquiteto do projeto que vendê-lo ao cliente, patrocinador e usuário (I'm the architect. I created the Matrix.)?

Ter certificações, pode não provar nada. Que me diga o Corcel Negro daquela vez que fiz curso de MSSQL... Mas mostram, novamente, o item persuação e o famoso índice "C", culhão mesmo! Uma SCJP é básica, e qualquer programador precisa tê-la. Uma SCEA é o foco aqui, e ela, bem, ela mostra o "C" do cara.

Conhecer pelo menos 2 outras plataformas são o básico para qualquer arquiteto que se preze. De que adianta conhecer Java de cabo a rabo se o cara não manja nada de C, VB, PHP, Clipper, Cobol, Delphi, Ruby ou outra coisa do gênero. Isso me remonta ao caso do I. que era vendedor de carros, e em uma entrevista ganhou a vaga de seus concorrentes porque... simplesmente viu que para o cliente em questão o melhor não era um corsinha básico e barato, mas sim uma grande, possante e cara wagon. Não entendeu? Bom, é porque você não merece a vaga mesmo...

Saber muito de SQL, obrigado. Eu sou um daqueles que ama OQL, JPA, Hibernate, OCL e outras coisas do gênero, e acredito piamente que, quando tivermos mídia óptica de baixo custo e alta velocidade para leitura e escrita isso vai ser o boom do negócio. Mas por enquanto, os antigos preceitos de Projeção, Junção e Produto Cartesiano são inerentes à qualquer arquitetura de dados (claro, fora o BigTable do branquelo) e, portanto, conhecer como fazer bons SQL é essencial para qualquer arquiteto.

"Entender" SOA, do início ao fim. Parece outra piada, né? Mas é incrível como pessoas que mal aprenderam a fazer um HelloWorld com Webservices já se acham "o cara" e querem pleitear vagas de arquiteto. Se você já usou (e abusou muito, mas muito mesmo) de recursos como Pipes, Mashups, GData, JSon, JQuery, RSS, Shale, ESB, BPMN, alguma engine de regras de inferência (como Jess, Drools, ILog...), Apps e outros, bem, você está no começo e vai bem como um arquiteto júnior. Agora, se você quer ser pleno, vai ter que manjar de muitas outras coisas ainda - do nível de um OFBiz, por exemplo. E para sênior, bem, plajeio (existe isso?) aqui meu professor no PMP: É o Sei; É o Sei que Não Sei e É o Não Sei que Não Sei. Ave!

Manjar de Versionadores como CVS e Subversion são (e sempre foram) pouco. Ao arquiteto que se preze não basta saber usar, configurar e manutenir ambientes de versionadores tradicionais como VSS (hic!), CVS ou SVN. Manjar de Git pode ser algo para uma galera mais restrita, mas Mercurial e outros dessa cepa são coisas que deveriam constar no CV com, no mínimo, "experiência profissional em uso, administração e tunning"...

Pacotes xOffice são o mínimo. Outra coisa que passa despercebida entre os candidatos. Conhecer famílias como MsOffice, Notes, OpenOffice e análogos não é coisa da "guria do marketing", não. Ao arquiteto que se preze, saber fazer mala direta, indexação, índices analíticos, campos customizados e fórmulas exotéricas numa planilha eletrônica são coisas básicas. E por quê? Bem, essa eu deixo para vocês responderem...

UML é básico; U.M.L. é outro nível. Mais uma das coisas que o pessoal acha bonito colocar no CV e gritar, "Sim, eu conheço". Conhecer os 13 diagramas dela em suas 2 nuances é barbada. Agora, saber como usá-los, quando usá-los, como interligá-los, como não poluí-los, como passá-los para a equipe e cliente - sim, cliente e, claro, como mantê-los em sincronia com a Gerência de Configuração ao longo dos diversos baselines e marcos de projeto, bem, aí entra novamente o feeling de um bom arquiteto. PS. Última palavra: Projetistas fazem diagramas; Arquitetos, os definem!)

Dicção e Boa Aparência: Ainda esta semana questionei a E. sobre o que seria Boa Aparência quando estávamos vendo uma vaga para postar na consultoria de RH. Ela não soube responder. Nem eu! Mas o fato é que um arquiteto que não sabe falar em público, ou que fala como uma voz de caixa de abelha ou radinho de pilhas, que encolhe os ombros, que olha para baixo quando fala, que não responde (e não se cala) quando deve, que não assume a liderança, que não se expresse corretamente (de forma gestual, escrita ou oral), que não "puxe" sua equipe (de projetistas, designers, desenvolvedores, analistas, testadores, estagiários, comercial, diretoria, etc, etc, etc) bem, este cara está fadado a *não ser arquiteto*.

Processos nunca são demais. Outra coisa que acho engraçada. Todos conhecem o Waterfall. Legal, muito bom. Alguns conheçem o RUP. Uau, estamos bem ainda. Outros conhecem XP, Crystal, REUP e esses caras. Mais gente, talvez os mais novos, são fãs do Scrum, FDD e outros. Nossa, como somos bons! Mas, ao arquiteto, não basta conhecê-los; é preciso vivenciá-los. E isso faz toda a diferença. Particularmente, adoro FDD. E também aplico Scrum. E XP, às vezes. E RUP, em alguns casos. E o REUP, esse eu ainda não tive oportunidade. Até um pouco do 4+1 já usei. Enfim, não existe nada como a prática. Longe de mim ser expert em qualquer um deles. E ainda mais quando tento aplicar os preceitos do PMBOK sobre eles. É uma loucura, pura e simples. Assim, arquitetos, não digam "conheço", digam "usei, e minhas dores foram...". É mais realista, e sim, isso sim aumenta seu cachê.

JSRs, eu quase esqueci delas. Nem todos gostam de lê-las. Quem dirá, entendê-las. Mas para os Javeiros, elas são nosso porto seguro, e é por elas que devemos nos guiar. Tenho algumas delas no meu note, e frequentemente as leio para entender o porquê das coisas - embora muitas vezes seja difícil de aceitar porque uma mesma interface não pode ser Remota e Local ao mesmo tempo, ou porque os Jobs dos Timers não podiam ser inicializados já no deployment do artefato... Enfim, JSRs como a do WebBeans (que nome feio - e errado!) ou da JPA são colossais, mas necessárias. É conhecendo elas que damos os primeiros passos para, depois, corrermos para o abraço. Arquitetos, vocês, diferentes de mim, não as esqueçam, please!

Maven, Ant, Integração contínua e desenvolvimento por branches não são bixos de sete cabeças. São mais do que isso; são o Santo Graal dos ambientes de desenvolvimento. Cabe aos arquitetos montá-los, gerenciá-los, intercambiá-los e, óbvio, mantê-los ao longo do tempo - muitas vezes por vários e vários anos a fio. Maven para mim é um ótima ferramenta de download e, talvez, por isso, não ouso pleitear uma vaga de alto escalão.

Utilitários, Bibliotecas e Frameworks não devem ser feitos. Pelo menos, não por você, arquiteto comercial. Você vai bem montando um utilitário para ajudar em algum projeto aqui ou acolá. Uma biblioteca? Bem, quantos de vocês podem colocar em um CV algo como um, hum, deixe-me ver...hum, um Javassist? Ou um MicroKernel JMX? Bem, são poucos. E frameworks então? Não é questão de mérito, mas de foco. Cada uma dessas coisas tem complexidade logarítmica para criação. Assim, quando estamos desenvolvendo um projeto, é notória a tendência de sair do foco do PROJETO DO CLIENTE e cair no MEU FOCO MEGALOMANÍACO de criar um novo framework da hora para o mercado, que vai derrubar aquele lixo do Hibernate ou Spring... É óbvio que são arquitetos visionários que criam coisas desse gênero, mas isso tem hora e lugar. Projetos Open Source são um cultivaris show de bola para isso. Então você colocar no seu CV que criou um "framework de persistência de alta performance no projeto X", bem, é mais fácil você conseguir uma oportunidade em um projeto de pesquisa do que em uma empresa de mercado que visa lucro com projetos comerciais.

Hierarquias e prioridades e precisam serem seguidas. Lembro de quando eu trabalhava mais forte nesse lance de projeto e arquitetura de sistemas - que diga-se de passagem eu adoro - e era constantemente "podado" pelos meus GPs. Eu ficava P da vida. Pô, eu vou demorar um pouquinho agora, mas daqui 3 semanas a galera vai estar 2 vezes mais rápida com isso... Maravilhoso, não? Pois é, nem sempre. Já ouvi por isso coisas como "ou vai você, ou vai a equipe". Fui eu. Hoje sei o que é isso, e embora eu adore perfis visionários - sim, confirmo, também o sou - eles tem hora e lugar para serem explorados. Quando falo como o J. ou mesmo com o P., sempre digo "pessoal, precisamos dos nossos lists e filtros genéricos" e, em conjunto, nos cobramos para fazê-los. Sentimos na carne não ainda os tê-los. Porém, a prioridade nos manda realizar a entrega do cliente, e não a nossa. Assim, hoje entendo aquilo que me cobravam há 10 anos atrás...

FINALMENTE

Não sei se falei tudo aquilo que nossa lista de itens pede para um arquiteto master f.cker, mas falei o mais importante.

Difícil é chegar pessoas com 3 ou 4 anos de experiência e quererem R$ 50,00/hora. Isso sim é difícil de entender.

Termino o post aqui com aquela do médico que vai ao mecânico e pergunta quanto deu o serviço de retífica do motor do seu carro:

_ Foi 3.000 real, chefia.
_ Hum, você não acha caro, não?
_ Pois é, né chefia, eu tive que abrí todo o motor e trocá umas parte. Mas tá tudo novinho di novo. Um relógio, basta ligá pra ver.
_ É, mas mesmo assim, é caro.
_ Chora não, chefia. O sinhô não cobra caro também só pra trocá umas pecinhas na genti, não?
_ Sim, mas as eu troco com o motor em funcionamento!

T+

O mundo é dos "picão"

Pois é, eu tava falando do Jira + Confluence como solução enterprise para um Sistema de Ouvidoria.

Então, acho que o mundo é dos "picão" mesmo, como diria um amigo meu.

Na orçamentação que fiz, com um hosting de 99,9% de disponibilidade - conforme exigido no próprio documento enviado pelo cliente - meu custo mínimo seria algo em torno de 9.000 reais/mes para suportar o sistema do cara, incluindo aí, além do hosting, horas de manutenção e acompanhamento, licenciamento anual dos produtos, SLA 24x7, upgrades, instalação, customização e integração iniciais além, é claro, de treinamento.

Enfim, teve um picão que colocou a proposta - e venceu o pleito - por míseros 4.100 reais mensais.

Uma coisa não está certa aqui: Ou o cara é mágico para suportar um SLA 99,9% em 24x7 (que para mim não ficou abaixo de 3.900 mes em um data center de boa qualidade com duas máquinas geograficamente dispersas e com balanceamento, replicação e backup remoto) ou o cara tá mentindo descaradamente.

Moral da história: As pessoas nem sempre querem aquilo que é real, eles podem querer a utopia de uma solução xinguelingue e, após sofridos e recorrentes "dodóis", enfim, cairem na realidade.

A roda jira, Jira, Jira, Jira!

NOTA: Eu poderia ter escrito este post de N formas diferentes. Preferi escrever assim para ser o mais neutro possível e preservar aqueles envolvidos (alguns pobres, e
outros fétidos) para não causar maiores atritos.

Sistema de Ouvidoria via Jira + Confluence

Esta semana tenho que terminar e enviar uma proposta para um Sistema de Ouvidoria de alta disponibilidade.

Minha idéia é usar a duplinha Jira + Confluence para resolver o problema dos caras.

Todos sabem (?) que o Jira é maravilhoso, e pode "fazer a mão" desde um simples controle de Help Desk até o gerenciamento de um complexo portfólio de uma empresa, passando aí obviamente por um mecanismo - eu dirita até simplista - que é um controle de Ouvidoria.

Entretanto, embora possamos customizar os formulários e fluxos (workflows) para cada tipo de atividade no Jira, a customização do layout pode não ser tão flexível quando os mais esmerados esperam (olha eu aí de novo usando palavras que soam iguais...).

Assim, o suporte de uma ferramenta wiki corporativa como o Atlassian Confluence é de suma importância, pois complementa e integra a solução ao ambiente do cliente.

Usando o sempre belo e agradável plugin FormNG, o Confluence dá conta do recado fazendo - plajeando minha mãe (puts, de novo!) - "misuras" na parte gráfica e integração.

Um exemplo

Ontem a noite, antes de ir dormir (bem, já eram 04:16 AM), criei uma página como esta abaixo:



Nela, tenho um simples formulário, já bem agradável, para uma pessoa qualquer enviar um email...

Este email nada mais pode ser do que uma conta (pop ou imap) monitorada pelo sempre estável, robusto, flexível...e aí vai um monte de adjetivos... Jira.

Ele "pega" este email, e conforme o tipo de demanda escolhida pelo usuário (eu poderia usar sua engine de workflow para fazer isso, ou então uma abordagem mais simples, onde o usuário tivesse um link anterior de escolha do email - Reclamação, Sugestão, Melhoria, etc - que mapeasse para um formulário diferenciado que seria remetido a um tipo específico de tarefa e workflow no Jira) essa demanda vai para o sistema e fica catalogada.

Depois disso, o (que clichê) céu é o limite, e "os GP", diretoria e outros podem ter seus relatórios e BI da forma que acharem melhor.

Particularmente, eu adoro a integração dessas informações em outras páginas Wiki do próprio Confluence, de forma que estas informações estão sempre integradas em tempo real, e podem ser afixadas e disponibilizadas em diversos formatos, como RSS, emails informativos, XMPP, SMS, etc.

Agora é tentar convencer o cliente para não pegar outros produtos, mas isso já outra história...

Bom findi.

OFF TOPIC: Brasil, ame-o ou deixe-o

São por essas coisas que nós desgarrados e sonhadores brasileiros nunca teremos condições de criar um branquelo, uma azulona ou uma intrépida vermelhona.

"(...) Ainda no quesito capital de risco, alguns números deixam claro o cenário de negócios nos Estados Unidos. O investimento médio de venture capital em empresas americanas, startups, é de US$ 6,5 milhões, em negócios nascentes. Empresas que faturam anualmente de US$ 10 a 15 milhões conseguem captar, em média, até R$ 50 milhões.

No Brasil, a realidade é totalmente diferente - uma empresa de R$ 10 milhões tem dificuldades de captar recursos de até R$ 5 milhões, por exemplo. A Microsoft pagou US$ 240 milhões em 2007, por 1,6% do Facebook, que ainda não tinha um modelo de receita definido, consolidado. (...)" (GONÇALVES).

Sinto isso toda vez que passo pelo site do FINEP, MCT, Inovar, Sebrae, Incubadoras e tantos outros quando tento (há anos) levantar capital para nossos projetos Open Source.

Entristece, sabem?!

Tip Day do Postgres

Embora eu tenho um passado triste com seu primo mais velho, eu acho o Postgres muito legal.

Porém, tem umas que a galera do desenvolvimento não precisava fazer, né?

Olhem o Tip Day que me abriu hoje:



Fala sério, codificar regras no BD até que vai, mas dizer que isso é uma das maravilhas do mundo civilizado, bem, tenham dó, né?

Enfim, o barco segue...

Geradores de codigo, ainda morro disso

Todos sabem que sou totalmente contra geradores de codigo-fonte. Em qualquer sentido e para qualquer linguagem.

Tirando abordagens MDA muito bem construidas - que diga-se de passagem são poucas - não tiro meu pé dessa (mediocre?) posição.

Entretanto, não posso ser bitolado ao extremo e, portanto, ainda me dou o luxo de dispensar meu escasso tempo olhando materiais na Internet para, algumas vezes, estender mais uns 3 ou 5 minutos para olhar vídeos, demos ou whitepapers sobre essas coisas (quase ridículas).

Enfim...

Skyway Builder
Hoje, recebi pelo TheServerSide uma news com o software da SkyWaySoftware, falando sobre (sempre falam isso) os 10 princípios que um gerador de código-fonte precisa seguir.



Como disse, dediquei 3 minutos (e agora mais 20 para escrever este post) para olhar o demo.

Resultado?

Ridículo.

Excetuando o uso do Eclipse RCP para construção do próprio gerador, o produto em si não agregou nada para esta já masserada, mastigada, massante, miserável e maldita área de geração de código.

Muito pelo contrário.

O que vi foi o cara que narra o vídeo perder 3 minutos para montar um POJO visualmente (com aqueles eternos wizards ou páginas com paletas e grids editáveis) e, a partir dele, gerar um CRUDzinho básico com uma (novamente ridícula - e isso não é somente eu que falo) DAO associada com um Controller e uma JSP e outros elementos básicos atrelados.

Em suma, nada de novo, apenas repeteco daquilo que já conhecemos.

E o Merlin?
Muitos podem dizer: Tá, mas e o seu famoso (hic) e famigerado Merlin?

Concordo, ele está parado mesmo :(

Por hora, estudo (quando sobra tempo) seu mecanismo de configuração realimentada para, quem sabe ano que vem, montar uma tese de doutorado sobre o assunto e, (novamente) quem sabe, em um horizonte de 5 - 8 anos, ter sua implementação finalizada.

É bucha, mas enquanto isso não acontece, muitos downloads do Skyway (Walker?) Builder vão ocorrer...

As Multiplas Curvas S no Gerenciamento de Projetos Ageis

E bem que um dia chega o post número 100. Aleluia irmãos!

E o assunto é sobre Gráficos Burn Up/Down e Curvas S no gerenciamento de projetos ágeis.

From this [moment]...
Escrevo este post pois li algo análogo (e muito, muito bom) no site do Leading Answers, do nosso (muito bom, idem) camarada Mike Griffiths.

Na prática, este texto é quase uma cópia espúria do post dele. Apenas não confirmo isso porque, realmente, li o PDF de base (também muito bem escrito) do texto e pratiquei bastante o assunto.

Assim, acredito que não fiz uma simples cópia...

Curvas S e Gráficos de Gannt
Curvas S são típicas em projetos. Uma equipe de projeto forma uma curva S ao longo do tempo: no início, temos o gerente, o arquiteto e um analista de sistemas; logo depois a equipe vai crescendo (progamadores, projetistas, designers, testadores, etc.) e depois, novamente, ao fim do projeto ela diminui até chegar a zero. Se montarmos um gráfico disso, teremos uma curva S!

Os gráficos de Gannt (ou pseudo-Gannt, como diria meu professor no curso PMBOK) são muito bons para mostrar a hierarquia das coisas no tempo e os marcos do projeto. E, de quebra, ele nos mostra os atrasos existentes.

Em suma, cada uma dessas ferramentas pode mostrar algo bom em determinada situação.

Projetos ágeis
Projetos ágeis não se sentem confortáveis com gráficos de Gannt. Simplesmente, podemos dizer que projetos ágeis focam o Sprint corrente (e quiçá o próximo). E nada mais. Ou seja, um bonito e horizontalmente longo gráfico de Gannt não ajuda muito quando nosso (constante e iterativo) foco são os próximos 15, 21 dias de projeto ;)

Em projetos ágeis, o importante são os (plajeando o Mike e o próprio... esqueci o nome do outro autor que fala a mesma coisa) "nebulosos" points (ou, no brazuquês, pontos).

Pontos? Sim, aquela coisinha maravilhosa que os caras do XP chamam de User Stories e os caras do RUP de Use Cases e os caras da FDD de Features (embora as features têm sim uma conotação muito plausível e realmente válida no mundo dos negócios - falo mais disso outra hora).

O problema básico é que "pontos" é difícil de engolir. Imagine um GP dizendo ao cliente "...olha, neste sprint nós entregamos 113 pontos, embora o esperado era 124. Os 11 pontos de diferença foram em virtude de um problema de dependência mal calculado, o que implica que, na verdade, nós entregamos 121 pontos, ou seja, apenas 3,5% a menos dos pontos esperados...".

Enfim, um ponto não representa nada para o cliente. Ele quer saber se a funcionalidade do sistema está OK. É simples, hora essa!

Além disso...

Gráficos Burn Down/UP
Gráficos Burn Down ou mesmo os gráficos Burn Up não correlacionam uma parte vital nos projetos.

E que parte é essa? Money, é claro.

Se entrarmos em um cara (diga-se: software para gerenciamento de projetos ágeis) muito bom, como o GreenHopper no JIRA e olharmos um gráfico Burn Down ou Burn Up podemos ter claramente os pontos (ou issues) que foram desenvolvidos no sprint corrente.

Porém, cadê a relação com o dinheiro consumido no período?

Simplesmente, esses gráficos não têm isso por natureza.

Aí entra uma outra coisa no cenário...

Os Gráficos de múltiplas curvas S
Lembro dos famosos gráficos de curva S e ABC quando eu estava desenvolvendo um ERP para uma empresa, lá nos idos de 2006.

Na época eu era projetista, e meu analista de negócio falava muito desses gráficos na parte de controle e manutenção de volumes de estoque...

Depois disso, eles foram para uma parte oculta do meu cérebro até que... umas duas semanas atrás eu li o post do Mike.

Coisa linda isso.

Um gráfico de múltiplas curvas S é simples: Ele mostra a variação de uma informação (os pontos, por exemplo) em relação a outra informação (o dinheiro investido) em função de uma outra informação que, geralmente, varia de forma linear (o tempo decorrido, por exemplo - embora Einstein tenha demonstrado lá na década de 20 passada que o tempo não é tão linear assim...).

Deu pra entender? Não?

Bom, deixamos a figura falar:



Neste gráfico de múltiplas curvas S eu mostro o total de issues (no meu caso Features da FDD) do sprint comparado ao volume de dinheiro (gasto na equipe de desenvolvimento) em função do tempo decorrido para o sprint (15 dias, sendo 10 os dias úteis).

Percebam ainda que eu tenho no gráfico tanto os valores realizados quanto as estimativas (de issues e financeiras).

No caso das estimativas, isso é uma informação que vai depender de vários fatores (como ter ou não históricos de desenvolvimento; ter ou não um mapeamento claro de tipos de issues que podem existir no meu projeto/processo/metodologia; saber ou não saber enquadrar as complexidades das issues; saber ou não saber quanto sua equipe trabalha efetivamente - regra de Paretto dos 80/20 é uma boa se você não souber nada; saber ou não saber que sua equipe mudou de tamanho durante uma sprint e... uma série de outras informações :() e, é por isso que você terá um bom acerto se, e somente se, tiver uma boa base para estimativas...

Enfim, mas tendo ou não as estimativas, o gráfico ainda mostra em background as partes (ou módulos, ou ainda - como preconizam a FDD e a DDD - os domínios do sistema).

Óbvio! Se eu priorizei minhas features (ops, issues - ops ainda, points - ops, ainda mais user stories) e começei a desenvolver o sistema/sprint por partes, é provável que durante o desenvolvimento, conforme as features forem sendo implementadas, cada parte do sistema será finalizada uma após a outra e assim sucessivamente, até eu ter o sistema completo.

E finalmente, de quebra, eu ainda tenho outras informações nesse lindo e belo gráfico...

PMBOK
Para os adeptos do PMBOK (que Sim meninos, em nada ele se opõe em relação aos projetos ágeis - muito pelo contrário), com este gráfico de múltiplas curvas S eu posso identificar várias informações:

VP - Valor Planejado - Quantas features (ops, issues) eu deveria ter prontas na data tal?
VA - Valor Agregado - Quantas features eu efetivamente tenho prontas na data tal?
CA - Custo Acumulado - Qual é o meu gasto financeiro na data tal?
ONT - Orçamento No Término - Qual deve ser o meu gasto na data tal? (NOTA: Claro, aqui eu mostrei um sprint finalizado, mas nada impede de eu usar uma linha de tendência no meu Excel da vida pra ter essa informação projetada no tempo no meio de um sprint/projeto)
IDC - Indice de Desempenho de Custos - Quanto o projeto está me retornando para cada R$/U$ investido? Ou quanto estou perdendo, se for o caso...
IDP - Indice de Desempenho de Prazo - Quanto o projeto está adiantado ou atrasado em relação ao planejado.

Toda essa sopa de letrinhas têm fórmulas clássicas na literatura, e o gráfico acima é capaz de mostrar tudo isso, bastando a você GP, usar as fórmulas dos livros para obter essas informações!

Finalmente, o 3PUP
Hoje, como disse (eu disse?), uso o JIRA e o GreenHopper, e não tenho as múltiplas curvas S automáticas.

Acabo fazendo elas por fora, num Excel da vida como mostrei acima.

Entretanto, com o ótimo suporte da wiki Confluence, minha idéia é colocar tudo isso integrado ao nosso processo 3PUP, de forma que os GPs nossos possam simplesmente acessar a wiki do projeto e, como dois plugins bacanas do Confluence (o Chart Plugin e SQL Plugin) eu ter essa informação online sem delonga alguma.

Não sei para quando conseguirei fazer essa automação, mas o importante não é nem isso, e sim o fato que, o post do Mike me ajudou muito (mesmo) e que, com o auxílio das formulazinhas que estão no PMBOK (e outros) e um pouco de trabalho num Excel (ou Calc) eu já posso melhorar muito o controle nos meus projetos e (quantos e's!), principalmente, mostrar informações úteis para meus clientes.

Boa Mike.

Metawidget no Seam

Este é meu post número 99. O último antes de precisar mais um algarismo para continuar a contagem...

Mas isso não importa. O que importa é que o cara do Metawidget continua firme e forte no framework dele.

Seam

Quem recebe a news do JBossORG deve ter visto que o pessoal do Seam já esta brincando com ele, fazendo implementações demo e tentando puxar as bordas da solução cada vez mais para fora.



Fico feliz pelo Richard, que deve estar fazendo um trabalho sobrehumano (agora pela nova Portuga acho que é junto mesmo...) ao liberar os releases do seu framework para geração multi-plataforma.

Já comentei em post passado que gostei da idéia do framework dele, que tal como Merlin não é um gerador de código, mas sim um renderizador de IU em tempo de execução.

Também já falei que difere do Merlin por fazer tudo um uma implementação única, através do pattern Bridge e com o suporte do DOM por baixo dos panos.

Mas enfim, o que vale mesmo é que o esforço do cara começa a render seus frutos.

Meu Merlin (até rimou ;)) continua parado. E pelo jeito que anda, cada vez mais.

E agora?

Bem, agora não sei como terminar este post.

Acho que termino simples assim, dizendo que agora é Sábado (ou Domingo), 1:42h AM e que vou encher mais uma xícara de chá branco e dar uma olhada no site do cara para ver o que o pessoal do Seam anda fazendo com ele.

At+

Porque eu adoro a Atlassian

A australina Atlassian, nossa parceira de negócios na LM2 Consulting é uma empresa cativante.

Quem conheçe sua base humana, seu conceito de trabalho, transparência e os movimentos sociais que promovem sabe do que estou falando.

Para os que não sabem, vai o screenshot abaixo:



Observem ao final da página um post meu do Twitter que fala sobre o JIRA, esta a ma-ra-vi-lho-sa ferramenta de bug tracking (como se traduz isso?) e controle de projetos.

Significado?

Tá, mas o que tem a ver isso?

Transparência, ora essas!

Pensem bem, os caras simplesmente fazem uma query no Twitter e trazem tudo que tiver a palavra JIRA. Simples assim.

E qual o impacto?

Ora, falem bem ou falem mal, mas falem de mim!

Claro, transparência. Sim, pois independente do que os internautas falarem, eles vão colocar no site deles, sem filtro, sem barreiras, sem diz-que-não-disse.

Enfim, eles não estão nem ai com isso.

E sabem por quê (Dani, vai acento aqui?) ?

Porque (ahã, esse eu sei como escrever!) as ferramentas dos caras são simplesmente excepcionais, sem comparação.

É por isso que empresas como essa do gigante que mantém o globo nas costas e aquela outra branquela resplandescem e norteiam nossos caminhos.

Três Viva para os caras! Viva!

JIRA 4, que venha logo

Hoje ao meio-dia (pelo menos medio-dia aqui em Porto Alegre) deixei o almoço para um pouco mais tarde e acompanhei o Webinar do Atlassian JIRA 4.0, que deve entrar no mercado a partir de Setembro próximo.

Peguei a apresentação do Brian Lane já no vigésimo quarto slide, mas deu pra acompanhar tranquilamente - mesmo com meu tosco inglês - o que o cara falava.

E o que ele falou?

Feature Nova: JQL

É uma sintaxe para queries no JIRA, que vai facilitar (ainda mais) a busca de tasks no sistema. Sim, alem da excelente implemnetação de uso do Apache Lucene que já vem na ferramente e o maravilhoso suporte para filtros que podem atuar sobre campos customizados de usuário, agora podemos fazer buscas Hand On.

O exemplo:

project in (JRA,CONF) and fixVersion = "3.14"

busca todas as issues do projeto JRA e CONF que devem ser corrigidas na versão 3.14. Simples assim!

Agora, meus processos de integração serão ainda mais tranquilos. Ponto pra Atlassian ;)

Feature Nova: Gadgets baseadas em JQuery

Conheçe JQuery? Se não conhece, deveria.

Agora os portlets da ferramenta suportam gadgets de terceiros em formatos padrão Web. O cara colocou um clássico (mas para mim inútil) controle previsão de tempo em um dashboard do sistema para mostrar isso.

Feature Nova: Dashboards (ainda mais configuráveis).

Já podíamos criar dashboards customizados por usuário e compartilhá-los com outrs pessoas.

Agora, podemos ter dashboards customizados por projeto ou perfil de usuário, envolvendo não apenas o conteúdo (os portlets), mas sim sua aparência.

Feature Nova: Look & Feel

E por falar em aparência, vale o screenshot:



Sentiu? Agora sim, interface "cleanead" e flexibilidade, tudo customizável. Nada mais de usuários reclamando que o JIRA não é bonito...

O que gostei mesmo nessa nova interface são os "quick links", que permitem coisas como a partir de uma listagem de issues, já registrar um worklog de trabalho (não sei se é padrão InplaceEditor tal como defende Nielsen - que o Gmail implementa muito bem, mas independente disso, já adorei).

Feature Nova: Active Streams

Isso cobre aquilo que projetos como Redmine já possuíam, que nada mais é que o "rastro" do projeto.

Um portlet especial traz as últimas atualizações do Confluence, Crucbile, Bamboo e Clover. Ainda, para os apressadinhos, existe suporte para extensão. Ficamos sem nada a dever para as outras ferramentas de projeto do mundo ágil.

NOTA: Essa feature já pode ser baixada e instalada no JIRA 3.13, mas apresenta alguns bugzinhos... nada demais, mas chato para quem gosta de estabilidade...

Compatibilidade: Java 5

Até então, o Java 1.4 era suportado. Agora, o requisito mínimo é o JDK 5. E o 6 muito bem recomendado para performance, visto que APIs de baixo nível para gerenciamento de IO, threads e renderização de gráficos.

Feature em Evidência: Greenhopper na gerência de projetos ágeis

No mundo ágil, Gannt já era. O que vale são gráficos como o Burn Down, Speed Up e as (adoro) Folhas do FDD.

Assim, no quesito Scrum, não vivemos com o JIRA sem ter o plugin GreenHopper.

Felizmente, mes passado a Atlassian adquiriu este plugin, e agora ele vem embedded no JIRA. Sorte para nós.

E, mesmo esquema, votem nas pendências do plugin para vê-las implementadas e melhoradas.

Plans

Conforme datasheet no final da apresentação, os trabalhos continuam para melhorar a performance, busca de issues, suporte REST para integração, autenticação integrada de usuários e Single Sign On e, claro, continuamente - e não mais rápido devido a complexidade - melhorias na interface do usuário.

Download e testes

Para quem quiser baixar e testar, é só acessar o site da Atlassian (abaixo).

Coloque dúvidas no fórum da empresa, e vote nas issues para que elas sejam implementadas (praxe na Atlassian isso - como em todo projeto do mundo livre).

Coming So

Já temos o Beta 1.

O Beta 2 deve vir em Julho.

O RC fica para o primeiro dia de Agosto se tudo correr bem para...

... em Setembro termos o novo release do Nirvana na gerência de issues (e, cada vez mais, na gerência de projetos).

Links de Interesse

• Download do JIRA 4.0b1
• Página Atlassian com apresentações do JIRA relacionadas
• Post sobre o JIRA 4

Bye.

Telas de cadastro: OFF TOPIC - Quanto Pesa a Internet?

Telas de cadastro: OFF TOPIC - Quanto Pesa a Internet?

A primeira Google Apps a gente nunca esquece

Ano passado comprei o dominio 3layer.org, este aqui embaixo:



Esta semana, encontrei o tal de http://appengine.google.com e fiquei maravilhado com ele.

E, ontem, resolvi configurar o NO-IP.com para apontar para o Google Apps e usar os recursos do branquelo para manter este endereco que, quica, venha um dia a ser um .ORG mesmo ;)

O GWT

Desde que o vi, adorei o Google Web Toolkit ou, simplesmente o GWT.

Nao porque eh um modelo MVC, nem porque eh "puro java", nem porque eh multibrowser, nem porque tem suporte a gerenciadores de layout, nem porque eh extensivel, nem porque traz ajax integrado, nem porque tem plugins para o Eclipse, nem porque eh facil de programar, nem porque se integra facilmente com frameworks como Velocity ou Freemarker, nem porque eh facil de customizar via simples arquivos CSS, nem porque tem um bom suporte a eventos de interface, nem porque eh facil de estender via (claro) java puro novamente, nem porque tem otima documentacao, nem porque tem um belo conjunto de componentes, nem porque eh extremamente rapido, nem porque se integra com outras solucoes como o Seam, nem porque tem comunidade extremanete ativa, nem...nei sei porque (hic).

Acho que gosto dele mesmo porque ele eh tudo isso junto!

Porem, mais do que tudo isso, se ainda se integra transparentemente como Google Apps Engine.

O Google Apps Engine

Sabe aquele stress de configurar servidor de integracao continua, repositorio de versionamento de codigo, fazer versionamento de deployments, controle integrado de issues, de usuarios e permissoes em projetos, dashboard para acompanhamento de performance de uso e acesso, montagem de ambiente de homologacao e producao, rollup e rollback de versoes, etc, etc, etc?

Pois bem, tudo isso se resume a uma coisa: Google Apps Engine.

Ele eh o stack operacional do branquelo para contruir e executar aplicacoes no proprio paque de maquinas do Google.

Sim, isso mesmo: Seguranca, disponibilidade e facilidade integrado as nossas (sim, que nao tem uma?) contas do bom, velho e "beta" Gmail...

FooBarWar na 3layer.org

Maniaco que sou pelo branquelo, tenho acho que umas 8 contas nele. E isso foi meu dodoi inicial para poder usar o Google Apps com tranquilidade.

Sim, os cookies antigos dos meus IE, FireFox e Chrome estavam em conflito, fazendo com que os scripts Python do SDK do Google Apps nao conseguissem submeter corretamente aquele que foi, hoje, meu primeiro deployment no stack do branquelo.

A singela aplicacao http://foobarwar.3layer.org eh apenas o classico Hello World dos "nois" programadores.

Mas fiquei feliz de deployar ela com sucesso.

Agora, o passo seguinte eh mexer mais um pouco e depois, ao longo desse segundo semestre, implementar os varios servivos RESTful que tenho na minha maquina local e na empresa, colocando todos eles no dominio publico da 3layer para entao, quem sabe, fazer o seu sobrenome .ORG valer a pena.

Deixo aqui o o screnshot desse primeiro deployment:





Viva o branquelo. Viva!

OFF TOPIC - Quanto Pesa a Internet?

Hi all,

O post de hoje nao tem nada a ver com TI, mas sim Astrofisica.

Escrevo sobre isso porque, afinal, encontrei um link muito legal sobre esses assuntos, com material de nivel aceitavel de interpretacao ate para leigos, como nos.

O link eh este http://hyperphysics.phy-astr.gsu.edu, e ate mandei ele para o R, meu amigo.

Mas o porque disso?

Historico

Bem, desde pequeno leio muito sobre esse assunto, que por sinal adoro. Sequencia principal, Degeneracao do eletron, Degeneracao do neutron, Bosons, Barions, Massa Critica, Energia escura e coisas do genero sao alguns termos comuns da area.

Talvez coisas que nao interessam muito para nos do mundo "comum", mas enfim, sao coisas que limpam a mente (pelo menos a minha) quando temas como Scrum, JSR, PMI, Ciclo evolutivo e outros enchem o saco...

Lembro que na 5a ou 6a serie do primario eu era um dos unicos (senao o unico) aficcionados que ia (e tinha autorizacao para) retirar na biblioteca livros que falavam sobre Fisica, Quimica Organica, Historia Antiga e que continham temas nada comparaveis a boa e velha Formula da Bascara que eu acabava de aprender (e que, como um automato, nada mais eu deveria fazer que ir substituindo variaveis ate chegar a um resultado e entregaro (mal)dito Tema no proximo encontro com o tutor...).

Nada disso, ao inves de ler Os Lusiadas e fazer o tema sobre o plano cartesiano, eu devorava livros sobre Pterodactilos, Equacoes de Maxwell, Periodo Cambriano e coisas assim.

Eh obvio que nao entendia nada (e ainda hoje nao entendo muita coisa). Mas aquilo era (e ainda eh) fascinante. Simplesmente aqueles livros velhos e amarelados me despertavam e me levavam para lugares Alem da Imaginacao.

Se pudesse (e a vida nao tivesse sido tao sacana - um dia ainda falo disso) eu teria estudado essa area mais a fundo e, quem sabe, hoje o mundo teria um Arquiteto de Software a menos - para terem uma ideia, minha primeira opcao no vestibular foi Quimica (devido nao existir Fisica no lugar), sendo Computacao a segunda e, embora tenha passados nas duas, ainda hoje me pegunto "porque?"...

Bem, porem, mesmo assim, na medida do possivel acompanho esses temas em paralelo todas as noites que posso. A Wikipedia e sites de universidades sao locais unicos para isso.

As Gigantes Vermelhas

Gigante Vermelha eh um termo dado a um periodo de vida das Estrelas. Comparando aos seres humanos, seria como a velhice, quando "literalmente" o gas esta no final e se comecamos a nos preparamos para o pior...

Que eu me lembre, desde sempre eu sabia tim-tim por tim-tim toda essa lenga-lenga do ciclo de vida das estrelas (ou Sequencia Principal), mas nunca tinha parado para tentar entender o porque uma Estrela passava por tudo isso...

Hoje, acredito que consigo entender e, pasmem, chato que sou, ate concordo com os cientistas ;)

Sirius A e B

Essas sao 2 estrelas relativamente proximas a nos (8,5 anos-luz) que foram um tipico Sistema Binario - sim, nosso Sol é uma excecao no Cosmos, visto que sempre que possivel (e devido as implicancias da Teoria da Gravitacao de Newton) os corpos tendem a formar sistemas duplos...

Esse caso eh bem interessante (e poderia ser explorado por nos da TI no sentido de "perceber o que esta acontecendo" ao inves de "sair fazendo") porque embora Sirius sempre tenha sido conhecida por nos (afinal eh a estrela mais brilhante no firmamento) nem sabiamos que existia uma outra Sirius ali por perto (bem, se voce considerar 20 UA uma distancia pequena, hic).

Mas o fato eh que, devido oscilacoes na orbita da Sirius, os sempre criteriosos homens da ciencia "sentiam que algo" (pela Teoria de Newton, claro) devia existir nas redondezas...

E assim foi. Em 1844 Friedrich W. Bessel teorizou e em 1862 foi comprovada a existencia de uma Ana Branca. Isso claro, mundo o nome o nome das agora irmas Sirius A (a ja conhecida) e Sirius B (a descoberta entao).

Futuro e o Peso (ou massa) da Internet

E os textos por ai vao..., com muita coisa que nao tem nada a ver com o nosso simplista e miseravel dia-a-dia.

Enfim, nessas andancas, um artigo que me chamou a atencao (agora nao lembro o link) foi o calculo que os caras fizeram:

Voce sabe quando pesa a Internet?

Sim, quando pesa!

Os caras calcularam (2006 se nao me engano) a quantidade de informacoes (bytes) trocados na rede, e a partir disso, inferiram a quantidade do fluxo eletrico na rede para, entao, atraves da classica Lei de Coulomb e uma série de outras estatísticas malucas (...), descobrir que "somados, em um dia" todos os eletrons que trafegam na Internet somados pesariam algo em torno de 2 onças (algo em torno de 57 gramas) e exigiriam nada menos do que 50 milhões de cavalos-força para funcionar".

Sim, eh incrivel! Pense bem, tudo que voce tem no mundo hoje na internet (videos, paginas, emails, documentos em download, tudo, tudo, tudo mesmo) cabe dentro de um vidrinho pequeno de Nescafe!

Ah, fala serio, vai dizer que ler essas coisas nao faz o cara limpar a mente?!

Abraco a todos.

Aleluia irmaos, finalmente a JSR 330

Acho que esta foi uma das mais rápidas movimentações do grupo JCP, onde conseguimos em um período de apenas 14 dias ter uma aprovação unânime sobre o assunto.

E qual o assunto mesmo? Injeção de dependências no Java ou, mais precisamente, a JSR 330.

Os Bandeirantes

Aos que se recordam, acho que a coisa começou la nos idos dos XDoclets (lembram?) com frameworks de Byetecode Enhancement (como o CGLib e o agora facílimo Javassist).

Depois veio as anotações Java e integrações com XML (já falei que detesto eles?) e frameworks AOP para, enfim, aparecer a IoC.

Águas passadas, tempo passou. E então vários e vários produtos surgiram, cada qual trazendo uma promessa milagrosa mas que, de alguma forma, trouxeram paulatinamente benefícios no nosso (belo e gordo) stack operacional.

Guice e Springframekork

Enquanto eu adoro o estilo do Google Guice, a galera do Springframework berra sempre aos quatro lados que foram eles que inventaram essa coisa de Inversão de Controle (IoC) e toda essa tralha de "programar por fora" do sistema.

Não que eu discorde, pelo contrário. Realmente acho IoC uma coisa muito útil e vital em sistemas enteprise. Mas falar que foram eles, bem, nosso amigo B. Meyer não ficaria tão feliz assim com uma declaração dessas...

Enfim, espero que a abordagem do branquelo para injeção de dependências balize esta JSR e que o pessoal do Springframework possa contribuir com seus anos de experiência (e dores) para criar arquiteturas flexíveis, extensíveis e, principalmente, estáveis.

Sim meninos, se vocês "perderam" na Umbrella JSR 313, agora vocês têm a sua rendenção à vista. Mas não desperdicem...

Os Votos e os Comentários

Dos 16 votantes, a Red Hat e a Nortel se absteram. O resto votou (de forma quase singela) Sim.

Embora a abstinência da Nortel não me interessa muito, a posição da vermelhona eu não entendo muito bem.

Argumentaram que IoC causa dependência de um container externo (o injetor de recursos) e coisas do gênero (...). Não sei quem da vermelhona que votou, mas o cara devia tá com outra dor de barriga no moemento pra dizer isso, uma vez que, para este argumento, não existe respaldo: é óbvio que isso á balela: O Guice é o que então?!

Os outros votaram e colocaram alguns comentários, com sempre.

A Sun pediu para a galera do Guice e Spring puxarem as rédeas das especificacação. E isso é bom (espero).

O pessoal do Spring votou e, pasmem, sem mais ressalvas.

A Ericsson enfatizou que o pessoal da JSR 299 deve estar sempre próximo desse grupo para não criarem duas "coisas" paralelas ao invés de convergentes. Concordo com eles.

A IBM e a Oracle foram na mesma linha, ou seja, dizendo que é importante evitar paralelismo.

Amém.

Afinal, JSR?

É óbvio que a 299 e essa 330 se sobrepõe em alguns pontos. Porém, o problema não é esse, e sim o tempo.

É notória a (r)evolução que as arquiteturas enterprise galopam, enquanto as SE's arrastam. inda hoje não tempos uma alternativa ao Swing!

Assim, se a 299 surgiu antes, vamos correr atrás do prejuízo e definir uma para o mundo SE e depois, durante sua construção, fazer a convergência.

O que não podemos fazer é estender ainda mais a 299 ou outras (JSRs) enterprises para cobrir o mundo todo. A 318 e suas quase 650 páginas que o digam.

Temos que repensar no trabalho do JCP, isso sim.

Afinal, gigantes ou não, quem está no Comitê deve definir padrões, e deixar suas brigas mercadológias no mundo pontoCom.

Farpas à parte, temos uma nova JSR.

Agile Design

Muito se lê e, eventualmente, alguma coisa se escreve.

Então, colocando em prática antes que ocorra o vazamento entre os neurônios, traduzo (e reduzo) aqui o artigo Process Agility and Software Usability: Toward Lightweight Usace-Centered Design, do nosso camarada Larry Constantine.


Visão Geral

O artigo traz o termo “Centrado no Uso”, e isso pode ser visto também como aquilo que o Eric Evans diz no início do seu livro Domain Drive Design, que nada mais é do que:

Faça modelos quando for necessário e onde for melhor, e não mais do que isso.

Cara, isso é perfeito.

Mas o que quer dizer isso mesmo? Vamos lá...

OS MODELOS são nossos diagramas em geral, casos de uso, atividades, colaboração, deployment and so. Não precisam ser necessariamente UML, mas se forem, melhor. Pode ser texto, pedaços de código em linguagem de programação ou pseudo-alguma-coisa, ou então... bem, qualquer coisa que faça o Destino (equipe) entender a origem (cliente e projetista).

A NECESSIDADE vem do objetivo. Se o prazo é curto, então nada de CASE, mas sim quadro branco (adoro), papel de pão, tabletPC, screenshot de tela rabiscado and so. Se o cliente exige formalismo (e claro, se vai pagar por isso – por exemplo, software para NASA ou alguma Telecom), então a CASE vai bem. Se nossa metodologia é burocrática (diga-se de passagem, implementamos um MPSbr, CMMI ou algo assim), então não basta a CASE, e precisamos um JIRA (rastreabilidade), Subversion (gerência de configuação), Atas de reunião (Plano de Comunicação no PMBOK) e por aí vai. Então, isso é a necessidade.

O MELHOR pode ser entendido com uma função f(x) = Satisfação do Cliente (PMBOK) versus Modelos versus Necessidade, ou seja, é como aquela história da importância dada a um risco de projeto, que equivale à sua probabilidade x impacto...

Parece complicado, eu sei. E por isso que a leitura do artigo original pode ajudar bastante...
No tocante às seções do artigo, ressalto os pontos mais relevantes abaixo.


Agilidade em Excesso

Muita agilidade não é bom. Quem o diga são os físicos, que ainda hoje brigam nos aceleradores de partículas para tentar compreender as coisas...

Então, a máxima aqui é: seu ambiente precisa ser tão ágil quanto for necessário para cumprir a (famosa) satisfação do cliente. E, novamente, não mais do que isso.
Práticas xiitas (essa eu copiei de ti Poletto) não são bem vindas de forma alguma. No meio termo entre XP e Agile UP, um FDD vai muito bem. Então, nosso 3PUP está legal.


Escalabilidade Falha

Lockwood é enfático em dizer que, de forma geral, equipes ágeis não escalam facilmente. E aqui, podemos encontrar pessoas que vão discordar. Eu não discordo dele porque (1) li o artigo e vi os porquês e (2), ainda não conheço nenhuma equipe de 300 pessoas ou mais, atuando de forma distribuída e que usam exclusivamente processo ágeis puros.

O Scrum (e não conheço muito bem outros processos) fala em “Scrum of Scrum”. Mas isso não se aplica aqui, pois Scrum (assim como todas práticas ágeis) é muito balizado pelo conceito de proximidade e galera pegando junto. Quanto mais um projeto cresce, menor é este fator.
Nesses casos, a alternativa mais viável ainda é burocratizar o processo e exigir documentação e controle. Assim, a agilidade diminui, mas o projeto continua...


Arquitetura de IU

De forma geral, excetuando sistemas compostos por grupos clusterizados de servidores, as aplicações geralmente necessitam uma arquitetura básica, onde geralmente 3 são as mais importantes na arquitetura do sistema:

• Uma estrutura essencial para que todas as IU sigam um padrão;
• Um esquema comum e versátil de navegação entre as IU e suas partes integrantes;
• Um esquema de interação entre usuário e IU que seja consistente e orientado à tarefas do usuário (os casos de uso do sistema).

Finalmente, teria mais texto, mas agora é quase meio-dia, e tenho que almoçar...

Então, como dica, leiam o cara em:

http://3layer.org/ebook/Modelagem,UML,Metodologia,GerenciaDeProjetos,PMI,PMBOK,Scrum,FDD,Agile,Requisitos,Requirements/Agile Design - Larry Constantine - Lockwood - 2002.pdf

Saiba Mais

Acesse o site http://foruse.com

Google Translate no Gmail, Coisiboa

Talvez vcs ja sabiam, mas eu sou meio panga, e soh instalei semana passada...

Estou falando da feature que habilita a traducao de emails diretamente dentro do Google Gmail. Eu adorei.


Ou quase...

Primeiro, realmente a facilidade eh enorme, com um clique a mensagem eh traduzida para o idimoa padrao meu de leitura (no caso o velho portuga). E os indices de acerto sao incriveis...


Incriveis?

Sim, dei uma olhada por traz do servico, e descobri que o banquelo (ahah, em Peps) nao utiliza dicionarios de gramatica para traducao, mas sim uma engenharia maluca de distanciamento de termos e cruzamento de bilhoes e bilhoes (sim, bilhoes) de termos, frases, palavras, flexoes, etc, etc, etc dos seus enormes buckets de processamento para produzir o resultado final.

E claro, essa base de traducao eh ativa, ou seja, voce pode contribuir tambem. Na pratica, eh o que voce, eu e milhoes de pessoas fazem ao acessar o Google Translate e dar uma "melhoradinha" na traducao do sistema.

Claro, voce deve pensar que ... ah, vou escrever um lixo qualquer e f.o.d.e.r o sistema. Nao adianta, pois internamente os algoritmos detectam padroes, interacoes, repetencias, distanciamento, profile (quando o cara logado) e outras heuristicas (ja falei que adoro heuristicas?) para evitar essas coisas que usuarios gostam de fazer...

Em suma, comparando com outros tradutores (o BabelFish, por exemplo que eh - quase - muito bom tambem) e produtos enterprise, o Translate do Google obtem uma taxa de 93% de acerto, enquanto os outros estacam na faixa dos 50%. Ah, nao adianta perguntar que nao lembro onde foi o PDF que li este artigo tecnico (que na pratica, pra variar, eh a base de doutorado de um engenheiro da equipe do branquelo...)

Ah, e a parte ruim?

Poderia estar ativo tambem para o envio de emails, para eu ir traduzindo coisas e verificando conforme eu "composing" um texto.

Mas acho que isso logo logo estara "embedded". Eh assim que se escreve? Deixa eu ver no Branquelo Translate...

Finalmente, o PNG da featura ativada (pelo Branquelo Labs)...

Equipes de projeto

A-a-adorei.

Bom, e por que com software não funciona assim?

Isso me lembra de...hum... "Engenharia de Software". Como assim engenharia? Usamos matemática? E projeto detalhado (sim, digo detalhado no nível 1 parede = X tijolos + Y cimento + Z areia...)? Cumprimos o projeto? Por que "gerenciamento de mudanças". E claro, porque o cliente no projeto?

Então, logo, infelizmente, não podemos usar engenharia, mas sim, acharia.

Dumping e Restore de database no Postgres

Sei que é fora de escopo aqui, mas enfim, é para meu arquivamento pessoal:

--
Dumping de database postgres (pode ser executado com o banco em uso)

pg_dump -b -C -f postgres-lm2-jira.backup -Fc -Z 9 -h localhost -p 5432 -U user.admin lm2-jira

Parametros:

-b Inclui campos Blob no backup
-C Insere no arquivo de backup os comandos para criar a database
-f Nome do arquivo de backup
-Fc Formato binario customizado (alta flexibilidade para filtros no restore)
-Z 9 Maximo nivel de compressao no arquivo destino
-h Hostname
-p Porta
-U Usuario que vai ser usado para conectar no BD e rodar o backup (sugere-se administrador)

O ultimo parametro eh o nome do database a ser backupeado

--
Restore de database postgres (primeiro crie o database no destino e os usuarios/permissoes)

pg_restore -1 -d lm2-jira -h localhost -p 5432 -U postgres postgres-lm2-jira.backup

-1 Isola os comandos de restore em uma unica transacao
-d Nome do database onde a estrutura sera restaurada
-h Hostname
-p Porta
-U Usuario que vai ser usado para conectar no BD e rodar o backup (sugere-se administrador)

O ultimo parametro eh o nome do arquivo com o backup

RESTFul via Super Pipes

Hoje consegui finalmente ler os Pipes do Yahoo e produzir uma saída singela, porém expressiva para nosso propósito: Condensar tudo o que nossa equipe faz durante o dia (commits de SVN, builds automáticos ou manuais, backups, emails, agendas, atualizações de wikis, worklogs do Jira, blogs, etc) e ejetar essa saída em....bem, ainda não sei exatamente :)

O Super Pipe

O pipe que montei foi este abaixo:



que na prática, é responsável por ler feeds diversos de vários locais (nos quais nossa equipe produz informação - por exemplo, um commit do SVN gera um Feed com um comentário de log, o qual é lido pelo pipe) e ejetar uma saída padronizada (em laranja na figura).

Essa saída é um típico JSON, que então uso como entrada na nossa arquitetura RESTFul.

Arquitetura

Na verdade, esse JSON é apenas uma das entradas, uma vez que outras são provenientes de locais que (ainda) não geram Feeds. Por exemplo, algumas tabelas de banco de dados atualizadas por sistemas de legado e calendários internos não publicáveis.

Todas essas entradas são interpretadas pelo que chamei de Producers, ou seja, classes produtoras de informação... que podem vir de qualquer lugar.

Os producers colocam as informações em uma base (ainda não sei se vou usar JMS ou vou fazer de outra forma para processar de forma assíncrona ou sei lá como).

Estando nessa base, os chamados Consumers são responsáveis por ler as informações que têm interesse e gerar algum resultado útil, tal como... hum, deixa eu ver... atualizar os Twitters pessoais ou da empresa ;) ou mesmo enviar SMS para os celulares dos plantonistas, no caso de emergências em clientes (por exemplo, o monitoramento JOPr indicar uma tendência para consumo de memória excessivo ou então a queda de um servidor JBoss em produção).

Um esboço primário disso é mostrado abaixo:



Observa-se que os producers e consumers são estensíveis. Na prática, estou configurando eles via um padrão "Quasi-Command", os quais são automaticamente escaneados e carregados se estiverem no classpath da aplicação.

NOTA: Sim, sim, eu sei. Também discuti com meu colega J. a possibilidade de usar um ESB (como o JBossESB) para isso. Mas daí o trabalho seria maior (no sentido de montar toda a plataforma operacional) e, principalmente, eu não teria a chance de voltar a programar depois de quase meio ano parado.

E o RESTFul?

Toda a arquitetura é montada com base em HTTP, usando uma sopa de letrinhas, orquestrada pelo RestEasy e alguns frameworks para trabalho com XML e JSON (mas não usei JAXB - bom, pelo menos não ainda), com ênfase para XPath, para extração e manipulação de dados (como JSON convertido em XML/DOM).

Finalizando

Nessa sexta, devo colocar a aplicação na nossa área Incubator, e começar a ajustar os ponteiros.

Até agora, foi tudo desenvolvimento local, sem testes profundos com estilo...hum, cowboy (putz).

A partir da outra semana, a coisa deve ficar mais bonitinha :)

Proxy AJP + No-Ip = Felicidade (ou Quase Isso)

Agora são 3:42AM, e não fui dormir ainda porque fiquei o dia inteiro atrás da porcaria da integração Yahoo Pipes ao nosso componente REST para o Google Calendar.

O problema começou porque o componente WebServices do Pipes não usa um MediaContent simples como "application/xml" ou "application/json". Ele insiste em usar algo mais exótico, como "application/x-www-form-urlencoded".

E aí a vaca vai pro brejo, pois os providers nativos do RestEasy não interpretam esse tipo de conteúdo, uma vez que ele é codificado.

Então, tive que partir para a criação de um provider customizado...

XStream

Mas pra variar, o Jettison parece não escrever Json com esse tipo de codificação, e então tive que apelar para o XStream, também lá da CodeHaus.

Ao juntar os dois, consegui parsear o Json e produzir meus objetos Java a partir do stream HTTP gerado pelo Yahoo Pipes. E fiquei quase feliz. Eu disse quase.

Trabalho x Casa

No trabalho, os meus Pipes do Yahoo apontam para nosso endereço http://jboss.lm2.com.br/xxx, qual é válido na Internet (ou seja, para os Pipes do Yahoo acessarem).

Mas em casa, a coisa é diferente. E tive que configurar meu Wireless e meu Modem ADSL para expor meu Tomcatezinho para Web.

Porém, o SpeedStream aqui da GVT me deu uma dor de cabeça do (...) e parece que os Forward das portas não funcionavam.

Cansado, apelei para o Putty, e acessando de um IP externo, percebi que meu Tomcatezinho realmente estava publicando as portas para a Web.

E fique um pouco mais quase feliz.

AJP + NO-IP = Felicidade (Quase)

A dúvida então era: Como manter uma URL única nos meus WebServices dos Pipes do Yahoo, tanto quanto eu estivesse desenvolvendo no ambiente de trabalho, ou em casa ou... em qualquer outro lugar?

A resposta veio com a duplinha AJP e No-Ip.

Via putty, configurei nosso servidor Apache para montar um balanceador, formado pela minha máquina enquanto eu estivesse dentro da rede da empresa, e outro nodo formado pelo... meu mesmo note, quando eu tivesse em casa ou em qualquer outro lugar.

Fiz isso usando o DNS do No-Ip, apontando para meu link pessoal. Veja abaixo como ficou:


BalancerMember ajp://192.168.20.233:8010 route=jvm1
BalancerMember ajp://mmrack.no-ip.info:8010 route=jvm1


Testei e funcionou, e fique quase feliz.

E por que quase? Porque agora são 04:00AM, e quando eu chegar atrasado no trabalho vão reclamar de mim, e ainda por cima, terei que validar meu processo de Json x Java para ver se tudo realmente está Ok.

Uma hora dessas eu canso.

A Maldita Anotação @LocalBean

Há pouco mais de um ano, eu estava postando sobre as novidades do EJB 3.1 - nossa, como o tempo passa! - e falava que a idéia do Bill (Burke) parecia que não iria vingar. Mas vingou.

Como todos já sabem (?), no Java EE 6 teremos o suporte à publicação local de EJBs, os quais poderão ser simples classes POJOs que não implementam nenhuma interface e que sejam anotadas com pouco mais do que @Stateless (@Stateful).

Isso seria muito legal, nao fosse o "pouco mais", conforme a página 84 (seção 4.4.2.2) da PFD (Proposed Final Draft) da JSR 318, que fala da maldita anotação @LocalBean.

A (Maldita) Anotação @LocalBean

Essa anotação não existia até agora, e é necessária para avisar o Container Java EE que o POJO em questão está sim publicando um EJB para acesso local.

Segundo a especificação isso é necessário porque podem existir EJBs que não desejam publicar um acesso local à sua funcionalidade de negócio e, situação que poderia incorrer em comportamentos anômolos durante o uso da aplicação...

Para mim isso soa como aquelas malditas e antiquadas interfaces LocalHome, RemoteHome e outras da série EJB 2.x, e em nada isso me sinaliza uma solução elegante para o problema.

Talvez minha mente obtusa não consiga enxergar muito longe e por isso eu esteja errado. Mas o é fato que colocar mais esta anotação incha ainda mais a especificação (copiando as palavras de Rod Johnson) e implica que EJBs pré-existentes tenham que ser, no mínímo, recompilados para funcionar (talvez até não, mas com certeza um re-empacotamento com descritores XML sobreescrevendo alguns comportamentos, isso sim).

O Bugs que Funcionavam

Quem acompanhou a Issue 751 e outras do JBossAS, sabia que na versão 4.0.5 era perfeitamente possível (e perfeitamente "funcionável") termos um EJB (ou uma interface) anotado com @Local e @Remote ao mesmo tempo.

Na versão 4.2 isso foi "corrigido" para, justamente (como dizia o Juvenal), aderir à especificação. Para mim, isso foi um caos - simplesmente tive que refazer vários dos meus EJBs nos processos de migração.

Ruby on Rails, Grails (e Outros da Série Convention Over Configuration)

Frameworks novos usam muito bem a prática da convenção ao invés da configuração. No mundo EJB (e Java EE), eu adoraria ver isso em prática.

Sim, demos um passo com a padronização (ainda rudimentar) do JNDI para os containers, porém precisaríamos caminhar mais rápido nesse cenário.

Anotações como @Stateless ou @Stateful são muito legais, mas poderiam simplesmente não existir, idem. E também poderíamos ter que nunca conhecer uma @LocalBean e nem mesmo se preocupar no projeto do sistema se vamos usar @Remote ou @Local sobre nossos elementos.

Com o andar da carruagem, simples modificações no container de IOC poderiam fazer todo esse mexe a qualquer momento, não exigindo a definição a priori, do comportamento de nossos beans no servidor de aplicação.

A (Longa) Estrada da Vida

A conversa poderia seguir indefinidamente, ao ponto de realmente modelarmos sistemas complexos segundo os princípios DDD, sem se preocupar com aspectos verticais no Stack (transações, contextos, clusters, local, remoto, etc, etc, etc). Em suma, um "mundo POJO" seria simplesmente lindo.

E isso não é utopia. Já podemos fazer muito disso com frameworks atuais e com o suporte a linguagens dinâmicas na Java 7, as coisas podem ir muito além. Muito além mesmo!

O "brabo" é fazer as pessoas pararem de pensar em novas e lindas Annotations.

Automatizando o Twitter - O código-fonte

Aqui, continuo o post anterior sobre a automatização do Twitter, colocando o Screenshot dos resultados e, claro, o fragmento de código essencial do Eclipse.

O Resultado no Twitter.com



Nada demais :|

O Código-fonte da aplicação REST



Percebe-se que o código é simples, declarando um @Path para o serviço, e uma operação GET (na verdade que gostaria de fazer via PUT, mas isso vejo depois...)

Para executar, basta deployar a aplicacação (que é um .WAR simples - igualzinho aos exemplos que vem no RESTEasy) e acessar a URL, no browser ou via utilitário wget, como abaixo:

wget "http://localhost:8081/treelayer-twitter/twitter/status/mmrack@minhasenha/Atualizando meu status via RESTEasy, agora com o WGET do Linux."

Que produziu isso:



Enfim

Ou seja, segue o baile agora pra publicar minha aplicação REST na Web, e usar os Pipes do Yahoo pra manter meu Twitter atualizado com minhas demandas diárias.