+ Se agregó sección con diseño gráfico de nueva propuesta
+ Se agregaron secciones relacionadas con la base de datos
+ Se agregaron secciones con relación a patrones de arquitectura de software
+ Se agregó diagrama de "stack" de tecnologías
```
15 de Mayo
==========
H1P3RV1NCUL4R (Hipervincular)
-----------------------------
H1P3RV1NCUL4R es un nombre tentativo para la obra. En la idea previa había pensado en "friendly :)" como nombre de la red social para poder empezar a trabajar en como se vería. Estuve pensando en diferentes nombres para la nueva idea, pero me parece que este funciona bien en tanto es "neutral". No quiero connotar ninguna cualidad positiva ni negativa sobre las redes sociales para no generar expectativas por fuera de la parte de realidad virtual de la experiencia.
Se me ocurrió hacer un logo que represente la vinculación entre las personas que estarán en cada momento en la instalación. Como planteé que la experiencia sería para 8 personas en simultáneo, dibujé un octágono y uní con lineas todos sus vértices entre sí:
Estuve estudiando diferentes posibilidades para almacenar los datos extraídos de las redes sociales y, posteriormente, los datos procesados producto de diferentes técnicas de minería de datos aplicados sobre los primeros.
Existen dos tipos de bases de datos que podría usar para almacenar estos datos: las bases de datos relacionales y las bases de datos documentales.
Después de estudiar las pros y las contras de cada una, decidí optar por una base de datos relacional. En ésta, la información se almacena en tablas en las que cada columna define un tipo de datos y una clave (nombre por el cual se identifica a esa columna).
Las tablas no pueden tener tablas anidadas como sucede en las bases de datos documentales, así que voy a tener diferentes tablas que corresponden a lxs usuarixs y otras para cada tipo de dato recolectado para las redes sociales (por ejemplo, una tabla para fotos de Facebook, y otra para "tweets" de Twitter). Cada usuarix y cada foto (u otro elemento en otra tabla) va a tener un identificador numérico único. Lxs usuarixs van a tener una columna en su tabla que lxs vincule con las fotos. Esto parece complicado que tener una tabla de fotos dentro de una columna en la tabla de usuarixs (que es una posibilidad en las bases de datos documentales), pero de esta manera hay dos ganancias:
- Cada foto puede pertenecer a varixs usuarixs. Esto puede ser útil para determinar las relaciones entre usuarixs, en el caso de que otra persona haya sido etiquetada a en una foto, por ejemplo
- Las bases de datos relacionales son mucho más rápidas que las bases de datos documentales por diseño, por lo que puedo trabajar con el set de datos completos de manera más eficiente.
Existen muchas bases de datos relacionales, pero decidí usar PostgreSQL porque responde al estándar de SQL^[ Esto me permite reemplazarla por otra base de datos que también responda al estándar. <https://en.wikipedia.org/wiki/SQL_compliance>], está bien documentada^[ Sitio web de la documentación oficial: <https://www.postgresql.org/docs/>], y es más rápida para trabajar con JSON^[ JSON significa JavaScript Object Notation. Es un formato para intercambio de datos muy utilizado] que otras alternativas^[ Benchmark: <https://medium.com/@servikash/postgresql-vs-mysql-performance-benchmarking-e2929ee377d4>]. Esto es importante porque tengo en mente almacenar la respuesta de cada petición a la API, y estas están en formato JSON. Es muy importante hacer esto porque puedo hacer nuevas peticiones a la API a partir de peticiones anteriores, debido a que cada una tiene al final de su JSON un hipervínculo para pedir la próxima "página": cada petición a la API tiene una extensión máxima y en el caso de que hayan más datos disponibles, se debe hacer otra llamada con los próximos datos.
Ejemplo de tablas en base de datos relacional
---------------------------------------------
Un tabla para usuarixs con fotos asociadas de facebook podría ser la siguiente:
| ID | Nombre | Apellido | eMail | Edad | ID de facebook | Fotos de Facebook |
En este ejemplo, la foto con ID 6 es compartida por ambos usuarixs para ilustrar la potencial ventaja de usar bases de datos relacionales.
ORM y modelos
-------------
Para hacer modificar o acceder a los datos de una base de datos relacional que utiliza SQL, se puede utilizar una linea de comandos en la cual se estructuran "consultas" en un lenguaje que es muy similar al inglés plano. Sin embargo, desde el código de mi aplicación no puedo hacer esto directamente porque los lenguajes de las bases de datos no son lenguajes de programación y los tipos de datos que utilizan no son necesariamente compatibles con los tipos de datos de las estructuras de datos de lenguajes de programación. Para hacer poder trabajar con los datos de la base de datos se puede utilizar un mapeo objeto-relacional^[ ver más en: <https://es.wikipedia.org/wiki/Mapeo_objeto-relacional>]. En mi caso, como estoy trabando con JavaScript decidí utilizar Sequelize^[ Documentación: <https://sequelize.org/v5/>] que es muy utilizado (3 millones de descargas por mes, aproximadamente) y con un desarrollo activo.
Con Sequelize puedo definir "modelos" que definen que forma va a tomar mi base de datos, para asegurarme de no insertar datos en tablas incorrectas, o de no solicitar datos no existentes accidentalmente.
Patrón de arquitectura de software MVC
--------------------------------------
La idea de los "modelos" tiene que ver con un patrón de arquitectura de software llamado "Modelo-Vista-Controlador", en la que las responsabilidades del código se dividen en esas tres categorías. Los modelos definen la forma de la base de datos, los controladores como se interactua con esos datos (pueden ser funciones que hagan peticiones a la base de datos o alguna manipulación de los datos), y las vistas son lo que se le presenta a lx usuarix final.
En mi caso, no estoy usando un framework para desarrollar aplicaciones sobre este patrón de arquitectura de software, sino que estoy tomando prestados algunos conceptos y adaptándolos para tener una mejor imagen mental de que hice y que me falta hacer. La parte de las vistas que generalmente se resuelve de lado de servidor la voy a implementar en el cliente utilizando React, y parte del flujo de datos no responderá a este patrón, porque no está pensado para la comunicación en tiempo real que necesito implementar para la sección de realidad virtual
Sobre la realidad virtual
-------------------------
Para llevar desarrollar la sección de realidad virtual necesito resolver dos cuestiones:
- La representación de gráficos tridimensionales
- La comunicación en tiempo real
Para la primera parte, voy a utilizar three.js^[ Sitio web: <https://threejs.org/>], que es una biblioteca desarrollada para ésto y que esta construida sobre el estándar de WebGL. Para la segunda parte, tengo pensado utilizar Socket.IO^[ Sitio web: <https://socket.io/>], que es una biblioteca para la comunicación en tiempo real utilizando WebSockets
Accediendo a las APIs de las redes sociales
-------------------------------------------
Las redes sociales proveen una API que permite generar un token de acceso para poder utilizar las diferentes APIs o acceder a los datos de cada usuarix en la red social. Cada una tiene sus particularidades que dependen de las decisiones de diseño que tomó cada equipo de desarrollo, por lo que para poder utilizar cada una debería estudiarla. Para ahorrarme este paso, voy a utilizar Passport.js, que es una biblioteca para autenticar usuarixs en un servidor a través de diferentes métodos. La biblioteca provee métodos (llamados estrategias en su sitio web) para autenticarse con cada una de las redes sociales mayores, por lo que puedo aprovechar esta capa de abstracción para poder utilizar las APIs que necesito realmente de forma directa.
Diagrama de tecnologías
-----------------------
En el siguiente gráfico están diagramados los componentes (mayores) del software de la instalación y sus relaciones:
