flan a écrit 1865 commentaires

Tout le monde ne suit pas cette logique : par exemple, Windows 10 (prévu pour la mi-2015) a les mêmes prérequis matériels que Windows Vista (sorti en 2007, soit 8 ans avant).
Pourtant, il y a pas mal de nouveautés en termes d'interface qui arrivent avec cette version (qu'on aime ou pas, c'est un autre débat).

Je ne sais pas comment je fais, mais ça ne m'est jamais arrivé de rajouter des bugs comme ça. Peut-être que mon IDE y est pour beaucoup, mais ça ne m'a jamais dérangé.

Il suffit de faire comme tout le monde et de suivre la PEP008 (qui décrit une norme de code à suivre), et tu n'as alors aucun problème.
Globalement, la PEP008 est très suivie, la plupart des codes Python que j'ai pu relire s'y conforment. Du coup, on a un écosystème assez homogène à ce niveau là et il est facile de se plonger dans le code d'un autre.

D'une part parce que je ne connaissais pas ( :D ), d'autre part c'est plus lourd à utiliser que DjangoFloor :

• pas de classe à définir
• possibilité de réutiliser les variables au sein de variable (par exemple je définis LOCAL_PATH, puis je redéfinis les autres valeurs avec : STATIC_ROOT = '{LOCAL_PATH}/static' )
• tu peux te passer des --configuration ou de export DJANGO_CONFIGURATION en utilisant un fichier nommé monprojet-manage (à la place de manage.py)
• il va chercher un fichier de conf' local (qui ne sera pas donc versionné, important quand il y a des mots de passe).

DjangoFloor est un module Python (et une app Django), donc tu peux le mettre à jour facilement.
Pas de merge à faire, vu que ses fichiers restent séparés de ceux du projet (et également séparés du fichier de conf local).

Normalement, les settings Django font partie du code « maison ». Avec DjangoFloor, les settings n'est plus dans le code maison, il se contente d'aller piocher dans le code maison les paramètres qui changent (puis dans la conf locale les paramètres spécifiques).

Mais MrBob rajoute un outil supplémentaire. Là, on utilise uniquement easy_install/pip (pour rester en mode Python) ou apt/yum (si on a pris la peine de les packager avec les setuptools), deux types d'outils bien intégrés avec les outils classiques de déploiement (Ansible, Puppet, Salt, etc.). On déploie un paquet (dont on ne touche pas les fichiers) et on écrit un fichier de conf, et c'est tout.

Pour moi, cookiecutter permettait de créer un début de code pour un nouveau projet, pas d'en déployer un existant.
L'inconvénient d'un template super complet, c'est que s'il est modernisé, alors tu dois modifier les projets existants à la main.

uwsgi -> un serveur applicatif, un peu l'équivalent de Tomcat pour Python (et quelques autres langages). En l'occurrence, je ne l'ai pas mis en dépendance explicite
bootstrap3 (django-bootstrap3 et django-admin-bootstrapped) -> une feuille CSS généraliste pour avoir un site web qui ressemble à quelque chose par défaut
font-awesome -> une feuille CSS avec des icônes sous forme de caractères d'une police faite sur mesure
CSS et JS (django-pipeline, jsmin et rcssmin) -> fusionne et minimise les feuilles CSS et fichiers JS
gestion de tâches (celery via Redis) ->
cache, websockets et sessions (django-websocket-redis, django-redis-sessions-fork, django-redis-cache) -> les websockets sont un moyen de faire des communications bi-directionnelles sur une page web, en gardant une connexion active
django-debug-toolbar
gunicorn -> un serveur applicatif 100% Python

Il y a uniquement gunicorn en dépendance, pour des raisons de simplicité (pas de module C à compiler…). En revanche, le script pour utiliser uwsgi est fourni (qui se contente d'importer le bon module, au final).

La place à l'intérieur du sac n'est pas extensible, tout simplement, et je me pose souvent comme contrainte de ne partir qu'avec ce sac.

Ou alors on accepte de rajouter trois millimètres d'épaisseur à la machine, ce n'est pas la mort non plus… En pratique, le poids et les dimensions (largeur x longueur) me paraissent beaucoup plus importants au quotidien que l'épaisseur.

Ça dépend beaucoup des gens. Pour moi, largeur et longueur ont peu d'importance tant que ça tient dans mon sac. Par contre, je préfère avoir l'ordi le plus fin possible, et les 3 mm comptent à ce niveau-là.

Ça pourrait être pas mal que l'USB-3.1 puisse faire du réseau. On aurait enfin une vraie prise universelle (vidéo, audio, alimentation, réseau, et périphériques classiques).

… pour être le meilleur choix, quelques soient les besoins de l'acheteur potentiel.

source ?

Outre Github, maintenant beaucoup d'outils ne proposent que git comme interface. Si je veux une forge à peu près moderne à installer chez soi, je ne vois que Gitlab qui soit à mon goût, et qui (Ô surprise) ne sait pas faire avec Mercurial. Si je ne me trompe pas, mon IDE sait uniquement faire du SVN et du Git par défaut (j'avoue que ça fait longtemps que je n'ai pas touché à la conf, donc je peux me tromper), même s'il y a un plugin pour Mercurial.

Même si je serais volontiers passé de svn à Mercurial, cette différence de traitement dans les outils a fait pencher la balance en faveur de git.

Les média ont un rôle dans l'éducation de la population ; on peut appeler ça propagande si tu préfères, mais quoiqu'il arrive, les programmes passant dans ces média ont forcément une influence.

En effet, Scala a un truc codé en Scala (SBT)… et j'aimerais bien qu'il soit codé dans un autre langage. Je pense de plus en plus à refaire quelque chose en Python pour mes propres besoins (je trouve qu'avoir 1 min de lancement pour quelques secondes de compilation est insupportable).

Sinon, on peut faire comme dans (presque) tous les autres langages : un dépôt central (avec la possibilité de rajouter des dépôts secondaires) qui contient les bibliothèques avec les différentes versions.
Je ne comprends pas le problème de la sécurité… au contraire, ça permet d'automatiser l'ensemble de la procédure (téléchargement, vérification de l'origine via une signature, vérification du téléchargement via un hash sha1).
Si on doit télécharger à la main sur des dizaines de sites différents, tu auras en pratique beaucoup moins de garantie.

Les environnements virtuels de Python sont pas mal, à ce niveau (je parle de Python, mais ça existe probablement dans d'autres langages).

C'est un peu la même idée qu'un chroot, mais limité à Python : la commande python correspondra à la version de Python choisie pour l'environnement virtuel en cours, et seuls les modules de l'environnement virtuel seront visibles.
Tu peux donc facilement passer d'un venv à l'autre, en choisissant la version de Python et des bibliothèques. Très pratique pour tester !

pourquoi installer dans /usr/local ? Tu pourrais installer dans ~/.local , qui ne demande pas des droits root.

À ce que j'ai entendu (par des gens dans le milieu du CHP), certains s'attendent à ce que l'ARM puisse concurrencer le x86 dans 5 ans environ (s'il n'y a pas de grosse surprise). Mais naturellement, si l'ARM obtient les mêmes perfs que le x86, ça sera au détriment de la consommation (qui sera équivalente à celle du x86).
Après, il n'y a pas de mystère : ce sont (globalement) les mêmes technos, qui veulent répondre aux mêmes problèmes, donc on peut s'attendre à avoir des résultats équivalents (sachant que finalement, la surcouche historique due au x86 n'est pas si coûteuse).

L'intérêt de l'ARM reste quand même d'avoir un vrai concurrent à Intel : depuis qu'Intel est le seul « vrai » fournisseur dans le CHP, le prix des processeurs a bien augmenté.

Accessoirement, on peut faire de l'OCSP via HTTP.

En quoi est-ce du code volé ?

Ok, merci pour toutes ces infos ; ça commence à être plus clair comme ça.

Et go a l'air de te poser beaucoup de problèmes niveau sécu. J'imagine que c'est lié au besoin des dernières versions de chaque lib (je comprends le risque à utiliser le git directement) et à la compilation en statique, mais y a-t-il autre chose ?

Merci :)

Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.

Qu'est-ce donc que kubernetes ou openshift origin ?

Il y a un risque : tu perds le mot de passe ou la clef et tes données sont irrécupérables. En entreprise, tu perds la personne (et donc son mot de passe) et ses données sont irrécupérables (sauf si tu as fait les choses bien, avec des clefs de recouvrement).