flancer32.com
Коллега IvanKlut в своей статье "В поисках идеальной модели лицензирования" поднял вопрос о несовершенстве существующих лицензий, используемых при разработке OpenSource-проектов, с точки зрения монетизации усилий разработчиков, и предложил "поразмыслить об устройстве более эффективной экосистемы разработки сложных программных продуктов сообществом независимых разработчиков" (с).
Под катом мои субъективные соображения на этот счет.
Впервые с Magento (тогда еще "единичкой") я столкнулся лет, эдак, 6 назад. С тех пор так с ней и работаю, с большей или меньшей плотностью. Изначально пост хотел назвать "Quo vadis, Magento?", но, как оказалось, этим популярным вопросом сообщество задавалось уже не раз — и когда Magento приобреталась ebay'ем, и когда продавалась, и все то время, пока делалась "двоечка", да и поныне этот вопрос остается актуальным (раз уж даже у меня возникло желание использовать такое название). Поэтому пост называется так, как он называется.
Под катом же я попытался сформулировать свое собственное (сиречь — субъективное) вИдение перспектив этой платформы — полное брюзжания и уныния. Без подробных выкладок. Без детальных размышлений. Без доказательств. И главное —
Когда-то, давным-давно, когда я еще учился программировать на Паскале, мне пришлось на лабораторке переделывать одну собственную функцию — нужно было в результатах возвращать не просто число, а число и строку. Как было бы хорошо, подумал я тогда, если бы в результате можно было возвращать множество переменных, как это сделано для входных параметров. Подумал, вздохнул и начал создавать структуру для передачи обратно в вызывающую функцию двух параметров за раз.
Аутентификация пользователей — базовый функционал подавляющего большинства web-приложений. Этот функционал имплементирован с помощью различных языков программирования и поддерживается различными репозиториями ("хардкод", файлы, базы данных, LDAP, ...).
В предыдущей своей публикации я высказал смелое заблуждение "Пока же создание очередного web-приложения зачастую начинается с проектирования собственной структуры данных для аутентификации пользователей", на что мне было скинуто несколько ссылок на некоторые имплементации аутентификации (в основном — на PHP). Под катом — сравнение структур User-моделей этих имплементаций.
Я довольно давно участвую в разработке web-приложений. Это не высоконагруженные приложения (типа Facebook или Gmail) — там, разумеется, своя специфика. Мои приложения были небольшими (можно было уместить на одном физическом сервере), но функционально насыщенными — финансовые, e-commerce. Я не работал в больших командах, зато пощупал весь спектр технологий, начиная от сборки аппаратуры в стойке и заканчивая редактированием CSS.
В какой-то момент поймал себя на мысли, что моя деятельность в области разработки web-приложений чем-то начала напоминать мне охоту моих далеких предков на мамонта (если под мамонтом подразумевать задачу, которую нужно решить). Только предки полагались на свою физическую силу, а мы вместо этого используем силу своего интеллекта. Но и как и прежде большую добычу не завалить в одиночку — нужны совместные усилия всех охотников.
Под катом я попытался собрать своё видение относительно наиболее важных с моей точки зрения аспектах в разработке web-приложений.
Тенденция перехода от сборки HTML-страниц на стороне сервера к их сборке на стороне клиента уже даже не тенденция, а тренд. Magento 2, шагая в ногу со временем в меру своих возможностей, также пытается быть в тренде, разнося обработку данных и их представление. Как простому разработчику заглянуть в "чистые" данные, если их представление вынесено достаточно далеко? Есть множество других хороших решений (начиная c tcpdump), и есть swagger.
Swagger достаточно хорошо интегрирован в Magento 2 (если только вам в голову не пришла дурацкая затея изменить код для "default" витрины). Все, что нужно для того, чтобы начать разглядывать "чистые" данные в Magento 2 с точки зрения удаленного приложения — использовать интегрированный в нее Swagger. В данном материале я не рассматриваю особенности использования самого Swagger'а, а просто привожу пример того, как использовать Swagger, интегрированный в Magneto 2, в режиме анонимного пользователя и в режиме аутентифицированного пользователя.
Процесс создания объектов в Magento 2 включает в себя некоторые особенности, присущие именно Magento 2 и связанные с автоматической генерацией кода при определенных условиях (proxies, factories и interceptors). С interceptor'ами для меня было все более-менее понятно, а вот назначение двух других типов генерируемых классов было скрыто туманом непонимания. И если относительно фабрик у меня туман пока еще остается, то вот относительно прокси-классов — туман развеялся.
Ни один разработчик в здравом уме и трезвой памяти при разработке сложных приложений (> 100K LOC, например) не станет отрицать необходимость использования тестирования вообще и модульного тестирования (unit tests) в частности. Это так же верно, как и то, что каждый разработчик постарается исключить бессмысленную работу из творческого процесса создания приложения. Где же та грань, которая отделяет необходимость от бессмысленности, если мы говорим о модульном тестировании в контексте сложных приложений? Пару своих соображений по этому поводу я изложил под катом.
Краткая памятка по созданию гридов в админке Magento 2. В качестве примера я взял простой грид из трех колонок, данные для которого (коды стран по ISO 3166) поставляются из прописанного в коде массива. Для того, чтобы сфокусироваться на основных аспектах построения грида я отбросил из дескриптора UI-компонента максимум возможного (дополнительные кнопки, фильтры, сортировка, bookmarks, ...) и часть настроек перенес в конструктор провайдера данных для грида. Если можно сделать еще короче без потери читабельности — с максимальным удовлетворением внесу соответствующие правки (UPD: спасибо коллеге Oxidant за контроллер). Код примера на github'е.
Есть пара весомых поводов не использовать рекурсию, но это не повод не использовать рекурсию вообще. Программы, во-первых, создаются программистами для программистов, и лишь во-вторых — программистами для компьютеров. В итоге, некоторыми годными программами могут пользоваться неподготовленные люди. Рекурсия имеет одно безусловное преимущество перед итерацией — читабельность. Когда программист создает программы для себе подобных, рекурсия имеет право на существование до тех пор, пока не докажет обратного (т.е. — не будет запущена на компьютере и не поперхнется реальными данными).
Тестирование — это, по сути, создание программ для программ, позволяющее программистам отодвигать порог непреодолимой сложности в разрабатываемых приложениях. Столкнувшись на днях с необходимостью написать юнит-тест для рекурсивного метода я был неприятно удивлен необходимостью мокировать сам тестируемый метод. Альтернатива — создавать такие входные данные, которые бы позволяли протестировать все ветки рекурсии в одном тестовом методе. В перспективе вырисовывалось не снижение сложности, а наоборот — ее увеличение. Порывшись в интернетах, я обнаружил кучу информации о том, чем нехороша рекурсия, массу советов, как перейти от рекурсии к итерации, но так и не нашел на русских формах того, что искал — как тестировать рекурсивный метод. Решив, что подготовить тестовые данные для трех проходов по коду — не такая уж непреодолимая сложность, отложил эту задачу до утра. Под катом решение, пришедшее в голову за ночь, позволяющее разбивать тестирование рекурсивных методов на части.
Под катом пример добавления в гриде админки Magento 2 дополнительной колонки с данными из таблицы, связанной с основной таблицей грида, и "грязный хак" для работы фильтра по дополнительной колонке. Допускаю, что это не вполне "Magento 2 way", но это как-то работает, а потому — имеет право на существование.
Иногда при обработке запросов в web-приложениях возникает необходимость в кратковременном сохранении промежуточной информации. Для записи информации в браузер клиента используется механизм cookies, для сохранения данных в пределах одного запроса — реестр, для сохранения данных между запросами — сессии. Под катом — примеры для Magento 2.
public function __construct(
\Psr\Log\LoggerInterface $logger,
\Zend_Db_Adapter_Pdo_Abstract $dba,
ISomeService $service,
...
) {
$this->_logger = $logger;
$this->_dba = $dba;
$this->_service = $service;
...
}setUp() в unit-тестах может существенно облегчить жизнь, если нужно несколько раз создать один и тот же набор mock'ов для тестирования различных особенностей реализации разрабатываемого класса.Одним из главных аспектов при разработке программного обеспечения вообще и web-приложений в частности я считаю способность программного обеспечения быть изменяемым — адаптируемым к изменениям окружающего мира. Это не значит, что разработчик должен заранее предусмотреть будущие изменения среды обитания своего кода, это значит, что код должен переносить множество циклов рефакторинга, оставаясь при этом работоспособным как можно дольше. А для этого нужно, чтобы последствия изменений, вносимых в код, были либо обозримы, либо предсказуемы. Под катом я суммировал свое понимание областей сокрытия кода, сформировавшееся в результате тесных, практически интимных, отношений с Magento 2 (платформой для построения интернет-магазинов). Изложенное ниже относится во-первых, к языку PHP, во-вторых — к web-приложениям, в-третьих — ко всему остальному.