Комментарии 112
В 2.1.
Фреймворк и сейчас работает отлично на семёрке. И да, быстрее. Рекомендую обновиться, если ещё нет.
проверено было на двух хостингах и двух разных проектах, это было поправлено или не обращали на это внимания?
Это ожидаемо. В режиме отладки пишутся для этой самой отладки дополнительные данные.
И? Это не наша проблема. Если технически фреймворк работает с 5.4 и проблем ни в поддержке ни в работе с PHP 7 это не вызывает, зачем завышать требования?
Если бы вопрос выбора сопровождался бы написанием тучи polyfill-ов для этой версии, повышали бы до семёрки не задумываясь. А так как уже всё написано, покрыто тестами и работает, смысла нет.
Переход должен быть потому, что 5.4-5.5 уже не поддерживаются даже фиксами безопасности, что создает брешь и в вашем продукте. По этой же причине следующая минимальная версия должна быть поддерживаемой (5.6 на излете).
Если он МОЖЕТ работать на старом, то он должен на нем работать.
Допустим у человека сервер завязан на 5.4 и он не может его проапгрейдить потому что на сервере есть другой софт со своими зависимостями. Но прикладного кода не много, и он тривиален, поэтому совместимость с прошлой версией фреймворка сохраняется или легко апдейтится. Разработчик хочет перейти с 2.0 на 2.1. Но тут мы ему такие специально подляну всунули — код может работать на 5.4., но мы решили подумать за него и всунуть ему в композер зависимость на пхп7. Вот с какого перепуга?
Обновление версии пхп это ответственность админа, хостера, кого угодно, но не фреймворка. Может сервер живет настолько глубоко, что при всем желании и возможности туда не достучаться злому дяде. Но на нем стоит кастомная сборка пхп5.4, с кастомным расширением в виде бинарника, и выпуск этого расширения под пхп7 неизвестно когда будет. При этом юии2.0 будет менее безопасен чем 2.1 (ну возьмем экзотический случай, что мы дожили до снятия с поддержки 2.0, но еще хотим пхп5.4, ну вот сферический конь в вакууме, но мало ли какие будут комбинации). И вы вынуждаете использовать устаревший софт, просто потому что «так нада».
одно дело писать в документации что мол настоятельно рекомендуем обновить пхп, что скоро мы можем прекратить его поддержку и т.п. Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям — моветон.
Это не ответственность фреймворка.это отвественность создателей продукта — поддерживать минимально безопасную экосистему
Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениямвот такой вот уровень дискуссии — представить мнение, которого придерживается большинство мейнетейнеров фреймворков, религиозным, т. е. маргинальным.
Безопасность тут не при чём. Смотрите: http://php.net/supported-versions.php
5.6 в плане безопасности поддерживаться будет дольше, чем 7.0.
Ну чем разумнее-то? У неё поддержка по времени меньше, чем у 5.6. 7.1 — да, разумно выбрать с точки зрения поддержки, но не разумно потому как никто его ещё не использует и массового перехода в ближайший год не будет.
То, что трендово и модно — не отрицаю. Рационально — нет.
Ну, если IBM, Facebook, Альфа-групп, мэрия Москвы, минфин Украины, РТРС, FIFA — это всё не enterprise, то хорошо...
б) никто не говорит о миграциях старых продуктов на новые мажорные версии
а) Есть. IBM — сеть моллов в Китае. Альфа-групп — биржа. РТРС — весь интранет с внутренними процессами. FIFA — часть интранета. Facebook, мэрия Москвы, минфин Украины — да, по сути CMS.
б) И как их поддерживать?
Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.
Ну а какие ещё варианты есть, если её нельзя не сломать?
- Сломать.
- Выпустить новую мажорную версию и задепрекейтить текущую.
По сути это одно и то же. Версионирование только отличается.
Ну а какие ещё варианты есть, если её нельзя не сломать?при разработке новой мажорной версии выбрать в качестве минимума не 5.6/7.0, а 7.1/7.2.
ломать совместимость — это почти то же самое что ничего не делать, т.к. формально вы предлагаете переписать приложение написанное под одну версию php на другую. У кого-то опытного заработает без допилки, а у кого-то весь код в задепрекейченных в новой версии php функциях. В прицнипе звучит достаточно просто, но формально неправильно.
Формальное несоблюдение SemVer да, в этом случае будет. Согласен.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая. Выбирать сейчас 7.1, как по мне — отбить охоту использовать фреймворк у тяжеловесов вроде IBM. Согласование мажорные версии у них проходит с большим скрипом как раз под конец официальной поддержки (знаю по Oracle и Siemens). Выбирать 7.0, если отбросить генерацию хайпа и рассматривать только проблемы с безопасностью, бессмысленно.
Выбирать сейчас 7.1ну когда вы собираетесь 2.1 выкатывать? далеко не сейчас же.
отбить охоту использовать фреймворк у тяжеловесов вроде IBMну что они, на шаредах что ли сайты пилят?) сейчас докер очень популярен в т.ч. и у монстров рынка, а через год и того больше.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокаяну по мне вероятность довольно высокая чуть ли не на любой версии проработать стабильно разумное кол-во лет. Хоть на 5.4. Но в то же время то одно то другое — curl, openssl, а это все связано.
Про SOLID слышали?)
Шучу, шучу. Понятно что слышали, и вопрос не без сарказма.
Я намекаю на то, что не нужно смешивать ответственности.
У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции. В требованиях указывается требование. Всё. Если мы будем засовывать в требования пожелания по безопасности, то мы вернемся к лапше девяностых. Во всём.
ПС: я бы допустил разговор о завышенных требованиях в шаблонах приложений, но точно не во фреймворке.
Ну и комментарий, да. Мол требуем больше чем надо ибо вы ребятки обновляйтесь а не спите.
У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции.если я правильно понял, вы против того, чтобы указывать в composer.json зависимости библиотеки — их надо «рекомендовать» в отдельном месте. Либо же вы отделяете зависимости в виде библиотек от зависимости в виде интерпретатора, как будто бы мейнтейнеры должны требовать установки определенных версий библиотек, на которых гарантируется стабильная работа фреймворка, но не должны требовать версию интерпретатора, потому что что-то.
Если свежая версия интерпретатора по факту не требуется для работы кода, зачем указывать её в composer.json?
Если сейчас было бы уместно указать 5.6/7.0, то к моменту выхода 2.1 до конца поддержки останутся месяцы, дай бог год.
Именно. Не требуется 7.0 для стабильной работы. Мы гарантируем, что 2.1 работает прекрасно на 5.6. Если в процессе разработки 2.1 потребуется технически 7.0 или найдут фатальный недостаток в 5.6, выставим в зависимостях 7.0.
Симфони/Ларавел УЖЕ на 7.0. Зенд УЖЕ на 5.6. PhpUnit6 уже на 7.0. Большинство библиотек из обзора php-новостей на хабре УЖЕ на 7.0. А мы обсуждаем с кор девелопером yii 5.6 или 7.0 выбрать ЧЕРЕЗ ГОД.
Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября. PHPUnit поднял версию ради поднятия версии. Просто потому что все прыгают и я прыгну. Технически в этом необходимости не было. Теперь будут поддерживать несколько веток.
Профессионально развитее потому что фреймворк не работает на 5.6 и при этом не использует ничего из 7.0? Да ладно вам. Я бы ещё понял если бы аргументом была большая степень абстракции или меньшая связанность, но не это...
Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября.да, ок был не прав. казалось, 3.3 уже вышла. Но тенденция ясна.
Технически в этом необходимости не былода и не должно быть. Вы не энтерпрайз. Вам надо хайп ловить, привлекать новых членов комьюнити за счет трендов и баззвордов.
Мне очень не хотелось бы в PHP видеть ту же картину, что и в JavaScript: новый тренд каждые два месяца. Начинаем делать проект на трендовом фреймворке, к релизу он уже безбожно "устарел" и не поддерживается официально. Одно дело программировать ради фана и просто забивать на любую поддержку, и совсем другое — делать основу, на которой строятся и поддерживаются годами отличные проекты.
В этом же контексте выплывает другая проблема — меняющиеся как кадры фильма версии без обратной совместимости не дают полноценно вырасти стабильной экосистеме.
Не поймите меня превратно. Вордпресс безнадежно устарел, и да, я никогда не считал его фреймворком в отличии от многих ВПфилов. Но его устаревание и его популярность это две стороны одного явления — преемственности. При всем желании ВП не может перейти на ООП, MVC и т.п. Он потеряет совместимость и перестанет быть ВП. Не ратую за то, чтобы застревать в девяностых как ВП, но понимать чего стоит гонка за модой тоже нужно.
Юии зависим от 5.4, значит надо указать его зависимость — 5.4.
Библиотеки тянутся с гитхаба одинаково хорошо, что старые, что новые, так что мешать не стоит. Плюс опять таки — минорную версию лучше указывать ту которая реальная зависимость, ведь компостер сам подтянет тебе посвежее из совместимого и стабильного.
Нет, хотите строгости и паранойи? Я вас понимаю. Глядя как в первом Юии (со вторым плотно не работал, только в уже готовое что-то дописывал, так что не слежу) половина вечно забывала включить проверку XSRF у себя я делаю такие вещи по умолчанию, а если хочешь без них, то отдельно отключай. Хотите паранойю — сделайте отдельную библиотеку, назовите ее например секьюритиТест или секьюритиПак, туда пристройте все зависимости, все строгости, все проверки и замечания. Так будет ок, так будет СОЛИДно. :)
Очень классная новость!
Когда-нибудь и его допилим.
Могу помочь или просто перенести в официальный пакет если есть интерес.
Да так много кто сделал. В issue https://github.com/yiisoft/yii2-queue есть ссылки.
https://github.com/zhuravljov/yii2-queue пока лучшая попытка.
Неплохая реализация, кстати. Эх, скоординироваться бы вам всем...
Придётся конечно помучаться, но по другому как правило это не происходит :)
Мне гораздо больше понравилось.
Ещё бы глянуть примеры реальных реализаций где-нибудь.
Не очень понравилось, что воркеры реализованы контроллерами. А так примерно то же.
Застревать ли заданию в очереди, перекидываться в другой воркер или что-то исправлять зависит от ситуации и должно реализовываться в воркере.
Повторно отправить задание в очередь из Job-объекта можно так:
class SomeJob implements Job
{
public function run()
{
Yii::$app->queue->push($this); // <--
}
}Потому что не убирать из очереди при фейле — далеко не единственный вариант.
Не могу сказать однозначно что правильно, а что — нет. Вариант, который вы озвучили, вполне имеет право на жизнь на ряду с прочими. Только я бы не на return ориентировался, а на перехват исключения брошенного в процессе выполнения задания. С ним проще. Его можно положить в лог, чтобы потом разобраться в причине отказа. Ну и кол-во попыток должно быть фиксированным. Потому что ошибки бывают разные. При одних действительно стоит повторить попытку, а вторые — просто ложить в лог по тихому. В общем, нужно думать и обсуждать.
А так, стоит понимать, что отправленное в очередь задание — это неотъемлемая часть логики реализованной в рамках основного процесса, но, по причине своей ресурсоемкости, вынесенная в отдельный процесс. То есть, код должен быть организован так же, как если бы вы его делали в рамках основного процесса. Если нужно перехватывать какие-то ошибки и перезапускать, то лучше делать это в коде самого job-а индивидуально.
Имхо это всё же не должно быть в коде задания. Это дело очереди, заниматься его запуском, и всему к этому относящемся. Ну да, возможно придется сделать несколько разных типов очередей, который по разному себя ведут при невыполнении задания. Но все же по моему так логичнее.
Потому что сейчас получается что если я сделаю queue/listen у меня будет запускаться задание по миллиону раз в секунду, и тут же выходить, потому что таймаут очередной попытки его выполнения не прошел ещё.
А если запускать гранулярно через крон и queue/run то сложно будет подобрать интервал запуска, не слишком частый и не слишком редкий.
Разве что делать по собственной очереди на каждый тип заданий.
Как обойтись без обратного вызова?
Если
$data = $cache->getOrSet($key, $this->calculateSomething());То эквивалентом будет
$default = $this->calculateSomething();
$data = $cache->get($key);
if ($data === false) {
$data = $default;
$cache->set($key, $data);
}Только в таком случае кеш бесполезен
А что не так с синтаксисом? Самый удобный вариант. Вы приводите пример с готовым значением 20. А где и как вы его будете получать? Вот именно этим и будет заниматься колбэк, если в кеше еще нет готового значения.
Наиболее распространенный кейс использования кэша:
if (($value = $cache->get($key)) === false) {
// Тут код ресурсоемкой операции, результат которой нужно закэшировать
$value = 123;
$cache->set($key, $value);
}Теперь можно так:
$value = $cache->getOrSet($key, function () {
// Код операции, результат которой нужно закешировать
return 123;
});
Вам объясняют что, тот вариант, в одну строку, который вы предлагаете, не рабочий. И, чтобы его рабочим сделать, одной строки не хватит. get() может вернуть null, а set() возвращает результат записи в кэш, а не значение, которое вы туда пишите.
Удобство в том, что \yii\caching\Cache::getOrSet универсальный метод, который корректно покрывает наиболее распространенный кейс.
Единственное, если бы параметр \Closure $closure не стали бы делать типизированным, было бы проще. Тогда вариант в одну строку с вашей функцией мог бы выглядеть так:
$value = $cache->getOrSet($key, [$this, 'calculateSomething']);Но и с анонимной функцией вполне удобно:
$value = $cache->getOrSet($key, function () {
return this->calculateSomething();
});С читабельностью все в порядке. Не пойму что именно вас смущает? Анонимные функции?
Минусы не мои.
Второй вариант не работает
Собственно, вы пришли к варианту, описанному в посте
Вы сейчас про альтернативную реализацию кэша. А причем тут Yii2?
А что нынче популярно в мире JS?
Этот вопрос уже много раз поднимался и много раз был дан ответ, что в 2.1 мы постепенно выпиливаем frontend-зависимости из ядра.
Про плюсы и минусы медленного SAT-солвера для PHP и JS сразу мы, естественно знаем.
Не так просто выпилить… но уже начали.
Yii 2.0.11