[SP-pm] Resumo do Evento Técnico

Sat Jan 31 03:56:06 PST 2015

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

> Pera. Não entendi. Você discorda quando eu concordo com vc?
>

Ok, deixa-me explicar, eu não concordo que seja uma questão de biscoito ou
bolacha (que aliás são tão sinônimos como canjica e mungunzá ou mandioca,
aipim e macaxeira).

A forma como você colocou deu-me a compreender que se tratava de uma
discussão sobre formalismo e não sobre uma questão de cunho prático e
relevante para a Ciência da Computação e Engenharia de Software.

Eu discordo, pois, depois de estudar Rest (eu venho do mundo de Soap/WSDL e
RMI em Java), eu consigo compreender muito melhor onde está a beleza do
AngularJS e como as pessoas estão fazendo muita coisa errada por aí, e isso
com um impacto negativo grande na performance, na longevidade e no custo de
manutenção das aplicações.

Existe uma razão pela qual o Rest explodiu como conceito de integração
entre sistemas e essa razão não é nem cutucada por softwares que fazer
JSON-RPC com forte acoplamento entre interface e API, quanto mais quando
são usadas especificações AdHoc de interfaces e essa razão é redução no
custo de manutenção dos softwares e longevidade dos clientes: algo ainda
mais importantes quando falamos de Mobile e Internet das coisas.

> []'s
>
>
> 2015-01-30 19:05 GMT-02:00 Leonardo Ruoso <leonardo em ruoso.com>:
> > 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
> >
> > =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/20150131/19a0531e/attachment-0001.html>