Buenas Prácticas en Git

Commits, qué hacer y qué evitar

Diogo Sampaio • 19 de julio de 2024

El artículo "Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git" discute las diferencias entre buenos y malos commits en Git, un sistema de control de versiones esencial para los desarrolladores. Un buen commit se caracteriza por mensajes claros y concisos que explican qué se ha cambiado y por qué, además de ser atómicos, es decir, se centran en un único cambio lógico. Ejemplos incluyen "Corregir error en el módulo de autenticación" o "Agregar pruebas para la función de inicio de sesión."

ejemplo de buen commit: git commit -m

Por otro lado, los malos commits tienen mensajes vagos como "Actualizaciones varias" y combinan múltiples cambios no relacionados, lo que dificulta el rastreo de errores y la revisión del código.

ejemplo de mal commit: git commit -m

En mi opinión, seguir buenas prácticas no solo mejora la colaboración dentro de los equipos, sino que también facilita el mantenimiento a largo plazo del proyecto. La claridad en los mensajes de commit puede verse como una inversión en el futuro del proyecto, ahorrando tiempo y esfuerzo cuando sea necesario revisar los cambios.

Falla Global de CrowdStrike: Lecciones Aprendidas

El artículo del Pragmatic Engineer detalla un incidente crítico causado por CrowdStrike, una empresa de ciberseguridad, que llevó al colapso de millones de máquinas Windows en todo el mundo. Este incidente comenzó cuando CrowdStrike envió una actualización de contenido a todos sus clientes.

Detalles del Incidente

El Proceso que Causó el Fallo: El proceso responsable del error se llama "CSAgent.sys". Este proceso fue instruido para mover bytes de la instrucción Assembly "mov r9d, [r8]", donde r8 era una dirección no mapeada (inválida), resultando en el colapso del sistema operativo.
Archivo de Contenido Problemático: El fallo fue causado por la lectura de un nuevo archivo de contenido que CrowdStrike envió a todos los clientes, llamado "C-00000291-*.sys". Hubo un problema en la forma en que este archivo fue analizado, lo que resultó en un error lógico que provocó que el sistema se bloquease.
Propósito de la Actualización: La actualización tenía como objetivo detectar pipes nombrados maliciosos. El producto Falcon de CrowdStrike monitorea cómo los procesos se comunican en una máquina o a través de la red para identificar actividades maliciosas. La actualización añadió un nuevo archivo de reglas para filtrar pipes nombrados sospechosos. Los pipes nombrados son un concepto común en los sistemas operativos para la comunicación entre procesos.
Error No Tratado: La actualización de configuración desencadenó un error lógico que provocó el colapso del sistema operativo. CrowdStrike divulgó que el problema no estaba relacionado con bytes nulos en el archivo Channel 291 ni en ningún otro archivo Channel.

Análisis del Problema

El problema central fue una instrucción de Assembly que intentó mover una ubicación de memoria no válida, lo que resultó en el fallo de los dispositivos Windows. Este incidente resalta la complejidad y la interdependencia de los sistemas modernos, donde un pequeño cambio puede tener repercusiones significativas a nivel global.

En mi opinión, este incidente sirve como advertencia sobre la importancia de prácticas robustas de gestión de cambios y validación de actualizaciones antes de su lanzamiento. El fallo subraya la necesidad de resiliencia y redundancia en los sistemas, además de una comunicación clara y eficiente durante las crisis. Las empresas deben utilizar estos eventos como estudios de caso para mejorar sus infraestructuras y procedimientos de respuesta a incidentes. Implementar pruebas rigurosas y planes de contingencia puede marcar la diferencia entre una recuperación rápida y un desastre prolongado.

Una Línea de Código: Impacto Inmenso

Desastre del Ariane 5

El 4 de junio de 1996, la ESA lanzó el Ariane 5, que se desintegró 37 segundos después del lanzamiento debido a una falla de software en el sistema de orientación. El problema fue un desbordamiento de valor resultante de la conversión incorrecta de un valor de punto flotante de 64 bits a un entero de 16 bits. Este error, remanente del código del Ariane 4, combinado con la trayectoria más empinada del Ariane 5, resultó en la destrucción del cohete y la pérdida de la carga valorada en casi medio billón de euros.

Incidente de SQLException que Paralizó una Aerolínea

Un incidente reciente paralizó vuelos en EE.UU. debido a un error de sincronización entre la base de datos primaria y de respaldo. Contratistas "borraron involuntariamente archivos", lo que resultó en una paralización nacional que afectó a más de 11.000 vuelos. Este evento refleja un problema descrito en el libro "Release It" de Michael Nygard, donde una excepción de SQL no capturada causó el agotamiento de la pool de recursos, paralizando el sistema central de una aerolínea durante tres horas.

Desastre del Boeing 737 MAX

En 2018 y 2019, dos aviones Boeing 737 MAX se estrellaron, matando a 346 personas. El problema fue con el sistema MCAS, que dependía de datos de un solo sensor de ángulo de ataque. Datos incorrectos llevaron al sistema a activarse innecesariamente, haciendo que la nariz del avión se inclinara hacia abajo repetidamente. La falta de información adecuada para los pilotos y la subcontratación del desarrollo de software contribuyeron a los accidentes.

Lecciones Aprendidas

Estos casos subrayan la importancia del rigor en el desarrollo de software, especialmente en sistemas críticos. Es esencial evitar copiar código sin entenderlo completamente, implementar un manejo adecuado de excepciones, considerar los requisitos del usuario y realizar pruebas exhaustivas. En el caso del Ariane 5, la falta de pruebas y el uso inadecuado de código antiguo resultaron en una falla catastrófica. El incidente de la aerolínea destacó la importancia del manejo adecuado de excepciones y la gestión de recursos. El desastre del Boeing 737 MAX evidenció los riesgos de depender de un solo punto de falla y la falta de comunicación adecuada con los usuarios finales.

Recomendaciones

Evitar Copiar Código sin Entendimiento: Utilizar código de forma no crítica puede introducir fallos ocultos.
Importancia de Manejar Excepciones: Los errores de programación deben manejarse adecuadamente para evitar fallas catastróficas.
Atención a los Requisitos: Los cambios en los requisitos, como la trayectoria del cohete, deben ser considerados cuidadosamente.
Pruebas Exhaustivas: Probar el software en condiciones reales y simuladas es esencial para garantizar su robustez.
Redundancia: Eliminar puntos únicos de falla para aumentar la resiliencia del sistema.
Simplificación: Mantener los sistemas simples para evitar la introducción de nuevas vulnerabilidades.

Estos incidentes sirven como recordatorios de los riesgos involucrados y la responsabilidad que recae sobre los profesionales del software. La implementación de prácticas rigurosas de pruebas, manejo de excepciones y un profundo entendimiento del código utilizado son esenciales para prevenir futuros desastres.

ORMs: Simplemente Aprende SQL

El autor del artículo "What ORMs Have Taught Me: Just Learn SQL" concluye que los ORMs (Object-Relational Mappers) pueden ser más perjudiciales que beneficiosos. Aunque pueden complementar el uso del SQL en un programa, no deben reemplazarlo. Después de trabajar con Postgres y SQLite, principalmente usando SQLAlchemy e Hibernate, el autor enfrentó varios problemas inherentes a los ORMs, como la "desadaptación objeto/relacional", la identidad de las entidades, los esquemas duales y los objetos parciales.

Los problemas con los ORMs comienzan con el "crecimiento de atributos" y el uso excesivo de claves foráneas, lo que resulta en tablas extremadamente amplias y consultas ineficientes. Las consultas que comienzan simples, como query(Foo.class).add(Restriction.eq("x", value)), se complican a medida que aumentan los atributos. Un ejemplo dado es la consulta que, al principio, funciona bien con cinco atributos, pero se convierte en una "manguera de datos" cuando la tabla tiene cientos de atributos, similar al uso de SELECT * en SQL. Para modelos simples, los ORMs pueden funcionar bien, pero cuando se trata de uniones complejas o funciones de ventana, los ORMs pueden dificultar la generación de SQL eficiente. A menudo, la solución es escribir consultas SQL directamente usando un sistema de plantillas, manteniendo la descripción de las tablas en el ORM.

Mantener definiciones de datos tanto en la aplicación como en la base de datos es redundante y problemático. El autor prefiere mantener las definiciones en la base de datos y utilizarlas en la aplicación. Esto evita la complejidad de sincronizar definiciones de datos entre dos sistemas. Sin embargo, la migración de datos sigue siendo un problema significativo, ya que cambiar el modelo de datos en la aplicación es fácil, pero migrar datos en la base de datos es complejo y propenso a errores. Manejar identidades de entidades y transacciones es complicado con los ORMs.

El autor describe la dificultad de manipular identificadores de base de datos y la complejidad de gestionar transacciones de forma eficiente. Menciona la necesidad de manipular el ORM para obtener identificadores de base de datos a través de técnicas como el vaciado manual de la caché o commits parciales.

Al reflexionar sobre su experiencia, cuestiona el rechazo generalizado de los procedimientos almacenados y considera la base de datos como un tipo de dato con una API: las consultas. Concluye que aprender SQL es esencial, ya que los ORMs, aunque útiles para representar definiciones de datos, son inadecuados para escribir consultas eficientes y gestionar el estado de los objetos. Por lo tanto, para cualquiera que use un RDBMS, aprender SQL es indispensable. Este enfoque permite una integración más simple y directa con la base de datos, evitando los problemas comunes asociados con el uso de ORMs.

En mi opinión, la crítica a los ORMs presentada es bastante pertinente, especialmente en escenarios donde el rendimiento y la complejidad de las consultas son cruciales. Aunque los ORMs ofrecen una abstracción conveniente, frecuentemente introducen una complejidad adicional e ineficiencias que podrían evitarse con un buen conocimiento de SQL. Estoy de acuerdo en que, en muchos casos, aprender SQL y usarlo directamente es un enfoque más eficaz y eficiente, especialmente cuando se trata de modelos de datos complejos y la necesidad de consultas optimizadas.

Theatre.js: Herramienta de Animación para el Navegador

Theatre.js es una biblioteca de animación en JavaScript que ofrece herramientas profesionales para el diseño de movimiento en la web. Altamente extensible, permite la creación de animaciones complejas y detalladas, desde escenas cinematográficas en THREE.js hasta interacciones de UI.

Con una línea de tiempo robusta, Theatre.js facilita la creación y gestión de animaciones. Incluye un editor visual que permite ajustar las animaciones directamente en el navegador, proporcionando un control preciso sobre cada fotograma.

La documentación de Theatre.js es exhaustiva, con guías detalladas y tutoriales que ayudan a los desarrolladores a comenzar rápidamente. Para más información, visite la documentación de Theatre.js.

Theatre.js representa un avance significativo en la democratización de herramientas de animación para la web. Al llevar capacidades avanzadas de animación al navegador, facilita el trabajo de desarrolladores y diseñadores, promoviendo la creatividad y la innovación. La combinación de un editor visual intuitivo con una potente línea de tiempo hace que esta biblioteca sea ideal para proyectos que requieran animaciones detalladas y precisas. La adopción de Theatre.js puede transformar la forma en que las animaciones se crean y gestionan en la web, haciendo que los procesos complejos sean más accesibles y eficientes.

La Singularidad de los Sitios Web Japoneses: Factores Culturales y Estéticos en Juego

En el artículo "Why Japanese Websites Look So Different," Mirijam Missbichler analiza las peculiaridades de los sitios web japoneses y explora las razones culturales, tecnológicas y estéticas que contribuyen a su estilo distintivo. Aquí están los puntos clave abordados:

Desafíos en la Creación de Fuentes y Desarrollo Front-End:

Complejidad de las Fuentes: La creación de fuentes para el japonés es significativamente más compleja que para los idiomas basados en alfabetos latinos. Mientras una fuente en inglés puede tener alrededor de 230 glifos, una fuente japonesa debe cubrir entre 7.000 y 16.000 glifos debido a los tres sistemas de escritura y al gran número de caracteres kanji. Esta complejidad técnica lleva al uso frecuente de imágenes con texto en lugar de fuentes digitales.
Implicaciones en el Diseño: La dificultad y el tiempo necesarios para crear nuevas fuentes resultan en un número limitado de opciones, lo que contribuye al uso de diseños visualmente densos y menos optimizados.

Desarrollo Tecnológico y Alfabetización Digital:

Tecnología Obsoleta: A pesar de ser un líder global en robótica y tecnología, Japón sigue utilizando tecnologías como disquetes y máquinas de fax. Japón "vive en el año 2000 desde 1985", reflejando un desfase tecnológico que puede afectar la forma en que se diseñan y actualizan los sitios web.
Alfabetización Digital: Este desfase tecnológico puede manifestarse en diseños web más conservadores y menos actualizados, lo que influye en cómo se desarrollan y mantienen los sitios.

Influencias Culturales:

Preferencias Visuales: El diseño de los sitios web japoneses está moldeado por tradiciones culturales que favorecen una estética rica y detallada. En lugar del minimalismo occidental, muchos sitios japoneses presentan diseños llenos de información y colores vibrantes. Esto refleja un enfoque cultural que valora la presentación extensa y detallada.
Experiencia del Usuario: En contextos como las compras en línea y la información gubernamental, se considera beneficioso contar con una mayor cantidad de detalles, lo que permite a los usuarios tomar decisiones más informadas y reducir el riesgo de errores.

Expectativas e Influencias Visuales:

Ejemplos Comparativos: El artículo compara sitios como Starbucks en EE.UU. y Japón para ilustrar las diferencias. El sitio estadounidense presenta un diseño limpio y moderno con fuentes distintivas, mientras que el sitio japonés utiliza imágenes para representar texto y botones, lo que da como resultado una apariencia más cargada y compleja.
Percepción y Adaptación Cultural: Aunque el diseño japonés puede parecer confuso para los occidentales debido a su densidad informativa, está adaptado a las expectativas culturales locales. La complejidad visual es una forma de proporcionar información de manera más atractiva y detallada para el público japonés.

Opinión:

El diseño de los sitios web japoneses puede parecer exagerado y sobrecargado para aquellos acostumbrados al minimalismo occidental. Sin embargo, esta diferencia es una adaptación a las normas culturales y tecnológicas de Japón. La expresión "Japón, viviendo en el año 2000 desde 1985" ilustra bien el desfase tecnológico que aún influye en el diseño de los sitios, lo que resulta en elecciones visuales que priorizan la información detallada y la prevención de errores. Comprender estas sutilezas culturales y técnicas es esencial para apreciar el diseño japonés y evitar juicios apresurados basados únicamente en perspectivas occidentales.