Carnet de notes

Auteur/autrice : Éric

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

  • People have name (ou pas)

    Et si vous arrê­tiez de deman­der mon nom et prénom ?

    À quoi cela vous sert-il ? Le plus souvent vous avez besoin du nom complet, et basta.

    Envoyer un email avec « Bonjour Nico­las » ? Avez-vous pris en compte que dans certaines cultures ça peut appa­raitre impoli ou même supé­rieur ?

    Et quand vous aurez besoin d’un nom complet, dans quel ordre asso­cie­rez-vous nom et prénom sachant que l’ordre dépend là aussi de la culture ? Ne pas inclure les titres peut aussi appa­raître comme une faute là où en France ou aux États-Unis c’est plutôt la règle.

    Vous aviez besoin du nom de famille pour trier ? Mais qu’a­vez vous prévu pour les « von », « mc », « de », « l’ » et autres préfixes ? Comment triez-vous 小林康宏 ? Et puis pourquoi triez-vous par nom de famille alors que certaines cultures trient par prénom ? Quel nom utili­sez-vous quand il y en a plusieurs alors que certains s’at­tendent à utili­ser le nom prin­ci­pal comme clef et que ce nom n’est pas le premier ?

    Je ne fais état là que de certaines problé­ma­tiques, il y en a bien d’autres. le W3C a une bonne docu­men­ta­tion liée à la gestion des noms en contexte inter­na­tio­nal et ainsi que quelques commen­taires et exemples sur une page distincte. Ne croyez pas que vous pouvez vous en passer en France, les fron­tières ne sont plus étanches depuis long­temps, surtout sur le web.

    Le plus souvent vous pouvez me deman­der mon nom complet, simple­ment. Éven­tuel­le­ment un champ pour le nom lorsque vous vous adres­sez à moi et un champ pour le nom que je souhaite affi­cher publique­ment dans votre service (et il est facile de pré-remplir le second à partir du premier pour que je n’ai à le modi­fier qu’en cas de besoin). Le reste est rare­ment vrai­ment néces­saire, juste une mauvaise habi­tude.

    Allons plus loin, quels sont vos pré-jugés sur les noms ?

    1. People have exactly one cano­ni­cal full name.
    2. People have exactly one full name which they go by.
    3. People have, at this point in time, exactly one cano­ni­cal full name.
    4. People have, at this point in time, one full name which they go by.
    5. People have exactly N names, for any value of N.
    6. People’s names fit within a certain defi­ned amount of space.
    7. People’s names do not change.
    8. People’s names change, but only at a certain enume­ra­ted set of events.
    9. People’s names are writ­ten in ASCII.
    10. People’s names are writ­ten in any single charac­ter set.
    11. People’s names are all mapped in Unicode code points.
    12. People’s names are case sensi­tive.
    13. People’s names are case insen­si­tive.
    14. People’s names some­times have prefixes or suffixes, but you can safely ignore those.
    15. People’s names do not contain numbers.
    16. People’s names are not writ­ten in ALL CAPS.
    17. People’s names are not writ­ten in all lower case letter

    ça conti­nue sur d’autres erreurs courantes (parce que oui, chacune de ces affir­ma­tions est fausse) en termi­nant par …

    1. People have names.

    Alors certes vous pouvez faire des raccour­cis, et vous y êtes bien obli­gés, mais 99% du temps vous allez contraindre voir reje­ter quelqu’un. Les geeks qui se font reje­ter leur adresse email valide parce qu’elle contient un « + » savent de quoi je parle, idem pour ceux qui s’as­treignent à reti­rer leurs accents ou carac­tères non ascii « au cas où ». Réali­sons que, à côté d’autres, nos compro­mis sont quasi­ment inexis­tants.

    Et d’ailleurs, pourquoi un nom ?

    Et si vous ne deman­diez rien fina­le­ment ?
    Avez-vous vrai­ment *besoin* de mon nom ? Vrai­ment ? Vous ne pour­riez rien faire sans ? Pourquoi le rendre obli­ga­toire alors ?

    Je n’ai jamais eu besoin de décli­ner mon iden­tité pour ache­ter du pain ou une paire de chaus­sette au super­mar­ché, pourquoi serait-ce le cas sur Inter­net ?

  • Finis­sons-en avec le 3D Secure actuel

    Vous avez forcé­ment déjà utilisé le 3D Secure lors d’un paie­ment en ligne. C’est le méca­nisme qui, après la saisie des infor­ma­tions de la carte, vous demande un code reçu par mail ou sms, voire un code dans une grille envoyée par la poste ou votre date de nais­sance.

    Côté commerçant ça permet de limi­ter la fraude mais ça augmente aussi drama­tique­ment les aban­dons lors du paie­ment. C’est au point où sauf si vous êtes une cible parti­cu­lière pour la fraude en ligne, les commerçants ont géné­ra­le­ment inté­rêt à désac­ti­ver la fonc­tion­na­lité.

    Bon, et puis sérieu­se­ment, si on vole votre sac, le télé­phone est proba­ble­ment à côté de la carte bancaire et le voleur pourra récu­pé­rer le code mail ou sms. Je ne parle même pas des banques qui demandent la date de nais­sance.

    Il existe pour­tant des solu­tions, des bonnes, avec des jetons tempo­raires direc­te­ment géné­rés par la carte bancaire. Pourquoi n’avons-nous pas ça ? Ça ne coûte­rait pas si cher à produire en plus.

    CodeSe­cure with Dot Matrix LCD (vidéo, commu­niqué de presse Visa, commu­niqué de presse MasterCard).

    Il serait temps de faire arri­ver ça concrè­te­ment sur nos cartes, c’est bien plus perti­nent que leur volonté de nous rajou­ter le paie­ment sans contact troué dont personne ne veut. Quand vous en parlez à votre banque, elle vous dit quoi ?

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

  • Des « entar­teurs » encourent jusqu’à 9 ans de prison

    Entar­ter est désor­mais assi­milé à un atten­tat en Espagne. […] Ils sont accu­sés d’ « atten­tat contre une personne dépo­si­taire de l’au­to­rité publique », avec des demandes du procu­reur allant de 4 à 9 années de prison. […] La juri­dic­tion dépêche égale­ment une commis­sion roga­toire auprès de la France pour qu’elle trans­fère les résul­tats de la recherche d’em­preintes et d’ADN sur les embal­lages des tartes.

    Le problème avec les lois d’ex­cep­tion, c’est qu’elles permettent juste­ment des choses qu’on juge norma­le­ment inac­cep­tables. Nous avons renié beau­coup de nos prin­cipes depuis une quin­zaine d’an­nées.

  • Une minute et trente cinq secondes pour résu­mer le copy­right

    Trop dense pour préci­ser, mais c’est assez court pour que ça vaille le coup de regar­der:

  • Post­mark

    Dans le même esprit que Logen­tries, je tombe sur Post­mark avec des prix rela­ti­ve­ment honnêtes (1,5$ les 1000 mails). Si cela permet de soula­ger le serveur d’un service et d’évi­ter les boites à SPAM, peut être que…

    Vous utili­sez quoi pour envoyer vos mails appli­ca­tifs ?

  • Logen­tries

    Quand je regarde Logen­tries, leurs tarifs, je me dis qu’ils ont trouvé un filon.

    Et vous, vous utili­sez quoi pour analy­ser vos logs ?

  • Élabo­ra­toire sur la docu­men­ta­tion des perfor­mances web

    Il y a quelques temps j’ai relâ­ché publique­ment mon travail initial sur un livre en français dédié à la perfor­mance des sites web. Relâ­cher en public ne suffit pas et pour voir appa­raitre une docu­men­ta­tion utile qui devient pas obso­lète il faut créer une vraie dyna­mique de mise à jour et de comple­tion. Le besoin d’une vraie réfé­rence en français (et même en anglais) est là, et il n’y a pas besoin que d’ex­perts pour y arri­ver.

    Sudweb arrive et j’y anime­rai un élabo­ra­toire. Je vous propose d’y travailler ensemble à la docu­men­ta­tion des pratiques et des problé­ma­tiques de perfor­mance. L’objec­tif est de réamor­cer une dyna­mique qui permette d’ar­ri­ver à un contenu utile et mis à jour.

    Pour que la session soit effi­cace il faut prépa­rer un peu :

    En préa­lable il faut réus­sir à poin­ter un maxi­mum le contenu manquant ou à réécrire. Si vous avez peu de temps, choi­sis­sez un sujet qui vous semble perti­nent. Ce peut être une problé­ma­tique croi­sée récem­ment, un sujet abordé dans un billet de blog ou un point tech­nique plus géné­ral. Ce peut être un sujet bateau, une problé­ma­tique très poin­tue ou un point de détail (même très en détail, n’ayez pas peur). Peu importe en fait, si le contenu est manquant ou à mettre à jour : Créez un ticket sur github pour le signa­ler.

    C’est là que vous pouvez aider, et c’est ça qui peut nous permettre d’avoir un contenu de réfé­rence utile et perti­nent au sujet de la perfor­mance web. Je répète : *Vous* pouvez aider. Oui, *vous* aussi, même si vous ne venez pas (mais je vous encou­rage à venir).

    Tout le monde peut parti­ci­per et y inves­tir le temps qu’il peut, même 10 minutes, quel que soit le niveau tech­nique. Si vous ne savez pas par quoi commen­cer regar­der vos dix lectures précé­dentes côté perfor­mance web et véri­fiez que tout ce qui vous semble utile est présent dans le contenu actuel. Mieux : À partir de main­te­nant faites un tour à chaque fois que vous lisez quelque chose sur la perfor­mance pour véri­fier si c’est déjà dans le livre.

    En avril nous ferons un second travail de quali­fi­ca­tion et de regrou­pe­ment pour tenter de consti­tuer des groupes de tâches avec des objec­tifs précis et réali­sables pour Sudweb.

    Merci de votre aide et n’hé­si­tez pas à relayer ce billet.