¿Qué necesitamos en la vida?

Creo que [Ricardo Darín] lo explica muy bien.

Hace un tiempo descubrí parte de la entrevista y como hoy la recordé, me puse a buscarla pensando que duraba diez o quince minutos. Estaba equivocado pues dura más de una hora 🤯

Quedé sorprendido por la calidad de la conversación y cómo es que se abordaban temas como:

  • Cine
  • Televisión
  • Familia
  • Felicidad
  • ¿Qué es lo que realmente importa?
Continue reading ¿Qué necesitamos en la vida?

¿Qué determina la calidad de nuestro trabajo?

Hace unas semanas encontré un [post en reddit] que llamó mi atención, este tenía como leyenda “me pagan por poner tuberías, no por mover rocas” y es posible que si la vieron, hayan recordado alguna experiencia personal (pues no somos perfectos) o la actitud de alguna persona que conocieron en el pasado (porque seamos claros, nadie es perfecto)

Me puse a reflexionar sobre eso y en cómo nuestra motivación, criterio y experiencias personales influyen en la calidad del trabajo que realizamos y cómo es que hay conceptos que podrían parecer implícitos pero que no siempre es así. Aquí los tres primeros que llegaron a mi mente:

Continue reading ¿Qué determina la calidad de nuestro trabajo?

¿Qué es lo más importante para la creación de un producto?

Yo creo que no importa el tamaño del equipo, cliente, tecnología o el producto a construir. Creo que es mucho mejor estar enamorado del problema [Bezos], seguir hambriento [Jobs] y dejar que nuestra imaginación nos permita crear cosas nuevas [Disney]

Claro, el camino será más sencillo si estamos en un equipo que disfruta esta aventura.

Fuente imagen: [Bold planning]

Principios de Arquitectura del nuevo Facebook Messenger

Hace poco me enteré de que los amigos de Facebook liberaron una nueva versión del Messenger para iOS. El nombre del proyecto es LightSpeed y los resultados son interesantes:

  • 1/4 del tamaño original
  • 2 veces más rápido
  • 84% menos en líneas de código (de 1.7M a 360k)

Mientras leo la publicación, encuentro que se habla de una plataforma de mensajería en vez de un app convencional. Creo que una visión de este tipo es muy importante si es que queremos dar un gran paso en el diseño de nuestro software. No está de más decir que una de las barreras que encontraremos regularmente, será el poco entendimiento de la diferencia entre plataforma, aplicación y herramienta.

Si bien es cierto la visión es muy importante, esta debe servir para definir –y abrazar– principios de arquitectura adecuados para cumplir con el sueño esperado.

1. Usar el Sistema Operativo

Aquí la clave fue eliminar el código que podía ser reemplazado por alguna funcionalidad del sistema operativo. Si este no lo hacía bien, pues se decidió construir una librería en lenguaje C, la cual estoy seguro será reutilizada en la versión para Android que lanzarán en algún momento.

Este tipo de estrategias es muy importante porque es una forma concreta de apoyar a la eliminación de código innecesario, el cual muchas veces se refleja en frameworks o intermediarios que a pesar de ayudarnos –bajo la perspectiva de programador– hace que la aplicación sea más lenta.

2. Usar SQLite

De lo que le he revisado no queda claro si antes utilizaban SQLite, pero en esta nueva versión toda la información que se utilice pasará primero por la base de datos local. Esto podría significar que no hay invocación directa a servicios pues la comunicación sería similar a lo que se ve en una aplicación monolítica convencional.

Queda mencionar que el gestor que se utiliza es una versión mejorada de SQLite. La diferencia radica en el soporte a stored procedures y de paso se promueve la reutilización.

A nivel de estructura de datos, lo que se ha buscado en esta nueva versión es eliminar los diseños complejos y reflejar en una tabla lo que se necesita para poder mostrarla en la interfaz de usuario. Estoy seguro de que son tablas con información redundante. Es decir, menos normalización, más velocidad 🙂

3. Reutilizar la Interfaz de Usuario

Cuando los amigos de Facebook revisaron el código fuente encontraron cosas interesantes, el caso que ponen como ejemplo es la cantidad de componentes visuales que representaban un mismo set de datos. Por ejemplo, se encontraron componentes diferentes para la presentación horizontal y la presentación vertical. Hasta aquí todo podría parecer natural, pero creo que encontrar 40 vistas para representar un mismo set de datos es un error que no se puede volver a cometer.

Lo que algunos hacemos en este tipo de casos es quedarnos con la vista que pueda ser tomada como base de reutilización o bueno, en el peor de los casos tenemos que crear un nuevo componente. Eso sí, en casi todos los casos iremos eliminando vistas innecesarias y por ende, código innecesario.

4. Usar –más– el servidor

Si bien es cierto estamos en la época de las aplicaciones que procesan información por medio de servicios o alguna de sus variantes, en este caso se aprovecha el procesamiento local (gracias a SQLite) y se trabaja con un componente que hace las veces de sincronizador de información. Lo interesante es que este componente está alojado principalmente en el servidor, lo cual me recuerda al concepto de publicador/suscriptor. Ojo que estoy tratando de simplificar conceptos, estoy seguro de que hay más trabajo por detrás 🙂

Comentarios

Me parece muy interesante de que Facebook invierta en un proceso de ingeniería que para muchos podría ser considerado como radical y que “no se puede hacer drásticamente pues no representará valor para el negocio”. Esto lo coloco entre comillas pues es una respuesta que encuentro regularmente cuando converso con desarrolladores de software que trabajan en proyectos en diferentes rubros.

Por otro lado, está de más mencionar que los beneficios hablan por sí solos, pero creo que es consecuencia de haber esperado tanto tiempo para poner una suerte de termómetro en el desarrollo que venían realizando. Estoy seguro de que hubo al menos una reunión en la que comentaba lo difícil que era seguir avanzando con el desarrollo y que lo mejor era rehacer algunas –o muchas– cosas si se buscaba mayor escalabilidad.

Con respecto a algunas consideraciones técnicas del trabajo realizado, la reducción de código es una consecuencia directa de la eliminación de código muerto y de haber descartado funcionalidades que eran menos utilizadas. También hay que resaltar la importancia de las automatización de pruebas unitarias y la respectiva cobertura, una vez escuché que en Facebook buscaban una cobertura del 100% y en este caso solo mencionan que el componente de sincronización cumple con ese objetivo.

Ahora, yendo un poco más atrás y revisando la presentación del proyecto en una sesión del F8 del año pasado, se menciona que el objetivo es contar con una nueva versión tanto para iOS como para Android, así que en cualquier momento tendremos mayores novedades 🙂

Un abrazo

new beta release in process