Reprise du message précédent :
Oui, les Epson "ecotank". Ca permet de baisser le rapport poids des cartouches/prix, mais ça reste un coût à la page bien plus élevé que les lasers.
 
Edit : clairement, aujourd'hui, pour de l'impression occasionnelle, une petite laser n&b est le choix le plus raisonnable et économique. Bon par contre, vaut mieux attendre pour acheter ce genre d'imprimante parce que depuis le confinement, tous les prix ont fait x2 L'équivalent de mon imprimante est à presque 80€ alors qu'il y a 4 ans, elle valait 40€.

Il y a que chez moi que le certificat de forum-images.hardware.fr est subitement considéré non secure par l'antivirus du taf?
Le forum est moins pratique à utiliser comme ça...

 
Ici, il y a plus aucune image dans le forum et le style est tout cassay.

Nan idem chez moi, il suffit d'ouvir la page du forum-images et de forcer la sécurité et hop ça retourne à la normal

 
Ah oui. Bien joued

idem

pas totalement, hein ... mais c'est mieux que rien

https://www.youtube.com/watch?v=5eivFReQAxk
c'est con mais j'adore

on parlait d'UT i ln'y a pas longtemps, : https://www.dealabs.com/bons-plans/ [...] am-1893237
moins de 2€ le pack complet

"Complexity of coding a PR is *proportional to the number of changes."
"Complexity of reviewing a PR is exponential to the number of changes."
 
discuss.

Pour les fans de cafés, quel moulin à café avez-vous ?

J'avais repéré le Baratza Encore que tout le monde recommande, mais 140€
Puis pas sûr d'avoir besoin des 256 réglages

Sinon une Krups GX5000 mais ça m'a l'air introuvable.

En ce moment il y a une bonne promotion sur le Bodum, c’est peut-être le meilleur plan

J'ai un Knock car je voulais passer au manuel et il est vraiment top pour le prix (mais ils ont un peu augmenté apparemment).

Cherche un Baratza (ou autre, par exemple un Grinta) d'occase?

Je pense que c'est globalement vrai, mais qu'on peut mettre en place de mesures d'atténuation. Ce qui change tout c'est de comprendre le contexte. C'est effectivement plus que proportionnel quand on doit comprendre comment tout interagit ensemble, mais une description bien ficelée peut expliquer tout ça correctement et rendre la revue de l'ensemble naturelle. Les tests aussi permettent de comprendre vite où l'auteur veut en venir (c'est jamais aussi parlant qu'un texte bien écrit).

J'ai un encore dont je suis content, mais au final vu la quantité de café que je consomme j'aurais probablement pu prendre un moulin manuel de bonne qualité.

Pas que ça aurait nécessairement été moins cher, notes. Mais il y a des morceaux du encore qui sont un peu chiant à nettoyer (genre sortir le "stator" de sa fixation plastique).

Le bistro c'est ce que j'avais précédemment (un modèle plus vieux quel le tien je pense, genre ça mais en blanc) et c'était pas mal mais un peu bof, les problèmes d'électricités statiques cités dans le lien étaient très présents et le plastique un peu souple était super salissant et grisait avec la poussière qui collait dessus. Et le réceptacle en verre était fragile, je pense que j'ai fini par le pêter.

 
J'ai un Hario manuel tout bête : https://www.maxicoffee.com/moulin-m [...] -2873.html

D'où l'intérêt de découper les PR.

mais j'ai un gros doute sur ça en vrai.

C'est plus une sigmoide imo, y'a un plafond ( souvent très bas ) où le reviewer n'aura ni le temps, ni l'envie de se plonger suffisamment dans le code: il oubliera des trucs qu'il regarde habituellement, il zappera des hunks, il testera rien ...  
 
A l'opposé, il y a aussi les très rares cas où parce que c'est gros, le mec sera super vigilant et cassera les couilles pour rien et souvent ça fini soit en truc qui ne sera jamais mergé, soit en une découpe plus ou moins hasardeuse suivi d'une série de LGTM tout aussi foireux. La série de commits qui compile qu'en un seul chunk niquera toutes tes chances de faire un bisect dans le futur ... mais t'auras fait des petites PRs donc tout le monde il est beau  
 
Bref, je m'emmerde plus: je fais des PRs les plus petites possibles dès le début pour éviter tout un tas d'emmerdes

mais le coût d'administration de chaque PR, tout le monde s'en fout ?

Je le constate régulièrement, donc je peux confirmer. (bon là c'est évidemment exagéré).

Personne n'a envie de prendre le temps de review une PR de 2000 lignes.

Souvent ça fait fini par *scroll* *scroll* *scroll* OK ça semble bon.

et ? c'est moins bien que d'ergoter sur chaque underscore ?
 
Je pense pas que qui que ce soit ait envie de review 200PRs de 10 lignes non plus.

Ben c'est clairement plus facile qu'une PR de 2000 lignes, non? C'est quoi ce coût d'administration dont tu parles ?

 
 
Je ne parle pas d'ergoter sur des underscore. Je parle de commencer à faire ta review correctement mais de finir par bâcler arrivé au quart parce que t'en as marre.
 
Des PR plus petites seront mieux reviewed (et surtout reviewed tout court), c'est tout.
 
Alors je ne veux pas faire de mon cas une généralité, mais je ne ne suis pas le seul à le penser. On est 7 dev dans l'équipe, et on est 7 à être d'accord sur ce point. Pour moi c'est une évidence.
 
S'il y a 200 PR de 10 lignes comme tu dis... tu vas pas avoir peur d'ouvrir une PR et tu vas la review rapidement. Éventuellement tu vas en faire une 2ème, puis une 3ème. Là t'en as marre, tu arrêtes...
 
Mais en attendant ça fait déjà 3 PR reviewed.
 
Une grosse PR, tu vas l'ouvrir... voir l'énorme liste de fichiers modifiés, la scroll bar à droite qui fait 2mm... d'avance t'as pas envie. D'avance tu sais que ça va te prendre 1000 ans.

toutes les PR vont avoir un retour pendant que tu es sur autre chose, il va falloir rouvrir les VMs associées, les remettre en configuration de test, remettre le code en état (la compil prend 10min), ergoter pour chaque PR s'il faut mettre une entrée dans le changelog, se planter en comittant un des fichiers sur lesquels on bossait (peut pas stasher des console.log()), reverser, se re-planter en comittant dans la mauvaise branche.
 
Et des rebase/merge, des dizaines de rebase/merge à haut risque.

 
création de la PR: c'est un one-click + auto-populated avec tes commit messages qui doivent de toute façon être bien écrits.
tests: excellente raison d'en automatiser un maximum et de foutre tout ça en CI / pre-commit checks
"discussion" des reviews: Avoir énormément de PRs et un coût d'aller retour élevé ( je bosse avec des équipes distribuées US / EMEA / APAC donc ça peut être très long ) force aussi à arrêter de se battre sur tout ce qui est style et co: tu mets des auto-formatteur de partout ( gofmt, rustfmt, prettier, ... ). Si les gens trouvent un truc qui leur va pas, ils sont invités à modifier les configs des fmt-ers ou fixer ces problèmes upstream, mais ce sera après avoir approuvé la PR qu'ils trouvaient stylistiquement à chier.
déploiement: CD => osef c'est automatisé. Si c'est batché dans des grosse releases => osef aussi, c'est pas moi qui prépare les releases mais à part pour générer des changelogs, c'est souvent complètement indépendant du nombre de PRs.

Ah ok je comprends. C'est compliqué si tu es pressé, mais si tu t'occupes séquentiellement de toutes les PR en partant de la première ça demande pas d'effort particulier (je comprends pas ce que tu entends par config de test, les tests sont fait par les outils automatiques en général ?). Faut avoir autre chose à faire en attendant bien sûr. Mais bon, la vitesse de mise en prod c'est rarement un argument entendable de toutes façons.

Ils n'ont aucun sens tes exemples...

Si pour chacune de tes "mini PR" t'es obligé de lancer des VM différentes, il est peu probable qu'elles soient directement liées... Et donc je ne vois pas comment l'ensemble de leurs commits auraient pu se retrouver dans une seule et unique PR

J’ai soit des scripts perso qui tournent que chez moi, soit des tests manuels, on a pas de tests auto qui touchent les serveurs chez plamcorps, personne n’a encore soulevé la montagne. Mais un collège a déjà mis un coup de pioche en regardant ipxe, et c’est déjà un enfer.

el comandante c40

 
comment ça arriverait ça ?
 
si t'as mettons A->B->C* et que t'as submit A et que ça revient avec des commentaires :  
- tu sauves tes changements en court dans C (tu pourras toujours amend plus tard)
- tu checkout A, fait les modifs, commit. Tu as A'
- tu rebases B sur A' (ou tu evolves)
 
j'admets que si ton C était clean, ça arrive d'oublier de checkout A, mais meme là y'a des commandes (avec hg tu peux faire hg prev --merge, je sais pas si il y a un équivalent git)
 
après de ce que j'entends vous vous battez pas mal pour des virgules et des underscore. Investissez dans un linter. Ici on a un linter intégriste, mais il a toujours le dernier mot, et surtout seule son opinion compte. et surtout tu peux le lancer avant de commit, et donc corriger tes conneries avant.

Vraiment cher par rapport à un Knock Feld* qui me semble mieux construit.
Tu peux quasiment acheter un Kinu à ce prix.

Mais pour être honnête, je suis septique sur la revue de code profonde en général, j’ai eu des problèmes assez en surface de trouvé en revue (oublié d’incrémenter des versions de module, le plus souvent), mais jamais de bug profonds.

me planter ça m'est arrivé avec des fichiers neufs.
Là sur ma tâche principale en cours, y'a du code qui doit pas partir en open source, c'est pour ça que j'ai laissé les console.log() pour l'instant (ça aussi ça va être une aventure, il va partir dans le projet closed source de kenshi, mais par copier-coller).
 
y'a un linter, mais y'a aussi toujours des remarques sur le code style.

c'est un cadeau, je l'ai pas choisi ... effectivement, y'a mieux en rapport q/p
mais j'en suis très satisfait.

Ah oui dans ce cas.
Faudrait que je trouve des potes qui m'offrent des moulins à 250 balles.
Voire une Rocket à 2000.

Mais du coup tu gagnerais pas a avoir 2 vranches, une avec ton code commun et l'autre avec ton code spécifique open source ?
Sinon pour le linter, ici il référence les titres du style guide. Et c'est rare qu'on te fasse chier pour qqc si c'est conforme au style guide. Du coup je serais tenté de dire :
- soit c'est une opinion fondée et du coup ça devrait amender le style guide et la conf du linter
- soit c'est une opinion fonctionnelle (on bite rien a ton nom de variable, etc...)
- soit en gros c'est une opinion, et pis ben voilà quoi (ici on a un moyen de répondre "Ack", et Héphaestos m'a expliqué que ça veut dire "ok, je prend note,ais je changerai rien" et tu peux submit quand même

De ce fait j'ai plutôt une bonne expérience des code reviews, parce que c'est jamais picky pour dire d'être picky. Et y'a un gros référentiel commun de ce qui est acceptable ou pas, donc les revues portent hyper rarement sur le style

J'en ai pas

Et le café moulu, c'est vraiment moins bon ?

J'bois pas de café.

Ouais.
 
Le café perd principalement (huiles, aromatiques, …) par oxidation, à partir du moment où le café est torréfié la perte commence, mais le café moulu a exponentiellement plus de surface que le café en grain, et la perte correspond (et plus la mouture est fine plus la perte est rapide).
 
Une un paquet scellé ou une atmosphère protectrice aide un peu (une fois que tout l'oxygène dedans qui a commis son meurtre aromatique), s'pour ça que les capsules peuvent tenir un peu mieux que le café moulu en vrac, mais tu veux surtout retarded la mouture au possible.

Ou alors tu mouds, et tu scelles en portion individuelle étanches

oui