Comecei recentemente a dar os primeiros passos na aprendizagem de Maven, e apesar de ainda ser um novato achei por bem partilhar as razões pelas quais esta tecnologia é tão interessante.

Apesar de utilizarmos Maven há já algum tempo nos nossos projectos na Webfuel e de conhecer os seus benefícios, nunca tinha investido tempo na sua aprendizagem visto que a configuração dos projectos com Maven estava a cargo de uma empresa nossa parceira (Web-Responsive). Sou, portanto, tenrinho no assunto, mas sinto-me compelido a partilhar as razões pelas quais vale a pena aprender Maven.

Este post não é um tutorial a explicar como se usa, mas sim uma descrição de alguns dos problemas (use cases) que o Maven resolve em projectos complexos. De notar ainda que o Maven não é específico ao desenvolvimento de RIAs, mas sim aplicável ao desenvolvimento em qualquer tecnologia que tenha um plugin para Maven. Para Flex existe o flex-mojos que cobre grande parte dos tópicos referidos neste post, mas não todos (ainda). Diria que no mundo J2EE, aí sim, o Maven se porta brilhantemente – por exemplo, na configuração de um JAVA + Spring + Hibernate + BlazeDS + Springflex + montes.de.outras.libs.

O que é o Maven?

O Maven é uma ferramenta poderosa para gestão de projectos, gestão de dependências, gestão de versões, automatização do processo de build (compilação, unit tests, reporting, etc), configuração de ambientes de desenvolvimento, entre outras. É uma ferramenta com cerca de 3 megas que se utiliza através da linha de comandos (ou através de alguns plugins para Eclipse, como o m2eclipse), para executar diversas tarefas sobre um (ou vários) projecto(s), regra geral associadas à sua compilação, mas sobretudo manutenção. Bem, o ideal é mesmo ver os exemplos mais abaixo…

(Mais prólogo) Esqueçamos o modelo de projectos gigantes…

É importante compreender que existe uma maneira “à-la-Maven” para a estruturação de um projecto. Um “projecto físico” deve ser separado em vários sub-projectos/componentes/bibliotecas (artefactos), com dependências entre eles. A noção de um projecto, com Maven, pode resultar em 10 ou mesmo 100 “projectos Eclipse”.  Por outras palavras, o projecto “my-huge-crm-application” quando criado “à-la-Maven” deve ser dividido em “my-crm-users”, “my-crm-reports”, “my-crm-costumers”, “my-crm-commons”, “my-crm-config”, “my-company-lib”, “my-3rdparty-lib”, etc – podendo-se atingir com facilidade 10 ou 20 projectos diferentes, com dependências uns dos outros (isto é, o my-crm-commons.jar é usado pelo my-crm-costumers, etc).

À primeira vista, pode parecer mais confuso, mas na realidade resulta numa maior simplicidade – graças à elegância do Maven, como veremos adiante.

O Maven lida com uma simplicidade extrema com as dependências entre projectos e com o processo de build – por exemplo, ao compilar um projecto que depende de outro, o Maven irá descarregar o outro projecto de um repositório onde possa estar instalado, ou se não o encontrar, mas tiver “acesso” ao código fonte, compilar o outro projecto -, e graças a esta arquitectura de gestão de dependências, torna-se relativamente fácil acoplar, desacoplar e substituir projectos/módulos/dependências num projecto.

(Ainda mais prólogo) Algumas notas prévias

Caso 1: Configurar um projecto do zero é demorado e aborrecido

O Maven resolve essa tarefa em dois segundos com um único comando, recorrendo a algo conhecido por “archetypes”. Como? Escrevendo:

mvn archetype:generate

O Maven irá fazer algumas perguntas (tipo de projecto, package, etc) e irá então criar uma estrutura de directorias base com alguns ficheiros necessários (ou dummy) tipicamente necessários nesse tipo de projectos, utilizando uma estrutura de pacotes pré-definida, e criará um ficheiro pom.xml de base. A estrutura de directorias usada pelo Maven obedece a uma *convenção*, normalmente muito bem definida, que torna permite que developers que estejam a analisar um projecto  pela primeira vez entendam rapidamente a sua estrutura, e onde encontrar todos os recursos. Além disso, a convenção usada pelo Maven reduz em *muito* a complexidade dos arquivos pom.xml do Maven (especialmente quando comparando ao Ant), pois não é necessário adicionar configurações extra ao pom.xml – O Maven irá “automaticamente” encontrar os recursos necessários nos locais correctos, se as convenções forem seguidas – mas, claro, os developers podem fazer override às convenções, embora não seja recomendável.

Outro dos desconfortos na criação de um projecto a partir do zero, é a configuração do projecto no Eclipse. Descarregar as dependências, adicioná-las à classpath no Eclipse, etc…, e depois fazer isto novamente em cada um dos postos de trabalho de uma equipa. Porém, graças ao maven-eclipse-plugin, basta um comando para gerar estas configurações. Fazendo:

maven eclipse:clean eclipse:eclipse

serão criados automaticamente os ficheiros de configuração do Eclipse (.project, e restantes), de acordo com as dependências e tipo de projecto definidos no pom.xml. A partir daí, basta que em cada posto de trabalho se faça um “Import Eclipse Project” no Eclipse, onde regra geral fica tudo maravilhosamente configurado. Graças ao pom.xml o Maven saberá o suficiente para criar correctamente os ficheiros de configuração do Eclipse. Claro que existem centenas de diferentes tipos de projectos no eclipse com configurações diferentes, e o maven-eclipse-plugin não conhece todas. Mas para JAVA, tem-se portado suficientemente bem para 90% dos meus casos. Os outros 10% são resolvidos facilmente adicionando algumas configurações adicionais no pom.xml.

Em resumo, a utilização de archetypes permite criar a estrutura e configuração de projectos a partir do zero, e o maven-eclipse-plugin permite criar e *actualizar* os ficheiros de configuração do Eclipse, sem ser necessário configurar projecto a projecto cada um dos projectos em cada um dos postos de trabalho à mão (isto, para JAVA, regra geral).

Caso 2: O meu projecto tem 20 dependências, e cada dependência também tem 10 outras dependências… Além de ser confuso, perco imenso tempo à procura das bibliotecas, a descarregá-las e configurá-las

Com o maven, é bastante simples. No pom.xml basta adicionar o seguinte XML para especificar que o projecto tem uma dependência do spring-flex, por exemplo:

         <dependency>
             <groupId> org.springframework.flex </groupId>
             <artifactId> spring-flex-core </artifactId>
             <version> 1.5.0.BUILD-SNAPSHOT </version>
         </dependency>

E aí basta correr:

mvn install

O Maven irá automaticamente encontrar a dependência (chamada de “artifact”) – pesquisando num conjunto de repositórios de dependências -, fazendo o download da mesma e “instalando-a” no seu repositório local. Irá fazer o mesmo para todas as dependências de cada dependência recursivamente, pelo que não temos que perder tempo com isso. E a partir daí, sempre que compilar com Maven, este irá adicionar cada uma das dependências ao classpath do compilador automaticamente.

A integração com o Eclipse também é incrível – ao executar:

mvn eclipse:clean eclipse:eclipse

o maven irá actualizar (na verdade, irá recriar) os ficheiros de configuração do Eclipse e adicionar as dependências correctamente ao classpath do projecto. Por outras palavras, algo que regra geral pode ser um autêntico pesadelo (definir as dezenas de dependências de um projecto, descarregá-las da internet, configurá-las, e por sua vez fazer o mesmo para as dependências de cada dependência…), é resolvido elegantemente em poucos segundos!

Esta simplicidade na gestão das dependências não só facilita a configuração das bibliotecas externas necessárias aos nossos projectos, como fomenta a separação dos nossos projectos em dezenas de módulos e bibliotecas, visto que com Maven se torna relativamente simples organizar todas as relações entre projectos.

Caso 3: Build através da linha de comandos

Com Maven, iremos utilizá-lo inevitavelmente para compilar.  A compilação é feita através de plagins, que invocam os compiladores com as directrizes de compilação apropriadas, de acordo com o pom.xml. Isto é, não definimos os argumentos dos compiladores; definimos sim a configuração do projecto, e o maven trata de definir os argumentos, regra geral automaticamente! Além da compilação, o Maven irá utilizar o resultado desta para executar tarefas adicionais, como a execução de unit-testing, geração de relatórios, envio de emails quando ocorrem erros de compilação, etc.

Algo extremamente elegante no Maven, é a forma como ele compila vários projectos em “simultâneo”, recursivamente de acordo com a ordem das dependências. Algo que iremos ver posteriormente

Caso 4: É difícil gerir diferentes versões dos meus projectos/bibliotecas e das suas dependências

Artefactos (módulos, bibliotecas, etc) possuem sempre um número de versão que lhes é inerente. Isto é, a biblioteca log4j poderá existir na versão 1.1, 1.2, etc. Isto significa que se o nosso projecto precisar do log4j 1.3, basta abrir o pom.xml, localizar a zona onde a dependência é definida (ver o caso 2), e mudar a versão para 1.3. O Maven irá descarregar automaticamente a versão 1.3 e actualizar as definições do projecto. Posteriormente, ao correr mvn eclipse:clean eclipse:eclipse, o Maven vai ainda reconfigurar o Eclipse com a nova versão da dependência. Agora imagine-se que por alguma razão é preciso voltar à versão 1.1 do log4j. Simples. Basta mudar no pom.xml a versão da dependência para 1.1, e o Maven trata do resto.

Mas o que acontece com suas próprias bibliotecas (aliás artefactos) – como são geridas as versões? Sempre que é executado o “mvn install”, o maven faz o build ao projecto, vai criar o package correspondente (i.e. Jar, War) e vai usar o número da versão definido no pom.xml para instalar o artefacto compilado no repositório local (ou online). Um repositório não é mais que um género de “base de dados” de bibliotecas gerida automaticamente pelo Maven.

Imagine-se que estamos a implementar o projecto A v1.0, que depende do projecto B v0.5. Temos ainda o projecto C v0.2 que também depende do Projecto B v0.5. Quando se faz o build install do projecto A v1.0, como este depende de B v0.5, o Maven vai primeiro fazer build, (package), e instalar o projecto B v0.5 e só depois o mesmo ao projecto A. Por sua vez, ao fazer build install ao projecto C v0.2, como o artefacto B v0.5 já existe e está instalado, o Maven não recompila o projecto B (excepto se houverem mudanças no código), usando a versão do projecto B v0.5 instalada no repositório.

Agora imaginemos que evoluimos o projecto B, actualizamos a versão para v0.6 no pom.xml. Estas alterações são necessárias ao projecto A, pelo que mudamos também o versão na dependência definida no pom.xml do projecto A. Porém, o projecto C ainda depende da versão v0.5 do projecto B, e não quer as novas alterações. O maven gere isto confortavelmente, pois irá simplesmente usar a versão do artefacto necessária, já previamente instalada no repositório.

Ou seja, elegantemente conseguimos ir evoluindo as versões das nossas bibliotecas “sem termos que nos preocupar” com quebrar a compatibilidade com projectos que dependem das mesmas, visto que o número de versão toma aqui um papel muito importante, facilmente gerido pelo Maven. Na realidade, é tão fácil, que quase nos esquecemos de porque é que era tão complicado lidar com diferentes versões das bibliotecas…!

Caso 5: O meu projecto consiste em 20 projectos de Eclipse, dependendo uns dos outros e é preciso compilá-los na ordem correcta para que tudo funcione

Esta é uma tarefa aborrecida no Eclipse, para a qual normalmente usamos o Ant. Mas que o Maven gere de uma forma muito simples, e confortável. Relembrando, cada projecto tem um ficheiro  pom.xml. Os projectos podem ser organizados em níveis. Por exemplo:

Cada um dos (artefactos) acima possui um pom.xml. Nos pom.xml “parent”, adiciona-se:

 <modules>
      <module>ProjectA-server</module>
      <module>ProjectA-flex-client</module>
  </modules>

Quando o maven é executado no projecto base, irá analisar a configuração dos módulos, e tentar executar primeiro o build em cada um dos módulos definidos, e por sua vez, em cada um dos sub-módulos, recursivamente na ordem correcta de dependência, “instalando-os” no repositório local. Mas claro, é sempre possível indicar ao Maven que queremos compilar só um projecto.

Caso 6: O projecto está a ser implementado numa equipa, mas é penoso configurar todos os projectos no Eclipse um a um em cada um dos postos de trabalho

Os ficheiros de projecto (.project) do Eclipse são específicos da máquina em que estão (i.e. um .project configurado no meu computador provavelmente não funcionará no computador do lado), e portanto não é boa prática colocá-los no SCM para partilhar com a equipa. Isto quer dizer que normalmente todos os elementos da equipa têm que criar à mão um novo projecto no Eclipse, configurar as dependências, definir a build path, etc, etc. Por vezes, estas configurações são até um pouco complicadas e demoradas, e algo corre mal, pelo que alguém tem que andar a saltar de estação em estação a ajudar a configurar o ambiente de desenvolvimento. E o pesadelo repete-se sempre que há uma alteração à configuração (novas dependências, novas versões, etc).

Com o Maven, como já foi referido anteriormente, queremos evitar de mexer com nas configurações de projecto do Eclipse. Por outras palavras, o Maven irá, regra geral, tratar desta tarefa automaticamente por nós. Quando escrevemos:

mvn eclipse:eclipse

O Maven irá ler o pom.xml, e usá-lo para criar os ficheiros de configuração do Eclipse para esse projecto, e para todos os sub-módulos desse projecto (ver Caso 5). Depois basta fazer um “Import > Eclipse project” no Eclipse, e já está, pronto a trabalhar. Naturalmente, já tinha referido isto no caso 1, mas voltei a repeti-lo aqui para reforçar o quão útil é este comportamento no desenvolvimento em equipa, especialmente na configuração inicial do ambiente de desenvolvimento de um novo projecto.

Mais possibilidades

Este post podia alongar-se em muitas mais páginas. Como ainda estou a estudar maven, este é o ponto a que já cheguei:

Mas ainda me falta:

Em resumo…

Resumindo, qualquer pessoa numa equipa pode executar um único comando que irá:

Interessa também realçar que os ficheiros pom.xml acabam por se tornar em manuais/guias valiosos para novos developers entenderem muito rapidamente a organização de um sistema complexo. Outro facto de realce, é que o plugin m2Eclipse possui um interface gráfico para editar e gerir os ficheiros pom.xml, simplificando em muito a vida na fase de configuração do projecto.

João Saleiro (Webfuel)

No FlashCamp 2010 a apresentação que levei conjuntamente com o Jorge Varandas recaiu sobre três temas sendo eles: Perlin Noise, SEO for Flash, Inverse Kinematics.
Neste artigo vou escrever sobre o primeiro tema, Perlin Noise.

O Perlin Noise é uma função matemática que gera uma pseudo-random textura que podemos descrever como um grandient noise.
O autor desta função foi Ken Perlin, desenvolveu-a para o filme clássico TRON em 1982 e melhorou-a em 2002. Valeu-lhe uns prémios e merecido reconhecimento. (Por ironia do destino a nova versão do TRON, TRON Legacy está ai trailer)

No Flash o PerlinNoise é um método da classe bitmapdata e têm uma grande utilidade nas mais variadas situações, onde a nossa imaginação é o limite. É muito usada em efeitos como nuvens, fogo, água corrente, backgrounds .. etc

Dica: O perlinnoise é intensivo para o processador proporcionalmente ao tamanho do bitmap e aos parâmetros como por exemplo o numero de octavas etc.. para resolver este problema é usual usar um bitmapdata pequeno e depois fazer scale.

Exemplos de aplicação profissional do perlinnoise em projectos:

NEVOEIRO

Com meia duzia de linhas usando o alpha Channel e uma mascara criamos o efeito de nevoeiro

PAPAGAIO

À mais ou menos 2 anos desenvolvemos um m-rec extensível para a Opel onde o utilizador podia interagir com um papagaio. Distorcemos as fitas do papagaio usando perlinnoise para dar uma sensação de vento.

JATO DE LIQUIDOS E EXPLOSÕES

No caso do jato de líquidos existe uma animação simples de scale e alpha a um png onde é aplicado uma distorção, é o mapa da distorção que é gerado com o perlinnoise.
Já nas explosões o perlinnoise serve de mapa de fluxo das partículas.

EXPLOSÃO NOME

MAPA DE FLUXO

O mapa de fluxo é um perlinnoise que é modificado de 5 em 5 segundos, dai a variação das partículas mais acentuada neste intervalo de tempo.
Este mapa serve para encontrar o vector de deslocação de cada partícula, retirando-o através das informações do canais de cor. Com 4 canais (ARGB) podemos fazer corresponder 4 variáveis com variação entre valores inteiros de 0 a 255.
Para termos reacção ao rato bastou desenhar no mapa de fluxo um circulo na posição correspondente ao Mouse.

APLICAÇÃO DO EFEITO NO SITE COFIDIS MOBILE

Se gostares deixa-me uma mensagem

Paulo Afonso
http://www.semmais.com/

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

Quando se fala em trigonometria geralmente é associada por grande parte a um “bicho daqueles maus” com cosenos, senos e mais um monte de fórmulas.
A verdade é que nos mais variados problemas é constante termos que aliar o actionscript com este ramo da matemática.

- PI:

É um numero irracional, eu normalmente uso apenas a aproximação com duas casas decimais 3,14. O record actualmente do numero mais aproximado é de Fabrice Bellard — um programador, claro!

Mas o que é visualmente este valor PI?

Importa saber que se fizermos um circulo perfeito com um raio de 1 unidade usando por exemplo uma corda, se esticarmos essa corda numa linha recta vamos ver que ela mede 2*PI. Portanto, metade da corda mede PI — um valor aproximado a 3.14159 26535 89793 23846 26433 83279 50288 4197 …. unidades! É a mesma coisa que dizer que o raio cabe PI vezes no arco de meia circunferência (um arco de circunferência de 180 graus).

- Está bem, pronto.. já gravei o que é o PI e agora o que faço com ele?

As funções Math.cos, Math.sin e outras no actionscript aceitam como parâmetro uma variável em radianos, esta variável indicam uma amplitude, um ponto especifico do nosso circulo.

A definição de Radiano

“O ângulo definido no centro de um círculo por um arco de circunferência com o mesmo comprimento que o raio do círculo é 1 radiano”
Ou seja, dizer que o raio do circulo “cabe” n vezes numa determinada parte do arco pode-se simplificar e dizer simplesmente que essa parte mede “n” radianos

Num sistema de coordenadas no plano cartesiano centrando um circulo com uma unidade de raio, fixa-se o ponto (a) mais à direita do circulo e mede-se o arco em sentido contrário ao sentido dos ponteiros do relógio obtendo um segundo ponto (b);
- a medida do arco entre os dois pontos “n radianos” (a verde), corresponde o parâmetro que usamos no coseno e no seno (entre outras funções do actionscript).

Seno

- traça-se uma recta paralela ao eixo dos xx’s que passa pelo ponto b e vai interceptar o eixo dos yy’s obtendo o valor do seno para “n radianos” (a laranja)

Coseno

- traça-se uma recta paralela ao eixo dos yy’s que passa pelo ponto b e que vai interceptar o eixo dos xx’s obtendo o valor do coseno para “n radianos” (a azul)

Isto é a parte chata da coisa, mas é o suficiente para fazermos milhares e milhares de cenas espectaculares .

Problema 1:

- Desenhar os pontos referentes às horas de um relógio analógico com raio de 80 pixeis e centro no ponto (200,122)

Resposta:

Sabemos que um circulo tem um arco de 2*PI, queremos dividir em 12 partes, portanto vamos ter 2*PI/12 como a medida de cada arco.
A partir daqui podemos passar estes arcos para coordenadas x,y usando o coseno e o seno.
Como queremos um raio maior que uma unidade temos que multiplicar os valores obtidos pelo novo raio desejado.

var arco_hora:Number=Math.PI*2/12;// simplificando Math.pi/6
var raio:Number=80;//raio do nosso relogio
this.graphics.lineStyle(4,0xff0000);//vamos por os pontos vermelhos

for (var i:int=0;i<12;i++)
{
var posx:Number=Math.cos(arco_hora*i)*raio;
var posy:Number=Math.sin(arco_hora*i)*raio;
this.graphics.drawCircle(posx,posy,4);
}

Ok, mas isto ficou no ponto (0,0), agora é necessário fazer uma translação para a posição final.

var arco_hora:Number=Math.PI*2/12;// simplificando Math.pi/6
var raio:Number=80;//raio do nosso relogio
var centro:Point=new Point(200,122);//posição central do relógio
this.graphics.lineStyle(4,0xff0000);//vamos por os pontos vermelhos

for (var i:int=0;i<12;i++)
{
var posx:Number=Math.cos(arco_hora*i)*raio+centro.x;
var posy:Number=Math.sin(arco_hora*i)*raio+centro.y;
this.graphics.drawCircle(posx,posy,4);
}

Desafio:

- Desenhar os ponteiros

Dica: Assim por alto podemos por um TIMER de 1000 e no evento TimerEvent.TIMER obtemos a hora e actualizamos os ponteiros.
Os ponteiros podem ser desenhados com

graphics.lineStyle(4,0xff0000);
graphics.moveTo(centro.x, centro.y);
graphics.lineTo(posx, posy);


Cuidados:

O coseno e seno são funções pesadas, o processador queixa-se se quando os usamos intensamente como por exemplo em sistemas de partículas.
Por isso uma leitura a este post do Michael Baczynski é recomendada.

Obrigado,
Paulo Afonso (semmais)
http://www.semmais.com/

Aceitam-se comentários

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.

O ciclo é composto por 5 sessões:

• Desenvolvimento de soluções RIA (8 de Setembro)

Num momento em que o Silverlight 2.0 se encontra em fase terminal de desenvolvimento e já com a licença Go-Live, é importante perceber qual a real capacidade desta tecnologia. Com este WebCast iremos analisar a Arquitectura, Modelo e Ferramentas de Desenvolvimento, relação com o WPF, bem como uma utilização mais avançada com vista a desenvolver uma solução RIA de raíz utilizando esta versão do Silverlight, incluindo questões como gestão do Layout da solução e os controlos standard que são disponibilizados, como Button, Calendar, Listbox, Image, Grid, Slider, TextBox entre outros. Será também analisado o suporte de DataBinding disponibilizado por esta versão.

Inscrição

• Desenvolvimento de soluções RIA -Tópicos avançados (9 de Setembro);

Num momento em que o Silverlight 2.0 se encontra em fase terminal de desenvolvimento e já com a licença Go-Live, é importante perceber qual a real capacidade desta tecnologia. Ao longo deste WebCast iremos dar atenção a tópicos mais avançados do desenvolvimento de Soluções RIA como são os casos da customização da aparência de controlos utilizando técnicas de Templating e Skinning, análise do VisualStateManager, e muito importante o Streaming Adaptativo que permite analisar as capacidades do cliente de forma a adaptar a experiência de utilização tendo como base a largura de banda e a velocidade do CPU. Se o tempo permitir iremos também ter uma primeira visão sobre o que nos espera no Silverlight for Mobile.

Inscrição

• Introdução ao Deep Zoom (10 de Setembro);

Num momento em que o Silverlight 2.0 se encontra em fase terminal de desenvolvimento e já com a licença Go-Live, é importante perceber qual a real capacidade desta tecnologia. Este WebCast tem como objectivo demonstrar como poderão ser melhoradas as soluções RIA desenvolvidas com suporte á utilização da funcionalidade Deep Zoom disponibilizada pelo Silverlight 2.0, e que tem por base a tecnologia SeaDragon criada pela Microsoft Research e que torna mais fácil e rápida a navegação em imagens de elevada resolução.

Inscrição

• Desenvolvimento soluções RIA distribuídas (11 de Setembro);

Num momento em que o Silverlight 2.0 se encontra em fase terminal de desenvolvimento e já com a licença Go-Live, é importante perceber qual a real capacidade desta tecnologia. Através deste WebCast iremos demonstrar as capacidades inerentes a esta tecnologia e que permitem o desenvolvimento de soluções RIA distribuídas, sendo que em primeiro lugar iremos analisar a arquitectura de comunicação (Networking stack) e a robustês da mesma, fazendo uma demonstração do consumo de diversos serviços que utilizam diferentes formas de comunicação, como o Representational State Trransfer (REST), SOAP, WS*, HTTP e também comunicações cross-domain. Um dos pontos importantes será também a análise das restrições existentes ao nível da camada de comunicações presente na mesma.

Inscrição

• Framework de testes para Silverlight 2.0 (12 de Setembro);

Num momento em que o Silverlight 2.0 se encontra em fase terminal de desenvolvimento e já com a licença Go-Live, é importante perceber qual a real capacidade desta tecnologia. Com a disponibilização deste WebCasts pertende-se demonstrar que o desenvolvimento deste tipo de soluções também poderá e deverá ser efectuado utilizando Testes unitários de forma a garantir a qualidade do desenvolvimento efectuado ao longo de todo o ciclo de desenvolvimento do projecto, por isso mesmo iremos analisar um conjunto de testes built-in que abragem todos os elementos que foram disponibilizados com o Silverlight 2.0 e também a forma de criar novos ou extender os existentes pois todos eles são Open-Source.

Inscrição

Só tive acesso ao artigo após ter dado entrada na gráfica, pelo que, na minha opinião, há algumas passagens que poderiam ter ficado mais precisas – nomeadamente, ser referida a Microsoft e não ser referida a Adobe (!!!), dar em alguns pontos a sensação de que as RIAs são gratuítas, e confundir-se algumas características que pertencem geralmente às Web Applications como características das RIAs. Ainda assim o artigo refere e bem a importância das RIAs para o negócio.

Coloco abaixo a entrevista original, que é mais específica e pormenorizada, podendo ser muito útil para elucidar algumas questões mais ligadas ao negócio que são feitas habitualmente por quem quer saber mais sobre o assunto. Curiosamente, estas são as questões que me são habitualmente feitas pelos clientes. Recordo que a entrevista não foi feita para publicação mas sim para ajudar o autor do artigo, pelo que poderão haver algumas “gralhas” de português.

A entrevista original

1- O que são as aplicações RIA?

Rich Internet Applications são aplicações com um interface gráfico, funcionalidades e interacção semelhantes ao de uma aplicação desktop, tal como o Microsoft Word, mas que correm dentro do web-browser. Imagine que não precisaria de instalar o Microsoft Word, sendo que para o usar bastaria abrir um endereço no seu web-browser. O endereço http://www.buzzword.com/ pode ser tomado como um exemplo de um processador de texto colaborativo no formato RIA.

2- Porque surgiram estas aplicações?

Este tipo de aplicações surgiu de uma evolução natural do software. Hoje em dia queremos aceder aos nossos dados e aplicações de qualquer local, dispositivo, e sistema operativo. Queremos simplicidade, não ter que passar pelo processo de instalação de software nem termos que nos preocupar com manutenção. Numa empresa, por exemplo, é penoso ter que instalar software em centenas ou milhares de computadores, dar manutenção, fazer actualizações, e por aí adiante – implica elevados custos, e demasiado tempo perdido. Daí as empresas hoje em dia terem convergido para o modelo de “Web-Application” – aplicações baseadas em html que correm remotamente sem terem que ser instaladas nos terminais. Infelizmente, as web-applications apesar de práticas possuem limitações a nível de interface gráfico e funcionalidades, sendo complicado imitar a interacção e objectividade do software desktop. As RIAs são no fundo o próximo passo: pegar no melhor das aplicações Web e das aplicações Desktop e juntar num único conceito.

3- Quais os seus objectivos principais?

As RIAs objectivam o mesmo que qualquer outra solução de software: resolver problemas. O cliente tem um problema, e precisa de uma solução. Essa solução pode ser desenvolvida no modelo “Desktop Application”, no modelo “Web Application”, e agora no modelo “RIA”. Portanto a nível de requisitos funcionais, os objectivos são os mesmos: resolver os problemas de negócio.
Porém, no que toca aos requisitos não funcionais – que se prendem com as características tecnológicas das aplicações – pretende-se com as RIAs disponibilizar software acessível de qualquer local e computador com ou sem restrições de segurança sendo dado especial destaque ao Interface Gráfico e interacção com o utilizador com vista a que o software seja o tão fácil de usar quanto possível. Regra geral é desdenhada a importância do interface gráfico e simplicidade de utilização, sendo esse um dos primeiros pontos que os clientes cortam no investimento – porém, surge a questão: de que serve software que funciona se ninguém o souber usar eficientemente?
Outra característica comum nas RIAs é que facilitam a colaboração: é possível que várias pessoas trabalhem sobre os mesmos dados ao mesmo tempo. Este é por exemplo o principal ponto forte do Buzzword: permite que várias pessoas estejam a trabalhar sobre o mesmo documento, algo que actualmente com o Microsoft Word não é possível.

4- Quem produz essas aplicações (empresas estrangeiras, portuguesas)? Há empresas a trabalhar exclusivamente nelas?

Sobretudo empresas estrangeiras. Posso referir com convicção a Cynergy Systems (http://www.cynergysystems.com/), líder mundial na matéria, a Fantasy Interactive, mais dotada no lado criativo (http://www.fantasy-interactive.com/) e a EffectiveUI (http://www.effectiveui.com/).
Em Portugal o conceito ainda é recente, e só agora se começa a ver algum interesse – em parte, um pouco graças aos www.riapt.org. Sei que existem algumas consultoras interessadas em apostar na matéria devido a contactos regulares que tenho recebido com questões sobre as tecnologias de desenvolvimento, procurando por técnicos especializados, ou solicitando a minha disponibilidade para dar formação e prestar serviços.
Enquanto estive em Madrid no Adobe onAir Tour – um evento sobre o assunto – conheci a Buzz-ID (http://www.buzz-id.com/), uma PME portuguesa que começa a dar cartas interessantes nesta matéria. No meu caso pessoal, comecei em 2005 a reunir esforços para criar uma equipa especializada na matéria – a Webfuel. Nestes dois anos estivemos essencialmente a reunir o know-how, a definir workflows e a preparar-mo-nos para o mercado. Neste momento falta simplesmente o “clique” – os clientes e projectos certos – para o arranque definitivo. (Neste momento já demos o clique e já ninguém nos pára )

5- A quem se destinam estas aplicações?

Estas aplicações são como quaisquer outras aplicações, portanto o destinatário é simplesmente qualquer utilizador de software que precise de uma ferramenta para o ajudar em algo. As RIAs podem portanto destinar-se ao end-user – que precisa por exemplo de ferramentas de manipulação de imagem, de processamento de texto, de agregração de informação, colaboração, etc – ou ao negócio em si – qualquer aplicação de business intelligence. Obviamente que os principais interessados serão aqueles que querem tirar partido do facto de não terem que instalar as aplicações podendo usá-las a partir de qualquer local e dispositivo mas sem se quererem limitar à típica “web application” baseada em HTML. Muitas empresas estrangeiras que trabalham com SAP começaram a desenvolver a camada de front-end das suas aplicações em tecnologias de desenvolvimento de RIAs – como o Adobe Flex -, integrando com os backends SAP existentes. A título de curiosidade, a SAP disponibiliza um livro exactamente sobre a integração com o Adobe Flex, e aborda os conceitos de RIA: http://www.sappress.com/product.cfm?account=&product=H1951

6- Quanto custa a sua criação?

Em termos de negócio, a diferença de uma RIA para outra aplicação reside sobretudo na camada de front-end. O investimento no backend é exactamente o mesmo, sendo que este simplesmente irá expôr os seus serviços tal como anteriormente na forma de Web-Services ou outra solução de comunicação (como o Flash Remoting). O investimento adicional é feito sobre a camada de front-end que implica colocar na equipa de desenvolvimento especialistas em design, interaction design, usabilidade e user experience. Porém, face ao custo total das aplicações habituais, o investimento adicional é ligeiro, facilmente suportável e perfeitamente justificado.

7- Qual o lucro/retorno que as empresas que criam estas aplicações obtêm ou esperam obter?

O ROI não é sobretudo dirigido a quem desenvolve o software, mas a quem o usa. As empresas que criam estas aplicações não são diferentes das outras empresas de desenvolvimento de software. Simplesmente, investiram numa área de ponta, inseriram na sua equipa criativos e especialistas nas plataformas de RIAs, de forma a desenvolver software que resulta na satisfação do cliente pela sua simplicidade de adopção e utilização.
Porém, empresas de desenvolvimento que criem as suas próprias aplicações genéricas podem usufruir de um novo modelo de negócio de distribuição de software denominado de “pay-per-use”. Ao invés de venderem um pacote que o cliente tem que comprar e instalar no seu computador, simplesmente disponibilizam a aplicação na Internet que pode ser usada através de um fee mensal, anual ou simplesmente pontual. (Faltou referir o modelo de negócio Software as a Service). A manutenção é feita simplesmente actualizando a aplicação no servidor central, sendo benéfico para quem desenvolve e para quem usa. Obtém-se um modelo de negócio mais fácil de gerir, e mais justo para ambas as partes. Uma vantagem que interessa realçar é que neste modelo não é possível piratear software. O que o utilizador compra é um acesso periódico à aplicação, pelo que a única hipótese para um pirata é roubar o acesso a outra pessoa.

Em certos casos específicos, também se pode adoptar um modelo de negócio de revenue-sharing, em que a empresa que desenvolve recebe parte dos lucros que a empresa que utiliza gera através do produto de software.
Outro modelo de negócio que não acho tão interessante, é a remuneração por publicidade, em que são colocados anúncios no meio da aplicação. Porém, é uma solução que a meu ver apenas se justifica em aplicações relacionadas com redes sociais online, e que para o negócio em si não faz sentido nenhum.

8- Que género de aplicações vão ser reformuladas para o formato RIA?

Quaisquer aplicações que não estejam dependentes das limitações da largura de banda actual, ou das restrições de segurança dos plugins das tecnologias em que se baseiam as RIAs. A título exemplificativo, podemos ir desde backoffices, CRMs, aplicações B2B, B2C às simples aplicações e ferramentas destinadas ao end-user, como processadores de texto, folhas de cálculo ou editores de imagem.

9- Quais as vantagens/desvantagens deste tipo de aplicações para as empresas clientes?

O custo de instalação de software desktop em centenas ou milhares de computadores é alto. No caso das aplicações empresariais, temos uma redução drástica no custo de deployment, na medida em que basta colocar a aplicação num servidor HTTP, e a partir daí milhares de terminais ficam com a aplicação disponível através do web-browser.  Além de que, ao se eliminar o passo do deployment, também se obtém um time-to-market muito menor, diminuindo o gap desde o momento em que se fechou o desenvolvimento até ao momento de início da sua utilização em ambiente de produção.
Na manutenção consegue-se novamente obter uma redução drástica de custos, visto que basta dar manutenção a um único ponto: o servidor HTTP onde é disponibilizada a aplicação. Ao actualizar essa aplicação, actualiza todos os clientes “em simultâneo”.

Quanto à sua utilização, o facto de regra geral serem dotadas de melhores interfaces gráficos resulta numa maior produtividade por parte dos seus utilizadores que se sentem mais confortáveis com a aplicação. Outra ponto que interessa realçar é que as RIAs são muito mais eficientes que as típicas web-applications no que toca à troca de informação com o servidor, obtendo-se tempos de espera muito menores.

Imaginemos por exemplo uma aplicação de B2B de gestão de stocks e encomendas. Um distribuidor pretende que os retalhistas com quem trabalha possam usar uma aplicação do distribuidor para fazer reposição de stocks. Se essa aplicação for uma RIA o distribuidor terá somente que entregar ao retalhista o URL da aplicação, com as respectivas credenciais de acesso. O retalhista simplesmente terá que utilizar o seu web-browser para abrir a aplicação, fazer o login, e utilizá-la. Isto é algo que acontece actualmente com as aplicações web, mas no caso das RIAs o retalhista irá usar algo que é realmente uma aplicação, com um interface gráfico e interacção em tudo idênticos ao software desktop, e não um conjunto de páginas HTML que se assemelham a uma aplicação.

10- Como é feito o controlo de acesso e a segurança às redes RIA?

Os sistemas de controlo de acessos e a segurança são em tudo idênticas às actuais aplicações Web. Os paradigmas e preocupações são exactamente os mesmos, pelo que não há alteração nem no investimento nem no know-how necessário. Qualquer aplicação distribuída, seja ela desktop, web, ou ria, que troque dados num canal deverá garantir que esse canal é seguro através de algumas técnicas habituais – como o https.

11- Não há riscos acrescidos de pirataria informática e uma espécie de terrorismo financeiro (caso haja bases de dados financeiras disponíveis na rede)?

Não mais que o risco actualmente existente quando utiliza um sistema de home-banking, como o CaixaDirecta. Porém, é natural que com a proliferação das aplicações RIAs surjam empresas com lacunas a nível de desenvolvimento e segurança e seja complicado para o utilizador distinguir se deve confiar nessa empresa/aplicação ou não. Mas como sabe que pode confiar no seu sistema de home-banking?  Os riscos dependem sobretudo da seriedade e experiência da equipa de desenvolvimento, e do investimento que foi feito em segurança.

No caso de aplicações críticas, estas podem e devem ser colocadas a correr em ambientes controlados, em que a aplicação está acessível somente dentro da rede da empresa. O acesso externo poderá ser concedido em condições especiais, como por exemplo, VPN’s, ou a partes limitadas do sistema consoante as credenciais do utilizador.

12- Como irá funcionar a utilização destas aplicações?

Simples: abre o seu browser, que regra geral vem equipado com um plugin como o Adobe Flash Player ou Microsoft Silverlight e coloca o endereço da aplicação. Por vezes pode ser necessário fazer um login, mas a partir daí a utilização da aplicação será em tudo idêntica à utilização do seu software habitual. Existem algumas pequenas limitações nos plugins que raramente se notam, mas independentemente disso estou convicto que até ao final deste ano até essas limitações estarão completamente ultrapassadas. (Falava do Flash Player 10)

13- É sabido que algumas das aplicações são open-source e outras são pagas. Como são definidas as que terão custos e o que as tornam pagas?

Cabe a quem desenvolve tomar essa decisão. Tem exclusivamente a ver com o modelo de negócio escolhido, e com as vantagens e desvantagens dos modelos de licenciamento de software aberto ou fechado. Há casos em que o software open-source é completamente justificado. Por exemplo, a empresa decide disponibilizar gratuitamente o código fonte sendo as receitas geradas pelo suporte e formação. Ou ainda, porque desenvolveu um produto para optimizar o seu negócio (i.e. as receitas são resultantes do negócio e não da venda do software), e acha que se disponibilizar o código fonte do seu produto este irá melhorar com o tempo graças à participação de outras pessoas, resultando consequentemente numa mais valia para o seu negócio que se torna mais eficiente à medida que o software é melhorado.

Porém, está é uma questão que não é inerente às RIAs, mas a qualquer tipo de software.

14- O que se espera do mercado das aplicações desktop? Vai entrar em falência?

Não acredito. Simplesmente vai ter que se adaptar a uma nova realidade, em que o destaque está nos dados e não na aplicação, e aprender a co-existir com as Rich Internet Applications. Começa a surgir um novo conceito, o de Rich Desktop Application. Uma Rich Desktop Application (RDA) consiste numa aplicação que é instalada no nosso computador, mas que regra geral é composta essencialmente por um interface gráfico. Os dados e a camada de negócio encontram-se num servidor remoto. E porque queremos instalar uma RDA no nosso computador, se podemos usar uma RIA? Porque podemos não estar sempre ligados à Internet, e não queremos deixar de usar as nossas aplicações quando a ligação está indisponível -  neste caso, quando a ligação é reposta, os dados são sincronizados com o servidor. Ou simplesmente porque as RDAs não estão limitadas pelas restrições de segurança das sandboxes dos plugins sobre as quais assentam as RIAs, permitindo uma maior integração com o sistema operativo.

Como disse atrás, o destaque hoje em dia está nos dados e não na aplicação em si. O que o utilizador quer é ubiquidade: manipular os seus dados a partir de qualquer local, independentemente do sistema operativo, dispositivo, ou meio de acesso. O que é criado pelas equipas de desenvolvimento são diferentes terminais: Desktop, Web, RIA, ou mesmo aplicações móveis, mas todos eles acedem e manipulam os mesmos dados. Tecnologias de desenvolvimento de RIAs como o Adobe Flex permitem facilmente criar uma RIA, e depois reutilizar o código para criar uma RDA (neste caso, assente sobre Adobe Air).

15- Existem problemas de compatibilidade entre máquinas e sistemas informáticos (ex: PC e MAC)?

A compatibilidade de acesso a uma RIA é definida pelo suporte do plugin sobre o qual a RIA assente nos diferentes sistemas operativos.
O Flash Player, por exemplo, é actualmente suportado em Windows (XP, Vista, 2003, 2000, ME e 98), Linux, Macintosh e Solaris, com uma penetração na ordem dos 95% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html) . A versão Lite do Flash Player pode ainda correr em dispositivos móveis, mas implica a criação de source code específico para essa versão.
O Microsoft Silverlight é actualmente suportado em Windows (Vista,2003, XP) e Mac OS. Está a ser desenvolvido suporte para Linux, e para dispositivos móveis com Windows Mobile 6 e Symbian S60.
A Adobe possui ainda uma tecnologia denominada Adobe Air que permite transformar uma RIA numa RDA dando-lhe funcionalidades adicionais de integração com o sistema operativo. O Adobe Air é compatível de forma idêntica em todos os sistemas operativos, tal como o Flash Player.

Em resumo, uma das vantagens das RIAs é efectivamente o facto de que não está dependente do sistema operativo.

Deixo aqui os slides da nossa apresentação. São úteis para quem não sabe o que são RIAs, nem conhece Flex e Air.

O tempo da nossa apresentação era muito limitado (30 minutos), pelo que não houve espaço para questões. Estejam por isso à vontade de me contactar directamente para joao [dot] saleiro [at] webfuel [dot] pt , ou através da mailing list.

Sapo Unplugged 08 – Usabilidade

Dia: 21 de Maio

Local: Reitoria da Universidade de Aveiro

Mais informações: http://labs.sapo.pt/eventos/unplugged08/plugged.html

Agenda:

• [14h] Abertura da conferência (Fernando Ramos e Celso Martinho);
• Henning Fisher da Adaptive Path;
• Oscar Mealha da Universidade de Aveiro;
• Pedro Branco da Universidade do Minho;
• [16h] Coffee Break;
• Ivo Gomes;
• Bruno Figueiredo;
• Pedro Custódio da Sapo;
• [18h30] Encerramento (Celso Martinho e Pedro Custódio);

BarCampFCT

Dia: 24 de Maio

Local: Departamento de Matemática da FCT, UNL

Mais informações: http://fct.enses.org/barcamp/app/

Agenda:

A agenda é flexível, como é costume nos BarCamps, mas conta com apresentações como:

• Social Experience for Newbies;
• From applications to services, ending as infrastructure;
• Empreendedorismo nas Universidades;
• etc…

Encontro #2 do Adobe User Group

Dia: 31 de Maio

Local: Faculdade de Engenharia da Universidade do Porto

Mais informações: http://aug.riapt.org/

Agenda:

• Rich Internet Applications na plataforma Flash usando Flex e Air (João Saleiro e João Fernandes);
• Flash Platform na Alert: passado, presente e futuro;
• [Tema em aberto - proponha o seu tema na mailing list].

Evento de criativos em Lisboa (by Adobe)

Dia: 5 de Junho

Local: Centro Cultural de Belém

Mais informações aqui

Agenda:

• [9:30-10:00] Boas-vindas e Agenda: Os desafios do profissional criativo;
• [10:00-10:30] Novas Tecnologias Adobe – Flash, Flex, AIR. Novas formas de chegar aos seus Clientes;
• [10:30-11:30] Fluxo de trabalho num estúdio de design com o Adobe Creative Suite CS3 Design Premium;
• [11:30-12:00] Coffee Break
• [12:00-13:00] Mais possibilidades para a criação de páginas e aplicações interactivas com o Creative Suite CS3 Web Premium
• [13:00-14:00] Creatividade em vídeo de alta qualidade. Monte a sua própria TV na web com o Adobe Creative Suite CS3 Production Premium
• [14:00-14:15] – Encerramento do Evento