Carnet de notes

Auteur/autrice : Éric

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

  • Trajet boulot dodo

    J’ai l’im­mense chance d’ha­bi­ter près de mon job, 20 minutes à pied. Pour contre-balan­cer je suis aussi un grand fainéant. Je cherche donc à éviter cette marche à pied de 40 minutes aller-retour, soit pour la réduire en temps de trajet soit pour la rendre plus confor­table.

    Je prends souvent le tram sur deux arrêts, mais ça me laisse encore 10 grosses minutes à pied et plusieurs minutes d’at­tente. C’est plus par parce que je n’ai toujours pas rési­lié mon abon­ne­ment de trans­port en commun. Je ne gagne pas signi­fi­ca­ti­ve­ment en temps de trajet total et ça n’a d’in­té­rêt que parce que je suis assis un peu plus au chaud. Sauf très forte pluie, ça ne se justi­fie pas vrai­ment et même ma fainéan­tise ne sera pas assez forte pour que je consi­dère ça comme une solu­tion.

    L’idéal pour ce type de trajet serait une bonne trot­ti­nette mais j’ai aussi une belle pente sur la moitié du trajet. Ce n’est pas énorme, dans les 5% au jugé, mais assez pour rendre la trot­ti­nette trop peu pratique.

    Reste le vélo mais mon côté fainéant reprend le dessus consi­dé­rant la pente à 5% (la montée se ferait le soir, quand je suis crevé). Du coup je regarde l’as­sis­tance élec­trique. Ça coûte cher, surtout si je ne l’uti­lise pas tous les jours (le vélo sous la pluie ne m’at­tire pas), donc j’ai un peu de mal à vrai­ment l’en­vi­sa­ger.

    Vous voyez un autre moyen de trans­port à envi­sa­ger ? Avez-vous des recom­man­da­tions ?

  • Adieu SSII, bonjour ESN !

    Est-ce qu’un chan­ge­ment de nom de SSII vers ESN va suffire à faire oublier leur répu­ta­tion sulfu­reuse (et souvent méri­tée) ? C’est pour­tant pour moi la seule moti­va­tion crédible à cette propo­si­tion. Je doute que « service numé­rique » soit signi­fi­ca­ti­ve­ment plus perti­nent, ou que la valeur ajou­tée renta­bi­li­sait le chan­ge­ment de nom.

    Bref, c’est unique­ment du marke­ting et le Syntec ferait mieux de faire évoluer les pratiques que de chan­ger l’em­bal­lage.

    Au moins nous avons évité l’ESD : l’en­tre­prise de services digi­taux. Je ne comprends toujours pas comment on peut faire confiance à toutes ses agences qui se disent expertes du web et du numé­rique et qui pour­tant ne se rendent même pas compte qu’elles utilisent le terme « digi­tal » de travers.

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

  • L’im­plo­sion du système Dassault pour ceux qui ont raté le début

    Le tireur présumé, en fuite, s’ap­pelle Younès B. Son nom a fuité très vite. L’homme serait un proche de Serge Dassault d’après Le Point et le Canard enchaîné, qui déroule son CV :

    • chauf­feur du colis­tier de Serge Dassault, qu’il a rencon­tré en 1995 ;
    • emploi-jeune à la mairie de Corbeil ;
    • créa­teur d’une entre­prise en affaires avec la ville ;
    • homme de main de l’an­cien maire, dans les dépla­ce­ments, les soirées élec­to­rales et pour les missions plus discrètes :

    […]

    La victime, elle, fait partie (toujours selon le Canard), des jeunes de cités qui ont dénoncé en 2010 l’achat de votes par Serge Dassault, avant de se rétrac­ter.

    Si le scan­dale Dassault se confirme, je ne peux qu’es­pé­rer qu’il fasse élec­tro­choc.

    « – Je veux vous remer­cier tous de ce que vous avez fait, car c’est vrai que c’est en grande partie grâce à vous et je le sais. Les collages la nuit, etc.

    – De toute façon, pour nous monsieur le maire c’était clair et net, nous on voulait que ça soit Serge Dassault. Parce que nous on est une géné­ra­tion de personnes qui avons grandi avec vous. […] Lui il souhaite monter quelque chose en restau­ra­tion, moi c’est ma licence de taxi, on souhaite savoir si vous pouvez nous aider. […]

    – D’ac­cord. Pratique­ment pour vous aider c’est 30 000 euros ? Et vous aussi ?

    – Fran­che­ment l’idéal, moi je vous le dis, j’ai pas osé tout à l’heure, mais main­te­nant j’ose vous le dire, mais fran­che­ment la somme idéale c’est de commen­cer avec 80 000 euros.

    – Et moi mon frère, il a l’am­bi­tion de créer une société de trans­port inter­na­tio­nal. Et ça repré­sente une somme de 100 000 euros. […]

    – Mais si vous dispa­rais­sez tous, moi après j’ai plus personne !

    – Devant vous vous avez sept jeunes qui sont prêts à rele­ver leurs manches. Ils seront toujours actifs sur Corbeil parce qu’on a tous grandi à Corbeil. On ne va pas vous aban­don­ner comme vous avez vu monsieur. »

  • Fin de Google Reader – Alter­na­tive

    Notre nouveau pape est là depuis juste quelques heures, qu’on annonce déjà la fin de Google Reader. Peut être pour mettre en avant Google+, peut être simple­ment parce que ça ne permet pas d’y mettre de la pub et que ça coûte cher.

    Quelques solu­tions (je ne prends en compte que ceux qui me semblent aptes à servir d’agré­ga­teur pour un nombre de flux à trois chiffres. Les jolies vues qui présentent 10 articles avec des belles photos ou celles qui proposent une boite pour chaque flux avec ses trois derniers billets sont donc à priori exclues (je classe Netvibes dans ces caté­go­ries à priori).

    À héber­ger chez vous :

    Leed : du PHP à instal­ler avec un cron pour parcou­rir les RSS. Il y a une vue smart­phone mais il manque les raccour­cis claviers. La vue est pagi­née, une fois lu/sauté les items d’une page, il faut rafrai­chir la page en cours (pas passer à la suivante sinon les 10 items suivants passe­ront en première page et seront igno­rés). Je n’ai pas l’im­pres­sion du même côté pratique que Google Reader. La FAQ me donne aussi une petite crainte sur la jeunesse du code.

    rssLounge : Assez peu d’in­for­ma­tions, si ce n’est qu’il gère les flux de photos et qu’il permet de gérer des prio­ri­tés suivant les flux. Cette dernière fonc­tion­na­lité peut être inté­res­sante. Il y a aussi un jeu de raccour­cis clavier. Je n’ai pas testé la visua­li­sa­tion pour mobile. Le projet semble de toutes façons mort depuis novembre 2011, ce qui n’est pas un bon signe.

    TinyTi­nyRSS : L’es­sen­tiel des liens sont morts, donc diffi­cile d’en savoir plus. Si ce n’est que c’est actif (dernière version hier), qu’il y a une API, des raccour­cis, et même une appli­ca­tion Android native (payante mais open source, à vous de recom­pi­ler l’ap­pli­ca­tion si besoin). La capture d’écran par défaut semble quand même bien moche.

    Service tiers :

    The Old Reader : Peut être celui qui ressemble le plus à Google Reader, avec une vue mobile, des raccour­cis, un fonc­tion­ne­ment simi­laire. Il y a même une inté­gra­tion Pocket. Si vous souhai­tez un clone, le voilà. Le fait qu’il demande l’ac­cès au carnet d’adresse Google pour s’iden­ti­fier est toute­fois assez bloquant. Certaines actions sont aussi parfois un peu lentes et ils ne parlent à aucun moment d’une API dispo­nible pour des tiers.

    Feedly : Complet, il présente pas mal de vues diffé­rentes, des raccour­cis, des applis sur les diffé­rents navi­ga­teurs et systèmes mobiles. Il fut basé sur Google Reader mais commence une migra­tion vers ses propres solu­tions, avec pour objec­tif d’ou­vrir aussi leur API (mais pour l’ins­tant c’est une promesse). Diffi­cile de dire ce que ça donnera ensuite. Le fait d’im­po­ser des exten­sions de navi­ga­teur mais pas d’in­ter­face web directe me gêne un peu : Impos­sible à consul­ter sur le poste de quelqu’un d’autre.

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

  • L’in­ter­dic­tion du cumul des mandats va être repous­sée en 2016–2017

    Le problème pour les réformes du système poli­tique, c’est qu’il faut forcé­ment frois­ser des inté­rêts person­nels d’élus. Si on ajoute la crainte de perdre, il y a à chaque fois de bonnes raisons de recu­ler.

    Du coup…. 2016 – 2017 pour l’in­ter­dic­tion du cumul des mandats, et même proba­ble­ment un peu plus parce qu’il n’y a pas de raisons qu’on ne recule pas encore une fois.

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