By the time I started using it seriously, the dominant platforms were already established: algorithmic feeds, centralized social networks, and applications designed around constant updates and notifications. That was simply the baseline.

Because of that, I never lived the earlier internet. I didn’t experience RSS when it was mainstream, I didn’t use mailing lists as my primary communication layer, and I didn’t grow up with tools like Emacs as part of a standard workflow. I encountered them later, as historical artifacts that were still quietly functional.

And that timing changes everything.

Discovering systems that were never “new” to me

When I first encountered RSS, it didn’t feel nostalgic. It felt unfamiliar. Almost counterintuitive.

I started using a self-hosted instance of FreshRSS, not because it reminded me of a past version of the web, but because it solved a present problem: information overload without structure.

What surprised me was not that it was simple, but that it felt complete. There was no sense that something was missing. No recommendation engine, no ranking system trying to optimize my attention. Just a direct relationship between sources and reader.

That simplicity didn’t feel like minimalism. It felt like removal of unnecessary assumptions.

Learning tools without the cultural context

The same happened with Emacs.

I didn’t grow up with it. I didn’t see it evolve. I encountered it in its modern form, already shaped by decades of development, plugins, and community conventions.

And yet, what stood out immediately was not its age, but its consistency.

Emacs doesn’t behave like a typical application. It behaves like an environment that you gradually shape. With distributions like Doom Emacs, that environment becomes more structured, but the core idea remains: the tool does not define your workflow—you do.

That is a very different assumption from most modern software.

Reading as an intentional act again

Using Elfeed reinforced that shift.

Reading RSS inside Emacs is not about consumption efficiency. It is about removing everything that competes with attention.

There is no feed designed to keep me scrolling. No interface trying to predict what I want next. Just a list of entries that I explicitly chose to follow.

Because I did not grow up with RSS, I don’t associate it with “going back” to anything. Instead, it feels like discovering a different set of design choices that were never part of my default experience.

Communication systems that don’t try to be platforms

The same pattern appears again with email and mailing lists.

I didn’t experience mailing lists as a primary communication medium. My default expectation was always platform-based messaging: centralized systems, profiles, and interfaces designed around immediacy.

But mailing lists operate differently. There is no feed optimized for engagement. No hidden ordering of messages. Everything is delivered as plain, structured conversation.

This is also where systems like SourceHut become interesting. They don’t try to abstract communication into a platform layer. Instead, they lean directly on existing primitives like email and patches, treating them as first-class workflows.

The result is slower communication, but also more transparent communication. Nothing is hidden behind an interface designed to shape behavior.

Reclaiming ownership with static sites

This entire blog is another example. It is built with Hugo, a static site generator.

For a long time, the easiest way to publish something online was to put it on a platform owned by someone else. You got an audience and an editor, but you gave up control over the presentation, the longevity, and the underlying data.

A static site is the exact opposite. It is just HTML, CSS, and Markdown. It doesn’t rely on a database that might become corrupted, or a platform that might change its business model tomorrow.

There is a quiet but growing movement around “Digital Gardens” and personal websites—spaces that are curated and owned by the author, rather than optimized for algorithmic discovery. Writing in plain text and compiling to static files feels less like creating content and more like building an archive.

The self-hosting mindset

Underlying many of these tools is the philosophy of self-hosting.

Using FreshRSS wasn’t just about the RSS protocol; it was about the realization that I could run the software myself. Instead of paying with my data or attention for a “free” Software as a Service (SaaS), I could rent a small server and deploy the tools I needed.

This changes the relationship you have with your software. When you host it, you are responsible for it, but you also have absolute sovereignty over it. It doesn’t try to upsell you, it doesn’t pivot to a new feature set you didn’t ask for, and it doesn’t shut down when a startup runs out of funding.

It is a heavier burden, but it is also a declaration of independence from the constant churn of the modern internet.

A different relationship with “old” technology

What makes all of this interesting is that I don’t experience it as nostalgia.

I don’t remember a time when these tools were the norm. I only encounter them as systems that still function, still evolve, and still serve specific purposes better than many modern alternatives.

That distance changes how I see them. They are not “old tools I used to use.” They are simply tools that exist, with different design assumptions.

And because I didn’t grow up with them, I am not comparing them emotionally to what came before. I am comparing them structurally to what I use now.

What these systems have in common

Over time, a pattern becomes visible across all of them.

They tend to assume:

• that communication does not need to be instantaneous
• that information should remain readable without mediation
• that users can control their own information flow
• that systems should be inspectable rather than opaque
• that simplicity is a long-term advantage, not a limitation

None of these ideas are inherently “old.” But they were implemented more consistently in earlier internet systems than in many modern ones.

Closing thoughts

The interesting part is not that these tools are old.

It is that they still work without needing to adapt to the assumptions of modern platform design.

Discovering them later in time creates a different perspective. There is no nostalgia involved, no sense of returning to something. Instead, there is a kind of structural clarity: realizing that the internet was not always built around attention, and does not have to be.

RSS, Emacs, mailing lists, SourceHut and static sites are not alternatives to modern tools because they are outdated. They are alternatives because they follow different principles.

And those principles are still valid

Thanks for reading. You can view the original article at Daniel López Blog, contact me directly, or send a comment to my mailing list.

El Reto: Programación sin barreras para los más pequeños

La Academia de Inventores nos planteó una misión clara: crear una plataforma de programación por bloques que fuera funcional, intuitiva para niños de entre 5 y 9 años, y que permitiera la interacción directa con hardware real (placas Arduino). Además, debía integrar Inteligencia Artificial para asistir a los pequeños inventores en su proceso de aprendizaje.

Así nació Hello Blocks! Kids^◊.

El ambiente en The Wave

El congreso no fue solo código y circuitos; fue un punto de encuentro increíble para la comunidad tech. Desde la entrada en el Palacio de Congresos hasta las salas llenas de energía, la atmósfera de innovación se respiraba en cada rincón.

Hello Blocks! Kids: Un entorno pensado para ellos

Nuestro enfoque fue priorizar la UX para un público infantil. Eliminamos la complejidad innecesaria y creamos un sistema visualmente atractivo y motivador.

1. Un mapa de aprendizaje lúdico

Diseñamos un sistema de niveles no lineal que transporta a los niños por diferentes retos, desde encender su primer LED en un faro hasta controlar motores más complejos.

2. CodePilot: La IA como mentora

Uno de los puntos clave del reto era la integración de IA. Desarrollamos a CodePilot, un pequeño robot asistente que no solo da instrucciones, sino que analiza el estado del código del niño y ofrece pistas contextualmente relevantes.

3. Programación y Hardware Real

Utilizando la Web Serial API, logramos que los bloques se tradujeran a código C++ de Arduino y se cargaran directamente a la placa desde el navegador, sin necesidad de instalar nada. El entorno incluye un simulador para que puedan probar sus algoritmos antes de volcarlos al hardware.

Arquitectura Técnica

Para lograr un sistema robusto y escalable en solo 24 horas, apostamos por un stack moderno y eficiente:

• Frontend: Desarrollado con React y Vite, utilizando Blockly para el motor de bloques y Framer Motion para las animaciones y micro-interacciones que dan vida a la interfaz.
• Backend: Una API en Node.js con Express que gestiona la persistencia de perfiles y la lógica de validación.
• Integración de IA: Implementamos un modelo de Mistral, consumido mediante un proxy desde Vite para mantener la seguridad de las claves y optimizar las peticiones del asistente CodePilot.
• Integración con Hardware: El backend incluye un flujo específico de compilación y carga para Arduino, permitiendo que el código generado por los niños se transforme en binarios ejecutables de forma transparente.

Conclusión

La Hackathon de The Wave fue una experiencia intensa pero increíblemente gratificante. Logramos desarrollar un producto mínimo viable (MVP) completamente funcional en menos de 24 horas, demostrando que la tecnología y la educación pueden ir de la mano para inspirar a la próxima generación de inventores.

¿Quieres verlo en acción? Puedes explorar la demo en hbk.demo.dlopez.eu.org.

¡Gracias a la Academia de Inventores y a la organización de The Wave por esta oportunidad!

Thanks for reading. You can view the original article at Daniel López Blog, contact me directly, or send a comment to my mailing list.

🛠️ Configuration & Setup

First things first: identify yourself to Git.

You can use --global to apply settings to all repositories on your system, or omit it for project-specific settings.

git config --global user.name "Your Name"

git config --global user.email "email@example.com"

🚀 Repository Initialization

Start a new project or grab an existing one from the cloud.

git init

git clone <url>

🔄 Daily Workflow (Staging & Committing)

This is where the magic happens. Move your changes from the working directory to the repository.

Status Check

git status

git add <file>

git commit -m "Descriptive message"

🌿 Branching & Merging

Branches are essential for working in parallel without affecting the main codebase (main).

Branching Concept

🏗️ Pull Requests (PRs)

A Pull Request is the way you propose changes to a repository and ask others to review them before they are integrated.

PR Merge Types:

• Standard Merge: Creates a “merge commit”, keeping the entire commit history of the branch.
• Squash and Merge: Combines all commits from the branch into a single one. Great for keeping a clean history.
• Rebase and Merge: Applies the branch’s commits one by one on top of the current base. Does not create a merge commit.

Use Draft Pull Requests if you want to showcase your work-in-progress but aren’t ready for official review yet.

🛠️ Workflow

The most common workflow on platforms like GitHub or SourceHut is:

1. Fork: Create a copy of the repository in your own account.
2. Clone: Download your copy locally: git clone <url>.
3. Branch: Create a branch for your change: git checkout -b my-improvement.
4. Commit: Make your changes and save them: git commit -am "Add X".
5. Push: Upload the branch to your remote: git push origin my-improvement.
6. PR: Open a Pull Request from the platform’s web interface.

🌐 Remote Operations

Sync your local work with a remote server (like GitHub or SourceHut).

git remote -v

git push origin <branch>

git pull origin <branch>

⏪ Undoing Changes

Mistakes happen. Here is how to fix them.

Caution

• Unstage a file: git reset <file>
• Discard local changes: git checkout -- <file>
• Undo last commit (keep changes): git reset --soft HEAD~1
• Revert a commit (safe): git revert <hash>

📦 Stashing

Need to switch branches but not ready to commit? Stash it!

git stash

git stash pop

🔍 Inspection & Logs

Understand the history of your project.

git log --oneline --graph --all

git diff --staged

🎓 Advanced Mastery

If you ever “lose” a commit after a bad reset, git reflog is your best friend. It tracks every move of the HEAD.

• Cherry-pick: git cherry-pick <hash> (Apply a specific commit from elsewhere)
• Reflog: git reflog
• Interactive Rebase: git rebase -i HEAD~n

Thanks for reading. You can view the original article at Daniel López Blog, contact me directly, or send a comment to my mailing list.

The Hardware Architecture

The system’s hardware is designed to simulate a real climate control environment:

• Core: The ESP32-S3 provides the necessary processing power and dual-radio capabilities (WiFi and BLE).
• Input: A 10k Potentiometer acts as an analog temperature sensor.
• Visual Feedback: Status LEDs (Green, Red, Blue) and a 7-segment Display for local readout.

The temperature reading is performed by mapping the internal ADC values:

// Mapping analogRead (0-4095) to a range of -10 to 60 degrees
tempActual = ((((analogRead(pot)) * 70) / 4095) - 10);

System Logic: The State Machine

The behavior of the thermostat is governed by a finite state machine that incorporates hysteresis ($H$). This is a critical concept in control theory to prevent rapidly switching the relay on and off when the temperature is exactly at the set point.

In the code, this is implemented within the loop() function using a switch statement that manages the transitions between NEUTRAL, CALENTANDO (Heating), and ENFRIANDO (Cooling).

Communication Protocols

The ESP32-S3 handles two concurrent interfaces:

1. Bluetooth Low Energy (BLE)

I implemented a custom BLE server with a specific callback class to handle remote commands. This allows for low-power configuration via a mobile app or terminal.

class MyCallbacks: public BLECharacteristicCallbacks {
  void onWrite(BLECharacteristic* pCharacteristic) {
      String value = pCharacteristic->getValue().c_str();
      if (value.length() > 0) {
          int comando = value[0] - '0'; // Command ID
          switch (comando) {
              case ESTABLECER_TEMP_OBJETIVO:
                  tempTermo = value.substring(1).toFloat();
                  guardarEEPROM("tempTermo", tempTermo);
                  break;
              // ... other commands
          }
      }
  }
};

2. Integrated Web Dashboard

The device also acts as a WiFi Access Point hosting a responsive web server. This interface provides a more user-friendly way to monitor and control the system.

The UI is designed to be clean and intuitive, following a modern “Glassmorphism” aesthetic:

• Real-time Monitoring: The current temperature is displayed prominently, fetching data from the /data JSON endpoint every 2 seconds.
• Dynamic Controls: Users can adjust the target temperature and hysteresis with a 0.5°C precision using interactive buttons.
• State Indicators: A color-coded status badge (“Heating”, “Cooling”, or “Optimal”) provides immediate context.

Non-Volatile Storage (Preferences)

To ensure the settings persist after a power cycle, I used the Preferences.h library, which interacts with the ESP32’s NVS flash partition.

void guardarEEPROM(const char* clave, float valor) {
    preferences.begin("TEMPERATURAS", false);
    preferences.putFloat(clave, valor);
    preferences.end();
}

Conclusion

This project successfully applied theoretical concepts of signal coding and data transmission in a practical IoT application. The combination of hardware control, wireless communication, and persistent storage makes this a robust prototype for smart home automation

Thanks for reading. You can view the original article at Daniel López Blog, contact me directly, or send a comment to my mailing list.