• Traitement de texte multicanal - Frank Taillandier
    http://frank.taillandier.me/2016/08/28/traitement-de-texte-multicanal

    Comme je l’expliquais dans la mouvance statique, il est important de bien choisir le format de fichier dans lesquels nous allons stocker nos écrits. C’est souvent la solution la plus simple qui est aussi la plus efficace : du texte brut mise en forme à l’aide d’une syntaxe elle aussi en #texte brut. #Markdown est de ce fait un format de fichier de plus en plus populaire car il assure une pérennité et une compatibilité à nos documents, tout en préservant une mise en forme au format texte. Markdown est le format par défaut des contenus dans la plupart des générateurs de site statique et il devrait devenir aussi le format par défaut dans lequel vous rédigez vos notes, vos rapports, vos articles de blog ou vos livres.

  • Que sont les Progressive Web Apps ? - Frank Taillandier
    http://frank.taillandier.me/2016/06/28/que-sont-les-progressive-web-apps

    Les Progressive Web Apps apportent les fonctionnalités attendues des applications natives à l’expérience de navigation Web sur un mobile en utilisant des technologies basées sur les standards et en tournant dans un conteneur sécurisé accessible à tous sur le Web.
    En somme, les Progressive Web Apps décrivent toute une série de technologies, de concepts d’architecture et d’API Web qui travaillent de concert pour proposer une expérience similaire aux applications natives sur le Web mobile. Voyons ensemble les quelques tenants de base des Progressive Web Apps.

    Le concept de « Progressive Web Apps » sent le marketing à plein nez mais l’idée de base est là : faire des applis web utilisables comme applis mobiles (ce qui était un des principe porté par Mozilla phone dans son concept d’OS mobile). Et au passage ça devrait permettre de se débarrasser des Truc Store et de la compilation par OS à chaque version d’une l’appli...
    Voir aussi :
    https://serviceworke.rs pour des exemples de « Service workers »
    https://developers.google.com/web/updates/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-3 et https://w3c.github.io/manifest pour l’utilisation de fichier manifest.json pour installer une web apps

    #progressive_web_apps #service_workers #app_shell #appli_mobile #manifest.json

    • En dehors de la question de la sécurité liée à un site PHP, et sans doute la tenue en charge d’un site à fort traffic, le reste contient des choses que je trouve vraiment discutables.

      – Introduire la difficulté de l’invalidation du cache, alors qu’on évoque des sites qui ne changent que rarement, et qu’on va arriver à un site totalement statique (équivalent à un cache qui ne serait jamais invalidé), c’est pas sérieux.

      – Je ne vois pas pourquoi un ensemble de fichiers structurés en Makdown serait fondamentalement plus « accessibles », « réutilisables », facilitant les « migrations ultérieures » que les mêmes « contenus enfermés dans une base de données ». Si la base de données à une structure claire, il n’y a vraiment pas grande difficulté à récupérer les données. Qu’il y ait une grosse mode des prestataires à privilégier des systèmes qui permettent de complexifier la structure de l’information dans le but assez évident d’interdire au client de changer de prestataire, n’est pas un argument pour le statique en tant que tel.

      – Le passage sur le refus du Wysiwyg (« accessibles et réutilisables »), je veux bien, mais bon -> SPIP a 16 ans et a toujours argumenté très sérieusement sur son refus du Wysiwyg…

      – Je suis très embêté sur la non-réponse au fait que si on a des systèmes permettant le dynamique, c’est parce qu’on a souvent besoin de gérer des informations dynamiques : forums, contributions, compteurs de visites, formulaires, etc. La réponse dans cet article ne me convainc pas : le coup des « microservices », c’est une énorme partie de la mode du « Web 2.0 » et de ses startups, qui a facilement 10 ou 15 ans ; je veux une interface pour les cartes géographiques, hop un web-service ; je veux un compteur, hop un Analytics ; je veux un forum, hop, hop, hop… Résultat : pas trop de libre, une énorme concentration des services (Google Analytics partout, forums Facebook, Google Maps pour les cartes prêtes à l’emploi, la vidéo chez Vimeo ou Youtube…). Ici l’article se termine avec un très beau : « Vous avez envie de réagir ? Laissez une mention sur Twitter. » OK.

      Un aspect non abordé, c’est je le crains le fait que les sites se referment et que les aspects très « ouverts » qui nous motivaient il y a 15 ans ne sont plus du tout à la mode (qui veut encore de la « publication ouverte » et/ou un comité éditorial décentralisé, gérer des forums sous les articles… ?).

      Bref : très d’accord sur l’intérêt de revenir à du statique dans de nombreux cas. Mais certains arguments ici sont problématiques.

    • Tout à fait d’accord avec @arno sur la plupart des arguments, sauf peut-être sur la crainte de fermeture : les CMS basés sur MySQL (notamment) ne permettent pas facilement d’en décentraliser la production (cf. l’argument, valable, de la difficulté qu’il y a à "passer en prod" des contenus). (Avec SQLite c’est un peu plus facile, mais bof pour la perf.)

      Tandis qu’une série de fichiers à plat, gérés sous git, c’est bonnard : c’est du même coup versionné, décentralisé, ouvert à la participation (via les pull-requests), ouvert aux bidouillages (via clonage et donc copie facile des contenus).

      La procédure export / import MySQL, avec les documents joints qui ne suivent pas, les identifiants arbitraires, etc, c’est vraiment problématique de ce point de vue. (C’est la raison notamment du raccourci “ressources” qui cherche à faire ce découplage.)

    • [je parle plus de techniques (bdd vs statique) mais de contenus/philosophie de publication.]
      Ça :

      Un aspect non abordé, c’est je le crains le fait que les sites se referment et que les aspects très « ouverts » qui nous motivaient il y a 15 ans ne sont plus du tout à la mode (qui veut encore de la « publication ouverte » et/ou un comité éditorial décentralisé, gérer des forums sous les articles… ?).

      Je trouve que c’est central. On m’a demandé récemment d’intervenir sur médias et diffusion des savoirs sur le genre. Bon, je vois vraiment une différence fondamentale entre un projet comme les pénélopes (par ex., mais y’en a d’autres) et les blogueuses féministes qui ont la côte en ce moment. La dimension collective et décentralisée étant un des arguments que je vais avancer pour dire que si il y a effectivement une prolifération de lieux de diffusions de savoir sur le genre (on me pose la question, hein) en ligne, cet « esprit du libre » s’est perdu, l’autonomie et surtout effectivement ces comités éditoriaux décentralisés, la démarche collective en somme, a laissé place au personal branding, à la mise en avant de soi, à la non confrontation avec d’autres dans la production du contenu. A cela tu ajoutes l’essoufflement associatif sur les médias tactiques (dont la définition n’est aujourd’hui plus que celle du marketing publicitaire), bon, alors, oui, on va faire des sites statiques en markdown.