Carnet de notes

Catégorie : Développement informatique

  • Offshore & star­tup

    Je recherche des star­tups Europe/US dont une partie de l’équipe tech­nique a été basée hors Europe/US pour des raisons de coûts.

    • Est-ce que ça existe ? Vous avez des noms ?
    • Si vous l’avez vécu (quel que soit le côté), quelles en ont été les enjeux, les diffi­cul­tés et les résul­tats ?
    • Si vous avez choisi de ne pas le faire, pourquoi ?

    Note : Je ne parle pas de régie offshore mais bien de gens internes à la star­tup.

    I am looking for Euro­pean/US star­tups in which part of the team has been loca­ted outside Europe/US to lower the costs.

    • Did you heard about such expe­riences ? Do you have names ?
    • If you lived it  (whate­ver the side), what where the stakes, the diffi­cul­ties and the results ?
    • If you choose not to go this way: why ?

    Note: I am not talking about offshore contrac­ting but about people who are direct employees of the star­tup

  • Lien vers du Javas­cript

    Problé­ma­tique du jour : Inter­cep­ter l’ap­pel à des liens via Javas­cript.

    Mon cas d’usage : J’ai des conte­nus (images, vidéos, audio, polices de carac­tères) stockés côté client (indexedDB, webSQL ou DOMS­to­rage) que je souhaite insé­rer dans mes pages.

    (billet mis à jour au fur et à mesure des réponses)

    Quelques solu­tions :

    Data:URI

    Je récu­père ma donnée, je la trans­forme en base64, et je remplace le lien stan­dard par un lien en data:uri.

    Deux défauts : Je stocke N fois la donnée dans le DOM où N est le nombre d’ap­pa­ri­tion de l’image ou de la ressource dans mes pages HTML/CSS. Pour ne rien gâcher, on stocke en base64 donc avec 30% de poids en plus. De plus, même si je n’ai pas de test à montrer, on s’est déjà pris les pieds dans le tapis à cause de très mauvaises perfor­mances de pages avec beau­coup de data:uri, spécia­le­ment sur Fire­fox (proba­ble­ment sur les polices de carac­tères)

    Blob + crea­teObjectURL

    Je récu­père ma donnée, je créé un Blob à partir de cette donnée, je passe par URL.crea­teObjectURL pour créer une URL dédiée et j’uti­lise cette dernière quand je réfé­rence ma ressource.

    On résout les problèmes du data:uri mais on se coupe de IE 9, IE mobile et iOS 5. Pas gravis­sime mais j’au­rai préféré éviter.

    Par contre la solu­tion ne fonc­tion­nera de toutes façons pas pour les images ou polices de carac­tères réfé­ren­cées depuis les CSS (sauf à construire les CSS via Javas­cript mais là on entre dans des usines à gaz).

    Cas spéci­fique des vidéo et audio

    Les deux solu­tions me posent de toutes façons un sérieux problème pour les vidéo et les audio, qui peuvent être de gros volume. Je me vois mal sortir d’in­dexedDB des dizaines de méga­oc­tets (au mieux) pour construire un blob juste et avoir une URL dans ma balise HTML sans même savoir si l’uti­li­sa­teur tentera effec­ti­ve­ment de lire la vidéo ou le fichier audio.

    Pour les vidéos et les audio (mais unique­ment ces deux types de contenu) je peux réflé­chir à mettre un lien vers une vidéo de taille quasi nulle et le chan­ger dès que la vidéo est acti­vée. J’ai toute­fois un peu peur des effets de bords. Il va falloir aussi bosser en amont pour que la première image s’af­fiche bien dans le lecteur vidéo malgré l’ab­sence de la vidéo complète.

    Bidouille

    Pour l’ins­tant ma solu­tion serait :

    • Pour les images et polices de carac­tères dans les CSS : data:uri. En espé­rant que la CSS ne contient pas trop de ressources inutiles ou trop de liens vers la même ressource.
      • Au pire : Géné­rer la CSS en Javas­cript avec des liens obte­nus par crea­teObjectUrl, l’in­sé­rer dans le DOM manuel­le­ment
    • Pour les images dans le code HTML : crea­teObjectURL si possible.
      • Véri­fier tout de même si le data:uri n’est pas plus simple. La diffé­rence entre les deux sera assez faible si les images ne sont pas répé­tées plusieurs fois.
    • Pour les audio et vidéo : Désac­ti­ver le preload, rensei­gner le lien via crea­teObjectURL qu’au lance­ment de la vidéo. Pour les vidéo, penser à créer une image d’at­tente avec l’at­tri­but poster.

    Ça reste fran­che­ment du brico­lage je trouve, et ça va néces­si­ter plein de javas­cript pour géné­rer tout ça.

    Dans mon monde idéal

    Dans l’idéal j’au­rai bien aimé avoir une sorte de faux serveur web en javas­cript depuis le navi­ga­teur. Genre toute url en « local-js://xxxxx » fait appel à un objet Javas­cript qui répond ensuite ce qu’il veut.

    À défaut, un URL.createObjectURL( 'text/html', function() { return bindata; } ) serait bien pratique : Le navi­ga­teur n’ap­pe­lant la fonc­tion pour récu­pé­rer le contenu que quand il cherche à accé­der au dit contenu, au lieu de lui donner tout le contenu par avance au cas où il en aurait besoin.

    Quelqu’un a des pistes pour moi ?

  • 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.

  • 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 ?

     

  • 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.

  • Ateliers sur la docu­men­ta­tion webperf

    J’ai partagé en ligne il y a quelques temps le début de livre que j’avais rédigé à propos de la perfor­mance des sites web.

    L’objec­tif était d’avoir une « bible » qui réfé­rence toutes les tech­niques impac­tant le temps de char­ge­ment des sites web et la théo­rie sous-jacente. Une moitié du travail était déjà là. C’est sur github, dans un format acces­sible à tous.

    En le posant sur github l’es­prit est « ce contenu appar­tient à ceux qui se l’ap­pro­prient ». Si vous y parti­ci­pez, ça devient un peu le vôtre. De mon côté ce n’est déjà plus « mon livre » mais un projet commu­nau­taire, dont je ne souhaite d’ailleurs pas forcé­ment être le main­te­neur ou l’ani­ma­teur.

    Pour initier la dyna­mique néces­saire, nous avons réalisé deux ateliers : un à Paris fin avril, un dans le cadre de Sudweb la semaine dernière. Il s’agit d’ex­pliquer le projet, puis de réali­ser relec­tures, mises à jour et rédac­tion par petits groupes. Le projet avance un peu, et chacun repart avec une meilleure connais­sance ou des échanges sur un sujet pointu.

    Si vous ne savez pas par où commen­cer vous pouvez commen­cer par regar­der les tickets en cours (« issues » dans la barre de menu github). Ils sont clas­sés par chapitre et par type d’ac­tion (relec­ture, mise à jour, contenu manquant, etc.). Le fichier « HELP.md » à la racine du projet contient aussi un guide de démar­rage avec quoi et comment sur diffé­rentes ques­tions que vous pour­riez vous poser. Vous pouvez aussi simple­ment vous signa­ler et poser vos ques­tions sur la liste de diffu­sion française : https://groups.google.com/group/perfor­mance-web?hl=fr

    La suite c’est de conti­nuer avec les ateliers. Il faut prévoir un anima­teur et proba­ble­ment au moins une personne qui a déjà lu le contenu et saura répondre aux ques­tions tech­niques webperf. Je compte en propo­ser quelques uns mais n’hé­si­tez pas à en orga­ni­ser vous-même dans vos commu­nau­tés locales. Avec un peu de temps se déga­ge­ront certai­ne­ment une ou deux personnes pour animer tout cela sur le long terme.

    Retour sur les deux ateliers précé­dents

    Sur les ateliers passés il y a eu un bon travail sur les relec­tures, qui s’est traduit via quelques correc­tions, quelques ajouts, mais aussi une bonne série de tickets qui permettent main­te­nant de struc­tu­rer et guider les bonnes volon­tés.

    Un gros merci à tous ceux qui ont parti­cipé.

    Deux points soule­vés :

    • En plus de la demie-heure de présen­ta­tion du projet et du fonc­tion­ne­ment, il faut prévoir des créneaux d’au moins une bonne heure, préfé­ra­ble­ment une heure et demie. En dessous on manque de temps pour amener un résul­tat concret.
    • La licence initiale était inuti­le­ment complexe de façon à garder la possi­bi­lité d’em­barquer un éditeur papier dans l’aven­ture. Suite aux diffé­rents retours, il appa­rait plus sage de rebas­cu­ler sur une licence ouverte plus simple, peut être une Crea­tive Commons. N’hé­si­tez pas à en discu­ter ici ou sur la liste de diffu­sion webperf

    Voilà, main­te­nant c’est à vous de jouer.

  • 42 pour une seule école ? ça fait 41 de trop

    Bon, une nouvelle école. Quelques réac­tions :

    J’ap­pré­cie l’ou­ver­ture sans trop faire atten­tion à l’âge. Les forma­tions privées sont trop souvent atta­chées au cursus avec l’obli­ga­tion d’en­chaî­ner sans s’ar­rê­ter sous peine de devoir passer dans les forma­tions conti­nues spéci­fiques pour.

    J’ap­pré­cie aussi l’hon­nê­teté de faire une vraie sélec­tion, sur l’été pour lais­ser les élèves avoir une porte de sortie avec la fac. Le fait de croire dans une forma­tion de déve­lop­peur et pas que dans des chefs de projets / ingé­nieurs, ça me fait aussi plai­sir : Il faut recré­di­bi­li­ser ces postes si on veut avoir des gens compé­tents.

    Tech­ni­cien expert, C++

    On y forme des tech­ni­ciens, dans la pure lignée Epita / Epitech. Que ce soit un ancien Epitech qui reprenne la chose n’est pas anodin. Ce n’est ni un plus ni un moins, juste diffé­rent de beau­coup de forma­tions actuelles. Je conti­nue à voir une vraie diffé­rence entre ceux qui sont formés avec une orien­ta­tion « ingé­nieur » et ceux qui sont formés avec une orien­ta­tion « tech­ni­cien expert ».

    Une école de plus avec de réels tech­ni­ciens infor­ma­tiques très poin­tus, ok, pourquoi pas, voyons plus loin.

    On ne cède pas à la mode. Tout s’ap­prend par C++ dès la première année. C’est la langue obli­gée qui sert de base pour le reste si je lis bien le programme. Je dirais que ça ne fait pas de mal, que les déve­lop­peurs bas niveau sont trop peu nombreux, mais je ques­tionne la perti­nence de voir le modèle objet par le prisme de C++.

    Peu de web

    Par la suite il y a de nombreuses sections pour C# et les tech­no­lo­gies Micro­soft, quelques sections Java, mais pour le reste on repas­sera : 3 crédits pour apprendre toutes les tech­no­lo­gies web (Javas­cript, PHP, HTML, XML, etc.) et 3 autres pour apprendre en même temps les frame­works web et le e-commerce (Rails, Zend, Ruby, le e-commerce, les cms, les IHM web, et même l’er­go­no­mie web), ça fait fran­che­ment chiche, même pour un simple survol Si j’étais méchant je dirai qu’on comprend mieux le pourquoi des inter­faces de Free.

    Peut être est-ce parce que c’est mon domaine et que j’y attache de l’im­por­tance, mais le web me semble l’objet tech­no­lo­gique majeur de ces dernières années. Bref, pour moi c’est étrange d’y consa­crer si peu. Je ne vois pas les gens apprendre Javas­cript, PHP, HTML5, Zend Frame­work, Ruby et Rails comme ça d’un coup.

    Quelques points datés

    Je conti­nue à tiquer sur GANTT, UML, Merise, ITIL. Je peux le comprendre dans certaines forma­tions. J’ai plus de mal dans une nouvelle forma­tion de zéro, et surtout dans celle là qui est très orien­tée pratique / tech­nique / déve­lop­pe­ment.

    À l’in­verse, pour une forma­tion axée sur le projet et la mise en pratique, parler de méthodes agiles en dernière année ça me semble un peu du gâchis.

    Point global sur le programme

    Bon, mais fina­le­ment tout ce qui précède reste assez cohé­rent. On forme des tech­ni­ciens experts, plutôt bas niveau, dont le haut du panier saura proba­ble­ment inter­ve­nir partout avec aisance et compé­tence.

    Tout juste le programme laisse-t-il appa­raître beau­coup de noms de tech­no­lo­gies et j’au­rais aimé y voir plus d’al­go­rith­mie ou de théo­rie, mais il est tout à fait possible que ce soit abordé à l’oc­ca­sion des projets.

    Je ne vais pas dire que c’est ce que j’au­rais choisi en créant une forma­tion, mais ça ne me semble pas méri­ter toutes les critiques que j’ai vues.

    Enro­bage marke­ting

    Non, moi ce qui me fait prendre de la distance c’est l’en­ro­bage. Ça pue le mauvais marke­ting au point que ça en est néga­tif. J’ai l’im­pres­sion de retrou­ver l’EPITA en 97 : tutoie­ment, on met en avant la créa­tion de virus, une épreuve de sélec­tion « ultime et redou­table » (qui élimine 2/3 à 3/4 des candi­dats, donc bien moins que la plupart des concours ou proces­sus de sélec­tion, dans l’édu­ca­tif ou non), le but est plus d’en mettre plein les yeux que d’ap­pa­raître sérieux.

    On retrouve aussi cet enro­bage dans le super marke­ting « pas de diplôme, l’im­por­tant ce sont les compé­tences ». Sauf que le diplôme en France c’est essen­tiel­le­ment un certi­fi­cat indiquant que tu as suivi une certaine forma­tion. Au lieu d’in­diquer « diplôme de master à xxxx » les élèves indique­ront « suivi forma­tion complète à xxx ». S’ils ne le font pas c’est mauvais signe pour la répu­ta­tion de la forma­tion en ques­tion.

    Pas de diplôme

    Au final ça ne chan­gera donc rien. Ou plutôt si, ça rendra impos­sible certains emplois publics ou diffi­cile certaines embauches à l’étran­ger, ça sera irréa­liste d’en­chaî­ner sur d’autres études supé­rieures comme la recherche ou un MBA en gestion/commerce pour la double compé­tence, et ça empê­chera les échanges par équi­va­lence de diplôme/compé­tence en Europe.

    Je note d’ailleurs que le parcours du DG[*] avec un MBA à HEC ne peut proba­ble­ment pas être fait dans cette nouvelle école (sauf à reprendre de zéro la prépa HEC) juste­ment à cause du manque de diplôme. Faites ce que je dis, pas ce que je fais. Tout ça pour quoi, un effet de manche marke­ting ?

    En fait là aussi ça me fait beau­coup penser à l’EPITA qui à l’époque se défen­dait de trou­ver un inté­rêt à avoir un diplôme reconnu par la CTI mais qui tentait régu­liè­re­ment de la demande (et se fera reje­ter jusqu’en 2007).

    Je me dis que l’ab­sence de diplôme en sortie est proba­ble­ment dû à l’ab­sence de pré-requis du bac en entrée (ça empêche proba­ble­ment de faire recon­naître le niveau ensuite par l’État) mais ça aurait été plus honnête de l’ex­pri­mer ainsi.

    [*] D’ailleurs, c’est moi ou il y a un couac ? Dans son profil Linke­din le DG en ques­tion est ingé­nieur EPITA depuis 92 alors que cette dernière ne délivre de diplôme reconnu que depuis 2007. Même chose pour la préci­sion du master EPITECH 2005 alors que l’école n’est habi­li­tée que depuis 2007. Pire, parce que là il indique une forma­tion entre 1999 et 2005 alors qu’il a fondé l’école et en était le DG à ce moment là (ça me parait un peu incom­pa­tible avec l’idée d’en sortir diplômé pour moi). On voit qu’ef­fec­ti­ve­ment tout n’est pas clair côté diplômes, et ça n’ins­pire pas confiance (Je me souviens un peu trop de l’am­bi­guité entre­te­nue concer­nant le titre ingé­nieur à l’EPITA avant qu’ils n’ob­tiennent l’ha­bi­li­ta­tion).

    Forma­tion

    Je retrouve encore EPITA dans l’idée qu’ils forment des archi­tectes tech­niques, des chefs de projets et des experts. J’ai bien parlé de tech­ni­cien expert plus haut, mais c’est plus pour faire la diffé­rence avec nombre de forma­tions de tech­ni­ciens basiques. Il reste que faire miroi­ter qu’être archi­tecte ou expert en sortie d’école c’est trom­per les élèves. À mon époque certains EPITA croyaient valoir deux fois le salaire d’em­bauche moyen telle­ment on leur montait la tête à ce niveau (je parle d’EPITA mais ce n’étaient pas les seuls).

    Et là où je bip c’est quand je vois parler d’école peer-to-peer. Outre le mot clef marke­ting pour les élèves en manque, ça me rappelle ce que j’ai vu dans d’autres orga­nismes de forma­tion où ce sont les élèves qui donnent les cours aux autres élèves. Ça peut fonc­tion­ner, mais ça a aussi de graves manques. C’est aussi juste infai­sable au départ.

    Si on ajoute que monter une promo de 1000 élèves en une seule année est quasi­ment infai­sable en arri­vant à une bonne qualité de forma­tion, j’ai tendance à croire que les cinq premières promo passe­ront à la trappe et qu’on s’en moque.

    Epita / Epitech / 42

    Au final voilà juste une EPITA / EPITECH de plus, fondée par la même personne, avec la même orien­ta­tion de tech­ni­cien expert, la même philo­so­phie vis à vis des diplôme (affir­mer que c’est inutile jusqu’à enfin réus­sir à avoir l’ha­bi­li­ta­tion), le même danger sur la forma­tion en partie assu­rée par les élèves. Faire des écoles en série ne m’ins­pire pas tant confiance que ça. La forma­tion n’est cepen­dant pas aussi critiquable que ne le laissent entendre quelques geeks.

    Côté résul­tat, comme les EPITA / EPITECH, il peut en sortir du mauvais comme du bon. Et comme dans les deux autres, il en sortira proba­ble­ment quelques-uns de très bons, comme une masse qui n’est pas excep­tion­nelle pour autant. Bref, comme partout : La valeur des gens dépend plus des gens que de la forma­tion.

    Vus le système, la promo immense et le côté marke­ting un peu forcé, je conseille tout de même au moins de ne pas faire partie des premières promos qui risquent de payer les pots cassés.

  • Défi­nir son API : version­ne­ment

    Toujours dans la logique de réflé­chir son API, parce qu’un jour il faudra la faire évoluer, comment gérer le version­ne­ment ?

    Plusieurs solu­tions ont émergé :

    • https://api-v2.example.com/mares­source
    • https://api.example.com/v2/mares­source
    • https://api.example.com/mares­source-v2
    • https://api.example.com/mares­source?v=2
    • https://api.example.com/mares­source avec une entête Version: 2
    • https://api.example.com/mares­source avec une entête Accept ou/et Content-type: appli­ca­tion/monfor­mat;version=2

    La solu­tion du sous-domaine n’est à mon sens à réser­ver que pour les big-bang. Elle n’est pas faci­le­ment multi­pliable à l’in­fini, mais à l’avan­tage de permettre aisé­ment d’avoir même deux plate­formes tota­le­ment sépa­rées pour les deux versions de l’API.

    Les deux suivantes se distinguent par le fait de version­ner l’API ou la ressource. J’ai tendance à penser que s’il faut version­ner la ressource en cassant la compa­ti­bi­lité, alors c’est peut être une nouvelle version de l’API qui est à publier si on ne veut pas finir avec un gros patch­work diffi­cile à main­te­nir : En gardant tout sous le même espace on s’in­ter­dit de faci­le­ment rendre obso­lète les anciennes versions.

    Quitte à parfois devoir version­ner au niveau de la ressource, l’idée d’ajou­ter un para­mètre a fini par me sembler plus propre. Il s’agit quasi­ment toujours de s’adres­ser à une repré­sen­ta­tion diffé­rente de la ressource, pas de chan­ger son sens fonda­men­tal. Le risque est que la plupart des gens conti­nuent à utili­ser la version d’ori­gine et ne pas prendre en compte le para­mètre. Rendre obso­lète des anciennes repré­sen­ta­tions risque là aussi d’être diffi­cile.

    Les possi­bi­li­tés d’ajou­ter les versions dans les entêtes sont souvent conseillées d’un point de vue théo­rique. En pratique mon retour est que c’est complexe à utili­ser, et d’une valeur ajou­tée assez discu­table. On oublie trop faci­le­ment que le bon usage de l’API tient direc­te­ment à sa simpli­cité et sa bonne compré­hen­sion. S’il y a besoin d’être expert en archi­tec­ture web pour comprendre le pourquoi des choses, c’est une mauvaise solu­tion. Le « tout dans l’URL » ajoute une faci­lité pour tester et échan­ger entre tech­ni­ciens qui vaut toutes les posi­tions acadé­miques du monde.

    Twilio a aussi une façon inté­res­sante de gérer les versions. Au lieu d’un v2 ou v3, le déve­lop­peur indique une date et c’est le serveur qui sélec­tionne la version de l’API à utili­ser en fonc­tion de la date. C’est tentant, souple, mais j’ai peur que ce ne soit pas suffi­sam­ment expli­cite sur ce qu’on utilise ou sur comment gérer ce para­mètre. Qu’est-ce qui change si je met à jour la date ?

    Des lectures et expé­riences je tire quelques recom­man­da­tions :

    • Prévoir dès le départ un système de version­ne­ment, vous en aurez besoin un jour, ne croyez pas que vos API pour­ront rester telles quelles ad vitam eter­nam
    • Impo­ser un version­ne­ment expli­cite, immé­dia­te­ment, dès la première version. Vous évite­rez les ambi­guï­tés et une partie des moules qui s’at­tachent aux adresses « sans version » par défaut
    • N’uti­li­ser que des numé­ros de version simples, pas de notion de mineur/majeur, pas de points ou virgules : Si ça change de façon non compa­tible c’est une nouvelle version et on incré­mente d’une unité. Le reste c’est du marke­ting et ça n’a rien à faire dans vos URLs.
    • Utili­ser un version­ne­ment dans l’URL, à la racine du service ; il sera temps d’uti­li­ser un autre sous-domaine si un jour il y a un vrai big bang qui le néces­site
    • Docu­men­ter (oui, c’est évident, mais pas si simple à ne pas oublier)

  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?

  • Bomber­man massi­ve­ment multijoueur

    Un bomber­man-like massi­ve­ment multijoueur ? Je ne suis pas convaincu par l’in­té­rêt ludique. Ne pas jouer avec ses amis, ne pas tisser de liens, avoir une inter­ac­tion limi­tée à quelques minutes et faite au hasard, j’ai peur que ça ne remplisse pas de promesses sur le long terme.

    Tech­nique­ment par contre c’est inté­res­sant, pas forcé­ment si complexe que ça, mais sacré­ment inté­res­sant. Le jeu dans le navi­ga­teur n’est qu’à ses débuts.