Fechar

sexta-feira, 9 de julho de 2010

É possivel usar o Lazarus em alternativa ao Delphi para desenvolver aplicações comerciais?

1 comentários
INTRODUÇÃO


IDE (integrated Development Environment) de desenvolvimento são ferramentas fundamentais para o desenvolvimento de sistemas, pois agilizam e facilitam o trabalho do programador. No entanto, há um problema no uso de ferramentas proprietárias, como o Delphi para o desenvolvimento de aplicações comerciais: o alto custo das licenças de uso, o que leva muitas vezes os desenvolvedores e as empresas ao uso da pirataria. Dessa necessidade surgem como alternativas os softwares de licença livre.
O Lazarus é um ambiente de desenvolvimento integrado que tem como objetivo ser compatível com a sintaxe Delphi, alem de suportar diversas arquiteturas e sistemas operacionais diferentes. Porém, é comum existir a dúvida se o software livre, nesse caso o Lazarus, é capaz de substituir inteiramente o proprietário, Delphi, na tarefa de construir um sistema.
Como modo de avaliação, foi proposta a idéia de construir um mesmo aplicativo no Delphi e no Lazarus que atendesse aos requisitos básicos de uma aplicação comercial. Desta forma seria possível medir as dificuldades e ao mesmo tempo avaliar o ambiente no Lazarus. Para este fim foi proposto o desenvolvimento do SUF, software de utilização financeira, que tem como objetivo ser uma ferramenta de apoio ao departamento financeiro de uma Fundação.
A escolha do SUF foi pelo fato de que seus requisitos continham características que interessavam a este experimento como ser multi-usuários, fazer acesso a banco de dados, ter cadastrado e pesquisa nos dados, possuir relatórios gerenciais e ser aplicação estável e confiável para uso no dia-a-dia.

1. Ambientes de Desenvolvimento


Para este experimento foi utilizado o Code Gear Rad Studio Delphi 2007. O Delphi 2007, apresentado na Figura 1, possui uma IDE semelhante ao Visual Studio da Microsoft, com o código e formulários centralizados e as barras de ferramentas nas laterais. A IDE permite a criação de diferentes áreas de trabalho facilitando para o desenvolvedor configurar o layout das ferramentas de acordo com o que está sendo feito. A IDE também permite instalar plugins de terceiros para adicionar novas funcionalidades.
Os componentes que acompanham a ferramenta permitem criar desde aplicações simples até aplicações mais robustas, sendo que se for necessidade o desenvolvedor pode criar seus próprios componentes e instalar componentes de terceiros.
Para a depuração de aplicativos, o Delphi possui ferramentas de visualização de pilhas de chamadas de funções, visualizador de conteúdo de variáveis, variáveis locais, o assembler que está sendo executado no processador, break points dentre outros. O Delphi possui ainda tecla de atalho para a maioria de suas funcionalidades.



Figura 1 Delphi 2007
Fonte: Autoria Própria



O Lazarus, apresentado na Figura 2, possui o visual muito semelhante ao Delphi 7, apresentado na Figura3, umas das versões mais usadas do Delphi, com as barras de ferramentas e editor de código flutuantes. O Editor de código fonte do Lazarus possui mais recursos do que os oferecidos pelo Delphi, como o formatador de código nativo e uma ferramenta para comentar e descomentar blocos de códigos.
O Lazarus traz os componentes que são mais básicos para o desenvolvimento de aplicações já pré-instalados e outros como o editor de relatórios, no seu diretório padrão de componentes que podem ser instalados a posterior. Assim como no Delphi o Lazarus permite que o desenvolvedor crie seus próprios componentes ou instale componentes de terceiros.



Figura 2 Lazarus
Fonte: Autoria Própria




Figura 3 Delphi 7
Fonte: Autoria Própria



As ferramentas de depuração de aplicativo seguem a mesma linha do Delphi, porem ainda precisam ser aprimoradas como é o caso do visualizador de conteúdo de variáveis que não “enxerga” o valor de uma variável que esta em outra unidade e o visualizador de assembler que não mostra muita informação. As teclas de atalhos das funcionalidades do Lazarus também são semelhantes as do Delphi. Atualmente o Lazarus está na versão 0.9.28.2 beta e para este experimento foi usado a versão win32 para Microsoft Windows XP.

1.1. Desenvolvimento


A idéia para o desenvolvimento surgiu da necessidade de uma Fundação cuja principal atividade é a pesquisa e presta serviços de controle de projetos a qual fica responsável também o gerenciamento de suas receitas e despesas necessitando de um sistema que atenda a essa demanda. A missão do SUF é ser uma ferramenta de software que satisfaça as necessidades da fundação, tanto para lançamentos financeiros como para realizar consultas proporcionando aos usuários agilidade em suas atividades.
A modelagem do SUF foi criada seguindo o documento de requisitos e o de caso de uso do Praxis e em seguida as tabelas com os respectivos relacionamentos no banco de dados. Os casos de uso do sistema podem ser vistos na figura 4.

Figura 4 Diagrama de Caso de Uso do Sistema SUF
Fonte: Autoria Própria

Para o gerenciamento do banco de dados, foi usado o Firebird, visando algumas das suas vantagens como: exige pouco processamento, pode ser instalados em computadores mais antigos evitando assim que se faça novos investimentos, gerencia bem banco de dados pequenos, é multi-plataforma e gratuito, mais comumente usado por programadores Delphi.
Na etapa seguinte foi desenvolvido o protótipo do SUF no Delphi. O desenvolvimento inicializou com a criação de uma tela padrão de cadastro da qual seriam herdadas as funcionalidades para construção das demais telas de cadastro reaproveitando o código. Ao final da criação das telas foram desenvolvidos os relatórios do sistema para a apresentação dos dados de forma mais agradável e organizada ao usuário.
Em seguida, o protótipo do SUF foi migrado para a plataforma do Lazarus, seguindo o mesmo processo de criação no Delphi. Após a instalação dos componentes, foram desenvolvidas, assim como no Delphi, as telas de cadastro reaproveitando o código já escrito no protótipo do Delphi. Para esta tarefa foi utilizada a ferramenta de migração de formulários disponível no Lazarus.
Durante o desenvolvimento do protótipo no Lazarus foi feito o levantamento das dificuldades encontradas na implementação para a comparação posterior.
A plataforma de hardware usado para o desenvolvimento do SUF tanto no Delphi como no Lazarus foi um notebook Amazon PC com processador Turion 64x2 1.6GHz, 250 GB de disco rígido e 4 GB de memória RAM.

2.1. Ambiente Delphi

Após a criação do banco de dados foi preparado o ambiente para o desenvolvimento primeiramente no Delphi com a instalação dos componentes de acesso a dados e gerenciador de relatórios.
Para o acesso a dados foi instalado o componente ZEOS Library visando manter compatibilidade no momento da exportação do código-fonte para o Lazarus já que a ZEOS Library também possui uma versão para o Lazarus. O gerenciador de relatórios usado no Delphi foi o Quick Report devido a sua semelhança de interface com o Lazarus Report.
Antes de iniciar a codificação dos formulários foi desenvolvido primeiro a interface padrão de usuário do SUF. Inicialmente foi planejada uma tela na qual o usuário pudesse visualizar os registros, navegar por eles e aplicar filtros e outra tela onde os registros fossem cadastrados e alterados.
Seguindo essa linha foram criados dois formulários padrões. No formulário para as operações de visualização/recuperação dos registros foi colocado um grid para exibir todos os registros e uma barra de ferramentas para a manipulação dos mesmos, além de um filtro. No formulário de cadastrado e edição, foi inseridos um contêiner onde poderão ser colocados os campos nos formulários filhos e uma barra de ferramenta com opções para cancelar e salvar o registro que está sendo criado/alterado.
Com a interface já criada, deu-se inicio a escrita do código onde foi inserido rotinas genéricas para salvar, recuperar, criar e alterar os registros do banco de dados além de rotinas para tratamento de erros. Essas rotinas tem a finalidade de poupar tempo na construção dos formulários filhos, sendo que na maioria das vezes não será preciso escrever nenhum código, bastando apenas "montar" a interface e associar a fonte de dados.
O formulário principal foi desenvolvido levando em conta que este deveria gerenciar os demais formulários, criando, exibindo e desalocando da memória. Com isso foi colocado um menu contendo a referencia para cada formulário criado .
Com o formulário principal e os formulários padrões de manipulação de registro criados, deu se inicio a criação dos demais formulários de cadastrado de acordo com os casos de uso. O primeiro a ser desenvolvido foi o de cadastro de clientes para o qual foi criado um novo formulário herdado do formulário de visualização e um outro herdado do formulário de cadastrado/edição.
Na tela de visualização foi preciso apenas associar a fonte de dados ao a grid. No formulário de cadastrado/edição foi colocados os controles para cada campo já ligando-os a fonte de dados. Após esta etapa o formulário já estava funcional e foi adicionado ao menu na tela principal.
Os demais formulários: cadastro de projetos, fornecedores, departamento, rubrica, bancos, usuários, contas a pagar e contas a receber, seguiram o mesmo processo. Somente o formulário de cadastrado de "valores impostos" é que não herdou dos formulários padrões devido a sua interface ser diferente.
Ao término da criação dos formulários, foram cadastrados alguns registros no banco de dados para que houvesse dados para possibilitar o desenvolvimento dos relatórios. Foi construído dois relatórios para o sistema, com a interface padronizada, com um cabeçalho e descrição de cada campo. Depois de finalizado o desenvolvimento do SUF no Delphi, deu-se inicio a preparação do ambiente no Lazarus e ao desenvolvimento do SUF neste ambiente.



Figura 5 Tela Principal do SUF no Delphi.
Fonte: Autoria Própria




Figura 6 Tela Principal do SUF no Lazarus
Fonte: Autoria Própria






Figura 7 Relatório do SUF no Delphi.
Fonte: Autoria Própria




Figura 8 Relatório do SUF no Lazarus.
Fonte: Autoria Própria




Figura 9 Tela de cadastro do SUF no Delphi.
Fonte: Autoria Própria



Figura 10 Tela de cadastro do SUF no Lazarus.
Fonte: Autoria Própria


2.2. Implementação no Lazarus e Limitações Encontradas


O objetivo maior desse experimento é fazer o levantamento das limitações da IDE do Lazarus e o impacto de uma migração de projetos para que seja possível analisar a possibilidade de seu real uso em desenvolvimentos de aplicações comercias.
O primeiro passo foi preparar o ambiente do Lazarus para o desenvolvimento como no Delphi instalando a ZEOS Library. Tentou se instalar a versão disponibilizada no site sourceforge.net, porém está versão apresentou uma serie de problemas e não conseguia conectar se ao banco de dados. Foi preciso pedir ajuda em uma lista de discussão especializada em Lazarus. Um membro da lista sugeriu uma versão que ainda está em fase de desenvolvimento mas que acabou funcionando. Após a instalação da ZEOS Library deu se inicio a instalação do Lazarus Report para a criação dos relatórios, este não apresentou nenhum problema.
Preparado o ambiente, iniciou-se a criação do projeto para a aplicação e ao criar um novo projeto no Lazarus apareceu um bug que não permite que se faça uma compilação sem antes salvar o projeto, fato que não causou problemas para o desenvolvimento, mas que foi custoso encontrar o motivo. Com a criação do projeto deu se inicio a criação dos formulários seguindo as mesmas etapas que no Delphi iniciando-se pelos formulários padrões.
Na criação do formulário de cadastro/edição e do formulário do visualização que fazem uso dos componentes de acesso a dados foram encontrado mais algumas dificuldades. Houve problemas para associar o Datasource a um Dataset que estava situado em um DataModulo. O componente Query que faz consultas ao banco de dados, na versão para o Lazarus, não possui mascara para edição de campos o que obrigou a instalação de um componente DBMaskedit para conseguir colocar mascara nos campos de edição.
O componente DBGrid do Lazarus é mais avançado do que o Delphi tanto em aparência quanto em funcionalidades, apesar de não possuir alguns eventos como o "DefaultDrawDataCell" . Mas a grande vantagem é que o desenvolvedor não precisa escrever código para pintar as zebras nas linhas do DBGrid, pois o componente já possui esta funcionalidade.
Herança visual é muito importante para reduzir o número de telas em uma aplicação e para reaproveitar o código. Nesse ponto uma limitação do Lazarus está em não adicionar a palavra-chave "inherited" automaticamente aos métodos herdados o que provoca erro nas rotinas que acabam não executando o código do pai.
No desenvolvimento do formulário principal, houve dificuldades para manipular o componente MainMenu, responsável por criar o menu de navegação na tela, devido a sua forma de “trabalhar” ser diferente a do Delphi. Também houve dificuldades para se “visualizar” um componente do tipo “Panel”, que faz o papel de contêiner, ocorrendo que é muito fácil confundi-lo com o próprio formulário.
Foi encontrada algumas limitações quanto ao uso de imagens no projeto: como que a IDE não suportar ícones de tamanho 24x24 obrigando a se fazer um redimensionamento dos ícones que foram usados no Delphi. Também não é possível visualizar as imagens contidas uma ImageList ao fazer um relacionamento de um objeto com um ícone. E ao alterar um ícone em actionlist o objeto que está vinculado a esta ActionList não atualiza o ícone sozinho, é preciso fazê-lo manualmente.
Na codificação do formulário foi usado o mesmo código que do Delphi e foi encontrada a falta da função LockWindowUpdate que faz referência a API do Windows, fato que é justificado pelo Lazarus ser multi-plataforma. Também não foi possível fazer com que a aplicação se comportasse como MDI, onde os formulários são aberto dentro de outros formulários. Outro problema é que quando não se faz mais uso de procedures que são declaradas automaticamente pela IDE, como é o caso de um clique de botão, a IDE não remove o código da procedure como ocorre no Delphi e é necessário remover manualmente.
As ferramentas de depuração de código não conseguiram ser tão eficientes quanto as do Delphi, como é o caso do dialogo de visualização de variáveis que não consegue visualizar o conteúdo de uma variável que está em outro modulo obrigando o programador a usar recursos antigos como dar um showmessage na variável para ver seu conteúdo. O compilador também gasta um pouco mais de tempo para gerar os binários da aplicação.
Quando o aplicativo está em execução e por alguma razão gera alguma exceção, é exibida uma mensagem genérica na tela, sem muita informação da origem do erro, isto pode ser um grande problema para o programador encontrar o que está gerando o erro.
O executável gerado possui um tamanho 23 vezes maior do que o criado no Delphi que estava com 2,67MB e no Lazarus com 45 MB. Mais tarde descobriu-se que uma configuração na IDE que reduziu o tamanho para 3,02MB. Ao usar esta configuração as opções de depuração não funcionaram mais.
A interface do Editor de relatório dificultou um pouco para encontrar o componente label, e em alguns momentos a IDE fechou abruptamente perdendo todo o trabalho que foi feito e que não havia sido salvo. Também não foi encontrada uma “régua” para auxiliar no posicionamento dos componentes na tela. Por outro lado, foram feitos testes com o aplicativo em execução onde foram gerados relatórios de 100 páginas e não houve nenhum problema.
Apesar de dar suporte ao código escrito no Delphi o Lazarus não permite portar componentes feitos para Delphi o que pode dificultar a migração de aplicações que usam componentes mais específicos, ou proprietários como impressoras fiscais, controle de portas seriais dentre outros.

3. Conclusões


O Lazarus possui um ambiente de trabalho semelhante ao Delphi como teclas de atalho iguais e alguns recursos em sua IDE mais avançados do que os do próprio Delphi. Tem a capacidade de compilar o mesmo projeto para diferentes plataformas dando uma vantagem competitiva para as aplicações.
O Lazarus consegue ainda compilar quase todo código escrito em Delphi. A maioria das classes, unidades e propriedades tem o mesmo nome e funcionalidades, ainda não é possível ter uma compatibilidade de 100%, mas é possível converter muito código entre eles. Com exceções de algumas classes que ainda não foram implementadas em sua estrutura.
Não é possível portar para o Lazarus componentes feitos para o Delphi devido a forma como os componentes são organizados, sendo assim alguns componentes como os que controlam impressoras fiscais, balanças e outros periféricos poderiam não existir no Lazarus, ficando o desenvolvedor dependente dos fabricantes realizar a portabilidade.
Desenvolver no Lazarus em sua versão atual, exige um pouco de esforço no sentido de que o usuário precisa algumas vezes procurar ajuda para resolver problemas de bug da ferramenta, o que pode ser um agravante para novos programadores que podem confundir os bugs e achar que são defeitos em seu código fazendo com o Lazarus perca em credibilidade.
A conclusão final é que seu uso para o desenvolvimento de aplicações comerciais de maior porte, apesar de possível, não é aconselhável. O Lazarus não está completo, existem pontos que ainda precisam ser melhorados pela comunidade, como bugs na IDE que ás vezes causam seu fechamento repentino e principalmente melhorar o depurador de código que às vezes obriga o programador a usar artifícios arcaicos para ver um simples conteúdo de uma variável.
Por outro lado, conclui-se que o futuro da ferramenta é promissor, a sua grande vantagem está em ser de código aberto e receber contribuições de toda comunidade. A portabilidade para outras plataformas é um diferencial tremendo para a maioria das empresas que ficam sem uma solução para a portabilidade de aplicativos escritos em object-pascal.
É preciso que novas pessoas se juntem ao projeto, programadores, documentadores e beta-testers para que a ferramenta possa ficar pronta e está apta a trabalhar com grandes aplicações.

3.1. Experimentos Futuros


Seguem algumas opções no que diz respeito ao uso do Lazarus para simular o Delphi. Abaixo estão algumas dessas possibilidades:


· Aplicação multitarefa

Uma aplicação multitarefa é aquela em que executa códigos em paralelo. Muito útil para processamento em massa, onde se faz melhor uso dos processadores e permiti que o usuário trabalhe livremente enquanto o sistema continua executando uma tarefa. A idéia principal é escrever e uma aplicação utilizando o Lazarus e analisar o seu comportamento ao trabalhar com threads podendo ir também ao sentindo da computação distribuída.

· Portabilidade

Este trabalho abre a possibilidade de se fazer a portabilidade do sistema SUF desenvolvido no Lazarus ser portado para outros sistemas operacionais como o Linux e observar o comportamento da aplicação nesses sistemas. Levando em consideração a chamadas de sistemas, comunicação com o banco de dados, performance da aplicação.

· Analise do Projeto

O Lazarus existe desde 1999, e ainda não está concluído, realizar um levantamento do projeto e apontar para a comunidade onde é preciso focar mais e propor campanhas para atrair mais pessoas e empresas para o projeto.





quinta-feira, 8 de julho de 2010

Auto Complete no apt get e no aptitude

0 comentários
Auto Complete no apt get e no aptitude

O auto complete do shell é um recurso muito útil, então porque não adciona-lo no apt-get e no aptitude para instalar pacotes?
Para usa-lo é preciso habilitar as linhas no arquivo .bashrc que fica no diretório do /root/

if [ -f /etc/bash_completion ]; then
. /etc/bash_completion fi


Ou então copiar diretamente este arquivo para /root/.basrc:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# don't overwrite GNU Midnight Commander's setting of `ignorespace'.
export HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
# ... or force ignoredups and ignorespace
export HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

#if [ -f ~/.bash_aliases ]; then
# . ~/.bash_aliases
#fi

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
eval "`dircolors -b`"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi


Obs: para usar este recurso é preciso ter o pacote bash-completion instalado!





Um pouco da História do Delphi

0 comentários
Um pouco da História do Delphi


Nos primórdios da computação não havia integração entre as ferramentas usadas para a programação dos computadores. Com isso o programador precisava usar editor de textos, compilador, linkeditor e depurador separadamente, perdendo um tempo precioso. Em 20 de Novembro de 1983, surgiu o conceito inovador de IDE (Integrated Development Environment) com o Turbo Pascal da Borland, que reunia todas as ferramentas em um único aplicativo .
Em 1990, a Microsoft evolui o conceito de IDE para RAD (Rapid Application Development) com o lançamento do Visual Basic. As novidades trazidas era uma IDE bem incrementada focado no desenvolvimento visual de sistemas (o programador só precisava arrastar e soltar componentes sobre um formulário). Desenvolver usando o Visual Basic era duas vezes mais rápido do que no Turbo Pascal, o que lhe trouxe grandes vantagens competitivas no mercado.
Seguindo o caminho do Visual Basic e do Turbo Pascal, surgiram também ferramentas RAD para outras linguagens como o Watcom, C++, SQLWindows e PowerBuilder.
Essa evolução no desenvolvimento de softwares seguiu sempre no sentindo da abstração. Juntando elementos simples o programador podia construir sistemas complexos e se preocupar mais com as regras de negocio envolvendo o projeto do que com o desenvolvimento em si, ganhando em produção .
Para não ficar a trás das inovações do Visual Basic, em 1993 a Borland começou o desenvolvimento de uma nova ferramenta baseada na linguagem orientada a objetos Object Pascal, com o nome de Delphi. O Delphi só foi lançado no mercado em 1995. O grande diferencial dessa ferramenta em relação ao Visual Basic era o compilador para Win32 e a exploração da API do Windows, pontos que o Visual Basic ainda não explorava.
No ano de 2002, com o lançamento da primeira versão da plataforma .Net houve novas mudanças no conceito de Ferramenta RAD com o Microsoft Visual Studio .NET. Antes os componentes eram fechados e faziam tudo por si só, o programador precisava apenas fazer algumas configurações. No conceito trazido pelo .Net, os componentes ainda tem configurações, porém o código-fonte que é gerado quando se arrasta o componente para a formulário, é acessível ao programador que pode personalizá-lo da forma que bem entender.
O Delphi teve o formato da sua IDE alterado pela primeira vez na desde seu lançamento na versão 8, ficando similar ao formato do Microsoft Visual Studio, inclusive gerando código para a plataforma .Net. A versão posterior, Delphi 2005, passou também a integrar no mesmo ambiente de desenvolvimento a possibilidade de se desenvolver aplicações usando Delphi, C++ Builder ou C#.

REFÊRENCIAS

LION, Raphael, História do delphi, 17 de outubro de 2007, Disponível em http://www.xtibia.com/xsite/component/xcontent/?task=post&id=249970, Acesso em 22 mar. 2010.

SOMERA, Guilherme. Treinamento Profissional em Delphi. ed. Digerati Books, São Paulo, 2007. ISBN: 978856048012-8

BUFALO, Rapid Application Development - ser ou não ser rápido ?, Julho de 2008. Disponível em http://www.bufaloinfo.com.br/ExibeNoticias.aspx?entryid=6868785682753498. Acesso em 23 mar. 2010.

REVISTA DO LINUX, Ambientes Integrados, Disponível em http://www.lenep.uenf.br/~bueno/DisciplinaSL/MANUAIS/00SOFTWARE_LIVRE/REVISTAS/RDL/029/desenvolvimento.html. Acesso em 22 mar. 2010.


Mais Populares

Seguidores

Є & V. Copyright 2011 Evaldo Avelar Marques - sprintrade network