Hace unos meses terminé el libro “Seven Languages In Seven Weeks” de Pragmatic Bookself. Fue una temporada bastante entretenida y muy enriquecedora para mi faceta de programador. Aquí va mi resumen.

El libro nos ofrece un aprendizaje relámpago por cada uno de los 7 lenguajes que trata, Ruby, IO, Prolog, Scala, Erlang, Clojure y Haskell. Pero aunque diga relámpago, no quiero decir que este aprendizaje sea pasándolos por encima y enseñándonos lo mismo que la típica presentación o curso introductorio. De hecho el autor no bromea con la alusión de tomarse 7 semanas para aprenderlos, ya que si quieres seguir los ejercicios que propone por cada lenguaje, más vale que te pongas las pilas. Tengo que confesaros que a mi me tomó al final 10 semanas.

Cada uno de estos lenguajes se divide en 3 capítulos, con deberes de investigación sobre los mismos y ejercicios, que van desde algo fácil, hasta algunos verdaderos quebraderos de cabeza. El autor Bruce Tate ni siquiera se para a explicarnos como instalar el entorno de cada lenguaje, sino que va directamente al grano.

En cada capítulo hay una mini-historia del lenguaje y una entrevista al creador o a alguna persona influyente en el proyecto. Y al final de estos, se resumen las fortalezas y debilidades de cada uno.
Ten en cuenta que no es para nada una guía de programación, sino una guía de estudio de cada uno de estos maravillosos y algunas veces desesperantes lenguajes de programación.

Una de las cosas que más me ha gustado de este libro es el sentido del humor del autor. Esta escrito de una forma muy amena y por cada lenguaje busca una figura de ciencia ficción o fantasía a la que se pueda asemejar para que te identifiques más con él y puedas comprenderlo, como puede ser el comandante Spock con Haskell, Eduardo Manos-Tijeras con Scala o Mary Poppins con Ruby. Por supuesto con sus ejemplos y definiciones de por qué se parecen a esos personajes, y desde mi punto de vista, acierta bastante

El libro descubre nuevas ideas a los programadores que estén acostumbrados a trabajar con lenguajes orientados a objetos, enseñando los distintos paradigmas que existen dentro de otros mundos, como la programación funcional o la lógica. Te obliga a salir de tu acostumbrada forma de pensar y le da la vuelta a todo para que tengas que forzarte a olvidar el como programas en el día a día, enseñándote un nuevo camino a la hora de organizar y construir programas. Con él aprendes el estado del arte dentro del mundo de la programación y los diferentes paradigmas que existen en este mundillo cada vez más amplio.
 

Paradigmas:

1º Orientación a Objetos (Ruby, Scala)

Este paradigma de programación es el más conocido y en el que se encuentran el groso de los programadores. El libro empieza con él para que te sientas a gusto y te acomodes a la forma de trabajar. En él practicamos con las 3 bases, encapsulación, polimorfismo y herencia.

Con Ruby experimentamos la potencia del “Dynamic duck typing” y la Metaprogramación, después pasando por Scala y introduciendonos en otro paradigma la “Programación funcional”.
Ambos lenguajes se utilizan en aplicaciones generalizadas y ambos presentan avances significativos en el diseño de lenguajes con respecto a los lenguajes principales como Java.

 

2º Orientación a Prototipos o Prototype Programing (IO)Este tipo, no llega a ser un paradigma en si mismo, sino más un subtipo de la programación orientada a objetos, pero se ha diferenciado suficiente en la práctica como para separarlo como modelo. En lugar de trabajar a través de la construcción de clases, todos los prototipos son instancias de objetos, que a su vez se van clonando y extendiendo sus funcionalidades.

3º Programación Lógica (Prolog)Este tipo de lenguajes de programación están orientados a resolver un estrecho tipo de problemas, aunque para ellos son asombrosamente eficientes. Con ellos definimos las reglas para el universo que plantea el problema y a continuación le preguntamos al lenguaje que nos desvele la solución a las preguntas.
Cuando el problema se ajusta a unas reglas lógicas, Prolog es capaz de conseguir resultados en muy pocas lineas de código que en cualquier otro lenguaje llevaría cientos de ellas y horas de comeduras de cabeza por parte del programador.
Estos lenguajes se utilizan en ámbitos como el control de tráfico aéreo o de trenes, casualmente en mi empresa se utiliza justo para el cálculo de rutas para trenes de cercanías

4º Programación Funcional (Scala, Erlang, Clojure, Haskell)Este paradigma es el más usado en el libro, con 4 lenguajes que se ajustan en mayor o menor pureza al mismo.
La programación funcional se basa en funciones matemáticas, las cuales da igual las veces que las llamemos que darán exactamente los mismo resultados, sin influir en otras o tener efectos secundarios. Estos lenguajes son muy expresivos y normalmente necesitan menos lineas de código que los lenguajes orientados a objetos para resolver problemas. Al tratar varios lenguajes, aprendemos que diferentes grados de pureza, nos ofrecen diferentes series de ventajas y desventajas.
Al eliminar los efectos secundarios se puede entender y predecir el comportamiento de un programa, esta es una de las principales ventajas que nos da el utilizar la programación funcional.

Para finalizar tengo que decir, que he disfrutado mucho leyendo este libro y sobre todo haciendo y sufriendo algunos ejercicios. He aprendido muchísimo acerca de como acercarme a resolver muchos tipos de problemas y sobre todo con que paradígma se resolvería mejor.

Aquí os dejo el link a mis ejercicios resueltos por si queréis echarles un ojo GitHub

Llevo aprendiendo lenguajes de programación desde que tenía 12 años. A esa edad aprendí Basic, del cual muchos de vosotros os acordaréis. Me tiré mucho tiempo aprendiendo y profundizando en ese lenguaje procedural, el cual me introdujo en todo este mundo . Un tiempo más tarde, avance a QuickBasic con más estructuras de control y mejor entorno de desarrollo.

A partir de ahí empecé a interesarme por Pascal, con el cual aprendí a estructurar bien el código, o todo lo bien que creía en ese momento. Y con Turbo Pascal aprendí los principios de la programación orientada a objetos.

Con 16 años y recién salido del instituto sabía que lo que quería hacer para ganarme la vida era programar, aprender más lenguajes y perfeccionar lo máximo su técnica.

 

 

A esa edad ya estudiando, aprendí en una asignatura C, con su control de memoria, sus librerías, toda esa potencia y su control de bajo nivel. Con este lenguaje empecé a sentirme “poderoso” y a tocar cosas que realmente alteraban el sistema. Aprendí más profundamente en que consistían las fases de compilado y linkado. También empecé a preocuparme por el aspecto de mi código. Con el que yo me sentía muy cómodo. Pero después de volver a mirar hoy las lineas sacadas del baúl de los recuerdos, he visto que me quedaba muchísimo por aprender :S

Ese mismo verano, junto con mi hermano, empecé a vislumbrar los lenguajes de Microsoft con los que era sencillísimo crear las interfaces gráficas de usuario y C++Builder nos sirvió para eso mismo. Lo afiancé con una asignatura al año siguiente sobre Visual Basic. Con el que aprendí el paradigma de programación dirigida por eventos.

Una vez trabajando en mi primera empresa, tuve que vérmelas con FORTRAN, aunque por suerte no demasiado tiempo De Fortran pasé a estar varios años desarrollando en Tcl/Tk. Un lenguaje ahora en desuso, pero que sigue viniendo por defecto instalado en multitud de distribuciones de Linux.

Con Tcl vi la fuerza de los lenguajes interpretados, su facilidad de uso y sobre todo su potencia en sentencias sencillisimas que no tienen nada que envidiar en la velocidad de ejecución de los programas en C. De hecho, me hice hasta un programa de benchmarking para comparar la rapidez de ejecución entre Tcl y C.

Con este lenguaje llegué a mi mejor nivel de maestría hasta el momento, me conocía toda la sintaxis y sus combinaciones a la perfección. Podía desarrollar cualquier cosa en poquísimo tiempo y me sentía agustísimo utilizándolo. De hecho, hasta colaboré en el proyecto a’MSN construido en este lenguaje.

 

 

En esta época me apunté a estudiar en la UNED y en otra asignatura aprendí Modula2. Del cual solo tengo que decir, que no está bien ni para empezar a aprender orientación a objetos, ya que no tiene herencia de ningún tipo.

Después cambie de división y proyecto dentro de la empresa, y entré en el verdadero mundo de los equipos de desarrollo. Un proyecto de 5 años en un equipo de casi 40 desarrolladores escrito en C++ sobre Linux. En esta época fue cuando más avancé en conocimientos sobre programación. Gracias sobre todo a los compañeros con más experiencia que me iban enseñando paso a paso patrones de desarrollo, control de punteros en profundidad, herencia multiple, a trabajar con ramas en repositorios de código que utilizaba todo el equipo, etc etc… Y lo más importante de todo, a ver mi trabajo desde el punto de vista de un profesional que quiere hacer todo lo mejor que puede su trabajo.

De ahí cambié de empresa y empecé a trabajar con Java. Simplificándome mucho las cosas al venir de C++. Sin control de memoria, sin punteros, independiente de plataforma y con soporte para red diréctamente. Aunque como no, con muchas taras de fábrica, como el no ser absolutamente orientado a objetos o no poder sobrecargar operadores.

También al principio en esta empresa, me toco mantener un programa desarrollado por otra, hecho en Flash con ActionScript. Este semi-injerto de lenguaje de programación lo sufrí más que degustarlo. Con sus MovieClips y su caótico interfaz en el que tienes que declarar cada objeto en tres sitios diferentes.

He tenido múltiples encontronazos fugaces con otros lenguajes como PHP, Bash (si lo podemos definir como lenguaje), Ruby, JavaScript, C# y esta misma semana Clojure, pero con los que solo he aprendido partes de su sintaxis y no he llegado a hacer nada serio.

 

 

Ahora mismo estoy inmerso en el aprendizaje de Groovy, un lenguaje bastante moderno, basado en Java, muy fácil de aprender, pero muy potente y productivo. Con el que pretendo desarrollar una web que seguramente comente en este blog más adelante. Aunque también estoy apunto de empezar en un grupo de trabajo para leer y aprender con “Seven Languages in Seven weeks” que retrasará mi enseñanza de Groovy seguramente.

En resumen, cada vez que miro atrás y observo mi código de hace algún tiempo, me doy cuenta de que si he avanzado. Veo cosas escritas por mí que ahora nunca permitiría subir al repositorio, código duplicado sencillísimo de refactorizar y este tipo de cosas. Pero ver justamente estos fallos es muy bueno. Me alegro de comprobar que no me he quedado estancado y he aprendido poco a poco como se deben hacer las cosas. Se que aún me queda muchísimo por aprender y practicar, pero sentir ese avance me da más ganas de continuar con ello.

Así que os aconsejo que de vez en cuando vayáis guardando algún trozo de código del que os sintáis orgullosos. Hacedlo cada cierto tiempo, 6 meses, 3, un año, es igual. Pero eso sí, cada año al menos, cuando sintáis un cambio en vuestra vida, cuando estéis decaídos por que creéis que no habéis hecho nada en años, o os apetezca simplemente, mirad ese código y podréis observar si al menos en esto habéis aprendido algo.

La mayoría de gente con la que he trabajado programando, cuando tenían que hacer alguna aplicación, una parte, API, clase o lo que fuera, lo escribían y ya está. Incluso yo hasta hace no mucho tiempo, escribía el código que mejor me salía a la primera y ahí lo dejaba, a veces orgulloso de él y todo :S . Por suerte, después de unos años de experiencia he aprendido que esto no debe ser así. 

No nos deberíamos limitar a  escribir un programa de principio a fin a la primera. Más importante aún, no deberíamos esperar ser capaces de escribir programas limpios y elegantes a la primera. Si algo he aprendido durante todo el periplo que ha supuesto mi carrera estudiantil y profesional, es que la programación es un arte más que una ciencia. Para escribir un código limpio, primero debemos escribir código sucio y luego limpiarlo.

Esto no debería ser una sorpresa para nadie. Escribir código limpio, es una cuestión de refinamientos sucesivos. Primero debemos escribir una primera versión, después revisarla, corregir lo que creamos conveniente, a continuación, volver a revisar y volver a refinar, y así sucesivas veces. Tener un ciclo de refactorizaciones sucesivas.

Un símil muy bueno se puede hacer con los polinomios de álgebra, donde los descomponemos en factores y los factorizamos paso a paso para hacerlos más simples y comprensibles sin modificar su resultado para llegar a una solución. Bien, pues con el código debemos hacer lo mismo, llegar a una solución lo más comprensible y simple para todo el mundo que vaya a meter mano a ese código.

La mayoría de los programadores jóvenes (con pocos años de experiencia en este tema) no están de acuerdo con esta técnica y no sigue este consejo muy bien. Ellos creen que el objetivo principal es conseguir que el programa funcione, dando igual como esté escrito por dentro. Terminando así con un código ilegible, código espagueti, o como le queráis llamar. Solo preocupa que funcione lo requerido y poder pasar así rápidamente a la siguiente tarea. Parafraseando a Uncle Bob “Los programadores más experimentados saben que esto es un suicidio profesional”.

El principal problema de que un programador se acostumbre a hacer refactorizaciones sucesivas de su código y cuidarlo con mucho más mimo, es que supone un esfuerzo y este esfuerzo no se ve plasmado en funcionalidades para el proyecto. A pesar de ello, si utilizamos esta forma de programar refactorizando, como técnica de desarrollo a lo largo del proyecto, conseguiremos que nuestro código sea de calidad y mucho más legible, ya no solo para nosotros, sino también para el resto de programadores del equipo. La experiencia dice (y no solo la mía) que este tiempo empleado en cada refinamiento sucesivo, será recuperado repercutiendo con creces en el avance del proyecto en el futuro.

Desde mi punto de vista, lo ideal es que la calidad quede automatizada e integrada en el propio proceso. Si algo falla, que pasará, algún tipo de alarma o aviso debe de saltar para que pueda ser corregido por alguien. Si algo falla y no se detecta, ya no es solo un problema, sino que es un problema del proceso y habrá que modificarlo para solucionar ese fallo de detección. Si alguien tiene que estar supervisando un proceso para controlar la calidad, es que dicho proceso no produce calidad solamente, sino que también produce defectos o desperdicios. Teniendo en cuenta que en la actualidad esto llevado al extremo es casi imposible, lo que nos tendremos que quedar es algo intermedio. Para lograr una excelente calidad en un proyecto necesitamos automatización y supervisión humana, lo mínimo indispensable en este último punto.
En Japón esta filosofía se denomina “Jidoka”, que podríamos traducirla como medio-automatización o automatización con ayuda humana. 

Este termino, “Jidoka” viene de Toyota, en concreto del telar que desarrolló Sakichi Toyoda, fundador de la empresa “Toyota” (Como no :P), que permitía parar la máquina, cuando esta rompía el hilo que utilizaba y así no terminaba desencadenando todos los problemas que esto ocasionaba.

De aquí, transladándolo al desarrollo de software, un ejemplo de auto-calidad dentro del proceso podría ser, el utilizar una buena herramienta de gestión de tareas como Jira, junto a sus plugings Greenhoper, FishEye, Crucible y Bamboo. Habituando al equipo a utilizar este tipo de herramientas, podremos llegar a tener un sistema totalmente integrado, que nos proporcione un buen nivel de calidad.

Un ejemplo simple de su uso prodría ser el siguiente:

1º Alta de nueva funcionalidad a implementar en el proyecto dentro de Jira (Historia de usuario).
2º Implementación de la funcionalidad en el Sprint actual suponiendo que utilicemos Scrum (Greenhoper)
3º Trazabilidad desde los requisitos introducidos en la tarea de Jira hasta los cambios que estos han ocasionado en el repositorio de código en su desarrollo (FishEye)
4º Revisión del código de esta tarea (Crucible)
5º Auto-build del proyecto completo con estos cambios de código (Bamboo)
6º Auto ejecución de test (Bamboo)

Si podemos conseguir que todo el equipo implicado en el proyecto siga estos pasos, habremos conseguido tener un mínimo control semi-automatizado de calidad, que ya quisieran muchos proyectos.
También quiero dejar muy claro, que la calidad no es responsabilidad de un único grupo o departamento. La calidad es responsabilidad de todo el equipo, desde la persona encargada en la toma y redacción de requisitos, hasta el programador más junior que tiene que esforzarse por escribir un buen “Clean Code”.

Otro buen ejemplo de prácticas que nos aseguran un mínimo de calidad en el proyecto siguiendo el proceso, sería TDD. Pero no de una forma de inspección después de la codificación, ni una etapa final o intermedia. Sino, como una disciplina de trabajo, una disciplina compartida por todo el equipo y todos los equipos de desarrolladores. Cada uno, debe de responsabilizarse de crear, ejecutar y mantener un conjunto de pruebas unitarias de todo el código que escribe, y estas deben ser automatizadas y ejecutarse en un tiempo moderado. Además de las pruebas, TDD define una refactorización del código continua, en la que el programador debe buscar en su propio código la forma de mejorarlo, dejarlo limpio, mantenible y así ahorrar tiempo futuro en su comprensión, con un gran ahorro también en deuda técnica.

Aunque parezca mentira, aquí lo difícil de su implantación no es la técnica, ni los medios, ni si quiera el tiempo de desarrollo, sino el que cada miembro de cada equipo asuma esta forma de trabajo como su responsabilidad. Cada miembro debe asimilar y comprender que el resultado del proyecto depende en gran parte de él y que si utiliza estas técnicas, llegará a tener un gran control de calidad, un código realmente mantenible y será finalmente más productivo. Algo duro y difícil de conseguir en una empresa.

Por desgracia, la calidad ha acabado siendo víctima de su propio éxito. Ha sido convertida en un fetiche del marketing, donde no importa tanto mejorar la calidad del proceso productivo, como obtener y galardonarte con una certificación de tal o de cual organización de moda. La pena, es que esto está empezando a pasarle también a las Metodologías Ágiles. Así que entendamos bien los conceptos básicos de calidad para que esto no nos ocurra a nosotros

Es muy importante marcarse objetivos y dejarlos claros, apuntarlos y releerlos de vez en cuando. Nuestra mente tiene un montón de pensamientos al día, si la enseñamos a fijarse en lo que más nos aporta, como son nuestros objetivos, esto nos beneficiará bastante a la hora de seguirlos. 

La gente tiene claro que quiere sentirse mejor, tener más energía o vivir con mayor satisfacción. Pero cuando preguntas qué es exactamente lo que quieren, casi nadie sabe responder. Todos sabemos que queremos tener dinero, tener muy buena salud y ser reconocidos, pero no definimos ningún paso para llegar a ello, no hemos pensado en que dirección avanzar para adquirirlo.

Seguro que os ha pasado muchas veces empezar a ver algo en todos lados. Algo en lo que antes no te habías fijado pero que ahora parece que te persigue. A mi me pasó por ejemplo cuando me saqué el carnet de conducir, (hace ya mucho )  no me había fijado en la cantidad de señales de trafico que hay por todos lados. O cuando empecé a leer sobre la agilidad, que pasé de no conocerla a encontrarme las metodologías por todas las web que leía. Esto, desde el punto de vista Zen, se denomina “Joriki” que se refiere al poder que surge de nuestra concentración.

Cuando te concentras en tus objetivos y estos te absorben completamente, tu tiempo pasa sin darte cuenta, como cuando programamos, investigamos o estamos absortos por una tarea que nos interesa y nos entusiasma.

Con la focalización se desarrolla una profunda concentración, Joriki.

“El poder o fuerza que surge cuando la mente se ha unificado y ha llegado a la concentración en un solo punto. Esto es más que la capacidad de concentrarse, en sentido usual de la palabra.”.

Mediante la apertura se cultiva la no resistencia, el desapego, el no imponerse. Esto para mi se refiere “Joriki”, el poder de concentrar tu mente en algo que te gusta y en algo en lo que quieres avanzar. Al fin y al cabo poner atención.

Con la concentración desarrollamos estabilidad mental para afrontar los retos, en este caso emocionales. Cuando comenzamos a desarrollar la no oposición, la no resistencia, entonces se produce una claridad mental para verlos como son y como actúan estos retos, estos objetivos.

Wolfgang von Goethe dijo “Estamos hechos y moldeados por lo que amamos”, y si lo que amamos es conseguir nuestros objetivos para ser mejores personas y vivir con energía, nos moldearemos por ello si nos esforzamos en conseguirlo.

Muchas veces nos toca hacer tareas repetitivas una y otra vez que nos quitan mucho tiempo. Normalmente no las damos la mayor importancia, ya que estamos acostumbrados a hacerlas y nos salen casi sin pensar. Desde un simple ssh o una copia de backup, hasta un despliegue de la aplicación a producción.

Este tipo de tarea son subceptibles a fallos, ya que estamos tan habituados a ellas, que las hacemos sin pensar. ¿Cuántas veces has cometido fallos al hacerlas? ¿cuántas veces has puesto mal el nombre de la máquina a la que te vas a conectar, has metido mal la password, o incluso hasta te has cargado algo por un error tonto? Yo multitud de ellas.

Una de las mejores cosas que tiene la informática, es que podemos automatizar las tareas para ahorrarnos un tiempo valiosísimo y evitar esta serie de errores tontos, pero que pueden ser garrafales.

Hoy voy a intentan enseñaros una herramienta simple para automatizar estas tareas, llamada Expect.

Me diréis, “¿por qué nos cuentas esto? create un programa en bash o en cualquier lenguaje y ala!” Pero hay muchas veces que tenemos que pegarnos contra una interfaz interactiva, a la cual tenemos que contestar y esperar a que nos conteste, por eso solemos hacer estas tareas a mano. Bien, pues con Expect podemos interactuar con la terminal de turno y de una manera realmente fácil

Expect es una herramienta basada en el lenguaje Tcl, utilizada para automatizar aplicaciones interactivas como ssh, telnet, scp, ftp, etc, y todo esto de una manera rápida y sencilla.

Bien, pues empecemos con un ejemplo de una simple conexión por ssh:

Bueno, como veis es bastante sencillito, no hace falta controlar mucho del lenguaje para manejar este tipo de scripts. Ahora simplemente modificando las variables tenéis un script que se conecta por ssh a la máquina que le digáis, de una manera muy rápida. Hasta podéis configurar el prompt sin necesidad de modificarlo en el .bashrc del servidor.
Yo concretamente uso este tipo de script para conectarme a mis máquinas en el trabajo, y nunca me equivoco en la ip ni en el usuario ni en el password

Ahora, podemos comprimir un directorio del que queramos hacer un backup (por ejemplo) una vez conectados a él con el script anterior y quitando el comando interact:

Para más ayuda, tenemos el comando autoexpect. Este comando graba todo lo que hagamos en una terminal y lo va guardando en un archivo en formato expect, y una vez hayamos terminado podemos ejecutarlo. Esto, repetirá fiel y exactamente los mismo pasos que habíamos hecho. Esto ya es el colmo!

Imaginaros que cantidad de cosas podemos automatizar de una forma sencillita y cuanto tiempo y errores podemos ahorrarnos. Ahora piensa que cosas repites una y otra vez de forma repetitiva todos los días y podrías automatizar…. y hazlo!!

Hace poco, terminé un libro llamado “El líder que no tenía cargo” de Robin Sharma.

El libro es una novela, en la que a través del protagonista, nos va abriendo las puertas a la filosofía del profesional, del líder sin cargo. La cuál se podría resumir, así:

“No importa el lugar que ocupes en el organigrama empresarial o cuales sean tus circustancias personales. Lo fundamental es que tienes capacidad para demostrar que eres un líder. Estés donde estés en tu profesión o en tu vida, siempre debes dar el máximo.”

En el libro, Robin, intenta hacer ver la habilidad que todos tenemos para llegar a tener un gran liderazgo. Pero no un liderazgo en el sentido de tener mucha presión acompañado de una gran responsabilidad en una gran empresa. Sino un liderazgo diario, en la vida de cada uno, y haciéndonos ver como podemos influenciar a cada persona de nuestro alrededor positivamente, inspirando, dando ejemplo en nuestro trabajo y actitud diaria. El tipo de liderazgo que tiene que ver con la excelencia en el trabajo y en el comportamiento, dando igual el puesto en el que te encuentres.

Todos podemos tener un millón de razones para desanimarnos, para no estar satisfechos, para no implicarnos en nuestro trabajo. Podríamos quejarnos de que no somos más que un empleado y que lo único que hacemos no es más que trabajar para la gente con mucho dinero. Pero una de las más grandes libertades que tenemos como personas, es la libertad de elegir cómo vemos nuestro papel en el mundo y el poder que tenemos para tomar decisiones positivas en cualquier circunstancia en la que nos encontramos.

Este libro me ha hecho recordar y replantearme muchas cosas de mi vida reciente. Cuando empecé a entrar, a leer y meterme en el mundo de la agilidad, no me dí cuenta de que cada vez estaba más ilusionado. No tenía ni idea de lo que depararía, pero desde entonces he aprendido que la incerteza es un regalo precioso. A casi todos nos da miedo lo desconocido. No debería ser así. Lo desconocido no es más que el comienzo de una aventura, una nueva oportunidad de crecer. Y justamente por estas causas me decidí a empezar a escribir en este blog