[SP-pm] Resumo do Evento Técnico

Fri Jan 30 13:07:52 PST 2015

Em 30 de janeiro de 2015 11:47, Hernan Lopes <hernanlopes em gmail.com>
escreveu:

>
> 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 ?
>

PKI é outro assunto que merece um workshop a parte :)

No entanto, PKI, assim como usuário e senha, referem-se ao início de uma
seção, ao handshake.

E, sim, uma aplicação Rest deveria permitir uso de PAM, no Linux, por
exemplo, ou DS/AD com Apple/Microsoft.

O problema da autorização segue o mesmo :D

> 2015-01-30 1:16 GMT-02:00 Blabos de Blebe <blabos em 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 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
>>
>
>
> =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/afc36b21/attachment-0001.html>