[Cascavel-pm] ERP com Catalyst

Luis Motta Campos luismottacampos em yahoo.co.uk
Sexta Abril 25 02:11:05 PDT 2008


ATENÇÃO: Se você não gosta de ser criticado, pare de ler este email
aqui. Você foi avisado.

Luciano Giordani Bassani wrote:
> Eu não sei se minha opinião vale, pois não sou um programador Perl de
>  verdade, mas mais um "colador de código".

Isso, lendo o teu email, a gente nota.

> Eu assisti a palestra de Catalyst e assisti a palestra de Ruby on
> Rails. Eu estou iniciando um projeto de conversão de ERP, também, mas
> é de MS Access para PHP5. Eu não queria produzir em PHP, eu gostaria
> de programar em bom Perl, mas infelizmente meu chefe não quer mais
> Perl em projetos deste gênero.

Eu gostaria de saber por que seu chefe não quer mais saber de Perl. E
gostaria de saber também há quanto tempo você está trabalhando com seu
chefe... talvez a opinião dele esteja muito vinculada à imagem que você
projeta do Perl.

> A sensação que eu tive é que estes frameworks são muito chatos e
> cheio de "declara aqui, declara ali". Não gostei. Eles tiram a parte
> boa que eu gosto de fazer, que é planejar bem a base de dados e a
> estrutura do sistema. Não gosto muito de ficar escrevendo e validando
> telas de cadastro, relatórios, etc. Gostaria de algo que fizesse este
> trabalho "sujo" para mim.

Você obviamente não compreendeu o motivo de se ter e usar frameworks.
Leia Edward Yourdon ("Modern Structured Analisys", Prentice Hall PTR,
ISBN-13: 978-0135986240), e Roger S Pressman ("Software Engineering: A
Practitioner's Approach", McGraw-Hill, ISBN-13: 978-0073019338). A gente
conversa sobre os motivos depois que você entender do que voce está falando.

Por agora, procure seguir os frameworks. Eles concentram e formalizam
mais conceitos sobre engenharia de software do que você.

> Por isso, para este projeto ERP que estou começando a desenvolver, 
> resolvi eu mesmo construir meu framework de uma forma que eu não
> precise ficar criando telas, pelo menos não as telas mais simples.
> Quando for uma tela mais complexa, não tem jeito. Faço manualmente
> mesmo, faz parte "sujar" um pouco as mãos.

Você pode não estar compreendendo isso, mas está escolhendo a pior
alternativa possível. Ao dividir tuas "telas" (Tela? O que é isso? Um
ateliê de artes plásticas?) em "simples" e "complicadas", você está
comentendo um erro básico: ter dois pesos e duas medidas, ter parte do
seu sistema feito à mão e outra parte gerada automaticamente (e as duas
com a mesma "funcionalidade").

> O projeto está muito no inicio ainda, mas como bom "colador" de
> código, reuni vários pacotes de desenvolvimento, para desenvolver um
> esquema tipo um "kernel" do aplicativo e estou abusando de DHTML.
> Acho que o projeto está começando a entrar nos eixos e talvez esta
> seja uma dica para vocês.

A dica é: "não faça como eu faço, ou seus chefes também vão achar que a
culpa é da linguagem Perl, que não ajuda nada".

Você está se comportando como um "colador de código", e ainda por cima
tem orgulho disso. :( Eu lamento dizer, meu caro, mas você está doente,
e precisa estudar muita engenharia de software para não perder o bonde e
terminar aposentado como "colador de código" breve. Por favor pense em
ler os livros que eu te indiquei, sim?

> Eu construi a aplicação de tal forma que na tela de grid, só preciso
>  informar o nome da tabela e o SQL que é para ser usado no banco. O
> resto o próprio código faz. Na tela de cadastro, eu só informo o nome
> da tabela (volto a ressaltar, só serve para telas simples, telas
> complexas, com muitas tabelas tem que codificar "no braço") e o meu
> código pega os dados do banco de dados e monta o formulário baseado
> na definição SQL da tabela. Assim, o código já verifica o tipo de
> campo, tamanho, se é obrigatório, etc, tudo via SQL (estou usando o
> PostgreSQL).

Bom, parece que a escolha da base de dados não foi assim tão ruim. Volto
a ressaltar: "tela" é coisa de atelier de pintura, não de engenharia de
software.

Também ressalto outra vez: seu problema é ter dois pesos e duas medidas:
você faz teu código funcionar bem em apenas uma parte dos casos, e
adiciona "cruft" ao sistema quando "resolve na mão" os problemas que não
sabe como tratar para as "telas mais complexas".

> OBS.: sobre a performance do CGI, eu uso isso em 2 projetos em Perl 
> rodando em um servidor Linux, Com vários portais rodando no Apache,
> mais PostgreSQL e MySQL juntos, com uma visitação de cerca de 10mil 
> visitantes únicos por dia, e nunca precisei usar FastCGI. A única
> coisa é que eu abuso da validação de dados com o Javascript. Em
> contra-partida, este projeto que esta em fase de teste em PHP5, no 
> mesmo servidor, tem se mostrado lento, mesmo sendo escrito com boas 
> práticas e eu estar usando PDO, que em tese deveria ser rápido. Meu 
> servidor é um DELL Xeon com 3,8GHz e 2GB de RAM (a RAM é muito 
> importante para o servidor web não ficar lento com o SGDB).

Bom, pequenas observações:

10.000 usuários únicos por dia? Isso é menos de um minuto de trabalho
dos meus sistemas. Eu tenho mais de 4 milhões de usuários únicos por
dia, e pouco menos de 900 milhões de page-hits por dia, nas minhas
páginas. Aqui, se usa ModPerl para as aplicações web, e alguma coisa já
é Catalyst. Estamos migrando os sistemas mais novos primeiro, por
questões políticas.

Sobre validar dados com JS: eu espero que isso seja apenas uma
estratégia para reduzir a quantidade de erros que você tem de tratar por
HTTP {GET,POST}, e que você tenha uma estratégia consistente e coerente
de validação implementada nos seus sistemas. De outra forma, teus
sistemas não passam de um brinquedo, e eu não dou nada pela segurança
das tuas "aplicações web".

E não me venha com aquela conversa-mole de que "os sistemas da Intranet
não precisam de segurança forte". O Gartner Group divulga faz muito
tempo que os maiores ataques contra os dados de uma organização partem,
em 75% dos casos, de dentro da própria organização: funcionários e
ex-funcionários que ainda tem acesso aos sistemas são os principais
responsáveis por fraude e tentativas de roubo ou destruição de dados.

Espero que isso ajude a mudar a tua forma de ver sistemas, meu amigo.
Cuide-se, estude, e depois conversamos mais.
Putamplexos.
-- 
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}



Mais detalhes sobre a lista de discussão Cascavel-pm