PHP *

Ещё один небольшой pet-проект: про кафе и коворкинги на солнечном Кипре. "Рабочие места" для цифровых кочевников ヽ(。_°)ノ

Делюсь процессом разработки, фичами и граблями. Общий подход к разработке прагматичен и аналогичен предыдущему проекту.

Среди некоторого количества шаблонизаторов для php есть один, который мы долгое время активно использовали и используем в своих проектах. Это Blitz, который являясь расширением, во-первых достаточно быстрый, во-вторых реализует давнюю мечту - максимальное отделение представления от логики.

Пока наши старые проекты были написаны на нативном php, пачке самописного кода и всякого «исторического наследия» проблем особых и не было. Но пришел момент когда некоторые старые куски мы решили переписать «жестко отрефакторить» и заодно влиться во вселенную Laravel. Но для ускорения процесса, перспектива переделать быстро десятки существующих шаблонов на Blade мне показалась такой себе идеей, поэтому надо было как-то прикрутить Blitz к Laravel, желательно в стиле самого Laravel. Ну типа там инсталяция в пару команд и все такое.

С другой стороны, в Blade есть некоторые фичи, которых нет в Blitz, как-то наследование шаблонов через @section/@yeld и внедрение хелперов. И было бы неплохо их добавить, для упрощения дальнейшего перехода на Blade, если будет надо. Сказано – сделано. На коленке за пару-тройку вечеров получился некий адаптер, с которым и хочу ознакомить. Собственно нижележащий текст это вольная попытка озвучить по-русски README.md, где я вообще был лаконичен как никогда

Недавно, - если быть точным - 3 года назад, я начал делать чат на PHP для собственных нужд. Буквально на днях я доработал пару функций и решил его всё-таки выпустить в мир. Технология, которую использует данная система, уже считается устаревшей: PHP (ООП, MVC), AJAX (XMLHttpRequest), HTML5, MYSQLI, CSS3. На одном из каналов Telegram кто-то пошутил и назвал чат ламповым, по аналогии с ламповыми телевизорами. Что тут скажешь?! Метафорически точно и остроумно подмечено! Изначально система задумывалась для замены чата на файлах в движке одной браузерной игры. Основная задача была: сделать максимально простую систему.

В 2022 году считается, что чаты на Ajax уже не делают, но почему-то продолжают делать системы комментариев к блогам, новостям и доскам объявлений. В моем представлении системы, которые называют message board и chat в целом имеют схожую схему работы, а порой вообще отличаются только названием. Система, которая получилась у меня, - что-то среднее между доской сообщений и чатом.

Хороший код читается легко, как проза. Многие книги учат нас тому, как важно делить код на небольшие, повторно используемые, легко потребляемые блоки.

Но почему-то, в случае с регэкспами у программистов как будто появляется слепое пятно на чувстве стиля. Вот такая регулярка – совершенно обычное дело:

/^(0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])[- /.]((19|20)\d\d)$/

В данной статье описан алгоритм использования пакета PHPMailer для отправки писем из приложений Laravel 8 через SMTP серверы. PHPMailer - легкий в применении опенсорсный проект, включающий в себя большое количество фич таких как возможность множественной отправки писем, настройки параметров отправки, прикрепления вложений, а также с защитой от Header Injection атак в соответствии со стандартами безопасности.

В рамках последнего семинара мы обсуждали концепцию DTO (Data Transfer Object). Главная особенность DTO заключается в том, что они содержат значения исключительно примитивных типов (строки, целые числа, логические значения), списки или ассоциативные массивы с такими значениями, включая и «вложенные» DTO. Я не могу точно сказать, кто придумал эту идею, но я использую ее, потому что она делает DTO структурами данных, которые энфорсят только схему заключенных в них значений (имена полей, ожидаемые типы, обязательные и необязательные поля), оставляя их семантику в покое. Это позволяет нам создавать DTO из любого источника данных, например из значений, полученных из формы ввода двнных, аргументов командной строки, JSON, XML, Yaml и т. д.

Использование примитивных значений в DTO является наглядной демонстрацией того, что эти значения не валидируются. DTO просто используется для передачи или переноса данных с одного слоя в другой. И вот в этом контексте во время семинара у нас возник вопрос: можем ли мы считать DateTimeImmutable значением примитивного типа? Если да, то можем ли мы использовать этот тип внутри DTO?

Мне кажется, что это достаточно интересный вопрос для разбора. Хочется сразу ответить «нет», но почему?

Как нам понять, удовлетворяет ли что-либо наш предикат? Для начала мы должны определить сам предикат. Когда мы оперируем абстрактными формулировками, то этот первый шаг вполне очевиден, но при обсуждении конкретных вопросов часто неясно, что разговор должен начинаться с определений; нам так не терпится сразу же перейти к ответу! Итак, чтобы ответить на это вопрос, нам для начала нужно определить, что является значением примитивного типа.

Когда у языка нет цветовой дифференциации функций… то у языка нет цели?

Я уже много лет занимаюсь компиляторами и языками в целом. Хочу поделиться интересной мыслью, которая когда-то пришла мне в голову. Почему-то такого я нигде не видел.

Если немного расширить понятие функции (ввести атрибут «цвет»), можно описывать паттерны вида «вызывать логгер из performance-critical мест — это плохо» или «ходить в базу при рендеринге шаблонов запрещено».

Идея абсолютно не зависит от языка и применима к любому: хоть JS, хоть Go. Разберу её подробно в статье, и это будет интересно больше с теоретической точки зрения. Хотя мы даже сделали практическую реализацию для PHP, чтобы использовать у себя. Ссылки на GitHub и видео приложу в конце, а пока обо всём по порядку.

В Joomla 4 используются контейнеры внедрения зависимостей (DI контейнеры, DIC). Эта статья-перевод (из нового портала документации для разработчиков) призвана объяснить, зачем их внедрили и как их использовать в Joomla. DI контейнеры уже давно существуют в экосистеме PHP, например, Symfony представила эту концепцию в 2009 году. Теперь они доступны и в Joomla.

TLDR; Использование Sqlite в Laravel (или любых других PHP приложениях) для Unit-тестирования может привести к false positive результатам тестов. Тот код который пройдет тесты, не заработает после переезда в production и использования других БД, например, MySQL. Вместо этого разверните тестовую БД с использованием той же технологии и движка, которые будут использоваться вашим приложением в production.

Во-первых, позвольте мне начать с того, что я очень рад видеть, что вы проводите Unit-тестирование — вы на верном пути! Laravel познакомил многих разработчиков с миром Unit-тестирования, сделав утилиты для тестирования первоклассной частью фреймворка. Это круто! Но нам нужно убедиться, что наше чувство безопасности, которое мы получаем от наших Unit-тестов, верно.

Один из механизмов, которые Laravel предлагает для Unit-тестов, основан на использовании базы данных SQLite . Для ускорения выполнения тестов, база данных запускается непосредственно в оперативной памяти. Такое решение работает в 95% случаев. Но, дьявол кроется в деталях, в этих 5%.

Поговорим о причинах, почему это не лучший выбор.

Это лишь часть таблицы инструментов, которые мы рассматривали. Подробнее по ссылке.

Мы используем New Relic в каждом из наших 250 PHP-сервисов. С его помощью отслеживаем взаимосвязи между сервисами, их зависимости, смотрим нагруженные транзакции, анализируем полный трейс запроса пользователя. Наши основные функциональные требования: связи, оценка по времени отклика и параметру APDEX (собирательное значение удовлетворенности пользователя).

Отказаться от New Relic хотели давно. Главная причина — он стал дорогой. Весной добавилась вторая причина — мы из России. Запереживали, что нас могут отключить. А мы в команде инфраструктуры стараемся все сервисы держать на своей стороне.

В августе закончился договор с New Relic, так что заранее стали искать ему замену. И вот, как оно было.

Привет, Хабр! 

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

Прежде чем приступить к изложению сути темы, расскажу историю из практики. Когда-то я занимался автоматизацией такого страшного явления как “аттестация педагогических работников”. Суть заключалась в том, чтобы разработать систему, куда доблестные труженики образования загрузят документы, подтверждающие успехи в работе - грамоты, дипломы учеников, и далее по списку. Стек: PHP+Python (если хотите знать, что тут делает Python - почитайте первую статью), JS (jQuery) на фронте. 

Конечно же, никакого ТЗ не было, порядок внесения изменений напоминал постройку железной дороги прямо перед движущимся паровозом. Закономерным следствием такого подхода стали некоторые “особенности” в работе системы. Так, например, список отправленных на рассмотрение портфолио для администратора формировался несколько минут. Однако это всех устраивало, потому что “внесение изменений может что-то сломать, а так оно работает пусть медленно, зато предсказуемо”. Оно и по сей день работает медленно, но предсказуемо.

В статье представлен код позволяющий отправлять транзакционные письма через сервис unione, делать HTTP запросы к REST апи, а так же отправлять обычные email по smtp используя общий класс отправитель различных сообщений.

Привет! На связи Данила Соловьев, руководитель направления PHP в AGIMA. Для проджект-менеджеров и джуниор-разработчиков я подготовил небольшой гайд по тому, как ускорять работу крупных проектов на Битрикс и повышать их отказоустойчивость. Здесь вы не найдете сложных кейсов или сногсшибательных решений. Но зато найдете простые и применимые советы.

Почему вы не прошли очередное собеседование? Вы можете прочитать кучу причин, про непрофессионализм, незнание какого-то фреймворка, софт-скилы и т.п. Главная причина - вы не понравились, вы не идеальны с точки зрения собеседующего, как человек вы ему неприятны, вы расходитесь во взглядах на жизнь. И простого подчинения политике компании на словах тут недостаточно. Я утверждаю это на основании моего довольно интересного опыта. У меня 2 стэка - PHP(Laravel и Symfony) и Ruby(Rails). Сравнивая десятки собеседований на эти 2 стэка(да, у меня два разных резюме, об этом ниже), я пришел к очень интересным выводам.

Joomla 4 "под капотом" претерпела немало изменений относительно предыдущих версий. Её кодовую базу сообщество разработчиков регулярно подтягивают до современных реалий, вводя актуальные технологии в ядро CMS. Так, например, если раньше загрузка классов была вариациями на тему include, то в Joomla 4 появился лоадер, приведённый к PSR-4. Ядро CMS переводится на концепцию сервис-провайдеров, внедрены DI-контейнеры. Эти изменения влекут за собой изменения в структуре компонентов, модулей и плагинов.

В данной статье пойдёт речь о том, как создать модуль для Joomla 4 с новой структурой файлов и классов. Как создать новый (или апгрейдить старый) модуль так, чтобы он ещё долго прослужил на Joomla 4 и Joomla 5? Читаем далее...

Как мы решаем проблемы со склонением для задач SEO-оптимизации с помощью phpMorphy.

Делимся решением!

Работая над проектом, у меня возникла задача: возвращать информацию об Exception в формате JSON если client в запросе указывает поддерживаемый им MIME тип application/json используя заголовок Accept.

Простыми словами - если клиенту нужна ошибка в JSON, то дать ему JSON. В других случаях возвращать стандартную ошибку в формате HTML.

Давайте рассмотрим пример, как это можно сделать используя механизм обработки встроенных событий Symfony.

В данной статье мы бы хотели описать использованный нами ООП подход к отправке писем через данный сервис рассылок на php. Суть которого заключается в создании объекта инкапсулирующего данные необходимые для отправки письма и методы работы с ними. Кажется что это довольно простая идея, но нам не встречалось ещё в доступных источниках такого подхода, поэтому хотим внести свой вклад в этом направлении. Тем не менее статья написана не для того чтобы пропагандировать данный подход. Она написана с целью развития компетенций в области ООП и способности его использования практических задач, будь то отправка писем или ещё что-то.

В публикации опишу подход к использованию контейнеров docker и make который я практиковал последние несколько лет в своих рабочих командах и личных pet-проектах. Подход сформировался в процессе поиска минималистичного и унифицированного способа запуска проектов на php. Чтобы любой разработчик мог в пару простейших команд получить рабочую копию для разработки, располагая только доступом к репозиторию, без бубнов, обновляемых инструкций и тимлида на соседнем стуле.

Каждый, кто знаком с WordPress, пользуется плагинами с его репозитория, это очень простой и удобный способ расширить стандартный функционал. Если вы разрабатывали или кастомизировали тему, то сколько раз вы копировали один и тот же код с предыдущего сайта на новый? Сколько раз вам приходила в голову идея, что ваша текущая фича была бы полезна и другим? Если данные мысли появлялись у вас, то в данной статье я пошагово, на примере покажу, что публикация плагина - задача абсолютно не сложная. Те, кто уже публиковал плагины, могут использовать эту статью в качестве шпаргалки для себя, а также я поделюсь парой подводных камней, на которые стоит обратить внимание.