Версионирование API – важная и зачастую сложная задача, у которой скорее всего нет какого-то универсального решения. Рассказываю об одном из возможных подходов в приложениях на базе Laravel.
Всем привет!
Это PHP Дайджест от CutCode. Давайте посмотрим, что произошло за прошедший месяц в мире PHP.
Даниэль Дюбуа, известный энтузиаст, поделился с сообществом переопределением модуля материалов Joomla, при помощи которого вы сможете отображать ленту последних материалов в стиле новостных лент.
Сегодня мы хотим поделиться нашим опытом разработки админ-панелей (CMS) с использованием Filament — чрезвычайно мощной библиотеки Fullstack-компонентов, основанной на фреймворке Laravel и технологии Livewire.
Мы используем Laravel в качестве основного фреймворка для разработки бэкенда всех наших проектов, и однажды возник вопрос: какое решение для админ-панелей выбрать? Мы остановились на Filament — тогда еще сырой, маленькой, почти незадокументированной open-source админке.
Как показало время, не зря.
В этой статье мы не будем сравнивать Filament с другими админками, так как это не особо вписывается в формат (тем более, это уже делали другие). Однако важно подметить, что мы достаточно долго выбирали между Filament и другой, на наш взгляд, более популярной среди русскоязычного комьюнити Laravel, библиотеки — Orchid (отечественная админ-панель с философией DIY).
Мы работали над несколькими проектами на Orchid параллельно с проектами на Filament и остановились на последнем. Постараемся объяснить, почему мы считаем, что Filament — пожалуй, лучший выбор, который вы можете сделать, если ваша деятельность связана с написанием CMS.
В web-разработке процесс деплоя играет важную роль. Это ответственный момент (даже торжественный), когда все усилия, потраченные на написание и тестирование кода, воплощаются в "живое" приложение, доступное пользователям. Ведь для этого приложение и делается, чтобы им кто-то пользовался. Каждый разработчик, независимо от уровня и специализации, регулярно сталкивается с задачей деплоя. Это статья рассчитана на новичков, которые учатся разворачивать приложения на сервере и хотят узнать различные варианты, сравнить их и выбрать подходящий.
В этой статье пошагово разберем самый простой вариант - деплой приложения на хостинг.
В процессе изучения Symfony Messenger мной было создано два самодостаточных примера, демонстрирующих его работу (описаны в отдельных статьях).
В каждом из этих учебных примеров в качестве транспорта сообщений для простоты была выбрана БД SQLite.
Готовой реализации транспорта именно для SQLite я не нашёл и пришлось её использовать через DBAL Doctrine.
И всё бы ничего, но внутренний перфекционист :-) нашёптывал, что использование целой Доктрины лишь для того, чтобы работать с одной-единственной таблицей с очередями сообщений — это явный перебор…
Бороться с затерроризировавшим меня внутренним перфекционистом ;-) я не стал и, решив поглубже разобраться с устройством транспорта сообщений в Symfony Messenger, создал такой транспорт для SQLite сам, с использованием PDO.
А заодно потестировал производительность самопального решения и решения на Doctrine (на HDD и на RAM drive).
Orange Tsai недавно запостил про «Одну из уязвимостей PHP, которая влияет на XAMPP, развернутый с настройками по умолчанию», и нам было интересно рассказать немного об этом. XAMPP - очень популярный способ администраторов и разработчиков развернуть Apache, PHP и множество других инструментов, и любая ошибка, которая может быть RCE в установке этого набора по умолчанию, звучит очень заманчиво.
Где нашлась очередная уязвимость PHP? Читайте далее.
Немного веселья на серьезную тему правильного нейминга тестов и 100500 их типов и видов.
Обязательно дочитай до конца, иначе пропустишь невероятно мудрый посыл ;)
В современном быстро развивающемся и ориентированном на данные мире создание сложных workflow, способных обрабатывать тысячи регистраций, процессов или действий, может быть сложной задачей. Важно иметь решение, которое будет масштабируемым, надежным и простым в использовании. К счастью, на рынке есть различные инструменты и движки, и одним из наших предпочтительных инструментов является Temporal.io. Temporal предоставляет набор проверенных паттернов, которые были опробованы в крупных продуктах и командах, позволяя разработчикам использовать их легко и эффективно, сосредоточив внимание исключительно на производительности инженерных решений.
В этом посте мы рассмотрим, как можно использовать Temporal Workflows для разработки структуры для эффективного управления жизненным циклом документов. Мы сосредоточимся на использовании Temporal для обработки событий workflow, связанных с изменениями документов, не перегружая систему ненужными процессами и ручными шагами. Мы предоставим примеры кода на PHP, но вы можете адаптировать их к любому из поддерживаемых языков Temporal.
WordPress Interactivity - это относительно новый API, который позволяет создавать декларативный фронтенд в WordPress нативно. Декларативный? Да, да, он использует тот же принцип, что React и Vue. Только тут под капотом Preact и собственные директивы. И конечно куда же без SSR, который здесь идет из коробки. Звучит интересно? Давайте разбираться вместе.
Недавно мной был создан самодостаточный пример совместной работы компонентов Symfony Messenger и Symfony Console, подробно описанный в статье https://habr.com/ru/articles/817425/.
Для демонстрации работы этого примера нужно вручную запустить несколько консолей (терминалов), а потом в каждой вручную запустить Worker.
Мой внутренний перфекционист :-) сильно против этого возражал и говорил «а вот бы все эти консоли-терминалы запускались одной командой, в нужном количестве, сразу с Worker’ами, а если какой Worker упадёт, то заново запускались в нужном количестве».
Возражать своему внутреннему перфекционисту я не стал и создал ещё один пример работы Symfony Messenger, который запускается Worker’ами из PHP фреймворка Workerman. При этом Symfony Console вообще не используется.
Пришёл и мой черёд асинхронно и многопоточно средствами PHP кое-что пообрабатывать… И я, естественно, вспомнил про компонент Messenger фреймворка Symfony.
Ранее я никогда Symfony Messenger не использовал.
Чтобы понять, как с ним работать, я пытался найти какой-то простой, законченный и самодостаточный пример, понятный даже чайнику, но мне это не удалось...
Всё, что находилось, было либо слишком сложным, либо это были какие-то отдельные куски кода, понятные только тем, кто уже работал с Symfony Messenger. К тому же всё, что находилось, в основном было "заточено" либо под Redis, либо под RabbitMQ. установка которых как-то немного перебор для учебного примера…
В-общем, я создал и выложил на GitHub такой простой, законченный и самодостаточный пример работы Symfony Messenger совместно с Symfony Console.
Вы когда-нибудь вносили изменения в файлы шаблонов только для того, чтобы обнаружить, что все, что вы изменили, исчезло при следующем обновлении? Тогда у нас для вас хорошие новости: начиная с Joomla 4.1 эта проблема решена. Благодаря возможности создавать дочерние шаблоны, добавленные в ядро, вы можете вносить изменения, которые сохранятся в системе без риска потери данных. В этой статье объясняется, как это работает.
Привет, меня зовут Алексей и я должен признаться, я PHP разработчик. Последние несколько лет плотно занимаюсь проектамиь на symfony и решил поделиться с сообществом практиками, которые стараюсь соблюдать при работе.
Многие из них довольно спорные, для дискуссии добро пожаловать в комментарии.
Привет, Хаброжители!
Для чистого, тестируемого и масштабируемого кода в фреймворке Laravel стоит применять необходимые практики. Особенно это важно с учетом гибкости PHP, ведь любые отклонения могут привести к усложненному коду, а скорость обнаружения ошибок гораздо снизится.
Разбираемся, как помогает Laravel, и называем нужные практики для создания приложений.
Привет, Хабр! На связи Виталий Киреев, руководитель R&D SpaceWeb. Это первая часть статьи про веб-безопасность — здесь я расскажу про главные уязвимости Server Side, покажу примеры и объясню, как защищать данные.
В одно мгновение мир, который мы знали, рухнул, оставив после себя только воспоминания о былой цивилизации. Теперь, в 2050 году, перед выжившими стоит задача не только сохранить себя, но и восстановить утраченное, шаг за шагом возвращаясь к технологическому прогрессу. Как?
Это история одной текстовой игры написанной программистом любителем с довольно сложными механиками и функционалом...
Пролог: Большое спасибо рекрутеру компании Emfy за то, что напомнил мне о моей способности быстро разбираться в незнакомых вещах ❤️
Всем привет! Это мой первый пост, и я хотел бы привнести свой вклад в сообщество, обсуждая интересные проекты и задачи с собеседований от руководителей различных компаний.
Начну, пожалуй, с того, что я PHP-разработчик, и мне нравится программировать. К сожалению, я упустил в своё время основные моменты при обучении и порой просто не обращал внимание на то, что мне не нравилось. Только совсем недавно, две недели назад, я начал изучать ООП.
Сегодня я хочу поделиться тестовым заданием, которое мне предоставила компания Emfy. Они занимаются внедрением интеграций, взаимодействуя с amoCRM. Стоит отметить, что я никогда раньше не сталкивался с API amoCRM, из-за чего возникли проблемы с усвоением новой информации по API, так как она обширна.
В этой статье мы затронем один из самых простых, но в то же время наиболее важных навыков в программировании. Ведь именно грамотное именование кода позволяет говорить о его качестве.
Существует четыре главных фактора, которые отличают хороший код от плохого: читаемость, изменяемость, безопасность и производительность. Первые три — тесно связаны, и главным среди них является именно читаемость.
Ведь читаемость это фундамент, без которого ничего не получится.
