Para a minha solução usei apenas os seguintes métodos:

#Retorna um array de strings com todos os arquivos do diretório.
Dir.entries("dir")

#Retorna se o arquivo é um diretório ou não.
File.directory?("arquivo")

#Renomeia o arquivo.
File.rename("nome_antigo", "nome_novo")

Minha solução final ficou assim:

def rename_in_dir(dir)
  files = Dir.entries(dir)
  files.each do |f|
    # Usei esse if para ignorar os arquivos que já tinham
    # extensão e as referências '.' e '..'
    next if f == "." or f == ".." or f =~ /.*\..{2,4}$/
    # é importante sempre usar o diretório junto, se não ele vai
    # procurar sempre no diretório onde o script está sendo executado
    if File.directory?("#{dir}/#{f}")
      # Se for um diretório faz a chamada recursiva
      puts "DIR: #{dir}/#{f}"
      rename_in_dir("#{dir}/#{f}")
    else
      puts "renaming: #{dir}/#{f}"
      # Adiciona a extensão .mp3 no arquivo
      File.rename("#{dir}/#{f}", "#{dir}/#{f}.mp3")
    end
  end
end
# Começa a partir do diretório onde o arquivo está
rename_in_dir(".")

Eu adorava o ambiente que tinha na DClick e na Caelum e também estou gostando muito das coisas aqui na Locaweb, com regras apenas de bom senso: vista o que quiser, chegue na hora que quiser, apenas faça suas horas semanais e cumpra seus deveres não importa como. Na minha opinião isso deveria ser regra para área de desenvolvimento, mas na hora de comprar os móveis é que as dúvidas começam, então vou listar alguns itens que considero importantes e comentar sobre os prós e contras que vivi nesses últimos anos.

Mesas

Sempre fui defensor dos mesões. Sempre achei que o ganho em comunicação vale mais do que as eventuais distrações que podem gerar, porém tanto a DClick quanto a Caelum são empresas relativamente pequenas, em ambas a nossa “salona” tinha no máximo 20 devs. A experiência das mesonas aqui na Locaweb está sendo bem menos produtiva pra mim. Na minha primeira semana aqui tive dias de produtividade MUITO baixas que atribuí ao barulho na sala. Não sei qual seria o número máximo de pessoas, ou se o problema não é quantidade e sim o bom senso, mas a questão é que hoje preciso me controlar bem mais para render o que gostaria num dia de trabalho. Aqui, além das mesonas existe outro fator que talvez seja o real “vilão”, que são as brincadeiras. Na Caelum era comum ver uma pessoa ou outra brincando com os dardos ou fazendo malabares, mas aqui na Loca é comum ver pessoas fazendo “guerrinha” com suas NERFs. Embora seja óbvio que “guerrinha” seja uma distração muito grande, nas outras empresas também tínhamos momentos de “distração coletiva” ou simplesmente barulho intenso, por isso não tiro a “culpa” dos mesões para esse tipo de bagunça.
Veredito: Use com bom senso. Claro que é mais fácil “controlar” 20 do que 500, mas mesmo para times grandes acho que vale a pena a utilização dos mesões, mas é necessário um pouco mais de responsabilidade dos funcionários.

Lugares fixos

Uma das coisas que mais senti falta quando fui para a Caelum era de ter o MEU lugar. Sempre gostei de ter a minha bagunça, fotos, planta (na DClick eu tínha um cactus na mesa, aqui na Loca ainda não), enfim, personalizar o lugar como você preferir. Tanto na DClick quanto aqui na Loca tenho essa possibilidade, mas na época de Caelum não tínhamos, e embora sentisse falta disso, lá faz muito sentido ser da maneira que é. Mais importante do que trazer a foto da familia é sentar próximo do seu time de trabalho. Aqui na Loca os time são bem definidos e pelo o que entendi, existe uma baixa rotatividade de pessoas entre times, na Caelum é exatamente o oposto. Lá não existe uma separação muito clara entre os times e a rotatividade é MUITO grande. Não faz o menor sentido você customizar seu lugar se vai trocar de lugar toda semana. Um ponto curioso sobre o assunto é que na DClick era mais ou menos o meio do caminho. Existem (pelo menos existiam) times bem definidos por projeto, mas a rotatividade era média e fazer a mudança eventualmente valia a pena. Durante o ano que trabalhei lá me lembro de ter remanejado minhas coisas pelo menos umas 3 ou 4 vezes.
Veredito: Dê preferência por manter os times juntos e, se as mudanças não forem frequentes, vale a pena deixá-los fixos.

Cadeiras

Compre cadeiras boas para seus funcionários! Eu sei que não é barato, mas além de lei, faz toda a diferença chegar em casa após um dia de trabalho numa cadeirinha vagabunda ou numa cadeira que você pode configurar altura, encosto e etc.
Veredito: Não precisa ser cadeira de presidente, mas compre pelo menos uma de rodinha com regulagem de altura, encosto e braços.

Monitores

Desde que usei dois monitores pela primera vez na DClick me apaixonei pela experiência. Poder ver o código e browser ao mesmo tempo ajuda MUITO no dia-a-dia. Se for optante pelos lugares fixos, compre 2 monitores pra todo mundo! (vai sair mais barato do que a cadeira), se não, deixe alguns espalhados pelas mesas para que as pessoas usem. Uma observação importante sobre essa opção é: quanto mais difícil for de usar, menos eles serão usados, então tente deixar tudo prontinho para apenas espetar o computador e sair usando.
Veredito: Eu me sinto bem mais produtivo usando outro monitor. Acredito que vale o investimento.

Copa/Cozinha/Banheiro

Essa parte é bem mais difícil de gerenciar pois na maior parte dos casos não temos como colocar um banheiro a mais onde queremos, mas é um fator que não deveria ser completamente ignorado. Na DClick a copa era pra um lado e o banheiro pra o outro, mas ambos bem próximos da maioria. Na pior da hipóteses ou você sentaria bem perto de um e um pouco longe do outro. Na Caelum, na última configuração de sala que tínhamos quando saí de lá, a “copa” estava integrada à nossa sala o que era ótimo. O único problema que tivemos com isso foi a facilidade que as pessoas tinham em comer nas mesonas e acabava sujando um espaço coletivo. Bastou uma conversa e tudo se resolveu. Quanto aos banheiros lá, usavamos os da área comum do prédio. Relativamente próximos com a desvantagem de ter que levar uma chave com você, além de ser só um por andar (relativamente comum tentar ir ao banheiro e estar ocupado). Aqui na Loca, tanto o banheiro quanto a copa ficam nos cantos do prédio e em apenas 2 cantos. Pra piorar, o banheiro masculino é de um lado e o feminino é do outro, ou seja, dependendo de onde você se sente pode ser uma longa jornada até você se aliviar ou conseguir o seu café. Porém, se sentar perto do banheiro vai acabar vendo um grande fluxo de pessoas por perto. Embora veja isso como um desperdício (pra que já leu um pouco sobre lean sabe do que estou falando) não vejo uma solução plausível para esse caso.
Veredito: Definitivamente comportar 500 pessoas é BEM mais difícil do que 20, mas tente se preocupar com esses detalhes na hora de escolher o prédio. Sem dúvidas seus funcionários precisão ir ao banheiro e quanto menos tempo eles demorarem, melhor pra todos! Prefira os ambientes com banheiros e copas (café) acessíveis e de preferência que sejam iguais para todos, independente de onde sentam.

Esses são os principais fatores físicos que acredito afetar a minha produtividade durante o dia-a-dia. Em nenhuma das 3 empresas que citei no post tive 100% dos itens que mais gosto e fui/sou muito feliz como funcionário de todas, então não se preocupe se não conseguir todos, mas tente fornecer o máximo desses itens para seus funcionários.
Lembre-se do princípio ágil:
“Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.”

Pra finalizar, fotos da minha mesa aqui na Locaweb:

Mais um evento organizado pela Caelum, obviamente com seus altos e baixos, mas muito mais altos do que baixos.

Questões como espaço, horário e lanches foram praticamente perfeitos e grandes apresentações como as do Jim Webber, Rebecca Parsons e o muito simpático Khawaja Shams com seus robôs dançantes e seu knob (botão) que cria máquinas na Amazon foram momentos de destaque do evento. Infelizmente alguns palestrantes acabaram decepcionando um pouco, mas este é o tipo de problema que não temos como prever e sempre vão acontecer em qualquer evento do mundo.

Outra grande vantagem desse tipo de evento é poder rever alguns amigos e ex-colegas de trabalho e matar a saudade do pessoal, além de conhecer novas pessoas e em alguns casos conhecer fisicamente algum grande amigo de internet (Acreditem, isso acontece! E muito!).

Gostaria de agradecer todos que participaram da organização do evento, os hosts das tracks e o Luiz Bassi da Caelum, que foram as principais pessoas por trás deste grande evento. Além disso um agradecimento especial para todos que apresentaram LT comigo:
Christian Reichel, que apresentou “Por um Java mais funcional”, onde mostrou exemplos de funções como map e reduce em java usando o Guava;

Diego Chohfi, que agora também faz parte do time da Caelum, mostrou um pouco do dinamismo não muito comentado do Objective-C;

E 3 grandes colaboradores do VRaptor falando sobre algumas funcionalidades extras do framework:

Washington Botelho que mostrou como implementar um controle de permissões baseado em perfis;

Rodolfo Liviero, autor do Vraptor-scaffold, mostrou como criar e “deployar” uma aplicação VRaptor no heroku em menos de 5 min usando seu projeto;

Guilherme Silveira que comentou sobre os vários plugins já criados para o VRaptor e ainda deu um “puxão de orelha” no pessoal presente para que extraiam plugins e colaborem com o projeto.

A minha apresentação foi mais abstrata e basicamente questionei sobre a integração de sistemas usando frameworks MVC em vários pontos diferentes sobe o título “MVC além do MVC”. Slides:

VRaptor Flex Plugin

Em ordem cronológica o primeiro “grande” feito ao Open Source neste ano foi ter criado, com a ajuda do Lucas Cavalcanti e do Erich Egert um plugin para o VRaptor que possibilita as chamadas remotas usando o protocolo AMF. Na verdade não fizemos todo o trabalho de (de)serialização, mas assim como o suporte para Spring, EJB, etc.  O que fizemos foi criar uma factory que você deve registrar no framework que realmente sabe fazer a serialização para AMF. Por enquanto estamos suportanto o BlazeDS e o GraniteDS.

Para saber um pouco mais sobre o plugin e como configurar e usar veja o página no próprio github para issues podem usar a mesma página de issues do VRaptor.

Stella 2.0

Alguns de vocês já deve ter ouvido falar no Stella. Um projeto com um monte de utilidades para desenvolvedores brasileiros, como validadores de CPF e CNPJ, gerador de boleto, conversor de números por extenso e um pouco mais. Embora muito útil, o projeto andava meio parado e recentemente eu, o Mario Amaral e o Paulo Silveira, além de outras contribuições da comunidade, atualizamos o projeto para suportar as “novas” especificações do JEE6 como o JSF2 e Bean Validation, além de muita refatoração e algumas melhorias na API.

Acabamos de liberar um release beta e em breve devemos ter uma versão 2.0 final disponível.

Static Server

O último projeto que trabalhei recentemente surgiu no momento de subir o site do Stella. Na Caelum estamos numa tendência de cada vez mais tirar a responsabilidade de infra das nossas mãos, então mesmo com um site estático a gente queria subir no Heroku ou Google App Engine. Pensamos em criar uma aplicação rails e deixar todos os arquivos no public, mas não fazia o menor sentido, então comecei a fazer usando apenas Rack, mas ficamos com o problema da home, aí comecei uma dsl pra configurar forward e redirect, fui refatorando até que surgiu o StaticServer que já está no rubygems como static_server.

Em breve vou colocar uma documentação melhor, mas por enquanto vocês podem ver os exemplos nos testes de integração.

Ajude você também

Esses e tantos outros projetos, brasileiros ou não, sempre precisam de ajuda, seja com código, documentação, exemplos e até mesmo encontrando e registrando bugs. Toda ajuda é bem vinda, sempre!

Em breve devo colocar mais exemplos e possivelmente escrever posts com mais detalhes da utilização de cada um deles.

describe Usuario do
  before :all do
    @obrigatorios = {nome: 'David Paniz', idade: 25}
  end
  it "deve ter Nome obrigatório" do
    u = Usuario.new(@obrigatorios.merge(nome: nil))
    u.should_not be_valid
    u.should have_at_least(1).error_on(:nome)
  end
  it "deve ter Idade obrigatório" do
    u = Usuario.new(@obrigatorios.merge(idade: nil))
    u.should_not be_valid
    u.should have_at_least(1).error_on(:idade)
  end
  it "Deve ser valido com todos os campos obrigatório" do
    u = Usuario.new(@obrigatorios)
    u.should be_valid
  end
end

Sempre que escrevo um código desses sinto que estou testando o Rails e não o meu model. No fundo a única coisa que tenho que testar é se eu coloquei a linha do validates_presence_of :atributo. O resto do trabalho (deixar o valid? falso e criar o error no campo) é problema do Rails e não do meu modelo. Além desse sensação estranha de testar a coisa errada esse é o tipo de código que eu escrevo e na hora percebo que a abordagem não é nada DRY.

Dei uma olhada em 2 opções para melhorar a abordagem dos testes, o Shoulda e o Remarkable.

Remarkable

Para instalar o remarkable com o Rails 3 o RSpec 2 precisamos usar a versão 4 que ainda está em alpha, nesse instante 4.0.0.alpha4.
Adicione ao seu Gemfile as dependências:

gem "rspec"
gem "rspec-rails"
gem "remarkable_activerecord", '4.0.0.alpha4'

Usando o Remakable você ganha alguns matcher especiais para verificar apenas se você realmente colocou a validação do atributo no seu model, por exemplo o matcher validate_presence_of. O código de teste equivalente ao de cima ficaria assim:

describe Usuario do
  it {should validate_presence_of :nome }
  it {should validate_presence_of :idade }
end

Para que o RSpec reconheça esses matchers do Remakable é preciso um último detalhe de configuração que é adicionar um require do remarkable no seu spec_helper.rb logo abaixo do require ‘rspec/rails’

# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'remarkable/active_record'

Shoulda

O shoulda ficou muito famoso sendo utilizado com o TestUnit, mas existe um sub-projeto dele que é o ‘shoulda-matchers’, atualmente na versão 1.0.0.beta1, que é a gem que vamos usar com o Rails 3 o RSpec 2. Adicione ao seu Gemfile as dependências:

gem "rspec"
gem "rspec-rails"
gem "shoulda-matchers"

Curiosamente para esses casos mais básicos o matcher do Shoulda é idêntico ao do Remakable e o código de teste fica idêntico ao dele:

describe Usuario do
  it {should validate_presence_of :nome }
  it {should validate_presence_of :idade }
end

Dessa vez não é preciso nenhuma configuração extra, basta apenas executar os testes e:  Seja uma pessoa mais feliz!

Conclusão

Ambas são ótimas opções para dar uma bombada nos seus testes, cada um com suas vantagens e desvantagens. Recomendo uma lida nas respectivas documentações para conhecer mais de cada um deles e escolher o que melhor supre suas necessidades.

Máquina / Sistema Operacional

Minha máquina “oficial” é meu macbook white 13″ que já está comigo desde 2008, mas com 4Gb e com upgrade pro Snow Leopard.

Editor

Pra arquivos texto no geral e RoR tenho e uso bastante o TextMate. Já dei algumas chances pro Vim, mas ainda não me adaptei perfeitamente, recentemente decidi lhe dar outra e parece que agora vou ficar com ele mesmo. Estou usando as configurações do Akita e o Bundle de afc que o Adriano fez. (afc é o formato que usamos pra escrever as apostilas da Caelum – Quem já teve curiosidade, conheça o Tubaina).
Pra programar java não abro mão do Eclipse!

Terminal

O bom e velho bash mesmo. Algumas poucas frescuras no ~/.bash_profile pra adicionar cores e personalizar o PS1, mas nada de mais. Normalmente meu terminal está uma zona com pelo menos umas 5 ou 6 abas abertas. Costumo ter umas 2 ou 3 por projeto (server, testes e “outros”) e quase sempre tenho abas de mais de projeto aberta.

Browser

Hoje meu browser principal é o Chrome, tanto pro dia-a-dia quanto pra desenvolvimento, mas tenho e uso o FF e o Safari. Assim como meu Terminal, meu browser também é uma salada de abas, mas piorada. Aqui tenho umas abas que ficam semanas abertas aguardando para serem lidas.

Software

QuickSilver, Adium, Skype, TweetDeck, DropBox e Keynote, além dos indispensáveis serviços do Google: GMail, Calendar e Docs.

Source-code

Felizmente tenho usado apenas o git hoje em dia.

Música

Quando preciso de muita concentração coloco meus fones e um bom Power Metal pra me isolar do mundo. Independente disso, gosto bastante de ouvir música enquanto programo, mas dentro da Caelum acabo ficando com o volume mais baixo ou com o fone em apenas 1 dos ouvidos pra ouvir as discussões. Um ponto curioso sobre as músicas comigo é que não posso ouvir uma música que me empolga e eu não conheço ela perfeitamente (saber tocar e/ou cantar). Ou escuto uma música que domino ou uma música neutra, se não ela passa a atrapalhar ao invés de ajudar. Para conhecer meu gosto musical recomendo uma passada no meu perfil no Last.fm

Os meus convidados são: Todos autores do Vida Geek

Em setembro aconteceu um dos eventos mais importantes de TI que já passou no nosso país. Pela primeira vez no Brasil ocorreu uma QCon e tive a felicidade de estar presente. Dessa vez não fui oficialmente um palestrante, mas fui convidado para ser o host de uma das tracks das lightning talks que vou comentar no final do post.

O evento não foi importante apenas pelo nome QCon, mas sem dúvidas tivemos um evento verdadeiramente de alto nível, tanto os palestrantes brasileiros quanto os internacionais fizeram ótimas apresentações. Na MINHA opinião, entre as palestras que assisti, os destaque vão para o Nick Kallen, Charles Nutter e a palestra em dupla do Alexandre Porcelli e Gleicon Moraes.

Resumindo o evento em poucas palavras me parece que a preocupação geral dos arquitetos hoje é escalabilidade. Linguagens funcionais, filas, denormalização, nosql, cloud e outros meios/técnicas para melhorar a responsividade de nossas aplicações foram assuntos muito comentados por todas as tracks que passei.

Voltando as lightning talks, tivemos ótimas apresentações! Como já falei fui o host de uma das tracks e além da minha própria talk contei com as apresentações de: Alberto Leal, Lucas Pérez, Rafael Viveiros, Cecilia Fernandes, André Luiz R. Silva, Hugo Baraúna e um pequeno oi do pessoal do GURU-SP no final. Muito obrigado e parabéns para todos vocês.

Rails Rumble

No meio de outubro aconteceu a 3ª edição do Rails Rumble, esse ano não deixei passar e, pela primeira vez, participei da competição. Meu time acabou não chegando na final, numa breve retrospectiva levantamos alguns pontos bobos onde falhamos, como não ter pensado num lugar pra tomar banho… (Sim, eu fiquei mais de 48h sem banho). Quem sabe ano que vem não aparecemos na final?! Pelo menos nossa app nos fez conhecer novos frameworks e nos trouxe algumas ideias de negócio que jamais imaginaríamos.

RubyConf Brasil 2010

O antigo Rails Summit Latin America agora está sob a franquia Ruby Conf, pela primeira vez com o nome novo, conseguiram trazer palestrantes ainda mais impressionantes do que os do ano passado, com destaque para os commiters do Rails Jose Valim, Aaron Patterson e Yehuda Katz, além do Ola Bini e novamente o Charles Nutter. Mais um evento de altíssima qualidade levando o Brasil, cada vez mais, para um patamar de igualdade com outros países considerados polos tecnológicos.

Resumindo o evento em poucas palavras, acredito que as boas práticas são chave para o momento que a comunidade está passando, foram apresentadas várias melhorias no Rails e outros frameworks auxiliares e especialmente no ruby 1.9. Acredito que o interesse de todos agora é que toda a força de vontade que a comunidade tem, relembrada pelo Fabio Akita na abertura do evento, seja catalisada para gerar valor real.

Encontro Ágil 2010

Pra finalizar os eventos do post, um evento que ainda não aconteceu. No próximo sábado, dia 06/11 vai acontecer o Encontro Ágil 2010, num formato completamente inovador, com muitos jogos, dojos e nada de palestras tradicionais, como eles anunciaram, um evento da comunidade para a comunidade, onde terei o prazer de falar sobre dívida técnica e como evita-la numa lightning talk que em breve estará disponível no meu Slideshare

Finalmente aqui estão slides da minha lightning talk na QCon:

Infelizmente eu e o Adriano Almeida tivemos um tempo bem limitado pra falar sobre um assunto tão amplo, mas acredito que alcançamos nosso objetivo e fizemos quem estava presente se questionar sobre as escolhas de tecnologia para persistência. Durante nossos 30 min falamos sobre o que é NOSQL, comentamos sobre a estrutura de alguns tipos de banco de dados não relacionais e finalmente apresentamos o Neo4j como uma implementação de Graph Database. Terminamos mostrando como integrar com rails através do Binding JRuby ou através da API REST utilizando o Restfulie para isso.
Slides da apresentação:

Sobre a minha palestra com o Leonardo Bessa, infelizmente demos uma atrasadinha na primeira metade da palestra e não conseguimos falar de tudo o que queríamos, mas pelo feedback que tivemos acredito que os presentes gostaram e aprenderam. O que não deu tempo de falar no dia com certeza vai virar post aqui no futuro. Para os que não puderam ir, felizmente o pessoal da organização gravou o evento e o vídeo da nossa apresentação pode ser visto aqui:

Para aqueles que foram ou apenas viram o vídeo, aqui estão os slides da palestra:

E aqui o código gerado durante a apresentação:

class Picapau
  def voa
    "voando..."
  end
  def anda
    "andando..."
  end
end
woody = Picapau.new
amigo = Picapau.new
#
# woody.voa
# amigo.voa
# woody.anda
# amigo.anda
#
# def woody.hehehe
#   p "hehehe-hehehe-hehehehehe"
#
# end
#
# woody.hehehe
#
# # amigo.hehehe
#
#
# p woody.class
# p amigo.class
# p woody.class == amigo.class
class Object
    def singleton_class
      # p self
      class << self
        # p self
      self
      end
    end
end
# p woody.singleton_class
# p amigo.singleton_class
# p amigo.singleton_class == woody.singleton_class
#
# class Picapau
#   alias :metodo_voa :voa
#   def voa(param='')
#     result = metodo_voa(param)
#     p "Chamando metodo voa com #{param.inspect} retornou #{result.inspect}"
#     result
#   end
# end
#
# class Picapau
#   def self.log(metodo)
#     metodo_velho = self.instance_method(metodo)
#     define_method(metodo) do |*arg|
#       result =  metodo_velho.bind(self).call(arg)
#       p "Chamando metodo voa com #{arg.inspect} retornou #{result.inspect}"
#     end
#   end
#   log :voa
# end
#
# class Picapau
#   def self.log(*metodos)
#     metodos.each do |metodo|
#       metodo_velho = self.instance_method(metodo)
#       define_method(metodo) do |*arg|
#         result =  metodo_velho.bind(self).call(arg)
#         p "Chamando metodo voa com #{arg.inspect} retornou #{result.inspect}"
#       end
#     end
#   end
#   log :voa, :anda
# end
module Logger
  def log(*nome_do_metodos)
     nome_do_metodos.each do |nome_do_metodo|
       metodo_velho = self.instance_method(nome_do_metodo)
       define_method(nome_do_metodo) do
         result = metodo_velho.bind(self).call
         p "Chamando metodo #{nome_do_metodo} e retornou #{result}"
         result
       end
     end
   end
end
module Andador
  def anda2
    p "novo metodo que anda"
  end
end
class Picapau
  extend Logger
  include Andador
  log :voa, :anda
end
woody.voa
woody.anda
woody2 = Picapau.new
woody2.anda2

Sobre o futuro, no dia 29 de maio estarei palestrando junto com o Leonardo Bessa no Ruby + Rails no mundo Real. Vamos falar, novamente, sobre Metaprogramação em ruby, mas dessa vez temos 1h e com certeza vamos ainda mais fundo nesse assunto.
Já tenho alguns posts em draft e em breve devo voltar a média de pelo menos 1 post por mês.
Até o próximo post!