Sobre

Graffiti \Graf*fi"ti\, s.m.
desenhos ou palavras feitos
em locais públicos. 
Aqui eles têm a intenção de 
provocar papos sobre TI e afins.

O Graffiti mudou!

Visite a nova versão em pfvasconcellos.net
Mostrando postagens com marcador java. Mostrar todas as postagens
Mostrando postagens com marcador java. Mostrar todas as postagens

O Braguinha, lá de Brotas e meio incrédulo, me mandou a seguinte notícia: Sun Hits the BRICs. Resumindo: segundo Schwartz, a Sun tornou o Java Open Source por causa do Brasil!?!?!

Quem diria? Como eu disse para o Braga, não creio que tenha sido o único motivo. Claro que não. Mas a Sun fica bonitona na foto falando que abriu o Java para atender requerimentos de um país emergente.

E, como eu já disse ontem, a Sun aprende... com 15 ou 10 anos de atraso, mas aprende! É bem melhor que aquelas empresas que colecionam c@g@d@s e não aprendem nunca.

Não, não é o Brasileirão. Há tempos esperava por algo parecido, mas não, também não é/será o Mundial de Fórmula 1. Também não serão os bilionários campeonatos europeus de futebol, ou a Eurocopa que rola ano que vem. O melhor torneio do biênio 2007/2008 tá rolando longe das massas, mas afetará a vida de todo mundo (que interage com micros, mais precisamente com a Web).

Desde que o Graffiti nasceu sou meio obcecado pelo tema: Tecnologias para a criação de interfaces Web. Já tem um tempinho que não falo nada. Estava só observando a maturação do AJAX, o ocaso do Workplace (IBM), o nascimento do Silverlight, os sustos da Sun e a consolidação do casório da Adobe com a Macromedia.

Ok, o Workplace é um estranho no ninho acima. Acontece que lá atrás, logo depois de seu lançamento, eu coloquei algumas fichas nele. Acontece que a IBM parece não gostar mais desse tipo de coisa (investimento em pesquisa, particularmente em software). A base do Workplace é o Eclipse. Atualmente ele é oferecido como um substituto do Lotus Notes. Só... ou quase só. Mas não importa. Vamos estreiar o "quadrante pichado" para dar uns chutes:

O Silverlight acabou de nascer. Como diz a lenda, as coisas na MS começam a funcionar só na versão 3. Acontece que não vai dar tempo. Mais grana mal gasta em Redmond. Eu disse, lá em jan/05*: briga pra comprar a Macromedia. Agora não adianta chorar.

O AJAX não é de ninguém. Então é de todo mundo. A Google o adora. Até lançou um kit de desenvolvimento para ele, o Google Web Toolkit. Aliás, todo mundo o fez. Talvez seja por isso mesmo que ninguém coloca a mão no fogo de vez. Google colocou? Que nada.. rola um boato quente que ela anda interessadíssima na Adobe.

Um movimento que jogaria a Sun (de novo!) no colo da MS. Coitada da Sun. Tem Java em tudo quanto é canto. Mas ainda não faz grana legal com ele. Deveria aprender um pouco do "efeito por causa de", mas essa é outra história. Pela enésima vez a Sun vai lançar algo especial para interfaces. E o Java 7 deve ser bem mais leve e inteligente e coisa e tal. Seguirá faltando alguma coisa...

Uma coisa que a Macromedia (sem querer?) desenvolveu e a Adobe papou: ubiquidade sem estardalhaço, portabilidade sem dor, presença sem briga (ainda) com a MS. O Flash tá em mais de 90% dos computadores ao redor do globo! O Flash é multimídia fácil (Youtube!). O Flash é elegante e relativamente leve. IMHO, o Flash só tem um probleminha sério: é proprietário. Mas não importa: ele tá na frente nessa bela corrida.

Quem corre por fora ou tem condições de influenciar (a la Edilson) o resultado? Apple e Google. A primeira falando sério sobre o padrão que adotará nas futuras versões do iPhone, iPods e Macs. A segunda decidindo se casa (com a Adobe) ou deixa a fila andar.

.:.

Hmm.. ok, fui bem nerd em minha escolha. É claro que o campeonato de F1 (tanto 2007 quanto 2008) será bem mais divertido. Mas a corridinha aí tem seu apelo sim. E, como eu disse, afeta mais gente que qualquer bicampeonato do Massa.

* Ok, muitas varadas n'água em minhas previsões. Não imaginei a aquisição da Macromedia pela Adobe. Mas acertei no enredo (na importância de ambas). E sigo acreditando que dificilmente elas seguirão... "virgens". Google? Quem sabe. Mas se eu morasse em Redmond não gostaria nem de imaginar tal possibilidade.

Por uma série de motivos eu vivo adiando um post sobre o assunto. Mas algumas estrelas se alinharam de forma inédita, uma segunda terra foi descoberta e muitas coincidências e notícias pipocaram nos últimos dias, me obrigando a falar. Ontem eu falei sobre os possíveis "grandes" projetos do Brasil em 2007. Fiz um breve comentário (negativo) sobre nossas seguradoras. Anteontem o David Berlind (ZDNet) escreveu sobre como a Zimbra resolveu o "problema" offline. Bem, correndo o risco de parecer muito pretencioso, vou contar como o tal "problema" QUASE foi resolvido aqui no Brasil, há exatos 5 (cinco!) anos.

Por razões óbvias, omitirei nomes e razões sociais. Só vou destacar os membros do time, autores de uma (QUASE) obra-prima. Vamos lá:

O ramo de seguros foi um dos primeiros a tirar proveito da tecnologia da informação. Investimentos em mainframes e grandes sistemas eram facilmente justificados. No entanto, com o tempo, tornou-se um ramo bastante conservador. Aqui no Brasil os bancos tomaram a dianteira - se tornaram mais inovadores. As seguradoras seguiram recebendo e armazenando toneladas de informações. Num estudo da IBM (internacional), o autor diz que as seguradoras têm "muita memória e nenhuma capacidade de raciocínio". O autor está falando dos sistemas. O cenário é um pouquinho pior.

Como o investimento no passado foi muito grande, as seguradoras simplesmente não tinham como promover uma substituição em larga escala de seus sistemas legados. A onda dos grandes pacotes, ERPs e afins, não tocou as seguradoras. Fizeram mais sentido em outros ramos de atividade, caracterizados por pobres e surrados sistemas administrativos que eram desenvolvidos e mantidos internamente. A insatisfação com esses sistemas era grande, o que facilitou o giro da "roda da fortuna" de empresas como SAP, Datasul, Microsiga e similares. Não havia no mercado uma boa oferta para as seguradoras. E, por outro lado, elas pareciam bastante satisfeitas com seus sistemas.

Driblavam suas deficiências com novas e pontuais aplicações. Em uma década, depois do advento da Internet comercial, criaram uma imensa pilha de pequenos, arredios e heterogêneos sistemas. Em um dos piores cenários que testemunhei, a seguradora tinha mais de 15 aplicações que, de certa forma, faziam a mesma coisa. Quando uma regra de negócio era alterada, mais de 15 sistemas tinham que ser alterados. Tinha de tudo: Cobol, Clipper, FoxPro, Java, VB, ASP ...

Há um mínimo denominador comum para a maioria dos "remendos". Eles informatizam canais: corretores, bancos, telemarketing, sites etc. Cada novo canal ou demanda das áreas de negócios fazia brotar uma nova arquitetura. Não é fácil explicar, mas existem justificativas. A dinâmica do negócio confundiu-se com a profusão de novas tecnologias. Sempre havia uma tecnologia "mais adequada". A ausência de uma boa proposta de Arquitetura Corporativa (EA) facilitou a composição do "samba do crioulo doido" que caracteriza a área de TI de diversas empresas.

[Wow.. quanta introdução!]

Num belo dia de maio de 2002 nossa turminha foi jogada num projeto para uma seguradora. Ambição pequena seria bobagem: íamos trocar os mais de 15 sistemas por um único. Principal requisito: um ponto único para atualização das regras e parâmetros. O projeto era tão bom que justificou até mesmo o desenvolvimento de protótipos (RICOS e FUNCIONAIS) em tempo de proposta. Confrontamos as alternativas tecnológicas (Java X MS, pra variar), e provamos em diversos testes que a melhor solução era 100% Java.

Tinha ali um grande divisor - o "complicômetro" que nos remete ao "problema" citado no título do post: a aplicação deveria ser idêntica tanto em modo online quanto offline. A Zimbra, citada lá no primeiro parágrafo, "descobriu" o JavaDB (ou Derby da Apache). Um gerenciador de base de dados bem leve e quase invisível (para o usuário final). Ele não existia em 2002. Na época optamos pelo Hypersonic (ao longo do projeto novas e melhores alternativas foram pintando. Mas o conceito já estava fechado). Além do óbvio armazenamento dos dados gerados em modo offline, nosso "banquinho" seria também nosso novo sistema de arquivos. Armazenaria todo o código Java, fazendo controle de versões e coisa e tal. Os detalhes não interessam (por enquanto).

Além da autonomia quando desplugada, a aplicação tinha outro requisito fundamental: o "look & feel" deveria ser o mesmo do ambiente online. Esta foi, por um bom tempo, uma das partes mais complexas de todo o projeto. Hoje pululam por aí Apollo (Adobe) e Silverlight (MS), mas na época não tínhamos muitos facilitadores. Pattern MVC elevado em não sei qual potência, com megalitros de energético e café e muita discussão boa. Aliás, pude mostrar os desafios do projeto para muitos papas javeiros tupiniquins. Todos simplesmente adoravam o projeto, mesmo que discordassem de algumas soluções aplicadas ("substituir o ClassLoader é um pecado mortal!!!") hehe..

Antes do triste final, os créditos: tive a oportunidade de trabalhar com 3 arquitetos e 2 (duas!) analistas que foram um show de bola durante todo o projeto: Nelson Ponce de Leon, Hamilton Veríssimo, Luis Felipe Braga, Claudinha Nogueira Pott e Ariane Garé. Seria sacanagem não citar também as valiosas colaborações de Flávio Crispim (o aprendiz mais rápido que já vi), Fábio Pan (o programador mais rápido que já vi) e Adilson Somensari (o maior bebedor d'água que já vi - hehe.. brincadeirinha).

O trabalho dos 3 arquitetos merece muito destaque. Tensão criativa era aquilo ali. Muita tensão. Mas muita criatividade também. Era o tipo de projeto que cria isso naturalmente, sem forçação de barra (ou eventos de motivação - arrgh!). Meu primeiro pesar foi não ter tido tempo suficiente para aprender a lidar com mais eficiência com a porção "tensão" do processo. Mas a experiência foi inesquecível. Tanto que, agora - 5 anos depois - ainda me lembro de detalhes do projeto.

Mas uma equipe (QUASE) perfeita não é nada quando as organizações não lidam bem com projetos dessa natureza. Vários problemas "políticos" (e MUITA VAIDADE) condenaram o projeto. Não tem espaço para choramingos, mas o fato é que o projeto foi interrompido em seu ápice, após 30% do caminho percorrido. Um ativo (de software) muito bom - atual apesar da idade - tá aí, perdido no tempo e no espaço.

Pior, perdido em um momento em que ele seria muito útil no mercado de seguros. O Braga sempre diz: "Código envelhece". Concordo, mas o desenho da solução não. Era SOA (Service-Oriented Architecture) antes da sigla. Era RIA (Rich Internet Application) antes da sigla. Era "web-offline" antes da Zimbra, do Apollo e do Silverlight.

.:.

Agora que criei coragem, vou prolongar um pouco mais a história. No próximo post falo um pouco mais sobre a solução e sua possível viabilização.

graffiare #405

13 março 2007

...a plataforma .Net está ficando cada vez mais aberta, cada vez mais flexível, cada vez mais... parecida com sistemas em UNIX.

- Phillip "Shoes" Calçado (em "Acorda, Maria Bonita")


.:.


Phillip é muito conhecido no mundo Java. Figura muito ativa nos JUGs e grupos de discussão. Saca muito do que fala. Por isso seu 'wake up call' para a comunidade Java é muito relevante. Na minha leitura, pra lá de preocupante: como uma coisa aberta (e de certa forma livre) pode ser ao mesmo tempo fechada? Leia o texto do 'Shoes' e você entenderá.

Jo Jo Gunne ataca novamente

17 janeiro 2007

Mary Jo "Jo Gunne" Foley é blogueira da ZDNet: "A mulher que nunca pisca" - espiando a MS. Tadinha... ela cai em cada uma. Num post de ontem ela tentou entender/explicar a ida do Don Ferguson ('pai' do Websphere) para a MS. Confusão total: ela diz que o Websphere é igual ao .Net: mutante e indefinível (na opinião dela). Se ela desse um tempo - e algumas piscadinhas - entenderia melhor o movimento da MS.

O .Net nunca alcançou o 'break-even'. Quiçá 'massa crítica'. Grandes e médias corporações depositam suas aplicações mais críticas, particularmente aquelas que se relacionam com o mundo exterior (via web/web-services), em derivados do padrão JavaEE (Websphere, Bea WebLogic, JBoss e um monte de etc). Apesar do ímpeto com o qual surfou na onda 'web services', a MS anda um tanto perdida quando o assunto são as Arquiteturas Orientadas a Serviços (SOA). Daí a contratação do Don que, segundo a própria Jo Jo, ajudou na definição da estratégia SOA da IBM. Ele deve (tentar) fazer o mesmo na MS. Aguardem um .Net 4.0 bastante remodelado.

[Eu torceria por um produto MS-JavaEE, hehe. Seria mais fácil. E é um dos meus sonhos mais antigos...]

Para tentar entender o que o Don faria na MS, a Jo Jo correu em seu blog que ainda estava ativo no DeveloperWorks da IBM (não está mais). Surrupiou-lhe 10 tendências para os próximos 5 anos:


Não comentarei a lista. Não agora. Por enquanto só cabe o alerta de que a sigla EDA, ao lado de SOA, deve significar "Event-Driven Architecture", o termo-xodó do Gartner. Né, Jo Jo?