Конфиги и данные в виде исполняемого кода
я всеми руками за 
Поломать можно больше, чем через обычные конфиги.
Поломать можно больше, чем через обычные конфиги.
Пока видится затруднённость (невозможность) горячей подгрузки.а в чем проблема?
> а в чем проблема?
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.в java в чем проблема?
в питоне такое видел Отличная тема
Отличная темаНевыполнены оба пункта из допущений.
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
на SHell так и делают всегда
Невыполнены оба пункта из допущений.неужто в java нельзя динамически компилировать код, в .NET это делается через Emit
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
погугли на тему java dynamically compilation code
вот тут меняют текстовый файл с кодом, и приложение его подхватывает, по-моему, как раз то, что тебе хочется
http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynami...
Пункты-то не про это.
Можно динамически, да. Но вот полная сборка проекта существенно дольше и пропорциональна кол-ву данных (а их много, обычно сильно больше, чем кода).
И читаемость у java-кода не ахти для непосвещённого. А надо еще и писать, не только читать.
Можно динамически, да. Но вот полная сборка проекта существенно дольше и пропорциональна кол-ву данных (а их много, обычно сильно больше, чем кода).
И читаемость у java-кода не ахти для непосвещённого. А надо еще и писать, не только читать.
Какие минусы есть такого подхода?Как и у любой дырки, позволяющей выполнить левый код.
Встречал подобное в ruby-приложении, показалось интересным.что именно видели? дайте ссылочку\ключевые слова, пожалуйста, потому что не очень ясно о чем речь.
если речь о встраивании скриптового языка в приложение, то таким образом не каждый ресурс\данные можно запихать, да и проблемы с предоставлением песочницы могут быть, и не ясно какие возможности\ограничения накладывает такой метод определения входных данных, т.к. язык общего назначения
У меня на одной из работ так однажды сделали.
Рассадник трудноуловимых багов, руки надо отрывать за такое по-хорошему:)
Рассадник трудноуловимых багов, руки надо отрывать за такое по-хорошему:)
> Как и у любой дырки, позволяющей выполнить левый код.
Это следствие того, что почти забесплатно переносится часть логики исполнения в данные (что есть осознанный выбор разработчика
а защититься от исполнения левого кода достаточно легко единожды написанными проверками.
Это следствие того, что почти забесплатно переносится часть логики исполнения в данные (что есть осознанный выбор разработчика
а защититься от исполнения левого кода достаточно легко единожды написанными проверками.
вполне приемлемо, если допустим данные не очень секретные, но их надо спрятать от лишних глаз.
а вот конфиг - его же редактировать надо?
а вот конфиг - его же редактировать надо?
Я считаю что в таком случае следует называть конфиг — лоадером, например, и относится к нему соответственно, и оформлять его соответственно. То есть не "приложение делает import custom_config", а "custom_run делает import application; application.configure("zzz" application.run".
Я к этому отношусь сугубо положительно, например. А вот к исполняемым конфигам — совершенно не так положительно.
Я к этому отношусь сугубо положительно, например. А вот к исполняемым конфигам — совершенно не так положительно.
Совершенно нормально.
В скриптовых языках типа php такое используется повсеместно. А для bash'а так и вообще существует устоявшееся название "dot file" от команды ". my_config.sh".
Минусы/плюсы очевидны:
В скриптовых языках типа php такое используется повсеместно. А для bash'а так и вообще существует устоявшееся название "dot file" от команды ". my_config.sh".
Минусы/плюсы очевидны:
- (-) В "конфиге" будет частично код — нужно тщательнее тестировать код в связке с "конфигом" при деплое
- (-) Нужно следить за тем, чтобы девелоперы не начали в "конфиг" засовывать весь код
- (-) Не-девелоперам будет сложнее править конфиг
- (+) Не нужны парсеры и маппинг между конфигом в объекты
ещё в плюсы можно записать то, что распространять приложение можно одним исполняемым файлом (и конфиг, и ресурсы - всё в одном) - порой очень удобно.
Оставить комментарий
danilov
Пусть есть приложение, у него имеются конфигурационные данные и данные приложения (все, кроме бинарных).Допустим
1. Язык позволяет держать данные одновременно и human-readable и исполняемыми. То есть они преставляют собой код, написанный на языке.
2. Нет больших оверхедов на сборку проекта в таком виде.
Какие минусы есть такого подхода? Интерес исключительно праздный, Java для этого слишком непригодна. Встречал подобное в ruby-приложении, показалось интересным. Пока видится затруднённость (невозможность) горячей подгрузки. Но эта проблема есть и при разделённом подходе.