Feliz añ… ¡Dame los datos!

Como viene siendo habitual hay que dedicar una entrada del blog a despedir el año y desearos lo mejor para el 2017.

Pero no nos pongamos emotivos todavía. Queda lo mejor. Analizar los datos de Google Analytics de esta y otras webs que he creado.

Un poco de historia

Como muchos sabréis ya, el blog ahora mismo funciona con WordPress, más concretamente en una Raspberry Pi 2 con Raspbian y WordPress se ejecuta sobre PHP7, con MariaDB de base de datos y nginx de servidor web. Antes no era así. Originalmente era un blog en Blogger muy simple. Después lo pasé a Jekyll con GitHub Pages usando un tema que cree sobre la marcha. Este tema tenía un diseño “peculiar” y tenía algunos problemas. Por eso inicié la transición a un tema nuevo basado en Material Design. Pero aquello no duró mucho, era más lento y daba más fallos. Al final decidí pasarme a WordPress y de paso comprar el dominio adrianistan.eu. Esta transición la hice en junio y hay que tenerla en cuenta ya que cambié las propiedades de Analytics en el proceso. El blog antiguo además no ha dejado de funcionar (para no romper enlaces) y lo tenéis en http://adrianistan.eu/blog/

blog.adrianistan.eu – Muy satisfecho

El flamante nuevo blog, usando WordPress y en chupando electricidad en mi casa ha tenido 3982 sesiones con 5213 visitas a páginas.

El pico más alto corresponde al 14 de julio y es el día siguiente a la publicación del Tutorial de GnuCash, artículo que como veremos ahora sigue siendo de los más visitados. El segundo pico, ya el 21 de noviembre fue el día siguiente a la publicación del artículo sobre Iron, un framework web escrito en Rust.

Respecto a los idiomas, nada raro, todas las variaciones de español que existen, algunos idiomas como Catalán, Gallego, Euskera o Portugués que pueden ser perfectamente de gente que entiende ambos idiomas. Inglés también está muy alto, teniendo en cuenta que es la configuración por defecto de muchas cosas tampoco es raro.

Analytics ha contabilizado accesos desde 70 países. La mayor parte del tráfico viene de España, con mucha diferencia, seguido de México y en tercer lugar Estados Unidos. En cuarto lugar Argentina. Le siguen Colombia, Venezuela, Chile, Perú, Ecuador y el top 10 lo termina Brasil. Me parece curioso, en undécimo puesto encontramos a Alemania. Y me ha sorprendido, no esperaba que estuviese tan arriba. Esta por encima de otros países latinoamericanos, supongo que esto se debe a los españoles que se han ido a trabajar a Alemania.

La mayoría de vosotros entráis con Google Chrome. En segundo lugar se posiciona Firefox. Con un porcentaje ya bastante reducido está Safari, que supongo que será sobre todo tráfico de iOS, aunque como veremos más adelante recibo más visitas desde macOS que desde iOS. Y este año hemos dado el sorpasso, el blog recibió más visitas con Edge que con Internet Explorer. Mención especial a NetNewsWire Browser, que me hizo tener que buscarlo en Google.

En sistemas operativos, primero Windows, después Android y a continuación Linux de escritorio. Esta tendencia la tengo en las otras webs y es algo que se lleva dando desde hace algún tiempo. Me sorprende que macOS posicione por encima de iOS. Se ve que cada vez hay más Macs en el mundo hispanohablante.

¿De dónde vienen las ovejas descarriadas que entran aquí?

Analytics dice que un alto porcentaje vienen de búsquedas en Google, Menéame aporta bastantes visitas, Google+ sigue trayéndome gente, Reddit también y Facebook ha empezado a traer usuarios de forma más constante. Pero lo más importante es el RSS y Feedly. Mucha gente viene a través de esos canales, lo cuál me alegra pues la gente que accede por allí suelen ser lectores que ya han decidido quedarse. El correo electrónico parece funcionar bien, aunque hay pocos suscriptores. Y me sorprende que al menos 16 personas hayan accedido al blog a través de mi perfil de Instagram. ¿En serio?

¿Y en qué corral artículo caen?

Los 3 tutoriales: CMake, WiX y GnuCash han sido muy populares. La calculadora de 4 bits lleva desde el 2013 siendo uno de los artículos más leídos siempre en mi blog.

Las conclusiones que saco es que Rust interesa, Bitcoin y Ethereum no tanto pero también. Esos dos temas van a ser importantes para este año 2017.

adrianistan.eu – El año del boom

adrianistan.eu reúne por un lado el blog hasta antes de junio, las descargas de Kovel, los complementos de Firefox y alguna cosilla más.

14889 sesiones y 12532 usuarios. El artículo de enero de 2016 titulado Cómo programar en C (en 2016) fue un absoluto éxito, llegando a la portada de Menéame. Fue además enlazado desde sitios como CyberHades o ElHacker. El artículo era una mera traducción a la que añadí un par de cosas al final. No recuerdo ahora mismo como lo encontré, pero me pareció bueno y a la vez el típico artículo que a veces pasa desapercibido. Le pedí si podía hacer la traducción y me dijo que sí. Hubo mucho debate sobre el artículo lo que además le dio repercusión.

En el mapa veo ya empiezo a ver cosas raras. España es el país líder, pero el segundo es… ¡¿Rusia?! Eso dice Analytics, pero creo que es mentira o mejor dicho, no es exactamente verdad. Esta propiedad ha recibido muchos hits desde unos dominios y mi teoría es que todos vienen de Rusia y son en realidad bots. El tercer país es Estados Unidos, seguido de México, Alemania, Argentina, Francia, Colombia, Venezuela y Perú. En total se han registrado datos de 153 países. Puntos extra para los que han entrado desde la isla de Mayotte y la isla de Guam.

Aquí gana Firefox, algo obvio debido a que parte del sitio está dedicado a alojar complementos de Firefox. Y aquí Rusia me vuelve a intrigar. YaBrowser es un navegador ruso y tiene un porcentaje considerable de visitas. Muy extraño todo. No aparecen en la imagen pero me han llamado la atención estos tres navegadores: Coc Coc, Dooble y PlayFreeBrowser.

Según mi teoría, site-auditor.online, rank-checker.online y monetizationking.net han estado generando tráfico falso. La verdad es que es muy intrigante. Las instalaciones de complementos siguen trayendo un buen tráfico.

Vamos con otra web.

Phaser.js Hispano – Una comunidad interesada

La web ha tenido muy buen recibimiento con gente interesada. Me da pena no poder escribir artículos para Phaser.js Hispano porque realmente hay gente que los está buscando y los necesita. Para paliar estos previsibles vacíos de contenidos he creado Gamedev Hispano, un foro donde se puede ir aportando poco a poco. El foro no ha tenido una buena acogida inicialmente, pero es un proyecto que puede tener futuro y no me voy a rendir todavía.

TucTum – Muchos usuarios desisten

TucTum es un nodo de GNU Social que te paga por la cantidad de me gustas que reciban tus publicaciones. El programa funciona pero la gente no se hace a TucTum. Entiendo que la interfaz no es tan sencilla pero el principal problema es, a mi modo de ver, que no hay gente suficiente como para retener a la gente que se va hace cuenta. Muchos se hacen cuenta y al ver que no hay nadie con quien hablar se van. No tengo nada preparado para TucTum este 2017.

Gaming on Haiku – El sitio que me plantea cambios

No voy a hablar mucho de Gaming on Haiku (2550 sesiones y 1933 usuarios) pero este sitio me ha hecho plantearme cosas. Primero, fue el lugar donde probé WordPress antes de usarlo en este blog. Además ha sido un sitio en inglés y mi impresión ha sido que con mucho menos esfuerzo he logrado mucha más repercusión. Enlaces en muchas más páginas y mayor interacción social. Pero también es un sitio de nicho, mucho más fácil de categorizar que este blog. La pregunta es: ¿qué parte de su éxito corresponde al idioma y qué parte a la temática de la página?

Llegados a este punto, ¿merece la pena convertir Adrianistán en un blog en inglés? Sin duda, algo que me voy a plantear muy seriamente en este 2017, por supuesto, vuestras opiniones me importan y podéis decir que pensáis al respecto.

¿Cómo programar en C (en 2016)?

Este artículo es una traducción del artículo How to C in 2016. Todo el contenido aparece originalmente en aquel artículo, yo solo me he limitado a traducirlo.

c

La primera regla de C es no escribir en C si puedes evitarlo.

Si te ves obligado a escribir en C, deberías seguir las reglas modernas.

C ha estado con nosotros desde principios de los 70. La gente a “aprendido C” en numerosos puntos de su evolución, pero el conocimiento normalmente se para después de aprender. Así pues todo el mundo piensa diferente sobre C según el año en que empezaron a aprenderlo.

Es importante no quedarse paralizado en las “cosas que aprendí en los 80/90” cuando programas en C.

Esta página asume que estás en una plataforma moderna, con estándares modernos y no tienes que mantener una compatibilidad con sistemas antiguos muy elevada. No debemos estar atados a estándares anticuados solo porque algunas compañías rechacen actualizar sistemas con más de 20 años de antigüedad.

Preliminar

Standard C99 (C99 significa “Estándar C de 1999”; C11 significa “Estándar C de 2011”, así que C11 > C99)

  • clang, por defecto
    • C99 es la implementación de C por defecto en clang, no necesita opciones extra
    • Sin embargo esta implementación no es realmente estándar. Si quieres forzar el estándar, usa -std=c99
    • Si quieres usar C11, debes especificar -std=c11
    • clang compila el código fuente más rápidamente que gcc
  • gcc necesita que especifiques -std=c99 o -std=c11
    • gcc compila más lentamente pero a veces genera ejecutables más rápidos
    • gcc-5 establece por defecto -std=gnu11, así que debes seguir especificando una versión estándar c99 o c11.

Optimizaciones

  • -O2, -O3
    • generalmente querrás -O2, pero algunas veces querrás -O3. Prueba tu código con ambos niveles (y entre distintos compiladores) y mantente con los ejecutables más eficientes y rápidos.
  • -Os
    • -Os ayuda si te preocupa la eficiencia de la caché (que debería)

Advertencias

  • -Wall -Wextra -pedantic
    • las nuevas versiones de los compiladores tienen -Wpedantic, pero todavía aceptan el antiguo -pedantic por cuestiones de compatibilidad.
    • durante las pruebas deberías añadir -Werror y -Wshadow en todas tus plataformas
    • puede ser peliagudo enviar a producción con -Werror porque cada plataforma y cada compilador y cada librería pueden emitir distintas advertencias. Probablemente no querrás terminar la compilación entera de un usuario porque su versión de GCC en una plataforma que nunca habías visto se queja de manera nueva y sorprendente.
    • algunas opciones más sofisticadas son -Wstrict-overflow -fno-strict-aliasing
    • especifica -fno-strict-aliasing o estate seguro de que solo accedes a los objetos con el tipo que tuvieron en su definición. Como mucho código en C ya existente se salta lo último es mucho más seguro usar -fno-strict-aliasing particularmente si no controlas todo el código que debes compilar.
    • ahora mismo, clang reporta alguna sintaxis válida como advertencia, así que debes añadir -Wno-missing-field-initializers
    • GCC resolvió este problema después de GCC 4.7

Compilando

  • Unidades de compilación
    • La manera más común de compilar proyectos en C es generar un fichero objeto de cada fichero fuente y unirlo todos al final. Este procedimiento es muy bueno para el desarrollo incremental, pero no lo es para el rendimiento y la optimización. El compilador no puede detectar optimizaciones entre archivos con este método.
  • LTO – Link Time Optimization
    • LTO arregla el problema de las unidades de compilación generando además una representación intermedia que puede ser sujeta de optimizaciones entre archivos. Este sistema ralentiza el tiempo de enlazado significativamente pero make -j puede ayudar.
    • clang LTO (guía)
    • gcc LTO
    • Ahora mismo, 2016, clang y gcc soportan LTO simplemente añadiendo -flto en las opciones tanto de compilación como de enlazado.
    • LTO todavía necesita asentarse. A veces, si tu programa tiene código que no usas directamente pero alguna librería sí, LTO puede borrarlo, porque detecta que en tu código no se hace nunca una llamada a esa función.

Arquitectura

  • -march=native
    • Le da al compilador permiso para usar todas las características de tu CPU
    • otra vez, compara el funcionamiento con los distintos tipos de optimización y que no tengan efectos secundarios.
  • msse2 y -msse4.2 pueden ser útiles si necesitas características que no están disponibles en el sistema desde el que compilas.

Escribiendo código

Tipos

Si te encuentras escribiendo char o int o short o long o unsigned, lo estás haciendo mal.

Para los programas modernos deberías incluir #include <stdint.h> y usar los tipos estándar.

Los tipos estándar comunes son:

  • int8_t, int16_t, int32_t, int64_t – enteros con signo
  • uint8_t, uint16_t, uint32_t, uint64_t – enteros sin signo
  • float – coma flotante de 32 bits
  • double – coma flotante de 64 bits

Te darás cuenta que ya no tenemos char. char está malinterpretado en C.

Los desarrolladores han abusado de char para representar un byte incluso cuando hacen operaciones sin signo. Es mucho más limpio usar uint8_t para representar un único byte sin signo y uint8_t * para representar una secuencia de bytes sin signo.

Una excepción a nunca-char

El único uso aceptable de char en 2016 es si una API ya existente necesita char (por ejemplo, strncat, printf,…) o si estás inicializando una cadena de texto de solo lectura (const char *hello = "hello";) porque el tipo de C para cadenas de texto sigue siendo char *

Además, en C11 tenemos soporte Unicode nativo y el tipo para cadenas UTF-8 sigue siendo char * incluso para secuencias multibyte como const char *abcgrr = u8"abc?";.

El signo

A estas alturas de la película no deberías escribir unsigned nunca en tu código. Podemos escribir sin usar la fea convención de C para tipos multi-palabra que restan legibilidad. ¿Quién quiere escribir unsigned long long int cuando puede escribir uint64_t? Los tipos de <stdint.h> son más explícitos, más exactos en su significado y son más compactos en su escritura y su legibilidad.

Pero podrías decir, “¡Necesito hacer cast a punteros a long para realizar aritmética de punteros sucia!”

Podrías decirlo. Pero estás equivocado.

El tipo correcto para aritmética de punteros es uintptr_t definido en <stddef.h>.

En vez de:

Usa:

Además:

Tipos dependientes del sistema

Sigues argumentando, “¡en una plataforma de 32 bits quiero longs de 32 bits y en una de 64 bits quiero longs de 64 bits!”

Si nos saltamos la idea de que estás introduciendo deliberadamente código que dificulta la comprensión del código al tener tamaños distintos dependiendo de la plataforma, aún no tendrías necesidad de usar long.

En estas situaciones debes usar intptr_t que se define según la plataforma en que te encuentres.

En plataformas de 32 bits, intptr_t es int32_t.

En plataformas de 64 bits, intptr_t es int64_t.

intprt_t también tiene una versión sin signo uintptr_t.

Para almacenar diferencias entre punteros, tenemos el ptrdiff_t.

Máxima capacidad

¿Quieres tener el entero con mayor capacidad de tu sistema?

La gente tiene a usar el más grande que conozca, en este caso uint64_t nos podrá almacenar el número más grande. Pero hay una manera más correcta de garantizar que podrá contener cualquier otro valor que se esté utilizando en el programa.

El contenedor más seguro para cualquier entero es intmax_t (también uintmax_t). Puedes asignar cualquier entero con signo a intmax_t sin pérdida de precisión. Puedes asignar cualquier entero sin signo a uintmax_t sin pérdida de precisión.

Ese otro tipo

Otro tipo que depende del sistema y es usado comúnmente es size_t.

size_t se define como “un entero capaz de contener el mayor tamaño de memoria disponible”.

En el lado práctico, size_t es el tipo que devuelve el operador sizeof.

En cualquier caso, la definición de size_t es prácticamente la misma que la de uintptr_t en todas las plataformas modernas.

También existe ssize_t que es size_t con signo y que devuelve -1 en caso de error. (Nota: ssize_t es POSIX así que no se aplica esto en Windows).

Así que, ¿debería usar sisze_t para aceptar tamaños dependientes del sistema en mis funciones? Sí, cualquier función que acepte un número de bytes puede usar size_t.

También lo puedes usar en malloc, y ssize_t es usado en read() y write() (solo en sistemas POSIX).

Mostrando tipos

Nunca debes hacer cast para mostrar el valor de los tipos. Usa siempre los especificadores adecuados.

Estos incluyen, pero no están limitados a:

  • size_t%zu
  • ssize_t%zd
  • ptrdiff_t%td
  • valor del puntero – %p (muestra el valor en hexadecimanl, haz cast a (void *) primero)
  • los tipos de 64 bits deben usar las macros PRIu64 (sin signo) y PRId64 (con signo)
    • es imposible especificar un valor correcto multiplataforma sin la ayuda de estas macros
  • intptr_t"%" PRIdPTR
  • uintptr_t"%" PRIuPTR
  • intmax_t"%" PRIdMAX
  • uintmax_t"%" PRIuMAX

Recordar que PRI* son macros, y las macros se tienen que expandir, no pueden estar dentro de una cadena de texto. No puedes hacer:

deberías usar:

Tienes que poner el símbolo ‘%’ dentro de la cadena de texto, pero el especificador fuera.

C99 permite declaraciones de variables en cualquier sitio

Así que no hagas esto:

Aunque si tienes un bucle muy exigente (un tight loop) las declaraciones a mitad de camino pueden ralentizar el bucle.

C99 permite a los bucles for declarar los contadores en la misma línea

Así que no hagas esto

Haz esto:

La mayoría de compiladores soportan #pragma once

Así que no hagas esto:

haz esto:

#pragma once le dice al compilador que solo incluya el archivo de cabecera una vez y no necesitas escribir esas tres líneas para evitarlo manualmente. Este pragma esta soportado por todos los compiladores modernos en todas las plataformas y está recomendado por encima de nombrar manualmente las cláusulas.

Para más detalles, observa la lista de compiladores que lo soportan en pragma once

C permite la inicialización estática de arrays ya asignados memoria

Así que no hagas:

Haz esto:

C permite la inicialización estática de structs ya asignados en memoria

Así que no hagas esto:

Haz esto:

NOTA IMPORTANTE: Si tu estructura tiene padding (relleno extra para coincidir con el alineamiento del procesador, todas por defecto en GCC, __attribute__((__packed__)) para desactivar este comportamiento), el método de {0} no llenará de ceros los bits de padding. Si necesitases rellenar todo de ceros, incluido los bits de padding, deberás seguir usando memset(&localThing, 0, sizeof(localThing)).

Si necesitas reinicializar un struct puedes declarar un struct global a cero para asignar posteriormente.

C99 permite arrays de longitud variable (VLA)

Así que no hagas esto:

Haz esto:

NOTA IMPORTANTE: Los VLA suelen situarse en el stack, junto a los arrays normales. Así que si no haces arrays de 3 millones de elementos normalmente, tampoco los hagas con esta sintaxis. Estos no son listas escalables tipo Python o Ruby. Si especificas una longitud muy grande en tiempo de ejecución tu programa podría empezar a hacer cosas raras. Los VLA están bien para situaciones pequeñas, de un solo uso y no se puede confiar en que escalen correctamente.

Hay gente que considera la sintaxis de VLA un antipatrón puesto que puede cerrar tu programa fácilmente.

NOTA: Debes estar seguro que arrayLength tiene un tamaño adecuado (menos de un par de KB se te darán para VLA). No puede asignar arrays enormes pero en casos concretos, es mucho más sencillo usar las capacidades de C99 VLA en vez de pringarse con malloc/free.

NOTA DOBLE: como puedes ver no hay ninguna verificación de entrada al usar VLA, así que cuida mucho el uso de las VLA.

C99 permite indicar parámetros de punteros que no se solapan

Mira la palabra reservada restrict (a veces, __restrict)

Tipos de los parámetros

Si una función acepta arbitrariamente datos y longitud, no restrinjas el tipo del parámetro.

Así que no hagas:

Haz esto:

Los tipos de entrada definen la interfaz de tu código, no lo que tu código hace con esos parámetros. La interfaz del código dice “aceptar un array de bytes y una longitud”, así que no quieres restringirles usar solo uint8_t. Quizá tus usuarios quieran pasar char * o algo más inesperado.

Al declarar el tipo de entrada como void * y haciendo cast dentro de tu función, los usuarios ya no tienen que pensar en abstracciones dentro de tu librería.

Algunos lectores afirman que podría haber problemas de alineamiento con este ejemplo, pero como estamos accediendo a los bytes uno por uno no hay problema en realidad. Si por el contrario tuviéramos tipos más grandes tendríamos que vigilar posibles problemas de alineamiento, mirar Unaligned Memory Access

Parámetros de devolución

C99 nos da el poder de usar <stdbool.h> que define true como 1 y false como 0.

Para valores de éxito/error, las funciones deben devolver true o false, nunca un entero especificando manualmente 1 y 0 (o peor, 1 y -1 (¿o era 0 éxito y 1 error? ¿o era 0 éxito y -1 error?))

Si una función modifica el valor de un parámetro de entrada, no lo devuelvas, usa dobles punteros.

Así que no hagas:

Haz esto:

O incluso mejor:

Formato

El estilo del código es muy importante.

Si tu proyecto tiene una guía de formato de 50 páginas, nadie te ayudará, pero si tu código tampoco se puede leer, nadie querrá ayudarte.

La solución es usar siempre un programa para formatear el código.

El único formateador de código usable en el 2016 es clang-format. clang-format tiene los mejores ajustes por defecto y sigue en desarrollo activo.

Aquí está el script que uso para formatear mi código:

Luego lo llamo

La opción -i indica que sobrescriba los archivos con los cambios que realice, en vez de generar nuevos archivos o crear copias.

Si tienes muchos archivos, puedes hacer la operación en paralelo

Y ahora el contenido del script cleanup-tidy aquí.

clang-tidy es una herramienta de refactorización basada en reglas. Las opciones de arriba activan dos arreglos:

  • readability-braces-around-statements – fuerza a que todos los if/while/for tengan el cuerpo rodeado por llaves.
    • ha sido un error que C permitiese las llaves opcionales. Son causa de muchos errores, sobre todo al mantener el código con el tiempo, así que aunque el compilador te lo acepte, no dejes que ocurra.
  • misc-macro-parentheses – añade automáticamente paréntesis alrededor de los parámetros usados en una macro.

clang-tidy es genial cuando funciona, pero para código complejo puede trabarse. Además, clang-tidy no formatea, así que necesitarás llamar a clang-format para formatear y alinear las nuevas llaves y demás cosas.

Legibilidad

Comentarios

Comentarios con sentido, dentro del código, no muy extensos.

Estructura de archivos

Intenta no tener archivos de más de 1000 líneas (1500 como mucho)

Otros detalles

Nunca uses malloc

Usa siempre calloc. No hay penalización de rendimiento por tener la memoria limpia, llena de ceros.

Los lectores han informado de un par de cosas:

  • calloc sí tiene un impacto en el rendimiento en asignaciones enormes
  • calloc sí tiene un impacto en el rendimiento en plataformas extrañas (sistemas empotrados, videoconsolas, hardware de 30 años de antigüedad, …)
  • una buena razón para no usar malloc() es que no puede comprobar si hay un desbordamiento y es un potencial fallo de seguridad

Todos son buenos puntos, razón por la que siempre debes probar el funcionamiento en todos los sistemas que puedas.

Una ventaja de usar calloc() directamente es que, al contrario que malloc(), calloc() puede comprobar un desbordamiento porque suma todo el tamaño necesario antes de que lo pida.

Algunas referencias al uso de calloc() se pueden encontrar aquí:

Sigo recomendando usar siempre calloc() para la mayoría de escenarios en 2016.

Nunca uses memset (si puedes evitarlo)

Nunca hagas memset(ptr, 0, len) cuando puedes inicializar una estructura (o un array) con {0}.

Generics en C11

C11 ha añadido los Generics. Funcionan como un switch, que distingue entre los tipos y dependiendo del valor que se le de devuelve una u otra cosa. Por ejemplo: