Sempre gostei de vídeo-games. Alias, lá no começo de tudo, a maior parte do tempo que eu passava na frente do MSX lá de casa era pra jogar. E continuou assim com meu primeiro PC (um 386 DX 40 MHz!). Entre o MSX e o 386 eu também tive um Phantom System. Fantástico também (para a época)!

Mas, de uns tempos para cá, por causa do meu trabalho, acabei tendo que entrar em contato com esta área dos vídeo-games sob um outro ponto de vista que se tornou, para mim, tão fascinante como aquele que eu tinha quando eu era apenas um “viciado” por jogos eletrônicos.

Este outro ponto de vista me levou a perceber coisas que, até então, apesar de parecerem naturais, não pareciam ter ligações entre si. Por exemplo, todo mundo sabe que a computação eletrônica vem evoluindo de maneira frenética nos últimos 20 anos ou mais, para não dizer desde que foi inventada. Também é meio que consenso geral que a evolução da computação, dentre outras coisas, é dirigida por necessidade de maior poder de processamento, afinal não faria sentido se aumentar o poder de processamento se não existem problemas que requeiram tal poder ou se não somos capazes de criar problemas para requererem este poder de processamento (não dizem que a computação veio para resolver os problemas que ela mesmo criou?). E ai chegamos no ponto que eu queria chegar: dentre as aplicações usadas por um usuário doméstico, quais são aquelas que, em geral, precisam de maior poder de processamento?… Jogos! Seja porque tentam renderizar gráficos com cada vez mais detalhes, seja porque tentam implementar inteligências artificiais cada vez mais complexas ou seja porque tentam criar novas formas de iteratividade com o usuário, jogos requerem um grande poder de processamento.

O poder de processamento de consoles de vídeo-games sempre foi relativamente grande se comparado com o poder de processamento de PCs. É claro que esta não é um comparação totalmente justa porque os consoles de vídeo-games não podem ser estritamente descritos como computadores de propósito geral e, por causa disso, é claro que eles sempre ganham em performance na execução de jogos quando comparados com os PCs. Mas é certo também que depois do meio da década de 1990 os PCs melhoraram bastante sua performance na execução de jogos. E, mais do que isso, parece que estamos vendo nascer uma nova indústria de consoles de vídeo-games onde o console começa a se misturar com o PC e vice-versa.

A entrada da Sony no mercado de consoles vídeo-games no meio da década de 1990 e, depois, da Microsoft no início dos anos 2000 mudaram definitivamente o rumo do mercado de consoles de vídeo-games no mundo. As duas desbancaram os fabricantes tradicionais de consoles, dos quais só sobrevive ainda hoje a Nintendo. Além disso, a entrada de ambos neste mercado marcou o início da era dos consoles que não apenas rodam os jogos mas também são capazes de muitas outras coisas.

Dos consoles atuais (de sétima geração), pelo menos dois deles apostam no aumento do poder de processamento como meio de se emplacarem no mercado. O XBox 360 da Microsoft e o PlayStation3 da Sony possuem processadores multi-core agressivos. Eles atacam nas frentes que já citei anteriormente: gráficos cada vez mais perfeitos e jogos cada vez mais inteligentes. Além disso, toda esta capacidade de processamento está tornando possível a criação de ambientes mais reais, já que o poder de processamento extra torna possível um processamento mais fino da física do jogo. Os raios de sol nestes consoles refletem nos vidros, a gravidade existe de forma mais parecida com aquilo que vivenciamos no nosso dia-a-dia e a água ondula de verdade quando jogamos uma pedra num lago.

É claro que tudo isso é muito legal, mas estes consoles vão ainda mais longe. Na minha opinião, eles querem se tornar as verdadeiras centrais de entreternimento das casas. Com tanto poder de processamento, estes consoles são capazes de tocar música e vídeos, servir como ponto de interconexão de dispositivos em rede na casa, navegar na Internet, permitir a conexão de TVs digitais e muito mais. Ah, sim, antes que eu me esqueça, eles são capazes de rodar jogos também!

Estes consoles tentam também emplacar novas tecnologias de mídia como o Blue-Ray, da Sony, que é padrão no PlayStation3, e o HD-DVD, apoiado pela Microsoft, que não é padrão no XBox 360 mas que pode ser conectado ao console.

Correndo por fora neste mercado, temos o Wii, console de sétima geração da Nintendo. Ele não possui um processador tão poderoso quanto o dos outros consoles, mas ele aposta numa nova forma de interação com o usuário que tem tudo para ser matadora neste mercado. Se os outros saem ganhando quando eles tentam ser a central de entertenimento da casa, o Wii sai ganhando por ser o console com melhor interatividade. A nova forma de interação com o usuário criada pelo Wii não é só inovadora, mas ela também justifica o que já citamos antes: ela também necessitou que houvesse um salto no poder de processamento dos consoles da Nintendo entre a sexta e a sétima geração para suportar, dentre outras coisas, este novo paradigma de interatividade. Mais ainda, ela também leva à evolução da computação de uma forma geral já que propõe novas formas de interação com sistemas de computação, se levarmos em conta que ela pode ser usada para outros sistemas que não sejam jogos.

Eu prentendo, mais pra frente, analisar mais a fundo pelo menos dois destes novos consoles de vídeo-games pois eu julgo que eles trazem inovações que irão afetar de forma definitiva a computação em geral e não só no mercado de vídeo-games nos próximos anos. Mas de qualquer forma, queria compartilhar com vocês esta minha percepção de que os vídeo-games são um dos grandes responsáveis pela evolução da computação pessoal nos últimos 10 a 15 anos, eu diria.

É claro que eu acredito que o que já citei neste post serve de prova para a ligação entre os vídeo-games e a inovação na computação, mas querem um outro argumento sobre porque eu acho que o mercado de consoles de vídeo-games está cada vez mais ligado ao mercado de computadores pessoais e à evolução da computação de uma forma geral? Sabem quem é o fabricante dos processadores dos três vídeo-games de sétima geração existentes?… A IBM, uma especialista em fazer processadores para servidores corporativos de alta capacidade de processamento e uma das maiores inovadoras nesta área.

Seguindo a linha do post anterior, queria falar sobre uma outra forma de interatividade que, de certa forma, é parecida com a anterior por usar alguns conceitos semelhantes mas na prática se mostra totalmente inovadora e diferente.

O Reactable, definido pelos próprios autores como uma “multi-user electro-acoustic music instrument with a tabletop tangible user interface” pode ser visto como um sintetizador modular (se olharmos para ele como um instrumento musical) ou até mesmo como uma linguagem de programação de controle de fluxo (se olharmos ele como um representante fiel de sistemas de controle movidos a sinais elétricos que dão origem a muito daquilo que conhecemos de robótica e computação).

Vou postar aqui alguns vídeos que na minha opinião valem serem assistidos para entender completamente o conceito sendo explorado. O sistema é simples. Basicamente uma câmera posicionada abaixo de uma mesa que captura os objetos que são colocados em cima da mesa e os movimentos que são feitos nos objetos. O resto dos efeitos e controles é feito por luzes e por um sistema computacional de controle. Depois de mostrar os vídeos tento comentar alguma coisa em cima do que pode ser visto neles, mas, como vocês vão ver, nada melhor mesmo que os vídeos para explicar o Reactable.

Como se pode ver pelos vídeos, o Reactable é, antes de mais nada, um sintetizador musical, um instrumento musical. E desta forma, como se pode ver por uma simples busca na internet, já foi usado em algumas festas na Europra. Imagina um que um bom DJ não conseguiria fazer com uma interface destas? Além do show musical, certamente seria um show a parte as imagens da manipulação do Reactable.

Por outro lado, como também é possível ver pelos vídeos, o Reactable nada mais do que reproduz um sistema de controle, no qual você pode compor suas ondas geradoras, retroalimentações, filtros de freqüência e etc. de forma a montar um sistema de controle. E, neste sentido, ele não deixa de ser uma linguagem de programação. Só que com uma interface muito mais intuitiva e com uma capacidade de mostrar o resultado da atuação do sistema de uma forma que realmente dá para visualizar a resposta antes de, por exemplo, ter que implementar um sistema de controle com as mesmas características para controlar um braço mecânico de um robô de uma linha de montagem.

Olhando por outro lado, também consigo ver nele uma tremenda e inovadora ferramenta educacional. Há se meus professores de física, sistemas de controle e telecomunicações tivessem acesso e disposição para usar uma ferramenta dessas durante as aulas! Certamente os conteúdos que, em geral são complexos e difíceis de entender por envolverem o espaço de freqüências, convoluções e etc. poderiam ser muito melhor compreendidos pelos alunos em um tempo bem menor!

E, ainda assim, se esquecermos tudo isso e voltarmos ao tópico sobre o qual estávamos falando originalmente, o Reactable nos mostra, de forma contundente, uma nova forma de interação homem-máquina que dá maior poder de expressão e de visualização de resultados para as pessoas que estão interagindo com o computador. É claro que vocês podem estar pensando como uma coisa como o Reactable poderia se aplicar na vida de uma pessoa comum, que usa o computador para navegar na internet e ler e-mails. Neste sentido, talvez a utilidade do multi-touch screen seja mais fácil de se enxergar. Mas não podemos de forma alguma descartar coisas como o Reactable, já que conceitos como este podem tornar possível, por exemplo, a apresentação de um objeto físico real (que não seja um quadradinho de plástico com um símbolo desenhado como nos exemplos) a um computador. Vocês já imaginaram nas possibilidades que podem se abrir se um computador conseguir a efetivamente reconhecer objetos e/ou pessoas que são apresentados a eles?

Depois de um tempo meio sumido, estou finalmente de volta! Espero não ficar tanto tempo assim longe do blog novamente.

Para voltar, queria falar sobre um assunto sobre o qual já postei no nosso blog (ainda no endereço antigo, no ano passado) mas que voltou à minha cabeça recentemente. Vou recolocar o vídeo aqui para quem não viu ou não lembra.

[youtube=http://www.youtube.com/v/nfVnwdda9Pw]

Neste e nos próximos posts eu queria falar um pouco sobre as novas formas de interação com computadores que estão surgindo nos últimos tempos.

Quando postei este vídeo o ano passado, a única coisa que me vinha à cabeça na época era: “que massa!”. Como bom apreciador de tecnologia eu achei o vídeo o máximo e a tecnologia mostrada algo inovador e capaz de quebrar paradigmas!

No entanto, mais recentemente, por força do meu trabalho atual, venho também analisando outros aspectos relacionados à interatividade homem-máquina e me veio a cabeça que são coisas deste tipo que vão nos fazer sair do marasmo criado há mais de 20 anos quando a última grande inovação tecnologica na interação entre homens e computadores saiu do forno: o mouse.

É claro que depois disso muitas outras coisas foram inventadas, mas nada ainda é realmente tão efetivo como um teclado e um mouse. E acho que isso em breve poderá mudar.

Finalmente estamos vendo se tornarem realidade novas formas de interação com os computadores que dão gosto de ver e de usar. Comandos por voz (que funcionam de verdade) e coisas como este multi-touch screen realmente me fazem ver uma luz no fim do túnel. Mais pra frente tentarei falar um pouco de vídeo-games explorando alguns dos novos assuntos com os quais ando tendo contato ultimamente e não poderei deixar de falar também do novo controle do Wii, o novo vídeo-game da Nintendo. Ele simplesmente aposta em um conceito revolucionário de interatividade que vem se provando um sucesso de mercado. Mas poderemos falar mais sobre isto em um próximo post.

Por hora, só queria deixar aqui minha percepção que as coisas estão mudando (e desta vez parece que para melhor!).

Já era hora!

O meu último artigo com o título de “Funções inline” acabou gerando uma contestação interessante, dizendo que o artigo ao qual eu me referenciava não se tratava de funções inline mas, sim, de conceitos relativos a uso de funções em linguagens que suportam programação funcional.

Bom, como não sou dono da verdade, fui atrás de uma definição formal de funções inline e eu estava errado. Certamente um melhor título para o artigo seria “Funções e programação funcional” ou alguma coisa do tipo.

Para deixar os conceitos mais claros, segue uma boa definição de funções inline. Segundo a definição formal, funções inline são parecidas com o conceito de macros que aparece em muitas linguagens de programação. Eu acabei usando o termo funções inline de forma indiscriminada no meu artigo para referenciar a capacidade de se declarar funções anonimamente na mesma linha em que se está chamando uma outra função (isto, em inglês, acaba sendo chamado como “inline” também, mas significa outra coisa).

Enfim, espero que esteja esclarecido este ponto. Sempre é bom ouvir outros pontos de vista e esclarecer nomenclaturas!

Outro dia estava desenvolvendo um programa em Java e precisei manipular alguns arquivos. Até ai, tudo bem. Java, para variar, possui um conjunto de classes em sua API padrão específica para tratamento de arquivos no pacote java.io.

Mais especificamente, eu estava usando a classe java.io.File, que possui uma abstração para acesso de arquivos independente do sistema operacional. Foi ai que tive um problema inesperado quando precisei de criar um link simbólico.

Para aqueles que não estão acostumados com o conceito, um link simbólico é, simplificadamente, um arquivo especial que no fundo só é um apontador para outro arquivo. Quem quiser maiores informações pode ler aqui. Este conceito de arquivo é muito usado em sistemas *nix, mas hoje ele está presente em outros sistemas também, como o Windows.

Apesar de ser um conceito muito bem difundido, para meu espanto, a classe java.io.File não consegue criar um link simbólico! O engraçado é que ela faz várias outras coisas: cria arquivos, cria diretórios, apaga arquivos, renomeia arquivos… Mas não cria links simbólicos!

Imaginei que poderia haver alguma outra forma de se criar um link simbólico em Java, mas após uma pesquisa rápida não achei nenhuma solução prática que não fosse a execução direta no sistema operacional do comando que cria links simbólicos, o que não é uma solução muito boa pois é dependente de sistema operacional e, se estamos programando em Java, uma das coisas que provavelmente estamos buscando é portabilidade (e, no meu caso, isto é verdade).

Para aumentar ainda mais minha perplexidade, achei um bug aberto no bug tracker da Sun descrevendo este problema em 1997. Só que o bug continua aberto e sendo atualizado com informações. Um dos últimos posts neste bug diz que talvez no Java 7 (que ainda está meio longe de aparecer, ainda estamos no Java 5) a interface para manipulação de arquivos em Java irá mudar (http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4042001 e http://bugs.sun.com/bugdatabase/view_bug.do;?bug_id=4313887).

Provavelmente esta funcionalidade foi deixada de lado na classe Java.io.File para que Java pudesse manter compatibilidade com todos os sistemas operacionais que rodam Java. No entanto, por ser uma funcionalidade muito aceita e muito útil, acho que o certo seria termos uma interface Java.io.IFile que possuisse todos os métodos e, cada sistema operacional teria sua implementação especifica desta interface. Estes detalhes, inclusive, poderiam ser totalmente abstraídos para o desenvolvedor, que poderia continuar usando a classe Java.io.File. A única coisa é que se ele tentasse criar um link simbólico em um sistema de arquivos que não suportasse isso, uma exceção seria gerada.

É pitoresco como uma linguagem muito utilizada como Java possui uma deficiência grave como esta. Alias, na minha opinião, a interface de manipulação de arquivos como um todo em Java é bem fraca. Não existe, também, um mecanismo atômico para copia de arquivos. Se alguém quiser copiar um arquivo, acho que a melhor solução será abrir um streaming para ler um arquivo, criar um novo arquivo e abrir outro streaming copiando todo o conteúdo do arqiuvo original. Algo muito mecânico se comparado com algumas outras grandes facilidade proporcionadas pela plataforma Java.

Enfim, apesar de Java ter muitas facilidades, é necessário algumas evoluções am alguns campos ainda. Apesar da minha reclamação, de certa forma isto é natural. Se todos os sistemas que existissem não precisassem de evolução a computação por si só perderia sentido.

Seguindo a onda do Miguel, segue mais um artigo muito interessante do Joel sobre funções inline e sua grande aplicabilidade.

É interessante como são poucas as lingugens ditas comercias e amplamente difundidas que possuem está funcionalidade. Tudo bem que está não é uma funcionalidade extremamente essencial nem sempre útil, mas pode facilitar muito a vida em determinadas situações.

É impressionante também como o Joel escreve bem.
Ah, e não sei se vocês perceberam, mas agora sou um colaborador oficial deste blog! Obrigado Miguel!

Por Leonardo Garcia

Sou usuário da Internet desde os idos de 1995, se não me engano. Antes
disso, ainda, existiam também as BBSs (pequenas redes comunitárias que
conectavam poucos computadores através de linha telefônica). Naquela
época, a Internet ainda era incipiente no Brasil, bem pequena e estava
em testes para o público em geral. Mesmo assim, o mundo que se abria
lentamente através dos primeiros sites web (sim, naquela época a web
era minúscula e usávamos o Mosaic, o primeiro navegador, e, depois, o
Netscape 1.0 para acessá-la!), dos e-mails, dos newsgroups (que
acabaram praticamente desaparecendo com as listas de distribuição por
e-mail) e do Gopher (este, coitado, foi praticamente extinto pelo
web… nem sei se ainda existem sites Gopher…). Fui um usuário de
teste do primeiro provedor do interior de Minas Gerais, se não me
engano.

Nesta época, a minha velocidade de conexão eram incríveis 4800 bps,
isto porque eu tinha um computador com o modem comercial mais rápido
existente na época. Alias, não era simplesmente um modem. Era um
fax/modem, que também passava fax do computador a incrívies 9600 bps!
Hoje em dia os modems de linha discada também enviam e recebem faxes,
mas esta funcionalidade quase perdeu sentido numa era de e-mails com
vídeos e voz.

Não dava pra ver quase nada a esta velocidade, até porque a qualidade
da infra-estrutura de Internet era muito ruim no Brasil ainda. Pelo
menos esta era a percepção de usuário que eu tinha.

O tempo foi passando e as minhas velocidade de conexão foram
aumentado: 14400 bps, 33600 bps, 56 kbps… mas sempre através de
linha discada.

Depois disso passei a conviver com redes maiores. Na Unicamp, por
exemplo, eram comuns redes Ethernet ou de cabo coaxial (estas nem
existem mais praticamente…). As coaxiais, sinceramente, não sei qual
era a velocidade delas, mas acho que o máximo era 10 Mbps. As
Ethernets que eu usei tinham 10 Mbps ou 100 Mbps. Como a universidade
tinha um bom acesso aos troncos de infra-estrutura de Internet no
Brasil, a velocidade de conexão lá era muito boa. Algumas vezes, é
verdade, tínhamos problema de velocidade, mas quase sempre por
problemas de configuração da rede do que por problemas de banda
disponível.

Quando comecei a trabalhar, eram comuns links de 256 kbps em empresas
pequenas, seja por ADSL ou por microondas.

Hoje já estamos em um patamar acima deste: eu, por exemplo, uso acesso
à Internet através do cabo da TV à cabo e tenho conexões que podem
chegar a 2 Mbps na minha casa! Isso é cerca de 500 vezes mais rápido
que o meu primeiro acesso à Internet!

Em dez anos, um crescimento de 500 vezes é impressionante. Mas o
crescimento não pára por ai. Hoje, por exemplo, muitos lugares já
possuem redes internas de fibra-óptica, com velocidades de conexão
interna da rede muito superiores a 1 Gbps. As universidades
brasileiras já tem acesso à chamada Internet 2, uma versão paralela da
Internet que se comunica com a Internet “comum” só que através de
velocidades muito maiores que aquelas às quais os usuários comuns
estão acostumados.

Mas, para onde vamos daqui pra frente? Existe motivo para crescer mais
ainda a banda de conexão disponível?

Eu particularmente acho que sim. Se, hoje em dia, não conseguimos
imaginar aplicações para redes de 100 Gbps, por exemplo, é porque,
dentre outras coisas, não temos esta banda disponível. Tenho certeza
que assim que estas velocidades estiverem disponíveis serão criadas
aplicações para ocupá-las.

Neste sentido, temos um projeto muito interessante sendo desenvolvido
no Brasil: o projeto TIDIA, da Fapesp (Fundação de Amaparo à Pesquisa
do Estado de São Paulo, a maior fundação deste tipo no Brasil). O
projeto TIDIA se propõe a algumas coisas, dentre elas, criar
infra-estrutura de rede de computadores ultra-rápidas e aplicações que
façam uso desta infra-estrutura super poderosa para educação a
distância. Não sei como o projeto está hoje, mas lembro-me de ter lido
que uma das coisas a serem desenvolvidas neste projeto era uma placa
de rede óptica capaz de transmitir dados entre computadores a até 400
Gbps!!! Velocidade para ninguem botar defeito!

Saindo do laboratório e indo para a vida real, várias empresas já
estão lançando servidores que suportam as redes com arquitetura
InfiniBand. Não sei maiores detalhes a respeito desta rede, mas elas
podem chegar a 96 Gbps!

Viajando um pouco mais nesta idéia de redes ultra-rápidas, há algum
tempo atrás li um artigo sobre fotón-gêmeos. Fótons-gêmeos são
partículas físicas que possuem características muito especiais. Vou
tentar explicar a propriedade especial que estes fótons-gêmeos possuem
e que, na minha cabeça, poderiam produzir velocidades de transmissão
de dados praticamente infinitas.

Os físicos descobriram que, se você isolar um fóton (uma particula de
luz, como as geradas por uma lâmpada acesa), e conseguir fazer este
fóton atravessar um prisma com propriedades especiais, do outro lado
do prisma sairão dois fótons. O interessante, neste caso, é que estes
dois fótons foram originados de um único fóton original e, como tudo
na natureza, eles buscam o equilíbrio de forças entre si. Em outras
palavras, se você executa uma ação sobre um dos fótons (por exemplo,
colocando-o para girar no sentido horário), o outro fóton executará a
mesma ação no sentido contrário, sem que nada aja diretamente sobre
ele (no nosso exemplo, ele giraria no sentido anti-horário).
Obviamente isto é uma simplificação grotesca do que realmente
acontece, mas é suficiente para tentar explicar o que vem em seguida.
Imaginando que poderiamos, num computador servidor, produzir um fóton,
isolá-lo, passá-lo por um prisma para termos dois fótons-gêmeos e que
conseguíssemos “trancar” um destes fótons no servidor e enviar o outro
fóton-gêmeo através de fibra óptica a um outro computador cliente,
onde este outro fóton seria trancado também. Imaginando também que
poderíamos fazer isto não só com um fóton, mas com centenas de milhões
de fótons, podemos pensar que, para transmitirmos dados entre os
computadores, precisaríamos apenas alterar as propriedades dos fótons
no servidor e estas propriedades seriam modificadas instantaneamente
nos fótons-gêmeos do computador cliente. Ou seja, a velocidade de
transmissão de dados, neste caso, seria tão grande quanto fosse nossa
capacidade de ler as propriedades físicas dos fótons alteradas!

Na prática, isto poderia nos levar a redes de computadores com
velocidades extremamente grandes, não sei nem dizer de qual ordem de
grandeza.

Para finalizar, só tenho a dizer que o que eu vi até agora no
desenvolvimento das redes de computadores nos últimos anos e o que vem
sendo dito no mercado de tecnologia me deixa na espectativa e
empolgado com o que deve vir por ai no futuro próximo. Mas, apesar de
todo o avanço, sempre é bom lembrar do que Tanenbaum disse num dos
livros clássicos sobre redes de computadores: “Never underestimate the
bandwith of a station wagon full of [storage] hurtling down the
highway.”. Numa tradução livre, algo como “Nunca subestime a banda de
um vagão de trem cheio de fitas com dados em uma estrada.”. Isso era
verdade na década de 80 quando esta frase foi escrita provavelmente
pela primeira vez e continua sendo verdade até hoje, afinal, não são
só as infra-estruturas de rede que evoluem, mas também a tecnologia de
storage. Mas isso é uma conversa para outro artigo.

[NDA: Leonardo Garcia é Engenheiro de Computação, e foi meu colega de graduação na UNICAMP. Já trabalhou em diversos projetos relacionados a software livre (inclusive já tendo construído sua própria mini distro de linux ) e em diversas empresas e atualmente está no Linux Technology Center da IBM ]

Uma das coisas mais interessantes que eu já presenciei é a diferença de percepção existente entre os desenvolvedores Java em geral e as pessoas da comunidade Linux. Nos últimos dois anos eu participei de vários eventos da tecnologia Java no Brasil. Dentre eles, os mais importantes com certeza foram os dois Sun Tech Days. Para aqueles que não conhecem, o Sun Tech Days é o maior evento de Java no Brasil. Ele é organizado pela Sun Microsystems Inc. e também acontece em outros países. Estes eventos seriam os segundos mais importantes depois do Java One, maior evento de Java do mundo que acontece anualmente em San Fracisco.

Nestes eventos sobre Java, é muito interessante a forma como a grande maioria dos desenvolvedores tem uma atitude de repúdio com o Windows, a tecnologia .NET e outras coisas vindas da Microsoft. Este tipo de comportamento é de certa forma normal em vários grupos de pessoas envolvidas com tecnologia. Até aí não vejo nada demais. A Microsoft mexe com o âmago de muitas pessoas, seja lá em qual sentido isto acontece. Obviamente, este tipo de comportamento é seguido pela defesa de tecnologias livres, aí incluindo, é claro, o sistema operacional Linux. Isto é ainda mais exacerbado pelo recente movimento da própria Sun na abertura do código-fonte de vários de seus produtos, inclusive o sistema operacional Solaris e da IDE de desenvolvimento NetBeans.

Neste ponto chego ao ponto interessante que comentei no inicio deste artigo. Ao mesmo tempo em que muitas pessoas envolvidas com Java no Brasil são a favor do software livre e do Linux, boa parte das pessoas da comunidade que eu já conheci não gostam da tecnologia Java. Existem, obviamente, vários motivos para este tipo de comportamento da pessoas da comunidade. Muitos não vêem com bons olhos as iniciativas de software livre da própria Sun devido às restrições das licenças da Sun. Especificamente em relação a Java, as licenças da maquina virtual Java e do SDK não são licenças de software livres. Os softwares são distribuídos gratuitamente e sua especificação é desenvolvida através do Java Community Process (JCP), que é um processo aberto a toda a comunidade para desenvolvimento das especificações de tecnologias relativas ao Java. No entanto, a implementação da Sun da máquina virtual Java e do seu SDK não possuem o código-fonte aberto, ainda.

Digo ainda porque existe uma certa boa vontade da Sun em liberalizar um pouco algumas questões relativas à licença do Java. Acho que ainda estamos um pouco longe de termos o código-fonte do Java SE da Sun liberados para a comunidade de software livre, mas no último Java One um dos principais assuntos foi a flexibilização da licença Java para que a implementação de Java SE da Sun possa, por exemplo, ser distribuída sem grandes problemas em distribuições Linux.

Apesar desta aparente boa vontade, posso estar enganado, mas as notícias mais recentes que tenho é que as distribuições Linux que antes estavam vendo com bons olhos a iniciativa da Sun para mudança da licença do Java agora estão com um pé atrás novamente. Isto porque as mudanças feitas na licença aparentemente não foram suficientes para que o Java possa ser disponibilizado juntamente com os outros pacotes de instalação das distribuições.

Esta questão legal, que é importante por um lado, acaba afetando diretamente os usuários finais que tem várias dificuldades para instalar o ambiente Java em Linux e utilizar este ambiente, por exemplo, dentro de seu navegador para acessar a um Internet Banking ou outra aplicação baseada em Java. Este tipo de dificuldade prática causada pelos problemas de licença acaba pesando muito na visão da comunidade de software livre sobre a tecnologia Java.

Não sei até que ponto este tipo de comportamento entre as pessoas envolvidas com a tecnologia Java e com a comunidade de software livre acontece em outras partes do mundo. No entanto, é interessante por si só verificar este tipo de relação no Brasil porque o Brasil é de longe o país com a maior comunidade de usuários Java do mundo e um dos mais ativos participantes em projetos de software livre também.

A idéia deste post surgiu das duas reclamações que o Miguel já fez neste blog a respeito da falta de documentação em projetos de Software Livre (uma destas reclamações está aqui) e de algumas conversas que tive com ele sobre este assunto baseadas na recente experiência que estou tendo no meu trabalho.

Bom, antes de mais nada, concordo com o Miguel de que falta documentação na maior parte dos projetos de software livre que eu já vi. Quer dizer, depende do que nós estamos acostumados a chamar de documentação. O meu referencial de documentação de um projeto vem dos conhecimentos de Engenharia de Software que eu tenho e da vivência com outras Engenharias. Deste ponto de vista, na minha opinião, documentação é tudo aquilo que te ajuda, de alguma forma, a explicar um sistema, como ele funciona, quais são suas funcionalidades e, talvez o mais importante, como usá-lo de uma maneira correta e eficiente, ou seja, para que o sistema serve.

Acho que a grande falha neste sentido para muitos projetos de software livre está no fato de que muitas pessoas da comunidade acreditam que a documentação é o código-fonte, afinal, que melhor maneira haveria para obter informações a respeito de um sistema do que simplesmente poder ver como o sistema funciona nos mínimos detalhes? A falha neste pensamento, comparado ao que eu disse no parágrafo anterior, está na palavra “ajuda”. A documentação deveria ajudar a entender o sistema e olhar o código fonte nem sempre ajuda muito no início. Em sistemas grandes como o Eclipse, pode-se demorar uma semana ou mais para se pegar o “jeito” e conseguir, a partir de então, obter informações relevantes do sistema a partir do código-fonte. Em projetos grandes, uma semana pode não ser muito tempo, mas isto inibe, por exemplo, que uma pessoa que nunca tenha feito um plugin para Eclipse se aventure a fazer um plugin que lhe pareça útil… simplesmente porque o tempo que ela vai gastar para entender a arquitetura do sistema lhe dá apenas duas opções: ou ela vai utilizar uma parte do seu tempo livre para entender o funcionamento do sistema ou vai se virar sem a funcionalidade que ela queria implementar e, provavelmente, distribuir gratuitamente para uso-fruto do resto da comunidade.

Outra questão importante é: se há documentação, muitas vezes ela não é de fácil acesso. É muito comum os sites que hospedam projetos de software livres terem estruturas complicadas, pouco amigáveis. Apesar de eu achar este um detalhe menor, é importante citá-lo também, pois isso leva com que pessoas que trabalham com software livre se comportem de uma maneira diferente de pessoas que, por exemplo, trabalham com software proprietário.

Quando eu programava em tecnologias proprietárias, minha maior fonte de referência não era o Google. Era muito mais fácil achar referências e soluções para meus problemas na própria documentação gerada pela empresa desenvolvedora do sistema. Tive esta experiência, por exemplo, com Visual Basic 6. Não quero aqui discutir as virtudes ou não desta linguagem e muito menos as virtudes ou não da Microsoft (isto dariam vários outros posts e este já vai ficar grande o suficiente). No entanto, a Microsoft fornece uma documentação muito completa, rica em exemplos e de fácil navegação e busca. Simplesmente isto fazia com que eu dificilmente recorresse a sites específicos a respeito de VB6, ou a fóruns ou ao próprio Oráculo, digo, Google. Isto também faz com que VB6 seja, ainda hoje, uma das linguagens mais conhecidas e mais utilizadas no desenvolvimento de sistemas, mesmo com todas as suas limitações e com o fim de suporte oficial da Microsoft à linguagem.]

Em compensação, todas as vezes que eu trabalho com software livre, “Google is my friend!”. Gosto das listas de discussão também, mas acho que elas são mais complicadas de serem utilizadas, pois existe toda uma etiqueta para participação de listas, o que inclui a leitura dos FAQs e perguntas antigas das listas, o que geralmente eu não tenho muita paciência para fazer. De qualquer forma, poderíamos dizer que neste caso a documentação não está escrita formalmente. Se ela existe, é difusa e esta mal catalogada (por melhor que o Google seja, ele não pode ser utilizado como catálogo de nada, até porque o objetivo dele não é este, por enquanto). Isto, na minha opinião, acaba inibindo alguns novos desenvolvedores a experimentarem o software livre. A filosofia de que a documentação é o código-fonte, para estas pessoas, não funciona.

Os mais puristas em relação ao modelo de desenvolvimento do software livre poderão pensar que eu estou exagerando, e talvez esteja mesmo. Mas eu queria chamar atenção para o fato de que talvez um processo mais elaborado de geração de documentação poderia fazer com que projetos de software livre fossem mais bem vistos por desenvolvedores de uma forma geral e pelas corporações também (afinal, hoje grandes empresas também têm papel decisivo no desenvolvimento de projetos de software livre).

Não estou dizendo também que se deva adotar um processo formal de qualidade de software no desenvolvimento de software livre. Este esquema, na minha opinião, não funciona com o modelo de desenvolvimento criado pelas comunidades de software livre. Um processo exagerado de documentação certamente desmotivaria os colaboradores dos projetos livres, mas alguns controles, como os criados, por exemplo, pelo Gforge, poderiam ser interessantes. Isto sem levar em conta alguns argumentos interessantes da comunidade de software livre para a ausência total de documentação nos projetos de software livre. Algumas que eu acho interessante e faço questão de comentar:

• Software de qualidade não necessariamente é feito com processos de qualidade e nem todo software feito com processo de qualidade tem qualidade. Isto é uma verdade indiscutível.
• Processos de qualidade de software como o CMMI focam boa parte do trabalho na definição dos processos pois se a empresa ou o grupo de desenvolvimento tiverem os processos bem definidos, isto significa que, teoricamente, a saída de uma pessoa do grupo e a sua substituição por outra pessoa não deveria interferir na qualidade do software produzido. Isto faz com que as pessoas sejam transformadas em meros recursos, o que, definitivamente, não é a idéia das comunidades de desenvolvedores de software livre, onde os desenvolvedores são os principais atores.
• Espera-se que a comunidade de software livre tenha colaboradores bons. E uma pessoa que não seja boa o suficiente para ler um código-fonte e entendê-lo não agregará nenhum valor ao movimento. Isto, na minha opinião, é uma verdade pela metade. Uma das grandes batalhas de um dos principais representantes do mundo de software livre, o Linux, é que ele seja um sistema operacional mais aceito e utilizado mundialmente. E, para que isto aconteça, é necessário, antes de mais nada, que o sistema seja fácil de usar e seja entendido por pessoas que não fazem nem idéia do que seja um código-fonte. Qual é a melhor maneira de se fazer entender neste caso? Eu acho que uma boa documentação poderia ajudar bastante nesta hora.
• Na comunidade de software livre, boa parte dos problemas que seriam resolvidos com processos de qualidade de software são resolvidos pelo mantenedor do projeto. Sem dúvida nenhuma, o mantenedor é uma figura crucial em projetos de software livre e ele é o responsável, como o próprio nome diz, pelo bom andamento do projeto. Dizer que o processo de desenvolvimento de software livre não possui nenhum processo formal de qualidade pode até ser verdade, mas isso não significa que o mantenedor e seus colaboradores não tenham que definir funcionalidades, recursos, estimar tempo de desenvolvimento e definir milestones e releases do produto. Tudo isto também acontece com software livre.

Em suma, acho que o que talvez falte para o software livre seja pegar algumas poucas idéias dos processos complexos de qualidade de software e tentar aplicar estas idéias de uma forma apropriada à sua realidade. Sei que cada projeto é um caso diferente e que as regras não seriam universais, mas alguns conceitos poderiam ser usados para tentar ajudar a vida não só dos desenvolvedores, mas também dos usuários comuns que queiram propagar a filosofia de ser livre.