<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Vamos algumas repostas...<br>
<br>
Meu chefe não quer mais saber de Perl, pq ele não consegue profissional
"barato". Aliás, ele não consegue profissional nenhum, hehehe<br>
Ele já botou várias vezes anúncio em jornal pedindo programador Perl,
mas nunca recebeu curriculum. Tenho pena dele se algum dia eu sair da
empresa. <span class="moz-smiley-s3"><span> ;-) </span></span><br>
Ele sabe da qualidade do Perl, mas encontrar programadores de outras
linguagens, como PHP é bem mais fácil e menos caro. Eu tenho um projeto
de ensinar um programador PHP a programar em Perl, até pq tem muita
coisa rodando que não vai ser migrada, mas infelizmente a rotatividade
entre programadores é muito grande. Tinha um programador, muito bom,
que eu já estava começando a dar umas dicas de Perl, mas ele largou
tudo e foi morar na Inglaterra.<br>
<br>
Contando a época que fui estagiário, estou nesta empresa a quase 12
anos.<br>
<br>
Acho que vou seguir o teu conselho e vou ler algum livro sobre isso,
mas em português. Algum dia, pq arrumar tempo é algo complicado. Mas a
verdade é que eu não gosto mais de desenvolver sistemas. Futuramente
pretendo ficar apenas com administração de servidores e desenvolver
softwares que ajudem nisso, mas por enquanto não dá para escolher o que
eu quero fazer.<br>
<br>
Eu divido as telas (que na empresa onde a gente trabalha são
formulários que devem ser preenchidos, validados e enviados ao banco de
dados) em simples e complicadas, pq neste novo projeto as telas simples
(que em geral são a maioria) são geradas automaticamente. Assim, eu só
passo para o script qual é o nome da tabela e mais algum ou outro
parâmetro. Através de consultas SQL, o script monta o formulário, vê o
tipo de campo e se é obrigatório ou não e monta toda a regra de
validação, isso tudo automático. Em tese, toda a regra de negócio eu
estou tentando deixar no PostgreSQL e o script apenas lê isso.<br>
<br>
Os formulários complicados (que na gíria da empresa chamamos de tela),
não podem ser automáticos pq existem outras regras e sub-formulários.
Por exemplo, telas que tem que calcular questões financeiras, etc. A
vantagem disso é que eu posso concentrar meu tempo no que realmente
importa e deixar estas questões de design praticamente automáticas.<br>
<br>
Eu penso que não é ruim ser "colador de código". Tem muita coisa pronta
na Internet é só procurar um pouco. O que eu faço é juntar estas coisas
prontas e gerar algo novo. Isso é o que eu posso fazer com os recursos
que eu tenho disponível, pois na empresa onde eu trabalho, eu faço
praticamente tudo sozinho, desde instalar, configurar e dar manutenção
no sistema operacional do servidor, analisar e gerar a base de dados
(de acordo com a analise de processos que meu chefe faz), desenvolver o
software, etc. Para a produção, em geral, tem apenas eu e mais um
designer (agora estamos sem novamente). Neste projeto novo que eu estou
trabalhado tinha aquele programador ajudando, mas ele saiu e por
enquanto não entrou ninguém novo. Resumindo: eu trabalho em uma pequena
empresa.<br>
<br>
Eu creio que não é educado da tua parte criticar os sistemas que eu
mantenho apenas pela quantidade de visitas que eles recebem. Meus
clientes merecem menos atenção apenas pq eles não tem tantos
visitantes? Creio que não. A tua experiência é válida para empresas que
precisam trabalhar com este volume de dados, assim como minha
experiência vale para quem tem um volume "menor". Este cliente que eu
citei, que tem 10mil visitantes únicos por dia é a uma das maiores
empresas de feiras e eventos do Brasil (talvez até seja a maior), ou
seja, não é uma empresa pequena e eles tem esta visitação nos sites
deles. Eu creio que a realidade deles é mais compatível com a realidade
da maioria das empresas brasileiras (excluindo empresas de
telecomunicações, de grandes empresas de vajero, etc).<br>
<br>
Sobre a validação eu já respondi para outra pessoa em outro e-mail e
sobre segurança eu posso afirmar, com 100% de certeza absoluta, que os
sistemas que eu mantenho são mais seguros do que os das Lojas
Americanas, Submarino, Saraíva, entre outros. Eu me preocupo com isso e
sempre que encontro uma falha nova eu procuro solucionar. Você está me
pré-julgado apenas pq eu falei em Javascript. Isso é um erro recorrente
dos "bons programadores". Relegam Javascript, acham que elas não servem
para nada. Javascript para mim é algo que uso direto, mesmo antes de
falarem em AJAX eu sempre usava Javascript para validação de dados e
jogar parte do processamento para o cliente. Com isso eu reduzo a
comunicação com o servidor e o sistema fica mais "rápido" para o
usuário. Nos projetos antigos, a validação no lado do servidor era
feito em Perl, mas neste projeto novo, minha intenção é que a validação
do lado do servidor passe a ser feita pela base de dados.<br>
<br>
Creio que era isso.<br>
<br>
<br>
SDS,<br>
<br>
Luciano<br>
<br>
<br>
<br>
<br>
<br>
Luis Motta Campos escreveu:
<blockquote cite="mid:4811A029.9070907@yahoo.co.uk" type="cite">
<pre wrap="">ATENÇÃO: Se você não gosta de ser criticado, pare de ler este email
aqui. Você foi avisado.
Luciano Giordani Bassani wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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".
</pre>
</blockquote>
<pre wrap=""><!---->
Isso, lendo o teu email, a gente nota.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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ê.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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").
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
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".
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
</body>
</html>