Lançado o mwsX 1.1

Para quem gosta de fazer sites "web 2.0+" em PHP, mas tem preguiça de fazer a comunicação entre o PHP e o JavaScript, hoje foi lançada a versão "1.1" do mwsX.

O mwsX se enquadra na categoria de “mais outra biblioteca facilitadora de AJAX” e versões dele estão rodando em muitos sites que participei/participo desde 2007. Esta nova versão permite usar o PHP no lado cliente e fornece maior compatibilidade com as várias versões de PHP e JS.

Página do projeto:
http://code.google.com/p/mwsx/

Sobre o Projeto:

Por quê criar mais uma biblioteca facilitadora de AJAX ?
Quando descobri o AJAX, da mesma forma que muitos, fiquei empolgado: aquilo era a nova Web. Não precisaríamos mais recarregar toda a página - e isto era só a ponta do iceberg, havia muito mais.

Da mesma forma que muitos, procurei mais sobre a tecnologia e cheguei na combinação “Apache + JSP + Tomcat + AXIS”. Tentei instalar ele e dias depois estava mais confuso do que no início.

Da mesma forma que muitos, a tentativa resultou em um trauma que não gosto nem de comentar: incompatibilidade entre versões, compilações que ficavam em cache, ter que escrever XMLs "na mão". Agora sei como vítimas de crimes graves se sentem - foi horrível, humilhante e vergonhoso.

Com base nesta terrível experiência tentei fazer algo com os motes “fácil de instalar/usar” e “não intrusivo” - e o resultado foi o mwsX. Não estou dizendo que o mwsX é o mais fácil de instalar e usar, isto é relativo de quem o usa e não pode ser medido - você pode usar e achá-lo horrível, dependerá de suas experiências pessoais, mas para mim ele é a biblioteca de AJAX mais fácil de usar e instalar e espero que o seja para muitos.

Valores do projeto
a) ser menos intrusivo possível: você não tem que alterar seu código PHP (ou terá que alterar muito pouco)
b) fácil de instalar e usar: não há instalação, compilação, etc. Você precisa de 2 arquivos e 2 linhas de inclusão (“include” no PHP e “script” no JS): só.

Clientes
no momento existem clientes para o PHP e para o JavaScript, mas sinta-se a vontade para fazer clientes em outras linguagens.

Padrões de Codificação

Conheci um profissional de criação web incrível, suas páginas são como impactantes obras de arte. É o tipo de pessoa que está só esperando que alguma grande empresa o descubra. Enfim, é “o cara”. Ao elogiá-lo para um colega, fui perguntado se ele era bom criativamente ou tecnicamente. “Ué, mas não é a mesma coisa ?” pergunto eu. “Ele faz ótimos trabalhos e o resultado é perfeito. Mas e a codificação dele faz jus à criação?” pergunta o colega.

Isto me fez refletir: já desenvolvi muitos programas que estão em atividade em empresas, mas meu código pode ser realmente uma porcaria. Programo há 21 anos e nunca li sobre padronizações. Por consequência, meu estilo de programação muda a cada semana e nem eu o entendo após algum tempo - imagine outros programadores. Alguns chegam a dizer que o código é criptografado.

O objetivo é alcançado, mas não seria também objetivo dar manutenção posterior ? A falta de ferramentas adequadas (no caso estilo de programação) não poderia estar limitando a criatividade ?

Dito isto, resolvi correr atrás de padronizações de código-fonte e achei os documentos a seguir que espero que sejam úteis para quem quiser criar código para o mundo e não para si só:

OWASP - guia de programação segura: http://www.owasp.org/images/e/e2/OWASP_SCP_Quick_Reference_PT-BR_v1.0.pdf

material sobre padronização de programação PHP:
http://www.dagbladet.no/development/phpcodingstandard/ (Inglês, para mim, o melhor) 
http://www.walkeralencar.com/PHPCodeStandards.pdf (pt-BR, um resumo traduzido do guia da Zend) 
http://framework.zend.com/manual/en/coding-standard.coding-style.html (Inglês, guia da Zend - "fabricante" do PHP)  

artigos sobre padronização: 
http://blog.walkeralencar.com/archives/25 http://www.arnaut.eti.br/op/cppfl25.htm

padronização Java (Oracle). Para programadores de outras linguagens, serve para encontrar pontos em comum com outras comunidades: http://www.oracle.com/technetwork/java/codeconventions-141999.html#680


UPDATE 17/02/2011:
Não sabia que a Google também tem seu próprio guia de estilos:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Divulgando conhecimento

Existem 2 formas de passar conhecimento - criando conteúdo original ou ecoando conteúdo de terceiros. Existe uma piada comum entre estudantes universitários que diz que “copiar de alguém é plágio, copiar de vários é pesquisa”. A menos que seja uma cópia tal e qual, com as mesmas palavras, eu discordo.

Reproduzir conteúdo de terceiros, é muitas vezes considerado plágio, principalmente se o conteúdo é pago. Porém o conteúdo original nem sempre é explicado de forma que todos consigam interpretar - sempre existe alguém que não entende patavinas do que foi dito. Isto quando o conteúdo não peca pela falta de divulgação. 

Ao reescrevermos o conteúdo original, podemos alcançar um número maior de pessoas tanto por usarmos outras formas de expressão - formas muitas vezes mais lúdicas (com outras palavras, vídeos, etc), mas também por divulgar mais o conteúdo. Aí entra o efeito “Twitter” onde a importância da notícia não é medida pelo seu conteúdo, mas sim pela quantidade de repetições feitas pelas pessoas.

A idéia de criar conteúdo original parece nobre, afinal não é plágio. Mas criatividade não é pegar 2 coisas comuns na nossa vida, mas diferentes entre si e mostrá-las juntas, de uma forma que ninguém viu (citação plágio do Stephen King) ? Não seria a originalidade nada mais do que uma criação coletiva que tudo aquilo recebemos (de Michelangelo à TV) e que regurgitamos à nossa maneira (citação plágio de César Brod) ?

Não importa como, mas me parece que a divulgação de conhecimento sempre se justifica.

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 ! "