Dica do Renato Carvalho

Eu avisei no último artigo desta série que muitos métodos do Rails seriam alterados para deixarem de receber seus parâmetros da forma convencional e passariam a recebe-los via um Hash de opções.

Pois bem, agora chegou a vez dos métodos truncate, highlight, excerpt, word_wrap e auto_link serem atualizados. Veja como eles devem ser usados a partir da próxima versão do Rails:

truncate

truncate("Once upon a time in a world far far away")
# => Once upon a time in a world f...

truncate("Once upon a time in a world far far away", :length => 14)
# => Once upon a...

truncate("And they found that many people were sleeping better.", :omission => "... (continued)", :length => 15)
# => And they found... (continued)

highlight

highlight('You searched for: rails', ['for', 'rails'], :highlighter => '<em>\1</em>')
# => You searched <em>for</em>: <em>rails</em>

highlight('You searched for: rails', 'rails', :highlighter => '<a href="search?q=\1">\1</a>')
# => You searched for: <a href="search?q=rails">rails</a>

excerpt

excerpt('This is an example', 'an', :radius => 5)
# => ...s is an exam...

excerpt('This is an example', 'is', :radius => 5)
# => This is a...

excerpt('This next thing is an example', 'ex', :radius => 2)
# => ...next...

excerpt('This is also an example', 'an', :radius => 8, :omission => '<chop> ')
# => <chop> is also an example

word_wrap

word_wrap('Once upon a time', :line_width => 8)
# => Once upon\na time

word_wrap('Once upon a time', :line_width => 1)
# => Once\nupon\na\ntime

auto_link

post_body = "Welcome to my new blog at http://www.myblog.com/. Please e-mail me at me@email.com."

auto_link(post_body, :urls)
# => "Welcome to my new blog at <a href=\"http://www.myblog.com/\">http://www.myblog.com</a>. Please e-mail me at me@email.com."

auto_link(post_body, :all, :target => "_blank")
# => "Welcome to my new blog at <a href=\"http://www.myblog.com/\" target=\"_blank\">http://www.myblog.com</a>. Please e-mail me at <a href=\"mailto:me@email.com\">me@email.com</a>."

Todos os métodos continuam funcionando da forma antiga por enquanto, mas alertas serão emitidos no terminal para lembra-lo de atualizar seu código o mais rápido possível.

Jamis Buck acabou de anunciar o lançamento da versão 1.2.3 do gem SQLite3-Ruby.

Entre as novidades está uma correção nas permissões dos arquivos database.rb e translator.rb, que na versão 1.2.2 estavam incorretas, o que acarretava em impedir a instalação em sistemas *nix. Também foram incluídas melhorias no código para aumentar a compatibilidade com o futuro Ruby 1.9, além de melhorias na performance.

Os leitores mais atentos devem ter notado a diferença no número da versão no título deste artigo e na primeira linha do texto. Isto se dá, porque minutos depois do anúncio de Jamis, ao atualizar a versão na minha máquina foi instalada a versão 1.2.4, possivelmente alguma coisa deu errado e um patch emergencial foi necessário.

Para atualizar ou instalar:

gem install sqlite3-ruby

Gregg Pollack e Jason Seifer, os malucos do Rails Envy inovaram mais uma vez.

Primeiro foram os vídeos satirizando o comercial da Apple, depois foi a vez do famoso Rails Envy podcast e dos vídeos preparados para o RailsConf, agora os caras lançaram um projeto chamado Envycasts.

No momento eles publicaram apenas um screencast com o tema “Advanced ActiveRecord“. A diferença é que eles usaram um fundo verde para gravar o vídeo o que permitiu que eles literalmente interagissem com o código e slides.

O primeiro vídeo tem 37 minutos de duração e custa 9 dólares.

A comunidade Rails de língua inglesa esta muito bem servida, agora já possuem os screencasts do Railscasts, Peepcode, Pragmatic Screencasts, Learning Rails Podcast/Screencast além desta nova séria produzidos por Gregg e Jason.

Aqui no Brasil, temos alguns poucos que iniciaram trabalhos neste sentido, mas infelizmente depois de um tempo os projetos são interrompidos, e eu sei exatamente qual é o motivo: “Falta de retorno da comunidade“. O público atingido por um screencast em português é infinitamente menor que o atingido por um screencast em inglês.

Eu mesmo me aventurei pelo mundo dos screencasts no passado, para relembrar clique aqui.

Neste blog publiquei alguns poucos artigos em inglês, mas a quantidade de acessos que recebi (e ainda recebo) neles é quase 20 vezes maior que o artigo mais famoso escrito em português. Claro que o motivo disto acontecer é óbvio, o mundo inteiro fala inglês.

Então, como manter os criadores de conteúdo motivados para continuar produzindo podcasts, screencasts e escrevendo artigos, tutoriais e livros? É muito fácil, comentando, agradecendo e recomendando seus sites e projetos para amigos. A medida que a quantidade de comentários e visitas cresce, mesmo que seja exponencialmente menor do que a realidade para conteúdo em inglês, ainda assim é um estimulo para continuar.

Pense da seguinte forma, por mais barato que seja, este podcast produzido pela Rails Envy não é de graça e eles devem conseguir uma boa grana devido a grande quantidade de downloads. No Brasil fazer algo deste tipo não é viável, já que o preço do screencast teria de ser altíssimo para compensar o fato de que poucos downloads serão feitos.

Quando ler, assistir ou ouvir algo que goste sobre Ruby on Rails, pense nisto, você está comprando um produto de qualidade e o preço é um simples comentário de agradecimento. Mantenha a pessoa estimulada, você só tem a ganhar com isto.

No episódio desta semana damos mais detalhes sobre a vulnerabilidade de Denial of Service no REXML, e também falamos sobre daemon_controller, EnglishLikeQueries, NeverBlock, Colorist, WhatLanguage, MooTools, RGhost, HAML, ObjectSpace, JMonkeyEngine, PostgreSQL, Factory Girl (que não é uma fabrica de mulheres) e mais um monte de coisas que deve interessar qualquer Railer de plantão.

Download: Episódio #29
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

Neste episódio

• Vulnerabilidade de Denial of Service no REXML - Atualizem seus Rails!
• GitHub Shirts Now Available!
• Re: Strange HTTP header?
• Pull Request Auto-Responder
• daemon_controller: a library for robust daemon management
• EnglishLikeQueries
• NeverBlock: Fast, Non-Blocking IO In Ruby Without Changing Program Flow
• My First Ruby/Rails Contribution: SmartMonth
• Zero to Production in 15 Minutes
• Colorist: Color Manipulation For WebHeads
• Interview with David Heinemeier Hansson: Rails Culture, Scaling Basecamp, and Building Successful Companies
• WhatLanguage: Ruby Library To Detect The Language Of A Text
• Tutorial de Rails Caching – Parte 1
• MooTools Basic Tips for Web Designer (Lesson 1)
• RGhost On Mac OSX
• Cheating on ERB with HAML
• Ruby’s ObjectSpace: Subclasses
• aprendendo-rails
• Migrating Mephisto Plugins to Drax 0.8
• Screencasting: How To Start, Tools and Guidelines
• Rails and REST: Don’t use auto-incremented database IDs as your resource identifier
• JRuby + JMonkeyEngine = Hello 3D World
• 101 Reasons Why PostgreSQL is a better fit for Rails than MySQL
• factorygirlon_rails
• Phusion Passenger on Amazon EC2
• bossman-gem
• MySQL asynchronous balancing with HTTP+JSON

O método error_message_on é extremamente útil. Com ele podemos exibir mensagens de erro retornadas por determinados métodos em um objeto de uma forma bem simples.

<%= error_message_on "post", "title" %>

<!-- ou -->

<%= error_message_on @post, "title" %>

Isto fará com que uma mensagem de erro seja exibida na sua página dentro de uma tag DIV, caso um erro esteja associado ao campo title do modelo post.

Mas o mais interessante do método error_message_on é que podemos personaliza-lo para que exibida mensagens mais amigáveis. E é aqui que entra a alteração para o Rails 2.2.

Na versão atual os parâmetros de personalização são passadas diretamente para o método, mas no Rails 2.2 serão passadas via um Hash de opções:

<%= error_message_on "post", "title",
      :prepend_text => "Title simply ",
      :append_text => " (or it won't work).",
      :css_class => "inputError" %>

Fique tranqüilo quanto a uma possível migração de seus projetos atuais, pois o código está preparado para funcionar também da forma antiga (pelo menos por um tempo), mas emitindo um aviso de alerta para que o código seja atualizado.

Este tipo de alteração está se mostrando uma tendência no código do Rails, pois deixa o código mais legível. Então esperem por mais alterações deste tipo.

Pelo menos em partes eu estava certo… clique aqui.

Não posso afirmar que o TibiaBR foi o culpado pela fraude, pode ser que não devido a grande comunidade em torno do jogo, mas muitos podcast que estavam entre os primeiros colocados não chegavam nem perto de serem bons podcasts.

De qualquer forma o concurso está suspenso até segunda ordem.

Às vezes você tem de rodar múltiplas cópias do mesmo projeto. Talvez você tenha um produto que será usado por vários clientes, ou talvez você apenas deseje rodar uma versão de teste e produção do seu software ao mesmo tempo.

A forma mais simples de se fazer isto é ter múltiplos (sub)domínios com uma instância do aplicativo em cada uma. Mas se isto não for possível você pode colocar seu aplicativo em um subdiretório e usar um prefixo na sua URL para distinguir as instâncias do seu software. Por exemplo, você poderia rodar vários blogs de usuários diferentes usando URLs como:

http://www.nomedojogo.com/fulano/blog
http://www.nomedojogo.com/sicrano/blog
http://www.nomedojogo.com/beltrano/blog

Nestes casos, os prefixos fulano, sicrano e beltrano identificarão as instâncias do aplicativo rodando em subdiretórios com os mesmos nomes. O roteamento do aplicativo começa depois disto. Você pode dizer ao Rails para ignorar esta parte das URLs quando uma requisição for feita, mas coloca-la nas URLs geradas por ele, configurando isto através da constante RAILS_RELATIVE_URL_ROOT ou do método AbstractRequest.relative_url_root.

Porém se seu projeto Rails estiver rodando sob o Apache, esse recurso já é ativado automaticamente, por isto na maioria dos casos não temos de nos preocupar em configurar isto hoje. Isto se você estiver usando Apache.

Porém, no Rails 2.2 o relative_url_root não será mais configurado automaticamente pelo HTTP header. Teremos de fazer isto manualmente, colocando uma linha mais ou menos assim no arquivo environment.rb de cada um dos aplicativos:

config.action_controller.relative_url_root = "/fulano"

Feito isto, seu aplicativo irá ignorar o prefixo “fulano” logo depois do domínio. Mas ao gerar URLs ele sempre colocará este prefixo para garantir que você estará acessando o projeto no subdiretório correto.

Este post é uma tradução deste artigo escrito por David Hansson.

Eu nunca gostei da idéia de livros com títulos como “for Dummies” ou “complete idiot’s guide to”,  mas o sucesso de vendas destes livros têm demonstrado que certamente muitas pessoas se identificam como iniciantes ou completos idiotas. A auto-depreciação é boa, apenas para mostrar uma linha íngreme entre abraçar a sua própria ignorância e garantir isto com certeza.

Isto vai muito além do tipo de livros que você está comprando. Eu já conheci muitas pessoas que parecem tão certos da sua falta de aptidões, que sempre dão o primeiro passo para barrar suas chances de sucesso. Embora, provavelmente há muitos gênios por aí, a maior parte das pessoas interessantes com quem falei eram pessoas bem inteligentes, mas desejavam estar acima da média.

Só porque você não sabe programar, criar um design, liderar ou fazer alguma coisa, isto não faz de você um idiota. A habilidade para fazer esta mais perto do que você imagina.

Eu comecei a programar de verdade depois dos meus 20 e poucos anos. Rails foi o meu primeiro projeto em Ruby. Jason não estudou para ser designer, mas é graduado em finanças. O mundo está cheio com as pessoas que não sabiam absolutamente nada do que estão fazendo há pouco tempo atrás e agora são altamente respeitados em suas áreas.

Se há algo que você não sabe como fazer neste momento, por favor, decida não ser um idiota. Você é tão inteligente quanto sempre foi, você só está tentando aprender algo novo. Defina a sua ambição de igualdade que: Não há qualquer razão para eu não ser tão bom quanto este cara ou garota que fazem o que eu quero fazer.

Na semana passada gravei um episódio especial do podcast junto com três figuras da nossa comunidade: Luca Bastos, Tino Gomes e Luiz Carlos Metzger. Foi um bate-papo muito legal onde falamos sobre o desafio de sobreviver em um mercado onde a maioria dos profissionais são jovens de 20 a 24 anos.

Foi uma primeira tentativa para um novo podcast com um tema um pouco mais genérico e não voltado somente para Ruby on Rails, como é o caso do Rails Podcast Brasil.

Infelizmente a conexão estava meio ruim e a gravação não ficou legal, gastei toda a minha habilidade tentando corrigir o problema, mas não deu. De qualquer forma deu para salvar alguns trechos do podcast e para não desperdiçar vou tentar coloca-los como citações no Rails Podcast Brasil.

Eu agradeço muito a este trio que colaborou com a gravação. Vamos tentar novamente qualquer dia destes!

O método number_with_delimiter recebeu uma nova implementação. Além de uma melhora no código para que fique mais limpo a assinatura do método também mudou. Veja a antiga:

def number_with_delimiter(number, delimiter=",", separator=".")

# Exemplos de uso
number_with_delimiter(12345678) # => 12,345,678
number_with_delimiter(12345678.05) # => 12,345,678.05
number_with_delimiter(12345678, ".") # => 12.345.678
number_with_delimiter(98765432.98, " ", ",")

E a nova:

def number_with_delimiter(number, *args)

# Exemplos de uso
number_with_delimiter(12345678) # => 12,345,678
number_with_delimiter(12345678.05) # => 12,345,678.05
number_with_delimiter(12345678, :delimiter => ".") # => 12.345.678
number_with_delimiter(12345678, :seperator => ",") # => 12,345,678
number_with_delimiter(98765432.98, :delimiter => " ", :separator => ",")

Então atenção, agora ao usarmos o método number_with_delimiter devemos informar as opções na chamada do método.

Olá! Bem-vindo a mais um Rails Podcast Brasil!

Um episódio curto, já que o episódio anterior foi feito no fim da semana passada e pouco tempo se passou até este podcast. Esta semana falamos sobre Thread-safe no Rails 2.2, Shoes, Gist, HPricot e mais uma vez de Rails no Windows…

Download: clique aqui
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

Neste episódio

• Happy Hour de Railers de Sampa
• Prêmio Podcast 2008
• Tradução: O que Rails (2.2) Thread-safe significa?
• MRI Ruby + MySQL + Threads == Stop the world… JRuby doesn’t
• Josh Peek officially joins the Rails core
• Novo tema do site: RedWhite
• Shoes – Ruby’s Cross Platform GUI App Toolkit – Grows Up
• Hacking a Gist API with Mechanize
• APIdock about to roll out… with Ruby and RSpec!
• RedCloth Cookbook: How Tos, Recipes, F.A.Qs – Using the Ruby Plain Text to Web Markup Gem
• Build Better Pages With Firebug
• Telling a good story – Rspec stories from the trenches
• gist-it
• method_missing in JavaScript?
• Threaded XMLHttpRequest In Shoes
• An HPricot-style interface to LibXml-Ruby
• The Complete Guide for You to Become an Almighty jQuery Developer
• i18ndemoapp
• RedCloth Cookbook: How Tos, Recipes, F.A.Qs – Using the Ruby Plain Text to Web Markup Gem
• Salvação para usuários Windows: andLinux!

Até o próximo podcast!

 

 Rails Podcast Brasil - Episódio 28 [38:28m]: Play Now | Play in Popup | Download

Não, não foi inveja do Akita. Eu já estou arrumando este layout há mais de uma semana e terminei o básico nesta madrugada. Ainda faltam coisas para ajustar mas vou fazendo isto com o tempo.

E aí o que achou?

Pessoal, agora precisamos da ajuda de vocês. Eu sei que esses prêmios não valem nada, mas é uma forma de ajudar a divulgar o podcast para as massas, e por tabela divulgar nosso querido Ruby on Rails.

Para votar no Rails Podcast Brasil, basta clicar na imagem acima.

Mas, se você é fã do Rails Podcast Brasil e quiser ajudar mais ainda, depois de clicar, peça para seus amigos fazer o mesmo.

Você também pode colocar um banner igual a este aí do lado no seu blog, para isto copie o código abaixo e coloque no seu site.

<a href="http://www.premiopodcast.com.br/index.php?a=in&u=carlosbrando"><img src="http://www.premiopodcast.com.br/button.php?u=carlosbrando" alt="Prêmio Podcast 2008" border="0" /></a>

Ajude a divulgar o Rails Podcast Brasil!

Se você ainda não sabe o que são ETags, leia o último post desta série.

Este recurso já foi efetivamente incluido no branch oficial do Rails, mas junto com ele também ganhamos mais dois novos métodos que devem facilitar a forma como vamos implementar isto em nosso código. Os métodos etag! e last_modified!.

Veja a implementação destes métodos direto do código fonte do Rails:

# Sets the Last-Modified response header. Returns 304 Not Modified if the
# If-Modified-Since request header is <= last modified.
def last_modified!(utc_time)
  head(:not_modified) if response.last_modified!(utc_time)
end

# Sets the ETag response header. Returns 304 Not Modified if the
# If-None-Match request header matches.
def etag!(etag)
  head(:not_modified) if response.etag!(etag)
end

Isto facilita muito as coisas. Veja como ficaria o exemplo dado no último post usando estes novos métodos:

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    etag! @article
    last_modified! @article.published_at.utc
  end
end

Bem mais simples!

O Carlos Júnior já escreveu sobre isto no blog da milk-it. Provavelmente teremos suporte a ETags no Rails 2.2. Eu disse provavelmente porque isto ainda não foi incluído no branch oficial do Rails, mas como é algo importante e está sendo feito pelo core team, é quase certo de que será.

Antes de começar a falar sobre isto, deixa eu tentar explicar o que são ETags (Entity Tags). Etags seriam de uma forma grosseira identificadores associados a cada recurso para determinar se o arquivo que está no servidor é o mesmo que está no cache do browser. No caso, o recurso seria uma página em HTML, mas também poderia ser um XML ou JSON.

Cabe ao servidor a responsabilidade de verificar se o recurso solicitado é igual dos dois lados. Caso o servidor confirme que o recurso armazenado no cache do browser do usuário é exatamente o mesmo que seria enviado de volta para ele, ao invés de devolver todo o conteúdo do recurso novamente ele apenas retorna um status 304 (Not Modified) e o browser usará o que está em seu cache.

Servidores Web como o Apache e o IIS já sabem fazer isto para página estáticas. Mas quando o conteúdo é dinâmico, como na maioria das páginas de um projeto Ruby on Rails, a responsabilidade é todo nossa.

O objeto response ganhou dois novos métodos, o last_modified= e o etag= (note o sinal de igualdade “=”). Quando você atribuir valores a estes métodos eles serão repassados aos cabeçalhos HTTP_IF_MODIFIED_SINCE e HTTP_IF_NONE_MATCH respectivamente. Quando uma nova requisição (request) deste recurso for feita ela retornará com estes cabeçalhos permitindo que você possa comparar com o novo valor informado no response e decidir se quer enviar todo o conteúdo do recurso novamente ou apenas um status 304.

Vamos ao código (roubando o exemplo dado por Ryan Daigle no seu blog):

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    # informado o identificador
    response.last_modified = @article.published_at.utc
    response.etag = @article

    # verificando se houve mudanças
    if request.fresh?(response)
      head :not_modified
    else
      respond_to do |wants|
        # retornando conteúdo normalmente
      end
    end
end

Note que estou atribuindo valores para response.last_modified e response.etag, e logo em seguinda usando o método request.fresh?(response) para determinar se houve alguma mudança ou não. Caso os dois cabeçalhos continuem iguais eu apenas retorno um status 304 e o browser do usuário usará o conteúdo que está armazenado no seu cache.

Quanto ao método etag, também podemos passar um array se for o caso:

response.etag = [@article, current_user]

A forma como foi implementado isto no Rails está causando um certo desconforto em muita gente e várias outras formas foram sugeridas pela comunidade, então possivelmente isto pode mudar antes do lançamento da versão 2.2.

Veja algumas sugestões dadas: in_modified_scope e with_etag_cache.

Está virando moda gravar o podcast de madrugada. Esta ficando difícil conciliar os horários para a gravação!

Neste episódio contamos as últimas novidades do Rails Summit Latin America, e desvendamos o que é esse tal de Adhearsion que promete ser o próximo killer app do Ruby. Também falamos sobre uma tal blogueira na comunidade, Getting Real 2, map and reduce, como ser sua própria Start-Up, Erlang e para fechar da dança do quadrado… digo Ruby ao quadrado.

Download: clique aqui
iTunes: http://podcast.rubyonrails.pro.br/rss
Episódios anteriores: http://podcast.rubyonrails.pro.br/

Neste episódio:

• Rails Summit Latin America
• openSteam
• Adhearsion – next killer app for Ruby?
• Sproutcore – A Page a Day…
• Editando código online via GitHub 14 Aug
• The Ruby Hoedown in 10 minutes
• Exceptional
• Phusion
• Criando uma Tela de Login
• Getting Real 2 update: First draft done, publisher search continues
• Ruby 1.9: What To Expect
• Ruby’s Exception Hierarchy
• Asynchronous DB: DBSlayer & HTTP
• iphone-universal
• Understanding map and reduce
• Hadoop: When grownups do open source
• Plugin inplaceedit agora com suporte a i18n
• RubyGems: With power comes responsibility
• jQuery é bom para designers
• Rails on IntelliJ
• Ruby Snapshot #4: Conectando no orkut / Google
• Walkthrough: Silverlight Flickr Client in IronRuby
• Be Your Start-Up
• Mais Erlang
• Ruby ao quadrado

Alguns de vocês já devem conhecer o método assert_queries que ajuda a validar nos testes a quantidade de queries executadas. Por exemplo:

assert_queries(Firm.partial_updates? ? 0 : 1) { firm.save! }

No teste acima estou afirmando que se houver partial_updates uma query deve ser executada no banco de dados, caso contrário nenhuma deve ser executada.

Agora ganhamos mais um helper para ajudar a testar o tipo de query executada, o método assert_sql. Um exemplo:

def test_empty_with_counter_sql
  company = Firm.find(:first)
  assert_sql /COUNT/i do
    assert_equal false, company.clients.empty?
  end
end

No exemplo acima estou afirmando que no bloco informado ao método pelo menos uma query deve conter a palavra COUNT. Obviamente você pode ser mais especifico na expressão regular que estiver usando. Vamos pegar um outro exemplo:

assert_sql(/\(\"companies\".\"id\" IN \(1\)\)/) do
  Account.find(1, :include => :firm)
end

Use com parcimônia!

via Melhores do Mundo

Muitas vezes a opção :index do método select pode ser útil, como por exemplo quando se precisa criar diversos dropdowns dinamicamente em uma página.

Até hoje o método fields_for não repassava esta opção para métodos como select, collection_select, country_select e time_zone_select, o que limitava o seu uso em determinados casos.

Isto já foi corrigido para a próxima versão do Rails. Por exemplo, apenas para efeito de teste veja o código abaixo e o seu retorno:

fields_for :post, @post, :index => 108 do |f|
  concat f.select(:category, %w( abe <mus> hest))
end

<select id=\"post_108_category\" name=\"post[108][category]\">
  <option value=\"abe\">abe</option>
  <option value=\"&lt;mus&gt;\" selected=\"selected\">