6 de Março de 2010 o RiaPT vai voltar ao Porto!

Marca desde já essa data na agenda e prepara-te para passar uma tarde bem disposta juntamente com pessoas que partilham contigo interesses e paixões pela Internet e não só!

Vamos ter speakers a abordar temas de elevado interesse da actualidade que te vão deixar com água na boca para aprender, explorar e procurar as inovações para o design e desenvolvimento das tuas aplicações!

O universo de desenvolvimento de aplicações web está em perfeita erupção! Não são só as tecnologias cliente, mas toda a “pilha” de desenvolvimento com as suas diversas tecnologias, linguagens e ferramentas está a ser posta em causa e cada um quer encontrar o seu nicho nesta realidade. Não perca esta oportunidade de ouvir alguns experts  portugueses na área do desenvolvimento de Rich Internet Applications.

Como se isto não fosse suficiente ainda vamos ter prémios para distribuir pelo pessoal que estiver a assistir que vão desde licenças de software a vouchers de cursos de formação e outros.

Não percam! Dia 6 de Março, no Edifício “Maus Hábitos”, às 14:00, e sim, no Porto!

Inscreve-te em: http://riapt.stagehq.com/events/182/booking/new

Agenda

Regra geral, evito colocar posts de opinião pessoal. Mas desta vez, não consigo não dar a minha opinião.
O anúncio do iPad sem suporte para o Flash Player originou um movimento na blogosfera onde tenho lido de tudo um pouco. Circulam por aí tantos disparates, tantos mitos e pessoas de horizontes limitados, que desta vez não consigo ficar quietinho sem dar a minha opinião sobre o tema. Pior ainda, quando vi alguns comentários perfeitamente rídiculos de tugas de “renome” (que não vou específicar) em blogs, no facebook, twitter e outros.

É sabido que a minha vida roda em redor das RIAs na plataforma Flash, que sou Adobe Certified bla bla, Adobe Community bla bla, etc. Mas também tenho cabecinha para tentar olhar para o mundo de forma imparcial, e acima de tudo pragmática. Até porque, não esqueçamos, há uns anos eu era anti-Flash. E depois ganhei juízo, e aprendi que não se deve criar preconceitos sem conhecermos realmente aquilo de que falamos. E é consoante essa visão que faço este post.

Prólogo

Antes de mais, um pouco de background na coisa.  A Apple lançou este mês o iPad, um meio termo entre um iPhone e um netbook, que em teoria é um dispositivo que se diz por aí ser revolucionário. Porém, o iPad, tal como o iPhone, não traz – nem se prevê que venha a trazer – suporte ao Flash Player. Imediatamente, a blogosfera e o twitter, encheram-se de reacções, onde muitos ditos puristas dos standards, apple-fanboys, ou simplesmente anti-flashers, começaram a festejar o início da morte do Flash. A atitude da Apple é sem dúvida uma afronta à Adobe que vai mexer com a taxa de penetração e credibilidade do Flash Player. E no meio deste hype, li e reli centenas de vezes um conjunto de mitos que por aí circulam, que não me conseguiram deixar impávido e sereno.

Flash vs HTML

Em duas palavras: comparação ridícula. Alhos com bugalhos. Resume-se a:

• HTML-> Documentos
• Flash -> Estados.

Enquanto que o  primeiro (HTML), serve para definir estruturas de dados, o segundo serve para criar aplicações. São duas tecnologias distintas com propósitos distintos. E o problema surge quando um começa a entrar no território do outro: não faz sentido usar o Flash para fazer um blog da mesma forma que não faz sentido usar o HTML para fazer uma ferramenta de manipulação de imagem.

Ambas as tecnologias devem complementar-se.
Para os menos atentos, nós na Webfuel desenvolvemos RIAs na plataforma Flash para a banca (gestão de finanças pessoais) e investimentos (plataformas de trading). Fazêmo-lo usando as boas práticas de Engenharia importadas do mundo J2EE, e puxamos a plataforma ao seu limite (interfaces interactivos e animados, com multimédia, e paradigmas de usabilidade complexos). E fazêmo-lo desta forma porque é possível; porque a plataforma o permite. Perdoem-me os puristas, mas nunca seria possível actualmente fazermos o que fazemos – e como o fazemos – em HTML. Talvez daqui a… 5 anos. E aí o Flash já terá evoluido outros 5 anos…

“O Flash atrasa a minha navegação na net, faz o meu CPU disparar, e os banners irritam”

Verdade seja dita: banners são irritantes. Especialmente aqueles que aparecem sobre o conteúdo das páginas que queremos ver, não nos deixando clicar em nada até que o banner desapareça. Ou aqueles que fazem as ventoinhas do CPU disparar. Ou mesmo aqueles que crasham o browser. Mas a realidade é que tudo é um negócio, e os banners são a maior fonte de receita na internet. E os senhores do marketing ficam todos excitados com animações, sons, e interactividade, e lá surgem os banners em Flash por todo o lado. Colocando realmente a navegação mais irritante. E lenta. E problemática.
E se não existisse Flash (ou outro plugin com penetração semelhante)?
Seria tudo igual. Haveriam banners na mesma. Em Javascript, ou outra tecnologia. Igualmente irritantes, mas possivelmente igualmente (ou mais) pesados para o processador (a performance do Flash Player é superior à do Javascript ).
A culpa não é do Flash Player. Só se for culpado de ser o runtime com a maior taxa de penetração do mercado, e de ser tão fácil e rápido implementar algo impressionante na plataforma Flash.

HTML 5 vai matar o Flash

Há quem julgue que sim, mas Flash não é sinónimo de vídeo. O Flash serve para construir experiências multimédia e software. O HTML 5 não vem para substituir o Flash. Poderá, sim, (e provavelmente assim será) começar a substituir/ser alternativa ao Flash em muitos sites de vídeo (Youtube, etc). Mas mais uma vez, é comparar alhos com bugalhos. É dizer que, assim que o HTML 5 sair, será a plataforma preferencial para fazer aplicações de trading, com realtime data push, advanced charting, acesso à câmara e microfone, etc. Enfim. Nem é fácil comentar este mito, por ser completamente díspare da realidade. O HTML 5 será, na melhor das hipóteses, um substituto daquilo que foi o Flash Player 5. Para não deixar de referir que há sempre o risco das várias implementações de cada browser se tornarem na habitual dor de cabeça dos developers – algo que não existe no mundo da plataforma Flash.

O Flash Player encrava o MacOS…

… tal como o JAVA, o C++, ou mesmo o Javascript ou qualquer outra plataforma. Claro que é rídiculo comparar a estabilidade da Virtual Machine do Flash Player com a da JVM, mas é suficientemente robusta para suportar aplicações críticas de trading a fazer transacções de milhares de dólares diariamente. A acusação à estabilidade do Flash Player não se deve à tecnologia em si, mas sim aos maus developers que andam por aí. E, verdade seja dita, o mundo Flash está repleto deles. Developers que não sabem (nem querem saber) o que são boas práticas. Ou designers que decidiram aventurar-se pelo mundo do desenvolvimento. E aqui, a culpa do Flash Player é mais uma vez a sua alta taxa de penetração, e o facto de ser tão fácil fazer algo impressionante na plataforma Flash.
E depois entram as estatísticas. Se passarmos um dia em frente ao computador, abrimos o Word 4 ou 5 vezes, mas arrancamos o Flash Player umas 50 vezes – pelo menos. Cada SWF – banners, websites, RIAs, vídeos, etc – é uma aplicação diferente feita por pessoas diferentes (sejam bons ou maus developers). Não é preciso ser-se expert em estatística para terminar o raciocínio. A realidade é que diariamente me deparo com tanta coisa mal implementada na web que pessoalmente até fico admirado com a robustez do Flash Player.
Aqui na Webfuel somos pelo menos 6 pessoas a puxar diariamente o Flash Player aos limites, de onde pelo menos uma é adepta (quase fanática) da Apple. E a realidade é que o Flash Player se aguenta perfeitamente com as nossas experiências e produtos.
Ainda assim, admito que há margem de melhoria na robustez do Flash Player, talvez começando por distribuir melhor os recursos consumidos por cada SWF, impedindo que um SWF problemático possa afectar outro.

Falta ainda dizer que, verdade seja dita, o Flash Player não encrava nenhum sistema operativo. Encrava, sim, o browser. E nos melhores browsers encrava apenas o tab onde o SWF ranhoso encravou.

O Flash Player é demasiado lento para correr no iPhone. E no iPad.

A Apple acusa a Adobe do Flash Player consumir demasiados recursos, pelo que não o poderia colocar a correr no iPhone. Mas a realidade é que o Flash Player 10.1 – que foi especificamente optimizado para dispositivos móveis – corre em telemóveis com poder de processamento teoricamente inferior ao do iPhone. O que é suspeito.

No entanto, para piorar, o iPad também não suporta o Flash Player. Quer isto dizer que a Apple lançou um produto de $600 que não tem poder de processamento para o Flash Player?

Segundo a Adobe, ao contrário da Microsoft, a Apple nunca ajudou a Adobe a optimizar o Flash Player para o MacOS. Segundo a Apple, a Adobe é preguiçosa.

Conclusões

A minha preocupação é desenvolver produtos que façam sentido para o consumidor final. Produtos de software ubíquos, acessíveis de qualquer local, computador, sistema operativo, ou browser, com um único codebase, e com preocupações acrescidas ao nível do interface e interactividade. Rich Internet Applications. Este é o futuro, podermos aceder às nossas aplicações e dados a partir de qualquer local.
E estando a trabalhar para isso há alguns anos, a realidade é que me sinto ofendido de ser apanhado no meio de uma guerrazinha de egos (e de milhões de dólares) onde no fundo quem fica a perder somos todos nós – tanto developers como consumidores.

Ontem realizei uma apresentação no AdobeUserGroup sobre a ligação do Flash à placa Arduino.

A Adobe publicou ontem uma imagem muito interessante e elucidativa para representar o ecosistema da Flash Platform. Na imagem é possível ver o universo das ferramentas Adobe, e a forma como se interligam.

À esquerda, a azul claro, temos as ferramentas de design: After Effects, Adobe Illustrator, Fireworks e Photoshop. Com estas ferramentas os designers podem criar o aspecto gráfico das aplicações / sites / experiências / etc, sendo este exportado num novo formato, o FXG. O FXG é um novo formato da Adobe baseado em XML para representar elementos gráficos, e que é compatível com o universo que circunda a plataforma Flash.

A azul escuro temos as aplicações de desenvolvimento: o Flash IDE, Flash Catalyst (anteriormente conhecido por Thermo), e o Flex Builder. O Flash IDE e o Flex Builder são os nossos já velhos conhecidos, sendo o primeiro mais virado para Interaction Designers que procuram um IDE visual, e o segundo para developers que procuram um IDE virado para código. O Flash Catalyst é uma ferramenta que ficará no meio, entre o Flash e o Flex Builder que permitirá a Interaction Designers utilizar um ambiente gráfico e intuitivo para importar layouts feitos nas ferramentas de design, e convertê-los através de alguns cliques para aplicações, podendo ser adicionada interactividade. O resultado o Flash Catalyst é MXML (bem formado, segundo dizem) que depois é entregue aos developers para implementarem toda a parte dura do código. Segundo se diz, o Flash Catalyst pode também carregar MXML já alterado pelos developers (corrijam-me se estiver enganado), pelo que permitirá que ambas as equipas – developers e designers – possam trabalhar ao mesmo tempo, recorrendo a um source control. O Flash Catalyst está ainda a um ano de ser lançado em versão final, pelo que durante este período serão certamente disponibilizadas versões beta e de preview.

A cinzento, em cima, temos o Flex SDK, a framework de eleição para desenvolvimento de RIAs. É composta por um conjunto de componentes, e ferramentas que assentam em Actionscript 3, para desenvolvimento rápido de aplicações. O Flex SDK está actualmente na versão 3, mas a versão que se segue (nome de código: Gumbo) vai trazer novidades absolutamente estontantes. Sendo open-source, é possível acompanhar o desenvolvimento do Gumbo, e inclusivé, fazer já aplicações com a actual versão. As milestones do Gumbo são:

• lançamento do MAX preview agora durante o MAX;
• versões Beta 1 e Beta 2 na primeira metade de 2009 (aposto em Fevereiro e Maio);
• versão final na segunda metade de 2009.

As ferramentas acima “não fazem mais” que gerar ficheiros SWF que são depois interpretados e executados nos devidos runtimes: o Flash Player, que corre dentro do browser, e com limitações de acesso à máquina do utilizador (obviamente por motivos de segurança), e o Adobe Air, que permite que os SWFs possam ser instalados nos computadores dos utilizadores e correr como aplicações desktop, com acesso à maquina do utilizador como qualquer outra aplicação (i.e. leitura do disco, clipboard, etc). O Flash Player está neste momento na versão 10 que introduz uma panóplia de funcionalidades fantásticas: suporte nativo a 3D, FileReference local, suporte a filtros avançados (Pixel Bender), suporte avançado a texto, melhor performance com suporte a aceleração pela placa gráfica, etc.

De referir que os runtimes acima são compatíveis com os principais sistemas operativos, nomeadamente Mac, Windows e Linux – e a grande novidades do Max: graças ao Open Screen project temos também o Flash Player 10 em Symbian, Windows Mobile, Wii, Playstation, etc.

As aplicações (SWFs) que assentam sobre os runtimes acima serão fat clients descarregados para as máquinas dos utilizadores (pelo browser, ou instalados com Adobe Air), e que poderão posteriormente comunicar com um servidor para trocar dados. Essa comunicação pode assentar em diversos protocolos e formatos, tais como simples texto, XML, SOAP (web-services), JSON, e AMF – o formato de dados em que assenta o Flash Remoting. Estes formatos podem ser trocados sobre HTTP ou HTTPs, Sockets, RTMP, entre outros.

Esta panóplia de formatos de comunicação permitem comunicar com quase todas as tecnologias server-side existentes no mercado, pelo que aplicações feitas em Flash são facilmente integráveis com plataformas existentes, sejam elas Adobe ou de terceiros. Da Adobe, temos os servidores especificamente criados para Flash: BlazeDS e Flash Media Server que introduzem funcionalidades de Data e Multimedia Streaming, entre outras. Depois temos os servidores ColdFusion e LiveCycle ES, de onde a minha funcionalidade favorita deste último é de longe o facto dos servidores poderem tomar a iniciativa de contactar os clientes e empurrar dados (i.e. dados dos clientes sincronizados automaticamente com o servidor). Apesar da Adobe fornecer as suas próprias soluções server-side, como dito acima aplicações Flash podem ser facilmente integradas com outras soluções de backend de entidades terceiras, como, PHP, JAVA, .NET, etc, desde que implementem algum dos protolocos de comunicação acima referidos. Como exemplos de plataformas, temos BEA, SAP, salesforce.com, WebSphere, Zend, etc.

Vendo esta imagem, é inevitável sentir orgulho de ter acreditado e escolhido um dia o caminho da plataforma Flash. Aquilo que começou um dia como uma ferramenta para adicionar animações a páginas Web, é hoje em dia a mais poderosa plataforma para criar aplicações distribuídas e interactivas. As nossas amigas RIAs.

Depois de vários meses em beta no Adobe Labs, chega a versão final do tanto esperado Flash Player 10.

É a primeira vez, na história do plugin, que é disponibilizado a versão para as plataformas Windows/Mac/Linux/Solaris ao mesmo tempo.

Relembro que das novidades mais importantes:

• Suporte para 3D
• Novo text engine (Saffron 3.1)
• RTMFP ( RTMP sobre UDP )
• Novo Codec de Audio (Speex)
• Novas APIs para desenhar
• Novo tipo de dados <Vector>
• Gerar som dinamicamente
• Acesso local ao FileSystem através de interação do utilizador

No labs encontra-se disponivel as release notes assim como os problemas que ainda persistem e o player pode ser encontrado aqui.