Ate que todos os commits sejam aceitos no repositorio oficial, o que podem executar para ter o ambiente configurado é o seguinte:

git submodule add -b rails3 git://github.com/dcrec1/blue-ridge.git ./vendor/plugins/blue-ridge
rails g blue_ridge:skeleton
rails g blue_ridge:javascript_spec core
rake spec:javascripts

Caso não conheçam o Blue-Ridge, o Dr. Nic publicou faz um tempo um post onde explica a ferramenta e onde também publicou o video de uma palestra que ele deu no Rails Underground 2009.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

• Vem ai Sproutcore
• Conheça o SproutCore, o matador de Flash e de Silverlight da Apple
• Fundador do SproutCore comenta tecnologia, seu funcionamento e MobileMe
• SproutCore, Cocoa para a web
• Apple lança SproutCore para concorrer com Flash e Silverlight

pelo que agora é a vez de brincar um pouco.

O primeiro passo para trabalhar com o SproutCore é baixar ele e conseguimos aquilo executando o seguinte comando no terminal (RubyGems deve estar corretamente instalado):

sudo gem install sproutcore

Ao executar o comando anteriormente mencionado o terminal ira mostrar o que esta sendo realizado. No meu caso, entra outras mensagens apareceram as seguintes:

Successfully installed merb-core-0.9.3
Successfully installed erubis-2.6.2

Ao ver aquilo me perguntei: Merb? O que tem a ver?

Pesquisei um pouco e parece que o Sproutcore é baseado no Merb, o que me diz que deve ser bem dinâmico e compatível com plugins. Podem ler uma breve descrição sobre o Merb aqui.

Sobre o Erubis, ele é uma implementação do eRuby, um sistema de templates para Ruby similar ao Freemarker do Java. A teoria é que o SproutCore utiliza o Erubis nas views, o que é bom porque é um tecnologia já conhecida, o que facilita as coisas.

Agora que temos o SproutCore instalado vamos criar um projeto. O projeto que vou criar se chamara sproutcore-demo. A sintaxe para a criação é similar a do Rails, somente muda o nome do comando:

sproutcore sproutcore_demo

O output, entre outras coisas, me disse que posso inicializar o sc-server e entrar na minha aplicação no browser. O sc-server parece ser um servidor que vem embutido com o SproutCore, algo similar ao WEBRick que vem com o Rails. Inicializei o sc-server executando dentro da pasta sproutcore-demo recém criada o comando:

sc-server

Algo que me chamo a atenção no output do ultimo comando foi a seguinte linha:

~Using Mongrel adapter

Que legal, parece que o SproutCore mantem o foco em fazer coisas novas e não em reinventar a roda. Por tal motivo tudo indica que ele inclui o Mongrel como servidor padrão em vez de criar um novo.

Acessei http://localhost:4020/sproutcore_demo e apareceu uma tela idêntica a essa.

Agora, tal como o post-it sugere, vamos preencher um pouco nossa aplicação com um model, um controller e uma view.

Começaremos criando um controller com o seguinte comando:

sc-gen controller sproutcore_demo/app

A execução do comando ira ter criado dois arquivos: clients/sproutcore_demo/controllers/app.js e o respetivo teste clients/sproutcore_demo/tests/app.rhtml. No meu caso o valor do cliente foi igual ao do nome do projeto, quer dizer: sproutcore_demo .

Mas o que são esses clientes? Cada cliente é uma especie de aplicação, pelo que podemos ter varias aplicações para um único serviço SproutCore ao contrario de criar um serviço para cada aplicação que queiramos ter.

No nosso novo controller temos o seguinte codigo:

SproutcoreDemo.appController = SC.Object.create({}) ;

Sabemos que em JavaScript as chaves ({}) definem um objeto e o método create utiliza o que foi passado como parâmetro para criar um objeto que herda dele mesmo. Vamos mexer um pouco nesse objeto e criar um atributo e um método, deixando o código algo assim:

SproutcoreDemo.appController = SC.Object.create({
	cor: "Branco",
	trocarCor: function() {
		var novaCor = (this.cor == "Branco") ? "Preto" : "Branco";
		this.set("cor", novaCor);
	}
});

Criei um método que muda o valor do atributo para poder testar um tal binding do SproutCore que não sei bem como funciona mas agora vamos descobrir.

Continuaremos editando uma view, o arquivo clients/sproutcore_demo/english.lproj/body.rhtml. Mas espera ai, o que é esse english.lproj? Ah ta, o SproutCore suporta localização (somar um ponto) e na teoria um poderia colocar pastas para cada idioma. A localização no SproutCore é algo que tenho que testar proximamente, mas agora editarei o ultimo arquivo mencionado e substituirei o conteúdo da div.sc-welcome com:

<%= label_view :labelId,
  :tag => ‘h1′,
  :bind => { :value => ‘SproutcoreDemo.appController.cor’ } %>
<%= button_view :buttonId,
  :title => ‘Trocar cor’,
  :action => ‘SproutcoreDemo.appController.trocarCor’ %>

O código é um pouco auto-explicável mas o que é aquele bind e por que trocamos o valor do atributo cor chamando o método set e não com uma simples atribuição?

SC.Object é uma classe que herda de SC.Observable, a classe que declara o método set. O método set alem de trocar o valor do atributo passado como parâmetro se encarrega de outras coisas como responder aos observadores do mesmo. Com o atributo bind do helper button_view (que herda de view como todos os demais helpers) estamos indicado que o atributo indicado como chave esta observando ao atributo indicado como valor, que no nosso caso seriam value e SproutcoreDemo.appController.cor respetivamente.

Uma referencia sobre os diferentes view helpers do SproutCore pode ser encontrada aqui.

Se acessarmos http://localhost:4020/sproutcore_demo deve aparecer a palavra Branco e um botão com o texto Trocar Cor que ao ser acionado devera alternar a primeira palavra entre Branco e Preto.

Agora que conhecemos bem melhor como o SproutCore funciona vamos criar algo mas complexo. Primeiro criaremos um model onde guardaremos a cor ativa (Branco ou Preto). No controller criaremos uma função que troque a cor e um observer que contara quantas vezes a cor mudo. Na view teremos o botão que chama a função para trocar a cor e uma barra de progresso que ira aumentando cada vez que a cor mudar (o valor de ela ira ter um bind com o numero de vezes que a cor mudou).

Continuamos agora criando um model:

sc-gen model sproutcore-demo/carro

O comando anterior devera ter criado três arquivos: clients/sproutcore_demo/models/carro.js, clients/sproutcore_demo/fixtures/carro.js e para que não exista nenhum motivo para não criar testes, clients/sproutcore_demo/tests/models/carro.rhtml.

Antes de continuar, o que é esse fixture?

O fixture é um código que é executado quando a aplicação é carregada e tem como finalidade criar registros iniciais. Mas por que é executado esse código quando a aplicação carrega? O arquivo clients/sproutcore_demo/main.js é um script que é carregado por padrão quando o servidor é inicializado e se nos dirigirmos a ele vamos nos encontrar com a seguinte linha:

SproutcoreDemo.server.preload(SproutcoreDemo.FIXTURES);

A seguinte linha, tal e como parece, indica que os fixtures devem ser carregados. Se apagarmos o comentarmos essa linha, os fixtures vão deixar de ser executados (:

Como eu quero que minha aplicação conte sempre com os dois últimos carros que comprei :P, vou adicionar o seguinte código no fixture carro.js:

require('core') ;
SproutcoreDemo.FIXTURES = SproutcoreDemo.FIXTURES.concat([
	{
		guid: 1,
		type: 'Carro',
		cor: 'Branco',
		fabricante: 'Porsche'
	},
	{
		guid: 2,
		type: 'Carro',
		cor: 'Amarelo',
		fabricante: 'Ferrari'
	}
]);

guid e type são atributos necessários e o guid deve ser único.

Já devem estar se perguntando por que indiquei como type Carro e não SproutcoreDemo.Carro. Resulta que nossa aplicação conta com um script clients/sproutcore_demo/core.js que define um namespace padrão para ser utilizado nos registros:

server: SC.Server.create({ prefix: ['SproutcoreDemo'] }),

Podem ter notado se escolheram um nome de projeto com - que em alguns casos o nome do namespace gerado foi SproutcoreDemo e em outros Sproutcore-demo, que é um nome invalido para um objeto em JavaScript. Isso parece ser um erro no SproutCore e de ser assim é uma boa ocasião para por teu nome na lista de commiters do projeto.

Voltando no código, o controller criado anteriormente ficara agora assim:

SproutcoreDemo.appController = SC.Object.create({
	cor: null,
	numeroDeMudancasDeCor: 0,
	observadorDeCor: function() {
		this.set("numeroDeMudancasDeCor", ++this.numeroDeMudancasDeCor);
	}.observes('cor'),
	trocarCor: function() {
		var novaCor;
		if (!this.cor) {
			novaCor = SproutcoreDemo.Carro.find(1).get("cor");
		} else {
			novaCor = (this.cor == "Branco") ? "Preto" : "Branco";
		}
		this.set("cor", novaCor);
	}
});

Eu sei que a estrutura do código no é das melhores mas é somente um exemplo para testar o framework.

A função trocarCor, como já sabemos e como o mesmo nome diz, terá como objetivo trocar o valor de cor. A diferença é que agora a cor sera pega pela primeira vez do carro com guid igual a 1.

Pegamos a cor do carro chamando o método get e não diretamente para que assim o framework possa trabalhar com os observadores e os binds e também porque Carro.cor não existe :D, o SproutCore cria uma estrutura interna que ainda não analisei.

Na função observadorDeCor temos algo novo. Ela chama o método observes e passa como parâmetro cor, indicando que queremos que seja chamada cada vez que o atributo passado como parâmetro mudar.

Antes de explicar o fluxo completo do procedimento, vamos modificar nossa view, o arquivo clients/sproutcore_demo/english.lproj/body.rhtml:

<% content_for('body') do %>

  <%= label_view :labelId,
    :tag => ‘h1′,
    :bind => { :value => ‘SproutcoreDemo.appController.cor’ } %>
  <%= button_view :buttonId,
    :title => ‘Trocar cor’,
    :action => ‘SproutcoreDemo.appController.trocarCor’ %>

  <%= progress_view :progressId,
    :minimum => 0,
    :maximum => 100,
    :bind => { :value => ‘SproutcoreDemo.appController.numeroDeMudancasDeCor’} %>


<% end %>

Os dois primeiros helpers já conhecemos, mas o terceiro é novo; mesmo assim não é dificil descubrir o que ele faz. O helper progress_view cria uma barra de progresso, que no nosso caso vai de zero a cem. O valor da barra de progresso terá um bind com o numero de mudanças da cor, pelo que cada vez que troquemos o valor de cor a barrinha devera ir se prenchendo.

Se tentarem acessar agora a view não vão a ver a barrinha porque ela precisa ter certos estilos, eu utilizei os seguintes (eles podem ser escritos no arquivo body.css):

.progress {
  width: 100px;
  height: 10px;
  border: thin solid #AAAAAA;
}

.progress .inner {
  width: 0px;
  height: 10px;
  background-color: #AAAAAA;
}

Agora sim o funcionamento da nossa aplicação:

Ao entrar na tela, não ira aparecer nenhum valor para cor porque não foi setado algum no controller. Ao acionar o botão Trocar Cor pela primeira vez, o controller ira procurar o carro com guid 1 e pegar o cor dele; futuramente ira alternar entre Branco e Preto. Agora o mais legal, cada vez que o valor de cor mudar, a função observadorDeCor sera chamada e ela ira aumentar em uma unidade o valor de numeroDeMudancasDeCor, o que ocasionara que a barra de progresso aumente.

O que chama muito a atenção e que os atributos não sabem quem os estão observando, somente o framework. Nosso controller não se preocupa com sair distribuindo dados, nem se importa com saber para onde aqueles dados vão, deixamos isso para o framework. Os negócios são assim agora, é somente ver os RSS, notificações por email, etc…

Isso foi tudo e desculpem se no final os erros de ortografia aumentar, o corretor ortográfico do Firefox parece que deixa de funcionar direito quando o texto começa a ficar longo

Ate a próxima!

O que é Bouncy Castle?

Depois de acessar a página do Bouncy Castle, a definição no Wikipedia e a definição no Java Glossary me atrevo a dizer que Bounce Castle é uma API de criptografia para Java e também um provedor das especificações JCE e JCA da Sun.

Algo curioso sobre Bouncy Castle é que por ser um projeto australiano ele não precisa cumprir as leis de Estados Unidos que proíbem a exportação de algoritmos fortes de criptografia. Mais informação aqui.

O que é RSA?

De acordo com a Wikipedia, RSA é

um algoritmo de encriptação de dados, (…) até à data (2008), a mais bem sucedida implementação de sistemas de chaves assimétricas, e fundamenta-se em Teorias Clássicas dos Números. É considerado dos mais seguros, já que mandou por terra todas as tentativas de quebrá-lo. Foi também o primeiro algoritmo a possibilitar encriptação e assinatura digital, e uma das grandes inovações em criptografia de chave pública.

RSA é um algoritmo que cria duas chaves, uma delas sendo pública e a outra privada. Toda mensagem que for cifrada utilizando a chave pública somente vai poder ser decifrada utilizando a chave privada.

Trabalhando com RSA

Vamos por as mãos na massa e brincar um pouco. Construiremos uma aplicação web simples que utilizando RSA crie uma chave privada e mande uma pública ao cliente. A aplicação servidor depois ira decifrar mensagens que foram cifradas com a chave publica. Para cifrar a chave pública na aplicação cliente utilizaremos a biblioetaca jsbn, dos estudandes de Stanford, implementada em JavaScript.

Começarei criando uma aplicação web dinâmica no Eclipse que rodara sobre o Tomcat e adicionarei ao meu pacote uma classe serviço que fará as operações relacionadas com Bouncy Castle e RSA e uma servlet que delegara as chamadas HTTP para o serviço correspondente.

Vou começar a implementar o serviço de RSA que utilizara Bouncy Castle como implementação, pelo que terei que incluir a livraria correspondente no meu classpath. As livrarias podem ser descarregadas de aqui. Nesse caso somente precisaremos da livraria Provider e OpenPGP/BCPG.

O primeiro passo ao trabalhar com Bouncy Castle é adicionar o provedor Bouncy Castle à lista de provedores. Colocarei o seguinte código no construtor da minha classe serviço:

Security.addProvider(new BouncyCastleProvider());

Agora vou criar um gerador de chaves pares para o algoritmo RSA utilizando como provedor o Bouncy Castle (BC) e depois inicializar ele especificando que o tamanho das chaves vai ser 1024 e que o provedor de números aleatórios vai ser SecureRandom, do pacote java.security. Essas operações irão estar num método chamado generateKeys que terminara devolvendo um par de chaves. O método fica assim:

public KeyPair generateKeys() throws Exception {
	KeyPairGenerator keyGenerator = KeyPairGenerator.getInstance("RSA",
			"BC");
	keyGenerator.initialize(1024, new SecureRandom());
	return keyGenerator.generateKeyPair();
}

O segundo método da classe serviço recebera uma mensagem cifrada junto com a chave privada correspondente à chave pública utilizada para cifrar a mensagem e retornara a mensagem decifrada.

O primeiro passo é pegar uma instância da classe Cipher. A classe Cipher é encarregada de cifrar e de decifrar arrays de bytes. Para pegar uma instância da classe Cipher chamamos o método estático getInstance da mesma. Ela recebe dois parâmetros: a transformação a ser utilizada e o provedor. Já sabemos que o provedor é Bouncy Castle, mas o que é a transformação?

A transformação é o método que foi utilizado para cifrar nossa mensagem. No nosso caso a transformação é RSA/NONE/PKCS1Padding, que define que utilizamos RSA como algoritmo de criptografia, que não utilizamos nenhuma técnica especial para cifragem em bloco e que utilizamos PKCS #1 como técnica de enchimento. Escolhi essa transformação porque é compatível com a livraria JavaScript utilizada.

Talvez agora surgiram mais dúvidas. Técnica para cifragem em bloco? Técnica de enchimento?

Quando ciframos um texto utilizando RSA, partimos ele em vários blocos e cada bloco vai sendo cifrado de alguma maneira. Como os blocos se relacionam e o tamanho deles, entre outras coisas, são características que definem as diferentes técnicas de cifragem em bloco. Para aprender mais podem acessar a definição no site da Wikipedia.

Agora imaginemos que nossos blocos devem ser de 10 bytes mas ao particionar nossa mensagem o último bloco ficou de 4 bytes. Nesse caso temos que fazer alguma operação para completar esses 6 bytes restantes. Essa operação e chamada de padding e existem varias técnicas. Mas detalhes podem ser obtidos novamente na definição no site da Wikipedia.

Uma vez com nossa instância da classe Cipher nosso seguinte passo é inicializar ele indicando que vamos a realizar um processo de descriptografia utilizando tal chave privada. Finalmente realizamos o processo chamando o método doFinal do cipher passando como parámetro os bytes da mensagem criptograda. O método doFinal ira retornar os bytes da mensagem decifrada, os quais utilizaremos para criar uma string e devolver ela como retorno do método, o qual fica assim:

public String decrypt(PrivateKey key, byte[] message) throws Exception {
	Cipher decrypt = Cipher.getInstance("RSA/NONE/PKCS1Padding", "BC");
	decrypt.init(Cipher.DECRYPT_MODE, key);
	return new String(decrypt.doFinal(message));
}

Começarei agora a desenvolver a classe que atuara como servlet. A classe servlet ira ter duas funções. A primeira função e mandar o serviço criar um par de chaves, guardar a chave privada na sessão e mandar os dados necessários da chave pública para o cliente (modulus e exponente). A segunda função é receber um texto em formato hexadecimal, passar ele para uma seqüencia de bytes e chamar o método do serviço encarregado de decifrar a cadeia de bytes. Finalmente devolvera a mensagem decifrada para o usuário.

Como o código da servlet é Java de todos os dias, não tem muito para explicar. Segue o código dos dois métodos encarregados de realizar as operações:

private void decrypt(HttpServletRequest request,
		HttpServletResponse response) throws Exception {
	KeyPair keys = (KeyPair) request.getSession().getAttribute("keyPair");
	PrivateKey privateKey = keys.getPrivate();
	RSAService service = new RSAService();
	byte[] bytes = Hexadecimal.parseSeq(request.getParameter("Decrypt"));
	String decrypted = service.decrypt(privateKey, bytes);
	response.getWriter().write(decrypted);
}

private void getPublicKey(HttpServletRequest request,
		HttpServletResponse response) throws Exception {
	RSAService service = new RSAService();
	KeyPair keys = service.generateKeys();
	request.getSession().setAttribute("keyPair", keys);
	RSAPublicKey publicKey = (RSAPublicKey) keys.getPublic();
	String modulus = publicKey.getModulus().toString(16);
	String exponent = publicKey.getPublicExponent().toString(16);
	PrintWriter writer = response.getWriter();
	writer.append("{'modulus':'");
	writer.append(modulus);
	writer.append("','exponent':'");
	writer.append(exponent);
	writer.append("'}");
	writer.flush();
}

O código cliente é bem simples. Quando a página carregar, a página ira solicitar ao servidor o modulus e o exponente da chave pública. Quando o usuário acionar um botão escolhido, ira ser chamada a função sendMessage. A função sendMessage ira instanciar um objeto do tipo RSAKey que sera o encarregado de cifrar o texto escrito no devido textbox. Apos instanciar um objecto do tipo RSAKey, a função sendMessage especificara o modulus e o exponente da chave pública e logo cifrara a mensagem. Finalmente a função enviara ela pro servidor e mostrara uma alerta com a resposta. Nosso código em JavaScript fica assim:

$(document).ready(function() {
	$.getJSON("do?GetPublicKey", function(key) {
		$("#exponent").val(key.exponent);
		$("#modulus").val(key.modulus);
	})
});

function sendMessage() {
	var rsa = new RSAKey();
	rsa.setPublic($("#modulus").val(), $("#exponent").val());
	var message = rsa.encrypt($("#text").val());
	$("#encrypted").html(message);
	$.get("do?Decrypt=" + message, function(data) {
		window.alert(data);
	})
}

O código da aplicação, incluíndo o jQuery, a classe Hexadecimal pegada da Internet, a biblioteca jsbn e o web.xml pode ser descarregado de aqui. Não esquecer que devem ser descarregadas ainda as bibliotecas do Bouncy Castle referentes a versão da JVM.

Se tiver dito alguma bobagem, por favor me perdoem e me corrijam nos comentários ou por email.

Ate a próxima!

Fiquei muito interessado e surpreso com o servidor e como não achei nenhuma aplicação de teste decidi baixar o servidor e experimentar um pouco, ver como eram renderizadas as paginas e se o processo era rápido ou não.

O primeiro passo foi descarregar o servidor desse link. Gostaria de poder ter testado ele em Linux mas ainda não esta disponível. O servidor ja vem com o servidor de Apache embutido e pesa 14 Mb.

A instalação e muito simples, basta com descomprimir o arquivo zip e para iniciar o servidor somente teve que executar o arquivo
StartServers.bat . Nesse momento é aberta uma janela de console e são criados 5 processos: dois httpd.exe, três Jaxer.exe e um JaxerManager.exe . Não sei por que existem dos processos httpd.exe e três Jaxer.exe, é algo que terei que pesquisar.

Ao entrar no endereço http://localhost:8081/aptana/ é apresentada uma página com informação sobre o servidor e alguns links. Um dos links era chamado Samples and Tools e como eu queria fazer uns testes, nada melhor que seguir ele. O link abriu umas paginas com as mesmas aplicações de demonstração que se encontram aqui.

Habilitei o FireBug e comecei a navegar pelas aplicações, analisando algumas coisas. Uma coisa que percebi era que em toda pagina eram inseridos dois trechos de código em JavaScript que não estavam na fonte original. Procurei e consegui achar um deles, o qual vem de um arquivo chamado clientFramework_compressed.js . Como o nome diz, o codigo esta compactado e não da para entender muita coisa, mas felizmente a fonte limpa se encontra na mesma pasta chamada framework.

Continuei comparando os códigos originais das aplicações com os resultantes e pode apreciar que efetivamente os scripts que rodam no servidor não são mandados pro cliente. Mas que acontece no caso em que uma função local precise chamar uma função a ser executada no servidor? Nesse caso temos que assinar o valor true ao atributo proxy da nossa função a ser executada remotamente. Parece que quando o Jaxer percebe que existe uma função no cliente que tem que se comunicar com uma no servidor ele envia duas funções pro cliente chamadas xpto() e xptoAsync(), supondo que nossa função original se chame xpto. Desse modo, se temos uma seguinte script a ser rodado no servidor:

function save(contents)
{
	contents = contents.replace(/\r\n/g, "\n");
	contents = contents.replace(/\r/g, "\n");
	checkValid(contents);
	Jaxer.File.write(getFilePath(), contents);
}
save.proxy = true;

no cliente ira chegar o seguinte:

function save() {return Jaxer.remote("save", arguments);}
function saveAsync(callback) {return Jaxer.remote("save", arguments, callback);}

Os scripts a serem executados em ambas camadas (runat=”both”) são enviados intactos para o cliente. E importante mencionar que em todos os casos o atributo runat e retirado da tag script, assim que parece que não tem jeito de saber se o script pode ser executado também no servidor ou não.

Antes que esqueça, quando analisei os arquivos fontes abri eles no Aptana Studio e algo que achei legal foi que ele pinta o fundo do script dependendo do atributo runat. Se o valor do atributo runat for server então o Aptana pinta o fundo de uma cor azul, caso for both ele pinta o fundo de uma cor meia laranja.

Realizei uns quantos eventos que precisavam fazer chamadas ao servidor e analise no console do FireBug as petições. Em todas elas era enviada ao servidor informação do seguinte tipo pelo método post:

id	               -1705679199
methodName	proxyLog
params	           ["warn","a proxied 'warn' log statement"]
uid	             1201567523859_501925

O id nunca mudava numa mesma aplicação. Pode ser o id do cliente, da aplicação ou da função, é algo que ainda tenho que descobrir. O methodName é o nome da função a ser executada no servidor, params contém os parâmetros exigidos pela função e uid é um valor que também não sei o que representa mas sempre foi mudando em cada solicitação.

Uma outra coisa interessante do Jaxer é que ele pode ser integrado facilmente com MySQL. Dentro da pasta raiz do Jaxer temos uma pasta chamada local_jaxer e dentro dela outra chamada conf, onde existem três arquivos: config.js, configLog.js e configRoutes.js . No primeiro arquivo podemos configurar a integração com o MySQL especificando usuario, host, porta, senha e base a ser utilizada, assim como outras opções do servidor. No segundo arquivo podemos configurar como queremos que o log trabalhe e no ultimo as regras para redirecionamento das paginas. Podemos por exemplo configurar para que ao cliente se dirigir no link xxx.host/yyy ele seja redirecionado para a aplicação yyy dentro da pasta xxx.

Por aqui termina meu primeiro contato com o Jaxer, espero que no futuro possa ter experiências e analises mais profundos desta ferramenta que como mencionei anteriormente, chama muito minha atenção.

Também nesses últimos dias chegamos a conhecer alguns projetos interessantes como o JoSQL que nos permite executar código SQL para selecionar coleções de objetos, similar ao LINQ da plataforma .NET e o JsonSQL que funciona similar mas para objetos em JavaScript, notação Json. Outros trabalhos interessante são os feitos na livraria Highslide JS que nos ajuda a simular o efeito do conhecido lightbox nas nossas aplicações, o Crap4j que se encarrega de qualificar nosso código Java em função a diferentes métricas, o AjaxSwing, que magicamente converte nossos projetos em Swing para aplicações web Ajax, o CajuScript, uma simples e poderosa implementação de script para usar com Java feito no território nacional, o Mibbit, um chat que trabalha com o protocolo IRC e desenvolvido com Ajax e finalmente o Jiggy, que nos permite criar aplicações para o iPhone de maneira muito simples e fácil.

Algumas leituras interessantes sobre Java e Design Patterns foram selecionadas também. Uma de elas é a conversação que se deu no forum GUJ chamada Então você gostaria de saber sobre AOP? que trata sobre a programação orientada a aspectos ou as que encontramos no site Core J2EE Patterns, com muita informação sobre os diferentes design patterns da especificação J2EE. Outro site interessante é Domain Driven Design, com muita informação sobre o tema que leva o mesmo nome.

Alguns tutoriais e artigos técnicos interessantes que chamaram nossa atenção foram aqueles chamados Autotestando JavaScript em Rails, de Dr. Nic, que explica como testar nossos scripts em JavaScript desde um script em Rails, Clousures do JavaScript para Dummies, de Morris Johns, que ensina de maneira muito clara como funcionam os poderosos clousures em JavaScript, um excelente tutorial sobre Ruby escrito por Eustaquio Rangel no seu periodo de aprendizagem da linguagem e Ultimo tutorial JAAS para comunicação com a base de dados que partiu de uma duvida no forum do JBoss sobre como implementar a especificação de seguridade e autenticação JAAS utilizando a base de dados num servidor de aplicação JBoss.

Também relacionado com JBoss, seguridade e autenticação são os wiki SecureJBoss que é uma fonte de conhecimento compartilhada sobre como configurar o JBoss para máxima seguridade e a definicação na Wikipedia de Single sign-on (SSO) que consiste em criar um único sistema de autenticação para diferentes aplicações.

O software livre não ficou atrás e assim chegamos a conhecer o WinLibre, um portal com muito software livre para o sistema operativo Windows. Os que deixaram Windows atrás ficaram contentes ao ver o post chamado 10 sites oferecendo cursos de Linux online de graça, do blog italiano Vagabondo Digitale, que recompilo alguns sites como o da IBM ou da Novell com excelentes cursos. Para os que gostam de especialmente Ubuntu, foi interessante conhecer a revista Full Circle Magazine que trata sobre tudo o relacionado com o sistema operativo Ubuntu e também o programa Ubuntu Tweak, que oferece muitas opções para alterar o mesmo. Muita gente pode estar querendo instalar o Java 6 no Ubuntu para treinar para alguma prova e o processo fica muito fácil depois de ler o artigo do Mundo Hev chamado Instalando Java 6 (1.6) no Ubuntu. Uma vez o Java corretamente instalado, a pagina sobre as certificações Java no portal JavaRanch pode nos ajudar bastante.

Voltando aos browsers, foi muito legal ver a aplicação de demonstração de SVG criada por Amaltas, o release 1.2.2 do jQuery, a comparação dos diferentes CSS Selectors em torno a velocidade realizada pelo pessoal do Ext JS e também a enorme quantidade (perto de 1000) de exemplos sobre Ajax, JavaScript e Dhtml que encontramos no site AjaxRain.

Finalmente, outros dois links interessantes foram o do Overview sobre Eclipse RAP e o Screencast de demostração criado por Michael Coté e o artigo escrito por Daniel Tenner chamado Como reconhecer um bom programador.

A operação de selecionar todos consistia em fazer um loop das options do select e marcar cada uma como “selected = true”. Tentando optimizar o processo um dos desenvolvedores lembro das épocas em que mexia com VB e sugeriu ocultar o select, fazer o loop e depois mostrar o select de novo. O resultado foi impressionante, o processo foi umas 20x mais rápido!

Segue o script e uma prova do mencionado. A função selectAll1() implementa o procedimento utilizado em primeira instância. Já a função selectAll2() implementa também o hack de ocultar a combo antes de fazer a operação. Nas duas funções e logado o tempo que demorou a operação.

function selectAll1() {
	var date = new Date();
	var options = document.getElementById("select").options;
	var optionsLength = options.length;
	for (var i = 0; i < optionsLength; i++) {
		options[i].selected = true;
	}
	log(1, new Date() - date);
}

function selectAll2() {
	var date = new Date();
	var select = document.getElementById("select");
	select.style.display = "none";
	var options = select.options;
	var optionsLength = options.length;
	for (var i = 0; i < optionsLength; i++) {
		options[i].selected = true;
	}
	select.style.display = "";
	log(2, new Date() - date);
}

function log(i, ms) {
	document.getElementById("console").innerHTML += "selectAll" + i +
			" : " + ms + "ms“;
}

No IE a função selectAll1 demorou em média 700ms, a diferença da função selectAll2 que foi executada em somente 30 segundos na média. No Firefox os resultados das duas funções não foram tão distantes. Demoraram em média 150ms e 140ms respectivamente.

(…) o tipo de protocolo para chamada remota de procedimentos em qualquer lugar da rede ou uma chamada de função para o método de transferência de controle de parte de um processo para outra, permite a divisão de um software em várias partes, (…)

Em outras palavras, com o protocolo RPC podemos ter em distintas maquinas objetos com métodos que ao ser chamados vão ser executados num lugar remoto.

Quando trabalhamos com aplicações web, normalmente temos funções e métodos em JavaScript. Podemos querer executar aqueles métodos e funções no servidor por vários motivos, como por exemplo porque são muito custosos e no browser a execução vai ficar muito lenta, porque precisam de uma lógica de negocio e não queremos expor nossa lógica ao cliente ou porque o método ou função precisa de acesso a recursos que o browser não pode oferecer diretamente.

A solução mais comum seria implementar as funções para que quando sejam chamadas, elas se comuniquem com o servidor mediante Ajax e consigam o resultado. Teríamos algo assim:

function x() {
    /* Ajax para chamar x no servidor */
}

function y() {
    /* Ajax para chamar y no servidor */
}

Rapidamente podemos perceber de vários problemas com esta solução. Primeiramente, o código fica muito repetitivo e muito sujeito a erros. Segundamente, precisamos definir uma função local para cada função remota que a gente tiver. Terceiramente, não tem como a gente saber se a função local que a gente esta chamando esta implementada no servidor ou não.

Felizmente com dojo.rpc podemos criar uma solução mais flexível e segura. dojo.rpc.JsonService é uma classe local que representa uma classe remota. O construtor de JsonService recebe uma definição da classe remota e a partir dela ira criar os diferentes métodos.

Struts 2 JSON é um plugin para o Struts que converte o resultado de uma Action em Struts em formato JSON. O resultado de uma Action que devolve um objeto com propriedades chamadas doubleValue do tipo Double, nestedBean do tipo Object, list do tipo List e array do tipo Array ficaria assim:

{
   "doubleValue": 10.10,
   "nestedBean": {
      "name": "Mr Bean"
   },
   "list": ["A", 10, 20.20, {
      "firstName": "El Zorro"
   }],
   "array": [10, 20]
}

O mais legal do Struts 2 JSON é que ele foi feito pensando no dojo.rpc e cria uma url com a definição das nossas classes configuradas para trabalhar com ele, de modo que possam ser interpretadas pelo construtor de JsonService.

Vou aproveitar o projeto web criado aqui para implementar uma classe no servidor que possa ser representada no cliente, uma solução RPC.

O primeiro passo é descarregar o plugin e colocar ele na pasta WebContent/WEB-INF/lib . A versão 0.19 do plugin pode ser baixada de aqui.

Seguidamente devemos criar nossa Action. Não sempre todos os métodos da nossa Action precisam estar também no cliente, pelo que colocamos a anotação @SMDMethod nos que efetivamente precisam. SMD é a abreviatura de Simple Method Definition, que seria nossa definição da classe remota. Nossa Action fica assim:

package com.mouseoverstudio.action;

import com.googlecode.jsonplugin.annotations.SMDMethod;
import com.opensymphony.xwork2.Action;

public class TesteStruts2JSON {

	public String execute() {
		return Action.SUCCESS;
	}

	@SMDMethod
	public String getStringResult() {
		String result = new String("MouseOver Studio");
		return result;
	}

	@SMDMethod
	public Integer getIntegerResult(String i) {
		Integer result = new Integer(i);
		return result;
	}
}

Vamos mapear agora nossa nova Action. Para isso, adicionamos no arquivo struts.xml o seguinte código:


<package name="struts2json" extends="json-default">
<action name="TesteRPC"
class="com.mouseoverstudio.action.TesteStruts2JSON">
<interceptor -ref name="json">
<param name="enableSMD">true</param>
</interceptor>
<result type="json">
<param name="enableSMD">true</param>
</result>
</action>
</package>


A parte do servidor ja esta feita. Vamo agora trabalhar no cliente. Precisamos da livraria de JavaScript Dojo. Podem baixar ela de aqui. Vamos criar uma página que crie uma instância da nossa classe definida no Action e execute os dois métodos dela. Seguidamente vamos utilizar o Firebug para validar a resposta do servidor.


<%@ taglib prefix="s" uri="/struts-tags" %>
<html>
<head>
<script type="text/javascript" src="./dojo-1.x/dojo/dojo.js"
djConfig="isDebug:true"></script>
<s :url id="url" action="TesteRPC" />
<script type="text/javascript">
dojo.require("dojo.rpc.JsonService");
var service = new dojo.rpc.JsonService("${url}");
service.getStringResult().addCallback(console.log);
service.getIntegerResult("1337").addCallback(console.log);
</script>
</head>
<body></body>
</html>


No resultado podemos apreciar como o Struts 2 JSON cria uma definição da nossa Action e também como o resultado de nossos métodos e convertido para formato JSON.

Trabalhar com RPC utilizando dojo.rpc e Struts 2 JSON e um processo muito simples que facilita muito o desenvolvimento de aplicações web. Para mas informação, podem como sempre perguntar ou se desejar, se referir ao seguintes links:

http://cwiki.apache.org/S2PLUGINS/json-plugin.html

Dados 16 times, o programador deverá realizar os jogos entre cada 2 países/seleções com placar aleatório, eliminando os times perdedores. Depois, com os 8 vencedores restantes definir mais 4 vencedores, assim até a final e definição do campeão. Cada jogo deverá ser impresso na tela com o placar e os times adversários

O resultado final pode ser acessado aqui. O vencedor do desafio conseguiu implementar uma solução em somente 215 caracteres, utilizando Ruby. Minha solução teve 334 caracteres, me levando a conseguir a primeira posição na categoria JavaScript, que fico também detrás de Python e PHP. O código que eu apresentei (com comentários) foi o seguinte:

/*
w = texto final a ser exibido
r = função random
R = função de arredondamento
b = quebra de linha
q = 'length'
a = array de países
i = índice
f = gols pais1
c = gols pais2
*/
w = "", r = Math.random, R = parseInt, b = "\n", q = "length";
/*
string com países separados por vírgula => converter para array =>
ordenar aleatóriamente ( 0.5 - numero aleatório entre 0 e 1)
*/
a = "Itália,França,Alemanha,Portugal,Brasil,Argentina,Inglaterra,Ucrânia,Espanha
Holanda,Suíça,Suécia,Austrália,México,Uruguai,Gana"
.split(",").sort(
function() { return .5 - r() }
);
/* para nada, sempre que exista a[1] */
for ( {}; a[1];) {
/*
string com mensagens => converter para array => selecionar o correspondente de acordo a quantidade de países
dentro do array (16, 8, 4 ou 2) e aumentar a quebra de linha
*/
w += ",,F,,Semif,,,,Quartas de f,,,,,,,,Oitavas de f"
.split(",")[a[q]] + "inal:" + b;
/* para i = 0, sempre que exista a[i] */
for (i = 0; a[i];) {
/* para nada, sempre que f (numero aleatório entre 0 e 5) seja igual a c (numero aleatório entre 0 e 5) */
for ( {}; (f = R(r() * 6)) == (c = R(r() * 6)); ) {}
/*
adicionamos a w o nome do primeiro pais, os gols do primeiro pais, 'X', o segundo pais,
os gols do segundo pais, '-', o nome do primeiro ou segundo pais dependendo
de se f for menor ou não a c
*/
w += [a[i],f,"X",a[i + 1],c,"-",a[i + (f < c)],
!a[2] ? "campeão" : b].join(" ");
a.splice((i++ + (f > c)), 1);
}
w += b;
}
alert(w);

O resto dos códigos dos demais participantes podem ser visualizados aqui.

Agradeço a Webly pela iniciativa, foi um desafio muito divertido e fico esperando pelo segundo.

Conhecendo isso podemos combinar a velocidade de destruir elementos tirando o elemento pai ao utilizar os métodos do DOM com criar novos elementos utilizando innerHTML.

Foi assim que uma solução foi sugerida e devido a participação dos leitores nos comentários foi melhorada notavelmente. DrSlump percebeu que mesmo a função sendo bem mais rápida que o innerHTML no Firefox, no IE era mais lenta e recomendou uma compilação condicional. Por sua parte, Dean Edwards sugeriu a utilização do método cloneNode para poder transferir todos os atributos de um elemento pra outro. Ao final a função ficou assim:

function replaceHtml(element, html) {
	var oldElement =
			(typeof element === "string" ? document.getElementById(element): element);
	/*@cc_on // innerHTML puro e mais rápido em IE
		oldElement.innerHTML = html;
		return oldElement;
	@*/
	var newElement = oldElement.cloneNode(false);
	newElement.innerHTML = html;
	oldElement.parentNode.replaceChild(newElement, oldElement);
	/* Como acabamos de remover o elemento antigo do DOM, retornar uma referenca
	ao novo elemento, o qual pode ser utilizado para restaurar referencias da variable */
	return newElement;
};

Para testar os resultados podem acessar a página criada pelo mesmo Steven.

function isMSIE() {
    /*@cc_on
        return true;
    @*/
    return false;
}

Depois de familiarizarmos com a sintaxe, podemos escrever códigos como o que Dean Edwards postou aqui:

var isMSIE = /*@cc_on!@*/false;