Le topic de la programmation: Et envoyez des sioux!

[William Vaurien]

Jusqu'à mon récent projet en C, j'ai toujours vu du code en "mauvais" anglais...

Maintenant j'ai du code en mauvais "franglais": les parties technique sont souvent en anglais, mais tout le code métier est en français.

C'est assez étrange à lire au début, surtout le mélange des mots clé et des appels techniques en anglais et le reste en français.

Du coup je n'arrive pas trop à savoir ce qui est mieux: d'un côté un code plus cohérent, mais bien souvent maladroit dans le nommage et avec des termes métiers qui ne correspondent pas à ceux des utilisateurs.
De l'autre un code polyglotte (étrange à lire) mais répondant un peu plus précisément au besoin. (Faut pas se leurrer non plus, même en utilisant la même langue que le métier, les noms de méthodes et de variables sont parfois très obscures...)

[Møgluglu]

Par contre je suis d'accord que les caractères spéciaux doivent être évités.

Heureusement il y a les trigraphes.

J'évite les lettres minuscules aussi, elles ne sont pas présentes sur tous les claviers APL.

[Sariyah]

Parce que n'importe quel dev un peu sérieux sait qu'il faut coder en anglais.

En fait l'objectif est simplement de s’entraîner à faire des algorithmes et pas du tout de se prendre pour un développeur sérieux du coup peut être qu'ils estiment que pour un public francophone c'est plus simple d'utiliser des mots français pour une meilleure compréhension.
De mon côté j'utilisais pas d'accent et je vais désormais tout mettre en anglais ça me fera pas de mal et autant prendre de bonnes habitudes. De toute façon j'en ai résolu 8 hier et je suis à nouveau bloqué.

[ducon]

Parce que ton code peut potentiellement être modifié par un non francophone, quelqu'un qui n'a pas forcément accès à ces accents sur son clavier.

Si c’est pour un projet perso, rien à battre.
Sinon, tu codes dans Numworks, le µPython dedans n’a pas les accents.

[Tramb]

Si c’est pour un projet perso, rien à battre.

Les projets perso, rien à battre.
A part que ceux qui ont de la valeur deviennent des projets de groupe à terme.

[Dross]

"C'est juste temporaire !"

[TiNitro]

Heureusement il y a les trigraphes.

J'évite les lettres minuscules aussi, elles ne sont pas présentes sur tous les claviers APL.

[vectra]

PS: Je ne comprends *vraiment* pas pourquoi t'emmerder avec Jira pour bosser tout seul. Déja que ça gave au boulot dans des équipes plus grosses...

J'utilisais ça dans mon ancien boulot, et j'avais du mal avec faute de temps pour m'y intéresser vraiment.
C'est pas très bien fait, mais malgré tout, ça marche bien. Pour l'organisation des tâches, bugfixes & co, je trouve ça quand-même très pratique même si l'interface est frustrante.
C'est bien pratique d'avoir une intégration jira-bitbucket, et j'aime bien l'idée de documenter des tâches au fur et à mesure (y compris quand je suis pas dessus). Si je devais faire l'équivalent avec mes fichiers org, je ne m'en sortirais pas.


Un Kanban pour soi tout seul, c'est quand-même à la cool...
Et puis surtout, ça fera une ligne sur mon CV si je dois revenir dans le privé.

[Dross]

Jira c'est ce que j'ai trouvé de mieux niveau gestion de tâches et suivi (calcul vitesse de dev, projections, etc). Actuellement on est sur TFS et niveau gestion de projet c'est l'horreur, si vous avez mieux que Jira je suis preneur (qui fasse le minimum dans le cadre de dev Agile : donc gestion des UserStories => Assignement des Points => Suivi => Calcul de la vitesse de dev et des estimés pour les livrables), mine de rien ça cours pas les rues les outils qui font ça.

[Orhin]

J'ai pas testé mais apparemment "Youtrack" de Jetbrains est pas mal.
Après, Jira fait en effet le café pour la grande majorité des usages.

[William Vaurien]

Des post-its ça suffit, non ?



Je serais curieux d'avoir des retours sur les outils Jetbrains autre que les IDE. Je me suis toujours dit qu'ils avaient l'air plus sympa que les Atlassians qui sont puissant mais ont un côté usine à gaz... En plus l'intégration dans les IDE doit être bien faite. Mais bon Jira est tellement implanté que c'est comme 'frigo', c'est devenu un nom commun...

Youtrack, Teamcity, Upsources ? Quelqu'un utilise ça ?

Et autrement quelqu'un a déjà utilisé leur outil mps ?

J'avais regardé ça il y a longtemps, mais je dois admettre que ça dépasse mes compétences actuelles d'ingénieur Java

[vectra]

Pour moi, Atlassian et CLion, c'est un peu la même came: des softs Java qui rament leur mère. Sur des machines vieillissantes, c'est juste no go et c'est bien dommage.
Alors ok, les gens sérieux installent Atlassian sur un serveur séparé (j'y travaille), mais même comme ça...

Vivement mon 8600K.

Tiens, au fait, Intel a donné une date de sortie pour les successeurs du Coffee Lake?

[Getz]

Des post-its ça suffit, non ?
https://www.la-rache.com/img/logo.png


Je serais curieux d'avoir des retours sur les outils Jetbrains autre que les IDE. Je me suis toujours dit qu'ils avaient l'air plus sympa que les Atlassians qui sont puissant mais ont un côté usine à gaz... En plus l'intégration dans les IDE doit être bien faite. Mais bon Jira est tellement implanté que c'est comme 'frigo', c'est devenu un nom commun...

Youtrack, Teamcity, Upsources ? Quelqu'un utilise ça ?

Et autrement quelqu'un a déjà utilisé leur outil mps ?

J'avais regardé ça il y a longtemps, mais je dois admettre que ça dépasse mes compétences actuelles d'ingénieur Java

J'ai utilisé Youtrack et Upsource dans deux missions distinctes. Par contre, jamais utilisé Jira donc je peux pas comparer désolé!

Je trouve les outils Jetbrains (hors IDE )extrêmement intuitifs, faciles d'utilisation et bien loin de "l'usine à gaz" justement.

Youtrack, pour l'usage simple qu'on en faisait, nous suffisait amplement (c'est à dire seulement le suivi des bugs, pas de calcul de vitesse de dev comme j'ai vu plus haut) . La possibilité de se créer des filtres personnalisés est vraiment puissante. Je ne sais pas ce que ça vaut pour une utilisation plus poussée avec une grosse équipe.

Upsource je l'ai mis en place quand on était encore sous SVN (avant de migrer sous Git avec Gitlab). Ca a été le seul outil que j'ai pu installé sur notre serveur de dev limité en droit (les autres nécessitant des installations de composants supplémentaires), installation et configuration très facile et rapide. Il se plug sur SVN, CVS et GIT de mémoire (peut-être d'autres).
L'interface est très sympa, l'outil de diff est très efficace. Possibilité d'intégrer plusieurs commits (même de projets distincts, dans notre cas c'était back et front) dans une même review, d'annoter une ligne de code ou la review entière, tout en pouvant bien sur commenter et réagir à chaque annotation. Vraiment très sympa, mais suite à la migration vers Git, il faisait un peu doublon avec Gitlab et ses merge request.

[Max_well]

Si vous etes sous Jira et Eclipse, je vous conseille le plugin Mylyn, qui fait notamment de la sauvegarde de session eclipse (tu cliques sur le bug, t'as toutes les fenêtres sur lesquels t'était la dernière fois qui se rouvre, c'est magique)

[Foudge]

Pour moi, Atlassian et CLion, c'est un peu la même came: des softs Java qui rament leur mère.

Je profite de ta remarque pour poster un lien qui tourne dans ma COGIP depuis quelques jours : https://blog.romainfallet.fr/desenchantement-logiciel/
Qu'en pensez-vous ?

[Nattefrost]

@Foudge Ca en a causé dans le dernier épisode des castcodeurs et soulevé de bons contre arguments : https://lescastcodeurs.com/2018/10/0...ille-debout-t/ vers la fin de l'épisode (48:30 ,merci Raplonu).

[Raplonu]

48:30

[vectra]

Je profite de ta remarque pour poster un lien qui tourne dans ma COGIP depuis quelques jours : https://blog.romainfallet.fr/desenchantement-logiciel/
Qu'en pensez-vous ?

Mais ce lien
https://www.chrisstucchio.com/blog/2...op_hatred.html

[Paradox]

Pour moi, Atlassian et CLion, c'est un peu la même came: des softs Java qui rament leur mère. Sur des machines vieillissantes, c'est juste no go et c'est bien dommage.
Alors ok, les gens sérieux installent Atlassian sur un serveur séparé (j'y travaille), mais même comme ça...

Vivement mon 8600K.

Tiens, au fait, Intel a donné une date de sortie pour les successeurs du Coffee Lake?

Nan mais genre les gens installent ca en LOCAL ?

[vectra]

Tu fais comment quand t'as pas de serveur...
apt-get install Bi-Xeon?

Je te rassure, CLion n'a pas besoin d'Atlassian en background pour ramer / freezer.
Ca commence à aller à peu près bien sur un 2500K, donc je ne suis pas inquiet pour la suite de mon projet. Mais lancer CLion sur un PC Cogip, c'est une expérience vraiment très intéressante.
Je pense qu'il faut toucher dans les options pour mettre la sourdine à CLang quand on a une petite config. Mais même pour de vulgaires macros, faut pas les enchainer trop vite...

Emacs a beau être trop à poil, ca tourne à une vitesse de malade en comparaison.

[Paradox]

[QUOTE=Foudge;11967899]Je profite de ta remarque pour poster un lien qui tourne dans ma COGIP depuis quelques jours : https://blog.romainfallet.fr/desenchantement-logiciel//QUOTE]

J'en pense que c'est totalement vrai pour la majorite de l'industrie.

C'etait d'ailleurs mon probleme avant meme que je ne sorte de l'ecole et je ne suis pour ainsi dire pas directement specialise en info.

J'ai eu l'occasion lors d'une experience professionnelle d'aller en formation sur l'informatique scientifique et le traitement efficace, actuel et futur, de donnees et c'etait exactement pour lutter contre ca. Apres, pour l'appliquer c'est une autre paire de manches, surtout quand, de bas en haut de la hierarchie, tout le monde s'en tape, et qu'on prefere se toucher la nouille sur des langages interpretes lents comme un 38T sur une route de montagne, parce que c'etait/c'est tendance, au lieu d'essayer de comprendre effectivement ce que fait comme calculs ton CPU (voire ton GPU).

Et vu le virage ecologique que l'humanite doit prendre (et l'essor des processeurs ARM un peu partout), je predis d'ici quelques annees que l'on devra coder pour une enveloppe energetique definie dans la majorite des secteurs. Placez vos paris.

- - - Mise à jour - - -

Tu fais comment quand t'as pas de serveur...
apt-get install Bi-Xeon?

Je te rassure, CLion n'a pas besoin d'Atlassian en background pour ramer / freezer.
Ca commence à aller à peu près bien sur un 2500K, donc je ne suis pas inquiet pour la suite de mon projet. Mais lancer CLion sur un PC Cogip, c'est une expérience vraiment très intéressante.
Je pense qu'il faut toucher dans les options pour mettre la sourdine à CLang quand on a une petite config. Mais même pour de vulgaires macros, faut pas les enchainer trop vite...

Emacs a beau être trop à poil, ca tourne à une vitesse de malade en comparaison.

J'en demande un. Je recupere une vieille tour. Je ramene un vieux PC perso. J'en demande un a une universite/labo pas loin.

Nan mais soyons serieux 5 min : faut pas travailler comme ca, sinon ca n'a pas beaucoup de sens, ni pour toi, ni pour ta boite. Si jamais on t'en file un, paye ta migration...

Je ne sais pas ou tu travailles mais ca fait pas serieux...

[Dross]

Je profite de ta remarque pour poster un lien qui tourne dans ma COGIP depuis quelques jours : https://blog.romainfallet.fr/desenchantement-logiciel/
Qu'en pensez-vous ?

Je pense que c'est un mec qui ne connais pas les autres domaines de l'ingénierie : quand il dit "Les constructions modernes utilisent juste ce qu’il faut de matières premières pour remplir leur fonction tout en étant suffisamment résistantes pour garantir la sécurité de leur ensemble sous certaines conditions." c'est qu'il n'a jamais entendu parler du "facteur de sécurité" qu'on applique en mécanique : on est tellement "confiant" dans les calculs qu'on va multiplier par 3-5 voir jusqu'à 10 quand y'a des humains en jeu, donc oui, pas mal de conceptions ont en fait 10 fois trop de matière pour garantir la résistances aux contraintes calculées (on n'est donc plus dans du 95-100% comme il le dit, mais donc seulement à 10%).

Fun fact: sauf pour les avions, si on appliquais de tels coefs on ne saurait pas les faire voler.
Donc on met des coefs dangereux, de l'ordre 1-3, mais du coup, comme on n'a pas confiance, on teste chaque pièce, on fait énormément de maintenance, et surtout, on fait des trucs de tordus comme prendre un avion en fin de ligne de montage, et tirer dessus jusqu'à ce qu'il casse, et comparer le tout aux simulations.

[vectra]

Je ne sais pas ou tu travailles mais ca fait pas serieux...

Le problème de faire de l'informatique avec des scientifiques je suppose...
Avant d'espérer un serveur, déjà toucher ma machine de travail tout court.
Pour l'instant, une vieille gloire de 10 ans retapée avec des pièces perso. Et c'était la moins pire du lot...

Donc quand je toucherai mon 8600K, je pense que je serai heureux d'y faire cohabiter CLion et Atlassian, plutôt que de voir Atlassian ramer comme un con tout seul sur l'ancienne machine.

[Møgluglu]

Je pense que c'est un mec qui ne connais pas les autres domaines de l'ingénierie : quand il dit "Les constructions modernes utilisent juste ce qu’il faut de matières premières pour remplir leur fonction tout en étant suffisamment résistantes pour garantir la sécurité de leur ensemble sous certaines conditions." c'est qu'il n'a jamais entendu parler du "facteur de sécurité" qu'on applique en mécanique : on est tellement "confiant" dans les calculs qu'on va multiplier par 3-5 voir jusqu'à 10 quand y'a des humains en jeu, donc oui, pas mal de conceptions ont en fait 10 fois trop de matière pour garantir la résistances aux contraintes calculées (on n'est donc plus dans du 95-100% comme il le dit, mais donc seulement à 10%).

C'est simplement pas comparable. Comme tu le dis, dans les domaines d'ingénierie "hardware" la marge est d'un ordre de grandeur grand maximum. En software, à part quelques domaines de niche en embarqué ou en HPC la surutilisation des ressources c'est plusieurs ordres de grandeur. Et surtout ce n'est absolument pas une marge de sécurité volontaire : on ne rend pas le logiciel plus complexe pour le rendre plus robuste, au contraire. On le fait juste pour gagner en productivité. Enfin tu sais ça mieux que moi si tu fais du génie logiciel.

[William Vaurien]

Je pense malgré tout que peu d'entre nous seraient réellement prêts à revenir sur des soft de 1998...
Je parle d'informatique grand public pas d'emacs.
Il y a encore une très grande marge de progression, mais les logiciels sont quand même plus robustes qu'avant. OK, surtout sur Windows. Je n'ai pas vu d'écran bleu depuis des années, ni de documents offices, alors que j'ai des souvenirs douloureux d'une époque pas si lointaine d'écran bleu, de toolbars occupant la moitié de l'écran, et de rapport de stage à faire ctrl+s toute les phrases par peur du plantage. Et les pages Web avaient beau être vide, il fallait quand même des plombes pour les afficher, avec les jpeg qui s'affichaient ligne par ligne, le tout en payant une fortune et en bloquant la ligne...

Aujourd'hui l'accent est mis sur des choses auparavant futiles, comme la stabilité et l'ergonomie, même si c'est pas encore totalement acquis. J'ai l'impression que les contraintes énergétiques vont nous pousser à faire des efforts sur le côté efficient de nos applis, mais dans l'ensemble je trouve que c'est assez positif.

[Dross]

Tout est une question de mesure en fait, quel est le plus intéressant, profiter des nouvelles capacités CPU et mémoire pour sortir du logiciel plus vite et de meilleur qualité, ou au contraire rester avec des anciennes techs et avoir les même problèmes qu'on avait il y a dix ans ? C'est sûr qu'un programme .NET ou Java va être carrément plus gourmand en ressources qu'un fait en C, mais sur les deux premiers je peux faire travailler des stagiaires, avoir un cycle de dev de quelques semaines et ne pas avoir la crainte d'un plantage logiciel à cause d'un pointeur qui se serai égaré, alors que sur le dernier je ne peux pas en dire autant.

De l'autre coté j'aurai un discours diamétralement opposé si je faisais de l'embarqué avec des cycles de dev long et des specs qui ne changent pas toutes les deux semaines.

Et faire ce genre de choix justement, c'est faire de l'ingénierie.

J'ai un diplôme d'ingénieur en conception mécanique (entre autre), on fait le même genre de choix en bureau d'étude, c'est pas la meilleure pièce du meilleur fabriquant qui est toujours retenu, c'est le résultat d'une matrice de décision entre prix, délais de livraison, deadline du projet, relation avec les fournisseurs, et qualité des pièces. Et c'est pas pour rien que dans les boites de mécanique, ils ont souvent différents fournisseurs qui se situent à différents niveaux dans cette matrice. Et si t'a l'encombrement pour prendre des pièces moins chères, bah tu va le faire, comme nous en informatique : si avec le matos d'aujourd'hui on peux se permettre de prendre nos aises, on va le faire. Pourtant on pourrai faire des compresseurs hydrauliques 50% plus petits, pourtant on pourrai faire des app 50% moins lourdes, mais si tu donne le choix au client entre 100mo de moins et 3 mois de dev en plus, ou 100mo de plus et avoir l'app tout de suite, que pense tu qu'il va choisir ?

[Paradox]

Je pense que c'est un mec qui ne connais pas les autres domaines de l'ingénierie : quand il dit "Les constructions modernes utilisent juste ce qu’il faut de matières premières pour remplir leur fonction tout en étant suffisamment résistantes pour garantir la sécurité de leur ensemble sous certaines conditions." c'est qu'il n'a jamais entendu parler du "facteur de sécurité" qu'on applique en mécanique : on est tellement "confiant" dans les calculs qu'on va multiplier par 3-5 voir jusqu'à 10 quand y'a des humains en jeu, donc oui, pas mal de conceptions ont en fait 10 fois trop de matière pour garantir la résistances aux contraintes calculées (on n'est donc plus dans du 95-100% comme il le dit, mais donc seulement à 10%).

Fun fact: sauf pour les avions, si on appliquais de tels coefs on ne saurait pas les faire voler.
Donc on met des coefs dangereux, de l'ordre 1-3, mais du coup, comme on n'a pas confiance, on teste chaque pièce, on fait énormément de maintenance, et surtout, on fait des trucs de tordus comme prendre un avion en fin de ligne de montage, et tirer dessus jusqu'à ce qu'il casse, et comparer le tout aux simulations.

Je pense que tu n'as pas du tout compris ce paragraphe, ou le type essaye moins d'etre dans l'exactitude que dans le principe.

Parce qu'avant meme que tu arrives avec ton fun fact, on se doute du principe : si tu fais une aile 10 fois trop lourde ca va tomber plus que voler ; c'est pas pour rien si aucun avion n'embarque de reacteur nucleaire

- - - Mise à jour - - -

C'est simplement pas comparable. Comme tu le dis, dans les domaines d'ingénierie "hardware" la marge est d'un ordre de grandeur grand maximum. En software, à part quelques domaines de niche en embarqué ou en HPC la surutilisation des ressources c'est plusieurs ordres de grandeur. Et surtout ce n'est absolument pas une marge de sécurité volontaire : on ne rend pas le logiciel plus complexe pour le rendre plus robuste, au contraire. On le fait juste pour gagner en productivité. Enfin tu sais ça mieux que moi si tu fais du génie logiciel.

+1.

J'allais faire un edit juste pour ca.

[Dross]

Mais même dans le principe, il a une vision totalement romantique de l'ingénierie.
A part dans le domaine de l'armement et de la recherche, on est toujours dans le compromis, et le compromis actuel de laisser les apps grossir (et autre) est loin d'être une mauvaise chose si on considère les raisons derrière ça (et pas uniquement les conséquences comme il le fait).

[Paradox]

Le problème de faire de l'informatique avec des scientifiques je suppose...
Avant d'espérer un serveur, déjà toucher ma machine de travail tout court.
Pour l'instant, une vieille gloire de 10 ans retapée avec des pièces perso. Et c'était la moins pire du lot...

Donc quand je toucherai mon 8600K, je pense que je serai heureux d'y faire cohabiter CLion et Atlassian, plutôt que de voir Atlassian ramer comme un con tout seul sur l'ancienne machine.

Ben, en temps normal, justement quand tu bosses avec des chercheurs (si c'est ce que tu veux dire par "scientifiques"), tu as au moins un serveur partage meme si datant d'avant-guerre.

Et au pire, je ne sais pas ou tu travailles, mais ce n'est pas si difficile dans un contexte academique de mettre la main sur un vieux truc. Et tu n'es pas force de me croire, mais c'est une bonne pratique de separer ce genre de choses.

Apres, c'est d'une tristresse d'attendre ton 8600K (K en plus ! quel interet) pour mettre le tout dans un shaker et le lui servir le tout... J'ai tellement l'impression de revoir la mode des laptops pour tous, "parce que", malgre l'absence totale d'interet de la chose...

- - - Mise à jour - - -

Mais même dans le principe, il a une vision totalement romantique de l'ingénierie.

L'idee etant justement de donner une idee en faisant un parallele, qui meme si tu le trouves maladroit, reste juste selon mes experiences un peu partout.

A part dans le domaine de l'armement et de la recherche, on est toujours dans le compromis, et le compromis actuel de laisser les apps grossir (et autre) est loin d'être une mauvaise chose si on considère les raisons derrière ça (et pas uniquement les conséquences comme il le fait).

Pour moi c'etait l'inverse en recherche (mais c'etait un environnement special aussi).

Si, c'est vraiment une tres mauvaise chose de laisser les apps grossir. Attention, je ne dis pas qu'il faut refactorer tous les lundis, mais au lieu du paradigme du "je le referais mieux plus tard" qui ne marche (quasiment) jamais, autant pondre un code propre tout de suite. La plupart des gens pensent que c'est une perte de temps mais ca ne l'est pas.

[Dross]

Non mais là il parle de taille du binaire, pas de la qualité du code, d'ailleurs, un code bien organisé et factorisé devrait prendre théoriquement plus de place qu'un code spaghetti dans une seule classe (car tu va rajouter l'injecteur de dépendance, rajouter tout les boilerplates liés à l'archi et aux design patterns, etc), donc l'exemple n'est pas top.
De la même manière, quand tu repose sur des frameworks ou des libs, même pour en exploiter que 20%, c'est bien mieux que de recréer la roue qui en plus sera moins bien testée et de moins bonne qualité que celle supportée par des communautés de développeurs. Sauf que ça fait grossir le livrable, c'est sur, mais est-ce vraiment une mauvaise chose ?