flowchart LR
lst(*lst) -.-> l1
subgraph Single Linked List
l1(first) --> l2(n) --> l3(last)
end
dll(*dll) -.-> d1
subgraph Doubly Linked List
d1(first)
d2(n)
d3(last)
d1 --> d2 --> d3
d3 --> d2 --> d1
end
que(*que) -.-> q1
subgraph Queue
q1(first) --> q2(...) --> q3(last)
end
stk(*stk) -.-> s1
subgraph Stack
s1(first) --> s2(...)
end
Porque las listas no son suficientes.
Las estructuras de datos son una parte fundamental de cualquier lenguaje de programación, y en este proyecto vas a aprender a implementar y a usar las siguientes:
Estructura de datos | Tipo | Descripción |
---|---|---|
Lista Doblemente Enlazada (Doubly Linked List) |
Lineal | Cada elemento apunta al anterior y al siguiente. Puede accederse a cualquier elemento. |
Cola (Queue) |
FIFO (First In, First Out) |
Cada elemento apunta al siguiente. Puede accederse solo al primer y último elemento. |
Pila (Stack) |
LIFO (Last In, First Out) |
Cada elemento apunta al siguiente. Puede accederse solo al primer elemento. |
Conjunto (Set) |
No lineal | Cada elemento apunta al siguiente. No admite elementos repetidos. |
[!TIP] Además, si todo sale bien, ¡luego podrás incluirlas en tu Libft!
Este proyecto seguirá la misma dinámica que cualquier otro proyecto del cursus: reglas del Makefile, Norma, etc; no obstante, para este proyecto en particular se añadirá algo nuevo, un buen uso de Git y GitHub:
[!NOTE] Será necesario repartir las tareas del proyecto entre los miembros del equipo para poder terminarlo a tiempo.
Un uso correcto de Git y GitHub durante el desarrollo del proyecto.
Este taller no trata sobre lenguaje C; así que lo importante no será el resultado final, sino el proceso.
Se espera un repositorio que contenga:
Aprendizaje sobre estructuras de datos.
Saber implementar y manejar estructuras de datos, una habilidad muy útil para todo programador.
Este proyecto está estructurado de una forma distinta a la que podrías estar acostumbrado: lee detenidamente este apartado antes de empezar a trabajar.
Todo el código necesario ya está programado en recursos, por lo que para realizar las tareas solo tendrás que colocarlo adecuadamente.
Este proyecto se divide en 2 partes bien diferenciadas:
Primero, formarás un equipo con otros estudiantes y gestionaréis un proyecto en GitHub usando las herramientas Issues, Milestones y Projects que ofrece la plataforma, con las que os repartiréis las distintas tareas de este proyecto.
El objetivo es que descubras cómo se puede usar GitHub para gestionar un proyecto y que aprendas a trabajar en equipo, ya que más adelante (ya sea en 42 o en tu futuro laboral) será necesario que sepas cómo desenvolverte en un entorno de trabajo colaborativo.
Segundo, implementarás la librería datalib usando las funciones que se encuentran en el fichero recursos para completar las funciones vacías de los ficheros de código C del proyecto. También cuentas con un Makefile que te ayudará a compilar y probar tu código.
El objetivo es que tu equipo y tú simuléis un entorno de trabajo real, donde trabajéis en paralelo y tengáis que combinar cambios de forma que no produzcan conflictos, comprobando cómo evoluciona el código gracias al proyecto anteriormente creado.
Cread un equipo de 3 personas: vuestro líder será el estudiante sentado en el centro de la fila, y el resto de miembros serán los que estén a su izquierda y a su derecha; dáos la mano, un par de besos, o lo que proceda.
El líder prepará el repositorio de GitHub del equipo, por lo que deberá:
Aún no vamos a empezar a programar, así que, ¡manitas quietas! Nada de clonar el repositorio.
No hay prisa, pensemos las cosas antes de empezar a trabajar.
El siguiente diagrama representa un ejemplo del uso de Projects, Issues y Milestones, todo vinculado:
flowchart TB
subgraph Proyectos
P1(Project I)
P2(Project II)
P3(ProjectIII)
end
subgraph Repositorio A
direction TB
subgraph Tareas A
direction LR
I1(Issue 1)
I2(Issue 2)
I3(Issue 3)
I4(Issue 4)
I5(Issue 5)
I6(Issue 6)
end
subgraph Hitos A
direction LR
M1(Milestone 1)
M2(Milestone 2)
end
I1 & I2 --- M1
I3 & I4 & I5 --- M2
end
subgraph Repositorio B
direction TB
subgraph Tareas B
direction LR
I7(Issue 7)
I8(Issue 8)
end
end
P1 -.- I1 & I2 & I3
P2 -.- I4 & I5 & I6
P3 -.- I6 & I7 & I8
Observa que los Projects son independientes a los Repositorios, al contrario de lo que pasa con los Issues y los Milestones; esto permite que un Project pueda contener recursos de distintos repositorios, pero un repositorio solo puede contener Issues y Milestones propios.
El dueño del repositorio -es decir, el líder- deberá:
Una vez hecho eso, observad los archivos que tenéis: creo que es evidente que para que el código compile y se ejecute, tendréis que completar las funciones que actualmente se encuentran vacías (todas, excepto los *_print.c); y por otra parte, también podéis observar que para cada estructura de datos hay varios archivos, por lo que quizás sea buena idea organizar el proyecto de la siguiente forma:
Dicho esto, y usando el Project que habéis creado:
[!WARNING] Aseguráos de cumplir correctamente con el punto 3.
Si no completáis estos datos, nada de lo que estáis haciendo tendrá sentido.
Aquí un ejemplo de Issue.
push
+ pull
Antes de que os pongáis manos a la obra, vais a hacer vosotros mismos un pequeño ejemplo sobre cómo váis a publicar y descargar cambios entre varios miembros del equipo: una versión reducida, simple y básica, luego usaremos los gloriosos Pull Requests.
El repositorio ya está listo:
El líder y solo el líder, hará un pequeño-gran cambio:
develop
.develop
remota, usando git push
.Ahora, el resto de miembros deberían tener ese cambio disponible para actualizar sus repositorios.
Una vez el líder haya subido los cambios, el resto de miembros deberán:
git fetch
.develop
usando git pull
. No sigáis hasta que no lo hayáis hecho.[!NOTE] Asumid que el resto de ejercicios se realizarán sobre dicha carpeta, correspondiente al proyecto de vuestro equipo.
Muy posiblemente hayáis estado copiando-y-pegando vuestra librería Libft en vuestros proyectos, o peor aún, solo sus funciones; ahora ha llegado el momento de convertirnos en seres eficientes y usar un submódulo.
He añadido mi Libft como submódulo; observad que dicha carpeta debería estar vacía, y eso es correcto, ya que un submódulo no contiene archivos, sino una referencia para clonar un repositorio; tendréis que inicializar el submódulo para poder usarlo.
Ya está todo listo para empezar el proyecto, y también para terminarlo, porque ya solo queda una última cosa por hacer: programar las funciones.
Cada miembro creará una rama para trabajar en su estructura de datos.
La rama debe tener un nombre significativo, por ejemplo: doubly-list
, stack
... y por supuesto, debe partir del último commit de develop
.
Usando el fichero recursos.txt, completad todas las funciones según vuestro reparto.
develop
.Lo que hacéis con ese último paso es informar a vuestros compañeros de que habéis terminado la funcionalidad en la que trabajábais, de modo que puede ser revisada y aceptada por un superior (en este caso, vosotros mismos).
Completando todos los Milestones, habréis terminado el proyecto. ¡Enhorabuena!
Ahora, la parte interesante, uando hayáis terminado el proyecto:
develop
con mi develop
, (repositorio original).Habéis estado trabajando todo el tiempo entre vosotros y en vuestro repositorio; pero con esto, estaréis trabajando con el repositorio de otro usuario y solicitando integrar vuestros cambios en un repositorio donde no tenéis permisos.
Si el cambio es aceptado (por mí), en el repositorio original apareceréis como contribuyentes y además, ¡habréis terminado el taller!
Efectivamente, estaban en el fichero de cabeceras desde el principio, ¡vaya plot-twist!
He estado hablando con HAL y me ha dicho que no hay forma de evaluar el proyecto, así que no hay evaluación.
Sí obstante, si queréis vacilar sobre quién tiene la rama más larga, siempre podréis pedírselo a otros de vuestros compañeros, ¡nadie os lo va a impedir!