Size: a a a

DocOps-сообщество

2019 June 16

L

Lejbron in DocOps-сообщество
Angela
вот тоже такое же ощущение, интересно, он не чистит билд-папку перед сборкой чтоли
Не удаляет, смотрите makefile, при необходимости туда можно прописать удаление предыдущей сборки, но это целесообразно только в случае если она делается за адекватно-быстрое время)
источник
2019 June 17

A

Angela in DocOps-сообщество
Lejbron
Не удаляет, смотрите makefile, при необходимости туда можно прописать удаление предыдущей сборки, но это целесообразно только в случае если она делается за адекватно-быстрое время)
я в целом уже настроила, отправила все временно отключённые файлы в отдельную папку, прописала exclude_patterns и добавила эту папку в гит игнор
источник
2019 June 19

VS

Vadim Smelyanskiy in DocOps-сообщество
Узнал тут, что у Visual Paradigm есть API для плагинов на Java и задумался

У кого-нибудь есть опыт сращивания софта вида всё-в-одном с DocOps'ными практиками?
Скажем, дать аналитикам работать в привычном им окружении, которое многое позволяет быстро делать, а к нему уже цеплять все свои CI/CD для документации, линты и т.д.
источник

NV

Nick Volynkin in DocOps-сообщество
тут можно смотреть в сторону CMS, которые работают с плейнтекстом и гитом, например getgrav.org
источник

НН

Нац Нац in DocOps-сообщество
Егор Доронин
+100500. В клиентах есть ненужные абстракции, плюс всегда настроить клиент всегда сложнее, чем консоль.
Я вбил логин пароль и всё заработало 🤔
источник

НН

Нац Нац in DocOps-сообщество
(но я тоже за консоль, но я неосилятор)
источник

NV

Nick Volynkin in DocOps-сообщество
знаю истории, когда из исходников в гите собираются документы, а потом эти документы пушатся в Confluence или Google Docs
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Nick Volynkin
знаю истории, когда из исходников в гите собираются документы, а потом эти документы пушатся в Confluence или Google Docs
Вот мы сейчас так и делаем, но всё ещё немало точек боли

Особенно комментарии и правки от внешних людей надоедает обрабатывать
источник

НН

Нац Нац in DocOps-сообщество
Nick Volynkin
знаю истории, когда из исходников в гите собираются документы, а потом эти документы пушатся в Confluence или Google Docs
О я б такое настроил с ГДоками на досуге, есть линк под рукой?
источник

NV

Nick Volynkin in DocOps-сообщество
Нац Нац
О я б такое настроил с ГДоками на досуге, есть линк под рукой?
Кажется, об этом @kvaleev рассказывал вот тут https://events.yandex.ru/lib/talks/4970/
источник

НН

Нац Нац in DocOps-сообщество
О, а ведь я даже палил
источник

OI

Olga Ilchukova in DocOps-сообщество
Nick Volynkin
Кажется, об этом @kvaleev рассказывал вот тут https://events.yandex.ru/lib/talks/4970/
После этого видео я выкинула свой ворд на помойку
источник

A

Antonio in DocOps-сообщество
Vadim Smelyanskiy
Вот мы сейчас так и делаем, но всё ещё немало точек боли

Особенно комментарии и правки от внешних людей надоедает обрабатывать
Ооо, а как собираете комментарии и правки? Edit this page?
источник

A

Antonio in DocOps-сообщество
@Nick_Volynkin @LittleSunnyboy по хорошему, если смотреть правде в глаза, то и markdown ни хрена не панацея от всех болезней.
У него есть разрушительные преимущества перед тем же Word и прочими текстовыми процессорами где ты больше занимаешься форматированием, чем писанием. Такой переход принесет много облегчения и радости от простоты его использования, ввиду незамысловатого синтаксиса.
Но, чем дольше и разнообразнее ты используешь markdown,  тем четче ты понимаешь, насколько он конченный, ограниченный и вообще, годится только для сраных ридми в гитхабе.
Для более-менее серьезного технического писательства он не подходит. От слова вообще
источник

НН

Нац Нац in DocOps-сообщество
А чего такого специфического он не умеет? Для примера возьмем markdeep.
источник

НН

Нац Нац in DocOps-сообщество
Да, есть проблемы, но не до уровня >Для более-менее серьезного технического писательства он не подходит. От слова вообще
источник

A

Antonio in DocOps-сообщество
Нац Нац
А чего такого специфического он не умеет? Для примера возьмем markdeep.
это уже первый минус маркдауна. У него нет одной спецификации и есть куча flavors, которые по сути не совместимы друн с другом
источник

НН

Нац Нац in DocOps-сообщество
а зачем им быть совместимыми друг с другом, если юзер или дев её смотрит. я не считаю это минусом
источник

НН

Нац Нац in DocOps-сообщество
Если дока настолько мудрёная, что на нее нехватает определенного Md — проблема не в инструменте, а в доке
источник

A

Antonio in DocOps-сообщество
Markdeep - один из flavor, есть github markdown, gitlab, kramdown и прочие
источник