From renato.cron at gmail.com Thu Jan 1 18:08:00 2015 From: renato.cron at gmail.com (Renato Santos) Date: Fri, 2 Jan 2015 00:08:00 -0200 Subject: [SP-pm] Site beta no "ar" In-Reply-To: <549df56d2b708_5a0015c1a08973e0955cb@a4-winter14.mail> References: <549df56d2b708_5a0015c1a08973e0955cb@a4-winter14.mail> Message-ID: Pessoal, botei o site no ar. ainda faltam algumas coisas.. mas no momento, j? tem quase tudo o que tinha no antigo, exceto o que l? estava desatualizado (/empresas por exemplo) agora inverti o jogo, o antigo est? na porta :8080 Alguem ai que tem acesso no Google Analytics pode me adicionar as stalker? 2014-12-26 21:55 GMT-02:00 Ricardo Stock : > Renato, parab?ns pelo trabalho, o site est? ficando ?timo. > > > Ricado Stock > ricardostock at bol.com.br > Um bom programador tem um desafio > Um programador mediano, tem um problema. > > > > > De: renato.cron at gmail.com > Enviada: Quinta-feira, 25 de Dezembro de 2014 18:19 > Para: saopaulo-pm at pm.org > Assunto: [SP-pm] Site beta no "ar" > > Pessoal, > Coloquei no ar, para voc?s poderem ir acompanhando, o novo site que estou > fazendo, > Esta na porta 8080 por enquanto, pois ainda falta eu migrar os equin?cios, > e ai, se ningu?m for contra*, eu fa?o o swap. > As publica??es est?o aqui: http://sao-paulo.pm.org:8080/pub > Como voc?s v?o ver, extrai o nome de cada autor e normalizei alguns > artigos para poder cruzar o nome com o e-mail. O e-mail, quase nunca est? > dispon?vel, ent?o eu usei a minha pr?pria conta de e-mail + google para > encontrar os autores e fazer o md5, para poder puxar o gravatar! > Quem quiser contribuir com layout, ajuste de encoding nos artigos, > normaliza??es do texto das licen?as, etc, pode ir l? no github, e mexer no > branch 'beta'. > O que j? foi feito: > Importa??o / manuten??o de quase todas as telas estaticas do site > antigo.agora elas s?o arquivos .tx e est? bem r?pido/simples de criar uma > nova p?ginaLayout limpo do twitter bootstrap 3 (foi um download custom, sem > um monte de coisa, praticamente, apenas a grid)URL's antigas dos > artigos fazem redirect 301 para as novas.Normaliza??o do encoding dos > arquivos para UTF-8.Cria??o de um banco de dados postgres para colocar os > artigosObten??o do Hash do e-mail dos autoresAlgumas datas de publica??es > foram encontradas, outras s?o ficaram "$year-01-01" mesmo...Vou continuar > evoluindo hoje, nesta ordem: > importar os equin?cios.tela do autor.lista dos autorescoment?rios (usando > a mesma base do site antigo)Mais pra frente, a ideia do site ? ser capaz de: > Depois de logado via google/cpan/email o autor pode editar os artigos j? > publicadoPublica??o dos eventos e encontros t?cnicos por 'qualquer > um'poder escrever novas publica??es e publicar [talvez alugma com > modera??o]Admins podem editar qualquer artigo.melhoria no site, como > filtro, calend?rio dos equin?cios, pesquisaum footer 'longo', com > links uteis de outros sites de perltalvez podemos pensar em subir o > perl-pro que foi programado, mas nunca entrou no ar.uma area de perl > 6.backendNo momento, como o site ? muito simples, a web acessa o banco > direto e n?o temos um API no meio. Na verdade, nem sei se ? necess?rio uma > API no momento. > Tamb?m escolhi PostgreSQL como base de dados, e, os scripts de importa??o > dos textos atuais, ficar?o apenas at? o momento que todos os artigos > estiverem no banco. > Quando isso acontecer, vou montar uma maneira de usar o pg_dump para fazer > o 'backup' di?rio dos artigos para o git. Assim, todo mundo poder? > subir uma copia inteira do site, exceto pela parte das contas do usu?rios. > Por isso que eu estou fazendo o 'ID' do autor ser o MD5 do e-mail > dele. > -- > * se algu?m for contra precisaremos consultar nosso l?der e fazer uma > an?lise da proposta que a pessoa sugerir, e depois, jogar uma moeda para > cima e se der coroa, a pessoa n?o vai cumprir o que podeira ser combinado! > 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 at pm.org > L > =end disclaimer > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.sutton at gmail.com Thu Jan 1 23:40:47 2015 From: igor.sutton at gmail.com (Igor Sutton) Date: Fri, 2 Jan 2015 08:40:47 +0100 Subject: [SP-pm] Site beta no "ar" In-Reply-To: References: <549df56d2b708_5a0015c1a08973e0955cb@a4-winter14.mail> Message-ID: <7C986CB4-906D-4FA6-B7B5-69345514EC9B@gmail.com> s/informa??es/informa??es/g. Tiraria o subheader das publica??es (n?o precisa de explica??o, menos ? mais). s/discurss?o/discuss?o/g. Em ?Publica??es?, o artigo do Jo?nio de 2006 come?a com ?Adicionano?, devido a um ?typo?. Esses artigos devem ser revisados (t?cnica e ortograficamente) antes de serem publicados, IMO. Eu tamb?m colocaria um ?abstract? junto a lista de publica??es na p?gina principal, por exemplo: ?8Leia mais ?8 On 02 Jan 2015, at 03:08, Renato Santos wrote: > > Pessoal, botei o site no ar. > > ainda faltam algumas coisas.. mas no momento, j? tem quase tudo o que tinha no antigo, exceto o que l? estava desatualizado (/empresas por exemplo) > > agora inverti o jogo, o antigo est? na porta :8080 > > Alguem ai que tem acesso no Google Analytics pode me adicionar as stalker? > > > > 2014-12-26 21:55 GMT-02:00 Ricardo Stock >: > Renato, parab?ns pelo trabalho, o site est? ficando ?timo. > > > Ricado Stock > ricardostock at bol.com.br > Um bom programador tem um desafio > Um programador mediano, tem um problema. > > > > > De: renato.cron at gmail.com > Enviada: Quinta-feira, 25 de Dezembro de 2014 18:19 > Para: saopaulo-pm at pm.org > Assunto: [SP-pm] Site beta no "ar" > > Pessoal, > Coloquei no ar, para voc?s poderem ir acompanhando, o novo site que estou fazendo, > Esta na porta 8080 por enquanto, pois ainda falta eu migrar os equin?cios, e ai, se ningu?m for contra*, eu fa?o o swap. > As publica??es est?o aqui: http://sao-paulo.pm.org:8080/pub > Como voc?s v?o ver, extrai o nome de cada autor e normalizei alguns artigos para poder cruzar o nome com o e-mail. O e-mail, quase nunca est? dispon?vel, ent?o eu usei a minha pr?pria conta de e-mail + google para encontrar os autores e fazer o md5, para poder puxar o gravatar! > Quem quiser contribuir com layout, ajuste de encoding nos artigos, normaliza??es do texto das licen?as, etc, pode ir l? no github, e mexer no branch 'beta'. > O que j? foi feito: > Importa??o / manuten??o de quase todas as telas estaticas do site antigo.agora elas s?o arquivos .tx e est? bem r?pido/simples de criar uma nova p?ginaLayout limpo do twitter bootstrap 3 (foi um download custom, sem um monte de coisa, praticamente, apenas a grid)URL's antigas dos artigos fazem redirect 301 para as novas.Normaliza??o do encoding dos arquivos para UTF-8.Cria??o de um banco de dados postgres para colocar os artigosObten??o do Hash do e-mail dos autoresAlgumas datas de publica??es foram encontradas, outras s?o ficaram "$year-01-01" mesmo...Vou continuar evoluindo hoje, nesta ordem: > importar os equin?cios.tela do autor.lista dos autorescoment?rios (usando a mesma base do site antigo)Mais pra frente, a ideia do site ? ser capaz de: > Depois de logado via google/cpan/email o autor pode editar os artigos j? publicadoPublica??o dos eventos e encontros t?cnicos por 'qualquer um'poder escrever novas publica??es e publicar [talvez alugma com modera??o]Admins podem editar qualquer artigo.melhoria no site, como filtro, calend?rio dos equin?cios, pesquisaum footer 'longo', com links uteis de outros sites de perltalvez podemos pensar em subir o perl-pro que foi programado, mas nunca entrou no ar.uma area de perl 6.backendNo momento, como o site ? muito simples, a web acessa o banco direto e n?o temos um API no meio. Na verdade, nem sei se ? necess?rio uma API no momento. > Tamb?m escolhi PostgreSQL como base de dados, e, os scripts de importa??o dos textos atuais, ficar?o apenas at? o momento que todos os artigos estiverem no banco. > Quando isso acontecer, vou montar uma maneira de usar o pg_dump para fazer o 'backup' di?rio dos artigos para o git. Assim, todo mundo poder? subir uma copia inteira do site, exceto pela parte das contas do usu?rios. > Por isso que eu estou fazendo o 'ID' do autor ser o MD5 do e-mail dele. > -- > * se algu?m for contra precisaremos consultar nosso l?der e fazer uma an?lise da proposta que a pessoa sugerir, e depois, jogar uma moeda para cima e se der coroa, a pessoa n?o vai cumprir o que podeira ser combinado! > 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 at pm.org > L> > =end disclaimer > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L> > =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 at pm.org > L > =end disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Fri Jan 2 01:28:14 2015 From: renato.cron at gmail.com (Renato Santos) Date: Fri, 2 Jan 2015 07:28:14 -0200 Subject: [SP-pm] Site beta no "ar" In-Reply-To: <7C986CB4-906D-4FA6-B7B5-69345514EC9B@gmail.com> References: <549df56d2b708_5a0015c1a08973e0955cb@a4-winter14.mail> <7C986CB4-906D-4FA6-B7B5-69345514EC9B@gmail.com> Message-ID: Opa Igor, Valeu pelas observa??es. Vou tentar usar um spell checker aqui no meu editor e dar uma revisada, pelo menos nas p?ginas e t?tulos. Sobre o texto do sub-header, realmente, eu posso tirar sem problemas, s? coloquei pra.. sei l?! Sobre o abstract, eu at? coloquei o campo na tabela, mas o que acontece, ? que, bom, no momento atual, o m?ximo que consigo fazer ? extrair o primeiro paragrafo do texto, o que as vezes pode n?o ser exatamente o abstract, devido a padr?es diferentes nas publica??es (por isso parei at? de usar o nome artigo, embora a tabela ainda chame-se *article*) 2015-01-02 5:40 GMT-02:00 Igor Sutton : > s/informa??es/informa??es/g. > > Tiraria o subheader das publica??es (n?o precisa de explica??o, menos ? > mais). > > s/discurss?o/discuss?o/g. > > Em ?Publica??es?, o artigo do Jo?nio de 2006 come?a com ?Adicionano?, > devido a um ?typo?. > > Esses artigos devem ser revisados (t?cnica e ortograficamente) antes de > serem publicados, IMO. > > Eu tamb?m colocaria um ?abstract? junto a lista de publica??es na p?gina > principal, por exemplo: > > ?8 T?tulo > Publicado em ... > > Abstract > > Leia mais > ?8 > E tamb?m ordenaria por data de publica??o, mais novos para os mais antigos. > > > On 02 Jan 2015, at 03:08, Renato Santos wrote: > > Pessoal, botei o site no ar. > > ainda faltam algumas coisas.. mas no momento, j? tem quase tudo o que > tinha no antigo, exceto o que l? estava desatualizado (/empresas por > exemplo) > > agora inverti o jogo, o antigo est? na porta :8080 > > Alguem ai que tem acesso no Google Analytics pode me adicionar as stalker? > > > > 2014-12-26 21:55 GMT-02:00 Ricardo Stock : > >> Renato, parab?ns pelo trabalho, o site est? ficando ?timo. >> >> >> Ricado Stock >> ricardostock at bol.com.br >> Um bom programador tem um desafio >> Um programador mediano, tem um problema. >> >> >> >> >> De: renato.cron at gmail.com >> Enviada: Quinta-feira, 25 de Dezembro de 2014 18:19 >> Para: saopaulo-pm at pm.org >> Assunto: [SP-pm] Site beta no "ar" >> >> Pessoal, >> Coloquei no ar, para voc?s poderem ir acompanhando, o novo site que estou >> fazendo, >> Esta na porta 8080 por enquanto, pois ainda falta eu migrar os >> equin?cios, e ai, se ningu?m for contra*, eu fa?o o swap. >> As publica??es est?o aqui: http://sao-paulo.pm.org:8080/pub >> Como voc?s v?o ver, extrai o nome de cada autor e normalizei alguns >> artigos para poder cruzar o nome com o e-mail. O e-mail, quase nunca est? >> dispon?vel, ent?o eu usei a minha pr?pria conta de e-mail + google para >> encontrar os autores e fazer o md5, para poder puxar o gravatar! >> Quem quiser contribuir com layout, ajuste de encoding nos artigos, >> normaliza??es do texto das licen?as, etc, pode ir l? no github, e mexer no >> branch 'beta'. >> O que j? foi feito: >> Importa??o / manuten??o de quase todas as telas estaticas do site >> antigo.agora elas s?o arquivos .tx e est? bem r?pido/simples de criar uma >> nova p?ginaLayout limpo do twitter bootstrap 3 (foi um download custom, sem >> um monte de coisa, praticamente, apenas a grid)URL's antigas dos >> artigos fazem redirect 301 para as novas.Normaliza??o do encoding dos >> arquivos para UTF-8.Cria??o de um banco de dados postgres para colocar os >> artigosObten??o do Hash do e-mail dos autoresAlgumas datas de publica??es >> foram encontradas, outras s?o ficaram "$year-01-01" mesmo...Vou continuar >> evoluindo hoje, nesta ordem: >> importar os equin?cios.tela do autor.lista dos autorescoment?rios (usando >> a mesma base do site antigo)Mais pra frente, a ideia do site ? ser capaz de: >> Depois de logado via google/cpan/email o autor pode editar os artigos j? >> publicadoPublica??o dos eventos e encontros t?cnicos por 'qualquer >> um'poder escrever novas publica??es e publicar [talvez alugma com >> modera??o]Admins podem editar qualquer artigo.melhoria no site, como >> filtro, calend?rio dos equin?cios, pesquisaum footer 'longo', com >> links uteis de outros sites de perltalvez podemos pensar em subir o >> perl-pro que foi programado, mas nunca entrou no ar.uma area de perl >> 6.backendNo momento, como o site ? muito simples, a web acessa o banco >> direto e n?o temos um API no meio. Na verdade, nem sei se ? necess?rio uma >> API no momento. >> Tamb?m escolhi PostgreSQL como base de dados, e, os scripts de importa??o >> dos textos atuais, ficar?o apenas at? o momento que todos os artigos >> estiverem no banco. >> Quando isso acontecer, vou montar uma maneira de usar o pg_dump para >> fazer o 'backup' di?rio dos artigos para o git. Assim, todo mundo >> poder? subir uma copia inteira do site, exceto pela parte das contas do >> usu?rios. >> Por isso que eu estou fazendo o 'ID' do autor ser o MD5 do e-mail >> dele. >> -- >> * se algu?m for contra precisaremos consultar nosso l?der e fazer uma >> an?lise da proposta que a pessoa sugerir, e depois, jogar uma moeda para >> cima e se der coroa, a pessoa n?o vai cumprir o que podeira ser combinado! >> 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 at pm.org >> L >> =end disclaimer >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Fri Jan 2 02:22:57 2015 From: renato.cron at gmail.com (Renato Santos) Date: Fri, 2 Jan 2015 08:22:57 -0200 Subject: [SP-pm] Site beta no "ar" In-Reply-To: References: <549df56d2b708_5a0015c1a08973e0955cb@a4-winter14.mail> <7C986CB4-906D-4FA6-B7B5-69345514EC9B@gmail.com> Message-ID: Bom, fiz o que deu pra fazer r?pido aqui, dando uma olhada em alguns artigos e fazendo um 'replace in file', deu bastante coisa at?. [beta a607513] mais spell checker! 117 files changed, 1176 insertions(+), 1176 deletions(-) Acho que os principais eram coisas tipo qw/tinhamos dispon?ves atraves alguem tambem poderiamos/. 2015-01-02 7:28 GMT-02:00 Renato Santos : > Opa Igor, > > Valeu pelas observa??es. > > Vou tentar usar um spell checker aqui no meu editor e dar uma revisada, > pelo menos nas p?ginas e t?tulos. > > Sobre o texto do sub-header, realmente, eu posso tirar sem problemas, s? > coloquei pra.. sei l?! > > Sobre o abstract, eu at? coloquei o campo na tabela, mas o que acontece, ? > que, bom, no momento atual, o m?ximo que consigo fazer ? extrair o primeiro > paragrafo do texto, o que as vezes pode n?o ser exatamente o abstract, > devido a padr?es diferentes nas publica??es (por isso parei at? de usar o > nome artigo, embora a tabela ainda chame-se *article*) > > > > 2015-01-02 5:40 GMT-02:00 Igor Sutton : > > s/informa??es/informa??es/g. >> >> Tiraria o subheader das publica??es (n?o precisa de explica??o, menos ? >> mais). >> >> s/discurss?o/discuss?o/g. >> >> Em ?Publica??es?, o artigo do Jo?nio de 2006 come?a com ?Adicionano?, >> devido a um ?typo?. >> >> Esses artigos devem ser revisados (t?cnica e ortograficamente) antes de >> serem publicados, IMO. >> >> Eu tamb?m colocaria um ?abstract? junto a lista de publica??es na p?gina >> principal, por exemplo: >> >> ?8> T?tulo >> Publicado em ... >> >> Abstract >> >> Leia mais >> ?8> >> E tamb?m ordenaria por data de publica??o, mais novos para os mais >> antigos. >> >> >> On 02 Jan 2015, at 03:08, Renato Santos wrote: >> >> Pessoal, botei o site no ar. >> >> ainda faltam algumas coisas.. mas no momento, j? tem quase tudo o que >> tinha no antigo, exceto o que l? estava desatualizado (/empresas por >> exemplo) >> >> agora inverti o jogo, o antigo est? na porta :8080 >> >> Alguem ai que tem acesso no Google Analytics pode me adicionar as >> stalker? >> >> >> >> 2014-12-26 21:55 GMT-02:00 Ricardo Stock : >> >>> Renato, parab?ns pelo trabalho, o site est? ficando ?timo. >>> >>> >>> Ricado Stock >>> ricardostock at bol.com.br >>> Um bom programador tem um desafio >>> Um programador mediano, tem um problema. >>> >>> >>> >>> >>> De: renato.cron at gmail.com >>> Enviada: Quinta-feira, 25 de Dezembro de 2014 18:19 >>> Para: saopaulo-pm at pm.org >>> Assunto: [SP-pm] Site beta no "ar" >>> >>> Pessoal, >>> Coloquei no ar, para voc?s poderem ir acompanhando, o novo site que >>> estou fazendo, >>> Esta na porta 8080 por enquanto, pois ainda falta eu migrar os >>> equin?cios, e ai, se ningu?m for contra*, eu fa?o o swap. >>> As publica??es est?o aqui: http://sao-paulo.pm.org:8080/pub >>> Como voc?s v?o ver, extrai o nome de cada autor e normalizei alguns >>> artigos para poder cruzar o nome com o e-mail. O e-mail, quase nunca est? >>> dispon?vel, ent?o eu usei a minha pr?pria conta de e-mail + google para >>> encontrar os autores e fazer o md5, para poder puxar o gravatar! >>> Quem quiser contribuir com layout, ajuste de encoding nos artigos, >>> normaliza??es do texto das licen?as, etc, pode ir l? no github, e mexer no >>> branch 'beta'. >>> O que j? foi feito: >>> Importa??o / manuten??o de quase todas as telas estaticas do site >>> antigo.agora elas s?o arquivos .tx e est? bem r?pido/simples de criar uma >>> nova p?ginaLayout limpo do twitter bootstrap 3 (foi um download custom, sem >>> um monte de coisa, praticamente, apenas a grid)URL's antigas dos >>> artigos fazem redirect 301 para as novas.Normaliza??o do encoding dos >>> arquivos para UTF-8.Cria??o de um banco de dados postgres para colocar os >>> artigosObten??o do Hash do e-mail dos autoresAlgumas datas de publica??es >>> foram encontradas, outras s?o ficaram "$year-01-01" mesmo...Vou continuar >>> evoluindo hoje, nesta ordem: >>> importar os equin?cios.tela do autor.lista dos autorescoment?rios >>> (usando a mesma base do site antigo)Mais pra frente, a ideia do site ? ser >>> capaz de: >>> Depois de logado via google/cpan/email o autor pode editar os artigos j? >>> publicadoPublica??o dos eventos e encontros t?cnicos por 'qualquer >>> um'poder escrever novas publica??es e publicar [talvez alugma com >>> modera??o]Admins podem editar qualquer artigo.melhoria no site, como >>> filtro, calend?rio dos equin?cios, pesquisaum footer 'longo', com >>> links uteis de outros sites de perltalvez podemos pensar em subir o >>> perl-pro que foi programado, mas nunca entrou no ar.uma area de perl >>> 6.backendNo momento, como o site ? muito simples, a web acessa o banco >>> direto e n?o temos um API no meio. Na verdade, nem sei se ? necess?rio uma >>> API no momento. >>> Tamb?m escolhi PostgreSQL como base de dados, e, os scripts de >>> importa??o dos textos atuais, ficar?o apenas at? o momento que todos os >>> artigos estiverem no banco. >>> Quando isso acontecer, vou montar uma maneira de usar o pg_dump para >>> fazer o 'backup' di?rio dos artigos para o git. Assim, todo mundo >>> poder? subir uma copia inteira do site, exceto pela parte das contas do >>> usu?rios. >>> Por isso que eu estou fazendo o 'ID' do autor ser o MD5 do >>> e-mail dele. >>> -- >>> * se algu?m for contra precisaremos consultar nosso l?der e fazer uma >>> an?lise da proposta que a pessoa sugerir, e depois, jogar uma moeda para >>> cima e se der coroa, a pessoa n?o vai cumprir o que podeira ser combinado! >>> 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 at pm.org >>> L >>> =end disclaimer >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > > > -- > Sarav?, > Renato CRON > http://www.renatocron.com/blog/ > @renato_cron > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From maia at eduardomaia.com Sat Jan 3 08:53:57 2015 From: maia at eduardomaia.com (Eduardo Maia) Date: Sat, 3 Jan 2015 14:53:57 -0200 Subject: [SP-pm] Palestras do ET dia 17/01/2015 Message-ID: Senhores, Gostaria de alinhar quais palestras teremos no dia 17/01/2015, para a divulga??o do evento. At? o momento, temos: Frederico Recsky - Blocks e YAPC Eduardo Maia - Boas pr?ticas em SQL Renato Cron - Hypertable Leandro Leite - Template::Toolkit Gabiru - ?? Thiago Rondon - ?? Gabiru e Thiago, por favor, poderiam informar os temas das palestras de voc?s? Quem mais gostaria de palestrar, sobre qual tema? Desde j?, muito obrigado. Abra?os, Eduardo Maia -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lorn at lornlab.org Mon Jan 5 06:32:31 2015 From: lorn at lornlab.org (Lindolfo Lorn Rodrigues) Date: Mon, 5 Jan 2015 12:32:31 -0200 Subject: [SP-pm] Palestras do ET dia 17/01/2015 In-Reply-To: References: Message-ID: Lindolfo Lorn Rodrigues - Open Source e Perl, o que eu aprendi at? agora. - Perl for humans ( fica mais legal em ingl?s, ? uma ideia meio polemica e ? fortemente baseada no Python for humans ) PS: S?o duas palestras 2015-01-03 14:53 GMT-02:00 Eduardo Maia : > Senhores, > > Gostaria de alinhar quais palestras teremos no dia 17/01/2015, para a > divulga??o do evento. At? o momento, temos: > > Frederico Recsky - Blocks e YAPC > Eduardo Maia - Boas pr?ticas em SQL > Renato Cron - Hypertable > Leandro Leite - Template::Toolkit > Gabiru - ?? > Thiago Rondon - ?? > > Gabiru e Thiago, por favor, poderiam informar os temas das palestras de > voc?s? > > Quem mais gostaria de palestrar, sobre qual tema? > > Desde j?, muito obrigado. > > Abra?os, > > Eduardo Maia > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lorn at lornlab.org Mon Jan 5 06:32:31 2015 From: lorn at lornlab.org (Lindolfo Lorn Rodrigues) Date: Mon, 5 Jan 2015 12:32:31 -0200 Subject: [SP-pm] Palestras do ET dia 17/01/2015 In-Reply-To: References: Message-ID: Lindolfo Lorn Rodrigues - Open Source e Perl, o que eu aprendi at? agora. - Perl for humans ( fica mais legal em ingl?s, ? uma ideia meio polemica e ? fortemente baseada no Python for humans ) PS: S?o duas palestras 2015-01-03 14:53 GMT-02:00 Eduardo Maia : > Senhores, > > Gostaria de alinhar quais palestras teremos no dia 17/01/2015, para a > divulga??o do evento. At? o momento, temos: > > Frederico Recsky - Blocks e YAPC > Eduardo Maia - Boas pr?ticas em SQL > Renato Cron - Hypertable > Leandro Leite - Template::Toolkit > Gabiru - ?? > Thiago Rondon - ?? > > Gabiru e Thiago, por favor, poderiam informar os temas das palestras de > voc?s? > > Quem mais gostaria de palestrar, sobre qual tema? > > Desde j?, muito obrigado. > > Abra?os, > > Eduardo Maia > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From thiago at eokoe.com Tue Jan 13 15:56:34 2015 From: thiago at eokoe.com (Thiago Rondon) Date: Tue, 13 Jan 2015 21:56:34 -0200 Subject: [SP-pm] ET 2015 - Janeiro Message-ID: Pessoal, Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos e conversar sobre Perl. O endere?o para cadastro/confirma??o do evento ? http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? ? Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? mostrar como usufruir do CPAN de diversas maneiras e demonstrar m?dulos fant?sticos. Abs! -Thiago Rondon From leonardo at ruoso.com Tue Jan 13 16:16:10 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Tue, 13 Jan 2015 22:16:10 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Qual o tempo de palestra? Em 13 de janeiro de 2015 21:56, Thiago Rondon escreveu: > Pessoal, > > Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo > Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos > e conversar sobre Perl. > > O endere?o para cadastro/confirma??o do evento ? > http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! > > Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? ? > > Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? > mostrar como usufruir do CPAN de diversas maneiras e demonstrar > m?dulos fant?sticos. > > Abs! > -Thiago Rondon > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From thiago at eokoe.com Tue Jan 13 16:27:13 2015 From: thiago at eokoe.com (Thiago Rondon) Date: Tue, 13 Jan 2015 22:27:13 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: A minha ser? de 25 minutos. :-) abs! -Thiago Rondon Em 13 de janeiro de 2015 22:16, Leonardo Ruoso escreveu: > Qual o tempo de palestra? > > > > > > Em 13 de janeiro de 2015 21:56, Thiago Rondon escreveu: >> >> Pessoal, >> >> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >> e conversar sobre Perl. >> >> O endere?o para cadastro/confirma??o do evento ? >> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! >> >> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? ? >> >> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >> m?dulos fant?sticos. >> >> Abs! >> -Thiago Rondon >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From shonorio at gmail.com Tue Jan 13 18:10:57 2015 From: shonorio at gmail.com (Solli Honorio) Date: Wed, 14 Jan 2015 00:10:57 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. Amanh? enviou email com os t?tulos das palestra confirmada. Abra?os, Solli Honorio Em 13 de janeiro de 2015 21:56, Thiago Rondon escreveu: > Pessoal, > > Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo > Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos > e conversar sobre Perl. > > O endere?o para cadastro/confirma??o do evento ? > http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! > > Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? ? > > Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? > mostrar como usufruir do CPAN de diversas maneiras e demonstrar > m?dulos fant?sticos. > > Abs! > -Thiago Rondon > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- "o animal satisfeito dorme". - Guimar?es Rosa -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From maia at eduardomaia.com Tue Jan 13 20:21:18 2015 From: maia at eduardomaia.com (Eduardo Maia) Date: Wed, 14 Jan 2015 02:21:18 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: At? o momento, estamos assim: Frederico Recsky - Blocks e YAPC Eduardo Maia - Boas pr?ticas em SQL Renato Cron - Hypertable Leandro Leite - Template::Toolkit Thiago Rondon - Andando pelo CPAN Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans Gabiru - ?? 2015-01-14 0:10 GMT-02:00 Solli Honorio : > As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. > > Amanh? enviou email com os t?tulos das palestra confirmada. > > Abra?os, > > Solli Honorio > > Em 13 de janeiro de 2015 21:56, Thiago Rondon escreveu: > >> Pessoal, >> >> >> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >> e conversar sobre Perl. >> >> O endere?o para cadastro/confirma??o do evento ? >> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! >> >> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? ? >> >> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >> m?dulos fant?sticos. >> >> Abs! >> -Thiago Rondon >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lorn at lornlab.org Wed Jan 14 10:30:10 2015 From: lorn at lornlab.org (Lindolfo Lorn Rodrigues) Date: Wed, 14 Jan 2015 16:30:10 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: S? reformulando, vou falar s? sobre Open Source e Perl Open Source e Perl: minha historia com o LWP::Curl 2015-01-14 2:21 GMT-02:00 Eduardo Maia : > At? o momento, estamos assim: > > Frederico Recsky - Blocks e YAPC > Eduardo Maia - Boas pr?ticas em SQL > Renato Cron - Hypertable > Leandro Leite - Template::Toolkit > Thiago Rondon - Andando pelo CPAN > Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans > Gabiru - ?? > > > > 2015-01-14 0:10 GMT-02:00 Solli Honorio : > > As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. >> >> Amanh? enviou email com os t?tulos das palestra confirmada. >> >> Abra?os, >> >> Solli Honorio >> >> Em 13 de janeiro de 2015 21:56, Thiago Rondon >> escreveu: >> >>> Pessoal, >>> >>> >>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >>> e conversar sobre Perl. >>> >>> O endere?o para cadastro/confirma??o do evento ? >>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! >>> >>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora l? >>> ? >>> >>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>> m?dulos fant?sticos. >>> >>> Abs! >>> -Thiago Rondon >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From renato.cron at gmail.com Wed Jan 14 10:45:46 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 14 Jan 2015 16:45:46 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: E a minha vai ser sobre testes e cover . Sorry hypertable On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" wrote: > S? reformulando, vou falar s? sobre Open Source e Perl > > Open Source e Perl: minha historia com o LWP::Curl > > 2015-01-14 2:21 GMT-02:00 Eduardo Maia : > >> At? o momento, estamos assim: >> >> Frederico Recsky - Blocks e YAPC >> Eduardo Maia - Boas pr?ticas em SQL >> Renato Cron - Hypertable >> Leandro Leite - Template::Toolkit >> Thiago Rondon - Andando pelo CPAN >> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >> Gabiru - ?? >> >> >> >> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >> >> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. >>> >>> Amanh? enviou email com os t?tulos das palestra confirmada. >>> >>> Abra?os, >>> >>> Solli Honorio >>> >>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>> escreveu: >>> >>>> Pessoal, >>>> >>>> >>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >>>> e conversar sobre Perl. >>>> >>>> O endere?o para cadastro/confirma??o do evento ? >>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! >>>> >>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora >>>> l? ? >>>> >>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>> m?dulos fant?sticos. >>>> >>>> Abs! >>>> -Thiago Rondon >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Wed Jan 14 12:08:18 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Wed, 14 Jan 2015 18:08:18 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo como: Rest rant: lets stop lying to ourselves Em 14/01/2015 16:46, "Renato Santos" escreveu: > E a minha vai ser sobre testes e cover . Sorry hypertable > On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" > wrote: > >> S? reformulando, vou falar s? sobre Open Source e Perl >> >> Open Source e Perl: minha historia com o LWP::Curl >> >> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >> >>> At? o momento, estamos assim: >>> >>> Frederico Recsky - Blocks e YAPC >>> Eduardo Maia - Boas pr?ticas em SQL >>> Renato Cron - Hypertable >>> Leandro Leite - Template::Toolkit >>> Thiago Rondon - Andando pelo CPAN >>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>> Gabiru - ?? >>> >>> >>> >>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>> >>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. >>>> >>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>> >>>> Abra?os, >>>> >>>> Solli Honorio >>>> >>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>> escreveu: >>>> >>>>> Pessoal, >>>>> >>>>> >>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >>>>> e conversar sobre Perl. >>>>> >>>>> O endere?o para cadastro/confirma??o do evento ? >>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o ! >>>>> >>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora >>>>> l? ? >>>>> >>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>> m?dulos fant?sticos. >>>>> >>>>> Abs! >>>>> -Thiago Rondon >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From thiago at eokoe.com Wed Jan 14 13:12:31 2015 From: thiago at eokoe.com (Thiago Rondon) Date: Wed, 14 Jan 2015 19:12:31 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Excelente tema! Em 14/01/2015 18:08, "Leonardo Ruoso" escreveu: > Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo > como: Rest rant: lets stop lying to ourselves > Em 14/01/2015 16:46, "Renato Santos" escreveu: > >> E a minha vai ser sobre testes e cover . Sorry hypertable >> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >> wrote: >> >>> S? reformulando, vou falar s? sobre Open Source e Perl >>> >>> Open Source e Perl: minha historia com o LWP::Curl >>> >>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>> >>>> At? o momento, estamos assim: >>>> >>>> Frederico Recsky - Blocks e YAPC >>>> Eduardo Maia - Boas pr?ticas em SQL >>>> Renato Cron - Hypertable >>>> Leandro Leite - Template::Toolkit >>>> Thiago Rondon - Andando pelo CPAN >>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>> Gabiru - ?? >>>> >>>> >>>> >>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>> >>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. >>>>> >>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>> >>>>> Abra?os, >>>>> >>>>> Solli Honorio >>>>> >>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>> escreveu: >>>>> >>>>>> Pessoal, >>>>>> >>>>>> >>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >>>>>> e conversar sobre Perl. >>>>>> >>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o >>>>>> ! >>>>>> >>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora >>>>>> l? ? >>>>>> >>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>> m?dulos fant?sticos. >>>>>> >>>>>> Abs! >>>>>> -Thiago Rondon >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shonorio at gmail.com Wed Jan 14 13:15:13 2015 From: shonorio at gmail.com (Solli Honorio) Date: Wed, 14 Jan 2015 19:15:13 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias ?? Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso escreveu: > Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo > como: Rest rant: lets stop lying to ourselves > Em 14/01/2015 16:46, "Renato Santos" > escreveu: > >> E a minha vai ser sobre testes e cover . Sorry hypertable >> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" > > wrote: >> >>> S? reformulando, vou falar s? sobre Open Source e Perl >>> >>> Open Source e Perl: minha historia com o LWP::Curl >>> >>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia >> >: >>> >>>> At? o momento, estamos assim: >>>> >>>> Frederico Recsky - Blocks e YAPC >>>> Eduardo Maia - Boas pr?ticas em SQL >>>> Renato Cron - Hypertable >>>> Leandro Leite - Template::Toolkit >>>> Thiago Rondon - Andando pelo CPAN >>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>> Gabiru - ?? >>>> >>>> >>>> >>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio >>> >: >>>> >>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema livre. >>>>> >>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>> >>>>> Abra?os, >>>>> >>>>> Solli Honorio >>>>> >>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>> > escreveu: >>>>> >>>>>> Pessoal, >>>>>> >>>>>> >>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos amigos >>>>>> e conversar sobre Perl. >>>>>> >>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua inscri??o >>>>>> ! >>>>>> >>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. Bora >>>>>> l? ? >>>>>> >>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>> m?dulos fant?sticos. >>>>>> >>>>>> Abs! >>>>>> -Thiago Rondon >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> >>>>>> L >>>>>> =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 at pm.org >>>>> >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> >>> L >>> =end disclaimer >>> >>> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> L >> =end disclaimer >> >> -- Enviado do Gmail para celular -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From leonardo at ruoso.com Wed Jan 14 13:17:25 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Wed, 14 Jan 2015 19:17:25 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Em 14 de janeiro de 2015 19:15, Solli Honorio escreveu: > Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias [image: ??] > Ou refor?ando sua f? na humanidade :/ Ou constatando como as pessoas morram de pregui?a de ler? > > Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso > escreveu: > > Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo >> como: Rest rant: lets stop lying to ourselves >> Em 14/01/2015 16:46, "Renato Santos" escreveu: >> >>> E a minha vai ser sobre testes e cover . Sorry hypertable >>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >>> wrote: >>> >>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>> >>>> Open Source e Perl: minha historia com o LWP::Curl >>>> >>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>> >>>>> At? o momento, estamos assim: >>>>> >>>>> Frederico Recsky - Blocks e YAPC >>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>> Renato Cron - Hypertable >>>>> Leandro Leite - Template::Toolkit >>>>> Thiago Rondon - Andando pelo CPAN >>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>> Gabiru - ?? >>>>> >>>>> >>>>> >>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>> >>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema >>>>>> livre. >>>>>> >>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>> >>>>>> Abra?os, >>>>>> >>>>>> Solli Honorio >>>>>> >>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>>> escreveu: >>>>>> >>>>>>> Pessoal, >>>>>>> >>>>>>> >>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos >>>>>>> amigos >>>>>>> e conversar sobre Perl. >>>>>>> >>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>> inscri??o ! >>>>>>> >>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. >>>>>>> Bora l? ? >>>>>>> >>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>>> m?dulos fant?sticos. >>>>>>> >>>>>>> Abs! >>>>>>> -Thiago Rondon >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> > > -- > Enviado do Gmail para celular > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1265 bytes Descri??o: n?o dispon?vel URL: From shonorio at gmail.com Wed Jan 14 13:30:17 2015 From: shonorio at gmail.com (Solli Honorio) Date: Wed, 14 Jan 2015 19:30:17 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Ou as pessoas est?o lendo de fonte errada ?? Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso escreveu: > Em 14 de janeiro de 2015 19:15, Solli Honorio > escreveu: > >> Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias [image: >> ??] >> > > Ou refor?ando sua f? na humanidade :/ > > Ou constatando como as pessoas morram de pregui?a de ler? > > >> >> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >> leonardo at ruoso.com > >> escreveu: >> >> Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo >>> como: Rest rant: lets stop lying to ourselves >>> Em 14/01/2015 16:46, "Renato Santos" escreveu: >>> >>>> E a minha vai ser sobre testes e cover . Sorry hypertable >>>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >>>> wrote: >>>> >>>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>>> >>>>> Open Source e Perl: minha historia com o LWP::Curl >>>>> >>>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>>> >>>>>> At? o momento, estamos assim: >>>>>> >>>>>> Frederico Recsky - Blocks e YAPC >>>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>>> Renato Cron - Hypertable >>>>>> Leandro Leite - Template::Toolkit >>>>>> Thiago Rondon - Andando pelo CPAN >>>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>>> Gabiru - ?? >>>>>> >>>>>> >>>>>> >>>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>>> >>>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema >>>>>>> livre. >>>>>>> >>>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>>> >>>>>>> Abra?os, >>>>>>> >>>>>>> Solli Honorio >>>>>>> >>>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>>>> escreveu: >>>>>>> >>>>>>>> Pessoal, >>>>>>>> >>>>>>>> >>>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos >>>>>>>> amigos >>>>>>>> e conversar sobre Perl. >>>>>>>> >>>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>>> inscri??o ! >>>>>>>> >>>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. >>>>>>>> Bora l? ? >>>>>>>> >>>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>>>> m?dulos fant?sticos. >>>>>>>> >>>>>>>> Abs! >>>>>>>> -Thiago Rondon >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >> >> -- >> Enviado do Gmail para celular >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> L >> =end disclaimer >> >> > > > -- > Leonardo Ruoso > Journalist, Perl developer and business consultant > Media, UFC/2006; Telecom, IFCE/1998 > -- Enviado do Gmail para celular -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1265 bytes Descri??o: n?o dispon?vel URL: From leonardo at ruoso.com Wed Jan 14 13:55:21 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Wed, 14 Jan 2015 19:55:21 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: H? relatos oficiais de que monografias s?o consideradas entediantes :) Em 14/01/2015 19:30, "Solli Honorio" escreveu: > Ou as pessoas est?o lendo de fonte errada ?? > > Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso > escreveu: > >> Em 14 de janeiro de 2015 19:15, Solli Honorio >> escreveu: >> >>> Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias [image: >>> ??] >>> >> >> Ou refor?ando sua f? na humanidade :/ >> >> Ou constatando como as pessoas morram de pregui?a de ler? >> >> >>> >>> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >>> leonardo at ruoso.com> escreveu: >>> >>> Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo >>>> como: Rest rant: lets stop lying to ourselves >>>> Em 14/01/2015 16:46, "Renato Santos" escreveu: >>>> >>>>> E a minha vai ser sobre testes e cover . Sorry hypertable >>>>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >>>>> wrote: >>>>> >>>>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>>>> >>>>>> Open Source e Perl: minha historia com o LWP::Curl >>>>>> >>>>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>>>> >>>>>>> At? o momento, estamos assim: >>>>>>> >>>>>>> Frederico Recsky - Blocks e YAPC >>>>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>>>> Renato Cron - Hypertable >>>>>>> Leandro Leite - Template::Toolkit >>>>>>> Thiago Rondon - Andando pelo CPAN >>>>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>>>> Gabiru - ?? >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>>>> >>>>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema >>>>>>>> livre. >>>>>>>> >>>>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>>>> >>>>>>>> Abra?os, >>>>>>>> >>>>>>>> Solli Honorio >>>>>>>> >>>>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>>>>> escreveu: >>>>>>>> >>>>>>>>> Pessoal, >>>>>>>>> >>>>>>>>> >>>>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos >>>>>>>>> amigos >>>>>>>>> e conversar sobre Perl. >>>>>>>>> >>>>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>>>> inscri??o ! >>>>>>>>> >>>>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. >>>>>>>>> Bora l? ? >>>>>>>>> >>>>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>>>>> m?dulos fant?sticos. >>>>>>>>> >>>>>>>>> Abs! >>>>>>>>> -Thiago Rondon >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>> >>> -- >>> Enviado do Gmail para celular >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> >> >> -- >> Leonardo Ruoso >> Journalist, Perl developer and business consultant >> Media, UFC/2006; Telecom, IFCE/1998 >> > > > -- > Enviado do Gmail para celular > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1265 bytes Descri??o: n?o dispon?vel URL: From leonardo at ruoso.com Wed Jan 14 14:05:47 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Wed, 14 Jan 2015 20:05:47 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Em 14 de janeiro de 2015 19:30, Solli Honorio escreveu: > Ou as pessoas est?o lendo de fonte errada [image: ??] > Ou n?o checam as refer?ncias :p > > Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso > escreveu: > >> Em 14 de janeiro de 2015 19:15, Solli Honorio >> escreveu: >> >>> Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias [image: >>> ??] >>> >> >> Ou refor?ando sua f? na humanidade :/ >> >> Ou constatando como as pessoas morram de pregui?a de ler? >> >> >>> >>> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >>> leonardo at ruoso.com> escreveu: >>> >>> Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer algo >>>> como: Rest rant: lets stop lying to ourselves >>>> Em 14/01/2015 16:46, "Renato Santos" escreveu: >>>> >>>>> E a minha vai ser sobre testes e cover . Sorry hypertable >>>>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >>>>> wrote: >>>>> >>>>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>>>> >>>>>> Open Source e Perl: minha historia com o LWP::Curl >>>>>> >>>>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>>>> >>>>>>> At? o momento, estamos assim: >>>>>>> >>>>>>> Frederico Recsky - Blocks e YAPC >>>>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>>>> Renato Cron - Hypertable >>>>>>> Leandro Leite - Template::Toolkit >>>>>>> Thiago Rondon - Andando pelo CPAN >>>>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>>>> Gabiru - ?? >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>>>> >>>>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema >>>>>>>> livre. >>>>>>>> >>>>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>>>> >>>>>>>> Abra?os, >>>>>>>> >>>>>>>> Solli Honorio >>>>>>>> >>>>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>>>>> escreveu: >>>>>>>> >>>>>>>>> Pessoal, >>>>>>>>> >>>>>>>>> >>>>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o Paulo >>>>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos >>>>>>>>> amigos >>>>>>>>> e conversar sobre Perl. >>>>>>>>> >>>>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>>>> inscri??o ! >>>>>>>>> >>>>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. >>>>>>>>> Bora l? ? >>>>>>>>> >>>>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>>>>> m?dulos fant?sticos. >>>>>>>>> >>>>>>>>> Abs! >>>>>>>>> -Thiago Rondon >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>> >>> -- >>> Enviado do Gmail para celular >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> >> >> -- >> Leonardo Ruoso >> Journalist, Perl developer and business consultant >> Media, UFC/2006; Telecom, IFCE/1998 >> > > > -- > Enviado do Gmail para celular > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1155 bytes Descri??o: n?o dispon?vel URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1265 bytes Descri??o: n?o dispon?vel URL: From andre at andrewalker.net Thu Jan 15 17:55:45 2015 From: andre at andrewalker.net (=?ISO-8859-1?Q?Andr=E9_Walker?=) Date: Thu, 15 Jan 2015 23:55:45 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: Ainda d? tempo de adicionar mais uma? Quero falar sobre o desenvolvimento do meu m?dulo mais recente no CPAN, o WebService::DigitalOcean. Em 14 de janeiro de 2015 20:05:47 BRST, Leonardo Ruoso escreveu: >Em 14 de janeiro de 2015 19:30, Solli Honorio >escreveu: > >> Ou as pessoas est?o lendo de fonte errada [image: ??] >> > >Ou n?o checam as refer?ncias :p > > > >> >> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso > >> escreveu: >> >>> Em 14 de janeiro de 2015 19:15, Solli Honorio >>> escreveu: >>> >>>> Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias >[image: >>>> ??] >>>> >>> >>> Ou refor?ando sua f? na humanidade :/ >>> >>> Ou constatando como as pessoas morram de pregui?a de ler? >>> >>> >>>> >>>> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >>>> leonardo at ruoso.com> escreveu: >>>> >>>> Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer >algo >>>>> como: Rest rant: lets stop lying to ourselves >>>>> Em 14/01/2015 16:46, "Renato Santos" >escreveu: >>>>> >>>>>> E a minha vai ser sobre testes e cover . Sorry hypertable >>>>>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" > >>>>>> wrote: >>>>>> >>>>>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>>>>> >>>>>>> Open Source e Perl: minha historia com o LWP::Curl >>>>>>> >>>>>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>>>>> >>>>>>>> At? o momento, estamos assim: >>>>>>>> >>>>>>>> Frederico Recsky - Blocks e YAPC >>>>>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>>>>> Renato Cron - Hypertable >>>>>>>> Leandro Leite - Template::Toolkit >>>>>>>> Thiago Rondon - Andando pelo CPAN >>>>>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>>>>> Gabiru - ?? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>>>>> >>>>>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com >tema >>>>>>>>> livre. >>>>>>>>> >>>>>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>>>>> >>>>>>>>> Abra?os, >>>>>>>>> >>>>>>>>> Solli Honorio >>>>>>>>> >>>>>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon > >>>>>>>>> escreveu: >>>>>>>>> >>>>>>>>>> Pessoal, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o >Paulo >>>>>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos >velhos >>>>>>>>>> amigos >>>>>>>>>> e conversar sobre Perl. >>>>>>>>>> >>>>>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>>>>> inscri??o ! >>>>>>>>>> >>>>>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos >palestrantes. >>>>>>>>>> Bora l? ? >>>>>>>>>> >>>>>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da >palestra ? >>>>>>>>>> mostrar como usufruir do CPAN de diversas maneiras e >demonstrar >>>>>>>>>> m?dulos fant?sticos. >>>>>>>>>> >>>>>>>>>> Abs! >>>>>>>>>> -Thiago Rondon >>>>>>>>>> =begin disclaimer >>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>> >>>> -- >>>> Enviado do Gmail para celular >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> >>> -- >>> Leonardo Ruoso >>> Journalist, Perl developer and business consultant >>> Media, UFC/2006; Telecom, IFCE/1998 >>> >> >> >> -- >> Enviado do Gmail para celular >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L >=end disclaimer -- E-mail enviado do meu celular Android usando K-9 Mail. Por favor, desculpe minha brevidade. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shonorio at gmail.com Thu Jan 15 18:18:35 2015 From: shonorio at gmail.com (Solli Honorio) Date: Fri, 16 Jan 2015 00:18:35 -0200 Subject: [SP-pm] ET 2015 - Janeiro In-Reply-To: References: Message-ID: D? sim, mais uma palestra Em quinta-feira, 15 de janeiro de 2015, Andr? Walker escreveu: > Ainda d? tempo de adicionar mais uma? Quero falar sobre o desenvolvimento > do meu m?dulo mais recente no CPAN, o WebService::DigitalOcean. > > Em 14 de janeiro de 2015 20:05:47 BRST, Leonardo Ruoso > escreveu: >> >> Em 14 de janeiro de 2015 19:30, Solli Honorio > > escreveu: >> >>> Ou as pessoas est?o lendo de fonte errada >>> >> >> Ou n?o checam as refer?ncias :p >> >> >> >>> >>> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >>> leonardo at ruoso.com > >>> escreveu: >>> >>>> Em 14 de janeiro de 2015 19:15, Solli Honorio >>>> escreveu: >>>> >>>>> Vish, olhe o Leonardo quebrando as minhas cren?as e ideologias >>>>> >>>> >>>> Ou refor?ando sua f? na humanidade :/ >>>> >>>> Ou constatando como as pessoas morram de pregui?a de ler? >>>> >>>> >>>>> >>>>> Em quarta-feira, 14 de janeiro de 2015, Leonardo Ruoso < >>>>> leonardo at ruoso.com> escreveu: >>>>> >>>>> Eu dificilmente consigo preparar uma apresenta??o, mas posso fazer >>>>>> algo como: Rest rant: lets stop lying to ourselves >>>>>> Em 14/01/2015 16:46, "Renato Santos" >>>>>> escreveu: >>>>>> >>>>>>> E a minha vai ser sobre testes e cover . Sorry hypertable >>>>>>> On Jan 14, 2015 4:30 PM, "Lindolfo Lorn Rodrigues" >>>>>>> wrote: >>>>>>> >>>>>>>> S? reformulando, vou falar s? sobre Open Source e Perl >>>>>>>> >>>>>>>> Open Source e Perl: minha historia com o LWP::Curl >>>>>>>> >>>>>>>> 2015-01-14 2:21 GMT-02:00 Eduardo Maia : >>>>>>>> >>>>>>>>> At? o momento, estamos assim: >>>>>>>>> >>>>>>>>> Frederico Recsky - Blocks e YAPC >>>>>>>>> Eduardo Maia - Boas pr?ticas em SQL >>>>>>>>> Renato Cron - Hypertable >>>>>>>>> Leandro Leite - Template::Toolkit >>>>>>>>> Thiago Rondon - Andando pelo CPAN >>>>>>>>> Lindolfo Lorn Rodrigues - Open Source e Perl + Perl for humans >>>>>>>>> Gabiru - ?? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-01-14 0:10 GMT-02:00 Solli Honorio : >>>>>>>>> >>>>>>>>> As palestras podem ter no m?nimo 10 minutos e m?ximo 30, com tema >>>>>>>>>> livre. >>>>>>>>>> >>>>>>>>>> Amanh? enviou email com os t?tulos das palestra confirmada. >>>>>>>>>> >>>>>>>>>> Abra?os, >>>>>>>>>> >>>>>>>>>> Solli Honorio >>>>>>>>>> >>>>>>>>>> Em 13 de janeiro de 2015 21:56, Thiago Rondon >>>>>>>>>> escreveu: >>>>>>>>>> >>>>>>>>>>> Pessoal, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lembrando que neste s?bado, teremos o encontro t?cnico da S?o >>>>>>>>>>> Paulo >>>>>>>>>>> Perl Mongers. Ser? um momento bacana para reencontrarmos velhos >>>>>>>>>>> amigos >>>>>>>>>>> e conversar sobre Perl. >>>>>>>>>>> >>>>>>>>>>> O endere?o para cadastro/confirma??o do evento ? >>>>>>>>>>> http://lanyrd.com/2015/etperl/. N?o deixem de realizar sua >>>>>>>>>>> inscri??o ! >>>>>>>>>>> >>>>>>>>>>> Vamos palestrar ? Precisamos de pelo menos 5 novos palestrantes. >>>>>>>>>>> Bora l? ? >>>>>>>>>>> >>>>>>>>>>> Minha palestra ser? "Andando pelo CPAN". O objetivo da palestra ? >>>>>>>>>>> mostrar como usufruir do CPAN de diversas maneiras e demonstrar >>>>>>>>>>> m?dulos fant?sticos. >>>>>>>>>>> >>>>>>>>>>> Abs! >>>>>>>>>>> -Thiago Rondon >>>>>>>>>>> =begin disclaimer >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =end disclaimer >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Enviado do Gmail para celular >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> >>>> -- >>>> Leonardo Ruoso >>>> Journalist, Perl developer and business consultant >>>> Media, UFC/2006; Telecom, IFCE/1998 >>>> >>> >>> >>> -- >>> Enviado do Gmail para celular >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> >>> L >>> =end disclaimer >>> >>> >> >> > -- > E-mail enviado do meu celular Android usando K-9 Mail. Por favor, desculpe > minha brevidade. > -- Enviado do Gmail para celular -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1155 bytes Descri??o: n?o dispon?vel URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: n?o dispon?vel Tipo: image/png Tamanho: 1265 bytes Descri??o: n?o dispon?vel URL: From shonorio at gmail.com Mon Jan 19 15:38:03 2015 From: shonorio at gmail.com (Solli Honorio) Date: Mon, 19 Jan 2015 21:38:03 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= Message-ID: Pessoal, Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o prazer de compartilhar conhecimentos interessantes dos palestrantes e a presen?a de pessoas novas, al?m dos habitue. Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento ocorra no dia 21/Mar?o/2015. Obrigado, Solli Honorio -- "o animal satisfeito dorme". - Guimar?es Rosa -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From daniel.oliveira.mantovani at gmail.com Mon Jan 19 17:53:45 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Mon, 19 Jan 2015 23:53:45 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Pessoa, n?o esque?am do Happy Hour depois do evento, o ?ltimo foi at? 05:00. 2015-01-19 21:38 GMT-02:00 Solli Honorio : > Pessoal, > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o > prazer de compartilhar conhecimentos interessantes dos palestrantes e a > presen?a de pessoas novas, al?m dos habitue. > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o > lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento > ocorra no dia 21/Mar?o/2015. > > Obrigado, > > Solli Honorio > > -- > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago at eokoe.com Mon Jan 19 17:54:31 2015 From: thiago at eokoe.com (Thiago Rondon) Date: Mon, 19 Jan 2015 23:54:31 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Boa Solli! Estarei l?! Abs! -Thiago Rondon Em 19 de janeiro de 2015 21:38, Solli Honorio escreveu: > Pessoal, > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o > prazer de compartilhar conhecimentos interessantes dos palestrantes e a > presen?a de pessoas novas, al?m dos habitue. > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o > lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento > ocorra no dia 21/Mar?o/2015. > > Obrigado, > > Solli Honorio > > -- > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardostock at bol.com.br Tue Jan 20 02:29:52 2015 From: ricardostock at bol.com.br (Ricardo Stock) Date: Tue, 20 Jan 2015 08:29:52 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: <679C8FA87CB84A3BB92230BBA4A053CA@PcRicardo> Foi uma pena n?o poder ter ido nesse. Uma pena mesmo Mas tentarei no pr?ximo ! Ricardo Stock www.stocksistemas.com.br From: Solli Honorio Sent: Monday, January 19, 2015 9:38 PM To: saopaulo-pm at mail.pm.org Subject: [SP-pm] Resumo do Evento T?cnico Pessoal, Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o prazer de compartilhar conhecimentos interessantes dos palestrantes e a presen?a de pessoas novas, al?m dos habitue. Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento ocorra no dia 21/Mar?o/2015. Obrigado, Solli Honorio -- "o animal satisfeito dorme". - Guimar?es Rosa -------------------------------------------------------------------------------- =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org L =end disclaimer --- Este email foi escaneado pelo Avast antiv?rus. http://www.avast.com -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lucasmateus.oliveira at gmail.com Tue Jan 20 04:04:31 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Tue, 20 Jan 2015 10:04:31 -0200 Subject: [SP-pm] =?iso-8859-1?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: Message-ID: Show de bola, ja vou deixar a minha apresenta??o pronta, dessa vez vou levar alguma coisa legal pra falar. Parab?ns Solli. Em 19/01/2015, ?(s) 21:38, Solli Honorio escreveu: > Pessoal, > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o prazer de compartilhar conhecimentos interessantes dos palestrantes e a presen?a de pessoas novas, al?m dos habitue. > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento ocorra no dia 21/Mar?o/2015. > > Obrigado, > > Solli Honorio > > -- > "o animal satisfeito dorme". - Guimar?es Rosa > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer From lorn at lornlab.org Tue Jan 20 07:20:20 2015 From: lorn at lornlab.org (Lindolfo Lorn Rodrigues) Date: Tue, 20 Jan 2015 13:20:20 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Mar?o s?o 2 meses n?o? Com o poss?vel equin?cio em Mar?o, n?o seria melhor que o evento fosse em Abril? 2015-01-20 10:04 GMT-02:00 Lucas Mateus : > > Show de bola, ja vou deixar a minha apresenta??o pronta, dessa vez > vou levar alguma coisa legal pra falar. > > Parab?ns Solli. > > Em 19/01/2015, ?(s) 21:38, Solli Honorio escreveu: > > > Pessoal, > > > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o > prazer de compartilhar conhecimentos interessantes dos palestrantes e a > presen?a de pessoas novas, al?m dos habitue. > > > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o > lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento > ocorra no dia 21/Mar?o/2015. > > > > Obrigado, > > > > Solli Honorio > > > > -- > > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > > L > > =end disclaimer > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lucasmateus.oliveira at gmail.com Tue Jan 20 07:21:23 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Tue, 20 Jan 2015 13:21:23 -0200 Subject: [SP-pm] =?iso-8859-1?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: Message-ID: <4EAC555D-2784-42B8-A079-54B8992AE2AC@gmail.com> P? Mar?o ? melhor :) Abril eu n?o estarei por aqui :P Em 20/01/2015, ?(s) 13:20, Lindolfo Lorn Rodrigues escreveu: > Mar?o s?o 2 meses n?o? > Com o poss?vel equin?cio em Mar?o, n?o seria melhor que o evento fosse em Abril? > > > 2015-01-20 10:04 GMT-02:00 Lucas Mateus : > > Show de bola, ja vou deixar a minha apresenta??o pronta, dessa vez vou levar alguma coisa legal pra falar. > > Parab?ns Solli. > > Em 19/01/2015, ?(s) 21:38, Solli Honorio escreveu: > > > Pessoal, > > > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o prazer de compartilhar conhecimentos interessantes dos palestrantes e a presen?a de pessoas novas, al?m dos habitue. > > > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento ocorra no dia 21/Mar?o/2015. > > > > Obrigado, > > > > Solli Honorio > > > > -- > > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > > L > > =end disclaimer > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From gabriel.vieira at gmail.com Tue Jan 20 07:22:43 2015 From: gabriel.vieira at gmail.com (Gabriel Vieira) Date: Tue, 20 Jan 2015 10:22:43 -0500 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Se tiver em Abril estarei presente \o/ 2015-01-20 10:20 GMT-05:00 Lindolfo Lorn Rodrigues : > Mar?o s?o 2 meses n?o? > Com o poss?vel equin?cio em Mar?o, n?o seria melhor que o evento fosse em > Abril? > > > 2015-01-20 10:04 GMT-02:00 Lucas Mateus : > > >> Show de bola, ja vou deixar a minha apresenta??o pronta, dessa >> vez vou levar alguma coisa legal pra falar. >> >> Parab?ns Solli. >> >> Em 19/01/2015, ?(s) 21:38, Solli Honorio escreveu: >> >> > Pessoal, >> > >> > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >> presen?a de pessoas novas, al?m dos habitue. >> > >> > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o >> lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >> ocorra no dia 21/Mar?o/2015. >> > >> > Obrigado, >> > >> > Solli Honorio >> > >> > -- >> > "o animal satisfeito dorme". - Guimar?es Rosa >> > =begin disclaimer >> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> > L >> > =end disclaimer >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Gabriel Vieira -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From leonardo at ruoso.com Sun Jan 25 12:45:46 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 25 Jan 2015 18:45:46 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Solli, Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, convidar a comunidade para escrever artigos sobre como implementar Restful, desde os b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; (2) Qual a diferen?a entre stateful and stateless?; (3) Por que se o seu client usar informa??o out-of-band para definir intera??es com o seu server seu software n?o pode ser considerado Restful?; (3) Quaos as diferen?as entre RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais as melhores formas para negociar formato e vers?o entre o cliente e o servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; (8) AngularJS e Restful services. (9) etc.. 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. Um grande abra?o, Em 19 de janeiro de 2015 21:38, Solli Honorio escreveu: > Pessoal, > > Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o > prazer de compartilhar conhecimentos interessantes dos palestrantes e a > presen?a de pessoas novas, al?m dos habitue. > > Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o > lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento > ocorra no dia 21/Mar?o/2015. > > Obrigado, > > Solli Honorio > > -- > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Sun Jan 25 14:30:30 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Sun, 25 Jan 2015 20:30:30 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Ruoso, eu j? vi pessoas mandando todas as transa??es REST sobre POST, seja para criar, atualizar, ler ou apagar. Eu toparia fazer parte de um grupo de estudos para me autualizar em REST. Abs, Em 25 de janeiro de 2015 18:45, Leonardo Ruoso escreveu: > Solli, > > Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. > > Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, convidar a > comunidade para escrever artigos sobre como implementar Restful, desde os > b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; (2) Qual a > diferen?a entre stateful and stateless?; (3) Por que se o seu client usar > informa??o out-of-band para definir intera??es com o seu server seu > software n?o pode ser considerado Restful?; (3) Quaos as diferen?as entre > RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para > implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais > as melhores formas para negociar formato e vers?o entre o cliente e o > servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de > implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; > (8) AngularJS e Restful services. (9) etc.. > > 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. > > Um grande abra?o, > > > Em 19 de janeiro de 2015 21:38, Solli Honorio > escreveu: > >> Pessoal, >> >> Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >> presen?a de pessoas novas, al?m dos habitue. >> >> Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o >> lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >> ocorra no dia 21/Mar?o/2015. >> >> Obrigado, >> >> Solli Honorio >> >> -- >> "o animal satisfeito dorme". - Guimar?es Rosa >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sun Jan 25 14:45:38 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 25 Jan 2015 20:45:38 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Kojo, O estilo seria mais de aprendizado cooperativo do que eu tentando propriamente ensinar. Acho que coletivamente temos condi??es de produzir um material bem interessante exatamente enquanto aprendemos sobre um assunto. Sendo assim, eu acredito que todo mundo que quiser se comprometer pode ir ajudando desde j? a montar um TOC para o pr?ximo equin?cio, que seria algo como "Designing (True) Restful Applications". Dito isso eu penso que podemos marcar umas reuni?es presenciais se conseguirmos alguma sala e para conseguir isso depende de termos pessoas interessadas (fica chato pra burro pedir sala e ir 3 ou 4 pessoas somente). Ideal mesmo ? que a gente conseguisse ter umas 7 pessoas, cada uma pensando em escrever 3 artigos e revisar outros 3 (um de cada uma das outras 3 pessoas) para o pr?ximo equin?cio. Quem tiver interesse vai sinalizando na lista. PS: (N?s nos conhecemos?) Em 25 de janeiro de 2015 20:30, Kojo escreveu: > Ruoso, > eu j? vi pessoas mandando todas as transa??es REST sobre POST, seja para > criar, atualizar, ler ou apagar. Eu toparia fazer parte de um grupo de > estudos para me autualizar em REST. > > Abs, > > > Em 25 de janeiro de 2015 18:45, Leonardo Ruoso > escreveu: > > Solli, >> >> Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. >> >> Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, convidar >> a comunidade para escrever artigos sobre como implementar Restful, desde os >> b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; (2) Qual a >> diferen?a entre stateful and stateless?; (3) Por que se o seu client usar >> informa??o out-of-band para definir intera??es com o seu server seu >> software n?o pode ser considerado Restful?; (3) Quaos as diferen?as entre >> RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para >> implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais >> as melhores formas para negociar formato e vers?o entre o cliente e o >> servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de >> implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; >> (8) AngularJS e Restful services. (9) etc.. >> >> 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. >> >> Um grande abra?o, >> >> >> Em 19 de janeiro de 2015 21:38, Solli Honorio >> escreveu: >> >>> Pessoal, >>> >>> Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >>> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >>> presen?a de pessoas novas, al?m dos habitue. >>> >>> Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o >>> lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >>> ocorra no dia 21/Mar?o/2015. >>> >>> Obrigado, >>> >>> Solli Honorio >>> >>> -- >>> "o animal satisfeito dorme". - Guimar?es Rosa >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Sun Jan 25 15:33:40 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Sun, 25 Jan 2015 21:33:40 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Estou definindo algumas coisas profissionais, se eu estiver com tempo eu topo participar, gostei do formato proposto. Na verdade estou definindo um trampo, se for com o pessoal de Perl melhor, fica mais perto. :) Eu estava l? no ?ltimo encontro. Abs, Em 25 de janeiro de 2015 20:45, Leonardo Ruoso escreveu: > Kojo, > > O estilo seria mais de aprendizado cooperativo do que eu tentando > propriamente ensinar. Acho que coletivamente temos condi??es de produzir um > material bem interessante exatamente enquanto aprendemos sobre um assunto. > Sendo assim, eu acredito que todo mundo que quiser se comprometer pode ir > ajudando desde j? a montar um TOC para o pr?ximo equin?cio, que seria algo > como "Designing (True) Restful Applications". > > Dito isso eu penso que podemos marcar umas reuni?es presenciais se > conseguirmos alguma sala e para conseguir isso depende de termos pessoas > interessadas (fica chato pra burro pedir sala e ir 3 ou 4 pessoas somente). > Ideal mesmo ? que a gente conseguisse ter umas 7 pessoas, cada uma pensando > em escrever 3 artigos e revisar outros 3 (um de cada uma das outras 3 > pessoas) para o pr?ximo equin?cio. > > Quem tiver interesse vai sinalizando na lista. > > PS: (N?s nos conhecemos?) > > > Em 25 de janeiro de 2015 20:30, Kojo escreveu: > > Ruoso, >> eu j? vi pessoas mandando todas as transa??es REST sobre POST, seja para >> criar, atualizar, ler ou apagar. Eu toparia fazer parte de um grupo de >> estudos para me autualizar em REST. >> >> Abs, >> >> >> Em 25 de janeiro de 2015 18:45, Leonardo Ruoso >> escreveu: >> >> Solli, >>> >>> Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. >>> >>> Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, convidar >>> a comunidade para escrever artigos sobre como implementar Restful, desde os >>> b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; (2) Qual a >>> diferen?a entre stateful and stateless?; (3) Por que se o seu client usar >>> informa??o out-of-band para definir intera??es com o seu server seu >>> software n?o pode ser considerado Restful?; (3) Quaos as diferen?as entre >>> RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para >>> implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais >>> as melhores formas para negociar formato e vers?o entre o cliente e o >>> servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de >>> implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; >>> (8) AngularJS e Restful services. (9) etc.. >>> >>> 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. >>> >>> Um grande abra?o, >>> >>> >>> Em 19 de janeiro de 2015 21:38, Solli Honorio >>> escreveu: >>> >>>> Pessoal, >>>> >>>> Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >>>> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >>>> presen?a de pessoas novas, al?m dos habitue. >>>> >>>> Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver o >>>> lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >>>> ocorra no dia 21/Mar?o/2015. >>>> >>>> Obrigado, >>>> >>>> Solli Honorio >>>> >>>> -- >>>> "o animal satisfeito dorme". - Guimar?es Rosa >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sun Jan 25 15:44:05 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 25 Jan 2015 21:44:05 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Kojo, Dizem que n?o falta trabalho para o pessoal de Perl, e olha que na minha experi?ncia a taxa de produtividade em Perl seja na casa de 9:1 comparado com Java, por exemplo. Por outro lado, o Spring.IO est? vindo com tudo, uma solu??o de dar inveja. Inclusive j? est?o avan?ando no suporte a Rest/Hateoas. Abra?os, Em 25 de janeiro de 2015 21:33, Kojo escreveu: > Estou definindo algumas coisas profissionais, se eu estiver com tempo eu > topo participar, gostei do formato proposto. > Na verdade estou definindo um trampo, se for com o pessoal de Perl melhor, > fica mais perto. :) > > Eu estava l? no ?ltimo encontro. > > Abs, > > > > > Em 25 de janeiro de 2015 20:45, Leonardo Ruoso > escreveu: > > Kojo, >> >> O estilo seria mais de aprendizado cooperativo do que eu tentando >> propriamente ensinar. Acho que coletivamente temos condi??es de produzir um >> material bem interessante exatamente enquanto aprendemos sobre um assunto. >> Sendo assim, eu acredito que todo mundo que quiser se comprometer pode ir >> ajudando desde j? a montar um TOC para o pr?ximo equin?cio, que seria algo >> como "Designing (True) Restful Applications". >> >> Dito isso eu penso que podemos marcar umas reuni?es presenciais se >> conseguirmos alguma sala e para conseguir isso depende de termos pessoas >> interessadas (fica chato pra burro pedir sala e ir 3 ou 4 pessoas somente). >> Ideal mesmo ? que a gente conseguisse ter umas 7 pessoas, cada uma pensando >> em escrever 3 artigos e revisar outros 3 (um de cada uma das outras 3 >> pessoas) para o pr?ximo equin?cio. >> >> Quem tiver interesse vai sinalizando na lista. >> >> PS: (N?s nos conhecemos?) >> >> >> Em 25 de janeiro de 2015 20:30, Kojo escreveu: >> >> Ruoso, >>> eu j? vi pessoas mandando todas as transa??es REST sobre POST, seja para >>> criar, atualizar, ler ou apagar. Eu toparia fazer parte de um grupo de >>> estudos para me autualizar em REST. >>> >>> Abs, >>> >>> >>> Em 25 de janeiro de 2015 18:45, Leonardo Ruoso >>> escreveu: >>> >>> Solli, >>>> >>>> Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. >>>> >>>> Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, >>>> convidar a comunidade para escrever artigos sobre como implementar Restful, >>>> desde os b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; >>>> (2) Qual a diferen?a entre stateful and stateless?; (3) Por que se o seu >>>> client usar informa??o out-of-band para definir intera??es com o seu server >>>> seu software n?o pode ser considerado Restful?; (3) Quaos as diferen?as >>>> entre RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para >>>> implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais >>>> as melhores formas para negociar formato e vers?o entre o cliente e o >>>> servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de >>>> implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; >>>> (8) AngularJS e Restful services. (9) etc.. >>>> >>>> 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. >>>> >>>> Um grande abra?o, >>>> >>>> >>>> Em 19 de janeiro de 2015 21:38, Solli Honorio >>>> escreveu: >>>> >>>>> Pessoal, >>>>> >>>>> Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >>>>> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >>>>> presen?a de pessoas novas, al?m dos habitue. >>>>> >>>>> Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver >>>>> o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >>>>> ocorra no dia 21/Mar?o/2015. >>>>> >>>>> Obrigado, >>>>> >>>>> Solli Honorio >>>>> >>>>> -- >>>>> "o animal satisfeito dorme". - Guimar?es Rosa >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Sun Jan 25 16:12:34 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Sun, 25 Jan 2015 22:12:34 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: Message-ID: Olha Ruoso, eu n?o tenho visto o pessoal passar aperto n?o. Quem se dedica ? ?rea e procura se manter atualizado sempre acha uma oportunidade. Sabe que eu gosto do Java. Para quem n?o veio do C++, como eu (eu n?o vim do C++), o Java foi ?timo para entender bem a formalidade da OO. Mas sem d?vida a produtividade em Perl ? bem maior. Abs, Em 25 de janeiro de 2015 21:44, Leonardo Ruoso escreveu: > Kojo, > > Dizem que n?o falta trabalho para o pessoal de Perl, e olha que na minha > experi?ncia a taxa de produtividade em Perl seja na casa de 9:1 comparado > com Java, por exemplo. > > Por outro lado, o Spring.IO est? vindo com tudo, uma solu??o de dar > inveja. Inclusive j? est?o avan?ando no suporte a Rest/Hateoas. > > Abra?os, > > > Em 25 de janeiro de 2015 21:33, Kojo escreveu: > > Estou definindo algumas coisas profissionais, se eu estiver com tempo eu >> topo participar, gostei do formato proposto. >> Na verdade estou definindo um trampo, se for com o pessoal de Perl >> melhor, fica mais perto. :) >> >> Eu estava l? no ?ltimo encontro. >> >> Abs, >> >> >> >> >> Em 25 de janeiro de 2015 20:45, Leonardo Ruoso >> escreveu: >> >> Kojo, >>> >>> O estilo seria mais de aprendizado cooperativo do que eu tentando >>> propriamente ensinar. Acho que coletivamente temos condi??es de produzir um >>> material bem interessante exatamente enquanto aprendemos sobre um assunto. >>> Sendo assim, eu acredito que todo mundo que quiser se comprometer pode ir >>> ajudando desde j? a montar um TOC para o pr?ximo equin?cio, que seria algo >>> como "Designing (True) Restful Applications". >>> >>> Dito isso eu penso que podemos marcar umas reuni?es presenciais se >>> conseguirmos alguma sala e para conseguir isso depende de termos pessoas >>> interessadas (fica chato pra burro pedir sala e ir 3 ou 4 pessoas somente). >>> Ideal mesmo ? que a gente conseguisse ter umas 7 pessoas, cada uma pensando >>> em escrever 3 artigos e revisar outros 3 (um de cada uma das outras 3 >>> pessoas) para o pr?ximo equin?cio. >>> >>> Quem tiver interesse vai sinalizando na lista. >>> >>> PS: (N?s nos conhecemos?) >>> >>> >>> Em 25 de janeiro de 2015 20:30, Kojo escreveu: >>> >>> Ruoso, >>>> eu j? vi pessoas mandando todas as transa??es REST sobre POST, seja >>>> para criar, atualizar, ler ou apagar. Eu toparia fazer parte de um grupo de >>>> estudos para me autualizar em REST. >>>> >>>> Abs, >>>> >>>> >>>> Em 25 de janeiro de 2015 18:45, Leonardo Ruoso >>>> escreveu: >>>> >>>> Solli, >>>>> >>>>> Eu acabei deixando meu rant por ?ltimo e as pessoas escaparam dele. >>>>> >>>>> Ent?o, como dia 21 de mar?o ? (~) tamb?m o equin?cio de outono, >>>>> convidar a comunidade para escrever artigos sobre como implementar Restful, >>>>> desde os b?sicos como (1) O que ? um HyperDocument e o que ? Linked Data; >>>>> (2) Qual a diferen?a entre stateful and stateless?; (3) Por que se o seu >>>>> client usar informa??o out-of-band para definir intera??es com o seu server >>>>> seu software n?o pode ser considerado Restful?; (3) Quaos as diferen?as >>>>> entre RPC e Rest?; (4) Quais os padr?es ou recomenda??es dispon?veis para >>>>> implementa??o de software Rest representado em HTML, XML e JSON?; (5) Quais >>>>> as melhores formas para negociar formato e vers?o entre o cliente e o >>>>> servidor em uma aplica??o Rest? (6) Qual o estado da arte em se tratando de >>>>> implementar Restful em Perl?; (7) Misturando Restful, SockJS e RabbitMQ; >>>>> (8) AngularJS e Restful services. (9) etc.. >>>>> >>>>> 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. >>>>> >>>>> Um grande abra?o, >>>>> >>>>> >>>>> Em 19 de janeiro de 2015 21:38, Solli Honorio >>>>> escreveu: >>>>> >>>>>> Pessoal, >>>>>> >>>>>> Felizmente o retorno do Evento T?cnico ocorreu com sucesso, tivemos o >>>>>> prazer de compartilhar conhecimentos interessantes dos palestrantes e a >>>>>> presen?a de pessoas novas, al?m dos habitue. >>>>>> >>>>>> Me comprometi que o evento ser? realizado a cada 3 meses, se eu tiver >>>>>> o lugar para realizar o evento, e a minha sugest?o ? que o pr?ximo evento >>>>>> ocorra no dia 21/Mar?o/2015. >>>>>> >>>>>> Obrigado, >>>>>> >>>>>> Solli Honorio >>>>>> >>>>>> -- >>>>>> "o animal satisfeito dorme". - Guimar?es Rosa >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucasmateus.oliveira at gmail.com Mon Jan 26 08:51:33 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Mon, 26 Jan 2015 14:51:33 -0200 Subject: [SP-pm] =?iso-8859-1?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: Message-ID: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From renato.cron at gmail.com Mon Jan 26 08:54:44 2015 From: renato.cron at gmail.com (Renato Santos) Date: Mon, 26 Jan 2015 14:54:44 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: 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 : > > Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Mon Jan 26 12:14:02 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Mon, 26 Jan 2015 18:14:02 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: Em 26 de janeiro de 2015 14:54, Renato Santos escreveu: > Eu posso me juntar, mas j? digo que eu s? fa?o API's REST, n?o RESTFul, > Rest ou Restful: Se n?o ? hyperdocument n?o ? Rest. Se tem informa??o out-of-band n?o ? Rest. Quem disse que a API tem de ser Rest e n?o JSON-RPC ou XML-RPC? e que nunca ouvi falar de HyperDocument > HyperDocument ? basicamente como a WWW funciona :p > e que linked-data pra mim tem que ser em RDF! > LinkedData pode ser RDF, mas pode ser JSON-LD tamb?m. Renato, e Hateoas? > 2015-01-26 14:51 GMT-02:00 Lucas Mateus : > >> >> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 at pm.org >> L >> =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 at pm.org > L > =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: From leonardo at ruoso.com Mon Jan 26 12:18:16 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Mon, 26 Jan 2015 18:18:16 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: 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 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 : > >> >> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 at pm.org >> L >> =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 at pm.org > L > =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: From lucasmateus.oliveira at gmail.com Mon Jan 26 12:20:53 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Mon, 26 Jan 2015 18:20:53 -0200 Subject: [SP-pm] =?iso-8859-1?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Eu uso o Catalyst::Controller::REST que implementa todo o ?sexo dos anjos? pra mim e vou ser feliz :D Em 26/01/2015, ?(s) 18:18, Leonardo Ruoso 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 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 : > > Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 at pm.org > L > =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 at pm.org > L > =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 at pm.org > L > =end disclaimer -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From renato.cron at gmail.com Mon Jan 26 12:54:15 2015 From: renato.cron at gmail.com (Renato Santos) Date: Mon, 26 Jan 2015 18:54:15 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: 2015-01-26 18:14 GMT-02:00 Leonardo Ruoso : > Em 26 de janeiro de 2015 14:54, Renato Santos > escreveu: > >> Eu posso me juntar, mas j? digo que eu s? fa?o API's REST, n?o RESTFul, >> > Rest ou Restful: > > Se n?o ? hyperdocument n?o ? Rest. > Se tem informa??o out-of-band n?o ? Rest. > Se informa??es out-of-band s?o informa??es que fazem o protocolo ser stateful, sim, ? web[1], n?o ? REST! > Quem disse que a API tem de ser Rest e n?o JSON-RPC ou XML-RPC? > Boa pergunta, n?o sei... algum preconceito com o RPC, provavelmente. Mas pode estar mudando com a chegada de microservices > > e que nunca ouvi falar de HyperDocument >> > > HyperDocument ? basicamente como a WWW funciona :p > > >> e que linked-data pra mim tem que ser em RDF! >> > > LinkedData pode ser RDF, mas pode ser JSON-LD tamb?m. > Concordo. Um ponto interessante, ? que, ao meu ver, para consultar as informa??es com SPARQL ? bem devagar se comparar com os bancos tradicionais, embora tenha alguns bancos especializados neste tipo de opera??es. > > Renato, e Hateoas? > Nunca implementei este conceito. > > [1] considerando que muita gente faz coisa errada com os cookies, aka, salvar informa??es 'out of band' Nas API's que geralmente fa?o, apenas no 'CREATE' do recurso, que eu retorno o header Location com o URI do objecto criado. Mas pensando bem, n?o seria dif?cil expandir os resultados para retornar a URI dos recursos em todos os lugares, ex: GET /books === 200 OK content-type: application/json { rows: [ { uri: "/books/barz-mozz", name => "barz", author => { uri => "/author/mozz-2", name => "mozz" } }, { uri: "/books/2", name => "pous", ... } ], has_more: 0 } GET /books/barz-mozz-2 === 200 OK content-type: application/json { self: { uri: "/foo/1", name => "barz" }, result_of => "/foo" } ===== n?o querendo fugir do assunto, mas eu estou no momento pensando muito mais em desnormaliza??o, bancos(ideologia) "append-only" e versionamento do que no protocolo da API. Acho que podemos come?ar pelo banco, at? subir e chegar na camada de apresenta??o/input. -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Mon Jan 26 15:03:56 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Mon, 26 Jan 2015 21:03:56 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> Message-ID: Em 26 de janeiro de 2015 18:54, Renato Santos escreveu: > 2015-01-26 18:14 GMT-02:00 Leonardo Ruoso : > >> Em 26 de janeiro de 2015 14:54, Renato Santos >> escreveu: >> >>> Eu posso me juntar, mas j? digo que eu s? fa?o API's REST, n?o RESTFul, >>> >> Rest ou Restful: >> >> Se n?o ? hyperdocument n?o ? Rest. >> Se tem informa??o out-of-band n?o ? Rest. >> > > Se informa??es out-of-band s?o informa??es que fazem o protocolo > ser stateful, sim, ? web[1], n?o ? REST! > Web ? muito amplo, mas de uma forma geral Rest ? a aplica??o da Web para Software. > Quem disse que a API tem de ser Rest e n?o JSON-RPC ou XML-RPC? >> > > Boa pergunta, n?o sei... algum preconceito com o RPC, provavelmente. Mas > pode estar mudando com a chegada de microservices > O fato de que com RPC voc? tem obrigatoriamente forte acoplamento de client e server. > e que nunca ouvi falar de HyperDocument >>> >> >> HyperDocument ? basicamente como a WWW funciona :p >> >> >>> e que linked-data pra mim tem que ser em RDF! >>> >> >> LinkedData pode ser RDF, mas pode ser JSON-LD tamb?m. >> > Concordo. > > Um ponto interessante, ? que, ao meu ver, para consultar as informa??es > com SPARQL ? bem devagar se comparar com os bancos tradicionais, embora > tenha alguns bancos especializados neste tipo de opera??es. > Mas, SPARQL como substituto de search query ou como substituto de SQL? A? rola uma confus?o comum. > Renato, e Hateoas? >> > Nunca implementei este conceito. > > >> [1] considerando que muita gente faz coisa errada com os cookies, aka, > salvar informa??es 'out of band' > > Nas API's que geralmente fa?o, apenas no 'CREATE' do recurso, que eu > retorno o header Location com o URI do objecto criado. > Mas pensando bem, n?o seria dif?cil expandir os resultados para retornar a > URI dos recursos em todos os lugares, ex: > > GET /books > === > 200 OK > content-type: application/json > > { rows: [ { uri: "/books/barz-mozz", name => "barz", author => { uri => > "/author/mozz-2", name => "mozz" } }, { uri: "/books/2", name => "pous", > ... } ], has_more: 0 } > > GET /books/barz-mozz-2 > === > 200 OK > content-type: application/json > > { self: { uri: "/foo/1", name => "barz" }, result_of => "/foo" } > > ===== > Ent?o, a quest?o ? que tamb?m, como "engenheiros" dever?amos estar muito preocupados em adotar padr?es ou recomenda??es, de modo que no caso de JSON dever?amos ver muito mais JSON-Schema e JSON-LD em nossos exemplos do dia-a-dia: @id, _link, _embedded e etc... j? deveriam ser parte do nosso meta-vocabul?rio de desenvolvedores. > n?o querendo fugir do assunto, mas eu estou no momento pensando muito mais > em desnormaliza??o, bancos(ideologia) "append-only" e versionamento do que > no protocolo da API. > Desnormaliza??o como Materializa??o de View faz todo o sentido por motivos de performance. Versionamento ? uma discuss?o fundamental quando falamos de Rest. Uma outra discuss?o important?ssima, a meu ver, ? ACL e com ACL vem SSO e vem LDAP/Kerberos, Roles e Realms. > Acho que podemos come?ar pelo banco, at? subir e chegar na camada de > apresenta??o/input. > Eu tenho a tend?ncia de come?ar pelo banco, e poder?amos facilmente sair com um Rest Helper para Catalyst + DBIx::Class. -- > Sarav?, > Renato CRON > http://www.renatocron.com/blog/ > @renato_cro > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Mon Jan 26 15:08:47 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Mon, 26 Jan 2015 21:08:47 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 26 de janeiro de 2015 18:20, Lucas Mateus 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 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 > 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 : >> >>> >>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso 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 at pm.org >>> L >>> =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 at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Mon Jan 26 18:24:31 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Tue, 27 Jan 2015 00:24:31 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Estou pensando e quero compartilhar e ouvir opini?es. O REST ? interessante na conex?o entre aplica??es mas nem sempre a melhor solu??o para integra??o webservice, na minha opini?o. 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. 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. 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. 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. Em 26 de janeiro de 2015 21:08, Leonardo Ruoso escreveu: > > Em 26 de janeiro de 2015 18:20, Lucas Mateus < > lucasmateus.oliveira at 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 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 >> 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 >>> : >>> >>>> >>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>> 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 at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Wed Jan 28 00:39:41 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Wed, 28 Jan 2015 06:39:41 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 27 de janeiro de 2015 00:24, Kojo escreveu: > Estou pensando e quero compartilhar e ouvir opini?es. O REST ? > interessante na conex?o entre aplica??es mas nem sempre a melhor solu??o > para integra??o webservice, na minha opini?o. > Na verdade, Rest seria o ?nico WebService digno desse nome. > 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. > 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? > 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 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. > 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. > > Em 26 de janeiro de 2015 21:08, Leonardo Ruoso > escreveu: > > >> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >> lucasmateus.oliveira at 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 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 >>> 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 >>> >: >>>> >>>>> >>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>> 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 at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Wed Jan 28 04:45:35 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Wed, 28 Jan 2015 10:45:35 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: > > >> 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 >> escreveu: >> >> >>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>> lucasmateus.oliveira at 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 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 >>>> 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 at gmail.com>: >>>>> >>>>>> >>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>> 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 at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Wed Jan 28 05:24:55 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 28 Jan 2015 11:24:55 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 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. [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 : > >>> 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 >>> escreveu: >>> >>> >>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>> lucasmateus.oliveira at 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 >>>>> 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 >>>>> 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 at gmail.com>: >>>>>> >>>>>>> >>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>> 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 at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbsnkjmr at gmail.com Wed Jan 28 10:34:30 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Wed, 28 Jan 2015 16:34:30 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 28 de janeiro de 2015 11:24, Renato Santos 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 : > > >>>> 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 >>>> escreveu: >>>> >>>> >>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>> lucasmateus.oliveira at 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 >>>>>> 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 >>>>>> 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 at gmail.com>: >>>>>>> >>>>>>>> >>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>> 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 at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Thu Jan 29 12:49:24 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Thu, 29 Jan 2015 18:49:24 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 escreveu: > Em 28 de janeiro de 2015 11:24, Renato Santos > 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 : >> >> >>>>> 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 >>>>> escreveu: >>>>> >>>>> >>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>> lucasmateus.oliveira at 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 >>>>>>> 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 >>>>>> > 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 at gmail.com>: >>>>>>>> >>>>>>>>> >>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>> 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 at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Thu Jan 29 15:45:32 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Thu, 29 Jan 2015 21:45:32 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 q Em 29 de janeiro de 2015 18:49, Leonardo Ruoso 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 escreveu: > > Em 28 de janeiro de 2015 11:24, Renato Santos >> 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 : >>> >>> >>>>>> 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 >>>>>> escreveu: >>>>>> >>>>>> >>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>> lucasmateus.oliveira at 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 >>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>> 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 at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbsnkjmr at gmail.com Thu Jan 29 15:54:54 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Thu, 29 Jan 2015 21:54:54 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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. > Em 29 de janeiro de 2015 18:49, Leonardo Ruoso > 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 escreveu: >> >> Em 28 de janeiro de 2015 11:24, Renato Santos >>> 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 : >>>> >>>> >>>>>>> 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 >>>>>>> escreveu: >>>>>>> >>>>>>> >>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>> lucasmateus.oliveira at 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 >>>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>> 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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shonorio at gmail.com Thu Jan 29 17:39:36 2015 From: shonorio at gmail.com (Solli Honorio) Date: Thu, 29 Jan 2015 23:39:36 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Estou realmente precisando tomar umas brejas contigo, afinal n?o estou conseguindo entender porque voc? est? supervalorizando uma tecnologia de implementa??o complicada e com um enorme overhead na apresenta??o dos dados, em rela??o a outra menos complicada. Talvez eu esteja muito desatualizado com as novidades da antiga SOAP, mas estamos falando de tecnologia dos anos 2000. O tempo que eu utilizei isto, era de uma complexidade infernal, e o WS Security ent?o era algo aparte de complexidade e infraestrutura. E mesmo assim, ao final do projeto, est?vamos utilizando a velha e ruim autentica??o baseado em usu?rio e senha para a aplica??o (e tudo mundo estava utilizando a mesma senha mesmo com uma tentativa de politica r?gida de seguran?a), e expondo de maneira medonha o kerberos da empresa na infeliz id?ia de ter um SSO (Single Sing-on). Sinceramente n?o sei qual ? a limita??o t?o impactante do REST em utilizar tecnologia de autentica??o baseado no oauth (like), secret token e session token. Com rela??o a ACL, vejo simplesmente como uma op??o de implementa??o no software, e cada um o faz da maneira que achar melhor. Veja o caso do sistema operacional, cada um tem a tua ACL, com as vantagens e desvantagens de cada uma. Em 29 de janeiro de 2015 18:49, Leonardo Ruoso 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 escreveu: > > Em 28 de janeiro de 2015 11:24, Renato Santos >> 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 : >>> >>> >>>>>> 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 >>>>>> escreveu: >>>>>> >>>>>> >>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>> lucasmateus.oliveira at 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 >>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>> 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 at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -- "o animal satisfeito dorme". - Guimar?es Rosa -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From shonorio at gmail.com Thu Jan 29 17:58:06 2015 From: shonorio at gmail.com (Solli Honorio) Date: Thu, 29 Jan 2015 23:58:06 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 29 de janeiro de 2015 21:54, Kojo 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 >> 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 escreveu: >>> >>> Em 28 de janeiro de 2015 11:24, Renato Santos >>>> 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 : >>>>> >>>>> >>>>>>>> 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 >>>>>>>> escreveu: >>>>>>>> >>>>>>>> >>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>>> lucasmateus.oliveira at 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 >>>>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>>> 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 at pm.org >>>>>>>>>>>> L >>>>>>>>>>>> =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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =end disclaimer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =begin disclaimer >>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- "o animal satisfeito dorme". - Guimar?es Rosa -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From blabos at gmail.com Thu Jan 29 19:16:32 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Fri, 30 Jan 2015 01:16:32 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 : > > > Em 29 de janeiro de 2015 21:54, Kojo 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 >>> 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 escreveu: >>>> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos >>>>> 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 : >>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> escreveu: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus >>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>>>> 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 at pm.org >>>>>>>>>>>>> L >>>>>>>>>>>>> =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 at pm.org >>>>>>>>>>>> L >>>>>>>>>>>> =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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =end disclaimer >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> =begin disclaimer >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =end disclaimer >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From hernanlopes at gmail.com Fri Jan 30 05:47:07 2015 From: hernanlopes at gmail.com (Hernan Lopes) Date: Fri, 30 Jan 2015 11:47:07 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 ? 2015-01-30 1:16 GMT-02:00 Blabos de Blebe : > 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 : > > > > > > Em 29 de janeiro de 2015 21:54, Kojo 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 > >>> 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 escreveu: > >>>> > >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos > > >>>>> 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 : > >>>>>> > >>>>>>>>> > >>>>>>>>> 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 at ruoso.com> > >>>>>>>>> escreveu: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus > >>>>>>>>>> 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 > >>>>>>>>>>> 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 > >>>>>>>>>>> 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 > >>>>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso < > leonardo at 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 at pm.org > >>>>>>>>>>>>> L > >>>>>>>>>>>>> =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 at pm.org > >>>>>>>>>>>> L > >>>>>>>>>>>> =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 at pm.org > >>>>>>>>>>> L > >>>>>>>>>>> =end disclaimer > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> =begin disclaimer > >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>>>>>> L > >>>>>>>>>>> =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 at pm.org > >>>>>>>>>> L > >>>>>>>>>> =end disclaimer > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> =begin disclaimer > >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>>>> L > >>>>>>>>> =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 at pm.org > >>>>>>>> L > >>>>>>>> =end disclaimer > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> =begin disclaimer > >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>> L > >>>>>>> =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 at pm.org > >>>>>> L > >>>>>> =end disclaimer > >>>>>> > >>>>> > >>>>> > >>>>> =begin disclaimer > >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>> L > >>>>> =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 at pm.org > >>>> L > >>>> =end disclaimer > >>>> > >>> > >> > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucasmateus.oliveira at gmail.com Fri Jan 30 05:48:54 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Fri, 30 Jan 2015 11:48:54 -0200 Subject: [SP-pm] =?iso-8859-1?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 30/01/2015, ?(s) 01:16, Blabos de Blebe escreveu: > No fim boa parte dessa conversa ? s? pra dizer se eu vou chamar o > treco de bolacha ou de biscoito Blabos++ -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From eduardo at web2solutions.com.br Fri Jan 30 05:55:36 2015 From: eduardo at web2solutions.com.br (Eduardo Almeida) Date: Fri, 30 Jan 2015 11:55:36 -0200 Subject: [SP-pm] =?windows-1252?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: <54CB8D58.4060901@web2solutions.com.br> On 1/30/15 11:48 AM, Lucas Mateus wrote: > > Em 30/01/2015, ?(s) 01:16, Blabos de Blebe > escreveu: > >> No fim boa parte dessa conversa ? s? pra dizer se eu vou chamar o >> treco de bolacha ou de biscoito > > Blabos++ Blabos++ > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer -- Eduardo Almeida - Software Engineer eduardo at web2solutions.com.br - 27 3261-0082 / 27 9839 3755 *WEB2 Solutions* - Inovando, sempre! -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: dhtmlx_certified.png Tipo: image/png Tamanho: 11630 bytes Descri??o: n?o dispon?vel URL: From eduardo at web2solutions.com.br Fri Jan 30 05:55:36 2015 From: eduardo at web2solutions.com.br (Eduardo Almeida) Date: Fri, 30 Jan 2015 11:55:36 -0200 Subject: [SP-pm] =?windows-1252?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: <54CB8D58.4060901@web2solutions.com.br> On 1/30/15 11:48 AM, Lucas Mateus wrote: > > Em 30/01/2015, ?(s) 01:16, Blabos de Blebe > escreveu: > >> No fim boa parte dessa conversa ? s? pra dizer se eu vou chamar o >> treco de bolacha ou de biscoito > > Blabos++ Blabos++ > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer -- Eduardo Almeida - Software Engineer eduardo at web2solutions.com.br - 27 3261-0082 / 27 9839 3755 *WEB2 Solutions* - Inovando, sempre! -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: -------------- Pr?xima Parte ---------- Um anexo n?o-texto foi limpo... Nome: dhtmlx_certified.png Tipo: image/png Tamanho: 11630 bytes Descri??o: n?o dispon?vel URL: From leonardo at ruoso.com Fri Jan 30 13:02:15 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Fri, 30 Jan 2015 19:02:15 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 29 de janeiro de 2015 23:39, Solli Honorio escreveu: > Estou realmente precisando tomar umas brejas contigo, > Mas claro. Essa ? a ideia. Provavelmente, n?o s? bregas, mas talvez podemos come?ar um livro sobre Restful e Perl... > afinal n?o estou conseguindo entender porque voc? est? supervalorizando > uma tecnologia de implementa??o complicada e com um enorme overhead na > apresenta??o dos dados, em rela??o a outra menos complicada. > Qual a tecnologia com implementa??o complicada e qual a menos complicada? Eu estou defendendo que Rest ? a maior sacada em Engenharia de Software desde o RDBMS, provavelmente. ? melhor que SOAP/WSDL pelo fato de que Rest ? melhor que RPC para a grande maioria das aplica??es, ao menos das aplica??es Enterprise ou P?blicas. > Talvez eu esteja muito desatualizado com as novidades da antiga SOAP, mas > estamos falando de tecnologia dos anos 2000. > Sim, estamos falando de tecnologia dos anos 2000, sempre, tanto SOAP quanto REST datam da virada do s?culo. > O tempo que eu utilizei isto, era de uma complexidade infernal, e o WS > Security ent?o era algo aparte de complexidade e infraestrutura. E mesmo > assim, ao final do projeto, est?vamos utilizando a velha e ruim > autentica??o baseado em usu?rio e senha para a aplica??o (e tudo mundo > estava utilizando a mesma senha mesmo com uma tentativa de politica r?gida > de seguran?a), e expondo de maneira medonha o kerberos da empresa na > infeliz id?ia de ter um SSO (Single Sing-on). > Voc? culpa o Otto e o Beau de Rochas quando um adolescente dirigindo embriagado assassina uma d?zia de pessoas que estavam aguardando o ?nibus numa parada? Se n?o, ent?o voc? entende que n?o deve atribuir as aberra??es implementadas por profissionais com treinamento insuficiente ? arquitetura que eles dizem estar adotando, correto? > Sinceramente n?o sei qual ? a limita??o t?o impactante do REST em utilizar > tecnologia de autentica??o baseado no oauth (like), secret token e session > token. Com rela??o a ACL, vejo simplesmente como uma op??o de implementa??o > no software, e cada um o faz da maneira que achar melhor. Veja o caso do > sistema operacional, cada um tem a tua ACL, com as vantagens e desvantagens > de cada uma. > Opa, mas eu nunca, jamais em toda vida disse que OAuth2 n?o seria um bom mecanismo de autentica??o, mas SSO e OAuth2 provavelmente s?o muito mais ortogonais como tecnologia que concorrentes. E quanto a cada um ter uma ACL diferente, bem, eu vejo uma tend?ncia imensa de converg?ncia, embora reconhe?a que seja um processo transgeracional, ainda assim, quanto mais heterog?neo o ambiente, mais especifica??o formal e mais abstra??o voc? precisa e n?o menos. > Em 29 de janeiro de 2015 18:49, Leonardo Ruoso > 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 escreveu: >> >> Em 28 de janeiro de 2015 11:24, Renato Santos >>> 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 : >>>> >>>> >>>>>>> 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 >>>>>>> escreveu: >>>>>>> >>>>>>> >>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>> lucasmateus.oliveira at 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 >>>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>> 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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =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 at pm.org > L > =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: From leonardo at ruoso.com Fri Jan 30 13:05:19 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Fri, 30 Jan 2015 19:05:19 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: 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 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 : > > > > > > Em 29 de janeiro de 2015 21:54, Kojo 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 > >>> 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 escreveu: > >>>> > >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos > > >>>>> 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 : > >>>>>> > >>>>>>>>> > >>>>>>>>> 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 at ruoso.com> > >>>>>>>>> escreveu: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus > >>>>>>>>>> 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 > >>>>>>>>>>> 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 > >>>>>>>>>>> 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 > >>>>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso < > leonardo at 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 at pm.org > >>>>>>>>>>>>> L > >>>>>>>>>>>>> =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 at pm.org > >>>>>>>>>>>> L > >>>>>>>>>>>> =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 at pm.org > >>>>>>>>>>> L > >>>>>>>>>>> =end disclaimer > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> =begin disclaimer > >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>>>>>> L > >>>>>>>>>>> =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 at pm.org > >>>>>>>>>> L > >>>>>>>>>> =end disclaimer > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> =begin disclaimer > >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>>>> L > >>>>>>>>> =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 at pm.org > >>>>>>>> L > >>>>>>>> =end disclaimer > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> =begin disclaimer > >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>>>> L > >>>>>>> =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 at pm.org > >>>>>> L > >>>>>> =end disclaimer > >>>>>> > >>>>> > >>>>> > >>>>> =begin disclaimer > >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>>>> L > >>>>> =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 at pm.org > >>>> L > >>>> =end disclaimer > >>>> > >>> > >> > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Fri Jan 30 13:07:52 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Fri, 30 Jan 2015 19:07:52 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 30 de janeiro de 2015 11:47, Hernan Lopes 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 : > > 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 : >> > >> > >> > Em 29 de janeiro de 2015 21:54, Kojo 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 >> >>> 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 escreveu: >> >>>> >> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos < >> renato.cron at 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 : >> >>>>>> >> >>>>>>>>> >> >>>>>>>>> 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 at ruoso.com> >> >>>>>>>>> escreveu: >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus >> >>>>>>>>>> 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 > > >> >>>>>>>>>>> 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 >> >>>>>>>>>>> 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 >> >>>>>>>>>>>> : >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso < >> leonardo at 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 at pm.org >> >>>>>>>>>>>>> L >> >>>>>>>>>>>>> =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 at pm.org >> >>>>>>>>>>>> L >> >>>>>>>>>>>> =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 at pm.org >> >>>>>>>>>>> L >> >>>>>>>>>>> =end disclaimer >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> =begin disclaimer >> >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>>>>>> L >> >>>>>>>>>>> =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 at pm.org >> >>>>>>>>>> L >> >>>>>>>>>> =end disclaimer >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> =begin disclaimer >> >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>>>> L >> >>>>>>>>> =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 at pm.org >> >>>>>>>> L >> >>>>>>>> =end disclaimer >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> =begin disclaimer >> >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>> L >> >>>>>>> =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 at pm.org >> >>>>>> L >> >>>>>> =end disclaimer >> >>>>>> >> >>>>> >> >>>>> >> >>>>> =begin disclaimer >> >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>> L >> >>>>> =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 at pm.org >> >>>> L >> >>>> =end disclaimer >> >>>> >> >>> >> >> >> >> >> >> =begin disclaimer >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> L >> >> =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 at pm.org >> > L >> > =end disclaimer >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Fri Jan 30 13:08:21 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Fri, 30 Jan 2015 19:08:21 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: JSON e XML s?o ortogonais a RPC e REST. Em 29 de janeiro de 2015 21:54, Kojo 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. > > > > > > >> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso >> 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 escreveu: >>> >>> Em 28 de janeiro de 2015 11:24, Renato Santos >>>> 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 : >>>>> >>>>> >>>>>>>> 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 >>>>>>>> escreveu: >>>>>>>> >>>>>>>> >>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>>> lucasmateus.oliveira at 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 >>>>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>>> 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 at pm.org >>>>>>>>>>>> L >>>>>>>>>>>> =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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =end disclaimer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =begin disclaimer >>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>> L >>>>>>>>>> =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 at pm.org >>>>>>>>> L >>>>>>>>> =end disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> =begin disclaimer >>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>> L >>>>>>>> =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 at pm.org >>>>>>> L >>>>>>> =end disclaimer >>>>>>> >>>>>>> >>>>>> >>>>>> =begin disclaimer >>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>> L >>>>>> =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 at pm.org >>>>> L >>>>> =end disclaimer >>>>> >>>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >>> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From ricardostock at bol.com.br Fri Jan 30 15:45:26 2015 From: ricardostock at bol.com.br (Ricardo Stock) Date: Fri, 30 Jan 2015 21:45:26 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: ["B736BDF8-C7E6-4EEB-B8DA-F3763E794006@gmail.com"] References: ["CAAetMDFk4tqxj9FPHtjqveVPfCsBVoVbnAw0iMgm55EucMDOCw@mail.gmail.com", "CALRTdbHy6t72UkzG0ZvzJB_c+qEsV+nZE2O-b3x1HN+iDouy4g@mail.gmail.com", "411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com", "CABmdQ_TmrG8w1peL9KvfofRAx=uQON2c+V9M-BLzfMAvQ_-jMg@mail.gmail.com", "CALRTdbEvtoXC62SvUn20ebc=vnG=XhwN4vYZOekGRz=UZ5YR0Q@mail.gmail.com", "0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com", "CALRTdbH0-32-TBN_LW0VP4sQhbEOGPbhdMRwFAM+xWfzE8tU2Q@mail.gmail.com", "CANzuQZR3WfP9SxmvoBh6S6NOXxrcNCENzraOFpkm9jcnVduVkw@mail.gmail.com", "CALRTdbF+7aBzG6PyCm9yUoG_YyKaVET9G=81hnB0++wRX31NHw@mail.gmail.com", "CANzuQZSyFubCeWNKdLOvC9UJM0UetM7pzvmYyMK1G1tTS9sq0w@mail.gmail.com", "CABmdQ_SmbSJaGxMedB=WBBgwcYJPbdq0jn=ZQ=N-MhTSA1f4zg@mail.gmail.com", "CANzuQZSF2jdR5Jommns2NZvLJe5Uj7SYrCXASirNc1F6qSQ2gQ@mail.gmail.com", "CALRTdbE3hVhJ_MJ0OaVpyVAMLXeMFo=MSQs2GvW3oYJSv4uA3g@mail.gmail.com", "CANzuQZRN18F+zcFoOFWRQ1G=Mx26YSz+EhhbTbiez8fW0DoCDQ@mail.gmail.com", "CANzuQZQ61n_KP72C8Vkhkq4bcUFJq0C5ffP9zHQwS2qdSKw=Rw@mail.gmail.com", "CAAetMDFfP1O9KsnZanT387sRZCpewNgSgdZ0C3petocPoT8MWg@mail.gmail.com", "CAAxpsiYv2z-AY-TkF-q5Uqc21UGJRn-FThNq-NnLPNi6uZnFiA@mail.gmail.com", "B736BDF8-C7E6-4EEB-B8DA-F3763E794006@gmail.com"] Message-ID: <54cc1796671ee_342115d14f6533cc70370@a4-winter26.mail> eu to acompanho e acho que vou chamar de cookie. Brincadeiras a parte, essa foi a melhor bablos :-) Bem explicado Ricado Stock ricardostock at bol.com.br Um bom programador tem um desafio Um programador mediano, tem um problema. De: lucasmateus.oliveira at gmail.com Enviada: Sexta-feira, 30 de Janeiro de 2015 11:48 Para: saopaulo-pm at mail.pm.org Assunto: [SP-pm] Resumo do Evento T?cnico Em 30/01/2015, ?(s) 01:16, Blabos de Blebe escreveu: No fim boa parte dessa conversa ? s? pra dizer se eu vou chamar o treco de bolacha ou de biscoito Blabos++=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org L =end disclaimer From blabos at gmail.com Fri Jan 30 16:21:21 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Fri, 30 Jan 2015 22:21:21 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Pera. N?o entendi. Voc? discorda quando eu concordo com vc? []'s 2015-01-30 19:05 GMT-02:00 Leonardo Ruoso : > 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 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 : >> > >> > >> > Em 29 de janeiro de 2015 21:54, Kojo 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 >> >>> 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 escreveu: >> >>>> >> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos >> >>>>> >> >>>>> 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 : >> >>>>>> >> >>>>>>>>> >> >>>>>>>>> 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 >> >>>>>>>>> >> >>>>>>>>> escreveu: >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus >> >>>>>>>>>> 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 >> >>>>>>>>>>> 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 >> >>>>>>>>>>> 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 >> >>>>>>>>>>>> : >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> 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 at pm.org >> >>>>>>>>>>>>> L >> >>>>>>>>>>>>> =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 at pm.org >> >>>>>>>>>>>> L >> >>>>>>>>>>>> =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 at pm.org >> >>>>>>>>>>> L >> >>>>>>>>>>> =end disclaimer >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> =begin disclaimer >> >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>>>>>> L >> >>>>>>>>>>> =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 at pm.org >> >>>>>>>>>> L >> >>>>>>>>>> =end disclaimer >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> =begin disclaimer >> >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>>>> L >> >>>>>>>>> =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 at pm.org >> >>>>>>>> L >> >>>>>>>> =end disclaimer >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> =begin disclaimer >> >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>>>> L >> >>>>>>> =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 at pm.org >> >>>>>> L >> >>>>>> =end disclaimer >> >>>>>> >> >>>>> >> >>>>> >> >>>>> =begin disclaimer >> >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>>>> L >> >>>>> =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 at pm.org >> >>>> L >> >>>> =end disclaimer >> >>>> >> >>> >> >> >> >> >> >> =begin disclaimer >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> L >> >> =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 at pm.org >> > L >> > =end disclaimer >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From rbsnkjmr at gmail.com Fri Jan 30 18:55:03 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Sat, 31 Jan 2015 02:55:03 +0000 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 30 de janeiro de 2015 01:58, Solli Honorio escreveu: > > 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. > 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) 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. 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. > Em 29 de janeiro de 2015 18:49, Leonardo Ruoso >>> 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 escreveu: >>>> >>>> Em 28 de janeiro de 2015 11:24, Renato Santos >>>>> 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 : >>>>>> >>>>>> >>>>>>>>> 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 >>>>>>>> > escreveu: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>>>> lucasmateus.oliveira at 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 >>>>>>>>>>> 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 at 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 at gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso >>>>>>>>>>>>> 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 at pm.org >>>>>>>>>>>>> L >>>>>>>>>>>>> =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 at pm.org >>>>>>>>>>>> L >>>>>>>>>>>> =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 at pm.org >>>>>>>>>>> L >>>>>>>>>>> =end disclaimer >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> =begin disclaimer >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>>>> L >>>>>>>>>>> =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 at pm.org >>>>>>>>>> L >>>>>>>>>> =end disclaimer >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> =begin disclaimer >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>>>> L >>>>>>>>> =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 at pm.org >>>>>>>> L >>>>>>>> =end disclaimer >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> =begin disclaimer >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>>>> L >>>>>>> =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 at pm.org >>>>>> L >>>>>> =end disclaimer >>>>>> >>>>>> >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>>> L >>>>> =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 at pm.org >>>> L >>>> =end disclaimer >>>> >>>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sat Jan 31 03:56:06 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 09:56:06 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 30 de janeiro de 2015 22:21, Blabos de Blebe 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 : > > 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 > 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 : > >> > > >> > > >> > Em 29 de janeiro de 2015 21:54, Kojo 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 > >> >>> 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 > escreveu: > >> >>>> > >> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos > >> >>>>> > >> >>>>> 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 : > >> >>>>>> > >> >>>>>>>>> > >> >>>>>>>>> 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 > >> >>>>>>>>> > >> >>>>>>>>> escreveu: > >> >>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus > >> >>>>>>>>>> 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 at 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 > >> >>>>>>>>>>> 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 > >> >>>>>>>>>>>> : > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Em 25/01/2015, ?(s) 18:45, Leonardo Ruoso > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> 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 at pm.org > >> >>>>>>>>>>>>> L > >> >>>>>>>>>>>>> =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 at pm.org > >> >>>>>>>>>>>> L > >> >>>>>>>>>>>> =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 at pm.org > >> >>>>>>>>>>> L > >> >>>>>>>>>>> =end disclaimer > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>> =begin disclaimer > >> >>>>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >>>>>>>>>>> L > >> >>>>>>>>>>> =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 at pm.org > >> >>>>>>>>>> L > >> >>>>>>>>>> =end disclaimer > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> =begin disclaimer > >> >>>>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >>>>>>>>> L > >> >>>>>>>>> =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 at pm.org > >> >>>>>>>> L > >> >>>>>>>> =end disclaimer > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> =begin disclaimer > >> >>>>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >>>>>>> L > >> >>>>>>> =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 at pm.org > >> >>>>>> L > >> >>>>>> =end disclaimer > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> =begin disclaimer > >> >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >>>>> L > >> >>>>> =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 at pm.org > >> >>>> L > >> >>>> =end disclaimer > >> >>>> > >> >>> > >> >> > >> >> > >> >> =begin disclaimer > >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >> L > >> >> =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 at pm.org > >> > L > >> > =end disclaimer > >> > > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Sat Jan 31 04:05:53 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 10:05:53 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 31 de janeiro de 2015 00:55, Kojo escreveu: > Em 30 de janeiro de 2015 01:58, Solli Honorio > escreveu: > >> >> [ ... ] > 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. > Permita-me corrigir uma coisa em minha coloca??o inicial... Minha proposta foi de que poder?amos formar um grupo para estudar e produzir algum material relevante sobre Rest e Perl, com a premissa de que as pessoas que participariam entendem Rest n?o apenas como uma proposta para o desenvolvimento de software relevante, mas que talvez seja a melhor arquitetura dispon?vel na atualidade, e que a import?ncia de implementa??o de servi?os Rest cresce exponencialmente com a demanda por clientes n?o-PC e, mesmo no PC, cresce com a ado??o de aplica??es ricas, onde o principal player ? o AngularJS, explicando melhor: Internet das Coisas, Mobile e SPA dependem de bons designers para seu sucesso e esses bons designers, em se tratando de Rest, ainda s?o raros na maioria das empresas. [ ... ] -- Leonardo Ruoso Journalist, Perl developer and business consultant Media, UFC/2006; Telecom, IFCE/1998 -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From blabos at gmail.com Sat Jan 31 05:38:48 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sat, 31 Jan 2015 11:38:48 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Eu concordo 2015-01-31 10:05 GMT-02:00 Leonardo Ruoso : > Em 31 de janeiro de 2015 00:55, Kojo escreveu: >> >> Em 30 de janeiro de 2015 01:58, Solli Honorio >> escreveu: >>> >>> > > [ ... ] > >> >> 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. > > > Permita-me corrigir uma coisa em minha coloca??o inicial... > > Minha proposta foi de que poder?amos formar um grupo para estudar e produzir > algum material relevante sobre Rest e Perl, com a premissa de que as pessoas > que participariam entendem Rest n?o apenas como uma proposta para o > desenvolvimento de software relevante, mas que talvez seja a melhor > arquitetura dispon?vel na atualidade, e que a import?ncia de implementa??o > de servi?os Rest cresce exponencialmente com a demanda por clientes n?o-PC > e, mesmo no PC, cresce com a ado??o de aplica??es ricas, onde o principal > player ? o AngularJS, explicando melhor: Internet das Coisas, Mobile e SPA > dependem de bons designers para seu sucesso e esses bons designers, em se > tratando de Rest, ainda s?o raros na maioria das empresas. > > [ ... ] > > -- > 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 at pm.org > L > =end disclaimer > From leonardo at ruoso.com Sat Jan 31 07:36:52 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 13:36:52 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 31 de janeiro de 2015 11:38, Blabos de Blebe escreveu: > Eu concordo > Eu concordo que voc? concorda :p > > 2015-01-31 10:05 GMT-02:00 Leonardo Ruoso : > > Em 31 de janeiro de 2015 00:55, Kojo escreveu: > >> > >> Em 30 de janeiro de 2015 01:58, Solli Honorio > >> escreveu: > >>> > >>> > > > > [ ... ] > > > >> > >> 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. > > > > > > Permita-me corrigir uma coisa em minha coloca??o inicial... > > > > Minha proposta foi de que poder?amos formar um grupo para estudar e > produzir > > algum material relevante sobre Rest e Perl, com a premissa de que as > pessoas > > que participariam entendem Rest n?o apenas como uma proposta para o > > desenvolvimento de software relevante, mas que talvez seja a melhor > > arquitetura dispon?vel na atualidade, e que a import?ncia de > implementa??o > > de servi?os Rest cresce exponencialmente com a demanda por clientes > n?o-PC > > e, mesmo no PC, cresce com a ado??o de aplica??es ricas, onde o principal > > player ? o AngularJS, explicando melhor: Internet das Coisas, Mobile e > SPA > > dependem de bons designers para seu sucesso e esses bons designers, em se > > tratando de Rest, ainda s?o raros na maioria das empresas. > > > > [ ... ] > > > > -- > > 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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From renato.cron at gmail.com Sat Jan 31 11:24:06 2015 From: renato.cron at gmail.com (Renato Santos) Date: Sat, 31 Jan 2015 17:24:06 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Fui procurar por "True REST APPLICATION" e ... Everyone says they have a REST (or RESTful or REST-like) API. Twitter does, Facebook does, as does Twilio and Gowalla and even Google. However, by the actual, original definition, none of them are truly RESTful. But that?s OK, because your API shouldn?t be either. http://www.intridea.com/blog/2010/4/29/rest-isnt-what-you-think-it-is 2015-01-31 13:36 GMT-02:00 Leonardo Ruoso : > Em 31 de janeiro de 2015 11:38, Blabos de Blebe > escreveu: > >> Eu concordo >> > > Eu concordo que voc? concorda :p > > >> >> 2015-01-31 10:05 GMT-02:00 Leonardo Ruoso : >> > Em 31 de janeiro de 2015 00:55, Kojo escreveu: >> >> >> >> Em 30 de janeiro de 2015 01:58, Solli Honorio >> >> escreveu: >> >>> >> >>> >> > >> > [ ... ] >> > >> >> >> >> 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. >> > >> > >> > Permita-me corrigir uma coisa em minha coloca??o inicial... >> > >> > Minha proposta foi de que poder?amos formar um grupo para estudar e >> produzir >> > algum material relevante sobre Rest e Perl, com a premissa de que as >> pessoas >> > que participariam entendem Rest n?o apenas como uma proposta para o >> > desenvolvimento de software relevante, mas que talvez seja a melhor >> > arquitetura dispon?vel na atualidade, e que a import?ncia de >> implementa??o >> > de servi?os Rest cresce exponencialmente com a demanda por clientes >> n?o-PC >> > e, mesmo no PC, cresce com a ado??o de aplica??es ricas, onde o >> principal >> > player ? o AngularJS, explicando melhor: Internet das Coisas, Mobile e >> SPA >> > dependem de bons designers para seu sucesso e esses bons designers, em >> se >> > tratando de Rest, ainda s?o raros na maioria das empresas. >> > >> > [ ... ] >> > >> > -- >> > 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 at pm.org >> > L >> > =end disclaimer >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Sat Jan 31 11:48:35 2015 From: renato.cron at gmail.com (Renato Santos) Date: Sat, 31 Jan 2015 17:48:35 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Mais links para ler: REST APIs must be hypertext-driven - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven (too strict) Creating an efficient REST API with HTTP - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) No come?o desta thread eu n?o conhecia esse tal REST do Dr Fielding. Foi legal conhecer, mas ainda n?o entendo porque o Leonardo diz que os REST-likes n?o ajudam sistemas mobiles/SPA. Nem todo mundo que conhe?o gostam de AngularJS, algumas, inclusive, tem um forte ?dio (quase como o Eden vs Mojolicious). ? claro que uma SPA ficaria mais f?cil de dar manuten??o se as respostas ? recursos da API contenham as URI's para os pr?ximos recursos, mas n?o impossibilita a SPA de existir de uma forma regular. A unica parte que n?o entendi at? agora foi essa: - A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. *[Failure here implies that identification is not separated from interaction.]* Como fazer uma API comunic?vel por diversos protocolos? HTTP e HTTPS n?o bastam? Os outros protocolos n?o podem ser "tunelados" por HTTP? -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sat Jan 31 11:50:07 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 17:50:07 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Opa, Em 31 de janeiro de 2015 17:24, Renato Santos escreveu: > Fui procurar por "True REST APPLICATION" e ... > Everyone says they have a REST (or RESTful or REST-like) API. Twitter > does, Facebook does, as does Twilio and Gowalla and even Google. However, > by the actual, original definition, none of them are truly RESTful. But > that?s OK, because your API shouldn?t be either. > > http://www.intridea.com/blog/2010/4/29/rest-isnt-what-you-think-it-is > > Eu conhe?o demais esse rant a? :p O texto contempla alguns equ?vocos e alguns aspectos efetivos. 1) Pode ser que fazer XML-RPC ou JSON-RPC seja exatamente o que o autor de um software deseja. Quem mesmo disse que o RPC est? ou deveria ser morto? O engra?ado ? que s?o as mesmas pessoas que querem adotar as tecnologias mais quentes dispon?veis as primeiras a se esquivar de qualquer responsabilidade em implementar essas tecnologias em seus aspectos que justamente as tornam quentes. 2) Mesmo que voc? decida n?o implementar Rest, ou implementar um subset de Rest, parece-me bem melhor como profissional saber o que se est? a fazer e n?o bancar o tolo por a?, escrevendo, falando e ensinando as pessoas a fazer coisas erradas. Quer dizer, se voc? quer fazer Rest, ent?o faz Rest. Quer fazer JSON-RPC schemaless, ent?o faz? 3) Muita gente pensou menos, de verdade, que Rest era uma alternativa leve ao Soap. Quando a grande diferen?a ? que o Rest trabalha com Dados e o Soap trabalha com m?todos e que os dados no Rest possuem uma identifica??o universal, um UUID em forma de URL. > > > 2015-01-31 13:36 GMT-02:00 Leonardo Ruoso : > > Em 31 de janeiro de 2015 11:38, Blabos de Blebe >> escreveu: >> >>> Eu concordo >>> >> >> Eu concordo que voc? concorda :p >> >> >>> >>> 2015-01-31 10:05 GMT-02:00 Leonardo Ruoso : >>> > Em 31 de janeiro de 2015 00:55, Kojo escreveu: >>> >> >>> >> Em 30 de janeiro de 2015 01:58, Solli Honorio >>> >> escreveu: >>> >>> >>> >>> >>> > >>> > [ ... ] >>> > >>> >> >>> >> 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. >>> > >>> > >>> > Permita-me corrigir uma coisa em minha coloca??o inicial... >>> > >>> > Minha proposta foi de que poder?amos formar um grupo para estudar e >>> produzir >>> > algum material relevante sobre Rest e Perl, com a premissa de que as >>> pessoas >>> > que participariam entendem Rest n?o apenas como uma proposta para o >>> > desenvolvimento de software relevante, mas que talvez seja a melhor >>> > arquitetura dispon?vel na atualidade, e que a import?ncia de >>> implementa??o >>> > de servi?os Rest cresce exponencialmente com a demanda por clientes >>> n?o-PC >>> > e, mesmo no PC, cresce com a ado??o de aplica??es ricas, onde o >>> principal >>> > player ? o AngularJS, explicando melhor: Internet das Coisas, Mobile e >>> SPA >>> > dependem de bons designers para seu sucesso e esses bons designers, em >>> se >>> > tratando de Rest, ainda s?o raros na maioria das empresas. >>> > >>> > [ ... ] >>> > >>> > -- >>> > 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 at pm.org >>> > L >>> > =end disclaimer >>> > >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =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 at pm.org > L > =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: From leonardo at ruoso.com Sat Jan 31 12:09:16 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 18:09:16 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 31 de janeiro de 2015 17:48, Renato Santos escreveu: > Mais links para ler: > > REST APIs must be hypertext-driven > - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven > (too strict) > > Creating an efficient REST API with HTTP > - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) > > > No come?o desta thread eu n?o conhecia esse tal REST do Dr Fielding. > E tem outro? Quer dizer, o tal Fielding ? uma das principais referencias n?o apenas em Rest, mas tamb?m em HTTP. > Foi legal conhecer, mas ainda n?o entendo porque o Leonardo diz que os > REST-likes n?o ajudam sistemas mobiles/SPA. > Esse ? um ponto que merece elabora??o, mas o primeiro ponto seria a longevidade dos clientes, algo que ? muito importante para IoT, Mobile e SPA. O problema est? em dizer que qualquer coisa que usa JSON/XML ? Rest ou Rest-Like. Tudo que for Rest-Like ajuda em alguma propor??o, mas desenvolvimento de aplica??es com forte acoplamento entre Interface e API ? tudo menos Rest-LIke e ? a? que o caldo entorna. Nem todo mundo que conhe?o gostam de AngularJS, algumas, inclusive, tem um > forte ?dio (quase como o Eden vs Mojolicious). > H? algumas alternativas ao AngularJS. Pessoalmente eu conhe?o o AngularJS. Agora, AngularJS est? muito mais para Catalyst que para Mojolicious. A tend?ncia seria de que o Eden gostasse do AngularJS. De fato, n?o conheci ningu?m que eu respeite como designer de software que n?o respeite consider?vel o AngularJS. ? claro que uma SPA ficaria mais f?cil de dar manuten??o se as respostas ? > recursos da API contenham as URI's para os pr?ximos recursos, mas n?o > impossibilita a SPA de existir de uma forma regular. > Um ponto que cabe entender para a discuss?o: Voc? entende o motivo de fraco acoplamento entre componentes de software, em especial componentes de rede, ser um aspecto importante para o desenvolvimento de boas API? Do contr?rio n?o vai adiantar eu dizer que o conceito de n?o haver informa??o espec?fica da aplica??o disponibilizada out-of-band ? FUNDAMENTAL pelo fato de que esse princ?pio GARANTE o fraco acoplamento entre cliente e servidor. Correto? > > A unica parte que n?o entendi at? agora foi essa: > > - A REST API should not be dependent on any single communication > protocol, though its successful mapping to a given protocol may be > dependent on the availability of metadata, choice of methods, etc. In > general, any protocol element that uses a URI for identification must allow > any URI scheme to be used for the sake of that identification. *[Failure > here implies that identification is not separated from interaction.]* > > Como fazer uma API comunic?vel por diversos protocolos? HTTP e HTTPS n?o > bastam? Os outros protocolos n?o podem ser "tunelados" por HTTP? > N?o, decididamente HTTP sobre SSL ou n?o s?o menos que bastante para todos os cen?rios. Eu diria que a exist?ncia de v?rios outros mecanismos de transporte como XMPP, AMQP, RMI, SMTP e outros usados para comunica??o entre componentes de software j? demonstra emp?ricamente essa necessidade, mesmo sem entrarmos nas especificidades do HTTP. Mas, enfim, se sairmos com um entendimento melhor do que ? Rest j? lucramos com a conversa? Penso eu. Se tr?s pessoas da lista se derem ao trabalho ao menos de ler a disserta??o que conceitua o Rest e ? d?zia de artigos, j? ter?amos realizado um grande avan?o como comunidade e reduzido a quantidade de besteiras que falamos por a? :p Por outro lado, o que eu tenho experimentado com o fracasso dos projetos em implementar Rest, mesmo quando Rest ? formalmente requisitado pelo contratante, tem ao menos uma grande consequ?ncia negativa, derivada diretamente do forte acoplamento entre interface (SPA, Mobile e IoT) e API: custo de manuten??o elevada. Isso sem mencionar maior custo de atualiza??o, menor escalabilidade e v?rias outras consequ?ncias bem conhecidas dos modelos de RPC amplamente adotados. Precisamos, como desenvolvedores, entender o motivo pelo qual os GURUS da engenharia de software reconheceram no Rest o grande parad?gma para resolver problemas bastante conhecidos dos desenvolvedores e esses problemas est?o em grande parte associados justamente a sistemas que dependem de chamadas RPC para funcionar. Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de chegar num ponte de termos ao menos um software com uma API de refer?ncia funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma aplica??o bem simples como uma nova vers?o do ACT. -- 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 at pm.org > L > =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: From leonardo at ruoso.com Sat Jan 31 12:38:03 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 18:38:03 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 31 de janeiro de 2015 18:09, Leonardo Ruoso escreveu: > Em 31 de janeiro de 2015 17:48, Renato Santos > escreveu: > >> Mais links para ler: >> >> REST APIs must be hypertext-driven >> - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven >> (too strict) >> > De fato, ? o mais strictu senso que voc? vai encontrar sobre Rest: um texto do Roy Fielding :p Creating an efficient REST API with HTTP >> - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) >> > O cara vai bem at?: Version your API, and never change released features Depois desse ponto o texto desanda em incorre??es e s? mostra como as pesoas tem uma pregui?a violenta de estudar. Versionar uma API (j? ? complicado falar em API quando se est? falando em Rest) ? bom, mas, n?o, por favor, n?o coloque a vers?o da API na URI do recurso, a vers?o da API ? parte da negocia??o de m?dia, deve ser feita da mesma forma que se negocia locale, por exemplo, ou formato de documento (HTML, XML, JSON). Na sequencia, falando de Hateoas, o cara confirma, mais uma vez, a dificuldade que o cidad?o comum tem em separar o exemplo do conceito, o concreto do abstrato. Nada impede voc? de implementar seu Rest em XML, JSON, YAML ou at? mesmo usando outros formatos conhecidos. O tipo de documento ? ortogonal ? especifica??o do recurso. De fato esse levantamento demonstra a necessidade de documenta??o mais acess?vel sobre Rest. Ent?o isso mostraria a relev?ncia de fazermos um Equin?cio sobre Rest? -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From rbsnkjmr at gmail.com Sat Jan 31 13:43:57 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Sat, 31 Jan 2015 19:43:57 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Em 31 de janeiro de 2015 18:09, Leonardo Ruoso escreveu: > Em 31 de janeiro de 2015 17:48, Renato Santos > escreveu: > > Nem todo mundo que conhe?o gostam de AngularJS, algumas, inclusive, tem um >> forte ?dio (quase como o Eden vs Mojolicious). >> > > H? algumas alternativas ao AngularJS. Pessoalmente eu conhe?o o AngularJS. > Agora, AngularJS est? muito mais para Catalyst que para Mojolicious. A > tend?ncia seria de que o Eden gostasse do AngularJS. De fato, n?o conheci > ningu?m que eu respeite como designer de software que n?o respeite > consider?vel o AngularJS. > O AngularJS est? para o Catalyst pq s?o dois MVCs, um trabalha no back e um no front. O Mojo pelo pouco que eu sei ? um framework, http/websocket server ass?ncrono. Ent?o acho que AngularJS e o Mojo trabalhariam bem juntos. Eu fiz uma implementa??o de AngularJS com Websocket, n?o usei Mojo pq o back n?o era Perl, mas o AngularJS tem uma biblioteca para trabalhar com o protocolo Websocket que vai tranquilo. > > >> A unica parte que n?o entendi at? agora foi essa: >> >> - A REST API should not be dependent on any single communication >> protocol, though its successful mapping to a given protocol may be >> dependent on the availability of metadata, choice of methods, etc. In >> general, any protocol element that uses a URI for identification must allow >> any URI scheme to be used for the sake of that identification. *[Failure >> here implies that identification is not separated from interaction.]* >> >> Como fazer uma API comunic?vel por diversos protocolos? HTTP e HTTPS n?o >> bastam? Os outros protocolos n?o podem ser "tunelados" por HTTP? >> > > Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de > chegar num ponte de termos ao menos um software com uma API de refer?ncia > funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP > tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma > aplica??o bem simples como uma nova vers?o do ACT. > J? que vc considera a possibilidade de implementar algo REST-like em Websocket, segue abaixo umaa pequena tabela que mapeia diferentes caracter?sticas de cada protocolo. O zero ? qdo n?o tem a caracter?stica e o um ? qdo tem a caracter?stica. HTTP Websocket Stateless (S? o Client mant?m estado) 1 0 Stateful (Client e Server mant?m estado) 0 1 Synchronous (Blocante) 1 0 Assynchronous (N?o Blocante) 0 1 HalfDuplex 1 0 FullDuplex (Real Time) 0 1 Algumas observa??es. 1. O Websocket ? n?o blocante, n?o d? para quer?-lo sincronizado. O cliente precisa trabalhar com callback, promisses, etc. 2. Para o Websocket ser ass?ncrono ele precisa ser stateful. 3. Para o Websocket ser RealTime, ele precisa ser stateful. Me arrisco dizer que seria complicado implementar uma API ?nica para os dois. > > > -- > 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 at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucasmateus.oliveira at gmail.com Sat Jan 31 13:45:20 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Sat, 31 Jan 2015 19:45:20 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" em v?rios casos AngularJS ? uma Porcaria principalmente para desktop, mais especificamente para motores de busca. Se voc? quer vender tem que aparecer no Google, se usar AngularJS esquece motores de busca. Enviado pelo meu Windows Phone -----Mensagem Original----- De: "Leonardo Ruoso" Enviada em: ?31/?01/?2015 18:38 Para: "saopaulo-pm at mail.pm.org" Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 18:09, Leonardo Ruoso escreveu: Em 31 de janeiro de 2015 17:48, Renato Santos escreveu: Mais links para ler: REST APIs must be hypertext-driven - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven (too strict) De fato, ? o mais strictu senso que voc? vai encontrar sobre Rest: um texto do Roy Fielding :p Creating an efficient REST API with HTTP - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) O cara vai bem at?: Version your API, and never change released features Depois desse ponto o texto desanda em incorre??es e s? mostra como as pesoas tem uma pregui?a violenta de estudar. Versionar uma API (j? ? complicado falar em API quando se est? falando em Rest) ? bom, mas, n?o, por favor, n?o coloque a vers?o da API na URI do recurso, a vers?o da API ? parte da negocia??o de m?dia, deve ser feita da mesma forma que se negocia locale, por exemplo, ou formato de documento (HTML, XML, JSON). Na sequencia, falando de Hateoas, o cara confirma, mais uma vez, a dificuldade que o cidad?o comum tem em separar o exemplo do conceito, o concreto do abstrato. Nada impede voc? de implementar seu Rest em XML, JSON, YAML ou at? mesmo usando outros formatos conhecidos. O tipo de documento ? ortogonal ? especifica??o do recurso. De fato esse levantamento demonstra a necessidade de documenta??o mais acess?vel sobre Rest. Ent?o isso mostraria a relev?ncia de fazermos um Equin?cio sobre Rest? -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From renato.cron at gmail.com Sat Jan 31 13:47:34 2015 From: renato.cron at gmail.com (Renato Santos) Date: Sat, 31 Jan 2015 19:47:34 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> Message-ID: Tendo um backend esperto da sim para ter um backend s?, por exemplo, um sistema async e ter na frente uma op??o de http que conversa com esse sistema async. On Jan 31, 2015 7:44 PM, "Kojo" wrote: > > Em 31 de janeiro de 2015 18:09, Leonardo Ruoso > escreveu: > >> Em 31 de janeiro de 2015 17:48, Renato Santos >> escreveu: >> >> Nem todo mundo que conhe?o gostam de AngularJS, algumas, inclusive, tem >>> um forte ?dio (quase como o Eden vs Mojolicious). >>> >> >> H? algumas alternativas ao AngularJS. Pessoalmente eu conhe?o o >> AngularJS. Agora, AngularJS est? muito mais para Catalyst que para >> Mojolicious. A tend?ncia seria de que o Eden gostasse do AngularJS. De >> fato, n?o conheci ningu?m que eu respeite como designer de software que n?o >> respeite consider?vel o AngularJS. >> > > O AngularJS est? para o Catalyst pq s?o dois MVCs, um trabalha no back e > um no front. O Mojo pelo pouco que eu sei ? um framework, http/websocket > server ass?ncrono. Ent?o acho que AngularJS e o Mojo trabalhariam bem > juntos. > Eu fiz uma implementa??o de AngularJS com Websocket, n?o usei Mojo pq o > back n?o era Perl, mas o AngularJS tem uma biblioteca para trabalhar com o > protocolo Websocket que vai tranquilo. > > > >> >> >>> A unica parte que n?o entendi at? agora foi essa: >>> >>> - A REST API should not be dependent on any single communication >>> protocol, though its successful mapping to a given protocol may be >>> dependent on the availability of metadata, choice of methods, etc. In >>> general, any protocol element that uses a URI for identification must allow >>> any URI scheme to be used for the sake of that identification. *[Failure >>> here implies that identification is not separated from interaction.]* >>> >>> Como fazer uma API comunic?vel por diversos protocolos? HTTP e HTTPS n?o >>> bastam? Os outros protocolos n?o podem ser "tunelados" por HTTP? >>> >> >> Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de >> chegar num ponte de termos ao menos um software com uma API de refer?ncia >> funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP >> tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma >> aplica??o bem simples como uma nova vers?o do ACT. >> > > > J? que vc considera a possibilidade de implementar algo REST-like em > Websocket, segue abaixo umaa pequena tabela que mapeia diferentes > caracter?sticas de cada protocolo. > O zero ? qdo n?o tem a caracter?stica e o um ? qdo tem a caracter?stica. > > > HTTP Websocket > Stateless (S? o Client mant?m estado) 1 0 > Stateful (Client e Server mant?m estado) 0 1 > Synchronous (Blocante) 1 0 > Assynchronous (N?o Blocante) 0 1 > HalfDuplex > 1 0 > FullDuplex (Real Time) 0 1 > > Algumas observa??es. > 1. O Websocket ? n?o blocante, n?o d? para quer?-lo sincronizado. O > cliente precisa trabalhar com callback, promisses, etc. > 2. Para o Websocket ser ass?ncrono ele precisa ser stateful. > 3. Para o Websocket ser RealTime, ele precisa ser stateful. > > Me arrisco dizer que seria complicado implementar uma API ?nica para os > dois. > > > > > > > > >> >> >> -- >> 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 at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Sat Jan 31 13:56:01 2015 From: renato.cron at gmail.com (Renato Santos) Date: Sat, 31 Jan 2015 19:56:01 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Message-ID: Verdade, Aplica??es otimizadas para SEO s?o complicadas com o AngularJS ou qualquer outro framework que trabalha no client side. Existem, IMHO, gambiarras, tipo botar um selenium entre o nginx. (http-server) -> detecta o user-agent, se for browser, compila uma vers?o do html com selenium e ai cospe uma pagina inteira. O Meteor est? ai pra provar que ? complicado ter uma aplica??o com Reactivity. Eu, pessoalmente, acho que este tipo de aplica??es ? para apenas alguns sistemas, pelo menos do jeito que eles implementaram, usando o mongodb para manter os clientes atualizados e enviar atualizacoes para o server. 2015-01-31 19:45 GMT-02:00 Lucas Mateus : > Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" em > v?rios casos AngularJS ? uma Porcaria principalmente para desktop, mais > especificamente para motores de busca. Se voc? quer vender tem que aparecer > no Google, se usar AngularJS esquece motores de busca. > > Enviado pelo meu Windows Phone > ------------------------------ > De: Leonardo Ruoso > Enviada em: ?31/?01/?2015 18:38 > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > > > Em 31 de janeiro de 2015 18:09, Leonardo Ruoso > escreveu: > >> Em 31 de janeiro de 2015 17:48, Renato Santos >> escreveu: >> >>> Mais links para ler: >>> >>> REST APIs must be hypertext-driven >>> - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven >>> (too strict) >>> >> > De fato, ? o mais strictu senso que voc? vai encontrar sobre Rest: um > texto do Roy Fielding :p > > Creating an efficient REST API with HTTP >>> - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) >>> >> > > O cara vai bem at?: > Version your API, and never change released features > Depois desse ponto o texto desanda em incorre??es e s? mostra como as > pesoas tem uma pregui?a violenta de estudar. > > Versionar uma API (j? ? complicado falar em API quando se est? falando em > Rest) ? bom, mas, n?o, por favor, n?o coloque a vers?o da API na URI do > recurso, a vers?o da API ? parte da negocia??o de m?dia, deve ser feita da > mesma forma que se negocia locale, por exemplo, ou formato de documento > (HTML, XML, JSON). > > Na sequencia, falando de Hateoas, o cara confirma, mais uma vez, a > dificuldade que o cidad?o comum tem em separar o exemplo do conceito, o > concreto do abstrato. Nada impede voc? de implementar seu Rest em XML, > JSON, YAML ou at? mesmo usando outros formatos conhecidos. O tipo de > documento ? ortogonal ? especifica??o do recurso. > > De fato esse levantamento demonstra a necessidade de documenta??o mais > acess?vel sobre Rest. Ent?o isso mostraria a relev?ncia de fazermos um > Equin?cio sobre Rest? > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sat Jan 31 15:42:49 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 21:42:49 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Message-ID: Em 31 de janeiro de 2015 19:45, Lucas Mateus escreveu: > Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" em > v?rios casos AngularJS ? uma Porcaria principalmente para desktop, mais > especificamente para motores de busca. Se voc? quer vender tem que aparecer > no Google, se usar AngularJS esquece motores de busca. > Ou voc? contrata uma equipe de pessoas preocupadas em fazer as coisas corretas, a? n?o vai ter problema com indexa??o. Enviado pelo meu Windows Phone > ------------------------------ > De: Leonardo Ruoso > Enviada em: ?31/?01/?2015 18:38 > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > > > Em 31 de janeiro de 2015 18:09, Leonardo Ruoso > escreveu: > >> Em 31 de janeiro de 2015 17:48, Renato Santos >> escreveu: >> >>> Mais links para ler: >>> >>> REST APIs must be hypertext-driven >>> - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven >>> (too strict) >>> >> > De fato, ? o mais strictu senso que voc? vai encontrar sobre Rest: um > texto do Roy Fielding :p > > Creating an efficient REST API with HTTP >>> - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) >>> >> > > O cara vai bem at?: > Version your API, and never change released features > Depois desse ponto o texto desanda em incorre??es e s? mostra como as > pesoas tem uma pregui?a violenta de estudar. > > Versionar uma API (j? ? complicado falar em API quando se est? falando em > Rest) ? bom, mas, n?o, por favor, n?o coloque a vers?o da API na URI do > recurso, a vers?o da API ? parte da negocia??o de m?dia, deve ser feita da > mesma forma que se negocia locale, por exemplo, ou formato de documento > (HTML, XML, JSON). > > Na sequencia, falando de Hateoas, o cara confirma, mais uma vez, a > dificuldade que o cidad?o comum tem em separar o exemplo do conceito, o > concreto do abstrato. Nada impede voc? de implementar seu Rest em XML, > JSON, YAML ou at? mesmo usando outros formatos conhecidos. O tipo de > documento ? ortogonal ? especifica??o do recurso. > > De fato esse levantamento demonstra a necessidade de documenta??o mais > acess?vel sobre Rest. Ent?o isso mostraria a relev?ncia de fazermos um > Equin?cio sobre Rest? > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Sat Jan 31 15:48:43 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 21:48:43 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Message-ID: Em 31 de janeiro de 2015 19:56, Renato Santos escreveu: > Verdade, > A ?nica verdade ? que as pessoas assumem que sabem muito mais do que deveriam assumir e n?o se preocupam em estudar quando encontram um desafio novo, querem sempre continuar fazendo as mesmas coisas de sempre, mas colocando r?tulos novos para "vender melhor". Enfim, a parte boa ? que nem sou eu que estou indicando raz?es pelas quais estudar Rest hoje ? importante. > Aplica??es otimizadas para SEO s?o complicadas com o AngularJS ou qualquer > outro framework que trabalha no client side. > Aplica??es otimizadas para SEO s?o perfeitamente saud?veis com AngularJS ou qualquer outro framework web rico ou Single Page App e se for Rest j? nasce feito. > Existem, IMHO, gambiarras, tipo botar um selenium entre o nginx. > Acho que voc? queria falar do Phantom, mas, bem, isso ? gambiarra mesmo e n?o funciona. > (http-server) -> detecta o user-agent, se for browser, compila uma vers?o > do html com selenium e ai cospe uma pagina inteira. > A ?nica raz?o para fazer isso ? contornar as limita??es de um projeto muito mal feito, e com pouco conte?do ou pouca renova??o de conte?do. > O Meteor est? ai pra provar que ? complicado ter uma > aplica??o com Reactivity. Eu, pessoalmente, acho que este tipo de > aplica??es ? para apenas alguns sistemas, pelo menos do jeito que eles > implementaram, usando o mongodb para manter os clientes atualizados e > enviar atualizacoes para o server. > Explica melhor o lance do MongoDB enviando atualiza??o? > 2015-01-31 19:45 GMT-02:00 Lucas Mateus : > >> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >> em v?rios casos AngularJS ? uma Porcaria principalmente para desktop, mais >> especificamente para motores de busca. Se voc? quer vender tem que aparecer >> no Google, se usar AngularJS esquece motores de busca. >> >> Enviado pelo meu Windows Phone >> ------------------------------ >> De: Leonardo Ruoso >> Enviada em: ?31/?01/?2015 18:38 >> Para: saopaulo-pm at mail.pm.org >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> >> >> Em 31 de janeiro de 2015 18:09, Leonardo Ruoso >> escreveu: >> >>> Em 31 de janeiro de 2015 17:48, Renato Santos >>> escreveu: >>> >>>> Mais links para ler: >>>> >>>> REST APIs must be hypertext-driven >>>> - >>>> http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven >>>> (too strict) >>>> >>> >> De fato, ? o mais strictu senso que voc? vai encontrar sobre Rest: um >> texto do Roy Fielding :p >> >> Creating an efficient REST API with HTTP >>>> - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) >>>> >>> >> >> O cara vai bem at?: >> Version your API, and never change released features >> Depois desse ponto o texto desanda em incorre??es e s? mostra como as >> pesoas tem uma pregui?a violenta de estudar. >> >> Versionar uma API (j? ? complicado falar em API quando se est? falando em >> Rest) ? bom, mas, n?o, por favor, n?o coloque a vers?o da API na URI do >> recurso, a vers?o da API ? parte da negocia??o de m?dia, deve ser feita da >> mesma forma que se negocia locale, por exemplo, ou formato de documento >> (HTML, XML, JSON). >> >> Na sequencia, falando de Hateoas, o cara confirma, mais uma vez, a >> dificuldade que o cidad?o comum tem em separar o exemplo do conceito, o >> concreto do abstrato. Nada impede voc? de implementar seu Rest em XML, >> JSON, YAML ou at? mesmo usando outros formatos conhecidos. O tipo de >> documento ? ortogonal ? especifica??o do recurso. >> >> De fato esse levantamento demonstra a necessidade de documenta??o mais >> acess?vel sobre Rest. Ent?o isso mostraria a relev?ncia de fazermos um >> Equin?cio sobre Rest? >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =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: From leonardo at ruoso.com Sat Jan 31 15:49:49 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sat, 31 Jan 2015 21:49:49 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Message-ID: Em 31 de janeiro de 2015 21:42, Leonardo Ruoso escreveu: > Em 31 de janeiro de 2015 19:45, Lucas Mateus < > lucasmateus.oliveira at gmail.com> escreveu: > >> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >> > Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From lucasmateus.oliveira at gmail.com Sat Jan 31 16:30:16 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Sat, 31 Jan 2015 22:30:16 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> Message-ID: <54cd7390.5177e00a.49c0.0d66@mx.google.com> Indexar uma app AngularJS ? Como se faz isso ? Enviado pelo meu Windows Phone -----Mensagem Original----- De: "Leonardo Ruoso" Enviada em: ?31/?01/?2015 21:50 Para: "saopaulo-pm at mail.pm.org" Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 21:42, Leonardo Ruoso escreveu: Em 31 de janeiro de 2015 19:45, Lucas Mateus escreveu: Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From leonardo at ruoso.com Sun Feb 1 01:39:54 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 07:39:54 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54cd7390.5177e00a.49c0.0d66@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: Em 31 de janeiro de 2015 22:30, Lucas Mateus escreveu: > Indexar uma app AngularJS ? Como se faz isso ? > A resposta can?nica ?, ironicamente considerando esta thread, *implementando um servi?o Rest* by the book. Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente ? apenas obtido do server, mas ele roda no computador do usu?rio e poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. ? nessa ora, ironicamente, que compreender a arquitetura com que se pretende trabalhar faz *toda* a diferen?a. Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos que foram acumulados para isso nos ?ltimos 30 anos. Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com conte?do *machine readableb.* De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que mesmo um com?rcio de flores local se beneficia de contratar uma empresa ou consultor atualizado para desenhar seus softwares e que voc? n?o precisa trabalhar para Google, Facebook ou Twitter para precisar se preocupar em adquirir conhecimento formal sobre as tecnologias que emprega. > Enviado pelo meu Windows Phone > ------------------------------ > De: Leonardo Ruoso > Enviada em: ?31/?01/?2015 21:50 > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > Em 31 de janeiro de 2015 21:42, Leonardo Ruoso > escreveu: > >> Em 31 de janeiro de 2015 19:45, Lucas Mateus < >> lucasmateus.oliveira at gmail.com> escreveu: >> >>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >>> >> > Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From blabos at gmail.com Sun Feb 1 04:07:38 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sun, 1 Feb 2015 10:07:38 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: Gente voc?s est?o fazendo eu me sentir velho! A solu??o pra indexar aplica??es em AngularJS existe desde 1999. Ningu?m lembra dela porque ela foi criada "antes" do Google indexar p?ginas. Confesso que eu mesmo n?o me lembrava at? pouco tempo atr?s. Nunca usei. ? genial de t?o boba. KISS. Pago uma cerveja pra quem fizer o dever de casa (Ruoso, vc n?o). *** Numa coisa eu tenho que concordar, o tom dessa conversa aparenta ser mais arrogante do que realmente ?, de ambos os lados. Vamos abaixar as tochas! (Ok, talvez por causa da seca, melhor n?o...) Se por um lado, o Ruoso parece um arrogante sabedor da verdade, por outro, pelo fato de cada um de n?s j? ter implementado com sucesso, aplica??es que contrariam o que ele diz (eu me incluo), tamb?m somos resistentes a aceitar que a nossa solu??o ? "errada". ? errada mesmo? Notem, certo e errado s?o palavras fortes e podem ser relativas. Muitas vezes estamos lidando com constrains de neg?cio, como tempo por exemplo, motivo pelo qual nem sempre podemos ler a tese do fielding de ponta a ponta, o que tamb?m n?o ? uma desculpa pra n?o buscar entender melhor as nossas escolhas. Essa diverg?ncia toda acontece porque o HTTP ? um protocolo t?o simples e t?o genial, que ele permite os mais variados usos, ou seja, h? uma gama enorme de formas de us?-lo. Boas, ruins, mais ou menos, ?timas, etc. HTTP tem tudo a ver com Perl, h? mais de uma forma de fazer, algumas melhores que as outras. Por que A ? melhor que B? Bom, a? depende de um monte de fatores e entend?-los bem ? (ou deveria ser) o foco dessa conversa. N?o ? porque eu vou estudar RESTful que eu vou ter que fazer tudo como o fielding diz, mas saber por que eu n?o estou fazendo me d? confian?a. Coisas que eu gostaria de discutir: 1) RESTful ? a solu??o pro meu problema? Ou um REST based ? melhor? Ou um levemente REST inspired? Ou seria melhor fazer SOAP? Ou RPC bin?rio? Por qu?? 2) Existem v?rias formas de fazer autentica??o. Qual a melhor pro meu caso? Por que a forma A ? melhor que a B? 3) Como eu versiono? Na URI? No header? Por qu?? 4) Como eu desacoplo os componentes? Eu preciso mesmo ter baixo acoplamento? Por qu?? 5) E a performance? E o cache? 6) Como fa?o upgrades? Como extendo? Como mantenho a compatibilidade? Preciso disso? Por qu?? 7) Que outras perguntas eu deveria estar fazendo? Eu gostaria muito de nos reunirmos pessoalmente, ao menos uma vez por semana, discutir o assunto, eventualmente implementar alguma coisa e depois a gente podia escrever a respeito. Pra esse equin?cio? Talvez sim, talvez esteja muito em cima pra digerir tudo. D? pra sair at? um curso disso. O que acham? []'s 2015-02-01 7:39 GMT-02:00 Leonardo Ruoso : > Em 31 de janeiro de 2015 22:30, Lucas Mateus > escreveu: >> >> Indexar uma app AngularJS ? Como se faz isso ? > > > A resposta can?nica ?, ironicamente considerando esta thread, implementando > um servi?o Rest by the book. > > Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? tudo > indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente ? > apenas obtido do server, mas ele roda no computador do usu?rio e poderia > mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > > ? nessa ora, ironicamente, que compreender a arquitetura com que se pretende > trabalhar faz toda a diferen?a. > > Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes > sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos > que foram acumulados para isso nos ?ltimos 30 anos. > > Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e funciona, > vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com > conte?do machine readableb. > > De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que mesmo > um com?rcio de flores local se beneficia de contratar uma empresa ou > consultor atualizado para desenhar seus softwares e que voc? n?o precisa > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > adquirir conhecimento formal sobre as tecnologias que emprega. > >> >> Enviado pelo meu Windows Phone >> ________________________________ >> De: Leonardo Ruoso >> Enviada em: ?31/?01/?2015 21:50 >> Para: saopaulo-pm at mail.pm.org >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >> escreveu: >>> >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus >>> escreveu: >>>> >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >> >> >> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >> recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. >> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From lucasmateus.oliveira at gmail.com Sun Feb 1 04:16:46 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Sun, 1 Feb 2015 10:16:46 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: <54ce192c.525c8c0a.760a.08b7@mx.google.com> So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o servem ao "internauta" e sim a uma outra aplica??o. Enviado pelo meu Windows Phone -----Mensagem Original----- De: "Leonardo Ruoso" Enviada em: ?01/?02/?2015 07:40 Para: "saopaulo-pm at mail.pm.org" Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 22:30, Lucas Mateus escreveu: Indexar uma app AngularJS ? Como se faz isso ? A resposta can?nica ?, ironicamente considerando esta thread, implementando um servi?o Rest by the book. Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente ? apenas obtido do server, mas ele roda no computador do usu?rio e poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. ? nessa ora, ironicamente, que compreender a arquitetura com que se pretende trabalhar faz toda a diferen?a. Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos que foram acumulados para isso nos ?ltimos 30 anos. Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com conte?do machine readableb. De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que mesmo um com?rcio de flores local se beneficia de contratar uma empresa ou consultor atualizado para desenhar seus softwares e que voc? n?o precisa trabalhar para Google, Facebook ou Twitter para precisar se preocupar em adquirir conhecimento formal sobre as tecnologias que emprega. Enviado pelo meu Windows Phone De: Leonardo Ruoso Enviada em: ?31/?01/?2015 21:50 Para: saopaulo-pm at mail.pm.org Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 21:42, Leonardo Ruoso escreveu: Em 31 de janeiro de 2015 19:45, Lucas Mateus escreveu: Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org L =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: From blabos at gmail.com Sun Feb 1 04:26:45 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sun, 1 Feb 2015 10:26:45 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54ce192c.525c8c0a.760a.08b7@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> Message-ID: > So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > servem ao "internauta" e sim a uma outra aplica??o. Pra mim isso faz todo sentido, concordo com voc?. O que a gente est? dizendo aqui ? que ? poss?vel fazer SEO de uma aplica??o AngularJS completamente renderizadas com javascript. N?o sei se ? isso que eu entendi que vc entendeu :) []'s 2015-02-01 10:16 GMT-02:00 Lucas Mateus : > So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > servem ao "internauta" e sim a uma outra aplica??o. > > Enviado pelo meu Windows Phone > ________________________________ > De: Leonardo Ruoso > Enviada em: ?01/?02/?2015 07:40 > > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > Em 31 de janeiro de 2015 22:30, Lucas Mateus > escreveu: >> >> Indexar uma app AngularJS ? Como se faz isso ? > > > A resposta can?nica ?, ironicamente considerando esta thread, implementando > um servi?o Rest by the book. > > Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? tudo > indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente ? > apenas obtido do server, mas ele roda no computador do usu?rio e poderia > mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > > ? nessa ora, ironicamente, que compreender a arquitetura com que se pretende > trabalhar faz toda a diferen?a. > > Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes > sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos > que foram acumulados para isso nos ?ltimos 30 anos. > > Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e funciona, > vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com > conte?do machine readableb. > > De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que mesmo > um com?rcio de flores local se beneficia de contratar uma empresa ou > consultor atualizado para desenhar seus softwares e que voc? n?o precisa > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > adquirir conhecimento formal sobre as tecnologias que emprega. > >> >> Enviado pelo meu Windows Phone >> ________________________________ >> De: Leonardo Ruoso >> Enviada em: ?31/?01/?2015 21:50 >> Para: saopaulo-pm at mail.pm.org >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >> escreveu: >>> >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus >>> escreveu: >>>> >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >> >> >> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >> recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. >> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From leonardo at ruoso.com Sun Feb 1 04:27:52 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 10:27:52 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54ce192c.525c8c0a.760a.08b7@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 10:16, Lucas Mateus < lucasmateus.oliveira at gmail.com> escreveu: > So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > servem ao "internauta" e sim a uma outra aplica??o. > ? por isso que eu digo que ? t?o importante estudar e entender o que ? rest antes de afirmar categoricamente coisas sobre Rest sem dispor da informa??o necess?ria. A frase acima pode ser v?lida para milh?es de aplica??es que prov?m interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para Rest. E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de Rest continuaremos sendo PICARETAS, continuaremos sendo o equivalente do mec?nico da REBIMBOCA DA PARAFUSETA. ? simples assim! N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma coisas sem sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? sendo profissional. Assim somos n?s. > Enviado pelo meu Windows Phone > ------------------------------ > De: Leonardo Ruoso > Enviada em: ?01/?02/?2015 07:40 > > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > Em 31 de janeiro de 2015 22:30, Lucas Mateus < > lucasmateus.oliveira at gmail.com> escreveu: > >> Indexar uma app AngularJS ? Como se faz isso ? >> > > A resposta can?nica ?, ironicamente considerando esta thread, *implementando > um servi?o Rest* by the book. > > Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? > tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu > cliente ? apenas obtido do server, mas ele roda no computador do usu?rio e > poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > > ? nessa ora, ironicamente, que compreender a arquitetura com que se > pretende trabalhar faz *toda* a diferen?a. > > Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes > sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos > que foram acumulados para isso nos ?ltimos 30 anos. > > Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, > apenas com conte?do *machine readableb.* > > De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que > mesmo um com?rcio de flores local se beneficia de contratar uma empresa ou > consultor atualizado para desenhar seus softwares e que voc? n?o precisa > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > adquirir conhecimento formal sobre as tecnologias que emprega. > > >> Enviado pelo meu Windows Phone >> ------------------------------ >> De: Leonardo Ruoso >> Enviada em: ?31/?01/?2015 21:50 >> Para: saopaulo-pm at mail.pm.org >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >> escreveu: >> >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus < >>> lucasmateus.oliveira at gmail.com> escreveu: >>> >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >>>> >>> >> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >> recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. >> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =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: From lucasmateus.oliveira at gmail.com Sun Feb 1 04:47:33 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Sun, 1 Feb 2015 10:47:33 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> Message-ID: <54ce2062.c7658c0a.0df4.5573@mx.google.com> Bom pode ser que esta muito abstrato para o meu entendimento. Leonardo poderia dar um exemplo concreto de como isso seria ? Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou dono da verdade e posso estar errado. Enviado pelo meu Windows Phone -----Mensagem Original----- De: "Leonardo Ruoso" Enviada em: ?01/?02/?2015 10:28 Para: "saopaulo-pm at mail.pm.org" Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 1 de fevereiro de 2015 10:16, Lucas Mateus escreveu: So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o servem ao "internauta" e sim a uma outra aplica??o. ? por isso que eu digo que ? t?o importante estudar e entender o que ? rest antes de afirmar categoricamente coisas sobre Rest sem dispor da informa??o necess?ria. A frase acima pode ser v?lida para milh?es de aplica??es que prov?m interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para Rest. E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de Rest continuaremos sendo PICARETAS, continuaremos sendo o equivalente do mec?nico da REBIMBOCA DA PARAFUSETA. ? simples assim! N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma coisas sem sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? sendo profissional. Assim somos n?s. Enviado pelo meu Windows Phone De: Leonardo Ruoso Enviada em: ?01/?02/?2015 07:40 Para: saopaulo-pm at mail.pm.org Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 22:30, Lucas Mateus escreveu: Indexar uma app AngularJS ? Como se faz isso ? A resposta can?nica ?, ironicamente considerando esta thread, implementando um servi?o Rest by the book. Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente ? apenas obtido do server, mas ele roda no computador do usu?rio e poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. ? nessa ora, ironicamente, que compreender a arquitetura com que se pretende trabalhar faz toda a diferen?a. Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos que foram acumulados para isso nos ?ltimos 30 anos. Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com conte?do machine readableb. De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que mesmo um com?rcio de flores local se beneficia de contratar uma empresa ou consultor atualizado para desenhar seus softwares e que voc? n?o precisa trabalhar para Google, Facebook ou Twitter para precisar se preocupar em adquirir conhecimento formal sobre as tecnologias que emprega. Enviado pelo meu Windows Phone De: Leonardo Ruoso Enviada em: ?31/?01/?2015 21:50 Para: saopaulo-pm at mail.pm.org Assunto: Re: [SP-pm] Resumo do Evento T?cnico Em 31 de janeiro de 2015 21:42, Leonardo Ruoso escreveu: Em 31 de janeiro de 2015 19:45, Lucas Mateus escreveu: Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org L =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 at pm.org L =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: From blabos at gmail.com Sun Feb 1 04:53:50 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sun, 1 Feb 2015 10:53:50 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54ce2062.c7658c0a.0df4.5573@mx.google.com> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou dono da > verdade e posso estar errado. O pior ? que d?. Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma aplica??o JS sim. Ainda t? valendo uma cerveja :) Bora juntar a galera e fazer umas meetings essa semana, depois do expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. Quem topa? []'s 2015-02-01 10:47 GMT-02:00 Lucas Mateus : > Bom pode ser que esta muito abstrato para o meu entendimento. Leonardo > poderia dar um exemplo concreto de como isso seria ? > > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou dono da > verdade e posso estar errado. > > Enviado pelo meu Windows Phone > ________________________________ > De: Leonardo Ruoso > Enviada em: ?01/?02/?2015 10:28 > > Para: saopaulo-pm at mail.pm.org > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > Em 1 de fevereiro de 2015 10:16, Lucas Mateus > escreveu: >> >> So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o >> servem ao "internauta" e sim a uma outra aplica??o. > > > ? por isso que eu digo que ? t?o importante estudar e entender o que ? rest > antes de afirmar categoricamente coisas sobre Rest sem dispor da informa??o > necess?ria. > > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para Rest. > > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de Rest > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do mec?nico > da REBIMBOCA DA PARAFUSETA. > > ? simples assim! > > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma coisas sem > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? sendo > profissional. Assim somos n?s. > > >> >> Enviado pelo meu Windows Phone >> ________________________________ >> De: Leonardo Ruoso >> Enviada em: ?01/?02/?2015 07:40 >> >> Para: saopaulo-pm at mail.pm.org >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> Em 31 de janeiro de 2015 22:30, Lucas Mateus >> escreveu: >>> >>> Indexar uma app AngularJS ? Como se faz isso ? >> >> >> A resposta can?nica ?, ironicamente considerando esta thread, >> implementando um servi?o Rest by the book. >> >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu >> cliente ? apenas obtido do server, mas ele roda no computador do usu?rio e >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. >> >> ? nessa ora, ironicamente, que compreender a arquitetura com que se >> pretende trabalhar faz toda a diferen?a. >> >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais >> servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em redes >> sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos >> que foram acumulados para isso nos ?ltimos 30 anos. >> >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, >> apenas com conte?do machine readableb. >> >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que >> mesmo um com?rcio de flores local se beneficia de contratar uma empresa ou >> consultor atualizado para desenhar seus softwares e que voc? n?o precisa >> trabalhar para Google, Facebook ou Twitter para precisar se preocupar em >> adquirir conhecimento formal sobre as tecnologias que emprega. >> >>> >>> Enviado pelo meu Windows Phone >>> ________________________________ >>> De: Leonardo Ruoso >>> Enviada em: ?31/?01/?2015 21:50 >>> Para: saopaulo-pm at mail.pm.org >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >>> >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >>> escreveu: >>>> >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus >>>> escreveu: >>>>> >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo" >>> >>> >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >>> recomendando AngularJS em compara??o com o perfil de quem recomenda MongoDB. >>> >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From leonardo at ruoso.com Sun Feb 1 04:57:10 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 10:57:10 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 10:07, Blabos de Blebe escreveu: > Gente voc?s est?o fazendo eu me sentir velho! > > A solu??o pra indexar aplica??es em AngularJS existe desde 1999. > Formas "criativas" para indexar softwares cujos clientes s?o implementados em AngularJS existem desde o HTTP 1.0/HTML 1.0, quando n?o havia sequer CSS. Solu??o formal para indexar aplica??es cujo cliente ? AngularJS existe formalmente desde 2000 (Rest ? uma inova??o tecnol?gica quando prop?e aplicar o conceito Web a Comunica??o Interprocessual). Essa solu??o chama-se REST! > Ningu?m lembra dela porque ela foi criada "antes" do Google indexar > p?ginas. Confesso que eu mesmo n?o me lembrava at? pouco tempo atr?s. > Nunca usei. ? genial de t?o boba. KISS. > Pago uma cerveja pra quem fizer o dever de casa (Ruoso, vc n?o). > At? pelo fato de que voc? sabe que eu tenho aplica??es JSON-RPC (com implementa??o parcial de Rest) feitas com AngularJS e Catalyst e que s?o indexadas pelo Google, compartilhadas no Facebook e etc... Ent?o voc? sabe que eu aprendi a fazer a gambiarra antes de saber fazer direito. > *** > > Se por um lado, o Ruoso parece um arrogante sabedor da verdade, por > outro, pelo fato de cada um de n?s j? ter implementado com sucesso, > aplica??es que contrariam o que ele diz (eu me incluo), tamb?m somos > resistentes a aceitar que a nossa solu??o ? "errada". ? errada mesmo? > Minha experi?ncia vem de SOAP/WSDL e por conta disso a primeira vez que eu tive de fazer um aplica??o Rest eu implementei, com a ajuda de colegas, JSON-RPC. Fiz isso e descobri magicamente que a aplica??o n?o era indexada (todos com que eu trabalhava na ?poca assumiram que o Google seria super legal com a gente e eu fui absolutamente humilhado na frente dos meus s?cios --li??o aprendida: implementamos uma gambiarra para fazer a aplica??o) e conseguimos corrigir isso com um hack cujo suporte ? totalmente formal e totalmente KISS. Agora, depois disso, estou experimentando e orientando pessoas que est?o desenvolvendo aplica??es em AngularJS e estamos sofrendo com todos os velhos problemas de desenvolvimento de componentes fortemente acoplados, quando o cliente solicitou que fosse uma aplica??o Rest e n?s fizemos JSON-RPC uma vez mais. Isso, necessidade pr?tica, levou-me a buscar saber o que est?vamos fazendo de errado. Felizmente, em meu projeto atual, eu tenho um substituto para o Eden (saudades do baiano), e por isso tinha uma pessoa com quem conversar e com a qual estou aprendendo bastante. Ele ? Arquiteto Java e sabe, tem consci?ncia, de que n?o est? conseguindo fazer as coisas direito no projeto, que ele ainda n?o conseguiu estabelecer os componentes corretos de arquitetura, mas est? COMPROMETIDO em melhorar a cada projeto. Isso ? algo que me parece n?o existir muitas vezes sob a desculpa de que d? muito trabalho fazer as coisas direito. > Notem, certo e errado s?o palavras fortes e podem ser relativas. > Certo e errado existem, nem sempre conseguimos fazer o certo, s? que n?s n?o somos padeiros falando de engenharia de software, n?s temos obriga??o formal de tratar as coisas pelos nomes certos. Eu n?o disse em nenhum momento que ningu?m deveria fazer JSON-RPC ou XML-RPC. Eu disse que era irrespons?vel apenas adotar uma terminologia sem se preocupar em entender o que ela significa e os motivos pelos quais ? festejada. Mesmo tentando entender e tentando implementar ainda podemos falhar, mas ? nossa responsabilidade estarmos conscientes disso, n?o do nosso cliente. > Muitas vezes estamos lidando com constrains de neg?cio, como tempo por > exemplo, motivo pelo qual nem sempre podemos ler a tese do fielding de > ponta a ponta, o que tamb?m n?o ? uma desculpa pra n?o buscar entender > melhor as nossas escolhas. > Pera, n?o temos que ler a disserta??o dele todos os dias, basta ler uma vez, duas dependendo da sua dificuldade em apreender conceitos t?cnicos. > Essa diverg?ncia toda acontece porque o HTTP ? um protocolo t?o > simples e t?o genial, que ele permite os mais variados usos, ou seja, > h? uma gama enorme de formas de us?-lo. Boas, ruins, mais ou menos, > ?timas, etc. > > HTTP tem tudo a ver com Perl, h? mais de uma forma de fazer, algumas > melhores que as outras. Por que A ? melhor que B? Bom, a? depende de > um monte de fatores e entend?-los bem ? (ou deveria ser) o foco dessa > conversa. > > N?o ? porque eu vou estudar RESTful que eu vou ter que fazer tudo como > o fielding diz, mas saber por que eu n?o estou fazendo me d? > confian?a. > ? certo, inclusive ? importante saber quais s?o as ressalvas que sua aplica??o tem em rela??o ? arquitetura que toma como base. Eu n?o disse jamais que n?o podemos dizer que nossa aplica??o ? baseada em Rest, mas que foi feita antes da recomenda??o JSON-LD sair e por isso usamos JSON-HAL, que deve ser depreciado agora, por exemplo. > Coisas que eu gostaria de discutir: > > 1) RESTful ? a solu??o pro meu problema? Ou um REST based ? melhor? Eu tenho uma dificuldade grande co Restful e Rest. Temos de entender onde tra?amos a fronteira. Isso ? uma d?vida minha. > Ou um levemente REST inspired? Considerando que o aspecto mais importante do Rest ? o HyperDocument, o que consideramos Rest based vs o que ? simplesmente JSON-RPC? > Ou seria melhor fazer SOAP? Ou RPC bin?rio? Por qu?? > RPC bin?rio requer compatibilidade bin?ria. SOAP ? uma especifica??o bastante madura, que permite manejar documentos e fazer RPC. > 2) Existem v?rias formas de fazer autentica??o. Qual a melhor pro meu > caso? Por que a forma A ? melhor que a B? > > 3) Como eu versiono? Na URI? No header? Por qu?? > Eu entendo que ter a vers?o na URI ? equivocada, exceto no caso da vers?o ser do objeto em si. Se a vers?o ? do protocolo, ent?o n?o deve participar da vers?o do documento. ? a mesma coisa que voc? ter a vers?o do HTML (1..5) na URI, isso seria equivocado. > 4) Como eu desacoplo os componentes? Eu preciso mesmo ter > baixo acoplamento? Por qu?? > Rest engloba uma proposta madura para desacoplar componentes, mas SOAP tamb?m disp?e de solu??es vi?veis para isso. Sempre que seu cliente dispuser de informa??es out-of-band espec?ficas da aplica??o ou do recurso voc? tem forte acoplamento. A desvantagem de forte acoplamento ? que qualquer mudan?a em qualquer recurso/objeto requer uma atualiza??o do cliente e isso ? uma desvantagem at? quando estamos falando de ThickClient com Swing, por exemplo. O Swing j? foi feito para que fosse poss?vel desenvolver ThickClient desacoplado ou menos acoplado aos servi?os. Se falarmos de m?ltiplos clientes diferentes, integra??o entre aplica??o, ? quase imoral propormos interfaces fortemente acopladas, pois o custo de manuten??o passa a ser algo como (O(n!)) e isso ? insustent?vel economicamente. 5) E a performance? E o cache? > Opa, performance e cache est?o no amalgama das vantagens do Rest. > 6) Como fa?o upgrades? Como extendo? Como mantenho a compatibilidade? > Preciso disso? Por qu?? > Com fraco acomplamento voc? continua tendo upgrades, exceto que s?o menos frequentes e sua aplica??o pode continuar funcionando, ao menos com suporte parcial, ? medida em que fica obsoleta. Isso ? especialmente importante falando de IoT. > 7) Que outras perguntas eu deveria estar fazendo? > Eu entendo que autoriza??o ? um problema bem mais complexo que autentica??o, por exemplo. > Eu gostaria muito de nos reunirmos pessoalmente, ao menos uma vez por > semana, discutir o assunto, eventualmente implementar alguma coisa e > depois a gente podia escrever a respeito. Pra esse equin?cio? Talvez > sim, talvez esteja muito em cima pra digerir tudo. > ? minha proposta! > D? pra sair at? um curso disso. > D? para sair um livro mesmo. > O que acham? > Eu QUERO, como diria o Eduardo Jorge. > > []'s > > 2015-02-01 7:39 GMT-02:00 Leonardo Ruoso : > > Em 31 de janeiro de 2015 22:30, Lucas Mateus > > escreveu: > >> > >> Indexar uma app AngularJS ? Como se faz isso ? > > > > > > A resposta can?nica ?, ironicamente considerando esta thread, > implementando > > um servi?o Rest by the book. > > > > Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? > tudo > > indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente > ? > > apenas obtido do server, mas ele roda no computador do usu?rio e poderia > > mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > > > > ? nessa ora, ironicamente, que compreender a arquitetura com que se > pretende > > trabalhar faz toda a diferen?a. > > > > Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > > servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > > acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em > redes > > sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos > > que foram acumulados para isso nos ?ltimos 30 anos. > > > > Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > funciona, > > vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com > > conte?do machine readableb. > > > > De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que > mesmo > > um com?rcio de flores local se beneficia de contratar uma empresa ou > > consultor atualizado para desenhar seus softwares e que voc? n?o precisa > > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > > adquirir conhecimento formal sobre as tecnologias que emprega. > > > >> > >> Enviado pelo meu Windows Phone > >> ________________________________ > >> De: Leonardo Ruoso > >> Enviada em: ?31/?01/?2015 21:50 > >> Para: saopaulo-pm at mail.pm.org > >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> > >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso > >> escreveu: > >>> > >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus > >>> escreveu: > >>>> > >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em > mongo" > >> > >> > >> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > >> recomendando AngularJS em compara??o com o perfil de quem recomenda > MongoDB. > >> > >> > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From tiago.peczenyj at gmail.com Sun Feb 1 05:00:14 2015 From: tiago.peczenyj at gmail.com (Tiago Peczenyj) Date: Sun, 1 Feb 2015 11:00:14 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> Message-ID: Isomorfismo B?blia on line faz isso e est? indexada no Google Em 01/02/2015 10:27, "Blabos de Blebe" escreveu: > > So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > > servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > > servem ao "internauta" e sim a uma outra aplica??o. > > Pra mim isso faz todo sentido, concordo com voc?. > > O que a gente est? dizendo aqui ? que ? poss?vel fazer SEO de uma > aplica??o AngularJS completamente renderizadas com javascript. > > N?o sei se ? isso que eu entendi que vc entendeu :) > > []'s > > > 2015-02-01 10:16 GMT-02:00 Lucas Mateus : > > So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > > servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > > servem ao "internauta" e sim a uma outra aplica??o. > > > > Enviado pelo meu Windows Phone > > ________________________________ > > De: Leonardo Ruoso > > Enviada em: ?01/?02/?2015 07:40 > > > > Para: saopaulo-pm at mail.pm.org > > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > > > Em 31 de janeiro de 2015 22:30, Lucas Mateus > > escreveu: > >> > >> Indexar uma app AngularJS ? Como se faz isso ? > > > > > > A resposta can?nica ?, ironicamente considerando esta thread, > implementando > > um servi?o Rest by the book. > > > > Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? > tudo > > indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente > ? > > apenas obtido do server, mas ele roda no computador do usu?rio e poderia > > mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > > > > ? nessa ora, ironicamente, que compreender a arquitetura com que se > pretende > > trabalhar faz toda a diferen?a. > > > > Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > > servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > > acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em > redes > > sociais, embebida em outros sites, etc? com todos os mesmos conhecimentos > > que foram acumulados para isso nos ?ltimos 30 anos. > > > > Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > funciona, > > vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com > > conte?do machine readableb. > > > > De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que > mesmo > > um com?rcio de flores local se beneficia de contratar uma empresa ou > > consultor atualizado para desenhar seus softwares e que voc? n?o precisa > > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > > adquirir conhecimento formal sobre as tecnologias que emprega. > > > >> > >> Enviado pelo meu Windows Phone > >> ________________________________ > >> De: Leonardo Ruoso > >> Enviada em: ?31/?01/?2015 21:50 > >> Para: saopaulo-pm at mail.pm.org > >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> > >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso > >> escreveu: > >>> > >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus > >>> escreveu: > >>>> > >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em > mongo" > >> > >> > >> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > >> recomendando AngularJS em compara??o com o perfil de quem recomenda > MongoDB. > >> > >> > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Sun Feb 1 05:00:46 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 11:00:46 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 10:53, Blabos de Blebe escreveu: > > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou > dono da > > verdade e posso estar errado. > > O pior ? que d?. > > Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma > aplica??o JS sim. Ainda t? valendo uma cerveja :) > Estritamente falando, com JSON, estamos no estado de W3C Recommendation. Com XML j? ? absolutamente maduro. Com HTML tamb?m. Bora juntar a galera e fazer umas meetings essa semana, depois do > expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. > Essa semana ? complicado depois do expediente, estou meio que pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o estou nem achando ruim) S?bado para mim seria ideal. > Quem topa? > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos emprestar uma sala de reuni?o perto da Paulista. > []'s > > > 2015-02-01 10:47 GMT-02:00 Lucas Mateus : > > Bom pode ser que esta muito abstrato para o meu entendimento. Leonardo > > poderia dar um exemplo concreto de como isso seria ? > > > > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou > dono da > > verdade e posso estar errado. > > > > Enviado pelo meu Windows Phone > > ________________________________ > > De: Leonardo Ruoso > > Enviada em: ?01/?02/?2015 10:28 > > > > Para: saopaulo-pm at mail.pm.org > > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > > > > Em 1 de fevereiro de 2015 10:16, Lucas Mateus > > escreveu: > >> > >> So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam > >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o > >> servem ao "internauta" e sim a uma outra aplica??o. > > > > > > ? por isso que eu digo que ? t?o importante estudar e entender o que ? > rest > > antes de afirmar categoricamente coisas sobre Rest sem dispor da > informa??o > > necess?ria. > > > > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m > > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para Rest. > > > > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de Rest > > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do > mec?nico > > da REBIMBOCA DA PARAFUSETA. > > > > ? simples assim! > > > > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma coisas > sem > > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? sendo > > profissional. Assim somos n?s. > > > > > >> > >> Enviado pelo meu Windows Phone > >> ________________________________ > >> De: Leonardo Ruoso > >> Enviada em: ?01/?02/?2015 07:40 > >> > >> Para: saopaulo-pm at mail.pm.org > >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> > >> Em 31 de janeiro de 2015 22:30, Lucas Mateus > >> escreveu: > >>> > >>> Indexar uma app AngularJS ? Como se faz isso ? > >> > >> > >> A resposta can?nica ?, ironicamente considerando esta thread, > >> implementando um servi?o Rest by the book. > >> > >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? > >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu > >> cliente ? apenas obtido do server, mas ele roda no computador do > usu?rio e > >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS App. > >> > >> ? nessa ora, ironicamente, que compreender a arquitetura com que se > >> pretende trabalhar faz toda a diferen?a. > >> > >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais > >> servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos > >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em > redes > >> sociais, embebida em outros sites, etc? com todos os mesmos > conhecimentos > >> que foram acumulados para isso nos ?ltimos 30 anos. > >> > >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, > >> apenas com conte?do machine readableb. > >> > >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que > >> mesmo um com?rcio de flores local se beneficia de contratar uma empresa > ou > >> consultor atualizado para desenhar seus softwares e que voc? n?o precisa > >> trabalhar para Google, Facebook ou Twitter para precisar se preocupar em > >> adquirir conhecimento formal sobre as tecnologias que emprega. > >> > >>> > >>> Enviado pelo meu Windows Phone > >>> ________________________________ > >>> De: Leonardo Ruoso > >>> Enviada em: ?31/?01/?2015 21:50 > >>> Para: saopaulo-pm at mail.pm.org > >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >>> > >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso > >>> escreveu: > >>>> > >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus > >>>> escreveu: > >>>>> > >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em > mongo" > >>> > >>> > >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > >>> recomendando AngularJS em compara??o com o perfil de quem recomenda > MongoDB. > >>> > >>> > >>> > >>> =begin disclaimer > >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>> L > >>> =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 at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Sun Feb 1 05:04:30 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 11:04:30 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 11:00, Leonardo Ruoso escreveu: > Em 1 de fevereiro de 2015 10:53, Blabos de Blebe > escreveu: > >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >> dono da >> > verdade e posso estar errado. >> >> O pior ? que d?. >> >> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >> aplica??o JS sim. Ainda t? valendo uma cerveja :) >> > > Estritamente falando, com JSON, estamos no estado de W3C Recommendation. > > Com XML j? ? absolutamente maduro. > > Com HTML tamb?m. > > Bora juntar a galera e fazer umas meetings essa semana, depois do >> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >> > > Essa semana ? complicado depois do expediente, estou meio que > pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o > estou nem achando ruim) > > S?bado para mim seria ideal. > > >> Quem topa? >> > > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos > emprestar uma sala de reuni?o perto da Paulista. > > Aquele CoWorking que tem em cima do metr? consola??o seria uma boa op??o, embora aquele outro l? da Augusta parece ser mais aberto a dar suporte a eventos da comunidade. Acho que estou falando de um chamado Link2U e outro chamado, ah, esqueci, mas ? um dos mais antigos coworkings de S?o Paulo e fica perto da Nefertite :p -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From blabos at gmail.com Sun Feb 1 05:07:46 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sun, 1 Feb 2015 11:07:46 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: > Com HTML tamb?m. Eu s? sei com HTML :( []'s 2015-02-01 11:00 GMT-02:00 Leonardo Ruoso : > Em 1 de fevereiro de 2015 10:53, Blabos de Blebe > escreveu: >> >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >> > dono da >> > verdade e posso estar errado. >> >> O pior ? que d?. >> >> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >> aplica??o JS sim. Ainda t? valendo uma cerveja :) > > > Estritamente falando, com JSON, estamos no estado de W3C Recommendation. > > Com XML j? ? absolutamente maduro. > > Com HTML tamb?m. > >> Bora juntar a galera e fazer umas meetings essa semana, depois do >> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. > > > Essa semana ? complicado depois do expediente, estou meio que pr?-programado > para fazer 12h por dia (e por ser fevereiro com carnaval n?o estou nem > achando ruim) > > S?bado para mim seria ideal. > >> >> Quem topa? > > > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos > emprestar uma sala de reuni?o perto da Paulista. > >> >> []'s >> >> >> 2015-02-01 10:47 GMT-02:00 Lucas Mateus : >> > Bom pode ser que esta muito abstrato para o meu entendimento. Leonardo >> > poderia dar um exemplo concreto de como isso seria ? >> > >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >> > dono da >> > verdade e posso estar errado. >> > >> > Enviado pelo meu Windows Phone >> > ________________________________ >> > De: Leonardo Ruoso >> > Enviada em: ?01/?02/?2015 10:28 >> > >> > Para: saopaulo-pm at mail.pm.org >> > Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> > >> > Em 1 de fevereiro de 2015 10:16, Lucas Mateus >> > escreveu: >> >> >> >> So que n?o existe SEO em servi?os Rest, nem os motores de busca indexam >> >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os n?o >> >> servem ao "internauta" e sim a uma outra aplica??o. >> > >> > >> > ? por isso que eu digo que ? t?o importante estudar e entender o que ? >> > rest >> > antes de afirmar categoricamente coisas sobre Rest sem dispor da >> > informa??o >> > necess?ria. >> > >> > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m >> > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para >> > Rest. >> > >> > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de >> > Rest >> > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do >> > mec?nico >> > da REBIMBOCA DA PARAFUSETA. >> > >> > ? simples assim! >> > >> > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma coisas >> > sem >> > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? >> > sendo >> > profissional. Assim somos n?s. >> > >> > >> >> >> >> Enviado pelo meu Windows Phone >> >> ________________________________ >> >> De: Leonardo Ruoso >> >> Enviada em: ?01/?02/?2015 07:40 >> >> >> >> Para: saopaulo-pm at mail.pm.org >> >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> >> >> Em 31 de janeiro de 2015 22:30, Lucas Mateus >> >> escreveu: >> >>> >> >>> Indexar uma app AngularJS ? Como se faz isso ? >> >> >> >> >> >> A resposta can?nica ?, ironicamente considerando esta thread, >> >> implementando um servi?o Rest by the book. >> >> >> >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? ter? >> >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu >> >> cliente ? apenas obtido do server, mas ele roda no computador do >> >> usu?rio e >> >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS >> >> App. >> >> >> >> ? nessa ora, ironicamente, que compreender a arquitetura com que se >> >> pretende trabalhar faz toda a diferen?a. >> >> >> >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou mais >> >> servi?os Rest, e faz seu Rest de acordo com todos os bons conhecimentos >> >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em >> >> redes >> >> sociais, embebida em outros sites, etc? com todos os mesmos >> >> conhecimentos >> >> que foram acumulados para isso nos ?ltimos 30 anos. >> >> >> >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e >> >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a >> >> WEB, >> >> apenas com conte?do machine readableb. >> >> >> >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram que >> >> mesmo um com?rcio de flores local se beneficia de contratar uma empresa >> >> ou >> >> consultor atualizado para desenhar seus softwares e que voc? n?o >> >> precisa >> >> trabalhar para Google, Facebook ou Twitter para precisar se preocupar >> >> em >> >> adquirir conhecimento formal sobre as tecnologias que emprega. >> >> >> >>> >> >>> Enviado pelo meu Windows Phone >> >>> ________________________________ >> >>> De: Leonardo Ruoso >> >>> Enviada em: ?31/?01/?2015 21:50 >> >>> Para: saopaulo-pm at mail.pm.org >> >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >>> >> >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >> >>> escreveu: >> >>>> >> >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus >> >>>> escreveu: >> >>>>> >> >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em >> >>>>> mongo" >> >>> >> >>> >> >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >> >>> recomendando AngularJS em compara??o com o perfil de quem recomenda >> >>> MongoDB. >> >>> >> >>> >> >>> >> >>> =begin disclaimer >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >>> L >> >>> =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 at pm.org >> >> L >> >> =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 at pm.org >> > L >> > =end disclaimer >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From leonardo at ruoso.com Sun Feb 1 05:14:05 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 11:14:05 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 10:07, Blabos de Blebe escreveu: > > Se por um lado, o Ruoso parece um arrogante sabedor da verdade, A ?nica verdade que eu sei ? que todas as verdades s?o transit?rias. > por outro, pelo fato de cada um de n?s j? ter implementado com sucesso, > aplica??es que contrariam o que ele diz (eu me incluo), tamb?m somos > resistentes a aceitar que a nossa solu??o ? "errada". ? errada mesmo? > Eu j? implementei MUITO software n?o Rest. N?o digo que foi errado. Errado foi quando implementei JSON-RPC e disse que era Rest, a? foi errado. Eu resisti para caramba para aceitar Rest, justamente pelo fato de que todo mundo que me apresentava Rest me apresentava uma gambiarra de JSON-RPC. A? eu abri meu cora??o para Rest em 2014 e deixei a coisa rolar num projeto. O resultado ficou bem distante de Rest e EU tive de encontrar hacks para os problemas que voc?s mesmos est?o levantando e que de fato existem na maioria das aplica??es thickclient web que usam JSON-RPC e da?, depois dos hacks, vem a necessidade de entender o que fiz de errado, e da?, vem entender que o que todo mundo estava me falando sobre Rest estava ERRADO. E eu tinha feito MERDA como gestor e n?o tinha implementado Rest e da? vinham v?rios problemas que tivemos. Agora, quando eu tenho a necessidade de entender como fazer Rest em ambiente corporativo, em que AUTORIZA??O ? muito mais complexo do que num aplicativo WEB P?BLICO, a? eu tive de estudar Rest e da? eu sei que tem v?rias coisas que EU N?O SEI COMO FAZER EM PERL + HTML/CSS/JS usando Rest. Errado eu entendo que ? enganar as pessoas, seja por ignor?ncia, seja por mal?cia. -- Leonardo Ruoso Journalist, Perl developer and business consultant Media, UFC/2006; Telecom, IFCE/1998 -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From leonardo at ruoso.com Sun Feb 1 05:15:31 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 11:15:31 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Em 1 de fevereiro de 2015 11:07, Blabos de Blebe escreveu: > > Com HTML tamb?m. > > Eu s? sei com HTML :( > Mas aposto que conta nos dedos onde est? implementado "correto", strictu senso, mesmo em HTML :p Que a galera gosta mesmo ? de uma gambiarra :D > []'s > > 2015-02-01 11:00 GMT-02:00 Leonardo Ruoso : > > Em 1 de fevereiro de 2015 10:53, Blabos de Blebe > > escreveu: > >> > >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou > >> > dono da > >> > verdade e posso estar errado. > >> > >> O pior ? que d?. > >> > >> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma > >> aplica??o JS sim. Ainda t? valendo uma cerveja :) > > > > > > Estritamente falando, com JSON, estamos no estado de W3C Recommendation. > > > > Com XML j? ? absolutamente maduro. > > > > Com HTML tamb?m. > > > >> Bora juntar a galera e fazer umas meetings essa semana, depois do > >> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. > > > > > > Essa semana ? complicado depois do expediente, estou meio que > pr?-programado > > para fazer 12h por dia (e por ser fevereiro com carnaval n?o estou nem > > achando ruim) > > > > S?bado para mim seria ideal. > > > >> > >> Quem topa? > > > > > > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos > > emprestar uma sala de reuni?o perto da Paulista. > > > >> > >> []'s > >> > >> > >> 2015-02-01 10:47 GMT-02:00 Lucas Mateus >: > >> > Bom pode ser que esta muito abstrato para o meu entendimento. Leonardo > >> > poderia dar um exemplo concreto de como isso seria ? > >> > > >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou > >> > dono da > >> > verdade e posso estar errado. > >> > > >> > Enviado pelo meu Windows Phone > >> > ________________________________ > >> > De: Leonardo Ruoso > >> > Enviada em: ?01/?02/?2015 10:28 > >> > > >> > Para: saopaulo-pm at mail.pm.org > >> > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> > > >> > Em 1 de fevereiro de 2015 10:16, Lucas Mateus > >> > escreveu: > >> >> > >> >> So que n?o existe SEO em servi?os Rest, nem os motores de busca > indexam > >> >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os > n?o > >> >> servem ao "internauta" e sim a uma outra aplica??o. > >> > > >> > > >> > ? por isso que eu digo que ? t?o importante estudar e entender o que ? > >> > rest > >> > antes de afirmar categoricamente coisas sobre Rest sem dispor da > >> > informa??o > >> > necess?ria. > >> > > >> > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m > >> > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para > >> > Rest. > >> > > >> > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de > >> > Rest > >> > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do > >> > mec?nico > >> > da REBIMBOCA DA PARAFUSETA. > >> > > >> > ? simples assim! > >> > > >> > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma > coisas > >> > sem > >> > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? > >> > sendo > >> > profissional. Assim somos n?s. > >> > > >> > > >> >> > >> >> Enviado pelo meu Windows Phone > >> >> ________________________________ > >> >> De: Leonardo Ruoso > >> >> Enviada em: ?01/?02/?2015 07:40 > >> >> > >> >> Para: saopaulo-pm at mail.pm.org > >> >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> >> > >> >> Em 31 de janeiro de 2015 22:30, Lucas Mateus > >> >> escreveu: > >> >>> > >> >>> Indexar uma app AngularJS ? Como se faz isso ? > >> >> > >> >> > >> >> A resposta can?nica ?, ironicamente considerando esta thread, > >> >> implementando um servi?o Rest by the book. > >> >> > >> >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? > ter? > >> >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, seu > >> >> cliente ? apenas obtido do server, mas ele roda no computador do > >> >> usu?rio e > >> >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS > >> >> App. > >> >> > >> >> ? nessa ora, ironicamente, que compreender a arquitetura com que se > >> >> pretende trabalhar faz toda a diferen?a. > >> >> > >> >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou > mais > >> >> servi?os Rest, e faz seu Rest de acordo com todos os bons > conhecimentos > >> >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada em > >> >> redes > >> >> sociais, embebida em outros sites, etc? com todos os mesmos > >> >> conhecimentos > >> >> que foram acumulados para isso nos ?ltimos 30 anos. > >> >> > >> >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > >> >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a > >> >> WEB, > >> >> apenas com conte?do machine readableb. > >> >> > >> >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram > que > >> >> mesmo um com?rcio de flores local se beneficia de contratar uma > empresa > >> >> ou > >> >> consultor atualizado para desenhar seus softwares e que voc? n?o > >> >> precisa > >> >> trabalhar para Google, Facebook ou Twitter para precisar se preocupar > >> >> em > >> >> adquirir conhecimento formal sobre as tecnologias que emprega. > >> >> > >> >>> > >> >>> Enviado pelo meu Windows Phone > >> >>> ________________________________ > >> >>> De: Leonardo Ruoso > >> >>> Enviada em: ?31/?01/?2015 21:50 > >> >>> Para: saopaulo-pm at mail.pm.org > >> >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> >>> > >> >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso > >> >>> escreveu: > >> >>>> > >> >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus > >> >>>> escreveu: > >> >>>>> > >> >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em > >> >>>>> mongo" > >> >>> > >> >>> > >> >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > >> >>> recomendando AngularJS em compara??o com o perfil de quem recomenda > >> >>> MongoDB. > >> >>> > >> >>> > >> >>> > >> >>> =begin disclaimer > >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >>> L > >> >>> =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 at pm.org > >> >> L > >> >> =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 at pm.org > >> > L > >> > =end disclaimer > >> > > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From blabos at gmail.com Sun Feb 1 05:17:50 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Sun, 1 Feb 2015 11:17:50 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: > Mas aposto que conta nos dedos onde est? implementado "correto", strictu > senso, mesmo em HTML :p Eu mesmo nunca vi nem fiz. S? sei que existe. 2015-02-01 11:15 GMT-02:00 Leonardo Ruoso : > Em 1 de fevereiro de 2015 11:07, Blabos de Blebe > escreveu: >> >> > Com HTML tamb?m. >> >> Eu s? sei com HTML :( > > > Mas aposto que conta nos dedos onde est? implementado "correto", strictu > senso, mesmo em HTML :p > > Que a galera gosta mesmo ? de uma gambiarra :D > >> >> []'s >> >> 2015-02-01 11:00 GMT-02:00 Leonardo Ruoso : >> > Em 1 de fevereiro de 2015 10:53, Blabos de Blebe >> > escreveu: >> >> >> >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >> >> > dono da >> >> > verdade e posso estar errado. >> >> >> >> O pior ? que d?. >> >> >> >> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >> >> aplica??o JS sim. Ainda t? valendo uma cerveja :) >> > >> > >> > Estritamente falando, com JSON, estamos no estado de W3C Recommendation. >> > >> > Com XML j? ? absolutamente maduro. >> > >> > Com HTML tamb?m. >> > >> >> Bora juntar a galera e fazer umas meetings essa semana, depois do >> >> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >> > >> > >> > Essa semana ? complicado depois do expediente, estou meio que >> > pr?-programado >> > para fazer 12h por dia (e por ser fevereiro com carnaval n?o estou nem >> > achando ruim) >> > >> > S?bado para mim seria ideal. >> > >> >> >> >> Quem topa? >> > >> > >> > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos >> > emprestar uma sala de reuni?o perto da Paulista. >> > >> >> >> >> []'s >> >> >> >> >> >> 2015-02-01 10:47 GMT-02:00 Lucas Mateus >> >> : >> >> > Bom pode ser que esta muito abstrato para o meu entendimento. >> >> > Leonardo >> >> > poderia dar um exemplo concreto de como isso seria ? >> >> > >> >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >> >> > dono da >> >> > verdade e posso estar errado. >> >> > >> >> > Enviado pelo meu Windows Phone >> >> > ________________________________ >> >> > De: Leonardo Ruoso >> >> > Enviada em: ?01/?02/?2015 10:28 >> >> > >> >> > Para: saopaulo-pm at mail.pm.org >> >> > Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> > >> >> > Em 1 de fevereiro de 2015 10:16, Lucas Mateus >> >> > escreveu: >> >> >> >> >> >> So que n?o existe SEO em servi?os Rest, nem os motores de busca >> >> >> indexam >> >> >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os >> >> >> n?o >> >> >> servem ao "internauta" e sim a uma outra aplica??o. >> >> > >> >> > >> >> > ? por isso que eu digo que ? t?o importante estudar e entender o que >> >> > ? >> >> > rest >> >> > antes de afirmar categoricamente coisas sobre Rest sem dispor da >> >> > informa??o >> >> > necess?ria. >> >> > >> >> > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m >> >> > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para >> >> > Rest. >> >> > >> >> > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC de >> >> > Rest >> >> > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do >> >> > mec?nico >> >> > da REBIMBOCA DA PARAFUSETA. >> >> > >> >> > ? simples assim! >> >> > >> >> > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma >> >> > coisas >> >> > sem >> >> > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? >> >> > sendo >> >> > profissional. Assim somos n?s. >> >> > >> >> > >> >> >> >> >> >> Enviado pelo meu Windows Phone >> >> >> ________________________________ >> >> >> De: Leonardo Ruoso >> >> >> Enviada em: ?01/?02/?2015 07:40 >> >> >> >> >> >> Para: saopaulo-pm at mail.pm.org >> >> >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> >> >> >> >> Em 31 de janeiro de 2015 22:30, Lucas Mateus >> >> >> escreveu: >> >> >>> >> >> >>> Indexar uma app AngularJS ? Como se faz isso ? >> >> >> >> >> >> >> >> >> A resposta can?nica ?, ironicamente considerando esta thread, >> >> >> implementando um servi?o Rest by the book. >> >> >> >> >> >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? >> >> >> ter? >> >> >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, >> >> >> seu >> >> >> cliente ? apenas obtido do server, mas ele roda no computador do >> >> >> usu?rio e >> >> >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou iOS >> >> >> App. >> >> >> >> >> >> ? nessa ora, ironicamente, que compreender a arquitetura com que se >> >> >> pretende trabalhar faz toda a diferen?a. >> >> >> >> >> >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou >> >> >> mais >> >> >> servi?os Rest, e faz seu Rest de acordo com todos os bons >> >> >> conhecimentos >> >> >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada >> >> >> em >> >> >> redes >> >> >> sociais, embebida em outros sites, etc? com todos os mesmos >> >> >> conhecimentos >> >> >> que foram acumulados para isso nos ?ltimos 30 anos. >> >> >> >> >> >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e >> >> >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos a >> >> >> WEB, >> >> >> apenas com conte?do machine readableb. >> >> >> >> >> >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram >> >> >> que >> >> >> mesmo um com?rcio de flores local se beneficia de contratar uma >> >> >> empresa >> >> >> ou >> >> >> consultor atualizado para desenhar seus softwares e que voc? n?o >> >> >> precisa >> >> >> trabalhar para Google, Facebook ou Twitter para precisar se >> >> >> preocupar >> >> >> em >> >> >> adquirir conhecimento formal sobre as tecnologias que emprega. >> >> >> >> >> >>> >> >> >>> Enviado pelo meu Windows Phone >> >> >>> ________________________________ >> >> >>> De: Leonardo Ruoso >> >> >>> Enviada em: ?31/?01/?2015 21:50 >> >> >>> Para: saopaulo-pm at mail.pm.org >> >> >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico >> >> >>> >> >> >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso >> >> >>> escreveu: >> >> >>>> >> >> >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus >> >> >>>> escreveu: >> >> >>>>> >> >> >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em >> >> >>>>> mongo" >> >> >>> >> >> >>> >> >> >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? >> >> >>> recomendando AngularJS em compara??o com o perfil de quem recomenda >> >> >>> MongoDB. >> >> >>> >> >> >>> >> >> >>> >> >> >>> =begin disclaimer >> >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >> >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> >>> L >> >> >>> =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 at pm.org >> >> >> L >> >> >> =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 at pm.org >> >> > L >> >> > =end disclaimer >> >> > >> >> =begin disclaimer >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> >> L >> >> =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 at pm.org >> > L >> > =end disclaimer >> > >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From lucasmateus.oliveira at gmail.com Sun Feb 1 07:32:00 2015 From: lucasmateus.oliveira at gmail.com (Lucas Mateus) Date: Sun, 1 Feb 2015 13:32:00 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: > Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma > aplica??o JS sim. Ainda t? valendo uma cerveja :) Blabos se tiver falando de tag noscript pelo amor de Deus. O Googlebot at? l? coisas de javascript (como document.write) e tags de noscript. Mas como o navegador n?o usa a tag noscript pq ele renderiza script, isso acaba n?o tendo relev?ncia pq o que vai importar ? o que o script vai fazer e n?o o noscript. E digo com certeza, uma solu??o "gambi" dessas na empresa em que trabalho geraria prejuizo de alguns milh?es / dia. Talvez numa app nova voc? n?o percebe pq ela n?o da lucro. E la na frente vai se perguntar pq ela continua n?o dando lucro. Em 1 de fevereiro de 2015 11:17, Blabos de Blebe escreveu: > > Mas aposto que conta nos dedos onde est? implementado "correto", strictu > > senso, mesmo em HTML :p > > Eu mesmo nunca vi nem fiz. S? sei que existe. > > 2015-02-01 11:15 GMT-02:00 Leonardo Ruoso : > > Em 1 de fevereiro de 2015 11:07, Blabos de Blebe > > escreveu: > >> > >> > Com HTML tamb?m. > >> > >> Eu s? sei com HTML :( > > > > > > Mas aposto que conta nos dedos onde est? implementado "correto", strictu > > senso, mesmo em HTML :p > > > > Que a galera gosta mesmo ? de uma gambiarra :D > > > >> > >> []'s > >> > >> 2015-02-01 11:00 GMT-02:00 Leonardo Ruoso : > >> > Em 1 de fevereiro de 2015 10:53, Blabos de Blebe > >> > escreveu: > >> >> > >> >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o > dou > >> >> > dono da > >> >> > verdade e posso estar errado. > >> >> > >> >> O pior ? que d?. > >> >> > >> >> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma > >> >> aplica??o JS sim. Ainda t? valendo uma cerveja :) > >> > > >> > > >> > Estritamente falando, com JSON, estamos no estado de W3C > Recommendation. > >> > > >> > Com XML j? ? absolutamente maduro. > >> > > >> > Com HTML tamb?m. > >> > > >> >> Bora juntar a galera e fazer umas meetings essa semana, depois do > >> >> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. > >> > > >> > > >> > Essa semana ? complicado depois do expediente, estou meio que > >> > pr?-programado > >> > para fazer 12h por dia (e por ser fevereiro com carnaval n?o estou nem > >> > achando ruim) > >> > > >> > S?bado para mim seria ideal. > >> > > >> >> > >> >> Quem topa? > >> > > >> > > >> > Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos > >> > emprestar uma sala de reuni?o perto da Paulista. > >> > > >> >> > >> >> []'s > >> >> > >> >> > >> >> 2015-02-01 10:47 GMT-02:00 Lucas Mateus > >> >> : > >> >> > Bom pode ser que esta muito abstrato para o meu entendimento. > >> >> > Leonardo > >> >> > poderia dar um exemplo concreto de como isso seria ? > >> >> > > >> >> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o > dou > >> >> > dono da > >> >> > verdade e posso estar errado. > >> >> > > >> >> > Enviado pelo meu Windows Phone > >> >> > ________________________________ > >> >> > De: Leonardo Ruoso > >> >> > Enviada em: ?01/?02/?2015 10:28 > >> >> > > >> >> > Para: saopaulo-pm at mail.pm.org > >> >> > Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> >> > > >> >> > Em 1 de fevereiro de 2015 10:16, Lucas Mateus > >> >> > escreveu: > >> >> >> > >> >> >> So que n?o existe SEO em servi?os Rest, nem os motores de busca > >> >> >> indexam > >> >> >> servi?os Rest e se indexar n?o tem relev?ncia, pois esses servi?os > >> >> >> n?o > >> >> >> servem ao "internauta" e sim a uma outra aplica??o. > >> >> > > >> >> > > >> >> > ? por isso que eu digo que ? t?o importante estudar e entender o > que > >> >> > ? > >> >> > rest > >> >> > antes de afirmar categoricamente coisas sobre Rest sem dispor da > >> >> > informa??o > >> >> > necess?ria. > >> >> > > >> >> > A frase acima pode ser v?lida para milh?es de aplica??es que prov?m > >> >> > interfaces JSON-RPC ou JSON-XML, s? ? absolutamente equivocada para > >> >> > Rest. > >> >> > > >> >> > E ? a? que eu insisto que enquanto continuarmos chamando JSON-RPC > de > >> >> > Rest > >> >> > continuaremos sendo PICARETAS, continuaremos sendo o equivalente do > >> >> > mec?nico > >> >> > da REBIMBOCA DA PARAFUSETA. > >> >> > > >> >> > ? simples assim! > >> >> > > >> >> > N?o faz diferen?a para o tomador do servi?o se o mec?nico afirma > >> >> > coisas > >> >> > sem > >> >> > sentido por ignor?ncia ou por mal?cia, em nenhum dos casos ele est? > >> >> > sendo > >> >> > profissional. Assim somos n?s. > >> >> > > >> >> > > >> >> >> > >> >> >> Enviado pelo meu Windows Phone > >> >> >> ________________________________ > >> >> >> De: Leonardo Ruoso > >> >> >> Enviada em: ?01/?02/?2015 07:40 > >> >> >> > >> >> >> Para: saopaulo-pm at mail.pm.org > >> >> >> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> >> >> > >> >> >> Em 31 de janeiro de 2015 22:30, Lucas Mateus > >> >> >> escreveu: > >> >> >>> > >> >> >>> Indexar uma app AngularJS ? Como se faz isso ? > >> >> >> > >> >> >> > >> >> >> A resposta can?nica ?, ironicamente considerando esta thread, > >> >> >> implementando um servi?o Rest by the book. > >> >> >> > >> >> >> Se sua App AngularJS for cliente de um ou mais servi?os Rest, voc? > >> >> >> ter? > >> >> >> tudo indexado. De fato, pouco importa seu cliente, pois, a rigor, > >> >> >> seu > >> >> >> cliente ? apenas obtido do server, mas ele roda no computador do > >> >> >> usu?rio e > >> >> >> poderia mesmo ser distribu?do como uma WebApp ou Android App ou > iOS > >> >> >> App. > >> >> >> > >> >> >> ? nessa ora, ironicamente, que compreender a arquitetura com que > se > >> >> >> pretende trabalhar faz toda a diferen?a. > >> >> >> > >> >> >> Enim, se voc? implementa AngularJS como aplica??o cliente de um ou > >> >> >> mais > >> >> >> servi?os Rest, e faz seu Rest de acordo com todos os bons > >> >> >> conhecimentos > >> >> >> acumulados em SEO, voc? ter? sua aplica??o indexada, compartilhada > >> >> >> em > >> >> >> redes > >> >> >> sociais, embebida em outros sites, etc? com todos os mesmos > >> >> >> conhecimentos > >> >> >> que foram acumulados para isso nos ?ltimos 30 anos. > >> >> >> > >> >> >> Nada muda, pois Rest nada mais ? do que: Olha como a WEB ? legal e > >> >> >> funciona, vamos fazer componentes de rede EXATAMENTE como fizemos > a > >> >> >> WEB, > >> >> >> apenas com conte?do machine readableb. > >> >> >> > >> >> >> De fato, voc?s s? levantaram mais um ponto e mostraram ou provaram > >> >> >> que > >> >> >> mesmo um com?rcio de flores local se beneficia de contratar uma > >> >> >> empresa > >> >> >> ou > >> >> >> consultor atualizado para desenhar seus softwares e que voc? n?o > >> >> >> precisa > >> >> >> trabalhar para Google, Facebook ou Twitter para precisar se > >> >> >> preocupar > >> >> >> em > >> >> >> adquirir conhecimento formal sobre as tecnologias que emprega. > >> >> >> > >> >> >>> > >> >> >>> Enviado pelo meu Windows Phone > >> >> >>> ________________________________ > >> >> >>> De: Leonardo Ruoso > >> >> >>> Enviada em: ?31/?01/?2015 21:50 > >> >> >>> Para: saopaulo-pm at mail.pm.org > >> >> >>> Assunto: Re: [SP-pm] Resumo do Evento T?cnico > >> >> >>> > >> >> >>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso < > leonardo at ruoso.com> > >> >> >>> escreveu: > >> >> >>>> > >> >> >>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus > >> >> >>>> escreveu: > >> >> >>>>> > >> >> >>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo > em > >> >> >>>>> mongo" > >> >> >>> > >> >> >>> > >> >> >>> Tem uma ?nica diferen?a, que ? o perfil profissional de quem est? > >> >> >>> recomendando AngularJS em compara??o com o perfil de quem > recomenda > >> >> >>> MongoDB. > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> =begin disclaimer > >> >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >> >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >> >>> L > >> >> >>> =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 at pm.org > >> >> >> L > >> >> >> =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 at pm.org > >> >> > L > >> >> > =end disclaimer > >> >> > > >> >> =begin disclaimer > >> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> >> L > >> >> =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 at pm.org > >> > L > >> > =end disclaimer > >> > > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From glasswalk3r at yahoo.com.br Sun Feb 1 07:42:36 2015 From: glasswalk3r at yahoo.com.br (Alceu Rodrigues de Freitas Junior) Date: Sun, 01 Feb 2015 13:42:36 -0200 Subject: [SP-pm] =?windows-1252?q?Resumo_do_Evento_T=E9cnico?= In-Reply-To: References: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> Message-ID: <54CE496C.7050802@yahoo.com.br> On 01-02-2015 10:57, Leonardo Ruoso wrote: > > 4) Como eu desacoplo os componentes? Eu preciso mesmo ter > baixo acoplamento? Por qu?? > > > Rest engloba uma proposta madura para desacoplar componentes, mas SOAP > tamb?m disp?e de solu??es vi?veis para isso. > > Sempre que seu cliente dispuser de informa??es out-of-band espec?ficas > da aplica??o ou do recurso voc? tem forte acoplamento. > > A desvantagem de forte acoplamento ? que qualquer mudan?a em qualquer > recurso/objeto requer uma atualiza??o do cliente e isso ? uma > desvantagem at? quando estamos falando de ThickClient com Swing, por > exemplo. O Swing j? foi feito para que fosse poss?vel desenvolver > ThickClient desacoplado ou menos acoplado aos servi?os. > Se falarmos de m?ltiplos clientes diferentes, integra??o entre > aplica??o, ? quase imoral propormos interfaces fortemente acopladas, > pois o custo de manuten??o passa a ser algo como (O(n!)) e isso ? > insustent?vel economicamente. > > 5) E a performance? E o cache? > > > Opa, performance e cache est?o no amalgama das vantagens do Rest. > Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento sobre Rest se encontram distantes da especifica??o original. :-) Conhe?o um pouco de SOAP e j? sofri bastante ao tentar implementar algo usando o "Programming Web Services with Perl" j? que na ?poca (2008/2009) o SOAP::Lite*** j? n?o servia para praticamente merda nenhuma (n?o sei como est? hoje) comparado a ferramentas de desenvolvimento para web services dispon?veis para .Net e Java. No entanto, essa hist?ria de baixo acoplamento/forte acoplamento tem forte rela??o com desempenho. Sei que o foco aqui ? ambiente web, mas fica dif?cil uma interface com outro sistema ser de baixo acoplamento (e portanto ter uma s?rie de abstra??es) ter um desempenho melhor do que algo como fazer uma chamada RPC (Sun RPC, Java RMI, etc) ou mesmo incorporar no seu c?digo uma biblioteca de terceiros. A especifica??o do SOAP ? complexa porque em teoria deveria permitir que sistemas fizessem integra??es entre si com o menor esfor?o poss?vel... mas algu?m a? j? viu UDDI funcionando? Por outro lado eu j? vi erros de integra??o usando SOAP que poderiam ter sido resolvidos em fase de projeto se simplesmente o XML Schema definido no WSDL tivesse inclu?do o tamanho m?ximo dos elementos (o que me faz pensar que a equipe de projeto estava tentando usar espoletas em uma Magnum 44). Estabelecidas minhas limita??es sobre o tema... como o Rest se prop?e a lidar com essas quest?es? Garantir que o formato de dados trocados seja interpretado da forma correta, com baixo acoplamento entre os dois sistemas e com desempenho vantajoso? Ali?s, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML RPC? JSON RPC? Abra?o, Alceu *** j? que estamos falando de livro sobre o tema, a literatura dispon?vel para Perl e web services est? completamente defasada, n?o? From leonardo at ruoso.com Sun Feb 1 11:44:09 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 17:44:09 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54CE496C.7050802@yahoo.com.br> References: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54CE496C.7050802@yahoo.com.br> Message-ID: Em 1 de fevereiro de 2015 13:42, Alceu Rodrigues de Freitas Junior < glasswalk3r at yahoo.com.br> escreveu: > On 01-02-2015 10:57, Leonardo Ruoso wrote: >> >> [...] > 5) E a performance? E o cache? > > >> >> Opa, performance e cache est?o no amalgama das vantagens do Rest. >> >> > Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento > sobre Rest se encontram distantes da especifica??o original. :-) > O ?nico detalhe ? que eu n?o conhe?o nenhuma segunda vers?o de especifica??o. :p > Conhe?o um pouco de SOAP e j? sofri bastante ao tentar implementar algo > usando o "Programming Web Services with Perl" j? que na ?poca (2008/2009) o > SOAP::Lite*** j? n?o servia para praticamente merda nenhuma (n?o sei como > est? hoje) comparado a ferramentas de desenvolvimento para web services > dispon?veis para .Net e Java. > Olha, eu uso muito os m?dulos do Daniel (meu irm?o) para Catalyst, que estendem outros componentes e s?o dessa ?poca a? (2007/2008). Ent?o pode ser uma quest?o de escolher os m?dulos corretos. Inclusive temos suporte para a aberra??o que ? a implementa??o da Microsoft. Que est? muito longe de ser boa: ? uma desgra?a de fato, mas temos de suportar para conversar com API feitas por pessoas que implementam .Net e que tem pregui?a de estudar especifica??o e fazem qualquer merda sem se preocupar com o que est?o fazendo s? pelo fato de que est? funcionando (parecendo funcionar) para eles. > No entanto, essa hist?ria de baixo acoplamento/forte acoplamento tem forte > rela??o com desempenho. Qual desempenho? Runtime? > Sei que o foco aqui ? ambiente web, mas fica dif?cil uma interface com > outro sistema ser de baixo acoplamento (e portanto ter uma s?rie de > abstra??es) ter um desempenho melhor do que algo como fazer uma chamada RPC > (Sun RPC, Java RMI, etc) ou mesmo incorporar no seu c?digo uma biblioteca > de terceiros. > Um exemplo de clients que s?o ou deveriam ser desenvolvidos com baixo acoplamento e que tem performance excelente s?o os clientes de AMQP. No caso desses clientes as classes s?o constru?das a partir dos elementos do XML da especifica??o do componente, logo se voc? estender o seu servidor (com plugins por exemplo) e usar apenas tipos previamente conhecidos o cliente deve ser capaz de conversar com seu plugin, ou seja, o que baixo acoplamento define ? que se eu estiver usando a mesma vers?o da API eu posso ter objetos diferentes: eu tenho de saber lidar com todo o vocabul?rio da API, mas a API pode ser incrementada, decrementada ou modificada dentro do escopo desse vocabul?rio e seu cliente continuar? compat?vel. O ?nico impacto que eu percebo nisso ? de compile time ou no momento em que recebo uma notifica??o de altera??o do schema. > A especifica??o do SOAP ? complexa porque em teoria deveria permitir que > sistemas fizessem integra??es entre si com o menor esfor?o poss?vel... mas > algu?m a? j? viu UDDI funcionando? > Para SOAP/WSDL sobre HTTP, sobre XMPP e sobre SMTP. > Por outro lado eu j? vi erros de integra??o usando SOAP que poderiam ter > sido resolvidos em fase de projeto se simplesmente o XML Schema definido no > WSDL tivesse inclu?do o tamanho m?ximo dos elementos (o que me faz pensar > que a equipe de projeto estava tentando usar espoletas em uma Magnum 44). > Mas voc? pode atualizar o WSDL em tempo de desenvolvimento caso identifique problemas no projeto original. Isso s?o problemas ortogonais: waterfall vs agile n?o tem nada a ver com schema vs schema-less. Claro que fazer waterfall com schema-less ? suic?dio. > Estabelecidas minhas limita??es sobre o tema... como o Rest se prop?e a > lidar com essas quest?es? Garantir que o formato de dados trocados seja > interpretado da forma correta, com baixo acoplamento entre os dois sistemas > e com desempenho vantajoso? > Em XML as solu??es s?o uma continuidade das solu??es que estavam dispon?veis no SOAP. Sendo conservadores, dever?amos usar XML at? que as especifica??es JSON fossem aprovadas ou estivessem em vias de aprova??o. Para JSON temos Recommendation saindo, mas o normal ? usar Json-Schema, Json-LD e suprir lacunas ainda existentes por imita??o das op??es dispon?veis em HTML/XML. > Ali?s, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML > RPC? JSON RPC? > Quest?o de desempenho tende a ser bastante melhor com Rest uma vez que Rest permite usar Cache enquanto Soap n?o. N?o faz sentido falar que um resultado de uma chamada s?ncrona n?o foi alterado desde hh:mm, enquanto faz todo sentido falar que um objeto persistido, um hyperdocumento, foi alterado pela ?ltima vez em hh:mm e por isso o cliente que j? tem essa c?pia pode n?o fazer um novo GET. > Abra?o, > > Alceu > > *** j? que estamos falando de livro sobre o tema, a literatura dispon?vel > para Perl e web services est? completamente defasada, n?o? > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From leonardo at ruoso.com Sun Feb 1 11:44:09 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Sun, 1 Feb 2015 17:44:09 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <54CE496C.7050802@yahoo.com.br> References: <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54CE496C.7050802@yahoo.com.br> Message-ID: Em 1 de fevereiro de 2015 13:42, Alceu Rodrigues de Freitas Junior < glasswalk3r at yahoo.com.br> escreveu: > On 01-02-2015 10:57, Leonardo Ruoso wrote: >> >> [...] > 5) E a performance? E o cache? > > >> >> Opa, performance e cache est?o no amalgama das vantagens do Rest. >> >> > Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento > sobre Rest se encontram distantes da especifica??o original. :-) > O ?nico detalhe ? que eu n?o conhe?o nenhuma segunda vers?o de especifica??o. :p > Conhe?o um pouco de SOAP e j? sofri bastante ao tentar implementar algo > usando o "Programming Web Services with Perl" j? que na ?poca (2008/2009) o > SOAP::Lite*** j? n?o servia para praticamente merda nenhuma (n?o sei como > est? hoje) comparado a ferramentas de desenvolvimento para web services > dispon?veis para .Net e Java. > Olha, eu uso muito os m?dulos do Daniel (meu irm?o) para Catalyst, que estendem outros componentes e s?o dessa ?poca a? (2007/2008). Ent?o pode ser uma quest?o de escolher os m?dulos corretos. Inclusive temos suporte para a aberra??o que ? a implementa??o da Microsoft. Que est? muito longe de ser boa: ? uma desgra?a de fato, mas temos de suportar para conversar com API feitas por pessoas que implementam .Net e que tem pregui?a de estudar especifica??o e fazem qualquer merda sem se preocupar com o que est?o fazendo s? pelo fato de que est? funcionando (parecendo funcionar) para eles. > No entanto, essa hist?ria de baixo acoplamento/forte acoplamento tem forte > rela??o com desempenho. Qual desempenho? Runtime? > Sei que o foco aqui ? ambiente web, mas fica dif?cil uma interface com > outro sistema ser de baixo acoplamento (e portanto ter uma s?rie de > abstra??es) ter um desempenho melhor do que algo como fazer uma chamada RPC > (Sun RPC, Java RMI, etc) ou mesmo incorporar no seu c?digo uma biblioteca > de terceiros. > Um exemplo de clients que s?o ou deveriam ser desenvolvidos com baixo acoplamento e que tem performance excelente s?o os clientes de AMQP. No caso desses clientes as classes s?o constru?das a partir dos elementos do XML da especifica??o do componente, logo se voc? estender o seu servidor (com plugins por exemplo) e usar apenas tipos previamente conhecidos o cliente deve ser capaz de conversar com seu plugin, ou seja, o que baixo acoplamento define ? que se eu estiver usando a mesma vers?o da API eu posso ter objetos diferentes: eu tenho de saber lidar com todo o vocabul?rio da API, mas a API pode ser incrementada, decrementada ou modificada dentro do escopo desse vocabul?rio e seu cliente continuar? compat?vel. O ?nico impacto que eu percebo nisso ? de compile time ou no momento em que recebo uma notifica??o de altera??o do schema. > A especifica??o do SOAP ? complexa porque em teoria deveria permitir que > sistemas fizessem integra??es entre si com o menor esfor?o poss?vel... mas > algu?m a? j? viu UDDI funcionando? > Para SOAP/WSDL sobre HTTP, sobre XMPP e sobre SMTP. > Por outro lado eu j? vi erros de integra??o usando SOAP que poderiam ter > sido resolvidos em fase de projeto se simplesmente o XML Schema definido no > WSDL tivesse inclu?do o tamanho m?ximo dos elementos (o que me faz pensar > que a equipe de projeto estava tentando usar espoletas em uma Magnum 44). > Mas voc? pode atualizar o WSDL em tempo de desenvolvimento caso identifique problemas no projeto original. Isso s?o problemas ortogonais: waterfall vs agile n?o tem nada a ver com schema vs schema-less. Claro que fazer waterfall com schema-less ? suic?dio. > Estabelecidas minhas limita??es sobre o tema... como o Rest se prop?e a > lidar com essas quest?es? Garantir que o formato de dados trocados seja > interpretado da forma correta, com baixo acoplamento entre os dois sistemas > e com desempenho vantajoso? > Em XML as solu??es s?o uma continuidade das solu??es que estavam dispon?veis no SOAP. Sendo conservadores, dever?amos usar XML at? que as especifica??es JSON fossem aprovadas ou estivessem em vias de aprova??o. Para JSON temos Recommendation saindo, mas o normal ? usar Json-Schema, Json-LD e suprir lacunas ainda existentes por imita??o das op??es dispon?veis em HTML/XML. > Ali?s, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML > RPC? JSON RPC? > Quest?o de desempenho tende a ser bastante melhor com Rest uma vez que Rest permite usar Cache enquanto Soap n?o. N?o faz sentido falar que um resultado de uma chamada s?ncrona n?o foi alterado desde hh:mm, enquanto faz todo sentido falar que um objeto persistido, um hyperdocumento, foi alterado pela ?ltima vez em hh:mm e por isso o cliente que j? tem essa c?pia pode n?o fazer um novo GET. > Abra?o, > > Alceu > > *** j? que estamos falando de livro sobre o tema, a literatura dispon?vel > para Perl e web services est? completamente defasada, n?o? > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Mon Feb 2 05:29:59 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Mon, 2 Feb 2015 11:29:59 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Eu topo. Sobre o lugar, vcs conhecem um clube chamado Garoa HC? ? um clube de hackers que fica bem perto da esta??o Pinheiros do metr?. Eu n?o sou s?cio, s? fui algumas vezes, o pessoal ? bem receptivo. Podemos pedir emprestado para bater um papo l? e ver se rola. O Garoa ? s? uma id?ia, se for em outro lugar eu topo tb. Abs, Em 1 de fevereiro de 2015 11:04, Leonardo Ruoso escreveu: > Em 1 de fevereiro de 2015 11:00, Leonardo Ruoso > escreveu: > >> Em 1 de fevereiro de 2015 10:53, Blabos de Blebe >> escreveu: >> >>> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >>> dono da >>> > verdade e posso estar errado. >>> >>> O pior ? que d?. >>> >>> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >>> aplica??o JS sim. Ainda t? valendo uma cerveja :) >>> >> >> Estritamente falando, com JSON, estamos no estado de W3C Recommendation. >> >> Com XML j? ? absolutamente maduro. >> >> Com HTML tamb?m. >> >> Bora juntar a galera e fazer umas meetings essa semana, depois do >>> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >>> >> >> Essa semana ? complicado depois do expediente, estou meio que >> pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o >> estou nem achando ruim) >> >> S?bado para mim seria ideal. >> >> >>> Quem topa? >>> >> >> Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos >> emprestar uma sala de reuni?o perto da Paulista. >> >> > > Aquele CoWorking que tem em cima do metr? consola??o seria uma boa op??o, > embora aquele outro l? da Augusta parece ser mais aberto a dar suporte a > eventos da comunidade. > > Acho que estou falando de um chamado Link2U e outro chamado, ah, esqueci, > mas ? um dos mais antigos coworkings de S?o Paulo e fica perto da Nefertite > :p > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo at ruoso.com Mon Feb 2 11:47:37 2015 From: leonardo at ruoso.com (Leonardo Ruoso) Date: Mon, 2 Feb 2015 17:47:37 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Em 2 de fevereiro de 2015 11:29, Kojo escreveu: > Eu topo. > Sobre o lugar, vcs conhecem um clube chamado Garoa HC? ? um clube de > hackers que fica bem perto da esta??o Pinheiros do metr?. > Eu n?o sou s?cio, s? fui algumas vezes, o pessoal ? bem receptivo. Podemos > pedir emprestado para bater um papo l? e ver se rola. > O Garoa ? s? uma id?ia, se for em outro lugar eu topo tb. > O Garoa ? uma boa ideia e eu n?o teria problema em me associar, faz tempo que eu quero fazer isso. > > Abs, > > > > Em 1 de fevereiro de 2015 11:04, Leonardo Ruoso > escreveu: > >> Em 1 de fevereiro de 2015 11:00, Leonardo Ruoso >> escreveu: >> >>> Em 1 de fevereiro de 2015 10:53, Blabos de Blebe >>> escreveu: >>> >>>> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >>>> dono da >>>> > verdade e posso estar errado. >>>> >>>> O pior ? que d?. >>>> >>>> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >>>> aplica??o JS sim. Ainda t? valendo uma cerveja :) >>>> >>> >>> Estritamente falando, com JSON, estamos no estado de W3C Recommendation. >>> >>> Com XML j? ? absolutamente maduro. >>> >>> Com HTML tamb?m. >>> >>> Bora juntar a galera e fazer umas meetings essa semana, depois do >>>> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >>>> >>> >>> Essa semana ? complicado depois do expediente, estou meio que >>> pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o >>> estou nem achando ruim) >>> >>> S?bado para mim seria ideal. >>> >>> >>>> Quem topa? >>>> >>> >>> Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos >>> emprestar uma sala de reuni?o perto da Paulista. >>> >>> >> >> Aquele CoWorking que tem em cima do metr? consola??o seria uma boa op??o, >> embora aquele outro l? da Augusta parece ser mais aberto a dar suporte a >> eventos da comunidade. >> >> Acho que estou falando de um chamado Link2U e outro chamado, ah, esqueci, >> mas ? um dos mais antigos coworkings de S?o Paulo e fica perto da Nefertite >> :p >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =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: From rbsnkjmr at gmail.com Mon Feb 2 18:04:42 2015 From: rbsnkjmr at gmail.com (Kojo) Date: Tue, 3 Feb 2015 00:04:42 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: Que dia ? bom? Se formos em poucas pessoas (3, 4 pessoa), acho que ? s? dar um toque para eles. Se forem mais pessoas, a? acho que ? legal perguntar se tudo bem, se v?o ter algum evento no dia etc. Eu gostaria de ir numa segunda, ou ter?a (? partir da semana que vem). Acho tb que s?o os dias mais tranquilos l?. Mas se for de final de semana, tdo bem por mim, ? s? quest?o de combinar. Abs, Em 2 de fevereiro de 2015 17:47, Leonardo Ruoso escreveu: > Em 2 de fevereiro de 2015 11:29, Kojo escreveu: > >> Eu topo. >> Sobre o lugar, vcs conhecem um clube chamado Garoa HC? ? um clube de >> hackers que fica bem perto da esta??o Pinheiros do metr?. >> Eu n?o sou s?cio, s? fui algumas vezes, o pessoal ? bem receptivo. >> Podemos pedir emprestado para bater um papo l? e ver se rola. >> O Garoa ? s? uma id?ia, se for em outro lugar eu topo tb. >> > > O Garoa ? uma boa ideia e eu n?o teria problema em me associar, faz tempo > que eu quero fazer isso. > > >> >> Abs, >> >> >> >> Em 1 de fevereiro de 2015 11:04, Leonardo Ruoso >> escreveu: >> >>> Em 1 de fevereiro de 2015 11:00, Leonardo Ruoso >>> escreveu: >>> >>>> Em 1 de fevereiro de 2015 10:53, Blabos de Blebe >>>> escreveu: >>>> >>>>> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >>>>> dono da >>>>> > verdade e posso estar errado. >>>>> >>>>> O pior ? que d?. >>>>> >>>>> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >>>>> aplica??o JS sim. Ainda t? valendo uma cerveja :) >>>>> >>>> >>>> Estritamente falando, com JSON, estamos no estado de W3C >>>> Recommendation. >>>> >>>> Com XML j? ? absolutamente maduro. >>>> >>>> Com HTML tamb?m. >>>> >>>> Bora juntar a galera e fazer umas meetings essa semana, depois do >>>>> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >>>>> >>>> >>>> Essa semana ? complicado depois do expediente, estou meio que >>>> pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o >>>> estou nem achando ruim) >>>> >>>> S?bado para mim seria ideal. >>>> >>>> >>>>> Quem topa? >>>>> >>>> >>>> Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos >>>> emprestar uma sala de reuni?o perto da Paulista. >>>> >>>> >>> >>> Aquele CoWorking que tem em cima do metr? consola??o seria uma boa >>> op??o, embora aquele outro l? da Augusta parece ser mais aberto a dar >>> suporte a eventos da comunidade. >>> >>> Acho que estou falando de um chamado Link2U e outro chamado, ah, >>> esqueci, mas ? um dos mais antigos coworkings de S?o Paulo e fica perto da >>> Nefertite :p >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandocorrea at gmail.com Tue Feb 3 03:19:42 2015 From: fernandocorrea at gmail.com (=?utf-8?Q?Fernando_Corr=C3=AAa_?=) Date: Tue, 3 Feb 2015 09:19:42 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> Message-ID: <34bf8c9a-d106-4e43-a7b9-4d261b60feb7@iPhone-de-Fernando-Oliveira> Voc?s n?o gostariam de fazer isso virtualmente? Tipo, eu estou no rio, mas gostaria muito de participar dessa discuss?o. -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From frederico at frederico.me Tue Feb 3 04:40:39 2015 From: frederico at frederico.me (Frederico Recsky) Date: Tue, 3 Feb 2015 10:40:39 -0200 Subject: [SP-pm] =?utf-8?q?Resumo_do_Evento_T=C3=A9cnico?= In-Reply-To: <34bf8c9a-d106-4e43-a7b9-4d261b60feb7@iPhone-de-Fernando-Oliveira> References: <411AB3BD-33EA-4938-9F1A-34D3AA3B890A@gmail.com> <0BDE45DE-C80C-4675-996F-9631D585E791@gmail.com> <54cd4ce8.c53ee00a.62ae.ffffccf4@mx.google.com> <54cd7390.5177e00a.49c0.0d66@mx.google.com> <54ce192c.525c8c0a.760a.08b7@mx.google.com> <54ce2062.c7658c0a.0df4.5573@mx.google.com> <34bf8c9a-d106-4e43-a7b9-4d261b60feb7@iPhone-de-Fernando-Oliveira> Message-ID: Remoto ? bem razoavel mesmo, se eu n?o me engano o Solli ja tem mais ou menos o caminho das pedras. Frederico summons Shonorio. :) 2015-02-03 9:19 GMT-02:00 Fernando Corr?a : > Voc?s n?o gostariam de fazer isso virtualmente? Tipo, eu estou no rio, mas > gostaria muito de participar dessa discuss?o. > > Em 03/02/2015 00:04, Kojo escreveu: > > Que dia ? bom? Se formos em poucas pessoas (3, 4 pessoa), acho que ? s? dar > um toque para eles. > Se forem mais pessoas, a? acho que ? legal perguntar se tudo bem, se v?o ter > algum evento no dia etc. > > Eu gostaria de ir numa segunda, ou ter?a (? partir da semana que vem). Acho > tb que s?o os dias mais tranquilos l?. Mas se for de final de semana, tdo > bem por mim, ? s? quest?o de combinar. > > Abs, > > > > Em 2 de fevereiro de 2015 17:47, Leonardo Ruoso > escreveu: >> >> Em 2 de fevereiro de 2015 11:29, Kojo escreveu: >>> >>> Eu topo. >>> Sobre o lugar, vcs conhecem um clube chamado Garoa HC? ? um clube de >>> hackers que fica bem perto da esta??o Pinheiros do metr?. >>> Eu n?o sou s?cio, s? fui algumas vezes, o pessoal ? bem receptivo. >>> Podemos pedir emprestado para bater um papo l? e ver se rola. >>> O Garoa ? s? uma id?ia, se for em outro lugar eu topo tb. >> >> >> O Garoa ? uma boa ideia e eu n?o teria problema em me associar, faz tempo >> que eu quero fazer isso. >> >>> >>> >>> Abs, >>> >>> >>> >>> Em 1 de fevereiro de 2015 11:04, Leonardo Ruoso >>> escreveu: >>>> >>>> Em 1 de fevereiro de 2015 11:00, Leonardo Ruoso >>>> escreveu: >>>>> >>>>> Em 1 de fevereiro de 2015 10:53, Blabos de Blebe >>>>> escreveu: >>>>>> >>>>>> > Sim Blabos, estou dizendo que n?o da pra indexar uma app js, n?o dou >>>>>> > dono da >>>>>> > verdade e posso estar errado. >>>>>> >>>>>> O pior ? que d?. >>>>>> >>>>>> Estritamente falando, n?o. Mas d? pra indexar o conte?do de uma >>>>>> aplica??o JS sim. Ainda t? valendo uma cerveja :) >>>>> >>>>> >>>>> Estritamente falando, com JSON, estamos no estado de W3C >>>>> Recommendation. >>>>> >>>>> Com XML j? ? absolutamente maduro. >>>>> >>>>> Com HTML tamb?m. >>>>> >>>>>> Bora juntar a galera e fazer umas meetings essa semana, depois do >>>>>> expediente? Eu topo sair daqui da Ro?a e ir SP s? pra isso. >>>>> >>>>> >>>>> Essa semana ? complicado depois do expediente, estou meio que >>>>> pr?-programado para fazer 12h por dia (e por ser fevereiro com carnaval n?o >>>>> estou nem achando ruim) >>>>> >>>>> S?bado para mim seria ideal. >>>>> >>>>>> >>>>>> Quem topa? >>>>> >>>>> >>>>> Precisamos de um lugar. Pode ser um coworking ou algu?m que possa nos >>>>> emprestar uma sala de reuni?o perto da Paulista. >>>>> >>>> >>>> >>>> Aquele CoWorking que tem em cima do metr? consola??o seria uma boa >>>> op??o, embora aquele outro l? da Augusta parece ser mais aberto a dar >>>> suporte a eventos da comunidade. >>>> >>>> Acho que estou falando de um chamado Link2U e outro chamado, ah, >>>> esqueci, mas ? um dos mais antigos coworkings de S?o Paulo e fica perto da >>>> Nefertite :p >>>> >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =end disclaimer >>>> >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > From shonorio at gmail.com Wed Feb 4 01:00:01 2015 From: shonorio at gmail.com (Solli Honorio) Date: Wed, 4 Feb 2015 07:00:01 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= Message-ID: Para quem deseja transformar o c?digo em um quadro !!! https://commits.io/# -- "o animal satisfeito dorme". - Guimar?es Rosa -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From kleber.carvalho at gmail.com Wed Feb 4 08:05:03 2015 From: kleber.carvalho at gmail.com (Kleber Rodrigo de Carvalho) Date: Wed, 4 Feb 2015 14:05:03 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE Message-ID: Pessoal, Estou escrevendo um programa em Perl, e preciso entender as diferen?as entre os FILEHANDLE. Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta diferente de um usando INFILE. Estou procurando na internet por: perl FILEHANDLE LOGFILE INFILE perl LOGFILE INFILE Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? ajudaria. Ser? que algu?m poderia me ajudar nisso? Muito obrigado Abra?os Kleber Rodrigo de Carvalho Engenheiro de Software KleberCarvalho.com | (15) 9-9161-3362 From gabriel.vieira at gmail.com Wed Feb 4 08:07:17 2015 From: gabriel.vieira at gmail.com (Gabriel Vieira) Date: Wed, 4 Feb 2015 11:07:17 -0500 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Qual a diferen?a de comportamento que voc? observou? 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < kleber.carvalho at gmail.com>: > Pessoal, > > Estou escrevendo um programa em Perl, e preciso entender as > diferen?as entre os FILEHANDLE. > Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta > diferente de um usando INFILE. > Estou procurando na internet por: > > perl FILEHANDLE LOGFILE INFILE > perl LOGFILE INFILE > > Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? > ajudaria. > Ser? que algu?m poderia me ajudar nisso? > > Muito obrigado > > Abra?os > Kleber Rodrigo de Carvalho > Engenheiro de Software > KleberCarvalho.com | (15) 9-9161-3362 > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- Gabriel Vieira -------------- Pr?xima Parte ---------- Um anexo em HTML foi limpo... URL: From renato.cron at gmail.com Wed Feb 4 08:15:15 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 4 Feb 2015 14:15:15 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Cara, estou achando que voc? est? lendo um programa j? feito, que esta usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) O jeito mais seguro, ? usar um FH dentro de uma ref, # ler em binario open(my $fh, '<:raw', '/tmp/foo.bin'); while( my $somebytes = <$fh>){ . .. } # ler em utf8 open(my $fh, '<:utf8', '/tmp/tmp.utf8'); while( my $line = <$fh>){ . .. } # escrever em utf8 open(my $fh, '>:utf8', '/tmp/tmp.utf8'); print $fh "uma linha\n"; 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > Qual a diferen?a de comportamento que voc? observou? > > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < > kleber.carvalho at gmail.com>: > > Pessoal, >> >> Estou escrevendo um programa em Perl, e preciso entender as >> diferen?as entre os FILEHANDLE. >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >> diferente de um usando INFILE. >> Estou procurando na internet por: >> >> perl FILEHANDLE LOGFILE INFILE >> perl LOGFILE INFILE >> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >> ajudaria. >> Ser? que algu?m poderia me ajudar nisso? >> >> Muito obrigado >> >> Abra?os >> Kleber Rodrigo de Carvalho >> Engenheiro de Software >> KleberCarvalho.com | (15) 9-9161-3362 >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> > > > > -- > Gabriel Vieira > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From kleber.carvalho at gmail.com Wed Feb 4 09:01:04 2015 From: kleber.carvalho at gmail.com (Kleber Rodrigo de Carvalho) Date: Wed, 4 Feb 2015 15:01:04 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE Message-ID: Ol? Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n Minha duvida ?: seek($filehandler, 0, 2); $curreof = tell($filehandler); print("curreof=" . $curreof . "\n"); Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, eu recebo curreof=56666091 O que isso significar? Obrigado Abra?os Kleber Rodrigo de Carvalho Engenheiro de Software KleberCarvalho.com | (15) 9-9161-3362 Cara, estou achando que voc? est? lendo um programa j? feito, que esta usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) O jeito mais seguro, ? usar um FH dentro de uma ref, # ler em binario open(my $fh, '<:raw', '/tmp/foo.bin'); while( my $somebytes = <$fh>){ . .. } # ler em utf8 open(my $fh, '<:utf8', '/tmp/tmp.utf8'); while( my $line = <$fh>){ . .. } # escrever em utf8 open(my $fh, '>:utf8', '/tmp/tmp.utf8'); print $fh "uma linha\n"; 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : Cara, estou achando que voc? est? lendo um programa j? feito, que esta usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) O jeito mais seguro, ? usar um FH dentro de uma ref, # ler em binario open(my $fh, '<:raw', '/tmp/foo.bin'); while( my $somebytes = <$fh>){ . .. } # ler em utf8 open(my $fh, '<:utf8', '/tmp/tmp.utf8'); while( my $line = <$fh>){ . .. } # escrever em utf8 open(my $fh, '>:utf8', '/tmp/tmp.utf8'); print $fh "uma linha\n"; 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > Qual a diferen?a de comportamento que voc? observou? > > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < > kleber.carvalho at gmail.com>: > > Pessoal, >> >> Estou escrevendo um programa em Perl, e preciso entender as >> diferen?as entre os FILEHANDLE. >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >> diferente de um usando INFILE. >> Estou procurando na internet por: >> >> perl FILEHANDLE LOGFILE INFILE >> perl LOGFILE INFILE >> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >> ajudaria. >> Ser? que algu?m poderia me ajudar nisso? >> >> Muito obrigado >> >> Abra?os >> Kleber Rodrigo de Carvalho >> Engenheiro de Software >> KleberCarvalho.com | (15) 9-9161-3362 From renato.cron at gmail.com Wed Feb 4 09:10:11 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 4 Feb 2015 15:10:11 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: seu programa j? est? feito, alguem que criou esses nomes e filehandles. o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). o tell esta mandando retornar a posicao atual. signfica que o LOGFILE esta na posicao 56666091(bytes/char?) 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < kleber.carvalho at gmail.com>: > Ol? > > Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n > > > Minha duvida ?: > > seek($filehandler, 0, 2); > $curreof = tell($filehandler); > print("curreof=" . $curreof . "\n"); > > > Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, > eu recebo curreof=56666091 > O que isso significar? > > Obrigado > > Abra?os > Kleber Rodrigo de Carvalho > Engenheiro de Software > KleberCarvalho.com | (15) 9-9161-3362 > > Cara, estou achando que voc? est? lendo um programa j? feito, que esta > usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) > > O jeito mais seguro, ? usar um FH dentro de uma ref, > > # ler em binario > open(my $fh, '<:raw', '/tmp/foo.bin'); > while( my $somebytes = <$fh>){ . .. } > > # ler em utf8 > open(my $fh, '<:utf8', '/tmp/tmp.utf8'); > while( my $line = <$fh>){ . .. } > > # escrever em utf8 > open(my $fh, '>:utf8', '/tmp/tmp.utf8'); > print $fh "uma linha\n"; > > > > 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > > Cara, estou achando que voc? est? lendo um programa j? feito, que esta > usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) > > O jeito mais seguro, ? usar um FH dentro de uma ref, > > # ler em binario > open(my $fh, '<:raw', '/tmp/foo.bin'); > while( my $somebytes = <$fh>){ . .. } > > # ler em utf8 > open(my $fh, '<:utf8', '/tmp/tmp.utf8'); > while( my $line = <$fh>){ . .. } > > # escrever em utf8 > open(my $fh, '>:utf8', '/tmp/tmp.utf8'); > print $fh "uma linha\n"; > > > > 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > > > Qual a diferen?a de comportamento que voc? observou? > > > > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < > > kleber.carvalho at gmail.com>: > > > > Pessoal, > >> > >> Estou escrevendo um programa em Perl, e preciso entender as > >> diferen?as entre os FILEHANDLE. > >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta > >> diferente de um usando INFILE. > >> Estou procurando na internet por: > >> > >> perl FILEHANDLE LOGFILE INFILE > >> perl LOGFILE INFILE > >> > >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? > >> ajudaria. > >> Ser? que algu?m poderia me ajudar nisso? > >> > >> Muito obrigado > >> > >> Abra?os > >> Kleber Rodrigo de Carvalho > >> Engenheiro de Software > >> KleberCarvalho.com | (15) 9-9161-3362 > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Wed Feb 4 09:10:11 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 4 Feb 2015 15:10:11 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: seu programa j? est? feito, alguem que criou esses nomes e filehandles. o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). o tell esta mandando retornar a posicao atual. signfica que o LOGFILE esta na posicao 56666091(bytes/char?) 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < kleber.carvalho at gmail.com>: > Ol? > > Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n > > > Minha duvida ?: > > seek($filehandler, 0, 2); > $curreof = tell($filehandler); > print("curreof=" . $curreof . "\n"); > > > Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, > eu recebo curreof=56666091 > O que isso significar? > > Obrigado > > Abra?os > Kleber Rodrigo de Carvalho > Engenheiro de Software > KleberCarvalho.com | (15) 9-9161-3362 > > Cara, estou achando que voc? est? lendo um programa j? feito, que esta > usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) > > O jeito mais seguro, ? usar um FH dentro de uma ref, > > # ler em binario > open(my $fh, '<:raw', '/tmp/foo.bin'); > while( my $somebytes = <$fh>){ . .. } > > # ler em utf8 > open(my $fh, '<:utf8', '/tmp/tmp.utf8'); > while( my $line = <$fh>){ . .. } > > # escrever em utf8 > open(my $fh, '>:utf8', '/tmp/tmp.utf8'); > print $fh "uma linha\n"; > > > > 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > > Cara, estou achando que voc? est? lendo um programa j? feito, que esta > usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) > > O jeito mais seguro, ? usar um FH dentro de uma ref, > > # ler em binario > open(my $fh, '<:raw', '/tmp/foo.bin'); > while( my $somebytes = <$fh>){ . .. } > > # ler em utf8 > open(my $fh, '<:utf8', '/tmp/tmp.utf8'); > while( my $line = <$fh>){ . .. } > > # escrever em utf8 > open(my $fh, '>:utf8', '/tmp/tmp.utf8'); > print $fh "uma linha\n"; > > > > 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > > > Qual a diferen?a de comportamento que voc? observou? > > > > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < > > kleber.carvalho at gmail.com>: > > > > Pessoal, > >> > >> Estou escrevendo um programa em Perl, e preciso entender as > >> diferen?as entre os FILEHANDLE. > >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta > >> diferente de um usando INFILE. > >> Estou procurando na internet por: > >> > >> perl FILEHANDLE LOGFILE INFILE > >> perl LOGFILE INFILE > >> > >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? > >> ajudaria. > >> Ser? que algu?m poderia me ajudar nisso? > >> > >> Muito obrigado > >> > >> Abra?os > >> Kleber Rodrigo de Carvalho > >> Engenheiro de Software > >> KleberCarvalho.com | (15) 9-9161-3362 > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.vinciguerra at gmail.com Wed Feb 4 09:22:35 2015 From: dan.vinciguerra at gmail.com (Daniel Vinciguerra) Date: Wed, 4 Feb 2015 15:22:35 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Voc? pode entender mais sobre o open ou a manipula??o de arquivos atrav?s dos manuais: $ perldoc -f open $ perldoc perlopentut S? pra tentar explicar melhor.... Segundo a primeira referencia citada acima, Perl possuis as seguintes formas de se abrir um arquivo: open FILEHANDLE,EXPR open FILEHANDLE,MODE,EXPR open FILEHANDLE,MODE,EXPR,LIST open FILEHANDLE,MODE,REFERENCE open FILEHANDLE Onde: FILEHANDLE = vari?vel referente a opera??o MODE = forma de manipula??o (escrita, leitura, leitura e escrita) EXPR = nome do arquivo E onde as formas de utiliza??o mais comumente encontradas s?o: open(FH, '< arquivo/para/leitura.txt') or die "..."; Que poderia ser melhor escrita desta forma... open my $fh, '<', 'arquivo/para/leitura.txt' or die "..."; Os FILEHANDLE, LOGFILE e INFILE a que voc? se refere s?o apenas nomes de v?ri?veis que, assim como o cron, eu sugiro que mude para utilizar como referencias usando $scalares. O que determina como cada um ir? se comportar ? o MODE que pode ser encontrado nas formas mais comuns como: '<' para leitura '>' para escrita (sobre escreve caso arquivo exista) '>>' para escrita (adiciona ao final do arquivo caso ele exista) Obs.: A supress?o deste indica a abertura do arquivo pra leitura. E ? isso!! Para concluir, 1. seu filehandle poderia se chamar at? KLEBERRODRIGOEHOCARA que seria um filehandle valido! ;) 2. leia as referencias no come?o do e-mail 3. se tiver mais alguma duvida poste um peda?o do seu c?digo pra ajudar o pessoal a te ajudar Grande abra?o, (se eu esqueci de algo algu?m me ajuda ou me puxe a orelha) ;P *Daniel Vinciguerra (@dvinciguerra)* Web solution architect, perl dev, vegetarian, geek and co-founder at *Bivee* bivee.com.br - github.com/Bivee 2015-02-04 14:15 GMT-02:00 Renato Santos : > Cara, estou achando que voc? est? lendo um programa j? feito, que esta > usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) > > O jeito mais seguro, ? usar um FH dentro de uma ref, > > # ler em binario > open(my $fh, '<:raw', '/tmp/foo.bin'); > while( my $somebytes = <$fh>){ . .. } > > # ler em utf8 > open(my $fh, '<:utf8', '/tmp/tmp.utf8'); > while( my $line = <$fh>){ . .. } > > # escrever em utf8 > open(my $fh, '>:utf8', '/tmp/tmp.utf8'); > print $fh "uma linha\n"; > > > > 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : > > Qual a diferen?a de comportamento que voc? observou? >> >> 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >> kleber.carvalho at gmail.com>: >> >> Pessoal, >>> >>> Estou escrevendo um programa em Perl, e preciso entender as >>> diferen?as entre os FILEHANDLE. >>> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >>> diferente de um usando INFILE. >>> Estou procurando na internet por: >>> >>> perl FILEHANDLE LOGFILE INFILE >>> perl LOGFILE INFILE >>> >>> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >>> ajudaria. >>> Ser? que algu?m poderia me ajudar nisso? >>> >>> Muito obrigado >>> >>> Abra?os >>> Kleber Rodrigo de Carvalho >>> Engenheiro de Software >>> KleberCarvalho.com | (15) 9-9161-3362 >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >> >> >> >> -- >> Gabriel Vieira >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.oliveira.mantovani at gmail.com Wed Feb 4 09:41:02 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Wed, 4 Feb 2015 15:41:02 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Depois de muito esfor?o consegui entender a sua pergunta. Voc? est? dizendo que ? diferente tratar um arquivo f?sico na m?quina ex, /etc/passwd da entrada padr?o de arquivos STDIN. Mas na verdade n?o ? bem assim, programa1: open my $filehandle, ,'<',STDIN or die $!; programa2: open my $filehandle,'<','/etc/password' or die $!; programa3: my @lines = ; #my @lines = <> - Mesma coisa $perl programa1 < arquivo.txt $cat /foo/*.txt|perl programa1 $perl programa2.pl $perl programa3 < arquivo.txt $cat /foo/*.txt|perl programa3 http://perldoc.perl.org/perlopentut.html 2015-02-04 14:05 GMT-02:00 Kleber Rodrigo de Carvalho < kleber.carvalho at gmail.com>: > Pessoal, > > Estou escrevendo um programa em Perl, e preciso entender as > diferen?as entre os FILEHANDLE. > Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta > diferente de um usando INFILE. > Estou procurando na internet por: > > perl FILEHANDLE LOGFILE INFILE > perl LOGFILE INFILE > > Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? > ajudaria. > Ser? que algu?m poderia me ajudar nisso? > > Muito obrigado > > Abra?os > Kleber Rodrigo de Carvalho > Engenheiro de Software > KleberCarvalho.com | (15) 9-9161-3362 > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.oliveira.mantovani at gmail.com Wed Feb 4 09:45:36 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Wed, 4 Feb 2015 15:45:36 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Kleber, tem um livro chamado Advanced Programming In the Unix Environment. Eu recomendo voc? ler o cap?tulo 3 - File I/O a sua d?vida n?o tem a ver com Perl e sim com conceitos de O.S. 2015-02-04 15:10 GMT-02:00 Renato Santos : > seu programa j? est? feito, alguem que criou esses nomes e filehandles. > > o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). > o tell esta mandando retornar a posicao atual. > > signfica que o LOGFILE esta na posicao 56666091(bytes/char?) > > 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < > kleber.carvalho at gmail.com>: > > Ol? >> >> Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n >> >> >> Minha duvida ?: >> >> seek($filehandler, 0, 2); >> $curreof = tell($filehandler); >> print("curreof=" . $curreof . "\n"); >> >> >> Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, >> eu recebo curreof=56666091 >> O que isso significar? >> >> Obrigado >> >> Abra?os >> Kleber Rodrigo de Carvalho >> Engenheiro de Software >> KleberCarvalho.com | (15) 9-9161-3362 >> >> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >> >> O jeito mais seguro, ? usar um FH dentro de uma ref, >> >> # ler em binario >> open(my $fh, '<:raw', '/tmp/foo.bin'); >> while( my $somebytes = <$fh>){ . .. } >> >> # ler em utf8 >> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >> while( my $line = <$fh>){ . .. } >> >> # escrever em utf8 >> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >> print $fh "uma linha\n"; >> >> >> >> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >> >> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >> >> O jeito mais seguro, ? usar um FH dentro de uma ref, >> >> # ler em binario >> open(my $fh, '<:raw', '/tmp/foo.bin'); >> while( my $somebytes = <$fh>){ . .. } >> >> # ler em utf8 >> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >> while( my $line = <$fh>){ . .. } >> >> # escrever em utf8 >> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >> print $fh "uma linha\n"; >> >> >> >> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >> >> > Qual a diferen?a de comportamento que voc? observou? >> > >> > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >> > kleber.carvalho at gmail.com>: >> > >> > Pessoal, >> >> >> >> Estou escrevendo um programa em Perl, e preciso entender as >> >> diferen?as entre os FILEHANDLE. >> >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >> >> diferente de um usando INFILE. >> >> Estou procurando na internet por: >> >> >> >> perl FILEHANDLE LOGFILE INFILE >> >> perl LOGFILE INFILE >> >> >> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >> >> ajudaria. >> >> Ser? que algu?m poderia me ajudar nisso? >> >> >> >> Muito obrigado >> >> >> >> Abra?os >> >> Kleber Rodrigo de Carvalho >> >> Engenheiro de Software >> >> KleberCarvalho.com | (15) 9-9161-3362 >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.oliveira.mantovani at gmail.com Wed Feb 4 09:45:36 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Wed, 4 Feb 2015 15:45:36 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Kleber, tem um livro chamado Advanced Programming In the Unix Environment. Eu recomendo voc? ler o cap?tulo 3 - File I/O a sua d?vida n?o tem a ver com Perl e sim com conceitos de O.S. 2015-02-04 15:10 GMT-02:00 Renato Santos : > seu programa j? est? feito, alguem que criou esses nomes e filehandles. > > o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). > o tell esta mandando retornar a posicao atual. > > signfica que o LOGFILE esta na posicao 56666091(bytes/char?) > > 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < > kleber.carvalho at gmail.com>: > > Ol? >> >> Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n >> >> >> Minha duvida ?: >> >> seek($filehandler, 0, 2); >> $curreof = tell($filehandler); >> print("curreof=" . $curreof . "\n"); >> >> >> Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, >> eu recebo curreof=56666091 >> O que isso significar? >> >> Obrigado >> >> Abra?os >> Kleber Rodrigo de Carvalho >> Engenheiro de Software >> KleberCarvalho.com | (15) 9-9161-3362 >> >> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >> >> O jeito mais seguro, ? usar um FH dentro de uma ref, >> >> # ler em binario >> open(my $fh, '<:raw', '/tmp/foo.bin'); >> while( my $somebytes = <$fh>){ . .. } >> >> # ler em utf8 >> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >> while( my $line = <$fh>){ . .. } >> >> # escrever em utf8 >> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >> print $fh "uma linha\n"; >> >> >> >> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >> >> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >> >> O jeito mais seguro, ? usar um FH dentro de uma ref, >> >> # ler em binario >> open(my $fh, '<:raw', '/tmp/foo.bin'); >> while( my $somebytes = <$fh>){ . .. } >> >> # ler em utf8 >> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >> while( my $line = <$fh>){ . .. } >> >> # escrever em utf8 >> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >> print $fh "uma linha\n"; >> >> >> >> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >> >> > Qual a diferen?a de comportamento que voc? observou? >> > >> > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >> > kleber.carvalho at gmail.com>: >> > >> > Pessoal, >> >> >> >> Estou escrevendo um programa em Perl, e preciso entender as >> >> diferen?as entre os FILEHANDLE. >> >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >> >> diferente de um usando INFILE. >> >> Estou procurando na internet por: >> >> >> >> perl FILEHANDLE LOGFILE INFILE >> >> perl LOGFILE INFILE >> >> >> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >> >> ajudaria. >> >> Ser? que algu?m poderia me ajudar nisso? >> >> >> >> Muito obrigado >> >> >> >> Abra?os >> >> Kleber Rodrigo de Carvalho >> >> Engenheiro de Software >> >> KleberCarvalho.com | (15) 9-9161-3362 >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.oliveira.mantovani at gmail.com Wed Feb 4 09:51:14 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Wed, 4 Feb 2015 15:51:14 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: BTW, voc? est? lendo o arquivo de log do WebSphere Application Server, SystemOut.log mesmo que voc? consiga implementar o "tail" que voc? est? tentando implementar, voc? vai ter problemas pois o WebSphere Application Server "rotate" o arquivo, sendo assim o seu programa vai perder o ID do descritor de arquivos e vai parar de funcionar. Para resolver o problema, al?m de voc? implementar o seu "tail", voc? precisa ficar verificando se o ID do SystemOut.log mudou. ? f?cil de implementar e voc? vai aprender v?rios conceitos de Unix-like do caminho, estamos aqui para ajudar. 2015-02-04 15:45 GMT-02:00 Daniel de Oliveira Mantovani < daniel.oliveira.mantovani at gmail.com>: > Kleber, tem um livro chamado Advanced Programming In the Unix Environment. > Eu recomendo voc? ler o cap?tulo 3 - File I/O a sua d?vida n?o tem a ver > com Perl e sim com conceitos de O.S. > > 2015-02-04 15:10 GMT-02:00 Renato Santos : > > seu programa j? est? feito, alguem que criou esses nomes e filehandles. >> >> o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). >> o tell esta mandando retornar a posicao atual. >> >> signfica que o LOGFILE esta na posicao 56666091(bytes/char?) >> >> 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < >> kleber.carvalho at gmail.com>: >> >> Ol? >>> >>> Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n >>> >>> >>> Minha duvida ?: >>> >>> seek($filehandler, 0, 2); >>> $curreof = tell($filehandler); >>> print("curreof=" . $curreof . "\n"); >>> >>> >>> Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, >>> eu recebo curreof=56666091 >>> O que isso significar? >>> >>> Obrigado >>> >>> Abra?os >>> Kleber Rodrigo de Carvalho >>> Engenheiro de Software >>> KleberCarvalho.com | (15) 9-9161-3362 >>> >>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>> >>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>> >>> # ler em binario >>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>> while( my $somebytes = <$fh>){ . .. } >>> >>> # ler em utf8 >>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>> while( my $line = <$fh>){ . .. } >>> >>> # escrever em utf8 >>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>> print $fh "uma linha\n"; >>> >>> >>> >>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>> >>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>> >>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>> >>> # ler em binario >>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>> while( my $somebytes = <$fh>){ . .. } >>> >>> # ler em utf8 >>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>> while( my $line = <$fh>){ . .. } >>> >>> # escrever em utf8 >>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>> print $fh "uma linha\n"; >>> >>> >>> >>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>> >>> > Qual a diferen?a de comportamento que voc? observou? >>> > >>> > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >>> > kleber.carvalho at gmail.com>: >>> > >>> > Pessoal, >>> >> >>> >> Estou escrevendo um programa em Perl, e preciso entender as >>> >> diferen?as entre os FILEHANDLE. >>> >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >>> >> diferente de um usando INFILE. >>> >> Estou procurando na internet por: >>> >> >>> >> perl FILEHANDLE LOGFILE INFILE >>> >> perl LOGFILE INFILE >>> >> >>> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >>> >> ajudaria. >>> >> Ser? que algu?m poderia me ajudar nisso? >>> >> >>> >> Muito obrigado >>> >> >>> >> Abra?os >>> >> Kleber Rodrigo de Carvalho >>> >> Engenheiro de Software >>> >> KleberCarvalho.com | (15) 9-9161-3362 >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > > -- > > -dom > > -- > > Daniel de Oliveira Mantovani > Business Analytic Specialist > Perl Evangelist /Astrophysics hobbyist. > +55 11 9 8538-9897 > XOXO > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.oliveira.mantovani at gmail.com Wed Feb 4 09:51:14 2015 From: daniel.oliveira.mantovani at gmail.com (Daniel de Oliveira Mantovani) Date: Wed, 4 Feb 2015 15:51:14 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: BTW, voc? est? lendo o arquivo de log do WebSphere Application Server, SystemOut.log mesmo que voc? consiga implementar o "tail" que voc? est? tentando implementar, voc? vai ter problemas pois o WebSphere Application Server "rotate" o arquivo, sendo assim o seu programa vai perder o ID do descritor de arquivos e vai parar de funcionar. Para resolver o problema, al?m de voc? implementar o seu "tail", voc? precisa ficar verificando se o ID do SystemOut.log mudou. ? f?cil de implementar e voc? vai aprender v?rios conceitos de Unix-like do caminho, estamos aqui para ajudar. 2015-02-04 15:45 GMT-02:00 Daniel de Oliveira Mantovani < daniel.oliveira.mantovani at gmail.com>: > Kleber, tem um livro chamado Advanced Programming In the Unix Environment. > Eu recomendo voc? ler o cap?tulo 3 - File I/O a sua d?vida n?o tem a ver > com Perl e sim com conceitos de O.S. > > 2015-02-04 15:10 GMT-02:00 Renato Santos : > > seu programa j? est? feito, alguem que criou esses nomes e filehandles. >> >> o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). >> o tell esta mandando retornar a posicao atual. >> >> signfica que o LOGFILE esta na posicao 56666091(bytes/char?) >> >> 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho < >> kleber.carvalho at gmail.com>: >> >> Ol? >>> >>> Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n >>> >>> >>> Minha duvida ?: >>> >>> seek($filehandler, 0, 2); >>> $curreof = tell($filehandler); >>> print("curreof=" . $curreof . "\n"); >>> >>> >>> Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, >>> eu recebo curreof=56666091 >>> O que isso significar? >>> >>> Obrigado >>> >>> Abra?os >>> Kleber Rodrigo de Carvalho >>> Engenheiro de Software >>> KleberCarvalho.com | (15) 9-9161-3362 >>> >>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>> >>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>> >>> # ler em binario >>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>> while( my $somebytes = <$fh>){ . .. } >>> >>> # ler em utf8 >>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>> while( my $line = <$fh>){ . .. } >>> >>> # escrever em utf8 >>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>> print $fh "uma linha\n"; >>> >>> >>> >>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>> >>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>> >>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>> >>> # ler em binario >>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>> while( my $somebytes = <$fh>){ . .. } >>> >>> # ler em utf8 >>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>> while( my $line = <$fh>){ . .. } >>> >>> # escrever em utf8 >>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>> print $fh "uma linha\n"; >>> >>> >>> >>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>> >>> > Qual a diferen?a de comportamento que voc? observou? >>> > >>> > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >>> > kleber.carvalho at gmail.com>: >>> > >>> > Pessoal, >>> >> >>> >> Estou escrevendo um programa em Perl, e preciso entender as >>> >> diferen?as entre os FILEHANDLE. >>> >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >>> >> diferente de um usando INFILE. >>> >> Estou procurando na internet por: >>> >> >>> >> perl FILEHANDLE LOGFILE INFILE >>> >> perl LOGFILE INFILE >>> >> >>> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >>> >> ajudaria. >>> >> Ser? que algu?m poderia me ajudar nisso? >>> >> >>> >> Muito obrigado >>> >> >>> >> Abra?os >>> >> Kleber Rodrigo de Carvalho >>> >> Engenheiro de Software >>> >> KleberCarvalho.com | (15) 9-9161-3362 >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =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 at pm.org >> L >> =end disclaimer >> >> > > > -- > > -dom > > -- > > Daniel de Oliveira Mantovani > Business Analytic Specialist > Perl Evangelist /Astrophysics hobbyist. > +55 11 9 8538-9897 > XOXO > -- -dom -- Daniel de Oliveira Mantovani Business Analytic Specialist Perl Evangelist /Astrophysics hobbyist. +55 11 9 8538-9897 XOXO -------------- next part -------------- An HTML attachment was scrubbed... URL: From kleber.carvalho at gmail.com Wed Feb 4 11:44:19 2015 From: kleber.carvalho at gmail.com (Kleber Rodrigo de Carvalho) Date: Wed, 4 Feb 2015 17:44:19 -0200 Subject: [SP-pm] FILEHANDLE LOGFILE or INFILE In-Reply-To: References: Message-ID: Pessoal, Muito obrigado pela ajuda. Eu estava com 2 d?vidas. 1) LOGFILE or INFILE Achei LOGFILE or INFILE eram tipos de filehandle para leitura e escrita de arquivo. Me desculpe, descrobri que s?o apenas nomes de v?rias. 2) > Minha duvida ?: > seek($filehandler, 0, 2); > $curreof = tell($filehandler); > print("curreof=" . $curreof . "\n"); > Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, eu recebo curreof=56666091 Descobri que esse 56666091 (Gabriel, Renato, Daniel Vinciguerra e Daniel ) na verdade ? o tamanho do arquivo em bytes/caracteres. Muito obrigado a todos pela ajuda. Abra?os Kleber Rodrigo de Carvalho Engenheiro de Software KleberCarvalho.com | (15) 9-9161-3362 2015-02-04 15:51 GMT-02:00 Daniel de Oliveira Mantovani : > BTW, voc? est? lendo o arquivo de log do WebSphere Application Server, > SystemOut.log mesmo que voc? consiga implementar o "tail" que voc? est? > tentando implementar, voc? vai ter problemas pois o WebSphere Application > Server "rotate" o arquivo, sendo assim o seu programa vai perder o ID do > descritor de arquivos e vai parar de funcionar. Para resolver o problema, > al?m de voc? implementar o seu "tail", voc? precisa ficar verificando se o > ID do SystemOut.log mudou. ? f?cil de implementar e voc? vai aprender v?rios > conceitos de Unix-like do caminho, estamos aqui para ajudar. > > 2015-02-04 15:45 GMT-02:00 Daniel de Oliveira Mantovani > : > >> Kleber, tem um livro chamado Advanced Programming In the Unix Environment. >> Eu recomendo voc? ler o cap?tulo 3 - File I/O a sua d?vida n?o tem a ver com >> Perl e sim com conceitos de O.S. >> >> 2015-02-04 15:10 GMT-02:00 Renato Santos : >> >>> seu programa j? est? feito, alguem que criou esses nomes e filehandles. >>> >>> o seek esta mandando ir para a ultima posicao (3 parametro com valor 2). >>> o tell esta mandando retornar a posicao atual. >>> >>> signfica que o LOGFILE esta na posicao 56666091(bytes/char?) >>> >>> 2015-02-04 15:01 GMT-02:00 Kleber Rodrigo de Carvalho >>> : >>> >>>> Ol? >>>> >>>> Disponibilizei meu c?digo aqui: http://pastebin.com/T6AGHm2n >>>> >>>> >>>> Minha duvida ?: >>>> >>>> seek($filehandler, 0, 2); >>>> $curreof = tell($filehandler); >>>> print("curreof=" . $curreof . "\n"); >>>> >>>> >>>> Porque quando eu executo esse trecho de c?digo acima usando LOGFILE, >>>> eu recebo curreof=56666091 >>>> O que isso significar? >>>> >>>> Obrigado >>>> >>>> Abra?os >>>> Kleber Rodrigo de Carvalho >>>> Engenheiro de Software >>>> KleberCarvalho.com | (15) 9-9161-3362 >>>> >>>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>>> >>>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>>> >>>> # ler em binario >>>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>>> while( my $somebytes = <$fh>){ . .. } >>>> >>>> # ler em utf8 >>>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>>> while( my $line = <$fh>){ . .. } >>>> >>>> # escrever em utf8 >>>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>>> print $fh "uma linha\n"; >>>> >>>> >>>> >>>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>>> >>>> Cara, estou achando que voc? est? lendo um programa j? feito, que esta >>>> usando *FILEHANDLE* em si, com esses nomes (LOGFILE, INLINE) >>>> >>>> O jeito mais seguro, ? usar um FH dentro de uma ref, >>>> >>>> # ler em binario >>>> open(my $fh, '<:raw', '/tmp/foo.bin'); >>>> while( my $somebytes = <$fh>){ . .. } >>>> >>>> # ler em utf8 >>>> open(my $fh, '<:utf8', '/tmp/tmp.utf8'); >>>> while( my $line = <$fh>){ . .. } >>>> >>>> # escrever em utf8 >>>> open(my $fh, '>:utf8', '/tmp/tmp.utf8'); >>>> print $fh "uma linha\n"; >>>> >>>> >>>> >>>> 2015-02-04 14:07 GMT-02:00 Gabriel Vieira : >>>> >>>> > Qual a diferen?a de comportamento que voc? observou? >>>> > >>>> > 2015-02-04 11:05 GMT-05:00 Kleber Rodrigo de Carvalho < >>>> > kleber.carvalho at gmail.com>: >>>> > >>>> > Pessoal, >>>> >> >>>> >> Estou escrevendo um programa em Perl, e preciso entender as >>>> >> diferen?as entre os FILEHANDLE. >>>> >> Por exemplo, um programa lendo um arquivo usando LOGFILE se comporta >>>> >> diferente de um usando INFILE. >>>> >> Estou procurando na internet por: >>>> >> >>>> >> perl FILEHANDLE LOGFILE INFILE >>>> >> perl LOGFILE INFILE >>>> >> >>>> >> Mas n?o encontrei nada. Se encontra todos os tipos de FILEHANDLE j? >>>> >> ajudaria. >>>> >> Ser? que algu?m poderia me ajudar nisso? >>>> >> >>>> >> Muito obrigado >>>> >> >>>> >> Abra?os >>>> >> Kleber Rodrigo de Carvalho >>>> >> Engenheiro de Software >>>> >> KleberCarvalho.com | (15) 9-9161-3362 >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>>> L >>>> =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 at pm.org >>> L >>> =end disclaimer >>> >> >> >> >> -- >> >> -dom >> >> -- >> >> Daniel de Oliveira Mantovani >> Business Analytic Specialist >> Perl Evangelist /Astrophysics hobbyist. >> +55 11 9 8538-9897 >> XOXO > > > > > -- > > -dom > > -- > > Daniel de Oliveira Mantovani > Business Analytic Specialist > Perl Evangelist /Astrophysics hobbyist. > +55 11 9 8538-9897 > XOXO > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > From contato at erikhenrique.com.br Wed Feb 4 12:24:05 2015 From: contato at erikhenrique.com.br (Erik Henrique) Date: Wed, 4 Feb 2015 18:24:05 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= In-Reply-To: References: Message-ID: mais um: http://instacod.es/ Em 4 de fevereiro de 2015 07:00, Solli Honorio escreveu: > Para quem deseja transformar o c?digo em um quadro !!! > > https://commits.io/# > > -- > "o animal satisfeito dorme". - Guimar?es Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Erik Henrique -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Wed Feb 4 12:26:44 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 4 Feb 2015 18:26:44 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= In-Reply-To: References: Message-ID: pow nao tem sintaxy higlight! 2015-02-04 18:24 GMT-02:00 Erik Henrique : > mais um: > > > http://instacod.es/ > > Em 4 de fevereiro de 2015 07:00, Solli Honorio > escreveu: > >> Para quem deseja transformar o c?digo em um quadro !!! >> >> https://commits.io/# >> >> -- >> "o animal satisfeito dorme". - Guimar?es Rosa >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > > > -- > Erik Henrique > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From renato.cron at gmail.com Wed Feb 4 12:30:14 2015 From: renato.cron at gmail.com (Renato Santos) Date: Wed, 4 Feb 2015 18:30:14 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= In-Reply-To: References: Message-ID: Gostei mais do instacod! http://i.imgur.com/QUEgnB6.png 2015-02-04 18:26 GMT-02:00 Renato Santos : > pow nao tem sintaxy higlight! > > 2015-02-04 18:24 GMT-02:00 Erik Henrique : > > mais um: >> >> >> http://instacod.es/ >> >> Em 4 de fevereiro de 2015 07:00, Solli Honorio >> escreveu: >> >>> Para quem deseja transformar o c?digo em um quadro !!! >>> >>> https://commits.io/# >>> >>> -- >>> "o animal satisfeito dorme". - Guimar?es Rosa >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >>> >> >> >> -- >> Erik Henrique >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =end disclaimer >> >> > > > -- > Sarav?, > Renato CRON > http://www.renatocron.com/blog/ > @renato_cron > -- Sarav?, Renato CRON http://www.renatocron.com/blog/ @renato_cron -------------- next part -------------- An HTML attachment was scrubbed... URL: From blabos at gmail.com Wed Feb 4 12:31:10 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Wed, 4 Feb 2015 18:31:10 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= In-Reply-To: References: Message-ID: Putz, Postei um c?digo mas ele n?o funcionou porque precisava ter pelo menos 10 linhas... 2015-02-04 18:26 GMT-02:00 Renato Santos : > pow nao tem sintaxy higlight! > > 2015-02-04 18:24 GMT-02:00 Erik Henrique : > >> mais um: >> >> >> http://instacod.es/ >> >> Em 4 de fevereiro de 2015 07:00, Solli Honorio >> escreveu: >>> >>> Para quem deseja transformar o c?digo em um quadro !!! >>> >>> https://commits.io/# >>> >>> -- >>> "o animal satisfeito dorme". - Guimar?es Rosa >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >>> L >>> =end disclaimer >>> >> >> >> >> -- >> Erik Henrique >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org >> L >> =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 at pm.org > L > =end disclaimer > From contato at erikhenrique.com.br Wed Feb 4 12:48:19 2015 From: contato at erikhenrique.com.br (Erik Henrique) Date: Wed, 4 Feb 2015 18:48:19 -0200 Subject: [SP-pm] =?utf-8?q?Seu_c=C3=B3digo_uma_obra_prima=2C_SQN?= In-Reply-To: References: Message-ID: 1 2 3 4 5 say "hello" 6 say "good bye" 7 8 9 10 ? Em 4 de fevereiro de 2015 18:31, Blabos de Blebe escreveu: > Putz, > > Postei um c?digo mas ele n?o funcionou porque precisava ter pelo menos > 10 linhas... > > 2015-02-04 18:26 GMT-02:00 Renato Santos : > > pow nao tem sintaxy higlight! > > > > 2015-02-04 18:24 GMT-02:00 Erik Henrique : > > > >> mais um: > >> > >> > >> http://instacod.es/ > >> > >> Em 4 de fevereiro de 2015 07:00, Solli Honorio > >> escreveu: > >>> > >>> Para quem deseja transformar o c?digo em um quadro !!! > >>> > >>> https://commits.io/# > >>> > >>> -- > >>> "o animal satisfeito dorme". - Guimar?es Rosa > >>> > >>> =begin disclaimer > >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >>> L > >>> =end disclaimer > >>> > >> > >> > >> > >> -- > >> Erik Henrique > >> > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > >> L > >> =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 at pm.org > > L > > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org > L > =end disclaimer > -- Erik Henrique -------------- next part -------------- An HTML attachment was scrubbed... URL: From blabos at gmail.com Thu Feb 5 03:01:12 2015 From: blabos at gmail.com (Blabos de Blebe) Date: Thu, 5 Feb 2015 09:01:12 -0200 Subject: [SP-pm] SEO e Javascript Message-ID: Opa, Sempre h? controv?rsias e ? isso que faz dessa comunidade interessante. Eu ficaria tecnologicamente bem atrasado se n?o fossem essas discuss?es. Sobre SEO, atualmente estou trabalhando em uma aplica??o onde faz muito sentido usar AngularJS, mas o sucesso dela ? extremamente sens?vel a search engines. Tem esse texto que diz alguma coisa sobre como o Google indexa Javascript, CSS e Flash: http://googlewebmastercentral.blogspot.com.es/2014/05/understanding-web-pages-better.html Muito embora, como apontado pelo Lucas, h? casos de grande escala onde "few potential issues" e "may negatively impact" realmente tem que ser considerados. 10% de 10 page views di?rios ? bem diferente de 10% de 10 milh?es de page views di?rios. Quanto ? utiliza??o da tag