[00:00.000 --> 00:14.760]  Creating a content pipeline with Intora, welcome to this talk here at Boston.
[00:14.760 --> 00:20.440]  Watch this talk to learn how to use ASCII.content from multiple sources for multiple websites
[00:20.440 --> 00:23.240]  and other downstream processes.
[00:23.240 --> 00:28.120]  In this talk Fabrice and I show you what problems were solved in the Eclipse chip project to
[00:28.120 --> 00:35.720]  allow for a shift left in the creation of the content and to automate all the things.
[00:35.720 --> 00:40.240]  After describing why there was a need to change and what was used in the solution, there's
[00:40.240 --> 00:45.200]  a demo showing how to use the different building blocks together.
[00:45.200 --> 00:47.960]  Let's get started and let us introduce ourselves.
[00:47.960 --> 00:51.840]  I'm happy to introduce to you Fabrice Flortable.
[00:51.840 --> 00:57.120]  He's also working at Red Hat together with me on a very different project, though his
[00:57.120 --> 01:02.240]  superpowers were to know the ways within Red Hat about documentation, so it helped
[01:02.240 --> 01:08.880]  me a lot to figure out how to feed downstream processes, something that I wouldn't have
[01:08.880 --> 01:11.280]  been able to figure out without him.
[01:11.280 --> 01:20.040]  He was willing to do things differently than before, so we tried out new stuff and he was
[01:20.040 --> 01:23.200]  volunteering to use that in the Eclipse chip project.
[01:23.200 --> 01:29.040]  He was then working at the time and the superpower of Fabrice is that he's both a technical writer
[01:29.040 --> 01:35.160]  and he can do programming and can do automation, as probably due to his previous life.
[01:35.160 --> 01:43.080]  He's been working in the automation and Ansible world quite a bit, so that's a very, very
[01:43.080 --> 01:45.400]  valuable skill for a technical writer.
[01:45.400 --> 01:48.840]  Thanks for having that and bringing that to the project.
[01:48.840 --> 01:53.720]  Today with me we have Alexandre Schwarz.
[01:53.720 --> 02:03.160]  First is the author of the IntelliJ ASCII DOC plugin that has Antora support and that's
[02:03.160 --> 02:13.760]  a game changer for all the authors who are playing with ASCII DOC and Antora in the world,
[02:13.760 --> 02:19.880]  so that's our first reason for being a superhero.
[02:19.880 --> 02:27.200]  Also Alexandre has a meetup that happens, I don't know, one per month, maybe less, of
[02:27.200 --> 02:33.200]  our topics that are relevant to documentation, so that's a very interesting meetup.
[02:33.200 --> 02:38.640]  What is the context of, in terms of content management and collaboration that we have
[02:38.640 --> 02:39.640]  here with Fabrice?
[02:39.640 --> 02:41.560]  Can you introduce us to the topic?
[02:41.560 --> 02:49.160]  Yeah, so the big picture is, let's apply the shift left principle to content management.
[02:49.160 --> 02:56.360]  So I work at Redat and at Redat we have a successful development model, which is we
[02:56.360 --> 03:03.320]  develop things upstream and then we transform the upstream project into a downstream product
[03:03.320 --> 03:09.560]  and we call it productization or downstreaming and moving the development effort from the
[03:09.560 --> 03:15.120]  product to the upstream project, that's what we call the shift left.
[03:15.120 --> 03:19.320]  Is this model also driving documentation?
[03:19.320 --> 03:25.320]  For the most part of it, the answer is no, that's not good, but it can change and probably
[03:25.320 --> 03:27.120]  it should change.
[03:27.120 --> 03:34.920]  So how do we apply this model, this shift left model to the documentation?
[03:34.920 --> 03:41.160]  So that's simple, you take your technical writers who are usually bound to the product
[03:41.160 --> 03:46.040]  and you let them contribute to the upstream project and you let them collaborate with
[03:46.040 --> 03:50.160]  engineers, that's super simple.
[03:50.160 --> 04:00.200]  For upstream, there is an immediate benefit, the community has an enterprise-grade documentation,
[04:00.200 --> 04:06.200]  so it means better docs, of course better docs because if you pay your writers and you
[04:06.200 --> 04:12.000]  don't have better docs at the end, what would be the sense of it?
[04:12.000 --> 04:19.240]  Good docs has been identified commonly as a key feature for a successful community.
[04:19.240 --> 04:27.480]  So we have multiple questions and thoughts that are saying that people look at the docs
[04:27.480 --> 04:34.640]  first when they come to a project and good docs means people go a little bit forward and
[04:34.640 --> 04:40.960]  just looking at the marketing homepage and maybe they stay a little bit longer.
[04:40.960 --> 04:47.200]  So in the end, it means happy community, good docs means happy community, happy community
[04:47.200 --> 04:52.160]  means probably users and then customers.
[04:52.160 --> 04:53.480]  So that's good.
[04:53.480 --> 05:01.480]  For upstream, obvious, but for downstream, because you're making things maybe more complex
[05:01.480 --> 05:07.160]  or you put your technical writers in a place where they are not used to go, so that can
[05:07.160 --> 05:08.160]  be difficult.
[05:08.160 --> 05:11.160]  But too many good benefits.
[05:11.160 --> 05:15.560]  So the first one is you scratch multiple Bufalo with one stick.
[05:15.560 --> 05:20.800]  You write your content once and you can publish it in multiple places.
[05:20.800 --> 05:24.880]  The second one is your content grows faster.
[05:24.880 --> 05:32.960]  Your writers can focus on enhancing the content that the community is producing and they are
[05:32.960 --> 05:35.120]  more productive.
[05:35.120 --> 05:37.360]  So that's the second one.
[05:37.360 --> 05:41.840]  Third one is the time to market because you automate everything, of course.
[05:41.840 --> 05:49.800]  So the documentation that is produced in the open, it lands immediately in the product.
[05:49.800 --> 05:55.600]  And that's something that is really important, is that you have merged your content in the
[05:55.600 --> 06:03.200]  project and you have a documentation, a product documentation that has it directly.
[06:03.200 --> 06:09.120]  I mean, there are cases where the documentation is written in the community, but you don't
[06:09.120 --> 06:16.320]  have technical writer there and the role of technical writer very often is a police
[06:16.320 --> 06:17.320]  role.
[06:17.320 --> 06:23.280]  Or yes, okay, that's okay for a community, but for a product documentation, you should
[06:23.280 --> 06:25.240]  not write it like this, like that.
[06:25.240 --> 06:27.080]  So it takes time.
[06:27.080 --> 06:35.520]  Something that you can write in five minutes and it's okay in a wiki upstream, then it
[06:35.520 --> 06:42.880]  needs to comply to more rules when you write it for downstream.
[06:42.880 --> 06:46.920]  So how do we solve this pain or this problem?
[06:46.920 --> 06:53.080]  So here we have two places where we can push left.
[06:53.080 --> 07:01.880]  Push left for docs, it means single sourcing and single sourcing as much as you can.
[07:01.880 --> 07:10.640]  It means you write your content to both left as you can in the chart and everywhere else,
[07:10.640 --> 07:14.920]  you just use it and you don't, you don't read it.
[07:14.920 --> 07:17.040]  Left means upstream for you, right?
[07:17.040 --> 07:21.320]  Left is upstream, it's in the open source and immediately when the code is being written
[07:21.320 --> 07:22.320]  in the first place.
[07:22.320 --> 07:25.280]  We have two opportunities to shift left here.
[07:25.280 --> 07:34.560]  That's the first one is to get content from the source code of the application.
[07:34.560 --> 07:39.760]  Exactly the content strings that are used in the user interface.
[07:39.760 --> 07:46.680]  So in a configuration field, the description, the description field is micro content.
[07:46.680 --> 07:49.720]  You can reuse it in the docs directly.
[07:49.720 --> 07:55.920]  So you can build your reference guide based on the strings that are present in the docs
[07:55.920 --> 07:57.360]  and you can automate that.
[07:57.360 --> 08:04.200]  When you do that, if a configuration field is removed, then the configuration field
[08:04.200 --> 08:06.440]  is removed from the docs too.
[08:06.440 --> 08:15.400]  If there is a new field that appears, then the next iteration on documentation publication
[08:15.400 --> 08:18.440]  will publish that new field.
[08:18.440 --> 08:19.440]  So that's important.
[08:19.440 --> 08:26.680]  I mean, that's not the main focus of this talk here, but that's something where you
[08:26.680 --> 08:31.840]  can write ad hoc scripts with your preferred language.
[08:31.840 --> 08:35.680]  That's quite a common problem in docs, I believe.
[08:35.680 --> 08:47.560]  The other shift left moment, the shift left opportunity is to have your content written
[08:47.560 --> 08:50.720]  in the upstream project and not in the downstream product.
[08:50.720 --> 08:53.400]  Really, you write the content upstream.
[08:53.400 --> 08:57.760]  You don't do any authoring of content downstream.
[08:57.760 --> 09:02.640]  It's not something where you copy, paste files and you write it down.
[09:02.640 --> 09:06.520]  There is no human interaction.
[09:06.520 --> 09:08.960]  There is no human adaptation.
[09:08.960 --> 09:13.840]  It's a fully automated process.
[09:13.840 --> 09:14.840]  And it's important.
[09:14.840 --> 09:17.840]  That's the fully automated process.
[09:17.840 --> 09:23.800]  This part is quite hard because you have to identify all the variations and you have
[09:23.800 --> 09:33.440]  to find a solution for every single point where there is a variation in content.
[09:33.440 --> 09:35.800]  Can you give an example for such a variation?
[09:35.800 --> 09:42.720]  We have to dress up a map of these variations and the first kind of variation, it's in-line
[09:42.720 --> 09:43.720]  content.
[09:43.720 --> 09:51.520]  For example, your project has a name, your product has a name, it's not the same.
[09:51.520 --> 09:56.680]  The project has a version, the product version is not the same.
[09:56.680 --> 10:04.160]  In the project I work on for three years, for example, the project is called Eclipse
[10:04.160 --> 10:05.160]  Che.
[10:05.160 --> 10:11.280]  The product is called Dev Spaces or right at OpenShift Dev Spaces.
[10:11.280 --> 10:16.520]  The project is working on Kubernetes.
[10:16.520 --> 10:19.440]  The orchestrator is Kubernetes.
[10:19.440 --> 10:24.680]  For the downstream product, the orchestrator is OpenShift.
[10:24.680 --> 10:29.440]  OpenShift is just a distribution of Kubernetes but the product is not meant to be installed
[10:29.440 --> 10:32.080]  on Kubernetes in any version.
[10:32.080 --> 10:34.120]  So that makes a difference.
[10:34.120 --> 10:42.080]  So that's good for a couple of words, a sentence, maximum, less than a paragraph.
[10:42.080 --> 10:44.000]  You can work like that.
[10:44.000 --> 10:52.080]  Then you have block content and block content, so it's more than one sentence, more than
[10:52.080 --> 11:03.760]  one paragraph, code block, image, screenshots, table, diagram, full procedure, a full set
[11:03.760 --> 11:05.840]  of procedure.
[11:05.840 --> 11:08.120]  It can be a lot of things.
[11:08.120 --> 11:15.600]  When you have three cases, you have content upstream different from content downstream.
[11:15.600 --> 11:21.160]  You have a content that is upstream and that is not downstream, and a content that is downstream
[11:21.160 --> 11:23.040]  and that is not upstream.
[11:23.040 --> 11:32.000]  So it means that at this point it's quite complex.
[11:32.000 --> 11:39.960]  But there is another problem which is maybe specific to Red Hat, but I'm not sure.
[11:39.960 --> 11:45.400]  It's how can you use modern tools in upstream?
[11:45.400 --> 11:50.880]  How can you have some freedom in the tools that you are using in upstream?
[11:50.880 --> 11:56.720]  When you have a downstream tool chain that is very specific and that has very specific
[11:56.720 --> 11:57.720]  requirements.
[11:58.400 --> 12:10.720]  And in my case, so in Red Hat's case, the customer portal publication tool chain is quite old.
[12:10.720 --> 12:15.720]  It's normal because when you have to move, you have to move the tool chain for all the
[12:15.720 --> 12:21.840]  products, so it's something that moves much, much slower than a project.
[12:21.840 --> 12:30.440]  But then it's how can you provide, how can you satisfy the downstream tool chain and
[12:30.440 --> 12:38.440]  still have something that is where you have fun upstream, where you have modern tools
[12:38.440 --> 12:47.440]  and where you just don't do things that the community finds stupid because for the community
[12:47.440 --> 12:48.880]  downstream doesn't exist.
[12:48.880 --> 12:50.960]  So you have also to think about that.
[12:50.960 --> 12:55.800]  For the community, downstream is not a reality.
[12:55.800 --> 13:02.120]  Downstream is just hidden and you cannot say, let's do this for downstream and believe
[13:02.120 --> 13:04.280]  that community will accept that.
[13:04.280 --> 13:06.000]  That's not the case.
[13:06.000 --> 13:07.640]  When it's stupid, it's stupid.
[13:07.640 --> 13:15.840]  So when it's stupid, when it's something that you do only for downstream, the chains
[13:15.840 --> 13:20.600]  that the community accept that is quite low and that's normal.
[13:20.600 --> 13:28.080]  And I believe that's really good because it's pushing the writers to do something better
[13:28.080 --> 13:35.320]  and to re-question some of the processes that you have in downstream.
[13:35.320 --> 13:39.720]  Yeah, and upstream is then the place to innovate to try out new things that then eventually
[13:39.720 --> 13:42.080]  get adopted in other places.
[13:42.080 --> 13:46.320]  So move fast, innovate in the upstream project.
[13:46.320 --> 13:53.280]  So in my experience, the upstream project is super innovative because we are using Antora,
[13:53.280 --> 14:01.920]  but not only Antora, we are using Antora extensions that are still in alpha stage and we are successful
[14:01.920 --> 14:02.920]  with that.
[14:02.920 --> 14:12.040]  So I mean, what we do in upstream is quite exactly the opposite of what we can do in downstream.
[14:12.040 --> 14:22.520]  So we can use alpha software and we can be successful with it and be happy with it.
[14:22.520 --> 14:24.800]  So that is a great introduction to the solution, right?
[14:24.800 --> 14:27.320]  So what do we do in the solution then?
[14:27.320 --> 14:34.000]  What did we use to make this happen, this shift left?
[14:34.000 --> 14:38.360]  We have found everything that we needed in the Antora ecosystem.
[14:38.360 --> 14:42.640]  So that's the thing that is completely unbelievable.
[14:42.640 --> 14:49.480]  Not all the tools were there in the beginning, but now they are there, so now it's time to
[14:49.480 --> 14:55.720]  talk about them because it's almost everything out of the shelves.
[14:55.720 --> 15:00.040]  First thing is Antora in general.
[15:00.040 --> 15:03.920]  So Antora is built to have multiple publications.
[15:03.920 --> 15:07.600]  It's built for an upstream downstream model.
[15:07.600 --> 15:12.720]  So you don't need to add anything to Antora and you can have a publication for upstream
[15:12.720 --> 15:17.960]  with one product name and a publication for downstream with a product name.
[15:17.960 --> 15:21.520]  And you can also have variation on content.
[15:21.520 --> 15:23.120]  It's all built in.
[15:23.120 --> 15:24.800]  That's the first thing.
[15:24.800 --> 15:32.200]  Then to content from some source code, there is a very nice extension called Antora Collector.
[15:32.200 --> 15:40.040]  And Antora Collector, it's more like a tool that lets you use your own code.
[15:40.040 --> 15:46.440]  So it's more kind of a scheduler that will execute a script at real time and make sure
[15:46.440 --> 15:48.240]  that you run it every time.
[15:48.240 --> 15:57.280]  So we are using that, for example, for Shedox to reference guide for the configuration of
[15:57.280 --> 16:00.640]  the application, for example.
[16:00.640 --> 16:09.880]  And the last bit is Antora Assembler, another Antora extension, very new and which is just
[16:09.880 --> 16:20.400]  high checking an extension that is there to produce a PDF and we use it to produce something
[16:20.400 --> 16:25.440]  that is required to do a PDF, but that is very helpful in our case.
[16:25.440 --> 16:35.240]  So Antora Assembler is taking an Antora website, an Antora component, an Antora something
[16:35.240 --> 16:48.280]  and it's processing it and putting everything in one monolithic Shedox file where all the
[16:48.280 --> 16:51.560]  Antora complexity is hidden.
[16:51.560 --> 17:01.680]  And meaning at the end, you can have a publication tool that is very simple and you don't need
[17:01.680 --> 17:06.640]  all the complexity of Antora to do your publication.
[17:06.640 --> 17:12.400]  So Antora Assembler is then the key for us to export it in a way that all our downstream
[17:12.400 --> 17:17.640]  processes can successfully work with all the content upstream.
[17:17.640 --> 17:22.520]  We talked about Antora and its extensions, how they solve things for you and the Eclipse
[17:22.520 --> 17:23.520]  Tray project.
[17:23.520 --> 17:29.320]  So what's the difference for you if a project picks Antora, what's then different than before?
[17:29.320 --> 17:33.520]  What are the unique features that you can benefit from Antora when using it?
[17:33.520 --> 17:40.680]  I can speak in general and I can speak also with a very specific thing in mind.
[17:40.680 --> 17:47.520]  It's because the project was using Jekyll before Antora and we had a problem with Jekyll.
[17:47.520 --> 17:57.880]  So we solved the problem with Antora but there are things that are quite special.
[17:57.880 --> 18:05.480]  First thing is Antora entirely correlates content to the rig and publication.
[18:05.480 --> 18:13.080]  So you can have the playbook, so the playbook that is used for publication in one repository
[18:13.080 --> 18:22.240]  and you can have the UI, so the team, the CSS, the presentation layer in another repository
[18:22.240 --> 18:29.600]  and you can have your content in one repository, multiple repositories, in branches, whatever
[18:29.600 --> 18:30.600]  you want.
[18:30.600 --> 18:35.400]  So it's really this thing is like HTML and CSS.
[18:35.400 --> 18:37.680]  It's the same principle.
[18:37.680 --> 18:45.680]  Antora is leaving somewhere, presentation layer is leaving somewhere and then the things
[18:45.680 --> 18:49.560]  that put all of that together is leaving somewhere else.
[18:49.560 --> 18:55.680]  So that's at the root of Antora, so that's the first thing.
[18:55.680 --> 19:04.040]  And then these things enable content variations and Antora is built to handle content variation.
[19:04.040 --> 19:07.000]  So it's just made for that.
[19:07.000 --> 19:09.040]  That's the thing that is so good.
[19:09.040 --> 19:12.000]  So it's made for an upstream downstream model.
[19:12.000 --> 19:13.000]  It's made of that.
[19:13.000 --> 19:21.800]  So it's supporting ASCII doc attributes out of the box and it's built on the fact that
[19:21.800 --> 19:25.440]  you are using ASCII doc attributes.
[19:25.440 --> 19:32.640]  It's using one feature of ASCII doc which is includes and it's using that everywhere
[19:32.640 --> 19:39.760]  and it's like, so ASCII doc is defining includes generally and Antora is doing a classification
[19:39.760 --> 19:40.920]  of includes.
[19:40.920 --> 19:46.360]  So you have examples, you have images, you have attachments, you have partials which
[19:46.360 --> 19:56.080]  is just a snippet of content that doesn't do a full URL.
[19:56.080 --> 19:58.920]  You can have also distributed components.
[19:58.920 --> 20:05.640]  So it means that you can have one repository where you have the contents and a distributed
[20:05.640 --> 20:09.400]  component where you have additional files.
[20:09.400 --> 20:11.120]  That's what we are using for downstream.
[20:11.120 --> 20:20.280]  So all the images that are specific to the, so the downstream repository has specific
[20:20.280 --> 20:26.760]  examples, specific content, text content are images.
[20:26.760 --> 20:36.760]  So the screenshots that are just with the product UI on it and it's as simple as creating,
[20:36.760 --> 20:44.200]  putting the file in the correct directory and there is not to think about it.
[20:44.200 --> 20:51.760]  When we were, so before as Antora assembler, we were juggling with directories where we
[20:51.760 --> 20:55.200]  overwrite content in this directory but not in this one.
[20:55.200 --> 20:56.200]  It was a mess.
[20:56.200 --> 21:03.520]  It was difficult for people who are, so even for writers, it was difficult to understand.
[21:03.520 --> 21:11.720]  Ah, but my file was overwritten, yes, because this file, you must edit it in upstream first.
[21:11.720 --> 21:17.720]  And with Antora assembler, the upstream files are not in the repository, they are really
[21:17.720 --> 21:18.720]  in a cache.
[21:18.720 --> 21:22.760]  They are just downloaded at build time.
[21:22.760 --> 21:26.760]  They don't appear in the Git history and there is no confusion.
[21:26.760 --> 21:32.920]  So that's one of the big, big, big wins of Antora assembler.
[21:32.920 --> 21:43.120]  And pushing further, Antora Composer, it's the same thing as the content that you generate
[21:43.120 --> 21:45.400]  don't live in the repository.
[21:45.400 --> 21:51.120]  So one, something that is really, really interesting with Antora is that the contents
[21:51.120 --> 21:57.560]  that is in your repository, that is in your Git repository, is the contents that you are
[21:57.560 --> 22:04.600]  authorized to edit and that the contents that comes from another content repository, you
[22:04.600 --> 22:07.560]  don't have to commit it into the repository.
[22:07.560 --> 22:13.680]  And Antora assembler and Antora code collector are using that as a, as a condom.
[22:13.680 --> 22:21.440]  So there is less confusion for the writers, for the authors, for the contributors, because
[22:21.440 --> 22:25.520]  a file that is in Git, it's a file that you can edit.
[22:25.520 --> 22:32.160]  And the problem that we had before is that we had, let's say, we were talking reference
[22:32.160 --> 22:33.160]  guide.
[22:33.160 --> 22:37.640]  So the output of the script was stored in Git.
[22:37.640 --> 22:45.120]  And then when we were doing, when we were doing an edit on another file, the script
[22:45.120 --> 22:51.280]  would update the file and then it would end up in a endless discussion on Git about like,
[22:51.280 --> 22:54.880]  but why are you committing this file?
[22:54.880 --> 22:56.800]  It's not in your content, et cetera.
[22:56.800 --> 22:57.920]  So it was available.
[22:57.920 --> 23:05.360]  That was endless discussion because it was not clear.
[23:05.360 --> 23:09.280]  And with Antora collector and Antora assembler, it's, everything is clear.
[23:09.280 --> 23:11.600]  It's in the repository, you can edit it.
[23:11.600 --> 23:12.600]  Yeah.
[23:12.600 --> 23:16.680]  And on the other hand, everything that's generated will never end up in a repository.
[23:16.680 --> 23:20.200]  Everything that's generated is only accessed in the code where it comes from plus a shell
[23:20.200 --> 23:24.880]  script or whatever else you need to generate it and never going to be committed to Git.
[23:24.880 --> 23:25.880]  Right?
[23:25.880 --> 23:27.720]  It's not committed to Git.
[23:27.720 --> 23:33.720]  We have a build artifact, which is the ASCII doc, the monolithic ASCII doc.
[23:33.720 --> 23:41.600]  But the toolchain require this build artifact to start doing its own build.
[23:41.600 --> 23:47.960]  And then this nice thing is then that Antora assembler, it creates an output that could
[23:47.960 --> 23:52.080]  have come from everywhere and it doesn't really need Antora anymore to render.
[23:52.080 --> 23:55.880]  It's just plain ASCII doc that comes out of that and everybody can render that.
[23:55.880 --> 24:01.480]  Any toolchain that could instead ASCII doc can render that monolithic ASCII doc file
[24:01.480 --> 24:03.000]  that's rendered by Antora assembler.
[24:03.520 --> 24:08.320]  If you say Antora is a great choice with collector, with assembler, still you have to do ASCII
[24:08.320 --> 24:09.320]  doc.
[24:09.320 --> 24:13.120]  So how do you think about ASCII doc and this single sourcing approach?
[24:13.120 --> 24:18.000]  Would you rather use another markup language or are you happy with ASCII doc as it is
[24:18.000 --> 24:19.000]  today?
[24:19.000 --> 24:29.600]  So Antora is so much based on features that are only in ASCII doc that it's difficult
[24:29.600 --> 24:37.880]  to imagine Antora for markdown because it's based on ASCII doc attributes.
[24:37.880 --> 24:43.560]  There is no such thing in the markdown ecosystem or not exactly.
[24:43.560 --> 24:45.760]  So that's one thing.
[24:45.760 --> 24:55.720]  I believe you have projects where you can also use variables that are extending markdown.
[24:55.720 --> 24:57.800]  So that's not impossible.
[24:57.800 --> 24:59.800]  But then the includes.
[24:59.800 --> 25:11.040]  The includes now I'm working on a project using docusers and it's markdown extended.
[25:11.040 --> 25:13.040]  It's different.
[25:13.040 --> 25:15.040]  It's more complex.
[25:15.040 --> 25:25.000]  I find ASCII doc is pretty simple with these include statements that they are simple.
[25:25.000 --> 25:33.000]  They are enabling a lot of things and Antora is based on it.
[25:33.000 --> 25:36.920]  One of the pillar of Antora is attributes.
[25:36.920 --> 25:42.000]  The other one is includes and the other one is cross references.
[25:42.000 --> 25:48.720]  And these are three features that you are very specific to ASCII doc.
[25:48.720 --> 25:56.120]  And of course, ASCII doc has also a very nice feature for the author.
[25:56.120 --> 25:58.000]  Then it's a matter of taste.
[25:58.000 --> 26:15.200]  So I know that we have a discussion with developers about the syntax, the formatting, all of that.
[26:15.200 --> 26:22.680]  That's something where people can be very opinionated.
[26:22.680 --> 26:27.280]  As an author, I really like ASCII doc because it's very consistent.
[26:27.280 --> 26:35.520]  So it's for inline stuff, the syntax is always the same.
[26:35.520 --> 26:38.960]  For block stuff, the syntax is always the same.
[26:38.960 --> 26:44.000]  The tables, there is one implementation of tables and not 20.
[26:44.000 --> 26:49.720]  The punctuation, it's very well defined, so that's good.
[26:49.720 --> 26:51.040]  You have extensions.
[26:51.040 --> 26:52.200]  You have Antora extensions.
[26:52.200 --> 26:57.840]  We talk a lot about them that you have also ASCII doc extensions, meaning you can add
[26:57.840 --> 26:59.240]  the diagrams.
[26:59.240 --> 27:04.240]  So cookie diagram, you can add them into ASCII doc.
[27:04.240 --> 27:15.440]  You have extensions to do PDF, to do presentation with revit.js, to process ASCII doc files
[27:15.440 --> 27:18.440]  directly in your browser.
[27:18.440 --> 27:23.440]  The ecosystem is very much alive.
[27:23.440 --> 27:29.240]  We have created a small demo project which contains Antora, Antora Collector and Antora
[27:29.240 --> 27:30.240]  Assembler.
[27:30.680 --> 27:34.280]  In this demo, I'll walk you through this project.
[27:34.280 --> 27:40.360]  The link to this project is also on the slide with all the links at the end of the talks.
[27:40.360 --> 27:42.320]  Let's have a look at the code.
[27:42.320 --> 27:48.280]  Like all good projects, it has a readme which walks you through what to find here and how
[27:48.280 --> 27:50.120]  to use it.
[27:50.120 --> 27:55.040]  While a real project with Antora is usually split into multiple git repositories, this
[27:55.040 --> 28:02.320]  demo combines everything as single repository as it makes it simpler to run local experiments.
[28:02.320 --> 28:07.360]  Blitting them in multiple repositories allows for advanced features and a separation of
[28:07.360 --> 28:15.160]  different responsibilities for different parts in a production setter.
[28:15.160 --> 28:22.880]  The docs folder contains the same component in two different versions.
[28:22.880 --> 28:27.640]  This version has the standard Antora folder structure.
[28:27.640 --> 28:34.080]  The version 2 also uses Antora Collector to run a script and pick up the generated files
[28:34.080 --> 28:38.080]  as if they would be checked into git.
[28:38.080 --> 28:44.640]  The start page is an Antora component with the special name root.
[28:44.640 --> 28:53.600]  In this example, it also is not versioned, so there is only a single version.
[28:53.600 --> 29:00.760]  Looking at the playbook folder, this contains everything to build the documentation site.
[29:00.760 --> 29:05.840]  It uses note to install and run Antora and its extensions.
[29:05.840 --> 29:10.160]  All dependencies are listed in the package.json file.
[29:10.160 --> 29:15.640]  There are two playbooks, one to build a production site, a second to build an author's preview
[29:15.640 --> 29:21.840]  from the local work tree to show changes which haven't been committed yet.
[29:21.840 --> 29:34.000]  The playbook lists among other things, components, extensions, the UI bundle and ASCII doc attributes.
[29:34.000 --> 29:40.000]  The Antora assembler needs another configuration file to specify how it should create a PDF.
[29:40.000 --> 29:47.200]  Optionally, it can keep the created monolithic ASCII doc file so you can use it in an additional
[29:47.200 --> 29:49.440]  build step.
[29:49.440 --> 29:55.200]  As an alternative, one could use the plugin as a blueprint to create other output files
[29:55.200 --> 29:57.200]  in your own plugin.
[29:58.160 --> 30:04.560]  There's a very small demo extension which accesses the attributes of a page to further
[30:04.560 --> 30:05.840]  process them.
[30:05.840 --> 30:13.200]  In this example, it prints the front-meter attributes of an ASCII doc page on the console.
[30:13.200 --> 30:20.200]  The supplemental UI folder contains several small customizations for the default Antora
[30:20.200 --> 30:21.840]  theme.
[30:21.840 --> 30:26.360]  Depending on your production setup, a full custom theme might be better.
[30:26.360 --> 30:31.720]  Have a look at the Antora UI projects for details on how to do this.
[30:31.720 --> 30:36.080]  For this demo, it was sufficient to override some of the partials of the original theme
[30:36.080 --> 30:42.240]  with modified partials, for example, for the header, the footer and the outdated page banner
[30:42.240 --> 30:46.320]  that I will show you in a second.
[30:46.320 --> 30:50.680]  Let's look at the site that has been generated.
[30:50.680 --> 30:55.400]  The start page doesn't have a navigation outline specified in the component descriptor,
[30:55.400 --> 31:02.760]  therefore it shows a default with all components and versions listed there.
[31:02.760 --> 31:08.240]  When I choose the content module version 1, I see a warning that I'm looking at an outdated
[31:08.240 --> 31:14.760]  version with a hint where to navigate to the latest version.
[31:14.760 --> 31:23.520]  On version 2, there's a link to a PDF containing the content of all pages in this component.
[31:23.520 --> 31:28.480]  On the page with the page attribute, I see some of the attributes that are available when
[31:28.480 --> 31:30.680]  rendering a page.
[31:30.680 --> 31:32.320]  Those attributes come in handy.
[31:32.320 --> 31:37.920]  They allow me to render information in the footer that links to the revision used to
[31:37.920 --> 31:41.960]  publish this page.
[31:41.960 --> 31:50.240]  I can also add a feedback link, which opens a GitHub issue referencing this page and
[31:50.240 --> 31:51.240]  its version.
[31:51.600 --> 31:59.400]  This is a simple mechanism to offer users providing feedback to my content.
[31:59.400 --> 32:04.000]  At the top right, there's a link to edit this page on GitHub.
[32:04.000 --> 32:11.360]  When I go to a generated page, this page doesn't have the edit button as it has been generated.
[32:11.360 --> 32:12.720]  This is the end of the demo tour.
[32:12.720 --> 32:20.520]  Give it a try yourself to find out what's possible with Antora and its extensions.
[32:20.520 --> 32:22.120]  Thanks for watching this talk.
[32:22.120 --> 32:28.120]  We hope you found some things you want to try out in your current ONIX project.
[32:28.120 --> 32:33.960]  Here are some links to Antora and its extensions and a link to the demo repository.
[32:33.960 --> 32:37.880]  On the right, you see the links to our blogs.
[32:37.880 --> 32:43.840]  When you are watching this live at Postem, we're looking forward to a vivid Q&A round.
[32:43.840 --> 32:49.340]  If you watch this at recording, visit our blogs and get in touch by email or our social
[32:49.340 --> 32:50.340]  media accounts.
[32:50.340 --> 32:56.340]  We'd love to hear where you're using or plan to use Antora in your projects.
[32:56.340 --> 33:19.340]  Hey, we're live for Breeze, we're live for, we have 10 minutes of Q&A time, isn't it?
[33:19.340 --> 33:20.340]  We are live?
[33:20.340 --> 33:21.340]  Yeah, we are live.
[33:21.340 --> 33:31.340]  So, people can listen to us in the complete world.
[33:31.340 --> 33:38.100]  We talked about this earlier, but we don't have so many questions yet.
[33:38.100 --> 33:43.100]  You said Antora changed some things for you with the simplicity of the workflow.
[33:43.100 --> 33:47.700]  I think you first started with the best script that was restored.
[33:47.700 --> 33:59.660]  So, really, 2022 was a year of big changes because the new version of Antora was published
[33:59.660 --> 34:01.460]  with the extensions.
[34:01.460 --> 34:11.420]  Then in the late 22, the first extension arrived and they changed what we can do.
[34:11.420 --> 34:16.660]  It's an enormous change in simplicity.
[34:16.660 --> 34:25.340]  I was doing the training since three years with, I don't know, 800 lines of bash, CREP.
[34:25.340 --> 34:34.260]  It was breaking very often, so lots of time to fix stuff because the content is broken.
[34:34.260 --> 34:42.380]  Now we have something that is done in a few lines of FML, just configuration file and there
[34:42.380 --> 34:50.500]  is still a little post-processing bash script, but it's less, it's 50 lines, it's small.
[34:50.500 --> 34:58.620]  So, the simplicity of the process has dramatically improved and there is another extension that
[34:58.620 --> 34:59.620]  is coming.
[34:59.620 --> 35:00.620]  It's Antora Atlas.
[35:00.620 --> 35:01.620]  We didn't talk about it.
[35:01.620 --> 35:02.620]  No, we didn't.
[35:02.620 --> 35:03.620]  Yeah.
[35:03.620 --> 35:09.580]  Antora Atlas, it's something where you can build just a subset of a documentation website.
[35:09.580 --> 35:17.700]  So, you can have a very large customer portal, so to say, or something like that, with a
[35:17.700 --> 35:22.540]  lot, big, big, big amount of documentation.
[35:22.540 --> 35:30.540]  If you want to build all of that in one go, it takes a big amount of time.
[35:30.540 --> 35:39.060]  But with that extension, you can just build a part of it and it goes much, much faster.
[35:39.420 --> 35:48.700]  So that's really something that's getting in the good direction to onboard Antora in
[35:48.700 --> 35:55.660]  large documentations or in companies that have a large population of documentation.
[35:55.660 --> 35:57.300]  So that's really good news.
[35:57.300 --> 36:02.780]  And I saw that with the Spring Security project, I think they are one of the users of the Atlas
[36:02.780 --> 36:04.340]  extension for Antora.
[36:04.340 --> 36:07.060]  So that's very interesting.
[36:07.060 --> 36:15.540]  But you said you did some post-processing with Bash from the output of the Assembler extension,
[36:15.540 --> 36:16.540]  probably.
[36:16.540 --> 36:17.540]  Mm-hmm.
[36:17.540 --> 36:22.940]  And I'm preparing this in a similar way for the Key Cloud project.
[36:22.940 --> 36:30.660]  And for that, I kind of forked part of the Assembler extension and put all the post-processing
[36:30.660 --> 36:35.580]  that I needed to move that from a Bash script that I had also moved that to the JavaScript
[36:35.620 --> 36:36.620]  code.
[36:36.620 --> 36:44.180]  And that makes it a bit more maintainable, I have more syntax support, some validation
[36:44.180 --> 36:45.180]  support.
[36:45.180 --> 36:48.300]  And yeah, so all these extensions that are there now.
[36:48.300 --> 36:59.100]  And so maybe one question in the scope of Antora Atlas that you talked about just before
[36:59.100 --> 37:08.380]  here in the Q&A, did you, well, do you know already some projects that could be starting
[37:08.380 --> 37:14.820]  to use them, to try to weigh in order to have a real case, a real-world use case?
[37:14.820 --> 37:19.020]  Or maybe organization you're talking to that?
[37:19.020 --> 37:23.820]  I would suggest to go to the lip chat of Antora and ask there.
[37:23.820 --> 37:27.260]  I don't know if it's getting developed right now.
[37:27.260 --> 37:33.620]  So it's like the author is saying every week, hey, I have a new alpha version and now this
[37:33.620 --> 37:34.620]  is working.
[37:34.620 --> 37:42.940]  And so it's just really impressive because you see the progress every week.
[37:42.940 --> 37:54.340]  And it's also, it's, oh, it makes me read some part of the ASCII doc code and everything
[37:54.340 --> 37:56.180]  our everything is done.
[37:56.180 --> 38:03.780]  So it's like really, it's really impressive how it's a continuous improvement process
[38:03.780 --> 38:09.900]  that is getting rid of that so that ASCII doctor will become better from there.
[38:09.900 --> 38:16.220]  So it's probably done for someone, but I don't know exactly who for who.
[38:16.220 --> 38:22.980]  But if you bring security, that would be the example and I can post a link to the chat
[38:22.980 --> 38:27.500]  so people can follow up on how that's going.
[38:27.500 --> 38:33.100]  In the meantime, we also have one question from Benson on the chat, which is about, is
[38:33.100 --> 38:36.140]  Antora accessible for screen readers?
[38:37.140 --> 38:41.820]  Well, I haven't tested this with screen readers on a laptop pro.
[38:41.820 --> 38:44.940]  So I need to be very cautious what I see here.
[38:44.940 --> 38:48.420]  Thing is, it's, it's plain HTML that helps.
[38:48.420 --> 38:54.660]  So it's not so much JavaScript and single page application that's probably also a help.
[38:54.660 --> 38:59.460]  And I'm not sure if they put in so many ARIA tags in there.
[38:59.460 --> 39:04.380]  I don't know that in the Senate theme, there are some, but if you want to really optimize
[39:04.500 --> 39:10.420]  it for a screen readers, you might need to put some more effort into that to see that
[39:10.420 --> 39:15.060]  the ARIA tags are right when it comes to the, to the scene, to the, I would say, outline
[39:15.060 --> 39:18.220]  navigation and all that stuff.
[39:18.220 --> 39:26.340]  Put ARIA tags in the content in the middle, I would say there's, yeah, maybe, maybe ask
[39:26.340 --> 39:27.340]  in the Zulip chat.
[39:27.340 --> 39:32.180]  I'm also on the Zulip chat there and then get pull requests into the standard Antora
[39:32.180 --> 39:33.180]  scene.
[39:33.180 --> 39:34.180]  Yeah.
[39:34.180 --> 39:40.460]  The one thing to know is that there is a default UI, so a default presentation there, but you
[39:40.460 --> 39:42.460]  can, you can change it.
[39:42.460 --> 39:53.540]  Some projects have made an entirely different UI, but I, I, I believe it's like accessible
[39:53.540 --> 40:00.060]  like most of the documentation framework that we have now, but I, I, I don't, I'm not sure
[40:00.060 --> 40:08.060]  to give a very prescriptive answer to that because I, I have not watched it.
[40:08.060 --> 40:09.060]  Okay.
[40:09.060 --> 40:10.060]  Thank you.
[40:10.060 --> 40:15.060]  I'm not sure to give a very prescriptive answer to that.
[40:15.060 --> 40:17.580]  And Fabrice, you, what kind of extension did you add?
[40:17.580 --> 40:22.420]  I think you added a link, an external link, checker extension to Antora in your project
[40:22.420 --> 40:24.420]  to do some additional validation.
[40:24.420 --> 40:25.420]  Yeah.
[40:25.420 --> 40:26.420]  I used, yeah.
[40:26.420 --> 40:27.420]  I used the, the Composer.
[40:27.420 --> 40:34.300]  So with, with the Composer extension, you can, you can call external scripts.
[40:34.300 --> 40:43.420]  And I did that to, to, I call Veil, so the Veil style guide lintar to verify that the,
[40:43.420 --> 40:47.020]  the, the content is compliant with the style guide.
[40:47.020 --> 40:51.980]  And I can calling also HTML test to verify the external links.
[40:51.980 --> 40:54.860]  So Antora is already checking all the x-refs.
[40:54.860 --> 41:00.860]  So if there is a broken x-refs, you, you will have a warning, but I added something to,
[41:00.860 --> 41:02.140]  to test.
[41:02.140 --> 41:07.220]  So that's the, the, the real nice thing is that Antora is in charge of, so before that
[41:07.220 --> 41:15.380]  we had Gulp who was launching all of these additional, additional tools.
[41:15.380 --> 41:18.460]  And yeah, it's Antora is in charge of everything.
[41:18.460 --> 41:28.060]  So it's, it's, it's, in terms of, of who owns the process, it's something much more
[41:28.060 --> 41:29.060]  clear.
[41:29.060 --> 41:35.660]  And, and also it's, it's reuse, so, you know, the, the checks that you have, you, you add
[41:35.660 --> 41:40.580]  in the, the project, there are no running the downstream project also, so that's, that's
[41:40.580 --> 41:41.580]  really, really nice.
[41:41.580 --> 41:45.540]  You have to write your pipeline at once.
[41:45.540 --> 41:46.540]  Sometimes it's so cool.
[41:46.540 --> 41:53.900]  So the difficult thing is to understand what belongs to the, the modules, so the Antorayana
[41:53.900 --> 42:00.300]  or what belongs to the playbook, Antora playbook, the channel and what happens in which, in
[42:00.300 --> 42:07.820]  which, in which area it's sometimes it's, it's, it can be confusing at the beginning,
[42:07.820 --> 42:08.820]  but, but.
[42:08.820 --> 42:09.820]  Yeah.
[42:09.820 --> 42:14.940]  It's like the playbook is the global configuration that is the whole site.
[42:14.940 --> 42:18.700]  And then for each component, you can have a separate configuration in the component
[42:18.700 --> 42:21.260]  or in the Antorayama file.
[42:21.260 --> 42:25.940]  And this can be then specific to a version of that component or always is specific to
[42:25.940 --> 42:26.940]  a version.
[42:26.940 --> 42:32.300]  Like if you have a version 19, then you have an Antorayama file for that version 19 living
[42:32.300 --> 42:41.100]  in the 19 branch of your software 20 version 20 component, the scripture Antorayama living
[42:41.100 --> 42:44.340]  in the 20 branch of your software.
[42:44.340 --> 42:46.300]  And they can have different validation rules.
[42:46.300 --> 42:48.140]  They can run different scripts.
[42:48.140 --> 42:53.900]  They can run whatever is necessary for that version to create the content that you want
[42:53.900 --> 42:56.420]  to show on the website.
[42:56.420 --> 42:59.500]  So it's really a divide and conquer here.
[42:59.500 --> 43:05.540]  One thing is the global stuff and the other thing is the version specific stuff.
[43:05.540 --> 43:06.540]  Okay.
[43:06.540 --> 43:14.660]  So the, the session will end in about one minute, then we'll go to the next session,
[43:14.660 --> 43:20.500]  which is about tribe, I think content structuring and collaborative framework.
[43:20.500 --> 43:24.980]  So if you want to ask further questions, we will have a room which will pop up in the
[43:24.980 --> 43:31.100]  chat of the, of the room right away and you will be able to access it and, and talk to
[43:31.100 --> 43:39.860]  well, talk to the speakers or talk to Fabrice and to Alexander and that are, that are there.
[43:39.860 --> 43:42.220]  So thank you for the both of you.
[43:42.220 --> 43:50.460]  And I hope that it will see each other so you're welcome to do them, right?
[43:50.460 --> 43:52.940]  So maybe, maybe next year.
[43:52.940 --> 43:53.940]  Thank you.
[43:53.940 --> 43:54.940]  See you there.
[43:54.940 --> 43:55.940]  Bye-bye.
[43:55.940 --> 43:56.940]  Bye-bye.
[43:56.940 --> 43:57.940]  Welcome everybody.
[43:57.940 --> 44:22.940]  Now there are people who will, who will maybe come here in the, in the screen or maybe not.
[44:22.940 --> 44:43.940]  Okay, now the room is public and now other people could join in and see if that happens
[44:43.940 --> 44:44.940]  or not happens.
[44:44.940 --> 44:51.500]  I think there were like six or seven, well, maybe two people really watching this talk
[44:51.500 --> 44:52.500]  at the moment.
[44:52.500 --> 44:53.500]  Let's see how it works.
[44:53.500 --> 44:54.500]  I made them.
[44:54.500 --> 44:57.500]  They will go to the next talk probably in some way.
[44:57.500 --> 44:58.500]  Yeah.
[44:58.500 --> 44:59.500]  Let's wait.
[44:59.500 --> 45:00.500]  So let's wait what, five minutes?
[45:00.500 --> 45:01.500]  Yeah, I think so.
[45:01.500 --> 45:02.500]  Just wait five minutes and then we, the final statement in the chat saying, welcome.
[45:02.500 --> 45:03.500]  Oh, sorry, goodbye everyone.
[45:03.500 --> 45:04.500]  That's it.
[45:04.500 --> 45:14.500]  I don't know if you follow or master them.
[45:14.500 --> 45:15.500]  Hmm?
[45:15.500 --> 45:24.500]  One of you follow or master them?
[45:24.500 --> 45:25.500]  Yeah, master them.
[45:25.500 --> 45:26.500]  Where do you follow?
[45:26.500 --> 45:27.500]  You're master them.
[45:27.500 --> 45:28.500]  Hmm?
[45:28.500 --> 45:29.500]  Tell them.
[45:29.500 --> 45:30.500]  No.
[45:30.500 --> 45:31.500]  No.
[45:31.500 --> 45:32.500]  No, no.
[45:32.500 --> 45:33.500]  No, no.
[45:33.500 --> 45:34.500]  They are not actually you, um, with master them.
[45:34.500 --> 45:35.500]  Hmm?
[45:35.500 --> 45:36.500]  Well, they are not.
[45:36.500 --> 45:37.500]  OK.
[45:37.500 --> 45:38.500]  They are not actually you.
[45:38.500 --> 45:39.500]  No.
[45:39.500 --> 45:40.500]  No.
[45:40.500 --> 45:41.500]  No.
[45:41.500 --> 45:42.500]  No.
[45:42.500 --> 45:43.500]  No.
[45:43.500 --> 45:44.500]  No.
[45:44.500 --> 45:45.500]  No.
[45:45.500 --> 45:46.500]  No.
[45:46.500 --> 45:47.500]  No.
[45:47.500 --> 45:48.500]  No.
[45:48.500 --> 45:49.500]  No.
[45:49.500 --> 45:50.500]  No.
[45:50.500 --> 45:51.500]  No.
[45:51.500 --> 45:52.500]  No.
[45:52.500 --> 45:53.500]  No.
[45:53.500 --> 45:54.500]  No.
[45:54.500 --> 45:55.500]  No.
[45:55.500 --> 45:56.500]  No.
[45:56.500 --> 45:57.500]  No.
[45:57.500 --> 45:58.500]  No.
[45:58.500 --> 45:59.500]  No.
[45:59.500 --> 46:00.260]  No.
[46:00.260 --> 46:01.000]  No.
[46:01.000 --> 46:02.000]  No.
[46:02.000 --> 46:03.000]  No.
[46:03.000 --> 46:04.000]  No.
[46:04.000 --> 46:05.000]  No.
[46:05.000 --> 46:06.000]  No.
[46:06.000 --> 46:07.000]  No.
[46:07.000 --> 46:08.000]  No.
[46:08.000 --> 46:09.000]  No.
[46:09.000 --> 46:09.880]  No, no.
[46:09.880 --> 46:10.880]  No.
[46:10.880 --> 46:11.880]  No.
[46:11.880 --> 46:12.900]  No.
[46:12.900 --> 46:13.900]  No.
[46:13.900 --> 46:14.900]  No.
[46:14.900 --> 46:15.900]  No.
[46:15.900 --> 46:17.000]  No.
[46:17.000 --> 46:18.000]  No.
[46:18.000 --> 46:19.000]  No.
[46:19.000 --> 46:20.000]  No.
[46:20.000 --> 46:20.800]  No.
[46:20.800 --> 46:21.500]  No.
[46:21.500 --> 46:22.500]  No.
[46:22.500 --> 46:23.500]  No.
[46:23.500 --> 46:24.500]  No.
[46:25.000 --> 46:28.000]  No.
[46:34.000 --> 46:35.000]  No.
[46:35.000 --> 46:36.000]  No.
[46:36.000 --> 46:37.000]  No.
[46:37.000 --> 46:38.000]  No.
[46:38.000 --> 46:39.000]  No.
[46:39.000 --> 46:40.000]  No.
[46:40.000 --> 46:41.000]  No.
[46:41.000 --> 46:42.000]  No.
[46:42.000 --> 46:43.000]  No.
[46:43.000 --> 46:44.000]  No.
[46:44.000 --> 46:45.000]  No.
[46:45.000 --> 46:46.000]  No.
[46:46.000 --> 46:47.000]  No.
[46:47.000 --> 46:48.000]  No.
[46:48.000 --> 46:49.000]  No.
[46:49.000 --> 46:50.000]  No.
[46:50.000 --> 46:51.000]  No.
[46:51.000 --> 46:52.000]  No.
[46:52.000 --> 46:53.000]  No.
[46:53.000 --> 46:54.700]  No.
[46:54.700 --> 46:58.500]  Did you write something with the, with the, with the hash tag enter.
[46:58.500 --> 46:59.500]  No.
[46:59.500 --> 47:00.500]  Ask The Dog.
[47:00.500 --> 47:04.500]  Awww, maybe.
[47:04.500 --> 47:07.500]  Are you on, are you?
[47:07.500 --> 47:09.500]  marry.
[47:09.500 --> 47:13.500]  No, it's just, it's.
[47:13.500 --> 47:15.000]  Okay, I don't know.
[47:15.000 --> 47:28.000]  Did you write something about first them?
[47:28.000 --> 47:31.000]  Yeah, but do you have to go first to them?
[47:31.000 --> 47:35.000]  Yeah, but it's just, how to find users is just painful.
[47:35.000 --> 47:41.000]  And I didn't just, my instance is, is offline or I don't know.
[47:41.000 --> 47:44.000]  What are you, what instance are you?
[47:44.000 --> 47:48.000]  I am, so you can find me maybe.
[47:48.000 --> 47:51.000]  That's a small instance.
[47:51.000 --> 47:53.000]  I believe nobody's coming now.
[47:53.000 --> 48:01.000]  Yeah, thank you.
[48:01.000 --> 48:08.000]  That was F, F0.
[48:08.000 --> 48:21.000]  Let me, let me.
[48:21.000 --> 48:22.000]  I appreciate your documentation.
[48:22.000 --> 48:31.000]  So this is the real pipeline.
[48:31.000 --> 48:47.000]  I don't know what happens when you, when you, when you move this out from a server.
[48:47.000 --> 49:15.000]  Okay.
[49:15.000 --> 49:44.000]  So nobody here.
[49:44.000 --> 50:09.000]  Okay.
[50:09.000 --> 50:38.000]  Okay.
[50:38.000 --> 51:07.000]  Okay.
[51:07.000 --> 51:33.000]  Okay.
[51:33.000 --> 51:50.000]  Okay.
[52:03.000 --> 52:29.000]  Okay.