Hoje será um pouco diferente, pois o texto não foi escrito por mim e sim pelo @wycats (Yehuda Katz) do blog “Katz Got Your Tongue?”. Ele é um membro da equipe do Ruby on Rails e desenvolvedor líder do projeto Merb. Ele é um membro do time principal do jQuery e um grande contribuidor para o DataMapper. Ele contribui para muitos projetos de código aberto, como Rubinius e Johnson, e trabalha em alguns que ele mesmo criou, como Thor. Yehuda gentilmente concedeu que eu traduzisse seu post e o colocasse no blog e, além dele, tive também a ajuda do grande @elomar, que fez a revisão completa da tradução com seus ajustes essenciais. Então, aí vai o post! (Link do original: My 10 Favorite Things About the Ruby Language)

OBS: Infelizmente, o código disposto aqui não está sendo tabulado corretamente, tornando difícil sua visualização. Peço desculpas a todos por isso e, assim que possível, corrigirei o problema.

“Eu trabalho com Ruby todos os dias e ao longo do tempo comecei a realmente gostar de usá-lo. Aqui está uma lista de algumas coisas específicas que eu realmente gosto em Ruby. Algumas delas são óbvias e algumas também existem em outras linguagens. A proposta é compartilhar coisas que eu gosto em Ruby, não para comparar e competir com alguma linguagem específica.

1. Tipagem Dinâmica

Existem coisas muito boas sobre linguagens de tipagem estática, como verificação em tempo de compilação e suporte a IDE. No entanto, na minha experiência, tipagem dinâmica realmente ajuda a conseguir projetos concisos e limpos durante as mudanças, especialmente nos estágios inicial e mediano deles.

Eu estou muito feliz que eu não preciso criar uma interface formal para meus novos objetos implementarem, simplesmente para me possibilitar trocar facilmente as classes por outras, no futuro.

2. Duck Typing

(nota: como é um termo técnico, não há tradução que seja interessante colocar)

Isso é efetivamente só uma extensão de Tipagem Dinâmica. Em Ruby, métodos que esperam ser aptos a operar objetos String não checam se é uma String (is_a?(String)). Eles checam se o objeto responde a mensagem to_str (respond_to?(:to_str)) e então chamam o to_str naquele objeto se ele permitir. Similarmente, objetos que representam Paths em Ruby podem implementar um método to_path para proporcionar uma representação de path.

Em Rails, nós usamos essa técnica para objetos que tem características de “model” ao esperar deles o respond_to?(:to_model). Isso permite-nos suportar qualquer objeto em contextos relevantes, se aqueles objetos puderem nos fornecer uma representação “model” deles.

3. Módulos Incríveis

Ruby fornece um benefício similar ao “traits” em Scala, Squeak e Perl. Efetivamente, os módulos de Ruby permitem a adição dinâmica de novos elementos da hierarquia de classe em tempo de execução. O uso de super é dinamicamente avaliado em tempo de execução para considerar qualquer módulo que possa ter sido acrescentado, tornando fácil extender funcionalidade em uma superclass quantas vezes você desejar, sem ser forçado a decidir onde super estará ao declarar sua classe.

Além disso, os módulos de Ruby fornecem os eventos append_features e included, que tornam possível usar módulos robustamente para isolar extensões uma da outra e para dinamicamente extender classes na base da característica de inclusão.

4. Corpos de classes não são especiais

Em Ruby, corpos de classes são tem um contexto especial. Eles são simplesmente um contexto onde self aponta para o objeto da classe. Se você já usou Rails, você provavelmente viu um código como esse:

class Comment < ActiveRecord::Base

validates_presence_of :post_id

end

Pode parecer que validates_presence_of é uma característica da linguagem, mas na verdade é um método sendo chamado em Comment que é fornecido por ActiveRecord::Base.

Esse método pode executar um código arbitrário, também no contexto da classe, incluindo criar novos métodos, executar outras partes de código ou atualizar a variável de instância da classe. Ao contrário das “Java annotations”, que devem ser executadas em tempo de compilação, corpos de classes em Ruby podem pegar informações em tempo de execução para considerar, como opções fornecidas dinamicamente ou os resultados da avaliação de outro código.

5. String Eval

Eu não estou me referindo a “String eval” arbitrários em tempo de execução, mas a String eval que são usados para criar métodos no processo de boot de uma aplicação Ruby.

Isso torna possível pegar estruturas definidas pelo Ruby, como Rails routes ou AOP-definitions, e compilá-las em métodos Ruby. Claro, é possível implementar essas coisas como complementos para outras linguagens, todavia Ruby torna possível implementar esse tipo de coisa em Ruby puro. É, numa visão ampla, uma linguagem “self-hosting” (que compila seu próprio código fonte).

6. Blocos e “Lambdas”

Eu já disse isso algumas vezes e repetirei: eu não considero linguagens sem “lambdas” anônimos poderosas o bastante para meu usuo diário. Essas construções são, na verdade, extremamente comuns e encontradas em linguagens como Ruby, JavaScript, Scala, Clojure e Lisp.

Eles tornam possível implementar construções de escopo de bloco que parecem características da linguagem. O exemplo mais comum é o de operações com arquivos. Em linguagens sem “lambdas”, usuários são forçados a utilizar um bloco no mesmo escopo que ele abriu o arquivo para assegurar que ele está fechado.

Em Java:

static void run(String in)

throws FileNotFoundException {

File input = new File(in);

String line; Scanner reader = null;

try {

reader = new Scanner(input);

while(reader.hasNextLine()) {

System.out.println(reader.nextLine());

}

} finally { reader.close(); }

}

Entre outras coisas, o Java precisa colocar a criação do Scanner em um bloco TRY para garantir que será fechado. Em contraste, a versão Ruby:

def run(input)

File.open(input, “r”) do |f|

f.each_line {|line| puts line }

end

end

Por causa da existência de blocos, é possível abstrair a necessidade de fechar o arquivo em um único local, minimizando erros do programador e reduzindo duplicação.

7. Ataque Combo: Linguagem que se “auto-compila”

A combinação de diversas das características acima produz exemplos reais de formas que podemos “extender” o Ruby em Rails. Considere o seguinte:

respond_to do |format|

if @user.save

flash[:notice] = ‘User was successfully created.’

format.html { redirect_to(@user) }

format.xml { render ml => @user, :status =>ted, :location => @user }

else

format.html { render :action => “new” }

format.xml { render ml => @user.errors, :status => :unprocessable_entity }

end

end

Nesse caso, nós estamos aptos a misturar métodos (respond_to) com código Ruby (if e else) para produzir um novo escopo de bloco. A semântica do Ruby para blocos permite-nos retornar ou executar blocos de dentro deles, mas misturando mais as fronteiras de blocos de código e construções como if ou while.

Em Rails 3, nós introduzimos:

class PeopleController < ApplicationController

respond_to :html, ml, :json

def index

@people = Person.find(:all)

respond_with(@people)

end

end

Aqui, respond_to é fornecido em um nível de classe. Isso diz ao Rails que respond_with (índice) deve aceitar HTML, XML ou JSON como formatos. Se o usuário solicitar um formato diferente, é automaticamente retornado um erro 406 (não aceito).

Se você for um pouco mais profundo, você pode ver que o método respond_to é definido como:

def respond_to(*mimes)

options = mimes.extract_options!

only_actions = Array(options.delete(:only))

except_actions = Array(options.delete(:except))

mimes.each do |mime|

mime = mime.to_sym

mimes_for_respond_to[mime] = {}

mimes_for_respond_to[mime][:only] = only_actions unless only_actions.empty?

mimes_for_respond_to[mime][:except] = except_actions unless except_actions.empty?

end

end

Esse método é definido no módulo ActionController::MimeResponds::ClassMethods, que é colocado no ActionController::Base. Além disso, mimes_for_respond_to é definido usando class_inheritable_reader. O método do class_inheritable_reader (macro?) usa class_eval para adicionar métodos numa classe em questão para emular a funcionalidade attr_accessor.

Entender todos os detalhes não é importante. O que é importante é que usando as características do Ruby descritas acima, é possível criar camadas de abstração que podem aparecer para adicionar funcionalidades na linguagem.

Um desenvolvedor olhando para o ActionController::MimeResponds não precisa entender como class_inheritable_reader trabalha – ele só precisa entender a função básica. E um desenvolvedor olhando para a documentação da API não precisa entender como o respond_to a nível de classe é implementado – ele só precisa entender a funcionalidade fornecida. Dito isso, descamando cada camada leva a simplificar as abstrações que controem outras abstrações. Não há necessidade de descamar tudo de uma vez só.

8. Bons Literais

(nota: literais são tipo valores básicos, que você pode criar sem chamar um método .new)

Eu geralmente esqueço isso quando programo em Ruby, somente para reclamar quando uso uma linguagem com menos e pouco expressivos literais.

Ruby tem literais para quase tudo:

• Strings: single-line (uma linha), double-line (duas linhas), interpolated (interpolado)
• Números: binary, octal, decimal, hex
• Null: nil
• Boolean: true (verdadeiro), false (falso)
• Vetores: [1,2], %w(cada palavra é um elemento)
• Dicionários: {chave => valor} e no Ruby 1.9 {chave: valor}
• Expressões regulares: /hello/, %r{hello/path}, %r{hello#{interpolated}}
• Símbolos: :name e :”string qualquer”
• Bloco: {bloco literal}

E eu penso que estou perdendo algo. Enquanto isso pode parecer acadêmico, bom, legível, literais podem aumentar a habilidade do programador de escrever um código curto, mas extremamente expressivo. É claramente possível conseguir as mesmas coisas que você pode com um Dicionário “literal” ao instanciar um novo objeto Dicionário e colocar as chaves e valores um por vez, mas isso reduz a capacidade deles como parâmetros de algum método, por exemplo.

A concisão de um Dicionário “literal” permitiu os programadores de Ruby a efetivamente adicionar um recurso de argumentos limitados por palavras-chave à linguagem sem precisar da aprovação dos criadores dela. Ainda é outro pequeno exemplo de auto-compilação.

9. Tudo é um Objeto e Todo Código é Executado e tem um Self

Eu mostrei isso um pouco atrás, mas muito da razão dos corpos das Classes trabalharem como eles trabalham é uma consequência da infalível orientação a objeto da linguagem Ruby. Dentro do corpo de uma classe, Ruby é simplesmente executado com um self apontando para a classe. Além disso, nada é especial no contexto da classe; é possível avaliar o código de um contexto de classe de qualquer localidade. Veja:

module Util

def self.evaluate(klass)

klass.class_eval do

def hello

puts “#{self} says Hello!”

end

end

end

end

class PersonName < String

Util.evaluate(self)

end

Isso é exatamente equivalente a:

class PersonName < String

def hello

puts “#{self} says Hello!”

end

end

Ao remover as fontreiras artificiais entre código em diferentes locais, Ruby reduz a sobrecarga conceitual de criar abstrações. E isso é o resultado de um forte e consistente modelo de objeto.

Mais um exemplo nesse tópico. Essa expressão é muito comum em Ruby: possivelmente_nulo && possivelmente_nulo.nome_do_metodo. Já que nil é somente um objeto em Ruby, mandar mensagens a ele que não serão entendidas resultará em um NoMethodError. Alguns desenvolvedores recomendam a seguinte sintaxe: possivelmente_nulo.try(:nome_do_metodo). Isso pode ser implementado em Ruby como a seguir:

class Object

alias_method :try, :__send__

end

class NilClass

def try

nil

end

end

Essencialmente, isso adiciona o método try a qualquer Object. Quando o Object é nil, try simplesmente retorna nil. Quando o Object não é nil, try simplesmente chama o método em questão.

Usando aplicações segmentadas das classes abertas de Ruby, combinado com o fato que tudo em Ruby, incluindo nil, é um objeto, nós estamos aptos a criar um novo recurso de Ruby. Novamente, isso não é grande coisa, mas é outro caso no qual as escolhas certas na linguagem podem permitir que nós criemos abstrações muito úteis.

10. Rack

Eu irei trapacear um pouco porque Rack não faz parte da linguagem Ruby, mas ele demonstra algumas coisas úteis sobre a linguagem. Primeiramente, a biblioteca Rack só chegou ao 1.0 no começo desse ano e já todo framework web de Ruby suporta Rack. Se você usa um framework Ruby, você pode ser garantido que ele usa Rack e qualquer “Rack middleware” padrão irá funcionar.

Isso foi tudo feito sem qualquer sacrifício de compatibilidade anterior, um tributo à flexibilidade da linguagem Ruby.

Rack também traz recursos do Ruby para fazer seu trabalho. A API Rack parece com isso:

Rack::Builder.new do

use Some::Middleware, param

use Some::Other::Middleware

run Application

end

Nesse breve trecho de código, muitas coisas estão trabalhando. Primeiro, um bloco é passado para Rack::Builder. Segundo, esse bloco é avaliado no contexto de uma nova instância de Rack::Builder, o que dá acesso a usar e rodar os métodos. Terceiro, o parâmetro passado para usar e rodar é uma classe “literal”, que em Ruby é um simples objeto. Isso permite Rack chamar passed_in_middleware.new(app, param), em que new é somente uma chamada de método no objeto da classe Some::Middleware.

E no caso de você pensar que implementar o código seria hediondo, aqui está:

class Rack::Builder

def initialize(&block)

@ins = []

instance_eval(&block) if block_given?

end

def use(middleware, *args, &block)

@ins << lambda { |app| middleware.new(app, *args, &block) }

end

def run(app)

@ins << app #lambda { |nothing| app }

end

end

Isso é todo o necessário para implementar o código que eu mostrei acima que cria uma nova aplicação Rack. Instanciando o middleware é uma simples questão:

def to_app

inner_app = @ins.last

@ins[0...-1].reverse_each { |app| inner_app = app.call(inner_app) }

inner_app

end

def call(env)

to_app.call(env)

end

Primeiro, nós pegamos o último elemento, que é nosso ponto final. Nós, então, iteramos os elementos restantes com reverse, instanciando cada middleware com o próximo elemento da cadeia e retornando o objeto resultante.

Finalmente, nós definimos uma chamada de método no Construtor, que é requerida pelo Rack especificamente, que chama to_app e passa o ambiente por ele, retirando a cadeia.

Através do uso de um bom número de técnicas descritas no post, nós estamos aptos a criar uma aplicação compatível com Rack que suporta o “Rack middleware” em menos que duas dúzias de linhas de código.”

Posts interessantes:

• Manifesto ágil
• Getting Real e mais sobre a 37signals
• Aprenda Ruby on Rails com os experts no assunto
• Ruby on Rails, a nova sensação da Web

Vamos lá, conte-nos o que achou desse nosso primeiro Guest Post! Já está com todo o gás para entrar no Ruby? Comente e pergunte!

Helton de Melo Duarte

“Em Deus está a minha salvação e a minha glória; a rocha da minha fortaleza e o meu refúgio estão em Deus.” Salmos 62.7

“Ouve, ó Deus, a minha voz na minha oração; livra a minha vida do horror do inimigo.” Salmos 64.1

Hoje venho mostrá-los algo que já está na comunidade de informática a algum tempo, contudo está ganhando forças a cada dia e mostrando-se muito eficaz: desenvolvimento ágil de software. Chega de milhões de diagramas das aulas de engenharia de software (eu sei que tem um propósito, mas é muita burocracia!), vou traduzir abaixo o Agile Manifesto, publicado em 2001 por grandes nomes da área.

“Nós estamos descobrindo melnhores maneiras de desenvolver software ao fazer isso e ajudando outros a fazer. Por esse trabalho, nós começamos a valorizar:

• Indivíduos e interações, ao invés de processos e ferramentas;
• Software funcional, ao invés de documentação compreensiva;
• Colaboração do cliente, ao invés de negociação de contrato;
• Resposta a mudanças, ao invés de seguir um plano.

É isso, enquanto há algum valor nos itens à direita, nós valorizamos mais os itens à esquerda.

Princípios por trás do Manifesto Ágil

Nós seguimos esses princípios:

• Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual.
• Seja bem-vindo à mudança de requisitos, mesmo que tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
• Entregar software utilizável frequentemente, de algumas semanas a alguns meses, com preferência a menores escalas de tempo.
• Executivos e desenvolvedores devem trabalhar juntos diariamente durante o projeto.
• Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda que eles precisam e confie neles para ter o trabalho concluído.
• O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é conversa face-a-face.
• Software funcional é a medida primordial do progresso.
• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente.
• Atenção contínua à excelência técnica e bom design aumenta a agilidade.
• Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
• As melhores arquiteturas, requisitos e design surgem de um time auto-organizado.
• Em intervalos regulares, o time reflete em como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento.”

Se você quiser saber mais sobre o assunto, sugiro que dê uma olhada na história de criação do Manifesto e sobre os autores, para ter uma visão mais legal. Além do mais, você pode demonstrar que realmente apóia o assunto e assinar o manifesto.

Posts interessantes:

• Getting Real e mais sobre a 37signals
• Aprenda Ruby on Rails com os experts no assunto
• Ruby on Rails, a nova sensação da Web

E aí, o que achou do desenvolvimento ágil? Conte suas experiências com técnicas como eXtreme Programming ou Scrum, pois depois haverá posts sobre eles. Comente!

Helton de Melo Duarte

“Livra-me, meu Deus, dos meus inimigos; defende-me daqueles que se levantam contra mim.” Salmos 59.1

“A ti, ó fortaleza minha, cantarei louvores, porque Deus é a minha defesa, é o Deus da minha misericórdia.” Salmos 59.17

Como dito em um post anterior o Oxente Rails está chegando a Natal nos dias 7 e 8 de agosto, com o objetivo de divulgar esse framework web que está crescendo tanto nos últimos anos. Eu, como muitas outras pessoas, irei ao evento para tentar aprender um pouco sobre a linguagem (Ruby) e a plataforma (Rails), no entanto não queria chegar lá sem saber de NADA e resolvi procurar tutoriais rápidos (ou ler a introdução dos tutoriais maiores) para iniciar. Juntando o útil ao agradável, resolvi fazer esse post mostrando links para as principais referências do assunto, já que não tive tempo nessa semana para pesquisar sobre Expressões Regulares (para escrever no blog), as quais ficarão para uma semana posterior, ok?

Bem, primeiramente, é fundamental a visita ao AkitaOnRails.com, site com diversos tutoriais feitos por um dos pioneiros de Rails no Brasil e aos blogs de Tapajós e Mergulhão. Temos também os sites comunitários como RubyOnRails.pro.br, RubyInsideBrasil, RubyOnBr.org, entre outros. Alguns tutoriais bem legais seguem abaixo para quem quiser se aventurar em Ruby On Rails!

• O que é Ruby?, por RubyOnBr.org
• Micro-Tutorial de Ruby, por Fábio Akita (não tem nada de micro…)
• Rolling with Rails 2.1 – The First Full Tutorial (a versão atual é 2.3)
• Getting Started with Rails

Veja também um post do blog sobre Ruby On Rails, a nova sensação da Web.

É isso aí, pessoal, nos encontramos no Oxente Rails! Quem vai? E alguém tem mais algum tutorial ou site que queria recomendar? Comente e conte-nos!

Helton de Melo Duarte

“Entrega o teu caminho ao SENHOR; confia nEle, e Ele tudo fará.” Salmos 37.5

“Mas os ímpios perecerão, e os ímpios do SENHOR serão como a gordura dos cordeiros; desaparecerão e em fumaça se desfarão.” Salmos 37.20

O post hoje tem um caráter bem técnico, mas curto, e fala de uma linguagem da qual eu não sou nem tão familiarizado, contudo é bastante difundida no mercado de desenvolvimento Web: o PHP. Esse tópico foi sugestão do Mayron Cachina, veja seu twitter e site. Faça você também sugestões de assuntos para serem postados e, para ter sempre informações sobre tecnologia, me siga no twitter.

O E-mail Injection é uma vulnerabilidade que pode ocorrer em aplicações de internet que enviam e-mails, sendo o caso mais conhecido ao usar a função mail() do PHP (entretanto, pode ocorrer em qualquer linguagem web). Tudo ocorre devido ao formato de uma mensagem do protocolo MIME, pois ela delimita os campos por “Carriage Return”, permitindo usuários maliciosos inserirem essas quebras de linha ao final do Remetente da mensagem, por exemplo, e colocando uma imensa lista de CC (cópias) para mandar SPAM. Veja abaixo:

Sender: sender@anonymous.www%0ACc:recipient@someothersite.xxx
Subject: ahem
Message: My Message…

Os dados da mensagem MIME ficarão da seguinte maneira (gerando o SPAM que o spammer quiser):

To: recipient@victim.xxx
Subject: ahem
From: sender@anonymous.xxx
Cc:recipient@someothersite.xxx

OBS: Para quem não sabe, o código hexadecimal para quebrar linha é %0A.

Para evitar esse ENORME problema, é necessário criar uma função para avaliar o conteúdo das variáveis recebidas do usuário, fazendo simples testes se há quebra de linha no meio dos campos, evitando o envio dos SPAMs e, muitas vezes, assegurando a integridade da imagem da empresa. Viu como é fácil? Portanto, não só os programadores PHP, mas todos os que mexem com Web, não podem mais cometer esses erros. Se quiser de mais informações, como alguns códigos de exemplos e tal, veja os seguintes links:

• damonkohler.com – Inglês
  
• MeioCódigo.com – Português
  
• thesitewizard.com – Inglês
  

Posts interessantes:

• XNA – A fábrica de jogos da Microsoft
• E3 2009 – Uma revolução
• Computação em nuvem: Evolução?

E aí pessoal, o que acharam? Façam comentários! Sugiram ideias para os próximos posts! Conte também suas experiências com essa situação de E-mail Injection.

Helton de Melo Duarte

“Guia-me na tua verdade e ensina-me, pois tu és o Deus da minha salvação; por ti estou esperando todo o dia.” Salmos 25.5

Como prometido, hoje irei contar um pouco sobre o que é o Microsoft XNA Game Studio, para todos aqueles fanáticos por jogos! Tenho consciência de que meu nível com o XNA não é tão grande e, portanto, não irei fazer um curso de programação em XNA, como tinha dito, porém darei os links das pessoas mais indicadas para isso, ok? Posso fazer alguns posts sobre assuntos interessantes que eu for descobrindo na minha empreitada de desenvolvimento de jogos.

XNA não é somente um framework, como dizem por aí. Na verdade, o XNA Game Studio é o ambiente de desenvolvimento baseado no XNA Framework. Esse último é um conjunto de ferramentas facilitadoras do desenvolvimento de jogos criado pela Microsoft e baseada no Visual C#, possibilitando uma enorme agilidade nesse processo e dando a permissão de criar games para Windows, XBox 360 e Zune, algo extremamente interessante. Ele vem de modo a substituir o Managed DirectX e é baseado no .NET framework, ou seja, facilita a vida do programador quanto a seguridade do código e outras coisas. Veja mais sobre o .NET Framework.

Hoje em dia o XNA já está bem popularizado, muito graças a Imagine Cup, acredito eu, pois nessa competição, uma das maiores e mais diversificadas do mundo, no que diz respeito a tecnologia, há uma categoria de desenvolvimento de jogos, a qual exige a utilização do XNA. Esse ano, como já em diversas vezes, o Brasil estará representado na final, agora pela equipe Levv IT. Além dela, já existem diversas competições de jogos Brasil afora, como XNA Challenge e o BRGames.

No final das contas, para você que gosta de desenvolver jogos, o Microsoft XNA Game Studio, que por sinal lançou sua versão XNA 3.1 hoje, é uma dos melhores IDEs (ambiente de desenvolvimento), está em crescente melhoramento e já possui uma vasta comunidade de desenvolvedores, pronta para ajudar os iniciantes. Veja agora, os principais links de tutoriais:

• XNA – MSDN Developer Center
• XNA Creators Club – Getting Started
• Sharpgames – Comunidade Brasileira de XNA

Além do mais, veja o blog do Luciano José, um dos maiores expoentes em XNA do Brasil. Para aqueles de Natal-RN, há a célula acadêmica da Microsoft, da qual eu participo (e, por sinal, sou pouco assíduo), o XNA Natal Academics. Então, bons jogos para vocês!

OBS: Relembrando que estou com a ideia de um projeto de desenvolvimento de jogos com fins terapêuticos, como para ajudar crianças com câncer ou algo do tipo. Esses jogos terão temas de combate a doenças, por exemplo: destruir as células maldosas do câncer; protejer a pele de raios ultra-violeta; entre outros. Peço a ajuda de todos com sugestões para esse projeto, principalmente com ideias de temas a serem utilizados.

Posts interessantes:

• E3 2009 – Uma revolução
• Cursos grátis na Internet – MIT

Prontos para aprender XNA? Vamos lá, pessoal! Está faltando alguma coisa no post? Deixe seu comentário e ajude-nos. Conte também sobre suas experiências com essa ferramenta!

Helton de Melo Duarte

“Quem é o Rei da Glória? O SENHOR forte e poderoso, o SENHOR poderoso na guerra. Quem é o Rei da Glória? O SENHOR dos Exércitos; Ele é o Rei da Glória.” Salmos 24.8,10

Venho aqui falar para vocês sobre uma nem tão nova ferramenta da Web, porém pouco conhecida ainda aqui em nosso país: o Ruby on Rails, criado por David Heinemeier Hanson, para ser uma linguagem linda, como o próprio falou em entrevista para a revista INFO Exame Novembro/2008. “[...]o Ruby me permitiu escrever os códigos mais belos que eu já programei.”

Primeiramente vamos descobrir o que é o Ruby, ok? Ruby é uma linguagem orientada a objetos com o objetivo de limpar o código dos programadores, tendo uma sintaxe bem limpa e de fácil compreensão (mescla características de Python, Pearl e Smalltalk, segundoBill Walton e Curt Hibbs). Foi criada por Yukihiro Matsumoto, no Japão, porém só foi fazer mais sucesso quando começaram a serem lançados livros em inglês sobre a linguagem.

O segundo ponto a ser abordado é o que seria o Rails, criado pelo dinamarquês David. Rails seria um framework para a linguagem Ruby, o qual tem código aberto e é direcionado para aplicações Web, podendo ter acesso a banco de dados, além disso seu principal foco é uma metodologia para desenvolvimento ágil. Você provavelmente deve estar se perguntando (principalmente se já programa para Web, em PHP por exemplo), por que eu escolherei o Rails se há diversos frameworks e linguagens para realizar a mesma função?

A resposta para sua pergunta é simples: porque o que David Heinemeier queria foi conseguido, Rails é realmente LINDO. O código torna-se extremamente limpo, além de ser baseado na arquitetura MVC (padrão de arquitetura de sofware que facilita a programação ao separar os dados – Model – e o layout – View – além de algo para uní-los, o Controller). Possui filosofias de desenvolvimento para simplificar a nossa vida, como as seguintes:

-> Convention over Configuration (CoC): é baseada no fato de que o programador não precisa especificar tudo em sua aplicação, apenas o que é não é convencional. Por exemplo, se eu desejo criar uma classe “Venda” na minha aplicação – dentro do Model, automaticamente exitirá no Banco de Dados uma tabela “Vendas” por padrão, contudo se eu preferir posso nomeá-la para “ProdutosVendidos” e apenas nesse caso precisarei especificar seu nome. Deu para entender? Qualquer dúvida pode mandar em um comentário que procurarei responder.

-> Don`t repeat yourself (DRY): princípio do livro The Pragmatic Programmer, de Andy Hunt e Dave Thomas, ele consiste no fato de que um código não pode estar duplicado de forma alguma, porque essa ação pode gerar futuras inconsistências e diminuir a clareza do código. Tudo em sua aplicação que possuir alguma relação lógica deve estar sincronizado com o outro em relação às mudanças, como o exemplo da tabela “Vendas”, citada anteriormente, que ao ser mudada também criaria outros campos na classe “Venda”, por exemplo.

Como visto acima, o Rails é algo que deve ser visto com bons olhos por todos aqui no Brasil por todos os motivos apresentados acima e precisa ser conhecido dos programadores Web, para trazer à tona um desenvolvimento belo e limpo, como nos sonhos de qualquer programador. Para você que gosta de Web essa é uma excelente oportunidade, também pelo fato de que diversas empresas já estão trabalhando com esse framework, um exemplo de grande sucesso é o Twitter, feito com Rails.

Para que você possa ter contato com essa plataforma, colocarei diversos links, muitos dos quais busquei informações para poder elaborar esse post:

* http://www.rubyonrails.pro.br/

* http://groups.google.com/group/rails-br

* http://www.rubyonbr.org/

* http://guides.rails.info/getting_started_with_rails.html

* http://imasters.uol.com.br/artigo/4746/programacao/porque_ruby_on_rails/

Bem acredito que seja isso que eu tinha para falar, espero ter dado uma visão geral sobre o Ruby on Rails para todos vocês, procurem mais sobre ele, não se prendam apenas à esse post, ok? Para o pessoal do nordeste, provavelmente no próximo ano será realizado o Oxente Rails, para todos nós agraciarmos essa beleza de linguagem e, se meu amigo Elomar França conseguir, acontecerá na minha cidade, em Natal-RN.

Até a próxima!

PS: lembrando que foi criada recentemente a página de Sugestões aqui no blog, para vocês comentarem como devem ser feitas as postagens ou algum assunto que desejam muito conhecer, para que eu possa estudar e postar sobre ele. Valeu!

Helton de Melo Duarte

“A Vida de um indivíduo só faz sentido se ajuda a tornar as vidas das demais criaturas mais nobres e mais belas.” Albert Einstein