Pythonices, simplificar objectos de dados.

Um objecto de dados só tem estado, não tem comportamento. Ou traduzindo para python: são instâncias de classes sem métodos, apenas com variáveis.

Formas de definir classes de dados.

Auto iniciar locais a partir dos argumentos

É a solução clássica e mais explícita:

class P:
    def __init__(self, sln, dll=None, aspnet=None): 
        self.sln = sln
        self.dll = dll
        self.aspnet = aspnet

Solução dinâmica

Compacta, python voodoo.

class P:
    def __init__(self, sln, dll=None, aspnet=None): self.__dict__.update(locals())

Ou para ser-se pedante

Falta remover o self do próprio dicionário.

class P:
    def __init__(self, sln, dll=None, aspnet=None): self.__dict__.update(locals()); del self.self

E agora uma coisa completamente diferente: namedtuple

Continuando no exemplo acima, mas desta vez sem defaults.

from collections import namedtuple
P = namedtuple("P", "sln dll aspnet".split())

p = P("xpto.sln", "xpto.dll", None)
print p

# recuperando a solucao classica
class Pc:
    def __init__(self, sln, dll=None, aspnet=None): 
        self.sln = sln
        self.dll = dll
        self.aspnet = aspnet

    def __str__(self): return str([self.sln, self.dll, self.aspnet])

p = Pc("xpto.sln", "xpto.dll", None)
print p

Tem como resultado:

P(sln='xpto.sln', dll='xpto.dll', aspnet=None)
['xpto.sln', 'xpto.dll', None]

---

Resumindo:

• o namedtuple fornece uma forma simples e legível de definir objectos de dados simples;
• as formas compactas são úteis para prototipagem.

Ubíquo Word.

O Word não só matou a documentação técnica como tomou o mundo da documentação de assalto. Desde a composição de documentos de notas com 3 ou 4 linhas, a livros com centenas de páginas, o seu uso é universal. Como as pessoas se habituaram ao Word, exigem receber documentos de Word. A situação chega a ser tão caricata como os seguintes casos reais:

• Cerca do ano 2000 enviei o meu CV em PDF a uma conhecida empresa. Responderam-me a dizer que não o conseguiam abrir – na altura o acrobat reader não estava muito disseminado – e que eu enviasse logo a versão “Word”. Algo impossível tendo em conta que eu não tinha usado sequer o Word para o produzir¹.

• Há uns anos enviei um artigo a um colega meu para revisão. Ele respondeu, algo frustrado, que tinha tido muito trabalho a editar o meu artigo porque eu não estava a usar um formato standard, e recomendou-me que da próxima vez o fizesse, que enviasse um doc de Word. O formato que lhe tinha enviado era HTML.
• Num sítio onde trabalhei havia um processo manual para fazer backups. Eu estava lá contratado para fazer administração de sistemas, mas aproveitei algum tempo livre para desenhar e desenvolver um software que automatizava o sistema de backups. O cliente ficou satisfeito com esse sistema novo mas alertou que não havia documentação. Compilei num README.txt toda a informação técnica sobre esse sistema. Como estava construído, como se instalava no master e nos slaves, como se corria… no dia seguinte mostrei o ficheiro de texto ao cliente. Instantaneamente vira-se para mim e diz: “Isto não é nada” (mesmo assim). Perguntei porquê, o que esperava ter encontrado que não estivesse no documento. Olhou-me de forma estranha, hesitou um pouco e disse que aquilo não era um documento. Apenas. Na realidade ele esperava a mesma informação só que num ficheiro Word. Um ficheiro de texto, apesar de conter o mesmo conteúdo, não era considerado “um documento”.
• Por fim, ainda me recordo de algumas coisas me terem caído ao chão – e não vou detalhar se em sentido alegórico ou não – quando vi este requisito por parte de uma empresa pública: “O adjudicatário entregará à entidade adjudicante (…) a seguinte documentação em suporte digital (.pdf e .doc/.ppt/.rtf) e em papel: (…)”.

---

1. tinha usado groff.↩

15 anos de desenvolvimento de software.

Ao longo de 15 anos na área do desenvolvimento de software, sobretudo no mundo das telcos, eis o cenário que pinto sobre o estado de arte nacional.

1. Não se faz 100% desenvolvimento: ao longo do tempo acabam por se fazer coisas tão díspares como administração de sistemas, coaching, entrevistas, gestão de projectos, burocracia e, sobretudo, pré-venda. Varia com cada um, mas há sempre desvios. Razões para isto?
   • não existe mercado em Portugal para manter uma função exclusiva de desenvolvimento;
   • o desenvolvimento feito em Portugal tipicamente é básico, logo pode ser feito por juniores, logo…
   • não há carreira técnica;
   • não há investimento em inovação, quanto mais em pesquisa;
   • a inovação existente resulta da utilização ou colocação em prática de novos softwares ou práticas vindas de fora, e.g. inovação por compra de novos produtos ou upgrade de versões.

2. A estratégia de TI empresarial está sujeita aos fornecedores tecnológicos.

3. O desenvolvimento nacional é pouco ambicioso e simples: a maior parte dos projectos desenvolvidos de raiz são uma implementação básica – ainda que por vezes massiva e/ou complicada – de um modelo source-process-dump. E.g. boa parte das aplicações web.

4. As necessidades de software mais exigente, do ponto de vista de complexidade, são normalmente supridas por soluções 3rd party.

5. Os projectos atrasam-se ou correm mal raramente por questões técnicas – já que são simples q.b. – mas por:
   • requisitos mal especificados inicialmente e alterados de forma inconsistente – continuando mal especificados – ao longo do projecto;
   • problemas de integração com outros sistemas;
   • indisponibilidade de ambientes e dados.

6. A tecnologia escolhida tem pouco impacto no projecto e é irrelevante para a organização: mesmo que outras linguagens e plataformas melhorassem 10x a produtividade no desenvolvimento e deploy, esse tempo seria diluído nas ineficiências gerais do projecto.

7. A falta de qualidade do código é suprida via testes, ou seja, prática de code-and-fix.

8. Os programadores juniores apresentam lacunas, que são impeditivas de realizar software bem construído embora suficientes para realizar os nossos projectos básicos (ainda que sem uma boa construção), em:
   • estruturação;
   • abstracção;
   • automatização;
   • scripting e prototipagem.

   As práticas de código mais comuns baseiam-se em excesso de programação imperativa mal estruturada com abuso de copy paste. Há evidência baseada em estudos que estes factores não melhoram com a experiência.

Reuniões como promoção de visibilidade.

«Additionally, meetings give visibility, an essential factor to anyone who hopes to rise in big-company hierarchy. You don’t get noticed by listening thoughtfully, so anyone who’s there for visibility is likely to be a talker. The worst meetings feel like congregations of windbags with nobody listening and everybody speaking or waiting to speak. Because there are so many who need to speak, meeting duration increases seemingly without bound.»

– “Meetings, Monologues, and Conversations” in Peopleware: Productive Projects and Teams (3ª edição), Tom DeMarco, Timothy Lister

Custa assim tanto perceber?!

Esta passagem deste magnífico livro fez-me lembrar um episódio real. Há cerca de 10 anos participei num grande projecto. Inicialmente tinha sido contratado um consultor da Microsoft, temporariamente, para arrancar com a solução técnica, mas como ninguém da equipa inicial percebia o que ele estava a fazer, integraram-me no projecto para acompanhar e dar continuidade ao seu trabalho. Rapidamente me tornei o “arquitecto” de facto do projecto e um dos seus grandes motores, sobretudo a nível de inovação.

Esse projecto – bem como o meu papel no mesmo – veio recentemente a tema com uma pessoa que também tinha estado envolvida no mesmo, embora como parte interessada, externa à equipa. Ambos desconhecíamos o envolvimento do outro. A reacção dele: “Estiveste no projecto? Não me lembro de ti nas reuniões!” Q.E.D.

Pythonices, obter vários valores de uma lista.

Objectivo: processar grupos de 3 linhas seguidas de um ficheiro.

Soluções…

Juntar as 3 no loop usando informação de estado

with file("pythonices") as f:
    lines = []
    for line in f:
        lines.append(line)
        if len(lines) == 3:
            process(lines)
            del lines[:]

A lista lines é usada para manter a contagem das linhas lidas. Chegando a 3, processa-as.

• a lógica de juntar as linhas torna o ciclo pouco claro;
• obriga a manter estado explícito.

Obter as 3 dentro do ciclo

with file("pythonices") as f:
    while 1: 
        try: 
            l1 = next(f)
            l2 = next(f)
            l3 = next(f)
            process([l1, l2, l3])
        except StopIteration: 
            break

• a obtenção de linhas é agora linear;
• a construção é mais simples;
• mas usa-se o bloco try-except para controlar a paragem do ciclo.

Alterando a source para fornecer logo as 3 linhas

with file("pythonices") as f:
    for l1,l2,l3 in zip(f,f,f): 
        process([l1,l2,l3])

Mais simples e legível.

E se o ficheiro não for múltiplo de 3? Os casos anteriores descartam as linhas extras. Com a última solução podemos controlar esse comportamento facilmente mexendo apenas na “fonte”. Neste caso usando itertools.izip_longest que funciona como o zip, só que convertendo os valores extra – caso os haja – num valor pré-definido.

import itertools

with file("pythonices") as f:
    for l1,l2,l3 in itertools.izip_longest(f,f,f, fillvalue=None): 
        process([l1,l2,l3])

A vantagem desta solução face às anteriores foi ter separado e abstraído a tarefa em duas instâncias: a obtenção das fontes e o seu processamento.

Criando funções que representam explicitamente as abstracções fica:

import itertools

def process(x): print x

def consume(f): 
    for l1,l2,l3 in itertools.izip_longest(f,f,f, fillvalue=None): 
        yield l1,l2,l3

with file("pythonices") as f:
    for l1,l2,l3 in consume(f): 
        process([l1,l2,l3])

De notar que não foram as funções que criaram as abstracções. As funções são estrutura. A primeira solução desta secção tem o mesmo nível de abstracção que esta última. Posso voltar no futuro ao tema abstracção.

Pythonices, list -> map.

Como é que consigo facilmente converter o texto “p_dist m show_acs curses tget termcap” num dicionário chave-valor, ou seja, nisto: {'tget': 'termcap', 'p_dist': 'm', 'show_acs': 'curses'} ?

Uma simples iteração

Criar um dicionário vazio, iterar a lista dois a dois, fazer chave igual ao próximo.

t = "p_dist m show_acs curses tget termcap".split()

x = {}
for i in range(0, len(t), 2): x[t[i]] = t[i+1]
print x

Zip it

Substituir a iteração 2 a 2, por uma construção funcional – zip – que extrai dois elementos de cada vez da lista. Para isso a lista precisa de ser encapsulada num iterador, que funciona como um consumidor linear da lista.

t = "p_dist m show_acs curses tget termcap".split()

x = {}
it = iter(t)
for k,v in zip(it, it): x[k] = v
print x

Compactar o zip

• [it,it] <=> [it]*2
• f(it,it) <=> f(*[it]*2)

logo…

t = "p_dist m show_acs curses tget termcap".split()
x = {}
for k,v in zip(*[iter(t)]*2): x[k] = v
print x

Eliminar o loop explícito

• zip(*[iter(t)]*2) = [('p_dist', 'm'), ('show_acs', 'curses'), ('tget', 'termcap')]

O lado direito é uma association list (alist), que é a representação python de um dicionário. Logo…

t = "p_dist m show_acs curses tget termcap".split()
x = dict(zip(*[iter(t)]*2))
print x

Verbatim

No limite podemos usar uma só expressão literal para criar um dicionário:

mymap = dict(zip(*[iter("""

chave1  valor1
chave2  valor2
chave3  valor3

""".split())]*2))

Ferramentas Linux, UNIX (2/2)

Multimédia

• sox: o canivete suíço de processamento de som. Desde conversões de formatos a manipulação de efeitos, quase tudo é possível, da linha de comando.
• mplayer/mencoder: o mplayer é mais que um video player da linha de comando (até porque também funciona como audio player). Além de aguentar com praticamente qualquer formato conhecido, também permite fazer processamento e conversões. O mencoder cria, ou converte, formatos de vídeo e som. mplayer -ao null FILE para ver sem som, ou mplayer -vo null FILE para ouvir sem imagem, devem ser os comandos multimédia que mais uso.
• ffmpeg: outro excelente processador / conversor / etc multimédia.

Sistemas, misto

• ddrescue: excelente ferramenta para tentar recuperar dados em drives que estão no processo de entrega de alma ao criador. O ddrescue não aborta a leitura em falhas de hardware e, através da manutenção de um ficheiro de log, permite várias passagens de leitura da drive, gravando apenas os blocos não lidos nas passagens anteriores.
  
• htop: aquilo que o top devia ter sido :)
• xtail: um tail que funciona em directorias, monitorizando todos os ficheiros lá existentes e novos que entretanto lá sejam criados. Não há que saber: xtail /var/log control- para sair, control-c dá o status.
• buffer, mbuffer: o comando buffer implementa um buffer ao nível da shell. O racional é simples: um processo produtor de dados, um processo consumidor de dados, um deles é mais lento que o outro e sofre uma enorme penalização de performance quando resume um bloqueio. Põe-se o buffer no meio e já está :) O mbuffer implementa o mesmo conceito com mais algumas funcionalidades interessantes.

• rename: às vezes as ideias simples são as mais interessantes. rename FROM TO files... renomeia os ficheiros substituindo FROM por TO no seu nome, em que ambos são strings banais (nada de expressões regulares). Por incrível que pareça a esmagadora maioria de renames que faço encaixam neste modelo:

  # xxx.jpeg => xxx.jpg
  rename .jpeg .jpg *.jpeg
  
  # t1.txt t2.txt ... t500.txt => t_001.txt t_002.txt ... t_500.txt
  rename t t_00 t?.txt 
  rename t t_0 t??.txt 
  rename t t_ t???.txt 
  
  # t_001.txt t_002.txt ... t_500.txt => t1.txt t2.txt ... t500.txt
  rename t_00 t t_00?.txt
  rename t_0 t t_0??.txt
  rename t_ t t_???.txt

• star: não sei ao certo o que significa o s antes do tar, provavelmente será s de Schilling, o nome do autor da ferramenta, que também tem outros utilitários começados por s. Independentemente disso, para mim o s é de super, isto é um super tar. Funciona como tar, cpio ou pax e suporta as N variantes de formatos de arquivamento desenvolvidos ao longo da história do Unix. Tem opções de buffering builtin, lê listas de ficheiros a partir do stdin (não mais tar -cf foo.tar `find . expr`), correcto na preservação de todos os atributos dos ficheiros, usa expressões find builtin, detecta compressão automaticamente, por aí fora.

Documentação

• pandoc: é o canivete suíço da documentação em texto com markup. À data a que escrevo isto, a versão 1.12.0.2 lê de 15 formatos diferentes e escreve para 35. Escrito em haskell, é bastante rápido.
• asciidoc: formato de texto com markup para efeitos de documentação. A vantagem deste é ser bastante mais rico que as comuns alternativas (rst, markdown). A quantidade de features permite escrever um livro de alta qualidade tipográfica. Na verdade existem alguns livros em asciidoc.
• Sphinx: um processador de reStructuredText (rst). Tem múltiplos formatos de saída (HTML, Latex, texto simples, entre outras), funcionalidades específicas para documentar código e uma integração especial para python já que foi criado como ferramenta de documentação oficial do projecto.
• Docutils: outro processador de reStructuredText.
• aspell: uma ferramenta da linha de comando para corrigir erros de escrita (validação simples contra dicionário). Útil para desenrascar.

XML

• XMLStarlet: processador de xml da linha de comando. Validações, queries xpath, transformações xslt, até reformatação, está lá tudo. Útil para pequenos scripts e verificações rápidas. Dica: xml fo <file> para reformar xml.
• jing-trang: jing valida xml contra schemas RELAX NG, trang converte entre schemas. Bastante útil… quando é preciso. :)

Outros

• gestão de versões:
  • svn: depois de ter morto o CVS, o subversion tornou-se no sistema de controlo de versões de facto… com repositório central. Continua a ser um bom sistema, provavelmente o mais usado, mas os novos DCVS têm-lhe diminuído a base de utilizadores.
  • git: um sistema de controlo de versões distribuído: cada checkout está associado a um repositório local. Desenvolvido inicialmente pelo Linus Torvalds, popularizou-se brutalmente com a sua adopção pelo github.
  • hg: como o git só que mais elegante e compreensível. :)

• dirdiff: uma ferramenta gráfica de comparação de várias directorias, com capacidades de merging, cópia ou remoção de ficheiros. É um software antigo, em tcl/tk, ainda bastante útil. Depois de se apanhar o truque para editar os merges torna-se numa das ferramentas mais potentes para o efeito. Mas admito que o sistema escolhido seja um bocado confuso inicialmente.

• nvi: o vi original há muito que passou a constar apenas nas tapes de arquivo dos sistemas BSD originais. Keith Bostic reimplementou-o como nvi (new vi), mantendo compatibilidade total face ao original com umas poucas funcionalidades extra de conveniência. O nvi manteve o espírito e tradição do antigo vi, é rápido, correcto (não tem bugs), consome poucos recursos, corre bem as minhas macros – deixando teclas livres para o fazer! – e faz bem o que deve fazer: editar texto. Totalmente a antítese do vim, mas isso são outras histórias.

• VirtualBox: um bom sistema de virtualização, relativamente rápido, é excelente para uso pessoal ou pequenas equipas. 100% manipulável da linha de comando: vboxheadless -s vmname para arrancar, vboxmanage ... para todas as restantes tarefas.

• make: é mais que uma ferramenta de construção de projectos – que aos poucos vai sendo substituído por ferramentas mais modernas e especializadas no domínio respectivo –, para mim funciona com um repositório de pequenas tarefas necessárias num contexto (ver: como são feitos estes artigos).

• units: um programa de linha de comando com uma enorme base de dados de unidades científicas e alguma inteligência associada na conversão.

  # quantas milhas por galão correspondem 6 litros aos 100 km 
  # notar que o programa detectou a inversão das grandezas (reciprocal conversion) 
  units 6l/100km miles/gallon
  reciprocal conversion
  * 39.202431
  / 0.025508622

Spam surreal.

As motivações do spam são conhecidas e têm o seu racional, ainda que ilegítimo. Agora fazer spam assim ultrapassa qualquer nível de compreensão!

From - Wed Oct 26 10:26:54 2011
Return-Path: <loriannelvira@cnh.com>
Received: from cfirg6vf (Static-96.99.98.14.tataidc.co.in [14.98.99.96] (may be forged))
    by ?????????? (8.14.4/8.14.3) with SMTP id p9Q9JrEL006873
    for <??????????????>; Wed, 26 Oct 2011 09:20:02 GMT
From: "Darcel Karlyn" <loriannelvira@cnh.com>
Subject:  6rr4k5
MIME-Version: 1.0
To: <??????????????>
Date: Wed, 26 Oct 2011 12:16:11 +0200
Message-ID: <98e24f23r72-48175613-679n2l41@hnxbidy>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

jq

Readable lisp

O LISP e todos os seus dialectos usam as conhecidas s-expr, que têm dois grandes problemas:

• notação prefixa;
• excesso de parêntesis.

O David A. Wheeler criou o sistema readable com três truques para simplificar a sintaxe das s-expr, mantendo total compatibilidade com a linguagem:

• curly infix c-exprs: {2 * 3} <=> (* 2 3);
• neoteric n-exprs: f(x) == (f x);
• sweet expressions s-exprs que é dedução de parêntesis por indentação, ala Haskell ou Python.

Em três passos se simplifica brutalmente o calcanhar de Aquiles do LISP: a sintaxe. Claro que já vem tarde, mas isso é outra história.