Если сообщество или команда переведёт и будет поддерживать — будет. Так-то я за, но самостоятельно перевод и его поддержку не втащу. Я пишу исходную документацию на английском. Некоторые члены команды, на русском. В этом случае она доступна сразу: https://github.com/yiisoft/yii-cycle/tree/master/docs
Ничего не мешает одновременно и шарить и рассказывать всё-таки основы. Если в приложении полно тривиальных XSS (а это в каждом первом где в команде нет того, кто хоть что-то понимает по теме), то смысла искать и фиксить там 0day никакого.
Пакеты, по идее, всегда должны общаться с другими пакетами через контракт-интерфейс. У Мартина обычно это подразумевается и говоря об изменениях он чаще всего имеет ввиду изменение реализации без изменения контракта. То есть чтобы меняя алгоритм работы не пришлось менять интерфейс и использующие его пакеты.
На самом деле SOLID и пакетные принципы довольно расплывчаты на тему определений и их трактования. На данный момент я думаю что понял их правильно, но если нет — поправьте.
Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?
Два года назад. PSR-12.
Но с тех пор появились занятные драфты:
https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md
Там и плюсы и минусы. Технически одни минусы. В плане размера аудитории плюс.
Подкаст стоит послушать прежде чем делать выводы.
Это я прекрасно знаю. Гайды в Yii 3 тоже будут неплохие, с переводом... ну, тут как сил хватит.
Если сообщество или команда переведёт и будет поддерживать — будет. Так-то я за, но самостоятельно перевод и его поддержку не втащу. Я пишу исходную документацию на английском. Некоторые члены команды, на русском. В этом случае она доступна сразу: https://github.com/yiisoft/yii-cycle/tree/master/docs
Хороший вопрос. https://rmcreative.ru/blog/post/yii-3-i-psr
Кому?
Для участников уже есть. В паблике пока нет.
На месте.
Не должно. Никто не хочет в Битрикс :)
Machine Learning исключите.
Она, в принципе, не очень простая.
OneDrive по соотношеню цена-качество хорош. В отличие от Яндекс.Диска не режет скорость при работе с файлами через API.
Не привязываемся к конкретной ORM.
ActiveRecord будет, но опционально. Тоже отдельный пакет.
По Yii 2 план поддерживать около 5 лет после релиза Yii 3. Это как минимум.
Какие-такие проблемы?
Ничего не мешает одновременно и шарить и рассказывать всё-таки основы. Если в приложении полно тривиальных XSS (а это в каждом первом где в команде нет того, кто хоть что-то понимает по теме), то смысла искать и фиксить там 0day никакого.
У нас выглядит не крайне костыльно. Но да, большая часть фич специфичных просто теряется.
Нормальная история. Фреймворк всё-таки подразумевает что знакомство с основами пройдено.
Пакеты, по идее, всегда должны общаться с другими пакетами через контракт-интерфейс. У Мартина обычно это подразумевается и говоря об изменениях он чаще всего имеет ввиду изменение реализации без изменения контракта. То есть чтобы меняя алгоритм работы не пришлось менять интерфейс и использующие его пакеты.
На самом деле SOLID и пакетные принципы довольно расплывчаты на тему определений и их трактования. На данный момент я думаю что понял их правильно, но если нет — поправьте.
Я бы так не сказал. Тот же Android SDK без документации было бы очень неприятно использовать.
Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?