Génération vidéo locale : ComfyUI et LTX-2.3

Auparavant, créer des vidéos à l’aide de réseaux de neurones était l’apanage des services cloud comme Runway ou Luma. Aujourd’hui, si vous disposez d’une carte graphique Nvidia moderne, vous pouvez générer des vidéos de haute qualité directement sur votre ordinateur. Dans cet article, je vais vous expliquer comment configurer la génération vidéo locale à l’aide de ComfyUI et du modèle efficace LTX-2.3.

Outils de génération de vidéos

Pour le travail, nous aurons besoin de :
ComfyUI : une interface puissante avec une architecture basée sur des nœuds qui vous permet de personnaliser de manière flexible le processus de génération.
LTX-2.3 : Un modèle moderne de Lightricks, optimisé pour créer des vidéos fluides et détaillées avec des besoins en mémoire vidéo relativement modérés.

Exigences matérielles

Générer une vidéo est un processus beaucoup plus gourmand en ressources que travailler avec des images :
Carte vidéo (GPU) : Nvidia RTX avec 8 Go de VRAM est le minimum requis pour une résolution de 768 x 512. Pour un fonctionnement confortable et des résolutions plus élevées, il est hautement souhaitable de disposer de 16 à 24 Go de VRAM.
Mémoire vive (RAM) : minimum 32 Go. Les modèles vidéo et les VAE prennent beaucoup de place lors du téléchargement.
Espace disque : environ 500 Go pour le modèle lui-même et les composants associés.

Configuration et lancement

Le processus de lancement de LTX-2.3 dans ComfyUI est le suivant :
1. Mettre à jour ComfyUI : Le modèle est relativement nouveau, alors assurez-vous d’avoir installé la dernière version de l’interface.
2. Installer le workflow : Le moyen le plus simple consiste à trouver un modèle JSON prêt à l’emploi pour LTX Video. Le modèle nécessite des nœuds spécifiques pour fonctionner avec l’espace latent vidéo.
3. Invite et paramètres : Saisissez une description de la scène en anglais. Notez que le LTX-2.3 comprend bien le mouvement (par exemple « la caméra tourne autour », « mouvement rapide »).

Pourquoi choisir LTX-2.3 ?

LTX-2.3 est remarquable car il fournit des résultats comparables aux services cloud propriétaires, mais s’exécute localement. Cela vous donne :
Confidentialité totale : vos invites et vidéos générées ne sont pas transmises aux serveurs d’autres personnes.
Contrôle : vous pouvez expérimenter la fréquence d’images (FPS), la résolution et la force de l’invite sans avoir à payer pour chaque tentative.

La génération vidéo locale est toujours en développement actif et LTX-2.3 constitue une excellente entrée dans le monde du « home Hollywood ».

Liens

https://github.com/comfyanonymous/ComfyUI
https://huggingface.co/Lightricks/LTX-Video

Redirection de port entre clients via Chisel : un tunnel épuré sans L3

Lorsque deux appareils sont derrière un NAT ou un pare-feu strict et ne peuvent pas se « voir » directement, un VPN semble être la solution standard. Mais un tunnel L3 à part entière (comme WireGuard ou OpenVPN) est souvent redondant : il nécessite des droits root, la configuration d’interfaces virtuelles et peut entrer en conflit avec les routes existantes.

Dans de tels cas, il est pratique d’utiliser Chisel – un tunnel TCP/UDP qui s’exécute sur HTTP et utilise WebSockets pour le transfert de données. Dans cette note, je vais montrer comment « transférer » un port d’un client à un autre via un serveur intermédiaire.

Comment ça marche ?

Imaginez la situation : vous disposez d’un Client A (par exemple, votre serveur domestique), d’un Client B (votre ordinateur portable de travail) et d’un VPS avec une adresse IP publique. Les clients A et B peuvent accéder au VPS, mais pas l’un à l’autre.

Le schéma de transfert ressemblera à ceci :
1. Le Client A se connecte au VPS et ouvre un port « inverse » sur le serveur. Désormais, tout ce qui arrive au port X du serveur va au port Y du client A.
2. Le Client B se connecte au VPS et transfère le port Z de sa machine locale vers le port X du serveur.
3. En conséquence, le client B accède à localhost:Z et se retrouve sur le client A:Y.

Cette approche est l’une des solutions dans les cas où la communication avec un VPS n’implémente pas la couche L3 ou où il n’y a pas de possibilité de configurer le routage entre les clients. Nous travaillons exclusivement au niveau applicatif et portuaire.

Étape 1 : Démarrez le serveur

Sur votre VPS, exécutez simplement Chisel en mode serveur. L’indicateur --reverse est requis pour permettre aux clients d’ouvrir des ports côté serveur.

chisel server --port 8080 --reverse

Étape 2 : Connexion du client A (source)

Disons que le client A souhaite ouvrir l’accès à son serveur Web local sur le port 3000. Il se connecte au VPS et dit : « réservez le port 2000 sur le serveur et transmettez-le-moi au 3000 ».

chisel client vps-ip:8080 R:2000:127.0.0.1:3000

Désormais, le port 2000 sur le VPS (sur l’interface de bouclage) mène au client A.

Étape 3 : Connexion du client B (consommateur)

Le client B souhaite désormais accéder à cette ressource. Il se connecte au même VPS et redirige son port local 8080 vers le port 2000 du serveur.

chisel client vps-ip:8080 8080:127.0.0.1:2000

Prêt! Désormais, lorsque vous ouvrez http://localhost:8080 sur le client B, vous verrez le service s’exécuter sur le client A.

Sécurité et nuances

Chisel prend en charge l’authentification via l’indicateur --auth, qui est fortement recommandé lorsque vous travaillez via des serveurs publics. Vous pouvez également utiliser des certificats TLS pour chiffrer le trafic.

Le principal avantage de cette approche est qu’elle ne nécessite pas de périphériques TUN/TAP ni de tables de routage complexes. Il s’agit d’un tunnel simplifié qui fait exactement une chose : lier les ports via une connexion WebSocket. Cela fonctionne même via des proxys d’entreprise si vous configurez Chisel pour qu’il fonctionne via le port 443.

Sortie

Chisel est un utilitaire pour des tâches réseau spécifiques. Lorsque vous devez transférer des ports entre des nœuds isolés sans configurer un VPN à part entière, une combinaison de tunnels aller et retour via un serveur relais s’avère être une solution tout à fait viable.

Liens

https://github.com/jpillora/chisel

Codage Vibe local : LM Studio, VS Code et Continuer

Si vous souhaitiez utiliser des réseaux de neurones pour vous aider à écrire du code (appelé codage Vibe) et que vous disposez d’un ordinateur assez puissant, par exemple avec une carte vidéo Nvidia RTX, alors vous pouvez déployer l’ensemble de l’environnement absolument gratuitement sur votre machine. Cela résout les problèmes liés aux abonnements payants et vous permet de travailler en toute sécurité avec des projets sous NDA, puisque votre code n’est envoyé nulle part. Dans cet article, je vais décrire comment assembler un bundle local de LM Studio, VS Code et l’extension Continue.

Outils pour le codage Vibe local

Pour un travail confortable, nous avons besoin de trois composants principaux :
LM Studio : une application pratique pour télécharger et exécuter des LLM locaux. Il prend en charge toute la complexité du travail avec les modèles GGUF et met en place un serveur local compatible avec l’API OpenAI.
VS Code : un éditeur de code populaire et familier.
Continuer : extension pour VS Code qui intègre les réseaux de neurones directement dans l’environnement de travail. Vous permet de discuter, de mettre en évidence le code pour la refactorisation et de prendre en charge la saisie semi-automatique.

Exigences matérielles

Les modèles de langage local sont gourmands en mémoire :
Carte vidéo (GPU) : Nvidia avec 8 Go de VRAM ou plus (pour un travail confortable avec des modèles avec 7 à 8 milliards de paramètres). Les modèles plus lourds nécessiteront 16 Go de VRAM.
Espace disque : environ 500 Go pour stocker les différents modèles téléchargés.

Configurer le lien

Le processus de configuration est assez simple et ne nécessite pas de manipulations complexes dans le terminal :
1. Téléchargez et installez LM Studio. Utilisez la recherche intégrée pour trouver un modèle léger tel que Qwen Coder ou gemma3:12b.
2. Dans LM Studio, accédez à l’onglet Serveur local et cliquez sur Démarrer le serveur. Par défaut, il démarrera sur `http://localhost:1234/v1`.
3. Ouvrez VS Code et installez l’extension Continuer à partir du magasin de plugins.
4. Ouvrez le fichier de configuration Continue et ajoutez un nouveau modèle, en spécifiant le fournisseur `openai` et l’adresse de votre serveur local depuis LM Studio.

Vous pouvez ensuite communiquer avec votre LLM local directement dans la barre latérale Continuer, poser des questions sur votre code et générer de nouveaux composants.

Pourquoi est-ce que ça marche ?

Comme je l’ai écrit plus tôt, les LLM réussissent mieux avec une structure plate et du code WET (Write Everything Twice). Les modèles de paramètres locaux peuvent être inférieurs aux géants comme GPT-4 lorsqu’il s’agit de concevoir des architectures complexes, mais ils sont plus que capables de générer du code passe-partout, de refactoriser des fonctions simples et de réaliser un prototypage rapide.

De plus, grâce au codage Vibe local, votre code ne quitte jamais la machine. Cela rend cette combinaison idéale pour le développement d’entreprise et le travail avec des données sensibles.

Sortie

Les réseaux de neurones locaux ne sont pas capables de remplacer complètement un programmeur ou de concevoir un système complexe. Cependant, la combinaison de LM Studio + VS Code + Continue offre une indépendance par rapport aux services cloud et préserve la confidentialité. Il s’agit d’un outil auxiliaire entièrement fonctionnel pour les tâches de routine, si vous êtes prêt à supporter les limitations des petits modèles et à contrôler indépendamment l’architecture du projet.

Liens

https://code.visualstudio.com/
https://lmstudio.ai/
https://continue.dev/

Sources

https://youtu.be/IqqCwhG46jY
https://www.youtube.com/watch?v=7AImkA96mE8

Génération de musique locale : modèle ComfyUI et ACE-Step-1.5

De nos jours, vous n’avez plus besoin de recourir aux services cloud pour créer du contenu : vous pouvez générer de la musique de haute qualité entièrement sur votre propre matériel. Dans cet article, je vais décrire comment exécuter le modèle ACE-Step-1.5 moderne localement sur votre ordinateur à l’aide de ComfyUI.

ComfyUI utilise une architecture basée sur les nœuds. Cela vous permet de :
– Contrôlez totalement chaque étape de la génération audio.
– Partagez facilement des « workflows » prêts à l’emploi.

ACE-Step-1.5 est un modèle avancé de génération de musique qui nécessite des ressources informatiques importantes. Les exigences matérielles sont supérieures à celles de nombreux synthétiseurs simples :
Carte vidéo (GPU) : Nvidia RTX avec 8 Go de VRAM ou plus (12 Go+ recommandés) pour un travail confortable et de haute qualité.
Mémoire vive (RAM) : minimum 16 Go (de préférence 32 Go et plus).
Processeur (CPU) : Processeur multicœur moderne avec une bonne prise en charge de l’informatique AVX/CUDA.
Espace disque : environ 20 à 50 Go pour les modèles et les composants.

Le moyen le plus simple d’exécuter ACE-Step-1.5 consiste à utiliser un modèle de génération audio prêt à l’emploi. Recherchez simplement le texte musical en audio dans la fenêtre des flux de travail et installez-le.

Écrivez une invite décrivant le genre et l’ambiance (par exemple, « piste synthwave inspirante avec des basses lourdes ») dans le nœud « Prompt Input ». Précisez la durée souhaitée et appuyez sur RUN.
La première génération peut prendre du temps, car les modèles seront chargés dans la mémoire de la carte vidéo et traiteront des modèles acoustiques complexes.

https://github.com/comfyanonymous/ComfyUI
https://www.youtube.com/watch?v=UAlLD5fS7-c

Raspberry PI 3 comme routeur Wi-Fi

Il existe de nombreux articles sur Internet sur la façon de créer un routeur Wi-Fi à partir d’un Raspberry Pi (RPI), dans cet article je vais décrire brièvement ma méthode de création d’un routeur Wi-Fi avec une sing-box à bord. La méthode décrite fonctionne actuellement et beaucoup de choses pourraient changer à l’avenir. Utilisez donc cette note comme un aperçu approximatif de ce à quoi vous serez confronté.

SSH

Pour ceux qui ne savent pas travailler avec OpenWrt, je recommande d’installer dietPI.
Connectez RPI à votre routeur actuel via eth0, puis connectez-vous-y via SSH. Vous pouvez connaître l’adresse IP RPI dans le panneau DHCP du routeur. Connectez-vous directement à root, par exemple comme ceci :

ssh root@[IP_ADDRESS]

Point d’accès

Le mot de passe dietPI par défaut pour root est dietpi. Une fois connecté, vous serez accueilli par l’installateur/configurateur dietPI. Une fois terminé, vous devrez vous reconnecter en raison du redémarrage de l’appareil.

Tout d’abord, vous devez configurer hostapd afin que les appareils puissent voir votre point d’accès. Si hostapd n’est pas installé, installez-le via apt.

Ensuite, vous devrez écrire une configuration pour hostapd. Exemple de ma config :

interface=wlan0
driver=nl80211
ssid=MyPiAP
hw_mode=a
channel=157
wmm_enabled=1

auth_algs=1
wpa=2
wpa_passphrase=your_password
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
ieee80211n=1
ieee80211ac=0
ieee80211ax=0
country_code=RU

La signification de la configuration hostapd peut être trouvée dans le manuel. Cependant, ce qui est important est de le configurer vous-même – le canal (2,4 GHz ou 5 GHz), le code du pays, sinon sans cela, vos appareils localisés peuvent fonctionner correctement avec le point d’accès, je l’ai déjà fait et je le sais, alors assurez-vous de définir votre pays.

DHCP

Ensuite, installez et configurez dnsmasq pour implémenter DHCP. Ceci est nécessaire pour que les ordinateurs connectés déterminent l’adresse IP et le serveur DNS.
Exemple de ma config :

interface=wlan0
dhcp-range=172.19.0.10,172.19.0.200,255.255.255.0,12h

dhcp-option=3,172.19.0.1

dhcp-option=6,1.1.1.1,8.8.8.8

no-resolv

server=1.1.1.1
server=8.8.8.8

C’est la configuration minimale qui vous permettra de vous connecter à un point d’accès et d’obtenir une adresse IP. Ensuite, vous devrez configurer le routage et le NAT. Cela est nécessaire pour que les ordinateurs connectés puissent accéder à Internet.

Ici, la note entre dans la catégorie des configurations de routage typiques sur un système compatible Debian classique, sur lesquelles il existe de nombreux articles sur Internet. Ensuite, tout dépend des objectifs que vous poursuivez, par exemple, vous connecter à un serveur externe en tant que nouvelle interface dans le système, ou simplement faire wlan0 <-> eth0, c’est là que se terminent les spécificités du RPI, puis configurez-le à votre goût.

Je voudrais également mentionner la nécessité de configurer des services système personnalisés via systemctl ; il peut être nécessaire de connecter les services en chaîne ; tout cela est dans les manuels systemctl sur le réseau. S’il y a des problèmes au niveau du service, vérifiez les journaux dans journalctl.

Adaptateur Wi-Fi

Le RPI3 intégré s’est avéré franchement faible et ne prend pas en charge 5 GHz. J’ai donc connecté l’adaptateur RITMIX RWA-150 sur le chipset Realtek RTL8811CU via USB 2. Les pilotes ont été ajoutés au noyau Linux qui se trouvait dans ma version dietPi. Ensuite, en utilisant dietpi-config, j’ai complètement désactivé le Wi-Fi intégré. En conséquence, il ne restait qu’un seul adaptateur USB wlan0.

Conclusion

À partir des mesures de vitesse, nous avons pu extraire environ 50 Mbps du RPI3 via Wi-Fi (après avoir connecté un adaptateur 5 GHz), ce qui signifie une perte de moitié de la vitesse par rapport à une connexion directe au routeur. J’admets que des modèles RPI plus productifs vous permettront d’obtenir de meilleurs résultats, et que les appareils OpenWrt spécialisés et les solutions prêtes à l’emploi peuvent également être mieux adaptés à vos besoins.

Sources

https://forums.raspberrypi.com/viewtopic.php?t=394710
https://superuser.com/questions/1408586/raspberry-pi-wifi-hotspot-slow-internet-speed
https://www.youtube.com/watch?v=jlHWnKVpygw

Génération d’images locales : modèle ComfyUI et FLUX

De nos jours, vous n’avez plus besoin de recourir aux services cloud : vous pouvez générer des images de haute qualité entièrement sur votre propre matériel. Dans cet article, je vais décrire comment exécuter le modèle FLUX moderne localement sur votre ordinateur à l’aide de ComfyUI.

ComfyUI utilise une architecture basée sur les nœuds. Cela vous permet de :
– Contrôlez totalement chaque étape de la génération.
– Partagez facilement des « workflows » prêts à l’emploi

FLUX est un grand modèle, la configuration matérielle requise est donc supérieure à celle de SD 1.5 ou SDXL :
Carte vidéo (GPU) : Nvidia RTX avec 12 Go de VRAM ou plus (pour un travail confortable). Si vous disposez de 8 Go ou moins, vous devrez utiliser les versions quantifiées (GGUF ou NF4).
Mémoire vive (RAM) : minimum 16 Go (de préférence 32 Go et plus).
Espace disque : environ 20 à 50 Go pour les modèles et les composants.

Le moyen le plus simple de démarrer FLUX est d’utiliser un modèle prêt à l’emploi. Recherchez simplement le texte de flux à image dans la fenêtre des flux de travail et installez-le.

Écrivez une invite en anglais dans le nœud « Text to Image (Flux.1 Dev) », sélectionnez la résolution (FLUX fonctionne bien avec 1024 x 1024 et même plus) et appuyez sur RUN.

La première génération peut prendre du temps car les modèles seront chargés dans la mémoire de la carte vidéo.

https://github.com/comfyanonymous/ComfyUI

Mars Mineurs v2

[Pause : Service d’information interplanétaire Red Horizon]

ANIMATEUR : Bonne nuit, Mars ! Le principal service d’information du Dôme est à vos côtés. Aujourd’hui, l’administration de la colonie Mars Miners a annoncé une mise à jour logicielle à grande échelle pour tous les colons et modules stratégiques.

PRINCIPAUX ÉVÉNEMENTS :

1. Mise à jour des circuits neuronaux des automates Le Département de Cybernétique a confirmé la mise à jour réussie de toutes les unités minières autonomes. Les nouveaux protocoles de réflexion stratégique éliminent les erreurs critiques dans la logique du développement. Désormais, la simulation de la concurrence pour les ressources deviendra encore plus imprévisible et difficile. Les colons peuvent définir indépendamment des délais d’analyse tactique pour leurs partenaires IA.

2. Intégration de terrains d’entraînement virtuels Les colons nouvellement arrivés ont accès à des simulateurs d’entraînement personnels. Vous pouvez désormais perfectionner vos compétences en matière de capture de secteur en mode solo avant de vous lancer dans le véritable combat pour les mines martiennes. Le système est équipé de protocoles de formation mis à jour.

3. Stabilisation des canaux de communication entre les dômes Les ingénieurs en communication ont terminé l’étalonnage de la constellation de satellites. L’interface d’interaction multijoueur entre avant-postes distants fonctionne désormais sans délai. Les anomalies qui entraînaient des interruptions de connexion lors d’opérations stratégiques ont été éliminées.

4. Calcul subconscient : mise à jour des déclencheurs neuronaux Le service technique a mis en place un système informatique parallèle. Le traitement des données tactiques de l’IA s’effectue désormais en arrière-plan, sans solliciter le CPU de vos terminaux personnels. Fini les pauses lors des phases critiques du jeu.

HÔTE : L’administration vous rappelle que la nouvelle version des simulateurs de jeux a déjà été chargée dans le terminal central. Pour synchroniser les données, il est recommandé de redémarrer vos interfaces locales.

L’avenir de Mars est entre vos mains. Restez avec nous sur la fréquence Red Horizon.

https://demensdeum.com/games/mars-miners/

Exécuter macOS dans Docker

Il est possible d’exécuter macOS dans Docker, malgré les objections de ceux qui disent que c’est impossible, et apparemment macOS dispose d’une sorte de système de protection qui peut résister à cela.

Certaines des méthodes classiques d’exécution de macOS sur des machines PC ont été historiquement :
*Hackintosh
* Virtualisation, par exemple à l’aide de VMWare

Hackintosh suppose la présence d’un matériel similaire ou très proche du Mac d’origine. La virtualisation impose certaines exigences en matière de matériel, mais généralement pas aussi strictes que dans le cas de Hackintosh. Cependant, dans le cas de la virtualisation, il existe des problèmes de performances, car macOS n’est pas optimisé pour travailler dans un environnement virtuel.

Récemment, il est devenu possible d’exécuter macOS dans Docker. Ceci est rendu possible par le projet Docker-OSX, qui fournit des images macOS prêtes à l’emploi à exécuter sur Docker. Il convient de noter que Docker-OSX n’est pas un projet Apple officiel et n’est pas pris en charge par celui-ci. Cependant, il vous permet d’exécuter macOS sur Docker et de l’utiliser pour développer et tester des applications.

L’un des premiers projets à exécuter macOS dans Docker :
https://github.com/sickcodes/Docker-OSX

Cependant, je n’ai jamais pu le lancer complètement ; après le chargement dans Recovery OS, mon clavier et ma souris sont tout simplement tombés et je n’ai pas pu continuer l’installation. En même temps, dans le premier menu de démarrage, le clavier fonctionne. Le fait est peut-être que ce projet n’est plus aussi activement pris en charge et qu’il existe des problèmes spécifiques lors de l’exécution sous Windows 11 + WSL2 + Ubuntu.

Un des projets les plus actifs en ce moment :
https://github.com/dockur/macos

Vous permet d’exécuter macOS dans Docker, l’interface fonctionne via le navigateur via le transfert VNC (?). Après le démarrage, macOS est disponible sur http://localhost:5900

J’ai réussi à exécuter ce projet et à installer macOS Big Sur (minute 2020) sur Windows 11 + WSL2 + Ubuntu, mais uniquement en modifiant le fichier de composition, à savoir :

environment:
    VERSION: "11"
    RAM_SIZE: "8G"
    CPU_CORES: "4"

VERSION : “11” est la version de macOS, dans ce cas Big Sur
RAM_SIZE : “8G” est la quantité de RAM allouée pour macOS
CPU_CORES : “4” est le nombre de cœurs de processeur alloués à macOS

Pour le moment, exécuter macOS tahoe (16) est également possible, mais il existe un certain nombre de problèmes que les développeurs du projet tentent de résoudre vaillamment.

Cette manière originale de lancer macOS vous permet de l’essayer sur votre matériel non Mac et, après avoir assez souffert, d’aller vous acheter un Mac. Cependant, cela peut être utile pour tester des logiciels sur des systèmes plus anciens et pour le développement général.

Construire Swift dans WSL2 (Linux)

L’écosystème Swift se développe activement en dehors des plates-formes Apple, et il est aujourd’hui assez confortable d’y écrire sous Windows à l’aide du sous-système Windows pour Linux (WSL2). Il convient de noter que pour les assemblys sous Linux/WSL, une version allégée de Swift est disponible – sans frameworks propriétaires Apple (tels que SwiftUI, UIKit, AppKit, CoreData, CoreML, ARKit, SpriteKit et autres bibliothèques spécifiques à iOS/macOS), mais pour les utilitaires de console et le backend, cela est plus que suffisant. Dans cet article, nous allons parcourir étape par étape le processus de préparation de l’environnement et de construction du compilateur Swift à partir du code source dans WSL2 (en utilisant Ubuntu/Debian comme exemple).

Nous mettons à jour la liste des packages et le système lui-même :

sudo apt update && sudo apt upgrade -y

Installez les dépendances nécessaires pour le build :

sudo apt install -y \
  git cmake ninja-build clang python3 python3-pip \
  libicu-dev libxml2-dev libcurl4-openssl-dev \
  libedit-dev libsqlite3-dev swig libncurses5-dev \
  pkg-config tzdata rsync

Installez le compilateur et l’éditeur de liens (LLVM et LLD) :

sudo apt install -y llvm lld

Clonez le dépôt Swift avec toutes les dépendances :

git clone https://github.com/apple/swift.git
cd swift
utils/update-checkout --clone

Installez Swiftly et prêt à l’emploi avec Swiftc

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

Commençons la construction (cela prendra beaucoup de temps) :

utils/build-script \
  --release-debuginfo \
  --swift-darwin-supported-archs="x86_64" \
  --llvm-targets-to-build="X86" \
  --skip-build-benchmarks \
  --skip-test-cmark \
  --skip-test-swift \
  --skip-ios \
  --skip-tvos \
  --skip-watchos \
  --skip-build-libdispatch=false \
  --skip-build-cmark=false \
  --skip-build-foundation \
  --skip-build-lldb \
  --skip-build-xctest \
  --skip-test-swift

Une fois la construction terminée, ajoutez le chemin d’accès au compilateur à PATH (spécifiez votre chemin d’accès au dossier de construction) :

export PATH=/root/Sources/3rdparty/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc:$PATH

Nous vérifions que la version installée de Swift fonctionne :

swift --version

Créez un fichier de test et exécutez-le :

echo "print(\"Hello, World!\")" > hello.swift
swift hello.swift

Vous pouvez également compiler le binaire et l’exécuter :

swiftc hello.swift
./hello

Sources

Téflécher

Teflecher est une application de quiz multiplateforme rapide, interactive, construite sur Kotlin Multiplatform (KMP) et Compose Multiplatform. Il permet aux utilisateurs de charger intuitivement des quiz à partir de fichiers JSON locaux ou d’URL distantes, de répondre à des questions à choix multiples, d’afficher des commentaires instantanés sur les réponses correctes et de suivre leurs résultats.

Internet :
https://demensdeum.com/software/teflecher/

GitHub :
https://github.com/zefir1990/teflecher

Egalement un éditeur de quiz au format Teflecher Editor basé sur les technologies Ionic + Capacitor

Internet :
https://demensdeum.com/software/teflecher-editor/

GitHub :
https://github.com/zefir1990/teflecher-editor

Interprète de modèles en pratique

Dans le dernier article, nous avons examiné la théorie du modèle Interpreter, appris ce qu’est un arbre AST et comment faire abstraction des expressions terminales et non terminales. Cette fois, éloignons-nous de la théorie et voyons comment ce modèle est appliqué dans des projets commerciaux sérieux que nous utilisons tous au quotidien !

Spoiler : Vous utilisez peut-être le modèle Interpreter en ce moment, simplement en lisant ce texte dans votre navigateur !

L’un des exemples les plus frappants et, peut-être, les plus importants de l’utilisation de ce modèle dans l’industrie est JavaScript. Le langage, qui a été créé à l’origine « sur le genou », fonctionne aujourd’hui sur des milliards d’appareils précisément grâce au concept d’interprétation.

10 jours qui ont changé Internet

L’histoire de JavaScript est pleine de légendes. En 1995, Brendan Eich, alors qu’il travaillait chez Netscape Communications, s’est vu confier la tâche de créer un langage de script simple pouvant s’exécuter directement dans un navigateur (Netscape Navigator) pour rendre les pages Web interactives. La direction voulait quelque chose avec une syntaxe similaire à Java alors très populaire, mais destiné non pas aux ingénieurs professionnels, mais aux concepteurs Web.

Eich n’a eu que 10 jours pour écrire le premier prototype du langage, qui s’appelait alors Mocha (puis LiveScript, et seulement ensuite JavaScript pour des raisons marketing). Cette ruée n’était pas fortuite : Microsoft était sur ses talons, qui préparait en même temps activement son propre langage de script VBScript à intégrer dans le navigateur Internet Explorer. Netscape devait de toute urgence publier sa réponse afin de ne pas perdre dans la guerre imminente des navigateurs.

Nous n’avions tout simplement pas le temps d’écrire un compilateur complexe en code machine. La solution évidente et la plus rapide pour Eich était l’architecture du classique Interpreter.

Le premier interprète (SpiderMonkey) fonctionnait comme ceci :

  1. Il lit le code source du texte du script à partir de la page.
  2. L’analyseur lexical a divisé le texte en jetons.
  3. L’analyseur a construit un arbre de syntaxe abstraite (AST). En termes de modèle Interpreter, cet arbre se composait d’expressions terminales (chaînes, nombres comme 42) et de non-terminaux (appels de fonction, instructions comme If, ​​​​While).
  4. Ensuite, la machine virtuelle a « parcouru » cet arbre étape par étape, exécutant les instructions qui y sont intégrées à chaque nœud (en appelant une méthode similaire à Interpret()).

Contexte et objets

Vous vous souvenez de l’objet Context que nous avons dû passer à la méthode Interpret(Context context) dans l’implémentation classique ? L’interpréteur en a besoin pour stocker l’état actuel de la mémoire.

Dans le cas de JavaScript, le rôle de ce contexte au niveau supérieur est joué par un Objet global (par exemple, une fenêtre dans un navigateur). Lorsque votre nœud AST essaie, par exemple, d’écrire du texte à l’écran via document.write(“Hello”), l’interpréteur accède à son contexte (l’objet document) et appelle l’API interne du navigateur souhaitée.

C’est grâce à l’interpréteur que JavaScript est capable d’interagir si facilement avec le DOM (Document Object Model) – ce ne sont que des objets dans un contexte accessibles par les nœuds de l’arborescence.

Évolution de l’interpréteur : Compilation JIT

Historiquement, JS dans les navigateurs est longtemps resté un « pur » interprète. Et cela avait un gros inconvénient : une vitesse lente. L’analyse de l’arborescence et la traversée lente de chaque nœud à chaque fois que le script était exécuté ralentissaient les applications Web complexes.

Avec l’avènement du moteur V8 de Google (intégré à Chrome) en 2008, une révolution s’est produite. Les ingénieurs ont réalisé qu’un seul interprète ne suffisait pas pour le Web moderne. Le moteur est devenu plus complexe : il construit toujours l’arborescence AST, mais utilise désormais la compilation JIT (Just-In-Time).

Les moteurs JS modernes (V8, SpiderMonkey) fonctionnent comme un pipeline complexe :

  1. L’interpréteur de base rapide et stupide commence à exécuter votre code JS instantanément, sans même attendre sa compilation (le modèle classique fonctionne toujours ici).
  2. En parallèle, le moteur surveille les sections de code « chaudes » (boucles ou fonctions appelées des milliers de fois).
  3. Ces sections sont compilées par le compilateur JIT directement dans un code machine optimisé, en contournant l’interpréteur lent.

C’est cette combinaison du démarrage instantané de l’interpréteur et de la puissance de calcul de la compilation qui a permis à JavaScript de conquérir le monde, devenant le langage des serveurs (Node.js) et des applications mobiles (React Native).

Interprète dans l’industrie du jeu vidéo

Malgré la domination du C++ dans l’informatique lourde, le modèle Interpreter est une norme industrielle en matière de développement de jeux pour la création de logique de jeu. Pour quoi? Pour que les concepteurs de jeux puissent créer des jeux sans risquer de « laisser tomber » le moteur ou sans avoir besoin de le recompiler constamment.

Un excellent exemple historique est UnrealScript – le langage dans lequel la logique des jeux Unreal Tournament et Gears of War a été écrite dans Unreal Engine 1, 2 et 3. Le texte a été compilé en bytecode compact et abstrait, qui a ensuite été (interprété) étape par étape par la machine virtuelle du moteur.

Scripts de graphiques visuels (Blueprints)

Aujourd’hui, le texte a été remplacé par une programmation visuelle – le système Blueprints dans Unreal Engine 4 et 5.

Si vous avez déjà ouvert un Blueprint dans Unreal Engine, vous avez vu de nombreux nœuds connectés par des fils. Sur le plan architectural, l’ensemble du graphique Blueprints est un immense arbre de syntaxe abstraite (AST) dessiné à l’écran :

  1. Expressions terminales : Nœuds constants. Par exemple, un nœud qui stocke simplement le nombre 42 ou une chaîne. Ils renvoient une valeur spécifique lorsqu’ils sont interprétés.
  2. Expressions non-terminales : nœuds de calcul (Ajouter) ou nœuds de contrôle de flux (Branche). Ils ont des entrées d’arguments, que l’interpréteur évalue d’abord de manière récursive avant de produire le résultat sous forme de broche de sortie.

Et le rôle de contexte ici est joué par la mémoire d’une instance d’un objet de jeu spécifique (acteur). La machine d’interprétation « parcourt » ce graphique en toute sécurité, demandant des données et effectuant des transitions.

Où d’autre l’interprète est-il utilisé ?

Le modèle d’interpréteur peut être trouvé dans presque tous les systèmes complexes où des instructions dynamiques doivent être exécutées. Voici quelques exemples de logiciels commerciaux :

  • Langages de programmation interprétés (Python, Ruby, PHP). L’ensemble de leur exécution est basé sur le modèle classique. Par exemple, l’implémentation de référence CPython analyse d’abord votre script .py dans un AST, le compile en bytecode, puis une énorme machine virtuelle (boucle de calcul) interprète ce bytecode étape par étape.
  • Machine virtuelle Java (JVM). Initialement, le code Java n’est pas compilé en instructions machine, mais en bytecode. Lorsque vous exécutez l’application, la JVM agit comme un interprète (mais avec une compilation JIT agressive, tout comme dans la V8).
  • Bases de données et SQL Lorsque vous émettez une requête SQL (utilisateurs SELECT * FROM) dans PostgreSQL ou MySQL, le moteur de base de données agit comme un interpréteur. Il effectue une analyse lexicale, construit un arbre de requêtes AST, génère un plan d’exécution, puis « interprète » littéralement ce plan en itérant sur les lignes des tables.
  • Expressions régulières (RegEx). Tout moteur d’expression régulière analyse en interne un modèle de chaîne (par exemple, ^\d{3}-\d{2}$) dans un graphe d’état (NFA/DFA Automata), que l’interpréteur interne traverse ensuite, en faisant correspondre chaque caractère d’entrée avec les sommets de ce graphe.
  • Unity Shader Graph / Unreal Material Editor – interprète les nœuds visuels dans un code de shader modulaire (GLSL/HLSL).
  • Nœuds géométriques Blender : interprètez les opérations mathématiques et géométriques pour générer de manière procédurale des modèles 3D en temps réel.

Total

Le modèle Interpreter a depuis longtemps dépassé le cadre de « l’écriture de votre propre calculatrice ». Il s’agit de la norme industrielle la plus puissante. Des moteurs JavaScript qui exécutent chaque jour des gigaoctets de code dans les coulisses des navigateurs, aux concepteurs de jeux qui vous permettent de créer une logique complexe sans connaissance du C++, les interpréteurs restent l’un des concepts architecturaux les plus importants du développement informatique moderne.

Glazki TV : lecteur moderne pour la télévision sur Internet

Glazki TV est un lecteur moderne et performant pour la télévision sur Internet (IPTV), construit sur la base de React Native et Expo. Le projet se concentre sur la facilité d’utilisation et la rapidité, en fournissant une interface pratique pour visualiser les chaînes IPTV à la fois sur les appareils mobiles et dans le navigateur.

Principales fonctionnalités

  • 📺 Navigation des chaînes : parcourez des milliers de chaînes, classées par catégories pour une navigation facile.
  • 🔍 Rechercher : trouvez rapidement les chaînes dont vous avez besoin par leur nom.
  • ❤️ Favoris : enregistrez vos chaînes préférées pour un accès rapide (données enregistrées localement).
  • 🔗 Deep Linking : Partagez des liens directs vers des chaînes qui s’ouvrent automatiquement.
  • 🌓 Prise en charge du thème : L’interface s’adapte automatiquement au thème sombre ou clair du système.
  • 🌐 Support Web : Le lecteur est entièrement fonctionnel dans le navigateur avec synchronisation d’URL.

Pile technologique

Le projet s’appuie sur des outils de développement modernes :

  • Framework : React Native + Expo
  • Video Player: expo-video (замена устаревшему expo-av)
  • Boîte à outils d’interface utilisateur : React-Native-paper
  • Analyseur de playlist : iptv-playlist-parser

Version Internet :
https://demensdeum.com/software/glazki-tv/

Version Google Play :
https://play.google.com/store/apps/details?id=com.demensdeum.glazkitv

Le projet continue de se développer et j’apprécierais tout retour !

Flame Steel : Masque de mort 2

In the dim, neon-flickering depths of the digital underworld, a new challenge awaits. We are excited to pull back the curtain on Flame Steel: Death Mask 2, a multiplayer 3D dungeon crawler that blends retro-cyberpunk aesthetics with modern real-time gameplay.

🕹️ What is Flame Steel: Death Mask 2?

Imagine waking up in a procedurally generated maze where every shadow could be another player or a hostile “Filter” entity. Flame Steel: Death Mask 2 puts you in the boots of a Seeker, navigating a world built on the Flame Steel Engine 2 and Three.js.

The game is currently in its early stages of development, but the core experience is already live and ready for exploration.

🚀 Key Features

  • Multiplayer Exploration: You aren’t alone in the grid. See other players in real-time as you navigate the labyrinthine corridors.
  • Procedural Dungeons: No two runs are the same. The server generates fresh maps filled with mystery and danger.
  • The Terminal: For those who prefer a more “hands-on” approach, an integrated command-line interface allows you to interact with the system directly—perform advanced actions, debug, or simply chat with fellow Seekers.
  • Combat & Survival: Face off against Filters to earn bits, then use those bits to unlock Chests and upgrade your stats. Keep an eye on your health; survival isn’t guaranteed.
  • Retro-Cyberpunk Aesthetic: High-contrast visuals and a gritty atmosphere that pays homage to the classic cyberpunk era.

🛠️ The Tech Behind the Mask

Built for the browser, the game leverages:

  • Frontend: Vanilla JavaScript and Three.js for smooth 3D rendering.
  • Backend: Node.js and WebSockets (ws) for lightning-fast multiplayer synchronization.
  • Infrastructure: MongoDB for data persistence and Redis for real-time spatial indexing.

🗺️ What’s Next?

We are just getting started. As an early-access project, Death Mask 2 will receive frequent updates, including:

  • New entity types and complex combat mechanics.
  • Deeper lore and environmental storytelling.
  • Enhanced terminal commands and social features.
  • Visual and performance polish.

🔗 Join the Grid

Want to test your mettle? Enter your codename and initialize your identity today:

👉 Play Flame Steel: Death Mask 2

Stay tuned for more updates as we continue to expand the digital frontier. Welcome to the service. It requires you.

Radio Ouchki

Ushki-Radio est un lecteur radio multiplateforme pour la radio en ligne, conçu en mettant l’accent sur la simplicité et le plaisir d’écoute. Pas de fonctions inutiles, pas d’interfaces surchargées : il suffit de l’allumer et d’écouter.


https://demensdeum.com/software/ushki-radio

Le projet utilise le navigateur radio open source, rendant disponibles des milliers de stations de radio du monde entier dans l’application. Vous pouvez les rechercher par nom, genre ou popularité, les ajouter à vos favoris et revenir rapidement à vos stations préférées.

Ushki-Radio est parfait pour le rôle de lecteur radio d’arrière-plan : il mémorise la dernière station, permet de contrôler le volume et ne nécessite pas de réglages complexes. L’interface est concise et compréhensible – tout est fait pour que rien ne détourne l’attention de la musique, des conversations et de la diffusion.

Techniquement, le projet est construit sur React Native et Expo, il fonctionne donc à la fois dans le navigateur et en tant qu’application native. Sous le capot, expo-av est utilisé pour lire l’audio et les paramètres utilisateur sont stockés localement. Plusieurs langues sont prises en charge, dont le russe et l’anglais.

Ushki-Radio est un bon exemple de ce que peut être un lecteur de radio Internet moderne : ouvert, léger, extensible et axé principalement sur l’auditeur. Le projet est distribué sous licence MIT et est parfait à la fois pour un usage personnel et comme base pour vos propres expériences avec des applications audio.

GitHub :
https://github.com/demensdeum/Ushki-Radio

couvreur

Coverseer – observateur de processus intelligent utilisant LLM

Coverseer est un outil Python CLI permettant de surveiller intelligemment et de redémarrer automatiquement les processus. Contrairement aux solutions de surveillance classiques, elle analyse le texte de l’application à l’aide du modèle LLM et prend des décisions basées sur le contexte, et pas seulement sur le code de sortie.

Le projet est open source et disponible sur GitHub :
https://github.com/demensdeum/coverseer

Qu’est-ce que Coverser

Coverseer démarre le processus spécifié, surveille en permanence sa sortie standard et son stderr, transmet les derniers morceaux de sortie au LLM local (via Ollama) et détermine si le processus est dans le bon état d’exécution.

Si le modèle détecte une erreur, un blocage ou un comportement incorrect, Coverseer met automatiquement fin au processus et le redémarre.

Fonctionnalités clés

  • Analyse contextuelle des résultats : au lieu de vérifier le code de sortie, l’analyse des journaux est utilisée à l’aide de LLM
  • Redémarrage automatique : le processus est redémarré lorsque des problèmes ou une interruption anormale sont détectés
  • Travailler avec des modèles locaux – Ollama est utilisé sans transférer de données vers des services externes
  • Journalisation détaillée : toutes les actions et décisions sont enregistrées pour les diagnostics ultérieurs
  • Exécution autonome : peut être regroupée dans un seul fichier exécutable (par exemple, .exe)

Comment ça marche

  1. Coverseer exécute la commande transmise via la CLI
  2. Collecte et met en mémoire tampon le texte généré par le processus
  3. Envoie les dernières lignes au modèle LLM
  4. Obtient une évaluation sémantique de l’état du processus
  5. Si nécessaire, termine et redémarre le processus

Cette approche vous permet d’identifier les problèmes qui ne peuvent pas être détectés par les outils de surveillance standards.

Exigences

  • Python 3.12 ou version ultérieure
  • Ollama installé et en cours d’exécution
  • Modèle chargé gemma3:4b-it-qat
  • Dépendances Python : requests, ollama-call

Utiliser un exemple


python coverseer.py "votre commande ici"

Par exemple, en regardant le modèle Ollama charger :


python coverseer.py "ollama pull gemma3:4b-it-qat"

Coverseer analysera le résultat de la commande et répondra automatiquement aux échecs ou aux erreurs.

Application pratique

Coverseer est particulièrement utile dans les scénarios où les mécanismes de supervision standards sont insuffisants :

  • Pipelines CI/CD et builds automatiques
  • Services et agents d’arrière-plan
  • Processus expérimentaux ou instables
  • Outils avec de grandes quantités de journaux de texte
  • Environnements de développement dans lesquels l’auto-réparation est importante

Pourquoi l’approche LLM est plus efficace

Les systèmes de surveillance classiques réagissent aux symptômes. Coverser analyse le comportement. Le modèle LLM est capable de reconnaître les erreurs, les avertissements, les échecs répétés et les impasses logiques même dans les cas où le processus continue formellement de fonctionner.

Cela rend la surveillance plus précise et réduit le nombre de fausses alarmes.

Conclusion

Coverseer est un exemple clair de l’application pratique du LLM dans les tâches DevOps et d’automatisation. Il développe la compréhension traditionnelle de la surveillance des processus et propose une approche plus intelligente et basée sur le contexte.

Le projet sera particulièrement intéressant pour les développeurs qui expérimentent des outils d’IA et recherchent des moyens d’améliorer la stabilité de leurs systèmes sans compliquer l’infrastructure.

Flame Steel : Mineurs de Mars

Flame Steel : Mars Miners est un jeu de stratégie tactique avec un rythme inhabituel et qui met l’accent sur la prise de décision plutôt que sur les réflexes. Le jeu se déroule sur Mars, où les joueurs s’affrontent pour le contrôle des ressources et des territoires face à des informations limitées et à la pression constante de leurs rivaux.

Le gameplay est basé sur la construction de stations hub qui constituent l’infrastructure de votre expédition. Les nœuds vous permettent d’extraire des ressources, d’étendre votre zone d’influence et de construire une logistique. Chaque placement compte : une erreur peut ouvrir la voie à l’ennemi vers des secteurs clés ou vous priver d’un avantage stratégique.

Le rythme du jeu est volontairement maîtrisé et intense. C’est quelque part entre les échecs, le Go et le combat naval : le positionnement, la prévision des actions de l’adversaire et la capacité à travailler dans l’incertitude sont ici importants. Une partie de la carte et les intentions de l’ennemi restent cachées, le succès dépend donc non seulement du calcul, mais aussi de la lecture de la situation.

Flame Steel : Mars Miners prend en charge le jeu en ligne, ce qui rend chaque jeu unique : les stratégies évoluent et la méta est en train de se former en ce moment. Le jeu est à un stade précoce de développement, et c’est sa force : les joueurs ont la possibilité d’être les premiers à se plonger dans un nouveau projet hors standard, à influencer son développement et à découvrir des mécaniques qui ne copient pas les modèles habituels du genre.

Si vous êtes intéressé par les jeux tactiques avec de la profondeur, une conception expérimentale et un accent sur la réflexion, Flame Steel: Mars Miners vaut le détour maintenant.

RÈGLES DU JEU

* Le terrain de jeu est constitué de cellules sur lesquelles les joueurs placent leurs objets un par un. À chaque tour, un joueur peut effectuer une action de construction.

* Seuls deux types d’objets peuvent être construits : les stations centrales et les mines. Toute construction est possible exclusivement sur une cellule libre située à côté d’un nœud joueur existant verticalement ou horizontalement. Le placement en diagonale n’est pas autorisé.

* Les stations centrales constituent la base du contrôle du territoire et servent de points d’expansion. Les mines sont placées selon les mêmes règles, mais sont considérées comme des objets ressources et affectent directement le résultat final de la partie.

* Si un joueur construit une ligne continue de ses stations-nœuds verticalement ou horizontalement, une telle ligne se transforme automatiquement en arme. L’arme permet d’attaquer l’ennemi et de détruire ses infrastructures.

* Pour tirer avec une arme à feu, le joueur sélectionne une cellule appartenant à son arme et pointe vers n’importe quelle station nodale ennemie sur le terrain. La station nodale ennemie sélectionnée est détruite et retirée du terrain de jeu. Les mines ne peuvent pas être attaquées directement – ​​uniquement en détruisant les nœuds qui y donnent accès.

* Le jeu continue jusqu’à la fin fixée du jeu. Le gagnant est le joueur qui possède à ce moment le plus grand nombre de mines de ressources sur le terrain de jeu. En cas d’égalité, le facteur décisif peut être le contrôle du territoire ou des conditions supplémentaires déterminées par le mode de jeu.

https://mediumdemens.vps.webdock.cloud/mars-miners

Antigravité

En quelques jours, avec l’aide d’Antigravity, j’ai transféré le backend Masonry-AR de PHP + MySQL vers Node.js + MongoDB + Redis -> Docker. Les capacités de l’IA sont vraiment incroyables, je me souviens comment, en 2022, j’ai écrit les shaders les plus simples sur shadertoy.com via ChatGPT et il semblait que ce jouet ne pouvait rien faire de plus.
https://www.shadertoy.com/view/cs2SWm

Quatre ans plus tard, je vois comment, en environ 10 invites, j’ai transféré sans effort mon projet d’une plateforme arrière à une autre, en ajoutant la conteneurisation.
https://mediumdemens.vps.webdock.cloud/masonry-ar/

Cool, vraiment cool.

Tableau Kaban

KabanBoard est une application web open source permettant de gérer des tâches au format Kanban. Le projet est axé sur la simplicité, une architecture compréhensible et la possibilité de modification pour les tâches spécifiques d’une équipe ou d’un développeur individuel.

La solution convient aux petits projets, aux processus d’équipe internes ou comme base de votre propre produit sans être liée à des services SaaS tiers.

Le dépôt du projet est disponible sur GitHub :
https://github.com/demensdeum/KabanBoard

Principales fonctionnalités

KabanBoard implémente un ensemble de fonctions basiques et pratiques pour travailler avec des tableaux Kanban.

  • Créer plusieurs tableaux pour différents projets
  • Structure de colonnes avec statuts de tâches
  • Fiches de tâches avec possibilité de modification et de suppression
  • Déplacer des tâches entre les colonnes (glisser-déposer)
  • Codage couleur des cartes
  • Thème d’interface sombre

La fonctionnalité n’est pas surchargée et se concentre sur le travail quotidien avec des tâches.

Technologies utilisées

Le projet est construit sur une pile commune et compréhensible.

  • Frontend :Vue 3, Vite
  • Backend : Node.js, Express
  • Stockage des données : MongoDB

Les parties client et serveur sont séparées, ce qui simplifie le support et le développement ultérieur du projet.

Déploiement du projet

Pour exécuter localement, vous aurez besoin d’un environnement standard.

  • Node.js
  • MongoDB (localement ou via le cloud)

Le projet peut être lancé soit en mode normal via npm, soit à l’aide de Docker, ce qui est pratique pour un déploiement rapide dans un environnement de test ou interne.

Application pratique

KabanBoard peut être utilisé dans différents scénarios.

  • Outil de gestion des tâches interne
  • Base d’une solution Kanban personnalisée
  • Projet de formation pour étudier l’architecture des SPA
  • Point de départ d’un projet ou d’un portfolio préféré

Conclusion

KabanBoard est une solution soignée et pratique pour travailler avec des tableaux Kanban. Le projet ne prétend pas remplacer les grands systèmes d’entreprise, mais est bien adapté aux petites équipes, à une utilisation individuelle et à un développement ultérieur pour des tâches spécifiques.

Gofis

Gofis est un outil de ligne de commande léger permettant de rechercher rapidement des fichiers dans le système de fichiers.
Il est écrit en Go et utilise beaucoup le parallélisme (goroutines), ce qui le rend particulièrement efficace.
lorsque vous travaillez avec de grands répertoires et projets.

Le projet est disponible sur GitHub :
https://github.com/demensdeum/gofis

🧠 Qu’est-ce que Gofis

Gofis est un utilitaire CLI permettant de rechercher des fichiers par nom, extension ou expression régulière.
Contrairement aux outils classiques comme find, gofis a été initialement conçu
en mettant l’accent sur la vitesse, la sortie lisible et le traitement parallèle des répertoires.

Le projet est distribué sous licence MIT et peut être utilisé librement
à des fins personnelles et commerciales.

⚙️ Principales fonctionnalités

  • Parcours de répertoires parallèles à l’aide de goroutines
  • Recherche par nom de fichier et expressions régulières
  • Filtrage par extensions
  • Ignorer les répertoires lourds (.git, node_modules, supplier)
  • Sortie lisible des tailles de fichiers
  • Dépendances minimales et construction rapide

🚀Installation

Nécessite Go installé pour fonctionner.

git clone https://github.com/demensdeum/gofis
cd gofis
go build -o gofis main.go

Une fois construit, le binaire peut être utilisé directement.

Il existe également une version autonome pour les versions modernes de Windows sur la page des versions :
https://github.com/demensdeum/gofis/releases/

🔍 Exemples d’utilisation

Rechercher des fichiers par nom :

./gofis -n "config" -e ".yaml" -p ./src

Recherche de position rapide :

./gofis "main" "./projects" 50

Recherche à l’aide d’une expression régulière :

./gofis "^.*\.ini$" "/"

🧩 Comment ça marche

Gofis s’appuie sur le modèle concurrentiel de Go :

  • Chaque répertoire est traité dans une goroutine distincte
  • Utilise un sémaphore pour limiter le nombre de tâches actives
  • Les canaux sont utilisés pour transmettre les résultats de recherche

Cette approche permet une utilisation efficace des ressources CPU
et accélère considérablement la recherche dans les arborescences de fichiers volumineux.

👨‍💻 À qui convient Gofis ?

  • Développeurs travaillant avec de grands dépôts
  • DevOps et administrateurs système
  • Utilisateurs ayant besoin d’une recherche rapide depuis le terminal
  • Pour ceux qui apprennent les utilisations pratiques de la simultanéité dans Go

📌Conclusion

Gofis est un outil simple mais efficace qui fait une chose et la fait bien.
Si vous recherchez souvent des fichiers dans des projets volumineux et que vous appréciez la vitesse,
cet outil CLI vaut vraiment le détour.

appel ollama

Si vous utilisez Ollama et que vous ne souhaitez pas écrire votre propre wrapper API à chaque fois,
le projet ollama_call simplifie considérablement le travail.

Il s’agit d’une petite bibliothèque Python qui vous permet d’envoyer une requête à un LLM local avec une seule fonction
et recevez immédiatement une réponse, y compris au format JSON.

Installation

pip install ollama-call

Pourquoi est-ce nécessaire

  • code minimal pour travailler avec le modèle ;
  • Réponse JSON structurée pour un traitement ultérieur ;
  • pratique pour les prototypes rapides et les MVP ;
  • prend en charge la sortie en streaming si nécessaire.

Utiliser un exemple

from ollama_call import ollama_call

response = ollama_call(
    user_prompt="Hello, how are you?",
    format="json",
    model="gemma3:12b"
)

print(response)

Quand c’est particulièrement utile

  • vous écrivez des scripts ou des services sur Ollama ;
  • besoin d’un format de réponse prévisible ;
  • il n’y a aucune volonté de connecter des frameworks lourds.

Total

ollama_call est un wrapper léger et clair pour travailler avec Ollama de Python.
Un bon choix si la simplicité et la rapidité des résultats sont importantes.

GitHub
https://github.com/demensdeum/ollama_call

SFAP : un cadre modulaire pour l’acquisition et le traitement modernes des données

Dans le contexte du développement actif de l’automatisation et de l’intelligence artificielle, la tâche de collecter efficacement,
Le nettoyage et la transformation des données deviennent essentiels. La plupart des solutions se ferment uniquement
étapes distinctes de ce processus, nécessitant une intégration et un support complexes.

SFAP (Seek · Filter · Adapt · Publish) est un projet open source en Python,
qui propose une approche holistique et extensible du traitement des données à toutes les étapes de leur cycle de vie :
de la recherche des sources à la publication du résultat final.

Qu’est-ce que SFAP

SFAP est un framework asynchrone construit autour d’un concept clair de pipeline de traitement de données.
Chaque étape est logiquement séparée et peut être étendue ou remplacée indépendamment.

Le projet est basé sur le modèle architectural de la Chaîne de responsabilité, qui fournit :

  • flexibilité de configuration du pipeline ;
  • tests simples des étapes individuelles ;
  • évolutivité pour des charges élevées ;
  • séparation nette des responsabilités entre les composants.

Principales étapes du pipeline

Recherche – recherche de données

A cette étape, les sources de données sont découvertes : pages web, API, stockages de fichiers
ou d’autres flux d’informations. SFAP facilite la connexion de nouvelles sources sans modification
le reste du système.

Filtre – filtrage

Le filtrage est conçu pour supprimer le bruit : contenus non pertinents, doublons, éléments techniques
et des données de mauvaise qualité. Ceci est essentiel pour les étapes de traitement ultérieures.

Adapter – adaptation et traitement

L’étape d’adaptation est responsable de la transformation des données : normalisation, structuration,
traitement sémantique et intégration avec des modèles d’IA (y compris génératifs).

Publier – publication

Au stade final, les données sont publiées au format cible : bases de données, API, fichiers, services externes
ou des plateformes de contenu. SFAP ne limite pas la manière dont le résultat est fourni.

Principales caractéristiques du projet

  • Architecture asynchrone basée sur asyncio
  • Modularité et extensibilité
  • Prise en charge des pipelines de traitement complexes
  • Prêt pour l’intégration avec les solutions IA/LLM
  • Convient aux systèmes très chargés

Cas d’utilisation pratiques

  • Agrégation et analyse de sources d’actualités
  • Préparer des ensembles de données pour le machine learning
  • Pipeline de contenu automatisé
  • Nettoyage et normalisation des flux de données volumineux
  • Intégration de données provenant de sources hétérogènes

Démarrer avec SFAP

Tout ce dont vous avez besoin pour commencer est :

  1. Cloner le dépôt du projet ;
  2. Installer les dépendances Python ;
  3. Définissez vos propres étapes de pipeline ;
  4. Démarrez un processus de traitement de données asynchrone.

Le projet s’adapte facilement à des tâches métier spécifiques et peut évoluer avec le système,
sans se transformer en monolithe.

Conclusion

SFAP n’est pas seulement un analyseur ou un collecteur de données, mais un cadre à part entière pour créer
systèmes de pipeline de données modernes. Il convient aux développeurs et aux équipes soucieux de
évolutif, architecturalement propre et prêt pour les données.
Le code source du projet est disponible sur GitHub :
https://github.com/demensdeum/SFAP

FlutDataStream

Une application Flutter qui convertit n’importe quel fichier en une séquence de codes lisibles par machine (QR et DataMatrix) pour un streaming de données à haut débit entre appareils.

Particularités
* Double encodage : représente chaque bloc de données à la fois sous forme de code QR et de code DataMatrix.
*Diffusion haute vitesse : prend en charge un intervalle de commutation automatique jusqu’à 330 ms.
* Smart Chunking : divise automatiquement les fichiers en morceaux personnalisés (par défaut : 512 octets).
* Scanner détaillé : lisez le code ASCII en temps réel pour le débogage et un retour instantané.
* Récupération automatique : récupère et enregistre instantanément les fichiers dans votre répertoire de téléchargements.
* Intégration du système : ouvre automatiquement le fichier enregistré à l’aide de l’application système par défaut une fois terminé.

https://github.com/demensdeum/FlutDataStream

Pourquoi ne puis-je pas corriger le bug ?

Vous passez des heures à travailler sur le code, à examiner des hypothèses, à ajuster les conditions, mais le bug est toujours reproduit. Cela vous semble familier ? Cet état de frustration est souvent appelé « chasse aux fantômes ». Le programme semble vivre sa propre vie, ignorant vos corrections.

L’une des raisons les plus courantes – et la plus ennuyeuse – de cette situation est la recherche d’une erreur au mauvais endroit dans l’application.

Le piège des « faux symptômes »

Lorsque nous constatons une erreur, notre attention est attirée sur l’endroit où elle a « tiré ». Mais dans les systèmes complexes, l’apparition d’un bug (plantage ou valeur incorrecte) n’est que la fin d’une longue chaîne d’événements. Lorsque vous essayez de réparer la fin, vous combattez les symptômes, pas la maladie.

C’est là qu’intervient le concept d’organigramme.

Comment ça marche en réalité

Bien sûr, il n’est pas nécessaire de dessiner (dessiner) directement un organigramme sur papier à chaque fois, mais il est important de l’avoir en tête ou à portée de main comme guide architectural. Un organigramme vous permet de visualiser le fonctionnement d’une application sous forme d’arbre de résultats.

Sans comprendre cette structure, le développeur tâtonne souvent dans le noir. Imaginez la situation : vous modifiez la logique dans une branche de condition, tandis que l’application (en raison d’un certain ensemble de paramètres) va dans une branche complètement différente à laquelle vous n’avez même pas pensé.


Résultat : vous passez des heures sur une correction de code « parfaite » dans une partie de l’algorithme, ce qui, bien sûr, ne fait rien pour résoudre le problème dans une autre partie de l’algorithme où il échoue réellement.

Algorithme pour vaincre un bug

Pour arrêter de frapper à porte fermée, vous devez changer votre approche du diagnostic :

  • Recherchez l’état dans l’arborescence des résultats :Avant d’écrire du code, vous devez déterminer exactement le chemin emprunté par l’application. À quel moment la logique a-t-elle pris une mauvaise tournure ? Quel État spécifique (État) est à l’origine du problème ?
  • La reproduction représente 80 % de réussite : elle est généralement effectuée par des testeurs et des tests automatisés. Si le bug est « flottant », le développement est impliqué dans le processus de recherche conjointe des conditions.
  • Utilisez autant d’informations que possible : les journaux, la version du système d’exploitation, les paramètres de l’appareil, le type de connexion (Wi-Fi/5G) et même un opérateur de télécommunications spécifique sont importants pour la localisation.

« Photographie » du moment de l’erreur

Idéalement, pour le corriger, vous devez obtenir l’état complet de l’application au moment où le bug a été reproduit. Les journaux d’interaction sont également d’une importance cruciale : ils montrent non seulement le point final, mais également l’intégralité du parcours utilisateur (quelles actions ont précédé l’échec). Cela aide à comprendre comment recréer à nouveau un état similaire.

Conseil futur : si vous rencontrez un cas complexe, ajoutez des informations de journalisation de débogage étendues à cette section de code au cas où la situation se reproduirait.

Le problème des États « insaisissables » à l’ère de l’IA

Dans les systèmes modernes utilisant le LLM (Large Language Models), le déterminisme classique (« une entrée, une sortie ») est souvent violé. Vous pouvez transmettre exactement les mêmes données d’entrée, mais obtenir un résultat différent.

Cela se produit en raison du non-déterminisme des systèmes de production modernes :

  • Parallélisme GPU : les opérations en virgule flottante GPU ne sont pas toujours associatives. En raison de l’exécution parallèle des threads, l’ordre dans lequel les nombres sont ajoutés peut légèrement changer, ce qui peut affecter le résultat.
  • Température et limitation du GPU : la vitesse d’exécution et la répartition de la charge peuvent dépendre de l’état physique du matériel. Dans les modèles volumineux, ces différences microscopiques s’accumulent et peuvent conduire à la sélection d’un jeton différent en sortie.
  • Lot dynamique : dans le cloud, votre demande est combinée avec d’autres. Différentes tailles de lots modifient les mathématiques des calculs dans les noyaux.

Dans de telles conditions, il devient presque impossible de reproduire « ce même état ». Seule une approche statistique des tests peut vous sauver la vie.

En cas d’échec de la logique : problèmes de mémoire

Si vous travaillez avec des langages « non sécurisés » (C ou C++), le bug peut survenir en raison d’une corruption de la mémoire.

Ce sont les cas les plus graves : une erreur dans un module peut « écraser » les données dans un autre. Cela conduit à des pannes totalement inexplicables et isolées qui ne peuvent pas être retracées à l’aide de la logique d’application normale.

Comment se protéger au niveau architectural ?

Pour éviter de tels bugs « mystiques », vous devez utiliser des approches modernes :

  • Modèles de programmation multithread : une synchronisation claire élimine les conditions de concurrence.
  • Langages thread-safe : outils garantissant la sécurité de la mémoire au moment de la compilation :
    • Rust : le système de propriété élimine les erreurs de mémoire.
    • Concurrency Swift 6 :Contrôles rigoureux de l’isolation des données.
    • Erlang : Isolation complète des processus grâce au modèle d’acteur.

Résumé

Corriger un bug ne consiste pas à écrire du nouveau code, mais à comprendre comment fonctionne l’ancien. N’oubliez pas : vous pourriez perdre du temps à éditer une branche à laquelle la direction ne touche même pas. Enregistrez l’état du système, tenez compte du facteur de non-déterminisme de l’IA et choisissez des outils sûrs.

Ferral

Ferral est un langage de programmation multi-paradigmes de haut niveau spécialement conçu pour générer du code à partir de grands modèles de langage (LLM). Alors que les langages traditionnels ont été conçus en gardant à l’esprit l’ergonomie humaine, Ferral est optimisé pour la façon dont les grands modèles de langage (LLM) raisonnent, tokenisent et déduisent la logique.

Le nom est orthographié avec deux R, indiquant une approche « réinventée » de la nature imprévisible du code généré par l’IA.

https://github.com/demensdeum/ferral

DoryChat

DoryChat est une plateforme de messagerie instantanée sécurisée et persistante construite sur un modèle architectural sans rétention. Les messages sont temporaires, chiffrés de bout en bout et automatiquement supprimés après 60 secondes, garantissant que les conversations ne laissent aucune trace sur l’infrastructure centrale.

https://github.com/demensdeum/DoryChat
https://mediumdemens.vps.webdock.cloud/dorychat-app