Onde estão os programadores da era DOS?

hra

No final dos anos 90 o Brasil vivia uma grande fase no desenvolvimento de software. Havia um programador CLIPPER em cada esquina. E um valkyrie em cada beco. E cadê esses tantos programadores? Porque não há Free Software para a locadora, pra farmácia, pro mercadinho? Passou da hora desses programadores colocarem aqueles fontes a disposição da comunidade Linux pra que eles sejam evoluídos.

[ Hits: 22.808 ]

Por: Hamilton R. Amorim em 03/05/2005 | Blog: http://www.algorista.tk


Hora de liberar a imensidão de código CLIPPER que está abandonada na gaveta



No final dos anos 90 o Brasil vivia uma grande fase no desenvolvimento de software. Havia um programador CLIPPER em cada esquina. E um valkyrie descompilando em cada beco.

E cadê esses tantos programadores? Porque não há Free Software para a locadora, pra farmácia, pro mercadinho, ...? Passou da hora desses programadores colocarem aqueles fontes à disposição da comunidade Linux pra que eles sejam evoluídos.

Hoje existe Free Software pra muita coisa, existe substituto pra qualquer programa importado, existem planilhas, editores de imagens, tocadores de música, etc.

Mas não tem aquele sisteminha pra locadora, pro dentista, pra farmácia. Esse tipo de programa foi o grande mercado do CLIPPER no Brasil. Existiam, e de fato ainda existem, muitos programadores que viviam exclusivamente disso. Produziam os programas sob-medida.

O negócio era começar sempre do zero. Chegava na locadora e ia pegando as informações, dali um mês tinha um programa sob-medida para as necessidades daquele cliente. No próximo era o mesmo trabalho.

O Linux precisa desse tipo de aplicação. Mesmo que rodando com telinha texto e quase sem atrativos (comparados às tela gráficas), esses programas ainda são extremamente práticos. Há quem não troque eles justamente porque não precisa de mouse.

O mercado continua praticamente o mesmo, todo mundo continua usando os programas feitos naquela época.

É hora de acordar pra esse mercado que tem muitas possibilidades. Imaginem ter em mãos um programa de "consultório dentário" feito em PHP. Agora imaginem quanto consultórios dentários estão interessados num programa desse tipo a um baixo custo.

E veja o mercado: customização! Nesse tipo de atividade ninguém instala e sai usando, sempre tem que adaptar as necessidades específicas: trabalho para centenas de programadores pelo Brasil.

É necessário liberar os velhos códigos fontes pra que eles sejam redesenvolvidos em linguagens e ferramentas novas. Existem milhares de programadores capazes no Brasil. Mas quantos desses sabem como funciona uma clínica dentária? Então quantos desses estão aptos a fazer um sistema pra uma clínica?

Criar esses programas não é como criar um utilitário, não é fazer alguma coisa e ir melhorando. Criar um aplicativo comercial exige conhecimento da área onde o programa irá atuar. E esse conhecimento exige análise, reuniões com o usuário, desenvolvimento, testes, conversas e redesenvolvimento.

E é isso que falta para o desenvolvimento Open Source engrenar nessa área, esse conhecimento. Se não é fácil colocar uma estação Linux numa empresa, imaginem coletar informações pra desenvolver algo que ficará a disposição de qualquer um. A mentalidade do empresário brasileiro ainda levará décadas pra entender isso.

Mesmo não tendo custo algum o empresário ainda quer guardar sigilo de seus processos e procedimentos administrativos. Porque? Só ele sabe, e não conta pra ninguém.

Nisso entram os programadores da antiga era DOS. Disponibilizar os velhos programas pode parecer inútil, mas não é. Neles está o conhecimento necessário pra criar novos programas, em ferramentas novas, e com linguagens modernas.

Um sistema Open Source em PHP para administração de locadoras seria um bom começo. Mas como é mesmo um sistema de locadora? Quais as necessidades de uma locadora? a resposta pode ser simples, mas não é.

Uma simples "locadora de vídeo da esquina" tem em seu computadorzinho o controle de tudo que entra e sai de lá. Desde o que foi comprado pra lavar o banheiro, até a folha de pagamento dos funcionários. Não é tão simples, não é apenas registrar a fita alugada e a devolução. Tem que ter suporte pra promoções, a tabela de preços é flexível de acordo com a data. Tem um faturamento diário e um mensal.

A coisa é séria, não é um bloco de notas com funções especiais.

Um programa novo tem que fazer tudo que o antigo faz e ainda melhor, senão é deixado de lado.

Nisso os fontes antigos seriam uma mão na roda, lá já tem todas as telas, todas as idéias, os relatórios, as soluções. Já está feito, é só reescrever aproveitando as idéias.

É preciso mudar a mentalidade. Esses programas já são passado, mas se forem postos à disposição da comunidade Open Source, eles podem se tornar o futuro e o ganha pão de milhares de brasileiros, inclusive você.

   

Páginas do artigo
   1. Hora de liberar a imensidão de código CLIPPER que está abandonada na gaveta
Outros artigos deste autor

Copiando programas dos LiveCDs (Kurumin) para seu Debian sem usar a internet

Porque tanta gente não usa o Linux? Será que o Linux é ruim mesmo?

Como fazer: Chroot Dosemu (Clipper no Linux)

Como fazer: chroot SSH (SSH mais seguro)

A miséria social do Brasil e o software proprietário

Leitura recomendada

Mais uma análise entre Windows e Linux

Como softwares livres podem gerar lucro

Consumo de memória dos ambientes gráficos do GNU/Linux

Projeto Xen - Visão Geral

A síndrome do noob kalinista + como quebrar senha Wi-Fi

  
Comentários
[1] Comentário enviado por removido em 03/05/2005 - 07:48h

Muiito bem lembrado, Hamilton. Esta é uma área em que, se não estou enganado, não há NADA disponível pra download nos repositórios Linux, de nenhuma distribuição.

E pra "cutucar" essa legião de desenvolvedores anônimos de Clipper, é bem provável que muitos deles usem abundantemente o software livre, mas se esquivem de compartilhar esses programas. Talvez muitos até estejam lendo seu texto como membros do VOL.

Parabêns pelo artigo que bem serve como um "puxão de orelhas".

Wesley

[2] Comentário enviado por k2 em 03/05/2005 - 07:55h

É Hamilton é mais ou menos que eu quis dizer em meu artigo publicado aqui no VOL sobre o Linux e Automação Comercial.Caso não tenha lido dê uma olhada em meu profile.

Parabéns pelo artigo!

[3] Comentário enviado por brevleq em 03/05/2005 - 08:17h

Cara, excelente artigo, se esse programas fossem feitos para o linux, com certeza agora eu não estaria brigando pra tentar emular um programa desse com o dosemu e wine.

[4] Comentário enviado por celsonetibr em 03/05/2005 - 11:30h

Como eu faria para disponibilizar meus sistemas em clipper com os fontes? Disponibilizo assim como estão (o EXE e os PRG)? Talvez devesse disponibilizar alguma documentação para desenvolvedor ler, como um DER, e comentar bem os fontes... mas isso demanda tempo. Como fazer? Alguém já fez isso e tem dicas para dar?

[5] Comentário enviado por hernandez em 03/05/2005 - 11:39h

Eu concordo contigo, porem alguem tem q organizar isso e puxar a fila.... Eu libero alguns sistemas desde que alguem administre e faça funcionar seriamente....
[]s

[6] Comentário enviado por jp em 03/05/2005 - 12:09h

Muitos programadores de Clipper migraram para Delphi e persistem no Delphi. Os programas para Windows (Delphi) tem certas vantagens e desvantagens com relação aos programas antigos, com certeza. Uma das desvantagens mais destacáveis é que muitos usuários estão acostumados com os sistemas antigos de Clipper, e estranham bastante um programa no Windows. Mas sem querer defendê-los, muitas interfaces pecam ao tentar ser criativas em cada pixel da tela, em vez de criarem uma interface padronizada com o que um usuário esperaria de um programa Windows comum.

Também, o seu programa de "1 mês", na verdade vai ganhando "galhos" conforme ele vai sendo alterado para adequá-lo a mais necessidades dos clientes, assim na verdade o trabalho é bem grande em fazê-los, embora não pareça. Assim, cada cliente do programa vai querer alterações para adequar o programa aos seus processos, porém isso significa uma profusão de código novo ou código copiado e colado, o que por si só é difícil de manter. No geral, é bom deixar o desenvolvimento, a venda e o suporte desses programas com os próprios programadores, pois só eles podem persistir ao longo dos anos dando suporte a eles. Só que o tempo do programador pode ficar caro, obrigando-o a cobrar mais dos seus clientes para poder continuar crescendo, e quem sabe contratar outros programadores para ajudá-lo.

Hoje em dia eu vejo que o cliente busca uma aliança que perdure no tempo com o programador, mas ambos tem que buscar a melhor capacitação para que essa aliança seja boa para ambos pelo maior tempo possível. O cliente tem que arcar com os custos, caso eles aumentem. E o programador tem que ser capaz de responder efetivamente a pedidos de melhoria no programa.

Qualquer intermediário nesse esquema pode ser prejudicial ao negócio. :-)

[7] Comentário enviado por Xxoin em 03/05/2005 - 12:13h

Hamilton, parabéns pelo artigo e mais ainda pela idéia!
Seria simplesmente fabuloso isto ser posto em prática, minha contribuição será tentar convencer umas poucas pessoas que conheço e têm algo do tipo...

[8] Comentário enviado por Nigthwing em 03/05/2005 - 12:14h

Uma coisa parece que passou despercebida.
A meu ver a imensa maioria dos antigos programadores Clipper migrou para o Delphi. Não que estejam fazendo programas melhores que os da época do Clipper, mas migraram já que sua ferramenta morreu(?). Já vi muitas farmácias que num dia têm o programinha em Delphi, mas na semana seguitne estão rodando o antigo em Clipper. Não basta fazer um novo programa. Ele tem que ser tão útil e prático quanto o anterior.

[9] Comentário enviado por tarcio em 03/05/2005 - 12:15h


Esta dica é para quem quer compilar o codigo CLIPPER diretamente no LINUX, sem nenhuma ou quase nenhuma modificação.

http://www.vivaolinux.com.br/dicas/verDica.php?codigo=1791

Na empresa em que trabalho já migramos 5 sistemas completos que usam base de dados DBF para LINUX sem nenhum problema.

Um problema mais comum é o "case sensitive" que no código clipper está referenciado minusculo e os arquivos podem estar em maiúculo. Mas sem contar isso nada impede do código ser compilado sem nenhum problema.

[10] Comentário enviado por rafaelreissouza em 03/05/2005 - 13:26h

Eu tb migrei o sistema aqui da empresa que era em clipper para xharbour funcionando tudo em linux...

Ficou perfeito .. muito muito muito rapido !!!!

Ex.: tinha uma operação que levava 7 minutos no antigo novell e uma estação XP P4 512 rodando em um servidor LINUX está levando 30 segundos ...

Tb gostaria de compeender melhor alguns conceitos e contribuir ...

Abraços

Contato Rafael
rafael@rolemar.com
Londrina - PR



[11] Comentário enviado por xnardelli em 03/05/2005 - 13:57h

Gostaria de parabenizar a iniciativa.
Tudo relacionado em software é passível de desenvolvimento. E nada melhor para evoluir em cima de erros passados. E nada melhor do que utilizar o conhecimento dos sistemas antigos nas novas aplicações livres desenvolvidas.
Assim, por enquanto deixo apenas o meu apoio ideológico, pois compartilho das idéias relacionadas ao software livre, principalmente quando estamos falando do Brasil.
A automação comercial em pequenas empresas no brasil, utilizando-se estes programas que exigem pouco equipamento, será um grande avanço social, onde as pequenas empresas, massacradas com a carga tributária, possam ter maior controle de seus estoques, custos e etc, sem ficar na ilegalidade ou arcar com os altos custos dos sistemas que conhecemos.
Muito boa sorte nesta nova empreitada...

[12] Comentário enviado por hra em 03/05/2005 - 14:57h

Para os que querem começar:

- Existem soluções para compilar o antigo código fonte quase sem modificação. Notavelmente xHarbour faz um bom trabalho compilando clipper.

- Quem não dispõe de tempo mas quer contribuir basta juntar os fontes com qualquer outra informação que dispor, colocar num site e deixar as instruções para quem quiser aproveitar o código, não esquecendo de deixar claro uma licenca (GNU, GNU Lesser, Dominio Publico, Creative Commons, etc), e é claro uma maneira segura de se comunicar com você para alguma eventualidade.

Para essa opção tem vários serviços que oferecem espaço e ferramentas adequadas, por exemplo o:

codigolivre.org.br

Nesse site você dispõe de tudo que precisa para liberar seu código fonte. Existem muitas outras opções com o sourceforge.net e o querencialivre.rs.gov.br

Uma vez que o código está livre os interessados darão uso adequado a ele. E os créditos iniciais nunca deixarão de ser do autor original (mesmo que seja só uma nótinha: "baseado em parte no código do fulado").

Eu teria lançado dezenas de programas clipper no OpenSource, mas meus disquetes (a maioria de 5 1/4) melaram de tanto tempo guardados.

Sucesso a todos nós
E viva o linux.


[13] Comentário enviado por removido em 03/05/2005 - 18:05h

Ótimo artigo sempre que vou em uma locadora ou na rodoviárioa aqui em Porto Alegre fico olhando aqueles micrios antigos rodando DOS e fico imaginando como a vida dos computadores seria melhor se fosse com linux, já que aqueles micros teriam muito mais poder de fogo :), pena que as pessoas não fazem questão de entender que o linux embora no modo texto seja parecido com o Dos ele tem muito mais aplicações e aproveitamento de Hardware.

MAS UM DIA VÃO ETENDER!


[]s

[14] Comentário enviado por randra em 04/05/2005 - 10:27h

artigo 10! mto bem feito e mto bem explicado... acho que ninguem aqui tem duvida que varias maquinas, como voce diz de dentistas, locadoras... farmácias... enfim ... acho que todas poderiam rodar um sistema linux... somente em modo texto, só que o problema disso é que ninguem chega para essas pessoas, oferecendo ou simplesmente chegam oferencendo e nao dao assistencia, querendo ou nao a assistencia linux no brasil ainda nao tem comparação com assistencia em windows, pagam mais caro por isso pagam... só que nao sabem de tudo que existe mundo a fora que eles ainda nao utilizam...

[15] Comentário enviado por marrento em 05/05/2005 - 14:08h

vejo várias aplicações interessantes de tecnologias de software livre nessas áreas:

* Aplicações cliente-servidor usando GTKpixbuff para não necessitar de um servidor X em um terminal que só vai rodar o aplicativo mesmo
* Aplicações web com terminais rodando sem servidor X, usando Lynx para acessar um servidor web
* Aplicações web rodando em terminal com um servidor X e um único aplicativo ( o navegador )
* Aplicativos cliente-servidor rodando em uma estação thin-client

Por fim, porque PHP? Hoje há tecnologias melhores do que Clipper e linguagens mais organizadas como Python ou Ruby. Em todo caso, melhor em PHP do que uma lambança Java ou ASP.NET.

[16] Comentário enviado por Hernando em 05/05/2005 - 15:03h

Cara muito bom!!! Sou desenvolvedor de aplicativos comerciais (e-commerce) voltados para web e sou obrigado a dizer que por mais de 1 vez fui obrigado a estudar o software que o meu cliente usava para desenvolver algo em cima dele... Hoje temos recursos que podem ser muito mais vantajosos do que aqueles sistemas onde temos a parte administrativa, a parte que roda apenas na intranet e podemos disponibilizar o mesmo sistema para internet tambem... e é isso que faço... pego esses sistemas antigos, crio a idéia em torno de suas aplicações e determino oque é interno, administrativo e externo... Realmente sou obrigado a concordar que esses fontes seriaum duas mãos na roda...

[17] Comentário enviado por gransoft em 05/05/2005 - 19:37h

ARAGUARI-MG, 5 de maio de 2005.

Prezados Srs.,

Estamos aqui sim... e na ativa!

Com bons algorítmos, seja em Microfocus-Cobol, Dataflex e TAMBÉM em CLIPPER 5.2e, continuamos desenvolvendo Aplicativos Comerciais Multiusuários, em conformidade com a Legislação pertinente, atendendo layouts do SINTEGRA, PED e o tal SAPI - aqui em Minas Gerais.

Agora, o tal "programador" virou "Responsável Técnico", necessitando de Pessoa Jurídica, e segundo o Novo Código Civil, passou a ser "Solidário e Conivente" juntamente com os Contabilistas, pelas informações Fiscais dos Empreendedores... talvez um pequeno entrave para disponibilizarmos nossos fontes como OpenSource/Domínio Público...

Eu não apreciaria ser intimado lá no Pará, porque um "contribuinte" alterou meus originais (que logicamente estavam documentados pelo MD5), e passou a errar (para menor!) na Base de Cálculo do ICMS...

Não obstante às exigências legais, com muita determinação, experimentamos todas as opções "console" para GNU/Linux, tais como o caríssimo FlagShip e o OpenSource xHarbour, sucessores do Clipper.

A intenção maior, prioridade mesmo, era e ainda É, sair definitivamente do S.O.Windows, em detrimento de interfaces gráficas nos Aplicativos.

Para quem optou pelo Delphi, questiono: Como manter upgrades, que em último orçamento que fiz, ultrapassou R$4.500,00. Kylix ? Vai por aí também.

Desenvolvimento com ferramentas "piratas"? Se pensam assim, melhor nem continuarem a ler este comentário - e qualquer outro de minha autoria.

O que denominamos de "Produtividade na Prática" é implementar um Aplicativo Fiscal PED (NF's e ECF/CF's), console/texto, em um parque de equipamentos que - não raro - encontramos MMX com 32Mb RAM, e atender prontamente à Sua Excelência O CLIENTE, e evidentemente, ao Fisco. Tudo isso com honorários aceitáveis para ambas as partes.

Banda Larga, novas "janelas", Servidores Web (Apache2 - claro!), PHP, trocentos Bancos de Dados... também fazem parte de nosso atual "metiê", assim como diversas distribuições GNU/Linux fazem parte do rol de testes ... Instalar, configurar principais serviços, documentar peculiaridades, comparar desempenhos - e assim vai.

Atenciosamente,
Janis Peters Grants.

Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br

[18] Comentário enviado por alsimoes em 05/05/2005 - 20:30h

Janis,

Em uma situação de mal uso do código fonte, você teria apenas o trabalho de arrumar um advogado que demostre que nos códigos fonte disponibilizados por você não há o tal erro.

Faz parte das liçencas livres deixar claro que código pertence a quem, juntamente com as vantagens da liberdade advém também as responsabilidades, neste ponto você só fica responsável pelo código que você já havia se responsabilizado antes.

Quando alguém baixa o seu programa e pura e simplesmente o instala (compilando ou não), a responsabilidade não é toda sua, porque você não vendeu, não houve contato ou contrato, ele baixou, instalou e usou o seu software porque quis. Se esta pessoa faz alterações a responsabilidade é toda dela.

Este cenário muda quando a empresa (neste exemplo) resolve que precisa fazer alterações no sistema então precisa contratar alguém, então quem melhor que o próprio criador do projeto? Este é o novo modelo de negócios proposto pelo software livre.

Se você é do Pará e alguém resolve usar o seu software em Florianópolis é problema dele, se ele quiser lhe contratar e tiver dinheiro para pagar pelo suporte de uma empresa a esta distância, talvez seja até melhor para você porque haveria a possibiliadade desta empresa de Santa Catarina contratar uma empresa de Belém sem conhecer o software? Sendo ele livre, você pode ganhar um cliente excelente sem precisar pagar um representante comercial.

Não sou a pessoa mais indicada para falar sobre os aspectos jurídicos, mas é por esse caminho.

Dê uma pesquisada por aqui: http://creativecommons.org/worldwide/

[19] Comentário enviado por gransoft em 05/05/2005 - 22:11h

ARAGUARI-MG, 5 de maio de 2005.

Prezado André Simões,

Obrigado pela atenção.

Há um bom tempo, acompanho os trabalhos da FGV junto à CREATIVE COMMONS.

Gosto muito desta BY-SA-2.0 em pt-BR:
http://creativecommons.org/licenses/by-sa/2.0/

E também da GNU em pt-BR:
http://creativecommons.org/licenses/LGPL/2.1/legalcode.pt

Essa BY-ND-2.0 é cruel:
http://creativecommons.org/licenses/by-nd/2.0/

Na realidade, aguardo que desenvolvedores do xHarbour.org acertem em 100% a compatibilidade do TBROWSE com o Clipper 5.2e, para migrar definitivamente para Desenvolvimento OpenSource, tanto para Windows, quanto para GNU/Linux.

Desta forma, pretendo viabilizar um Projeto antigo: disponibilizar os fontes de Aplicativos Fiscais PED / Gestão Integrada Faturamento NF/CF, Caixa, Contábil, C.Receber e C.Pagar - o trivial/funcional para uma pequena empresa e/ou programadores iniciantes - que necessariamente não precisariam reinventar a roda... E afinal não era esse o objetivo desde Artigo ? Compartilho da sua filosofia.

Claro!!! Uma versão gráfica também, inicialmente com Harbour/MiniGUI, para Windows.

Atenciosamente,
Janis Peters Grants.

Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br

[20] Comentário enviado por hra em 06/05/2005 - 13:16h

O clipper está vivo e forte, talvez eu tenha me expressado mal ao dizer que estes programas são passado, mas o fato é que há muitos programas clipper em funcionamento atualmente.
Na area fiscal é quase uma unanimidade.

Aqui na empresa onde trabalho existe um ERP que está em pleno funcionamento em várias industrias e lojas, ele demanda muita manutenção e customização, existe uma equipe que só cuida disso.

É um sistema excelente, que em recursos e versatilidade supera tudo que existe atualmente em modo visual (windows) ou web. O que só demonstra que migrar pra ferramenta visual nem sempre é o ideal. Muitos usuários preferem o modo texto pela praticidade na operação.

Estou trabalhando numa idéia que permitirá o mesmo programa ter uma interface visual, uma texto, e talvez até uma web. Tudo isso transparente para o programador, ficará por conta da API.

Janis:
Quem sabe você não pode contribuir com algo menor como, por exemplo, documentação para programadores. Hoje a maior dificuldade para desenvolver algo nessas áreas é justamente o total desconhecimento das regras de negócio. Pense no assunto.
Quanto ao xHarbour, já falou pra eles dessa sua idéia ? acredito que se eles souberem que só falta o TBrowse então vão direcionar os esforços nessa direção.
Obrigado pela atenção.

Sucesso para todos nós.

[21] Comentário enviado por gransoft em 07/05/2005 - 12:48h

ARAGUARI-MG, 7 de maio de 2005.

Prezado Hamilton,

Estou disponível para qualquer contribuição relacionada a OpenSource, Desenvolvimento de Aplicativos Fiscais PED e Legislação Tributária.

Sobre TBrowse: Ou é 100% compatível CLIPPER - ou é INCOMPATÍVEL!!! Não há meio termo. É inaceitável "remendos" nos algorítmos como um "paleativo".

Este assunto já é antigo:
http://www.pctoledo.com.br/forum/viewtopic.php?p=2290#2290

Analiso friamente que, alguns Projetos OpenSource são base para versões Comerciais, cujos participantes espontaneamente colaboram para testes de identificação de Bugs ... um "Modelo de Processo Terceirizado", altamente viável, para uma linha de Desenvolvimento de Softwares.

O aborrecedor nesta situação é que na maioria das vezes - via de regra, o que era um Fórum Público de discussões acaba se transformando em "News" fechadas, e posteriormente, em Suporte Pago, inviabilizando troca de informações sobre um referido Projeto dito "Open".

Atenciosamente,
Janis Peters Grants.

Skype: gransoft
http://www.gransoft.com.br
gransoft@zipmail.com.br

[22] Comentário enviado por fdavid em 05/06/2007 - 09:51h

Cara.... quando li seu artigo, na hora dei razão!
Tinha um projeto que nem comercializava mais só prestava suporte quando necessário.

Depois de muito ensaiar e organizar (infelizmente não mechi no fonte), consegui publica-lo.

fDavid SoftControl
http://softcontrol.fdavid.com.br/

Tenho outros projetos (velhos e novos) que estou pensando em liberar como opensource e outro freeware, vamos aguardar.

[23] Comentário enviado por gilsonpaulo em 23/11/2007 - 08:48h

Existia um programinha chamdo mascara que era usado para criar telas para clipper, alguem ai tem isso. Eu tinha e perdi.

[24] Comentário enviado por Teixeira em 06/11/2008 - 22:05h

Gostei muito do artigo e da forma como foi extensamente comentado por esta comunidade.

Concordo 80% com o conteúdo mas, apesar de já ter um ano a última postagem, gostaria de adicionar o meu comentário.

Meus 20% de não-total-concordância deve-se ao fato de que tenho trabalhado com manutenção de sotware desenvolvido por terceiros e, na minha opinião, o aproveitamento do código como open source - visando apenas o simples reaproveitamento - não é assim tão importante.

A meu ver, o que realmente importa é a própria engenharia do conhecimento, ou seja, conhecer o funcionamento da atividade de cada cliente e, diante de um caso específico, desenhar o sistema gerencial SEMPRE a partir do zero.

O programador deve ter em mente que a personalidade da cada empresa deve ser respeitada.

Cada um tem maneiras diferentes de resolver o mesmo assunto.

Se existe uma forma que nos parece visivelmente melhor, deve-se apresentá-la ao cliente e ele dará a decisão.

Nesse momento, algumas rotinas já desenvolvidas por terceiros (algumas com verdadeiros toques de genialidade)
poderão ser úteis (mas existe também muito código por aí que merece ir simplesmente para o lixo).

O programador, nesse caso, não deve limitar-se a conhecer apenas os comandos de uma ou mais linguagens, mas deve ir além e conhecer o gerenciamento do negócio do cliente.

No tocante ao aproveitamento do código, se realmente for feito, devemos lembrar também que as aparências podem enganar, e que a presença de remendos - em vez de evidenciar imcompetência do desenvolvedor - pode pelo contrário apontar uma preocupação com uma manutenção ostensiva para que o sistema corra atualizado e sem falhas.

Há uns tempos atrás, era comum as softwarehouses desenvolverem software que poderia ser operado por imbecís. E realmente, só imbecís poderiam operar tais sistemas.

O programador deve ter sua atenção voltada para quem realmente vai trabalhar na preparação dos dados, e sobretudo na digitação..

As telas deverão ser claras e objetivas, e todo sistema deverá ter um manual descritivo.

Telas poluídas (com excesso de informações) são para os tais imbecís.

Pessoas inteligentes gostam mesmo é de objetividade, clareza, rapidez e confiabilidade.

Nenhum sistema de estoque ou de contas a pagar, ou de folha de pagamento, será jamais operado por um menino de 6 anos de idade.
Portanto, qualquer sistema deverá ser utilizado por adultos de posse de sua capacidade produtiva mediana (o que varia muito de pessoa para pessoa)
Mas se o empresário já selecionou o(s) funcionário(s) responsável(eis) pela operação do sistema, ele JAMAIS colocará alguém incompetente, tardigrado ou sem-noção das coisas à sua volta.

Em um sistema de gerenciamento esperam-se resultados, e não animações e efeitos gráficos ou sonoros desnecessários.

E é sempre preferível um sistema monousuário que realmente funcione, que um multiusuário que não seja confiável.

São como que "regrinhas" básicas que o bom-senso nos dita, de forma praticamente automática.

Tendo em vista as afirmações acima, chego à particular conclusão de que muito pouco código servirá para open source pelo menos no que diz respeito a uma didática.

Programas dificilmente contém documentação que não seja pertinente ao próprio código.

E o que realmente necessitamos é saber gerenciar bem a locadora, o posto de gasolina, o escritório de contabilidade, etc.

Deixo bem claro que não estou aqui para fazer uma crítica vazia ou para discordar de quem quer que seja.

A idéia é ótima, e deve ser incentivada.

Apenas dou ênfase ao fato de que muito código que ainda pode ser encontrado à solta por aí não tem a qualidade didática necessária
para seu reaproveitamento sem uma bela análise prévia.

Ele pode não coincidir com a personalidade da empresa, com o seu "modus operandi".

Pode ser que o tempo gasto nessa análise venha a ser igual ao que dispenderíamos levantando todas as informações a partir do zero.

E tudo isso significa que há um nicho no mercado que pode, sim, ser explorado por nós e por todos aqueles que apreciam e valorizam o opensource.

[25] Comentário enviado por rafaelcosta em 29/06/2009 - 08:22h

me lembro de o meu pai ter comprado uma revista que vinha com um disquete. dentro dele havia um compilador e na revista varios programas em basic! eu compilei meus primeiros jogos. coisa bonita de se ver.

[26] Comentário enviado por steang em 23/03/2022 - 20:57h


Nem sei como cheguei aqui neste texto tantos anos depois, mas que eu me lembre, a maioria absoluta dos softwares para locadoras de vídeos e farmácias eram em COBOL. #Ono #COBOL


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts