J’ai l’impression que ce serait la même situation si le propriétaire ne le faisait pas lui-même et le confiait à quelqu’un d’autre.
Même quand on explique très bien, il y a des malentendus, et même quand on vérifie tout minutieusement, il existe toujours des aspects auxquels on n’a pas pensé.
Si l’on doit tout construire en posant des questions sur chaque point que le propriétaire n’a pas précisé, cela prend beaucoup de temps et devient frustrant, donc les experts gèrent souvent une grande partie par eux-mêmes, et j’ai l’impression que c’est justement là que naissent la plupart des frictions.
Cela dit, je vous envie : on dirait que vous n’avez pas encore trop été trahi par des sociétés de SI.
Haha, incroyable
J’ai vu passer ça sur Slack et je suis venu vérifier en pensant que c’était une faute de frappe, mais eh bien non, ce n’en était pas une mdr. J’ai pris beaucoup de plaisir à lire l’article. Merci pour ces explications détaillées
Petite parenthèse, mais on dirait qu’on retrouve un goût assez cohérent dans l’UI des applis Tesla, X et Starlink…
J’y avais pensé, essayer Starlink, mais voir quelqu’un l’emporter et l’utiliser pendant un voyage à l’étranger, c’est assez étonnant.
Comme prévu, le vrai obstacle, c’est de l’acheter dans un pays où il n’est pas encore commercialisé, puis d’activer le forfait.
Merci pour ce retour intéressant.
Plutôt qu’un besoin absolu d’Internet, j’avais surtout très envie, puisque je partais dans une région reculée sans signal cellulaire, d’essayer au moins une fois un service d’Internet par satellite accessible aux consommateurs ordinaires. haha
Comme on ne peut pas rejeter l’autorité d’un manuel sous prétexte qu’il est banal, ni facilement le remplacer par une alternative, les ouvrages de business reconnus constituent en eux-mêmes le socle, ou au moins le cœur, de la gestion et des études sur les startups.
Le travail majeur du professeur Steve Blank, la méthodologie de développement client, a servi de base à la théorie du Lean Startup, et les chercheurs et pionniers qui s’y sont engagés ont, à mon sens, créé puis popularisé des outils efficaces comme le Business Model Canvas et le Lean Canvas.
Je pense que les dénigrer, ou oublier leur objectif initial pour les considérer comme des remèdes universels, revient à ne pas comprendre correctement leur finalité première.
Je suis tout à fait d’accord sur le fait qu’à l’exception de Drucker, cette catégorie de livres est surtout écrite par des cadres chevronnés de multinationales. Les livres de ce genre sont vraiment une perte de temps et de papier. À la place, les ouvrages d’histoire, d’économie et de sciences humaines sont bien plus utiles.
Quand on passe Trivy, il y a bien moins de vulnérabilités high ou critical qu’avec js NPM ou Java Maven, donc de quel argument sur Rust cet article essaie-t-il de se servir ?
Il existe un Slack pour les leaders techniques animé par Michael Lopp. RLS - Rands Leadership Slack
Si cela vous intéresse, n’hésitez pas à y faire un tour. C’est actuellement un immense Slack qui rassemble plus de 36 000 membres.
Pour vous inscrire, il suffit de lire attentivement le contenu du lien ci-dessus puis d’envoyer un e-mail à Lopp.
Nom / profession / pourquoi vous souhaitez rejoindre / où vous avez entendu parler de RLS / votre compte LinkedIn ou Twitter, etc.
Ce n’est pas un problème propre à Rust.
C’est à la fois un avantage commun et un problème potentiel partagé par tous les langages qui ont un gestionnaire de paquets avec un dépôt public de paquets et la prise en charge des dépendances transitives.
Au final, tout dépend de la façon dont ceux qui les utilisent s’en servent…
Malgré l’affaire leftpad de Node&npm, rien n’a changé.
Dans le même ordre d’idée, lorsqu’on prépare aussi un document à remettre à un client, à un investisseur ou à un supérieur, il semble important de l’aborder du point de vue de créer quelque chose qui puisse se vendre. Les man pages sont excellentes, mais si on prenait leur format comme benchmark pour rédiger une présentation aux investisseurs, ce serait la catastrophe.
Je suis d’accord sur le fait qu’à l’ère du développement centré sur l’IA, il est indispensable d’implémenter des composants de petite taille avec une responsabilité unique.
Je pense que les microservices ont aussi beaucoup d’avantages dans une startup. Déjà, je recommande vraiment les avantages d’utiliser un monorepo.
Quand l’orientation du produit change, avec les microservices, les parties à modifier sont plus claires et moins nombreuses qu’avec un monolithe. Je pense vraiment que c’est un point très important.
À l’ère du développement largement assisté par l’IA, la petite taille des microservices les rend plus faciles à développer avec l’IA. (Je ne dis pas que c’est impossible avec un monolithe.)
Je reconnais la charge de CI/CD, mais il y a aussi des services qui sont abandonnés à l’étape où l’on cherche encore la bonne direction. Même si on les met en place seulement une fois la direction finale définie, c’est presque du copier-coller, donc on peut les monter en moins d’une semaine.
Les open source qui excellent selon les langages sont très clairement identifiés. On peut par exemple faire la sécurité et la logique métier en Java, et l’IA en Python ; dans une architecture en microservices, on peut ainsi utiliser autant d’open source que possible selon leurs points forts.
J’ai l’impression que ce serait la même situation si le propriétaire ne le faisait pas lui-même et le confiait à quelqu’un d’autre.
Même quand on explique très bien, il y a des malentendus, et même quand on vérifie tout minutieusement, il existe toujours des aspects auxquels on n’a pas pensé.
Si l’on doit tout construire en posant des questions sur chaque point que le propriétaire n’a pas précisé, cela prend beaucoup de temps et devient frustrant, donc les experts gèrent souvent une grande partie par eux-mêmes, et j’ai l’impression que c’est justement là que naissent la plupart des frictions.
Cela dit, je vous envie : on dirait que vous n’avez pas encore trop été trahi par des sociétés de SI.
Ça a l’air bien.
Incroyable !
Haha, incroyable
J’ai vu passer ça sur Slack et je suis venu vérifier en pensant que c’était une faute de frappe, mais eh bien non, ce n’en était pas une mdr. J’ai pris beaucoup de plaisir à lire l’article. Merci pour ces explications détaillées
Petite parenthèse, mais on dirait qu’on retrouve un goût assez cohérent dans l’UI des applis Tesla, X et Starlink…
J’aimerais bien essayer Cline moi aussi !
Hacker News était donc aussi une communauté assez âgée.
La diversité des avis est intéressante.
Hahahahaha, c’est exactement ça.
Le titre et le contenu ne correspondent pas. Je me suis fait avoir.
J’y avais pensé, essayer Starlink, mais voir quelqu’un l’emporter et l’utiliser pendant un voyage à l’étranger, c’est assez étonnant.
Comme prévu, le vrai obstacle, c’est de l’acheter dans un pays où il n’est pas encore commercialisé, puis d’activer le forfait.
Merci pour ce retour intéressant.
Quand toutes ces vagues seront passées, comment les générations futures se souviendront-elles de cette époque ?
Plutôt qu’un besoin absolu d’Internet, j’avais surtout très envie, puisque je partais dans une région reculée sans signal cellulaire, d’essayer au moins une fois un service d’Internet par satellite accessible aux consommateurs ordinaires. haha
Comme on ne peut pas rejeter l’autorité d’un manuel sous prétexte qu’il est banal, ni facilement le remplacer par une alternative, les ouvrages de business reconnus constituent en eux-mêmes le socle, ou au moins le cœur, de la gestion et des études sur les startups.
Le travail majeur du professeur Steve Blank, la méthodologie de développement client, a servi de base à la théorie du Lean Startup, et les chercheurs et pionniers qui s’y sont engagés ont, à mon sens, créé puis popularisé des outils efficaces comme le Business Model Canvas et le Lean Canvas.
Je pense que les dénigrer, ou oublier leur objectif initial pour les considérer comme des remèdes universels, revient à ne pas comprendre correctement leur finalité première.
Je suis tout à fait d’accord sur le fait qu’à l’exception de Drucker, cette catégorie de livres est surtout écrite par des cadres chevronnés de multinationales. Les livres de ce genre sont vraiment une perte de temps et de papier. À la place, les ouvrages d’histoire, d’économie et de sciences humaines sont bien plus utiles.
Quand on passe Trivy, il y a bien moins de vulnérabilités high ou critical qu’avec js NPM ou Java Maven, donc de quel argument sur Rust cet article essaie-t-il de se servir ?
N’existe-t-il pas un service qui permette simplement d’envoyer un lien vers une page web pour demander un résumé ?
Il existe un Slack pour les leaders techniques animé par Michael Lopp.
RLS - Rands Leadership Slack
Si cela vous intéresse, n’hésitez pas à y faire un tour. C’est actuellement un immense Slack qui rassemble plus de 36 000 membres.
Pour vous inscrire, il suffit de lire attentivement le contenu du lien ci-dessus puis d’envoyer un e-mail à Lopp.
Nom / profession / pourquoi vous souhaitez rejoindre / où vous avez entendu parler de RLS / votre compte LinkedIn ou Twitter, etc.
Ce n’est pas un problème propre à Rust.
C’est à la fois un avantage commun et un problème potentiel partagé par tous les langages qui ont un gestionnaire de paquets avec un dépôt public de paquets et la prise en charge des dépendances transitives.
Au final, tout dépend de la façon dont ceux qui les utilisent s’en servent…
Malgré l’affaire leftpad de Node&npm, rien n’a changé.
Dans le même ordre d’idée, lorsqu’on prépare aussi un document à remettre à un client, à un investisseur ou à un supérieur, il semble important de l’aborder du point de vue de créer quelque chose qui puisse se vendre. Les man pages sont excellentes, mais si on prenait leur format comme benchmark pour rédiger une présentation aux investisseurs, ce serait la catastrophe.
Je suis d’accord sur le fait qu’à l’ère du développement centré sur l’IA, il est indispensable d’implémenter des composants de petite taille avec une responsabilité unique.
Je pense que les microservices ont aussi beaucoup d’avantages dans une startup. Déjà, je recommande vraiment les avantages d’utiliser un monorepo.