Categoría 'desarrollo'

Tal como se explica en algunos artículos disponibles en la red (como este, este, o este) existen diversas similitudes entre los procesos de desarrollar un determinado software, y la realización de una película desde su concepción inicial. En esta entrada vamos a reunir esas analogías, así como descubrir algunas nuevas.

[…] seguir leyendo en METAeuFORiAS (1421 palabras)

Leo un artículo en el blog de Ricardo Galli titulado Tratar al código fuente como un ensayo que me ha vuelto a crear una conexión entre dos temas que en principio parecen poco relacionados pero de los que se puede extraer alguna enseñanza común; en este caso, la programación y la redacción de textos para la web.

Ricardo habla de un libro (Beautiful Code) y, más concretamente, de un capítulo titulado como su artículo: Treating Code As an Essay. En él se señala la similitud entre el código fuente de un programa y un ensayo, en el sentido de que, si bien en ambos casos su propósito es lo fundamental ("¿de qué se trata?"; "¿qué hace?"), no debe descuidarse el estilo en que están escritos, ya que no sirven de nada si no pueden ser interpretados por seres humanos.

A continuación rescata algunas reglas generales para escribir código de calidad:

• Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante
• Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas creean estrés y reducen productividad. Un lenguaje no debe obligar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
• Simplicidad: Si un programa es complicado de entender no puede tener belleza.
• Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
• etc.

Inmediatamente me han venido a la memoria las reglas que da Jakob Nielsen para escribir para la web; de hecho, algunos de los puntos son prácticamente idénticos: simplicidad, brevedad, lenguaje familiar, etc. Y es que, pensándolo un poco, las situaciones no son tan diferentes:

(sigue …)

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 …)

Me escribe Jesús Hurtado, CEO de Kroonos, solicitándome que le ayude en la promoción de su web ya que pronto (el 31 de octubre) dejará de estar abierto el registro de usuarios; a partir de entonces, será necesaria una invitación. Una mención en este blog no le va a causar ninguna avalancha de visitas, pero aquí queda esto.

El sitio web se autodefine así:

Kroonos es una web 2.0 que te permitirá sacarle partido a tu tiempo libre. Un banco del tiempo global donde podrás dar y recibir ayuda de forma gratuita de otros miembros de la comunidad.

Por el momento no se puede acceder directamente a ninguna funcionalidad específica del sitio; ésta se puede intuir buceando en el foro, en el blog, etc.; pero la falta de algo más tangible posiblemente le resta cierto atractivo a la hora de registrarse. Eso sí; el concepto de una comunidad en la que los usuarios intercambian tiempo para obtener otras cosas a cambio suena lo suficientemente interesante como para tomar nota y seguir su evolución. Yo ya me he registrado.

En lo que respecta al diseño, sin hacer un análisis profundo (es decir, echando un vistazo), el aspecto de la página es bastante claro y agradable. En el caso de una web con un propósito tan original es de agradecer el texto que lleva por título "¿Qué es Kroonos?", en el que se describe su objetivo, aunque como comenté anteriormente se echa de menos una visión más concreta de la funcionalidad que ofrecerá el sitio.

Por último, no puedo evitar que me venga a la memoria Momo, la novela de Michael Ende en la que unos misteriosos hombres grises se fumaban el tiempo de la gente. Seguiremos el desarrollo de Kroonos, aunque sea sólo para comprobar de qué otros extraños modos consume la gente su tiempo.

Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un paso más allá, el patrón MVC propone una separación del software en tres partes:

• Modelo (model): la información con la que trabaja la aplicación ("los datos"). Habitualmente esta parte está soportada por un sistema de base de datos.
• Vista (view): cómo interacciona el usuario con la aplicación ("la interfaz"). En una aplicación web suele utilizarse HTML y CSS.
• Controlador (controller): las acciones que realiza la aplicación ("el comportamiento" o "la lógica").

Muchos frameworks de desarrollo siguen este patrón, ya que las ventajas de esa separación son múltiples: la aplicación resulta más modular, más flexible, facilitando cambios en una de las partes sin necesidad de modificar el resto.

Por ejemplo, una aplicación desarrollada siguiendo ese patrón permitiría fácilmente cambiar el gestor de base de datos (el modelo) sin necesidad de modificar el resto de la aplicación; o desarrollar cada una de las partes de modo independiente; o acceder a la misma aplicación desde diferentes dispositivos como navegadores web o móviles, simplemente creando diferentes vistas.

¿Este patrón no queda del todo claro? ¿Sus ventajas no resultan tan evidentes? Puede que lo comprendamos mejor si establecemos un símil con algo que casi todos conocemos: la estructura de los teléfonos móviles.

(sigue …)

La semana pasada, del 2 al 4 de mayo, estuve en las Jornadas sobre Testeo de Software 2007, organizadas por el grupo SQUaC, en el que estoy trabajando actualmente; así que me tocó colaborar como ayudante de organización Este tipo de eventos son interesantes, no sólo por las ponencias, sino por su "aspecto social": charlas informales, conocer a gente interesante. ¡Ah!, y es una ocasión de practicar (el oxidado) inglés (no queda otro remedio cuando en una misma mesa se encuentra gente de Holanda, Estados Unidos, Alemania… ¡e incluso algún que otro español!)

Todas las ponencias trataron temas relacionados con el testeo; es decir, cómo encontrar errores en las aplicaciones que se desarrollan (porque, igual que las meigas, haberlos, haylos). Podría parecer que no hay mucho misterio en eso: se comprueba que el programa hace lo que debe, ¡y listos!

Pero los sistemas reales son demasiado complicados para verificar todas las maneras posibles de utilizarlos, así que existen multitud de técnicas y herramientas que ayudan a buscar los fallos allí donde puedan estar con mayor probabilidad. De eso precisamente han tratado las jornadas.

Nueva página y blog

Poco antes de que se iniciaran estas jornadas pusimos en marcha la nueva página del grupo SQUaC, que incluye un blog en el que hemos publicado información sobre las ponencias. Todavía estamos añadiendo contenidos y refinando su aspecto, aunque de momento estamos preocupándonos más de los temas de usabilidad y accesibilidad (hay que predicar con el ejemplo); el primer artículo del blog habla con un poco más de detalle de esos aspectos.

¡Por supuesto, estáis todos invitados a visitar la página y participar en el blog!

Muchos de los que nos dedicamos al desarrollo de software utilizamos, conocemos o, como mínimo, nos hemos tropezado con el concepto de framework (cuya traducción aproximada sería "marco de trabajo"). En concreto, y por diferentes motivos, he hecho algún pinito utilizando JavaServer Faces así como en Ruby on Rails.

Sin embargo, el concepto de framework no es sencillo de definir, a pesar de que cualquiera con experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté utilizando su propio framework (aunque no lo llame así).

¿Cuál es el sentido de un framework?

En casa del herrero…

Sabemos por experiencia lo importante que es la normalización de datos en cualquier aplicación. Los usuarios pueden manejar su información en papel, fichas, en su propia memoria, tenerla duplicada, con incoherencias, omisiones, … ¡Todo un infierno! Pero una aplicación informática necesita que esa información esté estructurada de un modo conocido para poder manejarla: almacenarla, recuperarla, y todos los "-arla" que se requieran. Para eso definimos modelos de datos con una determinada estructura (que habitualmente se convierten en tablas de una base de datos).

Pero ¿qué ocurre con la información que manejamos los propios desarrolladores para crear una aplicación? Léase código fuente, librerías, ficheros de configuración, etc. Muchas veces parece que la única elección importante es la tecnología concreta a utilizar (lenguaje de programación, gestor de bases de datos, etc.) pero, a partir de ahí, cada programador puede crear su propio maremagnum de ficheros y código fuente.

¿Por qué permitir ese "desorden" en un desarrollo, si estamos tan convencidos de las bondades de estructurar y normalizar la información? Eso es ni más ni menos lo que pretende un framework.

Entonces ¿qué es un 'framework'?

Siendo muy simple, es un esquema (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Sí, es una definición muy genérica, pero también puede serlo un framework: sin ir más lejos, el paradigma MVC (Model-View-Controller) dice poco más que "separa en tu aplicación la gestión de los datos, las operaciones, y la presentación". En el otro extremo, otros frameworks pueden llegar al detalle de definir los nombres de ficheros, su estructura, las convenciones de programación, etc.

Pongamos un ejemplo: una aplicación web que utilice Java como lenguaje de programación puede implementarse de multitud de formas, mediante servlets y JSPs. Hay algunas convenciones que es necesario seguir, como usar un fichero de configuración web.xml, pero el programador sigue sin tener un patrón claro a seguir para la creación de servlets, clases, JSPs, etc.

En una primera estandarización, la utilización de una arquitectura MVC aconseja que separemos la lógica de la aplicación (en los servlets) de la presentación (usando JSPs); en concreto, no sería correcto codificar lógica de aplicación o accesos a base de datos dentro de los JSP.

Un paso más allá: utilizando Faces como framework, la estructura de la aplicación queda todavía más definida: un único servlet (FacesServlet) va a controlar el flujo de la aplicación; además, el uso de un fichero concreto (faces-config.xml) permite crear la navegación de la aplicación, definir los objetos (beans) pasados como parámetros, etc., todo ello sin necesidad de codificarlo en Java o JSP.

Los frameworks no necesariamente están ligados a un lenguaje concreto, aunque sea así en muchas ocasiones. En el cada vez más popular Ruby on Rails, 'Ruby' es el lenguaje de programación y 'Rails' el framework; por otro lado, JavaServer Faces está orientado a desarrollos en Java. Sin embargo, nada impide definir el mismo framework para lenguajes diferentes: por ejemplo, existe un framework llamado Biscuit cuyo objetivo es prácticamente convertirse en un "PHP on Rails". Eso sí, cuanto más detallado es el framework, más necesidad tendrá de ceñirse a un lenguaje concreto.

También es posible que el framework defina una estructura para una aplicación completa, o bien sólo se centre en un aspecto de ella. Siguiendo con los ejemplos, Ruby on Rails ofrece un marco para el desarrollo completo de una aplicación web, mientras que JavaServer Faces está más orientado a la interfaz de usuario.

¿Qué ventajas tiene utilizar un 'framework'?

Las que se derivan de utilizar un estándar; entre otras:

• El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que "rellenar".
• Facilita la colaboración. Cualquiera que haya tenido que "pelearse" con el código fuente de otro programador (¡o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.
• Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el desarrollo.

¿Y si no necesito o no quiero utilizar un 'framework'?

Por supuesto, un desarrollador puede crear toda una aplicación sin seguir ningún framework conocido; puede que sea tan pequeña que no lo considere necesario, que no conozca ninguno que se adapte a sus necesidades, o simplemente no desee dedicar tiempo a seleccionar y utilizar uno.

Sin embargo, a medida que la aplicación crece, un programador competente procurará seguir unas determinadas pautas que le faciliten su trabajo de desarrollo y mantenimiento: separación de presentación y lógica, una sintaxis coherente, etc. La evolución natural sera hacia que, de algún modo, se construirá su propio framework.

Y en vez de definir un estándar, ¿por qué no utilizar uno ya definido, y aprovechar el trabajo de otros muchos desarrolladores? Hacer un desarrollo críptico y difícil de interpretar puede ser útil en un concurso de código ofuscado o para presumir de "gurú", pero es muy poco útil para desarrollar y mantener una aplicación. El coste inicial (la curva de aprendizaje) de utilizar un framework se compense probablemente en cuanto el trabajo de desarrollo crezca mínimamente.

De acuerdo; pero ¿qué 'framework' utilizo?

Buscando en la red se encuentra mucha información sobre los frameworks existentes para las diferentes plataformas y lenguajes. Posiblemente uno de sus principales problemas es que haya demasiados: ya se sabe, lo bueno de los estándares es que hay muchos para elegir . Sin embargo, la elección del framework concreto a utilizar vendrá marcada por:

• El tipo de aplicación a desarrollar
• El lenguaje de programación y otras tecnologías concretas: base de datos, sistema operativo, etc.

Como introducción a los frameworks, Ruby on Rails me parece una buena opción para desarrollar una aplicación web y como ejemplo de lo que es un framework. Dentro del mundo Java, Struts parece uno de los más extendidos.

En conclusión

La utilización de un framework en el desarrollo de una aplicación implica un cierto coste inicial de aprendizaje, aunque a largo plazo es probable que facilite tanto el desarrollo como el mantenimiento.

Existen multitud de frameworks orientados a diferentes lenguajes, funcionalidades, etc. Aunque la elección de uno de ellos puede ser una tarea complicada, lo más probable que a largo plazo sólo los mejor definidos (o más utilizados, que no siempre coinciden con los primeros) permanezcan. Y si ninguno de ellos se adapta a las necesidades de desarrollo, siempre es mejor definir uno propio que desarrollar "al por mayor".