[ZoomX]
Как и обещал, написал статью с разбором механизма кэширования элементов.
https://modzone.ru/blog/2022/04/17/caching-elements-in-zoomx/
Как и обещал, написал статью с разбором механизма кэширования элементов.
https://modzone.ru/blog/2022/04/17/caching-elements-in-zoomx/
modzone.ru
Кэширование элементов в ZoomX | Зона разработки
Кому интересно узнать, какой шаблонизатор быстрее (стандартный, Fenom или Smarty), читаем статью https://modx.pro/development/22872
Русскоязычное сообщество MODX
Сравнение шаблонизаторов MODX, Fenom и Smarty
В очередной раз прочитав утверждение, что Fenom быстрее стандартного парсера, решил провести указанный в документации pdoTools тест, чтобы расставить все точки над и. Но решил сделать это не отдел...
Многие разработчики знают о проблеме кэширования кода файловых сниппетов. Она сильно раздражает. Попробуем её обойти.
https://modzone.ru/blog/2022/04/30/pdotools-%D0%BB%D0%B0%D0%B9%D1%84%D1%85%D0%B0%D0%BA-%D0%B4%D0%BB%D1%8F-%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D0%BD%D0%B8%D0%BF%D0%BF%D0%B5%D1%82%D0%BE%D0%B2/
https://modzone.ru/blog/2022/04/30/pdotools-%D0%BB%D0%B0%D0%B9%D1%84%D1%85%D0%B0%D0%BA-%D0%B4%D0%BB%D1%8F-%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D0%BD%D0%B8%D0%BF%D0%BF%D0%B5%D1%82%D0%BE%D0%B2/
modzone.ru
Лайфхак для файловых сниппетов | Зона разработки
Fenom значительно превосходит стандартный парсер MODX. Но всегда ли это превосходство бесспорно?
https://modzone.ru/blog/2022/05/01/fenom-vs-modx-tags/
https://modzone.ru/blog/2022/05/01/fenom-vs-modx-tags/
modzone.ru
Fenom или MODX | Зона разработки
Forwarded from Beer::PHP 🍺 (Kirill Sulimovsky)
Поговорим о времени
В комментариях к этому посту было несколько просьб подробнее рассказать о часовых поясах. В этом посте я постарался собрать несколько важных тезисов по данной теме.
📚 Теория:
🕔 Всемирное время — 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). Это могут быть записи в логах, время регистрации пользователя, совершения заказа или отправки письма.
✅ Нужно ли хранить часовой пояс пользователя?
Да, только с помощью информации о часовом поясе мы можем сделать вывод о том, какое смещение у него сейчас или будет через пол года. Ведь, повторюсь, один часовой пояс может иметь несколько смещений.
✅ Если время привязано к пользователю — сохраняйте локальное время пользователя и его смещение.
Фактически
————
🔥 Вот те самые несколько нюансов, которыми хотелось поделиться. Пишите в комментарии, если есть что дополнить, возможно вместе соберём еще несколько дельных советов😉.
#php #datetime #middle
В комментариях к этому посту было несколько просьб подробнее рассказать о часовых поясах. В этом посте я постарался собрать несколько важных тезисов по данной теме.
📚 Теория:
🕔 Всемирное время — 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] В новой статье я расскажу про ещё один подводный камень использования шаблонизатора Fenom в MODX, про который знают единицы разработчиков.
https://modzone.ru/blog/2022/08/21/fenom-and-element-parameters/
https://modzone.ru/blog/2022/08/21/fenom-and-element-parameters/
modzone.ru
Fenom и параметры элементов | Зона разработки
Forwarded from Beer::PHP 🍺 (Kirill Sulimovsky)
Law of Demeter (Закон Деметры, LOD)
Этот закон часто используют вместе с темой Tell Don't Ask. Его идея в том, что объект должен обладать ограниченным знанием о других объектах и модулях, взаимодействовать только с теми, кто имеет к нему непосредственное отношение.
Формально правило звучит так, что в клиентском коде вы можете вызывать методы объектов, которые:
✅ Были переданы как аргументы;
✅ Были созданы локально;
✅ Являются глобальными;
✅ Собственные методы;
Пока что непонятно зачем это всё. Давайте разбираться.
Основная задача — создать условия для слабой связанности (loose coupling) между объектами. Но за счёт чего?
🌈 Представьте, вы находитесь в магазине, хотите купить товар стоимостью 25$. Вы дадите продавцу 25$ или вы отдадите продавцу свой кошелек, чтобы тот достал 25$? Давайте разберём этот пример.
👉 В первом случае мы явно знаем, что у объекта
❓ Чем же лучше второй вариант?
Когда у
🤓 LOD также называют законом "одной точки" (one dot), т.к. ноги растут из Java. В нашем же случае о его применении стоит задуматься при виде более одной стрелочки ->. Обращаю внимание, что речь идёт о методах (или свойствах), которые позволяют получить промежуточный объект, утрируя - о геттерах. То есть две стрелочки в каком нибудь fluent interface (напр.
🙈 У закона Деметры тоже есть свои минусы. Одним из них является необходимость создания большого количества методов-адаптеров. Если вы чувствуете, что классы становятся перегруженными - это признак плохого объектно-ориентированного дизайна.
❓ Можно ли нарушать закон Деметры?
Руководствуйтесь здравым смыслом. Если у вас, например, вложенные DTO, которые предназначены для транспортировки объектов, то нет никакого смысла наворачивать что-то подобное сверху. Используйте только там, где это уместно и помните о преимуществах 😉
#php #oop #middle #source
Этот закон часто используют вместе с темой 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
[ZoomX] Наконец в выходные получилось разобрать бэклог ZoomX и реализовать некоторые задумки. Доработок не очень много, но они важные. Итак, что было сделано:
- Добавлена поддержка контекстов.
- Файловые плагины доступны в контексте mgr.
- Исправлены некоторые ошибки, в том числе ошибка с роутами в пользовательской директории.
Особо хочу обратить внимание, что теперь в роутах все адреса нужно начинать со слеша /, а не только главную страницу. Чтобы не сломать обратную совместимость роуты будут будут работать и без слеша, но для этого задействуется дополнительная обработка, что несет небольшие накладные расходы.
- Добавлена поддержка контекстов.
- Файловые плагины доступны в контексте mgr.
- Исправлены некоторые ошибки, в том числе ошибка с роутами в пользовательской директории.
Особо хочу обратить внимание, что теперь в роутах все адреса нужно начинать со слеша /, а не только главную страницу. Чтобы не сломать обратную совместимость роуты будут будут работать и без слеша, но для этого задействуется дополнительная обработка, что несет небольшие накладные расходы.
[ZoomX] Новая версия 3.6.0.
Обсудив с товарищами и взвесив все "за" и "против" я решил ни с кем не считаясь добавить возможность формирования $_POST массива для JSON запросов через метод POST. 😁 Нехай будет. Ежели чего, эту фичу можно отключить в настройках. Спасибо за внимание!
Обсудив с товарищами и взвесив все "за" и "против" я решил ни с кем не считаясь добавить возможность формирования $_POST массива для JSON запросов через метод POST. 😁 Нехай будет. Ежели чего, эту фичу можно отключить в настройках. Спасибо за внимание!
Forwarded from Laravel World
Релиз PHP 8.2
Большое обновление языка. Содержит множество новых возможностей, включая readonly-классы, самостоятельные типы null, false и true, устаревшие динамические свойства, улучшение производительности и многое другое.
https://www.php.net/releases/8.2/ru.php
Большое обновление языка. Содержит множество новых возможностей, включая readonly-классы, самостоятельные типы null, false и true, устаревшие динамические свойства, улучшение производительности и многое другое.
https://www.php.net/releases/8.2/ru.php
Всем привет!
Обновил pdoTools и для MODX 2.x и для MODX 3. Времени хватило только на исправление критических багов. Исправления коснулись pdoPage:
- Пофиксена XSS уязвимость сниппета pdoPage.
- Допилена поддержка файловых элементов для pdoPage (фикс от создателя pdoTools Василия Наумкина).
На этом всё. Не очень много получилось, но сколько смог.
Обновил pdoTools и для MODX 2.x и для MODX 3. Времени хватило только на исправление критических багов. Исправления коснулись pdoPage:
- Пофиксена XSS уязвимость сниппета pdoPage.
- Допилена поддержка файловых элементов для pdoPage (фикс от создателя pdoTools Василия Наумкина).
На этом всё. Не очень много получилось, но сколько смог.
[pdoTools] Алиасы для элементов
В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе разработки сайта с большим количеством файловых элементов. Согласитесь, гораздо проще запомнить и написать такой вызов
Этот функционал также легко позволяет использовать в качестве модификаторов файловые сниппеты. Указанный модификатор перед вызовом несуществующего сниппета заменяется на файловый.
В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе разработки сайта с большим количеством файловых элементов. Согласитесь, гораздо проще запомнить и написать такой вызов
{'test_snippet' | snippet}чем такой
{'@FILE snippets/folder/test_snippet.php' | snippet}Такой же подход используется в Laravel например для middleware.
Этот функционал также легко позволяет использовать в качестве модификаторов файловые сниппеты. Указанный модификатор перед вызовом несуществующего сниппета заменяется на файловый.
В рамках продолжения оптимизации сайта под высокие нагрузки пришлось решишь проблему, описанную в предыдущем посте. У нас скорость загрузки страницы выросла почти в 3 раза.
Ну и до кучи решил закинуть все хотелки, о которых писал раньше - это алиасы для файловых элементов и отдельный класс для файловых сниппетов, чтобы избавиться от костыля ввиде создания дополнительного файла с хэшем в виде названия, необходимого для сниппетов из БД. Благодаря отдельному классу пропадает бесючая проблема кэширования, когда правки в файловом сниппете не работают, пока не очистишь кэш.
Как появится свободное время, напишу статью с примерами. В репе править не планирую.
Ну и до кучи решил закинуть все хотелки, о которых писал раньше - это алиасы для файловых элементов и отдельный класс для файловых сниппетов, чтобы избавиться от костыля ввиде создания дополнительного файла с хэшем в виде названия, необходимого для сниппетов из БД. Благодаря отдельному классу пропадает бесючая проблема кэширования, когда правки в файловом сниппете не работают, пока не очистишь кэш.
Как появится свободное время, напишу статью с примерами. В репе править не планирую.
Telegram
modZone.ru
[pdoTools] Алиасы для элементов
В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе…
В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе…
Коллеги, есть вопрос - нужен ли сайт modzone.ru сообществу MODX?
Как все уже слышали - хостинг modhost закрывается. И тем самым поставил передо мной задачу - что делать с сайтом? С одной стороны жалко, с другой - времени на него нет. Его уже давно пора причесать. Из-за не очень адаптивного дизайна поисковики его понизили. Хотя, на релевантные запросы он показывается в первых строчках. Но посещений не очень много. Поэтому не вижу особого смысла в нем. А личный блог мне не особо нужен. В общем, я в раздумьях 🤔
Как все уже слышали - хостинг modhost закрывается. И тем самым поставил передо мной задачу - что делать с сайтом? С одной стороны жалко, с другой - времени на него нет. Его уже давно пора причесать. Из-за не очень адаптивного дизайна поисковики его понизили. Хотя, на релевантные запросы он показывается в первых строчках. Но посещений не очень много. Поэтому не вижу особого смысла в нем. А личный блог мне не особо нужен. В общем, я в раздумьях 🤔
К нам в команду прилетела срочная задача запилить сайт средней сложности. Даже чуть проще. Для этого вполне подойдет CMS. Битрикс никто из нас не знает. Поэтому решили делать на MODX. Но у нас все сайты работают в Kubernetes. А, как вы понимаете, у MODX с этим есть проблемы. Вернее даже, не с самой контейнеризацией, а CI/CD. Это уже более серьёзный уровень разработки. А насколько я понимаю, модыксеры даже гитом пользуются не часто.
Помочь с этим может Gitify. Но он совсем не швейцарский нож, как утверждал Иван Климчук. Возможно в далеком 2015 году это было так. Но сейчас это очень спорное утверждение. Механизм установки пакетов не подходит для развертывания окружения в Кубере. Он сильно отличается от того же композера. А также отсутствует механизм миграций - можно только дампить базу целиком. Что совсем не подходит для командной разработки.
В общем, к чему я это. Я не смог нагуглить примеров решения похожей задачи. Только про развертывание MODX в контейнере. Поэтому придётся пилить свой инструмент для нормального развертывания рабочих окружений MODX в контейнерах. И самое простое - доработать Gitify. Пока не знаю, что из этого получится. Но если получится, то будет вполне себе рабочий юзкейс для модыксеров.
П.С. Если у кого есть примеры работы с Kubernetes, скиньте плиз.
Помочь с этим может Gitify. Но он совсем не швейцарский нож, как утверждал Иван Климчук. Возможно в далеком 2015 году это было так. Но сейчас это очень спорное утверждение. Механизм установки пакетов не подходит для развертывания окружения в Кубере. Он сильно отличается от того же композера. А также отсутствует механизм миграций - можно только дампить базу целиком. Что совсем не подходит для командной разработки.
В общем, к чему я это. Я не смог нагуглить примеров решения похожей задачи. Только про развертывание MODX в контейнере. Поэтому придётся пилить свой инструмент для нормального развертывания рабочих окружений MODX в контейнерах. И самое простое - доработать Gitify. Пока не знаю, что из этого получится. Но если получится, то будет вполне себе рабочий юзкейс для модыксеров.
П.С. Если у кого есть примеры работы с Kubernetes, скиньте плиз.
Ребята из SpaceWeb перенесли сайт к себе. Проверил, всё работает. Я практически палец о палец не ударил. Так что вопрос о судьбе сайта снят с повестки на некоторое время.
Прощай modhost. Удобная была площадка. Очень жаль.
Всем мир ✌️
Прощай modhost. Удобная была площадка. Очень жаль.
Всем мир ✌️