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

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

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

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

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

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

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

Но если вдруг проблема с кубером встанет — куча народу обновляет на кубере всякие текстовые файлы через замену плейсхолдеров %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 — и я ему скажу — "вот этот кусок кода сунь в конец конфига, и будет работать".

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


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

public class Config: IConfigurable
{

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

  }

}

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

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

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

НС>Зато с точки зрения анализа требований должно быть понятно, что если нам надо и коробочных пользователей окучивать, и тех самых 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НС>Тогда зачем вам вообще какие то конфиги? Пишите нормальный шарповый код, а для 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". Они наоборот, за счёт них существуют.

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

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

Ну, хорошо, коли так. Рад за вас.

НС>>Смысл конфигов именно в настройке коробки, а не изготовлении из коробки кастомного решения.
S>Ну вот вопрос границы между настройкой коробки и изготовлением кастомного решения является философским.

Нет, если плясать от конкретных юзкейсов.
IIS, собственно, построен именно так как я и писал. В нем есть и web.config, и несколько разных API.

S>Вот IIS — это коробка или нет?

Отчасти, в зависимости от того что мы в нем хостим.

S>MS Reporting Services — это коробка или не коробка?

Нет.

S>Они не пытаются "обойтись без professional services". Они наоборот, за счёт них существуют.

Еще как пытаются. Есть совсем ненулевое количество инсталляций 1С, где никто ничего руками в конфигурациях не докручивал, а используют готовое решение. Особенно это касается не собственных конфигураций от 1С, которые традиционно довольно куцые (как раз чтобы кормить тех самых интеграторов, о которых ты пишешь), а сторонних, например каминовской зарплаты. Последняя обычно просто ставится и работает, а настраивается не в конфигураторе, а в настройках в рантайме (т.е. во вполне классическом "конфиге").

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

НС>IIS, собственно, построен именно так как я и писал. В нем есть и web.config, и несколько разных API.

Для IIS вообще отдельная оснаска для конфигурирования, web.config напрямую что-то подправить.

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

НС>>IIS, собственно, построен именно так как я и писал. В нем есть и web.config, и несколько разных API.
S>Для IIS вообще отдельная оснаска для конфигурирования, web.config напрямую что-то подправить.

Оснастка, если говорить об уровне от проекта и ниже, web.config и правит.

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

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

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

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

S>>Для IIS вообще отдельная оснаска для конфигурирования, web.config напрямую что-то подправить.
НС>Оснастка, если говорить об уровне от проекта и ниже, web.config и правит.

Ну да, поэтому я удивился, когда увидел web.config -- если что-то простенькое подправить,
иначе -- оснастка. Но у меня, к сожалению, опыта с asp (iss) практически нет, поэтому
исключительно теоретические соображения. Или это взаимозаменяемые понятия для мира .net?
Не у каждого app.config есть оснастка.

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

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

Это уж как спроектируешь.

_> Клиент хочет формулу ситуативно поменять буквально на сутки, а я ему "Вы должны взять Visual Studio, создать проект, подключить наши сборки, прочитать доку по созданию аддона, собрать свою dll, положить рядом, и т.д.

Слышал про CD? Там как раз эту задачу решают.