Recentemente entrou em produção a nova versão do BuzzVolume. Sob o capô o “noSQL” Cassandra substituindo o antigo MySQL + Memcached. Sem processamento na base de dados e com um data store que substitui o memcached diminuímos o tempo de absolutamente todas páginas para bem pouco.

Alguns componentes estão sendo feitos em Node.js – HTTP request no meio da aplicação por exemplo – Para começar, não fazemos mais, mas em um caso extremo, enquanto o Ruby (Sinatra+Thin) chora o Node.js consome toda banda e serve vários clientes ao mesmo tempo que baixa as páginas.

A URL http://google.com/phone é legal. Não só isso é legal no celular do Google.

Finalmente o Android ficou pronto a ponto do Google anunciar publicamente sua marca junto a HTC, fabricante dos aparelhos. Alguns destaques do NexusOne:

Search do Google por voz (GPS + voz, na verdade, o que possibilita você falar “pizza” para o telefone e ele te mostrar no Google Maps o caminho às pizzarias próximas).

Hardware e resolução de tela (800×480) para rodar jogos muito melhor que qualquer PSP e o marketplace para baixar legalmente jogos muito melhores até que jogos de PS2. Tudo pelo 3G.

Marketplace dos modelos anteriores da HTC que rodam Android, com mais de 20 mil apps prontas para rodar no telefone do Google (Android 2.1).

Aparelho fino (1,19cm).

E o mais importante para os devs: SDK simples e publica.

Veja também sobre o Zeebo, um video game da brasileira TecToy que tem um Android dentro e os jogos são baixados pelo 3G.

Um dia o Mafra mandou um e-mail interessante. O plano era ficar milionário com um aplicativo de iPhone. Eu não tinha o aparelho e também não fazia parte do Apple Developer Program.

No Simulador comecei a fazer algumas brincadeiras com PhoneGap que poderiam um dia se tornar o aplicativo pronto. Não me preocupei com o problema que o PhoneGap enfrentou na App Store e continuei implementando o que precisava em JavaScript.

Quando implementei em JS uma copia do componente de DatePicker da SDK do iPhone ficou claro que eu teria que deixar o PhoneGap de lado e me apoiar em algo mais robusto.

O Cocoa tem suas peculiaridades mas depois que se aprende a ler e brincar com o Objective-C nos exemplos da Apple, tudo fica mais fácil.

Minha App se tornou um frankenstein. Em partes roda no WebKit (HTML/CSS/JS) e onde algo se move rápido na tela usa as animações da SDK.

Mas não é só na velocidade que o desenvolvimento com PhoneGap pode limitar o que o aplicativo pode fazer. Fazer requisições HTTP é complicado com as restrições impostas no navegador com o sentido de evitar cross-domain HTTP.

Código Objective-C pode ser usado para permitir chamadas em funções da SDK via JavaScript. Na verdade para mim é isso que resume o PhoneGap.

AlarmGame

O aplicativo tinha poucas funções programadas e não tinha nome definido ainda quando o @laka começou a desenhar e a criar o visual para ele. Foi nesse dia que fiz a inscrição para o concurso ARENA INFO. Concorreríamos na categoria iPhone. O premio: R$1000 para os primeiros de cada categoria e uma viagem a NY + U$2000 para o primeiro geral.

Em vez de tentar vender um aplicativo que não funciona*, tentei ir para NY na faixa.
Não deu certo. O aplicativo não foi classificado para a última fase de concurso.

Não vou ficar milionário nem ir para NY, mas fico feliz se você baixar o aplicativo.

Na próxima versão vou apostar no Admob.

*A SDK do iPhone não tem uma API de Alarm como o Palm Pre tem, fazendo com que para usar o despertador o aplicativo não possa ser fechado.

Eu precisava de uma maneira de exibir um conteúdo na tela do iPhone/Touch sempre do mesmo tamanho, independente do zoom usado no navegador (Safari/Webkit).

Então pesquisei algumas propriedades da tela e cheguei ao JavaScript que pode ser visto em ação aqui: iPhone Viewport/Zoom Test.

No aparelho ou no simulador tente dar zoom na imagem e você vai perceber que ela continuara do mesmo tamanho na tela.

Ninjas JS: fiquem a vontade para ganhar dinheiro a partir desse exemplo.

Na última semana reuni vários novos skills de desenvolvimento para iPhone. Não foi fácil. O pessoal que desenvolve para a plataforma parece que não curte muito compartilhar o que sabe… foda…

Seguindo a dica do @evertonfraga fui dar uma brincada com um plugin do jQuery que facilita a diversão com as funções de touch (touchstart, touchend, touchmove) e com a API de gestures (gesturestart, gesturechange, gestureend): jQuery Touch.

O problema é que versão original tem algumas cagadas jumentais.

O cara chamava N! vezes a função $() do jQuery e isso deixava o Safari puto (digo, muito lento).

Uma das utilizades da “função $()” do jQuery é buscar um elemento na página.

Na mais rápida das hipóteses, a busca pode ser feita pelo id, tipo $(’#content’), o que vai encadear uma chamada ao método document.getElementById(’content’) do navegador.

No WebKit/Safari essa função é bem rápida e chamar ela em um computador normal não deve deixar nada lento, mas meu amigo, no iPhone é outra história.

Arrumei rapidinho e agora tudo roda mais suave. Com o tempo devem surgir mais melhoras, mas você já pode se divertir também:

Baixe minha versão
Veja aqui como faz para usar isso

Ontem o desenvolvedor do Thin, Marc-André Cournoyer, lançou o que parece ser um release candidate para a primeira versão estável do seu servidor de aplicações Ruby.

Batizada de “Double Margarita” a versão 0.8.2 não vem com muitas funcionalidades novas mas corrige todos problemas graves das versões anteriores.

Para quem não sabe do que se trata, Thin é um web server Ruby que utiliza o que há de melhor para processamento HTTP no mundo Ruby:

• O Parser do Mongrel, de onde vem toda a velocidade e segurança do Mongrel
• Event Machine, uma biblioteca de network I/O com foco em escalabilidade, performance e estabilidade.
• Rack, a interface (API) entre web servers e frameworks Ruby

Essas características dão ao Thin o posto de “mais rápido que Mongrel com menos memoria que Mongrel”

Veja o artigo que compara Thin e Mongrel de onde reproduzi os gráficos

Porém ainda vejo outra vantagem além da performance atual que é a possibilidade de Thin rodar em Ruby 1.9 desde sua versão 0.5.1, permitindo aos desenvolvedores do “ambiente Thin” (leia-se Merb) desenvolverem suas bibliotecas compatíveis com o YARV (a famosa maquina virtual por trás da performance do próximo Ruby estável). Coisa que Mongrel e o “ecossistema” em volta dele ainda não permite.

Para saber mais:
Página Oficial
Como começar (em ingles)

John Resig criador do jQuery começou outro projeto interessante: um profiler para aplicações que utilizam o jQuery.

A intenção do projeto é criar uma maneira para se analisar a performance da aplicação e então optimizar os métodos com maior custo, mas acredito que saber quais funções foram utilizadas pode também ser útil para filtrar funções não utilizadas na biblioteca e então diminuir o tempo de carregamento e consumo de banda em sites que fazem uso desse incrível framework Javascript.

This evening I was playing around with the idea of profiling jQuery applications – trying to find a convenient way to completely analyze all the code that is being executed in your application. Deep Profiling jQuery Apps

Dharmesh Shah da HubSpot (startup de marketing na Internet) deixa claro em seu artigo “7 Uncannily Obvious Lessons From A Product Launch” o quão rápidas as iterações podem ocorrer dentro do conjunto de metodologias de desenvolvimento ágil de software. Principalmente em ambientes que facilitam tal perspectiva, como na web:

Seja realista na iteração: após os lançamentos eu intencionalmente limpo as pequenas distrações da minha agenda e então posso focalizar no software e iterar, iterar e iterar! Após o lançamento eu reescrevo software loucamente em vários updates diários do ambiente de produção! Nenhum dia pode passar em branco, sem que o software melhore para os usuários. Continue isso sempre que puder, quem sabe semanas ou mêses!

E eu que me achava estúpido por ter feito commit uma vez por dia em um dos serviços da boo-box por quase 2 semanas!

O que penso ser mais interessante do mercado que os americanos estão acostumados é a facilidade de se obter feedback (e a grande utilização do meio). No mesmo artigo Dharmesh diz que para se obter feedback, basta deixar algum lugar onde o usuário possa escrever sobre a ferramenta e clicar em “enviar”. Só isso!

Com o retorno dado pelos usuários a iteração fica mais rápida e produtiva, produzindo sempre um melhor serviço. Além disso, responder os contatos desses usuários enviando a solução para o problema é muito importante. Demonstra respeito pessoal a alguém que lhe fez o precioso trabalho de testar sua ferramenta.