flan a écrit 1848 commentaires

Pour ce prix, ce n'est pas un nouveau logiciel, mais une adaptation d'un logiciel existant (du SAP)…

Non, il dit « il y a vraiment peu de raisons d'utiliser un stockage texte quand il y a une meilleure option disponible »

Traduction : quand le binaire est meilleur, il ne voit pas de raison d'utiliser du texte.

Question bête pour la structuration des données.

Est-ce qu'une bête base de données SQL classique (sqlite quand on est en local, ou pgsql/mysql si on veut faire plus compliqué) ne pourrait pas convenir ? Quel est l'intérêt d'un format binaire spécifique alors que du SQlite dispose déjà de milliards d'outils ?

Gitlab utilise une base de données classique (postgres ou mysql). J'ai donc fait un petit script (avec l'ORM de Django vu que je maîtrise un minimum) qui écrit directement les utilisateurs et les groupes dans la base de données de Gitlab.

s%fichier large%gros fichier%
(enfin, je pense)

On ne parle pas spécialement d'utilisateur, on parle de filtrage des communications entre l'intranet et l'internet. Ces communications peuvent être faites par les utilisateurs, ou par des spywares qui vont communiquer en HTTPS pour se noyer justement dans le flux licite.

Après, pour le digne de confiance, il faut bien distinguer deux niveaux : les utilisateurs malveillants (concrètement, on ne doit pas pouvoir faire grand-chose contre eux à mon avis), et les utilisateurs négligents (là, fliquer peut aider pas mal, mais il faut qu'ils soient prévenus).

Bien sûr, tout dépend du niveau de sécurité demandé, mais c'est parfois nécessaire. Ça ne me choquerait pas qu'il y ait pas mal de mesures de sécurité pour des ministères comme Bercy.

mais l'Allemagne cherche à récupérer toute la partie intéressante (ils ont notamment essayé de déménager les bureaux de conception d'Airbus de Toulouse à Hambourg). De notre côté, on se laisse plutôt faire…

Parfois, la sécurité informatique prime, c'est normal de devoir surveiller ce qui sort de ton réseau local quand il y a potentiellement des informations un peu sensibles (je pense à Bercy, par exemple).

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.