T🐜
не знаю короче. как по мне надо. потому что на проде эта опция (сборка) должна работать. А значит и у дева должен быть тот же самый конфиг. С той лишь разницей, что в деве не надо кешировать, а в проде надо.
Size: a a a
2020 August 14
T🐜
иначе как ты будешь гонять тесты? не зная работает там что-то или нет. по факту получается 2 разных билда приложения. с разными зависимостями.
NO
The Ant 🐜
есть еще скрытые от тебя параметры. Например время ответа страницы, сколько % процессора отъедает конкретно мердж конфигов, и соответственно сколько это будет стоить на тех же авс?
У меня есть некоторый опыт в оптимизации приложений. Плюс прошёл теоретический курс по хайлоаду.
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
AB
кешировать девелоперу не нужно, т.к. девелопер постоянно меняет конфиги
далеко не постоянно. можно ж время обновления файлов смотреть. но тут надо смотреть насколько тяжелый там мердж, может и не стоит того
RM
Есть кейсы, когда с разными схемами - разные роуты?
То есть http://my.site.com !== https://my.site.com
То есть http://my.site.com !== https://my.site.com
В общем думаю для secure-only роутов.
T🐜
У меня есть некоторый опыт в оптимизации приложений. Плюс прошёл теоретический курс по хайлоаду.
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
У меня тоже есть опыт оптимизации приложений.
И этот опыт подсказывает мне, что конфиг надо собирать.
Мердж в рантайме на каждый запрос это потенциально слабое звено. Не спорю, в бложиках на 30 чел\дейли это не существенно, но мне надо на пару кк\дейли (которые генерируют больше 20кк запросов на бекенд в день). И этот мердж становится проблемой.
И этот опыт подсказывает мне, что конфиг надо собирать.
Мердж в рантайме на каждый запрос это потенциально слабое звено. Не спорю, в бложиках на 30 чел\дейли это не существенно, но мне надо на пару кк\дейли (которые генерируют больше 20кк запросов на бекенд в день). И этот мердж становится проблемой.
DS
У меня есть некоторый опыт в оптимизации приложений. Плюс прошёл теоретический курс по хайлоаду.
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
NO
The Ant 🐜
Просто ты странные вопросы задаешь. Очень странные.
Хорошо заданный вопрос, если попытаться на него всерьёз ответить, часто указывает на логические ошибки, тому кто на него пробует ответить.
Но это конечно должен быть сознательный выбор, попытаться ответить на вопрос, а не просто сказать "он странный".
Но это конечно должен быть сознательный выбор, попытаться ответить на вопрос, а не просто сказать "он странный".
NO
ну ты просто расписываешься в своём незнании. собирание конфига неизбежная часть фреймворка и приложения. в yii2 это было размазано по нескольким местам в фреймворке
Предвзято. Ок. Я ламер и ничего не знаю.
А
У меня есть некоторый опыт в оптимизации приложений. Плюс прошёл теоретический курс по хайлоаду.
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
В целом лучшей практикой при оптимизации считается такой путь.
1. Делаем замеры, выясняем что именно тормозит
2. Когда доказано, что тормоза в месте "X", оптимизируем место "X".
3. Делаем замеры, убеждаемся, что более не тормозит.
Любая оптимизация без предварительных замеров и контрольных замеров, это тыкание вслепую с околонулевой эффективностью.
——————————————
Что из этого следует? Что проблема с мёрджем конфигов должна быть доказана и измерена, а также её решение аналогично доказано и измерено. Тогда можно говорить, что дескать плагин решает вопрос тормозящей сборки...
И у меня конечно есть вопросы.
1. А нужна ли сборка в принципе? Зачем?
2. А тормозит ли она? Есть вероятность что проблема переоценена.
3. Если тормозит, то как часто встречается эта проблема? У какого процента пользователей?
4. Учтены ли другие аспекты, такие как удобство чтения и редактирования конфига?
> 1. А нужна ли сборка в принципе? Зачем?
Тогда надо определиться с терминологией, что такое "сборка"
Если вопрос в том, нужен ли мерж - то ответ да, т.к. имеется необходимость переопределения ключей. Скажем, пустое значение в пакете переопределяется значением в приложении, затем переопределяется локальным конфигом.
Если вопрос в том, что надо ли мержить в один файл - скорее да, чем нет (есть ряд причин).
Может подразумевается что-то другое?
Тогда надо определиться с терминологией, что такое "сборка"
Если вопрос в том, нужен ли мерж - то ответ да, т.к. имеется необходимость переопределения ключей. Скажем, пустое значение в пакете переопределяется значением в приложении, затем переопределяется локальным конфигом.
Если вопрос в том, что надо ли мержить в один файл - скорее да, чем нет (есть ряд причин).
Может подразумевается что-то другое?
AV
Да идея верная - конфиг плагин та ещё заноза в жопе. Но задачу решает и я лучше не придумал :)
RM
DS
https://github.com/yiisoft/router-fastroute/pull/30#discussion_r470443941 @yiiliveext ты уверен, что это дело роутера, а не фаструта?
Иначе у тебя будут дубли в паттернах в коллекции, когда например совпадают паттерны для разных поддоменов.
DS
либо надо допилить коллекцию, чтобы еще домен выдавала
DS
@rustamwin, ты какой метод коллекции роутов в консольной команде юзаешь для вывода?
DS
https://github.com/yiisoft/router-fastroute/pull/30#discussion_r470443941 @yiiliveext ты уверен, что это дело роутера, а не фаструта?
Наверное все же лучше допилить коллекцию, а это оставить в фастроуте
RM
@rustamwin, ты какой метод коллекции роутов в консольной команде юзаешь для вывода?
не понял.
DS
не понял.
Ну ты консольную команду для вывода роутов вроде делал, ты там с доменом выводишь?
NO
The Ant 🐜
пояснишь, почему мне не нужен конфиг, ну или хотябы, почему мне не нужно его кешировать?
Кто-то сказал что он тебе не нужен?
Я спросил "зачем он нужен?"
Это разные вещи.
Зачем вообще конфиг нужен, для чего он используется, какую задачу выполняет, какую проблему, главное, он решает? Почему с ним лучше, чем без него?
Хорошо бы понимать это для того, чтобы иметь возможность выбрать наилучшее решение, на концептуальном уровне.
А не просто "у меня есть конфиг мне надо его смержить"
Когда есть понимание, зачем что-то делается, то решение "как лучше сделать" находится быстрее и проще. Пока нет понимания, можно вечно ходить кругами.
Я спросил "зачем он нужен?"
Это разные вещи.
Зачем вообще конфиг нужен, для чего он используется, какую задачу выполняет, какую проблему, главное, он решает? Почему с ним лучше, чем без него?
Хорошо бы понимать это для того, чтобы иметь возможность выбрать наилучшее решение, на концептуальном уровне.
А не просто "у меня есть конфиг мне надо его смержить"
Когда есть понимание, зачем что-то делается, то решение "как лучше сделать" находится быстрее и проще. Пока нет понимания, можно вечно ходить кругами.
T🐜
Кто-то сказал что он тебе не нужен?
Я спросил "зачем он нужен?"
Это разные вещи.
Зачем вообще конфиг нужен, для чего он используется, какую задачу выполняет, какую проблему, главное, он решает? Почему с ним лучше, чем без него?
Хорошо бы понимать это для того, чтобы иметь возможность выбрать наилучшее решение, на концептуальном уровне.
А не просто "у меня есть конфиг мне надо его смержить"
Когда есть понимание, зачем что-то делается, то решение "как лучше сделать" находится быстрее и проще. Пока нет понимания, можно вечно ходить кругами.
Я спросил "зачем он нужен?"
Это разные вещи.
Зачем вообще конфиг нужен, для чего он используется, какую задачу выполняет, какую проблему, главное, он решает? Почему с ним лучше, чем без него?
Хорошо бы понимать это для того, чтобы иметь возможность выбрать наилучшее решение, на концептуальном уровне.
А не просто "у меня есть конфиг мне надо его смержить"
Когда есть понимание, зачем что-то делается, то решение "как лучше сделать" находится быстрее и проще. Пока нет понимания, можно вечно ходить кругами.
ну и зачем по твоему нужен конфиг?