<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Em 30 de janeiro de 2015 01:58, Solli Honorio <span dir="ltr"><<a href="mailto:shonorio@gmail.com" target="_blank">shonorio@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>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.<br></div></div></div></div></blockquote><div><br></div><div>Qdo eu falo que é para poucos, não é que dá para contar nos dedos das mãos, mas que no universo de milhões de servidores e serviços web (servidores; não clientes), nem todo mundo precisa comer a bolacha stateless, nem usar a semântica HTTP (POST, PUT etc)</div><div><br></div><div>No documento que o Blabos mandou, as vantagens citadas são "visibility, reliability, and scalability". A primeira é a menos importante, a segunda é bem interessante e a terceira, basicamente é que traz grandes benefícios aos poucos. Quem são esses poucos? Facebook, Twitter, Google, Youtube, Buscapé, Globo.com, mais umas centenas ou alguns poucos milhares de serviços que concentram "todo mundo". Para eles a bolacha stateless faz a diferença. </div><div><br></div><div>Os webservices que eu citei que eu desenvolvi, nenhum deles era REST (stateless). Mas pensando bem, eu teria que rever a documentação de um deles para ver se usávamos a sessão armazenada no servidor para alguma coisa. Mas com certeza em nenhum caso usamos a semântica HTTP REST com POST, PUT, etc. E sendo ou não REST, que nesse caso não eram, foram webservices que atenderam completamente a necessidade.</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <span dir="ltr"><<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span> escreveu:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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. <div><br></div><div>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.</div><div><br></div><div>Outro ponto que vale a pena considerar é que em tudo na vida a gente precisa estabelecer os paradigmas sobre os quais vai trabalhar. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Em 28 de janeiro de 2015 16:34, Kojo <span dir="ltr"><<a href="mailto:rbsnkjmr@gmail.com" target="_blank">rbsnkjmr@gmail.com</a>></span> escreveu:<div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Em 28 de janeiro de 2015 11:24, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>O protocolo HTTP em si, é stateless, e trabalha em cima do TCP. <br></div><div><br></div><div>O TCP sim é stateful, e existe todo um protocolo <i>complexo</i> (ACK, Flags, <b>Sequence</b>, e window size) para que todo ele funcione.</div><div><br></div><div>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.</div><div>Mesmo com headers (cookie) e query-parameters (api-key) o HTTP-per-si, é stateless.</div></div></blockquote><div><br></div><div><br></div></span>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.<span><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>Os dados do Request HTTP deveriam poder passar por todos os proxys e servers sem sofrer alterações nas respostas [1].</div><div><br></div><div>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 <b>estado a aplicação. </b>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. </div><div><br></div><div>A <b>visão </b>deste cookie/param tem que ser global entre os servidores. caso contrario, precisa usar sticky session. E sticky session é o que é horrível. </div><div><br></div><div>Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão global dos estados de cada cliente.</div></div></blockquote><div><br></div></span><div>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?</div><div><div><div><br></div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>[1] exceção de proxys que tentam colocar cache, ad's e bloquear o acesso, mas esse nao é o proxy que eu falo!<br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-28 10:45 GMT-02:00 Kojo <span dir="ltr"><<a href="mailto:rbsnkjmr@gmail.com" target="_blank">rbsnkjmr@gmail.com</a>></span>:<div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br>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. </div></blockquote><div><br></div></span><div>Não apenas, há várias outras vantagens em se trabalhar com stateless.<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>Qual seria um exemplo?<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>WebSocket funciona em cima de HTTP :p<br></div></div></div></div></blockquote><div> </div></span><div>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. </div><span><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP sobre WebSocket seja uma solução mais robusta.<br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>E em muito tempo a única forma racional (efetiva, eficaz e eficiente) que encontrei para implementar sistemas com WebSocket é baseada em Schema/LD.<br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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. </div></div></blockquote><div><br></div></span><div>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.<br><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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. </div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 21:08, Leonardo Ruoso <span dir="ltr"><<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span> escreveu:<div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 18:20, Lucas Mateus <span dir="ltr"><<a href="mailto:lucasmateus.oliveira@gmail.com" target="_blank">lucasmateus.oliveira@gmail.com</a>></span> escreveu:<span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span style="white-space:pre-wrap">       </span>Eu uso o Catalyst::Controller::REST que implementa todo o “sexo dos anjos” pra mim e vou ser feliz :D</div></div></blockquote><div><br></div></span><div>Não falta pretenção para o Catalyst::Controller::REST<br></div><div><br></div><div>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.</div><div><br></div><div>Se tiver uma galera na comunidade Perl entendo o que é Rest eu já, pessoalmente, ficarei muito feliz demais da conta.</div><div> </div><div>Que a galera Java, por exemplo, já está acordando para a vida.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>> escreveu:<br></div><div><div><div><br><blockquote type="cite"><div dir="ltr">Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem feito, há um motivo pelo qual todo mundo quer Rest: <b>REST É O ÚLTIMO BISCOITO DO PACOTE</b>! JSON-RPC funciona, mas não é Rest e por isso não tem todas as vantagens sensacionais do Rest. </div><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 14:54, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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!<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-26 14:51 GMT-02:00 Lucas Mateus <span dir="ltr"><<a href="mailto:lucasmateus.oliveira@gmail.com" target="_blank">lucasmateus.oliveira@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div style="word-wrap:break-word"><br><div><div>Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>> escreveu:</div><span><br><blockquote type="cite"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></blockquote></span></div><br><div>Hahaha comunidade de mentirosos :D</div></div><br></span><span>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font size="1" color="#333333"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font size="1" color="#333333"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cron</a></font></div></div>
</font></span></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div>
=begin disclaimer<br>   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>=end disclaimer<br></blockquote></div></div></div><br></div><br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><br>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- <br><div><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font size="1" color="#333333"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font size="1" color="#333333"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cron</a></font></div></div>
</div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div>
</blockquote></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br><br clear="all"><br>-- <br><span class=""><div>"o animal satisfeito dorme". - Guimarães Rosa</div>
</span></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br></div></div>