Composer ломается не в пакете, а в том, как вы собираете проект

За багами с зависимостями почти всегда стоят три вещи: слишком широкий constraint, отсутствие lock-файла в коммите и ручные правки vendor. Composer не магия, а детерминированный сборщик: если входные данные плавают, на выходе получите разные деревья пакетов на разных машинах.

Смотрите на require как на контракт, а не как на просьбу. • Не ставьте "звёздочки" без причины • Для библиотек держите совместимость шире, для приложений — уже • После изменения зависимостей запускайте update осознанно, а не на автомате. И отдельно: composer.lock должен жить в репозитории приложения, иначе у команды будет несколько «рабочих» сборок одновременно.

Ещё два правила, которые спасают релизы: не смешивайте major-обновления с рефакторингом и проверяйте platform packages. Если у вас в CI один PHP, а на проде другой, Composer может собрать проект, который локально проходит, а на сервере падает. Туда же относится ext-* и конфликтующие пакеты: лучше увидеть проблему на install, чем в рантайме.

Финал простой: перед мерджем зависимостей смотрите не на список обновлений, а на diff lock-файла и на то, что реально изменилось в дереве пакетов.

7 PHP-ошибок, которые незаметно ломают продакшн и отладку

Первая ловушка — смешивать бизнес-логику и работу с I/O в одном методе. Такой код сложно тестировать, а падение на внешнем сервисе маскирует реальную причину сбоя.

Вторая — полагаться на неявные преобразования типов. PHP многое «прощает», но потом это выстреливает в валидации, сравнениях и фильтрах. Сравнивай явно, особенно там, где участвуют строки, числа и `null`.

Третья — ловить `Exception` везде подряд и молча проглатывать ошибку. Если лог пустой, инцидент превращается в гадание. Минимум — контекст, максимум — отдельные типы ошибок и понятные сообщения.

Четвёртая — тащить в код массивы без формы. Когда структура не зафиксирована, баги прячутся в ключах, а не в логике. Для сложных данных лучше DTO, value objects или хотя бы строгие соглашения по полям.

Пятая — писать SQL/запросы так, будто N+1 «и так сойдёт». На локали всё быстро, в реальном трафике начинается деградация. Проверяй количество запросов и не делай лишнюю работу в циклах.

Если нужен базовый фильтр качества — ищи не «работает ли код», а «понятно ли, где он упадёт, и можно ли это быстро найти».

Как уходят из арбитража трафика: интервью с бывшим медиабайером

Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…

➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom

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

Livewire ломают не «магия PHP», а грязные границы между состоянием и UI

Если компонент начинает «сам решать» и валидацию, и загрузку данных, и рендер, и права доступа — он быстро превращается в мини-контроллер без структуры. Держите правило: один компонент = одна пользовательская задача. Всё, что относится к домену, выносите в сервисы, actions или query objects.

За этим обычно идут три проблемы:
— состояние хранится не там и не сбрасывается после действий;
— в шаблоне появляется лишняя логика, которую потом трудно тестировать;
— запросы в БД размножаются при каждом перерендере.

Отдельно следите за ключами в списках и вложенных компонентах. Если ключи плавают, Livewire начинает путать элементы, а вместе с ними — инпуты, ошибки валидации и временные значения. Ещё одна типовая ошибка — тащить в public-свойства тяжёлые модели вместо простых скаляров или DTO. Это раздувает сериализацию и делает компонент хрупким.

Хорошая практика простая: минимальный state, явные методы действий, вычисления — в отдельный слой, а UI-компоненту оставьте только сбор событий и вывод данных. Тогда Livewire остаётся быстрым, предсказуемым и нормально тестируется.

Composer ломается не в install, а в структуре проекта — 5 проверок перед запуском

Если пакет не ставится, сначала смотрят не на Composer, а на сам репозиторий: где лежит код, что объявлено в autoload, есть ли конфликт имён и не сломан ли корень проекта.

— composer.json должен описывать один понятный вход: PSR-4, корректный namespace, без дублей в autoload и autoload-dev.
— Если пакет — библиотека, проверь type, require и extra: лишние зависимости тянут за собой мусор в конечный проект.
— Для монорепы и локальной разработки не путай path-репозитории с рабочей копией пакета: после правки не забывай пересобирать автозагрузку.
— Конфликт версий часто сидит не в самом пакете, а в верхнеуровневом constraint: один жёсткий диапазон может заблокировать весь граф зависимостей.
— Если автозагрузка ведёт себя странно, первым делом проверь классы с одинаковыми именами, старые файлы в vendor и кеши генерации.

Хорошая привычка — прогонять composer validate, затем composer dump-autoload, и только потом искать баг в коде.

7 ошибок в Laravel-проектах, которые потом бьют по скорости, тестам и деплою

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

— Не тащите запросы в циклах: N+1 маскируется на маленьких данных и взрывается в проде.
— Не держите логику в FormRequest, Resource и Blade одновременно: один сценарий должен жить в одном слое.
— Не используйте фасады как повод не думать о зависимостях: тестировать такие места потом больно.

Есть наблюдение которое стоит проверить: если класс трудно назвать одним предложением, он уже делает слишком много. В Laravel это часто видно в сервисах на 500 строк, где смешаны валидация, доступ к БД, кеш и отправка уведомлений. Такой код почти невозможно безопасно рефакторить без регресса.

Практика простая: выносите операции в маленькие action-классы, для чтения данных используйте отдельные query-объекты или репозитории, а для внешних интеграций — тонкие адаптеры. Тогда PHPUnit покрывает поведение, а не угадывает намерения автора.

Если проект начинает «тормозить головой», сначала режьте связанность, потом уже ищите узкие места в SQL и кеше.

ByteDance анонсировала новую версию SeeDance версии 2.5

ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…

➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5

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

Codex уничтожит твой SSD за год

Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…

➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god

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

5 PHPUnit-проверок, которые экономят часы дебага в PHP-проекте

PHPUnit часто используют как «проверку на зелёную кнопку», но его ценность — в защите бизнес-логики от тихих поломок. Особенно там, где код трогает скидки, статусы, права доступа и интеграции.

— Тестируйте не только happy path. Ошибки, пустые входные данные, неверные статусы и запрещённые переходы ломают продукт чаще, чем «идеальный» сценарий.

— Проверяйте границы: ноль, пустую строку, null, длинный массив, дубликаты. Именно на границах прячутся баги, которые потом выглядят как «магия».

— Изолируйте внешние зависимости: HTTP, очередь, почта, файловая система, время. В тесте должен быть контроль, а не надежда на стабильность окружения.

— Ставьте осмысленные названия тестам: не `testSomething()`, а поведение в стиле `it_blocks_payment_for_expired_order`. Такой тест проще читать и чинить.

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

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

Spatie — пакетная экосистема, которую в проекте часто недооценивают до первого хаоса

У Spatie сильная сторона не в одном «магическом» пакете, а в наборе мелких решений, которые снимают рутину: permissions, media library, activity log, data transfer objects, backup, sitemap, ray-интеграции. Если держите Laravel-проект с админкой, CRM или внутренним сервисом, сначала смотрите не на кастом, а на то, есть ли у Spatie уже готовый кирпич.

Правило отбора простое:
— пакет должен закрывать типовую задачу без лишней магии;
— API должно читаться через код, а не через полдня в документации;
— модель расширения важнее «быстро завелось»;
— если пакет лезет в много мест приложения, проверьте, как он ведет себя в тестах и при обновлениях.

Главная ошибка — тащить Spatie как набор разрозненных зависимостей без единого подхода. Тогда появляются разные способы хранения настроек, разные модели прав, разный стиль событий и очередей. Лучше заранее договориться: где лежат конфиги, кто владеет миграциями, как вы пишете обертки над фасадами, и какие части пакета вообще разрешено использовать в доменной логике.

Еще одна полезная привычка — смотреть на пакеты Spatie как на слой инфраструктуры, а не как на замену архитектуре. Они хорошо работают, когда вы хотите сократить число самописных сервисов и оставить в проекте только то, что реально отличает ваш продукт от остальных.

Если пакет экономит время сейчас, но делает проект хрупким через полгода, это не ускорение, а долг. Выбирайте Spatie там, где он убирает повторяющийся код и не мешает вашему доменному ядру.

Composer ломается не в install, а в неверной структуре пакета и зависимостей

Если 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 становится скучным — а это лучший режим для деплоя.

Google ужесточает модерацию финансовой вертикали

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

5 признаков хорошего PHP-пакета: на чём ломаются проекты после установки

Хороший пакет в Composer — это не тот, у которого красивая README. Это тот, который не начинает жить своей жизнью после первого же обновления.

Проверь пакет по пяти вещам:
— API: минимальный, понятный, без десятка «магических» методов.
— Зависимости: чем их меньше, тем проще сопровождать и переиспользовать код.
— Тесты: если покрыт только happy path, пакет уже требует осторожности.
— Сервис-провайдеры и конфиг: пакет не должен навязывать лишнюю инфраструктуру.
— Совместимость: если автор ломает публичные методы без миграции, это не «смелый рефакторинг», а риск для продакшена.

Отдельно смотрю на то, как пакет ведёт себя в Laravel-проекте:
— не тащит лишние фасады и глобальное состояние;
— не прячет логику в хелперах без возможности подмены;
— не конфликтует с очередями, событиями и автозагрузкой.

Если пакет нужен для CRM, трекинга или админки, выбирай тот, который можно удалить без археологии по всему проекту. Чем легче он встраивается и откатывается, тем меньше сюрпризов у команды.

Перед установкой задавай один вопрос: смогу ли я сопровождать это через полгода, если автор исчезнет? Вот этот тест обычно честнее любой звезды на GitHub.

Filament ломают не кнопки: 5 правил, чтобы админка не превратилась в хаос

Filament любят за скорость сборки, но на живом проекте он быстро показывает слабые места. Если оставить «как вышло», через пару спринтов админка начинает тормозить разработку: сложные поля размазываются по страницам, логика дублируется, а права доступа живут отдельно от UI.

• Выноси бизнес-логику из ресурсов в сервисы или actions. Resource должен описывать форму и таблицу, а не решать, как считается статус заказа.
• Не плодите кастомные поля без причины. Часто хватает стандартных компонентов, а переусложнение делает поддержку дороже.
• Для больших таблиц сразу планируй фильтры, сортировки и eager loading. Иначе N+1 всплывает в самом неудобном месте.
• Политики и видимость действий проверяй на уровне модели, а не только в интерфейсе. Скрытая кнопка — не защита.
• Повторяющиеся схемы выноси в переиспользуемые классы или макросы, иначе каждая новая сущность будет копией предыдущей.

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

Если админка уже начала разрастаться, первым делом режьте дублирование и отделяйте домен от интерфейса — это экономит недели поддержки.

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