Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español In order to explore the concepts from the first post in a more practical fashion, today we will look at a step by step guide for creating a C programming language project built and tested using Autotools . 1: Application entry point This will be src/main.c . It's typical to have a src directory for source code, because when the project grows, it will probably need other top-level directories such as man for man pages , data for data files, and so on. src/main.c #include <config.h> #include <stdio.h> int main (void) { puts("Hello World!"); puts("This is " PACKAGE_STRING "."); return 0; } Including config.h is necessary because that's where PACKAGE_STRING will be defined. In turn, config.h will be generated by Autotools. 2: Top-level configure.ac file All configure.ac files contain Autoconf instructions which control the generation of the configure script. These

Versión en inglés / English version Para bajar a tierra los conceptos del primer post , hoy seguiremos paso a paso la creación de un proyecto en lenguaje C usando Autotools como sistema de build . 1: Punto de entrada En primer lugar, se crea el punto de entrada del programa, src/main.c . Es típico tener un directorio src para el código fuente, ya que al evolucionar el proyecto, probablemente se agreguen directorios como man para páginas de ayuda ( man pages ), data para archivos de datos, etc. src/main.c #include <config.h> #include <stdio.h> int main (void) { puts("Hello World!"); puts("This is " PACKAGE_STRING "."); return 0; } La inclusión de config.h viene dada porque ese archivo será generado por Autotools, y es donde estará definido PACKAGE_STRING. 2: Archivo configure.ac raíz Los archivos configure.ac contienen instrucciones Autoconf que controlan la generación del script configure . Dichas instru

Spanish version / Versión en Español One of the advantages of pure unit testing is validating logic in isolation from external dependencies. In the case of Arduino, it's possible to test an entire sketch without a physical board and (almost) without modifying the original code. In his book "Working effectively with legacy code" , Michael Feathers introduces the concept of seams . He defines them as places in the source code where it's possible to swap out an external dependency for a fake object in order to isolate the calling code for testing purposes. In today's post, we'll walk through a concrete example of some techniques that exploit these seams. In particular, we will do this for a simple Arduino project. As a starting point, let us consider the following Wokwi project . For the sake of context, Wokwi is a website that allows users to create Arduino projects using just a web browser, without a physical board or even installing any software. Wo

Versión en inglés / English version Una gran ventaja de tener tests unitarios puros es poder validar la lógica del código de manera aislada de las dependencias externas. En el caso de Arduino, es posible probar el sketch completo sin una placa física, y además, sin modificar el código original. En el libro "Working effectively with legacy code" , Michael Feathers habla del concepto de seam (costura). Para Feathers, un seam es un punto del código donde se puede reemplazar una dependencia externa con un objeto falso a fin de poder ejecutar el código en un ambiente de test. En el post de hoy, se verá un ejemplo concreto de técnicas para aprovechar estos seams . En particular, para un proyecto Arduino sencillo. Como punto de partida, considérese el siguiente proyecto Wokwi . Contexto: Wokwi es un sitio que permite crear proyectos Arduino en un navegador web, sin necesidad de placas físicas. Permite insertar y conectar componentes virtuales, y escribir código Arduino

Spanish version / Versión en Español Who would have thought that this blog would live long enough to see a third change of syntax highlighter? Incredibly enough, Blogger is also alive and kicking. This site's administration has decided to retire highlightjs , which seems to be still alive, but has lost ground to prismjs . Obviously, it's subjective, but personally I have decided to favor Prism due to the following reasons: It managed to handle VB.NET code blocks better. Yes, I know it's not the most modern language, but we still hold some affection for it. It looks better: it's more compact, with a better color selection. It also highlights more keywords, at least for the languages we use here. It offers an extensible architecture, including a plugin system which allows, for example, adding line numbers. HighlighJS has no such feature. All of these extra features, and still Prism has a very small footprint. Without fu

Versión en inglés / English version ¿Quién habría pensado que este blog viviría lo suficiente para ver un tercer cambio de resaltador de sintaxis? Increíblemente, también Blogger sigue vivo y coleando. La administración de este sitio ha decidido jubilar a highlightjs , que parece seguir con vida, pero ha perdido terreno ante prismjs . Obviamente es una cuestión subjetiva, pero personalmente me he decantado por prism por los siguientes motivos: Logró resaltar mejor los bloques de código VB.NET. Sí, sé que no es un lenguaje muy moderno que digamos, pero lo queremos igual. Se ve mejor: más compacto y con mejor selección de colores. También destaca más palabras. Ofrece una arquitectura extensible, incluyendo plugins para, por ejemplo, agregar números de línea. HighlightJS carece de esto. Todo esto y más, con un tamaño muy pequeño. Sin más preámbulo, veamos los pasos para empezar a usar prims en Blogger: En Blogger, seleccionado

Spanish version / Versión en Español First thing first: what are GNU Autotools , and what are they used for? The moniker "GNU Autotools" refers to a collection of software packages: Autoconf , Automake and Libtool . These packages include programs aimed at standardizing and automating the build, test, release and installation processes across multiple platforms. In that sense, it shares a lot of goals and purpose with other tools such as CMake . Most of the GNU software is built using Autotools; git is a famous example. More specifically, what the Autotools do is generate configure scripts and Makefiles from certain configuration files. When generating these files, portability across different platforms is considered in order to allow the package to be built in as many different environments as possible. A user's perspective In this context, we will consider a user a person who downloaded a source tarball for some package, and wants to build it and inst

Versión en inglés / English version En primer lugar: ¿qué son las Autotools de GNU , y para qué sirven? El nombre "GNU Autotools" se refiera a una colección de paquetes de software : Autoconf , Automake y Libtool . Estos paquetes contienen programas cuyo objetivo es estandarizar y automatizar los procesos de compilación, prueba, entrega e instalación a través de distintas plataformas. En ese sentido, comparte propósito con otras herramientas como CMake . Gran parte de el software de GNU ha sido creado con Autotools; git es un ejemplo célebre. Más específicamente, lo que las Autotools hacen es generar scripts y Makefiles a partir de archivos de configuración de entrada escritos por el desarrolador. Al generar estos scripts y Makefiles , se considera la portabilidad a través de distintas plataformas a fin de que el paquete funcione en la mayor cantidad de entornos posible. La perspectiva del usuario En este contexto, se considerará al usuario como una per