Exercendo a minha liberdade de expressão, vou tentar explicar por que raios, afinal, eu detesto tanto o DBIx::Class. Ninguém é obrigado a concordar comigo, mas espero que os que leiam, reflitam.

Sem dúvida, é um treco robusto e consistente, mas já dizia o Oscar Wilde: "Consistency is the last refuge of the unimaginative." Agora eu, felizmente (ou não), tenho imaginação de sobra. Sou conhecido por minhas gambiarras atrozes. Sou um péssimo programador, a ponto de ter largado a faculdade de computação no quarto ano e ter me formado em desenho industrial

O que gosto no Perl é a sua capacidade de ser um master-glue, amarrando pedaços desconexos numa "coisa" que, magicamente, atende às necessidades.

Como bem ilustra o fabuloso poema "Black Perl", o Perl é livre de preconceitos e purismos. Posso "furar" a privacidade dos atributos do Moose, subverter o MVC com o Mojolicious, além de fazer todo tipo de monkeypatching bizarro e ad-hoc.

Aí entra o DBIx::Class. Seu glorioso dbicdump já ofende os meus olhos:

# Created by DBIx::Class::Schema::Loader v0.07010 @ 2011-08-24 13:26:20
# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:qqyhu9B0Vr7l1KsQ6CG7Jw

Desgraçado, como assim?! Em primeiro lugar, a caralhada de classes (uma por tabela?!), para mim, por si só, é uma coisa javesca. E, em segundo lugar, o mentecapto é prolixo e nem posso ousar de intervir com o Perl::Tidy para deixar o código legível do jeito que gosto. Sem falar que o schema é "lossy" e perde várias informações.

Mas isso é o de menos. Não consigo imaginar um workflow que me agrade. Eu gosto do pgAdmin e do HeidiSQL e costumo elaborar as minhas tabelas e queries nessas GUIs. Isso me dá um retrabalho na hora de "portar" para Perl (diferentemente do DBI, aonde é só copiar e colar, ráááá).

E olha só, CRUD não é o foco do meu trabalho. Às vezes, preciso dar uma cutucada no banco de dados, ou então um grande processamento em lote. Mas variedade de queries? Não me pertence.

Aliás, um ponto importante: em geral, sou "equipe de um homem só". E Perl dá um grande poder nas mãos das equipes de um homem só. Não preciso de um código de fácil manutenção. Eu assumo a penalidade e o risco de me perder nas próprias queries quilométricas. Me divirto muito com isso.

Nesse ponto, DBIx::Class me parece coisa de tiozão. Me lembra aqueles emails corporativos aonde a assinatura é 100x maior do que a mensagem, sendo o schema a assinatura e o uso da mesma, a mensagem

Mas vamos começar pelo começo. Um belo dia, estive eu no caixa de um restaurante, prestes a pagar pelo meu almoço, quando uma notícia nada agradável me surpreende: o meu saldo estava zerado!!!

Como isso seria possível, se o meu ticket até está na minha planilha de gastos (isso é, sempre que uso ele, anoto quando e aonde foi)?! Pois é, foi clonado.

Então de que adiantou todo o meu acompanhamento de crédito/débito? Pfffffft

Aí no processo de resgatar o rico dinheirinho do meu rango, me deparei com o site oficial, http://www.ticket.com.br/, que é uma tosqueira inigualável. Para começar, o "sistema de segurança" é tão pífio que requer apenas o número do cartão, sem senha alguma, para consultas de extrato/saldo! Tudo bem que não é uma informação pra lá de sigilosa, ainda assim... Qual a utilidade podemos extrair disso?

1. Funcionários de uma mesma empresa recebem seus cartões do mesmo lote. A numeração dos cartões é sequencial, só muda o dígito verificador (que segue o padrão do cartão de crédito). No extrato sai o nome do local aonde o dinheiro foi debitado. Assim, é perfeitamente possível rastrear os meus coleguinhas;
2. Posso fazer coleta automática do extrato, assim saberei de antemão se fui debitado indevidamente. Poderia receber avisos de débito/crédito por email, mas o email está morrendo, e o hype do momento são os leitores de feed (sarcasmo mode off).

Acabei optando pela segunda opção. Aliás, aproveitei para fazer um test drive do DotCloud, e gostei!

Então, o negócio é o seguinte. Pegue o seu Ticket. Entre em http://ticket.iwatcher.net/. Preencha o respectivo campo, e gere URL do tracker. Eu gosto do Google Reader, mas funciona em qualquer outro agregador de feeds. A ideia central é: para cada "ping" no tracker, o webservice rodará um scrapper no site oficial, e gerará um feed a partir dos dados coletados. Assim, você terá um feed de notícias gerado pelos seus hábitos gastronômicos

Uma observação importantíssima a respeito da privacidade dos dados: o número do seu Ticket é transferido em plaintext, assim como no site oficial. Obviamente, dessa forma ele acaba parando no access.log do servidor. Não tem como evitar isso. Já os dados das transações não estão sendo replicadas em nenhum banco de dados. Traduzindo: eu não sei o que se passa na sua conta, caso você venha a utilizar o meu webservice. Nem pretendo saber. Mas, de posse dos logs dos servidores, é perfeitamente possível acessar o extrato referente a cada Ticket consultado, visto que o site oficial não utiliza nenhum tipo de PIN/senha.

Ah, e o layout da página do gerador de feeds fica uma nhaca no Firefox. Eu não sei corrigir

Alguém com um bom domínio de CSS se habilita?

Mas, por quê?!

Qual o sentido de alguém instalar os módulos dentro do seu $HOME? Normalmente, uma das duas:

1. Você não tem permissão suficiente para instalar no próprio sistema (você está mexendo num servidor ou coisa do tipo);
2. Você está desenvolvendo a bagaça, e quer manter a versão bleeding edge só para você.

Bom, se for o 2-o caso, existe o tal do perlbrew.

Mas eu gosto das instalações locais e as uso desde '97. E o local::lib foi uma mão na roda e tanto! Então, vamos lá:

Passo-a-passo:

Download do local::lib:

curl -LO http://search.cpan.org/CPAN/authors/id/A/AP/APEIRON/local-lib-1.008004.tar.gz
tar xzf local-lib-1.008004.tar.gz
cd local-lib-1.008004/

Instalação do local::lib:

perl Makefile.PL --bootstrap=$HOME/perl5
make
make test
make install

Ativando local::lib na inicialização da shell (Bash):

cat << PROFILE >> $HOME/.profile

export PERL_MM_USE_DEFAULT=1
eval \$(perl -I\$HOME/perl5/lib/perl5/ -Mlocal::lib)
PROFILE

Agora, é hora de logoff/logon para quem está acostumado com o Windows, ou então:

. $HOME/.profile

Prosseguindo com a configuração/teste do CPAN (essa configuração faz as dependências serem instaladas automaticamente):

cpan

cpan[1]> o conf prerequisites_policy follow
cpan[2]> o conf commit
cpan[3]> install App::cpanminus
cpan[4]> quit

Enumerando os módulos instalados:

perl -MExtUtils::Installed -E 'chdir $ENV{PERL_LOCAL_LIB_ROOT}; my $i = new ExtUtils::Installed; say for $i->modules'

cpanminus permite atualizar todos de uma vez, de uma maneira eficiente:

perl -MExtUtils::Installed -E 'chdir $ENV{PERL_LOCAL_LIB_ROOT}; my $i = new ExtUtils::Installed; say for $i->modules' | cpanm

Referências:

• Catalyst com local::lib
• Using CPAN

Dropbox é MUITO foda. Se você está lendo isso, certamente concorda, e provavelmente está atrás de uma maneira milagrosa de expandir o storage sem pagar um tostão, não é mesmo? Afinal, 2GB (default no momento da escrita do presente post) é menor até do que a caixa do GMail.
O próprio Dropbox oferece várias "gincanas" através das quais as pessoas tem chances de catar algumas migalhas de storage, mas o que realmente conta são 2 coisas:

1. Vincular e-mail de uma faculdade dobra o bônus dos referrals e, conseqüentemente, o espaço máximo possível de ser obtido através dos mesmos (16GB);
2. Referrals, propriamente ditos. Cada pessoa indicada que instala o cliente do Dropbox te acrescenta 250MB grátis (500MB, se você se qualificar no primeiro item).

No caso do e-mail, não há muito o que fazer. Ou você tem, ou algum amigo/parente seu tem. Não, um e-mail @australia.edu não funciona.

Já os referrals...

Se você trabalha com çáites já faz um tempinho, deve ter uns par desse no fundo da gaveta...

As imagens do walkthrough abaixo são clickáveis

Coube no orçamento de R$21,48, e olha que nem sei usar essa bagaça direito! Em apenas 3 dias, mission acomplished.

De fato, trouxe mais gente do que precisava, pois vários demoraram para instalar o programinha... Espero que algum dia aumentem o máximo de referrals para poder aumentar

Recapitulando o post mais explosivo desse blog sob uma perspectiva mais... chocante! Simplesmente demais!

Bonus para quem curte coisas de cientista maluco de desenho animado, tais como Tesla Coils, Jacob's Ladders e afins:

• Mike's Electric Stuff - destaque para The Destruct-O-Tron:

• Tesla Downunder - fico até confuso para indicar algo em especial desse site da terra do ornitorrinco! Eu não sei o que está acontecendo aqui, mas também quero participar:

• Nevada Lightning Laboratory - destaque para Lorentz Gun:

• E, para fechar com a chave de tungstênio, isso só pode ser fake, de tão grotesco que é:

Olha, não conheço sequer uma criatura digna de ser chamada Programador Perl que esteja dentro dos padrões daquilo que a sociedade considera "normal".

Se Perl mutila a psique humana ou apenas atrai freaks, jamais saberemos. O fato é: somos "foverer alone" e nos vangloriamos disso

Mas, por mais insuportável que será para mim deixar o meu covil, nesse dia 7 de maio ao menos terei uma boa razão para fazê-lo: o II São Paulo Perl Workshop! Esse evento promete, ao menos para mim, muito mais do que o famigerado Google Developer Day, a começar pelo fato de que o local não terá acesso à Internet!!! Ou seja: só vai quem se interessa pelo tema.

E, falando em coisas interessantes, o próprio Larry Wall, o criador do Perl, dará palestra! Se eu tivesse uma cópia de "Deus, um Delírio" [Richard Dawkins] em papel, garanto que pediria um autógrafo na contracapa.

Enfim, esse post não é patrocinado, eu não ganho comissão das inscrições, e, no fundo, quero mais que vocês todos, programadores .NOT, se fsck-odam. Para quem fica, a minha; para quem vai, a do meu pai!

Me recuso a entender como ainda existem uébidevélopers que não conseguem decidir se usam codificação ISO-8859-1 ou UTF-8 em suas bagaças, e acabam optando por ambas. Para piorar, os países que tem a capacidade de definir normas consistentes já o fizeram há décadas, e hoje podem sobreviver muito bem sem fugir do ASCII

Já quem lê (e escreve) em cirílico ou português, que se vire. Inclusive, quem escreve hoje em dia raramente pensa em quem vai ler. Então, você, que por razões de ofício ou não, precisa processar computacionalmente uma quantidade exorbitante de texto heterogêneo na língua de Camões, está fo-di-do.

Felizmente, pensou "processamento de textos", pensou Perl! Entretanto, por melhor que seja a ferramenta, não resolve o problema sozinha. Então, tentando fazer do mundo um lugar melhor, fiz uma miscelânea da minha experiência de dar cabeçada na parede. Have a phun:

Perl e Unicode (entre outras codificações de texto)

(Não que não seja considerado "fracasso" pagar a hospedagem do blog durante 1 ano e não usá-lo )

Encontrei através do Slashdot um excelente post baseado na carta do Walter Murch, um cara que é, sem menor sombra de dúvida, uma autoridade no mundo de cinema. Vale a pena:

Why 3D doesn't work and never will. Case closed.

O próprio título já se opõe veementemente aos filmes três-dê. E com razão. Um argumento forte citado contra os filmes estereoscópicos (esses aonde cada olho recebe uma imagem filmada de um ponto diferente) é a convergência. Descaradamente copio aqui um exemplo muito feliz (depois explico):

Resumindo, os nossos olhos fazem um esforço para fixarem-se ambos no mesmo objeto. O cérebro utiliza o feedback dos músculos acionados para isso para distinguir quão longe está o objeto. Com duas imagens filmadas de ângulos distintos, a convergência acaba sendo fixa, o que engana o cérebro, e a nossa (ao menos, a minha) cabeça dói por que assistir a um filme 3D é um estupro cerebral.

Agora, um detalhe curioso, que passou desapercebido pelo autor do artigo citado acima (mas talvez não pela fonte original): não é apenas a convergência dos olhos que desfoca os objetos distantes quando olhamos os que estão perto! Para focalizar os objetos distantes ou próximos, uma força é aplicada ao cristalino, que, comprimindo-se, resiste, e, novamente, temos um feedback para o cérebro! Não é a toa que enxergamos em profundidade tapando um olho. Eis um exemplo, por sinal, muito útil para quem mexe com computação gráfica:

Obviamente, as imagens de um suposto filme 3D possuem o foco fixo; ou seja, mais uma coisa para judiar do cérebro.

Bom, ainda, para fechar com a chave de ouro, uma homenagem às pessoas que vivenciam um mundo completamente 3D, apesar de terem somente um olho:

Update:

O grande mestre e conhecido tecnófobo Allan Sieber acaba de publicar esta tirinha em seu ilustre blog; nada melhor para ilustrar o meu descontentamento:

Jamais canso de me surpreender com a engenhosidade humana de propor soluções para os problemas que não existiam antes de serem resolvidos

O documentário Gizmo trata muito bem dessa problemática, e o meu objetivo não é esse. No vídeo acima, temos uma traquitana que diz destruir dados de um CD/DVD em apenas 5 segundos, riscando a superfície dos mesmos à moda de espirógrafo. Se não me falha a memória, superfície riscada é o menor estrago que pode acontecer a um disco óptico: existem engenhocas (muito mais úteis, por sinal) que revertem o processo, polindo a superfície.

Agora, eu, como um bom piromaníaco, tenho uma abordagem um tanto quanto explosiva. Muito mais garantida (quero ver juntar estilhaços, ráááá) e barata (uma bombinha de R$ 2,00 acaba com 20 discos em 5 segundos ). Eis a vídeo-aula que eu e o meu irmão fizemos, explicando o processo:

P.S. - e, crianças: não façam isso em casa

Atari ST, 8 MHz, 512 KB RAM (1985).

Cybernet ZPC-GX31, Intel® Core™ 2 Quad, 4 GB RAM (2008).

Ontem achei essas duas imagens mofando no meu HD... Queria publicá-las lado a lado há um tempão, mas sempre acabava ficando meio que fora do contexto, até que as mesmas foram esquecidas e jogadas de lado. Pois chegou a hora

Essa é justamente a parte da história da computação com a qual tenho uma forte ligação emocional, por assim dizer. Acontece que o Atari ST foi o primeiro computador com o qual tive contato. Lá no final da década de 80 do século passado o meu pai trouxe um da Alemanha, para usá-lo nos seus complexos cálculos científicos. E eu ficava brincando com alguns joguinhos, muitos dos quais existiam também em consoles de 16 bits, além de ficar me frustrando repetidamente no equivalente do Paint da época, pois achava que o computador iria fazer tudo ficar lindo e maravilhoso, e, bem, não era essa a verdade, ráááá!

Devo dizer que o computador em si era muuuuuuuuuito à frente do seu tempo. O seu sistema operacional, TOS (The Operating System), com a interface GEM (Graphical Environment Manager) faziam jus ao nome (super-criativo ), funcionando satisfatoriamente e apresentando recursos que só apareceram no Windows anos mais tarde. Já no plano do hardware, foi o primeiro computador pessoal a apresentar o MIDI. É através das portas MIDI que até 16 Ataris podiam ser juntados numa "rede" para jogar o MIDI Maze em deathmatch, eheheh!

Eu sei que parece TOSco, mas era impressionante numa TV de 20"!

Multiplayer de até 16 jogadores através das portas MIDI!

Se isso não parecer revolucionário o suficiente, é só lembrar que os pacotes mais fodásticos de geração de áudio e de imagens 3D da atualidade, Cubase e 3ds Max, tiveram as suas raízes no Atari ST. Até hoje o Fatboy Slim usa um Atari ST para compor, e existe uma legião de entusiastas mantendo o legado, reimplementando e mantendo o hardware e o software do Atari ST por conta própria.

Mas estou perdendo o foco. Lá em meados da década de 90, conheci um amigo do meu pai que tinha exatamente o mesmo modelo do computador, e trabalhava profissionalmente com a computação gráfica. Inclusive, fazia vinhetas 3D para a TV. Se não me falha a memória, o programa que ele usava era o fabuloso CAD-3D. Não, eu não sabia nem o que era um programa direito; mas a minha memória visual permitiu que eu reconhecesse o tal programa nos screenshots que a Internet preservou

CAD-3D, o ascendente direto do 3ds Max.

Não teve outra: fiquei fissurado com a computação gráfica, achando que era fácil. Pedi para o meu pai me ensinar a fazer algo com o computador que fosse além de jogar joguinhos e brincar no Paint. Ele me ensinou as funções gráficas do BASIC, daí fiquei semanas tentando fazer o que hoje chamam de um desenho vetorial paramétrico de uma cara com um chapéu, huahauahua! Droga, como eu queria achar isso em algum disquete perdido por aí, para dar umas boas risadas. Acho que se eu fosse usar o LOGO, sairia melhor.

Mas o estrago já tinha sido feito. Depois, viajei para o Brasil e fiquei anos sem chegar perto de um computador. Quando vi o 486-DX, 50 MHz, 8 MB RAM, novamente do trabalho do meu pai, e me cansei de Doom, Duke Nukem 3D e R.O.T.T., fiquei novamente brincando com o QBasic, JavaScript, Assembly, Perl e C (sim, mais ou menos nessa ordem). Somente uma década depois aprendi a usar (porcamente) o SolidWorks, depois de inúmeros fiascos com os programas de cunho mais artístico. Porém jamais desistirei do meu ideal: fazer o computador se esforçar bem mais do que eu para produzir uma imagem

OK, OK, e o que o ZPC-GX31 da Cybernet tem a ver com essa digressão toda?! Absolutamente nada; apenas me fez lembrar do velho e bom Atari ST, que, apesar de 23 anos mais velho, ainda me surpreende tanto