Donc pour récapituler. Je travaille depuis un peu avant 2000, j’ai fait du client / serveur et du Delphi pendant 5 ans, puis du décisionnel pendant 15 ans (BI, datawarehouse, SQL), puis j’ai été Product Owner un an et demi dans une boîte éditeur de logiciel qui a attisé mon envie de refaire du « vrai » développement.
Maintenant je fais du développement et en février prochain ça fera 3 ans que je fais du R Shiny (+ un peu de Python, Javascript, ssh, shell script) et je ne m’étais jamais autant éclaté en dépit qu’on dise qu’après 40 ans on ne devrait pas faire du développement (je viens d’avoir 10 de plus).
Je ne voudrais pas lancer une guerre de chapelle mais si je veux continuer dans le même sens Django est davantage logique que Symfony qui n’a de rapport que le développement Web, même si ce dernier est largement plus utilisé mais aussi plus concurrentiel.
En plus Django avec Python existe chez des clients plus industriels et scientifiques, les même qui utilisent R Shiny. Tandis qu’en php il y à boire et à manger: du super intéressant et professionnel, aux maintenances de sites spaghetti qui ont 20 ans.
J’ai été approché notamment pour être support d’essais cliniques, très valorisant, mais c’était trop admin ou trop data scientist et en 100% télétravail, ce qui est pour moi un souci si c’est 100% ou presque.
J’ai pas bien compris ta question : tu cherches à savoir si tu dois accepter plutôt un job PHP Symfony qu’un job Python Django ? Ou tu demandes quelle est la meilleure stack dans l’absolu ?
En fait vu mon profil et mon CV actuel, où j’ai viré les expériences BI sur LinkedIn, on me propose du R Shiny et tout ce qui est proche de ce domaine ce qui me va bien.
Et je pense m’autoformer, sachant que R Shiny est très puissant en données et visualisation, mais il faut réinventer la roue pour les CRUD. C’est intéressant de créer un système de CRUD à partir de rien, sauf le D de CRUD, mais ça a vite des limites.
Au début j’ai pensé à Symfony car très répandu et puissant mais finalement Django semble davantage dans la logique de mon profil. Sauf si c’est une daube, ce que j’ignore. Mais Symfony bien que très puissant me paraît être un peu une usine à gaz et davantage concurrentiel vu mon âge.
Quelques éléments à prendre en considération, pour répondre un peu « à côté » mais te donner des idées :
Python c’est plutôt de nos jours un langage orienté « data » et « infrastructure », tu vas retrouver pas mal d’employabilité dans des postes comme l’automatisation, le traitement de données (big data), etc. C’est aussi un langage qu’on retrouve plus largement dans des entreprises de petite taille pour des usages Web, mais ce sera moins vrai dans des grosses boîtes (banques-assurances notamment)
PHP est toujours le langage n°1 du web lui. Il est moins populaire dans les grosses boîtes (qui sont souvent passées sur des frameworks Javascript j’y reviens ci-dessous). Tu ne peux pas te tromper on te formant sur un framework PHP si tu es déjà à l’aise avec le langage et que tu cherches du boulot dans du développement de sites. Même les grosses boîtes qui font du JS majoritairement continuent à avoir du PHP, notamment pour des plus petits sites (communication, marketing, etc.).
Javascript en tant que langage de développement Web est omni-présent avec les deux gros frameworks Angular ou ReactJS chez les grosses boîtes, qui délaissent souvent PHP pour les gros portails clients, pour des architectures plus complexes. Si tu veux adresser le monde des grosses boîtes, ou si tu veux prendre un virage, c’est une bonne piste de formation.
Une fois qu’on a dit ça, tu as l’air d’avoir plutôt de la bouteille en R. La bonne vieille règle de l’art de la guerre : miser sur ses points forts et abandonner ses points faibles. Donc la vraie question c’est : est-ce que tu veux miser sur des compétences web ? ou est-ce que tu veux faire de la data et miser sur tes compétences en R ? ou encore est-ce que ton point fort c’est au contraire d’être polyvalent plutôt dans une petite structure, comme homme à tout faire ?
Et deuxième niveau de question…
Si tu veux faire du web, est-ce que tu veux développer du côté serveur (PHP, Python, pages statiques) ou du côté client pour faire tourner des applications en JS ? Sauf à bosser dans une très petite structure tu pourras difficilement faire les deux.
Si tu veux faire de la data, est-ce que tu veux faire de la glu applicative (imports/exports, traitements en masse, automatisation…), ou est-ce que tu veux faire de la présentation (IHM type CRUD, reporting métier) ? Là aussi, en grosses structures les postes sont souvent séparés. Côté data tu vas avoir envie de murmurer à l’oreille des bases de données de BI, ou de faire des bus de messages comme Apache Kafka. Tandis que du côté présentation tu vas plutôt aller développer des API et donc t’intéresser aux concepts associés (REST etc.) ; et laisser des équipes dédiées et coder les pages dans les langages plus web (typiquement JS).
Note que même en petites structures, les mêmes questions vont se poser. Tu vas faire de tout… Mais tu ne vas pas pouvoir consacrer ton temps à tout au niveau progrès et formation. Donc si tu devais choisir, qu’est-ce qui te fait kiffer ?
En fait j’ai commencé par faire des petits écrans R Shiny d’affichage de requêtes SQL de la mort et de proche en proche j’ai fait des traitements R dplyr de la suite tidyverse, puis j’ai fait des écrans R Shiny de plus en plus sophistiqués.
Autrement dit j’ai démarré avec mes compétences back provenant de la BI pour faire aussi pas mal de front alors que je croyais que cela ne m’intéresserait pas alors que c’est marrant aussi de trouver des solutions ergonomiques. Et en parallèle j’ai fait des traitements shell avec du ssh.
Et donc le front et le back m’intéressent et visiblement R Shiny, à part chez mon client où j’ai plusieurs milliers de lignes pour le même projet, il me semble qu’en général c’est plusieurs petits projets où on peut faire du back et du front. Et effectivement ce que tu dis confirme l’impression que j’ai lu que c’est la même chose pour Python.
Autant les apt-get me gonflent au bout d’un moment, autant les scripts de traitements fonctionnels de données me bottent.
Ça me va, je ne supporte pas de travailler en banque et assurance : hiérarchie rigide, bureaucratie, et moi qui m’intéresse au côté métier je ne comprend pas leur fonctionnel sans parler de la finance que je n’apprécie pas.
AMHA c’est tout le cheminement qui est intéressant, pas uniquement l’IHM, autrement dit pas que « faire un site ». Et effectivement faire du CRUD à longueur de journée risque d’être lassant… sauf si le travail n’est pas trop taylorisé.
Je le méfie de cela : ce qui m’avait écarté de la BI c’est principalement les ETL (j’étais expert Oracle Data Integrator et Datawaherouse) qui me gonflaient grave et devenaient de plus en plus clique-boutons. Je voudrait éviter d’y revenir. En fait toutes les offres qui appatent avec R ou Python mais qui insistent très lourdement sur la nécessité de connaître un ETL je m’en méfie énormément, c’est un piège. Ça m’a toujours agacé ces interfaces dont les décideurs kiffent comme quoi c’est l’avenir pour un monde sans développeurs… mais qui reviennent au bout du compte aux SI mais sans le plaisir du « vrai » développement avec des recherches d’algos et de résolution technique.
Je suis « obligé » de faire du développement Web puisque R Shiny est très limité en CRUD. J’aime bien ce que je fais en R mais comme mon niveau en maths et stats n’est pas suffisant je ne peux pas être Data Scientist, et il faut que j’ai d’autres cordes à mon arc… comme savoir faire un minimum d’IHM et de CRUD. Homme à tout faire : si c’est pour changer les cartouches d’encres, à part épisodiquement, non.
Les reporting métiers : je ne voudrais pas refaire du Business Objects d’autant que j’ai vu qu’en R Shiny la visualisation de données est vachement plus dynamique et interactif.
J’ai fait une autoformation en Angular, ça me paraît très carré voire presque trop, et je l’ai vu en action quand j’étais Product Owner. En fait si le projet n’a pas été pensé au départ pour Angular c’est mission impossible (là ça avait été conçu dès le début). Donc ça restreint un peu plus les projets. Pour avoir jeté un coup d’œil à React j’ai l’impression, peut être fausse, que ce n’est pas très MVC. Vue me paraît plus propre mais moins répandu. Mais faire du front sans back j’ai un peu de mal. Au bout du compte faire du back avec un peu de connaissance front, voire faire du back + REST me paraît peut-être plus logique étant donné mon parcours.
À te lire et en y réfléchissant la direction Django+Python m’a l’air peut-être préférable pour moi. En tout cas tu n’a pas l’air de me dire que Django est à éviter.
édit :
L’un comme l’autre, Django ou Symfony, je peux le faire chez mon client actuel. Django semble rester davantage dans la logique de ce qu’il y a déjà. Même s’il y a des bouts de php mais pas de Symfony.
Franchement pour moi Symfony c’est un peu à éviter. Quitte à faire du PHP il y’a des frameworks comme Laravel qui sont plus modernes.
A choisir je te conseillerais quand même de partir sur Python qui a une stack web pas trop mal (Django) et une lib de datascience au top (scikit) vu que ça a l’air d’être ton dada.
Et dans l’absolu, comme j’ai fait du dev dans pas mal de technos (beaucoup de Java, un peu de php, beaucoup de Ruby et pas mal de NodeJS) ça fait maintenant 4 ans que j’ai jeté mon dévolu sur Elixir (avec son framework web Phœnix) et c’est vraiment le top ! Sur Paris ou en remote tu peux trouver des jobs sur cette techno et au moins (contrairement à Symfony) tu sais que tu vas bosser avec des gars qui touchent un peu leur bille (sinon ils auraient pris la même techno que tout le monde )
Si Élixir t’intéresse ou que tu te demandes pourquoi Elixir ? Je peux faire un autre post mais demain !
Ben dis donc tu ne portes pas dans ton cœur Symfony ?!
Ça a l’air vraiment sympa comme langage Élixir. On dirait un mélange de R et Python.
Après je n’en ai jamais entendu parler. Ce n’est pas un peu confidentiel comme utilisation ? C’est quoi comme type d’applications et type d’entreprises qu’ils l’utilisent. Autant Django chez mon client peut passer comme une lettre à la poste en disant le mot Python, autant Élixir j’aurais plus de mal à le vendre je crains.
Est-ce qu’il a la même puissance de modifications de données que Numpy ou Dplyr ? J’ai l’impression en lisant en diagonale des infos dessus que c’est davantage temps réel : j’en conclu peut-être à tord que donc moins métier ?
Ah tu me dis que c’est bien Django , et effectivement Python est dans la suite voire même complèment de R.
Vu ce que tu dis de ton profil, de tes connaissances, et ce que tu montres comme intérêts, je pense que tu serais probablement plus à l’aise, et que tu t’éclaterais plus, en faisant du Python. Surtout si tu as l’air de kiffer quand même aussi le shell, autant faire d’une pierre deux coups
Si je devais te proposer une fullstack Python, pour pouvoir voir aussi bien le backend que le frontend, je pense que ce serait :
Alchemy pour l’intégration SQL
Flask comme framework front pour faire des dashboards, qui est plus léger que Django et donc plus souple pour apprendre (après je suis biaisé, quel que soit le langage je n’aime pas les gros frameworks qui te vendent des économies d’échelles à l’horizon plus lointain que leur vie ^_^… j’aime les trucs simples et rapides à mettre en oeuvre)
regarde tout particulièrement du côté des API REST, car même si tu fais des dashboard en Flask faire des API reste le moyen désormais universel de découpler front/back si tu veux bosser dans des contextes où les apps seront en JS
Mais en fait ce qui, à mes yeux, fait toute la qualité d’un développeur de nos jours c’est plutôt la maîtrise des outils que celle des frameworks. On change bien moins souvent d’outils que de framework en passant d’un job à un autre ou d’un projet à un autre (ou même en touchant aux projets Open Source sur la toile). Et donc on a bien souvent plus de gains à maîtriser les outils pour vite démarrer un projet, ou le prendre en main. Ce qu’on nomme pompeusement craftsmanship :
gestion des dépendances, c’est la base, regarde du côté de PyPI : packaging · PyPI
les tests unitaires, là aussi la différence entre un projet poubelle et un projet sérieux : je conseille PyTest personnellement (mais n’hésite pas à aller faire un peu de veille pour te familiariser avec les atouts/inconvénients des autres)
Et puis vu que tu es déjà plus qu’un bon pied dans le monde data, jette un œil à Apache Airflow. Le projet a ses défauts de jeunesse, mais il perce un peu dans le monde très rare des frameworks d’orchestration de traitements. C’est justement un outil en Flask + Alchemy; donc en plus si tu veux regarder sous le capot…
J’ai un collègue qui ne tarissait pas d’éloges sur Elixir. Mais alors là, tu rentres dans la niche, avec de la programmation réactive etc. C’est un peu comme Golang, dans la catégorie des langages géniaux mais pas du tout avec la même employabilité
Ha je l’ai vu apparaître plusieurs fois, je vais regarder. Effectivement si je pouvais éviter les frameworks trop gros, quitte à aller chez Django ensuite.
oui c’est indispensable.
Vu mon parcours je n’ai jamais encore fait de test unitaire mais j’ai commencé à me documenter. Et même si j’aurais du mal à en rajouter après coup dans mon projet actuel en R je vois comment et à quel endroit je devrais en mettre de façon prioritaire… car à cet endroit de changer la moindre virgule me stresse un peu surtout que c’est très métier à l’endroit auquel je pense.
En R il « suffit » de mettre dependencies= TRUE mais de dérouler la pelotte de laine peut durer assez longtemps… surtout avec un adsl d’entreprise en pleine campagne.
À l’opposé les dépendances NodeJs m’ont l’air d’être des usines à gaz.
De ce que j’en ai vu sur Python on peut procéder comme en R… mais c’est peut-être plus pro et puissant d’avoir un gestionnaire de dépendances. En R je viens de revérifier à part des solutions persos il n’y a pas de gestionnaire de dépendances.
Il manque une info : est-ce que tu vise du site web jetable façon web agency ou c’est du site triste interne d’entreprise ? Sous-entendu, est-ce que ça va devoir être maintenu 10 ans ou est-ce qu’on va le jeter dans 2 ans parce que la fraîcheur est ce qui compte ?
Autant, pour le site tout shiny et sexy, tu peux y mettre n’importe quoi vu que la maintenance sera quasi absente. Sur le site d’entreprise, vaut mieux s’orienter vers des frameworks vieillots et éprouvés, sur lequel ça sera facile de recruter des gens pour la maintenance long terme. Donc dans les trucs internes d’entreprises, tu vas direct oublier les frameworks python parce que c’est encore problématique pour recruter des devs pythons. De manière générale, le cycle de dev des outils web à la mode est souvent problématique pour la maintenance de long terme.
Bisous aux autres qui ont eux aussi encore de l’ASP et du JSF dans leur boìte
Effectivement, ce conseil est judicieux (*) mais… :
Certes mais si je ne m’oriente pas vers des sites vitrines de Web agency, les projets internes orientés données industrielles ou scientifiques sont davantages dans la logique Python / R. Pour des sites de Web agencies j’aurais suivi ton conseil.
Oui car trop jeunes et pas encore complètement organisés.
Noooon pas du VB pour le Web.
edit: * =Par contre je note ce conseil pour Django / Flask.
Je suis tombé sur 3 articles Django / Flask. J’ai l’impression en les lisant que Flask est trop permissif, pas assez structuré et trop dépendant de packages externes. Or bien que j’ai déjà utilisé un framework, CakePHP pour un unique site… finalement non livré pour un proche, je risque d’oublier des trucs ou d’avoir trop de libertés. Et si je veux valoriser un minimum mon employabilité.
Après si Django est trop une usine à gaz surtout pour la dizaine d’écran que je veux faire au début… peut-être que j’y viendrai, mais ces 2 articles me semblent pertinents. Qu’en pensez-vous ?
Pas juste pour ça, mais aussi parce que par exemple React et Angular ont des cycles de devs sans LTS (React), ou avec des LTS d’une durée de maintenance ridicule (Angular, 1 an). Idéalement on s’en fiche, mais si t’as un souci avec une lib d’un composant tiers, tu l’as dans l’os pour les mises à jour. Soit ils suivront les mises à jour du framework et dans ce cas t’es embêté parce que ça t’oblige souvent à mettre à jour, soit ils restent bloqués sur une vieille version et ça te gêne pour upgrader.
Dans les deux cas tu perds.
De mon coté, je ne fais que du prototypage. Django comme Flask ont des avantages et des inconvenants. Faire une API REST avec Flask, ça prend littéralement 5min. Faire tout un Front… bin c’est long et faut partir sur des fondations solides.
Avant de partir sur les framework, il faut prendre le temps de bien apprivoiser le langage (pip, venv,etc.) et les « lib classiques ». En python, t’as numpy ou panda qui sont des incontournables des que tu fais un peu de data.
C’est du 100% génie logiciel.
(et pas oublier que quand on est passé de python 2 a 3, beaucoup ont pleuré des larmes de sang)
Encore une fois c’est un avis strictement personnel, issu de mon expérience, mais la flexibilité d’un framework light peut être un intérêt plutôt qu’un handicap.
Il faut que tu te poses la question des fonctionnalités dont tu as besoin. Typiquement, l’une des plus importantes c’est la gestion des droits d’accès. Est-ce que ton application va devoir se connecter à un truc genre Active Directory ? Ou au contraire est-ce que tu vas créer des comptes locaux dans une base de données dédiée ? Voire même ne pas mettre de politique d’accès et faire un dashboard open-bar ?
Et des questions comme ça il y en a plein… Est-ce que tu auras besoin de tel ou tel type de connecteur à tel ou tel type de middleware ? Est-ce que tu as des besoins complexes en termes de modèles de données ou pas ? Etc. Pour faire simple, un framework comme Django va répondre à chacune des questions avec SA réponse ; et tu devras faire comme il dit. Avec un framework light comme Flask tu devras chercher une lib adaptée, parmi celles qui existent. D’un côté tu bénéficies du travail de gens qui ont fait la curation des libs, mais en échange tu dois embarquer tout un tas de code qui ne t’intéresse pas forcément et déléguer les choix ; de l’autre tu peux faire ta propre curation pile poil en fonction de ce que tu veux, mais en échange tu peux te tromper et choisir un truc qui finalement ne sera pas si bien dans 2 ans…
En abordant ce genre de choses tu rentres dans des considération d’architecture logicielle. J’ai vu plein de monde faire cette erreur avec le monde Java et le Java entreprise (Java EE / J2E). Si tout ce dont tu as besoin c’est SQL -> classes modèles de tes données -> dashboard web, alors Flask + Alchemy seront bien plus simples à apprendre.
En fait pour mon projet en cours, démarré en R Shiny mais avec reinventage de CRUD (que j’avais mis en place pour un précédent formulaire), j’ai l’impression que Flask sera suffisant. D’autant qu’il n’y a pas de besoin d’AD ou autre. Mais finalement l’écran que j’ai fait s’est révélé être comme une maquette : ça a permis à mon utilisateur de mieux savoir ce qu’il veut et c’est-à-dire en fait quelque chose de bien plus complexe.
D’où ma question sur les frameworks ici. Et si Flask suffirait au début, pas sûr qu’il reste suffisant par la suite. On est dans une sorte d’échange de demande de fonctionnalités à l’arrache tout à l’oral, qui se modifie au cours du temps.
La base est Sql server à laquelle je me connecte via une solution odbc pour Linux Ubuntu.
Pour ce qui est de Dashboard Web, R Shiny est très bon, là il s’agit plutôt de formulaires de mise-à-jour qui risquent d’être complexes dans leur ergonomie.
Et je ne peux pas continuer avec mon CRUD perso R Shiny, inspiré de morceaux de codes picorés sur github et stackoverflow. Il faut que la solution de framework soit quand même plus structuré que ce que j’ai fait en R Shiny pas fait pour cela, contrairement à ce que j’ai fait depuis 2 ans et demi sans CRUD ou très peu.
Que penses-tu de ces articles ? Sérieux mais trop perfectionniste ces articles ? J’ai suivi les 3/4 d’une autoformation Symfony: après avoir mis en place mon cakePHP ça me semblait beaucoup moins compliqué qu’avant. Avec ces bases apprendre un autre framework ne me paraît pas si compliqué.
Après tu vas me dire : ok tu te sens capable d’apprendre un framework complexe mais est-ce que ça répond vraiment à tes besoins, ben je ne sais pas encore .
Si tu me dis que Django est un peu surdimensionné pour ce que je veux faire. Mais j’ai peur d’avoir du mal à le faire évoluer si ça devient plus complexe, j’ai besoin d’un minimum de structuration. Si ça part d’un truc cool rapidement fait et efficace en Flask mais qu’ensuite j’ai besoin de plein de solutions externes qui partent dans tous les sens…
Les articles sont justes. Ils arrivent à la même conclusion que moi, mais juste pas au même choix, parce qu’ils ne parlent pas des mêmes besoins : structurer (Django) vs prototyper/livrer rapidement quelque chose d’exploitable (Flask) ?
Le sens de l’histoire côté développement c’est un ensemble de bonnes pratiques et de manière de choisir ses efforts :
livrer vite des choses qui fonctionnent pour l’utilisateur, pas des fonctionnalités sur le papier
quitte à se tromper; se tromper tôt (fail fast), et donc passer des séquences plus courtes sur le code, entrecoupée plus régulièrement de retours utilisateurs et d’analyse des usages
livrer plusieurs logiciels qui collaborent, plutôt qu’un gros logiciel qui fait tout (c’est pour ça que les API sont désormais si populaires)
un bon modèle >> un bon framework (un bon modèle est réutilisable à travers des frameworks différents)
une bonne API >> un bon framework (idem)
ou pour généraliser les deux points précédents, les surfaces d’échanges entre le logiciel et le reste du monde sont plus importantes que les rouages internes ; càd que tu adaptes plus souvent ton appli à un changement qui vient de l’extérieur, que pour promouvoir un changement interne => c’est plus important de mettre l’effort là où tu sais que le changement va avoir lieu, pour réduire les coûts, que pour avoir un beau moteur que toi seul touche de toute façon (et que tu peux jeter et refaire si un jour ça vaut vraiment la peine)
Pour toutes ces raisons, je n’aime pas les frameworks. Un framework te dit « vas-y, embarque moi pour 5 ans et le cadrage technique est gratuit grâce à moi ». Sauf que le cadrage technique, sauf à être vraiment ultra-pressé, c’est peanuts sur le long terme. Sur le long terme ce qui est coûteux c’est la qualité du modèle et des API, et le fait d’aller sans cesse comprendre comment les changer pour t’adapter aux utilisateurs.
Pour le dire autrement, si tu te plantes dans les grandes largeurs, et que la structure de ton projet va à la poubelle une fois pendant les 5 ans parce que tu as appris, et que finalement tu comprends mieux comment tout doit s’arranger… Bah ça va te faire quoi ? Quelques semaines ou quelques mois de dév perdus pour un gros refactoring ? C’est rien (à l’échelle de la vie d’un projet)… Et c’est peut-être même moins que ce que tu vas être obligé de passer comme temps à te former au framework, en échange de quoi tu auras appris un truc par cœur sans le comprendre forcément (avec un framework tu seras bon en « comment », sans maîtriser le « pourquoi »).
Prendre un framework du coup ça répond à d’autres besoins. Et notamment le fait d’avoir beaucoup de gens autour de beaucoup de projets. C’est un truc de grosses structures. Et de hype. Ne pas sous estimer le pouvoir de la hype…
Bref, pour apprendre, le mieux c’est les mains dans le cambouis. C’est ce qui fait progresser.
Et quand je dis ça au dessus, ça te fait dire cela en dessous en fait ?
Surtout si je suis dans une petite structure (je suis le seul informaticien) ? Et que si j’ai réussi à faire un gros projet en R Shiny j’aurais un minimum de structure ? Ok. Mais par contre ça risque d’être une structure made by Philippe non généralisable ailleurs, mes petites API en quelques sortes.
Par contre il y a quand même des gestion de CRUD digne de ce nom ? Et le fait qu’il y ait zéro structure ça me gêne un peu. En fait il faut partir d’une structure à la Django mais sur Flask comme dit dans les articles ? Tu as un tableau comparatif des fonctionnalités entre Django et Flask, ni trop gros ni trop petit, stp ?
)
.
.