Messages de Alpachinois69
Il y a pas grand chose d'intéressant. Pas d'évolutions possibles = je me casse 
. Faut mieux partir et essayer de monter ailleurs. L'autre solution = rupture co + freelance .
J'ai un dossier suppra chargé sur le dirlo donc voilà quoi.
Le 16 avril 2021 à 19:10:15 :
Le 16 avril 2021 à 13:44:09 :
Entretien RH fait avec vepee, bordel la RH est une 8/10 ukrainienne à l'accent ultra sexyhttps://image.noelshack.com/fichiers/2018/10/1/1520256134-risitasue2.png .Bon elle a dit qu'elle allait check avec un lead dev pour savoir si ça serait possible car j'ai jamais bossé avec Kubernetees donc elle veut voir si c'est éliminatoire
Mais sinon elle a dit que mon profil pourrait convenir à un poste de dev senior normalement qu'ils ont aussi ouvert. Le dev sénior aura donc un salaire < lead dev
tu accordes trop d'importance à l'aspect "lead".
Sur le papier c'est joli, dans la réalité beaucoup fuient ce poste (dans mon ancienne équipe, y'avait un tech lead de 7-8 ans d'xp... et tous les autres dev on avait 10-20 ans d'xp et on était d'ailleurs tous d'anciens tech lead). A la fin il m'a avoué que pour sa prochaine mission il préfère faire dev senior
Après en vrai ça dépend surtout de l'équipe. Dans une équipe de dev de 10+ ans d'xp un lead ça n'a pas trop de sens. Dans une équipe de jeunes de 2-3 ans d'xp, mettre un lead avec 10 ans d'xp ça peut valoir le coup
Comme je te l'ai dit en MP, j'osef des libellé de poste c'est du bullshit total pour moi 
. L'important est la paie que ça te rapporte et l'expérience que tu peux refourguer plus tard sur le CV. Dans les faits, dans ma boite actuelle une dirlo est en fait une secrétaire ++ et le dirlo de mon service est placardisé et passe ses journées à faire du helpdesk .
Entretien RH fait avec vepee, bordel la RH est une 8/10 ukrainienne à l'accent ultra sexy
Bon elle a dit qu'elle allait check avec un lead dev pour savoir si ça serait possible car j'ai jamais bossé avec Kubernetees donc elle veut voir si c'est éliminatoire 
Mais sinon elle a dit que mon profil pourrait convenir à un poste de dev senior normalement qu'ils ont aussi ouvert. Le dev sénior aura donc un salaire < lead dev 
Entretien mardi avec la RH et me dirlo branleur. Soit ça va se fight et donc j'ai déjà un dossier complet pour descendre le dirlo soit on me fait une proplale pour me sucer la bite pour rester 
.
En attendant entretien cet après-midi pour un poste lead dev avec vente privé et mardi matin chez un autre éditeur.
T'as oublié des importantes comme rebase ou merge
Sinon je viens d'avoir la RH. En gros c'était pour demander petit à petit du comment ça va jusqu'à ouais je souhaite une rupture conventionnelle .
Bon en amenant vers ça, en gros elle a fait un résumé à la direction et on revient vers moi fin cette semaine ou début next week. D'après ce qu'elle me dit, j'ai été entendu. J'ai dit : "T'es sûre? Car c'est quand même hardcore ce que j'ai dit " Elle m'a dit :"T'inquiètes pas, il y a des choses importantes qu'il faut dire et il faut les dire. Ce que toi tu as dit était vraiment intéressante et juste."
Du coup je reporte à la semaine prochaine pour ma demande de rupture .
Autumn falls, Anri okita, Maria Ozawa, lahaie jeune.
J'hésite
Toujours aucun retour RH depuis une semaine.
C'est décidé, demain après-midi j'appelle la RH pour demander une rupture conventionnelle.
Le 13 avril 2021 à 14:33:29 :
Mon rapport a l'esclavagisme est extreme
J'ai bien compris l'exemple des deux branches; ici la branche master représente le produit stable (+ ou -) avec les fonctionnalités désirées (et donc avec les branches mergées).
Donc, quand je travaille sur une feature, je crée une branche, je bosse dessus, je valide dessus, et je la merge au master quand j'ai envie de l'intégrer.Ca me parait encore lourd mais je vais lire le tuto de BinaryTree pour essaye de m'habituer
EDIT: Oh et dans mon cas, les "features"/modifications du code sont souvent tres petites. C'est toujours intéressant de passer par cette configuration ?
Le principe de git c'est de commit en masse. Genre tu codes 15 min et tu commit
Le 13 avril 2021 à 13:28:30 :
Le 13 avril 2021 à 13:11:23 :
Le 13 avril 2021 à 12:47:37 :
Le 13 avril 2021 à 12:19:08 :
Le 13 avril 2021 à 12:13:33 :
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?Le 13 avril 2021 à 12:52:28 :
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?
Je m'en sers seulement pour faire des "backups"/archivage de mon code (je suis en doctorat).Le truc c'est que j'ai peur de jouer avec les fonctionnalités plus poussées du genre faire du development sur plusieurs branches (Le code est utilisé sur deux terminaux qui développent des choses en parallele).
Ah et aussi, comment vous faites pour bien comprendre la structure du GIT de votre code ?
J'utilise seulement git log pour consulter l'historique de mes commits, et j'aurais aimé avoir une architecture en arbre littéralement. Je sais pas j'ai l'impression que je rate quelque chose..Pour ceux qui bossent en entreprise, a quel point on vous force a utiliser un gestionnaire de version (meme autre que git) ?
Déjà, je te conseille de faire toutes opérations GIT via ligne de commande et que tu comprennes ce qui se passe derrière.
On va dire que de base, tu travailles sur une branche "master" , "main" , ça dépends de ton environnement de travail et le rapport à l'esclavagisme.
Sur cette branche , tu vas opérer divers commandes : push, pull, fetch, commit, add, remote
Tu as ton environnement local et tu peux pousser aussi sur un site pour avoir un environnement globalisé avec une équipe par exemple (GitHub , Azure Devops, BitBucket, GitLab). Souvent sur ces sites, tu trouveras la représentation en arbre que tu cherches.
Possible de le faire en local ou via un logiciel mais je m'en sers rarement pour être franc.Pour les branches.
Imaginons, tu bosses sur "master". Un collègue te rejoins et vous décidez de mettre en place une "branch policy".
En gros résumé, vous ne développez plus sur master. Vous créez des branches pour vos features à coup de :
git branch 'features/order
git checkout features/orderLa tu pourrais croire que c'est de la branlette mental pour pas grand chose. L'interet est pour le CI/CD de mettre en place différentes stratégies en fonction de tes branches. (très bref comme résumé , voir Git flow si tu veux un exemple).
Après un certains temps, tu finis ton dev et tu décides qu'il serait de prendre ton code et le remettre sur la branche "master".
En fonction de ton environnement de travail : Pull request, merge, rebase
Dans tous les cas, ta Pull Request finira par un merge ou un rebase, c'est bien aussi de comprendre la différence entre ces deux concepts car ça change pas mal de chose dans ton historique de commit.En ce qui concerne les conflits, ça dépends de la taille de ton entreprise. Perso, on est une équipe de trois et c'est le dernier qui tire qui va se taper les conflits. Si il a besoin d'aide car il est pas sur du code ou quoi , bha on règle ça ensemble.
Ensuite pour GIT , a quel point j'utilise ça en entreprise ?
Tous les jours pour pouvoir travailler avec mes collaborateurs.
Je peux faire les commandes de base et par moment je me retrouve à faire des choses plus compliqués.
Liste de différentes choses qu'il m'arrive de faire :
Cherry pick
Stash
Reset
Grep
SubmoduleJe travaille déja en ligne de commande, je demandais l'interface graphique au cas ou ca pouvait s'avérer utile
Ahah je m'étais déja fait la reflexion de la branlette mentale bien vu !
Je vais aller me ré-enseigner sur les branches et le processus de PR, j'en ai jamais fait moi meme et c'est justement ce que j'aimrais apprendre. Dans mon cas: je développe des fonctionnalités différentes a deux endroits différents, et je pense qu'organiser ces deux activités en branches peut etre utile..
En tout cas merci de ta réponse bien détailléeJe conseille pour un débutant de passer en ligne de commande mais l'interface est quand même bien pratique et je l'utilise aussi. Un mix des deux outils est souvent le mieux.
Les branches c'est plutôt simple d'utilisation.
Par exemple dans ton cas on pourrait dire que tu as trois branches :
master - features/uno - features/duoTu fais évoluer uno et duo puis a un moment donné, tu vas merge sur master. Tu vas te retrouver dans master avec les changements de uno et duo.
Puis pour une raison X , master doit être figer (plus aucun changement dessus). Tu tires une nouvelle branches , tu prépares ta release suivante. Tu merges sur master quand le package est mature.
Et c'est presque tout le temps la même mécanique. Le nom de la branche n'a pas ou peu d'importance et tu peux merge dans tous les sens aussi sans soucis.
Si tu veux t'amuser, tu fais un repo git avec un fichier texte. Tu ajoutes une ligne dans le fichier , tu push.
Tu crées une branche, tu rajoutes une ligne dans le fichier. Tu rechanges de branche et tu regardes l'état du fichier.
Tu merges la branche avec le changement vers la branche sans changement, tu refais un changement dans la branche avec tout dedans et tu repousses dans l'autre branche.Un peu confus mais l'idée est là
https://image.noelshack.com/fichiers/2016/42/1476947003-risitas-lunettes-main.png
Ce mécanisme marche dans tous les gestionnaires de source style SVN
Le principal avantage de Git est de pouvoir faire des commit locaux avant de balancer ça au serveur Git est décentralisé
Le 13 avril 2021 à 13:11:23 :
Le 13 avril 2021 à 12:47:37 :
Le 13 avril 2021 à 12:19:08 :
Le 13 avril 2021 à 12:13:33 :
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?
Je m'en sers seulement pour faire des "backups"/archivage de mon code (je suis en doctorat).Le truc c'est que j'ai peur de jouer avec les fonctionnalités plus poussées du genre faire du development sur plusieurs branches (Le code est utilisé sur deux terminaux qui développent des choses en parallele).
Ah et aussi, comment vous faites pour bien comprendre la structure du GIT de votre code ?
J'utilise seulement git log pour consulter l'historique de mes commits, et j'aurais aimé avoir une architecture en arbre littéralement. Je sais pas j'ai l'impression que je rate quelque chose..Pour ceux qui bossent en entreprise, a quel point on vous force a utiliser un gestionnaire de version (meme autre que git) ?
Pour la gestion d'une structure en arbre, t'as des outils payant style GitKraken. Faut trouver une même genre d'alternative gratose
Pour les gestionnaires de versionning. On a un TFS qui fait tourner les anciens projets surtout le plus gros qui a 15 ans d'existance et totalement impossible de migrer dans Git tellement il est chaud
Après perso j'utilise pas des trucs trop compliqué, je push je pull, je merge, etc. Bref, je fais la même chose sur Git que sur SVN ou TFS c'est juste que sur le CV faut mettre le mot Git à juste titre, ça reste bien supérieur à SVN ou TFS si tu utilises bcp de fonctionnalités mais la plupart des gens font la même chose qu'avant je pense.
Tiens je connaissais pas TFS !
Merci de ton avis, le truc c'est que moi je commit, je push, je pull et a priori c'est tout.
Quand je lis des gens qui bossent sur plusieurs branches et qui doivent merger (on voit ca sur les repo git aussi d'ailleurs), je vois ca comme un bordel incommensurable dans le sens ou ca doit demander énormément d'énergie de merger deux modifications, meme différentes, a partir du moment ou il y a des conflits. D'ailleurs, meme si il n'y a pas de conflit a priori ca peut changer le comportement de l'application..L'avantage de Git par rapport à TFS ou SVN je pense est la rapidité du truc car calqué sur le répertoire. Genre t'ajoutes un fichier dans le répertoire X, git détecte direct le changement ce qui n'est pas le cas sur TFS. Vu que le comportement est chelou, il faut faire bcp plus gaffe sur TFS ou SVN que sur Git
Enfin les branches bouffent moins de place que sur SVN ou TFS où là si tu veux créer une branche pour tester un truc, faut download TOUTES les sources de la branche mère. Bref, ça peut être long si t'as une grosse application monolithique de 2 Go de codes source comme celle que je gère parfois
Excuse moi de te poser la question mais, quel est donc l'intéret de TFS ?
Non je comprends que c'est un choix que la boite a fait il y a longtemps et que la migration est trop difficile..Le 13 avril 2021 à 12:52:28 :
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?
Je m'en sers seulement pour faire des "backups"/archivage de mon code (je suis en doctorat).Le truc c'est que j'ai peur de jouer avec les fonctionnalités plus poussées du genre faire du development sur plusieurs branches (Le code est utilisé sur deux terminaux qui développent des choses en parallele).
Ah et aussi, comment vous faites pour bien comprendre la structure du GIT de votre code ?
J'utilise seulement git log pour consulter l'historique de mes commits, et j'aurais aimé avoir une architecture en arbre littéralement. Je sais pas j'ai l'impression que je rate quelque chose..Pour ceux qui bossent en entreprise, a quel point on vous force a utiliser un gestionnaire de version (meme autre que git) ?
Déjà, je te conseille de faire toutes opérations GIT via ligne de commande et que tu comprennes ce qui se passe derrière.
On va dire que de base, tu travailles sur une branche "master" , "main" , ça dépends de ton environnement de travail et le rapport à l'esclavagisme.
Sur cette branche , tu vas opérer divers commandes : push, pull, fetch, commit, add, remote
Tu as ton environnement local et tu peux pousser aussi sur un site pour avoir un environnement globalisé avec une équipe par exemple (GitHub , Azure Devops, BitBucket, GitLab). Souvent sur ces sites, tu trouveras la représentation en arbre que tu cherches.
Possible de le faire en local ou via un logiciel mais je m'en sers rarement pour être franc.Pour les branches.
Imaginons, tu bosses sur "master". Un collègue te rejoins et vous décidez de mettre en place une "branch policy".
En gros résumé, vous ne développez plus sur master. Vous créez des branches pour vos features à coup de :
git branch 'features/order
git checkout features/orderLa tu pourrais croire que c'est de la branlette mental pour pas grand chose. L'interet est pour le CI/CD de mettre en place différentes stratégies en fonction de tes branches. (très bref comme résumé , voir Git flow si tu veux un exemple).
Après un certains temps, tu finis ton dev et tu décides qu'il serait de prendre ton code et le remettre sur la branche "master".
En fonction de ton environnement de travail : Pull request, merge, rebase
Dans tous les cas, ta Pull Request finira par un merge ou un rebase, c'est bien aussi de comprendre la différence entre ces deux concepts car ça change pas mal de chose dans ton historique de commit.En ce qui concerne les conflits, ça dépends de la taille de ton entreprise. Perso, on est une équipe de trois et c'est le dernier qui tire qui va se taper les conflits. Si il a besoin d'aide car il est pas sur du code ou quoi , bha on règle ça ensemble.
Ensuite pour GIT , a quel point j'utilise ça en entreprise ?
Tous les jours pour pouvoir travailler avec mes collaborateurs.
Je peux faire les commandes de base et par moment je me retrouve à faire des choses plus compliqués.
Liste de différentes choses qu'il m'arrive de faire :
Cherry pick
Stash
Reset
Grep
SubmoduleJe travaille déja en ligne de commande, je demandais l'interface graphique au cas ou ca pouvait s'avérer utile
Ahah je m'étais déja fait la reflexion de la branlette mentale bien vu !
Je vais aller me ré-enseigner sur les branches et le processus de PR, j'en ai jamais fait moi meme et c'est justement ce que j'aimrais apprendre. Dans mon cas: je développe des fonctionnalités différentes a deux endroits différents, et je pense qu'organiser ces deux activités en branches peut etre utile..
En tout cas merci de ta réponse bien détaillée
En 2021 plus grand chose pour TFS hein. C'est juste qu'à l'époque Git n'existait pas (2005) . Ce projet a tellement été codé avec le cul (le mec qui l'a codé est un ancien BEP électrotechnique reconverti en dev mais franchement ça va c'est pas ce que j'ai vu de pire) et qu'il est tellement gros et fait tourner quasi la boite en gros. Donc le migrer sur Git je veux bien mais c'est facile 6 mois de projet là . L'objectif est de faire une refonte des logiciels pour ne plus l'utiliser. Ce qui n'est évidemment pas le cas car la moitié des dév sont encore fait dessus mais comme le dirlo est un branlos qui pige rien, il continue à ordonner de la merde .
En gros j'ai réussi à faire de mon côté en souterrain la seul application qui fait quasiment bosser 10% de la boite sans passer par le gros legacy. Bref, ça fait 2 ans qu'ils essaient de sortir un gros logiciel pour ne plus dépendre du passif mais tjr pas de démo
Le 13 avril 2021 à 12:19:08 :
Le 13 avril 2021 à 12:13:33 :
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?
Je m'en sers seulement pour faire des "backups"/archivage de mon code (je suis en doctorat).Le truc c'est que j'ai peur de jouer avec les fonctionnalités plus poussées du genre faire du development sur plusieurs branches (Le code est utilisé sur deux terminaux qui développent des choses en parallele).
Ah et aussi, comment vous faites pour bien comprendre la structure du GIT de votre code ?
J'utilise seulement git log pour consulter l'historique de mes commits, et j'aurais aimé avoir une architecture en arbre littéralement. Je sais pas j'ai l'impression que je rate quelque chose..Pour ceux qui bossent en entreprise, a quel point on vous force a utiliser un gestionnaire de version (meme autre que git) ?
Pour la gestion d'une structure en arbre, t'as des outils payant style GitKraken. Faut trouver une même genre d'alternative gratose
Pour les gestionnaires de versionning. On a un TFS qui fait tourner les anciens projets surtout le plus gros qui a 15 ans d'existance et totalement impossible de migrer dans Git tellement il est chaud
Après perso j'utilise pas des trucs trop compliqué, je push je pull, je merge, etc. Bref, je fais la même chose sur Git que sur SVN ou TFS c'est juste que sur le CV faut mettre le mot Git à juste titre, ça reste bien supérieur à SVN ou TFS si tu utilises bcp de fonctionnalités mais la plupart des gens font la même chose qu'avant je pense.
Tiens je connaissais pas TFS !
Merci de ton avis, le truc c'est que moi je commit, je push, je pull et a priori c'est tout.
Quand je lis des gens qui bossent sur plusieurs branches et qui doivent merger (on voit ca sur les repo git aussi d'ailleurs), je vois ca comme un bordel incommensurable dans le sens ou ca doit demander énormément d'énergie de merger deux modifications, meme différentes, a partir du moment ou il y a des conflits. D'ailleurs, meme si il n'y a pas de conflit a priori ca peut changer le comportement de l'application..
L'avantage de Git par rapport à TFS ou SVN je pense est la rapidité du truc car calqué sur le répertoire. Genre t'ajoutes un fichier dans le répertoire X, git détecte direct le changement ce qui n'est pas le cas sur TFS. Vu que le comportement est chelou, il faut faire bcp plus gaffe sur TFS ou SVN que sur Git Moi ben du coup ça ma permis vraiment de prendre l'habitude de faire gaffe sur les merges et la gestion des conflits avant de commit
Enfin les branches bouffent moins de place que sur SVN ou TFS où là si tu veux créer une branche pour tester un truc, faut dedownload TOUTES les sources de la branche mère. Bref, ça peut être long si t'as une grosse application monolithique de 2 Go de codes source comme celle que je gère parfois
Le 13 avril 2021 à 12:00:52 :
Vous auriez un tuto sur GIT pour une utilisation relativement poussée ?
Je m'en sers seulement pour faire des "backups"/archivage de mon code (je suis en doctorat).Le truc c'est que j'ai peur de jouer avec les fonctionnalités plus poussées du genre faire du development sur plusieurs branches (Le code est utilisé sur deux terminaux qui développent des choses en parallele).
Ah et aussi, comment vous faites pour bien comprendre la structure du GIT de votre code ?
J'utilise seulement git log pour consulter l'historique de mes commits, et j'aurais aimé avoir une architecture en arbre littéralement. Je sais pas j'ai l'impression que je rate quelque chose..Pour ceux qui bossent en entreprise, a quel point on vous force a utiliser un gestionnaire de version (meme autre que git) ?
Pour la gestion d'une structure en arbre, t'as des outils payant style GitKraken. Faut trouver une même genre d'alternative gratose
Pour les gestionnaires de versionning. On a un TFS qui fait tourner les anciens projets surtout le plus gros qui a 15 ans d'existance et totalement impossible de migrer dans Git tellement il est chaud
Après perso j'utilise pas des trucs trop compliqué, je push je pull, je merge, etc. Bref, je fais la même chose sur Git que sur SVN ou TFS c'est juste que sur le CV faut mettre le mot Git à juste titre, ça reste bien supérieur à SVN ou TFS si tu utilises bcp de fonctionnalités mais la plupart des gens font la même chose qu'avant je pense.