# Ingenieria de Software II

# Metodologias Agiles [03-09-2019]

### MVP: Minimal Value Product

### Agile Principles

* Protootyping and Brainstorming
* Requirement validation using prototyping
* Pruebas E2E
* Ingenieros QA -> Se encargan principalmente de testear el prototipo.

* Constant Integration and testing
* Prueba de Unidad -> Solamente una funcion
* Prueba de Integracion -> Toda la aplicación en conjunto, se incluyen el * entorno (lenguaje o framework), bases de datos y APIS..
* Prueba E2E

* Repeat Customer Testing
* Small Teams
* Short iterations
### Roles
* UI: Diseñ Integracion
* UX: Diseñador Experiencia

### Herramienta de Software
* Atlassian
* Conflence
* Jira
* Bitbucket

### Implementation of Methodologie
**Iteration 0:** Se lleva a cabo del planteamiento del proyecto.

### Documentation Agile
_Agiliza el proceso de desarrollo, pero no omite la documentacion_

### Agile development
Is more a set guidelines tehan an actual development model.

### Agile Manifest
* Individuos e iteraciones > Procesos y herramientas
* Software Funcional > Documentacion enetndible
* Colaboracion del cliente > Negociacion del contrato
* Responder al cambio > Seguir un Plan

### Principles

1. Satisfacer al cliente con Software continuo.
2. Cambio de requerimientos
3. Envio de trabajo con frecuencia
4. El trabajo con el software es la principal medida de progreso
5. Los procesos habiles promueven desarrollo sostenible-
6. atencion continua a la exelencia tecnica
7. Trabajo colaborativo
8. Motivaciones personales
9. conversaciones cara a cara
10. Simplicidad
11. auto-orgaizacion de equipos
12. como ser lo mas eficiente posible

### XP (EXTREME PROGRAMING)

* Sobre carga del laboral.
* Eficiente, liviana, flexible.
* Util para proyectos personales.
* Valores
* comunicacion
* simplicidad
* feedback
* respeto
* Roles
* Custumer
* Tracker
* Programmer
* Coach
* Tester
* Administrator

#### Good Practices
1. Planear el "Juego"
2. Pequeños Avances
3. Uso metaforas
4. Propiedad colectiva del codigo (el producto es de todo el team)
5. Uso de estandares de codigo
6. Diseño Simple
7. Reuniones de Pie
8. Refactoring
9. Testing (Mitigacion de Errores)
10. Continous Integration (Socializar Cambios)
11. Programacion por parejas

### SCRUM
* **Roles**
* Product Owner (Manejo del negocio)
* Scrum Master (Facilitador, puente entre el team y cliente)
* Developer Team
* **Activities**
* Sprint
* Sprint Planing
* Daily Scrum
* Sprit Execution
* Spring Review
* Sprint Retospective

* **Artefacts**
* Product Backlog
* Lista pririzada de requirimentos definida por el Product Owner
* Mejoras tecnicas
* reparacion de defectos
* Responde a necesidades actuales del proyecto
* Generalmente se escriben como historias de usuario (Herramienta recomendada: Gerkin)
* Cambian mucho a lo largo del proyecto
* Estructura de Historias de Usuario
* Tipo de Usurio,
* Lo que quiero y
* El porque. (*para que*)
* Sprint Backlog
* Una lista de requerimientos implementandos a lo largo de una iteracion.
* Ventana de tiempo
* Es una sublista del Product Backlog
* el scrum master divide cada historia de usuario en tareas que luego son el equipo, los cuales le dan una score
* Herramienta Recomendada, ClickUp

* **Sprint**
* El tiempo recomendable es 2 semanas
* Una semana es poco recmendable
* Partes del Sprint
* Sprint planning
* El PO describe el requerimiento
* SC divide el requerimiento en Tareas
* El PO y ST estiman puntos basados en historias
* Daily Scrum
* Que trabaje
* En que estoy trabajando
* En que voy a trabajar
* Sprint execution
* Desarrollo del producto para cumplir objetivos
* El quipo de desarrollo deside el *orden* y *como* desarrollar
* Sprint review
* Cliente presente
* ST, PO, SM y Cliente
* Sprint retrospective
* Se revisa el producto

### Kanban
* Desarrollo y respuesta a requerimientos costantes.
* Tablero en el que nunca se para, no se tienen sprint, tablero con cosas por hacer, se termina una y continua con otra
* Muy util en equipos que responden solucitudes de operacion (Claro, telecomunicaiones).

#### Practices
* Areas del Tablero (Kanban Board):
* TO DO
* IN PROGRESS
* REVIEW (Revisar un PULL request)
* DONE

* En la practica el desarrollador realiza su pieza de codigo, y solicita un pull request a otro miembro del team.

# Sistema de Control de Versiones [05-09-2019]
* **GitFlow**:
* Metodologia para el manejo y nombramiento de ramas de un proyecto.
* Master, Develop, Feature y Release.
* **VCS**:
* Sistema que maneja los cambios en un proyecto.
* **Permite**:
* Revertir cambios (de archivos o todo el proyecto) a un estado previo.
* Revisar cambios sobre el tiempo.
* Quien realizo la ultima modificacion.
* **Existen 3 tipos de VCS**:
* Local: Copias del proyecto por cada cambio.
* Centralizado: Un unico servidor con todos los cambios fraccionados.
* Distribuidos: El proyecto esta distribuido en varios partes, los usuarios suelen trabajar por medios de apuntadores.
* **Funcionamiento Basico de Git**
* Exite un servidor que contiene una carpeta con la informacion del proyecto.
* Una version del proyecto es un conjunto de apuntaodres a al estado de los repositorios.
* El usuario obtine una copia del repositorio que contiene tiene 2 partes, el STG y el local, su trabajo se lleva a cabo en el entorno local y cuando esta seguro de esto, envia su avance a STG (commit), el cual sera enviado posteriormente al repositorio (push).

# Git Flow [17-09-2019]
Existen las siguientes rama:
* **master**: rama oficial o principal aca solo van las versiones que estan en produccion, en realidad no se suele manipular la rama master esta cumple un papel de backup.
* **develop**: productos que de estan desarrollando (el codigo debe funcionar), esta rama provee de master para trabar sobre esta.
* **release**: usado para poder manejar cambios en produccion sin afectar master, luego de completar un producto en develop se mezcla con release, para ser enviado a produccion, cuando funciona bien se mecla con master, en caso de aparecer un bug, se crea una rama bugfix para arreglarlo, si manipular a master.
* **feature/ID**: donde se implementan los cambios, se debe tener un commit solamente antes de lanzar un pull request a develop. El mensaje del commit debe ser claro y consiso, usar git emoji.
* **bugfix/ID**: lugar donde se deben arreglar los bug's y errores, suelen salir de la rama release.

### **Consideraciones**

* **Delivery Manager:** Encargado de controlar todos cambios, avances y demas del proyecto, juega un papel importante a la hora de realiazar la integracion de los prodcutos.
* **Long-Lived Branches Can Be Unproductive:** Los features deben integrar lo mas rapido posible a develop (alrrededor de un dia es el tiempo ideal), de igual manera el develop debe integrarse continuamente a master, esto facilita el trabajo de Ingeniero QA (el encargo de realizar las pruebas)

* **Ambientes de desarrollo:** por lo general existen 3 ambientes de trabajo, el local para feature, el ambiente de develop, y el de release que es el mas importante ya que aqui se prueban de manera rigurosa los cmabion antes de ser llevados a produccion.

* **Hotfix:** Arreglo a un bug que se hace de manera momentanea, en general se puede entender como un bug que se arregla en produccion.
* **Kahoot** Juan Diego gano!

### Usar en el proyecto simple.
* **Master:** solamente 4 commit's uno por cada iteracion
* **Develop:** Antes de cada iteracion se saca una rama develop de master para poder trabajar en ella a traves de la iteracion.
* **Feature:** lugar donde se realizan las implementaciones para luego ser llevadas a la rama develop.

# Frameworks [19-09-2019]

**Repaso de POO**
* **Clase:** Se pueden considerar como plantillas que representan ciertas caracteriscas y comportamiento, de un ente que se desee modelar.
* **Objeto:** Intancias de la clases (materializacion de las clases).
* **Herencia:** Un clase puede "copiar" caracteristicas y comportamietno de otras clases. (El ejemplo clasico de los animales)
* **Polimorfismo:** Dotar de distintos comportamientos a un objeto dependiendo de las condiciones y propiedades.
* **Interfaces:** Permiten definir una serie de compartamientos.
* **Acoplamiento:** Medida de dependencia de un objeto en otro. (Ejemplo un caso de herencia).
* **Cohesion:** Concepto que indica que una clase haga unicamente lo que debe hacer que no se le deloguen otras tareas. (Ejemplo de baja cohesion: clase que imprime un string y tambien se encarga de evaluar si el formato del string es correcto).

* **Otros conceptos a tener en cuenta**:
* Tipos de Acceso
* Propiedades
* Metodos (metodos abiertos para extension, cerrados para modificacion).
* DTO: Data Transfer Object: Son objetos usados para persintencia de datos, en teoria estos objetos solo deberian poseer propiedades y en caso de edicion usar una clase que modifiqeu este objeto, pero en la practica se pueden implementar metodos que ayudan a mejorar el comportamiento.
* Clases Abstractas
* Implementacion y Herencia.
* Se pueden crear objetos de un tipo a partir de clases que heredaron o implementaron a el.
* Bajo acoplamiento, alta cohesion.

* MVC - Grails
* Model
* Clases -> Tablas Relacionales
* Vista
* .gsp -> Archivos que seran renderizados en HTML
* Controlador
* NombreController (Relacionado con una clase)

* Componentes de software que deben ser instalados, posee una estructura y un patron que facilita el desarrollo de aplicaciones de manera rapida y agil.

* Full Stack Framework: Framework que ofrece herramientas en todas y cada unas de las capas.

* El uso de frameworks facilita:
* Conexion a la base de datos, ORM.
* Manejor del modelo de dato.
* La implementacion de metodologias.
* La creacion de MVP.

# Frameworks Frontend [08-10-2019]

El mundo de los frameworks para froentend es bastante extenso, existe un avance cosntante facilitando el desarrollo de aplicaciones.

### **Historia**
Mocha: de los priemros frameworks fue desarrollado en 10 dias.

En los comienzos el desarrollo de era extremadamente complejo y tedioso, imcompatibilidad entre lenguajes.

Aparece CSS, para manejo de estilos, hizo que el desarrollo mucho mas complejo.

Para facilitar el desarrollo de fronted aparecen herramientas (Paquetes de codigo) como bootstrap, con una enorme cantidad de codigo. Despues de esto aparecieron una gran cantidad de paquetes enfocadas a propositos especificos.

Aparece JavaScript, con bastantes errores, pero con gran potencial.

Luego aparece JQuery (libreria de JavaScript) que prometia solucionar errores comunes de JavaScript.

Con el tiempo y el crecimiento de la comunidad se crearon una gran cantidad de librerias que resuelves una cantidad inimaginable de problemas, incluso existen varias herramientas que solucionan el mismo problema.

Con la gran cantidad de librerias y reutlizacion de codigo surge el concepto de Depencias.

### **Conceptos de JavaScript**

* Tipado
* Referencias
* Arrow Function

## Chat

# Notas
## Seguridad
* DevSecOps, antes de sacar una herramienta a produccion esta herramienta analiza de manera automatica fallas en el artefacto.

## Datos Curioso
* Octocat gato(Felis silvestris catus) de GitHub se puede diseñar de manera personalizada

## Explicaciones para Duumies:
* Los **microservicios** por lo general funcionan con ayuda del concepto de un TOKEN, un usuario usa su token para poder acceder a los diferentes microservicios que ofrece el software.

* **Contedor:** Proceso que permite automatizar el despliegue de una aplicacion. Funciona como una maquina virtual por encima del SO en donde puedo tener una unica version de java, SQL, etc.

* **Docker:** Un contenedor es una una instancia de una imagen, esta instancia contiene un configuracion del ambiente de produccion, esto permite que el desarrollador pueda trabajr en local simulando el ambiente de produccion, con el tiempo se crearon bastantes contenedores donde cada uno contenia un microservicios, en muchos algunos contenedores cumplen la funcion de respaldo.

* **Kubernetes**: Orquestador de contenedores, permite levantar una cantidad mucho mas grande de contenedores en estructuras llamadas "pod". Con esto podemos administrar contenedores a gran escala, por lo que se puede apagar o encender zonas completas.(Ejemplo de cartoon newtwok pornografico esto no es un ejemplo si hubieran tenido esta tegnologia hubieran solucionado este poroblema)

* **SDK:** Conjunto de codigo que ayuda a facilitar el desarrollo

* **Libreria:** Conjunto de codigo que ayuda a facilitar el desarrollo

* **API:** Componente que se maneja en una arquitectura de peticion y respuesta

* **Framework:** Tecnologia que permite construir apps de manera rapida, por lo general maneja un patron de diseño como MVC.

* **ORM(Object Relational Mapping)**: tecnologia que permite manejar una base de datos relacional en un mundo orientado a objetos

* **Compilador:** Java, genera instrucciones compredidas por la maquina, pero necesita pasar por un proceso de constreuccion.

* **Traspilar(Traducir):** TypeScript -> Java, transforma instruciones de un lenguaje a otro, y el nivel de abstracion es bastante similar, ambos lenguajes se leen de manera similar.

* **Interpretado:** Groovy -> Java. "Buscar Definicion ALV" .(puede tener su propia sintaxis y a su vez tener codigo Java).

* **Pruebas Acid:** Pruebas para CSS, al final salia una cara feliz si las pruebas salian exitosas