Carnet de notes

Catégorie : Développement informatique

  • Blanc sur orange, c’est noir sur noir

    Parce que ça m’a servi récem­ment, ça peut servir à d’autres.

    Du vert clair sur du blanc c’est illi­sible. Du marron sur du noir, c’est illi­sible. Quelle est la limite, le blanc sur orange est-il lisible ? Se fier à sa propre vision c’est oublier que tous n’ont pas les mêmes diffi­cul­tés, et oublier le contexte diffé­rent entre le visi­teur et le créa­teur de l’illus­tra­tion.

    Donc pour avoir une mesure objec­tive, je vous recom­mande la lecture du billet Open­web (une ressource excel­lente qui n’est jamais assez recom­man­dée), et l’ou­til Contrast-A. Par la même occa­sion faites atten­tion aux diffé­rents dalto­niens : Ça repré­sente tout de même presque 10% de la popu­la­tion mascu­line.

    J’en profite : même si c’est proba­ble­ment ce que je fais ici, vous avez en géné­ral inté­rêt à ne pas faire du noir sur blanc et encore moins du blanc sur noir. Atté­nuer le noir, voire le blanc, est souvent une bonne idée même si c’est moins épatant lors des présen­ta­tions à la direc­tion.

  • Parcou­rir des dossiers et filtrer les fichiers n’a jamais été aussi simple avec la SPL de PHP5

    Parcou­rir les fichiers c’est simple avec PHP 5 et la SPL. Ou pas.

    <?php
 class bigFileFilterIterator extends FilterIterator {
     public function accept() {
         $oFileInfo = $this->getInnerIterator()->current();
         return ($oFileInfo->getSize() > 10000);
     }
 }
 $themedir = __DIR__.'/theme';
 $iterator = new RecursiveDirectoryIterator($themedir, FilesystemIterator::SKIP_DOTS);
 $iterator->setFlags(FilesystemIterator::CURRENT_AS_FILEINFO);
 $recursiveIterator = new RecursiveIteratorIterator($iterator);
 foreach(new bigFileFilterIterator($recursiveIterator) as $file) {
     echo $file->getfilename()."n";
 }

    Sérieu­se­ment ? Mais pourquoi ne puis-je pas utili­ser direc­te­ment le Recur­si­veDi­rec­to­ryI­te­ra­tor et dois-je instan­cier un Recur­si­veI­te­ra­torI­te­ra­tor ? Celui qui a conçu cette dernière classe souffre-t-il de bégaye­ment ? Rien que l’ins­tan­cia­tion du premier itéra­teur ne tient pas sur une seule ligne. Un ->getIn­nerI­te­ra­tor()->current() et pas un para­mètre direc­te­ment dans la méthode ->accept() ? Sérieu­se­ment ?

    Montrer les nouvelles possi­bi­li­tés c’est appré­ciable, les quali­fier de simple est une insulte à l’in­tel­li­gence.

    De mon temps on faisait quelque chose comme ce qui suit :

    <?php
 function recursive_filter($path) {
     $dir = dir($path) ;
     while (false !== ($name = $dir->read())) {
         if ($name[0] === '.') return ;
         $new_path = $path.DIRECTORY_SEPARATOR.$name ;
         if (is_dir($new_path)) {
             recursive_filter($new_path) ;
         } elsif (file_size($new_path) > 10000) {
             echo $new_path ;
         }
     }
 }
 $themedir = __DIR__.'/theme';
 recursive_filter( $themedir ) ;

    Ce n’était pas plus court, mais pas plus long. On peut entrer dans de longs discours pour savoir si c’était plus simple ou plus complexe, mieux struc­turé ou non, mais la valeur ajou­tée du nouveau code ne saute pas aux yeux côté simpli­cité je trouve.

    À titre d’exemple, en ruby (« find » est dans la lib stan­dard) :

    require 'find'
 theme_dir = File.dirname(__FILE__)."/theme"
 Find.find(theme_dir) do |path|
     next if FileTest.directory?(path)
     puts path if FileTest.size(path) > 10000
 end

    Ou sur Python :

    import os
 themedir = os.path.join(os.path.dirname(__file__), "theme")
 def find_files(directory):
   for root, dirs, files in os.walk(directory):
     for basename in files:
       if not file.startswith("."):
         filename = os.path.join(root, basename)
         yield filenames
 for filename in find_file(themedir)
   if os.path.getsize(filename) > 10000 :
     print filename

    Il peut y avoir des fautes et il peut y avoir mieux dans les diffé­rents langages, et peu importe le nombre de lignes, mais dans les quatre codes précé­dents c’est bien le premier qui me semble complexe.

    Il y a bien d’autres occa­sions de trou­ver PHP « simple », mais pas les itéra­teurs de la SPL.

  • Récu­pé­rer les pull request github en local

    Parce que les bonnes astuces néces­sitent d’être parta­gées : Pour récu­pé­rer en local le contenu des « pull request » de github

  • Retour sur la première semaine – livre webperf

    J’ai ouvert le projet pour parta­ger mon début de livre sur la perfor­mance des sites web via github il y a une petite semaine. Il est temps de faire un premier point.

    Tout d’abord « merci ». J’ai eu plus de retours que je n’en espé­rais la première semaine. Le niveau de correc­tion des premier chapitres a dépassé celui des multiples relec­tures que dont j’avais déjà pu béné­fi­cier. Ce n’est pas grand chose en soi mais une multi­pli­ca­tion de petites fautes, c’est ce qui fait la diffé­rence entre une bonne lecture et un livre pénible à ouvrir.

    Au niveau de la tech­nique je confirme tous les techos qui disent que github est un bonheur. Le système de pull request et de commen­taires asso­ciés est infi­ni­ment mieux que ce que je faisais dans un pas si loin­tain passé avec des patchs envoyés par mail. La faci­lité de contri­bu­tion vient de là. Je regrette toute­fois ne pas pouvoir exclure/inclure ligne à ligne une contri­bu­tion envoyée par pull request. Là c’est du tout ou rien, et c’est dommage pour ce projet parti­cu­lier.

    Le contenu a lui été converti bien plus vite que prévu grâce à la contri­bu­tion de Yoav. Pour ceux qui le souhaitent, il y a désor­mais un script de conver­sion ODT -> Pandoc qui produit un code assez bon.

    Le gros défi à venir c’est l’évo­lu­tion de ce contenu. Jusqu’à main­te­nant les contri­bu­tions se sont concen­trées exclu­si­ve­ment sur des correc­tions de typo ou de formu­la­tion, et deux sur les outils. Pour que le projet vive, pour que je n’en sois plus le seul déten­teur, et pour arri­ver à un contenu complet, il faut que le contenu soit mis à jour, enri­chi et étendu.

    Bref, main­te­nant nous avons (aussi) besoin de contri­bu­teurs sur le contenu lui-même. N’ayez pas peur, c’est un très bon moyen de progres­ser et de se confron­ter aux autres. Il n’y a pas de risques à part celui d’ap­prendre.

  • Livre colla­bo­ra­tif, c’est lancé

    Voilà, c’est fait. J’ai commencé la retrans­crip­tion de mon livre sur la perfor­mance des sites web vers github pour en faire un projet colla­bo­ra­tif.

    Vous retrou­ve­rez l’avant-propos et le premier chapitre d’in­tro­duc­tion. Pour la suite je vais avoir besoin de vous comme promis :

    • Vous avez un bon français écrit ? Nous avons besoin de relec­ture pour corri­ger les rares fautes, pour amélio­rer les formu­la­tions, reti­rer les répé­ti­tions, réali­ser un meilleur décou­page des para­graphes et globa­le­ment rele­ver le niveau de français.
    • Vous n’avez pas peu de faire un peu de code simple ? Nous avons besoin de personnes pour retrans­crire les fichiers sources OpenDo­cu­ment en fichiers Mark­down avec illus­tra­tions jointes. Nous avons aussi besoin de gens pour véri­fier et corri­ger la produc­tion de ces fichiers Mark­down, amélio­rer la qualité des illus­tra­tions et créer des scripts d’au­to­ma­ti­sa­tion.
    • Vous vous y connais­sez un peu ? Il faut mettre à jour les conte­nus, ajou­ter les dernières décou­vertes, docu­men­ter les amélio­ra­tions des navi­ga­teurs, enri­chir le contenu, et complé­ter les chapitres manquants.

    Pour l’heure c’est assez simple : Si vous voulez amélio­rer l’exis­tant il suffit de faire un fork sous github, modi­fier ce qui vous semble à chan­ger et envoyer une pull request. L’in­ves­tis­se­ment est quasi nul.

    Si vous voulez aider à complé­ter l’exis­tant le mieux est de m’écrire ou commen­ter ci-dessous avec le temps dont vous dispo­sez pour que je vous envoie une partie du docu­ment source. Pour réfé­rence j’ai fait le chapitre 1 en envi­ron 3 heures, mais rien n’in­ter­dit de prendre une partie plus petite. L’idée est de faire des aller-retour sur 2 à 3 jours tout au plus, en préfé­rant beau­coup de petits pas à un très gros. Même une heure de travail permet de faire avan­cer les choses.

  • Livre en rédac­tion commu­nau­taire – Licence

    Les condi­tions et licences du livre que je compte relâ­cher sont en pleine réflexion. Je suis preneur de vos avis et de vos commen­taires, tout peut chan­ger en fonc­tion des diffé­rents retours.

    Pour faire court, le prin­ci­pal

    Ce billet est long, afin d’ex­pliquer mes choix et permettre d’avoir des retours argu­men­tés sur des points précis plutôt que des opinions géné­rales. Pour ceux qui ne liront pas tout :

    Je consi­dère que le livre appar­tient à ses auteurs et contri­bu­teurs. C’est à ceux qui contri­buent que revient(dra) le choix des condi­tions de diffu­sion.

    Un des modèles possibles est de leur réser­ver les usages commer­ciaux ou sous forme de livre, soit pour une durée fixe soit le temps de recueillir une certaine somme comme rétri­bu­tion du temps passé.

    Ce n’est pas le seul modèle et il est aussi tout à fait possible que le choix se porte sur une licence libre, mais il serait préma­turé de faire un tel choix avant que le contenu ne soit mature et que les contri­bu­teurs prin­ci­paux aient rejoint le projet.

    En plus des raisons expo­sées précé­dem­ment, l’objec­tif prin­ci­pal – et unique le temps que le contenu ait atteint un stade mature – est de voir le livre enri­chi et complété pour en faire une œuvre complète qui ait un sens – ce qu’elle n’est pas dans son état inachevé actuel.

    Ainsi, les droits accor­dés le sont pour l’ins­tant avec l’unique objec­tif de permettre le travail colla­bo­ra­tif, à l’ex­clu­sion de tout autre usage. Le reste sera décidé plus tard.

    Brouillon de condi­tions de réuti­li­sa­tion

    Tous les usages sont auto­ri­sés s’ils sont à titre privé et indi­vi­duel, sans redif­fu­sion ni partage.

    La redis­tri­bu­tion ou la diffu­sion du contenu verba­tim ou modi­fié, ainsi que les travaux déri­vés, sont auto­ri­sés aux condi­tions cumu­la­tives suivantes :

    1. Conser­va­tion du cartouche d’in­for­ma­tion mis à jour et mis en avant de façon claire, évidente et visible pour le lecteur et le contri­bu­teur
    2. Se faire sous la même forme et archi­tec­ture que l’œuvre d’ori­gine (pas de conver­sion vers un autre format ou un autre support par exemple)
    3. Ne pas avoir pour objet ou inten­tion de rempla­cer l’œuvre d’ori­gine
    4. Se faire sous les mêmes exactes condi­tions, qui ne peuvent être plus restric­tives
    5. Ne pas se faire à titre commer­cial ou publi­ci­taire
    6. Donner au groupe main­te­neur du contenu d’ori­gine un droit non exclu­sif et délé­gable de repré­sen­ta­tion, d’adap­ta­tion, de traduc­tion, d’ex­ploi­ta­tion, de diffu­sion, et d’uti­li­sa­tion, totale ou partielle, à titre commer­cial ou non, sur tout support (dont en parti­cu­lier : support numé­rique, papier, vidéo et audio – ce qui inclut entre autres les livres, revues, articles, présen­ta­tions, mémos, dépliants et affiches sous formes papier, fichier numé­rique, disque, bande, et strea­ming), dans le monde entier et pour la durée maxi­male prévue par le droit d’au­teur, sur les modi­fi­ca­tions et travaux déri­vés ainsi diffu­sés ainsi que sur les produits déri­vés qui pour­raient en décou­ler.

    Est consi­déré comme travail dérivé tout contenu incluant tout ou partie du contenu d’ori­gine ou/et qui ne peut être raison­na­ble­ment consi­déré comme indé­pen­dant de ce contenu d’ori­gine.

    L’ac­cep­ta­tion de ces condi­tions n’est pas requise mais sans ces condi­tions et leur accep­ta­tion, vous n’avez aucun droit d’uti­li­sa­tion et encore moins de diffu­sion sur le contenu.

    La distri­bu­tion du contenu protégé ou d’une œuvre déri­vée en ayant connais­sance des présentes condi­tions est consi­déré comme une accep­ta­tion des présentes condi­tions et en parti­cu­lier de la cession d’une licence non exclu­sive sur le contenu diffusé, tel que prévu au point 6.

    Le cartouche d’in­for­ma­tion

    Il reste à faire mais inclura les éléments suivants :

    • Le titre et l’adresse – avec un lien – du contenu d’ori­gine
    • La mention de tous les auteurs signi­fi­ca­tifs de l’œuvre d’ori­gine
    • S’il s’agit d’un contenu modi­fié ou d’une œuvre déri­vée :
      • La mention expli­cite que le contenu a été modi­fié et de quel contenu il dérive – avec un lien ou à défaut les coor­don­nées les plus complètes possibles
      • Au choix de la personne qui distri­bue, pour l’im­po­ser aux suivants s’il le souhaite, la mention de tous les auteurs signi­fi­ca­tifs de l’œuvre modi­fiée ou déri­vée
      • Les condi­tions d’usage et de redis­tri­bu­tion
      • La date de dernière modi­fi­ca­tion du contenu

    Notion d’au­teur signi­fi­ca­tif et répar­ti­tion des usages commer­ciaux

    Mon objec­tif est que les usages commer­ciaux pour l’ins­tant réser­vés béné­fi­cient à tous les auteurs. Il peut toute­fois être diffi­cile et inuti­le­ment complexe de prendre en compte des dizaines ou des centaines de contri­bu­tions unitaires réduites à des correc­tions de typo­gra­phie. Surtout, il sera impos­sible de prendre une quel­conque déci­sion d’ou­ver­ture sous licence libre s’il faut obte­nir l’ac­cord de plus qu’un groupe restreint.

    J’en­vi­sage donc de consi­dé­rer un groupe d’au­teurs « signi­fi­ca­tifs », c’est à dire étant à l’ori­gine d’au moins 10 % du travail réalisé sur l’œuvre. C’est à ce groupe que sont donnés les droits dans le cadre des condi­tions de réuti­li­sa­tion et que sont réser­vés les usages commer­ciaux éven­tuels. Les déci­sions et redis­tri­bu­tions pécu­niaires éven­tuelles peuvent être faites au pro-rata de la parti­ci­pa­tion.

    Tout ça est à discu­ter

    Tout ce qui précède est à discu­ter, rien n’est fixé et tout peut chan­ger du tout au tout en fonc­tion de vos commen­taires. Toute­fois, la voix de ceux qui comptent effec­ti­ve­ment contri­buer et si possible signi­fi­ca­ti­ve­ment seront les seules qui auront une forte influence.

  • Livre webperf, appel aux bonnes volon­tés

    Il est temps de faire le deuil de la forme du projet initial. J’ai commencé à écrire un livre tech­nique sur les temps de réponses des sites web il y a main­te­nant quelques années.

    Un livre ça prend du temps

    Suite à des chan­ge­ments profes­sion­nels et person­nels succes­sifs j’ai eu de moins en moins de temps à y accor­der et la rédac­tion plafonne irré­mé­dia­ble­ment à 50%. Ces derniers temps je consi­dère même que ce taux de 50% est en chute libre car le contenu vieillit en regard des capa­ci­tés actuelles des navi­ga­teurs et en regard de l’état de l’art. Voir mourir ce contenu dans lequel j’ai tant inves­tit me semble trop diffi­cile.

    J’ai tenté d’y inves­tir un peu plus de temps, de me faire accom­pa­gner par un auteur secon­daire, de co-écrire, ou même de donner ce contenu à un auteur qui pour­rait prendre la suite mais à chaque fois il est évident que le travail est énorme et que peu de gens sont à la fois suffi­sam­ment experts et avec assez de temps libre.

    Un projet commu­nau­taire ce n’est pas magique

    Je crois pas vrai­ment à l’idée qu’il suffise de relâ­cher le contenu dans la commu­nauté pour qu’il soit magique­ment mis à jour et enri­chi. Cela peut fonc­tion­ner le premier mois mais ensuite cela demande un réel inves­tis­se­ment avec des relec­teurs, des gens pour animer, pour coor­don­ner, et surtout de vraies bonnes volon­tés pour contri­buer plusieurs heures.

    « L’ef­fet Wiki­pe­dia » n’est pas si courant. On compte plus de projets délais­sés que de projets main­te­nus acti­ve­ment et même côté webperf il y a eu des expé­riences malheu­reuses en anglais. Relâ­cher son bébé dans la nature est toujours diffi­cile mais si c’est pour le voir mourir en public c’est encore plus frus­trant.

    Essayons, le travail à faire

    Ceci étant dit, ça vaut le coup d’es­sayer. L’objec­tif à court terme c’est extraire et conver­tir le contenu prove­nant d’un trai­te­ment de texte vers un format adapté pour un travail à plusieurs, proba­ble­ment du Mark­down ou équi­valent, avec des fichiers par chapitre ou sous-chapitre. Les images doivent être extraites, taillées, et orga­ni­sées de façon cohé­rente. Ensuite, une fois sous github, on pourra voir qui se sent de travailler.

    Un autre billet suivra sur la ques­tion des droits d’au­teurs et de la licence, ça mérite plus qu’un para­graphe. Entre temps je cherche des gens que ça inté­resse suffi­sam­ment pour envi­sa­ger d’ai­der à cette première étape d’ex­trac­tion et conver­sion. Il s’agit d’un vrai travail, qui pren­dra du temps et qui néces­si­tera des trai­te­ments manuels. Ne vous propo­sez pas si c’est juste pour penser « ouais c’est génial » sans arri­ver à déga­ger des heures de temps libre sur le sujet.

  • X-UA-Compa­tible : IE=Edge

    Je rage devant tous ces affi­cio­na­dos qui veulent être à la pointe et qui tout en crachant sur les mode de compa­ti­bi­lité et doctype swit­ching, forcent les futurs navi­ga­teurs à repro­duire les mêmes problèmes.

    N’uti­li­sez pas « X-UA-Compa­tible : IE=Edge ». C’est inutile et contre-produc­tif.

    Un pari risqué sur l’ave­nir

    Avec cette entête, on déclare expli­ci­te­ment une compa­ti­bi­lité avec tout moteur Inter­net Explo­rer futur. Celui de dans deux ans ou celui de dans cinq ans.

    Avec le passé des navi­ga­teurs, l’his­toire du doctype swit­ching, les modes de compa­ti­bi­lité et les ruptures de compa­ti­bi­lité diverses, c’est quand même un pari qui semble perdu d’avance.

    La ques­tion n’est pas telle­ment de savoir si vous codez « stan­dard », mais que le stan­dard peut évoluer ou se préci­ser, que certaines fonc­tion­na­li­tés peuvent être aban­don­nées, ou que certains bugs peuvent être corri­gés en intro­dui­sant des effets de bords sur vos pages. Même ceux qui codent « stan­dard » jusqu’au bout des ongles choi­sissent en géné­ral tel ou tel montage pour contour­ner les manques ou diffé­rences des navi­ga­teurs et que ces manques et diffé­rences évoluent avec le temps.

    Le problème n’est pas vos pages ou votre code, c’est l’en­vi­ron­ne­ment autour.

    Et encore, je laisse de côté ceux qui s’at­tachent telle­ment fort aux stan­dards qu’ils finissent pas n’uti­li­ser que des fonc­tion­na­li­tés avant leur stabi­li­sa­tion voire avec préfixées dans des versions de test. Eux *vont* des problèmes, mais ils le méritent.

    … (le plus souvent) inutile

    Le système est fait pour trois cas :

    • Permettre à un site codé pour une ancienne version d’In­ter­net Explo­rer et non compa­tible avec les suivantes, de bloquer le moteur de rendu à cette version précise.
    • Permettre à un intra­net ou à un site autre­fois liste noire pour incom­pa­ti­bi­lité histo­rique, après une refonte et en atten­dant d’être retiré des listes noires, de décla­rer pouvoir/vouloir désor­mais utili­ser les versions récentes du moteur d’In­ter­net Explo­rer.
    • Permettre à un site incom­pa­tible avec les anciennes versions d’In­ter­net Explo­rer d’être embarqué via une iframe dans un site non compa­tible (soit sur liste noire, soit qui demande expli­ci­te­ment une ancienne version du moteur)

    Si vous n’êtes pas dans un de ces trois cas, il est très probable que vous n’ayez pas besoin d’une entête X-UA-Compa­tible. Pour utili­ser la dernière version respec­tueuse des normes du moteur d’In­ter­net Explo­rer, il vous suffit de coder des pages valides avec un doctype correct et sans prologue XML.

    Sauf à être dans un des cas précé­dents, le X-UA-Compa­tible n’ap­por­tera rien de plus à part les effets néga­tifs qui seront décrits plus haut.

    Mais si vous souhai­tez quand même un opt-in

    Même si vous vous retrou­vez dans un des trois cas décrits plus haut, ou si vous souhai­tez quand même être expli­cite, se décla­rer expli­ci­te­ment compa­tible avec de futures versions qui n’ont même pas commencé à voir le jour est toujours aussi risqué.

    Vous avez testé avec IE10 ? alors décla­rez IE=10. Vous n’au­rez rien de moins que prévu, même si un IE11 ou un IE12 sortent. Si ces prochains n’in­tro­duisent pas de problème de compa­ti­bi­lité, il est probable que vous béné­fi­cie­rez de toutes façons du nouveau moteur. À l’in­verse, s’il y a rupture de compa­ti­bi­lité majeure, vous aurez proba­ble­ment moins de problèmes avec un mode de compa­ti­bi­lité « IE=10 » qu’a­vec un nouveau moteur incom­pa­tible « IE=Edge ».

    Vous avez tout à gagner à être honnête et à décla­rer la compa­ti­bi­lité réelle de vos pages. Au pire le site déve­loppé pour IE10 conti­nuera d’être vu avec un moteur compa­tible avec ce que propo­sait IE10. Est-ce vrai­ment si peu souhai­table ?

    Si ces pages sont toujours en main­te­nance active lors d’une nouvelle version du moteur IE *et* que ce moteur est compa­tible avec la version précé­dente *et* pour­tant qu’il décide de passer en compa­ti­bi­lité quand vous préci­sez IE=[la_version_préce­dente] (vous remarque­rez que les deux dernières condi­tions sont assez inco­hé­rentes entre elles), alors il vous sera facile de mettre à jour la décla­ra­tion. L’avan­tage c’est que si une de ces hypo­thèses devient inva­lide à l’insu de votre plein gré, au moins ça conti­nuera à fonc­tion­ner comme avant et comme prévu.

    À quoi ça sert alors ?

    Le mode IE=Edge est utile à condi­tion que vous testiez toutes les pages diffé­rentes à chaque nouvelle beta d’In­ter­net Explo­rer, et ce tant qu’au moins une de vos pages est en ligne (chez vous ou chez un tiers).

    Ça peut être votre cas si vous avez un petit site et que vous avez du temps à y passer. C’est toute­fois un pari sur le fait que vous restiez en main­te­nance active et que vous aurez du temps à perdre à l’ave­nir. Je ne compte pas le nombre d’ap­pli­ca­tions ou de sites aban­don­nés qui sont en théo­rie en main­te­nance ou dont on pensait qu’ils seraient encore en main­te­nance.

    Le plus souvent IE=Edge c’est surtout pour les sites en déve­lop­pe­ment, et ça devrait y rester cantonné.

    Mon problème n’est pas tant que vous choi­sis­siez d’uti­li­ser une décla­ra­tion IE=Edge, à vrai dire vous faites ce que bon vous semble et comme je n’uti­lise pas IE je n’au­rai pas à en souf­frir. Mon problème c’est quand ça arrive en recom­man­da­tion ou en bonne pratique à desti­na­tion des déve­lop­peurs. Là désolé de vous le dire, mais vous avez fauté. Vous enga­gez forte­ment un tiers à quelque chose dont je doute qu’il ait saisi toutes les impli­ca­tions, et ce pour un béné­fice qui reste fran­che­ment à démon­trer.

    Petite pensée pour l’ave­nir

    Si trop de gens utilisent IE=Edge, et qu’In­ter­net Explo­rer se sent obligé d’in­tro­duire une rupture de compa­ti­bi­lité signi­fi­ca­tive, quelle(s) solu­tion(s) leur restera-t-il ?

    • Casser la compa­ti­bi­lité, mais ils ont prouvé que dans leur cas spéci­fique, sachant que leur moteur était forte­ment utilisé aussi pour les appli­ca­tions natives et pas que le Web, c’était fran­che­ment nocif
    • Intro­duire un nouveau méca­nisme d’auto-détec­tion bancal comme le doctype swit­ching et complexi­fier encore plus le déve­lop­pe­ment web qui est déjà bien tordu à ce niveau si on prend en compte tous les modes de compa­ti­bi­lité
    • Consi­dé­rer que IE=Edge corres­pond en fait à IE=13 (par exemple) et créer un nouveau mot clef pour le rempla­cer, ou ajou­ter un suffixe expli­cite ; ceux qui ont joué avec les User-Agent savent combien ce mode de fonc­tion­ne­ment a ses limites

    Même du point de vue du web, en trichant à ce niveau vous n’ai­dez pas le web à rester à jour, vous risquez surtout de le casser ou de le complexi­fier. À bon enten­deur…

  • Pas de moteur DOM en ruby ? vrai­ment ?

    Je trouve ça telle­ment étrange qu’à mon avis j’ai simple­ment des oeillères qui me masquent la bonne librai­rie de code.

    Je cherche un moteur DOM XML utili­sable en program­ma­tion ruby. J’ai trouvé des moteurs dits DOM-like, c’est à dire des TreeBuil­der avec des API plus ou moins heureuses, et dont le parcours est géné­ra­le­ment fran­che­ment pénible si on n’uti­lise pas XPath ou qu’on ne recherche pas quelques éléments parti­cu­lier via leur chemin. Hpri­cot, Noko­giri, REXML et même libxml font partie de cette caté­go­rie.

    Par contre je n’ai trouvé aucun moteur DOM qui cherche vrai­ment l’im­plé­men­ta­tion de la spéci­fi­ca­tion DOM. J’at­tends par exemple un attri­but docu­mentE­le­ment sur la classe DOMDo­cu­ment. J’au­rai compris sur Ruby avoir un attri­but docu­ment_element au lieu de docu­mentE­le­ment mais là c’est géné­ra­le­ment un root que je retrouve. Sur les inter­faces pour parcou­rir le XML les diffé­rences sont bien plus profondes et je me retrouve avec des APIs qui sont géné­ra­le­ment très diffé­rentes.

    Certes, je peux me passer de DOM mais ce serait quand même étrange que personne n’ait implé­menté en ruby ce stan­dard extrê­me­ment courant. Qu’ai-je manqué ?

  • Signa­ture des appli­ca­tions Android sur Google Play

    Je trouve très peu de conseil ou bonnes pratiques. Déve­lop­peurs Android qui avez de l’ex­pé­rience là dedans, j’ai besoin de vos lumières.

    Pour l’ins­tant j’ai lu Signing you appli­ca­tions. J’ai retenu que toutes les appli­ca­tions doivent être signées, et que pour pouvoir les mettre à jour il faut utili­ser exac­te­ment le même certi­fi­cat que l’ap­pli­ca­tion d’ori­gine. Pour signer on créé un keys­tore et un alias.

    Une ou plusieurs clefs

    La bonne pratique habi­tuelle côté sécu­rité c’est une clef par desti­na­tion, appli­ca­tion ou usage. Éven­tuel­le­ment une clef globale pour certi­fier les premières si on a besoin de s’as­su­rer de la pater­nité de toutes les clefs. Ça mili­te­rait pour signer chaque appli­ca­tion avec une clef diffé­rente et ça permet­trait de délé­guer la produc­tion d’une ou plusieurs appli­ca­tions à un tiers sans devoir lui donner la clef globale.

    Le problème c’est que le docu­ment sur la doc Android, ainsi que les quelques docu­ments trou­vés sur le web à propos de Google Play, conseillent plutôt d’uti­li­ser une clef globale. Le seul gain que j’y vois c’est que les appli­ca­tions pour­ront commu­niquer entre elles. Je n’en ai pas besoin pour l’ins­tant mais il est vrai que je ne connais pas le futur.

    Alors, une clef par appli­ca­tion ou une clef globale ?

    Notion de keys­tore et alias

    Tel que je le comprends le keys­tore n’est qu’un simple entre­pôt pour stocker des clefs. Mis à part que lui même peut être protégé par un mot de passe pour éviter de donner trop faci­le­ment accès aux clefs privées. Les clefs privés sont en fait ce qui est pointé par les « alias » dans la docu­men­ta­tion. On peut donc avoir plusieurs clefs par keys­tore.

    J’en déduis que la notion de keys­tore n’in­flue pas du tout sur Google Play. Je peux sortir ma clef d’un keys­tore, la mettre dans un autre keys­tore et signer une mise à jour avec. Tant que c’est la même clef, on se moque du keys­tore. Ai-je bon ?

    J’en déduis donc aussi que Google n’a aucune notion de mon keys­tore et que je peux y ajou­ter de nouvelles clefs quand je le souhaite pour de nouvelles appli­ca­tions. Je n’ai pas besoin de prépa­rer un keys­tore avec un jeu de clef qui ne bougera pas et que je ne pour­rai pas mettre à jour. Ai-je bon ?

    Voilà voilà, j’ai besoin de vos lumières et ayant peu d’édi­teurs d’ap­pli­ca­tions dans mon réseau, j’ap­pré­cie­rai beau­coup que vous fassiez suivre mes inter­ro­ga­tions à vos propres connais­sances.

    Comme j’ai eu quelques conseils de gens qui réflé­chissent à haute voix mais n’ont eux-même pas essayé ou pas d’ex­pé­rience dans tout ça : Si vous vous retrou­vez dans cette situa­tion, merci de le préci­ser pour que je fasse le tri entre les retours d’ex­pé­rience réels et les autres.