Bot Discord collaboratif du serveur Dev Cherche Collègue
Pour collaborer efficacement, chaque collaborateur est responsable de se créer un Serveur Discord et d'inviter un bot créé à partir de son propre compte Discord.
Les étapes du bot sont documentées dans cette vidéo : créer un bot discord En cas de besoin la documentation officielle de Discord : documentation
On est également à votre disposition sur le canal textuel byebyedevbot pour vous aider à réaliser toutes ces étapes.
Pour tester sur votre serveur privé:
- Créer un bot avec tous les droits
- Inviter le bot sur votre serveur
- Renseigner la clé secrète dans le futur .env
- Créer des roles à assigner et récupérer leurs IDs
- Assigner à chaque emoji un role et dans le cas d'un emoji custom son id dans le fichier
emoji_to_roles.json
au format:
{
"<emoji_name>": {
"emoji_id": <emoji_id>,
"role_id": <role_id>
},
...
}
- Lancer le bot
python3 main.py
- Dans le channel de votre choix taper `! set_role_picker'
- Un message du bot devrait apparaitre avec les emotes configurées dans
emoji_to_roles.json
.
Création de l'environnement virtuel local
python3 -m venv venv
Création d'un fichier .env pour les variables locales
cat > .env <<EOF
DISCORD_BOT_SECRET_KEY=<YOUR DISCORD BOT SECRET KEY>
DISCORD_BOT_ADMIN_ID=<ID OF THE USER ABLE TO ADD REACT MESSAGES>
EOF
Activation de l'environnement (Linux et Mac)
source venv/bin/activate
Activation de l'environnement (Windows Powershell)
venv\bin\activate.ps1
Installation des dépendances
pip3 install -r requirements.txt
Installation des dépendances de test
pip3 install -r requirements.txt
pip3 install - r requirements-dev.txt
Exécuter le linter
pylama main.py app/*
Exécuter les tests
python3 -m pytest
python3 admin/setup_sqlite.py
ou
./admin/setup_sqlite.py
Pas de notion prod et développement pour le moment, c'est un protoype !
python3 main.py
ou
./main.py
La clean archi propose de séparer clairement le besoin métier (usecase), la communication avec l'utilisateur (transport) , l'implémention réelle (module) et les objets interne à l'application (domains).
Chaque module possède une part de la connaissance et s'interface avec les autres. Globalement:
Un utilisateur fait une demande au transport -> le transport analyse la demande et la traduit pour l'usecase concerné -> Le usecase appelle les modules nécessaire à la résolution du besoin -> Redispatch des retours des modules par le usecases qui gère les erreurs et renvois ce qui est nécessaire au transport pour répondre à l'utilisateur si besoin.
J'aime bien travailler avec ce découpage car il permet d'isoler la communication avec le client, le besoin fonctionnelle et le besoin technique. Mes usecases doivent idéalement être agnostique du transport et de l'implémentation mais ce ne doit pas être un point bloquant (si un usecase et propre a un prérequis de transport ou d'implém, il doit pouvoir ne pas être indépendant de celui-ci).
Cela simplifie l'écriture de test automatisé et permet une plus grande souplesse du code.