Autor: Jhonathan Borda Moreno

Razonamiento aproximado – Introducción
Desde la invención del perceptrón hemos avanzado muchísimo en el campo de la inteligencia artificial, el poder de computo y las técnicas para procesamiento de datos a crecido de manera extraordinaria y hoy en día tenemos modelos predictivos y generativos francamente impresionantes, cada día salen nuevas noticias e investigaciones de modelos de millones de parámetros, que si tienen conciencia (obviamente no), o que mejoran en predicciones y en general en lo que consideramos un comportamiento inteligente.

Justamente la clave para analizar estos avances radica en nuestra concepción de inteligencia ¿Qué entendemos por inteligente? Por ejemplo, podemos decir que un sistema es inteligente por que nos permite diferenciar entre perritos y gatitos, pero si extrapolamos esto a un humano claramente no asumiríamos que una persona es inteligente solo por diferencias entre perros y gatos; ahora si llevamos esto a diferentes etapas del desarrollo humano, en especifico a la infancia temprana podemos decir que hay indicios de inteligencia. Entonces, definimos la inteligencia artificial como sistemas que replican comportamientos humanos que consideramos inteligentes.
Teniendo en cuenta la premisa anterior debemos considerar que la inteligencia humana esta llena de incertidumbre e imprecisión, justamente la curiosidad es el mayor motor para el avance científico y es producto de un camino que recorremos hace miles de años, un proceso evolutivo y mental que queremos concluir por ejemplo en una teoría del todo, o en deserciones filosóficas para tratar de tener control y superar a la misma muerte (Si tiene curiosidad de por que digo esto vea este libro: Política para Amador). El punto del asunto es preguntarnos que tan relevante debería ser la incertidumbre en nuestros algoritmos; por eso se celebra un congreso para crear sistemas híbridos, dejando en claro que la inteligencia artificial no lo resuelve todo y que se necesita un acercamiento humano para entender y contextualizar los problemas; estamos acostumbrados a obtener grandes cantidades de datos y luego por medio de procesos estadísticos o métodos de inteligencia artificial inferir resultados y estimar predicciones, pero en estos procesos no se tiene en cuenta los sesgos humanos, coloquemos un ejemplo mas claro: imaginemos que se realiza una encuesta a diferentes poblaciones para determinar el nivel de felicidad, esto es muy subjetivo tanto para los encuestados como para los encuestadores, ya que los encuestadores por mas imparciales que pretendan ser interpretaran los datos a su propio contexto y por ejemplo no se tiene en cuenta la propia conducta y pensamiento humano; ahora podríamos decir que es por que nos falta variables, pero en si es imposible obtenerlas todas y ya veremos el por que.

El universo en si es un sistema caótico, por mas modelos o representaciones que hagamos de el simplemente no alcanzamos a modelar la realidad, para poder predecir algo con suma certeza deberíamos tomar todo nuestro universo y descomponerlo en variables, crear una simulación completa del todo, lo cual es imposible ya que ni siquiera conocemos la totalidad del universo y avanzamos poco a poco pero parece que nunca alcanzaremos datos totalmente certeros; y es que esta es la magia de los sistemas caóticos, podemos medir tanto como queramos, aproximarnos a cantidades de errores infinitesimales y aun así no obtendremos la cantidad exacta, vivimos en la paradoja de Zenón.

A pesar del caos muchas de nuestras mediciones y predicciones podemos hacerlas a partir de un contexto local, dándonos resultados muy buenos, este tipo de aproximaciones las trabajamos con la lógica difusa, que justamente considera las relaciones entre las variables de un contexto. Recuerdo un anécdota muy curioso de cuando la Nasa estrelló una sonda por una mala comunicación entre los ingenieros, esto demuestra que no solo es tomar datos y asumir que es suficiente, se debe hacer un análisis humano, a conciencia, previniendo y teniendo en cuenta nuestros sesgos y contextos.

Las principales causas de incertidumbre son:

Insuficiente experiencia

Inadecuada representación del conocimiento

Información poco fiable

No completitud

Inexactitud inherente al lenguaje

Sabemos que no podemos mitigar en su totalidad la incertidumbre pero podemos asociar niveles de confianza a la información, por ejemplo usando probabilidades o factores de certeza. Veamos algunos ejemplos de esto:

Probabilidad

Podemos modelar la incertidumbre a través del teorema de Bayes.

*estos datos son ilustrativos
P(S/M)=0,5 Probabilidad de tener Covid y fiebre
P(M)=1/6 Probabilidad de tener Covid
P(S)=1/20 Probabilidad de tener fiebre
P(M/S)=(0,5)*(1/6)/(1/20)=1.6

Como dijimos es muy difícil tener una certeza por que no tenemos todas las variables, además que debemos tener en cuenta las variables excluyentes también, ahí se nos va complicando la cosa.

Valores de certeza

Otra aproximación puede ser el uso de factores de certeza, estos son básicamente juicios dados por un experto e implementados correctamente puede facilitar muchísimo las estimaciones.

Por ejemplo, con la pandemia si tenias tos y fiebre el valor de certeza de Covid era muy alto, los médicos señalaban casi con total seguridad de que se trataba de este virus.

Los valores de certeza se dan en un intervalo de $[-1,1]$ , donde $1$ indica completa confianza y $-1$ la no creencia. Veamos la definición matemática para calcular un valor de certeza. $R1$ y $R2$ son reglas que alcanzan una misma conclusión $h$ , a partir de dos evidencias $e_1$ y $e_2$ :

$R1$ : Si $e_1$ entonces $h$ , CF(h,e_1)

$R2$ : Si $e_2$ entonces $h$ , CF(h,e_2)

El factor de certeza de $h$ se calcula como:

$CF(h,e_1)+CF(h,e_2)(1-CF(h,e_1))$ , si $CF(h,e_1)>0$ y $CF(h,e_2)>0$

$CF(h,e_1)+CF(h,e_2)(1+CF(h,e_1))$ , si $CF(h,e_1)<0$ y $CF(h,e_2)<0$

$[CF(h,e_1)+CF(h,e_2)]/(1-min(|CF(h,e_1)|,|CF(h,e_2)|)$ , en cualquier otro caso

Veamos unos ejemplos:

$R1$ : Si viernes entonces trafico, $0.8$

$R2$ : Si llueve entonces trafico, $0.7$

$h$ : Hoy es viernes y llueve ¿Cuál es la certeza de trafico?

$0.8+0.7*(1-0.8)=0.94$

*Se refuerza la certeza con ambas positivas

$R1$ : Si viernes entonces trafico, $0.8$

$R2$ : Si fin de mes entonces trafico, $-0.4$

$h$ : Hoy es viernes y fin de mes ¿Cuál es la certeza de trafico?

$0.8+(-0.4)/(1-min(0.8,0.4))=0.66$

*Se disminuye la fuerza de la mayor
Es importante tener presente las diferencias entre el enfoque probabilístico y los valores de certeza.

Las probabilidades vienen a partir de la medición y calculo de los datos; por el contrario los factores de certeza son evaluaciones o apreciaciones personales.

En resumen debemos quedarnos con que los modelos que realizamos son aproximaciones de la realidad y no son capaces de prevenir outliers. Estamos en un universo caótico y debemos tener en cuenta la incertidumbre. En próximos post veremos al detalle métodos que tratan de superar e incluso se apoyan en la incertidumbre.
junio 23, 2022
Spring Boot – Configuración
Vimos anteriormente que se puede hacer la inyección de dependencias por medio de archivos xml y usando anotaciones; sin embargo también podemos usar clases de configuración para instanciar objetos de manera fácil y limpia.

import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class AppConfig { @Bean("student") public Student getStudent(Service service) { return new StudentImpl(service); } @Bean("service") public Service getService() { return new ServiceImpl(); } }
La ventaja de este método es que permite liberar a las clases de negocio de anotaciones, dejándolas limpias.

La clave es marcar la clase con el decorador @Configuration, es cual es procesado por el Spring IoC, que en este caso crea las instancias marcadas con @Bean.

Veamos un ejemplo muy básico:

Creamos una interfaz con un método de prueba:
public interface Service { String hello(); }

Creamos la implementación del servicio:
public class ServiceImpl implements Service { @Override public String hello() { return "Hola"; } }

Creamos el archivo de configuración:
@Configuration public class Config { @Bean("service") public Service getService() { Service myService = new ServiceImpl(); System.out.println(myService.hello()); return myService; } }

Lo que hacemos es instanciar la implementación e imprimir en consola el String que viene del método hello, lo que resulta que al ejecutar la aplicación veamos un “hola” en consola.

. ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.7.0) Hola

Al ser una clase Java obtenemos las ventajas propias del lenguaje, como asegurarnos del tipado correcto, comprobación en tiempo de compilación y algo mas amigable para la lectura.

También si se desea, podemos usar las anotaciones en conjunto con con las clases de configuración.
Ver en GitHub
junio 21, 2022
Introducción a la minería de datos
El aprendizaje automático o supervisado hace parte de la minería de datos. Estos se concentran justamente en los modelos generados a partir de datos de naturaleza empírica, es decir, datos preexistentes resultado de un trabajo previo que no necesariamente estaban destinados a análisis de negocio, por ejemplo el histórico de ventas de un producto, su razón principal de ser es mantener un control sobre stock y ventas, pero a partir de estos registros podemos extraer mucha información relacionada con el producto. Actualmente este es el método mas utilizado, a partir de bases de datos existentes se hace el análisis de datos, de ahí el nombre de minería de datos, encontrar los valiosos patrones existentes en estas colecciones.

Tenemos muchas metodologías que nos sirve de marco (KDD, SEMMA, ASUM-DM entre otras), la mas conocidas y utilizadas esta CRISP-DM.

CRISP-DM

Cross-Industry Standard Process for Data Mining, integra todas las tareas necesarias para los proyectos de minería de datos, veamos sus fases:

Predicción

En el aprendizaje supervisado tenemos dos tipos de problemas en función del tipo de salida, que llamaremos clase (variable objetivo):

Regresión: variable de salida es numérica (número real).

Clasificación. variable es categórica (número discreto o etiqueta nominal).

Esta clase(predicción) se apoya en el conjunto de datos de entrada(dataset), en donde cada celda representa un dato de entrada; estos campos pueden ser de tipo numérico o categórico que llamaremos atributo, los cuales hacen parte de una instancia, es decir, una fila del dataset.
Las características principales para describir un data set son:

Número de instancias.

Número de atributos.

Nombre, tipo y breve descripción de cada atributo.

Tipo de datos de la clase, si tiene, y dominio de valores.

Nombre y breve descripción de la clase, si tiene.

Cantidad de valores ausentes.

El dominio se refiere al conjunto de valores que puede tomar la clase.
Principales roles

Voy a listar algunos de los roles mas comunes:

Director técnico de proyecto(data scientist chief): Conocimientos de gestión y técnicos. Mucha experiencia en el campo.

Científico de datos(data scientist – ML engineer): Buena comunicación, selección de soluciones y estrategias. Fuertes bases matemáticas y de informática. MLOps.

Analista de datos(data analyst): Fuertes bases de estadística, conocer la inteligencia de negocio.

Ingeniero de datos(data engineer): Manejo de bases de datos, uso de herramientas y lenguajes para construir las soluciones.

Para profundizar mas en estos roles recomiendo el artículo de The different data science roles in the industry

Diferencia entre Bias y Varianza

Tenemos tres tipos de errores:

Error irreducible: Propio de los datos.

Error de bias: Es la diferencia entre la predicción esperada de nuestro modelo y los valores verdaderos.

Error de varianza: Se refiere a la cantidad que la estimación de la función objetivo cambiará si se utiliza diferentes datos de entrenamiento.
junio 2, 2022
Fundamentos matemáticos para la computación cuántica
Números complejos

Los números complejos $\mathbb C$ puede representarse como la suma de un número real y un número imaginario.

$a = a_{r}+ia_{i},$ con $i=\sqrt{-1}$ $y:$

$a_{r}$ componente real, $a_{r} = \Re (a)$

$a_{i}$ componente imaginaria, $a_{i} = \Im (a)$

Operaciones con complejos
Suma

$a+b=(a_{r}+b_{r})+i(a_{i}+b_{i})\in \mathbb{C}$

Producto

Recordemos que $i^{2}=-1$

$ab=(a_{r}+ia_{i})(b_{r}+ib_{i})=(a_{r}b_{r}-a_{i}b_{i})+i(a_{r}b_{i}+a_{i}b_{r})\in \mathbb{C}$

Conjugado

El conjugado se obtiene cambiando el signo de su componente imaginaria.

$\bar{a}=a_r-ia_i$ o $a^*=a_r-ia_i$

La conjugación del denominador complejo juega el mismo papel que la racionalización de un denominador irracional. Se busca que el denominador sea real.

Facilita la división de números complejos, pues al conjugar el denominador, el cociente se transforma en un producto del dividendo por el inverso multiplicativo del divisor.

Permite calcular el módulo de cualquier número complejo.

Norma(Módulo)

Es el número real positivo que mide su tamaño y generaliza el valor absoluto de un número real. Esta noción es particularmente útil para definir una distancia en el plano complejo.

$|a|^2=a^*a=(a_r-ia_i)(a_r+ia_i)=a_r^2+ia_ra_i-ia_ia_r+a_i^2=a_r^2+a_i^2$

$\Rightarrow |a|=+\sqrt{a_r^2+a_i^2}\in \mathbb{R}$

División

$\frac{a}{b}=\frac{ab^*}{bb^*}$

$=\frac{(a_r+ia_i)(b_r-ib_i)}{|b|^2}$

$=\frac{(a_rb_r+a_ib_i)+i(a_ib_r-a_rb_i}{|b|^2}\in \mathbb{C}$

Forma polar

Podemos representar los números complejos como puntos en el plano, cada punto del plano se determina por una distancia y un ángulo.

Esta forma de representar los números complejos es ampliamente utilizada en física y trigonometría, ya que es normalmente mucho más simple trabajar con números complejos expresados en forma polar que con su equivalente en forma rectangular(forma que vimos anteriormente).

Formula de Euler: $e^{i\theta} = \cos\theta + i\sin\theta$ con $\theta\in \mathbb{R}$ denominada fase.

Nótese que en esta fórmula, al igual que en todas aquellas en las que intervienen exponenciales de ángulos, se asume que el ángulo θ está expresado en radianes.

Veamos algunas operaciones con forma polar:

Sean $a,b \in \mathbb{C}, a=|a|e^{i\theta}, b=|b|e^{i\varphi}$ , con $|a|, |b|, \theta, \varphi \in \mathbb{R}$

Ilustración de un número complejo en el plano complejo usando la fórmula de Euler

Producto

$a b = |a||b|e^{i(\theta+\varphi)} = |ab| (\cos(\theta+\varphi)+i\sin(\theta+\varphi))$

Conjugado

$a^* = |a|e^{-i\theta} = |a| (\cos\theta - i\sin\theta)$

División

$\frac{a}{b} = \frac{|a|}{|b|}e^{i(\theta-\varphi)} = \frac{|a|}{|b|}(\cos(\theta-\varphi)+i\sin(\theta-\varphi))$

Potencia

$a^n = |a|^ne^{in\theta} = |a|^n (\cos(n\theta) - i\sin(n\theta))$

Exponenciación

$e^{(x+yi)} = e^xe^{iy} = e^x(\cos(y)+i\sin(y))$

Raíces

$\sqrt[n]{a} = a^\frac{1}{n} = |a|^\frac{1}{n}e^{i\frac{\theta+2k\pi}{n}}$

Hagamos unas operaciones para sacar la norma y la fase con la forma polar.

Espacio de Hilbert

Es una generalización del concepto de espacio euclídeo. Esta generalización extiende los métodos del álgebra lineal y el cálculo aplicados en el espacio euclídeo de dos dimensiones y tres dimensiones a los espacios de dimensión arbitraria, incluyendo los espacios de dimensión infinita.

El estado de un sistema cuántico viene descrito por un vector (vector de estado) en un espacio de Hilbert de componentes complejas.
Espacio vectorial complejo: conjunto no vacío de elementos, denominados vectores, que incluye las operaciones de suma, negación y multiplicación por un escalar
Los vectores se representan como arrays de 𝑛 filas y 1 columna.

$\vec{v}=\begin{bmatrix} v_0\\ v_1\\ \vdots \\ v_{n-1} \end{bmatrix}$

$v_i\in \mathbb{C}$ y $n$ es la dimensión del espacio.

El espacio $\mathbb{V} = \mathbb{C}^2$ formado por los vectores de 2 elementos complejos con producto escalar es un espacio de Hilbert.

Notación de Dirac(bra-ket)

Es la notación estándar para describir los estados cuánticos, también se utiliza para denotar vectores abstractos y funcionales lineales en matemática.

El estado de un sistema físico se identifica con un vector en el espacio de Hilbert complejo, $\mathcal{H}$ . Cada vector se llama un ket, y se denota como $|\psi \rangle$ . Cada ket $|\psi \rangle$ tiene un bra dual, escrito como $\langle \phi |$ , esto es una funcional lineal continua de $\mathcal{H}$ a los números complejos C.

Ket: $|\,\rangle$

Bra: $\langle\,|$

$|v\rangle = \begin{bmatrix} v_0 \\ v_1\\ \vdots \\v_{n-1} \end{bmatrix}$

$\langle v| = (|v\rangle)^\dagger = \begin{bmatrix} v_0^* & v_1^* & \cdots & v_{n-1}^* \end{bmatrix}$

donde el símbolo $\dagger$ representa la matriz traspuesta conjugada

Producto escalar o interno

Se utiliza para determinar si dos vectores son ortogonales.

Sean $|u\rangle$ y $|v\rangle$ vectores de dimensión $n$ .

$\langle v|u\rangle = \begin{bmatrix} v_0^* & v_1^* & \cdots & v_{n-1}^* \end{bmatrix}\cdot \begin{bmatrix} u_0 \\ u_1\\ \vdots \\u_{n-1} \end{bmatrix} = v_0^*u_0 + v_1^*u_1 + \cdots + v_{n-1}^*u_{n-1} \in \mathbb{C}$

Módulo(Norma)

$\lVert|v\rangle\|^2 = \langle v|v\rangle = v_0^*v_0 + v_1^*v_1 + \cdots + v_{n-1}^*v_{n-1}$

$=|v_0|^2 + |v_1|^2 + \cdots + |v_{n-1}|^2 \in \mathbb{R}$

Esta norma es siempre positiva

$\||v\rangle\|\ge 0$, y $\||v\rangle\|= 0\Leftrightarrow |v\rangle = 0$

Propiedades del producto interno

Linealidad por la izquierda:- $\langle (\alpha v+\beta w)|u\rangle = \alpha\langle v|u\rangle+\beta\langle w|u\rangle$ con $\alpha,\beta \in \mathbb{C}$

Linealidad conjugada por la derecha: $\langle v|(\alpha u+\beta w)\rangle = \alpha^*\langle v|u\rangle+\beta^*\langle v|w\rangle$ con $\alpha,\beta \in \mathbb{C}$

Hermiticidad: $\langle v|u\rangle = (\langle u|v\rangle)^*$

Producto externo (outer product)

Se usa para probar si dos vectores son paralelos.

El producto externo de dos vectores de dimensión $n$ es una matriz de dimensión $n\times n$

$|u\rangle\langle v| = \begin{bmatrix} u_0 \\ u_1\\ \vdots \\u_{n-1} \end{bmatrix}\cdot \begin{bmatrix} v_0^* & v_1^* & \cdots & v_{n-1}^* \end{bmatrix}= \begin{bmatrix} u_0v_0^* & u_0v_1^* & \cdots & u_0v_{n-1}^*\\ u_1v_0^* & u_1v_1^* & \cdots & u_1v_{n-1}^*\\ \vdots & \vdots & \ddots & \vdots\\ u_{n-1}v_0^* & u_{n-1}v_1^* & \cdots & u_{n-1}v_{n-1}^*\\ \end{bmatrix}$

Propiedades del producto externo

$|u\rangle\langle v| = (|v\rangle\langle u|)^\dagger$

$(|u\rangle + |v\rangle)(\langle w|+\langle x|)$
$= |u\rangle(\langle w|+\langle x|)+|v\rangle(\langle w|+\langle x|)$
$= |u\rangle\langle w|+|u\rangle\langle x|+|v\rangle\langle w|+|v\rangle\langle x|$

$\alpha(|u\rangle\langle v|) = (\alpha|u\rangle)\langle v|$
$= |u\rangle(\alpha\langle v|)$ con $\alpha\in \mathbb{C}$

$(|u\rangle\langle v|)|w\rangle$
$= |u\rangle(\langle v|w\rangle)$
$= (\langle v|w\rangle)|u\rangle$ ya que $\langle v|w\rangle$ es un escalar

Producto tensor (Kronecker)

Denotado con $\otimes$ , a una operación sobre dos matrices de tamaño arbitrario que da como resultado una matriz bloque. Es un caso especial del producto tensorial. El producto de Kronecker no debería confundirse con el producto de matrices habitual, que es una operación totalmente diferente.

El producto tensor de un vector $|u\rangle$ de $m$ elementos y un vector $|v\rangle$ de $n$ elementos es un vector de $m\cdot n$ elementos dado por:

$|u\rangle\otimes|v\rangle \equiv |u\rangle|v\rangle \equiv |uv\rangle = \begin{bmatrix} u_0 \begin{bmatrix} v_0 \\ v_1\\ \vdots \\v_{n-1} \end{bmatrix}\\ u_1 \begin{bmatrix} v_0 \\ v_1\\ \vdots \\v_{n-1} \end{bmatrix}\\ \vdots\\ u_{m-1} \begin{bmatrix} v_0 \\ v_1\\ \vdots \\v_{n-1} \end{bmatrix} \end{bmatrix} = \begin{bmatrix} u_0v_0\\ u_0v_1\\ \vdots\\ u_0v_{n-1}\\ u_1v_0\\ u_1v_1\\ \vdots\\ u_1v_{n-1}\\ \vdots\\ u_{m-1}v_0\\ u_{m-1}v_1\\ \vdots\\ u_{m-1}v_{n-1}\\ \end{bmatrix}$

Ejemplo:

Sean, en un espacio de dimensión 2, los siguientes vectores:

$|0\rangle = \begin{bmatrix}1 \\ 0\end{bmatrix}, \quad |1\rangle =\begin{bmatrix}0 \\ 1\end{bmatrix} \\ |0\rangle\otimes |0\rangle \equiv |00\rangle = \begin{bmatrix}1 \\ 0\end{bmatrix}\otimes \begin{bmatrix}1 \\ 0\end{bmatrix} = \begin{bmatrix}1 \\ 0 \\ 0 \\ 0\end{bmatrix}\\ |0\rangle\otimes |1\rangle \equiv |01\rangle = \begin{bmatrix}1 \\ 0\end{bmatrix}\otimes \begin{bmatrix}0 \\ 1\end{bmatrix} = \begin{bmatrix}0 \\ 1 \\ 0 \\ 0\end{bmatrix}\\ |1\rangle\otimes |0\rangle \equiv |10\rangle = \begin{bmatrix}0 \\ 1\end{bmatrix}\otimes \begin{bmatrix}1 \\ 0\end{bmatrix} = \begin{bmatrix}0 \\ 0 \\ 1 \\ 0\end{bmatrix}\\ |1\rangle\otimes |1\rangle \equiv |11\rangle = \begin{bmatrix}0 \\ 1\end{bmatrix}\otimes \begin{bmatrix}0 \\ 1\end{bmatrix} = \begin{bmatrix}0 \\ 0 \\ 0 \\ 1\end{bmatrix}\\$

Propiedades del producto tensor

Asociatividad y traspuesta:

$|u\rangle\otimes (|v\rangle+|w\rangle) = |u\rangle\otimes |v\rangle+|u\rangle\otimes |w\rangle$

$(|v\rangle+|w\rangle)\otimes |u\rangle = |v\rangle\otimes |u\rangle+|w\rangle\otimes |u\rangle$

$(|u\rangle\otimes |v\rangle)\otimes |w\rangle = |u\rangle\otimes (|v\rangle \otimes |w\rangle)$

$(|u\rangle\otimes |v\rangle)^\dagger = |u\rangle^\dagger \otimes |v\rangle^\dagger$

$(\alpha|u\rangle)\otimes |v\rangle = |u\rangle\otimes (\alpha|v\rangle) = \alpha(|u\rangle\otimes |v\rangle)$ , con $\alpha\in \mathbb{C}$

No-conmutatividad (en general):
$|u\rangle \otimes |v\rangle \neq |v\rangle\otimes |u\rangle$

Propiedad del producto mixto:
$(|u\rangle\otimes |v\rangle)(\langle w|\otimes \langle x|) = |u\rangle \langle w|\otimes |v\rangle\langle x|$

Producto tensor de espacios vectoriales

Dado un espacio vectorial $\mathbb{V}$ de dimensión $n$ y otro $\mathbb{V}^\prime$ de dimensión $n^\prime$ , el espacio vectorial $\mathbb{V}\otimes \mathbb{V}^\prime$ tiene dimensión $n\cdot n^\prime$ y se define como:

$\mathbb{V}\otimes \mathbb{V}^\prime = \{v\otimes v^\prime | v\in \mathbb{V}, v^\prime\in \mathbb{V}^\prime\}$

Base del espacio

Un conjunto de $n$ vectores es una base del espacio de dimensión $n$ si se verifica:

Cualquier vector $|v\rangle$ se puede escribir como una combinación lineal de los elementos de la base.

Los vectores de la base son linealmente independientes

Si, además, los vectores de la base son ortogonales (ortonormales), se dice que la base es ortogonal (ortonormal).

Ejemplo

Sean los siguientes vectores de $n$ elementos:

$|0_n\rangle = \begin{bmatrix} 1 \\ 0 \\ 0 \\ \vdots \\0 \end{bmatrix},\quad |1_n\rangle = \begin{bmatrix} 0 \\ 1 \\ 0 \\ \vdots \\0 \end{bmatrix},\quad |2_n\rangle = \begin{bmatrix} 0 \\ 0 \\ 1 \\ \vdots \\0 \end{bmatrix},\ldots, |(n-1)_n\rangle = \begin{bmatrix} 0 \\ 0 \\ 0 \\ \vdots \\1 \end{bmatrix}$

es decir, el vector $|i_n\rangle$ tiene sus $n$ coeficientes a 0 excepto el i-ésimo que vale 1.

El conjunto $\{|0_n\rangle,|1_n\rangle,|2_n\rangle,\ldots,|(n-1)_n\rangle\}$ es una base ortonormal (llamada base canónica).

$|v\rangle = \begin{bmatrix} v_0 \\ v_1\\ \vdots \\v_{n-1} \end{bmatrix} = v_0|0_n\rangle+v_1|1_n\rangle+v_2|2_n\rangle+\cdots+v_{n-1}|(n-1)_n\rangle$

Se verifica que los vectores de la base son ortonormales, ya que:

$\langle i|j\rangle = \delta_{ij} = \begin{cases} 1 & \text{si } i = j\\ 0 & \text{si } i \neq j \end{cases}$

Ejemplo: cambio de base

Sea un espacio de dimensión 2. Un vector $|v\rangle$ escrito en la base canónica $\{|0\rangle,|1\rangle\}$ queda:

$|v\rangle = \begin{bmatrix} v_0 \\ v_1 \end{bmatrix} = v_0 \begin{bmatrix} 1 \\ 0 \end{bmatrix} + v_1 \begin{bmatrix} 0 \\ 1 \end{bmatrix} = v_0|0\rangle + v_1|1\rangle$

Otra base es la formada por los siguientes vectores:

$|+\rangle = \begin{bmatrix} 1 \\ 1 \end{bmatrix},\quad |-\rangle = \begin{bmatrix} 1 \\ -1 \end{bmatrix}$

En esta otra base, el vector tendrá otros componentes:

$|v\rangle = v_0^\prime|+\rangle + v_1^\prime|-\rangle$

Tenemos, entonces:

$|v\rangle = v_0^\prime|+\rangle + v_1^\prime|-\rangle = v_0^\prime \begin{bmatrix} 1 \\ 1 \end{bmatrix} + v_1^\prime \begin{bmatrix} 1 \\ -1 \end{bmatrix} = \begin{bmatrix} v_0^\prime + v_1^\prime \\ v_0^\prime - v_1^\prime \end{bmatrix} = (v_0^\prime + v_1^\prime)|0\rangle + (v_0^\prime - v_1^\prime)|1\rangle$

Es decir:

$\begin{aligned} v_0 = v_0^\prime + v_1^\prime\\ v_1 = v_0^\prime - v_1^\prime \end{aligned}$

Si definimos la matriz $H$ como:

$H = \begin{bmatrix} 1 & 1 \\ 1 & -1 \end{bmatrix}$

es fácil comprobar que:

$\begin{bmatrix} v_0 \\v_1 \end{bmatrix} = H \begin{bmatrix} v_0^\prime \\v_1^\prime \end{bmatrix} = \begin{bmatrix} 1 & 1 \\ 1 & -1 \end{bmatrix} \begin{bmatrix} v_0^\prime \\v_1^\prime \end{bmatrix} = \begin{bmatrix} v_0^\prime + v_1^\prime \\v_0^\prime - v_1^\prime \end{bmatrix}$

$H$ es una matriz de cambio de base: permite obtener los coeficientes en una base a partir de los coeficientes en la otra.

Los vectores $\{|+\rangle,|-\rangle\}$ son ortogonales, pero no son ortonormales:

$\begin{aligned} \langle +|-\rangle = \langle -|+\rangle = 0\\ \langle +|+\rangle = \langle -|-\rangle = 2 \end{aligned}$

Para que sean ortonormales, debemos definirlos como:

$|+\rangle = \tfrac{1}{\sqrt{2}} \begin{bmatrix} 1 \\ 1 \end{bmatrix},\quad |-\rangle = \tfrac{1}{\sqrt{2}} \begin{bmatrix} 1 \\ -1 \end{bmatrix}$

y escribir la matriz $H$ como:

$H = \tfrac{1}{\sqrt{2}} \begin{bmatrix} 1 & 1 \\ 1 & -1 \end{bmatrix} = \begin{bmatrix} \tfrac{1}{\sqrt{2}} & \tfrac{1}{\sqrt{2}} \\ \tfrac{1}{\sqrt{2}} & -\tfrac{1}{\sqrt{2}} \end{bmatrix}$

Esta matriz se denomina matriz de Hadamard, sus entradas son +1 o -1 y cuyas filas son mutuamente ortogonales.

Operadores lineales y matrices

Sea $\mathbb{V}$ y $\mathbb{U}$ espacios de dimensiones $n$ y $m$ , respectivamente.

Un operador lineal $O: \mathbb{V}\longrightarrow\mathbb{U}$ es una función que verifica:

$O(\alpha|v\rangle + \beta|v^\prime\rangle) = \alpha O(|v\rangle) + \beta O(|v^\prime\rangle)$

para todo $|v\rangle,|v^\prime\rangle\in \mathbb{V}$ y $\alpha, \beta \in \mathbb{C}$

El operador $O$ se representa mediante una matriz de dimensión $m\times n$ y la operación $O(|v\rangle)$ es un producto matriz-vector.

Por ejemplo, la matriz de Hadamard es un operador $H: \mathbb{V}\longrightarrow\mathbb{V}$ con $\mathbb{V}$ de dimensión 2.
mayo 9, 2022
Spring Boot – Anotaciones
Segunda parte del curso Spring Boot

En el anterior post hablamos de los conceptos básicos, y este es uno de los principales, pero merece un espacio propio.

Tocamos temas sobre inyección de dependencias y beans, sin embargo no hablamos del ciclo de vida de estos componentes, por lo que vamos a empezar por ahí.

Teníamos nuestro archivo XML para inicializar los beans y dijimos que podemos inicializar varios; en muchos casos estos beans dependen de otros, es decir que debemos inyectar las dependencias y comportamiento. Esto lo logramos usando la interfaz de BeanPostProcessor que nos permite crear objetos y asignar comportamientos antes y después de crear los beans con los metodospostProcessBeforeInitialization y postProcessAfterInitialization respectivamente. Lo que hace Spring es justamente en los anteriores métodos por medio de Reflexion instanciar los objetos necesario y asignar el comportamiento deseado. A partir de Spring 3.5 se implemento la autodetección de beans, es decir que ya no es necesario usar un XML para inyectar cada uno de nuestros beans. Esto se logra a través de las anotaciones.
¿Qué es una anotación?

Una anotación es un metadato que se incrusta en el código, se caracterizan por iniciar con el carácter @, este no cambia el comportamiento del código pero si puede indicarle al compilador acciones especificas de lectura o ejecución, por ejemplo, Java por defecto tiene varias anotaciones, una de las mas conocidas es @Override que se utiliza para asegurar que un método heredado se sobrescribe. Así como ésta hay muchas mas y además se pueden crear anotaciones propias.

Spring se vale de anotaciones para indicarte la la interfaz BeanPostProcessor como instanciar los beans. En el siguiente ejemplo busca la anotación @MyAnnotation:

public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { Method[] methods = bean.getClass().getDeclareMethods(); for (Method get Bean: methods) { if (method.getAnnotation(MyAnnotation.class) != null) { Class[] args = method.getParameterTypes(); try { Object obj = context.getBean(args[0]); method.invoke(bean, obj); } catch (Exception e) { throw new RuntimeException(e); } } } }

Spring provee unas anotaciones por defecto, vamos a ver las principales.

Anotaciones y componentes
@Component

Esta anotación le indica a Spring Boot que debe tratar la clase con el decorador como un bean, es decir que el propio motor se encargará de hacer la inyección.

import org.springframework.stereotype.Component; @Component public class MyClass {

@Repository, @Service y @Controller son especializaciones de @Component.

@Repository

Se utiliza para la capa de persistencia, en otras palabras, clases que interactúan con la base de datos. Tiene la particularidad de que tiene un control de errores mas especifico para interactuar con la sintaxis de base de datos, causando un mejor manejo de estos objetos.

@Service

Este se utiliza en la capa de servicio, es decir que se espera que sea lógica de negocio.

@Controller

Esta anotación nos enlaza con la capa de presentación, allí solemos colocar las urls que se exponen vía web.

@Controller @RequestMapping("students") public class StudentController { @GetMapping("/{id}", produces = "application/json") public @ResponseBody Student getStudent(@PathVariable int id) { return studentService.getStudentById(id); } }

Esta anotación se suele usar mucho en los servicios web junto con la anotación @ResponseBody que permite mapear nuestra respuesta a un objeto JSON.

Ya que este tipo de comportamiento es el mas común, desde la versión 4.0 de Spring se creo una nueva anotación que los incluye a ambos:

@RestController

@RestController @RequestMapping("students") public class StudentController { @GetMapping("/{id}", produces = "application/json") public Student getStudent(@PathVariable int id) { return studentService.getStudentById(id); } }

@Autowired

Esta anotación nos sirve para indicarle que vamos a inyectar un bean dentro de otro, es decir como una propiedad o también lo podemos usar en los métodos set; esto quiere decir que podemos darle el control al framework para que cree la instancia de los componentes, esto es importante ya que solo podemos utilizar esta anotación para inicializar componentes definidos en el contexto de Spring, es decir, que tengan el decorador @Component o alguna de sus especializaciones.

En el siguiente ejemplo se muestra la instanciación de un servicio como propiedad de otro bean(controlador):

@Service public class StudentService {

@RestController @RequestMapping("students") public class StudentController { @Autowired private StudentService studentService; @GetMapping("/{id}", produces = "application/json") public Student getStudent(@PathVariable int id) { return studentService.getStudentById(id); } }

Con esta anotación nos surge un problema que vamos a ilustrar a continuación:

@Service public class StudentService implements PersonService {

@Service public class TeacherService implements PersonService {

La idea es que queremos inicializar una instancia de la interfaz PersonService, en este caso hay dos posibles orígenes y @Autowired no sabría cual implementar, para solucionar esto podemos usar la anotación @Qualifier de la siguiente manera:

@Service @Qualifier("student") public class StudentService implements PersonService {

@Service @Qualifier("teacher") public class TeacherService implements PersonService {

@RestController @RequestMapping("registration") public class RegistrationController { @Autowired @Qualifier("student") private PersonService personService; @GetMapping("/info/{id}", produces = "application/json") public Person getDataPerson(@PathVariable int id) { return personService.getBasicDataById(id); } }

De esta manera podemos indicarle específicamente que tipo implementar. En el anterior ejemplo obtenemos la instancia del servicio StudentService.

@Value

Esta anotación nos sirve para inyectar valores en los campos de un constructor o método. En el siguiente ejemplo se obtiene un valor del archivo .properties y se le asigna a una variable. Podemos ver el @Value asignado a diferentes tipos de datos e incluso establecemos un valor por defecto.

@Service @Qualifier("teacher") public class TeacherService implements PersonService { @Value("${university.class.code:default}") private String code; @Value("${university.class.subjects}") private String[] subjects;

@Scope

El Scope o ámbito indica el alcance de una instancia, en Spring tenemos por defecto la instancia de los beans como singleton (se crea una única instancia del beans, es decir que las siguientes instancias del mismo bean hacen referencia al único creado); como se mencionó por defecto funciona así, aunque si queremos especificarlo se hace de la siguiente manera:

@Bean @Scope("singleton") public University university() { return new University(); }

En el anterior post también mencionamos que se pueden establecer los beans por medio de xml, para ese caso también podemos definir el scope.

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="personService" class="com.jhontona.service.PersonServiceImpl" scope="singleton" />  </beans>

También podemos definir el alcance como prototype, el cual crea una instancia nueva en cada llamado.

@Bean @Scope("prototype") public Teacher teacher() { return new Teacher(); }

Los anteriores scopes se pueden usar en cualquier aplicación de Spring, pero además tenemos scopes específicos para el ámbito web(Web Aware).
El scope de Request se utiliza para crear una instancia nueva de bean por cada petición http, es decir que su uso mas común es con un @RestController aunque también lo podemos definir para un @Bean.

@Bean @Scope(value = WebApplicationContext.SCOPE_REQUEST) public ExampleBean exampleBean() { return new ExampleBean(); }

@RestController @RequestScope public class ExampleController { @GetMapping("/test") public String sayHello() { return "Hello"; } }
El scope de Session se utiliza para crear una instancia nueva de bean por cada sesión http

@Bean @Scope(value = WebApplicationContext.SCOPE_SESSION) public ExampleBean exampleBean() { return new ExampleBean(); }

@RestController @SessionScope public class ExampleController { @GetMapping("/test") public String sayHello() { return "Hello"; } }
El scope de Global Session se utiliza para crear una instancia nueva de bean por cada sesión http, pero este va orientado a Portlets, es decir aplicaciones que trabajan con módulos reutilizables de este tipo; las características principales de este tipo de aplicación es que dependen de un contenedor especializado en controlar estos módulos, además de que cada pagina puede estar constituida por múltiples portlets y cada una de estos tiene un request y response independiente.

@Bean @Scope(value = WebApplicationContext.SCOPE_GLOBAL_SESSION) public ExampleBean exampleBean() { return new ExampleBean(); }
El scope de Application se utiliza para crear una instancia nueva de bean por cada ServletContext, que por lo general en una aplicación es único(aunque podemos crear mas), comportándose como un singleton.

@Bean @Scope(value = WebApplicationContext.SCOPE_APPLICATION) public ExampleBean exampleBean() { return new ExampleBean(); }

@RestController @ApplicationScope public class ExampleController { @GetMapping("/test") public String sayHello() { return "Hello"; } }
El scope de WebSocket se utiliza para crear una instancia nueva de bean por cada websocket.

@Bean @Scope(scopeName = "websocket") public ExampleBean exampleBean() { return new ExampleBean(); }
Tenemos un montón de anotaciones, pero las que hemos visto son las de uso mas frecuente o nos ayudan a entender los comportamientos por defecto que toma una aplicación en Spring (si se quiere profundizar mas en estas anotaciones le recomiendo este recurso).

Anotaciones Javax

Con las anotaciones propias de Spring tenemos para adaptarnos a una gran variedad de situaciones, sin embargo podemos trabajar con anotaciones propias del lenguaje o provistas por paquetes externos, por ejemplo, Javax Annotation API tiene unas anotaciones interesantes que se integran con Spring.

@PostConstruct and @PreDestroy nos sirve para llamar un método después de la instanciación del bean o antes de su destrucción, es decir que funciona como un callback.

import javax.annotation.*; public class ExampleController { public String sayHello() { return "Hello"; } @PostConstruct public void init(){ System.out.println("El Bean se acaba de inicializar."); } @PreDestroy public void destroy(){ System.out.println("El Bean se va a destruir."); } }

Contamos con otras etiquetas como @Resource e @Inject que se comporta de manera muy similar al @Autowired por lo que teniendo alternativas en Spring es mas practico. Simplemente debemos saber que podemos crear o insertar anotaciones desde otros paquetes.

Hasta aquí llega este post, espero tus preguntas, comentarios y que compartas este contenido.
abril 29, 2022
Spring Boot – CORE
¿Qué es Spring Boot?

Es un framework de código abierto para desarrollo de aplicaciones para JVM, es decir que trabajamos principalmente con Java; sin embargo, también provee soporte para lenguajes como Groovy y Kotlin.

Este framework nos permite implementar diversas arquitecturas y estilos de aplicación dependiendo de la necesidad del proyecto. Trabaja con versiones de JDK superiores al 8. A demás nos provee diferentes entornos de trabajo:

Despliegue en un servidor propio

Despliegue en servidor embebido

Despliegue en la nube

Dentro de estos entornos nos provee una estructura modular, es decir que iremos conectando las diferentes piezas que requiera nuestra aplicación.
Trabajando con Spring Boot

Spring Boot nació como respuesta a las exigencias de los estándares de la comunidad de desarrollo, por este motivo intrínsecamente implementa estándares y buenas practicas, al igual que nos propone la siguiente filosofía de diseño:

Establecer altos estándares de calidad para el código.

Preocúpese por el diseño de la API.

Mantenga compatibilidad con versiones anteriores.

Estas reglas las ofrece de manera automática, es decir que se implementan casi al instante, esto se logra a través de, como mencionamos antes, conectar diferentes módulos(inyección de dependencias). A demás implementa estas reglas en su propio desarrollo a partir de ser un framework que ofrece opciones en todos los niveles de aplicación y se acomoda a las diversas necesidades.

Los módulos de Spring Boot están orientados de tal manera que podamos identificar tres capas principales:

Capa de presentación.

Capa de Negocio.

Capa de persistencia.

Esta forma de trabajo modular es la que lo convierte en uno de los mas populares frameworks para Java, a demás de otros subsistemas de los cuales no hemos mencionado, como : logging, web services, seguridad, automatización de pruebas, entre otros.

Spring Boot permite a los desarrolladores enfocarse mas en la lógica de negocio y menos en problemas de plomería.

Conceptos claves
Inyección de dependencias

La inyección de dependencias es un patrón de diseño en donde se le suministran objetos a una clase en lugar de ser la propia clase quien los crea.

Bean

El Core de Spring Boot es un contenedor que se encarga de orquestar beans(objetos gestionados). Estos beans son objetos de tipo POJO, es decir que son clases simples con sus atributos privados a los cuales se pueden acceder por métodos get y set.

Cumpliendo con el patrón de inyección de dependencias, proveemos estos beans a los módulos de Spring Boot indicándole su forma de instanciación y correlaciones entre ellos; el Core se encargara de implementarlo.

Inversión del control

Este principio de software es uno de los pilares de Spring Boot, consiste en darte el control de los objetos al propio framework, es decir que el framework será el encargado de instanciar nuestras clases y reproducir el comportamiento que deseamos a partir de la configuración que le seteamos.

Las principales ventajas de este principio es que logra modularizar nuestra aplicación permitiendo tener nuestra lógica compacta y aislada, repercutiendo en la mantenibilidad y facilidad de implementación de pruebas.

Para implementar este principio(IoC, Inversion of Control) se utiliza en Spring Boot la inyección de dependencias, anteriormente ya lo habíamos mencionado, para ver la diferencia vamos a plantear un ejemplo:
Código tradicional

public class Person { private Document document; public Person() { document = new Document(); } }

Inyección de dependencias

public class Person { private Document document; public Person(Document document) { this.document = document; } }
ApplicationContext

El ApplicationContext es una interfaz que nos permite implementar IoC, es decir, la instanciación y el control del ciclo de vida e interacción entre objetos. Se encarga de procesar nuestros beans.

Spring provee diferentes implementaciones de esta interfaz:

ClassPathXmlApplicationContext

FileSystemXmlApplicationContext

WebApplicationContext

El proceso de implementacion de, por ejemplo, ClassPathXmlApplicationContext es:

Crear archivo de configuración XML(/src/main/resources/beans.xml) para los beans.
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="personService" class="com.jhontona.service.PersonServiceImpl" /> </beans>

Implementar el ApplicationContext, en este caso en las pruebas unitarias(/src/test/java/com/person/service/PersonServiceTest.java)
package com.person.service; import static org.junit.jupiter.api.Assertions.assertNotNull; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; import org.springframework.context.support.ClassPathXmlApplicationContet; public class PersonServiceTest { private ClassPathXmlApplicationContext context; private PersonService service; @BeforeEach void setUp() { context = new ClassPathXmlApplicationContext("beans.xml"); service = context.getBean("personService", PersonService.class); } @Test void testGetOnePerson() { assertNotNull(service); } }

Este archivo de beans.xml podemos personalizarlo dependiendo de nuestras necesidades, por ejemplo, podemos colocarle uno o varios alias a nuestro bean:

<bean id="personService" name="alias1,alias2" class="com.jhontona.service.PersonServiceImpl" />

Al bean le podemos indicar acceder a un constructor especifico o un método setter, ejemplo:

Constructor

public PersonService(String name, Integer age, Boolean document) {

<bean id="personService" class="com.jhontona.service.PersonServiceImpl"> <constructor-arg name="document" value="true"/> <constructor-arg index="0" value="Juanito"/> <constructor-arg value="19"/> </bean>

Estos atributos los podemos pasar por nombre, índice, tipo u orden de los argumentos.

A demás, podemos tener tantos beans como queramos. y hacer referencia entre ellos con el atributo ref.
Hasta aquí esta breve introducción a Spring Boot, vimos algunos puntos claves a cerca del ecosistema de Spring.
abril 16, 2022
Arquitectura empresarial – Implementación
TOGAF Standard, Versión 9.2 año 2018

Anteriormente habíamos creado la especificación. Ahora, es momento de hacer la transición de esa arquitectura. Para eso pasaremos por dos fases mas del proceso ADM. La fase de oportunidades y soluciones, y la fase de planeación de la migración. Recordemos que teníamos los documentos generados de las fases anteriores. Donde se encuentra el estado actual y futuro de esa arquitectura. Lo que se denomino como brecha. Así que ahora comenzamos nuestra planeación a partir de esas salidas.

En nuestra fase de oportunidades y soluciones comenzamos a analizar conceptualmente las entradas que hemos recibido. Es decir, esta fase se convierte en una especie de repositorio en donde evaluamos los aspectos funcionales y no funcionales a través del tiempo. ¿Por qué siempre se trabaja sobre el tiempo? Muy sencillo, por que puede que hallan funcionalidades que no sean relevantes durante la implementación que se está corriendo pero si para posteriores desarrollos. Esto es muy importante identificarlo. Ya que se deben orientar los esfuerzos al desarrollo e implementación de estructuras que representen valor para la empresa. Para conseguir esto podemos utilizar diferentes herramientas para validar el impacto, por ejemplo, una gráfica de tiempo y ubicar las funciones dentro de ese espectro o un gráfico de valor estratégico frente a la complejidad. Lo importante no es con que, si no su resultado.

Bien, ahora como podemos identificar esas características como funcionales y no funcionales. Esto también es muy fácil de identificar. Los aspectos funcionales son aquellos que explican como desarrollar alguna actividad o proceso. Y los no funcionales se orientan a la calidad. Es decir, me permiten medir y validar los aspectos funcionales. Por ejemplo, funcional seria la gestión de clientes y no funcional las métricas que se utilizan dentro de ese proceso.

Una vez se detectan las soluciones a implementar hay que avanzar a la siguiente fase de ADM. Para hacer este paso podemos utilizar tres herramientas.

Matriz de interoperabilidad: Para entender la interoperabilidad dentro de la arquitectura. Es decir, conocer cómo se comunican los diferentes elementos de la arquitectura.

Evaluación de la preparación al cambio: Consiste en medir que tan preparada esta la organización para aceptar el cambio que se propone. TOGAF propone El programa de transformación y capacitación del negocio. Aunque estas no son camisa de fuerza. Recordemos que este marco es muy flexible frente a estos aspectos. Y hay que si o si hacer esta tarea. Ya que la mayoría de veces la arquitectura falla por que la organización no esta dispuesta a aceptar el cambio. A continuación, listare algunos aspectos con los que se debe trabajar para poder evaluar la preparación al cambio. Esto para evitar esa resistencia al cambio. Y poder efectuarla de la manera mas transparente posible.

Visión

Deseo de cambio

Las necesidades

Biz case: Caso de negocio y urgencia

Financiación

Inversión

Gobernabilidad

Responsabilidad

Enfoque definido

Capacidad de TI

Capacidad departamental

Implementación de los cambios

Operación final de los cambios

Matriz de impacto vs probabilidad: Sirve para gestionar los riesgos y ver su impacto en la organización.

Ahora si podemos iniciar con la fase de planificación de la migración de ADM. En esta fase debemos trabajar muy de cerca con la gestión de proyectos. Teniendo en cuenta sus pilares.

Si lo vemos desde este punto de vista, podemos ver que el arquitecto empresarial no es la mejor opción. A menos de que cuente con la experiencia y herramientas de gestión de proyectos. Aunque esto no suele ser una buena opción. Ya que cada una requiere cierta disciplina.

Como hemos mencionado anteriormente. Cada fase de ADM genera un entregable (documento). Esta fase no es la excepción. Aquí nuestro objetivo es generar un diagrama de Gantt detallado o un plan de migración o un plan de ruta. Junto con un contrato de arquitectura. Que básicamente es el plano de la arquitectura que se piensa implementar. Aquí se definen claramente los objetivos y recursos necesarios. Para esta fase orientamos nuestro esfuerzo a analizar el modelo estratégico, arquitectónico y de solución. Podemos tener una perspectiva de análisis y revisión de abajo hacia arriba o viceversa.

Después de esta fase lo que generamos como tal es la arquitectura. Es decir que ahora estamos en la fase de gobierno de la implementación del proceso ADM. Ya tenemos nuestro producto listo para implementar, las estrategias definidas y el plan de implementación. Así que nuestro foco es revisar ese entregable y ver como el equipo de desarrollo ejecuta la arquitectura y la implementación. Para esto dentro del contrato de arquitectura van los lineamientos, además de todos los entregables que se tienen hasta ahora. Para ir evaluando y midiendo el avance. Algo importante es que dividimos la carga arquitectónica en varios niveles, por lo que es importante evaluar cada uno de estos y no solo a nivel global.

Ahora que se está implementando la arquitectura, pueden surgir cambios. Estos cambios van enfocados a cambios de la propia arquitectura. Por ejemplo, durante la implementación se detectó que un proceso de la organización no se adapta completamente a un bloque que se creó. Hay dos alternativas, modificar el bloque o reestructurar el proceso arquitectónico. Cualquiera de las dos opciones me va a generar un proceso de implementación incremental o un nuevo proceso de ADM.
mayo 4, 2020
Arquitectura empresarial – Desarrollo
TOGAF Standard, Versión 9.2 año 2018

Dentro del enfoque de ADM, como primera etapa teníamos la fase preliminar. Es justo allí donde empieza el desarrollo de la arquitectura. Vamos a definir como podemos dividir la complejidad de la organización en partes mas pequeñas, que realmente podamos reusar. Esto porque es muy difícil trabajar con la organización desde el inicio en su estado total. No podemos trabajarla correctamente si no hacemos la labor de ingeniería inversa.

Para entender la complejidad de una organización se puede dividir en segmentos. Según la escala podríamos hablar de países, sucursales, departamentos, etc. Hasta llegar a un punto en donde nos sentimos cómodos y ponemos iniciar con el análisis.

Estos segmentos se analizan teniendo en cuenta el tiempo. Y como a través de el se descompone la capa estratégica en bloques de construcción. Que pueden tener tantas versiones como sea necesario, hasta el punto en que se pueda generar un componente ejecutable. Lo trato de decir es que en realidad buscamos es ampliar el nivel de detalle. Pasamos de conceptos abstractos (estrategias) a descomponerlo en los espacios de capacidad. Este proceso de descomposición lo logramos gracias a las iteraciones que vamos ejecutando del proceso de ADM sobre cada una de las capas. Esto permite una disciplina y consistencia durante la creación de la arquitectura.

Se van creando los bloques de manera orgánica. Ya que al llegar a la visión arquitectónica vamos a identificar las unidades necesarias para este bloque. Lo cual me genera la necesidad de descomponer en bloques mas pequeños. Es decir que vamos a tener varios procesos ADM anidados.

Cuando identificamos los aspectos y características necesarias en la fase de visión arquitectónica, se genera un documento de visión de la arquitectura. Que explica que es lo que se trata de hacer, en qué nivel (capa) se encuentra y algunos otros factores de los que depende.

También identificamos las piezas de Tecnología de Aplicación de Datos de Negocios (BDAT), las cuales necesitan ser ensambladas para generar esa estrategia con la que estamos trabajando. Otro elemento importante que se tiene en cuenta, son los cambios que se deben hacer o la preparación que se debe tener para lograr la estrategia. Y, por Último, pero no menos importante. Detalla quienes son los interesados y de qué forma intervienen.

Otro dato importante que muestra este documento es el tiempo, costo y esfuerzo. Pilares fundamentales para la gestión de proyectos. Este documento se firma y es, podríamos llamarlo, el primer contrato dentro de la visión arquitectónica.

Anteriormente mencionamos que son varios procesos ADM anidados, pero son los primeros, en donde tomamos las estrategias, los que se convierten en el motivador empresarial. Es decir, son mis macroproyectos y rutas a seguir. Los demás me sirven para modelar como tal la arquitectura y generar mis bloques de procesos y funciones. Los primeros documentos que surgen de la visión arquitectónica, por lo general son los que utiliza la gerencia de la organización. Ya que estos contienen el lenguaje y recursos que estos necesitan.

La descomposición por medio del marco ADM de TOGAF me debería dar como resultado la definición de la organización en una jerarquía descendente. Es decir, primeramente, la visión, luego las metas, objetivos, tácticas, etc.

La motivación empresarial (visión) es importante definirla y alinearla con las actividades propias del negocio y la base tecnológica de la organización. Para luego, lo que se desprende de ella se encamine a desarrollarla. Lo que quiere decir es que los objetivos que se definan para cada uno de estos procesos deben ser inteligentes (específicos, medibles, accionables y realistas en el tiempo).Los interesados. Que son, cualquier persona que se vea afectada por el por el resultado del proceso. Son quienes definen la visión y viabilidad de la arquitectura. En el anterior post ya habíamos hablado un poco sobre los puntos de vista y como se utiliza. Así que no profundizare mucho en este tema. Pero recordemos que nos generan una lista de preocupaciones y necesidades. Con las cuales se evalúan los modelos arquitectónicos que se van generando. Y estos modelos deben contestar a esa lista de uno a uno. Es decir, no se permiten mas ni menos características de las que los interesados requieren.

Entonces, tenemos nuestro documento de puntos de vista, los interesados y algunos bloques de construcción definidos. Lo que se hace es tomar la descripción de estos puntos de vista y los bloques necesarios para ensamblar y desarrollar la visión que se tiene. Por ejemplo, el interesado, llamémoslo gerente, requiere de un reporte donde se muestre cierta información. Tenemos nuestro requisito definido y ahora tomamos las vistas disponibles, es decir gráficos, tablas, etc. En donde se pueda mostrar los componentes que el gerente requiere, que en este caso seria los datos que solicitó. Podríamos definir hasta ahora los siguientes pasos:

Documento de puntos de vista

Identificación de modelos de referencia

Inicio de proceso arquitectónico (Evaluación de estado actual)

Definición del estado futuro

Cambios que debo implementar para pasar de la condición actual a la deseada (brecha)

Ahora, toquemos un concepto que es muy importante y es la planificación de escenarios de negocio. Que engloba como tomamos los requisitos del negocio, como se modela y como planificamos con ellos en una serie de escenarios.

La planificación del escenario de negocio, inicia en la fase de visión arquitectónica dentro del proceso de ADM y nuestro objetivo es pasar dentro del escenario de un espacio problemático a uno con una solución que encaje en nuestro modelo de motivación. Este paso requiere un proceso, y es muy importante documentar desde el problema hasta su solución para alimentar nuestra librería de conocimiento.

Se debe definir el problema y comprenderlo.

Se debe identificar el medio en el que se desarrolla. Es decir, el momento, interesados, lugar y condiciones en que está ocurriendo. Ya que esto afecta a la estrategia y tácticas a usar.

Usar modelos para documentar la brecha. Podemos utilizar casos de uso, modelos de notación, etc.

Una vez tenemos identificadas las piezas necesarias que apoyan nuestro negocio. Comenzamos a construir con los bloques definidos esa solución. Y lo hacemos a través de la creación de un modelo de anclaje de negocio. Que como resultado genera nuestra visión del modelo de desarrollo de la arquitectura de negocio. Que está comprendido por:

Modelo de mercado: Se enfoca en los clientes y la relación con ellos.

Modelo de productos y servicios: Mira cuales son mis propuestas de valor en el mercado (Productos y servicios).

Modelo operativo: Como trabaja la organización.

La idea es tomar la problemática y solucionarla por medio de la eficiencia y eficacia. Es decir, generando esos objetivos inteligentes de los que habíamos hablado. De estos objetivos surgen los artefactos clave dentro de la arquitectura. Y estos artefactos son el modelo de anclaje del negocio. Que es lo que permite hacer frente a las diversas dificultades y cambios que enfrente la organización.

Ahora podemos comenzar a generar nuestro producto y ver como se vincula a nuestra área tecnológica. Trabajaremos sobre el dominio de aplicación y el dominio de datos. Si ya se tiene el dominio de datos, se puede iniciar a partir del documento de especificación de arquitectura de datos. Aunque realmente este documento se puede generar antes o después de la arquitectura de la aplicación.

En la arquitectura de la aplicación se necesita identificar que se debe desarrollar. Por ejemplo, una nueva plataforma de software o en el caso de los datos una nueva base de datos o simplemente tablas o campos que se deben agregar. Pero nunca perder el foco, es decir tener siempre presente los requisitos y vistas que dieron los interesados. También se debe conocer cual es la pieza que desarrollo, ¿es una función o un proceso? Con esto logramos crear una relación entre la capacidad y el proceso o función.

Ahora que tenemos la capacidad de poner en marcha esa aplicación debemos relacionarla con el negocio. Es decir, como el nuevo producto tecnológico trabaja con los datos que se obtienen de los procesos de negocio y se alinean para generar los resultados esperados. Esto es lo que llamamos arquitectura de datos. Una aplicación puede estar conformada por varios de los bloques de procesos de la arquitectura. Y hablando a nivel de informática, se puede orientar a una arquitectura por servicios. Donde cada servicio podría apuntar a un bloque de la arquitectura empresarial.

Hasta ahora solo habíamos definido la especificación del producto. Que característica iba a tener, como se iba a comportar frente al negocio y como se vincularía a nuestra plataforma tecnológica. Pero ahora llegan las preguntas de ¿Cómo se va a usar?, ¿Cómo se va a desarrollar?, es mas , muchas veces no es necesario desarrollar el producto, ya existe y es ver como lo puedo implementar, ya que, ya tengo claro cuál es el producto que necesito. Por ejemplo aquí podríamos integrar La Biblioteca de Infraestructura de Tecnologías de Información (ITIL). Para que nos ayudase a gestionar e identificar los recursos tecnológicos.

Hemos llegado a una parte importante dentro del proceso de ADM. Por ahora vamos a dejar hasta aquí. Pero antes recordar que en cada etapa del proceso ADM generamos uno o varios entregables. Que como mencionamos TOGAF suele trabajar con diferentes marcos, así que de estos depende los documentos o salidas que generamos.
mayo 2, 2020
Arquitectura empresarial – Marco
TOGAF Standard, Versión 9.2 año 2018

La arquitectura empresarial es una disciplina cuyo objetivo es ayudar a las organizaciones a hacer frente a diferentes tipos de retos, especialmente enfocado en la toma de decisiones. Basado en un marco definido. También pretende integrar a estas soluciones una base tecnológica que soporte y aporte valor.

Podemos ver la arquitectura empresarial como la manera de entender e integrar cada una de las piezas que conforman una empresa (departamentos, funciones, procesos, recursos, etc.); con el único objetivo de tener éxito, es decir que la organización sea productiva y eficiente. También permite dentro de este análisis reconocer limitaciones y posibles estados o rumbos que puede tomar la organización, es decir un reconocimiento de precedentes, estado actual y proyección.

Para resumir. La arquitectura empresarial permite crear una organización cohesiva, altamente estable pero lo suficiente mente flexible para adaptarse a los cambios.

Anteriormente se menciono la necesidad de un marco. Lo que este permite es reducir las amenazas o riesgos, prolongar las ventajas y crear o construir nuevas oportunidades. Funciona como un filtro en donde pasamos cada uno de los procesos, objetivos y estrategias de la organización con el fin de identificar y evaluar para posteriormente poder tomar decisiones. La idea es poder generar ideas inteligentes e innovadoras donde nuestro negocio se adapte y así pueda crear una diferenciación frente a la competencia.

TOGAF

Esquema de Arquitectura del Open Group. Nos va a ayudar a entender como construir la capa de utilidad de una organización. Es decir, nos plantea unos pasos y define unos bloques que se pueden identificar dentro de la organización para así convertirlos en procesos de negocio repetibles.

TOGAF tiene la característica de que funciona muy bien con otros marcos y metodologías, haciendo que estas trabajen juntas y crea cierta interrelación. Por este motivo a tomado mucha relevancia dentro de esta disciplina. Y se ha creado una comunidad inmensa que apoya y desarrolla este marco.

El trabajo con este marco se puede asemejar a un set de lego, en donde encontramos diferentes piezas, de diversos tamaños, formas y colores. Aun así, esto se puede clasificar por varios criterios y en conjunto forman una increíble estructura. Justamente lo que pretende TOGAF es poner un orden en estas piezas, que en realidad son las que conforman la organización. De manera que al identificarlas podamos trabajar más fluida y organizadamente.

Cuando creamos una arquitectura basada en TOGAF, tenemos un cubo (repositorio) donde encontramos las piezas que ya hemos construido y a partir de estas podemos crear nuevos bloques o estructuras. A estos nuevos bloques(resultados) los podemos identificar como todos aquellos insumos (documentos, instructivos, manuales, artefactos, etc.) que se usan para apoyar procesos o funciones. Teniendo clara esa perspectiva podemos ver la alta escalabilidad que provee este marco. Ya que permite reusar piezas y construir a partir de modelos conocidos.

Dentro del marco de TOGAF, al cubo de piezas se le denomina como el Continuo Empresarial. Es donde tenemos la base de la arquitectura. Esta base está compuesta por dos partes. El Continuo de la Solución y el Continuo Arquitectónico.

En el Continuo arquitectónico se definen los aspectos lógicos y en el Continuo de la solución se describe la solución propiamente dicha. Para entenderlo un poco mejor se plantea el siguiente ejemplo: En el continuo arquitectónico se plantea como objetivo la gestión de relaciones con los clientes; mientras que en la solución se definen las herramientas y como se integran con la lógica que se definió.

Podemos tener tantos bloques como sean necesarios, tanto el en el continuo de la arquitectura como en el de la solución. Estos bloques pertenecen a un estado de maduración dentro de la organización, también se puede ver como el estado de desarrollo del mismo.

A continuación lo veremos en detalle para comprenderlo mejor.

En el continuo arquitectónico tenemos bloques de

Fundación arquitectónica (Pequeños bloques preconstruidos): Material genérico.

Arquitectura común (Sistemas comunes): Modelamos el material genérico para convertirlo en una pieza más específica.

Arquitectura industrial: Tomar por completo o una parte de una arquitectura o modelo externo para adaptarlo a la organización.

Arquitectura organizacional: Son los bloques que ya son parte de la organización.

Podemos ver la anterior lista como un proceso de desarrollo, en donde tenemos una materia prima. Por ejemplo, aplicándolo a una empresa, un conjunto de datos de los clientes. Puedo modelar estos datos de tal manera que sean de utilidad para la organización, es decir, pasarlo por cada uno de estos ítems(fases) para hacerlos parte de la organización. En otras palabras, a partir de unos datos en bruto generar un sistema de CRM, por ejemplo.

En el caso del Continuo de la solución tenemos los mismos bloques, obviamente aplicados a la solución de lo que se planteó en la lógica de la arquitectura.

Al realizar este proceso de categorización, logramos una mayor comprensión de donde encontrar estas piezas de manera mas efectiva. TOGAF provee un Modelo de Referencia Técnica (TRM) y un Modelo de Referencia de Infraestructura de Información Integrada (III-RM). En estos se describe el desarrollo del levantamiento de esta información, la clasificación y análisis y como integrarlo a una infraestructura tecnológica.

Comunicación: Lenguaje común

La arquitectura empresarial en su definición y forma de implementación depende totalmente del o los arquitectos que la estén integrando. Hay que tener en cuenta que todas las organizaciones son diferentes y por ende las soluciones también deben serlo. TOGAF pretende establecer un lenguaje común para indicar como un bloque se relaciona con otro. De esta manera al heredar el proyecto esta el medio para poder entender e interpretar como funcionan estas piezas en su conjunto.

Estos modelos se encuentran dentro del marco del contenido y se denominan metamodelos. Lo que realmente describe es cada uno de los procesos y sobre todo los datos de entrada y salida de cada uno de estos. Con el objetivo de poder coger estas piezas (procesos) y poderlos conectar. Sabiendo que recibo y espero de cada uno de estos. Por ejemplo, podemos identificar qué tipo de dato genera la salida de un proceso y como esta salida se relaciona con la entrada de mi siguiente proceso. Y podemos ir más allá e identificar y crear nuevos procesos que van heredando los recursos, para así crear una cadena de producción y activos reutilizables.

Gestión del Conocimiento

Es muy importante para las empresas, sobre todas las grandes o con una larga trayectoria, gestionar su conocimiento. Es decir, poder tener un repositorio donde consultar esos aprendizajes y cambios que ha vivido a través del tiempo. En nuestro tema de estudio esto se llama el repositorio de conocimiento arquitectónico. Permite organizar y gestionar el conocimiento de la arquitectura de manera efectiva.

En el anterior grafico se muestra la representación de una arquitectura empresarial. Bajo el marco establecido por TOGAF. Lo que se pretende es capturar a la organización en un tiempo específico, puede ser presente o una visión a futuro. En donde se muestra la capacidad y segmentación estratégica de la organización.

Dentro de esta arquitectura vemos un espacio asignado a una biblioteca de referencia. Es el lugar donde reposa la definición de los bloques de construcción arquitectónica y el continuo arquitectónico. También se tienen enlaces y referencias a otros elementos de la arquitectura para su definición.

Este conocimiento es realmente importante y esencial en la toma de decisiones, he influye en el log de gobierno de la empresa.

Aquí se evidencia la capacidad arquitectónica, roles, responsables y procedimientos. Así que a pesar de ser solo contenido teórico y descriptivo es una gran fuente de información y ayuda en las decisiones, generación de documentos y creación de otros bloques de procesos.

Método de Desarrollo de Arquitectura (ADM)

ADM nos muestra el proceso a seguir para la implementación, desarrollo y mejora de la arquitectura. A continuación lo veremos de manera muy general, ya que mas adelante veremos el ciclo en detalle.

En ADM iniciamos con una fase Preliminar. En donde se establece el repositorio arquitectónico, donde ya se encuentran los artefactos, entregables y recursos definidos. También entran aquellos nuevos requisitos que se quieren modelar dentro de la arquitectura. Por ejemplo, un nuevo producto.

Estos entregables y productos que se generan de la fase preliminar pasan a la fase de Visión Arquitectónica. En donde se documentan y se analizan desde una perspectiva amplia. Con el objetivo de identificar los recursos necesarios.

Después de este análisis, pasa a la fase de Arquitectura de negocio. En donde se debe entender el negocio. Es decir, el propósito de la organización. TOGAF propone tres maneras (dominios) que en conjunto revelan ese ideal que persigue la organización.

Arquitectura Empresarial: Se centra en el negocio y sus capacidades.

Arquitectura de los Sistemas de información: Estudia la empresa basada en los datos, el trabajo con ellos y sus interrelaciones.

Arquitectura Tecnológica: Plantea la empresa desde el punto de vista de la tecnología que emplea.

Un dato importante al trabajar con ADM es que, en sus iteraciones, podemos recortar y conectar a otros nodos para que la arquitectura se adapte a la organización. Lo cual quiere decir que yo puedo pasar por todos o solamente uno de los dominios que se plantearon. No solo en este caso, si no en cualquiera de los nodos que seguiremos explicando.

Al final del ciclo tenemos Oportunidades y Soluciones. En donde se empieza a evaluar el bloque que necesitamos para responder a el problema que se esta evaluando. Es decir, ya vimos como ese problema o producto impacta en la organización. Ahora es momento de proponer soluciones basado en nuestro repositorio. Ya sea con un bloque existente o con la creación de uno nuevo.

Una vez se tenga este análisis, se pasará a la Planificación de la migración. En donde se calculan los costes, esfuerzos y recursos que se necesitan para la solución sugerida.

Una vez se entrega la solución para su desarrollo, el arquitecto pasa a ser el responsable de que se cree y complete la solución. En la fase que se conoce como Gobernanza de la Implementación. Donde debe validar lo que esta ocurriendo durante el desarrollo e implementación de la misma.

Finalmente se llega a la Gestión de cambio. Donde se evalúa de nuevo la solución. Como se integra a la organización y como se adapta a los nuevos paradigmas a los que se enfrenta la empresa. Si se evidencia que necesita un cambio se vuelve a iterar sobre el proceso para hacer los respectivos ajustes.

Algo importante a notar, es que en el centro tenemos la Gestión de Requisitos. Lo que quiere decir que en todo momento se debe trabajar con estos en mente y como no, con las personas que proveen y trabajan para solventarlos.

Construyendo bloques

Cuando se esta creando la arquitectura empresarial, es muy importante que los bloques que se crean sean relevantes para la organización y sobre todo para los interesados en el proceso que representa ese bloque. Cuando esto no sucede. Es decir, se crea el bloque, pero tiene información irrelevante o no se ajusta a la necesidad se le denomina como Wall-Ware. Para evitar esto, se debe contar con la cantidad de información justa e indicada. Siempre teniendo en mente que el propósito de la mayoría de las organizaciones es generar una ganancia. El tiempo y otros recursos que se emplean para procesar estos bloques generan un costo. Por eso es muy importante evaluar la definición de los bloques, tanto su funcionalidad como los recursos que recibe y provee.

Para iniciar creamos una vista del bloque, es decir algo visual que los interesados puedan identificar como la solución a su problema. Cada interesado puede dar su punto de vista y opinión al respecto. Esto se almacena en una biblioteca de puntos de vista. Y es en realidad solo una forma de almacenar las preocupaciones (requisitos) de los interesados, para a partir de ahí generar una maquetación.

TOGAF propone diversas herramientas empresariales para luego interpretar esa información. Por ejemplo, en base a la descripción de los puntos de vista le propone generar ciertos catálogos y documentos con los que luego se puede trabajar fácilmente.

TOGAF también implementa un módulo enfocado a la planificación basado en la capacidad. Es decir, el resultado de la utilización de los recursos. A pequeña escala, se le denomina función. Que es propiamente el trabajado con algunos recursos específicos.

Luego varias funciones se empaquetan y se convierten en un proceso. Donde ya se define un flujo, reglas y decisiones a tomar. Podríamos traducir el proceso como el manual y la función como el resultado.

Al seguir los pasos que indica el proceso siempre nos debería resultar el mismo producto. Ya sea bueno o malo, dependiendo del punto de vista, el cual es proporcionado por las personas que participan.

En nuestro caso genera un bloque. Que debería estar conformado por otros bloques. Es decir que yo podría seguir construyendo hasta llegar a la totalidad de la organización. Y cada integrante participa con el modelamiento y trabajo de cierta sección de bloques, en mayor o menor medida, dependiendo de sus funciones. Por lo que los bloques deben ser altamente reusables y poder crecer con ayuda de otros bloques. Esto garantiza que mas adelante la organización se podría adaptar a los cambios e inclusive a una nueva visión. A esto se le llama madurez.
mayo 1, 2020
Aplicación de una sola página

Una aplicación de una sola página, como su nombre lo indica, es un sitio donde su frontend se construye dinámicamente desde javascript en una única página, pero se hace de tal manera que cada uno de sus componentes o módulos se va cargando progresivamente, de esta manera se logra brindar una experiencia mucho más fluida. Veamos un ejemplo mas grafico para ver como funciona una petición(request) de una página comúnmente.

Proceso de petición de una pagina. En paginas convencionales cada vez que hacemos una petición el servidor nos responde con todo el contenido y refresca la pagina.

Imaginemos que entramos, por ejemplo, a una página construida en PHP (la web suele estar repleta de estos sitios). Nuestra carga inicial es cuando hacemos la petición al dominio, por ejemplo jhontona.com, el DNS se nos redirecciona al servidor que se encargará de brindarnos el contenido que solicitamos, suele ser común los .html (contenido), .css (estilos) y .js (funcionalidad). El problema es que cada vez que se procesa una nueva petición, por ejemplo al enviar un formulario, el cliente requiere hacer una nueva llamada al servidor, este la procesa y reenvía todo el contenido mas la respuesta para el usuario. Esto genera que el sitio se recargue en su totalidad.

En sus inicios la web eran solo bloques de texto, pero ahora tenemos imagen y video, el cual es demasiado costoso de enviar, sobre todo en redes lentas; para apalear un poco este problema los navegadores guardan en memoria (cache) los archivos más comunes (los mismos que miramos antes) con el objetivo de eliminar de la descarga esos archivos que previamente se habían cargado.

Las aplicaciones de una sola página (SPA) justamente se aprovechan de este sistema, enviando solamente el contenido que el usuario requiere en ese momento. Veamos como lo hace.

En nuestro esquema parece que no cambia mucho pero en la pagina esto tiene una gran repercusiÃ³n, ya que en múltiples peticiones al servidor solo se trae la información que se necesita en ese momento y esto se agradece mucho sobre todo en redes móviles, ya que hacen que nuestras paginas carguen mucho más rápido al solo traer lo que necesitamos para una carga inicial y a partir de esta vamos trayendo los fragmentos necesarios a medida que el usuario navega en nuestro sitio.

Para crear este tipo de sitios de una sola página se suele trabajar con javascript, este justamente se ejecuta en el cliente y se encarga de hacer las peticiones de manera incremental, podríamos por ejemplo con javascript puro ir haciendo nuestras peticiones a un servicio he ir mostrando la información como deseamos; pero afortunadamente no toca iniciar desde cero, entre los mas reconocidos frameworks tenemos Angular, React y VUE. Todos estos frameworks tienen el mismo objetivo, construir sitios SPA, pero utilizan diferentes enfoques. En un próximo post veremos por que usar Angular y sus características.

marzo 30, 2020

¡Hola a todos los entusiastas de la tecnología! Quería informarles que en mi blog utilizamos cookies para mejorar la experiencia de usuario. Estas pequeñas herramientas nos ayudan a personalizar el contenido y ofrecer funciones específicas. Al continuar explorando el sitio, aceptas nuestro uso de cookies. Puedes obtener más información sobre cómo las utilizamos en nuestra política de privacidad. ¡Gracias por ser parte de esta comunidad tecnológica! 🍪 Más información