Resumo do Curso CSPO – Primeiro dia

Já faz algum tempo que não publico nada aqui no meu blog, bem acho que inicialmente preciso compartilhar a minha felicidade de estar já a três meses na Locaweb, que além de uma empresa competitiva no ramo de serviços de internet (Líder na prestação de serviços hospedados de TI), também é um excelente lugar para trabalhar.

Entre os vários benefícios e atrativos que a empresa oferece, tais como um excelente ambiente de trabalho, desafios constantes e etc., ela também investe pesado em treinamento e aprecia ter pessoas ligadas a comunidade de software no seu quadro de colaboradores.

Nesse espírito de investir nos seus funcionários a Locaweb custeou a ida de algumas pessoas para o Agile Brazil 2010 em Porto Alegre e além disso possibilitou que algumas pessoas fizessem alguns cursos e é aí que eu entro, eu fui um dos premiados a fazer o curso do CSPO (Certified Scrum Product Owner)!

O curso foi excelente, ministrado pelo Alexandre Magno com o parceria do Luiz C. Parzianello, apesar de o formato do curso com dois “Mestres de Cerimônia” não tenha ficado tão bom quanto o esperado, a integração dos assuntos abordados pelos dois foi excelente!

Para saber mais informações de como foi o dia a dia do curso, recomendo a leitura do post de um amigo que fiz lá o André Nascimento e de meu amigo locaweber Rafael Rosa Fu.

A partir de agora vou repassar um pouco do resumo que fui fazendo ao longo do curso, espero que aproveitem!

• PO – todas as empresas tem problemas com esse papel do Scrum.

Uma das primeiras frases do Alexandre Magno no curso foi que o papel do PO é um papel que merece mais atenção nas empresas pois ainda muita falta de experiência para executá-lo.

• No início havia muito foco no papel do time.

Focava-se muito esforços no papel do time (Integrantes do time + Scrum Master) e agora é o momento de focar-se mais no papel do PO.

• Nada adianta um bom time se o produto está sendo desenvolvido errado.

Aqui o recado é que não adianta ter ótimos técnicos no seu time e um Scrum Master excelente em facilitação, se o produto desenvolvido não estiver focado nas necessidades do cliente.

• Pouco adianta práticas de engenharia para o produto errado.

Vale o mesmo recado da sentença anterior, TDD, Pair Programming, Continuos Integration pouco terão valor se o produto está errado no aspecto de negócio.

• Devemos focar mais esforço no negócio.

Nossos esforços devem estar mais direcionado a atender as necessidades de negócio.

• Pouco material técnico e mais práticas para deixar as pessoas mais focadas (curso).

Aqui foi uma frase que me chamou atenção, onde o Alexandre Magno deixou claro que o foco dele seria nas práticas e não em apostilinhas!

• Discussão do gerente de produto na (sua) empresa. Quais são as atribuições do Gerente Produto?

Neste momento tivemos uma excelente discussão de qual seria o papel do Gerente de Produtos, se quiser saber a conclusão faça o curso !

• Onde o GP e o PO se encontram (papéis)?

Outra excelente discussão, onde falamos muito sobre a intersecção do papel do PO e do cargo Gerentes de Produtos.

• Scrum foi pensado para projetos e não para empresas.

O Magno deu um recado que apesar de muito claro, tem muita gente que ainda não compreende que é o Scrum foi pensado para projetos e não para gestão de empresas! Ele foi bastante enfático nesse momento.

• PO é um papel do projeto e não da empresa… o GP é um cargo na empresa.

Mais um recado muito claro do Magno, o PO é um papel e o gerente de Produtos é (deveria ser) um cargo na empresa.

• A necessidade de um PO inicia quando o projeto inicia, não antes!

Não deveria ter PO eternos na empresa, a necessidade de um PO inicia quando o projeto inicia e não antes!

• Se não há projeto, não há Product Owner.

Resumindo: “Se não há projeto, não deveria haver Product Owner!”

• Time de alto desempenho as vezes não entregam valor por causa do PO ruim.

Um cruzado de direita do Magno, mesmo tendo um time de alto desempenho é muito provável não entregar nada de valor caso o PO for muito ruim.

• No mundo perfeito, todo PO será do cliente.

O ideal seria que o PO sempre fosse do cliente, ou seja, muito ligado ao produto, mas nem sempre isso é possível.

• De nada adianta um PO do cliente se ele não priorizar, ou priorizar mal.

Porém de nada adianta um PO do cliente se ele não for hábil para priorizar ou na pior das hipóteses priorizar mal.

• Mais difícil é encontrar lideres com objetivos do que times auto gerenciados.

Esta sentença para mim está muito ligada ao que o Magno disse no início do curso, muito foi focado no time, agora é muito mais fácil encontrar times auto-gerenciados do que lideres com objetivos bem definidos.

• O comum é lideres com time sheeting do que com objetivos claros.

Em muitas empresas que se auto denominam “Ágeis”, na verdade é comum encontrar liderem com um o gráfico de gantt e planilhinha de horas!

• PO deve ter um cuidado com o product backlog.

O product backlog deve ser um filho para o PO, que deve cuidar, proteger, defender !

• PO desenvolve a visão do produto e os passos para atingir o objetivo da visão.

A tão falada visão do produto deve ser desenvolvida pelo PO assim como os passos para atingir o objetivo determinado na visão.

• O macro management fica na mão do PO.

O macro management fica a cargo do PO, verificando as features e os releases numa perspectiva macro para atingir o objetivo do produto.

• O passos para atingir o objetivos das estórias (micro management) fica a cargo do time.

Já o micro management fica com o time, ou seja, os passos (tarefas) para atingir o objetivo da sprint.

• O PO tem que realmente ser um porco do projeto (é difícil ser porco em dois projetos).

O recado aqui é que é difícil dar o sangue (couro no caso do porco, ) em mais de um projeto, o PO sempre tem que se perguntar se será capaz de focar no projeto antes de ingressar nele.

• Scrum é incompleto e não precisa somente de práticas de engenharia, existem outro pontos (análise de risco, controle).

Aqui um recado do Parzianello, todos sabemos que o Scrum é incompleto, mas não é somente pela falta de práticas de engenharia, na verdade também lhe falta análise de risco e outras disciplinas ligadas ao negócio.

• Scrum é controle! (reunião diária, review, definition of done).

Apesar de soar muito estranho, mas Scrum é controle! Reunião diária, Review, Definition of Done, são provas que há sim, muito controle no Scrum, o que não tem é Comando!

• É interessante o time ter um integrante como Scrum Master exclusivo.

Sempre que possível é interessante ter um protetor do Scrum e do time, esse papel responde pelo nome de Scrum Master, mas claro, se o time for maduro a ponto de achar interessante que esse papel possa ser executado por um integrante do time não há problemas.

• Quais são os seus valores?

Aqui mais uma discussão aberta pelo Magno: Qual são seu valores? O que realmente importa para você?

• Dá para estimar o valor e o tempo com práticas ágeis?

Mais uma discussão sobre a possibilidade de se fazer estimativas de valor e de prazo com práticas ágeis, mas com certeza deverá haver uma quebra de paradigmas de quem for fazer a estimativa, bem como de quem for recebê-la.

• Product roadmap com práticas ágeis tem que quebrar paradigmas.

Ainda relacionado com a sentença anterior, deve-se quebrar paradigmas para se executar, receber e interpretar um product roadmap com práticas ágeis, caso contrário será difícil ter sucesso no projeto.

• Todo o ambiente de projeto deveria entender o que é Scrum para ter sucesso (principalmente patrocinadores e clientes!).

Essa é mais uma sentença auto explicativa, para ter sucesso todo mundo tem que compreender o Scrum!

• Premissa para o PO: você realmente tem disponibilidade para esse papel?

Ou seja, ou você estará disponível, envolvido ao projeto, caso contrário esse papel de PO NÃO é para você. Simples assim!

• Atribuições do PO

Definir a visão (com workshops etc.)
Manter o product backlog
Maximizar o ROI
Gerenciar, planejar release
Define as metas
Leva as informações do projeto para fora (divulgar o projeto)
Gerenciar conflitos de cliente, prioridades
Fazer gerenciamento macro
Bastante coisa, não?

• Meta: ou atingiu ou não atingiu!

Simples, atingiu a meta ou não atingiu a meta, não existe meia meta!

• PO sem poder de decisão ou com baixa disponibilidade ou que não foi preparado para exercer o papel.

Com um PO nessas condições será praticamente impossível ter um projeto de sucesso, ou se mitiga esses riscos ou é melhor nem iniciar o projeto.

• PO deve estar próximo no momento de quebrar tarefas.

E muito importante o PO estar próximo (sempre que possível) quando se for quebrar as tarefas, para auxiliar o time, para que essa atividade tenha o máximo de precisão possível.

• QA junto com PO para descobrir estórias e definir critérios de aceitação.

Outra dica do Magno, ter o QA próximo do PO no momento de descoberta de estórias e na definição dos critérios de aceitação.

• A cada review deve ser apresentado o que foi gerado para entregar aquele release!

Esse foi um soco de esquerda, a cada review o time deve apresentar o que foi gerado para entregar aquele release, mas também é importante que o PO tenha em mãos tudo para o próximo release que será desenvolvido.

• Retrabalho nível 2 – problemas intrínsecos do projeto nível 1

Aqui eu não me lembro, assim que eu lembrar atualizo aqui (poxa, o curso era de manhã!)

• Prestar atenção e conhecer Lean!

Apesar de neste momento o Magno e o Parzianello estarem falando de Lean, fica a dica de também prestarem atenção ao Kanban.

• Proteger receita e diminuir custo.

Aqui uma dica no Parzianello que fez a diferença, nós sempre pensamos no produto para aumentar as receitas ou lucros, mas muitas vezes poderíamos estar focados em proteger a receita atual e diminuir o custo. Esta discussão iniciou quando eu trouxe um problema enfrentado pelo meu time, sobre como eliminar o legado e entregar valor, nós não conseguíamos ver a possibilidade disso, mas na verdade o que nós queriamos era proteger a receita da empresa (manter os produtos atuais) porém diminuir o custo (software funcionando, manuteníveis, extensíveis com o mínimo possível de bugs), resumindo entregando valor sim!

• As vezes não é debito técnico, mas sim melhoria tecnológica.

Ainda na discussão anterior, as vezes não podemos encarar tudo como débito técnico, mas sim melhoria tecnológica que na verdade também é entrega de valor.

• Técnica Elevator Statement para definir a visão do produto.

Aqui fizemos uma excelente dinâmica para definir uma declaração que define a visão do produto, mais informações no curso.

• Desenvolver o product vision box.

Outra dinâmica show, foi o desenvolvimento do product vision box, o melhor, além da técnica e a explicação do Magno é claro, foi a integração com as outra pessoas que estavam fazendo o curso conosco. Foi um momento super descontraído e divertido!

E assim terminamos o primeiro dia do CSPO e agora fico devendo o segundo post, até lá!

Duck Typing Club

Sempre que pessoas que não conhecem o Duck Typing se deparam com esse estilo de programação torcem o nariz como um sinal de descrença.

- Ah, mas na minha linguagem é mais seguro, é muito mais claro saber o tipo de objeto.

Ok, na sua linguagem tem suas vantagens, mas o duck typing também tem as suas. Vamos a um exemplo numa linguagem que não faz parte do Duck Typing Club:

import java.io.*;
public interface Musica{

	void setNome(String nome);
	String getNome();
	void setArtista(String artista);
	String getArtista();

	void adicionaParaArquivo(File arquivo);
}

O exemplo é simples, dada uma música queremos adicioná-la a um arquivo, como bons programadores, vamos escrever o código de teste.

import java.io.*;
public class MusicaTest{

	@Test
	public void testAdicionarMusicaParaArquivo(){
		File arquivo = new File("arquivoTest.txt");
		Musica musica = new MusicaImpl("Sex Machine","James Brown");
		musica.adicionaParaArquivo(arquivo);

		...

	}

}

Vamos parar de escrever esse código por aqui, não aceitaremos ninguém que estiver fora do club!
Percebam que como a interface diz que o método recebe um File, nós precisaremos passar um arquivo para ele!
Um arquivo é um recurso relativamente barato, mas em outros casos escrever esse teste não seria uma tarefa tão fácil.

Classes não são Tipos

Apesar das linguagens estaticamente tipadas nos fazerem acreditar nisso, mesmo nelas, o tipo de um objeto muitas vezes é um conjunto de classes!
Mas em Ruby, definitivamente, uma Classe não é um tipo de objeto, ao inves disso, em Ruby um objeto é definido pelo o que ele é capaz de fazer. Se ele anda como um pato, fala como um pato, dança como um pato, tem como amigo um rato, então ele é o Pato Donnald!

Vamos agora para o exemplo de um integrante do Duck Typing Club o Ruby!

class Musica
  def initialize(nome, artista)
    @nome = nome
    @artista = artista
  end

  def adiciona_para_arquivo(arquivo)
    arquivo << @nome << " - " << @artista
  end
end

Novamente, como pragmáticos que somos, já temos o teste para esta unidade de código:

require 'test/unit'
require 'musica'

class TestMusica < Test::Unit::TestCase
  def test_adiciona_para_arquivo
    musica = Musica.new("Sex Machine", "James Brown")
    arquivo = File.open("musicas.txt","w") do |f|
      musica.adiciona_para_arquivo(f)
    end

    File.open("musicas.txt") do |f|
      assert_equal("Sex Machine - James Brown", f.gets)
    end
  ensure
    File.delete("musicas.txt") if File.exists?("musicas.txt")
  end
end

Trabalhoso né? Tivemos que criar o arquivo, reabrir para leitura e assegurar que ele foi apagado no fim do processo, pensando como “Pato”, nós só precisávamos de um objeto que respondesse a “<<", não é mesmo?

Programando como um Pato

Veja agora esse exemplo:

require 'test/unit'
require 'musica'

class TestMusica < Test::Unit::TestCase
  def test_adiciona_para_arquivo
    musica = Musica.new("Sex Machine", "James Brown")
    arquivo = ""
    musica.adiciona_para_arquivo(arquivo)
    assert_equal("Sex Machine - James Brown", arquivo)
  end
end

E agora? Bem mais simples né, e como sabemos String responde a “<<", assim nosso teste funciona e fica muito mais simples, poderia até ser um Array, veja:

require 'test/unit'
require 'musica'

class TestMusica < Test::Unit::TestCase
  def test_adiciona_para_arquivo
    musica = Musica.new("Sex Machine", "James Brown")
    arquivo = []
    musica.adiciona_para_arquivo(arquivo)
    assert_equal(["Sex Machine"," - ","James Brown"], arquivo)
  end
end

Mas você, cético que é, apesar de codificar com uma linguagem que faz parte do Clube, ainda assim tem motivos mais que plausíveis para dizer que precisa verificar o tipo do objeto recebido. Vamos ver se é isso que precisa:

class Musica
  def initialize(nome, artista)
    @nome = nome
    @artista = artista
  end

  def adiciona_para_arquivo(arquivo)
    unless arquivo.kind_of?(File)
      fail TypeError.new("Um arquivo era esperado")
    end
    arquivo << @nome << " - " << @artista
  end
end

Pronto, zuou tudo agora!!! Parabéns, se era isso que você queria, conseguiu!
Não né, você não é tão radical, a idéia era algo mais meio termo, vamos ver se é isso:

class Musica
  def initialize(nome, artista)
    @nome = nome
    @artista = artista
  end

  def adiciona_para_arquivo(arquivo)
    unless arquivo.respond_to?(:<<)
      fail TypeError.new("'arquivo' precisa responder a '<<'")
    end
    arquivo << @nome << " - " << @artista
  end

end

É, assim o testes passam, mas saiu do clube, mas ainda assim é bem melhor que o código anterior. Este você guarda para quando realmente for necessário, ok?

Então é isso, bem vindo ao Duck Typing Club!

Este post foi baseado na leitura do livro Programming in Ruby 1.9.

JMS e JRuby é com o JSparrow!

Quem já trabalhou com JMS sabe que esta API não é muito trivial para trabalhar com mensageria, mas com Java por mais que utilize um framework para abstrair a complexidade, nós sempre chegaremos bem próximos do JMS e conseqüentemente deixaremos nosso códigos complexos!

Bem com JRuby isso já não é um problema, existe um projeto que abstrai (onde é possível) a complexidade do JMS e torna nosso trabalho bem mais simples e sabem o melhor? É DO BRASIL!!!

JSparrow, é um projeto hospedado no github, está em pleno desenvolvimento e tem como idealizador Leandro Silva. Na última versão a 1.1.1 o projeto ganhou, entre outras features, a possibilidade de implementação de um Listener (tanto para filas e tópicos) e isto possibilitará a conclusão deste post.

Neste tópico vamos escrever um código clássico, para quem aprendeu JMS por livros com certeza já escreveu um Chat básico para ser usado na linha de comando, então, é isso que faremos agora.

O exemplo é muito simples, vamos criar um tópico em um Application Server, no meu caso foi no Weblogic, por que? Porque eu gosto de sofrer, oras! Depois vamos nos registrar nesse tópico e criar um listener para ficar escutando-o, tudo bem simples.

Então vamos ficar assim, o pré-requisito é que você tenha um provedor JMS, no meu caso como eu disse foi o Weblogic, mas eu não o recomendo, a escolha mais simples caso você não tenha experiência é o OpenJMS, o mesmo usado nos exemplos do JSparrow.

O exemplo escrito em Java pode ser visto no site onjava.com e o nosso veremos a seguir:

Instalando a gem

gem install jsparrow

Crie um arquivo chamado chat_com_jsparrow.rb.
Adicionando a gem ao exemplo:

require 'rubygems'
require 'jsparrow'

Recebendo parâmetros de linha e parametrizando a conexão com o provider.

$NOME = ARGV[0] if ARGV[0]

JSparrow::Connection.configure do |connection|
  # adicione aqui a lib do client do seu provider
  connection.use_jms_client_jar '/Users/alan/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.jar'

  # verifique as configurações do seu provider
  connection.use_jndi_properties :initial_context_factory => 'weblogic.jndi.WLInitialContextFactory',
                                 :provider_url            => 't3://localhost:7001',
                                 :security_principal      => 'weblogic',
                                 :security_credentials    => 'weblogic123'
   # o nome da factory e do topico que voce criou
  connection.enable_connection_factories :topic_connection_factory => 'ConnectionFactory'
  connection.enable_topics :chat_topic => 'MyTopic'
end

Iniciando a conexão e criando o sender para enviar as mensagens.

jms_client = JSparrow::Connection.new_client
jms_client.start
topic_sender = jms_client.topic_sender(:chat_topic)

Criando a implementação do listener.

class ChatTopicListener < JSparrow::Connection::Listener
   listen_to :topic => :chat_topic

   def on_receive_message(received_message)
      puts "#{received_message.text}"
   end
end

Registrando o listener e iniciando a “escutação” rs!

listener = JSparrow::Connection.new_listener :as => ChatTopicListener
listener.start_listening

Enviando as mensagens, começando a diversão!

texto = ""
while texto != "exit"
   print "Escreva seu texto: "
   texto = STDIN.gets.strip
   mensagem = texto
   mensagem = "#{$NOME} escreveu: #{mensagem}" if $NOME
   topic_sender.send_text_message(mensagem)
end

Finalizando.

listener.stop_listening
jms_client.stop

Fácil né? Vamos colocar para rodar!

bash$> jruby chat_com_jsparrow.rb Um_nome

E em outro terminal

bash$> jruby chat_com_jsparrow.rb Outro_nome

Escreva as mensagens e veja o resultado.

O JSparrow tem mais características interessante e avançadas, como por exemplo colocar critérios na seleção de mensagens no tópico ou em filas, então não deixe de acompanhar o projeto no github.

O código deste post pode ser encontrado no aqui, deixei o exemplo com seleção de mensagens.

Por hoje é só pessoal! Não esqueça de deixar seu comentário.

EJB 3.0 no Weblogic e JRuby, será que rola?

Não sei se todos aqui vem aqui no blog sabem, mas atualmente trabalho como Arquiteto de Sistemas da CVC Turismo, como não é o foco do post deixarei para falar sobre minhas atividades diarias outro dia !

Bem, entre o dia 23 e 24 de fevereiro (ontem e hoje considerando o dia que escrevi esse post) fiquei ajudando em um deploy e uma preparação de uma aplicação para uma apresentação. Entre um build, um deploy, uma leitura de um log, fiquei “rascunhando uns códigos”.

O que eu queria era fazer lookup de EJB de uma aplicação centralizadora de serviços de negócio que temos lá, com JRuby!
Considerando que quando migramos de OC4J para Weblogic (essa migração ainda está rolando) tivemos muito problemas com EJB’s, achei que eu não ia conseguir fazer esse tal lookup em 1 ou 2 horas, então fiquei nos código apenas para passar o tempo.
Acabei encontrando um post que me ajudou na brincadeira. E o resultado disso eu vou mostrar a seguir:

Primeiro o código Java para a gente entender o que foi feito:

import javax.ejb.*;
import javax.naming.*;
import br.com.cvc.systur.app.*;
import java.util.Calendar;
import java.util.GregorianCalendar;
import br.com.cvc.systur.domain.pessoa.*;
import br.com.cvc.systur.app.pessoa.*;
import br.com.cvc.systur.domain.pessoa.documento.*;

public class Client {
    public static void main(String[] args) throws Exception {
         Context ic = new InitialContext();
         Object obj = ic.lookup(ServiceCatalog.CONSULTA_PESSOA.getName());

         ConsultaPessoaService cps =(ConsultaPessoaService) obj;

          for(TipoDocumento tp : cps.consultarDocumentos()){
               System.out.println(tp.getDescricao());
          }
    }
}

Aqui já temos as “particularidades” do Weblogic aparecendo, como podem nós temos um catálogo com todos os serviços, não entrarei em detalhes, mas ele serve, além de outras coisas, para obtermos o nome do bidding do objeto na arvore JNDI, entenderemos melhor no código JRuby.

Este código obtém o EJB que representa um serviço de consulta de pessoas e utilizamos a operação consultarDocumentos para obter todos os tipos de documentos que trabalhamos, simples, muito simples!

Agora vamos ao JRuby

require 'java'
include_class 'javax.naming.InitialContext'

ic = InitialContext.new
teste = ic.lookup('systur-domainsystur-domain-ejb_jarConsultaPessoaServiceBean_ConsultaPessoaService')

tipo_docs = teste.consultarDocumentos

tipo_docs.each { |tipo_doc| puts tipo_doc.descricao }

Olhe o lookup, veja o nome de ligação padrão no Weblogic, sei que não é o foco do post, mas entendeu porque temos o nosso “Catalogo”, isso porque nem vou entrar nos detalhes de como fazemos versionamento dos nosso serviços!

Esse código em JRuby, mas exatamente a mesma coisa que o código em Java, obtém o EJB e utilizamos um método e imprimimos a descrições dos tipos de documento.

Terminada toda a diversão, o trabalho da madrugada foi feito e eu estou aqui agora, cheio de idéias, entre elas melhorar nossa base de testes (que é um debito técnico nosso!) e deixa-los mais expressivos com JRuby, ou mesmo validar a saúde de nossa aplicação em produção rodando um simples script e executar testes de em produção (audacioso)!

É isso, mais uma barreira do Weblogic quebrada e mais uns 100 pontos na balança do Ruby e do JRuby!

Primeiro projeto Rails com MongoDB

Você que leu o post 10 minutos com Ruby e MongoDB, provavelmente ficou pensando: “Como incluo o MongoDB no meu projeto Rails?”, bem, este post vem com intuito de ajudá-lo nesta sua dúvida cruel!

Nós poderíamos criar um projeto Rails com e ir ajustando-o, mas tem um jeito mais fácil para esta tarefa, eu encontrei esses templates e ajustei um pouco para escrever esse post.

Na pratica eu retirei alguns pontos e inclui outros para simplifica-lo, mas nada que altere o objetivo principal, criar um projeto Rails com MongoDB!

O Template passo a passo

Abaixo será apresentado o template usado para criar novas aplicações Rails com MongoDB, você também poderá ver o template aqui: http://gist.github.com/307386.

Removendo arquivos desnecessários

run "rm public/index.html"
run "rm public/images/rails.png"

Colocando o nome do seu banco no MongoDB e editando o arquivo database.yml com os dados do banco

db_name = ask('Qual será o nome do seu banco no mongodb? ')

# Editando o arquivo database.yml
# Com os dados do banco
file 'config/database.yml', <<-CODE
base: &base
  adapter: mongodb
  # em tempo de execucao vamos adicionar o "-\#{Rails.env}" ao nomo do banco
  database: "#{db_name}"
# Se estiver rodando o mongodb em outro host,
#vc deveria autenticar-se
  #host: host.mongodb.com
  #username: your-username
  #password: your-password

# use as proximas linhas para colocar algo especifico a cada ambiente
development:
  <<: *base

test:
  <<: *base

production:
  <<: *base
CODE

Colocando um arquivo na inicialização do rails. Este arquivo será encarregado de conectar no banco

initializer 'database.rb', <<-CODE
include MongoMapper

db_config = YAML::load(File.read(File.join(Rails.root, "/config/database.yml")))

if db_config[Rails.env] && db_config[Rails.env]['adapter'] == 'mongodb'
  mongo = db_config[Rails.env]
  MongoMapper.connection = Mongo::Connection.new(mongo['host'] || 'localhost',
                                                 mongo['port'] || 27017,
                                                :logger => Rails.logger)
  MongoMapper.database = "\#{mongo['database']}-\#{Rails.env}"

  if mongo['username'] && mongo['password']
    MongoMapper.database.authenticate(mongo['username'], mongo['password'])
  end
end

ActionController::Base.rescue_responses['MongoMapper::DocumentNotFound'] = :not_found
CODE

Não precisamos do Active Record.

environment 'config.frameworks -= [:active_record]'

Adicionando a gem do MongoMapper

gem 'mongo_mapper'

Adicionando um Testing Helper, que adicionará o método teardown (executado no fim do teste) para todas as classes que herdam ActiveSupport::TestCase

file 'test/test_helper.rb', <<-CODE
ENV['RAILS_ENV'] = 'test'
require File.expand_path(File.dirname(__FILE__) + '/../config/environment')
require 'test_help'

class ActiveSupport::TestCase
  # Apagando todas colecoes depois de cada test case
  def teardown
    MongoMapper.database.collections.each do |coll|
      coll.remove
    end
  end

# adicionando o metodo teardown em todos test cases
  def inherited(base)
    base.define_method teardown do
      super
    end
  end
end
CODE

Finalizando o gerenciamento das gems

rake 'gems:install'
rake 'gems:unpack'
rake 'rails:freeze:gems'

Ignorando alguns arquivos no controle de versão e comitando no git

file '.gitignore', <<-FILES
.DS_Store
**/.DS_Store
log/*
tmp/*
tmp/**/*
FILES

# comitando os fontes
git :init
git :add => '.'
msg_git = ask('Escreva seu comentario no commit do git')
git :commit => "-a -m \"#{msg_git}\""

Gerando sua aplicação Rails

rails nome_da_aplicacao -m "http://gist.github.com/307386.txt"
ou
rails nome_da_aplicacao -m "caminho_do_template"

Usando o generate

Na raiz do seu projeto recém criado rode:

ruby script/generate scaffold user

Aqui tem um ponto de atenção! O model não foi criado, isto porque não temos o ActiveRecord, mas calma será tudo muito simples, não desista agora!

Criando o Model

Seremos simples para não complicar! Um simples modelo de usuário (user.rb) a seguir:

# Diferente do ActiveRecord com o MongoMapper usamos inclusão ao invés de herança
class User
  include MongoMapper::Document

  # cada atributo deve ter o nome (como um Symbol) e seu tipo
  key :nome, String
  key :email, String
  key :nickname, String

  # para utilizar os Helper do ActionView é importante sobrescrever o método "to_s"
  def to_s
    self._id
  end
end

E as migrations??? É aqui não tem migrations, nós não precisamos nem criar o banco no MongoDB, a primeira vez que rodar a aplicação e utilizar o Model, voilá! Lá estarão as coleções!

Ajustando a view do CRUD

Aqui vamos chover um pouco no molhado, mas informação nunca é demais!

index.html.erb
Como eu disse acima, na construção do Model, o helper “link_to” usa o método “to_s” para construir os links no CRUD, nosso index ficará assim:

<h1>Listando Usuários</h1>

<table>
  <tr>
	<th>Nome</th>
	<th>Email</th>
	<th>Nickname</th>
  </tr>

<% @users.each do |user| %>
  <tr>
	<td><%= user.nome%></td>
	<td><%= user.email%></td>
	<td><%= user.nickname%></td>
    <td><%= link_to 'Show', user %></td>
    <td><%= link_to 'Edit', edit_user_path(user) %></td>
    <td><%= link_to 'Destroy', user, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New user', new_user_path %>

show.html.erb
Vale a dica do “link_to” mostrada no index

<b>Nome</b>: <%= @user.nome %><br />
<b>E-mail/<b>: <%= @user.email %><br />
<b>Nickname</b>: <%= @user.nickname %><br />
<%= link_to 'Edit', edit_user_path(@user) %> |
<%= link_to 'Back', users_path %>

new.html.erb
Nada de novo!

<h1>Novo Usuário</h1>

<% form_for(@user) do |f| %>
  <%= f.error_messages %>

<table>
	<tr>
		<td><%= f.label :nome %>:</td>
		<td><%= f.text_field :nome, :size => 40 %></td>
	</tr>
	<tr>
		<td><%= f.label :email, 'E-mail' %></td>
		<td><%= f.text_field :email %></td>
	</tr>
	<tr>
		<td><%= f.label :nickname, 'Nickname' %></td>
		<td><%= f.text_field :nickname %></td>
	</tr>
</table>

  <p>
    <%= f.submit 'Create' %>
  </p>
<% end %>

<%= link_to 'Back', users_path %>

edit.html.erb
Aqui também nada de novo.

<h1>Editando usuário</h1>

<% form_for(@user) do |f| %>
  <%= f.error_messages %>

<table>
	<tr>
		<td><%= f.label :nome %>:</td>
		<td><%= f.text_field :nome, :size => 40 %></td>
	</tr>
	<tr>
		<td><%= f.label :email, 'E-mail' %></td>
		<td><%= f.text_field :email %></td>
	</tr>
	<tr>
		<td><%= f.label :nickname, 'Nickname' %></td>
		<td><%= f.text_field :nickname %></td>
	</tr>
</table>

  <p>
    <%= f.submit 'Update' %>
  </p>
<% end %>

<%= link_to 'Show', @user %> |
<%= link_to 'Back', users_path %>

Adicionando validações

class User

  # obrigatoriedade +++++++++++++++++++++++++++++++++++++
  validates_presence_of :nome
  validates_presence_of :nickname

  # validando o formato +++++++++++++++++++++++++++++++++
  # nao use essa REGEX em seus projetos, é mto simples!!!
  REGEX_EMAIL = /[a-zA-Z0-9_.]+@([a-z0-9_]+\.)+[a-z]{2,5}\z/
  validates_format_of :email, :with => REGEX_EMAIL, allow_blank => false
end

Rodando nossa aplicação

Suba o MongoDB

[MONGODB_HOME]/bin/mongod &

Agora sua aplicação

ruby [app_name_dir]/script/server &

Em um browser entre: http://localhost:3000/users e divirta-se! Teste o MongoDB…

Testando

Com o MongoMapper é muito facil escrever testes, mas por favor, não escreva só testes tão obvios e nem faça tanta duplicação do código como neste exemplo!!!
Essa classe como é filha de ActiveSupport::TestCase terá o método tearDown adicionado, que será encarregado de remover os dados do banco no final do teste, já que no MongoDB os testes não serão envolvidos em uma transação do banco.

require 'test_helper'

class UserTest < ActiveSupport::TestCase

  test "validar a presença do nome" do
    user = User.new
    user.save
    assert_equal "can't be empty", user.errors.on(:nome)
  end

  test "validar a presença do email" do
    user = User.new
    user.save
    assert_equal "is invalid", user.errors.on(:email)
  end

  test "ter o e-mail com letrar minusculas" do
    user = User.new
    user.save
    user.email = "ALAN@EMAIL.COM"
    assert_equal "is invalid", user.errors.on(:email)
  end

  test "ter um email valido" do
    user = User.new
    user.save
    user.email = "123alan@email"
    assert_equal "is invalid", user.errors.on(:email)
  end

  test "gravar o usuario quando estiver corretamente preenchido" do
    user = User.new
    user.email = "alan@email.com"
    user.nickname = "alan"
    user.nome = "Alan"
    user.save
    assert_equal true, user.errors.empty?
  end
end

Então é isso, acho que agora você esta mais encorajado a escrever usa primeira aplicação com Rails e MongoDB! Os fontes usados neste post podem ser encontrados no git: http://github.com/alanrrb/Primeiro-projeto-Rails-com-MongoDB

Ah! Não se esqueça de deixar seu comentário!

10 minutos de Ruby e MongoDB

Continuando os meus estudos no movimento NoSQL, minha nova diversão é o MongoDB, mais um banco baseado em documentos. Agora você vai me perguntar: “Mas é o CouchDB que você estava estudando a um tempo atrás?”, calma caro leitor, é sempre bom ter varias ferramentas na caixa!
Vamos a uma breve descrição do MongoDB:

• MongoDB tem coleções de dados, mas não tabelas como conhecemos. Diferente do CouchDB, que também é um banco orientado a documentos, o MongoDB tem namespaces para dados, estes são “schema-less”, assim os dados poderiam estar organizados por namespaces. Você pode ter seus dados em cada coleção, semelhante ao ActiveRecord com Mysql ou qualquer SGDB.

• MongoDB tem indexes. Mesmo que que em cada coleção não tenha um “schema”, podemos ainda assim criar indexes e deixar as consultas ainda mais rápidas.

• MongoDB tem uma linguagem de consulta. Embora você possa usar o JavaScript para pesquisa através de uma coleção, como CouchDB, você também terá acesso a uma rica linguagem de consulta que pode filtrar com base nos campos, como o SQL, e filtrar com base no conteúdo dos documentos incorporados. Em vez de um complexo JOIN, você pode consultar todos os documentos da coleção de Posts que tiveram um comentário ou mais comentários no último mês de forma simples.

Bem vamos ao que interessa, a diversão!!!

Começaremos instalando o MongoDB, para não ser repetitivo, você encontrará mais informações no site oficial.

Galera do MacOS, prefiram seguir as instruções ao invés de usar o macports, eu tive problemas instalando o mongodb por ele(na verdade com as dependências), as instruções no site do MongoDB são muito mais simples.

Bem com tudo instalado vamos ao Ruby. Primeiro instale as gems:

gem install gemcutter

Depois as gems dos drivers do MongoDB.

gem install mongo
gem install mongo_ext

Só mais 8 minutos…

Em um terminal IRB rode.

require 'rubygems'
require 'mongo'

Conectando no banco:

conn = Mongo::Connection.new
db = conn.db("meu_bd")

Definindo uma coleção

coll_usuarios = db.collection("usuarios")

Inserindo documentos em uma coleção

coll_usuarios.insert({:nome => "Alan",
:email => "alanrrb@gmail.com",
:nickname => "alanrrb"})

coll_usuarios.insert({:nome => "Jose",
:email => "jose12332@gmail.com",
:nickname => "jose123321"})

coll_usuarios.insert({:nome => "Tom",
:email => "tom321123@gmail.com",
:nickname => "tom321123"})

Consultando um registro

usuario = coll_usuarios.find_one()
p usuario

{"_id"=>4b7e23b01919ba0353000001, "nome"=>"Alan", "email"=>"alanrrb@gmail.com", "nickname"=>"alanrrb"}

Buscando todos documentos com o nome “Tom”

coll_usuarios.find(:nome => "Tom").each do |doc|
p doc
end

{"_id"=>4b7e23b01919ba0353000003, "nome"=>"Tom", "email"=>"tom321123@gmail.com", "nickname"=>"tom321123"}

Mais 5 minutos…

E lá vem você com mais uma pergunta: “E aí, como incluir MongoDB em meus projetos Ruby e/ou Rails?”
E eu novamente lhe trago uma resposta… Existem alguns projetos interessantes de Object Mapper para MongoDB, destes o qual eu mais me interessei foi este MongoMapper, por parecer mais maduro e estar pronto para coloca-lo em produção sem grandes receios.

Mapeando Documentos

require 'mongo_mapper'

MongoMapper.database = "meu_bd"

class Usuario
include MongoMapper::Document

key :nome, String
key :email, String
key :nickname, String
end

Criando documentos e salvando:

marcia = Usuario.new
marcia.nome = "Marcia"
marcia.email = "email_marcia@gmail.com"
marcia.nickname = "nick_marcia"

marcia.save

Complicando um pouco mais, vamos adicionar relacionamentos

class Usuario
include MongoMapper::Document

many :pagamentos
end

class Pagamento
include MongoMapper::Document

key :valor, Float

belongs_to :usuario
end

marcia.pagamentos << Pagamento.new(:valor => 1.15)
marcia.save

Semelhante a um framework que conhecemos, o MongoMapper gera automaticamente alguns métodos, então é possível fazer isso:

alan = Usuario.find_by_nome("Alan")
p alan

#<Usuario nickname: "alanrrb", nome: "Alan", _id: 4b7e23b01919ba0353000001, email: "alanrrb@gmail.com">

Criando um documento e persistindo.

david = Usuario.create(:nome => "David", :email => "david321123@gmail.com", :nickname => "david")
p david

#<Usuario nickname: "david", nome: "David", _id: 4b7e23b11919ba0353000006, email: "david321123@gmail.com">

Se você conhece o ActiveRecord, com certeza viu algumas semelhanças e já esta com algumas ideias para incluir MongoDB nos seus próximos projetos, mas isso será assunto para a próximo post.

Os códigos usados neste post estão publicados aqui.

Por enquanto é só, não esqueçam de deixar seus comentários!

Mais um pouco de CouchDB e CouchRest

Se você já leu meu post anterior CouchDB – Resolvendo Problemas Reais saiba que esse é um post complementar, ou seja, se não leu pode le-lo agora!
No post anterior mostrei duas formas de modelar algo comum nos cenarios de softwares corporativo atuais.
Tá mais e ai, como utilizar as propostas? E possivel implementa-las?
Eu respondo, sim, é possivel! E para mostrar como eu vou usar o CouchRest uma gem do Ruby extremamente instalar e usar.
Não serei repetitivo, se quiser saber como usa-la utilize 5 minutos para isso ou um pouco mais que isso se preferir.
Chega de papo e vamos para o código!
Para ter nosso documento Cliente contendo seus Pedidos o modelo ficaria assim:

require 'rubygems'
require 'couchrest'

SERVER = CouchRest.new
SERVER.default_database = 'comercio2'
DB = SERVER.default_database

class Cliente < CouchRest::ExtendedDocument
  use_database DB

  property :nome
  property :email
  property :telefone
  property :pedidos, :cast_as => ['Pedido'], :default => []

  timestamps!
end

class Pedido < CouchRest::ExtendedDocument
  use_database DB

  property :numero
  property :valor
  property :data
end

Agora utilizando o modelo:

cliente = Cliente.new :nome => "Alan Rafael", :email => "alanbatista@gmail.com", :telefone => "9999-9999"
cliente.pedidos << Pedido.new(:numero => 1, :valor => 10, :data => Time.new)
cliente.pedidos << Pedido.new(:numero => 2, :valor => 105, :data => Time.new)
cliente.pedidos << Pedido.new(:numero => 3, :valor => 140, :data => Time.new)
cliente.save

puts cliente.id

#obtendo o cliente
clienteReloaded = Cliente.get cliente.id

puts "Pedidos do cliente #{clienteReloaded.nome}, são: "
clienteReloaded.pedidos.each do |pedido|
  p pedido
end

Saida do console:

Identificador do Cliente: 43d78f21600a60bd3371e02455aff980
Pedidos do cliente Alan Rafael, são:
{"data"=>"2010/01/29 01:42:24 +0000", "valor"=>10, "couchrest-type"=>"Pedido", "numero"=>1}
{"data"=>"2010/01/29 01:42:24 +0000", "valor"=>105, "couchrest-type"=>"Pedido", "numero"=>2}
{"data"=>"2010/01/29 01:42:24 +0000", "valor"=>140, "couchrest-type"=>"Pedido", "numero"=>3}

Vejam que o Cliente possui uma coleção de Pedidos, então agora vamos ver como o CouchDB armazena isso:

{
   "_id": "43d78f21600a60bd3371e02455aff980",
   "_rev": "1-97794fcd383ba246fc68ee0908621cc2",
   "created_at": "2010/01/29 01:42:24 +0000",
   "telefone": "9999-9999",
   "updated_at": "2010/01/29 01:42:24 +0000",
   "nome": "Alan Rafael",
   "pedidos": [
       {
           "data": "2010/01/29 01:42:24 +0000",
           "valor": 10,
           "couchrest-type": "Pedido",
           "numero": 1
       },
       {
           "data": "2010/01/29 01:42:24 +0000",
           "valor": 105,
           "couchrest-type": "Pedido",
           "numero": 2
       },
       {
           "data": "2010/01/29 01:42:24 +0000",
           "valor": 140,
           "couchrest-type": "Pedido",
           "numero": 3
       }
   ],
   "couchrest-type": "Cliente",
   "email": "alanbatista@gmail.com"
}

Simples né, um documento cliente contém os seus pedidos!

Bem agora vamos para o outro exemplo, um documento de Cliente com um ou mais documentos de Pedido.

require 'rubygems'
require 'couchrest'

SERVER = CouchRest.new
DB = SERVER.database('comercio')

class Cliente < CouchRest::ExtendedDocument
  use_database DB

  property :nome
  property :email
  property :telefone

  timestamps!

  def pedidos
    Pedido.by_cliente_id :key => id
  end
end

class Pedido < CouchRest::ExtendedDocument
  use_database DB

  property :numero
  property :valor
  property :data

  view_by :cliente_id

  def cliente= cliente
    self['cliente_id'] = cliente.id
  end
  def cliente
    Cliente.get(self['cliente_id']) if self['cliente_id']
  end
end

Vamos as novidades, não sei se contei, mas todo o CouchRest::ExtendedDocument é um Hash, então nessa parte:

  def cliente= cliente
    self['cliente_id'] = cliente.id
  end
  def cliente
    Cliente.get(self['cliente_id']) if self['cliente_id']
  end
end

Eu estou adicionando o atributo cliente_id ao documento pedido, assim podemos relacionar o documento Cliente ao documento Pedido.

Vamos usar esse modelo:

cliente = Cliente.new(:nome => "Alan Rafael", :email => "alanrrb@gmail.com", :telefone => "9999-9999")
cliente.save

pedido = Pedido.new
pedido.numero= 1
pedido.valor= 20000
pedido.data = Time.new
pedido.cliente= cliente
pedido.save

pedido = Pedido.new
pedido.numero= 2
pedido.valor= 1000
pedido.data = Time.new
pedido.cliente= cliente
pedido.save

puts "Identificador do Cliente #{cliente.nome}, id: #{cliente.id}"

puts "Pedidos do cliente #{cliente.nome}"
cliente.pedidos.each do |pedido|
  pedido.each do |chave, valor|
    puts "#{chave}: #{valor}"
  end
  puts
end

Saída do console:

Identificador do Cliente Alan Rafael, id: 019d581b142bfc059b7810694fcda012
Pedidos do cliente Alan Rafael
data: 2010/01/29 02:47:11 +0000
_rev: 1-af7e81f30c7fb4a379a053b929bd9cc8
_id: 0ea8803ebfb714d3ec47f93e0d33bac7
cliente_id: 019d581b142bfc059b7810694fcda012
valor: 1000
couchrest-type: Pedido
numero: 2

data: 2010/01/29 02:47:11 +0000
_rev: 1-bc1cbce13bbf65bfaeaaf193ef33cf28
_id: fa8ad3dd1f962a567ccf7e7c50f135c3
cliente_id: 019d581b142bfc059b7810694fcda012
valor: 20000
couchrest-type: Pedido
numero: 1

Voltando ao CouchDB vamos ver como ele salvou essa brincadeira:

Cliente:
{
   "_id": "019d581b142bfc059b7810694fcda012",
   "_rev": "1-5bb47e58256553b6fa2accca4f8475ba",
   "created_at": "2010/01/29 02:47:10 +0000",
   "telefone": "9999-9999",
   "updated_at": "2010/01/29 02:47:10 +0000",
   "nome": "Alan Rafael",
   "couchrest-type": "Cliente",
   "email": "alanrrb@gmail.com"
}
Pedidos:
{
   "_id": "0ea8803ebfb714d3ec47f93e0d33bac7",
   "_rev": "1-af7e81f30c7fb4a379a053b929bd9cc8",
   "data": "2010/01/29 02:47:11 +0000",
   "cliente_id": "019d581b142bfc059b7810694fcda012",
   "valor": 1000,
   "couchrest-type": "Pedido",
   "numero": 2
}

{
   "_id": "fa8ad3dd1f962a567ccf7e7c50f135c3",
   "_rev": "1-bc1cbce13bbf65bfaeaaf193ef33cf28",
   "data": "2010/01/29 02:47:11 +0000",
   "cliente_id": "019d581b142bfc059b7810694fcda012",
   "valor": 20000,
   "couchrest-type": "Pedido",
   "numero": 1
}

Como eu mostrei no post anterior, nesse forma de modelo, temos que ter um tipo em cada documento e o CouchRest “tipou” cada documento com o atributo “couchrest-type”, ficando assim muito simples obter cada registro e seu relacionamento.

Para finalizar, valor total de pedidos por cliente:

class Pedido
view_by :valor_total_pedidos,
              :map =>
                "function(doc) {
                    if(doc['couchrest-type'] == \"Pedido\")
                       emit(doc['cliente_id'], doc['valor']);
                 }",
              :reduce =>
                "function(keys, values, rereduce) {
                    return sum(values);
                 }"
end

total =  Pedido.by_valor_total_pedidos :key => cliente.id, :reduce => true
p "Valor total de pedidos para cliente: #{cliente.nome}, Total: #{total['rows'][0]['value']}"

Saída do console:

"Valor total de pedidos para cliente: Alan Rafael, Total: 21000"

O CouchRest nos dá muita flexibilidade e simplicidade para trabalhar com Ruby e CouchDB, espero te-los motivado para experimentar os dois.

Não se esqueçam de deixar seus comentários!

CouchDB – Resolvendo problemas reais

Há alguns meses me interessei pelo CouchDB, mas estava sem tempo para dedicar alguns minutos para conhece-lo mais.
Pois bem, nos 3 últimos dias abri mão de algum tempo e me dediquei a conhecer esse tal!
Mas como eu pensei, uma coisa leva a outra e então acabei encontrando aqui o CouchRest e acabei caindo mais aqui e aqui.

Amigos, o assunto é tão interessante que eu não consegui ficar com apenas os 5 minutos que o Leandro Silva sugeriu, acabei indo além e li quase inteiro o livro Beginning CouchDB em apenas 3 dias! (pra quem estava sem tempo, foi um recorde).

Fonte para conhecimento eu já indiquei nos links de posts acima, então vamos partir para um problema real.

Por ser baseado em documentos, supondo que você escolhesse o CouchDB para seu próximo projeto e neste tivesse o seguinte cenário:

Um sistema de vendas on-line no qual o cliente poderá executar vários pedidos. Bem simples e comum.

Em um banco de dados relacional você teria duas tabelas ligadas por uma “foreign key” e as consultaria através de um “join”, mas e no caso de um banco de dados “schema-free” e baseado em documentos? Provavelmente faríamos assim:

{
{"nome": "Alan Rafael Rodrigo Batista",
"e-mail": "alanrrb@gmail.com",
"telefone": "9999-9999",
"pedidos": [
{
"codigo":1,
"data":"2010/01/27 16:56:52 +0000",
"valor":2000
},
{
"codigo":1,
"data":"2010/01/27 16:56:52 +0000",
"valor":2000
},
{
"codigo":1,
"data":"2010/01/27 16:56:52 +0000",
"valor":2000
}
]
}

No próprio documento do cliente estaria a coleção de pedidos.

No CouchDB os documentos são salvos na formato JSON, então e muito fácil ter um relacionamento muitos para um.
Essa forma funcionaria sem problemas, até que num dado momento um processo tentar incluir um pedido, enquanto outro tenta alterar o cliente. O que acontecerá, um deles receberá erro “409 conflict“, além de sempre que quiser incluir um novo pedido, terá que obter todo o documento do cliente. (não que isso seja um problema)

E aí, qual outra opção?

Podemos também modelar um documento de cliente para um ou mais documentos de pedido. Para isso temos que criar um campo tipo em cada documento para que possamos identifica-los depois.
Ficaria assim:

{
"cliente_id": 1
"nome": "Alan Rafael Rodrigo Batista",
"e-mail": "alanrrb@gmail.com",
"telefone": "9999-9999"
"tipo": "Cliente"
}

{
"codigo":1,
"data":"2010/01/27 16:56:52 +0000",
"valor":2000,
"tipo" : "Pedido"
"cliente_id": 1
}

{
"codigo":2,
"data":"2010/01/27 16:56:52 +0000",
"valor":6300,
"tipo" : "Pedido"
"cliente_id": 1
}

{
"codigo":3,
"data":"2010/01/27 16:56:52 +0000",
"valor":200,
"tipo" : "Pedido"
"cliente_id": 1
}

Essa forma também funcionará sem problemas, mas sob o custo de ter mais requisições HTTP para manter os dados, já que o cliente e seus pedidos estão em documentos separados.

E como consultamos essas informações?

Valor total de pedidos por Cliente:

map: function(doc) {
   if(doc['tipo'] == "Pedido")
      emit(doc['cliente_id'], doc['valor']);
   }
reduce: function(keys, values, rereduce) {
   return sum(values);
}

Resultado:
{"rows":
[{
"key":"1",
"value":8500
}
]}

Podemos também obter um resultado da união dos dois documentos com um recurso de linguagem.

map: function(doc) {
   if(doc['tipo'] == "Pedido")
      emit([doc['cliente_id'],1], doc);
   } elseif(doc['tipo'] == "Cliente") {
      emit([doc['cliente_id'],0], doc);
   }
}

Assim você teria um documento que contém linhas com o codigo do cliente o próprio documento de cliente e outras com o código do cliente e o documento de pedido relacionado, simples né!

E qual das soluções é melhor? Não temos uma melhor ou pior e sim uma mais adequada ao seu projeto e isso que é belo no CouchDB, a liberdade que ele nós dá!

Bem acho que já é assunto suficiente para esse post, no próximo post vou demonstrar como escrever os dois exemplos em Ruby com o CouchRest.

Gostou do assunto? Comente! Não gostou? Comente também!

As aventuras de programador em busca do Ruby – Parte 1

Já faz um tempo que não posto nada, aproveitei o tempo vago nos últimos dias para aprender um nova linguagem de programação –algo que me dá uma grande satisfação–.

Baixei vários livros de diversas linguagens, mas os papos de corredor me levaram a escolher Ruby.

Apesar de programar em PHP por alguns anos, já estava desacostumado com linguagens Dinamicamente Tipadas, gosto muito de Java, estou até devendo escrever algo aqui no blog, mas com certeza ele me acostumou muito mal!!!

Pois bem, vamos parar de história e começar a diversão!

A escolha do livro

Essa parte foi bem difícil, porém, não menos interessante… Iniciei a leitura com o livro indicado por um amigo de trabalho o bem recomendado The Ruby Way, porém achei a leitura um tanto densa e longa (888 páginas assustam), então parti para um livro mais barato e menor, porém, não menos completo e interessante The Ruby Programming Language. O livro é ótimo e um dos seus autores é nada mais nada menos que o criador do Ruby Yukihiro Matsumoto – Matz –acho que o cara manja um pouquinho!–.
A leitura deste livro é bem tranqüila e eu estou gostando muito, recomendo, e enquanto for lendo vou compartilhar os ensinamentos adquiridos aqui no site, assim eu fixo o aprendizado e compartilho com a comunidade!
Vou deixar bem claro que não se trata de uma tradução, poderia talvez chamar isto de um “resumo público”, mas ainda assim, recomendo que comprem e leiam o livro.
Vou dividir a estrutura igual ao livro, porém vou iniciar a série de posts a partir do capitulo 2. Motivo? Quero que você tenha a mesma surpresa que eu tive quando ler o capitulo 1!

Estrutura e Execução de Programa Ruby

Estrutura Léxica

Comentários

# isto é um comentário de uma linha inteira
puts "Alan" # isto é um comentário
regex = /#[A-Za-z0-9] isto eh um expressão regular/ # isto é outro comentário

Comentários de múltiplas linhas deve ser feito assim:

#
# Desta forma é possível fazer um comentário de várias linhas
# No Ruby não há uma forma de comentar semelhante a essa no Java /* */
#

Documentos Embutidos

No Ruby há outra forma de inserir comentários multi linhas. Basta iniciar o bloco comentado por =begin e termina-lo com =end. Tudo que estiver entre =begin e =end será ignorado pelo interpretador, mas lembre-se, deve ter no minimo um espaço em branco após o =begin.

=begin isto é um comentário multi linha
tudo que esta aqui será ignorado pelo o interpretador.
=end

Literais

No Ruby há valores literais, aqueles que são inseridos diretamente no código, podem ser uma String, um número inteiro, ponto flutuante, expressão regular, etc., como o exemplo a seguir:

1         # inteiro
1.0       # ponto flutuante
"texto"   # string
/regex/   # expressão pessoal

Operadores

Há vários operadores no Ruby, porém vou falar mais sobre eles mais na frente (estão no capitulo 4 do livro rsrs), tem várias informações interessantes para falar sobre eles depois.

Identificadores

Identificadores são simplesmente um nome no Ruby e são usados para representar nomes de variáveis, métodos, Módulos, Classes e outros. Podem ser escritos por letras, números e underscore, porém eles não podem iniciar com um número.

Identificadores não podem iniciar por operadores exceto +, – ,|| e outros que serão descritos.

Os identificadores que iniciarem com uma letra maiúscula serão considerados constantes (passível que gerar um alerta, caso houver tentativa de alteração de seu valor). Classes e Módulos devem iniciar por uma letra maiúscula.

Ex:

a
a2
a_2
a2b
_var
PI                   # constante
class Pessoa # define a classe pessoa
end

O ruby é uma linguagem case sensitive, o identificador NOME é diferente de nome ou NoMe, lembre-se disso.

Outros usos de identificadores

No Ruby alguns identificadores tem um valor especial e são usados no inicio e no fim dos identificadores, vou mostrar essa parte com exemplos:

$var_global         # como no Perl, o Ruby define variáveis globais com $
@var_instance       # atributos de objeto são definidos com @ na frente do identificador
@@var_class         # atributos de escopo de classe recebem @@ na frente
obj.respond_to?     # métodos que retorno um boolean por convenção recebem um ? no final do identificador
"nome".upcase!      # métodos que devem ser usados com cuidado recebem um ! nome final
pessoa.nome="josé"  # métodos de atribuição deveria receber = no final... vamos falar mais disso depois

Palavras Chave

As seguintes palavras são chaves e tem um significado especial para Ruby.

__LINE__      case         ensure       not          then
__ENCODING__  class        false        or           true
__FILE__      def          for          redo         undef
BEGIN         defined?     if           rescue       unless
END           do           in           retry        until
alias         else         module       return       when
and           elsif        next         self         while
begin         end          nil          super        yield
break

E mais essas 3 que quando aparecem no inicio da linha tem um significado especial para o parser.

=begin   =end   __END__

Apesar de serem palavras chave, se estas palavras forem precedidas de @, @@, $ ou se usadas em nomes de métodos o código será interpretado sem erro (isto se deve a flexibilidade do interpretador do Ruby) porém o uso dessas palavras irá gerar um código de difícil interpretação, não acha?

Alguns comportamentos e características do Ruby estão ligados aos métodos de Kernel, Object, Module e Class. Como boa prática seria interessante tratar seus métodos como palavras reservadas.

# Estes métodos parecem palavras chaves ou reservadas
at_exit        catch          private        require
attr           include        proc           throw
attr_accessor  lambda         protected
attr_reader    load           public
attr_writer    loop           raise

# Estes são normalmente usados como funções globais
Array          chomp!         gsub!          select
Float          chop           iterator?      sleep
Integer        chop!          load           split
String         eval           open           sprintf
URI            exec           p              srand
abort          exit           print          sub
autoload       exit!          printf         sub!
autoload?      fail           putc           syscall
binding        fork           puts           system
block_given?   format         rand           test
callcc         getc           readline       trap
caller         gets           readlines      warn
chomp          gsub           scan

# E estes são usado  como métodos de Object
allocate       freeze         kind_of?       superclass
clone          frozen?        method         taint
display        hash           methods        tainted?
dup            id             new            to_a
enum_for       inherited      nil?           to_enum
eql?           inspect        object_id      to_s
equal?         instance_of?   respond_to?    untaint
extend         is_a?          send

Espaços em branco

A sintaxe do código Ruby é bem flexível, porém devemos ter alguns cuidados com isso. O uso de espaços em branco pode mudar a interpretação do código e causar resultados inesperados.
Ex:

avalia(3+1)+1 # executa o método avalia e adiciona 1
 

Outro exemplo:

# O Interpretador assume que o "(" (parenteses) foi omitido e intepreta (3+1)+1 e
# passa o resultado como argumento para o método avalia.
avalia (3+1)+1
 

Existem outras situação que serão mostradas nos post seguintes.

Estrutura Sintática

Neste capitulo do livro é introduzido temas relacionados a simples expressões a até complexos módulos.
No Ruby a unidade básica é a expressão, desde um valor literal que é uma expressão primária ou expressões mais complexas que usam palavras chaves como nil, self, true, false.

[:a,:b,:c]                                   # array de símbolos
["nome" => "José", "endereco" => "Rua Amazonas"]  # declaração literal de um hash
5                  # expressão primária
x = x+1    # atribuição

Assim como em outras linguagens de programação, no Ruby composições de declarações formam declarações (statement) conforme a seguir:

if x > 1
   puts "#{x} é maior que 1"
else
   puts "#{x} é menor ou igual a 1"
end

Blocos

Há duas maneiras de criar blocos no Ruby, e esta forma de construção é extremamente prático.

10.times { puts "Olá mundo 10 vezes, só para confirmar!" }

1.upto 10 do |n| puts "o número atual é #{n}" end

Mais informações sobre os blocos serão mostradas nos próximos posts.

Bem então é isso, a aventura não acabou, muito pelo contrário, ela está apenas iniciando.

Primeiras impressões

As primeiras impressões com o Ruby foram as melhores possíveis, acho que de todas as linguagens que aprendi essa foi a me mais me identifiquei até hoje, superou até o Python o qual eu não brinco já há algum tempo (tenho um colega que discordará dessa frase).
Pois bem, só posso concluir esse post dizendo, você deveria experimentar o ruby agora!!!

Ruby + Rails no Mundo Real 2010 – Resumo

No sábado passado (25/10/2010) aconteceu o Ruby + Rails no Mundo Real 2010, evento idealizado e organizado pelo Guru-SP (Grupo de Usuários Ruby de São Paulo).

Bem, resumindo, esse post é apenas um broadcast de um excelente post escrito por Rodrigo Ribeiro, com um Resumo deste evento. Este post ficou tão bem feito que eu não tenho o que complementar ou escrever, apenas para convidar à todos para participar do grupo, das listas de discussão e dos próximos eventos!

Aproveitem!

Minhas impressões – Ruby+Rails no mundo real 2010