Les poneys… pourquoi ?

13/08/2013 Comments off

My_Little_Pony_Friendship_is_Magic_logo.svg

Mais pourquoi tu regardes ça ?

C’est la question que l’on m’a le plus posé ces derniers temps. Or, étant donné que la réponse « Mais je t’assure que cette série est bien et bien en dehors des clichés habituels » ne semble pas convaincre, je vais rentrer un peu plus en détail et essayer de répondre à la question.

Répondons simplement à deux trois questions évidentes mais absurdes. Non ce n’est pas juste une phase. Non ce n’est pas simplement un délire de geek. Non ce n’est pas une secte foireuse rempli de gens sociologiquement déstabilisé. Non vous n’êtes pas obligé d’adhérer à ce mouvement.

Par contre ce que je demande, c’est que vous lisiez ce texte pour comprendre pourquoi plusieurs millions d’hommes adultes à travers le globe (oui oui, vous avez bien lu) regardent cette série.

Comment ça a commencé

Il y a un an et demi, je partage la fameuse vidéo PonyCraft 2. Cette vidéo met en scène la bande annonce de StarCraft 2 avec des morceaux extraits d’une sorte de dessin animé plutôt bien fait avec des chevaux/poneys. Fait étrange, cette vidéo ne contient QUE des extraits épiques, avec des dragons, des manticores, des serpents à 4 têtes, un ours géant, des sorts de magies, une sorcière mystérieuses et pas mal d’attitude ultra-classe. J’ai trouvé cette vidéo épique et étant donné que j’avais vu aussi quelques sujets sur teamliquid.net (site communautaire du jeu StarCraft) qui parlaient de ça, j’ai regardé vite fait deux trois extraits rapidement. J’ai trouvé ça bien mais je n’y ai pas accordé une grande important.

800px-Manticore_bucks_Applejack_off_S1E02 Nightmare_Moon Capture d’écran 2013-08-13 à 02.40.01

Eyyup. Une série pour fille, vous dis-je !

Puis, mon grand ami Gugli me met en commentaire que je devrais regarder cette série et qu’il ne me parlerait plus tant que je n’aurai pas vu un Sonic Rainboom (explosion d’arc-en-ciel lorsque l’on passe le mur du son). Ok. Je récupère la saison 1, je regarde les premiers épisodes et effectivement… ce show est bien fait !

L’animation est géniale, les acteurs sont excellent, la musique est bien écrite et le scénario est certes simple mais il n’est pas centré sur des clichés foireux. Il va sans dire que jamais, au grand jamais, je ne vous aurais embetté avec une série dont la seule préoccupation serait de prendre le gouter avec ses amis. J’ai très rapidement enchainé les épisodes et j’ai vraiment commencé à aimer cette série.

La série

Je ne vais pas vous mentir, oui il s’agit de poneys. Oui, il s’agit de poneys qui se font des amis. La différence, c’est qu’ils utilisent l’amitié pour combattre et comprendre les choses qui les dépassent, que ce soit des monstres, d’autres personnes, des situations de la vie courante, ou encore le fait d’accomplir leur rêve.

L’histoire au sens large, c’est principalement celle de Twilight, jeune apprentie qui apprend la magie. Sa mentor lui a ordonné d’apprendre ce qu’était l’amitié, qui dans son cas peut se traduire par une magie très puissante du genre pétrification de chimère (saison 2 épisode 2). Ses principales amies sont 5 personnages qui ont chacune leur trait de caractère très distinct qui représente un des éléments d’harmonie. C’est quand ils sont ensemble que cela permet le déclanchement de leur magie la plus puissante.

mane_6_vectors_by_zobe-d4iowcj

De gauche à droite, Applejack (fermière, élément d’honnêteté), Fluttershy (ultra-timide, élément de gentillesse), Rarity (designeuse, élément de générosité), Pinkie Pie (excentrique, élément du rire), Twilight (l’héroine), et enfin Rainbow Dash (athlète, élément de loyauté). Ces six personnages principaux sont totalement opposés et pourtant elles sont extrèmement proches.

Le concept de chaque épisode est de découvrir quelque chose supplémentaire sur l’amitié et d’en faire le rapport à sa tutrice. Ces leçons de vie sont certes simples mais elles sont efficaces et concernent tout le monde sur des sujets qui peuvent surprendre (comme un sur la science et la religion très bien traité d’ailleurs).

Attends mais ton machin sur l’amitié, c’est super mielleux, non ?

Temps mort ! Vous regardez bien des Disney et des Pixar ? Vous regardez bien des séries comme Glee ? Vous regardez bien des mangas/anime Shoujo ou Shonen ?

Personnellement, dans la plupart des cas, je trouve ça tout aussi mielleux voire plus que ce que j’ai pu voir sur MLP.

Toujours pas convaincu ? Le pilote de cette série, c’est l’histoire du retour de Nightmare Moon, une sorte de démon qui a été bani durant 1000 ans et dont le but est de garder la nuit à tout jamais. Or ce démon se trouve être la sœur de la déesse qui dirige ce royaume (et qui a la responsabilité de lever le soleil chaque jour). Pour la combattre, les héroines vont devoir affronter leurs peurs, des crevasses, un manticore, un dragon, et la trahison. Ouvrez les yeux, ça en jete !

Je me rappelle quand on était gamin, c’était horrible !

Oui ! Je suis tout à fait d’accord ! Vous pouvez même pas savoir à quel point je suis d’accord. Mais pour la quatrième génération, celle dont je parle ici, c’est Lauren Faust qui est aux commandes (en tout cas à la création). Petit micro background : Lauren Faust est très connue pour avoir travaillé sur les Super-Nanas avec son mari (série qui passait en France sur Cartoon Network). Et fait intéressant : c’est une femme qui parle régulièrement de propos féministes. Ok, maintenant, imaginez qu’on lui file un budget carte-blanche pour reprendre la licence MLP, licence la plus cliché de toute. Voilà ce que ça a donné.

Parce que chose que tout fan de la série sait, c’est Lauren qui est derrière cet univers, c’est elle qui l’a rendu épique, c’est elle qui a décidé qu’elle ne ferait pas un show stéréotypé pour petite fille. Elle voulait faire un show qui était pour les filles sans faire de clichés et aussi pour leurs parents, afin qu’ils puissent regarder ça avec leurs enfants. C’est ainsi que les bronies sont apparus (Bro-pony, bro voulant dire « pote » ou « frangin »)… en masse.

Oui même Rainbow Dash (G4) se fout de la gueule de la génération précédente

Tu vas pas me dire que ce machin te tiens pendant plusieurs années ?

Chose que personne n’avait prévu. Il y a eu un phénomène internet massif sur cette série. Beaucoup de gens se sont mis à aimer le show. Et le truc marrant, c’est que c’est devenu une communauté ultra-active et très artistique. Si je suis effectivement encore intéressé par ce phénomène, ce n’est pas uniquement par la série en soit. La série est bien, excellente même. Mais est-ce que ça vaut la peine de s’y attarder des années dessus ? Pas sûr. Par contre, si vous suivez EquestriaDaily vous y verrez chaque jour :

  • au moins une ou deux pages de plus d’une trentaines de nouvelles illustrations de qualité très haute comme (prise sur le dernier post au moment où j’écris cette ligne) :
    Thenightmare
  • plusieurs mises à jour de fanfics (histoire développées par des fans autour du show) comme sur FiMFiction
  • plusieurs nouvelles compositions musicales parfois de très grande qualité
    Et je vous assure qu’il y en a pour tous les goûts. Quelques exemples : Metal, Rock, Orchestral (il y en a plusieurs types évidemment), Jazz, Electro, Electro-swing, Balade et evidemment Dubstep. Sinon je vous invite à consulter mon archive twitter #brony
  • plusieurs vidéos allant d’animation de qualité professionnelle, à des reprises de bandes d’annonces, en passant par des PMV (pony music videos, nota : ce dernier lien est animé par les fans aussi) ou des trucs totalement random

Et je ne parle pas des articles et vidéos détaillés sur plein d’aspects du show (analyses en détail de l’histoire du show, décompositions d’animations, etc…). Et je rappelle que toutes ces productions sont catalysées par le show qui devient une source d’inspiration sans fond.

Mais pourquoi tant de barrouf ?

Ok cette section est déjà plus un mix philo-sociologique qui est en discussion encore mais certaines de ces reflexions sont vraiment intéressantes.

Les bronies sont des gens de tout genre et de tout âge qui ont non seulement appris à aimer quelque chose sur lequel ils avaient les pire a priori, mais de plus ils prennent les leçons de cette série à cœur. Dans le reportage « Bronies, the extremely unexpected adult fans of My Little Pony », des chercheurs en sociologies ont constaté que les bronies prennait les leçons du show pour les appliquer dans leur propre vie. Une des sociologues parle même très sérieusement du phénomène WWPD : What would a pony do ? (que ferait un poney à ma place).

La conséquence, c’est le fameux moto : « Love and Tolerate ». Tant que nous en sommes capable en tant que personne humaine avec nos défauts, nous essayons au mieux de tolérer, d’accepter, de ne pas juger et de pardonner. Ce sont des choses simples que le show nous parle et que nous avons tendance à oublier au fur et à mesure de notre vie.

love_and_tolerate_by_lazy_joe-d52bty1akiv128014e29953a15ee8

Nous sommes dans un monde où l’ironie est reine, où l’honnêteté est placé en second plan, où le mensonge est une part majeure des médias. Est-ce qu’il est possible d’avoir un temps mort et de recommencer à se dire les choses simplement, au premier degré, sans arrière pensée ? Honnêtement, c’est difficile vu l’ambiance dans laquelle nous régnons. J’ai entendu quelques d’interview par ci et là (sur EFN notamment) où plusieurs brony influents reconnaissaient le bonheur qu’ils avaient à écouter des dialogues sans arrière pensées et directs. Personnellement, je suis convaincu du bienfait de la série de ce point de vue là.

Dernier point important de cette série : le développement des personnages. Je pourrais rentrer en détails en vous démontrant la complexité de chacun des personnages mais c’est pas le but ici. Toutefois, voici tout de même quelques points intéressants :

  • Scootaloo est une pégase et fait parti des perso secondaires. Toutefois, nous ne l’avions jamais vu voler pendant beaucoup d’épisode mais bon pourquoi pas. Il se trouve que Lauren a déclaré que ce perso là était non seulement orphelin mais en plus handicapé et qu’il lui sera impossible de voler. Ce n’est jamais mentionné directement dans le show comme si tout le monde en était conscient et que tant pis on fait avec. QUOI !? Ok, dans n’importe quelle série au monde, il y aurait des flashbacks d’accident ou de moment dramatique dans sa vie lié à ce handicap. Tout le monde la traiterait comme tel et on tenterait de faire arracher la petite larme au spectateur sur sa condition. Ici, c’est une personne comme les autres… vraiment… simplement. J’ai jamais vu ça.
  • Le développement des Mane 6 (6 crinières, alias les 6 personnages principaux) est tellement correctement calibré que toute personne est capable de s’identifier à un (ou deux max) personnage(s). De plus, leur personnalité est en plusieurs couches. Par exemple, Fluttershy qui est extrèmement timide, peut montrer que dans certains cas elle peut se dépasser et devenir très confiante. Autre exemple, Pinkie Pie qui est toujours à la fête, lorsqu’elle tombe en dépression peut développer un sévère cas de schyzophrénie vraiment flippant.

Malgré ces développements complexes qui montrent un monde où justement, tout n’est pas rose, la série est capable de montrer qu’il est possible de façon tout à fait naturelle, de vivre ensemble dans la joie et la bonne humeur. Dans tous les cas, je pense que vous comprenez maintenant que nous ne sommes pas dans un monde parfait où la préoccupation unique est de savoir ce que l’on prend pour le gouter.

Conclusion

Ok, si vous avez lu jusqu’ici, félicitations ! Merci d’avoir pris le temps d’avoir lu ces lignes. Les a priori sur ce phénomène sont très ancrés et il devient difficile de se faire comprendre. J’espère que vous comprendez un peu mieux ce monde parrallèle très étrange qu’il m’arrive de fréquenter régulièrement.

Je vais arrêter de déblatérer maintenant. Je pourrais vous faire des discours en détails très long sur le positionnement de cette série par rapport au féminisme moderne ; ou encore des descriptions en long en large du talent des acteurs (de voix) sur cette équipe ; ou encore des nombreuses références à la culture populaire que l’on peut trouver à l’intérieur de ce show comme The Big Lebowsky ou encore le Seigneur des Anneaux ; ou encore des nombreuses découvertes musicales que j’ai pu trouver dans la communauté ; mais bon faut bien que je m’arrête 🙂

mlfw9627-cdg

Categories: Humeur

Stocker et interroger des données hiérarchiques

13/08/2012 Comments off

Cela fait un moment que j’avais envie de faire cette rubrique. Elle rassemblera des retours d’expériences que j’ai pu avoir sur les bases de données relationnelles (MySQL, Oracle, Postgres, H2, Derby, ou tout autre moteur similaire). Bref, des modélisations non triviales, des opérations bizarres, des structures d’index spécialisées, y’a de quoi faire dans ce monde en dehors des connaissances standards.

Aujourd’hui : comment stocker et interroger un arbre dans une BD ? Chaque nœud contiendra une seule donnée value de type integer.

Pourquoi c’est dur, chef ?

Pour comprendre la difficulté de ce problème, il faut revenir à l’algèbre relationnelle. Cette algèbre permet de manipuler les données modélisées sous forme de relations, c’est-à-dire d’ensembles de tuples respectant le même schéma. À son époque Edgar Codd a défini cette algèbre avec 6 opérateurs fondamentaux (sélection, projection, produit cartésien, union, différence ainsi que le renommage). Ensemble ces opérateurs permettent de faire de très nombreuses opérations complexes telles que des jointures, extérieures (outer) ou non.

Bon, ça, c’est bien gentil, mais on n’a pas spécialement avancé dans le problème. Peut-être que ça avancera mieux quand je dirais que le théorème de Codd montre que l’algèbre relationnelle a une puissance d’expression inférieure à la logique du premier ordre. En particulier, elle est équivalente si on enlève la récursion. La conséquence c’est que : le SQL de base n’est pas récursif. Mettez-vous bien ça dans le crâne quand vous faites une modélisation.

Les arbres : la structure récursive de référence. Les approches de « diviser pour mieux régner », les parcours, la programmation dynamique, tout est basé sur la récursion. Ainsi, même une requête simple comme « obtenir tous les fils d’un nœud » est impossible en SQL de base. Personnellement, j’ai eu plusieurs fois à utiliser cette structure pour représenter un réseau hiérarchique (réseau de capteur, réseau domestique).

Solution de l’auto-pilote : le id-parentId

L’approche que beaucoup beaucoup de gens font, car c’est la plus intuitive, la moins coûteuse en stockage. Mais aussi la plus limitée en interrogation. Attention je vous le donne en mile :

Tree(id INTEGER PRIMARY KEY, parentId INTEGER, value INTEGER NOT NULL)

Nous avons la relation indiquant : le nœud id a le parent parentId et la valeur value. Par mesure de simplification parentId peut être NULL. — Dans un schéma parfaitement normalisé par les définitions de Codd-Date, il faudrait une relation TreeSource(id, value) en plus. — Bon, évidemment, je suppose que vous n’êtes pas trop bête et vous m’ajoutez les index qui vont bien là où il y en a besoin.

Très efficace en terme de place, il permet aussi de répondre facilement à deux requêtes : « Quel est le parent d’un nœud ? » et « Quels sont les fils directs d’un nœud ? ». Par contre, oubliez les requêtes comme « TOUS les fils d’un nœud ».

MAIS, il y a une exception. Comme ce genre de modélisation revient régulièrement, les gens n’ont pas hésité à rajouter cette fonctionnalité dans SQL. Lors de la norme SQL-99, il a eu l’ajout de la clause WITH dans les requêtes SQL. Cela permet d’ajouter la récursion. Voilà la structure de ce genre de requête en gros :

WITH vueRecursive(attribut1,...,attributn)
AS (
      Requête d initialisation
      Liaison (UNION ALL, UNION, MINUS, INTERSECT)
      Requête de récursion
)
SELECT ... FROM vueRecursive ...

Des exemples existent pas mal sur la toile, cherchez « with clause sql », vous aurez masse de résultats. Par contre, il ne faut pas compter sur cette syntaxe la plupart du temps ! Il n’est pas implémenté dans tous les moteurs. Actuellement, seules les versions récentes d’Oracle, DB2, SQL Server et Postgres supportent cette syntaxe.

Le coût de cette solution n’est pas si moche au total, puisque vous êtes sur une requête que vous exécutez jusqu’à plus soif. En utilisant l’UNION ALL (qui s’optimise bien), vous vous en sortirez pas si mal la plupart du temps. Par contre, n’oubliez pas que la recherche pourra nécessiter la lecture de plusieurs pages de la relation (ou de l’index) pour trouver le résultat final. Les coûts I/O sont pas si géniaux que ça.

Solution qui a envie d’être intelligente : lft-rgt

Bon maintenant, on va essayer de penser outside the chimney pour trouver un solution qui tiens peut-être un peu mieux la route. Parlons donc de la plus connue : le modèle Nested Set. Voilà le schéma :

Tree(id INTEGER PRIMARY KEY, value INTEGER NOT NULL, lft INTEGER NOT NULL, rgt INTEGER NOT NULL)

Bon, je vous comprends, ça veut pas dire grand chose. Dites vous une chose, la contrainte est la suivante : les valeurs [lft, rgt] forment un intervalle et tous les autres intervalles strictement inclus dans celui-ci sont fils du nœud. Donc là on exploite à mort les propriétés des structures d’arbres.

Les requêtes possibles maintenant : il y en a quand même pas mal !

  • Récupérer un sous-arbre : sélection sur lft > v.lft et rgt < v.rgt, ordonné par lft pour former une réponse structurée.
  • Récupérer le chemin : sélection sur lft < v.lft et rgt > v.rgt, toujours ordonné par lft
  • Compter le nombre de nœuds fils : (rgt-lft-1)/2

Les complexités de sélection sont parfaites car ce sont juste des lookups d’index et ne dépendent pas de la profondeur de l’arbre donc youpi ! Avec des petits agrégats en plus, on est capable de récupérer le niveau d’un nœud ou d’autres opérations sympathiques rapidement.

Si vous voulez mon avis, cette solution est pas ultime ultime et ce pour une raison simple : la construction ou mise à jour est HORRIBLE ! Par exemple, l’insertion d’un nœud implique la modification de la moitié de la relation. L’idée est de décaler les indices lft et rgt des nœuds strictement à droite de 2, et pour les nœuds fils, s’il en existe, de 1. Je ne détaille pas les exemples ici, mais vous pouvez trouver des procédures pour mettre à jour ici.

Si vos données pour chaque nœud sont lourdes, vous pouvez découper la gestion des lft-rgt dans une autre table. Ainsi la modification ne demandera que la lecture-écriture de quelques pages en bloc (mais vous perdez la normalisation et vous savez ce que ça implique bande de coquins).

La solution du bonjour-j’ai-pas-peur : la table de clôture

Soyons bourrin Mesdames et Messieurs, n’ayons pas peur ! La taille n’a plus d’importance, le coût d’entretien, on s’en fiche : voici la table de clôture transitive ! Quant au schéma :

Tree(id INTEGER PRIMARY KEY, value INTEGER NOT NULL)
Closure(id INTEGER PRIMARY KEY, ancestorId INTEGER PRIMARY KEY, level INTEGER)

Oui, vous avez bien vu, oui ! Il y a une deuxième relation ! Et assez grosse en fait puisque si vous regardez bien, il y a une clé primaire composite. La relation Closure indique : le nœud id possède l’ancêtre ancestorId à un profondeur hiérarchique de level. L’idée de cette solution est de précalculer la récursion pour chaque nœud et de la stocker dans une relation.

Bon alors, passons les banalités : oui ça coûte en espace de stockage. Ça coûte même beaucoup, car pour chaque nœud vous allez avoir un n-uplet pour chaque ancêtre ! Ouchy-daisy. Mais bon, ça va très vite, on peut faire des jointures qui vont bien, on peut même sélectionner sur la profondeur de récursivité, wouzi ! De plus, on peut implémenter l’entretien de la clôture transitive de façon assez simpliste à coup de trigger si le SGBD le supporte. Conclusion : pas si moche.

La solution du futé : le lignage

Bonjour, je pète ma NF1, ça ne vous gêne pas ? Au lieu de faire une table spéciale pour faire la clôture, on va faire un attribut spécial qui désigne le lignage d’un nœud. Voici le schéma :

Tree(id INTEGER PRIMARY KEY, value INTEGER NOT NULL, path VARCHAR NOT NULL)

L’attribut path indique la liste des identifiants pour aller jusqu’au nœud actuel, par exemple « 1.21.6.3 ». Là où cette solution est très intelligente c’est que tous les moteurs actuels permettent des manipulations de chaines de caractères sans trop de soucis. Même, vous pouvez faire des recherches à coup d’expression régulières ! Insérer ou supprimer un nœud c’est assez direct et rapide. La seule restriction c’est qu’il ne faut pas avoir des profondeurs trop grandes pour ne pas faire exploser cet attribut. Par contre, il n’y a pas a priori d’index classique pour traiter ces conditions de sélection. Ainsi, toute requête nécessitera un parcours complet de la table pour vérifier que la condition soit correcte.

Petite cerise sur le gâteau : dans Postgres, pour utiliser ce chemin, il y a une structure d’index qui s’appelle ltree, conçue par deux chercheurs russes. Pour l’avoir expérimenté, on obtient des boost de performances monstrueux sur toutes les requêtes similaires aux regexp. C’est très bluffant. Conseil pour les concepteurs d’SGBD : laissez la possibilité à la communauté d’ajouter des structures custom !

En gros voire très gros

C’est chaud ! Il n’y a pas de solution universelle. Vous n’allez quand même pas croire que j’allais faire tout le boulot pour vous, n’est-ce pas ? Donc ce que je vous conseille : maitrisez bien les avantages et inconvénients de chacune des solutions. Et comme je suis gentil, voilà les questions que vous devez vous poser :

  • Est-ce que l’espace disque est limité ?
  • Est-ce que l’arbre sera profond ?
  • Quelles requêtes dois-je poser sur ma structure ?
  • Quelles sont les capacités de votre moteur (index, custom index, with clause) ?
  • Quel est le ratio accès/modification ? Quelles modifications seront faites (append-only, delete, build from scratch) ?

Une fois que vous avez les idées claires sur ça. Vous êtes tranquille. Sachez de plus que vous pouvez combiner des idées pour obtenir des accès plus efficaces, genre ajouter l’attribut parent au lignage par exemple. Enfin, si vous voulez allez un peu plus loin, il y a une super overview sur stackoverflow sur le sujet.

Categories: DB, Informatique

Structure d’un projet LaTeX

17/05/2012 Comments off

Je connais pas une seule personne qui a la même structure de projet LaTeX. Autant il existe des grandes conventions dans les projets de programmation en C ou en Java (notamment avec Maven). Mais pour le LaTeX, c’est un peu le vide intersidéral. Moi même, j’ai mis très longtemps à trouver quelque chose de stable. Pour la rédaction de mon dernier article, j’ai mis à l’épreuve une idée que j’avais depuis un petit moment. C’est le format que j’ai choisi pour la thèse.

Problèmes d’un projet LaTeX

  • Un projet LaTeX inclue des macros de l’utilisateur. Et potentiellement il voudrait bien réutiliser ses macros sur un autre projet
  • Certains packages doivent respecter un ordre d’inclusion
  • Les packages sont accompagnés par des paramétrages qui sont bien souvent toujours les mêmes
  • Le contenu du document doit être séparé en plusieurs fichiers pour être manipulable
  • Les chemins d’inclusions sont relatifs à partir du fichier maître (donc les dossiers sont lourds à manipuler)
  • Pour la raison précédente, tous les fichiers sont au même endroit sinon c’est chiant

Voilà, je viens de lister tout ce qui m’a bien saoulé pendant un bon moment. Je pense que vous êtes dans le même cas. Bon, arrêtons de tourner autour du pot. Voilà la structure de fichier.

Gestion de l’inclusion

Résolvons directement le problème de l’inclusion. Ce que je souhaite faire est la chose suivante : je décris la structure de mon document et de ses includes avec mon système de fichier. Par exemple, pour chaque chapitre, je fais un dossier, pour chaque section je fais un fichier à l’intérieur de ce dossier. Et si je souhaite regrouper mes chapitres en parties, je les regroupes dans un autre dossier. Ceci étant dit : comment on se débrouille maintenant ?

Prenons le chapitre introduction, voilà la structure que nous souhaitons faire :

introduction
|____contexte.tex
|____problematique.tex
|____objectif.tex
|____demarche.tex
|____plan.tex

Vous remarquez que ce dossier a un ordre. Les ruses habituelles pour trier tout ça est de renommer en 1-contexte 2-problematique etc… Bon c’est pas top hein. Ici on introduit un fichier .order qui contiendra l’ordre d’inclusion des fichiers.

$ cat introduction/.order
contexte
problematique
objectif
demarche
plan

Vous n’êtes pas obligé de mettre un fichier .order ou même de mentionner tous les fichiers. Si tel est le cas, les fichiers non-mentionnés seront inclus dans le désordre. Maintenant il faut un fichier pour inclure le tout, appeler la primitive \chapter (et faire un petit texte pour présenter le chapitre). Et c’est là que c’est joli. Ne mettez aucun \input ! Faites juste votre présentation.

$ cat introduction.tex
\chapter{Chapitre d'introduction}

Ce premier chapitre fait des trucs blabla

Voilà la tête de votre structure de fichier maintenant :

introduction
|____.order
|____contexte.tex
|____demarche.tex
|____objectif.tex
|____plan.tex
|____problematique.tex
introduction.tex

Vous pouvez imbriquer vos dossiers dans tous les sens du moment que vous respectez les principes que je vous ai montré.

Bon c’est bien gentil ce que tu nous fait Loïc mais c’est pas très compilable ton truc. Pas de panique, voici un script qui va vous ajouter les inputs qui vont bien à la fin de tous les fichiers qui ont un dossier avec leur nom. Vous pouvez trouver le script bash ici. Si ne mettez pas d’argument, il appliquera à tous les fichiers qu’il peut trouver dans la racine et sous-répertoires. Vous pouvez aussi lui mettre un pattern de recherche pour éviter de tout régénérer.

Les macros et les packages

Bon ça c’était la partie la plus tordue. Maintenant on va exploiter à mort cette structure pour gérer tout le reste ! Je vais donc faire un dossier inc qui contiendra encore deux dossiers packages et macros. Chaque fichier dans ces dossiers représente un bloc réutilisable ailleurs. Par exemple, voici mon fichier babel.tex qui introduit tous les packages qui vont bien pour faire du LaTeX en français :

$ cat packages/babel.tex
\usepackage[french]{babel}
\usepackage[T1]{fontenc}
\usepackage{eurosym}
\usepackage[babel=true]{csquotes}

Accumulez les packages qui vont bien (utf8, fullpage, babel, indent, wrapfigures…). Si vous avez un package qui nécessite une grosse configuration vous pouvez en profiter pour le customiser un peu. C’est le cas de listings qui est moche par défaut mais qu’avec le bon custom qui va bien : ça envoie du lourd.

De même pour les macros. Je me suis formé des fichiers qui rassemble des macros que j’ai pu faire au fur et à mesure :

$ cat macros/commonmath.tex
%Ensembles
\def\R{\mathbb{R}}
\def\C{\mathbb{C}}
\def\N{\mathbb{N}}
\def\Z{\mathbb{Z}}
...

Notez que vous pouvez utiliser le fichier .order pour résoudre les conflits d’ordre d’inclusion. Aussi, si vous voulez généraliser un fichier macros qui nécessite l’inclusion de packages vous pouvez utiliser des tricks qui permettent de tester avant d’inclure. Par exemple :

\ifx\colorbox\undefined\usepackage{color}\fi

Personnellement, j’aime bien aussi mettre un fichier title.tex dans le dossier inc qui contiendra toutes les méta-données de votre document (titre, auteur, date).

Le projet final

Petit bilan, vous avez de quoi gérer les macros/packages et vous avez une structure pour votre texte qui envoie du paté. Bon, ben c’est pas mal ça ! Pour le reste, voilà la structure que je vous conseille

Projet
|____ Master.tex
|____ bib
|____ template
|____ lib
|____ fig
  |____ src
|____ src
  |____ inc
  |____ tex

Expliquons un peu. Votre dossier bib contiendra tous vos fichiers bibtex. Le dossier template contient le cls (ou sty) du template que vous allez utiliser pour votre document. Il peut inclure des figures qui seront dans ce dossier aussi. Votre dossier lib contiendra des sty qui ne seront pas dans votre texmf (conseillé si vous travaillez en collaboratif et que vous avez besoin d’un package pas très courant, ou avec une version différente des distributions standardes). Évidemment, fig contiendra les figures qui peuvent être inclues dans votre document. Personnellement, je conseille de créer un dossier src à l’intérieur pour mettre les versions sources (svg, graphml, psd etc…). A vous de gérer la structure de vos sources par la suite. Et enfin, vous avez le dossier src qui contiendra tout vos .tex avec la séparation header/contenu.

Donc là si vous avez déjà tenté ce genre de structure vous êtes en train de penser que je vous enfume. Ouais ! Genre mon includepackage il va pas marcher si c’est dans lib. Scandale ! Petits chanceux, j’ai réponse à votre haine. Il est possible de changer le PATH de latex dans votre source. Mettez ce bout de code, soit dans votre Master.tex, soit dans le fichier inc.tex (suivant si vous avez un cls à inclure en gros) :

\makeatletter \def\input@path{{lib/}{template/}{fig/}{src/}} \makeatother

Et youpi, LaTeX va trouver vos figures, vos packages tout seul. Attention, les bib doivent être placés appelés correctement (car bibtex ne supporte pas le \input@path). Vous n’avez plus qu’à rédiger votre Master.tex qui va bien :

\documentclass[...]{...}
\input{inc}

\begin{document}
    \input{tex}

    \bibliographystyle{...}
    \bibliography{bib/...,bib/...}
\end{document}

Si ça c’est pas la classe !? Comme dit un collègue : How cool is that ?

Plus ?

Voilà en l’état où j’en suis sur mes structures de projet. Par la suite, il faudrait que je me trouve/me fabrique un gestionnaire de macros ou de packages couramment utilisés afin de pouvoir au mieux réutiliser les fichiers créés. Genre, vous êtes à la racine et youpi vous tappez un truc latexproject et vous avez une ligne de commande interactive. Après vous pouvez lister les macros que vous avez déjà fait, les inclure dans le projet (avec des liens symboliques !), supprimer une macro du projet etc… Bref ça enverrait du pâté !

Enjoy !

Categories: Informatique, LaTeX