I decided to migrate my wife’s website (for those who don’t know, my wife is the very famous brazilian singer Daniella Alcarpe, known also as @cantora).

The website is quite simple and easy to develop. Actually, there is no rocket science at all in everything I did. But I had a lot of fun and I learn a lot of things. This post cannot be used as a complete migration plan for those who want to migrate from Rails to Play, but it will give you an idea of the work you will have. Basically, you will have to re-write everything from scratch… or almost this…

First steps

The first thing I did was to visit the Play 2.0 website and follow the First Application Tutorial. I did both the Scala and the Java Tutorial. The tutorial is very easy to follow. It is well written, no big deal. One important thing to say is that I already studied Scala for six month last year, in my PhD class, so I was confortable with Scala. For those who never saw Scala, I suggest to read the book Programming in Scala 2nd Edition. I decided than to create the @cantora’s website in Scala, because it is a language that I love. It is very fun to write code in Scala!

I also decided to open the source of the @cantora’s website, so people can follow my steps (and maybe help to improve the site, or use it for other artists website).

I created a play project using the command

$ play new cantora

Then, I started to migrate the file app/views/layouts/application.html.erb in the old Rails application to the app/views/main.scala.html in the newly created Play 2.0 one.

The website has a dynamic title, which is set up using content_for block.

Rails code:

[html]<title><%= t(“site.title”) %> – <%= yield(:title) %></title>[/html]

Scala Code:

[html]<title>@Messages(“site.title”) – @title</title>[/html]

Note that the title is now a variable that I will pass to the layout, so my main.scala.html first line is:

[scala]@(title: String)(content: Html)[/scala]

I also had to change every t(“key”) for @Messages(“key”). Off course I used a regular expression replace to do it in all files.

Stylesheets and Javascripts, which usually are a one line of code in Rails required a more “hardcoded” solution in Scala.

Rails code:

[ruby]<%= javascript_include_tag :all, :cache => true %> <%= stylesheet_link_tag :all, :cache => true %>[/ruby]

Scala code:

[html]
<link rel=”stylesheet” media=”screen” href=”@routes.Assets.at(“stylesheets/grid.css”)”>
<link rel=”stylesheet” media=”screen” href=”@routes.Assets.at(“stylesheets/style.css”)”>
<link rel=”stylesheet” media=”screen” href=”@routes.Assets.at(“stylesheets/galleriffic.css”)”>
<script src=”@routes.Assets.at(“javascripts/applicaton.js”)” type=”text/javascript”></script>
<script src=”@routes.Assets.at(“javascripts/jquery-galletiffic.js”)” type=”text/javascript”></script>
<script src=”@routes.Assets.at(“javascripts/jquery.js”)” type=”text/javascript”></script>
<script src=”@routes.Assets.at(“javascripts/jquery.youtubeplaylist.js”)” type=”text/javascript”></script>
[/html]

Then I link in the main menu I had to replace for the Play 2.0 routes system:

Rails Code

[html]<li class=”menu”><%= link_to “#{t(‘site.singer’)}”, {:controller => “cantora”} %></li>[/html]

Scala Code

[html]<li class=”menu”><a href=”@routes.Application.cantora”>@Messages(“site.singer”)</a></li>[/html]

For this work, I had to add every route in the Play routes file. Different from Rails, that assumes your route based on controller and method name, you have to explicitly set the routes for every controller method. Actually I think this is not so bad. And if you want, you can easily create this “convention over configuration” scheme in Scala. So I added to the routes file:

GET     /cantora                           controllers.Application.cantora
GET     /musicas                           controllers.Application.music
GET     /agenda                           controllers.Application.shows
GET     /novidades                           controllers.Application.news

...

I have created every method in the default Application Controller:
[scala]
def cantora = Action { implicit request =>; Ok(views.html.cantora()) }
def music = Action { implicit request =>; Ok(views.html.music()) }
def shows = Action { implicit request => Ok(views.html.shows()) }
def news = Action { implicit request => Ok(views.html.news()) }
[/scala]

And also a view file for every action I had. Then, app/views/[controller_name]/index.erb.html became app/views/[method_name].scala.html

Most of my controllers had just one default index action. Those who had more than the default index method, I choosed another action name for it and used the same pattern.

Calling web services from a Play 2.0 application

The @cantora’s website looks very simple, but there are some very interesting integrations in the back-end of it, which turns it into a very interesting website for the artist:

1. All videos in the videos session are automatically imported from the artist channel
2. All photos in the photos session are automatically imported from the photos posted in the Facebook Artist Fan Page
3. The tweets in the social page are imported from the artist timeline
4. Shows are an embedded Google Agenda
5. News are from the artist Fan Page timeline
6. Every time someone register for music download, this record goes automatically to the artist email marketing database (integrated with Mailee API)

Off course I needed to maintain all this features in the Play 2.0 version. The features 4 and 5 are trivial, since no back-end code is necessary, all code is HTML and javascript, the same in both Rails and Play version of the website

But for features 1, 2, 3 and 6, I had to re-write the code, which is pretty simple, except for the Mailee API integration, which gave me some extra effort.

For the videos (1)

Rails Controller Code:

[ruby]
require 'restclient'

class VideosController < ApplicationController
  caches_action :index

  def index
    uri = "http://gdata.youtube.com/feeds/api/users/daniellaalcarpe/uploads"
    video_feed = RestClient.get(uri)
    @videos = Hash.from_xml(video_feed)['feed']['entry']
  end
end
[/ruby]

Scala Controller Code:

[scala]
def videos = Cached("videos", 18000) {
    Action { implicit request =>
      Async {
        val uri = "http://gdata.youtube.com/feeds/api/users/daniellaalcarpe/uploads"
        WS.url(uri).get().map { response =>
          Ok(views.html.videos(response.xml \ "entry"))
        }
      }
    }
  }
[/scala]

And the views are also a little bit different:

Rails View Code:

[html]
  <% @videos.each do |video| %>
    <li>
       <a href="<%= video['group']['player']['url'] %>">
           <%= video['title'] %>
       </a>
    </li>
  <% end %>
[/html]

[html]
@videos.map { video => 
  <li>
    <a href="@{ ((video \\ "group") \\ "player")(0).attribute("url")}">
       @{(video \ "title")(0).text}
    </a>
  </li>
}
[/html]

[ruby]require 'restclient'
class FotosController < ApplicationController
  caches_action :index, :expires_in => 1.day

  def index
    @albuns_photos = {}
    @albuns = []
    albuns = JSON.parse(RestClient.get("https://graph.facebook.com/daniella.alcarpe/albums"))["data"]
    albuns.each do |album|
      if (album['description'] == "*")
        photos = JSON.parse(RestClient.get("https://graph.facebook.com/#{album['id']}/photos"))["data"]
        albuns_photos = photos.map {|p| p["images"][3]["source"]}
        album['photos'] = albuns_photos
        @albuns << album
      end
    end
  end
end
[/ruby]

  [scala]def photos = Cached("photos", 18000) {
    Action { implicit request =>
      Async {
        WS.url("https://graph.facebook.com/daniella.alcarpe/albums").get().map { response =>
          val albuns = (response.json \ "data").
            as[List[JsObject]].filter(album =>
              (album \ "description").toString.equals("\"*\""))

          val photos = albuns.map { album =>
            WS.url("https://graph.facebook.com/" + (album \ "id").toString.replace("\"", "") + "/photos").get().map { response2 =>
              (response2.json \ "data").as[List[JsObject]].map { photo =>
                ((photo \ "images")(3) \ "source").toString.replace("\"", "")
              }
            }
          }

          Ok(views.html.photos(photos))
        }
      }
    }
  }[/scala]

Mesão de trabalho

Recebemos a visita do nosso CEO. Ele veio junto com um programador do time que não pôde participar do retiro por causa de compromissos pessoais. Esse programador era um especialista em churrasco, pois nasceu no sul do Brasil e morou muitos anos “no meio do mato”. Logo que chegou, ele se prontificou a tomar conta do nosso almoço. Foi até a cidade, no mercado central, e explicou pro açougueiro a maneira certa de cortar a carne Depois voltou para a casa e comandou a churrasqueira, enquanto o resto do pessoal trabalhava.

Pouco antes da hora do almoço, fomos na sauna úmida, que desta vez estava perfeita. Intercalamos minutos de sauna com mergulhos de choque térmico na piscina. Foi realmente muito relaxante. Depois comemos e voltamos para o mesão de trabalho no andar de cima da casa.

Há algumas semanas estávamos com a nossa suite de testes de aceitação quebrada. Esse é um problema clássico! Todo projeto de software pelo qual eu passei enfrentou em algum momento problemas com os testes de aceitação (usando Selenium por exemplo). O que acabávamos fazendo era sempre rodar os testes de aceitação manualmente todas as vezes que fazíamos deploy. Caso algum teste quebrasse, arrumávamos os dados “na mão” e rodávamos o teste de novo até passar. Muito ruim.

Brinde

Nesse último dia de retiro, um dos nossos programadores aceitou o desafio de arrumar os testes e deixa-los mais estáveis (não depender tanto do banco de dados e outros recursos que possuem estado). Finalmente nossos testes voltaram a passar!

Além de arrumar os testes, foram feitos 14 commits de código e um deploy de código novo em produção nesse dia. Não foram mudanças muito grandes: algumas correções de pequenos bugs, melhorias nos logs, algumas mudanças na nossa API interna.

No final do dia, fizemos um brinde para comemorar a nossa estadia na casa. Depois do brinde, algumas partidas insanas de Open Arena. Dessa vez, todo mundo entrou na batalhas. Era tiro para tudo que era lado e eu, pra variar, só perdia.

Pontos positivos do dia:

• Visita do nosso CEO
• Teste de aceitação voltaram a passar
• Fizemos um novo deploy
• Churrasco feito por um profissional do ramo
• Sauna úmida funcionou e estava absolutamente incrível
• Batalha final no Open Arena com o time completo foi demais

Pontos negativos do dia:

• Eu só perdi no Open Arena. Descobri que fiquei muito velho para jogar essas coisas…
• Foi o último dia – o retiro estava acabando

Considerações finais sobre o retiro

Foram 4 dias de muita emoção! Com certeza a experiência foi marcante para todos, inclusive para mim. Fiquei muito emocionado em concretizar esse sonho. Aprendi muito com cada momento. Foi muito bom conviver com o time todo durante vários dias. Pude observar e conhecer melhor cada pessoa. Fiquei muito feliz com o resultado, com a sensação de dever cumprido.

Obviamente também tivemos problemas. O maior deles foi no segundo dia, quando bug bizarro entrou em produção e tivemos dificuldade de alinhar a comunicação com o escritório em São Paulo. Essa situação foi desgastante. Aprendemos muito e tentamos identificar pontos para melhorar da próxima vez (sempre dá pra melhorar!).

Ao longo dos 4 dias que estivemos no retiro, foram:

Comidas Antes

Comidas Depois

• 73 commits
• 5 deploys
• 6 novas funcionalidades (histórias) implementadas e colocas em produção
• 3 carrinhos de supermercado cheios de comida devorados (compare as fotos da comida antes e depois…)
• Vários mergulhos e piscina
• Alguns minutos de sauna
• Algumas horas jogando Open Arena
• Algumas horas tocando e cantando mais de 50 músicas diferentes

Próximos passos

Ainda tenho algumas tarefas para realizar pós evento. Quero tentar extrair o máximo dessa experiência. Farei uma reunião de retrospectiva com o time, onde conversaremos sobre como foi a semana. Vamos levantar o que aconteceu de bom e de ruim e como podemos melhorar numa próxima oportunidade.

Também estou elaborando um questionário que será preenchido por todos que participaram. A ideia e coletar algumas informações sobre a experiência individual de cada um e também alguns dados quantitativos. Pretendo também escrever um artigo sobre o retiro, explorando um pouco mais algumas questões. A ideia é tentar responder perguntas como:

• O time foi mais produtivo nesse ambiente?
• As pessoas ficaram mais felizes?
• As pessoas foram mais criativas?
• Qual foi o impacto dessa experiência para o negócio?
• Qual o impacto na vida dos profissionais?

Talvez, no futuro, vamos repetir o retiro com o time, ou talvez com outros times da empresa. Considero bastante importante que as pessoas que ficaram em São Paulo possam passar pela mesma dinâmica, a fim de entender o processo, sentindo na pele o que é passar essa semana num ambiente diferente do tradicional. Também acho relevante fazer a experiência com um time só de mulheres. Acredito que os resultados podem ser bastante diferentes, quando comparamos grupos só de homens com grupos só de mulheres.

Outra possibilidade é fazer um retiro com um foco um pouco mais claro. Dessa vez, não tínhamos um projeto específico para desenvolver. Estávamos simplesmente realizando as tarefas e histórias do dia-a-dia de um sprint normal. Talvez, se tivéssemos um objetivo claro para a semana, um projeto com começo, meio e fim, talvez fosse bem instigante e divertido para as pessoas encararem o desafio de terminar a semana com o projeto entregue.

Enfim, ideias não faltam. Espero que esse relato sirva de inspiração para outros times de desenvolvedores fazerem seus próprios retiros e dividirem suas experiências e aprendizado.

Também gostaria de ler comentários: por favor, dê sugestões! Critique. Exponha suas ideias. O que achou do relato? O que poderíamos melhorar? Já fez algo parecido?

Até mais!

Elo7 Tech Team

Standup Meeting

O sol estava brilhando e bateu forte na nossa janela. Como o pessoal tinha ido dormir um pouco mais tarde, também acabamos acordando um pouco mais tarde. Como de costume, fizemos nosso standup meeting as 11h. A moça que contratamos para limpar a casa e cozinhar não veio nesse dia. Acabamos tendo que dar um jeito com as tarefas da casa.

Durante quase o dia todo, uma das duplas ficou investigando o bug do dia anterior, tentando reproduzir o comportamento em ambiente de teste. Não conseguiram evoluir muito, o que nos deixou bastante frustrados.

Eu fiquei trabalhando com um outro desenvolvedor numa mudança importante e grande que tínhamos que fazer no site, que envolvia a arquitetura e o design das páginas. Passamos praticamente o dia todo em cima do código, testando a nova arquitetura, fazendo um protótipo. Não conseguimos terminar todos os testes, mas evoluímos bastante.

Programando da beira da piscina

Na hora do almoço, fomos para a piscina e churrasqueira. O sol estava bombando. Aproveitei para fazer uns exercícios do Kung Fu. Quase todos também foram na sauna (só funcionou a seca). Um outro pessoal aproveitou a piscina para nadar. Também levamos os computadores e ficamos trabalhando da beira da água. Um momento mágico!

Os que ficaram responsáveis pela churrasqueira salgaram a carne demais, não acenderam o fogo direito. Além de tudo, a picanha tava dura igual uma pedra! Também colocamos umas batatas, cebolas e alho embrulhados no alumínio, mas não fizeram muito sucesso. No fim, a única coisa que se salvou do churrasco foi a berinjela. Acabamos com o arroz, feijão e salada do dia anterior e esse foi nosso almoço.

De noite, um de nós lembrou que o dia era de lua cheia e propôs uma meditação em grupo. Dizem que nesse dia, a energia da lua faz com que a meditação seja mais poderosa. Alguns gostaram da ideia e fizeram essa meditação que durou cerca de uma hora.

Enquanto isso, do que sobrou da carne dura do almoço, um pessoal tentou moer no liquidificador e fazer uns croquetes. Disseram que o gosto até que estava bom, mas continuava dura. A solução foi fritar uns hambúrgueres e comer lanche. Fizemos um vídeo da movimentação da cozinha de noite.

Meu quarto - espaço privado

Depois da janta, continuei trabalhando na história de arquitetura e fomos até meia noite nela. Nesse dia eu tive um insight muito interessante. Depois da piscina, resolvi dar uma passada no meu quarto para trocar de roupa. Quando eu estava sozinho no quarto, senti uma paz e um alívio muito grande de estar lá sozinho. Percebi a importância que era ter um espaço privado na casa. Notei que a distribuição de cômodos do lugar ajudava muito. Havia na casa uma parte de convívio compartilhada, mas também uma boa área íntima, permitindo que as pessoas se retirarem quando achassem conveniente.

Lembrei de ter lido algo a respeito de espaços público/privados no livro Peopleware, do Tom De Marco. Ele cita alguns padrões de arquitetura catalogados pelo Christopher Alexander. Tom De Marco enfatiza a importância de se ter num ambiente de trabalho, num escritório, espaços públicos e individuais harmoniosamente distribuídos e equilibrados. Pouca gente sabe, mas os padrões do Alexander influenciaram toda indústria de software: padrões de projeto (os famosos Design Patterns), Domain Driven Design, o livro de  Refatorações, Métodos ágeis são alguns dos muitos exemplos de conceitos da área de software que surgiram na comunidade de software que estuda padrões.

Pontos Positivos do Dia:

• A piscina estava muito boa
• Sol durante quase todo o dia
• Meditação da Lua cheia
• Stop Motion na cozinha na hora da preparação do jantar
  
• Consegui trabalhar e avançar a arquitetura de uma história importante junto com outro desenvolvedor

Pontos Negativos do Dia:

• As duas saunas não funcionam juntas
• A carne do churrasco foi um fiasco
• Uma dupla perdeu quase o dia todo investigando o bug do dia anterior e não encontraram a causa do bug

Trabalhando Juntos

Acordamos lá pelas 8 e meia, 9 horas. Também teve gente que acordou mais cedo para fazer um cooper. Como de costume, fizemos nosso Standup Meeting as 11h da manhã. Recebemos a visita do nosso diretor de produtos. Ele veio de São Paulo para cá, passar o dia com a gente. Foi muito importante sua vinda, pois pudemos conversar em mais detalhes sobre algumas histórias que estávamos implementando.

Contratamos uma moça para cozinhar e fazer a limpeza da casa nesse dia. Foi muito bom, pois não tivemos que nos preocupar com o almoço. Ela preparou um belo arroz feijão com frango grelhado e outras opções para os vegetarianos.

Time reunido

O dia foi um pouco difícil, pois fizemos um deploy que causou alguns bugs esquisitos. Eu e mais outro desenvolvedor ficamos praticamente o dia todo tentando entender o bug. Descobrimos a história que causou o problema, mas olhando o código não conseguimos entender por que o comportamento estranho em produção (todos os testes em ambiente de desenvolvimento e integração estavam perfeitos). Desconfiamos que seria algum problema de concorrência e decidimos tentar simular o bug em nosso ambiente de testes.

Mais tarde, fizemos um novo deploy com todas as funcionalidades novas, exceto a que estava dando problemas. Para isso, usamos o rebase interativo do git (git rebase -i). Funciona perfeito! Muito fácil tirar uma história da árvore de commits. Ao todo, foram 22 commits de código feitos desde a semana passada que entraram em produção.

Programming

No fim da tarde demos uma refrescada na cabeça com um mergulho na piscina. O tempo não estava muito quente, então não deu para ficar muito dentro daquela água gelada, mas foi bem gostoso o momento aquático para relaxar a tensão.

De noite, uma parte das pessoas continuou trabalhando, enquanto alguns outros foram jogar Open Arena. Eu fui para a cozinha fazer uma pasta. Foram três pacotes de Barilla e 4 kilos de tomate para alimentar o povo!

Skype com São Paulo

Depois do jantar, alguns continuaram nos seus computadores trabalhando até quase meia noite. Aproveitamos o sorvete de pistache que estava dando sopa no freezer.

Enquanto isso, fizemos um som com o violão que eu tinha levado. Rolou de tudo, desde Paulinho da Viola, Roupa Nova, passando por U2, Bon Jovi até Britney Spears. O pessoal se empolgou mesmo com a cantoria. Não paramos de dar risada.
Aproveitamos para fazer uma chamada por skype com um dos nossos devs que tinha ficado em São Paulo.

Fomos  dormir esgotados, ainda pensando no bug e nos problemas que ele causou para nossos clientes. Teríamos um dia seguinte desafiador pela frente…

Trabalhando tomando sorvete

Pontos Positivos do dia:

• Cantoria de noite
• Mergulho na piscina
• Visita do diretor de produtos (nosso PO)
• Almoço feito pela Suelma
• Pasta ao pomodoro e a bolognesa
• Open Arena
• Sol no final da tarde

Pontos Negativos do dia:

• BUG bizarro em produção
• Chuva na maior parte do dia
• Sauna a vapor não estava funcionando

Pela manhã, parte do grupo ficou na casa e eu fui com mais outros dois devs fazer as compras da casa para a semana. Achei que seria rápido, mas no fim demoramos quase três horas nessa tarefa, que foi bem divertida, apesar de cansativa.

Compramos de tudo: comidas, bebidas, material de limpeza, itens para churrasco, etc. Eu já tinha preparado a lista de supermercado antes, o que facilitou muito. Mesmo assim, lembramos de muitas coisas que não estavam na lista enquanto fazíamos as compras.

Voltamos para a casa por volta do meio-dia e o resto do pessoal já estava acomodado na mesa da sala programando. A mesa era bastante grande e cabiam todos os nove membros do time.

O primeiro problema que tivemos foi conseguir fazer a programação em pares da mesma forma que fazemos no escritório. Lá nós temos um computador com dois monitores, dois teclados e dois mouses. Seria inviável levarmos para a casa de campo todos os computadores do escritório e todos os monitores. A solução que encontramos foi cada desenvolvedor levar seu notebook pessoal (por sorte, todos tinham um!) – eram 7 MacBooks e 2 notes rodando Ubuntu Linux. Para fazer o pair programming, usamos o esquema de compartilhamento de tela do Mac OS X, que funciona muitíssimo bem. Assim, quando fazíamos os pares, uma das pessoas acessava a máquina da outra, visualizando sua tela e com a possibilidade de interagir (teclar e controlar o mouse).

O delay é praticamente zero, então dava para trabalhar junto usando esse esquema sem problema. Existem outras formas de fazer isso, usando o Screen e o Vim, porém, como parte do nosso ambiente é Java e temos uma grande dependência do Eclipse, preferimos o compartilhamento da tela.
Depois de comer, voltamos para a mesa e continuamos trabalhando até quase 22h.Por volta das 16h fizemos uma pausa para comer. Descemos para a área da churrasqueira. Alguns não comiam carne, então também fizemos opções vegetarianas (abobrinha, cebola, queijo coalho, saladas, etc). Todo mundo comeu bem e pôde descansar um pouco da viagem. Um dos programadores resolveu fazer uma sauna seca (que havia na casa também) e fizemos nossas tradicionais “flexões de braço antes do almoço”, para manter o time forte.

O segundo problema que tivemos durante o dia foi a lentidão da Internet. Em alguns momentos do dia, a rede baleiava. Pedimos para todos desligarem serviços em seus notes que eventualmente pudessem estar consumindo banda. Uma solução legal que fizemos foi na hora de rodar os testes de aceitação em ambiente de staging (integração). Em geral, esses testes rodavam usando Selenium e Firefox na máquina do desenvolvedor, acessando o site em nosso servidor de staging. Como a rede estava muito lenta, cada página demorava muito para carregar e os testes demoravam muito.

Tivemos a ideia de criar uma máquina no EC2 com Ubuntu e VNC. Assim, poderíamos rodar os testes de aceitação direto dessa máquina que, estando dentro da rede do EC2, rodariam bem mais rápido e não consumiriam nossa banda para rodar (apenas a banda do VNC, que poderíamos deixar a janela oculta. Para configurar essa máquina, usamos as instruções desse site.

A ideia não é nova, embora eu tenha visto poucas organizações, empresas ou pessoas executando ela de fato. Tudo surgiu de uma conversa com meu grande amigo Alexandre Freire, que já tinha vivido a experiência de levar programadores para a sua casa no bonete na Ilhabela em São Paulo. A aventura dele está documentada no blog do estúdio livre.

Reuni os nove desenvolvedores do Elo7 e propus de passarmos uma semana trabalhando em uma casa no campo, ao invés do tradicional escritório na Vila Olímpia. A casa que encontrei era ideal, tanto em termos de conforto quanto em opções de descontração:

• Sete suítes com camas individuais
• Piscina
• Churrasqueira e forno de pizza
• Sauna úmida e seca
• Sala de jantar com lareira
• Cozinha equipada

Além disso, a casa ficava num condomínio fechado, com opções esportivas como: quadra de tênis, campo de futebol, piscina olímpica, academia, etc. Tudo isso num lugar cheio de verde. Parecia o cenário perfeito para favorecer o florescimento de toda a criatividade dos engenheiros da empresa.

Durante a semana anterior a viagem, conversei individualmente com cada pessoa. Expliquei como seria a experiência e pedi sugestões de como fazer com que os dias na casa fossem o mais agradáveis e produtivos possível. Perguntei sobre preferências alimentares e necessidades individuais de cada um. Também tentei saber qual seria a melhor distribuição das pessoas entre os quartos, mas todos se mostraram bem abertos a qualquer configuração.

Tive que tomar algumas providências logísticas para viabilizar o evento:

• Contratar um link de Internet para a casa (essa parte foi bem difícil, pois na cidade não havia muitas opções de banda larga, mas no fim deu tudo certo);
• Encontrar uma faxineira para ajudar na limpeza ao longo da semana;
• Todos ficaram responsáveis por configurar seus computadores pessoais com o ambiente de desenvolvimento da empresa e leva-los para a casa;
• Trazer outros equipamentos: dois roteadores WI-FI, cabos de rede, cabos HDMI e VGA para eventualmente ligar os computadores;
• Alguns itens de primeiros socorros, termômetro, anti-séptico, etc.
• Outros brinquedinhos: Bucky Balls, baralho, instrumentos musicais (violão, pandeiro, tamborim, etc), iPods, caixinhas de som, almofadas de meditação

Algumas características do grupo facilitaram muito a organização da experiência. A maioria das pessoas não era casada e nenhum deles tinha filhos. Também não havia nenhuma mulher no grupo, o que evitou possíveis constrangimentos com namoradas.

Ao longo da semana vamos trabalhar intensamente nos desafios técnicos da empresa, implementar novas funcionalidades, definir arquiteturas, enfim, programar muito. Vamos também estudar, conversar bastante, compartilhar conhecimento e, acima de tudo, nos divertir muito, fazendo o que gostamos de fazer: escrever software!

Acompanhe aqui no blog um diário de bordo dessa experiência.

Sometimes your website is full of useful content, but they are not well organized, or the HTML behind it is malformed, so search engine robots can’t grab the right data from it. If you have good content, by following these tips you will boost your performance. There is no miracle in the SEO race. You need to join good content with the right tagging techniques, and you will certainly be in a good position. Don’t try to be smarter than the search engines. You won’t!

Tip 1 – Good treatment to your Meta Tags

There are a lot of information you must put into the <header> of you HTML. Here is an example for information about a product:

<meta property="og:type" content="article" />
<meta property="og:title" content="Lágrimas de Alegria | Estúdio 100 | 1A75C3" />
<meta property="og:image" content="http://www.elo7.com.br/pp/lagrimas-de-alegria.jpg" />
<meta property="og:url" content="http://www.elo7.com.br/lagrimas-de-alegria/1A75C3" />
<meta property="og:site_name" content="Elo7" />
<meta name="title" content="Lágrimas de Alegria Pocket Lenço FTC4 | Estúdio 100 | 1A75C3" />
<meta name="description" content="Pocket Lenço ORIGINAL Lencinhos para convidados. Envelope em papel branco textura floral + passaro Incluso 2 lencinhos de papel de bolso embalados em papel vegetal." />
<meta name="keywords" content="Lágrimas de Alegria Pocket Lenço FTC4,lagrimas de alegria,lencinho para casamento" />
<meta name="GOOGLEBOT" content="NOARCHIVE" />
<meta name="robots" content="index, follow, noarchive" />
<title>Lágrimas de Alegria Pocket Lenço FTC4 | Estúdio 100 | 1A75C3</title>

• Use all these tags (title, description, keywords, og:*)
• If your page content changes a lot, use noarchive tag
• Pay attention to title and description size. Title is smaller and description must not be too big.

Tip 2 – Nice and intuitive URLs help a lot

If you can use intuitive and nice URLs, it will count a lot in your SEO ranking. Try to be organized. For example: if you have products in stores, try to use something like:

• /products/my-beautiful-product – for the product URL
• /categories/nice-category or /nice-category – list all products in a category
• /stores/incredible-store – all products from a store
• /stores/incredible-store/awesome-department – list all products for a specific department in a store

Avoid URLs like /userProfile.do?command=showUserProfile&webCode=1CC1A. They mean nothing to the search engine bots. remember also that everything that goes after the query string (the question mark (?) in the URL) is usually weaker than what comes before the question mark.

Tip 3 – Name your images properly

If you are writing about lasagna in your page content, don’t the lasagna image IMG0345.jpg in the HTML! Name it lasagna.jpg! If you have 3 lasagnas photos, name them lasagna, lasagna-sugo.jpg, lasagna-bolognesa.jpg and so on. Put meaning in you page. And don’t forget the ALT and the TITLE properties in the IMG tag. They are indispensable!

Tip 4 – The use of canonical

If you have more than one URL pointing to the same page content, use a canonical link meta tag. Search engine robots are smart, so if you have two identical pages with two different address, their relevance will go down! Use this tag and put it in your HTML HEAD:

<link rel="canonical" href="http://www.elo7.com.br/lagrimas-de-alegria-pocket-lenco-ftc4/dp/1A75C3" />

Tip 5 – Semantic content

HTML is a good designed language for text content. It is not good for styles (colors, font, formats, etc). For styles you use CSS and for content you use HTML. Follow HTML conventions as much as possible:

• Put the main subject (the title) of your page in a H1 TAG.
• In H2 tags, put subsections.
• If you have a listings, use UL and LI.
• Use tables just when you are really presenting a table.
• If you want to emphasize something, use EM or STRONG tags.

If you know HTML5, which has new and very expressive TAGs for multimedia content (and other), use it!

Tip 6 – Use of schema information – semantic to the extremes

A recently launched website for the semantic web is schema.org. The purpose is to put some tags in your HTML to help robots to identify the kind of content you are serving. Differently from META tags that go in the top of your HTML HEAD, schema information go within the HTML code. Here are some examples that we used in Elo7 for product listing, for price, product description, etc.

<html lang="pt-br" itemscope itemtype='http://schema.org/Product'>
<div itemscope itemtype="http://schema.org/Product">
  <span itemprop="name">Lágrimas de Alegria Pocket Lenço FTC4</span>
  <img itemprop="image" src="http://img.elo7.com.br/product/main/37C149/lagrimas-de-alegria-pocket-lenco-ftc4.jpg" alt="Lágrimas de Alegria Pocket Lenço FTC4" title="Lágrimas de Alegria Pocket Lenço FTC4">
<span itemprop="description">Pocket Lenço ORIGINAL<br>Lencinhos para convidados...</span>
  <div itemprop="offers" itemscope="" itemtype="http://schema.org/Offer">
     <span itemprop="price">R$ 1,90</span>
  </div>
  <div itemprop="availability" href="http://schema.org/PreOrder">Prazo para produção: 15 dias</div>
  <a itemprop="url" href="http://www.elo7.com.br/marcador-de-pagina/dp/202850" />
</div>

The schema.org is still growing, but google is already considering schema information in its search engines. The complete schema taggin information can be found in schema.org website

Tip 7 – Be fast for robots

The faster your page loads, the better you will be ranked in search engine queries. Do as much page optimizations as possible in your website. For these optimizations, I recommend reading the Steve Sourders Books – High Performance Web Sites and Even Faster Web Sites. Believe it or not, if your website loads 20% faster, you can get 20% more traffic from search engines.

Tip 8 – Monitor and graph whatever you can

Everything you change in your website must be monitored, so you can make sure you are making changes in the right direction. I recommend 3 tools for it:

• Google Analytics – watch you traffic increasing after some days of your changes. Mark in analytics the days you pushed SEO modifications into production
• Google webmaster tools – metrics specifics for SEO. You can know how bots are crawling your site and if these bots are having problems with your code.
• New Relic – a very powerful monitoring tool. It monitors your web server and your application, and points you hotspots of possible optimizations. Wonderful but expensive tool

Tip 9 – Backlinking

This is a very powerful but also difficult task: have as many websites as possible linking to your content. But it is possible to do. Make partnerships with bloggers, big portals, and also your users (create link banners and give it to them to put in their websites). The more links you have pointing to your website, the more relevant it will be to search engines.

Tip 10 – Be careful with javascript and flash content

Robots do not execute javascripts nor have flash player! So, if your content is dynamically loaded using javascripts, you will need to change it, or have an alternative version of it in pure HTML.

An example of something that happen with us in Elo7: our products pages has 5 pictures for each product. The first main was a IMG tag, but the others were loaded using a javascript, just when the user clicked in the small thumbs of these images. For performance reasons, this is an intelligent strategy, because the browser does not need to load all images when the user goes to the page. The result was that just 1/5 of our website image where indexed in search engines. The solution was to put the other images in link <A HREF> tags. With this approach, the images are not loaded until the user clicks it, leaving the page fast; and the robots follow the link, so these images are indexed. Take a look of what happen to our SEO ranking when we did this small change in our HTML. The graph bellow (from Google Webmaster tools) shows that the quantity of listed itens more that double after the images started to appear to the robot: