3º Encontro GURU Sorocaba

Finalmente o tão aguardado 3º encontro do GURU Sorocaba !!!

Venha aprender sobre Ruby, Rails, Node.js, Javascript e muito mais.
Um bate papo descontraído com o melhor dos objetivos, compartilhar conhecimento.

Sábado, 12 de Novembro · 09:00 – 12:30
FATEC Sorocaba

Palestrantes:

Fábio Akita (Codeminer 42)

- Começando com Node.js
Veja como usar o Node.js na prática, passando por uma introdução avançada de JavaScript, onde irei mostrar um pouco sobre funções, escopo de variáveis e closures, conteúdo essencial para quem quer se aventurar no Node.js.
Nando Vieira (Codeplane e HowTo)

- The Plataforma Way
Rafael França (Plataformatec)

- Canaries in the air
Ricardo Almeida (Gonow)

Patrocinadores:

nu ( http://nudesign.com.br/ )
gonow ( http://www.gonow.com.br/)

Apoio:

Codeminer 42 ( http://www.codeminer42.com/ )
Codeplane ( https://codeplane.com/ )
HowTo ( http://howtocode.com.br/ )
Plataformatec ( http://www.plataformatec.com.br/ )
Novatec ( http://novatec.com.br/ )

Evento no Facebook ( http://www.facebook.com/event.php?eid=208686602537771 )

http://gurusorocaba.com.br/
————————————————————————————————————————
* Evento gratuito! *

Confirmem sua presença enviando um email para gurusorocaba@gmail.com
————————————————————————————————————————


Exibir mapa ampliado

CouchRest Model Slug

This is the first time that I blog in english, so please correct me if I write something wrong. Suggestions are welcome too =)

CouchDB automatically generates UUIDs if none are provided. Usually, it’s recommended because some things like replication. However, we can do better for users. UUIDs are ugly, then we can create friendly urls.
CouchRest Model Slug is a simple gem to generate better urls using CouchRest Model in an easy way. I created this gem based on Mongoid Slug.

Getting Started

Add to Gemfile

gem "couchrest_model_slug", "~> 0.0.2"

A simple example

class Post < CouchRest::Model::Base   
  include CouchRest::Model::Slug   

  property :title   
  property :text   

  slug :title 
end 

Querying

 
p = Post.create(:title => "CouchDB Time To Relax")
p.to_param # => "couchdb-time-to-relax"

Post.find("couchdb-time-to-relax") # =>#<Post slug: "couchdb-time-to-relax", title: "CouchDB...

CouchRest Model Slug was made to work with or without slugged value, then it uses the id to keep things running with no problems.

Post.create(:text => "post without slug") # => #<Post slug: "", title: nil, text: "post with no slug", _id: "9fdfdd090897680de59091c8c98ff064"...

Post.find("9fdfdd090897680de59091c8c98ff064") # => #<Post slug: "", title: nil, text: "post with no slug", _id: "9fdfdd090897680de59091c8c98ff064"...

See the github page for more information https://github.com/lucasrenan/couchrest-model-slug

Vaga desenvolvedor Ruby on Rails

Galera, já faz quase um ano que estou trabalhando para a nu design e nós estamos contratando programadores ruby \0/

A nu é um estúdio de design gráfico de São Paulo, com um trabalho forte em web. O estúdio é consagrado pelo bom desenho e por ter uma pesquisa permanente, também na área do desenvolvimento. Informal e descontraído –porém extremamente profissional e produtivo– o estúdio mantém uma equipe de ponta que trabalha duro (apenas durante a semana!) para entregar o próximo projeto sempre melhor que o anterior.

desenvolvedor ruby on rails

requisitos

– experiência em ruby
– testes automatizados
– xhtml / css
– javascript / jquery

diferenciais

– mongodb
– rspec (tdd e bdd)
– práticas ágeis (scrum e xp)
– nginx e passenger

é seu perfil? envie seu cv e usuário do github para contrata@nudesign.com.br

Bugs que o sistema apresentou no fim do sprint

Ano passado meu último post foi “Erros que cometi nesse sprint”, tratava-se de alguns erros que tinha cometido em um projeto, principalmente por não ouvir as pessoas. Outra vez vou contar um pouco da experiência que eu tive e que está totalmente relacionada aos princípios ágeis.

A grosso modo, o princípio básico das metodologias ágeis de desenvolvimento de software é: entregar software de qualidade e funcional o mais rápido possível para garantir o ROI (retorno sobre investimento). Esse é um assunto que já se tornou clichê no mundo do desenvolvimento de software, porém no dia a dia de um projeto seguir esse princípio não é tão fácil como parece. Então, seguindo essa linha de pensamento, quando vamos iniciar um sprint devemos priorizar quais tarefas serão executadas primeiro afim de entregar o quanto antes as funcionalidades que tem mais valor (ROI).

Muitas vezes o objetivo principal do projeto não fica claro em um primeiro momento, no caso o projeto tratava-se de um loja virtual de cursos, porém esse conceito só ficou realmente claro para a equipe depois que o projeto foi “finalizado”. Isso foi um grande problema, eu particularmente acabei me concentrando em vários detalhes que não estavam diretamente relacionados com o objetivo principal, ou seja, o usuário poder comprar e se matricular em um curso.

Depois do “fim” do projeto foram encontrados vários bugzinhos no sistema e várias coisas que não tinham sido implementadas ou que poderiam ser melhoradas. Eu fiquei encarregado de arrumar esses bugs para então o site ser finalmente concluído e entrar em produção. No fim da segunda semana que estava arrumando os erros percebemos que o processo de compra de um curso simplesmente não estava funcionando…

É aí que PAGAMOS O PREÇO por NÃO ser ÁGEIS

Não entregamos software funcionando incrementalmente, fizemos incrementalmente, mas não entregamos, dessa forma é muito mais difícil descobrir bugs e possíveis mudanças. Adiar mudanças significa aumentar o custo delas. E o pior é entregar software que não cumpre com seu principal objetivo.

Se o software apresenta muitos bugs e precisa de muitas correções, você estará perdendo dinheiro, afinal o cliente não vai pagar para arrumar erros de desenvolvimento.

Poderíamos ficar procurando N motivos para dizer o porque cometemos erros (acharíamos vários e achamos), principalmente pelo projeto ser de escopo fechado, mas era melhor salvar o projeto, não acha? =p

Salve o projeto, seja ÁGIL

Utilizando três técnicas ágeis, conseguimos em poucos dias, corrigir os bugs e tornar o sistema totalmente funcional.

– Testes Automatizados
– Programação em Par
– Refatoração

O sistema tinha/tem testes automatizados, isso nos proporcionou fazer uma refatoração no código programando em par, com a segurança de que não iríamos quebrar outras partes do sistema. Dessa forma conseguimos rapidamente corrigir os bugs e o processo de compra, tornando o sistema totalmente funcional.

E você? está utilizando desenvolvimento ágil nos seus projetos?

Erros que cometi nesse sprint

Estou há mais de um mês sem postar nada por aqui, sim, sempre a mesma desculpa da falta de tempo. Trabalhando bastante, vários trabalhos na faculdade, alguns projetos paralelos e outras coisas estão consumindo grande parte do meu tempo.

Bom, desculpas a parte, arranjei um tempinho para compartilhar um pouco dos problemas que tive essa semana no trabalho. Acho que tão útil quanto compartilhar coisas boas que aconteceram é bom compartilhar o que não foi tão bom assim, afinal aprendemos bastante com os erros, talvez os meus erros te ajudem a errar menos =)

Eu passei os últimos três anos da minha vida trabalhando no desenvolvimento do Guia SPMais (sim fizemos outros projetos na Seek, mas esse era o principal). Boa parte do que eu aprendi sobre desenvolvimento web, programação, SEO entre outras coisas foi desenvolvendo o SPMais. Fizemos muitas coisas boas, com destaque para a migração de PHP para Ruby on Rails. Eu gostava bastante de trabalhar na Seek, afinal lá trabalhei com amigos como o Godinho, a Cássia e o Hary.

Há cerca de dois meses mudei de emprego (vários os motivos que podem se tornar um post separado). Agora estou trabalhando na Nu Design em São Paulo/SP. A Nu é uma agência com um time de desenvolvimento fantástico (Rails é claro =p), estou tendo vários novos desafios e aprendendo muito com caras como Marco, Samuel e com a consultoria do Carlos também.

Toda essa introdução só para ficar mais claro o contexto hahahah. Basicamente a Nu tem um processo de desenvolvimento bastante maduro (no meu ponto de vista). Apesar dos contratos dos projetos ainda serem de escopo fechado, utilizamos SCRUM e alguns conceitos de metodologias ágeis.

Essa semana cometi alguns erros que comprometeram (não tão drasticamente assim) a entrega desse sprint. Vou listá-los abaixo.

- Comecei várias tarefas ao mesmo tempo

Sem dúvida o meu maior erro foi dar start em mais de uma tarefa ao mesmo tempo. No meio do sprint fiquei travado esperando um layout para terminar a minha tarefa, então comecei a fazer a modelagem que iria utilizar para as próximas tarefas, o problema foi que eu startei quatro tarefas (estimadas em 13 pontos) ao mesmo tempo. Ou seja, peguei uma carga de trabalho maior do que fui capaz de fazer e “impedi” que outra pessoa pegasse alguma desssas tarefas.

- Estimei mal o prazo

Estimar prazos é sempre complicado, as vezes queremos ser a Mãe Diná e tentamos prever o futuro, mesmo que seja algo próximo, cometi um baita erro estimando um prazo que não fui capaz de cumprir. Fiquei até mais tarde no trabalho e nem isso resolveu o problema da minha estimativa. Provavelmente por não entender o problema completamente.

- Cometi falhas na comunicação

Sem dúvida um dos principais objetivos das metodologias ágeis é melhorar a comunicação. Quando há falha na comunicação, há problemas sérios. O erro que cometi foi não me comunicar tanto com os outros desenvolvedores quanto com o PO, então tive dificuldade na parte técnica e a minha implementação não atendeu o esperado da funcionalidade.

- Não escutei as pessoas

Um erro comum do ser humano é não escutar as outras pessoas, principalmente aquelas que tem bem mais experiência que você, dentro de uma equipe de desenvolvimento não é diferente. No meio do sprint o Carlos identificou o problema de eu ter pego mais de uma tarefa ao mesmo tempo, mas fui teimoso acreditando que isso não iria atrapalhar. Cometi outro erro.

Lições que aprendi nesse sprint:

– Não tente abraçar o mundo, faça uma coisa de cada vez, uma tarefa por vez.
– Não se comprometa a fazer mais do que você é capaz.
– Investigue o problema de maneira profunda, sua estimativa será melhor.
– Converse com as pessoas, pergunte, questione, compartilhe e faça com que compartilhem com você.
– Escute as pessoas, quem tem mais experiência pode ter passado por problemas que você ainda não passou.
– Estude e aprenda sobre metodologias ágeis, nunca ache que você já sabe o suficiente.

E o mais importante

- Programar em par pode parecer “mais lento”, mas ajuda a diminuir problemas como esses.

CouchDB – No Locking

No Locking

Uma tabela em um banco de dados relacional é uma estrutura de dados única. Se você quer modificar uma tabela – digamos, atualizar um registro – o sistema de banco de dados deve garantir que ninguém mais esteja tentando atualizar aquela linha e que ninguém possa ler aquele registro enquanto ele esteja sendo atualizado. A forma mais comum para lidar com isso é o que conhecemos como lock. Se multiplos clientes quiserem acessar uma tabela, o primeiro cliente seta o lock, fazendo todos os outros clientes esperarem. Quando a requisição do primeiro cliente for processada, o próximo cliente terá acesso enquanto todos os outros clientes esperam e assim por diante. Essa execução de requisições seriais, mesmo quando chegam em paralelo, disperdiçam uma quantidade significativa de poder de processamento do seu servidor. Sob carga alta, um banco de dados relacional pode gastar mais tempo tentando descobrir quem é permitido fazer o que, e em que ordem, do que fazer qualquer trabalho efetivo.

Ao invés de locks, o CouchDB utiliza MVCC – Multi-Version Concurrency Control (controle de concorrência de multi versão) para gerenciar acessos ao banco. MVCC significa que o CouchDB pode ser executado a toda velocidade, todo o tempo, mesmo sob alta carga. As solicitações são executados em paralelo, fazendo um excelente uso de cada última gota do poder de processamento que seu servidor tem para oferecer.

CouchDB Lock Free MVCC

CouchDB Lock Free MVCC

Os documentos no CouchDB são versionados, bem como estariam em um sistema regular de controle de versões como Subversion. Se você quiser alterar um valor em um documento, você cria uma versão totalmente nova daquele documento e salva sobre o antigo.

Como isso oferece uma melhoria em relação aos locks? Considere um conjunto de requisições que querem acessar um documento. A primeira requisição lê o documento. Enquanto isso está sendo processado, a segunda requisição atualiza o documento. Desde que a segunda requisição inclua uma nova versão completa do documento, o CouchDB pode simplesmente adiciona-la ao banco sem ter que esperar pela primeira requisição de leitura terminar.

Quando uma terceira requisição quiser ler o mesmo documento, o CouchDB irá apontar para a nova versão do documento que acabou de ser escrita. Durante todo esse processo, a primeira requisição pode continuar lendo a versão original.

Uma requisição de leitura sempre verá a versão mais atualizada do seu banco no começo da requisição.

Tradução literal do livro CouchDB the Definite Guide.

Sinatra – Uma DSL Ruby

Quem não está muito ligado na comunidade Ruby talvez só tenha ouvido falar sobre o Rails. É claro que o Rails é o framework mais famoso de Ruby e vem ajudando a alavancar o crescimento da linguagem, porém existem outros frameworks e DSLs em Ruby. Uma DSL muito boa é o Sinatra. O Sinatra é uma DSL para se criar aplicações web de maneira rápida e com o mínimo de esforço. (eu aprendi a utilizá-lo com o Anderson Leite da Caelum)

O Sinatra possui algumas diferenças com relação ao Rails como por exemplo, não segue o padrão MVC. Seu uso é recomendado para resolver problemas pequenos e é realmente bem fácil utilizá-lo.

Vamos supor que você precise fazer algo simples como criar uma listagem qualquer ou qualquer outra coisa simples não compensando o desenvolvimento em Rails. (hoje eu precisei criar um sitemap com alguns dados da minha aplicação, bem simples, algo que não seria necessário agregar ao escopo da minha aplicação Rails).

Antes de começar é necessário instalar o Sinatra

sudo gem install sinatra

Vou utilizar também o MySQL e o Data Mapper como ORM

sudo gem install dm-core
sudo gem install dm-mysql-adapter

Supondo então que quero fazer uma simples consulta em uma tabela posteriormente criada e com dados cadastrados.
Crie o arquivo my_sinatra.rb com seu editor preferido

require 'rubygems'
require 'sinatra'
require 'dm-core'

#conexao com mysql
DataMapper.setup(:default, "mysql://user:pass@localhost/database")

#classe qualquer
class Product
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :status, String

  def self.active
    all(:status => "A")
  end
end

#listando produtos ativos
get '/' do
  @products = Product.active 
  erb :index
end

#utilizando SQL diretamente
get '/sql' do
  @products =  repository(:default).adapter.select("SELECT * FROM produtos WHERE status = 'A'")
  @products.collect{|p| p.id.to_s + " "}
end

Crie também uma pasta chamada views e o arquivo index.erb

<% @products.each do |p| %>
  <%= p.name %><br />
<%  end %>

Para startar a aplicação

ruby my_sinatra.rb

O Sinatra roda na porta 4567 (http://localhost:4567/)
Repare que as urls são definidas no início do bloco: get ‘/’ do

Para complementar o post, recomendo a leitura:
http://www.sinatrarb.com/intro
http://datamapper.org/getting-started

CouchDB Lucene – Buscas Full-text no CouchDB

O CouchDB Lucene provê a funcionalidade de realizar buscas full-text no CouchDB utilizando Lucene.

Antes de começar precisamos instalar as dependências, só lembrando que esse tutorial foi testado nas versões 10.04 e 9.10 do Ubuntu Linux, mas a princípio o procedimento de instalação para Mac deve ser parecido.
No Ubuntu 10.04 os pacotes sun-java6 foram removidos da seção Multiverse do Ubuntu archive, então você precisa adicionar o repositório Partner da Canonical.

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"

Então você pode instalar o JDK e o JRE:

sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-jdk

Para instalar o CouchDB Lucene é preciso que você tenha o Git e o Maven instalados:

sudo apt-get install git-core maven2

Finalmente para instalar o CouchDB Lucene é necessário clonar o repositório:

git clone git://github.com/rnewson/couchdb-lucene.git

No caso, hoje a versão estável é a 0.5.3, então vamos dar o build:

cd couchdb-lucene
git checkout v0.5.3
mvn

Configurando o CouchDB
Agora vamos configurar o CouchDB editando o arquivo de configuração que geralmente está localizado em /usr/local/etc/couchdb/local.ini

[couchdb]
os_process_timeout=60000 ; aumenta o timeout para 5 segundos

[external]
fti=/path/do/python /path/para/couchdb-lucene/tools/couchdb-external-hook.py ; geralmente /usr/bin/python

[httpd_db_handlers]
_fti = {couch_httpd_external, handle_external_req, <<"fti">>}

Agora vamos criar uma view de exemplo, supondo que temos um design document de Posts

{
    "_id": "_design/Post",
    "fulltext": {
        "by_title": {
            "index": "
            function(doc) { 
                if(doc['couchrest-type'] == 'Post') {
                    var ret=new Document(); 
                    ret.add(doc.title); 
                    return ret; 
                }
            }"
        }
    }
}

Pronto, você pode realizar buscas full-text no CouchDB utilizando Lucene:

curl http://localhost:5984/nome_banco/_fti/_design/Post/by_title?q=titulo_do_post

Group by no Couchdb

No post anterior sobre Order by no CouchDB eu mencionei que o próximo post seria sobre Group by, como prometido vou tentar abordar essa questão apresentando um exemplo simples de como agrupar resultados de views.

Para facilitar (como sempre) estou utilizando Ruby on Rails + CouchRest, porém vou postar aqui só a parte relevante do código para entendermos o exemplo. Então vamos considerar nosso model Post:

class Post < CouchRest::ExtendedDocument
  use_database CouchRest.database("http://127.0.0.1:5984/group_couchdb")

  property :titulo
  property :conteudo
  property :autor_id

  timestamps!

  view_by :data,
  :map => "
    function(doc) {
      if ((doc['couchrest-type'] == 'Post')) {
        data = doc.created_at;
        ano = parseInt(data.substr(0, 4));
        mes = parseInt(data.substr(5, 2), 10);
        dia = parseInt(data.substr(8, 2), 10);

        emit([ano, mes, dia], 1);
      }
    }",
  :reduce => "_count"

end

Detalhe para a view data que emite como chave um array contendo o ano, mes e dia do post e para cada valor (dependendo do agrupamento) emite o valor 1 para a função reduce (que conta quantos valores foram emitidos para cada chave em questão).

Não vou postar o código de inserção dos posts, você pode inserir alguns posts na sua base para realizar os testes.
Primeiro quero contar o número de posts realizados por dia (isso é possível pois a função map gera o array com dia, mês e ano, assim a função reduce soma os valores para as chaves).

curl http://127.0.0.1:5984/group_couchdb/_design/Post/_view/by_data?group=true

Acessando a url acima você vai ver um resultado parecido com esse:

{"rows":[
  {"key":[2010,6,10],"value":1},
  {"key":[2010,7,17],"value":1},
  {"key":[2010,7,18],"value":2}
]}

Ou seja, no dia 10/06/2010 foi cadastrado um post, assim como no dia 17/07/2010, já no dia 18/07/2010 foram cadastrados dois posts (esses são os posts que eu tenho cadastrado na minha base).

Agora vamos supor que queremos contar quantos posts foram cadastrados por ano. Isso é muito simples utilizando a view que já temos, o CouchDB aceita um parâmetro chamado group_level. Cada posição do array que foi emitida é um “level”, então podemos agrupar os valores por cada posição do array. Se passarmos group_level=2 serão emitidos como chave o ano e o mês, group_level=1 apenas o mês, etc.

Post.by_data(:reduce => true, :group_level=>1)

A url seria parecida com essa:


http://127.0.0.1:5984/group_couchdb/_design/Post/_view/by_data?group=true&group_level=1

E o resultado seria quatro posts para o ano de 2010

{"rows":[
  {"key":[2010],"value":4}
]}

Podemos concluir que agrupar valores no CouchDB não é tão difícil quanto parece, acredito que é uma questão da modelagem dos dados e da forma como utilizamos as views.

Order by no CouchDB

Uma das cláusulas mais utilizadas em SQL nos bancos relacionais é a ORDER BY. Sempre que queremos ordenar o resultado de uma query por determinada coluna de uma tabela, utilizamos ORDER BY nome_da_coluna e recomenda-se que seja criado um índice para essa coluna, afim de otimizar a ordenação dos dados. O problema começa quando precisamos ordernar os resultados por vários campos da tabela, sendo que pode ficar inviável criar uma série de índices, já que essa tabela pode também sofrer um grande número de atualizações.

Uma das grandes vantagens do CouchDB (noSQL) é o poder das views (eu sempre gosto de reforçar isso). Você pode criar várias views (que resultem em várias formas) para os seus dados, sem comprometer a inserção para aquele tipo de dado (documento). Ou seja, supondo que você precise ordenar alguns documentos por 3 “campos” diferentes, basta que você crie 3 views, sendo que cada uma emita como chave o determinado “campo” em questão. Podemos exemplificar em Ruby utilizando a gem CouchRest, vamos supor um modelo de cidades:

class City < CouchRest::ExtendedDocument
  use_database CouchRest.database("http://127.0.0.1:5984/order_by_couchdb")
  unique_id :slug
  
  property :slug, :read_only => true
  property :name
  property :state
  property :population
  timestamps!
  
  #o couchrest criara as views no banco
  view_by :name
  view_by :state
  view_by :population
  
  #antes de salvar cria o slug que sera o id do documento
  set_callback :save, :before, :generate_slug_from_name

  def generate_slug_from_name
    self['slug'] = name.downcase.gsub(/[^a-z0-9]/,'-').squeeze('-').gsub(/^\-|\-$/,'') if new?
  end
end

Vamos inserir algumas cidades para exemplificar (eu estou utilizando Rails também)

c = City.new(:name => "Sorocaba", :state => "SP", :population => 700000)
c.save

c2 = City.new(:name => "Sao Paulo", :state => "SP", :population => 11000000)
c2.save

c3 = City.new(:name => "Rio de Janeiro", :state => "RJ", :population => 6000000)
c3.save

O CouchRest vai criar 3 views (by_name, by_state, by_population). Ordenando as cidades pelo nome

City.by_name

Repare que no banco será criada a view (função map)

function(doc) {
  if ((doc['couchrest-type'] == 'City') && doc['name']) {
    emit(doc['name'], null);
  }
}

E o resultado será (ordenado alfabeticamente)

{"total_rows":3,"offset":0,"rows":[
  {"id":"rio-de-janeiro","key":"Rio de Janeiro","value":null},
  {"id":"sao-paulo","key":"Sao Paulo","value":null},
  {"id":"sorocaba","key":"Sorocaba","value":null}
]}

Ordenando as cidades pelo número da população, da maior para a menor

City.by_population(:descending => true)
{"total_rows":3,"offset":0,"rows":[
  {"id":"sao-paulo","key":11000000,"value":null},
  {"id":"rio-de-janeiro","key":6000000,"value":null},
  {"id":"sorocaba","key":600000,"value":null}
]}

Até aí tudo muito simples e fácil, podemos ordenar nossos dados de forma bem flexível. Então, vamos complicar um pouco. Vamos supor que queremos filtrar os resultados passando como parâmetro o estado, porém que as cidades sejam ordenadas pela data de criação, de forma que as mais velhas sejam mostradas primeiro. A princípio isso parece estranho, mas é muito útil por exemplo se quisermos ordernar posts, buscando por determinada categoria (queremos que sejam listados os últimos cadastrados) e também em outras situações que se precisa ordenar os resultados de forma crescente ou decrescente.

Se utilizarmos a view que emite apenas o estado como chave (by_state), o CouchDB vai ordenar as cidades pelo id (no caso o id é o nome da cidade) então teríamos as cidades do determinado estado, ordenadas alfabeticamente. Então, precisamos criar uma view que emita um array (estado e data de criação) como chave.
Acrescente na classe

view_by :state, :created_at

Será criada a seguinte view

function(doc) {
  if ((doc['couchrest-type'] == 'City') && doc['state'] && doc['created_at']) {
    emit([doc['state'], doc['created_at']], null);
  }
}

Buscando as cidades (cadastradas primeiro) do estado SP

City.by_state_and_created_at(:startkey => ['SP'], :endkey => ['SP', {}])

Repare que a cidade de Sorocaba vem primeiro (pois foi cadastrada primeiro), se tivéssemos utilizado a view que emite como chave apenas o estado, São Paulo viria primeiro

{"total_rows":3,"offset":1,"rows":[
  {"id":"sorocaba","key":["SP","2010/05/25 01:25:53 +0000"],"value":null},
  {"id":"sao-paulo","key":["SP","2010/05/25 01:25:54 +0000"],"value":null}
]}

Podemos concluir que as views do CouchDB são extremamente poderosas e simples, de início parece complicado, já que estamos habituados ao SQL, porém quando se entende bem o conceito do Map/Reduce as coisas ficam bem mais fáceis. No próximo post pretendo escrever sobre agrupamentos (GROUP BY).