Syndiquer le contenu
Mis à jour : il y a 12 min 5 sec

Profileurs mémoire MALT et NUMAPROF

2 septembre, 2018 - 15:40
Outils de profilage

En calcul à haute performance — HPC (High Performance Computing) —, les problèmes liés à la mémoire deviennent de plus en plus critiques, qu’il s’agisse du contrôle de la consommation mémoire des applications, de la limitation des interactions avec le système d’exploitation (trop nombreuses allocations, trop petites allocations…) et de choix de placement (NUMA) ; et relativement peu d’outils libres permettent de profiler les applications sur ce terrain. Deux outils récemment mis en ligne apportent une part de réponse à ces questions.

La suite de l’article présentera MALT et NUMAPROF plus en détails…

MALT

MALT (MALloc Tracker) a été développé lors d’un post‐doc comme un outil de profilage d’allocation mémoire. L’outil reprend la sémantique efficace du couple valgrind‐kcachegrind, mais appliquée au suivi des allocations mémoire d’une application C, C++ ou Fortran.

Fournissant une interface plus complète que kcachegrind, MALT fournit une interface graphique Web exportée par un petit serveur en Node.js. Cette approche a un double intérêt :

  1. rapidité de développement pour un rendu agréable, en utilisant les bibliothèques JavaScript Angular, Bootstrap, D3JS ;
  2. sur une grappe de serveurs distante, l’interface est rendue localement en se connectant au serveur distant par un ssh-port-forward, ce qui évite les ralentissements gênants et habituels liés à un X forward d’une interface Qt ou GTK ;
  3. possibilité de travailler à plusieurs sur le même profil.

L’outil fournit entre autres :

  • un résumé global sur la consommation de l’application ;
  • des annotation du source code pour les différentes métriques ;
  • des compteurs pour les tailles minimum et maximum d’allocation, le nombre d’allocations et la durée de vie ;
  • des graphiques temporels ;
  • la distribution de la taille des objets alloués ;
  • la distribution des allocations sur les différents fils d’exécution.

Exemple d’interface :

NUMAPROF

En calcul à haute performance et pour un certain nombre de serveurs, il est désormais courant de rencontrer des architectures dites NUMA (Non‐Uniform Memory Access). Autrement dit, avoir plusieurs processeurs sur la même carte mère, chacun attaché à ses propres bancs mémoire. La mémoire distante étant accessible de manière transparente, mais avec un surcoût. Cette topologie apparait même désormais à l’intérieur des processeurs eux‐mêmes, si l’on considère la gamme Xeon Phi d’Intel et certains processeurs AMD pour les serveurs.

Rappelons que sur les systèmes modernes, la mémoire vue par un programme est une mémoire dite virtuelle que le système d’exploitation est en charge, en collaboration avec le processeur, de faire correspondre à la mémoire physique. Cette correspondance entre les deux espaces est faite à l’aide du mécanisme de pagination consistant à découper ces deux espaces en pages (en général, 4 Kio ou 2 Mio sur les architectures x86 et x86-64).

Lorsqu’un segment est alloué par une application, il est initialement purement virtuel, le système d’exploitation autorisant cet espace mémoire, mais n’y projetant pas immédiatement de page physique. Ce n’est que lors du premier accès (dit « first touch ») que le système d’exploitation sera notifié et attachera une page à l’endroit touché.

Ce moment est critique sur architecture NUMA, car c’est à ce moment que le système d’exploitation va décider (en fonction de la position courante du fil d’exécution effectuant l’accès) sur quel nœud NUMA placer la page et donc les données. Le problème pour le développeur étant que cette association se fait de manière implicite par la première lecture‐écriture, et non par un appel explicite de fonction. Ceci conduit, dans de nombreuses applications, à des problèmes ignorés et de mauvaises correspondances difficiles à vérifier.

C’est dans ce cadre qu’a été développé NUMAPROF, en se basant sur pintool pour suivre tous les accès mémoire de l’application et reporter les correspondances NUMA. L’outil reprend une interface très similaire à MALT et fournit entre autres :

  • une annotation du source code ;
  • des métriques donnant le nombre d’accès distants, locaux, MCDRAM (pour les Intel Knight Landing), accès non liés (« bindés ») ;
  • une distribution sur les fils d’exécution ;
  • une matrice d’accès permettant de rapidement évaluer le comportement global de l’application.

Attention, l’outil ne prend pour l’instant en charge que les architectures x86-64.

Exemple d’interface :

Sources

Les deux outils sont libres et disponibles sur GitHub. Vous trouverez les sources, captures d’écran, documentations et liens vers des outils similaires sur : https://memtt.github.io/.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot)

31 août, 2018 - 20:46

Après le rachat de Splitted-Desktop Systems par ITRenew, l’été a été plus que studieux, et il s’est déroulé entre le pays de l’oncle Sam et notre bon vieux continent (à ce propos si vous voulez un truc, évitez la Californie en été, c’est bourré de geeks auxquels il faut ajouter les touristes et, là, ça devient n’importe quoi sur à peu près tous les sujets).

La rentrée c’est la semaine prochaine et il est temps de reprendre un peu le travail, tout en mêlant le plaisir. Cette rentrée s’annonce chargée pour ceux qui aiment l’Open Hardware et GNU/Linux. Plusieurs événements à venir, qui tiennent à cœur à votre serviteur, sont à découvrir en deuxième partie de dépêche.

On commence par quelque chose d’assez confidentiel à Erlangen (joli bourg à côté de Nuremberg) le 12 septembre (c’est bientôt), avec l’Open Source Firmware Conference, organisée par 9Elements, un des cofondateurs du projet LinuxBoot et membre du Technical Steering Committee (dont je fais partie). Pour plus d’info, c’est là : osfc.io. Les thématiques sont assez techniques et l’on y retrouvera le gratin du développement de micrologiciels libres, ainsi que des ingénieurs travaillant chez Google, Facebook et autres hyperscalers qui contribuent fortement à l’essor de LinuxBoot (allez Octave, les ingénieurs d’OVH sont les bienvenus).

Pour ceux qui ont du mal avec l’anglais, j’y donnerai deux « talks » avec un accent français bien prononcé. Un dont le titre est révélateur, « scotch-tape and flashrom », ou la dure vie d’un ingénieur BIOS. On racontera avec Arun Koshy de TCSL research les aléas, nous dirons ce que nous avons découvert avec chipsec. Le second « talk », « LinuxBoot CI », sera sur l’automatisation des tests des micrologiciels et l’apport de LinuxBoot et OpenBMC sur ces sujets.

Autre conférence, autre rôle de speaker. Embedded recipes, organisé par Hupstream à Paris. J’y donnerai un « talk » sur les modifications nécessaires au noyau Linux pour faire fonctionner LinuxBoot (avec un petit espoir de voir certaines de nos propositions reprises en amont). J’y serai co‐speaker avec Trammell Hudson de 2sigma, probablement un des meilleurs hackers que j’ai croisé ces dernières années.

Et pour finir en feu d’artifice, (OK, je ne suis peut‐être pas totalement intègre), l’OCP summit d’Amsterdam, du 1er au 2 octobre 2018. Pour ceux qui ne connaîtraient pas encore OCP, c’est un projet fondé par Facebook en 2011 qui poursuit pour objectif de dynamiser l’innovation dans les centres de données (datacenters) au travers de projets ouverts, sur lesquels vous pouvez contribuer. Il n’y pas que du matériel, beaucoup de logiciels, d’architecture, etc. (en clair, pas d’excuses pour ne pas venir).

La plupart des grands groupes américains seront représentés (OK, on dirait comme ça que j’encense les Étas‐Unis ; mais, en même temps, même si Octave semble vouloir s’intéresser au sujet, je n’ai pas encore totalement réussi à décrypter dans son tweet ce qui l’empêchait de basculer en Open Hardware ;)).

On y sera avec un stand, pleins de surprises et de nouvelles technologies (déjà publiques, hein Octave ; ce qui compte dans la propriété intellectuelle, c’est l’antériorité). Aaron Sullivan, directeur engineering hardware de Facebook, animera plusieurs débats avec des utilisateurs européens d’équipements Open Compute et de nombreux engineering workshops se tiendront.

Cela sera aussi l’occasion de découvrir la dynamique autour de ce marché et de venir glaner quelques idées sur les stands des différents sponsors. Plus que jamais, l’union fait la force. Et si vous êtes informaticiens, cela sera probablement le bon moment pour le constater.

L’événement est payant, mais pour ceux qui voudraient y venir et qui ont un petit budget, n’hésitez pas à me contacter (mon Twitter vejmarie) ; j’essaierai de vous trouver une solution.

Bonne rentrée à tous !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

GIMP 2.10.6 : rien ne nous arrête !

29 août, 2018 - 11:11

Alors que l’annonce précédente pour GIMP 2.10.4 vient à peine de quitter la première page des dépêches, voilà que GIMP 2.10.6 est déjà sorti !

Comme à notre habitude maintenant, non seulement cette version contient son lot de corrections, mais aussi plusieurs nouvelles fonctionnalités, dont certaines des plus excitantes, telles que l’écriture verticale, de nouveaux effets, des optimisations pour une expérience plus fluide…

Sommaire Principaux changements Calques de textes verticaux

Il est désormais possible d’écrire des textes verticaux, ce qui était une fonctionnalité particulièrement attendue pour l’écriture de certaines langues asiatiques, et aussi simplement pour tout besoin de design vertical.

Ainsi, GIMP propose plusieurs variantes de texte vertical, avec une orientation mixte (attendue dans les langues asiatiques qui pratiquent l’écriture verticale, à droite sur l’image) ou droite (plus habituelle pour l’écriture verticale occidentale, à gauche sur l’image), avec les colonnes successives pouvant aller de droite à gauche ou gauche à droite.

Merci à Yoshio Ono pour cette implémentation !
Pour la petite histoire, ce développeur avait apparemment écrit une version initiale du correctif pour GIMP 2.8, il y a cinq ans, puis il l’avait mis sur son site Web (plus récemment, semblerait‐il), ce qui fut découvert par hasard par quelqu’un sur un rapport de bogue demandant la fonctionnalité ! Depuis, je l’ai contacté, ai intégré son correctif (après qu’il a accepté de le mettre à jour), dans une version améliorée, revue et corrigée, et l’ai intégré à notre équipe.

Je pense que c’est à nouveau une belle illustration que le logiciel libre, ce n’est pas une sorte de cabale avec des membres désignés qui vous refusent des fonctionnalités. Le logiciel libre, c’est nous, c’est vous, c’est tout le monde !

Nouveaux filtres

Deux nouveaux filtres font leur entrée dans GIMP 2.10.6 :

Petite planète

Développée au‐dessus de l’opération gegl:stereographic-projection (qui existait déjà), ce filtre permet de créer de « petites planètes », à partir d’images panorama équirectangulaires 360 x 180°.

  Luftbild Panorama der Isar bei Ettling in Niederbayern, de Simon Waldherr (CC By-SA 4.0).

Ombres allongées

Ce nouveau filtre, développé par Ell, facilite énormément la création d’ombres allongées dans divers styles visuels.

Diverses configurations sont accessibles pour obtenir l’effet désiré. Une vidéo de démonstration est également disponible sur la news originale.

Redressement d’image amélioré dans l’outil de mesure

La nouvelle fonctionnalité de redressement horizontal implémentée dans GIMP 2.10.4 fut particulièrement appréciée. Nombreux sont ceux qui nous ont également demandé une possibilité de redressement vertical. C’est désormais possible !

  View of the western enclosing wall of the Great Mosque of Kairouan, de Moumou82 (CC By-SA 2.0).

En mode Auto (par défaut), l’alignement se fera par rapport au plus petit angle formé entre la ligne de mesure et les directions horizontale ou verticale. On peut également forcer le redressement dans l’une ou l’autre direction.

Optimisation du rendu des prévisualisations

Tout créateur qui a déjà travaillé sur des fichiers complexes, avec des dizaines de calques et de grandes images, a probablement vécu des ralentissements, notamment lors du défilement de la liste des calques et en affichant ou cachant des calques.

Une des raisons était que la génération des prévisualisations de calques se faisait dans le fil d’exécution principal et empêchait l’interface de se mettre à jour tant que toutes les prévisualisations n’étaient pas finies. Ell a rendu la génération des prévisualisations asynchrones, sur leur propre fil d’exécution, à l’exception des groupes de calques, qui ne peuvent pas encore être générés en asynchrone.
Pour cette raison, tant que ce cas n’est pas pris en charge à son tour, il est possible de désactiver la prévisualisation des groupes de calques en décochant la case adéquate dans PréférencesInterface.

Notons aussi que l’Ancrable « Tableau de bord » (introduit dans GIMP 2.10.0) affiche désormais le nombre d’opérations asynchrones, ce qui est surtout utile pour déboguer et analyser ce qui se passe dans GIMP.

Nouvelle localisation : Marathi

GIMP était déjà traduit dans 80 langues. Depuis cette version, ce nombre est passé à 81 !
Une équipe du North Maharashtra University, à Jalgao, a travaillé sur une traduction en Marathi, déjà presque complète.

C’est l’occasion de remercier nos nombreux traducteurs qui travaillent dans l’ombre continuellement pour améliorer la localisation de GIMP dans diverses langues. Ainsi, pour cette sortie, treize autres langues ont été mises à jour : allemand, espagnol, français, grec, hollandais, italien, letton, polonais, portugais brésilien, roumain, russe, slovène et suédois.

Simplification des filtres d’images (dialogues de fichier)

Une cause de confusion classique dans les dialogues de fichier (ouverture, sauvegarde, exportation) concernait la présence de deux listes de format de fichier, une pour l’affichage et l’autre pour le choix réel du format à prendre en compte. Nous avons simplifié cela.

Il n’y a donc plus qu’une seule liste qui fait office à la fois de filtre d’affichage et de choix du format de fichier.

Une nouvelle case à cocher permet d’afficher tous les fichiers inconditionnellement, ce qui est utile, par exemple, pour utiliser des extensions peu communes, ou réutiliser un nom de fichier existant en ne changeant que l’extension.

La fin de l’enfer des DLL ? Message pour les développeurs de greffons…

Un problème majeur depuis toujours, sur Windows, concerne ce que les développeurs nomment l’« enfer des DLL » (DLL hell en anglais). Ce problème (dans le cas de GIMP) se manifestait principalement à cause d’applications tierces qui installaient leurs bibliothèques logicielles (DLL) dans les dossiers système de Windows (ce qui est une mauvaise pratique sous Windows, puisque ces bibliothèques peuvent alors interférer avec d’autres logiciels utilisant les mêmes bibliothèques, mais dans une version différente ; pourtant c’est très courant), ou à cause de greffons s’installant avec une palanquée de bibliothèques dans le répertoire commun plug-ins/.

Le premier problème est désormais presque entièrement contourné en bidouillant l’ordre de priorité des dossiers de bibliothèques programmatiquement. Cette version de GIMP contient une correction additionnelle prenant en compte des greffons 32 bits s’exécutant sur un système 64 bits (mode WoW64).

Le second problème est déjà corrigé depuis GIMP 2.10.0, si et seulement si vous installez vos greffons dans leur propre sous‐répertoire (ce qui n’est pas encore obligatoire, mais le sera dans GIMP 3).

Par exemple, si votre greffon est monplugin.exe, installez‐le comme plug-ins/monplugin/monplugin.exe, avec toutes ses dépendances. Ce faisant, non seulement vous ne polluerez pas les autres greffons avec vos bibliothèques, mais surtout votre greffon ne sera pas bloqué par les bibliothèques installées par d’autres greffons.
Tous nos greffons officiels sont désormais installés ainsi. Nous conseillons ainsi à tous les greffons tiers de faire de même.

Développement en cours Préparez vous à l’invasion spatiale

Simultanément un projet surnommé « l’invasion spatiale » est en cours à la fois sur les fronts babl, GEGL et GIMP 2.99 (version de développement). Le but final est de simplifier et d’améliorer la gestion des couleurs dans GIMP (et autres projets basés sur GEGL).
  Chèvres mutantes de l’espace en phase d’atterrissage dans GIMP

Un an plus tôt, babl, la bibliothèque utilisée par GEGL et GIMP (et développée par les mêmes personnes) pour les conversions de couleur a été améliorée pour lier un espace de couleur RVB arbitraire à un format de pixel. Cela avait permis de commencer à utiliser babl pour convertir les couleurs entre certaines classes de profils de couleur, au lieu de se reposer sur la bibliothèque LCMS. L’une des conséquences immédiates fut une impressionnante amélioration des performances. Toutefois ces conversions n’étaient encore effectuées qu’entre la représentation interne des pixels dans GIMP et le « monde extérieur », avec peu d’effet dans les manipulations internes des pixels. Cela rendait certaines opérations de couleur moins correctes.

Le travail en cours corrigera ce problème en faisant en sorte que toute donnée d’image sera attachée à son profil, permettant ainsi à GEGL et GIMP d’effectuer les conversions adéquates au moment opportun pour que toute opération d’image soit appliquée dans l’espace de couleur approprié.

Ce travail se fait actuellement sur les branches stables de babl et GEGL, et la branche de développement de GIMP (futur GIMP 3). Ces améliorations seront cependant vraisemblablement rétro‐portées prochainement dans une version de GIMP 2.10.x, en accord avec notre nouvelle politique de sortie.

Les extensions GIMP

J’en parlais déjà dans l’annonce précédente. En plus de mon travail habituel d’amélioration de GIMP, j’ai enfin commencé à implémenter un de mes plus vieux projets pour GIMP : la gestion avancée des extensions, comme d’habitude sous la houlette du projet ZeMarmot.

Une extension peut contenir toute donnée installable dans GIMP, des greffons aux brosses, en passant par des motifs, des images de lancement (splash screen), des dégradés, etc. Le but est clairement de permettre, d’une part, aux créateurs de telles extensions de pouvoir les diffuser aisément en les téléversant sur des dépôts publics d’extensions, et d’autre part, de faciliter la recherche et l’installation de telles extensions pour tous, avec gestion des versions, mises à jour, etc.

  Installer, (dés)activer et mettre à jour des extensions en un clic

Là encore, le travail en cours est disponible dans la branche de développement principale et devrait parvenir dans une version future de GIMP 2.10.x.

Aidez le développement

Comme souvent, nous rappelons que vous pouvez aider au développement financièrement, si vous le souhaitez, grâce au financement participatif en continu des développeurs de GIMP. En particulier, deux développeurs sont actuellement financés collaborativement: pippin (pour le développement de la bibliothèque graphique GEGL) et moi‐même (Jehan), pour mon travail sur GIMP (je suis le développeur le plus actif sur la dernière année d’après OpenHub, en nombre de commits), grâce au projet ZeMarmot.

Si vous appréciez notre travail et souhaitez nous permettre de continuer à rendre GIMP encore meilleur, n’hésitez pas à nous soutenir :

Mais surtout, amusez‐vous bien avec GIMP !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

OpenDBViewer 1.1.0

29 août, 2018 - 11:11

Il y a presque un an, une dépêche annonçait le logiciel OpenDBViewer, sponsorisé par l’entreprise Jet1oeil et supervisé par moi‐même.

Il s’agit, comme son nom le suggère, d’un petit logiciel très léger écrit en C++/Qt pour lire et modifier les bases de données SQLite, MySQL et PostgreSQL. Le logiciel est sous licence GPL v3.

Avec la venue de stagiaires dans l’entreprise, nous avons pu développer de nouvelles fonctionnalités durant l’année afin d’encore améliorer son ergonomie.

Les fonctionnalités du logiciel sont :

  • compatibilité avec les systèmes d’exploitation GNU/Linux, macOS et Windows ;
  • compatibilité avec les bases de données SQLite, MySQL et PostgreSQL ;
  • coloration syntaxique SQL dans les feuilles de travail SQL ;
  • vue multiple des bases de données, tables et feuilles de travail.

Dont les nouveautés :

  • chargement de bases de données lourdes ;
  • chargement de bases SQLite via glisser‐déposer ;
  • historique des dix dernières connexions ;
  • modification de la base de données directement depuis la vue d’une table.

Nous utilisons surtout le logiciel avec SQLite sous GNU/Linux, alors nous sommes preneurs de retour d’utilisation sous Windows et macOS, afin de corriger les éventuels bogues.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Libération du code source de muzi.ch, quelle licence ?

29 août, 2018 - 11:10

Voilà il y a peu Spf me convainc d’ouvrir le code source du muzi.ch. En effet, je ne développe plus ce projet et je me suis souvent posé cette question de libération. Je n’avais pas encore franchi le pas pour une raison toute bête : le code source est vieux, j’ai rédigé ça il y a longtemps, le code n’est pas très pro, blablabla…

Cependant, pourquoi garder ce code fermé… Peut‐être que le projet intéressera la communauté et pourra avoir une seconde vie ? Bref, ça y est, j’ouvre le code source.

Muzi.ch qu’est‐ce que c’est ?

Déjà, vous pouvez aller y faire un tour : https://muzi.ch.

Un site Internet qui permet de :

  • écouter la musique partagée (depuis YouTube, SoundCloud, etc.) sur le réseau public ou le réseau personnel ;
  • écouter la musique avec un lecteur automatique ;
  • créer des listes de lecture ;
  • voter et mettre en favoris des partages de musique ;
  • étiqueter les partages ;
  • apposer des commentaires sur les partages.
Licence

Je n’ai pas encore choisi de licence pour ce projet. Je suis à l’écoute de vos propositions. À noter que le graphisme du site a été réalisé par floor26, qui doit en garder la paternité.

Ce que peut apporter l’ouverture du code source

Au‐delà de pouvoir monter son propre réseau « muzi.ch », je pense qu’il y a plusieurs possibilités :

  • couplage avec des systèmes comme Mastodon ;
  • fédération des réseaux.
Travail à effectuer aujourd’hui

Il reste à :

  • compléter le README pour l’installateur complet du projet (avec les tests automatiques) ;
  • mettre à jour les dépendances (le code a été rédigé en 2014, php5 avec Symfony2) ;
  • proposer un graphisme un peu personnalisable.
Le mot de la fin

C’est assez émouvant d’ouvrir le code source de ce projet sur lequel j’ai passé plus d’un millier d’heures de travail. J’espère que le projet plaira et qu’il retrouvera un nouveau souffle.

Il n’existe pas encore d’espace de discussion autour de ce projet. Dans un premier temps je pense que les commentaires de cette page pourront suffire. Vous pouvez d’ores et déjà effectuer des propositions de code ou rapports de bogues sur le Gitea du projet.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Linux Presentation Day d’automne 2018

29 août, 2018 - 09:05

Le Linux Presentation Day (ou LPD) est l’occasion de découvrir GNU/Linux et les logiciels libres. Un grand nombre de groupes d’utilisateurs de GNU/Linux (GUL) du monde entier, ainsi que des entreprises et des universités, organisent deux fois par an, aux mêmes périodes, des rencontres afin de présenter GNU/Linux et les logiciels libres.

Le prochain Linux Presentation Day aura lieu en France, à partir de l’équinoxe d’automne, c’est‐à‐dire le dimanche 23 septembre, pendant une semaine, jusqu’au samedi 29 septembre.

Ainsi, nous vous proposons d’inscrire sur cet espace, les activités de votre structure sur la présentation de GNU/Linux qui auront lieu lors de cette semaine.

L’organisation se fait en partenariat avec le site belge linux-presentation-day.be.

Les événements d’ores et déjà prévus (en attendant les vôtres) :

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Crowl, un crawler SEO open-source

28 août, 2018 - 22:03

Crowl est un projet de développement d’un crawler SEO collaboratif sous licence GPL v3. Développé en Python et basé sur le cadriciel Scrapy, Crowl a pour but de fournir aux professionnels du référencement un outil simple, robuste et innovant pour répondre à des besoins non couverts par les outils actuels.

À quoi sert un crawler SEO ?

Crawler, spider, scraper ou robot d’indexation : quel que soit le nom qu’on leur donne, de nombreux robots parcourent le Web et réalisent différentes tâches. La plupart du temps, il s’agit de récupérer des informations sur les pages Web et de les stocker.

Pour les professionnels du SEO, le modèle est Googlebot : la famille de robots d’indexation de Google. Ces robots parcourent chaque jour des dizaines de milliards de pages Web. Mais les besoins d’un moteur de recherche ne sont pas les mêmes que ceux d’un référenceur : là où le premier doit parcourir le Web dans son intégralité, le second cherche à optimiser un seul site (à la fois).

Les informations récupérées sont variables, mais on s’intéressera au statut HTTP des pages, à leur contenu ou encore aux liens qui les relient. Ces informations permettent ensuite de réaliser différentes analyses et de définir les chantiers d’optimisation du site concerné. Il peut s’agir de problèmes simples (liens cassés, redirections inutiles, pages dupliquées…) ou d’analyses plus complexes (répartition de la popularité interne, pertinence du contenu…).

Yet another crawler?

De nombreux outils existent sur le marché, mais la plupart sont commerciaux ou obsolètes. Par ailleurs, ils sont souvent limités d’une manière ou d’une autre dans leur fonctionnement. Bon nombre sont limités quant au volume de pages à traiter, ou aux informations qu’il est possible de récupérer.

Ainsi, il n’est pas rare que des référenceurs se lancent dans la conception d’un crawler pour dépasser ces limitations. Malheureusement, ce sont souvent des initiatives isolées, et « crawler » le Web n’est pas aussi simple qu’il n’y paraît.

Au fil de discussions avec quelques confrères, nous avons réalisé que nous étions plusieurs à travailler sur les mêmes problématiques en parallèle. Afin de mettre nos efforts en commun, nous avons décidé de lancer un projet open source, dans l’espoir d’attirer d’autres contributeurs.

Comment fonctionne Crowl

Crowl est basé sur Scrapy, un cadriciel Python qui permet d’extraire facilement des données depuis les sites Web. C’est une excellente base de départ, d’autant plus que Python est un langage facile d’accès et déjà utilisé par de nombreux référenceurs, notamment pour ses capacités en science des données. Cependant, Scrapy n’est pas pensé pour répondre aux besoins d’un crawler SEO et demande un certain nombre de configurations et d’adaptations.

En l’état, Crowl propose donc un projet Scrapy configuré pour les besoins génériques des référenceurs. Il est capable de parcourir l’intégralité d’un site Internet et de stocker les informations utiles dans une base de données MySQL.

Nous proposons en outre une méthode de calcul du poids des liens sortant d’une page Web, basée sur leur hauteur respective dans le code source. Ceci permet le calcul d’un PageRank interne plus précis, car les liens en pied de page sont ainsi dévalués.

Feuille de route et perspectives

Si l’outil est déjà opérationnel, il reste très basique pour l’instant. Nous avons déjà de nombreuses idées pour l’améliorer, qui seront mises en place au fil du temps et de la disponibilité des contributeurs.

Parmi ces idées, on peut citer le choix de multiples options de sauvegarde des données en plus de MySQL, la configuration des options au moyen d’un fichier de configuration, ou encore la création d’une interface utilisateur pour lancer les crawls et en analyser les résultats.

L’objectif est de séparer les principales fonctionnalités en une suite de modules indépendants pour traiter :

  • le crawl en lui‐même ;
  • les traitements post‐crawl ;
  • les interfaces de lancement et d’analyse d’un crawl.

Toute contribution est la bienvenue, y compris de la part de personnes qui ne sont pas issues du milieu du SEO : les contributeurs actuels n’étant pas des développeurs professionnels, nous sommes preneurs des conseils de personnes plus aguerries.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Embedded Recipes 2018 : bientôt les inscriptions

28 août, 2018 - 22:00

Nous sommes fiers de vous convier à la deuxième édition d’Embedded Recipes, cette fois‐ci pour deux jours de conférences, les 24 et 25 septembre 2018 à Paris.

Plus de talks, plus d’orateurs : Charles‐Antoine Couret, Fabien Lahoudère, Grant Likely, Guy Lunardi, Jean‐Marie Verdun, Jérémy Rosen, Marek Vašut, Mathieu Renard, Neil Armstrong, Rayna Stamboliyska, Ryad Benadjila, Steven Rostedt, Trammell Hudson et Yves‐Marie Morgan.

Cette année, deux jours consacrés à l’embarqué : couches basses, utilitaires, plate‐forme d’intégration, industrialisation, contribution, sécurité… Il y en aura pour tout le monde !

Merci à Mozilla qui nous accueille et nous permet de fournir une diffusion vidéo de la conférence. L’ensemble des supports et vidéos seront proposés en ligne après la conférence.

Merci également à nos sponsors sans qui cette conférence ne serait pas aussi accessible : Collabora, ARM, Baylibre et CIO systèmes embarqués.

Les inscriptions débuteront le jeudi 30 août 2018.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Kernel Recipes 2018 : c’est reparti pour la 7ᵉ édition !

28 août, 2018 - 18:45

Nous revoilà, gonflés à bloc pour lancer les inscriptions à cette septième édition de Kernel Recipes, qui aura lieu du 26 au 28 septembre 2018 à Paris. Encore une fois nous avons essayé de vous concocter un programme varié permettant de balayer une partie de l’actualité du noyau : sécurité, réseau, Spectre, développement… Il y en aura pour tout le monde !

Cette année encore de super orateurs qui ont bien voulu répondre présents : Steven Rostedt, Dodji Seketeli, Rafael J. Wysocki, Bartosz Gołaszewski, Jesper Dangaard Brouer, Will Deacon, Julia Lawall, James Bottomley, Vaishali Thakkar, Jiri Kosina, Frédéric Weisbecker, Paolo Bonzini, David Woodhouse, Miguel Ojeda, Alexander Graf, Ezequiel García, Nicolas Planel, Grégory Clément.

Cette année, Anisse Astier nous rejoint et publiera directement sur le site de la conférence sa retranscription en temps réel des différents talks.

Soutien indéfectible de la conférence, Mozilla Paris nous accueille cette année encore et nous propose des conditions parfaites pour ces trois jours d’échanges. Un diffusion en direct sera proposée tout au long de la conférence et les vidéos et supports de chacune des interventions seront proposés dans les semaines qui suivent l’événement.

Un grand merci également à nos supporteurs sans qui cette conférence ne pourrait pas être aussi accessible : notre partenaire et soutien depuis le début, Gandi, mais aussi ARM, Parrot, Baylibre, Red Hat, SUSE et Collabora.

Les inscriptions démarreront le jeudi 30 août 2018. Nous mettrons à disposition les places en deux fois, matin et après‐midi.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Agenda du Libre pour la semaine 35 de l’année 2018

26 août, 2018 - 12:03

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 11 événements (2 en Belgique, 8 en France, 0 au Luxembourg, 1 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

Sommaire [BE Bruxelles] Edition 2018 educode - Du dimanche 26 août 2018 à 18h00 au mercredi 29 août 2018 à 20h00.

 Educode.be est une conférence internationale educode sur l'enseignement et le numérique.

L'idée est que si nous voulons que nos concitoyens soient demain capables de gérer leurs environnements numériques, il faut aujourd'hui informer, former et faire réfléchir les enseignants, les directions et les décideurs politiques qui le plus souvent sont autodidactes. 

Les présidents d'honneur sont Bernard Rentier, ancien recteur de l'université de liège et Yves Poullet, ancien recteur de l'université de Namur.

La conférence commence par un cocktail d'accueil dimanche 26 août à 18h00 dans la salle de marbre de l'académie royale.

Elle commence réellement lundi 27 à 9h00 dans la salle Henri Le Bœuf de Bozar.

le programme est quasi fait.

Il sera visible sur http://educode.be/programme.

La dernière conférence de la journée sera de Thomas Pesquet, astronaute français qui a emporté des expériences de sciences utilisant des ordinateurs préparées par des lycéens français et sélectionnées par ESA.  

Toute la journée, il y aura une exposition de groupes d'enfants et de moins jeunes qui font des choses amusantes et intéressantes avec du numérique en classe ou en dehors des classes.

Puis nous profitons de la plus belle salle de concert bruxelloise pour faire un concert symphonique d'amateurs avertis avec des chœurs d'enfants et d'adultes pour célébrer la paix et marquer le 90e anniversaire du pacte de Paris ou pacte Brian-Kellog signé le 27 août 1928 et trop vite oublié.

Quel meilleur symbole pour marquer la paix que d'associer la musique et les langages de programmation, toutes langues universelles.

Mardi 28, de 9h00 à 17h00, nous organisons 60 à 80 ateliers pratiques sur des sujets très variés, depuis des usages de logiciels de composition musicale ou d'aide à la version latine jusqu'à la mise en forme d'enregistrements vidéo avec smartphone ou l'apprentissage de la programmation avec ou sans ordinateur en passant par des ateliers sur les méthodes agile et scrum adaptées à l'enseignement ou des ateliers expérimentaux de physique et chimie avec ordinateurs et smartphones.

En fin de journée, la fin du congrès pour la majorité des enseignants, nous allons prendre un buffet convivial autour des iguanodons de l'institut d'histoire naturelle.

Mercredi 29 de 9h00 à 18h00 à l'académie royale à nouveau, nous réfléchissons durant la journée aux expériences positives partout, échangeons sur celles-ci en mode congrès scientifique. 

Nous avons le soutien de nombreux partenaires, toutes les universités francophones, deux flamandes, de nombreuses associations, l'unesco, l'institut de formation en cours de carrière qui permet que les professeurs viennent en formation officielle, IBM, cap gemini, la plupart des ministres mais pas encore de garantie pour celui de l'enseignement obligatoire bizarrement. 

Bien sûr, pour faire la conférence comme nous en rêvons, votre soutien tant moral que financier serait très important.

Il manque encore des sous (nous sommes aussi occupés à essayer d'obtenir la possibilité que les dons soient défiscalisés si cela vous intéresse) 

L'affiche actuelle dans http://esi.link/educode-affiche-fr-02

[BE Bruxelles] Stand Primtux au colloque international Educode - Le lundi 27 août 2018 de 08h00 à 21h00.

EduCode est un colloque international dédié à l’éducation, aux pratiques et à la recherche dans les domaines liés au numérique.

Il est le résultat d’une collaboration entre différents acteurs-clé du numérique en Belgique et à l'étranger.

Pour plus d'information https://educode.be L'équipe Primtux est heureuse d'y tenir un stand.

Primtux est une distribution éducative à base de Debian, comprenant une centaine d'applications éducatives, regroupées selon des créneaux d'âges.

La distribution peut servir autant dans des écoles primaires que dans des centres périscolaires, des associations d'éducation populaire ou simplement des familles.

Toutes les infos sur https://primtux.fr

StéphaneDeudon, le créateur de la distribution, sera présent et informera les visiteurs.

[CA-QC Montréal] HackerNest BBQ d'août - Le lundi 27 août 2018 de 19h00 à 22h00.

HackerNest Tech Socials vous permettent d’établir des contacts avec vos confrères / consoeurs en tech en toute convivialité. L'atmosphère cool, amical, sans prétention, sans agenda (pas de vente), et plein de gens UltraIntelligent.

Horaire Tech Social typique arriver, prendre des boissons, socialiser >> introduction rapide, annonces et mercis aux sponsors >> retour à jaser avec de nouveaux et anciens copains >> rentrer à la maison, exalté par de grandes conversations

**** Entrée est $10. Si ce n'est pas possible, s'il vous plaît envoyez un courriel à Lydia à lydia@hackernest.com et inscrivez-vous pour faire du bénévolat cette nuit-là. ****

Août - quel meilleur moment pour organiser notre premier BBQ HackerNest Notre hôte Mingus Software fournira les boissons et les chips. Lighthouse Labs fournira des hotdogs (viande et végétalien / sans gluten) et salades. On vous offre de la bière, vin, l'eau, soda/pop, chips, salades, et hotdogs.

[FR Toulouse] Rencontres Tetalab - Le mercredi 29 août 2018 de 20h30 à 23h30.

Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

Ouvert au public tous les mercredi soir.

Venez nombreux.

[FR Challans] Permanence Linux - Le jeudi 30 août 2018 de 18h00 à 20h00.

Chaque dernier jeudi du mois, l'association Linux Challans vous donne rendez-vous à l'Albanera Café, 17 rue du Général Leclerc 85300 Challans.

Nous vous proposons lors de ces rendez-vous mensuels d'échanger autour du Libre, des conseils ou une assistance technique.

Vous pouvez venir pour vous faire aider, ou aider, à installer et paramétrer une distribution GNU/Linux de votre choix ou des logiciels libres sur votre ordinateur.

Recommandations

  • Sauvegardez vos données avant de venir.
  • Libérez de la place sur le disque dur (20 Go minimum) et défragmentez Windows si vous voulez le conserver.
  • Nous prévenir de votre passage via la messagerie.

Nous vous attendons toujours plus nombreux

[FR Paris] Soirée de Contribution au Libre - Le jeudi 30 août 2018 de 19h30 à 22h00.

Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.

Nous nous réunissons donc tous les dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

Regazouillez sur Twitter - Wiki des soirées

Programme non exhaustif

  • Fedora (sa traduction)
  • Parinux, ses bugs et son infrastructure
  • April, … y a toujours quelque chose à faire
  • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
  • Schema racktables, son code
  • Agenda du Libre, mise à jour et amélioration du code
  • Ubuntu-Fr, son orga, ses événements
  • En vente libre, maintenance et commandes
  • Open street map, une fois par mois
  • Linux-Fr sait faire
  • en vente libre

tout nouveau projet est le bienvenu.

[FR Mérignac] Permanences du libre - Le vendredi 31 août 2018 de 19h00 à 21h00.

Unbee est une association qui relie entre eux les utilisateurs du monde libre sur Mérignac.

En partenariat avec le Puzzle, tous les 1er vendredis de chaque mois, l'association Unbee organise un moment d'échange et de discussion autour des logiciels libres Ubuntu, Libre office, Gimp, Inskscape entre autre…

Sur place, vous pourrez consulter magazines et livres sur la même thématique.

Nous nous réunissons pour partager nos connaissances techniques et philosophiques du numérique libre, il n'y a pas d'expert, tout le monde participe et enrichit le débat

Avant de venir nous voir, il vaut mieux vérifier les dates dans le calendrier sur notre site internet.

[FR Orléans] Réunion mensuelle - Le vendredi 31 août 2018 de 20h30 à 23h00.

La prochaine réunion de l'association aura lieu le vendredi 31 août à partir de 20h30 à la salle des Arteliers de la Source

(2 rue Edouard Branly à Orléans-la-Source)

Au programme de ce vendredi

  • Vie de l'association prochains évènements (Festiv'asso, Rentrée en Fête, Vivre autrement en Sologne)
  • Configuration de pc
  • Questions diverses

Pour venir nous voir Plan d'accés

Grignotages et boissons assurée pour la bonne humeur de tous.

Venez nombreux et parlez-en autour de vous car les réunions de l'association sont aussi ouvertes aux non adhérents.

[FR Aix-en-Provence] Samedi Libre - Le samedi 1 septembre 2018 de 10h00 à 18h00.

PROGRAMME Attention aux NOUVEAUX HORAIRES

10h00 - 12h30 Atelier d'organisation des ateliers 2018-2019

12h30 - 13h30 Déjeuner en commun

13h30 - 18h00 Interventions sur rendez-vous et démonstrations

INFORMATIONS GÉNÉRALES

Ces **Samedis Libres sont organisés par l'Axul en collaboration avec plusieurs associations de logiciels libres des Bouches-du-Rhône.**

Ils proposent des présentations générales et une aide technique pour le dépannage et la mise à jour d'ordinateurs avec des logiciels libres. Ils présentent aussi des démonstrations de matériels libres.

Des informations sont disponibles sur la Culture Libre (OpenStreetMap, Wikipedia…).

PRÉSENTATIONS POSSIBLES

Présentation de livres et de sites Internet consacrés au Libre

conçu pour rendre l’enseignement et l’apprentissage facile et amusant.

Présentations liées aux nouveaux programmes scolaires sur le codage

  • Présentations de Pygame, Python, Scratch et Snap.
  • Présentations de modèles éducatifs libres écrits en HTML5 pour PC ou tablettes quel que soit le système d'exploitation exemple du site PhET.
  • Présentation du projet 1, 2, 3… codez: Enseigner l'informatique à l'école et au collège (Fondation La main à la pâte).
  • Présentations d'autres logiciels éducatifs et/ou scientifiques…

Autres présentations

  • Comparaison des environnements Cinnamon, GNOME, KDE, LXDE et Xfce installés avec la même version d'Ubuntu.
  • Distribution Emmabuntüs pour la rénovation d'ordinateurs anciens.
  • Distribution PrimTux 2 pour les élèves de l'école primaire.
  • Distribution Pure OS associée au projet Librem pour des ordinateurs avec des matériels et des logiciels libres.
  • Distribution Ubuntu 17.10.
  • Distribution Ubuntu Touch sur un téléphone mobile.
  • Distributions Linux installées sur des clefs USB insérées dans des ordinateurs Linux, Windows 7 ou Windows 10.
  • Cohabitation Linux - Windows 10 le cas d'Ubuntu 64 bits.
  • Évolution du projet pédagogique OLPC (One Laptop per Child) : ordinateur XO-4, tablette OLPC partiellement libérée avec F-Droid et différentes machines avec la plate-forme pédagogique Sugarizer.
  • Présentation d'Inkscape, logiciel de dessin vectoriel professionnel pour Windows, Mac OS X et GNU/Linux
  • Présentation de logiciels scientifiques libres (SageMath…)

NB Certaines démonstrations pédagogiques sont en libre service. Les autres démonstrations seront normalement possibles toute la journée elles seront lancées en fonction des souhaits des visiteurs et des disponibilités des spécialistes.

Adresse Centre Social et Culturel des Amandiers, 8 allée des Amandiers, Jas-de-Bouffan (cliquer sur ce dernier lien pour avoir un plan détaillé).

Ces samedis libres et gratuits sont ouverts à toutes et à tous, débutant(e)s ou expert(e)s GNU/Linux, membres ou non d'associations du Libre. Les locaux sont au rez-de chaussée et accessibles par tous.

Entrée Libre..

Prochain Samedi Libre

[FR Paris] Premier Samedi du Libre - Le samedi 1 septembre 2018 de 14h00 à 18h00.

Chaque premier samedi de chaque mois, de 14h00 à 18h00, des bénévoles passionnés de logiciels libres se retrouvent au Carrefour Numérique² de la Cité des Sciences, pour une install-party de distributions ou, ainsi que des ateliers et (parfois) des conférences.

Venez aider ou vous faire aider à installer et paramétrer des logiciels libres et toute distribution GNU/Linux ou Android avec les associations d'utilisateurs de FedoraMageiaUbuntu, Debian, Trisquel… (pour GNU/Linux) ; Replicant, LineageOS, f-droid (pour Android), sur netbook, portable, tour, PC/Mac (pour GNU/Linux), smartphone ou tablette (pour Android), éventuellement à côté de votre système actuel (pour GNU/Linux).

N'hésitez pas non plus à passer si vous rencontrez des difficultés avec des périphériques, matériels, logiciels libres sous ou Android.

  • 12h30-13h45 déjeuner à la pizzeria Le Verona, 25 avenue Corentin Cariou
  • 14h00-18h00 salle Classe Numérique install party GNU/Linux et Android, toutes distros
  • 14h00-18h00 salle Atelier atelier Blender3D du BUG (Blender3D Users Group)
  • 14h00-18h00 salle LivingLab atelier Brique Internet/auto-hébergement avec franciliens.net + atelier accessibilité avec des membres de Liberté 0
  • 14h00-18h00 salle Studio wikipermanence de l'association Wikimedia
  • et après 18h,  on continue à échanger et discuter (généralement dans un bar avenue Corentin Cariou)

Pour les salles, voir le plan du Carrefour Numérique.

Nous avons besoin de volontaires pour l'accueil et les installations. Il est utile, mais pas obligatoire, de vous inscrire comme parrainé, parrain, ou visiteur sur le site premier-samedi.org en décrivant votre matériel et vos attentes.

Parrainé·e·s

  • Pour l'installation d'une distribution :

    • venez de préférence dès le début (vers 14h-14h30)
    • sauvegardez sur disque externe, clé usb ou DVD vos fichiers importants
    • supprimez les fichiers et logiciels superflus
    • faites un nettoyage de disque et une défragmentation (utilitaires Windows)
    • n'oubliez pas votre chargeur, vos câbles etc.
    • prenez connaissance de la présentation, du code de conduite, du document présentant les liens et infos utiles et de la décharge
    • apportez un disque dur externe ou une clé usb ou un dvd
  • Pour l'installation d'une distribution Android

    • venez de préférence dès le début (vers 14h-14h30)
    • sauvegardez les données des applications (SMS, contacts, etc) car elles seront effacées durant l'installation, et si possible les fichiers/dossiers personnels (musique, films, pdf, etc) afin de ne pas risquer de les perdre en cas d'erreur technique
    • Si possible, essayez de vérifier s'il y a des distributions compatibles avec votre appareil
    • https://wiki.lineageos.org/devices/: liste des appareils compatibles avec LineageOS
    • https://redmine.replicant.us/projects/replicant/wiki/ReplicantStatus#Replicant-60: liste des appareils compatibles avec Replicant, ainsi que la liste des fonctionnalités (GPS, camera, etc) prises en charge
  • Dans tous les cas:

    • demandez l'autorisation de prendre des photos si vous souhaitez en prendre
    • n'oubliez pas que nous sommes des bénévoles, pas un S.A.V.  ;-)

Parrains et marraines

  • ISOs de nombreuses distros installables par serveur local Parinux et Raspberry-Pi 3
  • apportez une clé usb 3 ou un dvd, des ISOs, de vos distros favorites
  • demandez si l'installé·e a bien sauvegardé ses fichiers
  • demandez si l'installé·e a bien nettoyé, défragmenté, CHKDSKé
  • si possible, autonomisez l'installé-e, expliquez, laissez-lui le clavier
  • prenez connaissance de la présentation, du code de conduite, du document présentant les liens et infos utiles et de la décharge
  • évitez de commencer une installation complète après 16h00
  • préférez une réinstallation propre à une longue mise à jour
  • terminez ce que vous avez commencé ou passez le relais
  • incitez l'installé·e à se rapprocher de l'association dédiée à sa distribution
  • si possible, installez et lancez l'utilitaire Bleachbit.

Entrée libre et gratuite, pour tout public.

Transports

[FR St-Paul-en-Jarez] Conférence Comment se libérer des géants de l'informatique avec les logiciels libres - Le dimanche 2 septembre 2018 de 10h00 à 11h00.

L'avènement du numérique a été le moteur de nombreuses innovations technologiques et catalyseur de nombreuses créations numériques.

Ainsi ces dernières années nous avons pu voir des entreprises et des services aussi populaires que Google, Facebook, Microsoft, Apple, Youtube, Netflix, …

Des outils bien attrayants mais pas dénués de problématiques exploitations et partage de vos données personnelles, centralisation des services, obsolescence programmée, …

Les logiciels libres font partie des pistes de solutions à ces problématiques, avec d'autres bonnes pratiques qui seront proposées.

Cette conférence est destinée au grand public, et a lieu dans le cadre du festival "Groseille et Ciboulette", dont le programme complet est disponible dans ce PDF.

Elle sera animée par un membre de l'ALDIL (Association Lyonnaise pour le Développement de l'Informatique Libre), le dimanche 2 septembre de 10h00 à 11h00, tout au long duquel le public sera invité à échanger avec l'animateur, poser ses questions.

Une install party dédiée aux logiciels libres sera également tenue toute la journée du dimanche par ALOLISE (Association pour la promotion des Logiciels Libres de la région de Saint-Etienne).

Ce sera l'occasion de voir les logiciels libres en action

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Sortie de la version 0.8 de chordV

26 août, 2018 - 08:51

ChordV est un éditeur de partition et plus précisément un générateur de carnet de chansons, de grilles d’accords de guitare. Il permet aussi l’affichage des paroles de chansons pendant l’enregistrement ou de faire un karaoké. Il est écrit en C++ et placé sous licence GPL v3+.

Pour l’enregistrement, il assure la synchro par Jack transport pour démarrer les paroles sur un signal. Il permet de cadencer l’affichage des paroles en suivant le tempo et les temps du carnet de chant.

Le projet est disponible sur SourceForge et sur le site de l’auteur (RPM et .deb).

Pour voir d’autres copies d’écran : http://www.gillesmaire.com/tiki-index.php?page=chordV.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

VideoLAN Dev Days du 21 au 23 septembre 2018

25 août, 2018 - 12:32

Les VideoLAN Dev Days sont la conférence annuelle où l’ensemble de la communauté multimédia open source se retrouve. La dixième édition se déroulera au QG de Free (ouais !) les samedi et dimanche 22 et 23 septembre 2018.

Un jour communautaire, uniquement pour le fun, est aussi prévu le vendredi 21 dans la ville de Paris (ne soyez pas étonnés si vous apercevez une invasion de cônes dans les lieux touristiques).

Voyez le détail de ces journées dans la suite de l’article.

Samedi 22 septembre

Le programme des présentations actuellement prévues pour le jour principal :

VLC 4.0: what was planned, what is being done, and what we will finally get! VR!

Toutes les évolutions prévues et déjà achevées pour la nouvelle mouture de VLC.
Si vous avez visité notre stand au FOSDEM, vous avez peut être déjà testé la VR.

x265: an update

L’encodeur open source HEVC par MulticoreWare.

AV1: the final talk

Le codec haute performance vraiment libre, enfin finalisé, avec son encodeur.

Dav1d: a fast new AV1 decoder

Le seul décodeur existant (libaom) n’étant pas vraiment utilisable en temps réel,
Dav1d est un projet visant à fournir un vrai décodeur performant.

FFv2: A technical talk about FFv2, and directions for the future

Présentation du nouveau codec sans pertes de FFmpeg.

Dimanche 23 septembre Principalement des « lightning talks »

Notez que l’intégralité de la conférence se déroulera en anglais et souvent avec un niveau technique soutenu.

Combien ? Le tarif d’inscription est fixé au montant de la licence de VLC.

Pour des raisons évidentes d’organisation et d’accès à un bâtiment sécurisé, ne vous inscrivez que si vous êtes vraiment certain de venir.

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

./play.it 2.10 : Debian, Gentoo et jeux vidéo

22 août, 2018 - 12:41

Il y a maintenant un peu plus de cinq mois, nous vous présentions dans une dépêche LinuxFr.org « ./play.it », un logiciel permettant d’installer facilement sur différentes distributions GNU/Linux toute une collection de jeux vidéos.

En cinq mois, il s’est passé beaucoup de choses au sein de ce projet, et c’est ce dont nous allons vous parler au sein de cette dépêche.

Sommaire Rappel des faits

Ceux qui ont (re)lu la première dépêche au sujet de ./play.it ne vont rien apprendre de neuf ici, et sont invités à se rendre directement à la suite. Pour les autres, nous allons résumer très rapidement ce dont il est question ici.

./play.it consiste en une collection de scripts se basant tous sur une bibliothèque commune. Chacun de ces scripts est dédié à un jeu en particulier et accepte un ou plusieurs installateurs en entrée, de formats divers et variés (installateurs natifs MojoSetup, installateurs pour Windows InnoSetup, archives .tar.gz ou .zip, etc.). L’installateur donné sera traité par un processus qu’on peut résumer en trois points majeurs :

  1. extraction des données du jeu depuis le fichier d’origine ;
  2. organisation des fichiers extraits dans le respect du FHS ;
  3. construction de paquets à destination d’une des distributions gérées.

On aboutit donc à un ou des paquets prêts à être mangés par votre gestionnaire de paquets préféré.

Sont gérés, bien sûr, des jeux natifs, mais aussi des jeux originellement prévus pour d’autres systèmes d’exploitation grâce à des outils comme WINE, DOSBox ou ScummVM. Si des manipulations spécifiques sont nécessaires au fonctionnement optimal du jeu, celles‐ci seront réalisées automatiquement par le script ./play.it.

Pour résumer en quelques mots, ./play.it est donc un système permettant d’installer très facilement toute une collection de jeux commerciaux sur des distributions GNU/Linux, en les intégrant au maximum au reste du système. Un jeu installé par ./play.it devrait être presque indiscernable d’un jeu installé depuis les dépôts officiels de votre distribution.

Évolutions récentes

La première dépêche au sujet de ./play.it sur LinuxFr.org correspond grosso‐modo à la sortie de la version 2.6. Aujourd’hui, nous en sommes à la version 2.10, et pas mal de changements sont passés par là.

Pour ceux que ça intéresse, le journal des modifications complet (en anglais) se trouve sur framagit.org.

Mais comme ce n’est pas une lecture particulièrement passionnante, voici plutôt une liste de quelques évolutions majeures du projet depuis la dernière dépêche.

Des scripts plus simples à écrire

Un des objectifs de ./play.it est de permettre à n’importe qui, même sans connaissances préalables en programmation, d’écrire des scripts pour ses jeux favoris. La simplicité d’accès de ces scripts est donc primordiale, et c’est un point que nous cherchons à améliorer à chaque nouvelle version.

Quelques améliorations notables ont eu lieu dans ce sens depuis la version 2.6 :

  • il n’est plus nécessaire de lister explicitement les archives gérées par le script, si les détails de celles‐ci suivent certaines conventions de nommage la liste pourra être générée automatiquement ;
  • de la même manière, la liste des icônes associées à une application peut, elle aussi, être déduite dans certains cas ;
  • dans le cas des installateurs en plusieurs parties, la présence de toutes les parties sera testée automatiquement (il fallait précédemment faire explicitement appel à certaines fonctions pour chaque partie de l’installateur) ;
  • tout le code relatif aux icônes a été amélioré, et il n’est entre autres plus nécessaire de lister explicitement la liste des résolutions d’icônes fournies. (en contrepartie, tous les scripts gérant des icônes dépendent maintenant d’ImageMagick).
Une méthode d’installation améliorée

Il était déjà possible d’installer ./play.it dans le répertoire personnel d’un utilisateur pour pouvoir l’utiliser plus facilement. Cette installation se fait dorénavant dans des répertoires système par défaut, et les chemins d’installation sont configurables.

En plus de la bibliothèque et des scripts, une page de manuel est elle aussi installée.

Des jeux WINE qui savent rester à leur place

Les utilisateurs de WINE qui installent directement leurs jeux via WINE ou passent par des solutions comme PlayOnLinux ont l’habitude de voir leur répertoire personnel pollué par une collection hétéroclite de répertoires stockant des sauvegardes ou autres fichiers de configuration.

./play.it évite désormais cette nuisance en forçant les jeux WINE à stocker ces fichiers dans des répertoires définis ($XDG_DATA_HOME pour les sauvegardes, $XDG_CONFIG_HOME pour les configurations).

Une foultitude de corrections de bogues

Et bien sûr tout un tas de correction de bogues, en bonne partie grâce aux rapports de nos utilisateurs. Nous sommes généralement réactifs sur ces questions, donc n’hésitez pas à nous signaler sur notre système de suivi de bogues tout comportement qui vous paraît erroné.

La plupart des rapports de bogues sont faits en anglais, mais si vous n’êtes pas à l’aise avec cette langue, vous pouvez aussi nous en envoyer en français : l’un de nous se chargera de le traduire pour nos contributeurs non francophones.

Inclusion aux dépôts Debian

Phil Morrell (emorrp1) avait déjà apporté quelques contributions à ./play.it dans les versions précédentes. Ce que nous ne savions pas, c’est qu’il s’agissait déjà à ce moment d’un contributeur Debian et, depuis fin juillet, il a obtenu le statut de mainteneur Debian. C’est par exemple lui qui maintient au sein de Debian les paquets pour Scorched 3D et CorsixTH.

Il s’est donc proposé de maintenir un paquet Debian pour ./play.it au sein des dépôts officiels (section contrib, vu qu’on se concentre sur des jeux non libres) et, grâce à lui, ./play.it est depuis sa version 2.9.0 empaqueté au sein de Debian et de certaines dérivées comme Ubuntu. C’est entre autres grâce à son travail que le processus d’installation de ./play.it a été simplifié et amélioré, et qu’une ébauche de documentation est en travaux.

Vous pouvez voir où en est la propagation de ./play.it au sein des dépôts de nos distributions sur la page suivante : play.it package versions - Repology.

Gestion (expérimentale) de Gentoo

Un autre contributeur majeur au projet sur ces derniers mois est BetaRays, qui travaille activement depuis début juin à ajouter au sein de ./play.it la possibilité de l’utiliser pour installer des jeux sur Gentoo.

Actuellement la gestion de Gentoo est encore expérimentale, mais déjà fonctionnelle. En revanche, nous manquons cruellement de testeurs pour pouvoir la peaufiner avant de l’ajouter de manière « officielle » aux distributions gérées.

Si vous utilisez Gentoo et que vous avez envie de donner un coup de main sur les tests, ou sur le développement, vous pouvez nous rejoindre sur IRC (serveur Freenode, salon #play.it), nous contacter par courriel (une adresse de contact se trouve dans chaque script) ou simplement vous signaler en commentaire de cette dépêche. Quelqu’un de notre équipe vous guidera alors pour installer une version de ./play.it incluant cette gestion de Gentoo pour que vous puissiez nous aider à traquer les bogues et les points méritant d’être améliorés.

Nouveaux jeux gérés

Un des points sur lesquels nous ne nous arrêtons jamais de bûcher est l’ajout de nouveaux jeux à la collection de ceux gérés par ./play.it. C’est à la fois ce qui fait la visibilité du projet, et aussi ce qui amuse le plus une bonne partie de nos contributeurs ; pas étonnant donc que ce soit pour nous toujours une tâche de premier plan !

Voici donc la liste (presque) complète de ceux qui ont rejoint le catalogue depuis la dernière dépêche :

Si malgré tous ces ajouts votre jeu préféré manque encore à l’appel, nous avons depuis peu un dépôt sur Framagit spécialement dédié aux demandes de nouveaux jeux : https://framagit.org/vv221/play.it-games.

Appel à contributions

Comme vous pouvez le voir, ./play.it reste un projet dynamique au sein duquel de nouvelles fonctionnalités sont intégrées tous les mois, et la bibliothèque de jeux gérés croît toutes les semaines. Tout ça n’est possible que grâce au travail de tous nos contributeurs, qui tous participent sur leur temps libre par passion des jeux vidéos et du logiciel libre.

Vous pouvez vous aussi rejoindre notre équipe à tout moment, que ce soit pour une longue durée ou pour des contributions ponctuelles. Si votre distribution n’est pas encore gérée, si votre jeu favori ne fait pas encore partie de la bibliothèque, la meilleure façon de corriger ce problème est de venir nous voir et de développer vous‐même ce qui manque à ./play.it. Nous sommes toujours heureux de former de nouveaux contributeurs et de discuter autour de nouvelles propositions.

Nous attendons avec impatience vos suggestions, requêtes, propositions et rapports de bogues !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! »

21 août, 2018 - 08:58

L’équipe IMAGE du GREYC est heureuse de pouvoir fêter avec vous les dix années d’existence du logiciel G’MIC, son cadriciel libre (sous licence CeCILL), générique et extensible pour le traitement des images.
Le GREYC est un laboratoire de recherche publique en sciences du Numérique, situé à Caen en Normandie, et chapeauté par trois tutelles : le CNRS (UMR 6072), l’Université de Caen et l’ENSICAEN.


  G’MIC-Qt, l’interface utilisateur principale du projet libre G’MIC.

Cet anniversaire décennal nous donne l’occasion rêvée, d’une part, d’annoncer la sortie d’une nouvelle version de ce logiciel libre (numérotée 2.3.4), et d’autre part, de partager avec vous (comme à notre habitude) un résumé des dernières fonctionnalités notables ajoutées depuis la dernière dépêche sur G’MIC, publiée sur LinuxFr.org en février 2018.

Sommaire

N. D. A. : Cliquez sur les images de la dépêche pour en visualiser des versions à meilleure résolution.

1. Retour sur dix années de développement

G’MIC est un logiciel multi‐plate‐forme (GNU/Linux, macOS, Windows…) fournissant différentes interfaces utilisateur pour la manipulation de données image génériques, à savoir des images ou des séquences d’images hyperspectrales 2D ou 3D à valeurs flottantes (incluant donc les images couleur « classiques »). Plus de mille opérateurs différents de traitement d’images sont inclus, nombre extensible à l’envi puisque les utilisateurs peuvent ajouter leurs propres fonctionnalités via l’utilisation d’un langage de script intégré.

C’est fin juillet 2008, que les premières lignes de G’MIC sont rédigées (en C++).
À l’époque, j’étais le principal développeur impliqué dans CImg, une bibliothèque C++ open source légère pour le traitement d’images, et je réalisais le constat suivant :

  • l’objectif initial de CImg, qui était de proposer une bibliothèque « minimale » de fonctionnalités pour aider les développeurs C++ à élaborer des algorithmes autour du traitement d’images, était globalement atteint :
    • la plupart des algorithmes que je considérais comme « essentiels » en traitement d’images y étaient intégrés,
    • CImg était initialement conçue pour rester légère, et je ne souhaitais donc pas y inclure ad vitam æternam de nouveaux algorithmes, qui seraient trop lourds ou trop spécifiques et qui trahiraient le concept initial de la bibliothèque ;
  • cette satisfaction faisait néanmoins place à une certaine déception ; quel dommage de n’avoir pu toucher qu’un public finalement assez restreint, possédant à la fois des connaissances en C++ et en traitement d’images ! Une des évolutions naturelles du projet, consistant à créer des bibliothèques de liaison (bindings) de CImg pour d’autres langages de programmation, ne m’ouvrait pas de perspectives très réjouissantes, du point de vue de l’intérêt que j’y trouvais en développement informatique ; sans compter que ces bindings potentiels ne concernerait, là encore, qu’un public ayant une expertise en développement.

Mon envie prenait donc progressivement forme : il fallait proposer un moyen d’utiliser les fonctionnalités de traitement d’images de CImg pour les non‐programmeurs. Et pourquoi pas, dans un premier temps, en élaborant un outil utilisable en ligne de commande (à la façon du fameux convert d’ImageMagick) ? Une première tentative, en juin 2008 (inrcast, qui avait été présentée dans un journal LinuxFr), se révéla infructueuse mais me permit de mieux cerner les spécificités que se devait de posséder ce genre d’outils, pour traiter confortablement des images en ligne de commande.
Il m’apparut en particulier que la concision et la cohérence de la syntaxe commandant l’outil devaient être les deux piliers principaux sur lesquels il fallait se reposer. Ces aspects sont ceux qui m’ont demandé le plus d’efforts en recherche et développement (les fonctionnalités de traitement d’images proprement dites étant déjà implémentées dans CImg). En fin de compte, cela m’amènera bien plus loin que ce qui était prévu initialement, puisque G’MIC se dotera successivement d’un interpréteur de son propre langage de script, puis d’un compilateur à la volée (JIT) pour l’évaluation d’expressions mathématiques et d’algorithmes de traitement d’images travaillant au niveau pixel.

Fin juillet 2008, je me mettais donc au travail avec les idées (presque) claires, et étais heureux d’annoncer ici même, quelques jours plus tard, la sortie d’une première ébauche de G’MIC. Le projet était officiellement en marche !

  Fig. 1.1 : Logo du projet G’MIC, cadriciel libre pour le traitement d’images, et sa mignonne petite mascotte « Gmicky » (illustrée par David Revoy).

Quelques mois plus tard, en janvier 2009, enrichi par mon expérience précédente de développement du logiciel GREYCstoration (outil libre pour le débruitage et l’interpolation non linéaire d’images, dont un greffon existait pour GIMP), et dans l’espoir de toucher un public encore plus large, je diffusais une version de G’MIC se déclinant sous forme d’un greffon GTK pour GIMP.
Cette étape s’est avérée déterminante pour le projet G’MIC, le faisant passer de hautement confidentiel à doucement populaire :), comme l’illustre le saut significatif visible dans les statistiques de téléchargements mensuels de l’époque, présentées ci‐dessous (le projet était alors hébergé sur Sourceforge).

  Fig. 1.2 : Statistiques de téléchargement mensuels de G’MIC, entre juillet 2008 et mai 2009 (arrivée du greffon pour GIMP en janvier 2009).

Cet intérêt soudain pour le greffon de la part d’utilisateurs différents de GIMP (photographes, illustrateurs et autres artistes en tout genre…) fut en effet une vraie rampe de lancement pour le projet, avec l’apparition rapide de contributions et suggestions extérieures diverses et variées (pour le code, la gestion des forums, des pages Web, l’écriture de tutoriels, la réalisation de vidéos…). L’effet communautaire bénéfique du logiciel libre, souvent idéalisé, survenait finalement assez rapidement ! Avec aussi pour conséquence d’amener certains utilisateurs‐développeurs à s’intéresser plus en détails au fonctionnement de l’interface originelle en ligne de commande et à son langage de script associé (qui n’intéressait pas grand monde jusque‐là, il faut bien l’avouer !). De là, plusieurs d’entre eux franchirent le pas et commencèrent à élaborer et implémenter de nouveaux filtres de traitement d’images en langage G’MIC, intégrés progressivement au greffon pour GIMP (aujourd’hui, ces contributions représentent quasiment la moitié des filtres disponibles dans le greffon).

En parallèle, les apports importants et répétés de Sébastien Fourey, collègue de l'équipe IMAGE du GREYC (et développeur C++ chevronné s'il en est) ont permis d'améliorer significativement le confort d'utilisation de G'MIC. Sébastien est en effet à l'origine du développement des interfaces graphiques principales du projet, à savoir :

  • le service Web G’MIC Online (qui a plus tard été réorganisé par le service « développement » du GREYC) ;
  • Le logiciel libre ZArt, une interface graphique, basé sur la bibliothèque Qt, pour l’application de filtres G’MIC sur des séquences vidéos (provenant de fichiers ou de flux de caméras numériques) ;
  • et surtout, Sébastien s’est attaqué, fin 2016, à la réécriture complète du greffon G’MIC pour  GIMP sous une forme plus générique, dénommée G’MIC-Qt ; ce composant, basé également sur la bibliothèque Qt (comme son nom l’indique), se présente sous la forme d’un greffon unique qui fonctionne de manière équivalente sous GIMP et Krita, deux des logiciels libres de référence pour la retouche photographique et la peinture numérique. G’MIC-Qt a aujourd’hui complètement supplanté le greffon GTK d’origine grâce à ses nombreuses fonctionnalités : moteur de recherche de filtres intégré, meilleure prévisualisation, interactivité supérieure, etc. C’est aujourd’hui l’interface la plus aboutie et la plus utilisée du projet G’MIC, et nous espérons d’ailleurs pouvoir la décliner dans le futur pour d’autres logiciels hôtes (contactez‐nous si vous êtes intéressés par ce sujet !).

  Fig. 1.3 : Différentes interfaces graphiques du projet G’MIC, développées par Sébastien Fourey : G’MIC-Qt, G’MIC Online et ZArt.

L’idée de cette dépêche n’étant pas de rentrer trop en détails dans l’historique du projet, affirmons simplement que l’on n’a pas vraiment eu le temps de s’ennuyer ces dix dernières années !
Aujourd’hui, Sébastien et moi‐même sommes les deux mainteneurs principaux du projet G’MIC (Sébastien, majoritairement pour ce qui concerne les aspects « interface », et moi‐même pour le développement et l’amélioration des filtres et du cœur de calcul), ceci, en complément de notre activité professionnelle principale (la recherche, l’enseignement et l’encadrement).

Avouons‐le, gérer un projet libre comme G’MIC prend un temps considérable, malgré sa taille modeste (≈ 120 000 lignes de code). Mais l’objectif de départ a été atteint : des milliers d’utilisateurs non‐programmeurs ont l’occasion d’utiliser librement et aisément nos algorithmes de traitement d’images, et ce, dans de nombreux domaines différents : retouche photographique, illustration et peinture numérique, traitement vidéo, illustration scientifique, génération procédurale, glitch art… La barre des 3,5 millions de téléchargements totaux a été dépassée l’an dernier, avec une moyenne actuelle d’environ 400 téléchargements journaliers effectués depuis le site officiel (chiffres en baisse constante depuis quelques années car G’MIC est de plus en plus téléchargé et installé via des sources alternatives extérieures).
Il est parfois difficile de garder un rythme soutenu de développement et la motivation qui doit aller avec, mais on s’accroche, en repensant aux utilisateurs heureux qui partagent de temps à autre leur enthousiasme pour ce projet !

On ne peut évidemment pas nommer tous les particuliers, contributeurs à G’MIC, que l’on souhaiterait remercier, et avec qui on s’est régalé à échanger durant ces dix années, mais le cœur y est ! Remercions également le laboratoire GREYC et l’institut INS2I du CNRS qui affichent un fort soutien à ce projet libre. Un grand merci également à l’équipe de LinuxFr.org qui n’a pas rechigné à relire et publier nos propositions régulières de dépêches sur G’MIC ;).

Mais cessons de ressasser de vieux souvenirs et passons maintenant aux choses sérieuses : les nouveautés apparues depuis la dernière version majeure 2.2 !

2. Illumination automatique de dessins colorisés en aplats

G’MIC s’est récemment doté d’un filtre assez étonnant, nommé « Illuminate 2D shape », dont l’objectif est d’ajouter automatiquement des zones d’illumination et des ombres propres sur des dessins 2D colorisés en aplats, pour leur donner un aspect 3D.

Dans un premier temps, l’utilisateur fournit un objet à illuminer, sous la forme d’une image sur fond transparent (typiquement un dessin de personnage, ou d’animal). En analysant la forme et le contenu de l’image, G’MIC tente alors d’en déduire une carte d’élévations 3D concordante (« bumpmap »). La carte d’élévations obtenue est évidemment non exacte, puisqu’un dessin 2D colorisé en aplats ne contient pas d’informations franchement explicites sur sa structure 3D associée ! À partir des élévations 3D estimées, il est aisé d’en déduire une carte de normales (« normalmap ») qui est utilisée dans un second temps pour générer un calque d’illumination associé au dessin (suivant un modèle d’ombrage de Phong).

  Fig. 2.1 : Le filtre « Illuminate 2D shape » de G’MIC en action, pour ombrer un dessin de scarabée (résultat d’ombrage à droite).

Ce nouveau filtre est très flexible et permet à l’utilisateur d’avoir un contrôle assez fin sur les paramètres d’éclairage (position et type de rendu de la source lumineuse), et d’estimation des élévations 3D. Par ailleurs, le filtre laisse à l’artiste le loisir de retravailler le calque d’illumination généré, ou même directement les cartes d’élévations et de normales 3D estimées. La figure ci‐dessous illustre le processus dans son ensemble : à partir de l’image de scarabée colorisé en aplats (en haut à gauche), le filtre estime de manière complètement automatique une carte de normales 3D associée (en haut à droite), ce qui lui permet de générer des rendus d’illumination du dessin (ligne du bas, avec deux styles de rendus différents : lisse et quantifié).

  Fig. 2.2 : Le fonctionnement du filtre « Illuminate 2D shape » de G’MIC passe par l’estimation d’une carte de normales 3D pour générer l’illumination automatique d’un dessin.

Malgré la difficulté inhérente au problème de conversion d’une image 2D en informations d’élévations 3D, l’algorithme utilisé s’avère étonnamment efficace dans pas mal de cas, l’estimation de la carte d’élévations 3D obtenue étant suffisamment cohérente pour générer automatiquement des illuminations de dessins 2D plausibles, comme illustré par les deux exemples ci-dessous, obtenus en quelques clics seulement !


  Fig. 2.3 : Deux exemples d’illuminations complètement automatiques de dessins 2D, générés par G’MIC.

Il arrive, bien sûr, que la carte d’élévations 3D estimée ne corresponde pas tout à fait à ce que l’on pourrait souhaiter. Qu’à cela ne tienne, le filtre permet à l’utilisateur de fournir des « guides », sous la forme d’un calque additionnel composé de traits colorés, donnant des informations plus précises à l’algorithme sur la structure du dessin à analyser. La figure ci‐dessous illustre l’utilité de ces guides pour un exemple d’illumination d’un dessin d’une main (en haut à gauche) : l’illumination obtenue de manière complètement automatique (en haut à droite) ne prend pas en compte les informations de lignes de la main. Inclure ces quelques lignes dans un calque additionnel de « guides » (en rouge, en bas à gauche) permet d’aider l’algorithme à illuminer le dessin de manière plus satisfaisante.

  Fig. 2.4 : Utilisation d’un calque de « guides » pour améliorer le rendu d’illumination automatique généré par G’MIC.

Si l’on analyse plus précisément les différences obtenues entre les cartes d’élévations 3D estimées avec et sans « guides » (illustrées ci‐dessous sous forme d’objets 3D symétrisés), il n’y a pas photo : on passe d’une grosse moufle boudinée à une estimation 3D de main nettement plus détaillée !

  Fig. 2.5 : Élévations 3D estimées pour le dessin précédent de la main, avec et sans utilisation de « guides ».

Notons pour finir que ce filtre dispose également d’un mode de prévisualisation interactif, permettant à l’utilisateur de faire bouger la source lumineuse (à la souris) et d’avoir un aperçu du dessin illuminé en temps réel. En modifiant les paramètres de position de la source lumineuse, il est ainsi possible d’obtenir le type d’animations ci‐dessous en très peu de temps, qui donne une idée assez précise de la structure 3D estimée par l’algorithme à partir du dessin d’origine.
  Fig. 2.6 : Modification de la position de la source lumineuse et rendus d’illumination associés, calculés de manière automatique par G’MIC.

Une vidéo montrant les différentes possibilités d’édition de l’illumination permises par ce filtre est visible sur YouTube. Espérons que cette nouvelle fonctionnalité de G’MIC permette aux artistes d’accélérer l’étape d’illumination et d’ombrage de leurs futurs dessins !

3. Projection stéréographique

Dans un tout autre genre, nous avons également ajouté à G’MIC un filtre implémentant la projection stéréographique, très précisément nommé « Stereographic projection ». Ce type de projection cartographique permet de projeter des données images définies sur une sphère, sur un plan. Il faut savoir que c’est la projection usuelle utilisée pour générer des images de « mini‐planètes » à partir de panoramas équirectangulaires, comme celui illustré sur la figure ci‐dessous.

  Fig. 3.1 : Exemple de panorama équirectangulaire (réalisé par Alexandre Duret‐Lutz).

Si, sur ce panorama, on lance le greffon G’MIC et que l’on sélectionne le filtre « Stereographic projection », on obtient :
  Fig. 3.2 : Le filtre « Stereographic projection » de G’MIC en action dans le greffon pour GIMP ou Krita.

Le filtre permet des réglages précis du centre de projection, de l’angle de rotation et du rayon de la sphère considérée, tout ça de manière interactive directement sur la fenêtre de prévisualisation (nous y reviendrons par la suite). En quelques clics, et après application du filtre, nous obtenons la « mini‐planète » désirée :

  Fig. 3.3 : « Mini‐planète » obtenue après projection stéréographique.

Il est d’ailleurs cocasse de constater qu’en inversant simplement l’axe vertical des images, on transforme une « mini‐planète » en un « maxi‐tunnel » !

  Fig. 3.4 : « Maxi‐tunnel » obtenu par inversion de l’axe vertical puis projection stéréographique.

Là encore, nous avons réalisé cette petite vidéo qui montre ce filtre en conditions réelles d’utilisation. À noter que G’MIC possédait déjà un filtre similaire (dénommé « Sphere »), qui pouvait être utilisé pour la création de « mini‐planètes », mais avec un type de projection moins bien adapté que la projection stéréographique, qu’il est maintenant possible d’utiliser.

4. Toujours plus de possibilités pour la manipulation des couleurs

Triturer les couleurs des images est une occupation récurrente chez les photographes et les illustrateurs, et G’MIC possèdait déjà plusieurs dizaines de filtres destinés à cette unique activité, regroupés dans une catégorie dédiée (à savoir « Colors/ », pour faire original !). Cette catégorie s’étoffe encore, avec deux nouveaux filtres fraîchement apparus.

4.1. Le filtre « CLUT from after‐before layers »

Le filtre « **CLUT from after‐before layers_ » cherche à modéliser la transformation colorimétrique qui a été effectuée entre deux images (que l’on possède). Supposons par exemple que nous ayons la paire d’images suivante :
  Fig. 4.1 : Paire d’images où une transformation colorimétrique inconnue a été appliquée sur l’image du haut, pour obtenir celle du bas.

Problème : On ne se rappelle plus du tout comment on a fait pour passer de l’image originale à l’image modifiée, mais on voudrait absolument ré‐appliquer le même processus sur une autre image. Eh bien, plus de soucis, appelons G’MIC à la rescousse ! Le filtre en question va chercher à modéliser au mieux la modification des couleurs sous la forme d’une HaldCLUT, qui se trouve être une façon classique de représenter une transformation colorimétrique quelconque.

  Fig. 4.2 : Le filtre modélise la transformation colorimétrique entre deux images sous forme d’une HaldCLUT.

La HaldCLUT générée par le filtre va pouvoir être sauvée et ré‐appliquée sur d’autres images, avec la propriété désirée que l’application de cette HaldCLUT sur l’image originale redonne bien l’image modèle cible dont on s’est servi pour que le filtre apprenne la transformation couleur produite.
À partir de là, nous sommes capables d’appliquer une modification de couleurs équivalente, sur n’importe quelle autre image :
  Fig. 4.3 : La transformation colorimétrique estimée sous forme de HaldCLUT est ré‐appliquée sur une autre image.

Ce filtre permet donc in fine de créer des HaldCLUT « par l’exemple », et pourrait donc intéresser de nombreux photographes (notamment ceux qui diffusent des compilations de fichiers HaldCLUT, librement ou non !).

4.2. Filtre « Mixer [PCA] »

Un deuxième filtre de manipulation de couleurs, nommé « Mixer [PCA] » a été aussi récemment intégré à G’MIC. Il agit comme un classique mixeur de canaux couleurs, mais plutôt que de travailler dans un espace couleur prédéfini (comme sRGB, HSV, Lab…), il agit sur l’espace couleur « naturel » de l’image d’entrée, obtenue par analyse en composante principale (ACP) de ses couleurs RVB. Ainsi à chaque image sera associé un espace couleur différent.
Par exemple, si nous prenons l’image « lion » ci‐dessous, et que l’on regarde la distribution de ses couleurs dans le cube RVB (image de droite), on s’aperçoit que l’axe principal de variation des couleurs est défini par une droite allant du orange foncé au beige clair (axe symbolisé par la flèche rouge sur la figure).

  Fig. 4.4 : Distribution des couleurs de l’image « lion » dans le cube RVB, et axes principaux associés (colorisés en rouge, vert et bleu).

L’axe de variation secondaire quant à lui (flèche verte) va du bleu jusqu’à l’orange, et l’axe tertiaire (flèche bleue) du vert au rose. Ce sont ces axes de variations (plutôt que les axes RVB) qui vont donc définir la base de couleurs utilisée dans ce filtre de mixage de canaux.

  Fig. 4.5 : Le filtre « Mixer [PCA] » est un mixeur de canaux agissant sur les axes de variations de couleurs « naturels » de l’image.

Il serait malhonnête d’affirmer qu’il soit toujours meilleur de considérer la base couleur obtenue par ACP pour le mixage des canaux, et ce nouveau filtre n’a évidemment pas vocation à être le mixeur « ultime » qui remplacerait tous les autres. Il a simplement le mérite d’exister et de proposer une alternative aux outils usuels de mixage de canaux couleur, alternative dont les résultats se sont avérés effectivement intéressants sur plusieurs images de tests utilisées lors du développement de ce filtre. Cela ne coûte rien d’essayer en tout cas…

5. Méli‐mélo de filtres

Cette section présente pêle‐mêle quelques autres nouveaux filtres et améliorations diverses qui ont été intégrés récemment à G’MIC et qui méritent qu’on les mentionne, sans s’y attarder outre mesure.

5.1. Le filtre « Local processing »

Ce filtre permet d’appliquer un processus de normalisation ou d’égalisation de couleurs sur des voisinages locaux d’image (avec éventuellement du recouvrement entre voisinages). C’est un filtre supplémentaire permettant de faire ressortir des détails dans des photographies initialement surexposées ou sous‐exposées, mais qui peut parfois créer des « halos » disgracieux.

  Fig. 5.1 : Le filtre « Local processing » permet de rehausser les détails dans des photographies sur ou sous‐exposées.

5.2. Le filtre « Blend [standard] »

Vous trouvez que vous n’avez pas assez de modes de fusion de calques à votre disposition dans GIMP ou Krita ? Vous rêvez de pouvoir définir votre propre formule de fusion ? Alors le filtre « Blend [standard] » est fait pour vous ! Ce filtre, déjà existant auparavant, s’enrichit de la fonctionnalité « Custom formula » qui permet à l’utilisateur de spécifier sa propre formule mathématique de fusion de calques. Toutes les fantaisies deviennent possibles !

  Fig. 5.2 : Le filtre « Blend [standard] » permet maintenant de définir ses propres formules mathématiques de fusion de calques.

5.3. Le filtre « Sketch »

Signalons aussi la ré‐implémentation complète du sympathique filtre « Sketch », qui existait depuis plusieurs années, mais qui pouvait s’avérer un peu lent sur de grosses images. La nouvelle implémentation est beaucoup plus rapide, tirant notamment parti du calcul multicœur quand c’est possible.

  Fig. 5.3 : Le filtre « Sketch » a été réimplémenté et exploite maintenant tous les cœurs de calcul disponibles.

5.4. Le filtre « Mandelbrot - Julia sets »

Un gros travail de ré‐implémentation a été également réalisé sur le filtre « Mandelbrot - Julia sets », puisque l’interface de navigation a été entièrement repensée, rendant l’exploration de l’ensemble de Mandelbrot bien plus confortable (comme l’illustre cettevidéo). De nouvelle options pour le choix des couleurs sont également apparues.

  Fig. 5.4 : Le filtre « Mandelbrot - Julia sets » et sa nouvelle interface de navigation dans l’espace complexe.

5.5. Le filtre « Polygonize [Delaunay] »

Le filtre « Polygonize [Delaunay] » qui génère des rendus polygonisées d’images couleurs se dote d’un nouveau mode de rendu, utilisant des couleurs interpolées linéairement dans les triangles de Delaunay produits.

  Fig. 5.5 : Les différents modes de rendu du filtre « Polygonize [Delaunay] ».

6. Autres faits marquants du projet 6.1. Améliorations de l’interface du greffon

Bien sûr, les nouveautés dans G’MIC ne concernent pas seulement les filtres de traitement d’images proprement dits ! Un travail considérable a été par exemple réalisé sur l’interface graphique du greffon G’MIC-Qt.

Les filtres du greffon ont désormais la possibilité de spécifier un nouveau type de paramètre point(), qui se matérialise sous la forme d’un petit disque coloré que l’on peut manipuler directement à la souris au‐dessus de la fenêtre de prévisualisation. En pratique, cela permet de rendre cette fenêtre de prévisualisation interactive, et ce n’est pas rien ! De nombreux filtres utilisent maintenant cette capacité, ce qui les rend beaucoup plus agréables et intuitifs à utiliser (voir cette vidéo pour quelques exemples). L’animation ci‐dessous montre par exemple comment ces points interactifs sont utilisés dans le nouveau filtre « Stereographic projection », que nous avons décrit précédemment.

  Fig. 6.1 : La fenêtre de prévisualisation du greffon G’MIC-Qt s’enrichit de nouvelles possibilités d’interactions pour l’utilisateur.

L’introduction de cette fonctionnalité a de ce fait permis d’améliorer les modes de division de prévisualisation (« split preview »), utilisés par un grand nombre de filtres pour afficher côte à côte les images « avant / après » lors de la prévisualisation d’un filtre dans le greffon. Il est maintenant possible de déplacer la zone frontière des images « avant / après », comme illustré par l’animation ci‐dessous. Deux nouveaux modes de division, en damier, ont d’ailleurs été ajoutés à cette occasion.

  Fig. 6.2 : Les modes de division de la prévisualisation possèdent maintenant une frontière « avant / après » déplaçable.

Plein d’autres petites améliorations ont été faites dans le code du greffon : une prise en charge du dernier GIMP 2.10, de la version Qt 5.11, une meilleure gestion des messages d’erreurs s’affichant dans la fenêtre de prévisualisation, un design général plus épuré, et tout un tas de petites choses par forcément visibles mais participant néanmoins au confort de l’utilisateur (un système de cache d’images pour la fenêtre de prévisualisation par exemple). Bref, que du bon !

6.2. Perfectionnement du cœur du logiciel

De nouvelles améliorations ont également été apportées dans les couches internes de G’MIC.

La « bibliothèque standard » du langage de script G’MIC évolue, avec l’apparition de nouvelles commandes pour le calcul des fonctions hyperboliques inverses (acosh, asinh et atanh), ainsi que de la commande tsp (travelling salesman problem) qui estime une solution « acceptable » au problème bien connu du voyageur de commerce, et ceci pour un nuage de points de dimension et de taille quelconque.

  Fig. 6.3 : Estimation du circuit le plus court entre plusieurs centaines de points 2D, par la commande tsp de G’MIC.

  Fig. 6.4 : Estimation du circuit le plus court entre plusieurs couleurs du cube RVB (en 3D donc), grâce à la commande tsp de G’MIC.

L’interface de démonstration, qui se lance lorsque l’on invoque gmic sans arguments à partir de la ligne de commande, a également été refaite en repartant de zéro.
  Fig. 6.5 : La nouvelle interface de démonstration de gmic, l’outil en ligne de commande de G’MIC.

Le compilateur JIT d’expressions mathématiques intégré n’est pas non plus en reste et s’enrichit de nouvelles fonctions permettant de tracer des polygones (fonction polygon()) ou des ellipses (fonction ellipse()) dans des images. Ces expressions mathématiques peuvent en réalité définir de véritables petits programmes (possédant des variables locales, des fonctions utilisateur et des structures de contrôle). On peut ainsi générer des images synthétiques facilement, avec de simples lignes de commande, comme le montrent les deux exemples ci‐dessous.

$ gmic 400,400,1,3 eval "for (k = 0, k<300, ++k, polygon(3,u([vector10(0),[w,h,w,h,w,h,0.5,255,255,255])))"

Résultat :
  Fig. 6.6 : Utilisation de la nouvelle fonction polygon() du compilateur à la volée de G’MIC, pour générer une image synthétique aléatoire.

$ gmic 400,400,1,3 eval "for (k=0, k<20, ++k, ellipse(w/2,h/2,w/2,w/8,k*360/20,0.1,255))"

Résultat :
  Fig. 6.7 : Utilisation de la nouvelle fonction ellipse() du compilateur à la volée de G’MIC, pour générer une image synthétique florale.

Notons également une meilleure gestion des valeurs NaN lors des calculs réalisés par le cœur du logiciel, ce qui permet à G’MIC d’avoir un comportement cohérent même lorsqu’on le compile avec l’optimisation -ffast-math. Ainsi, G’MIC est maintenant compilable sans soucis avec le niveau d’optimisation maximal -Ofast du compilateur g++, alors que nous étions restreints dans le passé à utiliser « seulement » -O3. L’amélioration en vitesse de calcul se fait clairement ressentir pour certains filtres !

6.3. Supports de diffusion

Pas mal de changements ont aussi eu lieu sur les supports de diffusion utilisés par le projet.

Tout d’abord, les pages Web du projet (qui en passant utilisent maintenant des connexions sécurisées HTTPS par défaut) s’enrichissent d’une nouvelle galerie d’images. Cette galerie montre à la fois des résultats d’application de différents opérateurs de traitement d’images disponibles dans G’MIC, mais aussi la façon de les reproduire (à partir de la ligne de commande). Notons d’ailleurs que ces pages de galerie sont générées automatiquement par un script G’MIC dédié à cette tâche, ce qui nous assure que la syntaxe donnée pour chaque exemple est exacte.

  Fig. 6.8 : La nouvelle page de galerie d’images du site Web de G‘MIC.

Cette galerie est découpée en plusieurs sections, suivant le type de traitements effectué (Artistique, Noir & blanc, Déformation, Filtrage, etc.). La dernière section « Code sample  » est personnellement celle que je trouve la plus amusante, puisqu’elle présente de petites séquences d’images (sous forme de GIF animés qui bouclent) entièrement générées par des scripts courts en langage G’MIC. Une façon un tout petit peu exotique d’utiliser G’MIC, mais qui montre son potentiel pour l’art génératif.

  

  Fig. 6.9 : Deux exemples d’animations GIF générées par des scripts en langage G’MIC, visibles dans la galerie d’images.

Et puis, nous avons déménagé le dépôt source git principal du projet vers Framagit, en gardant néanmoins un miroir synchronisé sur GitHub au même emplacement qu’auparavant (pour profiter en particulier du fait que de nombreux développeurs sont présents sur GitHub et peuvent plus facilement créer un dépôt divergent (fork) et nous faire des rapports de bogues sur cette plate‐forme).

7. Conclusions et perspectives

Voilà ! Notre tour des nouveautés (des six derniers mois d’activité) du projet G’MIC s’achève enfin.

Nous sommes heureux d’avoir pu vivre dix belles années d’émotions informatiques avec la naissance et l’évolution de ce projet libre, et de pouvoir partager à notre manière, avec tous les utilisateurs, des techniques de traitements d’images avancées. On espère surtout repartir de plus belle pour de nombreuses années ! Les soutiens se font de plus en plus présents autour de nous, donc on se dit que ça doit pouvoir se faire (à ce propos, si vous voulez contribuer au projet de quelque manière que ce soit, vous êtes les bienvenus !).
Notons que l’année prochaine, on fêtera également les vingt ans d’existence de CImg, la bibliothèque C++ de traitement d’images qui est directement à l’origine du projet G’MIC (et qui, elle, est née en novembre 1999, ça ne nous rajeunit pas ma bonne dame…). Preuve s’il en est que l’intérêt du logiciel libre, c’est qu’il s’inscrit dans la durée !

Et en attendant la prochaine dépêche sur G’MIC, n’hésitez pas à tester ce logiciel, à jouer et triturer vos images de la manière la plus libre et créative possible !

Télécharger ce contenu au format Epub

Commentaires : voir le flux atom ouvrir dans le navigateur

Développement Web frontend en Haskell, Elm et Purescript

19 août, 2018 - 21:42

Actuellement, le développement Web côté client (frontend) est très souvent réalisé en JavaScript ou dans des langages dérivés comme TypeScript. Il existe cependant d’autres outils intéressants, basés sur des langages de programmation fonctionnelle, qui permettent notamment d’éviter de nombreuses erreurs lors de l’exécution sur le navigateur.

L’objectif de cette dépêche est de rappeler quelques généralités sur le développement Web frontend, et de présenter les outils Elm, Purescript, Miso et Reflex, à partir d’un exemple d’application (galerie d’images fournie via une API Web).

Attention : ceci n’est pas une étude rigoureuse et avancée mais juste un petit retour de petite expérience.

Voir également le dépôt de code de l’exemple et une présentation en vidéo.

    Sommaire Généralités sur le web frontend Page web, application web, application native

    Historiquement, les pages web se contentaient d'afficher un contenu statique et de proposer des liens vers d'autres pages. Des éléments dynamiques sont ensuite progressivement apparus : animations, formulaires avec vérifications de saisies… si bien, qu'aujourd'hui, de nombreuses pages web sont de véritables interfaces utilisateurs, comparables aux logiciels classiques installés sur le système. On appelle ce genre de pages des applications web (exécutées par un navigateur web), à distinguer des applications natives (exécutées par le système d'exploitation).

    D'un point de vue utilisateur, les applications web et les applitions natives sont de plus en plus proches. Par exemple, on trouve des applition web de traitement de texte (frama-pad, google-docs) qui possèdent une bonne part des fonctionnalités de leurs équivalents natifs (libreoffice, msoffice).

    D'un point de vue développeur, les technologies utilisées sont historiquement très différentes. Les applications natives utilisent généralement des langages comme Java, C#, Swift et leurs frameworks associés. Les applications web utilisent les technologies issues du web HTML/CSS/JavaScript et dépendent quasi-systématiquement d'un accès réseau via des websockets, requêtes AJAX ou autres. Cependant, on note une convergence web/natif également à ce niveau, notamment avec l'apparition du framework Electron, qui permet d'utiliser des technologies web pour développer des applications natives. De même, des architectures logicielles comme le Modèle-Vue-Contrôleur, très courant en natif, a été repris dans de nombreux frameworks web.

    Les langages pour le web frontend

    Le langage des applis web est sans conteste le JavaScript. C'est un langage assez controversé mais qui a tout de même des avantages indéniables, surtout depuis les récentes normes (ES2015…) : flexibilité, expressivité, compilateurs Just-In-Time performants, intégration dans les navigateurs…

    Cependant, JavaScript permet facilement de faire des erreurs qui se produiront à l'exécution finale de l'application, les fameuses runtime errors. Pour éviter ces erreurs, on utilise souvent des outils comme des analyseurs statiques, debuggers ou tests unitaires. Une autre solution consiste à utiliser des frameworks (Angular, React…), des bibliothèques (Immutable, Redux…) voire des langages dérivés (TypeScript…) qui réduisent les sources d'erreurs possibles.

    Les langages fonctionnels pour le web frontend

    En fait, une bonne partie des solutions proposées pour rendre le développement en JavaScript plus robuste existe déjà naturellement dans des langages fonctionnels comme Haskell : immuabilité, fonctions pures, typage statique fort… Certains développeurs se sont donc naturellement inspirés des langages fonctionnels pour proposer des technos web frontend garantissant l'absence d'erreurs au runtime.

    L'idée de ces technos est de fournir un écosystème complet (langage fonctionnel, compilateur, bibliothèques…) adapté au web et produisant du code JavaScript exécutable par un navigateur. Parmi ces technos, on trouve Elm et Purescript, qui proposent des langages inspirés d'Haskell. Il est également possible d'utiliser directement le langage Haskell (éventuellement avec des bibliothèques comme Miso ou Reflex) et le compilateur Ghcjs pour produire du code JavaScript. Enfin, il existe des outils dans d'autres langages fonctionnels comme ClojureScript, Ocsigen (OCaml)…

    Les concepts de MVC, FRP, Virtual-DOM

    Ces trois concepts sont généralement au cœur des technos web frontend fonctionnelles. Ils sont également assez fréquents dans l'écosystème JavaScript classique.

    Le MVC (Model-View-Controler) est une architecture de code qui permet d'organiser une application en trois parties : le modèle (données « métier » à manipuler), la vue (affichage présenté à l'utilisateur) et le contrôleur (mise à jour de l'application en fonction des événements). Généralement, un MVC gére les événements de façon asynchrone et unidirectionnelle : les événements de la vue sont passés au contrôleur, qui modifie le modèle puis lance un rafraichissement de la vue…

    crédit : Ossi Hanhinen

    Le FRP (Functional Reactive Programming) est le principe de base des frameworks fonctionnels, sur lequel est implémenté le MVC. Le FRP permet d'implémenter le comportement dynamique des interfaces utilisateur. Il traite les flux d'événements au cours du temps et transmet ces flux entre les différents composants de l'application, le tout de façon fonctionnelle (sans effet de bord).

    crédit : André Staltz

    Enfin, un concept essentiel aux applications web est le DOM virtuel. Le DOM (Document-Object-Model) décrit la structure d'une page web, donc de l'application, dans le navigateur. Au cours de son exécution, une appli web a besoin de manipuler le DOM, pour récupérer des données ou pour modifier l'affichage. Or, manipuler directement le DOM est coûteux et résulte en une application peu réactive. Pour améliorer les performances, les frameworks web utilisent un système de cache, le DOM virtuel, qui regroupe des modifications et ainsi minimise les accès au DOM.

    crédit : Naukri Engineering

    Un exemple de base

    Pour illustrer les outils de web frontend fonctionnel, imaginons qu'on veuille implémenter une appli client-serveur de recherche et d'affichage d'images d'animaux. Le serveur fournit les images en HTTP à l'URL /img/<nom-du-fichier>. Il fournit également une API JSON à l'URL /api/animals <prefix> auquel il répond par la liste des animaux de sa base de données dont le type correspond au préfixe donné en paramètre. Chaque élément de la liste retournée contient le type de l'animal et le nom du fichier image (accessible via l'URL /img). Si aucun préfixe n'est donné, le serveur retourne la liste complète.

    L'appli web client à réaliser contient simplement une zone de texte permettant de saisir le préfixe. Il envoie des requêtes AJAX au serveur pour récupérer les animaux correspondant puis affiche les images correspondantes après les avoir également demandées au serveur.

    Ci-dessous une image du client implémenté en Purescript. L'ensemble du code est disponible sur ce dépôt git.

    Elm

    Elm est un environnement complet de développement web frontend fonctionnel. Il fournit un langage fonctionnel (inspiré d'Haskell mais en beaucoup plus simple), un compilateur Elm vers JavaScript et des bibliothèques. Elm est basé sur un DOM virtuel performant et permet de développer des applis web selon une architecture MVC.

    Ci-dessous une implémentation en Elm de l'application d'exemple (note pour les développeurs Elm : désolé pour le non-respect des règles de formatage de code Elm mais j'ai subi des pressions de la part de la ligue de protection des molettes de souris). Ce code suit un schéma MVC et un style fonctionnel très classique. On définit un type Animal, avec ses fonctions de décodage de données JSON, ainsi que le modèle de l'application, c'est-à-dire simplement la liste des Animal à afficher.

    Au niveau du contrôleur, le type Msg définit les événements qui peuvent se produire. L'événement MsgInput modélise une action de l'utilisateur sur la zone de texte et l'événement MsgAnimals un message du serveur transmettant les Animal en réponse à une requête à l'API. Ces événements sont gérés dans la fonction update : MsgInput ne change pas le modèle mais lance une requête à l'API via la fonction queryAnimals, MsgAnimals met à jour le modèle avec les données Animal reçues.

    Enfin, la fonction view indique comment construire la vue de l'appli, à partir du modèle : un titre h1, une zone de texte input puis un div pour chaque Animal du modèle.

    module Main exposing (..) import Html exposing (..) import Html.Attributes exposing (height, href, src, width) import Html.Events exposing (onClick, onInput) import Http import Json.Decode as JD main : Program Never Model Msg main = Html.program { init = init , view = view , update = update , subscriptions = subscriptions } -- Model type alias Animal = { animalType : String , animalImage : String } decodeAnimal : JD.Decoder Animal decodeAnimal = JD.map2 Animal (JD.field "animalType" JD.string) (JD.field "animalImage" JD.string) decodeAnimalList : JD.Decoder (List Animal) decodeAnimalList = JD.list decodeAnimal type alias Model = { modelAnimals : List Animal } init : ( Model, Cmd Msg ) init = ( Model [], queryAnimals "" ) -- Controler subscriptions : Model -> Sub Msg subscriptions _ = Sub.none type Msg = MsgInput String | MsgAnimals (Result Http.Error (List Animal)) update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of MsgInput animalType -> ( model, queryAnimals animalType ) MsgAnimals (Ok Model animals) -> ( Model animals, Cmd.none ) MsgAnimals (Err _) -> ( Model [], Cmd.none ) queryAnimals : String -> Cmd Msg queryAnimals txt = let url = "http://localhost:3000/api/animals/" ++ txt in Http.send MsgAnimals (Http.get url decodeAnimalList) -- View view model = span [] [ h1 [] [ text "Animals (Elm)" ] , p [] [ input [ onInput MsgInput ] [] ] , span [] (List.map (\a -> div [] [ p [] [ text a.animalType ] , img [ src ("http://localhost:3000/img/" ++ a.animalImage) , height 240 , width 320 ] [] ] ) model.modelAnimals ) ]

    Elm a l'avantage d'être particulièrement simple à utiliser. Les applis développées suivent toujours un MVC bien définis et les messages du compilateur sont particulièrement clairs. Le code JavaScript produit est léger et performant. Parmi les inconvénients, on peut noter que Elm est limité au schéma MVC qui, bien que très répandu, ne sera peut-être pas adapté à toutes les applications.

    Purescript

    Purescript est également un environnement complet (langage, compilateur, bibliothèques) mais plus général que Elm. En effet, son langage est plus proche d'Haskell et plus puissant (il supporte notamment les classes de type). De plus, Purescript propose différentes architecture de code, dont MVC. Enfin, Purescript peut être également utilisé pour le développement côté serveur.

    Ci-dessous une implémentation en Purescript de l’application d’exemple, utilisant la bibliothèque Halogen (FRP + DOM virtuel). Ce code est très proche du code Elm. Pour le modèle, on définit également un type Animals, avec les fonctions de décodage JSON, et un type Model. Pour le contrôleur, on définit un type Query qui permet de gérer la requête AJAX et sa réponse, via la fonction eval. Enfin, la vue suit le même schéma que l'implémentation en Elm.

    module Main where import Control.Monad.Aff (Aff) import Control.Monad.Eff (Eff) import Data.Argonaut ((.?), class DecodeJson, decodeJson, Json) import Data.Either (Either(..)) import Data.Maybe (Maybe(..)) import Data.Traversable (traverse) import Halogen as H import Halogen.Aff as HA import Halogen.HTML as HH import Halogen.HTML.Events as HE import Halogen.HTML.Properties as HP import Halogen.VDom.Driver (runUI) import Network.HTTP.Affjax as AX import Prelude main :: Eff (HA.HalogenEffects (ajax :: AX.AJAX)) Unit main = HA.runHalogenAff do body <- HA.awaitBody io <- runUI ui unit body io.query $ H.action $ QueryAnimals "" ui :: forall eff. H.Component HH.HTML Query Unit Void (Aff (ajax :: AX.AJAX | eff)) ui = H.component { initialState: const initialState , render , eval , receiver: const Nothing } -- Model newtype Animal = Animal { animalType :: String , animalImage :: String } instance decodeJsonBlogPost :: DecodeJson Animal where decodeJson json = do obj <- decodeJson json animalType <- obj .? "animalType" animalImage <- obj .? "animalImage" pure $ Animal { animalType, animalImage } decodeAnimalArray :: Json -> Either String (Array Animal) decodeAnimalArray json = decodeJson json >>= traverse decodeJson type Model = { modelAnimals :: Array Animal } initialState :: Model initialState = { modelAnimals: [] } -- Controler data Query a = QueryAnimals String a eval :: forall eff. Query ~> H.ComponentDSL Model Query Void (Aff (ajax :: AX.AJAX | eff)) eval (QueryAnimals animal_type next) = do H.modify (_ { modelAnimals = [] }) response <- H.liftAff $ AX.get ("http://localhost:3000/api/animals/" <> animal_type) let animals = case decodeAnimalArray response.response of Left _ -> [] Right ra -> ra H.modify (_ { modelAnimals = animals }) pure next -- View render :: Model -> H.ComponentHTML Query render m = HH.span [] [ HH.h1 [] [ HH.text "Animals (Purescript)" ] , HH.p [] [ HH.input [ HE.onValueInput (HE.input QueryAnimals) ] ] , HH.span [] (map (\ (Animal {animalType, animalImage}) -> HH.div [] [ HH.p [] [ HH.text animalType ] , HH.img [ HP.src ("http://localhost:3000/img/" <> animalImage) , HP.width 320 , HP.height 240 ] ] ) m.modelAnimals) ]

    Purescript a l'avantage d'être plus puissant et plus général que Elm. En contrepartie, il est moins simple à utiliser. Son environnement est également plus compliqué à utiliser : il faut gérer les dépendances Purescript avec bower, les dépendances nodejs avec npm et la compilation avec pulp.

    Haskell/Miso

    Miso est une bibliothèque Haskell pour développer des applis web frontend. Miso permet de coder une appli MVC + DOM virtuel et de la compiler en JavaScript grâce à Ghcjs.

    Ci-dessous une implémentation en Haskell + Miso de l’application d’exemple. Ce code est très similaire à l'implémentation en Elm. Miso annonce d'ailleurs explicitement s'inspirer de Elm.

    {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} import Data.Aeson (FromJSON, decodeStrict) import Data.Maybe (fromMaybe) import Data.Monoid ((<>)) import Data.Text (Text) import GHC.Generics (Generic) import JavaScript.Web.XMLHttpRequest (Request(..), RequestData(..), Method(..), contents, xhrByteString) import Miso import Miso.String (MisoString, toMisoString, fromMisoString, pack) main :: IO () main = startApp App { model = Model [] , update = updateModel , view = viewModel , subs = [] , events = defaultEvents , initialAction = GetAnimals "" , mountPoint = Nothing } -- Model data Animal = Animal { animalType :: Text , animalImage :: Text } deriving (Eq, Generic, Show) instance FromJSON Animal data Model = Model { modelAnimals :: [Animal] } deriving (Eq, Show) -- Controler data Action = GetAnimals MisoString | SetAnimals [Animal] | NoOp deriving (Show, Eq) updateModel :: Action -> Model -> Effect Action Model updateModel (GetAnimals str) m = m <# (SetAnimals <$> queryAnimals str) updateModel (SetAnimals animals) m = noEff m { modelAnimals = animals } updateModel NoOp m = noEff m queryAnimals :: MisoString -> IO [Animal] queryAnimals str = do let uri = pack $ "http://localhost:3000/api/animals/" ++ fromMisoString str req = Request GET uri Nothing [] False NoData Just cont <- contents <$> xhrByteString req return $ fromMaybe [] $ decodeStrict cont -- View viewModel :: Model -> View Action viewModel (Model animals) = span_ [] [ h1_ [] [ text "Animals (Miso)" ] , p_ [] [ input_ [ onInput GetAnimals ] ] , span_ [] $ map fmtAnimal animals ] fmtAnimal :: Animal -> View Action fmtAnimal animal = div_ [] [ p_ [] [ text $ toMisoString $ animalType animal ] , img_ [ src_ $ toMisoString $ "http://localhost:3000/img/" <> animalImage animal , width_ "320" , height_ "240" ] ]

    Pour un développeur Haskell, Miso est une bibliothèque intéressante, car elle permet d'implémenter des applis simples « à la Elm » tout en restant dans l'écosystème Haskell. En revanche, son environnement est moins mature : les outils Ghcjs + Miso + Nix ne sont pas complètement triviaux à mettre en place et les temps d'installation d'installation et de compilation plus longs.

    Haskell/Reflex

    Reflex est une bibliothèque Haskell de FRP générique. Elle est complétée par des projets associés : reflex-dom (DOM virtuel), reflex-platform (système de compilation multi-plateforme)… Une application Reflex peut être compilée avec Ghc ou avec Ghcjs et ainsi produire des applications web ou natives (PC ou mobile).

    Ci-dessous une implémentation en Haskell + Reflex de l’application d’exemple. Contrairement aux implémentations précédentes, ce code ne suit pas une architecture MVC mais gère explicitement les éléments graphiques et leurs flux d'événements. Il est tout à fait possible d'organiser le code selon un MVC mais ceci est à la charge du programmeur.

    {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Aeson (FromJSON) import Data.Default (def) import Data.Maybe (fromJust) import Data.Monoid ((<>)) import Data.Text (Text) import GHC.Generics (Generic) import Prelude import Reflex (holdDyn) import Reflex.Dom import Reflex.Dom.Xhr (decodeXhrResponse, performRequestAsync, XhrRequest(..)) main :: IO () main = mainWidget ui -- Model data Animal = Animal { animalType :: Text , animalImage :: Text } deriving (Eq, Generic, Show) instance FromJSON Animal -- View / Controler ui :: MonadWidget t m => m () ui = do el "h1" $ text "Animals (Reflex)" myInput <- el "p" $ textInput def evStart <- getPostBuild let evs = [ () <$ _textInput_input myInput , evStart ] let evCode = tagPromptlyDyn (value myInput) (leftmost evs) evResponse <- performRequestAsync $ queryAnimals <$> evCode let evResult = fromJust . decodeXhrResponse <$> evResponse dynAnimals :: (Dynamic t [Animal]) <- holdDyn [] evResult _ <- el "span" $ simpleList dynAnimals displayAnimal return () queryAnimals :: Text -> XhrRequest () queryAnimals code = XhrRequest "GET" ("http://localhost:3000/api/animals/" <> code) def displayAnimal :: MonadWidget t m => Dynamic t Animal -> m () displayAnimal dynAnimal = do let imgSrc = (<>) "http://localhost:3000/img/" . animalImage <$> dynAnimal let imgAttrs0 = ("width" =: "320") <> ("height" =: "240") let imgAttrs = ((<>) imgAttrs0) . (=:) "src" <$> imgSrc el "div" $ do el "p" $ dynText $ animalType <$> dynAnimal elDynAttr "img" imgAttrs $ dynText imgSrc

    Reflex est un projet assez ambitieux, censé permettre de développer tout type d'interfaces utilisateur et pour de nombreuses plateformes différentes. Il a l'avantage d'utiliser le langage Haskell. En revanche, il est assez compliqué à prendre en main. Programmer directement en FRP nécessite un vrai apprentissage ainsi qu'une bonne compréhension des foncteurs, applicatives et monades. Enfin, il faut structurer son code soigneusement mais soi-même.

    Conclusion

    Elm, Purescript, Miso et Reflex permettent de développer des applis web tout en profitant des avantages de la programmation fonctionnelle. Ces outils facilitent effectivement la validation de code et le refactoring, et réduisent voire suppriment les erreurs au runtime.

    Le principal inconvénient réside dans le choix parmi ces outils, qui nécessite de faire un compromis entre simplicité et flexibilité. Elm et Purescript sont de bonnes options pour du web « pur et dur ». Miso et Reflex sont plutôt à réserver à des développeurs Haskell expérimentés.

    Enfin, en dehors d'Haskell, il peut être intéressant de considérer d'autres outils comme ClojureScript, Ocsigen…

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Agenda du Libre pour la semaine 34 de l’année 2018

    19 août, 2018 - 08:18

    Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 9 événements (2 en Belgique, 5 en France, 0 au Luxembourg, 2 au Québec, 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire [CA-QC Montréal] (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres deMontréal - Le lundi 20 août 2018 de 14h00 à 17h00.

    (3L)-Logiciels Libres en liberté groupe d’utilisateurs de Logiciels Libres, de niveau débutant qui tiendra sa rencontre régulière mensuelle tout les 3ième lundi de chaque mois.

    Amener vos portables,téléphone intelligent et tablette et votre bonne humeur. Venez jaser sur les logiciels libres, Nous montrer vos découvertes, poser vos questions

    [FR Paris] Certification PGP et CAcert - Le mercredi 22 août 2018 de 19h00 à 20h00.

    Vous souhaitez renouveler votre certificat CAcert Augmenter son niveau de confiance Augmenter le niveau de confiance de votre clé publique PGP

    Venez rencontrer des certificateurs autour d'un verre

    En pratique

    Pour votre clef PGP, préparez

    • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire, …
    • un petit papier imprimé avec l'identifiant et l'empreinte de votre clef, en autant d'exemplaires que vous espérez rencontrer de gentils autres porteurs de clefs.

    Pour votre certificat CAcert, préparez

    • deux documents d'identité français parmi la carte nationale d'identité, le passeport, la carte d'identité militaire, le permis de conduire
    • des formulaires d'accréditation imprimés, pré-remplis avec vos coordonnées en cliquant ici, ou vierges en cliquant là. Deux exemplaires pour chaque accréditation un pour vous, un pour le gentil accréditeur.

    Tous les détails sur le wiki de CAcert et Meetup

    [FR Toulouse] Rencontres Tetalab - Le mercredi 22 août 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Paris] Soirée de Contribution au Libre - Le jeudi 23 août 2018 de 19h30 à 22h00.

    Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d'eux pour que le logiciel évolue.

    Nous nous réunissons donc tous les dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

    Vous aurez très probablement besoin d'un ordinateur portable, mais électricité et réseau fournis.

    En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

    Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

    On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

    Regazouillez sur Twitter - Wiki des soirées

    Programme non exhaustif

    • Fedora (sa traduction)
    • Parinux, ses bugs et son infrastructure
    • April, … y a toujours quelque chose à faire
    • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
    • Schema racktables, son code
    • Agenda du Libre, mise à jour et amélioration du code
    • Ubuntu-Fr, son orga, ses événements
    • En vente libre, maintenance et commandes
    • Open street map, une fois par mois
    • Linux-Fr sait faire
    • en vente libre

    tout nouveau projet est le bienvenu.

    [CA-QC Coteau du Lac] Émission #158 de bloguelinux - Le jeudi 23 août 2018 de 20h00 à 21h00.

    bloguelinux.ca est un blogue québécois offrant la diffusion d'un podcast qui traite des logiciels libres, du système d'exploitation Linux et de la technologie en général il y a un processeur, il y a un système d'exploitation, c'est certain que ça nous intéresse

    bloguelinux.ca est enregistré le jeudi à 20h00 toutes les deux semaines.

    Vous pouvez nous écouter en direct lors des enregistrements à l'adresse http://live.bloguelinux.ca ou directement sur notre site à http://www.bloguelinux.ca en cliquant sur la radio dans le panneau de gauche du site.

    Vous pouvez rejoindre nos conversations avec Telegram en vous abonnant au groupe BlogueLinux en suivant le lien suivant https://t.me/joinchat/ArPfnBHCcui2t_CY6qAPAg et dans notre salle de chat en vous connectant sur les serveurs de freenode.net dans la salle #bloguelinux.

    Si vous n'avez pas de client IRC, vous pouvez utiliser l'adresse http://webchat.freenode.net

    AVERTISSEMENT Ce podcast peut contenir du langage inapproprié ou vulgaire et peut ne pas convenir à tout le monde.

    Animateurs Patrick et Sandrine

    [FR Cognac] Initiation à la programmation et à la robotique - Du vendredi 24 août 2018 à 09h00 au dimanche 26 août 2018 à 16h00. Atelier sur inscription en nous envoyant un message à contact@logicielslibrescognac.org

    Programme

    Initiation à la programmation structurée Faire un programme bash ( téléchargement automatique de fichiers sur un site internet ) Cette journée est très intéressante pour commencer simplement la programmation.

    Courte initiation à la programmation fonctionnelle et orientée Objet Faire un programme en C et C++ ( créer une liste de mots du dictionnaire … et comprendre pourquoi il faut avoir des mots de passes fort…).

    Initiation à arduino (programmation et cablage) pour la création d'un petit robothttp://logicielslibrescognac.org/contact.php

    [FR Rennes] Permanence Gulliver - Le samedi 25 août 2018 de 14h00 à 18h00.

    Venez vous renseigner pour diffuser largement vos œuvres.

    Sinon venez installer Linux ou des logiciels libres.

    Venez nombreux.

    [BE Saint Gilles] Gnu/Linux Install party - Le dimanche 26 août 2018 de 10h00 à 18h00.

    L’une des grandes qualités des logiciels libres, c’est qu’on peut librement les copier, les installer, les tester

    Une Linux Install Party est une réunion où tout un chacun peut

    • venir copier, échanger, se faire assister dans l'installation de logiciels libres
    • partager des connaissances, des configurations, faire circuler des informations…
    • faire connaissance avec une culture du Libre.

    Chaque quatrième dimanche du mois, nous organisons une Install Party à l’atelier multimedia de l’asbl fij

    Le comité asbl BxLUG 2018

    [BE Bruxelles] Educode.be 2018 - Du dimanche 26 août 2018 à 18h00 au mercredi 29 août 2018 à 20h00.

     Educode.be est une conférence internationale educode sur l'enseignement et le numérique.

    L'idée est que si nous voulons que nos concitoyens soient demain capables de gérer leurs environnements numériques, il faut aujourd'hui informer, former et faire réfléchir les enseignants, les directions et les décideurs politiques qui le plus souvent sont autodidactes. 

    Les présidents d'honneur sont Bernard Rentier, ancien recteur de l'université de liège et Yves Poullet, ancien recteur de l'université de Namur.

    La conférence commence par un cocktail d'accueil dimanche 26 août à 18h00 dans la salle de marbre de l'académie royale.

    Elle commence réellement lundi 27 à 9h00 dans la salle Henri Le Bœuf de Bozar.

    le programme est quasi fait.

    Il sera visible sur http://educode.be/programme.

    La dernière conférence de la journée sera de Thomas Pesquet, astronaute français qui a emporté des expériences de sciences utilisant des ordinateurs préparées par des lycéens français et sélectionnées par ESA.  

    Toute la journée, il y aura une exposition de groupes d'enfants et de moins jeunes qui font des choses amusantes et intéressantes avec du numérique en classe ou en dehors des classes.

    Puis nous profitons de la plus belle salle de concert bruxelloise pour faire un concert symphonique d'amateurs avertis avec des chœurs d'enfants et d'adultes pour célébrer la paix et marquer le 90e anniversaire du pacte de Paris ou pacte Brian-Kellog signé le 27 août 1928 et trop vite oublié.

    Quel meilleur symbole pour marquer la paix que d'associer la musique et les langages de programmation, toutes langues universelles.

    Mardi 28, de 9h00 à 17h00, nous organisons 60 à 80 ateliers pratiques sur des sujets très variés, depuis des usages de logiciels de composition musicale ou d'aide à la version latine jusqu'à la mise en forme d'enregistrements vidéo avec smartphone ou l'apprentissage de la programmation avec ou sans ordinateur en passant par des ateliers sur les méthodes agile et scrum adaptées à l'enseignement ou des ateliers expérimentaux de physique et chimie avec ordinateurs et smartphones.

    En fin de journée, la fin du congrès pour la majorité des enseignants, nous allons prendre un buffet convivial autour des iguanodons de l'institut d'histoire naturelle.

    Mercredi 29 de 9h00 à 18h00 à l'académie royale à nouveau, nous réfléchissons durant la journée aux expériences positives partout, échangeons sur celles-ci en mode congrès scientifique. 

    Nous avons le soutien de nombreux partenaires, toutes les universités francophones, deux flamandes, de nombreuses associations, l'unesco, l'institut de formation en cours de carrière qui permet que les professeurs viennent en formation officielle, IBM, cap gemini, la plupart des ministres mais pas encore de garantie pour celui de l'enseignement obligatoire bizarrement. 

    Bien sûr, pour faire la conférence comme nous en rêvons, votre soutien tant moral que financier serait très important.

    Il manque encore des sous (nous sommes aussi occupés à essayer d'obtenir la possibilité que les dons soient défiscalisés si cela vous intéresse) 

    L'affiche actuelle dans http://esi.link/educode-affiche-fr-02

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Haiku a 17 ans

    18 août, 2018 - 09:49

    Les années passent, et Haiku est toujours là !

    Le projet, inspiré du système d'exploitation BeOS, a démarré le 18 août 2001, avec le fameux message « So, let’s start » (« Bon, allons‐y ») sur sa liste de discussion. Alors nommé OpenBeOS, le projet avait été créé peu après l’annonce du retrait de Be du marché des ordinateurs de bureau.

    Cet anniversaire est l’occasion de faire le point sur les progrès de Haiku cette année (en l’absence de nouvelle version publiée depuis la version alpha 4 en 2012, il faut bien trouver un prétexte pour donner des nouvelles de temps en temps).

    Sommaire Présentation de Haiku

    Pour ceux qui n’auraient jamais entendu parler de Haiku, il s’agit d’un système d’exploitation pour les ordinateurs personnels (par opposition, d’une part aux serveurs, d’autre part aux smartphones, tablettes, et autres systèmes embarqués). Il est une réécriture de BeOS, un système propriétaire abandonné en 2001.

    D’un point de vue technique, ses particularités sont une base de code presque intégralement en C++ (oui, même le noyau) et généralement reconnue pour sa clarté et sa lisibilité (oui, même si c’est du C++), son approche de la programmation très multi‐thread (chaque fenêtre ouverte par une application a son propre fil d’exécution, par exemple), et la présence d’une API complète et cohérente pour faciliter le travail des développeurs d’applications.

    D’un point de vue utilisateur, l’objectif est d’avoir un système facile à utiliser et à appréhender (pas de surprise ou de comportements inattendus), réactif, tout en restant flexible et capable de faire ce qu’on attend de lui.

    Pourquoi un clone de BeOS ?

    À l’origine, Haiku est pensé pour fournir une continuité aux utilisateurs de BeOS et aux développeurs d’applications qui ne souhaitaient pas migrer vers un autre système.

    Cependant, 17 ans plus tard, BeOS est mort et enterré, et Haiku n’a pas réussi à fournir une version stable dans les temps. La plupart des développeurs d’applications sont passés à autre chose depuis. Cet objectif initial n’a donc pas été atteint en temps utile.

    Cependant, Haiku reste un projet pertinent aujourd’hui, car aucun système libre n’a vraiment pris la place que BeOS a libéré (dit autrement, non, ce n’est toujours pas l’année de GNU/Linux sur le Desktop).

    Le maintien de la compatibilité avec BeOS garde également un intérêt, pas pour les utilisateurs mais pour l’organisation du projet :

    • elle permet de garder un objectif à peu près raisonnable en vue, c’est‐à‐dire qu’on peut rejeter les propositions de nouvelles fonctionnalités en disant « ce n’était pas dans BeOS » ;
    • elle permet de comparer l’implémentation des API avec celle de BeOS, pour décider si un problème vient d’une application ou d’un problème d’implémentation côté Haiku ;
    • elle permet enfin d’expérimenter les difficultés à maintenir pendant plus de 15 ans la compatibilité de l’ABI, et à réfléchir à la meilleure façon de procéder pour assurer la compatibilité entre les futures versions de Haiku.

    Cependant les désavantages (utilisation de GCC 2, impossibilité d’implémenter certaines choses ou de résoudre certains problèmes de sécurité qui nécessiteraient de changer l’API) se font de plus en plus pressants, c’est pourquoi il existe maintenant une version 64 bits de Haiku qui peut s’affranchir de certaines de ces contraintes.

    Toujours pas de version bêta

    La dernière version publiée par Haiku est la version R1 alpha 4.1, qui date de novembre 2012. De très nombreux progrès ont été faits depuis, et en particulier un gros chantier sur l’infrastructure d’hébergement du projet permettant de mettre en place un dépôt de paquets pour tous les utilisateurs (ce sera l’une des grosses nouveautés de la prochaine version R1 bêta 1).

    Si on avait su que cela prendrait autant de temps, on se serait probablement organisé autrement, afin de pouvoir publier quelques versions alphas supplémentaires et faire patienter les gens. Pour l’instant, il vaut vraiment mieux télécharger un « nightly build » pour essayer Haiku.

    Nouveautés de l’année Corrections de bogues

    Il y en a beaucoup trop pour les détailler. Haiku est de plus en plus stable. Le portage d’applications venues d’autres systèmes, et la mise en place de machines fonctionnant sous Haiku pour la compilation des paquets présents dans les dépôts a permis (même si ce n’était pas le but initial) de tester le système de façon beaucoup plus intense. De nombreux problèmes difficiles à reproduire ont ainsi pu être plus facilement identifiés, puis résolus.

    La compatibilité POSIX s’améliore, le noyau fait de plus en plus de vérifications pour éviter les « panics » lors d’appels systèmes avec des paramètres invalides.

    Un bogue mérite une mention spéciale, la méthode Split() permettant de découper une chaîne de caractères à l’endroit où elle contient un séparateur ne fonctionnait pas correctement. Il est surprenant que ce problème n’ait jamais été détecté auparavant.

    Nous avons également corrigé plusieurs problèmes d’alignement de la pile (dans le fil d’exécution principal, les handlers de signaux, et dans le noyau) qui empêchaient l’utilisation fiable d’instructions SSE2. Le problème a été mis en évidence au départ dans le navigateur web, il a donc fallu creuser assez loin dans le système pour le corriger !

    Infrastructure

    Le vénérable serveur baron, qui hébergeait l’ensemble des services de Haiku (système de suivi, dépôts Git, site Web…) depuis fin 2009 est en train d’être mis à la retraite.

    Il est remplacé par maui, un serveur plus récent, qui utilise des conteneurs docker plutôt que des machines virtuelles pour isoler les différents services.

    C’est une opportunité pour revoir entièrement la façon de gérer le serveur. Baron était administré principalement par une personne qui faisait les changements directement. Mais avec le temps, de plus en plus de services ont été mis en place et il devenait trop difficile pour une seule personne de tout suivre. Le nouveau serveur est configuré à partir de dockerfiles qui peuvent donc être relus et modifiés par plusieurs personnes.

    D’autre part, un gros changement est le déploiement de Gerrit pour la revue de code. Précédemment, les contributeurs attachaient des correctifs dans leurs rapports de bugs et la revue était faite à partir de ces fichiers, ce qui est assez peu pratique. Gerrit permet de faire une revue plus facilement, et il est donc également utilisé par les développeurs (qui pourraient directement envoyer leurs changements sur la branche principale du dépôt Git) pour obtenir une relecture de leurs changements.

    En ce qui concerne l’hébergement des dépôts de logiciels, nous avons enfin tout mis en place pour compiler automatiquement les logiciels à partir de recettes fournies par le projet haikuports. Un système de miroirs est en train de se mettre en place, avec pour l’instant deux serveurs situés aux États‐Unis et en Nouvelle‐Zélande (en plus du serveur principal situé en Allemagne).

    Les paquets binaires sont donc rapidement disponibles dans HaikuDepot (le gestionnaire de paquets de Haiku) dès la publication des recettes permettant de les construire.

    Pilotes de périphériques

    Comme pour n’importe quel système d’exploitation, un point délicat est de pouvoir fonctionner correctement sur le plus d’ordinateurs possibles. Cela passe par l’écriture de pilotes pour tous les périphériques.

    C’est donc une partie de Haiku qui est assez active et il serait difficile de recenser précisément tous les changements intervenus dans l’année. Mentionnons quand même le support des boutons « étendus » pour les pavés tactiles Synaptics et un début de support de leur « clickpad » ; la possibilité d’utiliser une imprimante connectée sur un port série; des évolutions sur les pilotes graphiques Intel et Radeon pour prendre en charge plus de versions du matériel; et de petites améliorations sur le pilote de cartes son hda (qui est utilisé sur tous les ordinateurs à base de chipset Intel).

    Mise à jour des pilotes réseau

    Pour gagner du temps, Haiku réutilise les pilotes développés pour FreeBSD via une couche de compatibilité.

    Jusqu’à l’année dernière, les pilotes de FreeBSD 9 étaient utilisés, mais aujourd’hui nous utilisons ceux de FreeBSD 11. Cela augmente le nombre de cartes réseau prises en charge et corrige de nombreux problèmes d’instabilité de la connexion.

    D’autre part, un gros travail a été fait sur la pile TCP pour compléter l’implémentation de diverses RFC permettant d’obtenir de meilleures performances.

    Prise en charge de l’USB 3

    Le pilote xHCI est maintenant fonctionnel sur la plupart des machines, même s’il ne fonctionne pas encore parfaitement. Cela devenait nécessaire, car de plus en plus d’ordinateurs ne proposent plus du tout de ports USB 2.

    Pilotes VirtIO

    Les pilotes VirtIO sont maintenant pleinement fonctionnels. VirtIO est un bus utilisé par des machines virtuelles pour remplacer certains périphériques et éviter d’émuler un matériel réel. En utilisant une interface simplifiée, l’écriture des pilotes est facilitée et les performances sont meilleures.

    Haiku peut maintenant utiliser les cartes réseau, le « ballonnement » de la mémoire (mémoire vive qui peut être redimensionnée en fonction des besoins de l’hôte et des machines émulées), et le stockage de masse sur VirtIO.

    Mise à jour du navigateur Web

    Le navigateur fourni avec Haiku est basé sur un portage de WebKit. Nous avions l’an dernier un an et demi de retard sur la version de WebKit en amont. Nous avons rattrapé une partie de ce retard puisque nous utilisons aujourd’hui une version datant de janvier 2018.

    Ceci permet d’accéder à des sites Web modernes, même si de nombreux problèmes subsistent au niveau du rendu ainsi que de l’implémentation du protocole HTTP (moins simple qu’il n’y paraît à mettre en œuvre correctement).

    En attendant, les navigateurs Qupzilla et Otter browser, en Qt, permettent de visiter certains sites que WebPositive, le navigateur natif, ne parvient pas encore à traiter.

    Media Kit

    Le Media Kit prend en charge tous les aspects multimédia (audio et vidéo, principalement) dans Haiku. Il permet aux applications d’exposer des nœuds qui sont connectés dans un graphe, un peu à la façon de Jack ou GStreamer sous GNU/Linux.

    Ajout du BMediaClient

    L’écriture de nœuds média demande beaucoup de travail répétitif et inutilement complexe. Une nouvelle classe BMediaClient a donc été introduite qui propose de prendre en charge la plupart de cet effort et donc de proposer une interface plus simple à aborder aux développeurs.

    Passage à FFmpeg 4

    Haiku utilisait encore pour sa version GCC 2 une version 0.10 de FFmpeg, car il était impossible de compiler des versions plus récentes. Cela empêchait l’utilisation des API modernes de FFmpeg et commençait à poser problème pour la prise en charge de formats de fichiers récents.

    La solution mise en place consiste à compiler ffmpeg avec GCC 7, mais à faire l’édition de lien de façon compatible avec GCC 2. Pour l’instant, cela semble fonctionner dans ce cas précis. Nous allons donc pouvoir moderniser le greffon de décodage audio et vidéo basé sur FFmpeg, qui traite dans Haiku la plupart des formats de fichiers.

    Gestion du mode hybride 32/64 bits

    La version 64 bits de Haiku ne peut actuellement pas exécuter d’applications 32 bits. Il est probable que la version 32 bits soit un jour complètement abandonnée, mais pour cela il faudra proposer une solution pour que les utilisateurs puissent migrer vers la version 64 bits en conservant leurs applications.

    La gestion de l’exécution des applications 32 bits sur un noyau 64 bits est donc un des chantiers en cours. Cela pose un certain nombre de problèmes au niveau de l’interface entre le noyau et l’espace utilisateur, les appels systèmes devant traiter les données dans le bon format selon l’application utilisée.

    La première étape déjà franchie est l’intégration de SMAP et SMEP, qui permettent de s’assurer que le noyau n’accède pas par erreur aux données en espace utilisateur (la protection dans l’autre sens étant déjà assurée par la MMU). On a pu grâce à cette vérification clairement identifier tous les endroits ou de tels accès sont effectués, ce qui permettra de repérer facilement s’il est nécessaire ou pas de faire une conversion 32 <=> 64 bits. De plus, on gagne en sécurité puisqu’il sera plus compliqué pour une application d’utiliser un appel système de façon détournée pour lire ou écrire dans la mémoire du noyau.

    Passage à GCC 7

    Haiku dans sa version 32 bits est fourni avec deux compilateurs, une version 2.95.3 de GCC qui permet d’assurer la compatibilité binaire avec BeOS, et un GCC plus récent permettant de compiler les applications modernes (la version 64 bits de Haiku n’assure pas pour l’instant de compatibilité, et donc fournit uniquement une version moderne de GCC).

    L’année dernière, la version « moderne » utilisée était GCC 5.4. Nous utilisons maintenant la version 7.3. La migration a été l’occasion de corriger quelques bogues dans Haiku qui l’empêchaient de démarrer avec les nouvelles optimisations proposées par GCC.

    Le travail est déjà en cours pour le passage à GCC 8, qui lève de nouveaux warnings (une grande partie de Haiku est bien entendu compilée avec le drapeau -Werror, donc les warnings ne sont pas admis).

    Le retour de Cosmoe

    Cosmoe est un projet consistant à porter l’espace utilisateur de Haiku sur un noyau Linux ou BSD. Il n’a jamais abouti à quelque chose de fonctionnel, mais plusieurs développeurs (impliqués dans Haiku ou pas) ont repris le projet de temps en temps pour y faire quelques mises à jour.

    Cette fois, le projet a été repris par Dario Casuolinovo alias Barrett, qui a travaillé sur Caya (notre client de messagerie instantanée) et sur le Media Kit de Haiku. Son travail sur le Media Kit l’a convaincu que le noyau utilisé dans Haiku n’était plus pertinent aujourd’hui et qu’il valait mieux l’abandonner pour quelque chose d’autre. Nous verrons si Cosmoe arrive à percer cette fois‐ci.

    Les membres du projet Haiku pensent que leur noyau reste pertinent (pour diverses raisons, en particulier le fait qu’il est écrit en C++ et qu’il offre une ABI stable pour les pilotes de périphériques) mais sont heureux de voir émerger d’autres projets inspirés par BeOS.

    LibreOffice pour Haiku

    Ça y est ! après plusieurs tentatives (quand on a commencé, le projet s’appelait encore OpenOffice…), nous avons enfin une version de LibreOffice pour Haiku.

    Cela a été rendu possible par le gros travail chez LibreOffice pour simplifier leur système de compilation, et également par le système de paquets de Haiku qui a permis de capitaliser et de mutualiser le portage des dépendances de LibreOffice.

    Bien qu’une grande partie des efforts a été faite pour avoir une version native, c’est finalement l’apparition d’un back‐end Qt dans LibreOffice qui a permis d’avoir une version fonctionnelle le plus rapidement.

    La disponibilité d’une suite bureautique moderne est un point important, d’une part parce qu’on peut maintenant présenter Haiku sérieusement comme un système utilisable pour faire un peu de bureautique et de navigation Web, et d’autre part parce que LibreOffice remplace GoBe Productive, l’une des dernières applications BeOS non libres et encore utilisées (la prochaine sur la liste est Sync Modular — avis aux volontaires). On peut donc commencer à envisager plus sereinement l’abandon de la compatibilité binaire avec BeOS.

    D’autres langages de programmation

    Le langage Rust est à la mode, il était donc indispensable d’avoir une version pour Haiku et c’est maintenant chose faite. Rust 1.28 contient tous les correctifs nécessaires pour compiler directement sur Haiku, sans modifications.

    Mentionnons aussi une version de Swift qui est arrivée cette année, la prise en charge de Fortran disponible par défaut dans GCC, et des progrès pour avoir une version de Free Pascal complètement opérationnelle. Ceci, bien sûr, en plus de tous les langages qui fonctionnaient déjà très bien auparavant : Python 2 et 3, Lua, Perl, C, C++ et de nombreux autres.

    Java et Go ont été disponibles quelque temps, mais ont disparu des dépôts lors de l’automatisation des builds. L’ancien paquet pour Java 7 fonctionne, la version de Java 8 disponible plante au démarrage, et il n’y a pas encore eu de tentative pour les versions suivantes. Du côté de Go, une version assez ancienne était fonctionnelle, mais il est maintenant impossible de la compiler, car les sources référencent des dépôts hébergés par code.google.com, maintenant fermé. Avis aux volontaires pour remettre tout ça en route.

    Enfin, il semble utile de présenter yab, une divergence de yabasic qui permet de développer des applications graphiques pour Haiku. Il n’était plus vraiment maintenu, mais quelques développeurs l’utilisant se sont un peu mis au C++ pour faire les évolutions nécessaires. Il est maintenant disponible dans les dépôts, l’interpréteur étant distribué sous forme d’une bibliothèque partagée qui peut être utilisée par tous les programmes écrits en yab.

    Prise en charge de l’UEFI

    Il est maintenant possible d’installer Haiku sur une machine UEFI. Actuellement ce n’est pas intégré dans les « nightly builds » générés par nos buildbots, il s’agit d’une image séparée contenant uniquement un chargeur de démarrage UEFI. Plus tard, ce sera intégré aux images « anyboot » (qui disposent également d’un MBR pour démarrer depuis une clé USB, et d’un chargeur « el torrito » pour démarrer quand elles sont gravées sur un CD).

    Améliorations de l’interface utilisateur

    Là encore, beaucoup trop de changements pour tous les lister, mais les applications fournies avec Haiku ont vu de nombreux petits changements. Cela va du comportement des menus ouverts trop près du bord de l’écran, à une meilleure prise en charge des écrans haute résolution (il suffit de choisir une taille de police de caractères appropriée, le reste de l’interface doit s’adapter en fonction).

    Launch Daemon

    Le Launch Daemon est chargé de l’exécution des services, et du séquençage du démarrage et de l’arrêt du système.

    Les évolutions cette année portent sur la gestion des logs, une réécriture de la procédure d’arrêt pour éviter d’éteindre la machine avant que l’utilisateur ait pu enregistrer tous les changements dans des applications ouvertes (dans certains cas tordus). Il reste néanmoins bien plus léger que systemd.

    Évènements et conférences

    Comme chaque année, Haiku était présent au FOSDEM, au Capitole du Libre, aux JDLL et aux RMLL. L’occasion de donner plusieurs conférences, de rencontrer les développeurs d’autres projets et d’en profiter pour porter quelques logiciels vers Haiku avec l’aide des contributeurs principaux (mentionnons cette année Poezio, Dead Ascend, ou encore le Godot Engine, qui avait déjà un portage mais non maintenu). Nous avons également pu constater lNincompatibilité de Haiku avec les machines Purism Librem, sans avoir le temps de se pencher de plus près sur la question, malheureusement.

    La conférence BeGeistert, qui regroupe depuis très longtemps les utilisateurs et développeurs de Haiku (et de BeOS et Zeta), a pris une pause cette année, l’équipe organisatrice n’ayant plus la motivation pour s’en occuper étant donné le peu de personnes présentes.

    Le projet Haiku mettait à profit cette conférence pour organiser un « coding sprint », qui consiste à mettre le plus grand nombre possible de développeurs dans une salle de réunion pendant cinq jours avec un stock approprié de sodas, et une cantine et des lits à disposition. Le coding sprint étant un moyen étonnamment efficace de faire avancer les choses, nous avons décidé de le maintenir, et de l’organiser cette année juste après le Capitole du Libre, à Toulouse. Le changement de lieu a été plutôt apprécié par les développeurs présents, qui ont pu en particulier travailler sur le portage de LibreOffice, des corrections de bugs dans le navigateur web, l’amélioration de l’application HaikuDepot (le gestionnaire de paquets graphique) pour régler divers problèmes de performance et faire quelques améliorations cosmétiques, ou encore ajouter le réglage de la luminosité de l’écran sur les PC portables utilisant un chipset vidéo Intel.

    Bonne nouvelle, après cette année sans BeGeistert, l’évènement sera de retour en octobre prochain. Nous retournerons en Allemagne mais nous quitterons Düsseldorf, dont l’auberge de jeunesse qui nous a souvent accueilli n’offre plus des tarifs accessibles pour le budget de HSA (l’association qui finance l’évènement). Le format retenu est un évènement sur quatre jours, le détail sera décidé par la suite, sans doute un intermédiaire entre une conférence (avec quelques présentations) et un coding sprint.

    GCI et GSoC

    Haiku candidate tous les ans au Google Code‐In et au Google Summer of code.

    Google Summer of Code

    Il s’agit d’un programme organisé par Google dont le principe est de payer des étudiants pour qu’ils puissent travailler à plein temps sur des projets libres. Les membres de chaque projet s’occupent de l’encadrement, et ont toute liberté dans les sujets proposés.

    Haiku a accueilli trois étudiants cette année, travaillant sur le système de fichiers XFS (mais cela n’a pas donné grand‐chose), un pilote pour les périphériques SDHCI (lecteurs de cartes SD sur de nombreuses plates‐formes ARM et certains portables x86), et un client graphique pour Git intégré dans le système de suivi (largement inspiré de TortoiseGit sous Windows). Les deux derniers projets sont en bonne voie.

    Google Code‐In

    Code‐In, quant à lui, cible les enfants de 13 à 17 ans, le but étant de leur faire découvrir le logiciel libre et plus généralement le développement de logiciels.

    Il s’agit d’un concours où les participants doivent compléter différentes tâches assez simples proposées par un projet libre. Chaque projet choisit ensuite deux gagnants qui pourront passer une semaine à San Francisco, assister à des conférences de personnes travaillant chez Google, et obtenir de nombreux auto‐collants, T‐shirts, et autres goodies.

    Haiku participe tous les ans depuis la création du Google Code-In en 2010. Cela nécessite un investissement important de toute la communauté autour du projet, en effet il n’est pas facile de gérer l’arrivée massive des participants sur les canaux IRC et listes de diffusion du projet. Cependant, l’habitude est prise et l’organisation est un peu meilleure chaque année.

    Les tâches proposées sont diverses, on trouve des choses techniques (par exemple porter et packager un logiciel pour Haiku), graphiques (concevoir un autocollant à distribuer lors des conférences ou un poster présentant Haiku), de la documentation, ou encore du test (trouver des bugs dans un logiciel, écrire un plan de test, vérifier si des bugs reportés dans le passé sont toujours présents), et enfin une catégorie « outreach » (par exemple, préparer une présentation sur Haiku et la présenter à d’autres élèves, ou encore faire une vidéo présentant une fonctionnalité particulière).

    L’intérêt principal de ces deux programmes est l’accueil de nouveaux contributeurs et l’amélioration de la diversité de notre équipe, en effet la communication de Google et des différents projets participants permet de faire découvrir Haiku à des personnes qui ne seraient pas autrement venues contribuer.

    On ne compte plus vraiment sur ces projets pour faire avancer les choses directement : le temps nécessaire pour l’encadrement dépasse largement le temps qu’un développeur expérimenté aurait utilisé pour faire le travail directement. Cependant l’expérience est intéressante et nous permet aussi d’améliorer notre documentation et notre façon de travailler pour être plus accueillants aux nouveaux contributeurs.

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Dark Moon : une distribution GNU/Cygwin portable pour Windows

    16 août, 2018 - 22:42

    Dark Moon est un émulateur de terminal open source développé par Mehdi Boutayeb Ferkatou, étudiant à l'université Paul Sabatier, et édité par MBK logiciel dans sa version UWP sur le Microsoft Store.

    Dark Moon est à ce jour la seule distribution GNU/Cygwin disponible sur le Microsoft Store et sur le site de l’éditeur.

    Sommaire Présentation

    Dark Moon est un ensemble de logiciels libres basé sur Cygwin rendu portable permettant l’exécution de commandes POSIX dans le but d’émuler un environnement UNIX sur plate‐forme Windows x64. Dark Moon permet de créer des scripts et des programmes utilisant les commandes grâce à une grande collection d’outils GNU et open source intégrée dans le terminal.

    Embarquer une collection d’API POSIX sous la forme d’un exécutable nous permet d’envisager une informatique hyper‐transportable pour les émulateurs et distributions GNU/Cygwin, il suffit alors de trouver du courant et un processeur hôte pour exécuter l’application, ce qui aurait été auparavant impossible avant la naissance de Dark Moon. L’objectif technique recherché est de fournir un environnement de développement ainsi qu’un émulateur UNIX cloisonnés dans un exécutable apportant une mobilité au logiciel, permettant d’exécuter l’application sur n’importe quel système Windows.

    Idée générale

    Dark Moon est autonome, ce qui le distingue d’autres distributions équivalentes. Il est possible d’exécuter des commandes Shell et Bash ainsi que de créer et exécuter des scripts sur la console. L’application est également un outil de développement, notamment en offrant aux utilisateurs un environnement de développement libre tel que GCC.

    Cette distribution est également un outil UNIX complet, personnalisable et offrant une mobilité ne demandant pas d’installation préalable. Elle est née en vue de fournir aux utilisateurs des possibilités étendues en complément de l’interpréteur de commande Windows. Il est possible de manipuler des fichiers ainsi que la ruche de registre sans déposer aucune empreinte sur l’ordinateur hôte, afin d’éviter d’apporter des modifications durables à un poste utilisé temporairement.

    L’émulateur a fait l’objet d’une ouverture au public du code source, le logiciel libre est sous licence GNU GPL, il n’y a donc pas de restriction d’utilisation et de modification du logiciel tant que les conditions de la licence sont respectées.

    En comparaison d’autres distributions Cygwin et GNU/Linux, l’application ne requiert aucun composant externe, les fichiers étant cloisonnés dans l’exécutable même, permettant un emploi à partir d’un stockage amovible comme une clé USB.

    Différentes bibliothèques ont été incluses, notamment MinGW qui travaille avec des composants Windows comme la bibliothèque MSVCRT liée à Microsoft Visual C++. Busybox est intégré pour l’implémentation d’un grand nombre des commandes. Par ailleurs, il est également possible d’utiliser un agent d’authentification OpenSSH.

    Le code source ainsi que les fichiers compilés ont été emballés dans l’exécutable pour respecter le concept de portabilité (il suffit de l’extraire avec 7zip pour avoir accès aux fichiers sources).

    Liste des commandes actuellement disponibles Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Voi job_spec [&] history [-c] [-d offset] [n] or hist> (( expression )) if COMMANDS; then COMMANDS; [ elif C> . filename [arguments] jobs [-lnprs] [jobspec ...] or jobs > : kill [-s sigspec | -n signum | -sigs> [ arg... ] let arg [arg ...] [[ expression ]] local [option] name[=value] ... alias [-p] [name[=value] ... ] logout [n] bg [job_spec ...] mapfile [-d delim] [-n count] [-O or> bind [-lpsvPSVX] [-m keymap] [-f file> popd [-n] [+N | -N] break [n] printf [-v var] format [arguments] builtin [shell-builtin [arg ...]] pushd [-n] [+N | -N | dir] caller [expr] pwd [-LP] case WORD in [PATTERN [| PATTERN]...)> read [-ers] [-a array] [-d delim] [-> cd [-L|[-P [-e]] [-@]] [dir] readarray [-n count] [-O origin] [-s> command [-pVv] command [arg ...] readonly [-aAf] [name[=value] ...] o> compgen [-abcdefgjksuv] [-o option] [> return [n] complete [-abcdefgjksuv] [-pr] [-DE] > select NAME [in WORDS ... ;] do COMM> compopt [-o|+o option] [-DE] [name ..> set [-abefhkmnptuvxBCHP] [-o option-> continue [n] shift [n] coproc [NAME] command [redirections] shopt [-pqsu] [-o] [optname ...] declare [-aAfFgilnrtux] [-p] [name[=v> source filename [arguments] dirs [-clpv] [+N] [-N] suspend [-f] disown [-h] [-ar] [jobspec ... | pid > test [expr] echo [-neE] [arg ...] time [-p] pipeline enable [-a] [-dnps] [-f filename] [na> times eval [arg ...] trap [-lp] [[arg] signal_spec ...] exec [-cl] [-a name] [command [argume> true exit [n] type [-afptP] name [name ...] export [-fn] [name[=value] ...] or ex> typeset [-aAfFgilnrtux] [-p] name[=v> false ulimit [-SHabcdefiklmnpqrstuvxPT] [l> fc [-e ename] [-lnr] [first] [last] o> umask [-p] [-S] [mode] fg [job_spec] unalias [-a] name [name ...] for NAME [in WORDS ... ] ; do COMMAND> unset [-f] [-v] [-n] [name ...] for (( exp1; exp2; exp3 )); do COMMAN> until COMMANDS; do COMMANDS; done function name { COMMANDS ; } or name > variables - Names and meanings of so> getopts optstring name [arg] wait [-n] [id ...] hash [-lr] [-p pathname] [-dt] [name > while COMMANDS; do COMMANDS; done help [-dms] [pattern ...] { COMMANDS ; } Syntaxe

    Avec les appliquettes de commande mises à disposition, il est possible de créer des scripts aisément, comme présenté ci‐dessous :

    #Mon premier script function() { local variableLocal="function 1" echo "$variableLocal" echo "Nombres de paramètres : $#" echo $1 echo $2 } function "Hello" "World"

    Pour lancer le script, placez‐vous dans le dossier contenant le script (obligatoire) :

    cd C:\Users\[Userprofile]\Documents\script-Shell

    Faites un chmod :

    chmod 700 MonPremierScript

    Et exécutez‐le :

    Nombres de paramètres : 2 Hello World Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps !

    14 août, 2018 - 07:27

    Toutes celles et ceux qui ont travaillé dans un lycée ou une université savent à quel point la gestion des emplois du temps est un sac de nœuds. La personne responsable s’arrache les cheveux pour tenter de fabriquer quelque chose qui satisfasse tout le monde… et ne réussit jamais !

    Alors, avec quelques enseignants de l’IUT de Blagnac, on a développé FlOpEDT. C’est un logiciel libre qui génère les emplois du temps tout seul et permet aux utilisateurs de saisir leurs disponibilités et d’apporter des modifications en ligne et en toute autonomie.
    Toutes les briques de FlOpEDT sont libres, et lui‐même est en licence AGPL v3.

    Facile à utiliser et plein de liberté !

    Les utilisateurs se connectent et saisissent leurs préférences à l’aide d’une interface intuitive : un « sens interdit » pour les indisponibilités, une couleur explicite pour les préférences.

    Ensuite, l’emploi du temps est généré automatiquement en quelques minutes en respectant contraintes et préférences. L’emploi du temps est alors accessible à tous, et il est possible pour tout utilisateur de le modifier.

    Cette partie est celle qui étonne : on nous dit souvent que si tout le monde peut faire des modifications ce sera la pagaille. Notre expérience confirme l’inverse : cela génère du confort pour tout le monde, et tout le monde a à cœur de prendre soin de cette liberté nouvelle (pas de coups de fils à passer, pas de courriels gênés…). Évidemment, l’application empêche toute modification qui ne respecterait pas les règles fixées collectivement.

    FlOpEDT est aussi doté d’un outil de synchronisation avec iCal (pour les agendas en ligne), ainsi que d’un outil de synchronisation avec des bases de données extérieures.

    Plus précisément, FlOpEDT se divise en deux parties essentielles :

    • une application web, développée dans le cadriciel Django (Python 3), s’appuyant sur une base de données PostgreSQL ;
    • un outil de création de l’emploi du temps, qui passe par la définition d’un système d’équations linéaires (à l’aide de PuLP) et sa résolution.

    FlOpEDT n’en est qu’à sa version 0, et il n’est pour l’instant pas extrêmement générique : l’adaptation aux contours précis de votre établissement demanderait pour l’instant du travail. Mais ce temps investi permettrait d’en gagner ensuite beaucoup, et vous participeriez au développement d’un logiciel à terme utile à toutes et tous. Alors n’hésitez pas à nous contacter si vous voulez le tenter, votre proposition ne fera pas flop

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur

    Movim, mode d’emploi — Première partie : l’architecture

    13 août, 2018 - 22:03

    Je travaille maintenant depuis presque dix ans sur Movim et je n’ai jamais réellement eu l’opportunité d’expliquer comment le projet fonctionne. Prenons un peu le temps de mettre tout ça par écrit !

    Cette présentation sera divisée en plusieurs articles. Je vais commencer par présenter le projet de façon globale avant d’aller progressivement vers son fonctionnement interne et ses détails techniques.

    Sommaire

    J’utilise les plates‐formes sociales depuis pas mal d’années maintenant et je suis toujours surpris de voir que malgré les milliards de dollars investis par les géants du Web elles fonctionnent toutes plus ou moins selon la même architecture.

    Même avec toutes les technologies qui sont apparues ces dernières années les choses se présentent toujours plus ou moins de la même façon : vous publiez du contenu via des requêtes AJAX (ou au travers d’un Websocket), c’est sauvegardé dans une base de données et vos contacts vont périodiquement envoyer une requête au serveur pour voir si il y a quelque chose de nouveau à afficher.

    C’est au final assez facile à construire et si vous souhaitez le faire vous‐même il existe de nombreux cadriciels qui offrent tous les outils nécessaires pour réaliser cette architecture aisément (typiquement Laravel, Ruby on Rails, Django, Symfony ou Zend, connectés à une base de données SQL, une API REST, une jolie interface et hop vous avez un réseau social).

    Mais pourquoi donc devoir attendre pour récupérer les publications des autres contacts ?

    Nous avons depuis des décennies maintenant des technologies de messagerie instantanée qui nous permettent d’envoyer, en temps réel, tout autour du globe, du contenu sans le moindre souci. Pourquoi ne pouvons‐nous pas faire de même avec les réseaux sociaux ?

    Et c’est ici que réside l’idée de base du projet Movim.

    Créons un réseau social temps réel

    Donc, l’une des erreurs à éviter quand le projet a démarré, c’était de réinventer la roue. Vous verrez que Movim est principalement composé de technologies basiques et déjà éprouvées.

    Pour fabriquer un réseau social fonctionnant en temps réel, il me fallait transférer du contenu instantanément sur le réseau. Il devait donc être transporté au sein d’un système « connecté » et donc construit sur des sockets (contrairement aux systèmes construits sur des requêtes).

    Cela exclut déjà toutes les récentes technologies sociales standardisées par le W3C (bye bye ActivityPub et WebSub), ces dernières étant construites sur HTTP. Loin de moi l’idée de remettre en question ces standards, ce sont des solutions sérieuses et parfaitement valides, mais pas pour les besoins de Movim.

    Je cherchais donc un protocole qui soit :

    • temps réel ;
    • standard (avec des RFC sérieuses) ;
    • et si possible déjà éprouvé et largement déployé.

    Cela nous amène donc à XMPP (je ne vais pas expliquer en détail comment le protocole est construit, vous pouvez trouver plus d’informations sur la page Wikipedia et sur le site officiel de la fondation).

    Dans la pratique, XMPP nous offre quelques précieux avantages :

    • c’est un protocole temps réel (super !), les données sont échangées dans le format XML (oui, je vous vois déjà venir, vous les défenseurs du JSON ! Mais gardons de côté ce différend pour plus tard ;)) sous forme de paquets (appelés « stanzas » dans le cas présent) envoyés en TCP et chiffrés avec TLS ;
    • XMPP offre un cadriciel très simple et générique qui comprend de (très !) nombreuses extensions que l’on peut combiner afin de développer la solution désirée (voici pour l’exemple celles utilisées pour construire Movim) ; et parce que XMPP est basé sur XML, il est très facile de l’étendre au moyen d’espaces de noms (namespaces) existants : prenez Atom, ajoutez‐y Pubsub et voilà, vous obtenez un système de publication de contenu complet, temps réel, pour vos articles avec pièces jointes, bien défini et tout à fait spécifié ;
    • vous pouvez faire bien plus que de simples choses « sociales » avec XMPP ; pas besoin de composer avec dix autres protocoles, XMPP offre déjà tout pour faire du clavardage et des salons de discussion, de la vidéoconférence, des solutions de publication-abonnement et beaucoup d’autres choses. Et cela offre l’avantage de conserver un code assez concis puisqu’il n’y a qu’un unique protocole dans le back‐end ;
    • XMPP est fédéré et utilise un réseau un peu similaire à celui du courrier électronique ; les comptes sont créés sur les serveurs (c’est pourquoi les identifiants sont également similaires : nomutilisateur@serveur.tld), les clients se connectent ensuite à ces serveurs XMPP ; en plus de ça, vous pouvez avoir plusieurs clients connectés, en même temps, à votre compte et ils seront tous synchronisés en temps réel :) ;
    • il y a déjà une grande communauté, avec des serveurs sérieux qui peuvent gérer des millions de connexions simultanément sans aucun problème (ejabberd <3).

    C’est aussi un gros avantage pour Movim. Je n’ai pas à m’occuper de tous les problèmes de réseau. C’est « juste » un client simple et stupide qui se connecte aux serveurs XMPP, en obtient du contenu et leur en envoie.

    Si vous comparez cette solution avec d’autres solutions de réseau fédéré telles que Mastodon ou Diaspora, il y a là une grande différence : pour Movim, les comptes sont sur un serveur distinct. Je n’ai donc pas besoin de créer une autre API pour communiquer avec Movim. Tout le monde peut échanger avec Movim en implémentant simplement XMPP (et il y a déjà beaucoup de bibliothèques et de solutions dans la nature pour le faire).

    OK, nous avons choisi le protocole, maintenant nous devons construire le back‐end.

    Un peu d’histoire

    J’ai créé Movim en 2008 afin d’apprendre à programmer et essayer de construire par la même occasion une plate‐forme sociale sur laquelle j’aimerais échanger avec mes proches. Ayant choisi d’apprendre le langage PHP par la même occasion j’ai tout naturellement choisi celui‐ci pour commencer les travaux.

    Avec les connaissances acquises au cours de mes études, l’aide d’un ami (Etenil, si tu me lis…) et de ce que j’ai pu apprendre de façon autodidacte j’ai progressivement amélioré Movim et rajouté les nombreuses fonctionnalités qui me paraissaient intéressantes pour construire une plate‐forme sociale digne de ce nom.

    Puis au cours de l’été 2014 j’ai décidé d’entièrement réécrire le cœur de Movim afin d’en faire une plate‐forme entièrement temps réel. En effet, jusqu’ici le projet était construit sur une « émulation » de temps réel construite au dessus de HTTP via les connections XMPP (en utilisant l’extension BOSH).

    Ces changements apportèrent également une importante réécriture de l’architecture interne et d’une refonte de l’interface utilisateur.

    À cette période un nouveau cadriciel commençait à faire parler de lui au sein de la communauté. ReactPHP permettait en effet de construire très facilement des architectures entièrement en temps réel en PHP et offrait tout ce que je recherchais pour cette réécriture.

    Un démon, quelques tuyaux et voilà !

    ReactPHP est un ensemble d’outils s’interconnectant entre eux et permettant de créer toutes sortes d’architectures fonctionnant entièrement en temps réel.

    J’utilise à ce jour les modules suivants :

    • react/event-loop, le cœur de React, s’occupant de la gestion de toutes les entrées‐sorties ;
    • react/dns, un résolveur DNS asynchrone ;
    • react/promise-timer, pour exécuter périodiquement des évènements ;
    • react/socket, pour se connecter à XMPP en utilisant des sockets TCP (avec une couche de chiffrement TLS par dessus) ;
    • react/child-process, pour lancer et gérer des sous‐processus ;
    • react/stream, afin de connecter toutes ces choses ensemble ;
    • react/zmq, une bibliothèque ZeroMQ pour pouvoir gérer efficacement les communications au sein de Movim.

    Il m’a fallu ensuite quelques mois de recherche avant de trouver une architecture stable, qui n’a que peu changé par la suite.

    Rentrons un peu dans les détails.

    Toute la structure de Movim est prise en charge par un démon central (qui s’appelle daemon.php, c’est fou !). Ce démon s’occupe de tous les WebSockets des navigateurs des utilisateurs (mobiles et bureau) et lance un sous‐processus pour chaque utilisateur connecté. Finalement, il se comporte comme un routeur tout bête qui transfère les messages entre les WebSockets des utilisateurs et leurs processus respectifs

    Cette architecture offre plusieurs avantages :

    • les sessions utilisateur sont isolées et n’influent pas sur les performances les unes des autres ;
    • elles peuvent être contrôlées plus facilement (tuer une session ne supprimera pas les autres) ;
    • le démon principal est minimal (il agit comme un simple routeur).

    Cela présente néanmoins un inconvénient : la consommation de mémoire est supérieure. Le code est chargé plusieurs fois entre les différents sous‐processus. Il faut compter environ 10 à 20 Mio par utilisateur connecté. La situation s’est bien améliorée depuis les dernières versions puisque la consommation mémoire de Movim lui‐même a été réduite en retirant des dépendances et en mettant à jour PHP (PHP 7.0+). La consommation mémoire reste un point d’amélioration pour les versions à venir puisqu’elle pourrait devenir un goulot d’étranglement. Le cadriciel peut facilement supporter des milliers de connexions simultanées mais la mémoire vive manquera bien avant d’y arriver.

    Chacun des ces sous processus se connecte au serveur XMPP de l’utilisateur puis prend en charge toutes ses communications. Il se connecte aussi à la base de données SQL commune qui fait office de cache pour chaque compte et permet l’échange de données entre eux (via la découverte de ressources publiques par exemple)

    Pour finir, ces processus gèrent aussi tout ce qui est relatif au frontal, mais cette partie sera expliquée plus en détail dans un article à venir.

    Optimisations

    Certaines optimisations ont été faites pour améliorer les performances globales de cette architecture. En voici les trois principales, celles qui je pense, ont eu le plus grand impact sur le projet.

    Analyseur de flux XML

    Une connexion XMPP peut être ramenée à un flux XML bidirectionnel. Le client envoie des requêtes XML (appelées stanzas) et analyse (d’un point de vue lexical) les requêtes entrantes. Le point important ici est que les requêtes entrantes font partie d’un seul et même « document » XML. À l’origine, Movim détectait chacune de ces stanzas et les analysait séparément.

    L’analyseur a donc été remanié pour travailler en flux (voir analyseur syntaxique XML). Cela permet à Movim de préparer les stanzas entrantes et de lancer les événements qui leur sont relatifs dès que les premières balises XML sont reçus dans le socket. Le petit changement a vraiment amélioré les performances XMPP globales du projet. En particulier pendant la phase de connexion puisque Movim peut maintenant traiter plusieurs milliers de stanzas en quelques secondes.

    Hello ZeroMQ !

    Les communications entre le démon principal et les sous‐processus (qu’on appelle « linkers » dans Movim) sont à l’origine de simples stdin/stout. Cela a créé des problèmes de tampons et de performance et j’ai finalement choisi d’utiliser un outil spécifique à la tâche : ZeroMQ.

    À chaque fois que le démon principal invoque un linker pour un utilisateur, il crée deux flux IPC dédiés (un pour les messages entrants et un pour les messages sortants) puis gère tout ce qui les traverse.

    Cela m’a permis d’éviter la création de certains tampons dédiés au transit de messages et ainsi d’améliorer les performances globales, en particulier pour la partie interface utilisateur.

    ZeroMQ est aussi très léger et est déjà disponible et empaqueté sur la majeure partie des distributions GNU/Linux.

    De Modl à Eloquent

    Movim dépendait au début d’un ORM spécifiquement créé pour le projet (Modl). La version qui arrive (0.14) utilisera la bibliothèque reconnue Eloquent (utilisée par le cadriciel Laravel).

    Ce changement m’a permis d’utiliser des fonctionnalités comme le eager loading et le lazy loading, mais aussi d’écrire des migrations proprement et d’optimiser certaines requêtes.

    Plus d’informations dans l’article dédié.

    Ce que j’ai appris

    Après toutes ces années à travailler sur ce project temps réel, je peux maintenant tirer certaines conclusions sur les choix et changements que j’ai réalisés :

    • PHP n’est pas un problème la plupart du temps : PHP est rapide, vraiment rapide ; la plupart des optimisations que j’ai obtenues étaient liées à la façon dont je gérais les flux et leur contenu ainsi qu’aux requêtes dans la BDD ; passer à PHP 7 puis aux versions suivantes a un peu amélioré les performances, mais le gain a été négligeable par rapport à ce qui a découlé des autres changements réalisés dans le code ;
    • chercher le goulot d’étranglement : quand on travaille en temps réel, même si certaines parties sont gérées par des promesses et autres systèmes asynchrones, il y a toujours du code synchrone et donc bloquant ; il faut s’assurer que ce code n’est pas « trop lent ». Dans Movim, par exemple, les requêtes BDD sont toujours considérées comme bloquantes (c’est une autre optimisation qui pourrait être apportée…) ce qui fait qu’une requête qui prend 200 ms à être déclenchée va retarder l’exécution du reste du code de 200 ms ;
    • tester en « conditions réelles » : je pensais que Movim était rapide jusqu’au moment où j’ai vu des utilisateurs galérer avec (Nik, si tu me lis…) ; certains utilisateurs de Movim avaient beaucoup plus de salons de discussion et avaient souscrit à beaucoup plus de flux que prévu, ce qui a créé de gros ralentissements, en particulier pendant la phase de connexion ; grâce à quelques optimisations bien pensées (et parfois très simples), les choses sont revenues à la normale ;
    • et peut‐être la plus importante de toutes : Keep It Simple!

    J’ai l’impression que beaucoup de projets accordent trop d’importance au principe DRY — Don’t Repeat Yourself). Parfois il n’est pas nécessaire d’importer une bibliothèque entière, écrire une fonction qui correspond exactement à la situation peut faire l’affaire. Il est préférable de garder aussi peu de dépendances que possible.

    Questionnez‐vous sur ce dont votre projet a besoin pour fonctionner. Est‐ce que tout est vraiment indispensable ?

    Et pour finir, n’ayez pas peur d’un grand ménage de printemps de temps en temps (j’ai passé 50 heures à remplacer Modl par Eloquent) pour simplifier et nettoyer votre code si nécessaire.

    Du coup, Movim est rapide ?

    Movim est rapide. Dans certains cas, Movim est même plus rapide que certains clients XMPP natifs comme Pidgin ou Gajim. Movim est aussi plus rapide que certaines autres plates‐formes de discussion en ligne, de par son back‐end, mais aussi grâce à la façon dont son frontal est mis en œuvre. J’en reparlerai dans un prochain article.

    Sur mon compte (400 contacts, 50 salons de discussion) s’authentifier et obtenir une interface réactive ne prend qu’une poignée de secondes, surtout sachant que les données viennent d’un serveur tiers (votre serveur XMPP) et sont re‐synchronisées pour certaines lorsque vous vous connectez.
    Si vous voulez voir le résultat par vous‐même, faites un tour sur le site officiel. ;)

    That’s all folks!

    Télécharger ce contenu au format Epub

    Commentaires : voir le flux atom ouvrir dans le navigateur