Una sinfonía en C#

Un pequeño aporte a la comunidad de habla hispana.

Azure Devops: ¿Cómo saber el nombre de todas las variables y sus valores?

Si son como yo seguramente se confundirán todo el tiempo qué variable predefinda tiene qué valor, además de tener claro el valor en sí.

Por ejemplo al crear un pipeline de build no recordar si Build.ArtificatsStagingDirectory es lo mismo que Agent.BuildDirectory, etc. más aún, si además las variables que nosotros definimos tienen el valor esperado.

En este post vamos a ver un pequeño truco para averiguarlo en 2 minutos.

PowerShell al rescate

Además con este método vamos a saber cómo acceder a estas variables desde PowerShell, es decir, si hacemos un script (o inline) para que se ejecute como un step de un build o release podemos acceder a todas las variables.

Las variables de Azure Devops son variables de entorno en la máquina que se ejecuta el agente.

Al fin de cuentas cada variable de sistema de Azure Devops como las que definimos nosotros terminan llegando al agente como variables de entorno, y podemos acceder a ellas desde PowerShell o desde cualquier aplicación, solo tenemos que tener en cuenta algunas reglas.

Conversiones de nombre

  • Primero, los nombres de todas las variables se convierten a mayúsculas.
  • Segundo, los . que separan (por ejemplo) Agent.BuildDirectory, se reemplazan por _

Y listo, entonces System.ArtifiactsDirectory podemos encontrarlo como variable de entorno con el nombre SYSTEM_ARTIFACTSDIRECTORY

Y cómo hacemos para averiguar todos los nombres y valores desde Azure Devops?

Bien, el truco es simple, solo tenemos que crear un pipeline de build (o release, depende de qué variables queremos conocer) y agregamos una tarea de Powershell, elegimos que el Type del script sea “inline” y ponemos lo siguiente

ls env:

image

Solo eso, y la ejecutamos (si es un build guardar y encolar, si es un release, guardar, generar release, encolar) y cuando finaliza miramos el log, y veremos todas las variables de entorno de la máquina del agente en cuestión y entre ellas las propias de Azure Devops.

image

Ah, y para leer variables de entorno (como por ejemplo las de Azure Devops sean predefinidas o las creadas por nosotros) es tan simple como:

$variableValue = [System.Environment]::GetEnvironmentVariable("SYSTEM_DEFAULTWORKINGDIRECTORY")

Y obtenemos el valor de System.DefaultWorkingDirectory en este caso

Enjoy.

¿Qué es un Webhook? o ¿Cómo lograr ser informado de eventos sin hacer pooling?

En ocasiones necesitamos enterarnos de cambios en otros sistema, por ejemplo, tenemos un repositorio Git en Github y queremos saber cuándo se ha hecho un cambio para hacer algo en consecuencia (como iniciar un proceso de compilación).

Haciendo pooling

La primera forma de hacerlo sería de algún modo verificar si hay cambios ( cada 1 minuto digamos), es decir, enviar una petición cada 1 minuto.

image

Esta técnica se suela llamar pooling y de hecho se utiliza en casos que aplica, pero tiene ciertos problemas:

  • App1 (y todas las aplicaciones que desean saber si hay cambios) tiene que implementar el pooling, un timer, el request, etc.)
  • Cada App lo hará a su manera, y el intervalo de verificación puede ser diferente.
  • Cada App debería implementar un modo de saber que efectivamente hay cambios (imaginemos que en lugar de Git es una API que nos dice si hay un producto disponible por ejemplo) y esto podría tener un costo alto.
  • Todas las App cliente hacen pooling al mismo server y podría generar un costo a éste e incluso “tirarlo” si se hacen muchos request por segundo.

Webhooks al rescate

Hay dos formas prinicipales para solucionar problemas en software: la primera es agregra una capa más y la segunda es invertir el flujo y éste es el caso de los Webhooks.

Un Webhook es un endpoint que ofrece el cliente (por ejemplo App1) es decir una URL que acepta peticiones, y que es llamada por la API que queremos consumir, en este caso Github

image

 

Entonces en un primer momento App1 le dice a GitHub cuál es la URL de su Webhook (y eventualmente de qué eventos quiere ser informado) y luego se queda esperando.

Github (o la API que fuera) guarda la URL del Webhook de App1 (y a la todos los clientes que quieran ser notificados) y cuando detecta cambios le informa haciendo un POST a cada URL de los clientes, adicionalmente envía información sobre el evento ocurrido.

A partir de esto App1 hace un pull de los cambios (o lo que sea).

Es decir, en lugar de nosotros como cliente que consume una API preguntar cada x tiempo si hay cambios, le decimos a la API que nos avise cuando hay cambios a través de una URL dada, cuando esto ocurre hacemos algo en consecuencia.

Probando  un Webhook con Github.

Una cosa que no está definida en un Webhook son los datos que la API (Github en este caso) nos va a enviar en el payload del POST a nuestro Webhook (la información sobre los cambios, el evento, etc.) esto es libre, cada API/Aplicación/etc. incluye la información que cree necesaria, cosa que parece lógica para dar flexibilidad y porque cada aplicación puede querer informar cosas diferentes.

Entonces, ¿cómo sabemos qué datos nos llegan a nuestro Webhook?

Evidentemante nuestro Webhook ( el endpoint que ofrecemos para ser informados de eventos en Github en este ejemplo) tiene que ser accesible desde internet (para que Github puede invocarlo, claro) y estoy puede ser un problema a la hora de desarrollarlo.

Hay herramientas que voy a recomendar para verificar esto, es un sitio web que nos permite generar una URL aleatoria (nuestro Webhook temporal) y ver todas los requests que recibe y su respectivo payload. Entonces vamos a https://webhook.site

Webhook Site

Este sitio apenas ingresamos nos genera una URL aleatoria que será nuestro Webhook, es decir, la URL por la cual, mediante un POST las API (o apps que querramos que nos informen) nos informarán.

image

Para probar cómo funciona vamos a utilizar Postman y hace un simple request.

 

image

 

Simplemente un POST a la URL que generó webhook.site y ponemos algo en el body, apretamos Send

 

image

 

Y magia! vemos nuestro request, bien, funciona,ahora vamos a hacerlo con Github, crear un Webhook sobre un repositorio.

Configurar GitHub

Para esto vamos a un repositorio, a la pestaña de setting y ahí a Webhooks (se pueden configurar a nivel usuario también)

image

image

En este caso se seleccionó la opción “send me everything” para recibir todos los eventos (es una prueba, claro)

Lo primero que va a ocurrir es que Github envían un ping a nuestro Webhook para verificar que funciona, y podemos verlo en webhook.site

 

image

Esto es buena señal (quiere decir que la configuración es correcta), entonces ahora hacemos un cambio en cualquier archivo en nuestro repositorio y recibimos el evento con la información

image

Y recibimos un nuevo POST con la información que envía Github, como dije, esta información varía con cada evento y en cada sitio, de modo que tenemos que leer la documentación o probar qué nos envía para poder leer esto dentro de nuestro Webhook.

Conclusiones:

Los Webhook son una forma excelente de recibir notificaciones de sitios web (o APIs, Repositrios, etc.) que queremos monitorizar para realizar tareas en consecuencia, además hoy por hoy casi todo el mundo los soporta.

Falta ver el soporte de autenticación y algunos detalles más pero la idea básica es ésta, espero sera de utilidad, nos leemos.

Predicados y array en Javascript: find, filter, some.

En esta tercera parte vamos a ver varios métodos juntos, find, filter y some porque...bueno, porque sí.
En realidad porque tiene algo en común, todos reciben como parámetro un predicado

¿Y qué es un predicado?

En este contexto es una función que establece una condición contra la cual se evaluarán elementos.
Dicho en palabras un poco menos complicadas, pasamos una función que será la encargada de decirnos si un elemento de un array cumple con una condición.
Veamos un ejemplo:

Array.filter

Empecemos con filter, al final los tres métodos son similares pero hacen cosas distintas.
Filter permite tomar solo aquellos elementos de un array que cumplen con una condición, en este caso, determinada por el predicado.
Entonces, si tenemos el siguiente array:

var a = [1,2,3,4,5,6,7,8,9];

y quisiera quedarme solo con aquellos elementos que son pares podría hacer esto:

var aa = [];
for(var item in a){
     if(item % 2 == 0)
         aa.push(item);
}
console.log(aa);

Con filter la cosa sería así:

aa = a.filter(function(item){
     return item % 2 == 0; });

El resultado es exactamente el mismo.

Y es igual que:

aa = a.filter((item)=> item % 2 == 0);

Aún más elegante.

Algunas características de filter:

  • Solo se invoca el callback (el predicado) para elementos que tiene valores, es decir, los elementos del array sin valores se ignoran.
  • Los elementos borrados durante la ejecución no son visitados.
  • El rango de elementos a visitar se establece antes del inicio de la iteración, es decir, si se agregan elementos los mismo no son visitados.
  • Si un elemento cambia de valor se leerá el nuevo valor.

Además filter recibe dos parámentros, el callback que recibe tres: el elemento actual, el índice actual y el array original.
El segundo parámetro es el contexto de this, vamos, igual que las funciones que vimos en los posts anteriores.

Todo es es igual para el caso de find y some, veamos cómo funcionan.

Find

Simplemente retorna el primer elemento que coincida con el criterio del predicado, en el ejemplo anterior retornaría el número 2.

a.find((item)=> item % 2 == 0);

Evidentemente si hay más elementos que cumplen la condición establecida en el predicado son ignorados, en caso de no haber ninguno retorna undefined.

a.find((item) => item > 10);

Las mismas reglas de comportamiento anteriores se aplican a find.

Some

En este caso devuelve true si al menos un elemento cumple con el criterio de búsqueda y false si no hay ninguno.

a.some((item) => item > 2);

Devolverá true.

a.some((item)=> item > 10);

Devolverá false, sería casi como hacer algo así con find:

a.find((item)=>item > 10) != undefined;

Lo dejamos acá por hoy, nos leemos.

Array map en Javascript, se usa mal?

En el post anterior hablamos sobre Array.forEach y su funcionamiento, ahora vamos con el que hoy en día (creo yo) es el segundo método de Array más usado, map.

Map recorre un array y crea un nuevo array como resultado de la invocación a una función dada.
En palabras simples, map recorre un array y aplica una función (que es parámetro) a cada elemento del mismo, y crea un nuevo array con los elementos resultantes.

Un ejemplo simple (y no muy útil)

var a = [1, 2, 3, 4];
const m = a.map(function(item){
     return item;
});
console.log(m);

O lo que sería lo mismo:

m = array1.map(x => x);

Lo que ocurre es que la función que se pasa como parámetro es quien genera el resultado, en este caso devuelve el mismo elemento que recibe (en item se pasa cada valor del array, uno a la vez) entonces el resultado es igual, pero es un nuevo array, no es el mismo.

Evidentemente este ejemplo no tiene mucha utilidad, en genera uno realiza operaciones dentro de la función, por ejemplo:

var a = [1, 2, 3, 4];
var m = a.map(function(item){
     return item * 2;
});
console.log(m);

En este caso la función recibe en item cada elemento y retorna su valor * 2.
Por supuesto que dentro de esta función podemos hacer cualquier cosa, incluso ignorando los valores del array original.

var a = [1, 2, 3, 4];
var m = a.map(function(item){
     console.log(+new Date());
});

Alguna características de map:

  • La función recibe tres parámetros, el item actual, el índice del elemento y el array orginal, con lo cual podemos operar sobre el array orginal.
  • Se invoca a la función una vez por cada elemento del array que contiene valores.
  • Si no se usa el array resultante o no se retorna un valor en el callback se considera incorrecto el uso de map, en tal caso se puede usar for-of o forEach.
  • Los elementos recorridos por map son determinados antes de iniciar el recorrido.
  • Los elementos que hayan cambiando luego de iniciada la iteración se considerará su valor actual.
  • Los elementos removidos no son recorridos (ya que sus valores serían inválidos).
  • Es posible pasar el contexto como segundo parámetro (que tomaría el valor de this).

Como vemos muchas de estas características son iguales a forEach.

Entonces, cuándo usamos map y cuándo forEach?

Como dice más arriba, si no vamos a utilizar el array resultante se considera un antipatrón usar map y debemos echar manos de forEach o for-of.

El uso tal vez más común al consultar una API sería "reformatear" los objetos obtenidos.

var a = [{"nombre":"Marcelo", "nombre":"Leonardo"}];
var m = a.map(function(item){
     return {"Nombre":item.nombre}
});

console.log(m);

Nos leemos.

Métodos para trabajar con Arrays en Javascript

Esto viene de la curiosidad que me dio ver que varias personas utilizan el método map de Array para iterar aunque no deseen mapear los objetos, al preguntar el porqué de tal decisión me he dado cuenta que hay varios métodos del objeto Array poco conocidos que son muy útiles y, en algunas ocasiones, más adecuados según el caso de uso.

Los arrays en Javascript son cosa de todos los días, cuando manipulamos datos gran parte de las veces se trata de un array de elementos. Entonces conocer algunos métodos relacionados con ellos nos puede ser útil.
En este caso vamos a repasar algunos que me parece más útiles.

A los largo de algunos posts veremos:

  • Array.prototype.forEach
  • Array.prototype.map
  • Array.prototype.some
  • Array.prototype.filter
  • Array.prototype.find
  • Array.prototype.reduce
  • Array.prototype.findIndex

No todos separados, dependiendo un poco de lo largo que vayan quedando los posts.

Array.prototype.forEach

Empezamos con el que creo será el más común que utilizar al consultar un servicio.
forEach permite iterar todos los elementos de un array. Algo así:

var a = ['a', 'b', 'c'];
a.forEach(item => {
   console.log(item); });

Entonces en lugar de iterar con un for clásico (clásico para los que estudiamos programación estructurada) con forEach se recorre todo el array y nos da una referencia en el parámetro item.

Algunas características del forEach:

  • La cantidad de elementos a recorrer es establecida antes de iniciar el bucle, por lo tanto si agregamos un elemento dentro del forEach el mismo no será visitado.
  • Siempre retorna undefined, por lo tanto no es posible encadenarlo
  • No es posible interrumpir su ejecución (excepto con una excepción)
  • Si un elemento cambia y forEach no ha pasado aún por él se leerá el valor actualizado.
  • Si un elemento no visitado es borrado no será visitado.
  • Si un elemento ya visitado es borrado el resto de los elementos no será visitado.

El callback que recibe forEach como parámetro recibe 3 argumentos

  • El elemento actual que se está visitando.
  • El índice del elemento actual.
  • Otro array.

This dentro del forEach.


El valor de this dentro del forEach es el contexto actual (window en el navegador), es posible pasar un segundo parámetro a forEach a modo de contexto.

function Counter() {
   this.sum = 0;
}
Counter.prototype.add = function(array) {
   array.forEach((entry)=>{
     this.sum += entry;
   }, this);
};

Si hacemos:

var c = new Counter();
c.add({1,2,3});

el resultado es la suma, ya que el acumulador de this es el miembro sum del objeto Counter.

Y para qué es el tercer parámetro? un array?

El tercer parámetro que recibe el callback es el array original, ya que en Javascript los parámetros se pasan por valor (es decir, son copias) si hacemos esto:

var a = [1,2,3];
a.forEach(function(item, index, aa){
     item = 0;
});

Si comprobamos el valor del array a vemos que los valores no cambiaron, si quisiéramos cambiarlos deberíamos operar sobre el tercer parámetro que es el orginal.

a.forEach(function(item, index, aa){
     aa[index] = 0;
});

al comprobar el valor del array original vemos que todos sus valores fueron sobre-escritos, mágico.

Bueno, lo dejó acá. Espero les sea útil. Nos leemos.