Na última quinta-feira eu fui na palestra do Bruno Borges no RioJUG, sobre Apache Camel. A palestra em si foi bem legal, pois eu já conhecia um pouco do Apache Camel e pude ver algumas coisas a mais. Mas o ponto específico que eu quero abordar é um comentário que o Bruno fez, que diverge da minha postura em relação a open source.

Ele comentou que tenta sempre utilizar produtos Apache, evitando produtos open source que tenham vínculo com alguma empresa, como JBoss, SpringSource, entre outras. Não me recordo do motivo exato, mas a razão principal que ele explicou é o fato da Apache Software Foundation ser uma fundação composta de pessoas, em vez de ser uma empresa com fins comerciais.

Eu tenho uma postura diferente da dele em relação a open source. Eu gosto muito e tenho um respeito enorme pela fundação Apache. Já usei inúmeros produtos Apache e certamente continuarei usando por muito tempo. Entretanto, já usei vários produtos JBoss e vários componentes do Spring, e acho muito importante e saudável a existência dessas empresas.

A história do movimento open source tem vários elementos “românticos” e “filosóficos”, e essa característica ainda é muito presente em várias comunidades hoje em dia. Entretanto, com o crescimento do Linux, Java, Python, Ruby e outras tecnologias, existe hoje um mercado enorme de trabalho e negócios em torno do software livre.

O surgimento desse mercado naturalmente trouxe a participação de muitas empresas que vivem de software livre atualmente. Sei que há pessoas que enxergam open source e capitalismo como coisas opostas, mas na minha opinião essa visão é míope. Open source é um modelo de desenvolvimento de software e oferta de produtos e serviços. A busca do lucro é o que move nossas empresas, e isso não é diferente para quem atua com software livre.

O surgimento das empresas profissionais open source foi importantíssimo para o amadurecimento das tecnologias e dos profissionais. Se o movimento open source continuasse restrito ao meio acadêmico, o nível de competição no mercado de software seria muito menor, e o avanço tecnológico teria sido bem mais lento.

Além disso, minha postura profissional é de tentar sempre entregar os melhores resultados para os clientes e para a empresa em que trabalho. Em algumas situações pode ser mais adequado usar open source, em outras pode ser necessário usar software proprietário. Temos que nos adequar às necessidades dos clientes, em vez de esperar que eles se adeqüem às nossas preferências.

No meu ponto de vista, empresas como JBoss e SpringSource contribuíram e contribuem muito no processo de profissionalização do software livre. A existência delas criou um mercado fortíssimo em torno do software livre, e eu só tenho a agradecer por isso.

No momento atual, temos de 8 a 10 vagas, todas para início imediato e horizonte de longo prazo. Queremos profissionais que tenham paixão por software e auto-motivados, buscando evolução contínua. Profissionais deste perfil encontrarão um ambiente ótimo para seu crescimento dentro da Concrete. A descrição técnica dos perfis pode ser vista a seguir.

Os níveis de experiência são variados, então entre em contato se você se julgar dentro do perfil de profissional que buscamos. Quem quiser mais informações, não deixe de entrar em contato.

Desenvolvedor Java (preferencialmente com experiência em Web e/ou Mobile)

Java SE 5 e/ou 6. Java EE 1.4 e/ou 5.

JPA e/ou Hibernate são bastante desejáveis. Importante conhecer banco de dados relacionais e mapeamento objeto-relacional.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat  e Geronimo.

Struts, Spring MVC ou outro framework para web em Java. Boa experiência com Grails, Ruby on Rails ou Django também são válidos, e podem nos interessar mesmo se você não conhecer um framework web Java.

Inglês para leitura e estudo de material técnico.

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão ou Informática

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp.

Bons conhecimentos de client-side (HTML, CSS, Javascript) são muito positivos.

Conhecimento de plataforma Linux é desejável, mas não obrigatório.

Conhecimento em shellscripting para Unix/ Linux é muito bem-vindo.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Essa semana falei novamente sobre o assunto numa thread do CEJUG e então vou finalmente expôr algumas opiniões por aqui.

Provavelmente a implementação de persistência que está mais “na moda” atualmente é a Java Persistence Architecture (JPA) ou frameworks independentes com a mesma proposta, como o Hibernate e o Toplink. Realmente a proposta desta tecnologia é excelente. Quem programa usando orientação a objetos de verdade sempre prefere manipular classes de domínio ricas, e não gosta muito de lidar com as diferenças de paradigma que existem entre este modelo e o modelo relacional de bancos de dados.

A JPA aparentemente é bem fácil de usar, colocando anotações para mapear as classes e atributos em tabelas e colunas do banco de dados e colocando algumas anotações para declarar os relacionamentos entre as entidades. O problema que eu vejo é que as anotações de JPA são um tanto confusas. Em algumas situações você vê uma quantidade razoável de opções, e não fica tão óbvia a forma que você tem que usar as anotações.

Além disso, o esforço de analisar o comportamento da JPA é muitas vezes considerável. Você não escreve as queries, mas precisa acompanhar muito bem as queries que estão sendo geradas, se está sendo feito JOIN ou múltiplas queries, etc. Esse tipo de coisa a JPA abstrai da gente, mas muitas vezes os comportamentos não são triviais, e o esforço de monitorar isso não é desprezível. Uma anotação mal colocada pode te trazer problemas graves de performance e alguns dias de análise para otimização.

Eu gosto bastante da idéia de frameworks de mapeamento objeto-relacional. Quem trabalha verdadeiramente com orientação a objetos sempre quer ter a comodidade de usar este paradigma na aplicação toda. Entretanto, essas opções que temos em Java são complexas e muitas vezes não trazem ganhos de produtividade comparando com alternativas como o Ibatis por exemplo.

A parte mais chata da persistência em Java é escrever o código JDBC de gravação de objetos no BD e recuperação dos mesmos. Aqueles tratamentos altamente repetitivos e trabalhosos de conversão de colunas do BD de diferentes tipos para seus atributos das classes. Eu odeio escrever esse tipo de código, e o Ibatis ajuda demais nesse sentido, sem introduzir complexidade.

Uma coisa positiva que eu vejo no Ibatis é que ele é bem simples de usar e muito óbvio e previsível. Você manipula as coisas com o paradigma relacional, que embora tenha seus defeitos é amplamente conhecido de todo mundo e fácil de manipular. Usamos a DSL que é provavelmente a mais bem-sucedida até hoje (SQL).

A implementação de mapeamento objeto-relacional do Django (framework Python) por exemplo é excepcional, extremamente inteligente e produtiva. Muito dificilmente trocaria ela pelo Ibatis (assumindo que trocar fosse uma opção). Mas já há algum tempo eu estou desiludido com a JPA e vejo o Ibatis como uma opção com melhor custo-benefício.

Em situações em que o time todo domina plenamente JPA e já têm uma boa experiência com a mesma, é possível que o time ganhe um pouco de produtividade ao usá-la. Entretanto, em muitas situações o custo-benefício pode ser pior do que usar o Ibatis.

Já presenciei alguns casos em que a adoção de JPA em diferentes equipes prejudicou mais do que ajudou.  Os principais motivos para isso foram:

• Falta de experiência geral do time com a tecnologia
• Modelos legados de BD que não permitem um mapeamento de classes tão interessante
• Grande esforço de tunning

Eu e outros profissionais que eu respeito muito já passamos por esse tipo de situação, em que acabou prevalecendo o pragmatismo e a visão do que é valor para o negócio.

Eu li uma entrevista com o Carlos Ghosn (o brasileiro presidente da Renault e Nissan) na qual ele falou que a Nissan passou a ter bons resultados quando os engenheiros pararam de colocar ítens que eles achavam “bonitos” nos projetos, mas que os usuários nem percebiam. O argumento era mais ou menos esse: o usuário quer que o carro funcione bem, não importa para ele se o revestimento do motor vai ser de adamantium e resistente a criptonita

Decisões técnicas devem ser tomadas com foco no valor de negócio, em vez de focar na tecnologia que ficará mais bonita no currículo. Não esqueçam do exemplo do Carlos Ghosn

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

Este fim de semana o James Snell implementou um adapter do Apache Abdera para o CouchDB. Este adapter permite que se consiga facilmente implementar um armazenamento de dados no formato Atom com uso de uma instância do CouchDB.

Como eu já mencionei anteriormente, o Abdera oferece uma API para manipulação de conteúdo no formato Atom e a realização de operações do Atom Publishing Protocol. Já o CouchDB é um banco de dados orientado a documentos que é escrito em Erlang e foi projetado para extrema escalabilidade e permite fácil instalação em servidores com múltiplos núcleos ou em clusters de máquinas.

Em vez de utilizar tabelas com colunas (como os bancos de dados relacionais), o CouchDB armazena os documentos em formato JSON e disponibiliza como interface uma API Restful, com clientes já implementados em várias linguagens, como Javascript, Java, PHP, Ruby e Python.

Acho que isto expressa muito bem o horizonte que vem se formando. Em vez de pilha de tecnologias e protocolos proprietários, temos diversas tecnologias e plataformas diferentes conseguindo se comunicar através de HTTP. Um projeto open source Java que manipula conteúdo Atom já disponibiliza com facilidade um mecanismo de integração com serviços REST que manipulam dados em formato JSON.

É impressão minha ou estamos de fato vendo rapidamente uma mudança radical de abordagem na vanguarda da tecnologia? A mesma IBM que antigamente dominava de forma absoluta todo o mercado de hardware e software com soluções proprietárias agora patrocina diversos projetos open source e mantém sua elite intelectual trabalhando nestes projetos.

Soluções open source estão liderando várias frentes de desenvolvimento e com isso rapidamente surgem integrações entre componentes feitos em diferentes linguagens e plataformas. O conhecimento não está mais guardado a 7 chaves, e sim discutido abertamente por uma comunidade que aceita qualquer um com capacidade para agregar idéias boas.

A criatividade e a iniciativa individual nunca tiveram tanto poder, e isto é fabuloso. Com isso, claro que a versatilidade e o conhecimento diversificado ficam muito valiosos.

Hum… maybe it’s time for me to fight my disgust for Javascript and start developing something nice including JSON