Spatie — пакетная экосистема, которую в проекте часто недооценивают до первого хаоса
У Spatie сильная сторона не в одном «магическом» пакете, а в наборе мелких решений, которые снимают рутину: permissions, media library, activity log, data transfer objects, backup, sitemap, ray-интеграции. Если держите Laravel-проект с админкой, CRM или внутренним сервисом, сначала смотрите не на кастом, а на то, есть ли у Spatie уже готовый кирпич.
Правило отбора простое:
— пакет должен закрывать типовую задачу без лишней магии;
— API должно читаться через код, а не через полдня в документации;
— модель расширения важнее «быстро завелось»;
— если пакет лезет в много мест приложения, проверьте, как он ведет себя в тестах и при обновлениях.
Главная ошибка — тащить Spatie как набор разрозненных зависимостей без единого подхода. Тогда появляются разные способы хранения настроек, разные модели прав, разный стиль событий и очередей. Лучше заранее договориться: где лежат конфиги, кто владеет миграциями, как вы пишете обертки над фасадами, и какие части пакета вообще разрешено использовать в доменной логике.
Еще одна полезная привычка — смотреть на пакеты Spatie как на слой инфраструктуры, а не как на замену архитектуре. Они хорошо работают, когда вы хотите сократить число самописных сервисов и оставить в проекте только то, что реально отличает ваш продукт от остальных.
Если пакет экономит время сейчас, но делает проект хрупким через полгода, это не ускорение, а долг. Выбирайте Spatie там, где он убирает повторяющийся код и не мешает вашему доменному ядру.
У Spatie сильная сторона не в одном «магическом» пакете, а в наборе мелких решений, которые снимают рутину: permissions, media library, activity log, data transfer objects, backup, sitemap, ray-интеграции. Если держите Laravel-проект с админкой, CRM или внутренним сервисом, сначала смотрите не на кастом, а на то, есть ли у Spatie уже готовый кирпич.
Правило отбора простое:
— пакет должен закрывать типовую задачу без лишней магии;
— API должно читаться через код, а не через полдня в документации;
— модель расширения важнее «быстро завелось»;
— если пакет лезет в много мест приложения, проверьте, как он ведет себя в тестах и при обновлениях.
Главная ошибка — тащить Spatie как набор разрозненных зависимостей без единого подхода. Тогда появляются разные способы хранения настроек, разные модели прав, разный стиль событий и очередей. Лучше заранее договориться: где лежат конфиги, кто владеет миграциями, как вы пишете обертки над фасадами, и какие части пакета вообще разрешено использовать в доменной логике.
Еще одна полезная привычка — смотреть на пакеты Spatie как на слой инфраструктуры, а не как на замену архитектуре. Они хорошо работают, когда вы хотите сократить число самописных сервисов и оставить в проекте только то, что реально отличает ваш продукт от остальных.
Если пакет экономит время сейчас, но делает проект хрупким через полгода, это не ускорение, а долг. Выбирайте Spatie там, где он убирает повторяющийся код и не мешает вашему доменному ядру.
Composer ломается не в install, а в неверной структуре пакета и зависимостей
Если Composer ведёт себя странно, проблема часто не в нём, а в метаданных пакета. Проверь первым делом:
—
— PSR-4: путь и namespace должны совпадать без «почти»
—
Для рабочей установки важнее не «поставилось», а чтобы граф зависимостей был предсказуемым. Если пакет требует слишком широкий диапазон версий, он начнёт конфликтовать не сразу, а на следующем апгрейде соседнего модуля.
Проверяй не только root-проект, но и то, что утащит твой пакет в чужой код:
— не переопределяй без нужды общие библиотеки
— не тащи в production лишние dev-required зависимости
— следи за автозагрузкой файлов и classmap, если пакет старый или нестандартный
Ещё одна типовая ошибка — обновлять всё подряд без фиксации границ. Для проекта полезнее короткая дисциплина: сначала
Если держать пакет чистым на уровне метаданных, Composer становится скучным — а это лучший режим для деплоя.
Если Composer ведёт себя странно, проблема часто не в нём, а в метаданных пакета. Проверь первым делом:
—
composer.json: имя, тип, лицензия, autoload, require и conflicts— PSR-4: путь и namespace должны совпадать без «почти»
—
minimum-stability и prefer-stable: не загоняй проект в случайные dev-зависимостиДля рабочей установки важнее не «поставилось», а чтобы граф зависимостей был предсказуемым. Если пакет требует слишком широкий диапазон версий, он начнёт конфликтовать не сразу, а на следующем апгрейде соседнего модуля.
Проверяй не только root-проект, но и то, что утащит твой пакет в чужой код:
— не переопределяй без нужды общие библиотеки
— не тащи в production лишние dev-required зависимости
— следи за автозагрузкой файлов и classmap, если пакет старый или нестандартный
Ещё одна типовая ошибка — обновлять всё подряд без фиксации границ. Для проекта полезнее короткая дисциплина: сначала
composer validate, потом composer why и composer why-not, и только после этого правки в зависимостях.Если держать пакет чистым на уровне метаданных, Composer становится скучным — а это лучший режим для деплоя.
This media is not supported in your browser
VIEW IN TELEGRAM
Google ужесточает модерацию финансовой вертикали
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
Composer ломает проект не из-за пакетов, а из-за того, как им пользуются
В Laravel/PHP-стеке Composer — не просто «установщик зависимостей», а точка, где фиксируется весь контракт проекта: версии, автозагрузка, платформенные ограничения и поведение скриптов.
Если нужен стабильный репозиторий, проверьте базовые вещи:
— lock-файл должен жить в VCS;
— диапазоны версий в composer.json не должны быть слишком широкими;
— platform.php помогает не поставить пакет, который не поедет на сервере;
— scripts и post-install команды не должны прятать бизнес-логику.
Частая ошибка — тянуть всё через dev-master и потом удивляться, почему на соседнем окружении проект ведёт себя иначе. Вторая — ставить пакет «на глаз», не глядя в его зависимости: один конфликт по symfony/polyfill или psr/container способен разнести весь граф.
Для командной работы полезно держать отдельный ритуал: обновление зависимостей делается через pull request, а не вручную на боевом сервере. Тогда можно увидеть, кто именно принёс изменение в дерево пакетов, и быстро откатить проблему.
Если Composer у вас работает только как install, проект уже живёт в зоне риска. Нормальная дисциплина — это lock, контроль платформы и регулярная проверка дерева зависимостей перед тем, как код попадёт дальше по пайплайну.
В Laravel/PHP-стеке Composer — не просто «установщик зависимостей», а точка, где фиксируется весь контракт проекта: версии, автозагрузка, платформенные ограничения и поведение скриптов.
Если нужен стабильный репозиторий, проверьте базовые вещи:
— lock-файл должен жить в VCS;
— диапазоны версий в composer.json не должны быть слишком широкими;
— platform.php помогает не поставить пакет, который не поедет на сервере;
— scripts и post-install команды не должны прятать бизнес-логику.
Частая ошибка — тянуть всё через dev-master и потом удивляться, почему на соседнем окружении проект ведёт себя иначе. Вторая — ставить пакет «на глаз», не глядя в его зависимости: один конфликт по symfony/polyfill или psr/container способен разнести весь граф.
Для командной работы полезно держать отдельный ритуал: обновление зависимостей делается через pull request, а не вручную на боевом сервере. Тогда можно увидеть, кто именно принёс изменение в дерево пакетов, и быстро откатить проблему.
Если Composer у вас работает только как install, проект уже живёт в зоне риска. Нормальная дисциплина — это lock, контроль платформы и регулярная проверка дерева зависимостей перед тем, как код попадёт дальше по пайплайну.
5 признаков хорошего PHP-пакета: на чём ломаются проекты после установки
Хороший пакет в Composer — это не тот, у которого красивая README. Это тот, который не начинает жить своей жизнью после первого же обновления.
Проверь пакет по пяти вещам:
— API: минимальный, понятный, без десятка «магических» методов.
— Зависимости: чем их меньше, тем проще сопровождать и переиспользовать код.
— Тесты: если покрыт только happy path, пакет уже требует осторожности.
— Сервис-провайдеры и конфиг: пакет не должен навязывать лишнюю инфраструктуру.
— Совместимость: если автор ломает публичные методы без миграции, это не «смелый рефакторинг», а риск для продакшена.
Отдельно смотрю на то, как пакет ведёт себя в Laravel-проекте:
— не тащит лишние фасады и глобальное состояние;
— не прячет логику в хелперах без возможности подмены;
— не конфликтует с очередями, событиями и автозагрузкой.
Если пакет нужен для CRM, трекинга или админки, выбирай тот, который можно удалить без археологии по всему проекту. Чем легче он встраивается и откатывается, тем меньше сюрпризов у команды.
Перед установкой задавай один вопрос: смогу ли я сопровождать это через полгода, если автор исчезнет? Вот этот тест обычно честнее любой звезды на GitHub.
Хороший пакет в Composer — это не тот, у которого красивая README. Это тот, который не начинает жить своей жизнью после первого же обновления.
Проверь пакет по пяти вещам:
— API: минимальный, понятный, без десятка «магических» методов.
— Зависимости: чем их меньше, тем проще сопровождать и переиспользовать код.
— Тесты: если покрыт только happy path, пакет уже требует осторожности.
— Сервис-провайдеры и конфиг: пакет не должен навязывать лишнюю инфраструктуру.
— Совместимость: если автор ломает публичные методы без миграции, это не «смелый рефакторинг», а риск для продакшена.
Отдельно смотрю на то, как пакет ведёт себя в Laravel-проекте:
— не тащит лишние фасады и глобальное состояние;
— не прячет логику в хелперах без возможности подмены;
— не конфликтует с очередями, событиями и автозагрузкой.
Если пакет нужен для CRM, трекинга или админки, выбирай тот, который можно удалить без археологии по всему проекту. Чем легче он встраивается и откатывается, тем меньше сюрпризов у команды.
Перед установкой задавай один вопрос: смогу ли я сопровождать это через полгода, если автор исчезнет? Вот этот тест обычно честнее любой звезды на GitHub.
Filament ломают не кнопки: 5 правил, чтобы админка не превратилась в хаос
Filament любят за скорость сборки, но на живом проекте он быстро показывает слабые места. Если оставить «как вышло», через пару спринтов админка начинает тормозить разработку: сложные поля размазываются по страницам, логика дублируется, а права доступа живут отдельно от UI.
• Выноси бизнес-логику из ресурсов в сервисы или actions. Resource должен описывать форму и таблицу, а не решать, как считается статус заказа.
• Не плодите кастомные поля без причины. Часто хватает стандартных компонентов, а переусложнение делает поддержку дороже.
• Для больших таблиц сразу планируй фильтры, сортировки и eager loading. Иначе N+1 всплывает в самом неудобном месте.
• Политики и видимость действий проверяй на уровне модели, а не только в интерфейсе. Скрытая кнопка — не защита.
• Повторяющиеся схемы выноси в переиспользуемые классы или макросы, иначе каждая новая сущность будет копией предыдущей.
Есть наблюдение которое стоит проверить: Filament лучше всего работает там, где админка — это не отдельный продукт, а тонкий слой над доменной моделью. Чем меньше «магии» в ресурсах, тем проще тестировать, переиспользовать и передавать проект другому инженеру.
Если админка уже начала разрастаться, первым делом режьте дублирование и отделяйте домен от интерфейса — это экономит недели поддержки.
Filament любят за скорость сборки, но на живом проекте он быстро показывает слабые места. Если оставить «как вышло», через пару спринтов админка начинает тормозить разработку: сложные поля размазываются по страницам, логика дублируется, а права доступа живут отдельно от UI.
• Выноси бизнес-логику из ресурсов в сервисы или actions. Resource должен описывать форму и таблицу, а не решать, как считается статус заказа.
• Не плодите кастомные поля без причины. Часто хватает стандартных компонентов, а переусложнение делает поддержку дороже.
• Для больших таблиц сразу планируй фильтры, сортировки и eager loading. Иначе N+1 всплывает в самом неудобном месте.
• Политики и видимость действий проверяй на уровне модели, а не только в интерфейсе. Скрытая кнопка — не защита.
• Повторяющиеся схемы выноси в переиспользуемые классы или макросы, иначе каждая новая сущность будет копией предыдущей.
Есть наблюдение которое стоит проверить: Filament лучше всего работает там, где админка — это не отдельный продукт, а тонкий слой над доменной моделью. Чем меньше «магии» в ресурсах, тем проще тестировать, переиспользовать и передавать проект другому инженеру.
Если админка уже начала разрастаться, первым делом режьте дублирование и отделяйте домен от интерфейса — это экономит недели поддержки.
This media is not supported in your browser
VIEW IN TELEGRAM
Fable 5 скоро вернётся в публичный доступ
В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…
➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup
🧠 Ещё больше инсайтов → в канале AFF.top
В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…
➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup
🧠 Ещё больше инсайтов → в канале AFF.top
PHP-проект начинает тормозить не из-за фреймворка: проверьте эти 5 мест первым делом
Если в Laravel или Symfony “всё стало медленно”, причина часто не в роутинге и не в Eloquent. Обычно узкое место сидит рядом: в запросах, автозагрузке, кешах, очередях или файловой системе.
— Сначала смотрите N+1 и лишние eager load. Один «удобный» accessor на списке может превратить страницу в десятки запросов.
— Потом проверьте индексы и состав запроса: сортировка по неиндексированному полю, `LIKE '%...%'` и тяжёлые join’ы убивают ответ быстрее, чем любой сервисный слой.
— Дальше автозагрузка Composer: лишние пакеты, глубокие цепочки зависимостей и мусор в `autoload` бьют по времени старта каждого воркера.
— Не забудьте про кеши конфигурации и маршрутов: если приложение постоянно читает и собирает метаданные на лету, оно само себе создаёт лишнюю работу.
— И отдельно посмотрите на диск: логи, сессии, временные файлы, генерация изображений, синхронные записи в storage. I/O часто маскируется под “проблему PHP”.
Хорошая диагностика начинается с простого: замерьте время SQL, время PHP и время внешних вызовов отдельно. Тогда тормоз ищется не по ощущениям, а по факту.
Если в Laravel или Symfony “всё стало медленно”, причина часто не в роутинге и не в Eloquent. Обычно узкое место сидит рядом: в запросах, автозагрузке, кешах, очередях или файловой системе.
— Сначала смотрите N+1 и лишние eager load. Один «удобный» accessor на списке может превратить страницу в десятки запросов.
— Потом проверьте индексы и состав запроса: сортировка по неиндексированному полю, `LIKE '%...%'` и тяжёлые join’ы убивают ответ быстрее, чем любой сервисный слой.
— Дальше автозагрузка Composer: лишние пакеты, глубокие цепочки зависимостей и мусор в `autoload` бьют по времени старта каждого воркера.
— Не забудьте про кеши конфигурации и маршрутов: если приложение постоянно читает и собирает метаданные на лету, оно само себе создаёт лишнюю работу.
— И отдельно посмотрите на диск: логи, сессии, временные файлы, генерация изображений, синхронные записи в storage. I/O часто маскируется под “проблему PHP”.
Хорошая диагностика начинается с простого: замерьте время SQL, время PHP и время внешних вызовов отдельно. Тогда тормоз ищется не по ощущениям, а по факту.
Symfony ломается не в контроллере, а на границе между слоями
В проектах на Symfony чаще всего течёт не «фреймворк», а архитектурная дисциплина. Контроллер должен собирать вход, вызвать сервис и вернуть ответ; всё остальное уезжает в доменный слой, форму или отдельный handler. Как только в action появляются SQL, условные ветки по ролям и сборка HTML — код перестаёт быть тестируемым.
Есть три места, где стоит держать порядок:
— Request DTO или Form: валидация и нормализация входа
— Service/UseCase: бизнес-правило без HTTP-зависимостей
— Repository: только доступ к данным, без магии и сайд-эффектов
Ещё одна типовая ошибка — тащить container везде, где удобно. В Symfony это особенно соблазнительно, потому что сервисы рядом, но зависимость через контейнер скрывает контракт и усложняет тесты. Лучше явно прокидывать интерфейсы и держать сервисы маленькими: один класс — одна причина для изменения.
Если нужен быстрый аудит проекта, проверьте: есть ли у контроллеров только orchestration, можно ли поднять use case без ядра HTTP, и есть ли у каждого сервиса понятная зона ответственности. Там, где ответ «нет», и прячется будущий рефакторинг.
В проектах на Symfony чаще всего течёт не «фреймворк», а архитектурная дисциплина. Контроллер должен собирать вход, вызвать сервис и вернуть ответ; всё остальное уезжает в доменный слой, форму или отдельный handler. Как только в action появляются SQL, условные ветки по ролям и сборка HTML — код перестаёт быть тестируемым.
Есть три места, где стоит держать порядок:
— Request DTO или Form: валидация и нормализация входа
— Service/UseCase: бизнес-правило без HTTP-зависимостей
— Repository: только доступ к данным, без магии и сайд-эффектов
Ещё одна типовая ошибка — тащить container везде, где удобно. В Symfony это особенно соблазнительно, потому что сервисы рядом, но зависимость через контейнер скрывает контракт и усложняет тесты. Лучше явно прокидывать интерфейсы и держать сервисы маленькими: один класс — одна причина для изменения.
Если нужен быстрый аудит проекта, проверьте: есть ли у контроллеров только orchestration, можно ли поднять use case без ядра HTTP, и есть ли у каждого сервиса понятная зона ответственности. Там, где ответ «нет», и прячется будущий рефакторинг.
Composer ломается не из‑за пакетов, а из‑за дисциплины зависимостей
Если в проекте внезапно «поплыл» автолоад, сначала смотрите не на Composer, а на то, как живёт composer.json: • лишние прямые зависимости вместо транзитивных • версии без ограничений по смыслу • пакеты, которые тянут конфликтующие расширения PHP • ручные правки в vendor, которые потом никто не повторяет.
Вторая точка боли — lock-файл. Он нужен не «для галочки», а чтобы одинаково собирать проект на локали, в CI и на проде. Если composer.lock не коммитят, у команды будет каждый раз другой набор пакетов, а баги начнут выглядеть как магия.
Третье правило: ставьте обновления только через понятный сценарий. Сначала composer update конкретного пакета, потом тесты, потом проверка автозагрузки и конфликтов. Массовый update без причины почти всегда приносит больше шума, чем пользы. Ещё полезно держать под рукой composer validate и composer diagnose — они быстро находят мусор в конфиге и проблемы среды 🔧
Итог простой: Composer хорош там, где зависимости описаны аккуратно, lock-файл живёт в репозитории, а обновления идут по одному пакету, а не по принципу «потом разберёмся».
Если в проекте внезапно «поплыл» автолоад, сначала смотрите не на Composer, а на то, как живёт composer.json: • лишние прямые зависимости вместо транзитивных • версии без ограничений по смыслу • пакеты, которые тянут конфликтующие расширения PHP • ручные правки в vendor, которые потом никто не повторяет.
Вторая точка боли — lock-файл. Он нужен не «для галочки», а чтобы одинаково собирать проект на локали, в CI и на проде. Если composer.lock не коммитят, у команды будет каждый раз другой набор пакетов, а баги начнут выглядеть как магия.
Третье правило: ставьте обновления только через понятный сценарий. Сначала composer update конкретного пакета, потом тесты, потом проверка автозагрузки и конфликтов. Массовый update без причины почти всегда приносит больше шума, чем пользы. Ещё полезно держать под рукой composer validate и composer diagnose — они быстро находят мусор в конфиге и проблемы среды 🔧
Итог простой: Composer хорош там, где зависимости описаны аккуратно, lock-файл живёт в репозитории, а обновления идут по одному пакету, а не по принципу «потом разберёмся».
This media is not supported in your browser
VIEW IN TELEGRAM
Chat GPT-5.6 будут выдавать лишь избранным
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
Vk удалили из App store: что дальше?
Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…
➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe
🧠 Ещё больше инсайтов → в канале AFF.top
Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…
➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe
🧠 Ещё больше инсайтов → в канале AFF.top
Filament ломается не в CRUD, а в связке форм, policy и действий
Если Filament начал вести себя «странно», обычно проблема не в самом админ-UI, а в трёх местах: авторизация, состояние формы и побочные действия. На ровном CRUD это не видно, но как только появляются зависимости между полями, вложенные relation manager и массовые операции — всплывает реальная архитектура.
Проверь базовый порядок:
— доступ к ресурсу и странице отдельно от доступа к записи;
— hidden/disabled поля не должны быть единственным источником бизнес-логики;
— валидация должна жить не только в форме, но и на уровне модели или сервиса.
Частая ошибка — дублировать правила в каждом action. Тогда один create работает, а edit, bulk action или modal action обходят ограничение. В Filament лучше вынести правило в одно место и использовать его везде, где меняется доменная сущность.
Ещё одна зона риска — тяжёлые вычисления в `afterStateUpdated`. Если поле тянет расчёты, запросы или цепочку зависимых обновлений, интерфейс начинает «тупить» и ловить неожиданные циклы. Здесь помогает простой принцип: форма собирает данные, сервис их обрабатывает.
Если админка стала хрупкой, сначала упрости связь между UI и доменом. Filament любит чистые границы — и резко хуже переносит бизнес-логику, размазанную по полям, actions и страницам.
Если Filament начал вести себя «странно», обычно проблема не в самом админ-UI, а в трёх местах: авторизация, состояние формы и побочные действия. На ровном CRUD это не видно, но как только появляются зависимости между полями, вложенные relation manager и массовые операции — всплывает реальная архитектура.
Проверь базовый порядок:
— доступ к ресурсу и странице отдельно от доступа к записи;
— hidden/disabled поля не должны быть единственным источником бизнес-логики;
— валидация должна жить не только в форме, но и на уровне модели или сервиса.
Частая ошибка — дублировать правила в каждом action. Тогда один create работает, а edit, bulk action или modal action обходят ограничение. В Filament лучше вынести правило в одно место и использовать его везде, где меняется доменная сущность.
Ещё одна зона риска — тяжёлые вычисления в `afterStateUpdated`. Если поле тянет расчёты, запросы или цепочку зависимых обновлений, интерфейс начинает «тупить» и ловить неожиданные циклы. Здесь помогает простой принцип: форма собирает данные, сервис их обрабатывает.
Если админка стала хрупкой, сначала упрости связь между UI и доменом. Filament любит чистые границы — и резко хуже переносит бизнес-логику, размазанную по полям, actions и страницам.
Composer ломает проект не в vendor, а в привычках команды
За неделю в репах: половина «странных» багов после установки пакетов — это не пакет, а дисциплина вокруг Composer.
• Не коммитьте vendor, если у вас не зафиксирован особый сценарий деплоя.
• Всегда храните composer.lock в репозитории: без него вы не воспроизводите сборку.
• Не правьте зависимости руками в JSON, если можно использовать require/update/remove и сразу проверять конфликт.
Ещё три места, где обычно прячется боль: autoload, scripts и платформенные требования. Если PSR-4 маппинг расходится с реальной структурой, классы «пропадают» только на части окружений. Скрипты удобны, пока в них не складывают всё подряд: лучше держать там тонкие команды, а бизнес-логику — в коде. platform.php и ext-список помогают поймать несовместимость до выката, а не после.
Полезная привычка: перед merge прогоняйте composer validate, composer install и проверку автозагрузки в чистом окружении. Если проект большой, отдельно фиксируйте набор пакетов для dev и production — так проще понять, откуда пришла поломка.
Composer не про «поставить пакет», а про воспроизводимость. Чем раньше команда это принимает, тем меньше сюрпризов на стенде и в проде.
За неделю в репах: половина «странных» багов после установки пакетов — это не пакет, а дисциплина вокруг Composer.
• Не коммитьте vendor, если у вас не зафиксирован особый сценарий деплоя.
• Всегда храните composer.lock в репозитории: без него вы не воспроизводите сборку.
• Не правьте зависимости руками в JSON, если можно использовать require/update/remove и сразу проверять конфликт.
Ещё три места, где обычно прячется боль: autoload, scripts и платформенные требования. Если PSR-4 маппинг расходится с реальной структурой, классы «пропадают» только на части окружений. Скрипты удобны, пока в них не складывают всё подряд: лучше держать там тонкие команды, а бизнес-логику — в коде. platform.php и ext-список помогают поймать несовместимость до выката, а не после.
Полезная привычка: перед merge прогоняйте composer validate, composer install и проверку автозагрузки в чистом окружении. Если проект большой, отдельно фиксируйте набор пакетов для dev и production — так проще понять, откуда пришла поломка.
Composer не про «поставить пакет», а про воспроизводимость. Чем раньше команда это принимает, тем меньше сюрпризов на стенде и в проде.
Spatie в Laravel: 6 пакетов, которые экономят недели на типовом PHP-стеке
Если в проекте уже есть auth, очереди и нормальный деплой, Spatie закрывает скучную, но дорогую часть разработки. Ставка обычно делается не на «магический пакет», а на набор узких инструментов, которые не конфликтуют друг с другом.
Что чаще всего берут в прод:
—
—
—
—
—
Есть наблюдение которое стоит проверить: Spatie лучше всего работает там, где вы не пытаетесь натянуть пакет на хаос. Сначала задайте модель данных и правила доступа, потом подключайте пакет. Иначе получаются красивые фасады поверх путаницы.
Перед внедрением проверьте три вещи: конфликты с кастомными политиками, нагрузку на файловое хранилище и то, как пакет ведет себя в тестах. Особенно это важно для MediaLibrary и Permission — оба любят, когда у проекта уже есть дисциплина в моделях и миграциях.
Если нужен быстрый эффект без переписывания ядра, начинайте с permission и query builder: они дают порядок в самом проблемном месте и не требуют менять весь домен.
Если в проекте уже есть auth, очереди и нормальный деплой, Spatie закрывает скучную, но дорогую часть разработки. Ставка обычно делается не на «магический пакет», а на набор узких инструментов, которые не конфликтуют друг с другом.
Что чаще всего берут в прод:
—
spatie/laravel-permission для ролей и прав без самописной таблицы ACL—
spatie/laravel-medialibrary для файлов, превью и коллекций медиа—
spatie/laravel-query-builder когда API уже выросло и фильтры надо стандартизировать—
spatie/laravel-activitylog если нужен аудит действий, а не «смотрим по логам сервера»—
spatie/laravel-backup чтобы бэкап был частью приложения, а не надеждой на хостингЕсть наблюдение которое стоит проверить: Spatie лучше всего работает там, где вы не пытаетесь натянуть пакет на хаос. Сначала задайте модель данных и правила доступа, потом подключайте пакет. Иначе получаются красивые фасады поверх путаницы.
Перед внедрением проверьте три вещи: конфликты с кастомными политиками, нагрузку на файловое хранилище и то, как пакет ведет себя в тестах. Особенно это важно для MediaLibrary и Permission — оба любят, когда у проекта уже есть дисциплина в моделях и миграциях.
Если нужен быстрый эффект без переписывания ядра, начинайте с permission и query builder: они дают порядок в самом проблемном месте и не требуют менять весь домен.
Forwarded from Потрачено! Клуб спящих бизнесменов!
Коллеги, тут типа серьёзный пост про кое что новое....
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
Livewire тормозит не из-за фреймворка, а из-за лишних перерисовок и тяжёлых хендлеров
Livewire удобно тащит состояние в PHP, но за это платит частыми запросами и повторным рендером. Если компонент начинает «думать» на каждый чих, UI быстро превращается в кашу.
Проверь базовые вещи:
— не вешай на один компонент и форму, и фильтры, и таблицу;
— выноси тяжёлые вычисления в сервисы, а не в методы рендера;
— не гоняй в `wire:model` всё подряд, когда достаточно `defer` или ручного `submit`;
— для больших списков сразу используй пагинацию, а не попытку показать всё на одном экране.
Ещё одна типовая ошибка — лишние события между компонентами. Когда дочерний компонент начинает стрелять в родителя по каждому действию, ты получаешь не архитектуру, а цепочку каскадных обновлений.
Если нужен живой интерфейс без сюрпризов, держи компонент коротким: одна зона ответственности, минимум скрытой логики, максимум предсказуемых запросов. В Livewire это работает лучше любой «магии».
Livewire удобно тащит состояние в PHP, но за это платит частыми запросами и повторным рендером. Если компонент начинает «думать» на каждый чих, UI быстро превращается в кашу.
Проверь базовые вещи:
— не вешай на один компонент и форму, и фильтры, и таблицу;
— выноси тяжёлые вычисления в сервисы, а не в методы рендера;
— не гоняй в `wire:model` всё подряд, когда достаточно `defer` или ручного `submit`;
— для больших списков сразу используй пагинацию, а не попытку показать всё на одном экране.
Ещё одна типовая ошибка — лишние события между компонентами. Когда дочерний компонент начинает стрелять в родителя по каждому действию, ты получаешь не архитектуру, а цепочку каскадных обновлений.
Если нужен живой интерфейс без сюрпризов, держи компонент коротким: одна зона ответственности, минимум скрытой логики, максимум предсказуемых запросов. В Livewire это работает лучше любой «магии».