22 outubro 2010

Vida que Vivemos


Estou para mudar de cidade, mudar de vida. Estou muito feliz. Por enquanto é o que posso dizer. Que Deus me guie.

16 setembro 2010

Da Série: Efeitos Colaterais da Vida

De manhã após uma xícara de café forte: "Sinto que posso mudar o mundo".

À tarde: "Acho que vou deixar para amanhã".

À noite: "Preciso dormir".

27 julho 2010

O Patriotismo Não Proporciona Riqueza Às Nações

É uma tese que estou desenvolvendo.

Numa percepção empírica, tenho que em todos os povos reside -- em maior ou menor grau -- um sentimento nacionalista, sem exceção.

Todavia, o fato é que não é o amor à pátria que leva o Estado ao desenvolvimento. Estamos certos de que o apego a uma causa levará necessariamente a algum efeito, para melhor ou pior, mas a bandeira ufanista não roda as engrenagens econômicas, as quais dependem em certas ocasiões de variáveis macro-econômicas, ondas ocasionais, ou se concretizam no sucesso de uma leva de empreendedores que se lançam cegamente em aventuras empresariais.

Ainda não procurarei saber se algum autor já se debruçou sobre o tema, mas vou investigar.

29 maio 2010

Conversa Interna

Descortinando uma biblioteca antiga
-- Hmm... Pra que será que serve essa linha?... Vou apagar esse trecho que não serve pra nada...
-- Você tem certeza que vai funcionar se você apagar isso? Talvez seja melhor deixar do jeito que está. Ele sempre funcionou assim.
-- Mas pra que foi mesmo que vim olhar esse modulo?
-- Ah sim, era porque eu queria implementar um nova funcionalidade. Mas talvez eu devesse achar um meio mais fácil de fazer isso sem ter que mexer aqui...

22 abril 2010

La avanzada brasileña sobre empresas argentinas no se detiene, El Clarín


El mayor banco de Brasil compra el Patagonia por US$ 480 millones

Ya prevén lanzar una oferta por el 100%. La ANSeS tiene casi 15% de la institución local.




La avanzada brasileña sobre empresas argentinas no se detiene. El Banco Do Brasil, el grupo financiero más grande de América Latina, anunció ayer que tomará el control del Patagonia, con la compra de 51% del paquete accionario de la firma local por un monto que orilla los 480 millones de dólares. [Leia a íntegra]

12 abril 2010

Google Python Style Guide

Rodando por aí descobri que tem um google-styleguide, e que ao lado de C++ e Objective C, há o Google Python Style Guide.

De maneira geral esse guia recomenda o que já é recomendado em Python com alguns acréscimos com os quais concordo plenamente, incluindo a convenção sobre nomes:


Naming


module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_VAR_NAME, instance_var_name, function_parameter_name, local_var_name.
link
Names to Avoid
  • single character names except for counters or iterators
  • dashes (-) in any package/module name
  • __double_leading_and_trailing_underscore__ names (reserved by Python)

Naming Convention
  • "Internal" means internal to a module or protected or private within a class.
  • Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
  • Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
  • Use CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it's confusing when the module happens to be named after a class. ("wait -- did I writeimport StringIO or from StringIO import StringIO?")
***

A PEP 8, guia de estilo Python, desencoraja o uso de sublinhados em nomes de módulos, mas contrariando a PEP eu vinha usando "modulo_nome" mesmo assim, e agora vejo que não estou só.

Entretanto, não uso variáveis privadas (que iniciam com duplo sublinhado), somente internas (que começam por um único sublinhado), nunca vi necessidade de variáveis privadas em Python, mas acho que dependendo do grau de polimorfismo ou mágica talvez seja necessário usá-las.

07 abril 2010

Linux É "Linux"!

Há muita confusão desnecessária com o nome Linux. Criou-se uma pseudo-correção descabeçada que fez surgirem os tais: "Unix-like", "sistemas Unix", "Compatível com Unix", "Unix-family", "Posix" e "GNU/Linux".

Vamos desatar esses nós.

UNIX Bla-Bla-Bla
-----------------------
Linux foi desenvolvido baseado em Unix (pelo Minix) e com intuito de ser compatível com ele, o que não significará que ele é subproduto do Unix.

Você por acaso já ouviu alguém falar "QDOS-like" em vez de Windows, ou "Unix-like" em vez "Mac OS"?

Pois então, também não faz sentido chamar o filho do mesmo nome do pai. O Filho já cresceu, se tornou maior que o pai, de modo que a família a qual pertence Linux não é o mesmo que o nome próprio "Linux" -- o qual justamente o distingue dos demais sistemas derivados do Unix.

Esse uso só seria aceitável em casos bem restritos de aplicativos desenvolvidos para toda a família Unix, e mesmo assim seria melhor designar primeiro o sistema mais conhecido: "Desenvolvido para Linux (ou Unix-like)" ou ainda "Linux-like".

POSIX
---------
Esse aqui é ainda escabroso. Em Python se você invocar "os.name" em cima de Linux ele vai retornar "posix", mas POSIX é o nome de um conjunto de normas de interface destinada à família Unix, e jamais sinônimo de Linux, ou pior, o "nome" do sistema operacional.

GNU/LINUX
-------------------
Quem inventou esse nome foi Stallman na tentativa de se creditar ao projeto GNU o desenvolvimento de grande parte dos aplicativos de gerenciamento que rodam em cima do kernel (núcleo) de Linux.

Bem, esse nome é até aceitável. Ele envolve uma discussão abstrata e pouca precisa sobre terminologias.

Estamos certos de que o projeto GNU é importante, mas nos parece que ao criar mais um nome confuso para Linux acaba-se por atrapalhar a própria propagação dos aplicativos GNU, vez que atrapalham o fomento à adoção de Linux.

11 março 2010

(Orientação_a_objetos).crítica_sobre( )

O que chamamos de objetos não podem ser considerados objetos na concepção humana, mas apenas na concepção da própria disciplina de programação.

Aliás, lembro que tive certa dificuldade no princípio de compreender o que era a tal iluminada OO porque se nos apresentavam uma explicação segundo a qual a OO se aproximava da concepção humana a respeito de objetos -- premissa que hoje considero parcialmente falsa.

Digamos que eu tivesse ganhado um caderno, mas não soubesse o que é. Então pegaria aquele caderno, e analisando ele como objeto, diria à pessoa que me presenteou: "legal, mas o que eu faço com isso?"

Intuitivamente procuramos alguma coisa para fazer com um caderno, ou, procuramos saber para que ele serve. Todavia, assim concebendo não se pode afirmar que os números seriam objetos no sentido da OO, vez que eles não fazem nada, e sim quem o faria seria o engenheiro que usa de procedimentos matemáticos para com os números.

Note a discrepância. A classe é "Matemática", o procedimento é "soma", e os instrumentos: os números. Quando muito poderíamos asseverar que os números são o objeto da classe matemática, o que nunca implicaria entender que invocaríamos a função "soma" para um número, ao contrário, o parâmetro número é que é passado para o procedimento "soma", a lógica é inversa à da OO.

O único fato da OO que se assemelha ao pensamento humano é a existência de atributos ligados a um objeto. Nesse aspecto, um caderno pode ser verde, pequeno, etc.

Sucede que atributos não podem ser funções de um caderno, pois ninguém que toma o caderno nas mãos requer dele que proceda à sua função "escrever", senão usando o procedimento "escrever" passa-lhe um "caderno".

De modo que não é o paradigma OO que é intuitivo, mas sim o procedural, razão até pela qual um iniciante costuma ter mais facilidade em lidar com funções que com classes e métodos.

A grande idéia da OO é atar a um objeto tudo o que se pode obter dele: desde seus atributos até os procedimentos aplicáveis a ele. É como se um objeto já soubesse o que ele possui, o que ele pode fazer e quais as suas funções. Observe-se, contudo, que saber o que é, o que tem e o que pode fazer é muito mais a característica de uma ente autociente que a de um objeto.

Com efeito, seria mais coerente descrever a OO como a orientação a "entes autocientes", já que estão cientes de seus atributos e de suas funções.

Não obstante, o paradigma OO representou um grande avanço na programação, porque realizou que dentro de um universo bastante limitado de possibilidades é mais fácil atrelar atributos e métodos a um máquina autociente do que tentar atrelar objetos a centenas de rotinas não cientes.

Assim, nos parece mais desejável que, p.ex., em Python a função "max( )" fosse um método, pois embora intuitivamente se use primeiro o procedimento max( ) e depois o objeto "list", seria mais simples verificar que um objeto "list" detém a função "max( )", mesmo que "max( )" fosse o mesmo nome para funções semelhantes ligadas a "str" e a "tuple".

De outra lado, não nos parece razoável exigir exclusivamente o uso do paradigma OO. Ele deve ser preponderante, no entanto haverá ocasiões em que um conjunto de funções será mais funcional (por assim dizer), daí uma ampla vantagem de Python que permite o multi-paradigma, mas isso já é outra conversa.

05 março 2010

MongoDB é Magnífico!

Pretendia esperar esperar mais uns dias para postar com mais profundidade, mas estou tão deslumbrado com Mongo que vou postar com apenas dois dias de estudo.

Veja-se só as possibilidades, em Mongo podemos:

  • Armazenar diversos objetos/tipos nativos de Python como: int, float, datetime.datetime, list, unicode.
  • Uma vez que ele é "orientado a documentos", ficamos livres de necessariamente criar schemas, mas eles podem ser criados.
  • Pode-se armazenar documentos sem termos que definir tamanho máximo, de modo que facilmente é possível criar registros que contenham arquivos inteiros.
    • A abordagem é tão diferente que nem é necessário criar uma "tabela", basta denominar as chaves e depois determinar valores para elas.
  • Podemos acrescentar "campos" sem sofrer para definir novas regras.
  • O mais extraordinário sobre as regras de consistência / relacionamento / estruturação:
    • Como SQL, podemos criar "referências".
    • Como OO, podemos criar registros HERDADOS com simplicidade. Você pode acreditar nisso????
    • Como OO "Plus", podemos criar documentos EMBEDEDD com facilidade. Incrível!


Quando vi que era possível criar classes-documentos-filhos e também classes-documentos-embededd com consistência e naturalidade fiquei impressionado. Isso vai facilitar nossas vidas. Basta olhar aqui para ver.

Aliás, com tanto tempo no modelo SQL eu tive certa dificuldade no primeiro momento de imaginar outra modelagem de dados.

A propósito, estou usando um ORM para Mongo chamado "mongoengine" que roda em cima do pymongo.

INSTALANDO MONGOENGINE

$ sudo easy_intall mongoengine

Grato ao La Batalema sobre os posts de MongoDB.

04 março 2010

Como Instalar MongoDB no Ubuntu (para iniciantes)

Nem acredito que quebrei a cabeça olhando "how-to" por aí. Não é preciso, tem um pacote apt-get. É fácil.

$  sudo gedit /etc/apt/sources.list

Aberto o arquivo, acrescente a seguinte linha (para Ubuntu 10.4):

deb http://downloads.mongodb.org/distros/ubuntu 10.4 10gen

Se o seu Ubuntu é de outra versão substitua o "10.4" por "9.10" ou por "9.4"
Em seguida:

$  sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
$  sudo apt-get update
$  sudo apt-get install mongodb-stable

Pronto!

INSTALANDO O PYMONGO

Primeiro, instale o setuptools caso já não tenha:

$ sudo apt-get install python-setuptools

Depois:

$  sudo easy_install pymongo

Enjoy!

--------
ATUALIZAÇÃO (17/03/10): Alterada a forma de instalar pelo "apt-get". Desde de 5 de março não é mais válido o pacote por nome "mongodb". É preciso escolher entre "mongodb-stable", "mongodb-unstable" e "mongodb-snapshot" -- respectivamente o pacote estável, não-estável e o último git efetivado ao tempo da construção do pacote.

ATUALIZAÇÃO (22/06/10): Acrescentado o gpg public key.

26 fevereiro 2010

Notícias do Fronte de ZODB

Alguns vislumbres de ZODB:

.Me admira que ele receba tão pouca atenção
.Me admira que, além do Zeo, ele não venha empacotado com Zcatalog (indexador)
.Me admira que ninguém fale dele
.Me admira que ainda usemos Python com BDs relacionais

19 fevereiro 2010

Estudando ZODB

Resolvi estudar ZODB (sem Zope). O próprio wiki de ZODB diz que ZODB trabalha independente de Zope, vamos ver.

Nosso foco por enquanto é Desktop (e não Web), mas nunca vi ninguém comentar algum projeto baseado em ZODB sem Zope para Desktop. Será que seria uma boa idéia?

Do jeito que costumo ser meio radical, se der certo vou abandonar a minha então preciosa fórmula Storm-Postgres, mudando para pure-python-zodb.

PS. Por enquanto só não gostei do nome "zodb" porque nunca saberemos como realmente pronunciar isso, parece aquele nome transcendental "GNU" cuja a pronúncia, segunda as más línguas, só pode ser feita corretamente por Richard Stallman.

15 fevereiro 2010

Caso Arruda: Um Bom Indicativo Nacional?

O memorável acontecimento que ocupou os últimos assuntos nacionais, "Arruda na Prisão no Carnaval", que por tão importante nos faz um pouco mais alegres com o país, infelizmente talvez não seja um símbolo de qualquer avanço.

A decisão de Marco Aurélio (que resultou na permanência de Arruda na prisão) tomada isoladamente não quer dizer muita coisa, claro. Mas, seria acaso que representaria que o país avançou significativamente no combate à corrupção? Não nos parece. Contudo, já deu pra nos deixar um pouco mais feliz, o que será ainda melhor.

O STF tem duas facetas distinguíveis. Quem se liga um pouco na política deve ter muito ódio daquele STF que profere decisões como a do caso Daniel Dantas, deplorável. Todavia, há outro lado do STF que em geral não é objeto de análise dos críticos de economia e de política, somente acompanhada por estudiosos de Direito: a de um justiça de escol que invoca as mais sofisticadas teorias do universo jurídico euro-continental.

Digo-vos que nosso órgão julgador maior não raramente profere decisões dignas de um tribunal da sua importância. Entretanto, tratam-se de processos cujo objeto não envolve ao mesmo tempo muito dinheiro e gente muito poderosa.

E Roberto Arruda também não é poderoso e não tem muito dinheiro? Dinheiro talvez tenha, contudo por uma reviravolta do destino ficou desprovido de poder.

A começar, o vídeo era inequívoco e dava muito na cara ele recebendo um calhamaço enorme de dinheiro -- e me sai afirmando que era para os pobres. O esquema dele era pequeno, envolvia gente pequena, ele não possuía grandes tentáculos. Por essa razão (e para o azar dele) o DEM preferiu execrá-lo. Sem apoio do DEM, do PSDB e nem do PT, ficou isolado.

Não contando com quase nenhuma proteção política, Arruda se tornou desinteressante para que alguém quisesse gastar capital político com ele, fato que permitiu à grande mídia ecoar o descontentamento dos calangos com seu governador.

Ato contínuo, o processo subiu rapidamente ao STF como normalmente ocorre em casos malhados na imprensa. E nesse exato ponto em que Mendes poderia usurpar seus poderes e mandar soltá-lo, nada fez. Sem grande força Arruda não conseguiu interpelação suficiente junto a Mendes, que então deixou passar.

Marco Aurélio que historicamente concedia Habeas Corpus a grandes criminosos por achar que faltavam evidências (ou sabe-se lá por que), encontrou evidências aos montes. O destino dera o nó final, Arruda teve de permanecer na cadeia.

Fim? Acabou a carreira de Roberto? Duvido. Duvido até que fique na prisão por muito tempo; não nesse país, não na nossa época; não creio que haja chegado os tempos em que a impunidade cessará.

Me alegro com muitas coisas que tenho visto nessa nação. Todavia estou ainda cético quanto ao caso Arruda, e ainda mais cético quanto às boas intenções de Marco Aurélio (ele nunca foi disso).

10 fevereiro 2010

O Tal Banco de Dados Relacional

Acreditem eu só entendi o que deveras era um BD relacional quando tentei montar um BD orientado a objetos.

Em algumas horas livres rascunhei na mente o projeto de BD orientado a objetos. Um dia sentei e fiz a modelagem de dados começando por Python, usando Storm. Até aí perfeito: a classe pai ia dando o rumo aos filhos que além de necessariamente herdar os atributos do pai criavam outros filhos ou se relacionavam com outros filhos numa hierarquia angelical.

Legal. Passei para o Postgres. Daí o primeiro problema: as tabelas-filho estranhamente herdavam fisicamente as colunas da tabela-pai. Beleza, esqueci que tem esse detalhe. Mas não muda muito as coisas. Em seguida as "tabelas-filhas-netas" (herdavam da tabela pai e filho) se relacionavam com a segunda geração e tudo mais.

Tudo sincronizado em python-storm. Vamos para os testes e... saltam resultados estranhíssimos.

..:|:.. A chave primária da classe pai fora francamente violada sem que o Postgres reclamasse. Hmm... Teria feito alguma coisa errada? Reviso as restrições. Tudo certo. Como os Postgres havia aceitado aquilo?

..:|:.. Dados inconsistentes, as restrições haviam sido sumariamente ignoradas.

..:|:.. O próprio BD obrigava os dados a serem inconsistentes. Se tentasse consertar manualmente os problemas das chaves primárias e estrangeiras, o BD impunha novos dados inconsistentes. Que loucura era aquela?

O que estaria errado então? Fui ao Google e finalmente encontrei a chave-primária da questão: o Postgres é relacional e tentar fazê-lo orientado a objetos é amplamente desencorajado.

O neǵocio é que o que eu considerava inconsistente não era assim tão inconsistente, apenas que havia uma meia lógica objeto-relacional que justificava aqueles dados.

Final das contas: Usando um BD relacional seja apenas relacional, que funciona muito bem. A propósito, a idéia de OO é ótima, mas não é tudo.

19 janeiro 2010

Até Onde Deus se Moveria?

Acaso Deus não faria justiça aos seus filhos? Sim, faria e faria depressa, disse Jesus. Que a esperança no Filho de Deus nos console.

22 outubro 2010

Vida que Vivemos


Estou para mudar de cidade, mudar de vida. Estou muito feliz. Por enquanto é o que posso dizer. Que Deus me guie.

16 setembro 2010

Da Série: Efeitos Colaterais da Vida

De manhã após uma xícara de café forte: "Sinto que posso mudar o mundo".

À tarde: "Acho que vou deixar para amanhã".

À noite: "Preciso dormir".

27 julho 2010

O Patriotismo Não Proporciona Riqueza Às Nações

É uma tese que estou desenvolvendo.

Numa percepção empírica, tenho que em todos os povos reside -- em maior ou menor grau -- um sentimento nacionalista, sem exceção.

Todavia, o fato é que não é o amor à pátria que leva o Estado ao desenvolvimento. Estamos certos de que o apego a uma causa levará necessariamente a algum efeito, para melhor ou pior, mas a bandeira ufanista não roda as engrenagens econômicas, as quais dependem em certas ocasiões de variáveis macro-econômicas, ondas ocasionais, ou se concretizam no sucesso de uma leva de empreendedores que se lançam cegamente em aventuras empresariais.

Ainda não procurarei saber se algum autor já se debruçou sobre o tema, mas vou investigar.

29 maio 2010

Conversa Interna

Descortinando uma biblioteca antiga
-- Hmm... Pra que será que serve essa linha?... Vou apagar esse trecho que não serve pra nada...
-- Você tem certeza que vai funcionar se você apagar isso? Talvez seja melhor deixar do jeito que está. Ele sempre funcionou assim.
-- Mas pra que foi mesmo que vim olhar esse modulo?
-- Ah sim, era porque eu queria implementar um nova funcionalidade. Mas talvez eu devesse achar um meio mais fácil de fazer isso sem ter que mexer aqui...

22 abril 2010

La avanzada brasileña sobre empresas argentinas no se detiene, El Clarín


El mayor banco de Brasil compra el Patagonia por US$ 480 millones

Ya prevén lanzar una oferta por el 100%. La ANSeS tiene casi 15% de la institución local.




La avanzada brasileña sobre empresas argentinas no se detiene. El Banco Do Brasil, el grupo financiero más grande de América Latina, anunció ayer que tomará el control del Patagonia, con la compra de 51% del paquete accionario de la firma local por un monto que orilla los 480 millones de dólares. [Leia a íntegra]

12 abril 2010

Google Python Style Guide

Rodando por aí descobri que tem um google-styleguide, e que ao lado de C++ e Objective C, há o Google Python Style Guide.

De maneira geral esse guia recomenda o que já é recomendado em Python com alguns acréscimos com os quais concordo plenamente, incluindo a convenção sobre nomes:


Naming


module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_VAR_NAME, instance_var_name, function_parameter_name, local_var_name.
link
Names to Avoid
  • single character names except for counters or iterators
  • dashes (-) in any package/module name
  • __double_leading_and_trailing_underscore__ names (reserved by Python)

Naming Convention
  • "Internal" means internal to a module or protected or private within a class.
  • Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
  • Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
  • Use CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it's confusing when the module happens to be named after a class. ("wait -- did I writeimport StringIO or from StringIO import StringIO?")
***

A PEP 8, guia de estilo Python, desencoraja o uso de sublinhados em nomes de módulos, mas contrariando a PEP eu vinha usando "modulo_nome" mesmo assim, e agora vejo que não estou só.

Entretanto, não uso variáveis privadas (que iniciam com duplo sublinhado), somente internas (que começam por um único sublinhado), nunca vi necessidade de variáveis privadas em Python, mas acho que dependendo do grau de polimorfismo ou mágica talvez seja necessário usá-las.

07 abril 2010

Linux É "Linux"!

Há muita confusão desnecessária com o nome Linux. Criou-se uma pseudo-correção descabeçada que fez surgirem os tais: "Unix-like", "sistemas Unix", "Compatível com Unix", "Unix-family", "Posix" e "GNU/Linux".

Vamos desatar esses nós.

UNIX Bla-Bla-Bla
-----------------------
Linux foi desenvolvido baseado em Unix (pelo Minix) e com intuito de ser compatível com ele, o que não significará que ele é subproduto do Unix.

Você por acaso já ouviu alguém falar "QDOS-like" em vez de Windows, ou "Unix-like" em vez "Mac OS"?

Pois então, também não faz sentido chamar o filho do mesmo nome do pai. O Filho já cresceu, se tornou maior que o pai, de modo que a família a qual pertence Linux não é o mesmo que o nome próprio "Linux" -- o qual justamente o distingue dos demais sistemas derivados do Unix.

Esse uso só seria aceitável em casos bem restritos de aplicativos desenvolvidos para toda a família Unix, e mesmo assim seria melhor designar primeiro o sistema mais conhecido: "Desenvolvido para Linux (ou Unix-like)" ou ainda "Linux-like".

POSIX
---------
Esse aqui é ainda escabroso. Em Python se você invocar "os.name" em cima de Linux ele vai retornar "posix", mas POSIX é o nome de um conjunto de normas de interface destinada à família Unix, e jamais sinônimo de Linux, ou pior, o "nome" do sistema operacional.

GNU/LINUX
-------------------
Quem inventou esse nome foi Stallman na tentativa de se creditar ao projeto GNU o desenvolvimento de grande parte dos aplicativos de gerenciamento que rodam em cima do kernel (núcleo) de Linux.

Bem, esse nome é até aceitável. Ele envolve uma discussão abstrata e pouca precisa sobre terminologias.

Estamos certos de que o projeto GNU é importante, mas nos parece que ao criar mais um nome confuso para Linux acaba-se por atrapalhar a própria propagação dos aplicativos GNU, vez que atrapalham o fomento à adoção de Linux.

11 março 2010

(Orientação_a_objetos).crítica_sobre( )

O que chamamos de objetos não podem ser considerados objetos na concepção humana, mas apenas na concepção da própria disciplina de programação.

Aliás, lembro que tive certa dificuldade no princípio de compreender o que era a tal iluminada OO porque se nos apresentavam uma explicação segundo a qual a OO se aproximava da concepção humana a respeito de objetos -- premissa que hoje considero parcialmente falsa.

Digamos que eu tivesse ganhado um caderno, mas não soubesse o que é. Então pegaria aquele caderno, e analisando ele como objeto, diria à pessoa que me presenteou: "legal, mas o que eu faço com isso?"

Intuitivamente procuramos alguma coisa para fazer com um caderno, ou, procuramos saber para que ele serve. Todavia, assim concebendo não se pode afirmar que os números seriam objetos no sentido da OO, vez que eles não fazem nada, e sim quem o faria seria o engenheiro que usa de procedimentos matemáticos para com os números.

Note a discrepância. A classe é "Matemática", o procedimento é "soma", e os instrumentos: os números. Quando muito poderíamos asseverar que os números são o objeto da classe matemática, o que nunca implicaria entender que invocaríamos a função "soma" para um número, ao contrário, o parâmetro número é que é passado para o procedimento "soma", a lógica é inversa à da OO.

O único fato da OO que se assemelha ao pensamento humano é a existência de atributos ligados a um objeto. Nesse aspecto, um caderno pode ser verde, pequeno, etc.

Sucede que atributos não podem ser funções de um caderno, pois ninguém que toma o caderno nas mãos requer dele que proceda à sua função "escrever", senão usando o procedimento "escrever" passa-lhe um "caderno".

De modo que não é o paradigma OO que é intuitivo, mas sim o procedural, razão até pela qual um iniciante costuma ter mais facilidade em lidar com funções que com classes e métodos.

A grande idéia da OO é atar a um objeto tudo o que se pode obter dele: desde seus atributos até os procedimentos aplicáveis a ele. É como se um objeto já soubesse o que ele possui, o que ele pode fazer e quais as suas funções. Observe-se, contudo, que saber o que é, o que tem e o que pode fazer é muito mais a característica de uma ente autociente que a de um objeto.

Com efeito, seria mais coerente descrever a OO como a orientação a "entes autocientes", já que estão cientes de seus atributos e de suas funções.

Não obstante, o paradigma OO representou um grande avanço na programação, porque realizou que dentro de um universo bastante limitado de possibilidades é mais fácil atrelar atributos e métodos a um máquina autociente do que tentar atrelar objetos a centenas de rotinas não cientes.

Assim, nos parece mais desejável que, p.ex., em Python a função "max( )" fosse um método, pois embora intuitivamente se use primeiro o procedimento max( ) e depois o objeto "list", seria mais simples verificar que um objeto "list" detém a função "max( )", mesmo que "max( )" fosse o mesmo nome para funções semelhantes ligadas a "str" e a "tuple".

De outra lado, não nos parece razoável exigir exclusivamente o uso do paradigma OO. Ele deve ser preponderante, no entanto haverá ocasiões em que um conjunto de funções será mais funcional (por assim dizer), daí uma ampla vantagem de Python que permite o multi-paradigma, mas isso já é outra conversa.

05 março 2010

MongoDB é Magnífico!

Pretendia esperar esperar mais uns dias para postar com mais profundidade, mas estou tão deslumbrado com Mongo que vou postar com apenas dois dias de estudo.

Veja-se só as possibilidades, em Mongo podemos:

  • Armazenar diversos objetos/tipos nativos de Python como: int, float, datetime.datetime, list, unicode.
  • Uma vez que ele é "orientado a documentos", ficamos livres de necessariamente criar schemas, mas eles podem ser criados.
  • Pode-se armazenar documentos sem termos que definir tamanho máximo, de modo que facilmente é possível criar registros que contenham arquivos inteiros.
    • A abordagem é tão diferente que nem é necessário criar uma "tabela", basta denominar as chaves e depois determinar valores para elas.
  • Podemos acrescentar "campos" sem sofrer para definir novas regras.
  • O mais extraordinário sobre as regras de consistência / relacionamento / estruturação:
    • Como SQL, podemos criar "referências".
    • Como OO, podemos criar registros HERDADOS com simplicidade. Você pode acreditar nisso????
    • Como OO "Plus", podemos criar documentos EMBEDEDD com facilidade. Incrível!


Quando vi que era possível criar classes-documentos-filhos e também classes-documentos-embededd com consistência e naturalidade fiquei impressionado. Isso vai facilitar nossas vidas. Basta olhar aqui para ver.

Aliás, com tanto tempo no modelo SQL eu tive certa dificuldade no primeiro momento de imaginar outra modelagem de dados.

A propósito, estou usando um ORM para Mongo chamado "mongoengine" que roda em cima do pymongo.

INSTALANDO MONGOENGINE

$ sudo easy_intall mongoengine

Grato ao La Batalema sobre os posts de MongoDB.

04 março 2010

Como Instalar MongoDB no Ubuntu (para iniciantes)

Nem acredito que quebrei a cabeça olhando "how-to" por aí. Não é preciso, tem um pacote apt-get. É fácil.

$  sudo gedit /etc/apt/sources.list

Aberto o arquivo, acrescente a seguinte linha (para Ubuntu 10.4):

deb http://downloads.mongodb.org/distros/ubuntu 10.4 10gen

Se o seu Ubuntu é de outra versão substitua o "10.4" por "9.10" ou por "9.4"
Em seguida:

$  sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
$  sudo apt-get update
$  sudo apt-get install mongodb-stable

Pronto!

INSTALANDO O PYMONGO

Primeiro, instale o setuptools caso já não tenha:

$ sudo apt-get install python-setuptools

Depois:

$  sudo easy_install pymongo

Enjoy!

--------
ATUALIZAÇÃO (17/03/10): Alterada a forma de instalar pelo "apt-get". Desde de 5 de março não é mais válido o pacote por nome "mongodb". É preciso escolher entre "mongodb-stable", "mongodb-unstable" e "mongodb-snapshot" -- respectivamente o pacote estável, não-estável e o último git efetivado ao tempo da construção do pacote.

ATUALIZAÇÃO (22/06/10): Acrescentado o gpg public key.

26 fevereiro 2010

Notícias do Fronte de ZODB

Alguns vislumbres de ZODB:

.Me admira que ele receba tão pouca atenção
.Me admira que, além do Zeo, ele não venha empacotado com Zcatalog (indexador)
.Me admira que ninguém fale dele
.Me admira que ainda usemos Python com BDs relacionais

19 fevereiro 2010

Estudando ZODB

Resolvi estudar ZODB (sem Zope). O próprio wiki de ZODB diz que ZODB trabalha independente de Zope, vamos ver.

Nosso foco por enquanto é Desktop (e não Web), mas nunca vi ninguém comentar algum projeto baseado em ZODB sem Zope para Desktop. Será que seria uma boa idéia?

Do jeito que costumo ser meio radical, se der certo vou abandonar a minha então preciosa fórmula Storm-Postgres, mudando para pure-python-zodb.

PS. Por enquanto só não gostei do nome "zodb" porque nunca saberemos como realmente pronunciar isso, parece aquele nome transcendental "GNU" cuja a pronúncia, segunda as más línguas, só pode ser feita corretamente por Richard Stallman.

15 fevereiro 2010

Caso Arruda: Um Bom Indicativo Nacional?

O memorável acontecimento que ocupou os últimos assuntos nacionais, "Arruda na Prisão no Carnaval", que por tão importante nos faz um pouco mais alegres com o país, infelizmente talvez não seja um símbolo de qualquer avanço.

A decisão de Marco Aurélio (que resultou na permanência de Arruda na prisão) tomada isoladamente não quer dizer muita coisa, claro. Mas, seria acaso que representaria que o país avançou significativamente no combate à corrupção? Não nos parece. Contudo, já deu pra nos deixar um pouco mais feliz, o que será ainda melhor.

O STF tem duas facetas distinguíveis. Quem se liga um pouco na política deve ter muito ódio daquele STF que profere decisões como a do caso Daniel Dantas, deplorável. Todavia, há outro lado do STF que em geral não é objeto de análise dos críticos de economia e de política, somente acompanhada por estudiosos de Direito: a de um justiça de escol que invoca as mais sofisticadas teorias do universo jurídico euro-continental.

Digo-vos que nosso órgão julgador maior não raramente profere decisões dignas de um tribunal da sua importância. Entretanto, tratam-se de processos cujo objeto não envolve ao mesmo tempo muito dinheiro e gente muito poderosa.

E Roberto Arruda também não é poderoso e não tem muito dinheiro? Dinheiro talvez tenha, contudo por uma reviravolta do destino ficou desprovido de poder.

A começar, o vídeo era inequívoco e dava muito na cara ele recebendo um calhamaço enorme de dinheiro -- e me sai afirmando que era para os pobres. O esquema dele era pequeno, envolvia gente pequena, ele não possuía grandes tentáculos. Por essa razão (e para o azar dele) o DEM preferiu execrá-lo. Sem apoio do DEM, do PSDB e nem do PT, ficou isolado.

Não contando com quase nenhuma proteção política, Arruda se tornou desinteressante para que alguém quisesse gastar capital político com ele, fato que permitiu à grande mídia ecoar o descontentamento dos calangos com seu governador.

Ato contínuo, o processo subiu rapidamente ao STF como normalmente ocorre em casos malhados na imprensa. E nesse exato ponto em que Mendes poderia usurpar seus poderes e mandar soltá-lo, nada fez. Sem grande força Arruda não conseguiu interpelação suficiente junto a Mendes, que então deixou passar.

Marco Aurélio que historicamente concedia Habeas Corpus a grandes criminosos por achar que faltavam evidências (ou sabe-se lá por que), encontrou evidências aos montes. O destino dera o nó final, Arruda teve de permanecer na cadeia.

Fim? Acabou a carreira de Roberto? Duvido. Duvido até que fique na prisão por muito tempo; não nesse país, não na nossa época; não creio que haja chegado os tempos em que a impunidade cessará.

Me alegro com muitas coisas que tenho visto nessa nação. Todavia estou ainda cético quanto ao caso Arruda, e ainda mais cético quanto às boas intenções de Marco Aurélio (ele nunca foi disso).

10 fevereiro 2010

O Tal Banco de Dados Relacional

Acreditem eu só entendi o que deveras era um BD relacional quando tentei montar um BD orientado a objetos.

Em algumas horas livres rascunhei na mente o projeto de BD orientado a objetos. Um dia sentei e fiz a modelagem de dados começando por Python, usando Storm. Até aí perfeito: a classe pai ia dando o rumo aos filhos que além de necessariamente herdar os atributos do pai criavam outros filhos ou se relacionavam com outros filhos numa hierarquia angelical.

Legal. Passei para o Postgres. Daí o primeiro problema: as tabelas-filho estranhamente herdavam fisicamente as colunas da tabela-pai. Beleza, esqueci que tem esse detalhe. Mas não muda muito as coisas. Em seguida as "tabelas-filhas-netas" (herdavam da tabela pai e filho) se relacionavam com a segunda geração e tudo mais.

Tudo sincronizado em python-storm. Vamos para os testes e... saltam resultados estranhíssimos.

..:|:.. A chave primária da classe pai fora francamente violada sem que o Postgres reclamasse. Hmm... Teria feito alguma coisa errada? Reviso as restrições. Tudo certo. Como os Postgres havia aceitado aquilo?

..:|:.. Dados inconsistentes, as restrições haviam sido sumariamente ignoradas.

..:|:.. O próprio BD obrigava os dados a serem inconsistentes. Se tentasse consertar manualmente os problemas das chaves primárias e estrangeiras, o BD impunha novos dados inconsistentes. Que loucura era aquela?

O que estaria errado então? Fui ao Google e finalmente encontrei a chave-primária da questão: o Postgres é relacional e tentar fazê-lo orientado a objetos é amplamente desencorajado.

O neǵocio é que o que eu considerava inconsistente não era assim tão inconsistente, apenas que havia uma meia lógica objeto-relacional que justificava aqueles dados.

Final das contas: Usando um BD relacional seja apenas relacional, que funciona muito bem. A propósito, a idéia de OO é ótima, mas não é tudo.

19 janeiro 2010

Até Onde Deus se Moveria?

Acaso Deus não faria justiça aos seus filhos? Sim, faria e faria depressa, disse Jesus. Que a esperança no Filho de Deus nos console.