PHP *

Всем привет! Не говорите, что вам нечего приготовить, если у вас дома одна картошка. При смекалке и достаточном количестве специй — пюре, драники, запеканка, чипсы фри... Конечно, мы обсуждаем не кулинарию. Мне хотелось бы поговорить о GraphQL и некоторых фичах, которые мы внедрили у себя в компании, и тиражируем на различные проекты, где используется этот язык запросов.

Эта статья о базовой структуре, производительности, безопасности и гибкости GraphQL и будет интересна архитекторам, интеграторам, аналитикам и разработчикам, которые не ограничиваются рассмотрением информационных систем только с точки зрения «кода», а учитывают полный жизненный цикл системы, включая поддержку, развитие, систему управления знаниями и многое другое.

Декомпозиция монолита - не редкая проблема. Она возникала в большинстве компаний, где я работал. Происходит это потому, что на ранних стадиях развития любого стартапа накапливается так называемый decision debt - выбранная архитектура является оптимальной для быстрой разработки и экспериментирования, но не для зрелого продукта.

Учитывая популярность проблемы, существует множество книг и статей о подходах к её решению, но мне показалось, что есть недостаток практических примеров. Поэтому, в этой статье я сосредоточусь на технических деталях, используя в качестве примера приложение, написанное на PHP и фреймворке Symfony.

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

Собственно, а все ли поняли мем?

Человек прошел обучение, отбор посредством собеседования, имеет багаж знаний. После освоения навыков, набравшись практики (в наши дни стать junior-разработчиокм без практики нереально) добравшись до цели в виде трудоустройства. Не успев толком продышаться сразу сталкивается с такой вещью как бизнес процессы. Пытается понять что от него хотят коллеги по работе и как тут вообще все устроено. Он чувствует растерянность. Но тут стоит оговориться что бизнес это конкурентная среда. Там всем приходится непросто. Смотрите: программист это ремесленник, инструмент которым он пользуется сложный и не понятный - это его собственный мозг. Своим мозгом он обслуживает бизнес процессы. Решает задачи за счет которых приложение работодателя остается в рабочем состоянии и развиваются с точки зрения прибыли. Поток этих задач такой, что нет времени плавно погружаться в процесс, надо срочно в бой. Если вы не знакомы с программированием, взгляните на примеры кода и вы примерно ощутите тоже самое что junior-разработчик в свой первый рабочий день.

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

Проект делается на Laravel 10 на стартере Breeze Inertia + Vue.js.

Историю как я придумывал саму логику уведомлений я оставлю как-нибудь на потом, а вот о том как я распрощался с Pusher я расскажу сейчас. Вообще Pusher, конечно, сервис хороший, но если брать бесплатные лимиты, то там всё достаточно грустно, поэтому я решил использовать что‑то другое в качестве альтернативы. Выбор пал на Laravel Websockets.

Для справки, Laravel Websockets — это такая надстройка над Laravel, которая на бэке использует Ratchet, но никаких особых настроек делать не нужно, всё работает практически «из коробки». Правда есть несколько подводных камней, о которых я тоже расскажу.

Скоро Тейлор и его команда выпустят новую мажорную версию фреймворка. Расскажу, что на данный момент известно о ней.

Laravel 11 продолжает улучшения, начатые в Laravel 10.x, представляя упрощенную структуры приложения, посекундные ограничения скорости, маршруты проверки здоровья приложения, изящную ротацию ключа шифрования, улучшения тестирования очередей, почтовый транспорт Resend, интеграцию валидатора Prompt, новые команды Artisan и многое другое. Кроме того, был представлен Laravel Reverb — масштабируемый WebSocket-сервер обеспечивающий надежную работу в режиме реального времени.

Вчера я опубликовал перевод статьи на тему оптимизации использования респонсов в Laravel с "простейшими" данными. То есть когда в ответ нужно отдать какое-то число, строку, массив или объект. Но что делать если приложение построено на использовании Json Resource? Или ещё больше - нужно изменить уровень вложенности данных, возвращаемых коллекцией? Давайте разбираться!

В далекий 2019 год, когда про ковид никто не слышал и других жестей еще не было на горизонте, я читал очередную статью как “правильно” писать очередного бота на телеграм. И в очередной раз у меня крутилась мысль: че код так паршиво выглядит то? Где-то в то время телеграм еще был на хайпе, я упражнялся в ботописании, каждый второй выходец из онлайн школы программирования пытался объяснить окружающим как писать боты на телеграм. Глядя на это все, возник вопрос: а как оно должно выглядеть, чтоб мне понравилось ? Дальше речь пойдет про субъективщину и избавление от фатального недостатка. А я Саша, на тот момент был php разработчиком, а сейчас дожил до лида в Kokoc group.

В этой статье я расскажу как установить на Repka Pi 3 полноценный WEB сервер на Nginx с php-fpm и MySQL для того, чтоб в конечном счете установить WordPress и начать делать и размещать Ваш сайт на данной платформе. Ставить будем на родную ОС Repka Pi от 11.12.23 (последняя актуальна прошивка на момент написания статьи).

Не секрет, что при формировании новой команды руководители (Team Leader, Tech Leader) сталкиваются с проблемой формирования единого стиля написания программ, так как все члены команды новые, и у каждого из них свой подход к организации кода и выбору используемой практики. Как правило, в большинстве случаев это приводит к длинным диспутам на ревью, которые в итоге перетекают в различные толкования известных практик, таких как SOLID, KISS, DRY, и т.д. Принципы использования этих практик довольно размыты и, при должном упорстве, легко найти парадокс, когда одна из них противоречит другой. Например, рассмотрим Single Responsibility и DRY.

Одна из вариаций определения принципа единой ответственности (Single Responsibility - буква S из аббревиатуры SOLID) гласит, что каждый объект должен иметь одну ответственность, и эта ответственность должна быть полностью инкапсулирована в класс. Принцип DRY (Don’t repeat yourself) предлагает избегать дублирования в коде. Однако, если у нас в коде есть один набор данных (DTO), который может использоваться в разных слоях/сервисах/модулях, какому из этих принципов нам следовать? Безусловно, во многих книгах по программированию разбираются похожие ситуации, как правило, в них говорится, что если речь идет о разных объектах/функциях с одинаковым набором свойств и логики, но принадлежащим разным доменным областям, то дублированием это не является. Но как доказать что эти объекты ДОЛЖНЫ принадлежать разным доменным областям, и, главное, готов (и уверен ли в своих силах) руководитель доказывать это утверждение?

Комплексный обзор множества безопасных функций Laravel, которые могут помочь вам предотвратить болезненные ошибки.

Мы рассмотрим следующие механизмы безопасности:

• Предотвращение N+1
• Защита от частично гидрированных моделей
• Опечатки атрибутов и переименованные столбцы
• Защита от массового присвоения
• Строгость модели
• Принудительное выполнение полиморфного сопоставления
• Мониторинг долгосрочных событий

Практически у каждого разработчика на Битрикс при переходе с уровня "сайт из 5 страничек" на уровень "крупный проект с 10к+ пользователями" возникает потребность производить отладку отправки почты, но при этом чтобы фактически пользователи эту почту не получали. Так как случайная отправка отладочного сообщения пользователям сайта из 5 страничек, которых как обычно 5-6 человек, как правило ощутимых репутационных издержек не несет, что нельзя сказать о крупном проекте с большой пользовательской базой. Когда задачи не связаны с почтовой подсистемой, многие разработчики как правило просто отключают отправку исходящей почты на своем dev окружении, также как то давно я выходил из этой ситуации переконфигурированием почтового сервера для безусловной отправки всех писем на определенный ящик. Не совсем удобное, даже "костыльное" решение на мой взгляд, так как в приходящих сообщениях получаем измененный заголовок получателя и проверить правильность в полной мере по сути невозможно, только с точки зрения контента отправляемого письма.

Недавно я начал искать, какие решения есть сейчас для отладки отправки почты без ее фактической отправки, при этом решение должно ставиться локально на сервер, так как большинство проектов у меня связаны с разработкой порталов на Битрикс24 Энтерпрайз, поэтому за использование внешних сервисов можно получить очень большой "нагоняй" от службы ИБ заказчиков. Если же вам больше подходит онлайн-сервис, который не нужно как-то устанавливать, а просто прописать в настройках msmtp окружения - можете посмотреть в сторону DebugMail, MailSlurp, TestMail. Их "гуглится" масса, можно выбрать на свой вкус, по функционалу, цене, длине шерсти и хвоста :) Единственный недостаток - сервисы в большинстве иностранные, поэтому платную версию из России будет купить проблематично.

Решать задачу будем на примере каталога исторических экспонатов Музейного фонда РФ. API каталога является общедоступным сервисом. Сначала нам нужно будет сформировать ссылку на скачивание архива ZIP с информацией. Сделать это нужно аккуратно, так, чтобы изменения в названиях файлов, которые могут время от времени случаться, не повлияли на работоспособность нашего скрипта.

Затем, мы создадим шакалу загрузки, или прогресс‑бар, как ее еще называют, чтобы отслеживать процесс скачивания. Экспонатов много, каталог большой: «весит» он более 5 Гб. Без индикации загрузки пользователь может недоумевать, почему ничего не происходит и консоль просто висит долгое время. Наконец, скачаем файл из API, который потом можем разобрать по таблицам своей базы в том виде, в котором понадобится.

По большому счету единственной незакрытой темой в рубрике "Про Vim" осталась тема об альтернативе Conqueror of Completion для Neovim в Lua исполнении. Причиной перерыва между данной и предыдущей статьей в рубрике стало отсутствие необходимости в этой самой альтернативе. Ну или вернее причина может быть и была: во-первых - что бы удовлетворить любопытство, во-вторых - CoC действительно кажется громоздким и достаточно сложным внутри. Вариант на Lua мне бы дался легче, если бы захотелось что-то в нем подшаманить. Наверное.

Всем привет! Краткий обзор новостей из мира PHP и Laravel за январь 2024 года от Сергея Пантелеева и Данила Щуцкого (CutCode).

Одним из важнейших аспектов тестирования наряду с поиском ошибок в приложении является время, необходимое для его проведения. Если тестирование приложения занимает от нескольких минут до нескольких часов, то оно не подходит для разработки с использованием быстрого цикла обратной связи (fast feedback loop), и разработчики могут проводить его не так часто, как следовало бы.

Все главные новости из мира Joomla с момента выхода предыдущего дайджеста 4 августа 2023 года в одной статье. Также в дайджест попадает январь 2024 года. Традиционно наш дайджест обозревает новости, расширения, шаблоны и статьи из мира Joomla. Прошлый выпуск вы можете прочитать здесь.

Привет! Как и в предыдущие три года, в декабре 2023 было запущено исследование русскоязычного PHP-комьюнити. По итогам получился срез данных: на каких версиях PHP сидят в командах, какой фреймворк выбирают для рабочих проектов, а какой для личных, как относятся к ИИ-инструментам для разработки, кого считают человеком года и многие другие аспекты. Опрос помогают составлять и распространять ребята, которые развивают городские и региональные PHP-сообщества, а также руководят каналами и подкастами про PHP.

Посмотрим, каким был 2023 для сообщества, в 1120 мнениях.

Результаты также можно найти на phpcommunity.ru. Вот итоги за 2022, 2021, 2020.

Всем привет! Меня зовут Иван Шишкин и я руковожу разработкой в агентстве Intensa.

В этой статье хотел бы поделиться методом автоматического подключения каналов логирования в Laravel через механизм сервис контейнеров(DI).

Мысль о централизованном мониторинге логов хранилась в моей голове много лет, но реализовать ее я смог только совсем недавно. Рассказываю о настройке и подводных камнях связки Logstash + Manticore + Nginx + Symfony.

В статье пойдёт речь о самом базовом управлении устройствами умного дома Яндекс - а именно функции включения/выключения, т.к. ничего больше мне не нужно, но из базы довольно легко с помощью документации, научиться управлять и другими свойствами. Может этот материал не на статью вовсе, но вот захотелось поделиться. За код не ругайте сильно - я не настоящий программист. Код будет на простейшем PHP.