O site loja.flex.etc.br agora é danielschmitz.com.br. O sistema continua o mesmo, só que agora começaremos a lançar livros não somente relacionados a tecnologia Flex, mas também a outras áreas de TI. O primeiro deles é relacionado a Orientação a Objetos, e estamos na fase de desenvolvimento.

O blog flex.etc.br também mudou de layout e mudará de URL aos poucos. Em breve estaremos usando somente o endereço flex.danielschmitz.com.br e e alguns meses estaremos migrando para blog.danielschmitz.com.br, onde estarmos abordando diversos assuntos como flex, mobile, programação, TI, entre diversos outros.

Os emails de suporte e vendas também mudaram. Agora é vendas@danielschmitz.com.br e suporte@danielschmitz.com.br. Os emails antigos serão desativados gradativamente.

Hoje vou mostrar a integração de aplicações Flex 4 com back-end Java, utilizando o Blazeds para comunicação entre eles. Durante a instalação e configuração do ambiente de desenvolvimento, estamos considerando que você está trabalhando numa máquina com Windows. Caso não seja este o caso não fique preocupado, basta repetir os mesmos passos descritos para o Windows adaptando para o sistema operacional que você estiver utilizando.

1. Instalações

- Download Java Development Kit (JDK6), e após configurar a váriavel de sistema JAVA_HOME.
- Download Eclipse IDE for Java Developers.
- Download BlazeDS Turnkey, contêm uma versão configurada do servidor Tomcat e diversos exemplos.
- Download Adobe Flash Builder 4, versão Standalone.

2. Instalando o BlazeDS

Após o download do BlazeDS descompacte-o num diretório de sua preferência:
C:blazeds

* Nesse momento você já deve ter instalado o JDK e confgurado a variável JAVA_HOME.

Para verificar se tudo está funcionando vamos iniciar o servidor Tomcat.

Abra um prompt do Windows e digite:
cd C:blazedstomcatbin

Em seguida inicie o servidor Tomcat:
catalina start

Após a inicialização do servidor, você verá a janela abaixo:

O servidor de aplicação foi inicializado na porta 8400. Como eu disse anteriormente, o BlazeDS Turnkey vem com uma série de aplicações de exemplo mostrando a integração entre o Adobe Flex e o Java.

Para verificar se o servidor está rodando corretamente e ver as aplicações que citei, digite num browser de sua preferência:
http://localhost:8400/

3. Instalando o Eclipse

Após o download do Eclipse, descompacte o conteúdo do arquivo compactado para uma pasta um diretório de sua preferência:
C:eclipse

* Assim como o BlazeDS, o Eclipse também não necessita de instalação. Basta descompactá-lo para utilizar.

4. Instalando o Flash Builder 4

Para a instalação do Adobe Flash Builder 4 basta você ir avançando as opções, sempre mantendo os valores padrões. A versão Standalone é uma versão Trial que dura 60 dias. No site da Adobe você pode obter gratuitamente uma licensa de utilização caso você se enquadre nas exigências legais (estudantes, profissionais autônomos, etc).

5. Criando o projeto Java

Abra a pasta onde você descompactou o Ecplise e execute-o:
C:eclipseeclipse.exe

Em seguida vamos criar nosso projeto Java. Clique em:
File > New > Dynamic Web Project

Agora vamos criar um bean que será usado na serialização das informações que serão trocadas entre o Adobe Flex e o Java.

Clique com o botão direito do mouse no projeto e então:
New > Class

A seguir a implementa da nossa classa Java bean Usuario.java:

package br.com.rectius.model;
?
import java.io.Serializable;
?
public class Usuario implements Serializable {
?
	/**
	 *
	 */
	private static final long serialVersionUID = 1L;
?
	private String nome;
	private String email;
	private String cargo;
?
	public void setNome(String nome) {
		this.nome = nome;
	}
	public String getNome() {
		return nome;
	}
?
	public void setEmail(String email) {
		this.email = email;
	}
	public String getEmail() {
		return email;
	}
?
	public void setCargo(String cargo) {
		this.cargo = cargo;
	}
	public String getCargo() {
		return cargo;
	}
?
}

Agora vamos criar nossa camada de serviço, que será o ponto de entrada das requisições do nosso front-end Flex.

Clique novamente com o botão direito do mouse sobre o projeto e então:
New > Class

A seguir a implementação da nossa camada de serviço UsuarioService.java:

package br.com.rectius.service;
?
import java.util.ArrayList;
?
import br.com.rectius.model.Usuario;
?
public class UsuarioService {
?
	/*
	 * Como não estamos utilizando nenhuma ferramenta
	 * para persistência dos dados, vamos armazenar
	 * a informações nessa lista estática
	 */
	private static ArrayList<Usuario> listaUsuarios =
		new ArrayList<Usuario>();
?
	/*
	 * Insere um novo usuário
	 * @param usuario
	 */
	public void insereUsuario(Usuario usuario)
	{
		listaUsuarios.add(usuario);
	}
?
	/*
	 * Retorna todos os usuários
	 * @return
	 */
	public ArrayList<Usuario> listaUsuarios()
	{
		return listaUsuarios;
	}
?
}

Pronto! Nossa aplicação Java já está finalizada.

6. Configurando o BlazeDS

Para que o Adobe Flex possa se comunicar com nossa camada de serviço no Java, teremos que modificar alguns arquivos de configuração do BlazeDS.

Abra a pasta onde você descompactou o BlazeDS:
C:blazeds

Crie um nova pasta chamada:
C:blazedsBlazedsConfigBase

Localize agora o arquivo blazeds.war e descompacte-o na pasta que acabamos de criar:
Arquivo: C:blazedsblazeds.war
Pasta: C:blazedsBlazedsConfigBase

Veja o contéudo da pasta C:blazedsBlazedsConfigBase>:
C:blazedsBlazedsConfigBaseMETA-INF
C:blazedsBlazedsConfigBaseWEB-INF

* A pasta WEB-INF contém toda a informação necessária para a integração de um projeto Adobe Flex + Java + Blazeds.

Agora vamos copiar algumas pastas do BlazeDS para dentro nosso projeto Java. Localize a pasta:
C:blazedsBlazedsConfigBaseWEB-INF

Copie o arquivo e os diretórios abaixo para WebContentWEB-INF, dentro do Eclipse:
C:blazedsBlazedsConfigBaseWEB-INFweb.xml
C:blazedsBlazedsConfigBaseWEB-INFflex
C:blazedsBlazedsConfigBaseWEB-INFlib

A pasta lib contém todas as biliotecas necessárias para realizar a comunicação do Adobe Flex com o Java.
A pasta flex contém os arquivos de configuração necessários para estabelecer essa comunicação.

Nesse momento a estrutura do seu projeto deve estar como na imagem abaixo:

Agora vamos configurar nossa aplicação para que o Flex consiga se comunicar com o nosso projeto Java.

Dentro do Eclipse localize e abre o arquivo:
WebContentWEB-INFweb.xml

Configure-o conforme a seguir:

<?xml version="1.0" encoding="UTF-8"?>
DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
?
    <display-name>BlazeDSdisplay-name>
    <description>BlazeDS Applicationdescription>
?
    -- Http Flex Session attribute and binding listener support -->
    <listener>
        <listener-class>flex.messaging.HttpFlexSessionlistener-class>
    listener>
?
    -- MessageBroker Servlet -->
    <servlet>
        <servlet-name>MessageBrokerServletservlet-name>
        <display-name>MessageBrokerServletdisplay-name>
        <servlet-class>flex.messaging.MessageBrokerServletservlet-class>
        <init-param>
            <param-name>services.configuration.fileparam-name>
            <param-value>/WEB-INF/flex/services-config.xmlparam-value>
       init-param>
        <load-on-startup>1load-on-startup>
    servlet>
?
-- begin rds
end rds -->
    <servlet>
        <servlet-name>RDSDispatchServletservlet-name>
		<display-name>RDSDispatchServletdisplay-name>
        <servlet-class>flex.rds.server.servlet.FrontEndServletservlet-class>
		<init-param>
			<param-name>useAppserverSecurityparam-name>
			<param-value>falseparam-value>
		init-param>
        <load-on-startup>10load-on-startup>
    servlet>
?
    <servlet-mapping id="RDS_DISPATCH_MAPPING">
        <servlet-name>RDSDispatchServletservlet-name>
        <url-pattern>/CFIDE/main/ide.cfmurl-pattern>
    servlet-mapping>
?
    <servlet-mapping>
        <servlet-name>MessageBrokerServletservlet-name>
        <url-pattern>/messagebroker/*
    
?
    
        index.html
        index.htm
    
?
    
    
?

Ainda dentro do Eclipse localize e abra o arquivo:
WebContentWEB-INFflexremoting-config.xml

Dentro desse arquivo é que informamos quais os serviços que nosso front-end Flex poderá ter acesso. Para tal basta criar um novo destino para cada serviço.

Crie um destino para o serviço UsuarioService adicionando no arquivo remoting-config.xml o código abaixo:

    <destination id="UsuarioService">
    	<properties>
    		<source>br.com.rectius.service.UsuarioServicesource>
    	properties>
    destination>

Pronto! O projeto Java já está configurado para trabalhar com o BlazeDS.

7. Publicando nossa aplicação no Tomcat

Já terminamos o projeto Java e a configuração do BlazeDS. Agora o próximo passo é publicar o projeto no servidor de aplicações Tomcat.

Navegue até a pasta:
C:blazedstomcatwebapps

Crie uma pasta para o projeto Java:
C:blazedstomcatwebappsGerenciaUsuario

Agora dentro do Eclipse, clique sobre a pasta WEB-INF e a copie Edit > Copy.

Cole então seu conteúdo na pasta que criada no passo acima:
C:blazedstomcatwebappsGerenciaUsuario

Agora reinicie o servidor de aplicação Tomcat para subir o projeto que acabamos de fazer deploy:
catalina stop
catalina start

08. Criando o projeto Flex

Uma das novidades do novo ambiente de desenvolvimento Adobe Flex, o Flash Builder 4, é sem dúvidas os recursos de conexão a dados e serviços.
No passo 4 nós fizemos a instalação do Flash Builder 4. Agora localize seu ícone na área de trabalho ou no menu iniciar e abra o aplicativo.

Em seguida crie um novo projeto Flex. Clique em File > New > Flex Project

Agora faça suas configurações conforme a imagem abaixo:

Root folder: Representa o diretório onde fizemos o deploy do nosso projeto Java, dentro do servidor de aplicação.
Root URL: Representa a URL de acesso ao projeto no servidor de aplicação.
Context root: Representa o nome da nossa aplicação.
Output folder: Representa o local onde serão compilados os arquivos do Flex.

Clique em Validate Configuration para se certificar de que você configurou tudo corretamente e em seguida clique em Finish.

Antes de qualquer coisa vamos conferir se o Flash Builder inseriu corretamente um parâmetro de compilação no projeto Flex.

Clique com o botão direito do mouse no projeto Flex, clique em Properties e certifique-se de que o argumento de compilação -services foi inserido:

Agora vamos criar a interface. Digite o código abaixo:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx">
?
	<s:controlBarContent>
		<s:Label text="Gerenciamento de Usuários"
				 fontWeight="bold" fontSize="18"/>
	s:controlBarContent>
?
	<s:layout>
		<s:VerticalLayout
			horizontalAlign="center" verticalAlign="middle"
			paddingLeft="10" paddingRight="10" paddingBottom="20" paddingTop="20"/>
	s:layout>
?
	<s:Panel title="Cadastro de Usuários" width="500">
?
	s:Panel>
?
	<s:Panel width="500" height="100%" title="Listagem de Usuários">
		<mx:DataGrid id="dgUsuarios" left="20" right="20" bottom="20" top="20">
		mx:DataGrid>
	s:Panel>
?
s:Application>

09. Conectando a aplicação Adobe Flex ao Java

Em seguida vamos utilizar os novos recursos inseridos no Flash Builder 4 para se comunicar com o Java.

Clique em Windows > Data/Services. Após a aba correspondente se abrir clique em Connect to Data/Service….

Veja que alguns arquivos foram criados automaticamente:

Clique com o botão direito em qualquer ponto da sua Application (não clique nos componentes Panel ou qualquer outro que não seja a Application) e clique em Generate Service Call:

Em seguida selecione o método listaUsuarios():

Vá para o modo de visualização “Source” e veja que um método handler foi criado para manipular o evento CreationComplete da Application.

Agora volte para o modo “Design”, clique com o botão direito no componente DataGrid e em seguida clique em Bind to Data…

Clique no botão OK e veja o resultado:

Finalizamos o código para a listagem dos usuários. Agora precisamos fazer o código que vai inserir os usuários.

Novamente clique com o botão direito do mouse no componente DataGrid e então clique na opção Generate Details Form…

Arrume o posicionamento do formulário de cadastro, altere o label do botão. Em seguida clique com botão direito do mouse sobre o botão e Generate Service Call…

Agora altere o método button_clickHandler que foi gerado automaticamente:

protected function button_clickHandler(event:MouseEvent):void
{
	var usuario:Usuario = new Usuario();
	usuario.email = emailTextInput.text;
	usuario.nome = nomeTextInput.text;
	usuario.cargo = cargoTextInput.text;
	insereUsuarioResult.token = usuarioService.insereUsuario(usuario);
}

Com isso já conseguimos inserir usuários na coleção do back-end Java. Agora vamos modificar nosso código para que toda vez que um usuário for inserido os usuários sejam listados novamente no componente DataGrid.

Agora altere o método insereUsuarioResult_resultHandler:

protected function insereUsuarioResult_resultHandler(event:ResultEvent):void
{
	listaUsuariosResult.token = usuarioService.listaUsuarios();
}

Agora rode sua aplicação e veja o resultado final.

Pronto! A aplicação está rodando perfeitamente.
Como lição de casa, faça com que seja possível remover e alterar um usuário.

Fontes do projeto:

Download do projeto Flex (28 KB)
Download do projeto Java (3.67 MB)

Referências:
- Accessing data services overview

Espero que tenham gostado e até a próxima!

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.

É com muita alegria que faremos (falo pela RIA Labs) mais um curso com a E-genial: Imersão Front-End. Creio que seja o quinto ou sexto curso on line deles do qual participaremos. Quero ver se, depois de tanto tempo do primeiro curso feito, eles conseguiram manter aquela qualidade toda! =D

Clique para mais informações: http://www.egenial.com.br/imersaofrontend

Não é segredo algum que eu sou fã do produtos da Apple. A grande maioria das vezes que uso algo deles a única coisa que penso é como uma empresa tão grande consegue propagar um nível de qualidade tão alto para todos os seus produtos (software e hardware) e tento aprender um pouco com isto.

Fase inicial: susto!

Porém, no lançamento do iPhone OS 4.0 (que achei fantástico) uma coisa me assustou muito. A cláusula 3.3.1 do TOS do SDK da Apple, que resumindo é: Só vamos aceitar apps em Obj-c e derivados de C++, além de apps em Javascript que usam o Webkit.

A minha primeira reação foi: “que p&@#ra é essa?” . Eles vão acabar com as plataformas PhoneGap, Rhodes, MonoTouch e outras? Não faz sentido.

Honestamente eu duvido que eles vão negar apps em Titanium e PhoneGap pois a própria cláusula defende estas tecnologias. São tecnologias que basicamente empacotam uma web app feita em HTML5+CSS3+JS no componente WebView (que utiliza o >Webkit<) de forma que possa ser compilada e vendida na App Store. Você também ganha acesso a várias api’s como GPS, câmera e etc.

As outras plataformas como o Flash CS5 com certeza estão fora e não serão mais aceitas na App Store.

Fase 2: pensamento.

Todos que acompanham o meu trabalho sabem que gosto muito dos produtos da Adobe, principalmente a plataforma Flash. Apesar de achar que ela possui diversas falhas de arquitetura (não vou detalhar isto agora) e não é de longe um produto genial como por exemplo Ruby, Smalltalk ou até Obj-c. No entanto, é fato que o Flash é muito bom para criar experiências ricas na internet.

Para web não levanto a bandeira de nada para frontend pois na minha opinião as coisas estão engatinhando. Mas para desktop a coisa é um pouco diferente.

Nos últimos 8 meses tenho dedicado boa parte do meu tempo em pesquisar plataformas para desenvolvimento desktop. Acho que testei praticamente tudo, desde Titanium e QT até Adobe AIR. E a minha opinião final é que nenhuma destas tecnologias é algo como o Rails.

Quando digo como Rails me refiro a uma plataforma onde uma equipe de 2 pessoas consiga desenvolver algo extremamente bem
feito, fácil de manter, estável, com uma experiência fantástica e em curto prazo. Todos falham em algum ponto crítico e todas
são multi-plataforma.

Fase 3: experiência de usuário e exigência.

Dependendo do grau de exigência que você tem para seus projetos, simplesmente não existe multi-plataforma. Eu poderia listar
várias coisas que não gosto em Adobe AIR ou Titanium por exemplo. Mas o mais claro é que produtos multi-plataforma para desktop destroem a experiência do usuário e entregam algo que a pessoa não espera.

Ou você acha legal uma app em Java ter a interface totalmente diferente das nativas do Mac ou do Windows? Outro exemplo é o
Kindle For Mac, sem palavras, um lixo. Ao tentar ler um livro nesta coisa a última idéia que me vem a cabeça é que eu estou
usando uma aplicação Mac. Todos os atalhos são diferentes, os ícones são diferentes, as posições das coisas são diferentes.

Eu, como usuário, não dou a mínima se é caro manter 3 versões diferentes da aplicação. Apenas espero que ela funcione como eu espero ou é melhor que ela nem exista.

Você acha que sua mãe e seu irmão querem ter que re-aprender onde ficam as coisas cada vez que abrem uma aplicação nova? Não!

E eu passei por este problema ao tentar encontrar algo para desenvolver para dispositivos móveis. Algo que fosse portável para iPhone e Android. O resultado foi que tudo que eu tentei usar criava um Frankstein e um das lados, ou seja, a app ficava com cara de iPhone e não tinha nada de Android e vice-versa.

Eu não gastaria meses em um produto onde eu não consiga entregar uma experiência excelente então a minha opção foi abandonar
o conceito multi-plataforma e focar em iPhone. Nada de Phonegap também pois você perde muito tempo tentando emular o comportamento de apps nativas e ainda fica com algo a desejar.

E quando anunciaram o Flash CS5 com suporte para apps iPhone o que logo me ocorreu (e que depois comprovei ser verdade) é que
era apenas mais uma ferramenta que vai entregar aplicações com problemas como citei acima (Frankstein’s).

Fase 4: não sei mais se a Apple está errada.

Depois de pesquisar tanto entrei de cabeça no desenvolvimento Mac em Obj-c e MacRuby. MacRuby para quem não conhece é a própria implementação da Apple da linguagem Ruby e que é totalmente compatível com Cocoa e os demais frameworks para o Mac.

A única palavra sobre os meus estudos da plataforma Mac são: um produto genial! O Interface Builder por exemplo é sem dúvida
a melhor ferramenta que conheço para criar interfaces gráficas sem gerar código bagunçado (ex.: Dreamweaver, Delphi For PHP e etc).

O XCode é bem legal e eu pessoalmente odeio IDE’s. A documentação da Apple é simplesmente excelente, com centenas de vídeos, manual bem escrito de todas as classes, forums internos, suporte e etc. E todas as ferramentas são gratuitas (já paguei pelo Mac mas o ponto aqui é outro, no Windows você pagou pelo S.O. e ainda paga pela licença da ferramenta de desenvolvimento).

Porém, mais fantástico é a linguagem e seus frameworks. O Obj-c a primeira vista assusta pois a sintaxe é bem diferente de Java, C++ ou JS (bem mais parecido com Smalltak). No Entanto logo que se acostuma percebe como é uma linguagem sólida e poderosa que bate de frente com tecnologias de alto nível como Ruby e Smalltak. Além de ser uma tecnologia que evolui a mais de 20 anos.

Ao aprender Obj-c fica óbvio o porque da qualidade do OSX. A linguagem é simplesmente fantástica, com estruturas poderosas como Key Value Coding e Metaprogramação, tudo isso sem perder performance, permitindo a criação de animações complexas com Core Animation em conjunto com ferramentas como Quartz.

E o melhor de tudo isso é que todos os recursos são condizentes. Chega a ser difícil criar uma aplicação Cocoa (framework padrão para desenvolvimento Mac e iPhone) que saia dos padrões do que estamos acostumados da experiência de usuário no Mac.

Fase 5: minha exigência começa onde termina minha preguiça.

Conversando com um amigo que defende o Flash CS5 compilar apps iPhone ele disse que tempo é dinheiro e que se já sabemos
Flash e AS3 então é bobeira ter que aprender Obj-c/Cocoa. Descordo totalmente, se algo vai ser um Frankstein e você vai ter que passar muito tempo simulando a experiência padrão em um aparelho e criando um monstro em outro então eu prefiro aprender a plataforma correta.

Se plataforma correta for sólida, fácil de manter e acessível a equipes de 3 pessoas então a minha opção como desenvolvedor e empreendedor é sem dúvida esta plataforma. E a plataforma da Apple é assim (ainda acho que falta mais foco em TDD mas isso é porque sou um cara de Ruby).

Acredito ser melhor gastar 3 ou 4 semanas de estudo intensivo para ter uma visão correta de uma plataforma nativa para criar algo realmente bom do que ser preguiçoso inicialmente e gastar meses tentando simular a experiência desejável em uma fábrica de Frankstein’s.

A única exceção ao 3.3.1

Jogos deveriam ser a única exceção. Na minha opinião a Apple deveria colocar mais um parágrafo dizendo que jogos não se aplicam ao 3.3.1.

Todos sabem a complexidade técnica para criar um jogo (eu venho da plataforma Flash antes dessas história de RIA virar moda). Até em Flash, que á pouco tempo não envolvia complexidades como 3D, é muito difícil criar uma engine de física por exemplo.

Agora imagine criar uma engine de verdade como Unreal. Imaginem o custo para isto, vai muito além da maioria dos projetos de software. Uma empresa que investe em algo assim não pode focar em apenas uma plataforma.

E para experiência do usuário eles estão mais que corretos em serem multi-plataforma. Um jogo não deve seguir nenhum padrão como um aplicação de produtividade deve. Cada interface para um game deve ser diferente, os atalhos não devem ser iguais, as janelas são diferentes e etc.

Por isso não faz nenhum sentido aplicar o 3.3.1 em jogos.

A exigência em excelência da Apple

Para quem só usa os produtos da Apple e nunca precisou estudar suas tecnologias a fundo não tem a idéia que a empresa propaga a qualidade extrema em todas ferramentas. Não é apenas criar um produto final bonitinho. Tudo é perfeito, desde a documentação ao criador de interfaces até chegar ao produto final como Mac e iPhone.

A forma como a empresa tem encarado o seu dispositivo móvel (plataforma com limitações de recursos como memória e processamento) tem sido bem interessante. Lançando todas as “features” aos poucos, enquanto a mídia e os “boateiros” bombardeiam o produto dizendo que ele falta isso e aquilo.

No entanto, quando lançam a funcionalidade que “faltava” ela vem de uma forma muito bem feia. Vejam o copiar e colar do iPhone, as pastas e o tão falado “multi-tasking”. Um sinal de preocupação em fazer tudo sempre da forma mais bem feita possível e uma preocupação muito além do que estamos acostumados.

Então, do ponto de vista da empresa, não acredito que banir os Frankstein’s seja apenas uma tentativa de criar um monopólio e vencer a concorrência no braço.

Conclusão

Não tenho certeza se o que a Apple fez é correto do ponto de vista comercial ou de marketing. Mas para o usuário como o meu pai ou minha mãe acredito que seja positivo. Eu me belisco antes de dizer isto (principalmente porque defendo tecnologias opensource como Ruby e Rail), mas também acredito ser positivo para nós como desenvolvedores de apps de produtividade, principalmente se estivermos preocupados em entregar uma experiência fantástica mas coerente.

Se existe um caminho melhor do que definir uma regra dessas eu não sei. Mas não estou nada preocupado pela Apple restringir o restante pois como pretendo desenvolver algo de qualidade para Mac/iPhone já estou focado em Obj-c/Cocoa já tem um bom tempo.

Outros posts interessantes:

• Why Apple Changed Section 3.3.1
• Steve Jobs’ response on Section 3.3.1

Olá pessoal

A grande sensação ontem (23/03) foi a publicação pelo guru Christophe Coenraets demonstrando um vídeo aonde através do Flash Builder ele consumiu recursos de um projeto Java sem codificação no ambiente Flex. Nesse artigo vou demonstrar como trabalhar com esse recurso passo-a-passo.

Bom, primeiro passo é você ter em seu computador todas as ferramentas necessárias. Neste caso, você irá utilizar o Eclipse Galileu JEE, Flash Builder (stand-alone ou plugin) e do BlazeDS 4 Beta.

A aplicação que desenvolveremos nesse tutorial é a mesma desenvolvida no post anterior, com a diferença que aonde foi feito codificação manual no ambiente Flex, agora, iremos utilizar o Flash Builder para a geração do código fonte.

Bom, no Eclipse Galileo para iniciar um projeto, eu escolhi a opção File -> New -> Web -> Dynamic Web Project, conforme abaixo:

E depois configurei o projeto da seguinte maneira:

Bom, depois de configurar o projeto, iremos criar um Bean para serializarmos algumas informações que serão enviadas para o Flex. A idéia é bastante simples, irei criar um model para uma simples agenda de contato.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package br.com.horochovec.model;
 
import java.io.Serializable;
 
/**
 * Modelo para agenda de contato
 * @author Stefan Horochovec
 */
public class Contato implements Serializable {
 
	/**
	 *
	 */
	private static final long serialVersionUID = 1L;
 
	private String nome;
 
	private String email;
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
}

E em seguida, criarei um serviço que irá adicionar em um ArrayList os contatos que serão enviados do Flex para o Java.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package br.com.horochovec.service;
 
import java.util.ArrayList;
 
import br.com.horochovec.model.Contato;
 
/**
 * Serviço para manutenção dos contatos
 * @author Stefan Horochovec
 */
public class ContatoService {
 
	private static ArrayList listContato = new ArrayList();
 
	/**
	 * Adiciona um contato a lista
	 * @param contato
	 */
	public void addContato(Contato contato) {
		listContato.add(contato);
	}
 
	/**
	 * Retorna a lista de contatos
	 * @return
	 */
	public ArrayList getListContato() {
		return listContato;
	}
 
}

Após isso, já temos uma simples aplicação pronta para trabalhar com o Flex, basta apenas configurar os arquivos .XML para que o BlazeDS possa funcionar.

A partir de agora é necessário que você já tenha descompactado o arquivo blazeds-bin-4.0.0.14910.zip. Após descompactá-lo, você terá que descompactar o arquivo blazeds.war que surgiu da descompactação anterior. Como resultado, obterá o seguinte:

Bom, podemos copiar para o diretório WebContent/WEB-INF de nosso projeto Java, os diretórios: flex/, lib/, spring/ e os arquivos: flex-servlet.xml e web.xml. Após copiar esse conteúdo, o primeiro arquivo que iremos configurar, é o arquivo web.xml que fica dentro da pasta WebContent/WEB-INF/.

Para essa configuração, iremos alterar o conteúdo do arquivo web.xml que veio dentro do arquivo blazeds.war que foi previamente descompactado.

Perceba que os parametros da aplicação foram alterados e também foi alterado o valor da propriedade useAppserverSecurity para false. O resultado será:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 
    <display-name>FlexDuck</display-name>
    <description>FlexDuck</description>
 
    <!-- Http Flex Session attribute and binding listener support -->
    <listener>
        <listener-class>flex.messaging.HttpFlexSession</listener-class>
    </listener>
 
    <!-- MessageBroker Servlet -->
    <servlet>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <display-name>MessageBrokerServlet</display-name>
        <servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
        <init-param>
            <param-name>services.configuration.file</param-name>
            <param-value>/WEB-INF/flex/services-config.xml</param-value>
       </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
 
    <servlet>
        <servlet-name>RDSDispatchServlet</servlet-name>
		<display-name>RDSDispatchServlet</display-name>
        <servlet-class>flex.rds.server.servlet.FrontEndServlet</servlet-class>
		<init-param>
			<param-name>useAppserverSecurity</param-name>
			<param-value>false</param-value>
		</init-param>
        <load-on-startup>10</load-on-startup>
    </servlet>
 
    <servlet-mapping id="RDS_DISPATCH_MAPPING">
        <servlet-name>RDSDispatchServlet</servlet-name>
        <url-pattern>/CFIDE/main/ide.cfm</url-pattern>
    </servlet-mapping>
 
    <servlet-mapping>
        <servlet-name>MessageBrokerServlet</servlet-name>
        <url-pattern>/messagebroker/*</url-pattern>
    </servlet-mapping>
 
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
    </welcome-file-list>
 
    <!-- for WebSphere deployment, please uncomment -->
    <!--
    <resource-ref>
        <description>Flex Messaging WorkManager</description>
        <res-ref-name>wm/MessagingWorkManager</res-ref-name>
        <res-type>com.ibm.websphere.asynchbeans.WorkManager</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
    -->
 
<!--
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>
			/WEB-INF/spring/*-config.xml
		</param-value>
	</context-param>
 
    <filter>
        <filter-name>springSecurityFilterChain</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
 
    <filter-mapping>
      <filter-name>springSecurityFilterChain</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
 
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<servlet>
		<servlet-name>flex</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
 
	<servlet-mapping>
    	<servlet-name>flex</servlet-name>
    	<url-pattern>/messagebroker/*</url-pattern>
 	</servlet-mapping>
 
-->
 
</web-app>

Feito isso, iremos adicionar dentro da pasta WebContent a pasta flex que foi previamente descompactada do arquivo blazeds.war, e também todo o conteúdo da pasta lib para dentro do diretório WebContent/WEB-INF/lib , obtendo o seguinte resultado:

Feito isso, iremos configurar o único arquivo .xml do BlazeDS para que esse exemplo funcione. O arquivo WEB-INF/flex/remoting-config.xml. Iremos adicionar uma configuração para informar ao BlazeDS sobre o serviço ContatoService que foi criado anteriormente, conforme abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?xml version="1.0" encoding="UTF-8"?>
<service id="remoting-service" 
    class="flex.messaging.services.RemotingService">
 
    <adapters>
        <adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true"/>
    </adapters>
 
    <default-channels>
        <channel ref="my-amf"/>
    </default-channels>
 
    <destination id="ContatoService">
    	<properties>
    		<source>br.com.horochovec.service.ContatoService</source>
    	</properties>
    </destination>
 
</service>

Após essa última configuração, podemos exportar o nosso projeto para um servidor web. Nesse caso, utilizaremos o Tomcat 6.x. Neste artigo não entrarei em detalhes de sua instalação e configuração.

Bom, as configurações no projeto Java já foram finalizadas, e considerando que o deploy da aplicação dentro do Tomcat já foi realizado, a partir deste momento iremos trabalhar diretamente com o Flash Builder.

Neste artigo irei demonstrar a comunicação utilizando o Flash Builder e a versão do Flex 4. Você pode fazer o download da versão 4.0 do Flash Builder e do Flex 4 SDK aqui.

Após instalado e iniciado o Flash Builder, iremos criar um projeto no seguinte molde:

As configurações feitas na segunda tela de configuração são bastante importantes. Fazendo elas da forma correta, você estará apto a iniciar o projeto sem fazer novas configurações.

Na primeira linha, em Root Folder, foi apontado o diretório de deploy da minha aplicação dentro do meu servidor de aplicação.

Na segunda linha, em Root URL, foi apontado o caminho da URL para abertura da aplicação em meu navegador de internet.

Na terceira linha, em ContextRoot, apontamos o nome da nossa aplicação.

Na quarta e ultima linha, em Output folder, apontamos o diretório de onde deve ser exportados os arquivos quando compilados. Para esse tutorial, foi apontado diretamente o diretório de minha aplicação dentro do meu servidor Tomcat.

Como resultado, o Flash Builder irá criar e disponibilizar no workspace um projeto da seguinte forma:

É muito importante fazer a conferência de uma configuração gerada automaticamente pelo Flash Builder em cima dos parametros informados na segunda etapa da criação do projeto. No menu ‘Project’ vá na opção ‘Properties’ e confira as propriedades de acordo com a imagem abaixo:

Iremos criar uma tela no Flash Builder que contenha dois campos text input para preencher as informações do nome e email do contato, e também um grid para conter a lista dos contatos que serão adicionados no Java e retornarão ao Flex através do BlazeDS.

Segue sua implementação

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx" height="419">
 
 
	<fx:Declarations>
 
	</fx:Declarations>
 
 
	<s:Panel width="400" height="137" title="Cadastro" left="10" top="10">
 
	</s:Panel>
 
	<s:Panel x="12" y="166" width="400" height="227" title="Pesquisa" left="10">
		<mx:DataGrid x="10" y="10" bottom="30" left="5" right="5" top="5" id="grid">
		</mx:DataGrid>
		<s:Button x="-1" y="163" label="Listar todos" left="5" bottom="5" id="button"/>
	</s:Panel>
</s:Application>

A partir deste momento, usaremos os recursos de Data/Services presentes no Flash Builder 4 para a geração da comunicação com o Java.

Primeiro, iremos conectar o Flash Builder com o BlazeDS. Para isso, na aba “Data/Services” clique na opção “Connect to Data/Service”. Caso ela não esteja disponivel em seu workspace, vá ao menu “Window” e marque a opção “Data/Services”.

Feito isso, na próxima tela, marque a opção “BlazeDS”, clique em Next e marque a opção para não utilizar controle de acesso. Conforme as telas abaixo:

Na última tela, você deve marcar os serviços que deseja adicionar a aplicação, com opção de definição de endereços de pacotes e depois finalizar a criação do Objeto, conforme:

Após finalizar a configuração do serviço remoto, obtemos o seguinte resultado no Flash Builder.

Agora, iremos definir que no momento do click no botão logo abaixo do DataGrid, a aplicação deverá invocar o método getListContato().

O primeiro passo para isso, é clicar com o botão direito sobre o botão com do painel que contem o DataGrid e marcar a opção “Generate Service Call“. Feito isso configure a tela do serviço conforme apresentado abaixo:

Feito isso, selecione o DataGrid e clicando com o botão direito dentro dele, selecione a opção “Bind to Data” e configure a tela conforme informado abaixo:

Nesse momento, o painel responsável por listar as informações da nossa agenda de contato já está finalizado.

Agora, clicando novamente com o botão direito em cima do DataGrid, clique na opção “Generate Details Form” e configure a tela conforme abaixo:

O formulário gerado será adicionado no mesmo container que estiver o DataGrid, portanto, será necessário reposicioná-lo dentro do Panel já criado, conforme imagem abaixo:

Ok, agora basta configurarmos o clique do botão de salvar para que adicione novos contatos.

O primeiro passo é alterar o label do botão para “Cadastrar“.

O segundo passo é clicar com o botão direito sobre o botão de cadastro e selecionar a opção “Generate Service Call” e configure a opção da seguinte forma:

Ao terminar essa configuração, você será direcionado diretamente para a implementação do click do botão com a chamada do serviço remoto. A implementação gerada do método será a seguinte:

1
2
3
4
5
6

protected function button2_clickHandler(event:MouseEvent):void
{
	contato.email = emailTextInput.text;
	contato.nome = nomeTextInput.text;
	addContatoResult.token = contatoService.addContato(/*Enter value(s) for */ arg0);
}

E você deverá fazer a seguinte alteração. Adicionar o parametro a ser enviado no método addContato() e inicializar o objeto contato, da seguinte forma:

1
2
3
4
5
6
7

protected function button2_clickHandler(event:MouseEvent):void
{
	contato = new Contato();
	contato.email = emailTextInput.text;
	contato.nome = nomeTextInput.text;
	addContatoResult.token = contatoService.addContato(contato);
}

Com isso, nosso projeto estará enviado as informações para o Java. Agora, para finalizar, iremos adicionar um evento para disparar um método quando tivermos o resultado do serviço remoto.

No CallResponder com o id “addContatoResult” pressione o CTRL + SPACE para acionar o code complete e acione o event “result“, e em seguida, solicite para que seja adicionado o ResultHandler para o event adicionado, conforme imagens abaixo:

E na função adicionada no código devemos fazer a seguinte implementação:

1
2
3
4
5

protected function addContatoResult_resultHandler(event:ResultEvent):void
{
	contato = new Contato();
	getListContatoResult.token = contatoService.getListContato();
}

Rodando a aplicação, teremos como resultado no navegador o seguinte:

E como resultado final no código fonte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx" height="419" xmlns:services="services.*" xmlns:valueObjects="valueObjects.*">
	<fx:Script>
		<![CDATA[
			import mx.controls.Alert;
			import mx.rpc.events.ResultEvent;
 
			protected function button_clickHandler(event:MouseEvent):void
			{
				getListContatoResult.token = contatoService.getListContato();
			}
 
 
			protected function button2_clickHandler(event:MouseEvent):void
			{
				var contato : Contato = new Contato();
				contato.email = emailTextInput.text;
				contato.nome = nomeTextInput.text;
				addContatoResult.token = contatoService.addContato(contato);
			}
 
 
			protected function addContatoResult_resultHandler(event:ResultEvent):void
			{
				contato = new Contato();
				getListContatoResult.token = contatoService.getListContato();
			}
 
		]]>
	</fx:Script>
 
 
	<fx:Declarations>
		<s:CallResponder id="getListContatoResult"/>
		<services:ContatoService id="contatoService" fault="Alert.show(event.fault.faultString + 'n' + event.fault.faultDetail)" showBusyCursor="true"/>
		<valueObjects:Contato id="contato"/>
		<s:CallResponder id="addContatoResult" result="addContatoResult_resultHandler(event)"/>
	</fx:Declarations>
 
	<fx:Binding source="grid.selectedItem as Contato" destination="contato"/>
 
	<s:Panel width="400" height="137" title="Cadastro" left="10" top="10">
		<mx:Form defaultButton="{button2}" x="1" y="-4" bottom="0" left="0" right="0" top="0">
			<mx:FormItem label="Email">
				<s:TextInput id="emailTextInput" text="{contato.email}"/>
			</mx:FormItem>
			<mx:FormItem label="Nome">
				<s:TextInput id="nomeTextInput" text="{contato.nome}"/>
			</mx:FormItem>
			<s:Button id="button2" label="Cadastrar" click="button2_clickHandler(event)"/>
		</mx:Form>
 
	</s:Panel>
 
	<s:Panel x="12" y="166" width="400" height="227" title="Pesquisa" left="10">
		<mx:DataGrid x="10" y="10" bottom="30" left="5" right="5" top="5" id="grid" dataProvider="{getListContatoResult.lastResult}">
			<mx:columns>
				<mx:DataGridColumn headerText="email" dataField="email"/>
				<mx:DataGridColumn headerText="nome" dataField="nome"/>
			</mx:columns>
		</mx:DataGrid>
		<s:Button x="-1" y="163" label="Listar todos" left="5" bottom="5" id="button" click="button_clickHandler(event)"/>
	</s:Panel>
</s:Application>

Para fazer o download do projeto clique aqui.

Espero ter ajudado, um abraço

No mês passado eu fiz uma apresentação no nosso grupo local de Ruby, o RailsMG, falando sobre otimização de frontend. As dicas da apresentação servem para qualquer linguagem, mas eu mostro como solucionar cada problema usando o Rails.

Como tive alguns problemas na gravação e para editar o que foi filmado no dia acabou não ficando muito legal eu resolvi regrar em formato de screencast. O vídeo tem por volta de 50 minutos e mostra os conceitas da otimização e como aplicar na prática em um projeto Rails.

No mês passado eu fiz uma apresentação no nosso grupo local de Ruby, o RailsMG, falando sobre otimização de frontend. As dicas da apresentação servem para qualquer linguagem, mas eu mostro como solucionar cada problema usando o Rails.

Como tive alguns problemas na gravação e para editar o que foi filmado no dia acabou não ficando muito legal eu resolvi regrar em formato de screencast. O vídeo tem por volta de 50 minutos e mostra os conceitas da otimização e como aplicar na prática em um projeto Rails.

A apresentação é bem parecida com a que apresentei no RailsForKids de 2009 mas com atualizações e novos slides (que você pode baixar separadamente aqui).

O código fonte dos exemplos está disponível no meu GitHub em github.com/danielvlopes/optimizing_rails_frontends e conta com uma versão usando o asset_packager e outra usando o jammit.

Lumine + ZendAmf + Flex 3/5

Olá pessoal !!!

Vamos dar continuidade aos posts anteriores que trataram do Backend da nossa aplicação.
Nesse post vamos codificar o frontend da nossa aplicação, para isso vamos utilizar a dubla que se tornou titular em meus projetos : Flex + Swiz framework.

Flex Project

A estrutura do nosso Flex Project fica da seguinte forma :

Estrutura do projeto flex

Flex Compiler

Como estamos usando Swiz e as configurações de remote através do services.xml precisamos adicionar alguns argumento ao Flex Compiler, nesse caso ficou assim : -locale en_US -services=..services.xml -keep-as3-metadata+=Autowire.

RemotingService

Agora podemos configurar nosso RemotingService com o arquivo services.xml
Lembrando que o endpoint uri deve ser alterado para apontar para o seu projeto php
services.xml

<?xml version="1.0" encoding="UTF-8"?>
<services-config>
    <services>
        <service id="zend-service"
            class="flex.messaging.services.RemotingService"
            messageTypes="flex.messaging.messages.RemotingMessage">
            <destination id="zend">
                <channels>
                    <channel ref="zend-endpoint"/>
                </channels>
                <properties>
                    <source>*</source>
                </properties>
            </destination>
        </service>
    </services>
    <channels>
        <channel-definition id="zend-endpoint"
            class="mx.messaging.channels.AMFChannel">
            <endpoint uri="http://localhost/lumine-zend-flex/php/gateway.php"
                class="flex.messaging.endpoints.AMFEndpoint"/>
        </channel-definition>
    </channels>
</services-config>

Swiz

Então podemos configurar o Swiz para isso temos 2 arquivos :
ApplicationSwizConfig.mxml : Responsável pelas configurações básicas do Swiz
ApplicationBeans.mxml : Responsável pelo mapeamento dos nossos beans

ApplicationSwizConfig.mxml

<?xml version="1.0" encoding="utf-8"?>
<swizframework:SwizConfig
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	xmlns:swizframework="org.swizframework.*"
	eventPackages="{['br.com.flexria.events']}"
	viewPackages="{['br.com.flexria.view']}"
	logEventLevel="{LogEventLevel.DEBUG}"
	beanLoaders="{[ApplicationBeans]}"
	injectionEvent="preinitialize"
	mediateBubbledEvents="true"
	strict="true">
 
	<mx:Script>
		<![CDATA[
			import mx.logging.LogEventLevel;
		]]>
	</mx:Script>
 
	<mx:TraceTarget id="logTarget"
		includeCategory="true"
	    includeLevel="true" 
	    includeDate="true" 
	    includeTime="true"/>
 
</swizframework:SwizConfig>

ApplicationBeans.mxml

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*"
		xmlns:mx="http://www.adobe.com/2006/mxml"
		xmlns:factory="org.swizframework.factory.*"
		xmlns:delegates="br.com.flexria.delegates.*"
		xmlns:controllers="br.com.flexria.controllers.*">
 
   <!--DELEGATES-->
   <delegates:ContactDelegate 	id="contactDelegate"/>
   <delegates:PhoneDelegate 	id="phoneDelegate"/>
 
   <!--CONTROLLERS-->
   <controllers:ContactController   id="contactController"/>
   <controllers:PhoneController   id="phoneController"/>
 
   <!--REMOTES-->
   <mx:RemoteObject destination="zend"   id="contactRemote" source="ContactService" />
   <mx:RemoteObject destination="zend"   id="phoneRemote"   source="PhoneService" />
 
</BeanLoader>

Agora que temos nosso projeto flex configurado e podemos começar a codificar p valer : Tutorial : Lumine + ZendAmf + Flex 4/5

Até já !!!

Tutorial : Lumine + ZendAmf + Flex 1/5
Tutorial : Lumine + ZendAmf + Flex 2/5
Tutorial : Lumine + ZendAmf + Flex 3/5
Tutorial : Lumine + ZendAmf + Flex 4/5
Tutorial : Lumine + ZendAmf + Flex 5/5

Venho convidar todos para o próximo encontro que será no dia 26/01 as 19:00h no mesmo local (veja o mapa) .

Em todos os encontros teremos uma apresentação sobre temas relacionados ao Ruby e desta vez a responsabilidade é minha. Vou re-apresentar o que mostrei no RailsForKids mas com atualizações.

Olá pessoal, já não é novidade que estamos organizando encontros mensais sobre Ruby aqui em BH. É uma iniciativa para centralizar e aumentar a comunidade em Belo Horizonte e região. Venho convidar todos para o próximo encontro que será no dia 26/01 as 19:00h no mesmo local (veja o mapa) .

Apresentação

Em cada encontro teremos uma apresentação sobre temas relacionados ao Ruby e desta vez a responsabilidade é minha. Vou re-apresentar o que mostrei no RailsForKids com atualizações.

Vamos tirar um pouco o foco e relevância exagerada que é dada a performance do backend e mostrar que em 90% das aplicações os ajustes de performance devem ser feitos primeiro no front-end. Entender como pequenas alterações podem ajudar qualquer website a ser extremamente mais veloz. Também aprenderemos os recursos do Rails que ajudam estes mecanismos a funcionarem, detalhes de configuração que as vezes são ignorados no framework. Além de falar de projetos
como RackCache, AssetPackager, Jammit e Sprockets além de entender na prática GZip, eTags, expiração adiada, CDN e etc.

O que será mostrado basea-se nos conceitos levantados por Steve Sourders em seus livros High Performance Websites
e Even Faster Websites.

Sorteio

Neste encontro também teremos sorteios de prêmios entre os presentes. O que será sorteado é cortesia dos apoiadores Github , eGenial e 37Signals. Gostaríamos de agradece-los a prontidão em nos ajudar.