Por allá del 2020, fui invitado por un profesor (que resulta ser un amigo mio) del Tecnológico de Monterrey a tener una sesión de preguntas y respuestas con sus alumnos de curso sobre lo que trabajaba en aquel entonces. Debido a la pandemia, la sesión se llevó a cabo de manera virtual y hoy me encontré con las preguntas que me realizaron. Como realmente disfruté ese momento en el que podría encender la pasión por el software libre con nuevos contribuidores potenciales, ahora comparto el contenido de las preguntas (y mi respuestas a las mismas):

Tengo un pequeño pasatiempo con teclados mecánicos (nada serio aún). Uno de los problemas que tuve recientemente fue sobre modificar algunas opciones del teclado; específicamente intercambié las teclas de Esc con Bloq Mayus. Esto es muy sencillo gracias a gnome-tweaks: Abrir la aplicación gnome-tweaks Click en Keyboard & Mouse Click en el botón de Additional Layout Options Click en la opción Caps Lock behavior Seleccionar Swap Esc and Caps Lock Hasta aquí todo está bien, pero después inicié a usar teclados programables.

Una de las cosas en las que trabajé en un proyecto previo (en golang) era sobre interactuar con una biblioteca en C la cual usaba estructuras bitfield, así que no solo era interactuar con código en C, sino también manipular bits para asegurarse de que los datos representados no se corrompieran entre las estructuras bitfield de C y las estructuras de go, en ambos sentidos. Esta entrada es un recordatorio para mi mismo sobre cómo se hizo, en caso de que lo olvide en el futuro (lo cual realmente significa que no sé si lo olvide en 2 ó 4 meses).

Hoy aprendí sobre un detalle al compilar una biblioteca compartida. Quería ligar código contra una biblioteca que compilé con meson, pero seguía obteniendo errores al ligar, específicamente undefined reference to `func_name' # referencia indefinida a `func_name' Después de compilar la biblioteca manualmente e inspeccionar el objeto resultante con nm, la diferencia relevante fue a siguiente # creado con meson 0000000000001263 t func_name # compilada manuamente 0000000000001263 T func_name La diferencia es sobre la T siendo minúscula/mayúscula, como sugiere la página de manual de NM(1):

Esta receta es una de mis favoritas, además de que es muy sencilla de realizar y es muy completa. Ingredientes 1/2 Pechuga de pollo 1/2 Cebolla 2 Chayotes 2 Papas 3 Zanahorias 1 Corazón de lechuga Crema al gusto Sal al gusto Tostadas Procedimiento Se pica el chayote, papas y zanahorias en cubos pequeños (alrededor de 5 mm) y se cocen al vapor. Una vez cocidos, dejar enfriar. Se coce la pechuga de pollo con el trozo de cebolla, una vez cocida se deshebra.

Habíamos intentado variedad de recetas para este platillo, sin embargo a gusto propio esta fue la que mejor sabor y también parece más cercana (al sabor) de la vendida en lugares comerciales de la ciudad. Ingredientes 2 Cucharadas de caldo de pollo en polvo (Knorr Suiza) 750g Carne de res fileteada para carne en su jugo 500g Tomate verde 1 Manojo de cilantro 2 Dientes de ajo 250g de Cebolla blanca 250g de tocino 1 Manojo de cebollita cambray 7-8 Papas pequeñas Sal al gusto Pimienta al gusto (Opcional) Limón al gusto (Opcional) Cilantro y cebolla picados Procedimiento Cocer las papitas y los tomates juntos en una olla con agua.

Estas enchiladas probablemente no sean lo que normalmente se acostumbra en la gastronomía mexicana, sin embargo es la manera en que las he acostumbrado en casa desde que tengo memoria, así que para mi son las mejores. Además de que no tienen aceite y son vegetarianas. Igual podrían acompañarlas con unos frijoles de la olla o unas papas cocidas (servidas a parte) para darle otro impulso de sabores (mi papá suele comerlas acompañadas con una taza de caldo de frijoles caliente, por ejemplo).

4 - comentarios El comentario más valioso es aquel que no se tiene que escribir NO comentar código incorrecto, es mejor reescribirlo No hay nada más útil que un comentario en un lugar correcto, por otro lado, no hay nada peor que comentarios incorrecto No hay nada más dañino que un comentario viejo que mienta y desinforme Cuanto más viejo y alejado del código que describe, es mayor la probabilidad de que se equivoque Son un mal necesario Cuando escriba un comentario, piense si no existe otra forma de expresarlo a través del código Un comentario impreciso es peor que la ausencia de comentario Sólo el código dice la verdad respecto a lo que hace un comentario es útil cuando clarifica contenido que no podemos modificar para mejorar (como el uso de cosas de bibliotecas externas) Los comentarios TODO no son excusa para mantener código incorrecto No usar comentarios si se puede usar una función o una variable clara en su lugar Si se escribe un comentario, que describa el código que lo rodea, nunca información global fuera de contexto La conexión entre un comentario y el código que describe debe ser evidente, si se molestó en escribir un comentario, al menos asegúrese que el lector entenderá su significado Una función breve no requiere explicación y un buen nombre funciona mejor que un comentario en el encabezado No compensan código incorrecto El código incorrecto es la principal motivación para crear comentarios Un código claro y expresivo es mucho mejor a un código complejo con muchos comentarios, en lugar de invertir tiempo comentando código, resuélvalo Comentarios legales Aquellos por estándares corporativos, como los de derechos de autor (no son contratos legales.

Capítulo 3 (Funciones) El hacer software es como cualquier otro proceso creativo, primero se estructuran las ideas y después el mensaje, hasta que se lea bien. El primer borrador puede estar desorganizado, pero se retoca y se mejora hasta tener la forma adecuada. Deben ser de tamaño reducido (máximo de 20 lineas) Sangrado (o anidado) de máximo 2 niveles, de lo contrario dificulta la lectura Hacen algo o responden algo, no ambas cosas (cambia el estado de una estructura/objeto o devuelve información del mismo, hacer ambas causa confusión) Hacer una sola cosa Solo DEBEN hacer una cosa, hacerlo bien y debe ser lo único que hagan Las funciones que hacen una sola cosa no se pueden dividir en secciones Las funciones hacen una cosa si sus instrucciones están en el mismo nivel de abstracción El código se debería poder leer como un texto (de arriba a abajo); El primer párrafo P0 describe en un nivel de abstracción, el segundo párrafo P1 detalla la abstracción de la primera instrucción del párrafo anterior (P0) y así sucesivamente, de manera que cada uno describe el nivel de abstracción, mientras hace referencia a los párrafos posteriores del siguiente nivel Usar nombres descriptivos Cuanto más reducida y concreta sea una función, más sencillo será elegir un nombre descriptivo Un nombre descriptivo extenso es mejor que uno breve pero enigmático No tema dedicar tiempo a elegir un buen nombre; pruebe con varios nombres y lea el código con todos ellos hasta encontrar uno lo bastante descriptivo No es extraño que la búsqueda de nombres descriptivos genere una reestructuración favorable Use las mismas frases, sustantivos y verbos para los módulos Argumentos de funciones El número ideal de argumentos para una función es 0, después 1 y 2 Siempre que sea posible evite 3 argumentos Más de 3 argumentos requiere una justificación especial y NO es muy habitual Son más complicados desde el punto de vista de pruebas; tener que probar todas las permutaciones de valores en los argumentos es titánico en comparación con una función sin argumentos o con 1 argumento Los argumentos de salida son mucho más difíciles de entender que los de entrada; antes de la programación orientada a objetos, los argumentos de salida eran necesarios.

Capítulo 2 (Nombres con sentido) Crear nombres correctos La longitud de un nombre DEBE corresponder al tamaño de su ámbito El nombre de una clase NO debe ser un verbo Métodos DEBE tener nombres de verbo No tener miedo a molestias por cambio de nombre de variables (siempre que sea para mejor) Revelan intenciones ¿Por qué existe? ¿Qué hace? ¿Cómo se usa? Si un nombre requiere un comentario, entonces no revela su cometido Evitar desinformación No usar palabras lejanas al significado que se pretende Evitar nombres con variaciones mínimas: MethodUsedForHandlingOfStrings MethodUsedForEfficientStorageOfStrings Distinciones con sentido NO crear código solo para compilador/intérprete Nombres con series numéricas (a1, a2) no son intencionados, desinforman Palabras adicionales son redundantes (a, an, the, variable, info, data, table, NameString son ejemplos) // Son nombres distintos pero con el mismo significado class Product class ProductInfo class ProductData Pronunciables Usar nombres pronunciables (a los humanos se nos dan las palabras, si no lo puede pronunciar no lo puede explicar) Buscables Nombres de una letra y constantes numéricas NO son fáciles de localizar Evitar codificaciones Al codificar tipos o ámbitos en un nombre se dificulta la decodificación NO es razonable que nuevos empleados tengan que aprender otro lenguaje de codificación además del código a trabajar.