Carnet de notes

Catégorie : Technique

  • Please stop preten­ding PHP is a good language

    The first step to fixing a problem is admit­ting that there is one.

    Bon, des critiques de PHP ce n’est pas ce qui manque mais pour une raison incon­nue je m’étais dit que ça partait bien quand j’ai lu la première ligne. Sauf qu’au final…

    • It’s not ok that you can’t relia­bly get the first element of an array using less than 4 lines of code without causing side effects.*[1]
    • It’s not ok that the output of echo 5/3 might depend on the coun­try you live in if you don’t know the fine details of confi­gu­ring PHP.
    • It’s not ok that you won’t be able can’t call array_map” or just “$itera­tor->reduce” on an itera­tor in 2014.
    • It’s not ok to ignore the simple fact that most of the PHP world currently relies on parsing func­tion and class comments for it’s code to func­tion because people can’t get their shit toge­ther on mailing lists.
    • It’s not ok to run around shou­ting “type hinting for lite­rals would mean that passing an int to float hint would fatal PHP” and calling that an reaso­nable argu­ment while people just write $x = (float)$x; in the cases where it actually does matter anyways.
    • It’s not ok to be not able to talk to 2 back end data sources in paral­lel, using “promises” or whate­ver, in a language that has “pull stuff out of data­base and put it into the inter­net” as a proclai­med core compe­tency.
    • It’s not ok that echo 0.000001; produces 1.0E-6 and that casting it to string doesn’t help but putting quotes around it does.
    • It’s not ok that you have to clear the error buffer by gene­ra­ting a suppres­sed unde­fi­ned variable error just to be able to sanely use token_get_all().

    Au final la moitié des items ressemblent juste à « ça ne fait pas ce que j’es­père ». Alors pour ceux qui m’ont fait suivre le lien :

    Pour le premier item il existe plusieurs solu­tions, dont un simple array_values($tab)[0]. Bref, rien d’ex­cep­tion­nel pour aller itérer sur un diction­naire.

    Pour le second, si on demande expli­ci­te­ment au niveau du système à affi­cher les résul­tats suivant les conven­tions d’un pays spéci­fique, PHP s’y conforme. C’est le cas de la plupart des langages, y compris la ligne de commande de base. Diffi­cile d’avan­cer que c’est un problème, d’au­tant qu’il est bien évidem­ment possible d’igno­rer la confi­gu­ra­tion du système pour forcer une locale au niveau du langage.

    Quant à savoir comment affi­cher 0.000001 ou 1E-6, comme le langage n’a aucun moyen de savoir comment a été tapé la valeur initiale dans le code source (rien de spéci­fique à PHP, à ma connais­sance aucun ne le fait), il faut bien qu’il choi­sisse une forme arbi­trai­re­ment à la sortie. Si l’au­teur veut forcer autre chose, il a tous les outils pour ça.

    Pour le dernier item j’ai la flemme de véri­fier les cas limites mais à priori c’est juste que l’au­teur n’a pas eu le courage d’al­ler créer un gestion­naire d’er­reur pour gérer ses erreurs.

    Bref, tout ça c’est bien joli mais à première vue une bonne partie n’est qu’un problème de déve­lop­peur frus­tré, pas un problème de langage.

    Ce qui me frustre moi c’est que des problèmes de langages il y en a plein, et que pous­ser des faux problèmes décré­di­bi­lise ceux qui essayent de corri­ger les problèmes réels.

  • Bonnes pratiques API – les fichiers

    J’ai eu la chance d’échan­ger autour des API à trois confé­rences récem­ment. Les sujets ont été globa­le­ment les mêmes mais sous des angles diffé­rents.

    Mes réflexions avancent suite aux discus­sions et aux diffé­rents retours. Main­te­nant c’est à moi de travailler un peu pour ordon­ner tout ça et le retrans­crire quelque part.

    Entre temps je mets en ligne mes notes et mes présen­ta­tions pour ceux que ça inté­resse.

    Je vous recom­mande surtout les notes et la présen­ta­tion Paris-Web comme premières lectures. Norma­le­ment les trois présen­ta­tions ont été enre­gis­trées en vidéo, vous devriez les retrou­ver sur les pages des diffé­rents événe­ments le temps que le montage soit terminé (mais en géné­ral ça prend du temps).

  • Paris web en une anec­dote

    Il y a quelques minutes : Ques­tions réponses après une confé­rence tech­nique qui débor­dait sur l’éthique, sur l’in­te­rac­tion entre la tech­no­lo­gie et notre monde.

    À deux langues de distances, l’ora­teur à une confé­rence tech­nique répond à une ques­tion d’un malen­ten­dant. Inter­prète LSF-français, traduc­tion français-anglais, en direct. Même chose dans l’autre sens.  Au-dessus défile un sous-titrage auto­ma­tique de tout ce qui est dit, le tout (audio, vidéo, sous-titrage) trans­mis en direct sur le web.

    Parler d’ac­ces­si­bi­lité est une chose, le faire en est une autre.

    Si je dois résu­mer ce qui a été créé à Paris Web et que je ne retrouve nulle part ailleurs, même en dehors de nos fron­tières, je crois que ce sont ces quelques minutes qui l’ex­priment le mieux.

  • Forte baisse des salaire en raison de la pénu­rie d’in­for­ma­ti­ciens

    Remix Jobs relance la polé­mique sur la mythique pénu­rie d’in­for­ma­ti­ciens. Les mêmes rengaines arrivent chaque année entre juin et septembre. Cette fois ci, une semaine après, on voit dans la presse « Forte baisse des salaires à l’em­bauche en SSII ».

    Je n’ar­ri­ve­rai pas à comprendre comment on peut consi­dé­rer qu’il y a tension au recru­te­ment tout en faisant bais­ser les salaires. Ce n’est pas tant que les infor­ma­ti­ciens soient mal payés – ils ne le sont pas – mais les salaires d’autres pays sont bien plus haut, donc logique­ment la diffi­culté de recherche devrait faire monter les salaires au moins au niveau des voisins.

    Et qu’on ne se trompe pas, si la propor­tion des expé­ri­men­tés passe en dessous du tiers pour les nouvelles embauches, ce n’est pas qu’ils sont rares, c’est que personne n’a envie de payer pour l’ex­pé­rience avec autant de jeunes diplô­més sur le marché.

    Métier mal consi­déré, loca­tion de person­nel (majo­rité des embauches en SSII), salaire en baisse, déve­lop­peurs français recon­nus comme bons et mieux payés à l’étran­ger, déva­lo­ri­sa­tion du déve­lop­peur avec plus de cinq ans d’ex­pé­rience (« il aurait du passer chef de projet »)… il ne faut pas s’éton­ner que certains claquent la porte des recru­teurs français.

  • Vive la trans­la­tion du jargon

    J’ai cher­ché comment traduire « commit » dans le contexte d’un contrôle de versions type git ou subver­sion. J’ai eu quelques propo­si­tions qui peuvent permettre de construire des phrases au cas par cas, mais aucun terme vrai­ment éclai­rant et géné­rique.

    Mais surtout je me suis heurté à pas mal de réac­tions concer­nant l’idée même de traduire le terme.

    Fran­che­ment je ne cherche pas à « défendre la langue française ». Elle va très bien, merci pour elle, et surtout elle ira d’au­tant mieux qu’elle restera vivante et s’au­to­ri­sera à impor­ter des termes étran­gers. Il est d’ailleurs amusant de voir de temps en temps de la résis­tance à impor­ter un terme anglais… qui est en fait un terme français qui a été importé outre-manche ou outre-atlan­tique il y a bien long­temps. Bref, là n’est pas la ques­tion.

    Ma petite histoire

    C’est Eyrolles qui m’a pas mal ouvert les yeux sur l’uti­lité d’une traduc­tion. À l’époque de la rédac­tion de mon livre sur PHP, ils nous ont imposé de cher­cher au maxi­mum des traduc­tions.

    • Premier constat : Quand on cherche, le plus souvent, on trouve un terme français qui corres­pond très bien.
    • Second constat : Le plus souvent même ceux qui n’uti­lisent que les termes anglais ne remarquent même pas qu’il y a eu effort parti­cu­lier de traduc­tion.

    Tout le monde utilise thread, parser, template, tag… mais fina­le­ment un fil de discus­sion ou d’exé­cu­tion, un moteur ou un analy­seur syntaxique, un gaba­rit, une balise ou une étiquette, ça fonc­tionne très bien aussi. En fait ça fonc­tionne même mieux, avec une lecture bien plus fluide quand bien même les termes sont rare­ment fran­ci­sés dans le contexte infor­ma­tique.

    Il m’a ainsi fallu pas mal de volonté pour faire un chapitre sur les gaba­rits de pages HTML en PHP. Damned, j’ai résisté et voulu écrire « template » jusqu’au bout. Je me demande même si nous n’avions pas fini sur un compro­mis en lais­sant « template » dans le titre de chapitre en crai­gnant que « gaba­rit » ne soit pas immé­dia­te­ment compris. Sauf qu’au final je suis bien content de l’avoir fait ce chan­ge­ment.

    Abra­ca­da­bra

    J’ai vu trop d’in­for­ma­ti­ciens utili­ser les termes anglais comme des formules magiques. J’ai même eu plusieurs discus­sions à l’époque du choix de « gaba­rit » où on m’a expliqué qu’un « template » c’était diffé­rent parce que [insé­rez ici une conno­ta­tion imagi­naire]. Moins mon inter­lo­cu­teur avait de recul sur ce qu’il mani­pu­lait et de compré­hen­sion du fonc­tion­ne­ment, plus il était atta­ché au terme anglais. Cette consta­ta­tion n’a jamais été démen­tie (atten­tion à ne pas vous vexer : je ne prétends pas que la réci­proque est vraie).

    Si je tiens au français, c’est juste­ment pour parler français et pour ne pas utili­ser de termes formules magiques où chacun y met son propre imagi­naire. Ça permet de norma­li­ser le discours, de lais­ser prendre du recul à ceux qui sont trop habi­tués à copier sans comprendre, et de parler du fonc­tion­ne­ment plus que d’une série d’ou­tils et de commandes.

    Comme la plupart des infor­ma­ti­ciens, j’ai beau­coup tendance à utili­ser l’an­glais dans mon jargon. J’ai toute­fois pu noter de réelles diffé­rence d’im­pact et de compré­hen­sion dès que je fais l’ef­fort d’uti­li­ser des termes français. Et cette faci­lité d’échange ne concerne pas que les débu­tants : Je la constate aussi face à des habi­tués du terme comme de la tech­nique qu’il recoupe. À vrai dire plus la personne en face a du recul et de la compré­hen­sion, plus on peut parler de ce qu’il y a derrière et autour et plus la langue utili­sée est un détail.

    À l’usage

    Seule l’ha­bi­tude fait un peu résis­tance, mais pas tant que ça. En fait tout l’enjeu c’est de trou­ver un terme qui sera immé­dia­te­ment compris sans réflé­chir par un natif fran­co­phone, même par celui qui n’uti­lise que le terme anglais dans sa vie profes­sion­nelle. Très souvent on trouve, et si extrê­me­ment peu de mes corres­pon­dants parle­ront eux-même de fil d’exé­cu­tion, aucun ne tique quand je le fais.

    Il reste quelques termes diffi­ciles à traduire. Le plus souvent ce sont des termes qui ont déjà été détour­nés de leur sens usuel en anglais. Forcé­ment, trou­ver un terme français revient aussi souvent à le détour­ner de son sens usuel… et là ça coince. À l’écrit, quand ça arrive, je tente de forcer un peu le terme français s’il me semble viable, quitte à mettre le terme anglais en paren­thèses à la première occur­rence.

    Et quand rien ne va ? et bien j’uti­lise l’an­glais, ça me va aussi très bien. Fuck à l’Aca­dé­mie Française qui créé un nouveau mot complè­te­ment déli­rant par volonté abso­lue de ne pas utili­ser l’an­glais. Ce n’est pas ma moti­va­tion. Par contre j’en arrive là après une recherche sérieuse, avec l’aide de ceux qui le veulent.

    Et pour « commit » alors ? Après un nombre impor­tant de contri­bu­tions sans aucune suffi­sam­ment claire et géné­rique – de mon avis person­nel – Karl a proposé le simplis­sime « enre­gis­trer ». Ça ne plaira peut être pas aux puriste, mais j’ai l’im­pres­sion que ça colle parfai­te­ment à pas mal de sens qu’on donne à « commit », et que je trou­ve­rai bien les termes pour les quelques sens manquants avec les notions de version et tran­sac­tion. Ceci dit ça reste un sujet ouvert pour moi.

  • Bases de données en master – master

    J’ai cher­ché de quoi stocker des données avec plusieurs serveurs maîtres en répli­ca­tion, mais je n’ai rien trouvé d’in­té­res­sant pour l’ins­tant. Je me suis dis que toi, fidèle lecteur, tu pour­rais appor­ter ta pierre. D’au­tant qu’il me semble que c’est une problé­ma­tique courante, au moins pour les améri­cains qui doivent avoir des serveurs sur les deux côtes, synchro­ni­sés entre eux.

    Fonc­tion­nel­le­ment

    J’ai des visi­teurs qui vont accé­der en lecture, en écri­ture ou en modi­fi­ca­tion à des données. Ces visi­teurs peuvent être répar­tis géogra­phique­ment et j’ai­me­rai que dans la mesure du possible, ils puissent accé­der à leurs données rapi­de­ment. Par rapi­de­ment j’en­tends « sans avoir à payer 100 à 200 ms de latence pour joindre un serveur de base de données sur une autre côte ou sur un autre conti­nent ».

    Là où j’ai de la chance, c’est qu’une même données ne sera crée, modi­fiée ou lue que par un seul utili­sa­teur (ou presque). Cet utili­sa­teur sera donc le plus souvent au même endroit, donc je peux répar­tir mes données en consi­dé­rant qu’un seul serveur est maître sur chaque données. Dans mon esprit ça veut dire que ce sera rapide (données proches) 90% du temps et lent (serveur maître loin) les 10% du temps restant si l’uti­li­sa­teur navigue géogra­phique­ment. Par contre il faut que lors de la créa­tion d’une donnée, je puisse choi­sir quel serveur sera le maître pour la donnée en ques­tion (pas de répar­ti­tion auto­ma­tique par hachage de clef puisque le maître est choisi en fonc­tion de la proxi­mité géogra­phique).

    Histoire de complé­ter : J’ai assez peu de rela­tion­nel dans ces données et j’y accède quasi­ment toujours par leur clef primaire. Je suis prêt à utili­ser du SGBDR type MySQL, du clef/valeur type Redis, ou des inter­mé­diaires type MongoDB (bon, j’ai une préfé­rence pour du Redis, qui serait mon choix sans la contrainte multi-maître).

    J’ai des volumes qui vont repré­sen­ter plusieurs Go, entre 5 et 20 on va dire à vue de nez, non vola­tiles (donc j’ex­clue tout système qui ne permet pas de sauve­garde ou qui n’a pas de couche écri­ture disque). La perfor­mance est impor­tance lors des accès, mais je ne vais pas avoir un débit d’écri­ture phéno­mé­nal non plus. Je ne pense pas que ce soit le critère de choix prin­ci­pal.

    Enfin, je n’ai pas besoin d’écri­tures synchrones sur plusieurs serveurs. Je suis prêt à avoir une latence d’une ou plusieurs secondes avant de pouvoir accé­der à une nouvelle donnée (ou à une modi­fi­ca­tion) depuis un autre serveur que celui de sa créa­tion.

    Tech­nique­ment

    Beau­coup de solu­tions ont un mode maître-maître qui ne semble pas conve­nir à mon besoin, où les conflits peuvent être légion : Si un utili­sa­teur fait volon­tai­re­ment une opéra­tion sur une données à partir de plusieurs empla­ce­ments géogra­phique, je risque de ne pas pouvoir tracer ses diffé­rentes opéra­tions mais d’avoir au mieux la trace de la dernière. Sauf erreur de ma part, les bidouillages multi-maîtres MySQL et Post­greSQL entrent dans cette caté­go­rie.

    J’ai jeté un oeil à Redis-clus­ter, qui a l’air d’être assez proche de la philo­so­phie que je cherche (chaque donnée a un et un seul maître) mais c’est malheu­reu­se­ment avec une isola­tion complète, c’est à dire qu’au­cun noeud n’a l’en­semble des infor­ma­tions en lecture. J’y vien­drai s’il le faut, mais si je veux un fail-over correct ça veut dire qu’il faut que je double chaque noeud (le maître, puis son esclave en cas de défaillance). Je ne suis pas non plus certain de pouvoir choi­sir le maître à utili­ser lors de l’écri­ture.

    Je regarde Riak, CouchDB, RethinkDB, Tyrant, Volde­mort, Dyno­mite et quelques autres mais je manque cruel­le­ment de retours d’ex­pé­rience et d’in­for­ma­tions pour faire un choix éclairé, si tant est que l’un de ceux là puisse corres­pondre.

    J’ai aussi en tête de faire quelque chose à la main avec une logique appli­ca­tive par dessus le connec­teur Redis, pour qu’il se connecte au bon serveur en fonc­tion du premier carac­tère de la clef, mais j’ai­me­rai fran­che­ment éviter les bidouilles manuelle pour quelque chose qui doit certai­ne­ment avoir une solu­tion sur étagère.

    Dis, lecteur, as tu des liens, des retours d’ex­pé­rience, des infor­ma­tions, des commen­taires ?

     

  • Diffé­ren­cier le trafic pour créer de la valeur – le réseau auto­rou­tier

    Les jour­na­listes râlent encore sur l’en­com­bre­ment des réseaux auto­rou­tiers. Marron­nier. Évidem­ment il est hors de ques­tion d’aug­men­ter encore les tarifs des usagers.

    Vinci est créa­teur de 7500 emplois directs, les Auto­routes Paris-Rhin-Rhône plus de 4500, et ce ne sont que deux des conces­sion­naires du réseau auto­rou­tier. Tout ça fait vivre autant de personnes sur les commerces et sur l’éco­no­mie géné­rée aux alen­tours. C’est aussi par l’au­to­route que sont désen­cla­vées nombre de petites villes qui sinon dépé­ri­raient. Faut-il mettre tout ce monde au chômage sur l’au­tel d’un concept théo­rique ?

    Les asso­cia­tions se sont en effet oppo­sés à la segmen­ta­tion fine du trafic auto­rou­tier. Créa­teur de valeur pour les conces­sions d’au­to­route, ce système aurait pour­tant permis de géné­rer un revenu supplé­men­taire signi­fi­ca­tif.

    Merce­dez-Benz est en effet l’ori­gine de 20% du trafic auto­rou­tier poids-lourd à lui tout seul, le trafic le plus encom­brant pour le réseau. Le construc­teur profite sans gêne de nos infra­struc­tures pour vendre ses camions. Il est évident que les conces­sion­naires d’au­to­route ne peuvent pas conti­nuer à finan­cer seuls l’évo­lu­tion du réseau auto­rou­tier alors que les étran­gers qui y injectent du trafic n’y contri­buent en rien.

    La solu­tion tout le monde la connait : Faire du trafic diffé­ren­cié et canton­ner les véhi­cules de Merce­dez à la voie la plus à droite et à une seule file au barrières de péages. Le construc­teur devra payer l’opé­ra­teur auto­rou­tier pour un accès plus perfor­mant, et contri­buer ainsi au paie­ment des infra­struc­tures.

    Ce système vien­drait en renfor­ce­ment des offres à valeur ajou­tée pour les usagers : Des accès privi­lé­giés ont déjà été mis en œuvre via les télé­badges qui permettent de passer par des files prio­ri­taires dans les barrières de péage. On réflé­chit à étendre ce système pour permettre à des profes­sion­nels de sauter les bouchons via la bande d’ar­rêt d’ur­gence sous réserve de sous­crip­tion à un abon­ne­ment spéci­fique, ou d’ache­ter une exten­sion « Accès prio­ri­taire Merce­dez » pour ne plus être limité à la voie de droite.

    Les asso­cia­tions idéa­listes crient à l’at­teinte à la neutra­lité mais ces dernières n’ont rien compris à l’éco­no­mie, à la confron­ta­tion entre notre réseau auto­rou­tier financé en partie par l’État et les usagers, et entre les gros construc­teurs étran­gers qui en profitent sans y contri­buer. Il est temps d’ar­rê­ter avec ces concepts théo­riques et de prendre pied dans la réalité. Lais­sons les opéra­teurs d’au­to­route créer de la valeur.

  • Partage de fichiers en PME

    Comment parta­ger des fichiers au sein d’une PME d’une douzaine de personnes ?

    J’ai mis mes réflexions ci-dessous mais je suis preneur de recom­man­da­tions. J’ai du Mac, du Windows et du Linux, des postes fixes comme des portables (régu­liè­re­ment hors site).

    Un petit NAS

    Point parti­cu­lier : Il est diffi­cile d’ex­clure des vols dans les locaux, donc il faut que la NAS puisse chif­frer le système de fichier et synchro­ni­ser avec un service à distance.

    Je connais les Syno­logy, suivant la gamme on peut imagi­ner un DS213j et un disque unique synchro­nisé en rsync avec un serveur distant. C’est de l’ordre de 270€ mais ça me demande un disque en ligne donc empêche d’y mettre des To.

    On peut aussi imagi­ner un abon­ne­ment crash­plan, ce qui permet­trait de mettre un gros disque sans risquer de perte si jamais il dispa­rait. Pour ça il faut sauter sur le DS413 afin d’avoir les 1Go de mémoire néces­saires. On monte à 600€ plus 50€/an.

    On peut aussi imagi­ner un mini-PC avec un système d’ex­ploi­ta­tion dédié à un usage NAS, mais je n’ai aucun retour d’ex­pé­rience là dessus. Quelqu’un a déjà utilisé FreeNAS ou OpenMe­diaVault ? Au niveau prix, on risque de rester dans la même gamme que précé­dem­ment.

    Le défaut de ces solu­tions c’est qu’on va avoir des fichiers désyn­chro­ni­sés, des conflits parce que chacun édite dans son coin, des retours en arrière de version, etc. Par expé­rience c’est une horreur à gérer.

    Une synchro en ligne directe

    Comme de toutes façons il me faut une synchro en ligne, autant étudier la perti­nence que tout le monde synchro­nise ses fichiers en ligne avec un système type Drop­box. Ça permet d’évi­ter que chacun risque d’avoir une version non à jour sur son poste, ou au contraire que la version modi­fiée ne soit pas copiée sur le serveur central.

    Drop­box est clai­re­ment hors de prix pour le compte entre­prise. On parle de 1800 à 2000 € par an. Pour juste parta­ger des fichiers, ça me fait mal, quand bien même le service est très bon.

    Box.net propose 13€ par utili­sa­teur par mois, donc 2400€ par an pour 15. Ils offrent 1 To, ce qui est confor­table à condi­tion qu’un fichier partagé à 15 utili­sa­teur ne compte pas 15 fois. Ça a l’air plus complet que Drop­box mais pas moins cher.

    Wuala pour entre 10 et 15 personnes on parle de 600 € par an mais pour unique­ment 100 Go. Je ne sais même pas si un fichier partagé compte plusieurs fois.

    SugarSync n’est pas clair sur ses prix, ils parlent de 550$ par an pour 3 utili­sa­teurs et il faut passer par un commer­cial pour plus de 10 personnes. Comme je n’ai en plus aucun retour d’ex­pé­rien­ce…

    HubiC est disqua­li­fié, n’ayant pas de client Linux.

    On me dit d’ajou­ter Google Drive, qui peut effec­ti­ve­ment synchro­ni­ser sur disque des fichiers divers. Un compte pro c’est 50 € par mois, donc 750 € par an pour 15 utili­sa­teurs et 25 Go par utili­sa­teur.

  • Hyper­me­dia, quelques recherches pour JSON

    Je regarde un peu les implé­men­ta­tions hyper­me­dia pour une API. J’avoue que je pleure un peu. Qu’on soit clairs, JSON n’est pas adapté pour ça, sauf à construire des messages bien complexes à lire et à produire (ce qui tue un peu l’uti­lité de JSON). Main­te­nant si on veut garder JSON, voilà l’état de mes reflexions :

    — Ce billet est en évolu­tion constante, dernière mise à jour le 18 juin 2013 au matin —

    Déjà quelques specs liées :

    Et deux discus­sions à lire en amont (avec les commen­taires, pour les deux) :

    JSON API

    • Spec assez simple
    • Utilise URI Template
    • Réserve un terme trop géné­rique (links) pour les clefs de la racine JSON
    • Ne permet pas d’uti­li­ser des URI pour les types de rela­tion
    • Ne permet pas d’avoir plusieurs liens (de format diffé­rent par exemple) pour une même rela­tion
    • Le type de ressource ciblée par une rela­tion peut être spéci­fié (ce qui me parait super­flu : si on connait le sens de la rela­tion, on connait le type ciblé)
    • Impose JSON-PATCH

    HAL – Hyper­text Appli­ca­tion Language

    • Rendu assez moche (oui, c’est subjec­tif mais ça compte)
    • Gère des espaces de noms via Curie dans les liens et rela­tions
    • Utilise (option­nel­le­ment) les URI Template (mais ne précise pas où trou­ver les para­mètres)
    • Permet de préci­ser un profile pour quali­fier les attri­buts d’un objet (mais pas de mixer plusieurs voca­bu­laires)
    • Ne permet pas d’avoir plusieurs liens (de format diffé­rent par exemple) pour une même rela­tion
    • Beau­coup de biblio­thèques de code dans pas mal de langages, côté client et côté serveur
    • J’échoue complè­te­ment à sépa­rer ce une collec­tion ou un attri­but complexe et une ressource embarquée, donc à comprendre l’uti­lité de la clef _embed­ded
    • C’est en draft IETF

    JSON-LD

    • Semble être fait par des gens avec un esprit assez proche de RDF
    • Simple à lire, mais trop complète, trop complexe, risque d’être diffi­cile à implé­men­ter
    • Gère un des voca­bu­laire avec des URI pour quali­fier les liens, les clefs, etc. avec même des possi­bi­li­tés d’alias
    • Consi­dé­rant les indi­rec­tions possibles, trou­ver le lien avec une valeur spéci­fique de « rel » est une tâche assez complexe
    • Ne gère pas de template pour les liens, mais sait gérer les liens rela­tifs à une base décla­rée plus haut (ce qui compense un peu)
    • C’est en voie de stan­dar­di­sa­tion au W3C
    • On peut ajou­ter Hydra par dessus pour décrire les actions (petite présen­ta­tion)
    • Peu d’im­plé­men­ta­tions clientes (trouvé une PHP et un conver­tis­seur vers RDF en Ruby)

    Siren

    • Va plus loin que les autres, en décri­vant aussi les types d’ac­tions possibles sur la ressources décrite, les para­mètres pour les diffé­rentes actions, etc. (illu­sion de pouvoir coder un navi­ga­teur d’API géné­rique ?)
    • Pas de template pour les liens
    • Simple à comprendre et à relire (si on met de côté la partie « actions »)
    • Impose une enve­loppe, les clefs à la racine sont liées à Siren, pas à l’objet décrit
    • Pourquoi ici encore sépa­rer les enti­tés liées des proprié­tés ?

    Collec­tion/JSON

    Quand on pense avoir saturé, on se rend compte que ce n’est pas fini. J’ai donc trouvé Collec­tion+JSON après les autres. Il permet de défi­nit des gaba­rit d’at­tri­buts pour les ressources, ajoute les liens et les rôles des liens, la notion de collec­tion, et défi­nit les méca­nismes d’ajout/recherche.

    C’est fina­le­ment une de celes qui se concentrent le mieux sur la tâche fixée au départ, mais je ne suis pas certain d’être convaincu. Au moins on a évité la sur-ingé­nie­rie. C’est implé­men­table de bout en bout.

    Quelques pré-conclu­sions

    Certaines spéci­fi­ca­tions vont bien trop loin à mon goût, et pas toujours en sachant faire correc­te­ment la base (éviter les conflits de nommage, pouvoir utili­ser des URI pour le voca­bu­laire, voire des espaces de noms).

    Rien que les templates d’URI sont fina­le­ment inutiles. Ils permettent de grap­piller quelques octets en évitant de taper des liens complets, mais imposent de rédi­ger un code non négli­geable rien que pour recons­truire le lien final, et empêchent de copier un sous-objet en le consi­dé­rant comme auto­nome (il ne l’est pas, le template pour son URL est dans l’objet parent).

    Alors parler de décrire les actions et les inter­ac­tions possibles avec chaque objet… En voulant trop en faire on reporte beau­coup de complexité sur le client. On est parfois en train de faire des clients très complexes pour éviter de gérer des infor­ma­tions simples et qu’on va proba­ble­ment de toutes façons coder en dur quelque part. Ça en devient contre-produc­tif. De ce côté j’ap­pré­cie la peti­tesse de JSON-API.

    J’ai encore l’avis qu’i­ma­gi­ner un client HATEOAS complet et géné­rique est illu­soire. J’ai juste besoin d’at­ta­cher quelques méta­don­nées comme des liens, des rôles aux liens, et éven­tuel­le­ment un voca­bu­laire pour les types de données.

    Et puis, sérieu­se­ment, si c’est pour que le résul­tat ne soit plus éditable agréa­ble­ment et présente des struc­tures non natu­relles, quel est l’in­té­rêt d’être passé à JSON ?

    XML, ou même HTML avec des micro­data/formats est défi­ni­ti­ve­ment plus adapté que JSON pour ce que je cherche à faire. À JSON il manque au moins un moyen d’at­ta­cher des méta­don­nées à une clef/valeur (par exemple la notion d’at­tri­but sur les nœuds XML/HTML). Avec ça nous pour­rions faire un joli format, sans ça ça restera bien moche et peu pratique.

    Le problème c’est que déve­lop­per un client qui fouille des données HTML avec une struc­ture lâche à base de micro­data/formats, c’est aussi assez complexe à gérer. Reste le XML « à la main » mais si si je veux que mon API soit utili­sée, je crains que JSON ne soit le seul choix prag­ma­tique.

    Entre les diffé­rentes spéci­fi­ca­tions

    Mon cœur balance entre JSON-API pour sa simpli­cité (mais réser­ver le terme « links » me semble juste une aber­ra­tion), HAL parce qu’il semble de loin (mais ce « _embed­ded » me gêne toujours, et faire un « _links »: { « self »: { « href »: « xxxxxx » } } juste pour donner le lien du sous-objet courant me inuti­le­ment lourd), et JSON-LD parce que ça ressemble assez fort à la façon dont je pense et que ça semble permettre tout ce que je peux imagi­ner d’in­tel­li­gent (mais implé­men­ter la spec complè­te­ment risque d’être fran­che­ment diffi­cile).

    Dans une précé­dente version de ce billet j’ai tenté un subset de JSON-LD où n’im­porte quel objet peut conte­nir :

    • un attri­but (facul­ta­tif) @id, qui est le lien iden­ti­fiant l’objet
    • un attri­but (facul­ta­tif) @type, qui défi­nit l’URL du type de l’objet (par exemple un type de schema.org) et poten­tiel­le­ment le sens des sous-clefs ou sous-liens.
    • un sous-objet (facul­ta­tif) @con­text, qui contient les diffé­rents préfixes et adresses utili­sables pour les diffé­rentes clefs de l’objet (afin de pouvoir mixer plusieurs voca­bu­laires sans risquer de conflits de noms et de sens).
    • un sous-objet (facul­ta­tif) @rel, inexis­tant dans JSON-LD, qui pointe les diffé­rents objets liés par leur rôle (attri­but « rel » habi­tuel) pour les retrou­ver faci­le­ment (il y a trop d’in­di­rec­tions pour ça dans JSON-LD)

    Mais je n’aime pas réin­ven­ter la roue, et aussi moche soit-il, HAL contient peut être le prin­ci­pal. Entre une spéci­fi­ca­tion géniale mais trop complexe et sans implé­men­ta­tion cliente, et une spéci­fi­ca­tion plus simple, moche mais bour­rée d’im­plé­men­ta­tions, j’ai du mal à ne pas recom­man­der la seconde. J’ai quand même toujours un peu de mal à voir comment me servir utile­ment du _embed­ded.

  • Éton­nant l’es­pion­nage, vrai­ment ?

    Ces jours ci on apprend que la NSA aurait un accès sur les données de Google, Apple, Yahoo, Micro­soft, Face­book et d’autres via un projet nommé PRISM.

    Je trouve très hypo­crite tous ces gens qui se disent éton­nés et d’un coup scan­da­li­sés.

    Qui n’a pas entendu parler d’Eche­lon ? Même Jean-Pierre Pernot a du en parler à l’époque. Quel infor­ma­ti­cien un peu âgé et travaillant dans les réseaux n’a pas entendu parler de Carni­vore ? Quel geek n’a pas entendu parler de la pièce 614A utili­sée par la NSA au milieu de AT&T ? Quel infor­ma­ti­cien de plus de 30 ans n’a pas entendu parler de la polé­mique sur la clef NSA dans Micro­soft Windows ?

    Que les USA fouillent dans les commu­ni­ca­tions en ligne, ce n’est même plus un sujet. D’ailleurs les autres pays non plus. On peut parler du Great Fire­wall of China, mais aussi de Amesys en Libye, la Suède, la Suisse, et bien entendu la France. En fait quasi­ment tous les pays espionnent les commu­ni­ca­tions en ligne à leur niveau. Notre pays est même à la pointe sur ce genre d’outils d’in­ter­cep­tion à l’échelle de pays entiers.

    L’in­ter­cep­tion des lignes télé­pho­niques est main­te­nant presque un outil du passé. Qui croit vrai­ment que les États n’ont pas fait évoluer leurs outils ? Aujourd’­hui les polices et agences de rensei­gne­ment ont très offi­ciel­le­ment des batte­ries de virus et autres enre­gis­treurs de frappe. Il y a même des lois pour cadrer tout ça (au moins aux USA, en France et en Alle­magne, mais proba­ble­ment aussi partout ailleurs).

    Bref, oui c’est grave, oui il faut lutter, mais faire semblant de décou­vrir que les données privées sont proba­ble­ment inter­cep­tées, c’est juste hypo­crite. La seule chose qui change aujourd’­hui c’est que nous avons un nom et des éléments pour poser des ques­tions formelles.