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.

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".