Trabajo de Fin de Grado - Desarrollo de un gestor de contenidos

Motivación

A lo largo de los distintos desarrollos de aplicaciones y webs que he realizado, me he encontrado con un problema recurrente al gestionar el contenido, que surge de la necesidad de usar herramientas externas, cuando este varía con frecuencia o hace falta generar contenido nuevo a diario, como ocurre en un blog, por ejemplo. Un blog es hoy en día una sección casi imprescindible en cualquier proyecto, y la primera vez que me enfrenté al problema de gestionarlo fue en el desarrollo de la web para la empresa Alien Ventures, donde optaron por contenido estático generado a mano por un administrador. Esta opción no es la mejor porque implica mucho esfuerzo de mantenimiento, pero es la que requiere menos desarrollo al principio, y por eso elegí hacerlo así. La segunda, y la que me hizo pensar en una alternativa mejor, fue mi web personal, donde la necesidad de incluir un blog y poder publicar de forma rápida y eficiente era imprescindible para mí.

Por mi experiencia, hay tres opciones para gestionar el contenido de un blog: cada vez que hay que publicar contenido nuevo, generar a mano el HTML (HyperText Markup Language) correspondiente, usar una herramienta existente que se encargue de esta tarea, o desarrollar tu propio sistema de publicación de contenidos.

Según la frecuencia con la que haya que actualizar el contenido de una página web o requiera añadir o eliminar contenido, la opción de generar o editar estos ficheros HTML puede ser viable o no, y también hay que tener en cuenta que entrar a editar código no es algo accesible para cualquiera.

Usar un sistema de gestión de contenidos, o CMS (Content Management System) como lo llamaré a partir de ahora, tiene una serie de ventajas, pero también un buen número de desventajas que veré a continuación y que han motivado este trabajo.

Desarrollar tu propia herramienta de publicación es una tarea laboriosa y compleja, que no está al alcance de un usuario básico o medio que quiera gestionar su blog personal o incluso el de una empresa.

Objetivos

Antes de empezar a desarrollar la aplicación, tenía una serie de requisitos esenciales. La herramienta se basaría en tecnología web, esto es porque es un área en la que no había profundizado mucho en el grado y quería ampliar mis conocimientos, ya que tiene mucha demanda en el mercado laboral, algo que he podido comprobar buscando trabajo.

La herramienta debe estar diseñada para que una persona sin conocimientos de programación web sea capaz de escribir un artículo y publicarlo. El contenido generado por el gestor debe ser contenido estático y optimizado para SEO (Search Engine Optimization), un concepto que veré más adelante. La aplicación, aunque basada en tecnología web, no significa necesariamente que se vaya a acceder a ella desde un navegador; de hecho, la aplicación que se va a desarrollar en este TFG será de escritorio y multiplataforma, de modo que los usuarios de Windows, Mac y Linux podrán instalarla en sus ordenadores y empezar a trabajar.

Este trabajo de fin de grado tiene como objetivo presentar y explicar la aplicación resultante, cumpliendo los objetivos marcados, así como dar una visión general de las soluciones actualmente disponibles y aportar más información sobre ellas.

Composición de una página web

Por mi experiencia como desarrollador web, una página, en su mínima expresión, es un documento HTML que define los elementos que el navegador tiene que representar en pantalla. Un documento HTML se compone principalmente de dos bloques: una cabecera donde se especifica información para los navegadores y los motores de búsqueda, como Google, entre otra información que también puede aparecer en esta cabecera. El otro bloque principal es el cuerpo de la página, donde mediante distintas etiquetas defino los elementos; estos elementos pueden ser de distintos tipos y es importante mantener una estructura, para que mi página esté bien diseñada y se interprete fácilmente.

A este documento se le pueden añadir otros lenguajes que aportan más funcionalidades y me permiten personalizar y dotar de funcionalidad a mi página. El lenguaje CSS (Cascading Style Sheets) me da la posibilidad de especificar el estilo concreto con el que quiero representar un elemento del documento HTML, por ejemplo, que un texto determinado tenga un tamaño de doce píxeles o que un bloque tenga un fondo rojo.

JavaScript es un lenguaje de programación que se puede ejecutar en el navegador, y da dinamismo a las páginas web, permitiéndome modificar elementos del documento HTML, lanzar eventos en respuesta a interacciones del usuario con la interfaz (hacer clic en un botón, hacer scroll...) o incluso hacer peticiones adicionales desde el navegador al servidor.

SEO

La optimización de páginas web para motores de búsqueda es hoy en día uno de los objetivos más perseguidos por las empresas al desarrollar una web. Aprendí esto trabajando en Arsys (proveedor de infraestructura cloud), donde posicionar una de tus páginas en los primeros resultados para una búsqueda determinada se traduce en un aumento de las ventas y, por tanto, en un aumento de los beneficios.

En distintas formaciones impartidas por agencias especializadas en SEO, aprendí que obtener una buena puntuación en los distintos motores de búsqueda existentes depende de muchos factores y de los algoritmos usados para puntuar.

Tu página cambia cada cierto tiempo, así que posicionar tu web es un trabajo de actualización continua. Aunque estos criterios pueden variar con el tiempo, generar una página web con una estructura correcta —por ejemplo, que no haya un h2 (subtítulo) por encima de un h1 (título)— o la velocidad con la que carga tu web, son atributos de la página que siempre favorecerán una mejor puntuación y que se buscarán en las páginas generadas con mi aplicación.

Lighthouse

Para evaluar la calidad de una web, voy a usar la herramienta Lighthouse. Lighthouse es un software de código abierto desarrollado por la comunidad e impulsado por Google para auditar webs [1].

A partir de una URL (Uniform Resource Locator), Lighthouse lanza una serie de cargas sobre tu web y analiza los resultados obtenidos, simulando estas cargas tanto para una versión de escritorio como para una versión móvil. A partir de los resultados obtenidos, Lighthouse da una puntuación de cero a cien en cuatro categorías distintas: rendimiento, accesibilidad, buenas prácticas y SEO [2].

La puntuación obtenida en cada una de las categorías es una media ponderada del resultado de cada una de las métricas que la componen. La categoría que más me interesa para este trabajo es el rendimiento; dentro de ella encuentro como métricas el speed index de la página, el tiempo total que la web permanece bloqueada al cargar, el tiempo en el que el navegador hace una primera representación gráfica del contenido, entre otras [3].

El resumen de las auditorías realizadas sobre las distintas webs se mostrará como ilustración, mientras que el informe completo se adjuntará como anexo por si el lector quiere consultarlo en profundidad.

¿Qué es un CMS?

Un CMS no es más que un software diseñado para ser usado por cualquier usuario, sin necesidad de conocimientos técnicos más allá del uso del programa, para la creación, edición y publicación de contenido, generalmente páginas web.

Hay distintos tipos de CMS, según el propósito para el que se vaya a usar, por ejemplo, un blog personal, una página de empresa o una tienda de comercio electrónico, entre otros propósitos.

Estos CMS gestionan bases de datos a través de una interfaz, usada por la página web para mostrar el contenido con independencia de los estilos, de forma que la manera en que se muestra se puede cambiar sin necesidad de modificarlo. Están diseñados para que, una vez implementados, puedan usarlos los editores, dejando las tareas de mantenimiento y actualización a los desarrolladores [4].

Historia del CMS

Los primeros CMS de la historia se basaban en comandos sencillos en el servidor que, gracias a la aparición del DOM (Document Object Model), que es la representación de la estructura del documento y que me da una API para manipularlo [5], eran capaces de modificar el contenido HTML que finalmente se sirve al cliente a partir de una base de datos.

Estos primeros CMS fueron creados por empresas para su propio uso, adaptándolos a sus propias necesidades entre 1990 y 2000. Desde entonces, estos CMS se han ampliado para incluir muchas más funciones para las empresas, que han visto simplificadas sus tareas de gestión de contenidos. Al mismo tiempo aparecieron CMS de código abierto disponibles para todos los usuarios, como WordPress (https://wordpress.org/), del que hablaré más adelante, Joomla (https://www.joomla.org/), que no solo permite gestionar contenido sino también crear foros, encuestas y calendarios entre otras funcionalidades, Drupal (https://www.drupal.org/), desarrollado por la comunidad con funcionalidades muy parecidas a las de Joomla, PrestaShop (https://www.prestashop.com/es) o Magento (https://magento.com/), estos dos últimos gestores orientados al comercio electrónico [6]. Todos estos CMS están desarrollados en PHP (Hypertext Preprocessor) y dependen del uso de bases de datos, un enfoque muy distinto al del gestor de contenidos desarrollado en este TFG.

Tipos de CMS

Hoy en día encuentro distintos tipos de CMS según la utilidad que se les vaya a dar [6], estos son:

• Los constructores de páginas estáticas están pensados para generar ficheros que no se van a modificar muy a menudo, como una página web que muestra información sencilla sobre una empresa. Wix (https://es.wix.com/) es un ejemplo de este tipo de constructor web [6].
• Headless, son gestores de contenido que separan el contenido y la presentación que hago de él siguiendo el modelo vista-controlador, donde el contenido no depende en absoluto de los estilos aplicados [6].
• Híbridos, son una mezcla entre constructores de páginas web y CMS headless; me permiten crear y editar mis páginas, pero al mismo tiempo puedo enviar contenido a plataformas headless [6].
• Las plataformas de experiencia digital, o DXP, son paquetes que incluyen todas las herramientas que necesita una empresa para automatizar el contenido en páginas web, aplicaciones y dispositivos IoT (Internet of Things), así como el aprendizaje automático de los datos generados [7].

Si me fijo en el modelo de comercialización de estos CMS, puedo distinguir tres tipos [8]:

• CMS de código abierto, este tipo de software no tiene coste de entrada, es el más habitual entre los gestores usados por el público general y es el modelo de comercialización que va a seguir mi aplicación [8].
• CMS propietario, estos CMS pueden ser propietarios de una empresa para uso interno y no se comparten con el resto de usuarios, o se venden mediante un proceso de licencias a terceros [8]. Aquí encontraría, por ejemplo, los gestores usados por los periódicos para sus páginas web.
• CMS como SaaS (Software as a Service), consiste en CMS alojados en la nube y que normalmente se pagan mediante suscripción [8].

WordPress

WordPress es un CMS de código abierto lanzado en 2003 por su fundador Matt Mullenweg, pensado originalmente para la creación de blogs en páginas web. Es un fork del ya desaparecido CMS b2/cafeblog [9]. Con los años, WordPress se ha convertido en una herramienta capaz de crear cualquier tipo de página web gracias a su evolución y a la multitud de extensiones y componentes desarrollados en PHP por la comunidad o por uno mismo, lo que le permite no ser algo que te limite a lo que traiga de base, convirtiéndose así en el CMS más popular hoy en día. Se dice que tiene una cuota del 30% de todas las páginas web del mundo [10] [11].

Auditoría web

Me parece interesante, a modo de prueba, ver cómo se comporta un WordPress recién instalado al auditarlo con Lighthouse. Para ello he instalado WordPress en mi servidor web y no he hecho ninguna configuración ni modificación del contenido que viene por defecto; está con el tema por defecto y sin ningún plugin añadido. Este es el resultado de la auditoría.

A la vista de los resultados obtenidos en el Anexo A, puedo decir que he conseguido una buena puntuación; sin embargo, llama la atención que, sin haber añadido absolutamente nada a WordPress, no se obtenga una puntuación de cien de serie en rendimiento. No obtener la puntuación máxima en SEO es algo que entiendo, ya que esta valoración depende de completar unos metadatos usados después por los motores de búsqueda que no se han completado.

Para añadir funcionalidad a mi web, WordPress ofrece la posibilidad de instalar plugins de terceros, desarrollados por la comunidad. Cada uno de ellos tiene un comportamiento distinto y puede llegar a ser complicado usar un plugin para casi cualquier cosa que quieras añadir. A medida que tu sitio WordPress se hace más grande, más complejo y tiene más contenido, es prácticamente imposible mantener alto su rendimiento, obteniendo valoraciones pésimas de Lighthouse. Por ejemplo, TechCrunch, uno de los portales de tecnología más famosos del mundo, está hecho con WordPress, y a continuación puedo ver el resultado de su auditoría en el Anexo B.

Es lógico pensar que, a medida que aumenta la complejidad de una web, es muy difícil mantener un buen rendimiento, y todavía más difícil mantenerlo con WordPress, porque llegas a perder el control de toda la ejecución y las peticiones que existen por detrás.

¿Por qué no uso WordPress?

WordPress es una herramienta muy potente y útil precisamente para la tarea que necesitaba, implementar un blog en mi web personal; sin embargo, nunca fue una opción válida para mí. Uno de los mayores problemas que encontré fue que necesitaba una herramienta capaz de gestionar solamente el contenido con total independencia de dónde se fuera a insertar, ya que el resto de la web ya estaba construida con desarrollo propio, así que insertar un blog de WordPress requeriría la laboriosa tarea de crear un tema que replicara exactamente la interfaz y el comportamiento del resto de mi web.

Acceder al panel de gestión a través del navegador y tenerlo alojado en el servidor es una forma de exponer innecesariamente la plataforma a posibles intrusiones no deseadas o ataques maliciosos; por este motivo decidí hacer de mi aplicación una aplicación de escritorio, protegiéndola más del mundo exterior al tenerla localmente en mi ordenador.

WordPress añade demasiada funcionalidad y código que se vuelve innecesario cuando solo necesitas una tarea concreta, en mi caso una gestión sencilla de artículos, así que veo mejor otra herramienta enfocada específicamente a lo que necesito y que no añada más código del necesario. Crear estas páginas de forma dinámica es otro motivo por el que no estoy dispuesto a usar la herramienta, ya que el contenido de mi web debe ser estático y el objetivo es conseguir el mejor rendimiento posible, evitando consultas a bases de datos o ejecuciones en el lado del servidor.

Petición de un documento HTML

Un usuario pide al navegador acceder a un recurso a través de una dirección URL; esta dirección no es más que un alias que los servidores DNS (Domain Name System) traducen a una dirección IP (Internet Protocol) perteneciente al servidor web donde está alojada la página. El navegador envía una petición HTTP/HTTPS (Hypertext Transfer Protocol Secure), con sus cabeceras y el método correspondiente, al servidor web. Usando las cabeceras, el servidor web responde con el recurso que el navegador interpretará después. Aparte de los elementos que componen el recurso, se pueden especificar recursos adicionales necesarios para la construcción final de lo que el usuario podrá ver; estos pueden ser hojas de estilo, código JavaScript, fotografías, vídeos... Es al encontrar estas referencias cuando el navegador pide al servidor web estos recursos adicionales, que se envían de vuelta.

Uno de estos recursos que pide el navegador puede ser un documento HTML, y este no tiene por qué estar completo en el momento previo a la petición, sino que se puede generar o modificar en el momento de la petición o a posteriori. Durante todo este proceso encuentro distintos pasos hasta obtener un resultado final.

Modelo de mi aplicación

Teniendo en cuenta que el objetivo de mi aplicación es gestionar el contenido de una página web, tiene sentido pensar que el modelo perfecto a seguir es la ejecución en el lado del servidor consultando bases de datos de donde obtener el contenido de cada uno de los artículos del blog, y quizá usar algún tipo de framework de JavaScript para la generación de la interfaz. Esta es la forma más usada y habitual de hacerlo; sin embargo, por mi experiencia como analista SEO, este modelo no es el óptimo por varios motivos.

Los motores de búsqueda como Google, hoy en día, recorren Internet consultando las páginas existentes e indexando su contenido en sus páginas de resultados. En concreto, Google renderiza tu página web dos veces: una, y la más importante de las dos, simulando estar en un dispositivo móvil, y una segunda vez, simulando estar en un escritorio. Durante el proceso de renderizado toma varias capturas de pantalla en distintos momentos del proceso de carga. Cuando tienes HTML generado desde cero en el cliente, te aseguras de que, cuando Google hace una captura de tu web para comprobar el contenido visible, este está presente. Esto lo consigo tanto con ficheros estáticos que después no requieren peticiones adicionales del cliente, como con páginas generadas en ejecución en el servidor. Sin embargo, cuando uso frameworks de JavaScript del lado del cliente, me arriesgo a que, cuando Google compruebe mi web, parte del contenido, o el más relevante, todavía no se esté mostrando y por tanto no se indexe en los resultados de búsqueda; esto ocurre porque Google no se queda mirando tu web indefinidamente, sino que espera unos segundos mientras toma las capturas y se va. Como uno de los objetivos de las páginas generadas con mi aplicación es favorecer la optimización en buscadores, uso HTML con todo el contenido embebido en él.

Otro objetivo que me marqué es intentar que el tiempo de respuesta al consultar la web sea lo más corto posible, y por otro lado, también quería que la aplicación y los ficheros de contenido que genera fueran independientes del servidor donde se vaya a alojar la web y de las tecnologías que pueda tener, de forma que no sea un requisito que el servidor tenga PHP o NodeJS, sino que se pueda usar en cualquier tipo de servidor web. Por eso se descartó la ejecución en el lado del servidor, y por tanto también se descartó el modelo de consulta a bases de datos, reduciendo así los recursos del servidor, las llamadas y los tiempos de espera.

NodeJS

Los lenguajes de scripting están pensados para usarse junto con otros lenguajes de programación o de marcado como HTML; estos lenguajes se interpretan y no requieren un proceso de compilación previo a la ejecución del código [15].

Uno de los lenguajes de scripting más populares del mundo es JavaScript; este lenguaje orientado a objetos se incorporó primero en el navegador Netscape y lo copió Microsoft en Internet Explorer con el nombre de JScript. Desde entonces, JavaScript no ha dejado de aumentar en popularidad y funcionalidad [16]. Junto con la aparición del DOM, los programadores web son capaces de manipular los elementos de la página y crear dinamismo en ciertos elementos o en las interacciones del usuario con la interfaz. JavaScript lo interpretan motores de JavaScript integrados en los navegadores; por ejemplo, Google Chrome usa un motor de código abierto escrito en C++ llamado V8.

Teniendo en cuenta la popularidad y utilidad de este lenguaje de scripting, tiene sentido la idea de poder usarlo fuera de los navegadores, ya sea en un ordenador personal o en un servidor. NodeJS es un intérprete de JavaScript, que usa el motor V8 de Google, basado en la ejecución de eventos asíncronos, diseñado principalmente para aplicaciones de red que puedan ser escalables [17].

Para gestionar las llamadas asíncronas, NodeJS incorpora la posibilidad de enviar funciones en las llamadas como callbacks, que se ejecutan una vez ha terminado el proceso. Una de las ventajas es que los procesos nunca se bloquean, y está diseñado para funcionar sin hilos, aunque existe esa opción si el desarrollador lo desea [18].

Personalmente, usar NodeJS para desarrollar aplicaciones de escritorio, así como para la ejecución en el servidor, es una gran ventaja porque unifica el desarrollo de Back-End y Front-End en un único lenguaje, JavaScript. Esto siempre supone un mantenimiento más sencillo y menos trabajo de especialización del desarrollador en distintos lenguajes. Gracias a las llamadas asíncronas, puedo conseguir fácilmente mejor rendimiento que en un lenguaje concurrente.

NodeJS, por mi experiencia, es una tecnología en auge cada vez más presente en todos los desarrollos informáticos y que no se ha estudiado en el grado, que es también el motivo por el que aprovecho mi trabajo de fin de grado para obtener información y habilidades con esta tecnología.

Electron

Electron es un framework para desarrollar aplicaciones de escritorio multiplataforma con JavaScript, propiedad de Github, que a su vez es propiedad de Microsoft. Ofrece una serie de APIs (Application Programming Interface) a nivel de sistema operativo, y usa Chromium para mostrar páginas web como interfaz.

Arquitectura

Para el correcto funcionamiento de la aplicación solo hace falta tener un servidor web y un dominio que resuelva a la dirección IP y al directorio donde GdB sincroniza los ficheros HTML. Al ser contenido estático, este gestor de contenidos es compatible con servidores Apache con PHP, servidores NodeJS o cualquier otro tipo de servidor web. No hace falta ninguna base de datos.

GdB se instala en el ordenador del usuario que va a gestionar el contenido de la página web; una vez configurada correctamente, esta aplicación se comunica por SSH (Secure Shell) con el servidor web. A través de este túnel cifrado, GdB es capaz de subir o eliminar ficheros HTML que después se servirán a un navegador por HTTPS.

Una de las ventajas de tener la aplicación instalada en el ordenador es la posibilidad de hacerla compatible con un modo de edición de contenido offline y sincronización posterior con el servidor web. Esta funcionalidad no está implementada en este TFG y queda como una posible mejora futura.

Estructura de ficheros

La aplicación consta de unos pocos ficheros principales en el directorio raíz y algunas carpetas donde se concentran los distintos recursos y funcionalidades de la aplicación.

Panel

Como he comentado antes, el panel se compone de un único fichero HTML sobre el que cargo y descargo, muestro y oculto contenido desde el JavaScript. El primer paso para la generación de la interfaz es la creación de la ventana desde el Back-End; para ello, el framework me da el objeto «BrowserWindow», en el que especifico que el ancho y el alto de la ventana serán por defecto 1200 píxeles, siendo el alto y el ancho mínimos permitidos 800 píxeles. Además, elimino el marco por defecto del sistema operativo para después crear y gestionar yo mismo los eventos de la ventana.

El panel consta de tres elementos básicos: una cabecera, un menú lateral y la sección donde se muestra el contenido. A continuación se puede ver el panel vacío, sin ningún módulo cargado.

Tanto la cabecera como el menú lateral tienen una posición fija, así que no se ven afectados cuando ocurre el evento de scroll. La sección principal del panel, donde aparecerá el contenido de cada sección del menú, tiene márgenes internos arriba y a la izquierda para que los otros dos elementos no se superpongan sobre el contenido. En la cabecera he incluido mis propios iconos para minimizar, maximizar y cerrar la aplicación.

Panel modular

Una de las intenciones de este panel es que estuviera abierto a nuevos desarrolladores que quieran usarlo para aplicaciones distintas con otros usos, por eso la funcionalidad de moverse por los módulos del menú y cargarlos en el panel es independiente del propio gestor de contenidos. Tiene dos peculiaridades que lo hacen modular.

Carga automática de JavaScript

El JavaScript que usa la aplicación desde el Front-End, como en las páginas web, se referencia desde el fichero HTML que especifica que lo necesita. La aplicación necesita muchos JavaScript distintos; sin embargo, desde el único HTML que tengo solo referencio uno, «auto.js».

Para contener mi código JavaScript, uso un objeto que contiene todos los métodos que necesito. Para generar esta carga automática de JavaScript he creado un objeto proxy que actúa de intermediario entre cualquier llamada a un método del objeto y el propio objeto.

El objeto proxy se ha llamado «auto»; las únicas condiciones al crear un fichero JavaScript nuevo son que sea una extensión de este objeto y que el fichero se llame igual que el método que implementa. Cada vez que llamo a un método de este proxy, comprueba si este método existe en el objeto final. Si existe, procede a llamar al método; si no, el proxy busca en el directorio «auto» un fichero JavaScript con el mismo nombre que el método pedido, y por último inserta una nueva etiqueta «script» en el HTML incluyendo este fichero.

Con todo esto consigo que incorporar scripts nuevos en este panel sea tan fácil como crear un fichero nuevo en el directorio «auto» y sin tener que incluir su carga en el HTML; la primera vez que se llame a ese método se cargará automáticamente. Como no se cargan todos los scripts al principio, ahorro tiempo en la primera instancia, y solo llevo a cabo la carga cuando es realmente necesario.

Eventos en el Back-End

He visto cómo, desde el proceso principal, he creado la ventana donde se muestra la interfaz de la aplicación; aparte de esta función, desde aquí gestiono todas las llamadas que vienen del Front-End.

Por ejemplo, como he eliminado el marco del sistema operativo de la ventana, los iconos que se muestran en el HTML, una vez que se hace clic en ellos, el evento lo recoge el JavaScript del lado del Front-End, pero este no tiene la capacidad de ejecutar las instrucciones de Electron para realizar la tarea correspondiente. Lo que hacen estos eventos es enviar un mensaje al Back-End indicando que se quiere realizar esta tarea, y esto lo ejecuta el proceso principal.

Estos eventos se pueden haber enviado de forma síncrona o asíncrona; en el caso de los eventos síncronos, enviaré una respuesta de vuelta al Front-End para que pueda continuar con su ejecución.

Configuración de la aplicación

La primera vez que ejecutas la aplicación, una vez instalada en tu ordenador, aparece un proceso de configuración sencillo para indicar la dirección y las credenciales del servidor web que se va a usar.

El campo «Server» acepta tanto la dirección IP de un servidor como un dominio que resuelva a esa dirección IP. Los campos «Username» y «Password» corresponden a las credenciales SSH del servidor; preferiblemente, y para evitar problemas de permisos, se recomienda que el usuario indicado sea root. El campo «Path» especifica el directorio en el que tiene que trabajar la aplicación; este directorio tiene que estar dentro de los directorios del servidor web y tiene que poder resolverse la petición a estos ficheros por HTTPS.

Cuando el usuario pulsa el botón «START», la aplicación procede a establecer una conexión SSH con el servidor; esta conexión se consigue usando la librería «node-ssh» de NPM. Lo primero que hago es ejecutar el comando «ls» en el directorio indicado por el usuario y comprobar que no exista ya una carpeta llamada «blog», que es el nombre del directorio que usa la aplicación. Como lo estoy configurando por primera vez en un servidor donde nunca se ha conectado esta aplicación, este directorio no existirá, así que por SSH creo el directorio con otro directorio dentro llamado «data», que usaré para almacenar las credenciales de inicio de sesión. Por último, antes de terminar este proceso, genero un fichero JSON que guardaré localmente con los datos introducidos por el usuario; así, la próxima vez que entre en la aplicación, antes de pedirlos, comprobará si existen en este fichero, y si es así, se saltará este paso y leerá el JSON para tener las credenciales y poder establecer la comunicación.

Ya tengo la conexión establecida con el servidor, pero no tengo ningún usuario creado; esto es porque, al hacer SSH y un «ls» en la carpeta «data», no hay ningún «users.json», así que la aplicación me pide crear uno nuevo.

Una vez que el usuario hace clic en «SIGN IN», lo primero que compruebo es que ambas contraseñas introducidas sean idénticas; si es así, procedo a generar el usuario. Generar un usuario no es más que crear un fichero JSON con los datos; como este fichero residirá en el servidor, no puedo guardar la contraseña en claro, así que la paso por una función hash segura. Para esto uso la librería «bcrypt», en concreto el método «hash», que usa una función hash de implementación propia, a la que indico como argumento el número de rondas por las que pasará la contraseña, cada una de ellas con una sal distinta. Una vez que tengo el hash de la contraseña, genero un fichero «users.json» donde guardo todos estos datos y lo subo al servidor, al directorio «data».

El propósito de este trabajo no es crear una aplicación totalmente segura, y por eso no he profundizado más en la seguridad de las credenciales. Por la naturaleza de la aplicación, no es posible acceder al proceso de autenticación desde fuera, ya que la aplicación reside localmente en tu ordenador, pero, como la carpeta «data» reside en el servidor y contiene información sensible, se recomienda que el usuario no haga esta carpeta accesible mediante petición HTTP/HTTPS. Este tipo de reglas, en servidores web como Apache, se pueden especificar en el fichero «.htaccess». Para futuras actualizaciones de la aplicación sería interesante reforzarla para evitar posibles ataques y manipulaciones no deseadas de las páginas web generadas.

Inicio de sesión

Para poder usar la aplicación, hace falta pasar por un proceso de autenticación y autorización, para evitar que otra persona con acceso a tu ordenador pueda modificar la web. Este proceso también será importante para funcionalidades posteriores de esta aplicación, como la diferenciación entre roles de usuario y los permisos que tiene cada uno, mejoras no implementadas en este TFG.

La aplicación descarga del servidor, cada vez que inicio sesión, la última versión del fichero «users.json». Una vez que tengo el fichero localmente, lo paso a un objeto JavaScript y comparo los campos existentes con los introducidos por el usuario; como la contraseña no está en claro, uso el método «compare» de la librería «bcrypt», que pasa la contraseña en claro introducida por el usuario por la función hash y determina si es correcta.

Una vez que el Back-End le comunica al Front-End que el proceso ha sido correcto, procede a ocultar el cuadro de inicio de sesión y a cargar los módulos de la aplicación en el panel, como se ha explicado antes.

Tema oscuro y tema claro

Siguiendo la tendencia actual en los front ends web, las aplicaciones móviles y las aplicaciones de escritorio, GdB tiene soporte tanto para el tema oscuro (el visto hasta ahora) como para el tema claro.

Para desarrollar una única interfaz independiente de los colores, he desarrollado todas las reglas CSS referidas a colores usando, en vez de valores fijos, nombres de variables referidas a niveles de oscuridad. En concreto, la interfaz se mueve en siete tonos, es decir, siete niveles de color, que por detrás pueden ser lo que se quiera siguiendo una escala dentro del mismo rango.

Para decidir qué rango se aplica a la interfaz, se aplican variables CSS que contienen los colores a distintas clases del elemento «body» del documento HTML. Si el «body» no tiene ninguna clase definida, por defecto la interfaz es clara; sin embargo, cuando añado la clase «invert» se vuelve negra, esto ocurre porque sobrescribo las variables con esos colores y automáticamente cambian todos los elementos de la interfaz.

Módulo editor

Un gestor de contenidos debe tener un editor de texto que ofrezca a sus usuarios una interfaz sencilla donde escribir. El módulo encargado de esto se llama «editor»; se ha diseñado siguiendo una estructura de bloques, de ahí el nombre «gestor de bloques», en la que cada elemento para insertar contenido es un bloque. Cada uno de estos bloques consta de dos elementos, el texto del bloque y su tipo.

Un post de blog en este gestor de contenidos no es más que una sucesión de bloques, en la que cada uno de ellos tiene su propio espacio donde escribir el texto y un selector abajo a la derecha que me permite definir si el texto es un párrafo, título, subtítulo o cabecera. Los botones de la parte inferior izquierda de cada uno de estos bloques me permiten:

• El botón de más me permite añadir un bloque nuevo, que se insertará justo debajo del bloque desde el que estoy haciendo clic en el botón.
• El botón de menos me permite eliminar el bloque en el que estoy en ese momento.
• El botón de flecha hacia arriba permite mover el bloque una posición hacia arriba.
• El botón de flecha hacia abajo permite mover el bloque una posición hacia abajo.

Interfaz del módulo

Cuando voy a crear un artículo nuevo para el blog, entro al módulo editor del panel; por defecto solo aparece un bloque de tipo título, es decir, un «h1». Este bloque es el único al que la aplicación no permite cambiarle el tipo, ni moverlo de posición respecto a otros bloques; esto es porque, por buena práctica al generar una web, todas deben contener un único «h1» y este debe estar situado al principio, ya que los motores de búsqueda dan mucha relevancia a su contenido para indexar resultados. Otros bloques posteriores tampoco permiten cambiar el tipo a título, para evitar tener más de un «h1» en la página.

Para una escritura más rápida, además de los botones disponibles en cada uno de los bloques, creo eventos que se disparan al pulsar ciertas teclas del teclado, como enter, que tiene el mismo comportamiento que el botón de más; las flechas del teclado me permiten moverme rápidamente entre los distintos bloques.

Cuando añado un bloque nuevo, lo que hago es generar el HTML del bloque desde el JavaScript e insertarlo después del bloque desde el que se está añadiendo. Lo mismo hago al eliminar o moverme entre bloques; son todo eventos de JavaScript que alteran el DOM para cumplir la funcionalidad de cada uno de los botones.

Abajo a la derecha encuentro un botón que, al hacer clic, muestra otros dos: con uno puedo guardar el artículo y con el otro accedo a los campos que tengo que rellenar con los metadatos del artículo.

Plantilla

Como ya he mencionado, uno de los objetivos es poder añadir este blog sobre páginas ya desarrolladas. Para que la exportación de los bloques se haga en un HTML adaptado a la página web en la que irá este blog, es tan fácil como añadir una plantilla en el directorio destinado para ello dentro de la aplicación.

Una plantilla se compone de tres SHTML distintos (un trozo de HTML que se inserta en algún sitio), y usa un sistema de marcado para su posterior sustitución, buscando palabras clave que se sustituyen por contenido. La idea es dividir la estructura HTML de tu página web actual en dos partes: por un lado, todo el HTML que debe ir por encima del contenido del artículo que vas a publicar (menú web, cabecera...) y, por otro, el código HTML que debe ir por debajo del artículo (footer, menú inferior...). El nombre dado al SHTML superior es «up.shtml» y al inferior «down.shtml». El tercer SHTML necesario es el que define la estructura HTML con la que se mostrará cada una de las entradas de artículo en la página principal del blog, desde la que se puede acceder a cada uno de los artículos.

En la ilustración 14 se puede ver la estructura definida para exportar cada una de las entradas tal como quiero que se vean en mi web, donde «#url#» se sustituye por la URL que lleva al post en cuestión, «#title#» por el título del artículo, «#description#» por la descripción general del artículo y, por último, «#date#» por la fecha en la que se escribió. Esto, una vez en el servidor y con el CSS de mi web, se vería así.

Módulo buscador

Este módulo me permite visualizar las páginas existentes de mi blog, con la posibilidad de modificarlas, eliminarlas o establecer si en la siguiente sincronización tienen que estar online en el servidor web, o en el caso contrario, establecer que no se sincronicen y existan solo localmente en mi ordenador.

Cuando entro en este módulo, el código escanea el directorio donde están los ficheros JSON que se generan cada vez que creo una página nueva; para cada uno de estos ficheros, añade una entrada nueva en la interfaz con los datos de la página en cuestión, que se obtienen de este mismo fichero JSON, en concreto el nombre de la URL y la fecha en la que se creó la página.

Más tipos de bloques

Como se ha mencionado antes, esta demo solo contiene cuatro tipos de bloques distintos: título, subtítulo, cabecera y texto. Sin embargo, para que los usuarios puedan escribir un artículo, hace falta darles alguna herramienta más, como bloques de imagen o bloques de código fuente, si el blog pertenece a un desarrollador.

Un bloque de imagen es algo más complejo que cualquier bloque de tipo texto por dos motivos: la vista previa de la imagen en el bloque una vez insertada por el usuario, y la funcionalidad de cómo insertar la imagen. Para resolver esto último de la forma más profesional posible, haría falta maquetar un input de tipo «file» con una sección grande que también admita arrastrar un fichero dentro (drag and drop); Electron incorpora en su API una funcionalidad específica para esto.

Módulo de productos

Un gran porcentaje de las páginas web de hoy en día son de comercio electrónico, pequeños negocios que venden sus productos a través de una página web. Uno de los objetivos futuros de este gestor será incorporar un módulo nuevo que permita crear un catálogo de productos; esta sería la forma de monetizar la aplicación, ofrecer a los usuarios una pasarela de pago propia del gestor y cobrar una comisión por cada venta realizada en páginas web creadas con mi aplicación.

Modo offline y sincronización asíncrona

Una de las ventajas de ser una aplicación de escritorio es que se podría implementar de forma que se pudiera usar sin necesidad de tener conexión a Internet. Esto se podría implementar usando el último fichero «users.json» descargado del servidor para el inicio de sesión; todos los cambios en las páginas se registrarían en un JSON con el historial de cambios que después se podría contrastar con el servidor y las posibles modificaciones hechas por otros usuarios, para resolver posibles conflictos. Cuando el usuario vuelva a estar online, todos los cambios hechos durante el uso offline se sincronizarían automáticamente con el servidor.

Actualmente, durante el proceso de sincronización la aplicación se queda congelada mientras se realiza este proceso; si el volumen de elementos es muy grande, este proceso puede tardar varios minutos. Sería interesante que la ejecución de este proceso se hiciera de forma asíncrona respecto al resto de la aplicación, así podría seguir usándola mientras sincroniza.