Deprecate blog and mastodon link

17 files changed, 0 insertions, 575 deletions

diff --git a/src/content/blog/ataques-denial-wallet.md b/src/content/blog/ataques-denial-wallet.md
deleted file mode 100644
index a5f87ca..0000000
--- a/src/content/blog/ataques-denial-wallet.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: "Cuidado con los ataques Denial of Wallet"
-metaDescription: Hablamos de los ataques Denial of Wallet, que buscan encarecer la factura de servicios cloud hasta el punto de que la víctima no pueda pagarla y tenga que echar el cierre.
-publishedAt: 2024-05-01
----
-
-Cada vez más estamos viendo una nueva modalidad de ataques a la que algunos (entre los que me incluyo) han bautizado como "Denial of Wallet" o "denegación de cartera". Estos ataques consisten en atacar los servicios cloud de un individuo o empresa con el objetivo de encarecer la factura de servicios cloud, hasta el punto de que la víctima no pueda pagarla y tenga que echar el cierre.
-
-Lo vimos hace dos meses con un [cliente de Netlify](https://www.reddit.com/r/webdev/comments/1b14bty/netlify_just_sent_me_a_104k_bill_for_a_simple/) que recibió una factura de 104.000 dólares por un simple web estático. Algún "gracioso" hizo miles de peticiones a archivos pesados del sitio, y Netlify en vez de bloquearlo, las sirvió, cobrando el ancho de banda a la víctima (a precio de oro, por cierto).
-
-También lo vimos estos días con un [cliente de AWS](https://scribe.rip/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1) casi paga 1300 dólares por un bucket de S3 con un nombre lo suficientemente común para que miles de bots estuvieran intentando (por error) subir archivos. Las peticiones PUT en S3 cuestan 0,005 dólares por 1000 peticiones, y Amazon las cobra aunque no tenga éxito (en este caso, por no tener permisos).
-
-En ambos casos, la víctima no podía hacer nada para evitarlo, ya que en el caso de Netlify, no hay un límite de ancho de banda (solo de peticiones) ni se puede poner un WAF propio que bloquee peticiones maliciosas. En el caso de AWS, aunque los buckets sean privados (sin permisos salvo que te autentiques), las peticiones podían hacerse desde internet, y Amazon las cobra aunque no tengan éxito, no pudiendo tú hacer (casi) nada para evitarlo.
-
-## ¿Cómo evito un ataque como el de S3?
-
-Usando AWS, hay varias formas a implementar, que no deberían ser demaisado complicadas:
-
-1. Activar el modo "requester pays", que hace que se bloquee el acceso anónimo a los buckets, y que el coste de las peticiones PUT lo pague el que las hace, no el dueño del bucket. Si eres tú quien sube contenido a tu bucket, te costará lo mismo que antes, pero si es algún graciosillo, tendrá que autenticarse y pagar él.
-
-2. Añade un sufijo a tu bucket con caracteres aleatorios. Por ejemplo, en vez de llamarle `miempresa-aplicacion`, llámale `miempresa-aplicacion-3f4a2b1` y usa un servicio como CloudFront para servir el contenido del bucket y así evitar exponer el nombre del bucket. Así, aunque el bucket sea `miempresa-aplicacion-3f4a2b1`, la URL que se use para lectura será `d123456789.cloudfront.net` o `cdn.miempresa.com`.
-
-## Plus: cómo evitarlo en Azure
-
-Siendo usuario certificado de Azure y prefiriendo esta plataforma frente a AWS, me gustaría añadir cómo evitar un ataque similar en Azure Storage (que es más fácil, dicho sea de paso):
-
-1. En Azure puedes limitar quién puede acceder a la cuenta de almacenamiento, ya sea por rangos de IP y/o VNets. Si tu aplicación está en una VNet, puedes limitar el acceso a la cuenta de almacenamiento solo a esa VNet, evitando que alguien desde fuera pueda acceder a la cuenta de almacenamiento. Esto funciona con [Service endpoints](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview) y [Firewall y reglas de acceso](https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security).
-
-2. También puedes usar un Private Endpoint para lograr lo anterior de forma más segura, ya que el tráfico entre la VNet y la cuenta de almacenamiento no saldrá de la red de Azure, evitando que alguien desde fuera pueda acceder a la cuenta de almacenamiento. Esto funciona con [Private Link](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview), y crea una IP privada en tu VNet que se conecta a la cuenta de almacenamiento (con un coste adicional, eso sí).
-
-3. Por último, puedes usar [Azure CDN](https://learn.microsoft.com/en-us/azure/cdn/cdn-overview) para servir el contenido de la cuenta de almacenamiento, evitando exponer la URL de la cuenta de almacenamiento. Así, aunque la cuenta de almacenamiento sea `miempresa-aplicacion`, la URL que se use para lectura será `d123456789.azureedge.net` o `cdn.miempresa.com`.
\ No newline at end of file
diff --git a/src/content/blog/correos-ecommerce-1.md b/src/content/blog/correos-ecommerce-1.md
deleted file mode 100644
index 48c165b..0000000
--- a/src/content/blog/correos-ecommerce-1.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: "Probando el Buzón E-commerce de Correos"
-metaDescription: "Hoy he probado el Buzón E-commerce de Correos, doy mis primeras impresiones"
-publishedAt: 2024-05-20
----
-
-Hoy he contratado el servicio de Buzón E-commerce de Correos, y he querido compartir mis primeras impresiones. El servicio es muy sencillo, funciona casi como un apartado de correos, pero solo para recibir paquetes de tiendas online, sin importar el transportista.
-
-## ¿Cómo funciona?
-
-El funcionamiento es muy sencillo. Correos te asigna una dirección de envío, como un apartado postal, al que enviarán tus paquetes. Cuando llega un paquete, Correos te avisa y puedes ir a recogerlo a tu oficina de Correos.
-
-## ¿Por qué lo he contratado?
-
-Lo he contratado porque no quiero tener que estar en casa para recibir paquetes, o tener que ir a buscarlos a distintos lugares. En mi caso, tengo una oficina de Correos cerca de casa, pero no de otros proveedores populares como SEUR, CTT (la antigua Tourline Express) o DHL.
-
-## ¿A cuanto ha salido la broma?
-
-El servicio cuesta 30€ por un año o 30 envíos, lo que ocurra primero. Es decir, en el caso más beneficioso, te sale a 1€ por envío. No me parece caro, sobre todo teniendo en cuenta el coste en tiempo que supone ir a buscar paquetes a distintos lugares, o tener que estar en casa para recibirlos.
-
-## ¿Problemas hasta ahora?
-
-Me da la sensación de que no hay mucha información al respecto, y que darse de alta es un proceso demasiado manual. Al llegar a la oficina, no había opción en la impresora de tickets para "Otros servicios", solo envío, recogida, pago de impuestos y demás. Es decir, no es algo muy obvio ya de primeras.
-
-En un mundo ideal, podría haberlo hecho desde mi casa por Internet, seleccionar mi oficina y que ya me dieran el número de apartado donde tengo que enviar los paquetes, previo pago con tarjeta.
-
-Sin embargo, tuve que ir a la oficina, que la empleada de turno rellenara a mano un formulario dos veces, firmarlo, y darme de alta en el sistema. No recibí ningún correo de confirmación, ni SMS, ni nada. Solo la dirección completa, y porque la pregunté.
-
-## ¿Recomendaría el servicio?
-
-Igual no recomendarlo, por ahora, porque no lo he utilizado lo suficiente. Publicaré alguna entrada cuando haya recibido varios paquetes, y haya podido comprobar si el servicio es fiable o no. Pero de momento, no me parece mala idea, sobre todo si tienes una oficina de Correos cerca de casa, y no quieres estar pendiente de paquetes.
-
-Lo único, si alguien de la empresa por casualidad me lee, mejorad el proceso de alta, y dad más información al respecto. Sé que no es tan sencillo como "simplemente hacerlo", y que tendría un coste de desarrollo y mantenimiento detrás, pero creo que a la larga puede ser beneficioso para todos.
\ No newline at end of file
diff --git a/src/content/blog/cosas-de-c-que-echo-de-menos-en-otros-lenguajes.md b/src/content/blog/cosas-de-c-que-echo-de-menos-en-otros-lenguajes.md
deleted file mode 100644
index e7e1afd..0000000
--- a/src/content/blog/cosas-de-c-que-echo-de-menos-en-otros-lenguajes.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: "Cosas de C# que echo de menos en otros lenguajes"
-metaDescription: "C# tiene ciertas características que echo de menos en otros lenguajes, y hoy quiero hablar de ellas."
-publishedAt: 2023-09-28
----
-
-Desde comienzos de este año he estado trabajando con .NET y C#, con una experiencia genial en casi todos los aspectos del ecosistema (con excepciones como MAUI). Sin embargo, también he tenido que trabajar (generalmente por obligación) con otros lenguajes como Java, Python o (recientemente) PHP. Estos lenguajes no son necesariamente malos, aunque tengan sus… digamos… _peculiaridades_. Sin embargo, siempre echo de menos ciertas cosas que en C# doy por asumidas.
-
-## nameof
-
-La expresión `nameof` de C# devuelve el nombre de un símbolo (variable, clase, propiedad, método…) que tiene en el código, como una string. Así, por ejemplo, podemos hacer referencia al nombre de una propiedad «en código», en lugar de ir _hard-coded_ como una cadena de texto directamente. Por ejemplo:
-
-```csharp
-private static int _dia = 2;
-	
-public static void Main()
-{
-	Console.WriteLine(nameof(_dia));
-}
-```
-
-Este código imprimirá por consola _\_dia_ tal cual. No el valor, sino el nombre. Ahora bien ¿qué utilidad tiene esto? Para refactor, por ejemplo, es muy útil. Cuando vas a cambiar el nombre a una variable o una propiedad, se actualizará también en el _parámetro_ del nameof, de forma que no tendrás que buscar manualmente dónde se hace referencia a ese campo, útil cuando llamas a código que usa _reflection_, por ejemplo. Además, el IDE y el compilador sabrán a qué estás haciendo referencia, con lo que si un día te cargas la propiedad accidentalmente, el compilador te avisará de que estás pidiendo el nombre de una propiedad inexistente; evitando que ese fallo ocurra en tiempo de ejecución.
-
-## get; set;
-
-Salvo que uses los `record` en Java (solo disponibles desde Java 14) o algo similar, escribir clases para guardar datos es una tarea repetitiva: crear la clase, crear todas las propiedades como `private` y generar los getters y setters, quedándote con una clase de más de 100 líneas de código autogenerado, con el IDE quejándose de un montón de métodos no usados, y de código que tendrás que modificar si cambias una propiedad.
-
-Ahora bien, en C# no ocurre tal desgracia, ya que existen las [propiedades auto-implementadas](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties): puedo declarar una cadena de texto como `public string Nombre { get; set; }`, lo cual hará que sea accesible públicamente, aunque por detrás esté generando el campo donde realmente se almacena, de modo que hay encapsulamiento. Si hace falta que una propiedad nunca cambie, puedes hacer que solo tenga un getter. Si quieres hacer que solo pueda ser modificada desde la propia clase, puedes usar `private set`.
-
-Evitas generar decenas de líneas de código _plantilla_ que luego tendrás que modificar si las propiedades cambian, y que suponen cientos de líneas en un proyecto porque sí. Java dispone de Lombok, sí, pero es una biblioteca más que toca añadir. PHP no tiene tal cosa ni siquiera, siguen chapados a la antigua.
-
-## Todo en uno 
-
-Esta cuestión ya es un tanto más «filosófica», pero me gusta que .NET sea un ecosistema completo: casi todo lo que puedes necesitar está desarrollado y se actualiza cada año. El SDK base de .NET trae herramientas más que de sobra para crear aplicaciones de consola. Y con paquetes como `Microsoft.Extensions.Configuration` o `Microsoft.Extensions.Hosting` puedes evitar reinventar la rueda, en estos casos en el procesado de configuraciones y la creación de procesos de fondo.
-
-Si necesitas crear una aplicación web, puedes utilizar ASP.NET Core con tan solo instalar el SDK de .NET, pudiendo añadirle Entity Framework Core para conectarte a la base de datos, y paquetes como Identity para gestionar **TODO** lo relacionado con la identidad de usuarios, permisos, autenticación con redes sociales, MFA…
-
-Comparo esto con Symfony, que incluye su sistema de identidad también, pero no permite de serie la gestión dinámica de los roles (se declaran en tiempo de desarrollo, y no de ejecución), aparte de no permitir de serie la autenticación con proveedores externos (como Entra ID, Google Workspace o similares) ni tampoco la autenticación por factor doble con TOTP. Para esto último, hay que utilizar un paquete de terceros (scheb/2fa) que no compatible con la versión 6 del framework.
-
-La ventaja de tener «todo en uno» es que la aplicación se actualiza casi siempre al completo: pasar de .NET 7 a .NET 8 será cambiar las versiones de ciertos paquetes en el `.csproj` e instalar el SDK nuevo en tu máquina. Como mucho, ajustar el IDE, pero sin más. No tendrás que preocuparte de cosas como «es que Django no es compatible con la 3.11» o «es que Symfony rompe con la 8.2», o tener que saltar de Java 8 a 11, u 11 a 17 de golpe.
diff --git a/src/content/blog/demasiado-grande-caer.md b/src/content/blog/demasiado-grande-caer.md
deleted file mode 100644
index b5039af..0000000
--- a/src/content/blog/demasiado-grande-caer.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: "Gmail: demasiado grande para caer"
-metaDescription: "Gmail es un servicio tan grande que si cerrara, sería un caos para todo el mundo. ¿Qué pasaría si cerrara?"
-publishedAt: 2024-02-26
----
-
-Hace unos días se difundió por Twitter (o _X_ como le llama ahora el payaso que lo compró) que Gmail cerraría en unos meses. [Esto es mentira](https://www.bbc.com/news/technology-68374424), pero me ha hecho pensar en qué pasaría si cerrara.
-
-Para empezar, si cerrara de aquí a 6 meses, todo el mundo tendría que migrar a otro proveedor de correo. Y no es tan fácil como parece. Desde redes sociales, hasta servicios financieros, como bancos, suscripciones varias, administraciones públicas, y un largo etcétera, usan el correo electrónico como medio de autenticación (identificador de usuario) y método de contacto. Tendrías que averiguar TODO lo que tienes asociado a tu dirección de correo, y cambiarlo. Y generalmente para cambiar la dirección, te piden confirmar la actual y luego la nueva (o al menos, eso deberían hacer).
-
-Luego pensemos en todas las empresas que también usan Gmail, sea de forma corporativa (pagando Google Workspace) o de forma gratuita chapucera `miempresa@gmail.com`, y que tienen un montón de servicios asociados a esa cuenta. Tendrían que migrar a otro proveedor, y eso no es tan fácil como parece. Hay que descargar todo el correo de todos los buzones y traspasarlo a otro proveedor, sin olvidarse de ningún buzón ni alias.
-
-Podemos ver también que Gmail (o Google, de hecho) se usa como proveedor de identidad, siendo Gmail el identificador de usuario en muchos servicios. La cuenta de google se conservaría, pero al cambiar el correo, muchos servicios se romperían ya que usan este como identificador.
-
-Como vemos, es un servicio muy grande, usado por casi todo el mundo (aunque solo sea para registrarse en basura), y con mucha gente teniendo varias cuentas con distintos fines. Sería un caos, y es un peligro que haya un punto de fallo tan grande. Ya no solo por un posible cierre inminente, sino porque una caída de Google (o de Gmail) durante un tiempo prolongado detendría a muchas empresas y servicios que tienen dependencia absoluta de un conjunto de servicios reducido, y de una [empresa con cierta fama](https://killedbygoogle.com/) de cerrar servicios cuando le da la gana.
\ No newline at end of file
diff --git a/src/content/blog/dominios-cctld-parad.md b/src/content/blog/dominios-cctld-parad.md
deleted file mode 100644
index a7bd797..0000000
--- a/src/content/blog/dominios-cctld-parad.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: "Parad de una vez de comprar ccTLDs"
-metaDescription: "Los dominios ccTLD (Country-Code Top Level Domain) son los dominios de nivel superior que se asignan a cada país. Por qué no deberías usarlos, y qué deberías usar en su lugar."
-publishedAt: 2024-01-29
----
-
-Los dominios ccTLD (Country-Code Top Level Domain) son los dominios de nivel superior que se asignan a cada país. Por ejemplo, `.es` para España, `.fr` para Francia, `.de` para Alemania, `.uk` para Reino Unido, `.us` para Estados Unidos, etc. Estos dominios se asignan a cada país según el [código ISO 3166-1](https://es.wikipedia.org/wiki/ISO_3166-1) de cada país.
-
-En años recientes, sin embargo, vemos cada vez más frecuentemente que estos dominios se usan porque quedan "guay" en una dirección de correo electrónico, o porque el dominio `.com` ya está ocupado. Especialmente, veo un montón de dominios .io (Territorio Británico del Océano Índico) y .ai (Anguila) en uso, y no precisamente por empresas de esos países.
-
-Y como estos, muchos más: .tv (Tuvalu) por empresas como Twitch, .fm (Estados Federales de Micronesia) como Last.fm, .me (Montenegro) como About.me, .co (Colombia) como g.co (de Google). Y alguna vez que otra, también para software, como .sh (Santa Helena) para cosas relacionadas con shell scripting; o .rs (Serbia) para Rust; o .gg (Guernsey) para juegos.
-
-## ¿Por qué no deberías usarlos?
-
-Porque no son tuyos. Son de un país, y el país puede decidir que no te pertenecen. Por ejemplo, el gobierno de Tuvalu podría decidir que Twitch no puede usar el dominio .tv, y quitárselo. O el gobierno de Montenegro podría decidir que About.me no puede usar el dominio .me, y quitárselo.
-
-Cuando ocurrió el Brexit (la salida de Reino Unido de la Unión Europea), los ciudadanos de Reino Unido perdieron el derecho a usar dominios .eu. Quienes [no cumplían las condiciones](https://www.gov.uk/guidance/registering-and-renewing-eu-domain-names-in-the-uk) para tener un dominio .eu, lo perdieron en 2021. 
-
-¿Quién dice que el gobierno de Montenegro no se va a despertar mañana y decidir que solo los ciudadnos de Montenegro pueden usar dominios .me? O el de Mali. O el de Tuvalu. O el de cualquier otro país. O que van a subir las tasas de registro, y en vez de pagar 50€ por un .io, que pases a pagar 500€.
-
-Dejará de ser un dominio tan guay cuando tengas que pagar mucho más por un dominio porque tienes el correo alojado ahí, o porque tienes un montón de enlaces apuntando a él, o porque tienes un montón de clientes que te conocen por ese dominio.
-
-## ¿Qué deberías usar?
-
-Pues o el ccTLD de tu país, o uno al que tengas derecho (como el .eu si eres europeo) y dependa de un país estable y fiable. O uno genérico.
-
-Hoy en día existen un montón de dominios genéricos de reciente creación, como .dev, .app, .page, .blog, .shop, .online, .tech, .site, .website, .digital, .cloud, .software, .network, .host, y otros muchos más. O siempre puedes ir a los viejos confiables (.com, .net, .org y .info).
diff --git a/src/content/blog/hola-astro.md b/src/content/blog/hola-astro.md
deleted file mode 100644
index 44a56b9..0000000
--- a/src/content/blog/hola-astro.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: "Hola, Astro"
-metaDescription: "De mi migración a Astro, y por qué me gusta tanto"
-publishedAt: 2024-05-04
----
-
-He estado probando [Astro](https://astro.build) durante las últimas semanas, y me ha gustado mucho, hasta el punto de que he decidido migrar este blog a Astro. 
-
-## ¿Qué es Astro?
-
-Astro es un generador de sitios web estáticos implementado en JavaScript. Es similar a [Next.js](https://nextjs.org) o [Gatsby](https://www.gatsbyjs.com), pero con la diferencia de que Astro genera sitios estáticos sin JavaScript en el cliente (por defecto). De forma similar a Hugo, Hexo, Jekyll y otros generadores, a través de un sistema de plantillas, Astro genera HTML estático que se sirve al cliente.
-
-## ¿Por qué Astro?
-
-Astro me ha gustado por varias razones:
-
-1. **Sintaixs más cómoda**: Astro usa una sintaxis muy similar a HTML puro, pero con algunas mejoras. Por ejemplo, hay un "frontmatter" donde puedes definir JavaScript en tiempo de compilación, y tiene un sistema de componentes como el de React, Vue y otros frameworks modernos.
-
-2. **Soporte en el editor**: Astro tiene una extensión para Visual Studio Code que añade soporte para la sintaxis de Astro, y para el "frontmatter". Esto hace que sea más fácil trabajar con Astro en Visual Studio Code. Hugo usa el sistema de plantillas de Go, y no tiene soporte en Visual Studio Code, lo que hace que trabajar con Hugo sea más incómodo.
-
-3. **TypeScript**: Astro está escrito en TypeScript, y tiene soporte para TypeScript en los archivos de plantillas. Esto me gusta mucho, porque me permite usar TypeScript en los archivos de plantillas, y tener autocompletado y validación de tipos. En Hugo, por ejemplo, no puedo hacer esto, y dependo de compilar para enterarme de posibles errores.
-
-4. **SASS y estilos 'scoped'**: Astro tiene soporte para SASS, y para estilos "scoped" (es decir, estilos que solo afectan al componente donde se definen). Esto me gusta mucho, porque me permite tener estilos más organizados y reutilizables, y no tener que dar nombres de clases y montones de selectores.
-
-## ¿Qué he tenido que hacer para migrar?
-
-La migración ha sido relativamente sencilla, al poder aprovechar buena parte de los estilos y componentes que ya tenía en Hugo. He reimplementado las vistas HTML, aprovechando para arreglar "chapuzas" del pasado, y he usado algunos componentes para separar, por ejemplo, la cabecera y el pie de página.
-
-Además, he aprovechado para hacer otras mejoras, como añadir meta-descripciones a todas las páginas, y añadir un favicon. Añadí archivos al repositorio que me faltaban (como las licencias), y pulí un poco más los estilos.
-
-## ¿Qué me queda por hacer?
-
-Me queda por hacer algunas cosas, como añadir un sistema de comentarios (que crearé en Azure con Functions y CosmosDB), y potencialmente añadir un sistema de búsqueda (como Algolia). También me gustaría añadir un sistema de "dark mode" en algún momento, pero no es una prioridad.
\ No newline at end of file
diff --git a/src/content/blog/ipv4-debe-morir.md b/src/content/blog/ipv4-debe-morir.md
deleted file mode 100644
index e1043ed..0000000
--- a/src/content/blog/ipv4-debe-morir.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: "IPv4 debe morir, ya va siendo hora"
-metaDescription: "Razones por las que IPv4 es un incordio y un vestigio del pasado que deberíamos dejar atrás."
-publishedAt: 2024-03-23
----
-
-Desde hace años se viene hablando de la necesidad de migrar a IPv6, pero la realidad es que la mayoría de los servicios siguen funcionando en IPv4. La transición es lenta, y muchos administradores de red y desarrolladores no parecen tener prisa (o están directamente en contra) de hacer el cambio. Pero la realidad es que IPv4 debe morir, y ya va siendo hora de que lo haga.
-
-Si algo añade mucha complejidad a los sistemas de internet es IPv4, por cómo la limitación de direcciones ha llevado a tener que usar NAT para conectar redes enteras a internet, o llegando incluso al punto de inventar CG-NAT para poder seguir añadiendo dispositivos a internet. La realidad es que IPv4 no es sostenible, y la única solución es migrar a IPv6.
-
-¿Alguna vez has tenido que "abrir puertos" en tu router para poder acceder a un servicio que tienes en casa? ¿O usar algún sistema como Hamachi para poder jugar a videojuegos en red con tus amigos? O usar un túnel como [ngrok](https://ngrok.com/) para poder compartir un servicio que tienes en tu ordenador con alguien que está en otra red. Todo esto es debido a la falta de direcciones IPv4, y es algo que no debería existir en 2024.
-
-Con IPv4, cada "red" doméstica o de empresa tiene asignada una "IP pública" y luego tiene una red interna con direcciones privadas siguiendo la [RFC 1918](https://tools.ietf.org/html/rfc1918), usando los rangos `10.0.0.0/8`, `172.16.0.0/12` y `192.168.0.0/16` para estas redes, y luego creando subredes si es necesario. Pero esto añade complejidad, ya que si quieres acceder desde internet a este sistema, tienes que configurar NAT en el router y apuntar puertos a dispositivos concretos.
-
-Con IPv6, cada dispositivo puede tener su propia dirección pública, y no es necesario usar NAT para conectar dispositivos a internet. Esto simplifica mucho la configuración de redes, y hace que sea mucho más fácil compartir servicios con otras personas. Además, IPv6 añade seguridad, ya que cada dispositivo tiene su propia dirección, y no es necesario abrir puertos en el router para acceder a servicios.
-
-Además, al estar tan limitada la disponibilidad de direcciones IPv4, y por tanto tener precios muy elevados y dificultad para conseguirlas, los principales proveedores de Cloud ya están cobrando por las direcciones IPv4, con lo que el coste de tener IP públicas también aumenta.
-
-También, a nivel firewall para servicios cloud, complica las cosas. Por ejemplo, si mi servicio tiene que conectarse a tu servicio pero no quieres tenerlo expuesto a cualquiera, tendrías que añadir mi IP a tu firewall, y yo tendría que usar NAT para que mis múltiples servidores "salgan" con la misma IP. Con IPv6, cada servidor tendría su IP, que incluso podría ir rotando, y autorizas un rango sabiendo que todo ese rango lo controlo yo.
-
-En resumen, IPv4 debe morir, y ya va siendo hora de que lo haga. La transición a IPv6 es necesaria, y es algo que deberíamos hacer cuanto antes. Parte de la complejidad de _la nube_ y de las redes actuales se debe a todos los apaños que se han tenido que hacer para seguir usando IPv4, y la única solución es migrar a IPv6.
\ No newline at end of file
diff --git a/src/content/blog/irpf-para-tontos.md b/src/content/blog/irpf-para-tontos.md
deleted file mode 100644
index 96ebf84..0000000
--- a/src/content/blog/irpf-para-tontos.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: "IRPF para tontos"
-metaDescription: "Explicación sencilla del IRPF, cómo se calcula la retención, y qué es el borrador de la declaración de la renta."
-publishedAt: 2024-03-26
----
-
-Si hay algo que gusta hacer en España es quejarse, y cuando llega abril y toca hacer la declaración de la renta, la queja es generalizada, sobre todo porque "sale a pagar". Pero la realidad es que el IRPF no es tan complicado de entender, y en este artículo voy a intentar explicar cosas que la gente no parece meter en la cabeza.
-
-## ¿Qué es el IRPF?
-
-El IRPF es el Impuesto sobre la Renta de las Personas Físicas, y es un impuesto que grava la renta de las personas físicas. Es un impuesto progresivo, lo que significa que a mayor renta, mayor porcentaje de impuestos se paga.
-
-¿Cómo que progresivo? ¿No son así todos los impuestos, que cuanto más ganas más pagas? Sí y no. Todos los impuestos que son porcentuales se aplican según la "base imponible" (la cantidad de referencia sobre la que se *impone* el gravamen), pero no todos los impuestos son progresivos como el IRPF. Por ejemplo, el IVA y el de Sociedades son "lineales", ya que siempre son el 21% (menos excepciones) y el 25% respectivamente.
-
-En el caso del IRPF, en función de los ingresos, se aplican unos tramos u otros, pagando la cantidad que toca en cada tramo. Pongo un ejemplo sencillo para ilustrarlo, con porcentajes inventados:
-
-- Si ganas menos de 10.000€, no pagas nada.
-- De 10.000€ a 50.000€, pagas un 10%.
-- De 50.000€ y 100.000€, pagas un 20%.
-- Y por encima de eso, un 30%.
-
-Si ganas 60.000€, pagarías:
-
-1. El 0% en los primeros 10.000€.
-2. El 10% en los siguientes 40.000€, hasta llegar a los 50.000€. Esto son **4.000€**.
-3. El 20% en los siguientes 10.000€, hasta llegar a los 60.000€. Esto son **2.000€**.
-
-En total, pagarías **6.000€** de impuestos, lo que supone un 10% de tu renta, y no un 20% como se podría pensar "porque estoy en ese tramo". Pongamos en su lugar que ganas 90.000, quedando "en el mismo tramo": 
-
-1. El 0% en los primeros 10.000€.
-2. El 10% en los siguientes 40.000€, hasta llegar a los 50.000€. Esto son **4.000€**.
-3. El 20% en los siguientes 40.000€, hasta llegar a los 90.000€. Esto son **8.000€**.
-
-En total, pagarías **12.000€** de impuestos, lo que supone un 13,33% de tu renta, y no un 20% como se podría pensar "porque estoy en ese tramo". Es decir, al cobrar más **estás pagando un porcentaje mayor**, pero no de toda tu renta, sino solo de la parte que supera el tramo anterior.
-
-## Retención, borrador y declaración
-
-Otras dos cosas que se confunden mucho son la obligación de retener y la de declarar. La primera es una obligación de la empresa o entidad que te paga, y la segunda es una (posible) obligación tuya.
-
-A grandes rasgos, la obligación de retener es que tu empresa te retenga un porcentaje (que luego explicaré como se calcula) y lo ingrese en Hacienda en tu nombre. De esta forma, Hacienda tiene "liquidez" todos los meses, y se asegura de que no tendrás que pagar una cantidad muy grande en la declaración de la renta de abril.
-
-La obligación de declarar es que, si tus ingresos superan un cierto umbral, tienes que presentar una declaración de la renta. En general, si tienes un solo pagador y tus ingresos no superan los 22.000€, no tienes que declarar.
-
-En cualquier caso, puedes **elaborar un borrador** de la declaración de la renta, que es una propuesta de Hacienda con los datos que tiene de ti, aunque no tengas obligación de declarar. En este caso, si te sale a pagar (no te compensa) puedes no presentarlo, repito, si no tienes obligación de declarar. Si te sale a devolver, sí te interesa presentarlo, ya que te devolverán el dinero que te han retenido de más.
-
-## ¿Cómo se calcula la retención?
-
-La retención se calcula en función de tus ingresos, y de tus circunstancias personales. Proporcionando ciertos datos a Hacienda, con una serie de fórmulas ([o la calculadora online](https://sede.agenciatributaria.gob.es/Sede/Retenciones.shtml) de la Agencia Tributaria) se puede calcular cuánto te tienen que retener.
-
-En general, depende de factores como tus ingresos estimados, deducciones (como las cotizaciones, alquiler en algunas CCAA, etc.) y circunstancias personales (hijos y mayores a cargo, discapacidades, etc.).
-
-Esta retención se calcula a principio de año (o cuando hay cambios) y se aplica a tus nóminas. Si te retienen de más, te devolverán la diferencia en la declaración de la renta en abril. Si te retienen de menos, tendrás que pagar la diferencia en esa declaración. Por eso es importante que los datos que proporcionas a Hacienda sean correctos y actuales, para que no te retengan de más (tienes menos dinero todos los meses) ni de menos (tienes que pagar una cantidad grande en abril).
-
-Puede ser que esta retención sea 0, si tus ingresos son bajos (porque empezaste a trabajar a mitad de año, por ejemplo) o si tienes muchas deducciones (por ejemplo, si tienes hijos a cargo). **No tiene por qué ser un error o un problema futuro**, simplemente significa que no cobras lo suficiente como para tener que pagar.
\ No newline at end of file
diff --git a/src/content/blog/pesadilla-aws.md b/src/content/blog/pesadilla-aws.md
deleted file mode 100644
index 8fdcfca..0000000
--- a/src/content/blog/pesadilla-aws.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: "La pesadilla de AWS"
-metaDescription: "Trabajar con AWS es una locura, y aquí explico por qué."
-publishedAt: 2024-03-26
----
-
-Llevo unas semanas trabajando con AWS, y la verdad es que no me está gustando nada. No es que sean malos servicios (que funcionan bien), pero la cantidad de opciones, configuraciones, precios, cosas que están pasando por debajo... es una locura, y desde luego no compensa el tiempo que tienes que dedicar a entenderlo todo salvo que tengas un proyecto considerablemente grande.
-
-Por ejemplo, desplegar una aplicación sencilla en PHP (Symfony) y MySQL administrado en EC2 y RDS es relativamente sencillo usando la red VPC por defecto. Sin embargo, crear esto desde cero es una aventura: crear VPC y dos subredes, configurar un internet gateway, una tabla de rutas, un grupo de seguridad para limitar acceso desde internet, la instancia y la base de datos, configurar la base de datos para que acepte conexiones desde la instancia, configurar la instancia para que se conecte a la base de datos... y todo esto sin contar con cosas como balanceadores de carga, certificados TLS, etc.
-
-Esto nos dejaría con solo una base de datos en RDS y una instancia de EC2. Pero si queremos usar AWS como algo más que un "DigitalOcean caro", hay que pensar en un balanceador de carga y certificado, el WAF y tener varias instancias de EC2 con autoescalado. Para el autoescalado, hace falta crear una imagen de la instancia (instalar todo y prepararla, luego generar la AMI) y luego configurar el auto-scalign group, con su launch config, sus reglas y demás.
-
-Luego, como tenemos que tener algo escalable e independiente del sistema, tenemos que subir los archivos "de usuario" a S3, configurando las instancias para que tengan un rol de IAM que les permita acceder al bucket desde la instancia, y luego dar de alta CloudFront para que apunte a ese bucket, con otro certificado y cambios al DNS.
-
-Una vez hecho todo esto, tienes una infraestructura que se escala automáticamente, pero que te ha llevado mucho tiempo configurar, y que si no tienes un proyecto grande, estará infrautilizada. Además, para actualizar la aplicación, tendrás que crear otra AMI, y luego tendrás que hacer "apaños" para que la aplicación use credenciales compartidas (con Secrets Manager) y añadir monitorización con CloudWatch.
-
-Ah, todo esto sin contar que cuando quieras hacer un experimento luego tendrás que borrar los recursos uno a uno, porque a nadie en AWS se le ocurrió de primeras un sistema de "Resource Groups" como en Azure, o de "Projects" como en Google Cloud. Y sin contar fallos con la línea de comandos, como un 400 cada vez que quieres hacer `docker push` a un repositorio de ECR.
-
-Y luego la gracia de cambiarse de proveedor a largo plazo, porque todas estas configuraciones sirven solo para AWS, y tendrás que aprender como funcionan otros proveedores, o usar un sistema "neutral" como Kubernetes para el autoescalado y la gestión de recursos (que a su vez es otro mundo).
-
-Finalmente, cuando te quieras ir, AWS te cobrará una "penalización" por "salida a internet" y pagarás una cantidad considerable por mover tus datos a otro proveedor. O así era hasta hace poco, cuando [tuvieron que hacerlo gratuito](https://aws.amazon.com/es/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/) por culpa de la malvadísima Unión Europea que aprobó la European Data Act obligándoles a hacerlo.
diff --git a/src/content/blog/router-casero-raspberry.md b/src/content/blog/router-casero-raspberry.md
deleted file mode 100644
index 8441ed5..0000000
--- a/src/content/blog/router-casero-raspberry.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: "Montando un router casero con una Raspberry Pi"
-metaDescription: "Cómo montar un router casero con una Raspberry Pi, a modo de experimento de redes."
-publishedAt: 2024-04-29
----
-
-El otro día recordé que tengo una Raspberry 4B por casa, y que no le estoy dando ningún uso. Así que, con fines experimentales, decidí montar un router casero con ella.
-
-## Materiales
-
-- Raspberry Pi 4B
-- Tarjeta microSD flashada con Raspberry Pi OS (versión Lite sin entorno gráfico)
-- Netplan (de canonical) para configurar las interfaces de red de forma fácil y reproducible
-- Cable Ethernet al router principal
-- Editor de texto (yo uso Vim)
-
-## Funcionamiento
-
-Vamos a configurar la Raspberry Pi para que actúe como router, y que actúe como NAT para los dispositivos que se conecten a ella. La raspberry tiene dos interfaces: `eth0` por Ethernet, que voy a conectar al router de mi casa, y `wlan0` que voy a configurar como punto de acceso para que se conecten los dispositivos.
-
-En este caso, mi red de casa es `192.168.1.0/24`, y la Raspberry tiene la IP `192.168.1.14`. Para la nueva red, voy a usar `172.16.69.0/24`, y la Raspberry (el "router") tendrá la IP `172.16.69.1`. Los dispositivos que se conecten a la red de la Raspberry obtendrán una IP en este rango.
-
-## Activar forwarding de paquetes
-
-Comenzamos editando el archivo `/etc/sysctl.conf` y descomentando la línea `net.ipv4.ip_forward=1`. Aplicamos los cambios con `sysctl -p`.
-
-## Configuración de netplan
-
-Instalamos netplan con `sudo apt install netplan.io`. Creamos un archivo de configuración en `/etc/netplan/01-router.yaml` con el siguiente contenido:
-
-```yaml
-network:
-  renderer: NetworkManager
-  ethernets:
-    eth0:
-      addresses:
-        - 192.168.1.14/24
-      routes:
-        - to: default
-          via: 192.168.1.1
-      nameservers:
-        addresses:
-          - 1.1.1.1
-          - 8.8.8.8
-  wifis:
-    wlan0:
-      addresses:
-        - 172.16.69.1/24
-      access-points:
-        RASPI_ACG:
-          mode: ap
-          auth:
-            key-management: psk
-            password: "ClaveSuperSegura"
-      routes:
-        - to: default
-          via: 192.168.1.1
-          table: 102
-      routing-policy:
-        - from: 172.16.69.0/24
-          table: 102
-```
-
-Esta configuración hace lo siguiente:
-
-1. Configura `eth0` con IP4 fija y DNSs de Cloudflare y Google. También añade una ruta por defecto a través del router de casa, para que la Raspberry pueda salir a internet.
-
-2. Configura `wlan0` como punto de acceso con una clave WPA2-PSK y una IP fija
-
-3. En `wlan0` le añado una ruta por defecto a través del router de casa (`192.168.1.1`) y una política de enrutamiento para que el tráfico de la WLAN se reenvíe a través de esta ruta
-
-Aplicamos los cambios con `sudo netplan apply`.
-
-## Problemas
-
-La configuración funciona, y los dispositivos se pueden conectar a la red de la Raspberry y salir a internet. Sin embargo, hay un problema: no puedes ejecutar por tu cuenta un servidor DHCP (como Kea) y un servidor DNS (como Bind9) en la Raspberry, ya que NetworkManager lanza su propio servidor con `dnsmasq` como esclavo.
-
-Desactivando NetworkManager implicaría no poder usar `netplan`, ya que no se puede activar el modo AP de la Raspberry usando otro renderer (como `networkd`). Por tanto, he decidido no usar un servidor DHCP y DNS en la Raspberry, y confiar en los que gestiona el propio `NetworkManager`. Se puede modificar la configuración de este, ojo, pero prefería usar `bind9` porque me resulta más familiar.
-
-Por otra parte, mi móvil Android indica que la red no es segura, probablemente porque usa WPA2-PSK y no WPA3. No sé si mi Raspberry soporta configurar WPA3 (y menos con `netplan`), pero es algo a tener en cuenta.
\ No newline at end of file
diff --git a/src/content/blog/servidor-arm.md b/src/content/blog/servidor-arm.md
deleted file mode 100644
index a465b18..0000000
--- a/src/content/blog/servidor-arm.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: "Mi experiencia con un servidor ARM64"
-metaDescription: "Hace unas semanas arranqué un servidor VPS con arquitectura arm64, en concreto el CAX11 de Hetzner con dos núcleos de procesador Ampere y 4 GB de RAM. El motivo de esta elección fue reducir costes, y probar algo nuevo."
-publishedAt: 2024-03-22
----
-
-Hace unas semanas arranqué un servidor VPS con arquitectura `arm64`, en concreto el `CAX11` de [Hetzner](https://www.hetzner.com/cloud) con dos núcleos de procesador Ampere y 4 GB de RAM. El motivo de esta elección fue reducir costes (por un servidor de similares características en x86_64 estoy pagando 12€/mes a un proveedor español, y este sale por menos de 5€), y probar algo nuevo.
-
-La experiencia por el momento ha sido buena, utilizando Ubuntu Server 22.04. El rendimiento es igual o incluso servidor que el servidor x86_64, siendo los tiempos de compilación de un par de aplicaciones notablemente más rápidos.
-
-Una pega que he encontrado es que [Percona](https://www.percona.com/) no ofrece paquetes para ARM64, por lo que he tenido que usar los paquetes de MySQL ofrecidos por Canonical. No es un problema, pero es algo a tener en cuenta si, como yo, usas software de Percona por las funcionalidades extra que ofrece frente a las distribuciones oficiales (especialmente en MonogDB) o el sistema de copias de seguridad.
-
-En general, estoy contento con el cambio, y si no necesitas software específico que no esté disponible para ARM64, es una buena opción para reducir costes, mejorar ligeramente el rendimiento y tener una infraestructura algo más moderna.
\ No newline at end of file
diff --git a/src/content/blog/vuelvo-hugo.md b/src/content/blog/vuelvo-hugo.md
deleted file mode 100644
index 60c0aae..0000000
--- a/src/content/blog/vuelvo-hugo.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: "Vuelvo a Hugo, adios WordPress"
-metaDescription: "Hace unas semanas, decidí migrar mi blog de WordPress a Hugo. La razón principal fue que quería hacer mi propio tema personalizado, y WordPress no me daba la facilidad que otros generadores me dan."
-publishedAt: 2023-12-17
----
-
-Hace unas semanas, decidí migrar mi blog de WordPress a Hugo. La razón principal fue que quería hacer mi propio tema personalizado, y WordPress no me daba la facilidad que otros generadores me dan. Otra razón importante es que WordPress funcione de forma dinámica, ya que las páginas se generan de cada vez, y por tanto necesitan un servidor que ejecuta código.
-
-De esta forma, en cambio, es código estático que se sirve desde Azure Static Web Apps a partir de lo que genera Hugo en GitHub Actions. No solo es la web más rápida de cargar y más ligera, sino que además es más segura, ya que no hay código que ejecutar en un servidor propio.
-
-También el hecho de la base de datos, ya que WordPress necesita una base de datos MySQL para funcionar, y eso supone un coste adicional, no económico, sino de mantenimiento (si se quiere hacer bien). Hay que mantenerla actualizada, hacer copias de seguridad, etc. Con Hugo, no hay base de datos, y por tanto no hay que preocuparse de nada de eso.
-
-## ¿Por qué Hugo?
-
-Porque es el que más me gusta. Es rápido, relativamente sencillo y tiene una comunidad muy activa. Hay otros generadores como Jekyll (Ruby, no gracias), Gatsby (React, no gracias) o uno de los muchos que hay. En su día también probé sistemas como Ghost o Grav, pero no me convencieron.
-
-Entonces, creé un sitio con Hugo, creé mi propio "tema", que realmente son plantillas y estilos totalmente ad-hoc para mi blog, y lo subí a un repositorio de GitHub. Configuré Azure Static Web Apps para que se actualizara automáticamente cuando se subiera algo a la rama `main`, y listo. Y le configuré mi subdominio personalizado www.costas.dev para que apuntara a la web.
-
-No utilicé el dominio principal, para poder seguir teniendo ahí mi servidor, que utilizo para otras cosas. Aparte, no quería que el blog estuviera en la raíz del dominio, sino en un subdominio, para poder tener otras cosas en el dominio principal si algún día me apetece.
diff --git a/src/content/config.ts b/src/content/config.ts
deleted file mode 100644
index 88e67c4..0000000
--- a/src/content/config.ts
+++ /dev/null
@@ -1,14 +0,0 @@
-import { defineCollection, z } from 'astro:content';
-
-const blogCollection = defineCollection({
-	type: 'content',
-	schema: z.object({
-		title: z.string(),
-		metaDescription: z.string(),
-		publishedAt: z.date()
-	})
-});
-
-export const collections = {
-	'blog': blogCollection
-};
\ No newline at end of file
diff --git a/src/pages/blog.astro b/src/pages/blog.astro
deleted file mode 100644
index e533fb6..0000000
--- a/src/pages/blog.astro
+++ /dev/null
@@ -1,72 +0,0 @@
----
-import { getCollection } from "astro:content";
-import Layout from "../layouts/Layout.astro";
-
-const blogCollection = (await getCollection("blog")).sort((a, b) => {
-	return b.data.publishedAt.getTime() - a.data.publishedAt.getTime();
-});
-
-const groupedPosts = blogCollection.reduce(
-	(acc: Record<string, any[]>, post) => {
-		const year = post.data.publishedAt.getFullYear();
-		const month = post.data.publishedAt.getMonth() + 1;
-		const key = `${year}-${month}`;
-		if (!acc[key]) {
-			acc[key] = [];
-		}
-		acc[key].push(post);
-		return acc;
-	},
-	{},
-);
-
-function humaniseDate(date: Date) {
-	const result = date.toLocaleDateString("es-ES", {
-		month: "long",
-		year: "numeric",
-	});
-	return result.charAt(0).toUpperCase() + result.slice(1);
-}
-
-const schema = {
-	"@context": "https://schema.org",
-	"@type": "Blog",
-	"headline": "Blog de Ariel Costas",
-	"description": "En este blog encontrarás artículos sobre desarrollo, tecnología y otras temáticas que pueda querer compartir. Disclaimer de siempre: las opiniones son mías, y no representan a ninguna empresa o institución.",
-	"publisher": {
-		"@type": "Person",
-		"name": "Ariel Costas",
-	},
-	"author": {
-		"@type": "Person",
-		"name": "Ariel Costas",
-	}
-};
----
-
-<Layout title="Blog" description="Artículos sobre desarrollo, tecnología y otras temáticas que pueda querer compartir.">
-	<script type="application/ld+json" slot="head-jsonld" set:html={JSON.stringify(schema)}></script>
-
-	<h1>Blog de Ariel Costas</h1>
-
-	<p>
-		En este blog encontrarás artículos sobre desarrollo, tecnología y otras
-		temáticas que pueda querer compartir. Disclaimer de siempre: las
-		opiniones son mías, y no representan a ninguna empresa o institución.
-	</p>
-
-	{
-		Object.entries(groupedPosts).map(([key, posts]) => (
-			<section>
-				<h2>{humaniseDate(new Date(key))}</h2>
-				<ul>
-					{posts.map((post) => (
-						<li>
-							<a href={`/blog/${post.slug}`}>{post.data.title}</a>
-						</li>
-					))}
-				</ul>
-			</section>
-		))
-	}
-</Layout>
diff --git a/src/pages/blog.xml.js b/src/pages/blog.xml.js
deleted file mode 100644
index ec8d424..0000000
--- a/src/pages/blog.xml.js
+++ /dev/null
@@ -1,19 +0,0 @@
-import rss from '@astrojs/rss';
-import { getCollection } from 'astro:content';
-
-
-export async function GET(context) {
-	const collection = await getCollection('blog');
-
-	return rss({
-		title: "Blog de Ariel Costas",
-		description: "Artículos del blog de Ariel Costas",
-		site: context.site,
-		items: collection.map((post) => ({
-			title: post.data.title,
-			link: `${context.site}blog/${post.slug}`,
-			description: post.data.metaDescription,
-			pubDate: post.data.publishedAt
-		}))
-	})
-}
\ No newline at end of file
diff --git a/src/pages/blog/[slug].astro b/src/pages/blog/[slug].astro
deleted file mode 100644
index f9ceec1..0000000
--- a/src/pages/blog/[slug].astro
+++ /dev/null
@@ -1,59 +0,0 @@
----
-import type { GetStaticPaths } from "astro";
-import Layout from "../../layouts/Layout.astro";
-import { getCollection } from "astro:content";
-
-export const getStaticPaths = (async () => {
-	const entries = await getCollection("blog");
-	return entries.map((entry) => ({
-		params: { slug: entry.slug },
-		props: { entry },
-	}));
-}) satisfies GetStaticPaths;
-
-const { entry } = Astro.props;
-const { Content } = await entry.render();
-
-const formattedDate = new Date(entry.data.publishedAt).toLocaleDateString(
-	"es-ES",
-	{
-		year: "numeric",
-		month: "long",
-		day: "numeric",
-		weekday: "long",
-	},
-);
-
-const schema = {
-	"@context": "https://schema.org",
-	"@type": "BlogPosting",
-	headline: entry.data.title,
-	datePublished: entry.data.publishedAt.toISOString(),
-	author: {
-		"@type": "Person",
-		name: "Ariel Costas Guerrero",
-	},
-	publisher: {
-		"@type": "Person",
-		name: "Ariel Costas Guerrero",
-		logo: {
-			"@type": "ImageObject",
-			url: "https://www.costas.dev/favicon.png",
-		},
-	},
-};
----
-
-<Layout title={entry.data.title} description={entry.data.metaDescription}>
-	<script type="application/ld+json" slot="head-jsonld" set:html={JSON.stringify(schema)}></script>
-
-	<h1>{entry.data.title}</h1>
-	<small>
-		Publicado el
-		<time datetime={entry.data.publishedAt.toISOString()}>
-			{formattedDate}
-		</time>
-	</small>
-
-	<Content />
-</Layout>
diff --git a/src/partials/Header.astro b/src/partials/Header.astro
index 842841a..e351156 100644
--- a/src/partials/Header.astro
+++ b/src/partials/Header.astro
@@ -36,34 +36,10 @@ import Favicon from "../assets/Favicon.astro";
 		<a href="/">Inicio</a>
 		<a href="/trajectory">Trayectoria</a>
 		<a href="/portfolio">Portfolio</a>
-		<a href="/blog">Blog</a>
 		<a href="/contact">Contacto</a>
 	</nav>
 
 	<nav id="nav-socials">
-		<a rel="me" href="https://masto.es/@arielcg" title="Mastodon">
-			<svg
-				xmlns="http://www.w3.org/2000/svg"
-				class="icon icon-tabler icon-tabler-brand-mastodon"
-				width="32"
-				height="32"
-				viewBox="0 0 24 24"
-				stroke-width="2"
-				stroke="currentColor"
-				fill="none"
-				stroke-linecap="round"
-				stroke-linejoin="round"
-			>
-				<title>Mastodon logo</title>
-				<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
-				<path
-					d="M18.648 15.254c-1.816 1.763 -6.648 1.626 -6.648 1.626a18.262 18.262 0 0 1 -3.288 -.256c1.127 1.985 4.12 2.81 8.982 2.475c-1.945 2.013 -13.598 5.257 -13.668 -7.636l-.026 -1.154c0 -3.036 .023 -4.115 1.352 -5.633c1.671 -1.91 6.648 -1.666 6.648 -1.666s4.977 -.243 6.648 1.667c1.329 1.518 1.352 2.597 1.352 5.633s-.456 4.074 -1.352 4.944z"
-				></path>
-				<path
-					d="M12 11.204v-2.926c0 -1.258 -.895 -2.278 -2 -2.278s-2 1.02 -2 2.278v4.722m4 -4.722c0 -1.258 .895 -2.278 2 -2.278s2 1.02 2 2.278v4.722"
-				></path>
-			</svg>
-		</a>
 		<a href="https://github.com/arielcostas" title="GitHub">
 			<svg
 				xmlns="http://www.w3.org/2000/svg"