По поводу двуx роадмапов я руководствовался принципом "Информационная перегрузка"). Плюс я рассматривал этот вопрос в разрезе малой организации с той стороны, что первая часть роадмапы будет в меньшей степени подвергаться изменениям
Интересная идея с визуализацией роадмапы, в идеале вообще инфографику прикрутить. Я бы даже разделил на две роадмапы, по знакомству с компанией и процессами, а вторую для плана задач
Таблицы в любом случае будут зависеть друг от друга в той или иной степени. Не совсем понял, какие в вашем понимании отличия между "у тебя вообще граф получается" и "множество табличек"?
Очень хорошая аналогия с событиями и справочниками! Когда я проходил курс БД, нас грузили только признаками и как прийти к 3НФ. Самое интересное, что всегда требовали начинать с 1НФ, хотя если ты мыслишь объектами, то в 90% случаев ты уже построил 2НФ.
Хотелось достичь единообразия. Весь проект использует CMake. Плюс мы собираем не через MinGW, а через nmake и получается нужно было дублировать скрипт сборки. В целом вариант с shell скриптом хорош, а тут 100% единый интерфейс обращения будет.
По поводу двуx роадмапов я руководствовался принципом "Информационная перегрузка"). Плюс я рассматривал этот вопрос в разрезе малой организации с той стороны, что первая часть роадмапы будет в меньшей степени подвергаться изменениям
Интересная идея с визуализацией роадмапы, в идеале вообще инфографику прикрутить. Я бы даже разделил на две роадмапы, по знакомству с компанией и процессами, а вторую для плана задач
Таблицы в любом случае будут зависеть друг от друга в той или иной степени. Не совсем понял, какие в вашем понимании отличия между "у тебя вообще граф получается" и "множество табличек"?
Очень хорошая аналогия с событиями и справочниками! Когда я проходил курс БД, нас грузили только признаками и как прийти к 3НФ. Самое интересное, что всегда требовали начинать с 1НФ, хотя если ты мыслишь объектами, то в 90% случаев ты уже построил 2НФ.
За счёт вынесения пресетов в разные файлы и механизма наследования это становится приемлемым
Это сонька, она уже стоит между монитором и принтером
Монитор был куплен раньше, чем пришло озарение, поэтому так
Подразумевается, что читающий уже знаком с пресетами и это не гайд чтобы писать все от А до Я.
До этого они использовались, но одно дело когда тебе нужно запомнить 1 или 2 переменные, а когда их много как поступать?
Так механизм пресетов в CMake работает через JSON
Не совсем понял цели вопроса. Если вопрос в том, что скрипт сборки не умеет патчить, то это в целом и не нужно ему в моем сценарии использования
У нас кастомный - с белорусской криптографией
В целом CI на стадии зарождения. Уже перенес нативную сборку под windows на кросскомпиляцию. У нас как раз кастомный OpenSSL
Хотелось достичь единообразия. Весь проект использует CMake. Плюс мы собираем не через MinGW, а через nmake и получается нужно было дублировать скрипт сборки. В целом вариант с shell скриптом хорош, а тут 100% единый интерфейс обращения будет.