Arquivo Discussoes de Programacao e Tecnologia A empresa Thoughtworks divulgou a lista de tecnologias promissoras, dentre elas Mobile, BigData, NoSQL e frameworks JS, dentre outros…
PDF: http://thoughtworks.fileburst.com/assets/technology-radar-october-2012.pdf
Só não entendi porque o maven ficou em último lugar como ferramenta e segundo eles, se encaixa na categoria “Hold: Proceed with caution.”
Eles decidiram que xml não é mais moda. O legal agora, segundo esses caras, é usar soluções como o gradle em vez de maven.
Aliás, a lista é legal.
Nesse caso tenho que discordar dos caras…há anos venho trabalhando com o maven e acho que o XML é mínimo em troca dos benefícios que ele me traz…além do que, segundo o site deles mesmos:
"… Gradle combines the power and flexibility of Ant with the dependency management and conventions of Maven into a more effective way to build…"
De resto tb achei a lista bacana
Nesse caso tenho que discordar dos caras…há anos venho trabalhando com o maven e acho que o XML é mínimo em troca dos benefícios que ele me traz…além do que, segundo o site deles mesmos:
"… Gradle combines the power and flexibility of Ant with the dependency management and conventions of Maven into a more effective way to build…"De resto tb achei a lista bacana
E outra coisa, essa lista é de 2012 
Coisas estranhas nessa lista:
Só pra listar algumas… no geral, percebo que esse radar reflete mais o jeito da Thoughtworks de ser e menos o que o mercado precisa, de fato. OK, talvez o mercado até precise se adequar um pouco a isso, mas no geral, vejo que essa lista está bem longe de ser encarada como verdade absoluta.
[]'s
Concordo com vc Alexandre…a lista não reflete nossa realidade. Tanto em ferramentas quanto em técnicas. No geral é uma boa perspectiva dos caras.
Rodrigo essa lista foi concluída em Outubro de 2012, refletindo o mercado a partir de então. Ela não se refere somente a 2012
Isso é mais do que óbvio. Só estou te dizendo que a lista não é de 2013, como o título do seu tópico faz parecer.
É muito fácil para uma empresa divulgar o que lhe interessa. Falar que tecnologia x está morrendo pq eles não adotaram.
Falar que mavem como Hold? te catar viu…
Ué. Enterprise Service Bus em Hold?
Eu achava que isso era algo muito utilizado hoje em dia, e muito aceitado
Também acho… E o pessoal do Hibernate também.
Notícia velha. Isso é de 2012.
no geral, percebo que esse radar reflete mais o jeito da Thoughtworks de ser e menos o que o mercado precisa, de fato.
Teve uma apresentação deles ano passado (ou retrasado) na Caelum, justamente para comentar o último radar que havia sido lançado.
Um dos pontos que deixaram bem claro é justamente que essa é a opinião deles e das coisas que tem dado certo pra eles, não que deveria ser seguido por todos.
Seria interessante ver a visão de outras empresas também.
no geral, percebo que esse radar reflete mais o jeito da Thoughtworks de ser e menos o que o mercado precisa, de fato.Teve uma apresentação deles ano passado (ou retrasado) na Caelum, justamente para comentar o último radar que havia sido lançado.
Um dos pontos que deixaram bem claro é justamente que essa é a opinião deles e das coisas que tem dado certo pra eles, não que deveria ser seguido por todos.
Seria interessante ver a visão de outras empresas também.
Pois é… e, de fato, se você for parar pra pensar, é praticamente impossível encontrar uma empresa que tenha uma visão apurada do mercado E seja isenta. Tome o Gartner, por exemplo: acho os gráficos deles, de tendências e tudo mais, incrivelmente (com o perdão da palavra) tendencioso. Dá uma certa impressão de que eles defendem, e muito, os interesses deles ao elaborar os gráficos.
Em contrapartida, você tem uma Thoughtworks, que é uma consultoria… Ou seja, a TW serve como referência para adotar novas tecnologias e realizar assessment e tudo mais em cima destas, mas você não encontra algum gráfico deles falando de adoção de Oracle Database (que é um bom produto, porém antigo).
[]'s
Ué. Enterprise Service Bus em Hold?Eu achava que isso era algo muito utilizado hoje em dia, e muito aceitado
E é! Justamente por isso que eu estava falando do “estilo Thoughtworks de ser”: eles mostram as tendências dos projetos que eles têm assessorado, não do mercado como um todo. Como eu disse no post acima, você não vai encontrar a TW falando de Oracle Database, porque não faz parte da realidade deles. Ou seja, mesmo que seja um bom produto e amplamente utilizado, se eles não usam ou não querem mais usar, ou não colocam no gráfico ou colocam em Hold (que nem eles fizeram com o Maven, que também é amplamente adotado).
[]'s
P.S: Cadê o Luca aqui, para opinar sobre isso? =)
Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:
“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”
Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.
Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.
O que, aliás, me faz pensar se o protocolo HTTP já não seria defasado, e incapaz de suportar as necessidades de desenvolvimento atuais…
Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.
O que, aliás, me faz pensar se o protocolo HTTP já não seria defasado, e incapaz de suportar as necessidades de desenvolvimento atuais…
Pode até ser que esteja defasado, Alexandre. É até complicado argumentar contigo com todo o gabarito que vc tem =). Mas acredito que há coisas boas que rodam em cima dele, como REST e WS-*, além disso, com o suporte a websocket será possível aumentar ainda mais a interatividade entre servidor e cliente (browser). E nesse cenário, frameworks action-based permitem desacoplar melhor a parte do servidor da parte cliente. Mas como disse, você tem mais know-how que eu pra avaliar. E por falar nisso, seu livro da Casa do Código é meu próximo alvo =).
Encontrei um FAQ explicando como é feita a criação do radar: http://martinfowler.com/articles/radar-faq.html
Lá explica que muitos itens são cortados por falta de espaço OU por já terem sidos citados em outros radares.
Dão basicamente preferência a tecnologias que estão se movimentando no radar deles.
Como o Oracle já é padrão mais do que reconhecido, não falam dele. (Ah não ser se um dia deixarem de recomendar).
Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.
O que, aliás, me faz pensar se o protocolo HTTP já não seria defasado, e incapaz de suportar as necessidades de desenvolvimento atuais…
Pode até ser que esteja defasado, Alexandre. É até complicado argumentar contigo com todo o gabarito que vc tem =). Mas acredito que há coisas boas que rodam em cima dele, como REST e WS-*, além disso, com o suporte a websocket será possível aumentar ainda mais a interatividade entre servidor e cliente (browser). E nesse cenário, frameworks action-based permitem desacoplar melhor a parte do servidor da parte cliente. Mas como disse, você tem mais know-how que eu pra avaliar. E por falar nisso, seu livro da Casa do Código é meu próximo alvo =).
Opa, valeu pelo apoio =)
Mas então, na verdade, eu não falei pensando em nenhum protocolo existente (não um que eu conheça, pelo menos). Isso seria questão de analisar necessidades e, de repente, criar outro protocolo. Preciso arranjar um tempinho pra dar uma olhada no SPDY e ver se, de repente, não era nisso que eu tava pensando.
[]'s
SPDY nao adiciona nada de novo ao HTTP. É só um encoding diferente:
Ué. Enterprise Service Bus em Hold?Eu achava que isso era algo muito utilizado hoje em dia, e muito aceitado
Bom as equipes do MuleEsb - http://www.mulesoft.org, RedHat que comprou há pouco a FuseSource - http://fusesource.com, Oracle dona do ESB mais usado em Teles e Bancos do Brasil - http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html entre outros players + a consultoria SOA|EXPERT e a comunidade SOACLOUD - http://soacloud.com.br pensam ao contrário.
Não dá pra fazer integração Point-to-point, tradução de protocolos é necessário e há Patterns para isso - Enterprise Integration Patterns. A TW ainda não entendeu que o ESB é um framework que implementa tais padrões e hoje há diversas opções opensource, assim como o conceito está em constante evolução.
O mais engraçado é que recomendam o ApacheCamel, que é o Kernel do FuseESB, JBoss ESB, Service Mix etc. Acho que eles não entenderam muito bem a diferença entre uma coisa e a outra e principalmente, o papel do Pattern Message Bus, assim como o que os frameworks atuais oferecem como: Interceptadores, Segurança, Políticas e SLA, Monitoria etc.
Bom queria ver como fazem integração com SAP, Mainframe, EBS, Siebel etc. Deve ser um ninho de mafagafinho ou um jogo de palitinhos gigantesco
PS: A grande influência veio do Jim Webber, Restafarian convicto ex-diretor e autor do Rest in Practice, que escreveu outros radares no passado. Ele jogou muito com a polêmica, de integrações através de Hypermedia, contudo há diferentes tipos de protocolos, necessidades de tratamento de estado, performance etc. Ele sabe do contra-ponto e deixa claro no seu próprio livro, o problema foi a TW ter comprado a “venda” do conceito como algo estratégico, tiro no pé.
Também acredito que por isso o Neo4j é recomendado, sem explicarem os cenários de utilização.
Realmente, muito estranho essa lista.
Scala só tem acumulado críticas, tanto de usuários inexperientes, quanto desenvolvedores de frameworks… ainda assim está em adopt?! :shock:
Realmente, muito estranho essa lista.Scala só tem acumulado críticas, tanto de usuários inexperientes, quanto desenvolvedores de frameworks… ainda assim está em adopt?! :shock:
Se eu tivesse focado em cloud também ignoraria o que consultorias Oracle tem a dizer.
Bom as equipes do MuleEsb - http://www.mulesoft.org, RedHat que comprou há pouco a FuseSource - http://fusesource.com, Oracle dona do ESB mais usado em Teles e Bancos do Brasil - http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html entre outros players + a consultoria SOA|EXPERT e a comunidade SOACLOUD - http://soacloud.com.br pensam ao contrário.Não dá pra fazer integração Point-to-point, tradução de protocolos é necessário e há Patterns para isso - Enterprise Integration Patterns. A TW ainda não entendeu que o ESB é um framework que implementa tais padrões e hoje há diversas opções opensource, assim como o conceito está em constante evolução.
O mais engraçado é que recomendam o ApacheCamel, que é o Kernel do FuseESB, JBoss ESB, Service Mix etc. Acho que eles não entenderam muito bem a diferença entre uma coisa e a outra e principalmente, o papel do Pattern Message Bus, assim como o que os frameworks atuais oferecem como: Interceptadores, Segurança, Políticas e SLA, Monitoria etc.
Bom queria ver como fazem integração com SAP, Mainframe, EBS, Siebel etc. Deve ser um ninho de mafagafinho ou um jogo de palitinhos gigantesco
PS: A grande influência veio do Jim Webber, Restafarian convicto ex-diretor e autor do Rest in Practice, que escreveu outros radares no passado. Ele jogou muito com a polêmica, de integrações através de Hypermedia, contudo há diferentes tipos de protocolos, necessidades de tratamento de estado, performance etc. Ele sabe do contra-ponto e deixa claro no seu próprio livro, o problema foi a TW ter comprado a “venda” do conceito como algo estratégico, tiro no pé.
Também acredito que por isso o Neo4j é recomendado, sem explicarem os cenários de utilização.
Se eu tivesse focado em cloud também ignoraria o que consultorias Oracle tem a dizer.
Eu também ignoro, até porque a Oracle vende um modelo da década de 70 “Mainframe-Colocation” e chama de private Cloud.
Só uma coisa, somos neutros à partners !!
Apesar de ter coisas que não concordo na tal lista, gostei da colocação a respeito de frameworks component-based:“As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years
of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into
something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against -
these concepts.”Ao tentar transformar a web em desktop, não se leva todo o poder de fogo do desktop, e ainda perde os benefícios da característica stateless do protocolo HTTP e do modelo request-response. E no contato com a galera que conheço que ama frameworks component-based, a maioria só ama porque escode o javascript deles, coisa que não são tão proficientes. Acho muito mais válido estudar as tecnologias envolvidas na web e tirar o melhor proveito de suas características.
SPDY nao adiciona nada de novo ao HTTP. É só um encoding diferente:
http://en.wikipedia.org/wiki/SPDY
Então, cv, parte do que lí em duas matérias dizem, mais ou menos, que o SPDY está sendo considerado candidato a HTTP 2.0. Links:
Essa última, inclusive, deixa um pouco mais explícito que o SPDY pode ser um candidato em potencial para ajudar no desenvolvimento de aplicações orientadas a componentes já que (segundo a matéria), o SPDY “expande” o HTTP pipelining, eliminando a necessidade de ser uma fila FIFO. Dessa maneira, poderíamos enviar várias requisições (uma para cada componente) e ir atualizando a página à medida que recebemos respostas.
[]'a