Tout ce qui concerne le développement en général, que ce soit des choses générales, ou des choses bien précises. Cela va de la gestion de projet à la recherche du fonctionnement de pointeurs en C.
Le code est simple, il fautt avoir paplay d’installé (je ne sais pas si c’est installé par défaut dans Debian).
A partir de là voici un exemple de code qui joue un fichier ogg :
# python3
>>> import subprocess
>>> subprocess.Popen([
... "paplay",
... "/home/olivier/.local/blah/Mission_Failed.ogg"
... ]).poll()
>>>
Git |
|
| Workflow Git | trunkbaseddevelopment.com |
| Semantic versioning | semver.org | Commit messages, règles de base | gist.github.com/robertpainsi |
| Conventional commits | conventionalcommits.org |
| Full refresh à partir du develop (si problème ou autre) |
git reset --hard origin/develop
|
| Rafraîchir (à la main) une branche locale (si problème ou autre) |
git checkout master
|
Synchroniser le local avec le remote
|
git fetch
|
| Pour faire une nouvelle branche |
git checkout -b [nom de la branche]
|
| Pour changer de branche |
git checkout [nom de la branche]git pull
|
| Sous-module : ajouter un git qui vient d'un autre repo |
git submodule add [nom du repo] [dossier dest]Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js
Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
|
| Sous-module : ajouter un git qui vient d'un autre repo |
git submodule add [nom du repo] [dossier dest]Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js
Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
|
| Sous-module : ajouter un git qui vient d'un autre repo |
git submodule add [nom du repo] [dossier dest]Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js
Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
|
| Sous-module : : sur un autre PC mettre à jour avec tous les sous-modules |
Si git pull ne met pas à jour les sous-modules, c'est que ce qui gère les sous-modules sous git n'est pas initialisé :git submodule update --init
|
| Pour changer de branche |
git checkout [nom de la branche]git pull
|
| Pour changer de branche |
git checkout [nom de la branche]git pull
|
| Git global setup Sur PC dev |
git config --global user.name "Olivier Pons" |
Clone gitlab » devPush dev » gitlab |
git clone git@gitlab.com:olivier.pons/ajeter.git |
| Init. projet pas vide: Clone dev » gitlab |
cd existing_folder |
| Git existant sur dev Clone dev » gitlab |
cd existing_repo |
| Autre Git existant sur gitlab Clone gitlab » dev |
> git clone git@gitlab.com:adresse/repo/sur/gitlab/monprojet.git
Donc en local, on a en local nom-de-la-branche liée à la branche distante remotes/origin/nom-de-la-branche.A partir de là commit, push et pull fonctionnent. |
|
Si des branches ont été ajoutées au remote : Synchroniser le git local avec le remote |
git remote update origin --prune
|
requirements |
|
Le résultat du pip freeze permet d'avoir un "snapshot" des versions exactes utilisées, cela peut éviter certains bugs.
Dans tous les cas, il faut prendre en compte les dépendances dès le début du projet et tout au long de son cycle de vie.
|
|
Une bonne pratique quand on utilise pip est de structurer ses dépendances de la manière suivante :
requirements_dev.txt, le déploiement en prod utilise requirement_prod.txt ou requirements.txt.
Tout ceci permet d'avoir des environnements reproductibles avec des versions figées, et de ne pas avoir à installer des dépendances supplémentaires à la main (par exemple gunicorn en prod).
| |
Oui.
TAX INVOICE? One image:
Je l’ai fait. OUI.
J’ai même choisi toutes les catégories dans lesquelles il peut entrer :
Je lutte activement contre la mentalité Française latine : j’essaie d’expliquer à tout le monde qu’il faut arrêter de scier la branche sur laquelle on (= les développeurs) est assise : si vous pouvez avoir quelque chose de gratuit, mais que vous vous en servez souvent, faites le calcul : s’il vous fait économiser du temps, donc de l’argent, bah la conclusion est simple : il faut que cela continue. Pour que cela continue, payez (moins que ce qu’il vous a fait économiser, sinon c’est pas intéressant) mais payez, bon sang !
J’ai évolué de ce côté et je fais tout pour que les personnes que je fréquente – et étudiants – aillent dans ce sens.
Donc oui, Sublime Text me fait gagner du temps tous les jours depuis plusieurs années, et aujourd’hui, la conclusion est évidente : il m’a fait gagner bien plus que 80 €.
Donc… je résume, une image vaut mille mots. Et même si pour certains c’est vieux, le principe reste éternel :
PS : pour ceux qui ne savent pas ce que « OMFG » signifie, ne le dites à personne, et allez vite chercher sur Internet. Promis on ne le dira à personne. C’est comme « RTFM ». Promis.
Je vous donne des pistes, à vous de finir.
L’idée, c’est que je veux paramétrer pour la n-ième fois un nouveau nom de domaine via certbot, et je ne veux pas qu’il touche à la conf de nginx.
L’idée c’est que :
(1) Je le fais simplement via certbot-auto puis après,
(2) toutes les autres fois j’utilise « -d » pour qu’il ne touche pas à la conf, et je le fais à la main, en m’inspirant de la conf que cert-bot a fait dans le (1)
Donc, pour faire le (1), je demande à certbot de me créer uniquement le certificat :
./certbot-auto certonly -d monsite.fr
Pour le https, regardez ici.
Code exemple, qui lit un fichier JSON, lance le serveur et sert le fichier lu en tant que JSON :
import json
from flask import Flask, jsonify
app = Flask(__name__)
with open("mon fichier JSON", 'r') as f:
json_levels_full_description = json.load(f)
@app.route('/')
def index():
return jsonify(json_levels_full_description)
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8004)
else:
application = app
Attention : surtout ne faites pas le classique if __name__ == '__main__' car uwsgi inclut ce fichier, donc ce fichier n’est jamais un __main__, par contre la configuration au lancement a besoin d’une variable globale nommée application.
https, en voici un extrait diminué à mort pour ne pas polluer avec des règles personnelles, regardez bien le texte en gras, c’est le plus important pour faire tourner Nginx en collaboration avec wsgi :
server {
server_name "~(www\.)?monsite\.(com|fr|org|biz|be)$";
index index.html index.htm;
access_log /blah/proxy-access.monsite.log proxylog;
error_log /blah/proxy-error.monsite.log error;
listen 443 ssl;
ssl_certificate /blah/fullchain.pem;
ssl_certificate_key /blah/privkey.pem;
include /blah/options-ssl-nginx.conf;
ssl_dhparam /blah/ssl-dhparams.pem;
location / {
include denied_clients;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Server $host;
# (!) here it's uwsgi:
include uwsgi_params;
uwsgi_pass 127.0.0.1:8002;
}
}
# redirect http -> https:
server {
listen *:80;
server_name "~^monsite\..*$";
return 302 https://$host$request_uri;
}
Pour installer flask, et uwsgi, faites un environnement virtuel puis installez les deux :
$ python3 -m venv venvpython.3.6.6
$ source venvpython.3.6.6/bin/activate
$ pip install --upgrade pip
$ pip install flask
Il faut être dans le venv activé (voir paragraphe précédent), puis l’installer via pip :
$ pip install uwsgi
Enfin, le script de lancement !
uwsgi --chdir=/web/htdocs/blah \
--module=flask_server:application \
--master --pidfile=/tmp/uwsgi.blah.pid \
--socket=127.0.0.1:8004 \
--processes=5 \
--uid=1000 --gid=2000 \
--harakiri=20 \
--max-requests=5000 \
--vacuum \
--home=/web/htdocs/blah/venvpython.3.6.6
flask_server correspond au fichier python flask_server.pydécrit dans la section python au début et application est le nom de la variable globale (lisez le code de la section python)
Lorsque vous le lancerez, tout se passera bien, mais l’exécutable ne sera pas en tâche de fond. Cela a un avantage : un CTRL-C et vous l’arrêtez ! L’inconvénient, c’est que vous n’avez pas la main.
Si vous voulez le lancer en tâche de fond et qu’il écrive les logs dans un fichier, ajoutez l’option
--daemonize=/var/log/uwsgi/blah.uwsgi.log
8004 peut être passé en tant que variable d’environnement à l’application flask via le paramètre `env` de la commande uwsgi, ce qui rend le code plus portable ;my_app.ini et uwsgi serait alors lancé en faisant uwsgi my_app.ini
source)source, cloner la librairie à laquelle on veut contribuer viagit clone [repo concerné]
pip (ex : pip_env_lib)pip_env_lib, installer l’environnement pip via pipenv installpip_env_lib, lancer le « shell pip » via pip shellsourcepip install -e .pip install -e . (n’oubliez pas le . qui change tout, cela indique le répertoire à utiliser) signifie « si jamais le shell Python en cours essaie d’accéder à la librairie à laquelle on veut contribuer, aller la chercher dans source ». En fait, concrètement parlant, pip fait simplement un lien symbolique entre le dossier source d’installation de pip (ici c’est pip_env_lib), et le dossier source. N’oubliez pas que cela ne concerne le shell Python en cours (ici pip_env_lib).
L’avantage pratique de ce « lien symbolique », c’est qu’il est directement relié au code source. Donc, lorsqu’on modifie le code source de la librairie elle-même (dossier source), elle est immédiatement disponible. Si on fait donc des fichiers de tests unitaires, il suffit de les relancer, les modifications du code source sont toujours instantanément prises en compte. Toujours dans le shell Python en cours (ici pip_env_lib).
mkdir [source]
cd [source]
git clone [repo concerné]
cd ..
mkdir [pip_env]
cd [pip_env]
pipenv --python 3 install
pip shell
pip install -e .
.. et les modifications dans [source] peuvent commencer !
La documentation détaillée en anglais se trouve ici.
Bien meilleure que ce qui suit, mais longue, longue…
Voici les notes prises à la volées, d’un contributeur plutôt habitué à faire des contributions dans le monde Python.
Toute nouvelle note / correction éventuelle est la bienvenue.
Il y a trois choses différentes qu’on a tendance à confondre, mais qui n’ont fondamentalement aucun rapport. On a tendance à les confondre parce qu’on essaie d’utiliser, pour des raisons pratiques, le même nom, mais dans trois cadres différents.
Ces trois choses à bien dissocier sont :
– le nom du package PyPI : dans le fichier de déploiement setup.py, il est défini dans le paramètre « name » de la commande setup(). C’est ce qui est vu dans PyPI.
– le nom du projet qu’on met dans github : c’est le répertoire qui contient tous les fichiers du projet (= il peut être totalement différent, en général on s’arrange pour les appeler d’un nom différent) = c’est ce qu’on clone dans l’ordre git clone [repo concerné]
– le développeur final qui fait un « import » dans son code : ce module là peut être aussi différent, car c’est du Python. En général, c’est le répertoire de premier niveau du package (il doit contenir, bien sûr, « __init__.py » pour être vu comme un package et importable par Python). En général : « from [ma lib] import [quelque chose]« .
En général, on essaie de s’arranger pour que le nom du package sur PyPI soit le même que le nom du package dans le code Python même.
Mais s’il est déjà pris (dans un des trois contextes), il faut forcément utiliser un autre nom, et c’est là qu’il faut faire attention à ne pas se mélanger les pinceaux.
Pour faire un nouveau package sur PyPI le plus homogène possible :
PyPI : si ça fonctionne, alors vous pouvez continuer. Sinon, il faut utiliser un autre nomDans PyPI, les versions sont obligatoirement du type «a.b.c».
En général :
[a].[b].[c]
[a] = fonctionnalités totalement nouvelles / incompatibilité
[b] = améliorations / nouvelles "petites" fonctionnalités
[c] = correctifs bogues
Lorsque vous faites une nouvelle contribution, vous devez obligatoirement fournir un fichier setup.py.
Dans ce fichier, setup.py, il y a une fonction, ici aussi, obligatoire : setup().
Cette fonction, parmi tous les paramètres, a un paramètre particulier : classifiers qui permet au niveau de PyPI de dire « ce package est rangé dans telle(s) catégorie(s) ». La liste des expressions disponibles se trouve ici.
Voici le (petit) souci que tout le monde a forcément dès qu’on commence à vouloir un peu pousser la customization de l’administration Django : on aimerait avoir la possibilité d’accéder à certains modèles, mais uniquement en lecture seule. J’ai des tonnes d’exemples simples, mais très souvent, ce sont des modèles avec des choix « fixes » qui ne risquent pas d’évoluer dans le temps (exemple : sexe « féminin »/ »masculin »). Seulement (1) on ne veut pas le voir apparaître dans l’admin (2) si on ne veut pas le voir apparaître, il ne faut pas le déclarer, et Django ne veut pas accéder à un modèle qui n’est pas déclaré (= erreur), donc on en arrive toujours à (3) on déclare le modèle, on applique une solution « bidouille » que je ne décris pas ici mais même si le modèle n’apparaît pas dans l’interface, en tapant à la main la bonne URL (facile à deviner qui plus est), on peut tout de même modifier ce modèle. Heureusement la version 2.1 de Django pallie à ce manque !
Eh oui, dans la classe interne «Meta», ils ont fait évoluer default_permissions, qui est écrit en base. Donc en passant à Django 2.1 il vous faudra faire le fameux makemigrations migrate.
Là ou cela devient intéressant, c’est que dans les options vous avez default_permissions et elles sont ('add', 'change', 'delete', 'view'). Le plus important et le nouveau est donc 'view' qui pallie parfaitement au problème expliqué en haut !
Il vous suffit de déclarer votre modèle, de faire la classe dérivée de ModelAdmin et de préciser uniquement ('view',).
Attention, je n’ai pas testé, si quelqu’un veut tester et confirmer que ce code fonctionne (ou pas), je suis preneur !
class SexeAdmin(models.ModelAdmin):
class Meta:
default_permissions = ('view',)
Plein de code en moins, plus aucune bidouille ici, plus de lisibilité, bref, de mieux en mieux !
Côté utilisateur |
|
| La souris |
Quand on aimerait cliquer :/mouse disablePour la remettre : /mouse enable
|
| Documentation |
Raccourci : cliquer sur le lien : – Message privé – Raccourcis clavier |
Configuration |
|
| Toujours installer v2+ et pas moins | https://weechat.org/download/ |
Fichier de conf :~/.weechat/
|
Weechat = une seule instance. Conf. chargée en entier ici : ~/.weechat/Pour plusieurs instances, copier tout le dossier, ex : cp -R ~/.weechat ~/.weechat2Puis lancez en précisant weechat -d ~/.weechat2
|
| Lancement + connexion auto |
Exemple de code :weechat -r '/server add freenode irc.freenode.net; /connect freenode -nicks=Olivier; /set irc.server.freenode.username "Olivier2"; /set irc.server.freenode.realname "Olivier Pons"; /set irc.server.freenode.autojoin "#prognosis-dev"'
|
Plugins |
|
Situés dans :~/.weechat/
|
Plugins Python ici :~/.weechat/python
|
| Chargement manuel |
Exemple Python / plugin arespond.py :/script load arespond.py
|
| Chargement automatique |
Exemple Python / plugin arespond.py :Faire un lien symbolique : cd ~/.weechat/python/autoload
|
| Options / switches |
Définir une option manuellement :/set plugins.var.python.[SCRIPT_NAME].[option]="[valeur]Appuyer sur TAB pour autocompléterAu pire lire les options dans le code même. Exemple Python / plugin arespond.py :Les options sont en « camelCase », mais elles sont toutes transformées en minuscules dans weechat. Il y a trois options marquée dans le code: "muted""respondAfterMinutes""responderText"Donc pour y accéder, il suffit de taper : /set plugins.var.python.arespond.[tab]Et les trois options seront affichées sur la ligne du dessus, il suffit d’autocompléter. |
Petite parenthèse sur l’évolution de Django. Aujourd’hui, ce qui commence à importer plus que la vitesse, c’est la parallélisation des choses.
Donc avoir un serveur Web asynchrone, c’est censé être mieux qu’un serveur Web synchrone (= bloquant).
Si jamais vous décidez d’être un vrai guerrier, un de ceux qui veulent tout maîtriser, un de ceux qui, quand on leur donne des ordres, peuvent les refuser (oui c’est rare), et si vous voulez prendre des responsabilités, bref, si vous en avez : faites vous votre propre serveur git !
Je ne décrirai pas comment installer un serveur git sous Linux tellement c’est simple. Et je ne décrirai pas non plus comment faire ça sous Windows : pour des raisons de sécurité, de fiabilité et d’éthique, évitez Windows un point c’est tout.
Donc, sous Linux :
scp est votre ami si vous êtes sur un PC et que vous voulez faire cela sur un autre PC)/web/htdocs/interro/htdocs.gitignore*.pyc
__pycache__
myvenv
db.sqlite3
/static
.DS_Store.DS_Store est pour les personnes sous Mac (non je ne vous en veux pas, je suppose que vous ne connaissez pas bien l’histoire de l’informatique pour avoir acheté Apple)) » pour toutes les personnes qui vont cloner ce dossiergit add --all .git commit -m "My application, first commit"git status. Vous devez avoir un messsage ressemblant fortement ànothing to commit (working directory clean)git checkout -b development. git clone (dans PyCharm, c’est le menu VCS » git » clone)Bien sûr, comme tous les gestionnaires de version délocalisés, il vous faudra toujours trois étapes pour valider vos modifications :
git commit -m "mon message expliquant les modifs")git pull) vers votre code « local », au cas où d’autres personnes auraient « pushé » des modificationsgit push)Voici comment créer manuellement des groupes + des autorisations personnalisées :
from django.contrib.auth.models import Group, Permission
from django.contrib.contenttypes.models import ContentType
from django.contrib.auth.models import User
new_group, created = Group.objects.get_or_create(
name ='co_branding_trainer')
ct = ContentType.objects.get_for_model(User)
permission_co_branding_trainer = Permission.objects.create(
codename='co_branding_trainer',
name='Co-branding trainer', content_type=ct)
new_group.permissions.add(permission_co_branding_trainer)
Une fois cela fait, on a deux possibilités :
{% if perms.app_label.can_do_something %}
{% endif %}forbiddenComme je préfère la seconde (qui évite d’avoir dans le template des « if » un peu partout), voici comment faire : on crée un mixin qui se chargera de vérifier si, dans la vue, on a les droits : il suffit de chercher PermissionRequiredMixin dans le code de Django, et vous verrez que tout est simple, à partir de là vous pourrez faire descendre vos vues génériques de PermissionRequiredMixin.