Привет! Меня зовут Павел и я Magento 2 бэкенд-разработчик. Когда-то давно, когда я только начинал знакомство с Magento 2 (для краткости буду называть ее M2), мне понадобилось автоматизировать обработку однотипных событий при разработке одного решения. Тогда я удивился, насколько мало информации на русском языке об интеграции очередей в M2. Время идет, а ситуация не меняется: информации об этом на просторах рунета все так же мало. Раскроем эту тему. Для начала кратко поговорим про очереди: что это такое и зачем они нужны, потом рассмотрим интеграцию M2 с популярным менеджером очередей Rabbit MQ (далее по тексту — RMQ), а также напишем простую реализацию работы с очередями в качестве примера. Погнали!

В процессе обсуждения статьи "Почему я «мучаюсь» с JS" у меня сложилось понимание, что связка export / import в JS является базой для указания зависимостей между элементами кода (классами и функциями). А так как современные приложения вышли за рамки однофайловых и давно уже строятся из блоков, то выстраивание зависимостей между элементами кода имеет весомое значение. Настолько весомое, что в знаменитой аббревиатуре SOLID этому посвящена отдельная буква — D (Dependency inversion — инверсия зависимостей, не путать с Dependency injection — внедрение зависимостей).

Размышляя над тем, как связываются зависимые элементы кода в JS через export / import, я пришёл к выводу, что не все зависимости в коде es6-модулей SOLID'ных приложений можно описать инструкциями import. Излагаю свои соображения, чтобы коллеги могли указать, где я ошибаюсь, или подтвердить мои выкладки.

PHP, начиная с 7 версии, кардинально изменился. Код стал куда быстрее и надёжнее, и писать его стало намного приятнее. Но вот, уже релиз 8 версии! Ноябрь 26, 2020 — примерно на год раньше, чем обещали сами разработчики. И всё же, не смотря на это, мажорная версия получилась особенно удачной. В этой статье я попытаюсь выложить основные приятные изменения, которые мы должны знать.

1. JIT

Как говорят сами разработчики, они выжали максимум производительности в 7 версии (тем самым сделав PHP наиболее шустрым среди динамических ЯПов). Для дальнейшего ускорения, без JIT-компилятора не обойтись. Справедливости ради, стоит сказать, что для веб-приложений использование JIT не сильно улучшает скорость обработки запросов (в некоторых случаях скорость будет даже меньше, чем без него). А вот, где нужно выполнять много математических операций — там прирост скорости очень даже значительный. Например, теперь можно делать такие безумные вещи, как ИИ на PHP.
Включить JIT можно в настройках opcache в файле php.ini.
Подробнее 1 | Подробнее 2 | Подробнее 3

2. Аннотации/Атрибуты (Attributes)

Все мы помним, как раньше на Symfony код писался на языке комментариев. Очень радует, что такое теперь прекратится, и можно будет использовать подсказки любимой IDE, функция "Find usages", и даже рефакторинг!

Забавно, что символ # также можно было использовать для создания комментариев. Так что ничего не меняется в этом мире.

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)
Книга «Безопасность в PHP» (часть 3)
Книга «Безопасность в PHP» (часть 4)

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

1. Для случайного выбора опций из пула или диапазона известных опций.
2. Для генерирования векторов инициализации при шифровании.
3. Для генерирования непредсказуемых токенов или одноразовых значений при авторизации.
4. Для генерирования уникальных идентификаторов, например ID сессий.

Первая часть: Основы работы с видео и изображениями

27 января 2010 года один Крупный Мыслитель объявил о смерти ПК. Прошло десять лет, и ПК здравствует, хотя путешественник во времени из 2010 года мог бы и не узнать его. Вот как этот вымирающий вид эволюционировал и выжил.

Перевод статьи Christopher Pitt.

PHP разработчикам не так уж часто приходится следить за расходом памяти в своих приложениях. Сам движок PHP неплохо подчищает мусор за нами, да и модель веб-сервера с контекстом исполнения, "умирающим" после выполнения каждого запроса, позволяет даже самому плохому коду не создавать больших долгих проблем.

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

Последняя проблема и будет рассмотрена в этом уроке.

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

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

Проблема хрупкого базового класса

У нас проблемы с промисами

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Вступление

• Внешнее подключение media query
  
• Больше чем просто размер viewport
  
• Не только смартфоны
  
• Инструмент для работы с media query
  
• Выделяйте специфичное
  
• Breakpoints когда и сколько?
  
• Второстепенные breakpoints
  
• Относительные единицы измерения
  
• Условная загрузка
  
• Список использованных ресурсов
  

Аннотация

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

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