Reprise du message précédent :

A oui, je ne comptais que les langages de scripts utilisés a chaque déploiement, dont du code a été écris en interne

Normalement oui mais ça dépend sûrement de la force du freinage, qui est parfois paramétrable si tu veux pouvoir conduire à une seule pédale ou au contraire que tu préfères être vraiment en roue libre.

En fait j'arrive pas à imaginer un scénario où tu as besoin de développer dans tes 5 langages en même temps, et surtout quelle UX ça donne avec des langages compilés par un serveur LSP derrière. Mais je veux bien te croire, c'est vrai qu'utiliser IDEA Ultimate pour tout faire est sûrement pas top.
 
Pour moi ton principal argument vient surtout de votre politique qui interdit le checkout local, du coup oui un IDE client/serveur a du sens. Le reste des arguments me semble un peu orthogonal (par exemple l'intégration avec vos outils proprios), voire fumeux (l'empreinte relativement plus faible quand tu délègues tout le boulot à un serveur LSP pour finalement supporter moins de fonctionnalités qu'un IDE JetBrains).

putain je suis fan
https://www.youtube.com/watch?v=rdi7G1hY4-w

A vrai dire CLion est le seul que j'utilise, car le support de Rust dans VSCode est a chier comparé a CLion
 

Tres, tres grosse erreur du management je dirais, a la tete de tout le bousin il faut savoir imposer et limiter.
 
On est a un seul language, node/js, interdiction meme d'envisager autre chose. Et meme sur la liste des packages a utiliser on est pas mal strict, par exemple, lodash est banni. A chaque nouveau mec qui se pointe, lodash revient par la petite porte du petit commit qui va bien Petite explication en face a face et ca rentre dans l'ordre.

 
C'est quoi votre raison ? Ne pas faire grossir les node_modules pour une ou deux fonctions ?

 
Globalement, ca se passe toujours comme ca avec lodash:
  - un mec va l'utiliser parce que c'est un gros flemmard de premiere, mais pas le bon flemmard, le mauvais
  - donc tu vas commencer par avoir une PR qui ajoute lodash, et le plus souvent ca va etre par exemple uniq ou flatten qui est utilisée. Bref une des 3/4 fonctions principales de lodash.
  - un peu plus tard tu vas avoir un génie (pas forcément le meme) qui se dit que quand meme, lodash c'est pratique, on va ajouter maintenant clone dans la liste -par exemple-.
 
Et ca continue, et au fur a mesure ton projet se transforme et integre pas mal profond lodash.
 
Et c'est la ou ca se passe mal:
  - Deja, c'est une bibli qui ne fait rien. Les 3/4 des fonctions sont fesable en moins de trois ligne de ES6 <= et quand une bibli n'apporte rien, avant meme de lire la suite c'est deja la poubelle pour nous
  - de deux, ca demande a toute l'équipe de se tapper la doc, alors que si ca avait été ces 3 lignes de ES6 ca serait clair. Mais personne ne lit la doc, enfin les gens la survolent plutot que de la lire.
  - résultat ca ne marche pas. Ils vont utiliser clone alors qu'il aurait fallut deepClone - par exemple. Et donc ca introduit plein de bug de merde super dur a trouver, parce que le comportement de la fonction X n'est pas celui espéré, et que personne ne lit suffisamment en détail cette foutue doc.
 
Résultat, ben 3 lignes de ES6 x 4, c'est plutot franchement mieux en fait, ca te fait croire que t'es un caid de Node Et ca te donne une équipe qui a un code con a lire, et un code con a lire, c'est un excellent code
 
Bref, lodash c'est la poubelle directe, au final on a meme pas 4, 5 fonctions qui sont répliquées manuellement, et c'est beaucoup mieux ainsi

 
IDEA ultimate ça n'enlève pas le besoin d'utiliser CLion ? C'est possible hein, mais c'est pénible, perso j'ai pas envie. J'ai jamais besoin des deux en même temps, mais en parallèle, oui. En terme d'UX ça donne rien de particulier, on n'a pas d'outil de refactoring avancés on a juste l'autocompletion et la navigation, et du coup ça marche quel que soit le langage sur lequel on travaille. Rien à voir avec les possibilités que donne un IDE, mais je suis de ceux qui apprécient les moments de calme à taper des trucs répétitifs... C'est mieux que le tricot pour se relaxer.
 
Par contre oui je vois que pour le go c'est différent, c'est juste un plugin. Je sais pas ce que ça vaut en interne, j'ai jamais essayé.
 
Après tu as raison que le coté hébergé apporte en + une latence significative dans tous les clients lourds, mais ça reste faisable (et fait par pas mal de personne, qui sont en générale spécialistes). Typiquement, ça marche bien pour java, mal pour C++. La taille de la base de code n'aide pas.

Ca reste secret ici, mais chez Plamcorp y'a Lodash qui est pas mal utilisé. Partout où je passe, je vire les fonctions.  

J'ai rien contre, mais il est souvent mis pour 4-5 fonctions, donc je profite du rework pour faire du vide. Après tu peux aussi installer seulement la fonction dont tu as besoin, sans tout le package.

Les limites on en a parlé : faut se limiter aux langages préalablement approuvés. En contrepartie, dans ce cadre, chacun est relativement libre.

 
Ah c'est rigolo, on a eu pas mal de débats autour de lodash dans mon ancienne boîte.  
Au final, on a conservé, y a pas mal de méthodes plutôt pratiques, et redévelopper un truc bien maintenu peut être considéré comme discutable.
En revanche, on était très regardants sur son utilisation, parce qu'il y a effectivement énormément de reliquats conservés pour compatibilité avec de vieilles versions de JS/vieux navigateurs, alors qu'on peut faire la même chose (et parfois en mieux) en ES6 sans souci.
 
C'est presque plus un souci d'écosystème JS que de lodash lui-même en fait, je trouve. Et cette lib est un peu à cheval entre l'utile et le superflu.
 
Par contre c'est la seule lib du genre qu'on accepte, la politique c'est le moins de dépendances possible, pour éviter l'effet "is-promise"

Tu dois trouver du node et même sûrement du PHP chez nous aussi, pour des vieux trucs / trucs standalone. C'est logique de chercher à limiter la prolifération des langages, pour plein de raisons. Par ex tuner une JVM c'est un skillset assez spécifique, si tu investis dedans tu voudras une masse critique pour rentabiliser ça.
Donc oui je doute que ce soit la fête du slip niveau choix des technos dans ces boîtes là.

Je choisis un opticien qui a des lunettes Stark (parce que le pliage des branches vertical en plus de horizontal c'est super confortable.
Aussi parce que je peux essayer lesdites lunettes.
Après ça me paraîtrait assez moche de dire "bon ben merci pour l'essayage, je vais pas les faire ici".
Ma femme a fait des tas de lunettes en Chine (30 balles la paire), elle en est contente. Y'avait une app VR pour essayer, et puis sa sœur en avait commandé déjà.

Pour les grosses boîtes c'est très drivé par les éditeurs avec qui tu bosses, vu que les customisations seront contrainte par ça (eg, SAP implique ABAP et Java). Du coup dans toutes les boîtes où j'ai été tu avais de tout, et les devs maison (ultra limités par volonté sur le principe foireux que l'IT c'est pas core business), c'était en général contraint sur une liste de 2-3 choix genre .NET et Java.

Le scénario c'est plusieurs produits backend, plus la suite d'outils internes pour les gérer. Le gros du code est en C++, la UI est en TS, t'as un DSL maison fait en Kotlin, et historiquement y'a des bouts en java.

Pour le coup IntelliJ, Clion, VS code, Emacs, Vi et notre IDE web interne (qui migre sur VS) sont tous utilisables sur la codebase, et tu peux utiliser celui que tu veux sans demander à personne.

Le checkout local c'est un faux problème : notre repo se monte en mémoire, donc tu peux l'utiliser localement.

Je pense plutôt aux raisons suivantes :
- Google fonctionne par RPC, avec un système de serialisation maison (les fameux protos buffers). Donc chaque nouveau langage doit payer la taxe d'implémenter les protos et les RPC G-style sans quoi c'est inutilisable ici, vu que tout message est un proto.
- vu comme nos Ops fonctionnent (serveurs, stockage, etc...) Tu peux pas utiliser les abstractions courantes de ton language. Par ex, chaque langage doit implémenter gFile, qui permet d'accéder à des fichiers en local mais aussi à notre stockage distribué, sans avoir à gérer les détails. Des examples comme ça y'en a plein (on a notre propre langage de conf, etc...)

Si demain tu veux introduire un nouveau langage tu dois payer le coût de toutes ces integrations. Il est rare que ça en vaille la peine en fait.

L'ide web a plein d'avantage, dont celui que tu peux éditer des trucs sans avoir de machine de dev par ex.

Je serais a priori d'accord (ça m'a toujours gonflé le CV driven development où tu finis avec tous les outils hype du monde dans ta codebase, mais comme l'a dit Hepha ça joue pas chez G, a cause de ce que j'ai écrit plus haut. Tant que tu restes dans les 5-6 languages autorisés, ça coûte rien de laisser cette flexibilité.

Je ne vois plus mentionné Eclipse quand ça parle d'IDE, c'est mort et enterré comme IDE hideux ?

Je dis pas que c'est la fête du slip.
Mais de nouveau tu comprends pas la différence fondamentale entre votre modèle et celui des boîtes comme MS, Apple, Amazon où les outils et les contraintes sont peu/pas centralisées. Même FB et Twitter qui ont repris plein d'idées venant directement de chez vous (monorepo, respectivement Buck et Pants au lieu de Blaze, etc.) ont plus de latitude à ce niveau. Par exemple chez FB il y a des services critiques (pas des vieux petits projets dans un coin) en OCaml et Haskell (y avait même du D mais je sais pas si c'est d'actualité).
 

Ce n'était pas le propos de ma question. Hepha a dit qu'une architecture client/serveur avec le LSP facilite le travail sur les projets qui mélangent plusieurs langages, alors qu'a priori je pense que c'est plus compliqué à gérer que par une architecture traditionnelle (le système de plug-ins d'IntelliJ).

La lib avait un intêret à sa sortie (autour de la mort d'underscore quoi), mais maintenant c'est dur de justifier sont ajout en tant que dépendance et encore plus difficile l'ajout d'une seule fonction

Underscore est jamais mort. Ce meme est un mensonge du créateur de lodash, initialement forké d’underscore sous justification de performances (un peu comme pour cpython, ashkenas voulait garder la base simple).

soit, mais je sais pas si c'est nécessairement mieux. Ça veut dire qu'un SRE a d'autant plus de contextes de prod à maitriser, ça veut dire que si tes SWE bougent en interne tu vas avoir plus de chance qu'ils tombent sur un langage qu'ils ne connaissent pas et qu'ils devront apprendre. Du coup c'est valable que si la somme de toutes ces productivités perdues est compensée par un gain spécifique du langage choisit, et je fais de l'IT depuis suffisament longtemps pour avoir TRES rarement entendu une justification valable de ça. Dans bien des cas, la discussion se résume souvent à "je préfère coder en X parce que je connais X, ou que je veux essayer X", et les SWE factorent rarement le coût pour les autres de telles décisions. (un exemple, ton département Ops a l'habitude d'hoster des services nginx sous linux, avec une couche java dessus. Ce sont des boloss de la gestion de mémoire, fine tuning du garbage collector, etc...). Tout d'un coup ta boite décide de passer sur Windows / .NET, il va y avoir un gros recyclage nécessaire. Ça a un cout.
 

le truc c'est que :  
- tout est déjà un RPC, même si tu n'as qu'un langage (à l'intérieur d'une lib / d'un module évidemment ça utilise des appels classiques à des libs)
- tout utilise déjà les protos, même si tu n'as qu'un seul langage
 
Par conséquent, dans notre contexte, le coût d'utiliser un autre langage (sous réserve que celui-ci ait les intégrations / librairies, soit les 5 dont on parle) est nul. Si tu offres une API, que ce soit un client python ou C++ qui l'appelle ça ne change absolument rien.
 
Si on redéveloppait tout from scratch, est-ce que le mono-repo, protobuff, l'archi RPC, etc... seraient la meilleur approche ? J'en sais rien, j'ai pas suffisamment d'expertise technique pour le dire. Je vois qu'avec le temps ça nous isole beaucoup du monde, parce que cout d'onboarding d'une nouvelle lib est gros, et ça freine l'adoption. (on a un doc d'un de nos SVP qui documente très bien ce problème, doc resté lettres mortes pour le moment)

Le système de plugin force à supporter n outils pour chaque langage, et on a commencé la discussion avec le postulat que zéro (à une vache près) dév, quelles que soient les moyens de pressions utilisés, n'accepteront de lâcher leur éditeur. C'est évidemment un peu plus compliqué de gérer l'architecture à base de LSP, mais ça permet de supporter toutes les combinaisons outils x langages à moindre coût.
 
En +, IntelliJ a pas de plugin pour le C++.

Mort clinique si tu veux. N'empêche qu'il est 5 fois moins téléchargé que lodash et qu'il a 6 fois moins de dépendants

Il y a quelques fonctions ou je n'ai rien a redire, comme flatten par exemple, qui sont effectivement pratique.
 
Mais j'ai 20 fou furieux derriere moi, ca va plus vite de bannir le truc et de me poser de vraies questions de stratégie de dev/boite (c'est mon poste apres tout) plutot que de batailler sur une lib a la con
 

 
Je valide que c'est un probleme propre a JS et son ecosysteme qui a pas mal évolué, mais justement Node c'est assez stable depuis longtemps maintenant, donc le besoin d'avoir un layer de compatibilité se pose vraiment.
 
Lodash a certainement plus d'utilisation coté client que serveur, car en serveur ton environment est fixe, donc palier a un pb de compatibilité se résume a avoir la bonne version de node quand le mec arrive dans la boite, voir Docker au pire (mais je te dirais que si tu utilises Docker tu as probablement un pb de dépendances, tous, TOUS nos projets fonctionnement parfaitement de node 8 a node 16, sans aucune couche de compatibilité quelconque, justement parce que notre stack est tres volontairement tres maigre, et que l'on force a faire du code a la con et non pas du code pointu que 2 mecs pigent).
 
Ce point en gras, ca va assez loin d'ailleurs, mais clairement c'est la bonne pratique pour nous, ca fait que X qui a jamais bossé sur ce projet (on est en micro projet donc on en a genre 300), prend ce repo, on a ce probleme, fixe. En moyenne dans l'heure c'est fixé, c'est con a lire, donc con a comprendre et a fixer.
 

 
J'ai été formé a Maven et Java, j'ai vu ce que ca coutait de ne pas aller plus loin dans le détail de quelle lib tu utilises ou non Ca m'a refroidit pas mal
 
Si je regarde maintenant combien notre plus gros projet a, il a 5 ans et est dev tous les jours par 3 a 5 personnes environ: 25 packages. Principalement aws, async (on a bcp de gestion de flow), bcrypt, les trucs d'express, pg... Tres classique et assez minimaliste vu la taille du projet...

Personne n'a prétendu que c'est mieux ou moins bien.

Pour IntelliJ je savais pas! Donc oui si tu veux pas avoir CLion en parallèle je comprends parfaitement ton point de vue.

Et oui le LSP a l'avantage de réduire la complexité de faire supporter n langages par m IDEs c'est vrai.

Après d'un point de vue purement pratique, vu vos liens avec JetBrains et la quantité de gens qui bossent sur vos outils internes, si y a dix ans quelqu'un avait pris la décision inverse (aller à fond vers l'intégration d'IntelliJ plutôt qu'une solution web maison) ça aurait pu se faire, j'imagine.

Je me souviens de tes commentaires au début, à propos de tes collègues qui faisaient du Java dans vim. Dans ce que tu racontes aujourd'hui j'ai quand même l'impression que votre culture interne alimente cette position (les IDEs c'est pas pour nous) de manière un peu biaisée.

Ou ca:
 
https://dev.to/cseeman/what-s-up-wi [...] ything-he1
 
Qui m'a occupé pendant de longues soirées d'hiver. Les fils de **** qui virent le package pour un pb de license a la con, du jour au lendemain, sans rien dire ni annoncer, et encore moins en proposant une alternative ou une maniere de faire pour palier une fois fait. Des génies.

Donc vie = popularité indépendament de la vie du projet?

C’est aussi un problème de maturité / génération des outils, genre cargo permet pas de supprimer un package sans passer par les admins.

On va dire que je dénote un peu ici.

Après je crois que la visibilité est juste à l’échelle package non? Donc si t’as jamais eu besoin de créer une lib… c’est pas comme un rust où la visibilité joue aussi entre modules d’une crate.

perso ça m'est arrivé de devoir débugger des systèmes qui se parlent, et devoir descendre assez loin dans le terrier, pour aller comprendre pourquoi tel machin a expédié tel message et voir si c'est normal.

Franchement je crois vraiment que le problème s'est posé différemment. On est majoritaire (je crois) à regretter l'absence d'IDE potable. Mais on ne peut pas forcer tout le monde à abandonner vim, alors cette solution a été choisie pour quand même avoir un environnement vivable pour les être humains normaux.

j'en sais rien, j'essaye juste de finir ce projet et de retourner chez Plam, j'ai complètement foiré ce projet et il est temps de l'enterrer et de passer à autre chose.

Badge / pc rendu

Ça fait bizarre quand même

Ca faisait combien de temps?

10 mois  
ça a été bref, mais formateur, je n'avais jamais bossé dans une boite avec un tel effectif

\o/ Vacances \o/
 
P'tete je vais enfin me mettre à Rust.

ouch, je peux pas acheter un nouveau téléphone parce que toutes mes banques ont le téléphone comme 2FA

C'est pour ça que j'ai parlé mort clinique. Mais autrement:

- Sans popularité bien souvent tu as une baisse de motivation de l'équipe de dev notamment quand c'est un mec seul dans sa cave qui fait ça sur son temps libre et sans rémunération. [1]
- Un projet populaire peut attirer des sponsors. Voir [1]
- C'est souvent plus de contributions: soit de features, soit de bug fixes souvent détectés par le nombre et la diversité des usages.
- Idem pour la sécurité, ce qui peut mettre un projet au rebut pour un certains nombre de users. [2]
- Va voir un dicaïdor en lui disant "ouais t'inquiètes, ce projet là fait ce qu'on veut mais y'a pas eu de commit depuis deux ans par contre", et le jour où t'as un CVE dessus ou en downstream on va rigoler. Et voir [2] du coup.
- Sans parler du fait que si le projet est mort et que t'as un bug/feature manquante critique, si t'as pas les ressources ou les compétences pour fixer, c'est folklo.

Donc non, c'est pas le seul déterminant, mais oui ça joue.

Ou si tu développes une CLI, ou si tu utilises le layout pkg/xxx. Also la règle s'applique pour les membres d'un struct.

Aie merde..

En mode appli ou SMS?

Tu peux peut-être demander à quelqu'un ? La fille qui habite chez toi vous aviez l'air d'être proches, si tu promets de la rembourser rapidement...

 
Ils ont tout mis dans le camping.

Jubi, Hephaestos, on me dit que G a un headcount non officiel à Vancouver? Vous savez si c'est de l'engineering ? (En MP si vous voulez)

Ça dépend, tu es éligible au bonus de cooptation ?

It's a new life

J'imagine ? Je connais pas les critères d'éligibilité, la dernière fois que j'ai passé (fail) des entretiens chez G c'était en 2018.