Entendendo códigos-fonte: A missão

Para compreender um programa, primeiro temos que responder à questão: o quê diabos faz este programa ?

Pois bem, este é um excelente exercício que podemos nos habituar a fazer. O quê é o postgreSQL ? O que é o Samba ? E por aí vai.

Vamos pegar o PostgreSQL como exemplo: o que é o PostgreSQL ? A resposta mais rápida seria: "é um banco de dados". Embora isto seja o começo de tudo, esta resposta não estará completa sem antes listarmos todas as características que o compõe. Lembrando que características são itens mensuráveis, e não gostos, opiniões ou declarações variáveis com o tempo: "é o banco de dados mais rápido do mundo" não vale, pois mesmo mensurável, é variável com o tempo.

Missão do PostgreSQL
Considerando a versão 9.0, posso definir a "missão" do PostgreSQL como:

* é um SGBD (relacional, OLTP)
* trabalha no padrão SQL-95
* suporta transações (ACID, suporte à sub-transações - 'savepoints')
* suporta concorrência (MVCC)
* acesso é via rede tcp ou pipe de arquivo
* possui controle de permissões de acesso
* suporta replicação
* suporta integridade referencial (chaves primárias / estrangeiras)
* suporta "stored procedures" (linguagens modulares)
* suporta funções (do sistema, do usuário, funções anônimas)
* suporta visões (views não-materializadas)
* suporta gatilhos ('hooks' ativados por eventos)
* possui um sistema de mensagens (LISTEN/NOTIFY)
* suporte ao modelo híbrido objeto-relacional (SGBDOR, herança de tabelas)
* fortemente tipado
* multi-linguagem (BDs possuem um 'charset', 'collations')

Note que não existe definições corretas ou erradas (a menos que tenha uma informação falsa) - a "missão" de um programa é algo que deve ser feito para ser jogado fora. Serve apenas no momento em que está se montando a idéia do "quê" é o programa. Sua estrutura é algo estritamente pessoal. Eu por exemplo gosto de agrupar cada palavra-conceito do programa em características.

Valores
Adicionalmente, gosto de colocar a "filosofia" do programa - isto é, as características não-mensuráveis que servem para guiar o desenvolvimento dele - seus valores. No caso do PostgreSQL, segundo minhas constatações são:

* 1. estabilidade
* 2. baixa manutenção
* 3. segurança (pg_hba, grant, controle de usuários - owner/ACL, wal, PITR, 2PC, savepoints, hot/warm/cold/standby backup, logs, fsync, substituição de variáveis /set, RADIUS/LDAP)
* 4. velocidade (índices, fts, cluster (ordenação física), tablespaces, configurações postgresql.conf, shared buffers, vacuum/autovacuum - visibility map, toast, otimizador de querys, GEQO, explain, cost, fsync, cache (count e índices), heap only tuples - HOT, Copy vs INSERT, substituição de variáveis /set, estatísticas)
* 5. multi-plataforma: SO e arquitetura

Exercite sua mente
Tudo isto foi apenas um exercício mental. Brinque bastante de dizer qual a missão de um programa: o quê é e quais são suas características. Afinal, qual a missão do Windows 7, do Windows explorer, do Firefox, ... ?

Faça seu código voar

Uma tarefa cotidiana na vida de todo programador é ter que otimizar um código para velocidade. Afinal, a falta de velocidade até um certo ponto torna um programa inaceitável e acima do mesmo ponto, torna-se um atrativo poderoso. Porém, na medida que otimizamos para velocidade percebemos que o código vai se tornando ilegível, de difícil manutenção. Assim, ao otimizar, devemos optar por um conjunto de alterações que alcance nosso objetivo, mas que tenha o menor impacto nas demais características. Você não vai querer fugir da ira dos usuários para cair na ira dos programadores.

Otimização = antônimo de legibilidade
Quanto mais otimizamos, mais detalhistas temos que ser no código - temos que controlar cada detalhe - e como já vimos, quanto maior o nível de detalhe, menor é nossa visibilidade. É como ser uma formiga no meio de um campo de futebol e ter que dizer se um meio de campo é maior que outro. É como tentar entender a geologia do mundo olhando os seus grãos de areia. É como ..., bem acho que já entenderam.

Não faça "economia porca"
Normalmente 99% do tempo de execução de um programa é executado por um trecho de 1% do fonte ! Ok, estou exagerando, mas a regra é esta: apenas uma fração do seu código é responsável por quase todo o tempo de processo. Logo, só precisamos otimizar um pequeno pedaço, mantendo a legibilidade do resto do código. Isto é, só atacamos os gargalos - não é necessário deixar o código totalmente ilegível, mas apenas o que consome mais tempo:  funções rápidas que são acessadas muitas vezes, ou funções lentas acessadas poucas vezes.

Ponderação
Por fim, devemos sempre pesar se a ilegibilidade causada pela otimização não vai dificultar ou deixar mais lento as manutenções no fonte, os progressos e participação de novos programadores, se não irá aumentar o número de bugs, etc. Se o mote do projeto é ser "o mais rápido do mundo", então faça - mas fique sabendo o impacto que isto pode causar.

Entendendo códigos-fonte alheios

Quem já não teve dificuldades em entender o código-fonte escrito por outra pessoa ? Pior é quando temos que dar manutenção no código e aí não basta apenas entender, temos que entender muito bem. E quando é nosso próprio código, escrito há meses atrás, que não entendemos - aí chega a ser constrangedor. Mas por quê esta dificuldade ?

Visão Micro x Visão Macro
Imagine-se no meio de um campo de futebol. Olhando para o chão você vê a linha branca que delimita o meio de campo. Você olha para um lado e para o outro e tudo parece certo. Você consegue dizer se esta linha está torta ? Se ela realmente divide o campo ao meio ? Se uma das metades do campo não está maior que a outra ? Difícil. Agora vá para um ponto bem alto na arquibancada e você conseguirá ver o que está errado. Melhor, pegue um helicóptero, veja o campo de cima e... voilá, você terá a nítida noção se está tudo correto e poderá inclusive orientar a equipe de manutenção para corrigir os problemas. Agora, vamos considerar as folhas como o item mais elementar de um gramado de futebol, e que estas podem ser branca (pintada, formando as linhas) ou verde, conseguiríamos responder às questões acima olhando uma a uma com uma lupa ? Agora imagine uma foto ampliada 1 bilhão de vezes. Você consegue dizer a cor dos olhos da pessoa ? Você consegue dizer se há uma pessoa ? Acho que não.

 

Micro = implementação
Ocorre que quanto mais micro é nossa visão, quanto mais próximos estamos dos itens elementares, mais dificuldade temos em entender o todo. As coisas tornam-se tão micro, tão indivisíveis que é impossível fazer uma análise, que por definição significa dividir, decompor. Qualquer análise deve partir do ponto mais macro e ir dividindo até chegar ao ponto mais indivisível.
    Ao analisar um livro, partimos da idéia geral e vamos dividindo em capítulos, parágrafos, frases, palavras. Não é possível entender apenas olhando as palavras. O autor pode expressar suas idéias de várias formas. As sequencias de palavras são apenas uma forma que ele arranjou de implementar sua idéia. É possível então alterar as palavras sem perder a idéia geral. É possível passar o livro para outro idioma sem perder a idéia geral, assim como podemos trocar cada capim de posição que ninguém notará a diferença.
    Se olharmos para o gramado com uma lupa, folha por folha, estaremos tão perdidos que nem saberemos se estamos dentro ou fora do gramado. Não conseguiremos nem dizer se é um gramado de futebol ou de rugby. O mesmo é com um código-fonte: não é possível analisá-lo olhando linha por linha. É preciso fazer uma síntese - criando uma idéia macro, para depois analisarmos.
    A visão micro nos diz como uma idéia macro foi implementada, mas existem várias formas de implementar uma idéia. Olhe estas duas expressões: “2 + 2 = 4”, “3 + 1 = 4”. As duas expressões produzem o mesmo resultado (macro), mas tem seus elementos (micro) totalmente diferentes. Porém só a partir da visão macro (R=4) é que podemos discutir e implementar de formas diferentes.

Não analise um fonte, sintetize-o
Um fonte é o nível mais indivisível de uma idéia - você não pode analisá-lo. Quando alguém olha um código e modifica, está fazendo (mesmo que inconscientemente) uma síntese, e depois uma análise. Se dispomos apenas do micro, então temos que fazer uma síntese para fazer uma análise. Tudo que é análise é assim: processos de uma empresa, música, livros, fontes, etc. O “micro” é apenas uma implementação do “macro”.
Faça e execute um “Olá mundo” em “ASP + IIS + Win” e outro em “PHP + Apache + Linux”. Se olharmos para as instruções do processador, veremos que são totalmente diferentes, mas embora os resultados sejam iguais.

Mapeamento do programa Em resumo: o “micro”, a implementação, o fonte em si é supérfluo e não é analisando ele que você entenderá o código ou conseguirá discutí-lo. Faça antes uma síntese: qual a missão deste programa / quais são as características que o definem (missão) ? Quais os serviços que ele dispõe para alcançar sua missão (serviços) ? Quais os macroprocessos de cada serviço ? Quais os processos de cada macroprocesso ? Quais os subprocessos de cada processo ? Quais as atividades que compõe cada subprocesso ? Escreva estes 6 níveis e você começará a entender o fonte, por mais complexo que ele seja.

Por quê as pessoas contribuem com o Postgres e com o Software-livre

 segue interessante post no blog do Momjian sobre o porquê de participar da comunidade de software-livre:

Na última semana houve uma pequena discussão filosófica na lista sobre o por quê das pessoas contribuirem com o Postgres e com projetos de software-livre (que definitivamente vale a pena ler). 

Acredito que o comentário mais profundo foi este:
 
"Trabalhar no PostgreSQL é uma aventura e uma experiência muito boa - é um grande aprendizado para mim. É algo para quem gosta de programar, para quem gosta de 'hackear' e não para aqueles que ficam no escritório somente por suas 8 horas. Além disto, eu uso o PostgreSQL no meu trabalho - assim, 'hackear' o PostgreSQL me dá um perfeito conhecimento, um perfeito contato com desenvolvedores, e eu ainda posso trabalhar junto com os melhores programadores do planeta. e eu posso criar algumas coisas boas. Provavelmente se eu trabalhasse em projetos comerciais poderia ganhar mais dinheiro - mas a vida é uma só e dinheiro, embora importante, não está no topo das minhas prioridades - a vida DEVE ser uma aventura ! "

Administração de Empresas: 99% de frustraçao garantida !

conversa com um futuro administrador de empresas:

* Eu: por quê estás fazendo administração?
* Fulano: sempre quis ser chefe.
* Eu é por isto que digo que administração é o curso que mais fabrica pessoas frustradas. Para cada curso de administração aberto, é necessário abrir outro de psicologia só para tratar os futuros “administradores de empresas”.
* Fulano: como assim ?
* Eu: administração é um bom curso, mas a maioria acha que vai sair daqui e gerir uma empresa e no fim acaba virando empregado público frustrado ou aceitando qualquer bico para sobreviver. Ah, se os pais tem dinheiro, abre uma franquia e fica o resto da vida nas costas dos pais. 99% de frustração garantida.
* Fulano (levemente irritado): não tenho a pretensão de sair daqui administrando uma grande empresa. Vou começar aos poucos: administrar um setor já é um começo - mesmo ganhando pouco.
* Eu: espero que eu esteja errado, mas sei que isto não vai acontecer. Você quer uma profissão que não existe, fazendo um curso que não tem nada a ver com seu objetivo.
* Fulano (mais irritado): ah tá, administração de empresas não forma administradores ?
* Eu: acredito que não. Um bom administrador é aquele que tem boas habilidades sociais, algo que não é ensinado no curso. O curso te dá as ferramentas técnicas, te força a pensar, mas não trilha o caminho por ti.
* Fulano: e como tú achas que posso ser administrador de uma empresa ?
* Eu: imagina teu crescimento profissional como uma escada. No 1o degrau, tens que fazer todo o tipo de trabalho braçal e te exige apenas conhecimento técnico. A medida que sobes, vai sendo necessário cada vez menos conhecimento técnico na função, e mais sobre gerenciamento. Mudar de empresa é equivalente a mudar à uma escada ao lado - continuas no mesmo degrau - só trocas de escada. Agora, para chegar lá em cima, só tem uma forma: passar por todos os degraus, não existem atalhos - a menos que você seja filho ou afilhado de alguém rico ou importante. A administração te dá técnicas para subir mais eficientemente, mas não te coloca lá em cima.
* Eu: te recomendo começar de baixo e dar o máximo de si - sempre ser prestativo, bem humorado, moralmente sólido e puxando responsabilidade. Na medida que cresceres vais sentir necessidade de ferramentas que te auxiliem e somente com esta visão é que vais aproveitar bem o curso de administração.
* Fulano: maluco...

Wikipédia: POV on Rails

vagando pela web, encontrei uma entrada no artigo "Ruby" da wikipédia que escrevi há certo tempo (abr/07). Lembro de ter ficado profundamente irritado pelo fato do artigo ser mais um comercial da linguagem do que algo que pudesse realmente contribuir com alguém que estivesse interessado na linguagem. Abaixo reprodução do que havia escrito:

embora eu seja simpatizante pela linguagem, creio que há muito POV neste artigo. Ele não está totalmente imparcial, que é uma das principais regras de Wikipédia. Acho que o artigo está bom para ser colocado numa comunidade ruby (por exemplo, "www.ruby.com"), mas deve ser neutralizado para ficar na Wikipédia.

Uma forma de saber se um artigo apresenta POV, é pensar assim: "alguém que odeie Ruby vai concordar com este artigo ?". Se a pessoa discordar, significa que o artigo não foi baseado em fatos verificáveis, mas em gostos/opiniões pessoais, pois fatos são indiscutíveis. Um artigo neutro (NPOV) deve ser aceito tanto por simpáticos ao objeto em questão (Ruby) quanto aos contrários. Assim, tanto o pessoal que acha que páginas web deveriam ser cgi's escritos em assembler, quanto os rubistas devem concordar com o artigo.

alguns POV's que eu encontrei:

• "A linguagem foi criada pelo japonês Yukihiro Matsumoto, que aproveitou as melhores idéias das outras linguagens da época".

Idéias podem ser diferentes, mas não melhores nem piores. No caso, ele detectou padrões que fazim ele se sentir mais confortável, que faziam ele produzir mais e criou uma linguagem assim - mas não que ela seja melhor que outras.

• "a linguagem têm sido alvo de grandes elogios e grandes críticas, justamente pela sua praticidade".

Críticas por ser prática ? Honestamente, não consigo imaginar alguém reclamando do Ruby com frases do tipo: "é uma porcaria, com meia-dúzia de linhas você faz tudo !"

• "Isso deixa claro o conceito de facilidade do Ruby, deixando que você gaste mais tempo para a lógica da sua aplicação do que em formalidades da linguagem."

"facilidade" ?! Hmm, coboleiros acham COBOL fácil de entender porque você tem que escrever tudo nos mínimos detalhes. "COBOL é auto-documentado", como eles dizem. Para outros, o fonte é fácil de entender quando é reduzido, logo comentários atrapalham e não ajudam. Alguém está errado ? Não, apenas se adaptam melhor a uma linguagem ou outra. Assim, o conceito de facilidade não está claro não, pois alguns (pessoal do assembler, por exemplo) vão ter enorme dificuldade em entender o código.

Reportagem na BAND

sempre é bom ver o reconhecimento de nosso trabalho. No dia 4 de julho foi ao ar na BAND, no programa "Brasil Caminhoneiro", uma matéria sobre o "Sistema PAMPA" - sistema de agendamento de cargas que ajudou empresas e caminhoneiros da região - e que tive a honra de criá-lo junto com meu falecido colega Gustavo.

Continuo como líder do projeto, e, embora não tenha recebido 1 milésimo do que ele gerou em lucros, se soubesse do impacto social que ele iria ter, aceitaria pagar do meu próprio bolso para levar adiante uma idéia assim. Pois fazer algo impactante pela sociedade é algo que não tem preço.

Seguem links para o programa:

PS: a única coisa chata foi o fato de não terem me convidado para a entrevista :(

http://www.brasilcaminhoneiro.com.br/conheca-o-sistema-que-acabou-com-as-filas-de-caminhoes/
http://www.brasilcaminhoneiro.com.br/complexo-portuario-de-rio-grande-exemplo-de-eficiencia/