FUUUUUUUUUUU UUUUUUUUUU UUUUUUUUUUU UUUUUUUUUUUUU - Page 52

En fait mon collègue a apparemment un problème. Ca fait 4 mois, et tout le temps, constamment son nez se bouche en fait. C'est pour ça qu'il renifle, c'est pour ça qu'il slurpe et doit inspirer des masses d'air après. Même s'il reniffle toute la merde possiblement contenue dans ses sinus, même pas 5 secondes plus tard tu l'entends essayer de respirer avec le nez et que ça bloque, donc il ouvre la bouche. Ca doit être super dur à vivre mine de rien (J'ai moi même un peu ce souci, disons que j'ai un écoulement nasal constant mais là comme ça fait super longtemps que je ne suis pas tombé malade, pas même un rhume c'est super léger).

Par contre un autre (pas le phacochère non plus, lui a guéri \o/) m'énerve à tout le temps gratter sa gorge ; c'est pas un bruit normal, c'est un peu comme un moteur de tronçonneuse qui bloque contre un arbre aux noeuds un peu trop durs, vraiment très fort (alors qu'on peut se gratter la gorge quasi silencieusement, du moins pour le grattage régulier et sain qu'on ferait 2~3x par minute comme lui).

Je pense que tu devrais écrire un livre pour enfants, "Les collègues de Brunni", avec des jolis dessins du phacochère, du bûcheron, etc.

nhut?

Collab avec Nhut <3

Je crois que je pourrais les dessiner tout seul. Pas difficile. Et moi-même en caméo

Je n'en peux plus putain. Maintenant il y a la vieille jeep rouillée qu'on a sortie de la jungle du vietnam qui s'est mis à essayer de démarrer, 4x par minute, sans une goutte d'huile évidemment. Avec quelques reniflements et toussotements entre deux. Ils se sont organisés un tournus pour tomber malade. Mais bon ça c'est pas grave.

BIen sûr je pourrais gagner du temps en ayant un bon environnement (mon collègue a un vim tout customisé où il est apparemment capable d'aller d'un fichier à l'autre, c#, javascript, c++ etc. et il a les bons raccourcis, plugins, etc.) mais perso je ne sais pas, je n'ai même pas encore une vue complète du projet. Chaque modif, ne serait-ce que pour mettre un log je dois recompiler et attendre un peu plus d'une minute. Et encore, c'est après avoir bien optimisé le build process. Je fais ça toute la journée. J'attends. Je perds de la tête ce que j'étais en train de faire parfois, il me faut quelques tentatives de plus avant d'y arriver. C'est du javascript (la partie où je suis actuellement), c'est hyper compliqué (traitement d'événements de l'UI), il y a absolument zéro commentaire à part l'en-tête des fichiers, j'ai aucune idée de ce que signifient les paramètres (normalement ils sont nommés correctement, mais quand même, et Javascript n'affiche même pas au runtime le "type" que c'est donc il faut faire un best guess ou déranger le lead programmer, qui encore une fois est une ressource super limitée -- là ça fait 30min+ qu'il aide un autre gars). Je veux déboguer des trucs mais souvent c'est impossible parce que JSON.stringify dit qu'il y a une dépendance circulaire. Chaque modif, on arrête, on recompile, on recommence, on perd une minute+. Certaines commandes comme console.trace() ne fonctionnent pas, pour je ne sais quelle raison alors je dois faire un try catch et print l'exception pour avoir une idée de ce qui a bien pu se passer pour arriver dans cette partie du code. Il y a un moyen d'attacher le process à Chrome mais pour une raison inconnue sur MA machine le clavier ne fonctionne pas. Je dois ouvrir une hiérarchie à plus de 15 niveaux avec 5 objets en moyenne à chaque étage, à la main, clic par clic, en ne me foirant pas, et ce à chaque lancement (donc petite modification). Les objets sont distinguables par leur identificateur, comme par exemple module-cb5f5f3c-e77a-4c6f-b68f-0fbad5ca28c0, il ne faut pas se planter. Et certaines choses sont randomisées à chaque démarrage pour une raison encore obscure.

Oui je pourrais investir un effort massif pour améliorer mon environnement de développement, mais sérieux quoi. Le lead programmer apparemment il a juste tout en tête. Il va de fichier en fichier, il sait exactement où est quoi pour n'importe quelle partie. Effrayant.

Pauvre Brunni

Tu ne peux pas porter un casque, ou au moins des écouteurs ? Ça te couperait un peu des bruits extérieurs, et la musique te rendrait peut-être ton boulot un peu plus supportable.

Brunni (./1535) :
Oui je pourrais investir un effort massif pour améliorer mon environnement de développement

Comme changer de taf par exemple ?

Dites moi seulement que c'est pas partout comme ça le monde du software si ?
Et en ce moment je m'en fous de la Lada rouillée à Hitler qui traine son pare-choc dans les rues pavées de Moscou à vrai dire, ce qui m'énerve c'est cette impression de perdre mon temps. Ma vie. Chaque boulot jusqu'à maintenant ça a été ça. La seule chose que j'ai aimée c'est quand je faisais mes propres jeux, ou Highway Runners. Je choisissais mes technos, j'étais pragmatique, faisais des choix qui avaient du sens, je mettais des commentaires (sans non plus avoir à les formater en XML ou à répéter des trucs qui sont déjà déduisibles du prototype comme dans d'autres nazi-compagnies), optimisais l'environnement de dév pour pouvoir faire du debug/test rapide, etc.

non, c'est pas comme ca partout

il y a un sacré problème de qualité logicielle par chez vous.
-absence de commentaires BAD
-connaissance centralisée BAD
-archi merdique uber compliquée BAD

a ce point la je dirais casse toi ou alors accepte d'être inefficace, car c'est pas ta volonté. si on te dit la moindre chose, plains toi de l'environnement de merde.

tu pars quand, déja?

En mars. Mais la prochaine compagnie, même si elle sera sans doute mieux, ne me dit pas tant plus non plus (on fait des projets pour des clients, mais au moins c'est lié au JV et c'est avec des français donc niveau communication et esprit de groupe ça devrait aider). Donc j'ai peur de me retrouver dans la même merde.

Le plus dur est de savoir quoi chercher. Déjà 1) pour avoir un espoir de mieux, mais aussi surtout pour reprendre le pouvoir et apporter une contribution UTILE à la société, tant qu'à y consacrer la moitié de mes heures en vie. Trouver ce boulot sera une formalité lorsque je saurai ce que je cherche.

Et sinon oui c'est BAD comme tu dis mais absolument TOUT ce que je vois est bad. Et malheureusement j'ai un gros ego d'enculé, je peux pas "accepter d'être inefficace". Ca me plombe toutes les autres facettes de la vie avec : le fait d'accepter d'être "inutile"/"mauvais" dans une activité qui correspond à 50% de ma vie active signifie que je SUIS inutile/mauvais. Mais faut bien bosser quand même, j'aimerais vraiment trouver à terme qqch où je peux me poser et avoir des revenus stables, et me sentir faire partie d'une structure, en tant qu'homme. Tous ces bobos qui veulent utiliser du new&shiny parce que ça leur permet de mettre sur pied un prototype en 2 min et qu'après ils se disent on va faire une startup avec. Soyons franc aussi, on ne peut pas non plus maîtriser le code d'une plate-forme web. C'est trop complexe, trop gros, la concurrence va trop vite, pour ne pas utiliser des frameworks, des raccourcis, etc. résultat je ne peux pas non plus condamner. Mais quand t'es pas le gourou par contre c'est super désagréable...

Lol, mon collègue vient de me laisser en me disant 質問を纏めたらまた呼んでも良いですか？ Façon plutôt polie de me dire "débrouille toi encore un peu seul". C'est vrai que je lui ai déballé toutes les zones obscures et la page A4 de schémas tentant de représenter ce qui se passe dans le système lors d'un clic, que je réalise depuis le début de la journée. Il se trouvait que je ne regardais même pas au bon endroit finalement pour le truc que je voulais corriger

le fait d'accepter d'être "inutile"/"mauvais" dans une activité qui correspond à 50% de ma vie active signifie que je SUIS inutile/mauvais.

C'est la qu'on a pas le même caractère. pour moi dans une situation comme ca c'est EUX qui sont mauvais, pas moi, et ils me méritent pas. mais je comprends ce que tu veux dire.

Dans un gros projet y'a toujours un historique et faut du temps pour se plonger dedans, mais depuis le temps que tu galères c'est juste ce projet qui est mal foutu, vu tout ce que tu racontes c'est évident.

Ben après t'as les doutes, est-ce que c'est moi, est-ce que j'essaie pas assez fort, est-ce que je suis trop difficile, quelle est la limite "acceptable", à partir de laquelle tu dois accepter de faire avec, etc. tu peux pas dire si c'est toi-même ou l'autre.

C'est exactement ça. Être dans un environnement dysfonctionnel ou mauvais, à long terme, ça fait douter les gens d'eux-mêmes. Et ça ne concerne pas seulement ceux qui n'ont pas assez confiance en eux, ça peut arriver à tout le monde. C'est d'ailleurs une tactique utilisé par certains managers pervers qui veulent se débarrasser de quelqu'un sans devoir le licencier : ils créent insidieusement un cadre de travail pourri, pour que la personne en vienne à se plomber elle-même.

Et même si tu as confiance dans tes capacités, travailler dans un environnement comme ça est démotivant. J'avais eu cette discussion avec un chef (par ailleurs très bien) à un de mes ex-boulots. Je lui expliquais que comme d'habitude, la spéc que nous avait donnée un autre service était pourrie (incomplète, floue, des paragraphes qui se contredisent entre eux, etc.) et que si on implémentait tel quel ça ne marcherait jamais. Il m'avait répondu "je sais bien, on leur dit à chaque fois ; mais c'est pas grave, c'est de leur faute, on leur facturera toutes les corrections". Ben je n'ai jamais réussi à lui faire comprendre que c'était démoralisant de bosser sur du code dont on sait d'avance qu'il ne fonctionnera pas et qui partira à la poubelle. Résultat, je me suis barré au bout d'un peu moins d'un an parce que j'en pouvais plus (ce que j'ai raconté là n'était que le sommet de l'iceberg).

Si tu veux éviter ça je ne vois que deux méthodes :

- trouver une boîte qui ne fait pas n'importe quoi. Ça implique de les évaluer avant de postuler, via ton réseau, les sites comme Glassdoor, etc.

- t'établir comme indépendant. Mais pour les revenus réguliers, à moins que tu gères super bien, faudra pas y compter avant un certain temps. Et ça ne te libère que partiellement des contraintes à la con des clients (mais au moins, tu auras le contrôle sur ton organisation et tes outils de travail).

Ou alors il faut devenir le gigolo d'une japonaise qui cherche un étranger

Tu peux etre dans un boulot super mega giga interessant, mais ou le management fait de la merde, tu bosse pour 3 personnes et on arrive encore a toujorus te faire des reproche que ca ou ca est alle trop lentement, que tel projet qu'on ta donne pour, je cite, "te faire plaisir", n'a pas aboutit (connard c'est vous qui m'avais fourgué cette merde qui etait voué a l'echec vu la gestion du dit projet, et j'ai ete preempte par vous pour passer en mode urgence sur autre chose*, en plus le projet en question etati bien avant le code a pondre un truc que je ne maitris(ais) pas lie a un phenomene physique loin d'etre simple, d'ailleurs le proto marchais extremement mal, et les merdes qui nous on ete fourni/donne pour faire un test d'industrialisation n'etait meme pas utilisable, la ou un PCB aurais du etre un flex, c'etait un PCB de 1.6mm d'epais, comment dire..)




* fallait voir la gueule du prototype du truc en question, meme un labo de recherche aurais refusé de s'y pencher dessus.

Et même si tu as confiance dans tes capacités, travailler dans un environnement comme ça est démotivant

ca, oui, ca peut être chiant, et si rien ne change faut se barrer.

Sinon je dois avoir une sacré estime de moi même parce que j'arrive souvent a déterminer, si on me donne un truc infaisable ou merdique, que c'est pas moi le souci mais la chose donnée, et je n'ai pas ces doutes de valeur. je le *sais*, et la question ne se pose même pas.

Note: Je dis pas ca comme qc que tout le monde doit faire, mais comme une observation scientifique de moi même. je comprends bien que c'est pas le cas de tlm.

Bon c'est vrai que j'ai un bon contact avec toute ma boite et qu'on me respecte, ca aide...

Brunni (./1538) :
Dites moi seulement que c'est pas partout comme ça le monde du software si ?

Non, là ça a l'air d'être un projet bien pourri, avec un environnement pas maintenable.

squalyl (./1541) :
c'est juste ce projet qui est mal foutu, vu tout ce que tu racontes c'est évident.

Il suffit parfois de peu de choses. Par exemple, les gens qui mettent des String pour paramétrer des trucs dans les fonctions. Sans documentation. Tu ne sais jamais quoi passer à moins de passer un coup de débuggueur avant. Alors que la même fonction avec un enum rend tout immédiatement clair et facile.
Bref, si ton projet est intraçable et non maintenable, c'est qu'il est moisi.

C'est pas partout comme ça...


...mais c'est loin d'être une exception, malheureusement.

Mais c'est TOUT comme ça Pen^2. Dès que tu fais du javascript, ou N'IMPORTE QUEL langage de script genre python et toutes ces merdes, c'est immaintenable. Aujourd'hui j'ai écrit une fonction qui prenait en paramètre et recevait des strings style 'snapleft', 'snaptop', etc. et je devais les passer à une autre fonction qui prenait 'left', 'top', etc. je me suis dit, j'écris le snapResult.replace('snap', '') ? En plus y a aucune référence, n'importe qui qui change un des 'snaptop' n'aura AUCUNE idée que le code en dépend à cet endroit-là. Et paie ta façon propre de faire une constante dans ce langage !
Dans main.js t'as une table d'événements, et chaque événement doit être répliqué dans une autre table à un autre endroit, qui doit avoir les mêmes propriétés. Pas un commentaire. Par chance je l'ai vue et ai pu y ajouter ma propriété, mais dieu sait ce qu'il reste d'autre que je n'ai pas mis à jour. On le saura peut être en prod un jour avec un TypeError ou autre qui plantera la tablette quand on l'aura releasée sur le marché.
T'as aucun IDE qui est capable te sortir où est utilisée telle fonction, quel est le type du paramètre (je sais ça n'a plus beaucoup de sens avec les langages prototypés, mais un objet doit quand même remplir un contrat pour avoir un sens !), tu sais jamais les erreurs avant de tomber dessus, etc. alors oui c'est facile à hacker, facile pour le gourou qui a tout coder, mais merde à la fin. Soit le gourou c'est moi et je le dis clairement que c'est pas la peine de vouloir partager le projet, soit … on fait autrement merde.
Et utiliser un langage typé ça veut pas non plus devoir faire une interface et une implémentation pour chaque type, avec la documentation dupliquée !! C'est ce qui se passe dans notre partie C# qui est over-over formelle est illisible, dans un autre sens du terme (en comparaison du javascript absolument pas documenté du tout).
Mon code C++ pour Highway Runners, j'en ai déjà posté quelques exemples mais je trouve que c'est l'idéal. C'est quand même typé, tu peux naviguer et tout, mais c'est pas non plus documenté plus que raisonnablement nécessaire (genre le petit getter il aura un commentaire si ce qu'il fait n'est pas trivial ou si la propriété à laquelle il se réfère n'est pas claire). Les ownerships et autres trucs qu'on pourrait déduire d'un UML sont implicitement indiquées via les types de pointeurs utilisés (shared_ptr, etc.).

bref, javascript est pourri, et on le savait, malheureusement.

Oué, voilà.
Bon courage, sérieux...
Enfin si tu te barres bientôt, c'est déjà ça de pris, il suffit d'être patient

Tiens, un exemple d'un truc python lu hier : myVar = myVar[0]

Pen^2 (./1550) :
Tiens, un exemple d'un truc python lu hier : myVar = myVar[0]

au bûcher !

myVar[0] = myVar !

Pen^2 (./1550) :
Tiens, un exemple d'un truc python lu hier : myVar = myVar[0]

Oh, j'ai ça souvent dans du code... l'API LDAP de PHP renvoie des tableaux pour les résultats de requêtes, mais dans un certain nombre de cas (quand on fait une requête sur un dn, donc unique) on sait qu'on n'a qu'un seul résultat à traiter (s'il y en a plus, c'est qu'il y a un bug de l'API ou de la corruption des données, donc on lève éventuellement une exception, mais c'est un cas qui ne doit jamais arriver [sinon ça veut dire que le serveur ne respecte pas les RFC de base, donc on va avoir d'autres problèmes énormes plus importants ] donc on se passe de gestion d'erreur).
L'API renvoie en plus un élément du tableau dont la clé est "count" et qui n'est pas un résultat, mais une information sur le résultat (et on n'en a rien à faire).
Du coup, dans une grande majorité des scripts, on va avoir $resultat = $resultat[0];
Ca évite simplement d'avoir une variable intermédiaire inutile. Ce n'est effectivement pas propre, mais quand tu as des traitements qui sont toujours de ce type, c'est quand-même pratique (et c'est un usage assez généralisé dès qu'on a des scripts qui utilisent cette API). Mais c'est le typage faible de PHP qui permet ça.

Exemple de résultat (et encore, ce n'est pas le mode de résultat le plus verbeux) :
Array
(
[count] => 1
[0] => Array
(
[cn] => Array
(
[count] => 1
[0] => MON CN
)

[count] => 1
[dn] => uid=monUid,ou=Users,dc=maBoite,dc=fr
)

)
Cela dit, j'ai résolu le problème en maquillant la saleté, perso
J'ai créé une classe qui implémente l'API sous forme d'objets (elle est strictement impérative à la base) avec une méthode getSimpleResult() qui ne renvoie que le premier élément du tableau (en supprimant au passage les "count" qui sont inutiles la plupart du temps).

./1553
C'est fréquent d'avoir une méthode qui retourne des résultats dans un array, mais dont on sait parfois qu'un seul résultat est attendu, et pas envie de variable intermédiaire.
À mon goût, tant que le résultat et l'auto-assignation sont côte à côte, ça passe. Si les deux sont franchement éloignés, c'est un coup à se perdre.
Ce n'est pas rare sinon pour l'éviter que je fasse direct $maVar = $Objet->method()[0];

c'est le même genre avec sql quand tu fais par ex. un select COUNT, et que le resultat a juste une row, et qu'il faut quand même utiliser les API pour plusieurs rows.

Meowcate (./1557) :
Ce n'est pas rare sinon pour l'éviter que je fasse direct $maVar = $Objet->method()[0];

Oui là ça n'a rien à voir, c'est compact et potentiellement pas très sécurisé s'il existe des cas où le tableau est vide, mais au moins $maVar ne change pas de type en cours de route

La notion de typage est une notion toute relative
(et si $myVar[0] est un tableau, $myVar ne change pas de type )