Eu já comentei aqui no blog sobre o novo sistema de templates do Rails 2.3. Com este novo recurso podemos criar um modelo para novos projetos, automaticamente instalando gems e plugins, criando e modificando arquivos, incluindo novas rotas, etc.. Mas o que dizer de projetos já existentes? Uma nova tarefa rake foi criada para aplicar um template [...]
Existe uma escória na Internet e ela se chama Internet Explorer 6. Ela foi lançada em Agosto de 2001 e representa o aborto gerado pelo fim da Guerra dos Browsers, quando a Microsoft destruiu sem misericórdia a Netscape. A geração do IE 6 representa a Idade Média dos browsers.
Felizmente hoje estamos no início da Renascença dos browsers, com Firefox dominando entre os alternativos, mas com um ecossistema saudável de opções como Safari, Opera, Google Chrome.
Mesmo assim, o fantasma do IE 6 continua a nos assombrar. E o pior: ela se tornou tabu em muitas discussões. Todos sabemos que ela é tão nociva quanto a peste, mas também todos “sabemos” que devemos pagar nosso dízimo a ela, sem mais questões.
I’ve been thinking this through for a while about what are the best tools to develop Ruby and Rails project outside of the Mac. Specially on Windows. Netbeans and Eclipse Aptana are good choices and they are evolving fast, but I always thought of Java based IDE to be heavier than necessary.
I always say that you only need a good text editor and the terminal. But on Windows there is not that many competent editors such as Textmate. Even on the Mac, there are those who don’t want to pay for Textmate.
Railers have recently started to talk about Emacs, including Geoffrey who just released a great Peepcode screencast about it. Personally, I don’t feel like getting used to Emacs. It is just a personal taste thing, but I always preferred Vim.
Faz tempo que venho quebrando a cabeça sobre qual a melhor maneira de se programar com Ruby e Rails fora do ambiente Mac. Principalmente no Windows. O Netbeans e o Eclipse Aptana são boas opções e estão evoluindo rápido, mas eu sempre vou achá-los muito mais pesados do que necessário.
Sempre digo que basta um bom editor de textos e o terminal/linha de comando. Porém, no Windows não há tantos editores competentes como o Textmate. E mesmo no Mac, há quem não queira pagar pelo Textmate também.
Recentemente alguns Railers começaram a se voltar ao Emacs, incluindo Geoffrey, que fez um screencast sobre isso para o Peepcode. Sinceramente, eu ainda não consigo gostar muito do Emacs. É absolutamente questão de gosto pessoal, mas eu sempre preferi o Vim.
Se você é ainda um dos poucos a usar os scripts inspector, reaper e spawner do Rails, é bom saber que estes scripts não existirão mais à partir do Rails 2.3. Eu mesmo só me lembro de usá-los uma vez em um arquivo ./script/spin que criei para subir múltiplas instâncias do Mongrel. Como hoje a alternativa mais [...]
Pelo visto, a tradição manda que o último artigo do ano seja uma retrospectiva :-) Portanto, vamos às honras. Este foi um longo ano, definitivamente um dos melhores – e mais atarefados – que eu já passei. No meu blog, apesar disso, foram exatos 247 posts somente no meu blog. Foram 16 palestras (incluindo públicas e particulares) durante o ano todo.
Vamos aos meus posts favoritos do ano, foram vários.
Você tem uma conta Linux em alguma hospedagem compartilhada. Porém, por mais que nos esforcemos, é difícil manter tudo sempre atualizado, ainda mais no mundo Rails onde saem gems novas o tempo todo (por exemplo, o Merb 1.0.7 saiu dia 28 de dezembro e somente 3 dias depois o Yehuda já lançou o 1.0.7.1).
Mesmo assim muita gente quer usar a versão mais recente!
Outro problema: você fez sua aplicação Rails e não configurou corretamente as “config.gem” ou mesmo a variável RAILS_GEM_VERSION. Por alguma razão tem muita gente que comenta essa linha, o que está errado! Isso porque dessa forma sua aplicação sempre vai carregar o Rails mais novo instalado na máquina, se o servidor for atualizado, digamos de Rails 2.2 para Rails 2.3, sua aplicação tem a possibilidade de quebrar! Por alguma razão as pessoas acham que o correto é sempre carregar a versão mais recente. De novo: está errado. Claro subir da versão 1.0.0 para 1.0.1 não deveria ser um problema, mas carregar – sem saber – da versão 1.0 para 2.0, certamente alguma coisa vai quebrar e você só vai saber disso quando alguém entrar na sua aplicação e ela estourar um erro!
Mas existem várias soluções para isso. No Rails, você pode vendorizar todas as Gems dentro do diretório vendor/gems usando as tarefas de Rake que já vem com o Rails desde a versão 2.1 (melhoradas na 2.2).
Mais ainda, você pode ter seu próprio repositório de Gems (incluindo o comando “Gem” em si) totalmente local no seu diretório home da hospedagem. Por isso eu criei este artigo de Wiki ensinando como fazer isso em qualquer hospedagem Linux que possua acesso via SSH, tenha pelo menos um Ruby pré-instalado e acessível e compiladores (GCC) também acessíveis. Inclusive como instalar o Merb mais novo com todas as suas dependências.
Lembrem-se: as versões das suas Gems são importantes!! Se você controla tudo na sua máquina local e vai colocar num servidor dedicado, onde somente você usa, daí você pode instalar somente as versões que quiser. Mas se for colocar num servidor compartilhado, não há garantias, e é obrigação do desenvolvedor controlar isso.
Último dia do ano e o último artigo publicado este ano. Nada mais justo então do que uma retrospectiva de tudo o que rolou por aqui e comigo neste ano de 2008. Janeiro O ano começou muito bom com uma série de screencasts sobre os mais variados assuntos, desde Edge Rails até microformats. Também foi neste mês [...]
O método Rails.root foi alterado para não mais retornar um String com o caminho físico do seu projeto Rails, mas sim um objeto do tipo Pathname. É uma alteração simples, mas que agrega muito ao desenvolvimento. Por exemplo, veja o seguinte trecho de código: "#{Rails.root}/app/controllers" Ele pode ser facilmente substituído, pela nova implementação do método Rails.root, assim: Rails.root.join("app", "controllers") Todos [...]
O método assert_valid foi marcado como deprecated. Embora ele ainda continue existindo no Rails 2.3, não estará mais presente no Rails 3. Este método era útil para garantir que um registro era válido e que não possuía nenhuma mensagem de erro. A sugestão é que usemos o seguinte código em seu lugar: assert record.valid? # ou assert @model.valid?, @model.errors Todos [...]
Recentemente esbarrei no blog post do Paul Gross falando de Mephisto com Phusion Passenger, mais especificamente em como as versões mais recentes do Mephisto passam a gravar cache num diretório chamado “/public/cache/unusednow.com” em vez de gravar diretamente na raíz pública “/public”. Essa mudança aconteceu depois da 0.7.×. Acabei de atualizar meu blog a partir do repositório Git do Mephisto, que deve ser versão 0.8.x unstable.
Opa! Eu não tinha percebido isso. Eu atualizei meu Mephisto faz algum tempo e lembro que antigamente o cache ficava no /public. Isso significa uma coisa: que meu site está inteiro sendo servido dinamicamente o tempo todo! Péssimo para os recursos do servidor.
Existem duas maneiras de se corrigir isso. A primeira é exatamente como o Paul comenta no seu blog (leiam no link acima). Porém isso só é válido se você tem acesso a editar o arquivo de configuração do Apache. Num servidor compartilhado isso Não deve acontecer (e se acontece não é uma boa coisa para a estabilidade do servidor). Além disso, por alguma razão, não consegui fazer funcionar via .htaccess também. O Passenger, desabilita o mod_rewrite porque toda aplicação Rails antiga pré-cria um arquivo .htaccess padrão que mapeia tudo para CGI, o que é obviamente péssimo. Existe como religar isso no Passenger mas também significa que as aplicações que tem esse .htaccess vão começar a subir com CGI, o que não é bom.
Então, em vez de mexer no rewrite. Resolvi entender porque diabos o Mephisto transferiu tudo para esse diretório "/public/cache’. Ao que parece ele tem uma funcionalidade bastante experimental (leia-se: bugada e incompleta) para multi-sites, por isso essa diferença. Como eu não pretendo ter múltiplos sites na mesma aplicação, basta desligar a opção abaixo no arquivo “config/initializer/custom.rb”:
Site.multi_sites_enabled = false # originalmente estava true |
Feito isso, não esqueça de fazer “touch tmp/restart.txt” para forçar o reinício do Passenger e pronto! Em testes básicos usando o Firebug do Firefox, a chamada à minha homepage caiu de 5 seg. para 50ms (milissegundos!). Acho que é bem considerável.
E não se esqueça: sempre configure Page Caching nas suas páginas de maior acesso, principalmente na homepage. É razoávelmente simples, precisa entender como ele funciona, mas uma vez entendido e configurado, funciona perfeitamente e dará um aumento de ordens de grandeza em páginas altamente dinâmicas (minha homepage mesmo, tem dezenas de queries que não precisa executar o tempo todo).
Essas últimas semanas foram bastante atarefadas para mim. Mesmo quando estou em casa não estou parado. Estou com várias novas atribuições na Locaweb. O resultado disso é que minha taxa de blogging, podcasting e tudo mais andou caindo. Pelo que soube o Carlos Brando também andou mais carregado que o normal. Mas não se preocupem, em breve voltamos ao ritmo normal.
Mas para não acumular muita coisa, resolvi escrever um artigo com um resumo das últimas semanas, para acabar o ano sem pendências :-) Entao vamos lá.
Vocês devem ter acabado de ver o anúncio: Ruby on Rails e Merb vão se juntar num único projeto. Tanto Matt Aimonetti quanto Yehuda Katz passam a ser parte do Rails Core Team, e a Engine Yard deve colaborar também.
Sinceramente, era algo que eu não esperava tão cedo. Quer dizer, alguma coisa ia acontecer, mas não imaginei que fosse isso e nem que fosse tão cedo.
Quem está acompanhando deve ter visto a animosidade entre o Rails Core e a Engine Yard. Isso vem de longa data, desde quanto o Ezra começou o projeto Merb com o discurso de que “Rails não era bom o suficiente e por isso ele resolveu fazer um framework próprio”. Desde então a Engine Yard cresceu sendo um hosting especializado em Ruby on Rails, ou seja, o negócio lucrativo deles passou a ser Rails mas o discurso com o Merb não mudou.
Recentemente tivemos várias demonstrações hostis com a discussão das linhas de código que moveu Jeremy Kemper (bitsweat), Yehuda Katz e o próprio DHH. No caso foi a discussão sobre se Merb tinha menos linhas de código que o Rails ou não. Depois foi a discussão sobre modularidade, de que Rails era um monolito.
Além disso, no começo do projeto Rubinius, logo quando o Passenger estava sendo anunciado, o Ezra também anunciou o projeto mod_rubinius, que foi oficialmente morto recentemente e retirado do Github. Ambos os projetos não foram para frente. O Phusion Passenger foi lançado e cumpriu a promessa de resolver o problema de deployment do Rails. Mesmo assim o discurso da EY sempre foi que Passenger não era bom para projetos grandes. O próprio Tom Mornini, CEO da EY, retrucou às provocações do Pratik Naik, depois o Ninh Bui da Phusion também respondeu.
Vocês devem ter notado que depois do lançamento do Merb 1.0, o DHH voltou fortemente à ativa, evangelizando com nunca. Escreveu mais blog posts recentemente do que o ano passado inteiro, atualizou o site oficial do RubyOnRails.org, passou a apoiar publicamente o Passenger. Fora isso, o Rails 2.2 mal saiu e o Rails Core investiu mais tempo na integração com Rack e o Josh Peek lançou o Rails Metal como uma maneira de combater o Merb Bare. Fora alguns patches recentes para tentar melhorar o suporte a Rails Engines, também como forma de combater o Merb Slices.
Frente a tudo isso, conversei com o Matt e em seguida ele escreveu o Merb ♡ Rails numa tentativa de quebrar o gelo. Mas neste ponto as cartas já estavam na mesa. De lá para cá muita coisa aconteceu por baixo dos panos. Resumindo, ontem decidiram que a solução seria juntar os dois projetos. O Merb deve entrar em modo de manutenção e provavelmente a melhores features devem ser mescladas no código-fonte do Rails. Eu especularia que DataMapper poderia passar a ser uma alternativa ao ActiveRecord, o suporte a dependências poderia ser melhorado e o recurso de Slices poderia substituir o antigo Rails Engines.
Tecnicamente isso é uma boa notícia. As vantagens é que os melhores recursos do Merb estarão disponíveis no Rails 3.0 e ainda evitamos uma cisão de comunidades além de fecha a Guerra Fria e entrar num período de trégua. Por outro lado, sabendo um pouco mais do que andou acontecendo, vou segurar minhas fichas até ver como as equipes do Rails Core, do Merb Core e da Engine Yard vão se comportar de agora em diante.
Update:
*Primeiros Desenvolvimentos"