domingo, junho 28, 2009

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+

quinta-feira, junho 25, 2009

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!

terça-feira, junho 23, 2009

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

Bye.

segunda-feira, junho 22, 2009

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

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

domingo, junho 21, 2009

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!

sábado, junho 20, 2009

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.

terça-feira, junho 09, 2009

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.

sexta-feira, junho 05, 2009

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