Почему значение autovacuum_vacuum_scale_factor равно 0,2?
является "так захотел один из ведущих разработчиков". Это не какая-то полученная в результате тестирования или вычислений величина. Просто был спор по поводу этого значения, были предложены разные значения, и кто-то должен был сделать выбор.
Если предусловия теста в его начале не создаются тут же в коде явным образом, то предвариельная проверка с заваливанием всего теста из-за несоответствия ожидаемого предсостояния обязательна.
Особенно это важно в интеграционных тестах с БД. Т.к. после выполнения предыдущих тестов состояние может быть вообще не таким, каким его видит автор теста.
А что есть "оператор assert"? По-моему, очевидно, что под оператором понимается законченная проверка какого-либо объекта. Соответственно, если нужно проверить состояние объекта из 100500 полей, то именно это и должно быть выполнено в тесте. Не нравится простыни из assertEquals()/assertThat() - вынеси в отдельный метод assertSomeObjects() и в используй его в тесте.
Так оно и запускается. Если не использовать платформозависимые подгружаемые библиотеки и не вставлять искусственные проверки, приводящие к исключениям.
REST — это хорошо для запросов с мгновенным результатом.
REST - это вообще ни разу не про протокол взаимодействия. REST - это унифицированный набор правил для каждой конкретной системы; архитектурный стиль, если угодно. REST вполне себе может быть не поверх HTTP реализован.
Так я про это и написал. QUERY-метод только обсуждается и не поддерживается, по-моему, ничем из существующего. А люди уже идут на шаг впереди, т.к. понимают что за этим будущее.
Гораздо более неприятно узнавать, например, что довольно низкоуровневые инструменты, позволяющие работать с HTTP-протоколом, таят в себе подлянку в виде перетирания заранее заданного метода запроса.
Я только одного не понял: а зачем? Зачем, во-первых, сравнивать библиотеку и фреймворк (они по сути решают разные задачи), а, во-вторых, почему ретроспектива на 5 лет? Почему не на 10? Оба два уже были в 2015.
Ну, т.е. ответом на вопрос
является "так захотел один из ведущих разработчиков". Это не какая-то полученная в результате тестирования или вычислений величина. Просто был спор по поводу этого значения, были предложены разные значения, и кто-то должен был сделать выбор.
Если предусловия теста в его начале не создаются тут же в коде явным образом, то предвариельная проверка с заваливанием всего теста из-за несоответствия ожидаемого предсостояния обязательна.
Особенно это важно в интеграционных тестах с БД. Т.к. после выполнения предыдущих тестов состояние может быть вообще не таким, каким его видит автор теста.
Потому что так решили разработчики JVM.
Никак. Надо менять способ запуска и, соответственно, дистрибуции.
КГ/АМ.
А что есть "оператор assert"? По-моему, очевидно, что под оператором понимается законченная проверка какого-либо объекта. Соответственно, если нужно проверить состояние объекта из 100500 полей, то именно это и должно быть выполнено в тесте. Не нравится простыни из
assertEquals()/assertThat()- вынеси в отдельный методassertSomeObjects()и в используй его в тесте.Нужно только захотеть.
Так оно и запускается. Если не использовать платформозависимые подгружаемые библиотеки и не вставлять искусственные проверки, приводящие к исключениям.
Об этом вообще-то
русскиманглийским по белому в спецификации написано.Тынц.
Я правильно понял, что армейские проекты (!) хранятся на зарубежном (!!) ресурсе, контроллируемом вероятным противником (!!!)?
REST - это вообще ни разу не про протокол взаимодействия. REST - это унифицированный набор правил для каждой конкретной системы; архитектурный стиль, если угодно. REST вполне себе может быть не поверх HTTP реализован.
Нет, Ночь перед Рождеством.
Нет, не устроит. Я спрашивал конкретно, "кто, кроме разработчиков?", а ваше "да" - это ответ на абстрактный "кто-то, кроме разработчиков?"
Меня бы устроил ответ "Я" от любого неразработчика данного форка.
Так я про это и написал. QUERY-метод только обсуждается и не поддерживается, по-моему, ничем из существующего. А люди уже идут на шаг впереди, т.к. понимают что за этим будущее.
Гораздо более неприятно узнавать, например, что довольно низкоуровневые инструменты, позволяющие работать с HTTP-протоколом, таят в себе подлянку в виде перетирания заранее заданного метода запроса.
Это QUERY.
А кто его, кроме его же разработчиков, использует?
Допустимы оба варианта.
del
Поделилась? Расшаривай :)
Я только одного не понял: а зачем? Зачем, во-первых, сравнивать библиотеку и фреймворк (они по сути решают разные задачи), а, во-вторых, почему ретроспектива на 5 лет? Почему не на 10? Оба два уже были в 2015.
Если новая ЗП покрывала издержки премии за 3 года, то либо эта премия не такая и большая, либо одно из двух.