Convite Google Wave

Tenho doze convites do Google Wave para diſtribuir — o que é engraçado, porque até hoje não o uſei de fato.

Prioridade para comunidades de que participo, como PoſtgreSQL, Debian, Projeto GNU, Gutenberg, Sociedade Bíblica Croßwire, fotografia Quatro Terços e Olympus Zuiko, OpenRAW &c.

A loja mágica de brinquedos do ſenhor Saito

Hoje fomos conhecer a famoſa loja mágica de brinquedos do ſenhor Morio ‘Mário’ Saito. Não ſaímos incólumes: o Felipe ‘quebrou o cofrinho’ (metaforicamente) e levou dois conjuntos Lego Guerra nas Eſtrelas, levamos uma maletinha Playmobil e mais quatro caixas de Lego Creative Building para noßa igreja.

Embora haja lugares que dizem ter maior variedade de conjuntos Lego, os preços de Saito-ſan ſão incrivelmente mais baixos — diferenças de um terço ſão comuns, e, nas promoções, metade do preço das lojas brasileiras, loucura total! E lá tem catálogos de Lego deſde a década de 1.990, ſabem os brinquedos que já paßaram por lá antes, tem muito Playmobil, muita coiſa da Haſbro como os Mighty Mugs, & outros como Cocoricó & por aí vai.

O dono tem oitenta anos de idade, ſua eſpoſa ſetenta & ſete, & cuidam ſozinhos da loja há quarenta & ſete anos, aparentemente com o meſmo mobiliário de madeira dos anos ſeßenta, e com aquela concepção de comércio antiquada, mas tão prazeroſa: prateleiras abarrotadas, caixas empilhadas ſobre caixas, e Saito-ſan vai eſcavando as caixas para achar o que queremos…

O dia que tivermos dinheiro, e tendo em viſta a alta quantidade de informatas amantes de Lego, o povo do PoſtgreSQL podia fazer um elefante azul (noßo maſcote) de Lego… ſeria um ſuceßo nos eventos de ſiſtemas livres mundo afora!

Palestra no FISL marcada para sábado, dia vinte & sete

Foi marcada para das dezenove às vinte horas de sábado, dia vinte e sete deste mês de junho de AD 2009, minha palestra sobre ‘ferramentas de modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres’.

Na tradição da comunidade, o título da palestra é uma brincadeira com nosso mascote: O elefante ilustrado, procurando trazer a idéia de diagramação, e, portanto, modelagem de dados através do conceito de ‘ilustração’ — o que, de certa maneira, é um pouco enganoso porque meu foco é a modelagem, não a diagramação, uma vez que creio que os diagramas devem ser gerados automaticamente.

Agora é preparar-me…

Chamada de trabalhos para a III Conferência PostgreSQL Brasil (2009)

Está aberta a chamada de trabalhos para a III Conferência PostgreSQL Braſil (2009), a PgConBR 2009.

Se tens algum trabalho a apreſentar sobre PostgreSQL — pesquisa acadêmica, estudo de caso, novo desenvolvimento &c — faça-o o quanto antes! As PgConBRs são muito interessantes, mas principalmente para quem palestra: quem palestra é procurado pelas pessoas para conversar, e muita coisa interessante vem daí.

Fotos do I Dia PostgreSQL São Paulo (2009)

Depois de vários dias, doenças &c, começo a publicar as fotos tiradas por mim e por outros com câmera, luz estroboscópica e lentes curta e longa de minha esposa.

A maior parte foi obviamente tirada por mim, enquanto tentava desesperadamente não perder a atenção nas palestras em si. Juntando esse fato a minha conhecida inépcia, a falta de qualidade é responsabilidade do fotógrafo, não da câmera — como sempre.

Todas as fotos estão em formato JPEG, sendo que as primeiras tantas estão em qualidade média, por falha minha em reconfigurar a câmera após uma atualização de código embutido. Gostaria de fornecer à comunidade os arquivos originais ORF, mas não tenho um servidor onde os colocar.

A carga deve demorar ainda várias horas, portanto, pacientai-vos.

I Dia PostgreSQL São Paulo (2009)

Dia vinte e quatro de abril, sexta-feira próxima, será o I Dia PostgreSQL de São Paulo (2009), SP, Brasil. Vou apresentar as ferramentas de documentação automática de modelos e bases de dados PostgreSQL, espero que de maneira mais objetiva que o que consegui fazer na II Conferência Brasileira de PostgreSQL (2008), em Campinas.

Como sempre nos eventos dessa comunidade, haverá alguns ótimos palestrantes, como o Euler e o Guedes; desta vez teremos também o próprio organizador do evento, o Rodrigo Marins, possivelmente o Leonardo César, e um DBA da Caixa Econômica Federal. Parece que será bem interessante.

Pretendo abordar programação literária em NoWeb (en passant), mas principalmente Auto Doc, assim como um pouco do SQL Fairy e do Schema Spy.

O evento é gratuito, portanto a única desculpa para não ir é ser uma sexta-feira de trabalho. É uma semana curta por causa do feriado do Descobrimento do Brasil na terça-feira, dia vinte e um, o que pode ajudar — deve ser uma semana lenta de trabalho — ou atrapalhar — algumas pessoas podem ser atropeladas justamente pela falta de tempo na semana para liqüidar alguma tarefa urgente e inadiável. O lugar é um pouco remoto, a Lapa de Baixo, perto da Marginal do rio Tietê; mas, numa semana curta, esperamos que o trânsito não esteja ruim.

Balanço geral da II Conferência PostgreSQL Brasil (2008)

Depois de vários meses, consigo um pouco de tranqüilidade para fazer um balanço geral da II PgConBR (2.008).

Em primeiro lugar, devo dizer que fiquei impressionado. A I PgConBR (2.007) deixara altas expectativas: segundo o David Fetter, fora uma primeira conferência melhor do que muitas segundas ou terceiras conferências ao redor do mundo; ele viera com altas expectativas, que foram superadas. E, aparentemente, essa sua avaliação não foi isolada. Dado que imaginava que podia ter sido sorte de iniciante, talvez fruto de um grande entusiasmo, mas passageiro; e que a comunidade tomou a temerária iniciativa de organizar tudo sem o apoio duma empresa especializada, eu temia que pudesse haver problemas graves.

Certo, houve problemas. Mas os ingentes esforços da comunidade — e creio que aqui não cometo injustiça alguma em singularizar os esforços do Fábio Telles Rodrigues, que literalmente machucado e assoberbado de preocupações peitou a organização e supriu vários buracos, além de palestrar — fizeram que esta II PgConBr (2008) fosse ainda melhor que a I, de 2007.

Infelizmente não aproveitei tanto. Ao contrário da última vez, assumi de vez o papel de fotógrafo do evento, e descobri como é que fotografia pode ser, além de diversão e arte, artesanato e profissão: dá muito trabalho. Talvez porque não saiba fotografar direito… mas, enfim, o caso é que fotografar me tomou muito tempo de conversas, contatos e palestras. Em 2.007, fiquei quieto sentado vendo as palestras e fotografando de lado, até por não ter uma lente longa nem um tripé; até passei vergonha não sabendo operar o tripé que o Telles me emprestou enquanto seu filme não chegava… já desta vez, estava com tripé, lente longa, disparador remoto por cabo, flash, enfim, todo o aparato… e nenhuma folga. Espero que o resultado tenha sido dalguma valia. Aliás, quando palestrei, o Telles ainda fotografou, e mesmo machucado o fez muito mais dinamicamente que eu — realmente ¡é uma força da natureza!

Enfim, ¿como foi a conferência? Do que peguei, e do que conversei com outros que aproveitaram mais, foi bem melhor ainda que a primeira. Desta vez não houve nenhuma palestra fora de lugar, nenhum constrangimento fosse técnico ou da comunidade. A impressão foi de que houve menos pessoas, provavelmente porque Campinas é mais fora de mão que São Paulo, embora seja muito mais confortável e barata para quem vem de fora; mas o nível técnico, me parece, melhorou. Os temas das palestras me deixaram de água na boca: replicação, georeferenciamento, escalabilidade, recursividade, monitoramento… sem contar as minhas próprias sobre comunidade (com o Euler) e modelagem. E nenhuma decepcionou. Houve vários segmentos da comunidade representados: ativistas, usuários empresariais & governamentais, acadêmicos; houve palestras conceituais, sobre tecnologia & aplicações; gente de várias partes do país, e mesmo do Exterior.

Quanto às minhas palestras — ou minha meia-palestra e meu tutorial —, devo dizer que fiquei lisonjeado, em primeiro lugar por dividir uma palestra com o Euler, em segundo por ter sido recomendado para isso pelo Fetter, e finalmente por me terem confiado o único tutorial, de duas horas. Espero não ter decepcionado; no Brasil, é bem mais fácil saber dos elogios que das críticas. Fiquei um pouco preocupado porque praticamente metade do tutorial foi consumido por dúvidas básicas, conceituais, da audiência; mas, por outro lado, essa interação com os participantes é, na minha opinião, o melhor que há. Fica uma preocupação, que talvez possa ser sanada em conferências futuras dividindo certos temas em um nível básico e, outro, avançado; não sei se seria adequado, mas talvez seja uma maneira de evitar que alguns ‘bóiem’ e outros fiquem aborrecidos. Outro problema é que essas perguntas da platéia puxaram a primeira hora do tutorial para quase um ‘repeteco’ da palestra de 2.007; creio que, querendo palestrar em 2.009, devo conseguir outro tema. O que não é fácil para quem não pode se dedicar completamente ao PostgreSQL.

Em termos mais gerais para 2.009, fica a necessidade de obtermos mais voluntários para a organização do evento, ou uma empresa que nos sirva bem na organização; de obtermos cooperação mais efetiva do grupo global de desenvolvedores; e de mais propostas de palestras, para variarmos mais tanto temas quanto palestrantes.

Ah, e ano que vem, ¡quero levar a família!

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.

Conferência PostgreSQL Brasil 2007

Dois dias de conferência. Meſmo ſem ter participado da organização, fotografei (166 poses), ajudei a atender peßoas, fiquei até às 21h, traduzi… além de minha paleſtra.

Fazia tempo que não via tanta gente inteligente junta, e parece que minha paleſtra não foi um fiaſco completo. Eſpero que tenha ajudado.

Mais tarde publico algumas fotos — a maior parte ſe perdeu porque não sabia regular a ſenſibilidade do sensor, e lidei com um palco sombrio e a projeção das tranſparências ao fundo. Só no final deſcobri como ajuſtar o ASA para [48]00 e ſer feliz.

PostgreSQL Conference Brasil 2007

Vou falar no PGCon 2007, patrocinado e organizado pela comunidade PoſtgreSQL brasileira e pela Tempo Real, sobre Adminiſtração e Modelagem de Dados em PoſtgreSQL.

Inſcrevam-ſe e acompanhem aqui, pretendo publicar o conteúdo da palestra antes do evento para que todos a aproveitem melhor e quem ſabe naſça algum debate intereßante.

E o MS Windows afundou o Onda…

Hiſtória antiga:

Em 1 999–2 000 morei em Londrina, PR. O provedor mais popular lá era o Onda, na época ligado à Telepar e hoje à RPC.

Acabara de comprar meu ſaudoſo Apple Power Macintoſh G3 bege de meſa, com um (caríßimo, na época) modem Diamond. Funcionava que era uma beleza: conexões inſtantâneas, duráveis, eſtáveis, próximas do limite teórico da banda.

Pouco tempo antes de me mudar, tudo mudou. De um dia para outro, preciſava duas a quatro tentativas para obter uma conexão de menos da metade da banda com que eſtava acoſtumado, e que durava de cinco a quinze minutos antes de cair. Ligava para o Onda, e nada de ſolução. Fui tranſferido de volta para São Paulo, e deſencanei.

Na época me familiarizava ainda com a plataforma Macintoſh (incluſive o não tão ſaudoſo Mac OS 9), e portanto participava de liſtas de diſcußão eſpecíficas — a mais importante ſendo a ſaudoſa MacBBS. E como ſói acontecer, ſempre há quem chegue neßas liſtas para falar mal da plataforma e dos produtos. Geralmente fãs de carteirinha da MicroSoft, que, como a empreſa, têm dificuldade em aceitar tanto a diverſidade tecnológica quanto os padrões abertos e ſua própria inferioridade tecnológica; ou defenſores dalguma diſtribuição GNU/Linux ou BSD, dalguma verſão de Mac…

Enfim, apareceu um ignaro na MacBBS (ſe não me falha a memória) dizendo que Mac OS não preſtava (o que talvez foße verdade na verſão 9), que bom meſmo era MS Ƿindoƿs… quando vieram as críticas óbvias de inſegurança, eſtabilidade &c ele ‘argumentou' que elas ſe aplicavam ſomente ao NT, que de fato era ruim, mas que o 2000 era muito melhor, não tinha nenhum problema. Tentamos moſtrar‐lhe que era mera ignorância ſua de plataformas melhores; que ele achava o 2000 bom por não conhecer ſiſtemas POSIX ou de grande porte.

O peixe morre pela boca… ſem argumentos, noßo amigo quis dar exemplos. E diße que tinha um cliente no Paraná, um provedor de aceßo, que uſava Sun Solaris mas, devido ao alto cuſto de ſyſadmins e equipamento, migrara tudo para MS Ƿindoƿs 2000. ¡Bingo! Foi ſó perguntar quando ißo ocorrera, e confirmar que tratava‐ſe do Onda.

Deſneceßário dizer que todos meus conhecidos, contraparentes e amigos migraram do Onda para o outro grande provedor de Londrina, o Sercomtel. O barato ſaiu caro para o Onda.

Trens impoßíveis

A ſituação de tranſporte público em São Paulo eſtá vergonhoſa. Ainda prefiro o PSDB às alternativas, ainda mais ſabendo que o funcionaliſmo público é lento e a ſituação já melhorou muito em relação aos tempos em que os trens eram federais. Mas a linha Jurubatuba—Oſaſco eſtá ſuperlotada, tendo ganho a integração Jurubatuba–Autódromo sem ganhar mais vagões. Os trens têm quebrado e atraſado, e o reſultado ſão brigas entre os paßageiros para entrar e ſair dos vagões, gente paßando mal, e eſtes circulando de portas abertas.

Não adianta limitar as catracas de entrada ſe os trens atraſam; fizeram ißo hoje em Jurubatuba e piorou, porque um trem ſaiu relativamente vazio enquanto a fila eſtava grande, e o ſeguinte, atraſado, ſuperlotou.

Pura incompetência eſtatal. ¡Acorda, Serra! Nem que tenham de deſlocar vagões de outras linhas, colocar compoſições velhas de volta em circulação ou fazer licitações emergenciais. Não dá para eſperar a programação atual da CPTM, ¡que prevê melhorias apenas para 2009!

Aquecimento global… ¡ſe o pauliſtano é praticamente obrigado a andar de carro! Quem ſabe ¿os EUA poderiam ſe redimir da rejeição ao protocolo de Kyoto financiando noßo metrô? Se bem que a prioridade deve ſer a energia de carvão chinês…

Só ſaindo de São Paulo dos Campos de Piratininga.