Comments 14
UFO just landed and posted this here
Библиотека кстати называется Typesafe Config; это язык называется HOCON. И кстати, Typesafe Config — это go-to библиотека для конфигурации проектов на Scala, потому что многие популярные фреймворки и библиотеки, в частности, Play Framework и Akka, используют именно её.
ну примерно из за того же что описано в статье и использую HOCON
Примеры несколько странные, можно же написать проще, вместо:
{
s1 :
{
ip: “192.168.10.1”
}
s2 :
{
ip: “192.168.10.1”
}
s3 :
{
ip: “192.168.10.1”
}
}писать:
s1.ip = “192.168.10.1”
s2.ip = “192.168.10.1”
s3.ip = “192.168.10.1”и это будет тоже HOCON.
Добавлю, что важный недостаток (а иногда и нет) HOCON — это наличие include, но отсутствие require. Если конфиг, указанный по пути include не найден, он будет проигнорирован без каких-либо предупреждений. Так что будьте осторожнее.
Можно и так. Просто примеры купированные, в них опущено что в s1 помимо ip есть и другие параметры. В исходном варианте было как-то так
Кстати да, вместо двоеточия можно писать =, это как кому нравится.
Насчет того что include игнорирует пропуски, да я согласен что было бы неплохо иметь директиву с обязательным включением.
Семантика игнорирования missing files была задумана видимо как раз под описанный мной пример: когда в основном конфиге задаются все нужные параметры по умолчанию, а в опциональном дополнительном можно что-то если надо перекрыть.
s1:
{
ip = “192.168.10.1”
port = 123
database = "goodwin"
username = "root666"
password = "nobodyknows"
threadpool_size = 10
// и так далее
}
Кстати да, вместо двоеточия можно писать =, это как кому нравится.
Насчет того что include игнорирует пропуски, да я согласен что было бы неплохо иметь директиву с обязательным включением.
Семантика игнорирования missing files была задумана видимо как раз под описанный мной пример: когда в основном конфиге задаются все нужные параметры по умолчанию, а в опциональном дополнительном можно что-то если надо перекрыть.
> К чему городить весь этот огород вместо того, чтобы хранить свои конфиги в обычном JSON или XML?
Почему не хранить конфиги в скриптовом языке, например, javascript?
Почему не хранить конфиги в скриптовом языке, например, javascript?
Парсер HOCON — это маленькая библиотечка на Java, которая к тому же не тянет никаких зависимостей.
А если JavaScript — то в нашем случае это надо внутрь JVM, на которой наш сервер работает, целый JavaScript интерпретатор затаскивать.
Кроме того, описывать конфиги на JavaScript языке на мой взгляд все-таки не совсем удобно. Слишком широкие возможности, которые предоставляет полноценный скриптовый язык, могут привести к злоупотреблениям и чрезмерному усложнению конфигов.
Ну то есть при желании так сделать конечно можно, но я бы так делать не стал :)
А если JavaScript — то в нашем случае это надо внутрь JVM, на которой наш сервер работает, целый JavaScript интерпретатор затаскивать.
Кроме того, описывать конфиги на JavaScript языке на мой взгляд все-таки не совсем удобно. Слишком широкие возможности, которые предоставляет полноценный скриптовый язык, могут привести к злоупотреблениям и чрезмерному усложнению конфигов.
Ну то есть при желании так сделать конечно можно, но я бы так делать не стал :)
Есть и другие скриптовые языки, предустановленные на множестве систем (perl, bash, python), но тут скорее соглашусь.
А вот как это связано с увеличением сложности, я не понял. Ведь и на HOCON можно понаписать что-угодно, а любой интерпретируемый язык можно проверить статическим анализатором или еще кучей способов. Ведь, по-хорошему. конфиги тоже нужно тестировать.
Суть в чем, вот есть XML/JSON, при небольшой сложности всем устраивает, но вот понадобились переменные и уже нужно учить/выбирать новый язык, при следующем витке увеличения сложности — опять понадобится новый язык еще с чуть более расширенными возможностями. А это обучение, поддержка и т.д. Не проще ли сразу заложить один формат конфигурации и для простых схем, и для очень сложных, а контролировать формат отдельно для каждого проекта.
Интересует ваше мнение именно в контексте крупной компании, с множеством проектов, где важнее стандарты и единообразие?
А вот как это связано с увеличением сложности, я не понял. Ведь и на HOCON можно понаписать что-угодно, а любой интерпретируемый язык можно проверить статическим анализатором или еще кучей способов. Ведь, по-хорошему. конфиги тоже нужно тестировать.
Суть в чем, вот есть XML/JSON, при небольшой сложности всем устраивает, но вот понадобились переменные и уже нужно учить/выбирать новый язык, при следующем витке увеличения сложности — опять понадобится новый язык еще с чуть более расширенными возможностями. А это обучение, поддержка и т.д. Не проще ли сразу заложить один формат конфигурации и для простых схем, и для очень сложных, а контролировать формат отдельно для каждого проекта.
Интересует ваше мнение именно в контексте крупной компании, с множеством проектов, где важнее стандарты и единообразие?
Ну сначала о чисто бытовых неудобствах, которые мне видятся на пути подключения полноценных скриптов:
1. Они предустановленны, но не везде. Например мы в процессе разработки запускаем свои сервера на чем попало, в том числе и windows. Придется бегать и ставить скрипты там.
2. Предустановленная версия скриптов может не совпасть с требуемой. Или нестыковки в каких-то требуемых библиотеках, в путях, в переменных окружения.
3. Надо еще как то передать данные из скрипта в свою программу, а как? Первое что приходит в голову, скрипт печатает их в stdout, а программа парсит. Но тогда нужны какие-то соглашения о формате этих данных, чем-то печатать, чем-то парсить. То есть скрипт ещё не является готовым решением, надо еще строить мост между скриптом и родительской программой.
Если же сравнить эти телодвидения с HOCON, то нам надо всего лишь
1. Поключить библиотеку (с помощью maven или gradle это делается одной строчкой)
2. Вызвать функцию parseFile.
3. Profit. После этого мы получаем готовый объект из которого можно читать значения.
Теперь насчет сложности как языка. HOCON — это все-таки небольшая надстройка над JSON, с весьма ограниченными возможностями, которые решают вполне конкретную задачу. По сути это всё те же текстовые данные, но с возможностью прототипирования.
Когда делаешь конфиги на обычном JSON или XML, то основная проблема с которой сталкиваешься: дублирование данных. И хочется эти дубликаты как-то выносить в общее место и потом на них ссылаться. Собственно, HOCON с помощью прототипирования как раз и помогает это сделать.
А когда я говорю о сложности скриптов, то имею в виду, что скрипты — это все-таки вполне себе полноценные языки программирования: с условными переходами, с циклами, с библиотеками, с лямбдами и т.д. и т.п. И если дать все это богатство сисадмину, то есть опасение потом вместо конфигов увидеть целые программы, которые живут полноценной и насыщенной жизнью. И что в случае каких-то проблем придется сидеть и разбираться в этом богатстве, вплоть до отладки принтами.
HOCON же имеет те именно возможности, которые нужны для конфигов, не больше и не меньше. Он очень простой. Его изучение сводится к получасовому изучению мануала, после чего все более менее понятно и сразу можно работать.
Конечно, возможно в будущем опять окажется что чего-то не хватает, но пока что хватает. Одно из сильных достоинств HOCON — это его легковесность.
1. Они предустановленны, но не везде. Например мы в процессе разработки запускаем свои сервера на чем попало, в том числе и windows. Придется бегать и ставить скрипты там.
2. Предустановленная версия скриптов может не совпасть с требуемой. Или нестыковки в каких-то требуемых библиотеках, в путях, в переменных окружения.
3. Надо еще как то передать данные из скрипта в свою программу, а как? Первое что приходит в голову, скрипт печатает их в stdout, а программа парсит. Но тогда нужны какие-то соглашения о формате этих данных, чем-то печатать, чем-то парсить. То есть скрипт ещё не является готовым решением, надо еще строить мост между скриптом и родительской программой.
Если же сравнить эти телодвидения с HOCON, то нам надо всего лишь
1. Поключить библиотеку (с помощью maven или gradle это делается одной строчкой)
2. Вызвать функцию parseFile.
3. Profit. После этого мы получаем готовый объект из которого можно читать значения.
Теперь насчет сложности как языка. HOCON — это все-таки небольшая надстройка над JSON, с весьма ограниченными возможностями, которые решают вполне конкретную задачу. По сути это всё те же текстовые данные, но с возможностью прототипирования.
Когда делаешь конфиги на обычном JSON или XML, то основная проблема с которой сталкиваешься: дублирование данных. И хочется эти дубликаты как-то выносить в общее место и потом на них ссылаться. Собственно, HOCON с помощью прототипирования как раз и помогает это сделать.
А когда я говорю о сложности скриптов, то имею в виду, что скрипты — это все-таки вполне себе полноценные языки программирования: с условными переходами, с циклами, с библиотеками, с лямбдами и т.д. и т.п. И если дать все это богатство сисадмину, то есть опасение потом вместо конфигов увидеть целые программы, которые живут полноценной и насыщенной жизнью. И что в случае каких-то проблем придется сидеть и разбираться в этом богатстве, вплоть до отладки принтами.
HOCON же имеет те именно возможности, которые нужны для конфигов, не больше и не меньше. Он очень простой. Его изучение сводится к получасовому изучению мануала, после чего все более менее понятно и сразу можно работать.
Конечно, возможно в будущем опять окажется что чего-то не хватает, но пока что хватает. Одно из сильных достоинств HOCON — это его легковесность.
Вы все усложняете со скриптами. Не нужно ничего предустанавливать, согласовывать версии и парсить stdout. В джаве есть интерпретатор джаваскрипта.
Вот и все. Даже не нужно подключать внешних библиотек.
val engine = new ScriptEngineManager().getEngineByName("nashorn")
val config = engine.eval("""var config = {host: "localhost", port: 8080}; config""").asInstanceOf[ScriptObjectMirror]
println(config.get("host"))
Вот и все. Даже не нужно подключать внешних библиотек.
Принято.
Да, встроенный JavaScript убирает все инфраструктурные издержки.
Но увеличение сложности конфигов при использовании JavaScript все равно остается, а плюсов от дополнительных языковых возможностей в применении к конфигам я особо не вижу.
Впрочем, никто не мешает попробовать так сделать и потом рассказать о своем опыте. Я имею в виду не просто попробовать сделать в качестве эксперимента — понятно что так можно. Скорее интересен опыт долгосрочного использования, когда эти js конфиги отдаются на откуп админам, которые занимаются поддержкой системы, и они там на них что-то программируют.
Да, встроенный JavaScript убирает все инфраструктурные издержки.
Но увеличение сложности конфигов при использовании JavaScript все равно остается, а плюсов от дополнительных языковых возможностей в применении к конфигам я особо не вижу.
Впрочем, никто не мешает попробовать так сделать и потом рассказать о своем опыте. Я имею в виду не просто попробовать сделать в качестве эксперимента — понятно что так можно. Скорее интересен опыт долгосрочного использования, когда эти js конфиги отдаются на откуп админам, которые занимаются поддержкой системы, и они там на них что-то программируют.
Довольно интересно, спасибо. Надо будет посмотреть повнимательней на этот HOCON.
Sign up to leave a comment.
HOCON — конфигурируем гибко