Blog Lucas Renan

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

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

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?

O CakePHP é um framework para desenvolvimento rápido de aplicações em PHP. Baseado no Ruby on Rails, segue o paradigma da convenção sobre configuração. Usa design patterns como MVC e ORM, reduz os custos de desenvolvimento e ajuda os desenvolvedores a escreverem menos código.

Apesar de ser um bom framework e ser baseado no Rails, a principal diferença que faz o Rails mais vantajoso (fora o nível da comunidade ruby ser maior que o nível da comunidade php) é a própria sintaxe do Ruby em relação ao PHP. Eu particularmente recomendo fortemente o desenvolvimento em PHP utilizando o CakePHP, mas na minha opinião nada supera o Rails.

Abaixo segue um exemplo de uma consulta (inner join) entre dois modelos (Agencia e Cidade que possuem um relacionamento has_and_belongs_to_many) para uma consulta em que devem ser listadas as cidades (distintamente) que possuem relacionamento com agências ordenadas pelo nome:

O SQL esperado

SELECT cidades.id, cidades.nome FROM `cidades` INNER JOIN agencias_cidades ON (`agencias_cidades`.`cidade_id` = `cidades`.`id`) GROUP BY `cidades`.`id` ORDER BY `cidades`.`nome` ASC

Um possível exemplo no CakePHP (no controller agencias)

function index() {

        $cidades = $this->Agencia->Cidade->find('all', array(
            'recursive' => 0,
            'fields' => array('Cidade.id, Cidade.nome'),
            'joins' => array(array(
                'table' => 'agencias_cidades',
                'type' => 'INNER',
                'conditions' => array('agencias_cidades.cidade_id = Cidade.id')
            )),
            'order' => array('Cidade.nome'),
            'group' => array('Cidade.id')
        ));

        $this->set('cidades', $cidades);
}

Um possível exemplo no Ruby on Rails (no controller agencias)

def index
	@cidades = Cidade.all :select => "cidades.id, cidades.nome",
        :joins => "INNER JOIN agencias_cidades ON (`agencias_cidades`.`cidade_id` = `cidades`.`id`)",
        : order => "cidades.nome",
        :group => "cidades.id"
end

Esse é um exemplo bem simples, porém fica nítido a simplicidade do código, mesmo sem levar em consideração que no Rails bastaria uma linha em cada modelo para definir o relacionamento, enquanto que no Cake seria necessário mais linhas.