Они даже признали что их eager loading не так уж хорош и хотели исправить его в L4, но видимо руки как всегда не дошли. Если уж и писать на фреймворке который «строился на компонентах симфони» то я уже б выбрал симфони
P.S. один из комментариев из реддита: «I loved PHPixie, but I cannot be taken serious on my workspace using a framework named pixie with that colorful website =/»
Печально когда фреймворк на работе оценивают по цветовой гамме =(
Хм но вы так мокаете весь класс полчается. А что если внутри метода у меня испольузються два объекта одного класса с различными значениями num_animals?
Нет не разработчик =) Просто написал первый раз статью чтоб вылезть из песочницы, а потом смотрю люди плюсуют вот и решил писать дальше в том же направлении =)
Да, но если вы отключаете глобальное состояние то тест тогда не полный, потому что реальная прога будет использовать это состояние.
Бтв, всегда передаю конфигурация как параметр конструктора ( симфони тоже так делает, если ровно писать) =)
Насчет тестирования синглтонов. Проблема ту отнюдь не техническая и никакая библиотека ее не решит. Проблема в том что синглтон вносит global scope, то есть поведение методов использующих синглтоны не всегда однозначно, пример:
function add($n){
retrun $n + Number::instance()->m;
}
результат такого метода зависит не только от значения n но и от состояния синглтона Number.
То что это глобальное состояние можно задать наперед это очень хорошо, но такой тест уже не будет юнит тестом, потому что вы тестируете не только сам метод а еще и глобальное состояние программы. Для написания интеграцыонних тестов метод конечно идеален, но его использование еще не значит что можно начать писать синглтоны повсюду.
Ну практика конечно хорошая. Но я подозреваю что на деле может привести к куче методов с рдной строчки. Да и если честно то редко я ее вижк. Посмотрите например на симфони, они там часто используют как раз глубокие проперти
В комментах уже упомянул что там LACZOS. Насчет шрифтов в ГД то вы не правы. Во первых эти шрифты так же выглядят и в PNG, во-вторых (тоже с комментов) сам фреймворк ставит для джпега по дефолту качество 90%
ресайз LANCZOS, при компиляции оставлял все по дефолту. А вот насчет возможности работы в несколько потоков то при чем тут? ведь Imagick для пхп и так только по одному обрабатывает. Если я бы генерил много превюшек нараз то делал бы не через ПХП а напрямую используя mogrify.
Не спорю но мы тут сравниваем не так качество как скорость работы. Я понимаю что мог бы лучше подогнать параметры, но результат не так уж и изменился б.
forums.laravel.io/viewtopic.php?id=6140
Они даже признали что их eager loading не так уж хорош и хотели исправить его в L4, но видимо руки как всегда не дошли. Если уж и писать на фреймворке который «строился на компонентах симфони» то я уже б выбрал симфони
Печально когда фреймворк на работе оценивают по цветовой гамме =(
Бтв, всегда передаю конфигурация как параметр конструктора ( симфони тоже так делает, если ровно писать) =)
результат такого метода зависит не только от значения n но и от состояния синглтона Number.
То что это глобальное состояние можно задать наперед это очень хорошо, но такой тест уже не будет юнит тестом, потому что вы тестируете не только сам метод а еще и глобальное состояние программы. Для написания интеграцыонних тестов метод конечно идеален, но его использование еще не значит что можно начать писать синглтоны повсюду.
Как по мне то идентично
Спасибо что поправили с 95, я что-то недосмотрел