A : Spring, React, Android, iOS, on en prend une seule personne
B : On peut en prendre quatre, une personne pour chacun, non ?
A : J’ai dit qu’on n’en prenait qu’une seule
B :
À mon avis, dans une application hybride, la méthode classique de communication entre le web et l’app passe par les API fournies au niveau de l’OS et du navigateur, qu’on appelle aussi des bridges. Je ne pense pas qu’un serveur web local soit indispensable.
Si l’usage d’un serveur web local a posé problème ici, c’est probablement parce qu’il peut permettre des vulnérabilités comme le fait d’accéder à un port localhost depuis Chrome en mode secret et de compromettre ainsi l’anonymat de l’utilisateur. Si cette technique est indispensable dans les applications hybrides... alors ce sont les applications hybrides qui doivent disparaître.
C’est un article vraiment formateur. Il ne suffit pas d’avoir des outils puissants, il faut aussi être prêt à créer les outils nécessaires quand le besoin se présente. Et si tout fonctionne bien, les bénéfices à en tirer sont nombreux.
La situation semble similaire en Corée aussi. J’ai l’impression qu’en matière d’emploi, il vaut plutôt mieux avoir une autre spécialité avec des compétences en code, comme biologie + programmation. Avec le développement de toutes sortes de frameworks et du cloud, ainsi que l’arrivée des outils LLM, l’accès au code s’est démocratisé ; du coup, comme par le passé avec le passage de l’assembleur au C puis au Python, il semble qu’il faille savoir faire autre chose en plus des compétences de programmation pour entrer sur le marché de l’emploi.
C’est clairement utile quand il faut écrire un petit script simple à usage unique. Cela fait gagner énormément de temps.
C’est aussi utile lorsqu’il faut résoudre un problème sans pouvoir y investir beaucoup de temps. En revanche, même si cela reste globalement utile pour l’instant, cela ne remplace pas complètement une personne. Je ne sais pas jusqu’où cela progressera par la suite, mais pour le moment, en tant qu’assistant, c’est à peu près utilisable.
À l’époque de mon master, mon directeur de recherche était allé déjeuner avec un ingénieur passé par Google et, visiblement après avoir entendu parler des monorepos, il nous avait proposé d’adopter nous aussi une gestion en monorepo à l’avenir ; j’avais eu du mal à l’en dissuader...
Les monorepos ont certes beaucoup d’avantages, mais dans notre labo, de par sa nature, nous devons souvent partager nos livrables avec des personnes extérieures, et si nous les avions gérés en monorepo, cela nous aurait particulièrement compliqué la tâche sur ce point. Avec plusieurs dépôts, il suffit simplement d’ajuster le niveau de visibilité pour chaque livrable.
La plupart des cas où l’on souffre avec un monorepo viennent, à mon avis, du fait qu’on a déjà découpé le projet beaucoup trop finement. On prend un projet qui aurait pu n’en former qu’un ou deux à l’origine, on le fragmente en une dizaine, puis on essaie de tout réunifier et gérer en monorepo : il faut alors utiliser des outils de gestion de monorepo et la complexité augmente aussi. Mieux vaut simplement fusionner le projet lui-même en un ou deux projets, et même s’il y en a plus de deux, on peut le gérer plus sereinement sans outil dédié, en séparant juste les répertoires et en le considérant comme le fait de mettre le tout dans un seul dépôt.
La partie sur le fait de « faire ce qu’on aime » est quelque chose à laquelle je réfléchis souvent, donc j’ai hoché la tête du début à la fin en le lisant.
Comment traverser ces débuts éprouvants sans motivation intrinsèque ?
C : Je peux aussi faire DBA + BackEnd + Middle Ware + ingénierie Linux + architecture cloud, je peux monter à bord !?
Moi non plus, je n’arrive pas à faire confiance à l’app Meta, donc je ne l’utilise pas et je passe uniquement par Chrome dans le dossier sécurisé.
Vers mars 2025..
A : Spring, React, Android, iOS, on en prend une seule personne
B : On peut en prendre quatre, une personne pour chacun, non ?
A : J’ai dit qu’on n’en prenait qu’une seule
B :
Qu'est-ce que les humains y connaissent !
Le marché de l’emploi est impitoyable. Vu sous un autre angle, c’est aussi idéal pour créer un service en solo...
Même si on leur dit de ne surtout pas faire comme ça, il y en a toujours un sur dix pour le faire quand même -_-
Merci pour ce très bon article.
Moi aussi, j’aimerais vivre ainsi en tant que développeur solo.
À mon avis, dans une application hybride, la méthode classique de communication entre le web et l’app passe par les API fournies au niveau de l’OS et du navigateur, qu’on appelle aussi des bridges. Je ne pense pas qu’un serveur web local soit indispensable.
Si l’usage d’un serveur web local a posé problème ici, c’est probablement parce qu’il peut permettre des vulnérabilités comme le fait d’accéder à un port localhost depuis Chrome en mode secret et de compromettre ainsi l’anonymat de l’utilisateur. Si cette technique est indispensable dans les applications hybrides... alors ce sont les applications hybrides qui doivent disparaître.
Merci pour ce retour rapide~
C’est un article vraiment formateur. Il ne suffit pas d’avoir des outils puissants, il faut aussi être prêt à créer les outils nécessaires quand le besoin se présente. Et si tout fonctionne bien, les bénéfices à en tirer sont nombreux.
La situation semble similaire en Corée aussi. J’ai l’impression qu’en matière d’emploi, il vaut plutôt mieux avoir une autre spécialité avec des compétences en code, comme biologie + programmation. Avec le développement de toutes sortes de frameworks et du cloud, ainsi que l’arrivée des outils LLM, l’accès au code s’est démocratisé ; du coup, comme par le passé avec le passage de l’assembleur au C puis au Python, il semble qu’il faille savoir faire autre chose en plus des compétences de programmation pour entrer sur le marché de l’emploi.
J'applaudis !
C’est clairement utile quand il faut écrire un petit script simple à usage unique. Cela fait gagner énormément de temps.
C’est aussi utile lorsqu’il faut résoudre un problème sans pouvoir y investir beaucoup de temps. En revanche, même si cela reste globalement utile pour l’instant, cela ne remplace pas complètement une personne. Je ne sais pas jusqu’où cela progressera par la suite, mais pour le moment, en tant qu’assistant, c’est à peu près utilisable.
À l’époque de mon master, mon directeur de recherche était allé déjeuner avec un ingénieur passé par Google et, visiblement après avoir entendu parler des monorepos, il nous avait proposé d’adopter nous aussi une gestion en monorepo à l’avenir ; j’avais eu du mal à l’en dissuader...
Les monorepos ont certes beaucoup d’avantages, mais dans notre labo, de par sa nature, nous devons souvent partager nos livrables avec des personnes extérieures, et si nous les avions gérés en monorepo, cela nous aurait particulièrement compliqué la tâche sur ce point. Avec plusieurs dépôts, il suffit simplement d’ajuster le niveau de visibilité pour chaque livrable.
C’est un bon article ~
Ah, j’ai résolu le problème d’une autre manière. Merci !
La plupart des cas où l’on souffre avec un monorepo viennent, à mon avis, du fait qu’on a déjà découpé le projet beaucoup trop finement. On prend un projet qui aurait pu n’en former qu’un ou deux à l’origine, on le fragmente en une dizaine, puis on essaie de tout réunifier et gérer en monorepo : il faut alors utiliser des outils de gestion de monorepo et la complexité augmente aussi. Mieux vaut simplement fusionner le projet lui-même en un ou deux projets, et même s’il y en a plus de deux, on peut le gérer plus sereinement sans outil dédié, en séparant juste les répertoires et en le considérant comme le fait de mettre le tout dans un seul dépôt.
En donnant
min-width: 0à.topic_contents, le problème se corrige.min-width, quelle galère...C’est peut-être à cause du tableau que la mise en page mobile est cassée.
Je m’y retrouve complètement dans ce récit
La partie sur le fait de « faire ce qu’on aime » est quelque chose à laquelle je réfléchis souvent, donc j’ai hoché la tête du début à la fin en le lisant.
Comment traverser ces débuts éprouvants sans motivation intrinsèque ?