um pluguinho
Archive for June, 2008
Vamos ajudar na tradução do livro Why’s (Poignant) Guide to Ruby
Jun 24th
Bom pessoa o Carlos Brando pede neste post por ajuda para terminar a tradução do livro Why’s (Poignant) Guide to Ruby.
Quem souber inglês o suficiente e queira participar veja-la como é fácil fazer. Eu não estou ajudando na tradução porque não domino inglês o suficiente o que pode atrapalhar em vez de ajudar, mas estou aqui fazendo minha parte e pedindo ajuda a quem puder, se assim como eu não pode ajudar na tradução, ajude-nos a pedir ajuda 
Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
Jun 24th
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe – quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!
Webkit no maemo
Jun 14th
No projeto que começamos no fisl, o odfmobile, optamos por utilizar a engine Gecko do projeto Mozilla, para trabalhar a exibição dos documentos. O uso desta se deu através da biblioteca gtkmozembed para python.
A opção de usar o gtkmozembed foi mais por questão de tempo, e por consequência, disponibilidade da api, já integrada ao python. Mas depois de um tempo pesquisando sobre o desenvolvimento para plataforma maemo acabei esbarrando neste post. Lendo isso e tirando como base o navegador do N800 e do iPhone, fiquei me perguntando se o Webkit não seria uma opção melhor ao Gecko.
Para ter uma ideia do que seria melhor, resolvi baixar e compilar o Webkit para o maemo e ver no que dava. Então vamos aos passos para testar o Webkit no maemo, vou considerar que você já saiba com ter SDK do maemo em sua máquina e que esteja familiarizado com o mesmo.
Instale o m4:
> apt-get install m4
Depois baixe e instale os seguintes pacotes no seu scratchbox:
- http://www.atoker.com/webkit-maemo/flex_2.5.33-12_armel.deb
- http://www.atoker.com/webkit-maemo/gperf_3.0.3-1_armel.deb
- http://www.atoker.com/webkit-maemo/libicu36_3.6-2_armel.deb
- http://www.atoker.com/webkit-maemo/libicu36-dev_3.6-2_armel.deb
Existe duas maneiras de obter o Webkit, e elas estão descritas neste link.
Uma vez que tenha obtido o WebKit, rode o comandos:
> CPPFLAGS="-DMOBILE=1" ./autogen.sh --prefix=/opt/webkit --enable-video --disable-xslt --with-hildon
> make && make install
> make && make install
Ele deve criar uma pasta em /opt/webkit, para testar se deu certo a nossa instalação, vamos compilar um simples navegador feito em C.
> wget http://www.atoker.com/webkit-maemo/hildon-browser.c
> PKG_CONFIG_PATH=/opt/webkit/lib/pkgconfig:$PKG_CONFIG_PATH gcc -o hbrowser hildon-browser.c `pkg-config gtk+-2.0 hildon-1 webkit-1.0 --cflags --libs` -Wall
> PKG_CONFIG_PATH=/opt/webkit/lib/pkgconfig:$PKG_CONFIG_PATH gcc -o hbrowser hildon-browser.c `pkg-config gtk+-2.0 hildon-1 webkit-1.0 --cflags --libs` -Wall
Uma vez feito isso podemos transferir os arquivos para o dispositivo e testar, copie a pasta /opt/webkit para o /opt do seu dispositivo, depois copie o hbrowser para onde desejar. Antes de testar instale a biblioteca: libicu36_3.6-2_armel.deb, que já foi citada acima, no seu dispositivo.
Para rodar o hbrowser faça:
> LD_LIBRARY_PATH=/opt/webkit/lib:$LD_LIBRARY_PATH run-standalone.sh ./hbrowser
Nenhuma das tarefas a cima são triviais, mas isso são apenas os primeiros testes, partindo do principio de que funciona, posso fazer mais testes sobre a performance e estabilidade de Webkit no maemo.
Aguardem em breve mais novidades!!
Passenger versos Thin
Jun 9th
Depois ler sobre o Passenger varias vezes no site do Akita, e utilizar ele na minha maquina para o desenvolvimento da aplicação de e-commerce, resolvi fazer alguns benchmarks e vê como ele se saia comparado ao thin.
Os testes a seguir foram executados com a aplicação em environment production, eles caem consideravelmente quando em development:
No / do site:
Thin (MRI) – Produção: 3.68 [#/sec] (mean)
Thin (Ruby Enterprise): 6.72 [#/sec] (mean)
Passenger (Ruby Enterprise): 2.64 [#/sec] (mean)
Em uma página secundaria de produto:
Thin (MRI): 19.11 [#/sec] (mean)
Thin (Ruby Enterprise): 36.49 [#/sec] (mean)
Passenger (Ruby Enterprise) : 5.53 [#/sec] (mean)
Com esses testes descobri algumas coisas:
- Que minha aplicação esta incrivelmente lenta, 6.77 (o melhor resultado) é inaceitável, preciso melhorar muita coisa para chegar onde preciso.
- O Passenger, pelo menos por hora, só compensa no ambiente de desenvolvimento, pois evita ter que ficar levantando processo para testar as aplicações. obs: isto é para a minha aplicação, para sua pode ser completamente diferente.
- Vou trocar o ruby do servidor de produção pela versão “Enterprise”, os resultados são sem duvida motivadores, a diferença no caso da página de produtos foi gritante.
O resultado não quer dizer absolutamente nada sobre o Passenger, se é ou não mais rápido para todos os casos, isto pode, e vai variar muito de aplicação para aplicação, principalmente no meu caso onde a aplicação ainda não passou por nenhum refatoramento nem um analise profunda de performance.
Além dos testes com a página inicial e com a página de produto, fiz um teste com arquivo estático, uma imagem para ser mais preciso, e deixo um aviso os mais eufóricos, o Passenger, sem a correta configuração pode ser um problema com os arquivos estáticos. A questão esta no fato de que apenas a configuração básica da aplicação no apache faz com que o arquivos estáticos sejam servidos através do ruby o que da um perda de desempenho em responder a esse tipo de arquivo violenta, o certo e fazer como é descrito na tópico 5.3.3 do manual do Passenger.
Pelo menos no meu caso a melhor maneira de servir arquivos estáticos tem sido a configuração do Apache para não passar a requisição das pastas estáticas para os cluster thin. Usando a opção “ProxyPass /images !” o Apache não envia a requisição dos arquivos no caminho /images para o cluster, o que evita processamento dos arquivos pelo ruby.
Meu grande problema agora vai ser refatorar aplicação, fiquei decepcionado em saber que do jeito que esta, estou com uma média de 3.68 [#/sec], isso é muito baixo, e depois do lançamento oficial dos sites pode ser um grande problema 
Asset Packger e o problema com pontos
Jun 9th
Como disse no post anterior estamos trabalhando o jQuery e Asset Packger. So que existe um pequena incompatibilidade entre esses dois.
O Asset Packer tem um pequeno bug que dificulta na hora de trabalhar com arquivos javascript ou css que tenham ponto no nome, como em Jquery-1.2.3.js. O que acontece e que ele usa a função File.extname, que busca pela extensão de um arquivo dado seu nome completo. Então quando você insere no arquivo de configuração do Asset como: jquery-1.2.3, ele interpreta que a extensão desse arquivo já foi digita, e que ela é .3, inserido o arquivo com o nome errado no cabeçalho da página.
Um solução é adicionar o nome completo do arquivo: jquery-1.2.3.js, isso funciona, mas apenas em modo desenvolvimento. O Asset Packger compila todos os arquivos de um grupo em um único arquivo, mas a função que processa os arquivos no helper e no compile são diferentes, sendo que o compile não verifica se já existe um extensão no nome do arquivo, ela apenas julga que é necessário adicionar o .js na hora de incluir os arquivos na compilação.
Para resolver esse problema eu fiz um fork do projeto no Github e corrigi com um pequena modificação.
jQuery e Asset Packager
Jun 9th
No projeto de e-commerce que estou trabalhando, estávamos com um problema de sobre peso nas páginas, chegando inclusive a 1.4 MB em algumas partes do site.
O principal motivo desse peso todo eram as imagens e banners, como em quase todo site, uma vez resolvido este problema também tivemos problemas com a biblioteca de Javascript: o Prototype. Que o Prototype é gordinho, quase todo mundo já sabe, a questão era como resolver isso. A resposta veio com o jQuery, uma biblioteca Javascript infinitamente superior tanto em recursos como no fato de oferecer versões compactas das bibliotecas que a constitui.
Antes de tentar o jQuery, experimentei usar algumas ferramentas de “compactação” para Javascript, a mais conhecida foi o YUI Compressor, a ferramenta padrão de compressão do projeto Mootools, mas não obtive sucesso, a compactação não funciona com a Prototype, o código final gerado é invalido, e não há muito o que fazer, o problema esta na maneira com que a Prototype foi feita.
Então depois de alguns dias de pesquisa e substituição, consegui achar todos as funcionalidades e bibliotecas equivalentes para o jQuery, uma vez feita a substituição lembrei de plugin que já tinha visto para Rails que podia deixa a coisa ainda melhor.
O Asset Packer é um plugin para auxiliar na utilização de Javascript e Css, com base em um arquivo de configuração pode-se definir pacotes de css ou javascript, da-lhes um nome, e depois incluir esse pacote com apenas um chamada, além disso ele conta com um tarefa rake que permite gerar uma versão compacta dos pacotes.
O grande atrativo do Asset Packer, e que ele inclui o javascript ou css em sua forma descompactada ou compactada de acordo com environment, permitindo ao desenvolvedor trabalhar com os códigos sem compactação durante a fase de desenvolvimento e inserindo as versões compactadas quando em fase de produção. Além destes recursos o Asset Packer ainda trabalha junto ao controle de versão (infelizmente por enquanto apenas com Subversion) e pode ser configurado para gerar as versões compactadas diretamente no servidor, através de configurações junto ao Capistrano.
