1/10/2004

¡HA VUELTO GOMAESPUMA!

Gomaespuma.TV

Vale, esta noticia no tiene nada que ver ni con ISW ni con distribuidos... pero es que ¡ha vuelto gomaespuma!

Aquí los tenéis.
MÉTODOS DE APRENDIZAJE AUTOMÁTICO PARA MODELADO DE ESTILO MUSICAL (I)

IEEE Computer Society Digital Library

Llevo meses queriendo leer y pensar acerca de un artículo de la revista "Computer", de la IEEE Computer Society del mes de Octubre pasado:
"Using machine-learning methods for musical style learning", por Dubnov et al.

Se parte de una premisa -aparentemente bien documentada- de que el proceso de composición musical no es, para nada, una actividad aleatoria, sino que, aunque complicado, es formalizable.

Después comenta las dos capas principales de una composición: la "superficie musical", esto es, el pentagrama con sus notas, silencios, etc., y las características estilísticas, como el ritmo, la melodía, la armonía, etc. Gracias a aproximaciones estadísticas se pueden capturar las relaciones redundantes de estos estilos, y generar nuevas instancias de secuencias musicales que las adopten, con lo que serían del estilo de los ejemplos origen.


Con este tipo de herramientas, las aplicaciones que se podrían generar son, por ejemplo, las siguientes:

1. Herramientas de caracterización estilística para musicólogos.
2. Obtención inteligente de información en bases de datos musicales.
3. Generación musical automática para aplicaciones web, de juegos, etc.
4. Improvisación automática con o sin supervisión humana
5. Composición asistida por ordenador.


Ya era posible la generación automática de música a partir de la codificación de un conjunto de reglas musicales en algún tipo de lógica -reglas- o gramática formal, es decir, mediante la construcción de un sistema experto. El problema con esto es la necesidad de una explotación masiva del conocimiento musical -¿es esto un problema?-. El planteamiento de los autores es la utilización de técnicas estadísticas o inducción empírica.


Algunas opciones anteriores fueron:
- Utilización de Cadenas de Markov -que dependen del contexto inmediatamente anterior para generar un nuevo estado-: cuando se han utilizado cadenas de orden bajo, se ha visto que no eran útiles, mientras que a órdenes más altos, se llegaban a cadenas similares al corpus inicial.
- David Cope utiliza generación de gramática + "signatures" -microgestor melódicos de un autor concreto-. Con ambas cosas, consigue nuevas composiciones.

Este artículo busca la obtención automática de estos microgestos: pattern matching, me imagino.


1/09/2004

SPRING FRAMEWORK PARA J2EE (I)

Spring - j2ee Application Framework

Justo antes de navidades, Fabio García, ex-alumno de Nebrija, me recomendó que le echase un vistazo a este framework para J2EE. Que sirva este post para empezar a hacerle caso!

Sus "estatutos" son, principalmente, los siguientes:
- Es mejor programar sobre interfaces que sobre clases. En eso, estoy TOTALMENTE DE ACUERDO, aunque cuesta darse cuenta al principio.
- Se basan en JavaBeans.
- El diseño de la aplicación, mediante técnicas OO, es más importante que la tecnología utilizada, como J2EE. Chapeau!
- Un framework no debería obligarte a capturar tantas excepciones como te obliga Java con sus "checked exceptions".
- Las pruebas son fundamentales, y un framework debería "integrarlas" en el desarrollo habitual -volvemos al test-driven development de hace un par de posts-.


En este artículo del ServerSide se resume el Framework de Spring.

[KITKAT:
En este artículo se habla de POJOs, y no sabía lo que era: el WIKI de Martin Fowler lo explica... y, desgraciadamente, creo que tiene razón!
]

Lo primero de todo es decir qué NO ES Spring, y no tiene:
- No hay paquete de logging. Ya hay buenos en el mercado.
- No hay connection pool.
- No hay O/R mapper: JDO o Hibernate lo hacen genial.


Si ofrece -es decir, compite con otros- en:
- MVC framework -contra Struts, por ejemplo-.
- Contenedor ligero de componentes -ya hablé de ello en el post del Exo Container-.


Resumiendo lo que dice el artículo -¡aviso! artículo denso para los que no estén acostumbrados a vocablos del estilo JNDI, EJB, MVC, IoC, DAO, DBCP, etc.-:

Una característica que me atrae es la de no tener que instrumentalizar tu código con implementación de interfaces o extensión de clases, sino que la metadata y la utilización de una estructura JavaBean es suficiente.

Mejoran el API de JDBC para evitar tareas tediosas como el cierre de ResultSets y Statements, y para crear una estructura de excepciones, más allá del SQLException clásico.


DESARROLLO DE APLICACIONES CONDUCIDAS POR PRUEBAS -TEST-DRIVEN-


TheServerSide.com J2EE Community - Test-Driven Development Series Part I - Overview


Me parece increíble como, desgraciadamente, hay que inventarse nuevos conceptos para que los profesionales apliquen técnicas, flujos o metodologías que existen desde hace años, y que desde hace años también, se sabe que son fundamentales. Es el caso de las pruebas. No es una crítica contra los que inventan estas nuevas metodologías, sino contra todos los que no terminamos de aprender.

El artículo comienza describiendo los problemas de la realización manual de pruebas:

- Es repetitivo: si en un proyecto se realizan pruebas de regresión en cada defecto producido, ¿cuántas veces habremos de realizar una misma prueba? La primera vez es divertido, pero la decimocuarta...
- Da lugar a errores: porque somos humanos y nos cansamos, y no nos fijamos.
- No se prueba todo: las pruebas manuales tienden a ser pruebas de usuario, las cuáles son importantísimas -sobre todo en metodologías centradas en casos de uso-, pero a veces no suficientes, hay que ir más abajo.
- Otros han de creer en tu palabra... o tú has de demostrar que lo que dijiste que funcionaba, lo hacía de verdad.

La automatización de pruebas de manera integrada implica el que los casos de prueba, además de ser programados para poder repetirse una y otra vez -con lo cuál han de ser idempotentes-, han de evolucionar al mismo ritmo que el código probado, lo cuál nos obliga a un segundo esfuerzo que merecerá la pena al final.

Hay dos aproximaciones para este tipo de pruebas: la utilización de scripts que automatizan las pruebas de usuario, y APIs de Pruebas, como JUnit, para incluir en el propio código de la aplicación. Las APIs permiten lo siguiente:
- Seguir la regla TestFirst - DeployLater, seguida por varias metodologías, como ExtremeProgramming o, aunque no se diga explícitamente, el Proceso Unificado -aunque lo de que los casos de prueba deben realizarse antes de la implementación puede dar alguna pista-.
- Realizar pruebas unitarias.
- Realizar pruebas funcionales. Este es el único punto donde los scripts de pruebas de usuario hacen lo mismo, y quizá más rápidamente.

El artículo termina con una lista de las APIs más utilizadas en Java para tests.

¡A probarlo todos! ;)


LA LEY DE DEMETER PARA SISTEMAS ORIENTADOS A OBJETOS

Law of Demeter

De la web: Demetrio es el dios griego de la agricultura: construye el software en pequeños pasos

En este enlace se da una definición un poco más detallada: cada unidad sólo debe tener conocimiento limitado acerca de otras unidades: sólamente unidades "cercanas entre sí" deben conocerse: no hables con extraños.

Realmente, esto ya se ha discutido en clase tanto de Ingeniería del Software como en Distribuidos cuando se habla de obtener una cohesión máxima, pero un acoplamiento mínimo. La Ley de Demeter busca el desacoplamiento entre elementos para obtener una arquitectura en capas que permita su reutilización y su facilidad de cambio y ampliación.

Según los artículos enlazados en la página, esta idea de limitación de conocimiento por parte de elementos -o métodos- da pie a la Programación Orientada a Aspectos -AOP-.

En este otro enlace se define la ley de Demeter para Objetos, que, resumiendo, viene a decir que dentro de un método sólo se pueden enviar mensajes a objetos que sean parámetros del método, a métodos de él mismo, a objetos creados en el método, a un elemento de una colección que sea un atributo del objeto, y a un objeto devuelto por un método del objeto que invoca.

En ningún sitio se dice que esto sea fácil de conseguir, pero sin duda da lugar al desacoplamiento más adecuado para manejarse con sistemas que pueden cambiar constantemente.

Esto me lleva a apuntarme para próximos "posts" una explicación un poco más detallada de la Orientación a Aspectos. El curso pasado trajimos a un experto en AOP que ya explicó los fundamentos, pero vamos a ver si lo entendemos mejor.

1/08/2004

INTRODUCCIÓN A LA PLATAFORMA EXO

EXO

La plataforma EXO es un portal que cumple la JSR 168 -portlets-.


Los elementos fundamentales son:
1. Sistema de gestión de contenidos: a partir del Patrón Composite, y utiliza Programación Orientada a Aspectos (AspectJ). En la documentación comentan que en cuanto se publique la JSR 170 -Content Repository por Java-, la implementarán.

2. Contenedor de Portlets: basado en el PicoContainer, un contenedor de componentes basado en el Patrón de Inversión de Control (IoC, en su versión: Type 3 IOC).

3. Portal: implementa el JSR-127 -JavaServer Faces-, que implementa una arquitectura MVC -es la especificación de lo que antes lideraba Struts-.


Si hubiera tiempo... :( Pero bueno, seguiremos informando!
MÍRALE, ES UN TÉCNICO

TheServerSide.com J2EE Community - He's Just a Techie - Image and Impact of the Software Developer

Aunque sea, leed el chiste inicial... y con eso entenderéis cuán acertado es este artículo, al menos en su planteamiento.

Aunque trata diversos temas, me quiero centrar en dos:
- La necesidad de la certificación como "válvula de escape"
- La integración de los técnicos en la estructura corporativa de la empresa.

El primer punto se lleva discutiendo años en España, y lleva a peleas casi sangrientas entre los que exigen un Colegio nacional que ponga orden a esas "hordas de infieles que nos quitan la mujer, nos roban la comida y nos invaden la casa" -vamos, que nos quitan el trabajo ;)- a los que lo ven de una manera más fría y con algo de autocrítica por parte de los que nos consideramos "ingenieros" más que "informáticos". Ese es un tema en el que hoy no me apetece meterme.
Sin embargo, sí creo que el concepto anglosajón de la acreditación o certificación puede tener un futuro adecuado si conseguimos dividir entre las certificaciones profesionales de empresas del sector -ingenieros MSoft, CCNA de Cisco, BEA Architect- y las otorgadas por asociaciones multinacionales -estoy pensando en el CSDP de IEEE Computer Society para Ingenieros de Software que, por cierto, llevo tiempo planteándome... quizá para cuando acabe la tesis ;) ;) ;) -.


El otro punto es el que los técnicos, o los directores de departamentos de IT o sistemas tengan peso en la toma de decisiones de la empresa. El artículo de Pilgrim lo expresa muy bien. Se empieza con un "qué va a saber el Java-man este del negocio" y se termina dándose cuenta de que este "Java-man" está implementando todo el business process, lo que conlleva la integración de todas las aplicaciones interdepartamentales, y alguna que otra más. ¿De verdad que no sabe del negocio? ¿De verdad que no tiene nada que decir? Me extraña. Aunque lo que quizá ocurra es que no hable directamente de €$ sino de optimización.

Como nota final: en cada momento, en cada situación, hay que contar siempre con los que tienen ALGO QUE DECIR.



CÓMO CONVERTIR JAVA EN LA PLATAFORMA PERFECTA...

In pursuit of perfection

Humphrey Seil pretende identificar en este artículo qué debería ser una plataforma de desarrollo perfecta, y, tras estudiar las mayores debilidades de Java, ver si ésta podría serlo en un futuro cercano.

Su definición de "plataforma tecnológica perfecta" es aquella capaz de ser utilizada por "niños y viejos" para realizar cualquier tipo de aplicación en toda plataforma hw, y que corra en modo nativo o casi.

Primero, comienza dejando claro algo que siempre se ha sufrido: la curva de aprendizaje de Java en entornos empresariales -J2EE- es alta, y la dificultad de algunas de sus funcionalidades, también. No sólo J2EE como tal, sino las herramientas de desarrollo, todavía tienen mucho que currar para llegar la nivel de VStudio. Quizá el WebLogic Workshop esté ahí, tengo que verlo todavía.

Por tanto, las fortalezas que comenta son, por ejemplo:
- soporte de la plataforma
- separación entre especificación de Java y Runtime.
- Comunidad de desarrolladores.
- plataforma estable y madura.
- inserción en la universidad.

Desventajas:
- Comunidad de desarrolladores: demasiado activa.
- Complejidad creciente.


Puntos débiles, desafíos:
- La plataforma por defecto es demasiado pobre: falta Ant, XDoclet, ...
- Evolución darwiniana radical: que sólo el mejor sobreviva, por ejemplo:
- Persistencia: EJB vs. JDO vs. Hibernate.
- IDE: NetBeans vs. Eclipse.
...o que se llegue a un acuerdo!
- Keep It Simple!!!
- Creación de JCP "lite": la Java Community Process es el lugar donde las nuevas especificaciones de Java aparecen. Sin embargo, como con casi cualquier organismo de especificación, leer lo que escriben no es fácil. El autor propone un documento "simple" donde los "usuarios" puedan, al menos, empezar.


De todo lo que el autor propone, no tengo tan claro que la uniformidad lleve a la perfección. Gracias a proyectos "paralelos" a la industria, como Sprite, March, Chorus, ... los sistemas distribuidos siguieron avanzando. El que haya "guerras" acrecienta la iniciativa y la originalidad -siempre visto como competitividad bien entendida-.
La promesa de BEA Workshop de "realizar aplicaciones Java sin programar Java", o una vuelta a esa utopía llamada JavaStudio (sniff!) puede abrir puertas al futuro de Java, pero habrá que irlo viendo.





TRANSACCIONES, ESOS GRANDES DESCONOCIDOS... HASTA AHORA

XA Exposed, Part I


El pasado 5 de Enero (hace dos días) el Spille Blogs publicó la primera parte de su "magnum opus" sobre el Commit en 2 Fases. Me parece interesante comentarlo y resumirlo para "abrir boca" y así­ lo devoráis mejor.

El artí­culo comienza con un recordatorio de la integración de sistemas en los 80 y 90, y del problema principal de la agregación de esas "islas de datos" que poblaban (¿poblaban o pueblan?) el mundo empresarial.

Una primera solución al problema de realización de consultas y actualizaciones sobre datos distribuidos en diferentes bases de datos -consistencia, coherencia, etc.- fue el Commit en 2 Fases -2Phase Commit, 2PC o XA- que introduce el concepto de transacción global, y amplí­a el concepto de transacción obtenido ya hací­a tiempo por las bases de datos relacionales a través de sus caracterí­sticas ACID (Atomicity, Consistency, Isolation, Durability), a bases de datos distribuidas.


Como bien se apunta en el BLOG, las transacciones distribuidas estuvieron olvidadas por el "informático medio" durante algunos años. Pero ahora, con la necesidad de EAI (Enterprise Application Integration)y EII (Enterprise Information Integration) existente, con arquitecturas así­ncronas tipo JMS, se hace vital el contar con un soporte transaccional distribuido... ahora todo el mundo tiene que saber de XA.

El resumen de 2PC lo tomo directamente del blog:
"1. start(Xid) - enlist the resource as part of the transaction
2. end(Xid) - tell the resource that no more transactional work is coming its way
3. prepare(Xid) - prepare for commiting. The resource can respond "OK" or "oh no!". The latter indicates that the whole global transaction should be rolled back.
4. commit(Xid) - Really commit.
", donde Xid es el identificador de la transacción realizada (
XID Javadoc).


Esta frase me hace gracia: "The JTA specification, along with its philosophical parent, the X/Open XA specification[...]". Es como si poco a poco se fueran creando varios tipos de "ingenieros sw": los que leen y entienden y aprecian las especificaciones originales, y los que sólo las aceptan como base de algo más moderno y entendible, y, sobre todo, más práctico. Es como si tuviéramos la frase "La película Matrix, junto con su padre filosófico, La Caverna de Platón[...]" ;)

Un punto bastante conocido de la teoría transaccional local, pero que no deja de ser importante, es que el mayor coste en tiempo de ejecución proviene de lo que en el blog se denomina "disk forcing". Todas las operaciones realizadas han de ser almacenadas en disco para poder ser trazadas ("traceadas"), y de esa manera tengamos tolerancia a fallos (recuperación ante fallos).

Muy interesante, esperaremos a la segunda parte de su trabajo!

1/07/2004

TRANSACCIONES, ESOS GRANDES DESCONOCIDOS... HASTA AHORA

XA Exposed, Part I: "2PC"


El pasado 5 de Enero (hace dos días) el Spille Blogs publicó la primera parte de su "magnum opus" sobre el Commit en 2 Fases. Me parece interesante comentarlo y resumirlo para "abrir boca" y así lo devoréis mejor.

El artículo comienza con un recordatorio de la integración de sistemas en los 80 y 90, y del problema principal de la agregación de esas "islas de datos" que poblaban (¿poblaban o pueblan?) el mundo empresarial.

Una primera solución al problema de realización de consultas y actualizaciones sobre datos distribuidos en diferentes bases de datos -consistencia, coherencia, etc.- fue el Commit en 2 Fases -2Phase Commit, 2PC o XA- que introduce el concepto de transacción global, y amplía el concepto de transacción obtenido ya hacía tiempo por las bases de datos relacionales a través de sus características ACID (Atomicity, Consistency, Isolation, Durability), a bases de datos distribuidas.


Como bien se apunta en el BLOG, las transacciones distribuidas estuvieron olvidadas por el "informático medio" durante algunos años. Pero ahora, con la necesidad de EAI (Enterprise Application Integration)y EII (Enterprise Information Integration) existente, con arquitecturas asíncronas tipo JMS, se hace vital el contar con un soporte transaccional distribuido... ahora todo el mundo tiene que saber de XA.

El resumen de 2PC lo tomo directamente del blog:
"1. start(Xid) - enlist the resource as part of the transaction
2. end(Xid) - tell the resource that no more transactional work is coming its way
3. prepare(Xid) - prepare for commiting. The resource can respond "OK" or "oh no!". The latter indicates that the whole global transaction should be rolled back.
4. commit(Xid) - Really commit.
", donde Xid es el identificador de la transacción realizada (
XID Javadoc).


Esta frase me hace gracia: "The JTA specification, along with its philosophical parent, the X/Open XA specification[...]". Es como si poco a poco se fueran creando varios tipos de "ingenieros sw": los que leen y entienden y aprecian las especificaciones originales, y los que sólo las aceptan como base de algo más moderno y entendible, y, sobre todo, más práctico. Es como si tuviéramos la frase "La película Matrix, junto con su padre filosófico, La Caverna de Platón[...]" ;)

Un punto bastante conocido de la teoría transaccional local, pero que no deja de ser importante, es que el mayor coste en tiempo de ejecución proviene de lo que en el blog se denomina "disk forcing". Todas las operaciones realizadas han de ser almacenadas en disco para poder ser trazadas ("traceadas"), y de esa manera tengamos tolerancia a fallos (recuperación ante fallos).

Muy interesante, esperaremos a la segunda parte de su trabajo!

IDENTIDAD DE OBJETOS: DIFERENCIA ENTRE JDK1.1 Y J2SE

Object Identity and why JDK 1.0.2/1.1 was better than 1.2+

Poco que comentar aquí, pues el artículo es breve y conciso: la identidad de objetos es vital en los sistemas distribuidos, y hay que conocer con detalle cada versión de Java que estemos utilizando. Como comenta el blogger al final del artículo, C# utiliza la misma filosofía que la versión 1.1 de JDK.



PORQUE INNOVAR, POR SÍ SOLO, NO ES SUFICIENTE EN ESTE MUNDO

Fast Company | If He's So Smart...Steve Jobs, Apple, and the Limits of Innovation

"Innovar... eso es lo que hacemos". Y sin embargo, Apple no acaba de conseguir lo que ha deseado durante años: lo que Microsoft, Dell, IBM, ... tienen: ventas.

El artículo llega más lejos: Apple no es como Xerox PARC: Apple inventa cosas que son vendibles al 200%, incluso "molan" -cool-.

Me encanta el resumen del último sidebar:
1. Not All Innovation Is Equal
La innovación puede ser de la que te produce seguidores, y de la que te produce dinero. Uno es Apple, el otro es Dell.
2. Innovate for Cash, Not Cachet
Siempre hay que actuar pensando en la estrategia comercial de la compañía.
3. Don't Hoard Your Goodies
Esta es una idea típica: cada producto tiene su momento, no lo desperdiciemos.
4. Innovation Doesn't Generate Growth. Management Does
Pues eso.
5. Attention Deficit Has No Place Here
Y si se saca un producto innovador, mímalo todo lo que puedas. Cualquier puede copiarlo y dejarte sin porcentaje, a pesar de que hayas sido el inventor.


Por eso creo que es importante que los proyectos sean acometidos por, al menos dos perfiles bien diferenciados: es difícil ser a la vez el inventor "ilusionado e ilusionante" y el gerente práctico que intenta buscar en cada momento la opción más ventajosa de posicionamiento. Quizá no se lleven bien del todo, pero cada uno ha de respetar la otra parte. Creo que muchos tenemos ejemplos que poner, de nuestra propia experiencia profesional.

¿Se enseña esto en los MBAs en Innovación o Emprendedores? Esa es la idea en la que deben apoyarse estos cursos de postgrado: la idea llega, pero hace falta mucho más para ponerla en marcha, y, sobre todo, mantenerla ahí arriba.






ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? CONCLUSIONES (y V)

El capítulo 25 trata sobre aquellos proyectos donde, en principio, XP no tiene cabida.

- Cuando el cliente requiere un "libro de especificaciones", perfectamente cerrado antes de comenzar a desarrollar.
- Proveedores acostumbrados a 100h/semana.
- Número de desarrolladores / tamaño del proyecto.
- Tecnología con curva exponencial de coste.
- Construcción de frameworks: en XP se construyen aplicaciones.

Lo cierto es que en la actualidad la mayor parte de los proyectos tendrían posibilidad de utilizar XP según el libro.

ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? PR�CTICAS (IV)
- Las prácticas de XP:

1. Planning Game: diálogo entre negocio y técnico. Sin duda uno de los puntos calientes, que no creo que ninguna metodología pueda resolver, pues la gente de negocio no se atendrá a ello casi nunca -y esto no es echarles las culpas, sino que una metodología no puede dictarles cómo comportarse-.

2. Pequeñas releases: poco que decir. El PU, el modelo en espiral de Boehm, ... lo plantean desde siempre. La idea es hacer las releases cortas, consistentes y estables.

3. Metáforas: entiendo que es lo más cercano a una mezcla entre requisitos funcionales y no funcionales, pero estructurados como la arquitectura del sistema.

4. Diseño simple: está en contra del dicho de diseñar con el futuro en mente. No digo que no pueda ser factible en muchas aplicaciones, pero ¿no corremos el riesgo de posicionarnos en el otro extremo?

5. Pruebas: nada que decir: probar, probar, probar.

6. Refactoring: modificación del código, y reestructuración posterior para ver si es posible simplificarlo tras el cambio. No soy un experto en refactorización, apenas he tenido que hacerlo "en serio" un par de veces o tres. Queda pendiente la lectura del libro de Martin Fowler Refactoring: improving the design of existing code.

7. Pair programming: ya lo he comentado en un post anterior: pair programming, sí, pero con "minutos de soledad", como cuando vives en pareja ;)

8. Pertenencia colectiva: me parece perfecto, pero eso obliga a utilizar el estado del arte de las herramientas de gestión de versiones.

9. Integración continua: esto lo he podido comprobar de primera mano en un gran proyecto realizado hace unos años, y, de verdad, ¡funciona! Aunque, tal y como dice Beck, suele obligar a tener una máquina de integración dedicada, debido a la gran cantidad de checkins-checkouts-integraciones que se realizan al día.

10. Semanas de 40 horas: jajajajajajajajajajajajajajajajajajajajajajajajajaja!!!!!! Seamos realistas. Estamos de acuerdo en que una cosa es un "pico", y otra una "meseta"=conjunto de picos continuos. Pero esto no lo va a cambiar XP, me temo.

11. Cliente al lado: me parece una gran idea, que jamás he visto en serio. O el cliente no tiene tiempo para estar "ahí contigo", o tú no lo quieres "ahí contigo".

12. Estándares de codificación: mi duda -y lo es de verdad- es si hay o habrá estándares oficiales y mundialmente reconocidos de codificación para cada lenguaje de programación.


Mi impresión es que es un "mix" de ideas muy bien pensadas y valoradas, junto a una lista de deseos que, de vez en cuando, se cumplen.
ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? PRINCIPIOS BÁSICOS (III)

- Retroalimentación rápida: vamos, que reaccionemos cuanto antes.

- Asumir simplicidad: tal y como escribí en mi post anterior, es la parte que menos clara tengo. Quizá soy un ingeniero de sw "de los de antes", que da mucha importancia a la reutilización, y al dejar las cosas preparadas para posibles cambios futuros. Es cierto que esta filosofía conlleva más trabajo, y quizá la mayor parte de los desarrollos no lo requieran, pero también es tarea del ingeniero la de saber cuál es el nivel de complejidad que la herramienta va a requerir.

- Cambio incremental: con esto tengo que estar de acuerdo. Llevo años aplicado el Proceso Unificado, que se basa también en esto.

- Abrazar el cambio: ¿dónde está mi queso? ;)

- Trabajo de calidad: aquí sí creo que el "pair programming" ayuda. Aún dando por hecho que todos queremos hacer un trabajo de calidad -y habría que discutirlo en algunos casos-, desde luego, a nadie le gusta hacer el ridículo delante de un compañero. Esta situación nos obliga a sacar lo mejor de nosotros mismos.
Sin embargo, hay veces que el trabajo de dos en dos dificulta o coharta ese tiempo de reflexión que algunos necesitamos para llegar un poco más lejos.


Otros principios que se citan en el libro son, entre otros:
- Juega para ganar: en la universidad yo siempre decía lo mismo: me presento al examen para sacar un 10. Es la única manera de, salga lo que salga, salir orgulloso, y, desde luego, la única de poder ganar. Kent Beck habla de baloncesto, del equipo de UCLA de John Wooden. Si alguna vez habéis jugado a un deporte de equipo, sabéis lo que significa llegar a los segundos finales y "saber" que ese partido lo ganais, o tirar con tres tíos defendiéndote y "saber" que ese balón entra en el aro sin tener que comprobarlo.

- Aceptación de responsabilidad: bueno, esto no es nuevo, ya existe desde hace años en
el código ético del IEEE.

Sin duda la mayor parte de los profesionales del sw son sinceros, y aceptan sus errores. ¿Pero todo el mundo es así? ¿Cómo minimizar ese número?


ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? VALORES (II)

El capítulo 7 se centra en los cuatro Valores fundamentales de XP:
1. Comunicación: totalmente de acuerdo. Soy un defensor de las habilidades emocionales en la formación de un ingeniero o, en este caso, de un desarrollador. No dejan de ser elementos de un equipo, y los equipos funcionan con comunicación.

2. Simplicidad: este valor me da miedo. Aun creyendo en la simplicidad dentro de un diseño, veo dos problemas -sin meternos en tecnicismos-:
- ¿Cómo conseguir que el equipo completo entienda de la misma manera este concepto? Lo que para un es "simplificar", para otro es no comprender la complejidad del sistema.
- La filosofía "lazy" adoptada me puede resultar peligrosa cuando se trata de crear frameworks. Obviamente "simplicidad" no significa lo mismo en este ámbito que en el de una aplicación ad-hoc, pero ¿cómo simplificar en un desarrollo que busca ser lo más generalista posible?

3. Retroalimentación: sin duda. Se basa sobre todo en la realización constante de pruebas -de unidad, funcionales, etc.- y casos de prueba.

4. Coraje: igual que en el segundo valor, ¿qué significa coraje cuando cada componente del equipo lo entiende de diferente forma?

Y el quinto: el respeto. Ahí sí que me han dado. Ojalá existiera ese respeto en todos los proyectos, desde los grandes proyectos de decenas de personas, hasta los que involucran a tres o cuatro estudiantes de 4º de ingeniería informática...



ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? INTRODUCCIÓN (I)

Amazon.com: Books: Extreme Programming Explained: Embrace Change

El párrafo inicial sobre la Serie de libros sobre XP de Kent Beck resume la filosofía subyacente de XP: (traduciendo) "Si queremos eliminar confusión del desarrollo de software, debemos estar preparados para abrazar completamente las pocas 'prácticas' que adoptemos. Medidas tomadas a medias dejan problemas sin resolver que serán posteriormente tomadas por otras medidas a medias."

El libro está dividido en dos partes fundamentales: el problema y la solución.

El problema básico en un proyecto sw es, según Beck, el riesgo, y da varios ejemplos de riesgo:
- Fallos de planificación
- Cancelación de proyecto
- Ratio de defectos
- Cambios de procesos de negocio
- Cambios del equipo
- ...

Para cada ejemplo, Beck da la solución que XP tiene para evitar esos riesgos o, al menos, mitigarlos, p.e.:
- Fallos de planificación: metodología iterativa con ciclos cortos.
- Cancelación de proyecto: se pide que el cliente elija la release más pequeña que tenga más sentido.
- Ratio de defectos: tests constantemente.
- Cambios de procesos de negocio: los ciclos son muy cortos, es más difícil que el negocio cambie.
- Cambios del equipo: debido a la metodología, el desarrollador se frustra menos, se aumenta el contacto humano social, etc.
- ...

El capítulo 4 habla de las cuatro variables clásicas en la gestión de proyectos: Coste, Tiempo, Calidad y Alcance. -otro autor que ahora no recuerdo hablaba del dicho de la ingeniería del software: hay cuatro variables en la gestión de proyectos: elige dos ;) -.

ESCRIBIENDO CASOS DE USO EFECTIVOS

Amazon.com: Books: Writing Effective Use Cases


Estoy releyendo el libro de Cockburn, Writing Effective Use Cases.
Algunos puntos importantes del libro son los siguientes:
- El concepto de caso de uso de Cockburn no es exactamente el de UML, aunque en el mismo prólogo del libro se comenta que Jacobson le asegura que la mayor parte de las cosas que enumera Cockburn pueden ser realizadas con UML.
- El caso de uso es un contrato de comportamiento entre un actor y el sistema. Si comprendemos eso todos, mejor nos irá. Por supuesto, aquí no me refiero a los profesionales que llevan tiempo usándolos, sino a los estudiantes que se están pegando con ellos.
- La lista in/out de Rob Thomsett. Cuando hay dudas de si un elemento, tema, etc., pertenece o no al sistema -es decir, si es un requisito de este-, se construye una tabla con tres columnas: tema, in, out. Se discute si el tema está "in" el sistema o "out" del sistema. Muy simple, pero muy adecuado y útil.
- Diferenciación entre "stakeholders" y "actors".
- Niveles de Casos de Uso
- Metas de resumen, nivel nube o cometa: involucra un conjunto de casos de uso de usuario. Aunque con posibilidad de dar lugar a confusión, se puede hablar de casos de uso "estratégicos", o de proceso.
- Metas de usuario, nivel del mar: los más importantes.
- Subfunciones: submarinos

Me parece un gran acierto el cómo se responde a la pregunta: ¿cuál es el nivel adecuado para este caso de uso? Si este caso de uso responde a un "cómo", es de bajo nivel, mientras que si responde a un "por qué", pertenece a niveles más altos. Es como la diferenciación entre interfaz e implementación: uno responde al "qué", el otro al "cómo".

Otro punto muy interesante del libro es el apartado 11.2, "Fuerzas que afectan a los estilos de escritura de casos de uso", tales como, por ejemplo:
- Cultura: siempre lo hemos hecho de otra manera.
- Nivel de comprensión: acerca del dominio, del ciclo de vida, ...
- Necesidades del cliente: es técnico, le vale con una descripción de alto nivel, ...
- Experiencia vs. Formalidad.
- Cobertura
- Consistencia
- Complejidad: deseo de completitud, simplicidad de expresión, etc.
- Conflicto: la ambigüedad ayuda a esconderlo.
- ...

1/04/2004

Mi primer post en un blog. Me imagino que poco a poco iré habituándome a la jerga y demás. Mi intención es la siguiente, y el blog funcionará si soy capaz de cumplirla: dedicar una hora cada día a "leer y experimentar", de manera que siga al día en todo lo que necesito: ingeniería del software, sistemas distribuidos, nuevas tecnologías, infonomía, inteligencia emocional... todo lo que me interesa. A partir de ahí, publicar en el blog resúmenes, lo que opino, etc., de manera que se pueda generar discusión con la gente que conozca la url -en principio este blog es privado-.