Caelum Technology Radar Setembro 2013

O Thoughtworks Technology Radar é bem popular: ajuda a indústria de software a entender melhor os prós e contras das mais diferentes tecnologias, práticas e plataformas existentes, através das lentes da equipe técnica da empresa. Há algum tempo , a própria Thoughtworks vem divulgando a ideia de que as empresas também deveriam fazer, como exercício, seus próprios radares de tecnologia.

Baseado nisso, decidimos criar nosso próprio radar. Nele colocamos toda nossa experiência dos últimos anos em desenvolvimento, consultoria e ensino. Para isso, decidimos organizar um encontro entre todos os nossos desenvolvedores e, a partir daí, moderamos uma discussão entre todos.

Veja aqui detalhes do Radar da Caelum

Coletamos opiniões bastante interessantes. UX ágil, por exemplo, foi algo que apareceu com bastante força. O uso das mais diversas práticas ágeis, como testes automatizados, desenvolvimento iterativo e programação pareada, também foram considerados como essencial.

No entanto, nossa equipe acredita no não uso de geradores de código Javascript, como é o caso do CoffeeScript. Além disso, houve um favorecimento para frameworks web action-based, ao invés de component-based. Com exceção do JSF2, grande parte dos frameworks component-based foram criticados.

Na página do radar, você encontra mais informações sobre como o criamos, como ele deve ser interpretado, bem como a nossa opinião completa. Nosso objetivo com ele é divulgar para todo o mercado o que acreditamos ser boas práticas, tecnologias e plataformas, e que devem ser usadas com frequência, bem como as que devem ser usadas com mais moderação.

Obviamente há divergências dentro da própria equipe, e o Radar apresenta uma foto da média dessas opiniões.

Essa é a nossa primeira tentativa de criar um radar, e portanto esperamos feedback de vocês para melhorá-lo cada vez mais. Espero que gostem. Certamente em sua empresa o cenário é diferente. Quais tecnologias você tem evitado? Quais tem adotado? Não deixe de comentar!

25 Comentários

  1. Sérgio Lopes 24/09/2013 at 13:40 #

    Acho que o pessoal do radar não gosta muito do Sublime pra programar hahaha. Pena, excelente editor, e muito forte na comunidade front. Eu hoje uso bem mais Sublime que Eclipse no meu dia a dia.

    E não tenho nada contra CoffeeScript 😛

    Bom trabalho compilando e moderando essa lista (polêmica) de tópicos pro radar!

  2. Rafael Dipold 24/09/2013 at 13:45 #

    Muito legal!

    Só acho que ao contrário do que o Radar revelou, os geradores de javascript vão ganhar importância em pouco tempo, pois é difícil manter e debuggar projetos com grande quantidade de código em javascript.

    Também não vejo muita vantagem com CoffeeScript, mas acredito no potencial de outras alternativas bem mais corporativas como o TypeScript e o Dart.

  3. Geilson Fonte 24/09/2013 at 14:18 #

    Muito boa a iniciativa. O Radar da ThoughtWorks é ótimo, mas as vezes um pouco distante da nossa realidade.

    Fiquei curioso com o conceito ruim para o Gradle. Se não me engano, a ThoughtWorks recomendou substituir o Maven pelo Gradle.

  4. camilo lopes 24/09/2013 at 14:56 #

    Gostei dessa iniciativa da Caelum. Realmente é bom ter vários techradar por diferentes empresas, assim temos mais opções e opiniões diferentes para analisar. Muito bom.

  5. Alberto Souza 24/09/2013 at 16:35 #

    Opa @Sergio,

    O sublime vai entrar sim. Na verdade acho que foi um erro na hora da compilação, tiveram algumas pessoas, principalmente as que gostam mais de front, que comentaram :).

  6. Alberto Souza 24/09/2013 at 16:37 #

    Oi @Geilson,

    Em relação ao Gradle foi realmente por conta das nossas experiências mesmo. Nos projetos que tentamos não achamos que a troca que ele oferece, por exemplo, oferecendo o groovy para escrever o build nos trouxe muitas recompensas. Como existem outras opções para o mundo Java, optamos por deixa-lo um pouco de lado.

    Qual foi sua experiência com ele?

  7. Geilson Fonte 24/09/2013 at 18:02 #

    Alberto,

    Eu uso o Maven e tento não complicar, não usar um monte de plug-ins (que são o motivo de crítica da ThoughtWorks). Até agora tem me atendido satisfatoriamente. Toda vez que tenho algum problema relacionado a build, a culpa é mais do Eclipse do que do Maven.

  8. Lohandus 24/09/2013 at 22:13 #

    +1 para o Dart. Estou usando e gostando muito.

  9. Alexandre Aquiles 25/09/2013 at 09:42 #

    Ótima iniciativa (e execução)!

    Achei legal que foi bem pé no chão: vocês revelaram dificuldades pouco discutidas por aí sobre o uso de algumas novas tecnologias.

    Como o Sérgio disse, há uma boa dose de polêmica nos “holds”: Gradle, editores de texto, geradores de JS e testes em linguagem natural.
    ___

    Sobre o Gradle, ouvi dizer que a ferramenta é lenta pra iniciar. Há o Gradle Daemon[1], um servidorzinho pra resolver esse problema, mas não sei se funciona bem.

    Uso Maven no dia-a-dia mas, quando você sai do feijão-com-arroz, tudo parece ser mais complicado do que deveria.

    Uma coisa interessante é que no livro “Pragmatic Project Automation” [2], há um daqueles quadrinhos em que o autor do Ant, James Ducan Davidson, diz se arrepender de ter usado XML e que deveria ter usado alguma linguagem de script.
    Em seguida, o livro mostra como usar Groovy para instanciar tarefas do Ant (que no fundo são classes Java) e ter uma linguagem de script para o build.
    ___

    Sobre testes em linguagem natural, para um (infelizmente raro) contexto em que o cliente realmente participa do desenvolvimento definindo exemplos, pode ser uma boa.

    Já ouvi gente falando que há um ganho incrível só de definir a especificação com exemplos em texto usando Given/When/Then.
    Clientes que não entendiam requisitos no formato de casos de uso, passaram a entender e interagir bem mais.

    Sobre Cucumber, hoje em dia há alguns reports bem interessantes [3] e bonitos, que podem ser publicados no Jenkins.
    Se o cliente realmente se interessar, ele pode ver o que está falhando, o que está passando e o que está pendente. Accountability na veia!
    ___

    A moral da história é que toda tecnologia é boa se usada no contexto certo, não é mesmo? 🙂

    [1] http://www.gradle.org/docs/current/userguide/gradle_daemon.html
    [2] http://pragprog.com/book/auto/pragmatic-project-automation
    [3] https://github.com/masterthought/cucumber-reporting

  10. Gilmar Soares 25/09/2013 at 10:48 #

    Estava olhando o conteúdo do Radar, muito bacana, achei bacana o uso do Heroku, usei para um projeto simples de um amigo, e já que falou-se do Heroku achei que deveria ter algo falando do Tsuru que é um projeto Open Source da galera da Globo.com.
    O restante, Play Framework, Maven, tudo muito bacana.

  11. Gleison Rodrigues 25/09/2013 at 12:06 #

    Muito bom o radar. Parabéns.

    @Sergio tanto o Sublime, o Vim e o Brackets são mais utilizados pelo pessoal que faz front e/ou trabalha com linguagens com Python e Ruby.

    NginX é bom de mais.

  12. Rafael 25/09/2013 at 19:41 #

    Esse radar é bem legal, porque já da uma guia para escolher algumas tecnologias para o desenvolvimento ou até mesmo para o estudo.
    Seria bom colocar no radar os servidores de aplicação.

  13. Rafael 25/09/2013 at 19:59 #

    Acho que o JSF deveria estar no Trial. Já desenvolvi com essa tecnologia e o que percebi foi um alto acoplamento.

  14. Marcelino Avelar 25/09/2013 at 20:08 #

    Quais são os problemas com o Backbone.js ?

  15. Daniel 26/09/2013 at 04:47 #

    Olá pessoal!

    Parabéns pela iniciativa do radar, vocês realmente são referência nacional no que se trata em desenvolvimento de software, inovação e criatividade.

    No meu trabalho substituímos todos os mavens que encontramos pela reta em projetos legados de Java (até mesmo para projetos JBPM) por gradles, e o resultado foi extremamente satisfatório.
    Ao meu ver, talvez ainda falte um pouco de ousadia da comunidade em experimentar algo novo e talvez, quem sabe, bater com a cara no muro. POR MIM, só uso Gradle agora… rs!
    Acho XML uma ferramenta extraordinária (mas é CHATAAAA DEMAISSS DA CONTA SÔ) o que torna o Maven, pra mim, algo terrivelmente tediante e chato de manter e, até mesmo configurar pela primeira vez no projeto. Sem falar que cada plugin adicionado é uma dor nova de cabeça.

    MAS como usamos Grails em nossos principais projetos (aqui se referindo a projetos como código) acabamos que deixamos o Gradle somente para os projetos legados ainda desenvolvidos em Java.

    Sei que a comunidade de Groovy/Grails no Brasil não chega a fazer tanto barulho assim, mas vocês já chegaram a dar uma olhada nessa linguagem e nesse framework?
    Pra quem trabalha em projetos onde há necessidade de lidar com código legado e evoluir rápido, usando a força de linguagens dinâmicas, como Ruby/Python, pode (como nós fizemos) optar por usar o Groovy e o Grails para ganhar força e manter o nível de integração.
    Sem falar em peso, porque JAVA EE num nenhum beija-flor, usar Groovy/Grails é uma saída de mestre para desenvolvimento ágil e alta produtividade em ambientes de convívio com código legado.

    Não vi nada sobre frameworks como AngularJS, knockout, Backbone, Ember etc. O que vocês pensam deles?

    Novamente, parabéns pela iniciativa, é MUITO bom ver que em nosso país tem gente boa pra caramba e, que leva “a coisa do desenvolvimento” a sério, como a galera da Thoughtworks.

  16. Lucas Oliveira 26/09/2013 at 08:07 #

    Parabéns pelo radar, como disse o Geilson esse cenário descrito é muito mais próximo da nossa realidade. Confesso que também estava esperando o gradle nas ferramentas de build. Tive boas experiências com ele, principalmente em multi projetos.

  17. Mauricio Aniche 26/09/2013 at 11:36 #

    Oi pessoal,

    Realmente algumas coisas não apareceram no Radar. Optamos por não colocar tudo aquilo que não tínhamos uma experiência razoável para discutir. Um bom exemplo é o Tsuru, da Globo.com, que tem recebido excelentes comentários, mas ainda não o utilizamos.

    Rafael,

    JSF está em adopt! Em nossa opinião, se precisa de um component-based framework, JSF é a opção.

    Um abraço,

  18. Raphael Almeida 26/09/2013 at 18:09 #

    Mto bacana essa iniciativa, espero que ela ajude outras empresas a criarem os seus.
    Tenho uma curiosidade, como vcs monitoram os micro services e como são tratadas as questões de segurança?

  19. Raphael 27/09/2013 at 14:25 #

    Ideia do CA$#$#$@#@$!

    Post muito bom..

    o Link para
    http://radar.caelum.com.br/set-2013#progressive-enhancement

    está quebrado!

    Ótimos assuntos para se discutir nos cursos

  20. Raphael 27/09/2013 at 14:31 #

    ah ok.. vi que não tem explicação sobre ele mesmo.

    sorry

  21. Renato Gama 02/10/2013 at 10:28 #

    E aí pessoal, gostaria de saber do ponto de vista de vocês quais são as “muitas limitações quando comparamos a soluções já estabelecidas em outras plataformas” para o Node.js! Abração, muito fera o radar, parabéns!

  22. Sérgio Lopes 03/10/2013 at 12:33 #

    @Renato: De maneira geral, o Node por ser mais novo ainda não tem a mesma maturidade de outras plataforma. Faltam ainda ferramentas, frameworks, facilidades etc.

    Em assuntos tecnicos especificos, um grande problema que vemos é o uso do Node como bala de prata, em todas as situacoes. Aí o modelo natural do Node (assincrono, single-threaded) pode atrapalhar muito na hora de resolver certos problemas. Voce precisa mudar toda forma de pensar seu projeto pra ser assincrono. E coisas simples em outras plataformas, como usufruir de uma maquina multi-core, se tornam bem mais dificeis no Node por ser single-threaded.

  23. Gamarra 04/10/2013 at 01:21 #

    Muito boa ferramenta. Dá um norte para todos os desenvolvedores. Obviamente que precisa de alguns ajustes, mas acredito que, em sua grande maioria, está retratando a realidade.

  24. Thiago 08/08/2014 at 16:26 #

    Não cobrando, mas não vai ter uma versão mais nova?

  25. Maurício Aniche 08/08/2014 at 19:24 #

    Oi Thiago,

    Vai sim. Já estamos trabalhando nisso! 🙂

    Um abraço!

Deixe uma resposta