Vendo Shorter Oxford English Dictionary

Vendo minha quinta edição, pela Folio Society, de Londres, do Shorter Oxford English Dictionary, título da Oxford University Preß, na cidade homônima. Tudo da Inglaterra, claro.

O motivo é a pretendida troca pela nova, sexta edição. O volume está em perfeitíßimo estado, com muito pouco uso.

Google tropeça feio — e leva muita gente junto

Tenho um bom amigo que é um ótimo informata — e foi prejudicado pela Google.

Ele foi levado pela Google de seu estado natal para trabalhar em Belo Horizonte, Minas Gerais, junto com filha e mulher — que agora está grávida. E depois de cerca de um ano, a Google fechou seu departamento em Belo Horizonte e ele se vê desempregado, em terra estranha, com três dependentes.

É ou não sacanagem?

Mapear e Reduzir em PostgreSQL

O ‘Mapear e reduzir’, o conceito da Google para processamento de grandes quantidades de dados implementado como MapReduce, foi incoporado em dois derivativos do PostgreSQL, o Aster e o Greenplum.

Não fui atrás ainda dos detalhes de implementação e uso. Devido à licença do PostgreSQL, não neceßariamente temos o código-fonte desses derivativos; e conheço peßoas da comunidade, com muito mais conhecimento do que eu, que acham que na verdade ißo não é útil, mas apenas uma jogada de publicidade para aproveitar o nome Google. Vejamos!

Palestras da II Conferência Brasileira de PostgreSQL (2008)

Finalmente estão disponíveis os materiais referentes às palestras da II Conferência Brasileira de PostgreSQL (2008), vulgo PgConBR2008. Inclusive minha meia-palestra com o Euler Taveira de Oliveira e meu tutorial (também disponível em lâminas), assim como a palestra que traduzi do David Fetter.

Há alguns erros ortográficos e coisa e tal; se conseguir, um dia corrijo.

Aliás: os fontes estão disponíveis tanto para a Falando elefantês quanto para a O Elefante aparelhado; no caso desta última, para compilar o LaTeX são necessários os cabeçalhos de artigo ou de lâminas.

Primeiras fotos do PgConBR 2008

Estão no Shutterfly as primeiras fotos da II Conferência PostgreSQL Brasil (2008). São apenas três agora, duzentas e onze devem seguir-se nos próximos dias (ou semanas...) Paciência!

Aproveitando, aceito sugestões de onde carregar fotos em resolução mais alta ou até nos originais DNG ou ORF — mas tem de ser sem limite de espaço de armazenamento.

Não financie perdulários

Sei que há causas muito mais nobres, como a proteção à vida humana na forma de embriões, sobre as quais não me manifestei aqui — a única desculpa que posso dar são minhas preocupações diuturnas.

Mas não será isso que me impedirá de pedir a todos os meu leitores — vocês dois sabem quem são! — para assinarem o manifesto contra a CSS.

Minhas propostas ingênuas palestras para o PgCon BR 2008

Estou completamente sem originalidade — e sem tempo. Há outras coisas sobre o que escrever, mas, assim como duas vezes já nos últimos meses (e a segunda desde ontem) vou seguir o Fernando Ike com minha exposição de propostas ingênuas de palestras para a Conferência Brasileira de PostgreSQL 2008.

Lembrando que hoje (dia vinte e sete de junho do ano da Graça de dois mil e oito &c &c) é o último dia para apresentar as propostas.

Um elefante previdente: preparando-se para o futuro de seu sistema com uma boa arquitetura e modelagem de dados em PostgreSQL.

Palestra

Público Alvo: intermediário

Resumo

Freqüentemente vemos, em listas de discussões e outros fora de comunicações, pessoas pedindo ajuda com problemas decorrentes de abordagens ingênuas de arquitetura de sistemas, e dois dos aspectos mais problemáticos têm sido a arquitetura e a modelagem de dados. Muitas vezes os problemas só aparecem quando sua correção é praticamente impossível. Veremos quais conceitos básicos de administração e modelagem de dados são mais críticos para um sistema à prova de futuro, e como aplicá-los em sistemas PostgreSQL com alguns exemplos básicos em SQL e D.

Descrição

Problemas de arquitetura: a tragédia do cliente servidor e a crise de software.

Manipulando os dados onde estão: evitar turismo de bits.

Problemas de organização: saiba do que fala antes de abrir a boca.

Tipos (abstratos) de dados e domínios SQL: evitando a confusão.

Entidades e relacionamentos: cada coisa no seu porta-coisa.

Restrições de integridade: deixe a base de dados cuidar de si.

Problemas de modelagem: a otimização precoce é a raiz de toda sorte de males.

Normalização: otimizando o gargalo mais comum. Ou você quer mesmo fazer o disco se exercitar?

Desnormalização: ¿¡tem certeza!? Fazendo o disco trabalhar dobrado.

O elefante aparelhado: ferramental e processo de administração de dados em PostgreSQL.

Tutorial (pode também ser resumido numa palestra).

Público Alvo: intermediário

Resumo

Freqüentemente confunde-se modelagem e diagramação de dados, e aí vemos pessoas tentando ‘tirar leite de pedra’: criar um modelo apenas com ferramentas de diagramação, ou de mapeamento objeto-relacional.

Pior ainda, o trabalho de administração de dados não se resume à modelagem. A documentação, a manutenção do ciclo de vida de uma base de dados, o apoio ao desenvolvedor e ao usuário são também responsabilidades do administrador de dados.

Há toda uma variedade de ferramentas para auxiliar na administração de dados, e pretendemos mostrar algumas ao longo do ciclo de vida da base.

Descrição

Documentação: requisitos, interfaces e regras de negócio.

Rascunhos: cérebro, caneta e papel.

O modelo de dados: seu editor de textos preferidos, e DDL. Ou que tal algo melhor?: a possibilidade próxima futura de DDL relacional no Alphora Dataphor como uma interface relacional para PostgreSQL.

O diagrama de dados: AutoDoc e SQL::Fairy, deixe o programa trabalhar por você!

Documentos: AutoDoc, SQL::Fairy, LaTεχ e DocBook. Concentre-se no conteúdo, não na formatação.

Controle do ciclo de vida da base: versionamento, colaboração, e geração automática dos produtos.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe — quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

É uma idéia do Augusto Campos, da qual fiquei sabendo pelo Fernando Ike através do Planeta PostgreSQL Brasil.

Escolhi, além da Wikipædia, o OpenSSH, que é fundamental para a operação segura da Internet (além dos meus sistemas!). E viva a liberdade!

Em defesa do subemprego

Mais um artigo espalhando desinformação econômica. Desta feita é uma blogueira do Estadão, que normalmente não é tão primário: uma Andrea VIALLI (ninguém no Brasil se toca que Andrea não é nome feminino, mas o italiano para André?).

E a bobagem, muito naturalmente, é a velha toada esquerdista-submarxista-antiglobalização sobre más condições de trabalho. Reproduzo meu próprio comentário no blogue da mocinha, com um acréscimo aqui porque o blogue do Estadão não permite edições; adição em itálico:

Se há crianças trabalhando, é porque suas famílias não têm como alimentá-las.

Se crianças assim param de trabalhar, vão parar na prostituição ou na fome.

A solução não é pagar mais caro nas roupas. É ser mais frugal, para que o exemplo constranja ricaços e corruptos, e a renda seja distribuída; e trabalhar mais e, principalmente, mais inteligentemente, para que a renda seja maior.

Agora me veio outra questão. O blogue da moçoila teoricamente é sobre sustentabilidade. O que condições de trabalho têm a ver com isso? O velho problema dos despreparados de separar problemas que parecem insolúveis, o que acaba atrapalhando a escolha de políticas públicas capazes de ajudar a solucionar quaisquer deles.

Livros à Venda

Tenho mais alguns livros à venda na Eſtante Virtual.

Desta vez, é The General Theory of Employment, Interest and Money, de John Maynard Keynes, em capa dura, por R$44.

Quero limpar um pouco a casa, e tenho alguns livros du~ e até triplicados.

Yahoo! e PostgreSQL escalável

Esta é de se fazer pensar. Apesar da esperança que japoneses estejam fazendo algo sobre escalabilidade horizontal com o PostgreSQL, quem chega lá primeiro? O Yahoo!. O Yahoo! não publicou código, mas o simples fato de ter divulgado já ajuda outras iniciativas, e dá a esperança de que o código seja publicado.

Mesmo que o PostgreSQL estivesse sob esquerdo de cópia, essa situação de ter algo tão perto, tão longe, seria inevitável: nem o Yahoo! publica sua versão de PostgreSQL, nem o Google publica seu BigTables. A GNU GPL não obriga publicar código de uso interno, e nem pode: restringir uso interno, que não implique em redistribuição, seria transformar um programa de livre em proprietário.

Mas o mais interessante aqui não é o aspecto de licenciamento, é a perspectiva de bases de dados livres muito mais escaláveis que as atuais. O custo aparentemente é baixo, com menos de mil servidores para 2 PB. Um funcionário da Microsoft diz que é um sistema semelhante ao IBM DB2 Database Partitioning Feature, no qual trabalhou ainda sob o nome de Parallel Edition, antes de ir para o lado negro da Força, mas o fato de haver uma patente na jogada sugere que pode ser que a Yahoo! tenha de fato comprado uma jóia — este é um desenvolvimento duma tecnologia comprada com uma empresa chamada Mahat Technologies, da qual não há traços na Teia fora os relacionados a este anúncio, ao menos segundo o Google; e o que o Google não sabe, não existe!

Já há rumores de que a Yahoo! vai colaborar com a comunidade PostgreSQL, o que é reforçado por seu patrocínio à Conferência Mundial de PostgreSQL. A Hitachi e a EnterpriseDB também têm idéias semelhantes, então mesmo que a Yahoo! esteja com a melhor tecnologia e sua patente não permita que ninguém mais faça algo tão bom, ainda assim certamente deve haver grandes melhorias nessa área. O GridSQL já é um projeto livre, e dizem que a Hitachi vai liberar código também, veremos. A NTT Data, outra empresa japonesa, já está devendo o sistema de envio de registros; talvez as coisas no Japão venham devagar, enquanto eles limpam todo o código de quaisquer problemas que os pudessem envergonhar…

Ingres Relacional

Mais uma notícia interessante de tentativas de implementar plenamente o modelo relacional em sistemas de produção. Hugh Darwen nos diz que

O Projeto D do Ingres busca adicionar ao servidor de bases de dados Ingres suporte à linguagem Tutorial D. […]

O Projeto D possibilitará desenvolvimento de bases de dados usando um ambiente de desenvolvimento completamente conforme à especificação D, consistindo do servidor de bases de dados Ingres e um superconjunto da linguagem Tutorial D, incluindo ferramentas de suporte. […] Vai fornecer um SGBD robusto que, no final das contas, implementará tudo do Terceiro Manifesto, dados temporais e do Modelo Relacional

• Imposição de restrições complexas de integridade de dados afetando muito pouco o desempenho da maior parte das restrições.
• Variáveis de relação virtuais, visões materializadas.
• Otimização semântica de expressões relacionais.
• Atribuição múltipla simultânea eficiente.
• Otimização de bases de dados temporais.
• Especialização por restrição.
• Atualizações irrestritas a variáveis de relação virtuais, quando possível.
• Estruturas físicas de armazenamento auto-organizadas (SGBD autônomo).

Como vêem, são objetivos ambiciosos, e que certamente demorarão para amadurecer. Atualmente, o Alphora Dataphor é uma aposta muito mais segura, embora ainda careça de portes para plataformas livres, especificamente Mono e PostgreSQL. Entretanto, o Dataphor ainda é um sistema virtual, enquanto o Projeto D do Ingres, se for bem-sucedido, será um sistema integrado e já nascerá portável, aparentemente.

Resta ver se conseguirão evitar duas decisões que a Alphora viu-se constrangida a tomar: adotar os NULLs do SQL e abandonar a especialização por restrição. E, principalmente, quando chegarão os primeiros frutos.

‘O Segredo’ ſem ſegredo

Duma reportagem por Pablo Nogueira, na Galileu de julho de 2.007 AD, da Editora Globo:

O aspecto material das ambições dos adeptos não é o fator mais curioso no sucesso de "O Segredo", mas sim o fato de a obra não oferecer nada de realmente secreto. Ou mesmo de novo. "É o tradicional discurso sobre as virtudes do otimismo e do pensamento positivo e da auto-estima tantas vezes repisado", diz a antropóloga Carla Martelli, professora da Unesp e estudiosa da literatura de auto-ajuda. Segundo ela, essas idéias já eram veiculadas nos primeiros tempos do movimento, por volta do final do século XIX e começo do XX.

Dar roupagem contemporânea a coisas antigas é mais uma das grandes sacadas de Rhonda e colaboradores. Esse é o ponto em que a ciência assume o posto outrora ocupado pela religião. Em vez de fazer o leitor abrir o baú da fé, a autora opta pelo conhecimento, ou pelo menos um verniz que banhe as chaves para o sucesso e a felicidade com argumentos menos esotéricos.

Para tanto, a autora começa "O Segredo" afirmando que o Universo é regido por leis. Entre elas uma que ela chama de lei da atração, que estipula que cada um de nós atraia para sua vida aquilo que tem na mente. "Tudo o que entra na sua vida é você quem atrai, por meio das imagens mentais", escreve no livro o palestrante norte-americano Bob Proctor, um dos mais destacados participantes do projeto. Byrne aprofunda a idéia: "Cada um contém uma força magnética dentro de si mais poderosa do que qualquer coisa neste mundo emitida por seus pensamentos". Para ambos, nem é preciso acreditar na lei para que ela entre em ação. "A lei da atração é uma lei da natureza e tão imparcial e impessoal quanto a lei da gravidade. É precisa, exata", afirma Byrne.

O filósofo Osvaldo Pessoa Júnior, professor da USP e especialista em interpretações filosóficas da física quântica, diz que a lei da atração é um exemplo do que em filosofia se chama de naturalismo animista. Essa visão filosófica existe desde muito antes da ciência moderna. Na Antiguidade, era defendida na Grécia por pensadores como Pitágoras e os filósofos estóicos. É uma corrente que compara o Universo a um organismo vivo e dota a natureza com uma espécie de "alma". Nela estariam as explicações para muitos fenômenos. Por exemplo, os seres e objetos dotados de almas semelhantes atrairiam uns aos outros. Daí a crença grega de que "semelhante atrai semelhante".

Leonardo César e os softicidas

Conversa esses dias com o Leonardo César:

Eu: O que é isso?

LC: Isso o quê?

Softcida…

cida = assassinos (?)

E quem são os tais? Maus programadores, gestores, o quê?

Sim, estes mesmos…

Estes últimos, os gestores… certo!

Veja bem, estamos desenvolvendo uma arquitetura bem complexa e distribuída através de webservices (SOAP). Isso envolve alguns bancos e seguradoras e estes normalmente estão utilizando Java ou .Net. O problema é que as ferramentas geram os clientes automaticamente, baseado no WSDL.

Uau! Mas e aí?

E estas ferramentas não são compatíveis com a especificação padrão WSDL e os "programadores" não fazem a mínima questão de ler a especificação e ver que a ferramenta deles não gera o cliente porque fogem do padrão… e daí eu que preciso adequar o WSDL às ferramentas de todos os clientes… por isso odeio softcidas…

Isso me fez lembrar adivinhem o quê? Hybernate!

Pode parecer à primeira vista não ter nada a ver. Mas tem: alguém faz ferramentas de qualquer jeito, sem levar em conta os conceitos e padrões fundamentais, tornando-se um softcida, que vai gerar muito mais problemas do que aparentemente resolve.

Usar Hybernate é cometer softcídio, porque os resultados são terríveis assim que se precisa escalar, e geralmente muito antes, por causa da inconsistência de dados. Evite Hybernate, previna o softcídio. Aprenda dados e SQL.

Entrevista concedida ao Fernando Ike

O que é um Arquiteto de Dados?

A pessoa responsável pela arquitetura e administração dos dados de uma organização. No caso, a arquitetura envolve desde a arquitetura de sistemas de bases de dados até a modelagem dos dados e sua manutenção; e a administração seria mais especificamente a manutenção dos modelos e dicionários de dados.

Qual a interação de um Arquiteto de Dados e um DBA? Ou é a mesma coisa?

Muitas vezes, em organizações menores ou menos estruturadas, a administração de dados é efetuada pelo Administrador de Bases de Dados. Mas normalmente, o DBA deve se ocupar da administração diária dos bancos de dados físicos e seu conteúdo, efetivamente uma administração dos Sistemas Gestores de Bases de Dados. Enquanto o AD deve se ocupar do projeto das bases de dados e sua estrutura lógica, não se envolvendo diretamente nos aspectos físicos.

Ok. corrigindo, Administrador de Base de Dados.

Tanto faz. Databank era o uso até os anos 70, que ficou fixado no Brasil. No resto do mundo se usa base.

Com essa afirmação, é possível supor que o AD seria o chefe de DBA (vou manter a sigla por enquanto…)?

Não, eles colaboram em níveis hierárquicos similares. Imagine um novo sistema. O arquiteto de dados será responsável pelos aspectos lógicos, principalmente a modelagem da estrutura da base; o DBA participará do projeto físico, como questões de distribuição, processamento e armazenamento. Um não trabalha sem o outro, e enquanto o projeto lógico deveria teoricamente determinar o físico, restrições tecnológicas podem (embora indesejável) determinar aspectos do lógico.

Como você afirmou acima, as vezes o DBA acaba executando algumas funções que estariam com AD, no Brasil tem mercado para um Arquiteto de Dados?

Ainda restrito e subvalorizado, mas tem. Empresas que têm na informação seu principal meio de trabalho costumam contratar ou formar um quando amadurecem. Bancos, empresas de informação de crédito, seguradoras e até corretoras de seguros, mesmo fornecedores de programas (é o caso de meu empregador atual).

É verdade que há retrocessos, como o advento da terceirização; assim, há o caso de uma multinacional fabril que terceirizou a mão de obra, de modo que a mesma vaga, que antes percebia determinada quantia CLT, hoje percebe a mesma quantia mas em regime PJ, sem correção significativa.

Outro fator detrimental é o foco em produtos, não em conceitos e processos. Assim, a mesma multinacional já deixou de contratar ótimos candidatos por falta de experiência em determinada marca de ferramenta de administração e diagramação, sendo que o candidato em questão tinha experiência suficiente em mais de uma ferramenta completamente equivalente.

Resumindo, ainda é um mercado bastante imaturo, o que leva a situações como as recomendações do AD serem vencidas por meras impressões e preconceitos de pessoas sem experiência com dados, opinando simplesmente do ponto de vista de vícios de programação por exemplo.

Então é possível afirmar que para um Arquiteto de Dados não é necessário ter conhecimento em vários banco de dados?

Em princípio não. Entretanto, devido à imaturidade de vários SGBDs — citem-se por exemplo, mas não exaustivamente, suporte deficiente a tipos de dados em Oracle, MS SQL Server, Sybase e MySQL, e problemas graves de desempenho e consistência neste último —, muitas vezes é conveniente que o AD possa compreender essas especificidades e trabalhar com o DBA e os desenvolvedores para adaptar a arquitetura e o modelo de dados às circunstâncias tecnológicas.

Não citou o PostgreSQL, ele é um boa referência para quem quer iniciar uma carreira como AD?

Uma das melhores, no mesmo nível do IBM DB2. São os SGBDs que têm o melhor suporte tanto ao padrão ISO SQL:2003 (o 2006 ainda não se fez sentir no dia-a-dia) quanto ao modelo relacional — ambos com restrições, mas ainda assim superiores a todos os concorrentes mais óbvios.

Entretanto, sendo uma área de atuação eminentemente lógica, recomenda-se, mais que determinados SGBDs, o futuro AD tenha um bom domínio tanto do modelo relacional, quanto de outros aspectos da teoria da gestão de bases de dados, e inclusive do padrão ISO SQL:2003 em si. As referências padrão, pela atenção que dão aos aspectos lógicos, são as obras de Chris J Date, embora polêmicas em vários aspectos que chegam a suscitar reações apaixonadas contra e a favor de vários praticantes de prestígio.

Esse é um ponto interessante, pois reflete alguns aspectos teóricos que envolvem o DBA. Um AD necessariamente deve ser um DBA também?

Não necessariamente. Entretanto, justamente devido a todas as restrições tecnológicas atuais, é interessante que o AD tenha a capacidade de adaptar-se a circunstâncias, o que pode ser facilitado se ele tiver tido alguma experiência com aspectos físicos, seja como DBA, programador, analista de sistemas, SysAdmin… isso lhe dará mais empatia com posições eventualmente divergentes na negociação de projetos de arquitetura de dados e modelagem, e possibilidade de dialogar com os problemas físicos reais ou imaginários freqüentemente trazidos por outros profissionais.

Pensando que uma empresa irá contratar uma consultoria para área de banco de dados, o que a mesma economizará contratando um Arquiteto de Dados ao invés de ter somente DBAs?

Nem tudo na vida são economias. Embora o principal foco do AD não seja monetário, porque o resultado do seu trabalho dificilmente é mensurável nesses termos, há muitos erros de projeto caros que podem ser minorados pela presença de um AD, ou pelo menos de um DBA com preocupação pelos aspectos lógicos.

Um dos aspectos do trabalho do AD é a normalização, que evita duplicação de dados que normalmente torna o desenvolvimento do sistema como um todo, mesmo na fase de programação, mais complexo, frágil, lento e arriscado, podendo também gerar custos de manutenção e operação como freqüentes anomalias de atualização, consumo exagerado de recursos de sistema, problemas de escalabilidade &c.

Um exemplo foi uma operadora de telecomunicações brasileira que tinha um consultor ao custo de ao menos nove mil dólares por mês (valor mínimo cobrado pela consultoria, possivelmente muito mais naquele caso específico) para resolver casos de inconsistência de dados. Além desse gasto muito simples e mensurável, essas inconsistências geravam grandes problemas de insatisfação de clientes. Não é difícil imaginar alguns desses problemas tornando-se questões mesmo de relações públicas, no caso de uma operadora de serviços públicos.

Há que se considerar também a questão da eficiência: embora alguns DBAs possam desempenhar funções de AD com razoável competência, será um uso ineficiente do recurso humano, que perderá foco em sua função tradicional sem realmente se concentrar na de AD.

O outro lado da moeda é que, devido ao baixo nível intelectual de muitas equipes de desenvolvimento impedi-las de compreender questões lógicas de conseqüências não inteiramente óbvias e imediatas, o peso da opinião de um DBA praticante pode ser maior que a de um AD. Entretanto, uma equipe com esse problema certamente terá muitos outros problemas igualmente óbvios e imediatos.

É um problema de maturação do mercado de TI no geral.

Aliás, ou de maturação ou, às vezes dá impressão, decadência…

Dê duas ou três dicas rápidas para quem quiser trabalhar como AD.

1. Concentrar-se num sólido conhecimento conceitual;
2. Abstrair problemas específicos de SGBDs, mesmo que depois sejam necessárias adaptações;
3. Desenvolver uma visão ampla, que contemple desde as regras de negócio (== restrições de integridade) até questões de desempenho e manutenção da aplicação.

Administração de dados: codificação de caracteres

Codificação de caracteres. Não deve haver assunto mais insistente na lista brasileira de discussões. ASCII, Latin1 e UTF-8 estão sempre em discussão. Mas alguém pode dizer: ‘Isso não é um problema de administração de dados, mas físico! É uma questão do que é mais eficiente!’ Mas não — a codificação de caracteres limita o que pode ser codificado, e portanto um administrador de dados, sempre que possível, vai querer usar o que for mais flexível, que não estabeleça limites arbitrários.

Ainda tem gente brigando com bases de dados em ASCII. Tipicamente, porque instalou um sistema operacional sem configurar a língua, ficando com as configurações por omissão, ou seja, o local ‘C’. O problema é que o ASCII é 7 bits, portanto codifica apenas 128 caracteres — o que, devido a caracteres de controle, não imprimíveis, pontuação e acentuação para línguas mais votadas, não cobre todos os caracteres da língua portuguesa. Ou seja, é verboten!

A opinião mais corrente parece ser a de que ‘não se precisa mais que Latin1 no Brasil’. Errado! Latin1, cujo nome correto é ISO 8859-1, está obsoleto: por exemplo, não consegue codificar €, o símbolo do Euro. Ou seja, proibido também.

Então, dirão, vamos de Latin9, ISO 8859-15. Sim, é uma escolha razoável. Mas imagine que chegue um chinês maluco, goste de seu programa, e decida levá-lo para a China. Pena, você acabou de perder o negócio de sua vida. E se teu chefe decidir expandir negócios para a Índia, e descobrir que você criou um sistema que só serve para o Ocidente? Pena, você vai ter de procurar outro emprego.

Isso nos deixa com Unicode, do qual a escolha mais razoável no Ocidente é o UTF-8. Sim, UTF-16 é mais consistente, mas além de ser o único suportado pelo PostgreSQL, ocupa apenas um byte para os caracteres ocidentais, que costumam ser a grande maioria, exceto para aplicações estritamente locais do Oriente. E, se você tem algum problema em usar UTF-8… bom, ele suporta qualquer codificação, então certamente é um problema estritamente de aplicação, configuração, até um possível defeito no PostgreSQL ou alguma biblioteca relacionada, mas certamente não é um problema do UTF-8 em si.

Resumindo, a menos que você precise de algo muito, muito específico mesmo, faça-se um favor — Unicode na cabeça.

Administração de Dados: um sistema livre e relacional

Finalmente, habemus um sistema (quase) relacional e livre! Não, o (outramente ótimo) PostgreSQL não é relacional — ele é SQL e, portanto, não relacional. Mas o Alphora é tão livre quanto o PostgreSQL, e é quase completamente relacional, exceto por implementar os NULLs do SQL.

Perde-se algo? Desempenho, por enquanto. O Alphora é implementado por cima de bases SQL, portanto não consegue ter o mesmo desempenho, por acrescentar uma camada com seu próprio interpretador, alguma latência, consumo de recursos &c. Mas creio que vale a pena.

Buracos? Vários. Por enquanto roda somente em MS .Net, e nos SGBDs proprietários mais o MySQL. Mas tendo sido liberado o código-fonte (espero que seja bonito, ainda não vi), a esperança é que logo seja portado para Mono e PostgreSQL. E precisa de mais e melhor documentação.

Padrões em fotografia: negativos digitais

Negativos digitais ſão ſem dúvida a área na fotografia mais em falta de padrões. Muitas câmeras digitais nem ſequer produzem negativos digitais, vulgo arquivos crus. Seus JPEGs ſão os equivalentes digitais das câmeras inſtantâneas Polaroid: decentezinhas, mas não tem como preſervar a longo prazo nem como proceßar para melhorar.

O problema é que o JPEG repreſenta uma redução em relação às informações captadas pelos ſenſores, não tanto em reſolução mas pela redução na profundidade de cor (os ſenſores geralmente captam 12 ou até 14 bits), compreßão, equilíbrio dos brancos &c; todas deciſões que alteram ſignificativamente os reſultados fotográficos mas que não ſão reverſíveis num JPEG, por ißo a necessidade dos negativos digitais.

A preſervação devia ſer óbvia: um JPEG é para ſempre, mas o problema dos negativos digitais é que a grande maioria das câmeras grava formatos proprietários dos fabricantes. Certo, os formatos não ſão muito complexos e ſão todos razoavelmente ſuportados pelo DCRaw; mas ſomente um formato padrão ſerá realmente à prova do tempo, principalmente para uſuários de ſiſtemas proprietários que não uſem o DCRaw.

A alternativa mais viável no momento é o DNG. Definido pela Adobe, foi entretanto baſeado no padrão aberto TIFF/EP, que foi baſeado no padrão TIFF, originalmente pela Adobe, e ſerá ſucedido por uma nova verſão do TIFF/EP. Ou ſeja, tem hiſtória & tem futuro. O ſuporte geralmente ſe reſtringe a marcas menos vendáveis: Leica, Samsung, Pentax, Ricoh, Casio, modelos antigos da Haßelblad. E infelizmente, geralmente os modelos de menor volume de cada marca.

Mais infelizmente ainda para mim, não planejo ter nenhuma câmera DNG num futuro próximo. Há outros aſpectos de padronização que na verdade acabam ſendo tão importantes quanto o formato do negativo digital, e combinados com fatores econômicos acabam ſendo determinantes para mim; pretendo explorá-los aqui em breve. Mas, ſe você está penſando numa câmera, penſe neße fator.

Administração de Dados: tipos & domínios

Seguindo a série sobre os fundamentos da gestão de dados, falemos sobre os tipos de dados.

Fico impressionado com a quantidade de ‘ferramentas de modelagem de dados’ que não passam de diagramadores — porque não suportam o conceito mais básico depois da própria teoria de dados, que é o de tipagem.

Há muita confusão neste campo por erros terminológicos de ferramentas, métodos e mesmo padrões. Por exemplo, quase todos os sistemas de informática suportam alguns tipos de dados — mas geralmente são apenas alguns poucos tipos básicos, não extensíveis pelo usuário. E quando há essa extensibilidade, chamam-nos tipos abstratos de dados, como se houvesse outros tipos não abstratos. Confundem-se tipos com sua representação, de modo que duas representações são tratadas como tipos diferentes. E, por fim, chamam-se domínios a simples nomes dados a determinados tipos básicos, talvez com algumas restrições de integridade associadas.

Ora, tipos nada mais são que domínios e seus operadores associados; enquanto domínios são listas de valores (não necessariamente discretos) nos quais se pode definir um atributo. Assim, os domínios ISO SQL não são domínios de verdade, e o conceito realmente útil seria o de tipos, mas que também não é realmente suportado, e o que é suportado é de difícil implementação.

Sem uma definição de domínios centralizada no SGBD ou ao menos na ferramenta de modelagem, cada relação do modelo vai tender a ganhar diferentes definições para os mesmos tipos de dados, e o caos é o limite. Sem contar as comparações e cálculos absurdos que se fazem entre tipos de dados incompatíveis.

Em PostgreSQL temos uma sorte: os tipos são um pouco melhor implementados que noutros SGBD ou mesmo no padrão ISO SQL, e em combinação com os domínios SQL realmente se aproximam do conceito matemático. Duro é trabalhar num projeto que realmente implemente os tipos e aloque um programador (C ou D, por exemplo) para criar os tipos assim que possível, antes do resto da programação e implementação da base de dados.

O suporte, embora imperfeito, está aí. Mesmo que tipos SQL muitas vezes não sejam práticos, pelo menos seus ‘domínios’ ajudam. Agora não me venham com diagramas bonitos chamando-os de modelos, se pelo menos os domínios não estão definidos! Quase cem por cento de probabilidade de que, se já não houver grandes inconsistências, elas logo ocorram ao longo da vida da aplicação.

Arte e padrões abertos

Normalmente ſe aßocia a idéia de ſiſtemas abertos à Informática, principalmente na área de programação. Ultimamente, eſpecificamente a programas livres. Mas a verdade é mais complexa: exiſtem padrões abertos também na área de equipamentos, como as interfaces de computador PCI, USB, FireWire, SCSI, ATA… e mesmo fora da Informática. Na fotografia, os padrões abertos mais famoſos ſão a baioneta para câmeras reflex digitais Quatro Terços e a interface TTL para flash associada, os cartões de memória Compact Flaſh e sD, e os negativos digitais DNG e TIFF/EP.

Fica viſível que, em fotografia, apenas Compact Flaſh é um padrão amplamente difundido, até meſmo dominante; sD chega perto, enquanto o TIFF/EP e ſeu derivado DNG, aßim como o ſiſtema Quatro Terços, ſão francamente minoritários.

Ora, direis, ‘fotografia é arte, e o que importa é o fotógrafo, não o equipamento’. Mas primeiramente, ſou um Informata, um técnico, onde por maior ſeja o lado humaniſta (no ſentido amplo, não no de opoſição ao Criſtianiſmo) há também o lado perfeccioniſta; por eße lado, creio que os ſiſtemas abertos ajudam a conduzir à excelência técnica, que ſó pode ajudar a arte. Por outro lado, os padrões ajudam a diminuir as incertezas e complexidades do meio artíſtico, e aßim mais uma vez a arte é favorecida. Finalmente, o apriſionamento tecnológico derivado de padrões proprietários preßupõe ſegredos e dependência do indivíduo e das comunidades em relações a corporações, geralmente de grande porte, o que não parece coadunar com a expreßão artíſtica.

Alguém dirá ainda, ‘quanto romantiſmo’! Muito pelo contrário, o romantiſmo é o artiſta no centro de ſua obra, portanto profundamente egocêntrico. Padrões abertos favorecem a comunidade, ſão grandes equalizadores, e aßim tendem a diminuir o egocentriſmo e a diferenciação por ter ou não ter; ainda haveria diferenciação, mas por excelência, não por excluſividades.

Por fim, dirão que ‘padrões ſão paſteurizadores, impedem a inovação e a originalidade’. Mas eße é um engano fundamental ſobre a própria natureza de padrões abertos e seu opoſto, o apriſionamento tecnológico. Na verdade, o apriſionamento tecnológico impede a inovação e a originalidade, porque nele os padrões proprietários têm de permanecer ſecretos, impedindo que o conhecimento ſe eſpalhe e propicie avanços; e têm de mudar perifericamente quando o conhecimento ſe eſpalha para prevenir a compatibilidade ampla, preſervando a lucratividade do fornecedor, aßim roubando energia que poderia ter ſido dedicada a avanços reais.

Ao contrário, com ſiſtemas abertos os detalhes por aßim dizer mecânicos permanecem eſtáveis e não mudam ſem boa razão, e os ſiſtemas tendem a permanecer tão ſimples quanto poßível. Ora, tanto a eſtabilidade quanto a ſimplicidade favorecem as reais inovações, como bem ſabe qualquer engenheiro, ſeja formado ou prático (como eu); a inſtabilidade e a complexidade é que dificultam as inovações, juſtamente por fazer com que nos preocupemos com a mecânica, não com a utilidade.

Portanto, os fotógrafos, aßim como os informatas, ignoram os padrões abertos arriſcando a ſi meſmos, e prendem-ſe a ſiſtemas proprietários em prejuízo de ſua própria arte — para não dizer também de ſeus próprios bolſos.

Administração de Dados: os fundamentos

Gostaria de saber dum bom livro-texto de administração de dados. Faz falta, mesmo já com muitos anos de estrada, e mesmo tendo livros tão bons sobre modelos de dados quanto o do Date. Acontece que a ênfase dos livros costuma ser tecnológica; e mesmo um livro conceitual (e conceituado) como o do Date usa os conceitos como base para aplicações tecnológicas, não conseguindo — afinal, trata-se apenas de um livro-texto, não uma enciclopédia de gestão de dados — se preocupar com o projeto e manutenção dos modelos específicos de dados.

Aliás, também gostaria de ter mais contatos na área, a abrangência de meus interesses acaba prejudicando esse corpo-a-corpo tão necessário no Brasil.

Enfim, farei aqui algumas anotações, na esperança de que alguns colegas vejam e comentem.

Primeira anotação: qual o fundamento mais importante da administração de dados?

Resposta irrefutável, mas que virá como surpresa para os empiricistas: uma teoria de dados.

Muita gente começa até com um bom entendimento dos dados em si no sentido de que conhece a aplicação e os usos que fará de que dados. Mas acaba fracassando na organização desses dados, e criando sistemas que não escalam, que são xingados por usuários e mantenedores, que têm de ser refeitos várias vezes até se tornarem aceitáveis, por faltar uma teoria de dados. Daí também vêm tiros no pé como bases de dados multivaloradas (Pick, Caché), navigacionais (Clipper, BTrieve) e orientadas a objeto (Jasmim, de novo Caché). E coisas mais estranhas ainda, como o ReiserFS (não a implementação atual, mas o objetivo final).

Aqui não é o lugar para justificar o modelo relacional como única teoria de dados válida, nem para criticar os outros. Então meus (eventuais) leitores terão de fazer a tarefa de casa, que consiste em ler —­ de preferência, o Date supracitado — e pensar muito.

Fórum Quatro Terços

SSó para notificar os viſitantes que, além deſtas mal-traçadas, há um fórum Quatro Terços no DigiForum.

Padrões em fotografia

Algo que muito me preocupa, como informata (não procure a palavra nos dicionários, embora já seja usada até em projetos legislativos) partidário de ſiſtemas livres, ſão os padrões técnicos: baionetas de lente, cartões de memória, negativos digitais, baterias, flaſh.

Há muita confuſão no meio, aparentemente por falta de informação técnica — fotografia ainda é mais arte que técnica, e exiſte um preconceito intereßante e abſurdo de muitos artiſtas contra a técnica, aßim como muitos técnicos obcecam-ſe com a técnica em detrimento da arte — e especialmente porque muitos fotógrafos concentram-ſe apenas no conhecimento neceßário a operarem ſeu equipamento, portanto reſtringindo-ſe à tecnologia, padrões e nomenclatura de ſeu fornecedor.

O reſultado, é claro, é o apriſionamento tecnológico, levando a altos preços, funcionalidade limitada, confuſão na eſcolha de equipamentos, falta de liberdade na eſcolha de fornecedores.

Vou tentar anotar nos próximos dias algumas idéias ſobre padrões nas diverſas áreas delineadas acima. Vejamos ſe perſevero!

Wikipædia, até logo

Há anos já eu vinha editando a Wikipædia, principalmente em português e inglês mas também em francês e por vezes mesmo caſtelhano, galego e outras línguas menos votadas, ſe não me falha a memória.

Há algumas semanas virei o fio, quer dizer, cansei. Não pelos inúmeros problemas técnicos da Wikipædia, como ter ſido baſeada em MySQL — foße PoſtgreSQL, poderíamos ter um único uſuário cada um válido para todas as línguas do mundo, não teríamos tantas interrupções de ſerviço —, mas porque ſou um perfeccioniſta que ficava corrigindo pontuação, acentuação, tipografia, eſtilo &c. Continuam me irritando profundamente a mania brasileira de uſar traveßão (—) em vez de meia riſca (–) como separador, ou a deficiência generalizada de referências e ſeu uso inconſiſtente, e muitas outras coisas mais, mas chega, canſei. Deſde começos de fevereiro de dois mil e oito não edito mais. Não deſcarto voltar a fazê-lo, mas eſtou canſado de enxugar a praia, e tenho mais, muito mais o que fazer.

O que me faria voltar? Que as peßoas tentazem fazer o melhor, e aprendeßem com os erros e correções. Não me eſperem de volta tão cedo…

Fotografia

Vou paßar a eſcrever ſobre fotografia digital aqui. Estava eſcrevendo muito ſobre ißo em vários fora, alguns dos quais nem ſão indexados pelo Google, ſão comunidades fechadas. E prefiro as abertas. Vou continuar ajudando neles conforme o tempo permitir, mas a idéia é centralizar tudo aqui, e enfatizar participação em liſtas de diſcußão.

Já encontrei a liſta Zuikoholics Anonymous, que é ótima — muitas informações técnicas de altíßima qualidade, lá deſcobri muito ſobre as OM e ſobre flash, por exemplo — mas ainda é muito voltada a Olympus e a filme, eſpecialmente o ſiſtema OM, enquanto tenho grandes intereßes nos ſiſtemas Pen F e Quatro Terços; e embora a Pen F eſteja de fato no eſcopo da Zuikoholics, e as Olympus E ſejam do Quatro Terços e diſcutidas lá, ainda não achei uma liſta eſpecífica (que englobe as câmeras Quatro Terços da Panaſonic e da Leica, e lentes Sigma), nem tenho tempo de entrar noutra.