[SP-pm] Resumo do Evento Técnico

Hernan Lopes hernanlopes at gmail.com
Fri Jan 30 05:47:07 PST 2015


E o hash hmac ?
Com ele é possível autenticar sem usuário/senha... ao invés disso, é
enviado o request + chave pública(ou identificacao do user) + assinatura
feita com chave privada.
Isso não ajuda ?

2015-01-30 1:16 GMT-02:00 Blabos de Blebe <blabos at gmail.com>:

> Nah...
>
> A questão é que o termo REST, cunhado pelo tio Fielding
> (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm), é bem
> específico.
>
> Tecnicamente o que a gente chama de webservice REST com json pra lá e
> json pra ca não bate com a definição específica de REST criada por
> ele.
>
> O próprio Fielding "dá piti" quando a gente chama nossos webservices
> de RESTful, porque não bate com o termo que ele criou.
>
> O que o Leo tá dizendo é que conceitualmente existem diferenças, e a
> maioria esmagadora das pessoas, não entendem isso, gerando coisas
> bizarras, como um webservice que se comporta como SOAP, mas porque faz
> PUT e DELETE "quer ser REST".
>
> No fim boa parte dessa conversa é só pra dizer se eu vou chamar o
> treco de bolacha ou de biscoito.
>
> []'s
>
>
>
> 2015-01-29 23:58 GMT-02:00 Solli Honorio <shonorio at gmail.com>:
> >
> >
> > Em 29 de janeiro de 2015 21:54, Kojo <rbsnkjmr at gmail.com> escreveu:
> >>
> >> Dedo gordo, continuando.
> >>
> >> Olha, realmente eu não tenho interesse em rever a documentação de SOAP e
> >> WSDL mas estou achando essas discussão interessante porque nos obriga a
> >> tratar dos diferentes padrões com rigor técnico.
> >> Não sei se vale uma palestra, mas posso contar sobre as implementações
> de
> >> webservice que já participei, uma delas transionando em XML, outra SOAP
> e
> >> outra JSON.
> >> A JSON foi bem simplesinha, a SOAP nem tanto porque trabalhar no
> protocolo
> >> é exaustivo, e a XML foi uma solução caseira em 2001 bem interessante.
> Eu
> >> teria que rever alguns documentos da época para clarear a memória, era
> uma
> >> coleção de interfaces em XML para diferentes tipos de dados.
> >>
> >> Continuo achando que REST é para poucos porque dá para implementar um
> >> webservice de várias maneiras, mas podendo participar da discussão estou
> >> dentro.
> >
> >
> >
> > Continuo não entendendo esta afirmação de que REST só serve para poucos.
> > Neste exato momento temos bilhões de dispositivos móveis executando
> centenas
> > de bilhões de transações de milhares de aplicativos diferentes. Se isto
> > significa que esta arquitetura é para um nicho, então não sei o que é uma
> > arquitetura para a massa.
> >
> > O Leonardo fez um resumo que achei interessante, REST é WEB para
> aplicação,
> > e é aí que vejo o poder deste cara. É tão simples que chega a ser
> > complicado, e muito leve. É muito escalável e permitir implementar a
> > tecnologia de autenticação mais adequado a tua necessidade. É muito
> simples
> > implementar autenticação baseado em usuário/senha (inclusive com
> kerberos)
> > via um sistema de proxy/web servicer, ou um ouath like.
> >
> > O REST é o paraíso em linguagens dinâmicas, credito até que a adoção em
> > massa na internet só ocorreu por causa do grande número de projetos
> > utilizando linguagens dinâmicas (Ruby, Python, Perl) em detrimento de
> Java e
> > .Net (que alias é um pesadelo em utilizar o REST, mas parece que o Java
> está
> > melhorando este quesito segundo o Leonardo).
> >
> >
> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <leonardo at ruoso.com>
> >>> escreveu:
> >>>
> >>>> Há um ponto que eu considero importante: nem todos os softwares
> precisam
> >>>> ser web/rest. Muitos softwares podem usar HTTP para fazer RPC. Até aí
> nenhum
> >>>> problema.
> >>>>
> >>>> O problema, a meu ver, é fazer uma coisa dizendo que está fazendo
> outra,
> >>>> pelo fato de que a outra goza de melhor reputação. Isso é, para
> começar,
> >>>> desonesto.
> >>>>
> >>>> Outro ponto que vale a pena considerar é que em tudo na vida a gente
> >>>> precisa estabelecer os paradigmas sobre os quais vai trabalhar.
> >>>>
> >>>> Eu toparia participar de um workshop sobre RPC com Soap/WSDL sobre
> >>>> HTTP/XMPP/SMTP, mas creio que ainda menos pessoas se interessariam
> por RPC
> >>>> já que estudar Rest parece um investimento mais promissor hoje em dia.
> >>>>
> >>>> Pessoalmente eu estou bastante interessado em Rest, em compreender e
> >>>> talvez em entender como modelar softwares em Rest. Em especial eu
> estou
> >>>> interessado em gestão de autenticação e autorização para
> implementação de
> >>>> SSO/ACL para o que eu entendo que é fundamental para ter um software
> Rest
> >>>> que não seja equivalente à Wikipedia em termos de ACL.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Em 28 de janeiro de 2015 16:34, Kojo <rbsnkjmr at gmail.com> escreveu:
> >>>>
> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron at gmail.com
> >
> >>>>> escreveu:
> >>>>>>
> >>>>>> O protocolo HTTP em si, é stateless, e trabalha em cima do TCP.
> >>>>>>
> >>>>>> O TCP sim é stateful, e existe todo um protocolo complexo (ACK,
> Flags,
> >>>>>> Sequence, e window size) para que todo ele funcione.
> >>>>>>
> >>>>>> Como HTTP não tem estado, ou seja, a string "GET /meu-saldo\n\n" não
> >>>>>> contém nenhuma informação sobre os estados anteriores.
> >>>>>> Mesmo com headers (cookie) e query-parameters (api-key) o
> HTTP-per-si,
> >>>>>> é stateless.
> >>>>>
> >>>>>
> >>>>>
> >>>>> O HTTP é stateless mas a maiorida das aplicações que rodam sobre ele
> >>>>> não, então implementam o mecanismo de sessão para manter o estado. O
> REST
> >>>>> não, ele propõe transações atômicas para possibilitar a otimização de
> >>>>> recursos, de acordo com o que vc descreve abaixo.
> >>>>>
> >>>>>
> >>>>>> O problema é acontece quando, como server, você precisar que algum
> >>>>>> header ou query-parameter seja enviado para algum server em
> especial para
> >>>>>> receber a resposta correta.
> >>>>>>
> >>>>>> Os dados do Request HTTP deveriam poder passar por todos os proxys e
> >>>>>> servers sem sofrer alterações nas respostas [1].
> >>>>>>
> >>>>>> Quando a aplicação recebe o HTTP e lê ele, ela deveria sempre dar
> uma
> >>>>>> resposta concisa sobre o que foi pedido, não importando do estado a
> >>>>>> aplicação. Ela pode ser um servidor que acabou de ligar, pode ser
> um que
> >>>>>> está rodando a horas, pode ser o ultimo request que o load-balance
> está
> >>>>>> esperando terminar antes de desligar o servidor.
> >>>>>>
> >>>>>> A visão deste cookie/param tem que ser global entre os servidores.
> >>>>>> caso contrario, precisa usar sticky session. E sticky session é o
> que é
> >>>>>> horrível.
> >>>>>>
> >>>>>> Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão
> >>>>>> global dos estados de cada cliente.
> >>>>>
> >>>>>
> >>>>> Eu não entendo como esses mecanismos de cache impactam a arquitetura
> >>>>> stateless do REST de maneira positiva. Sei que eles trazem ganhos de
> >>>>> performance muito grande na leitura de dados, mas não que mude a
> arquitetura
> >>>>> em sí. Vc pode dar algum exemplo?
> >>>>>
> >>>>>
> >>>>>
> >>>>>> [1] exceção de proxys que tentam colocar cache, ad's e bloquear o
> >>>>>> acesso, mas esse nao é o proxy que eu falo!
> >>>>>> inclusive isso me lembra que, a maior parte de quem usa proxys de
> >>>>>> cache, tipo o varnish, fazem algum IF para dropar o cache caso
> tenha alguma
> >>>>>> indicação de 'stateful' no header/api-key.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2015-01-28 10:45 GMT-02:00 Kojo <rbsnkjmr at gmail.com>:
> >>>>>>
> >>>>>>>>>
> >>>>>>>>> O REST mantém o conceito de HTTP stateless, ou seja, o server
> nunca
> >>>>>>>>> sabe quem é o cliente, então não tem nada guardado em memória,
> não tem
> >>>>>>>>> nenhuma persistência de estado dos seus dados em relação aos
> seus clientes.
> >>>>>>>>> Isso é uma grande vantagem, mas para poucos, porque o grande
> alívio que ele
> >>>>>>>>> trás é para os serviços web que transacionam simultaneamente com
> milhṍes de
> >>>>>>>>> clientes, poupando memória, processamento, e infra em geral para
> persistir
> >>>>>>>>> os dados.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Não apenas, há várias outras vantagens em se trabalhar com
> >>>>>>>> stateless.
> >>>>>>>
> >>>>>>>
> >>>>>>> As vantagens que eu vejo no stateless estão todas relacionadas com
> >>>>>>> otimização de memória, não cache em cluster, não administração de
> sessão
> >>>>>>> etc.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Para outros webservices, que transacionam com "poucos clientes"
> >>>>>>>>> pode ser utilizada "qualquer arquitetura" que não fará muita
> diferença, vai
> >>>>>>>>> custar pouco e os servidores vão aguentar do mesmo jeito. Qdo
> falo em qquer
> >>>>>>>>> arquitetura, pode até ser um "REST stateful", que na verdade não
> é REST na
> >>>>>>>>> acepção da palavra.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Qual seria um exemplo?
> >>>>>>>
> >>>>>>>
> >>>>>>> Por exemplo uma aplicação web stateful que ofereça todos os métodos
> >>>>>>> que as partes necessitam em um webservice, como criação, update,
> leitura e
> >>>>>>> deleção, sem se preocupar com a semântica dos métodos HTTP sem se
> preocupar
> >>>>>>> em ser stateles. Em suma, uma aplicação web qquer que retorne xml,
> json ou
> >>>>>>> qquer coisa inclusive documentos.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Em termos de penetração de mercado acho REST limitado, e pensando
> >>>>>>>>> em um "REST stateful" acho que uma boa abordagem é o Websocket.
> O Websocket
> >>>>>>>>> elimina um outro problema do HTTP que além de ser stateless, é o
> >>>>>>>>> sincronismo. O HTTP é blocante e o cliente fica pendurado
> esperando a
> >>>>>>>>> resposta, carregando o servidor web. Já o Websocket é assincrono
> e por isso
> >>>>>>>>> aceita milhões de requisições que não ficam penduradas.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> WebSocket funciona em cima de HTTP :p
> >>>>>>>
> >>>>>>>
> >>>>>>> Funciona sobre HTTP mas não é uma premissa. O Websocket usa o HTTP
> >>>>>>> para fazer handshake e aproveita toda a infra do HTTP como as
> portas 80 e
> >>>>>>> 443, proxy etc, mas a idéia é futuramente mandar ele para outra
> porta e
> >>>>>>> deixar o protocolo independente. Ele funciona como se fosse
> tunelado, ou
> >>>>>>> seja, se vc estabelecer uma camada de transporte para ele, o resto
> já tá
> >>>>>>> pronto. E a RFC diz que futuramente vai ser feito.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP
> >>>>>>>> sobre WebSocket seja uma solução mais robusta.
> >>>>>>>>
> >>>>>>>> E em muito tempo a única forma racional (efetiva, eficaz e
> >>>>>>>> eficiente) que encontrei para implementar sistemas com WebSocket
> é baseada
> >>>>>>>> em Schema/LD.
> >>>>>>>
> >>>>>>>
> >>>>>>> Faz sentido, pq o Websocket é um protocolo e REST é uma
> arquitetura.
> >>>>>>> AMQP começa a ser uma composição de MQ com Websocket e tal. Aí
> começa a se
> >>>>>>> montar uma arquitetura compondo várias tecnologias e protocolos.
> >>>>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> Não estou dizendo que a arquitetura REST não é boa nem que não
> tem
> >>>>>>>>> utilidade, mas que é para poucos. HATEOAS me soa a mesma coisa,
> eu nunca
> >>>>>>>>> tinha ouvido falar, mas me lembrou WSDL, SOAP, etc.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Na verdade Rest é oposto a SOAP, que embora também suporte
> >>>>>>>> documentos e não apenas RPC, não tem as premissas de funcionar em
> WEB.
> >>>>>>>>
> >>>>>>>> Mas, sim, para fazer RPC tunelado sobre HTTP, XMPP, SMTP eu diria
> >>>>>>>> que ainda hoje o padrão mais maduro é, sem dúvida, SOAP/WSDL.
> Certamente é o
> >>>>>>>> que torna o desenvolvimento de software mais fácil.
> >>>>>>>
> >>>>>>>
> >>>>>>> Eu já trabalhei em uma implementação de SOAP e WSDL em PERL. A
> >>>>>>> empresa consumia os nossos webservices e foi uma solução
> interessante, a
> >>>>>>> arquitetura era deles. Eu acho que a solução funcionava bem porque
> não eram
> >>>>>>> muitos requests, senão valeria a pena pensar em algo assíncrono.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Em 26 de janeiro de 2015 21:08, Leonardo Ruoso <
> leonardo at ruoso.com>
> >>>>>>>>> escreveu:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus
> >>>>>>>>>> <lucasmateus.oliveira at gmail.com> escreveu:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Eu uso o Catalyst::Controller::REST que implementa todo o “sexo
> >>>>>>>>>>> dos anjos” pra mim e vou ser feliz :D
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Não falta pretenção para o Catalyst::Controller::REST
> >>>>>>>>>>
> >>>>>>>>>> Quanto a ser feliz, bem, eu acredito que se conseguirmos
> construir
> >>>>>>>>>> uma infraestrutura de software e uma prova de conceito Rest em
> Perl, em cima
> >>>>>>>>>> do Catalyst, por exemplo, com View, Controller e Model
> requerendo interfaces
> >>>>>>>>>> Rest de classes Moose (incluindo DBIx::Class Result(set)),
> vamos ser mais
> >>>>>>>>>> que felizes.
> >>>>>>>>>>
> >>>>>>>>>> Se tiver uma galera na comunidade Perl entendo o que é Rest eu
> já,
> >>>>>>>>>> pessoalmente, ficarei muito feliz demais da conta.
> >>>>>>>>>>
> >>>>>>>>>> Que a galera Java, por exemplo, já está acordando para a vida.
> >>>>>>>>>>
> >>>>>>>>>>> Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <leonardo at ruoso.com>
> >>>>>>>>>>> escreveu:
> >>>>>>>>>>>
> >>>>>>>>>>> Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem
> >>>>>>>>>>> feito, há um motivo pelo qual todo mundo quer Rest: REST É O
> ÚLTIMO BISCOITO
> >>>>>>>>>>> DO PACOTE! JSON-RPC funciona, mas não é Rest e por isso não
> tem todas as
> >>>>>>>>>>> vantagens sensacionais do Rest.
> >>>>>>>>>>>
> >>>>>>>>>>> Em 26 de janeiro de 2015 14:54, Renato Santos
> >>>>>>>>>>> <renato.cron at gmail.com> escreveu:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Eu posso me juntar, mas já digo que eu só faço API's REST, não
> >>>>>>>>>>>> RESTFul, e que nunca ouvi falar de HyperDocument e que
> linked-data pra mim
> >>>>>>>>>>>> tem que ser em RDF!
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2015-01-26 14:51 GMT-02:00 Lucas Mateus
> >>>>>>>>>>>> <lucasmateus.oliveira at gmail.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <
> leonardo at ruoso.com>
> >>>>>>>>>>>>> escreveu:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Caso na comunidade tenha gente disposta a se atualizar sobre
> >>>>>>>>>>>>> Restful (um conceito novo, lançado em 2000, e que se tornou
> a principal
> >>>>>>>>>>>>> vedete do desenvolvimento de software contemporâneo) e
> disposta a parar de
> >>>>>>>>>>>>> mentir para seus chefes e clientes de que está entregando
> restful quando
> >>>>>>>>>>>>> está na verdade entregando um tipo de RPC mais-que-porco, eu
> teria um imenso
> >>>>>>>>>>>>> prazer em integrar um grupo de estudo e de desenvolvimento
> com esse
> >>>>>>>>>>>>> objetivo.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hahaha comunidade de mentirosos :D
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> =begin disclaimer
> >>>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>>>>>> =end disclaimer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Saravá,
> >>>>>>>>>>>> Renato CRON
> >>>>>>>>>>>> http://www.renatocron.com/blog/
> >>>>>>>>>>>> @renato_cron
> >>>>>>>>>>>>
> >>>>>>>>>>>> =begin disclaimer
> >>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>>>>> =end disclaimer
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Leonardo Ruoso
> >>>>>>>>>>> Journalist, Perl developer and business consultant
> >>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
> >>>>>>>>>>> =begin disclaimer
> >>>>>>>>>>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>>>> =end disclaimer
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> =begin disclaimer
> >>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>>>> =end disclaimer
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Leonardo Ruoso
> >>>>>>>>>> Journalist, Perl developer and business consultant
> >>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
> >>>>>>>>>>
> >>>>>>>>>> =begin disclaimer
> >>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>>> =end disclaimer
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> =begin disclaimer
> >>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>>> =end disclaimer
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Leonardo Ruoso
> >>>>>>>> Journalist, Perl developer and business consultant
> >>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
> >>>>>>>>
> >>>>>>>> =begin disclaimer
> >>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>>> =end disclaimer
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> =begin disclaimer
> >>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>>> =end disclaimer
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Saravá,
> >>>>>> Renato CRON
> >>>>>> http://www.renatocron.com/blog/
> >>>>>> @renato_cron
> >>>>>>
> >>>>>> =begin disclaimer
> >>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>>> =end disclaimer
> >>>>>>
> >>>>>
> >>>>>
> >>>>> =begin disclaimer
> >>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>>> =end disclaimer
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Leonardo Ruoso
> >>>> Journalist, Perl developer and business consultant
> >>>> Media, UFC/2006; Telecom, IFCE/1998
> >>>>
> >>>> =begin disclaimer
> >>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >>>> =end disclaimer
> >>>>
> >>>
> >>
> >>
> >> =begin disclaimer
> >>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> >> =end disclaimer
> >>
> >
> >
> >
> > --
> > "o animal satisfeito dorme". - Guimarães Rosa
> >
> > =begin disclaimer
> >    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> > =end disclaimer
> >
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150130/50a65931/attachment-0001.html>


More information about the SaoPaulo-pm mailing list