Nivel 0: Mecánica de la materia + planteamiento de un proyecto para la misma

Principio ágil

Nuestra mayor prioridad es satisfacer al cliente a través de rápida y continua presentación de software valioso.

Por qué

Porque hay que saber formular problemas a todos los niveles, desde la creación de un producto hasta el resumen de un problema técnico que vaya a un issue o a una pregunta de StackOverflow.

Motivación

Esta materia tiene una serie de mecanismos específicos para su evaluación y entrega, los mismos que se usan en las empresas de desarrollo de software. Para superar este nivel, el estudiante debe aprender a usar correctamente estos mecanismos, así como entender el proceso de aprendizaje guiado que se va a llevar en esta materia.

A la vez, el estudiante tendrá que describir un problema general que se irá resolviendo en equipo, a través de la materia, usando software. Este problema podrá incluir un componente que se pueda desplegar en la nube. Este es el objetivo secundario: que el estudiante entienda el concepto de “problema”, de “cliente” y de “solución basada en la nube”; en general, para el desarrollo correcto de la materia, independientemente de que sea un proyecto para desplegar en la nube o no, conviene que se comprenda que no debe incluir ningún tipo de componente externo (en forma de servicios o de componentes materiales). El objetivo terciario es que empiece a desarrollar habilidades de trabajo en equipo, sintiéndose responsable tanto del propio trabajo como del trabajo del equipo en general.

Conceptos fundamentales

Cada nivel o sprint tiene una serie de conceptos fundamentales que tienes que asegurarte de entender antes de empezar. Si no es así, asegúrate de preguntar al profesor, compañeros, una IA como ChatGPT o buscar recursos en Internet para los mismos (validándolos con el profesor, si es necesario).

Git y GitHub: entender qué es un sistema de control de fuentes y nociones básicas.
Entre las nociones básicas tiene que incluirse saber qué es un pull request y su papel dentro del control de calidad de una organización, así como la transmisión de conocimiento dentro de la misma. Se puede consultar el documento de infraestructura, que muestra el punto de vista de esta asignatura, o cualquier otro tutorial sobre el tema.
Entender qué es una licencia de software y qué implica tener una en el repositorio.
Saber usar Markdown para crear ficheros con marcas estructurales y de apariencia.

TL;DR

Pensar en un problema a resolver que tenga entidad suficiente para poder llevar a cabo su desarrollo, en equipo, durante el resto de la materia.

Hago énfasis en el resto de la materia. Realmente habrá que intentar desarrollar un producto que resuelva parcialmente el problema que has planteado aquí. En el siguiente nivel se tendrán que plantear los hitos de desarrollo del proyecto y reflejar con más detalle qué problemas se van a resolver y para qué clientes, plasmando las necesidades del usuario, y en el segundo nivel comenzar a modelizar el problema de forma que se pueda empezar a trabajar en él en los niveles sucesivos.

En resumen: vas a tener que vivir con este proyecto, trabajar con él, hacerlo avanzar y darle cuerpo y realidad el resto de la materia. Tenlo en cuenta a la hora de plantearlo. Por eso es muy importante que pienses en un proyecto con el cual te sientas cómodo, entiendas a las personas que quieren que se resuelva el problema y, en general, sientas cierto interés por que efectivamente se resuelva.

Descripción

En este nivel inicial de la materia, y punto de partida del proyecto que se desarrollará en la misma, se trata de poner a punto las herramientas que se van a usar para mostrar el progreso del aprendizaje durante el resto del curso, a la vez que se busca que se interioricen una serie de buenas prácticas en desarrollo de software, que están siempre mediados por git en los entornos de trabajo actuales y que en general siguen el denominado manifiesto ágil.

Un factor esencial en el desarrollo ágil es la preocupación por la calidad. Una ingeniería debe ser capaz de proporcionar productos de calidad al cliente, y en esta materia se persigue que, en cada uno de los pasos, os preocupéis por la calidad de lo que entregáis. Por eso, se aconseja no os quedéis satisfechos con poner algo que parezca suficiente, sino que comprobéis que efectivamente muestra que habéis comprendido y puesto en práctica lo que se persigue que aprendáis en cada nivel. En este caso concreto bastará con que repaséis de forma crítica con vosotros mismos la lista de comprobación; más adelante, además, habrá que pasar algunos tests, pero una vez pasados los tests para poder entregar el nivel, la preocupación por la calidad os pide que efectivamente probéis manualmente que lo que se requiere en cada nivel es efectivamente lo que estáis entregando. Eso os servirá para asimilar mejor las prácticas de cada nivel, pero también para evitar trabajo por parte de quien corrige y también por vuestra parte, que tendréis que revisar el trabajo hasta que sea capaz de revisar el nivel.

Para ello, el equipo creará un repositorio que se usará durante el resto de la materia para mostrar el avance el proyecto en diferentes hitos en el desarrollo y despliegue de una aplicación.

Esto implicará primero crear una organización en GitHub, con todos los miembros del equipo, y a continuación un repositorio como parte de esa organización en el que tengan permiso todos los miembros del equipo.

El repositorio contendrá inicialmente:

Un fichero con el nombre, formato y extensión convencional, que explique de qué va a ir el proyecto, en qué va a estar basado y algunas referencias relacionadas con el mismo. El fichero sólo hablará del problema que se quiere resolver. Las herramientas (excepto el lenguaje) se irán decidiendo sobre la marcha (a partir del nivel 3).
Licencia que se va a usar en el proyecto, ya que se trata de un proyecto de software libre.
Otro fichero u otra serie de ficheros de uso habitual en repositorios.

En cuanto a la idea o problema que se quiere resolver, tiene que ser un problema del cual tengas conocimiento personal, preferiblemente. Cuanto más involucrado estés con el problema, o las personas que lo tienen, más interés vas a tener en hallar una solución al mismo y mejor entenderás qué sería lo que lo soluciona.

Otra cuestión es que ese problema /tenga entidad suficiente para poder crear, eventualmente, algún tipo de servidor que se pueda desplegar en la nube; es decir, tiene que tener descrita correctamente una lógica de negocio, que es el código propio que resuelve el problema. El centrarnos en la lógica de negocio (extraer información del texto de una página web ya descargada, por ejemplo) en vez de en los aspectos mecánicos (cómo obtener el URL de la página y cómo descargársela) permite que nos centremos en lo esencial de nuestro programa, que es lo que añade valor al cliente (no el hecho de que uno se descargue una página, o extraiga información de un API o como sea).

Propio quiere decir que toda la lógica de negocio tendrá que ser programada por el estudiante, principalmente en el nivel 5, y de ahí en adelante. Es decir, en este punto tienes que tener al menos una idea vaga de cómo resolver el problema mediante código con tus propios medios.

En general, este tipo de problemas requieren, por parte de la solución informática, una parte considerable de “computación” o “procesamiento” o “generación”. Si la idea y la descripción del problema sólo incluye palabras como “almacenamiento” y “búsqueda”, mientras que puede ser una aplicación completa perfectamente válida (dotada de un interfaz de usuario adecuado), los diferentes pasos por los que pasará la resolución del problema en los siguientes niveles no van a dar mucho de sí. Es decir, si se trata simplemente de objetos con un ciclo CRUD (create, read, update y delete), descartadla y pensad en otra que sí realice algún tipo de procesamiento.

En principio, el juego de rol debería ya haber eliminado este tipo de no-soluciones.

De la misma forma, aplicaciones que tengan una dependencia externa fuerte (por ejemplo, que recojan datos de un API o dispositivo externo, que pidan una gran cantidad de datos al usuario o que simplemente integren una biblioteca externa para llevar a cabo una operación sobre datos también externos) tampoco van a ser buenos proyectos, porque sus pruebas van a ser complicadas y no van a incluir ningún tipo de modelo. Lo esencial siempre es que la aplicación incluya un valor añadido en forma de lógica de negocio, y que se describa correctamente el problema a solucionar de forma que haga falta tal lógica de negocio para solucionarlo.

En este nivel no se pide que se especifique la solución al problema. Sin embargo, sí habrá que hacerlo más adelante y si se trata de un problema cuyas posibles soluciones no sean válidas para esta materia, se rechazará en este nivel. Por eso hay que pensar en la solución al problema, y en caso de que no quede claro su entidad por la sola descripción del mismo, especificarlo. Y esta descripción (que tiene que pasar por la lógica de negocio), sea explícitamente porque sea necesaria en este nivel, o en niveles siguientes, debe:

Incluir palabras como calcular, generar, procesar, predecir, visualizar (teniendo en cuenta en esta última que se va a hacer en el servidor), extraer, resumir, filtrar, validar, analizar.
No incluir palabras como “buscar”, “dar de alta”, “poner en contacto”, “recuperar”, “integrar”, “alertar”, “comunicar”.

La lógica de negocio será creada y testeada más adelante, a partir del nivel 5. Por eso es esencial que sea no trivial, para que los tests efectivamente comprueben que se está resolviendo el problema correctamente. Así mismo, los tests deben servir para validar que se ha resuelto el problema a través del programa, por lo que el problema debe ser formulado de forma que efectivamente, el procesamiento de la información que lleva a cabo el programa se pueda validar como una solución aceptable al problema.

Dónde buscar proyectos

En clase se hará un juego de rol para enfocar el problema, o poder hallar uno en caso de que se necesite ayuda.

En general, encontrar un proyecto que se pueda desarrollar en la materia es una cuestión personal, sobre todo porque es necesario que se trate de un proyecto donde uno tiene algún interés y conocimiento, y pueda identificar claramente cuales son los retos y qué es lo que funciona y aporta valor al cliente (que puede ser uno mismo). La metodología denominada design thinking te da una serie de pasos para poder entender posibles contextos en los cuales existe un problema, definirlo y proponer posibles soluciones.

En la primera sesión de clase se hará un juego de rol para poder abordar bien la fase de empatía de este proceso. Por tanto, se aconseja muy vivamente que se asista a esta primera clase y se participe en la actividad.

Incluso con interés, un problema adicional es encontrar proyectos en los cuales existan ya datos. No se va a ser suficientemente empático (como pide la metodología de design thinking) en un proyecto que requiera del usuario introducir gran cantidad de datos para obtener un resultado puntual. Por eso, y también porque las fuentes de datos públicos suelen coincidir con problemas y preocupaciones de la ciudadanía, pueden ser interesantes como base para un proyecto en esta materia. Por ejemplo, pueden ser interesantes estos portales:

Estos se pueden usar tanto para completar datos de una aplicación, como para crear un backend de la aplicación, siempre que se le añada valor suficiente en forma de una lógica de negocio.

Las aplicaciones no tienen por qué limitarse a programas cliente-servidor; pueden ser un app, o un juego. La única limitación es que efectivamente solucione el problema del cliente.

Cuál es el destino final del proyecto

Cuando se alcance el nivel final, el proyecto será desplegado en la nube, tras la descripción de la infraestructura virtual que necesitará para ello. El problema que se plantee será tal que pueda ser resuelto de esa forma. No se requerirá que se resuelva el problema totalmente, pero la mejor solución tiene que estar en una infraestructura virtual en la nube.

Preguntas frecuentemente preguntadas

Considera esto aclaraciones a las posibles revisiones que se puedan hacer a lo enviado. Dado que se puede enviar este nivel (y los demás) cuantas veces haga falta, en general este tipo de objeciones se harán por parte del profesor cuando lo entregues. Por supuesto, conviene tenerlas presentes antes de hacer el envío para cubrir este nivel.

¿Por qué hay que tener familiaridad con el problema?

La ingeniería resuelve un problema para alguien, en nuestro caso por medios informáticos. Durante el curso se va a desarrollar esa solución, y hay que validar que efectivamente resuelva el problema. Si no lo entiendes o no te es cercano, no vas a poder validar la solución, ni entender qué es una posible solución al problema.

¿Qué tipo de problemas son los más adecuados?

Problemas en los que tengas todos los datos necesarios y se sepa más o menos bien qué algoritmo se va a usar, o conjunto de procesamiento no trivial, para hallar la solución. También unos en los cuales una vez obtenido el resultado se pueda comprobar de forma más o menos independiente.

¿Qué tipo de problemas no van a ser adecuados?

Todos los problemas que requieran entradas físicas; todos aquellos en los que el usuario o cliente tenga que introducir mucha información. En general, todo problema que no se entienda bien.

¿Tiene que haber algún negocio para que pueda llamarse lógica de negocio?

No. En inglés se usa a veces business para indicar la parte importante de algo, o la que hace el trabajo. Evidentemente, en una eventual publicación de la aplicación habría que basar un negocio en ella, porque es la que aporta valor al cliente; también con ello se destaca que el código que compone la lógica de negocio es el que aporta valor al cliente; pensando en cómo se puede aportar ese valor puede, a la vez, descubrir diferentes tipos de clientes que puedan estar interesados en la aplicación.

A la vez, se distingue entre clientes (son los que se benefician de alguna forma con la aplicación) y simples usuarios (que pueden beneficiarse o no, pero aportan información que pueda usarse para la lógica de negocio y por lo tanto el cliente).

¿Por es necesario que la lógica de negocio ser no trivial?

Porque el estudiante tiene que programar esa lógica de negocio en los tests de los niveles a partir del cuatro. Si es trivial, ni siquiera requiere tests; si es de almacena y busca, ni siquiera es lógica de negocio.

¿Puede alguna lógica de negocio compleja ser inadecuada?

Si requiere un modelo complejo del problema, o un algoritmo complejo para trabajar con ella, puede ser un problema, porque, insisto, lo tiene que programar el estudiante. Si requiere predicción y por tanto un algoritmo de machine learning, doble problema, porque requiere conjunto de entrenamiento y programar el algoritmo. Se pueden usar, sin embargo, modelos ya entrenados siempre que se programe el intérprete de ese modelo.

¿Qué problemas serán adecuados para la nube?

Cualquiera que requiera muchos usuarios situados en muchos lugares diferentes, tendrán que desplegarse en la nube, siempre que los datos que necesite cada usuario estén en el servidor o bien proporcionados por el resto de usuarios. También los que usen datos agregados para generar información para otro cliente.

¿Cuáles serán inadecuados para una infraestructura virtual?

Las que estén dirigidas a un solo cliente, que tenga todos los datos necesarios para aplicar la lógica de negocio.

Prerrequisitos

Estar de alta en el grupo de Telegram.
En general, va a ser necesario que entiendas el mecanismo de la materia y sus contenidos. Por ello, consulta los contenidos impartidos en la primera sesión si no has podido asistir a clase.

Explicación

Primero, hay que comprobar que se ha configurado correctamente el entorno de desarrollo para este y otros proyectos, lo que incluye una configuración correcta del nombre y correo electrónico para que aparezca en los commits.

Usar un repositorio de forma correcta no solo permite organizar el trabajo de desarrollo de forma más eficiente, sino que también contribuye a que sea más fácil colaborar con él y a la creación de buenos hábitos de trabajo colaborativo. Hay una serie de buenas prácticas, que incluyen, pero no se limitan, a

Usar o bien el sistema de control de versiones que se incluya en el entorno de desarrollo, y con esto quiero decir, por ejemplo, que si se suele usar Emacs, VSCode, o algún editor específico para el lenguaje de programación que se vaya a usar, suelen tener un sistema de control de versiones integrado, o bien la línea de órdenes, lo que se recomienda, pero solo para las órdenes propias de git (es decir, excluyendo órdenes de GitHub como crear repositorios, que son propias de la web y del cliente de línea de órdenes de GitHub).
Entender bien el concepto de commit; por esa razón, hacer commits que abarquen una sola funcionalidad o tarea, pero solo si la funcionalidad es correcta (no tiene errores sintácticos, por ejemplo). Hacer commits a menudo.
De la misma forma, recordar que commit y push no son inseparables. Se hace push cuando se quiere sincronizar, y cuando se quieren pasar los tests. En caso de recursos de test limitados (créditos limitados, por ejemplo), cuantos menos push se hagan, mejor. Por eso, hacerlos sólo cuando se haya terminado una sesión de trabajo o se quiera sincronizar con el resto del equipo.
Usar desde el principio un fichero .gitignore para evitar añadir accidentalmente ficheros que no deban estar en el repositorio, como ficheros de respaldo o ficheros generados en compilación o construcción.
Siempre comprobar, antes de hacer un pull request, que se está trabajando sobre la última copia del fichero compartido (el de la entrega) para evitar conflictos que imposibiliten que se lleve a cabo la fusión por parte de la persona encargada del mismo. Para ello, hacer git pull --rebase inmediatamente antes de hacer push a una rama desde la que se vaya a hacer PR.

Material adicional

El proceso de design thinking para decidir sobre qué problema trabajar está descrito también en esta presentación o este tema.

El concepto de lógica de negocio se explica en este vídeo.

Entrega del material correspondiente a este nivel

Cada proyecto tendrá su propio repositorio en GitHub. La documentación se incluirá en ficheros con el formato Markdown (en su sabor GitHub, en caso de que se desee). Esta descripción de la aplicación irá evolucionando con los diferentes niveles.

En este nivel, los ficheros solicitados se crearán, en general, simplemente respondiendo a las preguntas de creación del repositorio. Sin embargo, adicionalmente hay que incluir en el fichero README.md una descripción de un problema que se vaya a intentar solucionar a lo largo de la materia, en las entregas del proyecto que se van a hacer, un proyecto que se desplegará en la nube. A partir de ahora, en todos los niveles se seguirá el siguiente procedimiento.

Para auxiliar al estudiante en estas labores se ha creado un plugin de git específico para la materia. Seguir las instrucciones en el mismo plugin para descargarlo e instalarlo.

En este caso, tras crear el repositorio, se creará una rama específica para este nivel (a partir de ahora, cada nivel tendrá su propia rama). Con el plugin de git instalado, esto se hará en este caso con git is nivel 0, que creará la rama y se trabajará en la misma.
En esta rama se modificarán los ficheros necesarios para llevar a cabo todo lo requerido, que no se haya hecho en la creación del repo.
Desde esa rama, se creará un pull request al propio repositorio indicando los cambios realizados. Este PR tendrá que ser aprobado por el profesor para que se considere el nivel alcanzado. También se puede hacer con el plugin (en parte), escribiendo git is sube-nivel. El mismo git imprimirá instrucciones que se podrán seguir (pinchando en un enlace) para crear el pull request (de una rama en tu repositorio a la rama principal).
Una vez creada esta rama, se debe copiar el URL de la misma, que será lo que se entregará.

Una vez hecho lo anterior, se añadirá al fichero de entrega del proyecto, en la fila correspondiente (que estará ya pre-rellena con el nombre el equipo), el nombre del proyecto, un enlace al PR que has creado desde una rama de tu repositorio y una versión, que seguirá el formato estándar vx.y.z, llamado versionado semántico. Para enviar este PR crearás también una rama específica del repositorio de la materia, y harás un nuevo PR desde la misma.

Por si queda poco claro, son dos PRs en dos repositorios diferentes. Uno en el repositorio de tu equipo, desde una rama creada específicamente para cada nivel a la principal, otro en el de la materia, desde una rama también específica del nivel a la principal.

El sistema de tests asegura la contención de cualquier tipo de cambio por parte del estudiante en el que se haga algo que pueda afectar al repositorio de la materia. Por lo tanto se aconseja al estudiante que pruebe y experimente con los envíos, siguiendo únicamente las condiciones que se indican en la propia plantilla de envíos:

No se deben abrir dos pull requests a la vez, porque es imposible saber cuál es el correcto (y también se recibirán excesivas notificaciones).
No se debe cerrar nunca un PR (porque git y GitHub tienen mecanismos para reparar un PR simplemente cambiando el contenido del repositorio y rama desde el que se solicita un PR por uno correcto).
Sólo debéis fusionar el PR en vuestro repositorio cuando haya sido aceptado por el profesor.

Se aconseja al estudiante que trate de solucionar los problemas que aparezcan, bien en los tests o a través de los comentarios del profesor, de la forma más rápida posible.

En el caso de la entrega en el repositorio de la materia, los tests no tardarán más de un minuto. Si falla, se aconseja que se corrija sobre la marcha y se vuelva a enviar.
Cuando haya correcciones por parte del profesor, que también se tratarán de hacer lo más rápidamente posible, se aconseja que se lean atentamente, se investigue las cuestiones que plantea, y se vuelva a enviar. Las objeciones y revisiones sólo desaparecerán cuando se altere la línea sobre la que se han hecho. Se aconseja no resolver nunca estas objeciones, salvo que hayan dado lugar a cambio en otra línea y por tanto no se haya cerrado. La resolución rápida de problemas para adquirir un objetivo de aprendizaje es imprescindible para progresar rápidamente en la materia.
Una vez hecha la revisión por el profesor la primera vez, se le notificarán todos los cambios en el PR; se pide, sin embargo, que cuando la revisión esté completa se solicite de nuevo revisión explícitamente en un comentario en el que se mencione al profesor o asignando como revisor al profesor en GitHub.

El README.md del proyecto será, efectivamente, la descripción del proyecto en sí.

Cuando el profesor apruebe el PR en el repositorio del equipo, se podrá fusionar ese contenido con su rama principal; en ese momento se estimará que se ha alcanzado el objetivo requerido. El profesor revisará, uno por uno, todos los envíos y hará preguntas (que habrá que aclarar generalmente investigando algún aspecto que no quede claro y cambiando el código) o sugerencias, que encaminarán al estudiante a entender mejor los objetivos correspondientes, y eventualmente a superar el nivel.

Por esto, se puede entregar el nivel todas las veces que necesites (solicitando de nuevo revisión por parte del profesor, preferiblemente a través del mecanismo que tiene GitHub para ello), mejorándolo siguiendo los consejos del profesor. No trates de poner lo que pide en la primera ocasión, ni en la segunda. Trata de entender qué es lo que tienes que aprender en cada nivel, y transmítelo en lo que entregues. Lo importante siempre es lo que aprendas, no lo que pongas o escribas. Esto se aplica a este nivel, y por supuesto al resto de la materia.

Por eso, no tienes que esperar a tenerlo perfecto para entregarlo; basta con que pase los requisitos mínimos, que se comprueban como tests. No se espera que esté perfecto con la entrega, se espera que con a ayuda del profesor y, a partir del nivel siguiente, de los compañeros, se alcancen los objetivos de aprendizaje.

Importante: el título de este pull request tiene que incluir la cadena [IS-23-24] para que pueda filtrar fácilmente los mensajes recibidos. Cuando se hagan en el PR las mejoras como respuesta a la revisión del profesor, el estudiante deberá pedir explícitamente revisiones adicionales con un comentario en el mismo que diga “Listo para revisión”.

Lista de comprobación

Hazte estas preguntas cuando envíes el nivel; tendrá que ser positiva la respuesta a todas, si quieres tener posibilidades de superación del nivel, pero que las marques como conseguidas no garantiza ni tiene relación alguna con la consecución del mismo. Así que marcad solamente las que efectivamente hayas superado.

* [ ] ¿Se trata de un problema real del que se tenga conocimiento personal?
* [ ] ¿Se trata de un problema que para solucionar requiera el despliegue
   de una aplicación en la nube?
* [ ] ¿La solución requiere una cierta cantidad de lógica de negocio, en vez
    solucionarse sólo almacenando y buscando?
* [ ] ¿Se ha incluído la configuración del repositorio y se ha enlazado desde el
`README`?
* [ ] ¿Tienes todos los datos necesarios para poder resolver el problema, o vas
a requerir que el usuario los introduzca?
* [ ] ¿Has seguido la lista de comprobación o estás marcando al buen tuntún
todo?

Puedes pegar este texto al PR que hagas en tu propio repositorio, e ir marcando según vayas comprobando que la respuesta es afirmativa. Ayudará si pones alguna explicación de por qué lo es El objetivo de esta lista de comprobación es que te ayude a prepararte para entregar el contenido del nivel, no que pongas y marques absolutamente todo. Hacerlo así no contribuye en absoluto a la superación del nivel, y sí aumenta la carga de trabajo de quien lo revisa, que tendrá que comprobar que efectivamente lo has hecho o indicarte en la revisión cuando has marcado algo que no has cumplido de ninguna de las maneras.

A donde ir desde aquí

Una vez entregado, podéis empezar con el siguiente nivel aunque evidentemente el desarrollo del mismo dependerá de que se acepte correctamente este; si necesitas que el profesor te indique las claves, pedidlo y se os explicará a vuestro equipo de forma personalizada. Puedes tener todos los PRs que desees abiertos en tu repositorio. Se puede consultar también el material sobre los PRs en caso de que no se haya entendido o llevado a cabo esa tarea dentro del equipo.

Se aconseja en todo caso que se inicie el trabajo en ese nivel inmediatamente en cuanto que se supere este; fuera de clase, se puede preguntar en el grupo de Telegram de la materia.