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

Eu já queria ter falado sobre ambientes virtuais, a volta do conteúdo baseado em navegadores e Flash antes, mas o que dessa vez me fez vim correndo escrever foi ver 2 serviços de ambientes virtuais como o SmallWorlds e ExitReality e também o lançamento do Google Earth para navegador voltando a ter destaque no TechCrunch.

Com toda a atual “facilidade” para se fazer 3D no Flash eu me perguntava (na verdade ainda me pergunto) qual o motivo de não existir algum Second Life-like utilizando a tecnologia que está presente em 98.8% dos navegadores para desktop.

Agora as coisas parecem pegar fogo nessa área e uma ou outra inovação acaba ultrapassando a barreira de suporte tecnológico e necessitando de plataformas diferentes das atuais. O que é um grande problemas, pois algumas dessas inovações podem se tornar tão importantes (talvez pelo nome de quem as lança) a ponto de levarem a Web para outra briga de navegadores ou algo parecido…

Na verdade duvido que outra briga de navegadores possa ocorrer. Hoje provavelmente existem mais pessoas evitando que isso ocorra do que o contrário. Desde w3c até Microsoft. (Pasmem, a Microsoft possui uma página sobre Acessibilidade.)

Mas, por exemplo, se o Google Gears não fosse a maravilha de um plugin para Firefox, ele poderia se tornar facilmente um novo navegador. Afinal, com suporte a SQLite, servidor local de arquivos e possibilidade de fazer grandes processamentos na maquina cliente quem não diria ser esse o navegador do futuro?

Por sorte ele é implementado como uma “especificação de API”, ou seja: os desenvolvedores podem implementa-lo facilmente em qualquer plataforma. Com isso até o pessoal do Opera disse que a sua próxima versão (9.5) irá suportar o middleware de navegação offline do Google.

Voltando ao ambiente 3D e ao que isso tem a ver com a rápida evolução dos navegadores e o perigo da falta de padrão entre eles: boa renderização 3D com suporte a protocolos http/https é exatamente onde os navegadores atuais pecam e não parece existir um consorcio de Web 3D que possua um bom e grande padrão.

Por sorte, ao mesmo tempo, parece surgir uma grande comunidade Open Source em volta do Flash e a recente escolha da Adobe em abrir as especificações dos formatos SWF and FLV/F4V pode levar a tecnologia para outro caminho, o de plataforma de ambientes virtuais.

Com a falta de um padrão para renderização 3D nos navegadores, o Flash pode ser uma excelente alternativa. Com a grande adoção que o Flash já possui na Web creio que utilizar todo o ambiente de desenvolvimento é uma melhor solução ao invés de reiventar a roda e basear aplicações em navegadores específicos ou novos plugins.

Se você tiver a próxima “big ideia” da Internet, tente nunca depender de barreiras tecnológicas como navegadores ou e até mesmo depender da instalação de um plugin para um browser especifico. Padrões e plataformas abertas de grande adoção estão ai justamente para evitar esse entraves técnicos!

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.