Amount of profanity in git commit messages per programming language

http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

Deadlock in São Paulo

http://en.wikipedia.org/wiki/Deadlock

Django Good Practices

[Editado em 2011/03/27]: melhor explicado e detalhado o primeiro tópico.

 Depois dos tópicos de antipadrões com Django (http://pythonsmalltalk.blogspot.com/2011/03/discussao-sobre-django-internet-e.html), agora um tópico de boas práticas.

• Usar filter e exclude somente dentro de managers ou models: Com django é tão fácil fazer query que acabamos inserindo filters e excludes em tudo quanto é local, tais como views e forms, o que é uma ideia terrível. Prejudica a testabilidade do código, mistura responsabilidades dos objetos etc.
• Dar nomes às urls e usar reverse e a tag url: Usar urls hard-coded além de prejudicar a manutenção, ainda dificulta i18n. Além disso, a aplicação pode deixar de ser um "pluggable", ou seja, dificilmente poderá ser reaproveitada em outros projetos.
• Utilizar select_related sempre que possível/necessário para otimização (http://docs.djangoproject.com/en/1.2/ref/models/querysets/#select-related)
• Usar distinct em buscas que envolvem várias tabelas. Mais comumente quando são usados campos many to many para buscas. Isso é pra evitar que uma busca traga registros repetidos. Chatices de SQL que são propagadas nos resultados das buscas. (http://docs.djangoproject.com/en/1.2/ref/models/querysets/#distinct)
• Criar Custom Fields caso um field siga um padrão (http://docs.djangoproject.com/en/1.2/howto/custom-model-fields)
• Sempre dar redirect depois de salvar um formulário (básico de qualquer framework Web).
• Não utilizar o arquivo tests.py. Criar uma pasta tests e adicionar arquivos de teste para arquivo da aplicação.
• Há várias maneiras de organizar o settings. Uma básica e boa é criar (pelo
  menos) um arquivo de settings para desenvolvimento e um para produção.

Django Dynamic Fixture 1.2.1

Version 1.2.1 of Django Dynamic Fixture released. Documentation was updated, including comparison with another tools.

Before this version, the tool was not able to create satisfactory objects that had auto calculated fields, like objects that inherits MPTT model: Dango-MPTT (http://code.google.com/p/django-mptt).

Django Dynamic Fixture 1.2.1: http://code.google.com/p/django-dynamic-fixture

Discussão sobre Django, Internet e frameworks Web

Já mexi com muitos frameworks Web, de diferentes linguagens: JSP/Servlets, Struts, JSF, GWT, Echo2 (todos anteriores para Java), Django (Python), Grails (Groovy), Rails (Ruby) etc. Desses todos, destaco dois como sendo os mais inteligentes: Django e GWT.

Django porque é muito simples, legível e poderoso.

GWT porque foi criado pensando completamente em comandos assíncronos. Talvez apenas o Echo2 poderia se comparar a ele.

Ainda não existe um framework perfeito (ou quase), até mesmo porque a internet ainda é muito bagunçada. Prova disso são as próprias "linguagens" de HTML, Javascript e CSS que são completamente rebuscadas. Não é a toa que hoje existem diversas ferramentas para geração de CSS e ferramentas de Javascript, tais como JQuery, que não apenas criam funções bacanas para serem usadas, mas que também fazem uma série de correções e adaptações para navegadores e pro próprio HTML/Javascript para que o desenvolvimento Web se torne menos amaldiçoado.

Isso dá até um bom argumento para a Microsoft e o IE não adotarem certos padrões e convenções. Uma empresa do tamanho da Microsoft não deve acatar a padrões mal definidos. Claro que não estou defendendo a Microsoft, até porque isso só piora ainda mais a situação. Entretanto, é compreensível.

Mas enfim, onde quero chegar é que Django não é perfeito e, acredito, tem certas coisas que devem ser evitadas. Segue uma lista:

• Framework de permissões: Acho útil apenas para interface de Admin. Para uso interno, não faz sentido. Devemos simplificar as coisas, não complicar. Logo, devemos trabalhar com grupos de usuários (vide django snippets). Perdemos em flexibilidade mas ganhamos em simplicidade e clareza.
• Formsets, Inline Formsets etc: Foram criados pensando na interface de Admin. Apesar de quebrarem um galhão as vezes, são muito rebuscados e limitados.
• Templates para comandos assíncronos: Templates no Django são muito legais, principalmente seu sistema de herança que é muito simples. Contudo, meu modo de ver é que templates é uma arquitetura pensando em páginas e comandos síncronos. Quando vamos trabalhar com chamadas assíncronas, eles perdem importância. Django não foi arquiteturado como o GWT, logo, não é trivial criar componentes de interface de usuário.
• get_absolute_url: O quê tem a ver url com a base de dados? Isso é uma tentativa de DRY, mas, ao meu ver, equivocada. Primeiro porque deixa confuso aonde a url será definida (temos o urls.py pra isso). Depois porque mistura de responsabilidade da camada de dados/negócios com a de exibição.
• Fixtures (estáticas) nos testes: Fixtures estáticas, não importa se é xml, yaml, json etc, são horríveis para manutenção. O máximo é ter um initial_data com usuários, grupos, permissões e algum outro dado básico e olhe lá.

À medida que for tendo novos pensamentos vou adicionando aqui.