modZone.ru

И снова всем здрасьте! Делая перекрестные код-ревью накопился приличный багаж интересных моментов. Интересных с точки зрения примеров как лучше не делать. Очень часто вижу такую конструкцию: if (условие) { $foo = 'bar'; } else { $foo = 'baz'; } Такая конструкция несёт дополнительную когнитивную нагрузку. Тоже самое можно сделать через тернарный оператор. И читается это легче: $foo = (условие) ? 'bar' : 'baz'; Конечно, это дело привычки и предпочтений. Но так советуют делать авторитетные в PHP сообществе разработчики. Так сказать best practices. Ваш код - это ваше отражение. По нему будут судить о вашем профессиональном уровне и вовлеченности в язык. Также до сих пор встречается частный случай от описанного, где нужно получить булев результат: $single = isset($elements) && count($elements) === 1 ? true : false; Думаю, не нужно объяснять, что само условие дает булев результат, поэтому его будет вполне достаточно: $single = isset($elements) && count($elements) === 1; Последний раз, когда я на код-ревью обратил на это внимание, мне аргументировали, что там наоборот нужно при положительном условии возвращать false. Пришлось коллегу посвятить в тайное знание об операции отрицания через "!". Уверен, что многие разработчики знают и второй способ - перевернуть отрицание условия с логическими "И" на логические "ИЛИ". 😉

Всем привет! Давненько ничего не писал. С MODX уже не работаю. Поэтому нет подходящих кейсов, которыми хотелось бы поделиться. Плюс загружен работой по самое горло. А в выходные, если выдается свободная минутка, занимаюсь самообразованием. Изучил Go. Прокачиваю скилы. Есть запрос от команды на разные утилиты. Но собственно, рассказать хотел о другом. Хочу поделиться одним случаем. Я на код-ревью всегда прошу исправлять места, где в параметрах функций вместо true/false указано 1/0. Обычно это аргументируют, что это одно и тоже. Но это конечно же не так и может когда-нибудь выстрелить в ногу. В итоге, на прошлой неделе эта мина сработала. И теперь у меня есть факт. Делая очередное ревью кода коллеги обнаружил, что в json_decode($json, 1) единичку заменили на $userId (нужно было везде хардкорный id админа заменить на динамический). И в запаре или автозаменой эту единичку заменили. Причина не так важна. Сделать это может даже опытный разработчик. К чему я это? Всегда используйте точные типы данных. Во-первых, это помогает избежать таких потенциальных ошибок. Во-вторых, читать такой код значительно проще. Согласитесь, что код if (count($data) > 0) понятнее, чем if ($data). Ну а уж написать true вместо 1 вообще не сложно. )

В свое время я рассказывал про фреймворк Workerman, который можно использовать как Websocket сервер. Или для асинхронных задач. Он очень простой и легко настраивается. У нас была задача, где нам понадобился websocket сервер. Я вспомнил про Workerman и решил прикрутить на наш рабочий сайт. Через 5 минут после запуска мы благополучно упали. Он сожрал всю память. На тестовом стенде мы нагрузочное тестирование не делали, вроде бы зачем. Ну и вот поплатились. Короче, вывод следующий - MODX в EventLoop не может очень сильно. Я ограничил жизнь коннектов 2-мя минутами, убивал объекты MODX, чтобы очистить память, настроил перезапуск сервера каждую ночь. Но при большом наплыве посетителей приходилось еще и днем принудительно перезагружаться. Т.е. я мониторил его 24/7. В итоге мы от него отказались. Но Workerman в целом мне понравился. Формат ТГ-канала не позволяет подробно описать все тонкости. Если найду время, напишу статью, для чего нужен Workerman и как им пользоваться, чтобы не наступать на наши грабли.

Ребята из SpaceWeb перенесли сайт к себе. Проверил, всё работает. Я практически палец о палец не ударил. Так что вопрос о судьбе сайта снят с повестки на некоторое время. Прощай modhost. Удобная была площадка. Очень жаль. Всем мир ✌️

К нам в команду прилетела срочная задача запилить сайт средней сложности. Даже чуть проще. Для этого вполне подойдет CMS. Битрикс никто из нас не знает. Поэтому решили делать на MODX. Но у нас все сайты работают в Kubernetes. А, как вы понимаете, у MODX с этим есть проблемы. Вернее даже, не с самой контейнеризацией, а CI/CD. Это уже более серьёзный уровень разработки. А насколько я понимаю, модыксеры даже гитом пользуются не часто. Помочь с этим может Gitify. Но он совсем не швейцарский нож, как утверждал Иван Климчук. Возможно в далеком 2015 году это было так. Но сейчас это очень спорное утверждение. Механизм установки пакетов не подходит для развертывания окружения в Кубере. Он сильно отличается от того же композера. А также отсутствует механизм миграций - можно только дампить базу целиком. Что совсем не подходит для командной разработки. В общем, к чему я это. Я не смог нагуглить примеров решения похожей задачи. Только про развертывание MODX в контейнере. Поэтому придётся пилить свой инструмент для нормального развертывания рабочих окружений MODX в контейнерах. И самое простое - доработать Gitify. Пока не знаю, что из этого получится. Но если получится, то будет вполне себе рабочий юзкейс для модыксеров. П.С. Если у кого есть примеры работы с Kubernetes, скиньте плиз.

Коллеги, есть вопрос - нужен ли сайт modzone.ru сообществу MODX? Как все уже слышали - хостинг modhost закрывается. И тем самым поставил передо мной задачу - что делать с сайтом? С одной стороны жалко, с другой - времени на него нет. Его уже давно пора причесать. Из-за не очень адаптивного дизайна поисковики его понизили. Хотя, на релевантные запросы он показывается в первых строчках. Но посещений не очень много. Поэтому не вижу особого смысла в нем. А личный блог мне не особо нужен. В общем, я в раздумьях 🤔

В рамках продолжения оптимизации сайта под высокие нагрузки пришлось решишь проблему, описанную в предыдущем посте. У нас скорость загрузки страницы выросла почти в 3 раза. Ну и до кучи решил закинуть все хотелки, о которых писал раньше - это алиасы для файловых элементов и отдельный класс для файловых сниппетов, чтобы избавиться от костыля ввиде создания дополнительного файла с хэшем в виде названия, необходимого для сниппетов из БД. Благодаря отдельному классу пропадает бесючая проблема кэширования, когда правки в файловом сниппете не работают, пока не очистишь кэш. Как появится свободное время, напишу статью с примерами. В репе править не планирую.

https://modzone.ru/blog/2024/03/09/another-optimization-of-pdotools/

[pdoTools] Алиасы для элементов В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе разработки сайта с большим количеством файловых элементов. Согласитесь, гораздо проще запомнить и написать такой вызов {'test_snippet' | snippet} чем такой {'@FILE snippets/folder/test_snippet.php' | snippet} Такой же подход используется в Laravel например для middleware. Этот функционал также легко позволяет использовать в качестве модификаторов файловые сниппеты. Указанный модификатор перед вызовом несуществующего сниппета заменяется на файловый.

Всем привет! Обновил pdoTools и для MODX 2.x и для MODX 3. Времени хватило только на исправление критических багов. Исправления коснулись pdoPage: - Пофиксена XSS уязвимость сниппета pdoPage. - Допилена поддержка файловых элементов для pdoPage (фикс от создателя pdoTools Василия Наумкина). На этом всё. Не очень много получилось, но сколько смог.

Релиз PHP 8.2 Большое обновление языка. Содержит множество новых возможностей, включая readonly-классы, самостоятельные типы null, false и true, устаревшие динамические свойства, улучшение производительности и многое другое. https://www.php.net/releases/8.2/ru.php

[ZoomX] Новая версия 3.6.0. Обсудив с товарищами и взвесив все "за" и "против" я решил ни с кем не считаясь добавить возможность формирования $_POST массива для JSON запросов через метод POST. 😁 Нехай будет. Ежели чего, эту фичу можно отключить в настройках. Спасибо за внимание!

https://ru.hexlet.io/blog/posts/zachem-izuchat-php-reyting-perspektivy-sfery-primeneniya

[ZoomX] Наконец в выходные получилось разобрать бэклог ZoomX и реализовать некоторые задумки. Доработок не очень много, но они важные. Итак, что было сделано: - Добавлена поддержка контекстов. - Файловые плагины доступны в контексте mgr. - Исправлены некоторые ошибки, в том числе ошибка с роутами в пользовательской директории. Особо хочу обратить внимание, что теперь в роутах все адреса нужно начинать со слеша /, а не только главную страницу. Чтобы не сломать обратную совместимость роуты будут будут работать и без слеша, но для этого задействуется дополнительная обработка, что несет небольшие накладные расходы.

Law of Demeter (Закон Деметры, LOD) Этот закон часто используют вместе с темой Tell Don't Ask. Его идея в том, что объект должен обладать ограниченным знанием о других объектах и модулях, взаимодействовать только с теми, кто имеет к нему непосредственное отношение. Формально правило звучит так, что в клиентском коде вы можете вызывать методы объектов, которые: ✅ Были переданы как аргументы; ✅ Были созданы локально; ✅ Являются глобальными; ✅ Собственные методы; Пока что непонятно зачем это всё. Давайте разбираться. Основная задача — создать условия для слабой связанности (loose coupling) между объектами. Но за счёт чего? 🌈 Представьте, вы находитесь в магазине, хотите купить товар стоимостью 25$. Вы дадите продавцу 25$ или вы отдадите продавцу свой кошелек, чтобы тот достал 25$? Давайте разберём этот пример. 👉 В первом случае мы явно знаем, что у объекта SomePerson есть Wallet, который мы хотим получить, чтобы достать (вычесть) из него какую-то сумму денег. Таким образом мы создаём сильную связь (tight coupling) с объектом кошелька, а также раскрываем особенности внутренней реализации. ❓ Чем же лучше второй вариант? Когда у SomeAnotherPerson мы вызываем метод subtractMoney, это нам даёт дополнительную гибкость, возможность легко изменить внутреннюю реализацию данного метода, не изменяя другие участки кода. Как бонус появляется information hiding, а также это дело менее проблематично мокать в тестах. 🤓 LOD также называют законом "одной точки" (one dot), т.к. ноги растут из Java. В нашем же случае о его применении стоит задуматься при виде более одной стрелочки ->. Обращаю внимание, что речь идёт о методах (или свойствах), которые позволяют получить промежуточный объект, утрируя - о геттерах. То есть две стрелочки в каком нибудь fluent interface (напр. $filter->limit(10)->offset(0)) сюда не относятся. 🙈 У закона Деметры тоже есть свои минусы. Одним из них является необходимость создания большого количества методов-адаптеров. Если вы чувствуете, что классы становятся перегруженными - это признак плохого объектно-ориентированного дизайна. ❓ Можно ли нарушать закон Деметры? Руководствуйтесь здравым смыслом. Если у вас, например, вложенные DTO, которые предназначены для транспортировки объектов, то нет никакого смысла наворачивать что-то подобное сверху. Используйте только там, где это уместно и помните о преимуществах 😉 #php #oop #middle #source

[pdoTools] В новой статье я расскажу про ещё один подводный камень использования шаблонизатора Fenom в MODX, про который знают единицы разработчиков. https://modzone.ru/blog/2022/08/21/fenom-and-element-parameters/

Поговорим о времени В комментариях к этому посту было несколько просьб подробнее рассказать о часовых поясах. В этом посте я постарался собрать несколько важных тезисов по данной теме. 📚 Теория: 🕔 Всемирное время — UTC. Было введено вместо устаревшего среднего времени по Гринвичу (GMT), поскольку шкала GMT является неравномерной и связана с суточным вращением Земли. Шкала UTC, в свою очередь основана на равномерной шкале атомного времени (TAI). Часовые пояса вокруг земного шара выражаются как положительное или отрицательное смещение относительно UTC. ❗️ Часовой пояс и смещение — не одно и то же. Почему? Всему виной летнее время (DST — Daylight Saving Time). 👉 Часовой пояс может иметь одно или несколько смещений. Какое именно время принято в качестве стандартного, зависит от текущих политических и/или экономических причин в конкретной стране. Так как время по UTC не переводится ни зимой, ни летом, то, для тех мест, где есть переход на летнее время и происходит смещение относительно UTC. ⌚️ Unix время — это количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года и представлено целым числом. 🔧 Практика: ✅ Следует работать с Unix временем. Такой формат удобно использовать для сравнения и хранения дат. При необходимости его легко преобразовать в любой подходящий формат (и обратно). На всякий случай упомяну про "критические даты", например 19 января 2038 года в 03:14:08 число секунд достигнет 2^31, что может привести к ошибочной интерпретации этого числа как отрицательного. Возможное решение проблемы состоит в использовании не 32-битной, а 64-битной переменной, которой хватит на 292 млрд лет. ✅ Если вам нужно хранить время только что произошедшего события, текущее время, по факту определённого действия, храните его в UTC (напр. для PostgreSQL —TIMESTAMP WITH TIME ZONE). Это могут быть записи в логах, время регистрации пользователя, совершения заказа или отправки письма. ✅ Нужно ли хранить часовой пояс пользователя? Да, только с помощью информации о часовом поясе мы можем сделать вывод о том, какое смещение у него сейчас или будет через пол года. Ведь, повторюсь, один часовой пояс может иметь несколько смещений. ✅ Если время привязано к пользователю — сохраняйте локальное время пользователя и его смещение. Фактически 1660050128, 2022–09–9T16:02:08+03:00 и 2022–09–9T13:02:08+00:00 — это одно и то же время. Сохраняя смещение мы оставляем важную информацию, которая может оказаться нужной как с точки зрения бизнеса, так и для внутренней отладки, принятия других решений. Иными словами если у вас есть информация, и её хранение вам не доставляет (существенных) дополнительных усилий — не выбрасывайте её. Вы не сможете получить её обратно. ———— 🔥 Вот те самые несколько нюансов, которыми хотелось поделиться. Пишите в комментарии, если есть что дополнить, возможно вместе соберём еще несколько дельных советов😉. #php #datetime #middle

Обновился pdoTools для MODX3. Исправлены почти все баги с гитхаба. Коих было не особо много. Поэтому я перевёл релиз в стабильную версию.

Fenom значительно превосходит стандартный парсер MODX. Но всегда ли это превосходство бесспорно? https://modzone.ru/blog/2022/05/01/fenom-vs-modx-tags/