SM
в любом место можно придумать боль. это не проблема формата, а проблема его применения.
Size: a a a
2016 March 15
PP
и кто теперь про велосипеды;)
Я про велосипеды. Я не хочу делать велосипед для чтения конфига.
PP
Велосипедов, внезапно, может быть много.
PP
И мне хочется на один меньше.
PP
Поэтому, я и говорю – если весь ваш софт идеален, я рад. У меня такого в жизни не было.
PP
(Ну разумеется, кроме петпроджектов, в которых, конечно же, я писал самый прекрасный код в истории человечества.)
SM
Разговор, напомню, начался с вопроса чтобы поиспользовать, а не конфиги каких форматов легче генерить велосипедом для непонятно какого софта
PP
Ну он им и остался. Я лишь сказал, что на практике оказывается болью.
PP
Вы думаете, что надо ini/yaml/whatever. Кто-то тоже думал.
PP
Конечно, если вы хотите поиспользовать конфиг с несколькими примитивными значениями, то проблем не будет.
PP
Когда вы говорите, что json никогда не должен использоваться для конфигов, то в реальной жизни софт авторов, считающих так же, оказывается болью.
PP
И всегда хотелось этих авторов спросить, что ими двигало.
PP
И надеюсь не "json для транспорта".
SM
Вот я тут https://telegram.me/spblug пользователям закинул про конфиги. Говорят, yaml
p
Еще здорово, когда фреймворк поддерживает несколько вариантов конфига. Ну, например, json, yaml и xml.
В некоторых ситуациях один из вариантов может быть более удачным чем остальные.
В некоторых ситуациях один из вариантов может быть более удачным чем остальные.
PP
Мне уже надоело. ) Как разработчик/инженер я буду работать с чем угодно. И я даже не буду хотеть сильно ругаться, если кто-то другой случайно стал причинять другим боль ("мы планировали развивать проект три месяца, а ему три года, 100500 sloc и деплой на кластер"). Но я никогда не пойму субъективных предубеждений на старте.
SM
а разве на старте в местах, где нет явных требований, бывает что-то кроме субъективности?
SM
если команда уже есть, то стек обычно выбирается по совокупному опыту команды, даже файл конфига
SM
с чем больше работали, то и ок, потому что легче избежать подводных камней
PP
Так требования всегда какие-то есть, и они почти всегда неполные. Дело в другом: бывают разные аргументы в выборе. "Конфиги должны быть такими, чтобы они могли реактироваться моим любимым sed'ом" – не очень хорошая причина. "Мы думаем, что нам не понадобится хранить в конфиге список" – получше.