Sobre Spring Boot y Java

 Para mi Spring boot llegó para ser una herramienta extremadamente útil para los desarrolladores especialmente de java pues confiere unas habilidades por defecto bastante comunes en aplicaciones de java, de una manera rápida y sin mucho rodeo.

He escuchado críticas a java primero por que no es tan práctico para la programación funcional y por que hay que escribir mucho código para lograr funcionalidades que en otros lenguajes se hacen en mucho menos espacio, sin esto dejar de ser cierto creo que java se sigue usando porque hay muchos programadores de java al menos aqui en latinoamerica, hay muchos sistemas legados de java y estas desventajas no muestran algo necesariamente mal con el lenguaje.

Spring cómo framework trajo un montón de soluciones listas para instalar en aplicaciones java, pero tenía dos cosas que se mejoraron enormemente con la traída en escena de spring boot. Spring boot funciona encima de spring como una manera de controlar automáticamente los archivos de configuración en spring(que podían llegar a ser extensos) con configuraciones por defecto cuando es posible,  y con el descubrimiento de clases.

La configuración automática permite que solo definamos la configuración de aquellas cosas que queremos cambiar y que el spring boot maneje el resto.
El descubrimiento de clases nos permite que spring controle el contexto de la aplicación de esta manera solo carga las clases que sean necesarias basado en anotaciones del tipo @ConditionalOn ….. , y usar anotaciones como  @autowired que nos permiten cargar interfaces/servicios/controladores en una clase dejando que spring boot resuelva cuál es la que se debe cargar y manteniendo el contexto de la aplicación general.

con spring boot el uso de anotaciones es común y práctico, por ejemplo si nosotros quisiéramos usar una caché en memoria para un método que hace un proceso pesado de procesamiento/memoria y/0 hace un llamado de red podemos en cuestión de dos anotaciones tenerla funcionando (un @EnabledCache en la configuración de spring y un @Cacheable en el método que queremos guarde en memoria sus resultados) lo que es ciertamente potente

Con estas y otras cosas spring boot genera velocidad en el desarrollo de aplicaciones java y/o kotlin(yo personalmente prefiero usarlo con kotlin por que me parece práctico en el manejo de valores nulos y la verbosidad de las aplicaciones).

las opiniones de java/kotlin son eso opiniones, sobre spring boot la fuente fue Spring Boot in Action de Craig Walls (capitulo 1 y 2)

Trading algoritmico

Hay muchas maneras de hacer lo mismo con resultados distintos para invertir pasa lo mismo podemos invertir con estrategias comprobadas atravez del tiempo como en un portafolio altamente diversificado y a largo plazo, si se le da suficiente  tiempo y suficiente dinero se va terminar con riqueza inevitablemente como lo dice nick murray en su libro simple wealth, inevitable wealth.

pero el argumento contrario  tambien tiene algo de verdad si los mercados son eficientes, son eficientes por que los participantes del mismo así lo hacen.

bueno entonces las estrategias algorítmicas buscan encontrar patrones en los mercados para obtener ganancias por encima de las normales de los mismos, esto inevitablemente conlleva riesgos pues nada garantiza que por que algo sucedió antes vaya suceder después.

lo primero que necesitamos para esto es obtener la información del mercado una opción es usar la api de alpha avantage para usarla se debe obtener una clave o api-key atravez de su pagina web que dan gratuitamente luego de tenerla se puede usar este endpoint para consultar el simbolo de la empresa que queramos analizar colocandolo en keywords

https://www.alphavantage.co/query?function=SYMBOL_SEARCH&keywords=bmw&apikey=YOUR-API-KEY

 teniendo el simbolo luego vamos a este otro endpoint para obtener la informacion historica diaria del simbolo

https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=BMW.FRK&outputsize=full&apikey=YOUR-API-KEY

 Esta info luego puede ser organizada en un dataframe de python con el siguiente codigo

import numpy as np
import pandas as pd
import pandas_datareader.data as pdr
from datetime import datetime
import matplotlib.pyplot as plt
plt.style.use('seaborn')
import requests
import json
response = requests.get("https://www.alphavantage.co/query?function=TIME_SERIES_DAILY&symbol=BMW.FRK&outputsize=full&apikey=YOUR-API-KEY")
alphadict = json.loads(response.text)
alphadict.keys()
stock = pd.DataFrame(alphadict['Time Series (Daily)']).T
stock.columns = ['open', 'high', 'low', 'close','volume']
stock.index = pd.to_datetime(stock.index)
stock = stock.sort_index(ascending = True)
stock = stock.astype(float)
raw=stock[['close']].copy()
raw.columns=['close']
raw.tail()

 

  Con ese codigo quedamos en la variable raw con un dataframe que contiene los closing prices para la compañia bmw, que podemos usar directametne para generar modelos de trading algoritmico(tecnicos, cuantitativos, sumandole mas informacion para otros modelos).para verificar el simbolo yo encuentro especialmente util la siguiente linea

raw[-2000:].plot(lw=2.0,figsize=(10,6)

nos permite generar un grafico con los valores ir cambiando el -2000 por la cantida de registros que tengamos en nuestra herramienta de trading para mirar por encima que los valores coincidan con la grafica. 

luego con estos valores por ejemplo podemos probar alguna extrategia ahora mismo la unica que yo estoy probando es usar medias moviles, con fuerza bruta como indicador de momentum para una operacion que se abre el lunes y se cierra el viernes

from itertools import product
sma1 = range(0, 201, 5)
sma2 = range(200,501, 5)
results = pd.DataFrame()
for SMA1, SMA2 in product(sma1, sma2):
    data=raw.copy()
    data.dropna(inplace=True)
    data['Returns'] = np.log(data['close'] / data['close'].shift(4))
    data['SMA1'] = data['close'].rolling(SMA1).mean()
    data['SMA2'] = data['close'].rolling(SMA2).mean()
    data.dropna(inplace=True)
    data['Position'] = np.where(data['SMA1'] > data['SMA2'], 1, -1)
    data['Strategy'] = data['Position'].shift(4) * data['Returns']
    data['date']=data.index
    data['day-of-week']=data['date'].dt.day_name()
    data=data[data['day-of-week']=='Friday']
    data=data[-100:]
    data.dropna(inplace=True)
    perf = np.exp(data[['Returns', 'Strategy']].sum())
    results = results.append(pd.DataFrame({'SMA1': SMA1, 'SMA2': SMA2,'MARKET': perf['Returns'],
                                           'STRATEGY': perf['Strategy'],
                                           'OUT': perf['Strategy'] - perf['Returns']},index=[0]), ignore_index=True)

results.sort_values('OUT', ascending=False).head(7)

los rangos de la variable sma1 y sma2 pueden ser reducidos considerablemente para que no tome tanto tiempo la fuerza bruta y son los que usan para hacer la fuerza bruta, alfinal se compara lo que indique esta estrategia contra una de comprar y mantener la operacion y se organiza para obtener el que mayores ganancias reporte.

 esto termina siendo sobreajustado(overfitting) por que no tiene datos de prueba para evaluar aparte y ya de por si hacer esto es mineria de datos por lo que el nivel de riesgo es elevado de seguir una estrategia como esta creo es elevado, por tanto recomiendo no usarla  

notas del curso https://learning.oreilly.com/learning-paths/learning-path-hands-on/9781492082613/ - Learning Path: Hands-On Algorithmic Trading with Python de Deepak Kanungo

el segundo bloque de codigo de fuerza bruta esta modificado del codigo encontrado en el  capitulo 15 de Python for Finance, 2nd Edition, donde tambien explican otras estrategias, y dan mas detalle del mismo

Microservicios

notas del libro Microservices Patterns,Chris Richardson, capítulo 1 y 2.

Lo primero es entender que existen varias dimensiones en la arquitectura de software, es decir un sistema puede estar usando varias arquitecturas al mismo tiempo por ejemplo una arquitectura de micro-servicios con arquitectura hexagonal, o una arquitectura monolítica con arquitectura de 3 capas.para explicar esto el autor usa las 4+1 vistas y un escenario y un sistema de coordenadas x,y,z para representar las diferentes dimensiones de la arquitectura.

una arquitectura de micro-servicios es una arquitectura en la que la aplicación está generada por múltiples servicios independientes y desacoplados(cuando se dice que los servicios deben ser desacoplados en una arquitectura de micro-servicios esto significa que los servicios deben comunicarse por api y que cada servicio debe tener su propia base de datos)

y una arquitectura monolítica es una arquitectura de aplicación con un solo desplegable/ejecutable.

la arquitectura de micro-servicios tiene como es usual ventajas y desventajas que el autor explica en 3 partes

1. las fortalezas de la arquitectura o lo bueno que trae
2. el contexto resultante o como queda el sistema después de aplicar la arquitectura con que debilidades y que fortalezas
3. y los patrones relacionados como un diagrama en el que se relaciona que otro patrón podría reemplazar a esta/cubrir sus problemas/ mejorarlo/o si este patrón es mejora de otro.
   

Para él es claro que si una empresa startup está empezando es mejor que esta empieze con una arquitectura monolítica y luego realiza el refactor a un arquitectura de micro-servicios. 

en qué punto hacer ese refactor es una línea delgada pero hay indicadores para reconocerlo por ejemplo.

• si el equipo de desarrolladores son muchos +7 seguramente tiene mas sentido dividir las responsabilidades, para con esto balancear el costo de la comunicación entre tantas personas es muy improductivo
• si la base de código es muy compleja y no le cabe en la cabeza a una sola persona, seguramente implica que no la deba trabajar una sola persona sino dividirla para diferentes partes las trabajen diferentes personas
• cuando la cantidad de usuarios es muy alta y el escalamiento es muy complejo. por ejemplo por que una parte de la aplicación requiere mucha memoria por una in-memory database, otra tiene una red neuronal y requiere gpu etc. escalar es complejo porque cada instancia de la aplicación va requerir la suma de recursos que necesita la app como todo para correr
  

Incluso con estos indicadores mutar o irse del monolito a una arquitectura de micro-servicios es peligroso y puede salir mal en el peor de los casos se termina con un monolito distribuido un engendro que suma las desventajas del monolito y las desventajas de los micro-servicios. 

Al mismo tiempo y siendo complejo en cierto punto hace más sentido realizar micro-servicios porque la curva exponencial para realizar entregas en el monolito se vuelve insostenible, y muchas empresas que han escalado mucho muchísimo lo han podido hacer por las capacidades que les proporciona una arquitectura de micro-servicios.

el autor recomienda juntar micro-servicios con una arquitectura hexagonal(o de puertos y adaptadores) pues esta encaja bien con DDD( domain driven design) que al mismo tiempo encaja muy bien con la división de un servicio monolito en micro-servicios, en otras palabras un triángulo virtuoso.

y describe 3 pasos generales para cambiar de una arquitectura monolítica a una micro-servicios.

1. reconocer los procesos que realiza la organización(estos se traducen usualmente a llamados o endpoint rest)
2. Reconocer los servicios: a través de los procesos fundamentales de la organización oa través de subdominios identificados por DDD.
3. identificar las api. es decir las interfaces de comunicación(de los servicios o atravesar de llamadas rest o eventos por mensajería)
   

yo creo que  plantear una arquitectura de micro-servicios es inevitable en cierto momento cuando las organizaciones crecen y su modelo de negocio tiene una base tecnología, y aunque tiene muchas complejidades lo único que queda es hacerlo lo mejor posible para no terminar solo con desventajas y/o más problemas

Helm plantillas para los recursos de kubernetes

Ya de por sí tener kubernetes si se usa con archivos que nos definan los recursos de infraestructura es un gran ventaja por que tenemos una forma replicable, usualmente versionada de la infraestructura que nos permite rastrear errores con facilidad. 

Los desarrolladores en general van y siguen automatizando/generalizando más para ganar velocidad y evitar que con la réplica de copiar/pegar se generen errores inesperados en este caso en la definición de recursos de kubernetes.

Es que un problema que puede ser frecuente es tener un recurso desplegado en algún proveedor de nube que debemos definir para un ambiente de desarrollo y para un ambiente de producción, usualmente con pequeñas diferencias como:

• en uno se puede estar usando una url diferente
• tener habilitado un mecanismos de seguridad adicional en producción
• usar un espacio de nombres diferentes
  

Al final es como si tuviéramos un plano del recurso y en puntos específicos quisiéramos definir valores dependendiendo de lo que necesitamos del recurso y esto es lo que permite hacer helm

Una forma de definir plantillas para los recursos de kubernetes que podemos aplicar con diferentes valores usualmente una para cada ambiente pero también una sola plantilla se puede estar usando múltiples veces para un recurso del mismo tipo en el mismo ambiente por ejemplo si un equipo realiza spring-boot.

para definir un recurso de esta manera lo primero es definir un chart que nos permite colocar entre otras cosas un nombre,una descripción, quienes mantienen esta plantilla etc
(Chart.yaml)

apiVersion: v2

name: <the-name>

description: <the description>

version: 1.0.0 # chart version

Luego creamos una carpeta templates y dentro definimos nuestro recurso o recursos de kubernetes con la ubicación de los valores que vamos a definir en otros archivos. incluso podemos colocar condiciones if para que dado que un valor se defina una configuración o no
templates/<uno o muchos archivos>.yaml

{{ .Values.host }} # para obtener valores de la definicion de values que

 tengamos

{{- if .Values.tls.enabled }}

{{- end }} # hay que tener cuidado respetando la indentacion 

nos permite poner definiciones dinamicas solo si es true el 

codigo en el medio entre if y end se agrega 

 

finalmente definimos un archivo de valores que se van a aplicar a nuestros templates
(values-xxx.yaml)

host: dev.example.com

tls:

enabled: false

para instalar esta definición con nuestra plantilla podemos usar el comando(previo a estar conectado a nuestro cluster sea el proveedor de nube o un cluster corriendo en la maquina propia como minikube)

$ helm install -f <whatever-name> values-xxx.yaml .

instalar el nombre que le pongamos el archivo values qué le vamos a aplicar a la plantilla con el . osea chart en el directorio actual
y si realizamos algún cambio sea en las plantillas o en los valores después de haberlo instalado podemos actualizarlo con 

$ helm upgrade -f <whatever-name> values-xxx.yaml .

Otra herramienta en la misma línea de helm es kustomize. helm se recomienda para aplicaciones propias en las que buscamos definir todo mientras kustomize se recomienda cuando vamos a definir despliegue de aplicaciones de terceros a las que solo queremos sobrescribir pequeños detalles con la configuración propia(por ejemplo una url).