Libro: The Clean Coder

downloadEsta semana he terminado de leer “The Clean Coder”, de Robert (Uncle Bob) Martin, un libro que la crítica considera la la continuación del célebre “Clean Code” del mismo autor, pese a que está más enfocado a corregir ciertas actitudes a la hora de programar, de relacionarnos con compañeros, aceptar responsabilidades, etc, dentro de la imagen del programador profesional.

A lo largo de poco más de 200 páginas el libro nos explica detalladamente conceptos técnicos como TDD, que nos ayuda a generar un conjunto de pruebas antes de comenzar a escribir una línea de código, la importancia de Pair Programming como medio de estar centrados en la solución del problema y de transmitir conocimientos, la necesidad de tener un sistema de integración continua que haga que los test se ejecuten de manera regular y la necesidad de que estos tests sean rápidos para poder ejecutarlos una y mil veces, entre otras cosas.

Por otra parte, y más relacionado con habilidades interpersonales, nos cuenta la importancia de saber decir NO a cualquier petición por urgente que parezca, y valorar si realmente podemos hacerlo, lo que nos lleva a saber decir , y hacernos responsables de las promesas que hacemos a nuestros clientes, managers y compañeros.

Siguiendo esta línea, el libro nos explica cómo los programadores solemos interpretar las estimaciones que hacemos como meras aproximaciones, y nuestros clientes o managers las suelen interpretar como deadlines, y explica varias técnicas para poder dar estimaciones más fiables como puede ser el análisis PERT, en el cual asignas caso mejor, caso más probable y caso peor a cualquier tarea.

Relacionado con la estimación, nos habla de la necesidad de conocer el negocio en el que nos encontramos para poder dar una mejor valoración a las prioridades que vienen “de arriba” usando algunas anécdotas.

Finalmente nos habla de la importancia de practicar, de aprender, de mantener nuestras herramientas al día, de buscar mentores, ya sea de la manera clásica (alguien que dedique activamente su tiempo a ayudarnos) o de maneras menos convencionales (un libro, una conferencia, algo que nos motive a seguir adelante aunque los autores no lo sepan).

En definitiva, una lectura recomendable, sobre todo al empezar un nuevo proyecto profesional, nos ayudarán a identificar puntos a mejorar de nuestros equipos, y nos ayudaran a ser mejores profesionales.

En Amazon: The Clean Coder: A Code of Conduct for Professional Programmers

Manteniendo nuestros eBooks sincronizados entre diferentes dispositivos.

Cuando nos movemos del modelo de libros físicos al modelo de libros digitales, ganamos una enorme conveniencia, y es que nuestros libros de repente se vuelven accesibles allá donde vayamos, en nuestro lector de eBooks, en nuestro móvil, en nuestra tablet, e incluso en cualquier ordenador vía el navegador, guardando el estado de la lectura.

A mí personalmente me encanta cómo funciona el ecosistema de Kindle, ya que tienes por una parte el dispositivo y por otra parte una suite de aplicaciones para iOS, Android, Windows y un lector web que mantienen todo conectado.

Sin embargo, a pesar de que el catálogo de Amazon es bastante grande, no es la única fuente para comprar ebooks, y a veces nos encontramos con otras fuentes, que incluso a veces ofrecen libros de manera gratuita, como por ejemplo:

  • O’Reilly y sus ofertas diarias
  • Manning, que nos regala el ebook cuando compramos el libro en papel.
  • Pragmatic Programmers, con ofertas recurrentes.
  • Microsoft Press, con libros gratuitos.

Amazon no ofrece ninguna manera de poder ampliar nuestra biblioteca, aunque sí que nos permite enviar libros a dispositivos y aplicaciones concretas, pero sin la capacidad de sincronización entre ellos.

Buscando una solución a esto me topé con Google Play Books, que para aquellos que tengan Android es la aplicación por defecto para abrir libros en formato ePub, también tiene aplicaciones para iPhone, y además es una web donde podemos continuar leyendo nuestros libros.

Una de las ventajas que descubrí de Google Play Books es la posibilidad de subir nuestros propios libros, hasta 1000, con lo cual (siempre que no estén protegidos por DRM) podemos tenerlos accesibles desde cualquier parte manteniendo nuestro estado guardado.

Como decía en mi artículo al principio del año, uno de mis objetivos es leer más, y de momento este pequeño descubrimiento me está ayudando bastante.

Enlace: Google Play Books

Y llegó 2016

Ya con esta son seis ediciones del resumen anual de mi blog, o lo que es lo mismo, más de 2000 días desde mi primer artículo, y es que 2015 ha sido un año muy interesante para mí, aunque he de reconocer que he escrito menos, mucho menos, de lo que pensaba en un primer momento.

Comencé el año volviendo a mi universidad a hablar de tres Tecnologías Microsoft que no se dan en la carrera, comprobando cómo, años después de mi paso por las aulas, el DotNetClub sigue vivo y dando caña. Enhorabuena a Arcadio (actual Presidente de la asociación) por ese trabajo.

En febrero publiqué The Time Box, mi primera aplicación para Android, y pude dar un vistazo a esa plataforma, tener mi primera aplicación en Google Play y ver todo el ciclo de desarrollo de una aplicación móvil.

En marzo tuve la oportunidad de formar parte de la primera gran conferencia de .NET a nivel nacional, en la que tuve el honor de presentar dos sesiones, una de ellas acompañado por el ilustre Eduard Tomás en la que hablamos de ASP.net vNext, y las novedades que traía.

Entre febrero y abril, Juan Quijano y yo un par de hangouts en los que tratamos temas como Xamarin o programación funcional desde la perspectiva del mundo real, y de cómo profesionales usan estas herramientas y lenguajes en su día a día.

Mayo fue mes de cambios, y de despedidas, ya que cerré un ciclo profesional en Frontiers, una empresa de publicaciones suiza en la que participé en la creación de Loop, su red social.

Alrededor de la misma fecha, y a pesar de que no le hice la publicidad que se merecía en el blog, publiqué mi primer curso de CampusMVP, que ahora forma parte de la oferta del Master Online de desarrollo de Aplicaciones Front-End.

Durante el resto del año estuve un poco alejado del blog, ya que apenas tuve tiempo, pero eso no me impidió publicar un monográfico de Scala, que me gustaría retomar este año, o publicar mi experiencia en el lambda world de Cádiz.

Como último artículo del año, me calcé las zapatillas otra vez y comenté mi experiencia corriendo la carrera “Ponle Freno” un año después de mi primera incursión en el mundo del “Running”

El año pasado además, dejé lista una lista de objetivos que quería cumplir este año:

  • Aprender un nuevo lenguaje de programación o framework, y hacer un proyecto en él: En este caso he aprendido algo de programación para Android y Scala, así que lo podemos dar por conseguido.

  • Hacer más vídeos en inglés y en castellano: La parte de castellano está conseguida con el curso de CampusMVP, la parte en inglés no tanto. digamos que cumplido al 50%

  • Montar más hangouts: 3 en 2014 contra 2 en 2015, está claro que este año no ha podido ser.

  • Hacer más proyectos personales: 2015 terminó con un par de ideas, mi primera aplicación Android y un pequeño clon de Trello, creo que lo podemos dar por conseguido.

  • Cerrar un ciclo de certificaciones Microsoft: Este año no ha podido ser.

  • Cursar y aprobar otro MOOC: Muy en la línea de las certificaciones Microsoft, tampoco ha podido ser.

  • Trabajar más en mi segundo o tercer idioma: A fecha de hoy trabajo en inglés al 100%, así que mi nivel de inglés y mi vocabulario han mejorado, pero el tercer idioma sigue siendo una incógnita.

  • Seguir escribiendo: Pese a que he escrito menos, he escrito, y espero seguir el año que viene.

Así, pongo la vista en 2016 con la siguiente lista de tareas, que seguramente sufrirá modificaciones a lo largo del año, pero esto es lo que quiero hacer a fecha de hoy:

  • Enviar al menos 3 papers a conferencias técnicas.

  • Leer más literatura técnica, mínimo 10 libros.

  • Hacer más proyectos personales, mínimo 3.

  • Escribir más artículos técnicos, mínimo 20.

  • Hacer un nuevo MOOC de Coursera/edX, etc.

  • Conseguir al menos una certificación de tecnología, ya sea Microsoft, Java, etc.

  • Aprender al menos un lenguaje, tecnología, plataforma o paradigma que me saque de mi zona de comfort.

Y a todo eso, sumar conseguir correr la San Silvestre Vallecana en menos de 1h.

Gracias por leer este blog. Espero que tengas un próspero y 2016 cargado de cosas interesantes.

OT: Corriendo voy… un año después

El año pasado por estas fechas comentaba mi primera experiencia en una carrera popular, y toda la tecnología que había visto en su momento.

He de reconocer que fue agónico, tuve que parar varias veces y el resultado implicó una semana de agujetas, aunque fue suficiente para que me picara la curiosidad, empezara a correr de manera más regular y a participar en alguna que otra carrera más:

  • Rexona Street Run (5K) en la que descubrí lo divertido que es participar en una carrera resfriado, altamente recomendable. Me paré un par de veces pero logré terminarla corriendo.

  • Rock n’Roll (10K), que llegué justo y no pude dejar la mochila en el guardarropa, con lo cual me tocó correr con la bolsa, una faena, pero logré terminarla sin parar.

  • Carrera Popular Alcobendas (10K) ya en primavera, pude comprobar que el calor no perdona, y los desniveles de Alcobendas son algo intimidantes. Me tocó pararme varias veces y casi no lo consigo.

  • Proniño (10K) la última carrera que corrí en verano, todo fue perfecto, un tiempo maravilloso, un terreno plano prácticamente sin cambios de nivel, logré terminarla sin parar logrando mi mejor tiempo en 10K hasta ahora.

  • Ponle Freno (5K) he repetido este año aunque en la modalidad 5K, con la suerte de que todo ha salido bien, desde el transporte hasta el guardarropa, y he conseguido mi mejor tiempo.

Con cada carrera, he ido aprendiendo muchísimo sobre ritmos, tiempos, estiramientos, qué llevar, qué no llevar, etc, y de momento mi stack tecnológico de runner consiste en lo siguiente:

  • Fitbit Charge HR: Además de contar pasos, Detecta cuando empiezo (y termino) una actividad como correr, registrando distancia y ritmo cardiaco, lo que me permite analizar mejor los resultados tras la carrera.

  • Pebble Time: Además de poder personalizar la hora y poder leer los mensajes de Whatsapp mientras corres, permite la conexión con Endomondo, resultando muy útil para tener datos como el ritmo actual directamente en la muñeca.

  • Auriculares Bluetooth MPow Cheetah: En su momento me costaron poco más de 20€, y son extremadamente buenos para el precio que tienen, se oyen bien, resultan cómodos, aíslan del ruido y evitan los molestos cables, sin sacrificar batería. disponible en Amazon

  • iPhone 6: Hace un año tenía un iPhone 5 que luego descubrí que formaba parte de la partida con problemas de batería, tras una temporada en el mundo Android he vuelto a iOS, y la batería del 6 me permite correr sin tener que depender de baterías extra.

  • Endomondo: Mi app de referencia para todo lo relacionado con deporte, me ayuda a correr, mide las distancias y me va indicando ritmo y kilómetros por los auriculares mientras corro.

  • Spotify He de reconocer que envidio a aquellos que son capaces de correr sin música, pero yo aún no he llegado a ese nivel, ni sé si seré capaz, de momento spotify (y su opción running) me ayudan a concentrarme, aunque para la carrera opté por una lista de reproducción, ya que spotify running requiere internet y no quería depender del estado de la red mientras corría.

Dar con el equipamiento definitivo es una cuestión de prueba y error, aunque de momento creo que el que tengo me vale, lo siguiente es encontrar unas buenas zapatillas, y creo que para eso le preguntaré a los chicos de runnics.

Nos vemos en la línea de meta!

Estuve en el Lambda World

Escribo estas líneas volviendo en tren desde Cádiz, una ciudad enigmática que me recuerda muchísimo a mi añorada Habana, tal vez porque la segunda se construyera basándose en la primera.

Cádiz, además de ser la ciudad que acogió la firma de la primera Constitución Española en 1812, ha acogido el pasado fin de semana el primer evento internacional de programación funcional celebrado en España, el Lambda World.

En este evento, ponentes de todas partes del mundo han venido a contarnos acerca de características de la programación funcional como mónadas, funciones puras, inmutabilidad, efectos secundarios, o sobre cómo llevar conceptos de programación funcional a programación orientada a objetos.

Para ello, hemos visto ejemplos en lenguajes como F#, C#, Java, Ruby, Swift, y, sobre todo, Scala. He aprendido muchísimo y aquí resumo algunos conceptos que me han llamado la atención y que me toca seguir estudiando.

La inmutabilidad, más complicada pero menos propensa a errores.

En programación orientada a objetos definimos clases con propiedades y comportamiento. Este comportamiento suele implicar un cambio en el estado del objeto.

Sin embargo, es justamente lo que queremos evitar en programación funcional, ya que trabajamos con objetos inmutables, con lo cual una vez creados, no cambia ninguna de sus propiedades.

Esto también se aplica a colecciones, y a los miembros de la misma, con lo cual la acción de añadir un objeto a una colección, o modificar un objeto de la misma requiere crear una nueva colección.

Con estos objetos inmutables lo que conseguimos asegurarnos que su estado no va a cambiar, y que no vamos a tener “sorpresas” cuando pasemos un objeto a un método que de repente modifique alguna de sus propiedades.

Sin embargo, aunque lenguajes como Swift, Scala o F# soportan inmutables por diseño, en el mundo clásico de la orientación a objetos, tanto para Java, C# o Ruby, es justamente al contrario, y queda de nuestra mano utilizar colecciones inmutables y definir manualmente nuestros objetos.

Las funciones puras no generan efectos secundarios, o casi

Otro concepto que se repitió bastante en el evento era el de función pura, que no es más que un método que recibe una entrada y devuelve una salida.

La magia de este concepto es que cuando lo combinamos con los objetos inmutables, conseguimos que para una entrada X tenemos la absoluta seguridad de que la salida será Y, SIEMPRE.

Esto nos permite, entre otras cosas, poder probar de manera rápida nuestras funciones si el lenguaje que estamos utilizando incorpora una consola REPL (Read Evaluate Print Loop), ya que una vez definida la función solamente tenemos que ejecutarla con los valores adecuados.

Los lenguajes funcionales no son algo solamente “académico”

Aunque los conceptos que nos muestren se acerquen bastante más a las matemáticas que a ensamblador, los ejemplos mostrados en aplicaciones móviles, sistemas cliente-servidor, arquitecturas funcionales y videojuegos, me dejaron bastante claro que la programación funcional está aquí para quedarse, y que ya estamos tardando, al menos, en aprender algunos de sus conceptos.

No tengo ni idea de lo que son las monads, creo.

Uno de los conceptos de programación funcional que se me escapa es el de las monads, que al parecer son tipos de datos con propiedades específicas, y uno de los ejemplos que veíamos en el evento era el del monad Either, que tiene dos tipos, Left o Right.

Con este monad podíamos definir el resultado de nuestra función, siendo Left un resultado de éxito, y Right una definición de un error, evitando flujos como captura de excepciones.

Este concepto tiene a su vez conceptos relacionados como monoids o functors… de los cuales tendré que leer, y mucho.

Podemos usar conceptos de programación funcional con lenguajes no puramente funcionales.

Conceptos como funciones puras u objetos inmutables son relativamente fáciles de implementar aunque los lenguajes no lo refuercen nativamente, sin embargo requiere un grado de disciplina mayor.

Sin embargo lenguajes como C# o Java van aportando cada vez más características de la programación funcional a su sintaxis, como las Lambdas y las colecciones inmutables. Aunque no es el escenario ideal para utilizar programación funcional, nos permite usar lo que ya sabemos.

Tenemos muchas maneras de empezar, aunque hay dos muy interesantes:

Por una parte tenemos lenguajes como Scala, en el que podemos desarrollar de la misma manera en la que lo veníamos haciendo hasta ahora, ya que soporta tanto tipos mutables como inmutables, e ir agregando características de la programación funcional a nuestros programas.

Por otra parte tenemos lenguajes F#, que nos permite lanzarnos al vacío, con una sintaxis que nos podría recordar cuando encadenamos la salida de distintos procesos en una shell de unix, que nos permite aprender programación funcional más “pura” y su interoperabilidad con C# nos permite agregar componentes funcionales a nuestro proyecto.

En resumen

Tenemos características como la inmutabilidad y las funciones puras que nos evitan sorpresas en nuestro código, podemos empezar migrando poco a poco a funcional o tirarnos a la piscina con lenguajes que solamente implementan este paradigma, y tenemos algo de soporte en nuestros lenguajes del día a día de algunos conceptos como las lambdas. Ha sido una experiencia muy enriquecedora, y espero veros en la siguiente edición de Lambda World

Scala desde la perspectiva de C# y JavaScript, desde la Mindcamp

Este fin de semana he tenido la oportunidad de dar una charla en la Mindcamp sobre las características de Scala que he ido aprendiendo durante estas últimas semanas.

Aunque queda aún mucho por aprender, esta charla resume los temas que hemos ido viendo en los artículos anteriores de esta serie, así como algunos ejemplos donde podemos ver:

  • Hola mundo y diferencias de sintaxis con Java o C#
  • Clases, objetos, y funciones como ciudadanos de primera clase.
  • Sintaxis iterativa VS Sintaxis funcional.
  • Traits como manera de tener interfaces con implementación.
  • Case classes para realizar pattern matching y separar la interfaz de la implementación.

Los ejemplos están disponibles en este repositorio de Github: Mindcamp7-Scala.

Como parte de la charla, puse una lista de una serie de características que se quedaron fuera y que quedan como idea para futuros artículos, como son:

  • Frameworks como Play y Scalaz
  • Testing con ScalaTest
  • Integración con herramientas
  • La línea de comandos (REPL) de Scala
  • Interoperabilidad con Java.
  • La herramienta Activator de Typesafe
  • Scala Build Tool

Además, algunos recursos, muchos de los cuales ya hemos listado anteriormente en el blog, como son:

Finalmente, un par de libros que me recomendó el gran Jorge Barroso (@flipper83) sobre programación funcional:

Las diapositivas están disponibles en mi SlideShare: Scala desde C# y JavaScript

La semana próxima estaré en la LambdaWorld, un evento que reúne en Cadiz a lo mejor de la programación funcional, y habrá, por supuesto, Scala. Nos vemos allí!

Scala desde la perspectiva de C# y JavaScript, tercera parte

En los artículos anteriores de esta serie, veíamos una pequeña introducción a Scala, y hacíamos una kata para comprobar que habíamos entendido la sintaxis. En este artículo veremos dos construcciones del lenguaje que resultan bastante interesantes, llamadas traits y case classes.

Traits

Podemos entender los traits como una mezcla entre interfaces y clases abstractas, ya que podemos definir un contrato como haríamos con una interfaz, y por otra parte podemos definir también una implementación.

A diferencia de Java, Scala nos permite implementar varias traits, y podemos utilizarlas para agregar características adicionales a nuestro código. Veamos un ejemplo.

En este caso vamos a definir una clase base llamada Employee, que tiene un salario, y luego vamos a definir varios traits, algunos solamente con valores, y otros con pequeñas comprobaciones.

  • El trait Temporary calcula el mes final del contrato
  • El trait Authority nos permite saber si un empleado tiene gente a su cargo
  • El trait Remote nos permite establecer una localización y una zona horaria
  • Finalmente, el trait InOffice nos permite establecer un despacho.

Con estos cuatro traits podemos componer las clases que forman a nuestros empleados, donde tenemos a Developer, a Manager y a Intern:

Como vemos en el ejemplo, podemos utilizar los traits para definir características adicionales a nuestras clases, y podemos también agregar lógica dentro de las mismas, mezclando los conceptos de interfaz y clase abstracta.

Case classes

La otra cara de la moneda son las Case Classes, que podemos encontrar cuando definimos jerarquías, pero sobre todo las podemos encontrar cuando tenemos un número específico de entidades y lo que realmente cambia es lo que hacemos con ellas. Recuperando el mismo caso de empleados, becarios y managers, vamos a redefinirlo como Case Classes:

En este caso hemos simplificado la manera de definir los diferentes datos, y solamente utilizaremos la fecha inicial para Dev y Manager, y el tiempo total de estancia para Intern. En este caso, podemos asumir que nuestro conjunto de datos está fijo.

Sin embargo, ¿qué pasaría si necesitáramos agregar información de nóminas a nuestra aplicación? Si recurriéramos a la herencia, deberíamos implementar un método “salary” o similar, para cada una de las clases, sin embargo, como estamos usando “case classes” podemos crear un único método que las compruebe todas, y se comporte de manera consistente:

En este caso, el método nos devolverá distintos resultados en función de la clase que estemos aplicando y los datos que contenga la misma, permitiendo una separación entre las clases que contienen los datos de los métodos para manipularlos.

Este enfoque tiene sus inconvenientes, y es que si tenemos que agregar un nuevo tipo de dato (por ejemplo, External) tendremos que cambiar todos los métodos auxiliares para soportar el nuevo caso, así que se reduce a elegir en función de las necesidades de nuestro proyecto.

Conclusiones

Construcciones como Case Classes o Traits nos permiten establecer restricciones de una manera sencilla, las traits nos permiten mezclar conceptos de interfaces y clases, y las case classes nos permiten separar los datos de nuestra clase de las transformaciones que hacemos con los mismos.

En C# tenemos a nuestra disposición los métodos de extensión, con los que podemos lograr un comportamiento similar que con las case classes, y que hemos visto con anterioridad en este artículo “Clases abstractas VS interfaces + métodos de extensión“.

En el próximo artículo de la serie veremos más construcciones y, como siempre, más ejemplos.

Para más información: