Nodejs vs Rails, ou a ironia de quando apertam no meu calo.

{ November 27th, 2011 }

Autor: cmilfont

Por volta de 2007/2008 quando o Rails se popularizou no mundo inteiro, um tema comum em todas as listas de discussões era como o Rails ia matar o Java. Ficavam furiosos os mais exaltados, porém míopes, javeiros.

Claro que era uma brincadeira com um fundo de verdade, um alerta para sermos poliglotas e usarmos o melhor ambiente/plataforma/ferramenta/etc para resoluções de problemas.

Claro que a comparação era esdrúxula porque comparavam um Framework com uma linguagem, aliás, não só linguagem, mas uma plataforma. Não importa se o Rails poderia ser executado na plataforma Java, a mensagem era o alerta de que não adianta fazer tudo com apenas uma ferramenta. Naquele momento se voce era programador DotNet, voce tentaria fazer tudo com DotNet, se voce fosse programador Java, o mesmo com sua linguagem/plataforma.

Na época Java era Mainstream, Rails um Framework que trazia consigo uma linguagem “Underground” com uma comunidade ainda muito pequena, porém vibrante.

A História se repete

Hoje em dia Rails é um Framework muito popular que criou um ecossistema em sua volta, graças a ele que a linguagem Ruby tem uma certa penetração até em grandes corporações. Ouso dizer que Rails é uma “plataforma” e que tudo gira em torno dele, retire esse Framework e a linguagem Ruby dificilmente se mantém no Mainstream.

Em 2009 surgiu uma ferramenta chamada Nodejs. Um “Evented I/O for V8 JavaScript“, ou seja, uma ferramenta para fazer IO não-bloqueante usando a VM do Chrome. Em pouco tempo a comunidade em volta do Nodejs repetiu o mesmo processo que o Rails levou de 2004 a 2010 só que em menos tempo. Esse ano (2011), as duas comunidades chamam a mesma atenção do mercado, principalmente as Startups do Vale do Silício.

Nodejs criou uma comunidade em sua volta, apesar de ter um propósito bem definido. Não existe um Framework no ecossistema Nodejs que sequer chegue aos pés do Rails, o máximo é algo similar o Sinatra chamado de Express. Mas somente a possibilidade de uma comunidade/ecossistema desviar a atenção e rivalizar no efeito “Sou foda, estou na crista da onda” já deixa incomodado muitos Railers.

Pois bem, eu dizia há alguns dias para amigos e clientes que a comunidade Rails iria subir nas tamancas quando o Nodejs crescesse mais do que já cresceu. O motivo que alerto é que a comunidade se tornou tão pedante quão a comunidade Java de 2007/2008. Hoje em dia temos “Railstards” que pregam o desenvolvimento somente com Ruby ao ponto de escreverem Javascript em Ruby por conveniência de não sair da sua zona de conforto.

Há alguns dias a Nodejitsu publicou uma página para acompanhar o momento onde o número de Watchers (observadores) do projeto nodejs no github ultrapassou o mesmo número no projeto Rails.

A Notícia por si só não deveria ter nenhum significado. Comparar um Framework popular com uma Ferramenta de Evented IO?

Ops, há alguns anos comparamos uma linguagem/plataforma com um Framework, ninguém disse na época que era descabido a comparação, porque seria hoje comparar Nodejs vs Rails?

Não rir dessa piada irônica só demonstra que você deveria subir um alerta, a grande maioria dos Javeiros já calçou a sandália da humildade, acho que ta na hora de nós Railers também

Como disse o @leonardoeloy: Se Java é o novo Cobol, Rails o novo Java, Nodejs o novo Rails, quem é o novo Nodejs?

Posted in Java, Rails, Ruby ~ 16 Comments

Terceiro Encontro GURU-CE

{ December 18th, 2010 }

Autor: cmilfont

Galera da guru_ce está mandando muito bem, dê uma sacada como foi o encontro:

Fiz código na hora e como sempre não deu tempo de mostrar tudo que eu gostaria, estourei o tempo e saímos de lá por volta de 12:30. Espero ter gerado curiosidade na dobradinha sencha e rails, vamos ver se a galera manda dúvidas para a lista.

Posted in Ext, Frameworks, Rails, REST, Ruby, sencha, Web Development ~ 1 Comment

Setup do Sunspot-rails no Rspec

{ June 23rd, 2010 }

Autor: cmilfont

Tínhamos um problema nos testes unitários por débito técnico [na verdade desleixo mesmo] com o setup do Rspec e Sunspot-rails em determinado projeto. O problema era que mesmo para executar um simples teste unitário, levantávamos o Sunspot no spec_helper.rb.

Resolvi refatorar isso, acabei descobrindo no before/after do Spec::Runner.configure algo que eu não usava e que já existia desde o rspec “1.1.12 / 2009-01-11″, pelo que percebi no changelog.

O que fiz e parece bobo é separar pelo tipo (type) integration a subida de uma instancia real do Sunspot e agora dá para usar a estrutura de Rspec que o Sunspot disponibiliza para meus testes unitários.

#arquivo spec_helper.rb

ENV["RAILS_ENV"] ||= 'test'

require File.expand_path(File.join(File.dirname(__FILE__),'..','config','environment'))

require 'spec/autorun'
require 'spec/rails'
require 'rake'
require 'ruby-debug' unless RUBY_VERSION > '1.9'
require 'sunspot/rails/tasks'
require 'authlogic/test_case'
require 'sunspot/rails/spec_helper'

require 'database_cleaner'

#observe aqui que eu criei uma pasta support porque guardo algumas confs em arquivos contidos nela
Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

Spec::Runner.configure do |config|
  config.use_transactional_fixtures = true
  config.use_instantiated_fixtures  = false
  config.fixture_path = RAILS_ROOT + '/spec/fixtures/'

  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end

  [:model, :helper, :controller].each {|type|
    config.before(:each, :type => type) do
      ::Sunspot.session = ::Sunspot::Rails::StubSessionProxy.new(::Sunspot.session)
    end
    config.after(:each, :type => type) do
      ::Sunspot.session = ::Sunspot.session.original_session
    end
  }

  config.before(:all, :type => :integration) do
    JojobaSunspot.new.start
  end
  config.after(:suite) do
    JojobaSunspot.new.stop
  end

end

Inspirado nesse post, eu adaptei para o código que uso ao subir o sunspot com linha de comando para os testes de integração. Observe no código anterior que importo configurações da pasta support, inclusive a classe JojobaSunspot, usada no after e before de integration.

require "net/http"

class JojobaSunspot

  def start
    @started = Time.now
    up_sunspot if starting
    up
  end

  def stop
    system("sunspot-solr stop --pid-dir=/tmp/pids") unless starting
  end

  private
  def port
    Sunspot::Rails::Server.new.port
  end

  def up_sunspot
    system("sunspot-solr start -p 8981 -d /tmp/solr_data_test --pid-dir=/tmp/pids --log-file=/tmp/solr_log_test.log --log-level=INFO")
  end

  def up
    while starting
      puts "Sunspot server is starting..."
    end
    puts "Sunspot server took #{'%.2f' % (Time.now - @started)} sec. to get up and running. Let's Jojoba!"
  end

  def starting
    begin
      sleep(1)
      request = Net::HTTP.get_response(URI.parse("http://localhost:#{port}/solr/"))
      false
    rescue Errno::ECONNREFUSED
      true
    end
  end

end

Desde que colocamos testes de integração o tempo de execução da bateria subiu muito, provocamos um setup ineficiente e desnecessário para os testes unitários. Fica a dica para quem passar pelo mesmo problema.

Posted in Rails, Rspec, Ruby, Sunspot ~ 1 Comment