Se você desenvolve front-end com Ruby on Rails o excelente Asset Pipeline faz tudo por você. Praticamente não há configuração que você precisa fazer, nenhum arquivo para scriptar seu próprio pipeline caseiro, nenhuma discussão sobre como fazer requires.

Para 80% dos casos (ou mais!), tudo que você precisa é conseguir desenvolver seus stylesheets (Sass!) de forma organizada podendo até usar Javascript ES6. No final o framework vai automaticamente concatenar tudo, minificar, adicionar controles corretos de versão (fingerprint/hash) para que ninguém precise se preocupar em expirar caches. E em desenvolvimento, tudo vai funcionar separado para ficar fácil debugar.

Hoje fui investigar um problema estranho em produção onde um controller não estava reagindo da mesma forma que em staging (aqueles momentos Murphy!) No final o problema era um SQL insert travando e dando timeout em toda request, problema em infraestrutura no Heroku Postgresql, e não da aplicação, mas para isolar o sintoma o seguinte truque ajudou.

Uma coisa que eu costumo fazer nesses casos é ligar o Rails Console (bundle exec rails c ou bin/rails c), criar a hash params com os parâmetros ig...

Se você é novo na comunidade Rails do Brasil, um dos melhores lugares hoje em dia para conseguir dicas e informações (DEPOIS que você já procurou no Google, Stackoverflow, etc) é o grupo "Ruby on Rails Brasil" no Facebook que, até a publicação desse post, conta com mais de 6 mil membros!

Eu e outras 11 pessoas administram esse grupo nas horas vagas, o que significa 500 pessoas por administrador. Portanto, para que as coisas funcionem de forma eficiente, precisamos da colaboração de todos.

Primeiro de tudo: se você for uma empresa procurando candidatos, esse é um excelente grupo para começar, mas não é a casa da mãe Joana e existem regras, então o mínimo que se deve fazer é: seguir as regras. O administrador André Stephano foi quem levantou a bola, então copio aqui o post que ele publicou no grupo:

Andre Stephano - July 10 at 2:33pm

Estamos pensando em voltar a forçar as empresas a informarem salário e forma de contratação se quiserem anunciar, dessa forma nenhum usuário perde tempo com algo que financeiramente é inviável e por outro lado, um anúncio generoso pode atrair desenvolvedores que não procuram emprego. O que acham disso? Motivo: Tem sido uma prática comum empresas colocarem anúncios chamativos para atraírem desenvolvedores. Inclusive, um amigo próximo foi para uma série de entrevistas em outra cidade, pra um vaga pra desenvolvedor senior em Ruby (completo com devOps e design) que no final de tudo revelou o salário de R$ 3.300,00 em PJ. O pior que nesse caso, a seleção ainda estava cheia de pessoas que também tinham grandes expectativas e foram enganadas. Isso acaba desvalorizando um pouco nosso mercado, faz pessoas voltarem frustradas achando que essa é a realidade, outros perdem tempo e no geral, desse monte de gente, alguém bom acaba aceitando já que chegou até ali. A ideia é fazer com que vocês saibam o que esperar antes de perder tempo enviando CV e indo pros processos seletivos. Querendo ou não, somos o principal canal de desenvolvedores Ruby no país, então pra postar aqui, que seja por nossas próprias regras. "Quem tem medo de mostrar o preço é porque quer pagar pouco"

Regra: coloque a remuneração da vaga no corpo do texto do post no grupo, não vale dentro da descrição num link externo.

Estou um pouco atrasado com meu review mas antes tarde do que nunca. Alguns dias atrás a Casa do Código lançou um novo livro para iniciantes que querem começar no mundo da programação.

Hoje existem muitos tutoriais na Web para aprender todo tipo de truque de programação. Para muitos, programar se tornou um processo de:

  1. pesquisar no Google, Stackoverflow ou outros fórums
  2. copiar o trecho de código e colar no seu próprio código
  3. lucrar

Isso é pouco, é muito pouco, é um enorme desserviço ao mercado de programação. Não há nada errado em copiar e colar trechos de código, até mesmo programadores realmente experientes fazem isso por conveniência muitas vezes. Mas é muito errado quando o programador faz isso sem ter consciência do que está realmente fazendo. E faça isso muitos anos, isso não o torna "experiente" em programação, meramente o torna uma máquina velha de copiar e colar.

Estou nos meus primeiros dias estudando Rust, a nova linguagem de sistema criado pela Mozilla. Essa linguagem está no meu radar faz vários meses, principalmente pelo suporte positivo de rubistas influentes como Steve Klabnik e Yehuda Katz.

Meu interesse é simples. Rust é uma linguagem pequena, mais próximo da categoria de C ou Objective-C do que GoLang, ou Elixir. Uma das coisas que sempre podemos fazer para "vitaminar" nosso querido Ruby é criar extensions em C. Mas se você já tentou fazer isso, sabe que nem é tão complicado com pequenas coisas à la "hello world", mas a coisa pode ficar exponencialmente complicada com muitas dependências e complexidades de toolchains. Então minha intenção em aprender Rust é ver se ela pode ser uma boa alternativa para criar extensions nativas performática facilmente consumíveis via FFI (Foreign Function Interface).

Este artigo é apenas um pequeno exercício que vai além de um simples "hello world", que seria absolutamente trivial. Quero fazer uma pequena biblioteca capaz de ler um arquivo de tamanho arbitrário (portanto não pode carregar tudo em memória) e fazer um parse com regular expressions (algo que fazemos comumente).

Ainda estou literalmente nos primeiros passos de aprender Elixir corretamente, mas achei interessante fazer um post demonstrando alguma coisa prática.

Para quem ainda não sabia, existe uma linguagem chamada "Erlang" (para "Ericsson Language"), uma linguagem "quase-funcional" com nada menos que 29 anos de idade (lançada em 1986) cujo núcleo é uma virtual machine muito leve, com grande tolerância a falhas e alta concorrência com processos leves e primitivas simples.

Elixir foi criado por ninguém menos que nosso conhecido Railer e Rubista José Valim para ser uma alternativa moderna de linguagem. A linguagem Erlang não é estranha da comunidade Ruby em geral pois Dave Thomas e Andy Hunt evangelizaram muito ela em 2007 pela Pragmatic Programmers. Mas a sintaxe realmente não é agradável para a maioria de nós. Para isso existe o Elixir: para que possamos usar toda a maturidade da VM do Erlang com uma sintaxe agradável com muitos traços de Ruby (embora não seja uma descendência direta).

Depois de alguns anos em desenvolvimento, o Valim fechou a versão 1.0 oficial em Setembro de 2014, então agora é um bom momento para investir tempo em aprender.

Este post não tem como objetivo ser um artigo altamente detalhado, apenas primeira impressões. Para aprender mais vá diretamente à fonte:

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.