bitácora de uno

Parte de las labores en el departamento de I+D en el que desarrollamos Osmius son las de decidir hacia dónde vamos.

En nuestro caso trato de plantearlo, de forma profunda y sin permitir tabúes, al menos una vez al año. La idea es no casarnos con nosotros mismos y tampoco con ninguna tecnología, o dicho de otro modo dejar que surjan dudas y luego intentar resolverlas con argumentos.

Algunas preguntas tipo que nos hacemos son:

• ¿Tenemos que cambiar profundamente alguna parte del desarrollo?
• ¿Debemos orientarnos hacia el Software como Servicio?

Pero de igual manera trato también de que nos replanteemos la tecnología que utilizamos y no sólo el roadmap de producto, aunque es verdad que en el desarrollo de software están bastante relacionados.

En una de éstas me di cuenta de que el desarrollo de la parte Web de Osmius, era lento, pesado, poco ágil y no por la gente de equipo sino porque es algo farragoso, editando 15 xmls para hacer una pantalla de mantenimiento de toda la vida y otras lindezas imperdonables. Un salto atrás en el tiempo si pensamos que con Visual Basic 3.0 ya era fácil desarrollar pantallas hace tropocientos años (unos 10, que en TI representan eones).

En éstas contacté con Álvaro y Nacho de Escuela Groovy para que primero nos convencieran razonando para utilizar Grails y Groovy y, segundo, para contratarles un curso que nos sirviera de comienzo. Finalmente hicimos el curso y estamos trabajando para aprender e incorporar la tecnología a nuestros desarrollos.

La razones de la elección se apuntan en las siguientes líneas:

El Producto: Osmius es un software de Monitorización de Sistemas y Servicios que tiene componentes:

• Procesos del “core” para monitorizar a toda velocidad y con poca carga -> C++
• Consola Web Java + Spring + Hibernate + JQuery + Spring Security con más de 50 pantallas y Web Services.
• Más 130 tablas en el Modelo de Datos.
• Metodología de trabajo Scrum

Necesidades a cubrir:

• Aunar la agilidad que ya disfrutamos en la metodología con el desarrollo.
• Peticiones de los usuarios: Más rápido, J2EE es muuuuyyyy lento.
• Actualizar a los Dinosaurios (equipo C++) y a los Cromagnones (equipo Java)

Grails y Groovy porque:

• La sintaxis de groovy no es extraña para Dinosaurios ni Cromañones.
• Podemos integrar Scripts de groovy en la monitorización (cuando el rendimiento salvaje no sea un problema).
• Reutilizamos conocimiento de Cromagnones: Spring, Hibernate, etc.
• El rendimiento no nos preocupa porque el core es C++ y tenemos muy optimizadas las sentencias a BBDD.

Curiosidades:

• Cromagnones: Están encantados, sobretodo con no tener que tocar quince XMLS cada vez.
• Dinosaurios: Están horrorizados. “El desarrollo Web es un infierno” (Vienen de Visual Basic: Arrastro control, click, código).

Ahora estamos dos del equipo en el evento sobre Spring y Grails en Madrid 2010: Spring2GXDay

El año que viene volveremos a ponernos en duda. Ya os contaré. ¿Roo, quizás? (No creo)

Hace ya años que empezamos a seguir la metodología Scrum en el equipo de desarrollo que coordino para hacer Osmius, un producto complicado de desarrollar desde el punto de vista de ingeniería, y con el objetivo de ser fácil de entender y de utilizar por el usuario.

Como dice Medinilla, Scrum no es la bala de plata, no soluciona problemas ajenos a la metodología, pero es cierto que en un equipo de gente medianamente responsable y motivada, debe servir para dos cosas:

• Mejorar la eficiciencia individual; y por tanto la del equipo
• Mejorar la visibilidad de lo que se hace: A los demás y a nosotros mismos

En mi caso, que me gusta construir, además y gracias a lo anterior se mejora la experiencia; disfruto más vaya.

Es por todo esto, que cada vez pienso más que podría crearse una empresa cuyos procesos de negocio - la producción, la operación, el marketing, la gestión del conocimiento, la gestión de los recursos, el community management, y el sursum corda - puedan gestionarse de igual manera con metodologías ágiles. La empresa Scrum que se diría.

Para que no me consideréis naive tan pronto, o no tanto, también es verdad que pienso que estas prácticas no son para todas las empresas o para todos los equipos o para todas las personas, pero sus razones habrá, pues está claro que la productividad aumenta cumplidos unos requisitos.

Bajando de las ramas y para quien esté interesado Ángel Medinilla ha vuelto a poner gratinos al montón de lo Ágil traduciendo junto a otros, el texto “Kanban vs Scrum”.

Ahora Kniberg ha sacado un nuevo trabajo comparando Scrum con una aproximación nueva que se está realizando a los procesos de desarrollo: Kanban. Kanban no es nuevo para nada, surge como todas estas herramientas y disciplinas en el seno del sistema de producción de Toyota, “la máquina que cambió el mundo”.

Más | Kanban vs Scrum en castellano en Presión Blogosférica

Curiosamente navegando por sitios web dedicados al diseño gráfico he llegado a “La filosofía Unix y el diseño” en el que se enumeran 17 reglas que no tienen desperdicio.

Os copio las 5 primeras que dejan claro como el agua cómo hacer determinadas cosas:

• Regla de Modularidad: Escribe partes simples, conectadas por interfaces simples.
• Regla de Claridad: ser Claro es mejor que ser ingenioso.
• Regla de Composición: Diseña programas para que se conecten a otros programas.
• Regla de Separación: Separa las reglas del funcionamiento; separa los interfaces de los mecanismos.
• Regla de Simplicidad: Diseña para la simplicidad; añade complejidad sólo donde sea estrictamente necesario.

¡Si es que está todo inventado !

Vía | Ale Muñoz de Sofá Naranja en “La filosofía Unix y el diseño”

Me reservo el derecho a romper estas reglas y cuantas me cruce si la ocasión lo requiere. Si quieres pido vez y te lo reservo también a ti.

Siempre he sido un defensor de la regla 80-20 que en el fondo no es regla sino concepto.

Para quien no se haya tropezado ya con ella, una forma de expresarla aplicándola a un producto software, cambie el lector el objeto a su antojo, sería que de todas las funcionalidades o características deseables del producto hay un 80% que le van a dar el máximo de amplitud, de clientes, de usuarios, y que el 20% restante te va a añadir pocos usuarios y que sin embargo el esfuerzo en implementarlo es mucho mayor.

Basándonos en esta regla, en el equipo de Desarrollo que coordino, priorizamos las funcionalidades más básicas y sencillas sobre las más específicas y complicadas. Así y a lo largo de los años, conseguimos un producto: Sencillo y Evolutivo.

Esto, en un proyecto complejo, no es ni bueno ni malo: Es necesidad.
Hay tanto que hacer que de esta forma evitas perderte en marasmos y haber echado medio año del trabajo del equipo en no sé qué característica que añadida.

Osea, una vez que tenemos las funcionalidades básicas, bien implementadas, con una buena ingeniería de componentes, usable y extendible, evitamos la especialización cuando es dolorosa y larga de desarrollar.

Además, en el caso de Osmius, estamos hablando de Software Libre, y esto quiere decir que tu modelo de negocio se basa en servicios, uno de los cuales es precisamente desarrollarle a alguien esa funcionalidad “Tipo 20%” de forma remunerada. Tienes una base, ese 80% o una parte de él, libre y dejas las personalizaciones o las tareas complicadas para quien las pague. Es un asunto de retorno de la inversión o de optimización del esfuerzo, que viene a ser lo mismo.

El problema es cuando se convierte uno en un Ochentacentista para todo. La regla anterior está bien, pero en ese 20% final está la diferencia entre la mediocridad y la excelencia, y cada una de ellas tiene su momento.

En el caso anterior queda claro que la mediocridad tiene su momento y su utilidad. Nos ha permitido priorizar y crecer de forma que mejoremos las posibilidades de éxito del proyecto, pero no podemos mantenernos en la misma línea en otros casos.

Rafael Nadal no deja de ir a por el 20% de las bolas en un partido de tenis. Va a por todas, busca el 99% de efectividad. Por eso es un top10.
Creo que de igual forma hay que comportarte ante otras situaciones como el desarrollo personalizado a un cliente, la preparación de una charla de venta importante sobre el producto, la redacción de una oferta o el soporte a alguien que tiene un problema.

Ahí no quieres ser mediocre, o yo no quiero o no me parece buena política para ser sostenible, rentable; no quiero dar un soporte al 80%, ahí no quiero ser del montón porque ser diferente es lo que vendo, pero igual que lo venden los demás. Qué comercial no dice de su producto X que los profesionales son los mejores, que si bli, que si bla.

Resumiendo: La regla 80-20 está muy bien, pero hay momentos y situaciones en que puede ser contraproducente, puede coartar buenas ideas y puede ser un impedimento para hacer algo realmente bien y que además sea lo que marca la diferencia en entornos competitivos en los que a menudo nos encontramos.

Detonante | Why the 80 20 rule is wrong
Detonante | For CIOs: 2010 will require new emphases on customers, revenue, external information, and a passion for rapid change

Foto tomada por Uno en el Santa Cruz de Isla de la Palma (ya les he enviado el CV)

Vamos a presentar los resultados del trabajo conjunto del último año entre la Facultad de Informática de Universidad Complutense de Madrid y el Departamento de I+D de Peopleware.

En este caso se trata de aplicar la predicción de tendencias y el reconocimiento de patrones a los elementos monitorizados por Osmius para responder a preguntas como:

• ¿Qué elementos de entre todos los monitorizados tienden a tener problemas a la vez?
• ¿Qué es más probable que se caiga en las próximas dos horas en función del histórico de datos de Osmius?
• ¿Hace el sistema lo que tiene que hacer? (Validación formal)

El título en inglés del artículo con la discusión y los resultados del trabajo es:

Trend prediction in network monitoring systems:
performing sequential pattern mining in Osmius
monitoring tool

Lugar:
Facultad de Informática - Aula 6
Universidad Complutense de Madrid

Cuándo:
Jueves 15 de octubre
11:00 AM

Estáis tod@s invitad@s
En breve pondremos por aquí el artículo completo.

Si tienes que trabajar con matrices grandes y te basta con valores de 0 ó 1 lo suyo es usar bits.

Es más rápido y sobretodo ocupa muchísimo menos.
En un programa para procesar textos sobre Biomedicina ni siquiera podía crear el array con short ints porque me daba un “core”.

La idea es ésta:

#define BITMASK(b) (1 < < ((b) % CHAR_BIT))
#define BITSLOT(b) ((b) / CHAR_BIT)
#define BITSET(a, b) ((a)[BITSLOT(b)] |= BITMASK(b))
#define BITCLEAR(a, b) ((a)[BITSLOT(b)] &= ~BITMASK(b))
#define BITTEST(a, b) ((a)[BITSLOT(b)] & BITMASK(b))
#define BITNSLOTS(nb) ((nb + CHAR_BIT - 1) / CHAR_BIT)
char miArray[BITNSLOTS(1024*1024)]; // De 1024*1024 posiciones.
memset(miArray, 0, BITNSLOTS(1024*1024)); // Todo a 0
BITSET(miArray, 100); // Un 1 en la posicion 100.
mybool = BITTEST(bitarray, 200); // Leer la posicion 200.


Via | comp.lang.c FAQ list · Question 20.8

El aprendizaje por refuerzo permite que un agente, un ente, que se relaciona con un entorno mediante sensores y actuando en él a través de ciertas acciones, aprenda qué acción es la más adecuada en cada momento para conseguir unos objetivos basándose en unas recompensas o castigos que va recibiendo con cada acción ejecutada.

Por ejemplo, puedo escribir un programa que aprenda a jugar a las damas sin escribir en reglas los algoritmos ganadores.
Otro ejemplo: Escribo un bot para que luche con otros en Quake pero no programo ninguna línea que diga “Si ves un robot a menos de 3 metros, dispara”.

La idea es interesante y de aplicaciones infinitas.

Por eso escribí un algoritmo que implementa el aprendizaje por refuerzo basado en tablas-Q y el algoritmo de Sutton y Barto, lo utilicé para que un bot - al que llamé ReBoTe - aprendiera a zurrales la badana a otros en el juego libre y sencillo RealTimeBattle, y por fin, este lunes presenté trabajo y resultados de la última asignatura del máster de investigación (no confundir con Máster del de MBA) que estoy haciendo en la Universidad Complutense.

El agente aprende que en cada estado S la mejor acción es A a través de las recompensas o castigos que va recibiendo.

Una de las ideas que tengo en mente es la de hacer un operador de monitorización automático.

Saber cuál es el estado del entorno (osea los servidores o las bases de datos o lo que sea) es fácil, las recompensas son positivas si mejora el estado hacia menos cŕitico y las acciones pueden estar programadas para no ser muy dañinas en principio (rearrancar servicio, enviar correo al administrador, borrar ficheros del directorio temporal del servidor con problemas). Además, con esto en mente, el código que hice para el robot lo he preparado para ser usado como un componente.

Si alguien está interesado: jlmarina [arrobón] gmail [.puntaco] CoM.

El artículo completo del trabajo: Aprendizaje por Refuerzo: Aplicado a luchas de robots en RealTimeBattle.

Por cierto que depués de 1000 partidas de entrenamiento ReBoTe está con el ego subidísmo: gana en un 70% de las veces.

Vuelvo a las andadas y poco aporto a la colección de dichos y proverbios que ha recolectado, quién sabe desde cuando, Tom Van Vleck.

Verlos, o mejor dicho leerlos, me ha gustado por cosas como ésta:

Desarrollando un software elige dos de: Bueno, Rápido o Barato.

Wexelblat

Para ir más rápido reduce la velocidad. Cualquiera que sepa de mecánica orbital lo entiende perfectamente.

Scott Cherf

Primero diseñas… y luego codificas.

Anónimo (pero didáctico)

Si encuentras tres errores en un programa, la mejor de las estimaciones es que hay otros tres.

Anónimo (pero cabrón)

Hacerlo lo mejor que puedas no es suficiente. Primero tienes que saber qué es lo que hay que hacer y ahora ya puedes hacerlo lo mejor que puedas

Anónimo (pero rompecocos)

Via | Recopilación de Proverbios de Tom Van Vleck.

Hace más de un año escribí lo que es para mi hacer software y cómo explicárselo a tu peluquera.

Creo que sigo de acuerdo con aquello en las ideas centrales, aunque algunos conceptos han evolucionado o cambiado. Por ejemplo ahora estoy lo suficientemente calvo como para tirar de máquina y no ver mucho a peluqueras.

Alberto Martín, me pasa un enlace a frases famosas de programadores de las cuales me quedo con una de un tal Linus Torvalds.

Nadie debe empezar un proyecto grande.
Empiezas con uno pequeño y trivial y nunca debes esperar que crezca; si lo haces solamente sobre-diseñarás y generalmente pensarás que es más importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamaño de lo que tu esperas que crezca.
Así que empieza pequeño y piensa en los detalles. No pienses acerca de la foto grande y el diseño elegante. Si no resuelve una necesidad inmediata, seguramente está sobre-diseñado. Y no esperes que la gente salte a ayudarte, no es así como estas cosas funcionan.
Primero debes tener algo medianamente usable y otros dirán “hey, esto casi funciona para mí” y se involucrarán en el proyecto.

Hombre “nadie” me parece demasiada restricción, pero sí que estoy convencido de que salen mejor los proyectos pensándolos sencillos desde un principio. La complejidad en un proyecto grande es inherente a él, así que mejor que ayudes en ese sentido.

Mejor pensarlo todo sencillo, incluso renunciando a funcionalidad, e independiente.

Más de una vez hemos comentado que pará qué hemos parametrizado tal parte del código, si nadie la va a utilizar (¿nadie = 1%?) y haberlo hecho a pelo pero clarito nos hubiera llevado la décima parte del tiempo. Además hay veces en que tocar unas líneas en un código clarito es más fácil que retocar un componente supermega reutilizable.

Que lo mejor no sea enemigo de lo bueno. Feliz 2009.

Via | Alberto
Foto | http://www.sxc.hu