[Rio-pm] MakeFile
Alexei Znamensky
russoz em gmail.com
Quinta Junho 7 17:48:59 PDT 2012
Por isso não, o DataFlow na sua última versão está um cágado, if you catch
my drift, mas não pude consertar ainda.
2012/6/7 breno <breno em rio.pm.org>
> Incidentalmente, isso acabou de aparecer no meu feed ;-)
>
>
> http://my.opera.com/cstrep/blog/2012/06/07/dist-zilla-y-u-suddenly-no-work-anymore
>
> []s
>
> -b
>
> 2012/6/7 Alexei Znamensky <russoz em gmail.com>:
> > Bom, lá vou eu fazer papel de advogado do diabo :-)
> >
> > 2012/6/3 breno <breno em rio.pm.org>
> > [...]
> >
> >>
> >> Acho que são problemas distintos. O Dist::Zilla foi criado para
> >> facilitar a criação de novas distribuições do zero, bem como a
> >> atualização dessas distribuições dentro do seu workflow (git, cpan,
> >> etc). Isso envolve a geração automática de um montão de coisas,
> >> inclusive de um Makefile.PL usando o builder que você escolher no seu
> >> ~/.dzil/profile, o que é *muito* legal. Mas...
> >
> >
> > Acho que a parte de criar distribuições do zero veio até depois, se não
> me
> > falha a memória. Até porque já havia o Module::Starter. Eu pessoalmente
> acho
> > que a melhor parte do Dist::Zilla não são essas, mas sim o fato de que
> você
> > não tem de fazer "boilerplate maintenance" - coisas que estão aparecendo
> > neste thread como escrever README, escrever Changelog, etc.. - toda vez
> que
> > for soltar uma versão nova da sua distribuição.
> >
> > Antes de entrar nos detalhes abaixo, apenas um comentário: todo o
> > comportamento do Dist::Zilla é configurável, então nenhum dos
> comportamentos
> > descritos abaixo é obrigatório.
> >
> >> Minhas críticas quanto ao Dist::Zilla são muito simples:
> >>
> >> * Ele altera o seu código fonte, o que para mim dificulta a
> >> depuração de bugs ("erro na linha X" e lá vamos nós abrir a versão
> >> instalada pra achar o bug e o original para consertá-lo);
> >
> >
> > "dzil build" gera um build da sua distro no subdiretorio
> > ./Sua::Distrib-versao, onde você pode testar e debulhar seus arquivos.
> >
> > nos meus módulos com Dist::Zilla, até onde lembro, não tem alteração de
> > código-fonte Perl (e seus números de linha). A seção de POD no fim do
> > arquivo é quase toda gerada, entretanto.
> >
> > Minto, lembrei-me depois aqiu que eu uso o plugin PerlTidy, que executa o
> > Perl::Tidy em todo o código. Apesar de isso potencialmente dificultar a
> > colaboração de outros autores, eu acho que:
> >
> > 1) Não custa nada, de vez em quando eu rodar um Perl::Tidy contra todo o
> meu
> > código e dar um commit.
> > 2) Se eu não fizer isso, o meu códigio vai sair bem formatado mesmo assim
> > 3) A facilidade de leitura que o código bem formatado dá supera, na minha
> > opinião, a dificuldade em encontrar uma linha de código
> >
> >>
> >> * Com arquivos auto-gerados (incluindo testes e Makefile.PL), ele
> >> dificulta a colaboração de autores, que precisam instalar o Dzil e
> >> todos os plugins que você usa no seu projeto, do contrário não vão
> >> conseguir testar o patch que fizeram pois não dá pra montar a sua
> >> distribuição. Isso é facilmetne resolvido distribuindo o Makefile.PL
> >> auto-gerado junto com a sua distribuição, mas não vejo isso acontecer;
> >
> >
> > "dzil authordeps | cpanm" instala tudo o que você precisa.
> >
> > O que talvez ajudasse mais seria, au rodar o dzil e encontrar um Plugin
> ou
> > Bundle que não está instalado no sistema, ao invés de dar erro,
> perguntar se
> > quer instalar e já resolver tudo.
> >
> >>
> >> * A geração de stubs de documentação genérica aparentemente
> >> desestimula autores a escrever documentação decente; Há um módulo
> >> muito bacana chamado Pod::Plexus sendo desenvolvido pelo Rocco Caputo,
> >> mas ainda assim o problema persiste;
> >
> >
> > O dzil não gera stubs de documentação de subs ou do código em si. O que
> ele
> > gera de stubs são as seções de um POD de Perl, e algumas das seções
> > "boilerplate" são preenchidas automagicamente, por exemplo:
> >
> > NAME
> > VERSION
> > SUPPORT
> > AUTHOR
> > COPYRIGHT
> > DISCLAIMER OF WARRANTY
> >
> > Ele não gera documentação de um método para o qual você não escreveu
> nada.
> > Assim, a decência ou indecência da documentação depende, como sempre
> > dependeu, somente do programador. Não vejo como isso esteja sendo
> estimulado
> > ou desestimulado pelo Dist::Zilla.
> >
> > Muito pelo contrário, com o uso de alguns plugins no Dist::Zilla, alguns
> > testes são incluídos na distribuição para melhorar a qualidade da mesma,
> > incluindo o testes de POD, que verificam se existe documentação gerada
> para
> > cada subrotina, caso não haja, ele não permite o release da distrbuição.
> >
> >> * A quantidade boçal de plugins e configurações acaba estimulando a
> >> criação de bundles com plugins específicos de um autor. Se vc vai
> >> contribuir num projeto do Russo e vê um dist.ini contendo [@RUSSOZ], o
> >> que que isso faz? E se um dos plugins (que são específicos de cada
> >> autor) não funcionar no seu sistema? Temos aí um caso em que o próprio
> >> Dist::Zilla foi vítima de facilitadores para criação de configurações
> >> padrão;
> >
> >
> > O bundle faz aquilo que o autor da distribuição considerou importante que
> > fosse feito. Sou totalmente a favor de se ter alguns Bundles
> padronizados,
> > mas não sei se isso altera a crítica. Os bundles são módulos por si só,
> > então é possível abrir o mesmo e verificar o que eles fazem - não que
> você
> > precise saber para usar.
> >
> > se um dos plugins não funcionar no seu sistema, faz-se aquilo que sempre
> se
> > faz quando um módulo não funciona no sistema: se você estiver de bom
> humor,
> > investiga e manda um patch, se estiver mais ou menos voce apenas manda um
> > bug report para o owner, e se estiver de mal humor, desencana de fazer o
> > patch da distribuição-que-usa-o-dist-zilla, manda um report pro owner e
> fala
> > pra ele corrigir, e se estiver muito puto da vida desencana de tudo isso
> e
> > dane-se.
> >
> > lembrando que o dist-zilla (e seus plugins em quantidades boçais) não são
> > necessários para voce instalar o módulo, são usados APENAS para fazer o
> > build do pacote de distribuição, isto é, só será realmente necessário
> pelo
> > autor ou se você quiser fazer algum patch para o autor.
> >
> >> * O dzil é muito voltado para subir módulos no CPAN e de fato é
> >> literalmente um comando para subir a nova versão. Mas isso acaba, do
> >> meu ponto de vista, facilitando a publicação equivocada de módulos, o
> >> que é particularmente preocupante se vc não quer essa distribuição no
> >> CPAN ou se ela é uma distribuição delicada/popular e vc precisa de uma
> >> certa garantia de qualidade ou pode quebrar sem querer o código dos
> >> outros. Tudo isso pode ser resolvido tomando cuidado e com boas
> >> práticas de desenvolvimento, mas exigem treinamento e disciplina.
> >
> >
> > O dzil automatiza testes também, então toda a "garantia" de qualidade que
> > você poderia ter sem ele, você pode ter com ele. Na verdade, uma vez que
> eu
> > criei o meu bundle de plugins, que inclui varios testes para qualidade de
> > código, eu tenho tantas garantias quanto eu sempre tive sem ele.
> >
> > Seguindo a sua lógica, o script de cpan-upload é tão ruim quanto. But
> then
> > again, eu acho que você está atirando no mensageiro. O CPAN é, por sua
> > natureza, um repositório aberto, que aceita tantos e quantos módulos
> > houverem para se publicar. Se eu, num ataque de loucura insana, decidir
> > fazer um Denial-of-service no CPAN, eu poderia simplesmente gerar
> > distribuições aleatórias e subí-los com o cpan-upload - não sei qual
> seria o
> > limite até onde eu poderia fazer isso, mas em algum momento o indexador
> e/ou
> > o ftp do CPAN iriam abrir o bico (imagine os mirrors puxando milhares de
> > módulos a mais, da noite pro dia). O *** CPAN *** permite que módulos
> sejam
> > subidos facilmente, não é o Dist::Zilla.
> >
> > Não exatamente, mas seguindo emuma linha parecida com a que conversamos
> no
> > outro dia, se houvesse um **outro** repositório, onde neguinho não pode
> sair
> > colocando qualquer coisa, isso sim daria alguma garantia.
> >
> >>
> >> Para o problema em questão ("como gerar uma distribuição perl"), a
> >> criação do Makefile.PL usando a API do Module::Install me parece ser
> >> mais fácil e com uma curva de aprendizado muito menor que a
> >> criação/configuração do dzil.ini. Mas podemos concordar em discordar
> >> :P
> >
> >
> > Podemos, e continuamos assim. :-)
> >
> > Ao usar o Module::Install, você tem de gerar Makefile.PL e mais um monte
> de
> > outras coisas, CADA VEZ que for soltar uma versão nova da distribuição.
> Com
> > o Dist::Zilla, você automatiza essa parte - inclusive depois de dominar
> os
> > Bundles, você automatiza a inclusão de incontáveis suítes de teste
> prontas
> > nas suas distribuições.
> >
> > my $two_cents;
> >
> > []s,
> > Russo
> >
> >>
> >> Dito isso, continuo afirmando que o Dist::Zilla é uma ótima solução
> >> para quem tem os problemas que ele se propõe a corrigir. Da minha
> >> parte, prefiro usar a combinação "module-starter" e "cpan-upload" =)
> >>
> >>
> >> []s
> >>
> >> -b
> >>
> >> >>
> >> >>
> >> >> ABS()
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> 2012/6/3 Alexei Znamensky <russoz em gmail.com>
> >> >>>
> >> >>>
> >> >>> 2012/6/3 breno <breno em rio.pm.org>
> >> >>>>
> >> >>>> Ao contrário do Stan, eu não recomendo o Dist::Zilla. Ou pelo menos
> >> >>>> não pra vc que está começando. Pode ser uma ótima ferramenta para
> >> >>>> alguns autores, mas se vc não entende a "mágica" que acontece por
> >> >>>> trás, pode se confundir e te deixar mais tempo
> configurando/depurando
> >> >>>> as ferramentas em vez de trabalhando no(s) seu(s) próprio(s)
> >> >>>> módulo(s).
> >> >>>
> >> >>>
> >> >>> Ao contrário do Garu, eu não des-recomendo o Dist::Zilla. Eu acho
> que
> >> >>> é
> >> >>> uma ferramenta fantástica para esconder do desenvolvedor de
> >> >>> distribuições os
> >> >>> detalhes de um build. Ao invés de tentarmos difundir ao máximo os
> >> >>> detalhes,
> >> >>> para que todos - teoricamente - saibam o que fazer quando houver um
> >> >>> problema, acho que é muito mais saudável para todos que os detalhes
> >> >>> sujos
> >> >>> fiquem o mais escondidos e automatizados o possível, simplificando a
> >> >>> vida de
> >> >>> todos, mas principalmente de quem está começando.
> >> >>>
> >> >>> Filosofando um pouco mais sobre o assunto, na rabeira de uma longa
> >> >>> conversa que eu e o Breno tivemos por telefone outro dia, eu fico
> >> >>> pensando
> >> >>> que "More Than One Way To Do It" é muito bom como possibilidade,
> como
> >> >>> para
> >> >>> ser usado em caso de exceção. Não deveria ser a regra. É muito bom
> que
> >> >>> haja
> >> >>> 2,3,4, 5 formas diferentes de expressar orientação a objeto,
> contanto
> >> >>> que
> >> >>> uma delas fosse uma "regra" e as outras fossem casos de exceção,
> >> >>> aplicados
> >> >>> para necessidades específicas (e de preferência bem definidas, se
> não
> >> >>> for
> >> >>> pedir muito). É muito bom estarmos todos produzindo e usando código
> >> >>> livre, e
> >> >>> se eu quiser mudar algo eu posso simplesmente alterar e fazer o que
> eu
> >> >>> quiser, mas ó céus cada módulo que eu for fuçar é uma caixinha de
> >> >>> surpresas.
> >> >>> Uns são feitos em Moose, outros em Mouse, tem um novo agora que eu
> nem
> >> >>> gravei o nome, tem os caras que fazem o bless na mão, e tem os caras
> >> >>> que
> >> >>> fazem magia negra. Ou seja, se eu quiser ser um bom (=bondoso,
> >> >>> cooperativo,
> >> >>> ativo, colaborativo, etc..) programador Perl, eu preciso ser fluente
> >> >>> em uns
> >> >>> 5 ou 6 tipos diferentes de expressar a mesma idéia. Ao invés de
> poder
> >> >>> contar
> >> >>> que algo vai ser de um jeito (ou de outro), e seguir adiante, e
> >> >>> produzir 5
> >> >>> ou 6 idéias novas.
> >> >>>
> >> >>> Fala-se, volta e meia, sobre produtividade em Perl e em Java, o
> >> >>> boilerplate code em Java é muito grande, etc.., mas toda vez que
> eles
> >> >>> (javeiros) precisam mexer em código dos outros, existe um padrão
> >> >>> mínimo de
> >> >>> consistência esperado (claro, sempre há quem ferre com isso, em
> >> >>> qualquer
> >> >>> idioma). Enquanto que, mexer em código dos outros, em Perl, como eu
> >> >>> disse, é
> >> >>> um Kinder Ovo. You never know what you gonna get. Talvez esse seja o
> >> >>> motivo,
> >> >>> na minha humirde opinião, pelo qual, eu percebo mais programadores
> >> >>> Perl no
> >> >>> perfil "lobo solitário" do que em Java, por exemplo. É mais fácil às
> >> >>> vezes
> >> >>> fazer um novo que entender o dialeto que o outro cara utiliza.
> >> >>>
> >> >>> my $0.02;
> >> >>>
> >> >>>>
> >> >>>> Respondendo a sua pergunta, os arquivos Makefile.PL existem para a
> >> >>>> criação de "distribuições", que podem conter um ou mais módulos
> (além
> >> >>>> de scripts e outros arquivos). Quando vc faz uma distribuição, não
> >> >>>> tem
> >> >>>> problema se os módulos dentro dela dependerem de outro, contanto
> que
> >> >>>> esse outro também esteja dentro da distribuição (mas tenha cuidado
> >> >>>> com
> >> >>>> dependências circulares!).
> >> >>>>
> >> >>>> Há 3 construtores populares:
> >> >>>>
> >> >>>> * ExtUtils::MakeMaker, a.k.a. EUMM (que vc já citou)
> >> >>>> * Module::Build, a.k.a MB
> >> >>>> * Module::Install, a.k.a. MI
> >> >>>>
> >> >>>> Embora o EUMM esteja no core, o M:I tem uma DSL bem fácil de usar
> e é
> >> >>>> utilizado em projetos de grande porte como Catalyst.
> >> >>>>
> >> >>>> Digamos que vc tenha a seguinte estrutura de módulos:
> >> >>>>
> >> >>>> lib/
> >> >>>> lib/MeuModulo.pm
> >> >>>> lib/MeuModulo
> >> >>>> lib/MeuModulo/Modulo1.pm
> >> >>>> lib/MeuModulo/Modulo2.pm
> >> >>>>
> >> >>>> e queira criar uma distribuição chamada "Minha-Dist" contendo isso
> >> >>>> tudo. A sintaxe do seu Makefile.PL é muito simples:
> >> >>>>
> >> >>>> ---------------8<---------------
> >> >>>> use inc::Module::Install;
> >> >>>>
> >> >>>> name 'Minha-Dist';
> >> >>>> all_from 'lib/MeuModulo.pm';
> >> >>>>
> >> >>>> WriteAll;
> >> >>>> --------------->8---------------
> >> >>>>
> >> >>>> Pronto. Fácil, não? Ao rodar "perl Makefile.PL" ele vai gerar
> alguns
> >> >>>> arquivos pra vc. Depois digite "make manifest" e "make dist" e vc
> >> >>>> terá
> >> >>>> um Minha-Dist-0.01.tar.gz te esperando, pronto pra ser instalado =)
> >> >>>>
> >> >>>> Algumas observações sobre o Makefile.PL acima:
> >> >>>>
> >> >>>> * "name" indica o nome da distribuição. A convenção é que vc use o
> >> >>>> mesmo nome do seu módulo base, o principal da sua distribuição (e
> que
> >> >>>> provavelmente a maioria das pessoas vai usar primeiro). No seu
> caso,
> >> >>>> suponho que o melhor "name" para a sua distribuição seria
> >> >>>> "MeuModulo".
> >> >>>>
> >> >>>> * "all_from" indica de onde o Makefile.PL deve extrair informações
> >> >>>> como versão, licença, autor, resumo, etc. Ele extrai essa
> informação
> >> >>>> de variáveis especiais de módulos (como "our $VERSION") e da
> >> >>>> documentação - então não esqueça de incluir os campos pertinentes
> na
> >> >>>> documentação (sempre uma boa prática!) ou terá que inclui-los
> >> >>>> explicitamente no Makefile.PL.
> >> >>>>
> >> >>>> Digamos que os módulos da sua distribuição dependam dos seguintes
> >> >>>> módulos EXTERNOS: File::Spec e Carp. Digamos ainda que, embora não
> >> >>>> seja uma dependência direta, se o usuário tiver instalado o módulo
> >> >>>> Data::Printer o seu programa consegue fazer alguma outra coisa
> >> >>>> bacana,
> >> >>>> então embora não seja obrigatório vc gostaria de recomendar o
> >> >>>> Data::Printer. Adicionar essas dependências no Makefile.PL é
> simples,
> >> >>>> ele fica assim:
> >> >>>>
> >> >>>> ---------------8<---------------
> >> >>>> use inc::Module::Install;
> >> >>>>
> >> >>>> name 'Minha-Dist';
> >> >>>> all_from 'lib/MeuModulo.pm';
> >> >>>>
> >> >>>> requires 'File::Spec' => 0;
> >> >>>> requires 'Carp' => 0;
> >> >>>>
> >> >>>> recommends 'Data::Printer' => 0.3;
> >> >>>>
> >> >>>> WriteAll;
> >> >>>> --------------->8---------------
> >> >>>>
> >> >>>> O número depois da "=>" indica a versão mínima do módulo, usamos
> zero
> >> >>>> (0) para indicar que qualquer versão serve.
> >> >>>>
> >> >>>> Com isso acho que vc já tem o suficiente. Não esqueça de criar um
> >> >>>> diretório "t" na raiz da sua distribuição para colocar os testes de
> >> >>>> seus módulos!! Mais sobre o M:I vc encontra na documentação
> >> >>>> (https://metacpan.org/module/Module::Install)
> >> >>>>
> >> >>>> Obs: quando criamos um novo módulo, há alguns "boilerplates" que
> >> >>>> criam
> >> >>>> as estruturas e documentações básicas para vc. Eu particularmente
> >> >>>> gosto do Module::Starter, com o plugin Module::Starter::PBP (mas eu
> >> >>>> modifico os templates em ~/.module-starter/PBP para conter o
> >> >>>> esqueleto
> >> >>>> que uso). Assim, basta escrever na linha de comando:
> >> >>>>
> >> >>>> $ module-starter --module="Meu::Novo::Modulo"
> >> >>>>
> >> >>>> e ele cria tudo para mim.
> >> >>>>
> >> >>>> Quando vc estiver acostumado a criar suas distribuições e entender
> o
> >> >>>> processo, vai começar a ficar preguiçoso. Aí sim, dê uma olhada no
> >> >>>> Dist::Zilla e veja se ele é para vc =)
> >> >>>>
> >> >>>>
> >> >>>> []s
> >> >>>>
> >> >>>> -b
> >> >>>>
> >> >>>> 2012/6/2 Stanislaw Pusep <creaktive em gmail.com>:
> >> >>>> > A resposta é: Dist::Zilla.
> >> >>>> > Pode parecer chatinho de aprender, mas, uma vez sabendo o básico,
> >> >>>> > criar
> >> >>>> > módulo com Makefile.PL completo e suíte de testes é dois palitos!
> >> >>>> > Recomendo:
> >> >>>> >
> >> >>>> > http://sao-paulo.pm.org/artigo/2011/OhnoItsDistZilla
> >> >>>> > http://sao-paulo.pm.org/equinocio/2011/set/2
> >> >>>> >
> >> >>>> > ABS()
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > 2012/6/2 Aureliano Guedes <guedes_1000 em hotmail.com>
> >> >>>> >>
> >> >>>> >> Ola,
> >> >>>> >> Monges.
> >> >>>> >>
> >> >>>> >> Eu estou tentando gerar um MakeFile.PL mas estou com um
> problema.
> >> >>>> >> Eu andei lendo, inclusive alguns materiais do Hernan Lopes mas
> >> >>>> >> ficou
> >> >>>> >> uma
> >> >>>> >> pergunta.
> >> >>>> >>
> >> >>>> >> Quando eu tenho varios modulos que na verdade sao dependencia de
> >> >>>> >> outro
> >> >>>> >> modulo.
> >> >>>> >> exemplo:
> >> >>>> >> MeuModulo.pm,
> >> >>>> >> MeuModulo/Modulo1.pm,
> >> >>>> >> MeuModulo/Modulo2.pm.
> >> >>>> >>
> >> >>>> >> Como faco?
> >> >>>> >>
> >> >>>> >> Nao achei nenhuma opcao no ExtUtils::MakeMaker.
> >> >>>> >>
> >> >>>> >> Desde ja, obrigado.
> >> >>>> >> Att,
> >> >>>> >>
> >> >>>> >> Aureliano Guedes
> >> >>>> >>
> >> >>>> >> PS: Desculpem a falta de acentos, o teclado esta desconfigurado.
> >> >>>> >>
> >> >>>> >> _______________________________________________
> >> >>>> >> Rio-pm mailing list
> >> >>>> >> Rio-pm em pm.org
> >> >>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > _______________________________________________
> >> >>>> > Rio-pm mailing list
> >> >>>> > Rio-pm em pm.org
> >> >>>> > http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>>> _______________________________________________
> >> >>>> Rio-pm mailing list
> >> >>>> Rio-pm em pm.org
> >> >>>> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
> >> >>> GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C
> >> >>> http://www.flickr.com/photos/alexeiz | http://github.com/russoz
> >> >>> "I don't know... fly casual!" -- Han Solo
> >> >>>
> >> >>> _______________________________________________
> >> >>> Rio-pm mailing list
> >> >>> Rio-pm em pm.org
> >> >>> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Rio-pm mailing list
> >> >> Rio-pm em pm.org
> >> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
> >> > GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C
> >> > http://www.flickr.com/photos/alexeiz | http://github.com/russoz
> >> > "I don't know... fly casual!" -- Han Solo
> >> >
> >> > _______________________________________________
> >> > Rio-pm mailing list
> >> > Rio-pm em pm.org
> >> > http://mail.pm.org/mailman/listinfo/rio-pm
> >> _______________________________________________
> >> Rio-pm mailing list
> >> Rio-pm em pm.org
> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >
> >
> >
> >
> > --
> > Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
> > GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C
> > http://www.flickr.com/photos/alexeiz | http://github.com/russoz
> > "I don't know... fly casual!" -- Han Solo
> >
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
--
Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C
http://www.flickr.com/photos/alexeiz | http://github.com/russoz
"I don't know... fly casual!" -- Han Solo
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120607/f6e956b9/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm