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


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

Здравствуйте, 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 вариантов с малыми отличиями друг от друга", ни сравнения версий.

Здравствуйте, 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>Писать же простыню кода на шарпе в блокнотике без компилятора и т.д. — это такое себе удовольствие не для программиста.
На чём основано это предположение?
Ну, то есть почему-то код на 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>Зато при внедрении заказчик сам галочки натыкает, параметры своего окружения укажет и всё хорошо, а иначе к стоимости программы приплюсуется и стоимость программиста, который будет конфиг заказчику писать с использованием компилятора, подсветки синтаксиса и т.д.
Плавали, знаем. Вот я сейчас работаю в продукте, где как раз "заказчик сам галочки натыкает, продукт настроит, и всё хорошо". По факту, к стоимости программы плюсуются так называемые professional services, которые натыкивают галочки за заказчика. Рекорд скорости по натыкиванию за многие годы — три месяца. Обычно — от шести месяцев и до полуторых лет. Иногда галочки натыкиваются так, что через два года клиент говорит "давайте всё снесём, и поставим заново с нуля, т.к. ваши попытки исправить косяки в конфигурации меня уже задолбали". Как раз ровно имеем ситуацию "нечем провалидировать конфиг".

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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-адресов, строк подключения к БД и т.д.
А если там какие-то конфиги на шарпе, которые делают совершенно разные вещи, то тест и продакшен ничего общего не имеют получается.

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

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

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

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

Здравствуйте, 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>А если там какие-то конфиги на шарпе, которые делают совершенно разные вещи, то тест и продакшен ничего общего не имеют получается.
Речь идёт о том, что когда у нас есть более-менее развитый текстовый конфиг, то мы можем распилить его на части удобным для эксплуатации образом.
И, к примеру, настройки плана счетов у нас будут лежать в одном файле, а настройки подключения к пеймент-гейтвею — в другом файле. И первый у нас будет реплицироваться со стейджинга на продакш, а второй — нет, не будет.

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

Здравствуйте, 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 лет кто-то что-то там писал и это теперь пропало и программа не загрузится, т.к. БД сформирована тем конфигом и другим не читается).
Примерно никогда не возникало желания что-то вообще настраивать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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