Aplicaciones autoadministradas y autoreparadas

Después de asistir a la conferencia de un gurú (o eso dijeron) de la arquitectura de software en un congreso, me llevo la idea de que el desarrollo de aplicaciones que sean capaces de administrase ellas solitas (y de paso repararse) es un buen nicho de mercado.

Esto no es, ni mucho menos, ciencia-ficción. Si no me equivoco la plataforma Java ya incorpora desde hace tiempo interfaces de monitorización de componentes bajo el nombre de JMX.

Para poder hacer esto, dado que la tecnología existe, lo que hay que hacer es plantearlo desde el comienzo del desarrollo de la aplicación e incluir en nuestra aplicación, módulos que monitoricen el funcionamiento de la misma y que tengan la capacidad de tomar las medidas correctivas necesarias. Esto puede venderse muy bien, ya que, como nos comentó el gurú, por cada dólar gastado en adquirir una aplicación (esto incluye el desarrollo a medida), se gastan nueve dólares en su administración y mantenimiento (en euros será menos, seguro). Si podemos desarrollar aplicaciones autoadministradas, podemos reducir el gasto durante toda la vida útil de la aplicación de nuestros clientes 9 veces, lo cuál es bastante interesante.

Además una aplicación que sea capaz de arreglarse a sí misma, es una aplicación que no tiene por qué detenerse nunca, lo cuál es muy beneficioso en ciertos nichos de mercado.

Presentaciones "De casos de uso a casos de prueba" en mi web

Saludos.

He puesto en mi web el 95% de las presentaciones que voy a usar en el seminario "De casos de uso a casos de prueba" que impartiré el martes 24 en el evento SoloRequisitos. La dirección es:

http://www.lsi.us.es/~javierj/cursos.htm

Después del evento publicaré el 100% de las transparencias, aunque el 5% que falta son las menos importantes.

Feliz otoño

Eclipse. Caballo ganador en la investigación

Saludos.

A menudo nos encontramos comparativas entre Eclipse y NetBeans y muchas veces nos da la impresión (al menos a mí) de que ambas plataformas tienen una lucha feroz por imponerse en el mundo de la empresa.
sin embargo en el mundo de la investigación y las universidades no es así. Por lo que he podido ver en un reciente congreso, todo el mundo usa Eclipse y desarrolla sus ideas a partir de Eclipse. En ese sentido, el EMF es una herramienta de uso casi inevitable. Netbeans no aparece por ningún sitio ni se le espera.

¡Dios mío, yo uso Netbeans!. ¿De dónde me puedo descargar Eclipse?.

Evitando el lado oscuro de las pruebas (y II)

Como ya comentamos hace tiempo en este blog, las pruebas de código tipo JUnit tienen un lado oscuro. Si el código cambia, las pruebas pueden quedar inservibles, lo cuál supone un desperdicio de tiempo y recursos.

La solución que propuse fue la de intentar automatizar lo máximo posible la generación de pruebas. Así, si el código cambiaba, simpleente se volvía a ejecutar el programa que generaba un nuevo conjunto de pruebas.

Otra posible solución que se ha comentado en el taller de pruebas es la verificacón estática del código. Es decir, revisar el código para buscar errores antes de ejecutarlo. Según comentaron, las revisiones estáticas de código pueden resolver cerca de un 80% de los errores básicos. Un artículo muy bueno al respecto puede encontrase en (http://in2test.lsi.uniovi.es/pris2006/).

Feliz otoño.