sexta-feira, 22 de agosto de 2008

Desenferrujando

Se você gosta de programar e adora Perl... nah... mesmo que você odeie Perl, pare o que está fazendo e assista já à entrevista do Damian Conway.

São meros 35 minutos em que ele fala do seu PhD em biologia computacional, do sotaque "errado" dos americanos, de linguagens de programação em geral e de Perl 6 especificamente. Eu nunca li ou ouvi uma explicação mais interessante sobre a diferença entre tipagem estática e tipagem dinâmica.

E o final da última resposta merece até uma tentativa de tradução:
...para ser um bom programador você tem que efetivamente programar. E isso é algo que não acontece. Sabe, a gente estuda computação, a gente aprende todas aquelas coisas e fica o tempo todo fazendo exercícios e provas. Daí a gente se forma e começa a freqüentar reuniões, a desenhar modelos, diagramas e todo o resto e você pára de programar. E se você é promovido, então você é literalmente promovido a perder a oportunidade de continuar programando e eu acho que isso é um problema. Se você quer ser um jogador de tênis realmente bom, você vai treinar todos os dias. Se você quer ser um grande lutador de artes marciais você vai pro tatame todo santo dia. Se você quer ser um grande programador, você vai programar todo dia—mesmo que você tenha que usar seu próprio tempo pra isso. Se você está acordado, você é um programador. Se você está acordado às 11 horas da noite, ou às 3 da manhã, você tem que usar parte desse tempo para programar porque assim que você começa a enferrujar você começa a morrer como um programador.

terça-feira, 19 de agosto de 2008

Nerdiness


I am nerdier than 88% of all people. Are you a nerd? Click here to find out!


Hmmm... devo ter mentido um pouco nas respostas porque não esperava que fosse tão alto assim.

O teste é antigo. Acho que eu já o havia feito há vários anos, mas nem me lembro quanto deu naquela época. Talvez eu tenha melhorado de tanto ouvir o nerdcast.

Lembrei do teste depois de ver o resultado do TK... acho que ele já foi muito mais nerd nos bons tempos. :-)

sexta-feira, 15 de agosto de 2008

TIMTOWTDI

Essa semana eu e minha equipe assistimos a uma palestra muito interessante sobre Python, ministrada pelo meu colega João Bueno. Lá pelas tantas ele começou a apresentar uns slides perigosos... cada um comparando Python a uma outra linguagem de programação. Perl, bash, Java e Ruby. Esses slides são perigosos porque comparar decentemente duas linguagens é uma tarefa complexa que não se pode condensar em um só slide. Primeiro é preciso definir um conjunto de critérios objetivos para a comparação. Depois, é preciso levar em conta o contexto de uso da linguagem. Coisas como o domínio das aplicações que serão desenvolvidas, as plataformas de desenvolvimento e de implantação, a experiência dos desenvolvedores com a linguagem, o tamanho da equipe e as restrições de prazo do projeto. Depois disso tudo, é preciso resistir arduamente à tentação de "puxar a sardinha" pro lado da linguagem de nossa predileção pra não parecer que estamos apenas fazendo picuinha.

Mas tudo bem... num grupo pequeno esse tipo de discussão é tão estimulante e inofensiva quanto falar de política, futebol e bolsa de valores num happy hour.

Acho que foi no slide sobre bash que o João sugeriu um problema para o qual uma shell Unix padrão não ofereceria uma solução tão econômica e legível quanto o interpretador de comandos interativo Python. O problema era, mais ou menos, o seguinte. Suponha que haja em um diretório um conjunto de arquivos cujos nomes consistem de um prefixo alfabético, seguido de uma sequência de dígitos e terminando na extensão .jpg. Por exemplo:
 $ ls
 a0.jpg  b1.jpg  c123.jpg

O desafio é renomeá-los de modo que todos os arquivos tenham o mesmo número de dígitos. No caso acima, o resultado deveria ser: a000.jpg, b001.jpg e c123.jpg.

Eu saí da palestra com o problema na cabeça e a primeira coisa que fiz foi bolar algumas soluções de uma linha e mandar pra ele por email:
 # imprimindo os nomes
 $ ls | perl -lpe 's/^([a-z]+)(\d+)\.jpg/sprintf "%s%03d.jpg",$1,$2/e'
 a000.jpg
 b001.jpg
 c123.jpg

 # gerando comandos para renomeá-los
 $ ls | perl -lpe 's/^([a-z]+)(\d+)\.jpg/sprintf "mv %s %s%03d.jpg",$&,$1,$2/e'
 mv a0.jpg a000.jpg
 mv b1.jpg b001.jpg
 mv c123.jpg c123.jpg

 # executando os comandos na shell
 $ ls | perl -lpe 's/^([a-z]+)(\d+)\.jpg/sprintf "mv %s %s%03d.jpg",$&,$1,$2/e' | sh

É assim que eu normalmente desenvolvo uma solução na shell. Ao invés de loops eu prefiro usar comandos que gerem outros comandos, como os mv acima, de modo que eu posso verificar facilmente se estou fazendo a coisa certa. Depois de ter certeza disso, basta acrescentar um "| sh" no final pra executar os comandos gerados.

Perl tem algumas opções muito úteis na confecção de one liners como o anterior. -l, -a, -n, -p e -e são as que eu utilizo mais frequentemente. Execute um "perldoc perlrun" pra saber mais sobre elas e outras tantas opções interessantes.

Mas, pra não dizer que Perl não pode fazer as coisas sozinho eu acrescentei uma solução que não usa a shell no final.
 # fazendo tudo sozinho
 $ ls | perl -le '/^([a-z]+)(\d+)\.jpg/;rename $_,sprintf "%s%03d.jpg",$1,$2'

 $ ls
 a000.jpg  b001.jpg  c123.jpg

Mas assim como eu sou fã de Perl e o João é fã de Python, o Andreyev é fã de Bash e não deixou barato, mandando o seguinte email pro grupo:
 $ ls
 a0.jpg  b1.jpg  c123.jpg

 $ for i in *.jpg; do j=${i%*.jpg}; printf "mv %s %s%03d.jpg\n" $i ${j//[0-9]/} ${j//[a-z]/}; done
 mv a0.jpg a000.jpg
 mv b1.jpg b001.jpg
 mv c123.jpg c123.jpg

 $ for i in *.jpg; do j=${i%*.jpg}; printf "mv %s %s%03d.jpg\n" $i ${j//[0-9]/} ${j//[a-z]/}; done | sh

 $ ls
 a000.jpg  b001.jpg  c123.jpg

 $ echo $BASH_VERSION
 3.2.25(1)-release

Ninja! Eu vou confessar que nunca tive força de vontade pra aprender esses golpes avançados de manipulação de strings em bash. Pra mim, shell é uma cola que serve pra "grudar" outros comandos. Sempre que eu preciso de algo mais complicado, como estruturas de dados ou expressões regulares, eu não penso duas vezes antes decidir por Perl.

Mas o João pagou pra ver com essa:
 > $ python
 > Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
 > [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
 > Type "help", "copyright", "credits" or "license" for more information.
 >>>> import os
 >>>> for nome in os.listdir("."):
 > ...   base, numero, ext = nome[0], nome[1:nome.find(".")], nome.split(".")[-1]
 > ...   os.rename(nome, "%s%03d.%s" % (base, int(numero), ext))
 > ...
 >>>>

 > # readability counts
Ah... que crítica sutil nesse último comentário... "Legibilidade conta."

É?

Mas Succinctness is Power!

Quando eu quero resolver uma questão com um one liner a "legibilidade" é irrelevante, porque se eu não vou salvar a solução num script, ninguém mais vai lê-la, certo? Mas vá lá... se fosse pra salvar num script eu provavelmente escreveria algo mais parecido com a sua versão em Python. Algo assim:
    opendir CWD, '.';
    foreach $nome (readdir CWD) {
        if (($base, $numero, $ext) = ($nome =~ /^(.)(\d+)\.(.*)/)) {
           rename $nome, sprintf("%s%03d.%s", $base, $numero, $ext);
        }
    }
    closedir CWD;

Hmmm... eu nem tentei quebrar o nome com operações de strings porque eu acho a expressão regular mais direta e, nesse caso, mais legível. Pra ficar ainda mais legível eu substituiria os comandos opendir, readdir e closedir por um glob pattern:
    foreach $nome (<*.jpg>) {
        if (($base, $numero, $ext) = ($nome =~ /^(.)(\d+)\.(.*)/)) {
           rename $nome, sprintf("%s%03d.%s", $base, $numero, $ext);
        }
    }

Melhor, né?

Mas ainda não está bom. Está muito... carregado, sei lá. Uma das grandes diferenças de Perl em relação a maioria das linguagens, e a Python em particular, é que não precisamos ser sempre explícitos. É mais ou menos como usar pronomes ou sujeito oculto. De início você não entende o idioma e fala assim:

- José é casado. José tem cinco filhos. Os filhos de José são todos solteiros.

Depois, você aprende a usar os pronomes e começa a falar de modo mais econômico.

- José é casado. Ele tem cinco filhos. Eles são todos solteiros.

Até que você fica realmente fluente no idioma e fala naturalmente assim:

- José é casado e tem cinco filhos, todos solteiros.

Ininteligível? Só pra quem está só começando a aprender o português. Normalmente conversamos com pessoas que são tão fluentes quanto nós, de modo que podemos, e devemos, ser econômicos e diretos. Evitando redundâncias nós não somos apenas mais diretos. Somos também mais inteligíveis (ou legíveis), porque não inserimos no discurso aquela série de nomes repetidos que acabam poluindo o texto, escondendo o conteúdo real da mensagem.

Bom, tudo isso pra justificar minha próxima versão, na qual eu suprimo a variável $nome, pois em Perl o iterador de um loop é implícito:
    foreach (<*.jpg>) {
        if (($base, $numero, $ext) = /^(.)(\d+)\.(.*)/) {
           rename $_, sprintf("%s%03d.%s", $base, $numero, $ext);
        }
    }

Se você não conhece Perl não vai saber que a expressão regular está sendo aplicada ao iterador implícito do foreach. Mas se você nunca viu Perl, esse não é o seu maior problema, né? Ah, e o $_ é o "pronome" que usamos pra nos referirmos explicitamente ao iterador dentro do loop.

Pensando bem, essas variáveis locais não estão servindo pra muita coisa além de dar nomes às partes capturadas pela expressão regular. Se fôssemos usá-las muitas vezes, vá lá. Mas pra só usarmos uma vez na próxima linha? A expressão regular já é suficientemente clara (depois adquirir alguma experiência com elas, obviamente). Que tal nos livrarmos dessas variáveis?
    foreach (<*.jpg>) {
        if (/^(.)(\d+)\.(.*)/) {
           rename $_, sprintf("%s%03d.%s", $1, $2, $3);
        }
    }

Hmmm... tá parecendo C. Em Perl é mais direto e legível interpolar as variáveis diretamente na string de formato:
    foreach (<*.jpg>) {
        if (/^(.)(\d+)\.(.*)/) {
           rename $_, sprintf("$1%03d.$3", $2);
        }
    }

Hmmm... o importante é o rename... o if é acessório. Em Perl, podemos inverter o teste e a ação, mais ou menos quando escolhemos a voz ativa ou a voz passiva por razões estilísticas. Então, vamos colocar primeiro o que interessa:
    foreach (<*.jpg>) {
        rename $_, sprintf("$1%03d.$3", $2)
            if /^(.)(\d+)\.(.*)/;
    }

Legal. Economizamos um par de chaves também, viram?

Ah... direto assim fica mais fácil perceber otimizações triviais:
    foreach (<*.jpg>) {
        rename $_, sprintf("$1%03d.jpg", $2)
            if /^(.)(\d+)\.jpg$/;
    }

Ou generalizações oportunas:
    foreach (<*.jpg>) {
        rename $_, sprintf("$1%03d.jpg", $2)
            if /^([a-z]+)(\d+)\.jpg$/i;
    }

Ficou bem legível pra mim. E pra vocês?

De qualquer modo, pelo menos isso prova que There Is More Than One Way To Do It.

Adendo: Algum tempo depois de escrever isto eu descobri o comando rename na linha de comando Linux. Com ele a solução é trivial:

    rename 's/(\d+)/sprintf("%03d", $1)/e' *.jpg

Ah... o rename é escrito em Perl. :-)

sexta-feira, 18 de abril de 2008

push @FISL9, $segundo_dia

Chegamos à PUCRS pouco antes das 9h e fui direto assistir ao YAPC::SA::2008. Cheguei lá e só vi o Randal Schwartz ($JAPH[0]) mexendo no seu laptop. Cumprimentei-o e fiquei esperando algo acontecer. Dez minutos depois chegaram o Eden e o Wallace, mas nada do Flávio Glock, que é quem normalmente lidera o encontro.

Tinha pouca gente quando o Wallace começou sua apresentação sobre o DBIx::Class, que é um módulo que implementa um mapeamento objeto-relacional. Eu não conhecia nada e fiquei um pouco decepcionado com a sua verbosidade... posso estar enganado ou comparando coisas diferentes, mas creio que já vi métodos mais diretos em Ruby.

O Eden seria o próximo a falar sobre Catalyst, que me interessava mais. Mas o Mac dele não tinha adaptador de vídeo pro projetor e ele levou uns 20 minutos pra conseguir transferir sua apresentação pro laptop do Wallace, usando meu pen drive. Tive que sair ainda no início da apresentação pra ver a do Ganeti. Na saída da sala fui tirar uma foto do grupo, que a essa altura já estava bem maior, e consegui um positivo do Randal.

Às 10h fui assistir à palestra sobre o Ganeti, proferida pelo Michael Hanselmann, do Google. Trata-se de de um cluster de virtualização desenvolvido em Python. Eu já havia assistido outra palestra sobre ele no CONISLI 2007 e cheguei a dar uma olhada. Na época, pareceu-me que ainda era um tanto imaturo. Segundo Michael, o Ganeti é usado na implementação dos serviços corporativos do Google, nos seus diversos escritórios, e não para implementar os serviços do Google.com. A arquitetura básica atual usa 20 servidores de 64-bits em um rack iniciando umas 80 instâncias, que é o termo que ele usa pra falar das VMs. Esses clusters são usados pra suportar serviços como DNS, DHCP e NTP, mas não serviços com maior demanda de desempenho, como servidores de arquivos, por exemplo.

Depois da palestra conversei com ele e perguntei qual era o problema que impedia a utilização do Ganeti pra serviços de alto desempenho e ele me disse, como eu já suspeitava, que basicamente isso se devia à ineficiência do mecanismo de sincronização de discos que ele usa atualmente, o DRBD. Eu perguntei se eles não têm planos de suportar outros mecanismos para sincronização de storage e ele me disse que estão trabalhando num backend baseado em arquivos e que, desse modo, os arquivos poderiam ficar num storage mais rápido, como uma SAN. Pra mim isso pode não ser o suficiente, pois o Xen, que é a tecnologia de virtualização que ele usa, trabalha com melhor desempenho usando raw devices. Além disso, para que os arquivos sejam acessíveis por mais de um nó do cluster eles vão precisar usar um sistema de arquivos de rede, como o NFS, ou um distribuído, como o GFS da Red Hat, mas isso só impõe mais barreiras ao desempenho geral. A melhor opção pra ganhar desempenho, a meu ver, seria implementar um backend que possa utilizar LUNs de uma SAN que sejam visíveis por todos os nós da rede. Imagino que com a maturação do código do Ganeti a implementação de uma coisa assim não seja complicada.

O roadmap para a evolução do Ganeti contempla algumas funcionalidades interessantes para a versão 1.3 que deverá sair até o final do ano. A mais interessante delas me parece ser o live migration que permitirá mover as instâncias sem precisar reiniciá-las. Além disso, eles pretendem implementar o failover automático, pois hoje ele ainda tem que ser feito manualmente.

Às 11h fui assistir à apresentação da Justiça do Trabalho sobre a migração que estão fazendo para o BrOffice.org. Pelo que entendi a migração ainda está no início, mas eles já têm várias varas de justiça pelo Brasil que já começaram a usar o BrOffice.org por conta própria, e estão usando a experiência adquirida pra diminuir os riscos da migração total, para a qual não mencionaram nenhum cronograma.

Em termos de complexidade, são 43 mil usuários com 40 mil máquinas distribuídos em 1600 varas, 26 regiões e o TST, em Brasília. Segundo Luís Fernando Pontello, que apresentou a palestra, os fatores críticos para o sucesso do projeto são divulgação, treinamento, equipamentos e patrocinadores. É importante que os usuários que irão migrar de aplicativo não sintam um impacto forte relacionado ao desempenho do novo. Por isso é importante que a diferença entre o velho e o novo seja avaliada e que os usuários recebam máquinas adequadas pra trabalhar com o novo. Os patrocinadores a que ele se refere são pessoas escolhidas a dedo dentro de cada vara que já tenham alguma afinidade com o software livre. Eles devem ser os primeiros a serem treinados e devem ser "trabalhados" para que "comprem" a idéia do projeto e funcionem como pontas de lança para a migração.

Alguém perguntou como é que eles conseguiam minimizar as "resistências" dos usuários e ele disse que o mais importante é ser bastante claro em apontar as razões da mudança, mostrando que não se trata de fazer um "voto de pobreza" e de apenas trocar um software bacana por um gratuito. É importante mostrar as economias, mas também é fundamental mostrar as outras razões de cunho estratégico e técnico pra mudança.

Pontello mencionou também outros projetos da Justiça do Trabalho relacionados ao software livre. Segundo ele, o TRT de Campinas tem um projeto chamado "estação livre" ou algo assim. Vou procurá-lo pra ver se obtenho mais detalhes a respeito.

Às 12h fui assistir à palestra "O Ministério da Saúde Mental adverte: onde há fumaça de trabaco é fogo", do Alexandre Oliva. Como sempre ele usa uma grande metáfora pra nos ajudar a pensar a questão do software livre e do software proprietário. Como eu temia, ele não conseguiu superar a do ano passado, mas não deixou de ser interessante. Durante a apresentação ele citou dois filmes e um livro que falam sobre o problema da indústria do tabaco e que servem de forte paralelo para a indústria do software proprietário: "Obrigado por Fumar", "O Informante" e o livro "O Juri". Preciso conferir o primeiro.

Às 14h assisti à palestra do Rasmus Lerdorf: Large Scale PHP. Confesso que fui levado mais pela eminência do palestrante que pelo tema da palestra. Afinal, não sou fã de PHP, mas dada a sua participação no mercado de linguagens para desenvolvimento web, seu autor deve ter muitas qualidades... e realmente tem.

O Rasmus começou dizendo que entende um pouco de português porque morou por algum tempo em Porto Alegre em 1991, quando trabalhou por aqui em uma empresa local. Isso foi uns três anos antes de ele criar o PHP... A história da criação do PHP já deve ser bem conhecida e ele fez um resumo.

Na primeira parte da palestra ele demonstrou algumas ferramentas muito interessantes pra fazer profiling de aplicações PHP: YSlow, Siege e Valgrind. A última delas é bastante famosa mas eu nunca a tinha visto em ação e fiquei bastante impressionado com a qualidade da apresentação e com o poder que ela confere ao desenvolvedor para analisar um programa C.

A segunda parte da palestra foi ainda melhor. Ele abordou a questão da segurança, ou da falta dela, nas aplicações web em geral. Sua mensagem foi clara: "nunca clique num link". Escrevendo assim não parece muito convincente, mas ele conseguiu convencer a todos mostrando um conjunto de exemplos aplicados a alguns sites daqui de Porto Alegre que ele obteve Googlando. Eu me lembrei de já ter ouvido um podcast com ele há alguns meses no qual ele falava das mesmas coisas. Alguém da platéia perguntou se a ferramenta que ele havia usado para detectar as vulnerabilidades "ao vivo" era uma tal ferramenta que ele havia desenvolvido mas que decidira não disponibilizar. Ele confirmou e explicou que não a disponibiliza basicamente porque não gosta de advogados... e teme ser acionado judicialmente caso uma leva de script kiddies passe a usar sua ferramenta pra invadir 99,9% dos sites da Internet... É... o problema é tão sério assim. Ao final da palestra ele foi ovacionado e formou-se uma enorme fila de tietes que queriam tirar fotos com ele. Sendo bastante simpático ele suportou com galhardia toda a tietagem e ficou vários minutos atendendo seus fãs. Gente fina o cara.

Às 15h assiti à palestra "The economic impact of FLOSS", do Rishab Ghosh que é membro da Open Source Initiative. Eu já havia lido o resultado de alguns de seus estudos e tinha idéia de que seria uma boa palestra. Ele procurou argumentar que o modelo de desenvolvimento colaborativo do software livre não é, como se costuma pensar, uma coisa de hobbistas e pessoas altruístas. Pelo contrário, há uma componente forte de auto interesse que pode ser estudada pela economia sem ter que apelas para modelos explicativos alternativos. Como primeiro exemplo ele citou um resultado específico de seus estudos. 70% dos entrevistados consideram que em relação ao software livre eles mais se beneficiam do que já existe do que são capazes de contribuir em retorno. Já quando são questionados sobre o que pensam dos demais participantes do movimento, menos de 50% considera que a maioria contribui mais do que obtém de retorno. Isso significa que há uma percepção equivocada de que a maioria das pessoas envolvidas com software livre sejam altruístas, mas a realidade é que a maioria delas tem a percepção de que a participação no movimento traz mais benefícios para o participante.

Outro ponto importante é a questão sobre como os desenvolvedores de software livre podem viver já que não conseguem vender o produto de seu desenvolvimento. Ocorre que apenas 6% dos desenvolvedores do mercado norte-americano trabalham produzindo software para ser vendido. Todos os outros 94% ou trabalham no desenvolvimento de software interno ou de software customizado para terceiros. E nesses dois modelos de negócio, o valor de venda do software produzido é função do tempo de desenvolvimento e não da exploração de um mercado aberto para seu produto. Por isso, ele argumenta que o impacto do software livre é insignificante em relação ao impedimento da venda do software e positivo para um número muito maior de desenvolvedores que podem contar com componentes livres para acelerar e melhorar a qualidade do produto que eles desenvolvem, permitindo que aumente a margem de lucro de venda simultaneamente ao barateamento do produto final.

Ainda outro ponto interessante é a avaliação do valor de todo o software livre disponível na Internet. Segundo ele, um estudo estimou em 12 bilhões de Euros e em 163 mil pessoas-ano o valor de todo o software livre disponível em 2005. A estimativa para 2010 era muito maior mas eu não consegui anotá-la. No todo foi uma palestra rica em informações e muito interessante, apesar de um tanto monotônica... o que fez o Mario quase roncar ao meu lado. :-)

Às 17h assisti à seção de perguntas e respostas sobre o kernel do Linux com o Theodore Ts'o. Eu já havia assistido a uma palestra dele em 2005 e confiava que seria interessante. Alguém começou perguntando pra ele se o Linux já era feature complete e quanto tempo levaria ainda para ser. Ele retrucou perguntando se o Emacs já é feature complete. :-)

Outro perguntou o que faz com que o kernel tenha um modelo de desenvolvimento tão escalável enquanto projetos bem menores às vezes entram em colapso. Em primeiro lugar, ele disse, o código do kernel é bastante modular, o que permite o desenvolvimento em paralelo e sem grandes interferências. Em segundo lugar, a utilização de ferramentas distribuídas para controle de versão de código, começando com o Bitkeeper e agora com o git, dá um poder muito grande de gerência da evolução do código para todos eles. Em terceiro lugar, milhares de desenvolvedores do kernel adquiriram uma cultura de discutir os problemas em uma lista de email que consegue suprir a falta de uma proximidade maior.

Ainda outro perguntou o que ele achava do OpenSolaris em geral e do dtrace e do zfs em particular. Ele elogiou a equi de desenvolvedores da Sun mas disse que eles ainda não conseguiram cativar um número significativo de desenvolvedores de fora da Sun, visto que a maioria dos commits do projeto ainda são realizados por engenheiros da própria Sun. Em relação ao dtrace ele disse que o Systemtap do linux está quase tão poderoso quanto seu irmão mais famoso, estando faltando apenas um maior envolvimento da comunidade para a construção de probes reutilizáveis por leigos. Em relação ao zfs, ele citou o BetterFS que é um novo sistema de arquivos sendo desenvolvido para o Linux e que deverá ser ainda melhor que o zfs.

A última palestra do dia foi uma debate muito didático e elucidativo (pelo menos pra mim) sobre a situação legal das concessões de espectro de frequências de ondas eletromagnéticas no Brasil. Aprendi que o marco regulatório brasileiro é da década de 1940 e que há muita sujeira e corrupção envolvida nas concessões. O Sergio Amadeu "levantou a galera" com seu jeito rápido e eloquente e eu gostei muitíssimo das intervenções do Gustavo Gindre, a quem eu não conhecia. Gostei particularmente de quando ele argumentou que a tecnologia não é neutra na definição dos impactos sociais que ela pode causar. Ele usou pra isso o exemplo das leis de Isaac Newton. Segundo ele, na época de Newton já existia o conceito da conservação da energia, embora isso ainda não fosse consenso entre os cientistas. Ocorre que a igreja anglicana não via com bons olhos esse princípio pois ele parecia indicar que não haveria mais lugar pra Deus na natureza. Como Newton era bastante ligado à igreja, ele fez questão de elaborar suas leis numa forma em que não precisasse invocar esse princípio. Achei muito interessante e vou procurar saber melhor sobre essa história.

Saímos da PUCRS e pedimos uma dica ao motorista de táxi que nos levou para a galeteria Via Veneto. Eu gostei muitíssimo das carnes e das massas. Quando estávamos de saída vimos chegar um grupo grande do FISL, dentre eles o Maddog Hall e o Felipe van de Wiel, do Debian.

Desta vez voltamos de táxi pro hotel. No caminho eu lhe disse que ontem havíamos voltado à pé e ele exclamou: "pelo amor de deus!".

quinta-feira, 17 de abril de 2008

push @FISL9, $first_day

Eu estava morrendo de sono ontem e apaguei às 23h45. O Mario disse que ficou acordado até depois da 1h e que teve dificuldade pra dormir por causa do barulho... do meu ronco. Melhor ele dormir antes de mim hoje.

Acordei às 6h30 e tomamos café tranqüilamente. Pegamos um táxi e chegamos à PUCRS antes das 8h30, o que parecia ser bastante cedo. Mas, ao chegarmos, vimos filas já bem grandes pra pegar o material. Fiquei mais de 1h na fila que, obviamente, era a mais lenta de todas.

As palestras das 10h não eram interessantes e eu dei uma passeada pelo setor de exposições. Há muito mais stands que em 2005 e eu achei que ficou meio apertado pra circular. Há vários stands de governo. Os maiores são os da Sun e o da Globo.com (quem diria).

Às 11h fomos assistir à palestra do Shane Coughlan, coordenador do Freedom Task Force da FSF Europe. Ele é irlandês e fala muito bem. Achei que a palestra seria sobre as diferentes licenças de software livre, mas tratou mais sobre as ações da FSFE para aumentar a visibilidade e o nível de informação sobre software livre no setor governamental europeu. Ele deixou claro que a principal missão do FSFE é educar os governos e os demais setores da União Européia e mencionou que, apesar de o nível de entendimento ser cada vez maior, ainda é necessário reforçar constantemente que o free em free software significa liberdade e não gratuidade, e que o mero acesso ao código fonte não significa que o programa seja livre ou open source, mas que a sua licença precisa garantir as liberdades básicas de usar, estudar, melhorar e distribuir o programa.

Em relação às licenças, ele disse que é fundamental entender o que elas garantem e exigem em contrapartida. Mais que isso, é preciso entender o porquê de elas serem como são para poder entender o benefício do software livre.

Ocorreu em 11/04 passado o European Licensing and Legal Workshop em Amsterdam, congregando agentes de governo e pequenas e médias empresas européias e asiáticas para discutir questões sobre o licenciamento de software livre e sobre os benefícios e riscos de sua utilização. Segundo Shane, esse evento foi um ponto de inflexão na discussão desses assuntos pois, pela primeira vez, não houve um ambiente conflituoso e todos os envolvidos estavam seriamente engajados em debater assuntos complexos e relevantes.

Às 12h fui assistir à 12ª edição dos Sapos Piramidais do professor Pedro Rezende. O título desta edição foi '"Pontes" de PI. Para onde?'. Ele falou sobre os eventos mais relevantes do último ano que afetaram ou ainda podem vir a afetar a sustentabilidade do modelo de software livre no aspecto jurídico. Foi uma palestra muito corrida e ele, como sempre, não conseguiu terminar antes de esgotar o tempo, não tendo dado tempo pra nenhuma pergunta.

O que eu achei mais interessante foi o conceito de forum shifting que, segundo ele, tem sido utilizado pelas grandes corporações pra defender seus modelos de negócio através da radicalização da legislação de propriedade imaterial. (Ele se recusa a usar o termo "propriedade intelectual" pelos motivos apontados pelo Richard Stallman.) Essa técnica consiste em abandonar um fórum de discussão quando o encaminhamento de um assunto esteja indo contra os seus interesses e tentar levar a discussão para um outro fórum. Por exemplo, é o que ocorreu na Europa quando as corporações de radio-difusão abandonaram a discussão no WIPO sobre o Tratado de Broadcasting e criaram uma nova entidade (ACTA) para reposicionar a discussão em termos mais favoráveis aos seus interesses.... é tão bacana quanto assustador.

Às 13h assisti à palestra do Arnaldo Carvalho de Melo sobre as ferramentas de depuração de binários em que ele está trabalhando. É muito interessante. As ferramentas (pahole, pfunct, codiff, etc.) usam as informações de depuração do binário ELF, que são em formato DWARF, pra tentar otimizar o leiaute das estruturas de dados visando melhor aproveitar as codelines do cache do processador e otimizar a utilização de funções inline. Essas ferramentas parecem ter tido muito valor na otimização do kernel do Linux e de outros projetos, como o KDE.

Eu não sabia, mas hoje é possível gerar as informações de depuração em um arquivo separado do binário ELF. Algumas distribuições já estão disponibilizando pacotes paralelos com esta informação. Por exemplo, o pacote "firefox" conteria os binários stripped enquanto o pacote "firefox-debuginfo" conteria os arquivos com as informações de depuração.

O nome DWARF foi "forçado" pra casar com ELF e lembrar o LOTR. Nerdisse...

Às 15h assisti a uma palestra "Uma nova Lei Autoral para o Brasil: equilíbrio entre proteção e acesso ao conhecimento" que foi apresentada por dois professores da FGV, um advogado do IDEC e um funcionário do Ministério da Cultura. Os quatro usaram diversos argumentos para demonstrar que a Lei Autoral brasileira é excessivamente restritiva e que precisa de uma atualização urgente para adequá-la à realidade de hoje em que mecanismos para cópia e disseminação de informação são ubíquos. De acordo com Sergio Branco, da FGV, o Brasil é dos poucos países "desenvolvidos" em que a lei não admite em hipótese alguma a cópia integral de uma obra. Em outros países isso é permitido para, por exemplo, permitir que uma biblioteca digitalize algum livro que esteja sendo destruído pelas traças, ou que o proprietário de um LP possa digitalizá-lo. A legislação alemã, por exemplo, permite que livros que já tenham saído de catálogo há mais de dois anos sejam copiados integralmente.

A legislação autoral brasileira, segundo eles, acaba forçando uma relação de perde-perde, pois os consumidores não têm acesso a obras das quais os próprios autores já não possam mais explorar comercialmente.

O participante do IDEC argumentou que a lei autoral fere o princípio jurídico da proporcionalidade, que diz que as penas devem ser proporcionais à gravidade do delito. Segundo ele, no Brasil, o cidadão que baixa músicas da Internet pode ser preso ao passo que há vários crimes muito mais graves que são punidos no máximo com a aplicação de uma multa.

O último a falar foi Pedro Paranaguá, que eu não conhecia mas que me impressionou pela juventude e pela clareza de idéias. O trabalho dele na FGV pode ser acompanhado no site http://www.a2kbrasil.org.br/.

Às 17h assisti à apresentação sobre a migração do site da Dicas-L para o Drupal. Infelizmente o Rubens Queiroz não pode vir. Além disso, a rede do FISL estava fora e os palestrantes não puderam mostrar o novo site e suas funcionalidades. A palestra acabou abordando as funcionalidades que foram implementadas no site e serviu pra tirar algumas dúvidas de quem estava lá e já trabalhava com o Drupal. Não me impressionou muito.

Ah, durante a citação das funcionalidades, pelo que entendi, eles disseram que a parte de envio das mensagens na newsletter não foi alterada porque são quase 30 mil destinatários e o esquema atual era suficientemente robusto. Eu não sei se o Rubens ainda usa o bulk_mailer, mas há alguns anos ele estava sofrendo pra enviar mensagens uma a uma e eu sugeri pra ele esse programa.

Às 18h fui assistir ao painel Futuros Digitais do qual deveria participar o ministro Mangabeira Unger, mas ele acabou não podendo vir. De qualquer modo foi muito interessante. O primeiro a falar foi o Marcelo D'Elia Branco que enrolou um pouco mas deixou seu recado argumentando que não é o patamar tecnológico de um país que determina a qualidade de suas relações sociais. Ele citou como exemplos de países com patamares tecnológicos evoluídos mas dos quais ele não inveja a situação social os EUA, pela exacerbação do individualismo, Cingapura, pelo regime totalitário e um outro de que não me lembro. Não sei se concordo com todos os exemplos, mas creio que ele tenha razão na sua tese.

O segundo palestrante foi o advogado Ronaldo Lemos que muito me impressionou. Ele fez mestrado em Harvard e doutorado na USP. Segundo ele, é fundamental que o Brasil crie um marco regulatório civil que defina as responsabilidades dos provedores de acesso e de conteúdo. Os EUA já têm o seu desde 1999. Enquanto não tivermos essa legislação estaremos sugeitos às mais variadas interpretações de juízes que em sua maioria não têm o conhecimento técnico e a experiência social que lhes permita avaliar corretamente casos envolvendo abusos dos meios de comunicação digitais. Ele citou um exemplo de um juíz de São Paulo que, por não ter conseguido identificar o autor de alguma calúnia postada no site de um terceiro, condenou a Lan House que foi identificada como tendo sido o ponto de acesso do infrator. Outro absurdo é o projeto de lei do senador Azeredo que pretende regulamentar criminalmente a Internet sem que tenhamos sua regulamentação civil definindo as responsabilidades dos seus usuários.

Ronaldo Lemos ainda citou um paradoxo interessante. Segundo ele, o Brasil é um dos poucos (se não o único, não me lembro) países a garantir o direito à privacidade na própria Constituição. Apesar disso, não temos leis regulamentando esses direitos. Por conta disto é que só em 2007 foram concedidos mais de 409 mil grampos telefônicos no Brasil... ainda bem que nossa privacidade é garantida!

Depois do Ronaldo quem falou foi o Pedro Paranaguá, da FGV. Ele citou vários casos em que as diferenças entre os regimes jurídicos dos países causam problemas nas relações internacionais.

Às 19h tentei assistir à palestra sobre o módulo Text::Statistics mas o palestrante estava atrasado e eu acabei indo ver a palestra do Frederico Neves, do Registro.br, sobre DNSSEC, que foi muito boa. Ele começou explicando sucintamente o funcionamento do DNS tradicional pra mostrar todas as suas vulnerabilidades. Daí ele introduziu o DNSSEC mostrando quais daquelas vulnerabilidades são resolvidas por ele. A importância do DNSSEC é que há diversos mecanismos de segurança que se baseiam no DNS, como os sistemas anti-phishing e anti-spam SPF e DKIM. Segundo ele, o problema hoje é tão sério que a maioria dos grandes bancos paga a empresas para ficarem monitorando constantemente o cache dos nameservers dos grandes provedores de acesso pra ter certeza de que não foram "poluídos" com informação inválida.

O Registro.br já implantou DNSSEC nos domínios jus.br, eng.br, eti.br e gov.br. A implantação nos domínios com.br e org.br depende ainda da homologação do NSEC3. Ocorre que o DNSSEC original define um mecanismo para que o cliente possa garantir a ausência de um registro que se chama NSEC, mas esse mecanismo permite que qualquer um consiga listar todos os registros de um domínio, essencialmente deixando publicados todos os registros de um domínio, o que é ruim do ponto de vista da segurança. O NSEC3 é uma nova forma de implementar garantia de inexistência de registro mas que não padece deste problema. Segundo Frederico, dentro de poucos meses poderemos contar com o DNSSEC no com.br e no org.br.

Ele fez uma exortação para que todos pensem seriamente em adotar essa tecnologia pois, quando estiver adotada em larga escala, poderá resolver grande parte dos problemas que hoje enfrentamos na Internet em relação à falsa identidade de servidores.

No final ele citou o BIND e o NDS como servidores DNS que estão em vias de implementar do NSEC3 totalmente. Eu perguntei a ele sobre o PowerDNS e ele disse que este servidor não implementa toda a especificação do DNSSEC. Eu disse a ele que recentemente me mostraram esse artigo que mostra que o PowerDNS é muito mais escalável que o BIND mas ele não acreditou. Segundo ele, o Registro.br já fez diversos testes com o PowerDNS e não constatou esta diferença. Eu fiquei de lhe enviar o link pra ele poder comentar.

Ainda sobre o PowerDNS, ele disse que a maior vantagem dele é que ele pode utilizar um banco de dados para manter os registros, coisa que o BIND não permite. Os registros do BIND ficam em arquivos texto. Mas, o Registro.br implementou um mecanismo de manutenção dos registros, que ficam em banco de dados, e que são espalhados para várias instâncias do BIND. Esse mecanismo deverá ser divulgado como software livre dentro de uns seis meses.

A última palestra do dia foi sobre as novidades do Plone3. Ela foi apresentada por dois caras da empresa ThreePointsWeb, que se especializa na criação de sites, treinamento e consultoria em Plone. Os caras parecem ser bons, mas a palestra foi cansativa. Segundo eles, o Plone é o único CMS livre que é considerado na categoria ECM, ou Enterprise Content Management.

Cansados e famintos fomos todos nos empanturrar na churrascaria Na Brasa, que foi considerada como a melhor da cidade pela revista Veja. Foi uma brasa, mora? Tanto que ao sairmos de lá o Daniel deu a idéia incrível de virmos a pé pro hotel. Afinal, seriam apenas cinco quadras. Só não raciocinamos direito e não previmos que tipo de quadras seriam elas... Eu disse que o hotel fica ao lado da rodoviária? E vocês conhecem alguma rodoviária que fique num bairro "viável" pra se passear a noite? ... Nem eu. A cada esquina eu dava uma olhada pra todos os lados e contava pra ver se ainda estávamos todos juntos. Felizmente chegamos todos vivos. O único incidente digno de nota foi uma topada que o Mario deu na calçada e quase foi de nariz no chão. É que ele estava andando e "apreciando a fauna" do outro lado da avenida.... hehe.

Amanhã eu volto é de táxi.

quarta-feira, 16 de abril de 2008

FISL 9.0

Cá estou em Porto Alegre pra mais um FISL. Dessa vez ele será de novo no campus da PUCRS, assim como em 2005 quando estive aqui pela primeira vez. No ano passado foi na FIERGS, que é muito mais longe da cidade.

Vim com o Mario Teixeira e com mais dois colegas do CPqD: Daniel Pataca e Hugo Lavalle. Saímos de Viracopos às 15h15 e o vôo correu sem maiores incidentes e no horário, o que foi uma grata surpresa. Durante o embarque encontramos o Alexandre Oliva que estava vindo pra cá com sua esposa e sua filha. Comentei com o Hugo que vai ser difícil ele superar a palestra sobre Matrix que ele apresentou no ano passado, mas quem sabe?

O Oliva se lembrou de que eu o havia alertado sobre o certificado digital do seu blog que estava expirado e me disse que acabou regerando-o ontem. Mas eu estava meio fora de contexto e acabei me esquecendo de perguntar pra ele por que é que ele usa links https no feed RSS do blog? Se eles fossem http não haveria problema algum com certificado... vou ver se pergunto pra ele durante o evento.

Estamos todos no hotel Ritter, próximo à rodoviária e não muito longe da PUCRS. O hotel é melhor que aquele em que fiquei no ano passado. Tem até wireless no quarto, mas o primeiro que pegamos (523) ficava no final do corredor e o sinal era muito baixo. Fomos até a recepção depois do jantar pra perguntar se podíamos trocar. O recepcionista verificou e disse que ficaríamos com o quarto 309, mais próximo ao access point. Depois disso ele me encarou, baixou a voz e disse que o novo quarto é triplo mas que ele iria fazer pela mesma diária. Eu disse "que ótimo", agradeci e subimos pra fazer a mudança.

Chegando no novo quarto vimos que apesar de ter uma cama a mais ele era um pouco menor... e a vista dá pra uma parede cheia de janelas... pelo menos o sinal da rede é melhor e está dando pra usar.

Mas o pior é que eu estou usando um laptop do tempo do onça. É o mesmo que usei nos dois FISLs anteriores e acabo de me lembrar que no ano passado eu jurei que não o traria mais... esqueci. Ele é extremamente lento e o firefox já capotou algumas vezes sem razão aparente... Juro que é a última vez.

Combinamos de tomar café amanhã às 7h30 pra chegarmos cedo no evento e evitarmos as filas. Mal posso esperar...

segunda-feira, 7 de abril de 2008

Desafio regex

Meu amigo Rogério Zamboim me desafiou a resolver um problema com uma expressão regular. Desconfio que isso estava lhe causando insônia e ele queria transferi-la pra alguém... De qualquer modo, o desafio acabou sendo bem interessante.

O problema é validar um campo cujo conteúdo deve ser uma seqüência de dígitos, de 1 a 8, separados por barras invertidas, em ordem monotônica decrescente. Exemplificando, os seguintes valores são válidos para o campo:
8\7\6\5\4\3\2\1
8
8\1
8\7\2
1
2\1
7\5\3
Já os seguintes valores são inválidos:
8\
\7
8\6\
\2\1
6\\2
7\6\6\2
6\2\5
Confesso que de cara dei um tiro n'água e enviei-lhe a seguinte "solução", obviamente errada:


/^[1-8](?:\\[1-7])?(?:\\[1-6])?(?:\\[1-5])?(?:\\[1-4])?(?:\\[1-3])?(?:\\[1-2])?(?:\\1)?$/


O problema é que ela não garante que os dígitos são decrescentes. Por exemplo, a string "4\5" é aceita por ela.

Pensando melhor, ficou claro que expressões regulares "puras" não têm poder de expressão suficiente pra especificar a regra de validação de modo conciso. Isso porque elas não conseguem expressar a ordenação dos dígitos. Não se trata de um impossibilidade teórica, mas prática. Uma solução puramente regular envolveria a descrição explícita de todas as possibilidades, resultando numa expressão enorme. Algo como:


/^(?:[1-8]|[2-8]\\1|[3-8]\\2|...|[3-8]\\2\\1|[4-8]\\3\\1|.../


Convencido de que não seria possível uma solução direta, resolvi usar uma expressão regular apenas para garantir a forma básica, i.e., uma seqüência de dígitos separados por barras invertidas, e deixar a verificação da ordem para um código posterior. O melhor que consegui foi o seguinte:


sub validate_loop {
my ($string) = @_;
my $top = 9;
for my $val (split /\\/, $string) {
return 0 unless $val =~ /^[1-8]$/;
return 0 unless $top > $val;
$top = $val;
}
return 1;
}


Esta função recebe uma string com o valor do campo. A variável $top contém sempre o valor máximo que o próximo dígito pode conter mais um, e começa com 9, já que o primeiro dígito pode estar entre 1 e 8. O loop quebra a string nas barras invertidas e verifica se o que há entre elas são dígitos entre 1 e 8 e se eles são menores que $top, atribuindo a $top o valor do próximo dígito.

É razoável, mas não satisfatório. Usa duas expressões regulares e faz muitos testes separados... Não estava muito bom.

Fiquei matutando uns dois dias sobre isso e pensando se dentre as várias extensões que Perl oferece além dos operadores básicos de expressões regulares não haveria algum que me permitisse construir uma solução mais sucinta. Relendo a documentação deparei-me com o operador "(?{code})", que permite inserir código no meio de uma expressão regular. Hmmm... parecia útil, mas eu nunca havia usado algo assim.

Depois de algumas tentativas frustradas acabei bolando a seguinte solução:


sub validate_re {
my ($string) = @_;
our ($dec, $last) = (1);
return ($string =~ /^([1-8])(?{$last=$^N})(?:\\([1-8])(?{$dec=0 if $last <= $^N; $last=$^N}))*$/) && $dec;
}


A expressão regular ficou maior por causa do código embutido dentro dela. Remova mentalmente os operadores (?{...}) e você verá que ela está simplesmente verificando se a string consiste em uma seqüência de dígitos separados por barras invertidas.

No primeiro operador de código, a variável $last recebe o valor do primeiro dígito da string. (A variável implícita $^N lembra o valor da última captura por parêntesis.) No segundo operador, usamos seu valor para verificar se o próximo dígito é menor que o anterior e atribuímos o novo dígito a ela.

A variável $dec mantém o estado da verificação de ordem. Ela começa como 1 e recebe 0 caso o segundo operador de código detecte que há algum dígito fora de ordem monotônica decrescente.

Eu demorei um bom tempo pra chegar à conclusão de que essas duas variáveis tinham que ser globais (declaradas com "our"). Se elas são locais (declaradas com "my") não funciona. A documentação não é clara a esse respeito e eu desconfio que seja um bug do próprio interpretador Perl, mas não tenho certeza.

A função acaba retornando a conjunção da avaliação da expressão regular com o valor final de $dec.

Pronto, agora eu posso dormir em paz.

(Não é verdade... a (des)formatação dos scripts acima está me deixando nervoso. Vou tentar resolver a questão usando o SyntaxHighlighter, mas não hoje.)


Passei a usar o SyntaxHighlighter, mas como ele ainda não tem suporte oficial pra Perl não ficou ainda muito bonito. Tem gente trabalhando nisso...

domingo, 23 de março de 2008

A Incrível


http://stulzer.net/blog/2008/03/18/a-terrivel-semana-que-richard-stallman-ficou-na-minha-casa/

domingo, 9 de março de 2008

Pai, você tem que ser forte

Sou fã do Nerdcast, um podcast muito divertido, feito por uns nerds cariocas. Eles falam um pouco de tudo o que interessa: filmes, livros, história, jogos, etc.

O episódio 101, sobre Traumas de Infância, foi um dos mais engraçados. Melhor ainda foi uma carta de um ouvinte, lida no episódio 102, na qual ele contou um trauma da sua infância causado pelo seu pai. Eu não vou contá-lo aqui pra não estragar pra vocês. Baixem o episódio e ouçam. A leitura das cartas é logo no início do episódio.

Acontece que eu achei a história tão engraçada que fui logo contar pro meu filho. Depois de contá-la eu fiz questão de que ele a escutasse o iPod. Na manhã seguinte eu fiz a mesma coisa com a minha esposa, que não achou tanta graça. Tenho uma teoria de que as mulheres têm uma deficiência no seu senso de humor, mas isso não vem ao caso agora.

Eu estava tão empolgado com a graça da história que ficava repetindo uma frase que o pai do rapaz teria dito pra ele usando uma voz bem grave:

- Filho, você tem que ser forte. Sua mãe vai virar peixe.

Eu repetia a frase e dava risada.

Naquela manhã era minha vez de levá-los pra escola, dando carona pra um coleguinha do meu filho. É óbvio que eu não podia perder a chance de contar pra mais um e recomecei a repetir a frase no carro. Foram várias vezes.

Chegando na escola todos saímos do carro. Eu encarei meu filho mais uma vez e repeti:

- Filho, você tem que ser forte. Sua mãe vai virar peixe.

Ele me encarou e falou o seguinte engrossando a voz:

- Pai, você tem que ser forte. Essa piada já perdeu a graça.

domingo, 24 de fevereiro de 2008

Sorvetou!

Minha sobrinha ligou querendo falar com minha filha. Encontrei-a assistindo TV enquanto minha esposa penteava-lhe cabelos. Eu disse a ela que era a prima e entreguei-lhe o telefone. Ela colou-o ao ouvido direito e a mãe reclamou que assim não dava pra continuar penteando...

Vocês sabem o quão difícil é conseguir a atenção de uma criança de cinco anos quando ela está vendo TV, não? É pior ainda quando além dos olhos ela tem os ouvidos ocupados com o telefone.

Eu disse e repeti algumas vezes:

- Troca o telefone de lado.

Mas não adiantou. Foi só quando eu elevei a voz acima do volume da TV que ela se dignou a olhar pra mim. Eu aproveitei a chance e repeti mais uma vez:

- Troca o telefone de lado!

Ela acenou com a cabeça, indicando que havia entendido e pediu pra prima:

- Espera aí, espera um pouco...

Daí ela virou o telefone 180º e colou as costas dele ao mesmo ouvido dizendo:

- Pode falar, prima!


Enquanto eu me dobrava de rir a mãe ainda conseguiu dizer:

- Sorvetou!