16го Декабря в Киеве прошла самая большая техническая конференция посвященная платформе Magento и eCommerce в целом. Конференция проходила в 4 параллельных потока, на которых было презентовано 30 докладов и воркшопов. Конференцию посетили 600+ участников.

Главному ивенту предшествовал Magento Contribution Day, проводимый в офисе компании Magento за день до этого и собравший более 100 человек, которые вместе с Magento Core программистами и архитекторами работали над улучшением платформы и исправлением багов. А также над разработкой новой функциональности системы — Multi-Source Inventory.



В ходе ивента было поставлено 40+ Pull Request в Magento 2 репозиторий.

В данном посте предлагаю ознакомиться с видео всех выступлений, которые вы найдете под катом. С программой конференции MageConf 2017 можно ознакомиться перейдя по ссылке.

PHP — это программное обеспечение, написанное на языке С. Кодовая база PHP содержит около 800 тысяч строк кода и в седьмой версии была существенно переработана.

В этой статье мы рассмотрим, что изменилось в движке Zend седьмой версии по сравнению с пятой, а также разберёмся, как можно эффективно использовать внутренние оптимизации. В качестве исходной точки возьмём PHP 5.6. Зачастую многое зависит от того, как те или иные вещи написаны и представлены движку. При написании критически важного кода необходимо уделять внимание его производительности. Изменив несколько мелочей, вы можете сильно ускорить работу движка, зачастую без ущерба для других аспектов вроде читабельности кода или управления отладкой. Свои рассуждения я докажу с помощью профилировщика Blackfire.

Архитектура большинства Java(и не только) приложений сегодня предусматривает возможность расширения функционала посредством различного рода магических воздействий на код. В последнее время это также стало возможно, если использовать какой-нибудь модный фреймворк или IoC-контейнер. Но что делать, если приложение долгоживущее и слишком сложное для того, чтобы переводить его на использование какого либо фреймворка?

В последнем приложении, с которым я работал, был реализован на тот момент неизвестный мне велосипед SPI механизм, который искал в джарках текстовые файлы вида META-INF/services/<qualified interface name> и брал оттуда название нужного класса, реализующего этот интерфейс, далее этот класс использовался как расширение. Поискав в интернете, узнал, что Service Provider Interface(SPI) представляет собой программный механизм для поддержки сменных компонентов и что этот механизм уже довольно давно используется в Java Runtime Environment(JRE), например в Java Database Connectivity(JDBC):

ps = Service.providers(java.sql.Driver.class);
try {
  while (ps.hasNext()) {
    ps.next();
  }
} catch (Throwable t) {
  // Do nothing
}

Благодаря этому коду приложения больше не нуждаются в конструкции Class.forName(<driver class>) (хотя и с ней будут работать), JDBC драйверы будут подгружены автоматически при первом обращении к методам класса DriverManager.

SPI механизм также используется в Java Cryptography Extension(JCE), Java Naming and Directory Service(JNDI), Java API for XML Processing(JAXP), Java Business Integration(JBI), Java Sound, Java Image I/O.

Как это работает?

Весь смысл в разделении логики на сервис(Service) и провайдеры(Service Providers). Ссылки на провайдеры сохраняются в джарках расширений в текстовом файле(UTF-8) META-INF/services/<qualified service class>, в каждой строке полное имя класса провайдера. Пустые строки и комментарии(начинающиеся с символа #) игнорируются. Ограничения на провайдеры: они должны реализовывать интерфейс либо наследоваться от класса сервиса и иметь конструктор по умолчанию(zero-argument public constructor).

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

Введение

Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами. Для чего они нужны? Они нужны, например, для моделирования прикладной области. Но как отношения отражаются в программном коде? Данное небольшое исследование пытается ответить на этот вопрос — показать эти отношения в коде.

В данной статье будет рассмотрен Service Layer в Magento 2 и сервисы (API интерфейсы) для управления сущностями, которые были описаны в предыдущей статье, посвященной проектированию и выделению доменных сущностей для системы управления складом (Inventory).

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

*Поломанный кран в офисе Magento и быстрое решение воплощенное в жизнь одним из инженеров — типичный Backward Compatible фикс.