Comendo comida de cachorro

Calma: este não é um post sobre dietas bizarras ou sobre gente com hábitos alimentares estranhos. Tampouco descrevo minhas experiências com o já citado alimento.

Em informática, existe um conceito chamado dogfooding (literalmente: comer sua própria comida de cachorro). Em português não há expressão similar, até onde eu sei (exceto talvez provar do próprio veneno, mas dogfooding não tem a conotação negativa desta).

Trata-se de uma empresa (de tecnologia, geralmente) usar seu próprio produto no dia-a-dia, em todas as etapas de desenvolvimento. Acho que todo mundo aqui acharia graça se a Microsoft não usasse Windows na maioria dos seus computadores ou se a Apple desse um smartphone da Samsung para cada um dos seus funcionários [1]. E ninguém compraria de uma empresa de informática que usasse máquinas de escrever.

Da mesma forma, o dogfooding expõe problemas reais que acontecem no uso de um produto e que podem passar despercebidos por testes, especificações e outros. Serve para a gerência ver (até certo ponto) como o usuário final irá empregar o produto. Foi dessa forma que a Microsoft, entre outras, revelou (e revela) vários bugs no Windows: todos os desenvolvedores deles são obrigados a usar o ambiente que eles estão desenvolvendo.

Em qualquer indústria é fácil de ver isso. Os fabricantes de um produto confiam nele? Além de fazer propaganda, eles consomem seu produto? Já vi restaurantes onde o dono não comia lá: óbvio que eu fui em outro lugar. Já vi desenvolvedores que não usavam seu próprio produto e, portanto, ignoravam problemas óbvios. Inclusive, já fui um desses.

Muitas vezes, quando eu pego um manual de instruções ou um livro, eu fico tentando decifrar o que seus autores escreveram: pergunto se eles tentaram se instruir pelo que eles mesmos escreveram. Ficou claro que não.

Mas esse conceito pode ser aplicado para muito além da tecnologia. Basta ver a quantidade de discursantes que não comem sua própria comida de cachorro: deixam para os outros cumprirem o que eles querem que seja cumprido, mas não cumprem o que eles mesmos pregam.

Falam um monte, prometem um monte, e até mesmo fingem que cumprem até a hora em que a situação aperta: é fácil falar de honestidade até que ela é posta à prova. É fácil dar um discurso inflamado contra X ou Y, mas usar esse mesmo X ou Y às escondidas. É bem comum falar que não tem preconceito até a hora em que se... tem preconceito.

Evidentemente, a maioria das pessoas não come a sua própria comida de cachorro. Elas deixam para que os outros a comam, mesmo que ela não alimente (como é o caso da maioria dos discursos recheados de platitudes) ou esteja estragada.

A maior prova de honestidade é comer sua própria comida de cachorro. É gostoso (ou não, depende da mão do cozinheiro) e faz bem. Na melhor das hipóteses, ela permite a alguém refinar seu trabalho; na pior das hipóteses, desmascara.

(Fonte da imagem: slava/Flickr - e aliás, notar semelhança com o cachorro da necessidade)

[1] No sentido estrito, esse exemplo não é o mais adequado, pois podem haver outras motivações técnicas para que um funcionário não necessariamente use os produtos da empresa. Mas aqui ele é bom o suficiente.

Comparando profissionais

Poucos escrevem como um arquiteto constrói: primeiro esboçando o projeto e considerando-o detalhadamente. A maioria escreve da mesma maneira com que jogamos dominó. Nesse jogo, às vezes segundo uma intenção, às vezes por mero acaso, uma peça se encaixa na outra, e o mesmo se dá com o encadeamento e a conexão de suas frases. -- Schopenhauer, A Arte de Escrever

Sejam dois profissionais, de igual formação acadêmica e trabalhando na mesma profissão.

• Profissional 1 projeta e planeja com base na experiência dele e dos outros. Fugir do foco do projeto? Não, a menos que seja necessário e justificável. Ele vai usar a solução mais adequada para resolver um problema. Ele não trabalha sem especificações - e quanto mais bem definidas, melhor.
  
• Profissional 2 faz as coisas da cabeça dele seguindo apenas suas vontades, seus caprichos e um ou outro modismo: é uma boa ideia fazer X, mesmo que fuja do foco do projeto. Ele vai tentar forçar soluções inadequadas, "por que é mais fácil" ou "por que eu já sei fazer".

• Profissional 1 documenta as suas decisões. Ele consegue entregar o trabalho para outra pessoa, que consegue retomar de onde ele parou. Se ele tiver que dar manutenção num projeto que ele fez há anos atrás, ele consegue.
  
• Profissional 2 acha que comentários, documentação etc... são "frescura" e que os bons não precisam disso. Aliás, o profissional 2 vive de se achar melhor do que ele realmente é, e usa isso como desculpa para não aprender tecnologias novas: ele não precisa disso, afinal o salário dele está garantido. Ou ele se apega a todas as novidades sem entender o que elas realmente são.

• Profissional 1 adota boas práticas desde o começo. Ele prima pelo trabalho dele ser limpo, enxuto e eficiente. Já o profissional 2? Só faz uma limpadinha por cima no final.
  
• Profissional 2 desenvolve e testa tudo de uma vez só; já o profissional 1 desenvolve iterativamente e testa conforme desenvolve, não começando outra parte do projeto até que uma esteja funcionando adequadamente. Aliás, uma das primeiras coisas que ele faz é especificar testes.

• Profissional 1 sabe que volume não é quantidade e que, aliás, as melhores e mais elegantes soluções são as mais simples. Já 2 quer é demonstrar a capacidade dele de ser prolixo.
  
• Profissional 2 consegue cobrar mais barato por isso e entregar o trabalho mais rapidamente: boa sorte para o cliente ou para quando ele mesmo tiver que fazer manutenção. Já o profissional 1 pode demorar mais, mas entrega um trabalho melhor.

Quando o projeto do profissional 1 dá errado ou não funciona de forma satisfatória, ele sabe por onde começar a corrigir os problemas. E provavelmente ele vai achar o problema: ele vai usar as ferramentas adequadas para descobrir o defeito.

Já o profissional 2 se desespera, rasga tudo e começa de novo. Ou usa a ferramenta errada, não é muito fácil mas dá pra dar um jeitinho.

Qual deles é o melhor profissional? Qual deles é o mais comum?

E infelizmente, o que mais vemos por aí são profissionais do tipo 2. Já começa desde cedo na faculdade: deixam tudo para a última hora, não organizam, não planejam, e faltando algumas horas para a data de entrega é um desespero para tentar fazer a coisa funcionar direito.

Se apegam a formas prontas para resolver problemas, e tentam forçar todas as soluções a caberem no mesmo molde, mesmo que isso seja péssimo de um ponto de vista técnico.

Mas o pior é ver empresas que sugerem que você se comporte como um profissional do tipo 2: recentemente, desenvolvendo com o hardware de um grande fabricante, uma das recomendações era encontrar um código parecido com o que você quer fazer, copiar e colar. Justamente para fugir da abstração que eles mesmos criaram. Na hora perdi a vontade de trabalhar com o hardware.

Profissional do tipo 2: não seja esse profissional. Aprenda a fazer direito, mesmo que isso lhe custe mais a curto prazo, para evitar o retrabalho, a perda de tempo (seja sua, seja do seu sucessor).

Aliás, o livro do qual eu tirei a citação do topo deste post é uma leitura bem interessante para qualquer profissão criativa: tudo que está lá pode ser facilmente adaptado.

(Fonte da foto: http://www.flickr.com/photos/jpaxonreyes/5034760960/lightbox/)

IPython: notebook e Qt Console

O IPython já é velho conhecido de quem desenvolve em Python, dispensa introduções etc... Mas outro recurso interessante, e que ainda não é muito explorado, é o recurso de notebook: um caderno onde se pode desenvolver de forma interativa.

Ele é igual a ideia dos notebooks, worksheets etc... para quem já usou o Mathematica, o Sage ou outros softwares matemáticos: um documento que concentra todo o código-fonte, junto (ou não) com a descrição e/ou a documentação dele.

Para usá-lo? Simples: digite ipython notebook --pylab inline no terminal, e pronto, vai abrir uma janela do seu browser. Daí é só criar um novo notebook.

Todos os recursos do IPython estão disponíveis (exceto o %debug, que requer uma interatividade que o 'notebook' ainda não suporta). E inclusive é possível embutir vídeos, imagens etc... dentro do documento! Excelente para a geração de aulas, tutoriais, e outras coisas que não são tão práticas de fazer com outros softwares (inclusive certos softwares proprietários :)

Ele também se demonstra um ótimo ambiente para trabalhar com Octave, R, etc... ou (para quem gosta - acho que todos sabem que eu não faço parte dessa estatística) com o MATLAB, através das extensões do IPython.

Outra vantagem, que eu não explorei, é a execução dele num servidor dedicado ou na nuvem: tchau à necessidade de instalar uma cópia do ambiente em cada máquina, basta ter um browser razoavelmente atual e pronto.

Uma possibilidade final que o IPython fornece é executar em um 'terminal gráfico' em Qt, usando o comando ipython2 qtconsole --pylab inline. Essa é mais interessante para scripts que executem e forneçam seus resultados de forma visual.

Beleza, software e distribuições Linux

Voltei para o Arch Linux como meu sistema operacional principal, devido a um pequeno motivo que sempre acaba me expulsando de outras distros: simplicidade. Cansei de arquivos de configuração feitos para serem editados por máquina (e não por humanos), de GUIs de uso obrigatório para ajustes no sistema, e de outras complicações desnecessárias. E isto permite uma reflexão sobre a questão da beleza.

Na matemática, uma solução 'bela' para um problema é simples e elegante. Usa o mínimo de axiomas, premissas e hipóteses possíveis, e pode ser facilmente generalizada para a resolução de diversos outros problemas do mesmo ramo. Evitam-se métodos muito complicados, number crunching etc... os quais são vistos como 'feios' e 'desengonçados'.

Podemos fazer uma analogia para um software bonito - não no aspecto da usabilidade, mas nos aspectos construtivos dele:

• usar o mínimo necessário de bibliotecas;
• ser o mais portátil possível (exceto em situações onde se usam recursos específicos de um sistema operacional);
• ter documentação de qualidade onde ele não for auto-explanatório;
• fugir dos anti-padrões de projeto;
• ser facilmente adaptável para as mais diversas situações.

Como consequência, temos uma ferramenta ou um sistema mais fáceis de manter e de administrar. Torna-se simples modificá-lo para a resolução de diversos problemas, ou aplicá-lo em situações distintas. Eles se tornam mais convidativos para o trabalho em equipe e para o reuso de código.

Nesses aspectos, sinto que muitas das distribuições Linux sofrem de uma falta de elegância: scripts de inicialização pouco amigáveis para quem os edita manualmente, XML atirado para lá e para cá - obviamente prevendo que os arquivos serão editados por outros programas, pacotes fragmentados etc...

O mesmo com outros softwares, são pequenas coisas que conseguem estragar o dia de um sysadmin ou de um usuário mais avançado, como:

• Configurações armazenadas em formato binário (ou XML) e que só podem ser feitas pela interface gráfica.
• Reinvenções contínuas (algumas quadradas) de rodas diversas.
• Excesso de dependências nem tão necessárias (e que no mínimo deveriam ser opcionais).
• Ocultar mensagens de erro para o bem do usuário.
• Entre outras diversas coisas que tornam a aplicação feia.  

Outro aspecto que a simplicidade traz é a flexibilidade: várias pequenas ferramentas podem - ou deveriam poder - ser interligadas para formar um todo, em vez de precisarmos de uma ferramenta monolítica para cada tarefa. Partes que se encaixam para formar um sistema, que podem ser reaproveitadas conforme necessário, e não um sistema 'faz tudo' altamente especializado em uma tarefa.

Da mesma forma, desenvolve-se uma vez e depois simplesmente se usa o trabalho já feito; o tempo gasto em debugging é menor. Facilita-se a portabilidade, e outras pessoas também podem aproveitar aquilo que já foi feito.

É importante notar que simplicidade não necessariamente se traduz em menor número de linhas de código, ou vice-versa: considero ser preferível escrever código um pouco maior, mas mais simples de entender, a usar hacks para economizar algumas poucas linhas de código. Soluções engenhosas são bem-vindas, desde que elas não sacrifiquem as premissas já feitas anteriormente.

Elegância e simplicidade para resolução de problemas não são más ideias: economizam recursos e evitam dor de cabeça para quem precisa ou quer interagir em um nível mais baixo. Podem custar mais na hora de desenvolver a solução, mas a longo prazo, simplificam o trabalho do desenvolvedor, do sysadmin ou de qualquer outro profissional.

E já que eu falei no Arch Linux, é justamente isso tudo que o Jeito Arch (The Arch Way) incorpora. Complexidade sem complicação, código simples e correto, ferramentas compactas e projetadas para interoperar. Arquivos de configuração feitos para serem lidos e entendidos por seres humanos. Tudo aquilo que pode ser considerado fundamental para um software bonito.


Recomendo, por fim, a leitura do excelente Most Software Stinks!, que define princípios gerais para um software bonito.

O ego, a incompetência e algumas distribuições Linux nacionais

Acredito que todo mundo já tenha visto aquelas distribuições Linux nacionais, fornecidas com os computadores populares. Quase sempre "quebradas", com pacotes obsoletos (como eu vi em uma delas: VirtualBox 1.5.0, sendo que já estamos na versão 3.0.4), e grande dificuldade na hora de instalar programas. Isso quando não cometem atrocidades maiores, como gambiarras diversas em arquivos de configuração mal-escritos e não-documentados. Coisas que o usuário final não nota, mas que para alguém que necessite configurar tais sistemas, traz muitos problemas.

Isso revela dois problemas de tais distros. O primeiro deles: a síndrome do precisamos fazer nossa própria distro, também conhecida como Not Invented Here (NIH). Uma reinvenção da roda desnecessária, que na minha opinião vai exatamente de encontro à própria ideia do software livre. Mas tudo bem, dizer que criou uma distro é engrandecedor, serve direitinho para que algumas pessoas possam se rotular de "desenvolvedoras".

Uma solução muito mais fácil e óbvia seria criar pacotes com as modificações, colocá-los em um repositório e aplicá-los em uma das várias distros end-user já disponíveis, assim garantindo a continuidade das atualizações - ao contrário de humilhar os usuários com versões antigas. E, também, se o usuário quisesse voltar à distro original, isso seria possível, assim como um usuário de Ubuntu pode "migrar" para o Kubuntu instalando um meta-pacote que nada mais faz do que depender dos pacotes relativos à distro desejada.

Poder-se-ia, por exemplo, pegar um Ubuntu ou openSUSE, acrescentar pacotes que reflitam as modificações desejadas, e aproveitar todos os repositórios, documentação e tutoriais, assim garantindo uma experiência mais agradável para os usuários iniciantes e acabando com a reinvenção da roda praticada em nome da satisfação pessoal.

Outro problema clássico é a síndrome de imitação do Windows. A intenção é boa, facilitar a migração, e talvez até funcione em ambientes corporativos, nos quais os usuários tem acesso restrito e pouco ou nenhum direito de instalação de programas e configuração. Exceto que... isso dificulta as coisas para um usuário doméstico, além de colaborar na criação da imagem de Windows de pobre, de cópia mal-feita.

Aparentemente, há uma falta de sinceridade e de capacidade em não tratar o usuário como um idiota. É possível, sim, criar desktops fáceis de serem usados e que não tenham uma imagem pixelada e desproporcional dizendo Iniciar, nem precisem roubar ícones do Windows (ironicamente, depois dessa, são os usuários Linux que reclamam de qualquer coisa que remotamente pareça ter sido copiada, mesmo que tal plágio não exista).

E ironicamente, o ambiente que "não deveria confundir o usuário" pode causar mais problemas. Quantas vezes já não vi um usuário desses sistemas tentando instalar o Messenger ou outro programa baixado do site da ... Microsoft? Embora o Wine já rode muito bem vários programas, ele ainda não é completamente plug-and-play.

(Um detalhe interessante: nunca vi um usuário que migrou de Windows para Mac reclamar da falta do botãozinho Iniciar ou que não tem Internet Explorer)

Mas não, para os desenvolvedores, tais ideias simples são muito distantes da realidade de quem quer poder afirmar que criou uma distro, mesmo sem ter como garantir a qualidade do sistema. Para eles, é necessário criar um ambiente sem nenhuma identidade, parcialmente compatível e completamente quebrado, assim fazendo com que o usuário-final pense o Linux é essa porcaria e alimentando os preconceitos sobre o sistema.

GIMP 2.7.0, versão de desenvolvimento

No dia 16 foi lançada a versão 2.7.0 do GIMP, versão de desenvolvimento, já com diversos recursos interessantes.









Provavelmente um dos recursos que mais irá ser importante é o suporte a tags nos pincéis/gradientes/texturas etc.... Recursos práticos para quem tem uma grande coleção desses materiais, mas era vítima da dificuldade em organizá-los.












Outra mudança que - infelizmente - irá irritar alguns usuários mais antigos (como eu), mas faz sentido para os novos, é a separação das funções 'Save' e 'Export': a primeira apenas salva no formato do GIMP, já a segunda permite salvar nos outros formatos, como JPEG e PNG.


Também é possível editar texto diretamente na imagem, sem aquela velha e - para alguns - desagradável janelinha flutuante.













No núcleo, vários algoritmos foram modificados, possibilitando - no futuro - recursos como camadas vetoriais, operações avançadas com pincéis (interessantes para quem usa tablet) e interfaces com a biblioteca gráfica GEGL - com a qual, espera-se, adicionar outras tão desejadas funções como suporte a imagens com mais de 8 bits por canal e camadas de ajuste (adjustment layers).

Um dos objetivos da versão 2.7 é que não sejam mais feitas mudanças em tal biblioteca gráfica, de forma a permitir que o desenvolvimento se concentre no GIMP em si.

Trata-se de uma versão de desenvolvimento, portanto não recomendo seu uso em produção, embora na minha máquina não tenha havido nenhum crash.

Para mais informações, leia o Changelog. Criei 3 PKGBUILDs para uso no Arch Linux, coloque-as em /var/abs/extra/{nome do pacote} e execute o makepkg.


http://codepad.org/6Avhu1Tg - babl-0.1.0
http://codepad.org/YnmvPwGu - gegl-0.1.0
http://codepad.org/75Hhn64T - gimp-2.7.0

Garbage in, garbage out (ou "pensar pra quê?")

Na computação, há um velho princípio (da época dos mainframes, vistos como máquinas pensantes, como me lembro de uma enciclopédia dos anos 70) chamado garbage in, garbage out. Basicamente, ele afirma que a saída é tão boa quanto a entrada; não existe mágica que transforme dados ruins em resultados milagrosos. Podemos generalizar esse princípio para qualquer procedimento experimental: simplesmente não há como obter resultados válidos a partir de dados inválidos sem cometermos uma fraude científica [1].

E um dos conceitos derivados é o perigoso garbage in, gospel out. É o que vejo muitas vezes por aí: uma confiança cega no resultado emitido por uma máquina que supostamente nunca está errada e que muitos acreditam ser "perfeita". A simulação, a modelagem, os algoritmos viraram verdadeiras armas mágicas, aquelas que substituem experimentos e análises e que, para alguns, nunca estão erradas.

Armas essas que podem machucar os seus usuários de forma violenta se usadas incorretamente. Basta lembrar que tais softwares têm milhares - senão milhões, ou bilhões em um futuro próximo - de componentes e linhas de código, assim sua complexidade cresce de forma assustadora. Assim, um modelo incompleto (como é o caso de componentes eletrônicos ou sistemas físicos, nos quais muitas vezes uma modelagem de baixo nível é inviável), um pequeno erro de digitação ou mesmo um atalho tomado para simplificar o código, podem esconder erros que aparecerão no imperfeito e imprevisível mundo real.

Tal comportamento, muitas vezes, vem da cultura de querer uma fórmula para tudo. Quem precisa de raciocínio e de interpretação quando existem milhões de fórmulas mágicas, nas quais basta apenas jogar os valores e, adequado à cultura da impaciência, temos ali uma resposta bonitinha? E é isso que leva a outro comportamento parecido: a dependência excessiva de ferramentas. Vejo pessoas usando calculadoras ou softwares para resolver problemas que poderiam ser executados de forma igualmente eficaz com alguns poucos cálculos manuais.

Ou mesmo passando horas chutando valores em um simulador, até obter o resultado desejado, mesmo que a solução seja impossível no mundo real, ou comentando e descomentando linhas em um código-fonte, praticando a chamada Cargo Cult Programming, tudo isso para evitar o trabalho de pensar e entender a causa do problema, e certamente não é esse o profissional que queremos ver. Em uma analogia, resolver problemas de tal forma seria similar a um "tratamento" médico no qual o profissional decide "sair cortando o paciente até achar onde está o problema".

Em um exemplo mundo-real, podemos fazer uma analogia entre um projeto feito apenas com simulações teóricas e uma pessoa que inicia um relacionamento apenas baseada em fotos e conversas virtuais. Talvez os resultados sejam os esperados, talvez completamente diferentes; talvez uma das, ou as duas pontas desanimem e decidam jogar tempo e trabalho fora.

Não quero defender o retorno às máquinas de escrever e as réguas de cálculo, mas sim que não existe solução - por mais avançada que seja - que tire do profissional o trabalho que nenhuma máquina pode fazer: o de entender o resultado e os limites das ferramentas empregadas e, principalmente, estar pronto para criticar e duvidar de tais, não servindo apenas como um mero apertador de botões.

Por mais poderosas que as ferramentas se tornem, elas não substituirão aquilo que delimita o bom profissional de um mero seguidor de fórmulas e resultados prontos: o bom-senso. E elas continuarão sendo importantes, desde que usadas com consciência de suas falhas e limitações e com a compreensão que nada substitui o mundo real para testes.

Recomendo a leitura desses artigos da coluna Rarely Asked Questions, escrita por um engenheiro da Analog Devices, fabricante de componentes eletrônicos:

1. Which carries more weight, a datasheet or SPICE macromodel? (modelagem X mundo-real)
2. What's in your toolbox? (escolha a ferramenta adequada)
3. Capable engineers should be prepared to question, and modify, anything, not just their own designs (necessidade de criticar e questionar resultados)


[1] Podemos generalizar o conceito de garbage in, garbage out para qualquer mercado: um produto ou serviço refletirá o esforço que nele foi investido e a qualidade que nele foi colocada. E o conceito de aplica-se a produtos de qualidade duvidosa endeusados pela propaganda e pela existência de grandes nomes por trás, no perfeito pensamento capitalista o que é bom para uma empresa, ou para alguém famoso, é bom para mim.