Informathécaires biblioticiens

Ben OK, mais nous on est des bibliothécaires, ON N’EST PAS des informaticiens !

Que le responsable de bibliothèque numérique (ou autre service s’occupant de près ou de loin d’ordinateurs) qui n’a pas entendu 70 fois cette sentence en réunion me jette le premier commentaire.

Soyons justes, si cette phrase est si souvent prononcée, c’est d’abord parce qu’elle est vraie.

Mais c’est aussi pour traduire la frustration commune à tous les utilisateurs non-experts1 face à un outil indispensable mais qui hélas, pour le dire en termes mesurés, ne fonctionne pas toujours parfaitement bien. J’ai déjà évoqué ici l’aspect technique des problèmes informatiques, mais aujourd’hui, je vais les prendre d’un côté qui m’intéresse encore plus – celui des gens – et esquisser l’organisation que nous avons testée pour affronter le problème insondable et universel des incidents informatiques. Je rédige ce billet après avoir pris le temps (deux petites années) de constater des résultats plus encourageants que ceux des tentatives précédentes.

Photographie d'un écran d'ordinateur manifestement hors service, montrant des tâches de couleurs géométriques aléatoires
Photo Mark Couvillion LOGOCCby-nc-nd.eu

 

 

 

L’énoncé

Il y a trois ans, je considérais, au quotidien, la maintenance informatique comme le principal problème de mon service. Ce problème avait deux facettes :

1 – côté pile (les BU) : des sollicitations très fréquentes, de toutes provenances (15 sites à Clermont, environ 100 personnes susceptibles de faire appel à la bibnum via une adresse générique, et qui ne s’en privaient pas) et généralement urgentes car quand ça ne marche pas, c’est toujours urgent. Et l’impression diffuse, chez tout le monde, qu’en réalité ça ne « marchait » jamais vraiment, ou jamais longtemps.

2 – côté face (la bibnum) : un sentiment de surcharge et d’impuissance. La bibliothèque numérique n’arrivait pas à traiter des problèmes trop nombreux, d’importance inégale mais toujours pressants, et peinait à se consacrer aux chantiers de fond permettant d’améliorer l’état général du réseau et des machines, ce qui entretenait un cercle vicieux très déplaisant.

Il y avait eu les essais de solutions techniques (déploiement d’outils de télémaintenance, par exemple) ; les essais d’organisation (arrêt de la tournée hebdomadaire jamais suffisante, pour passer à des déplacements « à la demande » pas plus suffisants). Rien de tout cela n’était parvenu à éliminer une frustration qui pourrait se résumer, côté face, par une apostrophe du genre « mais qu’est-ce qu’ils f… à la bibnum ? »2 et symétriquement, côté pile, par le cruel aphorisme informaticien : « En général, le problème se situe entre la chaise et le clavier »3.

La méthode

Concluant après ces essais insatisfaisants qu’il fallait emprunter une direction différente, nous avons décidé en 2013 de modifier plus radicalement le fonctionnement de l’informatique de proximité. Les objectifs pouvaient être résumés comme suit :

1 – côté pile (les BU) : résoudre plus vite les problèmes de premier niveau (connexion d’imprimante, pépin bureautique, perte de « raccourci bureau », installation de logiciel etc.) ;
2 – côté face (la bibnum) : avoir un canal d’information unique, naturel et régulier entre la bibliothèque numérique et les BU, pour canaliser le flot des demandes ;
3 – ET SURTOUT : inciter le côté pile à regarder en face, et le côté face à jeter un œil sous la pile. C’est-à-dire, en gros, améliorer la compréhension de l’informatique chez les bibliothécaires et améliorer chez les informaticiens la connaissance des bibliothèques et de leurs besoins, à la fois pour gagner en efficacité et pour améliorer les relations.

Les moyens déployés étaient simples, mais robustes, donc assez exigeants en temps pour les collègues concernés :

1 – dans les cinq principales BU, cinq collègues (administratifs, magasiniers ou bibliothécaires adjoints spécialisés) ont vu arriver dans leur fiche de poste 30% de temps de travail en tant que « correspondant informatique » ;
2 – à la bibliothèque numérique, des ateliers internes de formation intensive pour ces correspondants ont été organisés par les informaticiens, à raison d’une matinée toutes les trois semaines tout l’automne 2013, puis d’une matinée par mois le restant de l’année4. Les ateliers allaient de la prise en main de l’ENT et des listes de diffusion à l’architecture des serveurs, en passant par les questions bureautiques (la BCU travaillant avec la bureautique libre depuis 2012, il y avait matière), la maintenance des postes sous Windows (parc professionnel) et sous Linux (parc public), sans oublier le maniement des copieurs multifonctions, très sollicités par les utilisateurs et sources de fréquents incidents, et tous les incidents rencontrés entre deux ateliers par nos collègues ;
3 – Le tout agrémenté de quelques procédures pour trois ou quatre urgences identifiées, et d’une liste de diffusion commune aux informaticiens et aux correspondants pour faciliter les échanges d’informations au sein de ce groupe.

Les résultats

Deux ans ont passé, et, pour le dire en bref, « ça va mieux ». Il me semble qu’il existe aujourd’hui une culture d’équipe commune aux correspondants informatiques et aux informaticiens. De ce fait, l’informatique ne passe plus pour inabordable, et nos collègues en BU ne passent plus pour incapables de s’y frotter, puisqu’ils prouvent chaque jour leur aptitude à traiter des questions informatiques, en lien avec les informaticiens, mais d’une façon souvent autonome. La charge de travail est parfois lourde sur leurs épaules, mais elle vient aussi renforcer la solidarité entre eux et la bibliothèque numérique : en mesurant la charge et en la partageant avec les informaticiens, ils mesurent l’attente à laquelle une équipe informatique doit répondre, et par conséquent ils mesurent à quel point le rôle qu’ils assument est indispensable pour la bonne marche de l’informatique.
Dans le même temps, les capacités d’intervention dans le domaine informatique se trouvent démultipliées. Et même si je n’irais pas rêver que le nombre d’incidents a diminué5, je pense qu’ils sont tout de même traités mieux, plus vite, et d’une façon plus durable (la proximité permettant l’apprentissage entre le correspondant et les collègues de son service).

La conclusion

Nous pensions que les tensions qui se manifestaient parfois entre nous et nos collègues étaient liées à des manquements techniques. Expérience faite, je suis à peu près persuadé que nous avions pris la cause pour l’effet, et que c’était la difficulté à échanger de façon efficace sur des problèmes normaux et inévitables, qui aggravait des incidents banals et bénins en eux-mêmes.
Le titre de ce billet est un mensonge, bien sûr : nous n’avons pas créé une espèce professionnelle hybride, un mélange de bibliothécaire et d’informaticien6. L’informatique que les bibliothécaires ont besoin de maîtriser est une informatique d’utilisateur éclairé7, non de professionnel de l’informatique. Disons que nous avons essayé de faire passer entre les deux, par capillarité, juste ce qu’il faut de compétence et de familiarité pour que chacun fasse mieux SON métier.
Et même si ce n’est presque rien, ça change tout, car désormais, si l’on veut bien m’autoriser une conclusive, capillaire et consternante boutade8 : la pile sait face, et la face sait pile.

Tony Delgrosso, Lazy
Tony Delgrosso, Lazy LOGOCCby-nc-sa.eu 

 

 

 

  1. Je me compte dans le lot, bien qu’ayant plutôt progressé depuis quelques années. []
  2. Qu’il soit clair que je ne l’ai jamais entendue : le Bougnat, parfois rude, reste toujours courtois ; mais disons que nos échanges en réunion de service me donnaient à penser que ce genre de réflexion devait parfois, dans des moments d’extrême détresse, traverser fugitivement l’esprit de mes collègues. []
  3. Que je n’ai jamais entendu non plus, bien sûr ; j’imagine, simplement qu’il aurait pu être prononcé dans un moment de lassitude, par exemple un vendredi après-midi un peu tard en raccrochant le téléphone après une demi-heure de questions-réponses. []
  4. Le système a été reconduit cette année avec un rythme mensuel []
  5. Cela me paraît statistiquement peu probable. []
  6. Il en existe sans doute, mais on ne peut les cloner à volonté. []
  7. Là aussi, je me compte du nombre. []
  8. N’en déduisez pas trop vite que nos informaticiens se rasent ou n’ont plus rien à faire ! Disons qu’ils peuvent se consacrer davantage à des travaux de fond. []

L’informatique n’est pas un problème

À Clermont-Ferrand, le numérique est une affaire qui marche. Une bibliothèque de production, un site web développé en interne, un outil de découverte, et même un blog, c’est dire que l’informatique ne nous inspire aucune crainte. Il y a d’ailleurs une bonne raison à cela, c’est qu’elle ne nous pose aucun problème. Nos serveurs sont sûrs, notre réseau ne connaît pas la lenteur ni nos machines la panne ; nos utilisateurs sont assez experts pour résoudre seuls les très rares problèmes qu’ils rencontrent, et nos imprimantes ne manquent jamais de toner. Et il fait toujours beau chez nous.

 Ceux qui ont vraiment besoin de croire que tout va bien quelque part vont devoir arrêter ici leur lecture. Ceux qui préfèrent la réalité sont invités à poursuivre1.

Blue screen of death, par JackAce, publié sur FlickR sous licence Creative Commons: attribution ; pas d'utilisation commerciale.
Blue screen of death, par JackAce, publié sur FlickR sous licence Creative Commons: attribution ; pas d’utilisation commerciale.

L’avisé lecteur aura noté comment le premier paragraphe de ce billet, entamé sur un raccourci optimiste, glisse vers la franche exagération pour s’achever en galéjade grossière2. Revenons donc bravement à la réalité: à Clermont comme ailleurs, l’informatique pose régulièrement des problèmes. Régulièrement, mais particulièrement ces derniers temps. Il n’est pas inutile d’en faire état ici, d’abord parce que la première condition pour affronter sainement un problème est de l’autoriser à exister ; ensuite parce que ce blog est un outil de travail, non de propagande ; enfin pour remonter le moral des collègues (car il y en a peut-être ailleurs qu’ici) qui auraient connu un jour ou l’autre des problèmes informatiques : vous n’êtes pas seuls.

 Qu’il y ait des pannes est prévisible ; pourtant tout est imprévisible dans une panne : moment précis, causes exactes, élément déclencheur, temps de traitement; et récurrence, hélas. Ici, il y a longtemps que les incidents informatiques ne s’étaient succédé si nombreux en si peu de temps. Pour éviter de sombrer dans la superstition, je tiens ferme la loi des probabilités, qui prouve que le hasard suffit à expliquer les salves d’accidents, et dispense d’avoir recours aux explications astrales, à la malédiction divine ou à la malveillance de la NSA voire du voisin de bureau dans les cas extrêmes3.

Mais venons-en à notre petite série noire locale, trois grosses pannes en un mois.

  • le 10 décembre dernier, le site « enfance violence exil », hébergé et administré par la BCU, ne peut plus être affiché en raison d’un grave problème de sécurité informatique. Une solution improbable jaillit mi-janvier, alors que l’on s’apprêtait à entamer la réécriture du site, soit plusieurs semaines de chantier, au désespoir des chercheurs privés de leur outil de travail et de communication scientifique et pédagogique.
  • 16 décembre, à l’issue d’une mise à jour de routine, perte du contenu de 12 serveurs virtuels dont ceux qui portaient l’accès professionnel à notre système de gestion, le site web et notre outil de découverte. Le contenu est restauré quasi-intégralement en trois jours grâce aux sauvegardes automatiques, mais l’infrastructure n’est pas encore remise en place à ce jour : trois disques étaient défectueux et leur remplacement prend du temps. La machine de secours est située dans nos locaux, dont l’installation électrique est fragile… Une coupure de courant début janvier, à la fin des congés de Noël, provoque l’extinction du site web et du catalogue pendant deux jours, jusqu’à la réouverture.
  • 13 janvier, un disque dur externe à grande capacité contenant plusieurs mois de travail de numérisation cesse de fonctionner. Pas de perte de données à craindre a priori, mais en attendant que l’on puisse s’attaquer au problème (après avoir fini le déblaiement du précédent), la chaîne de numérisation tourne au ralenti.

Je passe sur les pannes et ralentissements quotidiens plus ou moins consécutifs aux précédents et qui ont égayé janvier : tandis que l’on répare les dégâts, les services tournent vaille que vaille sur des machines de remplacement, un peu anciennes. Cela ne va pas sans lenteurs ni coupures. À présent que l’on commence (restons prudents) à voir le bout du tunnel, quelles leçons tirer de cette rude série ?

 Peut-on rendre la technique fiable ?

 Bon gré mal gré, nous vivons sous le règne des serveurs. Dossiers et outils quittent nos ordinateurs personnels pour des machines plus puissantes et plus lointaines. Aujourd’hui, la BCU utilise des machines situés au CRRI (sur notre campus, mais hors de nos locaux) pour tous ses services critiques : SIGB, site web et intranet, outil de découverte, serveur de diffusion local des thèses. Elle recourt à l’hébergement externe pour le catalogue des revues en ligne et le résolveur de liens, la diffusion des thèses et articles (via HAL et TEL), ses blogs 14-18 et Alambic, et un jour prochain pour le SGB mutualisé.

 Cette organisation a son intérêt (les données sont abondantes et faciles d’accès), et son prix : toute panne a des conséquences collectives, voire massives. Qu’une machine cesse de fonctionner, les utilisateurs pénalisés sont dix fois, mille fois plus nombreux qu’avant. Il faut donc, selon le terme consacré, sécuriser les serveurs. Contre la panne électrique, contre la panne de climatisation, contre l’attaque informatique, contre l’avarie matérielle, contre le bug logiciel, contre la perte de données… Comme toute organisation utilisant abondamment l’informatique, la BCU a subi, tour à tour, chacune de ces pannes. Seuls des ensembles techniques colossaux peuvent déployer les moyens nécessaires pour satisfaire un besoin infini de stabilité technique. « Google ne s’arrête jamais » (encore que… mais si, même Google a connu deux pannes !) mais Google a un million de serveurs.

Bien qu’en dix ans la BCU ait multiplié par 12 le nombre de ses serveurs (passant de 2 à 24 !), nous cherchons la stabilité à une échelle quasi-dérisoire. Notre meilleure défense contre la panne est donc de nous appuyer sur des organisations matérielles plus robustes que la nôtre. Déplacement des machines vers le centre de ressources informatiques local (pour parer aux problèmes d’électricité et de climatisation), virtualisation et mise en place d’un outil global de sauvegarde (pour éviter les pertes de données), hébergement des services web dans de grandes infrastructures (CINES, CCSD, etc.). Tout cela prend du temps et demande aux informaticiens un travail d’adaptation qui ne finira qu’avec l’informatique elle-même. Pas tout de suite, donc, sauf imprévu.

« Mais qu’est-ce qui se passe ? »

 Le drame d’une panne, c’est moins la perte de données, généralement réduite, que le temps passé à réparer, durant lequel le service fait défaut, et durant lequel des dizaines de personnes réduites à l’impuissance attendent et se demandent ce que font les informaticiens (restons polis). Or, lorsqu’un informaticien sue sang et eau pour résoudre un problème le plus vite possible, il lui est difficile de s’adresser en même temps aux utilisateurs pour expliquer ce qui se passe, plus encore de leur prédire avec réalisme le retour au service normal.

C’est pourtant la première demande, et presque la seule en fait, des utilisateurs : savoir ce qui se passe et, surtout quand ça va remarcher. La seule (mais bien réelle) utilité des non-informaticiens de la bibliothèque numérique pendant les pannes informatiques est donc de brosser, pendant que les informaticiens travaillent, des points de situation honnêtes et des pronostics prudents. Puis, une fois le service rétabli, un compte rendu de ce qui s’est passé (et/ou un billet de blog), pour ceux qui ont envie de comprendre. Tant vis-à-vis de nos collègues ou du monde extérieur, l’exercice est à la fois indispensable et salutaire. Indispensable, parce que cacher nos problèmes est illusoire quand plus personne ne peut travailler, et que les exposer nous confère au moins le mérite de l’honnêteté, nous assurant autant de compréhension que le permet la frustration endurée par nos collègues ; salutaire, parce qu’il nous pousse à un diagnostic plus approfondi et plus fiable, car dégagé de la crainte superflue de perdre la face.

L’informatique n’est pas un problème. C’est un outil puissant, limité seulement par nos propres limites. Je crains que ce ne soit incurable.

 

  1. La vérité vous rendra libres ; mais il se pourrait que la vérité soit un peu triste. []
  2. je parle du toner, bien sûr ; l’information météorologique relève de la plus pure bonne foi. []
  3. je précise que ce dernier cas est purement théorique ; j’ai déjà dit ailleurs que mes collègues étaient parfaits et je le maintiens ; cela tient sans doute à la météo, cf. le premier paragraphe de ce billet. []

Omeka, une bibliothèque numérique prête à l’emploi

Omeka est un logiciel libre, sous licence GPL, développé par le Center for History and new Media. Selon leur site, Omeka est au croisement des CMS, des gestionnaires de collections numériques et des logiciels d’archives. Nous l’avons utilisé pour exposer les carnets de Philippe Glangeaud. Voici un retour sur ses fonctionnalités.

Facilité d’utilisation

Logo de Omeka
Logo de Omeka

La caractéristique principale d’Omeka est d’être rapide à prendre en main. Son principe est simple : il gère des « items » qui peuvent être attachés à une collection. Chaque item, que l’on peut comparer à une notice de catalogue, est décrit en dublincore et dispose d’un ou plusieurs documents numériques attachés. On peut ajouter également des données techniques sur ces fichiers dans la liste des métadonnées.
Un système de tags permet d’indexer ces éléments et de naviguer ainsi entre les collections.

À côté de ce service de base, on peut enrichir cet outil à l’aide de plusieurs modules proposés sur son site web. L’entrepôt OAI ou l’extension exhibit font partie des incontournables. Lincoln at 200 est un bel exemple des possibilités du module exposition. Chaque item ou collection peuvent être mis en valeur dans une galerie d’images complétées d’un texte d’illustration. Ce fonctionnement par briques rappel celui de Drupal mais dans le cas d’Omeka sa simplicité d’utilisation l’emporte aisément sur le CMS à la goutte d’eau.

Du côté technique

Les développeurs de cette bibliothèque numérique l’on rendu très flexible et souple d’emploi. On peut créer sans difficulté une extension qui étend ses capacités de base et on peut créer un nouveau thème sans être féru de développement web.
Quand nous nous étions intéressés à Omeka il y a quelque temps pour les carnets de géologie, il n’avait pas autant d’envergure. Les versions se sont succédées depuis et de nouvelles extensions ont vu le jour comme PDF search qui permet la recherche plein texte dans ce type de fichier.

Désormais, des projets importants comme la digital public library of america utilisent un moteur de recherche à facettes et hébergent de grandes quantités de notices et documents.

Vous pouvez même l’utiliser sans avoir un serveur et un développeur chez vous grâce à leur plateforme en ligne omeka.net. Il ne vous reste plus qu’à créer en un tour de clic, une exposition virtuelle à l’instar de ces musées ou universités américains.

Outil de découverte libre : un schéma pour y voir plus clair

Après le poster réalisé pour les journées ABES, et plusieurs billets sur l’alambic, voici un schéma plus détaillé de notre outil de découverte. Il présente avec plus de précisions les relations techniques entre notre catalogue Absysnet et l’installation de Blacklight. Un billet très court donc, mais parfois, un dessin vaut mieux qu’une longue explication.

Schéma de l'outil de découverte libre de la BCU
Schéma de l’outil de découverte libre de la BCU

 

Qu’est-ce qu’une solution élégante en programmation ?

Aujourd’hui, nous abordons la question de l’élégance d’un code informatique. Pour parler des coulisses d’un logiciel ou d’un site web, on utiliserait plutôt les expressions « mettre les mains dans le cambouis » ou « regarder sous le capot ». L’esthétique du sujet étant peu évidente de prime abord. Tentons de voir les lignes de code sous un autre jour.
Fractal vegetable
Fractal vegetable – Par Rum Bucolic Ape sur flickr – licence CC BY-ND 2.0

Pour commencer, un langage informatique a des similitudes avec celui d’une langue parlée. Il a des règles de syntaxe et d’orthographe très précises.
Ainsi, comme il y a de belles écritures manuscrites tant par leur forme que par leur style, il y a de gracieuses manières de disposer les caractères à l’écran, de choisir ses mots, appelés instructions.

Les développeurs inventent même des conventions dédiées à leurs logiciels. Drupal a par exemple des règles de codage qu’il est conseillé de suivre quand on est un de ses contributeurs.
La longueur des lignes, la taille des espacements, la disposition des instructions sont ainsi définies et utilisées par les « drupaliens ».

Il est alors plaisant visuellement d’avoir à parcourir un fichier bien structuré plutôt qu’un méli-mélo de sigles disparates. Il va de soi qu’un code bien présenté est aussi plus facile à comprendre et à modifier. Il existe différents styles de présentation associés ou non à un langage particulier.

Écrire de manière ramassée

À coté de cet aspect formel, le style de codage compte beaucoup dans l’appréciation d’un programme. Il y a souvent plusieurs façons de résoudre un problème et en règle générale, une solution courte est plus appréciée par un développeur soucieux de bien faire les choses.
Pour coder « joliment », l’informaticien dispose parfois de raccourcis syntaxiques permettant d’exprimer rapidement ce qui aurait nécessité un plus long développement en temps normal.

Mais attention, comme il peut-être inconvenant d’avoir à lire un texte écrit façon « sms », la concision en informatique n’est pas toujours gage d’un travail compréhensible.
Il y a un équilibre à trouver entre simplicité et lisibilité qui permet la reprise et la lecture du programme par d’autres personnes. Permettre le partage du code participe aussi à sa qualité.

Concevoir avec astuce et habileté

Un programme succinct sera souvent plus efficace en terme de temps d’exécution. Il est également plus satisfaisant intellectuellement de trouver une solution bien conçue et précise.
Faire preuve d’astuce et d’invention, éviter les répétitions inutiles, trouver un enchaînement logique des commandes, garder seulement les étapes indispensables comportent une certaine beauté à l’instar d’une démonstration mathématique ou d’un raisonnement argumenté.

Tout le monde connaît par exemple l’histoire de l’aiguille dans la botte de foin. Pour la résoudre vous pouvez, avec beaucoup de cœur à l’ouvrage, enlever les brindilles une à une. Il est plus aisé de mettre le feu à la meule et tamiser les cendres pour retrouver aisément le petit bout de métal.
C’est ce genre de résolution habile qui participe à l’élégance de la solution trouvée.

Du fractal au chou romanesco

Fractals
Fractals – Sur flickr par cowicide – licence CC BY-NC 2.0

Les informaticiens ont à leur service un autre outil que vous connaissez peut-être sans le savoir : la récursivité.
On la trouve dans la nature sous la forme de la structure harmonieuse et équilibrée d’un flocon de neige ou celle du chou romanesco.
L’image fractale ci-contre en est un autre exemple où l’on voit un motif se répéter à l’intérieur de lui-même. Cette notion existe en mathématique, en linguistique, en biologie, dans les arts, et en informatique…

Le principe est simple en apparence, un programme récursif est un programme qui s’appelle lui-même.

Si vous aviez à calculer la hauteur cumulée d’une poupée russe et de ses descendantes, vous pourriez les aligner les unes à coté des autres.
Puis les mesurer chacune à leur tour pour trouver la hauteur totale, mais ce n’est pas satisfaisant.

Si vous êtes plus inventif vous allez utiliser une boucle en ordonnant au programme de parcourir toute la série de poupées gigogne, de mesurer leur taille respective et calculer le résultat que l’on souhaite.

Mais il y a une solution plus astucieuse avec la récursivité.
Vous mesurerez la figurine la plus petite, le travail est minimal, et appellerez votre programme sur toute la collection en lui donnant l’instruction suivante : la hauteur d’une poupée russe est une fois et demi plus grande que sa première fille.

Avec cette relation générale, votre script commencera par la poupée la plus grande, puis continuera avec la suivante en enregistrant le rapport entre les deux. Et ainsi de suite, jusqu’à l’ultime poupée dont il connaît la taille exacte. Alors, il pourra remonter la file des relations entre matriochkas et donner un calcul juste à partir de cette valeur terminale.

En conclusion

Voilà pour cette tentative d’éclairer « l’écriture informatique » sous un angle différent. Il n’y a évidemment pas de réponse universelle à cette question. C’est une affaire largement subjective et la beauté d’une solution informatique n’est pas tant dans l’enchaînement des caractères numériques que dans l’intention du codeur de rendre les choses agréables.

Pour finir, vous trouverez sur le site « 99 bottles of beer« , les différentes versions d’un algorithme écrit dans 1500 langages et générant les paroles de cette chanson. Alors, quel est selon vous le langage le plus esthétique ?

Feriez-vous un bon développeur web ?

La frontière étant désormais bien floue entre savoirs des bibliothèques et monde numérique, vous envisagez peut-être d’élargir vos aptitudes à l’informatique. Afin de vous aider à répondre à la question du titre, voici une tentative subjective de décrire le métier du développement web.
Sans titre - Par Ricardo Machado - Sur Flickr - CC BY-NC-ND 2.0
Sans titre – Par Ricardo Machado – Sur Flickr – CC BY-NC-ND 2.0

Commençons par une définition. Si l’on en croit cette fiche du Gdt, le développeur intervient sur toute la chaîne de réalisation d’un logiciel. Pour faire simple, il s’occupe de traduire un problème en termes informatiques.
Laissons d’emblée de côté l’image usuelle de la personne absorbée derrière un écran parcouru par les lignes d’un code indéchiffrable. La totalité de ce processus implique de collaborer avec plusieurs personnes et pas forcément avec l’aide d’un ordinateur. Lors du travail préliminaire d’analyse et de conception vous serez amené à beaucoup échanger avec vos collègues.

Ceci étant dit vous aurez besoin de faire preuve d’une grande autonomie. La majeure partie de cette activité consiste à corriger des erreurs et résoudre des problèmes. La phase de réalisation et création n’est que la partie émergée de l’iceberg.
D’ailleurs, sans avoir fait de longues études de programmation vous en viendrez vite à penser que l’informatique n’est pas une science exacte. Les mauvaises langues diront même que ce constat est un euphémisme mais nous ne commenterons pas.

Trouver sa place

La définition précédente est un peu trop générale car la réalisation d’un site web moderne fait appel à toute une palette de savoirs. L’ergonome permet à l’utilisateur de naviguer de façon intuitive, le graphiste propose un habillage agréable à visiter et à regarder, l’expert accessibilité indique comment rendre les pages praticables par tout le monde quelque soit son support de navigation. N’oublions pas le webmestre qui vérifie la qualité des contenus, le chef de projet pour organiser tout ce beau monde, etc.

Las, abandonnez vos rêves de toute puissance, vous ne serez pas seul pour dire « c’est moi qui l’ai fait ! ». Réjouissez-vous plutôt qu’on ne vous demande pas de maîtriser tous ces domaines riches et inépuisables. Pourtant, il est fortement recommandé d’en connaître les principales fondations. Ne serait-ce que pour travailler de concert avec tous les professionnels impliqués.

Cela demandera du temps et pour compliquer la tâche les connaissances sont rarement figées. En guise d’exemple, vous avez peut-être déjà connu les longs débats pour savoir si il faut ouvrir un lien dans une nouvelle fenêtre du navigateur ou non… Il vous faudra alors lire, comparer, garder un esprit critique et trouver des solutions qui satisfont au mieux les multiples exigences rencontrées.

Rendre les choses belles

Cette petite introduction ne vous donnera sans doute pas l’envie de changer de carrière pour autant. En revanche, si vous aimez le travail bien fait et que pour vous la manière compte au moins autant que le résultat alors vous serez comblé par tout ce qu’offre cette activité.
Comme dans beaucoup de domaines, il y a des bonnes pratiques et, malheureusement, de nombreuses mauvaises manières de faire également. Libre à vous de choisir les autoroutes du  moins disant ou les sentiers escarpés des solutions plus élégantes.

Prenons le cas du langage HTML. Avec cette figure de proue  du WEB, il est possible de baliser de manière très incorrecte une page. On parle alors de « soupe de balise ». Un développeur averti respectera au mieux la sémantique du texte qui n’en sera que mieux référencé. Il aura plaisir à utiliser une balise de titre pour un titre ou une balise de paragraphe pour un paragraphe. Ne souriez pas à cette apparente évidence, on trouve parfois des syntaxes étranges lors de l’inspection d’un code source.

D’un code explicite à l’accessibilité pour tous

De manière générale, vous aurez à cœur de rendre votre code beau et soigné. Il sera alors plutôt concis et facile à lire. Personne ne vous y obligera mais imaginez-vous que vous ayez à offrir un code du travail ou une lettre sympathique à un ami. Tous deux sont des textes, mais l’un est un plus beau don que l’autre. C’est une affaire de goût aussi.
Il existe également de la poésie informatique mais restons lucides, elle n’est pas encore enseignée sur les bancs de la faculté.

Enfin, nostalgique des premières heures du web, vous voudrez rendre votre site ouvert et accessible à tous, en particulier aux personnes handicapées. Malheureusement, ce domaine est un peu le parent pauvre de la toile. Il vient souvent à la fin des discussions et ne dispose pas toujours du temps qu’il mériterait. Mais ne désespérons pas des grandes causes. Rien ne vous empêchera de souffler discrètement ce sujet fragile sur la table des discussions de temps à autre. À cœur vaillant rien d’impossible.

Il y aurait sans doute d’autres choses à dire mais peut-être en savez-vous suffisamment, et la réponse vous appartient. Alors, feriez-vous un bon développeur web ?

Blacklight : déploiement avec Ruby On Rails

Du serveur de développement au serveur de production, intéressons-nous maintenant aux grandes étapes de la mise en ligne de Blacklight. Nous avions commencé cette série par une prise en main de ce logiciel, puis par l’ajout des données d’exemplaire et enfin l’activation des services au lecteur. Les développeurs pourront compléter ce billet avec cette procédure détaillée.
Gaivota Bird oiseau Vogel uccello aves 鳥 птица – Sur Flickr par Rodrigo Sá – Licence CC BY 2.0

Déployer Blacklight offre plusieurs avantages. Tout d’abord, son serveur web proposé par défaut n’est pas assez robuste pour une mise en ligne. Nous devons donc en installer un nouveau à même d’assurer un nombre de visites élevé. Ce sera Apache avec le module Passenger.

Apache n’est plus à présenter dans le monde du développement web. Quant à Passenger, il s’agit d’un programme adossé à Apache pour rendre accessible en ligne une application faite avec Ruby On Rails. C’est une architecture complexe.

Si l’on récapitule :

  • Ruby est un langage de programmation.
  • Ruby on Rails est un framework, construit avec Ruby.
  • Blacklight est un moteur de recherche construit avec Ruby On Rails.
  • Apache et Passenger sont un serveur web mettant en ligne un logiciel fait avec Ruby On Rails, en l’occurrence : Blacklight !

Outils pour une maintenance aisée

Ces composants sont obligatoires pour rendre disponible notre nouveau catalogue. Nous utiliserons également Capistrano et Git pour faciliter les mises à jour du serveur de départ au serveur d’arrivée.
En revanche, ces deux derniers programmes ne sont pas nécessaires. Le déploiement peut se faire en copiant simplement les fichiers sur le serveur d’arrivée. Pourtant, même en étant un adepte féru de simplicité, leur relative complexité de prise en main est largement pondérée par ce qu’ils apportent.

Git pour garder un historique

Git, que l’on configure sur le serveur de développement, est un outil désormais prisé pour la gestion de versions. Il va nous permettre d’archiver toutes les étapes des développements ultérieurs. On pourra l’utiliser également pour rétablir une version antérieure de notre catalogue en cas de problèmes de mise à jour par exemple.

Déployer avec Capistrano

Capistrano est un logiciel écrit en Ruby permettant le déploiement automatisé d’une application d’une machine à une autre. Depuis le serveur de travail, il va se charger, avec très peu d’instructions de notre part, de déployer Blacklight en ligne, de passer d’une version à l’autre, ou de le mettre à jour aisément.

Il n’est pas simple dans cette nébuleuse d’utilitaires, modules, applications, serveurs de voir qui fait quoi et à quoi ça sert. Au final, on finit par l’oublier et ses avantages permettent de se concentrer plus profondément sur l’amélioration de Blacklight.

Voilà, notre catalogue est en ligne… Ah non me dit-on ! Il reste encore quelques menus détails à régler, mais bientôt Blacklight sortira en pleine lumière à la BCU…

Garder sa distribution GNU/Linux propre comme un sou neuf (deuxième partie)

Vous qui lisez ce blog régulièrement, vous vous rappellerez sans doute qu’il y a déjà quelques mois je m’étais intéressé à différentes méthodes visant à maintenir propre et net son système GNU/Linux… C’était dans ce billet et il n’y était guère question que de lignes de commandes.

Nous allons cette fois-ci et comme promis en conclusion du précédent article, nous orienter vers les applications graphiques. Comme toujours ce sont les distributions Debian/Ubuntu qui ont mes faveurs mais la plupart de ces outils sont présents ou installables sur bon nombre de systèmes Linux.

L’avantage de ces outils graphiques réside essentiellement dans leur ergonomie, qui leur permet de gérer simultanément une grande quantité de paramètres, mais comme toujours ils peuvent être utilisables eux-même en ligne de commande ou n’être simplement qu’une interface graphique à une ou plusieurs commandes préexistantes, comme l’est par exemple Gtkorphan pour deborphan

Suppression des fichiers de configuration dans Synaptic
Suppression des fichiers de configuration dans Synaptic

Tout nettoyage efficace commence par la purge des paquets obsolètes ou superflus et l’on dispose pour cela de synaptic et computer-janitor ; certes ce dernier n’est plus installé automatiquement sur les dernières versions d’Ubuntu, mais il n’en reste pas moins dans les dépots…

Le bouton État de Synaptic est particulièrement intéressant au sens ou il permet de connaitre immédiatement le statut des paquets et partant de faire des suppressions plutôt « intelligentes » notamment pour les paquets « pouvant être supprimés » (orphelins) ou encore les « résidus de configurations » . Il faut toujours garder à l’esprit que Synaptic est une GUI (Graphic User Interface) pour apt-get et que tout comme cette commande il ne gère pas la suppression automatique des dépendances ; de même pour obtenir l’équivalent de l’option purge il faudra sélectionner les paquets « pour une suppression complète » et il se chargera alors d’éliminer également les fichiers de configuration…

Nettoyage du système
Nettoyage du système 

D’une façon un peu plus automatique mais aussi plus opaque à l’utilisateur on peut également utiliser l’application identifiée par Nettoyage du système alias computer-janitor dans le menu administration…

Cette application traquera pour vous dans les confins du système tout à la fois les paquets inutiles, les fichiers de configurations orphelins et les anciens noyaux…

Petite limite selon moi à son intérêt et à son utilisation (ce qui explique certainement son retrait des applications installées automatiquement par le système), l’impossibilité pour l’utilisateur d’intervenir sur son mode de sélection ou son paramétrage, hormis la liste finale…

Nettoyage des librairies orphelines
Nettoyage des librairies orphelines

Un autre de ces outils fort utiles pour débarrasser son système des paquets superflus est Gtkorphan, GUI de la commande deborphan, permettant d’indiquer facilement via un menu le type de fichiers ou de bibliothèques orphelines que l’on souhaite effacer.

Ce n’est d’ailleurs pas la sa seule qualité, car l’éventail et la modularité des options est particulièrement riche. On peut spécifier en effet si l’on souhaite rechercher là encore les fichiers de configuration non effacés par une suppression de paquet ou choisir le type de librairies orphelines à enlever, de celles relatives à python, à perl, etc,  jusqu’à la totalité, soit l’équivalent d’un deborphan –guess-all en ligne de commande.

Par ailleurs, puisque l’on fait le ménage dans le système de paquetage logiciel, il est de bon ton de vider son cache ce qui peut faire gagner à terme quelques centaines de méga-octets d’espace disque. Synaptic peut le faire si on le lui spécifie dans ses options mais d’autres outils à vocation plus générale le font également : c’est ceux-ci que nous allons aborder à présent.

Nettoyage avec Bleachbit
Nettoyage avec Bleachbit

Bleachbit est ce que l’on pourrait qualifier de nettoyeur à tout faire, s’agissant des historiques, caches et répertoires temporaires divers. A noter que deux modes de fonctionnement sont possibles : un mode utilisateur plutôt orienté vidage de caches et un mode root plus ciblé sur le nettoyage système (cache des paquets, vidage de /tmp et des journaux système, traductions inutiles, etc) et toutes choses requérant les attributions de l’administrateur. Ce dernier mode est particulièrement efficace pour se défaire des fichiers d’internationalisation non supprimés par localepurge, avec une fois de plus à la clé une quantité notable d’espace disque récupéré.

Fslint
Recherche de fichiers temporaires avec Fslint

 

Dans un registre un peu plus technique vient Fslint, utilisable également en ligne de commande.

Cet outil au demeurant hautement paramétrable et donc extrêmement polyvalent va quant à lui permettre de rechercher d’abord dans son home directory mais à priori partout où on le lui spécifiera les fichiers dupliqués, les répertoires vides, les fichiers temporaires ou encore les liens symboliques erronés… Le site doc.ubuntu-fr.org qualifie Fslint de couteau suisse et je partage amplement cet avis.

Enfin, pour conclure ce rapide tour d’horizon (non exhaustif) des outils graphiques, je vais simplement présenter deux applications disponibles uniquement sur Ubuntu que sont Ubuntu Tweak et Ailurus, encore que ce dernier fonctionne également sous Fedora. Ces deux utilitaires sont de véritables postes de commandes du système à la vocation beaucoup plus large que le simple nettoyage du système, même si elles intègrent en effet cette fonctionnalité. Dans les deux cas ces applications ne se trouvent pas sur les dépôts officiels et il faudra donc télécharger les .deb correspondant à sa version de distribution ainsi qu’à son architecture. D’une façon plus cohérente dans la mesure où on peut les trouver via launchpad on installera leur dépôt ppa au moyen de la commande add-apt-repository ce qui permettra des mises à jours et des suppressions aisées.

Il serait trop long et un peu vain de détailler ici le fonctionnement de ces deux applications dont le but est de paramétrer son système avec finesse ; les essayer est un bien meilleur révélateur. En guise de conclusion, quelques copies d’écran qui je l’espère vous donneront envie de le faire…

Nettoyage avec Ubuntu Tweak
Nettoyage avec Ubuntu Tweak

Ubuntu Tweak fait la part belle à la gestion des paquets, y compris les ppa et facilite la gestion des sources. Dans ses versions pour des distributions récentes, les fonctions de nettoyage s’étendent également aux caches des navigateurs, entre autres…
Il ne faut cependant pas négliger le reste de ses fonctionnalités, qui permettent d’accéder facilement à nombre de paramètres peu accessibles du système.

Fonctionnalité "ordinateur médecin" dans Ailurus.
Fonctionnalité « ordinateur médecin » dans Ailurus.

Ailurus est peu ou prou équivalent à Ubuntu Tweak sur bien des points, mais se veut néanmoins plus didactique dans son approche au sens où toutes les modifications effectuées sur le système sont explicitement décrites avec la ligne de commande correspondante.

Note : pour aller plus loin avec Ubuntu Tweak et Ailurus, je vous invite à consulter les pages consacrées à ces applications sur le site doc.ubuntu-fr.org.
Et toujours dans la catégorie bonnes lectures, je vous invite à consulter une série d’articles rédigés par Raphaël Herzog, par ailleurs auteur des Cahiers de l’Admin Debian, sur son blog :

Enfin, et j’en terminerai la dessus, maintenir un système en bon ordre de marche résulte nécessairement d’une démarche volontaire et de l’utilisation conjointe d’un certain nombre d’outils, graphiques ou non, et pour certains partiellement automatiques, mais toujours sans perdre de vue que c’est vous qui êtes aux commandes…

Blacklight, troisième partie : les services au lecteur

La série avait commencé par une présentation introductive puis par ce billet consacré aux données d’exemplaires, voyons dès à présent le problème des services aux lecteurs : renouvellement, liste des prêts en cours, demande de communication et réservation. Comment intégrer ces nouvelles possibilités à Blacklight (BL) ?

Serveur en tenue - Par telomi sur Flickr - Licence CC BY-NC-ND 2.0
Serveur en tenue – Par telomi sur Flickr – Licence CC BY-NC-ND 2.0

Appelons cela un problème, car la solution n’est pas totalement dans les mains de BL qui ne fournit pas d’outils pour se connecter à un catalogue. Pour bénéficier de toutes ces fonctionnalités utiles aux lecteurs, il faut un préalable évident : le SIGB interrogé doit proposer une interface permettant d’interroger ses services par des applications externes comme BL. Ce n’est pas toujours le cas et, pour nous, Absysnet ne dispose pas, par défaut, de telles interfaces. Heureusement, nous avons sous la main un programme répondant au doux nom de « zabnetarch », ajouté il y a quelques années à Absysnet par le prestataire pour l’intégration à notre défunt et regretté portail Archimed.

Ce programme est interrogeable via une connexion réseau simple TCP/IP. Nous lui passons des ordres rudimentaires du type : « donne moi les informations du lecteur possédant tel identifiant » ou encore « réserve cet exemplaire pour tel lecteur », et « zabnetarch » répond en XML en fournissant les données souhaitées ou un code explicite indiquant l’échec ou la réussite de la commande.

Quelques lignes de code pour finir

Une fois pris en main le fonctionnement de cette « API» minimaliste, il ne reste plus qu’à l’intégrer à BL. Avec Ruby On Rails, le principe est simple, il suffit d’ajouter un fichier avec des instructions en ruby dans le répertoire « models » de l’application. Pour chaque service (renouvellement, réservation, etc.) on ajoute une fonction dédiée dans notre fichier qui pourra être appelée par le programme qui gère l’utilisateur authentifié, offrant ainsi de nouveaux usages à l’intention du lecteur.

Désormais, nous avons intégré les données d’exemplaires, les services aux lecteurs fonctionnent, notre nouvel OPAC est presque prêt. La prochaine étape sera de déployer Blacklight sur son serveur définitif. Au menu, il sera question de capistrano, git, passenger mais nous verrons cela dans un prochain billet…

T’imprimes, t’imprimes, t’imprimes…

Le meurtre du photocopieur (photo Aaron Landry, publiée sur FlickR sous licence Creative Commons Paternité, Pas d’utilisation commerciale, Partage à l’identique).

Parfois, un détonnant mélange d’agacement et de frustration vous donne subitement envie de brutaliser un objet récalcitrant voire une personne, comme dans la scène désormais fameuse qui a prêté son titre à ce billet (notez qu’il est hautement incivil d’agir ainsi, sauf au cinéma où il est bien entendu que la victime est totalement antipathique alors que le bourreau est juste un grand bon garçon un peu vif). Je confesse avoir eu envie, à une ou deux reprises cette année, d’appliquer ce genre de traitement aux photocopieurs et autres lecteurs de cartes magnétiques de la BU.

Néanmoins, l’affaire s’étant soldée par le happy end auquel on était en droit d’aspirer (nos lecteurs peuvent imprimer et photocopier), la destruction du copieur-imprimeur restera à l’état d’éventualité inaccomplie.

Pour ceux qui aiment savoir que les histoires se terminent bien avant de les commencer, voici tout de suite l’épilogue : il est désormais possible d’imprimer ses documents à la B.U. sciences à l’aide d’une carte de photocopie. Les deux postes dédiés à l’impression sont situés au voisinage des photocopieurs, l’un au rez-de-chaussée, l’autre au deuxième étage. Il suffit d’ouvrir son document sur l’un de ces postes (via une clef USB, un espace de stockage sur le Web, un site, etc.) et de débloquer l’impression à l’aide de sa carte de photocopie. Le même système sera déployé prochainement dans les bibliothèques de lettres et de droit. Bref, photocopieur et imprimante se marièrent et engendrèrent des milliers et des milliers de pages.

À présent pour ceux qui veulent regarder dans les coulisses, voici la version longue
(âmes sensibles et lecteurs pressés s’abstenir).

Situation initiale : la B.U. de sciences était depuis plusieurs années à la recherche d’une solution simple pour permettre l’impression aux lecteurs. Le logiciel commercial mis en place il y a plusieurs années, assez coûteux, avait été abandonné quand quelque mise à jour fatale avait provoqué une incompatibilité. L’impression gratuite épuisait les budgets de consommables informatique et de papier, l’impression contrôlée par les bibliothécaires (déblocage depuis le poste de renseignement) épuisait le personnel sans satisfaire les lecteurs. Dans les autres bibliothèques, on avait abandonné l’impression, ou on la pratiquait à la demande de façon assez exceptionnelle.

En janvier 2012, Acte I, la bibnum lance une consultation tous azimuts sur la façon dont les B.U. gèrent l’impression. Parmi les retours, la solution venue de Nancy nous paraît la plus simple : dans chaque BU, un ou deux postes, couplés avec un photocopieur imprimante et un lecteur de cartes magnétiques, permet de faire à la fois les impressions et les copies.

  • C’est simple pour les lecteurs, puisqu’ils ont déjà une carte pour la photocopie. Plus besoin d’aller quémander au bureau de renseignements le déblocage de l’impression pour trois pages de documents administratifs.
  • C’est simple pour les BU puisque les photocopieurs sont déjà intégrés à un marché et qu’il suffit d’activer leur fonction « imprimante ». Fini le déblocage au coup par coup et l’inconfortable sensation garde-chiourmesque qu’il procure.
  • C’est simple pour la bibnum puisqu’en faisant porter la fonction d’imprimante par des copieurs dépendant d’un marché, nous nous déchargeons des problèmes de maintenance sur des machines qui sont à la fois rapides et robustes. Adieu les cinquante remplacements de cartouche par an !

Hélas, même une solution très simple peut être très compliquée à mettre en place.

Pas de chance, les copieurs présents dans le réseau dépendent de trois marchés différents, conclus auprès de deux fournisseurs. Il fallut donc identifier les fournisseurs qui géraient les copieurs présents en BU. Déveine, les machines présentes à la B.U. sciences ne dépendaient pas toutes du même. Il fallut donc exposer à chacun le système visé, pour savoir s’ils pouvaient le fournir. Hélas, cette solution est un peu inhabituelle (peut-être parce qu’elle est simple et peu coûteuse ?). Pour éviter tout malentendu (en fait, il y en avait un, bien sûr) avec le commercial-qui-dit-pas-de-souci, il fallut donc assister à la présentation d’une offre de type « serveur d’impression » et la refuser, puis préciser de nouveau la nature exacte de notre demande. Coup du sort, à la B.U. de sciences, les photocopieurs présents dépendaient d’un marché un peu ancien et n’étaient pas pourvus de carte réseau. Il fallut donc débloquer un budget non prévu pour l’opération d’installation des cartes réseau et des lecteurs de carte, et même pleurer misère auprès du commercial pour diminuer un peu la facture de la prestation, car l’argent manquait. Veine, il était d’humeur commerçante et consentit à nous faire une ristourne (ah, si seulement il travaillait chez Elsevier !).

Tout cela nous conduisit fin juillet. Vacances, entracte.

Fin août, acte II. Installation d’une carte réseau sur les copieurs disponibles, puis première tentative du technicien pour installer le nouveau lecteur de carte. Mauvais sort, l’impression fonctionnait, mais non la copie. C’étaient la connectique qui était défectueuse, ou pas du bon modèle, bref ça n’allait pas. Comble d’infortune, nous nous apercevions dans le même temps (mais ça, nous aurions dû nous en douter) que nos postes publics sous linux ne pourraient pas gérer le système de commande du boitier lecteur de carte, et que pour les postes dédiés à l’impression il faudrait donc rééquiper spécialement des machines en windows. Mi-septembre, second passage du technicien, avec les bons câbles : tout semblait fonctionner.

Et là, la tuile (alors que depuis le début, vous avez remarqué, tout marchait sans accroc) : le lecteur de carte considère comme des centimes d’euros les unités chargées dans les cartes des étudiants, et de ce fait, débite cinq unités par impression, puisque l’unité coûte cinq centimes. De ce fait, un étudiant qui a chargé 40 unités dans sa carte la découvre vide après avoir imprimé 8 pages. Séance de bidouillage autour de l’interface de gestion du lecteur de carte. On parvient à faire passer l’affichage en mode « unité » et à faire paser le tarif de l’impression à une unité. Demi-victoire, car les photocopies, elles, restent obstinément tarifées à 5 unités. Troisième passage du technicien : il s’avère que le firmware (j’ai appris un mot) qui gérait le lecteur de cartes était périmé et que le téléchargement d’une nouvelle version permet de paramétrer correctement les tarifs de copie ET d’impression.

Il y a maintenant une dizaine de jours que le système a été officiellement mis en service. Pour être tout à fait honnête, je dois mentionner qu’à l’heure où je boucle ce billet, il semblerait que certaines cartes soient encore débitées de 5 unités par copie. Mais aucun test, sous toutes les configurations possibles (carte ancienne ou nouvelle, chargement récent ou non, etc), n’a permis de reproduire ce bug. Je peux donc, dans l’immédiat, le considérer comme non avenu et vous renvoyer à l’épilogue ci-dessus.

Si le problème se confirme, lorsque nous l’aurons résolu je pourrai le documenter par un nouveau billet. Ou bien vous apprendrez peut-être, par le billet consterné d’un collègue, que le responsable de la bibliothèque numérique a été mis en examen pour photocopicide volontaire avec préméditation.

Série de l’été : un succès, un regret, un projet (2)

Pour continuer la série voici, en avant-première en exclusivité mondiale et en co-rédaction avec le chef, les impressions d’un membre de l’équipe informatique :

Un succès ? Les débuts prometteurs de la mise en place d’une gestion en série du parc informatique. En l’occurrence, pour la première fois, en l’espace d’une grosse semaine, 45 machines ont été réceptionnées, leurs disques durs clonés (grâce à Clonezilla), leur déploiement final opéré sur trois sites différents. Jusque récemment, du fait de l’éclatement géographique, le parc se gérait presque machine par machine. L’automatisation progressive de la gestion permet d’envisager plus sereinement les installations à venir, même si le volume de machines doit encore aller croissant pendant les prochaines années.

Un regret ? Devoir partir en congé sans avoir absolument bouclé certaines tâches prévues, ou en laissant quelques problèmes irrésolus : en l’occurrence, un petit problème d’attribution d’adresse IP empêche l’utilisation du logiciel de gestion SIFAC sur une machine, et il est désagréable de savoir une collègue embarrassée dans son travail par un pépin informatique… quand on consacre une bonne partie de son travail à les prévenir et à les combattre.

Path par "Glenngould" (publié sous pseudonyme sur FlickR, sous licence Creative Commons, Paternité)
Path par « Glenngould » (publié sous pseudonyme sur FlickR, sous licence Creative Commons, Paternité)

Un projet ? Le service ayant quelques idées de production vidéo pour l’an prochain, je souhaiterais m’y impliquer, en mettant à profit mon attrait personnel pour ce domaine et la pratique que j’en ai déjà, pour acquérir une meilleure maîtrise des outils et apporter ma contribution à un projet du service pour les usagers.

Bonnes vacances à tous !

Série de l’été : un succès, un regret, un projet (1)

C’est au tour du développeur de contribuer à la série de l’été.

Un succès

C’est encore un peu tôt pour parler de succès car il n’est pas terminé mais le chantier du nouvel OPAC basé sur Blacklight est à classer au rang des satisfactions. Au début du projet l’horizon était plutôt brumeux. Notre catalogue réticent à la connexion d’applications externes n’était pas un gage de réussite. En pratique, les difficultés d’interrogation ont été levées une à une grâce notamment à la puissance du langage Ruby et de son framework associé RubyOnRails, appris sur le tas. La facilité de prise en main de ces langages et leur souplesse d’utilisation a été une découverte étonnante et instructive. En plus, disposer de temps pour se former au travail est un grand avantage.

Un regret

Pas de problème particulier à signaler sur le déroulement des projets au cours de l’année écoulée mais du côté du développement, l’arrivée de Blacklight a été bénéfique car elle m’a permis d’apprendre un nouveau langage et de changer mon quotidien fait de PHP/MYSQL depuis plusieurs années et de le remplacer par Ruby / RubyOnRails et la satisfaction d’apprendre de nouvelle choses.

Un projet

Les projets à venir comportent tous un côté intéressant. Que ce soit la refonte de l’intranet et sa connexion à l’annuaire LDAP de l’université (qui devrait apporter un peu de piment) ou la mise à jour de la version 6 de Drupal à sa version 7, avec la contrainte de ne rien casser aux contenus actuels, nous avons sur notre plan de route la promesse d’un voyage aux paysages variés et aux rebondissements assurés.

Le bonheur n'est pas au bout du chemin. Il est sur le chemin. - Sur Flickr par MarcGbx - licence CC BY-NC 2.0
Le bonheur n’est pas au bout du chemin. Il est sur le chemin. – Sur Flickr par MarcGbx – licence CC BY-NC 2.0

Blacklight, deuxième partie : les données d’exemplaires

Quand l'eau se fait RUBIS -Par CHRIS230*** - Licence CC BY-NC-SA 2.0 - Sur Flickr
Quand l’eau se fait RUBIS -Par CHRIS230*** – Licence CC BY-NC-SA 2.0 – Sur Flickr

Suite de notre série de billets sur Blacklight, commencée par une présentation générale.
La question qui nous intéresse désormais est de savoir comment connecter Blacklight à un SIGB. À priori, les nouvelles sont peu réjouissantes car Blacklight ne connait ni le z3950, ni OAI-PMH, ni aucun autre protocole pour interroger directement un catalogue. On peut l’alimenter d’une seule manière par défaut : en lisant des données au format Marc en XML ou ISO2709. Cependant, on peut le faire communiquer avec un catalogue, via z3950 notamment, sans devoir reprogrammer entièrement un client dédié. Si z3950 ne peut pas servir a récupérer un catalogue entier il peut être utile en revanche pour récupérer des informations en direct, comme les données d’exemplaires.

Nous allons utiliser ruby-zoom, une bibliothèque écrite en ruby et interrogeant ZOOM, une API disponible pour développer des services autour de z3950 (ce composant existe aussi pour PHP et C).
Pour l’installer sur un serveur Debian disposant d’un environnement Ruby, cette commande suffit :

[sourcecode language= »bash » gutter= »false »]$ apt-get install yaz libyaz4-dev[/sourcecode]

Ensuite, dans le fichier Gemfile de BL, ajoutons la ligne :

[sourcecode language= »ruby » gutter= »false »]gem ‘zoom’, :git => ‘https://github.com/bricestacey/ruby-zoom.git'[/sourcecode]

puis, dans le répertoire de BL, exécutons la commande suivante pour terminer l’installation de ruby-zoom (il sera compilé puis installé dans ruby on rails) :

[sourcecode language= »ruby » gutter= »false »]$ bundle install[/sourcecode]

Quelques lignes de code pour finir

À cette étape, il faut mettre la main à la pâte et programmer en Ruby. Le plus simple est de créer un nouveau modèle dans le framework Ruby on rails de BL dédié à la connexion z3950. Voici un exemple utilisant les fonctionnalités de ZOOM.

[sourcecode language= »ruby »]

class Z3950
attr_reader :ip, :base, :port, :url
attr_accessor :keyword

def initialize(ip, base, port)
@ip = ip
@base = base
@port = port
@url = @ip + ‘:’ + @port + ‘/’ + @base
end

def search
resultats =  »
begin
ZOOM::Connection.open(url) do |conn|
rset = conn.search(@keyword)
rset.each_record do |record|
resultats += record.xml
end
end
resultats.force_encoding(« ISO-8859-1 »).encode(« UTF-8″)
rescue
nil
end
end

def get_localisations(resultats= »)
doc = REXML::Document.new(resultats)
resultats = []
root = doc.root

if root.respond_to?(‘elements’)
#parcours des champs 998
root.elements.each(« datafield[@tag=’998′] ») do |element|
resultab = {}
#pour chaque element fils on récupère les informations d’exemplaire (localisation, salle, cote, empruntable ou non)
element.each do |field|
if field.respond_to?(‘elements’)
resultab[:localisation] = field.elements[« [@code=’b’] »].text if !field.elements[« [@code=’b’] »].nil?
resultab[:salle] = field.elements[« [@code=’c’] »].text if !field.elements[« [@code=’c’] »].nil?
resultab[:cote] = field.elements[« [@code=’e’] »].text if !field.elements[« [@code=’e’] »].nil?
if !field.elements[« [@code=’h’] »].nil?
if field.elements[« [@code=’h’] »].text ==  ‘ ‘
resultab[:empruntable] = nil
else
resultab[:empruntable] = field.elements[« [@code=’h’] »].text
end
end
end
end
resultats << resultab
end
end
resultats
end
end

[/sourcecode]

La méthode search définie ici s’occupe de la connexion au serveur z3950 et la méthode get_localisations récupère et traite la réponse XML du serveur pour obtenir les données d’exemplaire.
Il reste à ajouter quelques lignes de code dans le fichier catalog_controller.rb ou  l’on utilise les deux méthodes précédemment créées, puis dans le fichier show.html.erb pour afficher les résultats obtenus. Voici le résultat sur notre serveur de test, suivi des quelques lignes de code adéquates dans la vue et le contrôleur.

Affichage des données d’exemplaire dans BL

Le code à ajouter dans le fichier catalog_controller.rb :

[sourcecode language= »ruby »]
# surcharge de la méthode show du module catalog de blacklight
def show
@response, @document = get_solr_response_for_doc_id
connexion_z3950 = Z3950.new(‘X.X.X.X’, ‘base’, ‘port’)
connexion_z3950.keyword = @document.id
resultats = connexion_z3950.search
@localisations = connexion_z3950.get_localisations(resultats)

respond_to do |format|
format.html {setup_next_and_previous_documents}

# Add all dynamically added (such as by document extensions)
# export formats.
@document.export_formats.each_key do | format_name |
# It’s important that the argument to send be a symbol;
# if it’s a string, it makes Rails unhappy for unclear reasons.
format.send(format_name.to_sym) { render :text => @document.export_as(format_name), :layout => false }
end

end
end
[/sourcecode]

Et dans la vue (le fichier show.html.erb)

[sourcecode language= »html »]<p>
<table>
<tr>
<td>Disponibilité</td>
<td>Localisation</td>
<td>Salle</td>
<td>Cote</td>
</tr>
<% @localisations.each do |loc| %>
<tr>
<td><%= render_bouton_empruntable loc[:empruntable] %></td>
<td><%= loc[:localisation]%></td>
<td><%= loc[:salle]%></td>
<td><%= loc[:cote]%></td>
</tr>
<% end %>
</table>
</p>

[/sourcecode]

Garder sa distribution GNU/Linux propre comme un sou neuf (première partie)

Bien que la robustesse des systèmes de fichiers les plus fréquemment utilisés sous GNU/Linux et leur capacité intrinsèque à ne pas se fragmenter à l’utilisation ne soit plus à démontrer, force est de constater que la fréquence des mise à jour, quand ce n’est pas la succession d’installations/désinstallations de programmes contribuent néanmoins à encombrer inutilement le système de paquets obsolètes voire orphelins.
De même l’utilisation fréquente des applications de messagerie ou de navigation sur le web se traduit inévitablement par la mise en cache d’un grand nombre de fichiers temporaires, qui s’ils ne sont pas purgés périodiquement contribuent eux aussi à « l’encrassement » général du système…

Sans prétendre à l’exhaustivité, cet article se veut être un recueil de bonnes pratiques visant à maintenir son système GNU/Linux aussi propre que possible.

Comme d’habitude, nous nous intéresserons plus particulièrement aux distributions de type Debian/Ubuntu et dérivées, et dans ce premier article nous aborderons les outils disponibles en ligne de commande. Il en existe évidemment d’autres en mode graphique qui leur sont complémentaires ou qui permettent d’aller plus loin, aussi je leur consacrerai un prochain billet sur ce blog.

A chaque installation ou mise à jour d’un paquet logiciel, ce dernier est  téléchargé depuis les dépôts avant installation, puis est conservé en cache pour pouvoir être rapidement réinstallé, le cas échéant.
Si cette politique est tout à fait louable pour économiser de la bande passante et gagner du temps sur le téléchargement, on se retrouve très rapidement avec un cache de paquets de plusieurs giga-octets dont on peut facilement venir à bout :

sudo aptitude clean && sudo aptitude autoclean

Si l’on gagne ainsi un espace disque non négligeable, on peut cependant faire mieux. Chaque désinstallation de logiciel laisse en général (sauf si l’on a pris soin d’utiliser l’option –purge) des fichiers de configurations dont on peut se débarrasser facilement :

sudo aptitude purge ~c

Au reste, on peut sans forcément le savoir conserver au sein du système de nombreux paquets devenus obsolètes au fil des mise à jour que l’on éliminera comme suit :

sudo aptitude purge ~o

Sans faire preuve de frilosité outre mesure, on peut tout à fait préférer vérifier ce que l’on s’apprête à supprimer. Il suffira pour cela de remplacer dans ce qui précède l’argument purge par search, tout simplement…

A ce stade, vous aurez remarqué que j’utilise le gestionnaire de paquet aptitude au lieu d’apt-get qui est plus volontiers invoqué dans la documentation. De mon point de vue, étayé par cet article ou encore celui-ci, aptitude est à la fois plus souple et plus puissant qu’apt-get, et avant tout gère mieux les dépendances, y compris et surtout pour les mises à niveau de distributions. C’est également une habitude que j’ai prise depuis la Debian 3.1 « Sarge » et dont je n’ai pas envie de me défaire…

Maintenir propre sa base de paquets est une bonne chose, mais on peut cependant aller plus loin et débarrasser son système de nombre de fichiers inutiles, à commencer par les bibliothèques orphelines ou les fichiers de traduction dans les langues autres que la sienne. Pour cela on va se servir de deux programmes extrêmement utiles et efficaces que sont deborphan et localepurge. Installons-les pour commencer :

sudo aptitude install -r deborphan localepurge

deborphan (et son pendant graphique gtkorphan) repère les bibliothèques orphelines i.e. les composants de programmes rendus inutiles par désinstallation mais non supprimés par la gestion automatique des dépendances. Invoqué sans plus d’arguments à la ligne de commande, deborphan dresse la liste des « orphelins ». On l’utilise en général combiné à d’autre programmes, voire au sein de scripts shells :

deborphan | xargs sudo aptitude -y purge

supprimera les orphelins mais si l’on veut supprimer les paquets -dev devenus inutiles il suffira de faire :

deborphan --guess-dev | xargs sudo aptitude -y purge

Enfin, si l’on a pas froid aux yeux (et fait quelques vérifications préalables) on peut aussi procéder à un nettoyage radical avec :

deborphan --guess-all | xargs sudo aptitude -y purge

Pour en terminer avec la suppression des paquets inutilisés, voici un exemple de script de nettoyage permettant d’automatiser ce genre de tâche :

[sourcecode language= »bash » highlight= »3,31″]
#!/bin/zsh
echo « liste des paquets inutilisés : »
deborphan
echo « nettoyer? o/n »
read netdeb
if [[ $netdeb == o ]]
then
apt-get remove –purge `deborphan`
fi
echo « paquets desinstallés avec fichiers de config présents »
dpkg -l |grep « rc   » | awk ‘{ print $1″: »$2 }’ > liste_nom
for i in `more liste_nom`
do
echo $i > temp_verif
verif=`awk -F ‘:’ ‘{ print $1 }’ temp_verif`
if [[ $verif == « rc » ]]
then
paquet=`awk -F ‘:’ ‘{ print $2 }’ temp_verif`
echo « purger le paquet : » $paquet « ?  o/n »
read netconf
if [[ $netconf == « o » ]]
then
dpkg –purge $paquet
fi
fi
done
# nettoyage fichiers temporaires
rm liste_nom temp_verif
[/sourcecode]

Par ailleurs, l’internationalisation toujours plus poussée amène avec elle un inconvénient de taille, si l’on peut dire, sous la forme des traductions des pages de man. Hormis l’anglais qui est la langue native du système et le français la langue d’usage il est inutile de conserver l’ensemble des traductions et pour cela localepurge est notre ami. A l’installation, il suffit de cocher les cases en, fr et fr_FR :

configuration de localepurge
Configuration de localepurge.

Quant à l’usage on peut invoquer directement localepurge dans un terminal pour constater immédiatement son action, cependant c’est également sur le long terme que son action est efficace puisqu’il entre en action à la moindre installation de paquet afin de ne conserver que les traductions voulues.

Résultat
Résultat

Le seul reproche que l’on peut adresser à localepurge, c’est de ne pas éliminer toutes les traductions, notamment les fichiers d’internationalisation de l’interface graphique.
Voilà la transition toute trouvée pour aborder le thème de mon prochain article, car c’est précisément une situation à laquelle on remédiera en utilisant d’autres outils, graphiques cette fois.

D’ici quelques jours, je vous proposerai donc d’examiner plus avant le fonctionnement de Synaptic, Computer Janitor pour la gestion des paquets, BleachBit et Fslint pour le nettoyage sans oublier, mais cette fois-ci uniquement pour Ubuntu, cet outil fort pratique qu’est Ubuntu Tweak…

Présentation de Blacklight

Total solar eclipse solaire 1999 – Luc Latour sur Flickr – licence CC BY-SA 2.0
Total solar eclipse solaire 1999 – Luc Latour sur Flickr – licence CC BY-SA 2.0 

À la recherche d’une nouvelle interface de consultation de notre catalogue, nous testons actuellement un logiciel développé par plusieurs universités américaines : Blacklight (BL). Ce logiciel présenté lors d’une journée d’étude Couperin sur les discovery tools libres propose via une interface sobre et claire, une recherche par facette hautement configurable. Plusieurs exemples sont proposés sur le site du projet. Voyons son fonctionnement plus en détail.

À proprement parler, ce n’est pas BL qui fournit une recherche par facette mais un de ces composants : Solr, le moteur de la fondation Apache. BL est configuré pour l’interroger au mieux et avec des formats de données connus des bibliothèques. En l’occurrence, BL a été développé pour MARC mais on peut l’adapter pour d’autres formats. Par défaut, il propose différents champs : (titre, sous-titre, auteur, date de publication, sujets, format, localisation, etc.) que l’on retrouve dans les facettes sur la gauche (copie d’écran ci-dessous), ou en coulisses dans l’index de Solr. On peut bien sûr les modifier, en enlever ou en ajouter d’autres.

Blacklight à l'universite de Stanford
Blacklight à l’universite de Stanford

À ce jour, le seul moyen d’alimenter Blacklight fonctionne par Solr. Ce dernier dispose d’un certains nombres de connecteurs pour l’alimenter depuis une base de données, un fichier texte ou des notices en MARC via le programme Solrmarc, intégré par défaut à BL. Un fichier de configuration fait la correspondance entre les champs de BL et ceux des notices. À l’origine, ce mapping est prêt pour le MARC mais on peut l’adapter pour l’UNIMARC. La tâche est a priori aisée pour une correspondance directe de champs mais elle se complique quand il s’agit de les apparier, d’enlever une ponctuation inappropriée, de mettre une phrase en minuscule, etc. Dans ce cas, il est nécessaire de faire appel à des fonctions de traitement existantes ou à redéfinir en JAVA.

Une notice de Blacklight
Une notice de Blacklight

À l’usage, l’import de notices se fait très rapidement même pour un grand nombre d’enregistrements et BL est presque utilisable en l’état. On pourra configurer l’affichage des champs des notices ou des facettes à loisir dans un simple fichier de configuration. Cependant, si on opte pour l’UNIMARC, il reste un problème d’encodage pour les différents formats d’export de notice proposé par BL (en copie d’écran jointe). L’adaptation est délicate car elle nécessite de redéfinir des fonctions du cœur du programme en ruby.

Pour résumer, BL est relativement facile à prendre en main, à installer et à alimenter même quand on ne connait pas bien le fonctionnement de Ruby On Rails, le framework sur lequel il s’appuie. La tâche se complique pour le passer en UNIMARC ou pour des fonctionnalités plus personnalisées comme la connexion à un SIGB. Mais cela fera l’objet d’autres billets dans l’alambic…