[SP-pm] Resumo do Evento Técnico

Sun Feb 1 04:07:38 PST 2015

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 <leonardo em ruoso.com>:
> Em 31 de janeiro de 2015 22:30, Lucas Mateus
> <lucasmateus.oliveira em 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 em mail.pm.org
>> Assunto: Re: [SP-pm] Resumo do Evento Técnico
>>
>> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso <leonardo em ruoso.com>
>> escreveu:
>>>
>>> Em 31 de janeiro de 2015 19:45, Lucas Mateus
>>> <lucasmateus.oliveira em 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 em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>
>
>
> --
> Leonardo Ruoso
> Journalist, Perl developer and business consultant
> Media, UFC/2006; Telecom, IFCE/1998
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>