Vaga para desenvolvedor Python em Curitiba

A Orangotoe, empresa que desenvolve portais em Curitiba está procurando prodígios da web para trabalhar em projetos como o Paraná Online e Banda B.

Mais informações no blog da empresa.

Anúncios

Novo portal Rádio Banda B

UPDATE 12/03/2010: eu não trabalho com a equipe da rádio, apenas trabalhei no desenvolvimento do portal. Para falar com a equipe, acesse o portal.

UPDATE 14/07/2010: É engraçado que mesmo depois de colocar o aviso acima continuo recebendo pedidos dos mais variados em relação à rádio. Pessoas elogiando os programas, procurando casa para alugar, comprar, entre outros.

UPDATE 30/08/2010: Desisti! Comentários fechados.

Está no ar mais um portal em que eu tive o prazer de trabalhar aqui na Orangotoe: Rádio Banda B. A rádio é líder no seguimento AM em Curitiba e Região Metropolitana, seu conteúdo é voltado para a informação e entretenimento da comunidade, contendo trechos de programas da rádionotíciasblogs, agenda de programação e vários outros recursos.

O mais interessante deste projeto foi o modo em que foi desenvolvido, usando uma mistura de Scrum com XP. Foi aplicada uma série de boas práticas como desenvolvimento orientado a testes, programação em par e aplicações reutilizáveis. Vários módulos e aplicações de código aberto foram utilizados e outros criados internamente que poderão ser reaproveitados em novos projetos. Tudo isso contribuiu para que o processo fosse mais fluido e rápido.

Um destaque para a aplicação de calendário que suportou o agendamento e recorrência da programação da rádio. Um agradecimento especial ao Gustavo Niemeyer pelo módulo python-dateutil com as classes rrule e rruleset que foram fundamentais para o funcionamento desta aplicação.

Para saber mais basta visitar o portal! Estarei aqui para responder qualquer pergunta ou comentário, qualquer opinião é bem vinda!

Para ter um registro histórico, aqui vai um screenshot da home:

Screenshot da home do portal Rádio Banda B AM 550

ParseException com django-haystack e Whoosh

O haystack, utilitário de buscas para o Django, tem um problema quando se tenta listar todas as ocorrências indexadas para um único model.

Estou usando o Whoosh como backend de busca, não sei se isso acontece com outros backends.

Eu alertei o desenvolvedor, mas ainda não houve tempo de resposta pelo jeito já foi corrigido.

É possível contornar o problema filtrando pelo campo de content-type do índice ao invés de usar o método sugerido “models”. Algo assim:

SearchQuerySet().filter(django_ct='%s.%s' % (SomeModel._meta.app_label,
                                             SomeModel._meta.module_name))

Pesquisa sobre a Comunidade PythonBrasil

O Henrique Bastos vai estar na PyCon deste ano, em Atlanta nos Estados Unidos, e vai apresentar uma palestra “Small acts make great revolutions”.

Para isso está pedindo colaboração para traçar um perfil da comunidade Python no Brasil através de uma pesquisa. Se você é desenvolvedor, faça sua parte e preencha a pesquisa, é rápido e indolor. Não precisa trabalhar com Python, o perfil é geral.

Pesquisa:
http://henriquebastos.wufoo.com/forms/vamos-divulgar-nossa-comunidade-python-na-pycon/

Post inicial:
http://henriquebastos.net/2010/01/08/ajude-a-mostrar-a-pythonbrasil-na-pycon-2010/

Bombando:
http://henriquebastos.net/2010/01/13/a-pesquisa-sobre-a-comunidade-pythonbrasil-esta-bombando/

Como não vi nada no feed da Django Brasil, tomei a liberdade de “taguear” o post para aparecer lá também, sei que tem gente que acompanha novidades do Django mas não do Python em geral.

django-importer: Software Livre Compensa

Há um tempo atrás, desenvolvi uma aplicação para Django que achei bacana e resolvi lançar como um projeto no Google Code.

Divulguei nos canais competentes mas não houve muito alarde. Algumas pessoas pediram mais explicações mas parou por aí, o projeto ficou encostado.

Passado um tempo, o Josir me perguntou se eu poderia criar um módulo para importação de arquivos CSV. Combinamos um preço, o projeto continuaria aberto e eu desenvolvi o novo recurso.

Fiz melhorias além do requisitado, no código, na documentação e inclui um projeto de exemplo. O resultado já foi publicado e está disponível para quem quiser ver e usar.

O melhor dessa história toda é o reconhecimento, me senti muito bem em ver que o trabalho foi útil para alguém e que existe gente disposta a investir para torná-lo melhor.

Combinei com o Josir que iria divulgar o ocorrido, pode parecer algo pequeno, mas para mim foi significante e acho que serve como um bom exemplo de colaboração. Por falta de tempo, ele ainda não pode testar, mas teve o que precisava e com isso a comunidade também ganhou.

Então deixo aqui os meus agradecimentos ao Josir e à comunidade de software livre.

Auto-completar com o Fabric

Estive fazendo algumas coisas com fabric e senti falta de um auto-completar para as tarefas disponíveis.

Aí descobri que era possível listar as tarefas usando:

fab --list

Dei uma olhada no autocomplete do Django e também encontrei este artigo que me ajudou bastante.

Juntando um pouco daqui e dali cheguei neste script que deixei junto das minhas dotfiles.

Parece coisa de preguiçoso, normalmente as tarefas têm pouco mais de 4 letras, mas tudo bem, ajudar não dói não é?

Para instalar é só chamar o script no seu .bashrc ou .bashprofile:

. /caminho/para/fab_bash_completion

Também serve de exemplo para fazer o auto-completar dos seus próprios comandos.

Apache, processos, threads e django

Muitas vezes apenas adotamos os padrões e não nos questionamos porque eles foram escolhidos, então resolvi fazer uma breve pesquisa sobre threads e processos no Apache

Antes de mais nada, é importante falar um pouco sobre processos e threads. Os processos são independentes e têm seus próprios endereços de memória, os threads pertencem a um processo e compartilham o mesmo endereço de memória e recursos.

Tudo começa no webserver, vou falar do Apache. Existem dois sabores que se diferenciam em como será feito o processamento de múltiplas requisições: prefork e worker.

O prefork tem um processo de controle para outros sub-processos que irão receber e responder às requisições. Aqui não são utilizados threads, uma requisição é repassada para o primeiro sub-processo livre e este, por sua vez, só atenderá a uma requisição por vez.

O worker também tem um processo de controle para outros sub-processos, a diferença é que cada sub-processo cria um thread de escuta que fará o repasse de requisições para outros threads. Isto faz com que o uso de memória normalmente seja menor, pois os threads compartilham os mesmos recursos.

Em ambos os modelos é possível regular o mínimo ou máximo de processos e threads, o Apache se encarrega de reciclar os processos dentro destes limites. O ideal é que o servidor esteja configurado para aguentar o número esperado de requisições mas evitando consumir toda a RAM disponível, o que resultaria em uso da SWAP em disco e uma cascata de problemas.

Segundo a documentação, o prefork é indicado para evitar threading em aplicações que utilizam bibliotecas non-thread-safe, ou seja, evitar que ações em threads diferentes de um mesmo processo possam influenciar outro thread. Como o worker mantém um conjunto de threads em um mesmo processo, compartilhando recursos, bibliotecas mal preparadas podem causar resultados inesperados.

Em geral, o Django é tido como thread-safe, houve uma discussão sobre isso mas acredito que muitos dos problemas da época já tenham sido resolvidos. Ainda não fiz a experiência, mas este post do Armin Ronacher compara o sistema de templates do Django com o Jinja e comenta que algumas templatetags como a cycle não são thread-safe.

Por muito tempo o Django teve o modpython com Apache prefork como deploy recomendado, agora a recomendação oficial é para se utilizar o modwsgi* mas não cobre qual modelo de webserver é mais adequado.

* Curiosidade: conversando com o Jacob na Python Brasil aprendi que se pronuncia “mód uísgui”, mais fácil não? 🙂

Aqui vão mais alguns links interessantes: