um pluguinho
Desenvolvimento
Plugin tabs extend para gedit
Dec 10th
Já faz um bom tempo eu venho pensando em melhorar o gedit com algumas coisas que eu sinto falta. Para isso estou construindo uma lista de coisas que gostaria que fosse adicionadas ao editor, e agora vou começar a tirar um tempinho para implementar essa lista.
O primeiro pacote de funcionalidade vem com o plugin tabsextend, com os seguintes recursos:
- Fechar a aba com o botão do meio do mouse, ou com os dois botões se esta opção estiver configurada no seu X;
- Desfazer o fechar de uma aba, parecido com o Firefox. Fechou uma aba? Não era isso que queria? Ctrl+Shift+T e ele vai reabrindo as abas fechas na ordem em que foram fechadas;
- Fechar todas as outras abas menos a atual. Com atalho de Ctrl+Shift+O
- Menu para as duas opções acima e mais a opção de fechar todas as abas (Ctrl+Shift+W) no menu da aba, essa opção parece um pouco besta pelo fato de já existir os atalhos, mas as vezes eu sinto falta e tirar a mão do mouse nem sempre é a opção mais rápida
Para instalar baixe este pacote e extraia os arquivos na pasta ~/.gnome2/gedit/plugins.
Bom é isso, espero que o plugin posso ajudar aguem, instalem, testem e se possível dêem um feedback, que eu fico agradecido!
obs: Jayme seu plugin de fechar tags no html vai sair, tenha um pouco de paciência, rsrs
Ordenando a lista de opções no plugin activerecord_symbolize
Nov 14th
Ainda na continuação do post anterior, a troca de idéias com o Cássio acabaram por render mais frutos para o plugin.
Já tinha tempo que eu estava precisando de uma forma de ordenar as opções que no select ou radio gerado pelos helpers select_sym e radio_sym respectivamente. O problema era que o plugin trabalhava com o arrays simples ou com hash para estabelecer os valores possíveis para o atributo.
Bom como hash não tem um ardem certa em que os seus valores possam ser capturados, uma vez que ele seja definido, um simples each sobre o hash pode trazer seus valores em qualquer ordem.
Então agora o plugin conta com a opção de usar um matriz para definição dos valores, mantendo a opção de array simples e hash, sendo que no primeiro é mantido a ordem na qual os valores são definidos e no caso de hash é retornando em ordem alfabética. Vamos há alguns exemplos para claria as idéias:
Então para a definição de model acima, temos o seguintes resultados na view:
Observe que no caso do so, a ordem não é a mesma estabelecida na chamada do symbolize, mas sim em ordem alfabética do humanize do atribute, enquanto no caso de office os valores vem na ordem que foram declaradas dentro do array.
Bom é isso, em breve mais uma opção de ordenação, mas por hora espero que esta opção agrade a quem precisar.
Novo atributo *_humanize no plugin activerecord_symbolize
Nov 14th
O Cássio do /* CODIFICANDO */, fez um post dando uma dica de como simular uma funcionalidade de enum no ActiveRecord, para trabalhar com uma faixa de valores em um dos atributos do model. Então dei uma dica para ele do plugin activerecord_symbolize, do qual eu já falei por aqui e acabei por contribui com algumas alterações.
Trocando idéia com o Cássio, ele sugeri o método *_str, para facilitar na hora de transformar a propriedade do model em um valor legível para o usuário. Bom, eu já tinha feito está alteração localmente e acabei por esquecer o commit/push dela.
A diferença do que ele sugeriu para o que eu tinha feito é que dei o nome de *_humanize para o método, o que é mais Ruby mod do que _str, com o _str poderia ser confundido com o método to_str. Passamos a ter:
Com isso espero atender melhor aos usuário desse plugin, facilitando na hora de obter o valor que sera mostrado na view.
Hooks no bash
Nov 13th
Nos últimos dias tenho andado ocupado com muitos projetos e não esta sobrando muito tempo para escrever, e mesmo revisar os posts que já estão escrito aqui para o blog, faltando apenas a revisão e publicação, então vai um pequeno post sobre uma ferramenta para bash programers de plantão.
Estou trabalhando em uma gem que entre outras coisas vai enviar mensagens aos meus contatos de IM de acordo com o comando executado no shell, em breve ela deve ficar pronta e eu dou mais detalhes por aqui. Mas o importante nisso foi descobrir como monitorar o que é executado no shell.
A principio pensei em varias possibilidades, dês de interagir com o kernel em algum nível, para obter os comandos executados ou mesmo fazer alguma gambiarra com o comando “script”, mas quase todas as tentativas me levavam a um problema: como fazer isso de forma transparente e ainda mais importante em Userspace.
Pesquisando, acabei achando um pequeno truque. Neste site há uma explicação de como usar esse “hook” de bash para abrir uma caixa de aviso com Growl no mac (o que pode ser feito no Linux com o notify), para avisar sobre o termino de comandos muito longos.
A configuração é bem simples, basta baixar para o seu home dir o arquivo http://www.twistedmatrix.com/users/glyph/preexec.bash.txt e adicionar ao seu bash a chamada: “. ~/.preexec.bash”, feito isso você define duas funções a preexec e a precmd, funções que são chamadas antes do comando e depois do comando respectivamente.
As aplicações para este hook são quase que infinitas, mas atente para o fato de que isso aumenta o tempo de execução de um comando, pois ela trabalha em cima de todos os comandos que você executar em shell.
obs: Obrigado ao meu amigo Cássio pelas longas horas perdidas atrás dessa inhaca, se ele tivesse um blog eu linkaria aqui!
activerecord_symbolize a solução para o seus problemas
Aug 19th
Um dos erros que cometi quando comecei a desenvolvimento da loja foi usar o tipo enum do banco de dados mysql em algumas tabelas. O erro foi agravado pelo uso do plugin enum-column que adicionar suporte a esse tipo de coluna no ActiveRecord.
O problema se concentra no fato de que o tipo enum não é suportado por todos os bancos de dados, o que impede a migração da aplicação para outro tipos de banco que não sejam mysql. O plugin agrava o problema, não por si só, mas pela falta de atualização.
A partir do Rails 2.0 temos as sexy migration, por isso na criação de uma tabela usamos:
Isso adiciona um coluna do tipo enum no banco de dados, mas atualiza o arquivo schema.rb de forma errada, observe o código abaixo do arquivo schema.rb:
Não existe o método enum para class ActiveRecord::ConnectionAdapters::TableDefinition, o que gera erros quando usamos o schema.rb para criar o banco de dados, o que acontece sempre que rodamos testes por exemplo. A solução para este ultimo problema seria atualizar o plugin, mas ainda sim teríamos o outro problema.
Pensando nisso fui no github atrás de um plugin alternativo, acabei por encontrar o activerecord_symbolize, um plugin que na sua versão básica adiciona o suporte a atribuição de tipos simbólicos as propriedades de um modulo.
Mas lendo a documentação e testando o plugin acabei descobrindo que ele seria pouco para o que queria, por isso fiz um fork do projeto e adicionei algumas características ao plugin. Já fiz um pedido de pull para o projeto original e estou aguardando para ver se minhas modificações são aceitas. Enquanto isso vamos a forma de utiliza-lo.
Para instalar o plugin pode ser fazer o básico:
script/plugin install git://github.com/nuxlli/activerecord_symbolize.git
Na sua tabela usasse tipo string mesmo:
No seu model adicione:
Feito isso, User passa aceitar apenas os valores :female e :male para o atributo gender, gerando um erro de validação caso algum outro valor seja passado, o mesmo acontece com so. Se o symbolize fosse chamado sem a definição de in ele passaria a aceitar qualquer simbolo sem erro de validação.
Um outro recurso que adicionei foi dois helpers para facilitar na hora de criar formulários, ficando assim:
Com isso já se obtém dois campos radios para escolha do gênero e um select para escolha do SO, sendo que suas opções são puxadas diretamente da definição do symbolize.
Para mais informações: activerecord_symbolize
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:
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:
> 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.
> 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:
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.
Arena de programação
May 21st
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