Já faz algum tempo que eu leio documentações de informática. Acabei aprendendo a ler em inglês pois não havia nenhum manual para o editor Magic Windows II que eu rodava no Apple II em português. De lá para cá li muita coisa que eu gostei e coisas que eu prefiro nem lembrar. Entre as coisas que eu gostei de ler está o livro Programação Perl dos Srs. Larry Wall, Tom Christiansen e Jon Orwant. É bom pois é bem abrangente, bem escrito, com boa profundidade e bom humor. A documentação oficial do PostgreSQL também é bem escrita e bem abrangente. Uma boa diferença é que como o livro de Perl não pretende ser uma documentação oficial, ele é mais descontraído. Esta é uma característica comum das documentações relacionadas com Software Livre.

Uma outra diferença fundamental é que a documentação do PostgreSQL mostra detalhadamente “o que” mas mostra pouco “como”. Isto não significa que precisamos de um livro do tipo “Torne-se um DBA PostgreSQL em 7 dias”. Estes livros costumam ter o péssimo hábito de emburrecer as pessoas com receitas de bolo prontas e não convida o leitor a pensar ou tomar decisões. Quando li a documentação oficial do PostgreSQL pela primeira vez, me senti finalmente encorajado a começar a modelar meu primeiro sistema dedicado a ele. No entanto, uma infinidade de desafios e decisões apareceram no caminho, e a documentação oficial tinha pouco a me dizer naqueles momentos. Eu ainda tinha pouca experiência e isso me levou a tomar decisões baseadas muitas vezes no meu bom senso e outras em alguns poucos artigos que encontrei na Internet. Mas… já dizia o Sr. Hobbes, que o bom senso é o dom mais democrático e contraditório da humanidade: todos acham que os outros carecem e bom senso e se julgam igualmente possuidores de boas doses dele. Resultado, fracassei miseravelmente em diversos aspectos.

Com o tempo e envolvimento com a comunidade, fui descobrindo um erro aqui e outro acolá. Aprendendo sobre outros bancos de dados, principalmente olhando para as diferenças entre eles, percebi algumas coisas nas entrelinhas que nem sempre estão explícitas na documentação. Isto me levou a escrever alguns artigos neste blog, particularmente nos últimos tempos, quando comecei a me sentir mais corajoso no sentido de expor minhas idéias e me permitir errar, expondo idéias inacabadas. Isto culminou com uma palestra no PGCon Brasil 2007. A idéia da palestra “Como Fazer um Elefante Passar Debaixo da Porta” era a de ajudar as pessoas que estão começando a utilizar o PostgreSQL, mas não tem tanta experiência como DBA. Olhando para o público do evento, percebo que existe uma minoria de DBAs na platéia. A maioria eram desenvolvedores/analistas/programadores e haviam também administradores de sistemas/redes. A questão é a de que praticamente não existem cursos de graduação para formar Administradores de Bancos de Dados. A meu ver, a maioria dos DBAs foram administradores de sistemas ou desenvolvedores que por alguma razão misteriosa decidiram se especializar nesta área.

Se formos pensar bem, o DBA fica justamente numa posição entre o desenvolvedor e o administrador de sistemas. O novo DBA trás certamente as melhores práticas da sua área de origem. Os administradores de sistema trarão uma preocupação com o uso e monitoramento dos discos, métodos de autenticação autenticação, ajustes do SO e por aí vai. O desenvolvedor trás um padrão de codificação, esquemas de autenticação da aplicação, modelagem, distribuição de objetos, etc. Mas bancos de dados não são novos… já em priscas eras, os computadores utilizam bancos de dados. O modelo relacional, no qual todos os grandes SGDBs se baseam (e ao contrário do que o pessoal da programação orientada a objeto imagina, continuará assim por um bom tempo) foi criado há mais de 30 anos. O livro “Introdução a Banco de Dados” do C. J. Date também já é pode ser considerado um clássico e está em sua oitava edição.

Os bancos de dados relacionais atravessaram a era dos sistemas centralizados em mainframes (que continuam existindo), a era cliente-servidor e a era programação em 3 camadas. O PostgreSQL tem suporte para utilizar tudo isso, mas nem sempre os novos DBAs tem consciência desta história toda. Ao ler a documentação do PostgreSQL, hoje eu vejo décadas de história relacionadas com as suas funcionalidades. Então fica claro para mim, qual livro falta ser escrito para o PostgreSQL. Não é um livro que substiua a documentação oficial. Vale muito mais a pena complementar e traduzir a documentação oficial do que escrever pequenos livros que repetem boa parte do que já existe lá. Hoje eu descobri mais um pequeno livro sobre PostgreSQL. Nada contra o livro. Mas eu não preciso ler ele para saber como ele é. Este tem apenas 240 páginas. Para um livro genérico, isso mal dá para começar. Segundo a editora, a Érica que tem fama de fazer livros didáticos, que mais parecem apostilas. Terceiro, o autor, com quem eu já tive aula, tem dezenas de livros editados no mesmo estilo.

Minha idéia não seria esta, muito pelo contrário. Acredito que um bom livro de melhores práticas deveria estimular o leitor a ler a documentação com freqüência, citando-a em diversos pontos. Mesmo porquê, existe um trabalho intenso da comunidade em atualizar a documentação oficial a cada nova versão do PostgreSQL. Um livro de melhores práticas deveria se um pouco menos dependente de uma versão específica.

Um livro de melhores práticas deveria servir como subsídio didático para cursos de PostgreSQL, deveria conter inúmeros exemplos práticos e conduzir o leitor ao erro. Sim, ao erro. Somente a pessoa que erra tem condições de aprender de fato. Não são os acertos sucessivos que nos fazem acertar, e sim os erros e como corrigi-los. Assim, eu imagino uma aplicação sendo construída a partir do seu início, e as decisões sendo tomadas no meio do caminho. Imagino o livro conduzindo a decisões e discutindo as implicações destas decisões. Imagino muita polêmica onde não há um único caminho correto a seguir. Imagino a coleta de diferentes opiniões que convidem o leitor a pensar e escolher o seu próprio caminho. Imagino exemplos concretos de como seria a implementação em cada um destes caminhos. A questão ao fim é mostrar “como” e não “o que”.

O livro passaria certamente por tópicos que não são específicos do PostgreSQL. Uma coisa interessante seria mostrar as diferenças da implementação do PostgreSQL com as implementações de outros bancos de dados, quando isso for comparável. Imagino particularmente comparações entre implementações do Oracle, DB2, SQL Server e MySQL. Imagino também comparações com o padrão SQL e comparações com versões anteriores do próprio PostgreSQL. Seria muito interessante abrir o jogo aqui. O PostgreSQL não é perfeito e nunca será. Se ele fosse perfeito a humanidade teria esgotado a sua insatisfação e imperfeição eternas. Poderia-se mostrar onde outros bancos de dados oferecem vantagens e desvantagens em relação ao PostgreSQL. Pode-se dizer o mesmo em relação ao padrão SQL, que não é perfeito. No entanto, melhor do que criticar o padrão SQL - afinal, querendo ou não é o padrão que nós temos - devemos comparar os Bancos de Dados tendo o padrão SQL como referência.

Imagino algumas premissas para escrever o livro:

• Escrito a várias mãos. É preciso de alguém para organizar o livro, mas é preciso pegar o que há de melhor na especialidade de cada um. Uns conhecem melhor modelagem de dados, outros conhecem melhor que ninguém como ajustar a performance do seu servidor ou de uma consulta. Em momentos polêmicos, poderíamos citar mais de um autor e deixar o leitor tirar suas próprias conclusões.
• Licença livre. Seria imprecindível adotar uma licença que permita a cópia e modificação do livro. Gostaria no entanto de preservar a contribuição de cada pessoa no livro. Já vi trechos da documentação do PostgreSQL em diversas apostilas por aí. Sim, daquele curso que você está pensando também. Acho que manter os créditos é uma questão de respeito. Cada um pode alterar o livro para as suas necessidades e utilizar da forma que melhor entender, mas por favor, cite os autores que lhe ajudaram.
• Precisaria ser construído aos poucos. A idéia não seria juntar um monte de texto, revisar, publicar e abandonar. Muito pelo contrário, seria feito em capítulos, sendo que qualquer capítulo poderia sofrer acréscimos e correções a qualquer momento, eternamente.
• Precisaria ser construído via Internet. Não há como um projeto colaborativo prescindir do uso da internet. Não tenho certeza sobre a ferramenta correta a se adotar. Imagino que ao mesmo tempo deveria ser tão simples como usar uma ferramenta de escritório, fácil de se transformar em outros padrões como SGML (utilizado na documentação oficial), fácil de agregar novos colaboradores como uma ferramenta Wiki e tavez tão universal como o Google Docs.
• Precisa de um case real a ser desenvolvido. Para que os exemplos se tornem consistentes ao longo do livro, precisaríamos eleger um problema inicial a ser desenvolvido sob diferentes aspectos. Num determinado ponto do livro, chegaríamos a um pequeno grupo de tabelas e demais objetos que seriam explorados por todo o restante do livro. Só precisaríamos definir algumas regras de negócio bem básicas para que o exemplo se desenrole pelo restante do livro. Algumas licenças poéticas poderão ser admitidas, pois algumas técnicas só fazem sentido quando temos centenas de transações concorrentes ou tabelas com milhões de registros. A minha idéia inicial seria utilizar o pagila que já é mantido pela comunidade e vai sendo atualizado conforme novas versões do PostgreSQL vão surgindo. Ele pode ser tão simples e auto-explicável quanto se queira e também pode possuir graus de complexidade bem grandes para exemplificar algumas coisas;
• O público alvo seriam novos DBAs PostgreSQL, que podem ser estudantes, desenvolvedores, administradores de sistemas ou mesmo DBAs que estejam acostumados com outros bancos de dados.
• Deve ter profundidade na sua abordagem. Se sabemos que é possível fazer de algum jeito alguma tarefa, temos que mostrar como. Isto significa ter de desenvolver scripts e procedimentos em diversos pontos, bem como demonstrar a sua utilização com testes reais.
• Citar com cuidado e precisão. Realizar citações com links para a origem com a maior freqüência possível e apenas de fontes com boa credibilidade.

Possíveis tópicos a serem abordados:

• Implementando uma aplicação:
  • Ferramentas de trabalho: editores de texto em Windows e *nix, em modo gráfico e texto, formas de se trabalhar no dia-a-dia.
  • Modelagem básica: criação de tabelas, PK, FK;
  • Padrões de codificação: case sensitive, nomes para objetos, codificação explicita X implícita;
  • Domínios e tipos de dados;
  • Sequências e o uso de chaves artificiais e naturais;
  • ORDER BY, WHERE, GROUP BY, usos práticos;
  • Visões e visões atualizáveis (utilizando o RULEs);
  • Dados hierárquicos, abordagens possíveis;
  • Exportação de dados com dump, copy e PL;
  • Joins e subselects na clausula FROM, WHERE e SELECT;
  • Trabalhando com números: Localização, formatação;
  • Trabalhando com data e hora: Localização, internacionalização, conversão, formatação;
  • Trabalhando com texto: codificação de caracteres, internacionalização, conversão, formatação e manipulação;
  • Busca textual;
  • Desnormalização controlada: Gatilhos, funções e visões materializadas;
  • Uso de esquemas;
• Trabalhando com dados binários:
  • Tipos de uso por tamanho de arquivos, volume total, tipo de acesso e concorrência;
  • Uso do Bytea, OID e sistemas de arquivo;
  • Desempenho, flexibilidade e confiabilidade;
• Autitoria:
  • Campos de auditoria;
  • Tabelas de auditoria;
  • Logs de auditoria;
  • Ferramentas de auditoria;
• Segurança:
  • A rede, o SO, o PosgreSQL e a aplicação;
  • Ambiente de produção, homologação e testes;
  • Arquitetura da aplicação e estratégias de autenticação;
  • Encriptação de dados;
  • Obfuscando código;
  • Contornando falhas de segurança;
• Monitoramento de usuários:
  • Descobrindo o que os usuários estão fazendo no banco;
  • Locks de tabelas;
  • Uso de índices e estatísticas de uso;
  • Logs externos ao banco;
• Backup e Alta Disponibilidade;
  • Escolhendo a melhor estratégia;
  • Backup Lógico;
  • Transferindo dados entre bases;
  • Backup físico off-line;
  • Point-In-Time-Recovery;
  • Backup físico on-line;
  • Stand by;
  • Replicação assíncrona;
  • Replicação síncrona;
• Discos:
  • Planejando o volume de dados;
  • Particionamento do servidor;
  • Volumetria e monitoramento;
  • Distribuição de carga e uso de Tablespaces;
  • Sistemas de Arquivo;
  • LVM;
  • RAID por software e hardware;
• Instalação e Manutenção:
  • Compilação X Pacotes binários;
  • Testando e migrando de uma nova versão;
  • Flexibilidade para o ambiente de testes;
  • Segurança para o ambiente de produção;
  • Simetria entre ambientes;
  • Isolando ambientes no mesmo servidor;
  • Autovacuum manual, automático, full;
  • Reindex;
• Integrando aplicações:
  • DBLink;
  • DBILink;
  • Cargas de dados com dump, copy , via aplicações e outros métodos;
  • Validação, e auditoria na integração;
• Desempenho:
  • EXPLAIN e ANALYZE;
  • PREPARED STATEMENT;
  • Subconsultas;
  • Monitoramento avançado;

Eis aqui uma dica para você, que usa o PostgreSQL e sabe que em comparação com outros bancos de dados, a quantidade de documentação existente é ínfima. Então se você começar a escrever mais sobre PostgreSQL, você se tornará irresistível ao sexo oposto (e/ou ao mesmo sexo dependendo da sua preferência…), vai emagrecer, crescer cabelo, ficar milionário, famoso, respeitado mundialmente, etc, etc, etc. A questão é que há espaço na web para os seus artigos esperando por você. O site nacional do PostgreSQL é um wiki, qualquer um pode se registrar e atualizar um artigo existente lá ou criar novos artigos.

Ok, você não é fã de wiki? Então você pode montar um blog, todo seu. Existem inúmeras ferramentas que permitem como o blogger e o wordpress que permitem você criar um blog em minutos e sem gastar um tostão. E para provar que você terá público garantido, agora existe o Planeta PostgreSQL que reúne as publicações de vários blogs que tem por hábito publicar artigos sobre PostgreSQL em pt_BR. Para entrar no Planeta, basta seguir as instruções e todos os seus artigos relacionados com o PostgreSQL vão aparecer automaticamente por lá.

Há tempos, foi proposto reformular o site do PostgreSQL Brasil, e colocar o Drupal no lugar do MoinMoin. Na verdade o MoinMoin não seria desativado, mas passaria a ser utilizado para organização interna da comunidade. Por inúmeros fatores isto não aconteceu ainda. Eu reconheço que inclusive ajudei a atrapalhar um pouco a história. Mas o curioso é que na época em que isso foi proposto, um monte de gente se propôs a escrever e ajudar. Foi aí que surgiu a proposta do Planeta, que é algo mais simples de criar e manter. Bom, o Planeta está no ar… mas o curioso é que temos apenas 5 blogs nele até agora. É muito pouco na minha opinião… gostaria de ver mais gente escrevendo.

Ok, confesso que tenho escrito poucos artigos técnicos por aqui também… já até me puxaram a orelha… mas se você não sabe sobre o que escrever, então você pode tirar alguns posts que estão na minha fila de espera:

• Monitoramento vi psql e shell;
• Estratégias de autenticação de aplicações e segurança no PostgreSQL;
• Tipos de ferramentas de replicação e suas aplicações práticas;
• Estratégias de backup, recuperação de desastres e alta disponibilidade;
• Ambientes heterogêneos com DBI-Link;
• Usando e abusando das tabelas do pg_class e informatio_schema;
• Configurando logs para diversos propósitos;
• Como criar métricas de performance;
• Procurando gargalos de performance;
• Skytools;
• Ptop;

E por aí vai…

Até agora (21/03) já temos 5 palestras sobre PostgreSQL aprovadas na grade do FISL 9.0:

• Fernando Ike: HA em PostgreSQL: O Elefante disponível para além do infinito HA em PostgreSQL: O Elefante disponível para além do infinito
• Josh Berkus: Using SQL tools to secure your database application
• David Fetter: The Postgres Application Server
• Fábio Telles: Fazendo Um Elefante Passar Debaixo da Porta
• Diogo Biazus: Replicação Assíncrona Multi-Mestre com Bucardo

E se você acha pouco… então venha conhecer a Comunidade PostgreSQL, no Stand M3 que já está na planta baixa do evento bem em frente das salas “John Maddog Hall” e “Richard Stallman”. Vejo vocês por lá!

A exemplo do ano passado, estou soltando uma pesquisa para saber quais são os temas que as pessoas gostariam de ver no PGCon Brasil 2008.

Entre lá e dê sua opinião, agora!

No ano passado ocorreu algo inusitado durante o PGCon Brasil 2007. Um dos palestrantes sumiu do mapa de repente e ficamos com um furo na grade do evento. Então, eis que o Sr. Diogo Biazus em tempo recorde prepara uma palestra intitulada “PostgreSQL Br - Manual de Uso“. A palestra foi um grande sucesso e abordou um assunto que me incomoda há tempos: como participar de comunidades de SL. Infelizmente os slides da palestra do Diogo não revelam a riqueza da palestra. É claro que em alguns minutos de preparação não seria possível fazer melhor, mas o fato é que eu gostaria de compartilhar um pouco do assunto com as pessoas que não estiveram no evento e combinar isso com a minha experiência pessoal.

<devaneio>
Este post começou com uma provocação de um grande colega, o mestre fike. Eu dizia no IRC que me sentia frustrado por ter encampado uma campanha desastrosa para numa ação específica da comunidade de PostgreSQL-BR. Aí veio a provocação: “E o que você aprendeu com isso?”. Eu tinha a resposta na ponta da língua. Na verdade eu ainda estou com as sábias palavras do Sr. Diogo Biazus ecoando na mente. Mas como diria o Beto Guedes: “A lição sabemos de cor, só nos falta aprender…”. E eu devo dizer que eu sou cabeça dura… então cá estou eu escrevendo novamente. Acredito que aprendo muito quando escrevo, já é uma prática antiga minha. Acho que todos deveriam escrever o que pensam. Ao escrever, (com suas próprias palavras, não copiando), compilamos uma série de idéias em algo que deve fazer sentido para quem lê. Ainda tenho muito o que aprender… acho que o dia em que eu conseguir traduzir o que penso com poucas e simples palavras, serei uma pessoa mais sabida. Menos é mais… sei disso, só não sei como fazer ainda. Quem sabe na minha próxima palestra no FISL não consigo diminuir o número de slides… falar menos e ensinar mais?
</devaneio>

Motivos para participar de uma comunidade de SL

A primeira coisa que aprendi é que existem vários motivos que levam as pessoas participar de uma comunidade. O que nem sempre é óbvio é que nem todos estão lá pelo mesmo motivo que você. Mais que isso, nem sempre você mesmo tem clareza dos seus motivos. Você pode entrar com um propósito, continuar por outros e sair por algo completamente alheio a tudo isso.

1. Você quer aprender mais sobre a tecnologia X: este é o motivo que leva a maioria das pessoas a participar de uma comunidade. Veja que este não pode ser o único objetivo de todos, afinal, se todos quiserem apenas aprender, não haveria ninguém para ensinar. Mas a sede de conhecimento é algo que também tem as suas nuâncias. Há pessoas que querem aprender sobre determinada tecnologia por acreditarem que ela seja interessante por N motivos, há aqueles que são curiosos, há quem o faça por obrigação. Mais que isso, as pessoas estão acostumadas a aprender de formas diferentes. O conhecimento não é algo linear, não está contido em um livro ou em uma pessoa, ele existe e se recria a partir das relações humanas. Tarzan jamais aprenderia a falar, ler e escrever com livros numa ilha deserta. A relação entre os seres humanos é fundamental neste processo. Portanto as comunidades são espaços privilegiados para o aprendizado, pois é um ponto de encontro de pessoas dispostas a discutir sobre um assunto específico.
2. Você quer conhecer gente que gosta da tecnologia X: fazer amizades com pessoas com interesses semelhantes é um bom motivo para se entrar numa comunidade. Isto pode significar querer aprender mais sobre a tecnologia X, mas pode significar encontrar pessoas com as quais você gostaria de tomar cerveja, conversar no IRC de madrugada ou filosofar a ermo por aí. Nerds, Geeks, Hackers, seja como se denomina ou se intitulam estas pessoas, elas gostam de se encontrar e se organizar em grupos, não apenas para aprender, mas para conviver. Este é um lado muito importante das comunidades que algumas vezes são subestimadas: a diversão. Algumas pessoas são atraídas pelo simples fato de ser divertido, pelo ponto de encontro privilegiado da comunidade.
3. A vaidade, é um motivo muito comum. Você quer ser reconhecidas pelo seu talento, seu conhecimento, sua capacidade e seus feitos. Apesar da vaidade ser vista como um pecado, com um pouco de bom senso ela não chega a ser um problema e pode ser canalizada para uma grande virtude. O mundo perderia muito se os grandes gênios não compartilhassem com o mundo as suas grandes invenções. O fato é que a vaidade existe as comunidades convivem com ela o tempo todo. Há de se entender que um falso modesto pode ter uma presença parasitária enquanto um vaidoso sincero pode ser uma grande dádiva se alimentado corretamente. Por fim, lhes digo, o fato de montar um blog e exibi-lo ao mundo não tem uma ponta de vaidade?
4. Você quer se projetar profissionalmente. Assim como o aprendizado é irmão da amizade e da diversão, a vaidade é quase que gêmea da ambição. Você quer melhorar de vida ou não? O segredo do sucesso profissional não está apenas no conhecimento ou na sua capacidade técnica, está também no seu networking. Não adianta ser puritano e achar que você não pensa em ter sucesso profissional. Uma boa comunidade sempre foi um espaço de livre trânsito entre profissionais de uma área específica. Ser conhecido entre os profissionais mais destacados de uma comunidade poder ser uma boa porta para novas oportunidades. De fato, quando alguém precisa de um profissional com um perfil específico, para um trabalho importante, buscar uma indicação de alguém de destaque da comunidade é um caminho seguro. Os profissionais chaves, assim como executivos, não são encontrados em classificados ou empresas de consultorias, são encontrados por indicação. Você nunca será indicado para uma posição assim se não for conhecido.
5. Você quer ser altruísta e ajudar as pessoas de alguma forma. O Software Livre tem este chamariz que trás paz de espírito a pessoas de bom coração. Particularmente, este é um dos motivos mais citados ao se participar de uma comunidade e um dos menos realizados. Sejamos francos… numa lista de discussão de milhares de pessoas, quantos realmente ajudam com alguma coisa? Há no plano corporativo uma relação de “ganha-ganha”, que faz com que grandes empresas contribuam com algumas comunidades. Este tipo de investimento costuma ter retorno em termos de marketing interno e externo e também retorno em termos de redução de custos. Portanto, não podemos ignorar o fato de que o altruísmo tenha suas compensações. Mas de fato, ajudar pode ser gratificante, ainda mais se ele vier acompanhado com novas amizades e compartilhamento de conhecimento. É um trio realmente imbatível no plano do indivíduo.
6. Você é um evangelizador e quer mudar o mundo. Isto é muito parecido com o altruísmo, mas tem diferenças notáveis. Os evangelizadores não querem apenas ajudar, eles querem mudar o mundo. O apelo do SL para este tipo de pessoa é muito comum. Discussões sobre patentes, licenças e coisas do gênero tem vazão plena entre os evangelizadores. Muitos acham os evangelizadores chatos, mas eles são importantes, pois são o contrapeso da comunidade. O evangelizador, se não se desgastar numa verborragia sem eco podem propor mudanças de qualidade significativas para a comunidade, podem humaniza-la. Sim, não se espantem, os chatos podem ser parte importante da humanidade.

Problemas comuns encontrados nas comunidades de SL

As pessoas estão no meio deste caldeirão fervilhante da comunidade. Muitas coisas bacanas e ruins acontecem neste meio. Cada vontade pode ter seu lado positivo e negativo, dependendo da sua dose, forma e momento histórico em que a comunidade se encontra. A fusão de forma e conteúdo é tão importante nas comunidades que deveriam haver estátuas erguidas em torno desta idéia. Você não pode ser vazio de conteúdo, você deve ter algo a dizer ou então se calar. Mais do mesmo não traz nada de interessante, assim trazer alguma informação nova é importante. Mas tão importante quanto a mensagem é como ela chega aos seus receptores. O mesmo conteúdo, quando lapidado em sua forma se traduz num recepção completamente distinta. Cada comunidade possui a sua própria etiqueta, suas regras e códigos de conduta. Estas regras nem sempre são uma camisa de força, podem até ser modificadas, mas devem ser seguidas.

Mesmo com forma e conteúdo em harmonia, exitem alguns problemas intrínsecos aos motivos que o levam a querer participar da comunidade:

• Todos querem que você aprenda, mas você deve se esforçar um pouco para isso. Aprender exige esforço e disciplina. Se você não leu a documentação pertinente e não fez no mínimo uma busca no Google, então você não se esforçou. Não espere que as pessoas lhe ajudem sempre se você não dá valor ao esforço dos demais.
• Pode acontecer de ninguém saber como lhe ajudar, ou não ter tempo para lhe ajudar no momento em que você precisou. Você não tem em absoluto o menor direito de reclamar se isso lhe acontecer. Mas se acontecer, pense antes de mais nada se você foi claro na sua mensagem, se se comunicou da FORMA adequada. Saber perguntar é uma arte. Formular uma pergunta é algo mais complexo do que parece. Paulo Freire dizia que “uma boa pergunta vale mais da metade da resposta”. Vale a pena ler o texto de Eric Raimond “How To Ask Questions The Smart Way“, ou sua versão traduzida.
• O fato de você ter amigos na comunidade, não significa que você possa abrir mão de um mínimo de formalismo na comunicação. Quando você estiver apenas entre amigos, você pode relaxar, caso contrário, as regras da comunidade devem ser respeitadas. Utilizar a gramática minimamente correta, evitar gírias e muito respeito a todos é o mínimo que se espera. Cuidado com as brincadeiras, algumas pessoas certamente interpretarão você de forma equivocada. Em resumo, embora a descontração seja muitas vezes desejada, nem todos estão lá para brincar, muitos levam as coisas mais a sério.
• A humildade costuma estar presente entre os grandes desenvolvedores. Mas os entusiastas muitas vezes se empolgam. Não banque o dono da verdade. Se deseja criticar um ponto de vista, o faça de forma fundamentada e com muito respeito. Jamais se autodenomine hacker, mestre jedi ou qualquer outro título honorífico. Se os outros o fizerem, muito bom, mas nunca se auto glorifique. Campanhas de autopromoção então, nem pensar. Mesmo que você consiga disfarçar, alguém vai descobrir e você será abominado.
• Todos querem crescer profissionalmente, não apenas você. Não queira vender nada para ninguém, nem você mesmo. Você nunca será respeitado na comunidade se o fizer. Você pode divulgar seu currículo, produtos e serviços no seu blog pessoal, mas nunca em meio a comunidade, a não ser que você decida por exemplo patrocinar a comunidade. Banners em sites, quotas em eventos e outras formas de doações são válidos, mas é só.
• Se você quer ajudar, o faça de forma competente. Ensinar por exemplo, exige um mínimo de preocupação com a didática, com forma e conteúdo. O seu receptor pode não estar entendendo patavinas daquilo que você quer explicar. Já que está ajudando alguém, o faça da melhor forma possível. Isto não significa que você tenha que dar tudo mastigado na boca, mas que sua mensagem tem de ser clara e elucidativa. Pode ser um link para um artigo ou um capítulo da documentação, mas tem de ser acompanhado de um pequeno comentário explicando o que esperar daquele link. É comum acompanhar longas conversas sem pé nem cabeça que poderiam ser resolvidas com uma pequena explicação um pouco mais clara.
• Software Livre não é time de futebol. Se você gosta de determinada tecnologia, você não deve querer empurra-la em detrimento de outras. Você pode comparar, mostrar situações onde ela leva vantagens e desvantagens, mas não deve desmerecer as outras. Uma coisa é dizer que a tecnologia X é melhor e Y não presta. Outra coisa é dizer que num cenário A, a tecnologia X lhe atende com N vantagens. Veja, a forma é tudo. Se você simplesmente gritar que X é melhor que tudo, você não estará contribuindo com o ouvinte e ainda estará denegrindo a imagem da tecnologia X que terá fama de time de futebol.
• Ajude com o que você pode. Se você não tem pique para dar conta de uma determinada tarefa, não se proponha a ela. As pessoas passarão a contar com você e se você não der conta, a comunidade será prejudicada se você não der conta do trabalho. Há um ditado para isso: “Prometa pouco, faça muito e você será lembrado. Prometa muito, não cumpra e você será esquecido… ou pior, será lembrado!”
• A comunidade é como uma pessoa que nasce cresce, se multiplica, envelhece e morre. Você tem de saber avaliar o momento das coisas acontecerem. Por mais que você tenha uma visão além da comunidade, ela andará conforme o seu rítimo próprio e não há nada que você possa fazer contra isso. Você não pode apressar muitos as coisas, com o risco de desgastar a comunidade e causar um ataque cardíaco em plena adolescência. Um grupo muito novo precisa amadurecer e crescer de forma gradual. Por mais que você já tenha participado de outras comunidades mais maduras e tenha expectativas grandes, isto não se traduzirá em ação se você não encontrar um grupo de pessoas com expectativas semelhantes e mais: disposição para colocar em ação seus planos. Acredite, as pessoas crescem junto com a comunidade, você também crescerá.
• Nunca espere o reconhecimento da comunidade. Não existe um momento onde a comunidade se reúne para saudar os mais valorosos membros da sua comunidade. Não existem prêmios, bailes de gala ou fogos de artifício. Não cobre dívidas de gratidão. Não espere sequer um “muito obrigado’. Apenas esteja lá e faça o melhor que você está disposto a fazer.
• A maioria das comunidades tem uma estrutura muito informal. Pouquíssimas tem uma estrutura legal que a ampare, com cargos e eleições. Portanto não espere ser considerado um “membro oficial”. Algumas comunidades crescem a um ponto de criar uma estrutura burocrática maior, mas são poucas comunidades que o fazem e mesmo assim, você não deve esperar ser condecorado ou consagrado membro oficial. Alguns dos maiores e mais respeitados membros de comunidades tem um vínculo muito frágil ou até inexistente com o seu aparato burocrático.
• Não brigue. Não alimente os trolls. Os conflitos aparecem com alguma frequência, mas o seu impacto é inversamente proporcional a capacidade das pessoas ignora-las. O tempo perdido com brigas poderia ser gasto com coisas muito mais úteis como tomar cerveja com os amigos, passar mais tempo com a família ou até ajudar mais a sua comunidade.
• Conheça os meios de comunicação e saiba utiliza-los. A maioria das comunidades é geograficamente dispersa. Se você domina o Inglês, você está em contato com o mundo inteiro, o local onde você está não importa. A ferramenta mais importante de comunicação é o e-mail. Parece simples de usar, mas as pessoas cometem erros terríveis quando participam de listas. Alguns erros são até perdoáveis, mas em geral os erros afastam os seus leitores. Leia uma vez na vida a RFC 1855. Outras ferramentas como IRC, Wiki, TRAC, CVS, CMS e outros são fundamentais para você participar de forma efetiva. Aprenda, seja feliz e deixe os demais felizes também.
• Os iniciantes costumam levar puxões de orelha quando começam a ajudar. Acontece que não basta ajudar, é imprescindível ajudar da forma correta. Revisar o código/documentação/tradução/whatever de um novato dá trabalho para os mais experientes. Um trabalho mal feito dá mais trabalho para o revisor do que se ele mesmo o tivesse feito des do início. Há regras severas para incorporar alterações num código complexo. Até o Sr. Marcelo Tosatti levou vários puxões de orelha antes de ter seus primeiros patches aceitos.

Participe

Se você é uma daquelas pessoas que está entrando agora, está com todas as boas intensões do mundo, saiba que há inúmeras formas de se colaborar com uma comunidade. A mais importante dela é sem dúvida ajudar a melhorar o software. Lembre-se que por mais que sejam importantes outras contribuições, a comunidade não existiria se o software não existisse. Esta deveria ser a meta de todos os membros da comunidade. No entanto segue algumas coisas que você pode fazer:

• Ajude a escrever o software;
• Se você não sabe programar, ajude a documentar;
• Se não sabe documentar, ajude a traduzir,
• Se não sabe traduzir, ajude outras pessoas a utilizar,
• Se não sabe utilizar, ajude a divulgar,
• Se não sabe divulgar ajude a testar.

Meritocracia é a chave da participação na comunidade. Meritocracia - em comunidades de SL - significa que quem faz tem mérito e quem não faz não tem. Simples assim. As decisões são tomadas por aqueles que fazem. É muito comum as pessoas ficarem esperando que algum líder, cacique, chefe, mentor, ou seja lá o que for, delegar uma tarefa para você. Surpresa… isso não acontece. Você deve se candidatar às tarefas e não esperar que alguém lhe escolha para isso. Na maioria das vezes você faz alguma coisa e só depois apresenta para a comunidade o resultado do seu trabalho. É simples assim:

• Você tem uma idéia para fazer algo, ou verifica uma lista de coisas que a comunidade gostaria de fazer. A maioria das comunidades mantém um ‘todo list’, conheça ela, você pode ter algumas idéias a partir de lá. É comum também haver uma lista de coisas indesejadas, que não serão bem recebidas se você propor. Se a comunidade em que você quer atuar não tiver nenhum destes recursos, vale a pena consultar o histórico das suas listas de discussão ou fóruns para verificar se o assunto já foi debatido antes.
• Verifique se já existe alguém fazendo isso. Se tiver, você pode ajudar a pessoa ou grupo que esta fazendo isso ou escolher outra coisa para fazer. Pesquise bem antes de se lançar a ação. É muito comum você achar que teve uma idéia nova e na verdade ela já estar implementada, mesmo que em algum canto obscuro da Internet. Há muitas pessoas querendo ajudar, mas a maioria quer ter a glória de fazer algo só seu, ao invés de ajudar em algo já existente - basta pensar nas centenas de distribuições Linux existentes que isto começa a fazer muito sentido. Isso é improdutivo e causa uma grande confusão na comunidade - pense que criar algo novo é mais fácil do que mantê-lo atualizado.
• Faça! Se for uma tarefa que você pode cumprir sozinho, faça e só mostre quando você tiver algo funcional em mãos. Se a tarefa depende de outras pessoas, combine bem antes e tenha certeza que todos estão dispostos a faze-lo. Não divulgue a iniciativa se você não tiver certeza que terá condições de cumprir. Vale a máxima: “talk is cheap, show me the code”.
• Antes de mostrar o que você fez, verifique o calendário da comunidade. Há momentos em que a comunidade não está aberta para determinadas contribuições. Há épocas em que algumas prioridades são estabelecidas. Quando a comunidade está prestes a lançar uma nova versão de um software, os testes são importantes e código novo é indesejado. A organização de grandes eventos também costuma movimentar grande parte da comunidade para algumas ações, em detrimento de outras ações de divulgação. Bom senso é fundamental.
• Mostre o que você fez, esteja aberto a críticas e contribuições. Aqui você deve ser muito cuidadoso na forma de se comunicar. As pessoas devem entender exatamente o que você fez, devem se sentir confortáveis e estimuladas a analisarem e criticarem o seu trabalho. Seu trabalho só vai crescer se as pessoas incorporarem ele na comunidade, e isto depende da qualidade do seu trabalho e da forma como ele foi apresentado. Não estrague tudo com uma apresentação tosca ou arrogante.

É muito comum algumas pessoas participarem de várias ações ou se especializar em uma tarefa. Existem pessoas cuja participação vem em ondas, participando ativamente por um tempo e desaparecendo depois. Existem pessoas que gostam de algumas tarefas e odeiam outras. Uma coisa universal é que todos erram. Eu falhei miseravelmente em vários momentos. Acho que algumas pessoas já ficaram um tanto aborrecidas com os meus erros. Já venho errando há alguns anos… espero estar apto a acertar mais e cometer novos erros no futuro.

É fato:

• O Linux historicamente escala melhor do que o FreeBSD;
• O PostgreSQL historicamente escala melhor que o MySQL;

Digam o que quiserem, todos os testes conduzidos por pessoas sérias parecem concordar com estas duas afirmações. Para quem não sabe, “escalar” significa aumentar de performance proporcionalmente ao número de CPUs existentes no equipamento.

Mas o tempo passa, e como prometido, a versão 7.0 do FreeBSD parece ter cumprido a promessa de melhorar o escalonador de processos. O resultado você observa aqui. Os testes podem não ser 100% fidedignos ao representar uma situação real com banco de dados, mas os números parecem ser bastante promissores.

Parabéns a equipe de desenvolvimento do FreeBSD… certamente vocês vão ganhar novos DBAs como usuários.

OBS: Os testes foram realizados com até 8 cores, não há informações para um número maior de processadores.

Ok, é infame… vi no Use Perl.

I am the very model of a database relational,
My updates are atomic and ACIDic and transactional,
My planner aims to optimise your queries scatological,
My indexes will cope with SQL that is pathological

My data types encompass from mundane to geographical,
My data safety record shows concern that’s quite fanatical,
My cost per TPC will beat both DB2 and Oracle,
And yet the plebs persist in writing apps for bloody MySQL!

Opa… 2008 realmente começou! Vejamos algumas novidades:

• O Sr. Leonardo Cezar nos honrou finalmente com seu conhecimento sobre PostgreSQL em seu blog, o Postgreslogia’s weblo. Como era de se esperar, material de primeira qualidade… imperdível!
• Outro novo site é o PostgreSQL Docs, um wiki com diversas documentações em inglês. O site em 4 dias de existência tem crescido num rítimo bom com mais de 50 documentos, apontando para inúmeras outras documentações também. Não deixe de anotar esse.
• Acredite se quiser, mas dentro do site da IBM, encontra-se a notícia com o título: “2008 The Year For PostgreSQL“.
• O 9º FISL se aproxima, vai ocorrer nos dias 17, 18 e 19 de abril. Além de mim, várias pessoas do PostgreSQL nacional e internacional estarão por lá palestrando. O PostgreSQL promete fazer mais uma participação memorável. A novidade este ano fica por conta do Stand da comunidade que estará mais incrementado, graças a valorosa contribuição da Isis e demais voluntários. Se você vai para lá de avião, fica aqui a dica, a Varig está com bons preços.
• O PGCon 2008, o maior evento de PostgreSQL vai ocorrer em Otawa, Canadá no dias 20 a 23 de maio. O evento tem a maior concentração de desenvolvedores do PostgreSQL vindos dos 4 cantos do planeta, inclusive do Brasil.
• O número de eventos sobre PostgreSQL realmente explodiu em todo o planeta. Nós aqui no Brasil já iniciamos a organização do PGCon Brasil 2008. Muito breve já teremos data, local, chamada de trabalhos e outras novidades. Aguardem!

Bom, por enquanto é só pessoal.

A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

“Prezado Fabio Telles

Avaliamos sua proposta ‘Fazendo Um Elefante Passar Debaixo da Porta’ e informamos que ela foi aprovada pela comissão organizadora do fisl9.0.

Aguardamos sua confirmação até o dia 07 de Março.

Obrigado.
–
Comite de Programa do fisl9.0 - http://fisl.org.br
Associação Software Livre.Org
*****************************
http://www.softwarelivre.org
http://associacao.softwarelivre.org/”

Em resumo… guardem uma Polar para mim!!!