MouseOver Studio

MouseOver Studio header image 1

Indexação de documentos em JRuby com ActiveLucene

por Diego Carrion - janeiro 27th, 2010 · 5 comentários

ActiveLucene é uma interface para o Lucene similar com a interface do ActiveRecord e/ou ActiveModel.

Isso quer dizer que você pode gerar um scaffold numa aplicação Rails, ir no modelo, trocar ActiveRecord::Base por ActiveLucene::Document e tudo deveria continuar funcionando, com a diferença do modelo estar sendo salvo num índice do Lucene e não num banco de dados relacional.

Dado que os documentos são salvos num índice do Lucene, podemos procurar eles utilizando a sintaxe de query do Lucene, sem esquecer que por ter uma interface similar à do ActiveRecord, podemos também procurar eles por um id.

A classe base do ActiveLucene se chama Document porque ao igual que os documentos de outros sistemas, não tem uma estrutura definida e todos os atributos são dinâmicos, pelo que você não tem que se preocupar com eles.

o ActiveLucene foi extraído do Lunr, um servidor do qual vou falar num futuro post, mas hoje também pode ser utilizado em aplicações nas quais ter um banco de dados relacionais no faz muito sentido e especialmente nas quais se deseja procurar documentos por texto.

A restrição do ActiveLucene é que somente funciona com JRuby, dado que o Lucene é uma biblioteca em Java que roda sobre a JVM. Mesmo assim, caso isso não for um problema, utilizar o ActiveLucene deve ser bem mais simples e leve que utilizar uma solução como o Sphinx ou o Solr, onde dependendo do caso pode resultar numa grande vantagem.

O Lucene tem um monte de funcionalidades e o ActiveLucene não suporta todas elas, mas dependendo das necessidades das pessoas elas serão indo adicionadas ao projeto. Hoje existe um suporte a highlighting e um pouco a paginação, como pode ser visto no seguinte video, junto com uma demonstração básica de como funciona a ferramenta:

Full text search in JRuby with ActiveLucene from Diego Carrion on Vimeo.

Se você gostou do ActiveLucene, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ 5 comentáriosTags: Api · gem · java · jruby · jvm · plugin · Uncategorized

Logs com cores no Signal

por Diego Carrion - janeiro 20th, 2010 · Sem comentários

Faz uns dias foi adicionado no Signal o suporte a mostrar os logs dos builds com cores.

Caso estejam utilizando o Cucumber, deverão garantir que ele seja executado com a opção –color ou -c.

Caso estejam utilizando o RSpec, a variável de ambiente RSPEC_COLOR devera estar setada como true.

Com as opções mencionadas, os respectivos comandos irão criar o ouput com os códigos ANSI representando as diversas cores e o Signal conseguira entender isso.

Escrevendo o post teve uma idéia: proximamente o Signal vai executar o build setando a variável de ambiente RSPEC_COLOR como true automaticamente, de modo que quem utiliza RSpec não tenha que se preocupar com ela.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ Sem comentáriosTags: signal

Resumo das novas funcionalidades no Inploy

por Diego Carrion - dezembro 18th, 2009 · 1 comentário

Após ter anunciado o Inploy faz aproximadamente 2 meses, varias pessoas tem colaborado com ele e feito que ganhe mais funcionalidades, as quais vou expor nesse post.

Antes de mais nada, queria agradecer a essas pessoas pelas contribuições:

  • Andy Shen
  • Carlos Brando
  • Douglas Campos
  • Erik Dahlstrand
  • Joris Trooster
  • Josh Owens

Se você atualizar hoje o Inploy e não fizer mais nada, as funcionalidades que voce vai ganhar automáticamente são duas:

Controle de submódulos

Essa funcionalidade consiste em inicializar/atualizar os submódulos do Git em cada deploy, de modo que o código fique sempre atualizado sem a possibilidade de esquecer.

Notificação no Hoptoad

Para os que utilizam o Hoptoad, em cada atualização de código o Inploy ira avisar a ferramenta, enviando o ambiente e o código da revisão do deploy.

Além das novas funcionalidades mencionadas, o Inploy agora também conta com as seguintes configurações opcionais, as quais podem ser utilizadas no arquivo deploy.rb:

sudo

Caso queiramos que o usuário do deploy execute os comandos como sudo

server (suporte a Unicorn)

Agora o Inploy também trabalha com Unicorn, além do Passenger.

environment

O Inploy trabalha com production como environment padrão, mas agora podemos utilizar outro na noussa preferencia, como por exemplo staging.

branch

Tem vezes que temos um branch com as configurações do nosso deploy e desejamos utilizar ele, com a opção branch temos essa possibilidade.

ssh_opts

Caso desejamos utilizar algum parámetro na hora do Inploy se conetar ao servidor para o deploy, podemos especificalo nessa opção.

Segue um exemplo de como utilizar as opções mencionadas:

if ENV['environment'].eql? 'staging'
  deploy.ssh_opts = '-A'
  deploy.server = :unicorn
  deploy.environment = :staging
else
  deploy.branch = :deploy
  deploy.sudo = true
end

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ 1 comentárioTags: deploy · Inploy · rails

Integrando o Signal com CCMenu

por Diego Carrion - dezembro 2nd, 2009 · Sem comentários

Após ter anunciado o Signal no meu blog em inglês, recebi um feedback muito bom do Raphael, perguntando se planejava adicionar um feed compatível com o CCMenu.

Achei muito interessante a funcionalidade e hoje, para poder integrar o Signal com o CCMenu (OS X) ou CCTray (Windows), basta apontar para a URL http://host/projects/status.xml e selecionar o projeto desejado.

Gravei um pequeno vídeo (01:13 minutos) onde demostro como configurar e como trabalha a ferramenta, espero que gostem:

Signal integration with CCMenu from Diego Carrion on Vimeo.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ Sem comentáriosTags: ccmenu · continuous integration · signal

Integração contínua simples de verdade com Signal

por Diego Carrion - outubro 29th, 2009 · 1 comentário

Signal é um servidor de integração continua criado em Rails que na minha opinião pega as melhores funcionalidades dos concorrentes e une elas numa aplicação bem simples de utilizar.

Quando comecei a trabalhar com Rails, o primeiro servidor de integração continua que experimentei foi o CruiseControl.rb. O CC.rb foi escrito sobre Rails e o que mais me incomoda nele é que para adicionar um projeto você tem que ir no servidor e executar:

./cruise add [project-name] -r [repository] -s [svn|git|hg|bzr]

Após ter executado o comando podemos abrir um arquivo .yml e configurar o destinatário dos emails que serão enviados pela aplicação quando o build quebrar. Na terra do scaffold, isso não faz nenhum sentido para mim. É bem mais simples ter uma pagina onde qualquer usuário consegue cadastrar um projeto sem maior dificuldade, que nem no Hudson, no Integrity e no Signal.

Outra coisa que me incomoda no CC.rb é que ele dispara um monte de processos cruise e de vez em quando eles travam. Por um tempo achei que o problema era somente comigo mas após conversar com algumas pessoas descobri que é um problema comum.

A terceira coisa da qual vou reclamar do CC.rb é que na pagina inicial ele mostra os últimos cinco builds de cada projeto. A meu parecer, os últimos dois builds já é informação de mais. Saber que os últimos builds quebraram ou não para mim não quer dizer nada, o único que me importa é saber se nesse momento o projeto esta em um estado bom ou não, que nem o Integrity faz.

O Integrity faz varias coisas de um jeito legal, mas o que eu não gosto é que para instalar ele você tem que baixar primeiro a gem e depois executar um comando. O pior de tudo é que dependendo do servidor que você quer utilizar, o comando recebe parâmetros diferentes. Antes de explicar porque esse método de instalação é um problema, vou declarar que outra coisa que não gosto do Integrity é que ele vem sem suporte a email por padrão. Além dessa falta de suporte ser chata, para adicionar ela você tem que baixar outra gem e modificar um arquivo. Parece ser simples mas comigo não funcionou. Aparentemente a versão da gem plugin não era compatível com a versão da gem aplicação. Agora, como você troca a versão da aplicação que foi instalada ao executar o comando de uma gem? Seria somente baixar a segunda versão da gem e apagar a primeira? Seria necessário executar novamente o comando? Não sei, pode ser que tenha feito besteira mas as coisas não funcionaram comigo e por isso acredito que essa forma de trabalhar com aplicações é um problema.

O Signal tenta se aproveitar do bom e velho Git. Para instalar o Signal basta executar:

git clone git://github.com/dcrec1/signal.git
cd signal
rake inploy:local:setup

Caso algum dia queiramos voltar uma versão é somente executar git reset –hard ; simples, além de poder tirar proveito do histórico e saber o que estamos desfazendo e onde estamos.

Uma característica que o CC.rb tinha e que acho falta no Integrity é mostrar a data do build na página principal. O Signal mostra faz quanto tempo foi realizado o ultimo build, de modo que podamos saber quando foi o ultimo build e se eles estão sendo criados.

O report_card é um projeto que integra metric_fu com o Integrity, mas para isso é necessário rodar outra aplicação e rodar uns comandos, o que é muito complicado para mim. É por tal motivo que decidi que o Signal teria integração nativa com o metric_fu, o RSpec e o Cucumber.

A integração do Signal com o RSpec, Cucumber é metric_fu é bem simples. Em cada tela de build do Signal aparecem trés links: specs, features, e metrics, que apontam para ROOT/docs/specs.html, ROOT/docs/features.html e ROOT/tmp/metric_fu/output/index.html, padrão do metric_fu. Isso quer dizer que caso estejamos gerando outputs html das especificações, elas poderão ser acessadas a partir da página do build.

Outra integração que o Signal tem é com o Inploy. Caso desejemos realizar um deploy da aplicação, podemos ir na página dele e clicar no link deploy, a tarefa rake inploy:remote:update sera executada.

O Hudson é um servidor de integração legal, mas eu acho que o Signal supera ele em ser um pouco mais simples e se aproveitar de algumas convenções, além de ser desenvolvido em Rails e estar no Github.

Ser desenvolvido em Rails é uma vantagem porque este tipo de projetos acostumam ter vários plugins e plugins e Rails tem tudo a ver. Rails tem suporte nativo a plugins e quase tudo mundo que trabalha com Rails sabe como se instalam e como funcionam, pelo que facilita a criação deles.

Estar no Github é uma vantagem porque facilita ainda mais a colaboração com o projeto. Hoje o Signal tem muita coisa fixa que pode ser utilizada como convenção, mas caso alguém precise de alguma configuração especial, é somente dar um fork no projeto e começar a contribuir. Dado que o Signal foi desenvolvido com Rails e que ele é bem simples, as pessoas não vão ter muitas dificuldades para entender como ele funciona.

Uma das convenções do Signal é que em cada build ele executa a tarefa rake build, que eu acostumo ter mais ou menos assim dependendo do projeto:

task :build => [:'db:migrate', :spec, :cucumber, :'metrics:all']

Gravei um pequeno vídeo de quase trés minutos demonstrando como é fácil instalar e utilizar o Signal. Nele baixo a aplicação e instalo ela utilizando o Inploy. Seguidamente cadastro um novo projeto e mando criar um build dele. O build não é criado automaticamente junto com o projeto porque as vesses precisamos executar algumas ações antes de rodar ele. Somente por fins de demostração, escolhi um projeto em Ruby com um build muito rápido, ele não roda as features do Cucumber nem as métricas. Após o primeiro build, executo um start no delayed_job e criou um build a partir da linha de comando, como se estivesse num hook no Git. O vídeo termina com eu mostrando um build do projeto Signal e como é fácil visualizar os specs, estorias e métricas a partir dele.

Really easy continuous integration with Signal from Diego Carrion on Vimeo.

Considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ 1 comentárioTags: continuous integration · rails · signal

Deploys mais poderosos, simples e rápidos na Locaweb com Inploy

por Diego Carrion - outubro 17th, 2009 · 7 comentários

Tenho um servidor compartilhado na Locaweb onde de vez em quando subo aplicações para serem visualizadas por clientes. Ate o dia de ontem a melhor opção para realizar deploys nos servidores da Locaweb era utilizar a gem Locarails, do Akita, mas a partir de hoje o Inploy conta com um template chamado Locaweb, pelo que dependendo do caso, pode ser uma melhor opção que a anterior.

Umas das coisas que de cara ja não gosto no Locarails é que utiliza o Capistrano por debaixo dos panos. Eu ja expliquei por que não gosto muito do Capistrano mas em poucas palavras nesse caso isso se resume a ter um monte de pastas releases que não me servem para nada, ter tarefas como cap deploy e cap deploy:migration que não fazem muito sentido e para finalizar, ter um monstro chamado de receita.

Para entender melhor meu ultimo argumento podem visualizar esse gist, onde se encontra o arquivo deploy.rb configurado para trabalhar com Inploy e configurado para trabalhar com Locarails. Como podem ver, com o Inploy o arquivo de configuração fica bem mais simples e ainda faz mas coisas, aquelas que o Inploy faz por padrão, como por exemplo fazer um parse dos arquivos .less caso o plugin more exista. Essa funcionalidade foi adicionada também hoje.

Outra coisa que não gosto do Locarails é que por padrão ele funciona como modo “copy”, então fica copiando tudo o repositorio em cada deploy e ainda copia coisas que não deveria, como por exemplo arquivos de upload ou outros que se encontram no .gitconfig e não estão na lista de exclusão. Essa lista de exclusão pode ser configurada mas configurar é muito chato. Como resultado disso os deploy são mais demorados.

Como solução a isso, os colaboradores do Locarails parece que recentemente contornaram esse problema adicionando um modo “git”. Na minha máquina no chegou a funcionar mas foi excelente porque vendo o código percebi que tem um jeito muito possivelmente melhor de levar o repositorio para o servidor que o jeito atual utilizado pelo Inploy. A grão vantagem de utilizar Git no deploy é que em cada um somente vão as mudanzas, pelo que os deploys resultam ser bem mais rápidos.

Como puderam ver no arquivo de configuração, para utilizar Inploy na Locaweb basta declarar no arquivo de configuração (config/deploy.rb) que queremos utilizar o template :locaweb, o usuario e o host:

deploy.template = :locaweb
deploy.application = "hebraika"
deploy.user = 'dcrec1'
deploy.hosts = ['host.us']

Caso queiramos mandar a aplicação para uma pasta diferente de /home/:user/rails_app/:application, podemos configurar ela com deploy.path.

Gravei um pequeno video onde mostro muito rapidamente como utilizar o Inploy para realizar um deploy na Locaweb. Acho que o video esta bem claro mas se existir alguma duvida, não duvidar em questionar:

Deploy easily to Locaweb with Inploy from Diego Carrion on Vimeo.

Finalmente, queria deixar claro que eu acho o Locarails uma excelente solução para quem quer trabalhar com Capistrano, devido a que tira a responsabilidade de ter que configurar muita coisa. As coisas pelas quais eu não gosto do Locarais não são culpa dos colaboradores é sim do Capistrano, que era sem duvida a melhor opção na epoca em qual foi criado o plugin.

Se você gostou do plugin ou ele foi de alguma utilidade para você, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ 7 comentáriosTags: Inploy · plugin · rails

Deploy mais simples de aplicações Rails com Inploy

por Diego Carrion - outubro 9th, 2009 · 8 comentários

Após ter trabalhado em diversos sistemas feitos em Rails, trabalhar com Capistrano era uma das coisas que começou a me incomodar cada vez mais. Tentei achar outras alternativas, cheguei a dar uma olhada no Vlad, mas também não me agradou, pelo que decidi criar uma ferramenta e chamei ela de Inploy.

Antes de que os fans do Capistrano comecem a me crucificar, queria deixar claro que eu não acho o Capistrano ruim como ferramenta, somente acho ele ruim para minhas necessidades, que são bem mais simples das que o Capistrano consegue atender.

Uma da coisas que me incomoda no Capistrano é esse monte de pastas que ele cria, uma para cada release. Já argumentaram comigo que são uteis quando você quer voltar para um release velho. O problema é que eu nunca precisei voltar para um release x e a maioria de pessoas com as que falei também nunca precisaram, e talvez nunca precisarão.

Como podem ter percebido, eu falei “a maioria”. Algumas pessoas (muito poucas) me falaram que já tiveram que voltar para um release velho, mas foi porque subiram código que quebrou algumas funcionalidades e tiveram que dar rollback enquanto corregiam o erro.

De qualquer jeito, o Inploy utiliza Git, pelo que se precisamos voltar a uma versão x, é só dar um reset. Claro que a solução é mais limitada que a do Capistrano, mas é uma solução a um problema que possivelmente nunca deveríamos ter, um problema que possivelmente esta mais embaixo, no desenvolvimento.

Pelas estrategias de deploy que o Capistrano tem, os deploy resultam ser um pouco lentos para meu gosto. Eu sei que da para configurar o Capistrano de um jeito e acelerar o processo, mas configurar é uma das coisas que eu não quero fazer. Quero que a ferramenta que utilize trabalhe do melhor jeito possível por padrão. Em todos os casos nos quais trabalhei, o melhor jeito para um deploy mais rápido era o mais simples: git clone no setup e git pull no update, o mesmo que o Inploy faz.

Falando em padrões, com o Capistrano eu achava muito chato por exemplo ter que definir em cada projeto que para dar restart no Passenger o script devia dar um touch no arquivo tmp/restart.txt, ou que em cada deploy ele devia apagar a pasta public/cache e executar a tarefa asset:packager:build_all.

O Inploy tenta resolver esses problemas executando as tarefas comuns por padrão. Já me perguntaram: “E que acontece se eu não estiver utilizando o plugin asset_packager? A tarefa de empacotamento vai dar erro”. A resposta a isso é que a intenção do Inploy é ser um pouco inteligente, executando algumas tarefas somente se elas existem. Hoje ele empacota os assets unicamente se o plugin existir. Uma idéia é que também expire o cache do Memcached ou faça um parse dos arquivos .less, unicamente se eles estiverem sendo utilizados, e coisas assim. Vamos ver ate onde essa inteligencia pode chegar sem afetar outras coisas, mas basicamente a filosofia é que você não tenha que se preocupar com essa aquela tecnologia que você esta utilizando na hora de um deploy, que as coisas simplesmente funcionem sem que podamos errar.

Outra vantagem que eu vejo no Inploy sobre o Capistrano para a maioria dos casos é que somente tem um jeito de fazer deploy, que no Inploy é chamado de update. A tarefa consiste em baixar o código, fazer o que tem que fazer e executar as migrações. Não tem sentido para mim fazer um deploy e não executar as migrações pendentes. Nas equipes com as quais trabalhei, todo mundo conseguia fazer deploy e muitas vesses as pessoas executaram cap deploy quando era para executar cap deploy:migrations. Já me disseram que isso se resolve executando cap deploy:migrations sempre, mas nesse caso a brecha para errar continua existindo, eu prefiro que não exista.

Uma das necessidades que eu tinha com uma ferramenta de deploy é que ela pudesse trabalhar tanto remotamente como localmente. Trabalhei num sistema onde entregamos uma aplicação Rails para um cliente de outro país e as pessoas nesse cliente encarregadas de realizar o deploy não conseguiam faze-lo de outro modo que não seja entrando no servidor e executando alguma coisa. Todos eles utilizavam Windows e estavam acostumados a trabalhar com aplicações Java, onde tinham que entrar no servidor e substituir um arquivo .war e executar uns comandos. A solução nesse caso foi criar um arquivo na pasta raiz do projeto que ao ser executado realizava os passos necessários, aquelas pessoas eram muito limitadas e quando menos pudessem mexer ia ser melhor.

Com o Inploy o problema mencionado anteriormente não existe, devido a que ele pode ser rodado remotamente ou localmente. Ao ser rodado remotamente o único que ele faz é se conetar aos servidores e rodar as tasks como se estive alguem logado. É por tal motivo que atualmente o Inploy é um plugin, de modo que ele se encontre disponível em todos os ambientes.

Hoje, o Inploy somente vai servir para você se você estiver trabalhando com Passenger e com Git. Para poder utilizar ele basta instala-lo na tua aplicação Rails como um plugin. Uma alternativa é faze-lo executando:

script/plugin install git://github.com/dcrec1/inploy.git

O comando acima colocara um arquivo que devemos configurar chamado deploy.rb na pasta config. Esse arquivo é lido pelo plugin e deve estar algo assim:

deploy.application = "inploy"
deploy.repository = 'git://github.com/dcrec1/inploy.git'
deploy.user = 'dcrec1'
deploy.hosts = ['hooters', 'geni']
deploy.path = '/var/local/apps'

Após isso já podemos executar as quatro tarefas rake que o plugin tem:

rake inploy:local:setup
rake inploy:local:update
rake inploy:remote:setup
rake inploy:remote:update

Criei um pequeno vídeo demonstrando como utilizar as diferentes tasks do plugin. No vídeo estou dentro do projeto Signal, que já tem o Inploy incluso e removo ele junto com o arquivo de configuração para demostrar como é fácil instalar e configurar ele. Após isso executo um setup remoto e depois um update remoto. Podemos ver no vídeo que os comandos que o Inploy executa são logados, junto com os outputs correspondentes e que no setup os arquivos config/*.sample são renomeados para config/*. Na segunda parte do vídeo é executado um update local e depois é apagado o repositório, clonado novamente e executado um setup local, outra alternativa do plugin.

Rails deployment made easy with Inploy from Diego Carrion on Vimeo.

Para mais detalhes sobre o plugin podem acessar o repositorio, onde vou tentar manter tudo atualizado no README. Espero que tenha sido claro respeito a como trabalha o Inploy, mas outra opção é dar uma revisada um código, que é bem pequeno (+/- 50 linas de código) e que acredito esta bem claro. Segue um pequeno trecho:

def local_setup
  copy_sample_files
  install_gems
  run "mkdir -p tmp/pids"
  run "./init.sh" if File.exists?("init.sh")
  migrate_database
end

def local_update
  run "git pull origin master"
  install_gems
  migrate_database
  run "rm -R -f public/cache"
  rake_if_included "asset:packager:build_all"
  run "touch tmp/restart.txt"
end

Espero que esse código simples motive as pessoas a colaborar com o projeto e deixar ele cada vez mais espertinho. Qualquer duvida estou sempre a disposição.

E como sempre, considera me apoiar me recomendando no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

→ 8 comentáriosTags: Capistrano · deploy · Inploy · rails

Importa contatos do Google, Yahoo, Live e CSV na tua aplicação Rails com uma linha

por Diego Carrion - outubro 6th, 2009 · 4 comentários

Trabalhando em diversas aplicações me vi na necessidade de integra-las com diretórios de serviços como Google, Yahoo ou Live, de modo que os usuários podam importar seus contatos e realizar com eles diferentes ações.

Existe uma gem chamada contacts que encapsula a comunicação com esses serviços, porém mesmo utilizando ela, muito código ficou repetido entre minhas aplicações, pelo que decidi encapsular mais um pouco e criar o contacts_rails.

Com o Contacts::Rails o único que devemos fazer é criar as rotas para algum controller:

map.import_google '/home/import/google',   :controller => "home", :action => 'import_google_contacts'
map.import_live   '/home/import/live',     :controller => "home", :action => 'import_live_contacts'
map.import_yahoo  '/home/import/yahoo',    :controller => "home", :action => 'import_yahoo_contacts'
map.import_csv    '/home/import/csv',      :controller => "home", :action => 'import_csv_contacts'

e depois incluir Contacts::Imports no mesmo:

class HomeController < ApplicationController do
  include Contacts::Imports
end

Quando um usuário acessar as diferentes rotas, ele sera redirecionado para o serviço correspondente, onde terá que se logar. Finalmente ele sera enviado para a view import com a variável @contacts contendo uma lista de contatos, onde cada contato é um array de dois items: nome e email.

Como podem ver nas rotas, também podemos importar contatos a partir de um arquivo CSV. Para isso devemos enviar no parâmetro csv_file um arquivo com a seguinte estrutura:

email, name
bob@marley.com , Bob Marley
che@guevara.com, Che Guevara
john@lennon.com ,John Lennon

A primeira linha existe porque podemos inverter a ordem das colunas, pelo que ela ajuda a identificar à que corresponde cada uma.

Atenção

Os serviços do Yahoo e do Live são bem mais burocráticos que o do Google, pelo que para utilizar eles precisaram configurar o arquivo config/contacts.yml após ter cadastrado suas aplicações:

http://developer.yahoo.com/addressbook/
http://msdn.microsoft.com/en-us/library/cc287659.aspx

Queria agradecer ao Hugo Baraúna da Plataforma, que me ajudou com a gem explicando a implementação que ele fez no seu fork do projeto contacts.

→ 4 comentáriosTags: plugin · rails

Sai Sphinx, entra Solr: ActsAsSolrReloaded

por Diego Carrion - agosto 27th, 2009 · 13 comentários

Sempre utilizei o ThinkingSphinx ate que precisei indexar documentos com atributos dinâmicos. Dado que o Sphinx indexa os dados a partir do resultado de uma query SQL, o objetivo não parecia possível.

Foi assim que decidi dar novamente uma olhada no Solr. O Solr, a diferencia do Sphinx, é um servidor HTTP e recebe os dados a serem indexados via um documento XML. Cada documento que você envia pode ter uma estrutura diferente, pelo que se encaixa perfeitamente com o modelo de atributos dinâmicos.

O acts_as_solr é um plugin criado por Thiago Jackwin, vulgo RailsFreaks. O plugin é muito bom, mas o Thiago sumiu do mapa algum tempo atrás, perdeu o domínio, abandonou o Github e não responde emails. Como conseqüência disso, foram criados bastantes forks e forks de forks de forks do acts_as_solr, que não foram integrados no repositório oficial, e a arvore de alterações virou uma bagunça.

Incomodado com isso, criei um fork do fork que mais me agradava e realizei umas alterações que precisava, como um suporte simples a atributos dinâmicos, integração com o acts_as_taggable_on, busca por espaço e parametrização de relevâncias. Para poder trabalhar com busca por espaço, o Solr teve que ser atualizado para a versão 1.4 e tiveram que ser incluídos uns jars no servidor que vem junto com o plugin.

Decidi criar então um novo repositório, o acts_as_solr_reloaded, de modo que o fork fique mais fácil de ser encontrado e de mais confiabilidade. Além disso, eu vou me comprometer a manter ele sempre atualizado e a integrar as alterações que o pessoal possa realizar.

Para promover o plugin e mostrar o que tem de novo, decidi criar um screencast. Queria agradecer ao Ricardo Almeida por me emprestar a maquina dele para gravar o video e por ter editado e narrado dele, de modo que ninguém fique prejudicado com meu sotaque :P. Se ele falar alguma besteira, por favor cobrem de mim :)

Nota:O screencast ira ser gravado novamente porque as fontes ficaram pequenas, mas como andei prometendo o vídeo no Twitter, vou deixar esse aqui por enquanto, se colocarem ele em full screen da para ver melhor.

Se gostou do plugin ou do screencast, considera me ajudar me recomendando no Working With Rails e para mais novidades não deixe de me seguir no Twitter. Se quiser recomendar o Ricardo, pode faze lo aqui.

ActsAsSolrReloaded Demo from Diego Carrion on Vimeo.

→ 13 comentáriosTags: ActsAsSolr · ActsAsSolrReloaded · rails · Solr

Remarkable Extensions: mais matchers para teus testes!

por Diego Carrion - agosto 8th, 2009 · 2 comentários

O Remarkable Extensions é um plugin para o Remarkable com matchers que não foram inclusos no repositório oficial.

O motivo para os matchers não serem inclusos no repositório oficial é que dependendo do caso, podem não ser considerados BDD.

Eu acredito que não importa saber se teus testes são BDD, TDD ou o que for e sim entregar para o cliente uma especificação executável do que ele esta comprando, entre outras coisas.

No meu caso, estávamos trabalhando numa aplicação com serviços que eram consumidos por uma segunda aplicação e o business owner pediu para que tal recurso não tenha a ação de delete, pelo que foi criado o matcher have_action:

should_not_have_action :delete

Em outra oportunidade, o business owner me indicou que outro recurso somente podia ser editado e deletado pelo owner dele, pelo que chegamos na conclusão que devíamos filtrar os usuários que não tinham criado o mesmo e foi criado o matcher have_before_filter:

should_have_before_filter :require_owner, :only => [:edit, :destroy]

que na especificação ficou como:

should require owner before edit, destroy

e que o cliente entendeu perfeitamente.

Um terceiro matcher no plugin é have_after_filter.

Queria agradecer ao Jose Valim da Plataforma que me ajudou com uns códigos.

Se gostou do plugin, considera me recomendar no Working With Rails e para mais novidades não deixe de me seguir no Twitter.

→ 2 comentáriosTags: Remarkable · Remarkable Extensions · Remarkable Plugins · rspec · rspec-rails