NOTA: Traducción de Capítulo 1 Frederick P. Brooks, The Mythical Man-Month, Chapter 1, Addison-Wesley, 1975.

Frederick P. Brooks murió este 17 de noviembre.  The Mythical Man-Month fue uno de primeros libros que leí de Ingeniería de Software. Mucho de estos conceptos siguen vigentes hoy, 45 años después.

Esta traducción es un homenaje a Brooks.

Seguir leyendo

Como desarrolladores a veces necesitamos alguna información, el valor de una variable, los parámetros que llegan a un hook, o simplemente saber si el flujo pasó por cierta parte del código. Por eso hoy te enseño a hacer Debug con Woocommerce.

La documentación de Woocommerce lo explica. Pero yo te ayudo a entenderlo.

ALERTA: El contenido está dirigido a programadores. El código mal implementado puede afectar a tu Tienda.

Empecemos por una función:

wc_get_logger()

Primero veamos el significado de Log. Yo lo traduzco como bitácora o registro. Es un lugar donde vas guardando información de eventos. Normalmente incluyendo el tiempo en que sucedieron.

Woocommerce ya viene con un visor de logs. Para acceder al visor la ruta desde wp-admin es: WordPress Dashboard > WooCommerce > Status > Logs

Como puedes ver hay varios logs. Uno de ellos es el mío. Esto es posible con lo que te explico en este post.

En cualquier lugar de tu código donde necesites guardar informaicón, estos son los pasos:

Paso 1.- Llamar la función wc_get_logger():

$logger = wc_get_logger();
$context = array( 'source' => 'udev-log' );

Paso 2.- Llamar la función que escribe en el log:

$logger->debug( 'Información detallada para Debug', $context );
$logger->info( 'Eventos relevantes', $context );
$logger->notice( 'Eventos normales', $context );
$logger->warning( 'Eventos excepcionales, pero no son errores', $context );
$logger->error( 'Errorre que neceitan atención', $context );
$logger->critical( 'Condiciones críticas', $context );
$logger->alert( 'Acción inmediata necesaria', $context );
$logger->emergency( 'Houston, llamando Houston', $context );

La diferencia entre ellas es la clasificación de la información. El primer parámetros en un string con el contenido a guardar en el log. El segundo es opcional, si quieres tener tu propio log. El segundo es un array, que puede incluir información que quieras pasar al logger. Esto es útil en dos situaciones: cuando quieres un log exclusivo para ti, y cuando creas tu propio logger y necesitas información adicional. Pero eso es otro tema.

Tu propio log.

El parámetro source lleva el nombre del log. Bueno como ves en la imagen el nombre del log incluye el nombre que le pasas. En mi caso le paso como valor ‘udev-log’ y generó un log: udev-log-2022-09-04-4b3c742ca243b2f0dab1393322ec142f.log, por lo que se ve que incluye la fecha y un identificador único.

Según la documentación esos logs se borran después de 30 días.

En mi caso yo prefiero llamar directamente la función wc_get_logger():

wc_get_logger()->debug('Info de debug');

Y cuando quiero crear mi propio log:

wc_get_logger()->debug('Info de debug', array('source' = 'udev-log'));

Si te gustó este post, mira los temas de Temas de Curso Desarrollo en Woocommerce – Urano Dev/ y suscríbete a mi lista de espera.

Ya se veía venir. No es sorpresa, pero es algo que no había pasado, hasta que pasó. WP dej+o de crecer, y luego perdió participación.

Algunos expertos lo atribuyen a la falta de crecimiento funcional de la plataforma, parece que los años que llevan desarrollando Gutenberg, han afectado en la velocidad de otras funcionalidades.

El caso más sonado es la velocidad, comparada con los competidores.

En Octubre 12 del 2021 se propuso formar un equipo que se dedicar al tema del performance. Hasta antes de esta fecha, el performance se ha optimizado con plugins, pero muchos pensamos que debería estar en el core de WP. El equipo ya ha entregado una versión de mejoras.

Es decir, la arquitectura debería estar optimizada para el performance.

El performance es el diferenciador principal de la competencia: Wix, Shopify, … y quien se te ocurra.

Esto tenía que pasara algún día. Yo creo que en un año WP retomará el crecimiento. Actualmente ya se tienen mejoras, en forma de plugin. Conforme sea posible la funcionalidad de integrará en eel core.

Una vez solucionado el tema del performance, hay otro tema que puede frenar o restar el crecimiento, y tiene que ver con la participación de desarrolladores. Es sabido que es difícil el participar en el desarrollo del core.

Hasta hace poco cualquier propuesta de mejora se tomaba como una ofensa a los desarrolladores, al equipo de WP, en lugar de verlo como una oportunidad de mejora, se atacaba a quien proponía nuevas formas de hacer las cosas. Es sabido de varios casos que proponen mejoras, y por simple opinión se rechazan, sin análisis técnico. Simplemente al comité no le parece, y ya. No se aceptan.

Creo que eso está cambiando y espero que pronto sea más amigable el proceso de onboarding para nuevos desarrolladores.