Tutorial de Neon – Combina Node.js con Rust

Hoy en día muchas webs se diseñan con Node.js. Es una solución fantástica para respuestas rápidas pero numerosos benchmarks han demostrado que su rendimiento empeora en respuestas complejas. Estos mismos benchmarks recomiendan usar Java o .NET si preveemos que nuestra aplicación web va a generar respuestas complejas. Sin embargo renunciar a las ventajas de Node.js no es del agrado de muchos. Afortunadamente hay otra solución, usar Rust. Todo ello gracias a Neon.

Con Neon podemos generar módulos para Node.js que son escritos y compilados en Rust con las ventajas que supone desde un punto de vista de rendimiento y con la certeza de que en Rust la seguridad está garantizada.

Usando Neon puedes desarrollar tu aplicación en Node.js y si alguna parte tiene problemas de rendimiento sustituirla por su equivalente en Rust. Para el ejemplo voy a hacer un módulo de Markdown.

Instalando Neon

En primer lugar instalamos la herramienta de Neon desde npm.

npm install -g neon-cli

Una vez esté instalado podemos usar la herramienta de Neon para construir un esqueleto de módulo. Este esqueleto tendrá dos partes, un punto de entrada para Node.js y otro para Rust.

neon new PROYECTO

Hacemos un npm install como nos indica. Esto no solo obtendrá dependencias de Node.js sino que también se encargará de compilar el código nativo en Rust.

El código Node.js

Nuestro módulo contiene un archivo de Node.js que sirve de punto de entrada. Allí lo único que se debe hacer es cargar el módulo en Rust y hacer de pegamento. Puede ser algo tan simple como esto:

var addon = require("../native");

module.exports = addon; // se exportan todos los métodos del módulo nativo

Aunque si queremos añadir un tratamiento específico también es posible.

var addon = require("../native");

module.exports = {
    render: function(str){
        return addon.render(str);
    }
}

El código en Rust

Nos dirigimos ahora al archivo native/src/lib.rs. Ahí definimos los métodos nativos que va a tener el módulo. Lo hacemos a través de la macro register_module!.

register_module!(m,{
    m.export("render",render)
});

Ahora vamos a implementar la función render, que toma el texto en Markdown y lo devuelve en HTML.

fn render(call: Call) -> JsResult<JsString> {
    let scope = call.scope; // obtener el contexto
    let md: Handle<JsString> = try!(try!(call.arguments.require(scope,0)).check::<JsString>()); // obtener primer argumento como JsString. aquí puede hacerse tratamiento de fallos
    let string = md.value(); // Pasar JsString a String
    let html: String = markdown::to_html(&string); // usamos la crate markdown para renderizar a html
    Ok(JsString::new(scope, &html).unwrap()) // devolvemos un JsString con el contenido del HTML
}

Las funciones que interactuan con Node deben devolver un JsResult de un tipo JsXXX, por ejemplo, JsString, JsUndefined o JsInteger. Siempre aceptan un argumento llamado de tipo Call que nos da toda la información necesaria y que podemos usar para sacar argumentos. El scope o contexto es muy importante y lo deberemos usar en las funciones que interactúen con Node.

Código completo del fichero Rust

#[macro_use]
extern crate neon;
extern crate markdown;

use neon::vm::{Call, JsResult};
use neon::js::JsString;
use neon::mem::Handle;

fn render(call: Call) -> JsResult<JsString> {
    let scope = call.scope;
    let md: Handle<JsString> = try!(try!(call.arguments.require(scope,0)).check::<JsString>());
    let string = md.value();
    let html: String = markdown::to_html(&string);
    Ok(JsString::new(scope, &html).unwrap())
}

register_module!(m, {
    m.export("render", render)
});

Y no te olvides de añadir la dependencia markdown al fichero Cargo.toml.

Probándolo

Es muy fácil probarlo. Con el REPL de Node podemos probar partes del módulo antes de publicarlo a npm.

Para abrir el REPL ejecuta Node sin argumentos

node

E introduce línea por línea lo que quieras probar:

var md = require("./");
md.render("__Esto es Markdown__");

Verás el resultado por la pantalla:

Ahora que ya sabemos que funciona podemos publicarlo a npm si queremos con:

npm publish

Aunque recuerda revisar antes el fichero package.json para especificar la licencia y la descripción. Una vez esté publicado su uso en un nuevo proyecto será muy sencillo y de forma transparente se compilará el código nativo.

var md = require("rust-markdown");
var http = require('http');
var fs = require("fs");

var server = http.createServer((req, res) => {
  fs.readFile("index.md","utf-8",function(err,data){
     var html = md.render(data);
     res.statusCode = 200;
     res.setHeader('Content-Type', 'text/html');
     res.end(html);
  });
});

server.listen(8080, "127.0.0.1", () => {
  console.log("Server running");
});



 

 

loading...

Tutorial de Piston, programa juegos en Rust

Ya he hablado de Rust varias veces en este blog. La última vez fue en el tutorial de Iron, que os recomiendo ver si os interesa el tema del desarrollo web backend.

Hoy vamos a hablar de Piston. Piston es una de las librerías más antiguas del ecosistema Rust. Surgida cuando todavía no existía Cargo, esta librería está pensada para el desarrollo de juegos. No es la única que existe en Rust pero sí la más conocida. Piston es una librería que te enseñará Rust de la mejor forma. Y ahora quiero disculparme, porque Piston no es una librería, son un montón, pero eso lo veremos enseguida. En primer lugar creamos un proyecto nuevo con Cargo.

cargo new --bin ejemplo_piston
cd ejemplo_piston

Ahora abrimos el archivo Cargo.toml, vamos a añadir las dependencias necesarias. Las dependencias en Piston son un poco complicadas, veamos:

  • Existen las dependencias core, implementan la API fundamental pero no pueden usarse por separado, son window, input y event_loop. Se usan a través de piston.
  • Los backends de window, existen actualmente 3 backends: glutin, glfw, sdl2. Se importan manualmente.
  • Graphics, una API 2D, no presente en core, pero al igual que las dependencias core necesita un backend.
  • Los backends de graphics son varios: opengl, gfx y glium.
  • Existe una dependencia que nos deja todo montado, piston_window. Esta trae por defecto el core de Piston, glutin, graphics y gfx.
  • Luego existen dependencias extra, como por ejemplo para cargar texturas, estas las podremos ir añadiendo según las necesite el proyecto.

Para simplificar añadimos piston_window únicamente:

 

[package]
name = "piston_example"
version = "0.1.0"
authors = ["Adrián Arroyo Calle"]

[dependencies]
piston_window = "0.59.0"

 

Ahora abrimos el archivo main.rs. Añadimos la crate de piston_window y los módulos que vamos a usar.

extern crate piston_window;

use piston_window::*;
use std::path::Path;

 

Así mismo definimos un par de cosas para el resto del programa, la versión de OpenGL que usará Piston internamente y una estructura para guardar los movimientos de teclado.

const OPENGL: OpenGL = OpenGL::V3_1;

struct Movement{
    up: bool,
    down: bool,
    left: bool,
    right: bool
}

 

En la función main podemos crear la ventana, especificando título y tamaño. Más opciones como V-Sync, pantalla completa y demás también están disponibles.

fn main() {

    let mut window: PistonWindow = WindowSettings::new("Piston - Adrianistan",[640,480])
        .exit_on_esc(true)
        .opengl(OPENGL)
        .build()
        .unwrap();

 

Ahora cargamos la tipografía Sinkin Sans, que vamos a usar para dibujar texto en pantalla. Como hay dos posibles localizaciones comprobamos esos dos lugares antes de salir del programa si no se consigue cargar la fuente.

    let mut glyphs = Glyphs::new(Path::new("SinkinSans.ttf"),window.factory.clone()).unwrap_or_else(|_|{
        let glyphs = Glyphs::new(Path::new("target/debug/SinkinSans.ttf"),window.factory.clone()).unwrap_or_else(|_|{
            panic!("Failed to open the font file. Check that SinkinSans.tff is in the folder");
        });
        glyphs
    });

 

Inicializamos la estructura de movimientos, generamos las dimensiones iniciales del rectángulo (que será un cuadrado en este caso), su color y la posición del ratón.

    let mut mov = Movement{
        up: false,
        down: false,
        left: false,
        right: false
    };

    let mut dims = rectangle::square(50.0,50.0,100.0);
    let mut rect_color = color::BLACK;

    let mut mc: [f64; 2] = [0.0,0.0];

 

Ahora viene la parte importante, el bucle de eventos. El bucle va a funcionar infinitamente generando eventos por el camino (pueden ser eventos de inactividad también). Usamos la función draw_2d para dibujar en 2D. Hay dos maneras de dibujar un rectángulo, en primer lugar tenemos la forma abreviada y en segundo lugar una más completa que permite más opciones. Por último dibujamos el texto usando la fuente y realizando una transformación para que no quede el texto en la posición 0,0.

 while let Some(e) = window.next() {
        window.draw_2d(&e, |c, g| {
            clear([0.5, 0.5, 0.5, 1.0], g);
            rectangle([1.0, 0.0, 0.0, 1.0], // color rojo, rgba
                        [0.0, 0.0, 100.0, 100.0], // dimensiones
                        c.transform, g); // transormacion y donde se va a dibujar

            let rect = Rectangle::new(rect_color);
            rect.draw(dims,&c.draw_state,c.transform,g);
            text(color::BLACK,18,"¡Saludos desde Piston!",&mut glyphs,c.transform.trans(100.0,200.0),g); // aplicamos una transormacion, movemos las X 100 y las Y 200
        });

 

A continuación vamos a tratar cada evento de forma independiente, como todos los métodos devuelven Option, hemos de usar esta sintaxis con Some. En primer lugar tenemos un UpdateEvent, que básicamente nos informa del tiempo delta transcurrido. Recomiendo usar este evento para realizar los cambios en las geometrías, en este caso para mover el rectángulo.

if let Some(upd_args) = e.update_args() {
            let dt = upd_args.dt;
            
                if mov.right {
                    dims[0] += dt*100.0;
                }
                if mov.left {
                    dims[0] -= dt*100.0;
                }
                if mov.up {
                    dims[1] -= dt*100.0;
                }
                if mov.down {
                    dims[1] += dt*100.0;
                }
        }

Los siguientes dos eventos son opuestos, uno se activa cuando pulsamos una tecla y el otro cuando la soltamos. Comprobamos la tecla y modificamos la estructura movement en consecuencia.

if let Some(Button::Keyboard(key)) = e.press_args() {
            if key == Key::W {
                mov.up = true;
            }
            if key == Key::S {
                mov.down = true;
            }
            if key == Key::A {
                mov.left = true;
            }
            if key == Key::D {
                mov.right = true;
            }
        };
        if let Some(Button::Keyboard(key)) = e.release_args() {
            if key == Key::W {
                mov.up = false;
            }
            if key == Key::S {
                mov.down = false;
            }
            if key == Key::A {
                mov.left = false;
            }
            if key == Key::D {
                mov.right = false;
            }
        };

Por último, si queremos comprobar clicks del ratón hacemos algo similar. He añadido código para que cambio el color del rectángulo si pulsamos sobre él.

if let Some(Button::Mouse(mb)) = e.release_args() {
            if mb == MouseButton::Left {
                let x = mc[0];
                let y = mc[1];
                if x > dims[0] && x < dims[0] + dims[2] { if y > dims[1] && y < dims[1] + dims[3] {
                        rect_color = if rect_color == [1.0,0.0,0.0,0.7]{
                            [0.0,1.0,0.0,0.7]
                        } else if rect_color == [0.0,1.0,0.0,0.7] {
                            [0.0,0.0,1.0,0.7]
                        } else{
                            [1.0,0.0,0.0,0.7]
                        }
                    }
                }
                
            }
        }

A continuación un pequeño evento que guarda la última posición del ratón.

        if let Some(mouse_cursor) = e.mouse_cursor_args() {
            mc = mouse_cursor;
        }
    }
}

 

Y con esto ya tenemos hecho un ejemplo en Piston.

Si quieres tener un ejecutable para Windows sin que se muestre primero la consola debes compilar la versión que vas a distribuir con unos parámetros especiales. Si usas Rust con GCC usarás:

cargo rustc --release -- -Clink-args="-Wl,--subsystem,windows"

Si por el contrario usas Visual C++:

cargo rustc --release -- -Clink-args="/SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup"

 

Piston todavía se encuentra en fuerte desarrollo, en la API estan documentados todos los métodos pero aun así muchas veces no se sabe como hacer ciertas cosas. Piston soporta además 3D, contando con una librería especializada en vóxels. Veremos como evoluciona esta librería.

9front, un fork de Plan9 desarrollado por dementes

Hace poco, por IRC conocí la existencia de este sistema operativo, 9front, derivado de Plan9. En principio pensé que sería un fork normal y corriente. Cuando entré en su página descubrí sin embargo que era algo completamente distinto.

La 9community, formada por Henry Kissinger y Hillary Clinton, promotores del nuevo orden mundial

Su página web está cargada de minimalismo y memes, la gran mayoría de ellos inspirados en la guerra fría. Al entrar respiramos la esencia de 9front. Por ejemplo, el servidor web de la página es werc. Werc se define a sí mismo como el anti-framework anti-web. Sin bases de datos, solo ficheros y ¡programado en rc! Rc es un componente fundamental de 9front, una piedra angular. Se trata del lenguaje de shell de 9front. El equivalente en Linux sería Bash.

Werc es solo una de las cosas que acoge bajo su paraguas la organización Cat-V (de System-V, marcándose un chiste Unix de cuidado). El lema de Cat-V, Considered harmful (considerado peligroso) nos alerta de que encontraremos contenido que ha sido ajeno para la mayoría de la población. ¿Realmente estamos entrando en Cat-V en la iluminación de Internet? ¿Es entrar en Cat-V un equivalente moderno a salir de la cueva de Platón?

Algunos proyectos de Cat-V son:

  • 9P, un sistema de archivos distribuido. Es usado por 9front.
  • Acme, un editor de texto hecho por Rob Pike
  • Sam, otro editor de texto, también de Rob Pike
  • Fortune, una colección de archivos fortune de varios sistemas UNIX. Parémonos ante este fortune etiquetado dentro de OpenBSD:
(1) Alexander the Great was a great general.
(2) Great generals are forewarned.
(3) Forewarned is forearmed.
(4) Four is an even number.
(5) Four is certainly an odd number of arms for a man to have.
(6) The only number that is both even and odd is infinity.

Therefore, Alexander the Great had an infinite number of arms.

Corramos un tupido velo y sigamos.

¡La web oficial de Glenda!

Por si te lo preguntas, sí, la mascota de Go se encuentra inspirada en Glenda

El subdominio harmful está reservado para pensamientos y para expresar opiniones.

Se habla de economía, películas, periodismo, relaciones personales (de tratar con estúpidos, un artículo muy bueno), de lo políticamente correcto, de ciencia, de la seguridad post 11S, de sociedad (y para mi sorpresa contiene una opinión que yo también tengo pero que apenas he visto, el matrimonio debe ser eliminado del sistema legal de los países para pasar a ser algo cultural/religioso, similar al bautizo), se habla de software, de estándares y de palabras. Pretenden hablar de: SQL, fútbol, la Matrix, svn, postmodernismo, gnu, religión, vi, educación, apache, respeto, teoría de cuerdas, complejidad, comida ‘orgánica’, etanol, igualdad, metadata, lógica de “sentirse bien”, teoría del trabajo, …

HTTP 0.2, un intento de simplificar HTTP.

NineTimes, la web de noticias del mundo Plan9, Inferno y 9front.

Y por supuesto, un archivo de citas célebres.

Volvamos a 9front

Continué en la página de 9front, vi que tenía un Código de Conducta (algo que han introducido algunos proyectos open source pero que bajo mi punto de vista es innecesario y en algunos casos peligroso). Sin embargo en 9front no hay un código de conducta, hay varios. Cada vez que te metes en la página sale uno distinto. Y todos son muy random. Desde el credo en latín hasta una especie de receta para crear desarrolladores químicamente. La mitad son cánticos de alabanza a 9front. Yo veo en esto una sátira perfecta de lo que son algunos Códigos de Conducta.

Luego vemos para descargar las ISO, pero a estas alturas es lo que menos importa. A continuación encontramos una recopilación de webs alternativas para 9front. Hay una basada en 4chan, pero esta me gusta más:

Y llegamos a mi sección favorita, Propaganda.

Porque el boot de 9front es explosivo, nuclearmente explosivo
La comunidad 9front

Los altos mandos de 9front
The front fell off

Man es un comando muy propenso a chistes
Mothra es el navegador web de 9front
Orwell dirige NineTimes
El comando timesync no es más que una modernización de Stonehenge

Posiblemente haga una entrada seria hablando de 9front, pero es que la comunidad 9front tiene mucha tela que cortar.

Y donde dije dementes, quise decir genios. Son absolutos genios.

Un nuevo lenguaje de programación para juegos

En la inocentada sobre Rust puse un vídeo de Jonathan Blow titulado Ideas about a new programming language for games. En el vídeo, Blow analiza los problemas que presenta C++ para el desarrollo de juegos y por qué según él ni Go ni D ni Rust consiguen mejorar la situación. El lenguaje de programación perfecto para juegos debería tener las siguientes características:

  • Poca fricción
  • Placer por programar
  • Rendimiento
  • Simplicidad
  • Diseñado para buenos programadores

Con poca fricción se refiere a que la tarea de programar no debe añadir mucha complejidad para solucionar problemas que tendríamos si programásemos de la forma más simple posible. Fricción es para él RAII en C++. Fricción es la gestión de errores en Rust. Fricción se entiende como código que no añade significativamente nada pero que es necesario para un correcto funcionamiento. Fricción es rellenar papeleo de Hacienda. Muchos defensores de estas posturas argumentan que en realidad esa productividad perdida se recupera con el tiempo al reducir el número de bugs que pueden ocurrir. Blow dice que según su experiencia en juegos AAA realmente no compensa. Tardas más tiempo solventado bugs potenciales que bugs reales. Su solución no es evitar al 100% este tipo de bugs (como hace Rust) sino habilitar unas herramientas potentes que ayuden a solucionar estos bugs si alguna vez suceden.

Esto se relaciona con el placer por programar. Un lenguaje que te invite a programar, a experimentar, donde te sientas a gusto. Muchos lenguajes han perdido esa esencia. Con el tiempo muchos lenguajes se han ido complicando de forma innecesaria y se han ido volviendo pesadillas. Ruby sería el caso contrario, un lenguaje que conserva ese placer. Pero Ruby no entra en juego por razones obvias de rendimiento.

Con rendimiento básicamente dice que cualquier lenguaje que disponga de GC (recolector de basura) no es válido. Incluso Go, que tiene un GC mucho mejor que Java o la plataforma .NET no lo considera correcto.

Con simplicidad se busca legibilidad y potencia. El lenguaje debe ser uniforme, con cohesión en todos sus elementos.

Y con diseñado para buenos programadores se refiere a que el lenguaje no debe suponer que el programador es idiota e intentar corregir sus errores. Debe permitir hacer virguerías si así lo desea el programador. Rust está bien pues permite tener código unsafe. Justo lo que se necesita para hacer virguerías. Pero hace falta más trabajo en este aspecto pues supone un cambio de mentalidad.

La idea detrás de RAII es incorrecta

Mucha gente opina que RAII es una de las mejores cosas que han pasado en la programación. Muchos lenguajes presuponen RAII. D por ejemplo considera que RAII es la manera correcta de programar. Resource Acquisition Is Initialization consiste en que cada vez que vamos a acceder a un recurso tenemos que codificarlo en una clase, inicializar el recurso en un constructor y liberar el recurso en un destructor. Añades operadores para permitir copia, … Este sistema presenta una elevada fricción. Y además no funciona bien, en el sentido de que todo se acaba sobrecomplicando. Alejándose de esa simplicidad que estamos buscando.

Uno de los principales problemas de este patrón de diseño es que no existe un recurso. Es una generalización errónea de varios conceptos. Un recurso puede ser memoria, otro recurso puede ser un archivo, una entrada de teclado, etc El problema es que estos recursos son demasiado diferentes como para ser tratados con un mismo patrón de forma óptima. Mientras RAII puede ser interesante hablando de archivos, es una muy mala opción si hablamos de memoria. Porque la memoria es el recurso más importante para un programador. Se podría simplificar diciendo que un programador lo único que hace es modificar la memoria constantemente.

Pero muchos de los usos de RAII tienen que ver con las excepciones. Y a Blow tampoco le gustan las excepciones. La gestión de errores en C es pésima pero las excepciones son muy complejas. Una de las cosas más complejas que implementan los lenguajes de programación que disponen de ellas. Y la implementación de C++ más todavía. Blow se lamenta de que haya gente que siga pensando que es una buena idea. Reduce la claridad del código, complica el flujo del programa. RAII en C++ ayuda a que en caso de que se de una excepción los recursos puedan ser liberados.

No solo lo dice él, sino que enlaza el siguiente vídeo: Systematic Error Handling in C++ por Andrei Alexandrescu.


Un mejor sistema que las excepciones

Go implementa múltiples valores de retorno (al contrario que la mayoría de lenguajes derivados de C donde solo de devuelve una cosa). Go lo soporta de forma nativa. Pero Matt Newport le responde como podría hacer eso en C++11 con std::tie.

#include <iostream>;
#include <tuple>;
#include <functional>;
 
std::tuple<int, int> f()
{
    int x = 5;
    return std::make_tuple(x, 7); // return {x,7}; en C++17
}
 
int main()
{
    int a, b;
    std::tie(a, b) = f();
    std::cout << a << " " << b << "\n";
}

Rust, como Go, soporta esto de forma nativa:

fn f() -> (i32,i32) {
	(4,7)
}

fn main() -> () {
	let (a,b) = f();
	println!("A es {}, B es {}",a,b);
}

Aunque no es la manera en la que Rust maneja los errores. En su lugar posee Option y Result que en C++17 también van a ser implementados en std::optional y que es en realidad un concepto presente en Haskell.

Sintaxis exasperante

En la charla Blow sigue hablando y comenta que desde un punto de visto purista y correcto la sintaxis de punteros de C++11 es incorrecta. Que std::unique_ptr<Vector3[]> implica que quieres un Unique Ptr basado en Vector3 pero en realidad la idea correcta sería quiero un Vector3 con características de Unique Ptr. Lo mismo es aplicable para std::shared_ptr. Este tipo de punteros no deberían estar expresados de esta forma sino que deberían entrar en la sintaxis del lenguaje, por su utilidad práctica.

En Rust, el equivalente a std::unique_ptr sería Box que es el puntero más usado. El equivalente a std::shared_ptr sería Rc, no tan usado pero disponible.

Blow sigue hablando en este vídeo y en el siguiente de más errores que tiene C++, aunque de menor importancia. En todo caso, Blow sigue en el desarrollo de su compilador de Jai. C++ ha avanzado un montón y me ha llegado a sorprender que existiesen cosas como constexpr y los módulos de C++, una solución a los archivos de cabecera que son tan tediosos de escribir.

Si tenéis tiempo y sabéis inglés miráos el vídeo original. Creo que esta mucho mejor explicado que esto. Y también la respuesta de Matt Newport en la que dice que C++ SÍ es válido para todo lo que dice Blow.

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.