Archive for April, 2008

Programadores de Schrödinger

Tuesday, April 29th, 2008

Donald Knuth deu uma entrevista para o InformIt esses dias que deu o que falar!

Como o Paulo Silveira comentou no GUJ, Knuth tem algumas opiniões controversas e polêmicas sobre testes unitários, eXtreme Programming, Open Source e programação concorrente. O Phillip Calçado também comentou o assunto, referindo-se a opinião do Keith Braithwaite, que tem ótimos pontos.

Sobre testes unitários em particular, Knuth fala o seguinte:

[...] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

Basicamente ele parece não acreditar em testes unitários.

O problema é que hoje em dia, além da complexidade da programação em sí, é necessário lidar com a complexidade do domínio do software, com o fato de que as empresas devem responder rapidamente às mudanças (e o software deve acompanhar), o fato de que não existem “desenvolvedores solo” mas sim equipes de desenvolvimento e por aí vai. Por isso é essencial que os softwares sejam bem testados e que esses testes sejam executados constantemente para garantir o bom funcionamento do sistema ao longo dos incrementos que serão feitos durante seu ciclo de vida. Mesmo com todas essas precauções, como bem disse o Phillip, se nos dias de hoje alguém ou alguma empresa pagasse $2.56 por cada bug encontrado nos seus programas (como faz o Knuth), provavelmente já estaria falida. Já imaginou então se não houvessem os testes como que seria?

Convenhamos, o caso do Knuth é um caso a parte. Ele está na ativa desde os anos 60 quando nossos pais ainda eram adolescentes, e possivelmente por isso tem práticas e opiniões que não necessariamente se aplicam às situações de hoje. É claro que ele merece todo o respeito por tudo que ele fez e faz pela computação, mas não acho que a opinião dele sobre práticas ágeis em especial possa ser levada em consideração ao pé da letra. E o que mais me preocupa nisso tudo é que, por ele ser um ícone da computação, as pessoas tomem tudo que ele falou como verdade absoluta e comecem a achar que testes unitários não servem para nada, quando na verdade eles são essenciais para qualquer programador profissional!

Para mim, os programadores que não testam poderiam ser chamados de Programadores de Schrödinger.

Falo isso por causa da teoria do Gato de Shrödinger. Resumindo a história, o físico Erwin Schrödinger uma vez sugeriu que se puséssemos um gato numa caixa fechada, onde a vida do gato dependesse do estado de uma partícula sub-atômica, haveria uma superposição de estados que faria com que, do ponto de vista da mecânica quântica, o gato estivesse vivo e morto ao mesmo tempo até que a caixa fosse aberta. Seria impossível determinar o seu estado até abrir a caixa! Na minha imaginação eu fico pensando no momento que a caixa é aberta e aparece um gato vivo (ou morto) o que aconteceu com o outro gato… Provavelmente ele está em algum outro universo paralelo onde todas as coisas são ao contrário (e as pessoas acham guarda-chuvas ao invés de perdê-los). Enfim, não se sabe de forma alguma o que pode acontecer.

Finalizando toda essa viagem, os Programadores de Schrödinger simplesmente não sabem o que vai acontecer quando o seu sistema entrar em produção. Pode ser que nenhum bug apareça e que eles fiquem ricos e comprem milhares de jatos particulares. Ou não.

Na dúvida, eu escrevo testes. :)

We’re hiring!

Wednesday, April 23rd, 2008

Mais uma vez estamos contratando na Globo.com!

As vagas são para as equipes responsáveis pelos portais de vídeo e conteúdo líderes em audiência no Brasil, que diariamente são submetidos à prova por vários milhões de visitantes.

Não estamos procurando especificamente desenvolvedores Java, nem PHP, Python, C ou C++. Aqui nós usamos de tudo e estamos procurando profissionais capazes de usar a melhor ferramenta para cada problema. É óbvio que cada um tem suas especialidades e preferências, mas estamos procurando programadores multidisciplinares e que além disso sejam capazes não só de programar mas de arquitetar, analisar, testar e trabalhar com novas tecnologias o tempo todo. Mesmo assim, fortes conhecimentos em Java, PHP e/ou C são um grande diferencial.

Como trabalhamos com Internet, também é muito bom ter conhecimentos em Javascript, CSS, HTML e esse tipo de coisas. Programadores capazes de fazer mashups usando APIs e muito AJAX são altamente desejados.

Nosso time trabalha de forma ágil, usando Scrum e várias práticas de Extreme Programming. Nosso lema é qualidade – nós não viramos noite e mesmo assim entregamos software no prazo, testado e funcionando muito bem, obrigado. Por isso estamos procurando pessoas comprometidas, organizadas e que saibam trabalhar muito bem em equipe para entregar software de qualidade.

Aqui você trabalhará e/ou terá contato com webservices REST e SOAP, Atompub, Apache, JBoss, JBossWeb, Tomcat, Weblogic, plataformas de encoding de mídias, HTML/CSS, Javascript, Flash, AJAX, Java, Ruby on Rails, PHP, Perl, C, C++, Linux, Open Solaris, Shellscript, Oracle, MySQL, Memcached, Selenium, CruiseControl, FIT/Fitnesse, JUnit, JMock, OpenSocial, Capistrano, Hibernate/JPA, Spring, dentre muitas outras coisas. Trabalhamos com aplicações de alta disponibilidade em ambientes clusterizados e otimizadas para máxima performance. É uma empresa de ponta e temos que estar sempre trabalhando com as tecnologias mais novas e interessantes.

E por último mas não menos importante, todos nós somos nerds, geeks, apaixonados por tecnologia e super atualizados com as últimas novidades da Internet e do mercado. Nossa equipe é jovem, irreverente, descontraída e em constante evolução. São pessoas exatamente assim que estamos procurando.

A empresa oferece contratação apenas por CLT, com salário de mercado e plano de benefícios. Estamos localizados na Barra da Tijuca (Rio de Janeiro).

Se você acha que se enquadra, mande um email para mim (gc at corp.globo.com) com seu currículo os nomes dos 3 últimos livros técnicos que leu.

[FISL 9.0] Balanço do evento

Monday, April 21st, 2008

O FISL foi excelente! Eu não assisti tantas palestras porque fiquei grande parte do tempo no stand da Globo.com ou andando por aí conhecendo pessoas, mas as palestras que eu fui foram bem legais! Queria ter ido em várias outras mas foi impossível… Teve muita coisa boa.

Agora, o melhor do evento certamente não foram as apresentações. Conheci uma porção de gente que até hoje só tinha falado pela Internet, foi sensacional!

Para começar, conseguimos juntar nossa turma: Rodrigo Kumpera (que falou mal até dele mesmo na sua palestra e sempre me faz sentir um idiota quando fala trezentas coisas que eu não entendo), Diego Plentz (que é fã de Chitãozinho e Xororó), Fernando Meyer (o gaúcho português de São Paulo), Fabio Kung (que me mostrou como obrigar pessoas a aprender Lisp). Juntos com o Tiago Motta (que fica bêbado com Coca-Cola), nós destruímos as churrascarias gaúchas! O José Peleteiro também nos acompanhou no segundo dia e nos ajudou a convencer o Kung a ir pra Globo.com (calma Paulo, é brincadeirinha)! Batemos altos papos no stand da Globo.com, só faltou mesmo o Tiago Peczenyj levar o chimarrão!

Também foi ótimo ter conhecido a galera do JavaFree, especialmente o Vitor Pamplona, Dalton de Camargo e Daniel F. Martins. Também conheci gente nova como o Luiz Metzger, Ricardo Ogliari e Júlio César.

Bati um bom papo com o Carlos Eduardo da e-Genial, que andava meio sumido na Internet mas está voltando com força total. Ele ainda fez o favor de levar o Vinícius Teles da Improve It pra falar com a gente no stand. Moramos na mesma cidade, já trocamos vários e-mails, telefonemas e tudo mais mas foi preciso ir pra POA para nos conhecermos! Também conheci o Sylvestre Mergulhão, o mais novo membro da trupe da Improve It.

Além disso conheci um mundo de pessoas, dentre elas o Rodrigo Urubatan (gente finíssima), Fernando Boaglio, Luis Eduardo Bohrer, Jony Kostetzer e mais um monte de pessoas que infelizmente não lembro o nome. Só faltou mesmo o Fabio Akita (acabamos não conseguindo falar direito mas não faltarão oportunidades)!

E por último mas não com menos importância, gostaria de deixar registrado meu agradecimento pessoal e meu orgulho em trabalhar na Globo.com com gente tão talentosa, que acreditou no evento e levou quase 20 nerds para conversar e jogar videogame com a galera do FISL, especialmente ao Marco Lucio de Figueiredo Moreira (nosso Gerente de Tecnologia), Renata Rocha e Patricia Cavalcante, que trabalharam pesado na organização do evento. Nós somos d+! A partir de agora podem esperar nossa presença nesses eventos com força total!

Agradeço também ao pessoal que assistiu minha apresentação sobre Desenvolvimento Ágil com XP e Scrum, que elogiou e que foi lá no stand para conversar. Estava muito tumultuado e não consegui dar a atenção que gostaria para todo mundo, mas se ficou alguma coisa em aberto, entrem em contato para conversarmos!

O Vinícius Teles criou o grupo “Amigos do FISL” no Just-remind.us. Entrem em contato comigo ou com ele para pegar a senha :)

É isso aí galera, parabéns a todos nós que fizemos o evento ser um show!

[FISL 9.0] Desenvolvimento Ágil com XP e Scrum

Sunday, April 20th, 2008

Scrum no FISLOntem, no último dia do Fórum Internacional de Softwre Livre, fiz minha apresentação sobre Desenvolvimento Ágil com XP e Scrum, um assunto muito interessante que está se tornando cada vez mais popular nos últimos meses. A sala estava lotada, muita gente nem conseguiu entrar (fotos no Flickr)!

Infelizmente os 40 minutos não foram suficientes para falar tudo que eu queria/deveria e a apresentação ficou meio corrida… Então, como prometí, estou disponibilizando os slides da apresentação sob a licensa Creative Commons 2.5 para quem quiser dar uma olhada com mais calma.

Desenvolvimento Ágil com XP e Scrum
View SlideShare presentation or Upload your own. (tags: xp scrum)

Além disso, seguem alguns ponteiros para quem quiser estudar mais sobre o assunto:

Livros recomendados

Blogs sobre “Agile”, Scrum e XP

Links

[FISL 9.0] Globo.com no FISL!

Thursday, April 17th, 2008

globo.com no FISL Já estamos aqui no FISL preparando o stand da Globo.com para receber a galera.

Apareça aqui para batermos um papo sobre software livre, desenvolvimento e arquitetura de sistemas, ou então só pra jogar um video game mesmo. Aliás, quem conseguir me ganhar no futebol do Xbox ou no tênis do Wii está semi-contratado :)

Update: veja fotos do evento no meu Flickr.

Portfólio intelectual

Saturday, April 12th, 2008

A discussão sobre livros e carreira foi acesa novamente, especialmente depois que escreví um post com indicações de alguns livros importantes para desenvolvedores. Recebí uma meia dúzia de e-mails perguntando sobre outros tipos de coisas que podem ser feitas para alavancar a carreira e até mesmo perguntando se existe algum remédio para ficar acordado e poder estudar mais :)

Não tem muito segredo, basta você encarar sua vida profissional da forma apropriada. Existem várias formas de fazer isso, e uma delas é pensar que você tem que manter o seu portfólio intelectual. No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt apresentam esse conceito interessante que tenho usado há algum tempo:

Your Knowledge Portfolio

Your knowledge and experience are your most important professional assets. Unfortunately, they’re expiring assets. An expiring asset is something whose value diminishes over time. Examples include a warehouse full of bananas and a ticket to a ball game. Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the speed at which Web-years fly by, this can happen pretty quickly.

As the value of your knowledge declines, so does your value to your company or client. We want to prevent this from ever happening.

We like to think of all the facts programmers know about computing, the application domains they work in, and all their experience as their Knowledge Portfolios. Managing a knowledge portfolio is very similar to managing a financial portfolio:

  • 1. Serious investors invest regularly—as a habit.
  • 2. Diversification is the key to long-term success.
  • 3. Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
  • 4. Investors try to buy low and sell high for maximum return.
  • 5. Portfolios should be reviewed and rebalanced periodically.

To be successful in your career, you must manage your knowledge portfolio using these same guidelines.

Building Your Portfolio

  • Invest regularly. Just as in financial investing, you must invest in your knowledge portfolio regularly. Even if it’s just a small amount, the habit itself is as important as the sums. A few sample goals are listed in the next section.
  • Diversify. The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don’t stop there. The face of computing changes rapidly—hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.
  • Manage risk. Technology exists along a spectrum from risky, potentially high-reward to low-risk, low-reward standards. It’s not a good idea to invest all of your money in high-risk stocks that might collapse suddenly, nor should you invest all of it conservatively and miss out on possible opportunities. Don’t put all your technical eggs in one basket.
  • Buy low, sell high. Learning an emerging technology before it becomes popular can be just as hard as finding an undervalued stock, but the payoff can be just as rewarding. Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field.
  • Review and rebalance. This is a very dynamic industry. That hot technology you started investigating last month might be stone cold by now. Maybe you need to brush up on that database technology that you haven’t used in a while. Or perhaps you could be better positioned for that new job opening if you tried out that other language….

Of all these guidelines, the most important one is the simplest to do:

Tip: Invest Regularly in Your Knowledge Portfolio

Goals

Now that you have some guidelines on what and when to add to your knowledge portfolio, what’s the best way to go about acquiring intellectual capital with which to fund your portfolio? Here are a few suggestions.

  • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.
  • Read a technical book each quarter. Bookstores are full of technical books on interesting topics related to your current project. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project.
  • Read nontechnical books, too. It is important to remember that computers are used by people—people whose needs you are trying to satisfy. Don’t forget the human side of the equation.
  • Take classes. Look for interesting courses at your local community college or university, or perhaps at the next trade show that comes to town.
  • Participate in local user groups. Don’t just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.
  • Experiment with different environments. If you’ve worked only in Windows, play with Unix at home (the freely available Linux is perfect for this). If you’ve used only makefiles and an editor, try an IDE, and vice versa.
  • Stay current. Subscribe to trade magazines and other journals (see page 262 for recommendations). Choose some that cover technology different from that of your current project.
  • Get wired. Want to know the ins and outs of a new language or other technology? Newsgroups are a great way to find out what experiences other people are having with it, the particular jargon they use, and so on. Surf the Web for papers, commercial sites, and any other sources of information you can find.

It’s important to continue investing. Once you feel comfortable with some new language or bit of technology, move on. Learn another one.

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas. Get familiar with object orientation, for instance, and you’ll write plain C programs differently.

Opportunities for Learning

So you’re reading voraciously, you’re on top of all the latest breaking developments in your field (not an easy thing to do), and somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much.

Don’t let it stop there. Take it as a personal challenge to find the answer. Ask a guru. (If you don’t have a guru in your office, you should be able to find one on the Internet: see the box on on the facing page.) Search the Web. Go to the library. In this era of the Web, many people seem to have forgotten about real live libraries filled with research material and staff.

If you can’t find the answer yourself, find out who can. Don’t let it rest. Talking to other people will help build your personal network, and you may surprise yourself by finding solutions to other, unrelated problems along the way. And that old portfolio just keeps getting bigger….

All of this reading and researching takes time, and time is already in short supply. So you need to plan ahead. Always have something to read in an otherwise dead moment. Time spent waiting for doctors and dentists can be a great opportunity to catch up on your reading—but be sure to bring your own magazine with you, or you might find yourself thumbing through a dog-eared 1973 article about Papua New Guinea.

Critical Thinking

The last important point is to think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate and unswayed by either vendor or media hype. Beware of the zealots who insist that their dogma provides the only answer—it may or may not be applicable to you and your project.

Never underestimate the power of commercialism. Just because a Web search engine lists a hit first doesn’t mean that it’s the best match; the content provider can pay to get top billing. Just because a bookstore features a book prominently doesn’t mean it’s a good book, or even popular; they may have been paid to place it there.

Tip: Critically Analyze What You Read and Hear

Unfortunately, there are very few simple answers anymore. But with your extensive portfolio, and by applying some critical analysis to the torrent of technical publications you will read, you can understand the complex answers.

Challenges

  • Start learning a new language this week. Always programmed in C++? Try Smalltalk or Squeak. Doing Java? Try Eiffel or TOM.
  • Start reading a new book (but finish this one first’) If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book on coding techniques.
  • Get out and talk technology with people who aren’t Involved in your current project, or who don’t work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local user’s group meeting.

Esse livro é muito bom e tem várias outras dicas importantes como essa que te fazem abrir a cabeça e pensar de formas diferentes. Se você ainda não tem, vá na Amazon agora e compre! (eu não estou ganhando comissão por isso)

Scrum Master técnico?

Sunday, April 6th, 2008

Há algum tempo que tenho pensado muito sobre o que um Scrum Master pode/deve ou não fazer dentro de uma equipe Scrum.

Lendo vários livros e artigos sobre o assunto, percebi que todos eles enfatizam várias características do Scrum Master. Ele deve ser influente dentro da empresa, corajoso, comprometido com o projeto, deve ajudar o time a entender as práticas do Scrum e assegurar que elas não sejam violadas, dentre outras coisas.

O Scrum Master não precisa ser técnico. Todas as tarefas principais exigidas pela função podem perfeitamente ser realizadas por uma pessoa sem nenhum conhecimento técnico. Porém isso não significa que é ruim quando ele tem conhecimento técnico e usa-o em favor do time ou do projeto. Mais do que isso, acredito fortemente que os melhores Scrum Masters necessariamente devem ter conhecimento técnico e do negócio, pois isso os ajuda a entender melhor os problemas do projeto e ajudar melhor o time.

Essa não é uma opinião só minha. Mike Cohn, um dos grandes nomes do mundo ágil, escreveu no ano passado um artigo sobre o que ele considera que sejam as seis principais características dos melhores Scrum Masters. Uma dessas características é:

Knowledgeable

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.” Lockhart, K. 2006. Responsibility Junkie. Harvard Business Review (October): 30.

A princípio o Scrum Master não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Primeiro, porque impedirá que ele se concentre em resolver os impedimentos e problemas que estão no caminho do time, que no início da adoção são muitos e muito graves. Segundo, porque ele pode acabar tirando o compromisso do time. Ele pode acabar tomando decisões que nem todos concordam exatamente, mas farão porque alguém acima na hierarquia determinou e aí voltamos ao gerenciamento command-control onde as pessoas só fazem o que são mandadas. Para evitar esses problemas, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca e que se concentre em cuidar só disso.

Porém, vejo que depois de um certo tempo o time e o Scrum Master se adaptam tanto à empresa e a forma como ela trabalha (assim como a empresa se adapta às necessidades do time) que o time precisa cada vez menos do Scrum Master. Ele continuará sendo necessário na hora em que aparecerem problemas fora do alcance do time, mas penso que isso aconteça na menor parte do tempo e cada vez menos. O time e a empresa amadurecem sua relação e evoluem tanto que o time entra num ritmo de alta produtividade e sofre cada vez menos interferências.

E quando isso acontecer o Scrum Master deverá ficar sentado esperando o próximo problema/impedimento a ser resolvido? Certamente isso não seria bom para a empresa.

Todos os Scrum Masters ou líderes de projeto que conheço são pessoas excelentes tecnicamente. Muito modestamente e humildemente falando, eu me incluo neste grupo. Eu e todos esses líderes/Scrum Masters que conheço chegaram nesta posição por terem sido ótimos técnicos e se destacarem entre os demais. Como é que se pode ignorar este fato e pedir que eles simplesmente deixem de fazer o que mais sabem? Porque o Scrum Master não pode trabalhar com impedimentos técnicos? Ou programar? Desde que se concentre primariamente em exercer seu papel de Scrum Master, que não atrapalhe o time e que não atrapalhe o projeto, é totalmente aceitável que ele faça isso. Aliás, nenhum livro sobre Scrum fala o contrário.

Hoje, por exemplo, eu diria que uso metade do meu tempo exercendo ativamente o papel de Scrum Master. Na outra metade, eu não fico parado esperando o próximo problema acontecer.

No último Sprint do meu time, por exemplo, trabalhei para resolver um impedimento técnico gigantesco do próximo Sprint. Estamos no meio de um projeto importante para a empresa e a história que talvez seja a mais importante de todas acabou ficando de fora do Sprint. Já é certo que ela será a primeira história do próximo Sprint, porém, existe um grande impedimento técnico relacionado à forma como funciona uma API de busca interna da empresa, e eu trabalhei para contornar este problema e o time possa trabalhar tranquilamente na próxima semana. Outro exemplo, foi quando parei uns três dias para reconfigurar todo nosso ambiente de integração contínua e fazer um refactor agressivo no build. Ou então, para não desfocar o time do seu trabalho, eu resolvo silenciosamente vários bugzinhos chatos.

Muitas pessoas discordam dessa atitude simplesmente porque eu tive que codificar alguma coisa. Mas eu não estou facilitando o trabalho do time? Não estou resolvendo problemas e fazendo com que o time só precise se concentrar em entregar seu trabalho? O Scrum é um framework onde a cada período de desenvolvimento temos oportunidade de avaliar o que fizemos e nos adaptarmos às circuntâncias do projeto/time/empresa. Refletindo sobre o meu trabalho, percebi que se eu me adaptasse para trabalhar desta forma poderia contribuir muito mais com o time e a empresa do que simplesmente fazendo o feijão-com-arroz do Scrum.

Coincidentemente (ou não), o Phillip Calçado escreveu um post que vou usar como argumento para outro ponto importante. O manifesto ágil, base para todas as metodologias ágeis que conhecemos, coloca pessoas acima do processo. Ou seja, o processo importa menos do que as pessoas que participam dele. Parafraseando o Phillip, você não pode fazer que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor (ou Scrum Master) completamente desestimulado e frustrado na equipe. Mais ainda, você não pode fazer com que o processo deixe de lado pessoas técnicas altamente capazes.

A verdade é que não existe uma regra. Você faz a regra, mas faça com consciência e sabedoria.

FISL 9.0, aí vou eu!

Friday, April 4th, 2008

No próximo dia 17 estarei no 9o. Fórum Internacional de Software Livre, um dos maiores eventos nacionais de tecnologia!

Nesse ano a Globo.com será uma das empresas patrocinadoras do evento, e eu estarei lá no nosso stand para conversarmos sobre o que temos e o que fazemos aqui. Muita gente não faz idéia do que tem por trás de um dos maiores portais da Internet brasileira, e garanto que se surpreenderão quando souberem como uma empresa tão tradicional e com tecnologia de ponta pode basear a grande maioria dos seus produtos em software livre.

Apareça lá para batermos um papo! :)