Produtos ruins, programadores amadores?
March 25th, 2005
Prefiro não pensar muito no dia-a-dia da informática mas, algumas vezes, as coisas se acumulam e é necessário aliviar a pressão. Quando acontece, sai de baixo. :-)
Quando eu desenvolvo algo, procuro pesar e criar uma boa combinação de facilidades e robustez. Não me interessa desenvolver algo em 5 minutos que eu sei que possuirá falhas. Não que meus produtos sejam perfeitos. O resultado é que em grande parte dos casos, o preço é bem superior a um produto de qualidade baixa. Atualmente, o preço geralmente é um fator mais importante que a qualidade.
Hoje estava de bom humor até acordar. Liguei o computador, li algumas coisas e parei em uma entrada do JP e vi que ele cometeu um pequeno deslize ao informar que um site estava sendo convertido de ASP para LAMP. Pensei “…cambada de amadores…”. (não o JP, o pessoal do site). Fui dar uma olhadinha e vi que estavam trocando por PostgreSQL e não o MySQL (o M do LAMP). Tudo bem, coloquei uma mensagem informando o detalhe.
Abro a Linux Magazine e, logo na contracapa, uma página com propaganda do MySQL. O banco de dados mais consumido no mundo.. Shiiiit. Milhões de moscas comem e não deixa de ser o que é. Sei que opinião se vende, mas vou deixar a minha. Sim, é possível utilizar MySQL para diversas coisinhas, mas eu não uso para alguma aplicação mais séria. Simplesmente por deixarem para eu fazer a consistência. Os diversos motivos você poderá encontrar em MySQL Gotchas. Todos esses detalhes, aliados com a minha experiência anterior junto com o Marketing utilizado pelo MySQL (veja a contracapa da revista), detalhes antigos de quando não possuia transações e diziam não ser necessário, quando colocaram saiu até em capa de revista alemã, como se fosse o único. SPs? Bem, agora estão colocando. Views? Não sei quando será implementado )ou se será). Mas para tudo isso, sempre existe um guru dizendo: “não tem problema, basta criticar os dados na sua aplicação”. Tri. Se a Mercedes não pegar, basta pegar um taxi.
Mapeamento O/R? Humm. Depende. Fiz alguns testes com o Wee + Og e até criei uma apresentação que pretendia divulgar em sites como o br-linux.org. Mas PQP. Muito legal e tal, só que a dupla transformou o meu PostgreSQL em uma verdadeira ferramenta para bando de dados. (não fiz testes apenas com o Og, portanto não posso afirmar com certeza onde o problema foi inserido). Veja o código abaixo:
class Receitas
property : titulo, String, :sql => ’NOT NULL VARCHAR(32)’
...
validate value :titulo
...
end
Primeiro, não vejo motivo de especificar uma restrição na SQL e a necessidade de explicitar que a validação seja feita. Para mim, o validade value :titulo é supérfulo. Algo como “subir para cima”. De qualquer forma, para meu desespero, tanto a restrição como o pedido de validação foram simplesmente ignorados. Portanto, enquanto os problemas não forem corrigidos, a dobradinha ainda não é usável para aplicações mais sérias. Definitivamente não! Tenho mais o que fazer para ficar corrigindo.
Não tive um maior contato com o Ruby on Rails, mas acredito que seja uma aplicação mais profissional. Parece que um validade_presences_of :titulo resolveria o meu problema (parcialmente, pois acho que se criei a minha base de dados utilizando as restrições seria supérfulo). De qualquer forma, quando a cabeça não trabalha, o sujeito fica com pernas e braços avantajados. Que problema é aquele de data invalida? Como alguém poderia aceitar 31 de fevereiro (ou mesmo 30 ou 29 para anos não bissextos)? Não posso dizer onde está o problema. Ou melhor, se o problema está no meio de persistência, foi o programador que não soube escolher um que suprisse suas necessidades. Se, mesmo escolhendo um meio robusto, o problema do 31 de fevereiro persiste, então o problema e do programador que criou a camada intermediaria. Simples.
Então é isso. Se um produto é ruim, é porque o programador também não fica muito além. Ele, em primeiro lugar, deve saber escolher as ferramentas adequadas. Depois ele deve desenvolver os programas de forma correta. Se a ferramenta é fraca, o programa deverá ser mais robusto, e é claro que com um maior trabalho como conseqüência. É muita falta de consideração, para não dizer outra coisa, jogar no esgoto todo o trabalho de anos feito por centenas de programadores em busca do desenvolvimento de uma ferramenta robusta.
Nada contra niguém, apenas um pequeno desabafo. Entre o amadorismo e o profissionalismo, existe um grande caminho a ser percorrido (YMMV). Faça seu trabalho de forma profissional. Faça o seu trabalho, aprenda sempre, questione, forme uma opinião própria.
HTH.
Entry Filed under: Geral
7 Comments
1. Rafael Rezende | March 25th, 2005 at 9:50 pm
O problema da data inválida é que é gerada uma excessão quando o usuário escolhia uma data inexistente, então tem que ser feita uma validação ainda na camada de apresentação (com javascript) ou apelar e tacar um catch na hora de salvar o objeto.
Então o Ara Howard resolveu o problema de outra maneira, adicionando normalização no Time do Ruby e colocando um flag pra dizer se houve normalização ou não.
2. JP | March 26th, 2005 at 6:33 am
Eu fico entre a cruz e a espada. Entre o produzir o melhor possível, da melhor maneira possível, e o fazer qualquer coisa a fim de agradar o freguês.
Mas o que mais me chateia é o cinismo e a hipocrisia geral. Porém tudo passa… e a gente acaba virando cínico e hipócrita também. hehehe. :-)
3. Guaracy Monteiro | March 26th, 2005 at 5:55 pm
Como não é a minha área e não testei o Rails, não posso falar muito. Só
fiquei indignado com o Wee + Og por tomarem decisões passando por cima
da minha autoridade. No computador, eu mando e ele apenas tem que
obedecer. :-)
> O problema da data inválida é que é gerada uma excessão quando o
> usuário escolhia uma data inexistente, então tem que ser feita uma
> validação ainda na camada de apresentação (com javascript) ou apelar
Javascript não é 100% garantida. Se o navegador não possui ou não está
habilitada, já era.
> e tacar um catch na hora de salvar o objeto.
Se eu posso capturar a excessão no meu programa, ótimo. Mas ele deverá ser clara o suficiente para que possa ser tratada adequadamente. Fui testar o “eXPlain Project Management Tool” http://explainpmt.com/.
Como qualquer bom usuário, a primeira coisa foi informar 31/02/2005. Recebi um simples “Application error (Rails)” na cara. Eu sei onde foi o erro, mas se não soubesse ficaria olhando o computador, chutando o cachorro, …
> Então o Ara Howard resolveu o problema de outra maneira, adicionando
> normalização no Time do Ruby e colocando um flag pra dizer se houve
> normalização ou não.
Continuo fazendo suposições. É uma solução ou um ‘workaround’? O que eu acho que deveria ocorrer seria simplesmente um retorno do tipo:
Error => Invalid date. Pronto. Sei exatamente o tipo de erro que ocorreu. Se vierem mais informações, tipo qual o objeto causou o erro, melhor.
4. Guaracy Monteiro | March 26th, 2005 at 5:56 pm
> Eu fico entre a cruz e a espada. Entre o produzir o melhor possível,
> da melhor maneira possível, e o fazer qualquer coisa a fim de agradar
> o freguês.
Vai depender do modo de trabalho que escolheres. Como o meu trabalho é específico, consigo unir os dois de forma simples. Se pretendes desenvolver um produto e colocar no mercado, a primeira parte é fácil. A segunda, “agradar o freguês” é muito complicada. Tente agradar a maioria e pronto.
> Mas o que mais me chateia é o cinismo e a hipocrisia geral. Porém
> tudo passa… e a gente acaba virando cínico e hipócrita também.
> hehehe. :-)
De médico e louco todo mundo tem um pouco. Mas hoje estou mais calminho. :-)
5. Rafael Rezende | March 26th, 2005 at 9:15 pm
O Demetrius criou umas excessões novas que melhoraram um pouco a situação e o David aceitou o patch. Agora já se pode saber em qual campo está o problema, coisa que a excessão antiga não permitia.
Eu achei que a solução do Ara Howard foi até elegante, único problema é que altera a standard library (uma rotina de verificação de data em Javascript que eu encontrei, fazia a mesma coisa, mas a normalização já era automática da classe).
Quanto ao Javascript, concordo, mas acho que poucas pessoas fariam um projeto no Rails em que precisariam se preocupar com isso, afinal, quem quer a web estática depois do gmail? :)
6. Guaracy Monteiro | March 26th, 2005 at 10:08 pm
> O Demetrius criou umas excessões novas que melhoraram um pouco a
> situação e o David aceitou o patch. Agora já se pode saber em qual
> campo está o problema, coisa que a excessão antiga não permitia.
Então tá. Parabéns para os dois. Ao Demétrio, pela contribuição )para ele e quem mais necessitar). Ao David por ter aceitado o ‘patch’ de algo que, certamente, será importante para muitos e para o próprio projeto.
> Eu achei que a solução do Ara Howard foi até elegante, único problema
> é que altera a standard library (uma rotina de verificação de data em
> Javascript que eu encontrei, fazia a mesma coisa, mas a normalização
> já era automática da classe).
Alterar o funcionamento de uma classe tem seus prós e contras, como qualquer coisa. Mas é um recurso importante da liguagem.
> Quanto ao Javascript, concordo, mas acho que poucas pessoas fariam um
> projeto no Rails em que precisariam se preocupar com isso, afinal,
> quem quer a web estática depois do gmail? :)
Um usuário de Windows pirata? (que não poderá mais ser atualizado :-)
7. Rafael Rezende | March 27th, 2005 at 3:19 am
Coloca o Firefox no Windows pirata :)