Demorei para fazer esse post, mas antes tarde do que nunca!

O encontro de Abril aconteceu no dia 11 e novamente tivemos um bom quórum de participantes. Seguimos o mesmo modelo do encontro anterior onde cada um fala um pouco sobre o assunto que desejar e um assunto vai emendando no outro. Fica como se fosse um bate-papo mas com bastante conteúdo.

Iniciamos o encontro comigo mostrando um projeto open source que tenho trabalhado com outros desenvolvedores. Trata-se de um jogo de tabuleiro online baseado no jogo de tabuleiro do Game of Thrones. A ideia era basicamente contar como é importante contribuir para projetos open source e como isso além de te entreter te ajuda a melhorar o seu networking e suas seu conhecimento técnico. Também comentei sobre outro projeto open source que dedico parte do meu tempo, o Call4Paperz. A partir desse tema iniciamos uma conversa sobre Github Vs Bitbucket. Sabemos que cada um tem seus pontos bons e ruins, mas se vai trabalhar em projetos open source, o Github de fato é a melhor opção, principalmente por ter a maioria dos projetos open source hospedados lá e a comunidade está muito mais ativa lá.

Dando continuidade ao bate-papo falamos sobre Jekyll e que esse site do RubyOnRio é feito usando essa tecnologia. Falamos como é possível fazer bastante coisa usando apenas Jekyll e alguns plug-ins dele. As possibilidades são infinitas, desde documentação de projetos e APIs até sites pessoais. Ele é tão simples que lembramos do bom e velho Sinatra. Comentei que acho o sinatra fantástico, mas que dependendo da necessidade do projeto, não faz muito sentido usa-lo em dentrimento ao Rails. O Sinatra até tem algumas versões mais elaboradas como o Padrino, mas que sinceramente e particularmente não vejo muito sentido em usar. O Rails é um framework fantástico e cumpre com todos os requisitos que o Padrino oferece. Posso estar desmerecendo um pouco o projeto, mas o pouco que vi do Padrino não me convenceu a usá-lo ao invés do Rails.

Em seguida o André Fonseca iniciou sua contribuição para o encontro. Ele começou falando com um tema bastante comum no mercado de trabalho atual: “Como convencer o seu time ou empresa a mudar de tecnologia?”. Esse assunto gerou um papo bom e contribuição de bastante pessoas. Basicamente a conclusão que chegamos na hora foi de que é sempre importante optar por uma tecnologia mais adequada para a necessidade do projeto porém é mais importante ainda entender a realidade do time, quais os recursos que tem no momento e chegar num meio termo. Em outras palavras, se o seu time sabe mais sobre Ruby do que Node e a necessidade do projeto aceita ambas as tecnologias como solução, opte pela que será mais produtiva pela equipe, no caso do exemplo, Ruby.

Ainda nesse tema, André mostrou como um simples script em Python o ajudou a automatizar e acelerar uma tarefas que era feita manualmente na empresa. As vezes um simples script podm ajudar bastante na automatização de um processo, podendo ter até binários para esses scripts. No mundo Ruby por exemplo você pode fazer um script e utilizar o Thor. Essa gem é a responsável por gerar qualquer script Ruby em arquivos binários, assim como é feito com o Bundler, Vagrant, Rails e muitos outros.

Falando de Rails e outras tecnologias o papo começou a girar em torno de performance e como é possível sim ter projetos super performaticos com Ruby on Rails. Um exemplo citado por André foi de que é muito comum ver desenvolvedores cometendo erros basicos de configuração como ajustar corretamente o pool de conevões do Rails com o banco de dados. O Luciano também citou que muitos também esquecem de limpar os dados escritos no Redis pelo Sidekiq.

Algumas barreiras também foram citadas como problemas para mudar a tecnologia usada em algumas empresas, como por exemplo não ser possível rodar o Ruby no servidor da empresa. Nesse caso o André comentou sobre o Warbler, empacotador bit code para Java. Nesse caso é necessário ter o JRuby para gerar o bit code.

Performance é um assunto sempre polêmico, sendo assim André propôs a seguinte reflexão: “Não adianta falar que não é performatico. O que é performance?”. Essa reflexão sugere a todos nós pensarmos bem sobre o tema e o que realmente é necessário para solucionar o problema. Muitas vezes um simples cache ou ajuste fino nas configurações do seu servidor podem resolver o problema. Nesse momento foi citado o nome do nosso saudoso e sumido colega do RubyOnRio Rafael Martins a.k.a. Cabra. Cabra tem uma vasta experiência em performance com Ruby e outras tecnologias também. Experiência obtida através dos projetos por onde está e passou na Globo.com. Outra grande referência sobre performance e que também está na Globo.com é o Vinicius Pacheco que já palestrou em alguns eventos e também é colega nosso no RubyOnRio. Ambos trabalharam com o André na Globo.com.

Não lembro ao certo agora, mas pelas minhas anotações vi que também foi falado que é bem performatico utilizar Puma com JRuby.

E pra não perder a piada algum engraçadinho lembrou da maior aplicação monolítica em Rails e que é bem performatico (tem video também). Trata-se de um site de Receitas e que “basicamente” a solução para escalar a aplicação foi subir um monte de servidor nos horarios de pico! Foi uma descrição simplória minha. Assistam o video que vale a pena!

Fechando sua participação, André comentou sobre um post que viu do Fábio Akita sobre o fim do ruby e recomendou ~um livro que ainda não consegui pegar o nome correto, mas atualizarei o post assim que conseguir~ essa palestra do Joshua Kerievsky.

No final do encontro, conversando sobre ideias e pedindo sugestões de temas para os próximos encontros, comentei sobre uma ideia maluca que me ocorreu referente ao tema de performance. Basicamente seria uma “luta” entre aplicações. Ambas deveria mandar requests e responder aos requests o mais rápido possível e esses requests iriam aumentando até que uma dessas aplicações não aguentasse mais responder e perderia o desafio. É claro que tem muitas lacunas sobre como fazer isso acontecer e como julgar. Talvez teria que ter um outra aplicação escutando os dois, não sei. Só uma ideia que me ocorreu na hora. Também sugeri um uso alternativo no Call4paperz de modo a nos ajudar para os próximos enconros. Ao invés de inscrever as propostas quer falar, seria a inscrição de quais temas gostaria de ouvir.

Até a próxima!

Abraços,

Rafael B. Tauil