Qual será o motivo disto?
Não da para levar una asneira dessas em consideração, tem gente que gosta mesmo de falta de produtividade e bugs.[/quote]
Na verdade o exceço de RIA em sites é um erro, deixa tudo mais lento, e muitas vezes nem é necessário tudo isso, as vezes um HTML resolve, o exagero é que complica.[/quote]
Exatamente temos uma App aqui na empresa que foi desenvolvida em GWT+Grails e penso duas vezes de retirar o GWT deixou a aplicação mais complexa e sem nenhum ganho.
Oi pessoal
Creio que existam posições polemicas, mas nao ha como dizer que entre esses caras nao existam muitos visionarios. Muitas coisas que o Fowler falou em 2001 e 2002 nos seus livros, hoje sao padroes. Outras coisas que ele desaconselhou, hoje sumiram.
Quer ver um exemplo de março 2003, 1 ano depois da fundação do GUJ?
Quem mais falava de Ruby na época?
Quem leu o PoEAA mais recentemente deve ter percebido “poxa, eles falavam disso ja naquela época”. É que nem ler o Design Patterns e ver que em 1995 o cara criticava herança e citava papers da decada de 80.
Sem contar que isso ai vai bem mais longe que o Fowler, olhe a galera que assina o paper…
[quote=boaglio]
Não se esqueçam que vocês estão lendo uma opinião de uma empresa influente no mercado, mas que não dita as regras (alias ninguém consegue isso).
Mostrem esse documento para qualquer instituição financeira que eles vão perguntar: “onde está o Cobol?” 
[/quote]
Realmente. E temos que lembrar que aquilo é a opinião e experiência deles com algumas tecnologias. Da mesma forma que nada no mundo é bala de prata, nada no mundo é generalista o bastante para se aplicar a todos os casos. Acho que a visão deles sozinha não muda em nada. Mas talvez com a visão deles em conjunto com a visão de outras empresas(de micro á grandes), dá para se ver o que realmente é relevante, e o que realmente é asneira mercadológica.
Leio, respeito e reflito sobre a opinião deles.
Mas o mundo da tecnologia e especialmente de TI está muito amplo para se falar em tendências.
Para mim está tudo valendo, desde o C até o framework mais loco de Web.
Agora eu gostaria de ver se no lugar da Thoughtworks fosse a Oracle que fez esse estudo: O flamewar seria maior do que falar que java iria morrer
Visionários existem em qualquer lugar, a diferença é que alguns ainda acham que o que move profissionais são as empresas e não o esforço de cada um dos desenvolvedores/arquitetos/etc e tal.
Na realidade, é o WB-* Basic Profile, né? Sim, isso é um pé-no-saco, porque é muito fácil criar um Web Service que não possui interoperabilidade com outras linguagens.
[color=red] Concordo que tem muito desenvolvedor usando “geradores” - Contract Last, fazendo RPC e acha que e não tem a mínima idéia do que está acontecendo. Mas existem outros cenários que são importantes, como Orquestração - Máquina e estado, controlada por um processo de longa execução, por exemplo. Interoperabilidade com sistemas de mensageria, e por aí vai. [/color]
Eles falam sobre OAuth, serve?
Eu sei lá, eu consigo imaginar centralização de autenticação, com LDAP ou Active Directory. Mas não acho possível, ou mesmo aceitável, usar a mesma solução de segurança para todos os projetos de uma empresa.
[color=red] O OAUTH vai te servir se não precisar propagar sua certificado digital X.509, por exemplo, entre diferentes protocolos e sistemas. Senão, ferrou. Ele é uma solução que atende muito bem necessidades Web, mas quando vc precisa autenticar com um CICS pra falar com Mainframe, vai precisar de outra estrutura.
Quanto a autenticação, vc vai criar realemnte grupos usando LDAP e gerar políticas para autorização a cada serviço por grupos. A forma que vai utlizar para consultar no LDAP, como Kerberos Ticket, será definida como policy e pode ser propagada a outros sistemas.
Na prática, o que vemos é que cada solução implementa ou não ( o que é mais comum), segurança nas aplicações. Centralizar isso, é uma forma de controlar um pouco do CAOS do ambiente corporativo. A Redecard por exemplo, possui mais de 100 sistemas diferentes, imagine como fica cada uma dessas soluções ?
[/color]
Pra mim isto apenas um relato interno da ThoughtWorks, baseado em experiências do que eles tem usado no dia a dia. Achei legal saber o que eles tem usado e saber o que realmente para eles é uma tendência e o que não é.
Acho que isso é bom pra gente, pra mostrar que existe outras coisas além do Java (Linguagem em si).
Para alguns que citaram o tópico, é importante diferenciar:
O que foi dito na indicação do pessoal da ThoughWorks é válido? É verdadeiro?
É novidade?
Acredito eu, que o objetivo da ThoughWorks, não seja o de falar “usem o que eu uso”, seria imaturidade pra uma empresa com tamanha experiência.
Como alguns já disseram, eles recomendam o que, já utilizaram e tiveram boas experiências, e devem ser levadas em consideração, como o Paulo falou, muita coisa que o Fowler citou há anos atrás, hoje se firma como verdade.
É pura infantilidade ficar de birrinha, só porque alguma tecnologia hype, não foi citada no paper.
Kenobi, se você não tem que propagar sua certificado digital X.509 com CICS e mainframe com throttling e etc, oAuth funciona muito bem, não? Acho que é essa a mensagem que eles passam, evita comprar esses produtos caros, ou pesados, complexos e de baixa produtividade a menos que seja estritamente necessario.
É claro que eles puxam a brasa pra sardinha deles, mas muita coisas que eles falam tem sentido. Eu já vi muito mais projetos falharem por usar uma arquitetura muito complexo e produtos com baixa produtividade do que projetos falharem por que a arquitetura “não aguentou” a demanda ou requisitos técnicos complexos, por isso eu acho que é uma posição que faz sentido pra uma consultoria que não tem vinculo com nenhum vendor.
[quote=Rubem Azenha]Kenobi, se você não tem que propagar sua certificado digital X.509 com CICS e mainframe com throttling e etc, oAuth funciona muito bem, não? Acho que é essa a mensagem que eles passam, evita comprar esses produtos caros, ou pesados, complexos e de baixa produtividade a menos que seja estritamente necessario.
É claro que eles puxam a brasa pra sardinha deles, mas muita coisas que eles falam tem sentido. Eu já vi muito mais projetos falharem por usar uma arquitetura muito complexo e produtos com baixa produtividade do que projetos falharem por que a arquitetura “não aguentou” a demanda ou requisitos técnicos complexos, por isso eu acho que é uma posição que faz sentido pra uma consultoria que não tem vinculo com nenhum vendor.[/quote]
[color=red]
O que eu coloquei aqui é a famosa: Vamos analisar meu contexto. Se você não integra com CICS, pra que vai colocar o trem ? Concordo. Se está num projetinho Web simples, toca em Rails, simples assim.
Eu acho que é questão de bom senso e quando trabalhamos com players o bom senso é licença, merda…vimos esse filme !
Em contra-partida, muitas pessoas argumentam em cima de JSON em favor ao XML e nem sabem a diferença, somente sobre a verbosidade. Não sabem que o JSON é permissivo e em ambientes financeiros, isso poderia ser um problema. Que há protocolos já definidos como SWIFT (financeiro) e HI7 (saúde) e não vão mudar do dia pra noite.
Quando falamos de Telecom, há uso intensivo de mensageria e ainda não dá pra confiar em soluções em cima de PubSubHubBub.
Mas sabemos como é o cenário das empresas. Estou percorrendo alguns clientes e juro, você se chocariam com as coisas que ando vendo no ambiente coropativo. São aplicações do tempo do EPA e se você precisar conversar com elas, ferrou.
Para novas iniciativas isoladas, ou startups ou empresas ágeis, concordo integralmente. Faça sua arquitetura usando linguagens produtivas como Ruby, frameworks como Restfulie ou Corerest, integrações de serviços com YQL, Atom-Atompub, MicroFormats, RDF-RDFa e mete bala
Só pra constar, estou tocando um projetinho fazendo BDD-Cucumber + Restfulie + OAuth e estou adorando a brincadeira
[/color]
Então para projeto web Rails simples eu posso usar oAuth… Tipo o Twitter?
Protocolos “leves” não servem apenas para projetos simples, projetos complexos e grandes funcionam muito bem sem toda a parnafernália padrão do SOA. Falar " Se está num projetinho Web simples, toca em Rails, simples assim." é uma falta de bom senso.
Assim como falar que não se deve usar ESB é errado, é errado que falar que REST, oAuth, JSON, etc serve apenas para projetos simples.
PS: Não precisa colocar seus posts em vermelho para chamar mais atenção.
oi kenobi,
oq vc quis dizer com permissivo?
[]s,
bob
[quote]
Então para projeto web Rails simples eu posso usar oAuth… Tipo o Twitter?
Protocolos “leves” não servem apenas para projetos simples, projetos complexos e grandes funcionam muito bem sem toda a parnafernália padrão do SOA. Falar " Se está num projetinho Web simples, toca em Rails, simples assim." é uma falta de bom senso.
Assim como falar que não se deve usar ESB é errado, é errado que falar que REST, oAuth, JSON, etc serve apenas para projetos simples.
PS: Não precisa colocar seus posts em vermelho para chamar mais atenção.[/quote]
Falei projeto simples e do ponto de vista arquitetural e não simplistas. O Twitter possui Rails, mas uma série de outras soluções internas, com mensageria em Scala e sua arquitetura não é nem um pouco Simples ou Rails default. Assim como a Boo-Box com Redis, então a solução vc adapta de acordo com a necessidade. Simplifiquei somente o cenário Web, em cima de HTTP. E não quis dizer que se usa HTTP, JSON e afins somente para projetos simples e sim para projetos que rodem em cima de HTTP, como os Web.
Talvez tenha sido a semântica e ficou meio confuso, ou eu estou escrevendo meio torto, mas é isso.
[quote=bobmoe][quote=Kenobi]
Em contra-partida, muitas pessoas argumentam em cima de JSON em favor ao XML e nem sabem a diferença, somente sobre a verbosidade. Não sabem que o JSON é permissivo e em ambientes financeiros, isso poderia ser um problema. Que há protocolos já definidos como SWIFT (financeiro) e HI7 (saúde) e não vão mudar do dia pra noite.
[/quote]
oi kenobi,
oq vc quis dizer com permissivo?
[]s,
bob[/quote]
Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender
[quote=Kenobi][quote=bobmoe][quote=Kenobi]
Em contra-partida, muitas pessoas argumentam em cima de JSON em favor ao XML e nem sabem a diferença, somente sobre a verbosidade. Não sabem que o JSON é permissivo e em ambientes financeiros, isso poderia ser um problema. Que há protocolos já definidos como SWIFT (financeiro) e HI7 (saúde) e não vão mudar do dia pra noite.
[/quote]
oi kenobi,
oq vc quis dizer com permissivo?
[]s,
bob[/quote]
Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender [/quote]
eval() é tão perigoso quanto sql injection e não é por isso q paramos de usar banco de dados, simplesmente validamos as entradas.
[quote=Kenobi][quote]
Então para projeto web Rails simples eu posso usar oAuth… Tipo o Twitter?
Protocolos “leves” não servem apenas para projetos simples, projetos complexos e grandes funcionam muito bem sem toda a parnafernália padrão do SOA. Falar " Se está num projetinho Web simples, toca em Rails, simples assim." é uma falta de bom senso.
Assim como falar que não se deve usar ESB é errado, é errado que falar que REST, oAuth, JSON, etc serve apenas para projetos simples.
PS: Não precisa colocar seus posts em vermelho para chamar mais atenção.[/quote]
Falei projeto simples e do ponto de vista arquitetural e não simplistas. O Twitter possui Rails, mas uma série de outras soluções internas, com mensageria em Scala e sua arquitetura não é nem um pouco Simples ou Rails default. Assim como a Boo-Box com Redis, então a solução vc adapta de acordo com a necessidade. Simplifiquei somente o cenário Web, em cima de HTTP. E não quis dizer que se usa HTTP, JSON e afins somente para projetos simples e sim para projetos que rodem em cima de HTTP, como os Web.
Talvez tenha sido a semântica e ficou meio confuso, ou eu estou escrevendo meio torto, mas é isso. [/quote]
Kenobi acho que ele quis falar especificamente do oAuth, que o twitter esta usando agora. Inclusive todas as apps clientes tiveram que se adaptar, se não me engano foi agora em agosto a mudança.
Qual será o motivo disto?
Não da para levar una asneira dessas em consideração, tem gente que gosta mesmo de falta de produtividade e bugs.[/quote]
No caso das RIAs já disseram o problema, sobre o GWT:
[quote=bobmoe][quote=Kenobi][quote=bobmoe][quote=Kenobi]
Em contra-partida, muitas pessoas argumentam em cima de JSON em favor ao XML e nem sabem a diferença, somente sobre a verbosidade. Não sabem que o JSON é permissivo e em ambientes financeiros, isso poderia ser um problema. Que há protocolos já definidos como SWIFT (financeiro) e HI7 (saúde) e não vão mudar do dia pra noite.
[/quote]
oi kenobi,
oq vc quis dizer com permissivo?
[]s,
bob[/quote]
Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender [/quote]
eval() é tão perigoso quanto sql injection e não é por isso q paramos de usar banco de dados, simplesmente validamos as entradas.[/quote]
Mas há ainda Data Types, restrictions entre outros. Em fim, acho que em cenários pesados como o financeiro, precisaria pensar muito sobre o a adoção de JSON, prós e contras. Em projetos que não há tal preocupação intensiva, pode ser adotado algo mais leve, sou partidário da menor verbosidade e produtividade.
Quote for the win!