Objetivo 0: Entender correctamente la mecánica de la asignatura

Motivación

Esta asignatura tiene una serie de mecanismos específicos para su evaluación y entrega; estos mecanismos son los mismos que se usan en las empresas de desarrollo de software. Con este objetivo se pretende que el estudiante entienda correctamente estos mecanismos, así cómo el proceso de aprendizaje guiado que se va a llevar en esta asignatura.

A la vez, el estudiante tendrá que describir un problema general que se irá resolviendo, a través de la asignatura, usando software. Este problema general tendrá que incluir obligatoriamente un componente que se pueda desplegar en la nube. Este es el objetivo secundario: que el estudiante entienda el concepto de “problema” y de “solución basada en la nube”.

TL;DR

Pensar en una idea o problema a resolver que tenga entidad suficiente para poder llevar a cabo su desarrollo durante el resto del año.

Descripción

En este hito 0 del proyecto 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, que en general siguen el denominado manifiesto ágil.

Para ello, se creará un repositorio que se usará durante el resto de la asignatura para mostrar el avance el proyecto en diferentes hitos de despliegue de una aplicación. El repositorio contendrá inicialmente:

En cuanto a la idea o problema que se quiere resolver, tiene que ser un problema que tenga entidad suficiente para poder crear, eventualmente, algún tipo de servidor que se pueda desplegar en la nube. 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 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 objetivos no van a dar mucho de sí si se trata simplemente de objetos con un ciclo CRUD (create, read, update y delete).

De la misma forma, aplicaciones que tengan una dependencia externa fuerte (por ejemplo, que recojan datos de un API externo 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.

En generla, la descripción de la solución del problema debe:

Prerrequisitos

  1. Haber rellenado en la hoja de cálculo compartida la equivalencia entre nombre real y nick en GitHub, así como nick en Telegram.

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

Explicación

Primero, hay que configurar correctamente el entorno de desarrollo para este y otros proyectos, lo que incluye

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

Material adicional

Puedes consultar la presentación de git del curso de desarrollo ágil, el material o por supuesto consultar al profesor.

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

Entrega de la práctica

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 hitos.

En este objetivo, 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 asignatura, 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 objetivos se seguirá el siguiente procedimiento.

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

  1. En este caso, tras crear el repositorio, se creará una rama específica para este objetivo. Con el plugin de git para IV instalado, esto se hará en este caso con git iv objetivo 0, que creará la rama y se trabajará en la misma.
  2. 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.
  3. 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 objetivo alcanzado. También se puede hacer con el plugin (en parte), escribiendo git iv sube-objetivo. 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).
  4. 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 tu nombre), el nombre del proyecto, un enlace a la rama desde la que te estás haciendo un PR a ti mismo y una versión. Para hacer este PR crearás también una rama específica del repositorio de la asignatura, y harás el PR desde la misma.

Por si queda poco claro, son dos PRs en dos repositorios diferentes. Uno en tu repositorio, desde una rama del objetivo a la principal, otro en el de la asignatura, desde una rama también específica del objetivo 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 asignatura. 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:

El README.md del proyecto será, efectivamente, la descripción del proyecto en sí. Documentación adicional (por ejemplo, en la documentación de este objetivo mostrar que se han llevado a cabo las configuraciones que se han solicitado) se deben poner en un directorio aparte y enlazarse desde el README.md en un apartado específico (al final del mismo, por ejemplo). Por ejemplo, pantallazos u otro tipo de documentación que pruebe que se ha configurado correctamente git.

En general, el README.md sólo incluirá temas relativos al proyecto en sí. Lo necesario para valorar si se ha alcanzado el objetivo o no deberán ir en documentos aparte, para que se puedan corregir.

Cuando el profesor apruebe el PR en el repositorio del estudiante, se podrá fusionar ese contenido con su rama principal; en ese momento se estimará que se ha alcanzado el objetivo requerido.

Valoración

Se estima en una semana el tiempo necesario para llevar a cabo esta entrega. El alcanzar este objetivo avanzará, aproximadamente, 7.5% de la asignatura.

Donde ir desde aquí

Si has terminado, comienza con el siguiente.