PgBr MMXI

Mais um ano, e volta a Conferência Braſileira de PoſtgreSQL, agora chamada PgBr, e não mais PgConBr. Além de economizar três caracteres (¡dã!), o novo nome evita coliſão com a Conferência global de PoſtgreSQL, realizada todo ano em Otava, Ontário, Canadá, no primeiro ſemeſtre.

Ainda não ſei ſe poderei ir. Eſte ano, apeſar de ſer realizada na capital de São Paulo dos Campos de Piratininga, SP, a conferência realizar‐ſe‐á durante a ſemana de trabalho, como ſe fôra planejada para uma cidade de funcionários públicos, como Braſília, DF. Eu meſmo, funcionário público, ſaio do eſperado e me acho aßoberbado de trabalho, o que me dificulta a ida. Ißo ainda poderia ſer negociado; o que realmente me atrapalha é juſtificar ir ſem paleſtrar, e tenho já mais de um ano afaſtado da área de dados, o que me gera falta de aßunto.

Não que não haja aßuntos intereßantes. Mas após duas experiências ſofridas de paleſtrar ſem preparação adequada (PgBr MMIX, ſobre expreßões comuns de tabelas e PgCon MMX, ſobre modelagem literária), além de meu preſtígio ter baixado baſtante na comunidade, reluto em achar que conſeguirei preparar e apreſentar algo que valha a pena, ainda mais que ainda eſtou ſem meu Debian GNU/Linux em caſa, ainda com os problemas do EFI da Apple — no trabalho, onde ainda é Bios, eſtou no conforto do Debian com GNU Emacs — ſaudades do Open Firmware…

Idéias até tenho — por exemplo, ‘O Paquiderme univerſal’, ſobre como o PoſtgreSQL, ao rodar em todo tipo de plataforma, eſcalando do portátil ao grande porte, com todo tipo de linguagem e extenſão, atende a praticamente todas as demandas poßíveis e imagináveis de computação e geſtão de dados deſte lado do paraíſo relacional; ou ‘A Evolução paquidérmica: para o alto, e ¡avante!’, repaßando a liſta de afazeres do PoſtgreSQL, moſtrando como vamos melhorar, talvez colocando em perſpectiva tanto das noßas verſões mais recentes quanto do eſtado e melhorias mais recentes dos principais concorrentes; ou ‘O Elefante: ſua verdadeira forma, e diſfarces’, moſtrando as facilidades de migração de código, com ênfaſe dividida entre facilidades de compatibilidade com concorrentes e aplicação de padrões que facilitam a migração de e para o PoſtgreSQL. A queſtão é que, no momento, creio que há muito mais gente que poßa fazê-lo muito melhor do que eu.

Vejamos. No momento, não eſtou paßando bem. Talvez amanhã reſolva apreſentar algo, o prazo já ſe encerrará. Mas eu bem preferia que outros apreſentaßem eßes temas, e outros melhores ainda.

Se eu não puder ir, peço que alguém levante a diſcußão: regiſtremos os domínios Poſtgres, PoſtgreSQL e Postgres.org.br?

Como vê o mercado brasileiro, como DBA de experiência internacional. Empresas que oferecem/compram serviços; qualidade dos centros de treinamento…

Dißeste tudo, é mercado, não é profißão. O mercado livre preßupõe conhecimento da parte de quem compra, o que está longe de ser o caso — haja vista o NoSQL, que é a última versão da recauchutagem quase que anual dos enganos pré-relacionais, e que no Brasil faz suceßo mesmo entre pessoas que deveriam saber mais. As que oferecem serviços também, são mais ligadas a um produto que ao conhecimento neceßário a prestar um serviço de qualidade mínima; os poucos bons profißionais são, geralmente, preteridos em favor dos que fazem pouca marola. Agora, treinamento… a palavra já diz tudo. Peßoas são formadas, educadas; animais é que são treinados. Se alguém é treinado, é atleta ou operário, não profißional liberal ou técnico.

Procura-se

Procura‐ſe um programador que conheça Borland Delphi verſão 5, MS SQL Server e Oracle, para conduzir a migração dos sistemas de uma distribuidora multinacional estadunidense de equipamentos de Informática. Salário pode ser em torno de cinco mil reais, contratação efetiva pelas normas da Consolidação das leis do trabalho do Brasil.

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!

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.

Códigos de língua e território para o galego

Exiſte muita confuſão e deſinformação ſobre a codificação das variantes do galego na Informática. A única regra reconhecida é gl para língua e gl_ES para a variante oficial da Espanha; e há quem proponha pt_GL, gl_GZ ou pt_GZ para a variante portuguesa.

O problema é que a segunda parte do código de dialeto não designa a variante em si, mas o território onde é falada; e não existem os territórios GL ou GZ. Exiſte, sim, gl_ES e gl_PT; mas meſmo ißo é controverſo, viſto que galego e português ſão dois dialetos da meſma língua, em pé de igualdade com o português do Braſil. Talvez a ſolução mais correta foße pt_ES para o galego como eſcrito na Galícia eſpanhola, mas ißo deixaria o galego como eſcrito em Portugal ſem um código fácil, exigindo algo como pt_PT@gl.

Ißo torna o galaico‐português uma língua sui generis, com quatro codificações para três principais dialetos diferentes: gl_ES, gl_PT, pt_BR, pt_PT.

Administração de dados à la Unix

Originalmente publicada em pgbr-geral@postgresql.org., tranſcrita com adaptações.

Eſta é uma idéia bem incipiente, goſtaria de diſcuti-la aqui. Alguns podem achar que é fora do tópico; neße caſo, aceito ſugeſtões de onde debatê-la.

Andei inveſtigando ferramentas de modelagem, e acabei ficando fruſtrado. Pelo que olhei e até teſtei, as ferramentas ‘profißionais’ eſtão por volta de US$4K, chegando facilmente a US$8K ſe a gente quiſer ‘luxos’ (¡não!) como verſionamento. As ferramentas livres são inexiſtentes, incompletas e (ou) imaturas; eſcolha pelo menos dois deßes adjetivos. Além de falta de ſuporte a ſiſtemas livres e vai por aí afora.

Mas agora o que tem me irritado é o próprio fluxo de trabalho deßas ferramentas. Não são nada práticas, forçando tudo a paßar por diagramas. Eu preferiria fazer tudo em texto, e ter diagramas como ſaídas do proceßo, não entradas. E tive a idéia maluca de eſcrever uma propoſta a reſpeito, mas queria ſaber ſe alguém já viu algo aßim, ou ſe é abſurdo.

Hoje, numa ferramenta de modelagem de dados, o proceßo começa com a definição de um dicionário de dados. Uſando eße dicionário de dados, cria-ſe um DER. Eße diagrama é então traduzido para o ſabor SQL do SGBD relevante.

O problema óbvio é que diagramas são menos expreßivos e mais chatos de fazer que um programa SQL ou (idealmente) relacional. Então por que não eſcrever ISO SQL, Tutorial D ou meſmo D4 (deſculpem os idealiſtas, também ſou idealiſta mas…)?

Não ſeria fácil, mas creio que ſeria poßível, com planejamento e paciência, criar um ſiſtema muito mais produtivo e flexível uſando a filoſofia Unix: cada tarefa deve ſer bem feita por um componente. As interfaces são bem definidas, e cada ferramenta pode ſer ſubſtituída ou melhorada independentemente.

No caſo, começar‐ſe‐ia com uma gramática (por exemplo) Tutorial D ou D4. Talvez uſar um derivado de Scheme ou ML para obter mais concisão e poder programático, creio que já fizeram um SchemeQL ou coiſa aßim. Mas talvez um ſubconjunto do ISO SQL:2003, deixando de lado tudo o que for físico como ponteiros, índices &c; embora eu não creia que o SQL seja ſuficientemente expreßivo de todas as ſituações com que um SGBD deva lidar — eſpecificamente, todos os tipos de reſtrições de integridade.

Neßa linguagem, definiríamos domínios, entidades, regras de negócio &c, tudo o que tem a ver com o modelo lógico (conceitual). O básico é ter a linguagem definida; a partir daí criam-ſe validadores e compiladores. O reſultado dos compiladores ſeria um programeta de definição de dados para o(s) SGBD(s) alvo de eſcolha, por exemplo noßo caro Dumbo.

Deßa meſma definição, uſaríamos um AutoDoc ou SQL Fairy (cuidado, a página inicial dele cega!) para gerarmos todos os diagramas que quiséßemos: DER, IDEF1X &c para benefício dos uſuários. Até aí é trabalho do Adminiſtrador (ou Arquiteto) de Dados. A partir da linguagem, podemos criar todo tipo de auxílios, como IDEs (um modo Emacs, por exemplo).

Até aí foi conceitualmente tranqüilo. O que me preocupa, além da poßibilidade deßa idéia ſer muito pior do que me parece, é o ſegundo paßo: findo o trabalho do AD, começa o do Adminiſtrador de Baſes de Dados, o ſempre popular ABD (ou DBA, para os anglófilos). Ele teria de pegar eßa definição da Baſe de Dados (BD) e acreſcentar tudo o que é físico: índices, parâmetros de armazenamento &c. Não me parece eſpecialmente difícil; ele poderia fazê-lo ſeja numa extensão da noßa linguagem conceitual, ſeja na linguagem do ſiſtema alvo. Ou meſmo através de remendos a aplicar ao modelo conceitual, como ſe faz em programação tradicional meſmo.

Tenho certeza de que há muitos percalços nos quais não penſei, mas queria ſaber de vocês o que acham.

Para concluir, creio que um ſiſtema aßim poderia ſer o começo de coiſas muito melhores. Por exemplo, o único quaſe‐SGBDR hoje em produção é o Alphora Dataphor, que tem algo ſemelhante não para modelagem de dados mas para o ſiſtema como um todo: a gente eſcreve D4 (que é uma D válida) e os comandos são executados num SGBD SQL (infelizmente ainda não ſuporta o Jumbo). É um ſiſtema proprietário e complexo, e ainda por cima em MS .Net, mas é uma boa idéia. Não conſigo imaginar hoje um projeto dum clone ou equivalente livre dele, mas eße noßo ſiſtema eventualmente poderia ſer um primeiro paßo.

Deu para entender?

Críticas aos EUA

Outra do amigo Bachega:

American Jesus

Bad Religion

I don’t need to be a global citizen
’Cuz I’m blessed by nationality
I’m a member of a growing populace
We enforced our popularity
There are things thet seem to pull us under and
And there are things that drag us down
But there’s a power and vital presence
That’s looking all around
We’ve got the American Jesus (2×)
See him on the Interstate

I feel sorry for the Earth’s population
’Cuz so few live in the USA
At least the foreigners can copy our morality
They can visit but they cannot stay
Only precious few can garner the prosperity
And it makes us walk with confidence
We’ve got a place to go when we die
And the architect resides right here
We’ve got the American Jesus
Bolstering national plan
We’ve got the American Jesus
Overwhelming millions everyday

He’s the farmer barren fields
The force the army wields
The expressions in the faces
Of the starving millions
The power of the man
The fuel that drives the clan
The motive and the conscience
Of the murderer
He’s the preacher on TV
The false sincerity
The form letter that written by
The big computers
He’s the nuclear bombs
And the kids with no moms
And I’m fearful that
He’s inside me

We’ve got the American Jesus
See him on the interstate
We’ve got the American Jesus
Exercising his authority
We’ve got the American Jesus
See him on the interstate
We’ve got the American Jesus
Overwhelming millions everyday, Yeah!

One nation under God (×8)

As críticas ſão válidas para muitos eſtadunidenſes, e injuſtas para muitos outros.

Eu prefiro pregar o certo e criticar os de dentro, antes que os de fora. Eſtá muito fácil criticar os EUA em tempos de Buſh, e muito fácil perder a perſpectiva não vendo os erros dos outros — incluſive os noßos — que incluſive ajudam a propiciar os deles.

E olha que o pragmatiſmo eſtadunidenſe eſtá deſtruindo minha profißão, a Adminiſtração de Dados. Não ſem a colaboração da omißão européia, da cupidez oriental, e da ignorância braſileira — aliás, terceiromundiſta.

Migração de MySQL para PoſtgreSQL

Eſtive muito fruſtrado com um detalhe do meu trabalho, o MySQL. O caminho ideal ſeria migrar para PoſtgreSQL.

Cheguei a teſtar vários programetas Perl, Ruby, Python para fazer a migração. Todos funcionam, embora ſem conſertar os problemas de tipos de dados típicos duma baſe MySQL; alguns ſão baſtante ineficientes. E cheguei a ter ſuceßo.

Mas demorei demais, e o patrão arranjou outras prioridades para os deſenvolvedores que iam ajuſtar a aplicação. Projeto abortado, e eu, fruſtrado.

Agora, no CONISLI 2006, encontrei o David FETTER, autor do DBI Link, que nada mais é que um mecaniſmo de federação para PoſtgreSQL: permite gerir diverſas fontes de dados tabulares como tabelas do PoſtgreSQL.

A idéia agora é implantar, junto de cada baſe de dados MySQL, uma baſe de dados PoſtgreSQL, que ſerá a definitiva e enxerga todos os dados MySQL. Funcionando os aplicativos com a baſe PoſtgreSQL, pode-ſe migrar uma tabela de cada vez, ou as tabelas relativas a um aplicativo de cada vez.

De volta à Rede, configurado

Finalmente, após ‘longo e tenebroſo inverno’, eſtou de volta à Rede, configurado e eſtável.

Tentando corrigir um livro

Eſtou tentando já há meſes corrigir o (em outros aſpectos excelente) Oracle Essentials, 3ª edição, da O’Reilly:

Dr. Edgar F Codd first described the relational database concept in an IBM Research Report named Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks. His 1970 paper was published in Communications of the ACM, and was called A Relational Model of Data for Large Shared Data Banks. The inexistent System R4 Relational name seems to be a mishearing of IBM’s System R subproject of the Future System project, which was thus named in 1974: probably an author overheard someone mentioning it as something like the IBM System R, (where R stands) for Relational. Also, Oracle was not the first relational database. It was the first SQL DBMS: it is neither a database, but a DBMS, nor relational, but based on SQL, which is not relational. Actually the first relational DBMS seems to have been the original University Ingres, before it became the current PostgreSQL.

O texto original, errôneo, que tem ſido amplamente copiado e divulgado na Teia (ſegundo o Google), aparentemente porque eſtá diſponível como uma amoſtra copiável em Adobe PDF:

The Evolution of the Relational Database

The relational database concept was described first by Dr. Edgar F. Codd in an IBM research publication entitled “System R4 Relational” appearing in 1970. Initially, it was unclear whether any system based on this concept could achieve commercial success. Nevertheless, Relational Software, Incorporated (RSI) began in 1977 and released Oracle V.2 as the world’s first relational database within a couple of years. By 1985, Oracle could claim more than 1,000 relational database customer sites. By comparison, IBM would not embrace relational technology in a commercial product until the Query Management Facility in 1983.

Hoje deve ſer a terceira vez que envio o comentário acima à editora, através de ſua página de comentários. E até agora, ſe recuſaram a publicar, ſeja o meu comentário ſeja uma verſão ſanitizada dele. Se alguém tiver uma maneira mais política de dizer ißo, ou meſmo parte dißo, por favor, comente… e aguarde a publicação de seus comentários na página de errata ou, pelo menos, na de relatos ainda não confirmados. O meu comentário tem ſido ignorado.

Atualização: Há outros erros no mesmo parágrafo, também enviados à O’Reilly:

The first IBM commercial SQL product was actually 1982’s SQL/DS for DOS/VSE, announced in 1981. 1983 saw also the launch of DB2.

E:

Actually the first IBM relational product was BS12.

Jabber e GTalk

Uso o Jabber, que é cada vez mais útil dada sua adoção pelo Google Talk — mas ainda não consegui um cliente Web que funcione no MS IE 6 sobre MS WXP através do Squid. O que chega mais perto é o JWChat, mas não chega a me permitir dizer que estou em linha, adicionar amigos ou configurar.