<div dir="ltr">Em 1 de fevereiro de 2015 10:07, Blabos de Blebe <span dir="ltr"><<a href="mailto:blabos@gmail.com" target="_blank">blabos@gmail.com</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Gente vocês estão fazendo eu me sentir velho!<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A solução pra indexar aplicações em AngularJS existe desde 1999.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ninguém lembra dela porque ela foi criada "antes" do Google indexar<br>
páginas. Confesso que eu mesmo não me lembrava até pouco tempo atrás.<br>
Nunca usei. É genial de tão boba. KISS. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pago uma cerveja pra quem fizer o dever de casa (Ruoso, vc não).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">***<br>
<br>Se por um lado, o Ruoso parece um arrogante sabedor da verdade, por<br>
outro, pelo fato de cada um de nós já ter implementado com sucesso,<br>
aplicações que contrariam o que ele diz (eu me incluo), também somos<br>
resistentes a aceitar que a nossa solução é "errada". É errada mesmo?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Notem, certo e errado são palavras fortes e podem ser relativas.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Muitas vezes estamos lidando com constrains de negócio, como tempo por<br>
exemplo, motivo pelo qual nem sempre podemos ler a tese do fielding de<br>
ponta a ponta, o que também não é uma desculpa pra não buscar entender<br>
melhor as nossas escolhas.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Essa divergência toda acontece porque o HTTP é um protocolo tão<br>
simples e tão genial, que ele permite os mais variados usos, ou seja,<br>
há uma gama enorme de formas de usá-lo. Boas, ruins, mais ou menos,<br>
ótimas, etc.<br>
<br>
HTTP tem tudo a ver com Perl, há mais de uma forma de fazer, algumas<br>
melhores que as outras. Por que A é melhor que B? Bom, aí depende de<br>
um monte de fatores e entendê-los bem é (ou deveria ser) o foco dessa<br>
conversa.<br>
<br>
Não é porque eu vou estudar RESTful que eu vou ter que fazer tudo como<br>
o fielding diz, mas saber por que eu não estou fazendo me dá<br>
confiança.<br></blockquote><div><br></div><div>É 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Coisas que eu gostaria de discutir:<br>
<br>
1) RESTful é a solução pro meu problema? Ou um REST based é melhor?</blockquote><div><br></div><div>Eu tenho uma dificuldade grande co Restful e Rest. Temos de entender onde traçamos a fronteira. Isso é uma dúvida minha.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ou um levemente REST inspired?</blockquote><div><br></div><div>Considerando que o aspecto mais importante do Rest é o HyperDocument, o que consideramos Rest based vs o que é simplesmente JSON-RPC?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ou seria melhor fazer SOAP? Ou RPC binário? Por quê?<br></blockquote><div><br></div><div>RPC binário requer compatibilidade binária. </div><div><br></div><div>SOAP é uma especificação bastante madura, que permite manejar documentos e fazer RPC.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2) Existem várias formas de fazer autenticação. Qual a melhor pro meu<br>
caso? Por que a forma A é melhor que a B?<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3) Como eu versiono? Na URI? No header? Por quê?<br></blockquote><div><br></div><div>Eu entendo que ter a versão na URI é equivocada, exceto no caso da versão ser do objeto em si. </div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4) Como eu desacoplo os componentes? Eu preciso mesmo ter baixo acoplamento? Por quê?<br></blockquote><div><br></div><div>Rest engloba uma proposta madura para desacoplar componentes, mas SOAP também dispõe de soluções viáveis para isso. </div><div><br></div><div>Sempre que seu cliente dispuser de informações out-of-band específicas da aplicação ou do recurso você tem forte acoplamento.</div><div><br></div><div>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. </div><div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">5) E a performance? E o cache?<br></blockquote><div><br></div><div>Opa, performance e cache estão no amalgama das vantagens do Rest.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">6) Como faço upgrades? Como extendo? Como mantenho a compatibilidade?<br>
Preciso disso? Por quê?<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">7) Que outras perguntas eu deveria estar fazendo?<br></blockquote><div><br></div><div>Eu entendo que autorização é um problema bem mais complexo que autenticação, por exemplo.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eu gostaria muito de nos reunirmos pessoalmente, ao menos uma vez por<br>
semana, discutir o assunto, eventualmente implementar alguma coisa e<br>
depois a gente podia escrever a respeito. Pra esse equinócio? Talvez<br>
sim, talvez esteja muito em cima pra digerir tudo.<br></blockquote><div><br></div><div>É minha proposta!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dá pra sair até um curso disso.<br></blockquote><div><br></div><div>Dá para sair um livro mesmo.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">O que acham?<br></blockquote><div><br></div><div>Eu QUERO, como diria o Eduardo Jorge.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[]'s<br>
<br>
2015-02-01 7:39 GMT-02:00 Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Em 31 de janeiro de 2015 22:30, Lucas Mateus<br>
> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>> escreveu:<br>
>><br>
>> Indexar uma app AngularJS ? Como se faz isso ?<br>
><br>
><br>
> A resposta canônica é, ironicamente considerando esta thread, implementando<br>
> um serviço Rest by the book.<br>
><br>
> Se sua App AngularJS for cliente de um ou mais serviços Rest, você terá tudo<br>
> indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente é<br>
> apenas obtido do server, mas ele roda no computador do usuário e poderia<br>
> mesmo ser distribuído como uma WebApp ou Android App ou iOS App.<br>
><br>
> É nessa ora, ironicamente, que compreender a arquitetura com que se pretende<br>
> trabalhar faz toda a diferença.<br>
><br>
> Enim, se você implementa AngularJS como aplicação cliente de um ou mais<br>
> serviços Rest, e faz seu Rest de acordo com todos os bons conhecimentos<br>
> acumulados em SEO, você terá sua aplicação indexada, compartilhada em redes<br>
> sociais, embebida em outros sites, etc… com todos os mesmos conhecimentos<br>
> que foram acumulados para isso nos últimos 30 anos.<br>
><br>
> Nada muda, pois Rest nada mais é do que: Olha como a WEB é legal e funciona,<br>
> vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com<br>
> conteúdo machine readableb.<br>
><br>
> De fato, vocês só levantaram mais um ponto e mostraram ou provaram que mesmo<br>
> um comércio de flores local se beneficia de contratar uma empresa ou<br>
> consultor atualizado para desenhar seus softwares e que você não precisa<br>
> trabalhar para Google, Facebook ou Twitter para precisar se preocupar em<br>
> adquirir conhecimento formal sobre as tecnologias que emprega.<br>
><br>
>><br>
>> Enviado pelo meu Windows Phone<br>
>> ________________________________<br>
>> De: Leonardo Ruoso<br>
>> Enviada em: ‎31/‎01/‎2015 21:50<br>
>> Para: <a href="mailto:saopaulo-pm@mail.pm.org">saopaulo-pm@mail.pm.org</a><br>
>> Assunto: Re: [SP-pm] Resumo do Evento Técnico<br>
>><br>
>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>> escreveu:<br>
>>><br>
>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus<br>
>>> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>> escreveu:<br>
>>>><br>
>>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em mongo"<br>
>><br>
>><br>
>> Tem uma única diferença, que é o perfil profissional de quem está<br>
>> recomendando AngularJS em comparação com o perfil de quem recomenda MongoDB.<br>
>><br>
>><br>
>><br>
>> =begin disclaimer<br>
>>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> =end disclaimer<br>
>><br>
><br>
><br>
><br>
> --<br>
> Leonardo Ruoso<br>
> Journalist, Perl developer and business consultant<br>
> Media, UFC/2006; Telecom, IFCE/1998<br>
><br>
> =begin disclaimer<br>
>    Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
>  SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>  L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
> =end disclaimer<br>
><br>
=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div>