• Поговорим о Yii 2
    +2

    Порог действительно низкий. Это так.


    Вы хотите, чтобы на PHP были либо опытные продвинутые разработчики, либо никого? Я нет потому что тогда сильным проектам, где эти продвинутые разработчики нужны, будет неоткуда вырастать.


    Yii допускает много вольностей. На нём можно быстро фигачить, а можно писать грамотно и хорошо. Зависит от опыта и дисциплины того, кто пишет.

  • Поговорим о Yii 2
    +1

    4 года — это время жизни нормального проекта. Не каждые же пол года ломать всё и релизить мажорную версию...

  • Поговорим о Yii 2
    0

    Можно завести две record на одну таблицу в разных namespace-контекстах.

  • Поговорим о Yii 2
    0

    Из этого ничего :)


    • queue — фреймворконезависимых очередей нормальных не нашлось. Запилили прототип на хакатоне потому что было интересно, сможем ли. Прототип Журавлёв допилили до прекрасного состояния и расширение мы приютили. При этом он его развивает, мы только помогаем советами и докой, как и помогали пока репозиторий был в его аккаунте. Времени не кушает.
    • authclient был с самого начала. Он прилично интегрирован с аутентификацией. Если бы использовали внешнюю либу для OAuth, так и так пришлось бы обёртку делать.
    • collection — сильно просили прямо в фреймворке сделать поддержку. Решили сделать в расширении. Это не просто generic-коллекции, там есть и специфичные для AR Yii штуки, которые позволяют работать с базой довольно эффективно, а не вытягивать всё и фильтровать средствами PHP.
    • httpclient — обёртка с двумя простейшими дефолтными драйверами. Нужна чтобы, например, можно было бы подменить Guzzle на что-то ещё.
    • shell — да, скорее всего так. Но каши не просит, можно и оставить.
  • Поговорим о Yii 2
    +1
    Вам выше уже всё сказали — зачем, к примеру, пилить свой, какой-нибудь к примеру FileSystemHelper, если есть множество готовых, устанавливающихся одной командой composer? А на это тратится безумное количество времени.

    Конкретно FileSystemHelper — только обратная совместимость. Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.


    Ну и плюс тут вопрос контроля и хрупкости. Вспомните left-pad и npm...

  • Поговорим о Yii 2
    0

    Да не, не приходится. Отлично всё конфигурируется либо через контейнер, либо по месту. Просто люди привыкли делать обёртки ещё с 1.1 и по инерции наделали их очень много...

  • Поговорим о Yii 2
    +4
    с обязательным переносом на новый фреймворк через 2-3 года

    А сразу писать нормально или порефакторить потом никак?

  • Поговорим о Yii 2
    0

    Инстанциацию кастомную надо, да. Что-то вроде https://github.com/samdark/hydrator

  • Поговорим о Yii 2
    0

    Нет. Ничего не наследуется от AR. Используется либо AR внутри репозитория, либо вообще не используется. Query Builder тоже неплох.

  • Поговорим о Yii 2
    0

    Я много чего не озвучил: https://github.com/yiisoft/yii2/wiki/Plan-for-next-major-versions Плюс посмотрите issue на 2.1.

  • Поговорим о Yii 2
    +1

    Так и в Yii можно так же. DI контейнер в фреймворке вполне себе универсальный и может настраивать не только классы самого фреймворка.


    Также посмотрите на обилие прослоек, коннекторов и обёрток для независимых библиотек, реализованных в виде extension-пакетов.

  • Поговорим о Yii 2
    0

    Через магический геттер.

  • Поговорим о Yii 2
    0

    Почему не получается? Делайте Model и Repository. Кто мешает?

  • Поговорим о Yii 2
    +2

    Я тоже. Одно дело сам фреймворк — в него компоненты удачные перекочевали из тех времён, когда ничего не было. Плюс некоторые запилили с нуля потому как было время на них и могли сделать хорошо. Итеративно улучшать это всё логично потому как оно не хуже альтернатив. Хотя, конечно, временами некоторые части хочется выкинуть и взять что-то, что их переросло. Но обратная совместимость в 2.0 это сделать не позволяет.


    Совсем другое дело — проекты. Вот в них чем руководствуются, реализуя с нуля всякое, я не уверен...

  • Поговорим о Yii 2
    +2
    То, что для ее поддержки пришлось писать свой автолоадер?

    Нас, кроме алиасов, интересовала ещё и скорость загрузки классов. На момент релиза Yii лодер Composer-а был совсем плох в этом плане. issue на тему loader-а практически не было, работает всё стабильно, каши не просит.


    В итоге теперь мы оперируем и неймспейсами и алиасами. Алиасы для ФС выглядят как вынужденное наследие Yii 1, а не фича.

    Алиасами мы для загрузки классов не оперируем. Как и не оперируем неймспейсами для работы с файловой системой.


    Выделяя модули/расширения Yii-шного приложения в отдельные пакеты, мы на много лет вперед привязываемся к текущей мажорной версии Yii. Либо вынуждены писать максимально абстрагируясь то Yii, что очень непросто.

    Так этот факт не меняется вне зависимости от используемого фреймворка. Писать независимые компоненты сложнее, чем завязанные на другой код.


    Будет интересно услышать от вас планы по развитию фреймворка.

    Эволюционные. Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем...


    Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.


    Если не секрет, кто сейчас решает стратегические вопросы?

    Я, Carsten Brandt, Дмитрий Науменко, Климов Павел, Boudewijn Vahrmeijer.

  • Поговорим о Yii 2
    0

    В Yii вы можете навесить валидатор на соответствующий приватному свойству геттер. А вообще валидировать приватные свойства не в конструкторе и не в сеттере несколько странно.

  • Поговорим о Yii 2
    0

    Нет, в Active Record нельзя. Сам паттерн создан для обратного. Доктрина — не Active Record.

  • Поговорим о Yii 2
    0

    Поясните, как вы хотите получить публичный доступ к private?

  • Поговорим о Yii 2
    +1

    Ох, опять ужас придётся копи-пастить:


    global $kernel;
    $assetsManager = $kernel->getContainer()->get('acme_assets.assets_manager');‏

    Но что в Yii это сделать в разы легче — факт.

  • Поговорим о Yii 2
    +20

    Неплохой пост. Частично верный, частично нет. Думаю, стоит немного разобрать.


    Архитектура фреймворка


    Выходит, архитектура закладывалась в 2014 — 3 = 2011-м году. Или раньше?

    Архитектура закладывалась в течение многих лет. Что-то, что показало себя хорошо — перекочевало в немного изменённом виде ещё из Prado, что-то из Yii 1.1, а что-то, что показало себя плохо — было обдумано и разработано с нуля.


    Мысленно вернемся в 2014-й. Ожидание второй версии Yii кажется бесконечно долгим, core-разработчики не называют никаких сроков. Разработка ведется в закрытом от публики репозитории.

    А вот и нет: https://habrahabr.ru/post/178917/


    С первой версии нам достались глобальные константы в коде, свой autoloader, своя хитрая система алиасов для файлов и папок.
    Ооооок. Просто напоминаю, что сейчас идет вторая половина 2017-го.

    • Константы — да. Будем менять их на getenv или что-то подобное.
    • Не понимаю, что плохого в своём полностью PSR-4 совместимом autoloader-е, необходимом для поддержики алиасов и работающем быстрее, чем тот же autoload-ер Composer-а. Если бы он было хуже, тогда нет вопросов — выкинули бы не думая. Напомню, что писался он задолго до релиза Composer. И ещё уточню, что autoload-ер в Yii 2 не имеет ничего общего с autoload-ером Yii 1.1.
    • Что плохого в системе алиасов для путей файловой системы и URL тоже не понимаю.

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

    Конечно, зависит от опыта, но знакомые, которые писали на Yii проекты и до этого работали с Symfony, Django, RoR, Spring и т.д. сильных проблем не испытывали. Незнакомый код не в счёт. Изучение при использовании нового инструмента всегда занимает какое-то время. Любой фреймворк даёт надстройку над языком. Свой DSL, упрощающий построение проектов. Иначе какой в фреймворке смысл?


    Компоненты, их события, поведения… возможно, они имели смысл в PRADO Framework, где "компонентами" были TButton, TAccordion и все вот это.

    Они и сейчас имеют смысл. Да, иерерхия наследования в Yii далеко не идеальная и мысли по сокращению её есть.


    Среди достоинств Yii часто озвучивают простоту фреймворка. Но это правда только отчасти. Знаете, что происходит, когда вы делаете что-то безобидное вроде $post->title = 'Hello'?
    Вы можете побывать здесь, здесь, здесь, здесь, а также в любом прикрепленном к $post event-у или behavior-у. Это может свести с ума во время отладки.

    Только если кто-то очень сильно постарается в коде приложения и либо нацепляет очень много нетривиальных behavior-ов, либо сделает всё на событиях. Логика properties очень простая, покрытая на 100% тестами и хорошо документированная.


    Не добавляет радости и тот факт, что любой компонент приложения из любого места можно достать через Yii::$app. Эдакий экземпляр приложения и сервис-локатор в одном лице.

    Практически в любом фреймворке можно достать глобально и явно контейнер. Но это не означает, что по-другому писать нельзя (в Yii, например, есть нормальный autowiring) и это не означает, что так надо делать.


    DI-контейнер


    Отстутсвующие фичи из других фреймворков либо настолько редко используются, что никому не нужны, либо просто их никто не просил. Так мы не против допила контейнера, если в этом есть необходимость. Если вам лично нужна какая-то фича, опишите почему в issue и мы вместе подумаем над решением.


    Внутри Yii 2 собственный контейнер не используется, а все компоненты лежат в Yii::$app, прямо как в первой версии.

    Используется. Поэтому возможно, например, вот это: http://www.yiiframework.com/doc-2.0/guide-concept-di-container.html#practical-usage


    Вот автовайринга в ядре нет. Потому что во-первых — рефлексия, а во-вторых — при чрезмерном использовании отладка лазанья-кода с ним действительно превращается в ад.


    Active Record


    Единственный минус вытекает из сильной связанности фреймворка — если ваша бизнес-логика оказалась в AR-моделях, то переиспользовать все это добро можно только в рамках проектов на Yii.

    Хотели переиспользовать — нечего было бизнес-логику завязывать на работу с базой… если её запихать, например, в entity из Doctrine, которые вроде отдельные, а вроде и с метаданными в виде тучи аннотаций — лучше не будет. Хотите чистого кода — выделяйте его в отдельный слой. Да, это не просто, но одинаково не просто при использовании чего угодно потому как от фреймворка не зависит.


    Фронтенд


    Для установки Yii 2 вам нужно в принудительном порядке поставить глобально fxp/composer-asset-plugin, для того, чтобы поставить jQuery c помощью composer-а, для того, чтобы установился Yii.

    Со следующего релиза 2.0 уже нет. И долго ждать тоже не нужно. Хотя да, использовать fxp было рисковым предприятием и косяков вылезло много.


    jQuery входит в обязательные зависимости Yii 2.

    Пока да.


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

    https://github.com/cebe/assetfree-yii2


    Все остальные компоненты


    Абстракция над HTTP, кеширование, логирование… они есть, и они без проблем выполняют свои задачи.
    Конечно же они самобытные, гвоздями прибитые к Yii, и не имплементируют соответствующие им PSR-ы.

    Уже писал в комментах, но повторю. Во первых, это не совсем так: https://github.com/yiisoft/yii2/wiki/PSR-adoption
    Во-вторых, некоторые PSR ещё не были приняты на момент релиза 2.0 и ломать обратную совместимость сразу после их принятия было ни к чему.


    Будущее Yii


    Код, написанный на PHP, работает везде, а код, написанный на Yii — только на Yii. Вы либо ставите на Yii всё, либо ничего. Это риск для долгосрочного проекта.

    В чём именно риск, поясните.


    Конечно, приложив усилия, можно писать framework-agnostic код и разруливать все через DI-контейнер, но это не поощряется.
    Если вы все-таки решитесь на это, вам прийдется забыть про Yii-вский ActiveRecord или начать писать неприлично толстые прослойки между фреймворком и вашей бизнес-логикой.
    Но это, мягко говоря, неоправданно.

    Не понял, при чём там ссылка на issue, созданный членом команды Yii, где нет ни слова про DI.
    И ещё не понял, почему это я не могу взять, например, независимый Facebook SDK и использовать прекрасно в Yii, внедрив его в конструктор сервиса через autowiring?


    Если вы наследуете какой-либо класс своего приложения от любого другого класса Yii, без Yii вы его работать не заставите, ведь он обязательно наследует Object или Component. Вот.
    Даже если вы вытащите вместе с ним весь ворох родительских классов и реализуемых интерфейсов, это вам не поможет.

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


    С модными нынче DDD и CQRS/Event Sourcing Yii также вам не помощник. Скорее, даже будет вставлять палки в колеса.

    С DDD tactical вам мало что из современных фреймворков поможет. Палки Yii в колёса не вставляет, если вы знаете, как готовить DDD.


    Команда фреймворка всё пишет сама. Даже VarDumper они написали свой, а не взяли из компонентов Symfony.

    Потому что компонентов Symfony тогда ещё не было. Отказаться от всего, что мы написали просто потому, что есть альтенатива у другого фреймворка — не лучшая идея, особенно если наш код не хуже и поддерживать его не составляет проблем.


    Регулярно поддерживать и улучшать столько компонентов — очень непростая задача для небольшой команды. И у этой команды есть два пути.

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

    Во-вторых, можно все-таки разбить монолитный Yii на независимые от фреймворка компоненты.
    Но тогда это будет уже не Yii с простым и удобным API, а просто еще один набор компонентов, не востребованный вне экосистемы Yii.

    Оба пути ведут в никуда.

    Вот только пути не два и не обязательно пускаться в крайности. Например, можно пойти по пути Laravel — выкинуть всё своё, взять за базу компоненты Symfony, написать к ним обёртки и допы. Часть кода можно выделить в библиотеки. Тот же слой i18n у Yii один из самых мощных, так что за востребованность можно не беспокоиться. Или можно часть кода выделить в расширения и подключить к их поддержке и разработке заинтересованных людей. Это уже сделано с ElasticSearch, Docker и очередями и такой подход показывает себя неплохо.


    PHP 7


    Но если мы хотим использовать тайпхинтинг, все это удобное API превращается в тыкву.

    У вас опять крайности. Тайпхинтинг нужен не для того, чтобы его использовать, а для того, чтобы поймать ошибки. В вашем приложении никто не запрещает им пользоваться, а именно там случается большинство ошибок. Сам фреймворк хорошо оттестирован.


    Qiang так и не вернулся


    Самые внимательные заметили отсутствие через пять месяцев. Это означает только одно — даже если "грузовик передет" ещё одного члена core team, фреймворк не умрёт.

  • Поговорим о Yii 2
    0

    К сожалению, с event-driven системами работать приходилось :(

  • Поговорим о Yii 2
    +3

    Неактивные — это entity с репозиторием? Ну, в репозиторий, очевидно, напихать.


    А так, например, можно устроить beforeSave() в той же Doctrine. Не раз видел:


    /**
     * @PrePersist
     */
    public function beforeSave()
    {
        // колбасим
    }
  • Поговорим о Yii 2
    –3

    Почему?

  • Поговорим о Yii 2
    +7

    Принципиальная возможность напихать логику куда угодно есть в каком угодно фреймворке. Это не означает, что её туда необходимо пихать...

  • Поговорим о Yii 2
    +3

    Про PSR в Yii в курсе. Мы участвуем в PHP-FIG и эти самые PSR помогаем писать. Когда Yii 2.0 релизился, многие PSR ещё не были приняты, а после релиза ломать работающий код в минорных версиях — это не наш метод. В следующей мажорной версии PSR будут использоваться более широко. Вот текущее состояние: https://github.com/yiisoft/yii2/wiki/PSR-adoption

  • Поговорим о Yii 2
    +2

    Только это, скорее, про тесты и архитектуру, а не про фреймворки...

  • Поговорим о Yii 2
    0

    Какие именно стандарты?

  • Как поднять продажи в Москве на 60% в период кризиса? История успеха одной компании
    0

    Мониторились ли показатели на каждом из этапов? Если да, какова динамика?


    Исключены ли сезонные колебания? Не проводилось ли параллельно каких-то акций?

  • Yii 2.0.12
    0

    Закиньте на GitHub, если ещё не закинули. Посмотрим и, если надо, исправим.

  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +1

    У нас были командировки из дома в офис :)

  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +2

    По пиву однозначно Лондон выигрывает :) Как по ценам, так и по качеству.

  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +1

    Всё так, но есть в этом и минусы. Распределить команду и получить профит от часовых поясов не получится потому как всё основное происходит устно в курилке. По той же причине тяжело через год вспомнить, почему было принято то или иное решение.


    У нас в Stay.com была распределённая команда, но мы пару раз в год прилетали в офис. Во это время формировали задачи, планировали, кодили самое сложное вместе. Потом разъезжались и дожимали удалённо, получая профит от часовых поясов.

  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    +1

    Менталитет я бы в плюс особо не ставил. Лондон очень многонациональный. В Паддингтоне уже не англичане, а Кенсингтон с вами дел иметь не будет. В общем, как попадёт.


    Лондон прилично дороже Москвы. Под 2000 за стакан пива и пюрешку с сосиской, насколько помню. Ну и в магазинах ценник повыше.


    Плюс совершенно ужасные внутри здания и проводка. Не даром там на каждой розетке тумблер. Сначала засовываешь вилку, а потом уже включаешь. Иначе сноп искр.


    Ну а так, если на родине ничего не держит, достали всякие законы на тему VPN или просто хочется пожить в очень красивом городе с богатой историей и прокачать английский — идеально.

  • Как получить оффер в Badoo в день собеседования. Часть вторая, для PHP-разработчика
    0

    Не сказал бы, что Лондон так уж выигрывает. Особенно учитывая покупательскую способность.

  • Yii 2.0.12
    0

    Фикснули в master.

  • Yii 2.0.12
    0

    Возможно, будет даже раньше.

  • Yii 2.0.12
    0

    Да, 1000 по n^1024. Довольно типично. На тему дебажить или нет — согласен.

  • Yii 2.0.12
    0

    Фоновый импорт-экспорт, например.

  • Путешествие внутрь Avito: платформа
    0

    У меня тоже. Оказалось, косячит DNS у провайдера (или ещё на каком-то уровне). Только через VPN нормально работает.

  • Yii 2.0.12
    +3

    Что именно смотреть? Как именно слетели? Как были прописаны правила?