quarta-feira, junho 21, 2006

[Leonardo Garcia] Java e Linux

Por Leonardo Garcia

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.


[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 ]

segunda-feira, junho 19, 2006

[Curiosidade] RAU-TU Madame Myrna

O Rau-Tu é um sistema de perguntas e respostas desenvolvido pela UNIVATES. O sistema e dividido em tópicos (Linguagens de programação, OS, Rede, Sistemas de Edição, etc...), e cada tópico tem uma lista de  colaboradores cadastrados. Qualquer pessoa pode enviar um email com pergunta, que será respondida por algum colaborador disponível. Para manter a qualidade do sistema, a pessoa que envia a pergunta e recebe alguma resposta pode dar notas para as respostas. Os visitantes podem também pesquisar as perguntas enviadas por outras pessoas que já obtiveram resposta, para pesquisa rápida.

Funciona bem !

E hoje eu descobri que o sistema está se diversificando...

O nome: Rau-Tu Madame Myrna.

A descrição: " O RAU-TU Sentimental da Madame Myrna é uma homenagem da equipe de software livre da Univates ao grande escritor brasileiro Nelson Rodrigues (link: http://www.nilc.icmsc.sc.usp.br/literatura/nelsonrodrigues.htm), que nos anos 40 respondia no "Diário da Noite", do Rio de Janeiro, sob o pseudônimo de Myrna às dúvidas sentimentais de seus leitores e leitoras. O livro "Não se pode amar e ser feliz ao mesmo tempo", editado pela Companhia das Letras, reúne as melhores respostas de Myrna a seus leitores. Recomendamos a compra do mesmo e ficaremos extremamente felizes se alguma destas livrarias "online" quiser colocar um banner aqui e patrocinar o contínuo desenvolvimento de software livre pela equipe da UNIVATES. Este RAU-TU Sentimental da Madame Myrna foi criado com o intuito de provar que o sistema RAU-TU pode ser usado para as mais diversas finalidades, que envolvam a criação de uma base de conhecimento, facilitando o encontro de pessoas que colaboram umas com as outras, com o intuito de aprender mais ou se divertir."

O endereço: http://rau-tu.univates.br/madame_myrna/

:-)

quarta-feira, junho 14, 2006

[Leonardo Garcia] Software livre e processos de qualidade de software

Por Leonardo Garcia

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.

[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 ]

terça-feira, junho 13, 2006

[Python] Primeiras impressões

Bom, lendo meus últimos artigos, dá pra perceber que ultimamente andei brincando com Python. Fazia algum tempo que queria aprender esta linguagem, mas sempre rolava aquela preguiça básica. Há 3 semanas atrás tomei coragem, e comecei a programar.

Os motivos que me fizeram ficar interessado foram vários. Ouvi pela primeira vez falar de Python quando trabalhava no projeto AURORA, no CenPRA. Na época, a definição que me deram era que Python era uma ótima linguagem para integração de sistemas: uma espécie de cola. Depois li vários artigos que elogiavam a linguagem pela limpeza sintática e pela facilidade e velocidade de desenvolvimento de código. Além do mais, eu frequentemente preciso escrever alguns scripts para execução de tarefas cotidianas: a solução adotadas por outros desenvolvedores que trabalham comigo é Perl, que apesar de ser altamente poderosa, eu tenho sérios bloqueios com a sintaxe. No final, acabava optando por Java que pra pequenas tarefas cotidianas não é a mais adequada em geral, apesar de ser minha linguagem preferida e na qual tenho maior fluência. O argumento derradeiro foi saber que o Google utiliza muito Python...

O fato é que acabei começando a aprender, e devo dizer que gostei. A estratégia de aprendizagem foi simples: comecei programando algoritmos básicos de computação (merge sort, quicksort, selection sort, heap sort, lista ligada, fibonacci, fatorial), para exercitar comandos básicos da linguagem como recursão, chamada de funções, if-then-else, loops, declaracão de variáveis, manipulação de listas, dicionário, tuplas e outras estruturas de dados. Depois, comecei a usar Python para escrever scripts "real life", ou seja, scripts que tinham alguma funcionalidade no meu dia a dia. Veio a calhar pois atualmente estou processando algumas dezenas de milhares de arquivos contendo dados genéticos, e preciso executar operações como leitura e escrita de arquivos, análise de textos utilizando expressões regulares e geração de relatórios simples.

Não sou expert na linguagem ainda. Longe disso. Apenas escrevi algumas centenas de linhas de código, e não utilizei todos os recursos disponíveis (como orientação a objeto), portanto as impressões que colocarei aqui são apenas preliminares...

De fato a linguagem é bem limpa sintaticamente, e bem fácil de escrever. A questão do uso de indentação para separação dos blocos, que é o motivo principal de reclamação das pessoas que não gostam de Python, não chega  a ser um problema quando se tem um editor apropriado (no meu caso estou usando Emacs com Python Mode): o efeito colateral é que  o código é naturalmente  organizado e fácil de ler. A documentação, centralizada no site www.python.org,  é bem feita, com tutoriais para vários níveis, referencias, livros e mini how-tos, além de listas de discussões bem ativas.

As listas, tuplas e dicionários (também conhecidos como hashes) são o grande forte da linguagem, que possui funções e recursos sintáticos muito poderosos para manipulação destas. Segundo artigos que li, a implementação de hash de Python é uma das mais eficientes que existe. As variáveis em Python são dinamicamente tipadas: não se declara tipo de uma variável, mas uma vez que se atribui um tipo de variável, não se pode atribuir outro tipo de objeto.

O processo de IO (leitura e escrita básica de dados em arquivo) é muito simples e eficiente, assim como  a implementaçnao de  regexp. O modo de uso deste último não é tão direto quanto Perl, e se assemelha muito ao modelo implementado por Java, com patterns e matchers. Não consegui encontrar nenhum artigo comparando a performance das duas linguagens nesse quesito, mas minha experiência atual mostra que não existe uma grande diferença de velocidade...algum dia verifico isso.

Um ponto que eu não gostei muito: o fato de que Python, ao contrário de Perl, Java, C, C++ e outras linguagens, não possui escopo de bloco para variáveis. Ou seja: variáveis declaradas dentro de um bloco for, if ou while são válidas e visíveis fora dele. O escopo de  variáveis é função, módulo, objeto ou método. Também não gosto muito do fato de bastar atribuir um valor a uma variável que ela passa a existir: um modo strict semelhante ao Perl seria bem vindo.

Alguns pontos importantes restam a ser analisados e aprendidos, como orientação a objeto, reflection, organização de pacotes e uso de bibliotecas como processamento de XML, sockets, HTTP e acesso à base de dados. Isso fica para um próximo artigo.

quinta-feira, junho 08, 2006

[Linux Shell] Mão na roda

Nos últimos meses eu andei processando e extraindo dados de algumas centenas de milhares de arquivos de genética. Na maioria dos casos eu uso Perl ou Python para fazer o processamento mais pesado e gerar arquivos de resumo...relatórios simplificados: em geral, um conjunto de colunas. Eu costumava fazer o processamento final desses relatórios em programas de planilha como Excel ou OpenOffice. Mas graças a alguns hackers jedi que trabalham comigo eu aprendi alguns truques velhos conhecidos dos usuários antigos de linux, e antes de abrir esses programas, eu vejo se eu consigo extrair as informações necessárias usando os programinhas utilitários do Shell do Linux. É incrível a quantidade de pequenos utilitários de linha de comando que executam tarefas muito simples e que podem ser uma mão na roda (isso sem mencionar awk e sed..mas aí já complica). Como eu sou um mero iniciante na arte de processamento simples de texto em shell, conheço apenas alguns que vou citar aqui. Se conhecer outros, let me know :-)
  • cut : pega um arquivo contendo colunas separadas por algum delimitador (tipo csv) e extrai uma ou mais colunas. Por exemplo cut -f1,2 -d" " meuarquivo extrai as colunas 1 e 2 do arquivo meuarquivo cujas colunas estão delimitadas por espaços.
  • sort: Lê linhas de um arquivo e imprime a versão ordenada crescentemente. A opção -n indica que as linhas representam números, a opção -r ordena decrescentemente o arquivo e -u elimina elementos duplicados.
  • uniq: Lê um arquivo e descarta linhas idênticas sucessivas, imprimindo o resultado. Caso o arquivo esteja ordenado, elimina linhas duplicadas. A opção -c imprime o número de vezes sucessivas que uma linha apareceu no arquivo.
  • grep: Esse é um clássico. Recupera linhas que contenham uma palavra ou expressão regular: muito útil para filtros. A opção -v faz com que o comando imprima as linhas que não contenham a palavra passada como filtro (inverte o processamento).
  • wc: analisa um arquivo e conta quantas linhas, palavras, caracteres o arquivo possui. A opção -l imprime apenas o número de linhas de um arquivo.
Encadeando esses comandos de forma apropriada, é possível se obter informações bem interessantes de forma muito rápida. Por exemplo, se considerarmos o seguinte arquivo: SCEP 2 PERFECT SCBF 2 P ERFECT SCCC 1 MISC SCCC 3 P ERFECT SCSG 2 MISC SCCC 3 MISC SCSG 1 MISC SCSB 1 P ERFECT SCRF 1 PERFECT SCAC 1 PERFECT Digamos que eu queira saber quantas vezes cada número aparece na segunda coluna, apenas nas linhas contendo a flag PERFECT. O comando em shell seria o seguinte: grep PERFECT file | cut -f2 -d" " | sort -n | uniq -c C.Q.D. Have fun !

domingo, junho 04, 2006

[Python] Meu segundo e terceiro programa

Fatorial
def fat(n):
  if n == 0:
     return 1
  else:
 return n*fat(n-1)
Fibonacci
def fibo(n):
   if n <= 0:         
      return 0     
   elif n == 1:         
      return 1     
   else:  
      return fibo(n-1)+fibo(n-2) 
Classicos !