Re[15]: лучшие практики для настроек-конфигов приложения.. - .NET

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

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

Расскажу как это делается ~~у нас~~ правильно.

Конфиги типа сохранения размера окошек и других причуд пользователя — это отдельный разговор и вроде как стандартный Settings работает неплохо.

Тут будет про настройки самого приложения для различных окружений типа PROD, UAT, QA, DEV, TEST и т.п.

В качестве source имеется json следующего вида:

[
  {
    "Schema"  : "dbo",
    "Table"   : "Property",
    "Columns" : [ "Category", "Name", "Environment", "Value", "Type" ]
    "Data"    :
    [
      [ "Mail",                           "Host",              "DEFAULT",    "lalala.yoyoyo.com",            "string" ],
      [ "Mail",                           "Port",              "DEFAULT",    "25",                           "int"    ],
      [ "Mail.From",                      "LaLaLaNotifyEmail", "DEFAULT",    "lalala.dev@yoyoyo.com",        "string" ],
      [ "Mail.From",                      "LaLaLaNotifyEmail", "UAT",        "lalala.uat@yoyoyo.com",        "string" ],
      [ "Mail.From",                      "LaLaLaNotifyEmail", "PROD",       "lalala@yoyoyo.com",            "string" ],
      [ "Mail.To",                        "Support",           "DEVAULT",    "",                             "string" ],
      [ "Mail.To",                        "Support",           "DEV,QA,UAT", "lalala.developers@yoyoyo.com", "string" ],
      [ "Mail.To",                        "Support",           "PROD",       "lalala.support@yoyoyo.com",    "string" ],
      [ "PostProcessor.UpdateStatistics", "CommandTimeout",    "DEFAULT",    "0",                            "int"    ],
      [ "PostProcessor.UpdateStatistics", "CommandTimeout",    "PROD",       "720",                          "int"    ],

      ... ещё пару сотен переменных
    ]
  }
]

По этому файлу генерируется SQL скрипт:

-- [dbo].[Property]
--
MERGE INTO [dbo].[Property] AS Target
USING
(
    VALUES
    ( N'Mail',                           N'Host',              N'DEFAULT',    N'lalala.yoyoyo.com',            N'string' ),
    ( N'Mail',                           N'Port',              N'DEFAULT',    N'25',                           N'int'    ),
    ( N'Mail.From',                      N'LaLaLaNotifyEmail', N'DEFAULT',    N'lalala.dev@yoyoyo.com',        N'string' ),
    ( N'Mail.From',                      N'LaLaLaNotifyEmail', N'UAT',        N'lalala.uat@yoyoyo.com',        N'string' ),
    ( N'Mail.From',                      N'LaLaLaNotifyEmail', N'PROD',       N'lalala@yoyoyo.com',            N'string' ),
    ( N'Mail.To',                        N'Support',           N'DEVAULT',    N'',                             N'string' ),
    ( N'Mail.To',                        N'Support',           N'DEV,QA,UAT', N'lalala.developers@yoyoyo.com', N'string' ),
    ( N'Mail.To',                        N'Support',           N'PROD',       N'lalala.support@yoyoyo.com',    N'string' ),
    ( N'PostProcessor.UpdateStatistics', N'CommandTimeout',    N'DEFAULT',    N'0',                            N'int'    ),
    ( N'PostProcessor.UpdateStatistics', N'CommandTimeout',    N'PROD',       N'7200',                         N'int'    ),

      ... ещё пару сотен переменных
)
AS Source (...)
ON ...
WHEN MATCHED ...
WHEN NOT MATCHED BY Target ...
WHEN NOT MATCHED BY Source ...
;

Дополнительно генерируется C# файл:

static partial LaLaLaProperty
{
    public static partial class Mail
    {
        private static string _Host;
        public  static string Host { get { return _Host; } set { _Host = value; } }
        private static string _Port;
        public  static string Port { get { return _Port; } set { _Port = value; } }

        public static partial class From
        {
            private static string _LaLaLaNotifyEmail;
            public  static string  LaLaLaNotifyEmail { get { _LaLaLaNotifyEmail; } set { _LaLaLaNotifyEmail = value; } }
        }

        public static partial class To
        {
            private static string _CommandTimeout;
            public  static string  CommandTimeout { get { return _CommandTimeout; } set { _CommandTimeout = value; } }
        }
    }

    public static partial class PostProcessor
    {
        public static partial class To
        {
            private static string _Support;
            public  static string  Support { get { return _Support; } set { _Support = value; } }
        }
    }

    static void SetProperties()
    {
        Mail.Host                                      = GetValue<string>("Mail",                           "Host");
        Mail.Port                                      = GetValue<int>   ("Mail",                           "Port");
        Mail.From.LaLaLaNotifyEmail                    = GetValue<string>("Mail.From",                      "LaLaLaNotifyEmail");
        Mail.To.Support                                = GetValue<string>("Mail.To",                        "Support");
        PostProcessor.UpdateStatistics.CommandTimeoutt = GetValue<string>("PostProcessor.UpdateStatistics", "CommandTimeout");
    }
}

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

SendMail(Mail.Host, Mail.Port, ...);

Само собой код приведён не полностью, только чтобы обозначить идею. Да и всё это является лишь часью более крупной системы.

Итого. Для добавления настройки разработчику необходимо добавить её в json файл и запустить Run Custorm Tool для сообтветствующего T4, после чего она готова к употреблению.

MH>в каком формате хранить?
Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение. Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается

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

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

1. Времена лиспа не прошли.

2. JS в современном вебе — это данные или код?

3. Идея рассматривать код в качестве данных возникла задолго до лиспа, принадлежит Фон Нейману (это так и называется, "архитектура Фон Неймана), и позволяет использовать для программирования ЭВМ компиляторы, линкеры и загрузчики, а не вводить программы с помощью тумблеров на панели. Революционность этой идеи заключается в том, что в условиях, когда оперативная память была чертовски дорогой и ограниченной в объеме, все равно имело смысл потратить часть ее с целью облегчения жизни программистов, а не "по назначению" — для рассчета баллистических траекторий полета снарядов и взлома вражеских шифров.

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

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

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

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

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

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

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

НС>>Ну так это классика жанра. Сперва ваши продакты пошли на поводу у разрабов и начали абьюзить конфиги, напихивая туда то, что должно быть написано в коде. А потом огребли проблем, и ты теперь обвиняешь в них xml, json или что там у вас.
S>Не, ну всегда всё можно свалить на продактов. Делов-то.

Что значит свалить? Внешний облик продукта — именно их зона ответственности.

S>С точки зрения бизнес-требований, как раз и требовалось сделать так, чтобы можно было какие-то вещи настраивать.

Зато с точки зрения анализа требований должно быть понятно, что если нам надо и коробочных пользователей окучивать, и тех самых citizen developers, то крайне неудачная идея пытаться для них сделать единый набор ручек. Слишком сильно разнятся требования, в результате либо мы фигово окучим кого то одного, либо обоих. В исходном варианте у вас пострадали вторые. Ты предлагаешь, чтобы страдали первые. Единственный вариант хорошо сделать обеим категориям — сделать многоуровневый инструментарий.

S>Да, именно об этом я и говорю.

Нет, ты говоришь о переносе конфига в cs код.

S>Просто вот это вот архитектурное решение не всегда очевидно с первого взгляда; умение разделить citizen developers и core developers — редкая штука. Я по пальцам могу пересчитать подобные решения на рынке.

Так тем лучше, меньше конкуренция.

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

Это тоже плохое решение. Потому что стоимость там определяется требуемым хорошим знанием самой системы, и статическими проверками оно вообще никак не фиксится.
Правильное решение в нашем новом продукте. Ты ставишь коробку, и большое количество типовых сценариев (причем оптимизированных для конкретного рынка) ты получаешь из коробки. Если что то не устраивает — ты можешь в визифиге покрутить настроечки. Если мало — можешь свою настройку в том же визифиге собрать с использованием своих данных и ML. А если и этого мало — REST API тебе в руки.

S>Возможность втыкания коробки необученным пользователям, есличо, не является самостоятельной ценностью.

Еще как является. Проверено на практике.

S> Зачастую рынок ведёт себя контринтуитивным способом — например, если развёртывание систем данного класса принято делать при помощи системных интеграторов, то они неожиданно могут предпочитать те системы, которые сам пользователь воткнуть как раз не может — потому что "сложность внедрения" это их хлеб.

Поэтому рынок сперва изучается. Интервью крупных заказчиков, публичная демонстрация MVP, даже специальный demo-продукт. И если понятно что интеграторов выгоднее послать и работать с заказчиками напрямую — это и следует сделать.
Но мы очень далеко уже ушли от конфигов. Если спустится на уровень кода, а не продукта, то вот у меня в проект есть совершенно четкое разделение настроек в коде, которые обычно делаются в Startup-классе вызовом .Configure без указания секции или AddOptions, и те настройки, для которых таки есть в IConfiguration соответствующая секция. В последние что то выносится только явным указанием в требованиях на основе анализа конкретных use cases.
В таком раскладе уезжание в конфиг развесистых соплей со сложной логикой, как в твоем примере, вызовет вопросы еще на этапе написания диздоков, а не улезет в готовый продукт. И, скорее всего, до кода дело даже не дойдет, не говоря уж про применение костыле в виде компиляции шарпового кода на лету, которые все равно не совместимы нормально с типичной инфраструктурой конфигурации кластера в виде всяких куберовских конфигмапов или того же консула, и совершенно точно не совместимы с современными требованиями безопасности (хрен ты свои конфиги на полноценном языке сертифицируешь по ISO27001 и SOC2).

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

более интересный вопрос — как в приложении организована работа (чтение/хот релоад)?
тут есть два подхода.
1. где-то заранее (в Startup/Init) читаем в спец класс-конфиг (в нём каждая проперть соотвествует какой-то конфиг-настройке).
но минус в том что, будет один класс который должен знать обо всех настройках всех подсистем.
суть минуса — наличие зависимости, необходимости правки общего места (класса-конфига) при возникновении необходимости в новой настройке в локальной подсистеме.
это и плюс с другой стороны — мы знаем все настройки, они перечислены, задокументированы кодом, легко ищутся их использования.

2. противоположный 1-му подходу. на старте создаем некий IConfigProvider и далее через него все подсистемы сами читают что им нужно.
+ каждая подсистема сама читает нужные настройки, при возникновении в ней новых — не надо править центральное место.
— нет единого места, где все перечислены (хотя можно доку написать и поддерживать).

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

3. стандартный в .net подход с appsettings.
у меня не пошел. много церемоний, сложнее понимать.

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

НС>Ну так это классика жанра. Сперва ваши продакты пошли на поводу у разрабов и начали абьюзить конфиги, напихивая туда то, что должно быть написано в коде. А потом огребли проблем, и ты теперь обвиняешь в них xml, json или что там у вас.
Не, ну всегда всё можно свалить на продактов. Делов-то.
Не очень понятно, что такое "должно было быть написано в коде". С точки зрения бизнес-требований, как раз и требовалось сделать так, чтобы можно было какие-то вещи настраивать.
Потому что первое интуитивное решение, конечно, же реализовывать все 100*N сценариев для N клиентов в виде N вариантов сборки софта.
И это быстро тонет с ростом N, потому что есть объективная стоимость регрессионного тестирования и прочая себестоимость релиза, квазилинейно растущая с ростом объема кода.
Из этого как раз и вырастает требование — давайте мы сделаем 50 "платформенных фич", из которых будут конструироваться 100*N сценариев при помощи локальной настройки одной и той же платформы под нужды конкретного клиента.

НС>И решать такие проблемы надо не перетаскиванием всей конфигурации в код. Вместо этого продакт должен сесть и хорошо разделить сценарии именно конфигурации коробки, и превращения коробки в кастомное решение. Для первых сценариев как раз и нужны декларативные конфиги. Причем даже наличие в них имен типов логгеров как в твоем примере — уже ошибка, потому что это лишняя информация из кода, не имеющая к продукту отношения. А вот для второго типа сценариев, рассчитанного не на обычных админов, а на то что сейчас модно называть citizen developers, как раз и оправдано создание DSL или системы загрузки шарпового кода.
Да, именно об этом я и говорю. Просто вот это вот архитектурное решение не всегда очевидно с первого взгляда; умение разделить citizen developers и core developers — редкая штука. Я по пальцам могу пересчитать подобные решения на рынке.

НС>Если что, у нас в одном из старых продуктов точно такая же история. Сверхложное конфигурирование, которым заказчики заниматься не в состоянии, и специальная структура professional services, обладающая эзотерическими знаниями о продукте. И вот ведь затыка — там json конфигов как таковых и нет, а сложные вещи описываются на встроенном JS. Только это, мягко говоря, проблему не решает. Потому что проблема не в формате конфигов, а в том что при формировании требований к продукту никто не заморачивался возможностью для распространенных сценариев воткнуть коробку необученным пользователем.
Вы правы — тут трудно разделить технические проблемы от административных. Особенно когда у нас нет возможности подсмотреть в соседнюю реальность, где для тех же начальных условий было принято другое решение.
Например, у вас могли вместо встроенного JS выбрать "конфигурацию через БД", и к сложностям настройки добавились бы ещё и сложности переноса настроек между экземплярами системы.
А могли выбрать статически типизированный язык с развитыми возможностями декомпозиции, и снизить стоимость разработки этих конфигов.

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

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

scf>https://github.com/lightbend/config/blob/master/HOCON.md
scf>Формат вменяемый, удобный

Это такая 1-апрельская шутка штоле??

Эта бредятина документирована на 14(!!!!) страницах. С виду — какой-то гибрид макросов и JSON. На деле — переусложнённая хрень, где в JSON просто вмешали какие-то местечковые задачки. Поверь старому анжанеру — это г****вно не взлетит. Даже hi_octane с его "кодом-как-конфиг" (дырявым донельзя) имеет бóльшие шансы.

Здравствуйте, 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 какого, в которые никакую логику не засунуть.

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

В>>yaml

НС>Аргументы есть? Или как обычно?

Более человеко-читаемый чем json (и тем более чем xml)
Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени
Есть иерархия и списки (в отличие от ini)
Можно писать комментарии, в отличие от json

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

bnk>Более человеко-читаемый чем json (и тем более чем xml)

Обоснуй.

bnk>Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени

Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.

bnk>Можно писать комментарии, в отличие от json

В современном json комменты как правило можно таки писать.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

bnk>Я имел в виду, меньше визуального мусора типа этих скобочек, запятых и т.д.

С чего ты взял что это мусор? Или это очередная песнь про синтаксический оверхед.

НС>>Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.
bnk>Это да, бесит.

Ну и нафига тогда?

bnk>>>Можно писать комментарии, в отличие от json
НС>>В современном json комменты как правило можно таки писать.
bnk>jsonc?

Нет, в обычном json. Парсер дотнетный по крайней мере без проблем потребляет конфиги с комментами.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

S>Очень странный набор необоснованных утверждений.

Если ты что-то недопонимаешь, это не повод называть "безосновательные". Это повод задуматься: "А не слишком ли я глух к чужим словам, считая своё решение самым правильным?".

S>Что такое "настроечные величины"? Начинается всё обычно невинно: ну там, "номер порта, на котором слушать"

Именно! "настроечные величины" и есть самые простейшие скаляры, которыми "подстраивается" программа. Т.е. код — неизменен, изменяются лишь параметры.

S>Потом постепенно вырастают идеи типа "а давайте у нас приложение будет поставляться в виде набора универсальных кубиков, которые мы будем склеивать в рантайме в соответствии с конфигурацией".

Ну так ты вообще про другое — ПРО ПЛАГИНЫ! К каждому из которых, прикинь, можно тоже поставлять конфиг простейших величин.

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

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

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

K>Это такая 1-апрельская шутка штоле??

K>Эта бредятина документирована на 14(!!!!) страницах. С виду — какой-то гибрид макросов и JSON. На деле — переусложнённая хрень, где в JSON просто вмешали какие-то местечковые задачки. Поверь старому анжанеру — это г****вно не взлетит. Даже hi_octane с его "кодом-как-конфиг" (дырявым донельзя) имеет бóльшие шансы.

Если ты что-то недопонимаешь, это не повод называть "безосновательные". Это повод задуматься: "А не слишком ли я глух к чужим словам, считая своё решение самым правильным?".

http://rsdn.org/forum/dotnet/7979469.1

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

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

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

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

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

S>Ок, я вижу, чего вы не понимаете. Сотни тысяч строк образуются не единомоментно. Сначала у нас маленькая понятная система; потом в неё добавляется чуть-чуть гибкости; потом добавляются новые требования, и т.п. Всем нравятся такие системы, в которых требования можно реализовать настройкой. И вот у нас админы дописали чуть-чуть сюда, потом чуть-чуть туда, и вот у нас прошло пять лет — и в этом конгломерате уже хрен разберёшься.

Ну так это классика жанра. Сперва ваши продакты пошли на поводу у разрабов и начали абьюзить конфиги, напихивая туда то, что должно быть написано в коде. А потом огребли проблем, и ты теперь обвиняешь в них xml, json или что там у вас.
И решать такие проблемы надо не перетаскиванием всей конфигурации в код. Вме6сто этого продакт должен сесть и хорошо разделить сценарии именно конфигурации коробки, и превращения коробки в кастомное решение. Для первых сценариев как раз и нужны декларативные конфиги. Причем даже наличие в них имен типов логгеров как в твоем примере — уже ошибка, потому что это лишняя информация из кода, не имеющая к продукту отношения. А вот для второго типа сценариев, рассчитанного не на обычных админов, а на то что сейчас модно называть citizen developers, как раз и оправдано создание DSL или системы загрузки шарпового кода.
Если что, у нас в одном из старых продуктов точно такая же история. Сверхложное конфигурирование, которым заказчики заниматься не в состоянии, и специальная структура professional services, обладающая эзотерическими знаниями о продукте. И вот ведь затыка — там json конфигов как таковых и нет, а сложные вещи описываются на встроенном JS. Только это, мягко говоря, проблему не решает. Потому что проблема не в формате конфигов, а в том что при формировании требований к продукту никто не заморачивался возможностью для распространенных сценариев воткнуть коробку необученным пользователем.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

Но если вдруг проблема с кубером встанет — куча народу обновляет на кубере всякие текстовые файлы через замену плейсхолдеров %VALUE% на нормальные значения regex-ами. Думаю девопсы не долго думая тоже самое запилят и с нашим конфигом. Большой разницы называется файл .cs или .json для регекса в принципе нету. Значения name="value" выглядят почти одинаково на всех языках.

Но вот что ты будешь делать, если клиент скажет — "У нас в модуле XXX случается крэш раз в два дня. Потери ацкие. Надо чтобы после крэша приложение стартануло, посмотрело через API через которые оно работает 'на каком оно свете', и если всё хорошо — то запустило модуль XXX считать заново, а если всё плохо — запустило 'процедуру восстановления'". Я через конфиг в коде такое делал как индивидуальную затычку для конкретного клиента, за срочность и трудность выписал счёт. Если через полгодика выдержки сформируется что-то универсальное — может и решу перетащить это в код приложения как новую фичу. C ini, xml или json — я бы этого беднягу нафиг послал. Максимум что придумалось бы — выпилить идивидуальную плагин-DLL загружающуюся до старта с доступом "везде и всюду" ради такого случая

но эту DLL ещё предусмотреть надо. Или создавать персональный релиз.

Или ещё была ситуация — приложение расчитано на бесперебойную работу и слушать определённый порт анонсированный в паблик, но клиенту понадобилось странного — рестарты раз в сутки, минимум простоя и видимость бесперебойной работы. И вот хочет он "а сделайте что-бы данные мигрировали из процесса А который будет закрыт, в процесс Б". Для нас это выливается в "при старте процесс Б сигналит процессу А. Тот закрывает порт 3333, передаёт снэпшот процессу Б. Б проверяет что полученный снэпшот верный, после чего открывает порт 3333, грохает А, и готов продолжать работу". Снова, своим конфигом это сделали на проде, под конкретного клиента. И снова никакой xml такую ad-hoc хотелку не предусмотрит.

А ещё в конфиге некоторые параметры — формулы. Сейчас всё пишется естественно: A.B.Distribution = new OrderedDistribution(TimeSpan.FromSeconds(10), x => 2.0+x.AliveTime*x.AliveTime*x.AliveTime); Выдумывать парсер математических выражений в json/ini/xml? Изобретать отдельные секции для OrderedDistribution, FifoDistribution, RandomDistribution, LruDistribution? Спасибо, но нет. Одно из моих преимуществ — это то что клиент завтра придумает MySupaDupaDistribution — и я ему скажу — "вот этот кусок кода сунь в конец конфига, и будет работать".

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

S>Здравствуйте, karbofos42, Вы писали:
K>>Писать же простыню кода на шарпе в блокнотике без компилятора и т.д. — это такое себе удовольствие не для программиста.
S>На чём основано это предположение?
S>Ну, то есть почему-то код на JavaScript в блокнотике без калькулятора вы писать согласны, а на CS — нет. Хотелось бы более развёрнутого описания причины.

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

K>>Чтобы это работало, нужно, чтобы был установлен компилятор, IDE, и не отдельный файлик cs, а вполне себе целый проект с референсами на какие-то Assembly с интерфейсами для работы с API.
S>Компилятор у нас идёт как часть дотнета. IDE по-прежнему необязательна — если вас устраивает уровень "JSON в блокноте", то вы можете продолжать писать в блокноте.
K>>Компания купила программу, а потом будут нанимать программиста, который её настраивать будет? Не админа своего попросит, а именно разраба?
S>Почему? Попросит админа.

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

S>

Проблема как раз в том, что набор страниц правится в админке. Это та самая "тулза", за которую вы так ратуете.
S>Вот только последствия применения этой тулзы крайне разочаровывают.
S>Например, невозможно понять, кто, когда, и зачем поменял набор страниц. Был бы текстовый конфиг — мы бы сделали blame и нашли бы коммит с комментариями. По ним можно было бы восстановить ссылку на issue в трекере, с историей обсуждений и принятых решений.
S>Например, крайне тяжело перенести набор страниц (или его часть) со стейджинга в продакшн. Кроме "открыть две админки на двух мониторах" и вдумчиво втыкать — способов нет. Был бы текстовый конфиг — был бы копи-пейст.
S>Например, настройка 100 почти одинаковых страниц стоит ровно в 100 раз больше, чем одной. И так далее.

Осталось людям рассказать, что всякие там CMS не нужны и в них нельзя права раздавать и логи вести.
Нужно всем гит разворачивать и в IDE код писать, а не всякие там WYSIWYG-редакторы.

K>>Конфиг же для того, чтобы настроить окружение под запуск ПО.
K>>Прописать настройки подключения к БД, описать модули, которые должны подключаться и т.д. и т.п.
S>Опять: делаете ещё два шага — и у вас оказывается, что модули зависят друг от друга, и т.п. Конфиг начинает представлять собой декларативную программу, не оборудованную ни компилятором ни отладчиком.
S>Может, сразу начать с конфига на полноценном языке?

А в SQL-запросах параметры не нужны, нужно конкатенацией строк всё формировать, столько новых возможностей появится...

K>>Параметры отображения окошек, шрифт и т.п. вещи — это настройки, которые в идеале меняются из программы, а не нужно по каким-то файлам лазить и менять в IDE имя шрифта.
S>Ну и пусть меняются, кто вам запретит?
K>>Добавить какую-то логику — это уже скорее добавить плагин/модуль, вот он пусть будет в виде dll на шарпе, а в конфиге только добавляется запись о подключении этого модуля.
S>Не "добавить какую-то логику", а "сконфигурировать какую-то логику". "Пусть при наступлении условия X отправляется письмо по адресу f(X) с текстом g(X)". Как вы сделаете такую штуку в ini файле?
S>Или предлагаете для каждой нотификации обращаться к разработчикам исходной системы?

Если нотификацию не предусмотрел разработчик, то никак не сделать.
Если предусмотрел, то наверно он опишет как это сделать.
Если разработчик этого не описал, то куда и какой метод на шарпе я должен написать для этого? Откуда я получу контекст и узнаю что за X?

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

А в Майкрософт идиоты всякие оснастки *.msc делают. Не знал, что админы те же групповые политики вручную в блокнотике пишут и раскидывают по нужным папкам.
Сам вот грешен — предпочитал всякими gpedit пользоваться, а не вручную "конфиги" заполнял.
Ну, и странно, что скриптование на шелле просят, а не на шарпе.
Дайте файлы конфигурации — это дайте нам готовые файлы и скажите куда их положить или же: дайте нам документацию на сотню страниц и мы с нуля напишем конфигурацию в IDE с компилятором и всем таким?

K>>Так и вижу админов крупного предприятия, ставят одну программу — там конфиг на Java, вторую — на C#, третью — скрипт на PowerShell, ...
S>По факту — так и есть.
S>Потому что один XML конфиг отличается от другого XML конфига примерно так же, как JavaScript от Go — скобочки одинаковые, всё остальное разное.

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

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

Плавали, знаем. Вот я сейчас работаю в продукте, где как раз "заказчик сам галочки натыкает, продукт настроит, и всё хорошо". По факту, к стоимости программы плюсуются так называемые professional services, которые натыкивают галочки за заказчика. Рекорд скорости по натыкиванию за многие годы — три месяца. Обычно — от шести месяцев и до полуторых лет. Иногда галочки натыкиваются так, что через два года клиент говорит "давайте всё снесём, и поставим заново с нуля, т.к. ваши попытки исправить косяки в конфигурации меня уже задолбали". Как раз ровно имеем ситуацию "нечем провалидировать конфиг".

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

S>А платформ-тим уже несколько лет пытается добавить функции "экспорт/импорт конфигурации", с переменным успехом. Потому что не очень понятно, что считать частью конфигурации.
S>Ну, вот стейджинг же у нас должен отличаться от продакшна — хотя бы IP адресами; и ещё всякими мелочами типа что почта со стейджинга должна уходить в специальные почтоуловители, а не в реальный мир, и деньги не должны списываться с настоящих кредиток. А вот в остальном он должен максимально повторять продакшн, чтобы результаты тестирования на стейджинге были применимы к продакшну.
S>И как отделить локальные настройки от нелокальных — ХЗ.

У вас одна сборка и отладочные методы со всякими моками тоже заказчику отдадите?
Ну, там в банке админ сможет поправить конфиг на 5 минут, чтобы перенаправить нотификацию на почтоуловители и перевести на свою карту с каждого счёта по рублю при помощи какого-нибудь отладочного метода, а потом вернуть всё как было?
Чтобы больше соответствовало продакшену и нужно, чтобы различия были в виде IP-адресов, строк подключения к БД и т.д.
А если там какие-то конфиги на шарпе, которые делают совершенно разные вещи, то тест и продакшен ничего общего не имеют получается.

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

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

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

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

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

scf>5k звезд на гитхабе, массово применяется в серверном софте, де факто стандарт для Scala разработчиков, просачивается и в Java.

Ну это как "самый популярный тиктокер" — сам понимаешь, репутация не самая впечатляющая. Я даже из мира .NET знаю, что самое популярное — это JSON. Причём сам же его стал массово использовать, как только про него узнал. Зачем мне в .NET с его вездесущим XML понадобился жабоскриптный JSON? Вот поэтому — за простоту и гибкость! Хотя вариантов форматов было море, включая неуклюжий yaml, ini и т.п.

Есть такая штука — инженерное чутьё. Это та самая способность оставаться на месте, когда куча неадекватов бежит сломя голову, чтобы убиться об стену в тупике. Пыль рассеется — сам всё увидишь.

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

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

S>В случае настоящего языка программирования у нас есть компилятор, есть автопроверка кода в IDE, есть линтеры.

Если не жахаться с модными и молодежными json и yaml, то для xcml есть схема, которая большую часть валидации вполне позволяет описать, и она поддерживается любым приличным редактором.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

IT>>Итого. Для добавления настройки разработчику необходимо добавить её в json файл и запустить Run Custorm Tool для сообтветствующего T4, после чего она готова к употреблению.
НС>Это ты какой то велосипед придумал. Зачем настройки в РСУБД хранить? Зачем генерить класс по json?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Если не жахаться с модными и молодежными json и yaml, то для xcml есть схема, которая большую часть валидации вполне позволяет описать, и она поддерживается любым приличным редактором.
S>Тут, наверное, опечатка? Имелся в виду XML?
S>Ну, так это же попытка добавить семантику туда, где её изначально не было.
S>То есть сначала выбираем говноформат, неудобный ни для людей, ни для компьютеров, а потом мужественно прикручиваем к нему схему.
S>На всякий случай напомню, что схемы эти существуют строго в теории — ну, то есть, для каких-то популярных продуктов вы найдёте схему конфига. А для custom section — нет, не найдёте.
S>Так то и для JSON в теории существуют схемы — затруднился бы ещё кто-то их сесть и написать.

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

Как нам в этом поможет одинокий cs-файл? Откуда появится валидация и т.д.?
Или в каком виде предполагаются конфига на шарпе пользователям отдавать?

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

MH>что показывает практика, что лучше в долгую в среднем/большом проекте?

...поэтому глупо спрашивать, какой ответ лучше — "8" или "16"? Под какую задачу вам нужен ответ??

MH>3. стандартный в .net подход с appsettings.
MH>у меня не пошел. много церемоний, сложнее понимать.

Как ни удивительно, (3) прекрасно живёт во многих проектах!

В моей практике, (3) используется практически всегда (позиция окошек, конекшены, последнее имя юзера, рабочая папка и т.п.).
Но если юзер держит какие-то важные (или объёмные) данные личного характера, делаю отдельный JSON, который всегда можно бэкапнуть.
Во всех остальных конфигах смысла как-то не было.

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

НС>Здравствуйте, bnk, Вы писали:

bnk>>Более человеко-читаемый чем json (и тем более чем xml)

НС>Обоснуй.

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

bnk>>Меньше писать чем в json (и тем более xml), никаких левых скобочек, уголков и прочей служебной хрени

НС>Зато нечаянно удаленные пробельчики потом могут привести к совершенно феерическим спецэффектам. У меня народ с хелмами регулярно грабли собирает.

Это да, бесит. Но тут или шашечки или ехать. Питон же терпят.

bnk>>Можно писать комментарии, в отличие от json

НС>В современном json комменты как правило можно таки писать.

jsonc? Ну костыль конечно, но таки да.

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

S>Схренабы? Кто-то отменил compile on the fly?

Нафига такая дурь в данном конкретном случае?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sinclair, Вы писали:
S>>Схренабы? Кто-то отменил compile on the fly?
НС>Нафига такая дурь в данном конкретном случае?
Эмм. Вернёмся на шаг назад:

Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается

От себя добавлю: компайл-тайм (и едит-тайм) проверка валидности конфига; наличие инструментов по рефакторингу, автодополнению, и прочему.
Никаких проблем перекомпилировать конфиг после перечитывания нет, почему это "дурь" — решительно непонятно.

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

S>MH>2. противоположный 1-му подходу. на старте создаем некий IConfigProvider и далее через него все подсистемы сами читают что им нужно.
MH>>+ каждая подсистема сама читает нужные настройки, при возникновении в ней новых — не надо править центральное место.
MH>>- нет единого места, где все перечислены (хотя можно доку написать и поддерживать).
MH>>что показывает практика, что лучше в долгую в среднем/большом проекте? единый класс-конфиг или каждый читает сам что нужно?
S>MH>3. стандартный в .net подход с appsettings.
MH>>у меня не пошел. много церемоний, сложнее понимать.
S>

S>А в чем проблема совмещать 2 и 3 -- каждую секцию вычитывать своим IConfigProvider из одного файла appsettings?

Он жен написал, "у меня не пошел". Что тут можно обсуждать?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

Мое мнение:

1. Есть настройки для нормальной работы пользователя, и есть "технические" настройки для решения/исследования проблем. Надо их четко различать. К ним даже доступ должен быть разным. Например, в программе с графическим интерфейсом пользовательские настройки следует вынести в меню, а "технические" вполне уместно оставить в конфигурационном файле.

2. Чем пользовательских настроек меньше, тем лучше. Фактически, оставляя пользователю некую настройку, вы создаете механизм, чтобы извлечь из него некую информацию. Не надо пытаться извлекать из пользователя информацию, которой он не обладает, не надо заставлять его принимать решения, на принятие которых у него не хватит квалификации. Многие вещи программа вполне могла бы выяснить для себя автоматически, и не заставлять пользователя делать это за нее.

3. В то же время, не надо лишать пользователя влиять на параметры, изменение которых могло бы принести ему пользу.

4. В качестве формата лично я предпочитаю .INI. Но это не принципиально.

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

_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение. Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается

Основной минус — если в файл "конфига" сможет писать хакер, то полный контроль над системой гарантирован. Но если проект не для масс-маркета и обслуживается персональным админом, этот вариант даёт 200% гибкости.

Получается, для запуска приложения совершенно необходим компилятор, а пользователь должен знать C#?

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

Pzz>Получается, для запуска приложения совершенно необходим компилятор, а пользователь должен знать C#?

Уровень знаний у всех разный. Json это тоже часть javascript. Т.е. что-то о программировании нужно знать или нужен UI для изменения настроек.
А это уже совместный доступ. А это уже СУБД. Нужно видимо просто делить настройки на изменяемые и неизменяемые.
Но все условно конечно.

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

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

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

Угу. В sendmail'е так и сделано

Впрочем, ты не знаешь, что такое sendmail...

Здравствуйте, 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

Здравствуйте, 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 валидацией.

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

K>Только конфиги почему-то обычно в блокнотике правят
но для чего так страдать? к чему такой аскетизм?
какая религия запрещает просто скопировать папку с Visual Studio Code, запустить его, и получить подсветку кода, атоподстановку, etc.?

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

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

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

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

K>>xml, json, ini — большинству айтишников знакомы и понятны. Добавить раздел в xml или json сможет любой в блокнотике.

K>>Чем ему поможет, если конфиг будет в виде какого-нибудь cs-файла с кодом на шарпе?

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

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

S>В случае настоящего языка программирования у нас есть компилятор, есть автопроверка кода в IDE, есть линтеры.

Чтобы это работало, нужно, чтобы был установлен компилятор, IDE, и не отдельный файлик cs, а вполне себе целый проект с референсами на какие-то Assembly с интерфейсами для работы с API.
Компания купила программу, а потом будут нанимать программиста, который её настраивать будет? Не админа своего попросит, а именно разраба?

S>Для каких-то простых случаев, типа расположения окошек на экране, плоский текстовый файл, действительно, подойдёт.

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

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

K>>Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
S>В примитивных случаях — да. Но очень часто "залезают в конфиг" не только для изменения параметров, но и для штук типа "добавить вот такую форму ввода", или "добавить вот такую страничку в магазин".
S>И вот там-то начинается: 90% логики веб-магазина — как раз в страничках, и связях между ними.

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

S>Бенчмарк дотнет, к примеру, можно поконфигурить и через параметры командной строки. Но почему-то разработчики в основном пользуются нормальной конфигурацией на языке оригинала: https://benchmarkdotnet.org/articles/configs/configs.html

Да я и для Cake без особых проблем код писал и даже без компиляции и проверки синтаксиса, только это всё для разработчиков, а не для пользователей.
Ну, не упёрлось админам и прочим людям изучать какие-то там DSL, писать код на каких-то там ЯП.
Так и вижу админов крупного предприятия, ставят одну программу — там конфиг на Java, вторую — на C#, третью — скрипт на PowerShell, ...
И ни для чего нет нормального инсталлятора, бери архив и допиливай напильником до рабочего состояния и изучай все эти ЯП, ставь компиляторы, IDE,...

K>>Если уж конфиг нужно часто менять и сильно дописывать, то никто разработчикам не мешает сделать GUI-тулзу для заполнения этого json c валидацией.
S>GUI тулза стоит дороже, чем интерпретатор своего простого ЯП. При этом она всё ещё не умеет ни копи-пейста, ни "сделай мне 10 вариантов с малыми отличиями друг от друга", ни сравнения версий.

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

Здравствуйте, karbofos42, Вы писали:
K>Мне все эти js и не нравятся тем, что нужно в блокнотике всё писать и ловить в рантайме, только я хотя бы учился на программиста, а не админ/пользователь, которому внезапно приходится этим заниматься.
Ну, так и XML с ini ничуть не лучше.

K>И админ выучит шарп и с нуля накатает конфиг? Или его и хватит только на то, чтобы в готовом конфиге адрес сервера изменить?
Зачем с нуля? С нуля у вас пользователь и .ini файл вряд ли накатает. Там же надо синтаксис знать

А в готовом конфиге адрес сервера правится примерно одинаково — что в ini, что в JS, что в XML, что в CS.

K>Осталось людям рассказать, что всякие там CMS не нужны и в них нельзя права раздавать и логи вести.
Права ортогональны обсуждаемому вопросу. И большинство сайтов, "написанных" на CMS, страдают ровно от этих же проблем.
Потому что у вас часть "конфигурации" живёт в каталоге товаров, часть в конфиг файлах, а часть в виде контента в CMS.
И поддержка этого всего — отдельное недешёвое развлечение.
K>Нужно всем гит разворачивать и в IDE код писать, а не всякие там WYSIWYG-редакторы.
Да, вы совершенно правы, WYSISYG — зло, которого взрослые люди стараются избегать.
Ну, то есть сам по себе WYSIWYG неплох, но ровно до тех пор, пока он не является единственным способом работы.
Никто не верстает HTML в WYSIWYG редакторах, кроме совсем уж начинающих. Весь авторинг разметки делается в текстовом режиме, и, желательно, на современном языке.

K>А в SQL-запросах параметры не нужны, нужно конкатенацией строк всё формировать, столько новых возможностей появится...
Что за бред?

K>Если нотификацию не предусмотрел разработчик, то никак не сделать.
Предусмотрел. А как же. Так и предусмотрел — сюда пишем кондишн, сюда пишем шаблон письма. Запускаем — и смотрим. Если заработало — то ок. А если не заработало — ну, удачи.
Просто ini-файл — не лучший способ для описания предикатов.

K>А в Майкрософт идиоты всякие оснастки *.msc делают. Не знал, что админы те же групповые политики вручную в блокнотике пишут и раскидывают по нужным папкам.

K>Сам вот грешен — предпочитал всякими gpedit пользоваться, а не вручную "конфиги" заполнял.
K>Ну, и странно, что скриптование на шелле просят, а не на шарпе.
Просят на чём угодно. В наличии — выбор между убогим cmd и повершеллом, который проектировали супремасисты, считающие админов низшей расой.
K>Дайте файлы конфигурации — это дайте нам готовые файлы и скажите куда их положить или же: дайте нам документацию на сотню страниц и мы с нуля напишем конфигурацию в IDE с компилятором и всем таким?
А почему такая дихотомия-то? Вот вам готовые файлы, класть сюда. Можете их редактировать блокнотиком и молиться перед запуском; можете открыть в IDE и иметь автодополнение и проверку ошибок.

K>Пока изменение конфига заключается в заполнении адресов сервера в указанные места, примерно всё равно что там за формат.
K>Писать же с нуля сотни и тысячи строк конфига неудобно в любом формате.
Ок, я вижу, чего вы не понимаете. Сотни тысяч строк образуются не единомоментно. Сначала у нас маленькая понятная система; потом в неё добавляется чуть-чуть гибкости; потом добавляются новые требования, и т.п. Всем нравятся такие системы, в которых требования можно реализовать настройкой. И вот у нас админы дописали чуть-чуть сюда, потом чуть-чуть туда, и вот у нас прошло пять лет — и в этом конгломерате уже хрен разберёшься.
И каждое примитивное изменение типа "давайте добавим вот такой товар в каталог" занимает месяц, потому что (в отличие от программистов с их CI и исходниками) мы всё это делаем в гуе вручную, а потом прогоняем ручные же визуальные тесты.

K>т.е. вы заказчику дали тул, которым сами же не можете пользоваться и не смогли настроить своё же ПО.
Я не понимаю, как вы сделали этот вывод. Он неверен.
K>В итоге проблема в GUI-оболочке для выставления галочек, а вручную те же люди конечно же написали бы в конфиге правильный код на шарпе и всё было бы хорошо?
Ну конечно. Для каких-то отдельных кусков продукта сделаны скрипты, которые "выставляют галочки" программно, на основе некоего декларативного JSON-конфига.
Этот JSON-конфиг порождается из Excel, навелосипеженного мимо конвеера разработки.
Предполагался в качестве "временной меры", которая поможет заткнуть дыру на пару месяцев, пока платформа рожает аналогичный инструмент в универсальном варианте. Прошло пять лет, вот этот велосипед пользуется колоссальной популярностью и регулярно порождает вопросы от заказчиков про другие части продукта — типа "а вот тут можно также сделать"?

K>Заказчик запрещал в программе с галочками сделать валидацию конфига?
Это в общем случае невозможно. Процедурное порождение корректного конфига в разы проще валидации некорректного.

K>У вас одна сборка и отладочные методы со всякими моками тоже заказчику отдадите?
Нет, отладочных методов мы заказчику не отдаём. А какая разница?

K>Ну, там в банке админ сможет поправить конфиг на 5 минут, чтобы перенаправить нотификацию на почтоуловители и перевести на свою карту с каждого счёта по рублю при помощи какого-нибудь отладочного метода, а потом вернуть всё как было?
Админ в банке может это сделать безо всяких отладочных методов. Другой вопрос, что останутся следы, и таких админов время от времени успешно ловят.

K>Чтобы больше соответствовало продакшену и нужно, чтобы различия были в виде IP-адресов, строк подключения к БД и т.д.
K>А если там какие-то конфиги на шарпе, которые делают совершенно разные вещи, то тест и продакшен ничего общего не имеют получается.
Речь идёт о том, что когда у нас есть более-менее развитый текстовый конфиг, то мы можем распилить его на части удобным для эксплуатации образом.
И, к примеру, настройки плана счетов у нас будут лежать в одном файле, а настройки подключения к пеймент-гейтвею — в другом файле. И первый у нас будет реплицироваться со стейджинга на продакш, а второй — нет, не будет.

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

Здравствуйте, karbofos42, Вы писали:
K>Как нам в этом поможет одинокий cs-файл? Откуда появится валидация и т.д.?
K>Или в каком виде предполагаются конфига на шарпе пользователям отдавать?
Например, так:

using BenchmarkDotNet.Configs;
public class Config : ManualConfig
{
  public Config()
  {
    Add(new Job1(), new Job2());
    Add(new Column1(), new Column2());
    Add(new Exporter1(), new Exporter2());
    Add(new Logger1(), new Logger2());
    Add(new Diagnoser1(), new Diagnoser2());
    Add(new Analyser1(), new Analyser2());
    Add(new Filter1(), new Filter2());
  }
}

Или так:

using BenchmarkDotNet.Configs;
public class Config : IConfig
{
  public Config GetConfig()=>
    DefaultConfig.Instance.AddJob(Job.Default.WithRuntime(ClrRuntime.Net461))
                          .AddJob(Job.Default.WithRuntime(CoreRuntime.Core21))
                          .AddValidator(ExecutionValidator.FailOnError));
 
}

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

S>Ну, так это же попытка добавить семантику туда, где её изначально не было.

Это не попытка, это готовая и работающая технология.

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

Это все просто эмоции, не обладающие объективной ценностью.

S>На всякий случай напомню, что схемы эти существуют строго в теории

Они существуют строго на практике.

S>Никакой возможности проверить, скажем, что настройка логгера ссылается на существующий логгер, нету, и не предвидится.

Компилятор шарпа такое тоже не сможет проверить, потому что ему будет доступен только абстрактный ILogger.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

K>конфиг должен быть только конфигом, а не нести в себе какую-то логику

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

K>Как нам в этом поможет одинокий cs-файл? Откуда появится валидация и т.д.?
K>Или в каком виде предполагаются конфига на шарпе пользователям отдавать?
в пример Sinclair конечно для админа может быть несколько сложновато, но можно как-то так


public class Config: IConfigurable
{

  public void Configure(cfg: IAppConfig) {
    
    //ниже содержательная часть. и вот ниже не сложнее ini файла, +все фишки: интелисенс, проверка компилятора
    cfg.MailServiceDir = "....";
    cfg.MailServiceEnabled = false; 

  }

}

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

а продвинутый админ, вообще может навернуть не подетски — завернуть в функции группы настроек, разрулить сложные зависимости, и тп.

НС>И я на это сразу написал — если настройки можно написать в коде, то нет никакого смысла выносить их в конфиг. А если нужно имнено в конфиге, то динамическая компиляция cs кода на лету приносить больше проблем, чем пользы и выглядит кривой заменой нормального расширяемого API и внятного CD.
"Нормальный расширяемый API" категорически неудобен для небольших правок. Клиент хочет формулу ситуативно поменять буквально на сутки, а я ему "Вы должны взять Visual Studio, создать проект, подключить наши сборки, прочитать доку по созданию аддона, собрать свою dll, положить рядом, и т.д. Кстати, обновить dll аддона если она загружена дейтсвующим приложением никак — система держит файл. А теперь оцените наш расширяемый API по 5-и бальной шкале

".

Конфиг в cs-коде — даёт простоту конфигурирования простых настроек, и возможность конфигурирования ну очень сложных, вплоть до скриптования каких-то частей приложения. Для меня это польза. Другие виды конфигов даже близко такой гибкости не дают.

Ты пишешь что проблем от компиляции cs-кода больше. Кроме проблемы с безопасностью я как-то других проблем не вижу

Безопасность это конечно хорошо и важно, но если хакер получит возможность писать в файлы — стандартный дотнетовский конфиг настолько же опасен насколько и cs-код. Через секцию "добавить логгер из такой-то dll" и ей подобные, можно любую хрень загрузить. Не вижу большой разницы.

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

MH>3. стандартный в .net подход с appsettings.

для корэ. позволяет выделять настройки в отдельные файлы. 1 класс <-> 1 json.
нюанс, если настройка должна изменяться (например, время последней успешной операции) это уже не настройка,
и для изменяемых "настроек" я бы сразу использовал БД т.к. в конечном итоге настроек становится много
и есть такие ситуации когда при зависании пк его перегружают и на выходе пустой xml файл с настройками.
Т.е. дотнет вроде записал в файл (видно по размеру), а кэш видимо не сброшен на диск.
С БД таких косяков не встречал.

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

MH>>в каком формате хранить?
_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода.

Нет такой альтернативы — конфиг или код. Если тебе не нужно менять настройки после компиляции — нет никакого смысла хранить их во внешних файлах. Если нужно — код в принципе не подходит.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration

MH>в каком формате хранить?

xml, json или yaml. Первый наиболее богат инструментами, второй более менее сейчас принят, третий — модно и молодежно, хотя более грабельный формат еще поискать.

MH>но на практике не особо ощущается т.к. в том же ini-файле вложенность вполне ок можно эмулировать за счет имен секций [system.limits]

Хочется тебе ini файлы в 2021 году — кто ж тебе запретит? Непонятно только что ты хочешь тут услышать.

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

См. выше.

MH>3. стандартный в .net подход с appsettings.
MH>у меня не пошел.

Поздравляю. Тот же вопрос — что ты хочешь тут услышать в ответ?

MH>много церемоний, сложнее понимать.

Пару строк кода это много церемоний? Ну ОК.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

В>yaml

Аргументы есть? Или как обычно?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет такой альтернативы — конфиг или код. Если тебе не нужно менять настройки после компиляции — нет никакого смысла хранить их во внешних файлах. Если нужно — код в принципе не подходит.
Схренабы? Кто-то отменил compile on the fly?

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

MH>>в каком формате хранить?
_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение. Основной плюс — раз в квартал надо прямо на проде сделать что-то очень экзотическое, и это всегда получается

TG>А можно пример, пожалуйста?
Чего именно?

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

_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода.
с моей тз минус — нельзя сделать хот релоад. хотя если поприседать может и можно..

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

S>почему это "дурь" — решительно непонятно.

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

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

K>Это такая 1-апрельская шутка штоле??

5k звезд на гитхабе, массово применяется в серверном софте, де факто стандарт для Scala разработчиков, просачивается и в Java.

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

K>Потому что конфиг — это вообще не про код. Код должен быть в программе, а в конфиге — лишь "настроечные величины". Если ты налепил конфиг в виде кода, ты явно решил задачу левым путём. Времена ЛИСПа прошли и не потому, что ЛИСП устарел — он просто непригоден для надёжного ПО — как раз в силу идеи "данные как код".
Очень странный набор необоснованных утверждений.
Что такое "настроечные величины"? Начинается всё обычно невинно: ну там, "номер порта, на котором слушать", "фолдер, куда складывать логи".
Потом постепенно вырастают идеи типа "а давайте у нас приложение будет поставляться в виде набора универсальных кубиков, которые мы будем склеивать в рантайме в соответствии с конфигурацией".
Начиная от "запросы по адресам '/users/*' будет обрабатывать UserRequestHandler, а по адресам '/dicpics/*.png' — StaticContentHandler", и заканчивая "на форме UserProfileForm в координатах 100, 200 разместить кнопку размером 128*32 с текстом 'Ok', по нажатию выполнить метод UserProfileForm.OnOkClick".
И вот — не успеешь оглянуться, а у тебя целый язык описания конфигураций; исходники на нём занимают мегабайты. Вот только тулчейна для него либо нет никакого, либо есть заведомо убогий.
Вот, покажите мне рефакторинг тул для веб конфига, который бы умел "перенести правило на уровень выше" или, наоборот "перенести правило на уровень ниже". Или "разделить правило на два". Нету, увы.
Почему? Потому, что это отдельный xml-based недоязык для конфигурации.

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

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

MH>2. противоположный 1-му подходу. на старте создаем некий IConfigProvider и далее через него все подсистемы сами читают что им нужно.
MH>+ каждая подсистема сама читает нужные настройки, при возникновении в ней новых — не надо править центральное место.
MH>- нет единого места, где все перечислены (хотя можно доку написать и поддерживать).
MH>что показывает практика, что лучше в долгую в среднем/большом проекте? единый класс-конфиг или каждый читает сам что нужно?
MH>3. стандартный в .net подход с appsettings.
MH>у меня не пошел. много церемоний, сложнее понимать.

А в чем проблема совмещать 2 и 3 -- каждую секцию вычитывать своим IConfigProvider из одного файла appsettings?

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

MH>>в каком формате хранить?
_>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода. При старте конфиг компилируется и запускает всё приложение.
а чем отличается от варианта 1 ?

1. где-то заранее (в Startup/Init) читаем в спец класс-конфиг (в нём каждая проперть соотвествует какой-то конфиг-настройке).

по сути тоже — есть в итоге код (класс с пропертями), но более безопасно.
обычно в конфиге значения, логики нет... или у вас есть? зачем?

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

S>Начиная от "запросы по адресам '/users/*' будет обрабатывать UserRequestHandler, а по адресам '/dicpics/*.png' — StaticContentHandler",

Совершенно стандартная фича взрослого веб-сервера. И все они как то обходятся без компиляции кода.

S>и заканчивая "на форме UserProfileForm в координатах 100, 200 разместить кнопку размером 128*32 с текстом 'Ok', по нажатию выполнить метод UserProfileForm.OnOkClick".

А это уже выводит систему в совершенно иной класс, и там, возможно, компиляция шарпа будет относительно оправданной. Хотя популярно для такого обычно что то динамическое на ноде, питоне или руби.

S>И вот — не успеешь оглянуться, а у тебя целый язык описания конфигураций; исходники на нём занимают мегабайты.

Тут уместна пословица про стеклянный пенис.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

S>>А в чем проблема совмещать 2 и 3 -- каждую секцию вычитывать своим IConfigProvider из одного файла appsettings?

НС>Он жен написал, "у меня не пошел". Что тут можно обсуждать?

Не пошел отдельно 3, а вот в связке 2+3 может и пошло бы.

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

НС>>Он жен написал, "у меня не пошел". Что тут можно обсуждать?
S>Не пошел отдельно 3, а вот в связке 2+3 может и пошло бы.

Озвученные причины: "много церемоний, сложнее понимать". В связке с п.2 эти причины только усугубляются.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

IT>Итого. Для добавления настройки разработчику необходимо добавить её в json файл и запустить Run Custorm Tool для сообтветствующего T4, после чего она готова к употреблению.

Это ты какой то велосипед придумал. Зачем настройки в РСУБД хранить? Зачем генерить класс по json?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

_>>Последние несколько моих (наиболее успешных) проектов хранят конфиг в виде C# кода.
MH>с моей тз минус — нельзя сделать хот релоад. хотя если поприседать может и можно..

С другой стороны, если твоя система в целом переживает перезапуск какой-то части, то заодно получаешь устойчивость к аварийным перезапускам отдельных компонент. И хот релоад при этом становится не слишком-то и нужным.

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

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

Тут как бы всё очевидно. Чем больше зависимостей у тебя в проекте, тем больше ты от них зависишь. Ты зависишь от их багов, кривых конфигураций, кособоких 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, так и кода.

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

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

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

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

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

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

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

Ещё один любитель получать граблями!

Поясняю как в школе:

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

Здравствуйте, 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 (или того же реестра), которые очень сильно влияют на логику приложения.
И в общем случае нет никакого способа проверить корректность этих конфигов. Отсюда стандартный способ починки того, что отвалилось — просто переставляем приложение; если не помогло — переставляем винду.

Здравствуйте, 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>Хороший вопрос. Разберусь — отвечу.

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

K>xml, json, ini — большинству айтишников знакомы и понятны. Добавить раздел в xml или json сможет любой в блокнотике.

K>Чем ему поможет, если конфиг будет в виде какого-нибудь cs-файла с кодом на шарпе?

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

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

В случае настоящего языка программирования у нас есть компилятор, есть автопроверка кода в IDE, есть линтеры.

K>Админ может установить доверенное приложение в папку с запретом на запись рядовым пользователем, либо ограничить запуск только подписанных приложений.
K>Можно конечно и конфиг заблокировать.
S>>Вы хотите избежать ситуации, когда админом запускается код, принесённый не-админом? Этот аспект отличается для серверных и настольных приложений.
K>Я хочу избежать ситуации, когда админ вынужден давать лишние права "не админам".
K>Так я и говорю, что либо простой плоский ini/xml/json, либо отдельный человеческий инструмент, который даст пользователям нормально настроить программу

Для каких-то простых случаев, типа расположения окошек на экране, плоский текстовый файл, действительно, подойдёт.

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

K>Ну, значит программа на шарпе с использованием WPF и Entity Framework — это тоже некий конфиг

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

K>Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
В примитивных случаях — да. Но очень часто "залезают в конфиг" не только для изменения параметров, но и для штук типа "добавить вот такую форму ввода", или "добавить вот такую страничку в магазин".
И вот там-то начинается: 90% логики веб-магазина — как раз в страничках, и связях между ними.

Бенчмарк дотнет, к примеру, можно поконфигурить и через параметры командной строки. Но почему-то разработчики в основном пользуются нормальной конфигурацией на языке оригинала: https://benchmarkdotnet.org/articles/configs/configs.html

K>Если уж конфиг нужно часто менять и сильно дописывать, то никто разработчикам не мешает сделать GUI-тулзу для заполнения этого json c валидацией.
GUI тулза стоит дороже, чем интерпретатор своего простого ЯП. При этом она всё ещё не умеет ни копи-пейста, ни "сделай мне 10 вариантов с малыми отличиями друг от друга", ни сравнения версий.

Здравствуйте, karbofos42, Вы писали:
K>Писать же простыню кода на шарпе в блокнотике без компилятора и т.д. — это такое себе удовольствие не для программиста.
На чём основано это предположение?
Ну, то есть почему-то код на JavaScript в блокнотике без калькулятора вы писать согласны, а на CS — нет. Хотелось бы более развёрнутого описания причины.

K>Чтобы это работало, нужно, чтобы был установлен компилятор, IDE, и не отдельный файлик cs, а вполне себе целый проект с референсами на какие-то Assembly с интерфейсами для работы с API.
Компилятор у нас идёт как часть дотнета. IDE по-прежнему необязательна — если вас устраивает уровень "JSON в блокноте", то вы можете продолжать писать в блокноте.
K>Компания купила программу, а потом будут нанимать программиста, который её настраивать будет? Не админа своего попросит, а именно разраба?
Почему? Попросит админа.

K>А для сложных случаев, на мой взгляд, нужна уже какая-нибудь тулза, которая позволит это всё настроить без программирования и уже не так важно в каком виде "конфиг" хранится, т.к. вручную его никто не правит.
Вот "какая-нибудь тулза" и есть основное зло.

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

K>>>Что-то там дописывать будут только разработчики, а пользователи и админы всякие туда залезают обычно — поменять пути к файлам, изменить какие-то константы, добавить пару строчек копипастой из документации от разработчиков.
S>>В примитивных случаях — да. Но очень часто "залезают в конфиг" не только для изменения параметров, но и для штук типа "добавить вот такую форму ввода", или "добавить вот такую страничку в магазин".
S>>И вот там-то начинается: 90% логики веб-магазина — как раз в страничках, и связях между ними.

K>Какой-то странный сайт, что набор страниц правится в конфигах, а не в админке.

Проблема как раз в том, что набор страниц правится в админке. Это та самая "тулза", за которую вы так ратуете.
Вот только последствия применения этой тулзы крайне разочаровывают.
Например, невозможно понять, кто, когда, и зачем поменял набор страниц. Был бы текстовый конфиг — мы бы сделали blame и нашли бы коммит с комментариями. По ним можно было бы восстановить ссылку на issue в трекере, с историей обсуждений и принятых решений.
Например, крайне тяжело перенести набор страниц (или его часть) со стейджинга в продакшн. Кроме "открыть две админки на двух мониторах" и вдумчиво втыкать — способов нет. Был бы текстовый конфиг — был бы копи-пейст.
Например, настройка 100 почти одинаковых страниц стоит ровно в 100 раз больше, чем одной. И так далее.

Текстовый конфиг в этих сценариях рулит неимоверно. Вот только выпиливать его из JSON/ini/XML — то ещё удовольствие.

K>Конфиг же для того, чтобы настроить окружение под запуск ПО.
K>Прописать настройки подключения к БД, описать модули, которые должны подключаться и т.д. и т.п.
Опять: делаете ещё два шага — и у вас оказывается, что модули зависят друг от друга, и т.п. Конфиг начинает представлять собой декларативную программу, не оборудованную ни компилятором ни отладчиком.
Может, сразу начать с конфига на полноценном языке?

K>Параметры отображения окошек, шрифт и т.п. вещи — это настройки, которые в идеале меняются из программы, а не нужно по каким-то файлам лазить и менять в IDE имя шрифта.
Ну и пусть меняются, кто вам запретит?
K>Добавить какую-то логику — это уже скорее добавить плагин/модуль, вот он пусть будет в виде dll на шарпе, а в конфиге только добавляется запись о подключении этого модуля.
Не "добавить какую-то логику", а "сконфигурировать какую-то логику". "Пусть при наступлении условия X отправляется письмо по адресу f(X) с текстом g(X)". Как вы сделаете такую штуку в ini файле?
Или предлагаете для каждой нотификации обращаться к разработчикам исходной системы?

K>Да я и для Cake без особых проблем код писал и даже без компиляции и проверки синтаксиса, только это всё для разработчиков, а не для пользователей.
K>Ну, не упёрлось админам и прочим людям изучать какие-то там DSL, писать код на каких-то там ЯП.
По факту они уже пишут код на DSL. И изучают эти DSL каждый раз с нуля, и пользуются им без IDE.
Более того, админы как раз плюются от графических тулзов — это одноразовым пользователям подавай гую. А админы говорят "дайте нам файлы конфигурации и скриптование на шелле".

K>Так и вижу админов крупного предприятия, ставят одну программу — там конфиг на Java, вторую — на C#, третью — скрипт на PowerShell, ...
По факту — так и есть.
Потому что один XML конфиг отличается от другого XML конфига примерно так же, как JavaScript от Go — скобочки одинаковые, всё остальное разное.

K>И ни для чего нет нормального инсталлятора, бери архив и допиливай напильником до рабочего состояния и изучай все эти ЯП, ставь компиляторы, IDE,...
А это-то почему?

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

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

НС>Вот о чем я и говорю. Основная проблема велосипедов — шаг в сторону и мы вынуждены продолжать велосипедить. В то время как если бы мы взяли хотя бы штатный конфиг кора, то автоматом получили бы возможность поменять имя провайдера просто выставив переменную среды log4net_appender_type.
Во-первых, у вас опечатка

Во-вторых, не вижу проблемы сделать аналог такого поведения в случае написания конфига на .cs.

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

S>Во-вторых, не вижу проблемы сделать аналог такого поведения в случае написания конфига на .cs.

Именно это и называется велосипедостроительством. Пока Вилла Риба прикручивает очередную детальку к своему велосипеду, Вилла Баджо уже релизит проект.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если не жахаться с модными и молодежными json и yaml, то для xcml есть схема, которая большую часть валидации вполне позволяет описать, и она поддерживается любым приличным редактором.
Тут, наверное, опечатка? Имелся в виду XML?
Ну, так это же попытка добавить семантику туда, где её изначально не было.
То есть сначала выбираем говноформат, неудобный ни для людей, ни для компьютеров, а потом мужественно прикручиваем к нему схему.
На всякий случай напомню, что схемы эти существуют строго в теории — ну, то есть, для каких-то популярных продуктов вы найдёте схему конфига. А для custom section — нет, не найдёте.
Так то и для JSON в теории существуют схемы — затруднился бы ещё кто-то их сесть и написать.

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

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

S>Здравствуйте, karbofos42, Вы писали:
K>>Мне все эти js и не нравятся тем, что нужно в блокнотике всё писать и ловить в рантайме, только я хотя бы учился на программиста, а не админ/пользователь, которому внезапно приходится этим заниматься.
S>Ну, так и XML с ini ничуть не лучше.

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

K>>И админ выучит шарп и с нуля накатает конфиг? Или его и хватит только на то, чтобы в готовом конфиге адрес сервера изменить?
S>Зачем с нуля? С нуля у вас пользователь и .ini файл вряд ли накатает. Там же надо синтаксис знать

S>А в готовом конфиге адрес сервера правится примерно одинаково — что в ini, что в JS, что в XML, что в CS.

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

K>>Осталось людям рассказать, что всякие там CMS не нужны и в них нельзя права раздавать и логи вести.
S>Права ортогональны обсуждаемому вопросу. И большинство сайтов, "написанных" на CMS, страдают ровно от этих же проблем.
S>Потому что у вас часть "конфигурации" живёт в каталоге товаров, часть в конфиг файлах, а часть в виде контента в CMS.
S>И поддержка этого всего — отдельное недешёвое развлечение.
K>>Нужно всем гит разворачивать и в IDE код писать, а не всякие там WYSIWYG-редакторы.
S>Да, вы совершенно правы, WYSISYG — зло, которого взрослые люди стараются избегать.
S>Ну, то есть сам по себе WYSIWYG неплох, но ровно до тех пор, пока он не является единственным способом работы.
S>Никто не верстает HTML в WYSIWYG редакторах, кроме совсем уж начинающих. Весь авторинг разметки делается в текстовом режиме, и, желательно, на современном языке.

Был бы на этом форуме WYSIWYG редактор сообщений — это было бы в разы удобнее, чем сначала вбивать код, а потом на предпросмотре перепроверять, что цитирование не поплыло.
Вёрстка шаблона разработчиком — это одно, но не будешь же заставлять менеджеров писать html разметку, чтобы добавить новый товар в интернет-магазин.

K>>А в SQL-запросах параметры не нужны, нужно конкатенацией строк всё формировать, столько новых возможностей появится...
S>Что за бред?

конфиг в cs для меня примерно эквивалентом является.
Что в одном случае появляется возможность всяких sql injection, что в другом случае программа подгружает неизвестный код из отдельного файла.

S>Ок, я вижу, чего вы не понимаете. Сотни тысяч строк образуются не единомоментно. Сначала у нас маленькая понятная система; потом в неё добавляется чуть-чуть гибкости; потом добавляются новые требования, и т.п. Всем нравятся такие системы, в которых требования можно реализовать настройкой. И вот у нас админы дописали чуть-чуть сюда, потом чуть-чуть туда, и вот у нас прошло пять лет — и в этом конгломерате уже хрен разберёшься.
S>И каждое примитивное изменение типа "давайте добавим вот такой товар в каталог" занимает месяц, потому что (в отличие от программистов с их CI и исходниками) мы всё это делаем в гуе вручную, а потом прогоняем ручные же визуальные тесты.

Просто на мой взгляд под конфигом понимается слишком обширная область и она слишком много всего делает.

K>>У вас одна сборка и отладочные методы со всякими моками тоже заказчику отдадите?
S>Нет, отладочных методов мы заказчику не отдаём. А какая разница?

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

K>>Чтобы больше соответствовало продакшену и нужно, чтобы различия были в виде IP-адресов, строк подключения к БД и т.д.
K>>А если там какие-то конфиги на шарпе, которые делают совершенно разные вещи, то тест и продакшен ничего общего не имеют получается.
S>Речь идёт о том, что когда у нас есть более-менее развитый текстовый конфиг, то мы можем распилить его на части удобным для эксплуатации образом.
S>И, к примеру, настройки плана счетов у нас будут лежать в одном файле, а настройки подключения к пеймент-гейтвею — в другом файле. И первый у нас будет реплицироваться со стейджинга на продакш, а второй — нет, не будет.

Если этот конфиг лежит у разработчиков, используется для сборки и конечному пользователю не отдаётся — это одно.
Если же конфиг отдаётся как код на шарпе конечному пользователю и он может написать там что угодно — это совсем другое.

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

Лично я люблю, когда всё работает из коробки и мне не нужно разбираться в каких-то конфигах. В идеале — пошаговый мастер какой-нибудь, в котором можно указать параметры окружения (БД, папки какие-то и т.д.).
В плане админства важно только знать что и как бэкапить и разворачивать на другом железе (будет обидно, если делал бэкап только БД, надеясь, что программу просто с нуля потом поставить можно и скормить ей восстановленную БД, а потом окажется, что для программы нужен ещё какой-то конфиг, в который 5 лет кто-то что-то там писал и это теперь пропало и программа не загрузится, т.к. БД сформирована тем конфигом и другим не читается).
Примерно никогда не возникало желания что-то вообще настраивать.

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

НС>Компилятор шарпа такое тоже не сможет проверить, потому что ему будет доступен только абстрактный ILogger.
Запросто сможет. Definite assignment, type compatibility.

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

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

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

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

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

Не понял, какая связь с конфигами? То что ты говоришь в кубере обеспечивается startup-пробами, механика совершенно конфигам ортогональная. При этом, внезапно, чтобы "прозвонить" как ты говоришь зависимости нужны их адреса, а они, внезапно, хранятся в конфигах. Поэтому до начала работы с конфигом "прозвонить" у тебя ничего не получится.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

НС>Не понял, какая связь с конфигами? То что ты говоришь в кубере обеспечивается startup-пробами, механика совершенно конфигам ортогональная. При этом, внезапно, чтобы "прозвонить" как ты говоришь зависимости нужны их адреса, а они, внезапно, хранятся в конфигах. Поэтому до начала работы с конфигом "прозвонить" у тебя ничего не получится.

Если проблема с конфигом, startup-пробы не завалятся?

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

НС>Зато с точки зрения анализа требований должно быть понятно, что если нам надо и коробочных пользователей окучивать, и тех самых citizen developers, то крайне неудачная идея пытаться для них сделать единый набор ручек. Слишком сильно разнятся требования, в результате либо мы фигово окучим кого то одного, либо обоих. В исходном варианте у вас пострадали вторые. Ты предлагаешь, чтобы страдали первые. Единственный вариант хорошо сделать обеим категориям — сделать многоуровневый инструментарий.
Если чо, категория "первых" в лично нашем продукте не существует вовсе. Несколько лет назад была такая инициатива, "а давайте сделаем урезанную коробку, которую можно поставить при помощи ГУИ-визарда и чтобы влезла в один сервер". Через некоторое время продукт был закрыт, за отсутствием платежеспособного спроса.
Поэтому я совершенно не против того, чтобы страдали некие несуществующие в природе "первые".

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

НС>Правильное решение в нашем новом продукте. Ты ставишь коробку, и большое количество типовых сценариев (причем оптимизированных для конкретного рынка) ты получаешь из коробки. Если что то не устраивает — ты можешь в визифиге покрутить настроечки. Если мало — можешь свою настройку в том же визифиге собрать с использованием своих данных и ML. А если и этого мало — REST API тебе в руки.
Ну штош. Хорошо, коли так.
НС>Еще как является. Проверено на практике.
Ну, при этом почему-то оракл, требующий сертифицированного инженера для запуска, много лет отгружал MS SQL, которого мог поставить студент. Несмотря на TPC-C и прочие технологические превосходства.

НС>Поэтому рынок сперва изучается. Интервью крупных заказчиков, публичная демонстрация MVP, даже специальный demo-продукт. И если понятно что интеграторов выгоднее послать и работать с заказчиками напрямую — это и следует сделать.
Расскажите об этом 1с.

НС>Но мы очень далеко уже ушли от конфигов. Если спустится на уровень кода, а не продукта, то вот у меня в проект есть совершенно четкое разделение настроек в коде, которые обычно делаются в Startup-классе вызовом .Configure без указания секции или AddOptions, и те настройки, для которых таки есть в IConfiguration соответствующая секция. В последние что то выносится только явным указанием в требованиях на основе анализа конкретных use cases.
НС>В таком раскладе уезжание в конфиг развесистых соплей со сложной логикой, как в твоем примере, вызовет вопросы еще на этапе написания диздоков, а не улезет в готовый продукт. И, скорее всего, до кода дело даже не дойдет, не говоря уж про применение костыле в виде компиляции шарпового кода на лету, которые все равно не совместимы нормально с типичной инфраструктурой конфигурации кластера в виде всяких куберовских конфигмапов или того же консула, и совершенно точно не совместимы с современными требованиями безопасности (хрен ты свои конфиги на полноценном языке сертифицируешь по ISO27001 и SOC2).
Ну, хорошо, коли так. Рад за вас.

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

_>Но вот что ты будешь делать, если клиент скажет — "У нас в модуле XXX случается крэш раз в два дня. Потери ацкие. Надо чтобы после крэша приложение стартануло, посмотрело через API через которые оно работает 'на каком оно свете', и если всё хорошо — то запустило модуль XXX считать заново, а если всё плохо — запустило 'процедуру восстановления'".

_>Или ещё была ситуация — приложение расчитано на бесперебойную работу и слушать определённый порт анонсированный в паблик, но клиенту понадобилось странного — рестарты раз в сутки, минимум простоя и видимость бесперебойной работы. И вот хочет он "а сделайте что-бы данные мигрировали из процесса А который будет закрыт, в процесс Б". Для нас это выливается в "при старте процесс Б сигналит процессу А. Тот закрывает порт 3333, передаёт снэпшот процессу Б. Б проверяет что полученный снэпшот верный, после чего открывает порт 3333, грохает А, и готов продолжать работу".

Это все очень сложно назвать конфигами, тем более что правишь код ты сам. Это больше похоже на некий доморощенный CD.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

S>Если чо, категория "первых" в лично нашем продукте не существует вовсе.

Ну вот и в нашем старом продукте тоже не существует. В результате имеем что имеем, спрос на рынке мы им покрыть не можем.

S>Поэтому я совершенно не против того, чтобы страдали некие несуществующие в природе "первые".

Тогда зачем вам вообще какие то конфиги? Пишите нормальный шарповый код, а для citizen developers сделайте нормальный API.
Смысл конфигов именно в настройке коробки, а не изготовлении из коробки кастомного решения.

НС>>Еще как является. Проверено на практике.
S>Ну, при этом почему-то оракл, требующий сертифицированного инженера для запуска, много лет отгружал MS SQL, которого мог поставить студент.

Традиции на том рынке очень сильны.

НС>>Поэтому рынок сперва изучается. Интервью крупных заказчиков, публичная демонстрация MVP, даже специальный demo-продукт. И если понятно что интеграторов выгоднее послать и работать с заказчиками напрямую — это и следует сделать.
S>Расскажите об этом 1с.

А что 1С? Они не пытаются делать конфиги, они дают полноценную IDE.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

НС>Это все очень сложно назвать конфигами, тем более что правишь код ты сам. Это больше похоже на некий доморощенный CD.
Ну я правлю только "экзотические случаи раз в пол-года", собственно сразу это и написал.

Простые настройки видны у клиента в приложении. Что-бы поменять где-то там 20 на 30 или настроить какие нотификации куда получать, в конфиг ручками лезть не надо. Страница настроек рослином грузит единственный cs файл в отдельный workspace, рендерит в нём пару методов, где лежат настройки вида name=value, и пишет всё назад.

Клиентские админы/девопсы/программеры делают настройки по-сложнее. То что из приложения настроить никак, но можно сделать глядя на другие части конфига или в документацию.

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

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

_>Простые настройки видны у клиента в приложении. Что-бы поменять где-то там 20 на 30 или настроить какие нотификации куда получать, в конфиг ручками лезть не надо. Страница настроек рослином грузит единственный cs файл в отдельный workspace, рендерит в нём пару методов, где лежат настройки вида name=value, и пишет всё назад.

И я на это сразу написал — если настройки можно написать в коде, то нет никакого смысла выносить их в конфиг. А если нужно имнено в конфиге, то динамическая компиляция cs кода на лету приносить больше проблем, чем пользы и выглядит кривой заменой нормального расширяемого API и внятного CD.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

НС>Тогда зачем вам вообще какие то конфиги? Пишите нормальный шарповый код, а для citizen developers сделайте нормальный API.
Ну, ещё лет через 10 мы к этому, возможно, придём. Правда, не к шарпу — а вот к нормальному API, возможно, и получится.
НС>Смысл конфигов именно в настройке коробки, а не изготовлении из коробки кастомного решения.
Ну вот вопрос границы между настройкой коробки и изготовлением кастомного решения является философским.
Вот IIS — это коробка или нет?
MS Reporting Services — это коробка или не коробка?

НС>Традиции на том рынке очень сильны.
Я в своё время читал истории про то, как это работало — и как раз то, что оракл такой тяжёлый, давало ему преимущества среди интеграторов.
Удивительным образом оказывается, что то, что мы, инженеры, считаем "коробкой", очень большая часть рынка считает "услугой".
Типа для нас Microsoft Word — это коробочный продукт, который можно купить просто на кассе в best buy.
А почти вся индустрия это делает как "мы аутсорсим IT-услуги местной компании, они нам и железки покупают, и Exchange c Active Directoty настраивают, и лицензии на софт покупают".
Поэтому когда MS перетаскивает потребителей в облако, она целится не в самих потребителей (они вообще могут не в курсе быть, что их почта теперь не на локальном Exchange, а на outlook.com), а в тех самых интеграторов.
Это интегратор перестаёт покупать коробку, и начинает покупать "повременную лицензию".
И вот тут и начинаются игры парадоксов: скажем, зачем интегратор будет ставить людям open office? Им выгоднее продавать продукт от MS — он платный, с него маржа есть.
Интегратор, который продал 100 лицензий на продукт MS, получает ~10% от суммы сделки. А то, что это fixed-term license, гарантирует ему не просто одноразовую сумму, а ежемесячные (или ежегодные) отчисления.
Интегратор, который поставил Open Office, не получит ничего — потому что 10% от нуля это ноль. И интегратор не сможет брать с клиента даже $1 в месяц за лицензию — ну, потому что это же бесплатный продукт!
НС>А что 1С? Они не пытаются делать конфиги, они дают полноценную IDE.
Всё верно. У них "конфигурация" — это часть решения, с нормальной поддержкой разработки этих конфигураций.
Они не пытаются "обойтись без professional services". Они наоборот, за счёт них существуют.

	От:	scf
	Дата:	22.03.21 15:24
	Оценка:	42 (2) -1

От:	IT	linq2db.com
Дата:	24.03.21 16:31
Оценка:	17 (4)

	От:	hi_octane
	Дата:	21.03.21 00:19
	Оценка:	11 (2) +2

От:	Pzz	https://github.com/alexpevzner
Дата:	28.03.21 12:59
Оценка:	4 (1) +1 -2

От:	Sinclair	https://github.com/evilguest/
Дата:	30.03.21 16:07
Оценка:	12 (1) +1

	От:	Ночной Смотрящий
	Дата:	06.04.21 10:31
	Оценка:	9 (1) +1

	От:	MadHuman
	Дата:	16.03.21 05:54
	Оценка:	6 (1) +1

	От:	karbofos42
	Дата:	31.03.21 04:12
	Оценка:	1 (1) -1

От:	bnk	http://unmanagedvisio.com/
Дата:	21.03.21 11:42
Оценка:	+2

От:	Carc	https://vk.com/gosha_mazov
Дата:	31.03.21 10:49
Оценка:	4 (1)

От:	Cheblin2	https://github.com/cheblin
Дата:	04.04.21 13:38
Оценка:	+1

	От:	Аноним931
	Дата:	06.04.21 12:13
	Оценка:	-1

	От:	Ватакуси
	Дата:	20.03.21 23:03
	Оценка:

	От:	varenikAA
	Дата:	29.03.21 03:27
	Оценка:	+1