Je sais plus qui cherchait du python pour son gosse (g5 ?) mais : https://korben.info/twilioquest.html
 
Vous pouvez cliquer sur ce site de boomer, c'est safe.

 
Et bien je suis pas d'accord. Moi j'aime la gamification et je trouve que l'un n'empêche pas l'autre. Si tu aimes pas un truc, c'est pas avec la gamification que tu vas l'aimer et inversement.
Perso j'apprends le Piano avec Flowkey et même si c'est pas de la gamification, ça me conviens bien comme système et c'est pas une méthode d'apprentissage standard. Mon but n'est pas de devenir Mozart, juste de jouer les morceaux que j'aime, même si c'est du par coeur.
 
Ca peut être la même chose avec le dev. A moins d'en faire ton métier, c'est pas avec de la gamification sur UN truc que tu finis dev.
Je préfère apprendre un langage avec un rendu type jeu, ou codingame qu'en lisant un pavé dans un livre.

C'est quand même très connu Korben dans le monde de l'informatique  

je suis d'accord avec ça, ma question c'est si c'est 7h du matin, et que tu veux faire rapidement 2 cafés, un lungo un peu rond, et un ristretto un peu plus corsé, tu fais comment si t'as qu'un moulin, sans passer du temps à le nettoyer et à le sécher ?

Le café étant une poudre, il doit en rester pas mal dans le moulin quand t'as fini de moudre

sans parler du fait que tu dois aussi sortir les grains non utilisés

 
Moi je suis un vieux con. Je déteste la "gamification". La prog c'est super fun, mais c'est après avoir bossé. On ne peut pas y échapper. C'est comme la musique, c'est fun, mais tu ne joueras jamais correctement d'un instrument en t'amusant. C'est un mensonge. Le pire, c'est que la "gamification", c'est en gros ce qu'on m'a seriné à tous les étages quand j'ai passé mon DE pour être prof de musique (en conservatoire).  
Si un ado veut faire de la prog, on peut l'aider, mais ça doit avant tout l'intéresser à fond. Il doit être passionné par ça.
 
Ma fille, la musique, j'ai tenté de lui apprendre le piano, et j'ai vite vu que cela la faisait chier XXL. Là, elle fait de la prog, mais ça vient d'elle à 100% et c'est elle qui me fait chier tous les jours pour en faire. Quand tu as un enfant ou un ado qui est décidé à faire quelque chose, tout ce que tu as à faire c'est de l'accompagner, tu as pas besoin d'un jeu à la con pour l'intéresser.

 
C'est surtout connu pour être un bon site de merde, bourré de pub et contenu sponso avec des news que même Muchacho trouverait ça old.
 
Je précisais juste que pour une fois ça allait.

Oui, pareil que Kenshineuh, apprendre en s'amusant, je trouve que c'est la meilleure façon d'apprendre, quel que soit l'âge. On mémorise bien mieux et plus vite quand on s'amuse. Pour apprendre le dév à des enfants, code.org ou Leekwars, c'est très bien, je trouve.
Après, s'il veut en faire son métier, là, effectivement, il va devoir faire des études et donc apprendre la théorie. C'est clair que si tu commences à apprendre des notions comme la complexité des algos à un enfant, il va vite lâcher l'affaire  
Mais même la théorie, tu peux l'apprendre de manière ludique. Dans mon école d'ingé, l'un des projets de fin d'étude de 2 potes, c'était de faire des couses de fourmis qui mettaient en scènes algorithmes d'ordonnancement classique (simplex, Johnson, voyageur du commerce, plus court chemin...). Aux journées portes ouvertes, ça avait son petit succès.
 
Autre exemple d'apprentissage en s'amusant, les premières décimales du nombre PI : https://www.youtube.com/watch?v=Ts0ItJHZB4Y

 
 thé

 
   café au lait.

 
 
Ricoré à la rigueur.

C'est probablement du lipton yellow

Ok, y'a pas mal de pub mais faut bien vivre.
Après, franchement, c'est pas mal quand tu cherches un outil un peu original ou spécifiques à certains besoins. Moi, je m'en sers pour faire un peu de veille techno. Après, c'est vrai que ces dernières années, j'y vais moins qu'avant.

C'est probablement du lipton yellow

Ta femme se met au long black

 
Ce qui dérange, ce n'est pas le "jeu" pour apprendre en soi, mais la disparition de la culture de l'effort, particulièrement à l'école.

Tu exagères largement mon propos mais je comprends ce que tu veux dire. Je pense que la culture de l'effort est nécessaire quelque soit le domaine et je trouve que sur le plan pédagogique, on ne fait plus que de la "gamification" justement, y compris à l'école et avec ensuite toutes les lacunes atroces que l'on constate.

<harko>Ta femme se met au long black et si elle est pas contente targe dans sa gueule</harko>

Un bon moulin il va en rester très peu, et tu sauras pas le sortir sauf à  démonter ton moulin en entier à chaque fois (ce que tu fais pas).

Ya pas de grain pas utilisé noob Chez toi tu prépares la dose exacte en entrée en fonction du ratio désiré, tu le fais pas en sortie.

Aucun moulin n'est fait pour ressortir des grains par le haut, par contre beaucoup de moulins modernes non-pro ont de tout petit "paniers" haut (le Niche Zero tient 55g de café en grains), plus tu montes en gamme moins il y a de place pour laisser des grains pas moulus dans le moulin jusqu'au moment où tu passes au semi-pro où tu fais le café en grandes quantités où tu vas avoir des trucs comme la pesée de la mouture en sortie.
 

non c'était au bureau

je suis d'accord avec ça, ma question c'est si c'est 7h du matin, et que tu veux faire rapidement 2 cafés, un lungo un peu rond, et un ristretto un peu plus corsé, tu fais comment si t'as qu'un moulin, sans passer du temps à le nettoyer et à le sécher ? Le café étant une poudre, il doit en rester pas mal dans le moulin quand t'as fini de moudre, sans parler du fait que tu dois aussi sortir les grains non utilisés (ou garder de la mouture non utilisée, ce qui est chaud si tu veux pas qu'elle s'oxide)
Ma question porte précisément sur ce changemetn rapide de café, je me doute bien qu'avec bon moulin tu peux moudre n'importe quel café

Ouais mais genre, dans un espace dédié manipulé par un pro, pas en accès libre, rassures moi?
Parce que entre:

- La mouture pas adaptée
- Les bourrins du tamper
- Les manips pas faites correctement
- La maintenance

J'imagine même pas la catastrophe  

Je hais MongoDB (d'ailleurs on le vire de notre appli cette année, on est en train de translater les requêtes mongo en requêtes xquery ces mois-ci...).
On avait une requête qui prenait 15mn en dev, en preprod, elle était pas finie au bout de 3j...
On a pas mal cherché, au final, on est revenu aux performances de la bécane de dev.
La cause du pb :

 
A+,

Moi j'aime pas le café  

 
Team thé ou café au lait.
 
Ricoré à la rigueur.

Ouais mais genre, dans un espace dédié manipulé par un pro, pas en accès libre, rassures moi?
Parce que entre:
 
- La mouture pas adaptée
- Les bourrins du tamper
- Les manips pas faites correctement
- La maintenance
 
J'imagine même pas la catastrophe    
 

 
Tiens justement, j'ai toujours cru que je détestais le thé. Et une fois que j'en ai gouté du "vrai" (en tout cas pas lipton), j'ai clairement changé d'avis.  

mais du coup est-ce que c'est viable de changer les grains entre 2 cafés ?

les modèles que j'ai utilisé y'a une grosse cuve en verre pleine de grains, tu amènes la tete en dessous, tu appuies sur un bouton pour moudre exactement la quantité que tu veux, et elle est belle.
Problème : ça ne marche que si tu fais 50 cafés de suite avec les mêmes grains (case in point, on avait 3 moulins, 1 pour des grains "strong", un pour des grains "mild" et un pour des grains "decaf" )

et du coup sur les modèles grand public, comment est-ce que tu changes les grains ?

Lê de la chaîne youtube Science4all vient de publier une excellente vidéo sur l'explication vraiment technique du fonctionnement du vaccin à ARNm : https://www.youtube.com/watch?v=LITxersG52U
 
En fait, ça marche comme un patch d'un binaire    
Son code source mais environ 1 Ko si on code les lettres A, C, G, U en binaire. Et la covid, son code source, c'est environ 29 Ko.  

Moi j'aime pas le café  

https://www.tiktok.com/@natidreddd    
 
la voix de cette fille, et son accent      
(J'avais une collègue écossaise qui avait un accent très similaire, elle pouvait parler de n'importe quoi je pouvais l'écouter des heures)

 
Tu exagères largement mon propos mais je comprends ce que tu veux dire. Je pense que la culture de l'effort est nécessaire quelque soit le domaine et je trouve que sur le plan pédagogique, on ne fait plus que de la "gamification" justement, y compris à l'école et avec ensuite toutes les lacunes atroces que l'on constate.

Tu n'aimes pas le caflaie ?

Comme accent anglais, je recommande le scouse, c'est au moins aussi déroutant que le scottish english...
https://www.youtube.com/watch?v=sWAUrHODRWM
A+,

Comme accent anglais, je recommande le scouse, c'est au moins aussi déroutant que le scottish english...
https://www.youtube.com/watch?v=sWAUrHODRWM
A+,

Moi j'aime pas le café  

C'est surtout connu pour être un bon site de merde, bourré de pub et contenu sponso avec des news que même Muchacho trouverait ça old.
 
Je précisais juste que pour une fois ça allait.

Dites les gens, en Scrum, pour l'évaluation des tâches, il y a 2 possibilités, l'effort théorique, et le nombre de jours que la tâche va prendre.
Autant le nombre de jours est quelque chose de concret et se base sur l'expérience de l'effort de la tâche et de la durée de toutes les sous-tâches nécessaires pour la réaliser, autant l'effort théorique ne tient pas compte de tous les problèmes techniques que l'on rencontre en pratique, n'est-ce pas ? Dans ce cas, il ne peut donner lieu à un planning précis, il ne sert qu'à évaluer la complexité de la tâche elle-même. Sinon comment fait-on ?

jours/hommes  

Pour avoir essayé les deux (les jours/hommes et les points de complexité), y a pas de méthode magique. Sur les points de complexité, une fois que tu as de l'historique, tu peux en théorie transformer ça en "date de release", avec une idée de la vélocité de ton équipe.
Mais une fois qu'on a dit ça, on se plante déjà. Si on commence à confondre "estimation", avec "quand ce sera fini", c'est déjà un premier piège.
Toute estimation comporte une part d'incertitude, plus ou moins grande. Le problème étant que des features complexes sont souvent la sommes de plusieurs sous tâches, chacune avec son niveau d'incertitude... Et l'accumulation de ces incertitudes rend très très compliqué le fait d'avoir des dates fiables. Tu peux comme Harko le faire artificiellement rajouter N points à chaque fois, mais au final en faisant ça tu ne fais que compenser le biais d'optimisme des devs et si ça marche pour 80% des devs "standards", il est très probable que t'ais une partie des devs ou les 2 points ajoutés ne suffisent pas.
 
Rien que le terme "estimation" est foireux: "j'estime que cette pièce fait 20m2" => je fais une approximation à la louche d'un truc qui a une vraie réalité "physique". Et il est d'ailleurs assez facile de comparer la qualité de l'estimation/approximation avec ladite réalité.
Pour moi ce qu'on nous demande de faire avec les "estims" (que ce soit en poker planning ou autre), c'est plus une prédiction, comme en météo en fait (les modèles scientifiques en moins): on nous demande de prévoir le futur, comment ça va se passer. Et forcément c'est compliqué et pas une science exacte. Si ton management accepte pas ça...
 
Après je comprend bien que coté business on veuille avoir des dates de release, mais pour moi c'est justement le principe essentiel des méthodes agiles normalement: la flexibilité et revoir, toutes les semaines, tous les 15 jours le projet, et ajuster son scope, son budget et son délai pour prendre en compte ces incertitudes et ce qu'on apprend au fur et à mesure de l'avancée du projet. C'est SpaceX avec les SN1-9 et pas le SLS. Et surement pas Scrum et ses myriades de codification/rituels/process
 

putain
https://monetendoir.fr/etendoir-jar [...] etail.html

GPD Win 3 commandée

putain
https://monetendoir.fr/etendoir-jar [...] etail.html

Pour avoir essayé les deux (les jours/hommes et les points de complexité), y a pas de méthode magique. Sur les points de complexité, une fois que tu as de l'historique, tu peux en théorie transformer ça en "date de release", avec une idée de la vélocité de ton équipe.
Mais une fois qu'on a dit ça, on se plante déjà. Si on commence à confondre "estimation", avec "quand ce sera fini", c'est déjà un premier piège.
Toute estimation comporte une part d'incertitude, plus ou moins grande. Le problème étant que des features complexes sont souvent la sommes de plusieurs sous tâches, chacune avec son niveau d'incertitude... Et l'accumulation de ces incertitudes rend très très compliqué le fait d'avoir des dates fiables. Tu peux comme Harko le faire artificiellement rajouter N points à chaque fois, mais au final en faisant ça tu ne fais que compenser le biais d'optimisme des devs et si ça marche pour 80% des devs "standards", il est très probable que t'ais une partie des devs ou les 2 points ajoutés ne suffisent pas.
 
Rien que le terme "estimation" est foireux: "j'estime que cette pièce fait 20m2" => je fais une approximation à la louche d'un truc qui a une vraie réalité "physique". Et il est d'ailleurs assez facile de comparer la qualité de l'estimation/approximation avec ladite réalité.
Pour moi ce qu'on nous demande de faire avec les "estims" (que ce soit en poker planning ou autre), c'est plus une prédiction, comme en météo en fait (les modèles scientifiques en moins): on nous demande de prévoir le futur, comment ça va se passer. Et forcément c'est compliqué et pas une science exacte. Si ton management accepte pas ça...
 
Après je comprend bien que coté business on veuille avoir des dates de release, mais pour moi c'est justement le principe essentiel des méthodes agiles normalement: la flexibilité et revoir, toutes les semaines, tous les 15 jours le projet, et ajuster son scope, son budget et son délai pour prendre en compte ces incertitudes et ce qu'on apprend au fur et à mesure de l'avancée du projet. C'est SpaceX avec les SN1-9 et pas le SLS. Et surement pas Scrum et ses myriades de codification/rituels/process