Carnet de notes

Catégorie : Technique

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

  • Graphiques à affi­cher – Flotr2

    Il y a long­temps j’uti­li­sais jpgraph puis arti­chow en PHP pour géné­rer toutes sortes de courbes ou camem­berts. Un peu après j’uti­li­sais beau­coup les API google chart, avec pour bonne valeur ajou­tée de ne plus faire de trai­te­ment sur mes serveurs. Le anno­ta­ted time­line est d’ailleurs encore un modèle du genre avec ses anno­ta­tions et ses possi­bi­li­tés de zoom par période.

    J’ai testé plusieurs biblio­thèques javas­cript plus ou moins inté­res­santes mais je suis retombé sur Flotr2 qui génère des images assez lèchées. Pour de l’ap­pli­ca­tif complexe les fonc­tion­na­li­tés de google chart restent avec peu d’équi­valent, mais pour 80% des besoins courants, ça fait le job, et plutôt très bien.

    Vous avez quoi en stock de votre côté pour géné­rer des info­gra­phies de données ?

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

  • Patterns – RubyGems guides

    Pour ma propre archives : Les conven­tions d’or­ga­ni­sa­tion des fichiers et des classes pour les gem Ruby

  • Je veux chan­ger ça, et ça, et ça

    Je pense que je ne suis pas le seul à imagi­ner régu­liè­re­ment comment créer un nouveau langage ou modi­fier les exis­tants à ma conve­nance. Sans aller jusque là, en croi­sant ce qui se fait dans les diffé­rents langages, on trouve toujours des point inté­res­sants qu’on aime­rait voir copiés.

    Voilà donc quelques unes de mes frus­tra­tions, parce que les expri­mer permet de s’en débar­ras­ser un peu et de se concen­trer sur l’im­por­tant : ce qu’on fait avec le langage.

    Persis­tance du code en PHP

    Chaque requête web recharge entiè­re­ment l’ap­pli­ca­tif PHP. APC apporte une béquille indis­pen­sable mais ça reste au niveau de la béquille. Toute l’ini­tia­li­sa­tion est à refaire à chaque fois. Ça fonc­tionne, mais j’ai­me­rai vrai­ment un mode de PHP ou un frame­work web PHP qui permette de commen­cer direc­te­ment au trai­te­ment des requêtes sans avoir à tout refaire de zéro.

    Acces­seurs en PHP

    Toujours côté PHP j’at­tends depuis bien long­temps l’ap­pa­ri­tion d’ac­ces­seurs trans­pa­rents pour les attri­buts des objets. Ruby, Python et Javas­cript ont chacun leur façon de faire. Là il ne s’agit pas de repiquer une syntaxe au langage voisin mais bien de combler un manque.
    Sérieu­se­ment, je n’en peux plus de ces getX() et setX(). C’est encore plus pénible à l’uti­li­sa­tion qu’à la créa­tion.

    Espaces de noms

    Fut un temps je râlais beau­coup contre PHP mais ce dernier une bonne partie du retard qu’il avait. Mieux : Arrivé en dernier il s’est permis de parfois faire les choses plus intel­li­gem­ment.

    Dites, pourquoi n’ai-je pas d’es­paces de nom en Javas­cript ?

    Les « use » de PHP me manquent aussi en Ruby. Ils présentent une solu­tion élégante et pour donner des noms courts en local à des classes qui viennent d’autres espaces de noms, mais ils permettent aussi les alias pour chan­ger faci­le­ment une implé­men­ta­tion par une autre sans impac­ter le code.

    Pendant qu’on y est, pourquoi pas d’auto-char­ge­ment en Ruby ? Si je charge X::Y::Z, j’ai­me­rai bien que le langage se charge tout seul d’al­ler cher­cher le fichier X/Y/Z.rb. Ça fonc­tionne dans quasi­ment tous les autres langages mais Ruby conti­nue de faire du spaghetti d’in­clu­sion manuelle de fichiers.

    Blocs et ferme­tures lexi­cales

    Les blocs sont *la* fonc­tion­na­lité qui me fait utili­ser Ruby. On peut certes faire beau­coup de choses simi­laires avec des fonc­tions anonymes en Javas­cript ou en PHP mais c’est juste moins élégant (et ça compte beau­coup pour se sentir à l’aise).

    Par contre, sérieu­se­ment, la récep­tion des para­mètres dans les blocs est vrai­ment peu lisible. Le choix de la barre verti­cale comme déli­mi­teur est juste illi­sible.

    Le pire arrive avec les ferme­tures lexi­cales. Ruby laisse bien trop faci­le­ment utili­ser par erreur une variable venant de la portée parente. La syntaxe pour forcer une variable comme locale ajoute encore plus au côté non lisible. |x, y=3; z| ? sérieu­se­ment ?

    À côté de ça PHP et Python proposent des variables en lecture seule, ce qui limite la casse. PHP impose même de décla­rer expli­ci­te­ment les variables à impor­ter de la portée parente au lieu de décla­rer les variables locales. Diffi­cile à imagi­ner en monde Ruby mais assez confor­table au final.

    Et vous ? qu’est-ce que vous chan­ge­riez en premier ?

  • La lame de fond nodejs

    En ce moment côté star­tup et inno­va­teurs, les déve­lop­peurs javas­cript ont le vent en poupe. Pour autant, je ne crois pas que Javas­cript côté serveur soit le rouleau compres­seur qu’on veut nous faire croire.

    La syntaxe du langage est honnête, mais a large­ment autant de points néga­tifs que de points posi­tifs par rapport à l’exis­tant ailleurs.

    Si je résume, on me dit que Javas­cript a

    • Une grosse base de déve­lop­peurs à cause de son utili­sa­tion dans les pages web
    • Un runtime exis­tant sur quasi­ment toutes les machines
    • La possi­bi­lité d’avoir un seul langage côté client et côté serveur
    • Un système de proto­type
    • Un système d’event loop, api asyn­chrones et call­backs sur nodejs

    La base d’uti­li­sa­teur est un facteur très impor­tant, mais sur ceux ci une frange très mineure peut se récla­mer d’avoir une bonne connais­sance de Javas­cript. Le niveau moyen est même presque pire que sur PHP. Si on se contente de ceux qui font plus de quelques lignes et qui pour­raient passer côté serveur, la base utili­sa­teur n’est plus si fantas­tique que cela. PHP ou Java en ont proba­ble­ment autant si ce n’est plus.

    On trouve de quoi exécu­ter Javas­cript même sous Windows, mais au final on va instal­ler une machine virtuelle dédiée. Encore une fois, si on parle de côté serveur, Linux et autres BSD sont une bien meilleure cible et là Python ou Ruby sont par défaut, PHP est déployable faci­le­ment, Java est presque partout. Je n’ai jamais entendu dire que l’un des trois premiers souf­frait d’un frein à cause de la néces­sité d’ins­tal­la­tion sur telle ou telle machine.

    La possi­bi­lité d’avoir un seul langage n’est pas à négli­ger, mais au final coder du Javas­cript pour une page web dans le navi­ga­teur n’est pas comme coder du Javas­cript pour nodejs : Les API, les perfor­mances, les besoins, tout ça est diffé­rent. Même sans ça, les partages de code entre client et serveurs reste­ront anec­do­tique, Java en a fait l’ex­pé­rience il y a long­temps. Reste la syntaxe qui est la même, et évite un nouvel appren­tis­sage, mais c’est assez faible. L’ex­per­tise dans un langage est prin­ci­pa­le­ment liée à l’API et à ses impli­ca­tions, la syntaxe de base s’ap­prend rapi­de­ment.

    Le système de proto­type est effec­ti­ve­ment une des spéci­fi­ci­tés de Javas­cript par rapport aux langages courants. Ceci dit c’est un point incom­pris par quasi­ment tous les déve­lop­peurs au point que tous essayent de recréer arti­fi­ciel­le­ment un système de classe au dessus du système de proto­type. Le résul­tat est d’ailleurs un peu bancal. En théo­rie le système de proto­type ça peut être génial. Dans la réalité, sauf pour une petite mino­rité, c’est un gros point noir. Diffi­cile de consi­dé­rer ça comme un avan­tage.

    Il reste un point, parti­cu­lier : Tout l’en­vi­ron­ne­ment Javas­cript côté serveur s’est construit autour d’un système asyn­chrone bourré de call­back. S’il est facile d’y faire de la program­ma­tion spaghetti, c’est aussi une grande force et la plus grande spéci­fi­cité du langage.

    Avoir un système d’évent loop avec des accès asyn­chrones c’est réali­sable sur les autres langages, mais ça prend du temps. Il faut refaire tout un jeu de biblio­thèques. Les quelques essais actuels sont limi­tés, complexes à mettre en oeuvre, et surtout n’ont pas eu le coup de projec­teur qui a lancé nodejs.

    Et c’est un peu ça l’idée : Rien n’em­pêche Ruby, Python ou Java de créer une biblio­thèque équi­va­lente à nodejs. S’il y a une vraie valeur ajou­tée, alors ça se fera. À ce moment là, à part le coup de projec­teur, Javas­cript n’aura plus de quoi prétendre être en avance. Ça restera un bon langage, avec une excel­lente machine virtuelle, qui méri­tera proba­ble­ment d’être côté serveur, mais pas plus que les autres. Je ne vois pas ce qui justi­fiera la lame de fond que certains imaginent.

  • Acces­seurs

    Je déteste avoir à program­mer ou utili­ser des acces­seurs. Voilà, c’est dit.

    Sérieu­se­ment, qui a eu l’idée de faire des méthodes getX() et setX() ? Dans le meilleur des cas c’est pénible a écrire et diffi­cile à lire.

    Qu’on ne me parle pas d’en­cap­su­la­tion, ces méthodes arti­fi­cielles sont tout sauf un besoin d’en­cap­su­la­tion. C’est même exac­te­ment le contraire de l’en­cap­su­la­tion : C’est parce que je n’ai pas à savoir si un attri­but est en accès direct ou non que je n’ai pas à utili­ser d’ac­ces­seurs.

    Il n’est pas besoin d’im­pac­ter la manière dont on appelle les attri­buts d’un objet pour diffé­ren­cier l’in­ter­face publique et les données internes. De nombreux langages on trouvé une manière élégante de gérer les acces­seurs au niveau du langage au lieu de faire faire des pirouettes à l’uti­li­sa­teur. Un des gros avan­tages c’est qu’on ne commence à défi­nir des méthodes d’ac­ces­seur que quand on en a vrai­ment l’uti­lité, pas « partout, au cas où pour plus tard ».

    Donc, quand il s’agit de migrer un attri­but autre­fois en accès direct, en Javas­cript :

    A = { 
  get b() { return this._b; },
  set b(val) { return this._b = val;} 
};
// ou 

A.__defineGetter__("b", function() { return this._b; };
A.__defineSetter__("b", function(val) { return this._b = val; };

    en Ruby :

    class A
  def b
    @b
  end
  def b=(val)
    @b = val
  end
end

    en Python :

    class X(object):
  def getb(self):
    return self._b
  def setb(self, val):
    self._b = val
  b = property(getb, setb)

# ou mieux :

class X(object):
  @property
  def b(self):
    return self._b
  @b.setter
  def b(self, val):
    self._b = val

    Sérieu­se­ment, c’est moins de complexité pour démar­rer du code (pas besoin de déve­lop­per des acces­seurs passe-plat au cas où on en aurait besoin plus tard, on peut s’en occu­per unique­ment quand le besoin arrive), et c’est plus de clarté pour tout ce qui utilise notre code (et là le gain est immense même si ça semble juste quelques carac­tères). Je n’ima­gine pas de m’en passer dans les langages où ça existe.

    Si vous utili­sez des getter et setter passes-plat, c’est soit votre code qui est mauvais, soit votre langage qui est bridé (soit que vous utili­sez consciem­ment un langage bas niveau). Dans les deux premiers cas il y a quelque chose à repen­ser.

    Bien entendu PHP reste à la traine, sous prétexte de simpli­cité (allez comprendre).

  • Évolu­tion de PHP – acces­seurs

    Il y a matière à se réjouir : Le déve­lop­pe­ment et l’évo­lu­tion du langage PHP a repris. Nous avons eu les fonc­tions anonymes, les espaces de nom, et quelques nouveau­tés bien­ve­nues, souvent atten­dues de trèèèèès longue date.

    Bref, ça bouge, bien. Nous avons  cepen­dant encore deux courants très oppo­sés au niveau du langage : L’un qui souhaite le garder simple et « comme il est », avec souvent un histo­rique quick’n dirty, et qui au final freine quasi­ment toutes les évolu­tions. L’autre qui souhaite le voir profon­dé­ment changé, et reprendre les bonnes idées des autres langages, au risque de trop vouloir copier ces autres langages.

    Si je devais cari­ca­tu­rer je dirai qu’une majo­rité des déve­lop­peurs de PHP (surtout les histo­riques) sont ceux qui freinent, et qu’une majo­rité des utili­sa­teurs actifs de PHP sont ceux qui poussent. Si ça bouge depuis PHP 5.3, c’est que l’ex­cès du « on ne touche rien » a provoqué un trop grand ras-le-bol, et les déve­lop­peurs de PHP ont été forcés de mettre de l’eau dans leur vin.

    Malheu­reu­se­ment les deux courants existent toujours et rien n’a été tran­ché. On le voit très bien sur la RFC concer­nant les acces­seurs : Une bonne partie des « contre » sont ceux que je quali­fie de « déve­lop­peurs histo­riques du langage », et une partie des « pour » sont ceux que je quali­fie de « utili­sa­teurs actifs dans le langage ».

    Il est plus que temps de déci­der où l’on va, sinon nous allons conti­nuer à avoir un Fran­ken­stein.