Prodis a.k.a. Fernando Hamasaki de Amorim

PaperClip é um plugin de upload de arquivos para Ruby on Rails que cria atributos dos arquivos nas classes ActiveRecord funcionando da mesma maneira como se estivesse utilizando campos do banco de dados.

Para utilizar esse plugin, é necessário instalar o ImageMagick, que pode ser feito via MacPorts:
$ sudo port install ImageMagick

Eu fiz isso e obtive o seguinte erro:

On Mac OS X 10.5, tiff 3.8.2 requires Xcode 3.1 or later but you have Xcode 3.0.
Error: Target org.macports.extract returned: incompatible Xcode version
Error: The following dependencies failed to build: tiff xorg-libXext xorg-libX11 autoconf help2man p5-locale-gettext m4 automake libtool xorg-bigreqsproto xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-libXt xorg-libsm xorg-libice
Error: Status 1 encountered during processing.

.
Para instalar o ImageMagick no Mac OS X 10.5 é preciso ter o Xcode 3.1 ou superior. Eu tinha o Xcode 3.0 instalado, então fui até a página de desenvolvedores da Apple e baixei a últma versão do Xcode para Mac OS X 10.5.

O endereço é https://connect.apple.com. Você precisa se logar para ter acesso aos downloads. Se você não tem cadastro, pode criar uma nova conta.

Depois de logado, clique no link Downloads, depois no menu da direita em Developer Tools, localize a seção Xcode 3.1.4 Developer Tools e faça o download dos 993 MB do arquivo Xcode 3.1.4 Developer DVD (Disk Image).

Após instalado o Xcode 3.1.4, você já pode instalar o ImageMagick via MacPorts e depois utilizar o PaperClip.

Para mais informações sobre o PaperClip, acesse esse link:
http://delicious.com/prodis.net/paperclip

Unix ActiveRecord, ImageMagick, Mac OS X, PaperClip, Ruby on Rails, Unix, Xcode

Nas últimas semanas, a equipe que eu trabalho estava desenvolvendo um web service onde havia a necessidade de renderizar o retorno de uma lógica de negócio em representações XML. Digo representações (no plural), pois para um retorno com sucesso a representação seria uma e para retorno com erro a representação seria outra.

Por exemplo, um retorno com sucesso:

<natural-person>
  <name>Prodis</name>
  <cpf>01234567890</cpf>
</natural-person>

E um retorno sem sucesso:

<error>
  <description>CPF inválido.</description>
</error>

Como era um web service em REST, para sucesso retornamos o código de status HTTP “200 OK” e, dependendo do não sucesso da operação, o código de status HTTP da resposta poderia ser “400 Bad Request”, “404 Not Found” ou qualquer outro código 4xx ou 5xx que melhor se adequasse.

Mantendo um controller magro, a idéia era somente instanciar uma classe de negócio, chamar um método e renderizar o retorno. Algo como:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    natural_person = business.search_by_cpf params[:cpf]

    # TODO: Renderizar pessoa física ou mensagem de erro
  end
end

A partir daqui a equipe iniciou uma discussão sobre a melhor forma de se obter o(s) retorno(s) esperado(s). O controller precisava saber se a consulta havia sido feita com sucesso, para renderizar um objeto NaturalPerson retornando o código de status HTTP 200, ou se a consulta não tivesse sucesso, renderizar a mensagem de erro retornando um código de status HTTP 4xx adequado.

Como “bons programadores .NET e Java”, a primeira coisa que pensamos foi lançar uma exceção customizada caso a consulta não tivesse sucesso, capturar essa exceção no controller e, através das informações de descrição de erro e código de status HTTP contidas nessa exceção, renderizar o retorno adequado.

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new

    begin
      natural_person = business.search_by_cpf params[:cpf]

      render natural_person, 200
    rescue BusinessException => e
      render e.error, e.status_code
    end
  end
end

A gente não tinha visto muito código Ruby utilizando begin rescue, então essa solução não nos pareceu muito “Ruby way”. Achamos melhor pedir a opinião de alguém com mais experiência em Ruby. Perguntamos ao Rafael Rosa, que nos disse que cada vez que lançamos uma exceção em Ruby “alguma coisa ruim acontece no servidor” e consequentemente a aplicação ficará mais lenta.

Ele indicou um post falando a respeito:
http://www.simonecarletti.com/blog/2010/01/how-slow-are-ruby-exceptions

Rafael Rosa nos sugeriu retornar um array de duas posições: uma com o código de status HTTP e outra com o objeto a ser renderizado.

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result[1], result[0]
  end
end

Resolveu, mas o código não ficou muito intuitivo. A partir daí imaginamos algumas outras soluções.

Retornar um hash:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result[:data], result[:status_code]
  end
end

Criar uma classe de retorno:

class SomeBusinessResult
  attr_accessor :status_code, :data
end

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    result = business.search_by_cpf params[:cpf]

    render result.data, result.status_code
  end
end

Posteriormente, o Rafael Rosa também sugeriu essa última opção, mas criando uma Struct ao invés de uma classe.

Então eu sugeri o método search_by_cpf retornar dois valores. Todos da equipe me perguntaram: “Como assim retornar dois valores?”. Falei que em Ruby um método pode retornar vários valores, que vi isso no livro The Ruby Programming Language.

O código do controller ficou bem mais intuitivo:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    status_code, data = business.search_by_cpf params[:cpf]

    render data, status_code
  end
end

O método search_by_cpf está retornando tanto o código de status HTTP quanto os dados para serem renderizados:

class SomeBusiness
  def search_by_cpf(cpf)
    # Lógica de negócio aqui
    return 200, natural_person
  end
end

Note que mesmo a linha 4 sendo a última linha de instrução do método, o retorno de mais de um valor obrigatoriamente precisa utilizar o comando return.

Quando há mais de um valor de retorno para um método, os valores são colocados implicitamente dentro de uma array e essa array fica sendo o único retorno do método.

O mesmo resultado seria obtido dessa forma:

class Business
  def search_by_cpf(cpf)
    # Lógica de negócio aqui
    [200, natural_person]
  end
end

Quem está consumindo um método que retorna mais de um valor, pode utilizar o recurso de atribuição paralela do Ruby para distribuir os valores de retorno em variáveis distintas, como é o caso no nosso controller:

class NaturalPersonController < ActiveRecord::Controller
  def index
    business = SomeBusiness.new
    status_code, data = business.search_by_cpf params[:cpf]

    render data, status_code
  end
end

O dinamismo do Ruby lhe oferece várias opções para você encontrar soluções para o mesmo problema ou questão. Cabe a você decidir qual melhor abordagem para seu tipo de problema. O interessante é você conhecer essas opções para facilitar a sua decisão.

Ruby Exception, REST, Ruby, Ruby on Rails

Segue a relação dos cinco melhores posts (ou os mais acessados e comentados) do ano de 2009.

1. Configurando teclado em inglês no Ubuntu (e com cedilha)
2. Curso de Ruby on Rails na Caelum
3. Sanguessugas de blogs
4. Serialização de objetos em JSON com .NET
5. Cheeseburgers, Decorators e Mocks

.NET, Arquitetura, Ruby, Unix .NET, Arquitetura, Blog, Decorator, JSON, Linux, Melhores do ano, Mock, Ruby, Ruby on Rails, Serialização, Ubuntu, Unix

Em um post anterior mostrei como serializar objetos em JSON utilizando .NET. Agora vamos fazer a mesma coisa com Ruby on Rails.

Esse é o Jason, não JSON.

Vamos utilizar como exemplo uma classe de modelo chamada SomeFake:

class SomeFake < ActiveRecord::Base

end

Utilizando essa migration:

class CreateSomeFakes < ActiveRecord::Migration
  def self.up
    create_table :some_fakes do |t|
      t.string :text
      t.float :value
      t.timestamps
    end
  end

  def self.down
    drop_table :some_fakes
  end
end

No script/console vamos criar uma instância do modelo SomeFake com os seguintes dados:
>> fake = SomeFake.create :text => "I am a sample text.", :value => 150.85
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:18ac9f0,'0.15085E3',8(12)>, created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">

Então queremos serializar a variável fake em JSON para obter o seguinte resultado:
{"id":1,"text":"I am a sample text.","value":150.85}

Para fazer isso, vamos chamar o método to_json na variável fake (estou usando o comando print para uma exibição melhor no console do JSON gerado):
>> print fake_json = fake.to_json
"{"some_fake": {"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.", "id": 1, "value": 150.85, "created_at": "2009-12-13T19:43:28Z"}}"


O resultado que obtemos não é exatamente igual ao que estávamos querendo.

Primeiro, o nome do nosso modelo foi serializado como raiz do objeto em JSON. Isso aconteceu porque por padrão em uma aplicação Rails, a opção ActiveRecord::Base.include_root_in_json é configurada para true no arquivo config/initializers/new_rails_defaults.rb. Nós podemos alterar essa opção para false nesse arquivo, o que afeta a serialização em JSON de toda a aplicação, ou podemos alterá-lo no próprio script/console para nossos testes:
>> ActiveRecord::Base.include_root_in_json = false
=> false


Agora nosso objeto serializado fica assim:
>> print fake_json = fake.to_json
"{"updated_at": "2009-12-13T19:43:28Z", "text": "I am a sample text.", "id": 1, "value": 150.85, "created_at": "2009-12-13T19:43:28Z"}"


A segunda diferença é que não queremos que os atributos de timestamps (created_at, updated_at) sejam serializados. Então vamos dizer para o método to_json não serializar esses atributos, utilizando a opção except:
>> print fake_json = fake.to_json(:except => [:created_at, :updated_at])
“{”text”: “I am a sample text.”, “id”: 1, “value”: 150.85}”


Para fazer o inverso, transformar dados em JSON para um objeto, criamos uma nova instância da classe SomeFake e chamamos o método from_json passando a variável fake_json como parâmetro:
>> other_fake = SomeFake.new
=> #<SomeFake id: nil, text: nil, value: nil, created_at: nil, updated_at: nil>


>> other_fake.from_json fake_json
=> #<SomeFake id: nil, text: "I am a sample text.", value: #<BigDecimal:1708a04,'0.15085E3',8(12)>, created_at: nil, updated_at: nil>


Caso você precise serializar objetos em JSON sem os atributos timestamps com frequência, ao invés de sempre passar a opção except para o método to_json, podemos incluir um novo método na classe ActiveRecord::Base que faça a serialização sem esses atributos. Dessa forma, todos os nossos modelos terão essa funcionalidade.

Vamos chamar esse método de to_json_no_timestamps, o qual sua implementação é mostrada abaixo:

class ActiveRecord::Base
  def to_json_no_timestamps(options = {})
    timestamps_options = [:created_at, :updated_at]

    if (options.has_key? :except)
      if (options[:except].class == Array)
        timestamps_options = options[:except] | timestamps_options
      else
        timestamps_options << options[:except].to_sym unless options[:except].nil?
      end
    end

    options[:except] = timestamps_options

    to_json options
  end
end

E então basta chamar nosso novo método em uma instância de qualquer modelo:
>> fake = SomeFake.first
=> #<SomeFake id: 1, text: "I am a sample text.", value: #<BigDecimal:1712798,'0.15085E3',8(12)>, created_at: "2009-12-13 19:43:28", updated_at: "2009-12-13 19:43:28">

>> print fake_json = fake.to_json_no_timestamps
"{"text": "I am a sample text.", "id": 1, "value": 150.85}"

Arquitetura, Ruby ActiveRecord, JSON, Ruby, Ruby on Rails, Serialização

Ruby Head First, Livros, Rails, Ruby, Ruby on Rails, Use a Cabeça

Quarta, 14 de outubro, aconteceu o segundo e último dia do Rails Summit Latin America 2009, o maior evento das comunidades Ruby e Ruby on Rails da América Latina.

Todos os palestrantes do Rails Summit Latin America 2009 por Daniel Cukier

Vamos às palestras.

Richard Kilmer: MacRuby + HotCocoa

Richard Kilmer mostrou como o MacRuby e o HotCocoa podem simplificar o desenvolvimento para aplicações que rodam no Mac OS X. Ele disse que alguns objetivos da Apple são fazer o Mac OS X a melhor plataforma para desenvolvimento em Ruby e tornar Ruby a principal linguagem de programação para o framework Cocoa.

Ele explicou que com a utilização de RubyCocoa há o processo do Ruby rodando de um lado que conversa com o runtime do Objective-C, sendo assim há dois garbage collectors. Além disso, a sintaxe do RubyCocoa, adaptada do Objective-C é um tanto “odd”, quando se diz respeito a selectors do Objective-C.

Já com MacRuby, a sintaxe usando hashs nos parâmetros dos selectors ficam mais claras. Em geral, a sintaxe fica muito mais simplificada que a sintaxe que Objective-C. O MacRuby unifica o modelo de objetos de Ruby e Objective-C, tudo que é objeto no Ruby é objeto no Objective-C.

Com a versão 0.5 doMacRuby haverá uma nova máquina virtual chamada LLVM (Low Level Virtual Machine), que compila código Objective-C. Todas as características dinâmicas do Ruby iram rodar com melhor performance.

Richard por fim exemplificou como o HotCocoa simplifica o uso de recursos de Objective-C utilizando MacRuby. Foi mostrado um exemplo de código com e sem HotCocoa e a quantidade de código que se reduziu o programa foi incrível. Você consegue criar janelas, botões e outros controles com ele usando poucas linhas de código.

O vídeo da apresentação você pode assistir aqui e os slides da apresentação você pode visualizar aqui.

Carlos Villela: Ruby na ThoughtWorks

Carlos Villela fez sua apresentação baseada no artigo Ruby at ThoughtWorks publicado por Martin Fowler. Ele disse que a ThoughtWorks é pioneira em desenvolvimento ágil e que possui em torno de 42 projetos em Ruby espalhados pelo mundo. Na Inglaterra, a adoção de Ruby demorou um pouco em relação a outros países. A grande maioria dos projetos em Ruby aconteceram nos EUA.

Em uma pesquisa interna, foi perguntado se Ruby foi uma boa escolha? A maioria respondeu que sim e que Ruby era mais produtivo realmente, sendo que 13 dos 42 projetos acharam que a produtividade dobrou. Mas 5 disseram que não foi uma boa escolha, onde 4  dos 5 disseram que havia uma curva de aprendizado que não cabia no projeto.

Quanto a performance nenhum projeto teve problema.

Também foi pergunta na pesquisa se Ruby é difícil de entender? Existe muita coisa nova em relação a outras linguagens comerciais e há, além da curva de aprendizado, a curva de manutenção. Quando mais você usa meta-programação você acha que é óbvio e bom, mas excesso de meta-programação não é um bom sinal.

Ele disse que muitas vezes a plataforma Ruby não é viável por conta do ambiente da empresa, e enfatizou que Ruby não é uma solução para tudo.

No final da palestra ele apresentou algumas dicas:

• Controllers magros, modelos cheios, mas não ter toda a lógica do sistema, somente o que for lógica de negócio.
• Testes com ActiveRecord falando com banco de dados de verdade, sem usar stubs.
• Exposição de SQL no AcitveRecord: muitas vezes é inevitável.
• Requisições de longa duração: uso de filas quando possível e um módulo separado do Apache que não roda no Rails (gambi?).
• Controle de Gems: tomar cuidado para uma atualização de gem não quebrar o que está funcionando.
• Atualizações: pode quebrar seu código, não demore muito para atualizar suas gems.
• Desenvolvimento no Windows: não rola, rodar em produção é viagem, desenvolver no Windows dá, mas não vale a pena.
• Não se empolgue tanto com plug-ins: confira se o plug-in tem um mínimo de qualidade, não saia instalando tudo quanto é plug-in no seu projeto, planeje bem isso para não criar um monte de dependências.

O vídeo da apresentação você pode assistir aqui.

Nando Vieira: O que mudou no Ruby 1.9

Nando Vieira
por Levy Carneiro

Nando Vieira mostrou as diferenças da nova versão do Ruby e deu dicas para uma futura migração do seu código atual.

Os slides da apresentação você pode visualizar aqui.

Pratik Naik: Lessons Learnt in 2009

Pratik Naik
por Levy Carneiro

Eu não assisti a palestra do Pratik Naik. De acordo com Herbert Fischer, problemas como posicionamento de microfone e slides com fontes pequenas atrapalharam um pouco.

De qualquer forma, o vídeo da apresentação você pode assistir aqui.

Marcos Tapajós: CouchDB no Rails

Marcos Tapajós iniciou apresentando alguns recursos e características do CouchDB:

• Orientado a documentos: no CouchDB um documento nada mais é do que um JSON.
• Há uma maior flexibilidade, pois não há esquema definido.
• Se quiser colocar mais um campo, vai lá no JSON e acrescenta, não precisa alterar o banco de dados.
• A comunicaçào com o banco é feito por REST.
• Todos os documentos armazenados no banco são versionados. Todas as operações que você faz no banco, é criada uma nova versão.
• Há um rotina de manutenção para eliminar as versões de documentos anteriores, com um gerenciador de conflitos.
• É legal você quebrar os documentos de uma forma que você evite a possibilidade de conflitos. Acaba sendo uma sutileza, não porque o documento vai ficar grande.
• As consultas no CouchDB são feitas através de views, utilizando o conceito de map reduce.
• É possível fazer replicação bidirecional no CouchDB. Essa replicação fica consistente por conta do versionamento de documentos.
• A replicação traz uma grande vantagem de você ter uma aplicação offline, que pode ser sincronizada com outra base que funciona como Master. Funciona mais ou menos como no Git, onde você tem um repositório local e vai sincronizando com o repositório remoto.
• É possível gravar arquivos binários (doc, pdf, jpg, etc) como “attachments”.  Nas consultas você não trafega os anexos, a não ser que você especifique isso quando quiser trazer o arquivo.

Depois ele falou que o casamento entre o CouchDB e o Ruby é muito bom. Você pode pegar o objeto como ele é na sua aplicação e jogar isso dentro do banco de dados. Com isso, elimina o mapeamento objeto-relacional.

APIs CouchDB de Rails que mapeiam como ActiveRecord não são legais. Você tem que quebrar o paradigma de um banco de dados relacional.

Por fim, ele recomendou o utilização da gem CouchRest para interagir com o CouchDB no Rails.

Os slides da apresentação você pode visualizar aqui.

Bruno Miranda e Jeison Seifer: Rails não Escala

Usando o estudo de caso do Cyloop, uma aplicação Rails por baixo do canal de áudio da MSN do Canadá até a Argentina, incluindo MSN Brasil, Bruno Miranda e Jeison Seifer mostraram como ajustar uma arquitetura para escalabilidade com técnicas incluindo filas, engines alternativos de storage, Rails Metal e Web Services.

O vídeo da apresentação você pode assistir aqui.

Vinícius Telles: Do serviço ao produto

Vinicius Telles contou a interessante trajetória de sua carreira. Não vou me alongar aqui, pois você pode (e deve) assistir a palestra inteira. Somente quero frizar algumas frases interessantes que foram ditas:

• O líder sempre é o culpado, mas quem leva os méritos é a equipe.
• Saiba escutar e reconheça seu erro.
• Existe uma diferença entre os EUA e o Brasil: lá fora eles tem uma auto-estima enorme.
• Se você não fizer algo que não lhe satisfaz, não faça mais isso. Você nunca conseguirá voltar no tempo.
• Primeira coisa para abrir uma empresa: pense em ter uma reserva. Às vezes a reserva é seu próprio atual emprego.
• Software tem muito a ver com relacionamentos entre pessoas, no caso seus clientes, do que mais do que tecnologia.
• Converse com o cliente: pessoalmente ou por telefone. As pessoas não tem confiança que tem alguém do outro lado.
• Isoladamente o software, a reserva e o relacionamento com o cliente não importa, o que importa é o conjunto que essas coisas geram.
• Paciência é muito importante para o empreendorismo.
• A melhor maneira de se destacar nesse mundo é compartilhar suas experiências. Ajudar as pessoas acaba sendo uma iniciativa de marketing.

Arthur Zapparoli: Git - Controle de Versões do Jeito Certo

A palestra do Arthur Zapparoli eu não assisti, mas os slides da apresentação você pode visualizar aqui.

Obie Fernandez: Mastering the Art of Application Development

Para fechar o Rails Summit 2009, Obie Fernandez fez sua apresentação dizendo que desenvolvimento de aplicações é arte. O importante é a prática, em tudo que você faz, para se tornar um mestre.

O desenvolvedor deve, ou deveria passar, por estágios semelhantes ao Shu Ha Ri:

Numa primeira fase, você está em Shu, o “seguir”, você ouve o que o instrutor/professor/sênior está lhe passando a informação e você simplesmente “recebe” e repete o que ele manda. Você ainda não é capaz de discutir ou raciocinar sobre isso agora porque você basicamente não tem conhecimento ou vivência o suficiente pra isso.

Em uma segunda fase você passa pra Ha e começa a experimentar caminhos diferentes, começa finalmente a raciocinar sobre o que está fazendo e fugir um pouco dos caminhos que o mestre ensinou.

Na última fase, o Ri ou transcendência, o estudante vira praticante e busca agora originalidade na prática, ele a aperfeiçoou de uma forma que ela não é mais igual a do seu mestre mas sim a melhor para ele mesmo.

Descrição de Shu Ha Ri retirada do comentário de Maurício Linhares de Aragão Junior no post http://akitaonrails.com/2009/09/26/off-topic-procurar-raciocionar-faz-bem

Obie sugeriu que para se tornar bom em alguma coisa, uma pessoa deve ter 10.000 horas de prática, enfatizando não só as 10.000 horas, mas também a prática correta, do jeito certo.

Ele questionou: Quantas horas você realmente codifica (pratica)? Em que você gasta o seu tempo?

E para finalizar: “Keep practicing for excelence. What you waiting for?”

O vídeo da apresentação você pode assistir aqui.

Eventos, Ruby Eventos, Rails, Rails Summit, Ruby, Ruby on Rails

Hoje aconteceu o primeiro dia do Rails Summit Latin America 2009, o maior evento das comunidades Ruby e Ruby on Rails da América Latina.

Antes de iniciar a abertura do evento, eu e o Luciano Coelho aproveitamos para jogar algumas partidas de baseball e tênis num dos Wii que estavam disponíveis para a galera jogar. Mas vamos às palestras do dia.

Chad Fowler: Ruby on Rails Insurgency

Na primeira palestra do dia, Chad Fowler mostrou um pouco de como o Rails está alcançando desenvolvedores corporativos e sendo utilizados por empresas startups.

Chad Fowler é autor do livro The Passionate Programmer: Creating a Remarkable Career in Software Development, o qual você pode obter aqui.

O vídeo da apresentação você pode assistir aqui.

Gregg Pollack: Scaling Rails in 60 seconds

Gregg Pollack deu dicas de utilização de plugins do ActiveRecord e Rails, como o Bullet e o Rack-bug, e libraries, como o Mad Mimi, que ajudam a otimizar aplicações Ruby on Rails.

O vídeo da apresentação você pode assistir aqui e uma lista completa dos plugins você tem nesse link.

Carlos Brando: Como o Rails funciona por dentro

Em sua palestra, Carlos Brando acabou falando mais a respeito do framework Sociably, que está desenvolvendo na empresa SocialSmart.

Logo na introdução do apresentação ele perguntou à platéia quem programava em Rails. A grande maioria levantou a mão. Mas aí, ele disse: “Ninguém aqui programa em Rails, vocês programam em Ruby. Ruby on Rails não é linguagem de programação, é um framework Web desenvolvido em Ruby.”

Além disso, ele fez uma analogia com o Rails sendo igual macarrão instantâneo, pois rapidamente fica pronto. Mas não dá para fazer feijoada com miojo, então Rails não serve para tudo.

Os slides da apresentação você pode visualizar aqui.

Glenn Vanderburg: Tarantula - Rails Fuzz Testing

Glenn Vanderburg apresentou o Tarantula, um plugin Rails para realizar testes fuzz de maneira fácil e repetitível para aplicações Rails.

O vídeo da apresentação você pode assistir aqui.

José Valim: Geradores de código com Thor e Rails 3.0

José Valim explicou como o Thor uniu os geradores de código, tarefas e templates do Rails, substituindo o Rake, Sake e Rubigen.

Os slides da apresentação você pode visualizar aqui.

David Chelimsky: RSpec and Cucumber: Beyond the Basics

David Chelimsky, acabou falando praticamente somente de RSpec. Ele destacou que utilizando BDD com RSpec, você mantém o foco no comportamento, cria uma documentação executável, os testes são fáceis de ler e acabam sendo uma otimização de TDD.

Uma frase interessante da palestra foi “Balancing DRY and clarity is an art”.

David Chelimsky é autor do livro The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends, o qual você pode obter aqui.

Fabio Kung: DSLs Internas e Ruby

Fabio Kung
por Levy Carneiro

Essa apresentação do Fabio Kung infelizmente eu não assisti, mas quem viu disse que gostou muito.

O vídeo da apresentação você pode assistir aqui, os slides da apresentação você pode visualizar aqui e o código-fonte você pode baixar aqui.

Fabio Akita: Agile, além do Caos

Nem me arrisco a falar muito dessa palestra do Fabio Akita. Ela foi muito boa, mas foi uma grande viagem. Coisas do tipo “Caos não é aleatório, caos não é caótico.” e “Auto-organização emerge de sistemas caóticos naturalmente.” ditaram o rumo da apresentação.

O que achei interessante é que no final das contas, as idéias foram lançadas, mas não houve conclusões. Cada um pensa a respeito do viu e ouviu e se quiser, ou puder, tire suas conclusões. Meu, viagem, assista.

O vídeo da apresentação você pode assistir aqui.

Matt Aimonetti: The Future of Ruby & Rails

Matt Aimonetti mostrou o que vem por aí na versão 3.0 do Rails com a junção do Merb. Também falou a respeito das novidades do Ruby, JRuby, IronRuby e MacRuby.

O vídeo da apresentação você pode assistir aqui.

Desconferência

A desconferência é um espaço para os participantes do evento fazerem suas próprias apresentações e palestras em um curto espaço de tempo.

O destaque foi para o Aldo Filho, um garoto de 11 anos, que fez uma apresentação da sua trajetória em dois meses para aprender a programar (desde o Oxente Rails) e depois, ao vivo, criou o tal do blog em 15 minutos.

E imaginar que tem nêgo barbado que não consegue fazer uma apresentação, o garoto teve a coragem de subir no palco e programar na frente de mais de 100 expectadores.

O vídeo da apresentação você pode assistir aqui.

Eventos, Ruby Eventos, Rails, Rails Summit, Ruby, Ruby on Rails

Estou começando a desenvolver em Ruby on Rails e, da mesma forma que descrevi no post anterior, gostaria de ler uma revista específica sobre o assunto. Até então não havia encontrado nenhuma e estava até pensando se os rubystas brasileiros não tomariam a iniciativa.

Eis que ontem leio uma mensagem no Twitter do Fabio Akita recomendando a leitura da edição 4 da Rails Magazine. Fiquei muito feliz em saber sobre a existência dessa revista.

E como não poderia deixar de ser, já que estamos falando sobre Ruby, a revista é grátis. Você pode baixar o arquivo PDF de cada edição ou navegar no site pelas edições para ler online os artigos. Caso você opte pela versão impressa, aí sim terá que pagar pela mesma.

A Rails Magazine se auto-define como uma revista periódica, mas não especifica qual é essa periocidade. A revista é mantida pela comunidade Ruby on Rails e aceita contribuições e sugestões de artigos. Além disso, doações são bem vindas para manter a revista no formato atual.

Você pode acessá-la utilizando o endereço abaixo:
http://railsmagazine.com

Ruby Grátis, Rails, Rails Magazine, Revistas, Ruby, Ruby on Rails

Estão abertas as inscrições para o Rails Summit Latin America 2009, o maior evento das comunidades Ruby e Ruby on Rails da América Latina.

O evento, que é organizado pelo Locaweb, acontecerá nos dias 13 e 14 de outubro, no Centro de Convenções Anhembi, em São Paulo. A última edição reuniu mais de 550 participantes.

Palestrantes como Obie Fernandez, Chad Fowler, Fabio Akita, Richard Kilmer, Vinicius Telles e Carlos Brando estarão presentes.

O valor da inscrição é R$ 400,00 ou R$ 200,00 para estudantes. 10% de desconto para grupos de 5 ou mais registros inteiros (não-estudantes).

Inscrições, programação, lista completa dos participantes e demais informações você tem no site do evento.

Eventos, Ruby Eventos, Rails, Rails Summit, Ruby, Ruby on Rails

Está previsto para 15/08/2009 o lançamento do livro Use a Cabeça Rails, pela editora Alta Books, que promete mostrar de uma maneira divertida como utilizar os recursos do Ruby on Rails, um framework para desenvolvimento ágil de aplicações Web baseado em Ruby, que aumenta a velocidade e a produtividade do desenvolvimento de suas aplicações sem comprometer a qualidade do código.

O livro original, Head First Rails de David Griffiths, publicado pela editora O’Reilly, faz parte da série Head First, que traz um formato diferente de transmitir conhecimento. Segundo os criadores da série, Kathy Sierra e Bert Bates, a abordagem consiste em apresentar a informação para o cérebro de forma amigável e interessante, usando exemplos do cotidiano, o que faz com que a aprendizagem seja mais fácil e prazerosa. O cérebro é estimulado a aprender. O truque é fazer com que seu cérebro defina qual informação é realmente importante.

Tendo como base pesquisas de neurobiologia, ciência cognitiva e teoria do aprendizado, os livros da série Head First têm um visual rico, recheados de ilustrações inteligentes, projetados na forma como seu cérebro funciona; não se tratando de uma abordagem pesada que faz com que você caia no sono profundamente.

A Alta Books já publicou várias traduções dos livros dessa série, com o nome de Use a Cabeça.

Através do Submarino, você pode cadastrar seu e-mail nesse endereço para ser avisado quando o livro estiver disponível para venda, pois o mesmo já aparece no catálogo.

O livro Use a Cabeça Rails, que tem como preço inicial R$ 76,41, é uma ótima opção para quem quer aprender ou está começando a mexer com Ruby on Rails.

Ruby Head First, Livros, Rails, Ruby, Ruby on Rails, Use a Cabeça