Ah, je ne cherche pas à dénigrer la vision future d’OpenAI ni les innovations améliorées autour de Browser+AI.
Ce que je veux dire, c’est que si OpenAI tente d’aller dans cette direction, comme des navigateurs majeurs tels que Chromium ou Firefox sont déjà ouverts, je ne pense pas qu’une acquisition distincte soit nécessaire du point de vue du développement.
Autrement dit, une acquisition n’est pas indispensable pour créer un fossé technologique.
Donc, si une acquisition est envisagée, je pense que le moteur principal serait davantage l’expansion via la part de marché que l’aspect technique.
Si l’entreprise lançait simplement un nouveau navigateur basé sur Chromium, cela n’aurait pas beaucoup d’attrait pour les utilisateurs qui ne quitteraient pas Chrome. En revanche, en rachetant Chrome, elle pourrait officiellement permettre, via des mises à jour, aux utilisateurs qui représentent 70 % du marché des navigateurs de découvrir ses services de modèles d’IA. La barrière à l’expansion d’un nouveau service serait considérablement réduite.
Comme vous l’avez dit, le fait qu’Edge ne soit pas en train de s’étendre semble relever d’une logique similaire. Le marché des navigateurs est vraiment très conservateur. Je pense qu’OpenAI envisage aussi le rachat de Chrome en tenant compte de cet aspect. C’est pourquoi, lorsque OpenAI parle de « navigation web pilotée par l’IA », j’estime que l’influence du marché de Chrome pèse davantage que les capacités propres d’OpenAI.
Supabase se distingue par son adéquation aux systèmes basés sur le CRUD, et comme il n’est pas nécessaire de développer ni d’exploiter un serveur d’API, il est possible d’implémenter le CRUD côté frontend, ce qui réduit la charge de développement backend. Les développeurs frontend et backend communiquent via la définition des tables plutôt qu’au moyen de spécifications d’API, et utilisent principalement des fonctionnalités comme la console web, l’authentification et le stockage d’objets.
Comme le frontend dépend des définitions des tables, des vues et des fonctions de la base de données, il faut prêter une certaine attention au suivi des changements de données. Si vous avez besoin d’une logique côté serveur, je pense qu’il vaut mieux mettre en place séparément un WAS/REST API.
Je recommande toujours Supabase comme premier choix à celles et ceux qui veulent lancer un side project. J’espère que Supabase continuera à encore mieux réussir !
C’est un service que j’apprécie énormément. On peut créer un service uniquement côté front, sans configuration complexe du backend/de la base de données.
Je l’utilise activement pour essayer de l’intégrer à un vrai service, et personnellement, j’ai même trouvé l’expérience développeur meilleure que celle de Firebase.
Il y a aussi une région en Corée, et le free tier est plutôt généreux, ce qui est appréciable. On peut aussi faire du self-hosting.
Une levée en série D, c’est une bonne nouvelle ! Cela dit, comme cela revient sans cesse dans les avis, je m’inquiète un peu de la viabilité du modèle économique à long terme.
À mon avis, utiliser un service serverless d’un fournisseur est risqué, mais fournir en interne un environnement serverless en s’appuyant sur des conteneurs me paraît être une bonne idée. Ce serait bien d’utiliser le serverless non pas comme un service, mais comme un concept.
Réfléchissez bien aux raisons pour lesquelles les autres vous critiquent autant, et à l’avenir, évitez de vous montrer arrogant et de raconter ce genre d’absurdités.
De nombreuses personnes travaillent aussi avec passion dans les technologies informatiques. Ne généralisez pas à partir de vos propres idées et expériences. C’est insultant pour elles.
Il y a un problème qui apparaît à mesure que, contrairement au passé, le périmètre dont une seule personne doit s’occuper s’est élargi.
•Il est vrai qu’aujourd’hui, on attend d’un seul ingénieur un champ de compétences plus large et plus important qu’autrefois. Et bien plus qu’avant, le monde réel s’est intégré aux systèmes informatiques, ce qui fait grimper rapidement la difficulté de l’abstraction comme de l’implémentation. Je ne vois pas bien en quoi énumérer des tâches plus difficiles dans le monde réel obligerait à soutenir que ce métier n’est pas difficile...
• Le titre a été traduit comme « c’est de la folie », mais j’ai l’impression qu’il exprime plutôt la situation actuelle, qui épuise tout simplement les gens. Et, pour ma part, je suis assez d’accord avec le texte. Il est vrai que, par rapport au passé, ce qu’on attend d’un seul ingénieur s’est élargi et considérablement accru. Et bien plus qu’autrefois, une immense part du monde réel est entrée dans les systèmes informatiques ; du même coup, le niveau d’abstraction et la difficulté de mise en œuvre augmentent eux aussi rapidement. Je ne vois pas bien pourquoi, sous prétexte d’énumérer des tâches plus difficiles dans le monde réel, il faudrait soutenir que ce métier n’est pas difficile...
C’est un exemple complètement différent, non ? Il suffit de faire un rollback et c’est réglé ? Votre propre expérience ne résume pas tout. Vous n’avez jamais travaillé sur des chantiers de grande ampleur ?
•Je pense que vous vous méprenez en croyant que le développement logiciel consiste simplement à générer du code ou des API. L’essence du développement logiciel, c’est d’abstraire la réalité pour créer des protocoles et des interfaces, puis d’y faire entrer les choses. Il s’agit de relier des éléments qui fonctionnent différemment pour les faire agir comme un tout. C’est une activité intellectuelle plus complexe qu’on ne l’imagine, et c’est pour cela qu’il est plus difficile qu’on ne le pense de former des ingénieurs logiciels. On dit qu’il y a beaucoup de monde aujourd’hui, mais parmi eux, combien sont réellement capables de faire correctement le travail ? La plupart ont simplement essayé un outil une fois, mais ce n’est pas là le cœur du métier d’ingénieur logiciel.
• La comparaison directe avec l’industrie manufacturière est-elle vraiment pertinente ? Si l’on part du point de vue que le secteur n’a pas encore atteint un niveau de sophistication suffisant, alors le point de comparaison semble être la fabrication. Si l’on essaie de comprendre le métier du logiciel à travers le paradigme de l’industrie manufacturière, il peut sembler relever de l’artisanat ou du développement amateur ; mais à l’inverse, je pense que ce sont précisément ces aspects qui créent une culture souple et créative propre au développement logiciel, et qui lui servent de tremplin pour grandir.
• Il est vrai qu’aujourd’hui, on attend d’un seul ingénieur un champ de compétences plus large et plus important qu’autrefois. Et bien plus d’éléments du monde réel ont été intégrés dans les systèmes informatiques qu’auparavant, ce qui fait que le niveau d’abstraction et la difficulté d’implémentation augmentent rapidement. Je ne suis pas sûr qu’il soit nécessaire d’énumérer des tâches plus difficiles dans le monde réel pour prétendre que ce métier n’est pas difficile...
• L’environnement a changé. Je ne pense pas que si les attentes du marché envers les développeurs et leur rémunération ont augmenté par rapport au passé, ce soit uniquement à cause de leur technique, de leur niveau de maîtrise ou de leur expertise. Plus l’IT s’enfonce profondément dans la vie humaine, plus le logiciel devient important, en soutenant une grande quantité d’infrastructures. Je ne pense pas que la rémunération augmente parce que les capacités de chaque développeur se sont accrues, mais simplement parce que le travail lui-même est devenu plus coûteux. Parce qu’il est plus important qu’avant.
Il y a des critiques pertinentes ci-dessous. Le fait que les technologies informatiques soient très accessibles doit aussi beaucoup aux ingénieurs logiciels. Et accessibilité ne veut pas dire qu’il est facile de devenir un professionnel.
Est-ce que, parce que la cuisine est accessible, il est facile de devenir un expert culinaire ?
•C’est facile à apprendre. D’accord, mais une faible barrière à l’entrée ne signifie pas une faible technicité. Si c’est plus facile à apprendre que d’autres métiers techniques dans d’autres secteurs, en particulier dans l’industrie manufacturière, ce n’est pas tant parce que le développement est simple, mais plutôt grâce à la culture open source ou au faible niveau de risque. Comme je l’ai dit plus haut à propos de la diversité des développeurs, il y a des tâches qu’on peut apprendre rapidement à faire, et d’autres qui exigent une véritable expertise.
•Si vous apprenez un peu le dessin puis entrez comme assistant d’un auteur de BD, vous allez vous présenter comme un professionnel ? Ou alors, parce que vous avez suivi quelques cours de cuisine et trouvé un emploi en cuisine, vous allez vous dire expert culinaire, chef ? C’est à peu près le même niveau que ce que vous dites. Si c’était aussi simple, on n’appellerait pas ça un professionnel.
L’une des choses les plus difficiles quand on développait avec Spring, c’était je crois les dépendances circulaires..
Cette frustration de les voir s’initialiser mutuellement à l’infini jusqu’à faire planter l’appli avec une fuite mémoire...
Votre critique est hors de propos. L’auteur du message original n’a rabaissé personne ; n’est-ce pas plutôt vous qui dévalorisez et rabaissez la profession d’ingénieur logiciel ?
J’avais publié un article à l’époque du lancement de la bêta publique il y a 5 ans, et l’un des cofondateurs était même venu laisser un commentaire. Ils ont énormément grandi depuis haha.
Début de la bêta publique de Supabase - une alternative open source à Firebase
Ah, je ne cherche pas à dénigrer la vision future d’OpenAI ni les innovations améliorées autour de Browser+AI.
Ce que je veux dire, c’est que si OpenAI tente d’aller dans cette direction, comme des navigateurs majeurs tels que Chromium ou Firefox sont déjà ouverts, je ne pense pas qu’une acquisition distincte soit nécessaire du point de vue du développement.
Autrement dit, une acquisition n’est pas indispensable pour créer un fossé technologique.
Donc, si une acquisition est envisagée, je pense que le moteur principal serait davantage l’expansion via la part de marché que l’aspect technique.
Si l’entreprise lançait simplement un nouveau navigateur basé sur Chromium, cela n’aurait pas beaucoup d’attrait pour les utilisateurs qui ne quitteraient pas Chrome. En revanche, en rachetant Chrome, elle pourrait officiellement permettre, via des mises à jour, aux utilisateurs qui représentent 70 % du marché des navigateurs de découvrir ses services de modèles d’IA. La barrière à l’expansion d’un nouveau service serait considérablement réduite.
Comme vous l’avez dit, le fait qu’Edge ne soit pas en train de s’étendre semble relever d’une logique similaire. Le marché des navigateurs est vraiment très conservateur. Je pense qu’OpenAI envisage aussi le rachat de Chrome en tenant compte de cet aspect. C’est pourquoi, lorsque OpenAI parle de « navigation web pilotée par l’IA », j’estime que l’influence du marché de Chrome pèse davantage que les capacités propres d’OpenAI.
Je l’utilise énormément pour mes projets personnels.
Soudainement, Godot… ?!
Supabase se distingue par son adéquation aux systèmes basés sur le CRUD, et comme il n’est pas nécessaire de développer ni d’exploiter un serveur d’API, il est possible d’implémenter le CRUD côté frontend, ce qui réduit la charge de développement backend. Les développeurs frontend et backend communiquent via la définition des tables plutôt qu’au moyen de spécifications d’API, et utilisent principalement des fonctionnalités comme la console web, l’authentification et le stockage d’objets.
Comme le frontend dépend des définitions des tables, des vues et des fonctions de la base de données, il faut prêter une certaine attention au suivi des changements de données. Si vous avez besoin d’une logique côté serveur, je pense qu’il vaut mieux mettre en place séparément un WAS/REST API.
Je recommande toujours Supabase comme premier choix à celles et ceux qui veulent lancer un side project. J’espère que Supabase continuera à encore mieux réussir !
C’est un service que j’apprécie énormément. On peut créer un service uniquement côté front, sans configuration complexe du backend/de la base de données.
Je l’utilise activement pour essayer de l’intégrer à un vrai service, et personnellement, j’ai même trouvé l’expérience développeur meilleure que celle de Firebase.
Il y a aussi une région en Corée, et le free tier est plutôt généreux, ce qui est appréciable. On peut aussi faire du self-hosting.
Une levée en série D, c’est une bonne nouvelle ! Cela dit, comme cela revient sans cesse dans les avis, je m’inquiète un peu de la viabilité du modèle économique à long terme.
À mon avis, utiliser un service serverless d’un fournisseur est risqué, mais fournir en interne un environnement serverless en s’appuyant sur des conteneurs me paraît être une bonne idée. Ce serait bien d’utiliser le serverless non pas comme un service, mais comme un concept.
L’expression « Je voulais une banane, mais on m’a livré la jungle » est vraiment très drôle.
Réfléchissez bien aux raisons pour lesquelles les autres vous critiquent autant, et à l’avenir, évitez de vous montrer arrogant et de raconter ce genre d’absurdités.
De nombreuses personnes travaillent aussi avec passion dans les technologies informatiques. Ne généralisez pas à partir de vos propres idées et expériences. C’est insultant pour elles.
Il y a un problème qui apparaît à mesure que, contrairement au passé, le périmètre dont une seule personne doit s’occuper s’est élargi.
•Il est vrai qu’aujourd’hui, on attend d’un seul ingénieur un champ de compétences plus large et plus important qu’autrefois. Et bien plus qu’avant, le monde réel s’est intégré aux systèmes informatiques, ce qui fait grimper rapidement la difficulté de l’abstraction comme de l’implémentation. Je ne vois pas bien en quoi énumérer des tâches plus difficiles dans le monde réel obligerait à soutenir que ce métier n’est pas difficile...
Il n’est pas nécessaire de comparer cela.
• Le titre a été traduit comme « c’est de la folie », mais j’ai l’impression qu’il exprime plutôt la situation actuelle, qui épuise tout simplement les gens. Et, pour ma part, je suis assez d’accord avec le texte. Il est vrai que, par rapport au passé, ce qu’on attend d’un seul ingénieur s’est élargi et considérablement accru. Et bien plus qu’autrefois, une immense part du monde réel est entrée dans les systèmes informatiques ; du même coup, le niveau d’abstraction et la difficulté de mise en œuvre augmentent eux aussi rapidement. Je ne vois pas bien pourquoi, sous prétexte d’énumérer des tâches plus difficiles dans le monde réel, il faudrait soutenir que ce métier n’est pas difficile...
C’est un exemple complètement différent, non ? Il suffit de faire un rollback et c’est réglé ? Votre propre expérience ne résume pas tout. Vous n’avez jamais travaillé sur des chantiers de grande ampleur ?
•Je pense que vous vous méprenez en croyant que le développement logiciel consiste simplement à générer du code ou des API. L’essence du développement logiciel, c’est d’abstraire la réalité pour créer des protocoles et des interfaces, puis d’y faire entrer les choses. Il s’agit de relier des éléments qui fonctionnent différemment pour les faire agir comme un tout. C’est une activité intellectuelle plus complexe qu’on ne l’imagine, et c’est pour cela qu’il est plus difficile qu’on ne le pense de former des ingénieurs logiciels. On dit qu’il y a beaucoup de monde aujourd’hui, mais parmi eux, combien sont réellement capables de faire correctement le travail ? La plupart ont simplement essayé un outil une fois, mais ce n’est pas là le cœur du métier d’ingénieur logiciel.
• La comparaison directe avec l’industrie manufacturière est-elle vraiment pertinente ? Si l’on part du point de vue que le secteur n’a pas encore atteint un niveau de sophistication suffisant, alors le point de comparaison semble être la fabrication. Si l’on essaie de comprendre le métier du logiciel à travers le paradigme de l’industrie manufacturière, il peut sembler relever de l’artisanat ou du développement amateur ; mais à l’inverse, je pense que ce sont précisément ces aspects qui créent une culture souple et créative propre au développement logiciel, et qui lui servent de tremplin pour grandir.
• Il est vrai qu’aujourd’hui, on attend d’un seul ingénieur un champ de compétences plus large et plus important qu’autrefois. Et bien plus d’éléments du monde réel ont été intégrés dans les systèmes informatiques qu’auparavant, ce qui fait que le niveau d’abstraction et la difficulté d’implémentation augmentent rapidement. Je ne suis pas sûr qu’il soit nécessaire d’énumérer des tâches plus difficiles dans le monde réel pour prétendre que ce métier n’est pas difficile...
• L’environnement a changé. Je ne pense pas que si les attentes du marché envers les développeurs et leur rémunération ont augmenté par rapport au passé, ce soit uniquement à cause de leur technique, de leur niveau de maîtrise ou de leur expertise. Plus l’IT s’enfonce profondément dans la vie humaine, plus le logiciel devient important, en soutenant une grande quantité d’infrastructures. Je ne pense pas que la rémunération augmente parce que les capacités de chaque développeur se sont accrues, mais simplement parce que le travail lui-même est devenu plus coûteux. Parce qu’il est plus important qu’avant.
Il y a des critiques pertinentes ci-dessous. Le fait que les technologies informatiques soient très accessibles doit aussi beaucoup aux ingénieurs logiciels. Et accessibilité ne veut pas dire qu’il est facile de devenir un professionnel. Est-ce que, parce que la cuisine est accessible, il est facile de devenir un expert culinaire ?
•C’est facile à apprendre. D’accord, mais une faible barrière à l’entrée ne signifie pas une faible technicité. Si c’est plus facile à apprendre que d’autres métiers techniques dans d’autres secteurs, en particulier dans l’industrie manufacturière, ce n’est pas tant parce que le développement est simple, mais plutôt grâce à la culture open source ou au faible niveau de risque. Comme je l’ai dit plus haut à propos de la diversité des développeurs, il y a des tâches qu’on peut apprendre rapidement à faire, et d’autres qui exigent une véritable expertise.
•Si vous apprenez un peu le dessin puis entrez comme assistant d’un auteur de BD, vous allez vous présenter comme un professionnel ? Ou alors, parce que vous avez suivi quelques cours de cuisine et trouvé un emploi en cuisine, vous allez vous dire expert culinaire, chef ? C’est à peu près le même niveau que ce que vous dites. Si c’était aussi simple, on n’appellerait pas ça un professionnel.
L’une des choses les plus difficiles quand on développait avec Spring, c’était je crois les dépendances circulaires..
Cette frustration de les voir s’initialiser mutuellement à l’infini jusqu’à faire planter l’appli avec une fuite mémoire...
Votre critique est hors de propos. L’auteur du message original n’a rabaissé personne ; n’est-ce pas plutôt vous qui dévalorisez et rabaissez la profession d’ingénieur logiciel ?
+11111