Campus Party é considerado o maior evento de inovação tecnológica e entretenimento eletrônico em rede do mundo. Um encontro anual realizado desde 1997 na Espanha, que reúne durante sete dias milhares de participantes com seus próprios computadores procedentes de diversos países, com a finalidade de compartilhar curiosidades, trocar experiências e realizar todo tipo de atividades relacionadas a tecnologia, a cultura digital e ao entretenimento em rede.

Tá bom ou quer mais?

A organização do evento desse ano ainda vai dar uma lambuja pra quem acha que ainda não tá bom. Eles irão BANCAR a inscrição de quem participar da primeira caravana organizada de cada estado (a lista tem que ter no mínimo 30 e no máximo 50 nomes).

O @obrunomendonca mandou a idéia de Curitiba para agitarmos as coisas por aqui e fazer o Paraná marcar presença no #cparty09. A idéia é que juntando o pessoal de várias cidades, fique mais fácil espalhar o lance todo . Por enquanto o transporte não foi combinado, mas há a possibilidade de partimos em uma Van (vamos combinar!).

Assim que completarmos os 30 vamos mandar para não arriscar perder para uma escola de informatica xing-ling da vida. Chamem seus amigos, pais, tios e irmãos para ir!

Para participar: inscrevam-se no Evento mas não efetuem o pagamento. Preencham este formulário e twittem sobre ;D

Já estão participando:

• Deus salve a Rainha
• Nerd Curitibano
• Teusma Press
• Luciano de Sampaio
• Pomo T.I

Eu resolvi fazer alguns testes com Threads e Timeouts no Ruby hoje e para tal resolvi lidar com algo real: chamadas a APIs.

Problema

O problema todo da escalabilidade acontece por um simples motivo: uma chamada que demora para responder gera uma bola de neve no sistema. E esse problema da bola de neve se repete em várias partes do sistema todo. É isso que ocorre com as querys longas no MySQL ou upload de arquivo que trava uma instância do servidor e deixa todas próximas requisições lentas.

Por isso que é muito mais importante diminuir o tempo das querys longas no MySQL do que qualquer outra coisa. Você provavelmente consegue tirar mais tempo das querys mais longas, certo? Pense no lance de proporção, certo?

Problemas em escalar leitura em MySQL são comuns e por isso as soluções são amplamente conhecidas. Apesar de existir lock para leitura e outras características que machucam muito o trabalho de quem tem que escalar base de dados relacionais, caras como o Flickr fazem um bom uso do MySQL até hoje (sempre com ajuda de cache, lembre-se disso).

Mas e se a fonte de dados da aplicação é algo muito mais lento que um MySQL? E se a fonte de dados é digamos um WebService? Ou no pior dos casos: Web Scraping?

Um WebService ou uma API RESTfull não tem latência controlada como uma query rodando no MySQL local (ou em um cluster de) pode ter. Para começar a falar sobre WebServices eu penso logo em 200ms de latência só para atingir o servidor. E acredite, na maioria das vezes isso é pouco e de qualquer forma é o tempo de resposta que uma query comum no MySQL deve levar.

Além da lentidão você tem que pensar que a coisa toda pode não funcionar. Você pode fazer a requisição HTTP e ela não voltar. É da natureza do HTTP não retornar algumas requisições.

Agora você pensa em centenas de requisições entrando na fila a cada segundo em um sistema que busca os dados em uma API de tempo de resposta médio de 2 segundos. Esqueça a moleza do MySQL. 2 segundos aqui (no meu exemplo de API) é o tempo de resposta mínimo! Ferrou.

Eu já passei por isso. A maneira básica de lidar é cache. Você sabe. Todo mundo sabe…

Mas ainda acontece que as requisições são muito lentas! Muito! O cache não pode ser para sempre e as vezes acontecem coisas que lhe obrigam a limpar todo o cache.

Não importa quantos processos Ruby você abrir (ou quantas requisições/segundo seu Apache sirva em uma maquina de 16 bits), sua aplicação não escala e a culpa é da sua fonte de dados que para piorar é externa e você não pode fazer nada.

Solução

Eu estou planejando cortar muito processos Ruby de uma aplicação em Merb que bate 2MM req/dia com uma solução parecida com a experiência de hoje (que alias se encontra no final do post).

Por enquanto, para manter o serviço no ar a solução foi usar o que havia de melhor na infra: Nginx, Memcached e Thin. Ainda assim eu preciso de 75 instancias do Thin para que tudo funcione (lembre-se: cache não é eterno e requisições sem cache são extremamente lentas).

Como irei mudar o cenário? Quase da mesma forma como espanquei um WebServer a poucas horas com somente um processo Ruby aberto e muito menos banda do que um VPS costuma ter… “Threads”.

Usei Threads de Ruby aqui para a experiência que vou passar, mas para produção recomendo o uso de bibliotecas que irão gerenciar o trabalho. Nanite leva a carga de conhecimento em engenharia que a EngineYard possui, e apesar de não ter uma solução baseada especificamente na questão de threads pode servir para distribuir instâncias do servidor entre várias maquinas numa rede local (lógico que não é - e nem pretende ser - uma implementação do MapReduce). Ainda preciso fazer um bom teste com Nanite e conhecer soluções como NeverBlock. De qualquer forma, essas são boas soluções para o problema de escalabilidade. Pode confiar

Abaixo o código (experimental) que derrubou um IIS (inclusive expondo pedaços da aplicação). Ele mostra como eu usei o máximo da banda disponível para fazer tantas requisições em um servidor remoto até ele cair. Isso com somente um processo Ruby.

Em casos comuns o gargalo seria do script Ruby que faz as requisições no outro servidor, no caso desse script eu tranformei o gargalo em banda e na capacidade do outro servidor de me responder. Situação bem melhor do que gargalo na requisição em si.

Ouvi dizer que essa não é a maneira mais fácil de lidar com o problema, certamente no Ruby NeverBlock é uma solução legal. Como eu disse, preciso olhar com atenção.

Boa parte do código serve para estimar o tempo necessário para conclusão da tarefa e para exibir quanto tempo cada Thread está levando.
O ideal é achar um bom número para colocar no método join da Thread. Tente deixar esse número um pouco acima do tempo médio que o servidor remoto (ou serviço externo) responda tranquilo suas requisições sem cair no mesmo problema de bola de neve. O grande segredo do código está nesse valor e você precisa ajustar ele para sua realidade.

Notas da brincadeira:

• Prefira utilizar Ruby 1.8.6. A documentação do 1.8.7 não está muito real. Principalmente com bibliotecas, onde enfrentei um probleminha com as classes Date e Time no 1.8.7.
• Cuidado com comparação de Floats (principalmente se tratando de datas), Floats são números muito mais complexos do que parecem.
• Hadoop

Acabei de instalar o Fluid para o OS X. Mesmo já tendo ouvido falar antes nunca dei atenção para o poder dele.

A principio parece que ele vai somente adicionar aqueles iconezinhos chatos na Dock, você acha que isso vai atrapalhar sua produtividade e fecha o site.

Nós estamos na cloud. Temos aplicações reais que ficam o dia inteiro abertas nos computadores, como Gmail, Google Docs, os outros do Google e até mesmo o Campfire (muito comum nos Estados Unidos). O problema é que até mesmo o Firefox sofre com um pouco de instabilidade ao rodar serviços pesados como esses.

Para começar o Fluid é inspirado no Prism do Mozilla Labs e tudo que é inspirado em algum produto do Mozilla Labs merece meu respeito.

Ele inclui scripting (no estilo do Greasemonkey), ícones para a Dock, integração com Quicksilver, notificações no Glow, uma API de Javascript no estilo do Greasemonkey (esqueça extensões para Firefox, elas são muito chatas difíceis de fazer), algumas integrações com as características do sistema operacional como “drag and drop” (apesar que na minha opinião essas características muito dependentes de sistema devessem fazer parte de plug-ins), separa cada “Aplicação” em um processo diferente e faz muito bem o trabalho para que a falha em um aplicativo não atrapalhe outro.

A diferença básica que encontrei entre ele e o Chrome é que o Fluid prefere não utilizar abas para navegação. Ainda estou em dúvida se foram as características melhores ou se foi a interface diferenciada que fizeram a diferença positiva no meu uso. De qualquer forma, com processos separados ou não, a escolha do usuário fica com a melhor interface.

O Chrome foi um grande sucesso de lançamento do Google e assim que o pessoal voltar a ler o que ele faz com certeza irão começar a usa-lo. Algumas melhoras na interface podem ajuda-lo a conquistar espaço entre o usuário comum (que ainda pode estar chocado com a aparência muito igual ao Firefox e diferente ao Internet Explorer). Estou definindo usuário comum como o cara que usa Windows XP rodando Internet Explorer, ok?

Enquanto isso o pessoal do Fluid saiu na frente entregando um produto que utiliza da interface gráfica do OS X (Cocoa) para entregar algo competente igual o Chrome. Se eles se empenharem em produzir um produto de qualidade para o Windows, tenho certeza que podem concorrer com o navegador do Google na próxima geração dos browsers. Vale a pena testar, mesmo.

Esse foi o melhor desde quando comecei a mexer no Unix
Depois de adicionar esse alias, para saber a documentação de um programa do sistema, digite:
comofas [nome do programa]
e tenha a documentação dele impressa no terminal.

O MerbCamp rolou em São Diego, Califórnia nos dias 11 e 12 desse mês. O pessoal da EngineYard mostrou ter feito um ótimo trabalho para o lançamento do Merb 1.0.

O foco da EngineYard está bem voltado em “fazer a coisa escalável”. E não é só no bizarro mundo da guerra de frameworks e linguagens. O Ezra apresentou um gem que cria um balanceador de carga entre vários processos Ruby, que eu não acho tão importante em si mas enxergo esse como um projeto que saiu da estrutura do Vertebra. Para quem não sabe Vertebra é o nome do projeto que rola dentro da EngineYard para criação de uma interface de aplicações para computação distribuída (cloud, já cansei de ouvir e tentei mudar um pouco

Abaixo uma apresentação com o que o pessoal do projeto Merb na EngineYard pensa sobre o atual estagio dele:

Perceberam que para mostrar que Rails é bem lento em comparação a Merb eles usaram o PHP como saco de pancada?

Voltando ao projeto do Ezra chamado de “Nanite“, prestem atenção nele! Logo de cara eu já identifiquei que ele resolve um grande problema que eu iria enfrentar futuramente em uma aplicação: Assincronicidade. Uma ótima resolução para problemas com escalabilidade é tranformar as partes mais lentas do sistema em assincronas. O Nanite serve como um auxilio para o desenvolvimento de uma aplicação que irá conter “background jobs”. O George fez um post legal sobre o tema: “Programação Assíncrona“, vale conferir!

VSF. Olhem esse game!

O marketing dos caras parece SPAM no YouTube. O game parece ter um criador de personagem identico ao seu criador, alguem jogou para falar pra gente?

Um vídeo com as gatas que estavam na E3 para apresentar o game pra galera:

E o melhor: propaganda no “The Big Bang Theory”! Sério, cliquem!

http://www.youtube.com/watch?v=J5KJMO7xqSw
http://www.youtube.com/watch?v=P7sZY4H1sFI

Site oficial Age of Conan.

O Tefo também curtiu, junto com o @laka que mandou o link.

O que é?

Seguindo a tradição do NerdsOnBeer de propor um ambiente descolado pra nerds discutirem, venho convida-los para o NerdsOnCoffeel que será realizado em Londrina, no dia 25/10 (por isso o L no final).

O café toma o lugar da cerveja neste evento, por querermos lembras das discussões no dia seguinte e quem saber até blogar sobre elas =D. Além do que, qual bebida adotamos como divindade maior que nos ajuda a pensar? han han han?!

Quem pode ir?

Estão convidados blogueiros, designers, fans de seriados, garotas, workaholics e quem tiver passando na rua que se proponha a discutir formas de economia, redes sociais, wiki, long tail, gadgets e etc em um clima de desconferência.

Quanto mais gente melhor! twite sobre (#nerdsoncoffeel), post sobre, coloque no seu orkut, msn,  testa.

Por que ir?

Vai fazero que num sábado a tarde? Vem tomar um café!

E não adianta depois reclamar que não tem evento desse tipo por aqui.

Vamo! Vamo! Vamo! Vamo! Vamo! Vamo! Vamo! Vamo! Vamo!

Moro/Estou em outra cidade. Fudeu?

Só se você estiver a fim. Nesse incrível mundo de internet temos a possibilidade de fazer stream e conexão skype! Genial né? É, eu sei.

Então compre o pó o café, prepare a caneca e o Mic/Mac e vamo ser feliz! (uí melamor).

Onde pitabas vai ser isso?

Não sei. Honestamente, pretendo definir essa semana. Estamos vendo possíveis locais que possam abrigar pessoas pálidas e notebooks com cobertura wi-fi, expressos satisfatórios e mesas. Até o momento o Frans, o Rei do Mate, Copenhagen e Hachimitsu estão na disputa. Logo atualizaremos com o local definitivo. Mas vai acontecer!

Mais um excelente motivo para querer participar da Wired NextFest.

Bobeando Procurando por inovação e algo com potencial para as futuras tendências no youtube, esbarrei no vídeo abaixo filmado na edição de 2007. Explica do melhor jeito possível o Brainball, uma partida entre um nerd e uma garota.

Ele mede a atividade cerebral dos jogadores e de acordo com intensidade da mesma, aumenta ou diminui a força magnética do seu anel que atrai a pequena esfera metálica.
Quanto mais relaxado melhor.

Além de mestres hindus, maconhistas surfistas e monges, toda uma geração que está crescendo alucinada por controles com eixos gravitacionais irão adorar as tendências que este jogo está seguindo.

Encare o Brainball como o Pong desta geração

Eu estava aqui estudando um pouco da arte de SEO. Um grande trunfo para ganhar dinheiro nessa industria vital que é a Internet.

Tive uma grande frustração ao juntar algumas frases dos guias de optimização e o foco do livro “The Long Tail”.

Toda a informação que agora eu sei seria muito mais útil se eu ainda estivesse lá em Londrina. Por mais que na época eu tentasse convencer o pessoal das agências a inovarem e buscarem conhecimentos além daqueles que eles aprenderam quando montaram suas “firmas” a coisa lá não ia. Eu era só o peão, entendem?

Eu cheguei até a fazer uma apresentação para pessoal de uma loja de informática, mas mesmo a loja fazendo a maioria de suas vendas pela web e tendo uma excelente participação em forums e comunidades dos usuários de seus produtos, a coisa não rolou.

A questão é a seguinte: grandes players precisam investir muito se quiserem aumentar seus lucros fazendo SEO (ou qualquer outra “grande sacada” da web atual).
Pequenas empresas e prestadores de serviço com foco em pequenos ninchos são os que mais se beneficiam com investimentos em suas páginas.

Esse investimento comparado a outros tipos de campanhas geram um retorno muito maior.

Como eu disse uma vez ao observar tanto o outdoor da Sercomtel quanto o outdoor da empresa de informática que vende para web: “Porque esses caras estão dando esse tiro de canhão?”.
Se o consumidor da loja está na web, qual o sentido desse muro com a marca deles?
Se o possível consumidor da Internet Sercomtel provavelmente está em uma Lan House louco para ter uma conexão em casa, porque eles gastam porrilhões em um outdoor?

Eu espero que alguma coisa tenha mudado desde que vim para São Paulo…

De qualquer forma: se você entende a falta de lógica nessas ações de publicidade dessas pequenas empresas com mercados regionais e quer mudar isso na sua empresa, eu ainda conheço um cara em Londrina que ficaria feliz em colocar um terno e explicar melhor o que você deveria fazer com a próxima verba de marketing.

Então certo dia lá estava eu, tentando uma expressão regular para interpretar (ou parsear) HTML. Uma tarde inteira tentando “achar” um elemento do HTML e substituir por outro. Apanhando da Regex…

Levantei, bebi agua e reclamei alto da vida. O Marco me perguntou o motivo do momento de fúria. Expliquei e fui submetido a mais um daqueles momentos “como eu sou tão estupido” que está ficando comum comentar aqui.

“Usa o jQuery porra!”

Uma das principais coisas fodas do jQuery é como ele trata o DOM (Document Object Model) das páginas e como ele permite buscar pela arvore de elementos “desse tal” de DOM. Ele armazena tudo de maneira bem leve e consegue procurar absurdamente rápido dentro dos elementos do HTML.

E o melhor: o jQuery permite que você crie essa “arvore de elementos” enviando uma string que contenha HTML/xHTML (XML para ser mais exato).

O código fala mais que a histórinha:

Para procurar o elemento você pode usar “CSS Selector” (igualzinho CSS3) e ainda tem a ajuda das várias funções de busca que o jQuery possui.

Ah! Vale lembrar que não é só no jQuery que é possível usar essa mágica. Existem bibliotecas parecidas em outras linguagens.
Em Ruby eu venho usando bastante a Hpricot. Elas utiliza a mesma lógica de armazenamento do jQuery e permite uso de seletores CSS e XPath.
Em PHP já me mostraram a SimpleHtmlDOM, parece bem fácil também.
Procure saber biblioteca é legal para usar na sua linguagem preferida e nunca mais tenha problemas em parsear HTML utilizando expressões regulares.