Qu'estce que Sourcebit?

Dans cet épisode du Smashing Podcast, nous parlons d'un outil open-source intéressant appelé Sourcebit. Comment cela peut-il aider notre flux de travail de contenu avec les sites JAMstack? J'ai parlé au développeur Eduardo Bouças pour le découvrir.

Notes de présentation

Mise à jour hebdomadaire

Transcription

Drew McLellan: Il est développeur Web, technologue, écrivain et conférencier occasionnel avec un solide expérience de travail sur des projets open source. Il travaille en tant qu'ingénieur logiciel sur la plateforme de gestion de site JAMstack, Stackbit, et développe des outils open source tels que Staticman, Speedtracker et Sourcebit. Nous savons donc qu'il est un expert de la plate-forme Web moderne. Mais saviez-vous qu'il est mortellement allergique à mercredi? Mes amis Smashing souhaitent la bienvenue à Eduardo Boucas. Salut, Eduardo, comment vas-tu?

Eduardo Bouças: Je suis en train de casser.

Drew: Je voulais vous parler aujourd'hui d'un outil sur lequel je sais que vous avez travaillé sur appelé Sourcebit. Je sais que vous faites beaucoup de travail à la fois au travail de jour Stackbit, et personnellement à votre rythme, autour d'une sorte d'outillage avec une sorte de ce que nous appelons maintenant des sites JAMstack. Donc, avant de parler de ce que Sourcebit fait lui-même, vous pouvez peut-être nous parler un peu du type de scénario avec le site JAMstack qui pourrait conduire quelqu'un à avoir besoin d'un outil comme Sourcebit.

Eduardo: Bien sûr. Donc, pour remonter un peu dans le temps lorsque j'ai commencé à utiliser un générateur de site statique. Ma première rencontre avec un JAMstack a été avec Jekyll, comme je suis sûr que beaucoup de gens le sont aussi. Et quand j'ai commencé à utiliser Jekyll pour mon site, l'expérience de création était un peu lourde. Cela impliquait donc de modifier manuellement les fichiers Markdown sur ma machine locale, puis de les pousser pour obtenir le dépôt et ensuite la chose serait intégrée et construite. Et c'est toujours un flux de travail qui existe aujourd'hui et que beaucoup de gens utilisent et cela a du sens pour beaucoup de gens dans beaucoup d'organisations. Mais, tout d'abord, cela ne fonctionne pas très bien si vous avez comme une équipe plus grande et surtout si vous avez des gens d'horizons moins techniques qui ne sont peut-être pas à l'aise avec Markdown ou avec Git ou avec tout cela poussant vers un dépôt GitHub

Eduardo: Et il est donc très logique, à mon avis, de coupler un générateur de site statique avec ce que l'on appelle aujourd'hui un CMS sans tête ou découplé. Donc, si vous venez d'un contexte de développement Web plus traditionnel où vous pouvez utiliser quelque chose comme WordPress, un CMS sans tête est quelque chose qui se comporte de manière très similaire. Donc, vous avez toujours cette interface où vous pouvez créer votre contenu, et vous avez un bel éditeur WYSIWYG et une gestion des médias et tout.

Eduardo: Mais la sortie d'une telle plate-forme n'est pas une page HTML entièrement formatée. Et au lieu de cela, le contenu est exporté d'une manière dans un format qui est indépendant de toute technologie ou de toute pile technologique. Et pour que le contenu soit, il est possible d'intégrer ce contenu avec votre générateur de site statique. Et c'est pourquoi je pense qu'il est très logique de coupler un CMS sans tête avec un générateur de site statique, car vous obtenez en quelque sorte le meilleur des deux mondes en ce sens que vous obtenez les performances, la sécurité et la simplicité d'utilisation d'un site statique générateur, mais en même temps, vous obtenez toujours une sorte d'expérience de création riche en utilisant une belle interface éditoriale.

Eduardo: Et même si cela a beaucoup de sens de coupler ces deux outils ensemble, ce n'est pas particulièrement simple de les intégrer. Surtout si vous utilisez un générateur de site statique basé sur des fichiers plus traditionnel, comme Jekyll ou Hugo, où tout doit vivre en tant que fichier. Alors, comment prenez-vous ce contenu qui vit dans ce CMS sans tête? Et comment traduire cela en fichiers que votre générateur de site statique peut comprendre et traiter?

Eduardo: Comme vous l'avez dit, je suis très passionné par la création d'outils pour les développeurs et en particulier par la création d'outils permettant aux développeurs d'utiliser le Paradigme JAMstack avec le moins de friction possible. Et c’est là que la source entre en jeu. C’est pourquoi je suis particulièrement passionné par ce projet. L'idée est donc que Sourcebit vous permet de vous connecter à n'importe quelle source de données basée sur une API telle qu'un CMS sans tête, vous lui dites en quelque sorte où se trouve votre contenu, vous l'aidez à comprendre la structure de votre contenu. Et puis Sourcebit s'occupe de sucer tout ce contenu et de l'écrire dans les fichiers avec les formats dans un générateur de site statique à l'emplacement attendu. C'est donc en quelque sorte l'idée derrière Sourcebit.

Drew: Donc, plutôt que de laisser les auteurs travailler directement avec les fichiers de démarque, que votre générateur de site statique se transforme en site, vous avez fait travailler vos auteurs avec un autre outil, un CMS sans tête, peut-être quelque chose comme Contentful ou même WordPress, puis Sourcebit est le bit entre les deux qui obtient ce contenu d'où il a été créé, et le traduit d'une manière dans un format que le générateur de site statique peut transformer en un site statique?

Eduardo: Exactement, oui. Et de la façon dont cela pourrait, voyez en quelque sorte deux façons différentes d'utiliser l'outil qui peuvent aider les développeurs. L'une consiste à intégrer Sourcebit à votre routine de déploiement. Donc, si vous utilisez une plate-forme d'hébergement comme Netlify, par exemple, et que vous configurez vos commandes de déploiement pour être une build Hugo, est-ce la commande build pour Hugo ou quelque chose comme ça, donc la commande qui génère les fichiers statiques pour Hugo, vous aurait également une autre commande dans le cadre de cette routine. Ce serait quelque chose comme l'extraction de Sourcebit. Et donc au moment de la construction, Sourcebit va extraire toutes les autres données, générer tous les fichiers dont Hugo a besoin. Et puis l'ensemble du déploiement utilisera déjà ces fichiers et déploiera tout le contenu provenant du CMS. Voilà donc un cas d'utilisation possible pour Sourcebit.

Eduardo: L'autre consiste à utiliser Sourcebit dans un flux de travail de développement local. Vous pouvez donc exécuter Sourcebit avec quelque chose que nous appelons le mode veille. Et donc Sourcebit continue de chercher des changements dans la source de données distante, donc dans ce cas, un CMS sans tête. Et donc chaque fois que vous publiez un article ou que vous modifiez une entrée dans CMS Sourcebit le reconnaîtra et il régénérera tous les fichiers pour vous localement. Et donc ce que cela signifie pour un développeur travaillant localement, c'est que vous pouvez avoir votre fenêtre CMS à côté de votre site Jekyll ou Hugo, s'exécutant localement, et vous pourrez alors voir les changements se produire en temps réel. Vous changez quelque chose sur le CMS, puis vous pouvez voir ce changement se refléter du côté local, ce que je trouve super utile. Donc, ce sont les deux façons d'utiliser Sourcebit.

Drew: Donc, pour que tout cela fonctionne, Sourcebit doit connaître à la fois le système dans lequel le contenu est stocké et la façon dont le statique le générateur de site a besoin des fichiers organisés dans le système de fichiers. Comment ces deux choses fonctionnent-elles?

Eduardo: Sourcebit est une architecture basée sur des plugins. L'idée est donc que vous allez avoir différents types de plugins qui accompliront différentes tâches. Nous avons quelque chose que nous appelons les plugins source, qui sont les seuls responsables de la connexion à une source de données comme Contentful, par exemple, et ils se connecteront à cette source de données, ils tireront du contenu et normaliseront ce contenu dans un format qui est sorte d'agnostique de source de données de sorte que si vous souhaitez connecter plusieurs sources de données, vous utilisez donc WordPress et Contentful, et Sanity, par exemple, tout le contenu de ces sources de données sera normalisé dans un format qui est un peu normalisé à travers le conseil d'administration. Donc, la responsabilité des plugins source sera juste de cela, pour se connecter à une source de données, normaliser le contenu et les mettre dans un seau de données.

Eduardo: Et puis vous avez un autre type de plugin que nous appeler un plugin cible. Et le plugin cible n'a aucune connaissance de l'origine des données, mais il connaît un logiciel particulier qui attend ces données par exemple, vous pourriez avoir un plugin cible pour Hugo un plugin cible pour Jekyll. Ainsi, le plug-in cible sera responsable de l'écriture de ces données dans un format spécifique et aux emplacements spécifiques que le site statique généré attend.

Eduardo: Et puis vous pourriez avoir d'autres types de plugins qui ne connaissent pas la source et je ne sais pas sur la destination. Ils sont juste responsables de masser les données et de faire toutes sortes de transformations entre les deux. Voilà donc comment l'organisation est organisée. Et je pense que l'avantage de cette approche est que chaque plugin n'est concerné que par un domaine spécifique. Donc, si vous l'êtes, disons que vous maintenez le plugin source pour Contentful, vous n'avez jamais à vous soucier des générateurs de sites statiques qui seront pris en charge. Vous n'avez qu'à vous soucier de la maintenance de ce plugin spécifique que nous prenons soin de nous assurer qu'il peut être connecté à n'importe quelle combinaison de générateurs de sites statiques ou de différentes sorties que vous souhaitez utiliser.

Drew: Il est donc possible de avoir plusieurs sources en même temps et utiliser un Sourcebit plus comme un agrégateur de contenu pour les extraire de nombreuses sources différentes à la fois?

Eduardo: Oui, oui, c'est tout à fait possible. Et c'est pourquoi nous utilisons ce principe de normalisation des données, car vous pouvez avoir autant de sources de données que vous le souhaitez. Et puis, quand un plugin arrive pour transformer ces données, peu importe d'où viennent les données, tout est traité de la même manière. Il est donc tout à fait possible de le faire. Vous pouvez configurer autant de plugins sources que vous le souhaitez. Et donc ça va extraire des données d’autant d’endroits que vous voulez.

Drew: Ouais, ça pourrait être assez intéressant. Pourriez-vous penser à un site Web d'entreprise pourrait avoir un blog là-dedans, il pourrait avoir une copie du marketing, il pourrait y avoir des offres d'emploi provenant d'un système RH. Et vous pourriez potentiellement configurer Sourcebit pour tirer cela en un seul endroit avant de générer le site, ce qui est une perspective assez excitante, je pense.

Eduardo: Ouais, ouais. Et le CMS n'est qu'une source de données possible avec laquelle vous pourriez utiliser cet outil. Par exemple, un de mes collègues qui a commencé à créer un plugin source qui extrait des données de Reddit, par exemple. Et ce n'est là qu'un exemple très simple d'une source de données possible. Donc, comme vous le dites, cela pourrait devenir très intéressant parce que vous pourriez extraire des données d'un CMS, peut-être des données de Reddit, Twitter ou d'une plate-forme RH et tout se résume bien. Donc, oui, c'est certainement un cas d'utilisation possible.

Drew: Quels types de plugins existent actuellement pour différentes sources?

Eduardo: Nous avons donc lancé le premier type de public version de l'outil la semaine dernière. Et nous avons lancé avec deux plugins sources et deux plugins cibles. Les plugins sources sont donc pour Contentful et Sanity. Et les plugins cibles sont pour Jacqueline et Hugo. Nous continuerons à travailler sur vos plugins en interne chez Stackbit. Mais notre objectif est que la communauté finisse par s'approprier l'outil, comme c'est un projet de licence MIT entièrement open source. Et donc nous aimerions voir des gens créer leurs plugins et créer des trucs avec Sourcebit auxquels nous n'avons même pas pensé. C’est donc le but ultime. Nous avons été en contact avec des personnes de différentes sociétés CMS qui souhaitent également créer leurs plugins. Nous sommes donc en contact permanent avec eux. J'espère donc que nous verrons bientôt un bel écosystème de plugins.

Drew: À quel point est-ce complexe de développer un plugin si vous avez un système complètement personnalisé avec lequel vous savez que vous devez vous intégrer? Est-ce une tâche difficile très impliquée de développer un plugin ou est-ce plus facile que cela?

Eduardo: Je suis un peu partisan de répondre à cela. J'aime penser que c'est simple et j'ai fait de mon mieux pour rendre le processus simple et aussi très bien documenté. Nous avons donc l'un des référentiels que nous mettons à disposition est une sorte d'exemple de plugin, où nous avons un code source entièrement annoté pour un plugin. Nous avons donc des commentaires sur chaque fonction possible que vous pourriez implémenter décrivant les arguments qu'elle reçoit, comment vous pouvez utiliser cette fonction pour obtenir des données à partir de cela, etc. J'espère donc que ce sera une ressource très utile. Nous avons également des pages de documentation où nous décrivons en quelque sorte l'anatomie d'un plugin, comme la façon dont il tire les données là où il est censé les pousser. J'espère donc que c'est un processus assez simple.

Eduardo: Mais différents systèmes présenteront des défis différents. Je suis donc sûr qu'il y aura des suggestions et des demandes de fonctionnalités de la part d'une personne de la communauté disant: «Je veux m'intégrer à ce système. J'ai donc en quelque sorte besoin d'un moyen de le faire. » Et nous serons plus qu'heureux de répondre à ces demandes et de travailler avec la communauté pour améliorer l'architecture du plugin au fil du temps.

Drew: Et tout est écrit, je suppose que c'est le nœud JavaScript?

Eduardo: Ça l'est.

Drew: J'ai remarqué que vous avez mentionné plus tôt que vous pouvez exécuter Sourcebit avec un indicateur de surveillance, et cela vous aidera à avoir une sorte de flux de travail de mise à jour en direct. Est-ce quelque chose qui doit être implémenté par le plugin source, ou est-ce un système général? Est-ce un mécanisme d'interrogation ou écoutez-vous des trucs et des trucs du système source?

Eduardo: L'application principale est très allégée, et elle n'a pas du tout d'opinion. Il appartient donc à chaque plugin source d'implémenter cette fonctionnalité. Tout ce que l'application de base fait à cet égard, c'est qu'elle indique au plugin quelles sont les options proposées par l'utilisateur. Donc, dans les deux plugins que nous avons lancés, nous en avons un pour Contentful et un pour Sanity, la façon dont le mode de veille est implémenté dans chacun d'eux est très différente. Par exemple, dans Contentful, nous avons, comme je l'ai mentionné, un mécanisme d'interrogation dans un intervalle de temps régulier, comme l'interrogation des changements tandis que pour Sanity, nous avons comme une socket Web en cours d'exécution qui écoute constamment les changements et répond aux changements. Mais en gros, l'idée est que le plugin source implémente son propre mécanisme d'écoute et qu'il est responsable de dire à l'application principale que j'ai du nouveau contenu, veuillez vous mettre à jour. C’est le genre d’idée de domaine.

Drew: Cela semble être un système assez flexible qui devrait faire face à de nombreuses sources différentes et différents types de système.

Eduardo: Oui. J'allais juste dire comme toujours sur ce sujet de la flexibilité, une chose que je voulais aussi mentionner est que Sourcebit est configuré à l'aide d'un fichier JavaScript. Donc, si quelque chose de similaire à ce que vous feriez avec certains comme web pack, par exemple, bien qu'un peu plus simple. Et vous avez donc la possibilité de configurer manuellement chacun des plugins sur ce fichier. Mais nous proposons également cette interface de ligne de commande, où fondamentalement chaque plugin est capable de dire à l'application principale l'ensemble des questions qu'elle doit poser à l'utilisateur afin de se configurer. Donc, fondamentalement, lorsque vous exécutez npx create-sourcebit, il peut tout créer à partir de zéro pour vous.

Eduardo: Il tire donc une liste de tous les plugins disponibles pour avoir la possibilité de s'asseoir sur un plugin source pour Contentful et le plugin cible pour Jekyll, par exemple. Et puis, en fonction des plugins que vous choisissez, il vous pose ensuite une série de questions qui mèneront finalement à un fichier JavaScript entièrement configuré. Par exemple, pour Contentful, il vous demandera vos informations d'identification, comme comment accéder à votre compte Contentful? Et puis, il extraira tous les types de contenu de Contentful. Et je vous le demande, j'ai trouvé ce type de contenu appelé articles de blog. Qu'est-ce que c'est? Est-ce que c'est comme une page? S'agit-il d'un objet de données? Et s'il s'agit d'une page, où dois-je la stocker? Quel type de champs dois-je utiliser pour la mise en page du contenu?

Eduardo: Je pense que c'est une manière très conviviale de configurer l'ensemble du projet. Donc, espérons-le, à la fin de ce processus de configuration, vous pouvez simplement exécuter une commande et vous pouvez extraire le contenu immédiatement sans avoir à jouer avec les fichiers JavaScript.

Drew: Donc, ce processus de configuration répondant à ces questions, écrit ensuite le fichier de configuration JavaScript pour vous, que vous pouvez ensuite vraisemblablement simplement valider dans votre contrôle de source et distribuer à d'autres développeurs sur votre projet ou dans votre processus de génération pour l'exécution en direct. Vous avez mentionné un troisième type de plugin distinct de la source et de la cible qui fonctionne sur les données dans ce format agnostique au milieu. Pour quel type de scénarios imaginez-vous que cela est utilisé?

Eduardo: Nous avons créé un plugin qui est responsable de la transformation des actifs. Donc, pour vous donner un exemple, supposons que j'utilise Contentful, et que des images soient intégrées dans un article de blog. Et par défaut, si vous extrayez simplement ces données de Contentful, les images utiliseront une URL en direct de Contentful CDN qui est une option totalement viable si c'est ce que vous souhaitez utiliser. Mais vous voudrez peut-être plutôt servir les images à côté du contenu. Ayez-les donc dans votre référentiel et servis à partir du service que vous utilisez pour servir sur le site également. Et pour que ce plugin soit spécifique, il recherchera tous les actifs qui utilisent, il les tirera vers le bas, les télécharger essentiellement vers votre référentiel ou vers votre système de fichiers local qu'il pourra ensuite pousser.

Eduardo: Et il remplacera toutes les URL de vos fichiers qui référencent cette URL distante, il remplacera celles avec des références aux fichiers locaux à la place. Donc, fondamentalement, lorsque vous poussez le site, vous poussez le contenu et les actifs et tout fonctionnera de manière transparente. Donc, c'est un exemple d'un type de plugin de transformation qui ne tire pas. Ce n'est pas spécifique à une source de données et ce n'est pas spécifique à un générateur de site statique.

Drew: Vous avez mentionné qu'il existe des plugins cibles pour Jekyll et Hugo, y en a-t-il que vous vous attendez à voir dans un avenir proche?

Eduardo: Eh bien, je suis un grand fan d'Eleventy. J'espère donc vraiment voir un plugin Eleventy sortir assez bientôt. Et puis je suppose qu'il existe des générateurs de sites statiques qui ont déjà leur propre type d'écosystème de plugins. Je suis donc curieux de voir si les gens trouveront toujours un besoin d'avoir un plugin source pour ces types de générateurs de sites statiques. Soit dit en passant, vous pouvez utiliser Sourcebit de la même manière que si vous utilisez quelque chose comme Next.js, comme n'importe quel générateur de site statique basé sur un nœud. Vous n'avez pas nécessairement besoin d'un plugin cible, vous pouvez simplement avoir besoin de Sourcebit comme module NPM, et vous pouvez exécuter tous les mécanismes de récupération des données. Vous pouvez simplement les exécuter comme dans les fonctions de mémoire et rendre votre contenu disponible dans le cadre de vos pages Next.js. Pour répondre à votre question, je suppose que pour ceux que nous ne verrons pas spécifiquement les plugins cibles, mais nous pouvons déjà utiliser Sourcebit de cette façon. En ce qui concerne les prochains plugins source, je m'attendrais à voir Eleventy et peut-être quelques autres types de générateurs de sites statiques basés sur des fichiers dans un avenir proche.

Drew: Tout cela est très excitant, je pense. Est-ce juste que vous travaillez dessus en termes de développement ou y a-t-il une plus grande équipe?

Eduardo: J'ai été en quelque sorte le développeur principal qui y travaille, mais c'est un effort d'équipe. C'est donc quelque chose qu'un groupe de personnes chez Stackbit a identifié comme un problème. Et nous avons travaillé ensemble sur le type de spécification et la bonne façon d'aborder cela. Il se trouve que je suis le gars qui appuie sur les touches pour y arriver.

Drew: Et je suppose que Sourcebit peut en fait être très utile pour les clients de Stackbit, ce qui est la motivation de Stackbits pour développer et contribuer à cela, mais évidemment, ça va pour être utile à un public beaucoup plus large que les seuls clients de Stackbit.

Eduardo: Oui, nous avons de grands projets pour Sourcebit en interne. Cela nous aidera vraiment à réaliser notre mission en termes de rendre JAMstack, accessible au plus grand nombre de personnes possible, mais nous voulions nous assurer que nous partagions ce projet particulier avec la communauté parce que nous pensons que cela va aider beaucoup de gens qu'ils soient intéressés ou non à utiliser Stackbit. C'est pourquoi c'est un projet entièrement open source.

Drew: C'est super. Y a-t-il autre chose que vous aimeriez nous dire à propos de Sourcebit?

Eduardo: Non. J'aimerais simplement que les gens l'essayent. Je suis sûr que nous pouvons partager des liens pour aimer le repo et des trucs comme ça. Il y a une vidéo YouTube dans le référentiel principal, qui montre à quoi ressemble l'expérience lorsque vous utilisez Sourcebit avec un CMS sans tête et un générateur de site statique. Donc, cela vous donne une idée de ce que c'est que d'utiliser la CLI et de l'ensemble du processus de configuration interactive, et j'aimerais simplement que les gens l'essayent. Et contactez-les s'ils pensent que cela pourrait être amélioré ou si c'est terrible, ou si c'est génial, ou si cela les aide. Alors oui, j'aimerais entendre des gens.

Drew: C'est super. Nous lierons tout cela à partir des notes de l'émission, mais également Sourcebit sur github.com/stackbithq/sourcebit. J'ai donc tout appris sur Sourcebit aujourd'hui, qu'avez-vous appris récemment?

Eduardo: Je suis très intéressé par l'apprentissage de Serverless. Et j'essaie en fait d'en apprendre le plus possible à ce sujet depuis quelques mois. C’est un concept qui m’intéresse beaucoup. C’est un de ces changements sismiques dans votre approche du développement. Et je suis très intéressé par le type de cas d'utilisation dont il dispose et par les différentes façons de repenser la façon dont vous créez une application pour Serverless. C'est donc quelque chose que j'essaie de lire autant que possible et de simplement jouer et essayer, comme des projets parallèles. Oui, c'est un domaine qui me passionne énormément.

Drew: C'est très intéressant, n'est-ce pas? Un changement dans la façon dont vous devez penser les projets?

Eduardo: Certainement, définitivement. Il y a une métaphore, et je ne veux pas parler de Serverless ici, c'est qu'une métaphore qui je pense est vraiment utile est de penser à Serverless comme une sorte d'utiliser Uber plutôt que de posséder une voiture, comme cela vous oblige à, vous avez toujours une voiture, comme le terme Serverless est peut-être un peu trompeur parce que vous avez toujours un serveur, mais si vous avez une voiture, vous pourriez juste laisser vos affaires dans la voiture parce que vous savez qu'elle sera là le lendemain, alors que si vous utilisez chez Uber, cela vous oblige à repenser et à reconnaître que chaque jour, vous allez obtenir une nouvelle voiture avec des personnes différentes qui la conduisent, et il suffit d'adapter votre façon de contourner ce fait. Donc, cette métaphore m'a vraiment aidé à comprendre ce paradigme sans serveur.

Drew: Oui, je n'avais jamais entendu cela auparavant, c'est une façon assez intéressante de voir les choses. Si vous, cher auditeur, souhaitez en savoir plus sur Eduardo, vous pouvez le suivre sur Twitter, où il est @Eduardoboucas. Et vous pouvez trouver ses temps de construction périodiques de développement Web sur Eduardoboucas.com. Merci de nous rejoindre aujourd'hui. Eduardo. Avez-vous des mots d'adieu?

Eduardo: Non, pas vraiment. Tout d'abord, merci beaucoup de m'avoir invité. Ce fut un plaisir. Et à propos cette prononciation bizarre pour mon nom de famille, je devrais peut-être dire que c'est le cas, si vous voulez trouver mon pseudo Twitter et mon site Web, le nom de famille est B-O-U-C-A-S. Boucas est une autre prononciation portugaise bizarre si vous voulez trouver, c'est Eduardoboucas. Alors, merci beaucoup de m'avoir invité. Ce fut un plaisir.

Drew: Merci beaucoup.

(dm, ra, il)