[SP-pm] Resumo do Evento Técnico

Fri Jan 30 13:05:19 PST 2015

Blabos,

Discordo profundamente e os impactos econômicos para empresas de software
da ignorância ou negligência dos profissionais são bastante significativos,
certamente não desprezíveis.

Deixo claro, no entanto, que não tenho a menor intenção de que todos
concordem, nem em usar Rest, nem em participar de um workshop sobre isso.
Acho que tem de ser algo prazeroso para pessoas que gostam de engenharia de
software ou design, que não é algo que a maioria das pessoas gosta.

Em 30 de janeiro de 2015 01:16, Blabos de Blebe <blabos em gmail.com> escreveu:

> 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 em gmail.com>:
> >
> >
> > Em 29 de janeiro de 2015 21:54, Kojo <rbsnkjmr em 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 em 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 em gmail.com> escreveu:
> >>>>
> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron em 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 em 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 em ruoso.com>
> >>>>>>>>> escreveu:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus
> >>>>>>>>>> <lucasmateus.oliveira em 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 em 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 em 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 em gmail.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <
> leonardo em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150130/6fa81441/attachment-0001.html>