Eis que estava me atualizando e retornando ao mundo do HTML + JS + CSS, com isso a primera tarefa foi ver o que havia de bom no mercado. Observei que as libs e frameworks de JavaScript evoluiram além do que eu havia imaginado. Durante meus estudos e pesquisas acabei vendo muitos exemplos, onde as pessoas estavam utilizando o Backbone.js (alguns links sobre), porém não gostei muito da forma de trabalho, então um dia conversando com a galera na internet, o @vedovelli comentou sobre o Angular.js e outras pessoas além dele também me falaram muito bem a seu respeito, com isto resolvi construir uma aplicação e mecher um pouco para ver como é que ele se comporta durante o desenvolvimento de uma aplicação.

Com a missão de enriquecer o vocabulário HTML o framework AngularJS chega com a marca Google de simplicidade e promete um workflow diferente para os desenvolvedores.

Atenção não tenho intenção de escrever um post introdutório sobre o Angular.js, caso queira algo mais inicial recomendo antes de continuar a leitura ver os respectivos post's: 

Vedovelli - Introdução ao AngularJS

Tableless - Criando uma aplicação simples com AngularJS

O que me chamou atenção e me agradou no Angular.js?

Como venho do desenvolvimento de sistemas utilizando o Adobe Flex, sempre gostei da facilidade e flexibilidade para o desenvolvimento e definições de novos componentes, além da facilidade de programação oferecida pelo Flex. Algo similar a essa característica observei no Angular.js, em resumo, achei muito fácil e prático desenvolver uma aplicação utilizando o Angular.js.

O Angular.js possui uma funcionalidade de injeção de dependências que é muito inteligente e funciona muito bem. Por si só ele já consegue reconhecer os parametros dos controllers e injetar o respectivo objeto referente ao nome do paramâmetro.

Porém o Angular.js não te limita e restringe a utilizar obrigatóriamente estes nomes, que ele já sabe tratar, caso queira, você pode definir livremente o nome do parametro que desejar, então, basta definir o que deve ser injetado na respectiva sequência dos parâmetros que foi definido na function, conforme descrito na documentação (link $injector):

Outro ponto forte do Angular.js que me agradou é sua documentação: Doc 1.0.1 / Guide

Qual teste que eu realizei utilizando o Angular.js?

Já aviso, não fui nada criativo, resolvi construir a minha versão da aplicação: AngularJS GitHub Contributors ( app | github ), a qual acessava a API do GitHub e lista os repositórios públicos de um determinado usuário e respectivos contribuidores dos repositórios. Onde esta aplicacão utiliza a YUI Library do Yahoo para a definição da interface.

No meu caso reconstrui a aplicação utilizando como base o Twitter Bootstrap para a definição do layout da aplicação, e mudei algumas características da organização do código, porém na essência a idéia e aplicação é a mesma, com o adicional da listagem dos Gists públicos do usuário.

Outra diferença na implementação deste projeto foi a utilização do modelo de Closures para a definição dos controllers (github: controllers.js), seguindo uma boa prática de programação com JavaScript. Lembrando que o escopo de qualquer declaração de variável e/ou função é global valido para todo o HTML em execução pelo browser, o que pode gerar alguns problemas conforme a aplicação cresce de tamanho.

Um recurso que utilizei nesta aplicação foi o roteamento das URLs da aplicação (github: app.js) e injeção dos respectivos templates de html no (github: index.html), onde está a definição do div com o atributo ng-view

Mas onde está esta aplicação que até aqui você apenas falou?

Calma, calma, segue o link: ver a aplicação em execução / código no github.

E a estrutura ad aplicação?

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.

Como estou retornando ao mundo do HTML+JS é inevitável ter que voltar a codificar em JavaScript, certo? Bom, talvez não… para isto temos o CoffeeScript que apresenta uma proposta bem interessante de sintaxe e codificação que no final o resultado gerado é JavaScript.

CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again

O que achei interessante nessa apresentação foi a apresentação dos demais geradores de JavaScript, como GWT em java, entre outros, bom ao final dessa apresentação achei bem interessante e considerável o uso do CoffeeScript para gerar o JavaScript, utilizando uma sintaxe melhor e obviamente não apenas uma nova sintaxe, pois o CoffeeScript possui algumas facilitações de codificação bem interessantes.

No próprio site do CoffeeScript possui alguns exemplos e um local onde você pode escrever um coffeescript e ver o javascript resultado.

Um fato que me chamou atenção o compilador do CoffeeScript está vinculado ao NodeJS.

Atenção: vale lembrar que o CoffeeScript nada mais é que uma maneira diferente de codificar JavaScript, ou seja, caso queria utilizar jQuery ou outra lib JavaScript codificando via CoffeeScript é possível (How CoffeeScript makes jQuery more fun than ever).

Links úteis para instalação do CoffeeScript:

How To Install CoffeeScript On Mac OS X

5 Steps to Get Started with CoffeeScript (Mac OS X)

Node.js and CoffeeScript on Windows, Redux

CoffeeScript compilador para windows (GitHub)

Installing CoffeeScript on Ubuntu

Segue alguns links de introdução ao CoffeeScript:

What is CoffeeScript?

Simple CoffeeScript Introduction

A brief introduction to CoffeeScript

Introduction To Coffeescript & Node.Js By Pedro Teixeira

Let's Have a Cup of CoffeeScript

Plugin para os editores de código:

CoffeeScript GitHub

Plugin para o Sublime Text 2

Sublime Text 2 Build System Scripts: CoffeeScript & Node

Coffeescript package for Sublime Text (GitHub)

CoffeeScript with Sublime Text

Não adianta chorar o leite derramado, depois que a Adobe lançou as últimas notícias vemos que o mercado indo de vez para o HTML5 e não adianta reclamar, daqui para frente mais projetos irão demandar conhecimentos em HTML5 (novas tags), Javascript e sobre as novidades do CSS3.

Voltando ao mundo HTML teremos que voltar inevitávelmente ao uso do Javascript, mas ao menos a boa notícia hoje é que diferente de anos atrás temos disponíveis boas bibliotecas javascript para nos ajudar na difícil tarefa de fazer uma aplicação (que tente) funcionar em todos os principais web browsers do mercado (Google Chrome, Mozilla Firefox e o temível IE)

Quanto ao Javascript, hoje pelo que tenho visto é quase impossível se falar em javascript sem associar ao JQuery, que ajuda muito a criar um código mais limpo e organizado e até podemos dizer, sofrer menos com o uso do javascript.

Sobre Javascript e JQuery recomendo os respectivos materiais para observar:

The JQuery Essentials

Aos que ficaram interessados pelo JQuery o @bielversallini  mandou uma dica muito boa de curso web de JQuery, o jQuery Air, também jQuery Fundamentals e Livro fundamentos de jQuery 100% traduzido para pt-BR

jQuery Proven Performance Tips & Tricks, 2011

Confesso que desanimei ao ver esta apresentação, pois basicamente todos os recursos que gostei no JQuery são os mais lentos e recomendados para que não sejam usados a menos que não haja outra alternativa ou extremamente necessários.

jQuery & Responsive Web Design

Excelente dica de como projetar uma página/sistema que se adeque as dimensões disponíveis (por alguns este recurso é chamado de layout fuido/adaptativo). Como estou falando sobre layout recomendo olhar tambem o Knockout.js que possui recursos interessantes para auxiliar na definição da view.

Agora para falar a verdade mesmo o melhor material sobre desenvolvimento HTML+JS que vi que o autor foi real e sincero sobre o tema é o respectivo abaixo:

Taking JavaScript Seriously (feat. Backbone.js)

Como é dito nos slides, o javascript não é a melhor linguagem do mercado, ela foi escrita em 10 dias, possui muitas deficiências, mas temos que aprender pois não temos nenhuma outra opção.

Outro detalhe que me chamou atenção e achei muito útil foi a apresentação do Backbone.js como uma alternativa para suprir a necessidade de organizar o código em algo que tenta ser o mais próximo possível do MVC.

Mas e sobre arquitetura aplicações de larga escala? Bom recomendo observar este material abaixo, o qual indica as boas pratícas de mercado e atuais recursos disponíveis:

Large-scale JavaScript Application Architecture

Cheguei até esta apresentação através deste post.

Atenção este texto a seguir expressa minha opinião pessoal

Sinceramente esta apresentação foi o santo gral da agonia, pois para mim se trata de uma regressão tecnológica brutal, irei mudar esta minha opinião no dia em que, eu consiga ter uma arquitetura com um mesmo nível que possuo hoje com Adobe Flex + Swiz, como a descrevi neste post, quando este dia chegar (se é que vai) irei dizer que podemos então começar a pensar em utilizar o HTML+JS para soluções corporativas.

E vamos a luta, retornando ao velho mundo do HTML, por alguns chamados de revolucionário mundo do HTML5…

Outros materiais interessantes para ler: JavaScript Syntax / Advanced JavaScript / Javascript as a programming language / I'm Afraid of JavaScript / JavaScript MDN

Algumas vezes nossa aplicação em Adobe Flex/Flash esbarra no tal crossdomain.xml, que limita o acesso de uma aplicação da Adobe para o respectivo domínio, não possibilitando que sua aplicação no http://dominioA.dom acessar algo que está no http://dominioB.com, porque lá existe um crossdomain.xml que limita o acesso ao conteúdo apenas para as aplicações Adobe Flash/Flex para o seu respectivo domínio.
 
Nessa hora que entra o tal do proxy, que nada mais é que um meio de caminho para acessar o conteúdo…
 
Nesse post, refere-se a um script PHP que utilizei para conseguir acessar um XML em um domínio que não consegui acessar diretamente pela minha aplicação Flex, com isto o funcionamento ficou assim:

Aplicação Flex > Script PHP > Pega XML do outro dominio > retorna para minha Aplicação Flex

( Realizar a chamada desse Script PHP, utilizando o HttpService do Adobe Flex)

 
eis o script:

1
2
3
4
5
6
7
8
9

/*
	revisado por : Erko Bridee
	Fonte:
	http://cognitivecache.blogspot.com/2008/03/overcoming-cross-domain-issues-through.html
*/
$url = ($_POST['url']) ? $_POST['url'] : $_GET['url'];
header('Content-Type: text/xml');
$content = file_get_contents($url);
echo $content;

 
e no Flex definir a URL do HttpService como o modelo abaixo:

1

httpService.url = "http://seu_dominio/xml_proxy.php?url=" + {URL_XML};

Feito isso, você conseguirá acessar algo no outro domínio, sem esbarrar no tal crossdomain =]

Estive olhando na internet um meio de esconder aquela imagem do sorrizo, que é adicionado quando se utiliza o plugin Stats do WordPress.
 
Plugin Stats : para estatísticas relacionadas ao blog. Para utilizar este plugin é necessário/obrigatório ter uma conta no WordPress.com, para ter acesso a API Key. O uso desse plugin por padrão adiciona uma imagem de um sorrizo no final da sua página.
 
Como remover?
 
Pelo que andei lendo na internet a maioria das sugestões está em adicionar um CSS para movimentar a posição da imagem para um local fora da área de visualização, porém todos os exemplos indicam a inclusão desse na página.
 
Então pensei, se eu editar o meu tema atual, quando eu mudar de tema terei o retrabalho de implementar essa chamada do CSS no novo tema.. pensando nisso, resolvi fazer umas modificações diretamente no plugin Stats:
1 – criei um stats.css
2 – adicionei alguns códigos a mais no stats.php
 

stats.css

1
2
3
4
5
6
7
8
9
10
11

/*
Por: Erko Bridee
data: 23/02/2009
 
escondendo o sorrizo do plugin Stats do Wordpress
*/
#wpstats { 
	position:absolute; 
	top:-5000px; 
	left:-5000px; 
}

Editando o stats.php

 
1 – Criar as function acima da function stats_footer()

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

/* 
Erko 23/02/2009 
BEGIN
*/
function getStatsPluginUrl() {
	$path = dirname(__FILE__);
	$path = str_replace("\\","/",$path);
	$path = trailingslashit(get_bloginfo('wpurl')) . trailingslashit(substr($path,strpos($path,"wp-content/")));
	return $path;
}
 
function insert_css() {
	return '<link href="'.getStatsPluginUrl().'stats.css" rel="stylesheet" type="text/css" />';
}
 
function stats_header() {
	echo '<!-- Por: Erko Bridee | Esconde o smile do Stats plugin | 23/02/2009 -->'."\n";
	echo insert_css();
}
/* 
END
Erko 23/02/2009 
*/

 
2 – Agora registrar a ação para adicionar isto no cabeçalho.
 
Para isso localize o código, que fica no final do stats.php:

1

add_action( 'wp_footer', 'stats_footer', 101 );

 
Adicione o respectivo código, antes do código que foi solicitado para localizar no final do arquivo stats.php:

1
2

// Erko 23/02/2009 - adicionando estilo no cabeçalho
add_action( 'wp_head', 'stats_header' );

 
Pronto, feito isso, basta atualizar o seu plugin no servidor que o sorrizo some.

Opa pessoal,

uma novidade para quem acessa ao blog, implementei um suporte para gerar um link, que possibilita chamar o serviço de tradução de URL do Google Translator, que pode ser utilizado através das bandeiras que estão disponibilizadas ali no canto superior direito, do lado do ícone do Feed RSS.

Problema encontrado:

- No Firefox 2.x, quando o blog foi traduzido, apareceu um quadro branco em cima da página traduzida, ou seja quem estiver usando ainda o Firefox 2.x, terá esse problema.

Onde funcionou?

- Firefox 3.x

- Internet Explorer 7

( isso no teste que fiz usando Windows Vista)

- Testei tambem no Ubunto Linux 8.04, com Firefox 3 Beta

Espero que gostem

Quem tiver interesse no plugin que desenvolvi deixe um comentário.

Mais a frente pretendo escrever um post descrevendo o componente e como utilizar, assim como disponibilizar um link para download.

Vamos ao tradicional Hello World, testar o plugin wp-codebox que vou utilizar para publicar códigos aqui no blog

1
2
3

<?php
	echo "Hello World!\\n";
?>

Parece legal esse plugin. O que você acha?