Carnet de notes

Catégorie : Technique

  • Baisse des débits SFR

    Croyez-y ou non, mais ces four­nis­seurs d’ac­cès Inter­net qui se plaignent de devoir suppor­ter les coûts du réseau alors qu’un trafic asymé­trique leur est imposé de la part des four­nis­seurs de conte­nu… Font visi­ble­ment tout pour encou­ra­ger cette asymé­trie.

    SFR avait jusqu’à présent deux offres fibre. Ce n’était pas le critère diffé­ren­cia­teur et il fallait aller dans les petites lignes pour s’en rendre compte mais la moins chère était une offre 100/10 et la plus chère une offre 100/50. Il y a toujours deux offres, mais désor­mais le trafic montant est bloqué à 10 Mb/s quelle que soit l’offre. Le fait de s’en­ga­ger dans une baisse des débits est quand même assez extra­or­di­naire.

    Qu’on ne se leurre pas, il s’agit d’af­fi­cher des superbes « 24 Mega » et « 100 Mega » mais surtout pas que les gens les utilisent (et dans le cas des 24, les gens ne les auront même pas). Il y a un vrai combat contre tous ces nouveaux services en ligne qui consomment la bande passante et qu’on ne veut surtout pas que vous utili­siez.

    Si le ratio qui devient habi­tuel est de 10/100 voire 3/100 (Numé­ri­cable) ce n’est pas un hasard : Ceux qui nous vendent l’ac­cès cherchent à avoir la plus grande asymé­trie possible pour que vous n’uti­li­siez pas leur réseau. Marrant non ?

  • Secure headers

    Secu­re­hea­ders, une gem ruby pour ajou­ter et confi­gu­rer des entêtes liées à la sécu­rité sur vos appli­ca­tions web.

    Et vous, quelles entêtes ajou­tez vous à vos sites pour gérer la sécu­rité ?

  • Conver­gence web et appli­ca­tion – Stockage Safari mobil / iOS

    Les API qui arrivent sur nos navi­ga­teurs depuis quelques années commence à nous faire imagi­ner une vraie conver­gence entre les appli­ca­tions mobiles et le web.

    C’est déjà un premier pas énorme qu’on voit avec Chrome web store, Fire­fox Market­place, et autres Windows 8 : On commence à déve­lop­per direc­te­ment avec les tech­no­lo­gies web, éven­tuel­le­ment direc­te­ment avec le navi­ga­teur comme plate­forme.

    Main­te­nant pour moi ce n’est pas encore ça. J’ai quelques problèmes côté sécu­rité par exemple (théo­rique­ment entre l’at­tri­but sand­box, l’api postMes­sage et les décla­ra­tions CSP on devrait arri­ver à avoir une bonne base, mais ça n’a pas l’air de coller si faci­le­ment si ce n’est pas bien prévu dès le départ).

    Le butoir sérieux est côté iOS avec son stockage de 50 Mo maxi­mum. Ça peut sembler beau­coup mais c’est fina­le­ment très réduit dès qu’on y stocke autre chose que du pur texte à lire. J’ai réel­le­ment besoin de dépas­ser ce palier. Je paye une bière à celui qui me trouve un méca­nisme qui tourne effi­ca­ce­ment et qui permet de s’en affran­chir sur Safari mobile. Plusieurs bières même. Il peut même y avoir un job ou une mission à la clef pour des bon bidouilleurs javas­cript. Avis aux inté­res­sés.

  • Direc­teur artis­tique, je pouffe

    Chris­tophe nous propose une petite mise à plat sur le terme de direc­teur artis­tique qui fait un peu polé­mique. Il faut y lire direc­teur dans le sens « donner la direc­tion » et artis­tique dans le sens cultu­rel, contex­tuel et émotion­nel.

    Je n’ai aucun problème avec l’ex­pli­ca­tion, mais ça n’en fait pas un bon terme : Ce terme est mal compris, mal perçu, et est même parfois utilisé pour abuser l’in­ter­lo­cu­teur.

    Si on ne comprend rien à ce terme, c’est qu’il faut le chan­ger.

    Alors, oui, je ne comprend peut être pas non plus le tech­ni­cien en charge des examens non-destruc­tifs, mais je n’en suis pas la cible. Je peux suppo­ser que le terme est compris et perçu correc­te­ment dans l’in­dus­trie nucléaire. Force est de consta­ter que le terme de direc­teur artis­tique est mal compris ou mal perçu par beau­coup de gens du web, clients ou colla­bo­ra­teurs. Et ça ça fait une grosse diffé­rence.

    Une partie du rôle de ce direc­teur artis­tique est d’adap­ter le design et l’in­ter­face pour que le message soit compris et que l’uti­li­sa­tion soit effi­cace. Si le design ou l’in­ter­face ne sont pas compris ou mal perçu, alors le travail est mal fait, tout simple­ment. Le direc­teur artis­tique qui dirait que son travail est bon, que c’est juste l’uti­li­sa­teur qui ne comprend rien, que ce dernier manque de curio­sité et qu’il faut l’éduquer… n’a simple­ment rien compris à son métier. Alors pourquoi l’ad­mettre sur son titre lui-même ? Désolé ça n’a aucun sens pour moi comme argu­men­ta­tion.

    Là le terme reste pour des ques­tions d’égo ou de vente alors qu’il ne sert pas la fonc­tion. C’est tota­le­ment insensé.

    Direc­teur artis­tique « junior », je pouffe.

    Oui, je pouffe. Je comprends l’idée que dans tout métier il y a des juniors et des seniors. Je suis même de ceux, rares, qui consi­dèrent qu’il peut y avoir des chefs de projets junior, et même des chefs de projet stagiaires. Pour­tant là je ne pouffe pas, contrai­re­ment au direc­teur artis­tique.

    Qu’on le veuille ou non, la notion de direc­teur induit la conno­ta­tion de direc­tion dans le sens gestion / mana­ge­ment. Certaines agences jouent et abusent même de cette ambi­guité quand elles vendent un direc­teur artis­tique ou quand elles proposent des postes à des junior.

    Parlons des déve­lop­peurs qui sont nommés en fin de billet juste­ment. Nombre d’entre eux sont aussi là pour « donner une direc­tion ». Pour­tant aucun d’entre eux ne se nommera « direc­teur front-end » ou « direc­teur tech­nique » (et encore moins « direc­teur * junior ») sans avoir un poste de direc­tion au sens gestion / mana­ge­ment.

    Le direc­teur artis­tique est à ma connais­sance le seul à le faire, et à ma connais­sance je dirai même que c’est exacerbé en France et limité au web : Dans un spec­tacle le direc­teur artis­tique a toujours un rôle de haut niveau au niveau de la prise de déci­sion.

    Les déve­lop­peurs il y en a des juniors, des seniors, des experts, mais ils sont déve­lop­peurs, éven­tuel­le­ment archi­tectes. On ne me reti­rera pas que nombre de direc­teurs artis­tiques sont des illus­tra­teurs, graphistes, inter­ac­tion desi­gner, éven­tuel­le­ment artistes (au sens créa­tion artis­tiques), ergo­nomes ou plein d’autres choses (souvent plusieurs) qui sont bien plus signi­fi­ca­tives que ce mauvais terme de direc­teur artis­tique.

    Alors ?

    Mais pourquoi donc il y a-t-il tant d’at­ta­che­ment à un nom de fonc­tion qu’il est si mal compris et mal perçu par les tiers ? Il va être diffi­cile de me convaincre que ce n’est pas une ques­tion d’égo pour une partie des DA et une ques­tion de abuser le client pour une partie des agences.

    Effi­ca­cité : Si ce n’est pas ce qui fonc­tionne, chan­geons, même si on pense avoir « raison » acadé­mique­ment. Je ne peux pas penser une seconde que les DA ne connaissent pas ce prin­cipe. Ce devrait même être à la base de leur métier.

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