оно же опенсорс и на пхп, можно допилить наверное

На сайте написано, что данные оно в MySQL хранит

Отказываться от СУБД будет больно, хоть на файловую систему, хоть in-memory repository

чёйто?

Если там MySQL не чисто для того, чтоб туда blob'ы запихать, а какая-то нормализованная инфа + SELECT'ы/JOIN'ы хитрые для каких-то фич, любая стратегия для переезда на git будет адской болью

Хоть только хранение файлов – тогда нужно будет хуки/git-сервер вшивать в сам bookstack, чтобы целостность БД поддерживать с хранилищем

Хоть всё туда перевозить – тогда все метаданные нужно будет хз как размапить и написать обёртку для работы над этим всем, которая по сути будет сужением SQL

Короче, допилить-то можно, но я б за это в свободное время не брался)

Недельки 3-4 надо, запроектировать, закодить, покрыть тестами

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

всё так, но хранение в гите имеет стратегические преимущества.

#aboutme
Привет сообществу!
Роман, ИТ-архитектор. В настоящий момент озабочен задачей систематизации и автоматизации ведения проектной документации, документирования технологической (и не только) архитектуры предприятия. Особенно в части коллективной работы, контроля и приемки изменений.

Коллеги, знаете ли вы инструменты построения BPMN диаграмм процессов из текстового представления, по примеру PlantUML?

Привет, Роман!

Ну и наконец-то многострадальная статья про рисование графиков в документации буквами. Ловите!

http://telegra.ph/Uchimsya-risovat-grafiki-v-dokumentacii-bez-dizajnera-i-talanta-07-12

Может кто посоветует, для питоновских либ мы использует sphinhx для автогенерации документации как "в свободном стиле", так и докстрингов из кода, но у нас есть еще фронтендная часть на Angular, какую экосистему выбрать там, комментарии сейчас пишутся в перемешку на ng docs и jsdocs. Не знаю, как подступиться к джсной части

documentation.js может помочь. пример использования тут: https://github.com/wemake-services/wemake-vue-template

Может кто-то знает, как определить, должа ли быть точка в тексте ошибки?

Поясню: в американской традиции точки ставятся таким образом:
blabla “bla.”
То есть точка, относящаяся к концу предложения, ставится внутрь кавычек. Если и закавыченное заканчивается точкой, и предложение целиком, то точка ставится одна, внутри кавычек.

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

Как определять, что имеется в виду, не уточняя каждый раз у заказчика?

Спасибо, интересно.

По рисовалкам BPMN похоже все глухо, придется дожидаться когда PlantUML доделает поддержку BPMN. а пока перебиваться на основе UML Activity diagrams.

вы пробовали draw.io?

Да, я смотрел на него - не подходит по требованиям.
Мне не нужен не WYSISWYG редактор, а генератор диаграммы из human readable текстового формата.
То есть что-то в стиле PlantUML, только для BPMN.

Трансляция и запись митапа будет!

Подклчайтесь: https://www.youtube.com/watch?v=UMEDdvUNRAQ

Начнём в 19:00 по Москве.

ура!