Categorías
Desarrollo web Temporada 2

SleepTracker 0.1-b

La siguiente iteración del desarrollo de la app se centra en el ciclo de inserción y finalización de una entrada.

Inserción

Funciones

Lanzada al presionar el boton de nueva entrada, automaticamente genera una entrada con la fecha y la hora del instante de la inserción.

Para evitar duplicados, comprueba que en los últimos 7 eventos no haya ninguna inserción que se haya realizado en las últimas 12 horas: en caso de serlo, lanzaría un error.

Si todo está correcto, devuelve la nueva inserción.

Presentacion

Esta fase muestra disponibles aquellos botones que, dados los datos obtenidos, pueden ser usados por el usuario:

En un primer momento la idea era realizar una consulta al backend mediante la que obtener las últimas entradas y comprobar si estas estaban activas.

En esta primera versión he decidido que resultaba más sencillo comprobar simplemente si existía una entrada abierta y no permitir al usuario crear nuevas hasta no cerrar la abierta.


✅ En caso de no haber entradas activas, el link new sleep está activo.
❌ En caso de haber entradas activas, el link New Sleep está desactivado y aparece la opción de cerrar el ciclo

Finalización

Por último, activamos la opción de poder evaluar la entrada y cerrar definitivamente el proceso cambiando el flag de completed a TRUE.

De esta forma, el ciclo de entrada se reinicia, el usuario ya tiene la posibilidad de insertar una nueva entrada y la base de datos almacena la anterior como completada con los datos necesarios: fecha de inicio, fecha de fin y evaluación de la calidad del sueño.

La forma de presentar esta evaluación ha sido mediante una escala de estrellas donde 1 es el peor valor y 5 el mejor:

Con esto cerraríamos ya el proceso de inserción y nos podremos centrar a partir de ahora en el análisis de datos.

Categorías
Desarrollo web General Temporada 2

SleepTracker 0.1-a

Siguiendo con la idea de trabajar en mini-proyectos, hace unas semanas comencé a crear una aplicación web que fuera capaz de hacer un seguimiento de las horas de sueño.

Aquí la complejidad vendría de la mano de tener que desarrollar el stack completo:

Arquitectura

En la parte del servidor he creado un pequeño server con NodeJS y Express que monta una API sencilla sobre la que realizar las consultas.

Los datos están almacenados en una base de datos MongoDB que almacena todas las entradas, tanto las completadas como las que no.

Decidí que fuera la lógica del cliente la que decidiera qué valores mostrar.

La parte del front-end la estoy haciendo con una aplicación simple en React organizada por componentes con la lógica y las consultas extraídas de ella para manejarlas de forma más sencilla.

Diseño frontend

Ahora queda la parte más visual y la de tratamiento de datos.

Una vez comprobadas las conexiones y viendo que la aplicación web es capaz de obtener todos los datos del servidor he empezado a trabajar con ReCharts (https://recharts.org/en-US) para la presentación gráfica.

Lo cierto es que, por ahora, la forma de mostrar las gráficas está siendo bastante sencilla, pero me estoy empezando a encontrar problemas a la hora de personalizar bien los estilos.

Siguientes pasos

Voy a intentar perfilar un poco mejor la presentación gráfica, adecuando los estilos al diseño de la página y terminaré de añadir algunos de los componentes restantes.

Una vez que haya terminado la parte más visual, prepararé el diseño de la inserción de datos, que ha de dividirse en dos partes:

  • Nueva entrada: En el momento de ir a dormir, para marcar el inicio del tiempo.
  • Cierre de entrada: En el momento de despertarse, para marcar el fin del tiempo.

Esto se hará desde un acceso paralelo y mucho más simple para que se puede hacer de forma rápida desde el teléfono móvil.

Categorías
Desarrollo web

RecipeApp: Log 1

Esta es la última de las mini aplicaciones que quiero desarrollar en esta primera serie y, por tanto, es la que más complejidad quiero que añada.

Por eso, al hecho de implementar el front y el back como TypeScript, le quiero añadir la gestión de la API de recetas mediante GraphQL.

La API de recetas, además, deberá conectar con una base de datos MongoDB donde pretendo almacenar todas las recetas y sus ingredientes.

Mi intención es que el desarrollo de esta solución incluya la posibilidad de una mejora que permita integrarla en un sistema de gestión de recetas bastante más complejo, si llegase el caso.

Objetivos principales

Frontend

  1. Desarrollar un diseño responsive que permita su integración en dispositivos móviles.
  2. La aplicación va a estar gestionada desde una única página pero va a permitir el uso de rutas para acceder a las recetas.
  3. Todo el sistema estará desarrollado en TypeScript

Backend

  1. API conectada con base de datos MongoDB
  2. Gestión de la API mediante GraphQL estandarizando las queries y las mutations.
  3. El backend también estará escrito en TypeScript

Base de datos

Base de datos NoSQL con dos colecciones de documentos principales: recetas e ingredientes, relacionadas entre sí 1:n.

La gestión de los distintos elementos tipados la va a hacer la propia API, puesto que tendrá que añadir elementos de a los objetos definidos.

Así, mi idea es que los Intgredientes sean, en realidad, un objeto que incluya su ID, la cantidad y el peso.

Objetivos secundarios

La implementación del tipo Ingrediente puede abrirme a la posibilidad de introducir datos específicos de los ingredientes, esto es, información nutricional o el precio.

Aunque en la primera versión de esta aplicación no van a tener una utilidad real, quiero dejar preparada la estructura de datas para posibles futuras actualizaciones.

El problema que esto plantea es que su gestión genera alguna capa más de dificultad, tanto a nivel de la gestión de los datos, como de la interfaz de usuario a la hora de introducir nuevos ingredientes.

Categorías
Desarrollo web General

Trabajando en miniproyectos

Uno de los obstáculos con los que me estoy enfrentando a la hora de seguir mi aprendizaje en el mundo del desarrollo web es que los proyectos que inicio suelen eternizarse.

Esto, al final, tiene un efecto importante y es que afecta a la motivación y el interés por el proyecto y, por ende, en el aprendizaje, decae.

Excesiva complejidad = expansión en el tiempo

Cuando te lanzas a entender y comprender un nuevo lenguaje de programación y asimilas algunas de sus estructuras básicas y su potencia puedes tener la tentación de querer abarcar más de lo que eres capaz en realidad.

Como un Sísifo del código, te impones una roca demasiado grande y una montaña demasiado elevada.

A los numerosos parones a los que tienes que enfrentar tu motivación por tratarse de un constante proceso de aprendizaje, has de añadirle que el proyecto, por su propia complejidad, crece en el tiempo y se termina por eternizar.

Aquí es cuando el impulso inicial se diluye y, lo más normal, es el abandono prematuro del proyecto.

Agilidad, especificidad y retorno rápido

Con la idea de los mini proyectos, lo que busco es alcanzar los mismos objetivos de aprendizaje, pero segmentándolos en tareas cerradas más sencillas.

De esta forma, el proyecto tiene un principio y un final mucho más definido, se extiende mucho menos el tiempo y el retorno en forma de satisfacción al haber completado los objetivos es más inmediato.

Lista de mini proyectos

To Do App

Lista de tareas implementada con React & Typescript con un backend basado en SQLite.

Fue mi primer contacto con NES.css, un pequeño framework de CSS con un rollo pixelart muy divertido.

QuizApp

Sistema de preguntas y respuestas. Aquí también empleé React y TypeScript, aunque no desarrollé backend. En su lugar, gestioné las preguntas con un archivo JSON bastante sencillo.

La parte más interesante del proyecto fue su despliegue en Heroku y ver cómo respondía ante un acceso de un usuario externo.

Aplicación de recetas

En proceso.

Categorías
Desarrollo web

Client-side rendering vs Server-side rendering

En el momento en el que aterrizas en el mundo del desarrollo web, una tormenta de terminología te sacude dándote la bienvenida.

Uno de esos términos que aparentan ser complejos, pero que en realidad son una forma ‘cool’ de decir algo simple, es lo que se conoce como Client-side rendering (CSR) y Server-side rendering (SSR).

La comunicación web

Client-side rendering

El Client-side rendering (CSR) es el funcionamiento más común: nuestro navegador (cliente) realiza una petición de una serie de recursos y el servidor los devuelve. Entre ellos, los archivos Javascript (.js), que se ejecutan en el navegador del cliente, realizando así los procesos programados en el lado del cliente.

Server-side rendering

El Server-side rendering (SSR), en cambio, nos facilita una primera versión pre-renderizada del contenido de forma que mejoramos la velocidad de respuesta. El contenido servido se puede mostrar directamente en el navegador. No obstante, y esto es importante, la parte dinámica de nuestra aplicación no se procesa. Esto se hace con posterioridad, descargándose los archivos Javascript necesarios.

La diferencia es obvia, la primera versión estática pre-cargada en nuestro navegador se realiza de forma mucho más rápida y eficiente, mientras que la descarga de la parte más pesada y dinámica se realiza mientras el usuario ya tiene la posibilidad de ver contenido.

En una solución CSR, el usuario debe esperar hasta que se descarguen todos los recursos para poder interactuar con la página.