Saisis un ticket ! Oussa ???

Comment signaler un souci technique sur un site Web ? C’est la question que se posent quotidiennement les camarades Karl et “File a bug” Rik. Et dont la réponse pourrait être une « bonne pratique ». La solution la plus simple est bien sûr de ne pas oublier, sur la page de contact du site, les adresses du service technique s’en occupant. Une alternative un peu plus /geek/ serait d’utiliser le fichier humans.txt, qui permet de lister les humains impliqués dans la réalisation du site. Mais ces deux options ne permettent pas d’automatiser la recherche du bon contact, c’est à dire d’avoir par exemple dans son navigateur une extension qui affiche un bouton « Signaler un problème sur ce site ».

La solution est alors peut-être à chercher du côté du Web sémantique. Ajouter au code source de chaque page des informations sémantiques pointant vers un système de gestion de tickets. Le vocabulaire DOAP — Description Of A Project semble indiqué pour cette tâche, puisqu’il propose une propriété bug-database. Il suffit donc d’ajouter cette information à la page.

Voici trois propositions d’implémentations, utilisant sauf erreur de ma part RDFa, RDFa Lite et les micro-données HTML5. Je précise que j’ai beaucoup de mal avec ces spécifications, donc ne garantis pas la justesse de mes exemples. Différents outils semblent cependant les trouver valides et réussir à en extraire les données.

  • en RDFa, via les méta-données de la page

    <html lang="fr" >
      <head prefix="doap: http://usefulinc.com/ns/doap#">
        <title>Saisis un ticket ! Oussa ???</title>
        <meta charset="utf-8" />
        <meta name="description" content="Esquisses, brouillons et notes en vrac d'un apprenti geek intéressé par la liberté" />
        <meta name="author" content="Clochix" />
        <meta property="doap:bug-database" content="https://github.com/clochix/esquisses/issues">
    
  • en RDFa Lite

    <div vocab="http://usefulinc.com/ns/doap#" typeof="Project">
      <a property="bug-database" href="https://github.com/clochix/esquisses/issues">Signaler un problème</a>
    </div>
    
  • avec les micro-données HTML5

    <div itemscope itemtype="http://usefulinc.com/ns/doap#Project">
      <a itemprop="bug-database" href="https://github.com/clochix/esquisses/issues">Signaler un problème</a>
    </div>
    

Une fois les informations ajoutées à la page, reste à pouvoir les utiliser, par exemple depuis une extension. Et de ce point de vue, bien que préférant RDFa, je dois admettre que les micro-données viennent de prendre un petit avantage avec l’arrivée dans Firefox de l’API DOM pour y accéder. Ce petit bout de code devrait être capable d’extraire les données. Je vous laisse l’embarquer dans une /marque-pagette/ ou une extension.

var items = document.getItems("http://usefulinc.com/ns/doap#Project");
if (items.length > 0) {
  Array.prototype.forEach.call(items, function (elmt) {
    if (elmt.properties['bug-database']) {
      console.log(elmt.properties['bug-database'].getValues().join(','));
    }
  })
}

Du côté de RDFa / RDFa Lite, la spécification d’une API native semble en sommeil et il faudra utiliser des bibliothèques tierces pour extraire les informations.

Le pari du Web

Ayé, la version Mozilla des applications Web arrive enfin sur GNU/Linux. Youpy. Et zut, car passé le premier enthousiasme lié à la nouveauté, cela signifie que l’heure a aussi sonné d’essayer de jeter un regard critique sur ce concept et de se poser la question : s’y mettre ? Ou pas ? Telle est la question.

Esquisses de réflexion.

Dark Side of the Web

À vrai dire, les raisons de ne pas sauter le pas sont nombreuses.

Les applications Web sont nées de bidouilles, de détournements, et sont encore aujourd’hui loin d’être des citoyennes de première classe sur la vaste toile mondiale. Si le microcosme s’active en ce moment à réinventer le fil à couper le beurre pour les doter de toutes les capacités des applications natives, on est encore loin du compte. Surtout, elles manquent d’un élément essentiel : une bonne bibliothèque d’interface utilisateur. Et c’est une grave lacune que tout le monde semble aujourd’hui avoir acceptée. Les différentes propositions pour créer un langage permettant de décrire une interface utilisateur riche ont toutes été abandonnées. Ne reste plus que HTML, un langage de description de documents. Certes, on lui adjoint quelques composants d’interface supplémentaire, essentiellement pour simplifier la gestion de formulaires. Mais pas d’onglets, d’arbres, de zones redimensionnables… Pour créer l’interface des applications Web, on va devoir rester dans le domaine de la bidouille, du détournement, des lourdes bibliothèques en JavaScript. Triste.

Les limitations techniques sont nombreuses, et certaines ne semblent pas prêtes à sauter. Mais elles ne sont pas les seuls inconvénients de la plate-forme Web. Celle-ci pose également des questions en matière de souveraineté des utilisateurs sur leurs données. Les applications peuvent bien sûr stocker les données localement, sur le terminal où elles s’exécutent. Mais il y a fort à parier que la tentation de tout stocker sur le réseau va être forte. De confier nos données aux sites des éditeurs des applications. Ce qui ne fera que renforcer la fragmentation actuelle, le Web devenant de plus en plus composé d’immenses silos où sera stockée une partie de notre vie, et dont il sera difficile de s’échapper. On stockera tous ses documents chez Google, Facebook, Microsoft, Apple et consorts. Il sera difficile également d’être tranquille quant à la sécurité de nos données. Quid si l’entrepôt se fait cambrioler ? S’il « brûle » ? Si quelqu’un me vole mes clés et prend mes meubles en otage ? Ou si, plus simplement, l’entrepôt décide arbitrairement et soudainement de m’interdire l’accès ? Avec les applications Web, le risque de perte de contrôle sur nos données, voire de perte tout court, est plus élevé qu’avec les applications natives actuelles.

À moitié plein

Mais, en tant que libriste, je vois également des avantages à l’utilisation du Web pour créer des applications. Le Web

  • est une plate-forme ouverte, essentiellement bâtie sur des normes décidées en concertation par une partie des acteurs. Tout le monde peut librement consulter ces spécifications et les implémenter;
  • est une plate-forme largement adoptée. Des centaines de millions de personnes se promènent tous les jours sur le Web en utilisant un navigateur moderne. Une application (bien) écrite pour le Web peut donc être utilisée simplement par des millions de gens, quelle que soit leur matériel et leur façon d’accéder à la toile;
  • est une plate-forme accessible. Le coût d’entrée est des plus faible, aussi bien financièrement qu’en terme d’apprentissage. On peut facilement utiliser le réseau, on peut également simplement commencer à y créer des applications. Certes à mesure qu’elle gagne en puissance, la plate-forme se complexifie et devient plus difficile à programmer. Mais les connaissances requises pour créer un site ou une application Web basiques sont à la portée de pratiquement tout le monde;
  • chaque composant de la plate-forme dispose d’implémentations libres elles aussi largement répandues. Tant sur le serveur (Apache et Nginx par exemple) que côté client (Firefox et le moteur Webkit, malheureusement souvent emprisonné sous des couches privatrices, équipent environ la moitié des internautes). Le Web est donc compatible avec la religion de celles et ceux qui accordent de l’importance à la liberté concédée par les logiciels qu’ils utilisent;
  • est une plate-forme propice à la découverte et à l’expérimentation, à la bidouille. Nul besoin d’installer des logiciels supplémentaires pour étudier le fonctionnement du Web et commencer à le bidouiller. Les navigateurs contiennent nativement tout ce qu’il faut pour étudier la structure d’une page, écrire ses premières lignes de JavaScript, etc. Quiconque veut comprendre comment ça fonctionne, veut créer sur le Web, peut le faire, il n’y a pratiquement pas de barrière;
  • est un cheval de Troie. Les tentatives de verrouiller une plate-forme, de contrôler strictement tout ce que font les utilisateurs, sont légions. Certaines ont plutôt le vent en poupe en ce moment, oui Apple c’est toi et tes sectateurs que je regarde. Mais aussi fermé soit le système d’exploitation, le Web y est toujours accessible. Que vous utilisiez un téléphone sous iOS, une machine de bureau sous Windaube ou un objet bidouillable non identifié sous Haiku, vous pouvez toujours vous connecter au Web, et donc utiliser les applications conçues pour cette plate-forme 1;

Boire ou conduire ?

Le Web est une plate-forme. Une fondation. Un jardin. Il n’est ni le fruit que l’on mangera ni la maison que l’on habitera. Il est ce terrain où chacun est libre de faire pousser ce qu’il veut, fruits ou cabane, maison ouverte ou prison. Chacun y est réellement libre. Parce qu’il ne faut demander la permission à personne. Parce que tous les outils sont disponibles. Le reste ne dépend que de nous.

Que faire alors ? Boycotter la plate-forme pour ses limitations techniques et les menaces pour la vie privée qu’elle porte ? Ou l’adopter en jugeant qu’elle offre des opportunités pour promouvoir les valeurs de liberté, d’égalité et de solidarité au cœur de la démarche du Logiciel Libre ? À chacun de trancher. La réponse a tout d’un pari. Le pari du Web.

  1. avec une grosse limitation, il faut disposer d’un navigateur capable d’exécuter de telles applications. Sur iOS par exemple, Apple interdisant tout autre navigateur que Safari, les WebApps ne pourront utiliser que les fonctionnalités HTML5 disponibles dans Safari.

Add Github infos to npm results

(Version française en dessous)

Too much choices is the same as no choice at all. This is what I say to myself every time I’m looking for a library in Node Packages Registry. Every search with npm return tens of results, most of then being dead or sleeping projects. But for each one I get the URL, and have a look on Github to see if the project is alive and seems a little popular. Waste of time.

Fortunately, both npm and Github have easy to use API. So I just hacked a little mashup that performs a search with npm, eliminates packages not hosted on Github (sorry guys), and then queries Github to display some metrics (number of followers and forks, date of last update…). I can know select only two or three packages that the crowd seems to promote, and have a deeper look at them. I know this is not fair nor objective, but I had to find a way to quickly choose a library, so…

Enough words, if you’re interested just have a look at the code. Comments welcome :)

Ajouter des informations de Github aux résultats de recherche npm

Trop de choix tue le choix, c’est la réflexion que je me fais à chaque fois que je cherche une bibliothèque à utiliser dans un projet Node. Chaque recherche avec npm ramène des dizaines de résultats, mais la plupart sont des projets morts ou en hibernation profonde. Pour juger si le projet est encore vivant et jouit d’une certaine popularité, il faut aller faire un tour sur la page de chacun sur Github. Fastidieux.

Heureusement, tant npm que Github proposent des APIs. Bidouiller un script mariant les deux est très simple. Ce script recherche dans le registre de npm puis, pour chaque résultat dont le code est hébergé sur Github (oui, c’est un critère très subjectif), interroge Github pour afficher quelques informations comme le nombre de gens qui suivent le projet et l’ont dérivé ou la date de dernière mise à jour. Ça me permet de sélectionner deux ou trois projets adoubés par les foules, que je vais ensuite regarder de plus près. La méthode n’est certes ni très objective, ni très juste, mais il me fallait trouver quelques critères pour pratiquer un rapide écrémage.

Trêve de bavardages, si ça vous intéresse allez jeter un œil au code. Commentaires bienvenus :)

Mon lave-linge et moi

J’ai un aveu à te faire, camarade : je me moque du nombre de programmes disponibles dans mon lave-linge. À vrai dire, s’il n’y en avait qu’un, avec un seul gros bouton, je m’en porterais mieux. Et je n’ai aucune préférence en matière de lessive. Je ne prend jamais la même. Je m’en fous. C’est triste à avouer, mais je crois que je ne suis pas un geek des lave-linge.

Pourtant, pouvoir choisir la façon dont son linge sera lavé, c’est important. Du programme dépend probablement l’aspect des fringues qui en sortiront et, partant, l’allure que l’on aura en les portant. Si je ne choisis pas le bon programme, c’est le lave-linge qui choisira comment je serai habillé, qui déterminera le regard que l’on portera sur moi. Comme aime à le répéter mon chat, Si tu ne programmes pas ton lave-linge, ton lave-linge te programmera.

Je m’en fous.

Si demain, à l’allumage, il me posait moult questions avant que je puisse lancer une lessive, j’en serais sans doute rapidement énervé, et l’engin finirait à la benne, remplacé par un collègue moins brise-noix. Kékenahafout du prélavage, du programme « délicat », de l’adoucisseur ou que sais-je encore. Ce sont des termes techniques auxquels je n’entend rien. Je veux juste laver mon linge, décide pour moi, bestiole, je te fais confiance, mais surtout ne me demande pas de faire des choix, je n’y comprend rien et m’en fous.

Et pourtant, pourtant, j’ai ouï dire que dans de sombres recoins du réseau, des endroits à faire passer 4chan pour une visite de TeleTubbies sur l’île aux enfants, existent des forums où des fous furieux s’écharpent à longueur de nuit sur la vitesse d’essorage. Les uns prétendent à raison qu’elle dépend de la nature des tissus, et qu’il est inconcevable d’autoriser le programme à démarrer sans que le ménager n’ait choisi le nombre de tours par minute auquel son linge sera centrifugé. Cette fonctionnalité est d’ailleurs suffisamment importante pour mériter un gros bouton en façade de l’engin. Les autres répliquent fort justement, études comportementales à la main, que la majorité des ménagers et des ménagères ne maîtrise pas les subtilités de l’essorage, voir s’en moque, et que la machine doit fixer elle-même cette vitesse en fonction de ce qu’elle connaît des habitudes de son utilisateur et du contenu actuel de son ventre. Les débats sont souvent violents, on se lance des noms d’assouplissant, on claque les portes du tambour… J’ai beau être blasé, ne plus être étonné par grand chose de ce que je pourrais rencontrer en ligne, j’avoue avoir du mal à croire à l’existence de ces forums.

Mais je m’égare. Demain je vous parlerai de mon rapport aux voitures. Ou aux perceuses. À moins que je ne me fende d’un nouveau billet furibard pourfendant la stupidité de certains de mes contemporains qui utilisent des saloperies emprisonnantes comme MacOS, Windows ou Chrome, abandonnant leur liberté, acceptant d’être programmés, par simple volonté paresseuse d’avoir un produit qui simplement fonctionne. Comme un lave-linge. Un scandale !

Les applis Web arrivent sur GNU/Linux

Il était une fois…

Au commencement, le Web était un système de gestion de documents. Il permettait de créer des documents (via un langage simple, HTML), de les publier, les consulter et de créer des liens entre eux (via HTTP). Puis apparut l’interactivité, on ajouta aux navigateurs la faculté d’exécuter des programmes contenus dans des documents Web. Le temps passa et l’on put progressivement utiliser des programmes de plus en plus complexes à l’intérieur des navigateurs. Cette évolution se concrétise depuis quelques années avec HTML5. HTML5 est un ensemble de normes qui permettent au Web d’endosser une nouvelle fonction : c’est désormais à la fois une plate-forme de gestion de documents, et une plate-forme où l’on peut exécuter des applications.

Les applications Web, ou WebApps, ce sont des programmes hébergés sur le Web qui s’exécutent à l’intérieur d’un navigateur. Les Webmails sont probablement l’exemple le plus connu. Avec HTML5, ces applications Web sont désormais capables, dans de nombreux domaines, de faire pratiquement les mêmes choses que des applications « classiques » ou « natives », qui s’exécutent directement sur l’ordinateur. Pratiquement, mais pas encore tout à fait. Quelques limitations demeurent, que les développeurs s’attachent à marches forcées à combler.

Combler la lagune

Une de ces limitations est qu’une WebApp s’exécutant à l’intérieur du navigateur, elle n’a pas accès directement à l’ordinateur. Elle ne peut par exemple pas lire de fichiers sur le disque, accéder à l’appareil photo, etc. Pour combler ces lacunes, HTML5 s’enrichit régulièrement de nouvelles spécifications, des APIs. Mozilla travaille activement à la définition de ces APIs, via son projet WebAPI. Cela consiste à définir la façon dont les applications Web peuvent par exemple utiliser les fonctions de téléphonie, stocker des données sur l’ordinateur, communiquer les unes avec les autres, etc. Bref, faire exactement tout ce que peuvent faire des applications natives. Ces fonctions sont progressivement intégrées aux navigateurs qui les mettent à la disposition des sites et applications Web.

Faire son marché

Autre chantier en cours, permettre aux utilisateurs de facilement découvrir les applications répondant à un de leurs besoins. Les ordiphones ont popularisé un concept connu depuis longtemps des utilisateurs de GNU/Linux, celui de dépôts d’applications ou logithèques. Ce sont des sites Web centralisés où les développeurs déposent leurs applications et qui permettent aux utilisateurs de les installer. Même s’il a entraîné de très discutables dérives, c’est un modèle qui a prouvé sa pertinence. Pour permettre aux utilisateurs de facilement découvrir les applications Web dont ils ont besoin, il faut donc créer des sites centralisés répertoriant les applications et permettant de les installer.

C’est l’objet du projet Marketplace de Mozilla. On peut voir les applications Web comme des sortes d’extension du navigateur. Lorsqu’on cherche une extension, on peut utiliser un moteur de recherche et installer l’extension directement depuis le site de son créateur. On peut aussi aller sur le site dédié de son navigateur (par exemple pour Firefox). L’avantage de cette seconde option est que les extensions sont plus faciles à trouver, catégorisées, évaluées par d’autres utilisateurs et ont généralement été vérifiées pour s’assurer qu’elles ne contenaient pas de saloperies. Le Marketplace de Mozilla est un site Web qui offrira les mêmes fonctionnalités pour les applications Web.

Jouer

Une fois trouvée une WebApp, reste à l’installer sur son ordinateur ou son téléphone, et à l’utiliser. L’utilisateur se moque probablement de connaître les technologies utilisées par l’application, code natif ou HTML. Pour rivaliser avec les applications natives, seule compte l’expérience. Pour convaincre les utilisateurs, les WebApps vont probablement devoir dans un premier temps se rapprocher du fonctionnement bien connu des applications natives. Par exemple pouvoir être installées et utilisées comme n’importe quel programme, en faisant oublier qu’elles s’exécutent en fait à l’intérieur d’un navigateur. C’est un des objets du projet Open Web Apps. Il définit comment transformer une application s’exécutant sur un site Web en application utilisable directement sur l’ordinateur. Il fournit des outils qui permettent d’installer l’application au sein du système d’exploitation et de l’exécuter dans une version spéciale du navigateur, débarrassée des éléments de l’interface spécifique à un navigateur (barre d’URL, marque-pages, etc).

La version spéciale de Firefox pour les applications Web n’était jusqu’à présent disponible que pour MacOS et Windows. Non par désaffection pour l’environnement GNU/Linux, mais parce que du fait de l’hétérogénéité de cette plate-forme, trouver une solution qui fonctionne sur toutes les distributions et tous les environnements de bureau était un peu plus complexe. Heureusement, le retard sur GNU/Linux est en train d’être comblé, grâce au travail de Marco Castelluccio dans le cadre d’un projet Google Summer of Code. Marco tient à jour une page où il décrit ses objectifs et ses progrès. Grâce à son travail, on peut enfin depuis quelques jours installer une WebApp sur notre OS. C’est encore très basique, il reste beaucoup de travail. Mais ce travail est en train de se faire, et « à la Mozilla », c’est à dire de manière ouverte. C’est pourquoi je ne peux que t’inciter, Camarade Libriste, si tu veux avoir une solution qui roxxe sur ta plateforme, à tester sans plus attendre le bouzin — il te faudra pour cela une nightly et créer tes propres applis ou aller en télécharger sur la version de test du Marketplace —, pester contre ce qui ne fonctionne pas, ouvrir des tickets et, pourquoi pas, bidouiller toi-même le code. La feuille de route de Marco est chargée, et vu la diversité de notre plate-forme, si nous voulons avoir la meilleure implémentation dans toutes les configurations, il ne va pas falloir hésiter à mettre la main à la pâte.

Fork me on GitHub