Revista Do Linux
EDIÇÃO DO MÊS
 CD do Mês

 Capa
 Entrevista
 Corporativo
 Distro
 Segurança
 Hardware
 Produto
 Primeiros Passos
 Sistema
 

Escolha suas armas

Algumas opções para desenvolver aplicativos em Linux e que estão trazendo uma avalanche de novos produtos para as terras do pingüim

O principal indicador para as empresas brasileiras de software para que possam apresentar aos seus clientes a possibilidade de abandonar a plataforma Windows — que reconhecidamente é um enigma insolúvel, pois nunca obterá um release estável, a não ser que se transforme em um dialeto Unix — é a existência de ferramentas de desenvolvimento de grande qualidade e com suporte comercial garantido para levar suas aplicações para o Linux. São muitos os requisitos para essa migração, certamente bem mais do que um usuário leigo possa elencar, mas um deles se destaca entre os demais: as bases de dados. Elas são o coração das empresas e as aplicações que acessam esses dados refletem seu nível de eficiência profissional.

Selecionamos cinco excelentes ferramentas de desenvolvimento que garantem o porte de aplicativos para o Linux: FlagShip, DataFlex, JBuilder, Acucobol e Kylix. É o que poderíamos chamar de os 5 pesos pesados, pelo poderio e desempenho que oferecem ao desenvolvedor. Todas elas têm uma garantia expressa de continuidade de desenvolvimento porque são produtos de empresas que estão atuando no mercado mundial há pelo menos dez anos e são reconhecidas muito mais por sua excelência do que por seu marketing. É claro que existem outras ferramentas de desenvolvimento para Linux, mas essa seleção tenta abarcar todas as necessidades do chamado "grande mercado" e as comunidades mais expressivas de desenvolvimento aqui no Brasil. Para todos os gostos há uma ferramenta adequada à sua cultura, para clippeiros, coboleiros, delphistas ou de outro grupo qualquer.

As ferramentas livres, como o excelente PHP, têm uma legião de defensores, mas, por outro lado, nem sempre apresentam uma abundância de mão-de-obra especializada ou mesmo a garantia de suporte comercial, condição inegociável para muitos desenvolvedores e empresas de software. Já para o técnico que desenvolve aplicações, migrar para uma plataforma nova como o Linux e ter domínio sobre o assunto é uma tarefa árdua, mas se tiver que mudar também de ambiente de desenvolvimento, partindo da estaca zero, ele ficará um bom tempo fora do mercado para hibernar em um novo aprendizado, o que na maioria dos casos é absolutamente inviável.

FlagShip

O Brasil tem a segunda maior comunidade Clipper do mundo, superada apenas pela Alemanha, e é justamente lá que nasceu o FlagShip, uma implementação do padrão xBase para sistemas operacionais baseados em Unix. Originalmente desenvolvido para o Nixdorf da Siemens, é compatível com o Clipper desde a versão Summer 87 até a 5.2, e é ao mesmo tempo uma linguagem de desenvolvimento e uma ferramenta de migração de aplicativos para Linux/Unix.

O FlagShip destaca-se por possuir suporte nativo à programação orientada a objeto (OOP), pelo acréscimo de comandos e funções inexistentes no Clipper (150 novos comandos), pela fácil integração com C, e suporte a características dos sistemas compatíveis com Unix, tais como acesso a arquivos, uso de pipes, spool de impressão etc. Seu funcionamento é simples: os fontes do sistema (*.prg) são convertidos para C, e então as ferramentas de desenvolvimento da plataforma (compilador C, assembler, linkeditor etc.) são invocadas para a geração do executável final, cujo código é de 32 bits. Esse executável, gerado estática ou dinamicamente, é independente e roda sem necessidade do uso de runtime ou coisa parecida.

Para converter de sistemas Clipper para FlagShip deve-se:

  • obter os fontes de absolutamente tudo: as bibliotecas e os arquivos OBJ de terceiros não são binariamente compatíveis com o Linux e é necessário que os fontes sejam recompilados;
  • copiar os arquivos .prg e .dbf para o ambiente Linux normalmente, via ftp, disquete etc.;
  • incluir no .prg principal de cada sistema a cláusula
    
    #include "fspreset.fh";
    
    
  • reindexar sua base de dados (uma única vez): os arquivos de índices utilizados pelo FlagShip têm, além de outro nome (.idx ), outro padrão também.

Para os que usam a linguagem Clipper a curva de aprendizado é quase nula, porém esses também encontrarão no Linux um ambiente muito diferente. De imediato, notam-se os seguintes benefícios:

  • maior segurança para a base de dados, pois a perda de índices praticamente desaparece (o processamento é feito no servidor e os dados não transitam pela rede);
  • código 32 bits (disponível nativamente para mais de 20 plataformas);
  • muito mais rapidez, pois no tempo de compilação o FlagShip converte para C e depois compila e linkedita com o C nativo da plataforma;
  • três tipos de estações: terminal burro, estações Linux ou Windows;
  • possibilita conexão à distância via linhas dedicadas, discadas ou Internet;
  • não há limite de tamanho para o executável;
  • como o processamento é feito no servidor, a estação de baixa configuração tem praticamente a mesma velocidade das estações maiores.

A distribuidora exclusiva no Brasil é a Inso Informática (www.inso.com.br) e ela agregou algumas soluções complementares ao produto, tais como:

  • FS-CGI — biblioteca para desenvolvimento Web;
  • FS-Connection — um RDD/API que possibilita o uso de outros bancos relacionais, como CA-Ingres, Oracle e Interbase;
  • biblioteca para impressão de códigos de barras.

Outro ponto de destaque importante refere-se ao uso de ECFs (impressoras fiscais). Os drivers e programas fornecidos para Linux pelos diversos fabricantes podem ser utilizados normalmente pelos programas em FlagShip, diretamente no caso dos programas (comando RUN) ou através de interfaces específicas escritas em C. Também a GAS Informática, em parceria com a Inso, liberou uma versão de sua ferramenta de geração de programas para o FlagShip, e há muita expectativa no mercado pelo lançamento do Visual FlagShip, que deverá inaugurar uma nova era para a empresa alemã Multisoft, proprietária do FlagShip, e para os desenvolvedores xBase.

 

DataFlex

Quem em 1988 usava DataFlex, já na época uma linguagem de quarta geração orientada a objetos, e não quis desfazer-se do seu legado de aplicações sabe hoje que foi uma decisão acertada. Grandes empresas como a Parmalat, a Moore Formulários, a Hertz do Brasil, a Souza Cruz, a Sulamericana e diversas prefeituras brasileiras, bem como médias e pequenas empresas, rodam muitos sistemas em DataFlex, principalmente pela facilidade de desenvolvimento e pela portabilidade assegurada.

É muito comum encontrarmos sistemas nessa linguagem rodando em antigos 386 há quase dez anos, um sinal de que são sistemas bastante confiáveis. Mas o DataFlex evoluiu bastante nos últimos anos e ele usa hoje uma metodologia framework para desenvolvimento, o que garante uma consistência muito grande para suas aplicações, mesmo quando são feitas alterações estruturais no código ou na inclusão de novos módulos. Existem agora drivers nativos para Oracle, SQL Server e DB2, e a interação dos dados desses bancos, ou de outros via ODBC, com um banco DataFlex é totalmente administrada por um dicionário de dados, uma camada que rege as "regras de negócio" dessa conversação.

Integrados no pacote do produto encontramos o Crystal Reports 8, o Pervasive SQL, o WebApp Studio e o Data Access Universal Unix. Na versão Windows há o Visual DataFlex 7, mas para o Linux prevalece o tradicional modo console e o WebApp Server 3, um servidor de aplicativos. A razão de não haver uma versão visual para Linux até agora vem principalmente do fato de essa versão 3 do WebApp Server gerar dinamicamente o fonte em JSP (Java Server Page), e também em WML para WAP. As aplicações no browser ou em devices possibilitam aos desenvolvedores de DataFlex gerar aplicativos para Web e Wap, afinal "tudo está virando Web" para a maioria deles.

No Brasil a filial da DataAccess (www.dataaccess.com.br) tem sido bastante consultada por seus clientes e desenvolvedores sobre o desempenho e performance do DataFlex em Linux, principalmente as empresas que usam SCO-Unix e que estão migrando depois que seu suporte desapareceu no Brasil.

Como os sistemas DataFlex usam licenças comerciais de uso (runtime), há um efeito catapulta nos custos e que depende diretamente da escolha do sistema operacional. Essas licenças começam como monousuário (desenvolvedor), depois passam para grupos de 4 usuários e vão até a licença "ilimitada" para mais de 300 clientes. Uma aplicação que não possa prescindir de 300 outras licenças de uso de sistema operacional encontra um sério problema financeiro a resolver. O Linux remove esse obstáculo, tornando-se muito atraente para os desenvolvedores e empresas de todos os portes, além de oferecer um ambiente tão seguro e robusto quanto o SCO-Unix.

Em algumas distribuições do Linux há uma versão trial do DataFlex (df32lin.tar), plenamente funcional em modo console, mas limitada a 250 registros no banco de dados, e que pode ser encontrada no site da DataAccess.

É aconselhável baixar também o manual de instalação (DF31d.pdf), que descreve todos passos de configuração de ambiente no Linux, e se você tiver um bom link recomenda-se o download do manual de referência (DF32Doc.zip), que tem um tamanho razoável: 16 Mb. De qualquer maneira há um manual on-line no DataFlex de 1,5 Mb, que cumpre a mesma função.

Para os que se interessam por desenvolvimento de aplicativos transacionais para Web ou Wap, pode-se encomendar no site da DataAccess o livro Descobrindo WebApp Server Product Suite, literatura oficial do WebApp e que ilustra para onde vai o DataFlex no futuro.

 

JBuilder

Muitas empresas e desenvolvedores no mundo inteiro acreditam que o browser está se impondo como a interface obrigatória para aplicações depois da explosão mundial da Internet, e também que Java é a linguagem que atende melhor a topologia cada dia mais intrincada da grande rede. Escalando as redes e suas aplicações para equipamentos cada vez maiores, a palavra de ordem "conectividade" é a chave para servir informações para equipamentos de qualquer porte e em qualquer lugar. A fórmula básica dessa equação é Internet + aplicações multiplataforma + formatos populares de arquivos.

O JBuilder é um dos carros-chefe da Borland e seu produto de maior sucesso no mercado americano. O programa segue a mesma padronização de ambiente de todos os produtos da companhia, com a mesma IDE que o C++ Builder, o Delphi e o Kylix, os mesmos atalhos de teclado, a mesma organização de componentes em paletas, e faz uso intensivo do drag&drop para gerar aplicações com quase nada de digitação de código.

Os primeiros applets Java (aplicação que roda na máquina cliente) que começaram a aparecer em profusão na Web no início de 1997 comprometeram um pouco a imagem do então inovador Java por serem códigos mal escritos e com performance sofrível. Claro que o maior vilão era e continua sendo a falta de banda de comunicação, mas encontramos hoje códigos muito mais enxutos e um aumento significativo de servlets Java (aplicação que roda no servidor), principalmente no mercado financeiro internacional, em que se observa um crescimento vertiginoso de aplicações, muitas delas fazendo uso da tecnologia push para a atualização real-time de balanços e cotações.

O JBuilder é um dos campeões de download com mais de 500 mil cópias baixadas do site da Borland desde que foi lançada uma versão freeware (JBuilder Foundation) no ano passado. Enquanto se esperam bandas mais largas de comunicação e o fim dos gargalos, o JBuilder vem conquistando uma legião de desenvolvedores em todo o mundo e sustentando um número gigantesco de intranets corporativas.

Assim como o Delphi, o Kylix e o C++ Builder, o JBuilder está repleto de assistentes (wizards) que, com um simples arrastar e soltar de componentes, geram puro código Java que acessam, através de uma camada de abstração de dados, chamada Data Express, diversos bancos de dados via JDBC e ODBC, além do nativo JDataStore e do Interbase. Administrar a persistência de dados fica na incumbência exclusiva dessa camada e alivia bastante o trabalho de codificação.

Dois problemas freqüentes que o desenvolvedor Java encontra são a inconsistência das máquinas virtuais (Java Virtual Machine) do lado cliente e a busca pelo menor caminho na aplicação para reduzir o tempo de download, o principal obstáculo nesse ambiente. Para contornar os dois problemas é preciso se concentrar em obter estruturas com o mínimo de código e chamadas-padrão para quaisquer das implementações de Java. Por outro lado, o resultado do esforço é a liberdade de devolver sempre levíssimas strings em HTML, que independem de hardware e software instalado na máquina do cliente. Por isso o padrão JSP já é uma realidade para todos os provedores. No Brasil, o problema se concentra na escassez de profissionais Java, um grande gap para o mercado americano, mas em dois ou três anos a demanda deverá estar suprida.

Acucobol

O Acucobol tem versões para mais de 600 plataformas, embora todos os anos alguém teime em dizer que este será o último ano do Cobol, que não vale a pena investir mais nele e sim em uma nova linguagem que está surgindo. Os anos passam e os revolucionários produtos sugeridos para substituí-lo, assim como os efêmeros defensores deles, vão e vem com as modas, e ele permanece. Principalmente no grande porte o Cobol tem cadeira cativa e é reconhecido por gerar sistemas extremamente rápidos, seguros e robustos. Antigos programadores, os chamados "coboleiros", costumam dizer que ler um código em Cobol é o mesmo que ler um poema, e é tamanha a legibilidade de suas estruturas que elas permitem que qualquer novo programador intervenha no trabalho de outro com bastante facilidade. Quando se fala em legado de plataforma, o Cobol leva boa vantagem diante das outras linguagens.

O principal apelo do Acucobol é que um código gerado para uma determinada plataforma pode ser levado para qualquer outra sem a necessidade de recompilação. Isso acontece porque o código gera um objeto que será lido por um módulo runtime e é, portanto, interpretado. Sucede que a execução é extremamente rápida, ao contrário do que se espera de um código interpretado, e boa parte disso se deve ao tamanho desses objetos, e não raro encontraremos aplicações sofisticadas com apenas 4k.

Como banco de dados nativo ele usa o Vision, que trata arquivos com número ilimitado de registros e é totalmente portável, podendo exportar dados para diversos formatos e, mesmo não sendo um banco SQL, possui um driver de relacionamento, o ACU4GL, para Oracle, Sybase, Informix e muitos outros servidores de banco de dados. Esse driver de relacionamento trata os select, os create table e demais comandos SQL de maneira a obter os queries desejados em outros bancos e exportar essa "relação" para dentro do Vision. No mais, o desempenho do banco é aquilo que já se conhece do Cobol: velocidade e segurança.

Quanto ao módulo runtime que ocupa apenas 700k, não há como se notar diferença de desempenho entre os binários "puros" e os minúsculos objetos gerados pelo Acucobol, pois esse módulo chegou ao nível de concisão necessária para dispensar a compilação e equiparar a performance.

Para aplicações Web há as chamadas CGI dentro do próprio ambiente do Acucobol e que dispensam o uso de linguagens auxiliares como Perl, C ou Java, e com um tempo de resposta de solicitações literalmente "voador". É difícil apontar os nichos onde o Cobol domina fora do grande porte, mas em todos os bancos, em boa parte das empresas de transporte, nas indústrias de porte médio e grande, nas grandes construtoras, nas forças armadas e em outros locais em que o tráfego de dados é muito intenso, encontram-se com facilidade sistemas Cobol rodando há anos como um "relógio".

A Acucorp, a empresa americana de San Diego que desenvolve o Acucobol, realizou no ano passado um evento em conjunto com a Marinha americana para celebrar os 40 anos do Cobol. Desde que a brilhante oficial Grace Hopper criou a linguagem para uso interno do setor de inteligência da Marinha dos Estados Unidos, o Cobol saiu e conquistou o mundo dos negócios, construindo uma imagem de excelência e reputação inabaláveis.

No Brasil a distribuição oficial do Acucobol é feita pela Interon (www.interon.com.br) e no seu site podemos saber mais sobre a história de Grace Hopper e sua obra para construir uma linguagem que se autodocumenta e é fortemente orientada para os negócios.

 

Kylix

Ele era a ferramenta de desenvolvimento mais aguardada no mercado, pois alimentava a promessa de uma migração expressiva de diversas empresas para a plataforma Linux. No road show pelas capitais brasileiras, segundo as palavras de José Rubens Tocci, diretor-geral da Borland no Brasil, "não imaginávamos que houvesse tanto Linux na praça e nem que todas as software houses que desenvolvem para Windows estivessem interessadas no Kylix. Nunca houve tanto interesse por um produto nosso como agora".

O grande trunfo do Kylix é que ele é realmente RAD, como prometiam os press releases da Borland. Arrastar, soltar, preencher umas poucas caixas de diálogos e compilar, pronto! Em minutos obtém-se uma aplicação completa, com bases de dados, menus e caixas de rolagem na interface gráfica, botões e, o que é melhor, sem emulação de APIs Windows. O produto gera código 100% nativo de 32 bits para Linux. Essa era uma das desconfianças sobre o Kylix e que se mostrou infundada.

Outra grande surpresa é o lançamento de uma versão open source do Kylix prevista para o fim de junho e que tem gerado um número enorme de e-mails em nossa redação especulando sobre a possibilidade de distribuirmos essa versão no CD do Mês da RdL. Estamos sempre em contato com o pessoal da Borland aqui no Brasil e já manifestamos esse interesse, e se houver possibilidade, o faremos.

Conversando com David Intersimone, vice-presidente de relações com desenvolvedores e uma das principais cabeças da Borland americana, soubemos que eles se preocuparam em fazer do Kylix e do Interbase o que de melhor podem produzir, perseguindo exaustivamente uma otimização do compilador Object Pascal, uma interface bastante elaborada com uma camada de abstração de dados bem integrada a um servidor de banco de dados enxuto, robusto e confiável. David foi responsável por diversas versões do antigo Turbo Pascal e do Turbo C e conhece como poucos esses segredos. Ele disse que "num futuro muito próximo Kylix, JBuilder e C++ Builder serão um só produto".


A Revista do Linux é editada pela Conectiva S/A
Todos os Direitos Reservados.

Política de Privacidade
Anuncie na Revista do Linux