Reseña libro Clean Code

Hoy os traigo una revisión de un libro sobre programación. No tanto sobre un lenguaje sino sobre la programación en general, buenas prácticas. El libro se llama Clean Code.

Creo que es un libro que todo programador debiera de leer.

Os dejo el vídeo

Espero que os guste

Como acelerar el arranque de una persona en un nuevo proyecto

En esta ocasión quería comentar una herramienta para configurar y distribuir servidores. Concretamente la herramienta se llama Docker

Para ver qué es lo que nos puede aportar Docker vamos a plantear una problemática muy común en las empresas de desarrollo.

Llega una nueva persona al equipo del proyecto y… ¿ cual es una de las primeras cosas que suele tener que hacer ?,… efectivamente, ponerse el entorno.

En muchos sitios este trámite consiste en que algún compañero le haga un zip de su servidor y de su herramienta de desarrollo y se lo pase.

El compañerismo está muy bien, pero esta forma de proceder no es la más adecuada, porque se acaba arrastrando mucha porquería, ya que no es un entorno limpio.

Sin contar que tampoco suele haber ningún mecanismo para tener actualizado el entorno. Así que cuando se libera una nueva versión de alguna librería o del servidor toca actualizarse manualmente.

Y aquí entramos en:

– personas que no lo hacen porque tienen que entregar algo sin falta y van apurados.
– o personas que al seguir el manual de como actualizar se equivocan.
– o simplemente personas que tiene montado el entorno a su manera.

Total que con esta forma de proceder el tener un entorno actualizado es casi una quimera o de conseguirse el coste es muy alto. Y estas operaciones se repiten bastante a menudo dentro de un proyecto un poco grande y largo.

Pero hay soluciones, una de las que más auge está tomando últimamente es Docker.

Tengo un ejemplo muy simple, en youtube, que consiste en un servidor WildFly, que es la versión de la comunidad del JBoss, con un módulo instalado para obtener métricas de la ejecución de nuestra aplicación, que viene a simular las librerías específicas de un proyecto y una aplicación muy sencilla de ejemplo.

Las herramientas que se usan en este vídeo son las siguientes:
– Docker versión 1.9
– Docker Hub
– JBoss Developer Studio 9.0.0
– WildFly 9.0.2
– Dropwizard metrics

Espero que os sirva de ayuda, y no dudes en dar a like y compartirlo.

Innovación

A los profesionales con inquietudes nos suele gustar innovar en nuestro trabajo, pero cuando trabajas para terceros no siempre es fácil. Debemos tener muy presente que toda mejora supone un cambio, pero no todo cambio supone una mejora. Lo importante de la innovación es aportar valor al cliente. 

Cuando te encuentras trabajando para una organización que ya tiene establecidas sus herramientas y metodologías es complicado poder innovar, porque si quieres hacerlo sobre algún área ya definida por la organización vas a tener que proponer algo que realmente les aporte una sustancial mejora, ya que sino acabamos cambiando y no mejorando. Y no es fácil salvo que te encuentres trabajando para una organización con planteamientos y herramientas obsoletas.

Para matar el gusanillo suele ser más útil el buscar algún reducto donde la organización no se haya desarrollado. De esta forma con no mucho trabajo puedes conseguir proporcionar mucho valor al cliente. Es una tarea no precisamente fácil, sobre todo cuanto más organizada y moderna sea la organización, ya que tendrá cubiertos las principales áreas. 

Curriculum vs. pasión

Últimamente está muy de moda dentro del agilismo y todas estas prácticas de emprendimiento el recalcar la importancia del la pasión en el trabajo y que el currículum hoy día tiene poca validez, ya que es una herramienta 1.0 del siglo pasado.

A veces hay conceptos que cuesta un poco asimilar y aunque puedes entender que efectivamente es importante la pasión en el trabajo, no es tan fácil entender porque un currículum no es algo tan válido hoy día. Pero últimamente se han dado una serie de circunstancias que me han hecho entender cual es esa diferencia.

Yo, por ejemplo, (y no tiene nada que ver con esas circunstancias que he comentado) en mi currículum puedo poner que he dado formación y es cierto, y no lo hacía mal del todo. Pero es algo que siempre he intentado evitar, porque no me gusta. Es lo que tiene el curriculum que o mientes quitando cosas o si realmente lo que estás diciendo es la realidad, es como su nombre indica, el discurrir de la vida y yo efectivamente… he sido profesor.

Pero por ejemplo sí vemos el blog, este blog que estás leyendo, podrás darte cuenta de que cosas son las que me interesan, porque nadie me obliga a escribir lo que escribo, simplemente escribo lo que me apasiona o lo que me molesta.

Para mi esa es la validez que tiene este blog, es una forma de expresar claramente qué cosas son las que me apasionan y que cosas no. No quiere decir que todo de lo que no escriba aquí lo aborrezca hay cosas que simplemente no tengo tiempo para abordarlas y otras que si que efectivamente pues ni si ni no, las he hecho porque tocaba hacerlas.

Ampliando horizontes en YouTube

Hoy toca hablar de novedades en este blog, ya que recientemente he iniciado una serie de videotutoriales en mi canal de YouTube .

Desde hace tiempo he sido partidario de utilizar toda la tecnología que tenemos a nuestra mano y de forma accesible para mejorar en nuestra profesión, y uno de los puntos que siempre me ha parecido que tiene mucho margen de mejora es la parte de enseñar a la gente que se va incorporando a la empresa o proyecto.

Cada vez que entra alguien, sobre todo en proyectos grandes con mucha gente hay que andar repitiendo las mismas explicaciones, porque al final todo el mundo tiene básicamente las mismas dudas. Y ahi el hecho de hacer pequeñas grabaciones en plan screencast pueden ser muy útiles.

Así que me he animado a grabar algunas cosas, sobre todo pequeños tutoriales o trucos y además lo he realizado en nuestro idioma, ya que he visto que no hay mucho material en nuestro idioma.

Son grabaciones caseras, en las que la única inversión ha sido un micrófono un poco más profesional que el de la webcam, para que se oiga mejor. Es un micrófono chulísimo y que recoge muy bien la voz.

Espero que os guste y no dudéis en suscribiros al canal de youtube o darle a la manita para arriba si os gustan los videos.

Nuestro rol como clientes y proveedores y sus paradojas

En la vida de cada uno de nosotros en la mayor parte de las situaciones somos consumidores de productos o servicios. Compramos cosas, como ropa, electrónica, etc, o bien contratamos servicios, como por ejemplo la línea telefónica.

Y normalmente somos exigentes con las compañías que nos prestan estos servicios. Es lo normal, pagamos por un producto y servicio y queremos que nos lo presten correctamente. A nadie le gusta quedarse sin cobertura en el teléfono, o que no le funcione el terminal, o que el medico no le diagnostique bien, o un largo etcetera.

A veces lo que nos ocurre como trabajadores es que no nos damos cuenta que en ese momento nosotros somos los prestadores del servicio. Y lógicamente nuestros clientes van a tener un nivel de exigencia similar al que nosotros tendríamos si fuésemos los clientes. Y se nos suele olvidar.

¿Que pensaríamos si estamos reformando la cocina de nuestra casa y el albañil cuando llega la fecha de entrega nos dice que va a tardar más? Lógicamente lo más probable es que no nos parezca bien, no vamos a disponer de nuestra cocina, con el trastorno que nos supone, y encima nos va a costar más, porque obviamente el albañil no va trabajar gratis.

Pero me he encontrado con casos en este sector de la informática en los que gente del equipo se permite plantear que se le pida más tiempo al cliente. Y lo más curioso es que luego cuando las cosas van mal y el cliente te echa se extrañan.

Pero ¿alguien mantendría o volvería a contratar al albañil que obviamente está siendo incapaz de llevar la reforma de la cocina a cabo?.

Cambiando tu organización (para peones)

El otro día encontré, en esa fuente inagotable de conocimiento que es el blog de Javier Garzás una entrada con la que me siento totalmente identificado.

Habla de una persona que entró en una empresa como programador y sus intentos de cambiarla de un modelo en cascada a un modelo ágil.

No tiene desperdicio y da recomendaciones que subscribo totalmente, sobre todo la primera parte en la que habla de lo difícil que es. De esto puedo dar fe, no ya para alguien que entra en la organización sin ese cometido, sino incluso cuando entras con el, como me ha pasado a mi.

Las resistencias puede llegar a ser Numantinas, incluso en sitios en los que los problemas son más que evidentes y de una magnitud muy considerable.

En resumen una lectura corta y muy recomendable para todo aquel que quiera cambiar la forma de trabajo de su organización, independientemente de que sea un peón o no.

Autogestión y planning poker

En la entrada anterior comentaba sobre los equipos autogestionados que propugna scrum y la dificultad de pasar de un equipo gestionado de forma tradicional a un equipo autogestionado.

Hay una forma que, aunque reconozco que nunca he tenido la oportunidad de poner en práctica, me parece muy indicada para conseguir que el equipo avance en la autogestión. Me refiero al Planning Poker.

El motivo es que el planning poker implica que todo el equipo debe estimar las tareas. Esto obliga a que cada integrante del equipo se implique y entienda cada tarea por lo menos de una forma básica. En el manifiesto de Extremme Programming Kent Beck comentaba que la mayor parte de los problemas en un proyecto provenían de alguien que no había contado algo a otro.

Con las técnicas de estimación tradicionales en las que el jefe estima, el equipo no va a poder desarrollar esa faceta, así que nunca va a aprender a tomar decisiones y luego apechugar con las consecuencias. Así que tendrá difícil poder autogestionarse algún día.

Otras veces en un movimiento hacia la autogestión cada integrante del equipo estima las tareas que va a realizar, con lo que se pierde la oportunidad de que el resto del equipo las interiorice, total no lo tengo que hacer yo así que desconecto y no presto atención.

No creo que el planning poker sea infalible, porque hay cierto tipo de personas que niegan la realidad y ellos siempre tienen razón y no se equivocan. Pero este tipo de gente es tóxica, así que mejor desprenderse de ella cuanto antes, y que el resto del equipo esté involucrado no es una mala forma de hacerlo.

¿Está tu equipo preparado para autogestionarse?

En scrum se propugnan los equipos autogestionados. Pero la pregunta es ¿Está tu equipo preparado para autogestionarse?

Aunque suene muy interesante la autogestión de un equipo hay ciertas dificultades para llevarlo a cabo. Normalmente los equipos, y consiguientemente los integrantes del equipo, están acostumbrados a tener un jefe que les indique lo que tienen que realizar.

Prescindir de esa figura que se encarga de gestionar el equipo puede ser traumático, por varios motivos.

Cuando los integrantes del equipo están acostumbrados a que alguien se encargue de la gestión, normalmente no se preocupan de como se gestiona, que cosas hay que tener en cuenta, que criterios hay que seguir para priorizar tareas, o para asignarlas, etc.

Así que se corre el riesgo de que cuando el equipo se autogestiona cometa muchos errores por inexperiencia.

Hay que tener en cuenta que aunque el equipo se autogestione eso no implica que todo el mundo se vuelva un experto en todas las materias. Hay que conocer los límites de cada uno y no decir o proponer cosas que luego se comprueben que no son adecuadas, ya que es contraproducente a nivel personal. Si en el equipo, por ejemplo, hay un experto en la funcionalidad del aplicativo, cuando se traten temas de funcionalidad hay que tener muy en cuenta su opinión.

La autogestión no significa tampoco la anarquía o el barra libre. Los acuerdos a los que se llegue dentro del equipo hay que respetarlos, independientemente de que nos parezcan adecuados o no. Los informáticos desgraciadamente somos muy dados a ir por libre, pero es completamente contraproducente, sobre todo porque si el equipo demuestra que no es capaz de autogestionarse, tarde o temprano les acabarán volviendo a poner a un gestor.

No sería el primer equipo que veo autogestionarse hacia el fracaso.

Tengo todos los ingredientes y esto no funciona…

Algunas veces me ha venido a la cabeza la imagen que Kent Beck describe en su libro sobre la programación Extrema.

Describe los elementos que propugna como un cuadro de mandos en el que pone todos los mandos al máximo y el sistema es estable. También explica como unos con otros se compensan para hacer que el sistema sea así de estable.

A veces me encuentro en sitios en los que pese a tener todos o muchas de las herramientas de hoy día las cosas no funcionan bien. Puedes instalarte en un periquete un git y tener control de versiones, un Jenkins y tener una integración continua, un sonar y tener un cuadro de mando de deuda técnica, etc, pero no hacer que el sistema funcione.

De hecho es complicado hacer que funcione, porque tener las herramientas no asegura que el equipo las use, y si no están configuradas con un planteamiento adecuado, es probable que no les sean útiles, con lo que se hundirán como un barco con una gran vía de agua. Y reflotar algo que se ha ido a pique es complicado.

Alguna reflexión ya he dejado previamente.