DAW UT6 - PAUCASESNOVES

En una aplicación conviene documentar: La interfaz. La implementación. La toma de decisiones. Las tres opciones son correctas.

Existen herramientas que permiten generar documentación a partir del código fuente. Verdadero. Falso.

Javadoc es la herramienta estándar de PHP para generar documentación de manera automática, mientras que phpDocumentor es la de Java. Verdadero. Falso.

phpDocumentor permite generar la documentación desde: Línea de comandos (php CLI). Desde interfaz web. Desde el código a través de scripts propios. Las tres opciones son correctas.

Es necesario especificar el directorio de nuestro código, para que phpDocumentor pueda recorrer los subdirectorios de forma automática para generar la documentación, y un directorio de salida, que señale dónde se ha de generar. Verdadero. Falso.

Los formatos de salida de phpDocumentor son: HTML, con la posibilidad de elegir entre plantillas predefinidas. PDF. XML. Las tres opciones son correctas.

Doxygen es una alternativa a phpDocumentor, y prácticamente viene a ser lo mismo, ya que funciona de igual manera. No, Doxygen genera documentación en Java. No, Doxygen es un IDE para generar el código. Sí, además Doxygen puede generar documentación en otros lenguajes de programación. No, es cierto que es una alternativa, pero Doxygen es un programa, mientras que phpDocumentor es una colección de código PHP.

En phpDocumentor, la documentación se distribuye en bloques 'DocBlock'. Verdadero. Falso.

phpDocumentor permite marcas dentro de su DocBlock que serán interpretadas con un significado especial a la hora de generar la documentación. Algunas son: @access. @author. @deprecated. @link. Todas las opciones son correctas.

Existen tres marcas que solamente se pueden utilizar en bloques de determinados elementos: @global para especificar variables globales. @param para especificar parámetros. @return para especificar un valor retornado. Todas las opciones son correctas.

phpDocumentor se puede instalar a través de consola con el siguiente comando: sudo apt install php-pear. sudo install phpDocumentor. sudo apt install php-doc. sudo install php-doc.

Indica las afirmaciones verdaderas: phpDocumentor es una colección de código en PHP. Para que funcione phpDocumentor es necesario tener instalado PHP. phpDocumentor únicamente va a funcionar en los servidores web. Apache no es necesario para trabajar con phpDocumentor.

Javadoc es una utilidad de Sun Microsystems para generar APIs (Aplication programing Interface) en formato HTML de un archivo de código fuente Java. Verdadero. Falso.

Javadoc es un programa, que recoge los comentarios que se colocan en el código con marcas especiales y construye un archivo HTML con clases, métodos y la documentación que corresponde. Verdadero. Falso.

En Javadoc hay etiquetas: Etiquetas de bloque. Etiquetas inline. Etiquetas externas. Etiquetas dinámicas.

En Javadoc, las etiquetas se ubican dentro de los comentarios, comienzan con el símbolo @ y son sensibles a mayúsculas-minúsculas. Verdadero. Falso.

Algunas etiquetas de Javadoc son: @author (Indica el autor del código). @version (Para indicar la versión). @see (Para relacionar otra clase o método con el bloque comentado). Todas las opciones son correctas. @throws (Para métodos que pueden lanzar una excepción).

Un sistema de control de versiones permite: Revisar el código en un estado puntal en el tiempo. Tener ramas o líneas de desarrollo independientes que derivan de una rama o línea principal y se utilizan para trabajar en nuevas características o experimentos sin afectar al resto de código en producción. Trabajar con repositorios clonados, locales o en remoto, es decir, tener una copia del código fuente y realizar los cambios en ella, para más tarde sincronizarlos con el repositorio original. Desarrollar el código de un directorio, ya sea de manera local (en red) o remota, con la posibilidad de trabar en diferentes funcionalidades al mismo tiempo, siempre y cuando haya una comunicación clara entre los desarrolladores.

¿Qué es el control de versiones y cuál es su propósito en el desarrollo de software?. Registrar y controlar los cambios realizados en el código fuente a lo largo del tiempo. Realizar copias de seguridad de los archivos de código fuente. Permitir a múltiples desarrolladores trabajar simultáneamente en el mismo código. Gestionar el acceso a la red de una aplicación web.

¿Cuál es la diferencia entre un sistema de control de versiones centralizado y uno distribuido?. En un sistema centralizado, todos los archivos y la historia de cambios están almacenados en un único servidor, mientras que en un sistema distribuido, cada usuario tiene una copia completa del repositorio. En un sistema distribuido, solo se puede acceder al repositorio desde un servidor central, mientras que en un sistema centralizado, cada usuario tiene una copia completa del repositorio. En un sistema centralizado, cada usuario tiene una copia completa del repositorio, mientras que en un sistema distribuido, todos los archivos y la historia de cambios están almacenados en un único servidor. En un sistema distribuido, solo se puede acceder al repositorio desde un servidor central, mientras que en un sistema centralizado, todos los archivos y la historia de cambios están almacenados en un único servidor.

¿Qué es un repositorio en el contexto de un sistema de control de versiones?. Un almacenamiento centralizado de archivos y la historia de cambios asociada. Un servidor que almacena correos electrónicos y permite su acceso remoto. Una base de datos relacional utilizada para almacenar datos de la aplicación. Un servidor web que hospeda múltiples sitios web en una misma máquina.

¿Qué es una revisión de código y cuál es su propósito en el desarrollo de software?. Un proceso de inspección de código realizado por otros miembros del equipo para identificar errores y mejorar la calidad del código. Una copia exacta de un conjunto de archivos en un momento específico del tiempo. Un informe detallado que describe los cambios realizados en el código fuente a lo largo del tiempo. Un sistema para rastrear y asignar problemas o tareas relacionadas con el desarrollo de software.

¿Qué es una rama (branch) en el contexto de un sistema de control de versiones y cuál es su función?. Una línea de desarrollo independiente que deriva de la línea principal y se utiliza para trabajar en nuevas características o experimentos sin afectar al código en producción. Una extensión de software que agrega funcionalidades específicas al servidor. Un servidor que aloja múltiples sitios web en una misma máquina. Una versión específica de un conjunto de archivos en un momento dado del tiempo.

¿Qué es una fusión (merge) en el contexto de un sistema de control de versiones y cuándo se utiliza?. Combina los cambios de una rama de desarrollo en otra rama, generalmente después de que se hayan completado y probado las nuevas características. Controla el acceso a la red de la aplicación y garantiza su seguridad. Configura las directivas del servidor, como los puertos de escucha y los hosts virtuales. Almacena las páginas HTML y CSS del sitio web.

¿Qué es un conflicto de fusión (merge conflict) en el contexto de un sistema de control de versiones y cómo se resuelve?. Ocurre cuando dos ramas de desarrollo contienen cambios incompatibles en la misma línea de código y se resuelve manualmente editando el archivo en conflicto. Controla el acceso a la red de la aplicación y garantiza su seguridad. Configura las directivas del servidor, como los puertos de escucha y los hosts virtuales. Almacena las páginas HTML y CSS del sitio web.

¿Qué es una etiqueta (tag) en el contexto de un sistema de control de versiones y cuándo se utiliza?. Una referencia estática a un punto específico en la historia de cambios de un repositorio, generalmente utilizado para marcar versiones de lanzamiento. Una referencia dinámica que cambia de contexto según la rama en la que se trabaje. Señala la fecha y hora exactas de la actualización de un archivo. Hace referencia a la fecha y hora exactas de la actualización de un archivo, al igual que al desarrollador que ha realizado el cambio.

Un 'pull request' es una solicitud para fusionar cambios de una rama de desarrollo en otra, generalmente acompañada de una revisión de código y pruebas de calidad. Verdadero. Falso.

Un changelog es un documento que enumera y describe los cambios realizados en el código fuente a lo largo del tiempo. Verdadero. Falso.

En términos de Git, ¿Qué es un fork?. Es la copia de una rama de un repositorio. Es la copia de un repositorio propio para poder enviarlo a otro desarrollador. Es la copia de un repositorio existente, que se crea como nuestro en un plataforma como GitHub, que permite desarrollar cambios libremente sin afectar al repositorio original. Es una copia de un repositorio existente, que se crea como nuestro en un plataforma como GitHub, que permite desarrollar cambios que se ven reflejados automáticamente en el repositorio original, sin la necesidad de tener que hacer gestiones manualmente.

Para traer un repositorio de nuestro GitHub en local, y sincronizarlo con el repositorio de GitHub es necesario... Autenticarnos cada vez que hagamos commit, en caso de operar con HTTPS. Crear una clave SSH, en caso de clonar y operar con SSH, evitando así tener que introducir credenciales cada vez que queremos conectar con GitHub. Utilizar un cliente GUI, como Github Desktop, TortoiseGit, GitKraken, etc.

Para poder sincronizar el repositorio local con GitHub utilizando el método SSH... Asegurarnos de tener un directorio '.ssh' en la partición que contiene la carpeta Usuarios en nuestro equipo. Ej: "C:\Users\'usuario'\.ssh. Tenemos que generar la clave SSH mediante comando en terminal 'ssh-keygen -t ed25519 -C tu@email'. Introducimos el nombre del archivo que se generará y será la clave, y la contraseña (opcional). Nos aseguramos de tener el agente SSH en ejecución mediante la consola, como PowerShell, p.ej. Agregamos la clave privada SSH al agente mediante comando por consola: ssh-add "C:\Users\'usuario'\.ssh\clave". Agregamos la clave pública a nuestro GitHub como 'Authentication Key'. "C:\Users\'usuario'\.ssh\clave.pub". Comprobamos que podemos conectarnos a GitHub mediante nuestra clave SSH a través del comando: ssh -T git@github.com.

Para clonar un repositorio en local, copiamos el enlace SSH del repositorio en GitHub, e introducimos en Git Bash: git clone 'enlaceSSH'. Sí, estando ubicados en el directorio donde queremos que se descargue el repositorio, y siempre que hayamos configurado antes una clave SSH para nuestro equipo (agente SSH) y GitHub. Sí. No.

Git permite su implementación en diferentes IDEs como NetBeans, VSCode, etc. Verdadero. Falso.

Para hacer un commit a través de Git Bash podemos utilizar el siguiente comando: git comit -msg 'Mensaje...'. git commit -messages 'Mensaje...' 'Mensaje...' 'Mensaje...'. git comit 'Mensaje...'. git commit -m 'Mensaje...'.

El comando 'git push' envía los cambios locales en tu repositorio a un repositorio remoto, actualizando el repositorio remoto con los commits realizados en tu copia local. Verdadero. Falso.

El comando 'git commit' guarda los cambios en el repositorio local creando un nuevo commit con un mensaje descriptivo. Este commit crea una instantánea del estado actual del proyecto. Verdadero. Falso.

Un 'pull request' es una solicitud que propone cambios en un repositorio, solicitando la revisión y la fusión (en caso de que la revisión sea satisfactoria) de los cambios en la rama principal del proyecto. Verdadero. Falso.

El comando 'git merge' combina los cambios de una rama en la rama actual, integrando los historiales de commits de ambas ramas. Verdadero. Falso.

Supongamos que tenemos rama1 y rama2. Para hacer un merge de rama2 en rama1 tenemos que: Estar en rama2 y utilizar el comando 'git merge rama1'. Estar en rama1 y utilizar el comando 'git merge rama2'. El comando 'git merge' no existe. Estar en rama2 y utilizar el comando 'git merge prev-branch'.

Con el comando 'git checkout' podemos cambiar de rama. Verdadero. Falso.

El comando 'git log' muestra el historial de commits del repositorio, incluyendo detalles como el identificador del commit, el autor, la fecha y el mensaje del commit. Verdadero. Falso.

Relaciona cada variante del comando 'git log' con sus características: git log --oneline. git log --graph. git log --stat. git log -p.

El comando 'git log' permite añadirle flags (opciones) para personalizar su salida. (ej: git log --oneline). Verdadero. Falso.