Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter

#байтовый_юмор

Whisp — простая стартовая точка для создания приложений PHP SSH Whisp — это «чистый PHP» SSH-сервер, который позволяет запускать PHP-скрипты как SSH-приложения: при SSH-подключении вы попадаете не в обычную оболочку, а в PHP-приложение с TUI или CLI. Можно задать набор «приложений» (скриптов) — и пользователи могут выбирать, куда подключаться, либо указывать имя приложения при SSH. Требования: PHP 8.2+, расширения FFI, pcntl и libsodium 🔗 Github Библиотека пхпшника #инструменты

⚖️ Чем отличается ?: от ?? на самом деле В проектах их часто путают, хотя работают они по разным правилам. Коротко и по делу — что выбирать и когда. 🔸 Тернарный оператор ?: Проверяет true/false значение. $displayName = $payload['name'] ?: 'Guest'; 📌 Возвращает правую часть, если значение: '', null, false, 0 или другая «ложь». ❗️ Но если ключ не существует → получите Undefined array key. Пример: $payload['name'] = false; // → 'Guest' $payload['name'] не существует → ошибка 🔸 Null coalescing оператор ?? Проверяет существует ли ключ и не null. $displayName = $payload['name'] ?? 'Guest'; 📌 Работает безопасно даже если ключ отсутствует. 📌 Возвращает любые значения, в том числе false и пустую строку. Пример: $payload['name'] = false; // → false $payload['name'] отсутствует → 'Guest' ⚠️ Частая ошибка ?? может спрятать баги. $firstName = $payload['frist_name'] ?? 'Guest'; Опечатка → ошибки нет → баг уходит в прод. ?: в такой ситуации бы упал и подсветил проблему. 🧭 Что использовать? Используйте ?:, если: 🔸 значение точно существует 🔸 нужно проверять truthiness Используйте ??, если: 🔸 ключ может отсутствовать 🔸 важно отличать null от false, 0, '' 🔸 работаете с внешними API / неполными payload'ами 🐸 Библиотека пхпшника 📍 Навигация: Вакансии • Задачи • Вопросы с собеса #элементарный_выбор

Что будет выведено данным скриптом?

PHP жил, жив и будет жить. А ты? Рынок требует от PHP-разработчиков всё больше: понимание сложных архитектур, алгоритмическая база, умение работать с высокими нагрузками. Хватит клепать сайты-визитки. Акция 1 + 2: Три курса по цене одного. Оплачиваешь самый дорогой, два других — в подарок. Твой путь к Senior: — архитектуры и шаблоны проектирования; — алгоритмы и структуры данных. Прокачаться Акция до 31 декабря. Не знаешь, что выбрать? @manager_proglib

🚀 Symfony 7.4 — новый LTS, время апгрейда В конце ноября 2025 вышла Symfony 7.4 — официальная Long-Term Support версия. Это не просто «ещё одна версия»: 7.4 — серьёзный шаг к упрощению архитектуры и снижению лишнего кода, особенно если вы работаете на PHP 8.2+. ✅ Что реально даёт Symfony 7.4 Многоэкранные маршруты — теперь в атрибуте #[Route] env принимает массив. Можно одним маршрутом охватить, например, dev и test, и при этом его не будет в prod. Чисто, понятно, без дублирования. Меньше проверок вручную — атрибут #[CurrentUser] теперь поддерживает union-типизации. Если в одном фаерволе используются, скажем, AdminUser и Customer, — можно сразу типизировать параметр метода как AdminUser|Customer, без ручных instanceof. Более гибкая безопасность — с #[IsGranted] можно указывать проверку не для всего метода, а только для конкретных HTTP-методов (GET, DELETE и т.д.). Это даёт возможность держать логику (например, чтение и удаление ресурса) в одном методе, но с разным контролем доступа. Унификация событий — #[AsEventListener] теперь поддерживает union-типы в сигнатуре: можно одним слушателем обрабатывать сразу несколько событий. Это сокращает дублирование кода и упрощает архитектуру. Возможность «допиливать» чужие классы — теперь можно добавлять атрибуты валидации/сериализации к DTO или другим классам, которые вы не контролируете. То есть, если используете сторонний класс — всё равно можно навесить свои ограничения через «прокси-классы». 🔎 Почему это важно Symfony 7.4 — это не просто «новые фишки», это стремление к чистоте архитектуры, к уменьшению шаблонного кода и увеличению устойчивости. Это значит: 🔸 меньше boilerplate, меньше копипасты; 🔸 легче поддерживать, рефакторить и тестировать код; 🔸 проще масштабировать проекты — меньше «магии» конфигураций, больше явного, понятного кода; 🔸 долгосрочная стабильность: LTS-версия, с поддержкой багфиксов до 2028 и патчей безопасности до 2029. Если вы всё ещё на Symfony 6.4 или 7.x — сейчас самое время планировать миграцию. Особенно, если проект живёт и будет жить несколько лет. 📅 Что делать прямо сейчас Проверьте, что ваш PHP ≥ 8.2 — это минимальное требование для 7.4. Проанализируйте, где у вас используются маршруты, проверки CurrentUser, слушатели событий, валидация/сериализация — подумайте, как они могут упроститься. Поднимите 7.4 на тестовом окружении, прогоните тесты — и постепенно заменяйте устаревшие YAML/аннотации/дублирование на современные атрибуты. 👉 Читать статью Библиотека пхпшника

💡 Совет по Laravel: Форматоры Faker Поскольку Laravel использует FakerPHP для генерации фиктивных данных, вы можете использовать как numerify, так и bothify для генерации данных по определенному шаблону 🚀. Библиотека пхпшника 📍 Навигация: Вакансии • Задачи • Вопросы с собеса #vardump

💻 Подборка новостей по PHP за неделю:​ 🔹 CakePHP 4.6.3 — исправлены предупреждения о депрекейшнах в PHP 8.4 и 8.5, а также ошибки при работе с подзапросами, которые уже были выполнены. 🔹 PhpStorm 2025.3 — крупное обновление IDE: нативная интеграция Claude Agent, поддержка Laravel «из коробки», совместимость с PHP 8.5, улучшенная работа с дженериками и новая тема Islands. 🔹 Laravel 12.41 — представлен обновлённый современный шаблон писем, добавлены хелперы для длительностей (миллисекунды, недели, месяцы) и команда перезагрузки сервисов во время деплоя. 🔹 Symfony 8.0.2 — maintenance-релиз с исправлениями и улучшениями стабильности. 🔹 Symfony 1–7 декабря — активная работа над багфиксами после релиза Symfony 7.4 и 8.0, опубликован отчёт с SymfonyCon Amsterdam и анонсирована конференция SymfonyCon Warsaw 2026. Библиотека пхпшника #свежак

📚 Laravel Up & Running, 3rd Edition: A Framework for Building Modern PHP Apps (2023) Если ты давно смотришь на Laravel, но каждый раз откладываешь «до выходных, когда будет время» — вот тот самый пинок 🦵 Автор объясняет фреймворк так, чтобы опытный PHP-разработчик мог быстро въехать и начать писать живые продакшен-проекты. Что внутри 👇 🟡 Быстрый вход в Laravel 11: что изменилось, как сейчас устроены auth, фронтовый туллинг и первые шаги в экосистеме 🟡 Blade без боли: как не превращать шаблоны в спагетти и использовать компоненты и слоты по уму 🟡 Работа с данными: сбор, валидация, нормализация и фильтрация пользовательского ввода так, чтобы не стыдно было смотреть в логах 🟡 Eloquent ORM: грамотные модели, связи, запросы и работа с несколькими базами — без магии, но с пониманием, что происходит под капотом 🟡 Жизненный цикл запроса: Illuminate request object и то, как запрос гуляет по приложению 🟡 Тестирование по-взрослому: PHPUnit, Mockery, Dusk — как прикрутить автотесты так, чтобы они реально спасали, а не просто «чтобы были» 🟡 JSON и REST API: построение API на Laravel и с учётом современных требований 🟡 Интерфейсы для файлов, сессий, кэша и поиска: как не завязываться на конкретное хранилище и спокойно мигрировать 🟡 Очереди, события, задачи, WebSocket-ивенты: чтобы фоновые задачи и realtime-фичи не превращались в монстра 🟡 Scout, Passport, Cashier и компания: обзор first-party пакетов, с которыми меньше кода и больше фич 🔗 Скачать 🐸 Книги для программистов | Поддержать бустом

#байтовый_юмор

📣 Многие встроенные классы Laravel имеют метод под названием «macro». Например, Collection, Str, Arr, Request, Cache, File и так далее. Вы можете определить собственные методы для этих классов, подобно этому ☝️ Библиотека пхпшника

👨‍💻 Где читаете про новые фичи и лучшие практики Официальные доки — это хорошо. Но давайте честно: половину знаний мы получаем из случайных статей, чьих-то каналов и обсуждений в комментариях. Интересно узнать: 📌 Какие телеграм-каналы или блоги вы читаете регулярно? 📌 Есть ли YouTube-каналы, которые реально помогли разобраться в сложных темах? 📌 В каких комьюнити задаёте вопросы, когда застряли? 📌 Кто из авторов объясняет так, что всё сразу становится понятно? 🎈 Может быть, вы сами ведёте блог или делитесь опытом — расскажите об этом тоже, пришло ваше время! Соберём список реально полезных мест для разработчиков. Пишите в комментариях ⬇️ 🐸 Библиотека пхпшника

🐘 PHP для начинающих: Маршрутизация в Laravel В Laravel маршруты — это каркас вашего приложения. Web-маршруты живут в routes/web.php, API — в routes/api.php, а каналы трансляций — в routes/channels.php (появляются после install:api или install:broadcast). Если говорить практично, ключевые вещи, которые должен помнить каждый разработчик: • Базовые маршруты легко описывать замыканиями — удобно для простых страниц. • Вербы маршрутов (get, post, put, delete, match, any) позволяют тонко управлять поведением приложения. • Контроллеры лучше использовать, когда логика разрастается — код становится чище и масштабируемее. • Параметры маршрутов могут быть обязательными, опциональными и ограниченными по regex. • Именованные маршруты дают стабильные ссылки и избавляют от жёстких URL в шаблонах. Кому важна архитектурная чистота, удобная навигация и качественная API-структура — разбор в статье ниже будет особенно полезен. 👉 Подробнее в статье — разбор всех примеров и нюансов маршрутизации Laravel. Библиотека пхпшника

🧠 Лайфхак: Активное использование консоли ⚡ Зачем активно использовать консоль ✅ Консоль даёт быстрый доступ к внутренним инструментам фреймворка: генерация кода, миграции, очистка кешей, тестирование, выполнение скриптов — всё через одну команду. ✅ Это экономит время: часто операции, которые вручную занимают несколько минут (создание модели + контроллера + миграции + сидера), превращаются в одну строку. ✅ Понижает рутинную нагрузку и человеческий фактор — меньше шансов допустить ошибку вручную при копи-пейсте, при генерации boilerplate-кода, при очистке кеша и т.п. ✅ Консоль позволяет быстро экспериментировать — запускать куски кода, тестировать модели, делать запросы к БД, без необходимости писать контроллеры или временные скрипты. 🔧 Что даёт консоль во Laravel & Symfony 🛠️ Основные возможности Artisan (в Laravel) — набор встроенных CLI-команд для генерации моделей, контроллеров, миграций, фабрик, сидеров и др Tinker — интерактивная REPL-консоль, позволяющая напрямую взаимодействовать с приложением: работать с моделями, делать запросы, проверять логику, не создавая маршруты/контроллеры. Возможность создавать свои консольные команды — для автоматизации задач, которые повторяются: очистка кешей, рассылки, миграции, бэкапы, отчёты и др. Планировщик задач (scheduler) — можно запускать команды по расписанию, автоматизируя фоновые процессы. 🧠 Примеры, как консоль ускоряет вашу работу ➤ Быстрая генерация структуры Вместо ручного создания файла модели, миграции, контроллера, фабрики — просто: php artisan make:model Post -mfc (модель + миграция + фабрика + контроллер) — буквально за секунды. ➤ Эксперименты «на лету» Открыл консоль через php artisan tinker, написал пару строк: запросил модель, проверил данные, протестировал логику — без лишнего кода, без запуска браузера. ➤ Автоматизация рутинных задач Например, можно сделать команду для очистки кешей, логов, старых данных — и запускать её вручную или по расписанию, без лишних усилий. ➤ Быстрый деплой / обслуживание Через CLI можно прогнать миграции, сброс кешей, подготовить окружение, выполнить задачи перед деплоем — удобно и надёжно. ✅ Когда и как лучше использовать 🔸 Используйте консоль, когда делаете рутинные или повторяющиеся действия: генерация кода, миграции, очистка кешей, сидинг, бэкапы. 🔸 В момент разработки — для быстрых тестов, прототипирования, проверки моделей, структур данных. 🔸 В продакшн/CI/CD — для автоматизации задач, миграций, задач обслуживания. 🔸 Создавайте собственные console-команды для специфичных задач: отчётов, задач очистки, миграций, операций над БД, фоновых job-ов. Библиотека пхпшника

🐇 Publish без подтверждений в RabbitMQ: почему так работает и что с этим делать Сегодня разберём один практический кейс. Тема старая, но до сих пор вызывающая недопонимание: почему basic.publish в RabbitMQ по умолчанию не гарантирует доставку сообщения, и как правильно работать с подтверждениями. 🔸 Почему basic.publish не надёжен из коробки Метод basic.publish в AMQP 0-9-1 не имеет возвратной части. То есть он работает в режиме fire-and-forget — семантика at most once. RabbitMQ базируется именно на AMQP 0-9-1 (AMQP 1.0 добавлен с версии 4.0, но это в основном надстройки, а не новое поведение). 📌 В отличие от других методов AMQP, у basic.publish нет пары some-method-ok. Это значит, что отправитель не знает, дошло ли сообщение до брокера. И да — в 99.999% случаев всё будет хорошо. Но если вам нужна гарантированная доставка, на одном только basic.publish далеко не уедешь. 🔸 Зачем так сделано AMQP создавали в JPMorgan — под задачи финансового сектора. Там есть сценарии, где огромные потоки данных (например, котировки с частотой 10k+ событий/сек) допускают потерю части сообщений. Для таких задач fire-and-forget — нормальное поведение. Для строгой гарантированной доставки в спецификации AMQP предусмотрены транзакции.

В AMQP 2.2.3 прямо сказано: «Success is silent, and failure is noisy. When applications need explicit tracking of success and failure, they should use transactions.»

Но: 🟢 транзакции в RabbitMQ замедляют publish до 250 раз (по данным официальной документации), 🟢 в RabbitMQ транзакции — лишь «простая форма батчинга», без ACID, 🟢 под каждый publish транзакцию заводить бессмысленно. Итог: транзакции — рудимент, использовать их в RMQ почти никогда не стоит. 🔸 Как это исправили в RabbitMQ Команда RabbitMQ расширила протокол AMQP и добавила механизм Publisher Confirms — подтверждения на уровне basic.publish. Это не часть стандарта AMQP, а собственное расширение RabbitMQ. Но именно оно стало де-факто стандартом для гарантированной доставки сообщений. 🔸 Как работает Publisher Confirms Канал переводится в режим подтверждений методом: $channel->confirm_select(); После этого RabbitMQ: считает каждое опубликованное сообщение, отправляет ack или nack после обработки, гарантирует, что отправитель узнает результат. Главное — вызывать: $channel->wait_for_pending_acks(); Он блокирует выполнение, пока брокер не даст ответы по всем сообщениям. 🔗 Хабр Библиотека пхпшника

🔥 How to: Упростить сложные запросы в репозитории с помощью Specification Pattern Когда метод репозитория разрастается до сотен строк с подзапросами, условными блоками и повторяющимися правилами, поддержка кода становится дорогой и рискованной. Частые ошибки, сложность тестирования и высокий порог входа — типичные последствия. Specification Pattern позволяет разложить такую логику на небольшие независимые компоненты. Каждый класс отвечает за одно правило фильтрации, а общий запрос строится путем композиции этих правил. Архитектура становится чище, поведение — прозрачнее, тестирование — проще. Что даёт подход: 🔸 разбиение огромных методов на компактные блоки; 🔸 минимизацию дублирования логики; 🔸 предсказуемость и лёгкую расширяемость; 🔸 существенное снижение сложности и рост покрытия тестами. 👉 Читать статью Библиотека пхпшника

#байтовый_юмор

Opis/closure Это библиотека для PHP, которая даёт возможность сериализовать (преобразовать в строку/байты) замыкания (closures / анонимные функции), а также анонимные классы и произвольные данные. По умолчанию PHP не поддерживает сериализацию замыканий: попытка вызвать serialize() на Closure приводит к ошибке. Opis/closure обходит это ограничение, обёртывая замыкание — и благодаря этому Вы можете сериализовать, передавать, хранить, а потом восстанавливать функцию и её контекст. ✅ Основные возможности 🔸 Поддержка PHP 8.0+ (включая 8.5) — современный синтаксис, типы, readonly-свойства, атрибуты и пр. 🔸 Сериализация замыканий, анонимных классов, сложных объектов, включая структуры с круговыми ссылками. 🔸 Возможность «безопасного» сериализования: есть поддержка подписанных (signed) данных. 🔸 Не требуется каких-либо расширений PHP (например, FFI) — всё реализовано «на чистом PHP». 🔸 Универсальность: не просто для замыканий — можно сериализовать «любой сложный объект», что даёт гибкость. 📦 Где это используется — и зачем Вам может пригодиться Фреймворки и библиотеки, которым нужно отложенно сохранять/восстанавливать функции — например, очередь задач, jobs, callback-хранение. Если хотите передавать анонимные функции между процессами, сохранять их в БД, передавать через очереди — без описания «класса + метод». При необходимости сериализовать объекты с нестандартным состоянием, содержащие функции или анонимные классы. Для систем, где нужно «сохранить и восстановить» произвольное состояние (функции, контекст, данные), несмотря на ограничение PHP на сериализацию замыканий. ⚠️ Что важно учитывать 🔹 Библиотека поддерживает PHP 8.0+; если проект на более старой версии — могут быть ограничения. 🔹 Бывают нюансы с «безопасностью»: если используются подписанные сериализованные данные и разные ключи — при десериализации может быть ошибка. 🔹 Как и с любой подобной техникой — злоумелое использование (например, unserialize от данных из ненадёжного источника) — может быть рискованным. 🔗 Github Библиотека пхпшника

PostgreSQL vs MongoDB — что выбрать? В разработке часто сталкиваешься с вопросом: какую СУБД выбрать — реляционную или документо-ориентированную? Но правильный вопрос не «какая база лучше», а «какая подходит под ваши задачи». Обе технологии заслужили доверие и популярность — просто они решают разные задачи. 🔎 Основные отличия 🛡️ PostgreSQL — реляционная СУБД с таблицами, строгими схемами и SQL, хорошо подходит для надёжных, структурированных моделей. 🌐 MongoDB — документно-ориентированная NoSQL-СУБД, хранит данные как JSON-/BSON-документы без жёсткой схемы — больше гибкости для меняющихся, динамических данных. PostgreSQL обеспечивает ACID-транзакции, целостность, сложные связи и надёжность. MongoDB даёт гибкость, масштабируемость и простоту схемы, особенно когда структура данных может изменяться. ✅ Когда PostgreSQL — ваш выбор 🟦 Структурированные данные, чёткие связи между сущностями. 🟦 Необходимы транзакции, консистентность, строгие ограничения (финансы, учёт, бухгалтерия, критичные операции). 🟦 Сложные запросы, отчёты, JOIN-ы, аналитика, отчётность. 🟦 Долгосрочное хранение, стабильность, предсказуемость схемы и данных. ✅ Когда MongoDB — лучший вариант 🟩 Данные меняются часто; структура может эволюционировать, добавляются новые поля, типы записей. 🟩 Необходима гибкость: документы, JSON-объекты, агрегации, неструктурированные или полуструктурированные данные. 🟩 Требуется горизонтальное масштабирование, распределённое хранилище, высокая нагрузка на запись/чтение. 🟩 Быстрая разработка, прототипы, MVP, где хочется избежать долгих миграций схем. 👉 Полная статья с примерами и различными сценариями Библиотека пхпшника