Aquela velha historia

A maioria dos projetos, tem uma documentação inicial, onde são colocadas as necessidades do cliente. Num projeto tradicional, ou não, esta documentação será entregue aos desenvolvedores para fazer o milgre de transformar texto impresso no papel, em software. Até agora não contei novidade alguma, mas a coisa vai ficar mais interessante a partir de agora.

Os desenvolvedores começam então, a escrever o software baseado nas informações contidas na documentação entregue a eles. Agora imagine que boa parte do software já está implementada e o gerente de proejetos está super feliz em ver o gráfico do project bonitinho, mostrando que o projeto está até adiantado. Quando... acontece o que sempre acontece em projetos de software. Uma grande mudança, uma alteração tão radical que afetará varios pontos do sistema. Vocês já viram este filme, e sabem que numa situação dessas é comum ter que fazer tudo pra ontem e sem prejuizo ao cronograma. O que se traduz em horas extras e trabalho nos finais de semana. O ambiente de trabalho legal para os desenvolvedores costuma acabar neste ponto. Como as alterações são todas urgentes, é muito comum que a equipe concentre forças na alteração do código fonte, enquanto a alteração da documentação fica pra depois. Um depois que geralmente nunca acontece.

TDD e Documentos... onde você quer chegar?

Pronto agora cheguei onde queria =). Comecei falando de TDD e no paragrafo anterior falei de documentação desatualizada. Que relação essas coisas podem ter?

Bem, a documentação incial do projeto, em papel, descreve o que o software deve fazer (comportamento), os métodos das classes escritas pelos desenvolvedores são responsáveis por realizar este comportamento. Em um cenário, como posso dizer, "mais comum" depois do desenvolvedor implementar o software, uma pessoa seria encarregada de testar o comportamento do software, para isso ela precisaria recorrer a documentação do projeto. Mas depois da mudança a documentação vai estar desatualizada o que abre margem para problemas maiores.

Uma maneira de resolver este problema seria automatizando os testes, e neste ponto entram os testes de unidade. Imagine que nossos desenvolvedores escreveram testes de unidade automatizados para checar o compotamento de cada um dos métodos implemetados por eles. Agora não precisarimos de mais uma pessoa para testar, e o mais importante, agora temos uma documentação executável. Isso mesmo pense nos testes de unidade como sendo uma documentação executável, uma documentação que quebra se não for atualizada.

Documentação Executável

Como todos sabem a documentação mais atualizada de um software é o código fonte. O problema é que ele não é "amigavel e legivel" para todos.  Pode ser pouco agradavel ter de ficar olhando varios arquivos, classes e métodos para entender o que eles fazem realmente. Na tentativa de melhorar, esse cenário pessoas passaram a utilizar uma técnica para escrita de testes que tenta expressar mais a intenção daquele comportamento. Esta técnica é conhecida como Behaviour Driven Development (BDD), foi um termo cunhado por Dan North mais informações aqui. Mas continua sendo muito código, e fica ainda complicado identificar o que é uma pré-condição, o que realmente está sendo testado é o que é a pós-condição. No JUnit por exemplo, a responsabilidade de descrever o comportamento testado fica no nome do método, que pode ficar quilometrico (nada contra), como por exemplo: deveSerCapazDeCriarUmaListaDePedidosAPartirDoXML.

Na tentativa de tornar os comportamentos mais evidentes, sugriam framework's como RSpec utilizado por desenvolvedores ruby.
Veja abaixo um exemplo de código do RSpec

describe "Uma Conta"
it "nao deve permitir saques superiores ao valor de seu saldo" do
   conta = Conta.new
   conta.deposita 100
   lambda{ conta.saca 200}.should raise_error ArgumentError
end

Apesar de ter menos "ruido", muito também devido a linguagem ruby,  este código ainda tem muito apelo programático. Fica dificil usar um negocio desses com seu cliente, ou especialista de negocios. Então o bacana mesmo seria escrever especificações/documentação, usando o bom e velho português, e ter algum vodoo que tornasse essa documentação executável.

E esse Vodoo existe?

Sim esse vodoo existe e se chama Cucumber.
O Cucumber é um framework que permite a escrita de funcionalidades, no estilo user story, uma especie de caso de uso. Vejamos um exemplo:

#language: pt
Funcionalidade: Saque de conta
   Para retirar dinheiro do banco
   Como um correntista do banco
   Devo realizar um saque
 
Cenario: Saque com sucesso
   Dado que a "minha conta" possui "saldo" de "100" reais
   Quando eu sacar "70" reais da "minha conta"
   Entao "minha conta" devera ter "saldo" de "30" reais
 
Cenario: Saldo Insuficiente para Saque
   Dado que a "minha conta" possui "saldo" de "100" reais
   Quando eu sacar "200" reais da "minha conta"
   Entao um erro de "Saldo Insuficiente" deve ser exibido

Pra começar as historias descrevem funcionalidades (features), e é comum se apresentarem neste formato:
Para alguma coisa
Como um papel,
Devo fazer alguma coisa.
Logo depois definimos os cenários, nosso exemplo tem dois cenários um de sucesso e outro de falha, você pode escrever quantos cenários quiser.

Aham Cláudia senta lá...

Então agora eu escrevo a especificação que eu quiser usando português e pronto vai funcionar? Quase isso, o cucumber permite o uso do português para descrevermos a funcionalidade e seus cenários, mas lembre-se que no fundo no fundo tudo isso é um grande teste. A grande diferença é que o apelo programático é retirado, mas a intenção do teste ainda está lá. O JUnit nos fornece os chamados TestCase para que possamos agrupar nossos testes. O cucumber nos fornece o recurso de features (funcionalides) no qual descrevemos uma funcionalidade. Cada funcionalidade do sistema costuma ser descrita por em um arquivo separado que possui a extensão .feature, o exemplo da funcionalide saque de conta ficaria num arquivo chamado: saque_conta.feature. Além disso o cucumber impõe que estes arquivos "vivam" dentro de uma pasta que se chame "features". As features podem conter vários cenários. Dá pra fazer um paralelo entre os cenários e os métodos de teste de um TestCase do JUnit. Os cenários descrevem de maneira mais intuitiva os 3 componentes do teste: pré-condição, teste e pós-condição, como podemos ver abaixo:

Cenario: Saque com sucesso
   Dado que a "minha conta" possui "saldo" de "100" reais #pré-condição
   Quando eu sacar "70" reais da "minha conta"             #teste
   Entao "minha conta" devera ter "saldo" de "30" reais  #pós-condição

A primeira linha define a pré-condição a segunda deixa claro o que queremos testar e a útlima linha checa a pós-condição, tudo sem apelo programático.

E cadê o código que faz isso funcionar?

Bem a gente precisa escrver esse código, não tem jeito. Porém o bacana é que ele fica totalmente separado do texto da funcionalidade e dos cenários. O cucumber espera que você forneça para cada passo dos seus cenários, um bloco de código fonte, para que ele consiga executar os testes. Estes blocos de código são definidos dentro de um arquivo, que geralmente é chamado de "step.rb", e precisa ficar dentro da pasta "features/step_definitions".

Quando o cucumber interpreta o arquivo da feature e identifica  passos "indefinidos", ele gera uma especie de template do passo, para que este possa ser implementado no arquivo de definicao de passos, o step.rb por exemplo. Um exemplo deste template seria:

Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |arg1, arg2, arg3|
  pending # express the regexp above with the code you wish you had
end

Repare que tudo que foi informado entre "" foi considerado como parametro pelo cucumber, repare também que o template já abre um bloco de código onde ele nós fornece os argumentos. Entre este "do" e "end" é que colocamos a implementação do nosso passo. Veja agora um exemplo de implementação:

Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
   conta = obter_conta_pelo_nome(nome_da_conta)
   atributo = change_spaces_for_underlines(atributo)
   conta.instance_variable_set( "@#{atributo}", valor.to_f )
end

O bacana é que os steps são reapoveitaveis, repare que o step do exemplo acima também é utilizado no cenário de saque com saldo insuficiente. No início vamos implementar muitos steps, mas depois vamos passar mais tempo escrevendo cenários e novas features do que implementando steps efetivamente. É possivel configurar o cucumber para fazer o output de seus testes em html. O interessante deste formato é que as funcionalidades e cenários ficam com "cara" de documentação "formal".

Conclusão

É foi isso... A ideia aqui era focar no teste como forma de documentação. Apesar desta não ser uma ideia nova, vimos que o ruido programático dos testes pode atrapalhar. Terminamos vendo que o Cucumber resolve o problema do ruído na documentação executavel seprando a definicao das funcionalidades e cenários do código que faz tudo funcionar.

Abraços e até a próxima,

Sérgio Junior

Abaixo está a implementação completa da funcionalidade descrita neste post:

require 'lib/conta/conta'
 
Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
   conta = obter_conta_pelo_nome(nome_da_conta)
   atributo = change_spaces_for_underlines(atributo)
   conta.instance_variable_set( "@#{atributo}", valor.to_f )
end
 
Dado /^que a "([^\"]*)" esta bloqueada$/ do |nome_conta|
   conta = obter_conta_pelo_nome(nome_conta)
   conta.bloqueada = true
end
 
Quando /^eu transferir "([^\"]*)" reais da "([^\"]*)" para "([^\"]*)"$/ do |valor, origem, destino|
  conta_origem = obter_conta_pelo_nome(origem)
  conta_destino = obter_conta_pelo_nome(destino)
  begin
    conta_origem.transfere :para => conta_destino, :valor => valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Quando /^eu sacar "([^\"]*)" reais da "([^\"]*)"$/ do |valor, nome_conta|
  conta = obter_conta_pelo_nome(nome_conta)
  begin
    conta.saca valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Quando /^eu depositar "([^\"]*)" reais na "([^\"]*)"$/ do |valor, nome_conta|
  conta = obter_conta_pelo_nome(nome_conta)
  begin
    conta.deposita valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Entao /^"([^\"]*)" devera ter "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
  conta = obter_conta_pelo_nome(nome_da_conta)
  atributo = change_spaces_for_underlines(atributo)
  conta.instance_variable_get( "@#{atributo}" ).should == valor.to_f
end  
 
Entao /^um erro de "([^\"]*)" deve ser exibido$/ do |mensagem|
  @erro.message.should == mensagem
end
 
private
  def obter_conta_pelo_nome(nome_da_conta)
    conta_simbolo = name_to_symbol(nome_da_conta)
    @contas ||= {}
    if @contas[conta_simbolo]
      conta = @contas[conta_simbolo]
    else
      conta = Conta.new
      @contas[conta_simbolo] = conta
    end
  end
 
  def change_spaces_for_underlines(name)
    name.gsub(/\s/,'_')
  end
 
  def name_to_symbol(name)
    change_spaces_for_underlines(name).to_sym
  end

Problema Inicial:

Devemos criar um  método que seja capaz de percorrer um array, exibindo seus elementos. (Ok, tudo bem nós sabemos que todo array possui um método each. Mas vamos fingir que esse kra não existe)

lista = ["sergio","roberto", "iuri","luiz"]
def mostra_elementos( array )
  for elemento in array
    puts elemento
  end
end
mostra_elementos(lista)

Ótimo! Atingimos nosso objetivo. O codigo acima exibira os nomes contidos no array.

Os requisitos mudaram:

Agora nós queremos  percorrer o array exibindo cada um de seus elementos ao contrario, por exemplo, "sergio" será exibido como "oigres". Podemos criar um novo método para isso, então vamos ao trabalho:

<span id="more-451"></span>def mostra_elementos_ao_contrario( array )
  for elemento in array
    puts elemento.reverse
  end
end
mostra_elementos_ao_contrario( lista )

Perfeito! Mais uma vez concluímos nossa tarefa.

DRY, mais um princípio de Desenvolvimento de Software:

Os problemas anteriores envolviam operações com elementos de um array (uma lista), e assim acabamos criando dois métodos para resolver os problemas propostos. Existe um princípio de desenvolvimento de software que é focado em reduzir a repetição/duplicação de código, ele é conhecido como: Don't Repeat Yourself - (DRY). Este principio diz que:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

O que poderiamos traduzir como: "Cada parte do conhecimento deve ter uma representação única e não ambigua dentro de um sistema". Desta forma utilizando o DRY para analisar as funções que escrevemos até agora, podemos notar que a parte do conhecimento de percorrer um array não possui uma representação única em nosso sistema. O ideal seria que o codigo de percorrer um array nao fosse mais repetido, e é exatamente nisso que vamos trabalhar agora.

Aplicando o DRY

A maneira mais simples de resolvemos o problema de duplicação do codigo de percorrer o array, é sem duvida realizar um refactor chamado extract method, e assim isolar a lógica de percorrer arrays em um método. Entao vamos lá:

def percorre_array( array )
  for elemento in array
 
  end
end
def mostra_elementos( array )
   percorre_array( array)
   puts elemento
end
def mostra_elementos_ao_contrario( array )
  percorre_array(array)
  puts elemento.reverse
end
lista = ["sergio","roberto", "iuri","luiz"]
mostra_elementos(lista)
mostra_elementos_ao_contrario(lista)

Pronto! Com este método que acabamos de criar eliminamos o problema de  repetição de código. Porém ao executar este programa receberemos uma mensagem de erro. O grande problema aqui é que agora os métodos mostra_elementos e mostra_elementos_ao_contrario não conseguem mais acessar cada elemento do array. Estes métodos agora usam a função percorre_array, e somente dentro desta função é que a variavel elemento existe. Neste ponto podemos pensar que, ou fazemos a coisa ficar DRY, ou fazemos o programa funcionar. Calma, com Ruby nos poderemos fazer isso funcionar e ainda ser DRY. Para isso só precisamos aprender a usar os famosos blocos do Ruby.

Ruby block's

Com certeza você já ouviu, que tudo em ruby é objeto. Na verdade mesmo, quase tudo em Ruby é objeto, por exemplo blocos de código não são objetos. Mas o importante é  que  em Ruby podemos armazenar trechos de código em um objeto especial que se chama Proc. Veja:

bloco = Proc.new { puts "sou um bloco de codigo" }
bloco.call

Acabamos de criar um objeto, que contem código, e fizemos isso utilizando Proc.new e fornecendo o código através das chaves  "{ }". De posse de uma Proc, podemos executar o código que ela contem a qualquer momento. Basta pra isso usar o método call da Proc. No exemplo acima ao chamar bloco.call veremos o texto sou um bloco de codigo. O interessante disso é que agora podemos passar código como parametro, veja um exemplo:

def faco_o_que_mandar( block )
  block.call
end
bloco = Proc.new {puts "sou um bloco de codigo"}
faco_o_que_mandar(bloco)
faco_o_que_mandar Proc.new{puts "Mais um bloco"}

Mas podemos fazer como os rubistas fazem na maioria das vezes. Eles chamam a função e passam o bloco como parametro, para isso precisamos fazer uma pequena alteração em nossa função, basta colocar um & a frente do nome do nosso parametro. Outra coisa é que geralmente os rubistas utilizam a plavara yield ao invés de coisas como bloco.call, vamos mudar isso também:

def faco_o_que_mandar( &block )
  yield
end
faco_o_que_mandar {puts "sou um bloco de codigo tipo rubista"}
faco_o_que_mandar do
  puts "blocos do end sao usados quando vc quer"
  puts "fazer coisas que precisem de mais de uma"
  puts "linha =)"
end

O grande barato é que agora escrevemos uma função que recebe e executa um código "visitante". Este é um recurso muito poderoso, e é graças a ele que vamos conseguir resolver o problema de percorrer um array para fazer coisas diferentes com seus elementos, sem precisar repetir código.

Tirando vantagem dos blocos

Bem, nós já temos uma função que sabe andar em um array. Agora só precisamos fazer esta função receber um bloco de código "visitante" e assim teremos tudo resolvido. Vamos então ao trabalho:

def percorre_array( array, &block )
  for elemento in array
    yield
  end
end
lista = ["sergio","roberto", "iuri","luiz"]
percorre_array(lista) { puts elemento }
percorre_array(lista) { puts elemento.reverse }

Neste momento você pode estar se perguntando o porquê do bloco de código estar fora dos parênteses. Por mais estranho que possa parecer é desse jeito que funciona mesmo. Os blocos são informados depois dos parametros "convencionais".

Agora seria ótimo se isso funcionasse, não é? Pena que não vai funcionar. Ao executar esse código veremos o seguinte erro: undefined local variable or method `elemento' for main:Object (NameError).

Repare no erro, ele diz que a variavel elemento não está definida. Isso aconteceu porque esta variavel é local do método percorre_array, ou seja só existe, e só é visivel naquele método. Nós precisamos manipular esta variavel, para que isto seja possível o método que possui a variavel precisa permitir que os blocos visitantes utilizem esta variavel. Fazer isso é simples, basta que no yield nos passemos a variavel em questão como parâmetro.

Quando colocamos o  yield na função é como se dissesemos: "Rode o codigo visitante agora". E quando colocamos a frente do yield parâmetros é como se dissessemos: "Ei código vistante, se você quiser pode usar estes caras aqui que eu tenho". Vejamos como fica isso no nosso codigo:

def percorre_array( array, &block )
  for elemento in array
    #agora estamos expondo a variavel elemento
    # para o codigo visitante
    yield elemento
  end
end
lista = ["sergio","roberto", "iuri","luiz"]
# uma pequena alteracao é necessaria aqui
percorre_array(lista) { |elemento| puts elemento }
percorre_array(lista) do |elemento|
  puts elemento.reverse
end

Agora sim o código funciona. A linha yield elemento, tem o efeito de enviar para o bloco visitante a variavel elemento como parametro. Assim a cada iteracao do loop for um novo valor é enviado ao código visitante através da variavel elemento. Com isso nosso trabalho está terminado, implementamos as funcionalidades solicitadas, sem repetir código, e de quebra aprendemos sobre DRY e blocos de código em Ruby.

Bloco de código é um assunto bem interessante, e aqui nós abordamos só uma pequena parte. Tem ainda um lance de lambdas, enfim como disse antes o assunto é muito interessante, e se você quiser saber mais pode olhar um post do Anderson Leite sobre isso, o link é este.

Abraços.

Bom artigo amigo, porém penso que esteja havendo alguma confusão sobre o que é “tipagem forte” e o que é “type casting implícito”, em minha opinião a linguagem é fracamente tipada, haja visto que se pode atribuir uma referência de qualquer TIPO de objeto a uma variável, porém a linguagem não realiza o TypeCasting de tipos de forma implícita e arbritária como caso de algumas “Linguagens Chatas” (tomei a liberdade de utilizar seu termo…).

Como o post era antigo acabei demorando para ver o comentário e consequentemente enviar uma respota, porém o comentário aborda um assunto tão interessante, que resolvi escrever um post para esclarecer o assunto, por tanto gostaria antes de mais nada  agradecer o seu comémtario, e aqui vai a minha resposta

O Fato de não precisar definir um tipo para uma variavél, não é necessáriamene uma caracterísica de uma tipagem fraca, pois quando estamos atribuindo algo a uma variável, estamos apenas passando uma refêrencia, por exemplo:

nome = "Iuri"
puts nome
>> "Iuri"

O que eu fiz no exemplo acima, foi atribuir a instancia de um objeto do tipo string a variavel nome, não preciso dizer que a variavel nome é do tipo string, isso é uma característica de uma linguagem dinâmica. porém as vezes as pessoa confundem isso com tipagem fraca por causa do exemplo abaixo:

 nome = "Iuri"
 puts nome
>> "Iuri"
 nome = 1
 puts nome
>> 1

Nesse exemplo o que eu fiz foi atribuir a referência de um objeto string "Iuri" para a variavel nome, imprimir seu valor na tela, em seguida atribui a referência de um objeto FixNum 1 para o varivel nome e imprimir o seu valor. O fato de eu conseguir passar um valor string para uma variavel e em seguida um valor FixNum, não quer dizer que a minha linguagem tem tipagem fraca, ruby tem tipagem implicita o que é bem diferente de tipagem fraca, o minha variavel apenas trocou de referência no processo acima e por ela ser dinâmica automaticamente trocou de tipo.
Agora vamos ver outro exemplo para provar de vez que Ruby possui tipagem forte:

nome = "Iuri"
soma = nome + 1
>> TypeError: can't convert Fixnum into String

Viu?? deu erro!
Isso por que Ruby tem tipagem forte, eu não posso somar um objeto do tipo string com um objeto do tipo FixNum. Isso é tipagem forte
Se excutarmos o mesmo algoritimo em javascript ,que esse sim possui tipagem fraca, o resultado seria bem diferente:

  nome = "Iuri"
  soma = nome + 1
  document.write(soma)

O resultado desse exemplo será Iuri1

Referencias:

http://en.wikipedia.org/wiki/Type_system#Duck_typing

http://en.wikipedia.org/wiki/Type_system#Dynamic_typing

http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing

Estrutura

O Método em Ruby é declarado da seguinte forma:

def nomeDoMetodo
   #código
end

Só isso?
Não tenho que dizer o que ele retorna?
Ou dizer que ele não retorna nada "void" ?
É isso mesmo, no Ruby você não precisa definir o que o seu método retorna, também não temos obrigação de utilizar "return" o nosso método sempre vai retornar o ultimo valor atribuído.
É tão simples que deve ter ficado difícil de você visualizar:). Vamos ver um exemplo:

# criando um método chamado teste
def teste
  valor = 1
end
#chamando esse método
teste
=> 1

Parâmetros

O modo de passar parâmetros para um método em Ruby, é quase parecido com o das linguagens chatas:

 def nomeDoMetodo(parametro1,parametro2)
    valor = parametro1 + parametro2
 end

Ok! a similaridade com as linguagens chatas para por aqui.
Uma das coias legais de se trabalhar com uma linguagem dinamica é essa, note que não precisamos definir tipos para o parâmetro, isso nos da uma grande flexibilidade!
Você não acha?
Não!? e se eu disser para você que a flexibilidade não se limita a isso, e se eu disser que podemos também, passar um numero indeterminado de parâmetros para o nosso método?
você não acredita? vamos ver um exemplo então:

  # note como declaro o parâmetro no método
  def teste(*parametros)
    parametros.each { |parametro| puts parametro }
  end
  #chamando o método
  teste(1,2,3)
  1
  2
  3
  => [1,2,3]

Para finalizar esse post, vou dar um exemplo que os programadores Delphi vão adorar.

Caramba senti muita falta disso, quando comecei a programar em Java

Nos métodos em Ruby é possivel definir um valor default para o parâmetro. Heeeee!!!

  def teste(parametro="Não foi passado nenhum valor")
    parametro
  end
  teste("novo valor")
  => novo valor
  teste
  => Não foi passado nehum valor

pode falar... agora eu consegui te impressionar!

Por enquanto vamos ficar por aqui, mas ainda temos muito para ver sobre métodos em Ruby.
Aguardem o próximo post.

Abraço!

Iuri Menescal

Mas depois de publicar o último post, tive um retorno tão bom que fiquei empolgado em escrever outro logo .
Alem disso, fiquei com uma sensação de que estava faltando alguma coisa, como disse antes o foco não é mostrar os métodos de cada classe do Ruby, mas o Array em Ruby é tão maneiro que eu tinha que mostrar mais algumas coisas legais.

No post anterior eu disse que uma das coisas que me desanimou no Array, quando comecei a programar, era a dificuldade de recuperar os dados, então aqui vai mais alguns exemplos de como o Ruby resolve esse problema:

Ordenação

1
2
3
4
5
6
7

#o método sort ordena os valores em ordem alfabética
meuArray = %w(Alagoas Rio\ de\ Janeiro Brasília) 
=> ["Alagoas","Rio de Janeiro","Brasilia"]
#presto atenção na "\" para escrever algo com espaço dentro do mesmo item do array?
#agora vamos ordenar por nome
meuArray.sort
=> ["Alagoas","Brasilia","Rio de Janeiro"]

Grande coisa o exemplo acima, qual é a linguagem que não faz isso, né?
Então, vamos jogar um pouco do pó mágico do Ruby e deixar o próximo exemplo mais atraente.

1
2
3
4
5
6
7
8
9

meuArray = ["Alagoas","Brasilia","Rio de Janeiro"]
=> ["Alagoas","Brasilia","Rio de Janeiro"]
#olha o que podemos fazer acrescentando um bloco no final
#vamos ordenar ao contrario agora 
#mas lembre-se que você pode passar N condições 
#pois estamos trabalhando com blocos!
 
meuArray.sort {|x,y| y <=> x}
=> ["Rio de Janeiro", "Brasília", "Alagoas"]

Pesquisa

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

estados = ["RJ","MG","SP"]
=> ["RJ","MG","SP"]
#Quero confirmar se nesse Array 
#realmente existe o estado "Rio de Janeiro"
estados.include?("RJ")
=> true
 
#Agora queremos saber se algum item do meu array possui a letra "S"
estados.any? { |item| item.include?("S") }
=> true
#e se eu quiser saber se todos os itens do meu array possui a letra "S"?
#simples!
estados.all? { |item| item.include?("S") }
=> false
 
#quero separar do meu array os estados com letra "S"
estadosComS, estadosSemS = estados.partition { |item| item.include("S") }
estadosComS
=> ["SP"]
estadosSemS
=> ["RJ","MG"]

Olha só que linguagem linda! Notem a expressividade desse código: "include?"
Eu quero saber se o meu array de estados contem o estado "RJ". Se eu quero saber algo sobre o meu array, eu tenho que perguntar para ele e uma pergunta deve terminar com interrogação, então: estados.include?("RJ").

Pode falar... da vontade de congelar esse projeto, que você ta desenvolvendo ai na sua empresa e reescreve tudo em Ruby, não é? rs...

Mais uma vez utilizei bastante o conceito de blocos, que é um dos grandes baratos do Ruby.

Logo irão surgir outros conceitos que vão me obrigar a ter a mesma postura, no próximo post vamos ver um pouco sobre lambdas, que é um outro recurso bem bacana.
É importante fixar bem esses conceitos para programadores que vem de linguagens como Java, Delphi, C#, pois é mais difícil se acostumar com algo tão fora do trivial do seu dia a dia, é importante isso ficar na "veia", para que você consiga lembrar de utilizar esses tipos de recursos quando precisar. Tenho certeza que isso vai facilitar muito a sua vida quando estiver programando em Ruby.

Acho que agora deu para fechar com chave de ouro o nosso estudo sobre arrays.

Até a próxima!

Iuri

Acho que agora as coisas começam a ficar mais divertidas

Não é minha intenção, ficar explicando cada classe básica do Ruby, acho que mais importante focarmos no conceito da linguagem, acredito que a melhor forma de aprender a programar é praticando, por tanto vou usar alguns exemplos utilizando funcionalidades da String e do Array, para explicar os conceitos e ao mesmo tempo mostrar como é produtivo programar em Ruby.

Para entender os recursos de cada classe, basta olhar a documentação do Ruby que é bem abrangente.

Vamos ver alguns exemplos, de como podemos concatenar valores em uma string:

variavel = "um dois tres"
variavel = variavel+" quatro cinco seis"
 
#pode ser assim também
variavel = "um dois tres"
variavel += " quatro cinco seis"
 
#Também podemos fazer assim
variavel = "um dois tres"
variavel.concat(" quatro cinco seis")
 
#ou melho ainda, esse é muito maneiro, o código fica claro!
variavel = "um dois tres"
variavel << " quatro cinco seis"
#alem de claro, esse tipo de atribuição é mais rápido.

Viu por que Ruby é agil?
- Até minha mãe entende que com esse simbolo "<<" estou inserindo uma valor na String
É claro que em java temos outros modos de concatenar valores em uma String, mas provavelmente alguns deles nos obriga a instanciar alguma classe utilitária como o StringBuilder, por exemplo.

Gostou? você ainda não viu nada, olha só que F0D@! :p

Delete

#aqui eu quero remover todas as vogais de uma String
"a b c d e f g h i ".delete "aeiou"
=> "b c d f g h"
 
#podemos utilizar exceções.
#vamos remover todas as vogais, exceto a vogal "i"
"a b c d e f g h i".delete "aeiou", "^i"
=> "b c d f g h i"

Quer ver mais?

#Conversão de case
"saga do programador".upcase
=> "SAGA DO PROGRAMADOR"
"SAGA DO PROGRAMADOR".downcase
=>"saga do programador"

#olha só que maneiro:
#veja como esse código é expressivo!
"saga do programador".include? "programador"
=> true
#é esse tipo de coisa q faz a diferença
#quero saber quantos caracteres diferentes existem entre as Strings
"Iuri" <=> "Iure"
=> 1
#agora eu quero tirar caracteres duplicados de uma String
"google".tr_s("o","o")
=> "gogle"
"google".tr_s("o","")
=> ggle

Arrays:

Na boa! Quando comecei a programar, aprendi sobre Arrays com o velho Pascal, achei muito chato. Pelas dificuldades apresentandas para recuperar os dados.

Com a evolução das linguagens as coisas foram melhorando, mas definitivamente trabalhar com Arrays em linguagens dinâmicas, supera as expectativas!

Vamos aos exemplos:

#Criando uma array em Ruby:
meuArray = [“um”, “dois”,3]
=> [“um”,”dois”,3]
#Sim é isso mesmo! Eu posso ter tipos diferentes dentro do mesmo Array

Olha com as coisas ficam ainda mais legais, quando nos aproveitamos das facilidades que a linguagem Ruby nos proporciona com o conceito de blocos:

meuArray = Array.new(2) {1}
=> [1,1]

Alguma vez você imaginou preencher um Array de maneira tão simples, como no exemplo abaixo:

meuArray = Array.new(5) {|n| n+1}
=> [1,2,3,4,5]

No post anterior eu finalizei com a seguinte pergunta:
Tenho uma String com seguinte valor “um dois tres quatro cinco”, como você faria em uma linguagem chata para transformar essa String em um array contendo cinco itens?

Bom, existe N maneires de fazer isso em N linguagens, meu exemplo de linguagem chata, será em delphi, vamos a roubada rs.. :

//Para facilitar, ao invés de utilizar um Array, vou usar a classe TStringList.
Var
  valor: String;
  listaValor: TStringList;
begin
  valor := 'um dois tres quatro cinco';
  listaValor := TStringList.Create;
  valor := StringReplace(valor,' ',',',[rfReplaceAll]);
  listaValor.CommaText := valor;
end;

Agora em Ruby:

#Preste atenção como é complexo rs...
meuArray = %w(um dois tres quatro cinco)
=> [“um”,”dois”,”tres”,”quatro”,”cinco”]

Outros exemplos:

#Sim! O operador "<<" também funciona para o Array
 
meuArray = [1]
=> [1]
meuArray << 2
=> [1,2]

No incio desse topico sobre arrays, comentei que um dos grandes problemas de trabalhar com Arrays nas linguagens chatas, e a dificuldade para manipular os dados, vamos ver agora uma pequena amostra, das facilidades que o Ruby nos oferece para trabalhar com isso:

meuArray = [1,2,3,4,5]
=> [1,2,3,4,5]
 
#Retornar só os numero pares, mais uma vez vou me prevalecer do conceito de blocos.
 
arrayPares = meuArray.select{ |valor| valor%2==0 }
=> [2,4]

Bom, por enquanto é só!
Acho que agora as coisas estão ficando mais com a cara do Ruby, pois deixamos de lado o bla bla e passamos para a pratica, algo mais produtivo, talvez você ainda não tenha notado, mas nesse post conseguimos trabalhar bastante um otimo conceito do Ruby que são os blocos. A intenção daqui para frente é utilizar exemplos de códigos, para expressar os conceitos das funcionalidades que essa maravilhosa linguagem nos proporciona

Até a próxima!

Iuri Menescal

Eu sei que não é um assunto muito empolgante, ou melhor não é muito "Ruby" (ou seja Dinamico, Agil, Divertido), mas para ter um bom entendimento temos que consolidar os fundamentos.
"Espero que o Luiz não leia isto rs.. "piada interna" hehe!"

Mas logo logo vamos entrar na parte legal, pense nessa fase como o primeiro periodo da faculdade, só que com mais serventia

Como falei anteriormente tudo em Ruby é objeto. Variaveis são apenas referencias para objetos e bla bla bla bla...

Vamos ver mais alguns exemplos:

Viu? o valor1 ficou com o mesmo valor2, isso por que as duas variáveis são referencias para o mesmo objeto.
Note que eu alterei a variável "Var2[5] = 2" ao invés de atribuir um outro valor para ela "var2 = valor2", nesse ultimo caso eu estaria atribuindo um novo objeto String para a variável var2.
Mas isso você já sabia né? hum... Você lembra de todo aquela papo de linguagem dinâmica e tipagem forte do primeiro post? Não? putz.. seu fanfarrão! da uma olhada lá novamente: post1

Existem métodos que nos ajudam a manipular variáveis, como o método freeze que congela a variável e não permite que ela seja alterada.

Outro método legal é o método dup:

variavel1 = "Valor1"
variavel2 = variavel1.dup

Esse método deveria ser usado no exemplo anterior, para impedir que as duas variáveis ficassem com a mesma referencia.

Operadores

Grande parte dos operadores são métodos e podem ser alterados.

+,-,*	adição,subtração,multiplicação
/,%	divisão,resto
**	Expoente
&	AND binario
^ ou |	OR binario
>,>=,<,<=	maior, maior ou igual, menor, menor ou igual
<=>,==,===,!=, =~, !~	Operadores de igualdade, você vai entender melhor nos próximos post`s
=, %=, -=, +=, /=,*=,**=, ||=, &&=, <<,	Atribuição
Lógicos
&&	AND
||	OR
.. e ...	Ranges
? :	If Then else "Adoro esse "
not	negação
or e and	composição

Durante nosso aprendizado, vamos ter oportunidade de ver mais detalhes de alguns operadores.
Ai você vai começar a entender por quê programar em ruby é tão legal

Só para deixar esse post menos chato, vamos ver um exemplo:

#só quero atribuir um valor quando a variável for nil
variavel = 1
=> 1
variavel ||= 2
=> 1
variavel = nil
=> nil
variavel ||= 2
=> 2
#agora o oposto
variavel = 1
=> 1
variavel &&= 2
=> 2
variavel = nil
=> nil
variavel &&= 1
=> nil

Por enquanto é só, tenho certeza que já no próximo post, as coisas vão ficar mais empolgantes, ainda essa semana vou publicar a terceira parte aonde vamos ver alguns detalhes da classe String.
Não deixe de continuar acompanhando, agora já passamos pela pior parte, o que vem pela frente é só diversão tenho certeza que do decorrer dos exemplos que estão por vir você vai dizer algumas vezes "Caramba! que f0d@!!" :p

Fica aqui uma charada para o próximo post:

Tenho uma String com seguinte valor "um dois tres quatro cinco", como você faria em uma linguagem chata para transformar essa String em um array contendo cinco itens?

Abraço!

Iuri Menescal
Diga não as drogas, não use IE!

Muitos se animaram e assim como eu estão estudando esse framework, mas uma coisa que venho notando é que as pessoas que querem aprender Rails, começam a estudar Rails sem nunca ter visto Ruby.

Isso é um erro comum e que demora para ser percebido, por conta da facilidade e da agilidade do Rails em gerar resultados logo no primeiro dia de estudos, o que acaba causando uma falsa impressão de evolução e te transformando em um "Code monkey".

Acabamos escrevendo código sem saber o significado, e convenhamos para que vem de linguagens como (Delphi, C#, etc..) é um mundo completamente diferente.
(No decorrer dessa sequencia de post`s vou ser obrigado a citar novamente esse exemplo, por isso vamos utilizar o termo "Linguagens chatas" )

Pode parecer meio radical, mas antes do fim dessa série você vai notar, que alem de tudo Ruby é divertido!

É muito normal uma pessoa que só desenvolve em Linguagens chatas ter dificuldade para entender o código abaixo:

    sexo = "M"
   nome = "Iuri"
   puts "Ola " << "sr#S#".gsub(/#S#/,sexo == "F"?"a.":".") << nome

Pode apostar, o resultado desse códito seria: "Ola sr. Iuri"

Por isso resolvi publicar uma serie de artigos falando mais sobre Ruby.
Então já para dar inicio, vou terminar esse post com uma breve explicação.

O que é Ruby?

Ruby é uma linguagem dinâmica e de tipagem forte para programação OO.
Na verdade Ruby é muito mais do que isso, mas isso você vai descobrir no decorrer dos nossos estudos.

O Ruby foi inventado por Yukihiro Matsumoto.
É uma linguagem totalmente livre, (Usar, Copiar, Modificar...)

O Ruby é uma linguagem 100% orientada a objetos, tudo em Ruby é objeto, qualquer variável em Ruby aponta para um objeto.

Por exemplo:

Exemplo de Classe

Quer mais provas?

O atributo "methods" exibe todos as funções disponíveis na classe

Como eu disse no inicio o Ruby possui tipagem forte, vamos ver um exemplo:

"Ué você não falou que tem tipagem forte? como eu consegui atribuir uma string em um numérico?"
Sim tem tipagem forte, como eu disse no inicio, variaveis são referencias para objetos, nesse caso eu apenas apontei a variavel para um novo objeto.
Agora vamos ver o exemplo abaixo:

Bom, por enquanto é só. No próximo post vamos começar a colcar a mão na massa, ai sim você vai começar a descobrir como Ruby é divertido

Abraço!

Iuri Menescal
Diga não as drogas, não use IE!

Cedendo ao convite do Luiz, vou escrever a minha retrospectiva também. Trabalhamos na mesma equipe e isso pode tornar o que vou escrever uma cópia do post dele, já que isso pode acontecer, vou colar alguns trechos aqui na cara de pau mesmo hehehehe!

Post do Luiz

O ano de 2008 foi um ano muito bom profissionalmente, neste ano consegui mudar de tecnologia no meu trabalho, consegui aplicar algumas das principais técnicas que estudo há alguns anos.