Barrapunto

Que lista más divertida, vayamos a comentarla por partes (se nota que últimamente tengo poco trabajo ;)


Problema N1: Programación colaborativa distribuida.
El nóbel de la informática práctica se lo llevará quien invente una metodología sólida para desarrollar código igual que funcionan las redes P2P, dividiendo el trabajo en tareas de no más de 1 hora que puedan ser ejecutadas redundantemente por varios programadores geográficamente dispersos. Por ahora disponemos de herramienta de recogida de requisitos, diseño UML, control de versiones, testeo, bug trackers, etc. Pero los mejores programas (y casi los únicos que funcionan bien) siguen siendo desarrollados por un grupo muy reducido y cohesionado de programadores. No existe un genuino "divide y vencerás" aplicado a la producción de código. A más programadores implicados, menor productividad por programador y menor predictibilidad del resultado final del proyecto.


Esto se podría crear si la especificación fuese totalmente cerrada y no cambiante como son ahora los desarrollos creo yo.


Problema N2: Productividad en el desarrollo de interfaces web.
El uso de HTML y JavaScript supuso un retroceso de 10 años en el estado del arte de las herramientas de desarrollo. Cuando ya teníamos VisualBASIC 4.0 con el cual te picabas una aplicación operativa en 3 días, volvimos a usar diseño con lenguaje marcas que sólo funcionaba bien si lo editabas a pelo con UltraEdit, por no hablar de que el JavaScript ni siquiera tiene un debugger decente. Ahora los frameworks AJAX prometen el oro y el moro. O tienes la opción de casarte con Microsoft .NET. Mi amigo Javier Gallardo incluso dice que a ellos les va bien con Adobe Flex pero con cualquiera de estas cosas te la juegas a quedarte pillado a medio plazo.


Por fin alguien que me entiende¡¡¡, sigo pensando que usar la interface web para hacer programas es una aberración, aunque este de moda, algún día esto cambiara, y espero que pronto.


Problema N3: La temporalidad en el modelo relacional.
¿Porque nadie ha implementado aún un modelo relacional extendido que incluya manejo de la temporalidad? Para poder expresar con naturalidad cosas como que un empleado perteneció a un departamento dado entre tal y cual fecha, por ejemplo. Los históricos y los solapamientos de fechas hay que manejarlos a mano en la base de datos. Lo cual resulta muy engorroso.


Ahora los campos Memo del nuevo SqlServer 2008 ya traen historico de cambios (se puede desactivar), quizá dentro de poco veamos extender eso y llevar un control de cambios de todas las celdas, quien sabe.


Problema N4: La multimoneda.
¿Porqué no existe un tipo moneda que funcione bien en las bases de datos? Me refiero a uno que te permita sumar 3 con 5$ y te dé el resultado correcto en función de un tipo de cambio dado externamente.


Eso si que no, realizar la conversión de las monedas no es tan trivial como aplicar un tipo de cambio. Existen incluso brokers on-line que permiten jugar con la cotización diaria de las mismas y especular con ello. Sumar euros con dolares es como sumar peras con manzanas. La solución pasa por usar una moneda única en la aplicación y convertirlo todo a la moneda final, pero claro, las cotizaciónes cambian y nos encontramos con el problema anterior.


Problema N5: Integridad referencial en los borrados.
¿Cómo borrar algo de una base de datos si infringir las reglas de integridad referencial? En realidad, la solución es simple ¡nunca borrar nada! sino en cambio dar bajas lógicas. Pero entonces ¿porqué no tenemos un procedimiento predefinido para las bajas lógicas?


quizá pase por la solución anterior, guarda