Que faire lorsque l’on perd sa SUICA

Cet article ne va concerner qu’un nombre réduit de personnes, à savoir les francophones résidant au Japon, puisque comme l’indique le titre il explique ce qu’il faut faire lorsque l’on perd sa carte SUICA. Mais cela me donne l’occasion de rédiger quelque chose, ce que je n’ai pas fait depuis trop longtemps. Avec de la chance il servira à quelqu’un arrivé ici après une recherche Google.

Par égard pour ceux qui continuent à lire alors qu’ils ne sont pas concernés, je vais préciser que la carte SUICA est une carte à base de RFID utilisée dans certaines parties du Japon (je ne sais pas lesquelles, je sais juste qu’à Nagoya je ne pouvais pas l’utiliser car les machines ne connaissaient que le PASMO) et servant notamment de titre de transport. On peut y ajouter de l’argent grâce à des bornes et ainsi payer son transport simplement en passant les portiques, ou l’utiliser pour payer dans les combini ou même aux distributeurs de boissons (une race dominante, qui semble tolérer la présence des humains). En cela c’est une version réussie du Moneo. On peut également l’utiliser comme support pour son abonnement, le commuter pass, ce qui est tout de même autrement plus pratique qu’un billet magnétique dont l’espérance de vie pour un usage quotidien est probablement très inférieure à la durée de l’abonnement. En cela c’est un équivalent du Pass Navigo.

Il y a deux semaines j’ai donc égaré cette carte, et si je n’étais pas trop ému à l’idée de ne plus revoir le millier de Yens que je me souvenais avoir dessus, j’étais déjà beaucoup plus triste pour mon abonnement de six mois que je venais tout juste de renouveler. Après avoir attendu quelques jours avec l’espoir de remettre la main dessus ou que l’on me contacte pour me prévenir qu’elle avait été retrouvée (mes coordonnées étant présentes dessus ; on n’est pas obligé de les indiquer il me semble), j’ai finalement fait le deuil de cette idée et me suis rendu dans un bureau JR (Japan Railway) afin de faire une nouvelle carte.

Là j’ai dû remplir un formulaire de demande et présenter ma carte de gaijin, que le guichetier a utilisés pour retrouver mes références dans sa base de données et finir de remplir le formulaire, et me suis vu remettre un coupon magnétique à apporter le lendemain pour obtenir une nouvelle carte. Deux jours plus tard — car le lendemain j’étais bien trop occupé à tester quelques grands huit — je suis donc allé au même bureau, où il m’a effectivement suffit de donner ce coupon et montrer à nouveau ma carte de gaijin pour récupérer, moyennant 1000 Yen (si j’ai bien compris : 500 pour la carte comme d’habitude, et 500 de frais), une nouvelle SUICA avec mon abonnement ainsi que la quantité de crédit que je me souvenais à peu près avoir.

En bref, si vous perdez votre carte SUICA mais que vous aviez indiqué vos coordonnées (il me semble que cette condition est obligatoire), la mésaventure ne vous coûtera que 1000 Yen et les frais de transport que vous aurez pendant ce temps, ainsi que deux visites au guichet.

Maxime

Hier j’ai fait la connaissance de Maxime. Il devait être pas loin de huit heures du soir, je marchais dans les rues du 13ème arrondissement de Paris, en plein quartier chinois, cherchant du regard une boutique qui proposerait des services d’encadrement, quand j’ai entendu un voix discrète sur ma gauche qui tentait timidement de m’interpeler.

C’était un jeune homme qui se tenait assis sous un petit porche. N’ayant pas compris sa phrase, quoi que me doutant un peu du contenu, je lui fais répéter. « Vous n’auriez pas une pièce ? » « Peut-être. » Je fouille dans mon porte-feuille tout en entamant la discussion. Il semble particulièrement jeune : des traits bouffis de fatigue sur un visage de lycéen.

Maxime a 20 ans. Il n’est bien sûr aucunement qualifié, et ce d’autant moins qu’il a pour seul diplôme un BEP. Il est à la rue depuis octobre ; presque un an, en attente d’une place dans un foyer, mais ça n’avance pas. Pas de famille, pas de potes, et puis au bout d’un moment on ne peut pas abuser de l’aide des gens. D’ailleurs son compagnon d’infortune, que je n’ai pas rencontré mais dont il m’a parlé, en a payé le prix : à lui rendre service il s’est retrouvé lui aussi à la rue. Il est le plus âgé des deux : 21 ans.

Je lui demande comment ils dorment, comment ils se douchent… Dormir, c’est ici ou là, dans la rue, à même le sol. Ils n’ont pas de sac de couchage ou de tapis de sol, car ça pose des problèmes de posséder de l’équipement quand on n’a pas de chez soi. Alors dormir est un bien grand mot : c’est une somnolence de quelques heures. Ceux qui ont déjà dormi sur du bitume le savent bien. La toilette se passe au Mac Do ou autre endroit du genre. Pour les douches ils ont essayé les bains public, mais la description qu’il m’en donne suffit à me faire comprendre pourquoi ils n’y retournent pas. Ils ne connaissent pas de squat ; ils ont déjà fréquenté des gens, mais avec la drogue ils ont préféré s’éloigner. Ses propos transpirent l’humilité et l’intégrité.

Alors ils économisent jour après jour afin de pouvoir s’offrir une nuit d’hôtel une fois de temps en temps. C’est le seul moment où ils peuvent recharger leurs batteries dit-il. Là ils peuvent dormir, prendre une douche. Mais l’hôtel c’est cher, et lui n’arrive à faire qu’une dizaine d’Euros par jour, « Alors 20 Euros, sa phrase est restée en suspend, 20 Euros c’est trop ». Pourtant quand on travaille, 20 Euros ça représente au plus à peine deux heures de travail. Mais comment travailler dans cette situation ?

Je lui demande quelle est la dernière fois qu’il a travaillé : un chantier, en février. Mais le patron a fini par lui faire arrêter, s’inquiétant de sa santé avec l’hiver. Et pour trouver du travail, il faut un CV, un téléphone… Pendant la discussion un asiatique est passé rapidement, lui annonçant sans lui promettre que c’était peut-être bon pour demain. Un plan pour une carte SIM. « C’est sympa, il n’est pas obligé de nous aider comme ça. » Et puis tout coûte cher : pour faire un CV, etc.

En deux mots, à un âge où ils devraient être à l’université ou apprentis sur un chantier, ils sont dans une merde noire.

« Je peux te proposer un lit et une douche, pour un jour ou deux.

– Mais y a mon pote…

– Je peux vous proposer deux lits et une douche.

– Ouais mais je veux pas vous gêner…

– Honnêtement ça me fait encore plus chier de te voir dans la rue. »

Son expression ne laisse aucun doute sur l’idée de pouvoir dormir sous un toit, mais ils ont déjà eu de mauvaises expériences semble-t-il sous-entendre, alors il va voir avec son pote quand ils se retrouveront. Je lui laisse un numéro où me rappeler. Je n’ai pas eu de nouvelle depuis. Peut-être ont-ils préféré ne pas faire confiance, peut-être n’ont-ils pas osé, peut-être un peu de tout ça. Peut-être aussi ont-ils eu une autre galère et n’ont pas pu me joindre. Je repasserai à l’occasion prendre des nouvelles.

Maxime est facile à trouver : il est toujours sur la rue d’Ivry, pas très loin de la rue Tolbiac. Il ne sait pas que j’ai écrit ceci, mais si vous pensez pouvoir l’aider, passez donc lui rendre visite. Ma conviction est qu’ils n’ont rien à faire là, croulant sous la fatigue et pourtant inactifs, quand ils devraient jouer un tout autre rôle dans la société. Mon impression est qu’il faudrait finalement assez peu de chose pour les sortir de là, mais que c’est absolument hors de portée sans une aide extérieure : un lit, un repas, un travail (à ce stade autant dire que même une très courte durée serait bien venue)…  Si vous avez cela, merci pour eux.

You'll need to download Flash^WSafari to view this demo

D’habitude lorsque j’entends parler de HTML 5, je me réjouis. Pourtant aujourd’hui j’ai l’impression d’être pris pour le dernier des imbéciles, et comme mon ego est délicat, je n’aime pas être pris pour un imbécile.

Il y a peu, Apple et Adobe faisaient la une de la presse technologique avec leur roman « Je t’aime, moi non plus » à grand coups de lettres ouvertes et autres coups de couteau dans le dos. Au point de départ de ce divorce consommé, l’absence de Flash revendiquée sur les plateforme iPhone et surtout, iPad. Bien que comme beaucoup de programmeurs je n’aime pas Flash, plusieurs arguments de Steve Jobs pour justifier ce refus d’intégrer cette technologie me semblent fallacieux. Toutefois, je ne peux être que d’accord sur le fait que c’est une technologie fermée et qui n’est pas nécessaire lorsque l’on supporte le HTML 5.

Mais aujourd’hui je découvre que Apple présente une page avec des exemples de HTML 5… qui se contentent sous Firefox d’afficher « You’ll need to download Safari to view this demo. »

Vous savez quoi ? Je retrouve ici l’une des raisons pour lesquelles je n’aime pas le Flash. J’ai l’impression de lire « You’ll need to install Flash to view this website. » alors que mon navigateur est déjà parfaitement fonctionnel (et parle le HTML 5). Alors si j’ai bien suivi, Flash c’est fermé c’est mal. HTML 5 c’est standard c’est bien. Mais vous devez téléchargez notre navigateur pour en profiter, n’allez surtout pas croire que les autres fonctionnent correctement.

Rien à faire, j’ai vraiment l’impression d’être pris pour un imbécile par Apple.

Le graphiste

Entre le jeu vidéo et le développement d’applications plus classiques j’ai eu l’occasion de travailler avec un certains nombre de graphistes, et de remarquer comme certains traits se retrouvent souvent chez cette espèce. Aujourd’hui j’ai envie de me faire plaisir, et de vous raconter : le graphiste.

À ceux qui ne me connaissent pas, mon métier est programmeur. Si vous ne situez pas ce que c’est, je vous renvoie à cette phrase d’un game-designer de Blizzard qui résumait la création d’un jeu vidéo :

Programmers make the game run, artists make it beautiful, but it is the designer’s job to make it fun.

Les programmeurs font marcher le jeu, les graphistes le rendent beau, mais c’est au game-designer de le rendre sympa.

En tant que programmeur, on peut être amené à beaucoup communiquer avec des graphistes, et c’est amusant car ce sont deux espèces qui n’ont pas la même apparence, pas la même culture, pas la même approche et qui ne parlent pas la même langue. :-)

Le graphiste se reconnaît d’abord à son allure. Alors que la tenue vestimentaire du programmeur évolue plutôt depuis le jean et teeshirt lorsqu’il est jeune diplômé, vers un habillement dit classique à l’approche de la trentaine, pantalon de ville et chemisette avec peut-être encore quelques référence à la culture geek, le graphiste au contraire est tout droit sorti d’une affiche publicitaire. Coupe de cheveux tendance, pantalon décontracté à la découpe moderne, attributs corporels divers : bracelets, piercings, éventuellement paire de chaussures hors du commun, etc. Attention, ce n’est pas du punk brutal : c’est plus subtil et sophistiqué, même si c’est parfois proche du personnage de jeux vidéos.

Ensuite le graphiste à besoin d’un environnement très particulier pour travailler. Outre la tablette graphique, on reconnaît sans hésitation son bureau à l’écosystème qui s’y est rapidement développé : affiches, Nintendo DS et boites de jeux vidéos, livres d’artworks, feuilles de brouillon avec des dessins esquissés (souvent de grande qualité), figurines et autres objets improbables en nombre et tailles variées (qui peuvent aller jusqu’au dragon de 30cm d’envergure posé sur l’écran). Le graphiste a en effet besoin d’une sollicitation visuelle importante pour être productif.

La salle du groupe de graphiste est normalement bruyante ; c’est ce qui la rend parfaitement incompatible avec l’environnement du programmeur. Le graphiste a besoin d’un flux continu de conversations pour pouvoir travailler. Séparez un graphiste de son groupe pour le mettre dans le bureau austère et silencieux (selon des critères de graphiste) des programmeurs et il va vite montrer des signes de dépression. Mettez au contraire un programmeur dans la salle des graphistes et il ne pourra tout simplement plus travailler du tout.

Le chef des graphistes se reconnaît à la taille de son écran. Son titre est D.A. : il est craint et respecté. Beaucoup rêvent d’être lui car c’est lui qui décide de l’orientation du style graphique, et c’est quand même plus sympa que de faire des textures d’herbe à longueur de journée.

Comme pour les chasseurs, en terme de talent, il y a le bon graphiste et le mauvais graphiste. Quand le bon graphiste vient vous poser une question tout en s’occupant les mains avec une feuille qui traîne sur votre bureau, la feuille termine au mur de votre bureau. Si par chance vous êtes un programmeur très sollicité par un bon graphiste, rapidement les autres programmeurs deviennent jaloux de votre mur. Quand le mauvais graphiste vient vous voir, vous vous retenez de lui expliquer que son animation de personnage qui court est complètement ratée parce que ça ne servirait à rien.

Le graphiste parle une langue différente. Le graphiste expérimenté utilisera sans pitié des termes techniques de typographie ou de composition. Dans un tel cas soit vous vous serez déjà documenté sur le sujet, soit vous aurez affaire à un graphiste pédagogique, soit vous serez largué. Le graphiste peu expérimenté mettra à peu près tout et n’importe quoi derrière une liste relativement courte de mots tels que « flou », « shader », « glow »… et vous aurez toutes les peines du monde à comprendre ce qu’il essaie de vous dire en graphiste. De temps en temps le graphiste essaiera de vous emprunter votre vocabulaire technique mais pour y mettre d’autre chose, et vous devrez penser à traduire.

Le graphiste est étranger à l’idée de système de gestion de versions. C’est normal qu’il ne connaisse pas : les outils de production ne sont pas son domaine de compétence. Mais là je ne dis pas qu’il ne connaît pas, j’insiste sur le fait qu’il y est étranger. Vous aurez beau lui expliquer le principe, le fait que ça permet de retrouver n’importe quelle version précédente d’un fichier pour lui éviter d’avoir à s’en préoccuper, lui montrer comment on s’en sert : vous trouverez régulièrement sur votre dépôt des fichiers texture_backup.png et texture_backup2.png. Vous verrez également fleurir des fichiers créés automatiquement tels que les thumbs.db de Windows, lorsque le graphiste aura tout ajouté automatiquement sans vérifier.

Le graphiste n’accorde d’ailleurs pas la moindre importance aux noms de fichiers et sera incapable de respecter toute règle de nommage quelle qu’elle soit. Le nom d’un fichier créé par ses soins est fonction de son inspiration du moment, et a de fortes chances de changer s’il doit un jour apporter une modification. Vous verrez donc facilement un fond.png à côté d’un background.jpeg et d’un bg_bleu.png, qui seront en fait la même ressource. Il faut être attentif. Souvent c’est votre projet lui même qui vous signalera les nouveautés, non pas parce que vous verrez de nouvelles choses apparaître, mais parce que vous verrez apparaître des choses qui ne marchent pas. Expliquez lui qu’il lui suffit de placer un objet nommé « mine » dans le monde pour avoir une mine créée à cet emplacement, et vous trouverez rapidement tout un tas de « Mine », « mines », « mine1 », « mine_bleue » et autres preuves de créativité. Oubliez l’idée d’essayer de lui expliquer que l’outil d’import ne peut pas deviner ce qu’il voulait faire : faire un outil d’import qui devine ce qu’il voulait faire vous prendra moins de temps. C’est la conclusion à laquelle je suis arrivé en voyant un de mes collègues essayer l’une, puis l’autre méthode.

Le graphiste n’accorde pas non plus d’importance à l’aspect technique. En cela que ce n’est pas son travail, je le soutiendrais entièrement, s’il avait des outils lui permettant de s’abstraire de cet aspect. Mais ce n’est pas le cas : ses outils lui permettent d’exporter dans un luxe possibilités de formats parmi lesquels le choix risque fort d’être arbitraire. Le graphiste vous sortira sans problème une photo en PNG, un aplat en JPEG, des images monochromes en RGBA et des textures dans des résolutions absolument obscènes aux limites techniques des cartes graphiques pour des éléments qui ne feront que quelques pixels à l’écran. Paradoxalement, il pourra vous enseigner malgré lui des détails techniques fort intéressants sur ces formats. C’est par exemple quand un graphiste m’a envoyé une image au format PNG de près de 1Mo pour moins de 500 par 500 pixels que j’ai découvert que ce format gérait les calques : le fichier contenait les dix versions de l’image…

La rigueur dans le positionnement des éléments est étonnamment fluctuante chez le graphiste. Lors de la création d’une interface un peu jolie par exemple, il appartient au graphiste de faire les différentes version d’un bouton (normal, appuyé, sélectionné…) ou d’une fenêtre (active, en arrière plan…) pour ne citer que ces éléments. Les différentes versions venant s’afficher au même endroit selon l’état de l’élément. Naturellement en tant que programmeur, il vous semblera évident que ces versions doivent être calées au pixel près. Si vous travaillez avec un graphiste qui fait des éléments de la même taille et correctement alignés, prenez en soin, c’est un spécimen rare.

Mais à l’inverse, si le graphiste imagine un élément textuel et vous propose un exemple réalisé avec Photoshop, que les astres vous protègent si vous n’avez pas les moyens techniques de reproduire le résultat exactement à l’identique ! L’affichage de texte est d’ailleurs un thème de désaccord très récurrent entre graphistes et programmeurs. Lorsque le graphiste doit imaginer un élément textuel, il se transforme en maquettiste : les images viennent s’agencer et s’aligner autour pour un résultat le plus esthétique possible. Malheureusement il oubliera immanquablement de tenir compte de l’aspect dynamique de ce texte, à l’instar de sa composition. Qu’il s’agisse d’un compteur et il vous proposera un exemple avec deux chiffres qui ne marchera plus avec un ou trois chiffres, ou pire, il vous dessinera des chiffres ne feront pas tous la même largeur, donnant un résultat atroce une fois animé. Qu’il s’agisse de mots, et vous pourrez lire dans ses yeux toute la frustration du monde lorsque vous lui rappellerez que dans la version allemande son texte sera trois fois plus long et ne rentrera pas dans l’espace qu’il a prévu.

Mais pour le coup, dans ce cas là vous pourrez pleurer avec lui d’en être réduits à faire un truc moche et aller noyer votre chagrin ensemble dans le pub en bas du bureau.

Que retenir de "Bourne Into Oblivion" ?

#rm -rf /On m’a fait lire hier un article, « Bourne Into Oblivion« , dans lequel l’auteur explique comment ce qu’il nomme une bombe à retardement a eu des conséquences gravissimes pour le système informatique d’une société. En résumé, un script d’administration faisait le ménage après avoir terminé sa tâche grâce à un rm -rf $var1/$var2. Mais ce script s’est vu exécuté avec $var1 et $var2 non définis, et s’est donc terminé avec un rm -rf /, en root, sur un NFS (pour les non unixiens, cela signifie effacer l’intégralité des systèmes de fichiers du réseau, avec le droit de le faire). Autant dire que c’est une catastrophe sans nom pour la société, surtout lorsque l’on ajoute que c’est à ce moment que les backups se révèlent être inutilisables.

Cette histoire qui ferait froid dans le dos à tout administrateur système m’a plongé dans une réflexion, que voici, sur la liste finalement assez importante d’erreurs ayant conduit à cet accident. Le but n’est pas de critiquer, mais de voir ce qu’il est possible d’apprendre de tout cela.

Tout d’abord, il est clair que ce script était exécuté avec des privilèges bien trop importants. Il n’y a que peu de choses qui puissent justifier qu’un script doive être lancé en tant que root. Il aurait dû être lancé en tant que simple utilisateur sans privilège, éventuellement avec un compte créé spécialement dans ce but. Les opérations nécessitant réellement des droits de super utilisateur auraient dû être isolées et appelées avec un sudo ou encore disposer d’un bit suid. Pour le reste, et notamment tout ce qui s’apparente à de la lecture, des droits correctement affectés avec des groupes auraient dû suffire. D’une façon générale lancer un script en root n’est absolument pas anodin, et au delà du problème rencontré ici, se pose celui de la possibilité d’une faille de sécurité.

L’article mentionne de plus le fait d’avoir lancé un script pour le week-end, autrement dit pour une durée d’exécution a priori relativement longue. Si le fait de laisser une tâche d’administration sans surveillance est courant, le fait que ce soit en tant que root change la donne et vient aggraver, s’il était besoin, le point précédent.

La justification de l’exécution en tant que super utilisateur mise de côté, ce bout de script n’était manifestement pas assez défensif étant donné ce contexte particulièrement dangereux. Son auteur n’aurait jamais dû laisser un tel appel se faire sans un test des deux variables. Cela dit le script n’était peut-être pas prévu à l’origine pour être lancé en tant que root, ce qui amène donc à considérer comme règle qu’un code faisant ce type de manipulation doit être défensif quoi qu’il arrive, dans la mesure où l’on ne sait pas dans quelles conditions il peut-être amené à être utilisé par la suite.

On peut de plus remarquer que le fait d’utiliser un répertoire à la racine est déjà discutable. Si cette remarque peut sembler être un pinaillage purement cosmétique, on s’aperçoit que si en pratique les répertoires utilisés avaient été /tmp/$var1/$var2 ou encore /usr/src/$var1/$var2 par exemple, un tel drame ne serait pas survenu.

Pour finir sur l’aspect purement administration, ce script aurait dû être documenté. D’après l’article, l’absence de définition des variables est la conséquence du fait que l’opérateur ne savait pas qu’il y avait des opérations à effectuer au préalable. Ce point aurait donc dû être documenté. Cependant l’expérience montre que documenter n’évite pas les accident, et reste donc insuffisant (d’ailleurs le script était peut-être même déjà documenté) : j’ai l’exemple d’un script qui servait à envoyer un mail informatif à une base d’utilisateurs, et qui portait le nom pour le moins clair de spam.sh. Il avait pourtant fallu commenter la commande essentielle du script depuis que quelqu’un l’avait lancé par erreur, n’ayant apparemment pas considéré son nom comme un avertissement suffisamment clair sur l’effet du script. Un autre exemple amusant est le message d’avertissement du système Debian en cas de apt-get jugé un peu trop violent : il demande alors de taper en toutes lettres « Oui, faites ce que je vous dis ! ». Quoi qu’il en soit, il faut d’une façon ou d’une autre, mais par un moyen technique, mettre une commande dangereuse hors de portée de toute personne qui n’est pas parfaitement renseignée.

Accessoirement, Joel Spolsky explique au deuxième point de son célèbre article, « The Joel Test« , que d’après lui l’opération de compilation et livraison d’un projet doit pouvoir être faite en une seule action, car toute étape supplémentaire entraîne la possibilité d’une erreur. L’erreur dont il est question ici et les conséquences qu’elle a eu montrent que finalement, la règle peut être étendue à toute opération d’administration.

D’autres erreurs, de nature plus humaine, sont également à l’origine de cet accident. Comme le souligne l’auteur de l’article, le passage de compétences ne s’est pas fait correctement par exemple, et la gravité de la tâche d’administration a été négligée en étant affectée à un novice. Je ne m’étendrai pas plus sur ce sujet, qui n’est plus celui de ma réflexion.

Aussi pour conclure, on se rend compte que cet incident, qui est extrêmement grave pour une société puisqu’il peut lui être fatal si les données ne sont pas récupérées, aurait pu être évité par de simples précautions. Pour la plupart d’entre elles, une seule de ces précautions aurait suffit à éviter cela. Mais peut-être que parce que ces précautions semblent dérisoires, elles sont négligées. Paradoxalement elles semblent tellement évidentes que les rappeler peut également paraître dérisoire.

Voilà en substance la réflexion que m’inspire cette histoire. N’ayant pas la prétention d’avoir plus de quelques notions d’administration système, je suis peut-être passé à côté de points importants. Si vous en voyez, n’hésitez pas à en faire part en commentaires.