La respuesta puede parecer obvia, pero vale la pena la aclaración, NO.
Hace pocas horas, usuarios de HBO Max recibieron un mensaje que, si no conoces de tecnología, puede que no lo entiendas. El hecho es simple, se ejecutó una prueba sin verificar los destinatarios.
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:
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.
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.
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 🙂
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.
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 🙂
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
El mes pasado quería terminar tres libros y solo pude con uno. Si bien es cierto el que terminé tiene más de 700 páginas y hubo un momento en el que me detuve a pensar cómo mejorar mi velocidad, decidí que estaba bien pues disfruté mucho la aventura y es lo que siempre debería contar 🙂
Autor: Mario Vargas Llosa
Género: Ficción
Año de publicación: 1969
Si bien es cierto el título es considerado un clásico de la Literatura Peruana, recién me animé a comprar la novela hace seis años. Confieso –que como con otras publicaciones– no tuve éxito en el primer intento. Esto a pesar de que el autor ha comentado más de una vez que es su novela preferida, en mi caso sentía que todo era muy desordenado y lento a la vez.
Es así que guardé la novela hasta hace poco y creo que en esta oportunidad encontré muchas cosas interesantes. Algo que me gustó bastante es el desarrollo de los personajes, casi todo contado a manera de conversaciones y recuerdos que surgen a raíz de una conversación que se da en un bar de nombre “La Catedral”. Un dato interesante de las conversaciones es que estas se describen en paralelo mientras –en muchos casos– ocurren en tiempos diferentes, logrando que con el paso de cada capítulo aparezcan más personajes, cada uno con una historia que se va explicando de a pocos.
Como dije al iniciar, la lectura resulta compleja –pues no se cuenta linealmente– e incluso en situaciones que parecen ‘normales” me pasó que tenía que volver a leer o regresar a capítulos anteriores para refrescar algunos momentos.
Encuentro además que hay muchos hechos de la realidad que a pesar del tiempo –dios, han pasado 50 años– se mantienen, se explican casos de racismo, diferencias marcadas entre cada clase social, prejuicios, conflictos familiares, injusticias, desempleo y claro, corrupción. No por algo muchos recordamos esta novela por la frase ¿En qué momento se jodió el Perú?
Creo que la pregunta –y claro, la novela– viene “con truco”, no es que la respuesta esté en una página en particular. Lo que encuentro es un conjunto de personajes que reflexionan desde sus realidades, encuentro diferentes clases sociales que buscan sobrevivir a lo que va ocurriendo en su mundo más cercano. Lo que encuentro triste es esas historias podrían volverse a contar ahora y muchos pensarían de que están hablando de nuestra sociedad.
Espero volver a leer la novela en otro momento de mi vida y claro, también espero de que las cosas hayan cambiado.
Un abrazo,
Si trabajamos en el mundo de la tecnología, ya nos debe haber pasado –o escuchado– de que el sistema se cayó por un cambio mal realizado. A veces nos pasa que mientras arreglamos una cosa malogramos otras. Mucho cuidado con los círculos viciosos.
Estas situaciones me recuerdan las veces que juego [Jenga] con mis amigos. Y es que, de empezar con una mala estrategia, llegado un punto, cada turno se vuelve emocionante pues nadie quiere tumbar la torre de madera.
Si en los proyectos de tecnología empezamos sin una estrategia técnica adecuada, muchas veces tendremos dolores de cabeza en el futuro. Sin ir muy lejos, muchas decisiones técnicas son pasadas por alto a consecuencia de “ahorrar”, “lo arreglamos después”, “las cosas siempre fueron así” o la necesidad de solucionar problemas rápidamente sin entender por completo las implicancias del mismo o incluso sin entender la solución.
Sinceramente creo que pasar por este tipo de situaciones nos hacen crecer profesionalmente. Sin ir muy lejos, con el paso del tiempo he descubierto que ya no me gustan algunas soluciones que hice en proyectos anteriores, la idea es ir descubriendo nuevas formas y cuestionar nuestro trabajo. Creo que deberíamos ser los primeros en hacerlo.
Regresando a la analogía, les cuento que conversando con muchos amigos o con las personas que me entrevistaban mientras buscaba trabajo, he confirmado mi teoría; todos hemos tenido una torre de Jenga que se ha derrumbado al menos una vez en nuestros sistemas. A veces nos reímos de eso y otras nos avergüenza, pero lo más importante es que hemos tenido la capacidad de aprender y jugar sabiamente.
Tal como dije al empezar con este post, puede que nos hayan pasado estas cosas y no hay problema con ello. Lo que sí creo es que sería irresponsable no hacer algo al respecto para que esto no nos vuelva a ocurrir.
Puede que este sea –o suene– un trabajo complicado pero no es imposible. Los factores de éxito más importante tienen que ver con la determinación para resolver los problemas y el tiempo necesario para empezar con este tipo de trabajos.
A pesar de ello, he dividido esta estrategia en tres etapas.
Hay que tener en cuenta de que estamos trabajando sobre la practica de ir mejorando lo existente mientras seguimos atendiendo la misión del negocio. Esto es lo que ocurre normalmente, no debemos olvidar la visión del negocio y que además esta nos sirve como referencia principal de nuestra visión tecnológica. Lo que he encontrado en algunas situaciones es que también hay mucho trabajo por realizar, aquí algunas consideraciones:
Lo que he encontrado en algunos equipos es que con el paso del tiempo nos volvemos jugadores expertos de Jenga y la verdad es que eso es algo que no deberíamos buscar. No es saludable.
Lo que también he encontrado es que una definición incorrecta del trabajo a realizar –para atacar la torre de Jenga– hará que no se encuentre o vea el valor de lo que estamos buscando. Parte de esto lo menciono en [la importancia de la arquitectura de un sistema]
Algo muy importante –y obvio para algunos– es que necesitarán más jugadores de equipo y menos jugadores de Jenga.
Un abrazo,
Cuando [Alan Kay] fue a la entrevista de trabajo en [Xerox PARC], una de las preguntas tenía que ver con sus sueños ¿cuál crees que será tu mayor logro? le preguntaron. “Una computadora personal”, respondió.
Como parecía que no le entendían lo qué estaba hablando, cogió una cartera del tamaño de un cuaderno, la abrió y dijo: “Esto será una pantalla plana. Aquí abajo habrá un teclado, y tendrá la potencia suficiente para almacenar correo, archivos, música, imágenes y libros. No pesará más de un kilogramo. De eso estoy hablando”.
El entrevistador se rascó la cabeza, murmuró: “Sí, claro” y lo contrató. Era el año de 1970.
Esa historia la descubrí mientras leía [Los Innovadores] de [Walter Isaacson]. Había escuchado un poco de Alan Kay, pero no tenía idea del genio que me estaba perdiendo.
No quiero entrar en más detalles pues este sería un post interminable. Me queda agregar que este pionero de la computación ha hecho más de lo que conocemos y posiblemente estemos usando algo que haya sido uno de sus sueños (sin ir muy lejos, la programación orientada a objetos, la interfaz de usuario y claro ¡las tablets!). Los dejo con un video que resume rápidamente los aportes del gran –y quizá único– Alan Kay.
Un abrazo (y gracias, Alan)
Fuente cabecera: [Extracts from Alan Kay’s AMA on Hacker News]
