Специалистом по CAD не являюсь, но вроде файлы .sch хранятся в xml. А это уже открытый формат, независимый от приложения. Аналогично с .xlsx – это набор xml в zip архиве. Работать с исходником в данном случае можно, но неудобно, но и в Markdown не всё идеально.
Смотря о каком маркдауне речь. Основа – это CommonMark. Всё остальное – вариации. В CommonMark не так много элементов и даже нет таблиц, про которые вы говорите :) Пруф: https://commonmark.org/help/
Грамакс нативно поддерживает GitHub Flavored Markdown. Можно писать только на GFM через визуальный редактор. Но эта вариация также весьма ограничена и если нужно больше, то можно использовать вариацию маркдауна от Грамакс или Яндекс.
Тоже as code в виде mermaid диаграмм) Была интеграция со structurizr. Но мы пока убрали её из интерфейса, т.к. для него сервер нужен и ещё какие-то проблемы были. В будущем можем добавить.
Из комментариев к коду или readme не собрать пользовательскую документацию, как мне кажется. И там, обычно, нет описания зачем мы что-то разрабатываем, какие есть бизнес-ограничения, почему они есть и много чего еще.
Docs as code — это прежде всего про процессы и инструменты, а не про то, откуда берётся текст. Пруф: https://www.writethedocs.org/guide/docs-as-code/ Автогенерация документации из кода – это отдельное независимое направление.
По Markdown в гите можно diff смотреть и ревьюить через MR/PR. А docx — бинарник, с ним ничего не сделаешь, кроме как открыть и вручную сравнивать с docx из другой ветки.
Да, уже поддерживаем Bitbucket, Gitea, Gogs, GitVerse, GitFlic. Как подключить. GitLab self hosted в open source выложен, можно спокойно использовать. Плюс недавно запартнёрились с GitVerse, хорошая и приятная команда у них.
Obsidian с нативной интеграцией с git, с комментариями и мерж реквестами :) Сейчас фокус больше на создание публичной документации для продуктов (обычно делается через SSG, GitBook), но можно и вести собственную вики корпоративную. Доступы можно через GitLab/GitHub регулировать в open source версии или через наш UI в платной.
Понравилась статья, спасибо! Пробовали ли размещаться в awesome lists на GitHub? И размещение на индийских ютуб-каналах было платным?
Мы только сейчас начали заниматься вопросом звёзд на GitHub. Но их уже пассивно набралось 84. Звёзд 10 набрали просто после того, как привели readme.md в порядок на английском и нас начали находить в поиске. Сейчас хотим пробовать awesome lists и работу с блогерами рус/англ.
По нему diff не посмотреть в git. В этом смысл
Специалистом по CAD не являюсь, но вроде файлы .sch хранятся в xml. А это уже открытый формат, независимый от приложения. Аналогично с .xlsx – это набор xml в zip архиве. Работать с исходником в данном случае можно, но неудобно, но и в Markdown не всё идеально.
На следующей неделе добавим шаблоны для docx. Через 1-2 месяца шаблоны для PDF.
Грамакс по таким же причинам появился :) Но потом пришли бизнес-пользователи и попросили интерфейс, интеграции и много чего ещё :)
Смотря о каком маркдауне речь. Основа – это CommonMark. Всё остальное – вариации. В CommonMark не так много элементов и даже нет таблиц, про которые вы говорите :) Пруф: https://commonmark.org/help/
Грамакс нативно поддерживает GitHub Flavored Markdown. Можно писать только на GFM через визуальный редактор.
Но эта вариация также весьма ограничена и если нужно больше, то можно использовать вариацию маркдауна от Грамакс или Яндекс.
Тоже as code в виде mermaid диаграмм)
Была интеграция со structurizr. Но мы пока убрали её из интерфейса, т.к. для него сервер нужен и ещё какие-то проблемы были. В будущем можем добавить.
Из комментариев к коду или readme не собрать пользовательскую документацию, как мне кажется. И там, обычно, нет описания зачем мы что-то разрабатываем, какие есть бизнес-ограничения, почему они есть и много чего еще.
Docs as code — это прежде всего про процессы и инструменты, а не про то, откуда берётся текст. Пруф: https://www.writethedocs.org/guide/docs-as-code/
Автогенерация документации из кода – это отдельное независимое направление.
По Markdown в гите можно diff смотреть и ревьюить через MR/PR. А docx — бинарник, с ним ничего не сделаешь, кроме как открыть и вручную сравнивать с docx из другой ветки.
В виде картинки, т.к. хранится в svg. Думали насчёт xml, но тогда нужно будет делать серверный рендеринг, пока решили отложить на потом.
Записал видео для демонстрации, сначала mermaid, потом draw.io.
https://rutube.ru/video/16f45bd2d0cf9354c6219b254065f536/
Да, уже поддерживаем Bitbucket, Gitea, Gogs, GitVerse, GitFlic. Как подключить.
GitLab self hosted в open source выложен, можно спокойно использовать.
Плюс недавно запартнёрились с GitVerse, хорошая и приятная команда у них.
Спасибо!)
Obsidian с нативной интеграцией с git, с комментариями и мерж реквестами :)
Сейчас фокус больше на создание публичной документации для продуктов (обычно делается через SSG, GitBook), но можно и вести собственную вики корпоративную. Доступы можно через GitLab/GitHub регулировать в open source версии или через наш UI в платной.
Понравилась статья, спасибо!
Пробовали ли размещаться в awesome lists на GitHub?
И размещение на индийских ютуб-каналах было платным?
Мы только сейчас начали заниматься вопросом звёзд на GitHub. Но их уже пассивно набралось 84. Звёзд 10 набрали просто после того, как привели readme.md в порядок на английском и нас начали находить в поиске. Сейчас хотим пробовать awesome lists и работу с блогерами рус/англ.