Petite découverte récente et sympa : Flysystem. Une bibliothèque de code PHP qui présente une abstraction assez simple et sympa autour des systèmes de fichier locaux, S3, dropbox, FTP, …
Catégorie : Développement informatique
-
Documentation PHP
Quelques (nombreux) écrans de présentation de Willian Durand à propos de PHP
Je ne sais pas à qui est destiné cette documentation, mais c’est un boulot énorme et très bien fait de collecte, analyse et présentation des bonnes pratiques. Vous devriez passer dessus et prendre du temps à lire même si vous travaillez déjà avec PHP au jour le jour.
Pour m’être frotté à ce genre d’exercice, j’ai rarement vu un résultat aussi bon.
Il y a une version pour la suite qui parle plus particulièrement de Symfony, mais moins essentielle à mon avis.
-
Offshore & startup
Je recherche des startups Europe/US dont une partie de l’équipe technique 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 difficultés et les résultats ?
- 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 startup.
I am looking for European/US startups in which part of the team has been located outside Europe/US to lower the costs.
- Did you heard about such experiences ? Do you have names ?
- If you lived it (whatever the side), what where the stakes, the difficulties and the results ?
- If you choose not to go this way: why ?
Note: I am not talking about offshore contracting but about people who are direct employees of the startup
-
Lien vers du Javascript
Problématique du jour : Intercepter l’appel à des liens via Javascript.
Mon cas d’usage : J’ai des contenus (images, vidéos, audio, polices de caractères) stockés côté client (indexedDB, webSQL ou DOMStorage) que je souhaite insérer dans mes pages.
(billet mis à jour au fur et à mesure des réponses)
Quelques solutions :
Data:URI
Je récupère ma donnée, je la transforme en base64, et je remplace le lien standard 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’apparition 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 performances de pages avec beaucoup de data:uri, spécialement sur Firefox (probablement sur les polices de caractères)
Blob + createObjectURL
Je récupère ma donnée, je créé un Blob à partir de cette donnée, je passe par URL.createObjectURL pour créer une URL dédiée et j’utilise 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 gravissime mais j’aurai préféré éviter.
Par contre la solution ne fonctionnera de toutes façons pas pour les images ou polices de caractères référencées depuis les CSS (sauf à construire les CSS via Javascript mais là on entre dans des usines à gaz).
Cas spécifique des vidéo et audio
Les deux solutions 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’indexedDB des dizaines de mégaoctets (au mieux) pour construire un blob juste et avoir une URL dans ma balise HTML sans même savoir si l’utilisateur tentera effectivement de lire la vidéo ou le fichier audio.
Pour les vidéos et les audio (mais uniquement ces deux types de contenu) je peux réfléchir à mettre un lien vers une vidéo de taille quasi nulle et le changer dès que la vidéo est activée. J’ai toutefois un peu peur des effets de bords. Il va falloir aussi bosser en amont pour que la première image s’affiche bien dans le lecteur vidéo malgré l’absence de la vidéo complète.
Bidouille
Pour l’instant ma solution serait :
- Pour les images et polices de caractè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 Javascript avec des liens obtenus par createObjectUrl, l’insérer dans le DOM manuellement
- Pour les images dans le code HTML : createObjectURL si possible.
- Vérifier 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ésactiver le preload, renseigner le lien via createObjectURL qu’au lancement de la vidéo. Pour les vidéo, penser à créer une image d’attente avec l’attribut poster.
Ça reste franchement du bricolage je trouve, et ça va nécessiter plein de javascript pour générer tout ça.
Dans mon monde idéal
Dans l’idéal j’aurai bien aimé avoir une sorte de faux serveur web en javascript depuis le navigateur. Genre toute url en « local-js://xxxxx » fait appel à un objet Javascript qui répond ensuite ce qu’il veut.
À défaut, un
URL.createObjectURL( 'text/html', function() { return bindata; } )
serait bien pratique : Le navigateur n’appelant la fonction pour récupé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 ?
- Pour les images et polices de caractè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.
-
Please stop pretending PHP is a good language
The first step to fixing a problem is admitting that there is one.
Bon, des critiques de PHP ce n’est pas ce qui manque mais pour une raison inconnue 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 reliably 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 country you live in if you don’t know the fine details of configuring PHP. - It’s not ok that you won’t be able can’t call array_map” or just “$iterator->reduce” on an iterator in 2014.
- It’s not ok to ignore the simple fact that most of the PHP world currently relies on parsing function and class comments for it’s code to function because people can’t get their shit together on mailing lists.
- It’s not ok to run around shouting “type hinting for literals would mean that passing an int to float hint would fatal PHP” and calling that an reasonable argument 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 parallel, using “promises” or whatever, in a language that has “pull stuff out of database and put it into the internet” as a proclaimed core competency.
- It’s not ok that
echo 0.000001;
produces1.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 generating a suppressed undefined 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’espère ». Alors pour ceux qui m’ont fait suivre le lien :
Pour le premier item il existe plusieurs solutions, dont un simple array_values($tab)[0]. Bref, rien d’exceptionnel pour aller itérer sur un dictionnaire.
Pour le second, si on demande explicitement au niveau du système à afficher les résultats suivant les conventions d’un pays spécifique, PHP s’y conforme. C’est le cas de la plupart des langages, y compris la ligne de commande de base. Difficile d’avancer que c’est un problème, d’autant qu’il est bien évidemment possible d’ignorer la configuration du système pour forcer une locale au niveau du langage.
Quant à savoir comment afficher 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écifique à PHP, à ma connaissance aucun ne le fait), il faut bien qu’il choisisse une forme arbitrairement à la sortie. Si l’auteur veut forcer autre chose, il a tous les outils pour ça.
Pour le dernier item j’ai la flemme de vérifier les cas limites mais à priori c’est juste que l’auteur n’a pas eu le courage d’aller créer un gestionnaire d’erreur 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éveloppeur frustré, 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 pousser des faux problèmes décrédibilise ceux qui essayent de corriger les problèmes réels.
-
Bases de données en master – master
J’ai cherché de quoi stocker des données avec plusieurs serveurs maîtres en réplication, mais je n’ai rien trouvé d’intéressant pour l’instant. Je me suis dis que toi, fidèle lecteur, tu pourrais apporter ta pierre. D’autant qu’il me semble que c’est une problématique courante, au moins pour les américains qui doivent avoir des serveurs sur les deux côtes, synchronisés entre eux.
Fonctionnellement
J’ai des visiteurs qui vont accéder en lecture, en écriture ou en modification à des données. Ces visiteurs peuvent être répartis géographiquement et j’aimerai que dans la mesure du possible, ils puissent accéder à leurs données rapidement. Par rapidement j’entends « 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 continent ».
Là où j’ai de la chance, c’est qu’une même données ne sera crée, modifiée ou lue que par un seul utilisateur (ou presque). Cet utilisateur sera donc le plus souvent au même endroit, donc je peux répartir mes données en considé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’utilisateur navigue géographiquement. Par contre il faut que lors de la création d’une donnée, je puisse choisir quel serveur sera le maître pour la donnée en question (pas de répartition automatique par hachage de clef puisque le maître est choisi en fonction de la proximité géographique).
Histoire de compléter : J’ai assez peu de relationnel dans ces données et j’y accède quasiment toujours par leur clef primaire. Je suis prêt à utiliser du SGBDR type MySQL, du clef/valeur type Redis, ou des intermé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ésenter plusieurs Go, entre 5 et 20 on va dire à vue de nez, non volatiles (donc j’exclue tout système qui ne permet pas de sauvegarde ou qui n’a pas de couche écriture disque). La performance est importance lors des accès, mais je ne vais pas avoir un débit d’écriture phénoménal non plus. Je ne pense pas que ce soit le critère de choix principal.
Enfin, je n’ai pas besoin d’écritures 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 modification) depuis un autre serveur que celui de sa création.
Techniquement
Beaucoup de solutions ont un mode maître-maître qui ne semble pas convenir à mon besoin, où les conflits peuvent être légion : Si un utilisateur fait volontairement une opération sur une données à partir de plusieurs emplacements géographique, je risque de ne pas pouvoir tracer ses différentes opérations mais d’avoir au mieux la trace de la dernière. Sauf erreur de ma part, les bidouillages multi-maîtres MySQL et PostgreSQL entrent dans cette catégorie.
J’ai jeté un oeil à Redis-cluster, qui a l’air d’être assez proche de la philosophie que je cherche (chaque donnée a un et un seul maître) mais c’est malheureusement avec une isolation complète, c’est à dire qu’aucun noeud n’a l’ensemble des informations en lecture. J’y viendrai 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 choisir le maître à utiliser lors de l’écriture.
Je regarde Riak, CouchDB, RethinkDB, Tyrant, Voldemort, Dynomite et quelques autres mais je manque cruellement de retours d’expérience et d’informations pour faire un choix éclairé, si tant est que l’un de ceux là puisse correspondre.
J’ai aussi en tête de faire quelque chose à la main avec une logique applicative par dessus le connecteur Redis, pour qu’il se connecte au bon serveur en fonction du premier caractère de la clef, mais j’aimerai franchement éviter les bidouilles manuelle pour quelque chose qui doit certainement avoir une solution sur étagère.
Dis, lecteur, as tu des liens, des retours d’expérience, des informations, des commentaires ?
-
Hypermedia, quelques recherches pour JSON
Je regarde un peu les implémentations hypermedia 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’utilité de JSON). Maintenant si on veut garder JSON, voilà l’état de mes reflexions :
— Ce billet est en évolution constante, dernière mise à jour le 18 juin 2013 au matin —
Déjà quelques specs liées :
- URI Template : RFC6570
- Web linking : RFC5988
- Profile pour les types de liens : Draft draft-wilde-profile-link-04
- JSON-PATCH : RFC6902
- Syntaxe réduite pour les liens : Curie
Et deux discussions à lire en amont (avec les commentaires, pour les deux) :
- Linking in JSON, Mark Nottingham
- Getting hyper about hypermedia APIs, David Heinermeier Hansson
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’utiliser des URI pour les types de relation
- Ne permet pas d’avoir plusieurs liens (de format différent par exemple) pour une même relation
- Le type de ressource ciblée par une relation peut être spécifié (ce qui me parait superflu : si on connait le sens de la relation, on connait le type ciblé)
- Impose JSON-PATCH
HAL – Hypertext Application Language
- Rendu assez moche (oui, c’est subjectif mais ça compte)
- Gère des espaces de noms via Curie dans les liens et relations
- Utilise (optionnellement) les URI Template (mais ne précise pas où trouver les paramètres)
- Permet de préciser un profile pour qualifier les attributs d’un objet (mais pas de mixer plusieurs vocabulaires)
- Ne permet pas d’avoir plusieurs liens (de format différent par exemple) pour une même relation
- Beaucoup de bibliothèques de code dans pas mal de langages, côté client et côté serveur
- J’échoue complètement à séparer ce une collection ou un attribut complexe et une ressource embarquée, donc à comprendre l’utilité de la clef _embedded
- 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 difficile à implémenter
- Gère un des vocabulaire avec des URI pour qualifier les liens, les clefs, etc. avec même des possibilités d’alias
- Considérant les indirections possibles, trouver le lien avec une valeur spécifique de « rel » est une tâche assez complexe
- Ne gère pas de template pour les liens, mais sait gérer les liens relatifs à une base déclarée plus haut (ce qui compense un peu)
- C’est en voie de standardisation au W3C
- On peut ajouter Hydra par dessus pour décrire les actions (petite présentation)
- Peu d’implémentations clientes (trouvé une PHP et un convertisseur vers RDF en Ruby)
Siren
- Va plus loin que les autres, en décrivant aussi les types d’actions possibles sur la ressources décrite, les paramètres pour les différentes actions, etc. (illusion de pouvoir coder un navigateur 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 enveloppe, les clefs à la racine sont liées à Siren, pas à l’objet décrit
- Pourquoi ici encore séparer les entités liées des propriétés ?
Collection/JSON
Quand on pense avoir saturé, on se rend compte que ce n’est pas fini. J’ai donc trouvé Collection+JSON après les autres. Il permet de définit des gabarit d’attributs pour les ressources, ajoute les liens et les rôles des liens, la notion de collection, et définit les mécanismes d’ajout/recherche.
C’est finalement 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énierie. C’est implémentable de bout en bout.
Quelques pré-conclusions
Certaines spécifications vont bien trop loin à mon goût, et pas toujours en sachant faire correctement la base (éviter les conflits de nommage, pouvoir utiliser des URI pour le vocabulaire, voire des espaces de noms).
Rien que les templates d’URI sont finalement inutiles. Ils permettent de grappiller quelques octets en évitant de taper des liens complets, mais imposent de rédiger un code non négligeable rien que pour reconstruire le lien final, et empêchent de copier un sous-objet en le considérant comme autonome (il ne l’est pas, le template pour son URL est dans l’objet parent).
Alors parler de décrire les actions et les interactions possibles avec chaque objet… En voulant trop en faire on reporte beaucoup de complexité sur le client. On est parfois en train de faire des clients très complexes pour éviter de gérer des informations simples et qu’on va probablement de toutes façons coder en dur quelque part. Ça en devient contre-productif. De ce côté j’apprécie la petitesse de JSON-API.
J’ai encore l’avis qu’imaginer un client HATEOAS complet et générique est illusoire. J’ai juste besoin d’attacher quelques métadonnées comme des liens, des rôles aux liens, et éventuellement un vocabulaire pour les types de données.
Et puis, sérieusement, si c’est pour que le résultat ne soit plus éditable agréablement et présente des structures non naturelles, quel est l’intérêt d’être passé à JSON ?
XML, ou même HTML avec des microdata/formats est définitivement plus adapté que JSON pour ce que je cherche à faire. À JSON il manque au moins un moyen d’attacher des métadonnées à une clef/valeur (par exemple la notion d’attribut sur les nœuds XML/HTML). Avec ça nous pourrions faire un joli format, sans ça ça restera bien moche et peu pratique.
Le problème c’est que développer un client qui fouille des données HTML avec une structure lâche à base de microdata/formats, c’est aussi assez complexe à gérer. Reste le XML « à la main » mais si si je veux que mon API soit utilisée, je crains que JSON ne soit le seul choix pragmatique.
Entre les différentes spécifications
Mon cœur balance entre JSON-API pour sa simplicité (mais réserver le terme « links » me semble juste une aberration), HAL parce qu’il semble de loin (mais ce « _embedded » me gêne toujours, et faire un « _links »: { « self »: { « href »: « xxxxxx » } } juste pour donner le lien du sous-objet courant me inutilement 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 imaginer d’intelligent (mais implémenter la spec complètement risque d’être franchement difficile).
Dans une précédente version de ce billet j’ai tenté un subset de JSON-LD où n’importe quel objet peut contenir :
- un attribut (facultatif) @id, qui est le lien identifiant l’objet
- un attribut (facultatif) @type, qui définit l’URL du type de l’objet (par exemple un type de schema.org) et potentiellement le sens des sous-clefs ou sous-liens.
- un sous-objet (facultatif) @context, qui contient les différents préfixes et adresses utilisables pour les différentes clefs de l’objet (afin de pouvoir mixer plusieurs vocabulaires sans risquer de conflits de noms et de sens).
- un sous-objet (facultatif) @rel, inexistant dans JSON-LD, qui pointe les différents objets liés par leur rôle (attribut « rel » habituel) pour les retrouver facilement (il y a trop d’indirections pour ça dans JSON-LD)
Mais je n’aime pas réinventer la roue, et aussi moche soit-il, HAL contient peut être le principal. Entre une spécification géniale mais trop complexe et sans implémentation cliente, et une spécification plus simple, moche mais bourrée d’implémentations, j’ai du mal à ne pas recommander la seconde. J’ai quand même toujours un peu de mal à voir comment me servir utilement du _embedded.
-
Ateliers sur la documentation webperf
J’ai partagé en ligne il y a quelques temps le début de livre que j’avais rédigé à propos de la performance des sites web.
L’objectif était d’avoir une « bible » qui référence toutes les techniques impactant le temps de chargement des sites web et la théorie sous-jacente. Une moitié du travail était déjà là. C’est sur github, dans un format accessible à tous.
En le posant sur github l’esprit est « ce contenu appartient à ceux qui se l’approprient ». Si vous y participez, ça devient un peu le vôtre. De mon côté ce n’est déjà plus « mon livre » mais un projet communautaire, dont je ne souhaite d’ailleurs pas forcément être le mainteneur ou l’animateur.
Pour initier la dynamique nécessaire, nous avons réalisé deux ateliers : un à Paris fin avril, un dans le cadre de Sudweb la semaine dernière. Il s’agit d’expliquer le projet, puis de réaliser relectures, mises à jour et rédaction par petits groupes. Le projet avance un peu, et chacun repart avec une meilleure connaissance ou des échanges sur un sujet pointu.
Si vous ne savez pas par où commencer vous pouvez commencer par regarder les tickets en cours (« issues » dans la barre de menu github). Ils sont classés par chapitre et par type d’action (relecture, mise à jour, contenu manquant, etc.). Le fichier « HELP.md » à la racine du projet contient aussi un guide de démarrage avec quoi et comment sur différentes questions que vous pourriez vous poser. Vous pouvez aussi simplement vous signaler et poser vos questions sur la liste de diffusion française : https://groups.google.com/group/performance-web?hl=fr
La suite c’est de continuer avec les ateliers. Il faut prévoir un animateur et probablement au moins une personne qui a déjà lu le contenu et saura répondre aux questions techniques webperf. Je compte en proposer quelques uns mais n’hésitez pas à en organiser vous-même dans vos communautés locales. Avec un peu de temps se dégageront certainement 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 relectures, qui s’est traduit via quelques corrections, quelques ajouts, mais aussi une bonne série de tickets qui permettent maintenant de structurer et guider les bonnes volontés.
Un gros merci à tous ceux qui ont participé.
Deux points soulevés :
- En plus de la demie-heure de présentation du projet et du fonctionnement, il faut prévoir des créneaux d’au moins une bonne heure, préférablement une heure et demie. En dessous on manque de temps pour amener un résultat concret.
- La licence initiale était inutilement complexe de façon à garder la possibilité d’embarquer un éditeur papier dans l’aventure. Suite aux différents retours, il apparait plus sage de rebasculer sur une licence ouverte plus simple, peut être une Creative Commons. N’hésitez pas à en discuter ici ou sur la liste de diffusion webperf
Voilà, maintenant c’est à vous de jouer.
-
42 pour une seule école ? ça fait 41 de trop
Bon, une nouvelle école. Quelques réactions :
J’apprécie l’ouverture sans trop faire attention à l’âge. Les formations privées sont trop souvent attachées au cursus avec l’obligation d’enchaîner sans s’arrêter sous peine de devoir passer dans les formations continues spécifiques pour.
J’apprécie aussi l’honnêteté de faire une vraie sélection, sur l’été pour laisser les élèves avoir une porte de sortie avec la fac. Le fait de croire dans une formation de développeur et pas que dans des chefs de projets / ingénieurs, ça me fait aussi plaisir : Il faut recrédibiliser ces postes si on veut avoir des gens compétents.
Technicien expert, C++
On y forme des techniciens, 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 beaucoup de formations actuelles. Je continue à voir une vraie différence entre ceux qui sont formés avec une orientation « ingénieur » et ceux qui sont formés avec une orientation « technicien expert ».
Une école de plus avec de réels techniciens informatiques très pointus, ok, pourquoi pas, voyons plus loin.
On ne cède pas à la mode. Tout s’apprend par C++ dès la première année. C’est la langue obligé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éveloppeurs bas niveau sont trop peu nombreux, mais je questionne la pertinence 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 technologies Microsoft, quelques sections Java, mais pour le reste on repassera : 3 crédits pour apprendre toutes les technologies web (Javascript, PHP, HTML, XML, etc.) et 3 autres pour apprendre en même temps les frameworks web et le e-commerce (Rails, Zend, Ruby, le e-commerce, les cms, les IHM web, et même l’ergonomie web), ça fait franchement chiche, même pour un simple survol Si j’étais méchant je dirai qu’on comprend mieux le pourquoi des interfaces de Free.
Peut être est-ce parce que c’est mon domaine et que j’y attache de l’importance, mais le web me semble l’objet technologique majeur de ces dernières années. Bref, pour moi c’est étrange d’y consacrer si peu. Je ne vois pas les gens apprendre Javascript, PHP, HTML5, Zend Framework, Ruby et Rails comme ça d’un coup.
Quelques points datés
Je continue à tiquer sur GANTT, UML, Merise, ITIL. Je peux le comprendre dans certaines formations. J’ai plus de mal dans une nouvelle formation de zéro, et surtout dans celle là qui est très orientée pratique / technique / développement.
À l’inverse, pour une formation 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 finalement tout ce qui précède reste assez cohérent. On forme des techniciens experts, plutôt bas niveau, dont le haut du panier saura probablement intervenir partout avec aisance et compétence.
Tout juste le programme laisse-t-il apparaître beaucoup de noms de technologies et j’aurais aimé y voir plus d’algorithmie ou de théorie, mais il est tout à fait possible que ce soit abordé à l’occasion des projets.
Je ne vais pas dire que c’est ce que j’aurais choisi en créant une formation, mais ça ne me semble pas mériter toutes les critiques que j’ai vues.
Enrobage marketing
Non, moi ce qui me fait prendre de la distance c’est l’enrobage. Ça pue le mauvais marketing au point que ça en est négatif. J’ai l’impression de retrouver l’EPITA en 97 : tutoiement, on met en avant la création de virus, une épreuve de sélection « ultime et redoutable » (qui élimine 2/3 à 3/4 des candidats, donc bien moins que la plupart des concours ou processus de sélection, dans l’éducatif ou non), le but est plus d’en mettre plein les yeux que d’apparaître sérieux.
On retrouve aussi cet enrobage dans le super marketing « pas de diplôme, l’important ce sont les compétences ». Sauf que le diplôme en France c’est essentiellement un certificat indiquant que tu as suivi une certaine formation. Au lieu d’indiquer « diplôme de master à xxxx » les élèves indiqueront « suivi formation complète à xxx ». S’ils ne le font pas c’est mauvais signe pour la réputation de la formation en question.
Pas de diplôme
Au final ça ne changera donc rien. Ou plutôt si, ça rendra impossible certains emplois publics ou difficile certaines embauches à l’étranger, ça sera irréaliste d’enchaî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 équivalence de diplôme/compétence en Europe.
Je note d’ailleurs que le parcours du DG[*] avec un MBA à HEC ne peut probablement pas être fait dans cette nouvelle école (sauf à reprendre de zéro la prépa HEC) justement à cause du manque de diplôme. Faites ce que je dis, pas ce que je fais. Tout ça pour quoi, un effet de manche marketing ?
En fait là aussi ça me fait beaucoup penser à l’EPITA qui à l’époque se défendait de trouver un intérêt à avoir un diplôme reconnu par la CTI mais qui tentait régulièrement de la demande (et se fera rejeter jusqu’en 2007).
Je me dis que l’absence de diplôme en sortie est probablement dû à l’absence de pré-requis du bac en entrée (ça empêche probablement de faire reconnaître le niveau ensuite par l’État) mais ça aurait été plus honnête de l’exprimer ainsi.
[*] D’ailleurs, c’est moi ou il y a un couac ? Dans son profil Linkedin le DG en question 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écision du master EPITECH 2005 alors que l’école n’est habilitée que depuis 2007. Pire, parce que là il indique une formation entre 1999 et 2005 alors qu’il a fondé l’école et en était le DG à ce moment là (ça me parait un peu incompatible avec l’idée d’en sortir diplômé pour moi). On voit qu’effectivement tout n’est pas clair côté diplômes, et ça n’inspire pas confiance (Je me souviens un peu trop de l’ambiguité entretenue concernant le titre ingénieur à l’EPITA avant qu’ils n’obtiennent l’habilitation).
Formation
Je retrouve encore EPITA dans l’idée qu’ils forment des architectes techniques, des chefs de projets et des experts. J’ai bien parlé de technicien expert plus haut, mais c’est plus pour faire la différence avec nombre de formations de techniciens basiques. Il reste que faire miroiter qu’être architecte ou expert en sortie d’école c’est tromper les élèves. À mon époque certains EPITA croyaient valoir deux fois le salaire d’embauche moyen tellement 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 marketing pour les élèves en manque, ça me rappelle ce que j’ai vu dans d’autres organismes de formation où ce sont les élèves qui donnent les cours aux autres élèves. Ça peut fonctionner, mais ça a aussi de graves manques. C’est aussi juste infaisable au départ.
Si on ajoute que monter une promo de 1000 élèves en une seule année est quasiment infaisable en arrivant à une bonne qualité de formation, j’ai tendance à croire que les cinq premières promo passeront à 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 orientation de technicien expert, la même philosophie vis à vis des diplôme (affirmer que c’est inutile jusqu’à enfin réussir à avoir l’habilitation), le même danger sur la formation en partie assurée par les élèves. Faire des écoles en série ne m’inspire pas tant confiance que ça. La formation n’est cependant pas aussi critiquable que ne le laissent entendre quelques geeks.
Côté résultat, comme les EPITA / EPITECH, il peut en sortir du mauvais comme du bon. Et comme dans les deux autres, il en sortira probablement quelques-uns de très bons, comme une masse qui n’est pas exceptionnelle pour autant. Bref, comme partout : La valeur des gens dépend plus des gens que de la formation.
Vus le système, la promo immense et le côté marketing 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éfinir son API : versionnement
Toujours dans la logique de réfléchir son API, parce qu’un jour il faudra la faire évoluer, comment gérer le versionnement ?
Plusieurs solutions ont émergé :
- https://api-v2.example.com/maressource
- https://api.example.com/v2/maressource
- https://api.example.com/maressource-v2
- https://api.example.com/maressource?v=2
- https://api.example.com/maressource avec une entête Version: 2
- https://api.example.com/maressource avec une entête Accept ou/et Content-type: application/monformat;version=2
La solution du sous-domaine n’est à mon sens à réserver que pour les big-bang. Elle n’est pas facilement multipliable à l’infini, mais à l’avantage de permettre aisément d’avoir même deux plateformes totalement séparées pour les deux versions de l’API.
Les deux suivantes se distinguent par le fait de versionner l’API ou la ressource. J’ai tendance à penser que s’il faut versionner la ressource en cassant la compatibilité, alors c’est peut être une nouvelle version de l’API qui est à publier si on ne veut pas finir avec un gros patchwork difficile à maintenir : En gardant tout sous le même espace on s’interdit de facilement rendre obsolète les anciennes versions.
Quitte à parfois devoir versionner au niveau de la ressource, l’idée d’ajouter un paramètre a fini par me sembler plus propre. Il s’agit quasiment toujours de s’adresser à une représentation différente de la ressource, pas de changer son sens fondamental. Le risque est que la plupart des gens continuent à utiliser la version d’origine et ne pas prendre en compte le paramètre. Rendre obsolète des anciennes représentations risque là aussi d’être difficile.
Les possibilités d’ajouter les versions dans les entêtes sont souvent conseillées d’un point de vue théorique. En pratique mon retour est que c’est complexe à utiliser, et d’une valeur ajoutée assez discutable. On oublie trop facilement que le bon usage de l’API tient directement à sa simplicité et sa bonne compréhension. S’il y a besoin d’être expert en architecture web pour comprendre le pourquoi des choses, c’est une mauvaise solution. Le « tout dans l’URL » ajoute une facilité pour tester et échanger entre techniciens qui vaut toutes les positions académiques du monde.
Twilio a aussi une façon intéressante de gérer les versions. Au lieu d’un v2 ou v3, le développeur indique une date et c’est le serveur qui sélectionne la version de l’API à utiliser en fonction de la date. C’est tentant, souple, mais j’ai peur que ce ne soit pas suffisamment explicite sur ce qu’on utilise ou sur comment gérer ce paramètre. Qu’est-ce qui change si je met à jour la date ?
Des lectures et expériences je tire quelques recommandations :
- Prévoir dès le départ un système de versionnement, vous en aurez besoin un jour, ne croyez pas que vos API pourront rester telles quelles ad vitam eternam
- Imposer un versionnement explicite, immédiatement, dès la première version. Vous éviterez les ambiguïtés et une partie des moules qui s’attachent aux adresses « sans version » par défaut
- N’utiliser 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 compatible c’est une nouvelle version et on incrémente d’une unité. Le reste c’est du marketing et ça n’a rien à faire dans vos URLs.
- Utiliser un versionnement dans l’URL, à la racine du service ; il sera temps d’utiliser un autre sous-domaine si un jour il y a un vrai big bang qui le nécessite
- Documenter (oui, c’est évident, mais pas si simple à ne pas oublier)