Fable 5 скоро вернётся в публичный доступ

В исходном коде 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 и время внешних вызовов отдельно. Тогда тормоз ищется не по ощущениям, а по факту.

Symfony ломается не в контроллере, а на границе между слоями

В проектах на 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-файл живёт в репозитории, а обновления идут по одному пакету, а не по принципу «потом разберёмся».

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

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

Filament ломается не в CRUD, а в связке форм, policy и действий

Если 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 не про «поставить пакет», а про воспроизводимость. Чем раньше команда это принимает, тем меньше сюрпризов на стенде и в проде.

Spatie в Laravel: 6 пакетов, которые экономят недели на типовом PHP-стеке

Если в проекте уже есть 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: они дают порядок в самом проблемном месте и не требуют менять весь домен.

Livewire тормозит не из-за фреймворка, а из-за лишних перерисовок и тяжёлых хендлеров

Livewire удобно тащит состояние в PHP, но за это платит частыми запросами и повторным рендером. Если компонент начинает «думать» на каждый чих, UI быстро превращается в кашу.

Проверь базовые вещи:
— не вешай на один компонент и форму, и фильтры, и таблицу;
— выноси тяжёлые вычисления в сервисы, а не в методы рендера;
— не гоняй в `wire:model` всё подряд, когда достаточно `defer` или ручного `submit`;
— для больших списков сразу используй пагинацию, а не попытку показать всё на одном экране.

Ещё одна типовая ошибка — лишние события между компонентами. Когда дочерний компонент начинает стрелять в родителя по каждому действию, ты получаешь не архитектуру, а цепочку каскадных обновлений.

Если нужен живой интерфейс без сюрпризов, держи компонент коротким: одна зона ответственности, минимум скрытой логики, максимум предсказуемых запросов. В Livewire это работает лучше любой «магии».