La simplificación de la complejidad de la arquitectura de las aplicaciones web

La nueva generación de javascripters cree que inventó justo ayer la programación web, pero resulta que hace 25 años ya se libraba la misma batalla que libran ahora, sólo que exclusivamente con LAMP. A Docker y Kubernetes no se llegó precisamente de sopetón… La solución a los problemas fue aumentar la complejidad, lo que a su vez creó nuevos problemas, esta situación y su evolución se describe en este breve artículo de Ben Johnson de lectura muy recomendable.

Asimismo, propone una solución en la que se deshace gran parte de la complejidad añadida durante más de 2 décadas. Esta solución consiste en aumentar la capacidad de un servidor en vez de aumentar el número de los mismos y emplear… ¡el denostado SQLite! (Al menos denostado para las aplicaciones web) Hoy en día Amazon, a través de AWS, ofrece servidores con 96 núcleos y cientos de gigas de RAM. En un servidor bastante más grande, pero dentro de lo que puede administrar un kernel de Linux, se ha conseguido con SQLite la friolera de 4 millones de consultas SQL por segundo con un solo hilo.

El inconveniente de SQLite, es que a diferencia de los sistemas gestores de bases de datos relacionales como MySQL u Oracle, no tiene capacidades de red, con lo que no hay replicación de los datos a otros servidores, entre otros inconvenientes, por lo que si el servidor revienta, se perdieron los datos desde la última copia de seguridad realizada. Para solucionar este problema, Ben ha creado Litestream, una herramienta que se encarga de replicar continuamente una base de datos SQLite en un Amazon S3 (un servicio de almacenamiento en la nube).

Curiosa e interesante iniciativa, que lleva el principio KISS (Keep it simple, stupid!) al extremo. A ver cómo evoluciona…

Difícilmente habrá inmunización cuando empiece el verano

En los últimos meses se ha vendido la esperanza de que una vez llegue la vacuna esta pandemia será historia, a más tardar llegado el verano, pero esta idea parece que no pasa de las buenas intenciones si hacemos un elemental cálculo matemático. A continuación, se verá el caso concreto de España pero fácilmente podrá el lector extrapolarlo a su país.

vacunas covid-19 Sigue leyendo

¿Qué representa el producto escalar?

En un artículo anterior acerca del producto escalar, se explicó detalladamente cómo se define matemáticamente esta operación. En la presente entrada se explicará qué representa realmente esta operación entre dos vectores, la noción «intuitiva» del mismo; algo imprescindible para entender qué estamos calculando realmente en otras ciencias (por ejemplo física) cuando es empleado.

Dados dos vectores, desde un punto de vista estrictamente matemático podríamos definir infinitas operaciones con ellos, por ejemplo el «producto payaso» de los vectores de n dimensiones u y v, se denota mediante u 🤡 v y se define así:

u 🤡 v = (u1·vn·|u|, u2·vn-1·|v|, u3·vn-2·|u|, …, un·v1·|v|)

Donde las coordenadas impares se multiplican por |u| y las pares por |v|.

Entonces, ¿por qué la operación conocida como producto escalar es importante? Un profesor de matemáticas podría responder a esta pregunta de sus alumnos afirmando que entenderán su importancia en la asignatura de física, donde es muy usado, pues tal vez en matemáticas no tenga un valor especial, pero esta respuesta es un tanto esquiva. La razón por la que es importante en física es precisamente por su interpretación geométrica (ergo matemática), pero esta sistemáticamente se omite, de manera que en física los alumnos deben resignarse a aplicarlo ciegamente.

La explicación a grosso modo no debería rehuirse pues no es ningún concepto especialmente complejo ni requiere de matemáticas «superiores»: el producto escalar de dos vectores, u·v, expresa «cuánto» de u «descansa» en la dirección de v, escalado al tamaño de v. (Esto ya se expresó sucintamente en el artículo anterior) Una vez expuesto esto, resulta mucho más intuitivo entender porqué en física se emplea para:

El trabajo

En la mítica representación del trabajo en Bachillerato:

trabajo en fisica

Sigue leyendo

Evolución de casos de coronavirus en España

En la anterior entrada estimé el crecimiento de casos en España a partir de un titular de un diario, en el presente se pretende hacer una estimación mejor fundamentada. En todo caso, ni en el anterior ni en el presente artículo estoy haciendo nada más que un pasatiempo, sin mayores pretensiones. Una vez aclarado que para cualquier estudio serio del tema deben consultarse fuentes oficiales, podemos empezar. En primer lugar, vamos a trabajar con los datos que proporciona el Ministerio de Sanidad del Gobierno de España:

Fecha Día Casos Ln(Casos)
24/02/20 1 4 1,3862943611
25/02/20 2 8 2,0794415417
26/02/20 3 14 2,6390573296
27/02/20 4 26 3,258096538
28/02/20 5 45 3,8066624898
29/02/20 6 59 4,0775374439
01/03/20 7 84 4,4308167988
02/03/20 8 125 4,8283137373
03/03/20 9 169 5,1298987149
04/03/20 10 228 5,429345629
05/03/20 11 282 5,6419070709
06/03/20 12 365 5,8998973536
07/03/20 13 430 6,0637852087
08/03/20 14 674 6,5132301109
09/03/20 15 1231 7,1155821262
10/03/20 16 1695 7,4354380198
11/03/20 17 2277 7,7306140661
12/03/20 18 3146 8,0538870836
13/03/20 19 5232 8,5625488931
14/03/20 20 6332 8,753371421
15/03/20 21 7844 8,9675041873
16/03/20 22 9942 9,2045234867
17/03/20 23 11178 9,3217028398
18/03/20 24 14769 9,6002856684
19/03/20 25 18077 9,802395691
20/03/20 26 20410 9,9237802558
21/03/20 27 25374 10,1414803067
22/03/20 28 28768 10,2670189373
23/03/20 29 33089 10,4069561798

Las columnas «Fecha» y «Casos» son los datos oficiales, mientras que las columnas «Día» y «Ln(Casos)» se han añadido para realizar las estimaciones. Desde los medios de comunicación se repite que el crecimiento es exponencial, algo que podemos comprobar que es cierto si hacemos una representación gráfica a partir de los datos de la tabla:

casos coronavirus españa

(1)

Sigue leyendo

Cómo probar las consultas de manipulación de datos antes de ejecutarlas en MySQL

base de datos mysql

Las instrucciones SQL de manipulación de datos o DML (Data Manipulation Language) pueden producir una grave pérdida o alteración de los datos. Un descuido en la sintaxis al escribir una orden UPDATE, por ejemplo, o cualquier otro «detalle» que pase desapercibido en ese momento pueden tener unas consecuencias completamente indeseadas para los valiosos datos. Para evitar caer en esa situación, existen dos posibilidades que no son mutuamente excluyentes. La primera, la más evidente, usar la instrucción por excelencia del DQL (Data Query Language):

SELECT

En un caso hipotético, se desea concatenar los campos del piso (adfloor) y el número (adnumber) a la dirección (address) como paso previo a la eliminación de estos. Un SELECT que adelante los resultados del UPDATE sería:

SELECT address, adnumber, adfloor,
concat(coalesce(address, ''), ' ', coalesce(adnumber, ''), ' ', coalesce(adfloor, '')) AS address_concat
FROM table;

Si los resultados son los esperados, puede lanzarse el UPDATE:

UPDATE table
SET address = concat(coalesce(address, ''), ' ', coalesce(adnumber, ''), ' ', coalesce(adfloor, ''));

La segunda, es mediante TCL (Transaction Control Language):

Transacciones

Sigue leyendo