Tentei fazer o jogo usando JavaScript puro. O que sempre me frustra sempre que eu preciso usar js é que, quando usada sem frameworks como jQuery, Prototype, underscore, etc a linguagem carece de muitos métodos bastante úteis que mesclam programacão funcional e o uso de colecões. Uma das coisas que eu tive que fazer para deixar com que o código do jogo ficasse mais funcional foi extender prototypo Array para suportar as funcões map, select, partition e etc, que são bastante úteis e de implementacão trivial. Me admira muito que funcões desse tipo não estão na implementacão padrão dos arrays javascript.

Como sempre, o código-fonte do jogo está hospedado no github. Por enquanto a implementacão é bem simples e ainda tem muito a melhorar.

Escrevi testes com o Rspec, me baseando nos testes do Ruby Quiz #155 e fui portando do algoritmo aos poucos, me certificando que os testes passavam na medida em que ele ia sendo totalmente implementado. Já estamos usando o parser há algum tempo e até hoje não deu nenhum problema. A única limitacão mais grave é que ele não sabe lidar muito bem com alguns casos de JSON inválido, mas isso não é um problema grande nos casos em que ele é usado na Superficie, porque todo JSON interpretado por ele é gerado pelo Rails.

Segue o link para baixar a gem no RubyGems: http://rubygems.org/gems/sketchup_json

Além de encapsular o acesso a API do yahoo, a yahoo_weatherman provê uma maneira simples de adicionar suas próprias traducões para as respostas da API. Como a API do Yahoo Weather é baseada em XML, usei a gem nokogiri para fazer todo o trabalho de parsing. Nada complicado.

A outra gem é minha aposta no torneio que o pessoal do Stack Exchange anunciou junto com a primeira versão publica da sua API beta. Tem um prêmio para quem fizer o melhor wrapper. Eu dúvido que vá ganhar, mas já anunciei minha gem no fórum. No momento ela já cobre a maior parte da API e pode ser considerada “usável”.

A API do Stack Exchange é baseada em json e não precisei de nada além do que o ruby já oferece na sua standard library.  No início achei que precisaria da hashie ou da mash para transformar os hashs do ruby em algo mais parecido com objetos javascript,  mas descobri que a OpenStruct da standard lib já faz isso de uma forma muito simples e acabei usando ela.

A primeira coisa que me chamou atenção foi a persistência do autor em dizer que uma linguagem adequada para sistemas grandes deve ser multi-paradigma. A razão disto é que em sistemas muito grandes, vários tipos de problemas diferentes devem ser resolvidos. Como cada paradigma de programação é mais adequado pra um determinado tipo de problema, nada mais natural do que ter uma linguagem que consiga lidar com o maior número de problemas possível. Uma boa escolha de linguagem teria dois paradigmas: um para “programming in the small” e outro para “programming in the large”.

Isso me fez pensar em duas coisas: 1) é mais fácil cair na tentação de que “minha linguagem resolve tudo” do escolher/aprender uma linguagem adequada ao domínio o qual se deseja trabalhar; 2) até onde aprender uma linguagem pura (funcional ou orientada a objetos, por exemplo) é válido para aplicá-la em um problema real.

Outra parte que merece destaque no paper são as definições de conceitos de linguagens de programação importantes como records, closures, concorrência e estado. A surpresa aqui foi a grande importância dada ao estado (o termo usado no paper é named state) para a modularidade dos sistemas. De acordo com o autor, estado é imprescindível quando se deseja ter modularidade, pois somente com ele um componente pode se adaptar ao ambiente em que ele está. Fiquei surpreso pois ultimamente andei lendo umas críticas bem pesadas com relação a manter estado no contexto de computação paralela. E, é claro, fiquei com a dúvida: como se consegue modularização em linguagens puramente funcionais?

Há um tópico apenas sobre concorrência. Nele podemos encontrar uma descrição mais formal sobre a diferença entre paralelismo e concorrência. Paralelismo é um conceito relacionado a hardware e à capacidade de executar duas partes simultaneamente em multiplos processadores. Concorrência é relacionada à linguagem de programação e à capacidade de dividir o tempo do processador entre duas atividades. Os modelos de concorrência adotados por várias linguagens são descritos detalhadamente, assim como suas vantagens de desvantagens.

Linguagens que abordam concorrência de uma forma diferente da maioria das linguagens mainstream (Java, C++, Ruby) foram citadas. Destaque para Oz, Alice, FrTime e Yampa onde condições de corrida são impossíveis de ocorrer. O modelo de concorrência declarativa (Oz) foi destacado por sua propriedade de confluência, em que não importa a ordem em que as funções são avaliadas, pois o resultado é sempre o mesmo. Isso é fortemente desejado, pois elimina toda necessidade de compartilhamento de memória e sincronização entre processos, evitando grande parte dos problemas de concorrência.

Concluindo, o paper ainda fala sobre conceitos e paradigmas que eu nem mencionei aqui. Tudo é muito bem explicado o que torna o texto uma leitura recomendada pra quem tem vontade de aprender mais sobre paradigmas e linguagens.

Continuarei citando mais vantagens e desvantagens entre a herança prototípica em relação a baseada em classes. Num outro post, quando sobrar um tempinho, vou falar sobre as maneiras de simular a flexibilidade da herança prototípica em Ruby por meio do uso de módulos como mixins, metaprogramação e do método Class#new que aceita um bloco como parâmetro.

Vantagens

Algumas vantagens que não foram citadas no primeiro post:

• Relacionamentos simplificados entre objetos: para entender como os objetos se relacionam em um sistema baseado em classes devemos saber que podem existir dois tipo de relações entre eles. A primeira, citada no paper como ‘is_a’, indica se um objeto é instância de uma classe. A segunda, ‘kind_of’, indica se a classe objeto é subclasse de outra. Quando se tem herança prototípica, a única relação entre dois objetos é ‘inherits_from’ que indica se ele foi clonado de outro.
• Criação por cópia: instanciar um objeto a partir de uma classe é como construir uma casa a partir de uma planta. Clonar um objeto a partir de outro seria então uma metáfora mais simples para instanciação.
• Exemplos de módulos pré-existentes: Protótipos são mais contretos do que classes por que eles são modelos existentes com comportamento definido, que pode ser observado. Eles são exemplos do comportamento que será clonado por outros objetos. Classes são descrições do que os objetos instanciados por elas virão a ser. Há uma diferença entre ser um exemplo que se pode interagir e uma descrição estática.

Desvantagens

As principais desvantagens são relacionadas à organização do código. Como saber se um objeto só existe para ser protótipo de outros? Esse problema é um sistema grande pode dar uma baita dor de cabeça. Uma saída, ainda que bem precária (na minha humilde opinião :) para isto pode ser usar convenções para nomes de variáveis.

Tudo começou quando eu estava lendo um post no blog do Rodrigo Kumpera, em que ele deu umas dicas de papers pra ler. Li esse paper sobre a linguagem Self e achei muito interessante o fato de alguns conceitos citados poderem ser usados em duas linguagens que eu uso bastante, que são o Ruby e o Javascript.

Herança prototípica é uma estratégia para reutilização de comportamento entre objetos. Existem várias diferenças entre a herança prototípica e a baseada em classes. O objetivo dos meus próximos posts é descrever as principais diferenças entre cada uma delas e dar exemplos de situações em que a herança prototípica está presente.

O papel da classe em uma linguagem como o Java é descrever a estrutura e o comportamento de um objeto que será instanciado por ela, além de fornecer um construtor que será utilizado para instanciar esse objeto. A estrutura do objeto instanciado é sua interface, que foi descrita na classe e seu comportamento é determinado pelos métodos que foram implementados na classe.

Em linguagens que usam herança prototípica não existe o conceito de classe, apenas o de objetos e protótipos. Um objeto não tem uma forma estática descrita por uma classe e novos objetos são obtidos a partir da clonagem de um protótipo. Quando se deseja obter um objeto novo, se faz uma cópia de um objeto. Este objeto copiado é que é chamado protótipo. O papel da instanciação do objeto está no seu protótipo, que por acaso, é um objeto também.

Tudo que interessa saber dele em tempo de execução é seu comportamento, quais métodos ele tem. A definição desse comportamento é feita de forma completamente dinãmica. Basicamente, a coisa funciona da seguinte forma: um objeto pode ser imaginado como um amontoado de “coisas”  (objetos e funções/métodos) e essas coisas são guardadas em compartimentos (slots).

Herança prototípica é um conceito que a primeira vista parece muito simples, mas que traz consigo algumas implicações bem interessantes. Por exemplo, todas as informações a respeito de um objeto estão nele, e não comportamento no objeto e descrição/formato na classe. Os protótipos também são mais “contretos” do que classes, porque eles são exemplos do comportamento do objeto ao invés de apenas descrições deles.

Outra coisa bem interessante é que esta forma de herança encoraja a criação de objetos unicamente especializados. Quando utilizamos classes, geralmente estamos descrevendo vários objetos. O que é um problema quando queremos, por exemplo, instanciar apenas um objeto daquela classe. Será que precisamos declarar uma classe que só será usada por um objeto? Ruby e Smalltalk, por exemplo, têm uma classe usada para descrever cada um dos valores booleanos. Já em Self, precisaríamos de dois objetos comuns, o que se comporta como o valor true e outro que se comporta como false. E se eu quiser um objeto que seja só um pouquinho diferente de outro? Preciso usar herança e sobrescrever um método ou adicionar outro? Bom, acho que deu pra entender do que estou falando…

Bom, como já havia dito no inicío do post vou ter que escrever mais outro dia, pra dar citar mais diferenças entre os dois paradigmas e dar mais exemplos em código.  Por enquanto dê uma olhada nesse exemplo em javascript, que não tem nada demais pra quem já conhece a linguagem ou já usou metaprogramação em Ruby, Python ou outra linguagem mais dinâmica, mas que serve como um bom ponto de partida pra quem está totalmente cru no assunto.

/* Objetos em Javascript */

var o = new Object();

o['slot1'] = new Object(); // outro objeto

o['slot2'] = 1000;

o['slot3'] = function() { return this.slot2; } //o ‘this’ da função vai apontar pro escopo do objeto.

Podemos usar a notação literal de objetos para simplificar um pouco isso:

var o = { slot1 : {}, slot2 : 1000, slot3 : funtion() { return this.slot2; }}

É fácil ver que esse estilo de programação encoraja bastante a adição de comportamentos a um objeto em tempo de execução. Por exemplo, seria trivial escrever código para inserir métodos dinâmicamente em um objeto em Javascript:

var entidade = {}

for (nomeAtr in tabelaDoBanco) {

entidade[nomeAtr] = function() {return valorDoAtributo(nomeAtr)};

}

Mas esse exemplo é bastante simplório. No próximo post vou descrever mais detalhadamente as vantagens de desvantagens de linguagens que usam herança prototípica.

Zen of Python

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one– and preferably only one –obvious way to do it.

Although that way may not be obvious at first unless you’re Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it’s a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea — let’s do more of those!

Depois de um bom quarto de hora procurando pela resposta no google, encontrei esse post no fórum do rails, que explica o porquê e como resolver essa situação esquisita.

A solução é a seguinte: depois de alterar a estrutura de uma tabela em uma migration, você deve chamar o método reset_column_information do seu modelo, para que o Rails atualize os dados do mesmo, coisa que ele não faz por padrão.

Em português:

Rails Podcast Brasil

Improvecast

Em inglês:

Stack Overflow

Rails Envy

Por hoje é só!

Fiz uma pequena pesquisa e vi que muita gente já usava Groovy, BeanShell, Rhino ou JRuby para este fim. Não cheguei a testar todas e tenho certeza que o console dessas linguagens pode ser uma mão na roda, mas como estou imerso em Ruby ultimamente, optei pelo JRuby.

A instalação do JRuby no Debian é bastante simples, um apt-get install jruby dá conta do recado. A única coisa que eu tive que mexer no meu ambiente de trabalho foi adicionar um alias no meu .zshrc (equivalente ao .bashrc para usuários de bash) pra poder chamar o jirb na linha de comando sem precisar colocar a versão do programa no final.

O que eu precisei fazer foi basicamente:

apt-get install jruby

cd ~

echo “alias jirb=’jirb1.0′” >> .zshrc

source .zshrc

Depois apenas segui um tutorial que explica como testar o comportamento de algumas classes do Java no jirb e voilá, agora já posso testar classes Java com muito mais praticidade. :)

No wiki do jruby tem mais informações sobre como chamar código Java de dentro do Ruby.