Arquivo → October, 2008
Visual Basic boy, stay away from my code!
Identificação imediata! :)
“Nada” contra Visual Basic. Sendo assim, sem flame wars ok? :)
Alguns fatos bem interessantes (quase chocantes) sobre COBOL
Sempre que ouvia falar em COBOL, vinha a imagem de uma tecnologia ultrapassada, esquecida e fedorenta. Óbviamente, fruto do meu preconceito. Na realidade, até então, eu nunca havia visto uma linha sequer de Cobol na minha frente!
Sei que muitos compartilham comigo esta primeira impressão também ficarão chocados com alguns fatos bem interessantes sobre Cobol:
- Em 1999, o grupo Gartner fez uma pesquisa e concluiu que 80% das aplicações corporativas em execução no mundo naquele momento eram escritas em Cobol. Os outros 20% eram compartilhados pelas demais linguagens. Este dado tem 9 anos hoje, no entanto, a realidade não deve ser tão diferente nos dias atuais. Basta levar em consideração que BOA parte deste código estava presente em aplicações de missão crítica que, com alta probabilidade, ainda estão em execução hoje. Aliás, um estudo mais recente do mesmo instituto, comprovou que atualmente (artigo de 2006), há aproximadamente 180 bilhões de linhas de código escritas em Cobol em execução atualmente. Uou!
- Cobol é orientado a objetos. O padrão Cobol 2002 aceita orientação a objetos. E tanto Fujitsu quanto Microfocus oferecem compiladores que suportam o paradigma. Mais interessante ainda: se você programa na plataforma .net, pode experimentar Cobol se quiser. Aliás, logo aparecerá um compilador para Java também. É apenas questão de tempo.
- Em 2002, uma pesquisa do grupo Gartner comprovou a existência de dois milhões de programadores Cobol no mundo.
- Cobol paga bem. Dada a necessidade por profissionais que saibam trabalhar com Cobol, e a escassez de mão-de-obra, temos como resultado um aumento significativo dos salários destes programadores. Os salários podem chegar a até R$ 12.000. No exterior, a situação é ainda melhor.
- Programas feitos em Cobol costumam ficar em execução por décadas, ou seja, estes sistemas estão em execução não porque simplesmente “já existem”, mas sim porque são extremamente fáceis de se manter. Boa parte do problema do agora risível “bug do milênio” se deveu ao fato de que os desenvolvedores iniciais daquelas aplicações (a maior parte, escrita em… adivinha!) não imaginava que elas fossem durar tanto tempo.
Dado que o ponto forte de venda de plataformas como Java e .net é justamente a facilidade de manutenção destes sistemas, soa quase “conspiracionista” pensar no porquê deste fato ser tão pouco mencionado. - A sintaxe não é horrível. Sério: eu imaginava que a sintaxe do Cobol fosse algo ridículamente complexo e, para a minha surpresa, é incrívelmente simples. Parece inclusive linguagem coloquial, tal como nos exemplos abaixo:
MULTIPLY B BY B GIVING B-SQUARED. MULTIPLY 4 BY A GIVING FOUR-A. MULTIPLY FOUR-A BY C GIVING FOUR-A-C. SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1. COMPUTE RESULT-2 = RESULT-1 ** .5. SUBTRACT B FROM RESULT-2 GIVING NUMERATOR. MULTIPLY 2 BY A GIVING DENOMINATOR. DIVIDE NUMERATOR BY DENOMINATOR GIVING X.
Como pode ser visto no exemplo acima, na realidade, é extremamente coloquial!
Claro, o exemplo que dei acima é péssimo. Trata-se da execução da fórmula de Bhaskara (lembra? Para se calcular equações de segundo grau…). Isto quer dizer que você não pode escrever fórmulas complexas em Cobol? Claro que não, veja o exemplo abaixo:
COMPUTE X = (-B + (B ** 2 - (4 * A * C)) **.5) / (2 * A)
Após tomar conhecimento destes fatos, uma pergunta fica: por que tão poucas pessoas sabem disto? Por que temos a impressão de que as linguagens mais utilizadas são Java, C/C++, C#, Visual Basic, PHP ou outras? Simples: por causa do mercado no qual Cobol é focado.
Cobol foi desenvolvido para a criação de aplicações de negócios, ou seja, não se trata aqui do mercado horizontal (que produz software de prateleira, ou componentes que são feitos para serem distribuídos), mas sim do mercado vertical, ou seja, Cobol é mais utilizado na confecção de aplicações internas para empresas. Aplicações estas que, normalmente, jamais sairão do ambiente para o qual foram desenvolvidas. Este é o porquê. Ao vermos uma aplicação como o Word, por exemplo, sendo vendida aos milhões, passamos a achar que C++ é uma das linguagens mais utilizadas no mundo. No entanto, nos esquecemos de que esta aplicação foi desenvolvida por apenas UM pequeno grupo de desenvolvedores (em comparação ao resto).
E por que devemos nos preocupar com Cobol?
- Tal como expus acima: porque Cobol possui um mercado imenso, assim como as oportunidades que podem surgir do mesmo. Mais um fato interessante com relação ao mercado: foi estimado que o custo de substituição de código Cobol por código em outra linguagem gira em algo em torno de US$ 25,00 por linha de Código Cobol substituida. Uou!
- Para acabar com a ilusão de que nossa plataforma de desenvolvimento é a “mais linda do mundo” por ser relativamente recente. Só para lembrar: Cobol foi desenvolvido no final da década de 50. Foi uma das primeiras linguagens de programação e, até hoje, é utilizada em massa com relativamente poucas alterações desde sua introdução.
Cobol é a coisa mais linda do mundo? Não. É uma das sete maravilhas do mundo? Também não. Mas também, como pode ser visto, com certeza não é uma das maiores desgraças da história.
Conseguirá Java e C# por exemplo esta façanha? Atualmente, só conheço três linguagens que conseguiram: Cobol, Lisp e Fortran
E eu sei Cobol? Ainda não. ;)
Flash que se cuide por causa da volta dos applets Java?

Talvez. Mas apenas talvez.
Java FX até agora não pegou, no entanto, para minha surpresa, me deparei com um projeto opensource (destes que. literalmente, surgem do NADA) chamado PulpCore. Trata-se de um framework para desenvolvimento de aplicações gráficas em 2D, específicamente desenvolvido paraa criação de applets Java. Ao acessar o site do projeto, e experimentar algumas de suas demonstrações, fiquei realmente impressionado, principalmente com os abaixo:
O que mais me impressionou, foi o fato dos applets gerados serem incrívelmente leves. Realmente, obtem-se o mesmo efeito que temos com Flash. Ainda não escrevi nada usando este framework, porém, pode apostar, assim que tiver meus primeiros exemplos, vocês os verão aqui. Enquanto isto, torço para que este projeto “que surge do nada”, seja como outros, com origem semelhante, que revolucionaram nossa maneira de desenvolver aplicações. ;)
Link para o projeto: http://www.interactivepulp.com/pulpcore/
14 ferramentas gratuitas que te dizem porque os visitantes abandonam seu site

Eis que encontro um link bem interessante, expondo 14 ferramentas bem interessantes para analisar o perfil dos visitantes dos seus sites.
Mercurial aposenta o Subversion (pelo menos pra mim)
Eu amo o Subversion em grande parte porque o meu primeiro gerenciador de versões foi o CVS. Ao entrar em contato com o CVS, a impressão que tinha é que era muito mais fácil simplesmente manter cópias dos meus arquivos a usar aquilo. Tudo era complicado, diria mais: feio.
Foi quando conheci o Subversion, e as coisas ficaram incrívelmente mais fáceis pra mim. E, desde então, venho usado o Subversion como meu principal sistema gerenciador de versões. Tem me atendido 70% das vezes e, devo confessar, não tenho muito o que reclamar. Poderia ficar com ele por anos ainda, até conhecer o Mercurial.
Na primeira vez que ouvi falar do Mercurial, fiquei curioso: “um sistema de gerenciamento de versões distribuido”. Que é isto? Como isto funciona? Pra que serve? Quais as vantagens? Se o modelo do Subversion já me atende tão bem, o que isto poderia me adicionar? E, devo confessar, deixei o Mercurial passar despercebido pela primeira vez.
Mas o mundo da muitas voltas e, pra minha surpresa, de repente estou eu trabalhando no ODF Easy, tentando dar minhas contribuições ao projeto ODFDOM e… no caso do projeto ODFDOM, é usado o Mercurial. Foi quando resolvi aprender a usá-lo de fato (e o Subversion foi pra fila do INSS).
Pra começar, o conceito de gerenciar versões de maneira distribuída é muito interessante. Ao contrário do que termos um servidor central, no qual se encontram todas as versões de nossos arquivos, no caso do Mercurial, todos os usuários do sistema possuem o repositório inteiro em seus computadores.
Qual a vantagem? Simples: você não precisa estar conectado a uma rede para trabalhar com o gerenciamento de suas versões. O usuário do sistema não precisa lutar com uma conexão ruim ou um servidor que pifou. Como consequencia, em um projeto no qual diversas pessoas participam, a segurança é elevada. O servidor aonde seu repositório estava foi abduzido por alienígenas? Ok, basta copiar o repositório de outro participante do projeto para sua máquina. Simples assim.
Então, o ideal agora é por a mão na massa. Para usar o Mercurial, obviamente, a primeira coisa que você precisa fazer consiste em instalá-lo em seu computador. No site oficial você poderá encontrar uma instalação para o seu sistema operacional. Dado que é feito em Python, há versões para todos (ou quase) os sistemas operacionais que oferecem suporte a esta linguagem.
Instalado o mercurial, podemos começar a trabalhar com o bicho. Para criar um repositório em sua máquina, na interface de linha de comando do seu sistema operacional, digite o comando
hg init [nome do repositório]
Exemplo:
hg init ODFEasy
Será criado um diretório com o nome do seu repositório relativo ao seu diretorio atual. Simples assim, e até agora, nada demais.
Deseja os arquivos presentes em outro repositório em seu computador? Na linha de comando, digite o seguinte comando:
hg clone [caminho para o repositório] [nome do repositório a ser criado que conterá os arquivos copiados] Exemplo: hg clone repositorioOrigem repositorioDestino Buscando os arquivos que se encontrem em outro computador: hg clone http://enderecoDoServidor:porta repositorioDestino
Aqui você sentirá uma grande diferença em relação ao nosso aposentado amigo Subversion: performance. Mercurial é inacreditavelmente rápido. Quando vi que era feito em Python, minha mente preconceituosa pensou: “deve ser lento”. Ao utilizá-lo, no entanto, choque: é impressionantemente rápido. Só para ter uma idéia, baixei todo o repositório do projeto ODFEasy, usando uma rede wireless absurdamente lenta em menos de 5 segundos. Espanto! (o projeto ocupa atualmente algo em torno de uns 3/4 megas (incluindo alguns arquivos adicionais ainda não publicados)). Em um dado projeto no qual trabalho, leva no mínimo uma hora fazer um checkout de todo o seu conteúdo com o Subversion. Com o Mercurial, acredito que este tempo deva diminuir para algo em torno de uns 3 a 4 minutos (testarei um dia e postarei aqui o resultado).
Tal como pode ser visto no exemplo anterior, puxei os arquivos a partir de um servidor web. Que servidor foi este? O do próprio Mercurial! Ele já vem com um servidor web bem simples que você pode usar para compartilhar seus repositórios. Como iniciar um repositório? Simples também.
Estando no diretório que contém seu repositório, simplesmente digite o comando
hg serve
Boom! O sevidor já está em execução, operando por padrão na porta 8000 do seu computador. Qualquer computador da sua rede interna, que acessar o endereço http://enderecoDoServidor:8000 poderá navegar por todos os arquivos contidos no seu repositório, porém um aviso: este servidor não oferece ainda suporte a autenticação ou qualquer recurso de segurança, sendo assim, utilize-o pelo mínimo de tempo possível. Se quiser maior segurança, no entanto, é possível configurar o servidor Apache para trabalhar com o Mercurial. Problema resolvido.
Já tive inúmeros problemas ao iniciar um servidor do Subversion (mea culpa). Com o Mercurial, logo de cara, funcionou perfeitamente. Sem dúvidas, uma grata surpresa.
Como comitar seus arquivos no repositório?
hg commit
estando no diretório que contém a sua working copy. E se você quiser enviar seus arquivos para outro repositório, em outro computador?
hg push [servidor ou repositório]
Quer passar para o seu repositório as mudanças feitas em outro?
hg pull [servidor ou repositório]
E agora, um detalhe bacana: o Netbeans oferece excelente suporte ao Mercurial, muito similar ao oferecido ao Subversion (e o Eclipse também!).
Por enquanto, esta tem sido a minha curta experiência com o Mercurial. Durará a excelente imagem? O tempo dirá. E quem virá a aposentar o Mercurial no futuro? Pelo que ouvi, possívelmente o git, mas ainda não tenho experiências com ele para compartilhar.
Será que em breve terei um post “Git aposenta o Mercurial”?
ODF Easy 0.2 lançado – gerar planilhas do OpenOffice está ficando mais fácil!
Acabo de lançar a versão 0.2 do ODF Easy. Nesta nova versão, finalmente inclui suporte a alguma formatação de células (cor de fundo, fontes, bordas, etc.) e iniciei o desenvolvimento do suporte à criação de gráficos também.
Espero que com este projeto, possa ajudar aqueles que passaram pelas mesmas dificuldades que passei ao tentar gerar documentos ODF em Java.
Para facilitar a divulgação do projeto, criei um site para o mesmo: http://odfeasy.itexto.com.br
11 empresas web 2.0 potencialmente falidas (Twitter,Meebo e Skype na lista)
Topei com o seguinte artigo hoje no news.com:Today’s Kozmos?: 11 potentially doomed dot-coms
Eis a lista: Twitter (!), Meebo (!!), TripIt, Zillow, Pandora, Second Life (!!!), Skype (!!!!!!!!), Ask, DailyMotion, Net Vibes, MySpace (!!!!!!!!!!!!!!!!). Link para o artigo.
Claro, nada impede que não passe de incertezas. Afinal, basta lembrar como a mídia tratou a Apple por exemplo.
Abaixo: só um refresco para a memória: como a Wired vê a Apple em dois momentos distintos. De práticamente quebrada (mais especulação do que de fato) a sucesso absoluto.
Incrível demo de OpenGL em Java (pelo menos pra mim!)
Estudando, topei com o projeto JOGL, que consiste no encapsulamento da biblioteca OpenGL para a plataforma Java. Navegando pelas demonstrações, topei com um exemplo de refração/reflexão usando Java + OpenGL que simplesmente jogou meu queixo no chão.
O demo pode ser acessado via Java Webstart, clicando aqui. Ao executar a demonstração, arraste o coelho com o mouse, redimensione a janela, fuce no que quiser. É realmente incrível como o lag é mínimo.
Uma demonstração realmente impressionante (pelo menos pra mim, que até agora, no OpenGL, só consigo desenhar uma casinha tosca composta por quadrados e triangulos).
Mais demonstrações podem ser encontradas aqui.
Link: comparando licenças open source (com quadro comparativo realmente útil)
Encontrei este link na internet: Comparison of Different Open Source Licenses -“With Comparison Chart!”, no qual são comparadas diversas licenças open source, de uma maneira bem simples de entender.
Grande coisa: a diferença deste post é que contém um quadro comparativo bastante interessante, que exponho abaixo:
Por que o OpenDocument Format (ODF) é importante (e porque fico assustado com o quão negligenciado o mesmo é)?
É interessante se fazer a pergunta: por que x é importante? Antes de iniciar o desenvolvimento do projeto ODFEasy, sabia que ODF seria algo “importante”, mas nunca havia sentido na pele a sua necessidade. Afinal de contas, se já temos o Microsoft Office, por que precisamos de outro formato? A pergunta se responde: exatamente porque temos o Microsoft Office e, basicamente, APENAS o Microsoft Office.
Como desenvolvedor, 95% das vezes, opto por trabalhar com ferramentas abertas, principalmente Java. E, neste processo, vez por outra faz-se necessária a geração de arquivos no formato do Office (no meu caso, 99,9% das vezes, planilhas). É aí sempre o mesmo problema retorna. Se você está desenvolvendo na plataforma .net, sempre há como integrar sua aplicação ao Office via automação e, a partir dai, gerar o que você sonhar. Se não quiser trabalhar com automação, há uma ou outra biblioteca que lhe auxilia na geração desta tarefa. Normalmente, estas bibliotecas não abrangem 100% do formato, mas acabam por quebrar o galho.
Já se você trabalha com alguma plataforma aberta, como Java, as coisas começam a ficar mais complicadas. Para começar, as bibliotecas que possuímos estão bem distantes de serem apropriadas. Podemos criar planilhas e arquivos do Word, mas não podemos nos aprofundar muito na geração destes documentos. Se você quiser, por exemplo, incluir um gráfico em uma planilha (foi o meu caso), terá de primeiro criar um documento de modelo, incluir no mesmo suas séries, o gráfico em questão, definir o número de ocorrências e, posteriormente, programaticamente, simplesmente substituir o valor destas células. Limitação total.
Há ainda problemas provenientes de optar-se pela automação: para começar, seu cliente terá de ter o Microsoft Office instalado (traduzindo: Linux está fora da jogada). Isto sem mencionar que a geração de documentos via automação é leeeenta.
E a razão pela qual as bibliotecas para geração deste tipo de documentos ser tão limitada é simples: quase tudo o que sabemos sobre o formato Microsoft Office até agora é a partir de engenharia reversa. Só neste ano a Microsoft liberou a especificação destes formatos, sendo assim, ainda não deu tempo para estas bibliotecas compreenderem de fato como são estruturados estes arquivos. Claro, há também o OOXML, mas caso optemos por este formato, novamente estaremos nos prendendo a um único fornecedor. A solução, portanto, consiste em buscar um formato alternativo para se gerar documentos. É quando o OpenDocument entra em cena.
OpenDocument consiste em um padrão independente de fornecedor e 100% aberto para representar arquivos de escritório. Se é 100% aberto, isto significa que qualquer um pode conhecer sua estrutura e, com base na mesma, criar documentos neste formato. E se é independente de fornecedor, não precisamos nos preocupar se amanhã existirá um OpenOffice ou não. Nossos documentos serão suportados por outro fornecedor sem problemas, com 100% (ao menos em teoria) de compatibilidade. O mesmo não pode ser dito dos seus arquivos do Office.
Do ponto de vista do desenvolvedor, isto equivale a liberdade total. Ao adotar-se o padrão ODF, o desenvolvedor não precisa se preocupar com o fato de seus clientes possuirem ou não o Microsoft Office. Não é necessário se preocupar com o fato de sua biblioteca suportar os recursos x,y ou z do formato, pois caso a mesma não possua este suporte, editar estes arquivos é extremamente simples. Afinal de contas, basicamente, consistem em arquivos XML! E o melhor: trata-se de uma tecnologia REALMENTE gratuita.
Antes da criação do formato OpenDocument, se alguém quisesse criar uma suite de produtividade, teria de gastar uma fortuna com o desenvolvimento de seu próprio formato, além de fornecer suporte aos demais formatos utilizados pelas demais suites. Hoje, este custo diminuiu absurdamente, uma vez que não é mais necessário investir no desenvolvimento de formatos proprietários. Basta seguir o padrão definido pelo comitê responsável pelo desenvolvimento do padrão. E se quiser incluir algo específico da sua aplicação? No problem! O padrão OpenDocument já prevê estas necessidades e propicia aos desenvolvedores lidar com estas peculiaridades sem denegrir o padrão. Sendo assim, é óbvio que o formato será o futuro, correto?
E aqui entra a minha preocupação. Mesmo com todas estas vantagens, não vejo muitos desenvolvedores (ao menos aqui no Brasil) se interessarem pelo formato. Ao buscar informações no GUJ (neste link há a busca pelo formato ODF), por exemplo, a respeito da geração de documentos no formato ODF, fiquei besta ao perceber quão poucas são as dúvidas. A maior parte dos posts diz respeito a notícias relacionadas, Ao postar no fórum sobre o projeto ODFEasy, fiquei chocado ao notar que só obtive UMA resposta! O que me fez parar para pensar sobre a real necessidade do projeto.
Ao que tudo indica, a comunidade de desenvolvedores não encontra-se atenta para este formato. Basta observar quão poucas são as bibliotecas existentes hoje para a geração de documentos. Ao navegar pela mail list do projeto ODF Toolkit (que visa a criação de ferramentas que possibilitem a geração de documentos ODF via código), percebe-se que não é uma lista tão ativa quanto deveria ser. Sinceramente, a impressão que tenho é a de que todos estão esperando que algo apareça para facilitar a tarefa, porém poucos de fato fazem alguma coisa a respeito. Claro: há também o fato de hoje o Microsoft Office ser dominante, e que nossos clientes de fato querem arquivos do Office, e não do OpenOffice, porém, convém mencionar que isto é o AGORA. Se nada for feito, iremos ter os problemas que citei acima indefinidamente.
Dado que estes problemas são percebidos mais claramente por desenvolvedores, e não por usuários finais, cabe a nós fazer algo a respeito, buscando conhecer melhor o formato, criando ferramentas que facilitem a criação de documentos e, principalmente, expondo aos nossos clientes os ganhos provenientes da adoção do formato.
No que diz respeito à computação pessoal/corporativa, existem os seguintes pilares:
- Sistemas operacionais: temos o Linux, Solaris, Mac OS e BSD brilhando aonde antes havia apenas Windows.
- Bancos de dados: temos MySQL, PostgreSQL, Firebird, HSQLDB e diversos outros SGBDs que tornaram a compra de SGBDs proprietários algo do passado.
- Ferramentas de desenvolvimento: Java, C/C++, Perl e todas as linguagens abertas que, uma vez aprendidas, se mostram infinitamente superiores às ferramentas proprietárias que dominavam até então, como o Visual Studio, Delphi, etc.
- Criação de documentos: temos o OpenOffice, e o Microsoft Office dominando TODO o mercado (causando os problemas que acima citei).
Como pode ser visto, três dos pilares já estão sólidos. Falta apenas um! Pessoas compram computadores hoje para dois propósitos: navegar na Internet (e esta sim é baseada em padrões abertos) e criar documentos. A partir do momento em que passarem a gerar documentos usando padrões abertos, não precisarão mais gastar 200,300,400,600 reais com Windows + 100 reais com anti-vírus. Poderão usar Linux, BSD, Solaris, Mac OS, o que quiserem.
E como consequência, nós, desenvolvedores, não ficaremos presos a uma única plataforma nem seremos limitados ao que o fornecedor da plataforma dominante QUER abrir ou não.








