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
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.
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.
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.
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
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 ?
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.
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 ?
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…
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) ?
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…
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.
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 :
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) :
À 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
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.
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
À 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.
À 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.
À 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…
Le développement web devient une tâche rapidement complexe quand il s’agit de rendre un site compatible avec le plus grand nombre de navigateurs possibles. D’un côté, HTML5 ET CSS3 font course en tête et sont chaque jour un peu mieux pris en charge par les nouveaux navigateurs. De l’autre, Internet Explorer dans ses versions 6 et 7, freine l’utilisation des nouveaux langages qu’ils comprennent très mal, ou pas du tout. Ajoutons à cela, l’expansion des mobiles et tablettes nécessitant des feuilles de style dédiées et le casse-tête devient difficile à résoudre. Pour tenter d’y voir plus clair et adapter nos choix techniques en conséquence, nous pouvons utiliser les statistiques du site web (fournis par notre logiciel Piwik) qui fournit des informations détaillées sur les équipements de nos usagers.
D’abord, Piwik fait la distinction entre le nombre de visites et le nombre de visites uniques (un visiteur est alors compté une seule fois même si il visite le site plusieurs fois dans la journée). Les résultats sont sensiblement différents entre ces deux chiffres. Le nombre de visites est significatif des utilisateurs les plus actifs tandis que le nombre de visites uniques représente mieux la diversité des visiteurs. Voyons ce qu’il en est pour les navigateurs de nos usagers.
On voit que le navigateur Chrome est largement représenté (camembert de gauche) mais que c’est Firefox et Internet Explorer qui sont les plus utilisés (à droite). Quand on regarde les statistiques plus précisément, Internet Explorer 6 et 7 comptabilisent 10% des visites.
Pour les utilisateurs de mobiles, les chiffres sont surprenant. Leur proportion est de 10% en visites uniques et tombe à 1% quand on regarde leur activité sur le site (la catégorie “autres” contient des systèmes aussi incongrus que la playstation ou la nintendo wii).
Que conclure de ces chiffres ?
D’abord, la proportion des usagers d’Internet Explorer 6 et 7 n’est pas négligeable et les développements doivent tenir compte de leurs spécificités. Adieu donc les bonnes pratiques de développement en CSS et adieu également aux innovations de pointe proposées par CSS3. Nous pouvons cependant utiliser la technique de dégradation élégante qui permet de rendre le site compatible avec tous les navigateurs pour un rendu meilleur sur les plus modernes et moins bon sur les plus anciens.
Concernant les mobiles, leur proportion est loin d’être négligeable également mais leurs utilisateurs ne semblent pas réellement actifs sur le site. Comme nous n’avons pas encore de feuille de style dédiée à ces équipements, c’est compréhensible. Cependant il serait intéressant de connaître l’usage réel fait avec ces appareils (une recherche documentaire semble peu probable sur mobile) pour mieux connaître leur impact.
Nos serveurs étant installés selon la technologie RAID, le risque de perte de données provient essentiellement d’une erreur logicielle ou humaine. Ne disposant pas de solution de sauvegarde professionnelle pour nos sites web et documents numériques, nous ne pouvions cependant pas rester sans copie de secours des fichiers et des bases les plus importants. Concernant ces dernières, un simple script les enregistre dans des fichiers distincts à intervalles réguliers. L’alambic numérique étant peu pourvu en langage informatique — un comble pour le blog d’une bibliothèque numérique –, voyons plus en détail le fonctionnement de ces quelques lignes de code.
MySQL, le système de gestion de bases de données que nous utilisons, dispose d’un certain nombre d’outils d’administration. L’un d’entre-eux, permet d’exporter les bases dans un format adapté à un éventuel ré-import (en SQL). Chaque nuit, le programme qui nous intéresse ici, exporte les données de nos sites principaux à l’aide de ces commandes de gestion. Les extractions de la veille sont écrasées systématiquement et même si nous archivons régulièrement ces fichiers il n’y a donc pas de gestion des versions précédentes. Nous disposons tout de même d’une copie de secours en cas d’une perte de données inattendue.
Voici ce script et un commentaire associé :
[sourcecode language=”bash” highlight=”15,31″]
#! /bin/bash
#fonction testant la presence d’un element dans un tableau de chaînes
function in_array(){
chaine=$1
trouve=$(echo ${exclude[*]} | grep “$chaine”)
if [ “$trouve” != “” ]
then
return 1
else
return 0
fi
}
#récupération de la liste des bases
bases=($(mysqlshow -pmotdepasse | cut -d ‘|’ -f2 | sed ‘1,3d’ | sed ‘$d’))
#repertoire de sauvegarde ou sont copiés les exports
rep=’/sauvegardes’
#liste des bases a exclure
exclude=(base1 base2 base3)
#lancement de l’export
for i in ${!bases[*]}
do
$(in_array ${bases[$i]})
inarray=$(echo $?)
if [ $inarray -eq 0 ]
then
echo ${bases[$i]}
mysqldump -u root -pmotdepasse –opt ${bases[$i]} > $rep/${bases[$i]}.sql
fi
done
[/sourcecode]
Ces quelques lignes sont écrites pour BASH, l’interpréteur de la ligne de commande sous Linux. Son fonctionnement est simple, il récupère la liste des bases présentes dans le serveur MySQL puis les enregistre dans un répertoire indiqué dans le programme à la ligne 18 . Certaines bases peuvent être ignorées en indiquant leur nom dans la liste de la ligne 21.
Les lignes en surbrillance ont une syntaxe particulière. Il ne s’agit pas d’une faute de frappe mais le mot de passe doit être accolé à l’option « -p » passée aux commandes mysqlshow et mysqldump.
Il suffit ensuite d’attribuer les droits d’exécution à ce script et de le lancer avec les commandes suivantes :
À l’intérieur de notre réseau, l’usage des logiciels libres est de plus en plus courant : la généralisation de l’utilisation d’OpenOffice est en cours, nos serveurs et sites web sont pour la plupart sous licences libres et certains postes publics sont équipés d’une distribution Linux. Si cette transition ne provoque pas de levée de boucliers, la notion de logiciel libre reste cependant mal comprise. À destination des collègues de la BCU, cet article a pour but d’éclairer un peu mieux le choix de nos outils informatiques…
D’abord, une définition. Pour cela, prenons l’exemple couramment utilisé de la recette de cuisine. Imaginez un instant que vous réalisiez un superbe gâteau pour l’anniversaire d’un ami. Les convives admiratifs, après s’être régalés de la pâtisserie, vous demandent alors la recette. Deux possibilités s’offrent à vous. Vous pouvez jalousement garder le secret de fabrication et lancer un « Oh tu sais, c’est tout simple, j’ai fait ça les yeux fermés ». Vous pouvez également copier la recette de votre œuvre et la distribuer généreusement à votre entourage selon les principes du logiciel libre. Quelles sont les différences entre ces deux façons de faire ?
Dans le premier cas, vos invités ignorent la recette du gâteau. Ils ne peuvent le reproduire à l’identique, vous seul(e) détenant le secret de fabrication.
Dans le deuxième cas, chacun peut reproduire le gâteau chez lui à sa guise. Si on pousse l’analogie avec les logiciels libres plus loin, vos amis pourront également modifier la recette et la distribuer à nouveau avec leurs modifications. Toutefois, rien ne garantit que c’est à vous qu’il feront goûter le fruit de leurs efforts…
Pour en revenir au logiciel, chacun d’entre eux possède sa recette qu’on appelle le code source. Dans le cas d’un logiciel non-libre, le code source n’est pas accessible. L’utilisateur est alors dans l’impossibilité d’étudier son fonctionnement, de le reproduire ou de le modifier (sous réserve qu’il ait les connaissances informatiques pour le faire). Il n’aura pas non plus l’autorisation de le partager avec quelqu’un d’autre, ces droits étant déterminés par la licence accompagnant le logiciel. Ainsi on pourrait définir un logiciel libre par « logiciel ayant une licence libre». La GPL (Gnu General Public License) est la figure de proue des licences libres mais il en existe d’autres.
La comparaison culinaire a ses limites et, pour une définition plus précise, vous pourrez lire cette page de la free software foundation à l’origine du concept de logiciel libre.
«N’est-ce pas moins bien parce que c’est gratuit ? »
Au détour d’une conversation sur les “Free software” (à ne pas confondre avec “freeware”), vous entendrez peut-être la question ci-dessus qui contient deux erreurs à elle seule.
Libre ne veut pas dire gratuit. Vous pouvez tout à fait commercialiser un programme sous licence libre. Cependant, il y a peu d’intérêt à vendre un logiciel dont on distribue le code librement. Les entreprises qui occupent ce secteur vendent des services (maintenances, mises à jour) plutôt que le logiciel en lui-même.
Sans vouloir faire un comparatif entre logiciels libres et logiciels non-libres, la qualité n’est pas un argument en leur défaveur. L’ouverture du code entraîne en général une amélioration de la fiabilité du programme. La raison en est que les communautés de développeurs peuvent détecter plus rapidement et plus facilement les éventuelles erreurs de programmation et améliorer le logiciel en conséquence.
Une autre confusion provient de la similitude entre la notion d’open source et celle de logiciel libre. La FSF (Free Software Foundation) est à l’origine de l’appellation « logiciel libre » tandis que l’organisme OSI (Open Source Initiative) revendique l’appellation « open source ». Les premiers, emmenés par Richard Stallman, mettent en avant les valeurs de partage et de liberté garanties par les licences libres. Les seconds, qui se réclament d’Eric Raymond, (hacker respecté pour son livre La cathédrale et le bazar) se veulent pragmatiques et prônent l’open source pour ses qualités intrinsèques (meilleure fiabilité du logiciel due à l’ouverture du code). Selon que l’on est partisan de l’un ou de l’autre camp, les termes et la philosophie varient mais les deux définitions sont en accord dans la plupart des cas.
Enfin, il reste une confusion mineure mais néanmoins problématique. Rendons son honneur à Tux, mascotte emblématique de Linux. Il est souvent confondu avec un pingouin à cause du mot anglais « penguin » qui signifie en réalité « manchot ». Un spécialiste avancerait que pour un manchot, Tux ne ressemble à aucun autre de ses confrères mais cessons là la comparaison.
Pour finir, voici un lien vers le site Framasoft, référence incontournable du « monde libre », sur lequel vous trouverez quantité de fiches descriptives de logiciels libres en tout genre pour différents systèmes d’exploitation. Bonne découverte !
À Clermont-Ferrand le dépôt des thèses numériques dans STAR est officiel depuis Septembre 2010 pour l’université Blaise Pascal et depuis Janvier 2011 pour l’université d’Auvergne. Pour faciliter le dépôt des nouvelles thèses, un lien a été établi entre APOGEE et STAR et éviter ainsi une double saisie des informations administratives. Les données d’APOGEE sont extraites, puis mises en forme afin d’être importées dans STAR.
Cette méthode n’a rien d’originale et est notamment utilisée à l’université de Tours qui a généreusement transmis sa méthode d’export/import sur la liste des correspondants STAR. Cette procédure a été retranscrite à l’université de Metz également. Nous l’avons quelque peu modifiée afin de simplifier cette routine effectuée chaque semaine.
Quelques fichiers à adapter
Le script d’extraction
Ce programme a été affiné par un informaticien de notre centre de ressources informatiques. Seules les informations des nouveaux doctorants (depuis la dernière extraction) sont aspirées. L’étape de suppression des doctorants déjà présents dans STAR est ainsi évitée.
Les données issues de l’export
L’étape d’édition du fichier CSV est encore nécessaire. Ceci pourrait être automatisé en adaptant la feuille de style XSL mais pour l’instant le jeu n’en vaut pas la chandelle. En pratique, il arrive que le nom du président du jury ne soit pas saisi dans APOGEE ce qui empêche l’import dans STAR (ce champ étant requis dans la recommandation TEF).
La feuille de style XSL
En plus de l’adaptation du numéro d’autorité Sudoc, on a du changer l’en-tête XML et une balise XSL pour l’adapter à la version de saxon. Il faut donc remplacer la ligne :
Ces modifications faites, un petit script (disponible en bas de cette page) a été créé pour automatiser la transformation du fichier d’export en fichiers de thèses XML conformes à la recommandation TEF.
Sous linux, il n’y a pas de problème d’encodage entre l’ANSI et l’UTF-8 (ce dernier format étant natif), on peut alors lancer notre script qui créera les fichiers des thèses dans un répertoire dédié.
Ce petit programme utilise le logiciel ffe (flat file extractor) pour transformer le CSV en XML, puis saxon (comme à Tours) pour la transformation en TEF.
Pour l’utiliser sous Ubuntu, les paquets libsaxon-java et ffe doivent être installés. La suite des opérations se déroule en ligne de commande.
on place le fichier CSV issu de l’extraction à la racine du répertoire du script.
on place le fichier de transformation XSL dans le répertoire « scripts »
on execute la ligne de commande suivante :
$ ./ star.sh theses.csv scripts/feuilleXSL.xsl
Les thèses seront alors disponibles dans le répertoire « résultats » et prêtes pour l’import par mail.
3 bonnes raisons de travailler en bibliothèque numérique ? Prêtons-nous au jeu, voici le point de vue d’un développeur.
Première bonne raison : Les logiciels libres. Du point de vue philosophique, ils ont toute leur place en bibliothèque, dès lors que l’on parle de partage et mise en commun. Du point de vue pratique, ils permettent au quotidien de travailler de manière autonome tout en s’appuyant sur le travail d’une communauté de développeurs et d’utilisateurs. En bref, avec les logiciels libres, on ne réinvente pas sans cesse la roue et on travaille de manière intelligente (ce qui ne veut pas dire que le résultat est meilleur par ailleurs, mais c’est un autre problème).
Deuxième bonne raison : Bénéficier de la présence en ligne des biblio-bloggeurs. Une chose m’a frappé lorsque j’ai commencé à découvrir le monde des bibliothèques : les bibliothécaires passent beaucoup de temps à réfléchir à leur métier. Cette pratique me semble moins répandue en informatique par exemple. On trouve bien des bloggeurs/développeurs dispensant de précieux conseils en programmation mais peu de discussions sur l’évolution de l’informatique et de ses pratiques. La communauté de bibliothécaires en ligne et plus généralement, les ressources sur les évolutions du métier sont particulièrement enrichissantes dans notre travail quotidien.
Troisième bonne raison : L’absence de public. Si l’on en croit la « cote 400 » de Sophie Divry, « l’usager » n’est pas aussi sage que les livres disposés dans les rayons. L’âge numérique apporte enfin la délivrance au bibliothécaire : se débarrasser du public. Fini les grincheux, les bruyants, les « Où sont les toilettes? ». En bibliothèque numérique, les remontrances se font désormais via formulaire interposé. Prière de s’adresser à la page d’accueil. C’est ainsi que l’on passe du profil de rat de bibliothèque à celui du geek abrité par son écran. L’évolution ne fait pas toujours bien les choses.
Ne tenez bien sur pas compte de la troisième raison, les vacances approchant, on peut se permettre de finir sur une note plus légère.
Quand une bibliothèque dispose d’un développeur, la question des logiciels libres est au cœur des développements. Leur utilisation amène pourtant des contraintes et influence l’organisation du travail. Voici un état des lieux sur leur pratique, avantages et inconvénients.
Un développeur seul n’est rien
Commençons par un constat : pour un développeur web, ce n’est pas très productif de programmer un logiciel de A à Z. La plupart des fonctionnalités de base (création de pages web, gestion d’utilisateurs, etc.) sont fournies par la majorité des CMS et il serait vain de vouloir faire mieux ou de les reproduire à l’identique en travaillant seul. Autre écueil, le travail d’une personne, ne peut rivaliser avec celui d’une communauté de développeurs fournissant mises à jour régulières et correctifs contre les failles de sécurité.
Cependant, on peut comprendre l’envie de l’informaticien de créer sa propre application. Concevoir, modéliser, pratiquer de manière avancée la programmation objet et les patrons de conception sont autant d’étapes passionnantes du cycle de développement. A la manière du forgeron, c’est en développant que l’on devient développeur et l’exercice de son cœur de métier lui permet de réfléchir à sa pratique de la programmation, le code devenant plus propre et efficace, et même beau, au passage.
Des logiciels de qualité
Partant de ce constat, l’utilisation des logiciels libres devient un atout considérable pour un service informatique en bibliothèque. Leur licence permet leur réutilisation, leur modification et offre au développeur la possibilité de les enrichir et les adapter en mettant ses compétences en application. La bibliothèque profite également du travail de la communauté de développeurs fournissant les logiciels, d’autant plus lorsque ces derniers sont spécialisés dans le métier. Leur nombre et leur diversité représente une manne considérable, souvent gratuite. A la BCU, nous n’hésitons pas à les tester et les déployer pour répondre à des besoins précis et ponctuels. Nous avons ainsi mis à disposition des chercheurs une galerie d’images numérisées (piwigo), pour qu’ils puissent les décrire en Dublin Core. Cette description sera réutilisable pour une bibliothèque numérique.
Bref, le tableau est presque idyllique mais à l’usage on rencontre quelques contraintes.
Une course à l’évolution
En premier lieu, intéressons-nous aux mises à jour accompagnant tout logiciel libre. Signe de bonne santé d’un projet, elles permettent de bénéficier des correctifs comblant les failles de sécurité inhérentes à tout logiciel complexe. Elles offrent également les toutes dernières innovations techniques et fonctionnelles du web. A priori, c’est donc un bénéfice de les installer et de faire évoluer le logiciel.
Mais ce processus a une contrepartie. Les temps de maintenance augmentent au fur et à mesure du nombre d’applications installées. Pour preuve, wordpress, utilisé pour l’alambic numérique, propose environ une mise à jour par semaine, que ce soit pour le corps du programme ou pour les extensions installées.
De manière générale les logiciels libres, au moins les plus actifs, souffrent d’une instabilité chronique (au sens d’évolution permanente). Prenons l’exemple de Drupal. Nous l’avons sorti en version 6, au moment même où paraissait la version 7. Dans un an et demi ou deux, quand la version 8 sera prête, la version 6 ne sera plus maintenue. Faut-il passer à la version 7 dès que possible ? Faut-il attendre la version 8 et refondre entièrement le site à ce moment là ? Si l’on veut respecter ces changements de version (et continuer à bénéficier du support de mise à jour), le remplacement du site impliquera de recommencer un cycle de développement (cahier des charges, acquisition de connaissances, formation des utilisateurs, etc.) peu de temps après le précédent.
Il faut toutefois pondérer cet inconvénient. Si le logiciel évolue, les services évoluent en parallèle. Dans deux ans, on peut imaginer que de nouveaux besoins seront apparus et que le remplacement de notre site deviendra évident, et pas seulement pour des raisons logicielles. En bibliothèque, l’avenir proche amènera sans doute à s’intéresser au web de données et au format RDF. On peut toutefois se demander si les efforts fournis aux étapes précédentes ont le temps de porter leurs fruits.
S’adapter au cycle de vie des logiciels apporte son lot de questions importantes : Comment gérer au mieux l’ensemble d’un grand nombre de logiciels installés en interne ? Comment ne pas se laisser déborder par les tâches de maintenance? Comment profiter des changements de version sans devoir tout recommencer à chaque fois ?
Nous n’avons pas les réponses dans l’immédiat, mais ces questions seront au cœur de nos travaux à venir…
Logiciels libres et bibliothèques est une association de plus en plus répandue. Leur utilisation amène pourtant des contraintes et influence l’organisation du travail. Voici un état des lieux sur leur pratique, avantages et inconvénients.