Ferramentas Linux, UNIX (1/2)

Como utilizador veterano de Linux (e outros sistemas Unix no passado, não tanto agora) fui adoptando um grande número de ferramentas ao longo dos anos. Deixo uma pequena lista de alguns dos que mais uso e/ou considero interessantes, para não se tornar exaustiva. Ficaram de fora alguns dos tradicionais comandos de Unix (sed, awk, cat, dd, find, grep, …), software servidor (apache, samba, …) ou outros demasiados específicos.

Aviso: é natural que as minhas raízes command line se revelem um pouco.

Comunicações mundanas

• firefox – o meu browser. Há outros, bons, como o opera, chrome, mas é este que uso já desde o tempo do monolítico netscape.
• thunderbird – o meu interface de mail. Mais um do projecto mozilla, favorito de longa data.
• pidgin (ex gaim) – instant messenger com vários protocolos suportados. Pode não suportar as funcionalidades mais avançadas de outros talkers específicos, mas centraliza as comunicações do tipo IM e serve para o uso que lhe dou (pouco).

Networking

• stone – um excelente repetidor tcp/ip. stone proxy 8888 e tenho um proxy http lançado no porto 8888. Suporta mais protocolos e esquemas de repetição.
• iperf – qual é a largura de banda entre dois pontos de rede?

• netcat – cliente/servidor tcp/udp flexível. Um clássico, mas que ainda hoje uso. Servidor: nc -l -p 8888, cliente: echo ola | nc 127.0.0.1 8888. Para determinar rapidamente o contéudo de um pedido http:

  [edit /etc/hosts "127.0.0.1 mysite"]
  nc -l -p 80
  [browse to http://mysite/urlpath]

• tcpdump – mostra o que passa num interface de rede. O avozinho deste tipo de ferramentas, com interface totalmente baseado na linha de comando, dispõe de um flexível mecanismo de filtros.
• wireshark, ex ethereal – um tcpdump em modo gráfico. Captura e analisa os pacotes de rede.
• nmap – mais do que um port scanner, isto é um autêntico canivete suíço de rede. De vez em quando uso o nmap -sV -O ip para tentar descortinar um pouco do que se está a passar, mas hoje em dia isto foge ao meu trabalho típico. A suite nmap inclui outros utilitários interessantes como o ncat (inspirado pelo netcat referido acima), ndiff e nping.
• curl, wget – download de URLs (ftp e http) da linha de comando. O curl é mais completo, permite fazer upload, suporta autenticação ntlm. O wget aceita vários URLs e funciona em modo recursivo. Complementam-se bem.
• ncftp, lftp – há cada vez menos coisas em ftp que não estejam disponíveis por http, mas quando é preciso, estes dois continuam a ser bons clientes ftp interactivos.

• rsync – inicialmente o objectivo do rsync era fazer transferências por rede optimizadas, i.e. permitia transferir apenas um conjunto mínimo de diferenças entre a origem remota e o destino local (ou vice versa), reconstruindo a mesma imagem no destino. Mas com o tempo, usar o rsync para copiar de qualquer sítio para qualquer sítio tornou-se um vício.

  # actualiza em dest os conteúdos de source
  rsync -av --delete /a/b/source /x/y/dest 
  
  # envia os meus dados para o servidor, via ssh, com compressão, 
  # restringindo a largura de banda usada a 50KB/s, para não me 
  # estrangular a minha ligação de rede
  rsync -Pav --delete ~/stuff/. host:/stuff/. -e ssh -z --bwlimit=50

• cntlm – quando a Microsoft decidiu implementar um mecanismo de segurança proprietário, NTLM, sem qualquer documentação, nem suporte fora de Windows, o resto do mundo ficou às escuras. Nos sítios em que se usavam proxies com autenticação NTLM isso significava não ter acesso a nada. Felizmente alguém com tanto de generosidade como de genialidade fez o reverse engineering desse protocolo e implementou um proxy que se autenticava via NTLM num MS Proxy Server. Esse proxy era o NTLM Authorization Proxy Server, escrito em python. Mais tarde apareceu esta versão em C que trouxe algumas melhorias e funcionalidades. Exemplo real de utilização:

  # cria um proxy http anónimo no porto 5866 que se autentica e usa o 
  # proxy windows NTLM_PROXY no porto 80 
  cntlm -g -d DOMAIN -u USER -p PASS -l 5866 NTLM_PROXY:80

• w3m, links2 – w3m é, para mim, o melhor browser em modo texto. Também funciona como paginador e até suporta tags. As outras incarnações de browsers texto (lynx, links, elinks) nunca me convenceram, excepto o links2 que adicionou suporte javascript e gráficos (links -g). De vez em quando dão jeito.

Gráficos, diagramas

• PlantUML – a partir de uma simples descrição textual o plantuml gera diagramas UML de sequência, casos de uso, classes, actividade, componentes, estado e objectos. Muito útil para documentar rapidamente fluxos e processos.

  @startuml cache.png title padrão usual de cache (*) --> "cache get" if "hit?" then --> [yes] (*) else -> [no] "source get" --> "cache set" --> (*) endif @enduml

  —>

• yUML – ferramenta online com um conceito semelhante ao plantuml. Os gráficos têm melhor qualidade, contudo.
• graphviz – conjunto de ferramentas para produzir todo o tipo de diagramas, a partir de especificações textuais. Útil para gerar diagramas programaticamente.
• Pencil – um poor man’s visio que funciona como extensão do firefox ou standalone (é uma aplicação XUL). Surpreendemente funcional! O “Sketchy GUI” é excelente para prototipar mockups.

• ImageMagick, GraphicsMagick – ImageMagick é uma suite de utilitários para processar imagens da linha de comando, embora também inclua o display que é um utilitário gráfico. Assim, tarefas como converter entre formatos, alterar resoluções, aplicar efeitos ou outras operações em imagens está à distância de usar o nosso mecanismo de automatização preferido a envolver isto. Exemplo em shell+awk para re-escalar todas as imagens para 800x600:

  # confirmar se está tudo ok
  ls *.png *.jpg | awk -vR=800x600 '
    function f(s) {sub(".[^.]*$", "_" R "&", s);return s} 
    {printf "convert -geometry %s \"%s\" \"%s\"\n", R, $0, f($0)}'
  
  # executar
  ls *.png *.jpg | awk -vR=800x600 '
    function f(s) {sub(".[^.]*$", "_" R "&", s);return s} 
    {printf "convert -geometry %s \"%s\" \"%s\"\n", R, $0, f($0)}' | sh -x

  O GraphicsMagick foi um spin-off do ImageMagick feito em 2002 que reivindica ser melhor. Independentemente das pretensões dos autores, uma coisa que eu prefiro no GraphicsMagick é o uso do comando gm como driver dos outros subprogramas (gm convert, gm identify, …).

• pinta – finalmente um programação de edição gráfica simples, funcional e usável, que funciona em Linux.

As pessoas são recursos?

O uso do termo “recurso” como designação de pessoa tem-se vindo a generalizar e banalizar. Mas são as pessoas recursos?

Um recurso é algo do qual se faz uso para um propósito. Como recurso é indistinguível face a outros equivalentes ou iguais. Por exemplo, posso trocar um carro por outro modelo igual sem perda de funcionalidade ou necessidade de adaptação.

Ora as pessoas não têm “modelos iguais”. Se assim fosse não eram precisas entrevistas no processo de contratação, bastava consultar a ficha técnica da pessoa. Não era preciso haver período experimental, ou outros expedientes usados devido à individualidade de cada ser humano.

O próprio lugar-comum “a maior riqueza são as pessoas” enferma de uma contradição na asserção pessoa-recurso. Se as pessoas se trocam facilmente enquanto recursos, não constituem maior riqueza que os outros recursos da empresa, como instalações, veículos, etc.

Resumindo: uma pessoa é um ser humano, não é um recurso.

Por incrível que pareça há pessoas que têm dificuldade em tratar as outras pessoas por… pessoas.

Notas:

• a expressão “recursos humanos” faz sentido enquanto designação de uma área comportamental ou organizacional;
• a expressão “recurso humano” não faz sentido para mim.

Outras leituras:

• Recursos Humanos na gestão de pessoas - Felicidade em pauta
• Você prefere ser chamado de colaborador ou recurso?
• Pessoas não são recursos!

ACK, um grep para programadores.

Por vezes bastam pequenas ideias para nos melhorarem a vida, e o ACK é um desses casos. Quantas vezes não sentimos necessidade de fazer coisas como:

find ! -path \*/.svn\* -print0 | xargs -0 grep foo

ou outras artimanhas do género? O ACK resolve este problema: é um grep que exclui à partida padrões com reconhecido desinteresse. Adicionalmente possui mais umas poucas opções extras de conveniência. É escrito em perl mas é rápido q.b. e bastante prático de se usar.

Lições que podemos aprender com a NASA.

A NASA é a agência espacial dos EUA e é-lhe associada uma imagem de excelência, pelos feitos alcançados ao longo da sua história, apesar de terem tido a sua quota de reveses.

O contexto aeroespacial justifica condições ímpares que uma empresa comum não pode alcançar, no entanto algumas das práticas que a NASA tem empregue não exigem meios significativos e servem como exemplos a seguir.

Aprender com os erros

Especialmente no início da exploração espacial aconteceram muitos erros, houve muitas falhas e alguns desastres com consequências trágicas. O que a NASA fez foi aprender com esses erros. Com isto melhorou os protótipos seguintes, melhorou os métodos de treino, as técnicas de construção, etc.

O conceito de aprender com os erros em si nem é uma grande lição – o termo “lessons learned” ouve-se nestes dias em qualquer empresa – a sua prática efectiva é que o é. É preciso analisar o que se passou com objectividade, fugindo à tentação humana de (des)culpabilização. E com base nessa análise é preciso tomar acções correctivas.

Ora isto é algo que, da minha experiência, nunca acontece. Isto é, ou nem sequer é feita a análise, ou é mal feita, ou não se tomam acções de correcção.

Registos

A NASA dá muito importância aos registos. Registos de construção, registos de procedimentos, registos fotográficos, recolha de amostras, levantamento de materiais e equipamentos, etc.

Os registos são importantes para analisar problemas ocorridos, para servir de base a novos desenvolvimentos, para reconstituir cenários, etc.

Redundância

Ao longo do tempo popularizou-se o conceito que a NASA faz tudo a dobrar. Isto tem origem nos seus procedimentos reais desde longa data: eles mantinham duas equipas “iguais”, a principal e a de backup, sujeitas aos mesmos treinos durante todo o ciclo de preparação para uma missão, por exemplo. Também tinham réplicas de equipamentos e peças. Os próprios equipamentos construídos eram desenhados com vários sistemas de backup em casa de falha dos componentes principais.

Estar preparado

Além de tudo o exposto, a NASA tem mostrado o conceito de estar preparado, fazendo uso, por exemplo, das mais mundanas técnicas e materiais.

Um exemplo é a fita adesiva, que desde longa data faz parte do material levado pelos astronautas para o espaço, tendo sido já útil por algumas vezes. Não sendo um material de alta tecnologia, foi importante em certos contextos devido à sua versatilidade.

---

No próximo artigo, usando o caso real da missão Apollo 13, mostrarei como muitos dos eventos reais ocorridos se encaixam nestas práticas.

O Word matou a documentação técnica.

Sejamos sinceros: escrevemos pouca e má documentação. Sobretudo técnica. Porquê?

• porque não temos cultura documental: escrevemos pouco… e lemos menos;
• porque não aprendemos a fazê-lo nas escolas;
• porque o mercado é demasiado pequeno para haver technical writers;
• e porque… usamos o Word?

Sim, o Word! O Word porque é universal e porque não é apropriado para escrever documentação técnica. Logo, se universalmente usamos algo inapropriado para uma finalidade, destruímo-la. QED :-)

Universalidade

Ainda estou para conhecer alguém, profissionalmente, que nunca me tenha enviado um .doc ou .docx. Toda a gente usa o Word! Seja para escrever 3 ou 4 linhas de anotações, seja para fazer o CV, seja para escrever regulamentação. Faz-se tudo com o Word. E nem se espera que os destinatários não abram os documentos ou não os consigam editar. É assumido que sim.

Isto “secou” as alternativas, que até existem, mas têm pouca comunidade. Não me serve de muito escrever em markdown (texto) se mais ninguém o fizer.

Inapropriado para documentação técnica

Primeiro algumas premissas que considero pertinentes na produção documental:

• A documentação técnica deve residir ao lado do código, num sistema de controlo de versões (SCV). Para poder evoluir com o código. É a única forma prática de o conseguir.

• Uma parte substancial da documentação deve ser gerada automaticamente, como APIs, tabelas, diagramas ou modelos de dados.

• Ferramentas simples e universais devem poder ser usadas para manter documentação: controlar versões, obter diferenças, corrigir ortografia, substituições massivas, etc.

• Devem poder ser gerados vários formatos finais para diferentes meios de publicação. Exemplos: PDF, html único, html paginado.

• Os formato finais devem poder ser construídos automaticamente.

Ora nada disto se consegue em termos práticos com o Word! O Word implica ter um enorme programa lançado, que só corre em Windows, usando as suas idiossincrasias. Ficamos fechados nesse interface, com um sistema de automatização complexo e limitado em VBA. Torna-se difícil descobrir diferenças entre versões. Torna-se impossível haver edição partilhada.

A técnica mais frequente de edição em equipa é penosamente sequencial: consiste em passar um .doc de mail em mail pelos vários editores. Isto tem impactos em termos de tempo – tem que se esperar que o actual “proprietário” passe o documento – e impede a resolução imediata de conflitos. No cenário em que o editor N estraga parte das edições do editor N-1, como passa o documento em seguida ao editor N+1, o N-1 só lhe voltará a ter acesso na revisão final, o que irá dificultar bastante o seu trabalho de correcção. Na realidade já assisti a muitas edições perderem-se desta forma.

Aos pontos acima acrescento um novo:

• A tarefa de documentar deve ser tão leve e fácil como a de programar!

Abrir o Word para documentar uma API, por exemplo, é pesado e “difícil”. Um fluxo típico de trabalho consiste em saltar de janela em janela, fazendo vários copy-pastes. Copy da janela de código, paste para a janela do Word. Todos os aspectos gráficos terão de ser feitos manualmente, um a um. Exemplo: colocar todas as variáveis em itálico, ou trechos de código numa fonte fixa.

Solução: texto!

Todos os pontos anteriores conseguem-se cumprir facilmente usando texto como representação fonte da nossa documentação.

Como tal a documentação deve ser escrita directamente em texto, ou pelo menos ter uma representação textual ¹, para que possa ser processada por ferramentas simples e comuns. O texto é um formato verdadeiramente universal, logo qualquer ferramenta virtualmente o suporta.

Assim:

• Edição leve e fácil: basta um editor de texto. Pode ser o nosso preferido. Pode ser o mesmo que usamos para editar código. Isto significa que podemos alterar a documentação sem sequer sair do contexto de desenvolvimento.

• Colocando os ficheiros de documentação num SCV a gestão de versões é imediata. Quem editou o quê? O que mudou entre duas versões? Conseguimos reverter uma edição errada, ou até melhor, reverter as porções erradas de um dada edição. Tal como já o fazemos em relação ao código.

• Edição simultânea em equipa: várias pessoas têm a hipótese de trabalhar na documentação em simultâneo, deixando o SCV tratar do merge das edições.

• O sistema de construção do projecto pode ser adaptado para construir a documentação, incluindo também a geração das partes automáticas.

Referências

• http://www.apeth.net/matt/iosbooktoolchain.html: descreve o processo usado para escrever o livro “Programming iOS 4”;

• do blog: documentação ágil;

• do blog: como são feitos estes artigos;

• a documentação oficial do Python usa o sphinx (reStructuredText);

• o projecto de documentação Read The Docs (RTD) também usa sphinx.

---

1. a edição até pode ser visual, através de um editor WYSIWYG, mas o formato dos ficheiros gravados deveria ser texto compreensível.↩