Pythonologia, o blog da Triveos

PythonBrasil [6] – Curitiba, 21 a 23 de outubro

Osvaldo Santana Neto — Thu, 12 Aug 2010 22:04:27 +0000

Como não podia deixar de ser esse ano teremos mais uma edição do encontro brasileiro da comunidade Python: a PythonBrasil [6].

Das seis edições do evento eu só não pude ir na que aconteceu no ano passado. Essa ausência me “dói” até hoje e eu ainda sou corroído por uma “invejinha” de quem foi.

A PythonBrasil tem muitas características que eu gosto de ver em eventos de tecnologia: formatos inovadores (palestras relâmpago, open spaces) além das tradicionais apresentações e cursos, a presença de uma turma realmente especial de desenvolvedores extremamente experientes, um evento com a “mente aberta” (já é praxe convidar palestrantes para falar de outras linguagens de programação), etc, etc.

Esse ano teremos algo ainda mais especial: o evento acontece aqui na nossa cidade: Curitiba.

Se você quer participar de um evento muito legal eu recomendo que você faça sua inscrição. Se você já usa Python e tem coisas legais para mostrar para nós submeta uma proposta de palestra ou curso.

Nós da Triveos estaremos por lá e (se nossas propostas forem aprovadas) apresentaremos algumas das coisas que estamos fazendo com Python e Django. Além disso vamos distribuir alguns brindes para os participantes do evento.

Usando Django com IIS e SQL Server

Osvaldo Santana Neto — Wed, 04 Aug 2010 20:46:26 +0000

As distribuições Linux e o Mac OS X já possuem uma instalação bastante completa de Python e instalar o Django é rápido e fácil nesses ambientes.

Como o Django suporta “oficialmente” os servidores Web e de banco de dados mais comuns no mundo open-source (Apache, nginx, lighttpd, MySQL, PostgreSQL, etc) a documentação dele está repleta de exemplos sobre como fazer um deploy nesses ambientes.

Mas e se você trabalha num ambiente onde a plataforma da Microsoft é usada intensamente? E se você usa o IIS como servidor Web e o SQL Server como banco de dados relacional, seria possível usar o Django?

A resposta é sim, mas por não ser suportado “oficialmente” a configuração desses ambientes não é muito documentada nem é muito simples (ao menos pra nós que não trabalhamos intensamente com a plataforma da Microsoft).

Vamos descrever os passos necessários para colocar esse ambiente “no ar”.

Baixando e instalando o Python

O jeito mais fácil de instalar o Python na plataforma Windows é com o ActivePython distribuido pela ActiveState. Além da instalação padrão do Python essa distribuição inclui módulos e bibliotecas muito úteis no ambiente Windows.

Nota, a versão recomendada é a Active Python 2.5. Os screenshots são meramente ilustrativos

Active Python da ActiveState

Acessando o site e clicando no link para download você será encaminhado para um formulário cujo preenchimento é opcional e o download será iniciado.

Formulário cujo preenchimento é opcional

Assim que o download terminar é só executar o instalador e seguir as instruções.

Seguindo as instruções do instalador

Instalando o Django e suas dependências

Para facilitar o trabalho, a Triveos desenvolveu um instalador que já instala o Django e outros pacotes necessários (que funciona APENAS com o Active Python 2.5) Baixe-o aqui

Mas se desejar instar o Django manualmente continue lendo.

O procedimento para instalar o Django e parte de suas dependências segue no “Prompt de Comandos”. O ActivePython já colocou os diretórios do Python no PATH do sistema e instalou as ferramentas necessárias para baixar e instalar o Django e suas dependências (setuptools/easy_install/pip).

Agora é só a gente criar um ambiente isolado de trabalho (que chamaremos de ‘gerenciador’) com o virtualenv e instalar o Django com o pip.

Instalando o Django

C:\Users\usuario> virtualenv gerenciador
C:\Users\usuario> cd gerenciador
C:\Users\usuario\gerenciador> Scripts\activate.bat
(gerenciador) C:\Users\usuario\gerenciador> pip install django

Criando um projeto Django

Com o que a gente já fez é possível iniciar um projeto Django que, posteriormente, armazenara seus dados num servidor SQL Server e será acessível através de um servidor IIS. Esse projeto também se chamará ‘gerenciador’ e será criado dentro do nosso ambiente virtual que tem o mesmo nome: “C:\Users\usuario\gerenciador\gerenciador“.

Criando o projeto

(gerenciador) C:\Users\usuario\gerenciador> python Scripts\django-admin.py startproject gerenciador
(gerenciador) C:\Users\usuario\gerenciador> cd gerenciador
(gerenciador) C:\Users\usuario\gerenciador\gerenciador>

Configurando o acesso ao SQL Server

Para que seja possível acessar um banco de dados SQL Server a partir de uma aplicação feita em Django é necessário instalar o backend do mesmo já que ele não faz parte da instalação padrão do Django. O projeto que implementa esse backend fica no endereço: http://code.google.com/p/django-mssql/.

Para que o backend funcione é necessário colocar o diretório “[django-mssql]/source/sqlserver_ado/” em um caminho do PYTHONPATH. No nosso caso vamos colocá-lo dentro do diretório do nosso próprio projeto. Para facilitar o nosso trabalho é só baixar o arquivo com o backend e descompactá-lo dentro do diretório do nosso projeto Django.

Criando o banco de dados

Crie o banco de dados que será usado por nossa aplicação no SQL Server e certifique-se de usar a autenticação por senha e não a autenticação Windows (que não é suportada pelo backend).

Banco de dados

Agora é só configurar a conexão no arquivo settings.py do nosso projeto.

Configuração do projeto

Assim que a gente rodar um python manage.py syncdb…

Rodando o

… as tabelas serão criadas no banco de dados.

Tabelas prontas para serem usadas

Configurando o IIS

Devo confessar que essa foi a parte mais complicada do trabalho!

Antes de instalar o seu projeto no IIS teste-o usando o manage.py.

Para facilitar o trabalho, a Triveos desenvolveu um instalador (que funciona APENAS com o Active Python 2.5) Baixe-o aqui

Este instalador instala o Django e todas os pacotes necessários (django-mssql e isapi-wsgi). Exige o Active Python 2.5

Após instalado, faça da seguinte forma:

1 – crie o diretório que vai receber o seu projeto no IIS (pode ser dentro do c:\inetpub)
2 – crie o arquivo handler de WSGI neste diretório, assim:

import os, sys 

#inclua aqui o caminho para o seu projeto
#é comum incluir o caminho para o diretório do projeto e seu pai
sys.path.append('C:\\django_projects')
sys.path.append('C:\\django_projects\\example_project') 

#configure aqui para apontar para o arquivo de settings de seu projeto
os.environ['DJANGO_SETTINGS_MODULE'] = 'example_project.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler() 

import isapi_wsgi
# The entry points for the ISAPI extension.
def __ExtensionFactory__():
    return isapi_wsgi.ISAPISimpleHandler(application)

3 – salve o arquivo com algum nome (por exemplo, wsgi.py)
4 – Busque dentro do diretório do Python o arquivo PyISAPI_loader.dll (normalmente em C:\Python25\Lib\site-packages\isapi). Copie-a para o diretório com o mesmo nome do arquivo .py (com extensão .dll) mas precedido de um caracter ‘_’ (underscore). Assim, se o arquivo foi salvo como wsgi.py, copie a dll e a renomeie para _wsgi.dll
5 – Para os diretórios de media e admin_media, você deverá incluir Virtual Directories do IIS apontando para eles

Virtual dirs para admin media

6 – Finalmente crie os mapeamentos da seguinte forma:

Nas configurações do site, em Handler Mappings adicione um Script Map da seguinte forma:
-Request Path: *
-Executable: aponte para a .dll dentro do diretório
-Nome: como desejado

Crie um mapeamento para StaticFileModule para os caminhos que apontam para os virtual dirs. Infelizmente é necessário criar um mapeamento para todos os subdiretórios. (ou seja, é necessário criar um mapeamento para admin_media/css/*, admin_media/js/* admin_media/img/*)

Module mappings não ordenados

Ordene os mapeamentos colocando os de media primeiro e o Script Map por último.

Se tudo der certo o seu site está funcionando no IIS agora!

Interface Admin do Django: um baita quebra-galho.

Osvaldo Santana Neto — Sat, 03 Jul 2010 00:57:42 +0000

Já faz algum tempo que nós aqui na Triveos estamos usando Django e Python. Também tenho apresentado palestras e ministrado cursos de Django em vários lugares. Temos até mesmo um curso online de Python e Django à venda em um site desenvolvido em Django.

A Interface Admin do Django

Todos os programadores Django adoram falar sobre um dos grandes diferenciais desse framework: A Interface Admin.

Realmente, só quem desenvolve aplicações Web a bastante tempo e perdeu tempo precioso fazendo “telinhas de cadastro” sabe como essa tarefa é chata e pouco desafiadora. E todos que desenvolvem com Django agradecem a existência dessa funcionalidade.

A interface Admin do Django é prática, fácil de ser usada, e bonitinha. Uma mão na roda. Um baita quebra-galho. Até mesmo… mágica! A diferença entre um projeto entregue e um projeto atrasado.

Mas isso termina por aqui.

A interface de Admin do Django tem uma função clara: administrar o sistema. Tanto que ela foi feita para ser acessada só por usuários do “staff“.

Ela foi feita para que os desenvolvedores do site não percam tempo fazendo cadastros “bobinhos” que precisam ser mantidos só pelos funcionários da empresa.

O Django nasceu no mercado editorial e o primeiro projeto desenvolvido nele foi um gerenciador de conteúdo (CMS). A interface de Admin do Django servia (serve?) para que os editores, jornalistas, autores, etc. inserissem conteúdo nos sites dos jornais do grupo The World Company.

A interface Admin não foi feita para você desenvolver toda a sua aplicação nela. Ela é muito poderosa e até faz algumas coisas além de permitir somente a inclusão, visualização, alteração, e exclusão de conteúdo. Ela permite ordenar registros, efetuar buscas, definir ações, etc. Mas paramos por aí.

Funcionalidades mais elaboradas ou que precisam ser acessadas por pessoas que não fazem parte do “staff” continuam tendo o seu desenvolvimento necessário.

No site Ludeos, que foi desenvolvido em Django, a interface Admin ainda é usada para verificar os pagamentos dos cursos, e na manutenção das lojas e produtos. O fato do Django oferecer essa funcionalidade pra gente fez a diferença entre um projeto “atrasado” e um projeto “no ar”.

Mas o uso da interface Admin é um fator limitante para o nosso uso do sistema. Fica claro que, para que o projeto evolua, será necessário tirar algumas dessas funcionalidades da interface de Admin.

Em resumo: usem a interface Admin, mas saibam que em determinado momento ela pode limitar as suas ações e, nestes casos, Django oferece outras alternativas pra te ajudar a deixar a interface Admin: Generic Views. Falaremos sobre elas em outra oportunidade.

Pythonologia será o blog da Triveos

Osvaldo Santana Neto — Fri, 18 Jun 2010 20:29:17 +0000

Algumas pessoas já devem ter notado algumas mudanças ou até mesmo algum flood de posts antigos devem ter inundado os agregadores e leitores de notícias (pelo qual pedimos desculpas). Essas mudanças são conseqüência da mudança do blog Pythonologia que, a partir de agora, passa a ser o blog “oficial” da minha empresa.

Razões para a mudança

A Triveos, minha empresa, precisava ter um blog para falar sobre desenvolvimento de software, Python, Django e sobre empreendedorismo.
A opção de criar um blog novo foi rapidamente descartada por um motivo bastante claro: falta de tempo para atualizá-lo. Até então eu tinha 2 blogs e não conseguiria lidar com um terceiro.
Com o lançamento da versão online do nosso Curso de Desenvolvimento Web com Python e Django, nós decidimos adotar a estratégia de fazer da Triveos a maior referência em desenvolvimento Python e Django do país (algo muito difícil de se fazer).
O Pythonologia é bem ranqueado nos sites de busca quando o assunto é Python e Django e torná-lo o blog da Triveos seria um passo interessante em direção ao nosso objetivo.

O que muda

Posts com conteúdo mais “pessoal” ou não relacionado aos tópicos que nos interessavam foram migrados para o meu novo blog pessoal.
O Pythonologia ganhou um novo editor: @dsracoon. O Thiago é o meu sócio aqui na empresa e também é desenvolvedor.
A organização dos posts por tags (que eu havia abandonado) voltarão a funcionar.
A freqüência dos posts vai aumentar.
Foco exclusivo nos tópicos: Desenvolvimento, Web, Python, Django e Empreendedorismo.
Voltarei a fazer resenhas de livros relacionados aos tópicos do blog.
A publicidade do blog será restrita aos produtos da Triveos. Deixará de ser ostensiva e passará a ser informativa (aka saem Adsense, Submarino, etc).
O domínio pythonologia.org agora redireciona para blog.triveos.com.br (nos casos dos posts ‘pessoais’ ele redireciona para o blog “E-Mail Público”)

O que não muda

Manteremos o tom informal e pessoal que, em nossa opinião, deve ser característica de todos os bons blogs.
O blog continua com a função de informar, ensinar e de compartilhar conhecimento sobre os tópicos listados acima. Não usaremos o blog como um painel de anúncios da Triveos.

Conclusão

Espero que quem já acompanha o blog continue a acompanhar e que novos leitores se interessem por ele.

Devido às mudanças (que foram grandes) é possível que alguns problemas aconteçam ao tentar acessar algum artigo. Agradeceríamos muito se vocês nos avisassem desses problemas postando um comentário aqui mesmo.

Django-ZODB 0.2rc1 lançado

Osvaldo Santana Neto — Tue, 08 Jun 2010 21:05:32 +0000

Post rápido pra anunciar que hoje eu subi o módulo django-zodb-0.2rc1 no PyPI. Publiquei essa versão para que outros pythonistas que usam Django e/ou ZODB possam colaborar com o projeto.

A ajuda que preciso com maior urgência é para corrigir os meus erros de inglês na documentação (deve ter toneladas deles no README.rst) e completá-la (removendo os XXX). Consertando os bugs que forem aparecendo e finalizando a documentação eu já lanço a versão 0.2final. Modificações que mudem a API só entram nessa versão se forem pra corrigir erros de design.

Novas funcionalidades podem ser incorporadas em um branch separado. O projeto está hospedado no github, portanto, isso é fácil de se fazer. Tem uma mini-lista de coisas que ainda faltam ser feitas no fim do arquivo README.

Layout provisório do site do projeto Django-ZODB

Já tenho um template pronto para o site do projeto mas não poderei trabalhar nisso nos próximos dias. Se alguém quiser mexer nisso é só falar comigo.

Novo sistema de comentários

Osvaldo Santana Neto — Wed, 05 May 2010 17:06:38 +0000

Quem acompanha o Pythonologia via feed não deve ter notado ainda mas quem visita o site regularmente deve ter notado que eu troquei o sistema de comentários do blog para o Disqus.

Fiz essa troca pelos seguintes motivos:

Centralização na moderação dos meus dois blogs: esse aqui e o E-Mail Público
Opções ‘infinitas’ de autenticação para comentários. Acho muito chato ter que me cadastrar em um blog para comentar e acredito que tem mais pessoas que pensam como eu.
Funcionalidades de ‘rede social’ nos comentários. O seu perfil no Disqus é integrado e você pode usá-lo em qualquer blog que utilize esse sistema.
Quantidade grande de ferramentas providas automaticamente (sem a necessidade de instalar, e manter plugins do WP).

Percebi que algumas páginas ainda exibem o sistema antigo de comentários (graças à toneladas de caches que eu uso nesse site). Podem usá-lo sem problema nenhum. Estou monitorando os dois sistemas e fazendo o ‘sync’ entre eles o tempo todo. Pode demorar um pouquinho mais pro seu comentário aparecer no sistema novo mas aparece.

Se notarem algum problema mais grave é só entrar em contato comigo por e-mail ou via twitter mesmo.

Trabalhando com Python e Django à moda Osvaldo

Osvaldo Santana Neto — Mon, 26 Apr 2010 01:45:40 +0000

Esse post está aqui para ser usado por mim como referência futura mas, como pode ser útil para outras pessoas vou deixá-lo público aqui no blog.

Software

Trabalhei muito tempo com Linux (e alguns outros Unices) e de três anos pra cá sou mais um Apple Fanboy que usa o excelente OS X. Mas acho que boa parte das dicas aqui ainda são úteis para usuários de Linux.

Terminal.app – Porque Mac é máquina pra ‘macho’ :D
bash – Pesadão, bloat, mas não consegui me habituar com outro. É o default do OS X.
Vim – Esse é o editor pra tudo. É difícil de aprender a usar mas é um F1. Depois que aprendemos a lidar com ele a gente voa. Uso a versão texto que acompanha o OS X.
TextMate – Esse eu uso para o desenvolvimento ‘pesado’. Dá pra usar o Vim pra isso também. Mas dependendo do meu humor eu escolho o TextMate para algumas coisas.
Rudix – O OS X não vem com tudo mas você encontra o que falta no Rudix.
Git – Uso o git pros meus projetos mas também tenho o Mercurial, Bazaar, Subversion, … instalados para contribuir com outros projetos open-source
virtualenv – ter um ambiente isolado para cada projeto Python onde você trabalha é muito legal. Já escrevi sobre o virtualenv aqui.
pylint e pyflakes – Analisadores estáticos de código.

Diretórios básicos

$HOME/
- Work – Diretório onde os projetos em que trabalho ficam.
- bin – Diretório com scripts, binários estáticos, etc. Esse diretório fica no $PATH

Configuração

Sempre que eu falar sobre um arquivo de configuração específico você pode encontrá-lo no endereço: http://github.com/osantana/personal.

Os arquivos ‘.’ (ponto)

.profile

Configurar 3 aliases: mv='mv -i' e cp='cp -i' pra evitar acidentes com arquivos sendo sobrescritos e ls='ls -G' para habilitar cores no comando ls.
Configurações genéricas para cores no terminal
Definir o vim como EDITOR padrão.
Definir LANG e LC_CTYPE como en_US.UTF-8 para que o Mercurial e alguns outros softwares funcionem corretamente.
Adicionar o diretório $HOME/bin ao $PATH. Nesse diretório eu jogo todos aqueles programinhas utilitários usados no dia a dia.
Configurações Python:
- export PYTHONSTARTUP="$HOME/.pystartup.py"
- source ~/bin/django_bash_completion
Configuração Java: export JAVA_HOME="/Library/Java/Home"
Configuração Ruby: adicionar $HOME/.gem/ruby/1.8/bin ao $PATH

Eu uso virtualenv em todos os meus projetos então crio duas funções para ativar os ambientes e entrar nos diretórios desses projetos:

# Uso: p nome_do_projeto
p() {
    cd ~/Work/$1*
    [ -f bin/activate ] && source bin/activate
}
 
# Uso: c
c() {
    [ -d "$VIRTUAL_ENV" ] && cd $VIRTUAL_ENV
}

.gitconfig

[user]
	name = Osvaldo Santana
	email = osantana na triveos.com
[color]
	status = auto
	diff = auto
	branch = auto
	ui = auto
	grep = auto
[alias]
	st = status
	ci = commit
	co = checkout
[merge]
	tool = opendiff
[core]
	legacyheaders = false
	excludesfile = /Users/osantana/.gitignore
    whitespace = trailing-space,space-before-tab
[apply]
    whitespace = fix
[repack]
	usedeltabaseoffset = true
[git-tmbundle]
	gitx-path = /Application/GitX.app/
[mergetool "opendiff"]
	cmd = opendiff
	trustExitCode = true
[clean]
	requireForce = false

.gitignore

.DS_Store
*.py[co]
*.tmproj
*~
*.swp*

.inputrc

Eu uso o modo vi também no console. Neste arquivo fica essa configuração e mais umas outras que deixam o comportamento do prompt do Mac mais parecido com o do Linux.

Já falei sobre essas configurações aqui no blog. Use por conta e risco.

.pylintrc

As configurações que eu uso para análise estática do código que eu produzo. Eu rodo o pylint antes de fazer o commit do meu código. Durante o desenvolvimento eu uso somente o pyflakes que é mais simples e rápido mas faz uma análise mais superficial do código. Eu costumava usar o pep8.py mas já faz um tempo que o aposentei.

.pystartup.py

Script executado pelo interpretador Python ao entrar no modo interativo. Eu configuro o ‘auto-completion’ do prompt interativo do Python, gravo o histórico de comandos, etc.

Infelizmente ele não funciona com o Python padrão do Mac porque o mesmo não é compilado com a biblioteca readline. Mas no Linux ele (deve) funcionar certinho.

.vimrc

Esse é o meu famoso arquivo .vimrc. Ele não tem nada de muito especial.

Outros arquivos

Existem outros arquivos mas, nestes casos, eles contém informações privativas e não faria sentido colocar aqui pra vocês :)

Criando e Usando um projeto Python (com Django)

Para exemplificar vamos criar um projeto “pythonologia”:

~ $ cd ~/Work
Work $ virtualenv --no-site-package pythonologia
New python executable in pythonologia/bin/python
Installing setuptools............done.
Work $ p pythonologia
(pythonologia) pythonologia $ easy_install django
(pythonologia) pythonologia $ django-admin.py pythonologia
(pythonologia) pythonologia $ cd pythonologia
(pythonologia) pythonologia $ git init
(pythonologia) pythonologia $ git add *.py
(pythonologia) pythonologia $ git commit -m "Initial commit"

Projeto criado e a estrutura de diretórios vai ficar mais ou menos assim:

~/Work/pythonologia
       |____ pythonologia
       |     |____ app_django1
       |      \___ app_django2
       |____ bin
       |____ include
        \___ lib
             \____ python2.6
                   |____ distutils
                    \____ site-packages

Os arquivos que não são mantidos no repositório Git ficam no diretório ~/Work/pythonologia ou em um diretório ~/Work/pythonologia/files. O arquivo de projeto do Textmate, por exemplo, fica em ~/Work/pythonologia/pythonologia.tmproj.

Eu também crio um link simbólico ~/Work/pythonologia/django -> ~/Work/pythonologia/lib/pythonX.X/site-package/Django-1.1.1-py2.6.egg/django para dar uma ‘espiada’ no código do Django quando necessário.

Quando eu quero trabalhar num outro projeto eu faço:

(pythonologia) pythonologia $ deactivate
pythonologia $ p outro_projeto
(outro_projeto) outro_projeto $

Eu estou num diretório qualquer e quero voltar para o diretório raiz do projeto basta fazer:

(pythonologia) ~ $ c
(pythonologia) pythonologia $

E os programadores, onde erram?

Osvaldo Santana Neto — Sun, 25 Apr 2010 15:54:58 +0000

O @marionogueira provocou e eu vou responder.

Mas antes vou explicar porque eu compartilho da visão de que o trabalho de desenvolvedor guarda semelhanças com o trabalho de um artista (importante dar destaque à palavra “semelhança” para não pensar que as coisas são iguais).

Como programador você pega uma especificação abstrata que se parece com uma ‘inspiração’ e começa a trabalhar nela até obter algo ‘bruto’, aí você vai lapidando (iterando) sobre esse trabalho, simplificando, e aproximando o software daquela inspiração (especificação).

Nesse processo o programador vai deixando seu “estilo” no código. Na escolha de algorítmos, de estruturas de dados, nos textos de comentários e até mesmo no “Coding Style”. Essas características são tão notáveis que depois de um tempo é possível identificar o autor do código mesmo quando ele não está ‘assinado’.

Uma diferença importante entre o trabalho de artistas e de programadores é que raramente vemos o trabalho em equipe (times) no universo das artes e o mesmo é quase uma regra no mundo do software.

Mas daqui para frente eu vou falar sobre um tipo específico de artistas: aqueles que trabalham sob encomenda pintando retratos de reis e nobres para garantir o seu sustento. E para ilustrar o meu raciocínio vou usar uma das obras de arte mais conhecidas no mundo: a Monalisa.

A Monalisa (La Gioconda) foi uma obra encomendada por Francesco del Giocondo a Leonardo Da Vinci. Existe muitas versões, mitos e mistérios que cercam essa obra mas vamos nos ater à “história oficial”.

Francesco passou uma especificação para Da Vinci (ele queria um retrato de sua esposa Lisa Gherardini) e provavelmente especificou prazo e preço. Ou talvez tenham feito um contrato de escopo aberto? Não sei, não estudei essa história muito a fundo.

Leonardo Da Vinci, então, fez os primeiros esboços e foi apresentando esses esboços ao contratante. Talvez não tenha feito isso porque o contratante confiava plenamente na capacidade de entrega dele. Mas não teria sido vergonha se tivesse que apresentar os esboços no meio da execução do projeto.

O resultado final foi um trabalho encomendado, executado no prazo combinado, à um custo determinado e que, mesmo assim, era uma obra de arte.

Curiosamente o escritório da Triveos é vizinho de uma escola de pintura. Todo dia passo em frente à sala de aula e vejo o trabalho dos alunos. É fácil perceber que não tem nenhum Leonardo Da Vinci ali (por enquanto). Falta-lhes experiência. Prática. Com o tempo e empenho eles se transformarão em bons artistas. Talvez gênios.

O mesmo acontece com os programadores. Só com a prática, a experiência, e com o domínio da técnica um programador se tornará um ‘artista’ de verdade.

Mas voltando à questão levantada pelo @marionogueira…

O ‘mundo’ está errado no gerenciamento dos programadores quando eles mudam escopo, prazo e custo dos projetos a todo o instante e ainda exigem uma obra de arte como resultado do trabalho. Ou quando não permitem que o ‘artista’ trabalhe ao seu modo.

A Monalisa seria uma obra de arte se, durante o seu desenvolvimento, o contratante desse palpites sobre as cores e cenários deveriam ser usados na obra?

Mas os programadores também erram!

Erram quando aceitam o desafio de desenvolver uma obra de arte sem ter o domínio adequado da técnica, a prática e a experiência necessária para transformar aquela especificação em arte.

Em projetos ideais onde o escopo é claro, o prazo é razoável e custo está sob controle os programadores falham quando não compreendem que, mesmo tendo sido encomendada, a ‘obra de arte’ é dele também. Sem essa compreensão eles deixam de se comprometer com sua execução.

Mesmo tendo sido encomendada, Da Vinci não fez a Monalisa ‘nas coxas’. Ele fez o máximo possível para entregar uma obra de arte única. Isso fica claro em projetos open-source onde a obra e o nome do artista fica público.

Um artista não precisa de foco e disciplina para se inspirar. Aliás, isso pode até atrapalhar. Mas para executar a obra é necessário muito foco e muita disciplina. Principalmente se a obra foi encomendada e tem custos e prazos pré-estabelecidos.

O programador falha quando ele não tem foco e disciplina no seu trabalho. Twitter, MSN, GTalk, IRC e outros sugadores de foco, hoje, ficam mais tempo em funcionamento do que a IDEs, editor de textos e outras ferramentas de desenvolvimento. Eu sei. Eu vivo isso.

Fora isso eles podem errar em outras questões que envolvem relacionamento interpessoal, trabalho em equipe, ética, etc. Mas nessas questões todos podem errar.

Como garantir um emprego de desenvolvedor

Osvaldo Santana Neto — Wed, 21 Apr 2010 19:34:32 +0000

Post rápido e ligeiro com uma lista de atributos que certamente vão garantir a sua vaga como desenvolvedor em qualquer empresa que valha a pena trabalhar.

Cada atributo tem um dos graus de importância abaixo (do mais importante para o menos importante):

Vital – característica mais do que essencial para vagas de desenvolvedor ou para qualquer outro tipo de posição.
Essencial – característica imprescindível para um desenvolvedor.
Importante – característica importante mas não imprescindível. Pode-se contratar um desenvolvedor que não tenha essa característica desde que haja um compromisso do mesmo em desenvolvê-la.
“Plus” – não faz muita diferença mas pode ser uma característica que pode desempatar (a favor de quem a tem) numa disputa entre dois ou mais candidatos.
Desnecessária – não faz diferença alguma.
Condenável – característica que pode depor contra a sua candidatura.

O que está escrito aqui é a minha visão sobre o assunto. Algumas empresas contratantes podem divergir no grau de importância de cada atributo. Outras, por questões legais, podem exigir determinada característica listada como

Comunicação (vital) – comunicação escrita e verbal, capacidade de argumentação e de expressar idéias e conceitos.
Prazer em programar (vital) – você programa nas horas vagas? Não? Então desista. Corra atrás de trabalhar com aquilo que você faz nas horas vagas. Todos ficarão gratos.
Prazer por aprender coisas novas (vital) – Veja… eu disse “prazer por” e não “interesse em”.
Inglês para leitura (vital) – não dá mais tempo de esperar por traduções de documentação.
Programação (essencial) – tem que saber teoria e prática. Conhecer algoritmos, estruturas de dados, conceitos de OO, paradigmas de programação, teoria da computação, matemática, …
Familizarização rápida com ferramentas (essencial) – você é capaz de corrigir um bug numa aplicação escrita numa linguagem que você não conhece em quanto tempo? Consegue produzir código numa linguagem nova em menos de uma semana?
Inglês para escrita (essencial) – grande parte dos softwares, bibliotecas e sistemas que usamos hoje são desenvolvidos por estrangeiros. Freqüentemente precisamos trocar um e-mail com esses desenvolvedores.
Conhecer bem ao menos uma linguagem (essencial) – essa linguagem varia de acordo com o que você deseja desenvolver, mas ela tem que ser uma espécie de ‘segundo idioma’ seu. No meu caso essa linguagem é Python, mas poderia ser outra.
Inglês conversação (importante) – grande parte dos lugares bacanas pra se trabalhar, hoje, são estrangeiros, tem filiais fora do país ou estão contratando estrangeiros pros seus times. Poder conversar com eles é importante.
Ter familiaridade com ‘linguagens chave’ (importante) – algumas linguagens de programação estão presentes em tantos lugares que não é mais possível desconhecê-las: assembly de pelo menos 1 plataforma, C, Shell Script, linguagem funcional (fico devendo essa :D), linguagem OO (Java, Smalltalk, Python, Ruby, …).
Participação em projetos FLOSS (importante) – universo perfeito para exercitar, experimentar, participar, desenvolver, aperfeiçoar, … todas as características listadas aqui. Alguns lugares onde trabalhei sequer pedia curriculums para contratar um desenvolvedor e usavam só a participação dos mesmos em projetos FLOSS
Formação acadêmica (plus) – desde que seja numa boa faculdade (USP, Unesp, UNICAMP, UF*, UTF*, PUC*, …) podem indicar que os alunos aprenderam alguns fundamentos importantes de programação. O convívio social dos alunos para estudo, execução de projetos e trabalhos também acrescenta.
Certificações (desnecessária) – empresas que pedem ou avaliam certificações não podem ser empresas onde valha a pena trabalhar. Empresas que usam certificações são aquelas que são incapazes de avaliar corretamente os candidatos e ‘terceirizam’ essa tarefa para as entidades certificadoras. Uma empresa incapaz de avaliar um candidato não pode ser capaz de lhe dar boas condições de trabalho.
“Corporacionismo” (condenável) – profissionais que falam “frases que agregam valor e aumentam a sinergia do time junior de colaboradores” ou que acham fundamental a existência de uma regulamentação no mercado de trabalho de TI geralmente são aqueles que não querem ou não conseguem se destacar como desenvolvedor por conta própria e precisa de uma ‘mãozinha’ do governo pra isso.

Esse artigo descreve algumas características que um desenvolvedor deve ter para conseguir um emprego. Mas se o desenvolvedor quiser empreender e montar o seu próprio negócio, ele precisa das mesmas características? Sim, mas com graus de importância diferentes. Além desses atributos são necessários alguns outros que tentarei abordar em outro artigo.

Python ainda é pythônico?

Osvaldo Santana Neto — Sun, 11 Apr 2010 01:04:46 +0000

Eu estava lendo um (longo) artigo que fala sobre várias coisas sobre como desenvolvíamos software no passado e como desenvolvemos hoje, etc… E num determinado momento ele fala sobre bibliotecas, frameworks e sobre um conceito denominado por ele “radius of comprehension“.

O conceito de “radius of comprehension” é simples: dado um determinado trecho pequeno de código, quanto de código a mais você precisa ler para entender o que ele faz. Quanto menor o “radius of comprehension” melhor.

Ao ler isso eu me lembrei de uma palestra do Luciano Ramalho onde ele fala que gosta da linguagem Python (e da idéia de algo ser ‘pythonico’) porque ela “cabe na cabeça” dele e acho que isso tem uma relação direta com a idéia de “radius of comprehension“.

Eu também pensava da mesma forma que o Luciano. Achava que Python “cabia” na minha cabeça. Mas hoje eu devo admitir que isso é parcialmente verdade.

Em primeiro lugar eu acho que a linguagem vem crescendo demais desde a versão 2.2. Adicionando funcionalidades e “acúcares sintáticos” cujos benefícios podem ser facilmente questionados.

Mas não vou falar muito da linguagem não. Vou falar de alguns módulos da biblioteca padrão do Python que são praticamente impossíveis de serem usadas sem ter a documentação à mão:

logging – esse é o pior de todos. Não tem uma única vez que eu não preciso recorrer à documentação do módulo pra fazer algo “bobo”. Sei que um “logging.log(…)” basta para o básico, mas se você precisa de algo básico+1 você já se vê obrigado a ler toda a documentação do módulo. Acho que o problema desse módulo foi tentar copiar o log4j do mundo Java. Todos nós conhecemos o gosto por “over engineering” dos programadores Java.
ConfigParser – não tenho muito a dizer. Porque esse módulo precisa daqueles conceitos complicados de configurações “globais”, busca de arquivos em múltiplos diretórios, etc. Ele poderia implementar o simples e fácil e deixar as extensões para bibliotecas de terceiros.
email – precisei usar esse aqui uma única vez e desde então eu tremo de medo sempre que alguém me pede pra “manipular e-mails” em uma aplicação Python. Sei que manipular e-mails é complicado se considerarmos a quantidade de “variações dos padrões” existentes num serviço que tem quase a idade da Internet, mas as abstrações devem ser construídas para nos poupar desses detalhes, não?
xml.dom e xml.sax – eu já não gosto de XML, imagina manipular XML com essas duas bibliotecas “podres”. Se eu pego um código pra dar manutenção e esse código usa uma dessas duas bibliotecas eu triplico o valor do serviço.
re – neste caso eu não acho que seja muito culpa do Python, mas peça pra alguém que conheça regex mas não conheça Python explicar a diferença entre re.search() e re.match(). Ou mostre pra ele uma regex com “(?P.*)” significa.

Além dessas tem outras que não vou me lembrar. Tem também algumas bibliotecas, módulos e frameworks no atual “eco sistema” do Python que simplesmente não entram na minha cabeça:

Zope e Plone – a turma do PythonBrasil já conhece essa história. Eu tentei bem umas 3 vezes estudar essa dupla e nas 3 eu não consegui ir além de abrir a interface de administração do Zope. Mas de duas uma: ou sou burro demais ou o troço é desnecessariamente complicado. Por sorte o ZODB funciona separadamente porque esse sim é poderoso e fácil de usar.
Buildout – esse eu já usei basicamente pra instalar alguns programas mas é uma caixa preta completa pra mim. Não tenho certeza, mas acho que ele nasceu no (ou em função do) Zope/Plone e talvez isso explique um pouco disso. Eu não sei direito se ele é um sistema de build, um sistema pra criação de ambiente de desenvolvimento, ou se é algum sistema alienígena de IA.

Eu sei que os problemas que temos que resolver hoje em dia são bem mais complexos do que os que tínhamos que resolver quando comecei a programar, mas problemas complexos não precisam de soluções que deixem transparecer essa complexidade.