If you ask what's the best way to do a fast content site, many people will point you to Jekyll or a similar tool.

The concept is simple: nothing will be faster than a statically generated website. But writing a complete website statically is not viable because you will be repeating HTML code for headers, footers, sidebars, and more across all pages. But current tools such as Markdown, SASS, Sprockets (or Gulp/Grunt tasks if you're using a Javascript clone of Jekyll) will make it a whole lot easier to properly structure, organize and separate concerns on what are reusable snippets and what is just content. Then it will "compile" the content and the snippets into complete HTML pages ready to just transfer to any web server.

Because it's already static files, the web server doesn't need to reverse proxy to an application server or have any other kind of dynamic processing, just serve the files as it would serve any other asset. And this is Fast.

If you're doing a personal blog, a simple and temporary hotsite, something that you know won't change too much, and if you're a developer, this is possibly the way to go: fire up Jekyll, write your content in Markdown, compile, copy assets to S3 or Github Pages, and you're up.

Problem is: what if I want more from my content web site? What if I don't want to have developer tools around to compile my pages and I just want a plain simple Administrative section to edit my content? What it I want to mix a static content section with my dynamic web application (an ecommerce, social network, etc)?

Then I have to use Rails and Rails is very slow compared to a static web site. Or is it?

Static vs Dynamic

Obs: libsass não necessariamente é 100% compatível com Sass-Ruby ainda. Em muitos casos você não deve ter problemas (teste!) Mas fique de olho nesta tabela comparativa de compatibilidade. No instante da publicação o libsass 3.2 está a 98.53% de compatibilidade!

Nada foi mais disruptivo no mundo de desenvolvimento de stylesheets do que o advento do SASS em 2007. Sim, faz 8 anos, e sim, estou exagerando, CSS 3 foi bem mais disruptivo, mas vocês entenderam! A menos que eu esteja enganado foi quando se entendeu também que era possível transformar uma linguagem tosca (CSS 2) em algo bem mais trabalhável, foi o início do uso do conceito de transpilers para Web.

Por todos esses anos o Sass, escrito em Ruby, serviu seu propósito muito bem, mas sabemos que ele é um dos calcanhares de aquiles quando fazemos deployment de projetos Ruby. Em paralelo se iniciou uma reimplementação em C (libsass) para tornar o Sass não dependente de Ruby (agnóstico de linguagem) e com performance mais adequada.

O pessoal de Node e outras linguagens já usa o libsass em pacotes como o node-sass. É hora do filho pródigo retornar à sua casa. Para usar em projetos Ruby on Rails precisamos fazer o seguinte:

Eu queria fazer uma limpeza geral na minha conta do Slack (que já tinha mais do que o suficiente de imagens-memes entupindo o limite de armazenamento), o problema é que ele não tem um "marcar tudo" e "deletar tudo" na interface de administração, mas felizmente ele tem APIs!

Então eu escrevi este pequeno script em Ruby que tem 4 dicas que vale a pena compartilhar:

Finalmente coloquei no ar o site do Call for Papers então, todos que querem palestrar, por favor, submetam o quanto antes. Lembrando que vou tentar até o fim de maio ou começo de junho e que você pode já submeter e ir alterando o conteúdo até lá.

Este ano teremos uma novidade: quero experimentar um novo formato de conferência. Este será o oitavo ano consecutivo com o mesmo formato: 2 tracks paralelos, durante 2 dias inteiros, com quase 30 palestras com assuntos que vão de iniciantes até avançado.

A conferência conta com cerca de mil participantes no local, onde de um terço até metade é composto tanto de iniciantes quanto pessoas que vão pela primeira vez ao evento (sim, pelo menos segundo a composição dos participantes da Rubyconf, todo ano a comunidade em geral parece que aumenta 50% pelo menos).

Está cada vez mais complicado selecionar palestras que agradem a todos. Antes que chegue um ponto que o formato se torne inviável, chegou a hora de mexer em time que está ganhando. Este anos vamos dividir o evento em 2: um mais focado ao pessoal mais experiente e/ou avançado e outro focado no pessoal menos experiente e/ou que está iniciando, tanto em Ruby quanto em tecnologias Web em geral.

Se você participou da Rubyconf Brasil em 2014 teve a oportunidade de ver em primeira mão o lançamento do produto Jelastic Cloud, da Locaweb, na época com suporte beta a Ruby.

Ontem brinquei com o Jelastic com a ajuda do camarada Kemel Zaidan, evangelista de tecnologia da Locaweb e colocamos o site do Call for Papers para a Rubyconf Brasil deste ano no ar por lá.

Como há alguns truques, resolvi fazer um pequeno post para dar uma idéia do que é possível fazer. Diferente de VPS ou similares, o Jelastic é um Platform as a Service (PaaS) que oferece tanto escalabilidade horizontal (mais servidores embaixo de um balanceador de carga) ou também escalabilidade vertical (mais recursos como memória e CPU mais rápido na mesma máquina). Além disso ele pré-configura quase tudo para que você não tenha que lidar com coisas como configurar o NGINX como proxy reverso para balancear carga ou configurar o PostgreSQL.

Criar uma conta trial é simples, você recebe sua senha por email e pode entrar no dashboard. De lá basta configurar a topologia da sua aplicação que te dá opção de escolher a tecnologia (Java, PHP, Ruby, Node.js, Python, .NET). No caso de Ruby você pode escolher direto a opção do Raptor Beta. Então pode configurar quantos cloudlets quer (pelo que entendi 1 cloudlet é uma unidade de processamento que representa 128Mb e 200Mhz e pode escalar verticalmente até 64 cloudlets ou 8GB e 12.80Ghz) por node. E horizontalmente você pode escolher ter até 18 nodes. Em termos de preço isso pode ir de até R$15 por mês (lembrando que é pagamento por utilização e não preço fixo) até R$10.179 na configuração máxima.

O Koichi Sasada palestrou recentemente no evento RubyconfPH sobre as melhorias no garbage collector.

Na prática: o Ruby 2.2.1 tem agora garbage collector com 4 gerações (2 jovens, 1 velho, 1 survival). Na versão 2.1 eram somente 2 gerações (nova e velha, onde objetos novos eram promovidos pra velhos se sobrevivessem a um fase de marking do GC, mas isso levava objetos a serem promovidos prematuramente, usando mais memória do que deveria).

Quem assistiu minha palestra no QConSP ano passado aprendeu em mais detalhes sobre a evolução do garbage collector. Se não assistiu veja a gravação. Recapitulando:

TL;DR: se está familiarizado com os problemas de executar Rails no Windows e já sabe o que é o HttpPlatformHandler, porque devemos usar JRuby no Windows, pule direto pra seção Configurando Rails da forma Correta para Windows mais pra abaixo.

No dia 4/2 a Microsoft anunciou o módulo HttpPlatformHandler. Então, em 9/2, o conhecido blogueiro Scott Hanselman fez um blog post explicando como poderíamos usar esse módulo para servir uma aplicação Rails atrás do IIS 8. Depois de um comentário que fiz ele atualizou para demonstrar como servir uma aplicação Rails em cima do JRuby.

Quase 2 anos atrás fiz um artigo que teve muitos leitores sobre instalar Ruby no Ubuntu 12.04 LTS. Inclusive era o que eu estava usando até agora como ambiente de desenvolvimento no Vagrant. O bom é que dá pra desenvolver tudo sem problema algum nesse ambiente e é bem estável, mas resolvi atualizar o mesmo artigo para instalar no último Long Term Support do Ubuntu, o 14.04 LTS Trusty Tahr.

Para VPS pequenos, eu particularmente não me incomodo de usar RVM em single-user mode com Nginx+Passenger. Em particular eu instalo esse ambiente num Vagrant, então se for esse o caso, depois de instalar o Vagrant, faça assim:

1
2
3
vagrant init phusion/ubuntu-14.04-amd64
vagrant up
vagrant ssh

Este é um dos assuntos mais antigos que eu exploro neste blog. Muitos dos princípios, filosofias, pensamentos por trás disso estão nos meus famigerados (e longos) Off-Topic. Como são muitos anos de posts, resolvi compilar o que considero as bases do que todos precisam saber sobre esse longo bikeshedding chamado "processos e metodologias".

Comece simples com o artigo que empresta título a esta coletânea Processos e Metodologias não vão te Ajudar que publiquei nos blogs da Abril em 2011. Para começar entendendo o que são processos, metodologias e procedimentos.

Em muitos aspectos o ano de 2014 foi extremamente triste para a comunidade internacional de Ruby e para mim pessoalmente já que conheci os 3 pessoalmente.

A comunidade internacional de Ruby vira e mexe surge com alguns "dramas". Toda comunidade tem seus "dramas", mas os Ruby Dramas particularmente chamam a atenção das demais comunidades então de vez em quando vale a pena explorar alguns deles para explicar porque eles acontecem e quais as ramificações.

No último dia de 2014, Brian Shirai soltou um post unilateral entitulado "Matz's Ruby Developers Don't Use RubySpec and It's Hurting Ruby", onde ele explica porque é ruim o Core Team do MRI não usar regularmente o projeto RubySpec, vale a pena dar uma lida.

Como contexto, vale explicar que Brixen é quem herdou o manto da implementação Rubinius e também do projeto RubySpec, que tenta ser uma suíte de testes que define o comportamento do que é a "linguagem Ruby" para que implementações alternativas como o próprio Rubinius ou JRuby ou outras possam se basear. Os projetos originaram com Evan Phoenix, atual membro do Ruby Central e organizador das RailsConf. Digamos que Evan é mais "politicamente correto", Brian é mais "agressivo".

Update 30/12/2014: existe um bug/regressão no Ruby 2.2.0 que não existia no 2.2.0-preview1.Se estiver usando Rails 3.2 você deve encontrar o warning de "circular argument reference". Então não atualize pra 2.2.0 se estiver no Rails 3.2 ou use este patch que o Aman Gupta fez.

Como prometido pelo Ruby Core Team, novamente como presente de Natal, no dia 25 de dezembro de 2014 tivemos o lançamento do esperado Ruby 2.2.0. Para saber o que mudou veja este artigo da InfoQ.

Para começar, é bom lembrar que a versão 1.8.7 está terminada desde 2013 com o End of Life oficial.

A série 1.9 trouxe diversas mudanças drásticas estruturais que, embora não quebrem tanto em termos de sintaxe, quebram nas estruturas de dados, como suporte nativo a Unicode, nova sintaxe de hash, Fibers, por exemplo. Peter Cooper tem um Walkthrough que vale a pena dar uma olhada. As versões 1.9.1 (experimental), 1.9.2 (estável mas ruim) e 1.9.3 (a melhor da série) foram grandes avanços desde a série 1.8, tanto em funcionalidades quanto performance.

A série 2.0 trouxe keyword arguments, module prepend, lazy enumerators, refinements (experimental). E a série 2.1 trouxe refinements como feature estável, inteiros de 128bits, melhoria no cache de métodos (um grande problema numa linguagem dinâmica com classes abertas), e a introdução da primeira geração do Restricted Generational Garbage Collector (RGenGC). Eu fiz um artigo chamado O que tem de novo no Ruby 2.1? que explica um pouco mais disso. Também fiz um artigo chamado Indo de Ruby 1.8 e Rails 2.3 para Ruby 2.0 e Rails 3.2 cujas técnicas continuam válidas para as novas versões de Ruby e Rails.

O mais relevante desde a versão 1.9.3 (lançada em outubro de 2011), seguindo pra 2.0.0 (lançada em fevereiro de 2013), depois a série 2.1 (lançada em dezembro de 2013) e finalmente com a 2.2.0 (lançada agora em dezembro de 2014), são 3 anos de evolução rápida e constante do Garbage Collector e algumas estruturas internas importantes como method caching e symbols.

Assistam minha palestra sobre Garbage Collector de Ruby para entender o funcionamento exato:

Um problema que nos persegue há muito tempo são uploads. À primeira vista é algo simples:

  1. Coloque um form com multipart configura
  2. Coloque um campo de input tipo "file"
  3. Dê POST, o upload vai iniciar com o web server
  4. Quando o upload terminar o web server passa o arquivo pra aplicação, agora é só salvar no disco

Mas esse é o jeito ruim. Funciona muito bem pra coisas pequenas, mas tenha muitos usuários fazendo uploads de dezenas de megabytes (que é o tamanho de qualquer foto tirada em smartphones) e de repente seu servidor fica de joelhos. Tenha muitos usuários fazendo uploads em conexões toscas (3G) e de repente seu web server fica travado à merce de conexões lentas. E no caso do Heroku, com timeout fixo em 30 segundos, tudo é cancelado depois de um tempo.

Daí tem o problema de onde colocar os arquivos: se colocar em arquivos no disco do servidor, a hora que você precisar colocar um segundo servidor em load balancing, vai ter problemas. Ainda tem gente que acha uma boa idéia colocar binários em campos BLOB num banco de dados (NUNCA FAÇA ISSO!!!). A única solução decente é jogar em buckets do S3 ou outros storages em cloud, mas sua aplicação fica mais lenta ainda: primeiro esperando o upload do usuário e depois fazendo o upload pro cloud. Tudo parece piorar o problema!

Pensando nisso fiz um artigo explicando em detalhes o problema, chamado S3 Direct Upload + Carrierwave + Sidekiq. Não é uma forma simples mas funciona. Porém o criador do Carrierwave, Jonas Nicklas parece que se cansou desse e outros problemas mais inerentes ao Carrierwave e resolveu começar do zero. Ele criou e lançou recentemente a excelente gem REFILE.

TL;DR: Esqueça Paperclip, Carrierwave ou Dragonfly. Use Refile! Ele tem dezenas de opções como qual storage você quer usar e muito mais, mas neste post vou me limitar ao caso de uso mais comum: Direct Upload para o S3, sem carregar seu servidor/aplicação. Tão fácil que cabe num Small Bites.

Acho que esta vai ser realmente a primeira small bite versão miniatura mesmo! :-)

Kindle Paperwhite + Manga = Diversão