Reprise du message précédent :

Certainement. Tout ce que je souligne c'est que ça ne devrait pas être là qu'il y a la moindre ambiguïté. Tout le monde sait comment il faut faire, pourtant on utilise un outil qui fournit 36 façons de faire différemment.

Tiens sinon je vous ai pas raconté : hier soir, une connaissance aide-soignante (en psychiatrie, mais aide-soignante quand même) :
"Je vais me faire vacciner, bien obligée si je veux continuer à bosser, alors j'arrête d'allaiter mon bébé".
Je m'étonne, ah bon l'allaitement est contre-indiqué avec le vaccin ?
"Non mais je préfères faire gaffe, après tout les anticorps passent dans le lait alors ceux du vaccin aussi"
J'ai pas trouvé les mots pour répondre, je crois que c'est mieux comme ça.

Cette pandémie aura eu le mérite de faire une belle purge au niveau des "soignants" (ceux qui ont quitté le métier à cause de la "dictature" ).

T'es pas obligé de faire du git flow non plus

Je répondais à un commentaire spécifique  

A mon avis peu importe le flow choisi, il y en a aucun qui préconise de faire des commits en double
Le problème de fond c'est de pas même pas se poser la question si c'est perturbant ou non pour le reste de l'équipe, si ça s'inscrire dans un effort de cohésion.

C'est un peu comme un type qui double par la droite sur l'autoroute quoi.
Il en a rien à foutre, personne n'a a lui expliquer comment il faut conduire, et d'ailleurs il n'y a pas de problème.

Un langage de programmation c'est un outil qui permet de faire quelque chose de 150 façons, pourtant on sait par expérience et par bon sens, que certaines façon de faire son à proscrire.
On sait aussi qu'il faut se mettre d'accord dans l'équipe sur certaines façon de faire, certaines conventions, faire du code review.

GIT c'est pareil, en fait, tu peux remettre en cause une façon de faire, appliquer des best practices, faire du nommage intelligent, du nommage bête.

A la fin on parle des défauts ou avantage de git mais le problème de fond c'est plus comment réussir à bosser avec certaines personnes, et pourquoi parfois ça semble incroyablement compliqué.

Concernant les SCM alternatifs, j'ai déjà du utiliser Rational Team Concert, dont le principe c'est les changesets qui sont un peu comme des commits ouverts, auxquels ont attache des fichiers, sauf qu'on ne peut pas attacher le même fichiers dans deux changesets différents qui sont ouverts.

Résultat, en voulant éviter le concept de branches et de merges, on se retrouve avec des erreurs comme du code d'une fonctionnalité embarqué par erreur dans le changeset d'une autre fonctionnalité.

Avec git tu as une branche par fonctionnalité, donc tes fonctionnalités sont étanches, mais il faut faire des merges ou des rebases.

Personnellement je préfère git, car tu peux switcher sans encombre entre un blem de prod et un dev, sans nécéssairement avoir plusieurs IDEs ouverts.

Quelque part GIT vs RTC, c'est la souplesse de l'opensource vs la rigidité du propriétaire

Certes, mais c'est le plus connus, et c'est nécéssaire d'avoir une sorte de convention quand on a autant de turnover parmis les équipes de dev.
Mais si tu veux faire autrement, alors dans ce cas tu proposes une solution, tu fais pas ta petite bricole dans ton coin, tu communiques, tu proposes.

Quand j'ai commencé je pense que je m'en branlais de pas mal de trucs, les tests unitaires je savais même pas ce que c'était, les tests ça me faisait chier.
Et petit à petit j'ai réalisé que faire des tests unitaires permettait de me faire chier encore moins, et que pour en arriver à cette tranquilité il fallait faire quelques efforts en amont, et je pense que GIT fait partie de ces efforts en amont qui valent le coup pour ensuite ne pas être dans le rush à cause de conneries.

 
Deux remarques.
 
Déjà il faut arrêter avec la notion de "bon sens", c'est pas un bon concept : il ne s'apprend pas, il ne se transmet pas, il est mal défini, bref c'est inutilisable.
 
 
Ensuite un langage de programmation et git n'ont pas la même portée en termes d'usages, un langage est plus souple dans son utilisation parce qu'il permet d'exprimer virtuellement n'importe quel programme possible, alors que git bah ça fait de la gestion de version distribuée qui est un espace de problèmes à résoudre beaucoup plus restreint. Et j'ajoute que tous les langages ne se valent pas en termes de multiples façons de faire les choses. Certains ont une syntaxe moins ambiguë, avec moins d'alternatives et moins de confusion possible. C'est pas pour rien le motto de Perl "there's more that one way to do it" est critiqué depuis des décennies et que le langage est volontiers décrit comme "write-only".
 
Quand on est sur un outil comme git, on peut restreindre volontairement les possibilités, mais c'est pas forcément venu à l'esprit de gens qui étaient déjà pas foutus de nommer leur concept de façon cohérente (alors ce truc des fois on l'appelle "staging area" puis des fois "index", il a fallu attendre 2019 pour qu'ils percutent que donner plein de sens différents à la commande "checkout" était débile, etc)

// the weird "n" value is to avoid calling .Next on a possibly deleted edge
    for e, n := edge, edge.Next; e.IsHorizontal(); e, n = n, n.Next {
        tFace := e.Twin.Face.Name
        if eFace == tFace {
            // islands are not implemented, so weird cuts are expected and left alone
            continue
        }
        //snip
    }

quand tu fais de la topologie, mais pas trop

https://www.tresor.economie.gouv.fr [...] t-l-argent

Ça ne te choque pas de devoir faire face au même genre de complexité quand tu écris un programme que quand tu utilises un logiciel de gestion de versions ?

Ce n'est pas une fatalité ; tu l'acceptes parce que tu as toujours fait comme ça et qu'aujourd'hui on n'a en pratique pas vraiment le choix. Mais d'autres outils n'ont pas ce défaut.

Y a bientôt 10 ans, dans une ancienne boîte, quand on est passé de Subversion à Git une équipe d'une vingtaine de devs, on a constaté la difficulté à l'époque de prise en main simple.
Du coup on avait développé une surcouche en CLI en interne (dont vous pouvez voir la doc ici : https://blog.ratibus.net/pflow/). Ça avait tellement simplifié la prise en main Et pourtant on avait d'excellents devs.
Je m'en sers encore à titre perso
 
Vu qu'on voulait pas héberger le code sur Github, on avait même développé notre propre interface de code review : http://crew-cr.github.io/Crew/
Utilisé visiblement un moment chez Blablacar : https://twitter.com/mikaelrandy/sta [...] 8403090432

// the weird "n" value is to avoid calling .Next on a possibly deleted edge
    for e, n := edge, edge.Next; e.IsHorizontal(); e, n = n, n.Next {
        tFace := e.Twin.Face.Name
        if eFace == tFace {
            // islands are not implemented, so weird cuts are expected and left alone
            continue
        }
        //snip
    }

Ouin ouin ils demandent de savoir traverser un graphe à l'entretien d'embauche mais personne ne fait jamais ça dans ce métier !

le pire c'est que comme je détecte pas les iles, j'ai aucune vraie traversée du graphe

Dans les bouchons grenoblois...

'faut utiliser un vélo

Ca a changé le remote

Jour 1 quelque papier, recup de l'ordinateur, coucou aux gens

Je voulais tester si ça le faisait en voiture. Et en fait c'est la misère

Tu crèches où ?

Lolmacon

je crois que je vais être obligé de changer de taf.
 
https://g5-digital.com/

Ah bah oui 400 bornes pour avoir un ordi et récupérer des papiers  

Shinuza aurai pu me gérer l'envoi.

@flo: je sais pas si tu as vu tous les messages de bienvenue. Je crois qu’on t’as ajouté un peu tard dans le channel.

Il faut comprendre, une petite startup ne peut pas avoir la souplesse et l'agilité d'une COGIP luxembourgeoise    
 

La 7ème compagnie

Tu aurais pu envoyer gatsu en trotinette, en 20 minutes c'était plié...

Coucou les loulous, allez c'est lundi, on se remet au travail
 
Petite question du jour :
J'ai un service web (site php), à destination d'utilisateurs enregistrés.  
En utilisant le service les utilisateurs déposent du contenu qui aboutit en bdd mysql + fichiers.
 
J'aimerai permettre à ces utilisateurs d'avoir une sauvegarde de leurs données pour qu'ils puissent récupérer des informations par exemple de l'heure précédente, du jour précédent, semaine...
 
Jusqu'à présent j'avais fait un espèce de backup (plutôt pensé pour le cas d'un crash du serveur principal) via un mysqldump/restore + rsync pour les fichiers, sur un autre serveur, j'avais rendu le tout accessible via un sous domaine genre backup.monsite.com
 
Ca tourne toutes les heures depuis des années et ça marche plutôt bien.
 
Après ça ne répond pas au problème pour les utilisateurs dans le sens où s'ils effacent par erreur du contenu à 9h55 et qu'ils s'en rendent compte à 10h05 ben c'est trop tard le "backup" a "ratrapé son retard" à 10h00 et donc désormais montre la version avec les données effacées.
 
Question : vous feriez comment pour permettre une granularité plus fine et un historique plus pertinent ?
 
Mon idée première c'est de "dupliquer" ce même système (mysqldump/rsync) mais de rajouter sur le serveur de backup des tâches pour décaler les sauvegarde (renommage de bdd, de dossier) pour que par exemple h-1 devienne h-2. Que chaque jour j-1 devienne j-2
Mais j'ai l'impression que ça va être un bon gros bordel, que tout le monde va se marcher sur les pieds (genre à 10h00 la tâche qui pousse la sauvegarde du serveur de prod vers celui de backup, selon le temps qu'elle prend elle risque de se retrouver directement propulsée en h-2)...
 
Il reste aussi la manière de proposer ça "visuellement" à mes utilisateurs. Pour l'instant j'imagine dans l'interface de l'appli une liste déroulante où on choisit la temporalité de la sauvegarde qu'on veut consulter (h-1, h-2, j-1...) et en validant ça renvoie vers un domaine genre backupj-1.monsite.com par exemple) mais c'est peut-être inutilement compliqué.
 
Bref, vous feriez comment ?

Tiens on parlait de google drive il y a peu ; vous savez si on peut récupérer le client windows sans l'installer qui nécessite les droits d'admin ? A chaque fois je suis obligé d'installer le client dans une VM pour pouvoir recopier les fichiers sur mon PC du boulot, c'est lourd

Toi aussi  

1h10 ce matin, le kiff  

 
Oui c'est vrai que le plaisir de rencontrer physiquement quelqu'un qui n'est pas si loin que ça (par rapport à ceux à l'étranger ou à Tours ou Rouen et bientôt Toulouse), qui va manger avec nous à midi c'est terrible   On a du le menacer pour qu'il vienne, chez nous le télétravail ça existe pas    
 

 
1h de mon côté

 
 
Surtout que je suis venu la première semaine. Enfin c'est normal quoi.

 
C'est Dion

C'est bien, excite toi sur la partie qui n'est pas dans le message
 

Comme si on faisait venir uniquement pour un PC ou des papiers Mais bonne tentative de troll, comme d'habitude. T'es vraiment un gros con en ligne

Si vous le faites venir pour le "rencontrer physiquement", personnellement je trouve ça pire

Il faut que tu te relaxes, moins stressé tu aurais probablement remarqué qu'il s'agissait uniquement de chambrer flonuméro et ses trajets en mazoutière plutôt que l'agilité (le recours à un terme bullshit bingo était peut être un signe) de vos processus administratifs.
Alors qu'on sait tous que ce gros pince veut se faire payer le restau (probablement un restaurant ethnique comme nray, ils ne doivent pas avoir ça à macon)
 

Le drama du jour sur proton est délicieux
 
https://old.reddit.com/r/ProtonMail [...] l/hbqha63/
Mais vous respectez la loi ?    

Dans la SSII de ma copine (ils sont que 2000 sur la France ) je viens d'apprendre que les devs payaient leur license Intellij s'ils en voulaient une.  

Plusieurs personnes ici avaient l’air de trouver ça acceptable  

Bah là y'a un dev qui vient de lui expliquer que Webstorm c'est mieux que Vscode car il ferme une div sans plugin, alors du coup c'est worth de le payer soi-même.