Jan 4

Mac OS X do Snow para o Lion… lentidão

Escrito por Erko Bridee em .NET, 1, 2.0, 4, 6, action, Adobe, Adobe Flex, Air, api, aplicacao, Aplicativos, app, apple, AR, back, blog, Blogs, C#, cache, chrome, class, Desenvolvimento, Dica, Dicas, Eclipse, err, exemplo, firefox, Flex, for, git, Google, Hibernate, html, ide, IE, if, image, JPA, library, Mac, menu, mg, O, on, Oracle, Outros, padrão, Partilha, problema, RIA, Ria’s Geral, S+S, servidor, Software, Tech, UI, web @ 01 4th, 2012 | via http://blog.erkobridee.com | Sem comentários

Um post r?pido para compartilhar algo que pode ser ?til a mais algu?m…

Recentemente fiz o upgrade do meu Macbook Pro do Mac OS X Snow Leopard para o Lion, depois de todas as atualiza??es de software, no uso do dia a dia notei que o Lion estava absurdamente lento, Google Chrome, Mozilla Firefox, o Eclipse (esse estava de chorar e desanimador de t?o lento que estava)

Lendo os blogs, achei 2 dicas que resolveram o problema:

1 – Verificar e reparar as permiss?es de acesso ao HD

Caminho: Finder > Applications > Utilities > Disk Utility

Selecionar o drive que representa o Mac, depois clicar no bot?o: Verify Disk Permissions, esperar finalizar e depois no bot?o: Repair DIsk Permissions

Link do post com as dicas: Speed up Mac OS X Lion

Desde post tamb?m revisei as configura??es do Spotlight.

2 – Limpar os caches

Abrir o Finder > Menu: Go > Go Folder | ou executar o atalho: Shift + Command + G

Digite: ~/Library/Caches

Apague o conte?do deste diret?rio

Caso n?o tenha total seguran?a se deve apagar todos os arquivos e diret?rios, fa?a um backup, copiando o conte?do da pasta para outro diret?rio. Obs.: esse passo n?o ? necess?rio, mas caso queria alguma garantia de o que fazer se algo der errado ter? as c?pias.

Aten??o: alguns diret?rios e arquivos n?o ser?o exclu?dos pois est?o em execu??o, por exemplo, cache referente ao Finder e a alguns outros aplicativos do Mac OS X.

Reinicie seu Mac.

Link do post com a dica: OSX Lion – Clear your caches!

Feito estes procedimentos, os aplicativos e o Mac OS X Lion passou a ter uma performance e resposta aceit?vel, assim como tinha no Mac OS X Snow Leopard.

Veja também:

Dez 14

Testes Unitários com JUnit – De volta ao básico

Escrito por DClick Team em 1, 2.0, 4, 6, Air, AR, arte, C#, case, class, classe, classes, cliente, código, comparação, demo, Desenvolvimento, Design, Download, Eclipse, err, erro, exemplo, falha, Ferramenta, Flex, for, framework, Google, ide, IE, if, int, Introdução, Java, NaN, O, on, Opinião, Outros, padrão, Plugin, print, rest, RIA, Ria’s Geral, S+S, Sem categoria, site, string, Sun, super(), TAT, Tema, Teste, Twitter, UI, uint @ 12 14th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Já que ultimamente estamos falando bastante de testes unitários, principalmente aqui na DClick, vamos revisar uma das ferramentas essenciais para executar essa tarefa: JUnit. Mais especificamente, vamos fazer alguns testes com o JUnit 4.8.1, que pode ser encontrado para download no site do projeto, ou até mesmo no repositório do maven.
A proposta desse post é apresentar a ferramenta para quem ainda não conhece, e relembrar ou até mesmo mostrar algumas funcionalidades muito úteis para nosso dia a dia de desenvolvimento.

Um pouco sobre a nova versão

Nas versões anteriores do JUnit, da 3.* pra baixo para ser mais exato, era necessário criar as classes de testes seguindo uma hierarquia pré-definida do JUnit para que os testes fossem executados. Era necessário extender uma das classes de Test Case do JUnit, e seus métodos precisavam seguir um padrão de nome específico definido pelo framework.
Com a versão 4.* e a introdução ao suporte a Java 5, agora todas as configurações de testes unitários em JUnit são feitas via anotações, o que na minha opinião é muito mais rápido e fácil, tornando muito mais agradável e flexível escrever testes unitários. Agora é possível definir umahierarquia específica para os testes do projeto, podendo abstrair muitas inicializações e padrões do sistema, facilitando o reaproveitamento e aumentando a velocidade de desenvolvimento. Afinal a maior parte do tempo gasto em desenvolvimento é com os testes.
Porém, com anotações, perdemos o acesso direto aos métodos de asserção de valores que as super classes definiam. A solução adotada foi tornar todos esses métodos estáticos e públicos, em uma classe específica para guardá-los: org.junit.Assert.
Pode parecer uma solução não muito elegante do ponto de vista de código, e de fato não é quando consideramos código que será distribuído e deploiado, porém é uma solução que faz total sentido no escopo dos testes unitários, tornando fácil o uso e acesso a tais funcionalidades.

Asserções

Para testar nosso código, o JUnit fornece os métodos de assert. O conceito é muito simples, todo método de asserção recebe um valor que é o correto esperado pelo teste, e o outro valor que é o devolvido pelo seu código. A comparação é executada, e o teste falha caso sejam diferentes e passa caso sejam iguais. Apenas com esse conceito é possível testar todo o código, basta saber quais são os valores que devem ser testados para garantir o funcionamento do código.
A chave para escrever um teste unitário que cobre muito bem o seu código, é colocar as asserções nos valores realmente relevantes ao funcionamento do sistema. Algumas vezes por exemplo, não é preciso testar um valor intermediário gerado pelo código, apenas o resultado final, outras vezes esse valor intermediário gerado é crucial para o resultado final, e portanto deve ser verificado também.
Quando eu menciono ‘valores’, entenda que um valor pode ser qualquer objeto Java, portanto é muito importante implementar o equals e hashcode de seus objetos de resposta que serão testados pelo JUnit.

Exemplo Prático

Vamos criar um exemplo de classe de testes com o JUnit 4 para vermos como funciona na prática a execução de testes unitários.
Se você utiliza o Eclipse, você já possui instalado o plugin de execução de testes do JUnit, caso você não tenha tal plugin, recomendo que instale posi facilita muito a execução e depuração dos testes.
Vamos criar uma classe de testes:

1
2
3

public class JUnitTestCase

Repare que apesar do nome parecer que segue algum padrão, não é necessário que a classe tenha nenhuma dessas palavras em seu nome. Porém esta classe ainda não é uma classe de testes do JUnit. Para torná-la um teste, crie um método da seguinte forma:

1
2
3
4

@Test
public void metodoQualquer()

Repare na anotação org.junit.Test. Essa anotação diz que nosso método ‘metodoQualquer’ é um teste do JUnit. Perceba também que seu retorno é ‘void’ e ele não recebe nenhum argumento. Agora nossa classe é um teste propriamente dito. Simples assim. Vamos adicionar uma asserção agora para ver o funcionamento da mesma. Dentro do método que acabamos de criar, adicione a seguinte chamada:

1	Assert.assertEquals(“2 dividido por 2 deveria ser 1.”, 1, 2 / 2);

Repare que o primeiro argumento do método, é a mensagem que vai aparecer caso o método falhe. Mude o valor obtido (último argumento) para ver a mensagem de erro.
Esse é o básico de execução de testes. Por mais simples que possa parecer, esse é o ponto de partida. Agora existem outras funcionalidades qua ajudam a escrever testes mais complexos, por exemplo, se precisarmos criar um objeto mais complexo para nossos testes, fazemos o seguinte, adicione o seguinte código em nossa classe de testes:

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

private String stringLocal;

@Before
public void inicializaLocal()
System.out.println(“Inicializou.”);
this.stringLocal = “inicializada”;

@Test
public void testInicializadaLocal1()
Assert.assertEquals(“A String deveria estar inicializada.”, “inicializada”,
this.stringLocal);

@Test
public void testInicializadaLocal2()
Assert.assertEquals(“A String deveria estar inicializada.”, “inicializada”,
this.stringLocal);

@After
public void setaNull()
System.out.println(“Setou nulo.”);
this.stringLocal = null;

Rode o teste e veja o que aparece no console.
Repare que a String é inicializada e setada novamente pra ‘null’ 3 vezes. Isso porque nossa classe possui 3 métodos de testes, e os métodosanotados com @Before rodam sempre antes de todos os métodos de teste. O mesmo vale para os métodos anotados com @After, só que estes rodam depois de executar os métodos de teste.
Só com essas duas anotações é possível criar cenários que estão sempre ‘zerados’ e corretamente incializados para cada teste que será executado em sua classe. Perceba que com isso é possível separa melhor as asserções em suas classes em mais métodos, deixando mais específico e focado cada método de teste.
Porém algumas vezes queremos inicializar algum objeto para o teste todo, sem precisar de algo específico para cada execução. Nesse caso existem duas outras anotações que podem ser úteis. Adicione o seguinte trecho em nossa classe de testes:

1
2
3
4
5
6
7
8
9

@BeforeClass
public static void antesDeTudo()
System.out.println(“Executado Antes.”);

@AfterClass
public static void depoisDeTudo()
System.out.println(“Executado Depois.”);

Só existe um restrição com essa abordagem, e acho que está claro no código qual que é: o escopo dessas chamadas é estático. Repare que os métodos precisam ser estáticos, e portanto as incializações só servirão para propriedades que são estáticas em sua classe de testes.
Essa funcionalidade possui esse comportamento porque o JUnit instancia um novo objeto da sua classe de testes para cada método que será rodado, dessa forma ele garante um melhor isolamento dos testes, tornando-os mais unitários por assim dizer. Dessa forma somente métodos estáticos são garantia de execução antes de todos os outros métodos.
Rode o teste e veja a ordem das mensagens em seu console.

Próximos passos

Essa foi uma introdução muito simples do JUnit e testes unitários. Acho que já passou pela sua cabeça muitas formas de inicializar, integrar e rodar testes em sua aplicação usando JUnit, o que é ótimo, mas ainda existem boas práticas para criar testes assim como existem boas práticas para escrever código, afinal testes são linhas de código também.
O segredo de um bom teste unitário é o quanto ele consegue cobrir do funcionamento do código, sem que seja necessário escrever um teste extremamente detalhado que deixe o código acoplado demais, e não permita muita mudança no código original. Se você investir tempo demais testando TODOS os valores possíveis de suas classes de maneira extremamente detalhada, quando o cliente pedir que um requisito mude, você com certeza vai ter a sensação de trabalho jogado fora, e desânimo por ter que escrever tudo novamente. A idéia é utilizar padrões de design para testes unitários, de forma que se mantenha a cobertura de código no 85%+ e ainda deixe os testes bem flexíveis a mudança. Difícil mas não impossível, e sim, é muito mais difícil e trabalhosos escrever testes realmente bons, do que escrever o código que será testado.

Por @Gust4v0_H4xx0r

Dez 5

Play Framework – alta produtividade em Java

Escrito por Erko Bridee em .NET, 1, 2.0, 4, 6, action, Adobe, Adobe Flex, apache, api, AR, Arquitetura, BI, blog, browser, C#, case, class, cliente, Componente, Componentes, control, Controles, CRUD, css, Curso, Cursos, dados, Desenvolvedor, desenvolvedores, Desenvolvimento, Desktop, Dica, Download, Eclipse, email, engine, err, erro, exemplo, Exemplos, Flex, Flexmania, for, framework, Frameworks, gae, Geral, git, Google, Hibernate, html, ide, IE, if, image, imagens, int, internet, Java, JPA, Links, mg, mvc, novidade, Novidades, O, on, Outros, produtividade, rails, rest, RIA, Ria’s Geral, ruby, ruby on rails, S+S, server, servidor, site, state, tag, TAT, Tema, template, Teste, Tree, Tutorial, UI, UX, Ved, web, Web Service, XML, XP @ 12 5th, 2011 | via http://blog.erkobridee.com | Sem comentários

O Play ? um framework open source para aplica??es web, escrito em Java, que possibilita o desenvolvimento de aplica??es web que seguem o padr?o MVC. Tem por objetivo otimizar a produtividade do desenvolvedor atrav?s do uso de configura??o sobre conven??o (CoC). Com recompila??o feita durante a execu??o da aplica??o, e caso ocorra algum erro, o respectivo ? exibido no browser, indicando a linha do erro.

Aten??o: o objetivo desse post ? realizar uma vis?o geral do que se trat? o Play Framework que temos ouvidos os coment?rios na internet.

O Play Framework torna o desenvolvimento de aplica??es Java e Scala uma tarefa f?cil para o desenvolvedor.

Site: Play Framework

Descubra uma alternativa limpa e leve para as atuais aplica??es Java Enterprise. O Play ? focado na produtividade do desenvolvedor e tem por alvo a arquitetura RESTFul.

Apesar do Play ter sido escrito em Java, ele suporta a linguagem Scala desde a vers?o 1.1 (hoje[Dezembro/2011] est? na vers?o 1.2.4). Este ano a empresa Typesafe (respons?vel pela linguagem Scala), anunciou a aquisi??o do Play Framework e este ser? mantido pela empresa. Uma das novidades relacionado a este anuncio ? que a vers?o 2.0 o n?cleo do Play Framework est? sendo totalmente reescrito em Scala.

Um v?deo para uma breve apresenta??o do Play Framework: Desenvolcendo uma aplica??o web em 10 minutos

Motiva??o

O Play foi muito inspirado no Ruby on Rails e Django. Um desenvolvedor familiarizado com qualquer um desses 2, ir? se sentir em casa.

Algo que ? fato, Ruby on Rails e Django s?o produtivos, ent?o por que n?o ter o mesmo n?vel de produtividade com java?

O Play utiliza do poder das aplica??es Java, por?m sem o “sofrimento” necess?rio para o desenvolvimento de aplica??es centradas no modelo Java Enterprise. Libertando das metodologias e ideologias relacionadas ao desenvolvimento de aplica??es Java EE, o Play prove para os desenvolvedores uma maneira f?cil e elegante de trabalhar, visando o aumento da produtividade.

Caso voc? queria, basta um editor de c?digo e ser? mais que o suficiente para o desenvolvimento de aplica??es, chega a ser incr?vel pensar que conseguiremos desenvolver aplica??es Java Web sem a necessidade de um IDE (Eclipse, Netbeans, …), mas vale lembrar, que estas IDE's ainda possuem seus atrat?vos e auxiliam em nossa produtividade.

Apesar de que as aplica??es desenvolvidas com o Play, foram projetadas para executar dentro do JBoss Netty Web Server, as aplica??es podem ser empacotadas em arquivos WAR e distribu?das para outros servidores de aplica??es Java EE (ex.: Apache Tomcat).

Maiores diferen?as com os demais frameworks

Stateless: o Play ? totalmente RESTful – n?o existe conex?o por sess?o Java EE. Isto torna o Play muito mais escal?vel que os demais frameworks.

Sem configura??o: realizar o download, descompactar e desenvolver.

F?cil ida e volta: sem necessidade de deploy no servidor de aplica??o, apenas edite o c?digo e atualize o browser.

Teste unit?rio integrado: suportes nativos para JUnit e Selenium.

API elegante: raramente um desenvolvedor ter? a necessidade de importar alguma lib. O Play j? disponibiliza a maioria dos recursos necess?rios para o desenvolvimento de uma aplica??o.

M?todos est?ticos: todos os controles de entrada e m?todos de neg?cio s?o declarados como est?ticos. E isto ? de fato bem diferente o que vemos nos demais frameworks Java.

I/O Ass?ncrona: atrav?s do uso do servidor web JBoss Netty, o Play consegue disponibilizar e tratar uma enorme quantidade de requisi??es ass?ncronas.

Arquitetura Modular: assim como Rail e Django, o Play utiliza o conceito de m?dulos. O que possibilida um meio elegante e simples de expandir o core do Play.

M?dulo CRUD: f?cil constru??o de UI administrativas com pouco c?digo.

M?dulo Scala: disponibiliza um suporte completo para Scala.

Componentes

O Play utiliza massivamente algumas bibliotecas populares:

JBoss Netty para o servidor web.
Hibernate para a camada de dados.
Groovy para a os templates.
O compilador do Eclipse para atualiza??o da aplica??o sem necessidade de realizar um deploy da aplica??o para testar as altera??es (hot-reloading).
Apache Ivy para gerencimanto de dependencias.

Funcionalidades presentes no n?cleo do Play:

Um framework RESTful limpo e leve.
CRUD: um m?dulo para simplicifar a edi??o de modelos de objetos.
Secure: um m?dulo para habilitar um sistema de autentifica??o de usu?rios.
Um framework de valida??o baseado em anota??es.
Um Job Scheduler (agendamento de tarefas).
Suporte para emails SMTP de maneira simples.
Suporte para JSON e XML.
Uma camada de persist?ncia baseada em JPA.
Uma base de dados embutida para r?pido deploy e testes da aplica??o.
Um framework completo para realiza??o de testes.
Funcionalidade para upload de arquivos.
Suporte para m?ltiplos ambientes de desenvolvimento.
Uma poderosa engine de templates baseadas em Groovy com templates, hierarquias e tags.
Arquitetura modular, que possibilita criar novas funcionalidades para o n?cleo facilmente.
Suporte para OpenID e clientes de Web Service.

Links ?teis

Informa??es a mais da Wikipedia

Overview do Play Framework 1.2.4

Documenta??o Play Framework 1.2.4

A documenta??o foi algo que achei interessante, me parece bem completa com bastante exemplos e informa??es de como utilizar as funcionalidades presentes no Play Framework.

Suporte para a linguagem Scala

Utilize a IDE de sua prefer?ncia (Eclipse, Netbeans, …)

Se por um acaso voc? utilize o Sublime Text 2, veja esse suporte para este editor de c?digo [github]

Reposit?rio de M?dulos

Dentre eles temos: MongoDB, GAE, Gera??o de PDF, GWT, SASS e SCSS, entre outros.

E agora?

Bom agora que j? temos uma boa id?ia do que se trata o Play Framework ? baixar e come?ar a testar e ver se na pr?tica ele ? bom mesmo.

Hora de fazer o download, instalar e colocar a m?o no c?digo: Tutorial para seguir e ver uma aplica??o do in?cio at? o “fim”

Eu particularmente ainda possuo algumas quest?es em aberto para descobrir as respostas, dentre elas est? uma: - Como ? que eu utilizo o Play Framework em um projeto com uma equipe? At? o momento s? tenho visto casos onde s?o apresentados desenvolvimetno de aplica??es r?pidas, por?m com um ?nico desenvolvedor…

No meu caso eu vou atr?s dessa reposta.

Veja também:

Nov 5

Principais erros ao startar o JBOSS através do eclipse

Escrito por Daniel Schmitz em 1, 2.0, 6, AR, BI, C#, Eclipse, err, erro, for, Formação, how-to, O, on, Partilha, Pessoal, Ria’s Geral, S+S, Sem categoria, server, serviço, Wordpress @ 11 5th, 2011 | via http://flex.etc.br | Sem comentários

Pessoal, o nosso leitor Joabio Vilela está compartilhando esta informação conosco sobre alguns erros ao iniciar o JBOSS no eclipse:

1 – porta 8080 ocupada por outro serviço.

2 –

, ver:

http://community.jboss.org/thread/2390?tstart=0

3 – timeouts, ver:

http://manoharbhattarai.wordpress.com/2010/05/06/jboss-server-unable-to-start-within-50-seconds-how-to-increase-the-jboss-server-start-time/

Agradeço ao nosso leitor por compartilhar

Ago 3

Gerir projectos no Eclipse, Flash Builder, Zend, Aptana, etc

Escrito por riaPT em Best Practices, Eclipse, Flash Platform, Flex, Ria’s Geral, RIAPT, Rich UI, Scrum, Vídeos @ 08 3rd, 2011 | via http://riapt.org | Sem comentários

A versão 1.5 do Airgile – uma plataforma online de gestão de equipas e projectos -, lançada esta semana, suporta agora a interligação com IDEs baseados em Eclipse, como o Flash Builder, Zend ou Aptana, entre outros. Este conector permite que gestores de projecto e equipas de desenvolvimento possam colaborar de uma forma mais eficaz.

O gestor de projecto irá usufruir do conforto do Airgile para gerir e acompanhar a evolução dos projectos, delegando tarefas aos consultores e programadores. Estes receberão as tarefas directamente no Eclipse, a sua ferramenta de trabalho de eleição. À medida que completam as tarefas, os consultores podem fechá-las directamente no Eclipse, que irá sincronizar com o Airgile (automaticamente), actualizando os indicadores e notificando o gestor de projecto.

Este é o workflow de gestão que usamos na Webfuel, ligando o Eclipse antigamente ao Trac e actualmente com o Airgile – que é mais rápido e confortável. É relativamente fácil configurar a ligação, estando as instruções disponíveis aqui.

No vídeo abaixo, a partir dos 5:45 é possível ver o conector em acção.

Esta versão do Airgile, entre dezenas de novidades, possui agora um novo interface gráfico, ainda mais leve e intuitivo.
Desde a versão 1 foram adicionadas muitas novas funcionalidades ao Airgile, como a filtragem avançada, registo de actividade, ferramentas de planificação, criação/edição rápida de tarefas, e faseamento de projectos, entre outras. As próximas versões contarão com planeamento de Sprints e um Burndown-chart para projectos baseados em SCRUM.

Tarefas partilhadas entre o Airgile e o Eclipse

Tarefas partilhadas entre o Airgile e o Eclipse

Mai 9

Flash Builder 4.5 – Produtividade e Desenvolvimento para Mobile

Escrito por riaPT em Adobe Air, Eclipse, flash, Flex, mobile, Ria’s Geral, Ria's Geral, Rich UI, Vídeos @ 05 9th, 2011 | via http://riapt.org | Sem comentários

Foi lançado esta semana o Flash Builder 4.5 cujas novidades assentam no desenvolvimento para Smartphones e Tablets e nas ferramentas de aumento de produtividade.

O aumento de produtividade no Flash Builder destaca-se através de várias pequenas mas extremamente úteis funcionalidades para simplificar a vida do programador enquanto escreve código, tais como:

Code templates – o Flash Builder traz cerca de uma centena de code templates, mas estes são configuráveis pelo programadorsendo fácil adicionar novos. Para activar um code template, basta, por exemplo, escrever “fori”, carregar CTRL+Space, e o Flash Builder escreverá automaticamente “for (var i:Number = 0 …. etc”.

Code completion para Metadata – basta escrever [B (Ctrl+Space) e o FB preenche o resto

Live error Highlighting - ao escrever código o Flash Builder agora aponta os erros sem ser necessário compilar. De notar que isto funciona com grande parte dos erros, mas não com todos.

Melhorias no IDE - a performance do IDE foi melhorada, tal como a velocidade de compilação. O design mode agora consegue fazer o rendering de views mais complexas

Quick-assist - na realidade esta não é uma, mas sim dezenas de funcionalidades. O Quick-assist é um atalho (CTRL+1) que quando é chamado abre um menu com várias opções, de acordo com o contexto, como por exemplo:

Geração de event handlers
Organização dos imports
Criação de métodos automática
Declaração de variáveis
Promoção de variáveis locais para propriedades da classe
[... outras ...]

Neste vídeo do Serge, é possível ver algumas destas funcionalidades em acção:

Relativamente ao desenvolvimento para dispositivos móveis, o Flash Builder é agora um ambiente extremamente confortável para desenvolver para smartphones e tablets Android, iOS e BlackBerry (Playbook).

A versão que foi disponibilizada ainda só exporta aplicações para Android, mas muito em breve será lançado um update que permite exportar a mesma aplicação com o mesmo código para iOS.

O Flex SDK possui agora um conjunto de componentes “light” especialmente optimizados para telemóveis e ainda uma framework que simplifica o desenvolvimento? ao gerir pelo programador a navegação entre as views, a “cache” dos dados em cada view, etc.? No desenvolvimento para Mobile é importante ter em conta as diferentes resoluções e densidades de cada smartphone – o Flash Builder possui ferramentas para gerir confortavelmente o desenvolvimento para diferentes ecrãs (multi-screen development).

Neste vídeo do Serge podemos ver mais sobre o desenvolvimento para Mobile:

Este é também um vídeo interessante que mostra os Charting components a correr no iPad, iPhone, Android e BlackBerry Playbook:

Para quem pretende explorar mais o desenvolvimento para Mobile usando Adobe Air, deixo aqui este recurso (embora não seja completamente orientado ao Flex):

Book cover of Developing Android Applications with Adobe AIR

Esta é, na minha opinião, a melhor release do Flash Builder até ? data. Ou pelo menos, é a mais sólida e que eleva o desenvolvimento em Flex para outro patamar, muito próximo da experiência de desenvolvimento típica no mundo JAVA.

Eu, o Rui Silva e o João Fernandes acompanhamos esta release desde o início e tivemos a oportunidade de contribuir para a evolução da mesma. Orgulhosamente temos agora dois nomes portugueses nos créditos do Flash Builder, se bem que o João Fernandes também merecia. E não queria deixar de mandar um abraço para o Carlos Rovira ali na vizinha Espanha.

Não se esqueçam que podem sempre utilizar a Mailing List para partilhar as vossas experiências ou colocar questões ao resto da comunidade.

Mai 6

Flash Builder 4.5 Eclipse

Escrito por Felipe Borella em 1, 2.0, 4, 6, Adobe, AR, BI, builder 4, C#, Desenvolvimento, Eclipse, flash, flash builder, Flash Builder 4, Flex, html, instalação, int, iphone, mobile, O, on, Plugin, Ria’s Geral, S+S, Teste, UI, uint, XP @ 05 6th, 2011 | via http://www.fborella.com.br/blog/ | Sem comentários

Opa.

Fiz alguns testes com o Flash Builder 4.5 e fiquei impressionado com o desenvolvimento para mobile. Show de bola mesmo.
Bom para instalar o Eclipse juntamente com o Flash Builder é fácil.

Depois do Flash Builder instalado va ate a página http://kb2.adobe.com/cps/890/cpsid_89021.html que é bem fácil a instalação.

Tradução é +- isso:

Flash Builder 4,5 suporta a instalação de um plugin para o Eclipse uma instância existente. Para fazer isso:

Navegue até o local de instalação instalado o Flash Builder e abra a pasta Utilitários.
Execute o executável do Adobe Flash Builder 4,5 Plug-in Utility.exe.
Selecione o idioma e clique em OK.
Selecione o local de instalação do Flash Builder, se solicitado.
Selecione a pasta do Eclipse para o qual deseja Flash Builder 4.5 para ser conectado e clique em Avançar. (Nota: A cópia do Eclipse deve ser versão 3.6.1 ou posterior, de 32 bits e deve conter uma pasta chamada “dropins”)
Reveja a pré-instalação de resumo e clique em Install
Após a instalação, é recomendável que você edite o arquivo eclipse.ini para a instância do Eclipse, para que ele inclui as seguintes definições:

-Vmargs-Xms256m-Xmx512m-XX: MaxPermSize = 256m-XX: PermSize = 64m

E isso ai

Felipe.

Mar 21

Maven 3 – Mudanças e Melhorias

Escrito por DClick Team em 1, 2.0, 4, 6, análise, apache, api, AR, arte, Beta, BI, blog, bug, busca, class, código, configuração, control, Desenvolvedor, Desenvolvimento, Documentação, Download, Eclipse, err, erro, exemplo, falha, Ferramenta, Flex, for, html, ide, IE, if, image, int, internet, Java, mg, mudanças, NaN, O, on, Outros, padrão, Plugin, problema, problemas, programação, Projetos, relatório, Relatórios, rest, RIA, Ria’s Geral, site, tag, TAT, Tecnologia, Tutoriais, Tutorial, Twitter, UI, UX, validação, Ved, XML, XP @ 03 21st, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Maven – O que muda?

Vimos alguns tutoriais e posts que descreviam o funcionamento do maven, e tabmbém criamos alguns projetos com seus respectivos relatórios. Porém sempre utilizamos uma versão do Maven 2. Atualmente está disponível (não mais como beta) a versão 3 da ferramenta. Mas afinal, o que muda e como que sua aplicação construída utilizando Maven 2 irá se comportar com o Maven 3? Veremos!

Primeiras mudanças

A primeira coisa a se notar de diferente é a saída no terminal de comando gerada pelo Maven 3. Veja a saída em um projeto padrão maven criado para o exemplo:

Note que a divisão entre projetos está mais clara e que cada goal está explicitamente descrito com seus respectivos plugins, tornando mais fácil identificar possíveis problemas. Por exemplo vejamos o que forçarmos um erro no build:

Repare que ao executar o plugin maven-compiler-plugin do Maven na fase de compile ocorreu um erro que está descrito logo abaixo. Note também que agora o Maven sugere uma URL da documentação onde você pode encontar ajuda sobre a falha.
Caso mais de um erro tivesse ocorrido, seria descrito em ordem de ocorrência e se fosse possível sugerir ajuda, estariam descritas as URLs de ajuda.

Essa é a primeira mudança mais notável. Uma segunda mudança pode ser percebida também, mas é mais sutil: performance. A Apache diz que o Maven é muito mais performático que suas versões anteriores em muitos aspectos.
Eu trabalho com Maven a um bom tempo já e posso dizer por experência que sim, o Maven 3 é de fato mais rápido mas não o suficiente para impressionar e de fato afetar o dia-a-dia. Está mais rápido identificar alguns problemas que podem acontecer durante o build, isso sim eu acho que afeta mais no dia-a-dia.
Quanto aos downloads de artefatos, está melhor que nas versão anteriores, pois o download em paralelo está melhor implementado e portanto a banda é melhor gerenciado. Essa mudança também afeta no dia-a-dia de uma maneira positiva.
Outra melhoria de performance é com relação aos plugins externos. A Apache diz que a API de uso do Maven para plugins externos está muito melhorada, e que a integração está bem mais otimizada. Aqui na empresa utilizo bastante a integração com o plugin do Flex para o Maven (FlexMojos), e posso dizer que nesse ponto a mudança foi drástica. O build está de fato muito mais rápido que nas versão anteriores do maven e melhorou bastante no dia-a-dia do desenvolvimento.

Organização

A validação dos poms do projeto está mais bem estruturada e descrita pela ferramenta. Por exemplo, caso você repita uma dependência em um de seus poms, o build não será afetado, mas o Maven irá lhe alertar dos possíveis problemas:

Repare que é informada exatamente a posição do erro no pom do projeto e o que pode acontecer caso a inconsistência permaneça. Outro ponto para a versão nova da ferramenta. Muitos dos projetos que rodei o Maven 3 e estavam sobre o controle do Maven 2 apresentaram algum tipo de inconsistência que poderia interferir no controle de versões dos artefatos e até mesmo no funcionamento da aplicação.

Outra mudança na organização, é o controle do parent pom. Era comum criar projetos auxiliares aos projetos principais para guardar o pom que serviria de parent para os demais poms da aplicação. Era criado tal projeto para poder importá-lo no Eclipse como se fosse um projeto como qualquer outro. Dessa forma, o pom do projeto que agregava todos os sub-projetos servia apenas como descritor dos módulos presentes sendo que este também herdava do pom parent em um de seus sub-projetos. Temos um erro de consistência nesse caso, pois era necessário realizar o install deste sub-projeto antes de todos os outros, e no build com todos os projetos portanto, a versão do parent pom era sempre uma anterior a que está sendo instalada.
Na versão nova da ferramenta tal organização é ainda tolerada, mas é lançado um aviso de que existe tal inconsistência, e de que possivelmente as próximas versões do Maven não irão mais suportá-la. O único problema com essa organização é não poder importar o projeto no Eclipse de maneira simples, pois o projeto pai trará todos os filhos como sub-pastas do mesmo, mas é de fato melhor em termos de organização e facilita na manutenção do parent pom.

Muitas outras validações são feitas nos poms do projeto que são muito úteis para manutenção e controle das versões das bibliotecas da aplicação.

Reporting

Reporting no Maven 2 possui sua própria tag no xml do pom do projeto. No Maven 3 tal tag é ignorada e portanto seus projetos devem ser refatorados para que os relatórios ainda funcionem. Isso acontece porque agora o módulo de relatórios do maven está completamente independente da ferramenta, e portanto deve ser executado por um plugin. Portanto a descrição dos relatórios deve ser feita na tag de build do pom na parte de plugins.
A configuração mudou um pouco, pois agora os tipos de relatórios são descritos como configuração do plugin de geração de relatórios do maven, por exemplo um pom compatível com a versão 3 do Maven:

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

>
? ? …
? ? >
? ? ? ? …
? ? ? ? >
? ? ? ? ? ? …
? ? ? ? ? ? >
? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? >maven-site-plugin>
? ? ? ? ? ? ? ? >3.0-beta-3>
? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >maven-project-info-reports-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.3.1>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >maven-source-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.1.2>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >maven-javadoc-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.7>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.codehaus.mojo>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >cobertura-maven-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.4>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>html>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>xml>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.codehaus.mojo>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >findbugs-maven-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Low>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >Default>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.3.1>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >maven-jxr-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.2>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.apache.maven.plugins>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >maven-pmd-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.5>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >1.6>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ? ? ? >org.codehaus.mojo>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >jdepend-maven-plugin>
? ? ? ? ? ? ? ? ? ? ? ? ? ? >2.0-beta-2>
? ? ? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? >
? ? ? ? ? ? ? ? >
? ? ? ? ? ? >
? ? ? ? >
? ? >
? ? …
>

Nesta configuração estou gerando uma série de relatórios de cobertura e análise de código, assim como alguns de documentação também. Repare que é necessário utilizar o maven-project-info-reports-plugin, isso porque o site gerado pelo maven por padrão não gera um index.html que serve de agregador dos demais relatórios, por isso este plugin está presente na configuração.

Conclusão

Em conclusão o Maven 3 é mais um passo bem grande na evolução da ferramente que tem como objetivo tornar mais intuitivo o uso e menos intrusivo no dia-a-dia do desenvolvedor.
A integração com plugins externos está muito melhorada, o que acredit que possibilitará muitas outras integrações com diversas outras tecnologias em um mesmo projeto, facilitando muito o controle de versões e a manutenção dos projetos.
A parte de relatórios fiquei um pouco decepcionado com a mudança, pois a documentação ainda não deixa claro exatamente o que foi alterado e o que deixou de fazer parte da execução padrão, tive que chegar nessa configuração por tentativa e erro e buscando na internet por pessoas que passaram pelos mesmo problemas. O resultado obtido é exatamente o mesmo, exceto por um bug que não gera o site do pom parent linkando todos os seus filhos em uma mesma página. Este sim é um problema que afeta no dia-a-dia, principalmente se você executa o build de maneira contínua, gerando os relatórios para deixá-los disponíveis na empresa.
De resto acredito que o Maven ainda tem muito a oferecer, e existem outras melhorias as quais não abordei aqui no post, mas que assim que passar por elas irei postando aqui no blog.

Por @Gust4v0_H4xx0r

Mar 7

BlazeDS – do básico ao avançado – Parte 1

Escrito por DClick Team em 1, 2009, 4, 6, action, Actionscript, Adobe, AMF, apache, app, AR, arte, auto, BI, Blazeds, blog, botão, class, classe, cliente, código, código fonte, Componente, componente flex, Componentes, comunicação, configuração, control, Controls, Crossdomain, custom, dados, demo, developer, Diversos, Documentação, Download, Eclipse, err, erro, event, Evento, events, exemplo, Exemplos, falha, flash, Flex, fonte, for, framework, Frameworks, function, Galileo, git, handle, Hibernate, HTTPService, ide, IE, if, image, instalação, int, Java, library, LOB, Messaging, mg, MXML, NaN, O, on, opensource, Outros, Plugin, problema, problemas, pt, reference, referencia, Remoting, RIA, Ria’s Geral, runtime, screen, Screencast, screencasts, Segurança, Sem categoria, server, serviço, Serviços, servidor, site, spark, Spring, string, tag, TAT, Tecnologia, Twitter, UI, uint, web, Webservice, window, XML @ 03 7th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

BlazeDS é uma aplicação Java opensource mantida pela Adobe, sob licensa GNU Lesser General Public License, Version 3 (LGPL v3), que fornece um conjunto de serviços, todos sobre o protocolo HTTP(Hyper Text Transfer Protocol), para permitir uma aplicação Flex fazer chamadas a serviços remotos Java, retornando os dados tanto de forma assíncrona como em tempo real.

Por utilizar o formato de dados binário chamado AMF(Action Message Format) para a serialiazação e deserialização de dados, a comunicação entre uma aplicação Flex e o servidor Web se torna muito otimizada. Existem estudos feitos comparando as diversas tecnologias, como o Jamesward, mostrando o potencial do AMF.

Outra grande vantagem quando usamos o BlazeDS é a facilidade de ter classe Java automaticamente convertida para uma classe ActionScript e vice-versa.

O BlazeDS pode ser baixado do site da Adobe em dois formatos:

Turnkey – Versão que já vem com exemplos e servidor tomcat pré configurado
Binary – Versão com os binários

Você pode optar também por fazer o download do código fonte. A documentação também está disponível neste link.

Entendendo os arquivos de configuração do BlazeDS
A estrutura de arquivos do BlazeDS é bem simples, quando descompactamos o blazeds.war, presente na versão binária, podemos ver a seguinte estrutura:

Devemos nos atentar a duas pastas. A pasta lib, que contém todos os jars necessários, e a pasta flex, que contém todos os arquivos de configuração do BlazeDS. Vamos ver o que cada arquivo significa:

services-config.xml: É neste arquivo que estão as principais configurações do BlazeDS como segurança, logging, serviços disponíveis (Canais), fábricas para a integração com Frameworks Java como Spring e EJB3 e as referências para os outros três arquivos de configuração.
remoting-config.xml: É nesse arquivo que iremos configurar os serviços Java para serem “consumidos” pela aplicação Flex. Sempre quando configuramos este arquivo, iremos trabalhar com o componente Flex chamado RemoteObject.
message-config.xml: Aqui é configurado tudo o que for relacionado com mensageria, sempre necessário quando trabalhamos com os componentes Flex Consumer e Producer. Um exemplo da utilização desta tecnologia seria fazer um bate bapo, ou até mesmo aplicações colaborativas, onde é desejável a iteração simultânea de diversos usuários.
proxy-config.xml: Além da possibilidade de utilizarmos o componente RemoteObject, o Flex disponibiliza mais duas formas de integração: O HTTPService e o WebService. Porém, por questões de segurança, os serviços só podem ser chamados quando os mesmos estão no mesmo domínio que a aplicação, ou que exista uma configuração específica que permita um cliente Flex fazer a consulta (esta configuração é feita por um arquivo chamado crossdomain.xml e está sempre no servidor onde está o serviço chamado). Caso uma das duas condições acima não seja satisfeita, deveremos utilizar o BlazeDS como proxy , e é ai que configuração deste arquivo se torna necessário.

Criando o seu primeiro projeto com o BlazeDS

Para criar o projeto iremos precisar de:

Feito os downloads e a instalação do Eclipse e FlashBuilder, vamos iniciar o FlashBuilder para criar o projeto.
Antes de criar o projeto, vamos configurar o Tomcat:

Nas preferências do Eclipse, vá em Server — Runtime Environments e clique em Add…
Na pasta Apache selecione Apache Tomcat v6.0 e clique em Next
Selecione a pasta onde você descompactou o Tomcat e clique em Finish

Feito a configuração do Tomcat, vamos criar o projeto:

Vá em File – New – Flex Project
Preencha os dados do primeiro passo como na imagem abaixo e clique em Next
Neste passo vamos configurar os dados do servidor. Deixe tudo configurado como na imagem e clique em Next

Para selecionar o “Target Runtime”, clique em New e depois escolha o Apache Tomcat 6, como na imagem abaixo.
No último passo não será necessário mudar nada, clique em Finish

Agora vamos criar a classe Java que terá o serviço para retornar a string “HelloBlazeDS”

Crie uma classe Java br.com.dclick.service.RemotingService
Crie o serviço:

1
2
3
4
5
6
7
8

package br.com.dclick.service;
public class RemotingService {

? ? public String sayHello() {
? ? ? ? return “HelloBlazeDS”;
? ? }
? ?
}

Agora vamos configurar o BlazeDS para disponibilizar o serviço que acabamos de criar.

Abra o arquivo remoting-config.xml que está na pasta WebContent/WEB-INF/flex

Para que seja possível chamar os métodos da classe Java, precisamos configurar um destination. Isso é necessário para cada classe Java.
O arquivo fica assim:

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

xml version=“1.0″ encoding=“UTF-8″?>
“remoting-service” class=“flex.messaging.services.RemotingService”>
? ?
? ? ? ? “java-object”
? ? ? ? ? ? class=“flex.messaging.services.remoting.adapters.JavaAdapter”
? ? ? ? ? ? default=“true” />
? ?
? ?
? ? ? ? “my-amf” />
? ?
? ? “blazeServices”>
? ? ? ? ? ? ? ? ? ? br.com.dclick.service.RemotingService
? ? ? ? ? ?

Vamos colocar na aplicação a chamada para o servidor.

A primeira coisa que precisamos fazer é configurar o RemoteObject. Fazer isso é muito simples:

1
2
3
4
5

? ? ? ?
? ? ? ? “services” destination=“blazeServices”
? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)”
? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” />
? ?

Alguns detalhes:

* Perceba que a propriedade destination aponta para o destination que configuramos no arquivo remoting-config.xml

* Precisamos declarar um id para poder referenciar o RemoteObject

* Adicionamos um ResultHandler para tratar o resultdo do serviço

* Adicionamos um FaultHandler para tratar a falha do serviço

Os Handlers ficam assim:

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

? ? ? ?
? ? ? ? [CDATA[
? ? ? ? ? ? import mx.controls.Alert;
? ? ? ? ? ? import mx.rpc.events.FaultEvent;
? ? ? ? ? ? import mx.rpc.events.ResultEvent;

? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? Alert.show(event.result.toString());
? ? ? ? ? ? }

? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? Alert.show(event.fault.message);
? ? ? ? ? ? }

? ? ? ? ]]>
? ?

Alguns detalhes:

* A propriedade result do evento ResultEvent vai conter o resultado do serviço. No nosso caso o serviço retorna uma String “HelloBlazeDS”

* A propriedade fault do evento FaultEvent contém os detalhes do erro.

A última coisa é chamar o serviço. Vamos fazer isso no evento creationComplete, como segue:

1
2
3
4

? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? services.sayHello();
? ? ? ? ? ? }

A aplicação inteira fica assim:

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

? ? ? ? xml version=“1.0″ encoding=“utf-8″?>
“http://ns.adobe.com/mxml/2009″
? ? ? ? ? ?? ? xmlns:s=“library://ns.adobe.com/flex/spark”
? ? ? ? ? ?? ? xmlns:mx=“library://ns.adobe.com/flex/mx” minWidth=“955″ minHeight=“600″
? ? ? ? ? ?? ? creationComplete=“application1_creationCompleteHandler(event)”>
? ?
? ? ? ? [CDATA[
? ? ? ? ? ? import mx.controls.Alert;
? ? ? ? ? ? import mx.events.FlexEvent;
? ? ? ? ? ? import mx.rpc.events.FaultEvent;
? ? ? ? ? ? import mx.rpc.events.ResultEvent;

? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? Alert.show(event.result.toString());
? ? ? ? ? ? }

? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? Alert.show(event.fault.message);
? ? ? ? ? ? }

? ? ? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void
? ? ? ? ? ? {
? ? ? ? ? ? ? ? services.sayHello();
? ? ? ? ? ? }

? ? ? ? ]]>
? ?
? ?
? ? ? ? “services” destination=“blazeServices”
? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)”
? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” />
? ?

Agora só falta fazer o deploy da aplicação e subir o servidor.

Vá em Window – Show View – Other. Na janela que abrir, digite Servers e clique OK
Na view Servers, clique com o botão direito em Tomcat v6.0 e selecione Add and Remove…
Selecione a aplicação HelloBlazeDS e clique em Add e depois Finish
Na view Servers, clique com o botão direito em Tomcat v6.0 e clique em Run

Agora é só executar a aplicação e ver o resultado:

Isso é tudo, guarde esse projeto configurado para ser usado nos próximos posts.

Mar 2

Flex + NetBeans PHP ?

Escrito por Daniel Schmitz em Adobe, AR, BI, Desenvolvimento, Diversos, Download, Eclipse, email, flash, flash builder, Flex, html, ide, instalação, int, Java, Livro, Livros, O, on, PHP, Plugin, problema, problemas, procura, pt, RIA, Ria’s Geral, ruby, Tecnologia, Tema, Teste, UI, Vários @ 03 2nd, 2011 | via http://flex.etc.br | 2 comentários

Durante o desenvolvimento dos livros sempre tentei integrar a IDE do Adobe Flash Builder ao Eclipse PDT. Até no livro Desenvolvendo sistemas com Flex e PHP usei o Aptana PHP, que “morreu” naquele mesmo ano. Esta integração gerou alguns emails de leitores com problemas, problemas as vezes muito *esquisitos*, devido as inúmeras incompatibilidades internas do eclipse. Resumindo, a opção de integração entre Flex e PHP em uma mesma IDE só vale a pena se você gostar muito do Eclipse PDT, e se tudo der certo na instalação, claro.

Pensando bem sobre “como andas” o Eclipse PDT, decidi mudar minha IDE para o NetBeans PHP, e esquecer a tal integração entre as IDEs. O Netbeans PHP, pelo menos para mim, está melhor que o Eclipse PDT, em diversos aspectos. Talvez o Eclipse PDT com vários plugins “extras” até fique melhor, mas eu nao quero ficar em uma procura interminável de plugins. Eu uso o Netbeans que já vem com tudo que eu preciso.

Estou usando o Netbeans há 2 meses, o que me dá uma boa base para dizer que a IDE cumpre bem o que promete. E a partir de agora, passo a recomendá-la também. Então se você gosta de testar novas tecnologias e está sempre a procura de uma melhor IDE, teste também o Netbeans para PHP, ou então as inúmeras variações, para Java, Python e/ou Ruby: http://netbeans.org/downloads/index.html

« Entradas anteriores |