Carnet de notes

Catégorie : Technique

  • Frame­work js pour appli­ca­tion web

    Je regarde un peu les frame­works JS pour « appli­ca­tions dans le navi­ga­teur ».

    Plus j’avance plus je me dis qu’a­vec l’ap­proche mobile et la gestion du offline, on aban­donne le web tel que je le connais­sais. Même avec une foul­ti­tude de javas­cript et d’ajax, nous avons long­temps gardé l’ap­proche « vue sur le client, appli­ca­tion sur le serveur », et j’en ai été un grand défen­seur. Aujourd’­hui l’idée c’est plutôt « appli­ca­tion sur le navi­ga­teur, API sur le serveur ».

    La démarche n’est pas neuve en infor­ma­tique et le milieu a déjà subit plusieurs aller-retour entre les modes « appli­ca­tion sur le client », « appli­ca­tion sur le client synchro­ni­sée avec un serveur », et « appli­ca­tion sur le serveur, vue sur le client ». Il s’agit juste d’un de ces mouve­ments mais côté appli­ca­tions web.

    J’ai regardé quelques frame­works, nommé­ment Back­bo­neJS, Angu­larJS et EmberJS, plus quelques compa­ra­tifs plus éten­dus. Pour l’ins­tant j’ai l’im­pres­sion qu’ils proposent surtout une notion de MVC, avec éven­tuel­le­ment un système de rendu avec liai­son directe entre la partie modèle et la partie contrô­leur.

    Je peux me leur­rer sur la complexité ou sur la valeur ajou­tée en main­te­nance mais j’ai l’im­pres­sion que ça ne sera pas mes points d’at­ten­tion. Orga­ni­ser mes classes je le ferai certai­ne­ment moins bien si je prends tout de zéro, mais ce ne sera pas ma diffi­culté prin­ci­pale. Les liai­sons directes entre vue et modèle ne me semblent pas non plus forcé­ment indis­pen­sable, ça peut même être contre­pro­duc­tif vue la perte de perfor­mance.

    Par contre j’ai besoin de quelque chose pour gérer le côté appli­ca­tif :

    1. M’abs­traire des diffé­rentes solu­tions de stockage client, si possible en gérant les quotas, en ayant un méca­nisme quand on se rend compte que ce stockage a été écrasé et néces­site d’être recréé, etc. Dans l’idéal quelque chose qui ne se contente pas d’être un simple wrap­per et qui sait faire la diffé­rence entre des préfé­rences et de gros conte­nus par exemple, en me propo­sant des solu­tions diffé­rentes pour les deux cas en fonc­tion de ce qui est dispo­nible sur le navi­ga­teur (on n’uti­lise pas les API File et le local storage dans les mêmes contextes)
    2. Avoir en ligne de vue le fonc­tion­ne­ment hors ligne, avec un vrai méca­nisme de mise à jour de l’ap­pli­ca­tion, un vrai méca­nisme de mise à jour des données (synchro­ni­ser dans les deux sens, un premier méca­nisme de conflit ou de prio­ri­sa­tion en cas de conflit), des notions de « à exécu­ter plus tard une fois en ligne », etc. La ques­tion du login est aussi impor­tante (jeton tempo­raire ou perma­nent, quelle sécu­rité, etc.)
    3. Un méca­nisme complet de gestion des URL à base de popS­tate et pushS­tate de façon à ne pas avoir qu’un seul lien vers la page d’ac­cueil mais pouvoir gérer le bouton retour arrière du navi­ga­teur, les favo­ris, les liens entrants, etc. Bref, si je regarde un contenu parti­cu­lier je dois avoir une URL spéci­fique, que je peux copier, trans­mettre, utili­ser. Et par pitié oubliez les #!. C’est aussi plus diffi­cile qu’il n’y parait dès qu’on fait inter­agir ça avec le mode offline.
    4. * Une gestion de base pour les conte­nus. Si on stocke hors ligne, j’ai­me­rai avoir à jouer le moins possible moi-même avec les data:uri, et pouvoir réfé­ren­cer des images ou des conte­nus dans mes vues, à partir de choses stockées hors ligne dans un local­sto­rage, indexdb ou équi­valent
    5. C’est annexe et peut être non relié, mais si possible un jeu de widget ou templates par défaut qui s’adaptent aux diffé­rents contextes de navi­ga­tion (android, ios, win8, la manière dont on présente les listes, les menus, les retours arrière, ne sont pas les mêmes)

    Vous avez quoi pour gérer ces aspects parti­cu­liers ? Parce que pour dessi­ner des pages à partir de modèles et vues OK, mais pour gérer une appli­ca­tion j’ai l’im­pres­sion d’être sans rien.

    Oh, et en plus vu qu’il s’agit d’être multi-device, je ne souhaite pas quelque chose qui rame sur smart­phone. Par contre j’ac­cepte de coder beau­coup de choses à la main, je ne cherche pas forcé­ment un truc qui fasse le café. Même 4 ou 5 petites lib qui s’oc­cupent de leur partie spéci­fique, ça me va.

  • Char­pen­tier infor­ma­tique

    Inter­vie­wer: So, you’re a carpen­ter, are you?
    Carpen­ter: That’s right, that’s what I do.

    […]

    Inter­vie­wer: First of all, we’re working in a subdi­vi­sion buil­ding a lot of brown houses. Have you built a lot of brown houses before?
    Carpen­ter: Well, I’m a carpen­ter, so I build houses, and people pretty much paint them the way they want.

    […]

    Carpen­ter: Really, is that it? So I lost the job because I didn’t have enough brown?
    Inter­vie­wer: Well, it was partly that, but partly we got the other fellow a lot chea­per.
    Carpen­ter: Really — how much expe­rience does he have?
    Inter­vie­wer: Well, he’s not really a carpen­ter, he’s a car sales­man — but he’s sold a lot of brown cars and he’s worked with walnut inter­iors.

    Ça me rappelle forte­ment une direc­tion qui à un moment pensait qu’il fallait segmen­ter les déve­lop­peur par domaine commer­cial, et que la valeur ajou­tée était moins dans la qualité tech­nique ou le recul du déve­lop­peur que dans le fait qu’il ait déjà travaillé dans le secteur de l’éner­gie (même si c’est pour coder un CMS ou un outil de réser­va­tion de salles de réunion) ou dans l’in­dus­trie du luxe (même si c’est pour coder un formu­laire d’ins­crip­tion à une news­let­ter).

    La petite histoire reste une petite fable forgée de toutes pièces, mais elle est amusante à lire, et parfois se révèle un peu trop proche de la vérité.

  • Tester, docu­men­ter et débo­guer une API REST

    Je découvre apiary.io. Il y a de quoi docu­men­ter, tester et débo­guer une API REST, avec des mocks et des proxy de débo­guage.

    Je ne sais pas si la valeur ajou­tée est suffi­sante pour imagi­ner utili­ser un service de ce type mais c’est bien foutu, simple, et assez clair. Je n’ai simple­ment pas compris quel est le modèle busi­ness (et ça c’est un gros point noir).

    Bref, à surveiller, le compte de test peut être créé en quelques secondes à partir d’un compte github.

  • Blogs et EPUB

    L’EPUB c’est fina­le­ment juste un site web encap­sulé dans un conte­neur, avec quelques méta­don­nées pour le circuit de lecture. Certains voient une conver­gence entre l’EPUB et les sites web dans le futur, et pourquoi pas des sites web diffu­sés en tant qu’EPUB.

    David cite Thierry Crou­zet :

    Faire des livres, quelle que soit leur forme, me paraît soudain plus moderne que tenir un blog, simple offi­cine dans la rue des boutiques obscures. Ce qui compte, c’est publier, parta­ger, pas d’être maître chez soi.

    Un format et un outil doivent toujours être mis en regard d’usages et d’objec­tifs. Il est rare qu’un soit plus simple qu’un autre en soi, de façon univer­selle.

    Je vois deux visions à celle du « aban­don­nons le blog pour l’epub » : soit un EPUB unique pour l’in­té­gra­lité des conte­nus, soit un EPUB par billet avec éven­tuel­le­ment des pages web pour l’in­dex des archives et un flux RSS tiers.

    Dans la première vision j’ai un blog figé, qui ne bouge plus. Je ne suis pas alerté des mises à jour, je ne suis pas capable de ne télé­char­ger qu’un contenu isolé­ment du reste, et surtout je ne suis même plus capable de faire un lien vers un contenu parti­cu­lier de l’en­semble. Ce dernier point est presque le plus grave : On sort le contenu du web en rendant impos­sible les liens entrants. C’est viable pour une archive, pas pour un blog, dont la nature même est de vivre : d’avoir un ajout régu­lier de nouveau contenu et des échanges (donc les liens).

    Dans la seconde vision on revient quasi­ment à ce qu’on a actuel­le­ment sauf qu’on a remplacé les pages HTML des conte­nus unitaires par des fichiers EPUB, qui ne contiennent que la page HTML qu’on vient de rempla­cer. C’est un chan­ge­ment pure­ment tech­nique, dont j’ai du mal à voir la valeur ajou­tée. Sans comp­ter que si tout ce qui sait lire un EPUB sait aussi lire un fichier HTML direc­te­ment, l’in­verse n’est pas vrai.

    Au final il ne faut pas perdre de vue les usages et les objec­tifs. Le blog cherche à commu­niquer. David parle de partage. En étant plus terre à terre je parle­rai de mise à jour, d’ajout régu­lier de contenu, de liens et de commen­taires. Qu’ap­porte un passage à l’EPUB pour ce type d’usage ?

    Si l’EPUB a toutes les raisons de s’étendre hors du livre, il faut bien voir que ce livre a un usage bien parti­cu­lier : contenu rela­ti­ve­ment figé dans le temps, lu géné­ra­le­ment séquen­tiel­le­ment, formant le plus souvent un contenu unique bien défini. Ces attri­buts peuvent adres­ser bien des objets du web, mais proba­ble­ment pas les blogs, juste­ment.

    Pour amélio­rer les blogs parlons plutôt simpli­cité de diffu­sion, faci­lité d’écri­ture, amélio­ra­tion des discus­sions, mais tout ceci est rare­ment une ques­tion de format ou de tech­nique.

  • Apprendre EPUB gratui­te­ment avec O’Reilly

    C’est peut être vieux mais aujourd’­hui je remarque que les titres « What is EPUB 3« , « Acces­sible EPUB 3 » et « HTML 5 for publi­shers » sont gratuits chez O’Reilly, en EPUB et PDF.

    Si la concep­tion de livres numé­riques vous inté­resse, ce serait dommage de se priver.

    Pour ceux qui sont un peu plus marke­ting, il y a aussi « The Global eBook Market: Current Condi­tions & Future Projec­tions » mais qui date un peu (octobre 2011)

  • Writing Web Apps Quickly With Mortar

    Les webapps sont pour moi défi­ni­ti­ve­ment la direc­tion vers laquelle aller. Mozilla pousse beau­coup via Fire­fox OS. Pour jouer avec eux, jetez un oeil à Mortar, qui permet d’ini­tia­li­ser tout le néces­saire. Il y a un joli billet de hacks.mozilla.org qui peut vous permettre de démar­rer.

  • Linux Kernel Tuning

    Quelques para­mètres obscurs (ou pas) à confi­gu­rer pour vos serveurs Linux. Je regrette juste l’ab­sence des para­mètres pour amélio­rer l’ou­ver­ture des fenêtres TCP (effet garanti sur les serveurs web, peu de risques, quasi­ment pas d’ef­fet néga­tif en situa­tion réelle).

  • Liga­tures privées et rempla­ce­ment de textes

    Pendant quelques années nous avons cher­ché le saint Graal pour rempla­cer du texte par des images dans les pages HTML. Il y a eu sIFR qui néces­si­tait le plugin Flash, des bidouilles à base d’in­den­ta­tion et marges CSS néga­tives qui risquaient de casser pour ceux qui n’af­fi­chaient pas les images, des trucs horribles à base de display:none qui empê­chaient le copier/coller, etc.

    J’avais pas mal laissé tombé quand j’ai vu que certains jouaient avec des polices de carac­tères à la wing­dings. Ça ne faisait pas de rempla­ce­ment et ça néces­si­tait d’ajou­ter des carac­tères arbi­traires qui risquaient de mal passer en cas d’ab­sence de la police choi­sie.

    Sauf que visi­ble­ment ils ont trouvé le saint Graal il y a un bon moment et personne ne m’a prévenu. Alors si vous aussi on ne vous a pas prévenu, regar­dez Symbol­set et Liga­ture Symbols.

    L’idée c’est d’uti­li­ser les liga­tures. Les liga­tures ce sont ces arte­facts qui permettent de rempla­cer certaines suites de carac­tères par un visuel spéci­fique afin d’en simpli­fier la lecture. On cite souvent « fl » et fi » comme exemple de liga­ture mais Wiki­pe­dia a une superbe illus­tra­tion.

    L’as­tuce est de décla­rer une police person­na­li­sée où « se connec­ter » est remplacé par une liga­ture qui contient l’icône corres­pon­dante. C’est vecto­riel, ça s’adapte en taille comme en couleur, ça se dégrade parfai­te­ment pour ceux qui ne savent pas relire la liga­ture ou la police de carac­tères, et pour le système ça reste encore le mot « se connec­ter » donc c’est tota­le­ment trans­pa­rent. Bref, comme en plus c’est léger en poids, on a presque trouvé le saint Graal. Pourquoi personne ne m’avais rien dit ? Comment ai-je pu passer à côté ?

    Vous avez même un outil en ligne qui fait tout ça : Icomoon

  • Do not be evil en chinois ça s’écrit comment ?

    Google has quietly disa­bled a feature that noti­fied users of its search service in China when a keyword had been censo­red by the Chinese govern­ment’s inter­net controls

    Pas de quoi faire mentir la devise initiale de Google. La noti­fi­ca­tion n’avait pas de rôle philan­thro­pique, elle avait pour objec­tif d’évi­ter que l’in­ter­naute cher­chant le mauvais mot clef ne se voit coupé de Google et aban­donne ses recherches. Quand le gouver­ne­ment chinois réagit et que la noti­fi­ca­tion fait perdre plus de recherche que son absence : elle dispa­rait.

    Reste que ça donne à réflé­chir. Si seul compte le busi­ness, que risque-t-on si un jour nos valeurs iront contre leur busi­ness ?

  • Quelques liens javas­cript

    Partagé sans commen­taires, mais vous pouvez faire les vôtres :