Um caso bastante comum são URLs compostas que sempre apontam para um mesmo recurso. Por exemplo, um blog que possua rotas para seus posts no formato /posts/autor/categoria/permalink provavelmente terá uma rota mapeada como map.post "posts/:author/:category/:permalink" gerando automaticamente os helpers post_path e post_url.

Muito bom, porém para usufruirmos desta facilidade precisamos fornecer os valores dos parâmetros dinâmicos nos controllers e views:

post_path(:author => @post.author, :category => @post.category, :permalink => @post.permalink)

E mesmo que você forneça os parâmetros em um array, vai dar muito trabalho além de deixar muito código repetido pela aplicação.

Entendi! Mas como resolvo este problema?

Para este caso, apenas implementar o método to_param do model não vai servir. Uma solução seria reescrever o método post_path (que é gerado automaticamente) no respectivo helper (posts_helper.rb):

def post_path(post, options = {})
  super(post, :author => post.author, :category => post.category, :permalink => post.permalink)
end

Outra solução seria sobrescrever o método default_url_options no controller para retorna os parâmetros padrões da rota:

def default_url_options(options = {})
  options.merge!(:author => @post.author, :category => @post.category, :permalink => @post.permalink) if options[:action] == "show"
end

A má notícia é que você terá que fazer isto para todos seus controllers e respectivos models.

A terceira solução (e mais elegante) é padronizar a maneira com que os parâmetros opcionais da rota são obtidos a partir do controller e seu respectivo model. Basta adicionar os seguintes métodos no seu ApplicationController:

def default_url_options(options = {})
  if (model = controller_model(options))
    dynamic_route_params(options).each do |param|
      options[param] = model.send(param) if model.respond_to?(param)
    end
  end
  options
end
 
def controller_model(options = {})
  clazz = (options[:controller].singularize.camelize.constantize rescue ActiveRecord)
  options.select { |key, value| value.is_a?(clazz) }.first.second
rescue
  nil
end 
 
def dynamic_route_params(options = {})
  returning [] do |dynamic_params|
    matched_routes = ActionController::Routing::Routes.routes.select do |route|
      route.matches_controller_and_action?(options[:controller], options[:action])
    end
    dynamic_segments = matched_routes.map(&:segments).flatten.each do |segment|
      dynamic_params << segment.key if segment.is_a?(ActionController::Routing::DynamicSegment)
    end
  end
end

Assim, os valores defaults dos parâmetros da rota serão obtidos diretamente do model. Caso queiram contribuir, este código está disponível no github.

Referências
Rails Routing from the Inside Out
Rails Guides: Routing

Instalando a gem:

sudo gem install will_paginate

Para utilizar na aplicação, adicione no final do config/environment.rb:

require 'will_paginate'

Altere o controller para utilizar paginação:

def index
  @posts = Post.paginate :all, :page => params[:page], :per_page => 10
end

E adicione os links da paginação na view:

<%= will_paginate @posts %>

Pronto! Ao clicar nos links da paginação o parâmetro “page” será incluído automaticamente na requisição.

Legal, mas cadê o “ajax”?

Por padrão o WillPaginate não se preocupa com isso. O próprio desenvolvedor recomenda usar javascript para interceptar o “click” dos links e renderizar o resultado na mesma página.

Outra alternativa seria estender a classe responsável por renderizar os links da paginação para utilizar requisições com ajax.

Inclua em app/helpers o arquivo ajax_will_paginate.rb com o código:

class AjaxWillPaginate < WillPaginate::LinkRenderer
  def prepare(collection, options, template)
    @update = options[:update]
    super
  end
  protected
  def page_link(page, text, attributes = {})
    @template.link_to_remote(text, {
      :url     => url_for(page),
      :method  => :get,
      :update => @update
    })
  end
end

Então adicione no final do arquivo config/environment.rb:

  WillPaginate::ViewHelpers.pagination_options[:renderer] = 'AjaxWillPaginate'

E altere a chamada do helper na view para:

<%= will_paginate @posts, :update => 'div_principal' %>

Informe na opção :update o Id de um objeto html que contenha todo o conteúdo da paginação que será substituído nas requisições seguintes.

É importante lembrar que esta solução altera o comportamento de todos os helpers de paginação da aplicação, por isso deve ser utilizada com cautela. Outras soluções parecidas podem ser encontradas aqui.

Instalação:

sudo gem install rufus-scheduler

Utilização:

require 'rubygems'
require 'rufus/scheduler'

scheduler = Rufus::Scheduler.start_new

scheduler.every '5m' do
  puts 'Executando a cada 5 minutos'
end

scheduler.schedule '0 18 * * *' do
  puts 'Executando todos os dias as 18h'
end

Simples assim! Consulte a documentação oficial ou contribua com o código.

Nós somos fãs de jQuery pela sua simplicidade e poder de extensão através de plugins. Falando nisso, este plugin torna qualquer tabela <table/> em um “grid” ordenável, pesquisavel e paginável automagicamente.

Para usar, basta incluir o plugin na página após o jQuery e executar o script:

$(document).ready(function() {
    $("id-tabela").dataTable();
}

No site oficial é possível consultar a documentação, exemplos e a tradução para pt-br.

GitHub API, version 2

Os caras do GitHub não são fracos não… já faz um tempinho, mas antes tarde do que nunca, anunciaram em seu blog a versão 2 do GitHub API. Ela provê acesso à “Repository, User, Commit, Object and Network” e futuramente ao Gist também. Como é a primeira release e ainda estão trabalhando nela, o próprio pessoal do Github pede ajuda a “desbravadores” e que abram tickets, caso encontrem algo. Documentação você encontra em develop.github.com.

Links da semana

8 características de User Interfaces (UI) de sucesso

Nifty Generators para Ruby on Rails

JRuby on Rails no Google App Engine

Grid com ordenação e paginação animados

Este livro é sensacional e demonstra exatamente o espírito do Ruby: papo de programador.

O livro é bem divertido. As tirinhas das raposas são ótimas. Várias pessoas contribuíram com a tradução para pt-br que está disponível no Github.

Leitura obrigatória. Chunky bacon!

Autospec-notification

O Autospec é um script gerado pelo RSpec que utiliza o Autotest para rodar os testes automaticamente a cada alteração no código.

Unindo o útil ao agradável, foi criado o Autospec-notification, que exibe as notificações do autospec no desktop.

Para instalar, comece pela gem ZenTest:

sudo gem install ZenTest

No linux, instale o Libnotify:

sudo apt-get install libnotify-bin

Agora instale a gem do autotest-notification:

sudo gem install carlosbrando-autotest-notification --source=http://gems.github.com

Ative o autotest-notification e rode o autospec no seu projeto:

an-install

script/autospec

O código está no Github. Escreva seus testes e divirta-se!

Remarkable 3.0

Foi lançada a nova versão do Remarkable, um framework para testes com RSpec. Dentre as novidades, estão:

• I18n, possibilitando gerar o output das specs no seu idioma favorito fluente
• Pending Macros, facilitando o agrupamento das specs pendentes
• Macro stubs e mais opções de Matchers, simplificando testes com mocks

Para instalar basta um sudo gem install remarkable_rails

Saiba mais no site do Carlos Brando, lendo a documentação ou espiando o código no Github.

jqGrid no Rails

jQuery é um dos frameworks Javascript mais populares do mercado. O que esse cara fez foi juntar o jqGrid, que é um plugin muito bom para trabalhar com grids, num plugin para Rails, facilitando sua utilização.

Veja aqui um guia de utilização do plugin, a aplicação de exemplo ou confira o código no Github.

Heroku

Apesar da simplicidade do Business Bingo Generator, houve muitas “manhas” aprendidas no seu desenvolvimento. O Heroku foi uma delas, onde pudemos publicar rapidamente a aplicação. Se você quer hospedar um projeto simples feito em Rails, nós o recomendamos. O seu uso é muito simples e a incrível idéia de usar o git como interface para deploy é realmente sensacional. Basta instalar o client do Heroku, dar um “git push” e pronto: a aplicação está no ar!

Github Issue Tracker

Nova funcionalidade no GitHub para facilitar nossas vidas, permitindo informar os “bugs” nos projetos. No link acima, contém o vídeo “Introduction to GitHub Issues” para mais detalhes.

Caso já use um Issue Tracker para o seu projeto no github, você pode desabilitá-lo na seção do Features na aba Admin.

Business Bingo! Generator

A idéia deste post, além de ajudar a divulgar o site, é ter um local central para comentários, sugestões, reclamações e elogios para o Business Bingo Generator.

Curiosidade

• O Business Bingo, também conhecido como Buzzword Bingo, ganhou notoridade em 1994, com uma tirinha publicada do Dilbert.
• Um dos “grandes” eventos “documentados”, foi em 1996, que alunos do MIT o usaram no discurso do vice-presidente dos EUA, Al-Gore.

Uma nota rápida a desenvolvedores

A primeira versão foi desenvolvida em dois dias, isso mesmo, dois dias e já estava em produção. Eu e o Rodrigo Panachi resolvemos implementar a idéia do “generator” para aprender na prática como funciona o Ruby on Rails. Num post futuro irei colocar mais detalhes técnicos, que apesar de ser uma aplicação muito pequena, podemos tirar proveito de grandes aulas. Para quem quiser contribuir, o Business Bingo Generator está no GitHub.

Antes de começar a apresentar o “the best of my rotina”, é bom deixar bem claro o meu cenário:

• Trabalho sozinho no projeto, sou humano e faço pair programming com a cpu, que eu tenho certeza que é pogger!
• O meu cliente, o que requisita correções e/ou novas funcionalidades, é um cliente interno e eu tenho acesso direto a ele.
• O sistema não tem testes unitários, testes de integração e etc.
• Muito código foi copiado, não somente na camada de negócio, mas também nas views. As páginas por aqui, também são conhecidas como business-view.
• Tem mais complicações, mais acho que já tem o suficiente para entenderem o meu cenário.

O que já fizemos para começar a arrumar a casa:

• Implantamos um bug tracker, conhecido como Redmine. Sabe aquele velho problema de planilha pra lá e pra cá e ninguém nunca sabia quem, e o que estava fazendo? Pois bem, este problema está quase resolvido aqui (quase porque ainda tem projeto faltando para migrar).
• Implantamos um servidor de integração continua, com o Hudson. Apesar de eu não ter testes, havia um sério problema aqui para implantar novas versões em homologação e produção, e agora com o Hudson centralizando o build, ele mesmo já disponibiliza o war.
• Por sinal, montar e começar a usar o war foi outro trampo também.

Sabendo que o meu contexto é diferente do seu, sinta-se livre para adaptar qualquer coisa. Tentei deixar as dicas o mais genérico possível.

1. Trabalhe com tarefas Curtas

Tarefas curtas são muito mais fáceis para desenvolver, testar e se livrar! Por exemplo, se tem que desenvolver aquele formulário com vinte telas, não tenha dúvida, quebre isto em pequenas funcionalidades. Para identificar as partes “quebráveis”, leve em conta o que a torna funcional, ainda no exemplo anterior, se das vinte telas, você fizer a primeira e a última são suficientes para um cadastro básico, está ai a sua primeira tarefa. Muitas pessoas não dão importância para isso, mas saber “extrair” as tarefas certas de um novo desenvolvimento ou manutenção, traz um leque de vantagens:

• Testar uma funcionalidade curta é muito mais rápido e fácil do que testar uma gigantesca;
• Fica mais dificil perder o foco.
• Os prazos ficam mais “coerentes”.
• Você pode retirar ou incluir novas funcionalidades, a “negociação” com o cliente fica mais simples.

2. Monte e use um roteiro de teste

Pra quem usa TDD, este passo pode pular. Pra quem trabalha com legados e ainda não tem testes (meu caso), eu costumo fazer um roteiro de testes antes de implementar a funcionalidade curta. Este roteiro costuma ser enxuto e abrangente, isto permite que eu descanse meu cerebro enquanto testo, pois com ele, acaba se tornando um processo mecânico. Vou colocar um exemplo recente de roteiro que usei:

Teste de Primeiro Acesso

• Limpar a base, apagar os registros da tabela xpto e suas dependências.
• Limpar os cookies.
• Acessar o index.jsp da Aplicação (esta página simula um login via cookie).
• A tela inicial só permite cadastrar os dados do perfil, os links “xxx” e “zzz” não ficam disponíveis.
• Após o Teste de Restrições ao Editar o Perfil, verificar que os links “xxx” e “zzz” estão disponíveis.
• Clicar em salvar novamente para verificar se o problema de “unique id” não ocorre.

Estes roteiros se tornaram um costume, eu perco pouquissimo tempo pra fazer e apesar de parecer besta, ele me ajuda muito na hora de executar um teste de sanidade por exemplo. O ideal seria transformar este roteiro num teste unitário ou até mesmo num script via Selenium, mas devido a estrutura (ou a falta dela?!) eu ainda não consegui esta automação tão sonhada.
Apesar deste roteiro ser descartável e somente para ajudá-lo, uma idéia legal que venho fazendo é colocá-lo como comentário caso use um bug tracker.

3. Teste seu sistema num ambiente isolado

Estes últimos dois anos tenho usado linux no desktop para desenvolvimento. Infelizmente, todos nós sabemos que todo sistema web tem que ser testado nos IE*s e cia. É claro que durante o inicio do desenvolvimento, uso meu firefox local mesmo, mas assim que termino a funcionalidade, uso uma máquina virtual para averiguar a compatibilidade com os navegadores mais utilizados.
Usando o Virtual Box e Multiple IEs mais o opcional roteiro de testes, consigo validar o sistema numa boa gama de navegadores. Para usar o Multiple IEs não tem segredo, é só atualizar para o IE7 e depois rodar o executável do mesmo.

4. Automatize o que for possível

Já ocorreu de você precisar preencher n campos, navegar em n telas e descobrir que você errou o nome de uma variável javascript e ter que fazer tudo de novo? Pois bem, comigo já aconteceu muito, e uma das soluções que venho usando é o Selenium Ide. Com o plugin do firefox, eu gravo scripts temporários (durante o desenvolvimento da tarefa) que preenche os n campos e navegam nas n telas, assim pelo menos este tempo de navegação eu só perco uma vez.

Finalizando …

Todas estas “técnicas” nada mais são do que uma retrospectiva minha, de uma tentativa (frustada por sinal) de Scrum Solo. Aqui estou colocando o que vem dando resultado, e se você achou besteira ou legal, gostaria muito do seu comentário. Sabe aquela frase da maça e conhecimento, então, minha única expectativa com este post é esta: Novas Idéias!

Valeu e feliz ano novo a todos!

Bom pessoal, hoje estou aqui pra pedir ajuda. Sim, pedir ajuda pra todos àqueles que utilizam a web(www) para alguma coisa, seja para estudar, trabalhar, jogar ou ficar rico! E falo por todos desenvolvedores que tem o navegador como container de suas aplicações, que tem que lidar com as diversidades de dois mundos, MS Internet Explorer 6 contra a rapa!

O dia-a-dia no desenvolvimento de software web é um tanto sofrido para quem tem que, além de fazer uma aplicação com boa usabilidade, performance e ainda bonitinha, tem de manter compatibilidade com a ferramenta <voz_do_faustão>da gloriosa Microsoft</voz_do_faustão> que vem com o Windows XP: IE6. Sempre que você faz algum milagre em JavaScript, ou usa alguma técnica Web 2.0 pensando em agradar o usuário final (ou até mesmo o seu gerente!), tem que ficar com os dois pés atrás, pois você só pode comemorar depois de testar no IE6. O IE6 com certeza pode ser apontando como o pior navegador de todos os tempos, lento, péssima usabilidade, segurança terrível e ainda vai na contra-mão de todos os padrões WWW. O fato é que muita gente que programa não sabe que na verdade nem JavaScript este browser suporta, na verdade ele suporta um clone da Microsoft chamado JScript, este sim é o que deixa os programadores do mundo todo de cabelo em pé.

É claro que eu não podia deixar de fazer um comentário maldoso. Atualmente ainda temos muitas aplicações que não usam muitos recursos maravilhosos que a nova gereção de navegadores oferecem por culpa de empresas que não tem coragem de chutar o balde e forçar seus clientes à migrarem seus navegadores em prol de uma melhoria para todos, desenvolvedores e usuários! É claro que este tipo de empresa casualmente adotam metodologias duvidosas (waterfall puro!!), que refletem diretamente na qualidade de seus aplicativos, mas por outro lado temos empresas que lideram um movimento que deveria ser seguido por todos àqueles que querem se manter no mercado, uma delas é a 37Signals, que já manifestou algumas vezes o seu abandono ao IE6 dizendo que apartir do dia 15 de agosto todas suas aplicações passariam a não ter o compromisso de suportar o IE6.

Bom, acho que já ficou claro até aqui, que o passoal do 1Up4Developers apoia esta causa, e é por isso que escrevo este post, para mostrar a nossa aderência à campanha SaveTheDelelopers.

Assim como nós, muitas pessoas começam a apoiar essa campanha através de seus blogs, pessoas que são referência no desenvolvimento de software web. Eu descobri esta campanha através do blog Nome do Jogo, do Carlos Brando, e de imediato pensei em fazer este post.

Pessoal, disseminem esta idéa em todos os lugares, quando algum parente chamar você para consertar seu computador diga: só se você atualizar o seu navegador!

Abraço

Outro dia estava tendo uma conversa discussão com meu amigo Nivaldo sobre interfaces web com uso abusivo de javascript. Aí lembrei o que o Miguel disse sobre interfaces citando como parâmetro o Google e a Apple e a pouca importância que as empresas dão para esse assunto.

O mercado (alvo) está cada vez mais competitivo. Usuários não querem simplesmente um sistema funcional; ele deve ser bonito, intuitivo, agradável de usar. Um bom exemplo do que estou falando é o popular Goggle Reader: será que estaria tão popular se não fosse sua interface “rica”?

Acredito que atualmente, para sistemas web, a interface deve(ria) ser o principal “exciter” e onde as forças devem atuar consideravelmente. Digo isso porque as outras partes de um sistema (estou falando do negócio e banco de dados) estão razoávelmente maduras em termos de conceitos (OO, Teste, ORM), frameworks, etc.

Foi o tempo em que precisavamos saber apenas escrever código funcional. O desenvolvedor de hoje precisa saber muito bem HTML, CSS e JavaScript. E para isso, felizmente podemos (e devemos) utilizar recursos e frameworks para isso.