9.16.2008

De menos a más

La programación web no ha sido lo mio, aunque tengo que reconocer que cada día me atrae más, no tanto la parte front end, el interfaz de usuario, javascripts, html y tecnologías varias, si no la parte de servicio.

Para llevar un tracking de los usuarios de demos agroguía implementé un sistema de tracking muy rudimentario, la herramienta enviaba -de alguna forma, no voy a revelar el secreto, aunque si sigues el blog sabrás como- datos a un servicio web (http más bien). Cuando planeé el servicio estaba pensado para funcionar, siempre y cuando no hubiese accesos recurrentes.

Con ese requisito, hice un script cgi en dos minutos que me ha funcionado hasta hace una semana. Desde hace una semana tengo una cantidad razonable de peticiones al server, las justas para que haya posibilidad de accesos múltiples al mismo tiempo, de forma que los datos se han corrompido.

La pregunta es la siguiente: hubiera merecido la pena hacer el servicio bien desde el principio o es preferible trabajar dos veces?.

Los puristas responderían sin dudarlo: "deberías haber hecho las cosas bien y planificarlo para el futuro", los pragmáticos hubieran hecho lo que yo hice :). Si analizas bien la aplicación te das cuenta que la probabilidad de accesos recurrentes era bajísima y la probabilidad de perder los datos muy baja (teniendo en cuenta los backups del server) y el valor de los datos bajo, con lo cual no merecía la pena.

Vale, pero ahora te toca hacer lo que no hiciste hace tiempo, con lo cual si lo hubieras hecho hace un tiempo ahora no tendrías problemas. FALSO, porque con esa herramienta de dos minutos que ha funcionado a modo de test he aprendido ciertas cosas -el know how famoso- que ahora voy a tener en cuenta. Esa es la principal razón de no intentar hacer todo desde el principio, cosa que he visto repetida cientos de veces en diferentes entornos empresariales.

Moraleja: "no trates de correr antes de aprender a andar"

3 comentarios:

Blaxter dijo...

Sin duda que la mejor forma de aprender es a base de palos xD.

Aunque, sin conocer el caso, pero posiblemente el tema de la concurrencia se soluciona al instante y si no es al instante posiblemente tendrás que rehacer todo. Es decir, que es un aspecto que (para cualquier cosa, web, foo o bar) o lo tienes en cuenta desde el inicio, o luego puede llegar a ser imposible conseguirlo.

En "The pragmatic programmer" si no recuerdo mal lo mencionaban, "programa siempre desde el punto de vista concurrente" (y en el mundo web todavía más).

Javi Santana dijo...

toda la razón. Realmente el servicio no era concurrente porque el cgi abría un fichero y escribía en él, imaginate con dos peticiones la que se puede liar. Pero para hacerlo concurrente tendría que haber montado un servidor de aplicaciones, un mod_python, mod_proxy o similar.

Cyttorak dijo...

Totalmente de acuerdo. Ya sabes, "lo mejor es enemigo de lo bueno". Si una solución es "suficiente", es que es buena. Esto no es una regla de oro, pero por lo que has contado hiciste lo correcto :)