automatizando coisas no virtualenv

Trabalhando com virtualenvwrapper você possui alguns hooks auxiliares que podem ser úteis.

$ cat ~/.virtualenvs/postactivate 
#!/bin/bash
# This hook is run after every virtualenv is activated.

e

$ cat ~/.virtualenvs/postmkvirtualenv 
#!/bin/bash
# This hook is run after a new virtualenv is activated.

Os nomes são autoexplicativos, eu diria. Se bem que o comentário do postmkvirtualenv poderia dizer após o virtualenv ser criado.
O seu postmkvirtualenv poderia conter algo como:

$ cat ~/.virtualenvs/postmkvirtualenv 
#!/bin/bash
# This hook is run after a new virtualenv is activated.
pip install ipython
pip install nose
pip install coverage

E por ai vai.. pode colocar variáveis de ambiente, instalar mais pacotes e etc

=]

grep excluindo pasta

Como fazer um grep mas quer excluir alguma pasta da busca?

Simples, simples

$ grep "alguma coisa" -Rn ./ | grep -v essa_pasta_nao

=]

InfoQ downloader

InfoQ sempre tem vídeos bem interessantes de tecnologia, incluindo Luciano Ramalho, TDC e outros.

Felizmente existe uma forma bacana de baixar o vídeo e slides.

git clone https://github.com/joncasdam/infoq-downloader.git
cd infoq-downloader
pip install -r requirements.txt

E o uso é mais fácil ainda:

python infoq_downloader.py http://www.infoq.com/produtividade-e-qualidade-em-python

pega lá meu fork:
https://github.com/joncasdam/infoq-downloader

=]

Instalando versões antigas de fórmulas no brew

Digamos que você está com um projeto legado em mãos e deseja, portanto, instalar as dependências e, dentre as tais, está uma versão antiga de uma fórmula.

Eis o que passei recentemente:

A versão corrente do PostgreSQL é 9.x, mas o projeto precisa da 8.x

Se você usar:
$ brew install postgres
Como é de se esperar, ele instala a versão mais nova.

Primeiro você precisa descobrir quais as versões disponíveis para instalação.

$ brew search postgres
check_postgres    homebrew/versions/postgresql9
homebrew/versions/postgresql92   postgres-xc
homebrew/versions/postgresql8    homebrew/versions/postgresql91
homebrew/versions/postgresql93  postgresql
Caskroom/cask/navicat-for-postgresql    Caskroom/cask/postgres

Tendo encontrado a versão que precisava, use:

$brew install homebrew/versions/postgresql8

Be happy.

retornar JSON com Django

Antes de tudo, vamos deixar claro que a partir do Django 1.7, há uma classe responsável para isso.
Sim, isso mesmo: a classe JsonResponse:

from django.http import JsonResponse
return JsonResponse({'foo':'bar'})

Agora, se você ainda está em uma versão do Django anterior a 1.7, há uma forma bem simples:

from django.http import HttpResponse
return HttpResponse(json.dumps(dados), content_type="application/json")

=]

semantic matters

*post (auto)convidado

Quando comecei a programar minha primeira preocupação era:

Como djabus eu faço isso?!

Depois de algumas horas testando, quebrando a cara e lendo documentação comecei a me encontrar nesse universo. Não entendia muito bem como tudo isso funcionava. Não sabia bem o que eram variáveis, loops, funções, etc mas tinha uma ideia de como usar tudo isso então minha primeira preocupação como programador passou a ser sintaxe. Afinal, se a sintaxe não estiver correta seu código não roda e não serve para nada.

Depois de algum tempo comecei a me dar bem com a sintaxe. Escrevia, o código rodava e eu ficava feliz :D Porém, eventualmente, o código rodava mas não fazia o que eu queria. Eis que essa se tornou minha primeira preocupação como programador: O código devia fazer o que eu queria que fizesse.

Em pouco tempo me deparei com uma ordenação. Queria ordenar minha lista de músicas em meu mIRC Script então descobri o Bubble Sort. Entendi como funcionava, implementei no mIRC e rodei. Eram quase 10 minutos para ordenar minhas 300 e poucas músicas em ordem alfabética. Foi aí que descobri duas coisas: Não adianta rodar e fazer o que eu quero mas levar 10 minutos para isso; Não adianta tentar reinventar a roda: Alguém já deve ter implementado isso que você quer. Comecei a me preocupar com desempenho e aprender como melhorá-lo e essa passou a ser minha primeira preocupação (principalmente por trabalhar numa linguagem de script num computador lento)

Algum meses depois precisei corrigir algum código antigo que não estava funcionando como eu queria e sabe o que eu descobri? Que era impossível entender aquela merda que eu tinha feito! Tinha linhas com literalmente centenas de caracteres que, na época, podiam fazer sentido mas agora eram puro lixo! Então fazer um código inteligível passou a ser minha primeira preocupação.

Mais algum tempo se passou e conheci o Python. Fiquei feliz, era simples, fácil, tinha todas as rodas inventadas já implementadas, meu código rodava e fazia o que eu queria! Mas não era "pythônico" :( Então essa passou a ser minha primeira preocupação: Tinha que ser pythônico. Comecei a estudar esse tal de python, PEPs, ver códigos de outras pessoas, me converti a "Igreja Pythônica, PEP8 é meu pastor e tudo commitarás" então não bastava rodar, fazer o que eu queria, ser rápido e compreensível. Tinha que ser pythônico.

Hoje acho que posso dizer que domínio bem esse tal de Python, meus códigos são "pythônicos", diria que 99,5% PEP8 e PEP257 clean, fazem o que eu quero, são compreensíveis e rodam. Qual a próxima principal preocupação? Agora estou me preocupando com semântica. Ao ter que trabalhar em códigos completamente sem semântica alguma percebi o quanto isso é importante, afinal, se você encontra uma variável chamada "pessoa" você espera que ela represente uma pessoa e não uma lista de cachorros.

Então esse pensamento em semântica tem me ajudado muito também para nomear coisas. Antes eu pensava: "O que tem dentro dessa variável?" e a resposta me ajudava a dar um nome a ela. Com isso eu tinha variáveis como "pessoa_attr_dict", "lista_pessoa_ativa". Funcionava, certo, mas eram bons nomes? Hoje penso: "O que essa variável representa?" então passei a ter variáveis como "pessoa", "pessoas_ativas". Melhor, não? Então se você faz um request na API da loja o retorno não será "resposta_api_loja" ou "dados_loja" e sim simplesmente "produtos". E passei a ter refactories "inúteis" como:

ruim.py

bom.py

Com isso seguem algumas "normas" que criei/copiei e tenho usado bastante:

- Se representa uma Coisa a variável se chama "coisa".
- Se representa um conjunto de Coisas a variável é um array chamado "coisas".
- Todo plural representa um array e todo array estará no plural.
- Se a variável contém partes de Coisa e partes de Treco, pense duas vezes. Faz sentido ter isso dentro de uma variável?
- Não dê tipo aos nomes. "lista_pessoas", "dict_coisa" não é legal
- Pense em como você vai usar. Se você tem a classe "Stuff" e quer um método que retorne a coisa ativa use "get_active" ao invés "get_active_stuff" pois você já vai usar "Stuff.get_active()". Não precisa de "Stuff.get_active_stuff()"
- E a universalmente útil: Sempre que você duplica um código Deus mata um gatinho. (Diogenes, Humberto)


--
Fábio Pachelli Pacheco, autor do que acabaste de ler, é um ex-coworker meu, sagaz em várias artes, inclusive nas informáticas.