Здравствуйте, IT, Вы писали:

IT>Здрасти. Велосипеды — это наше всё! Лучше своя хорошо контролируемая самоделка, которую в любой момент можно переделать в любую сторону, чем рукожопный кусок непонятно чего с гитхаба. На то, что у меня уходит до недели работы, я предпачитаю велосипедить сам. Потом меньше проблем.

У меня опыт прямо обратный. Почти всегда велосипеды — не едут.

IT>Что касается РСУБД, то это вопрос философский. Когда это только делалось я сам вопрошал коллег а нужна ли здесь СУБД? Как часто мы меняем настройки между релизами? Решили, что пусть будет. А вдруг. Хотя за всё время эксплуатации системы не припомню, чтобы это делалось. Хотя я не уверен.

Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.

IT>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?

Предлагаю в данном случае code first.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>У меня опыт прямо обратный. Почти всегда велосипеды — не едут.

Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.

НС>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.

Консул это тут? Если да, то оно вообще для чего? Там про какой-то порт Go для HTTP API. Ты предлагаешь мне ради пары побочных функций тащить это всё в свой проект?

IT>>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?
НС>Предлагаю в данном случае code first.

Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода. А так согласен, если бы БД была не нужны, то можно было бы сделать простенький репозиторий настроечных параметров.

Здравствуйте, IT, Вы писали:

НС>>У меня опыт прямо обратный. Почти всегда велосипеды — не едут.
IT>Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.

Если следовать этой логике — надо начинать со своей ОС или сразу процессор свой проектировать?

НС>>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.

IT>Консул это тут?

Нет. Это https://www.consul.io/

IT>>>Про json не понял. Ты предлагаешь не генерировать класс, а каждый раз парсить json или наоборот?
НС>>Предлагаю в данном случае code first.
IT>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.

Почему он, а не дотнетный класс? Ну а генерация скриптов это следствие выбора РСУБД для хранения конфигов, а не исходное требование.

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких API, причуд разработчиков и т.п.
НС>Если следовать этой логике — надо начинать со своей ОС или сразу процессор свой проектировать?

Не надо передёргивать. Логику я обозначил выше. Если затраты на велосипед не более нескольких дней, то можно себе позволить.

НС>>>Тем не менее есть готовые решения, например Consul, в которых много pain points заранее предусмотрено.

IT>>Консул это тут?
НС>Нет. Это https://www.consul.io/

Таже фигня, если не хуже. Ради мелкой задачки тянут в проект неизвестную науке пое...хрень.

IT>>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.
НС>Почему он, а не дотнетный класс?

Потому что json парсить проще, чем дотнетный класс.

НС>Ну а генерация скриптов это следствие выбора РСУБД для хранения конфигов, а не исходное требование.

Об этом я уже сказал.

Здравствуйте, IT, Вы писали:


IT>>>Консул это тут?
НС>>Нет. Это https://www.consul.io/
IT>Таже фигня, если не хуже. Ради мелкой задачки тянут в проект неизвестную науке пое...хрень.

Ну это еще большой вопрос насколько она мелкая. Потому что когда в проект приходит пачка деплойментов, всякие SOC-сертификации и прочая — все становится намного веселее и велосипеды начинают припадать на оба колеса.

IT>>>Тут вопрос деплоймента. БД у нас деплоится отдельно. json в данном случае выступаетв в качестве golden source для генерации как SQL, так и кода.
НС>>Почему он, а не дотнетный класс?
IT>Потому что json парсить проще, чем дотнетный класс.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Таже фигня, если не хуже. Ради мелкой задачки тянут в проект неизвестную науке пое...хрень.
НС>Ну это еще большой вопрос насколько она мелкая. Потому что когда в проект приходит пачка деплойментов, всякие SOC-сертификации и прочая — все становится намного веселее и велосипеды начинают припадать на оба колеса.

А если не приходит? Или если не приходит, то надо сделать так, чтобы пришли, иначе это уже неправильная система?

IT>>Потому что json парсить проще, чем дотнетный класс.
НС>А зачем парсить дотнетный класс, если можно воспользоваться уже отпарсеным компилятором в сборке?

Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет. Или знаешь? Хотя это уже гордынькой попахивает

Здравствуйте, IT, Вы писали:

IT>А если не приходит?

Значит повезло.

IT>>>Потому что json парсить проще, чем дотнетный класс.
НС>>А зачем парсить дотнетный класс, если можно воспользоваться уже отпарсеным компилятором в сборке?
IT>Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет.

Здесь вроде топик не про твою персональную систему, не?

Здравствуйте, Ночной Смотрящий, Вы писали:

IT>>Я могу и уже согласился с тем, что в случае отсутствия БД можно всё сделать в виде класса. Но не могу согласиться с тем, что ты лучше меня знаешь нужна мне в моей системе БД или нет.
НС>Здесь вроде топик не про твою персональную систему, не?

С тех пор как я привёл код — про мою.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Kolesiki, Вы писали:

K>>Потому что конфиг — это вообще не про код. Код должен быть в программе, а в конфиге — лишь "настроечные величины". Если ты налепил конфиг в виде кода, ты явно решил задачу левым путём. Времена ЛИСПа прошли и не потому, что ЛИСП устарел — он просто непригоден для надёжного ПО — как раз в силу идеи "данные как код".

Pzz>...[оффтопишная бредятина поскипана]
Pzz>4. Если конфигурация должна описывать некие действия (например, куда почтовый сервер должен отправить письмо, в зависимости от его параметров), то описание ее в виде инперативной "программы" может быть значительно удобнее, чем в виде декларативного набора правил.

Ещё один любитель получать граблями! Поясняю как в школе:

Если логика выбора сервера сложная, делается плагин (о чём я уже упомянул).
Если логика покрывается простыми регэкспами над хэдер-полями (что на 99% верно), то и в конфиге просто прописываем нужные RE!

Здравствуйте, Kolesiki, Вы писали:

K>Если логика выбора сервера сложная, делается плагин (о чём я уже упомянул).
K>Если логика покрывается простыми регэкспами над хэдер-полями (что на 99% верно), то и в конфиге просто прописываем нужные RE!

Угу. В sendmail'е так и сделано
Впрочем, ты не знаешь, что такое sendmail...

Здравствуйте, Kolesiki, Вы писали:
K>Ну так ты вообще про другое — ПРО ПЛАГИНЫ! К каждому из которых, прикинь, можно тоже поставлять конфиг простейших величин.
Я, наверное, плохо объяснил. Плагины — плагинами. Но "простейшие величины" быстро превращаются в сложную кашу типа "получи данные от плагина №4512, результат запиши в плагин №2145".
На первый взгляд мы всё ещё работаем с "простым плоским конфигом", но вот только резко растут шансы сделать ошибку — типа сослаться на несуществующй номер плагина, или получить кольцевую зависимость.

Я N+1 раз встречал на практике системы, в которых "конфиг" — это половина логики решения.
В итоге получается так, что программисты реализуют и выкатывают фичу за месяц, а эксплуатация её конфигурит на проде два месяца.
Потому, что у программистов есть средства проверки корректности их кода — от подсветки в редакторе, выхлопа компилятора, и до верификаторов и юнит-тестов, которые прогоняются автоматом.
А у эксплуатации всё, что есть — это какая-то каша из "простейших величин", с бесконечным количеством способов сделать в них незначительную ошибку, которую обнаружить можно будет только по тикетам в саппорт.

S>>Начиная от "запросы по адресам '/users/*'...

K>Местечковая галиматья. НЕТ у конфигов задачи "запросы по адресам". Это твоя бизнес-задача, решённая через одно неприличное место.
Правда что ли? Авторы nginx, iss, и apache с вами не согласны.
K>Ещё раз вернись в место, где про "простейшие величины" — вот конфиг — это оно. При всех порочных практиках, самое ужасное, что ты можешь сделать — позволить чему-то внешнему исполняться на хосте.

То есть, вы полагаете, что конфиги с "простейщими величинами" можно давать править кому угодно, а вот код — уже нет?
Я вот не вижу принципиальной разницы. Ну, то есть понятно, что будучи суперосторожным, можно так ограничить конфиг, чтобы злоумышленник не смог при помощи него сделать ничего опасного.
Но таких случаев — исчезающе мало. Даже выбор "на каком порту слушать" уже позволяет нам в определённых обстоятельствах организовать атаку.
Поэтому самое ужасное, что вы можете сделать при всех порочных практиках — это давать доступ до конфигурации тем, кому нельзя доверять.
А если у вас (как и у всех минимально вменяемых людей) доступ к конфигурации ограничен, то нет никакой разницы, класть туда "данные" или "код".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Kolesiki, Вы писали:
K>>Ну так ты вообще про другое — ПРО ПЛАГИНЫ! К каждому из которых, прикинь, можно тоже поставлять конфиг простейших величин.
S>Я, наверное, плохо объяснил. Плагины — плагинами. Но "простейшие величины" быстро превращаются в сложную кашу типа "получи данные от плагина №4512, результат запиши в плагин №2145".
S>На первый взгляд мы всё ещё работаем с "простым плоским конфигом", но вот только резко растут шансы сделать ошибку — типа сослаться на несуществующй номер плагина, или получить кольцевую зависимость.

Это уже не конфиг, а обмен данными какой-то.

S>Я N+1 раз встречал на практике системы, в которых "конфиг" — это половина логики решения.
S>В итоге получается так, что программисты реализуют и выкатывают фичу за месяц, а эксплуатация её конфигурит на проде два месяца.
S>Потому, что у программистов есть средства проверки корректности их кода — от подсветки в редакторе, выхлопа компилятора, и до верификаторов и юнит-тестов, которые прогоняются автоматом.
S>А у эксплуатации всё, что есть — это какая-то каша из "простейших величин", с бесконечным количеством способов сделать в них незначительную ошибку, которую обнаружить можно будет только по тикетам в саппорт.

Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?

S>>>Начиная от "запросы по адресам '/users/*'...

K>>Местечковая галиматья. НЕТ у конфигов задачи "запросы по адресам". Это твоя бизнес-задача, решённая через одно неприличное место.
S>Правда что ли? Авторы nginx, iss, и apache с вами не согласны.
K>>Ещё раз вернись в место, где про "простейшие величины" — вот конфиг — это оно. При всех порочных практиках, самое ужасное, что ты можешь сделать — позволить чему-то внешнему исполняться на хосте.

S> То есть, вы полагаете, что конфиги с "простейщими величинами" можно давать править кому угодно, а вот код — уже нет?

Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.

S>Я вот не вижу принципиальной разницы. Ну, то есть понятно, что будучи суперосторожным, можно так ограничить конфиг, чтобы злоумышленник не смог при помощи него сделать ничего опасного.
S>Но таких случаев — исчезающе мало. Даже выбор "на каком порту слушать" уже позволяет нам в определённых обстоятельствах организовать атаку.
S>Поэтому самое ужасное, что вы можете сделать при всех порочных практиках — это давать доступ до конфигурации тем, кому нельзя доверять.
S>А если у вас (как и у всех минимально вменяемых людей) доступ к конфигурации ограничен, то нет никакой разницы, класть туда "данные" или "код".

Так вы о каких-то разных конфигах говорите.
Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.
Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.
Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.

Здравствуйте, karbofos42, Вы писали:
K>Это уже не конфиг, а обмен данными какой-то.
Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

K>Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?
Что вы имеете в виду?

S>>>>Начиная от "запросы по адресам '/users/*'...
K>Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
K>Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
K>Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.
Ну, мы же говорим не про C/C++, где код может резвиться как ему угодно. Мы говорим об управляемой среде, в которой код не может получить доступ к тому, к чему ему доступа не дали.
Если он сделает что-то совсем неправильное, то ПО упадёт при запуске и работать не будет.
Самый патологический случай — это бесконечный цикл в коде "вычисления параметра конфига". Такие вещи статическим компилятором не отловишь.
Если такие проблемы представляют реальную угрозу, то инициализация конфига выносится в отдельный поток с таймаутом, при превышении которого приложение вырубается с соответствующей записью в логе.

K>Так вы о каких-то разных конфигах говорите.
K>Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
K>Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
Как это "кто хочет"? Ставить приложение — привилегия админа. Если у пользователя есть привилегия ставить приложение, то его никакое разделение кода и данных не спасёт.
K>Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.
K>Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.
Скрипт развёртывания — это скрипт развёртывания. Он выполняется один раз при развёртывании.
А конфиг — это конфиг; он читается при старте приложения и, по хорошему, каждый раз при его изменении.
Более-менее любое Line of business приложение состоит из "конфигов" чуть менее, чем полностью. Какой-нибудь Power BI, или 1С — там же всё как раз в "конфигурации".
Вот, расскажите мне, как свести конфигурацию 1C к небольшому набору параметров.

K>Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.
Как раз на винде масса всяческих конфигов в виде ini-файлов или xml (или того же реестра), которые очень сильно влияют на логику приложения.
И в общем случае нет никакого способа проверить корректность этих конфигов. Отсюда стандартный способ починки того, что отвалилось — просто переставляем приложение; если не помогло — переставляем винду.

Здравствуйте, MadHuman, Вы писали:

MH>Доброго всем!
MH>Коллеги, поделитесь опытом к каким практикам для организации работы с настройками в приложениях/сервисах пришли и почему..

MH>В частности интересны следующие моменты (и для затравки, привожу свой опыт)
MH>в каком формате хранить?
MH>В ini файлах — легко читать/править. большинство практических потребностей покрывает.
MH>xml/json — сложнее править, больше шансов ошибиться при ручной правке. основное преимущество — возможность большей вложенности (иерархичность) настроек,
MH>но на практике не особо ощущается т.к. в том же ini-файле вложенность вполне ок можно эмулировать за счет имен секций [system.limits]

MH>более интересный вопрос — как в приложении организована работа (чтение/хот релоад)?

Единый класс COptions, с открытыми member-переменными настроек (всякие bool, long\num, strings)

умеет писать себя и в реестр, и в ini-файл. Это спрятано внутри класс COptions. Сделано через выбор интерфейсов IWriteSettings, IReadSettings на лету. Выбор куда писать: реестр или ини-файл определяется пользователем.

Из плюсов:
1) Если реестр — то настройки единые для всех копий софтины на диске. Если ини — тогда у каждой копии софтины (разные версии например) у каждой свои копии настроек.
2) Второй плюс: экспорт настроек действием пользователя суть та же запись в ini-файл через тот же самый интерфейс IWriteSettings. Разве что имя ини-файла выбирается пользователем стандартным диалогом выбора файла.
3) Легкость создания портабельных настроек. Для портабельной версии используется запись\чтение настроек именно в\из ини-файла.

Для каких-то малоиспользуемых настроек (к примеру, какая-то третьеразрядная галка, в каком-то вспомогательном диалоге, в самом дальнем уголке проекта) этот класс COptions предоставляет парочку статических функций Write_Value(bool|string|num) и соответственно Read_Value(…). Но за уникальный ключ (для реестра\ини-файла) отвечает внешний код. Какое-то маловменяемое имя (ключ) для таких настроек придумать несложно. Благо это всё равно используется для малозначимых, каких-то там третьеразрядных настроек.

Чтение в стиле hot. При первом же обращении к такому классу COptions, он сам выполняет чтение (из того же реестра\ини-файла).

Все переменные в COptions — открытые, дабы без конца не мутить геттеры\сеттеры.

Как только появляется более "хитропопая" логика использования какой-либо переменной, она переносится в private. И приписывается геттер\сеттер. Проект, конечно, приходится крепко пересобрать. Но компилятор сам всё отловит. Останется только пробежаться по таким ошибочным строчкам, и тупо через копи-паст заменить прямое обращение к переменной на вызовы геттеров\сеттеров.

Пример: выручает когда чешутся ручки удалить какую-то настройку, потому как, никто ей как настройкой и не пользуется. Но "терзают смутные сомнения" ©, а пользователям оно как будет? Может кто-то всё-таки использует эту "мнительную" настройку.

В таком случае переменная этой настройки в COptions закрывается в private, дописываются геттеры-сеттеры, и всё пересобирается. Но! Есть нюанс. Сами геттеры\сеттеры просто ни хрена не делают. Геттер всегда возвращает одну и ту же константу, сеттер — это просто пустышка.
Что это дает: для внешнего кода всё как было, так и осталось читает\меняет настройку через геттеры\сеттеры. Логика как была, так и осталось. Но де факто то, на самом деле никакой настройки больше нет.

Со временем, если всё тихо, и пользователям "такой поворот с рекой" прошел нормально, эти пустышки геттеры\сеттеры удаляются.

А вот если начинается кипешь пользователей на тему "верни настройку, я все прощу", тогда просто правим пару строк в геттерах\сеттерах — возвращая логику настройки по сути. И опять просто пересобираем код, и всё готово.

Ну, как-то так что ли…

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, karbofos42, Вы писали:
K>>Это уже не конфиг, а обмен данными какой-то.
S>Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
S>Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

Ни разу не попадалось в конфигах что-то сильно замороченное.
Имя файлов лога, продолжительность хранения, уровень логгирования,..
Чтобы там поменять две строчки местами и всё сломалось — не попадалось.

K>>Разве это не показатель, что конфиг должен быть только конфигом, а не нести в себе какую-то логику?
S>Что вы имеете в виду?

Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.

S>>>>>Начиная от "запросы по адресам '/users/*'...
K>>Так простейшие величины — по сути просто значения переменных, которые потом пойдут на вход каких-то методов, а в методах вероятно будет валидация входных параметров.
K>>Ну, неправильное значение размера буфера человек указал или адрес сервера не тот, значит ПО упадёт при запуске и работать не будет, либо вместо некорректных значений будет использовать дефолтные.
K>>Неправильный код сложнее изолировать и потом окажется, что ошибка в конфиге разносит БД или ещё что-то важное ломает/удаляет.
S>Ну, мы же говорим не про C/C++, где код может резвиться как ему угодно. Мы говорим об управляемой среде, в которой код не может получить доступ к тому, к чему ему доступа не дали.
S>Если он сделает что-то совсем неправильное, то ПО упадёт при запуске и работать не будет.
S>Самый патологический случай — это бесконечный цикл в коде "вычисления параметра конфига". Такие вещи статическим компилятором не отловишь.
S>Если такие проблемы представляют реальную угрозу, то инициализация конфига выносится в отдельный поток с таймаутом, при превышении которого приложение вырубается с соответствующей записью в логе.

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

K>>Так вы о каких-то разных конфигах говорите.
K>>Одно дело — серверная часть, для которой и настройка может быть сложнее и доступ ограничен.
K>>Другое дело — какой-нибудь Notepad++, который ставит кто хочет и его конфиги правит кто хочет.
S>Как это "кто хочет"? Ставить приложение — привилегия админа. Если у пользователя есть привилегия ставить приложение, то его никакое разделение кода и данных не спасёт.
K>>Делаем конфиг такого приложения просто куском кода, который потом исполняется и завтра у нас будет толпа вирусов, которые просто дописывают нужный код в текстовый файлик, никто на это не обращает внимания, а пользователь потом ещё и сам админские права даст на выполнение, т.к. он же программе доверяет и никто её не менял.

Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.

K>>Не уверен, что некий скрипт развёртывания сервера правильно называть конфигом.
S>Скрипт развёртывания — это скрипт развёртывания. Он выполняется один раз при развёртывании.
S>А конфиг — это конфиг; он читается при старте приложения и, по хорошему, каждый раз при его изменении.
S>Более-менее любое Line of business приложение состоит из "конфигов" чуть менее, чем полностью. Какой-нибудь Power BI, или 1С — там же всё как раз в "конфигурации".
S>Вот, расскажите мне, как свести конфигурацию 1C к небольшому набору параметров.

Конфигурация в 1С — это отдельная песня.
Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.
А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.

K>>Может просто дело в том, что вырос на винде и привык к конфигам в виде ini-файла или xml какого, в которые никакую логику не засунуть.
S>Как раз на винде масса всяческих конфигов в виде ini-файлов или xml (или того же реестра), которые очень сильно влияют на логику приложения.
S>И в общем случае нет никакого способа проверить корректность этих конфигов. Отсюда стандартный способ починки того, что отвалилось — просто переставляем приложение; если не помогло — переставляем винду.

эти конфиги достаточно просты и их легко сейчас заменяет сериализация DTO в json

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, karbofos42, Вы писали:
K>>>Это уже не конфиг, а обмен данными какой-то.
S>>Обмен данными — это то, что происходит в рантайме. А конфиг задаёт то, кто с кем общается.
S>>Вы можете это наблюдать в любом app.config в виде секций, к примеру, управления логгированием.

K>Ни разу не попадалось в конфигах что-то сильно замороченное.
K>Имя файлов лога, продолжительность хранения, уровень логгирования,..
K>Чтобы там поменять две строчки местами и всё сломалось — не попадалось.
Правда что ли?

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
    </configSections>
    <log4net>
        <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender" > <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
            <layout type="log4net.Layout.PatternLayout"> <-- опечатка в имени типа, или неподключенная сборка - ловим в рантайме.
                <conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
            </layout>
        </appender>
        <root>
            <level value="INFO" />
            <appender-ref ref="ConsoleAppender" /> <-- ссылка на аппендер, определённый в другой части конфигурации. Ошибка в ссылке - ловим в рантайме.
        </root>
    </log4net>
</configuration>

Когда мы это размажем по иерархии веб-конфигов, всё станет ещё веселее.
K>Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.
У нас с вами разные понятия об удобстве инструментов для настройки ПО. Вот в примере выше в качестве языка управления конфигурацией мы породили некоторый DSL, для которого нет инструментов ни автодополнения, ни рефакторинга. Это нам ещё повезло — язык остался текстовым (а не представлен, скажем, в виде каких-то данных в РСУБД), поэтому мы хотя бы можем делать diff и blame.
Даже в таком простом примере видно, что "простые значения" в конфиге должны быть согласованы между собой; но никаких средств проверки этого (кроме запуска приложения и тестирования сценариев) у нас нет.

K>Этот код выполнится в том же процессе и в том же домене. Запустил человек доверенную программу под админом, а там какой-то левый код побежал по файлам шуршать.
Ещё проще — человек запустил доверенное приложение под админом, а в нём — левый код.
Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.
В том смысле, что для настольных он более важен.
В целом, я думаю, что вы правы в том, что выполнять произвольный императивный код в конфиге — не лучшая идея.
Но я всё ещё считаю, что это должен быть код на каком-то языке с нормальным тулчейном, а не просто плоский ini, или простынки json/XML.

K>Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.
Ещё раз: в такой фирме или дома, компьютер уже представляет из себя большую дыру. Люди гоняют скачанные из интернета екзешники под локальным админом и в ус не дуют.

K>Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.
K>А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.
Да, я предлагаю конфигурацию 1С считать конфигурацией. Ну, потому что это конфигурация.

K>эти конфиги достаточно просты и их легко сейчас заменяет сериализация DTO в json
А почему не хранить сам этот DTO в формате object initializer?
В отличие от json, этот код можно рефакторить, а написание оборудовано автодополнением.

Здравствуйте, Sinclair, Вы писали:

S> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> <-- опечатка в имени типа, или неподключенная сборка — ловим в рантайме.

А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?
Хороший вопрос. Разберусь — отвечу.

Здравствуйте, Sinclair, Вы писали:

НС>>А как надо? Захерачить в код, а как потом в кубере эту настройку поменять пусть у девопсов голова болит?
S>Хороший вопрос. Разберусь — отвечу.



Вот о чем я и говорю. Основная проблема велосипедов — шаг в сторону и мы вынуждены продолжать велосипедить. В то время как если бы мы взяли хотя бы штатный конфиг кора, то автоматом получили бы возможность поменять имя провайдера просто выставив переменную среды log4net_appender_type. А если бы мы еще и консул взяли, то получили бы еще и готовые инструкции всякие для админов/девопсов/безопасников, которые для велосипеда в случае какой нибудь SOC сертификации пришлось бы писать самому.

Здравствуйте, Sinclair, Вы писали:

S>Когда мы это размажем по иерархии веб-конфигов, всё станет ещё веселее.

В итоге этого можно относительно избежать, если конфиг делать в виде библиотеки, чтобы пользователь открывал IDE Собирал проект с зависимостями от неких публичных API приложения и тогда у него будет всё относительно доступно. Только конфиги почему-то обычно в блокнотике правят совсем не программисты.

K>>Что лучше бы программисты десяток типовых сборок сделало или реализовать удобный инструмент для настройки ПО, чем заставлять людей месяцами ковыряться в километровых конфигах неизвестно на каком языке.
S>У нас с вами разные понятия об удобстве инструментов для настройки ПО. Вот в примере выше в качестве языка управления конфигурацией мы породили некоторый DSL, для которого нет инструментов ни автодополнения, ни рефакторинга. Это нам ещё повезло — язык остался текстовым (а не представлен, скажем, в виде каких-то данных в РСУБД), поэтому мы хотя бы можем делать diff и blame.

xml, json, ini — большинству айтишников знакомы и понятны. Добавить раздел в xml или json сможет любой в блокнотике.
Чем ему поможет, если конфиг будет в виде какого-нибудь cs-файла с кодом на шарпе?

S>Даже в таком простом примере видно, что "простые значения" в конфиге должны быть согласованы между собой; но никаких средств проверки этого (кроме запуска приложения и тестирования сценариев) у нас нет.

Их не будет в любом случае

K>>Этот код выполнится в том же процессе и в том же домене. Запустил человек доверенную программу под админом, а там какой-то левый код побежал по файлам шуршать.
S>Ещё проще — человек запустил доверенное приложение под админом, а в нём — левый код.

Админ может установить доверенное приложение в папку с запретом на запись рядовым пользователем, либо ограничить запуск только подписанных приложений.
Можно конечно и конфиг заблокировать.

S>Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.

Я хочу избежать ситуации, когда админ вынужден давать лишние права "не админам".

S>Но я всё ещё считаю, что это должен быть код на каком-то языке с нормальным тулчейном, а не просто плоский ini, или простынки json/XML.

Так я и говорю, что либо простой плоский ini/xml/json, либо отдельный человеческий инструмент, который даст пользователям нормально настроить программу

K>>Ну, конечно дома или в фирме на 30 сотрудников, есть админ, который ещё и осилит права правильно раздать.
S>Ещё раз: в такой фирме или дома, компьютер уже представляет из себя большую дыру. Люди гоняют скачанные из интернета екзешники под локальным админом и в ус не дуют.

Потому что программисты пишут программы с конфигами, которые требуют админов для работы.
На форуме многих программ админы просят: сделайте возможность работы программы без админских прав, но это деньги не приносит, поэтому просьбы игнорируются.

K>>Только вот настраивается 1С Предприятие автоматически, а минимальные настройки для ключей и т.п. — обычные ini-файлы из десятка строк, где что-то сломать проблематично.
K>>А если конфигурацию из 1С считать конфигом, то в принципе любую программу можно считать им, особенно если там интерпретатор, а не компилятор.
S>Да, я предлагаю конфигурацию 1С считать конфигурацией. Ну, потому что это конфигурация.

Ну, значит программа на шарпе с использованием WPF и Entity Framework — это тоже некий конфиг
Конфигурация 1С — это не просто описание подключения неких модулей, а вполне себе и описание схемы БД и код всех методов.

S>А почему не хранить сам этот DTO в формате object initializer?
S>В отличие от json, этот код можно рефакторить, а написание оборудовано автодополнением.

Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
Если уж конфиг нужно часто менять и сильно дописывать, то никто разработчикам не мешает сделать GUI-тулзу для заполнения этого json c валидацией.