Tu mets le check sur le CI et tu le laisse formatter à la main si ça l’amuse  

Parce que tu penses vraiment qu'on à une CI ?  

Mon collègue ne veut toujours pas mettre Prettier épisode 124 :
- On s'en fiche des espaces en trop ou du formatage, on peut le faire à la main.
- Ces outils m'ont créés des problèmes quand je les utilisais il y a 15 ans.
- Je ne vois aucun avantage.
- On s'en fiche de l'esthétisme.

Ne parlons même pas des linter.

Why are you like this

JE sais plus qui m'a recommandé qqwerty-fr, mais aprè reboot ça marche, et c'est effectivement plutôt pas mal pensé.
Le truc qui me reste encore à apprivoiser c'est la position de control et command... j'ai très envie de les intervertir, mais bon..

Pourquoi est-ce qu'il a le choix ?

- "Des modifications auto entre le moment où j'ai sauvegardé/stagé et commité, j'aime pas l'idée."

- "Des modifications auto entre le moment où j'ai sauvegardé/stagé et commité, j'aime pas l'idée."

Parce que des changements y en a tout le temps quand tu travailles à plusieurs.

Pas entre le moment où tu sauves et le moment où tu committes.

Habituellement les changements tu les synchronise explicitement.

Mais vos outils de reformatting vous sauvegardent les fichiers à posteriori ?

Perso soit je reformate au moment du save

Why are you like this

Une CI avant 2030  

Bonne fête nationale jubi et DDT !
Une petite raclette pour célébrer ? Ou une partie de chasse au frontalier avec le fusil d'assaut familial ?

Il y a des gens qui configurent ça en precommit.

Donc à ton insu, tu fais une action, ça fait des bricolages, et tu te retrouves avec dans le fichier du contenu que tu n’as pas écrit

Tu peux l’avoir configuré toi même il y a 10mn, ou bien il y a deux ans, ou bien t’as un script d’install / setup qui a fait ça pour toi sans te poser la question.

Dans tous les cas ça n’a aucun rapport avec le travail collaboratif.

C'est ça votre problème, vous dites que vous êtes l’élite mais vous avez besoin de 50 outils, de tests unitaires, de CI.  
 
Notre code fonctionne sans ça, sans bug, et sans régression. NOUS SOMMES L'ÉLITE.  

De mon expérience sans CI le code est cassé 3 fois par jour juste parce que roger a oublié de rajouter un nouveau fichier dans le repos.
« Je comprends pas ça compile sur ma machine »

Je pense que les suisses se sont plus concentré sur leur réseau de train que sur leur hymne, et c’est tout à leur honneur.

Mon collègue ne veut toujours pas mettre Prettier épisode 124 :
- On s'en fiche des espaces en trop ou du formatage, on peut le faire à la main.
- Ces outils m'ont créés des problèmes quand je les utilisais il y a 15 ans.
- Je ne vois aucun avantage.
- On s'en fiche de l'esthétisme.

Ne parlons même pas des linter.

C’est un formateur has-been pour le js oui.

On a pas de tests unitaires sur nos projets. Du coup pas besoin de CI.

save action run prettier/biome problem solved

Et quand tu fais une modif d'une ligne, le commit fait+357/-354

Je préférerais un câble
S'il sens fiche, tu peux dire un linter

Je préférerais un câble
S'il sens fiche, tu peux dire un linter

Elsabeth?

C'est l'occasion de chanter l'hymne national suisse, une merveille

En même temps l’hymne national suisse n’est pas très bien.

Dites, je cherche un frigo under counter (aucune idée en français -> c'est les frigos qui se mettent sous le plan de travail.  
 
Je cherche un energy rating A. Le nouveau système d'energy rating fait que :
 
A++ devient E
A+++ devient D
 
anéfé : https://www.kelwatt.fr/guide/conso/ [...] ique/frigo
 
Mais je ne trouve AUCUN frigo noté B ou A avec le nouveau système. Ça existe au moins ??

Dites, je cherche un frigo under counter (aucune idée en français -> c'est les frigos qui se mettent sous le plan de travail.  
 
Je cherche un energy rating A. Le nouveau système d'energy rating fait que :
 
A++ devient E
A+++ devient D
 
anéfé : https://www.kelwatt.fr/guide/conso/ [...] ique/frigo
 
Mais je ne trouve AUCUN frigo noté B ou A avec le nouveau système. Ça existe au moins ??

On a pas de tests unitaires sur nos projets. Du coup pas besoin de CI.

Mon collègue ne veut toujours pas mettre Prettier épisode 124 :
- On s'en fiche des espaces en trop ou du formatage, on peut le faire à la main.
- Ces outils m'ont créés des problèmes quand je les utilisais il y a 15 ans.
- Je ne vois aucun avantage.
- On s'en fiche de l'esthétisme.  
 
Ne parlons même pas des linter.
 

Pourquoi est-ce qu'il a le choix ?

C'est ça votre problème, vous dites que vous êtes l’élite mais vous avez besoin de 50 outils, de tests unitaires, de CI.  
 
Notre code fonctionne sans ça, sans bug, et sans régression. NOUS SOMMES L'ÉLITE.  

Rassure moi, c'est pour ton taf perso, pas chez PlamCorp ?

Y a pas un CTO pour arbitrer ces trucs de base ?

Retour de karma dans 5, 4, 3...

J'ai besoin de votre avis sur une question de design  
 
J'ai un service qui persiste un objet et son enfant :
 

class AwesomeMessage
{
    public function create()
    {
        $message = new Message();
        $message->save();
        $attachment = new Attachment();
        $attachment->message_id = $message->getKey();
        $attachment->save();
    }    
}

 
Ces deux opérations ne peuvent pas être indépendantes, on ne veut pas "Attachment" sans "Message", il faut donc wrapper l'ensemble dans une transaction.
 
Qu'est-ce qui vous semble le mieux :  
 
1) Wrapper l'appel de la méthode "create" dans une transaction à l'endroit où le service est appelé ?
2) Wrapper le coeur de la méthode "create" dans une transaction ?
 
Je suis pour 2). Quand j'appelle create() je n'ai pas à connaitre les détails de son implémentation, je ne sais donc pas forcément qu'il faut la wrapper dans une transaction.
 
Ça me semble évident que ce soit 2) mais apparemment je suis le seul ici, et je passe donc peut-être à côté de quelque chose d'évident  
 
Quand je demande une justification pour 1) je n'ai pas de réponse claire autre que "oui mais si tu appelles une méthode qui réalise une transaction qui elle même appelle une méthode qui réalise une transaction alors tu peux avoir des problèmes"

J'ai besoin de votre avis sur une question de design  
 
J'ai un service qui persiste un objet et son enfant :
 

class AwesomeMessage
{
    public function create()
    {
        $message = new Message();
        $message->save();
        $attachment = new Attachment();
        $attachment->message_id = $message->getKey();
        $attachment->save();
    }    
}

 
Ces deux opérations ne peuvent pas être indépendantes, on ne veut pas "Attachment" sans "Message", il faut donc wrapper l'ensemble dans une transaction.
 
Qu'est-ce qui vous semble le mieux :  
 
1) Wrapper l'appel de la méthode "create" dans une transaction à l'endroit où le service est appelé ?
2) Wrapper le coeur de la méthode "create" dans une transaction ?
 
Je suis pour 2). Quand j'appelle create() je n'ai pas à connaitre les détails de son implémentation, je ne sais donc pas forcément qu'il faut la wrapper dans une transaction.
 
Ça me semble évident que ce soit 2) mais apparemment je suis le seul ici, et je passe donc peut-être à côté de quelque chose d'évident  
 
Quand je demande une justification pour 1) je n'ai pas de réponse claire autre que "oui mais si tu appelles une méthode qui réalise une transaction qui elle même appelle une méthode qui réalise une transaction alors tu peux avoir des problèmes"

Je vois des frigos de table (encastrable 89cm) en A/B, mais ils sont pas donnés.

Edit: https://home.liebherr.com/en/gbr/pr [...] -3950.html

J'ai besoin de votre avis sur une question de design

J'ai un service qui persiste un objet et son enfant :

class AwesomeMessage
{
    public function create()
    {
        $message = new Message();
        $message->save();
        $attachment = new Attachment();
        $attachment->message_id = $message->getKey();
        $attachment->save();
    }    
}

Ces deux opérations ne peuvent pas être indépendantes, on ne veut pas "Attachment" sans "Message", il faut donc wrapper l'ensemble dans une transaction.

Qu'est-ce qui vous semble le mieux :

1) Wrapper l'appel de la méthode "create" dans une transaction à l'endroit où le service est appelé ?
2) Wrapper le coeur de la méthode "create" dans une transaction ?

Je suis pour 2). Quand j'appelle create() je n'ai pas à connaitre les détails de son implémentation, je ne sais donc pas forcément qu'il faut la wrapper dans une transaction.

Ça me semble évident que ce soit 2) mais apparemment je suis le seul ici, et je passe donc peut-être à côté de quelque chose d'évident

Quand je demande une justification pour 1) je n'ai pas de réponse claire autre que "oui mais si tu appelles une méthode qui réalise une transaction qui elle même appelle une méthode qui réalise une transaction alors tu peux avoir des problèmes"