Scratch : utiliser les boucles

Mots-clés

boucles, code, scratch

Les boucles sont au code ce que l’huile d’olive est à la cuisine italienne : indispensables. On finit lors des ateliers et formations par s’en amuser, tellement je donne l’impression de me répéter (c’est le cas de la dire) lorsque j’évoque les boucles. Une par ci, une par là. Impossible de faire sans… Scratch n’en manque pas avec des particularités que l’on ne retrouve dans aucun autre langage. Petit passage en revue.

Répéter indéfiniment

La boucle la plus célèbre de Scratch et celle qui revient le plus souvent. Proche d’un des premiers codes que j’ai tapé en BASIC.


10 Print "Bonjour"
20 Goto 10


Ou comment rendre l’ordinateur fou en lui faisant sans cesse répéter la même chose sans moyen d’en sortir. Dans Scratch, la boucle « répéter indéfiniment » est essentiellement utilisée pour vérifier des états et des conditions. Ainsi, dans l’exemple ci-dessous (1er script), elle permet de suivre l’évolution du volume sonore et de déclencher un événement si celui-ci dépasse la valeur 70. La boucle est souvent oubliée et renvoie à une erreur classique. Le deuxième script en effet ne vérifie le volume sonore qu’une seule fois au déclenchement du programme en cliquant sur le drapeau vert.

Il est possible d’arrêter une telle boucle en utilisant l’instruction « stop ». Par exemple :

Répéter x fois

La boucle la plus simple à comprendre. À utiliser quand vous savez exactement de combien de répétitions vous avez besoin. Par exemple :

Cette boucle peut aussi s’utiliser avec des variables quand on ne connaît pas le nombre de répétitions à la base. Par exemple pour épeler un prénom :

C’est un peu dans ce cas l’équivalent d’une boucle « for … next » qui permet d’utiliser une boucle en faisant évoluer une ou plusieurs valeurs. Cela m’a toujours étonné que Scratch ne possède pas de boucle de ce type mais on peut la simuler avec la boucle « répéter jusqu’à ».

Répéter jusqu’à

Cette boucle est particulièrement utile car elle permet des choses que peu de langages offriraient aussi facilement. Par exemple :

Mais je l’utilise principalement pour les boucles « for … next ». Une boucle de ce type possède une condition de départ, une condition de fin et une variation de la valeur suivant un « pas ». Ainsi, par exemple, la variable x vaut 0 en condition de départ ; on arrête la boucle lorsque x vaut 250 en condition de fin et on la fait varier de 10 en 10.

En Basic, cela ressemblerait à ceci :


FOR x = 0 TO 250 STEP 10
PRINT x
NEXT


Et avec Scratch :

Ces boucles sont fort utiles notamment dans le traitement des chaînes de caractère ou dans la génération de graphismes.

Bon amusement !

ParcourSup et algorithmes : le principe de diabolisation

Crédit : Viewminder (Flickr)

Dire que ParcourSup rencontre quelques petits problèmes est un euphémisme… Cela semble malheureusement être le plantage total. Et, comme de coutume, je vois fleurir les commentaires façon « c’était mieux avant ». La technologie a bon dos.

Pourtant une machine ne fait que ce qu’on lui demande de faire. Elle ne va pas plus loin. Quand un programme est codé avec des moufles, il y a bien une paire de mains dans ces dernières.

Se planter n’est pas grave mais il y a un moment pour se planter. Comme pour les artistes, ce n’est pas sur scène qu’il faut se planter mais lors des répétitions. C’est à ce moment que le plantage est salvateur car il révèle des failles et des erreurs de conception que l’on peut alors corriger.

On peut appliquer ce que j’appelle le principe de diabolisation. Concevoir, coder un algorithme est plus ou moins complexe et, dans la majorité des cas, on l’imagine dans des conditions idéales. C’est le moteur de base qui est loin d’être fini et qui ne fonctionnerait tel quel que dans un paradis comme la planète Beatituda que les Simpson sont censés atteindre un jour dans un épisode consacré aux sectes. Mais je m’égare… Les conditions idéales n’existent pas et on va alors viser des conditions de M… Je vous laisse compléter.

Se faire l’avocat du diable, c’est en effet se poser la question de savoir qu’est-ce qui va bien pouvoir « merder » dans la solution que l’on a mise en place. Passez moi le terme car c’est celui qui convient. C’est un principe « hacker » que de chercher la petite bête, que d’imaginer des conditions diverses parfois complètement folles dans lesquelles la solution va planter lamentablement. Un développeur qui a pour adage « bon, ça ira comme ça » est soit un incompétent, soit un inconscient tout droit sorti des Télétubbies, soit enfin un adepte des mises à jour plus que fréquentes. Diaboliser, c’est prévoir et prévoir, c’est jouer la carte de la sécurité pour laquelle il ne faut pas hésiter à aller très loin dans le délire.

Par exemple :

« Affluence record : on n’a pas assez de serveurs pour répondre. » -> « Ok, mise en place d’une autre série de serveurs en cas de débordement. »

« Le circuit électrique tombe en panne. » -> « Ok, on prévoit des générateurs indépendants. »

« Batman ne trouve pas sa voie. » -> « Ok, on ouvre une section supplémentaire. »

« La Russie, la Corée du Nord et les États-Unis prévoient une attaque de grande ampleur pour déstabiliser le site . -> « Ok, on a une équipe sur le coup et un bon rempart en place. »

« Une météorite menace de s’écraser sur le data center ou un peu plus loin dans l’océan. » -> « Ok, on reporte à la semaine prochaine et, en attendant, on va boire un coup. »

« Rien ne va. C’est l’apocalypse. » -> « Ok, on a une belle page 404 avec les indications à suivre et des messages rassurants. »

Je plaisante avec ces exemples. Le problème est qu’aujourd’hui nous sommes face à un enjeu extrêmement important et un fiasco qui risque de mettre sur le carreau nombre de jeunes étudiants. On ne sait déjà pas trop ce que l’on veut faire à 18 ans alors si en plus on nous met des bâtons dans les roues… Personnellement je bénis le fait de n’avoir pas connu ce casse-tête. Je ne sais pas dans quelle section je me serais retrouvé. Je n’aurais en tous cas sûrement jamais pu faire les études que j’ai effectuées.

Alors, innovons aujourd’hui, innovons demain mais testons, testons encore, testons encore plus loin, cassons la machine, une fois, deux fois, trois fois mais, j’insiste : comme au théâtre, lors des répétitions pas lors de la première…

Carnaval numérique au Forum des Sciences de la Villette : Micro:bit, macro-possibilités

Crédit : Wikipédia

Cela fait déjà quelques temps que je m’amuse régulièrement avec le Micro:bit, un mini-ordinateur développé par la BBC et à destination de l’apprentissage du code. Le prétexte particulièrement justifié d’organiser lors du Carnaval Numérique de l’AN@É un atelier consacré à cette petite merveille de l’électronique.

Lancé en 2015, le Micro:bit est destiné à être distribué dans l’ensemble des écoles de Grande Bretagne et la BBC prévoyait un minimum d’un million d’exemplaires. Le projet fait écho au BBC Micro, un ordinateur distribué dans un objectif pédagogique à hauteur d’1,5 millions d’exemplaires au début des années 80, et plus récemment au projet de la fondation américaine OLPC (One Laptop Per Child) qui a distribué plusieurs millions d’ordinateurs XO aux enfants de pays en voie de développement.

Le Micro:bit connaît un franc succès et ne devrait pas tarder à envahir nos contrées. Il faut reconnaître qu’il possède un certain nombre d’atouts non négligeables. Sa modularité et les différentes approches possibles en font un dispositif incontournable pour des projets pédagogiques qu’ils soient à orientation technique, artistique ou scientifique.

Ne cherchez pas d’écran. Le Micro:bit tient dans la main et se contente d’un affichage de 5 leds sur 5. Cela paraît réduit de prime abord mais convient tout à fait aux projets dédiés au Microbit et force à penser à la manière des anciens jeux vidéos et du graphisme 8 bits.

Le Micro:bit peut être alimenté via un câble USB connecté à l’ordinateur mais aussi par deux piles 1,5 volts, le rendant ainsi portable. Il s’intègre alors dans des dispositifs divers : boîte en carton, support imprimé en 3D, porte-bagde, tissu…

La liste du matériel électronique embarqué par le Micro:bit est impressionnante pour un si petit dispositif : accéléromètre, gyroscope, compas, capteur de température. Deux boutons peuvent être programmés à souhait et 5 connecteurs permettent de piloter des composants, d’utiliser le corps comme interrupteur comme pour une Makey Makey ou d’ajouter une sortie sonore tel un buzzer par exemple car le Micro:bit peut produire du son, de la musique et possède même des fonctions de synthèse vocale.

Coté code, le Micro:bit peut se programmer en ligne via le site officiel au travers de deux interfaces : l’une orientée programmation graphique façon Blockly et reprenant la syntaxe du Javascript, l’autre en code « texte » avec le langage Python. D’autres modalités sont disponibles, notamment au travers de Scratch et des extensions ScratchX http://scratchx.org/ Un éditeur hors-ligne, MU, est aussi disponible. Il est aussi possible d’utiliser des applications Android et iOs pour communiquer avec le Micro:bit et le programmer. De nombreuses autres extensions tant logicielles qu’électroniques sont disponibles et il me tarde d’y plonger.

Pour les premiers pas, j’ai tendance à utiliser la version Blockly en ligne car, outre sa similitude avec Scratch, elle dispose d’un émulateur. Cela permet de faire découvrir le Micro:bit même si l’on ne dispose pas du précieux artefact.

L’accueil des enfants fut enthousiaste. Envie d’explorer, de bidouiller, de bricoder… Tant avec la petite machine qu’en utilisant le simulateur. Cela promet de belles perspectives d’atelier auxquelles il ne reste plus qu’à ajouter un scénario, un univers au-delà des simples aspects techniques.