AWS IoT Core utiliza temas para enrutar mensajes de los editores a los suscriptores. Un topico es simplemente un canal de comunicación en el que los dispositivos pueden publicar mensajes y suscribirse para recibir esos mensajes. Los temas de AWS IoT Core tienen estructuras jerárquicas y se definen mediante barras diagonales (/) como delimitador. Por ejemplo, un topico podría ser “hogar/dormitorio/luz”.
Los temas reservados son temas del sistema que comienzan con un signo de dólar ($), Por ejemplo $aws/things/thingName/shadow/update
es un topico reservado para actualizar la sombra del dispositivo de un objeto llamado “thingName”
Los temas reservados se clasifican en tres tipos:
Estos temas reservados proporcionan un medio para que AWS IoT Core se comunique directamente con los dispositivos. Por ejemplo, cuando un dispositivo necesita recibir una actualización de firmware, AWS IoT Core puede enviar un mensaje al dispositivo a través del topico del trabajo reservado. Luego, el dispositivo puede recuperar la actualización del firmware y aplicarla.
Si bien el dispositivo puede publicar en estos temas reservados, no puede suscribirse a ellos. Estos temas se utilizan para que AWS IoT Core se comunique con el dispositivo, no para que el dispositivo se comunique con AWS IoT Core
En conclusión, el signo de dólar ($) en los temas principales de AWS IoT se utiliza para indicar temas del sistema que están reservados para la comunicación entre AWS IoT y el dispositivo. El dispositivo no puede suscribirse a estos temas, pero puede publicarlos para solicitar operaciones específicas.
Reserved topics - AWS IoT Core
Publish/Subscribe policy examples - AWS IoT Core
]]>log( ( <Instance Memory> * 1073741824) / 8187281408 ) * 1000 = <Default Max Connections>
Para Aurora Serverless, el valor máximo de conexiones se basa en las unidades de capacidad asignadas (ACU) del clúster. aquí hay una lista de conexiones máximas por ACU:
Es importante tener en cuenta que Aurora Serverless v1 no le permite modificar el valor de conexiones máximas manualmente. Además, las conexiones máximas se verán afectadas por las limitaciones en la cantidad de conexiones simultáneas permitidas por el motor de base de datos en arquitecturas serverless.
How Aurora Serverless v1 works - Amazon Aurora
Implement an Amazon Aurora Serverless cluster
Aurora Serverless: The Good, the Bad and the Scalable - Jeremy Daly
Creating an Aurora Serverless v1 DB cluster - Amazon Aurora
Aurora Serverless v2: Why You Need It, New Features and Pricing
]]>Si en cambio quisieramos ejecutar lint desde un hook de git, podemos abrir el archivo .git/hooks/pre-commit
#!/bin/bash
npm run lint --prefix path/to/your/npm/installation
Se puede alterar el string directamente sin un struct:
package main
import (
"bytes"
"encoding/json"
"fmt"
"log"
)
func PrettyJSON(str string) (string, error) {
var prettyJSON bytes.Buffer
if err := json.Indent(&prettyJSON, []byte(str), "", " "); err != nil {
return "", err
}
return prettyJSON.String(), nil
}
func main() {
rawJSON := `{"name": "Mike", "lastname": "Tyson"}`
response, err := PrettyJSON(rawJSON)
if err != nil {
log.Fatal(err)
}
fmt.Println(response)
}
Resultado:
{
"name": "Mike",
"lastname": "Tyson"
}
const AWS = require("aws-sdk");
console.log("Loading...");
const uploadData = (filename, fileContent) => {
return new Promise((resolve, reject) => {
const s3 = new AWS.S3();
const params = {
Bucket: process.env.S3_Bucket,
Key: `${filename}.json`,
Body: fileContent,
};
s3.upload(params, (err, data) => {
if (err) {
reject(err);
}
resolve(data.Location);
});
});
};
exports.handler = async function (event, context) {
if (event.path === "/" && event.httpMethod === "POST") {
await uploadData(context.awsRequestId, event.body);
}
return {
statusCode: 200,
body: JSON.stringify({ requestId: context.awsRequestId }),
};
};
import boto3
import json
s3 = boto3.resource('s3')
bucket = "nombre-del-bucket"
file="nombre-del-archivo.json"
content_object = s3.Object('test', 'sample_json.txt')
file_content = content_object.get()['Body'].read().decode('utf-8')
json_content = json.loads(file_content)
print(json_content)
expect
de mocha no incluye el validador de uuid, para eso hay que instalar el paquete chai-uuid
npm install chai-uuid
Indicar en el test que mocha
use la libreria
const chai = require("chai");
chai.use(require("chai-uuid"));
y finalmente usarlo con expect
const chai = require("chai");
chai.use(require("chai-uuid"));
const expect = chai.expect;
// validar v1 de UUID
expect("bd74c8da-4d9e-11e7-b114-b2f933d5fe66").to.be.a.uuid("v1");
// validar v2 de UUID
expect("f6b93689-1c6a-2931-a785-c7d5606f7f4d").to.be.a.uuid("v2");
// validar v3 de UUID
expect("622ab4f8-c3e7-3747-a548-0e2d11bf5ab1").to.be.a.uuid("v3");
// validar v4 de UUID
expect("0ce529f4-8854-41ec-b67c-fbcb4e716e42").to.be.a.uuid("v4");
// validar v5 de UUID
expect("48a698a0-1641-5aca-bc1b-de9b1a482ee1").to.be.a.uuid("v5");
// validar cualquier version UUID
expect("a416d989-91d1-48c9-b583-267df138834c").to.be.a.uuid();
Más documentación oficial en inglés:
]]>pg-mem
es un proyecto de codigo abierto para javascript (funciona en Node.js y el navegador) donde podemos simular un servidor de Postgres en memoria, bastante útil para unit test y test locales.
No viene sin sus propias limitation, por defecto, pg-mem no tiene implementado extensiones nativas.
La más común que uso es uuid_generate_v4 como valor por defecto devuelve un uuid para los id en mis tablas.
Si quieramos emular el mismo comportamiento aquí el código:
import { v4 } from "uuid";
db.registerExtension("uuid-ossp", (schema) => {
schema.registerFunction({
name: "uuid_generate_v4",
returns: DataType.uuid,
implementation: v4,
impure: true,
});
});
Más información en inglés en el GitHub del proyecto oficial: https://github.com/oguimbal/pg-mem/wiki/FAQ#-what-if-i-need-an-extension-like-uuid-ossp-
]]>sudo apt-get remove docker docker-engine docker.io containerd runc
Requerimientos minimos
sudo apt-get update
sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
gnupg
Agregando la pgp keys
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo \
"deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Listo para instalar desde apt
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Testeando
docker ps
Si al correr el ultimo comando da un error de permisos como:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json: dial unix /var/run/docker.sock: connect: permission denied
Tenemos que agregar a nuestro usuario al grupo docker
sudo usermod -aG docker $(whoami)
Es necesario desloguear al usuario actual para que haga efecto el cambio.
Para mas detalles en inglés en la documentación oficial: https://docs.docker.com/engine/install/ubuntu/
]]>tmp
vacia (por defecto git no va a subirla al repositorio), para lograr ese cometido necesitamos un .gitignore
./tmp/.gitignore
El contenido del archivo indica “ignorar todos los archivos y subcarpetas” y agrega una excepción del archivo actual .gitignore
*
*/
!.gitignore