Если решением архитектурных вопросов вроде выбора между RabbitMQ и Kafka, то книг на эту тему ещё не написано.
Серьёзно ничего нет в виде книг, описывающего на что смотреть при выборе очередей и хранилищ? Чего-то вроде https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9303425, но более обобщённого. Что-то не верится что это какие-то сакральные знания.
Если сообщество или команда переведёт и будет поддерживать — будет. Так-то я за, но самостоятельно перевод и его поддержку не втащу. Я пишу исходную документацию на английском. Некоторые члены команды, на русском. В этом случае она доступна сразу: https://github.com/yiisoft/yii-cycle/tree/master/docs
Ничего не мешает одновременно и шарить и рассказывать всё-таки основы. Если в приложении полно тривиальных XSS (а это в каждом первом где в команде нет того, кто хоть что-то понимает по теме), то смысла искать и фиксить там 0day никакого.
Пакеты, по идее, всегда должны общаться с другими пакетами через контракт-интерфейс. У Мартина обычно это подразумевается и говоря об изменениях он чаще всего имеет ввиду изменение реализации без изменения контракта. То есть чтобы меняя алгоритм работы не пришлось менять интерфейс и использующие его пакеты.
На самом деле SOLID и пакетные принципы довольно расплывчаты на тему определений и их трактования. На данный момент я думаю что понял их правильно, но если нет — поправьте.
Серьёзно ничего нет в виде книг, описывающего на что смотреть при выборе очередей и хранилищ? Чего-то вроде https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9303425, но более обобщённого. Что-то не верится что это какие-то сакральные знания.
Два года назад. 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 без документации было бы очень неприятно использовать.