Following on the steps of Dr.Nic, the guy from the Ruby on Rails fame and the one that recommends everyone to have a domain name with their own name, I decided to move this blog from LevyOnRails.com to the domain LevyCarneiro.com.

I found having "Rails" in the name was a little restrictive, being I wanted to cover a wider spectrum of Web technology knowledge. And why not, sometimes post things about my hobbies and other stuff I find interesting.

I also changed from a Rails custom blog, to using Wordpress, which I find is much more suited for the task, since I didn't have much time to add everything I wanted, and Wordpress is ready with so many plugins, widgets and themes already to use. Being pragmatic is good!

That's it.

So please add the new feed to your reader:
http://feeds2.feedburner.com/LevyCarneiro

Please visit the new site from now on.

Thanks for watching!

O Twitter se tornou uma grande ferramenta para interação social, já até ameaçando o conteúdo oferecido em blogs.

Indo ainda mais longe, alguns já falam que não importa mais quantos seguidores você tenha no Twitter, mas que a pessoa com maior autoridade é aquela com o maior número de mensagens "retweetadas", mostrando então que o que esta pessoa escreve é conteúdo bom e merece ser repassado a todos.

O projeto Trânsito Não! é um experimento social com Twitter e um assunto que deixa todo mundo fora de si: o trânsito. Este website conta tweets enviados como idéias e/ou votos, gerando um espaço público de discussão sobre um dos problemas mais urgentes destes dias.

Este projeto é direcionado a todo o Brasil, só que mais especialmente aquelas pessoas que vivem na Grande São Paulo, uma região com cerca de 17 milhões de habitantes que experimentam um dos maiores volumes de tráfego de veículos do mundo.

Usei Ruby on Rails para construir este site. Este framework web oferece grande produtividade ao desenvolvedor. Se você ainda não assistiu, não deixe de ver este vídeo que mostra a criação de um blog em apenas 15 minutos usando Ruby on Rails.

O sistema de votação funciona assim: você envia um tweet (no Twitter) com uma idéia ou solução para resolver o problema do trânsito. Esta idéia vira então uma "idéia" dentro do Trânsito Não! Cada retweet da sua idéia, vira um voto. Então quanto mais a sua idéia se espalhar no Twitter, mais votos ela recebe no site. Os tweets são obtidos do Twitter através de uma API que é lida a cada minuto. As idéias ou votos são adicionados ao banco de dados, e as páginas são geradas novamente.

Você pode me encontrar em meu blog, Twitter, ou por e-mail.

Twitter has become a great tool for social interaction, and it's also gaining more authority than content in blogs.

Going even further, some people say it doesn't matter how many followers you have on Twitter, but instead what matters is how many times your tweets get forwarded by those following you, showing that this person writes more valuable content, which deserves to be sent over to other people.

The project Trânsito Não! (which stands for "No To Traffic!") is a social experiment with Twitter and a subject that gets everyone mad: the traffic jams. This web app cast tweets as ideas and/or votes, generating a public web space to debate on one of the most urgent problems of these days.

This project is aimed at the Brazilian people, specially those people living in the greater area of Sao Paulo, a region with about 17 million people experiencing one of the biggest car traffics in the world.

I developed this website with Ruby on Rails. This web framework offers great productivity to the developer. If you haven't the chance yet, don't miss this video showing a complete web blog written in only 15 minutes using Ruby on Rails.

The voting works like this: you tweet some idea or solution for the traffic problems, followed by the hashtag #transitonao. This tweet becomes a "idea" on TransitoNao website. If your tweet gets retweeded X times, these X times become votes for your idea. So the longer your idea spreads, the more votes you get. New tweets are read from the Twitter API every minute, being added to the database, and the pages being also refreshed (using page caching).

You can find me on my blog, Twitter, or at my personal email.

This guy put together a presentation on what is SCRUM. It's very informative and to the point. "By the end of this fast-paced video, you'll know about burn-down charts, team roles, product backlogs, sprints, daily scrums and more."

I'm so glad I'm able to breathe, because this guy wasn't :)

Here's a quick tip on how to test those helpers such as 'new_post_path' and 'home_path'. Also those formatted routes such as 'formatted_posts_path'. And why is important to test those.

Here's how I test route helper methods.

# spec/controllers/ideas_controller_spec.rb

describe IdeasController do
  describe "GET /ideas/new" do
    it "should have helper method new_idea_path" do
      get :new
      new_idea_path.should_not be_nil
      new_idea_path.should == '/ideas/new'
    end

    it "should have helper method formatted_new_idea_path" do
      get :new, :format => :json
      formatted_new_idea_path.should_not be_nil
      formatted_new_idea_path.should == '/ideas/new.json'
    end

    (...)
  end
end

And why it's important to test those methods, since they're already tested by Rails tests?

Rails 2.3 has removed all those formatted_xxx named routes. Turns out these routes ate up a lot of memory and served minimal purpose. Read article here.

So if you use something like formatted_new_user, and you need to upgrade the application to Rails 2.3, it would be broken without test coverage.

Here's a tip for creating a generic Cucumber step, handling the Webrat visit method.

Imagine you have many Cucumber scenarios, and you have many steps like these:

  Given I am on the new task page
  Given I am on the new project page
  Given I am on the home page

This way you'd have to create mapping between these strings above, to real paths inside the application. You could use the method 'path_to', which is already provided with Cucumber, inside features/support/paths.rb. That could lead to something like this:

# features/support/paths.rb

def path_to(page_name)
  case page_name

  when /new task/i
    new_task_path
  when /tasks/i
    tasks_path

  when /new user/i
    new_user_path
  when /users/i
    users_path

  when /home/i
    root_path

  # and so forth...

  else
    raise "Can't find mapping from \"#{page_name}\" to a path."
  end
end

Or you could use something more generic and more maintanable.

So, let's take advantage of the path helpers already provided by Rails such as new_task_page, tasks_path, home_path, and do this instead:

  Given I am on the new_task page
  Given I am on the new_project page
  Given I am on the home page

And add this to your create_task_steps.rb:

# features/step_definitions/create_task_steps.rb

Given /^I am on the (.+) page$/ do |page_name|
  eval("visit #{page_name}_path")
end

This way Webrat will visit the path: new_page_path, and you won't have to maintain the paths.rb file.

Gregg Pollack and New Relic just launched a Screencast series on Scaling Rails. And, it's free! :)

"Learn everything you need to know about Scaling your Rails app through 13 informative Screencasts produced by Gregg Pollack with the support of New Relic. In the next few weeks we’re going to bring you 13 educational videos, teaching you just about everything you need to know to create a Rails application that can scale."

Topics covered:

• Introduction
• Episode #1 - Page Responsiveness
• Episode #2 - Page Caching
• Episode #3 - Cache Expiration
• Episode #4 - New Relic RPM
• Episode #5 - Advanced Page Caching
• Episode #6 - Action Caching
• Episode #7 - Fragment Caching
• Episode #8 - Memcached
• Episode #9 - Client Side Caching
• Episode #10 - Advanced HTTP Caching
• Episode #11 - Database Speed, by Taylor Weibly from EngineYard
• Episode #12 - Deployment Strategies, by Jesse Newland from RailsMachine
• Episode #13 - New Relic Advanced Features, by Jim Gochee from New Relic