Faz tempo que meus dois filhos implicam com o meu hábito de vestir a camisa por dentro da calça. Como sempre, eu me divirto. Há uns dias minha filha Juliana (de seis anos) me veio com essa:
- Pai, por que é que você põe a camisa por dentro da calça?
- Por que o papai acha mais confortável.
- Por que é que você prefere o conforto à beleza?
(.... pausa pra pensar numa boa resposta...)
- Acho que é porque eu sou velho!
Camisa por dentro da calça
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.
Nerdiness
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. :-)
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 seqüência de dígitos e terminando na extensão .jpg. Por exemplo:
$ ls
a0.jpg b1.jpg 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:
Ah... que crítica sutil nesse último comentário... "Legibilidade conta."
> $ 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
É?
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.
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!".
Assinar:
Postagens (Atom)
