R. Chavarria's Blog

Proud of developing software, proud of being an Engineer

Tests de integración lentos

Es una sensación extraña, pero me pasa a veces. Se supone que las máquinas, los ordenadores, son más rápidos que nosotros haciendo según qué cosas. Aún así, hay muchas veces que me desespero. Seguro que más de una vez te has puesto de los nervios porque tu ordenador tardaba mucho en finalizar una tarea: copiar un fichero, abrir un documento, cargar una página web,… Pues una cosa que me exaspera mientras estoy trabajando es esperar a que los tests terminen de ejecutarse.

El post de hoy va de una historia de abuelo cebolleta: hace un tiempo, tuvimos una discusión en la oficia, dentro del equipo con el que trabajo. Estuvimos discutiendo sobre cómo hacer nuestros tests de integración más rápidos.

Por aquel momento teníamos un gran número de tests de integración, más o menos emparejado con el número de tests unitarios. Bueno, sí, ya empezamos mal. Estoy de acuerdo con la teoría de que es mucho mejor tener una pirámide de tests, no un cucurucho de tests. Pero esa era nuestra realidad. La verdad es que a día de hoy, hemos conseguido tener muchos más tests unitarios que de integración, pero esa es otra historia.

Ready player one

de Ernest Cline

Por qué lo he leído

La primera vez que leí una recomendación sobre el libro fue en Microsiervos. Comentaban que era un libro de ciencia ficción relacionado con los videojuegos con muchísimas referencias a videojuegos de los años 80.

Al principio no estaba seguro si me gustaría o no. Puede que conozca unos cuantos juegos de los 80, pero por aquellos años yo era aún un niño, así que no estaba seguro de que fuera a entender todas esas referencias.

Pero más adelante, los de Microsiervos lo volvieron a recomendar, y un poco después escuché otra recomendación por parte de Kevin Kelly en el podcast de Tim Ferris. Uno no se puede resistir a tantas recomendaciones.

De qué trata el libro

La historia que cuenta el libro está ubicada en un tiempo futuro. Un tiempo donde todo gira alrededor de internet. La vida digital tiene más peso que la vida analógica. Pero no todo el mundo se puede permitir las mejores conexiones a internet.

El protagonista es un estudiante que no tiene una vida fácil. Pero le apasionan los videojuegos.

Un creador de videojuegos ha creado el mejor videojuego de todos los tiempos. Es un juego de realidad virtual donde cada jugador está representado por un avatar y la acción se desarrolla en un mundo virtual. Ese mundo tiene multitud de escenarios, planetas, ciudades y edificios, los avatares se reúnen, chatean o hacen videoconferencias. Vamos, todo lo que se puede hacer online, se hace a través del videojuego. El hecho es que el creador del juego muere, pero antes de morir organiza un concurso dentro del videojuego, y aquel que gane el concurso obtendrá un premio que le cambiará la vida.

El concurso trata de encontrar tesoros, de buscar pistas, de superar pruebas,… Todos ellos referenciando a juegos de la juventud del creador de juegos, que resulta que son juegos reales de los años 80 y 90. Un jugador importante de este concurso, es nuestro protagonista, que por más suerte que otra cosa, es quien supera la primera prueba, lo que desencadena una carrera frenética por conseguir el premio.

Conclusiones y valoración

El libro es una pasada. La historia es sencilla, a veces predecible, pero tiene unos cuantos giros inesperados que te hacen disfrutar. La trama no es complicada para nada de seguir. Aún así, hace infinitos guiños a la historia de los videojuegos. Personalmente, no he entendido todos de ellos, pero si has jugado a algún videojuego en tu vida, seguro que sentirás muchas conexiones.

También resulta muy interesante para alguien muy relacionado con la tecnología, como yo, pues el autor describe hardware y software que podrían ser realidad hoy en día, pero quizá no están muy extendidos entre la gente o es una tecnología un poco verde todavía, pero puede que sean realidad dentro de pocos años.

Si eres un apasionado de los videojuegos (aunque no hayas conocido los inicios de ellos) o si eres un apasionado de la tecnología, estoy seguro de que este libro te encantará y disfrutarás leyéndolo. Y si no te apetece leer, puedes esperar a la película (prevista para marzo de 2018, según IMDB).

Notas tomadas

Simplemente, tomé esta nota:

(Hablando sobre comecocos) Permitía vencer a un rival controlado por ordenador. En un juego como ese, un jugador humano con talento siempre podía ganar a la máquina, porque el software no era capaz de improvisar. O bien reaccionaba aleatoriamente, o en un número limitado de formas predeterminadas, basadas en una cifra finita de condiciones programadas con antelación. Ese era un axioma de los videojuegos, y seguiría siéndolo hasta que los seres humanos inventen la verdadera inteligencia artificial.

¿Estaremos ya cerca de ese final? Espero que no. Los videojuegos perderán su gracia.

Referencias

Cómo desplegar una aplicación Elixir/Phoenix en Heroku

Heroku es una plataforma donde los desarrolladores pueden desplegar sus aplicaciones (sobretodo está pensado para aplicaciones web) y hacerlas públicas de forma gratuita o por un pequeño precio. Yo he utilizado a veces este servicio para hacer pruebas con servidores en JavaScript (NodeJS) o PHP, pero también admite muchos otros lenguages de programación: Ruby, Java, Python, Go,…

No es ningún secreto que estoy tonteando con Elixir, y el framework Phoenix es el framework por referencia para crear aplicaciones web en Elixir. Pero ese no es un lenguaje soportado por Heroku, así que parecía un poco complejo poder hacer unas pruebas desplegando una aplicación Elixir/Phoenix en Heroku.

Por suerte, Wendy Smoak escribió un artículo hace un tiempo hablando de esto mismo: Deploying a Phoenix app to Heroku. Dicho artículo tiene licencia Creative Commons CC-BY-NC. Este post no es una traducción en sí, pero como está basado en él me parece justo y obligatorio respetarla. Así que este post está basado en el artículo Deploying a Phoenix app to Heroku, de Wendy Smoak, y también está licenciado bajo la Creative Commons CC-BY-NC, digan lo que digan el resto de posts de este blog.

The nature of software developent

de Ron Jeffries

Por qué lo he leído

Como casi todos los libros, por recomendación. Ví que lo recomendaba Carlos Buenosvinos, y no pude resistirme. Además, el autor es una leyenda viva del desarrollo del software y del manifiesto Agile, así que tenía que ser un libro de aúpa.

¿Un libro que trata sobre la naturaleza de la profesión a la que te dedicas? A leerlo casi, casi, sin pensarlo.

Elixir: noveno asalto

En el asalto anterior aprendimos un par de conceptos básicos sobre los nodos. En este asalto aprenderemos sobre servidores OTP: qué son, para qué sirven, por qué son útiles y cómo implementarlos fácilmente.

Todo esto, siguiendo el método de aprendizaje con el que comenzé la serie:

  • Aprender lo suficiente para comenzar
  • Experimentar, jugar, buscar puntos desconocidos, hacerse preguntas
  • Aprender lo suficiente para hacer algo de utilidad
  • Enseñar lo aprendido

The Phoenix project

de Gene Kim

Por qué lo he leído

Había visto varias referencias al libro por Twitter, blogs y distintos podcasts. Sabía que el libro era muy similar a La meta, de Eliyahu M. Goldratt, un libro que me gustó bastante.

Así que, tras ver que Eduardo Ferro también lo había leído, me decidí a leerlo yo también.

Elixir: octavo asalto

Último post del año, que no de la serie sobre aprender Elixir. Este asalto va de nodos, PIDs y un poquito (muy poco) de entrada/salida.

Aprenderemos qué es un nodo, cómo crear nuevos nodos y cómo comunicarlos a un nivel muy básico. Y algo muy interesante, cómo hacer que un nodo ejecute una función a nuestro antojo.

Todo esto, siguiendo el método de aprendizaje con el que comenzé la serie:

  • Aprender lo suficiente para comenzar
  • Experimentar, jugar, buscar puntos desconocidos, hacerse preguntas
  • Aprender lo suficiente para hacer algo de utilidad
  • Enseñar lo aprendido

Imagen basada en Risk de Ben Stephenson, algunos derechos reservados, licencia: CC BY 2.0

The 4 hour body

de Tim Ferriss

Por qué lo he leído

Soy un oyente del podcast de Tim Ferriss, the 4 hour workweek podcast, y me parece una persona bastante peculiar, con unas ideas bastante rompedoras, y muy preocupado por el aprender y dominar muy distintas disciplinas rápidamente. No estoy de acuerdo con todo lo que Tim predica, pero la verdad es que muchas de sus ideas me parecen muy buenas y les han dado resultados a muchos de sus seguidores. Entiendo que eso no quiere decir que funcionen en todos los casos, pero al menos las ideas locas de Tim han sido probadas más de una vez.

The 4 hour body, o El cuerpo perfecto en 4 horas que es su título en español, trata de dos cosas básicamente: cómo perder peso, y cómo ganar músculo. Y yo estoy interesado en perder peso, asi que ¿por qué no conocer algunas ideas de una persona seguida por millones?

Global Day of Code Retreat 2016

Siento que el título esté inglés, no he encontrado una traducción que suene bien en español: ¿Día global del retiro del código? Uff, no lo veo.

A lo que vamos, el pasado día (day) sábado 22 se celebró a nivel mundial (global) un evento en el que programadores se reúnen (retreat) para… programar (code).

Sí, como lo oyes. Hay gente a la que le chirría que unas personas que se dedican profesionalmente a programar se reúnan con compañeros de profesión para seguir programando un día no laborable. Pero es que este evento no tiene nada que ver con lo laboral, aunque sí con la profesión. Una definición tirando a formal sería:

Un «code retreat» es un evento de un día, de intensa práctica, enfocado en los fundamentos del diseño y desarrollo de software. El formato ha demostrado ser un medio efectivo de mejora de habilidades dado que proporciona a los desarrolladores la oportunidad de tomar parte en prácticas focalizadas, dejando de lado las presiones de tener un que terminar un trabajo.

(traducción libre de la definición sacada de Code retreat)

Foto: «Global Day of Code Retreat 2016», por Eduardo Ferro