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

No podemos ignorar que todos tenemos días malos. Por una causa o por otra, de vez en cuando tenemos un tiempo de bajón emocional, en el que nos vemos incapaces de levantar la cabeza y seguir el ritmo diario como siempre.

Lo primero en estos casos es darse cuenta de que nos está ocurriendo. Mucha gente simplemente sigue su marcha diaria con malestar y desgana, hasta que se recupera y continúa normalmente. Pero en estos casos, este tiempo de decaída suele durar bastante más que si nos paramos, nos damos cuenta de la situación y hacemos algo para remediarla.

¿Que sueles hacer para cambiar tu estado emocional a mejor? Yo suelo utilizar las siguientes técnicas:

• - Construir algo, como un puzzle o una figurita de papel
• - Programar y ver el avance
• - Escuchar canciones positivas
• - Escribir sobre ello
• - Hablar con amigos, por teléfono o mejor, salir a tomarse unas cañas con ellos.
• - Tomarse unas vacaciones.
• - Rodearse de personas positivas.
• - Ver videos “alegres/motivadores” por internet.
• - Leer sobre el tema y aprender sobre él para poder enfrentarme mejor la próxima vez que pase.

Al fin y al cabo todo se reduce a la actitud con la que nos enfrentemos al momento. Si nos dejamos llevar y optamos por la actitud “Todo me va mal” solo conseguiremos entrar en una amarga y peligrosa espiral de pensamientos y sentimientos negativos, que nos hundirán más aún en la misma.

Los problemas son solo problemas cuando los convertimos en problemas. Las víctimas se quejan diciendo “¿Por qué a mí?” Pero alguien que se enfrenta a las cosas grita “¡Depende de mi!” y entonces aprovechan unas oportunidades soberbias para dedicarse a obtener resultados excepcionales. Cuando sabemos que todo depende de nosotros mismos, cuando vemos que según la mentalidad por la que apostemos, positiva o negativa, podemos modelar nuestro alrededor para ser más felices, es cuando saldremos de ese estado de desánimo y entraremos con energía en un estado de felicidad.

 

Así que sé el amo de tu destino, sé el capitán de tu alma…..

 

 

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.

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

“Ser tú mismo en un mundo que intenta constantemente convertirte en otra cosa es el mayor de los logros.” Ralph Waldo Emerson.

Realmente lo importante no es ni tener un cargo, ni tener el poder que este puede otorgar. Lo importante de verdad es el trabajo que tu hagas, estar a gusto con él, que te divierta y guste, para poder dar tu máximo cada día. Así realmente serás importante en la empresa.

Todos nosotros tenemos el poder de ir cada día al trabajo y dar lo mejor de nosotros mismos. Y para eso no hace falta tener un cargo. Tenemos el poder de inspirar, influir y ensalzar a todas las personas con las que nos encontremos mediante el don del buen ejemplo. Y para eso no hace falta tener un cargo. Todos nosotros podemos crear cambios positivos ante unas condiciones negativas. Todos tenemos el poder de tratar a todos los implicados en una organización con respeto, aprecio y bondad, y al hacerlo, elevar la cultura de la organización a lo mejor de lo mejor.. Y para eso no hace falta en absoluto, tener un cargo.

“El dinero, la influencia y la posición no son nada comparados con la mente, los principios, la energía y la perseverancia” Orison Swett Marden

La definición de enciclopedia de Poder sería “Estar capacitado, reunir las condiciones, para hacer lo que se expresa.” con lo que cada uno de nosotros tenemos el poder en el día a día.

Todos los días, antes de entrar al trabajo, tendríamos que dejar nuestro ego en la puerta. En lugar de obsesionarnos con los objetivos que la sociedad quiere que rijan nuestra vida, con un despacho más grande y un sueldo más alto, deberíamos dedicar toda nuestra concentración y nuestras capacidades a realizar nuestro trabajo de la mejor manera posible. Todo lo demás vendrá dado. De ese modo, podemos dejar una huella en las vidas de nuestros compañeros y de nuestros clientes, y crear una organización mejor. No definir nuestro éxito por lo que conseguimos o el puesto en el que estamos, sino por lo que damos y podemos aportar. Esto, además de hacernos especiales a los ojos de todo el mundo, nos llenará de una sensación de plenitud y felicidad, por que sabríamos que estaríamos utilizando nuestra vida a una causa con sentido. Y para lograr todo esto, ya sabéis…. no hace falta tener un cargo