Blog // Exirel.me

Hospitalité de façade

Par Florian Strzelecki - 09:00 - 20.08.2018

Tags : JDR, VEDUT

Les étapes sont nombreuses sur les chemins de pèlerinage, et il n'y a pas toujours de monastère, de chapelle ou d'hospice pour accueillir les voyageurs - et encore faut-il parfois les bons sauf-conduits. Sur le devant de cet établissement une belle affiche gravée et peinte sur bois présente le propriétaire des lieux recevant le pèlerin avec tous les honneurs qui sont dû aux fervents croyants. Sur le derrière des choses, c'est une toute autre histoire : les prix changent à la tête du client - celui-ci a l'air riche il pourra bien payer plus, celui-là a l'air désespéré il n'osera pas dire non, et ce dernier n'osera jamais dormir à la belle étoile ! Et ces lits... la promesse de 20 lits dans une salle commune se transforme en réalité en une douzaine de paillasses posées sans soin dans une salle aux murs décrépits et où règne l'humidité et les miasmes, le tout loin de l'image d'une soirée agréable autour du feu de cheminée. La nourriture est tellement infecte qu'il n'est pas nécessaire d'aborder le sujet - évitons d'avoir la nausée. Non, vraiment, c'est peut-être la seule option, mais elle est peut-être plus terrible encore qu'une nuit dehors.

Comment allez-vous marchander votre nuit ? Est-ce que vous serez vraiment à l’abri de tous les dangers ? Qui surveille vos affaires, et à qui pourrez-vous faire confiance ? Et le lendemain, si jamais vous prenait l'envie de négocier le prix, pourrez-vous faire fasse à l'aubergiste et ses gros bras ? Ce ne serait pas la première fois qu'un pèlerin viendrait à disparaître pendant son voyage, et si ce n'est pas vous, peut-être vos oreilles entendront le plan ourdit par les sbires du cruel propriétaire des lieux voulant détrousser, au hasard : un jeune couple venu se réfugier là pour la nuit ; un marchand accompagné d'une mule et d'un précieux chargement ; ou encore un voyageur naïf à la richesse trop voyante.

Les voyages ne sont jamais parfaitement sûr, ils comportent des risques, et il n'y a pas de raison que l'avarice des hommes ne s'emploie pas à le démontrer à la moindre étape du parcours. Cher MJs, voilà une bonne occasion de pimenter la route !

Les films de janvier à juillet 2018

Par Florian Strzelecki - 13:11 - 18.08.2018

Tags : Cinéma

Le cinéma est un bon divertissement, et entre Netflix et mon abonnement de cinéma, j'ai l'occasion de voir beaucoup de films. Certains sont excellents, d'autres... c'est discutable. J'ai envie de faire un petit bilan de presque-mi-année sur les films que j'ai vu depuis janvier 2018, et de voir ce qu'il en ressort.

C'est un classement subjectif non pas sur la qualité des films, mais sur le plaisir à les regarder. Cela n'indique rien de la valeur des films, et je ne cherche pas non plus à analyser pourquoi j'ai plus aimer un film qu'un autre. Je me contente de dire ce que j'en ai pensé. Parfois, je vais voir un film à l'exact moment qu'il faut, et parfois le film tombe à plat parce que ce n'était pas le bon moment, ou pas les bonnes conditions pour le voir. Parfois un film répond à mes attentes, et parfois il me déçoit tellement que je vais le détester. Ne prenez pas cela trop au sérieux !

Top-tier

Still-Good-tier

Almost-tier

Meh-tier

Nope-tier

Plus de 50 films

Et voilà, c'était plus de 50 films vu cette année. Pour le moment aucun n'arrive à atteindre mon top-50 de mes films les mieux notés sur Criticker. Mais l'année n'est pas terminée !

Sur la place de l'église

Par Florian Strzelecki - 09:00 - 13.08.2018

Tags : JDR, VEDUT

Chaque dimanche après la messe il est désormais coutume dans ce petit village que l'herboriste fasse taverne sur la place en face de l'église. Il sort de sa boutique deux vieux tonneaux vides et dépose une simple planche de bois, tandis que les villageois s'occupent d'apporter chaises et bancs sur lesquels s'assoir pour partager un moment communautaire. Il vend sur son étal temporaire des productions locales - toutes autorisées par le prêtre de la paroisse qui prélèvent son dû - ainsi qu'un alcool qu'il est le seul à distiller à partir de céréales de la région. C'est une habitude bien ancrée chez les habitants, qui viennent après la messe moins pour se désaltérer que pour partager les dernières rumeurs. C'est un moment important de la vie sociale voire politique des gens du coin, et tant que l'église n'est pas menacé et l'ordre maintenu, ni la morale ni les autorités n'ont rien à y redire. Jusqu'à présent.

Qu'allez-vous apprendre comme rumeur ? Est-ce que les villageois s'ouvriront vraiment à un étranger lors de cet événement qui leur est d'habitude réservé ? Comment les autorités vont-elles réagir s'il y a du grabuge ? Et de quel côté serez vous à ce moment là ? Auriez-vous renversé le verre de quelqu'un ? Ou bien fait les yeux doux à la mauvaise personne ? N'est-ce pas le meilleur moment pour tâter la température ? Et si un jour l'herboriste ne vient pas à la messe, et n'ouvre pas sa porte à l'heure prévue ? Qui peut dire l'effet d'un empoisonnement en plein jour sur la place publique, un verre à la main ?

Il existe bien des possibilités de jouer autour de cette taverne. Un village, une petite communauté, ses habitudes, et un élément perturbateur qui pourrait bien tout chambouler. Cher MJs, je pense que vous trouverez des idées !

Projet épisodique

Par Florian Strzelecki - 23:47 - 11.08.2018

Tags : JDR, VEDUT

L'idée originale de VEDUT, pour "Vous Êtes Dans Une Taverne", n'est pas de moi, mais d'un ami qui aujourd'hui produit des œuvres bien plus grandes que ce que nous pouvions imaginer dans notre adolescence. J'aimerais cependant m'approprier pleinement un projet qui en est librement inspiré. Ce n'est pas un souhait nouveau, mais assez lointain et toujours remis à demain jusqu'à présent. Je ne sais pas me mettre en route pour ce genre de chose. Chaque départ est le début de la procrastination et de l'éparpillement. Je succombe à la liberté de tout faire, en ne faisant plus rien. Il ne me reste plus qu'à essayer, en exploitant ce que je sais de moi : je travaille mieux avec des contraintes qu'avec des libertés.

En voici deux : publier par épisode, comme un feuilleton, et publier des textes courts. Se forcer à rentrer dans un cadre, à limiter les dérives de l'imagination, à vaincre la paralysie devant l'infinité des possibles qui engendre cette peur de ne rien produire. Les idées sont parfaites tant qu'il n'y a rien pour les concrétiser.

VEDUT sera mon feuilleton de tavernes, auberges, boîtes de nuits, bars, brasseries, et autres débits de boissons inspirés de l'imaginaire collectif du jeu de rôle. Un épisode pour un lieu, ses décors et ses habitants.

1986

Par Florian Strzelecki - 00:00 - 04.08.2018

Tags : Bonjour, 4 Août

J'aime bien relire la page Wikipédia de l'année 1986 :

Et le tout, avant le 4 août 1986.

Fantastic Tests

Par Florian Strzelecki - 18:25 - 13.04.2018

Tags : Programmation, Bonne pratique, Développement, Unit Testing, Tests

And How to Write Them

J'ai donné le mois dernier un talk mystère à Software Crafts·wo·manship, car j'avais envie de parler des tests (en programmation). Le format ne permettant pas de s'étendre beaucoup sur le sujet, je prends le temps aujourd'hui de l'explorer un peu plus par écrit.

J'aime les tests. Tous les types de tests : unitaire, intégration, QA, utilisateur, performance, chaos, etc. il en existe plus que je ne peux en lister. C'est, avec la documentation, un outil indispensable pour moi. Si je ne suis pas un extrémiste du TDD, je tente de le pratiquer aussi souvent que possible, et je ne cesse d'en défendre l'utilité et les usages.

Pourtant, je tombe encore et toujours sur les mêmes débats sans fin, les mêmes remarques subjectives, les mêmes traits d'esprit qui se veulent toujours plus malins, et les mêmes conflits stériles qui cristallisent des positions bien campées là où il faudrait plutôt résoudre les problèmes - et de répondre aux vrais besoins.

2 unit tests. 0 integration tests

Je prends souvent en exemple le cas des blagues "2 unit tests. 0 integration tests". Il en existe beaucoup de variantes, toute plus ou moins drôles.

Je n'aime pas cette blague. Ce n'est pas tant qu'elle soit employée à tort et à travers, que le fait qu'elle se base sur un paradigme que je trouve fondamentalement inadapté : il y aurait d'un côté les tests unitaires, et de l'autre les tests d'intégration. Certains verront dans cette blague une défense des tests d'intégrations, d'autre une attaque des tests unitaires, alors que le problème de fond, ce n'est pas l'un ou l'autre, ou l'un sans l'autre, mais l'inadéquation des tests avec les besoins réels. Passer son temps à dire qu'il faut les deux ne permet toujours pas de dire comment écrire de bons tests.

Le problème de fond qui m'intéresse, moi, c'est d'écrire des tests qui ont un sens ; des tests qui m'apportent quelque chose, non pas en statistique ou par respect de certains principes, mais en sécurité, en maintenabilité, et surtout, en utilisabilité.

À la fin de la journée, lorsque je reçois un rapport de test positif, ce qui compte, c'est que je sois rassuré : l'utilisateur va pouvoir utiliser mon application.

Youtube & Cinéma

Par Florian Strzelecki - 13:52 - 10.03.2018

Tags : Cinéma, Youtube

J'aime le cinéma, et je passe beaucoup de temps sur Youtube : c'est l'occasion de partager une liste de chaînes Youtube auxquelles je suis abonné.

Il n'y a aucun ordre, pas même alphabétique. Certaines sont plus intéressantes que d'autres, certaines ne vous plairont pas, et d'autres encore sont absentes : vous êtes seul juge, et vous pouvez toujours partager vos trouvailles.

Critiques de films

Une opinion ? Une critique ? Un avis ?

Divertissements

Parce que le cinéma est vaste et qu'il y a toujours moyen d'en rire ou de s'en amuser - et pas seulement en regardant des films.

Analyses de films & séries

Pour aller un peu plus loin dans les thématiques d'un film, d'une série, d'un genre.

Analyses des techniques

Derrière chaque film il y a des équipes qui réalisent, produisent, montent, assemblent. Les métiers du cinéma sont nombreux, les techniques pour donner vie à un films encore plus.

Thierry Roland

Par Florian Strzelecki - 10:05 - 04.08.2017

Tags : Ma vie, 4 Août, football

Thierry Roland, né le 4 août 1937 à Boulogne-Billancourt et mort le 16 juin 2012 à Paris, est un journaliste sportif français et un célèbre commentateur de matchs de football.

Wikipédia

Je n'ai jamais trop été intéressé par le football, déjà parce que c'est un sport et que j'ai une attention très limitée quand il s'agit de sport ; ensuite parce que concrètement il ne se passe jamais grand chose dans les 90min que prend un match.

Mais Thierry Roland, ça, je m'en souviens. Aussi loin que je me souvienne, c'est sa voix que j'entendais à la TV lorsque ça parlait de foot, sa voix reconnaissable entre mille.

Mais bon, moi, le foot...

DRY, de la fonction au décorateur

Par Florian Strzelecki - 23:38 - 12.07.2017

Tags : Python, Programmation, Développement, decorator

Prenons un exemple de code python simpliste :

def more(number, i):
    """Add ``number`` and ``i``"""
    return number + i

print(more(5, 2))

Sans grande surprise, ceci affiche dans le terminal le nombre "7". Maintenant, mettons que j'ai envie d'afficher du texte avant de faire l'addition... mais seulement de temps en temps ?

La version simpliste, c'est d'écrire une autre fonction, comme ceci :

def more_verbose(number, i):
    """Print a sentence and return ``more(number, i)``"""
    print('Calling function `more`')
    return more(number, i)

print(more_verbose(5, 2))

Ce qui affiche :

Calling function `more`
7

Et maintenant, qu'est-ce qui se passerait si je voulais faire la même chose avec une autre fonction ?

Limites de sphinx-autodoc

Par Florian Strzelecki - 17:31 - 09.07.2017

Tags : Python, Documentation, sphinx, autodoc

J'utilise Sphinx pour écrire des documentations depuis quelques années maintenant, que ce soit pour des projets Python ou non, et avec le recul j'en viens à en considérer les limites. Elles sont nombreuses, et de plus en plus frustrantes.

Mais pour le moment, je vais me concentrer sur son extension autodoc, qui inspecte le code et permet d'en extraire les docstring. Son but est simple : générer une documentation exhaustive et à jour (ce que j'appelle "la référence technique"), puisqu'elle concorde avec le code source documenté (pour l'exercice, on supposera toujours vrai que les docstrings soient toujours à jour avec le code source).

Ma première expérience de documentation fut avec Doxygen, à l'IUT (entre 2004 et 2006). Ce fut une bonne expérience, et une ouverture sur la documentation et sur son importance pour la qualité.

Sans expérience en la matière, il m'apparut très vite comme une pratique essentielle du métier, bien que ce ne soit pas l'avis de tout le monde. Autant dire qu'il y a de quoi écrire des livres entiers sur la place de la documentation, que ce soit dans notre culture ou dans nos passages à la pratique.

Plus tard, j'ai été amené à utiliser des outils similaires, pour d'autres langages, et pour un lectorat de plus en plus varié. Depuis, j'ai même eu l'occasion de donner plusieurs ateliers et conférences sur le sujet, qui me passionne peut-être même plus que le code lui même.

Obsolescence de la documentation

Par Florian Strzelecki - 18:21 - 28.01.2017

Tags : Documentation, Lecture, Obsolète

Les déménagements ont ceci de formidable qu'ils permettent de regarder ses plus vieilles affaires oubliées, et de faire un choix : garder, ou jeter. N'ayant plus la place de tout garder, et n'étant pas spécialement attaché aux affaires du passé, j'ai tendance à jeter assez vite - sauf les livres, c'est beaucoup trop difficile avec les livres.

Il se trouve que j'ai eu ce choix difficile devant un carton de livres techniques. Garder ou jeter ? Et puis, j'ai lu les titres, j'ai relu quelques passages, et surtout, j'ai vérifié les dates de publication : de 2006 à 2011. Le choix a finalement été beaucoup plus facile que prévu.

La documentation n'est ni éternelle ni immuable, elle doit changer, évoluer, et s'adapter aux évolutions de son sujet (langage, framework, outil, etc.). Les livres papiers, malheureusement, ne peuvent pas faire évoluer leur contenu - pas sans une intervention physique, généralement plus destructrice que bénéfique si j'en crois mon expérience. Je rajoute d'ailleurs que les magazines techs ont exactement le même problème : à partir du moment où c'est imprimé sur du papier, il y a une date de péremption au dos.

Je ne nie pas l'intérêt historique ou d'archivage de tels documents, qui restent très intéressant pour voir l'évolution de notre univers informatique - c'est toujours un peu drôle de voir 300 pages sur jQuery ou PHP 4 - mais d'intérêt pratique au quotidien, pour apprendre et transmettre des savoirs.

Au final, concernant les livres, je n'en achète plus, ayant réalisé déjà il y a quelques temps qu'ils ne peuvent pas rester une source d'informations fiables suffisamment longtemps pour en justifier l'achat.

Et en ligne, me direz-vous ? La situation n'est pas toujours mieux : dans l'univers JavaScript, il m'est souvent difficile de trouver la bonne documentation. Parfois l'URL de la doc n'est plus la même entre deux versions (par exemple pour Webpack), ou bien la documentation ne précise pas quelle version du logiciel elle documente (pour Godot), ou pire encore la documentation d'une version précédente, toujours supportée, a été retirée et n'est plus consultable en ligne.

Maintenir une documentation n'est pas une tâche aisée, j'en conviens, mais je suis toujours aussi surpris de voir que nous avons si peu d'outils à notre disposition pour améliorer la situation...

Python, Makefile, et tests

Par Florian Strzelecki - 19:15 - 24.10.2016

Tags : Python, Bonne pratique, Unit Testing, Code Coverage, Makefile

Depuis quelques temps, j'essaie plusieurs fichiers Makefile pour mes projets en pythons : pour lancer les tests, les validateurs divers, et générer les différents rapports (tests, couverture, et qualité).

Voici ce à quoi j'arrive pour le moment :

# Project tasks
# ==========

test:
    coverage run --source=<package> setup.py test

report: pylint
    coverage html

pylint:
    pylint <package> > pylint.html || exit 0

isort:
    isort -rc <package> test.py

flake8:
    flake8

quality: isort flake8

all: quality test report

En général, je lance simplement avec make all, pour tout faire d'un coup sans me poser de questions. Cela va donc lancer :

Premier constat : inutile pour moi de lancer des tests sur du code qui n'est pas correctement formaté. Le coût d'un code propre est minime voire quasi inexistant - j'ai l'habitude, ça aide beaucoup - alors autant se fixer des règles strictes et s'y tenir.

Second constat : je n'utilise plus (ou presque plus) de lanceur de tests spécifiques (py.test, nosetests, etc.). Pourquoi ? Parce qu'au final, ces outils ne font qu'ajouter de la déco sur les tests, mais ils ne m'aident pas à écrire de meilleurs tests. Je suis habitué à unittest, et la plupart du temps, je n'ai pas besoin d'une explication particulière pour un test.

D'ailleurs, que l'on utilise simplement assert ou les méthodes du framework unittest, un message manuel est souvent préférable à une interprétation du lanceur de tests :

import unittest

class TestIsPositive(unittest.TestCase):
    def test_behavior(self):
        assert is_positive(0) is True, (
            'is_positive must return True with 0')
        assert is_positive(2) is True, (
            'is_positive must return True with > 0')
        self.assertFalse(
            is_positive(-1),
            'is_positive must return False with < 0')

Bien entendu, c'est un cas où le message est un peu accessoire : il faut imaginer des cas plus complexes, où le résultat d'une fonction est d'un type complexe, et donc la raison d'être demande un peu plus qu'une simple "ceci doit être égal à cela".

Quoi qu'il en soit, make all est maintenant ma routine quotidienne, simple, rapide, et efficace.

Risque et qualité

Par Florian Strzelecki - 01:33 - 25.08.2016

Tags : Programmation, Bonne pratique, Qualité

Récemment, mon père me disait sa satisfaction à utiliser son nouveau smartphone, un Nexus 5 que j'ai utilisé 2 ans et qu'il possède désormais. Avant, il utilisait un téléphone bas de gamme, qui remplissait parfaitement ses fonctions et qui n'avait rien à se reprocher.

Le Nexus 5 est un appareil de bonne facture et très agréable à utiliser : c'est un produit de qualité, et cela, mon père, pour qui la puissance du processeur et autres chiffres ne sont que du charabia, l'a très bien ressenti dans son usage quotidien.

Qualité

J'ai mis le doigt récemment sur un comportement que j'adopte lorsque je suis face à un problème de qualité sur un projet : je cherche par tous les moyens à minimiser les risques encourus par le projet pour surmonter ledit problème de qualité.

Jusqu'à présent, je n'avais pas réalisé pourquoi j'adoptais parfois une attitude si défensive dans un projet informatique, alors que sur d'autres je peux prendre beaucoup plus de risques, faisant même parfois preuve d'un optimisme qui frôle la témérité !

Essayons de mettre certaines choses au clair dans mon esprit, en mettant bout à bout ce à quoi je pense.

Rapport proportionnel

Mon intime conviction est que le risque d'un projet est inversement proportionnel à la qualité du projet, qu'elle soit interne ou externe à ce dernier.

Par exemple, lorsque je travaille sur un bout de code :

Je sais que je dois redoubler de vigilance. Pas seulement parce que c'est "compliqué", mais aussi parce que je risque simplement d'ajouter plus de bugs que je n'en corrige. Parce que la qualité intrinsèque (ou plutôt son absence) d'un bout de code augmente drastiquement le risque de rencontrer un problème en travaillant dessus.

Si je veux m'en sortir, je dois alors faire en sorte de réduire les risques : je peux augmenter la qualité (en documentant au fur et à mesure, ou en écrivant des tests), et je peux augmenter le niveau de défense autour du code - en limitant les dépendances, en limitant les modifications, en relisant plusieurs fois mon propre code, et de manière générale en ajoutant plusieurs contrôles autour du code.

Dans tous les cas, j'adopte une posture défensive, où j'avance pas à pas, et où je réduis au maximum la prise de risque. Cela demande souvent plus de temps et génère bien plus de fatigue mentale qu'une tâche complexe pourrait provoquer à elle seule.

Du code au projet

La qualité d'un bout de code est du domaine de la micro-gestion, et si j'adopte une posture défensive à ce niveau là, je reproduis le même schéma au niveau macro-gestion : si la quantité de bugs est importante, si les fournisseurs ne sont pas fiables, si les documents de travail ou les réunions ne sont pas claires ou satisfaisantes, alors je vais chercher à réduire les risques au niveau du projet lui-même.

C'est dans ce genre de cas où je vais me mettre à poser plus de questions, à écrire plus de documents, et à prendre plus de temps pour analyser les causes internes et externes aux problèmes rencontrés. Je ne vais pas seulement chercher à comprendre pourquoi je travaille, je vais aussi chercher à comprendre comment le projet en est arrivé là. Je suis plutôt convaincu que l'histoire d'un projet permet de mieux comprendre pourquoi il faut faire certains choix aujourd'hui.

Quant à réduire les risques, je vais proposer moins de fonctionnalités, ou définir plus de limitations. De manière générale, je vais augmenter le temps passé et, surtout, je vais faire en sorte de diminuer les attentes des clients : s'ils s'attendent à moins, ils seront moins déçus si le projet se passe mal.

Du projet aux humains

Je suis rarement d'accord avec mes collègues à partir du moment où je me mets dans une posture défensive pour réduire les risques. Dans les cas les plus extrêmes j'ai à peu près tout entendu : je serais paranoïaque, je ferais dans la sur-qualité, mon code serait trop défensif et serait une pure perte de temps et de moyens, et le pire de tous, je n'aurais aucune vision business et mon avis serait donc à ignorer complètement.

Autant vous dire que j'ai surtout eu des problèmes en ESN, où la qualité n'est clairement pas un objectif de l'entreprise - le client quant à lui se faisant surtout tondre comme un mouton en payant des rallonges de jours-homme sur son projet.

Le plus souvent, je suis simplement en désaccord avec la façon de procéder, sur le rythme à suivre, sur la démarche initiale et sur la vision à moyen terme. Bref, je vise à limiter les risques, tout en partageant le même objectif final - simplement, pas de la même façon.

Réciproque

Lorsque la qualité est absente, le risque augmente. Lorsque le risque augmente, il arrive toujours un problème grave auquel il faut répondre rapidement. Je n'aime pas ça, parce qu'en général les petites mains qui doivent réparer en catastrophe, ce sont les miennes.

Mais il n'y a pas que ça. Si augmenter la qualité permet de faire diminuer les risques, je pense que la réciproque est vraie aussi : en diminuant les risques, la qualité augmente - ne serait-ce qu'un peu. Parce qu'en diminuant les risques, on diminue le nombre des catastrophes. On diminue le nombre d'interventions faites dans l'urgence. On diminue les problèmes que peuvent subir les clients.

Parce que la qualité (ou son absence), et bien au bout du compte, ce sont surtout les clients qui en paient le prix.

A New High Score

Par Florian Strzelecki - 23:52 - 10.08.2016

Tags : Jeux vidéo, Steam, Récompense, Culpabilité

Il y a certains soirs où je n'ai plus envie de rien. Se lever de sa chaise, préparer un repas ou aller au restaurant, l'idée même de devoir choisir entre ces deux options aussi triviales soient-elles me fatigue au plus haut point. C'est le genre de soirée perdue à décider quoi faire et quand le faire, avec le sentiment confus d'une certaine culpabilité, mêlée d'ennuis et de frustrations.

Je décide d'ouvrir ma bibliothèque de jeux Steam. Je devrais peut-être les trier, non ? Les ranger dans des petites catégories, les uns après les autres. Ceux là dans les "Action RPG", ceux ci dans "Arcade", et celui là dans "Tower Defense". Je pourrais sans doute jouer à l'un d'eux, histoire de dire "un de moins" sur la longue liste des jeux auxquels je n'ai jamais joué, la longue liste des jeux que je ne fais que "posséder" (si tant est que cela puisse encore vouloir dire quelque chose à l'ère du produit dématérialisé).

Alors je parcours les 402 jeux que j'ai à ce jour. Celui là non. Celui ci bof. En voilà un que j'ai déjà terminé. Ce jeu là, j'ai essayé, mais quelque chose m'a déplu au point de le désinstaller presque immédiatement. Je pourrais sans doute installer les 20 Go de ce JRPG, mais ai-je vraiment envie de me lancer dans cette aventure ? De devoir apprendre de nouvelles mécaniques, de nouveaux systèmes, de remettre en cause mes compétences en tant que joueur et de devoir m'investir à nouveau des dizaines d'heures dans un nouveau monde...

C'est le genre de soirée où je me donne bonne conscience en me disant que j'attends simplement le bon jeu, celui qui sort bientôt et qui est plein de promesses.

Ou alors...

Bejeweled 3

Oui, je suis sérieux. Non, ce n'est pas une blague. Tout de même... c'est... Et puis pourquoi ai-je ce jeu ? Comment cela se fait-il qu'au milieu du reste...

Oh et puis tant pis ! Je n'ai que ça à faire, et j'ai déjà cliqué sur "installer". Avec la fibre, je n'ai plus le temps d'y penser qu'il est déjà là, prêt à jouer, prêt à se lancer.

...

Je ne sais pas si je dois prendre le jeu au sérieux ou si c'est une blague très élaborée. L'écran d'accueil est là, rutilant de sphères de diamant, chacune m'invitant à jouer à l'une des variantes possibles. Oh bon sang il y a un mode quête ! Dans Bejeweled ! Je le lance, pour voir. Chaque niveau est un mini-jeu, qui permet de débloquer une perle, qui permet de débloquer un "artefact" de Bejeweled. La première partie se lance.

C'est coloré, tout scintille, et surtout, c'est fluide.

D'autant plus qu'il y a un paramètre graphique "ultra". Rien que ça.

Unbelievable

La première chose que je remarque, après la fluidité des mouvements, ce sont les bruits : chacun donne un feedback sur ce qui se passe, que le mouvement soit accepté ou refusé.

Mais il y a mieux : l'annonceur.

Good

Euh... merci ? Je veux dire, je n'ai fait qu'intervertir deux gemmes, ce n'était rien, vraiment. La suite, ce n'est pas moi, c'est seulement le hasard.

Excellent!

Ah bon d'accord c'était si bien que ça alors ?

Level Complete

... Déjà ?

Bien entendu, c'est le premier niveau, c'est donc vraiment très facile. Il n'en reste pas moins que chaque mouvement un peu "spécial" permet de recevoir les félicitations appuyées de l'annonceur, d'une voix grave et profonde, comme si chaque petite action était l'accomplissement d'une tâche héroïque.

Déplacer une gemme devient l'équivalent d'un déplacement de montagne.

Trop

Ma soirée n'avait pas grand intérêt, et Bejeweled n'est qu'un passe temps. Et le jeu doit certainement le savoir, car il en fait des tonnes. Il surjoue absolument tout, de l'écran d'accueil à l'annonceur, en passant par le bruits des combos, le scintillement des gemmes, et les effets visuels des gemmes spéciales.

Je suis à la fois fasciné et terrifié à l'idée que des gens se sont sérieusement posés dans une pièce pour se dire :

Et là, lorsque la gemme explose, il faut des arcs électriques qui partent d'elle et rejoignent jusqu'à 3 autres gemmes dans un effet de foudre, et le bruit doit être conséquent mais pas trop bruyant et surtout ne pas crépiter. Ah et au fait pour les mini-jeu, il en faudrait un avec des colonnes de glaces qui remontent petit à petit pour bloquer la progression.

Je comprends très bien que chaque détail est important. C'est même tout à fait normal en réalité : le plaisir de ce jeu repose en grande partie sur le puissant sentiment d'accomplissement dans la destruction d'un plateau de gemmes scintillantes. Et plus le nombre de gemmes explosées est grand, plus l'effet visuel et sonore doit être retentissant.

Jouer à Bejeweled, c'est faire l'expérience du vide qui en fait trop. C'est l'expérience du plaisir immédiat et de la récompense de héros pour des gestes banals. C'est la couche de reconnaissance du moindre des petits accomplissements du joueur. C'est le menu big-mac du petit jeu sur smartphone porté sur grand écran.

Comme si la culpabilité de lancer un passe temps alors qu'il existe tellement de bons jeux là dehors, prêt à être jouer pendant des heures, devait être lavée par un maelstrom de félicitations pour avoir bouger le curseur de sa souris.

...

Je ferais bien d'aller me coucher.

La lettre de Vannes

Par Florian Strzelecki - 00:00 - 04.08.2016

Tags : Ma vie, 4 Août, Bretagne

Il se trouve que nous sommes le 4 Août, et c'est au moins le 3ème article que je publie un 4 Août. À croire qu'il y a une raison derrière tout ça.

Quoi qu'il en soit, j'habite en Bretagne - à Rennes - depuis maintenant 6 ans. Et l'Histoire de la Bretagne est une très longue histoire, avec des traités, des batailles, et tout un tas de gens importants.

Je regardais, tout à fait au hasard, l'article Wikipédia concernant l'Union de la Bretagne à la France, lorsque j'ai découvert que :

Le 4 août 1532, les États de Bretagne, convoqués par François Ier à Vannes, adressent au monarque une supplique pour « unir et joindre par union perpétuelle iceluy pays et duché de Bretagne au royaume, le suppliant de garder et entretenir les droits, libertés et privilèges dudit pays et duché »

C'est plutôt rare de trouver une occurrence du mot "iceluy" (ou plutôt icelui pour le CNRTL). Il faut bien que la langue évolue, alors des mots disparaissent, et d'autres se forment.

Tant mieux, tant pis.