Opinion

Juan Mellado, 13 Noviembre, 2006 - 17:29

Actualmente trabajo en una empresa multinacional cuya actividad principal es el desarrollo de software y que me ofrece la posibilidad de realizar distintos cursos de formación a lo largo del año. La mayoría de los cursos están encaminados, o bien a reforzar mis conocimientos en las áreas en las que normalmente trabajo, o bien a conocer el detalle de las nuevas herramientas y arquitecturas que se desarrollan dentro de la propia empresa.

Uno de los objetivos principales de estos cursos es el de consolidar y unificar todos los procesos de desarrollo en torno a un único estándar que sirva de referencia a los distintos equipos, que en cierta forma trabajan aislados los unos de los otros en el día a día de cada proyecto en particular. Lo que se hace es tomar las fases características por las que se pasa durante el proceso de desarrollo: toma de requerimientos, análisis, diseño, codificación, prueba, documentación, etc. y se estudia cuales son los métodos y las herramientas más adecuadas a aplicar en cada fase en concreto.

En estos momentos estoy estudiando el método de "Puntos Función" que sirve para obtener métricas del software, o dicho de otra forma, para calcular (medir) distintos indicadores de un proyecto de software, sobre todo estimaciones de tamaño, tiempo y esfuerzo. Conocer con la máxima precisión posible el tiempo y las personas que se van a dedicar a realizar una tarea concreta es un factor clave para triunfar en el competitivo mundo en el que vivimos hoy en día.

El método está orientado a ser utilizado para proyectos de desarrollo de aplicaciones de gestión, y a grandes rasgos consiste en separar los procesos de los datos y asignar a cada una de ellos un peso. Los procesos se dividen en entradas, salidas y consultas. Los datos se dividen en internos y externos. Las entradas son cada uno de los procesos únicos y distinguibles a través de los que los datos se introducirán en el sistema, las salidas los procesos que retornarán al menos un dato calculado, y las consultas los que implicarán una interacción con el propósito de obtener un determinado dato. Los datos internos son los que se mantendrán dentro de los límites del sistema, y los externos los que no. El método consiste en delimitar el sistema, identificar cada uno de sus elementos y asignarles una medida adimensional que es el punto función. En una versión simplificada del método los puntos función se toman de una tabla de medidas medias en la que se indica que para una entrada se necesitan 4 puntos función, 5 para una consulta, y así sucesivamente. Multiplicando cada elemento por su número de puntos función se obtiene el número de puntos función brutos del sistema. Finalmente el tiempo y el esfuerzo se determinan considerando la historia de la empresa, es decir, si un programador medio de la empresa suele desarrollar 2 puntos función al día entonces se podrán desarrollar 10 puntos función en una semana (2 pf x 5 días = 10 pf/semana)

Una de las cosas que primero me llamaron la atención es que el método aborda el problema desde el punto funcional y no técnico. Es decir, estudia la complejidad de los sistemas que se quieren construir o modificar desde el punto del vista de los usuarios que los utilizarán, y no desde el punto de vista de los equipos que los desarrollarán. Lo paradójico de este planteamiento es que quien realizará la medición es un equipo normalmente técnico con el objetivo de determinar cuanto tiempo va a tardar en ejecutar el proyecto, o mejor dicho, en entregar el producto.

¿Se lo imaginan? Un método que promete obtener una estimación fiable del tiempo y esfuerzo que se necesitará para desarrollar un programa que cubra todas las necesidades solicitadas por los usuarios examinando sólo los requerimientos de los mismos. Naturalmente mi escepticismo inicial se está convirtiendo en desilusión a medida que avanzo en el aprendizaje del método.

Si sólo se miran los requerimientos, ¿qué ocurre entonces con la complejidad técnica? ¿Es lo mismo implementar un sistema de gestión que un sistema de control en tiempo real? ¿Podemos llegar a un nivel de abstracción tal que no sea necesario conocer detalles de implementación ni la tecnología que se utilizará? La respuesta por supuesto es que no. Así que, ¿cómo resuelve todos estos problemas el método para dar una medida final? Pues de la única forma posible, sacándose de la manga una decena de factores de ajustes de carácter técnico. Y es que no hay otra, al final alguien tiene que mojarse y dar una estimación subjetiva del tiempo que se va a tardar en desarrollar el sistema. Esos factores de ajuste ponderan los puntos función obtenidos anteriormente para tener en cuenta aspectos tales como la concurrencia o la disponibilidad, es decir, lo difícil que será implementar finalmente el sistema.

Pero en cualquier caso la conclusión final tiene que ser positiva. Lo importante es tener un método y aplicarlo, es hacer examen de conciencia y reconocer la necesidad de cuantificar lo que se está haciendo. Medir, medir y medir. Puede que el sistema no sea óptimo, pero es lo mejor que tenemos por ahora. Y no es una excusa. El hecho de que una empresa reconozca la necesidad de disponer de un método para medir de la mejor forma posible algo tan etéreo, complejo y difícil, como es el proceso de desarrollo de software es un paso muy importante.

Juan Mellado, 7 Noviembre, 2006 - 11:50

Una de las cosas más importantes que tiene que hacerse para garantizar que los programas resulten fáciles de desarrollar y posteriormente darles mantenimiento es utilizar estándares de nomenclatura. El problema es que esta práctica sólo se suele asociar al nombre de los ficheros y al estilo del código fuente, pero hay otras áreas en las que también resultan de crucial importancia. Hoy me estaba fijando en los nombres de los objetos en Base de Datos, como las tablas por ejemplo.

Es bastante frecuente, sobre todo en aplicaciones web sencillas, tener tablas con nombres comunes como CLIENTES o FACTURAS. Esto resulta claro y conciso durante el diseño y desarrollo, pero a la larga puede traer problemas. Por ejemplo, no se pueden instalar dos aplicaciones distintas en una misma instancia de Base de Datos para un mismo usuario si los nombres de las tablas que utilizan son iguales, y usando nombres tan comunes es bastante normal que antes o después se den conflictos. Pero sobre todo resulta problemático cuando se tiene que dar mantenimiento a la aplicación y se tiene que medir de forma rápida el impacto de una modificación importante sobre una tabla bastante utilizada como puede ser CLIENTES. En la mayoría de los casos lo que se hace es buscar la palabra "CLIENTES" en todos los fuentes, y ocurre que aparece en comentarios, nombres de variables, nombres de funciones, cadenas de texto, sentencias SQL, etc. siendo difícil discriminar de forma rápida las modificaciones concretas que habrá que realizar.

Una mejor estrategia de nomenclatura es prefijar los nombres de los objetos con unas siglas identificativas del proyecto. Por ejemplo, si se está elaborando el sistema SuperGes 1.0, basta con anteponer al nombre de las tablas un prefijo tal como "SGE_", pasando entonces las tablas a llamarse "SGE_CLIENTES" o "SGE_FACTURAS".

Este simple método anula completamente la probabilidad de conflicto de nombres con los distintos proyectos que desarrollemos dentro de nuestra empresa, pero no anula la probabilidad de conflicto con aplicaciones de otras empresas que pueden estar siguiendo nuestro mismo método de nomenclatura. Una solución más completa, utilizada en algunos paquetes de software libre, es decidir el prefijo de las tablas en el momento que se realiza la instalación de la aplicación.

Drupal por ejemplo permite que los nombres de las tablas se prefijen como se quiera al crear la Base de Datos durante el proceso de instalación, y que se ponga en un fichero de configuración el prefijo escogido. Esto resulta especialmente útil cuando se tienen varias versiones instaladas a un mismo tiempo, ya que nos permite tener varios conjuntos de unas mismas tablas pero prefijadas de forma distinta para evitar conflictos, como "drp468_" y "drp472_" por ejemplo.

La magia del asunto consiste en que dentro del código fuente de Drupal los nombres de las tablas en las sentencias SQL se escriben encerradas por llaves, como en "SELECT nid FROM {node}". De esta forma la capa de acceso a Base de Datos puede detectar la referencia a cada tabla y anteponerle el prefijo escogido. Si el sobrecoste que implica sustituir en tiempo de ejecución una cadena de texto por otra resulta prohibitiva, cosa que dudo ya que en comparación el tiempo de acceso a Base de Datos será siempre de varios órdenes de magnitud mayor, se puede optar por sustituir los nombres de las tablas dentro de los propios ficheros fuentes durante el proceso de instalación del software, algo plausible si se utiliza algún lenguaje como PHP por ejemplo, que normalmente es interpretado.

Hablando de Base de datos, otra práctica bastante común en algunos desarrollos web sencillos es el obviar el uso de foreign keys. A veces simplemente porque no hay más remedio, por ejemplo porque el gestor de Base de Datos que se está utilizando no lo permite, pero la mayoría de las veces es por pura dejadez y una cierta aversión al uso de las mismas. No sé, es como si tuvieran mala fama o se pensase que resultan totalmente inútiles. Las excusas hablan de que ralentizan el funcionamiento, que dificultan los imports parciales, y que en general no sirven para nada cuando las relaciones son evidentes. Todas excusas vanas. Lo único cierto y verdad es que sólo implican una carga extra para el servidor cuando se insertan o borran registros, no cuando se hacen consultas, que es lo que hace el 99% del tiempo una aplicación web típica. Tampoco dificultan los imports, todo lo contrario, ayudan a que no quede información incoherente en Base de Datos que de otra forma podría ser difícil de depurar. Y por supuesto sí sirven para algo, sobre todo cuando tenemos que enfrentarnos a modelos que constan de 300 o 400 tablas, y no las 6 ó 7 de una aplicación pequeña y que hemos desarrollado completamente nosotros. Obtener la estructura puede ser sencillo, pero averiguar el uso y la intención es normalmente una labor más compleja, por lo que toda ayuda resulta poca.

Juan Mellado, 6 Noviembre, 2006 - 11:09

Recientemente hemos tenido que acometer un encargo dentro del proyecto en el que trabajo consistente en automatizar un proceso de descarga de ficheros desde unas páginas web. La situación era que una serie de personas debían conectarse diariamente con un navegador a unas páginas web determinadas para descargarse de ellas unos ficheros con una información que le es necesaria para la normal realización de su trabajo. Lo que se quería era evitar el tiempo que se perdía en la descarga manual y que fuera en cambio un proceso automático el que descargarse los ficheros y los dejara en un servidor de red.

Nuestra primera opción fue utilizar wget, una aplicación multiplataforma, de uso gratuito y código abierto, que sirve precisamente para descargar archivos de webs. Es frecuente encontrarla instalada en máquinas UNIX, y quizás uno de sus usos más conocidos es el de descargar webs enteras, ya que es capaz de seguir todos los links que se le indiquen de forma recursiva.

Comprobamos que wget se encontraba instalado en el servidor que íbamos a utilizar, pero desgraciadamente resultó que era una versión antigua y no soportaba HTTPS, algo que necesitábamos utilizar porque algunas de las webs a las que teníamos que acceder utilizaban este protocolo. Mientras gestionábamos el upgrade de versión, algo complicado de conseguir ya que la máquina que teníamos que utilizar era un servidor de producción con un riguroso protocolo de certificación del software instalado, encontramos una alternativa en cURL, otra aplicación multiplataforma, de software libre y código abierto.

La funcionalidad que ofrece cURL es básicamente igual a la de wget, así que nos decidimos a probarla. Con un poco de recelo, y en vez de bajar un paquete de instalación ya preparado, nos decidimos por descargar los fuentes y compilarlos para la máquina destino. Increíblemente todo funcionó bien a la primera, y es que en estos casos nunca sabes lo que te puedes encontrar. Bastó con ejecutar un script con los parámetros adecuados para obtener el software listo para funcionar. El script tardó varios minutos en ejecutarse durante los cuales realizó una enorme lista de comprobaciones acerca de la máquina y el software disponible, así como el compilador instalado y las opciones que este soportaba.

Utilizar cURL es tan sencillo como pasarle la URL que se quiere descargar. Aunque naturalmente admite una larga serie de parámetros para controlar las salidas que genera por consola, para los distintos protocolos que soporta (HTTP, HTTPS, FTP, SFTP, ...), para la configuración del proxy a utilizar, para enviar información en las cabeceras al servidor, y así un largo etcétera.

De esta forma el proceso automático que nos encargaron quedó como un sencillo shell script programado diariamente en el cron de la máquina.

No es la primera vez que solucionamos este tipo de encargos mediante el uso de software libre. Hace unos meses por ejemplo utilizamos PDFCreator para permitir que los usuarios pudieran generar ficheros en formato PDF directamente desde nuestra aplicación. Y a diario utilizamos herramientas como PuTTY o FileZilla, por poner sólo dos.

Juan Mellado, 3 Noviembre, 2006 - 11:46

Hace poco estuve releyendo uno de los múltiples libros que pululan por mi casa y que tratan, como no, de informática. No recuerdo el título exacto en estos momentos, pero es algo así como "Error fatal: A la caza del error informático". Es un libro algo antiguo, anterior al efecto 2000, pero muchas de las cosas de las que habla siguen teniendo vigencia hoy en día.

En los distintos capítulos se cuentan casos de sistemas informáticos que fallaron en algún momento concreto mientras se estaban utilizando, provocando a veces incluso pérdidas de vidas humanas. Un aparato médico para la administración de radiaciones a enfermos de cáncer que administra una dosis excesiva y letal, un avión que se estrella al contradecir las órdenes del piloto, una falta de previsión que haría fallar a los sistemas informáticos en la medianoche del cambio de milenio, calculadoras y microprocesadores incapaces de obtener el resultado exacto al realizar determinadas operaciones aritméticas, ...

El libro se adentra en los detalles de cada error, haciendo una revisión del antes, durante y después de cada caso de estudio, y sobre todo del porqué. Las conclusiones finales sólo pueden ser las esperadas, señalando la complejidad de los sistemas y el factor humano como los principales responsables de los problemas. En uno de los capítulos se entrevista a una especialista que afirma sin reparos que los errores son siempre causados por el factor humano, incluso los atribuidos al desgaste de materiales, ya que estos debieron haber sido revisados por personas humanas. Y en otro capítulo se señala que la verdadera razón de tanto despropósito es que las aplicaciones informáticas son probablemente los sistemas más complejos jamás inventados por los hombres.

Escapando un poco de las catástrofes, responsabilidades, dificultades, e ineficacia de los sistemas actuales de prueba y verificación de programas se hablan de estudios y sistemas concretos que se pueden aplicar al trabajo diario de un programador con el fin de entender mejor el trabajo que está realizando y disminuir los errores. Uno de los métodos de los que se habla es la "lectura de código", pues sí, algo tan simple como leer con atención el código fuente que escribimos. No es la primera vez que oía hablar de ese método y la verdad es que yo mismo llevo años utilizándolo a diario en mi trabajo sin pensar realmente en ningún momento que estaba aplicando un "método".

Es fácil observar como muchas veces los programadores sin experiencia se limitan a lanzar repetidamente el programa en el que están trabajando para comprobar el buen funcionamiento del mismo y esperando detectar así el máximo número de errores posibles mediante esas pruebas. "Programación empírica" la llamaba un antiguo compañero de facultad. No leen el código, sólo lo escriben. Parece paradójico, pero desgraciadamente no lo es, sucede continuamente.

Supongo que uno de los motivos por los que prefiero y uso casi inconscientemente este método tiene que ver con mi formación como programador a lo largo del tiempo. Hace bastante años era difícil disponer de entornos de desarrollo integrados, la única posibilidad real de depuración de un programa en algunos casos se limitaba a escribir las salidas en un fichero de trazas, y a veces eso no era ni siquiera una opción, por ejemplo cuando se estaba trabajando con una rutina en ensamblador. También se daba el caso de que los ordenadores y las herramientas disponibles no eran tan potentes como lo son hoy en día, por lo que la compilación de un programa demoraba un tiempo excesivo que impedía la ejecución continua y repetida del mismo.

Aunque son de la opinión que un programa es algo más que su código fuente, a veces creo que no le damos la suficiente importancia a cada una de las líneas que tanto trabajo nos cuesta escribir en el editor. Leer el código es una de las prácticas más efectiva de desarrollo que existen, y es algo que no sólo deberíamos limitar a nuestro propio código, sino al de nuestros compañeros de trabajo, y ellos debieran hacer lo propio con el nuestro. Cuando alguien viene a verme para consultarme acerca de un error que está teniendo y no encuentra siempre le pido que abra el editor de código y que me explique leyendo el código como funciona lo que está haciendo, es rara la vez en la que tenemos que llegar a ejecutar el programa antes de detectar el error.

Temas: Opinion
Juan Mellado, 30 Octubre, 2006 - 10:07

Va a hacer un mes desde que me mudé de Madrid a Ciudad Real, y la verdad es que no fue hasta la semana pasada cuando volví a instalar mi ordenador que prácticamente aún no había acabado de desembalar. El sol y las buenas temperaturas de este octubre absolutamente veraniego, amén de una ciudad nueva por conocer, no invitaban precisamente a quedarse en casa pegado al monitor.

Ciudad Real es una ciudad pequeña y tranquila que apenas cuenta con 70.000 habitantes. Aparte de la figura del Quijote, que se ha adueñado de estatuas, parques y museos, las instituciones más destacables son su Universidad, su moderno hospital provincial y su equipo de balonmano. La ciudad cuenta con unas buenas infraestructuras de transporte, destacando el AVE que la comunica con Madrid en tan sólo 50 minutos, y que se verá complementado dentro de poco con un aeropuerto, lo que presumiblemente puede atraer a alguna aerolínea de bajo coste que podría fijar en él alguna de sus sedes.

El sentir de estos primeros días es que la ciudad lucha por dejar de ser considerada como una etapa de paso entre el centro de la península y la costa, al tiempo que observo ciertas dependencias con Madrid, como si mirase en exceso a la villa en busca de referencias. Como posibles salidas se encuentran el turismo rural y las rutas culturales por sus pueblos plagados de historias, amén de los tres parques naturales que nos rodean: Cabañeros, Las Tablas de Daimiel y Las Lagunas de Ruidera, los dos primeros calificados como Parques Nacionales.

En lo personal el cambio puedo calificarlo sin lugar a dudas de bastante positivo. El beneficio más evidente es el aumento de la calidad de vida, como la posibilidad de ir andando al trabajo en un corto paseo de 10 minutos en vez de en 50 en Metro, o de disponer de una mejor vivienda gracias a unos alquileres mucho más asequibles que los de Madrid. Naturalmente existen contrapartidas, como la pérdida de oferta cultural y de servicios, algo que se deja notar en pequeños detalles, como una mayor tardanza en la entrega del correo, o no haber conseguido que Telefónica me instale una línea, ni que sea capaz de darme una estimación del tiempo que va a tardar en instalármela a pesar de haber solicitado el alta en agosto, cuando ya tenía apalabrado el piso.

Básicamente llevo sin Internet en casa desde verano, cuando di de baja la línea de Madrid. He utilizado el móvil puntualmente para conectarme, pero los precios son prohibitivos, hasta 10 euros por 1 Mb descargado a través de una conexión GPRS. La gran trampa de las operadoras de cobrar por volumen. Ni tampoco se puede llamar tarifa plana a un contrato que cubre sólo un 1 Gb de descarga al mes.

Dentro del apartado laboral la mudanza no ha supuesto un gran cambio, ya que sigo trabajando para la misma empresa, sólo que lo hago en las oficinas que tiene en Ciudad Real en vez de las que tiene en Madrid.

A medida que pasan los días me voy acostumbrado poco a poco a mi nueva casa y voy adquiriendo nuevas rutinas. Aún así a veces sigo sin encontrar el interruptor de la luz al entrar en una habitación. Es ese tipo de gestos, automáticos, casi instintivos, que te llevan a levantar la mano en busca del interruptor esperando encontrarlo donde llevas encontrándolo durante los últimos seis años. No en vano se dice que los hombres somos animales de costumbres.