Archivo de Febrero, 2008

… incluya no sólo las acertadas decisiones e importantes acciones que va a llevar a cabo cada partido político si es elegido para gobernar, sino también todo lo que NO van a hacer.

Porque gobernar implica elegir, dedicando recursos limitados (dinero, tiempo, …) para conseguir unos objetivos a cambio de renunciar a otros. ¿Se atrevería algún líder a decirnos cuáles serán esas renuncias?

Y es que uno escucha declaraciones, lee programas, y ve entrevistas a líderes políticos, y se siente como un niño pequeño al que prometen que mañana conseguirá cualquier cosa que desee si se porta bien. No nos deberíamos dejar engañar; al menos, no los que no aceptamos dogmas en otros ámbitos.

Igual que una teoría científica sólo se puede considerar como tal si es falsable (es decir, que pueden aparecer casos que nos muestren que no es válida), sólo deberíamos tomarnos en serio una promesa electoral si va acompañada de lo que no se hará a cambio.

La teoría gravitacional de Newton es una teoría científica porque cualquier observación que no se ajuste a sus predicciones demuestra que no es válida. Que, de hecho, es lo que ocurre cuando se hacen mediciones con la suficiente precisión, que sí son explicadas por la teoría relativista de Einstein (que, a su vez, también son falsables por observaciones que no fueran explicadas por ella).

Exijamos a los políticos que nos expliquen de dónde va a salir el presupuesto si se bajan los impuestos, o en qué partidas se van a invertir menos recursos. Que nos digan a quién no van a subir las penas cuando quieren endurecer las de determinados delitos. Que nos aclaren con qué países nos vamos a llevar peor como consecuencia de llevarnos mejor con otros.

Entonces los partidos políticos dejarán de parecerse más a una religión, imposible de falsear, siempre con una explicación a cualquier realidad que pueda aparecer.

Y que no necesitan razonamiento, sino… fe.

PD: lástima que no podamos votarlos a ellos:

Después de desarrollar varias aplicaciones utilizando Microsoft Access, uno descubre que existen algunas prácticas y formas de trabajo que simplifican su desarrollo y el mantenimiento, sobre todo cuando la aplicación empieza a crecer más de lo que tenías previsto (cosa que suele pasar casi siempre).

Seguramente Access no es una base de datos que pueda soportar una gran aplicación con multitud de usuarios accediendo al mismo tiempo, que maneje una gran cantidad de datos, o con requisitos complejos de rendimiento o seguridad. Pero como herramienta que permite implementar una aplicación completa (desde las tablas de datos hasta interfaces de pantalla o informes impresos) para unos pocos usuarios de manera rápida, hay que reconocer que tiene pocos rivales. Los desarrollos con Access son tan rápidos que puede utilizarse como una herramienta de prototipado que ayude a definir claramente los requisitos de usuario antes de pasar a un sistema más potente.

1. Define bien las tablas y sus relaciones

Los desarrolladores conocen lo importante que es tener un buen modelo de datos en su aplicación. Y en Access, eso se convierte en la pantalla de Relaciones (dentro del menú Herramientas):

Es decir, define globalmente los campos de cada tabla y las relaciones entre tablas, para toda la aplicación, tal como son en la realidad (no como deberían ser). No definas tablas, campos y relaciones para necesidades puntuales que puedas tener en un formulario o informe concreto.

En concreto, evita las listas de valores y conviértelas en tablas. Si vas a guardar todos tus CD y libros en la base de datos, no introduzcas el "tipo de objeto" como una lista de valores en un campo de la tabla "Objetos" o de un formulario; mejor crea una tabla "Tipos de objeto" y guarda los valores "libro" y "CD" como registros. Si más adelante quieres añadir un nuevo tipo de objeto (como "DVD"), bastará añadirlo a la tabla y te evitarás tener que buscar todos los puntos donde está especificada la lista de valores.

[Actualización 03-mar-2008]

Tal como indica javieran en un comentario, es conveniente crear las relaciones desde el diseño de tablas. Para eso, basta con seleccionar la pestaña "Búsqueda" y la opción "Mostrar control" > "Cuadro combinado", seleccionando una tabla como "Origen de la fila"; todo esto cuando se defina un campo que obtiene los valores de otra tabla previamente creada (lo que se conoce como "clave externa").

Siguiendo con el ejemplo anterior, se trataría de utilizar esa opción cuando se defina, dentro de la tabla "Objetos", el campo "Tipo de objeto" para que indique si cada registro es un libro, un CD o un DVD.

Esta acción tiene dos efectos:

• En vez de un cuadro de texto, la interfaz de Access mostrará automáticamente un cuadro combinado para seleccionar uno de los valores existentes.
• Se crea una relación entre ambas tablas (por defecto, sin integridad referencial)

(sigue …)

(visto en un tablón de anuncios del Ágora de la Universidad Politécnica de Valencia)

Paradojas del Access

Os presento aquí uno de los dos proyectos que envié a la beca Alzado y que, obviamente, no fueron premiados. Como ya expresé en un comentario en Alzado (comentario núm. 4), creo que los criterios de la beca podrían haber estado mejor definidos, pero el motivo de escribir este artículo es otro.

Las ideas están sólo esbozadas y (todavía) no tienen "cuerpo", aunque me gustaría poder desarrollarlas en algún momento. Sería muy optimista pensar que voy a hacerlo yo sólo, así que antes de que se pierda en el olvido, prefiero dejarlo aquí explicado de modo que, si alguien quiere colaborar en ponerlo en marcha o tiene alguna aportación que hacer, pueda contactar conmigo.

TALAIOT

El objetivo de este proyecto sería proporcionar a los usuarios alguna herramienta que les permita seguir las modificaciones en páginas que les interesen, incluso para aquellas que no las publiquen de modo explícito con sistemas como RSS o similares.

Esto permitiría, por ejemplo, enterarnos de nuevos comentarios en artículos de blogs, conocer cambios en nuestras páginas de del.icio.us, o saber cuándo se modifican las páginas de la competencia.

Este proyecto constaría de dos partes:

1. Crear un sistema que permita valorar (numéricamente y automáticamente) las modificaciones que se producen en cualquier página HTML, a partir del análisis de su código y a partir de determinados algoritmos.
2. Ofrecer un sistema que permita a los usuarios utilizar ese sistema para recibir notificaciones cuando se produzcan cambios en las páginas en las que estén interesados.

Aunque no hay nada inamovible, mi intención inicial era utilizar Ruby on Rails (y aprender de paso) para el desarrollo, dedicándole especial atención a dos elementos clave (a mi entender) en cualquier aplicación: el esquema de base de datos por un lado y a la usabilidad de las interfaces por el otro.

Propuesta TALAIOT (PDF, 334KB)

Os invito a que leáis la presentación de la propuesta (se hace en un par de minutos), a que hagáis vuestras aportaciones mediante los comentarios de esta entrada, y a que os pongáis en contacto conmigo si queréis colaborar de algún modo en ella. Gracias.