AlissonPabon1976fgch298910

Npm, Sbt, Maven: para la construcción de proyectos, dependiendo del lenguaje de

programación,
Npm para proyectos con NodeJS como microservicios o
Angular, Sbt para proyectos java Play Framework y Maven para proyectos Java de otra
índole.
Git o Clear Case: Sistemas de control de versiones, existen en el mercado varios
clientes de Git como GITLab o Bitbucket.
Jenkins o GoCD: Servidor de integración continua, equipo donde se ejecutan los
scripts de validación, compilado y distribución.
SonarQube: Herramienta para análisis de código, SonarQube es una herramienta que se
puede integrar con la mayoría de los lenguajes de programación existentes.
Artifactory: repositorio de artefactos, con características de almacenamiento de
imágenes Docker.
Docker: una vez que la distribución esta lista para el despliegue los scripts de
despliegue generan la imagen a ser instalada de acuerdo con el ambiente
correspondiente.
Private Docker Registry: Representa un repositorio local creando en Artifactory
donde se almacenan las imágenes, al cual puedan acceder todos los integrantes del
equipo de desarrollo.

--------------------------------

Code: Code Development and Review, continuous integration tools

Build: Version control tools, code merging, Build status
Test: Test and results determine performance
Package: Artifact repository, Application pre-deployment staging
Release: Change management, Release approvals, release automation
Configure: Infrastructure configuration and management, Infrastructure as Code
tools
Monitor: Applications performance monitoring, End user experience

Code, Build, Test, Package, Release, Configure, Monitor

DevOps
3rd IBM Limited Edition
by Sanjeev Sharma and Bernie Coyne

Código: Desarrollo y revisión de código, herramientas de integración continua.

Construir: herramientas de control de versiones, fusión de código, estado de
compilación.
Prueba: la prueba y los resultados determinan el rendimiento.
Paquete: repositorio de artefactos, etapa previa a la implementación de la
aplicación.
Lanzamiento: gestión de cambios, aprobaciones de versiones, automatización de
versiones.
Configurar: configuración y administración de la infraestructura, Infraestructura
como herramientas de código.
Monitor: monitoreo del rendimiento de las aplicaciones, experiencia del usuario
final.
------------------------------
Distribución inteligente de contenedores en los nodos.
Fácil escalado, tanto horizontal como vertical.
Administración de cargas de trabajo ya que nos provee de balanceadores de cargas.
Facilita la gestión de gran cantidad de servicios y aplicaciones.
Provee de alta disponibilidad.
Muy modular, mucha flexibilidad.

--------------------------------------------------------
https://www.redeszone.net/2017/12/31/diferencias-virtualbox-contenedor-docker/
La principal diferencia entre ambas tecnologías es que, por un lado, cuando
virtualizamos un sistema operativo
con VirtualBox instalamos y ejecutamos el 100% del sistema operativo, con su
kernel, su entorno, sus librerías, sus dependencias, etc.
Igual que instalamos Windows o Linux en un ordenador real se instala al completo en
VirtualBox.

Cuando utilizamos los contenedores de Docker, por ejemplo, la cosa cambia. En lugar
de virtualizar un sistema operativo completo,
solo creamos un pequeño kernel con las librerías y dependencias necesarias para
realizar nuestra tarea,
obviando todo lo demás. De esta manera, los contenedores no son un sistema
operativo virtual como tal,
sino más bien se entienden como “paquetes” que se ejecutan aislados sobre el
sistema operativo principal,
pero sin depender de un sistema virtual.

------------------------------------------------------
Characteristics of Microservices
Independent Technology Stacks.
Independent Scaling.
Independent Evolution of Features.
Stable Interfaces – Standardized Communication.
Componentization via Services.
Favors Cross-Functional Teams.

---------------------------------------------
Understanding the CAP theory Before we dig into the details we have to discuss what
CAP actually means.
CAP is an abbreviation for the following three features:
• Consistency: This feature indicates whether all the nodes in a cluster see the
same data at the same time or not.
• Availability: This feature indicates if it is certain that you will receive an
answer to every request.
Can a user consider all the nodes in a cluster to be available? Think of data
or state information split between two machines.
A request is made, and machine 1 has some of the data and machine 2 has the
rest of the data.
If either machine goes down, not all the requests can be fulfilled, because
not all of the data or state information is available entirely on either machine.
• Partition tolerance: This feature indicates if the system will continue to work
if arbitrary messages are lost on the way.
A Network Partition event occurs when a system is no longer accessible (think
of a network connection failing).
 A different way of considering partition tolerance is to think of it as
message passing.
If an individual system can no longer send/receive messages to/ from other
systems, it has been effectively partitioned out of the network.

Comprender la teoría de la PAC Antes de profundizar en los detalles, debemos

analizar qué significa realmente la PAC.
CAP es la abreviatura de las siguientes tres características:
• Consistencia: esta característica indica si todos los nodos de un clúster ven los
mismos datos al mismo tiempo o no.
• Disponibilidad: esta función indica si es seguro que recibirá una respuesta para
cada solicitud.
¿Puede un usuario considerar que todos los nodos en un clúster estén
disponibles?
Piense en información de datos o estado dividida entre dos máquinas.
Se realiza una solicitud, y la máquina 1 tiene algunos datos y la máquina 2
tiene el resto de los datos.
Si cualquiera de las máquinas se cae, no se pueden cumplir todas las
solicitudes,
porque no todos los datos o la información de estado están disponibles por
completo en ninguna de las máquinas.
• Tolerancia de partición: esta característica indica si el sistema continuará
funcionando si se pierden mensajes arbitrarios en el camino.

Un evento de Partición de Red ocurre cuando un sistema ya no es accesible

(piense en una conexión de red que falla).
Una forma diferente de considerar la tolerancia de partición es considerarla
como un mensaje que pasa.
Si un sistema individual ya no puede enviar / recibir mensajes hacia / desde
otros sistemas, ha sido efectivamente particionado fuera de la red.

Propiedades críticas de un ACID de transacción

Propiedades críticas de un ACID de transacción
Atomicidad: compromiso de transacción exitosa; aborto fallido de la transacción.
Consistencia: cada transacción está programada para preservar la consistencia de la
base de datos.
Aislamiento: cada transacción se ejecuta como si se ejecutara solo.
Durabilidad: el resultado de una transacción comprometida está garantizado en un
almacenamiento estable.

Propagating Updates
Asynchronous (Lazy / Store and Forward) - Post commit sends information to all
other systems involved in the distribution. – Trade Off: Data synchronization and
conflict resolution
Synchronous (Eager) – Pre commit sends information to all other systems in the
distribution and verifies a commit or roll back on each transaction for the entire
distribution. – Trade Off: Performance and scalability

¿Cuales son los modos de propagación de actualizaciones en PostgreSQL?

Asincrónico (Lazy / Store and Forward): La confirmación de envío envía información

a todos los demás sistemas involucrados en la distribución.
- Trade Off: sincronización de datos y
resolución de conflictos
Sincrónico (Eager): La confirmación previa envía información a todos los otros
sistemas en la distribución y verifica una confirmación o restitución en cada
transacción para toda la distribución.
- Trade Off: rendimiento y escalabilidad
--------------------------------------
Recorrer el árbol usando CON RECURSIVO
CREATE TABLE empl ( NAME TEXT PRIMARY KEY, boss TEXT NULL DEFAULT NULL);
INSERT INTO empl VALUES ('Paul',NULL);
INSERT INTO empl VALUES ('Luke','Paul');
INSERT INTO empl VALUES ('Kate','Paul');
INSERT INTO empl VALUES ('Marge','Kate');
INSERT INTO empl VALUES ('Edith','Kate');
INSERT INTO empl VALUES ('Pam','Kate');
INSERT INTO empl VALUES ('Carol','Luke');
INSERT INTO empl VALUES ('John','Luke');
INSERT INTO empl VALUES ('Jack','Carol');
INSERT INTO empl VALUES ('Alex','Carol');
WITH RECURSIVE t(LEVEL,path,boss,NAME) AS (
SELECT 0,NAME,boss,NAME FROM empl WHERE boss IS NULL
UNION
SELECT
LEVEL + 1,
path || ' > ' || empl.NAME,
empl.boss,
empl.NAME
FROM
empl JOIN t
ON empl.boss = t.NAME
) SELECT * FROM t ORDER BY path;

----
CREATE TABLE empl (
NAME TEXT PRIMARY KEY,
boss TEXT NULL DEFAULT NULL
);
INSERT INTO empl VALUES ('Paul',NULL),('Luke','Paul'),('Kate','Paul'),
('Marge','Kate'),('Edith','Kate'),('Pam','Kate'),('Carol','Luke'),('John','Luke'),
('Jack','Carol'),('Alex','Carol');
WITH RECURSIVE t(LEVEL,path,boss,NAME) AS (
SELECT 0,NAME,boss,NAME FROM empl WHERE boss IS NULL
UNION
SELECT LEVEL + 1, path || ' > ' || empl.NAME, empl.boss, empl.NAME FROM empl JOIN
t ON empl.boss = t.NAME
) SELECT * FROM t ORDER BY path;

++++++++++++++++++++
CREATE TABLE empl (
NAMES TEXT PRIMARY KEY,
boss TEXT NULL DEFAULT NULL
);
INSERTS INTO empl VALUES ('Paul',NULL),('Luke','Paul'),('Kate','Paul'),
('Marge','Kate'),('Edith','Kate'),('Pam','Kate'),('Carol','Luke'),('John','Luke'),
('Jack','Carol'),('Alex','Carol');
WITH RECURSIVE t(LEVEL,path,boss,NAME) AS (
SELECT 0,NAME,boss,NAME FROM empl WHERE boss IS NULL
UNION
SELECT LEVEL + 1, path || ' > ' || empl.NAME, empl.boss, empl.NAME FROM empl JOIN
t ON empl.boss = t.NAME
) SELECT * FROM t ORDER BY path;
---------------
CREATE TABLE empl (
NAMES TEXT PRIMARY KEY,
boss TEXT NULL DEFAULT NULL
);
INSERTS INTO empl VALUES ('Paul',NULL),('Luke','Paul'),('Kate','Paul'),
('Marge','Kate'),('Edith','Kate'),('Pam','Kate'),('Carol','Luke'),('John','Luke'),
('Jack','Carol'),('Alex','Carol');
select empl.NAME || ' > ' || empl.NAME, empl.boss,
empl.NAME from empl where name = (select name from empl where name = null)
union
SELECT * FROM t ORDER BY NAME;

https://goalkicker.com/,
PostgreSQL Notes for Professionals, pag 31

--
Using VACUUM
The PostgreSQL SQL VACUUM command has two uses:
• Reclaiming database storage space
• Updating optimizer statistics
The VACUUM command has the following syntax:
---
Usando VACÍO
El comando PostgreSQL SQL VACUUM tiene dos usos:
Recuperar el espacio de almacenamiento de la base de datos
Actualización de las estadísticas del optimizador
El comando VACUUM tiene la siguiente sintaxis:

Using VACUUM
The PostgreSQL SQL VACUUM command has two uses:
• Reclaiming database storage space
• Updating optimizer statistics
The VACUUM command has the following syntax:

-----------------------------------------------------------------------------------
----------
-----------------------------------------------------------------------------------
------------
Características de GraphQL GraphQL tiene algunas ventajas claras sobre REST,
especialmente cuando se trata de algunas de las características mencionadas en
GraphQL de la siguiente manera:
Consultas jerárquicas: la estructura de las consultas se ve exactamente como los
datos de respuesta. Un cliente desafía la respuesta que desea y cómo debería verse,
y los datos de respuesta se parecerán automáticamente a los que el cliente
solicitó.
Introspectivo: GraphQL le permite al cliente consultar sobre los campos, tipos y
consultas compatibles. Esto es lo que permite a GraphQL realizar la
autocompletación de consultas y proporcionar documentación de esquemas. Con esta
característica, el cliente puede saber exactamente qué operaciones son compatibles
y los campos requeridos y qué tipo de resultados se pueden devolver. A partir de
esa información general, el cliente puede elegir cuidadosamente solo las partes
relevantes.
Fuertemente tipado: la presencia de un sistema de tipo permite la validación de
consultas sintácticas y el servidor responde con mensajes de error apropiados. Esto
implica que, si el esquema en el servidor desafía que está esperando que un
parámetro de consulta sea un entero, un tipo de datos diferente dará como resultado
un error de validación. La mayoría de los editores de consultas GraphQL han sido
equipados con la capacidad de detectar estos errores en función del esquema.
Consultas especificadas por el cliente: el cliente decide qué datos desean a través
de diferentes campos en las consultas. Esta es una gran ventaja sobre REST, donde
la función GET recupera todos los datos de la API.

--
Queries jerárquicos: La estructura de los queries se ve exactamente como la
información de respuesta.
Un cliente desafía qué respuesta ellos quieren y lo que debería verse y los datos
de respuesta automáticamente se parecerán a lo que el cliente pidió.

--
Cuales son las características de GraphQL
GraphQL tiene algunas ventajas claras sobre REST, especialmente cuando se trata de
algunas de las características mencionadas en GraphQL de la siguiente manera:

Consultas jerárquicas: La estructura de las consultas se ve exactamente como los

datos de respuesta.
Un cliente desafía la respuesta que desea y
cómo debería verse, y los datos de respuesta se parecerán automáticamente a los que
el cliente solicitó.
Introspectivo: GraphQL le permite al cliente consultar sobre los campos, tipos y
consultas compatibles.
Esto es lo que permite a GraphQL realizar la
autocompletación de consultas y proporcionar documentación de esquemas.
Con esta característica, el cliente puede saber
exactamente qué operaciones son compatibles y los campos requeridos
y qué tipo de resultados se pueden devolver. A
partir de esa información general, el cliente puede elegir cuidadosamente solo las
partes relevantes.
Fuertemente tipado: La presencia de un sistema de tipado permite la validación de
consultas sintácticas y el servidor responde con mensajes de error apropiados.
Esto implica que, si el esquema en el servidor
desafía que está esperando que un parámetro de consulta sea un entero,
un tipo de datos diferente dará como resultado un
error de validación.
La mayoría de los editores de consultas GraphQL han
sido equipados con la capacidad de detectar estos errores en función del esquema.
Consultas especificadas por el cliente: el cliente decide qué datos desean a través
de diferentes campos en las consultas.
Esta es una gran ventaja sobre REST, donde la función
GET recupera todos los datos de la API.

--
Consultas jerárquicas: La estructura de las consultas se ve exactamente como los
datos de respuesta.
Introspectivo: GraphQL le permite al cliente consultar sobre los campos, tipos y
consultas compatibles.
Esto es lo que permite a GraphQL realizar la
autocompletación de consultas y proporcionar documentación de esquemas.

Fuertemente tipado: La presencia de un sistema de tipado permite la validación de

consultas sintácticas y el servidor responde con mensajes de error apropiados.

Consultas especificadas por el cliente: El cliente decide qué datos desean a través
de diferentes campos en las consultas.

------
Mutation
Las queries nos permiten obtener datos, pero toda aplicación necesita una forma de
crear, modificar, eliminar o interactuar con estos datos.
Estas acciones son llamadas mutaciones. Una mutación es similar a una función:
recibe ciertos parámetros, realiza un cambio y devuelve una respuesta. Así:
Mientras que las consultas son sinónimos del método REST que obtiene datos: GET.
Las mutaciones son sinónimos de los métodos REST que crean y actualizan datos como,
POST, PUT, PATCH y DELETE.

Las suscripciones son una caracteristicas de GraphQL que permite obtener

actualizaciones en tiempo real desde la base de datos en un backend GraphQL.
Los configuras suscribiéndote a los cambios que son causados por mutaciones
específicas y luego ejecutas algún código en tu aplicación para reaccionar ante ese
cambio.

Beginning GraphQL
Brian Kimokoti

-------------------------

Envío de servidor (s)

Estos parámetros se pueden configurar en cualquier servidor que envíe datos de
replicación a uno o más en espera
servidores
El maestro siempre es un servidor de envío, por lo que estos parámetros siempre se
deben establecer en el maestro.
La función y el significado de estos parámetros no cambia después de que un modo en
espera se convierta en el maestro.

Cuales son los parámetros de configuración de Replicación mediante Envío de

servidor (Sending Server(s))
max_wal_senders (integer)
max_replication_slots (integer)
wal_keep_segments (integer)
wal_sender_timeout (integer)
track_commit_timestamp (boolean)

synchronous_standby_names (string)
vacuum_defer_cleanup_age (integer)

hot_standby (boolean)
max_standby_archive_delay (integer)
max_standby_streaming_delay (integer)
wal_receiver_status_interval (integer)
hot_standby_feedback (boolean)
wal_receiver_timeout (integer)
wal_retrieve_retry_interval (integer)

-------------------------------
patrón de arquitectura de software
El patrón de componentes:
Se utiliza no solo en el desarrollo de software, sino también en la fabricación,
construcción y otros campos.
Consiste en combinar bloques de construcción más pequeños y discretos en productos
terminados más grandes.
En el desarrollo de software, los componentes son unidades lógicas que se pueden
combinar en aplicaciones más grandes.
Los componentes tienden a tener lógica interna y propiedades que están protegidas u
ocultas de la aplicación más grande.

La aplicación más grande consume estos bloques de construcción a través de

pasarelas específicas, llamadas interfaces,
que exponen solo lo que se necesita para hacer uso del componente. De esta manera,
la lógica interna del componente se
puede modificar sin afectar a la aplicación más grande, siempre que las interfaces
no se cambien.

Volviendo a nuestro ejemplo de batería, el automóvil consume la batería a través de

una serie de conectores. Sin embargo, si la batería se agota,
se puede reemplazar por una batería completamente nueva, siempre que esa batería
tenga los mismos conectores.
Esto significa que el fabricante del automóvil no tiene que preocuparse por los
componentes internos de la batería,
lo que simplifica el proceso de construcción del automóvil. Aún más importante, el
propietario del automóvil no tiene
que reemplazar su automóvil cada vez que la batería se agota. Para ampliar la
analogía, los fabricantes de baterías pueden
comercializarlos para una gama de diferentes vehículos, por ejemplo, vehículos todo
terreno, barcos o motos de nieve.
Así que el patrón de componentes les permite realizar economías de escala aún
mayores.

Uso del patrón de componentes en aplicaciones web A medida que las aplicaciones web
continúan haciéndose más sofisticadas,
la necesidad de poder construirlas a partir de componentes más pequeños y discretos
se vuelve más convincente.
Los componentes permiten que las aplicaciones se construyan de una manera que evite
que se conviertan en un desorden del código spaghetti.
En su lugar, el diseño basado en componentes nos permite razonar sobre partes
específicas de la aplicación de forma aislada de las otras partes,
y luego podemos unir la aplicación en un punto de conexión completo y completo a
través de un acuerdo. Además,
los costos de mantenimiento son menores porque la lógica interna de cada componente
se puede administrar por separado sin afectar las otras partes de la aplicación.
Y poner las aplicaciones juntas utilizando componentes de autodescripción hace que
la aplicación sea más fácil de entender a un nivel más alto de abstracción.

--
Modelo-vista-controlador (MVC)
es un patrón de arquitectura de software, que separa los datos y la lógica de
negocio de una aplicación de su representación
y el módulo encargado de gestionar los eventos y las comunicaciones.
Para ello MVC propone la construcción de tres componentes distintos que son el
modelo, la vista y el controlador, es decir,
por un lado define componentes para la representación de la información,
y por otro lado para la interacción del usuario.12 Este patrón de arquitectura de
software se basa en
las ideas de reutilización de código y la separación de conceptos, características
que buscan facilitar
la tarea de desarrollo de aplicaciones y su posterior mantenimiento.34

Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa

los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres
componentes distintos.
El Modelo que contiene una representación de los datos que maneja el sistema, su
lógica de negocio, y sus mecanismos de persistencia.
La Vista, o interfaz de usuario, que compone la información que se envía al cliente
y los mecanismos interacción con éste.
El Controlador, que actúa como intermediario entre el Modelo y la Vista,
gestionando el flujo de información entre ellos y las transformaciones para adaptar
los datos a las necesidades de cada uno.

---
El patrón Composite sirve para construir objetos complejos a partir de otros más
simples y similares entre sí,
gracias a la composición recursiva y a una estructura en forma de árbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos
una interfaz común, se tratan todos de la misma manera.
Dependiendo de la implementación, pueden aplicarse procedimientos al total o una de
las partes de la estructura compuesta como si de un nodo final se tratara,
aunque dicha parte esté compuesta a su vez de muchas otras. Un claro ejemplo de uso
extendido de este patrón se da en los entornos de programación 2D para aplicaciones
gráficas.
Un videojuego puede contener diferentes capas "layers" de sprites (como una capa de
enemigos)
pudiéndose invocar un método que actúe sobre toda esta capa de sprites a la vez
(por ejemplo, para ocultarlos, darles un filtro de color etc.).

--
El patrón modelo–vista–modelo de vista (en inglés, model–view–viewmodel, abreviado
MVVM) es un patrón de arquitectura de software.
Se caracteriza por tratar de desacoplar lo máximo posible la interfaz de usuario de
la lógica de la aplicación.
El modelo: Representa la capa de datos y/o la lógica de negocio, también denominado
como el objeto del dominio.
El modelo contiene la información, pero nunca las acciones o servicios que la
manipulan. En ningún caso tiene dependencia alguna con la vista.
La vista: La misión de la vista es representar la información a través de los
elementos visuales que la componen.
Las vistas en MVVM son activas, contienen comportamientos, eventos y enlaces a
datos que, en cierta manera, necesitan tener conocimiento del modelo subyacente.
Modelo de vista: El modelo de vista es un actor intermediario entre el modelo y la
vista, contiene toda la lógica de presentación y se comporta como una abstracción
de la interfaz.
La comunicación entre la vista y el viewmodel se realiza por medio los enlaces de
datos.

G14577