Quoi, t’aimes pas les parenthèses ?
(Je répète, c’est surtout de la curiosité, si je fais ça un jour je me réserve le droit de changer d’avis au bout de deux semaines).
1 « J'aime »
Le truc le plus gros que j’aie vu là dessus est jinteki.net. C’est impressionnant la vitesse à laquelle ils implémentent les nouvelles cartes à chaque sortie d’extension. Et pourtant le jeu a un fonctionnel très complexe, même si ça s’est calmé depuis la fin chez FFG. C’est codé avec du clojure qui tourne sur Node.
Oui j’avais vu (mais je ne suis pas allé fouiller dans le code, il faudra d’ailleurs, si je trouve le temps un jour).
Après toutes les mécaniques sont loin d’être implémentées, mais il faudrait un autre thread. 
Je recrute des gens de qualité, c’est tout. S’ils sont smart et curieux (les deux vraies qualités que je recherche) ils apprendront bien vite à coder en Élixir. Pour l’instant ce choix a fonctionné et les gens que j’ai embauché sont désormais très productifs.
Une tête bien faite vaut mieux qu’une tête bien pleine
2 « J'aime »
Tu n’as pas lu ce que j’ai écrit en fait.
lol si mais j’ai compris de travers.
Mais du coup on est d’accord 
2 « J'aime »
Mon premier souci a été de vérifier que ça fonctionne avec Sql Serveur 2008 Express, ou tout au moins Sql Server Express, c’était le principal. Avec en plus d’essayer de ne pas être cantonné à une version ancienne de Django. Donc finalement j’y suis arrivé avec https://pypi.org/project/django-mssql-backend/ (en faisant bien des pip uninstall des packages essayés avant: s’il y a un vieux pyodbc il le garde mais downgrade tout).
J’ai vu qu’à l’instar du cran pour R, l’entrepôt anaconda n’a pas les versions hyper récentes ni tout les packages Python. Dans un environnement virtuel anaconda que j’ai créé j’ai pu avoir la version 3.x de Django via pip install qui n’existe qu’en version 2.x via conda install (ou tout cas en packagé).
J’ai joué avec migrate et je pense que je vais faire les mises à jour de table à la main en SQL car il me fait des misères pour des modifications mineures: sql server ne veut pas renommer un champ, il est vrai en PK (*) . J’espère que je ne vais pas avoir les mêmes surprises pour l’ORM et les mises à jour de données des formulaires.
J’ai quand même 2 questions sur migrate:
- comment forcer pour rejouer une étape en particulier, il faut modifier les données dans la table migrations ?
- à l’inverse, par exemple mon renommage, il y a moyen de lui dire, « t’inquiète, je m’en suis occupé » (idem en modifiant la table migration).
Ça serait cool que ça soit possible ça me permettrait d’utiliser migrate sans être bloqué par le fait que Sql Server n’est pas un composant interne à Django (c’est à dire pas supporté par Django Project). En plus je cherche des ennuis avec ma vieille version de Sql Server : ancienne pour qu’une vieille appli 32 bits d’environ 15 ans puisse y faire des exports.
Avant de lire un tutorial complet et récent je voulais déjà faire mumuse avec la base de la base. Je l’ai donc fait avec le début de ce mini tutoriel sur mon Django 3 (bien qu’ils parlent d’une très ancienne version de Django) . Principalement pour tester les principaux cas de figure avec Sql Server Express.
http://codehubpython.appspot.com/django
édit : *= Je ne serai pas étonné que même avec une version 2012 voire vraiment récente, il ne sache pas plus faire cela puisqu’il ne me semble pas que les DDL de Sql server aient beaucoup changées.
Puisque la discussion a un peu dérivé et s’est conclue par le choix de Python, my 2 cents concernant la partie front de ton app : je te déconseille d’utiliser n’importe quel framework JS connu (react/vue/angular) a moins que tu fasses une vraie app, comprendre un configurateur, une IHM custom, etc… En gros vaut mieux servir du html si le state de ton app n’a pas besoin d’être conservé d’une page à l’autre.
Dans le cas où 90% de ton site serait statique mais tu aurais une app un peu velue à un endroit (c’est souvent le cas dans les outils pro) dans ce cas tu peux t’épargner une stack JS en utilisant simplement VueJS via une balise script pour ladite page et ainsi charger ton app dedans, comme si c’était jquery en gros. Tu t’épargneras le tracas d’avoir une stack frontend en JS tout en conservant les bénéfices de bosser avec VueJS qui il faut l’avouer est agréable à utiliser a de chouettes outils de dev.
Si aucune grosse application mais que tu as besoin d’un peu d’interactivité dans chacune de tes pages et que tu veux compartimenter un peu pour ne pas retomber dans le spaghetti à la jquery, je te conseille de regarder du côté de Stimulus : https://stimulusjs.org/
Voila voila, bon courage pour le projet. 
1 « J'aime »
Current version: 1.1.1 — released January 07, 2019
Utiliser un framework JS qui ne sort pas une version majeure toutes les deux semaines ? Hérésie ! 
Disclaimer: je ne connais pas stimulusJS, c’est gratuit.
1 « J'aime »
C’est un framework utilisé conçu et maintenu par Basecamp dont un des cofondateurs est le créateur de Ruby on Rails. Une nouvelle version devrait bientôt arriver qui permettra plus de choses. En attendant je te conseille de lire la page expliquant le projet : https://stimulusjs.org/handbook/origin
2 « J'aime »
+1 pour Stimulus, c’est simple, c’est frais !
1 « J'aime »
Ça a l’air sympa effectivement ce stimulusJS.
J’ai du loupé quelque chose: est-ce qu’il y a une raison particulière pour ne pas utiliser une DB supporté par Django de base ?
Uh ? Ça fait longtemps que je n’ai pas utilisé conda, mais si j’en crois cette page c’est bien la dernière version de Django qui est dispo (3.1.2)
As-tu regardé la page dédié aux migrations dans la documentation ?
conda install ne me rapatriait que la 2.x. En tout cas ça correspond au tableau : linux-64 : v2.2.5. Peut-être que ça vient du fait que la 3.x, que j’ai bien vu, est en noarch (je ne connais pas encore). Après peut-être qu’avec mes divers essais j’avais une dépendance qui me faisait descendre de version. Toujours est-il qu’avec pip ça a fonctionné tout seul.
Oui je l’ai regardé 
et j’ai cherché et je n’ai pas trouvé la réponse à mes 2 questions (après y’en a des tartines, peut-être loupé dans ma recherche). Merci pour le RTFM, y’a très longtemps qu’on ne me l’avait pas fait 
.
J’avais peut-être mal rédigé ma phrase mais la revoici ci dessous annotée. Quelque fois un package n’existe pas sur conda, là il n’existait qu’en noarch, mais ça ne voulait pas.
En général quand je n’arrive pas à récupérer un package, (et là visiblement avec noarch ça ne voulait pas) quelque soit l’environnement logiciel, je change d’entrepôts. Je descend du ou des entrepôts a priori les plus validés… jusqu’à éventuellement la version github de développement si rien n’y fait.
édit :
Oui j’en ai écrit la raison ci-dessous.
La 2e raison, c’est que comme il n’y a pas d’autre informaticien, il faut que la base de données soit facilement accessible d’un environnement windows. Après j’aurais pu faire des transferts sqllite vers Sql Server, mais autant que toutes les bases soit sur le même moteur de base de données, comme celle du projet R Shiny en Sql Server pour les mêmes raisons.
Tiens je viens de tomber sur 3 articles:
- quelqu’un qui était à 200% Django et qui maintenant les apprécie tout les 2
- Un mini tutoriel en français plus clair que le mini en anglais (avant que je lise un vrai gros tutoriel complet et récent )
- Un article qui peut plus ou moins répondre à mes soucis de migration avec Sql Server.
Alooors. J’ai fait le POC pour tester Django avec Sql server et a priori je n’ai pas de surprise (avec le mini tutoriel en anglais). C’est vraiment compact et puissant
J’hésite à exclure les tables métiers du migrate avec managed = False, à cause des soucis de mise-à-jour de la structure des tables Sql Server indiqués dans les précédents messages. (Et j’ai lu l’idée de laisser la base technique Django en sqllite et les données métiers en sql server. Mais je ne suis pas sûr d’y voir un intérêt.)
Tout à fait d’accord. Pour du front c’est un peu chaud pour utiliser un framework front comme tu le dis, et je risque de ramer de mener de front l’apprentissage et la mise en place de Django et d’un framework front.
En revanche, l’intéractivité et la souplesse des post Ajax risquent de me manquer. Et j’ai vu cette solution qui paraît a priori simple, qui garde la logique des views et templates tout en utilisant des serializers back Django et des serializers front jquery.
Trucs en vrac:
- J’aime bien les billets de sametmax sur Django (et Python en général). J’aurais voulu le découvrir plus tôt.
- Pareil pour tout ce qui est sur Realpython
- Pour apprendre en premier Django, j’ai trouvé le tutorial de Mozilla plus accessible que celui de Django, mais surtout parce qu’il correspondait de manière plus proche à ce que je voulais réaliser avec Django (une collection de vidéos stocké ailleurs)
- Pour plus tard: ce mec (un core developer de Django) et sametmax s’accordent: les class based views, c’est bien quand on suit un tutoriel, et quand on développe un truc pour la première fois, mais c’est beaucoup moins fun quand on doit reprendre le code 3 mois plus tard et/ou si quelqu’un d’autre reprend l’affaire (notamment parce qu’il faut connaitre les mécanismes internes et implicites de Django qui interprètent les déclarations dans les CBV), alors que les function based views sont conceptuellement plus simple (« c’est une fonction qui te renvoie un objet
HttpReponse»). - Django ORM Cookbook m’a aidé lorsque je voulais obtenir des donnés de mon Django de manière un peu funky.
J’ai lu/entendu (blog ? podcast?) qu’un des trucs chouette de Django c’était son ORM (le machin qui transforme le concept des objets de Django en query dans ta base de donnée). Avoir une application tierce qui modifie une base de donné de Django me parait un peu périlleux (?). Cela dit il y a une page de la doc qui semble couvrir en partie ce cas de figure (Integrating Django with a legacy database).
C’est une solution qui te fait construire des réponses REST à la main, mais il y a un package très populaire qui s’occupe d’automatiser tout ça en tenant compte de tes modèles existant: Django Rest Framework .
1 « J'aime »
Les trucs de mise à jour auto du modèle font frémir les DBAs et ça complique les déploiements multi-instanciés. C’est commode mais sur des petits déploiements.
2 « J'aime »
C’est clair qu’ayant été presque DBA, ça m’aurait inquiété : pour moi dans le cas que tu décrit il faudrait laisser générer les delta SQL sur une base de qualification, et livrer des ALTER TABLE déduits et validés.
Je me méfie de tout ce qui est génération de SQL, surtout pour en avoir vu pas mal quand je faisais de la BDD et de la BI. Pour moi l’intérêt de d’un ORM, c’est pour faciliter les CRUD, et c’est pour cela que je souhaite avoir un ORM.
Par contre pour des requêtes complexes il faut revenir au SQL « pur ». Par exemple je me sers en partie de la librairie R dbplyr pour générer des requêtes SQL pour l’aspect dynamique des SELECT et GROUP BY sur une table temporaire ou une vue matérialisée (et je la modifie derrière le cas échéant avec des expressions régulières) . Mais dès que ça se complique ce qu’on gagne au départ on le perd en performance, et en traitement cible : pour les SELECT et GROUP BY ces générateurs sont pratiques mais les jointures sont souvent mauvaises et erronées, c’est rarement conforme à ce qu’on attend sans parler du fait que ça génère du SQL spaghetti.
Surtout si le SGBDR n’est pas un composant géré de base par Django comme Sql Server.
J’ai vu ce package mais on n’a plus les views et templates Django en back, à moins que j’ai loupé un épisode (ou pas trouvé d’exemples le faisant).
Sinon merci pour tes liens que je vais regarder.