Pull to refresh

Comments 112

Спасибо. И за фреймворк и за новость.
Дякую за проведену роботу, буде що підучити:)
Отличная новость!) Какие дальнейшие планы?

Релизы расширений, новый сайт, yiipowered, 2.1.

Yii powered websites showcase
https://github.com/samdark/yiipowered
UFO just landed and posted this here

Будет принимать от всех желающих информацию о проектах, сделанных на Yii, и показывать её.

А когда откажетесь от поддержки php 5.4? Я понимаю что это круто (старые версии и шаред хостинги), но все же…
В сторону php 5.6?
А смысл, если уже есть производительный 7?

Фреймворк и сейчас работает отлично на семёрке. И да, быстрее. Рекомендую обновиться, если ещё нет.

На семерке был замечен баг, когда выключение режима отладки увеличивало общее время генерации страницы и ответа сервера.
проверено было на двух хостингах и двух разных проектах, это было поправлено или не обращали на это внимания?

Это ожидаемо. В режиме отладки пишутся для этой самой отладки дополнительные данные.

выключение режима отладки увеличивало общее время

Либо Вы не поняли, либо человек опечатался.
Но если опечатался, то это да, капитанство получается.

А если не опечатался, то я не в курсе и надо это на github...

нет, не опечатался :) в том то и дело

Интересно. Ждём на github с замерами и способом воспроизвести...

хорошо, посмотрю :)
я замерял давно уже. проверю еще раз
до этого были примерно такие показатели на PHP 7.0.X
              YII_DEBUG(TRUE)      YII_DEBUG(FALSE)
Проект1       45 Мсек                   50 Мсек


Проект2      700 Мсек                  750 Мсек

сразу на 7? вроде нижнюю планку обсуждали. Клиенты с простыми сайтами не всегда готовы идти на VPS
5.6 уже на security support, т.е. всё.

И? Это не наша проблема. Если технически фреймворк работает с 5.4 и проблем ни в поддержке ни в работе с PHP 7 это не вызывает, зачем завышать требования?

я не про завышение, а про неразумность выбирать в качестве нового минимума версию, уже снимаемую с поддержки. А повышать или не повышать — дело команды.

Если бы вопрос выбора сопровождался бы написанием тучи polyfill-ов для этой версии, повышали бы до семёрки не задумываясь. А так как уже всё написано, покрыто тестами и работает, смысла нет.

Александр, ты продолжаешь о чем-то своем рассуждать. Речь идет о выборе минимально поддерживаемой версии во время предполагаемого перехода в одной из мажорных версий фреймворка. Ни полифиллы ни тесты здесь не причем.
Переход должен быть потому, что 5.4-5.5 уже не поддерживаются даже фиксами безопасности, что создает брешь и в вашем продукте. По этой же причине следующая минимальная версия должна быть поддерживаемой (5.6 на излете).
А зачем? Выбор версии софта на сервере это не ответственность фреймворка.
Если он МОЖЕТ работать на старом, то он должен на нем работать.
Допустим у человека сервер завязан на 5.4 и он не может его проапгрейдить потому что на сервере есть другой софт со своими зависимостями. Но прикладного кода не много, и он тривиален, поэтому совместимость с прошлой версией фреймворка сохраняется или легко апдейтится. Разработчик хочет перейти с 2.0 на 2.1. Но тут мы ему такие специально подляну всунули — код может работать на 5.4., но мы решили подумать за него и всунуть ему в композер зависимость на пхп7. Вот с какого перепуга?
поддержка определенной версии — это не столько вопрос плюшек новых версий, сколько вопрос уверенности пользователя (т.е. разработчика/заказчика) в стабильной его работе на данной версии. Заявляя поддержку версии, которая уже не получает фиксов безопасности, ты подставляешь своих пользователей, т.к. не обеспечиваешь эту самую стабильную работу. Поэтому каждая мажорная версия должна поднимать минимально поддерживаемую фреймворком версию вслед за минимальной поддерживаемой версией php его разработчиком.
Это не ответственность фреймворка.
Обновление версии пхп это ответственность админа, хостера, кого угодно, но не фреймворка. Может сервер живет настолько глубоко, что при всем желании и возможности туда не достучаться злому дяде. Но на нем стоит кастомная сборка пхп5.4, с кастомным расширением в виде бинарника, и выпуск этого расширения под пхп7 неизвестно когда будет. При этом юии2.0 будет менее безопасен чем 2.1 (ну возьмем экзотический случай, что мы дожили до снятия с поддержки 2.0, но еще хотим пхп5.4, ну вот сферический конь в вакууме, но мало ли какие будут комбинации). И вы вынуждаете использовать устаревший софт, просто потому что «так нада».
одно дело писать в документации что мол настоятельно рекомендуем обновить пхп, что скоро мы можем прекратить его поддержку и т.п. Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям — моветон.
Это не ответственность фреймворка.
это отвественность создателей продукта — поддерживать минимально безопасную экосистему
Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям
вот такой вот уровень дискуссии — представить мнение, которого придерживается большинство мейнетейнеров фреймворков, религиозным, т. е. маргинальным.
именно. поэтому и выбирать в качестве минимальной можно не 5.6 и 7.0, а 7.1. но с учетом распространения версий и функциональных изменений разумнее будет выбрать 7.0, которую в качестве минимальной выбирают все зарелизенные в последние полгода популярные в комьюнити библиотеки (от symfony/laravel до phpunit). А мы кстати говорим о 2.1, релиз которого вряд ли произойдет ранее второй половины года, а то и вообще не в 2017, судя по прошлой динамике.

Ну чем разумнее-то? У неё поддержка по времени меньше, чем у 5.6. 7.1 — да, разумно выбрать с точки зрения поддержки, но не разумно потому как никто его ещё не использует и массового перехода в ближайший год не будет.

одинаковая у нее подержка. разница в 3 недели.

Ну тогда почему обязательно 7, а не 5.6?

для стимулирования комьюнити. если бы не было 2.0, то комьюнити до сих пор не знало бы что такое неймспейсы (на форуме и сейчас, в 2017 вылазят люди и говорят, что за неймспейсы вы придумали).

Для стимулирования мы уже написали в гайде "runs best with PHP 7.0+" и на сайте на главной напишем большими буквами. Но требовать это через composer.json, всё-таки, не стоит.

То, что трендово и модно — не отрицаю. Рационально — нет.

yii2 — не про энтерпрайз. не стоит поддерживать все старье в новых мажорных версиях.

Ну, если IBM, Facebook, Альфа-групп, мэрия Москвы, минфин Украины, РТРС, FIFA — это всё не enterprise, то хорошо...

а) смешно (уверен в этом списке нет ничего кроме визиток и небольших личных кабинетов — про фейсбук например я точно помню, что там было.)
б) никто не говорит о миграциях старых продуктов на новые мажорные версии

а) Есть. IBM — сеть моллов в Китае. Альфа-групп — биржа. РТРС — весь интранет с внутренними процессами. FIFA — часть интранета. Facebook, мэрия Москвы, минфин Украины — да, по сути CMS.
б) И как их поддерживать?

вы и не будете их поддерживать, т.к. вы не энтерпрайз. поэтому когда к вам в issue прибегут с проблемой взломов сайтов на yii2, использующих 5.4.*, вы разведете руками — поддержка 5.4 кончилась. Поэтому в ваших же интересах указывать версии php с более долгим сроком поддержки. Проблема в php, а репутация пострадает ваша.

Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.

и сломаете обратную совместимость

Ну а какие ещё варианты есть, если её нельзя не сломать?


  1. Сломать.
  2. Выпустить новую мажорную версию и задепрекейтить текущую.

По сути это одно и то же. Версионирование только отличается.

Ну а какие ещё варианты есть, если её нельзя не сломать?
при разработке новой мажорной версии выбрать в качестве минимума не 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?

для стабильной работы. вы не поддерживаете php и сторонние либы, поэтому указываете те версии, на которых гарантируете стабильную работу фреймворка. Либо сами пишите патчи для зависимостей. Вы не энтерпрайз, поэтому непонятно почему вы не можете более свободно относиться к зависимостям, не ломая совместимости в рамках семвера.
Если сейчас было бы уместно указать 5.6/7.0, то к моменту выхода 2.1 до конца поддержки останутся месяцы, дай бог год.

Именно. Не требуется 7.0 для стабильной работы. Мы гарантируем, что 2.1 работает прекрасно на 5.6. Если в процессе разработки 2.1 потребуется технически 7.0 или найдут фатальный недостаток в 5.6, выставим в зависимостях 7.0.

поэтому сообщество зенда, симфони, ларавела будет всегда профессионально развитее, а сообщество yii2 будет состоять из динозавров.
Симфони/Ларавел УЖЕ на 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 у себя я делаю такие вещи по умолчанию, а если хочешь без них, то отдельно отключай. Хотите паранойю — сделайте отдельную библиотеку, назовите ее например секьюритиТест или секьюритиПак, туда пристройте все зависимости, все строгости, все проверки и замечания. Так будет ок, так будет СОЛИДно. :)
Полностью поддерживаю. Сам в свое время перешел на 5.4 только потому что задолбался с array(). По факту конечно скорее всего есть и другие зависимости от 5.4., но когда требование на 5.4 уже есть, то дальше уже не смотришь. А всё остальное (почти всё) некритично, и стараешься писать слишком не злоупотребляя свежатиной, а когда основной костяк уже написан, то и поддерживать обратную совместимость не приходится особо. Старый код УЖЕ есть. Чисто под проект можно вводить более свежие зависимости, но ядро то зачем?
Я долго ждал конфигурации DI через config и вот, наконец-то, дождался. Спасибо! ))
Как я с Вами солидарен, сударь. Это, пожалуй, самая приятная новость)
Только queue модуля не хватает для полного счастья.

Когда-нибудь и его допилим.

Я уже себе допилил github.
Могу помочь или просто перенести в официальный пакет если есть интерес.

Неплохая реализация, кстати. Эх, скоординироваться бы вам всем...

Объяви официальную инициативу :)
Придётся конечно помучаться, но по другому как правило это не происходит :)
А что скажете про https://github.com/urbanindo/yii2-queue

Мне гораздо больше понравилось.
Ещё бы глянуть примеры реальных реализаций где-нибудь.

Не очень понравилось, что воркеры реализованы контроллерами. А так примерно то же.

Я может непонятливый, потому что новайс. Но не понял как у Журавлёва сделать чтобы в случае если задание не отработало нормально, оно не удалилось из очереди. Вот у этого Urbanindo можно явно вернуть false из метода — и всё.

Застревать ли заданию в очереди, перекидываться в другой воркер или что-то исправлять зависит от ситуации и должно реализовываться в воркере.

Повторно отправить задание в очередь из Job-объекта можно так:


class SomeJob implements Job
{
    public function run()
    {
        Yii::$app->queue->push($this); // <--
    }
}
А почему так правильней?

Потому что не убирать из очереди при фейле — далеко не единственный вариант.

Не могу сказать однозначно что правильно, а что — нет. Вариант, который вы озвучили, вполне имеет право на жизнь на ряду с прочими. Только я бы не на return ориентировался, а на перехват исключения брошенного в процессе выполнения задания. С ним проще. Его можно положить в лог, чтобы потом разобраться в причине отказа. Ну и кол-во попыток должно быть фиксированным. Потому что ошибки бывают разные. При одних действительно стоит повторить попытку, а вторые — просто ложить в лог по тихому. В общем, нужно думать и обсуждать.


А так, стоит понимать, что отправленное в очередь задание — это неотъемлемая часть логики реализованной в рамках основного процесса, но, по причине своей ресурсоемкости, вынесенная в отдельный процесс. То есть, код должен быть организован так же, как если бы вы его делали в рамках основного процесса. Если нужно перехватывать какие-то ошибки и перезапускать, то лучше делать это в коде самого job-а индивидуально.

Ну вот я добрался до реализации когда, пришлось городить менеджмент очереди, с проверкой количества попыток, и отложенным запуском.
Имхо это всё же не должно быть в коде задания. Это дело очереди, заниматься его запуском, и всему к этому относящемся. Ну да, возможно придется сделать несколько разных типов очередей, который по разному себя ведут при невыполнении задания. Но все же по моему так логичнее.

Потому что сейчас получается что если я сделаю queue/listen у меня будет запускаться задание по миллиону раз в секунду, и тут же выходить, потому что таймаут очередной попытки его выполнения не прошел ещё.

А если запускать гранулярно через крон и queue/run то сложно будет подобрать интервал запуска, не слишком частый и не слишком редкий.

Разве что делать по собственной очереди на каждый тип заданий.

Обычно как раз и делается по собственной очереди на каждый тип заданий.

Мда. Видимо это просто два разных подхода. И мне нужен прямо противоположный этому :)
UFO just landed and posted this here
Меньше буковок печатать.
Код выше делает то же, что и:
$data = $cache->get($key);
if ($data === false) {
    $data = $this->calculateSomething();
    $cache->set($key, $data);
}

А чем вас смущает новый синтаксис? Никто не запрещает по-старинке расписать все явно.
UFO just landed and posted this here

А данные откуда брать, если в кеше их не оказалось?

UFO just landed and posted this here

Вы привели совсем не эквивалент. То, что у вас — это обычный $cache->get, который в таком виде уже давно существует. То, что в релизе — это getOrSet. То есть попробовать получить из кеша и, в случае отсутствия, вычислить и сунуть в кеш.

UFO just landed and posted this here

Как обойтись без обратного вызова?
Если


$data = $cache->getOrSet($key, $this->calculateSomething());

То эквивалентом будет


$default = $this->calculateSomething();
$data = $cache->get($key);
if ($data === false) {
    $data = $default;
    $cache->set($key, $data);
}

Только в таком случае кеш бесполезен

UFO just landed and posted this here
<irony> хоспади, люди просто добавили сахара, чего ж вы к синтаксису приклепались?)) </irony>

А что не так с синтаксисом? Самый удобный вариант. Вы приводите пример с готовым значением 20. А где и как вы его будете получать? Вот именно этим и будет заниматься колбэк, если в кеше еще нет готового значения.


Наиболее распространенный кейс использования кэша:


if (($value = $cache->get($key)) === false) {
    // Тут код ресурсоемкой операции, результат которой нужно закэшировать
    $value = 123; 
    $cache->set($key, $value);
}

Теперь можно так:


$value = $cache->getOrSet($key, function () {
    // Код операции, результат которой нужно закешировать
    return 123;
});
UFO just landed and posted this here
В кеше вполне может быть значение null и в этом случае ваш код будет всегда перекешировывать этот null. В «удобном» же варианте такого не должно происходить. Да и set метод скорее всего возвращает void.
UFO just landed and posted this here

Вам объясняют что, тот вариант, в одну строку, который вы предлагаете, не рабочий. И, чтобы его рабочим сделать, одной строки не хватит. get() может вернуть null, а set() возвращает результат записи в кэш, а не значение, которое вы туда пишите.


Удобство в том, что \yii\caching\Cache::getOrSet универсальный метод, который корректно покрывает наиболее распространенный кейс.


Единственное, если бы параметр \Closure $closure не стали бы делать типизированным, было бы проще. Тогда вариант в одну строку с вашей функцией мог бы выглядеть так:


$value = $cache->getOrSet($key, [$this, 'calculateSomething']);

Но и с анонимной функцией вполне удобно:


$value = $cache->getOrSet($key, function () {
    return this->calculateSomething();
});

С читабельностью все в порядке. Не пойму что именно вас смущает? Анонимные функции?


Минусы не мои.

UFO just landed and posted this here
UFO just landed and posted this here

Собственно, вы пришли к варианту, описанному в посте

Вы сейчас про альтернативную реализацию кэша. А причем тут Yii2?

вы про абстрактный кеш в вакууме, а мы про кеш в yii2. сдается мне, что вы не до конца разглядели как и что возвращает кеш в yii. Ваши примеры имеют право на жизнь и они даже местами приятны взору, но разговор опять же о yii2
За дефолтные параметры при генерации урлов отдельное спасибо. Еще бы DI в вызов экшенов (в крайнем случае в конструктор контроллеров).

В конструкторе есть.

Уберите наконец bower assets :) 2017 год на дворе…

А что нынче популярно в мире JS?

Да все то же самое, bower, npm, yarn вот новый. Да только 1) что делают фронтенд пакеты в коре, нафиг они нужны, если делать Rest API, 2) плагин надо ставить непонятный, да ещё и глобальный, 3) плагин отвратительно ищет в Bower, кучу времени занимает это. Я как бы понимаю, зачем все это, типа, чтоб ассеты пачкой тащить и бакенд и фронтенд, формы там валидировать, аяксы слать. Но в базовой поставке все это — лишнее.

Этот вопрос уже много раз поднимался и много раз был дан ответ, что в 2.1 мы постепенно выпиливаем frontend-зависимости из ядра.


Про плюсы и минусы медленного SAT-солвера для PHP и JS сразу мы, естественно знаем.

Да-да, я даже видел тред где говорилось, что это было большой ошибкой включать подобное в ядро. Однако вчера я смотрел в ветку 2.1 и там пока все присутствует… очень ждём :)
Sign up to leave a comment.

Articles