Comments 115
А что мешало .pptx хранить в GitHub? Ну и прям сплю и вижу, насколько удобнее в голове прикидывать координаты узлов графа, нежели ткнуть мышкой в редакторе. :)
Ничего не мешает, вот только мержить не очень удобно… Точнее почти невозможно.
2) Архива версий/изменений, как я понимаю, нет.
Так может будущее — одновременная работа как с текстом, так и с WYSIWYG? Каждый выбирает что ему удобней, а противоположное представление формируется автоматически.
Секрет прост — текстовый вид не включает варианты правильных настроек и контроль неправильных.
Прежде чем рассуждать о недостатках WISIWIG-редакторов, попробуйте поредактрировать файл без WISYWIG. Я про EDLIN, TECO и им подобные. На протяжении десятка лет работы с аналогами EDLIN я все время видел одну и ту же картину — пользователи стрелой убегают из хорошего навороченного строчного редактора в простейший WYSIWIG (TED).
Текст легко обрабатывать, хранить, передавать, демонстрировать, сравнивать, индексировать, и так далее, нежели пропиетарные бинарные форматы.Работа с текстом без WISYWIG нужна лишь отдельным программистам. Не верите — ну напишите статью при помощи echo, а редактируйте её SED.
Даже свой пост против WISIWIG вы все-таки писали в WISIWIG-редакторе.
Зато без WISIWIG — работают 5-6 пользователей на 62 килобайта памяти (на M6000). Возможности работы со считанными килобайтами у строчных редакторов не отнять.
Вопрос тут прагматичнее. Научился делать что-то в plaintext’е — сможешь грузить это на рынок килограммами. Приведу по памяти цитату Генри Форда: «Чтобы достичь успеха, необходимо научиться делать что-то полезное в больших количествах и по низкой цене».
Вы хоть раз в жизни пробовали редактировать plain-текст без WISIWIG?
Даже у асов строчного редактора скорость в WISIWIG в 2-3 раза больше. У не асов — в 10 раз больше, у новичков… Возьмите редактор VI и попробуйте набивать и редактировать текст без режима вставки.
Ни о каких " килограммах" без WISIWIG речь не идёт, в среднем — 10 строк текста в день.
И ещё раз, WISIWIG полезнее всего именно для plain- текста. Потому что люди превращают любой plain в двумерный объект сложной структуры. Вспомните про отступы.
«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 не является.
Боюсь, что в те годы, когда появился этот термин, вас ещё на свете не было. Поэтому и не понимаете, что ввод комментария на хабре — это именно визуальное редактирование, WISIWYG. Иного визуального редактирования на текстовых терминалах 70х годов просто не было.
Так что вы мне напоминание того героя Мольера, который с удивлением узнал, что говорит прозой.
Чтобы удалить 2 символа в невизуаальном режиме, надо дать команду 2D, примерно как в командном режиме vi. Это очень удобно для программирования, но крайне неудобно для редактирования человеком.
Примерно с конца 50х годов плоские файлы стали не совсем плоскими — появились отступы и разбивка на абзацы. Настоящий плоский текст сейчас используется только в языках типа breinfuck. Ну или в редких случаях использования перфоленты.
Просто я настолько стар, что застал и перфоленты и строчные редакторы и совсем плоские тексты программ.
Иного визуального редактирования на текстовых терминалах 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.
Господи, какая каша у вас в голове. Теги HTML — это разметка. Она может вставляться как визуальным редактором ( где коды не видны), так и невизуальным.
Но я о другом, о кодах перевода строки. Вы эту разметку видите? Всякие CR и LF? Не видите.
И самое главное — вы перемещаете курсор по тексту и мгновенно видите результат редактирования текста. А не даёте вначале команды движения курсора, потом команды редактирования, потом — отображения результате.
Вы просто привыкли, что любой редактор плоского текста визуальный. Видимо see, teco, edlin и командный режим vi ошеломят вас.
Я не спорю, что с годами люди настолько отвыкли от командных и строчных редакторов, что даже в вики написали неверно.
В эпоху барабанных принтеров и символьных дисплеев WISIWYG был именно таким. Никакого курсива, никаких шрифтов, даже никаких маленьких букв. Максимум — отдельные принтеры позволяли хак с жирным шрифтом.
И вот тогда и появились визуальные редакторы и маркетинговый термин WISIWYG.
А уж потом этот маркетиновый термин перезапустили еще раз, для графических терминалов и матричных принтеров.
Вы разметку разделения на строки видите? У вас текст плоский, то есть одномерная лента символов? Вы делаете навигацию по тексту командами? Вы редактируете командами?
Пять "нет" — это чистый wisiwyg. Просто для обычных текстов, а не rich.
А чтобы понять, насколько это удобно — набейте свой ответ в редакторе SED.
Перевод строки я вие переводом строки не потому что это WYSIWYG, а потому что это то, как поле ввода отображает ascii-символ #10. И конечно же я могу сделать так, чтобы он отображался взуально тоже.
А ещё я могу заставить редактор текста издавать пищение бипером, используя символ ascci #7 (Если ещё не выкосили это из последних редакторов текста). Конечно же командный режим vi ровно так же отображает перенос строки.
И вы упорно продолжаете неправильно писать термин WYSIWYG — на английском языке там просто не может быть I второй буквой.
В этом смысле барабанные принтеры и полноэкранные редакторы обеспечивали лучший WISIWYG, чем нынешний ворд. С вордом надо очень постараться, чтобы на любом принтере оно печаталось одинаково. Ну хотя бы из-за разных дефолтных размеров полей.
Перевод строки я вие переводом строки не потому что это WYSIWYG, а потому что это то, как поле ввода отображает ascii-символ #10.Гм, вы редакторы текста писали? Ну ОК, напиши редактор текста для
Как вы думаете, как отрабатывается простейший backspace? В режиме замены — сдвиг курсора влево, вывод пробела, опять сдвиг влево. Если backspace умеет отрабатывать в нулевой позиции строки, то все хитрее — может потребоваться даже сдвиг экрана, если мы делаем backspace из нулевой колонки нулевой строки. Ещё сложнее — в режиме вставки.
Так что WISIWYG режим требует от терминала хотя бы 8-битного процессора, терминалы на дискретной логике поддержать его не могут.
Собственно попробуйте в консольном режиме написать WISIWYG редактор — сразу увидите, как много операций вам надо.
А нынешние «поля ввода» практически все нужное умеют сами, это не секрет.
WISIWYG — What I See (on screen) Is What You get (on paper).
Термин не гуглится, так что я считаю что вы его придумали и дискуссию не продолжаю.
С приходом персоналок отличие между тем, кто редактирует документ и тем, кто забирает его с распечатки, разумеется, стерлось. Молодежь не понимает, что ЭВМ могла занимать целый этаж, а час машинного времени стоит половину зарплаты программиста.
У меня вполне нагуглился: раз, два, три, четыре… ЧЯДНТ? Но вообще материалы доинтернетной эпохи гуглятся очень плохо.
А по вашей логике получается, что стандарта С++17 не существует? Ибо полный текст стандарта (а не final draft) не гуглится. Как и куча других платных стандартов.
Даже некоторые вещи из современных ГОСТ не гуглятся. Вот в этом ГОСТ упомянут PRDCU. Он тоже не гуглится.
P.S. insolite, товарищ, при написании с мобильника в поезде, очень плохо по клавиатуре попадает. Так что там и VIVIVIC мог быть. Но как раз изначальный смысл термина — не распечатывать много раз, а видеть на экране то, что будет напечатано. И для плоского текста — это эквивалентно экранному редактированию. В отличие от строчного.
А что товарища могила ждет не дождется — это факт.
Пять «нет» — это чистый wisiwyg. Просто для обычных текстов, а не rich.
WYSIWYG имеет отношение к форматированным документам, в большинстве редакторов мы набираем plain text. По-вашему получается что даже блокнот на винде — WYSIWYG.
Ну и перевод строки, это стого говоря, не форматирование.
Верстка и форматирование в эту эпоху были, как и программы для них.
Выключкупо формату изначально делали вручную, пробелами. Потом появились программы верстки, делающие выключку в плоских текстах, потом стало возможным эту выключку делать в WISIWYG редакторах вручную. Более того, некоторые из них (может ЛЕКСИКОН?) умели делать выключку сами. Несмотря на плоские тексты.
Аналогично с форматированием программного кода в алгоподобных языках — форматеры появились где-то в 60ые. Да, отступы делались пробелами и табуляциями, но они делались.
Строго говоря, нынешний WISIWYG тоже неполноценен, ибо по цветам на принтере получаем совсем не то, что на экране. Так что вангую, что после широкого распространения дешевых цветных принтеров и вхождения в документы цвета понятие WISIWYG расшириться и на точную цветопередачу.
А что с переходом на пропорциональные шрифты и графическую печать оно сузилось — это закономерно.
Вы что, д_у_м_а_е_т_е, в эпоху м*о*н*о*ш*и*р*и*н*н*ы*х шрифтов и б*а*р*а*б*а*н*н*ы*х принтеров форматирования НЕ БЫЛО?
С чего вы взяли что я так думаю? При чем тут вообще это?
Вы мне всю ветку пытались доказать, что редактор комментариев на хабре и блокнот на винде — это WYSIWYG.
Теперь решили просто случайных фактов накидать?
2d
OMG, нет! Этот «свой пост против WISIWG» я писал Atom-е c Markdown-плагином. И выкладывал в закрытый репозиторий на гитхабе, чтобы коллеги поревьюили.
Как тут уже ответили, форматы типа pptx не приспособлены для того, чтобы смотреть диффы и мёржить в гите.
WYSIWYG — безусловно, изменил наш мир, сделав использование компьютеров более массовым. Но я бы не сказал, что переход на использование языков разметки — это «обратный процесс». Языки разметки существовали всегда, просто для профессионального использования, а не для «бытового». Вы же, поди, web-страницы не во FrontPage верстаете? Да и тот же LaTeX, который спокойно пережил и 25 лет WYSIWYG, и ещё много чего переживёт.
Оптимальное размещение графа — это вся суть GraphViz, но иногда хочется нарисовать граф по-красивее и логически структурированнее, а GraphViz позволяет настраивать параметры компоновки в очень ограниченных пределах. В этом случае приходится либо смиряться с алгоритмами оптимизации GraphViz, либо рисовать диаграмму вручную в каком-нибудь draw.io.
Помню, лет 25 назад в нашу жизнь ворвался подход WYSIWYG. Забавно наблюдать обратный процесс :)
Потому, что пришло понимание того, что WYSIWYG не серебряная пуля
Наш выбор пал на AsciiDoctor, и выбору этому мы не перестаём радоваться, но это тема для отдельной статьи.
Реквестую!
Как-то раз я попытался работать с дизайнером, пересылая файлы .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 продукты.
2. Про версионирование. Кажется, я прямо начинаю с того, что презентация из себя представляет проект в виде набора plain-text-исходников, и версионирование производится системой контроля версий. С ветками, пулл-реквестами и прочими прелестями, которые мы используем для любого другого кода, будь то программа на Java, конфигурация сервера на Ansible и т. д. и т. д.
3. Про «дизайнеры пошлют подальше». Не предполагается, что дизайнеры должны разрабатывать диаграммы GraphViz или PlantUML, диаграмма — это контент презентации, её разрабатывает докладчик. А вот чему дизайнеры рады (и это действительно так по моему личному опыту) — так это тому, что можно реализовывать дизайн с помощью знакомой им HTML/CSS вёрстки. Все дизайнеры сегодня — веб-дизайнеры. Достаточно показать им index.html + CSS, и они реально рады предложить свои услуги. Ещё и спасибо говорить вам будут, что не в PowerPoint. Проверено.
4. Про «рекламу AsciiDoctor». Жаль что кому-то так показалось. Нет, я не утверждаю, что этот подход годится всем и каждому. Многое зависит от характера контента презентации, от технической подготовки автора доклада, от мотивации людей, участвующих в процессе. Нам зашёл AsciiDoctor. В командах, где знают LaTeX — наверное, лучше LaTeX. Но в любом случае, я не знаю другого способа организовать совместную работу над большим проектом, кроме как представления его в виде кода на языке разметки, а самих языков разметки и технологий вокруг них — великое множество.
Про Word и документацию, а почему не собираете онлайн с импортом в PDF?
Про Word: в смысле «собираете онлайн»? Вы на CI-системе предлагаете ворд-файлы в PDF выгружать? Ну это решило бы только микроскопическую часть проблем, которую мы имеем с вордом. Я даже не знаю с чего начать. Ну хотя бы начнём с того, что в ворде смешан контент и представление, и пользователи ворда снова и снова нарушают правила работы со стилями. А в языке разметки ты пишешь только контент с семантической разметкой, представление — не твоё дело вообще. Дальше, невзоможность мёржить, как следствие — невозможность работать с параллельными ветками, невозможность безопасно включить документацию в единый репозиторий с проектом и вести непрерывную документацию (когда требования к PR — это синхронная тройка изменений «код-тесты-документация», а не вот это вот: «ну мы сейчас изменение внесём, а когда-нибудь потом, когда руки дойдут, задокументируем»). Текстовые диффы. Гиперссылки. Инклюды (разбиение на подфайлы и их переиспользование). Тривиальная автогенерация AsciiDoc на основе других источников.
Про невозможность мёржить вы неправы, word-документы прекрасно мёржатся и дифаются тем же word'ом, и с гитом это можно интегрировать. Другой вопрос, что, конечно же, это далеко не так удобно, как с чисто текстовым контентом. Но, если хочется, то делается.
Диффалка там есть в меню Review → Compare.
Вроде бы она служит и мержилкой тоже, 3-way merge я там, к сожалению, не нашёл (простите, если ввёл в заблуждение, сам думал что оно есть, а его нет).
Для диффа у меня на гитхабе лежит вот такой pwsh-скрипт, его можно интегрировать с гитом: https://github.com/ForNeVeR/ExtDiff
1.
1.1.
1.2.
2.
1.
1.1.
1.2.
3.
4.
Причем в последнее время встречаю этот баг регулярно. Приходится отдельно перепроверять в измененых документах.
Ну и картинки часто показывает что изменилось, при отсутствии в них изменения.
Я имел ввиду вообще систему онлайн документации без какого либо формата. Висвиг редактором с заданными стилями. Вот уж точно однотипные доки будут
систему онлайн документации без какого либо формата.
Вам не важны результаты работы? Как вы резервные копии «без формата» делать будете?
Рано или поздно любой онлайн-сервис прекратит деятельность.
Если повезёт — предупредят за пол-года, не повезёт — просто в один прекрасный понедельник вместо онлайн-сервиса увидите «Сервер не найден вместе со всеми вашими документами. Спасибо, что пользовались нашими услугами».
не туда
Должно очень хорошо зайти, всё-таки у версионирования тут будет огромный плюс по сравнению с пересылкой файлов туда-сюда.
И отдельный плюс — разделение информации и представления. Вот уж где мучение для многих программистов, имеющих своё специфическое (утилитарное) представление о красоте презентации ;) не совпадающее с тем что от них иногда требуют в оформлении.
Кстати, по идее можно на выходе не только pdf, но наверно и в powerpoint формат скомпилировать, не изучали вопрос?
Да, можете прямо за основу взять проект github.com/inponomarev/csa-hb — клонируйте его со всеми потрохами, всё должно работать. Если чего не заработает — пишите, помогу, чем смогу)
Варианты-то разные есть даже с закрытыми форматами — в конце концов можно перенести всё кусками, банально нарезав на скриншоты и вставив их как картинки. Неоптимально, но уже не невозможно. А раз можно руками, можно и автоматом, RPA в помощь. Ну и наверняка более оптимальные пути найдутся.
К вопросу «зачем» — не знаю, потому и говорю что бесполезно :) Но мало ли, вдруг кому-то именно powerpoint-файл. Пусть не унывают)
Про github Ваш спасибо, заходил уже туда, смотрел — всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)
всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)
По хорошему схема и рендер должны быть доступны сразу.
Но тут речь шла про выложенные на github файлы :) Конкретно — https://github.com/inponomarev/csa-hb/blob/master/src/main/asciidoc/csa.adoc
Я тоже к подобному пришел, писал статью об этом: Современный формат презентаций.
Только я использовал Markdown, а не AsciiDoctor. А почему вы используете его, первый же более распространенный?
К счастью, AsciiDoctor интегрирован с системой Graphviz
Вот это очень круто, мне такого не хватало.
Две хитрости при запуске decktape, к которым пришлось прийти методом проб и ошибок:
Да, к сожалению, с конвертингом исходников в другие форматы пока что есть проблемы.
Наверное потому, что AsciiDoctor более распространён у нас в компании в принципе.
Для написания слайдов, наверное, нет большой разницы между Markdown и AsciiDoctor. А для написания документации (задача, под которую к нам «зашёл» AsciiDoctor) — разница есть в пользу последнего, например, структурирование таблиц в AsciiDoctor гораздо более продвинуто.
Да, есть такой :) Пользуйтесь, обращайтесь если что. Можно даже репортить баги и дорабатывать. Вообще я о нем собирался статью на хабр написать, но пока что руки не дошли.
Я этот движок во всю использую при публикации, сами статьи хранятся тут: Articles.
В планах — доработать конвертацию статей на CI сервере, использовать другой движок парсинга. К сожалению, у хабра нет публичного API для публикаций и обновления статей, поэтому приходится просто их копипастить вручную. Однако можно попробовать подход из статьи Плагин к Sublime Text для публикации статей на Хабр хотя бы для плагинов к текстовым редакторам.
Вдруг они заиндексируются поисковиком, а потом при публикации на хабр оно заблокируется по «антиплагиату»? Ведь по правилам хабра, размещать тут репосты нельзя, а если статья уже в открытом гитхаб-репозитории лежит, то она как бы тем самым уже в веб запощена. Или нет такой проблемы? хотелось бы кстати от НЛО услышать мнение на сей счёт)
Да вроде как уже можно
А ничего, что статьи в гите лежат открытом в доступе до публикации?
И над этим вопросом я конечно же подумал :) Сейчас у меня есть два репозитория: приватный, для написания и вычитки редакторами, и публичный, для уже опубликованных статей и потенциальных правок со стороны читатей. Так как используется Git, то нет проблемы пушить и пулить в оба репозитория. С недавнего времени у GitHub появились бесплатные приватные репозитории, а так вообще им не ограничивается, можно использовать GitLab, Bitbucket и другие сервисы. А вообще на самом деле часто всем пофиг, поэтому можно сразу пушить в паблик репозитории какие-то вещи. Поисковики вряд ли индексируют определенные ветви.
А почему вы используете его, первый же более распространенный?
- Потому что Acsiidoc технически лучше
- Если бы большая распространённость была веским аргументом, в мире бы вообще не появлялось новых технологий, т.к. в начале своего зарождения они распространены на нуль.
Потому что Acsiidoc технически лучше
Можете расписать подробней почему технически лучше? У него больше возможностей?
Существенно больше:
Инклюды. Причём можно инклюдить не только аскидок-файлы, но и, например, файлы с кодом (и даже фрагменты из файлов с кодом).
Таблицы. Причём они смогли придумать удобный синтаксис, позволяющий описывать ячейки на раздельных строках.
Из коробки умеет производить html/pdf/epub/man и reveal.js-презентации, про который эта статья.
Более простое управление блоками. Например, попробуйте в маркдауне запихнуть блок текста внутрь элемента списка. В аскидоке для этого достаточно написать
+на пустой строке между элементом списка и блоком.
Контролируемый механизм расширений, в документе чётко размечено где какое расширение.
Макросы, способствующие принципу DRY.
Настраиваемое поведение в масштабах документа. Оглавление, нумерация глав/изображений/примеров кода. В маркдауне всего этого просто нет.
Поддержка глоссария и списка библиографии. Ну и вообще, аскидок нацелен на то что на выходе может быть книга, а не просто html-страничка.
Ну и офигенная документация всего этого добра: https://asciidoctor.org/docs/user-manual/
Ну и с учётом того что аскидок как и маркдаун из коробки поддерживается в github/gitlab, я вообще не знаю какие у маркдауна перед ним преимущества.
Наверно у вас не принят Sharepoint, поэтому вы не в курсе, но в современном Офисе collaborative редактирование очень даже удобно. Можно редактировать спредшит или слайды одновременно полсотней человекам, при этом сохраняется история версий с возможностью отката, можно видеть над каким слайдом/диапазоном работает любой коллега, есть встроенный чатик и проч…
Честно говоря не могу себе представить как язык разметки лучше чем диаграмма из pp в условиях близкого дедлайна. Выяснить во время компиляции что картинка swampboy.jpg переименована или находится на чьем-то локальном диске, или что в разметке диаграммы стрелочки не в ту сторону…
Выяснить во время компиляции что картинка swampboy.jpg переименована или находится на чьем-то локальном диске, или что в разметке диаграммы стрелочки не в ту сторону…
А разве рендер сразу вместе с исходником не доступен? Я думал выглядит это так: слева — исходник, справа — рендер. Во всяком в моем подходе, который выше уже упоминал, это именно так. Реализовано это как плагин к VSCode. Либо просто переключение между исходником и рендером с помощью кнопочки.
Я представил обычную ситуацию, когда в субботу вечером ваша команда налепила слайдов и довольная разошлась по домам, с вы просматриваете pdf перед тем как послать клиенту и находите на слайде . Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается...
По идее такая ситуация возможна в большинстве подобных систем (обратная сторона медали, куда же без неё).
Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается...
Если все хранится в Git репозитории, то доступ ко всем файлам внутри репозитория есть у всех. Поэтому либо вы не используете систему контроля версий, что не очень хорошо, либо кто-то неправильно ей воспользовался.
Так что там где разграничение прав доступа есть, ситуация возможна.
Но это явно не уникальная проблема описываемого тут подхода, не вижу причин почему с sharepoint и пр ситуация была бы иная (бесконтрольность vs проблема отсутствия доступа к неким материалам, если доступ забыли дать).
Всё-таки думается что описанная ситуация возможна, т.к. неправильно как-то если доступ есть у всех и ко всему — иначе, условно, клинеры придут и вместе с пылью код почистят) Или в прод пасхалок насуют.
Доступ есть ко всем файлам, но не ко всем веткам. Например, часто ветвь master является защищенной, т.е. коммитить туда может только ограниченный круг лиц, а то и вообще через merge request. Если "клинер" что-то там себе подчистит, то ревьювер сразу это заметит по изменениям в риквесте.
Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинаетсяв таком случае если в целом доступ к репозиторию есть то сделать себе копию и исправить до отправки клиенту можно; а потом отправить merge request, если нет «доступа к папочке» (в данном случае к записи в master).
Что касается последнего пункта — проблем с картинкой и стрелочкой — так тут инструмент можно сказать на коленке придуман и ещё не успел обрасти фичами полезными.
И тест на наличие картинки в нужной локации, и моментальный визуальный превью диаграмм — это же вообще не проблема.
Так же как в sharepoint нужные фичи допиливаются (у знакомых в относительно небольшой конторе целый отдел этим занят), так и тут при желании можно любую нужную обвязку вокруг накидать быстро.
Вплоть до того что условно через чат-бота в мессенджере писать/редактировать презентацию и диаграммы (!!!) :)
Спасибо, что не предложили собственное облако поднимать с закупкой серверов)
Процесс непрерывной интеграции, о котором в том числе говорится в статье в отношении презентации, более чем отлично может отрабатывать ситуации с недоступными ресурсами, а заодно и с многими другими возможными нарушениями качества, которые можно поймать автоматически: орфография, висячие предлоги в заголовках и т.п. Направление стрелочки, конечно, попутать можно, впрочем, как и Северную Корею с Южной.
Если говорить в целом об организации совместной работы, то система контроля версий и непрерывная интеграция — это другой порядок эффективности, чем Sharepoint. Проблема в том, что часто нужна функциональность Powerpoint’а. Ну и тот же git, да ещё и с Travis’ом, да ещё и с Maven’ом освоить значительно сложнее, чем Sharepoint.
В статье смешиваются AsciiDoc (язык разметки) и AsciiDoctor (конкретную реализацию инструментов для работы с AsciiDoc)
Кстати, а движок диаграмм mermaid не пробовали использовать? Можно ли его подчключить?
Вопрос: а мне одному там в примере «An example of a sequence diagram» не хватает стрелочек на визуализации? Конкретно в «John->Bob: How about you?» вообще не понять, откуда куда сигнал идёт. Что я упустил?..
Но, кажется PlantUML всё ещё мощнее, особенно учитывая stdlib.
Вань, спасибо за статью! А как выглядит презентация? Next slide есть?
Каких-то мультиэкранных фишечек (слайд-заметки, следующий слайд на другом экране), конечно, нет, ибо это всего лишь браузер или всего лишь Acrobat Reader.
Слайд-заметки, кстати, есть
Было бы очень интересно узнать подробности.
О, и preview тоже есть. https://asciidoctor.org/docs/asciidoctor-revealjs/#basic-presentation-with-speaker-notes
Спасибо за статью!
Кстати, Travis позволяет описывать деплой в конфиге, который он потом сам и разливает в нужный бранч на гитхабе. Пример.
Лично мне удобнее наш вариант из-за
- возможности простой вставки исходников с автоподсветкой синтаксиса,
- кодирования диаграмм GraphViz/PlantUML,
- единого для всей команды процесса работы с исходниками (GitHub/pull requests), с текстовыми диффами
- понятного дизайнерам и верстальщикам CSS
Ну и в принципе оно как-то спокойнее, что все исходники твоих документов — у тебя, а не неизвестно в каком формате в облаке.
Но, ещё раз повторюсь: всё зависит от задачи. Если у вас нет массовых слайдов с кодом, например, то гугл-докс — отличный выбор.
Генерация PDF как-то костыльно выглядит.
Доктор на Ruby, но для генерации PDF будьте любезны установить Node.js с браузером.
TeX в PDF более естественным путём превращается.
Кстати, decktape способен таким образом конвертировать не только RevealJS слайды, но вообще слайды из кучи других презентационных фреймворков.
И ещё, кстати, ставить браузер не надо. Пакет puppeteer тащит автоматом безголовый хром за собой. Ну и в принципе если это всё происходит на CI, то хлопот не так много.
А вообще, кто уже делает слайды в техе, те молодцы и им тут делать нечего, я считаю ))))
https://yhatt.github.io/marp/
https://gitpitch.com/
https://remarkjs.com/
Миллион их, почему именно AsciiDoctor?
С презентациями классно. А как на счёт верстки документов в css/html с наполнением через markdown, чтобы выглядело как отчёт или документация или например курсач?
Для презентаций еще есть интересный вариант в виде org-mode + reveal.js: пишем презентацию как обычную заметку в org-mode (добавляется лишь несколько кастомных тегов), а потом автоматически можем сконвертировать в красивую HTML5 презентацию.
Из плюшек reveal'а:
- Возможность создавать нелинейных презентаций. Т.е. слайды могут структурироваться в виде грида, когда двигаться можно влево/вправо/вверх/вниз, это бывает удобно, когда хочется добавить сопроводительного материала, для иллюстрации возможных вопросов, которым не хочется загромождать основную презентацию.
- Возможность создавать спикер ноуты к слайдам. Во врмея презентации на экране спикера можно выводить много всякой информации помимо самих ноутсов, например тайминги по всей презентации и по текущему слайду и тд и тп.
- Даже из коробки там вполне приличный стиль и можно особо не париться с оформлением презентации. Но если есть желание заморочиться, то вся мощь HTML5 поможет в этом.
Вообще в reveal можно конвертироваться не только из org-mode, но и из других форматов, типа markdown, но связка с org'ом позволяет за считанные минуты превратить свои заметки в презентацию, готовую к показу.
По сути, презентация PowerPoint — это ведь тоже plaintext. Вернее, это набор файлов xml, и картинок, просто запакованных в zip-архив переименованный в .pptx.
Я не проверял, но по логике можно хранить презентацию в распакованном виде на github и мержить изменения. Хотя для удобства придется отдельно написать скрипты автоматически собирающие/разбирающие .pptx.
Правда тут желательно придерживаться одной версии PowerPoint, иначе могут вноситься сногочисленные изменения в конфиг-файлах при каждом пересохранении. На результат они не повляют, но наглядность истории изменений пострадает… Хотя можно выводить только правки файлов «presentation.pptx\ppt\slides\slide[n].xml» — там все что относится к самим слайдам.
По сути, презентация PowerPoint — это ведь тоже plaintext. Вернее, это набор файлов xml, и картинок, просто запакованных в zip-архив переименованный в .pptx.
Все так, но в этих xml много избыточности и дифать их неудобно.
Я не проверял, но по логике можно хранить презентацию в распакованном виде на github и мержить изменения. Хотя для удобства придется отдельно написать скрипты автоматически собирающие/разбирающие .pptx.
Git можно настроить таким образом, чтобы он использовать разные diff утилиты для разных расширений, в частности, для pptx.
Сам давно на такое смотрю, страдая так же, от бесчисленных версий презентаций, кастомизированных и переведенных для заказчиков, где правки постоянно теряются.
Подход как код я бы назвал ортогональным — управляемость в ущерб дизайну. С другой стороны здесь хоть можно прикрутить постобработку дизайнерскую, но тогда мы опять получаем ситуацию, что часть работы живет в отрыве от версионирования.
Презентация как код, или Почему я больше не пользуюсь Powerpoint-ом