sábado, 14 de septiembre de 2019

Como señalar los fallos

Durante el desarrollo del software, los programadores van cometiendo pequeños errores y grandes errores. Unos pueden ser grandes meteduras de pata y otras pequeñas tonterias pero todas van sumando fallos que hay que solucionar y que penalizan las entregas. Esto es asi y se debe tener en cuenta como riesgo en la planificacion del proyecto. Pero existe otro gran problema, los programadores normalmente no son conscientes de estos fallos y cuando llega la hora de las entregas y no se llega o la calidad del software no es buena entonces aparecen los enfados y frases como:

  • Era imposible llegar.
  • Como puede ser? yo le hecho todo bien.

Para solucionar este problema se debe:
  • Tiene que haber un supervisor, jefe, integrador, etc... que detecte estos fallos y los ponga de manifiesto.
  • Se le debe comunicar al equipo de forma adecuada.
En este ultimo punto quiero incidir, Cual es la forma correcta de comunicar los fallos? 

  • Si se hace de forma continua e inmediata (cuando se detecta el fallo enseguida se indica) entonces geneneras en el programador las ganas de "devolvertela" (estara deseando que el supervisor se equivoque para echarselo en cara).
  • Si se hace de forma aislada entonces pierdes el poder que da estar hablando en grupo y dejas que el programador se pueda "picar" e intentar defenderse con unñas y dientes aunque no tenga razon.
La forma correcta es tener una rutina de reuniones (una a la semana) donde el supervisor hable de asuntos tecnicos y cuando lo vea oportuno indicar  cosas como:

  • Esta ultima entrega ha ido mal y yo creo que...
  • Las metricas de calidad han bajador debido a...
  • Normalmente usamos "esto" en el codigo y deberiamos usar "esto otro" 

viernes, 23 de agosto de 2019

Miedo a la integración


En muchas ocasiones, y sobre todo cuando el proyecto alcanza un tamaño grande, ante un nuevo desarrollo/solventar incidencia se implementa una parte completamente nueva aun sabiendo que ya hay una parte implementada que deberia ser modificada/ampliada para solucionar dicho desarrollo/incidencia. Esta situación pasa porque: 
  • El programador quiere “ahorrase” el tener que conocer una lógica compleja.  
  • No se han proporcionado las herramientas necesarias para adquirir el conocimiento de la parte a modificar/ampliar y la tarea se hace demasiado pesada. 

Este “miedo” tambien afecta a la parte funcional ya que en muchos casos se recurre a “Comentarios”, “Anexos”, etc.. En lugar de modificar el documento donde se indique la parte a modificar/ampliar. 

La única solución a este problema es identificar la necesidad de la redefinición y que es una tarea que debe ser teniada en cuenta en las planificaciones. No se debe considerar la redefinición/ampliación como un error. Habrá casos donde la redefinición/ampliación sera un fallo ya que no hacia falta pero en otros casos no seria un fallo y es parte del desarrollo del software. 

domingo, 11 de agosto de 2019

Problemas para dividir el trabajo

Cuando se piensa en la informática,  y en concreto en la programacion, lo primero que se piensa es que el programador está en cualquier sitio del mundo. Nada más alejado de la realidad, al programador se le quiere al lado del negocio y si se piensa en tener al programador alejado es por temas laborales( por conciliación familiar, teletrabajo, etc...).

Por qué se necesita al programador al lado del negocio? Los principales motivos son:

- No hay una figura de comprobador/integrador técnico que asegure que lo que hacen los programadores sea correcto. Este tarea se delega en el grupo de programadores.

- El negocio requiere continuos cambios y definición on-fly( en el momento) y tiene que aclararlo en persona.

A lo largo de la historia reciente de los productos que han revolucionado la informatico y/o el mundo ( Facebook, WhatsApp, wifi, Etc..) se  puede llegar a la conclusión de que todos eran grandes soluciones que caían por su propio peso y no eran grandes soluciones por lo complejo de su implementación. Este problema es lo mismo, lo único que se necesita es dar con la idea feliz que permita tener programadores en cualquier parte del mundo de manera eficaz.

domingo, 4 de agosto de 2019

No querer ver la realidad

Cuando se planifica con tiempo el desarrollo de un software y se mira hacia la implementación se pretende hacer de forma correcta y se crea el perfil de arquitecto de software pretendiendo que diseñe el software y lo haga tan bien que implementarlo sería solo la parte fácil.

Nada más lejos de la realidad. Puede que en un futuro este planteamiento sea una realidad pero ahora no lo es y nunca ha sido una realidad por mucho que nos empeñemos en no querer la realidad.

El no querer ver la realidad siempre es lo mismo. Todo el mundo ha estado en un proyecto donde se dice: este proyecto no ha quedado bien, al siguiente lo haremos mejor. Al siguiente se hace de forma distinta pero el resultado es más o menos el mismo y ya se empieza a decir: la culpa es de esta otra persona por esto o por lo otro.

Rindamonos a lo evidente. Al menos hasta que cambien las cosas y se establezcan métodos claros y que todos sigan para que la implementación sea lo más sencillo. Es cierto que se necesita un arquitecto de software pero el arquitecto también programa, se moja las manos y resuelve problemas de bajo nivel. Si hace este tipo de tareas entonces se ganará la confianza del grupo de desarrollo y del grupo de gerencia. Con esta piedra angular el desarrollo irá por buen camino.

jueves, 13 de junio de 2019

Una aplicación informática es una aplicación informática.

Se me ha ocurrido usar una técnica de autoayuda/formación de equipo que consiste en repetir mucho algo muy obvio pero que se nota que tenemos en cuenta porque al ser tan obvio nos centramos en otras cosas de tal manera que puede hacer que no hagamos la parte obvia. Por ejemplo, nos encomiendan hacer una casa y podemos pensar "bueno si voy a hacer una casa empecemos por algo sencillo, voy a comprar la tele" o otra como "pongo las puertas", etc.. cosas asi. Pero cuando pasa el tiempo y comprobamos lo que tenemos nos damos cuenta que "no se me ocurrio empezar por las paredes" y cuando se supone que tenemos que entregar la casa tenemos un monton de "cosas de la casa sueltas" pero no tenemos paredes.

Yo creo que si esto le ha pasado a alguien a alguna vez lo que penso al ver el fracaso es "¿por que no empece por las paredes?".

Cuando estas haciendo una aplicación informática pasa lo mismo, una aplicación informática no es un conjunto de funcionalidades que puedes implementar y luego ver como las juntas, no es un conjunto de historias de usuario que debemos cumplir, etc.. Claro que la aplicación informática debe dar solución a todo eso pero no olvides que una aplicación informatica es un conjunto de interfaces que acceden a una logica. Empieza por las interfaces. La casa debe tener una tele pero primero mejor ponle paredes. 

domingo, 26 de mayo de 2019

Supervisor técnico

En los proyectos actuales siempre veo roles que se repiten: jefe de proyecto, funcionales, técnicos, arquitectos y programadores. Con las técnicas de gestión ágiles aparece el product owner, el scrum master y el cliente (este ultimo nunca forma parte del equipo). Me falta alguien que creo que es vital para la culminación de un proyecto de desarrollo de software, el supervisor tecnico. Esta figura es el encargado de:


  • Diseño técnico.
  • Que los programadores sigan las especificaciones técnicas y los estilos de programación.
  • Ser el validador de que lo implementado es lo que realmente se ha indicado en los funcionales.

sábado, 20 de abril de 2019

Kafka con Spring Boot. Topicos y Colas.

Kafka es un gran framework que se usa para comunicación entre aplicaciones. El objetivo de este artículo no es estudiar las características de Kafka ni de Spring boot, para eso hay mucha documentación en las paginas web de cada framework. El objetivo de este articulo es explicar una forma sencilla de montar Kafka, de como usarlo para comunicar aplicaciones Spring boot, como realizar una comunicación por tópicos (es decir todos los consumidores escuchan el mensaje) y realizar comunicación por colas (es decir solo un consumidor escucha el mensaje) para los programadores que están acostumbrados a otros frameworks como ActiveMQ o RabbitMQ.

Kafka no funciona de la misma manera que los framework mas comunes(ActiveMQ o RabbitMQ) por lo que no hay una forma directa de hacer lo mismo pero en este artículo voy a describir como aplicar comportamientos equivalentes.


Para comprender correctamente este articulo necesitas tener conocimientos básicos de Docker y Spring boot.

La forma mas sencilla de montar un "servidor" de Kafka es usar Docker, se puede usar el siguiente fichero de docker-compose:


docker-compose.yml 

version: '3'
services:
  zookeeper:
    image: wurstmeister/zookeeper
    ports:
      - "2181:2181"
    hostname: zookeeper
  kafka:
    image: wurstmeister/kafka
    command: [start-kafka.sh]
    ports:
      - "9092:9092"
    hostname: kafka
    environment:
      KAFKA_ADVERTISED_HOST_NAME: localhost
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_PORT: 9092
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - "zookeeper"



Una vez ejecutado este fichero, ya esta disponible Kafka en el puerto 9092.

El código del productor de mensajes y de consumidor de mensajes esta en https://github.com/rumberomelo/productor-consumidor-basico

Si descargas el código y lo ejecutas (y has arrancado Kafka como indico al principio) puedes comprobar el funcionamiento mas sencillo, un productor que escribe un mensaje de texto que lee un unico consumidor. Para hacer funcionar el ejemplo solo tienes que hacer la siguiente petición:

http://localhost:9000/envia/mensaje?texto=hola

Esta petición hará que el productor escriba en el tópico de Kafka "TOPIC_EJEMPLO" el mensaje "hola". Puedes comprobar en el log del consumidor que lo ha leido ya que aparecera un mensaje como INFO 47114 --- [ntainer#0-0-C-1] com.rumberomelo.kafka.consumer.Consumer  : Se ha consumido el mensaje hola.

Este ejemplo muestra como un consumidor lee un mensaje que produce un productor. Si lanzaramos un consumidor exactamente igual pueden pasar dos cosas (depende de como se configure Kafka):

  • El nuevo consumidor es el unico que lee todos los mensajes de productor.
  • El nuevo consumidor siempre queda a la espera (nunca lee ningun mensaje) y el viejo consumidor lee todos los mensajes.
Esto se puede comprobar en el ejemplo https://github.com/rumberomelo/productor-dos-consumidores y ver que solo un consumidor lee el mensaje. Si aplicamos un pequeño cambio y cambiamos el nombre de los grupos de cada uno de los consumidores como indican estos dibujos:





Al arrancar de nuevo los ejemplos se puede comprobar como los dos consumidores reciben en mensaje mirando el log de los consumidores. Este comportamiento es igual al tópico de frameworks como RabbitMQ o ActiveMQ.

Volvemos a dejar el nombre de los grupos como estaba. ¿Como se hace para que un mensaje lo lea uno de los consumidores (no siempre el mismo)? Se hace indicando las particiones en las que se quiere dividir el tópico. Cuando un productor escribe en un tópico que no existe (que es lo que se ha hecho al principio de este articulo) se crea automáticamente sin particiones, si tienes varias particiones entonces los consumidores se reparten dichas particiones de tal manera que cada consumidor solo lee de una de las particiones asignadas y como un mensaje se puede colocar aleatoriamente en cualquier particiones ya se ha logrado que sea un consumidor cualquiera el que lea el mensaje.

Para probarlo, se debe entrar en el contenedor de Kafka:


$ docker exec -it articulokafta_kafka_1 bash

Se puede comprobar que no hay particiones:


$ kafka-topics.sh --describe --zookeeper zookeeper:2181 --topic TOPIC_EJEMPLO

Topic:TOPIC_EJEMPLO PartitionCount:1 ReplicationFactor:1 Configs:
Topic: TOPIC_EJEMPLO Partition: 0 Leader: 1001 Replicas: 1001 Isr: 1001

Se añaden dos particiones:


$ kafka-topics.sh --alter --zookeeper zookeeper:2181 --topic TOPIC_EJEMPLO --partitions 2


Al arrancar de nuevo el ejemplo https://github.com/rumberomelo/productor-dos-consumidores y dejar el nombre de los grupos como estaban originalmente, si se hace la prueba de lanzar varios mensajes entonces se puede comprobar como a veces los lee un consumidor y a veces otro.