Em 30 de janeiro de 2015 22:21, Blabos de Blebe <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]>: > >> > > >> > > >> > Em 29 de janeiro de 2015 21:54, Kojo <[email protected]> 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 <[email protected]> > >> >>> 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 <[email protected]> > escreveu: > >> >>>> > >> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos > >> >>>>> <[email protected]> > >> >>>>> 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 <[email protected]>: > >> >>>>>> > >> >>>>>>>>> > >> >>>>>>>>> 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 > >> >>>>>>>>> <[email protected]> > >> >>>>>>>>> escreveu: > >> >>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus > >> >>>>>>>>>> <[email protected]> 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 < > [email protected]> > >> >>>>>>>>>>> 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 > >> >>>>>>>>>>> <[email protected]> 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 > >> >>>>>>>>>>>> <[email protected]>: > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso > >> >>>>>>>>>>>>> <[email protected]> > >> >>>>>>>>>>>>> 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: [email protected] > >> >>>>>>>>>>>>> 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: [email protected] > >> >>>>>>>>>>>> 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: [email protected] > >> >>>>>>>>>>> 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: [email protected] > >> >>>>>>>>>>> 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: [email protected] > >> >>>>>>>>>> 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: [email protected] > >> >>>>>>>>> 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: [email protected] > >> >>>>>>>> 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: [email protected] > >> >>>>>>> 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: [email protected] > >> >>>>>> 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: [email protected] > >> >>>>> 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: [email protected] > >> >>>> 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: [email protected] > >> >> 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: [email protected] > >> > 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: [email protected] > >> 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: [email protected] > > 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: [email protected] > 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
