Reprise du message précédent :

Pour Tomb raider pourquoi pas, mais le bench de Cyberpunk fait pas rêver. Déjà en medium c'est pas ouf mais alors jouer à 30 FPS.

J'me doute que la console peut pas faire tourner en RTX ON et tout hein. Mais du coup, autant citer des jeux qui tournent à 60 FPS.

 
Sympa le thread. Ils ont l'air bons Cure53
En même temps penser qu'on peut dev un desktop crypto wallet avec Electron, y a des gens qui ont peur de rien visiblement

C'est sur un écran de 7", ca va être dur de voir les details

la psychiatre vient de m'envoyer un document appelé "ADULT ADHD SELF-REPORT SCALE (ASRS-V1.1) SYMPTOM CHECKLIST"

Je viens de regarder, je coche pas mal de cases.
Cela dit vu que c'est a priori génétique et que ma fille est diagnostiquée tdahp...

On aurait dû l'écouter : https://twitter.com/NicolasSarkozy/ [...] 1926808576

Nan mais déjà la première question

Ouais ils ont aussi fait des audits pour mozilla, rustls, … et à chaque fois que je les vois mentionnés c’est très positif.  

Même pas en rêve j’ouvre ça, le déni c’est comfortable.

Il manque la case "each and every time"

 
Mon généraliste qui me laisse en plan depuis 1 mois alors qu'il doit me mettre en relation avec un spécialiste pour un diag  

Ca dépend de beaucoup de choses comme la culture de la boite, l'organisation de l'équipe, les rôles et séniorité de chacun. Tu as souvent quelqu'un qui a un rôle type scrum master qui est censé un peu structurer ton meeting et faire en sorte que vous ne descendiez pas au niveau des conditions à mettre dans les If, par contre s'il y a plusieurs options techniques vous pouvez prendre un peu de temps pour en débattre et déterminer collectivement quelle est la meilleure option, ou décider, là encore collectivement, de l'ajourner pour creuser le point.
 
 

Oui enfin tant qu'on est là le périmètre n'est pas livré à temps, pas dans le budget et pas au niveau de qualité demandé. Dans un contexte COGIP, le premier truc qui lâche est 95% du temps la qualité, et ensuite c'est un peu selon le projet et l'impact que cela va avoir pour la carrière du sponsor métier d'être en retard ou d'être hors budget
 

Le dév qui passe la moitié de son temps à traiter des problèmes qui n'arriveront jamais est beaucoup plus fréquent et mérite aussi le cassage de genoux
 

Les ravages d'une enfance avec Tintin au Congo, c'est pas vraiment de sa faute

Tu dois avoir 80% du topic qui rêve d'être diagnostiqué comme cela

 
Perso je rêve de pouvoir me concentrer plus d'une minute sur un truc qui m'emmerde en fait.

 
Bof, le diagnostic apporte pas grand chose pour ceux qui n'ont pas de pbs liés / qui s'en accommodent bien...
...et après chez les adultes je sais pas trop ce qui existe comme traitements, genre la ritaline c'est utilisé que chez les gosses non?

Oui, la tendance à l'over engineering est clairement présente chez beaucoup de devs. Note cependant que t'as rarement le business ou le management qui pousse à faire de gros refactoring "pour aller plus vite", alors que le fait de pousser à faire des trucs "crados" à tendance à être plus fréquent

Oui moi aussi, surtout sur ma phobie administrative
 
Et je ne dis pas que ce n'est pas sous diagnostiqué, que personne n'a ça sur ce topic ou que les diagnostics fait par de vrais médecins sont foireux, mais juste que presque tout le monde ou presque ici va chouiner qu'on ne finit pas les trucs qu'on commence et qu'on procrastine    

C'est en train de changer, un peu.

Non. Et c’est pas le seul médoc, selon le cas tu peux aussi avoir tenex / estulic, LDX, dexedrine, …. Généralement accompagné de thérapie pour mettre en place des stratégies d’adaptation.

 
Je vois une sorte de pattern comme ça (grosso modo) selon l'expérience :  

• 0 à 2-3 ans : code crade ou maladroit
• 2-3 à 6-8 ans : tendance à l'over engineering
• 6-8 et + : lisible simple efficace etc

Hello, on fait régulièrement dans mon équipe des mini prez techs sur des sujets qui nous intéressent sans forcément de rapport direct avec l’opérationnel. Je voudrais en faire une sur Rust, parce que pour le moment j'aime beaucoup le langage, même si je ne l'ai jamais utilisé dans le cadre pro.
En dehors des arguments classiques présentés sur le site officiel, j'ai un "feeling" que je voudrai exprimer, mais je ne sais pas si j'ai raison d'avoir ce feeling et, le cas échéant, si je l'exprime suffisamment clairement.  
 
L'idée que je voudrais faire passer :
 

 
Bref, est ce que d'autres personnes qui ont testé Rust partagent aussi ce "feeling" ou je dis de la merde ?
 
( après je parle aussi des défauts du langage, notamment la courbe d'apprentissage )

 
Ouai voilà... Quand je dis que les mecs comme ça ont honte de rien !

 
Putain, ça me conforte quand même bcp dans ma tendance à vouloir jeter au feu tout ce merdier.

 
J'te sens tendu en ce moment. Allonge toi sur le canapé, on va en discuter.

 
Nos SM ont été balancés là par hasard, dans la majorité des cas ils n'apportent rien du tout.
 
Même syndrome que le mec qui devient PO et qui sait à peine rédiger une US.
 
C'est triste

Tu ne serais pas black, plam te proposerait un job

 
A vrai dire avec quand meme un peu d'XP sur Rust maintenant, si je devais commencer une présentation, je partirai sur match:
 
Des cas complexe de match:
https://doc.rust-lang.org/rust-by-e [...] match.html
 
Des cas avec des match de bout de struct:
https://doc.rust-lang.org/stable/bo [...] art-values
 
Partant de la j'expliquerai pourquoi match existe par rapport a IF, j'escaladerai sur le fait que match est un des nombreux éléments qui rend rust tres stable (avec Result, Option et j'en passe).
 
Et apres j'expliquerai que grace a cela, ben ca fait de rust un language bas niveau dans lequel, globalement, si ca passe la compilation, t'a de bonne chance que ca ne plante pas trop (pas trop seulement). Qui a donc un assez bon mix entre performance, qualité de code (je remarque que, comparé a n'importe quel language interprété, le cout de faire "a l'arache" en rust est tellement élevé que souvent ca te force a aller a l'essentiel), et stabilité sur le long terme.

ah tiens. Hier j'ai discuté avec un PO un peu juju.
 
On doit faire converger 2 modèles qui fonctionnellement ont plein de trucs en commun (normal, c'est un seul domaine métier, découpé en sous-ensembles par type de Message entrant)
 
Allez savoir pourquoi, ils ont décidé de confier le dev de l'IHM de gestion de chaque type de message à une équipe différente.
Chacune avec un PO
 
Je lui ai demandé un MCD du domaine métier...Il m'a d'abord demandé ce que c'était.. Et qunad il a compris il m'a dit que c'était le boulot de l'équipe de dev, que eux les POs il faisaient les écrans.
 
Je sais pas quelle formation il a, mais il me semble qu'il y a des trous quand même.

c'est un natasserie ce truc  

C'est pas un UI Designer qui a changé parce qu'il allait être mieux payé en tant que PO ?

je sais pas.
 
Non, mais c'est courant chez ce client : les mecs pensent que "appli = IHM"
 
Les services qui se parlent dans tous les sens dans le SI, il faut les éduquer pour qu'ils comprennent.. Il y en a qui n ecomprennent jamais. Sur mon projet d'avant on n'avait pas d'IHM, le mec a tenu 2 mois, à nous faire des US avec des écrans d'applis qui appelaient nos services (pas directement) et on lui disait que non, il nous fallait une description des donées à envoyer.

       
2 mois quand même, respect    
 

Alors peut être... Mais écoute on ne se connait pas bien donc je ne sais pas à quoi tu ressembles, cependant j'ai un peu étudié en live et il lui faut au moins un cul de gonzesse, le niveau de mélanine ne suffit pas  

 
Sprints de 2 semaines :
un sprint de WTF de notre part  
un sprint de boudage intense de sa part et de résistance passive de la nôtre
2 sprints pour trouver un remplacant
 
 

Faut voir d'où ça part en fait (quel est le type d'audience), parce que match et le reste du pattern matching (let, if let) c'est assez bateau dans les langages fonctionnels.

Si c'est pour des purs impératifs, alors oui commencer par parler des ADTs & match, avec Option/Result amenés derrière, peut être sympa. Ça peut être embrayé sur l'ownership pour montrer les machines à état validées statiquement.

Pour le bas niveau ou la gestion des resources, RAII et le fait que l'ownership soit vérifié statiquement est utile, pour les gens qui viennent du cpp parler de trucs genre destructive moves, iterator invalidation, tout ça. Mentionner que les fonctionalités sont orthogonales est utile aussi, t'as pas le problèmes des copy ctor et autres conneries, et `drop` c'est juste `drop`.

Pour plus montrer les trucs sexy, les APIs genre hash_map::Entry, ou l'idée que mutex/rwlock ce sont des conteneurs, "protégés" par l'ownership et le borrow checker, c'est assez

Pour les gens qui ont de l'expérience dans la merde qu'est le multithreading, Sync/Send .

edit: si c'est des pythonistas qui se font bouffer par asyncio,

#[must_use = "futures do nothing unless you `.await` or poll them"]
pub trait Future {

Je coche surtout la 5

 
Depuis quand les PO font les MCD ?

Définir le domaine, les acteurs, les relations et ce genre de trucs c'est le boulot du métier, pas celui des devs.
En l'occurrence ça serait plutôt le boulot des urbanistes du si de faire ça, mais les PO DOIVENT en avoir connaissance, et répondre aux questions des devs pour que l'implémentation soit correcte.

Exemple : c'est au PO ou au métier de décider si on mélange ou pas les adresses de clients avec celles des compteurs dans la DB, sur la base de ce qu'il sait des cas d'utilisation et de ce que lui disent les devs en termes d'impacts de chaque solution.
(En plus on a un PO technique a côté du PO fonctionnel)

Après réflexion chuis d'accord avec g5, au premier commentaire pensant au modèle logique voire physique j'étais comme rati (c'est un des problèmes de parler de MCD au final c'est pas assez précis) mais c'est clairement le boulot du métier (donc du PO) de pouvoir formuler le modèle conceptuel, pas juste de définir les vues externes mais pouvoir articuler les relations entre les concepts de haut niveau, s'ils y réfléchissent pas soit le dev va devoir remonter en permanence pour lancer une réflexion sur la question, soit il va devoir prendre des décisions exécutives qui vont pas nécessairement coller aux besoins métier, et on peut se demander quel est le rôle du PO hors lécher les couilles de son n+1.

Tu ferais pas du Java ?

Pour les gens qui progressent, j'ai eu des collègues avec 10-15+ qui étaient encore au stade du 0-3 ans