Si tu viens ou repars en direction de Lyon ou Valence, en semaine, passes prendre un café à Algoo (sauf si c'est la semaine des RMLL). Je crois que tu fais du python… nous aussi :)
Si je lis entre les lignes, OVH fait partie des acteurs français avec qui vous auriez pu (aimé ?) avancer mais que ça ne s'est pas fait pour des raisons plutôt dépendantes de leur volonté.
Tu peux nous en dire plus ? (ou c'est confidentiel ?)
Tu dois soumettre ton projet aux organisateurs et qu'ils le valident.
La pub, yen a un peu, mais si tu veux être sûr d'avoir du monde c'est plutôt à toi de la faire. Regarde la page du programme de l'an dernier pour te faire une idée : https://www.pycon.fr/2017/programme.html
La bonne solution si tu veux avoir de la visibilité, c'est de publier par exemple un journal ou une dépêche sur LinuxFR :)
Je dis pas qu'il faut pas le faire, hein ! Je pense que c'est super intéressant de résoudre ce genre de problèmes (tout comme ce que tu fais et présentes dans ces 2 très bons journaux ) ; je partageais juste les retours que j'ai pu avoir lorsque j'avais échangé avec les dev de l'équipe R&D qui bossaient sur le sujet et notamment sur les calculs de parcours outil.
La découpe en biais complexifie énormément la programmation. Tu passes d'une programmation 3 axes à minimum 5 axes car tu dois piloter en dynamique la tête pour l'orienter progressivement toujours dans la bonne direction.
Ça paraît à peine plus compliqué, mais c'est très nettement plus complexe. Les éléments de base qui complexifie les choses :
si tu coupes en biais, l'épaisseur de coupe varie (donc la puissance, la vitesse de coupe, ou les deux)
si tu positionnes ta tête de coupe en biais, tu dois approcher la tête de la matière car la distance de la tête doit rester la même par rapport à la matière
le décalage (offset) de la tête varie également en fonction de l'orientation de ta tête. Concrètement, si tu decoupes un rectangle de 30mm par 20mm, la tête va parcourir un rectangle de 30,2mm par 20,2mm pour prendre en compte le trait de coupe. Couplé au reste ça donne des parcours outil extrêmement plus complexes.
sur des coupes en biais, les zones de sécurité deviennent différentes, parce que le parcours outil + son orientation donnent une zone balayable beaucoup plus vaste, sans parler des réflexions optiques qui sont «simples» en cas de coupe droite.
Pour faire des coupes en biais, on passe d'un robot 5 axes avec projection 2D (l'axe Z est juste là pour «approcher» la tôle) à un robot 5 axes pour une pièce finie en vrai 3D (la forme n'est cairement pas la même selon le niveau dans la tôle), c'est vraiment pas la même chose…
Je confirme : tu soumets le projet de sprint, et sauf inadéquation ça devrait être accepté… mais l'équipe organisatrice garde (logiquement) le pouvoir, ne serait-ce que pour éviter trop de projets si le cas se présente.
On a proposé un sprint l'an dernier sur Tracim, on en proposera sans doute un cette année aussi.
L'idée des sprints, c'est : tu viens avec ton projet - faire du dev sur un projet, de la doc, … peu importe. Tu « pitches » ton projet en début de journée et les personnes motivées viennent participer. Pas mal de projets viennent déjà avec leur sprint et des contributeurs. Je pense qu'il y a déjà de la comm' en amont. Ce n'est pas obligé. Par exemple on a eu des contributeurs sur nos sprints sans avoir rien anticipé. Ce qu'il faut c'est « juste » proposer qqchose qui intéresse et qui est accessible à un dev qui connaît pas ton projet.
Il me semble qu'il n'y a pas de «sélection» pour les sprints (du moment que tu rentres dans le cadre de la thématique de pyconfr).
Pour les conférences et ateliers, c'est différent car salles et créneaux horaire sont limités. (On s'était fait recaler une proposition;)
J'invite les autres visiteurs enrichir ce fil avec leur propre retour d'expérience.
Ca permettra d'obtenir des réponses plus pertinentes parce que - par exemple, on ne suggèrera pas ce que tu utilises déjà (de plus ça permettra d'identifier les limitations de la solution technique).
De notre côté on utilise Shinken. Avantage : on peut réutiliser les modules Nagios. Inconvénient : je trouve ça ps forcément top en terme d'organisation du dashboard ; je sais pas ce qu'on peut personnaliser ou pas ni ce qu'il est possible de faire en "push".
Les personas doivent représenter les utilisateurs. Si il y a 80% d'hommes, il est normal de faire peu de personas féminines (et ce n'est pas du sexisme)
On a un webdesigner dont je serais heureux qu'il donne un coup de main sur l'esthétique de LinuxFR. Ça peut s'envisager de différentes manières : travail purement graphique - choix de polices / palettes de couleurs / icones, atomic design sur les entités visuelles du site pour intégration par des contributeurs de LinuxFR…
En terme de maquettage vous (tu ?) avez fait déjà un super boulot ! Question au passage : quel outil vous (tu) avez utilisé pour les maquettes ? Gravit Designer ? C'est pas libre, si ? (j'ai pas trouvé de sources pour déployer "chez moi")
Je vois ce que tu veux dire. La détection de version est côté client, mais le stockage et la gestion des versions est côté serveur. Je ne vois pas comment le versionning pourrait être côté serveur avec du chiffrage de bout en bout (si une api préviens le serveur de la présence d'une nouvelle version on est dans le même mécanisme de détection de version côté client)
En mode non chiffré, en revanche, le versionning est bien côté serveur et totalement transparent pour l'utilisateur.
Les versions sont sur le serveur. Si tu travailles sans chiffrement, chaque enregistrement d'une nouvelle version correspond à un nouveau contenu et donc est automatiquement versionné dans Tracim.
Si tu travailles avec des fichiers chiffrés, chaque chiffrement donne un fichier binaire différent, donc sans modifier le fichier on pourrait détecter plusieurs versions alors qu'en réalité le contenu est toujours le même (il est binairement différent à cause du sel qu'on injecte dans le chiffrement)
Donc le script que j'évoque fait la distinction en local entre version en clair et version chiffrée, puis si une évolution dans la version locale est détectée, chiffre le fichier et pousse cette nouvelle version sur le serveur.
Je ne comprends pas où est la complexité de versionner un fichier chiffré :
sur ton poste client tu sais décrypter le fichier donc tu es capable de savoir à un instant donné quel est son contenu réel.
tu compares ce contenu au contenu du fichier en cours de modification.
si les contenus sont différents, tu chiffres et tu sauvegarde sur le serveur la nouvelle version
si les contenus sont identiques, tu n'envoies tout simplement pas de nouvelle version sur le serveur.
Sur Tracim on propose un versionning natif des fichiers. On ne propose pas de chiffrement de bout en bout, mais un petit script python m'a permis de valider le concept. Ce que fait le script :
- il synchronise les fichiers déchiffrés avec leur version chiffrée sur le poste client (j'ai un dossier /fichiers/non/chiffrés et un dossier /fichiers/chiffrés)
- il synchronise les fichiers dans leur version chiffrés via webdav entre Tracim et le poste client (synchronisation de /fichiers/chiffrés local et de dav://tracim/webdav/fichiers/chiffrés)
Les fichiers sont gérés et versionnés sur Tracim, leur contenu est chiffré. Sur le poste de travail on travaille sur la version non chiffrée.
Si tu es intéressé par transformer mon script "proof of concept" en client Tracim de chiffrement, je suis intéressé pour qu'on fasse ça ensemble.
Note que ça ne fonctionnera pas offline pour le versionning.
Soit on pars d'un truc minimaliste et on construit dessus. Ça permet de rendre explicite tout ce qui se passe […].
Ce qui rend le code compréhensible par tout développeur connaissant le langage mais pas forcément les bibliothèques utilisées.
Mais il peut être plus compliqué de rentrer dans le code car, justement, il a ses propres conventions. Ça peut aussi être plus compliqué, il peut y avoir des bugs subtils car l'intégration de la façon de gérer la base de données et les contrôleurs web ne correspond pas vraiment. La maintenance dans le temps peu aussi être plus complexe : mettre à jour une bibliothèque peu casser toute son intégration.
La maintenance d'une appli django est très compliquée. Les fonctionnalités de Django évoluent vite, et comme c'est basé sur des conventions qui changent/s'enrichissent, c'est très difficile de savoir ce qui est disponible et ce qui ne l'est pas sur une application donnée. Par ailleurs, les conventions et la "magie" de Django rendent des sujets a priori simples très compliqués à comprendre pour quelqu'un qui ne connait pas ou peu le framework.
Je vais prendre juste un exemple : Django propose un mécanisme de signaux pour exécuter des "triggers". C'est chouette ça simplifie l'écriture du code et tu arrives rapidement à l'objectif. Mais à lire/relire/maintenir/faire évoluer c'est une autre histoire.
Django est très bien si tu fais du pur développement web (par exemple : l'idée de réutiliser des briques de code ailleurs que dans un contexte web, c'est pas vraiment fait pour… et l'archi de Django ne t'incite pas à découper ton code en vue/logique/modèle ). Si tu es dans un environnement partiellement hors web, j'aurais tendance à ne pas partir sur un Django.
L'avantage de Django, c'est que si tu fais des choses web "classiques", tu vas hyper vite car tout est fait pour (modules disponibles, comportements par défaut correspondant à 90% des cas d'utilisation). A un moment leur tagline était qqchose comme "Django, the web application framework for projects with deadlines". En gros pour écrire vite (et si possible bien). Et ça marche bien dans ce contexte. Par exemple la gestion des migrations de modèles de base de données, les interfaces d'admin… c'est du clé-en-main. Et tu as une communauté qui créé des modules ou applications pour django qui te permettent de construire en assemblant des briques.
Mais si tu veux sortir des sentiers battus (ou prévoit de le faire), avec Django tu vas tordre ta logique de développeur pour la faire rentrer dans le moule Django et non l'inverse. Et ça, c'est pas forcément une bonne idée.
La customisation de certains élément peut, par contre être plus complexe (elle demande généralement à bien comprendre le framework).
La moindre sortie de la route tracée par Django rend le code extrêmement plus complexe.
C'est ce qui va distinguer les microframeworks comme Flask ou Sinatra des gros framework comme Django ou Rails.
Pour compléter (ou reformuler) : un framework comme Flask va te laisser choisir les briques que tu assembles, en te proposant des solutions standards (par exemple : associer SQLAlchemy avec Flask) mais pas obligatoires. Ces solutions sont de la documentation que tu vas décider de suivre ou pas. Dans un framework comme Django ça sera inclut d'office, voire difficile à remplacer si tu veux utiliser autre chose.
On a ça au bureau. Par rapport à ton cahier des charges, il manque seulement le A3 et le multibac. C'est bien supporté sous linux. Regarde dans la même gamme s'il y a des modèles multibac. Par contre, ergonomie de l'interface utilisateur de l'écran tactile à chier.
Pour une entreprises protéger ses investissements c'est légitime et c'est normal mais détruire la concurrence non. Il ne faut pas tirer sur la corde et dégoutter les utilisateurs car de plus en plus d'utilisateurs se détournent des imprimantes pour faire du zero papier. C'est tout-une économie et pleins d'emplois qui risquent d’être menacés a terme à cause du modèle économique qu'ont choisis les fabricants d'imprimantes.
C'est l'illustration que tu mélanges des choses qui n'ont rien à voir. Avoir des pratiques anti-concurrentielles c'est une chose. Programmer de l'obsolescence c'en est une autre, même si les deux sont répréhensibles par la loi.
# Scribus
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Générateur de formulaire PDF. Évalué à 4.
Scribus est logiciel dePAO - Publication Assistée par Ordinateur.
Un tutoriel video : https://a-votre-idee.fr/tuto-video-utile-creer-un-pdf-modifiable-avec-scribus-logiciel-libre-et-gratuit/
Une doc de 200 page : http://adte.ca/pdf/scribus.pdf
Et un site en français : https://scribus.fr/
# pas sûr d'avoir compris clairement ton besoin...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Logiciel de gestion de doc technique. Évalué à 4.
Ce que tu veux faire c'est :
Ou c'est plutôt :
Si c'est le premier cas, comme je l'imagine, il y a XML & XSL qui sont fais pour ce genre de chose :
En faisant des transformations XSL, tu craches n'importe quel format «text-based».
https://fr.m.wikipedia.org/wiki/Extensible_Stylesheet_Language_Transformations
[^] # Re: Randos et coins sympa
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Vacances région de Grenoble. Évalué à 4.
oui : damien point accorsi arobase algoo point fr
[^] # Re: Randos et coins sympa
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Vacances région de Grenoble. Évalué à 4.
Si tu viens ou repars en direction de Lyon ou Valence, en semaine, passes prendre un café à Algoo (sauf si c'est la semaine des RMLL). Je crois que tu fais du python… nous aussi :)
# Randos et coins sympa
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Vacances région de Grenoble. Évalué à 6. Dernière modification le 23 juin 2018 à 22:38.
En étant vers Laffrey, quelques trucs top :
Si tu as des questions, hésite pas.
# hôpital et charité
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Un rachat, un summit et un BIOS qui s'ouvre de plus en plus grâce à linux . Évalué à 7.
Si je lis entre les lignes, OVH fait partie des acteurs français avec qui vous auriez pu (aimé ?) avancer mais que ça ne s'est pas fait pour des raisons plutôt dépendantes de leur volonté.
Tu peux nous en dire plus ? (ou c'est confidentiel ?)
[^] # Re: réseau libre ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche PyConFR 2018, du 4 au 7 octobre à Lille : appel à contributions. Évalué à 4.
Tu dois soumettre ton projet aux organisateurs et qu'ils le valident.
La pub, yen a un peu, mais si tu veux être sûr d'avoir du monde c'est plutôt à toi de la faire. Regarde la page du programme de l'an dernier pour te faire une idée : https://www.pycon.fr/2017/programme.html
La bonne solution si tu veux avoir de la visibilité, c'est de publier par exemple un journal ou une dépêche sur LinuxFR :)
[^] # Re: Bravo et merci !
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tutoriel 3D - 2D découpe au laser, le retour du tux. Évalué à 4.
Je dis pas qu'il faut pas le faire, hein ! Je pense que c'est super intéressant de résoudre ce genre de problèmes (tout comme ce que tu fais et présentes dans ces 2 très bons journaux ) ; je partageais juste les retours que j'ai pu avoir lorsque j'avais échangé avec les dev de l'équipe R&D qui bossaient sur le sujet et notamment sur les calculs de parcours outil.
[^] # Re: Bravo et merci !
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tutoriel 3D - 2D découpe au laser, le retour du tux. Évalué à 10.
La découpe en biais complexifie énormément la programmation. Tu passes d'une programmation 3 axes à minimum 5 axes car tu dois piloter en dynamique la tête pour l'orienter progressivement toujours dans la bonne direction.
Ça paraît à peine plus compliqué, mais c'est très nettement plus complexe. Les éléments de base qui complexifie les choses :
Pour faire des coupes en biais, on passe d'un robot 5 axes avec projection 2D (l'axe Z est juste là pour «approcher» la tôle) à un robot 5 axes pour une pièce finie en vrai 3D (la forme n'est cairement pas la même selon le niveau dans la tôle), c'est vraiment pas la même chose…
Ça se fait : http://www.laser53.com/nos-prestations/decoupe-laser-5-axes/
Pas les mêmes machines, pas les mêmes logiciels, pas le même travail de préparation… probablement pas du tout les même tarifs…
(Note : j'ai bossé chez Alma, la boîte qui développe le logiciel de FAO utilisé par laser53 pour la découpe 3D)
[^] # Re: réseau libre ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche PyConFR 2018, du 4 au 7 octobre à Lille : appel à contributions. Évalué à 2.
Je confirme : tu soumets le projet de sprint, et sauf inadéquation ça devrait être accepté… mais l'équipe organisatrice garde (logiquement) le pouvoir, ne serait-ce que pour éviter trop de projets si le cas se présente.
[^] # Re: réseau libre ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche PyConFR 2018, du 4 au 7 octobre à Lille : appel à contributions. Évalué à 4.
Bonjour Goffi,
On a proposé un sprint l'an dernier sur Tracim, on en proposera sans doute un cette année aussi.
L'idée des sprints, c'est : tu viens avec ton projet - faire du dev sur un projet, de la doc, … peu importe. Tu « pitches » ton projet en début de journée et les personnes motivées viennent participer. Pas mal de projets viennent déjà avec leur sprint et des contributeurs. Je pense qu'il y a déjà de la comm' en amont. Ce n'est pas obligé. Par exemple on a eu des contributeurs sur nos sprints sans avoir rien anticipé. Ce qu'il faut c'est « juste » proposer qqchose qui intéresse et qui est accessible à un dev qui connaît pas ton projet.
Il me semble qu'il n'y a pas de «sélection» pour les sprints (du moment que tu rentres dans le cadre de la thématique de pyconfr).
Pour les conférences et ateliers, c'est différent car salles et créneaux horaire sont limités. (On s'était fait recaler une proposition;)
J'invite les autres visiteurs enrichir ce fil avec leur propre retour d'expérience.
En tout cas, c'est vraiment bienveillant :)
[^] # Re: Quelle est ta solution actuelle et pourquoi ne convient-elle plus ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Outil libre de monitoring. Évalué à 2.
Je connaissais pas thruk. Merci pour la découverte. https://www.thruk.org/
[^] # Re: Quelle est ta solution actuelle et pourquoi ne convient-elle plus ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Outil libre de monitoring. Évalué à 3.
http://www.shinken-monitoring.org/
# Quelle est ta solution actuelle et pourquoi ne convient-elle plus ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Outil libre de monitoring. Évalué à 4.
Ca permettra d'obtenir des réponses plus pertinentes parce que - par exemple, on ne suggèrera pas ce que tu utilises déjà (de plus ça permettra d'identifier les limitations de la solution technique).
De notre côté on utilise Shinken. Avantage : on peut réutiliser les modules Nagios. Inconvénient : je trouve ça ps forcément top en terme d'organisation du dashboard ; je sais pas ce qu'on peut personnaliser ou pas ni ce qu'il est possible de faire en "push".
[^] # Re: Personas femme?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Refaire LinuxFr.org : résultats de l’enquête. Évalué à 3.
Les personas doivent représenter les utilisateurs. Si il y a 80% d'hommes, il est normal de faire peu de personas féminines (et ce n'est pas du sexisme)
# Aide en webdesign ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Refaire LinuxFr.org : résultats de l’enquête. Évalué à 10.
Bonjour,
Je suis un contributeur régulier de LinuxFR ; je dirige une une boîte spécialisée dans le développement d'applications web dont j'ai parlé à plusieurs reprise dans les colonnes du site. On développe notamment l'outil collaboratif libre Tracim.
On a un webdesigner dont je serais heureux qu'il donne un coup de main sur l'esthétique de LinuxFR. Ça peut s'envisager de différentes manières : travail purement graphique - choix de polices / palettes de couleurs / icones, atomic design sur les entités visuelles du site pour intégration par des contributeurs de LinuxFR…
En terme de maquettage vous (tu ?) avez fait déjà un super boulot ! Question au passage : quel outil vous (tu) avez utilisé pour les maquettes ? Gravit Designer ? C'est pas libre, si ? (j'ai pas trouvé de sources pour déployer "chez moi")
[^] # Re: Retour vers le futur
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message hébergeur image gratuit sans tracking. Évalué à 3.
J'ai plussé pour la touche d'ironie sur la fin :-D
[^] # Re: chiffrement pas fichier ou de partition ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 2.
oui je vois bien :)
[^] # Re: chiffrement pas fichier ou de partition ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 2.
Je vois ce que tu veux dire. La détection de version est côté client, mais le stockage et la gestion des versions est côté serveur. Je ne vois pas comment le versionning pourrait être côté serveur avec du chiffrage de bout en bout (si une api préviens le serveur de la présence d'une nouvelle version on est dans le même mécanisme de détection de version côté client)
En mode non chiffré, en revanche, le versionning est bien côté serveur et totalement transparent pour l'utilisateur.
[^] # Re: chiffrement pas fichier ou de partition ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 2.
Tu connais qui ?
[^] # Re: chiffrement pas fichier ou de partition ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 2.
Les versions sont sur le serveur. Si tu travailles sans chiffrement, chaque enregistrement d'une nouvelle version correspond à un nouveau contenu et donc est automatiquement versionné dans Tracim.
Si tu travailles avec des fichiers chiffrés, chaque chiffrement donne un fichier binaire différent, donc sans modifier le fichier on pourrait détecter plusieurs versions alors qu'en réalité le contenu est toujours le même (il est binairement différent à cause du sel qu'on injecte dans le chiffrement)
Donc le script que j'évoque fait la distinction en local entre version en clair et version chiffrée, puis si une évolution dans la version locale est détectée, chiffre le fichier et pousse cette nouvelle version sur le serveur.
[^] # Re: chiffrement pas fichier ou de partition ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Nexcloud ou Seafile avec versionning et surtout chiffrement de bout en bout. Évalué à 3.
Je ne comprends pas où est la complexité de versionner un fichier chiffré :
Sur Tracim on propose un versionning natif des fichiers. On ne propose pas de chiffrement de bout en bout, mais un petit script python m'a permis de valider le concept. Ce que fait le script :
- il synchronise les fichiers déchiffrés avec leur version chiffrée sur le poste client (j'ai un dossier
/fichiers/non/chiffréset un dossier/fichiers/chiffrés)- il synchronise les fichiers dans leur version chiffrés via webdav entre Tracim et le poste client (synchronisation de
/fichiers/chiffréslocal etde dav://tracim/webdav/fichiers/chiffrés)Les fichiers sont gérés et versionnés sur Tracim, leur contenu est chiffré. Sur le poste de travail on travaille sur la version non chiffrée.
Si tu es intéressé par transformer mon script "proof of concept" en client Tracim de chiffrement, je suis intéressé pour qu'on fasse ça ensemble.
Note que ça ne fonctionnera pas offline pour le versionning.
[^] # Re: Position par rapport à Django ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Flask 1.0. Évalué à 9.
Pour compléter ce que tu dis…
Ce qui rend le code compréhensible par tout développeur connaissant le langage mais pas forcément les bibliothèques utilisées.
La maintenance d'une appli django est très compliquée. Les fonctionnalités de Django évoluent vite, et comme c'est basé sur des conventions qui changent/s'enrichissent, c'est très difficile de savoir ce qui est disponible et ce qui ne l'est pas sur une application donnée. Par ailleurs, les conventions et la "magie" de Django rendent des sujets a priori simples très compliqués à comprendre pour quelqu'un qui ne connait pas ou peu le framework.
Je vais prendre juste un exemple : Django propose un mécanisme de signaux pour exécuter des "triggers". C'est chouette ça simplifie l'écriture du code et tu arrives rapidement à l'objectif. Mais à lire/relire/maintenir/faire évoluer c'est une autre histoire.
Django est très bien si tu fais du pur développement web (par exemple : l'idée de réutiliser des briques de code ailleurs que dans un contexte web, c'est pas vraiment fait pour… et l'archi de Django ne t'incite pas à découper ton code en vue/logique/modèle ). Si tu es dans un environnement partiellement hors web, j'aurais tendance à ne pas partir sur un Django.
L'avantage de Django, c'est que si tu fais des choses web "classiques", tu vas hyper vite car tout est fait pour (modules disponibles, comportements par défaut correspondant à 90% des cas d'utilisation). A un moment leur tagline était qqchose comme "Django, the web application framework for projects with deadlines". En gros pour écrire vite (et si possible bien). Et ça marche bien dans ce contexte. Par exemple la gestion des migrations de modèles de base de données, les interfaces d'admin… c'est du clé-en-main. Et tu as une communauté qui créé des modules ou applications pour django qui te permettent de construire en assemblant des briques.
Mais si tu veux sortir des sentiers battus (ou prévoit de le faire), avec Django tu vas tordre ta logique de développeur pour la faire rentrer dans le moule Django et non l'inverse. Et ça, c'est pas forcément une bonne idée.
La moindre sortie de la route tracée par Django rend le code extrêmement plus complexe.
Pour compléter (ou reformuler) : un framework comme Flask va te laisser choisir les briques que tu assembles, en te proposant des solutions standards (par exemple : associer SQLAlchemy avec Flask) mais pas obligatoires. Ces solutions sont de la documentation que tu vas décider de suivre ou pas. Dans un framework comme Django ça sera inclut d'office, voire difficile à remplacer si tu veux utiliser autre chose.
# Brother DCP9020CDW (simple bac)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Cherche imprimante scanner multi bac compatible Linux. Évalué à 2.
On a ça au bureau. Par rapport à ton cahier des charges, il manque seulement le A3 et le multibac. C'est bien supporté sous linux. Regarde dans la même gamme s'il y a des modèles multibac. Par contre, ergonomie de l'interface utilisateur de l'écran tactile à chier.
[^] # Re: Halte à l'obsolescence programmée...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Du rififi dans ta cartouche d’encre. Évalué à 7.
C'est l'illustration que tu mélanges des choses qui n'ont rien à voir. Avoir des pratiques anti-concurrentielles c'est une chose. Programmer de l'obsolescence c'en est une autre, même si les deux sont répréhensibles par la loi.