Peepcode sponsors akitaonrails.com Locaweb sponsors akitaonrails.com

A derrota dos Reclamões

AkitaOnRails / 14.May.2008 at 02:32pm

O Charles postou um ‘call to action’ hoje no seu blog avisando que os famosos RubySpecs do Rubinius finalmente se tornou um projeto independente. A idéia desse call to action é integrar os diversos suites de testes que existem para Ruby em um único maior e mais completo. O JRuby hoje executa meia dúzia de pacotes separados e com muitos testes redundantes entre eles.

Um RubySpecs completo primeiro auxiliaria todas as outras implementações como IronRuby, Rubinius e o próprio MRI e cala a boca de todos que ficaram dizendo “Ruby não tem especificação”. E por falar em Rubinius, outro cala boca a quem não acreditava nele: no estágio atual ele já começa a rodar Merb. Claro, ainda é insipiente, mas é um sinal que as coisas estão evoluindo bem.

Outro ‘cala boca’ veio na forma do suporte a mod_rails pela Dreamhost. Vocês vão se lembrar que alguns meses atrás eles pisaram na bola ao simplesmente falar mal de Rails e cruzar os braços (sendo que são eles que lucram com hosting de Rails). Pois bem, como eu venho dizendo, o pessoal da Phusion mandou ver numa solução decente a agora a Dreamhost não tem do que reclamar. Os reclamões deveriam se sentir envergonhados de ver um grupo de garotos (o pessoal da Phusion está na média dos 23 anos) resolver esse tipo de problema que muitos achavam que era o “calcanhar de aquiles” do Rails. O Zed Shaw deu uma resposta à altura com Mongrel e agora a Phusion dá uma segunda resposta à altura com Passenger.

“Ruby é lento, JRuby é lento” bla bla bla. Quantas vezes já não ouvimos isso? Hoje na lista rails-br o Antonio Carlos, da Object Training, postou sua experiência sobre seus sistemas rodando no MRI e agora em JRuby. Inclusive, serve de cala-boca para mim mesmo: eles tem um ERP com boa parte feita em Rails :-) Aliás, é um bom texto para mostrar as diferenças de se fazer aplicações em PHP e Rails vindo da parte de quem tem real experiência com ambos.

Um ano atrás as coisas eram bem diferentes, dois anos atrás eram mais insipientes ainda. Em menos de 3 anos a comunidade Ruby deu um enorme salto à frente e é por isso que eu sempre digo: a melhor parte do Ruby é a comunidade que a cerca, um exército de pessoas pró-ativas e efetivamente geniais em programação. Todo ano eu penso: “será que tem tanta novidade para ter 2 RailsConf todos os anos?” E a resposta é sim! Mesmo quando eu e o Carlos Brando começamos a gravar nosso podcast semanal ficávamos pensando “será que vai ter assunto suficiente pra falar toda semana?” e, pelo tamanho de cada podcast, dá para ver que a densidade de novidades toda semana é enorme!

E, também como eu sempre digo, os que apenas reclamam e cruzam os braços nunca vão sair do lugar. Por isso mesmo o que temos hoje representa uma derrota dos Reclamões. Não dêem ouvidos a quem só sabe dizer “Não”. É como no mundo de consultoria nós definimos como “crocodilos”: boca grande e braços curtos.

Steve Jobs já usou essa famosa frase de Alan Kay: “A melhor forma de prever o futuro, é criar o futuro.”

8 Comments

“The best way to predict the future is to invent it”. Hahahaha, essa era minha assinatura no gmail, até que eu mudei pra uma de Warren Buffett, tem uns três meses. É uma ótima frase, quando foi que Steve Jobs usou?

Boa Akita, mandou bem. Realmente a comunidade Ruby é muito ativa, tanto que é muito difícil acompanhar tudo que acontece, tento me manter atualizado, mais a galera produz muito e muito rápido. []’s

Parabens akita, a algun tempo eu deu uma alfinetada na rails-br no tópico do twitter e escalabilidade e eu falava exatamente disso, eu dizia que para mim até agora (ainda sou novato, não tem nem um ano que trabalho com rails) o rails estava perfeito e se alguem está tendo problema com escalabilidade que va a luta e crie uma solução, então eu disse que quem chama o rails de tecnologia imatura e etc só pode estár querendo criar um flame ao invés de ter uma vista tecnica sendo que a comunidade em 3 anos deve ter evoluido igual a uns 10 em outras tecnologias…

Parabens de novo, e falando em Call to action, quando vamos ter um outro para traduzir algum livro de Rails ou Ruby ???

“É como no mundo de consultoria nós definimos como “crocodilos”: boca grande e braços curtos.”

Eu os conhecia como “Horácios” em referência ao personagem homônimo do Maurício de Souza.

Eu hoje mesmo tinha falado de que Java ou .NET são conhecidos por ser “mais enterprise” pq tem especificações ( e amarras… ), agora com uma especificação de Ruby será realmente um “cala tua boca” para algumas pessoas que insistem em discutir o que é ou o que não é enterprise… O mod_phusion é outra vitória do mundo ruby! Realmente acho que ruby só tende a crescer, rails, merb e outros só tendem a crescer com ele, e estou muito feliz trabalhando com ferramentas escritas em ruby diariamente.

O Que mais me fascina no ruby é a comunidade!

cada dia mais e mais coisas novas e ótimas aparecem…

Parabéns akita pelas noticias quentinhas :-)

Abraços

Venho acompanhando a página das doações ao projeto Passenger há algum tempo. O mais interessante é a DreamHost não ter doado nada até o presente momento. Interessante…

Caro Akita,

sobre o artigo, Performance, escalabilidade, ruby-vms e nossa experiência, do Antonio Carlos termina com a conclusão que o PHP com Zend Framework é mais lento, ele diz

“Os sites de nossos clientes que eram integrados com nosso ERP, ficaram 10 vezes mais rápido com Rails do que com PHP (utilizando Zend Framework). Isto se dá porque nosso projeto é MUITO grande. E o PHP apresentava problema pois a quantidade de “require” feita em cascata (um arquivo chamando outro arquivo) era tão grande que uma requisição básica se utilizava de 237 arquivos PHP

Bem, como desenvolvedor PHP posso afirmar que isso é um problema de Patterns, já que o projeto dele, provavelmente não utilizava o Autoloading Objects (http://www.php.net/manual/pt_BR/language.oop5.autoload.php) que permite que não seja mais necessarios utilizar os require em cada definição de classe.

Isso permite que por exemplo uma classa chamada A que tem 2 metodos, a1 e a2 e usa a Classe B no metodo a1. Se eu apenas usar o metodo a2, apenas a classe A sera definida no script e pronto. Quando eu usar o metodo a1 e a classe B ainda não estiver definida, o script invocara o autoload para carregar a definição da classe B. Assim quando o requisição apenas precisar executar pequenas tarefas, o script tera caregado as classes que usou, nada mais, nada menos.

Abraços

Leave a Comment