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

Javascript a linguagem que não serve para nada, serve para tudo, que não presta e é muito boa… mais à frente entenderão.

Com a introdução do conceito Web 2.0  e com o aparecimento de frameworks como Jquery, Prototype ,Mootools,etc.. começaram a surgir RIAs em HTML/Javascript, sem recorrer a plugins – aplicações como Gmail, GoogleDocs, GoogleCalendar e  mais recentemente o GoogleWave (mencionei estas mas podia ter mencionado ‘N’; estas se calhar já todos nós experimentamos). No meio de tudo isto nasce também o conceito de Ajax (Asynchronous JavaScript and XML), a tecnologia base que permite um novo tipo de interacções do browser com o servidor.

O Javascript até então era uma “besta” adormecida que era vista por muitos como uma linguagem de “designers” sem grande valor, assim como o Flash/Actionscript era visto antes da última versão do ActionScript a 3.0.

E porquê todo este “frenesim”? Porque o HTML/Javascript estão prestes a ser revistos e vem ai o HTML5 e o ECMAscript 3.1 aka Harmony aka ECMAscript 5 que vai ser a nova base do Javascript  e que vão trazer coisas novas como:

• Web Forms
• Audio/video
• Canvas
• Drag & Drop
• Editable
• History api
• Undo
• XDomain
• Messaging
• Storage
• Geolocation
• Databases
• QuerySelector
• Sockets
• Workers

Entre outras. Deixo também aqui um vídeo interessante de uma apresentação que fala de algumas especificações e dá exemplos práticos. Estas coisas já podem ser usadas hoje em dia, basta para tal termos um browser “moderno”. Existe uma lista disponibilizada pelo Yahoo das compatiblidades de cada browser, onde podemos consultar em que browsers é que vai funcionar o quê, e dependendo do nosso target/necessidades ponderar se é viavel ou não.
E o que é possivel fazer hoje em dia com Javascript? Frameworks(vou omitir Jquery e companhia) etc.. fica uma lista de links/Exemplos :
Aqui podem ver  uma compilação de 47 demos de CSS3 e as suas capacidades, desde relógios, cubos em 3d, rotações de imagens, enfim dá para ter uma noção geral do que aí vem.
E aqui um impressionante proof of concept com Javascript e o novo elemento <canvas>  do HTML5 que é uma versão do jogo “Another World”.

Frameworks:
http://sproutcore.com/ – A framework com o backup da apple.
http://cappuccino.org/ – Uma framework que apesar de não se programar directamente em Javascript o resultado final é javascript e tem um excelente demo http://280slides.com/ que vale a pena ver para ficar com uma noção das possiblidades que esta framework oferece.
http://qooxdoo.org/
http://www.extjs.com/
http://mochaui.com/
http://www.effectgames.com/effect/ – uma Framework totalmente dedicada á criação de jogos em Javascript.

Deixo aqui mais uns artigos que acho interessantes sobre este tema:
http://www.stimuli.com.br/trane/2010/feb/01/the-web-doe-not-need-flash/
http://lifehacker.com/5416100/how-html5-will-change-the-way-you-use-the-web/

Podia estar aqui o dia todo e provavelmente nem chegaria a metade do que existe por aí mas qualquer pesquisa no Google sobre o tema e chega-se lá. E isto é apenas uma parte do que o javascript tem actualmente para oferecer – sim há mais.

Pois, como todos sabemos uma aplicação web não é só client side (e o javascript serve para tudo como eu disse na introdução, ou já se esqueciam?). O Javascript também está a abarbatar o server side e começa também a ser uma linguagem a considerar.
Há cerca de dois anos atrás no SapoCodeBits 2008 conheci o Srº Mário Valente(MV), e foi quando ouvi falar nisto pela primeira vez, obviamente que o que me veio à  cabeça foi “O quê??? Javascript???”. Mas depois de ouvir os argumentos dele, fez-se luz. Passaram-se dois anos e tenho a dizer que as previsões estavam certas. E hoje em dia já se vê Javascript no servidor a fazer as mesmas coisas que qualquer outra linguagem de servidor. Neste post do blog do MV ele faz uma descrição da framework de desenvolvimento que ele idealiza.Na semana passada disse também possivelmente ter encontrado essa framework – chama-se “Pintura”.
Ainda não experimentei o pintura. Tenho feito apenas uns testes e lido umas coisas sobre Node.js, que é considerado por um dos criadores do Django(python) como “the most exciting new project I’ve come across in quite a while“ .

Ficam aqui uns links sobre o tema javascript-server-Side:
A Apresentação do nodeJS aconselho a verem para perceberem as potencialidades.
http://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/

Continuando… Para finalizar e como o javascript é uma verdadeira “besta”, não nos podemos esquecer que numa aplicação Web temos uma terceira  componente que é a  base de dados. E sim o Javascript também está lá  bem representado, temos o CouchDB que é uma document-oriented database, que guarda documentos em Json (Javascript Object Notation) e oferece uma forma query e indexação através de funções de MapReduce, funções estas programadas em Javascript.

Uns links para quem quiser investigar sobre isto:
um pequeno video nas GoogleTechTalks sobre couchDB
http://jan.prima.de/~jan/plok/archives/108-Programming-CouchDB-with-Javascript.html

Bem esperero não vos ter maçado com esta coisa do javascript e deixo aqui um cartoon engraçado “roubado” ao MV que por sua vez também “roubou” aqui. Espero que dêem  uma vista de olhos no Javascript que é capaz de vos ser útil no futuro.

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.