Uma das principais características do Ruby é ser uma linguagem dinâmica, o que significa que a tipagem é dinâmica, ou seja, a linguagem permite que uma variável seja usada sem ser previamente declarada, assuma um valor de uma classe qualquer e depois possa ter seu valor alterado para um objeto de outra classe.

Apesar da simplicidade que esta característica traz, frequentemente precisamos verificar o tipo de classe de uma variável, para termos certeza de que em uma chamada de função não é passada uma variável contendo um objeto de uma classe diferente da esperada, por exemplo. Isto não é necessário em linguagens como C e Java, onde cada variável precisa ser declarada antes do uso, e na declaração é necessário especificar o tipo de variável.

Este artigo apresenta um módulo Ruby chamado Types, que simplifica bastante o trabalho de verificação do tipo de classe passado em cada parâmetro de uma função. É possível, inclusive, verificar se a classe passada implementa um método específico. Qualquer tipo de verificação é feito acrescentando-se uma linha antes da definição da função, eliminando a necessidade de verificarmos o tipo de cada parâmetro no código da função. Não cheguei a testar o módulo ainda, porém, de acordo com o artigo, parece ser uma solução muito simples e flexível para problemas de tipagem.


Um dos princípios do desenvolvimento em Rails é o DRY (don’t repeat yourself). A idéia é que você nunca repita o código que já escreveu uma vez, procurando reaproveitar sempre que possível.

No caso das views, por exemplo, isso é bem simples de implementar, através do uso de partials. Você deve criar um arquivo de view começando com “_” (ex: _item.rhtml) e usar o comando render em outra view para carregar o partial dentro do layout (ex: render :partial => 'item').

Outro dia descobri uma maneira muito interessante de usar essa técnica no arquivo database.yml. Esse arquivo mantém as configurações de banco de dados para cada um dos ambientes - development, test e production. Porém, geralmente alguns destes parâmetros de configuração são iguais. O adapter, por exemplo, muito provavelmente é o mesmo; o username, senha e host também podem se repetir.

Segue abaixo um exemplo de como definir estas configurações sem repetições:

login: &login
  adapter: mysql
  username: username
  password: password
  host: mysql.example.com

development:
  <<: *login
  database: app_dev

test:
  <<: *login
  database: app_test

production:
  <<: *login
  database: app_prod

Só encontrei um problema: se você usar o Aptana RadRails para desenvolver, usando essa técnica, o modo “Data perspective”, que permite analisar a estrutura do banco de dados e executar querys, retorna uma mensagem de erro (“Invalid YML syntax”). Fora isso, está tudo funcionando bem. No NetBeans não há este problema.


Um detalhe muito incômodo no Ubuntu é que as configurações de rede realizadas através da opção “Network” (no menu System -> Administration) não são permanentes. Qualquer alteração realizada no endereço IP, gateway, DNS ou domínios é perdida após um reboot. Se você editar as configurações de uma interface de rede via ifconfig, o mesmo problema ocorrerá. Não sei se isso é um bug ou uma característica desejada, mas eu acho muito inconveniente.

Para tornar as configurações de rede permanentes, você deve editar os seguintes arquivos (como root ou sudo):

  • Configurações de DNS: arquivo /etc/dhcp3/dhclient.conf. Para definir servidores DNS, retire o comentário da linha prepend domain-name-servers e acrescente os IPs após 127.0.0.1, separados por espaço. Para definir domínios de busca, retire o comentário da linha supersede domain-name e digite os domínios entre aspas, separados por espaço;

  • Configurações de interface de rede: arquivo /etc/network/interfaces. Para configurar a interface eth0, por exemplo, acrescente as seguintes linhas no final do arquivo, substituindo os endereços IP pelos valores correspondentes:

auto eth0
iface eth0 inet static
address 192.168.254.3
netmask 255.255.255.0
gateway 192.168.254.254

Após concluir as alterações, reinicie o serviço de rede com o comando /etc/init.d/networking restart.


Atualmente, uma das tecnologias mais comentadas na web é o Ruby on Rails. Quando surgem estas novidades, eu costumo ficar com um pé atrás, pois muitas tecnologias que surgiram de repente e empolgaram muita gente sumiram tão rapidamente quanto apareceram.

Em relação ao Ruby on Rails, como já faz uns 2 ou 3 anos que começou a explodir, achei que valia a pena começar a dar uma olhada. Afinal, se entrar de cabeça em novas tecnologias pode ser perigoso, também não é legal ficar muito atrás de todo mundo, certo?

Há alguns meses atrás, finalmente comecei a estudar Rails (e Ruby, pois eu também não conhecia a linguagem). Optei por começar pelo livro “Build Your Own Ruby On Rails Web Applications”, pois estava disponível por tempo determinado para download gratuito em PDF no Sitepoint. Agora só é possível fazer o download de alguns capítulos.

Pensei que seria interessante começar com esse livro por ter um capítulo inicial dedicado à linguagem Ruby, e não me arrependi. Achei o livro muito interessante e extremamente didático. Cada linha de código apresentada é explicada em detalhes.

Ao concluir a leitura desse livro, comecei o tão comentado “Agile Web Development with Rails”, e até agora me decepcionei. Não estou gostando da didática dele, e não entendi ainda por que ele cria toda a estrutura do banco de dados manualmente, em vez de usar o excelente sistema de migrações do Rails. Talvez ele explique o motivo mais para frente, ainda estou no capítulo 7. Assim que concluir a leitura voltarei ao assunto.


Seja bem-vindo ao meu blog!

Pretendo usar este espaço para discutir novidades na área de informática, sempre que possível trazendo exemplos e situações do dia-a-dia do meu ambiente de trabalho. Comentários são sempre bem-vindos.