ThoughtWorks indica reavaliar o desenvolvimento em linguagem Java e investir forte na plataforma

Bruno Laturner:

O ThoughtWorks Technical Advisory Board é um grupo dos altos dirigentes técnicos da empresa, eles acabaram de publicar mais uma edição da ThoughtWorks Technology Radar, contendo um relatório para ajudar CIOs e tomadores de decisões nas empresas a avaliar tecnologias novas e atuais que impactam o mercado, ou tendenciarão o mesmo.

Continuando as afirmações do relatório anterior, eles pedem para que as empresas considerem diminuir a quantidade de código desenvolvido especificamente para Java, em favor de linguagens mais indicadas para o desenvolvimento de suas soluções.

Ainda sobre linguagens, eles recomendam a adoção de Ruby, JRuby, C# 4.0, e JavaScript como linguagem de primeiro escalão, e também começarem a tentar Groovy e DSLs.

Por outro lado, eles continuam recomendando a JVM como plataforma, reforçando o uso dela como uma máquina virtual de propósito geral para linguagens como Ruby, Groovy, Scala e Clojure. (retirado do relatório de Janeiro).

Plataformas, também desaconselham o GWT, e desenvolvimento de RIAs, além de seu uso em visualizações ricas. (Abril)

No campo de SOA, aconselham a evitar o ESB, e os WS-* além do básico.

Eu já li o Radar deles passado e quem assina, Jim Webber, que detesta ESBs e acho isso uma tremenda ignorância, pois os patterns de integração isoladamente são muito bem aceitos.

Ninguém tem preconceito com o Apache Camel, por exemplo, e um ESB de segunda geração, trata uma série de outras problemáticas, como tradução de protocolos, throttling (represa de processamento), SLAs e por aí vai.

Aliás, retirado desse radar atual:

In today?s connected systems environments almost all new development needs to integrate with existing applications and services. In conjunction with our adoption of simple message buses and integration techniques at the edges of a system, we have successfully used small libraries such as Apache Camel to perform the protocol bridging, message transformation and message routing tasks common to such integrations. Camel?s fluent Java interface, unit testing support and connectors for many different transports and message formats provide for an effective anti-corruption layer when implementing distributed applications.

Aqui há um paradoxo nervoso, pois o Camel é um ESB, pode ser light, pois ele não endereça outras questões.

Eu acho que os caras tem uma raiva de “produtos” e hoje há muita competição nesse mercado, amadurecimento e até projetos opensource como o Oxygen, Camel, Fuse, JBoss que cumprem muito bem o seu papel.

Outra coisa que ele não menciona é sobre centralização de segurança, por exemplo, que é um grande vilão em projetos com equipes e frameworks heterogêneos.

Eu acho esse relatório muito tendencioso a visão de “pregador” RESTful,e acaba um pouco míope.

A mesma coisa sobre WS*, em cenários de integração com outros protocolos, como SNA, vc pode utilizar o odiado SOAP como protocolo lógico que navega sob outros protocolos.

Não vou criar um troll sobre o assunto, mas valeria à pena o pessoal pesquisar sobre o Akka - Scala + Camel, por exemplo e como endereçam problemas de integração.

Bruno Laturner:

Continuando as afirmações do relatório anterior, eles pedem para que as empresas considerem diminuir a quantidade de código desenvolvido especificamente para Java, em favor de linguagens mais indicadas para o desenvolvimento de suas soluções.

(…)

Por outro lado, eles continuam recomendando a JVM como plataforma, reforçando o uso dela como uma máquina virtual de propósito geral para linguagens como Ruby, Groovy, Scala e Clojure. (retirado do relatório de Janeiro).

É a tendência desde 2007. E é um alerta para os programadores se adaptarem, procurando aprender outras linguagens. Infelizmente, a reação de muitos é trollar no GUJ ao invés de tomar atitude.

Principalmente o Ruby, né? A recente versão do Rails 3 é pra mim uma prova de que os railers deixaram de ser babacas e se tornaram adultos; pois o framework agora deixou de ser “opinionated” para ser modularizável e extensível, coisa que qualquer framework ou plataforma grande deve ser.

RIA sempre foi bullshitagem pra mim. É colocar a aparência estética acima da simplicidade, elegância e usabilidade. Os projetos RIA que eu participei entregavam softwares bonitos mais muito pouco funcionais, e acredito que essa era a norma do mercado.

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.

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.

Espera, Espera… Desenvolver menos código em java?? Porque eu deixaria de programar em Java para programar em C# ou Ruby? Existe um bom motivo para eu fazer isso? Pessoal vamos à prática. Se eu resolver abandonar JAVA hoje aqui na empresa, qual linguagem iria mim dá o mesmo suporte em termos de documentação disponível, ferramentas (livres e open source) e grupos de discursão como o JAVA? Qual linguagem eu tenho tudo isso e posso programar para a web, desktop mobile?

Eu reconheço a necessidade de se aprender novas linguagens e tals… Mas não estamos falando disso.

Eu realmente gostaria de saber da opnião de vocês.

E então?

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.

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.

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.

JavaFXMan:

Espera, Espera… Desenvolver menos código em java?? Porque eu deixaria de programar em Java para programar em C# ou Ruby? Existe um bom motivo para eu fazer isso? Pessoal vamos à prática. Se eu resolver abandonar JAVA hoje aqui na empresa, qual linguagem iria mim dá o mesmo suporte em termos de documentação disponível, ferramentas (livres e open source) e grupos de discursão como o JAVA? Qual linguagem eu tenho tudo isso e posso programar para a web, desktop mobile?

Eu reconheço a necessidade de se aprender novas linguagens e tals… Mas não estamos falando disso.

Eu realmente gostaria de saber da opnião de vocês.

E então?

Bom motivo? a necessidade do mercado somente.
Ou seja, sendo que este boletim é um indicativo para as lideranças das grandes empresas, e indica para ,não abandonar o java, mas não se limitar a ele
e considerar a possibilidade de adotar outras linguagens, e que isso é uma tendencia.

Se você, profissional que trabalha com desenvolvimento, vai se adptar a isso ou não ja é outra história.

Para um simples site, com formulários de cadastro, e coisas do tipo realmente não tem necessidade.
Agora para desenvolvimento de aplicações maiores, com grande quantidade de regras de negócio e workflow agregados a camada de visualização, eu recomendo 100% o uso destas ferramentas.

DiegoVenan:

JavaFXMan:

Espera, Espera… Desenvolver menos código em java?? Porque eu deixaria de programar em Java para programar em C# ou Ruby? Existe um bom motivo para eu fazer isso? Pessoal vamos à prática. Se eu resolver abandonar JAVA hoje aqui na empresa, qual linguagem iria mim dá o mesmo suporte em termos de documentação disponível, ferramentas (livres e open source) e grupos de discursão como o JAVA? Qual linguagem eu tenho tudo isso e posso programar para a web, desktop mobile?

Eu reconheço a necessidade de se aprender novas linguagens e tals… Mas não estamos falando disso.

Eu realmente gostaria de saber da opnião de vocês.

E então?

Bom motivo? a necessidade do mercado somente.
Ou seja, sendo que este boletim é um indicativo para as lideranças das grandes empresas, e indica para ,não abandonar o java, mas não se limitar a ele
e considerar a possibilidade de adotar outras linguagens, e que isso é uma tendencia.

Se você, profissional que trabalha com desenvolvimento, vai se adptar a isso ou não ja é outra história.

Se essa for mesmo a intenção dos caras da ThoughtWorks, queria parabenizá-los. Descobriram a pólvora.
As vezes as pessoas dão uma importância grande a palavras que não trazem nada de relevante só porque foram escritas/ditas por alguém que têm visibilidade no mercado.

Bom não há duvidas que outras linguagens rodando na JVM é uma tendência ja ha algum tempo.

Sobre abandonar java de vez, não precisa ser 8 ou 80, isto pode e deve ser gradativo, e para não perder o que o colega citou acima, toda a gama de ferramentas ja prontas em java, eu indicaria Scala, Groovy e ?Ruby?, bom não conheço muito de ruby e nao sei dizer o quanto ele se integra com java por isso as “???”, mas voce pode começar a desenvolver em Scala ou Groovy e continuar usufruindo de todos os seus frameworks e ferramentas escritos em java sem problemas. Esta é a grande vantagem que vejos nestas linguagens que rodam na JVM.
É indiscutivel a enorme quantidade de frameworks e ferraments desenvolvidos em java, não podemos simplesmente pegar tudo isto e jogar no lixo da noite pro dia.

JavaFXMan:

Espera, Espera… Desenvolver menos código em java?? Porque eu deixaria de programar em Java para programar em C# ou Ruby? Existe um bom motivo para eu fazer isso? Pessoal vamos à prática. Se eu resolver abandonar JAVA hoje aqui na empresa, qual linguagem iria mim dá o mesmo suporte em termos de documentação disponível, ferramentas (livres e open source) e grupos de discursão como o JAVA? Qual linguagem eu tenho tudo isso e posso programar para a web, desktop mobile?

Eu reconheço a necessidade de se aprender novas linguagens e tals… Mas não estamos falando disso.

Eu realmente gostaria de saber da opnião de vocês.

E então?

Esta dizendo que suporte, documentação, ferramentas, comunidade, é tudo exclusividade do Java e não existe em outras tecnologias??? Sério???

Apesar de achar que esse tipo de relatório tem quase nenhuma influência sobre diretores de TI e outras pessoas em cargo de decisão nas empresas, por outro lado é bom para programadores que andam confusos sobre mudanças que estão ocorrendo no mercado.

Parabéns ao “grupo de alto dirigentes técnicos” da thoughtworks!

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?”

Eu senti um ar de “O que nós usamos é o futuro!”

++

Ué… voce acha que eles deveriam recomendar o que nunca usaram?

é… eu também tive a impressão de que foram um pouco tendenciosos, apesar disso assim mesmo indicaram tecnologias que me parecem ser interessantes… só discordo bastante quanto ao java

eu também senti um certo ar de “o que usamos é o futuro”, mas esse “futuro” ai vejo ja a muito tempo que estão dizendo que vai ser o futuro e esse futuro não chega… acho que ainda vai demorar um certo tanto pra chegar (alguns chegarão beeeem fracos no mercado)…

Eles tem filiais no mundo todo, milhares de funcionários, centenas de projetos em andamento e outro a serem iniciados, é óbvio que uma empresa desse porte precisa ter algum indicador de “por onde devemos seguir”.

Agora usar essa informação ao seu próprio favor, fica a critério de cada um, no relatório não fala que eles são os masters do universo e quem que todo mundo é obrigado a seguir o que eles falam, MAS, ignorar o estudo deles, é no mínimo uma má conduta para um desenvolvedor.

[]s

Interessante a notícia. É sempre bom saber para onde as grandes instituições estão caminhando, pois pode se tornar uma tendência de mercado.

Att.

Eu ja senti um ar mais de :
“Java é UM caminho, e não O caminho”

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.

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.

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…

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?”

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:

1. O que foi dito na indicação do pessoal da ThoughWorks é válido? É verdadeiro?

2. É 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.

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.

[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

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.

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.

bobmoe:

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.

oi kenobi,

oq vc quis dizer com permissivo?

[]s,
bob

Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender

Kenobi:

bobmoe:

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.

oi kenobi,

oq vc quis dizer com permissivo?

[]s,
bob

Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender

Kenobi:

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.

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.

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.

No caso das RIAs já disseram o problema, sobre o GWT:

bobmoe:

Kenobi:

bobmoe:

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.

oi kenobi,

oq vc quis dizer com permissivo?

[]s,
bob

Olá Bob, depois dê uma pesquisada em segurança, injeção de tags, restrições de tipos, que vai entender

eval() é tão perigoso quanto sql injection e não é por isso q paramos de usar banco de dados, simplesmente validamos as entradas.

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!

Tem algum link com alguma explicação de por que XML é mais seguro para aplicações corporativas do setor financeiro? Eu to achando que é FUD…

De qualquer forma, concordo que JSON é muito bom pra ser usado para AJAX, mas eu também optaria por XML em webservices REST para comunicação entre sistemas.

Rubem Azenha:

De qualquer forma, concordo que JSON é muito bom pra ser usado para AJAX, mas eu também optaria por XML em webservices REST para comunicação entre sistemas.

Não que isso seja um problema, mas sua API não é de fato RESTful se vc usa JSON porque JSON não é um formato de hypermedia.

Não precisamos ser dogmáticos.

Rubem Azenha:

mochuara:

Não que isso seja um problema, mas sua API não é de fato RESTful se vc usa JSON porque JSON não é um formato de hypermedia.

Não precisamos ser dogmáticos.

E o que significa não ser dogmático neste caso? Poder chamar de REST aquilo que é qq coisa menos REST?

Desculpa, mas REST não é dogma, e sim uma arquitetura para sistemas escaláveis, e violar os princípios que tornam possível a realização desse objetivo não é ser anti-dogmatico, e sim ignorante em relação ao assunto.

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.

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.

vc diz isto pq não conhece Flex e nem o protocolo AMF… se conhece-los mudaria sua opinião neste aspecto…

Esses dias tava conversando com o meu chefe sobre começar a deixar de usar Java como linguagem de desenvolvimento, e a resposta dele foi a seguinte

De certa forma eu concordo com ele. Em um mercado aonde falta profissionais como o nosso, você usar algo que não seja mainstream é praticamente assinar um termo de “Terei que treinar todos os profissionais que vierem trabalhar aqui”, e isso tem um custo elevado.

É preciso levar esse fato em conta também. Principalmente em áreas como aqui, que um projeto durá em produção 10 anos ou mais. E se vc faz um projeto que vai durar esse tempo em Scala, e neste intervalo Scala é abandonado?

É uma decisão bem delicada essa de abandonar a linguagem Java.

Para nós desenvolvedores, é importante aprender várias linguagens destas que estão surgindo, e tocar nossos projetinhos pessoais com a linguagem que atender melhor e for mais rápida pra aquilo. Mas para as empresas, a decisão fica bem mais difícil.

Já vi um monte de linguagem nova aparecer, pregarem que é o futuro e que os desenvolvedores tem de focar nelas. Daí um monte de gente gasta dinheiro com treinamento, participando de congressos e apresentações e meses depois a linguagem desaparece.

Vamos ser críticos: quanto tempo um bom desenvolvedor demora pra aprender uma linguagem pelo menos ao ponto de ficar produtivo?

Se na sua região o mercado dessas linguagens estiver promissor, beleza. Mas se ainda ficar só na promessa, acho melhor investir em tecnologias que hoje estão em alta e geram dinheiro.

O que não pode é a pessoa ficar extremamente focada em uma só linguagem ou uma só tecnologia, mesmo Java sendo a mais popular. Mas acho que isso é óbvio.

marcosalex:

Já vi um monte de linguagem nova aparecer, pregarem que é o futuro e que os desenvolvedores tem de focar nelas. Daí um monte de gente gasta dinheiro com treinamento, participando de congressos e apresentações e meses depois a linguagem desaparece.

Vamos ser críticos: quanto tempo um bom desenvolvedor demora pra aprender uma linguagem pelo menos ao ponto de ficar produtivo?

Se na sua região o mercado dessas linguagens estiver promissor, beleza. Mas se ainda ficar só na promessa, acho melhor investir em tecnologias que hoje estão em alta e geram dinheiro.

O que não pode é a pessoa ficar extremamente focada em uma só linguagem ou uma só tecnologia, mesmo Java sendo a mais popular. Mas acho que isso é óbvio.

marcosalex:

Já vi um monte de linguagem nova aparecer, pregarem que é o futuro e que os desenvolvedores tem de focar nelas. Daí um monte de gente gasta dinheiro com treinamento, participando de congressos e apresentações e meses depois a linguagem desaparece.

Vamos ser críticos: quanto tempo um bom desenvolvedor demora pra aprender uma linguagem pelo menos ao ponto de ficar produtivo?

Se na sua região o mercado dessas linguagens estiver promissor, beleza. Mas se ainda ficar só na promessa, acho melhor investir em tecnologias que hoje estão em alta e geram dinheiro.

O que não pode é a pessoa ficar extremamente focada em uma só linguagem ou uma só tecnologia, mesmo Java sendo a mais popular. Mas acho que isso é óbvio.

1- Não aparece tanta linguagem nova assim.
2- Qual foi a última linguagem que desapareceu? Eu não conheço nenhuma.
3- Um bom desenvolvedor não demora pra aprender uma nova linguagem. Se demora, não é bom!
4- Inicialmente, um profissional deve buscar sim as tecnologias mais utilizadas hoje. Porém, duvido que demore mais de dois anos pra aprendê-las. Após esse período, o profissional precisa dedicar parte do seu tempo mais no futuro do que no presente. Senão, corre um sério risco de perder o bonde.

lavh:

Esses dias tava conversando com o meu chefe sobre começar a deixar de usar Java como linguagem de desenvolvimento, e a resposta dele foi a seguinte

De certa forma eu concordo com ele. Em um mercado aonde falta profissionais como o nosso, você usar algo que não seja mainstream é praticamente assinar um termo de “Terei que treinar todos os profissionais que vierem trabalhar aqui”, e isso tem um custo elevado.

É preciso levar esse fato em conta também. Principalmente em áreas como aqui, que um projeto durá em produção 10 anos ou mais. E se vc faz um projeto que vai durar esse tempo em Scala, e neste intervalo Scala é abandonado?

É uma decisão bem delicada essa de abandonar a linguagem Java.

Para nós desenvolvedores, é importante aprender várias linguagens destas que estão surgindo, e tocar nossos projetinhos pessoais com a linguagem que atender melhor e for mais rápida pra aquilo. Mas para as empresas, a decisão fica bem mais difícil.

É a velha visão de curto prazo obfuscando a visão de longo prazo. Às vezes, gostaria de saber de quem não consegue contratar o que foi oferecido para os candidatos e aonde os procurou. Porque, sério, eu recentemente procurei emprego e a maioria dos recrutadores não mostrava nenhum diferencial que pudesse atrair candidatos, nenhum! É tudo a mesma coisa! Como é que eles esperam despertar o interesse de quem já tem quase a mesma coisa num outro emprego?! Bom, divago, voltando ao tópico…

O que você e seu chefe não percebem é que:

a) o pool de programadores Java é grande, mas está cheio de imbecis e alpinistas de carreira, salvando-se poucos; porém, o pool de programadores Scala é pequeno, mas que estão ali por paixão, onde boa parte é muito produtivo.

b) Qualidade triunfa sobre quantidade. A mentalidade taylorista impede de ver que a diferença de produtividade entre o pior e o melhor programador é muito grande, da ordem de 20 vezes mais. Sim, é isso mesmo, programação é uma atividade intelectual, portanto não é limitado pelo cansaço muscular. Posso dizer que é melhor ter uma equipe pequena de sete programadores Scala altamente motivados do que 50 operários que mechem (com “ch”, porque não sabem nem português) com Java, mas desmotivados e sem possibilidade de alçar voos.

c) Uma empresa só vai contratar muito menos de 0,1% do pool de programadores. Não precisa que o pool seja grande, apenas que corresponda com a expectativa daqueles que estão neles. Outra, pare de procurar na APInfo, corre atrás e participe das comunidades Scala.

d) Um software não vai durar 10 anos se a política for manter a mesma arquitetura. Ela precisa evoluir, nem que seja pra trocar de linguagens por um tempo. Ou você acha que existe otário dando manutenção em um sistema do jeito que era feito há dez anos trás? (Não precisa responder, eu sei que tem!) Imagine: J2EE 1.3, com Struts 1.2.x, aqueles DTOs intermináveis… Acha que um sistema sobrevive, atendendo plenamente o cliente, continuando do jeito que tá? Se liga! Chegará o momento em que alguma nova tecnologia atenderá melhor os problemas do cliente do que a arquitetura corrente, e os homens do sistema precisam ter coragem para mudar!

bem eh uma visao deles, mas o nosso mercado a TW ela nao dita muita coisa por aqui nao, e tb nao tem forte influencia no Java, sabemos quais empresas decidem o negocio, pois essas que tem os potenciais clientes que sao os donos do mercado, uma empresa de tecnologia ela nunca vai ditar,e dizer, vamos usar isso, pq eu acho melhor, sabemos que isso nao funciona.

bem abadonar o java eh dificil viu, quantas instituicoes, grandes dependem do java, e fizeram ja alto investimentos. um cliente que nao perde 1 centavo do que gastou sao as instituicoes financeiras, e boa parte delas usam Java.

O que a TW falou pode ser uma tendencia, que para a nossa realidade ainda nao estar firme, e acredito que em outros mercados tb.

LPJava:

bem abadonar o java eh dificil viu, quantas instituicoes, grandes dependem do java, e fizeram ja alto investimentos. um cliente que nao perde 1 centavo do que gastou sao as instituicoes financeiras, e boa parte delas usam Java.

Por favor, gostaria que citasse a fonte que diz que boa parte dos sistemas de instituições financeiras são feitos em Java.

lavh:

Esses dias tava conversando com o meu chefe sobre começar a deixar de usar Java como linguagem de desenvolvimento, e a resposta dele foi a seguinte

De certa forma eu concordo com ele. Em um mercado aonde falta profissionais como o nosso, você usar algo que não seja mainstream é praticamente assinar um termo de “Terei que treinar todos os profissionais que vierem trabalhar aqui”, e isso tem um custo elevado.

É preciso levar esse fato em conta também. Principalmente em áreas como aqui, que um projeto durá em produção 10 anos ou mais. E se vc faz um projeto que vai durar esse tempo em Scala, e neste intervalo Scala é abandonado?

É uma decisão bem delicada essa de abandonar a linguagem Java.

Para nós desenvolvedores, é importante aprender várias linguagens destas que estão surgindo, e tocar nossos projetinhos pessoais com a linguagem que atender melhor e for mais rápida pra aquilo. Mas para as empresas, a decisão fica bem mais difícil.

Sem dúvida, pra que contratar desenvolvedores de verdade quando basta alguém que saiba alguns frameworks e copiar/colar XML?

Vocês todos estão confundindo as coisas, o que é necessário é um esforço de colaboração projeto de software é um contexto de muitos e não de uma pessoa só , sobre usar determinada tecnologia ou não você consulta o modelo pra entender soluções, se vai usar Java , Scala , Clojure ou o que for, isso é um estudo que visa o entendimento pelo instrumento e vantagem tecnica que o projeto poderá se situar.

“No plano de vocês a linguagem entende-se aqui como o recurso final , quando isso é absurdamente mentiroso e sem fundamento”

Eu ja senti um ar mais de :
“Java é UM caminho, e não O caminho”

Concordo. Para cada situação existe uma melhor situação.

Falar que RIA é lixo? Se fosse, não estaria no mercado e crescendo.
Falar que SOA é lixo? Se fosse, não estaria no mercado e crescendo.
Falar que Java,Ruby…

Existem linguagens que aos poucos começam a sumir do mercado, e existem as linguagens que chegam.

O importante é sempre estar preparado.

Rubem Azenha:

Tem algum link com alguma explicação de por que XML é mais seguro para aplicações corporativas do setor financeiro? Eu to achando que é FUD…

De qualquer forma, concordo que JSON é muito bom pra ser usado para AJAX, mas eu também optaria por XML em webservices REST para comunicação entre sistemas.

Tambem fico na mesma duvida que nosso amigo Rubem Azenha… por que XML é mais seguro para aplicações corporativas do setor financeiro?

pois se não á um bom motivo para usar XML invez de JSON acho melhor não usar… pois JSON é bem menor e mais limpo que XML…

mas entre JSON e XML prefiro o AMF do Flex…

luistiagos:

Rubem Azenha:

Tem algum link com alguma explicação de por que XML é mais seguro para aplicações corporativas do setor financeiro? Eu to achando que é FUD…

De qualquer forma, concordo que JSON é muito bom pra ser usado para AJAX, mas eu também optaria por XML em webservices REST para comunicação entre sistemas.

Tambem fico na mesma duvida que nosso amigo Rubem Azenha… por que XML é mais seguro para aplicações corporativas do setor financeiro?

pois se não á um bom motivo para usar XML invez de JSON acho melhor não usar… pois JSON é bem menor e mais limpo que XML…

mas entre JSON e XML prefiro o AMF do Flex…

XML e JSON são dados, e dados são elementos passivos que por si só não causam risco algum, a não ser quando manipulados por algum código malicioso, e código malicioso pode fazer uso tanto de XML, JSON ou qualquer coisa, ou seja, é puro FUD mesmo.

mochuara:

luistiagos:

Rubem Azenha:

Tem algum link com alguma explicação de por que XML é mais seguro para aplicações corporativas do setor financeiro? Eu to achando que é FUD…

De qualquer forma, concordo que JSON é muito bom pra ser usado para AJAX, mas eu também optaria por XML em webservices REST para comunicação entre sistemas.

Tambem fico na mesma duvida que nosso amigo Rubem Azenha… por que XML é mais seguro para aplicações corporativas do setor financeiro?

pois se não á um bom motivo para usar XML invez de JSON acho melhor não usar… pois JSON é bem menor e mais limpo que XML…

mas entre JSON e XML prefiro o AMF do Flex…

XML e JSON são dados, e dados são elementos passivos que por si só não causam risco algum, a não ser quando manipulados por algum código malicioso, e código malicioso pode fazer uso tanto de XML, JSON ou qualquer coisa, ou seja, é puro FUD mesmo.

concordo… FUD dos grandes ainda…