Segue abaixo o resumo das minhas submissões e, se você quiser, além de poder deixar comentários aqui, também pode fazer isso no próprio site de submissões do evento.

Espero te ver lá!

Como vi Scrum ser completamente rechaçado em uma grande empresa

Ouvimos por aí muitos relatos de sucesso de implementação de métodos ágeis em empresas grandes. Nós mesmos temos alguns. Mas onde estão os relatos de derrotas?

Nesta palestra vou contar uma história real em que vi Scrum ser completamente rechaçado em uma grande empresa que trabalhei.

Essa não é uma palestra sobre apontar culpados, mas sobre identificar falhas que comprometeram completamente a adoção de métodos ágeis nesta empresa.

Princípios de Agile Coaching

O que faz um coach ágil? Quais são suas ferramentas? Em que se baseia seu trabalho?

Essa palestra é sobre alguns princípios do coach ágil e como ser eficaz nessa missão. Vou abordar temas como:

- educação
- facilitação
- feedback
- percepção
- apoio

Além de falar sobre as atitudes esperadas de um coach:

- liderança por exemplos
- equilibrio emocional
- respeito ao ritmo do time
- linguagem que vence barreiras
- deixar o time aprender com seus erros

Contextualizando

Há pouco tempo assumi uma posição na Locaweb como gerente da equipe de desenvolvimento responsável pelos sistemas centrais da empresa. É uma equipe relativamente grande, dividida em três times de multi-talentosos desenvolvedores, um para cada domínio de negócio que lidamos: Provisionamento, Cobrança e Atendimento; além de dois sysadmins que dão suporte a estes times em tempo integral.

Os times atualmente estão organizados como times de Scrum tipicos, com os tais multi-talentosos desenvolvedores, um Scrum Master e um Product Owner – que no nosso caso, é um gerente de produtos que trabalhar fortemente conosco, extremamente comprometido com os interesses de negócio da empresa.

Desde então, comecei a buscar me interar um pouco mais sobre assuntos de gerenciamento e liderança ao melhor espírito ágil, com a preocupação de não me tornar aquele tipo de gerente que simplesmente “delarga” e vive alienado; ou pior ainda, aquele que comanda e controla o tempo todo, e que no final das contas, mais caroça e atrapalha do que ajuda.

Novo release: Gerente 2.0

Bem, além de conversar com vários amigos – muito mais experiêntes do que eu nesse papel –, também naveguei bastante pela Web e acabei chegando num artigo muito interessante de Pete Deemer, da Scrum Training Institute, que tem me ajudado bastante. Se você também tem interesse no assunto, acho que vale a pena ler.

Pete sugere no artigo, de maneira bem coerente, 14 atividades de um gerente de desenvolvimento. Vamos dar uma olhada no resumão delas:

1- Ajuda a remover impedimentos que o time não tem condições de resolver por si só

Enquanto o Scrum Master remove impedimentos hora-a-hora, dia-a-dia, coisas referentes ao projeto, o gerente precisará focar seus esforços em resolver impedimentos mais sistemátivos, mais corporativo, digamos assim.

Estes impedimentos, frequentemente, são os mais desagradáveis; e que requerem alguma influência, alguma autoridade, para lidar com eles de maneira efetiva.

2- Dá ao time conselhos e sugestões sobre dificuldades técnicas que aparecem

Gerentes deveriam estar disponíveis para dar conselhos e assitência técnica ao time sempre que solicitado.

Nota minha: é que claro que, volta e meia, o gerente vai precisar ir a reuniões estratégicas, corporativas – ou seja lá como chamemos em nossa empresa –, e não poderá atender às solicitações do time de imediato. É preciso tratar isso de maneira bem madura com o time, colocando na mesa as limitações impostas por suas outras atividades e buscando uma maneira de mitigar isso, para que nem o time fique na mão quando precisar, nem o gerente seja crucificado quando não estiver à pronta disposição.

3- Regularmente conversa com os membros do time, um por um, para dar coaching e mentoring

Gerentes deveriam gastar tempo com os membros do time, individualmente, com certa frequência (que cada um deve achar a melhor para si), para dar coaching e mentoring. Veja: não é para pedir status report; é para ensinar, ajudar, guiar, etc, menos cobrar.

Alguns gerentes gostam de fazer isso pareando e escrevendo código junto.

4- Dá sugestões sobre como fazer features melhores

Estas sugestões são endereçadas diretamente ao Product Owner, geralmente, durante a Sprint Review.

Nota minha: o ideal é que isso aconteça sempre, mantendo o máximo de proximidade possível com o Product Owner. No meu caso, por exemplo, sento de frente para o gerente de produtos de sistemas centrais e bato-papo com ele o tempo todo. Ou seja, se tenho algo a sugerir, não preciso esperar a cerimonia de revisão.

5- Mantem-se pari passu do desenvolvimento de ferramentas, tecnologias e técnicas que o time está usando

Esta é uma atividade muito importante e frequentente negligenciada pelos gerentes. Gerentes não podem ficar congelados no tempo. Mesmo porque, a atividade 2 é sobre estar apto a dar conselhos técnicos ao time.

Nota minha: não tem coisa mais irritante do que um gerente que não entende nada do trabalho que você está fazendo, dando palpites furados, e ainda querendo que você explique para ele algo que ele não tem um mínimo de base técnica e conceitual para entender.

6- Planeja treinamento e outros skills de desenvolvimento para os membros do time

Gerentes deveriam pensar cuidadosamente sobre onde o time poderia usar seu skill; e também, cláro, que capacidades o time precisará ter quando for desenvolver determinados itens do Product Backlog.

7- Mantem-se atualizado sobre as novidades e evoluções da indústria

Novamente, uma atividade importante, mas frequentemente neglienciada. Sem ela, a atividade 2 fica fortemente comprometida.

8- Antecipa ferramentas, skills e futuras necessidades

Outra atividade importante, que tem tudo a ver com a atividade 6, e que é frequentemente negligenciada. Converse com seu time a respeito, peça sugestões.

9- Planeja e gerencie orçamento e caixa

Outra vez, algo muito importante, mas muito negligenciado por diversos gerentes.

Nota minha: qual foi a última vez que você colocou no seu orçamento um din-din para cursos, eventos, livros, e outras coisas que melhoram o skill do seu time? Ou você é do tipo que não se preocupa com isso e que, pior ainda, até acha ruim que seu time vá a eventos, faça cursos ou leia livros no horário de trabalho?

10- Dá sugestões de que features o time deveria construir

Vale o mesmo comentário do item 4, não vale? Acho que sim, tem tudo a ver.

11- Faz avalição de performance e dá feedback aos membros do time

Isso é algo necessário em muitas empresas, apesar de bastante subjetivo. Mas o ponto aqui é que gerentes deveriam basear suas avaliações em suas próprias observações, bem como no feedback de outros membros de time.

12- Faz planejamento e desenvolvimento de carreira com os membros do time

Oportunidade de carreira é uma das mais significantes formas de compensar pessoas por seu trabalho. Além de din-din, é lógico!

13- Recruta, entrevista e contrata novos membros para o time

Uma das melhores (mas às vezes, aterrorizantes!) ações de gerenciamento é tomar decisões de contratação. Isso porque boas contratações dão lucro desde o primeiro dia, enquanto que más contratações são uma “taxa” invisivel na habilidade do time entregar valor de negócio.

14- Remove membros que não são capazes de fazer um bom trabalho no time

Se mesmo depois de extenso coaching um membro do time não é capaz de contribuir, de trabalhar harmoniosamente com os outros membros do time, ou de fazer seu trabalho na qualidade esperada, ele precisa ser removido do time, ou mesmo da empresa, rapidamente. Tipicamente, gerentes precisam guiar esse processo de maneira coordenada com o RH da empresa.

Nota minha: não deixe a moral do seu time e o dinheiro da sua empresa ir para o ralo. Cuidado! Há uma linha muito tênue entre “vou dar mais uma chance” e a omissão. Não tenha medo de fazer uma demissão, mesmo que tenha sido você que fez a má contratação. Contratações são quase que como loterias! Na verdade, quem fez a má contratação é o que menos importa; o que realmente importa é a performance e moral do time, que no final das contas, se traduz em mais dinheiro para a empresa.

Conclusão

O papel do gerente de desenvolvimento 2.0, como diz esse artigo de Pete Deemer, traz um mix de habilidades de liderança técnica e de gerenciamento de pessoas – pelo amor de Deus, não chame as pessoas de recursos!

A mim faz todo sentido; e está bem alinhado com as atribuições que recebi, quando contratado pela Locaweb. Aliás, acho que vale citar que, uma das coisas que Pete diz no artigo é que esse “novo” papel do gerente de desenvolviemnto precisa ter uma bênção formal do diretor de direitor TI, ou alguém com poderes equivalentes.

Mas e você, o que acha? Deixe um comentário…

Há alguns meses, quando comecei a mexer mais com Erlang/OTP, senti a necessidade de ter uma ferramenta que gerasse a estrutura dos projetos, bem como stubs dos módulos necessários. Não encontrei nenhuma que fosse realmente simples. O que fiz? Cocei minha própria coceira, crie o projeto otp_kickoff.

Agora, de saco cheio desconfortável de usar Make para automatizar tarefas de build, resolvi coçar minha própria coceira novamente, crie o projeto ebuilder.

Se você também está mexendo com Erlang/OTP, sugiro que dê uma olhada nestes projetos, quem sabe eles também não facilitam sua vida, ahmmm?

O objetivo do evento é compartilharmos entre nós mesmos as coisas que estudamos durante todo o ano. Levantamos então uma porção de assuntos que gostariamos de compartilhar, votamos nos que gostaríamos de ver, e no final, os mais votados são apresentados.

Este ano não tivemos o Jim, mas tivemos muita gente boa da Caelum falando sobre Ruby, JavaScript, Scala, Java, o Guilherme Silveira falando de RESTful junto com o Cauê Guerra e eu falando de Erlang/OTP junto com o Thadeu Russo.

Veja a nossa apresentação logo abaixo e divirtam-se com Erlang!

Na semana que passou, parti da CVC Turismo – deixando muitos bons amigos e lembranças fantásticas – e me juntei à Locaweb, como gerente de desenvolvimento sistemas, no departamento de sistemas centrais, passando a liderar tecnicamente uma galera muito gente fina e tecnicamente ótima.

Fui muito bem recebido e minhas expectativas são enormes. Estou muito feliz mesmo.

Vejamos o que o futuro nos reserva…

A BIF self() é analoga ao this do Java, por exemplo, que é capaz de responder quem é o objeto contenedor do método atualmente em execução. Semelhantemente, em Erlang, self() é capaz de dizer quem é o processo contenedor da função atualmente em execução avaliação. Assim, se você chamar self() no Erlang shell, você vai receber como retorno o Pid (identificador de processo) do próprio Erlang shell.

Faça um teste no seu Erlang shell:

1> self().

Você deve ter recebido algo semelhante a <0.31.0> com retorno. Isto porque o Erlang shell nada mais é do que um processo Erlang com um comportamento REPL.

Ok. Agora, o que acontece se você tiver um programa com um único módulo em que há duas funções que trocam mensagens entre dois processos? Qual seria o retorno de self() nestas duas funções?

Um pequeno exemplo

Vejamos um exemplo bem simples deste caso extraído do livro Erlang Programming:

-module(add_two).
-export([start/0, request/1, loop/0]).

start() ->
  process_flag(trap_exit, true),
  Pid = spawn_link(add_two, loop, []),
  register(add_two, Pid),
  {ok, Pid}.

request(Int) ->
  add_two ! {request, self(), Int},
  receive
    {result, Result}       -> Result;
    {'EXIT', _Pid, Reason} -> {error, Reason}
    after 1000             -> timeout
  end.

loop() ->
  receive
    {request, Pid, Msg} ->
       Pid ! {result, Msg + 2}
  end,
  loop().

De maneira bem objetiva, o que este código faz é o seguinte:

1- Quando um processo já existente – que no nosso caso será o próprio Erlang shell – faz uma chamada à função start(), um novo processo é gerado, tendo como ponto de partida a função loop(), o seu identificador é associado à variável Pid e, por fim, ele recebe o apelido add_two.

2- Todas as vezes que a função request(Int) é chamada, uma mensagem é enviada para o processo add_two, para que este some 2 ao número passado como parâmetro e envie o resultado de volta ao processo solicitante.

3- Sempre que o processo add_two recebe uma nova mensagem, esta é capturada na sentença receive ... end da função loop(), que verifica se é um “pedido de soma”, e então, envia o resultado da soma ao processo solicitante, identificado por Pid.

A confusão

Bem simples mesmo, certo? Então, por que acontece a tal confusão?

A confusão acontece, porque o retorno de self() não é o mesmo em todas as funções deste módulo. Isto porque a função loop(), apesar de estar contida no mesmo módulo que as funções start() e request(Int), não está rodando sendo avaliada no mesmo processo que elas estão. A função loop() está sendo avaliada no processo add_two, enquanto que start() e request() estão sendo avaliadas no primeiro processo – o Erlang shell. Assim, self() em loop() retorna um identificador de processo diferente do que retornaria as demais funções.

Quer tirar a prova?

Mais um simples exemplo, só que desta vez, esclarecedor!

Eu adicionei um bocado de “prints” no código que apresentei anteriormente e se você executá-lo agora, terá a prova do que foi discutido. (Tá tudo bem, você não precisa de uma prova a estas alturas do campeonato, mas vai ser divertido.)

-module(add_two).
-export([start/0, request/1, loop/0]).

start() ->
io:format(": start -> self() = ~w~n", [self()]),
  process_flag(trap_exit, true),
  Pid = spawn_link(add_two, loop, []),
  io:format(": start -> Pid  = ~w~n", [Pid]),
  register(add_two, Pid),
  {ok, Pid}.

request(Int) ->
  io:format(": request -> self() = ~w~n", [self()]),
  add_two ! {request, self(), Int},
  receive
    {result, Result}       -> Result;
    {'EXIT', _Pid, Reason} -> {error, Reason}
    after 1000             -> timeout
  end.

loop() ->
  receive
    {request, Pid, Msg} ->
       io:format(": loop/receive -> self() = ~w~n", [self()]),
       io:format(": loop/receive -> Pid    = ~w~n", [Pid]),
       Pid ! {result, Msg + 2}
  end,
  loop().

Após fazer a devida compilação, faz o seguinte teste no Erlang shell:

1- Veja o identificador de processo (aka Pid) do Erlang shell:

1> self().

2- Inicie o processo add_two:

2> add_two:start().

3- Chame a função request(Int):

3> add_two:request(10).

Executou? Comparou os Pids? Viu a diferença de escopo entre as três funções? Pois muito bem, então fica aqui a lição:

“Módulos servem para agrupar funções com um mesmo escopo conceitual, mas nem sempre com o mesmo escopo de processo”

Erlang nasceu no laboratório de ciência da computação da Ericsson na década de 1980, influenciada por linguagens como ML, Ada, Module, Prolog e Smalltalk, quando um time de três cientistas – entre eles, o grande Joe Armstrong – receberam a missão de descobrir qual seria a melhor linguagem de programação para escrever a próxima geração de sistemas de telecom. Após dois anos de investigação e prototipação, estes cientistas descobriram que nenhuma linguagem era completa o bastante para tal objetivo e, conclusivamente, decidiram criar uma nova linguagem. Nasceu então Erlang, the Ericsson Language.

De lá pra cá, Erlang tem sido evoluida e usada para escrever grandes sistemas críticos, porque é exatamente nesse cenário que Erlang faz mais sentido. Se seu projeto é construir um sistema crítico, altamente tolerante a falhas, com disponibilidade 24×7 e veloz como o papa-léguas, sim, Erlang é para você. Mas se não é bem esta sua necessidade, se você quer apenas construir um pequeno sistema, com baixa concorrência, poucos usuários, pouca necessidade de performance e possibilidade de passar horas down em manutenção, não, você não precisa de Erlang. Que tal Basic?

Diferente de algumas linguagens que nascem para encontrar um nicho, Erlang nasceu com um problema a ser resolvido, com requisitos a serem atendidos. Tolerância a falhas, concorrência realmente pesada, computação distribuída, atualização da aplicação sem derrubá-la, sistemas de tempo real, este é o nicho de Erlang; foi para isto que Erlang nasceu.

Quem usa Erlang atualmente?

Além da Ericsson, é lógico, há algumas outras grandes empresas e projetos usando Erlang, como por exemplo:

- Facebook, no backend de seu sistema de chat, lidando com 100 milhõs de usuários ativos;
- Delicious, que tem mais de 5 milhões de usuários e mais de 150 milhões de bookmarks;
- Amazon SimpleDB, o serviço de dados do seu poderoso EC2;
- Motorola, CouchDB, RabbitMQ, Ejabbed, etc.

Ok, mas Erlang é propriedade da Ericsson?

Não, felizmente, não. Em 1998 a Ericsson tornou Erlang open source sob a licença EPL.

Quer mais uma boa notícia? Você não precisa de um servidor de aplicações para rodar sua aplicação Erlang, nem mesmo uma pesada IDE para escrevê-las. Tudo o que você precisa é de uma distribuição de Erlang para sua plataforma, seja Mac OS X, Linux, Windows, Solaris, ou qualquer outro sistema Unix-like, que traz consigo máquina virtual, compilador e vasta bibliotéca de módulos muito úteis – além do banco de dados Mnesia; e um editor de textos de sua preferência – TextMate, por exemplo, tem um ótimo bundle para Erlang.

Algumas características de Erlang

1- Expressividade e beleza

Há quem diga que não, mas Erlang é uma linguagem muito bonita — ao menos pra mim. Dado as já citadas influências de Erlang, ela é uma linguagem bem expressiva e declarativa, que encoraja a escrita de código simples e objetivo, o que certamente torna seu código fácil de ler, de escrever e de organizar [em módulos reutilizáveis]. O snippet abaixo é um exemplo de implementação do famoso fatorial:

-module(sample1).
-export([fac/1]).

fac(0) -> 1;
fac(N) -> N * fac(N-1).

2- Forte uso de recursividade

Isto certamente é uma herança da veia funcional de Erlang que torna o código muito menos imperativo e mais declarativo. Mas além da beleza declarativa óbvia, é importante saber que Erlang foi projetada para lidar com iterações recursivas gigantescas sem qualquer degradação – e sem estourar o “heap” de memória.

3- Livre de efeito colateral

Uma das grandes capacidades dadas por Erlang é a construção de sistemas altamente concorrentes rodando em processadores com multiplos núcleos. Isto não combina nada com efeito colateral, por isso, em Erlang, uma vez que um dado valor tenha sido atribuído a uma variável, esta não poderá mais ser modificada – ou seja, estão mais para o que conhecemos por constantes do que para o que conhecemos por variaveis.

Se você já escreveu código concorrênte sabe o quanto tê-lo livre de efeitos colaterais te faz livre de dores de cabeça. Poucas coisas são tão deprimentes quanto debugar código concorrênte repleto de efeitos colaterais.

4- Pattern matching

Pattern matching em Erlang é usado para associar valores a variáveis, controlar fluxo de execução de programs, extrair valores de estruturas de dados compostas e lidar com argumentos de funções. Mais um ponto para código declarativo e expressividade. Vejamos o código abaixo:

-module(sample2).
-export([convert_length/1]).

convert_length(Length) ->
    case Length of
        {centimeter, X} ->
            {inch, X / 2.54};
        {inch, Y} ->
            {centimeter, Y * 2.54}
    end.

Fala por si, não?

5- Concorrência baseada em passagem de mensagens (a.k.a. Actors)

Acho que concorrência baseada em passagem de mensagem entre atores é uma das features mais populares de Erlang. Vejamos o porque com o famoso exemplo do Ping-Pong:

-module(sample3).

-export([start/0, ping/2, pong/0]).

ping(0, Pong_PID) ->
    Pong_PID ! finished,
    io:format("Ping finished~n", []);

ping(N, Pong_PID) ->
    Pong_PID ! {ping, self()},
    receive
        pong ->
            io:format("Ping received pong~n", [])
    end,
    ping(N - 1, Pong_PID).

pong() ->
    receive
        finished ->
            io:format("Pong finished~n", []);
        {ping, Ping_PID} ->
            io:format("Pong received ping~n", []),
            Ping_PID ! pong,
            pong()
    end.

start() ->
    Pong_PID = spawn(sample3, pong, []),
    spawn(sample3, ping, [3, Pong_PID]).

Neste pequeno snippet podemos observar algumas características de Erlang já citadas neste post, tal como pattern matching na captura das mensagens e recursividade no controle das iterações.

Agora, falando do aspecto concorrente em sim, algumas coisas são particularmente interessantes aqui:

a. Em Erlang, a concorrência acontece entre processos leves, diferente de linguagens como C++ e Java, que baseiam sua concorrência em threads nativas de sistema operacional [caríssimas];
b. Em Erlang, há um tipo de dado chamado PID, o qual é o identificador do processo paralelo (mais conhecido como Actor) e para o qual as mensagens podem ser enviadas.

Releia o código acima com estas informações em mente e veja como concorrência em Erlang é algo completamente descomplicado e natural. Depois, pense no mesmo código implementado em C#, Java ou C++.

Gostei de Erlang, há algum livro para eu começar a estudar?

Sim, há dois livros excepcionais. Um, do próprio criador da linguagem, Joe Armstrong:

E outro de Francesco Cesarini e Simon Thompson:

Além disso, há o próprio material on line que é muito bom e barato.

Conclusão

Erlang possui muitas outras características e informações bem interessantes, mas que me falta espaço neste post para citar e apresentar, senão ele ficará absurdamente gigantesco para o meu gosto. Mas acredito que pelo que já apresentei até aqui, você já tenha motivos suficientes para pensar em Erlang com carinho e conciderá-la para seu próximo grande projeto.

Em breve devo escrever algo sobre OTP, já que neste post apresentei características mais inerentes à linguagem em si e nem tanto sobre a plataforma.

Até mais!

Não ganhamos a competição, mas ganhamos muito participando da competição. Aprendemos muita coisa, fizemos amigos, nos divertimos bastante e fizemos umas das coisas que mais gostamos de fazer: programamos pra caramba! – dormi aproximadamente 5 horas durante as 48 horas de competição.

Meus sinceros agradecimentos à galera do meu time: Anderson Leite (com quem pareei bastante), Rafael (que foi quem teve a brilhante idéia do projeto) e Douglas (o melhor sysadmin que eu conheço). Foi muito bom fazer parte do time com vocês.

Nosso projeto

Bem, o resultado final do nosso projeto é este: whatannoysus.com. Não é tudo que nós gostaríamos que fosse, mas com certeza, já é um ótimo começo – e vamos dar continuidade.

Nós o construímos em menos de 48 horas, usando Ruby on Rails, Cucumber e MySQL; e o botamos para rodar num Ubuntu Server com Phusion Passenger e Nginx.

Patrocínio

Vida longa à Gonow!

A Gonow nos tratou muito bem, com tudo do bom e do melhor. Comida, camiseta Rails Rumble, hotel (que eu nem fui lá conhecer) e uma infra-estrutura de primeira.

Muito obrigado mesmo, a todos da Gonow e, se precisarem de alguma coisa, é nóiz!

Poder aos pares!

Tenho que concordar com o Yoshima, parear traz um ganho incrível no desenvolvimento. Ainda tem muita gente que acha que parear é reduzir o trabalho pela metada, afinal, são dois em um computador. Mas a real é que boa parte do nosso trabalho como programadores é pensar e conceber soluções que, em última instância, codificamos. E é aí que entra o ganho da programação em parte: duas cabeças pensam melhor do que uma – e quatro olhos acham bugs mais rápido também.

Outros relatos?

É isso que eu [resumidamente] tinha a dizer. Se você quiser saber um pouco mais, conhecer outros relatos, veja os posts do Anderson Leite e do Rodrigo Yoshima. E se houver algo que eu não mencionei e que você gostariam de saber, sinta-se à vontade para deixar um comentário.

Vou ficando por aqui e espero poder rever toda a galera – que foi muito legal conhecer – na Rails Summit.

Abraço!

Daqui a poucos minutos sairei aqui do meu trabalho em direção à Gonow para dar início à minha participação na Rails Rumble 2009, junto com meus camaradas @qmx, @r4f4el e @anderson_leite. A emoção está a mil, pode ter certeza!

Serão 48 horas de programação frenética, muita risada, descontração… e mais programação frenética — até o último git push.

Desde de já, quero agradecer demais a Gonow por todo apoio, que até camiseta e hotsite fez para todos fiquem realmente no clima da competição. Diego, valeu!

Torçam por nós!

@codezone
the_annoyers

O tema é CouchDB, o revolucionario banco de dados orientado a documentos e com interface totalmente RESTful, e a Ruby gem CouchRest, que é uma verdadeira mão-na-roda. Obviamente que, em tão pouco tempo — até para cumprir a promessa inicial –, eu não vou explicar os fundamentos do CouchDB, mas você pode encontrar uma introdução interessante aqui.

A primeira coisa que você precisa fazer é se certificar de que possui Ruby e CouchDB instalados. Caso você ainda não os possua, no Google você encontra inumeras receitas para todo sabor de sistema operacional. No meu caso, estou usando Mac OS X com Ruby EE da Phusion e CouchDB instalado via MacPorts — que acho a maneira mais prática de instação de qualquer coisa; esforço zero.

$ sudo port install couchdb

De qualquer forma, se você quiser uma fonte rápida de informação sobre instalação do CouchDB no seu sistema operacional, consulte o apêndice do livro CouchDB: The Definitive Guide. Lá você encontra um guia rápido para instalação em Windows, Mac OS X, Unix-like e a partir do fonte.

Mão na massa

Bem, com todos os pré-requisitos OK, vamos por a mão na massa logo de uma vez!

1- Instale a gem CouchRest

$ sudo gem install jchris-couchrest

2- Inicie o CouchDB

$ sudo couchdb -b

Acesse http://localhost:5984/_utils. Se você viu um camaradinha relaxando num sofá vermelho no canto superior direito da página, é porque está tudo certo com seu CouchDB. Vamos em frente.

3- Abra um terminal IRB

require 'rubygems'
require 'couchrest'

Tudo requerido corretamente, hora de começar a brincar com nosso banco de dados. Mas antes, vamos criá-lo!

db = CouchRest.database!('http://localhost:5984/my_db')

Agora vamos criar os atributos do documento que será gravado nesse banco.

attributes = { "name" => "Leandro Silva", "blog" => "leandrosilva.com.br", "titles" => ["System Architect", "Blogger"]}

Criado os atributos do documento, vamos gravá-lo.

result = db.save_doc(attributes)

Documento criado! Você pode acessar novamente http://localhost:5984/_utils e ver o que aconteceu até agora. Há um documento criado no banco my_db, com uma revisão apenas, contendo os dados que definimos no hash attributes.

Você também pode acessar informações resultantes da operação anterior através do hash result.

result['id']
result['rev']

Viu? São as mesmas informações que você viu no gerenciador web do CouchDB.

Vamos continuar acessando estas informações [de maneira absurdamente fácil] através da CouchRest.

record = db.get(result['id'])

Veja o hash record. Há duas chaves particularmente interessantes: _id e _rev. Estas duas chaves são equivalentes a id e rev do nosso hash anterior, o result.

Um teste? Compare os resultados abaixo.

result['id']
record['_id']

result['rev']
record['_rev']

Taí, simples assim. Viu a equivalência?

Vamos ver outros campos do nosso registro.

record['titles']

Que tal adicionar mais um titulo?

record['titles'] << 'Polyglot Programmer'

Bem, acho que já é hora de salvar e ir adiante, porque este tutorial tem que ser breve. Vamos lá.

result = db.save_doc(record)

Outra coisa interessante aqui. Vamos conferir a chave rev do nosso hash result.

result['rev']

Diferente da primeira vez que vimos, não? Vá ao gerenciador web do CouchDB e veja se algo mudou. Sim, algo mudou. Agora você tem a opção de navegar pelas revisões do seu documento. Fantástico!

Legal, muito bem por hoje.

db.delete_doc(record)

Agora volte ao gerenciador web do CouchDB e dê um refresh na página de visualização — caso você esteja nela.

O que aconteceu? Sumiu! O registro foi apagado.

Finalizando

$ sudo couchdb -d

Bem, por hoje é só pessoal. Espero que tenha sido realmente útil e que vocês tenham gostado.

Ah! E se gostaram, please, me deem um pontinho lá no WWRails. =p