Après presque 2 ans de silence et le remplacement de Hugo et Bootstrap par Zola et Tailwind/daisyUI l’été dernier pour générer le site, je vous souhaite une bonne année à tous et la résolution de publier plus régulièrement mes trouvailles… Data Multi-Database Support in DuckDB : Cela multiplie les possibilités :sunglasses: TL;DR: DuckDB can attach MySQL, Postgres, and SQLite databases in addition to databases stored in its own format. This allows data to be read into DuckDB and moved between these systems in a convenient manner. IoT Devenez un expert LoRaWAN via LoRa et LoRaWAN pour l’Internet des Objets: si vous cherchez un cours théorique et pratique pour vous former aux protocoles LoRa et LoRaWan, je vous le recommande chaudement. Ops DKron via Dkron pilote vos crontab : un gestionnaire de cron distribué, avec une jolie interface et uen API - que demander de plus ? Sur un modèle agent/serveur, le serveur dRkon distribue les tâches aux agents dKron concernés. les agents dKron étant déployés sur les serveurs sur lesquels les jobs doivent s’exécuter. Reverse Proxy Caddy : si vous avez besoin d’un reverse-proxy avec gestion automatique des certificats et redirection HTTP > HTTPS et plein d’autres choses encore mais sans nécessité d’intégration avec Docker comme Traefik, alors jetez un coup d’oeil à Caddy. Il permet également d’avoir un certificat sur localhost. Comme Traefik, il est écrit en Go. J’avoue que la concision de Caddy vs Traefik et le provider file est bien appréciable:
Cron et Crontab sont dans un bateau… Il fut un temps où pour programmer le lancement des actions, notre meilleur ami était “cron” et la “crontab”. Outre la syntaxe et l’organisation de la crontab peu mémorisable, les tâches cron restaient complexes à déployer et à monitorer dans leur exécution. Si le fait d’avoir des répertoires plus génériques comme /etc/cron.{d,hourly,daily,weekly,monthly} ont un peu amélioré la partie exploitabilité/déployabilité, ils offraient assez peu de souplesses pour une plannification fine des tâches. De nombreux serveurs ont donc eu un mix de crontab classique et de ce format pendant des années. Debian 9.0 (mais d’autres aussi comme Archlinux par ex) a fait le choix dans le cadre de son adoption de systemd de ne plus proposer un logiciel de type cron mais de s’appuyer sur l’implémentation interne à systemd, à savoir les “timers”. C’est une unité (unit) spéciale de systemd qui est controllée et supervisée par systemd et qui s’exécute selon une configuration temporelle donnée.
On orchestre, on conçoit — et on code aussi. Parlons de votre plateforme, vos données ou votre projet IoT.
Contactez-nous →