Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

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.

Y tú, que opinas?

Ανακαλύψτε το.

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto "fraco" do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos "Web 2.0". O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de "Livros que quero ler quando tiver tempo", mas já o movi para a lista de livros que li :)

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve :)

Alguns anos atrás o TheServerSide era o meu site de tecnologia (e Java) preferido em geral. Muitas discussões interessantes rolavam por lá, tinha os Tech Talks, os simpósios, artigos, etc. Era muito bom para acompanhar o que estava acontecendo de importante na nossa área.

De uns tempos para cá, a qualidade do site despencou, e agora praticamente só noticiam coisas do tipo "XYZ was released". Onde XYZ podia ser qualquer coisa. Framework, servidor de aplicações, biblioteca, livro, qualquer coisa. Muito raramente eu vejo alguma coisa que me motive a ler mais do que o título.

Já o InfoQ traz diariamente várias coisas pelas quais me interesso. Tem tanto conteúdo de qualidade que eu não consigo acompanhar a velocidade de divulgação das coisas. E isso é ótimo, pois sempre sei que encontrarei coisas boas para ler por lá. Uma coisa que eu gosto no InfoQ é que nele eu vejo muita coisa boa além de Java. Conteúdo sobre metodologias de desenvolvimento, outras linguagens, outras plataformas. Novidades que podem me agregar bastante coisa. Quase todas as vezes que sai alguma notícia "XYZ was released" no TheServerSide eu não ligo a mínima pro que tá sendo lançado. E se é algo que me interessa, eu rapidamente viria a saber do lançamento em algum outro lugar.

Uma coisa que o InfoQ e o TheServerSide têm em comum é que ambos foram fundados pelo Floyd Marinescu. O TheServerSide foi fundado no final de 99, e o InfoQ no começo de 2006. Floyd Marinescu deixou o TSS em agosto de 2005, então muito provavelmente sua saída teve significativo impacto na qualidade do site. Atualmente o TSS é o 4o site da minha lista de preferências, atrás do InfoQ, Artima e DeveloperWorks. Mas do jeito que a coisa está indo não sei se ele vai conseguir sobreviver por muito tempo.

Especialmente depois que eu comecei a escrever artigos pra Java Magazine, eu passei a reparar bastante nas formas de exposição de conteúdo técnico. Conseguir cativar um público de alto nível é muito difícil. Desenvolvedores, arquitetos e gerentes de software não têm muito tempo para desperdiçar, pois a quantidade de coisas a estudar é enorme. Para conseguir que um público assim leia o que você se propõe a escrever, você precisa escrever de forma precisa, mas também estimulante. Se você simplesmente jogar informações nos leitores, não vai conquistar o apreço deles e eles não continuarão acompanhando as suas publicações.

Uma coisa que eu tento fazer nos meus artigos é sempre mostrar a motivação por trás do que estou falando. Especialmente se for um tema polêmico ou controverso, é fundamental estimular a discussão das pessoas. Ninguém gosta de ouvir a "Voz do Brasil", mas conheço muitas pessoas que gostam de ouvir a Band News, com a apresentação do Ricardo Boechat (eu sou uma dessas pessoas). Talvez as notícias presentes nos 2 programas sejam as mesmas. Entretanto, eu sempre me interesso pelas opiniões do Boechat, e eu nunca ouvi coisa mais enfadonha que a Voz do Brasil.

Comecei falando do InfoQ e terminarei falando sobre o mesmo. Este site é um belo exemplo de conteúdo técnico de qualidade, com temas que realmente atraem os leitores mais exigentes. O Floyd Marinescu parece uma excelente referência de como oferecer conteúdo para a nossa área.

Aos poucos venho começando a escrever meus artigos e também aqui no blog, e meu objetivo será sempre a linha do InfoQ. Conteúdo de qualidade com inteligência por trás. Quero escrever coisas que eu gostaria de ler se fosse outra pessoa escrevendo. Escrever bem é muito mais do que escrever corretamente. Espero conseguir atingir estes objetivos, e se possível ajudar a Java Magazine a ganhar cada vez mais qualidade. E é claro que sempre vou receber muito bem as críticas e opiniões de quem quiser colaborar nesta empreitada ;)

This is a blog set up only to blog about QCon London 2008 organized by Trifork and InfoQ. My name is Therese Hansen, and I will blog about the conference as I see it and contribute to the pool of blog posts from participants in QCon. I am from Denmark so please forgive me when I make writing errors.

The biggest downside of such a conference is that you cannot attend every session. There will be things that you miss out on even though it interests you. So I blog and others can read what I experience at the conference and I read other blogs to see what I missed.

I'll see you around at the conference

I recently had the pleasure to interview Dan Yoder, the creator of a new Ruby web framework called Waves.  Waves is a MVC framework, like that of Ruby on Rails but takes on some very unique ways of doing things and it piqued my interest.   I missed Waves when I wrote about 10 Alternative Ruby Web Frameworks recently and Dan pinged me to let me know about Waves.

Dan has leveraged existing technology were appropriate, such as:

• Markaby
• Erubis
• Sequel
• Mongrel
• Rack

It's great to see web frameworks being created for Ruby, a perfect example that the success of Rails continues to drive innovation.

You can read my interview with Dan on InfoQ and checkout the Waves feature list on the Waves web site.

The need to figure out dependencies before crisis hits

The main point here is that good software design heavily promotes resource abstraction. Databases become simple data sources that can be used without worrying about their whereabouts. So this makes dependency mapping an intricate task if it is not conducted in parallel to the development process. We have all sifted through lines and lines of J2EE thread dumps (to cite an extreme) in a moment of crisis to end up looking at 5 different configuration files and pinpoint exactly which resource is failing. Right there that requires someone who is familiar with application server internals and that someone is usually someone from the application development team rather than a system administrator.

Power crunch

Software does not get efficient quarter after quarter, rendering efforts on the hardware side negligible.

An active/active disaster recovery setup is often preferable to active/passive

The initial set-up cost in complexity and capital expenses is often by two critical factors:

1. active/active means that both sites are tested as opposed to a passive site, which you discover at the worst moment possible, won't be able to serve without configuration changes
2. active/passive failover is typically disruptive (lost sessions, etc.) so the business impact is higher

Another nicety of an active/active set-up is that, as you multiply the number of sites, each one requires less excess capacity to sustain the loss of 1 site. Set up 3 sites and each needs to have 150% of nominal capacity to absorb the loss of one; 4 sites means 133%, etc.

Developers have 2 groups of customers, real customers and the ops team

That is the gist of the "Release It!" book mentioned in an earlier post.

Some figures about eBay's current infrastructure

They use 5000 application servers running on commodity hardware and about 300 database servers running on mid-range Sun hardware.

Merb

My latest article is up on InfoQ talking about the latest Merb developments with Ezra Zygmuntowicz, Merb creator and founder of the Engine Yard.

As you read through the interview, understand an important point by Ezra:

Merb is a web application framework with many similarities to Rails.  The main difference is a focus on understandable, non-magic, fast code.

I think this is important for Merb as well as future Ruby frameworks, Ruby on Rails is the current killer application for Ruby.  Rails is the pioneer in Ruby web frameworks but it is not without faults.  Any pioneer knows there will be followers who imitate and duplicate their efforts to leverage their strengths and improve on their weaknesses.  In my opinion, Merb is a perfect example.  The Merb team decided what they did not like in Rails and created their own framework and avoided those problems, a perfect example of evolution in action.

I think we will see many Ruby frameworks looking to improve on Rails, improve on Merb and create better and better technology.  This is certainly exciting times in Ruby web development.

I think the interview gives some good insight to where the team is today with the implementation and where they need to be once they release IronRuby 1.0.  John was gracious in responding to my questions, even though he is extremely busy with this project.

It is an exciting time for Ruby developers whether you are on Linux, Mac or Windows and whether your company is committed to running applications on the Java Virtual Machine (JVM) or you are a Microsoft shop committed to .NET.  Very soon you will be able to take a Ruby application and run it anywhere.

There are some announcements coming from MIX08 in March from Microsoft we will not want to miss which will shed some more light on where IronRuby is in relation to the DLR and Silverlight.

I have some announcements coming of my own which I consider exciting as well but a bit too early to talk about.

Note: This is not intended to be a review, I may add one later.  One of the other .NET Editors at InfoQ is going to be publishing a complete review of NDepend 2.6, so I won't duplicate the effort.  I just wanted to show some parts of the application and what the output looks like.

Startup Screen

I began working with NDepend a few weeks ago when I started talking to Patrick.  NDepend has a nice start screen, much like that in Visual Studio 2008.

Project Loaded

Once the project is loaded the developer has access to the CQL (query language) window and find out many useful metrics about the assemblies being analyzed.  The Class Browser window looks a lot like Reflector.

The NDepend Report

The report produced once the assemblies are loaded up is proportional to the size of the project.  The project I analyzed was small and produced a large report.  Below is just the first page of the report created with NDepend 2.6.

I am looking forward to giving NDepend a project to run through the paces with and learn how to use the product better.

You can check out the full interview, Talking Rails 2.0 with David Heinemeier Hansson, at InfoQ.

... The promise is that if you adhere to REST principles while designing your application, you will end up with a system that exploits the Web’s architecture to your benefit. In summary, the five key principles are:

Give every “thing” an ID
Link things together
Use standard methods
Resources with multiple representations
Communicate statelessly ...

but, what is new on netbeans-6.0?

Editor Improvements

• Smarter code completion
• Highlights
• Better Navigation and Inspection
• Live Templates and Surround Functionality

Ruby/JRuby/Ruby on Rails Support

• Project support including Gems and RSpec
• Advanced Ruby Editing
• ActiveRecord Code Completion
• Ruby Debugger
• Ruby on Rails Support

Profiling

• Profiler integrated into NetBeans IDE
• Compare Memory Snapshots
• Heap Walker
• JMeter Integration
• Dynamic Attach on JDK 1.6

Web and Java EE

• Built-in visual design for web applications
• Visual page flow editing
• Enhanced JavaScript support
• Enhanced web services support
• Support for Ajax-enabled JavaServer Faces components

Mobility

• New Integrated UI for CLDC/MIDP and CDC development
• New game builder
• New Visual Mobile Designer
• Re-written JSR-172 stub compiler

SOA

• Artifacts for service composition and assembly
• Graphical WSDL editor
• XSLT editor to edit transformations.
• Tooling support for binding components
• Java EE Web Service project support

Check out NetBeans 6.0 Released with Support for Ruby, Mobility Enhancemens, and Integrated Profiles

I have been using this framework on some test projects to try to learn the .NET side of an MVC framework.  The talk with Hamilton was loaded with incite, thank you Hamilton for giving me the time.

I had the great opportunity to chat with Eric J. Smith of CodeSmith Tools, LLC to talk about their PLINQO templates that enhance Microsoft's LINQ to SQL.  These templates are an add-on to CodeSmith, which is a great code generation tool.

Please check out the article.

I wrote about my thoughts on InfoQ in the past.  I find their content focused and always relevant.

My first article is up on InfoQ, titled Promesh.NET - an MVC Web Framework for .NET.  It is a conversation I had with Philippe Leybaert the creator of ProMesh.NET, an MVC framework to create web applications on .NET.  It talks about the recently released ProMesh.NET into open source on CodePlex.  Please check it out.