Los ordenadores son, esencialmente, deterministas

Los ordenadores, fallos hardware aparte, son autómatas deterministas: dado un estado inicial, una serie de operaciones llevan siempre al mismo resultado.
Una conclusión de esto es que no hacen "cosas raras". Puede haber cosas mal hechas, claro está, pero sus efectos son predecibles.
Un caso paradigmático de esto son las librerías. En todas hay bugs, claro, pero pocos. Si algo "no funciona" revisa antes tu código. Las librerías de código abierto son usadas por millones de desarrolladores, y revisadas por gran parte de ellos (¿aún no has asociado las fuentes a los binarios en Eclipse? ¿A qué esperas?). Sin embargo, tu código es nuevo y sólo tuyo, probablemente el problema esté ahí.
Cuando llamamos a un SAT lo primero que nos preguntan es ¿está enchufado? Sí, es irritante, pero, ¿compruebas que tu código lo está? El determinismo hace que para solucionar la mayor parte de los errores en el código no sea necesario ni pensar. Símplemente un análisis metódico desde el error nos conduce al error: vete a la línea que falla y vete "tirando del hilo". El problema aparecerá solo.

PS: ¿Ah, que estás utilizando librerías propietarias, sin el código? Mmm... ¡Buena suerte!

Posted by Juan Ignacio Sánchez Lara 14:40 Enlaces a esta entrada  



IPhone 3.0 y ubiquidad

No es mi costumbre usar este blog para hacer reseñas de productos, pero sí me gustaría hablar un poco del IPhone, a cuento del reciente anuncio de la versión 3.0 de su sistema operativo.
Se habla mucho de cloud computing, Web 3.0 y demás milongas últimamente, que, en mi opinión, sólo sirven para alimentar los blogs, las columnas en las revistas, y con ello, las nóminas, de supuestos visionarios. Nuevas etiquetas para productos que ya existen.
Sin embargo, la auténtica evolución (no creo que haya revoluciones a la vista) de Internet es la presencia ubíqua de la misma. Hace aproximadamente cinco años trabajé en proyectos de I+D sobre este tema, y se veía claro que el futuro pasaba por ahí. Sin embargo, el precio de los dispositivos y la cara y escasa cobertura de Internet de calidad lo hacían imposible.
A día de hoy los dispositivos están al alcance de cualquiera, y la conexión es más que aceptable, así que esto está a punto de estallar. Google lo sabe y se ha posicionado con Android. Apple, con su iPhone, ya lo está experimentando.
La versión 3.0 contiene dos bombas potenciales en este aspecto: las compras in-app y la conexión de dispositivos.
Sí, todos gritábamos por tener, por favor, cortapega ("ortodoxo", ya que con jailbreaking ya se podía), tethering y A2DP (Bluetooth Estéreo). Pero lo que puede ser una revolución ubíqua es lo otro.
Las compras in-app permiten un modelo de negocio basado en micropagos, para ofrecer contenido de calidad (de pago). Off-topic: ¿tendrá el siguiente iPhone una pantalla de lector de ebooks a color y reventará el mercado?
La conexión a dispositivos permitirá conectar cualquier aparato a Internet, sin requerir una dedicada. Ya estoy empezando a pensar aplicaciones online a aparatos que ahora son offline...

Quien quiera innovar y forrarse, que piense en ubiquidad y se deje de modas pasajeras.

Posted by Juan Ignacio Sánchez Lara 18:53 Enlaces a esta entrada  



Artesanía

El desarrollo de software tiene más de artesanía que de ingeniería. Sí, hay métricas, calidad, automatizaciones... Pero lo que requiere de la persona que lo realiza es que sea un buen artesano, que haga las cosas con esmero, meticulosidad...

Posted by Juan Ignacio Sánchez Lara 9:56 Enlaces a esta entrada  



Cuándo hacer el modelo de datos

Si me preguntasen por el mínimo común denominador de la aplicación de las metodologías tradicionales que he visto en los últimos años, respondería sin dudar el modelo de datos. La gestión de los requisitos es muy variable, el diseño y la construcción varían enormemente... Sin embargo, el momento y la forma en que se hace el modelo de datos siempre era la misma. Una vez recogidos los requisitos, durante el análisis, el paso clave que marcaba, en cierto modo, el fin del trabajo del analista y el comienzo del resto, era la validación del modelo de datos.

En las metodologías tradicionales se hace en dos partes: en la fase de análisis se hace el modelo lógico, y en diseño se hace el físico. En la práctica siempre he visto que esto se fusionaba. Quizá por las herramientas, quizá por lo innecesario de la división, siempre se hace directamente el segundo.

Desde que uso Hibernate había querido aprovechar al máximo la potencia de su mapeo relacional, relegando el modelo de datos a un segundo plano en favor del modelo de clases. Esto, que parece un detalle menor, en mi opinión tiene una gran importancia práctica. Hacerlo implicaría que el analista/diseñador haría, en vez del modelo, directamente las clases, las cuales generarían el primero automáticamente. Expuse esta idea esgrimiendo una serie de ventajas:

  • El trabajo de modelado aportaría más información, ya que los modelos Java más las anotaciones de persistencia aportan más información y valor que las tablas (se introducen validaciones de datos, propiedades calculadas, documentación...).
  • Eliminaríamos el problemático trabajo de mapear tablas existentes.
  • Adelantaríamos el trabajo de la programación de las entidades.
  • Podríamos anticipar cosas como pruebas automáticas para verificar la corrección del modelo.
  • Personalmente trabajo mejor con una herramienta de desarrollo que con una de modelado. Andar con el ratón, dobles clicks y diálogos me parece engorroso y lento, aunque esto ya son preferencias de cada uno.
  • No renunciamos a la información gráfica, ya que podemos generar diagramas tanto de clases como de objetos mediante ingeniería inversa (NetBeans es realmente útil para esto).
La idea no prosperó, y los siguientes proyectos se hicieron como anteriormente.

Al pasar a metodologías ágiles, al desaparecer estas fases, toca decidir cuándo realizar este trabajo. Scrum obviamente no entra en esta decisión, así que, ya con la capacidad de decisión, me adherí al principio de diseño contínuo y además adopté las ideas anteriores. De esta forma, no se haría el trabajo explícito de modelado de los datos, sino que, a medida que se avanzase en la aplicación, se iría mejorando a través del propio diseño de las clases.

Ya con el proyecto en desarrollo, saco las siguientes conclusiones:
  • No realizar análisis del modelo de datos, sino trabajar directamente en el diseño de las clases, es muy práctico: es mucho más tolerante a los cambios (hemos pasado de claves deferred a compuestas de forma trivial, por ejemplo), facilita el trabajo en equipo (no más "lanza de nuevo el script de base de datos, que he cambiado el esquema")... Me reafirmo, por tanto, en los puntos expuestos antes.
  • Desaparece la mentalidad de "tenemos que ceñirnos al modelo de datos a cualquier coste". He visto auténticos malabarismos por parte de desarrolladores por querer respetar el modelo del analista por todos los medios. El hecho de no tenerlo tira esa barrera.
  • Pese a esto, sigue siendo necesario hacer un trabajo previo de análisis. Comprender las clases y las relaciones entre ellas es fundamental para el desarrollo del proyecto. No es necesario especificar desde un principio cada propiedad de cada clase, sus longitudes máximas y sus validaciones, pero sí es importante tener claro lo antes posible el esquema general. Los desarrolladores tendemos a centrarnos en "pantallas", y en una no está la auténtica lógica de las relaciones entre los datos.
Para el siguiente proyecto estoy pensando incluso en hacer una primera versión del modelo de clases en el primer Sprint Meeting. En este creamos una tarea específica para ello, pero esto hace que el conocimiento quede en una sola persona. Creo que el trabajo de hacer una primera aproximación, incluso antes de la estimación de las tareas, ayudaría a todo el equipo a comprender el problema a resolver y la complejidad del desarrollo.

Posted by Juan Ignacio Sánchez Lara 15:15 Enlaces a esta entrada