Configuración inicial: stack tecnológico, GitHub y estructura del proyecto

 

Fecha: martes 10 de marzo 2026

Hora de inicio: 6:30 pm

Hora de finalización: 10:00 pm

Horas trabajadas: 3 h y 30 min

 

Actividades realizadas

6:00 pm – 8:40pm

En primera instancia durante este tiempo, yo, JJ, estuve investigando un poco sobre que lenguaje/framework usar para el backend, ya que ni VB ni yo hemos trabajado nunca en desarrollo web ni en conexión de web browser con una base de datos. Después le pregunté a VB sobre que había investigado ella al respecto, y después de discutirlo llegamos a la decisión de usar Python + Flask para la parte de capa lógica.

Durante el proceso, además de Python+ Flask(decisión final), se tomaron en cuenta Java + Springboot, JavaScript (node.js), Python+Django, entre otros. Por motivos de tiempo (para este punto del proceso quedan 15 días para entregar el trabajo) y tomando también en cuenta los otros cursos que ambas llevamos, consideramos que lo mejor para un primer acercamiento es utilizar Python (lenguaje que ambas manejamos) y Flask, que, según nuestras investigaciones, es un microframework bastante flexible y una buena opción para personas que apenas se adentran al mundo del desarrollo web.

Divergencia de criterio

No fue exactamente una divergencia de criterio, pero en un punto, una vez decidido que íbamos a usar Python, no estábamos seguras si usar Django o Flask, fue algo que se mantuvo en discusión durante un tiempo, hasta que al final, después de cada una buscar información por su lado, decidimos usar Flask por ser mucho más amigable con programadores que nunca han hecho desarrollo web.

 

9:00 pm – 10:00pm

Posterior a tomar la decisión sobre que lenguaje/framework usar, decidimos que era momento de crear el repositorio en GitHub para llevar el control de versiones. Se creó el repositorio en mi cuenta personal (JohaJM) y lo cloné localmente usando git clone. Luego, abrí el proyecto en VS Code para crear la estructura base.

Problema

Durante el proceso me encontré antes un pequeño error al intentar hacer push para guardar los cambios, ya que el repositorio contenía el README.md generado automáticamente que no tenía localmente, por lo que al intentar subir la actualización dio el siguiente error: Updates were rejected because the remote contains work that you do not have locally.

Solución

La solución en realidad fue bastante sencilla, se resolvió ejecutando en el powershell git pull origin main --allow-unrelated-histories  y luego git push origin main –force.

Una vez resuelto ese pequeño problema procedí a configurar la estructura base para la tarea.

Imagen que muestra como quedó la estructura base de la tarea. Estructura sujeta a cambios según necesidad.

 

Forma de trabajo del equipo

Nos coordinamos por WhatsApp durante toda la sesión. Como fue una sesión más investigativa que otra cosa no fue necesario mandarnos muchas cosas en relación a avances o similar. Nos enviábamos links de videos que hablaran sobre el tema. Posteriormente, una vez creado el repositorio y la estructura base, le envié una invitación a unirse al repositorio y por medio del chat nos aseguramos que le aparecieran las actualizaciones que yo hice.

 

Buenas prácticas descubiertas

·        Al crear un repositorio en GitHub, es recomendable no inicializarle un README si ya hay código local, ya que va a generar un conflicto al realizar el primer push. Aunque es un error que se puede resolver fácilmente, es más sencillo crear el repositorio vacío y agregar el README después.

·        Antes de hacer push, siempre verificar con git remote -v (en caso de trabajar desde la terminal) que el repositorio remoto apunta al correcto. Es algo bastante básico, pero es muy fácil de olvidar.

Moraleja

Decidir la tecnología a usar antes de escribir una sola línea de código es más importante de lo que se pensó en un incio. Dedicamos más tiempo de lo esperado debatiendo entre Flask, Sprinboot, Django, Node.js, etc. Para el futuro es mejor evaluar la situación con base en criterios concretos desde un incio, como tiempo disponible, conocimiento previo, entre otros. En nuestro caso ya ambas conocemos Python (lo cual no ocurría con JavaScript, por ejemplo) y elegimos Flask, que es bastante sencillo para empezar, además, terminamos tomando en cuenta el tiempo que tenemos para hacer la tarea así como las partes no programadas de la tarea que también demandan tiempo y esfuerzo. De ahora en adelante, para elegir nuestros entornos y tecnologías vamos a evaluar varios factores primero para no invertir más tiempo del que es verdaderamente necesario.


Referencias:

Comentarios

Entradas más populares de este blog

Instalación del servidor

Creación de la base de datos y el primer stored procedure