Descobertas

Diretamente do cotidiano de um programador

Game of Life

leave a comment »

Na falta do que fazer nesse final de semana, implementei o Conway’s Game of Life, usando JavaScript e a tag Canvas do HTML5. Não entendo nada de programacão gráfica para web, então não vou comparar o canvas com Flash com qualquer outra coisa.

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.

Written by Dalto

setembro 6, 2010 at 7:56 pm

JSON Parser

leave a comment »

Estamos usando JSON meu novo trabalho na Superficie para fazer a comunicacão entre plugins do SketchUp e uma aplicacao escrita em Rails. Acontece que a versao do Ruby do SketchUp é a 1.8.5 e, além disso, não possui nenhuma biblioteca padrão, o que torna algumas coisas como parsear strings JSON um pouco mais complicadas do que em uma instalacão do Ruby padrão. Procurei uma solucão para isso nos forums de desenvolvimento de plugin para o SketchUp, mas parece que até hoje ninguém tinha compartilhado uma gem para interpretacão e geracão de JSON a partir de objetos Ruby no ambiente limitado do SketchUp. Resolvi então portar o classico parser recursivo descentente do Douglas Crockford para Ruby.

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

Written by Dalto

agosto 13, 2010 at 11:32 am

Gems

with 2 comments

Meu dois últimos projetos em ruby foram dois wrappers para APIs. Uma para a API de previsão do Yahoo Weather, devido a uma necessidade que surgiu ao criar intranet para um cliente. Já existia uma gem em Ruby com essa finalidade, mas ao baixar o código para adicionar uma funcionalidade que eu precisava, vi que seria mais fácil fazer tudo do zero.

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.

Written by Dalto

junho 3, 2010 at 6:02 pm

Publicado em ruby, software livre

Programming Paradigms for Dummies

leave a comment »

Eu havia prometido pra mim mesmo que nunca leria alguma coisa que tivesse “for dummies” no título. Felizmente quebrei a promessa e li Programming Paradigms for Dummies, que introduz vários paradigmas de programação e explica quando e porque cada um é mais apropriado. Resolvi escrever algumas impressões que ficaram depois da leitura e registrá-las por aqui :)

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.

Written by Dalto

maio 26, 2010 at 10:42 am

Publicado em programming languages

Mais um pouco sobre herança prototípica

leave a comment »

Vamos continuar com as minhas divagações sobre herança prototípica. ;)

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.

Written by Dalto

novembro 18, 2009 at 4:23 am

O que é herança prototípica?

leave a comment »

Inicialmente eu queria falar bastante sobre herança prototípica em um post só, mas iria ficar muito maçante. Ainda mais que eu não sou expert no assunto e só quero clarear os conceitos pra mim mesmo e, se possível, abrir um espaço pra discussão (aquela discussão sadia que raramente se vê por aí) na área de comentários.

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.

Written by Dalto

outubro 20, 2009 at 3:49 am

Zen of Python

leave a comment »

Embora Ruby tenha algumas coisas bem diferentes em relação ao Python eu tento seguir o Zen of Python sempre que estou programando. Muito educativo e tem um certo senso de humor. ;)

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!

Written by Dalto

agosto 4, 2009 at 5:32 pm

Publicado em Uncategorized

Tagged with

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.