--Originally published at Programming
Siento nostalgia al volver a escribir en este blog que comencé a utilizar hace dos años, pero me gusta ver todo lo que he avanzado desde el momento en el que puse un pie en la universidad. He adquirido muchos conocimientos y conocido profesores que además de tener pasión por la educación son buenas personas. Todo esto me ha ido forjando el camino hacia este famoso semestre i. Por eso, en este blog hablaré sobre mi experiencia técnica con la aplicación web y al montar la base de datos. Antes de comenzar me gustaría clarificar qué fue lo que hicimos en el semestre i para aquellos que no están familiarizados con el reto. Este reto se trataba de buscar una solución a la problemática del alumbrado público utilizando el internet de las cosas. Nuestra solución fue la implementación de alumbrado inteligente con un servicio en la nube de administración remota, el cual les permite a los administradores de forma sencilla visualizar datos y estadísticas, así como ver las fallas de las lámparas y asignar técnicos para la pronta reparación de estas.
Mi equipo de semestre i estuvo muy bien balanceado, teníamos personas con experiencia y conocimientos en diversas áreas. Por lo que la realización de la parte técnica del reto fue pan comido. Cada integrante se encargaba de lo suyo y luego compartía sus conocimientos a los demás integrantes del equipo para que todos supieran cómo lo hizo y cuáles eran las mejores prácticas. En mi caso, al ser estudiante de ISC, no me tocó meterme tanto en el microcontrolador, yo me encargué principalmente del diseño y la implementación de la base de datos y parte de la aplicación web. Como estudiante de computación pensarían que principalmente me enfoqué en la aplicación web, pero la verdad es que en nuestro había un electrónico muy fuerte en el área de desarrollo web y es que trabajaba en una empresa como full stack web developer. El lenguaje con el que está más familiarizado es Python con Flask como microframework para desarrollo web, lo que ocasionó un choque entre nosotros durante la primera etapa del semestre dado que yo tenía planeado realizar la aplicación web con PHP y Laravel. Al final quedó que la aplicación web se iba a realizar con Python para conservar el equipo unido y que no hubiera discusiones. Luego me di cuenta de lo sencillo que era usar Flask para crear una API, pero hablaré de esto más adelante.
Durante las dos primeras etapas del semestre, me enfoqué en diseñar e implementar la base de datos. Dado que en la primera semana de inmersión ya debíamos contar con una base de datos pequeña. Hicimos un diseño la verdad muy pobre, dado que no nos habíamos basado en requerimientos y la habíamos hecho al aventón. Solamente presentamos dos tablas, lámpara y microcontrolador con una sola relación entre ellas. Sinceramente uno de los peores diseños para una base de datos. Pero esto no me preocupaba, ya que sabía que el diseño era solo para probar la base de datos durante esa etapa, debido a que no teníamos bien definido los requerimientos de usuario ni del sistema. Algo que me molestó fue la ausencia de un cliente o usuario físico para nuestro sistema, ya que los requerimientos de usuario tuvimos que “inventarlos” por decir así, dado que no teníamos a alguien que nos dijera cómo quería el sistema. Intentamos hacerlo lo más acercado a la realidad, sin embargo, si era necesario tener a un cliente que te diga qué funcionalidades específicas quiere que tenga el sistema. Fue por ahí del final de la segunda etapa cuando acabamos de definir y profundizar nuestros requerimientos de usuario y del sistema, funcionales y no funcionales con la ayuda de nuestra maestra de base de datos. Con esto pude realizar el modelo de datos utilizando el diagrama entidad relación en formato de UML y mapeándolo a modelo relacional para conseguir las tablas de nuestra base de datos. Cabe mencionar que nuestras tablas se encuentran normalizadas hasta la tercera forma normal. Ya que teníamos definidas nuestras tablas tocaba pasarlas a nuestra base de datos.
Así como hubo discusión sobre qué lenguaje íbamos a usar para nuestra API, también tuvimos que decidir qué RDBMS íbamos a usar para nuestra solución. En clase de base de datos estábamos usando Oracle, sin embargo, yo ya tenía experiencia previa con MySQL. Aunque también fue sugerida por un compañero utilizar SQL Server de Microsoft. Después de ver lo tedioso que era montar un SQL Server en Azure y la falta de VPN para utilizar Oracle DB desde nuestras casas, decidimos montar MySQL en una máquina virtual en Azure. El proceso de instalación fue sencillo y comenzamos a usarlo de manera inmediata. Creamos la base de datos para nuestro semestre i y comenzamos a poner las tablas de nuestro sistema. Todo esto estuvo listo antes de nuestra segunda semana de inmersión para probar lo que llevábamos de nuestra interfaz para el administrador. La base de datos sufrió un par de cambios desde esa semana para mejorar nuestro sistema.
Tener una base de datos sin un lugar para mostrar los datos o hacer algo con ellos es prácticamente inútil. Por eso, en nuestra solución, decidimos implementar un sistema para los administradores y técnicos. En donde el administrador pueda ver datos y estadísticas generadas a partir de cada luminaria, ver ubicación de las lámparas en las colonias que administra y ver información detallada de cada reporte generado por una falla, los cuales son asignados a un técnico para la reparación. El técnico, por otra parte, tiene su propia interfaz en donde solamente puede ver los reportes que le son asignados e interactuar con ellos. También decidimos hacer una interfaz separada para que los ciudadanos puedan hacer sus propios reportes de lámparas. Estos reportes se marcan como generados por el usuario para no confundirlos por los que son generados automáticamente por las luminarias. Aquí es donde entra la API, ya que necesitábamos algo que uniera a los microcontroladores y las interfaces con la base de datos. Como mencioné, hicimos la API con Python. La primera parte de la API la hizo mi compañero para mostrar el avance que teníamos en nuestra segunda semana de inmersión. Luego, para la última entrega y para aprovechar lo más posible nuestra base de datos le hice algunos cambios y agregué algunas funcionalidades extras. Es aquí donde me di cuenta de lo sencillo que es Flask. Para que la API funcionara de la forma planeada era necesario saber primero qué datos queríamos regresar o modificar, una vez teníamos eso en mente, me encargué de diseñar las queries necesarias y realicé las funciones en Python, donde algunas regresaban archivos JSON para facilitar el intercambio de información.
Ahora bien, ya he hablado mucho sobre la base de datos y nuestra API. Por lo que falta describir más a detalle sobre dichas interfaces. Como mencioné, principalmente nuestro sistema de administración remoto cuenta con tres interfaces. Una para los administradores, otra para los técnicos y la última para ciudadanos. Para ingresar a las primeras dos se necesitan credenciales válidas. Para la interfaz del ciudadano no hemos definido muy bien si cualquier persona puede entrar o necesitan registrarse de alguna manera. La interfaz del administrador la realizó mi compañero utilizando un template que había encontrado en internet. Estéticamente se ve muy bien, sin embargo, tiene varios problemas. Uno de ellos siendo que utiliza una versión vieja de jQuery por lo que hubo varios inconvenientes para hacer que funcionaran algunas cosas, principalmente las peticiones Ajax. El problema de cambiar la versión de jQuery a la más reciente era que muchas cosas podían fallar así que decidimos dejarlo como estaba. Al fin de cuentas se trata solamente de un prototipo funcional y no un producto final. La interfaz para el ciudadano utilizó el mismo template. En cuanto a la interfaz del técnico, decidimos hacerla diferente. Yo me encargué de esta interfaz y la hice con un par de frameworks. Bootstrap 4 para ayudar con el diseño y Vue.js para tener una forma sencilla para mostrar la información, además de que ayuda a tener un código más limpio. Cabe mencionar que en esta interfaz sí se usó la versión más reciente de jQuery y el diseño de la interfaz es muy parecido a la de los administradores con el fin de mostrar consistencia en nuestro sistema.
Ya que la base de datos y la API estaban funcionando, nuestras interfaces estaban terminadas corriendo en servidores locales y el microcontrolador hacía correctamente su función, tocó integrar el sistema completo. Dado que habíamos trabajado modularmente y las pruebas ya se habían hecho por separado no hubo fallas en el funcionamiento del sistema y pudimos entregar un buen proyecto al final del semestre. Estoy consiente de que lo que tenemos es meramente un prototipo funcional que no fue realizado de la mejor manera. Sin embargo, lo que me llevo de este semestre es la experiencia, las habilidades adquiridas y el buen trabajo en equipo que realizamos. Al iniciar el semestre no tenía ni idea de cómo montar una base de datos en un servidor Linux, ni cómo levantar un servidor apache y mucho menos cómo hacer una API. Todo debe empezarse desde cero y nadie nace sabiendo cómo se hacen las cosas. Es por eso que me voy contento de este semestre con nuevos conocimientos y experiencias diferentes.
