Próton lança plataforma para monitoração de software

Cloud LogoA Próton Sistemas tem desenvolvido uma série de iniciativas com propósito de disponibilizar, para a equipe técnica e comercial, ferramentas de gestão e monitoração remota dos seus softwares. Denominada Cloud Services, esta plataforma permite a integração e análise de informações críticas de desempenho e gerenciamento de licenças de forma centralizada e em tempo real.

Cloud Services

Sua arquitetura suporta a inclusão de novas funcionalidades plugáveis, em sintonia com estratégias definidas pela empresa. Espera-se que a plataforma forneça a base sobre a qual novos produtos da empresa serão construídos, dentro da visão de disponibilizar soluções inovadoras e com baixo custo para os clientes, focando a web e dispositivos móveis.

WM3D: Gestão de Armazém em Ambiente Virtual

WM3D

WM3D

Maximizar a eficiência na movimentação e armazenagem de materiais é um dos grandes desafios enfrentados diariamente nas operações de logística das empresas. Embora os sistemas de gestão de armazém (WMS) ofereçam diversas ferramentas e relatórios para auxilio operacional, esses ainda apresentam uma visão pouco intuitiva das posições de estoque no sistema de endereçamento físico – muitas vezes baseado em tradicionais relatórios impressos (listagens, fichas, planilhas, etc) cujo resultado precisa ser interpretado para que decisões sejam tomadas.  Em ambientes com grande movimentação esse método mostra-se pouco eficiente e pode representar um gargalo na produtividade que não pode ser ignorado.

O WM3D (Warehouse Management 3D – Gestão de Armazém em 3D) é um projeto conceitual que visa o desenvolvimento futuro de uma ferramenta que possibilite ao gestor maior interatividade e visão instantânea da situação do armazém, em todos os níveis, mediante ao uso de um ambiente tridimensional navegável pelo usuário.   O sistema, cujo esboço teve início em 2012,  opera como uma ferramenta auxiliar ao WMS, permitindo tornar visíveis as posições de armazenamento físico registrados no banco de dados e estabelecer pontos de acesso a informações e processos disponibilizados pelo sistema de gestão do armazém.

Inspecionando posição de armazenagem

Inspecionando posição de armazenagem

A solução opera com o conceito de “camadas”.  Por exemplo, o gestor pode habilitar a visualização apenas das posições de estoque sem giro há mais de 30 dias ou com lotes a vencer – e ter um feedback visual instantâneo de onde esses materiais estão. Ao navegar pelo ambiente virtual, o usuário pode clicar em uma posição palete e ver todas as informações relevantes sobre aquela posição ou executar ordens específicas (transmitidas ao WMS via webservices) com base nas informações coletadas.  Munidos com um tablet, os colaboradores responsáveis pela movimentação de materiais dentro do armazém poderão se posicionar com maior precisão e estabelecer rotas mais curtas ao cumprir suas ordens de movimentação.

Detalhe Posição Palete

Detalhe Posição Palete

Outros usos possíveis da ferramenta podem incluir:

  • Auxílio didático para familiarização de colaboradores com o layout do armazém;
  • Simulações de movimentação de materiais;
  • Consolidação de inventário;
  • Monitoração em tempo real;
  • Inspeção remota do armazém.

Por ser um projeto conceitual e educacional, não há previsão de quando a ferramenta poderá se tornar um produto (o que depende de outros fatores, tais como análise de mercado, investimento, etc).   No momento o projeto tem baixa prioridade em minha agenda e concentra-se basicamente no desenvolvimento das tecnologias necessárias à implementação do piloto.   Foi criado uma engine 3d em C++ (MingW + eclipse) com OpenGL  e o grande desafio técnico atualmente é extrair o máximo de performance do hardware sem exigir placas gráficas de alto desempenho – e caras.

Detalhe Posição Palete

Detalhe Posição Palete

O diagrama abaixo ilustra uma típica configuração operacional da ferramenta:

Diagrama Operacional

Diagrama Operacional

 

Projeto de Férias: Drone Command!

Drone Command

Você é o comandante responsável por defender uma área de exclusão aérea e terrestre infestada de inimigos hostis que fazem incursões com vários tipos de veículos blindados letais. Para combater o exército inimigo você tem à disposição um Drone quadri-rotor avançado que deve ser pilotado remotamente em missões de reconhecimento, defesa e ataque. Utilize o canhão de plasma do drone – capaz de disparar 300 projéteis de alta energia – para eliminar seus alvos! mas não pense que será uma tarefa fácil pois o inimigo é inteligente, ataca em grupo e possui armas anti-aéreas de longo alcance. Somente a sua habilidade como piloto e estrategista poderão decidir esta batalha!

Drone Command Pre Alpha

Drone Command Pre Alpha

Este é o Drone Command, nosso projeto “pet” de férias. Trata-se de um game 2D feito em Java / LWJGL que vem sendo desenvolvido em pequenas porções a passos de tartaruga – a maior parte durante férias ou feriados prolongados. Durante esse tempo me concentrei mais no desenvolvimento da engine que só agora começa a mostrar sinais de maturidade e estabilidade. O game mostra uma visão top-down do campo de batalha no estilo tower defense. Com a engine finalmente estável, poderei dedicar tempo para implementar uma fase e ver como a coisa vai funcionar. Para isso tenho a ajuda de um “consultor” (Daniel) para avaliar a jogabilidade e sugerir melhorias. Quem sabe um dia publicamos nosso projeto no Steam!

Daniel em Ação!

Daniel em Ação!

Uma das coisas legais que vamos testar é o uso de um Tablet Android como controlador sem fio, permitindo comandar a batalha confortavelmente sentado no sofá! afinal, não é para isso que servem os drones?

Drone Command Pre Alpha

Drone Command Pre Alpha

Arqueologia Digital: Conhecendo o Passado

Uma frase atribuída ao físico Albert Einstein afirma que “se você não sabe escrever três páginas sobre um assunto, então você não conhece o assunto”.  Conhecer o passado, compreender o presente e projetar o futuro é fundamental para quem deseja estar na primeira fila da inovação, sobretudo nesta época de maravilhas tecnológicas.  Falando da história, a velocidade em que hardware e software são jogados fora para dar lugar à “próxima geração” de novas tecnologias tem literalmente exterminado conhecimento valioso – verdadeiros tesouros que nos ajudariam a compreender como nossa história foi escrita.  Contudo, graças à tecnologia de virtualização, ao movimento open source e ao vencimento de patentes que protegiam informações técnicas, hoje é possível reviver esses artefatos do passado a fim de compreendê-los, estudando suas falhas e copiando seu sucesso.  É sobre isso que vou tratar nesse post.

O Projeto

Não sei se por nostalgia ou por aventura, tenho embarcado nesta onda – o que tem rendido horas de pura diversão e conhecimento.  Meu objeto de atenção tem sido duas peças do passado que sempre me fascinaram: o microprocessador MOS 6502 e a linguagem de programação FORTH.

Microprocessador 6502

MOS6502Lançado em 1975, o 6502 foi criado por um pequeno grupo de ex-engenheiros da Motorola liderados por Chuck Peddle cujo objetivo era criar um microprocessador de 8 bits com preço mais em conta do que as opções existentes no mercado. Para isso, tomaram uma série de decisões de engenharia inovadoras, como um conjunto reduzido de instruções, poucos registradores e componentes.  Alguns creditam o 6502 como sendo o primeiro chip a usar o conceito mais tarde conhecido como RISC.  Graças à eficiência do design, o 6502 com clock de 1 MHZ tinha performance comparável aos produtos concorrentes que tinham o dobro de clock, mas a uma fração do custo.   Este componente viabilizou a revolução dos microcomputadores iniciada em meados da década de 70, tendo sido utilizado pelo Apple I/II,  BBC Micro, Commodore,  console de jogos Atari 2600  e muitos outros produtos que mudaram para sempre nosso relacionamento com os computadores.  No início de minha aventura com a informática, tive o privilégio de ter um “clone” do Apple II (comprado de segunda mão em um leilão)  que eu programava alegremente usado a linguagem de máquina do 6502, codificando as instruções em hexadecimal (por pura ignorância, joguei meu Apple II fora após comprar meu primeiro PC).

Linguagem FORTH

A linguagem FORTH foi criada por Charles H. Moore e tem sido desenvolvida, de uma forma ou outra, desde o final da década de 50.  FORTH ficou famosa após seu criador tê-la usado para controlar um Rádio-Telescópio enquanto trabalhava no Laboratório Nacional de Radio Astronomia – NRAO – nos Estados Unidos.  Embora não tão popular quanto outras linguagens contemporâneas (como C), FORTH tinha uma sintaxe elegante e trazia diversas características interessantes, tais como notação polonesa reversa, uso explícito da pilha de dados para armazenar parâmetros além de ser muito extensível.  Com FORTH era possível criar novas palavras-chaves (denominadas “WORDS”) e adicioná-las à linguagem. Graças à sua simplicidade, FORTH executava um código muito eficiente, sendo bastante adequada a pequenos computadores.  Muitos usuários a utilizavam para controlar dispositivos de hardware – um dos seus usos mais comuns.

Emulando o 6502 com Java

Meu projeto de arqueologia digital visa construir um emulador e rodar nele uma versão original do FORTH denominada fig-FORTH – lançada em 1979.  O sistema é composto pelo processador 6502, 48 K de RAM, 12 K de ROM (para armazenar o firmware e dar o boot no sistema) ,  um chip ACIA (Asynchronous Communications Interface Adapter) para comunicação serial, além de um visor LCD com 20×4 caracteres para saída de dados em forma de texto. O sistema possui também um conjunto de Leds usados para ajudar a depurar o estado do barramento de dados de 8 bits, e do byte (Rx/Tx) sendo recebido ou transmitido pela interface serial – tudo emulado via software.

6502

O sistema é o que se pode chamar de um Single Board Computer – um computador com placa única – do tipo que os hobbistas usavam no passado para testar seus experimentos com hardware e software (semelhante ao que é feito atualmente com o Arduino). O projeto é escrito em Java e o 6502 executa software escrito em sua linguagem de máquina original, armazenado na ROM. Atualmente estou ajustando o compilador FORTH para executar as chamadas de ROM do emulador, uma vez que o software original foi feito para outro hardware (KYM-1).

Um dos desafios para emular um sistema que não existe mais é ter dados técnicos precisos e detalhados. Felizmente, o 6502 é provavelmente o processador mais documentado que já existiu, sendo possível encontrar software escrito para ele (principalmente em Assembly) além de detalhes da sua arquitetura interna, tais como opcodes, ciclos de máquina, flags, status do processador, interrupções e até bugs.  Facilita também o fato do chip possuir um conjunto reduzido de instruções e poucos registros.

Resultado

Embora alguns possam questionar o investimento de tempo necessário a um projeto relativamente complexo como este,  sua implementação pode tornar-se uma experiência educacional muito rica. De fato, este projeto tem me ajudado a compreender de maneira mais profunda a operação interna de um microprocessador e como escrever código de maneira eficiente em Java.  Além disso, finalmente pude relembrar como escrever o divertido Assembly do 6502 – algo que havia quase esquecido. Existem outras aplicações práticas para projetos deste tipo, além do exercício de simples nostalgia.  Por exemplo,  estudantes de engenharia de software ou ciência da computação podem solidificar seus conhecimentos de maneira significativa ao implementarem algo semelhante – e para mostrar que este tópico está em alta, finalizo o post lembrando que um dos Mods mais populares do jogo Minecraft (chamado RedPower)  também implementa um processador 6502 com suporte à linguagem  FORTH.  Este Mod permite criar programas que interagem com o ambiente virtual do Minecraft e executam uma série de operações controladas pelo processador virtual.

Novo Framework PRÓTON está em produção

O núcleo tecnológico usado em nossos produtos (Client Framework, desenvolvido em Delphi e C++)  acaba de receber uma nova interface gráfica inspirada no padrão Modern.  O design manteve a tradição de boa ergonomia da versão anterior porém adicionou novos recursos que facilitam a vida do usuário, além de ser visualmente agradável.

As mudanças incluem novas APIs, componentes gráficos, de imagem, internacionalização e controle de processos. Uma das novidades é um componente especializado na criação de Wizards muito útil na captura de informações para realização de processos complexos. A nova API inclui também paralelismo na interface gráfica tornando-a mais responsiva com a execução controlada de processos em segundo plano, quando necessário.

O  framework passa a utilizar uma nova tecnologia de acesso a dados com inúmeras vantagens em relação ao modelo anterior.  A nova infraestrutura dispensa a instalação do cliente Oracle nas estações de trabalho e elimina necessidade de configurações manuais para conexão ao banco de dados.

 

A conversão do primeiro produto (PROTON WMS) para o novo padrão foi feita em apenas 25 dias, contando apenas com um desenvolvedor. O produto passou da fase beta sem dificuldades e entrou em produção em clientes com operação 24×7, sem nenhum incidente.

Graças à nova tecnologia de acesso a dados, foi possível melhorar o desempenho de alguns processos em até 40% para consultas parametrizadas e em até 70% para transações originadas no cliente.

Passado o ciclo inicial de desenvolvimento, outras melhorias vão focar na integração com webservices e deployment em ambiente de nuvem.

Aplicativo Comercial (AC) com java, Flex e MVC

Uma lição que rapidamente se aprende desenvolvendo software de gestão (especialmente em meio a constantes mudanças de requerimentos típicas para esse tipo de solução)  é que desacoplar adequadamente a camada de apresentação da camada de negócios é uma peça chave para viabilizar a manutenção de um sistema complexo em longo prazo.   Em nossa experiência passada,  onde isso não foi observado, tivemos que enfrentar dilemas ao ter que implementar uma mudança tecnológica em uma parte do sistema, por exemplo,  e descobrir (para nosso horror)  que a mudança poderia quebrar certos elementos da camada de apresentação praticamente misturados com modelo de dados.   Em pelo menos um caso, isso levou a adiar mudanças importantes até que uma estratégia adequada fosse montada para viabilizar a mudança.   Definitivamente, algo de tirar o sono.

Deixamos de cair em armadilhas como essa usando padrões de projeto que satisfazem o requerimento de prover a separação de camadas.   O mais conhecido é o MVC (model-view-controller) – um padrão de projeto “arquitetural” no sentido em que divide a aplicação em camadas distintas (o modelo, a visão e o controlador, respectivamente), atribuindo-lhes papeis específicos e imutáveis no ciclo de operação do sistema.

MVC

Por ser basicamente um catálogo de boas práticas, o MVC não possui uma implementação padrão na qual um arquiteto de software possa se basear, por isso ao desenvolver um projeto baseado neste modelo é comum despender algum tempo procurando um framework que ofereça uma implementação  já provada em produção.  Naturalmente, isso torna-se uma tarefa nada fácil quando se percebe que cada aplicação possui requisitos únicos e que podem chocar com uma implementação particular do MVC.  Como consequência, é comum termos que criar adapters para conectar nosso software ao framework, o que nos leva de volta ao problema que buscávamos evitar: um código difícil de manter.

Por isso, em alguns casos é melhor criar sua própria implementação da arquitetura de forma a obter os benefícios esperados sem gerar complexidade ou dependências indesejáveis.   Esta abordagem parece particularmente interessante no desenvolvimento de softwares de uso dedicado, tais como ATMs e ACs (aplicativos comerciais usados em pontos de venda).  Esses softwares possuem um caso de uso bastante rígido, seguindo uma série de etapas interconectadas e com forte interação com o usuário.   Além disso, alguns aspectos de sua operação seguem regras regulamentadas por lei (e portanto, sujeitos a mudanças).

Com esta visão em mente,  iniciei o projeto de um framework MVC Java (denominado provisoriamente de j-MVC) com o propósito de investigar seu uso em softwares com as características citadas acima. Em particular, estou adaptando o protótipo de um AC com front end Flex/AIR para usar o framework.  Uma das idéias é basear os pontos de contato entre as camadas em plugins de modo a tornar o modelo transparente à tecnologia empregada na apresentação.  A maneira como um front end Flex se comunica com seu controlador Java,  é muito diferente da maneira como SWT/Swing ou Java FX se comunicam, por exemplo.   O conceito apresentado expande a estabilidade da arquitetura não apenas a mudanças de ordem funcional (mais comum)  mas também a mudanças de ordem tecnológica.  Esta é uma característica muito desejável em um software criado para manter-se atualizado e sofrer mudanças ao longo de sua vida útil.

POS_1366x728_3D_500

Alguns resultados pretendidos:

  • Toda a comunicação entre a visão e o controlador mediante um padrão como JSON/XML   (webservices). Esta  feature ainda requer um robusto suporte do framework (APIs) para ser viável;
  • Ter apenas um entry-point para comunicação entre a visão e o mundo exterior;
  • Incorporar alguns conceitos do framework Cairngorm, usado pelo ADOBE FLEX (especialmente o FrontController);
  • Implementar uma API simples de usar;
  • Utilizar o j-MVC em um projeto de produção;
  • Evoluir o protótipo para realizar todo o ciclo básico de operação de um AC.

Os resultados obtidos nos testes iniciais são promissores e os benefícios gerados pela separação de camadas em um projeto dessa natureza justificam a implementação do framework.  Projetos futuros para uso em produção serão beneficiados por esta iniciativa. 

Persistência descomplicada em Java com ExaQuery

ExaQueryEste post inicia uma série sobre o ExaQuery, uma solução de persistência em Java que estamos desenvolvendo para uso em sistemas corporativos.

Sistemas de uso corporativo como portais,  ERPs, CRMs e POS apresentam grandes desafios para os desenvolvedores devido a requerimentos cada vez mais elevados, tais como  escalabilidade, segurança, robustez e custo efetivo.  Além disso, a própria dinâmica dos negócios e a legislação podem representar uma demanda constante por novas funcionalidades ou alteração de funcionalidades existentes.

Em um ambiente com essas características é de fundamental importância dispor de uma sólida base tecnológica sobre a qual os sistemas podem ser construídos e mantidos.   Java tem sido uma excelente plataforma para o desenvolvimento desse tipo de solução – especialmente no lado do servidor – mas a eficácia do produto final depende de escolhas acertadas dos componentes usados.  Por exemplo, a camada de persistência é um dos elementos mais críticos em um sistema corporativo, tendo influência significativa sobre o design e outras decisões de projeto.

Após vários anos usando diferentes soluções de persistência em produção com Java observamos alguns obstáculos difíceis de contornar, tais como:

  • Complexidade da API resultando em baixa produtividade e dificuldade de manutenção do código em projetos mais complexos;
  • Dificuldade de configuração, exigindo a manutenção de arquivos XML externos;
  • Suporte limitado ao uso de SQL nativo do banco de dados utilizado.  Algumas soluções de persistência assumem total controle sobre o SQL emitido dificultando sua depuração e otimização;
  • Baixa performance;
  • Documentação incompleta ou inexistente;
  • Pouca aderência a casos de uso mais comuns em aplicações do mundo real.

As dificuldades acima foram um dos fatores que me motivaram a desenvolver o ExaQuery – uma solução de persistência objeto-relacional em Java que suporta os principais bancos de dados em uso no mercado.   ExaQuery tem como foco o desenvolvimento de sistemas corporativos,  oferecendo ferramentas de geração de codigo-fonte integradas ao Eclipse IDE, além de um ambiente de runtime.   Sua API foi desenhada de modo ser simples e poderosa,  provendo ao desenvolvedor recursos para uma fácil integração entre objetos Java e o banco e dados.

Vários recursos oferecidos pela API de ExaQuery são baseados em requerimentos comuns no desenvolvimento de aplicações.   Por exemplo, como obter um arquivo XML a partir de uma consulta SQL parametrizada ?  Com ExaQuery isso pode ser feito da seguinte forma:

Session se = SessionFactory.create("MYSQL", null, null, "Mundo", "usuario", "senha");
DataStore ds = DataStoreFactory.create(se);
String XML = ds.queryXML("select * from PAISES where NOME_PAIS = :nome", "BRASIL");

{...}

Vamos ver o que esse código faz.  A primeira linha cria um objeto Session o qual estabelece um canal de acesso a um banco de dados em particular (MySQL neste exemplo).   ExaQuery suporta atualmente os seguintes bancos de dados:

  • Oracle
  • Firebird
  • MySQL
  • Postgre
  • SQL Server

Na segunda linha criamos um objeto DataStore.   A interface DataStore expõe ao desenvolvedor uma API de acesso a dados com dezenas de métodos que implementam as operações DML mais comuns, como consultas, updates e transações.  Uma característica distinta dessa interface é a sua natureza “inline” em que maioria das operações são realizadas através da chamada a apenas um método – uma decisão de design deliberada para tornar mais simples o uso da API.

Finalmente, na terceira linha, fazemos uma consulta SQL parametrizada – ExaQuery suporta parâmetros nomeados – que retorna uma string contendo o XML representando o resultado da consulta.   Outros métodos de DataStore podem retornar Value Objects, coleções, JSON, ResultSets, tipos primitivos Java ou tipos definidos pelo usuário.

O pequeno exemplo foi uma breve introdução e existem inúmeras situações de uso real em que a API de ExaQuery fornece uma solução igualmente simples de implementar e manter.  Examinaremos algumas delas nos próximos posts.

Curiosity: 7 Minutos de Terror

Sequência final de pouso do Curiosity

Com esta frase pouco amigável os engenheiros do JPL definiram o que esperavam do pouso da sonda Curiosity na superficie de Marte – o que aconteceu na madrugada do dia 5 de Agosto (horário de Brasilia).  O “Terror” referia-se à sequência automática de pouso usada para colocar a nave intacta na superfície do planeta vermelho – e com tolerância a erros igual a zero. Sete minutos é o tempo decorrido desde o contato da espaçonave com a camada mais alta da atmosfera marciana até o pouso, o que é algo alucinante. Tudo precisa acontecer na sequência certa e no tempo certo, caso contrário anos de planejamento e muito dinheiro vão direto para o lixo.

Pousar um objeto voando a 13.000 milhas por hora (cerca de 21.928  km) na superfície de Marte não é nada fácil já que a atmosfera é rarefeita (100 vezes menos densa que na Terra). Por isso os engenheiros tiveram que imaginar e implementar uma manobra extremamente complexa conhecida como EDL –  Entry descent landing.

Primeiro, o Curiosity entra na atmosfera protegido por um escudo térmico que deve suportar um enorme arrasto aerodinâmico e temperaturas de até 1600 graus.  Durante esta fase os computadores da nave devem acionar pequenos jatos para manter o ângulo de descida precisamente alinhado, sob pena de desintegrar a nave.

Em seguida é aberto o maior paraquedas supersônico jamais usado em um veículo espacial, para reduzir a valocidade a até cerca de 400km por hora.   Nesse momento o escudo térmico que protege os sensíveis equipamentos do Curiosity é liberado para que os radares possam “enxergar” o solo e alimentar o sistema de pouso automático com dados.   Com o auxílio dos radares a nave deve localizar um ponto dentro de uma cratera de 3 bilhões de anos, previamente selecionada.   Devido à grande distância que separa a Terra de Marte, a esse ponto da missão os cientistas não podem fazer nada a não ser esperar – tudo é controlado pelo software de navegação do Curiosity.

O próximo passo é ativar oito motores-foguete para reduzir ainda mais a velocidade, fazendo com que a nave desça gentilmente em direção ao local de pouso.  Mas isso não é tudo:  a enorme coluna de poeira provocada pelos motores ao chegar perto da superfície pode danificar os equipamentos mais sensíveis do Curiosity,  por isso a 20 metros acima do solo os computadores fazem a nave pairar (como um helicóptero) e acionam uma espécie de guindaste para descer o Curiosity através de cabos até a superfície.  Quando as rodas tocarem o solo, sensores avisam à nave para cortar os cabos do guindaste e voar para longe – para não acabar “pousando” em cima do robô.

Sete minutos após esses eventos,  engenheiros e cientistas no JPL recebem a notícia.  Tudo aconteceu com perfeição !

Campus Party Recife 2012

“Quando você vê tudo na teoria, pode achar chato. A prática é outra coisa, você pode estar desperdiçando o seu talento. A grande coisa na vida é por a mão na massa e descobrir onde você se encaixa, do que você gosta.  Assim, você pode chegar a ser um super star”.

Palestra sobre robótica feita por Mike Comberiate, engenheiro da Nasa, Campus Party Recife 2012.

Flash e Silverlight: Plugins em Crise ?

Desde que a Apple anunciou que não permitiria mais plugins em seus produtos como o iPhone e iPad, dois dos  grandes players da indústria (Adobe e Microsoft)  surpreenderam com mudanças de estratégia relacionadas a seus produtos Flash/Flex e Silverlight.   Quem se mexeu primeiro foi a Adobe ao anunciar que não pretende mais evoluir o Flash Player em tablets e smartphones e recomendando o Adobe AIR como plataforma para desenvolvimento de aplicações nesses dispositivos.   A justificativa foi a dificuldade em acompanhar multiplicidade de arquiteturas existente e “atender necessidades atuais e futuras de seus clientes”.

Já a Microsoft estabeleceu um novo posicionamento para sua plataforma Silverlight (o principal concorrente do Flash)    para o desenvolvimento de aplicações de negócios e como uma das duas alternativas de desenvolvimento para o Windows Phone.   Surgiram inclusive rumores na imprensa especializada que a versão 5 do Silverlight seria a última a ser suportada.   O barulho foi tão grande que posteriormente Redmond se apressou em anunciar que o suporte estaria garantido até 2021 – mas aí o estrago já estava feito.

Mas afinal o que há por trás de todo esse burburinho envolvendo tecnologias já consagradas e agora ameaçadas de “extinção” ? A resposta é o HTML 5.  Trata-se de uma das grandes apostas (ou melhor dizendo, promessas) da indústria no que diz respeito à publicação de conteúdo rico via web que teoricamente dispensaria a necessidade de plugins como o Flash e Silverlight para entregar aplicações ricas e interativas (incluindo 3d e aceleração por hardware) e todo conteúdo altamente dinâmico que temos em nosso dia-a-dia.   Todos os browsers implementariam o padrão e haveria um ecosistema – possivelmente em torno de uma plataforma única – o que ajudaria a reduzir os custos com criação e deployment  de conteúdo.   Mas a realidade não é bem assim.

Embora esteja em desenvolvimento  desde 2004,  ainda não existe uma especificação fechada sobre esta tecnologia e para piorar as coisas os produtores de browsers terão liberdade para particularizar certos aspectos da implementação o que poderá fazer com que voltemos à era onde você era obrigado a criar uma versão de seu software para cada browser !   Obviamente muitos veem nisso um retrocesso, mas os potenciais problemas não impediram tanto a Adobe quanto a Microsoft de abraçarem a causa e seguirem em direção ao HTML 5 – algo amplamente evidenciado nas principais conferências de tecnologia patrocinadas por essas empresas.   Desenvolvedores que investiram tempo e dinheiro  para dominar Silverlight e C# ficaram de cabelo em pé com os cenários demonstrados pela Microsoft  envolvendo HTML 5 e javascript.  Um retrocesso ?  talvez, pelo menos por enquanto.

A questão é que ainda pode levar muito tempo até que o HTML 5 se torne um padrão de mercado – especialmente na esfera altamente especializada que envolve aplicações de uso empresarial.   Sendo assim,  os produtores que tenham projetos em Flex ou Silverlight podem agregar valor com essas plataformas que são robustas, contam com uma comunidade ativa e vibrante e representam o melhor que a indústria dispõe atualmente.   Definitivamente a missão dos plugins não estará encerrada até que o HTML 5 atinja a maioridade e cumpra suas promessas conceituais  – e este tempo ainda está por vir.