31/10/2007 | Tags: intercon 2007, open source, rails, ruby, web scrap | Escrito por: Dirceu Júnior
[update 01/10 - 6:35] Duh! Foi o que falei quando vi esse link. Uma lista com realmente todas postagens do Intercon no Twitter. Também né fí, Google! Ai ganha em quantidade, mas a minha lista continuar sendo listada pela ordem cronológica das postagens.[/update]
Se você só quer ver a lista, não perca tempo:
Lista de tuitadas do Intercon 2007
(para evitar broncas, não adicionei ninguém. se você quiser ver seus updates, deixa lá seu nick)
Se você quiser saber um pouco mais sobre a breve história dela, enjoy!
Ontem cedo eu soltei uma lista de “tuitadas” que gerei com um web scraper. Mas de automática aquela lista só tinha a parte de entrar em profiles pré-determinados e procurar postagens com #intercon. Assim eu teria que ficar adicionando a galera que pedisse, gerar uma lista local e subir por FTP, como disseram: W3T demais!
Já que eu odeio ir pra faculdade adoro estudar por contra própria, decidi brincar e fazer algo mais decente.
Essa nova lista permite que você envie seu twitter-name (com ou sem @) e então a aplicação vai atrás de scrapear, jogar em um mysql (updates e nick), limpar cache e exibir listagem atualizada.
Terreno ruim pra quem não estava muito familiarizado com debugar Rails. Quase tudo na aplicação dava erro e por isso ficou difícil acha-los. Talvez seja útil falar os problemas que tive: Instalar gems na DreamHost, Timeout do FastCGI e Impossibilidade de definir Timeout no Scrubyt.
A questão dos gems foi a que tomou mais tempo, não por ser complicada mas pela minha inexperiência em entender de onde surgia os erros. Fica uma dica: Se você criou a aplicação na DreamHost (rails app) e só depois instalou seus próprios ruby, rails e gems, delete e re-crie a estrutura de pastas do Rails (rails app). Isso porque alguns arquivos (dispatch.fcgi, …) vão com o local que o Ruby está quando você os cria (aquela primeira linha #!/usr/bin/ruby1.8)
Com a questão do Timeout eu já estava mais esperto, com um SSH aberto só pra ficar no tail do log (muitos termos geeks ehehe), a solução foi até mais complicada mas o processo de localizar mais rápido.
O Timeout do FastCGI que era provocado justamente pela falta de Timeout no Scrubyt quebrava a aplicação. O Scrubyt utiliza o Mechanize para ler as paginas da web, que possui Timeout implementado. Então fiz algumas alterações no código do Scrubyt e ele passou aceitar passagem de parâmetro para Timeout. A próxima versão já deve vim com essa minha contribuição.
Enfim, matei aula da faculdade e tive muitas horas de diversão e aprendizado com Ruby/SHH/Rails/Apache/FastCGI e XPath/DOM também, porque não? ;D
Legal!? Então comente ;D
Ruim? Então faça uma sugestão ![]()


