Reprise du message précédent :

Pareil sauf qu’il me reste que des E14 en stock
 
Edit: ah non j’ai du G4 au dessus de l’évier mais je les utilise jamais.

Tu dois confondre avec Haskell & Scala

Son point de reference est Go, vu la distance il y a aucune différence, surtout depuis qu’arecibo s’est vautré

Je confirme, vu d'ici c'est la même chose pour moi. (Sauf qu'on n'a pas Haskell et Scala à Google du coup ça ne me préoccupe pas.)

Nico, tu sais s’il y a moyen de trouver sur quels ports un process écoute (style netsock / ss) en python?

non, pas vu passer mieux que d'appeler une commande externe.
 
sauf si tu as fait le listen toi-même dans ce cas tu dois pouvoir relire le port sur la socket.

En fait psutil a une méthode connections(), c’est pas plus compliqué que ça    
(Quand t’es pas sous wsl).

Bon choix Lady Gaga, elle envoie du bois.

Extrêmement inquiet par le choix de J.Lo par contre.

#vraisproblèmes

Tu te rends compte que les démocrates ne gagnent plus une élection nationale sans un fort soutien hispanique ?  

 
Non mais on s'en fout de la politique intérieure putain, t'as déjà vu des vidéos Youtube où elle chantait live sans playback ?

Dans l'immense majorité des cas quand il y a du JLO qui passe je suis :

• en train de mater les culs des nanas qui dansent/se trémoussent
• en train de zoner à 3g de sang par litre d'alcool

Dans tous les cas pas à analyser une technique de lip sync  

 
Ne sois pas trompé par les cailloux qu'elle a eus, c'est toujours, toujours Jenny du ter-ter.

hé ho, hier j'ai passé ma journée à faire des requetes SQL parce qu'on est des manants, on a pas de dashboards propres.

vu ce que ça veut dire chez nous, je salue le courage des mecs qui se sont dit : allez, on pousse Kotlin. Y'a un peu de travail pour que ce soit bien intégré
 

go je trouve que ça rate le coche : c'est rapide mais c'est pas le plus rapide, niveau syntaxe y'a beaucoup plus agréable de nos jours (le fait qu'il y ait pas de for: loop simple genre for book in books: déjà c'est non)
 

Toi aussi l'as eu l'habitude d'avoir peu et maintenant t'as beaucoup ?

https://prnt.sc/xbuitu
 
Ce tableau vient de là.
 
Quelle est votre approche face à la doc ?
Là je suis dans une équipe qui fait de l'agile, et le manque de doc d'architecture autant que fonctionnelle se fait criant, au point que je me demande si quelqu'un sait comment le système fonctionne.

Je ne vois pas ce que la documentation vient faire dans les moyens de communications. Si on lit l'article, ça part de la documentation comme méthode pour établir les objectifs d'un projet, ce qui restreint quand même pas mal le rôle de la documentation en général ; et ça enchaine sur ces chiffres : In the Autumn of 2008 I decided to validate the lessons from MRT for agile software development teams through a survey that I ran on the Extreme Programming, Scrum Development, Test-Driven Development (TDD) and Agile Modeling mailing lists. Le gars il veut valider sa théorie sur la pertinence des méthodes agiles, et il pose la question sur les mailing lists Agile. Habile.

https://twitter.com/ABCPolitics/sta [...] 77/video/1
 
Ça aura pas attendu longtemps tiens

Pour répondre à ta question, perso ça fait bien longtemps que j'ai pas vu une documentation produit mais c'est parce que je suis trop bas dans la chaîne alimentaire. Je demande aux PMs quand j'ai besoin de clarifier quelque chose. À mon niveau, la documentation c'est
- celle du code, rien à t'apprendre.
- les design docs : dès qu'une discussion sur un choix de conception apparaît non trivial, on crée un design docs pour l'héberger, et materialiser les choix qui sont faits. Ils ne sont pertinents que quelques mois en général, mais ça reste des ressources archéologiques intéressantes. C'est aussi des artefacts essentiels pour les dossiers de promotion.

https://www.dealabs.com/bons-plans/ [...] RTY2079404 mmm sexy

Oui on en avait pas mal parlé, c'est un bon écran pour un excellent prix.
Par contre une curvature à 1500R je ne sais pas comment les gens supportent.
 
A la limite le 1000R sur un Odyssey G9 en 49" je comprend car ça t'entoure vraiment, mais du 1500R sur un 34" je capte pas... (mais les gens font ce qu'ils veulent tant qu'ils sont heureux et que le marché continue de fabriquer de bons écrans qui me plaisent )

je suis content de mon 38"
par contre en réunion en partage d'écran les gens avec un petit écran (clb) veulent que j'agrandisse (cmb)

chez Nespresso on avait fini par avoir de la bonne doc fonctionelle : process documentés et tenus à jour pour les trucs touchy (genre les 150 trucs qui se passent quand tu cliques "order" ) , bonne couverture des features, etc... ça permettait de servir une grosse communauté de gens (marchés, équipes de call center) sans jamais devoir déranger un dev.
Ça servait aussi pour le dev pour savoir en quoi les choix impactaient des process métier compliqués
 

Ici y'a une excellente traçabilité des choix techniques je trouve (les design doc sont référencés dans les PR en general, donc en remontant le code, tu trouves les docs nécessaires, à la fois les commentaires dans les PR et les docs associés)
Par contre si tu veux une overview de comment les systèmes sont architecturés (des grosses boites avec des flèches), ou une bonne vue d'un process fonctionnel, ben t'es bon pour créer la vue toi meme en compilant les mini-docs crées par les 10 équipes qui touchent ton process, en interviewant plein de gens (y compris des qui sont partis dans d'autres équipes), et je trouve ça assez chiant perso.
Ça rend l'onboarding sur n'importe quel sujet beaucoup plus dur que nécessaire (par comparaison à l'état qu'on avait obtenu chez Nespresso)
 
La culture ici est très réfractaire à la doc sous prétexte que "oui mais les systèmes changent, tu comprends"
 
 

Moi j'ai remarqué que la bonne doc c'était toujours dans le projet d'avant ou la boite d'avant, jamais vu personne qui était content de la doc à un instant T.
Sauf au moment où tu dis qu'il faudrait peut être cut des features, du refactoring and co et là la doc devient "pas mal" et "plutôt complète".

Bah c'est normal de ne jamais être satisfait de la qualité de la doc ou du code, ça n'empêche pas de découvrir qu'ailleurs c'est bien pire et de regretter après coup  
 
Je suis étonné dans le tableau "Within team" de la différence entre face to face et teleconf/videoconf, c'est peut-être lié à une certaine taille d'équipe mais sur un groupe de 3-4 personnes la différence ne me semble pas énorme  

 
Parce que le challenge de la doc, c'est justement le fait qu'elle soit up-to-date. Les gens se concentrent sur le support de la doc au lieu de se concentrer sur le "content" et surtout sur l'actualisation.
 
Ici, la solution que j'ai trouvé est la suivante :
 
- On utilise une plateforme appelée bookstack qu'on a un peu customisé.
- Les articles appartiennent par défaut a celui qui les crée, mais le créateur a la possibilité d'assigner l'article à un autre user s'il estime que cet autre user est plus à même de suivre l'évolution de ce dont il est question.
- Tous les 6 mois, un reminder est envoyé au proprio de l'article qui doit vérifier que l'article est toujours à jour et sinon, il corrige l'article en question. Cette personne est officiellement responsable du contenu de l'article. Si plus tard le support se plaint ou quelqu'un d'autre, on se retournera vers elle. Il va de soi que l'utilisateur n'est pas obligé d'attendre 6 mois avant de mettre à jour l'article s'il est au courant que quelque chose a changé entre temps.
- Quand un utilisateur quitte la boite, tous ses articles sont assignés à un autre user qui devient responsable des articles en question.
 
Le fait d'être responsable des articles est dans les jobs specs et les personnes qui s'en foutraient auront des avertissements (ça s'est jamais produit, car le système en place est récent) et ce sera considéré comme faute professionnelle. On a été très clair là dessus et le principe a été accepté par tous les utilisateurs. On sait aussi si l'article en question a été reviewed ou pas.

Non, il part de la documentation comme moyen de transmettre des infos entre membres d'une équipe et des personnes extérieures, donc de la communication.
Parmi ces informations, il y a des descriptions techniques et des descriptions fonctionnelles, et de ses sondages, il conclue que le plus efficace est le "just barely good enough", quand on peut s'en contenter.
Je ne suis pas forcément d'accord, mais il a quelques arguments.

J'ai connu le mode full cycle en V, chez Portos, et c'est une perte de temps phénoménale: des équipes entières à glander en attendant que la doc soit "terminée" (et de toute façon elle sera obsolète tôt ou tard).

J'ai connu le mode "mi agile", aka un product manager qui écrit une doc fonctionnelle, moi qui la traduisais en doc technique, et des itérations de 3 semaines à un mois: mon fonctionnement préféré.

Et là le mode "full agile", aka on code et on voit si ça marche.

Voila, c'est exactement le problème que j'ai.
Là, j'ai développé un petit process avec un truc BPMN nommé Camunda (pas mal du tout au demeurant), le bouzin fait son truc dans son coin, fonctionne impec sur ma machine, mais sur l'environnement de test un autre process vient interférer avec (après une heure de débogage). Et bien sûr, on ne m'en a jamais parlé, donc je ne sais pas si c'est normal, vu que rien n'est documenté. Et ce qui est plus inquiétant: personne n'est capable de répondre.
Donc là on n'est même pas au niveau "just barely enough".

Franchement, je n'arrive pas à tirer d'information utile de cet article. Le sondage parle de communication en général tandis que le reste de l'article se concentre sur les requirements specifications, du coup ça ne colle pas vraiment à l'argumentaire global. Il me semble évident que les équipes agiles ne vont pas favoriser la documentation comme moyen de communication, ça ne veut pas dire grand chose. Et même au delà de ça, utiliser un document comme moyen de communication, ce n'est pas faire de la documentation à mon avis. La documentation c'est quelque chose d'uni-directionnel, ce n'est pas de la communication. Utiliser un document comme support de communication c'est ce qu'on fait pendant la phase d'élaboration, et le document à ce moment n'est rien de plus qu'un support.

C'est plus que ça, c'est un moyen de stocker et de retrouver de l'information.
A mon sens c'est l'aspect essentiel qui manque dans cet article.

Oui, mais du coup en tant que support de communication, ça présente des avantages et des inconvénients. Les inconvénients sont évidents : c'est lourd, c'est lent. Les avantages c'est que la discussion est encadrée, structurée, elle a un objectif clair, et souvent une personne (l'auteur) qui est pleinement responsable du produit de la discussion.

En plus de ça effectivement, un document laisse une trace, et peut devenir de la documentation. Selon la nature du document et ce qu'on souhaite en tirer, ça peut n'être pas du tout pertinent.

Les limites que je voie au dernier mode, et que j'ai rencontré relativement souvent dans mes startups, c'est que passé une certaines taille/historique, t'as forcément du code un peu "bizarre" qui traîne qui a été accumulé (pour gérer les bugs, les edge cases, des légères modif de la fonctionnalité au cous du temps).
Et du coup quand t'as typiquement un bug report d'un user/du business par exemple, tu lis le code, tu vois qu'en fait le cas est "normal" (dans le sens ou ça a été "codé comme ça" ), par contre est ce que le code comme ça c'est vraiment voulu ? Ou est ce que c'est un truc qui n'a pas été vu à la recette ? Ou c'est un comportement bizarre, mais parfaitement "normal" parce que y a 2 ans un gros compte avait une utilisation un peu bizarre du produit et donc fallait que ça fonctionne comme ça ?
Si t'as que le code, sans aucune doc, c'est impossible de répondre à ces questions, t'es obligé d'aller pinger les gens qui ont bossé là dessus (en espérant qu'ils sont toujours dans la boite )

T’as aussi le cas des erreurs émergeant de changement d’utilisations, le code est plus appelé pareil et ça permet d’attendre des cas limites qui initialement étaient inaccessibles.

 
tu as raison, mais pour le coup après 5 ans chez Nespresso, et en était parti de rien, j'étais hyper satisfait de la doc à partir de mi 2013 (soit 3.5 ans après le début)
 
on avait un wiki confluence, tout le monde pouvait éditer toutes les pages, et gros focus sur le fait de tenir à jour. On avait aussi une culture de "check the wiki first", ce qui filtrait le gros des questions "triviales"
Du coup les équipes avaient vite compris qu'avoir une doc à jour réduisait le bruit.
L'autre avantage c'est que la doc c'est lisible par des non-dev.
 
Chez Google la qualité de la doc est extremement variable : ça varie de inexistante à absolument phénoménale. De manière générale, le doc technique est bonne (grosse assumption que tu sais lire du code ce qui est largement vrai ici, donc la doc couvre plus les choix techniques (les commentaires sont en general la meilleure expression fonctionelle que tu puisses trivialement trouver, ce qui est terrible), la doc fonctionelle est inexistante, merdique au mieux.

La classe mondiale... Peut être même le champion du monde  

https://twitter.com/SenTedCruz/stat [...] 29312?s=20

voila et c'est comme ça que tu te retrouves avec du legacy que personne ne veut toucher, parce que c'est en prod.

Je pense que c’est la pire des conneries de prendre Ted Cruz pour un demeuré, il est intellectuellement brillant et ça le rend extrêmement dangereux malgré son charisme de moule

Bah écoute fallait m’acheter un audit à l’époque  

Il se prend un beau ratio.
La réponse d'AOC: