Segue para o conteúdo

Artigos marcados como ‘desenvolvimento’

25
abr

Trabalhando com Python e Django à moda Osvaldo

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:
  • 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 $
25
abr

E os programadores, onde erram?

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.

21
abr

Como garantir um emprego de desenvolvedor

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):

  1. Vital – característica mais do que essencial para vagas de desenvolvedor ou para qualquer outro tipo de posição.
  2. Essencial – característica imprescindível para um desenvolvedor.
  3. 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.
  4. “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.
  5. Desnecessária – não faz diferença alguma.
  6. 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.

« Artigos Anteriores
Artigos Recentes »