1. On nonsense and science

    The modern scientific education is associated to rigor ; it extols the power of reason over feelings. Rising above other mere mortals, the scientist has a grand vision of what he should accomplish, and sets himself to work, wielding an impressive array of mathematical tools. In contrast, the poet seems to err without a definite goal, writing words after words in some everlasting quest for beauty.

    James Clerk Maxwell.png
    By George J. Stodart - Frontpiece in James Maxwell, The Scientific Papers of James Clerk Maxwell. Ed: W. D. Niven. New York: Dover, 1890., Public Domain, Link

    I’m no poet. I’m more of a scientist by training. As such, I have a great admiration for James Clerk Maxwell. To defeat the stereotypes, he was an outstanding physicists who wrote poetry. His poems are little known gems. I recently found this one, entitled “Molecular Evolution”.

    Molecular Evolution, by J.C. Maxwell

    At quite uncertain times and places,
    The atoms left their heavenly path,
    And by fortuitous embraces,
    Engendered all that being hath.
    And though they seem to cling together,
    And form “associations” here,
    Yet, soon or late, they burst their tether,
    And through the depths of space career.

    So we who sat, oppressed with science,
    As British asses, wise and grave,
    Are now transformed to wild Red Lions,
    As round our prey we ramp and rave.
    Thus, by a swift metamorphosis,
    Wisdom turns wit, and science joke,
    Nonsense is incense to our noses,
    For when Red Lions speak, they smoke.

    Hail, Nonsense! dry nurse of Red Lions,
    From thee the wise their wisdom learn,
    From thee they cull those truths of science,
    Which into thee again they turn.
    What combinations of ideas,
    Nonsense alone can wisely form!
    What sage has half the power that she has,
    To take the towers of Truth by storm?

    Yield, then, ye rules of rigid reason!
    Dissolve, thou too, too solid sense!
    Melt into nonsense for a season,
    Then in some nobler form condense.
    Soon, all too soon, the chilly morning,
    This flow of soul will crystallize,
    Then those who Nonsense now are scorning,
    May learn, too late, where wisdom lies.

    Now, that’s a piece of philosophy of science. It got me thinking.

    Randomness in science

    This poem deals with the exploration/exploitation tradeoff and the necessity of having a fair share of exploration in science. Which means that you may have to walk on paths forbidden by reason. Of course, reason shouldn’t be entirely forgotten: for nonsense to crystallize into some nobler form, one needs to discern the emerging patterns in the outburst of ideas. Indeed, what Maxwell say is to try random combinations of ideas. Take the risk to be ridiculed. Get creative.

    Interestingly, this is also the conclusion of a 2015 paper from the British Journal for the Philosophy of Science, entitled Conservatism and the Scientific State of Nature, in which the authors conclude:

    …that governments and foundations should reverse the general trend and intervene to encourage risky science beyond what would occur without their intervention.

    The authors modeled the scientists as bandits: a scientist can chose to work on the project that looks the most promising or to experiment with new, radical alternatives. It turns out that if all scientists have the same incentive to choose the safe path, it is detrimental to the progress of science, which involves following crazy ideas.

    Las Vegas slot machines.jpg
    By Yamaguchi先生, CC BY-SA 3.0, Link

    A big question in Philosophy of Science is the demarcation between what is science and what is not. What are bandits, and how the demarcation question can be reinterpreted within a bandits framework is an interesting topic. I’ll try to write more about it in a sequel to this post. Meanwhile, I just want you to remember that randomness is good, because it allows exploration.

    Quoting the same paper:

    The history of science is filled with stories of the crazy idea that turned out to be right.

    Let’s follow Maxwell the poet, and fill History of Science with more nonsense.


  2. About Peopleware

    The book Peopleware by Tom DeMarco and Timothy Lister is a popular book on software project management. The first edition was from 1987 but the book has been revised in 2013. Peopleware addresses the issue of software developers management.

    This article is a short-list of what I take away from the book. The book is really easy to read and full of interesting insights, I recommend it to anyone working in software projects — even if you’re not into management.

    The authors note that a lot of software projects fail, and that in their experience, most of the time the failure is “people-related”. The main thesis is stated in the first chapter and reads:

    The major problems of our work are not so much technological as sociological in nature.

    The book is divided into 5 parts, but I think we can extract 2 main ideas:

    1. Productivity in a software project is quite different than in a physical product assembly line (eg Cheeseburger production),
    2. You will have better productivity by actually showing respect for and trust in your people.

    The authors explain the first point to support the second, and then expand on the multiple facets of what makes software developers work better.

    Productivity reassessed

    Software development is a work of the mind. It requires abstract thinking and creativity. On the opposite, making a Cheeseburger requires no novelty, and production can be standardized.

    When you replace a developer, you find a person with a different experience each time. Turnover is more costly than you think. On the contrary, a Cheeseburger maker is quite interchangeable.

    When developing software, quality matters a lot, because software is evolving and must be maintained. You can’t trade-off quality for productivity.

    What’s not so easy is keeping in mind an inconvenient truth like this one:

    People under time pressure don’t work better — they just work faster.

    In order to work faster, they may have to sacrifice the quality of the product and of their own work experience.

    How to care for software developers

    If you want to know all about it, go read the book. Here I will keep 5 points that I found particularly interesting, considering my short experience of software development.

    Respect their work

    • Allow, even encourage errors: they will feel more free to try new things and will learn in the process.
    • People’s self-esteem is tied to the quality of the work they produce: strive for quality.
    • Be open to change.
    • Create an atmosphere of safety, remove competition inside a team.
    • Avoid unnecessary dress codes, Methodologies, and bureaucracy, which make people feel that their appearance, or a Method (with a big M), or the politically-correct, is more important than their actual work.

    Chris Lema selected that last point as one of the Three Reasons Why High Performers Quit:

    Proper procedure is more valuable than high performance.

    Respect their time

    • Sometimes a developer has to stop coding and think. That’s OK.
    • Avoid useless meetings, etc.
    • Avoid impossible deadlines: your developers also want the work done, they’ll do it even without a deadline.
    • Be aware that working more is not being more productive. Respect your people’s work/personal life balance.

    Your people are very aware of the one short life that each person is allotted. And they know too well that there has got to be something more important than the silly job they’re working on.

    Let them work in peace

    The main idea is that building software involves building abstract ideas. The developer is then in a fragile state of flow.

    • Give them a nice, quiet place to think.
    • Don’t let them be interrupted in their work at any time (including with your own visits). Be mindful of the effect of meetings, telephone, emails, etc.

    The authors actually devote a full part of the book to the workspace. This is reinforced by Joel Spolsky, for instance in 2000 with Where do These People Get Their (Unoriginal) Ideas? and in 2006 with A Field Guide to Developers.

    Help them make progress

    • Trust people: let them be autonomous after you’ve entrusted them with your job.
    • Use deadlines so they see the work progresses in the right direction.
    • Grow teams: when people inside the team feel safe, with no competition, they’ll naturally coach each other and share knowledge.
    • Facilitate learning.

    Reward

    • Make people feel involved.
    • Make them see the work progressing with small part goals.
    • Use tests for private self-assessment.
    • Avoid creating competition through bonuses tied to performance.

    Conclusion

    The authors tell some stories and give supporting data to make their point. I think they might go a bit too far at times, for instance when they insist on making the workplace a community: some people may like it, but some may not. In any case, I believe I would work better in the environment they detail along the pages.

    If you’re still not convinced whether you should read the book, there’s a more classic review here, and thousands of reviews on goodreads.

    Please share your comments or relevant articles on Reddit. I’d like to write a follow-up article with some practical examples, eg a company/project failure or success due to a specific sociological factor.


  3. Andrew Ng about Deep Learning at Paris ML Meetup

    The last Paris Machine Learning meetup #12, hosted at Google Paris, was actually held Europe wide, together with London, Berlin and Zurich ML meetups. Andrew Ng was the guest star, available from San Francisco through Hangout. You can watch the video of the entire meetup, which is available on YouTube, but make yourself comfortable because it’s almost 3h30 long. Here I will only write about Andrew Ng’s talk and the first set of questions he was asked, that is only a bit more than half-an-hour.

    Talk summary

    Andrew Ng talked about deep learning, a subject on which he’s been involved a lot with his teams, and which he describes as “our best shot at progress towards real AI”.

    In the traditional learning framework, there are 3 steps:

    • take an input,
    • design & extract features,
    • feed a learning algorithm.

    The idea behind deep learning is driven by the “one learning algorithm” hypothesis, i.e. the idea that there must be somehow an algorithm that could learn to process almost any type of data. Our brain is capable of very impressive rewiring to reuse areas of the cortex for different kinds of learning, when a sensor is disconnected. There must be something in common in the way our brain learns to process the different channels.

    A way to implement that is with representation learning, that is try to learn the features. Andrew Ng described how sparse coding is a useful way to learn features, not only for images, but also applicable to audio. And you can repeat this to build feature hierarchies.

    After observing that this kind of system worked ever better when increasing the number of features, the idea was to scale up, really. He started working on neural networks with millions of parameters, with the Google Brain project. They made it scale up to 1 billion parameters, and famously made the neural network watch YouTube for a week. It learnt the concepts of faces & cats. They were able to ship new products with the same technology.

    The next question was: how to make it more easily available, i.e. without needing the huge Google infrastucture ? In a word: use GPUs.

    For future work, Andrew Ng explained that deep learning has been used in practical application mostly with supervised learning — to exploit the large amount of available labeled data accompanying the digitization of our society. It is an interesting feature of deep learning algorithms that it keeps getting better and better with more data. He pointed to the fact that there’s been an underinvestment on unsupervised learning. The obvious reason is that it is hard. However, this is probably nearer to how we learn. He gave the example of how we teach a child to recognize a car: you won’t point to him tens of thousands of cars, however loving a parent you are! A few labeled examples are enough. Most of the learning is unsupervised.

    About his own future work, Andrew Ng explained that, after Coursera, he wants to spend more time working on machine learning, GPUs and AI, which is what he’ll be doing at Baidu.

    Questions

    Andrew Ng then proceeded to answer the questions asked on Google moderator.

    1. “Could you give your top 3 most promising topics in machine learning ?” The first answer was, “unsupervised learning”. Then, about supervised learning, he mentioned the importance of giving tools and making infrastructures easily available to teams, and then listed “speech recognition” and “language embedding”.

    2. “Your introductory course to ML at coursera was really great. Will you teach an advanced ML course at coursera with latest techniques around Convolutional Neural Networks, Deep Learning etc. ?” He’s not sure how he’ll find the time to do it, but he thinks about it and wishes to do so.

    3. “How do you see the job of a Data Scientist in the future?” The increase in digital activities that create data and the rapid drop in computational cost are at the origin of the “big data” trend. As long as these two phenomena continue, the demand for data scientists will grow, and don’t worry, deep learning won’t replace them any time soon. This is an exciting discipline. Data science creates value.

    4. “What are common use-cases where re-sampling (e.g. bootstrapping) is not sufficient for estimating distributions and considering the whole (Big)Data set is a real advantage?” Large neural networks need lots of data. When you have a lot of parameters, with a lot of flexibility in the model, booststrapping doesn’t help. With high VC-dimension, it is simply better to increase the size of the data set.

    5. “What will be the next “killer application” of Deep Learning after visual object recognition and speech recognition?” Thinks that’s speech recognition. Vision & language are still to come.

    6. “How do you see the gap between the research and practical implementation of ML algorithms?” You should minimize this gap. Have researcher for the innovative ideas, but avoid steps between researchers and production implementation. The same person does the research & works with the product team.

    7. “What is it that you find most difficult in machine learning?” Innovation. Innovation requires teamwork. This entails employee development and teaching, to empower people to innovate “like crazy”.

    I’m partial to question n°7 since I’m the one who asked it. I really like his answer, now it’s no wonder why he founded Coursera.

    Take-away

    • Deep learning is not a new fad. The theory behind it is decades old, it’s the result of years of research, and it’s booming due to hardware improvements. It’s not pure chance that it works so well. And there’s still research to do to make it even better.

    • More data & more computational power make for better performance. OK. No intelligence required? It seems it’s not that obvious.

    • Keep in mind that innovation is at the core of a researcher’s work. And that is the most difficult. Choose/educate your team well. Share knowledge.

    • Yann LeCun had a different approach to introducing deep learning for his talk at ESIEE a few days before Andrew Ng. Maybe I’ll write about it later.

    Please share your thoughts about this post and the talk on Reddit.


  4. On survey bias

    How do you bias a survey to get just the result you want?

    Bias the device

    Here’s how SNCF does it. They put some kind of device in the new renovated Saint-Lazare station. The display invites passers-by to tell how much they love the new station (of course, it is beautiful, it’s brand new, full of natural light, and though we suffered a lot with years of works, it was worth the pain). You have two choices : either click on a pink button with a big heart shape (saying, I love it), or take a picture of a QR code “to explain why you don’t love it”.

    The surest way to get more than 90% approval.

    Bias the questionnaire

    But it gets better. After clicking a few times on the button (ok, maybe they handle that kind of childish behavior), I scanned the QR code. There, after waiting for long seconds, I was retargeted to a page saying “3221 people love the new station, and you?” with… a button to say “I love it”, and a smaller one to go to a new page to enter a message. All in a positive tone (help us improve!) So cute.

    I left a message saying something about statistics and fiability. For now, I have just received the standard reply, with a thank you.

    What is it good for?

    From the url linked by the QR code, I found their campaign was using MyFeelBack solutions. So there are some customer feedback professionals making this kind of survey, and there are people making money. Well, I can only hope they take into account the bias introduced in their procedure when they analyze the result. How can they do this?

    • compare the number of clicks with the number of people coming to the station everyday (or, if they have the figure, the number that can pass near the device),
    • add a new device with a random question and estimate how much people want to click on it,
    • count the number of customers from which you can expect feedback with a button vs. a QR code and a form,
    • only take the written feedback into account.

    Maybe the device is not entirely useless, after all? What do you think?


  5. Introduction à Python super-facile

    Premiers pas

    Remarque : J’ai écris ce tuto il y a très longtemps, et je ne l’ai jamais publié… mais il peut servir alors je le mets là.

    1. Installer Python

    Pour commencer, nous allons installer le minimum vital, installer uniquement des outils basiques. Nous verrons plus tard qu’il est possible d’utiliser des outils plus performants, et plus pratiques, mais pour faire ses premiers pas en programmation, c’est un peu compliqué.

    Je suppose que vous êtes sous Windows, et mes exemples utiliseront Windows 7.

    Nous allons donc commencer par installer Python : c’est bien le minimum nécessaire pour utiliser ce langage de programmation, la librairie standard, l’interpréteur. Nous allons donc pour commencer sur la page www.python.org/download/. Il y a plein de versions disponibles :

    Je vous conseille de prendre la dernière version (3.3.3 au moment où j’écris), avec un installeur MSI (pour Windows, donc) 64bits (si vous n’êtes pas sûr d’avoir une machine 64bits, prenez la version X86 tout court).

    Cliquez sur le lien, puis sur enregistrer. Exécutez l’installeur en double-cliquant sur le fichier python-3.3.3.amd64.msi.

    Windows demande confirmation avant d’éxécuter, par sécurité : on fait confiance à la Python Software Foundation, et le fichier a été téléchargé directement depuis www.python.org, donc on peut l’éxécuter en toute confiance : cliquez sur Exécuter.

    Windows demandera une seconde fois de confirmer après la configuration de l’installation. Pour l’instant, il n’y a qu’à suivre les instruction d’installations :

    • installer pour tous les utilisateurs ou non ? Choisissez seulement votre utilisateur si vous n’êtes pas sur votre propre ordinateur.

    • emplacement par défaut : c’est le répertoire où l’installeur va copier tous les fichiers nécessaires au fonctionnement de Python. Pas besoin de changer.

    • Personnalisation de l’installation : cocher en plus la seule option qui n’est pas mise par défaut, pour ajouter python.exe à votre path.

    • Puis plus rien à faire, juste attendre un peu et cliquer sur Finish.

    2. Utiliser la console Python

    Une fois Python installé, la première chose est de tester que ça fonctionne ! Aller dans le menu démarrer, chercher et cliquer sur Python (command line).

    La console Python démarre : la première ligne affiche la version de Python installée (donc ici Python 3.3.3, version 64 bits).

    Tester une première commande, selon la tradition des tutoriaux de programmation, nous allons saluer le monde (mais en français), et plus précisément le monde de Python : taper print("Bonjour, Python !").

    Bravo, vous avez installé Python avec succès ! Nous allons pouvoir passer aux choses sérieuses et apprendre à programmer !

    Pour jouer avec :

    • Remplacez les guillemets doubles par des guillemets simples : c’est pareil !
    • Ecrivez une autre phrase.
    • Essayez d’enlever les guillemets : print(Bonjour, Python !) : cela fait une erreur au niveau du point d’exclamation : SyntaxError: invalid syntax. Et si on enlève le point d’exclamation ? Une autre erreur : NameError: 'Bonjour' is not defined. On pourrait expliquer dans les détaills mais pour commencer, il faut retenir que si on ne met pas les guillemets, Python cherche à interpréter autrement les caractères que l’on écrit.
    • Essayez en commençant avec un guillemet double et en terminant avec un guillemet simple, que se passe-t-il ?
    • Essayez avec des caractères spéciaux
    • Essayez en écrivant ‘Bonjour,\nmonde’, ‘Bonjour\tmonde’ : à quoi servent ‘\n’ et ‘\t’ ?

    Pour comprendre : quelques explications.

    print est une fonction standard de Python, qui prend une chaîne de caractères et l’affiche dans la console. Une chaîne de caractères en Python est signalée par des guillemets simples (touche 4 ') ou doubles (touche 3 "). On appelle caractère tout ce qu’on utilise quand on écrit : les lettres (abcdefghijklmnop…), les chiffres (0123456789), les signes de ponctuation (,?:!;), les symboles mathématiques (+-*/), par exemple, mais il en existe beaucoup plus (%ùàç€&$…). Si vous êtes curieux, vous pouvez lire l’article de Wikipédia sur les caractères informatiques.

    La plupart du temps, on n’utilise pas un caractère tout seul, mais plutôt un mot ou une phrase. Pour dire à Python qu’on veut un mot ou une phrase, c’est-à-dire une “chaîne de caractères”, on les met ensemble entre guillemets, comme dans notre exemple : “Bonjour, Python !”. L’interpréteur Python sait alors que cette chose qu’on lui fait lire est une chaîne de caractères, et pas autre chose.

    3. Un premier script

    Pour écrire des scripts de façon très simple, il y a un éditeur qui est fourni avec l’installeur de Python : IDLE (Python GUI).

    • GUI, ça veut dire quoi ? C’est de l’anglais pour “Graphical User Interface”, en français on dit une “interface graphique”. En fait, quand on a pas d’interface graphique, ça veut dire qu’on est dans une console. Sous Windows, vous utilisez l’écrasante majorité des logiciels avec une interface graphique.

    Créez un répertoire sur votre ordinateur dans lequel vous allez mettre tous les fichiers liés à ce tutoriel (par exemple dans Mes Documents, un répertoire “IntroPython”).

    Dans la fenêtre ‘Python 3.3.3 Shell’, cliquer sur File->New File, cela ouvre une autre fenêtre dans laquelle vous allez pouvoir écrire votre premier script. Tapez : print(“Bonjour, monde !”), puis sauvegardez le fichier en sélectionnant bien votre répertoire de travail (“IntroPython”).

    Il faut maintenant exécuter le script. Pour cela, dans le menu de l’éditeur, cliquez sur ‘Run’, puis ‘Run Module’. Ou alors, encore plus simple, appuyez sur la touche F5. Voilà ce qui doit s’afficher dans la fenêtre “Shell” :

    >>> ================================ RESTART ================================
    >>> 
    Bonjour, monde !
    

    On va essayer de faire un peu mieux. Effacez la ligne déjà écrites et copiez à la place les lignes suivantes :

    print("Bonjour, comment t'appelles-tu ?")
    chaine1 = input()
    print(chaine1, ", quel joli nom !", sep='')
    

    Pour comprendre :

    print est une fonction python, jusqu’à présent on lui passait en argument juste un chaîne de caractères, mais ici, à la troisième ligne, on voit qu’on peut lui en passer plusieurs. Chaque chaîne passée est affichée, en les séparants par la chaîne indiquée par sep='', ici, une chaîne vide, donc les chaînes sont collées. input est aussi une fonction, et comme elle ne prend pas de paramètres, on l’appelle avec des parenthèses vides : input().

    chaine1 est une variable, elle permet d’enregistrer une valeur et de la réutiliser plus loin. Ici, on l’initialise avec ce que nous renvoie la fonction input, c’est-à-dire une chaîne entrée par l’utilisateur dans la console. Ensuite, on l’utilise pour afficher cette chaîne.

    4. Un premier jeu

    A partir du premier script, il est très facile de faire un quizz. Posez une question, vérifiez si la réponse est bonne, et comptez les points.

    Par exemple :

    """
    Un jeu de quizz
    Le programme pose des questions,
    l'utilisateur répond dans la console,
    le programme compare sa réponse avec la bonne réponse
    le programme ajoute 1 point par bonne réponse.
    """
    
    # On commence avec aucun point
    points = 0
    
    # Question 1
    # Affiche la question
    print("1. Quelle est la capitale de la France ?")
    # Récupère la réponse entrée par l'utilisateur dans une variable appelée capitale
    capitale = input()
    # Compare la réponse de l'utilisateur avec la bonne réponse, "Paris"
    if capitale == "Paris":
        # Donne un point si la réponse est bonne
        points = points + 1
        print("Bravo, bonne réponse !")
    else:
        print("Erreur ! La bonne réponse est : Paris.")
    
    if points > 1:
        print("Score :", points, "points")
    else:
        print("Score :", points, "point")
    

    Pour comprendre

    On apprend plusieurs choses avec ce tout petit bout de programme.

    • En Python, il y a deux façons de faire des commentaires dans son code :
      • pour faire un commentaire sur plusieurs lignes, on utilise des triples guillemets """ pour indiquer le début et la fin d’un commentaire,
      • pour faire un commentaire sur une seule ligne, il suffit de commencer la ligne par le symbole dièse : # (touches Alt Gr + 3).
    • On utilise deux variables :
      • une variable pour stocker la réponse donnée par l’utilisateur. Ici, on l’appelle capitale. On aurait pu l’appeler reponse1. Ce qui est important, c’est de donner un nom qui permet de comprendre à quoi sert cette variable. Comme on y met une chaine de caractères (la réponse de l’utilisateur entrée dans la console), cette variable est de type “chaîne”.
      • une variable pour stocker le nombre de points accumulés par le joueur, autrement dit, son score. Au départ, c’est zéro, et on l’augmente de 1 point à chaque fois qu’il répond bien. Les scores possibles sont donc 0, 1, 2, … mais jamais 0,5 ou 1,75. Notre score est forcément un nombre entier. La variable points est donc de type entier, en anglais on dit integer, et en programmation on écrit souvent int.
    • On fait un test avec le mot-clé if, en écrivant une “condition”, et en terminant le test par un double point :.
      • Les lignes à exécuter dans le cas où la condition est vraie sont écrites sur les lignes suivantes, avec une tabulation. Cette tabulation est importante, et c’est une des caractéristiques de Python. Vous pouvez utiliser des tabulations ou des espaces, mais vous devez respecter toujours le même alignement. Si vous vous trompez d’un espace, vous aurez une erreur (essayez !). On parle aussi d’indentation
      • Ici la condition est une comparaison avec == : Python va comparer le contenu de capitale avec la chaîne "Paris", et renvoyer True si capitale contient exactement la chaîne "Paris" (il ne faut pas se tromper sur la majuscule !).
      • Si la condition est fausse (elle vaut False), c’est ce qui est après else: qui est exécuté (toujours avec la nécessité de bien aligner les lignes d’instructions).
    • On peut changer la valeur de la variable points très facilement : il suffit d’écrire points = <autre chose>
      • en écrivant points = points + 1, on prend la valeur de point (0, dans notre programme), on y ajoute 1, et on met cette nouvelle valeur dans point.

    Pour jouer avec

    Que se passe-t-il si au lieu de répondre exactement “Paris”, quelqu’un répond, “PARIS” ? Est-ce que c’est faux ? Non, il a juste utilisé des majuscules. Il connaît la capitale de la France. Mais notre programme lui dit qu’il se trompe. Pour changer ça, il faudrait pouvoir faire en sorte de comparer les lettres sans tenir compte du fait que ce sont des majuscules ou des minuscules. Une idée ? Une façon de faire ça, c’est de convertir capitale en majuscules avant de faire la comparaison :

    if capitale.upper() == "PARIS":
        # Donne un point si la réponse est bonne
        points = points + 1
        print("Bravo, bonne réponse !")
    else:
        print("Erreur ! La bonne réponse est : Paris.")
    

    Pratique : la fonction upper, appliquée à une chaîne de caractères, la convertit tout en majuscules ! Et pareil, il existe lower qui convertit tout en minuscules.

    Mais, si quelqu’un est un peu bavard et répond : “C’est Paris !”, notre programme va encore lui dire qu’il se trompe. Comment faire ? Deux solutions : soit on précise à l’utilisateur qu’on ne veut que la réponse, et pas une phrase (on précise la consigne), soit on modifie notre programme pour qu’il comprenne la réponse. S’il trouve le mot “Paris” dans la réponse, c’est bon ! Python nous permet d’exprimer très facilement cette condition :

    if "PARIS" in capitale.upper():
        # Donne un point si la réponse est bonne
        points = points + 1
        print("Bravo, bonne réponse !")
    else:
        print("Erreur ! La bonne réponse est : Paris.")
    

    On peut presque lire en traduisant littéralement : Si "PARIS" est dans capitale.upper(), alors…

    Et si je teste avec une réponse de bavard :

    >>> 
    1. Quelle est la capitale de la France ?
    c'est paris
    Bravo, bonne réponse !
    Score : 1 point
    

    Il est facile d’ajouter de nouvelles questions, à vous d’être inventif ! Faites attention à bien compter les points, vérifiez en affichant le score après chaque réponse.

    Pour aller plus loin

    Pour ajouter des nouvelles questions, on peut copier-coller le code et changer les questions. Très vite, le code va être très très long, alors que, finalement, on fait toujours la même chose : afficher une question, récupérer la réponse, comparer avec la vraie réponse, compter les points. Un des grands principes en programmation, c’est de ne pas se répéter. En anglais, don’t repeat yourself, c’est-à-dire : DRY.

    Comment faire ici ?

    D’abord on voudrait pouvoir représenter une paire question-réponse. Une paire, c’est une liste de longueur fixe égale à 2. En Python, on peut représenter ça par ce qu’on appelle un tuple : un certain nombre de valeurs, séparées par des virgules, forment un tuple. On peut mettre des parenthèses autour pour mettre en évidence le fait que ces objets vont ensemble. Par exemple :

    "Quelle est la capitale de la France ?", "Paris"
    

    peut aussi se noter :

    ("Quelle est la capitale de la France ?", "Paris")
    

    On peut maintenant représenter une paire question-réponse, mais dans un quizz, on voudrait en avoir plusieurs. Nous allons donc utiliser une autre structure de Python, la liste. Une liste regroupe un ensemble de variables qui ont le même type. Nous reviendrons plus tard sur ce qu’on peut faire avec des listes. Pour l’instant, nous allons juste faire une liste de questions-réponses :

    question_reponses = [("Quelle est la capitale de la France ?", "Paris"),
          ("Quelle est la monnaie du Japon ?", "Yen"),
          ("Dans quelle ville ont eu lieu les Jeux Olympiques d'été en 2012 ?", "Londres"),
          ]
    

    Une fois qu’on a cette liste de questions, on veut exécuter notre programme pour chaque paire de questions réponses. Pour afficher la liste des questions et des réponses, on peut faire :

    for question, vraie_reponse in question_reponses:
        # Affiche la question
        print(question)
        # Affiche la réponse
        print(vraie_reponse)
    

    Et voilà, vous avez fait votre première boucle for ! Comme on sait que notre liste contient des tuples (des paires), on peut récupérer directement chaque élément sous forme de paire question, vraie_reponse (on crée directement deux variables). Une “boucle”, comme son nom l’indique, consiste à répéter les mêmes instructions un certain nombre de fois (en boucle). Ici, avec la boucle for (pour, en français), on répète les instructions pour chaque élément de la liste question_reponses. Le double point :, et l’indentation, c’est exactement comme avec le test if.

    On peut maintenant réécrire le programme pour qu’il pose plus de questions. C’est encore plus facile de poser des questions !

    Encore quelques petites améliorations :

    • pour faire plus joli, j’ai ajouté une numérotation. La fonction enumerate permet de renvoyer l’indice de la position de chaque élément de la liste, en plus de l’élément…
    • au lieu d’écrire points = points + 1, ce qui est bien trop long, on peut écrire points += 1 :-).

    Nous avons donc pour terminer le script suivant :

    """
    Un jeu de quizz
    Le programme pose des questions,
    l'utilisateur répond dans la console,
    le programme compare sa réponse avec la bonne réponse
    le programme ajoute 1 point par bonne réponse
    """
    
    # On commence avec aucun point
    points = 0
    
    question_reponses = [("Quelle est la capitale de la France ?", "Paris"),
          ("Quelle est la monnaie du Japon ?", "Yen"),
          ("Dans quelle ville ont eu lieu les Jeux Olympiques d'été en 2012 ?", "Londres"),
          ]
    
    for i, (question, vraie_reponse) in enumerate(question_reponses):
        # Affiche la question
        print(i + 1, "-", question)
        # Récupère la réponse entrée par l'utilisateur dans une variable appelée capitale
        reponse = input()
        # Compare la réponse de l'utilisateur avec la bonne réponse, "Paris"
        if vraie_reponse.upper() in reponse.upper():
            # Donne un point si la réponse est bonne
            points += 1
            print("Bravo, bonne réponse !")
        else:
            print("Erreur ! La bonne réponse est :", vraie_reponse)
    
        if points > 1:
            print("Score :", points, "points")
        else:
            print("Score :", points, "point")
    

    You can download it here.


  6. On recruiting in computer programming

    When looking for some specific technical positions, finding the right candidate can become a nightmare. You want someone who can code right, of course. You also want someone with decent knowledge. Conversely, if you’re looking for a job, you have probably noticed it’s quite difficult to convey all the depth and breadth of your knowledge in a classic resume.

    Enter the Internet era: there’s plenty way to show off your skills & knowledge there. Here’s the idea: start a blog, answer questions on stackoverflow, become influent on twitter ; if you write open source code, you can show your Github account. Then give all that information to recruiters. If you’re the recruiter, ask the candidates to show you their Github account.

    James Coglan wrote an interesting blog post on why using Github as a Resume is not a good idea. What he says is you will exclude people that may be competent programmers, but simply don’t have their code on Github :

    we’re creating a filter that means only people with copious leisure time and no other hobbies or commitments will end up in these jobs. People have plenty of valid reasons not to spend their spare time on their job, and certainly most of the great programmers I’ve worked with aren’t big-time GitHubbers.

    Sure. Yet, hiring is difficult because one wants to see the candidate’s coding abilities. Coglan has some good advice there too:

    Fine, but how are we supposed to hire people?

    The hard way. Sorry everyone, but it’s the best we’ve got. People’s problem-solving ability and reasoning can’t be surmised from reading the end result of those processes, you have to talk to them. … If you want to choose wisely, and fairly, stop demanding free work from people.

    Ironically, a few days after reading this, I saw a link to resume.github.io on Twitter. A lot of people were enthusiastically tweeting and linking to it. Obviously there exists a debate about about how to do hiring properly for computer programming positions.

    In the same vein: looking at stackoverflow points. Personnally, I use SO a lot, and often find my answers there. I wish I’d have the time to answer more of them, but often answering a question needs quite a bit of digging, so I just can’t give more than a few hints.

    Anyway, when recruiting, I’m sticking to the “hard way”… test people. For code, that’s point 11 in the Joel Test, by the way.


  7. Why “Miscellany”?

    The idea of a “commonplace” is not new. I’ve taken the title “Miscellany” from Faraday. Here’s an excerpt from a biography of Michael Faraday by Colin A. Russell.

    By a great good fortune, in 1809 he (Michael Faraday) lighted on a book that had just been reprinted […] Its title could not have been more appropriate: The Improvement of the Mind. It was a famous work by a man well known not as a philosopher or scientist but as a writer of hymn. […] Among this book’s recommendations were assiduous reading, attendance at lectures, correspondence with others of similar mind, formation of discussion groups, and the keeping of a “commonplace” book in which to record facts and opinions that might otherwise be forgotten. Within a few weeks the industrious Faraday had begun a commonplace book of his own, formidably entitled The Philosophical Miscellany.

    Let’s try this experiment, and see what we can learn on the way.


Page 1 / 1