Older blog entries for jarod (starting at number 121)

8 Sep 2008 (updated 3 Oct 2008 at 00:07 UTC) »

Pylons e TurboGears

Alguns dias atrás, alguém fez a seguinte busca no google: "Pylons é melhor do que turbogears?" e acabou caindo aqui no blog. Dizer qual entre dois frameworks é o melhor é uma tarefa difícil, e pode causar convulsões em algum fanboy (talvez não seja o caso, já que ambos estão ficando em segundo plano por causa do Django, ao menos aqui no Brasil). Porém isso não nos impede de dar uma pequena olhada nos pontos em que esses frameworks se diferenciam e onde está o poder de cada um deles.

TurboGears

O TurboGears é um framework construído por diversas partes (ao contrário do Django, onde toda a stack parte de um mesmo lugar). Atualmente, usa o CherryPy, SQLObject para mapeamento objeto relacional, Kid para templates MochiKit para JavaScript e AJAX. O Framework foi criado por Kevin Dangoor, e teve seu desenvolvimento iniciado no começo de 2005.

Pylons

O desenvolvimento do Pylons começou no início de 2006, e tinha como um dos objetivos, na época, ser uma resposta ao Ruby on Rails, tanto que possui alguns componentes portados do próprio Rails, como o sistema de roteamento de URLS e controladores (Routes) e o WebHelpers. Outra decisão que direciona o projeto até hoje é o fato dele dar extremo valor ao padrão WSGI. Atualmente, o projeto está chegando a versão 0.97. O WebHelpers está sendo praticamente reescrito - a geração de código javascript, e as funções link_to_remote, por exemplo, estão caindo em desuso. Segundo os autores, o framework não deve ser acoplado a nenhuma biblioteca JavaScript, até porque elas estão em constante evolução e a biblioteca da vez sempre muda, o que faria com que sempre alguém ficasse descontente por não ter sua biblioteca preferida suportada. Segundo o Charleno Pires, o Pylons é de certa forma semelhante ao Merb (Ruby), ao prover um framework pequeno e bastante personalizavel.

TurboGears 2

Um julho de 2007, uma surpresa aconteceu: após um sprint, o pessoal do TurboGears decidiu implementar o TurboGears 2 usando o Pylons como fundamento (trocando então o CherryPy). Na época algumas pessoas acharam esquisito implementar um framework sobre o outro (porém, o mesmo acontece com zope, ao pesarmos em CMF>Plone>Archetypes), e houve até uma especulação sobre um possível merge dos dois projetos. Porém, os dois projetos tem propósitos e visões diferentes. Enquanto o Pylons é mais um meta-framework, uma base crua sobre a qual idéias podem ser desenvolvidas, o TurboGears já pressupõe que você irá usar um banco de dados relacional (suposição que o Pylons não faz), possui algumas ferramentas para geração de formulários, ou seja, provê de certa forma uma estrada mais pavimentada para o usuário do framework. Você pode encontrar mais informações sobre o porquê desse merge não ter acontecido na documentação do TurboGears.

E o resultado é...

Entender a história dos frameworks, junto com a experiência de uso deles, é a melhor forma de fazer uma boa escolha. Espero ter contribuído com essa escolha ao detalhar um pouco da história desses dois frameworks!

Links

  1. Rum - Um 'gerador de CRUD para SQLAlchemy, feito pelo Alberto Valverde.
  2. Uma introdução ao WSGI - Ian Bicking
  3. WSGI - a resposta para a questão definitiva sobre Python, a web e tudo mais? - Humberto Diógenes
  4. Pylons Book Livro sobre o Pylons (em fase de escrita ainda)
  5. Documentação do TurboGears 2
  6. Documentação da versão 0.97 do Pylons

Syndicated 2008-09-07 18:59:14 (Updated 2008-10-02 17:08:25) from devlog

Notícia recorrente

  1. 2 de junho de 2008: SquirrelFish é a engine de JavaScript mais rápida do mundo!
  2. 22 de agosto de 2008: TraceMonkey é a engine de JavaScript mais rápida do mundo!
  3. 1 de setembro de 2008: V8 é a engine de JavasSript mais rápida do mundo!
  4. 1 de abril de 2009: VeryHotSpot é a engine de JavaScript mais rápida do mundo!

Wacky Races at Goodwood Festival of Speed 2008
Creative Commons License photo credit: Lauri Väin

Syndicated 2008-09-05 20:13:28 from devlog

5 Sep 2008 (updated 2 Oct 2008 at 00:07 UTC) »

V8 x Tracemonkey

Ok, depois de compilar o v8, eu pensei: e agora? Após ler sobre o tracemonkey, minha idéia caiu no seguinte: eu compilo o tracemonkey e faço testes com ambos.

Eu adaptei o shell script que roda o benchmark do tracemonkey para rodar o mesmo benchmark, só que usando o v8.

chrome teste 1

chrome teste 2

chrome teste3

Sobre as duas VMS:

  • O líder do desenvolvimento do V8 é Lars Bak, que foi o líder técnico do Strongtalk e do HotSpot (Java) e também um grande contribuidor da maquina virtual original do Self. Segundo o projeto, o V8 é otimizado para acesso de propriedades e tem um coletor de lixo agressivo.
  • O Tracemonkey usa código do Tamarin, a máquina virtual de JavaScript da Adobe, que doou o código para a Mozilla Foundation. A otimização e o JIT é feito usando um processo chamado Tracing Trees. Se você estiver disposto a ler um paper comprido, complicado e interessante, pode ler o Incremental Dynamic Code Generation With Trace Trees.

No geral, o tempo total dos testes foi menor para o tracemonkey, embora comparando os quadros, não teve uma máquina virtual que tenha vencido em todos os testes.

Os testes foram feitos usando a revisão 110 do v8 (disponível em http://v8.googlecode.com/svn/trunk) e a revisão db4260e7ee13 do tracemonkey (disponível em http://hg.mozilla.org/tracemonkey/), e foi usado o próprio benchmark do tracemonkey para testar as duas VMs.

Agora a pouco, eu refiz os testes com as últimas versões das máquinas virtuais, e os resultados se alteraram um pouco:

chrome_v8_0last

chrome_v8_1last

chrome_v8_2last

Diferente do teste do Brendan Eich, foi testado apenas VM e não o desempenho dela dentro do navegador, mas no geral, os resultados do meu teste aqui condizem com o dele.

Mais sobre o v8 e assuntos relacionados

Syndicated 2008-09-04 14:37:19 (Updated 2008-10-01 14:27:33) from devlog

Google Chrome - download e código fonte

Finalmente, as URLs para o Google Chrome começam a aparecer.

Você pode entrar em http://www.google.com/chrome/eula.html para fazer o download, somente para windows. Ou pode fazer o download do binário direto em http://www.google.com/chrome/eula.html (e tentar rodar no wine, sei lá).

O código fonte você encontra em http://dev.chromium.org/developers/how-tos/getting-started.

A engine de Javascript V8 você pode baixar no Google Code. O scons (um tipo de make em python) é necessário para a compilação. Eu tive problemas para compilá-la com o gcc 4.3. Fiz algumas correções, mas antes mesmo que eu tivesse tempo de postar o patch, Seo Sanghyeon postou o patch necessário na lista v8-dev. A licença, como era esperado, é a BSD.

V8shell

Mais links:

Syndicated 2008-09-02 20:46:06 from devlog

2 Sep 2008 (updated 3 Sep 2008 at 00:06 UTC) »

Google Chrome

http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html

O google agora começa a tocar na peça fundamental para a web, que está bem diante dos seus olhos: o navegador. A divulgação, feita pelo blog oficial do google, aponta para um quadrinho (publicado no google books).

Usando componentes do Webkit e do Mozilla Firefox, juntando a uma interface própria e uma nova engine de JavaScript, V8. Por enquanto, disponível apenas para windows, mas o anúncio diz que em breve sairão versões para Linux e Mac.

O que mais falta agora?

A nota de lançamento pode ser vista em português no blog go google em português.

Syndicated 2008-09-02 03:16:55 (Updated 2008-09-02 13:48:03) from devlog

ECMA 4: vá com Deus (ou que o diabo te carregue!)

E a batata quente, quente, quente, queimou. Após o encontro do ECMA (Ecma's Technical
Committee 39) em Oslo, em julho, a especificação ES4 foi deixada (temporariamente) de lado. Brendan Eich fez o anúncio. O foco, por enquanto era o ES3.1 (Baseado no ECMA-262 Edição 3). Packages, namespaces e early binding, por enquanto, ficam de fora.

Podem até dizer que é conspiração da Microsoft (o Brendan Eich nega). O fato é que, ao menos pra mim, as coisas ficaram como sempre deveriam estar. Por enquanto.

Syndicated 2008-08-26 18:55:28 (Updated 2008-08-26 18:55:58) from devlog

Wordpress 2.6, TinyMCE

Usando o wordpress 2.6, que vem com o TinyMCE 3.1.1 (que a propósito, não é bem um 3.1.1), mesmo depois deu ter conseguido habilitar o plugin para tabelas do TinyMCE (ei, elas podem ser úteis e necessárias em alguns contextos), a tela ficava como no screenshot abaixo.

Wordpress TinyMCE

Após ler alguns posts, eu consegui 'resolver' (vulgo, usar um tipo leve de POG) para fazer funcionar. Segue os passos!

  1. Baixar o TinyMCE do site
  2. Copiar o plugin table para wp-includes/js/tinymce/plugins
  3. Editar o wp-includes/js/tinymce/tiny_mce_config.php e incluir o 'table' no array $plugins;
  4. Editar o wp-includes/js/tinymce/tiny_mce_config.php e incluir o 'tablecontrols' no array $mce_buttons_3;

Verifique também se não existe um cache do javascript do tiny_mce. Ele fica em /wp-content/uploads/js_cache. Você pode precisar apagá-lo para que suas configurações do plugin sejam lidas. Adicionalmente, você pode desabilitar o cache em wp-includes/js/tinymce/tiny_mce_config.php .

Se tudo correu bem até aqui, o seu editor de tabelas no tinyMCE deverá estar funcionando como o meu.

Segundo um comentário no fórum do tinymce, a chamada (!tinymce.ScriptLoader.isDone(u)) na função requireLangPack nunca retornava verdadeiro. Como Javascript nos permite fazer alterar um método dinamicamente, podemos aplicar um pequeno hack no table.js, logo no início do arquivo, antes da chamana a requireLangPack:


tinyMCEPopup.requireLangPack = function () {
    var u = this.getWindowArg("plugin_url") || this.getWindowArg("theme_url");
    if (u && this.editor.settings.language) {
        u += "/langs/" + this.editor.settings.language + "_dlg.js";
        tinymce.ScriptLoader.lookup[u] = {state:0} //HACK MALIGNO
        if (!tinymce.ScriptLoader.isDone(u)) {
            document.write("&ltscript type="text/javascript" src="" + tinymce._addVer(u) + "">");
            tinymce.ScriptLoader.markDone(u);
        }
    }
}
 

Basicamente, estamos fazendo um HACK MALIGNO, dizendo que o script nunca está carregado, portanto, sempre o carregue. Se você estiver usando o locale pt_BR no wordpress, vai precisar criar um arquivo pt_dlg.js na pasta langs do plugin table.

Curioso para saber o que eu ando fazendo com wordpress? Dá uma olhada no site da China 2008!

Syndicated 2008-08-11 20:57:14 (Updated 2008-08-11 21:22:55) from devlog

PHP4 na hora da morte!

http://www.php.net/archive/2007.php

De acordo com a notícia no php.net, e como já foi anunciado em alguns blogs por aí, hoje é o dia da morte do PHP 4. Ainda bem que se foi (embora ainda continue muito vivo mum servidor perto de você, ou, infelizmente, de mim!)

Syndicated 2008-08-08 18:06:12 from devlog

Dr. Project

https://www.drproject.org/

Apesar da recente popularização de sistemas de controles de versão distribuídos como o git ou o mercurial, o svn ainda é a ferramenta mais popular para controle de versões. E junto com ele, quase sempre está o trac, que adiciona ao repositório um wiki, tickets e outras ferramentas para gerenciar o desenvolvimento.

Porém, a maior questão dos usuários com o trac é ter de subir uma instalação do trac para cada repositório. Não é uma tarefa muito difícil, mas convenhamos, podia ser mais fácil.

Pensando nisso, a Universidade de Toronto fez um fork do trac, adicionando a capacidade de múltiplos projetos. Entre as facilidades oferecidas, podemos citar, por exemplo, que criar um projeto no DrProject já cria o respectivo repositório.

Comparação

O DrProject era originalmente um fork do portal open source leve chamado Trac. Essa é a comparação dos dois hoje:

DrProject Trac
Múltiplos projetos por portal sim não
Listas de e-mails integradas sim não
Controle de Acesso baseado em Roles sim não
Contas de Usuários externas sim por plugins de terceiros
Camada de banco de dados Elixir/SQLAlchemy SQL manual
Navegador de repositório Subversion sim sim
Support a Perforce, BZR, etc. não por plugins de terceiros
Busca Cross-Component sim sim
Administração baseada em Web sim parcial
Sintaxe do Wiki Markdown custom
Milestones Sim Sim
Tagging yes by third-party plugin
Remote Scripting API yes no
Client-Side Javascript Dojo handwritten Javascript
RSS Feeds yes yes
Custom Ticket Views no yes
Integração ao Eclipse não por plugins de terceiros

Segundo Jeff Balogh, o trunk dele é estável, com o desenvolvimento feito nos branches.

O projeto foi originalmente desenvolvido para uso no ensino[bb]. Numa troca de e-mail rápida com os desenvolvedores, perguntei no que isso se fazia presente no projeto. David Wolever me disse que o sistema de permissões é um reflexo disso, já que num projeto open source o acesso ao código não precisa ser restrito. Greg Wilson me falou a respeito das listas de e-mail integradas, e das operações em lote, como criar vários projetos com nomes sequenciais - que são úteis dentro de um ambiente de ensino.

A instalação do projeto foi parecida com a do trac, com a exceção que o DrProject espera que os repositórios estejam dentro dele, já que ele os administra. Numa tentativa de atualização, o meu banco de dados (sqlite) teve algum problema, mas logo depois o problema desapareceu. Sinais de que o projeto ainda tem muito o que andar, mas é uma boa pedida pra adicionar na lista de coisas a testar.

Syndicated 2008-07-21 21:54:43 from devlog

2+2 = 5

Se tem uma coisa que me irrita, é quando as pessoas dão nomes as coisas de uma forma não condizente.

Por exemplo, trabalhando com o Plone e categorização de objetos. Você já imagina que para procurar objetos por categorias você irá esbarrar em categories, category, até um possível tag. Mas dentro do Plone, você busca por Subject.

Mas em um outro caso, é o Plone que me salva. Se você vai adicionar uma informação geográfica a um objeto, você logo pensa em location. Ao menos é o que a tela de edição do Plone mostra. E é o que o Dublin Core chama de coverage.

Vocês podem achar que eu estou sendo excessivamente chato com isso, mas lembre-se que você sempre terá de gastar alguns segundos para associar a palavra ao seu significado específico dentro daquele contexto onde ela tem um significado alienígena

Syndicated 2008-07-17 21:12:11 (Updated 2008-07-17 21:13:15) from devlog

112 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!