Em base de dados a largura de banda, apesar de ser importante não chega ao nível de importância que o tempo de busca tem. E dispositivos de armazenamento de estado sólido possuem praticamente zero de tempo de busca.

Outro dia essa idéia me veio a cabeça e eu achei essa comparação: More Details on MySQL & SSD drive performance, agora fiquei animado ao ver um case no HighScalability onde a empresa de games online “EVE Online” utiliza SSD em seus servidores SQL Server. Abaixo um paragrafo do case:

Cluster de base de dados - Essa é a camada persistente da EVE Online. Os nós do cluster usam bastante a base de dados, então claro que quase tudo que se fazer com o game está aqui. Graças aos discos de estado sólido a base de dados consegue lidar com uma quantidade enorme de I/O tranqüilamente.

Como é possível ver nos gráficos desse artigo a diferença é realmente absurda.

Para reforçar que para aumentar performance na base de dados pode valer a pena o investimento em um SDD, leia o artigo do Marcos Tapajós sobre CouchDB - Databases don’t scale. YET! - ele deixa bem claro que o maior problema de escalabilidade é base de dados e mostra o CouchDB, promissor projeto da incubadora da Apache.

Brincadeira.

A parada não funcionava com códigos de verdade (que ião além dos meus testes bobos) pois não manejava direito aspas e contra-barras. Agora funciona. Se você ficou puto que essa porcaria não prestava antes, me dê outra chance.

Posicionamento no Mercado

O Zeebo não vem para brigar diretamente com os consoles da nova geração, como Xbox 360 e PlayStation 3, mas sim para oferecer uma alternativa viável para aqueles consumidores que ainda estão em uma escala inferior e hoje acabam comprando um PS2 desbloqueado para rodar apenas jogos piratas, por falta de outra oportunidade. Com um preço estimado para o mercado na casa de R$ 599 e disponível nas grandes lojas de varejo, com opções de facilidade do pagamento, a Tectoy espera chegar até este público, oferecendo jogos originais, que serão comprados com preço médio de R$ 20, podendo variar entre R$ 10 e R$ 30. Os próprios executivos da empresa esperam que a qualidade gráfica esteja entre o PS1 e o PS2, ficando no início talvez mais próximo do PS1 e com o passar do tempo e com o desenvolvimento de novos games, podemos chegar até a algo similar ao Resident Evil 4 no PS2. A diferença é que todos os games serão 100% em português e podemos dizer que o Zeebo é a prova de pirataria, já que a única forma de transferir os games é pela rede ZeeboNet 3G. [...]

[...]Para comprar os games, os usuários devem adquirir créditos em sua conta (chamados de Z-Credits), que poderão ser recarregados de diversas formas como cartão de crédito, boleto bancário, crédito em conta corrente ou cartão pré-pago, que poderão ser adquiridos em estabelecimentos comerciais. Os games lançados não serão simples conversões de outras plataformas, haverá todo um processo de preparação para deixá-los aptos para rodar no Zeebo, que vai desde a tradução das falas, menus e interfaces com o usuário, até a melhorias ou otimizações gráficas e preparo para a jogabilidade no joystick. A idéia é trabalhar com publishers conhecidas de renome mundial, tais como Sega, Capcom e Namco, além de contar com um controle no lançamento que englobe a função de acelerômetro, que inclui um sensor de movimento como o Wii da Nintendo.

Na íntegra no gamersbrasil.uol

Ok, legal até a idéia. Quais os problemas?

Eles copiaram na cara dura a frente do PS3, a lateral do Xbox e as cores do Wii… O hardware é equivalente a um PS1 e o preço de um PS2 a venda em qualquer site.
A idéia que realmente se destaca é a de baixar os jogos. Mas não creio que seja uma idéia genial vender um console com preço de um PS2, com jogos do preço de jogos do PS2 pirata sem qualquer outra vantagem. É o polystation novo?
Inserir uma conexão como a 3G é muito legal, não poderiam aproveitar e inserir a opção de jogar em rede? Ou então inserir uma conexão wi-fi para maior velocidade sendo que as tendências apontam para que existam cada vez mais área urbanas com wi-fi a um custo próximo do nulo. Essa sim seria uma vantagem tremenda…
Quanto ao preço, o mercado é formado pelas classes mais pobrelares, ou seja, não podem esperar que o lucro de um videogame cujo propósito é lucrar com o download de jogos sem qualquer custo de produção, além do desenvolvimento, fique na venda do console.

Tenham por exemplo a Apple. O iPod é considerado um player barato em relação ao custo benefício no Estados Unidos. Por que ele é o maior sucesso da Apple? Por que o Steve não cobra 1000 dólares no iPhone? Por causa da iTunes Store e a App Store, que vende as músicas e aplicativos neste mesmo sistema e obtêm o retorno sobre o investimento na parte longa da cauda.

Imaginem um videogame de 100 a 150 reais com milhares de jogos à disposição (a maioria desses, seria de produtoras independentes) custando de 2 a 5 reais cada um. O problema com os jogos mais populares é que empresas como a EA e outras ainda focam o mercado de alto nível, deixando campo aberto para a pirataria sendo que boa parte da renda destes jogos fica nos revendedores, cabendo ao nerd gamer pagar 100 reais em um disco de dvd com o jogo. Também não dá espaço aos desenvolvedores independentes de mostrarem que tem algo legal que gostariam que os outros vissem e prestigiassem. No mesmo esquema da App Store, o grupo cria um jogo, mostra pra uns amigos fazerem o review e vendem a licença para a TecToy ou outra empresa que se ligue nessa IDÉIA e disponibilize o jogo para download. Dos 3 reais que o usuário pagaria para baixar em média, 1 real iria para o dono da idéia e 2 reais a empresa que criou o console, o sistema e tem um custo quase nulo de mante-lo vendo a abrangência do mercado.

Digamos que venda meio milhão de consoles ao preço que sugeriram, R$ 599,99. Seriam quase 300 milhões de receita para eles, fora os 2 ou 3 jogos que cada usuario ira comprar antes de descobrirem um jeito de baixar os jogos pelo computador e colocar pela entrada USB do console… oops.

E se vendessem 1 milhão de consoles a 150 reais? “Só” 150 milhões de receita para vender o dobro de aparelhos.. não parece legal certo? ou parece? Pagando 3 reais por jogo considerando que não teria o custo de buscar em comunidades do orkut onde baixar no PC Positivo deles, parece um bom negócio. Até baixaria aquele jogo novo que o Zézinho contou. É só o preço de um salgado mais um suco. Não gostei? Ok, baixo outro, quem sabe aquele jogo independente que tem tudo que eu gosto porque tá na seção de tiros e tem as tags “emo” “matar” “chuck+norris-like”. Baixaria até uns 50 jogos assim…

E assim por diante.

Não façam um produto 1.0 em uma sociedade 2.0.

Inovem e repensem o conceito de produto.

Marketing não é aquele bicho de 42 cabeças maiores que a tua mãe falava pra você acreditar em deus.
Marketing não é o cu de chato, não é Mara, não é um ahazooo nem qualquer boiolice que você ache numa comunidade do Orkut.
Marketing não é propaganda, propaganda é marketing.

Mas que caralho… como eu posso falar o que não é marketing se nem eu sei? Se nem teu pai sabe? Se nem aquele seu tio que sabe inventar umas respostas para as perguntas mais esdrúxulas sabe. Se professores de marketing querendo mostrar que sabem mais de marketing que nós, porque eles tiveram mais tempo e menos vida social para ler mais uma porrada de livros escritos por mais um bando de gente que mal sabe o que é uma janela aberta, quanto mais uma opinião própria verdadeira, quem saberá de fato o que é marketing ?!

O meu marketing é aquilo que me faz olhar o mundo com os olhos de uma criança e perguntar “Tio, que acontece se eu apertar esse botão… PLICK” e falar “wow…, ia ser legal se tivessem filmado isso”.
Não é o que me faz admirar o mundo, é o que me faz ver as coisas como são e dizer “posso fazer isso ficar melhor”.

O meu marketing, o seu marketing e o caraleo a la quatre de seja aquela qual for a razão pela qual você fale “Seu tosco, eu sou melhor que você” para alguém é a verdadeira coisa na qual você tem de focar, e não naquilo que dizem que dá certo focar. Não vou gastar mais saliva ou células dermais dos dedos recontando o porque de fazer isso. Simplesmente faça e pronto.

Leia livros de pessoas boas no que fazem, veja no que eles contrastam com você. Abra a janela, não espere receber um direct falando que vai chover.

Para encerrar, um dos vídeos mais fodas que assisti este ano:

Alcioli - Nada a Declarar

Seguindo a proposta de papos e conversas “normais”, o primeiro tópico que conversamos foi a perspectiva dos blogueiros e nerds presentes e virtuais sobre o que está havendo na web e dar continuidade à conversa iniciada este ano sobre como desenvolver o potencial de londrina para o mercado de mídias sociais.

Depois passamos a temas muito mais sérios como o hype do labrute entre outros

Eu, Vitor Hugo e Paulo Farine compartilhamos as experiências de blogueiros, discutindo o público que abrangimos, o tema, o interesse e potenciais dele.

Ok, pulando a parte chata,  TIVEMOS A PRESENÇA DE UMA GAROTA =D

O que deu pra ver por lá foi que tem muita gente em Londrina que gosta desse assunto, mas não se conhece e acaba simplesmente chupinhando os eventos de SP e região.

Consideremos que da galera que foi, cada um conhece uns 3 ou 5 amigos que curtem isso mas acabaram não podendo ir, e assim por diante. Esse bate-papo vai crescer e já temos a data do próximo!

No sábado, dia 22/11, no Fran’s Café

NerdsOnCoffel #2!

Apesar de algumas pessoas dizerem o contrario (em alguns pontos com razão), as possibilidades com o SearchMonkey são muito maiores do que se espera de um produto que abre ao usuário a customização dos resultados de busca. Com tantas possibilidades eu só fui descobrir algumas coisas agora, um tempão após o evento terminar.

Abaixo as 3 extensões que fiz entre ontem e hoje (para adicionar é necessário estar logado no Yahoo!).

GitHub

Adicionar

MySpace

Adicionar

Downloads

Adicionar

Mas a melhor de todas que vou mostrar não foi feita por mim. O Maurício vem trabalhando a algum tempo em cima dessa que ruleia bastante:

BuscaPé

Adicionar

Se você possui dados valiosos na aplicação, acredite, as pessoas vão querer ler e mesclar esses dados dentro de novos aplicativos. Não adianta fazer nada, por que a questão é justamente “o que você deixou de fazer”. Eles fizeram.

O lado bom é que as vezes (muitas vezes) eles podem pagar por isso. Eles podem comprar a sua empresa só para agregar o valor do produto (dados). Podem te pagar pagar mensalmente pelos dados. E ainda existe o caso no qual a empresa pode recompensar quem usar sua API (se isso agregar valor de alguma forma ao produto, ou o tornar real).

Mas aqui tem um problema. Um problema que fica imperceptível aos olhos de pequenas aplicações mas que fica claro em robustas (pense no Twitter): são muitos dados para buscar e muitas requisições para responder.

No caso do Twitter, mesmo quando eles haviam entendido a aplicação como um sistema de entrega de mensagens assíncronas e então resolvido os problemas com leitura/escrita e locks na base de dados, faltava-lhes algo. Eles sabiam que estavam somente começando a enfrentar o problema de escrita/leitura de uma grande quantidade de dados ao mesmo tempo. Tanto que compram logo o Summize que tinha um estrutura e melhor experiência para lidar com esse tipo de problema.

Particularmente eu acho muito mais importante entender ferramentas como o Hadoop e/ou CouchDB do que depender da quantidade de memoria da maquina de MySQL, de sharding ou de cluster. E provavelmente foi isso que o pessoal do Twitter fez, provavelmente era isso que o Summize tinha e vendeu: conhecimento em sistemas distribuídos para web.

Mas voltando ao assunto principal: API.
Se sua aplicação vai ser digamos que o novo Submarino. Digamos que no meio da crise você consiga até comprar a B2W (empresa responsável pelo Submarino). Por que você deveria se preocupar em fazer uma boa API?

Ah… é um e-commerce. Não é nenhuma dessas aplicações novas da Web. Pra que RSS? Pra que API?

Eu digo por que: se você não fizer um RSS ou uma API, as pessoas irão partir para ignorância.
Repito: se você está expondo dados de alguma forma na web, não tem como impedir que eles não sejam extraídos para uma outra aplicação. Screen Scraping é uma arte antiga e fácil.

E aqui você tem um grande problema: como você não planejou esse tipo de acesso (bots acessando muito frequentemente o seu servidor), você vai ter problemas decorrentes da falta de planejamento.

Que eu saiba somente um grande (e antigo) player da Web brasileira está desenvolvendo uma API para um grande estoque de produtos. Essa é a chance da sua solução de e-commerce ter algo competitivo com esses caras: faça uma API rapidamente. Procure por algum protocolo aberto para o seu modelo de API (API de fotos, API de produtos, etc) e desenvolva essa área. Se você fizer algo, por favor deixe-me ficar sabendo. Eu quero o maior número de API de produtos que vocês conseguirem me dar e prometo que retribuo

Só para reforçar a importância que uma API tem, dê uma olhada na qualidade da documentação que o Twitter disponibiliza para sua interface de aplicação. Reparem na quantidade de dados que é possível retirar com uma só requisição… totalmente excelente!

Desculpas para quem leu a versão zuada que foi no RSS antes. Publiquei antes de assar

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

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

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.