Vamos ajudar na tradução do livro Why’s (Poignant) Guide to Ruby
Posted on June 24, 2008, under Ruby/Rails.
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!
Posted on June 24, 2008, under Uncategorized.
…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
Posted on June 14, 2008, under Desenvolvimento, N800, Uncategorized.
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
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
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
Posted on June 9, 2008, under Desenvolvimento, Passenger, Ruby/Rails.
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
Posted on June 9, 2008, under Desenvolvimento, Ruby/Rails.
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
Posted on June 9, 2008, under Desenvolvimento, Ruby/Rails.
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.
Definitivamente de volta a terrinha
Posted on May 29, 2008, under Uncategorized.
É isso pessoal, depois de 3 anos e meio morando em Curitiba estou de volta a Patos de Minas. Saudades de Curitiba não vão faltar, foram 3 anos de muitas felicidades, amigos e aprendizado.
A explicação para essa guinada na vida são muitas, primeiro que o projeto em que estou trabalhando esta começando a render seus frutos, o que por si só já seria motivo o suficiente para voltar. Mas além disso a saudade da família e da terra bateu, Curitiba é um cidade maravilhosa e diferente do que muitos falam, seu povo e receptivo, basta saber chegar e conversar 
Infelizmente não consegui terminar a faculdade em Curitiba, o que não chega a ser um problema, aqui em Patos tem dois cursos de informática e todos me agradam. Graças a tecnologia a vida muda pouco, o acesso as informações é fácil tanto quanto era em Curitiba, e agora que conheci um pedaço do Brasil viajar se tornou ainda mais divertido, com certeza minhas viagens para treinamento, palestras, eventos e cursos pelo Brasil devem aumentar.
Eu diria que Patos é uma Curitiba em miniatura, as coisas aqui são boas, a cidade é limpa, organizada, e tem algo que me agrada mais do que em Curitiba: as festas, ainda não estou participando de nada, o tempo não tem permitido, mas com certeza neste requisito a coisa e mais animada por aqui.
E vamo que vamo…
Arena de programação
Posted on May 21, 2008, under Desenvolvimento, N800, Uncategorized, fisl.
Depois de um mês do fim do fisl 9.0, finalmente sobrou um tempo para falar sobre a Arena de Programação, acompanhado do fato de que o N95, um dos prémios da arena, chegou hoje pela manha
Para quem não sabe a arena é um evento que acontece dentro do fisl, sendo este o segundo ano de arena, e esperamos que muitos outros ainda venham. O objetivo geral da arena é promover a integração entre os programadores do mundo livre e gerar algum tipo de contribuição com essa integração. No ano passado tivemos uma arena voltada ao projeto Debian, e esse ano ao projeto Gobo Linux e a plataforma de desenvolvimento móvel da Nokia.
Na primeira fase tivemos um processo de seleção com base em patch que deveriam ser feitos para o projeto Gobo Linux, mais informações aqui. Graças ao fato de que o número de inscrições nesse processo foi aquém do esperado, eu pude participar, meus patch foram enviados com 1 semana apenas de antecedência.
Já no primeiro dia de arena a coisa pegou fogo, fomos divididos em grupos de 4 programadores, e cada equipe recebeu um N95, onde constavam uma lista de tarefas a serem executadas com o aparelho usando python. Terminei este dia frustado, tínhamos feito muita coisa, mas nada tinha ficado realmente pronto e funcional, ficamos com um tarefa pronta, e todas as outras semi acabadas. Fui pro hotel cabisbaixo e pronto pra receber a notícia de que não havíamos nos classificado.
Passei uma noite de cão, pois decidi que não ia deixar aqueles códigos besta me vencer, como tinha instalado o emulador da plataforma S60 um domingo antes de ir para o fisl, resolvi que faria o que não consegui fazer durante o dia, obs: isso não contava em nada, fiz porque era um desafio que deveria ser vencido, mas não iria mudar a decisão do dia seguinte.
Na manha de sexta estava lá as 9:00, cansando pra caramba da noite anterior, mas ainda sim tive um tempo pra fazer mais alguns testes e refinar as tarefas que eu tinha feito durante a noite. No fim consegui terminar uma das tarefas e desenrolar uma outra, de um joguinho, mas como o emulador não tem suporte ao acelerómetro, o joguinho ficou só na teoria de que funcionaria.
Qual foi a surpresa de saber que nossa equipe tinha classificado, os códigos que entregamos mesmo na sua maioria incompletos, estavam dentro do esperado, de fato tínhamos feito um bom trabalho. Foi uma grade satisfação saber que todo o trabalho que tinha feito a noite anterior, não tinha sido em vão, ninguém da organização ficou sabendo sobre isso, mas pessoalmente teve um imenso valor.
Eu não sou de forma algum experiente em programação em Python. Eu trabalho com programação a uns 10 anos, mas Python nunca foi o meu forte, mesmo com várias semelhanças com Ruby, que tem sido minha linguagem principal nos últimos meses, o Python era de certa forma um obstáculo.
Mas as 24 horas que passei programado, 12 da quinta feira, e mais 12 da noite que virei programando, com certeza me preparou pra o trabalho que veria em seguida. Então, logo após o anuncio de quais as equipes que tinha se classificado ficamos sabendo que as equipes deveriam se re-arranjar em grupos de três.
Minha equipe mudou e passei a trabalhar com dois programadores de Joeville, nem sabia eu que essa seria a equipe vencedora. Recebemos um N800 e a árdua tarefa de criar um leitor de ODF para o aparelho, usando pymaemo.
A tarefa em si não seria complexa, não fosse o tempo pra programar. Levando em conta que os aparelhos só ficaram disponíveis lá pelas 12h da sexta feira e que teríamos que entregar de volta ás 21h, e que no sábado teríamos mais umas 4 horas para termina o trabalho, ficamos com umas 13 horas de aparelho disponível para trabalhar.
Novamente mais um dia puxado de trabalho, pegando um pouco mais leve, afinal eu estava a mais de 24h sem dormir e com um agravante que quase ninguém sabia, eu passei por um cirurgia de apendicite no final do mês de março, e ainda não estava completamente recuperando, inclusive tendo que trocar curativos.
Mais um dia se foi e muito trabalho ainda tinha que ser feito, uma vez definido o caminho que queríamos seguir o trabalho estava nos trilhos, mas ainda longe de ser concluído. Novamente fui para casa e para mais algumas horas de trabalho noturno, cheguei no hotel tomei um banho e dei um tempo comendo uma parmejiana com amigos no Copão. De volta ao hotel passei mais uma noite em claro estudando pra o dia seguinte, como não tinha o aparelho, e dessa vez nem o emulador, passei a noite estudando sobre xslt (que estávamos usando na solução) e mais um pouco sobre Python e as bibliotecas que estávamos usando.
No dia seguinte a coisa foi um susto, em menos de 4 horas conseguimos juntar o trabalho que os três estavam fazendo e fazer um programa funcional a tempo de entregar, nossa estratégia se mostrou eficiente, pois mesmo trabalhando separados, estávamos sempre trocando ideia sobre o todo. Cada um pegou seu pedaço e trabalhou firme nele.
As horas seguintes ao fim da arena foram as mais duras que já passei, tínhamos que esperar das 12h até as 20h, quando aconteceria o encerramento do fisl, e teríamos o anuncio do resultado. Eu estava tremendamente cansado, com mais de 48 horas de olhos abertos, mas nem tentei deitar em um cato e descansar, estava ansioso d+ para isso.
As 19h rolou uma apresentação das equipes finalistas, falamos sobre nossas soluções, e fizemos um pequeno momento de reflexo sobre a possibilidade de continuar o projeto que tínhamos começado ali. Passado isso fomos andando para o teatro principal para o encerramento do evento, as borboletas no estômago já estavam do tamanho de elefantes, e a ansiedade de saber o resultado era visível no rosto de cada participante que tinha chegado ate ali.
Como sempre o anuncio dos vencedores começou pela ordem inversa e os ganhadores do terceiro e segundo lugar foram anunciados por primeiro. Neste 2 minutos que dura entre o anuncio do segundo lugar e o primeiro existe um vazio na cabeça de quem espera o resultado que é indiscritível, afinal, ou foi tudo ou foi nada, e as chances em números são as mesmas para os dois lados. Então o anuncio do vencedor e algo que não se pode dizer em palavras, ficamos tão feliz que pulamos os três abraçados por um longo e feliz minuto.
Depois disso a coisa só fica melhor, você leva horas para perceber o que aconteceu, e que você realmente ganhou. Receber o prémio e algo fantástico, mas saber que você deu conta é ainda melhor, e a loucura e algo que domina facilmente a gente nesse momento.
Logo depois de mostrar com toda felicidade o N800 que tinha ganhando ao público, escutei um sonoro “joga, joga, joga!!!”, era uma plateia maravilhada com os prémios, e que clamava de alguma forma pra participar daquilo, não pensei duas vezes, virei para uma mesa, deixei minha sacola, e comecei a desmontar meu W300 na busca pelo chip GSM, que não queria sair de forma alguma, quando consegui arranca-lo do aparelho foi apenas um grito: “PEGUE O CARREGADOR COMIGO DEPOIS”, estava feito, tinha jogado meu celular para plateia que o recebeu com toda a felicidade.
Depois disso veio a entrevista para a impressa, e maravilhosos momentos de comemoração e orgulho da conquista. O N800 foi explorado de todas as formas, e tenho grandes planos de participar do seu desenvolvimento, seja com projetos Open Source ou pessoais. O N95 demorou um pouco para ser entregue, mas finalmente chegou e é outro brinquedo sem igual.
Quanto ao projeto que desenvolvemos para o N800 a coisa esta andando, ainda não temos nenhum release, mas em breve devemos postar alguma novidade por aqui, quem quiser acompanhar o andamento do projeto pode acessar o site do projeto: http://code.google.com/p/odfmobile/ ou ainda o repositório do mesmo: http://github.com/nuxlli/odfmobile
Firefox 3 no Leopard 8)
Semana passada eu falei aqui sobre o que eu acho sobre o Firefox 3 ser o browser padrão do Ubuntu, e agora também do Fedora 9. Mas hoje estou aqui pra elogiar o trabalho que estão fazendo no Firefox, não se preocupe eu também me acho maluco por ter opiniões tão divergentes de mim mesmo 
Hoje resolvi testar o FF 3 no Leopard, e só posso dizer uma coisa: ficou do c….., sério, estou espantado ate agora, como eles trabalharam bem em cima da compatibilidade visual com os SOs. No Linux com Gnome essa melhora e pouco perceptiva, principalmente pelo Firefox já ter uma cara de aplicação gtk.
Mas no Leopard isso ficou muito bem feito, o navegador se adapta ao visual do SO muito bem. Destaque para os botões de navegação e para abas. Mas as melhorias não ficam só nisso, anteriormente eu tinha usado a linha 1.5 e 2 do navegador no Mac, dava uns problema de renderização que faziam aparecer manchas e objetos perdidos pela tela, nunca vi ninguém reclamando disso, mas nunca funcionou bem pra mim.
Agora esta tudo 100%, mesmo na versão beta, estou usando desde de ontem a noite e só tive um crach, e foi com o youtube aberto, coisa que acontece com certa frequência e todas as versões do ff que já usei.
Eu ainda continuo achando que colocar um software ainda em versão beta em um trabalho dito final é um erro, mas só tenho elogios ao Firefox 3.
Bem vindos ao novo endereço
Posted on May 14, 2008, under Uncategorized.
Bom pessoal depois de muito pensar (que nada decidi em duas horas), resolvi registrar o domínio e mudar de casa.
O wordpress.com foi uma boa, mas ele é limitado em termos de recursos e não te oferece todo o poder do Wordpress, então, aqui estamos com um novo visual e hospedando no VPS do projeto Shopcerto (qualquer dia desses falo sobre o projeto).
Espero escrever mais, e escrever bem, tenho lido os posts anteriores e ainda tem muito a caminhar.
