Carnet de notes

Catégorie : Ruby

  • J’ef­face mes traces

    Il y a désor­mais 5 ans que j’ef­face mes traces.

    J’avais fait un petit billet pour expliquer que j’ef­façais mes tweets après 48h. Je l’ai fait un temps mais via des scripts lancés à la main, pour garder le contrôle. Je l’ai fait de façon irré­gu­lière, puis plus du tout pendant un temps.

    La moti­va­tion n’a toute­fois pas chan­gée.

    Je m’y remets avec un script un peu plus évolué qui devrait à terme pouvoir être lancé en auto­ma­tique (quand j’au­rais un peu plus confiance). Désor­mais la plupart de mes tweets pour­ront être suppri­més au bout d’une dizaine de jours.

    Si j’ai le courage j’éten­drai ça à Masto­don et aux autres réseaux. Plus géné­ra­le­ment, tout ce qui n’est pas dans un espace que je contrôle person­nel­le­ment est poten­tiel­le­ment amené à dispa­raitre. Ce qui m’im­porte est géné­ra­le­ment retrans­crit sur le site que vous êtes en train de lire.

  • The Safe Navi­ga­tion Opera­tor (&.) in Ruby

    The most inter­es­ting addi­tion to Ruby 2.3.0 is the Safe Navi­ga­tion Opera­tor(&.). A simi­lar opera­tor has been present in C# and Groovy for a long time with a slightly different syntax – ?.. So what does it do?

    — Georgi Mitrev, via Pascal

    Ruby ayant déjà la possi­bi­lité d’avoir des ? dans le nom des méthodes, il n’y avait pas de syntaxe super classe. Les discus­sions que j’avais vu tour­naient autour de a.?b mais ça deve­nait moche si la méthode termi­nait déjà par ? : a.?b?.

    Au final nous aurons trois syntaxes :

    a && a.b && a.b.c
a.try(:b).try(:c)
a&.b&.c

    La première est ultra verbeuse et retour­nera false si a ou b retourne false. Sauf à ruser avec des variables tempo­raires, on finit par appe­ler a trois fois et b deux fois.

    La seconde méthode est plus sympa, mais longue assez moche à la lecture. Elle est aussi ultra tolé­rante et n’échouera pas même si rien ne retourne nil ou false mais que les méthodes b ou c n’existent pas.

    La dernière née est donc plus stricte. Elle ne sert que si a ou b retournent nil, et dans aucun autre cas. Restera à s’ha­bi­tuer à la syntaxe.

    Atten­tion, nil&.nil? retourne nil. L’opé­ra­teur & a donc la prio­rité sur ce qui suit. C’est logique, mais c’est un coup à se plan­ter si on en fait pas atten­tion.

    Sinon, spéci­fique­ment pour les Hash, même logique avec la méthode dig, là aussi bien­ve­nue :

    a[:b] && a[:b][:c] && a[:b][:c][:d]
a[:b].try(:[], :c).try(:[], :d)
a.fetch(:b, []).fetch(:c, []).fetch(:d, nil)
a.fetch(:b, nil)&.fetch(:c, nil)&.fetch(:d, nil)
a.dig(:b, :c, :d)

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