shadowmaru.org

Como o Marcio Trindade falou no seu blog, implementei, junto com a equipe da DBurns Design, um e-commerce em Rails usando como base o Spree.

O Spree tem o básico para um e-commerce: produtos, carrinho de compras, checkout, pagamento por cartão de crédito (usando o ActiveMerchant) e taxonomias (categorização). O resto pode ser customizado por você mesmo usando extensões. No nosso caso, fizemos uma extensão para mudar todo o layout da loja, outra para as páginas de conteúdo usando o nosso CMS próprio, outra para imagens para imprensa, e adicionei uma extensão para busca feita pelo Edmundo Valle Neto. O site não está no ar ainda, mas deve estar em breve.

Durante o desenvolvimento do projeto, notei que faltavam algumas features que o cliente exigia: suporte a SSL e pagamentos através do Authorize.Net (até então suportava apenas Linkpoint e PayPal). No melhor espírito open source, postei na lista, o mantenedor (Sean Schofield) me pediu para implementar e o fiz. O Sean aprovou os patches e os incorporou ao projeto, portanto agora o Spree suporta pagamentos pelo Authorize.Net e SSL.

Paperclip é um plugin para Rails que permite o upload de arquivos para a aplicação, e ainda faz transformações em imagens usando o ImageMagick. Também possibilita o armazenamento do arquivo no próprio servidor, ou em serviços como o Amazon S3.

Comecei a usá-lo em abril, algum tempo depois de ser lançado em março. Achei um plugin mais fácil de usar e mais simples que o attachment_fu, por exemplo. Agora vejo muita gente migrando do attachment_fu para o Paperclip, saindo posts em vários blogs da comunidade, como Carlos Brando, Peter Cooper (via Rails Inside) e Ryan Bates.

Um problema comum que estou vendo em muita gente que está começando a usar o Paperclip (EDIT: e se estiver usando Passenger, como bem lembrou o dookie) é subir uma imagem que tenha diferentes versões (:medium e :thumb, por exemplo), mas só aparecer no diretório a versão original. Isso geralmente acontece porque você precisa configurar o caminho para o executável do ImageMagick, o convert.

Então, se você estiver em um sistema *nix, digite:

which convert

e ele retornará o caminho, no meu caso /usr/local/bin/convert.

Daí é só criar um initializer (em config/initializers), por exemplo, paperclip.rb e colocar o conteúdo:

Paperclip.options[:image_magick_path] = '/usr/local/bin'

Se quiser ter configurações diferentes dependendo do ambiente, faça:

1
2
3
4
5

if RAILS_ENV=development
     Paperclip.options[:image_magick_path] = '/usr/local/bin'
else
     Paperclip.options[:image_magick_path] = '/opt/local/bin'
end

Agora reinicie o servidor e tente subir a imagem novamente.

#ficaadica

Bom, agora que escrevi sobre o que aconteceu nos dois dias de Rails Summit Latin America (dia 1 e dia 2), vou falar sobre o que esta experiência significou para mim.

Sempre participei de eventos de tecnologia, congressos e etc., mas introvertido que sou, sempre fiquei na minha e só assistia. A Rails Summit proporcionou um encontro com pessoas que eu já conhecia online, na lista rails-br, no twitter, e também presencialmente, como no happy-hour de railers em Agosto e o pessoal da Webco. Foi muito legal ser reconhecido pelo que faço online (“ah, você é o Shadow…”).

Mais que isso, os palestrantes se mostraram muito abertos à conversa, e socializaram bastante durante o evento e após ele. Vai parecer propaganda de cartão de crédito, mas a possibilidade de conversar com Chad Fowler, Obie Fernandez, Dr. Nic, Hongli Lai e Ninh Bui (além dos palestrantes brasileiros) não tem preço. Fora o pessoal que nem era palestrante mas estava lá. Guilherme Chapiewski por exemplo. O ingresso para o evento ficou muito barato de repente.

O que quero dizer com isso é: não perca essas oportunidades. Às vezes não é nem pelo conteúdo das palestras, mas pelo networking e pela chance de aprender com as feras. Não reclame de preço. É por isso que os eventos não falam em custo. Falam em investimento. E realmente é um investimento, na sua carreira e em você como pessoa (aproveitando o gancho motivacional de algumas palestras do Summit).

E é isso.

O segundo dia do Rails Summit Latin America (veja o primeiro dia) começou bem. O pessoal da Phusion (Ninh Bui e Hongli Lai) deu uma palestra show sobre o Passenger e escalabilidade, com direito a Megaman, Star Wars e Scarlett Johansson.

A palestra seguinte foi uma videoconferência com Charles Nutter e Thomas Enebo, sobre JRuby. Não sou dos maiores fãs de Java, então não prestei muita atenção à apresentação, que por problemas de conexão teve muitas falhas de áudio.

A seguir começaram as sessões paralelas. Eu assisti somente às brasileiras, já que as estrangeiras estavam sendo gravadas. A primeira foi do George Guimarães, do Pagestacker, sobre como colocar uma aplicação Rails em produção e monitorá-la.

Depois do almoço, duas palestras sobre empreendedorismo, de duas empresas brasileiras. A primeira foi da WebCo, dada por Manoel Lemos, Ronaldo Ferraz e Nando Vieira. Como começou o BlogBlogs, como ele cresceu e o que foi feito para escalar a aplicação. Também falaram sobre o Brasigo e o dia-a-dia da empresa.

A segunda palestra foi do Vinicius Teles, da ImproveIT. Foi uma palestra dividida com o Carl Youngblood, da Surgeworks, mais uma vez falando motivacionalmente, como você pode fazer a diferença, principalmente no Brasil.

A palestra seguinte foi sobre testes automatizados, com o Danilo Sato. Foi uma passagem sobre os testes que você pode fazer na sua aplicação Rails e alguns problemas e lições aprendidas com os testes.

As sessões paralelas seguintes não me interessavam (Ruby on Windows e mais JRuby), então aproveitei para começar a escrever este post :)

O keynote de encerramento foi do Obie Fernandez, falando sobre a Hashrocket e como eles adotam os princípios do Manifesto Ágil da sua própria maneira. Como muitas outras palestras nesta Rails Summit, muito inspirador.

Assim acabou a Rails Summit (oficialmente). Mas espere, tem mais! No próximo post….

O Rails Summit Latin America começou no dia 15/10, no Auditório Elis Regina, no Anhembi. É o maior evento de Ruby on Rails da América Latina, e trouxe alguns dos maiores nomes de Rails do mundo.

O primeiro dia teve a abertura de Gilberto Mautner e Fabio Akita, da Locaweb. Logo em seguida tivemos uma sessão de perguntas e respostas com David Heinemeier Hansson (DHH), o criador do Rails. Ele respondeu perguntas ao vivo da platéia através de videoconferência. Apesar de algumas perguntas parecerem suporte técnico, outras foram bem interessantes, como sobre as novidades do Rails 2.2 e o futuro do framework.

Em seguida tivemos o keynote de Chad Fowler. Chad, sem a barba que lhe é característica, falou sobre como ser marcante (remarkable). Segue mais ou menos a linha do seu livro, “My Job Went to India”. Algumas frases da apresentação foram realmente marcantes, como:

Cada dia faça uma coisa melhor que o dia anterior

Você é um produto

Faça barulho

Depois do almoço, na sessão dupla, assisti à palestra de George Malamidis e Danilo Sato, que falaram sobre REST. Foi uma palestra bem teórica, e boa para quem ainda não está familiarizado com o conceito de RESTful Web Services. A palestra paralela, que não assisti, foi do Akita, que pelo que ouvi, foi bem básica, sobre o básico de Rails.

A palestra seguinte foi do Dr. Nic Williams, cujo tema foi “Todos podem contribuir”. Foi bastante similar à do Chad Fowler, motivacional, incentivando todos a contribuir para projetos open source, e falou sobre os ‘segredos’ para se tornar sensacional: aprenda testes unitários, comece um blog, aprenda a criar, e melhore seus conhecimentos. A sessão paralela foi com Carlos Brando, que falou como é trabalhar para uma empresa de fora do Brasil.

Todos voltaram ao auditório principal para o keynote de Chris Wanstrath, do github. Uma palestra também motivacional, muito parecida com a que ele deu no Ruby Hoedown deste ano.

Após a última palestra, começou o Birds of a Feather, que na verdade acabou sendo Lighting Talks, palestras bem rápidas sobre algum assunto relacionado. Infelizmente alguns participantes não captaram a mensagem e falaram sobre coisas totalmente sem relação com Ruby ou Rails, inclusive política (?). As melhores, sem dúvida, foram a do pessoal da Phusion, que demonstraram um interpretador Brainfuck em Ruby, e a do Elomar França, de apenas 17 anos, que deu um show na sua apresentação sobre o grupo de estudos aprendendo-rails.

Assim acabou o primeiro dia de Rails Summit. Hoje tem mais!

Há algum tempo (acho que dois anos) tomei contato com esse framework impressionante que é o Rails. Desde então decidi que iria investir no aprendizado da linguagem (Ruby) e do framework (Rails), assim como seus usuais agregados: Mac OS, Git, BDD, Agile methods, para algum dia trabalhar a maior parte do tempo com isso, visto que estava preso a vários sistemas que estavam em PHP.

Agora tudo começa a valer a pena. A partir deste mês sou mais um railer a se juntar ao excelente time da DBurns Design. Será fascinante trabalhar full-time com aquilo que eu me dediquei tanto a aprender: Rails, Git, BDD, XP, Scrum, e por aí vai, ainda mais com uma equipe que está crescendo e se dedicando cada vez mais ao Rails.

Agradeço os meus colegas de trabalho da Space que me aguentaram por mais de sete anos, mas é hora de mudar.

Este post é para designers que pretendem trabalhar com Rails e querem um guia inicial para poderem se dar bem com o programador. É bem introdutório, então muita gente que já conhece Rails vai falar 'putz, isso é muito básico'. E é mesmo. Mas pra quem não manja nada de programação vai ajudar. Vou falar de MVC, a estrutura do Rails e também sobre partials e helpers (um pouco mais avançado).

MVC

MVC quer dizer 'Model, View, Controller' e é um jeito de separar as camadas de um sistema. O que vai interessar a você são as Views, que são o front-end do sistema. Você não vai ter que ficar olhando aquele código enorme de programação antes do seu HTML. Talvez nem no meio. Só para complementar, no Model são implementadas as regras de negócio do sistema e as conexões com o banco de dados, e no Controller a lógica de processamento, ou seja, a intermediação do Model com as Views. É no controller que as variáveis que serão usadas nas Views são geradas.

Estrutura do Rails

Para facilitar a sua vida, todos os arquivos que você precisará editar estão ou em app/views/ ou em public/.

Existem duas estruturas básicas para as URLs em Rails, uma seguindo o padrão REST e outra que era padrão até o Rails 1.2. Você não precisa saber exatamente o que é REST, mas preicsa saber qual view editar. Qualquer dúvida, pergunte ao programador se ele está usando alguma rota específica ou fora do padrão. Para não complicar muito, digamos que o seu sistema segue o padrão REST (ou seja, é RESTful):

http://dominio.com/posts/1

Segundo o padrão REST do Rails, o controller posts vai chamar a action 'show', portanto o arquivo que você terá que editar será o app/views/posts/show.html.erb

Já se a URL for

http://dominio.com/posts/new

o arquivo será app/views/posts/new.html.erb

Public

No diretório public/ estão todos os artefatos que você normalmente usa numa página web: imagens, estilos, JavaScript, Flash, cada um no seu respectivo diretório:

• public/images
• public/stylesheets
• public/javascripts

E para chamá-los é só imaginar o diretório public/ como a raiz do seu domínio, por exemplo

<img src="/images/logo.jpg" />

Layouts

Bom, layouts são basicamente templates. Eles estão em app/views/layouts. É onde você inclui elementos comuns de um site, como topo, rodapé e o conteúdo principal vai no meio. Aquilo que vai no meio da página é o conteúdo das views e tudo em volta faz parte do layout. Bem, então como eu coloco esse conteúdo das views? É só incluir a tag <%= yield %> onde você quiser que ele apareça.

O padrão no Rails é que seja renderizado o layout com o mesmo nome do controller. Se esse layout não existir, app/views/layouts/application.html.erb é utilizado.

Um arquivo .html.erb é como se fosse um arquivo HTML normal, só que com algum código Ruby embutido (ERb é embedded ruby).

Vamos ver um exemplo de layout:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
 
  <head>
    <title><%= @title || "Título" %></title>
    <%= stylesheet_link_tag 'site' %>
    <%= javascript_include_tag 'application', 'prototype', 'effects' %>
  </head>
 
  <body>
    <div id="header">
      <%= render :partial => 'shared/header' %>
    </div>
    <div id="content">
      <%= yield %>
    </div>
    <div id="footer">
      <%= render :partial => 'shared/footer' %>
    </div>
  </body>
 
</html>

Veja, parece um HTML normal, que você já está acostumado a ver e escrever. Vamos ver alguns detalhes:

 <title><%= @title || "Título" %></title>

@title aqui é uma variável, que vai estar definida em algum controller. Se ela não existir, será usada a string "Título". O || quer dizer 'ou'.

1
2

<%= stylesheet_link_tag 'site' %>
<%= javascript_include_tag 'application', 'prototype', 'effects' %>

Estas são os helpers no Rails para inclusão de CSS e JavaScript. No caso, eles vão automaticamente gerar uma tag para /stylesheets/site.css e tags para os arquivos /javascripts/application.js, /javascripts/prototype.js e /javascripts/effects.js.

Existem muitos outros helpers que podem ajudar você (e o programador) a gerar código HTML. Para mais informações, consulte a API do Rails.

Partials

Vejamos esta chamada:

<%= render :partial => 'shared/header' %>

Já viu no PHP algo como

<?php include 'header.php';?> 

? Então, é parecido. São pequenos pedaços de HTML que são comuns a várias páginas que você gostaria de reutilizar. Aliás esse é um dos princípios do Rails: DRY (Don't Repeat Yourself). O arquivo que ele vai chamar tem que ter um '_' na frente, no caso app/views/shared/_header.html.erb.

DISCLAIMER: este artigo é inspirado e muito baseado neste post (embora não seja uma tradução literal): http://glu.ttono.us/articles/2006/03/21/rails-for-designers

No blog Riding Rails (o blog oficial do Rails), o DHH pediu para as pessoas contarem sua história pessoal com o Rails. Segue o post traduzido:

“Tenho recebido algumas histórias realmente tocantes sobre pessoas que se tornaram programadores Rails a partir de diversas origens durante esses anos. Eu até conversei uma vez com um taxista que estava me levando para o aeroporto que estava programando em Rails. Ou os caras que queriam largar a programação, mas começaram a se divertir noovamente com Rails.

Todas essas são histórias poderosas que eu adoraria poder compartilhá-las com o mundo. Então vamos tentar fazer isso! Se você tem uma ótima história sobre como você chegou ao Rails, então por favor mande para david arroba loudthinking ponto com com o assunto “My Rails story”. Eu flitrarei todas as mensagens em uma pasta e veremos um jeito de publicá-las”.

Minha história não é nada sensacional. Eu já era programador, quando um outro desenvolvedor foi contratado, e ele queria programar em Rails, e nos convenceu a fazer isso. Eu comecei a ver o que ele fazia, estudar e comecei a mexer com Rails também.

Mas quem sabe a sua história não é sensacional, a ponto do DHH publicá-la?

Além dos livros, uma outra forma de aprender Rails me ajudou muito: os screencasts. Eles são uma forma de aprendizado mais dinâmica que os livros, e mais visual que os podcasts. Segue uma lista dos screencasts que eu já assisti e recomendo:

• Peepcode – é um dos mais antigos, portanto um dos que tem mais conteúdo. É pago (9 USD cada) mas vale cada centavo, além de ter uma assinatura anual (149 USD). Os screencasts são longos, então cuidado para não dormir :) Por Geoffrey Grosenbach (putz, acertei de primeira)

• Railscasts – grátis, episódios curtos e focados. Excelente. Feito por Ryan Bates.

• Nome do Jogo – infelizmente o Carlos Brando interrompeu a série de screencasts, que ia muito na linha do Railscasts. Quem sabe não volta?

• Pragmatic Screencasts – pago também, feito por várias pessoas e organizado pela Pragmatic Programmers, mais conhecida pelos seus livros.

• Learning Rails – gratuito, e cobre o básico para criar sua aplicação Rails. Começou como podcast, e virou screencast.

• Envycasts – lançado recentemente, é pago (9 USD cada), a qualidade é ótima, o conteúdo muito bom e conta com todo o senso de humor do Gregg Pollack e do Jason Seifer, que vocês podem conferir também no Rails Envy e no Rails Envy Podcast.

Reparem que quase todos os screencasts são em inglês. Mais um motivo então para aprender inglês, que eu considero fundamental para qualquer programador, apesar de haver muito material traduzido por aí, com esforços da comunidade.

Parece que o segundo semestre se estabeleceu como o período dos grandes eventos, pelo menos na área de TI/Web. Depois de um primeiro semestre meio inerte, o segundo promete!

Tivemos nesta sexta-feira o primeiro Happy Hour de Railers em São Paulo, no Bar do Juarez. Foi bem legal, tinha umas 30 pessoas, incluindo gente da WebCo, Pagestacker e boo-box. Quem sabe isso não motiva encontros regionais em outras cidades?

Vamos ter o InterCon 2008, evento sobre web e tendências, onde vão palestrar grandes nomes da web/blogosfera brasileira, como Fabio Seixas, Manoel Lemos, Marco Gomes, Fabio Akita, Cris Dias e o grande Luli Radfahrer. O InterCon acontece no dia 25 de outubro e tem como tema a inovação digital. Eu vou!

Ainda em outubro, nos dias 15 e 16, teremos o grande evento de Rails do ano, que eu já mencionei no post anterior, aqui em São Paulo: a Rails Summit Latin America. Eu vou!

Sem confirmação ainda, deve acontecer em setembro o Minas on Rails. Se realmente acontecer, vou fazer um esforço para comparecer.

Isso fora o ExpoMoney, mas isso é assunto para outro blog.

Como o Fabio Akita anunciou no seu blog, em outubro (dias 15 e 16) haverá a Rails Summit Brazil Latin America 2008. Vai ser o primeiro grande evento de Rails no Brasil, com presenças internacionais como Chad Fowler, Obie Fernandez, Dr. Nic Williams e até o próprio DHH (por vídeo-conferência), e nacionais como Manoel Lemos e Vinicius Teles.

Para colaborar um pouco com o evento e a divulgação, resolvi fazer (inspirado por uma pergunta do Tapajós no Twitter) uma listagem dos hotéis que ficam perto do local do evento, o Anhembi, para as pessoas que não são de São Paulo. Não sei se haverá hospedagem oficial, mas o que importa é a liberdade de escolha :)

Segue a lista (os preços variam conforme o tipo de quarto):

• Holiday Inn Parque Anhembi
  É definitivamente o hotel mais perto, ele fica dentro do complexo do Anhembi.
  Diária: de R$250 a R$400
  
• Ibis Barra Funda
  Diária: R$135 (+R$9,50 com café da manhã)
  
• Novotel Center Norte
  Diária: R$145 a R$320
  
• Mercure Apt Nortel
  Diária: R$150 a R$220
  
• Best Western Metrô Tietê
  Não está disponível para o período. UPDATE: O Tapajós conseguiu reserva lá, então estou mudando o status.
  

Mais um projeto de tradução do qual eu participei (o outro foi o Learn to Program): é a tradução, desta vez do Português para o Inglês do e-book do Carlos Brando, sobre as novidades do Rails 2.1, lançado oficialmente durante a RailsConf 2008.

Traduzi somente o capítulo 14 (todos os outros já “tinham dono”), mas pelo menos pude contribuir. Foi o primeiro livro a ser lançado sobre o assunto, tanto em Português como em Inglês, e fico feliz por ter feito parte desse projeto. Agora deve sair até versão em italiano!

Veja a versão em Português

Veja a versão em Inglês

Gostou? Recomende o pessoal no Working with Rails!

Uma das melhores maneiras de se aprender uma linguagem (ou, no caso, um framework) é lendo um livro. O problema em aprender Rails através de livros é que a linguagem muda frequentemente, então as versões nas quais os livros foram escritos tornam-se desatualizadas muito rapidamente.

Veja as versões e suas datas de lançamento:

• Rails 1.0 – 13/12/2005
• Rails 1.1 – 27/03/2006
• Rails 1.2 – 17/01/2007
• Rails 2.0 – 06/12/2007
• Rails 2.1 – 31/05/2008

Para ajudar o iniciante que quer aprender Ruby on Rails, compilei uma lista com os livros mais populares com suas respectivas versões:

Agile Web Development with Rails 1ed. (2005)
Dave Thomas/David Heinemeier Hansson
Inglês
Rails 1.0

Agile Web Development with Rails 2ed. (2006)
Dave Thomas/David Heinemeier Hansson
Inglês
Rails 1.2

Agile Web Development with Rails 3ed. (beta)
Sam Ruby/Dave Thomas
Inglês
Rails 2.x

Rails Recipes (2006)
Chad Fowler
Inglês
Rails 1.1

Advanced Rails Recipes (2008)
Mike Clark
Inglês
Rails 2.0

The Rails Way (2007)
Obie Fernandez
Inglês
Rails 2.0

Rails for PHP Developers (2008)
Derek DeVries/Mike Naberezny
Inglês
Rails 2.0

Repensando a Web com Rails (2006)
Fabio Akita
Português
Rails 1.1.2

Rails para Desenvolvedores Java (2007)
Stuart Halloway/Justin Gehtland
Português
Rails 1.1

Ruby on Rails: Executando (2006)
Curt Hibbs/Bruce Tate
Português
Rails 1.1

Ajax on Rails (2007)
Scott Raymond
Inglês
Rails 1.1

Rails Cookbook (2007)
Rob Orsini
Inglês
Rails 1.2

Beginning Rails (2007)
Cloves Carneiro Jr./Jeffrey Allan Hardy
Inglês
Rails 1.2.3

Pode-se ver que a oferta é grande mas as versões não são as mais atuais. Minha sugestão: se não tiver acesso a um livro mais recente, aprenda com a versão do livro que você tem (e baixe a versão do Rails correspondente), e depois veja quais foram as alterações de uma versão para a outra.

Quick note: Este blog deve ficar fora do ar por algum tempo — espero que pouco — pois abri uma conta na Rails Playground e vou tentar migrar meus sites neste fim de semana.

EDIT: blog já movido. Fora um pequeno problema com o fcgi (aqui eles usam mod_fcgid) está tudo rodando beleza!

Um dos maiores motivos para resistência à mudança dos nossos sistemas na empresa, de PHP para Ruby on Rails, sempre foi o deploy. Convenhamos, colocar um sistema Rails em produção não é a coisa mais fácil do mundo. FastCGI, Mongrel, Mongrel Cluster, Apache…

Agora a coisa parece mudar de figura e ficar tão fácil como o mod_php. Foi lançado hoje o Phusion Passenger (ou mod_rails), um módulo do Apache que torna o deploy tão simples como copiar os arquivos pro servidor e configurar o caminho no Apache.

Acredito que a partir de agora a adesão ao Rails (principalmente por parte das empresas de hosting) será ainda maior…