Презентация как код, или Почему я больше не пользуюсь Powerpoint-ом


    Кажется, мне довелось сделать десятки презентаций для коллег, заказчиков и публичных выступлений за мою карьеру в IT. Многие годы Powerpoint как средство изготовления слайдов оставался для меня естественным и надёжным выбором. Но в этом году ситуация качественно изменилась. С февраля по май мне довелось выступить на пяти конференциях, и слайды к докладам надо было готовить в сжатые сроки, но качественно. Встал вопрос о делегировании той части работы, что касается визуального дизайна слайдов, другим людям. Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах. И я решил попробовать что-то новое. Попробовал, и с тех пор не думаю возвращаться к Powerpoint.


    Что мы хотим


    Года полтора назад мы в компании отказались от использования Word для создания проектной документации, столкнувшись с теми же проблемами: хотя Word хорош для того, чтобы набрать небольшой документ, по мере роста объёмов, возникают трудности с совместной работой и получением качественного и унифицированного оформления. Наш выбор пал на AsciiDoctor, и выбору этому мы не перестаём радоваться, но это тема для отдельной статьи. Примерно тогда же мы познали эффективность одного из DevOps-принципов "everything as code", поэтому выбор требований для новой технологии создания презентационных слайдов был довольно очевидным:


    1. Презентация должна представлять собой plain text-файл на языке разметки.
    2. Слайды у нас про проекты разработки, поэтому разметка должна позволять легко, не прибегая к помощи внешних систем, вставлять
      • фрагменты кода с подсветкой синтаксиса,
      • простые диаграммы в виде геометрических фигур, соединённых стрелками,
      • UML-диаграммы, блок-схемы и прочее.
    3. Проект презентации должен храниться в системе контроля версий.
    4. Валидация и сборка готовых слайдов должна производиться в CI-системе.

    На сегодня возможны два базовых варианта создания слайдов на языках разметки: пакет beamer для LaTeX или один из фреймворков для создания слайдов на HTML/CSS (RevealJS, remark, deck.js и многие другие).


    Хотя моя душа лежит к LaTeX-у, разум подсказывал, что выбор решения, которым буду пользоваться не я один, должен быть на стороне решения, знакомого более широкому кругу лиц. LaTeX знают не все, и если ваша каждодневная практика не связана с написанием научных статей, то вряд ли у вас найдётся время на погружение в огромный замысловатый мир этой системы.


    Впрочем, и владение HTML/CSS — не сказать чтобы повсеместно распространённый навык: я, например, им владею далеко не в полной мере. К счастью, тут на помощь приходит уже знакомый нам AsciiDoctor: конвертер asciidoctor-revealjs позволяет создавать RevealJS-слайды, используя AsciiDoctor-разметку. А уж она-то проста для изучения и доступна каждому!


    Как закодировать слайды


    Чтобы понять суть кодирования слайдов на AsciiDoctor, проще всего привести конкретные примеры. Все они — из реальных слайдов, которые я делал для своих конференционных докладов в этом году.


    Слайд с заголовком и списком в открывающихся один за другим пунктах:


    == Зачем нам Streams API?
    
    [%step]
    * Real-time stream processing
    * Stream-like API (map / reduce)
    * Под капотом:
    ** Автоматический offset commit
    ** Ребалансировка
    ** Внутреннее состояние обработчиков
    ** Легкое масштабирование

    Результат


    Заголовок и фрагмент исходного кода с подсветкой синтаксиса:


    == Kafka Streams API: общая структура KStreams-приложения
    
    [source,java]
    ----
    StreamsConfig config = ...;
    //Здесь устанавливаем всякие опции
    
    Topology topology = new StreamsBuilder()
    //Здесь строим топологию
    ....build();
    ----

    Результат


    В процессе подготовки к докладу демонстрационные примеры кода подвергаются неоднократным переделкам и улучшениям, поэтому бесценна возможность быстро скопировать и вставить «сырой код» прямо в слайд, обеспечивая актуальность демо-примера и не заботясь о подсветке синтаксиса.


    Заголовок, иллюстрация и текст (раскладку по слайду выполняем в ячейках таблицы AsciiDoctor):


    == Kafka Streams in Action
    
    [.custom-style]
    [cols="30a,70a"]
    |===
    |image::KSIA.jpg[]
    |
    * **William Bejeck**, +
    “Kafka Streams in Action”, November 2018
    * Примеры кода для Kafka 1.0
    |===

    Результат


    Иногда заголовок не нужен, а для иллюстрации твоей мысли нужна просто картинка во весь экран:


    [%notitle]
    == Жить в легаси нелегко
    
    image::swampman.jpg[canvas, size=cover]

    Результат


    Часто мысль необходимо подкрепить простой диаграммой, в виде «квадратиков, соединённых стрелочками». К счастью, AsciiDoctor интегрирован с системой Graphviz — языком, позволяющим описывать графовые диаграммы на основании описания вершин и связей между ними. Graphviz нужно осваивать, но на основе имеющихся примеров сделать это довольно легко! Вот как это выглядит:


    == Пишем “Bet Totalling App”
    
    Какова сумма выплат по сделанным ставкам, если сыграет исход?
    
    [graphviz, "counting-topology.png"]
    -----
    digraph G {
    graph [ dpi = 150 ];
    rankdir="LR";
    node [fontsize=18; shape="circle"; fixedsize="true"; width="1.1"];
    Store [shape="cylinder"; label="Local Store"; fixedsize="true"; width="1.5"]
    Source -> MapVal -> Sum -> Sink
    Sum -> Store [dir=both; label=" \n "]
    {rank = same; Store; Sum;}
    }
    -----

    Результат


    В случае, когда необходимо отредактировать подпись на фигуре, изменить направление стрелки и т. п. — это можно сделать непосредственно в коде презентации, вместо того, чтобы перерисовывать где-то картинку и заново вставлять её в слайд. Это значительно увеличивает скорость работы над слайдами.


    Пример посложнее:


    == Невоспроизводимая сборка
    [graphviz, "unstable-update.png"]
    -----
    digraph G {
      rankdir="LR";
      graph [ dpi = 150 ];
      u -> r0;
      u[shape=plaintext; label="linter update\n+ 13 warnings"]
      r0[shape=point, width = 0]
      r1 -> r0[ arrowhead = none, label="master branch" ];
      r0-> r2 [];   b1 -> b4;  r1->b1
      r1[label="150\nwarnings"]
      b1[label="± 0\nwarnings"]
      b4[label="± 0\nwarnings"]
      b4->r2
      r2[label="163\nwarnings", color="red", xlabel=<<font color="red">merge blocked</font>>]
      {rank = same; u; r0; b4;}
    }
    -----

    Результат


    Кстати, экспериментировать с Graphviz и отлаживать картинки удобно на странице Graphviz online.


    Наконец, если нужно вставить в слайд блок-схему, диаграмму классов или иную стандартизованную диаграмму, то в этом случае на помощь может прийти ещё одна интегрированная с AsciiDoctor система, PlantUML. Про обширные возможности PlantUML мой коллега Николай Поташников написал отдельный пост.


    Превращение проекта презентации в код, хранящийся на системе контроля версий, даёт возможность организовать совместную работу над презентацией, прежде всего разделить задачи создания контента и оформления. Оформление слайдов (шрифты, фоны, отступы) в RevealJS описывается с помощью CSS. Моё личное умение управляться с CSS лучше всего передаёт эта гифка — но это не страшно, когда есть люди, работающие с CSS гораздо ловчее и быстрее меня. В итоге получается, что в условиях стремительно приближающегося дедлайна по презентации мы можем работать одновременно над разными файлами через Git и развивать скорость совместной работы, невозможную при пересылке по почте файлов .pptx.


    Сборка HTML-страницы со слайдами


    Plain text-исходники — это здорово, но как их скомпилировать в саму презентацию?


    AsciiDoctor — это проект, написанный на Ruby, и запустить его можно несколькими способами. Во-первых, вы можете установить язык Ruby и запускать asciidoctor напрямую, что, наверное, будет наиболее близко Ruby-разработчикам.


    Если не хочется связываться с установкой Ruby, можно воспользоваться docker-образом asciidoctor/docker-asciidoctor, в который при запуске можно через VOLUME подключить папку с исходниками проекта и в заданном месте получить результат.


    Вариант, на котором остановился я, может показаться несколько неожиданным, но он наиболее удобен мне как Java-разработчику. Он не требует ни установки Ruby, ни наличия docker, зато позволяет генерировать слайды с помощью Maven-скрипта.


    Дело в том, что проект JRuby — Java-реализация языка Ruby — настолько хорош, что позволяет запускать в Java-машине практически всё, что создано для Ruby, и запуск AsciiDoctor — одно из наиболее частых применений JRuby.


    Наличие asciidoctor-maven-plugin позволяет собирать AsciiDoctor-документацию, являющуюся частью Java-проекта (чем мы активно пользуемся). При этом AsciiDoctor и JRuby скачиваются Maven-ом автоматически, и AsciiDoctor выполняется в среде JRuby: ничего устанавливать на машину не надо! (За исключением пакета graphviz, который нужен, если вы хотите использовать графику GraphViz или PlantUML.) Достаточно поместить ваши .adoc-файлы в папку src/main/asciidoc/. Вот пример помника, собирающего слайды с диаграммами.


    Конвертация слайдов в PDF


    Хотя HTML-версия слайдов вполне самодостаточна, всё же иметь PDF-вариант слайдов тоже бывает необходимо. Во-первых, случается, что на некоторых конференциях, не предоставляющих спикеру возможность подключения собственного ноутбука, требуют слайды «строго в формате pptx или pdf», не ожидая, что они бывают ещё и в HTML. Во-вторых, хорошим тоном является отправить организаторам неизменяемый вариант ваших слайдов в том виде, как они были показаны на докладе, в формате PDF для публикации файла в материалах конференции.


    К счастью, с этой задачей справляется Node.js утилита decktape, построенная на базе Puppeteer — системы автоматизации управления браузером Chrome. Сконвертировать RevealJS презентацию в PDF можно командой


    node decktape.js -s 3200x1800 --slides 1-500 \
      reveal "file:///index.html?fragments=true" slides.pdf  

    Две хитрости при запуске decktape, к которым пришлось прийти методом проб и ошибок:


    • разрешение через параметр -s надо задавать с двухкратным запасом, иначе возможны проблемы с результатами конвертации


    • в URL HTML-версии презентации надо передавать параметр ?fragments=true, что позволит создавать отдельную PDF- страницу для каждого промежуточного состояния вашего слайда (например, пять страниц для пяти пунктов списка, если они показываются один за другим). Это позволит использовать такой PDF сам по себе в качестве презентации при докладе.



    Автоматическая сборка и публикация в вебе


    Удобно, когда слайды собираются автоматически при попадании изменений в систему контроля версий, и ещё удобнее, когда автоматически скомпилированные слайды выкладываются в интернет для всеобщего использования. Слайды из интернета можно легко «проиграть» перед аудиторией с любой машины, подсоединённой к интернету и проектору.


    Т. к. мы используем в работе GitHub, то естественным выбором CI-системы является TravisCI, а для хостинга готовых презентаций — github.io. Идея github.io заключается в том, что любой статический контент, помещённый в ветку gh-pages вашего проекта на GitHub, становится доступен по адресу <ваше имя>.gihub.io/<ваш проект>.


    Полный конфигурационный файл TravisCI, включающий в себя компиляцию HTML-версии страницы с помощью Maven, конвертацию в PDF при помощи decktape и выгрузку результатов в ветку gh-pages для публикации на github.io, выглядит так.


    Для сборки такого проекта на стороне TravisCI необходимо настроить переменные среды


    • GH_REF — значение вида github.com/inponomarev/csa-hb
    • GH_TOKEN — токен доступа к GitHub. Можно получить в GitHub-е в настройках своего профиля, Developer Settings -> Personal Access Tokens. Если вы выкладываете презентацию в публичный репозиторий, то для этого токена достаточно указать единственный уровень доступа "Access public repositories".
    • GH_USER_EMAIL / GH_USER_NAME — пара имя/почта, от имени которой будет осуществлён пуш в ветку gh-pages.

    Таким образом, каждый коммит кода презентации на GitHub приводит к автоматическому перестроению слайдов в форматах HTML и PDF и перезаливке их на github.io. (Конечно же, выкладывать на github.io нужно лишь те презентации, которые вы хотите в итоге сделать публичными.)


    Примеры проектов


    Напоследок — ссылки на пару примеров проектов презентаций с настроенными Maven-скриптами и CI-конфигурацией для Travis-CI, которые можно клонировать и использовать при создании собственных проектов презентаций:



    Прощай, Powerpoint! Не думаю, что ты мне когда-нибудь понадобишься для технических презентаций :-)

    Поделиться публикацией

    Комментарии 113

      +1
      Помню, лет 25 назад в нашу жизнь ворвался подход WYSIWYG. Забавно наблюдать обратный процесс :)
      А что мешало .pptx хранить в GitHub? Ну и прям сплю и вижу, насколько удобнее в голове прикидывать координаты узлов графа, нежели ткнуть мышкой в редакторе. :)
        +10
        >> А что мешало .pptx хранить в GitHub?

        Ничего не мешает, вот только мержить не очень удобно… Точнее почти невозможно.
          –6
          а зачем мерджить? это просто файлы презентаций разных версий. Вы же байтовые ресурсы не мержите?
            +22
            Не мёржим, потому что не можем. Как следствие, два человека не могут одновременно вносить правки в два байтовых ресурса. А в два текстовых — могут.
              +7
              В Powerpoint есть встроенная функция для совместной работы над документом, пример из статьи больше похож на неудобный велосипед
              image
                0
                Ну, тут всё зависит от задачи: где велосипед удобнее, где — Камаз. Я давно не пользовался Офисом365: скажите, параллельная работа (как в Google Docs) над слайдами возможна, или всё ещё надо делать Check Out / Check In?
                  +3
                  Да, возможна, есть даже общий чат тут можно подробнее почитать
                    0
                    Поправьте меня, если не прав, но в Office365 групповая работа организована чуть по-другому. Слияние изменений происходит при сохранении, а не как в Google Docs в режиме on-line. Хотя, возможно Microsoft уже добился одновременной работы в режиме on-line.
                      +1

                      Добился. Сохраняет сам, как из веба, так и из десктопного приложения

                  0
                  del
                    –5
                    1) Чужое облако нарушает приватность.
                    2) Архива версий/изменений, как я понимаю, нет.
                      +2
                      1) Office365 может быть развернут локально
                      2) Архив версий / изменений поддерживается автоматически средствами Office 365
                      +7

                      На самом деле, как правило, работа с текстовыми форматами всегда удобнее. Мы это можем, например, наблюдать по тому, как WYSIWYG редакторы, голый html (и всякие bbcode) эволюционно почти везде оказались вытеснены markdown. Причем это произошло само собой. Просто потому так на самом деле удобнее всем.


                      Можно еще много примеров найти. Еще один пример из несколько другой области. Что-то похожее происходило в конце 90-х, начале 2000-х, когда многие компании представили CASE среды разработки, где программы предлагалось создавать из блоков в визуальных редакторов. Все это представлялось с большой помпой: «Сейчас каждый ребенок сможет из блоков мышкой составить программу любой сложности». И где все эти среды сейчас?..


                      Еще пример: в те же годы шли баталии между сторонниками GUI и CLI. Типа того, что мышкой можно все делать быстрее и без предварительного обучения, и это намного удобнее, чем всякие там CLI и текстовые файлы конфигурации. Тем не менее, все эволюционно пришли к некоторому балансу, и даже Microsoft начал выкатывать PowerShell, терминалы, WSL.


                      Текст легко обрабатывать, хранить, передавать, демонстрировать, сравнивать, индексировать, и так далее, нежели пропиетарные бинарные форматы.

                        +2

                        Так может будущее — одновременная работа как с текстом, так и с WYSIWYG? Каждый выбирает что ему удобней, а противоположное представление формируется автоматически.

                          0

                          Преобразование не всегда однозначно или вообще выполнимо (если говорить не только о презентациях). Например, язык текстового инструмента может быть turing complete (содержать условия, циклы, и т.п.), тогда для него очень сложно или даже невозможно создать GUI. Или такой GUI становится настолько сложным и неочевидным, что проще все равно писать текстом.

                            +1

                            Ну так далеко и не всегда нужны turing complete возможности. К тому же для таких элементов язык может быть односторонним, т.е. поддерживать редактирование только со стороны исходников.

                          –1
                          Ну скажем и нам и нашим пользователям удобнее использовать GUI-редактор конфигурации, чем текстовый конфиг (могу и то и то). Мне самому — удобнее править форму в программе GUI, чем в текстовом виде.

                          Секрет прост — текстовый вид не включает варианты правильных настроек и контроль неправильных.

                          Прежде чем рассуждать о недостатках WISIWIG-редакторов, попробуйте поредактрировать файл без WISYWIG. Я про EDLIN, TECO и им подобные. На протяжении десятка лет работы с аналогами EDLIN я все время видел одну и ту же картину — пользователи стрелой убегают из хорошего навороченного строчного редактора в простейший WYSIWIG (TED).

                          Текст легко обрабатывать, хранить, передавать, демонстрировать, сравнивать, индексировать, и так далее, нежели пропиетарные бинарные форматы.
                          Работа с текстом без WISYWIG нужна лишь отдельным программистам. Не верите — ну напишите статью при помощи echo, а редактируйте её SED.

                          Даже свой пост против WISIWIG вы все-таки писали в WISIWIG-редакторе.

                          Зато без WISIWIG — работают 5-6 пользователей на 62 килобайта памяти (на M6000). Возможности работы со считанными килобайтами у строчных редакторов не отнять.
                            0

                            Вопрос тут прагматичнее. Научился делать что-то в plaintext’е — сможешь грузить это на рынок килограммами. Приведу по памяти цитату Генри Форда: «Чтобы достичь успеха, необходимо научиться делать что-то полезное в больших количествах и по низкой цене».

                              –2

                              Вы хоть раз в жизни пробовали редактировать plain-текст без WISIWIG?


                              Даже у асов строчного редактора скорость в WISIWIG в 2-3 раза больше. У не асов — в 10 раз больше, у новичков… Возьмите редактор VI и попробуйте набивать и редактировать текст без режима вставки.


                              Ни о каких " килограммах" без WISIWIG речь не идёт, в среднем — 10 строк текста в день.


                              И ещё раз, WISIWIG полезнее всего именно для plain- текста. Потому что люди превращают любой plain в двумерный объект сложной структуры. Вспомните про отступы.

                              +4

                              «WYSIWYG» это давно устоявшийся термин, не стоит пытаться наделить его самопальными смыслами.


                              WYSIWYG (произносится [ˈwɪziwɪɡ], является аббревиатурой от англ. What You See Is What You Get, «что видишь, то и получишь») — свойство прикладных программ или веб-интерфейсов, в которых содержание отображается в процессе редактирования и выглядит максимально близко похожим на конечную продукцию, которая может быть печатным документом, веб-страницей или презентацией. В настоящее время для подобных программ также широко используется понятие «визуальный редактор».

                              (Цитата из https://ru.wikipedia.org/wiki/WYSIWYG)


                              Когда вы выделяете в MS Word фрагмент текста, жмёте кнопку полужирного текста и выделенный фрагмент начинает отображаться на экране полужирным шрифтом — это WYSIWYG.


                              Когда вы выделяете фрагмент текста в поле ввода комментария на Хабрахабре и оный фрагмент обрамляется тегами <b>...</b> — это НЕ WYSIWYG.


                              Даже свой пост против WISIWIG вы все-таки писали в WISIWIG-редакторе.

                              Вы не автору статьи отвечали, так что никаких «постов против WISIWIG» он не писал.
                              Поле ввода комментария тут WYSIWYG не является.

                                –5

                                Боюсь, что в те годы, когда появился этот термин, вас ещё на свете не было. Поэтому и не понимаете, что ввод комментария на хабре — это именно визуальное редактирование, WISIWYG. Иного визуального редактирования на текстовых терминалах 70х годов просто не было.


                                Так что вы мне напоминание того героя Мольера, который с удивлением узнал, что говорит прозой.


                                Чтобы удалить 2 символа в невизуаальном режиме, надо дать команду 2D, примерно как в командном режиме vi. Это очень удобно для программирования, но крайне неудобно для редактирования человеком.


                                Примерно с конца 50х годов плоские файлы стали не совсем плоскими — появились отступы и разбивка на абзацы. Настоящий плоский текст сейчас используется только в языках типа breinfuck. Ну или в редких случаях использования перфоленты.


                                Просто я настолько стар, что застал и перфоленты и строчные редакторы и совсем плоские тексты программ.

                                  +6
                                  Иного визуального редактирования на текстовых терминалах 70х годов просто не было.

                                  Хорошая история, дедушка.
                                  Первый WYSIWYG (вы конечно очень старый, но давайте все-таки термины правильно писать) «официально» появился в 1974 году в XEROX Parc. Вообще первые WYSIWYG редакторы появились в основном с целью получения на принтере такого же изображения как на экране редактора.

                                  Цитата из Википедии:
                                  Before the adoption of WYSIWYG techniques… Users were required to enter special non-printing control codes (now referred to as markup code tags) to indicate that some text should be in boldface, italics, or a different typeface or size.

                                  Т.е. до изобретения WYSIWYG — юзерам приходилось использовать специальные теги разметки (как раз то что вы описываете)

                                  Поэтому html — это не WYSIWYG, и редактор комментариев на хабре тоже не WYSIWYG.
                                    –5

                                    Господи, какая каша у вас в голове. Теги HTML — это разметка. Она может вставляться как визуальным редактором ( где коды не видны), так и невизуальным.


                                    Но я о другом, о кодах перевода строки. Вы эту разметку видите? Всякие CR и LF? Не видите.


                                    И самое главное — вы перемещаете курсор по тексту и мгновенно видите результат редактирования текста. А не даёте вначале команды движения курсора, потом команды редактирования, потом — отображения результате.


                                    Вы просто привыкли, что любой редактор плоского текста визуальный. Видимо see, teco, edlin и командный режим vi ошеломят вас.


                                    Я не спорю, что с годами люди настолько отвыкли от командных и строчных редакторов, что даже в вики написали неверно.


                                    В эпоху барабанных принтеров и символьных дисплеев WISIWYG был именно таким. Никакого курсива, никаких шрифтов, даже никаких маленьких букв. Максимум — отдельные принтеры позволяли хак с жирным шрифтом.


                                    И вот тогда и появились визуальные редакторы и маркетинговый термин WISIWYG.


                                    А уж потом этот маркетиновый термин перезапустили еще раз, для графических терминалов и матричных принтеров.


                                    Вы разметку разделения на строки видите? У вас текст плоский, то есть одномерная лента символов? Вы делаете навигацию по тексту командами? Вы редактируете командами?


                                    Пять "нет" — это чистый wisiwyg. Просто для обычных текстов, а не rich.


                                    А чтобы понять, насколько это удобно — набейте свой ответ в редакторе SED.

                                      +1

                                      Перевод строки я вие переводом строки не потому что это WYSIWYG, а потому что это то, как поле ввода отображает ascii-символ #10. И конечно же я могу сделать так, чтобы он отображался взуально тоже.
                                      А ещё я могу заставить редактор текста издавать пищение бипером, используя символ ascci #7 (Если ещё не выкосили это из последних редакторов текста). Конечно же командный режим vi ровно так же отображает перенос строки.
                                      И вы упорно продолжаете неправильно писать термин WYSIWYG — на английском языке там просто не может быть I второй буквой.

                                        –2
                                        WISIWYG — What I See (on screen) Is What You get (on paper). То есть я могу сделать документ и передать его вам для печати. И вы при печати получите ровно то, что у меня на экране. По крайней мере так оно понималось лет 30-40 назад, в эпоху до персоналок.

                                        В этом смысле барабанные принтеры и полноэкранные редакторы обеспечивали лучший WISIWYG, чем нынешний ворд. С вордом надо очень постараться, чтобы на любом принтере оно печаталось одинаково. Ну хотя бы из-за разных дефолтных размеров полей.

                                        Перевод строки я вие переводом строки не потому что это WYSIWYG, а потому что это то, как поле ввода отображает ascii-символ #10.
                                        Гм, вы редакторы текста писали? Ну ОК, напиши редактор текста для принтера с клавиатурой электрической печатающей машинки, то есть для CONSUL 260. А первые дисплеи были ненамного умнее CONSUL.

                                        Как вы думаете, как отрабатывается простейший backspace? В режиме замены — сдвиг курсора влево, вывод пробела, опять сдвиг влево. Если backspace умеет отрабатывать в нулевой позиции строки, то все хитрее — может потребоваться даже сдвиг экрана, если мы делаем backspace из нулевой колонки нулевой строки. Ещё сложнее — в режиме вставки.

                                        Так что WISIWYG режим требует от терминала хотя бы 8-битного процессора, терминалы на дискретной логике поддержать его не могут.

                                        Собственно попробуйте в консольном режиме написать WISIWYG редактор — сразу увидите, как много операций вам надо.

                                        А нынешние «поля ввода» практически все нужное умеют сами, это не секрет.
                                          0
                                          WISIWYG — What I See (on screen) Is What You get (on paper).

                                          Термин не гуглится, так что я считаю что вы его придумали и дискуссию не продолжаю.

                                            +1
                                            Товарищ в силу своей упоротости просто не может признать, что понимал значение термина неправильно. У него же сначала был WISIWIG, потом WISIWYG, теперь он под последний уже базу придумал.
                                              0
                                              Термин тот же, просто если память не изменяет, то в каких-то книжках 70-80 годов расшифровывался именно так. Потому что цикл «отредактировал, сходил на печать, взял распечатку, глянул глазками, пометил правки ручкой, дождался машинного времени, внес правки, отправил на печать» — мягко говоря, всех достал. Идеал был «отредактировал — а заказчик печатает сразу набело».

                                              С приходом персоналок отличие между тем, кто редактирует документ и тем, кто забирает его с распечатки, разумеется, стерлось. Молодежь не понимает, что ЭВМ могла занимать целый этаж, а час машинного времени стоит половину зарплаты программиста.

                                              У меня вполне нагуглился: раз, два, три, четыре… ЧЯДНТ? Но вообще материалы доинтернетной эпохи гуглятся очень плохо.

                                              А по вашей логике получается, что стандарта С++17 не существует? Ибо полный текст стандарта (а не final draft) не гуглится. Как и куча других платных стандартов.

                                              Даже некоторые вещи из современных ГОСТ не гуглятся. Вот в этом ГОСТ упомянут PRDCU. Он тоже не гуглится.

                                              P.S. insolite, товарищ, при написании с мобильника в поезде, очень плохо по клавиатуре попадает. Так что там и VIVIVIC мог быть. Но как раз изначальный смысл термина — не распечатывать много раз, а видеть на экране то, что будет напечатано. И для плоского текста — это эквивалентно экранному редактированию. В отличие от строчного.

                                              А что товарища могила ждет не дождется — это факт.
                                          +1
                                          Пять «нет» — это чистый wisiwyg. Просто для обычных текстов, а не rich.

                                          WYSIWYG имеет отношение к форматированным документам, в большинстве редакторов мы набираем plain text. По-вашему получается что даже блокнот на винде — WYSIWYG.
                                          Ну и перевод строки, это стого говоря, не форматирование.
                                            0
                                            Вы что, д_у_м_а_е_т_е, в эпоху м*о*н*о*ш*и*р*и*н*н*ы*х шрифтов и б*а*р*а*б*а*н*н*ы*х принтеров форматирования НЕ БЫЛО? А фразу «не повышай на меня шрифт» никогда не слышали?

                                            Верстка и форматирование в эту эпоху были, как и программы для них.

                                            Выключкупо формату изначально делали вручную, пробелами. Потом появились программы верстки, делающие выключку в плоских текстах, потом стало возможным эту выключку делать в WISIWYG редакторах вручную. Более того, некоторые из них (может ЛЕКСИКОН?) умели делать выключку сами. Несмотря на плоские тексты.

                                            Аналогично с форматированием программного кода в алгоподобных языках — форматеры появились где-то в 60ые. Да, отступы делались пробелами и табуляциями, но они делались.

                                            Строго говоря, нынешний WISIWYG тоже неполноценен, ибо по цветам на принтере получаем совсем не то, что на экране. Так что вангую, что после широкого распространения дешевых цветных принтеров и вхождения в документы цвета понятие WISIWYG расшириться и на точную цветопередачу.

                                            А что с переходом на пропорциональные шрифты и графическую печать оно сузилось — это закономерно.
                                              0
                                              Вы что, д_у_м_а_е_т_е, в эпоху м*о*н*о*ш*и*р*и*н*н*ы*х шрифтов и б*а*р*а*б*а*н*н*ы*х принтеров форматирования НЕ БЫЛО?

                                              С чего вы взяли что я так думаю? При чем тут вообще это?
                                              Вы мне всю ветку пытались доказать, что редактор комментариев на хабре и блокнот на винде — это WYSIWYG.
                                              Теперь решили просто случайных фактов накидать?
                                        0

                                        2d

                                          0
                                          На СМ-3/СМ-4 в основном использовались VT-52 совместимые 7битные терминалы, в которых вместо маленький латинских буквы были большие русские. Так что или 2D или 2Д, но не 2d. По воспоминания — 2D. vi был написан несколько позже. То, что мы использовали в RSX-11 — было ближе к ed.
                                            0

                                            Пардон, почему-то мне показалось что там опечатка.

                                        –1
                                        > Даже свой пост против WISIWIG вы все-таки писали в WISIWIG-редакторе.

                                        OMG, нет! Этот «свой пост против WISIWG» я писал Atom-е c Markdown-плагином. И выкладывал в закрытый репозиторий на гитхабе, чтобы коллеги поревьюили.
                            +10
                            Посмотрите на примеры кода и обратите внимание на то, что «координаты узлов графа» в скриптах GraphViz нигде не фигурируют. Вообще. Вы лишь прописываете связи между узлами (a->b->c; b<->d;), а в каких координатах будут нарисованы узлы — это дело GraphViz, в том-то и соль.

                            Как тут уже ответили, форматы типа pptx не приспособлены для того, чтобы смотреть диффы и мёржить в гите.

                            WYSIWYG — безусловно, изменил наш мир, сделав использование компьютеров более массовым. Но я бы не сказал, что переход на использование языков разметки — это «обратный процесс». Языки разметки существовали всегда, просто для профессионального использования, а не для «бытового». Вы же, поди, web-страницы не во FrontPage верстаете? Да и тот же LaTeX, который спокойно пережил и 25 лет WYSIWYG, и ещё много чего переживёт.
                              +3

                              Оптимальное размещение графа — это вся суть GraphViz, но иногда хочется нарисовать граф по-красивее и логически структурированнее, а GraphViz позволяет настраивать параметры компоновки в очень ограниченных пределах. В этом случае приходится либо смиряться с алгоритмами оптимизации GraphViz, либо рисовать диаграмму вручную в каком-нибудь draw.io.

                              +7

                              Я все свои (увы, немногочисленные) научные статьи, презентации и прочее пишу в латехе и храню в гите. Рисунки там же, при этом это может быть tikz, graphviz или вообще gnuplot-скрипт для генерации графиков по данным. Очень удобно.

                                +6
                                Помню, лет 25 назад в нашу жизнь ворвался подход WYSIWYG. Забавно наблюдать обратный процесс :)

                                Потому, что пришло понимание того, что WYSIWYG не серебряная пуля
                                +10
                                Наш выбор пал на AsciiDoctor, и выбору этому мы не перестаём радоваться, но это тема для отдельной статьи.

                                Реквестую!

                                  +3
                                  Да, надо, надо будет!
                                    +1

                                    Отлично, тогда я не буду писать. Вплотную подсел на Asciidoc пару месяцев назад, доволен крайне. Удивлён что маркдаун гораздо более известен. С технической точки зрения преимуществ маркдауна перед asciidoc я не нашёл примерно ни одного.

                                  +5
                                  Статья больше похоже на рекламу Аскии-доктора, чем на пример из опыта работы. Я обратил внимание на статью, поскольку мы очень много работаем с дизайнерами и презентациями: на каждого клиента своя презентация, чаще всего свой дизайн под каждого клиента, копи-паст не пройдет.
                                  Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах.

                                  Я правильно понимаю, что в тексте отмечено отсутствие версионирования, как проблема работы powerpoint?
                                  Также указано некорректное отображение на машинах из-за разных шрифтов? Автор забыл про интеграцию шрифтов в документ?

                                  Ошибки объявлены, и автор предложил панацею и все довольны: Asciidoctor (произносится как «Адский-доктор»).

                                  Даже если предположить, что статья — это не реклама. Смотрим, как это решает объявленные и неявные сложности:

                                  Store [shape=«cylinder»; label=«Local Store»; fixedsize=«true»; width=«1.5»]
                                  Source -> MapVal -> Sum -> Sink
                                  Sum -> Store [dir=both; label=" \n "]

                                  Я не смогу заказать подобный дизайн в местных дизайнерских фирмах. Меня просто пошлют подальше с предложением разработать презентацию в таком виде. Вы знаете, у кого можно заказать подобную презентацию?

                                  Не понятно из статьи, как решена объявленная проблема работы со шрифтами.

                                  Как решается вопрос версионирования в Аскидокторе?

                                  На мой взгляд получается, что для единоличного пользования Аскии-доктор может и прокатит, но для потоковой работы с презентациями преимуществ не обнаружено.

                                  P.s. Забыл сказать, что мы тоже не работаем с MS-Powerpoint. У нас стоят только Adobe продукты.
                                    +8
                                    1. Про шрифты. Шрифты прекрасно интегрируются в проект презентации. Посмотрите на примеры проектов в гитхабе (ссылки в конце статьи), всё станет ясно.

                                    2. Про версионирование. Кажется, я прямо начинаю с того, что презентация из себя представляет проект в виде набора plain-text-исходников, и версионирование производится системой контроля версий. С ветками, пулл-реквестами и прочими прелестями, которые мы используем для любого другого кода, будь то программа на Java, конфигурация сервера на Ansible и т. д. и т. д.

                                    3. Про «дизайнеры пошлют подальше». Не предполагается, что дизайнеры должны разрабатывать диаграммы GraphViz или PlantUML, диаграмма — это контент презентации, её разрабатывает докладчик. А вот чему дизайнеры рады (и это действительно так по моему личному опыту) — так это тому, что можно реализовывать дизайн с помощью знакомой им HTML/CSS вёрстки. Все дизайнеры сегодня — веб-дизайнеры. Достаточно показать им index.html + CSS, и они реально рады предложить свои услуги. Ещё и спасибо говорить вам будут, что не в PowerPoint. Проверено.

                                    4. Про «рекламу AsciiDoctor». Жаль что кому-то так показалось. Нет, я не утверждаю, что этот подход годится всем и каждому. Многое зависит от характера контента презентации, от технической подготовки автора доклада, от мотивации людей, участвующих в процессе. Нам зашёл AsciiDoctor. В командах, где знают LaTeX — наверное, лучше LaTeX. Но в любом случае, я не знаю другого способа организовать совместную работу над большим проектом, кроме как представления его в виде кода на языке разметки, а самих языков разметки и технологий вокруг них — великое множество.
                                      0
                                      Идея то понятна, жаль, что «делегирование той части работы, что касается визуального дизайна слайдов» в Аскидокторе — наши местные фирмы так не работают.

                                      Про Word и документацию, а почему не собираете онлайн с импортом в PDF?
                                        +4
                                        Конкретно сейчас мою очередную презентацию дизайнит фирма. Всё нормально. До этого — дизайнили мы сами, только те из нас, кто лучше меня разбирается в верстке.

                                        Про Word: в смысле «собираете онлайн»? Вы на CI-системе предлагаете ворд-файлы в PDF выгружать? Ну это решило бы только микроскопическую часть проблем, которую мы имеем с вордом. Я даже не знаю с чего начать. Ну хотя бы начнём с того, что в ворде смешан контент и представление, и пользователи ворда снова и снова нарушают правила работы со стилями. А в языке разметки ты пишешь только контент с семантической разметкой, представление — не твоё дело вообще. Дальше, невзоможность мёржить, как следствие — невозможность работать с параллельными ветками, невозможность безопасно включить документацию в единый репозиторий с проектом и вести непрерывную документацию (когда требования к PR — это синхронная тройка изменений «код-тесты-документация», а не вот это вот: «ну мы сейчас изменение внесём, а когда-нибудь потом, когда руки дойдут, задокументируем»). Текстовые диффы. Гиперссылки. Инклюды (разбиение на подфайлы и их переиспользование). Тривиальная автогенерация AsciiDoc на основе других источников.
                                          +1
                                          Инклюды (разбиение на подфайлы и их переиспользование).

                                          В ворде есть subdocument, который как раз про это. Остальные проблемы текстовового редактора, конечно, остаются.
                                            +1

                                            Про невозможность мёржить вы неправы, word-документы прекрасно мёржатся и дифаются тем же word'ом, и с гитом это можно интегрировать. Другой вопрос, что, конечно же, это далеко не так удобно, как с чисто текстовым контентом. Но, если хочется, то делается.

                                              +4
                                              Расскажите, как.
                                                0

                                                Диффалка там есть в меню Review → Compare.
                                                Вроде бы она служит и мержилкой тоже, 3-way merge я там, к сожалению, не нашёл (простите, если ввёл в заблуждение, сам думал что оно есть, а его нет).


                                                Для диффа у меня на гитхабе лежит вот такой pwsh-скрипт, его можно интегрировать с гитом: https://github.com/ForNeVeR/ExtDiff

                                                  +1
                                                  В работе постоянно используем Word, и «Compare» частый инструмент, но вот работает он, порой мягко говоря не очень хорошо, самая частая выявленная проблема это не корректное отображение нумерованных списков, не верно отображает нумерацию
                                                  Пример
                                                  Буквально вчера было, в нумерованный список добавили 3-ой элемент, в обновленном документе все хорошо, но в результатах сравнения:
                                                  1.
                                                  1.1.
                                                  1.2.
                                                  2.
                                                  1.
                                                  1.1.
                                                  1.2.

                                                  3.
                                                  4.


                                                  Причем в последнее время встречаю этот баг регулярно. Приходится отдельно перепроверять в измененых документах.
                                                  Ну и картинки часто показывает что изменилось, при отсутствии в них изменения.
                                              –2

                                              Я имел ввиду вообще систему онлайн документации без какого либо формата. Висвиг редактором с заданными стилями. Вот уж точно однотипные доки будут

                                                +2
                                                систему онлайн документации без какого либо формата.

                                                Вам не важны результаты работы? Как вы резервные копии «без формата» делать будете?


                                                Рано или поздно любой онлайн-сервис прекратит деятельность.
                                                Если повезёт — предупредят за пол-года, не повезёт — просто в один прекрасный понедельник вместо онлайн-сервиса увидите «Сервер не найден вместе со всеми вашими документами. Спасибо, что пользовались нашими услугами».

                                                  0

                                                  не туда

                                          +2
                                          Спасибо за идею и подачу, на мой взгляд весьма изящный вышел подход, и Вы хорошо его описали — обязательно протестируем такой способ при подготовке презентации группой людей, которым код ближе чем тыканье мышкой в powerpoint :)

                                          Должно очень хорошо зайти, всё-таки у версионирования тут будет огромный плюс по сравнению с пересылкой файлов туда-сюда.

                                          И отдельный плюс — разделение информации и представления. Вот уж где мучение для многих программистов, имеющих своё специфическое (утилитарное) представление о красоте презентации ;) не совпадающее с тем что от них иногда требуют в оформлении.

                                          Кстати, по идее можно на выходе не только pdf, но наверно и в powerpoint формат скомпилировать, не изучали вопрос?
                                            0
                                            Мне кажется, выгрузка в powerpoint тут не возможна — по той же причине, что невозможна выгрузка в Word из LaTeX ) Но и зачем? не видел ещё ни одной конференции, которая бы отказалась принять слайды в формате pdf.

                                            Да, можете прямо за основу взять проект github.com/inponomarev/csa-hb — клонируйте его со всеми потрохами, всё должно работать. Если чего не заработает — пишите, помогу, чем смогу)
                                              +2
                                              Думаю что Вы согласитесь что слово «невозможно» тут только раззадорить может ;) Руки так и тянутся потратить время впустую но «сделать невозможное возможным».

                                              Варианты-то разные есть даже с закрытыми форматами — в конце концов можно перенести всё кусками, банально нарезав на скриншоты и вставив их как картинки. Неоптимально, но уже не невозможно. А раз можно руками, можно и автоматом, RPA в помощь. Ну и наверняка более оптимальные пути найдутся.

                                              К вопросу «зачем» — не знаю, потому и говорю что бесполезно :) Но мало ли, вдруг кому-то именно powerpoint-файл. Пусть не унывают)

                                              Про github Ваш спасибо, заходил уже туда, смотрел — всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)
                                                0
                                                всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)

                                                По хорошему схема и рендер должны быть доступны сразу.

                                              0
                                              Мне кажется, выгрузка в powerpoint тут не возможна

                                              pandoc-же!


                                              коммент также для bobrabobr

                                            +3

                                            Я тоже к подобному пришел, писал статью об этом: Современный формат презентаций.


                                            Только я использовал Markdown, а не AsciiDoctor. А почему вы используете его, первый же более распространенный?


                                            К счастью, AsciiDoctor интегрирован с системой Graphviz

                                            Вот это очень круто, мне такого не хватало.


                                            Две хитрости при запуске decktape, к которым пришлось прийти методом проб и ошибок:

                                            Да, к сожалению, с конвертингом исходников в другие форматы пока что есть проблемы.

                                              0
                                              > А почему вы используете его, первый же более распространенный?

                                              Наверное потому, что AsciiDoctor более распространён у нас в компании в принципе.

                                              Для написания слайдов, наверное, нет большой разницы между Markdown и AsciiDoctor. А для написания документации (задача, под которую к нам «зашёл» AsciiDoctor) — разница есть в пользу последнего, например, структурирование таблиц в AsciiDoctor гораздо более продвинуто.
                                                0
                                                Посмотрел Вашу статью. Да, мы явно сходимся по убеждениям насчёт презентаций) И внезапно узнал, что есть MarkConv для конвертации из гитхаба в хабр. В следующий раз попробую!!!
                                                  +2

                                                  Да, есть такой :) Пользуйтесь, обращайтесь если что. Можно даже репортить баги и дорабатывать. Вообще я о нем собирался статью на хабр написать, но пока что руки не дошли.


                                                  Я этот движок во всю использую при публикации, сами статьи хранятся тут: Articles.


                                                  В планах — доработать конвертацию статей на CI сервере, использовать другой движок парсинга. К сожалению, у хабра нет публичного API для публикаций и обновления статей, поэтому приходится просто их копипастить вручную. Однако можно попробовать подход из статьи Плагин к Sublime Text для публикации статей на Хабр хотя бы для плагинов к текстовым редакторам.

                                                    0
                                                    А ничего, что статьи в гите лежат открытом в доступе до публикации?

                                                    Вдруг они заиндексируются поисковиком, а потом при публикации на хабр оно заблокируется по «антиплагиату»? Ведь по правилам хабра, размещать тут репосты нельзя, а если статья уже в открытом гитхаб-репозитории лежит, то она как бы тем самым уже в веб запощена. Или нет такой проблемы? хотелось бы кстати от НЛО услышать мнение на сей счёт)
                                                      0

                                                      Да вроде как уже можно

                                                        0
                                                        А ничего, что статьи в гите лежат открытом в доступе до публикации?

                                                        И над этим вопросом я конечно же подумал :) Сейчас у меня есть два репозитория: приватный, для написания и вычитки редакторами, и публичный, для уже опубликованных статей и потенциальных правок со стороны читатей. Так как используется Git, то нет проблемы пушить и пулить в оба репозитория. С недавнего времени у GitHub появились бесплатные приватные репозитории, а так вообще им не ограничивается, можно использовать GitLab, Bitbucket и другие сервисы. А вообще на самом деле часто всем пофиг, поэтому можно сразу пушить в паблик репозитории какие-то вещи. Поисковики вряд ли индексируют определенные ветви.

                                                    +1
                                                    А почему вы используете его, первый же более распространенный?

                                                    1. Потому что Acsiidoc технически лучше
                                                    2. Если бы большая распространённость была веским аргументом, в мире бы вообще не появлялось новых технологий, т.к. в начале своего зарождения они распространены на нуль.
                                                      0
                                                      Потому что Acsiidoc технически лучше

                                                      Можете расписать подробней почему технически лучше? У него больше возможностей?

                                                        +3

                                                        Существенно больше:


                                                        1. Инклюды. Причём можно инклюдить не только аскидок-файлы, но и, например, файлы с кодом (и даже фрагменты из файлов с кодом).


                                                        2. Таблицы. Причём они смогли придумать удобный синтаксис, позволяющий описывать ячейки на раздельных строках.


                                                        3. Из коробки умеет производить html/pdf/epub/man и reveal.js-презентации, про который эта статья.


                                                        4. Более простое управление блоками. Например, попробуйте в маркдауне запихнуть блок текста внутрь элемента списка. В аскидоке для этого достаточно написать + на пустой строке между элементом списка и блоком.


                                                        5. Контролируемый механизм расширений, в документе чётко размечено где какое расширение.


                                                        6. Макросы, способствующие принципу DRY.


                                                        7. Настраиваемое поведение в масштабах документа. Оглавление, нумерация глав/изображений/примеров кода. В маркдауне всего этого просто нет.


                                                        8. Поддержка глоссария и списка библиографии. Ну и вообще, аскидок нацелен на то что на выходе может быть книга, а не просто html-страничка.


                                                        9. Ну и офигенная документация всего этого добра: https://asciidoctor.org/docs/user-manual/



                                                        Ну и с учётом того что аскидок как и маркдаун из коробки поддерживается в github/gitlab, я вообще не знаю какие у маркдауна перед ним преимущества.

                                                          +1
                                                          Тоже считают, что asciidoctor в настоящий момент — лучшее решение. Но справедливости ради необходимо отметить, что (1) есть не менее популярный Shinx (https://github.com/sphinx-doc/sphinx), (2) есть проекты, которые пытаются и довольно успешно компенсировать недостатки маркдауна (https://github.com/foliant-docs/foliant) и (3) на солнце (в asciidoctor'е) тоже есть пятна
                                                    +6

                                                    Наверно у вас не принят Sharepoint, поэтому вы не в курсе, но в современном Офисе collaborative редактирование очень даже удобно. Можно редактировать спредшит или слайды одновременно полсотней человекам, при этом сохраняется история версий с возможностью отката, можно видеть над каким слайдом/диапазоном работает любой коллега, есть встроенный чатик и проч…
                                                    Честно говоря не могу себе представить как язык разметки лучше чем диаграмма из pp в условиях близкого дедлайна. Выяснить во время компиляции что картинка swampboy.jpg переименована или находится на чьем-то локальном диске, или что в разметке диаграммы стрелочки не в ту сторону…

                                                      +1
                                                      Выяснить во время компиляции что картинка swampboy.jpg переименована или находится на чьем-то локальном диске, или что в разметке диаграммы стрелочки не в ту сторону…

                                                      А разве рендер сразу вместе с исходником не доступен? Я думал выглядит это так: слева — исходник, справа — рендер. Во всяком в моем подходе, который выше уже упоминал, это именно так. Реализовано это как плагин к VSCode. Либо просто переключение между исходником и рендером с помощью кнопочки.

                                                        0

                                                        Я представил обычную ситуацию, когда в субботу вечером ваша команда налепила слайдов и довольная разошлась по домам, с вы просматриваете pdf перед тем как послать клиенту и находите на слайде . Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается...

                                                          0
                                                          Ситуация возможна, да. Но сразу вопрос — скажите пожалуйста, а с тем же sharepoint никогда не сталкивались с ограничением прав? Все могут всё что угодно редактировать? ;)
                                                          По идее такая ситуация возможна в большинстве подобных систем (обратная сторона медали, куда же без неё).
                                                            0
                                                            Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается...

                                                            Если все хранится в Git репозитории, то доступ ко всем файлам внутри репозитория есть у всех. Поэтому либо вы не используете систему контроля версий, что не очень хорошо, либо кто-то неправильно ей воспользовался.

                                                              0
                                                              Всё-таки думается что описанная ситуация возможна, т.к. неправильно как-то если доступ есть у всех и ко всему — иначе, условно, клинеры придут и вместе с пылью код почистят) Или в прод пасхалок насуют.

                                                              Так что там где разграничение прав доступа есть, ситуация возможна.

                                                              Но это явно не уникальная проблема описываемого тут подхода, не вижу причин почему с sharepoint и пр ситуация была бы иная (бесконтрольность vs проблема отсутствия доступа к неким материалам, если доступ забыли дать).
                                                                0
                                                                Всё-таки думается что описанная ситуация возможна, т.к. неправильно как-то если доступ есть у всех и ко всему — иначе, условно, клинеры придут и вместе с пылью код почистят) Или в прод пасхалок насуют.

                                                                Доступ есть ко всем файлам, но не ко всем веткам. Например, часто ветвь master является защищенной, т.е. коммитить туда может только ограниченный круг лиц, а то и вообще через merge request. Если "клинер" что-то там себе подчистит, то ревьювер сразу это заметит по изменениям в риквесте.

                                                                  0
                                                                  Вы правы, вообще-то с точки зрения исходной проблемы
                                                                  Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается
                                                                  в таком случае если в целом доступ к репозиторию есть то сделать себе копию и исправить до отправки клиенту можно; а потом отправить merge request, если нет «доступа к папочке» (в данном случае к записи в master).
                                                          0
                                                          Тут речь о целевой аудитории, кому что ближе. Кому-то проще мышкой и визуально, а кому-то проще клавиатурой исходник написать, чтобы визуальная часть сама собралась.

                                                          Что касается последнего пункта — проблем с картинкой и стрелочкой — так тут инструмент можно сказать на коленке придуман и ещё не успел обрасти фичами полезными.

                                                          И тест на наличие картинки в нужной локации, и моментальный визуальный превью диаграмм — это же вообще не проблема.

                                                          Так же как в sharepoint нужные фичи допиливаются (у знакомых в относительно небольшой конторе целый отдел этим занят), так и тут при желании можно любую нужную обвязку вокруг накидать быстро.

                                                          Вплоть до того что условно через чат-бота в мессенджере писать/редактировать презентацию и диаграммы (!!!) :)
                                                            0
                                                            Ох) Сейчас бы шарепоинт поднимать, чтобы текст поредактировать…
                                                            Спасибо, что не предложили собственное облако поднимать с закупкой серверов)
                                                              0

                                                              Процесс непрерывной интеграции, о котором в том числе говорится в статье в отношении презентации, более чем отлично может отрабатывать ситуации с недоступными ресурсами, а заодно и с многими другими возможными нарушениями качества, которые можно поймать автоматически: орфография, висячие предлоги в заголовках и т.п. Направление стрелочки, конечно, попутать можно, впрочем, как и Северную Корею с Южной.


                                                              Если говорить в целом об организации совместной работы, то система контроля версий и непрерывная интеграция — это другой порядок эффективности, чем Sharepoint. Проблема в том, что часто нужна функциональность Powerpoint’а. Ну и тот же git, да ещё и с Travis’ом, да ещё и с Maven’ом освоить значительно сложнее, чем Sharepoint.

                                                              0

                                                              В статье смешиваются AsciiDoc (язык разметки) и AsciiDoctor (конкретную реализацию инструментов для работы с AsciiDoc)

                                                                +1

                                                                Кстати, а движок диаграмм mermaid не пробовали использовать? Можно ли его подчключить?

                                                                  0
                                                                  Посмотрел, интересный движок! Не знаю, как обстоят дела с интеграцией его в AsciiDoctor
                                                                    0
                                                                    Реально интересная штука, спасибо!
                                                                    Вопрос: а мне одному там в примере «An example of a sequence diagram» не хватает стрелочек на визуализации? Конкретно в «John->Bob: How about you?» вообще не понять, откуда куда сигнал идёт. Что я упустил?..
                                                                      +1

                                                                      Но, кажется PlantUML всё ещё мощнее, особенно учитывая stdlib.

                                                                        0
                                                                        Согласен, первое впечатление такое, что во многом это повторение PlantUML. Хотя есть интересные специфичные диаграммы (гит граф, или гантт)
                                                                      0

                                                                      Вань, спасибо за статью! А как выглядит презентация? Next slide есть?

                                                                        0
                                                                        Пожалуйста за статью ) Презентация выглядит или так (HTML) или так (PDF). Открываешь либо браузер, либо Acrobat Reader в полноэкранном режиме, кликер в руку и жгёшь :-)

                                                                        Каких-то мультиэкранных фишечек (слайд-заметки, следующий слайд на другом экране), конечно, нет, ибо это всего лишь браузер или всего лишь Acrobat Reader.
                                                                      +1

                                                                      Спасибо за статью!
                                                                      Кстати, Travis позволяет описывать деплой в конфиге, который он потом сам и разливает в нужный бранч на гитхабе. Пример.

                                                                        +1
                                                                        Спасибо за комментарий! Век живи, век учись! Буду теперь знать про `deploy: provider: pages` в Трависе, спасибо!
                                                                        0
                                                                        Тоже давно не использую MS, перешел на гугл-презентации. Подскажите, чем в плане использования (и возможности правок) ваше решение принципиально лучше пакета презентаций из гугл-докс?
                                                                          0
                                                                          Всё зависит от задачи. Может быть, в вашем случае как раз лучше гугл-докс (который очень неплох)!

                                                                          Лично мне удобнее наш вариант из-за
                                                                          • возможности простой вставки исходников с автоподсветкой синтаксиса,
                                                                          • кодирования диаграмм GraphViz/PlantUML,
                                                                          • единого для всей команды процесса работы с исходниками (GitHub/pull requests), с текстовыми диффами
                                                                          • понятного дизайнерам и верстальщикам CSS


                                                                          Ну и в принципе оно как-то спокойнее, что все исходники твоих документов — у тебя, а не неизвестно в каком формате в облаке.

                                                                          Но, ещё раз повторюсь: всё зависит от задачи. Если у вас нет массовых слайдов с кодом, например, то гугл-докс — отличный выбор.
                                                                          –1

                                                                          Генерация PDF как-то костыльно выглядит.
                                                                          Доктор на Ruby, но для генерации PDF будьте любезны установить Node.js с браузером.
                                                                          TeX в PDF более естественным путём превращается.

                                                                            +1
                                                                            Увы и ах. Доктор переносит всё только в HTML. decktape уже, управляя безголовым хромом, записывает снимки страниц в PDF.

                                                                            Кстати, decktape способен таким образом конвертировать не только RevealJS слайды, но вообще слайды из кучи других презентационных фреймворков.

                                                                            И ещё, кстати, ставить браузер не надо. Пакет puppeteer тащит автоматом безголовый хром за собой. Ну и в принципе если это всё происходит на CI, то хлопот не так много.

                                                                            А вообще, кто уже делает слайды в техе, те молодцы и им тут делать нечего, я считаю ))))
                                                                            0

                                                                            https://yhatt.github.io/marp/
                                                                            https://gitpitch.com/
                                                                            https://remarkjs.com/


                                                                            Миллион их, почему именно AsciiDoctor?

                                                                              0

                                                                              AsciiDoc — это не только лишь презентации. При этом в презентациях он достаточно хорош чтобы не было желания использовать для них узкоспециализированный инструмент.

                                                                              –1
                                                                              Делаю презентации на голом HTML + SVG + JS. Быстро, просто, очень гибко.
                                                                                –3

                                                                                Держите нас в курсе.

                                                                                0

                                                                                С презентациями классно. А как на счёт верстки документов в css/html с наполнением через markdown, чтобы выглядело как отчёт или документация или например курсач?

                                                                                  0

                                                                                  Для презентаций еще есть интересный вариант в виде org-mode + reveal.js: пишем презентацию как обычную заметку в org-mode (добавляется лишь несколько кастомных тегов), а потом автоматически можем сконвертировать в красивую HTML5 презентацию.
                                                                                  Из плюшек reveal'а:


                                                                                  • Возможность создавать нелинейных презентаций. Т.е. слайды могут структурироваться в виде грида, когда двигаться можно влево/вправо/вверх/вниз, это бывает удобно, когда хочется добавить сопроводительного материала, для иллюстрации возможных вопросов, которым не хочется загромождать основную презентацию.
                                                                                  • Возможность создавать спикер ноуты к слайдам. Во врмея презентации на экране спикера можно выводить много всякой информации помимо самих ноутсов, например тайминги по всей презентации и по текущему слайду и тд и тп.
                                                                                  • Даже из коробки там вполне приличный стиль и можно особо не париться с оформлением презентации. Но если есть желание заморочиться, то вся мощь HTML5 поможет в этом.

                                                                                  Вообще в reveal можно конвертироваться не только из org-mode, но и из других форматов, типа markdown, но связка с org'ом позволяет за считанные минуты превратить свои заметки в презентацию, готовую к показу.

                                                                                    +1
                                                                                    Не могу не упомянуть про `pandoc`. Он умеет генерировать beamer-презентации из org-mode файликов, markdown-файликов и ещё огромного множества форматов. Получается быстро и довольно красиво.
                                                                                      0

                                                                                      … если вы смогли установить LaTeX, а также преодолеть проблемы с юникодом. Сходу markdown->pdf в pandoc юникодные символы не переваривает.

                                                                                        0
                                                                                        Это да, но решается элементарно использованием xelatex+нормального шрифта.
                                                                                      0
                                                                                      Просто в качестве мысли.

                                                                                      По сути, презентация PowerPoint — это ведь тоже plaintext. Вернее, это набор файлов xml, и картинок, просто запакованных в zip-архив переименованный в .pptx.

                                                                                      Я не проверял, но по логике можно хранить презентацию в распакованном виде на github и мержить изменения. Хотя для удобства придется отдельно написать скрипты автоматически собирающие/разбирающие .pptx.

                                                                                      Правда тут желательно придерживаться одной версии PowerPoint, иначе могут вноситься сногочисленные изменения в конфиг-файлах при каждом пересохранении. На результат они не повляют, но наглядность истории изменений пострадает… Хотя можно выводить только правки файлов «presentation.pptx\ppt\slides\slide[n].xml» — там все что относится к самим слайдам.
                                                                                        0
                                                                                        По сути, презентация PowerPoint — это ведь тоже plaintext. Вернее, это набор файлов xml, и картинок, просто запакованных в zip-архив переименованный в .pptx.

                                                                                        Все так, но в этих xml много избыточности и дифать их неудобно.


                                                                                        Я не проверял, но по логике можно хранить презентацию в распакованном виде на github и мержить изменения. Хотя для удобства придется отдельно написать скрипты автоматически собирающие/разбирающие .pptx.

                                                                                        Git можно настроить таким образом, чтобы он использовать разные diff утилиты для разных расширений, в частности, для pptx.

                                                                                        0
                                                                                        Есть легкие но за деньги системы, не SharePoint которые помогают управляться с библиотеками слайдов, и генерить презентацию из библиотеки на ходу на базе свежих версий слайдов- типа Zoom( искать по slide management).
                                                                                        Сам давно на такое смотрю, страдая так же, от бесчисленных версий презентаций, кастомизированных и переведенных для заказчиков, где правки постоянно теряются.
                                                                                        Подход как код я бы назвал ортогональным — управляемость в ущерб дизайну. С другой стороны здесь хоть можно прикрутить постобработку дизайнерскую, но тогда мы опять получаем ситуацию, что часть работы живет в отрыве от версионирования.

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                        Самое читаемое