Extraindo informações usando Ruby
Hoje lancei uma aplicação que faz a análise dos palpites de um bolão (O bolão da Marko Informática) e mostra um gráfico com a quantidade de palpites por placa em um determinado jogo.
Para extrair essas informações eu não precisei acessar o banco de dados. Apenas consumi o que todos já podem ver, como por exemplo este link.
Essa brincadeira de extrair essas informações do bolão da Marko Informática começou com uma dúvida da minha esposa, Tatyana Emérito, se tinha condição de ver no site os palpites dos outros participantes. Em menos de cinco minutos depois eu vi que tinha a possibilidade de ver essa informação como vocês podem ver neste link, mas que infelizmente para mim é irrelevante.
Essa informação é desorganizada e não vai me ajudar a tomar uma decisão quanto aos meus palpites. Para mim é mais importante ter esses dados sumarizados de forma que eu não perca tempo analisando todos os palpites, um por um. Então, organizar a informação para que eu saiba quantos apostaram em 2x1 é mais interessante do que ter que contabilizar isso manualmente.
Para fazer isso em ruby eu utilizo a gem nokogiri, que faz justamente a análise e busca em html/xml. Com ela eu posso facilmente consumir o conteúdo de uma página e extrair os dados que realmente importa.
Nada muito complexo de se aprender, como você pode ver aqui.
Eu pensei em fazer usando o Rails 3, mas depois de fazer o primeiro protótipo, vi que não seria necessária algo tão grande, então tirei o Rails e coloquei o Sinatra.
Para montar o gráfico eu perguntei no Twitter quem indicaria bibliotecas js que fizessem Chart. Depois de olhar todas, a do Google Charts foi a que eu achei mais simples e sem burocracia para colocar no site.
E por fim, para fazer deploy da aplicação eu usei o Heroku, que é um serviço Cloud para aplicações em Ruby.
Trabalhando com datas naturalmente com Chronic
Esta semana passei gastando um tempão implementando um Parser que me retornaria um dia em que um evento ocorre em uma determinada data.
Mas a data seria algo “Quero trazer todos os usuários que se cadastraram na terceira terça feira do mês de janeiro”. A forma que eu estava implementando não era assim tão segura, apesar de todos os testes estarem passando.
Então hoje eu encontro o Chronic. É uma gem ruby que faz justamente o que eu precisava:
irb(main):005:0> Chronic.parse("3rd tuesday in january", :context => :past)
=> Tue Jan 19 12:00:00 -0300 2010
Simples e rápido.
Sincronizando bancos MySQL com Maatkit
Maatkit é uma ferramenta criada para DBAs, programadores e usuários que lidam com bancos de dados opensource em replicação master-master e master-slave.
A maioria das ferramentas foi feita para o MySQL, mas você pode utilizar em seu banco de dados preferido (Não sei quais seriam esses outros bancos :P).
Uma das ferramentas do Maatkit é a sincronização entre bancos de dados. Ela é extremamente útil quando você tem bancos de dados MySQL replicados, sendo ele na configuração master-master ou master-slave.
Após instalado (debian like é apt-get install maatkit) você pode fazer o seguinte comando:
mk-table-sync —execute —synctomaster —verbose
mk-table-sync é um dos executáveis que ele instala junto com vários outros.
Para sincronizar dois bancos sem ser master-slave você pode fazer da seguinte forma:
mk-table-sync —execute u=user,p=pass,h=host1,D=db,t=tbl host2
Se você que mais detalhes e ver os outros executáveis, visite o site do projeto.
Atualmente eu trabalho em basicamente duas aplicações: a do Jus Navigandi e o TrendTime. São duas aplicações Ruby On Rails, bem distintas, nessas duas aplicações eu faço testes.
Mas são níveis de testes diferentes, infelizmente. Enquanto que na aplicação do Jus Navigandi eu não escrevo código sem testes, na do TrendTime eu ignoro alguns lugares.
Eu faço isso por um único motivo: No Jus Navigandi o código não é meu, não é uma aplicação minha. Justamente por isso eu não posso arriscar em escrever códigos sem testes, sem ter um mínimo de qualidade aceitável. No TrendTime parte da aplicação foi feita sem testes, só no “olhômetro”. Claro que temos uma suíte de testes, mas ela não cobre a aplicação 100%.
Eu faço isso por quê no TrendTime eu posso errar e voltar atrás, enquanto que na aplicação do Jus Navigandi eu não posso cometer esse mesmo deslize. O código não é meu, o código é do Jus Navigandi, e como o código faz parte da empresa, o código tem que refletir a qualidade que é o Jus Navigandi.
O Jus Navigandi é uma empresa em excelência nos artigos publicados, é uma revista jurídica, como tal não é qualquer texto que entra lá. Existe uma bancada de pessoas que analisa todos os textos no dia a dia e apenas os melhores textos é que são selecionados.
Nós programadores temos que levar essa qualidade para dentro do coração do Jus Navigandi, o código tem que refletir a mesma qualidade com que os textos do Jus Navigandi são aceitos. O código tem que ser bom, o código tem que ser limpo e o código tem que ter testes (ciclo vicioso de qualidade).
Quando eu navego pelo github, por vários projetos, a primeira coisa que eu faço é descer a barra de rolagem e procuro por test ou spec. Faço isso pra saber se o criador daquela biblioteca teve pelo menos o trabalho de fazer alguns testes naquele código. Faço isso porquê eu, como um desenvolvedor que vai usar aquele código, fico mais tranquilo em saber que a biblioteca possui testes. Por conta disso, posso codificar com mais tranquilidade e se alguma coisa acontecer, vou primeiro verificar meus testes/códigos.
Assim como as bibliotecas que eu vou escrever, se eu não fizer os testes, vou passar menos confiança para quem possivelmente vai utiliza-la. Aprendi que na comunidade Ruby On Rails, os testes expressam mais do que os códigos. Se eu quiser saber como uma biblioteca realmente funciona, eu não preciso necessariamente criar algo com aquele código, eu posso ver a suíte de testes e me situar sobre aquela biblioteca.
Em uma empresa que você faz parte do time, é essencial que você passe tranquilidade para os outros programadores, sejam eles pessoas que já trabalhe com você ou um novo programador que vai ajudar o seu time.
Com uma suíte de testes, você tem a oportunidade de mudar tudo, arrumar e deixar como era antes. Por exemplo, mudar de SQL para NoSQL e sua aplicação continuar a mesma.
A melhor forma de você passar confiança para outros programadores é fazendo testes e cobrindo sua aplicação de testes. São eles que vão te salvar no dia que você vai ter que mudar a regra de negócio. São os testes que vão te guiar para uma solução simples.
The surprising truth about what motivates us.
Estudos (repetidos diversas vezes) mostram que dinheiro não é o principal motivador quando o trabalho envolve esforço mental. O vídeo explica o porquê.
Dúvidas com Git? Olha o blog do Alberto Leal
MongoID
MongoID é um ORM Ruby para MongoDB
NoSQL não é a bala de prata
Assim como qualquer tecnologia, ela nunca será a bala de prata. Escolher qual NoSQL usar é como mulher escolhe roupa: sempre a que fica melhor.
Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo.
PORRA, CHARLIE!!! PORRA, HURLEY!!! POOOORRA, LOST!!! ATÉ NA ILHA TEM ESSA PORRA DE REBOLEIXON?!?!?!? NÃÃÃO FOOOOOOOOODE, CARAAAALHOOOOOOO!!!!!
Contribuição do Filipe Bruno
CouchDB webcast recap, and info on next one…
Last week we had our first CouchDB webcast with O’Reilly, and it went really well! Thanks to all that attended, about 185 or so. Everyone was really active on the chat and the CouchDB experts were great at answering questions from those less familiar with CouchDB. Hope everyone enjoyed it as much as we did!
Our next webcast is “CouchApp Evently Guided Hack w/ CouchDB” on May 20th. Please register now for this free webinar.
Slides Introdução a NoSQL
Links dos slides do Chirp
Chirp, a conferência para desenvolvedores que o Twitter promoveu.
Big Data at Twitter, Chirp 2010
Chirp 2010: Twitter International
Effective Use of the Twitter Search API
The Why and How of Scala at Twitter
Chirp 2010: Scaling Twitter
Chirp 2010: Too many secrets, but never enough: OAuth at Twitter
Twitter Streaming API Architecture
“What’s Happening” to “What’s Happening Here” @ Chirp
Scaling Twitter with Cassandra
