Laravel-проект, который не разваливается: 7 вещей, которые фиксируют порядок
Если проект живёт дольше пары спринтов, хаос почти всегда приходит через одно и то же: разъезжающиеся слои, жирные контроллеры, магию в моделях и «временные» костыли, которые потом никто не находит.
— Контроллер отвечает только за вход/выход. Вся бизнес-логика уезжает в сервисы, action-классы или доменные объекты.
— Валидация не размазана по коду: Form Request для HTTP, отдельные правила для внутренних сценариев.
— Модели не становятся свалкой. Accessor, mutator, observer и scope — только если это реально про поведение модели.
— Запросы к БД не прячутся в шаблонах и не живут в циклах. Всё тяжёлое — в репозитории, query object или отдельном классе.
— Имена файлов и классов должны объяснять роль без чтения содержимого. Если название надо расшифровывать — уже проблема.
— Любой «быстрый фикс» либо сразу оборачивается тестом, либо помечается как временный технический долг. Иначе он становится постоянным.
— Общие правила для проекта лучше держать в одном месте: формат ответа, обработка ошибок, авторизация, типовые DTO.
Laravel сам по себе не спасает от архитектурной каши. Он просто позволяет написать её быстрее, если не держать границы.
Хорошая привычка: перед новым фичерным кодом спросить себя, куда пойдёт логика через 3 месяца. Если ответ «везде» — это сигнал остановиться.
Если проект живёт дольше пары спринтов, хаос почти всегда приходит через одно и то же: разъезжающиеся слои, жирные контроллеры, магию в моделях и «временные» костыли, которые потом никто не находит.
— Контроллер отвечает только за вход/выход. Вся бизнес-логика уезжает в сервисы, action-классы или доменные объекты.
— Валидация не размазана по коду: Form Request для HTTP, отдельные правила для внутренних сценариев.
— Модели не становятся свалкой. Accessor, mutator, observer и scope — только если это реально про поведение модели.
— Запросы к БД не прячутся в шаблонах и не живут в циклах. Всё тяжёлое — в репозитории, query object или отдельном классе.
— Имена файлов и классов должны объяснять роль без чтения содержимого. Если название надо расшифровывать — уже проблема.
— Любой «быстрый фикс» либо сразу оборачивается тестом, либо помечается как временный технический долг. Иначе он становится постоянным.
— Общие правила для проекта лучше держать в одном месте: формат ответа, обработка ошибок, авторизация, типовые DTO.
Laravel сам по себе не спасает от архитектурной каши. Он просто позволяет написать её быстрее, если не держать границы.
Хорошая привычка: перед новым фичерным кодом спросить себя, куда пойдёт логика через 3 месяца. Если ответ «везде» — это сигнал остановиться.
Octane ускоряет Laravel, но ломается там, где код писали под «каждый запрос заново»
Главная ловушка — состояние. Всё, что живёт в singleton, статике, глобальном helper-кэше или замыкании контейнера, может пережить запрос и утащить за собой старые данные. Проверяйте сервисы на утечки: не храните user context, tenant, request, locale и connection state дольше одного цикла.
Вторая зона риска — фасады, события и сторонние пакеты. Если пакет внутри держит mutable-объект или полагается на сброс локального кэша между запросами, под Octane он начинает «плавать». Отдельно смотрите на очереди, транзакции и авторизацию: после warm-up они должны работать так же, как в обычном PHP-FPM.
Практика простая: убирайте состояние в request-scoped объекты, очищайте кеши в terminate/hook, не используйте static для бизнес-логики и прогоняйте нагрузочный сценарий с повторяющимися пользователями, а не только с «пустыми» запросами. Если баг исчезает после перезапуска воркера — это почти всегда намёк на утечку состояния.
Octane даёт прирост только тем проектам, где код написан как stateless. Сначала чините границы состояния, потом включайте ускорение — иначе вы просто ускорите воспроизведение багов.
Главная ловушка — состояние. Всё, что живёт в singleton, статике, глобальном helper-кэше или замыкании контейнера, может пережить запрос и утащить за собой старые данные. Проверяйте сервисы на утечки: не храните user context, tenant, request, locale и connection state дольше одного цикла.
Вторая зона риска — фасады, события и сторонние пакеты. Если пакет внутри держит mutable-объект или полагается на сброс локального кэша между запросами, под Octane он начинает «плавать». Отдельно смотрите на очереди, транзакции и авторизацию: после warm-up они должны работать так же, как в обычном PHP-FPM.
Практика простая: убирайте состояние в request-scoped объекты, очищайте кеши в terminate/hook, не используйте static для бизнес-логики и прогоняйте нагрузочный сценарий с повторяющимися пользователями, а не только с «пустыми» запросами. Если баг исчезает после перезапуска воркера — это почти всегда намёк на утечку состояния.
Octane даёт прирост только тем проектам, где код написан как stateless. Сначала чините границы состояния, потом включайте ускорение — иначе вы просто ускорите воспроизведение багов.
5 ошибок в Laravel, из-за которых проект медленно деградирует и дорожает в поддержке
Чаще всего Laravel не «ломается» — его постепенно делают неудобным. И это видно не в роуте или контроллере, а в мелочах, которые потом превращаются в техдолг.
— Логика уезжает в контроллеры. В итоге один метод знает про валидацию, оплату, уведомления и побочные эффекты. Лучше выносить сценарий в сервис, action или job, а контроллер оставить тонким.
— Модели начинают жить как свалка. Accessors, мутаторы, запросы, бизнес-правила и форматирование в одном месте — плохой знак. Модель должна быть про состояние и связи, а не про весь продукт.
— Запросы пишутся «как получилось». Без eager loading, без scope, без индексов, с N+1 в циклах. На маленьком объёме это не видно, на живом трафике — уже боль.
— Валидация размазана по коду. Часть в контроллере, часть в модели, часть в JavaScript. Потом никто не может быстро понять, где у запроса настоящий контракт.
— Очереди и события используются как магия, а не как граница ответственности. Если job зависит от неявного состояния или event вызывает слишком много сайд-эффектов, отладка быстро становится лотереей.
Есть наблюдение которое стоит проверить: если новый разработчик не может за 15 минут понять, где заканчивается HTTP-слой и начинается бизнес-логика, архитектура уже расползается.
Держите контроллеры тонкими, а сценарии — явными. Тогда Laravel остаётся быстрым не только на запросе, но и в сопровождении.
Чаще всего Laravel не «ломается» — его постепенно делают неудобным. И это видно не в роуте или контроллере, а в мелочах, которые потом превращаются в техдолг.
— Логика уезжает в контроллеры. В итоге один метод знает про валидацию, оплату, уведомления и побочные эффекты. Лучше выносить сценарий в сервис, action или job, а контроллер оставить тонким.
— Модели начинают жить как свалка. Accessors, мутаторы, запросы, бизнес-правила и форматирование в одном месте — плохой знак. Модель должна быть про состояние и связи, а не про весь продукт.
— Запросы пишутся «как получилось». Без eager loading, без scope, без индексов, с N+1 в циклах. На маленьком объёме это не видно, на живом трафике — уже боль.
— Валидация размазана по коду. Часть в контроллере, часть в модели, часть в JavaScript. Потом никто не может быстро понять, где у запроса настоящий контракт.
— Очереди и события используются как магия, а не как граница ответственности. Если job зависит от неявного состояния или event вызывает слишком много сайд-эффектов, отладка быстро становится лотереей.
Есть наблюдение которое стоит проверить: если новый разработчик не может за 15 минут понять, где заканчивается HTTP-слой и начинается бизнес-логика, архитектура уже расползается.
Держите контроллеры тонкими, а сценарии — явными. Тогда Laravel остаётся быстрым не только на запросе, но и в сопровождении.
Vite ускоряет проект только тогда, когда вы не тащите в него старый Webpack-мысленный стиль
Если оставить конфиг «как попало», Vite быстро превращается из ускорителя в источник странных багов. Главные места, где спотыкаются:
— импорт всего подряд из commonjs-пакетов без проверки совместимости;
— алиасы, которые не совпадают в vite.config и tsconfig;
— ожидание, что все env-переменные попадут в клиент автоматически.
Для React-проекта базовый чек простой: держите зависимости ESM-готовыми, следите за одинаковыми путями импорта и не смешивайте dev-логики с прод-сборкой. Если библиотека тянет тяжёлый CJS-слой, проверьте, не ломает ли она tree-shaking и не раздувает ли бандл. У Vite это особенно заметно: сборка быстрая, но лишний мусор видно сразу.
Ещё одна типовая ошибка — использовать Vite только как «быстрый стартер» и не настраивать окружение. Переменные вида VITE_* должны быть предсказуемыми, а всё секретное — оставаться на сервере. Иначе фронт начинает зависеть от случайных значений, которые трудно повторить локально и на стенде.
Если проект растёт, Vite выигрывает не скоростью старта, а дисциплиной вокруг модулей, алиасов и окружения.
Если оставить конфиг «как попало», Vite быстро превращается из ускорителя в источник странных багов. Главные места, где спотыкаются:
— импорт всего подряд из commonjs-пакетов без проверки совместимости;
— алиасы, которые не совпадают в vite.config и tsconfig;
— ожидание, что все env-переменные попадут в клиент автоматически.
Для React-проекта базовый чек простой: держите зависимости ESM-готовыми, следите за одинаковыми путями импорта и не смешивайте dev-логики с прод-сборкой. Если библиотека тянет тяжёлый CJS-слой, проверьте, не ломает ли она tree-shaking и не раздувает ли бандл. У Vite это особенно заметно: сборка быстрая, но лишний мусор видно сразу.
Ещё одна типовая ошибка — использовать Vite только как «быстрый стартер» и не настраивать окружение. Переменные вида VITE_* должны быть предсказуемыми, а всё секретное — оставаться на сервере. Иначе фронт начинает зависеть от случайных значений, которые трудно повторить локально и на стенде.
Если проект растёт, Vite выигрывает не скоростью старта, а дисциплиной вокруг модулей, алиасов и окружения.
This media is not supported in your browser
VIEW IN TELEGRAM
Claude скоро станет по паспорту
С 8 июля 2026 года все модели Claude потребуют верификации личности через паспорт и селфи. Это произошло после закрытия доступа к Fable 5, выпущенной в открытый доступ буквально на неделю. Ограничение касается веб-версии на сайте Anthropic, но остаётся неясным, будут ли верификацию требовать API и AI-агенты вроде Codex. Решение выглядит излишне строгим в свете качества моделей, однако компания явно ужесточает контроль над доступом к своим продук…
➡️ Читайте на сайте: https://aff.top/blog/claude-skoro-stanet-po-pasportu
🧠 Ещё больше инсайтов → в канале AFF.top
С 8 июля 2026 года все модели Claude потребуют верификации личности через паспорт и селфи. Это произошло после закрытия доступа к Fable 5, выпущенной в открытый доступ буквально на неделю. Ограничение касается веб-версии на сайте Anthropic, но остаётся неясным, будут ли верификацию требовать API и AI-агенты вроде Codex. Решение выглядит излишне строгим в свете качества моделей, однако компания явно ужесточает контроль над доступом к своим продук…
➡️ Читайте на сайте: https://aff.top/blog/claude-skoro-stanet-po-pasportu
🧠 Ещё больше инсайтов → в канале AFF.top
Push-permission rate растёт не из кнопки, а из сценария до неё
Если вы показываете системный попап сразу после первого экрана — вы почти всегда срезаете согласие. Пользователь ещё не понял ценность, а уже должен выбрать. Работает другой порядок: сначала короткий pre-prompt, потом объяснение, зачем нужны пуши именно в этом WebView.
Что важно:
— формулировка в pre-prompt должна быть конкретной: «получать статусы, напоминания, доступ к новым офферам», а не «улучшить опыт»
— кнопка «Разрешить» должна быть визуально сильнее, чем «Позже»
— первый экран после открытия должен вести к действию, а не к чтению простыни
— не просите permission до первого микро-успеха: клик, свайп, выбор категории, запуск квиза
На практике лучше всего работает двухшаговая логика: пользователь видит пользу, совершает простое действие, затем получает permission request в момент, когда уже есть доверие. Если просить слишком рано — вы теряете часть аудитории навсегда. Если слишком поздно — часть уже ушла и окно согласия закрыто.
Ещё один момент: не маскируйте системный запрос под «обязательное» действие. Люди чаще соглашаются, когда понимают, что это опция, а не блокировка. Хороший ориентир — сначала прогреть, потом попросить, и только после этого повторять через новый смысловой экран.
Если вы показываете системный попап сразу после первого экрана — вы почти всегда срезаете согласие. Пользователь ещё не понял ценность, а уже должен выбрать. Работает другой порядок: сначала короткий pre-prompt, потом объяснение, зачем нужны пуши именно в этом WebView.
Что важно:
— формулировка в pre-prompt должна быть конкретной: «получать статусы, напоминания, доступ к новым офферам», а не «улучшить опыт»
— кнопка «Разрешить» должна быть визуально сильнее, чем «Позже»
— первый экран после открытия должен вести к действию, а не к чтению простыни
— не просите permission до первого микро-успеха: клик, свайп, выбор категории, запуск квиза
На практике лучше всего работает двухшаговая логика: пользователь видит пользу, совершает простое действие, затем получает permission request в момент, когда уже есть доверие. Если просить слишком рано — вы теряете часть аудитории навсегда. Если слишком поздно — часть уже ушла и окно согласия закрыто.
Ещё один момент: не маскируйте системный запрос под «обязательное» действие. Люди чаще соглашаются, когда понимают, что это опция, а не блокировка. Хороший ориентир — сначала прогреть, потом попросить, и только после этого повторять через новый смысловой экран.
Где дата-центр прокси в 10 раз дешевле резидентных — и почему это не мёртвая ниша
Дата-центр прокси мёртв для Facebook и TikTok, но остаётся рабочим инструментом в SEO- и аналитических задачах. Главное преимущество — скорость, стабильный пинг и цена за IP. Если не маскироваться под пользователя, а собирать публичные данные, банить начинают не сразу.
Google: парсинг выдачи, проверка позиций, мониторинг ставок в Google Ads. При низкой частоте запросов (до 1-2 в секунду с одного IP) и правильных User-Agent Google редко выдаёт капчу. Работает через desktop-выдачу с нужным geo. Для сбора семантики и отслеживания конкурентов DC-прокси остаются стандартом.
Яндекс: Вордстат, Директ.Коммандер, проверка объявлений и ставок. Яндекс агрессивнее крупных дата-центров, но пропускает запросы из региональных подсетей и при использовании мобильных заголовков. Парсинг выдачи через XML или мобильную версию требует ротации каждые 5-10 запросов, но остаётся дешевле мобильных прокси на порядок.
Что важно: чистые IP не из топовых ASN (OVH, Hetzner, AWS), ротация по запросам или таймауту, корректные TLS- fingerprint и заголовки. Без этого даже резидентный прокси словит бан.
На практике: если задача — сбор данных, а не имитация реального пользователя, берите дата-центр с фильтром по ASN и тестируйте пул на целевом сервисе перед покупкой. Экономия на трафике — 70-90% по сравнению с резидентом.
Дата-центр прокси мёртв для Facebook и TikTok, но остаётся рабочим инструментом в SEO- и аналитических задачах. Главное преимущество — скорость, стабильный пинг и цена за IP. Если не маскироваться под пользователя, а собирать публичные данные, банить начинают не сразу.
Google: парсинг выдачи, проверка позиций, мониторинг ставок в Google Ads. При низкой частоте запросов (до 1-2 в секунду с одного IP) и правильных User-Agent Google редко выдаёт капчу. Работает через desktop-выдачу с нужным geo. Для сбора семантики и отслеживания конкурентов DC-прокси остаются стандартом.
Яндекс: Вордстат, Директ.Коммандер, проверка объявлений и ставок. Яндекс агрессивнее крупных дата-центров, но пропускает запросы из региональных подсетей и при использовании мобильных заголовков. Парсинг выдачи через XML или мобильную версию требует ротации каждые 5-10 запросов, но остаётся дешевле мобильных прокси на порядок.
Что важно: чистые IP не из топовых ASN (OVH, Hetzner, AWS), ротация по запросам или таймауту, корректные TLS- fingerprint и заголовки. Без этого даже резидентный прокси словит бан.
На практике: если задача — сбор данных, а не имитация реального пользователя, берите дата-центр с фильтром по ASN и тестируйте пул на целевом сервисе перед покупкой. Экономия на трафике — 70-90% по сравнению с резидентом.
Filament ломает не админку, а дисциплину вокруг полей, ролей и таблиц
Если в проекте Filament “вроде бы уже стоит”, а дальше начинаются костыли, обычно проблема не в пакете. Проблема в том, что ресурс собирают как набор красивых форм, а не как слой управления данными. Отсюда дубли полей, лишние запросы и страницы, которые невозможно сопровождать без боли.
Перед тем как добавлять новый Resource, проверь базу:
— какие поля реально нужны оператору;
— какие действия можно вынести в отдельный Action;
— где нужен RelationManager, а где достаточно таблицы с фильтром;
— какие поля должны быть read-only, чтобы не плодить ошибки.
Если этого нет, Filament быстро превращается в конструктор случайных экранов.
Отдельно смотри на авторизацию. Policies и scopes должны определять доступ до рендера интерфейса, а не после клика по кнопке. Иначе у тебя “красивый” экран, который показывает лишние строки, лишние кнопки и лишние ожидания у команды поддержки. Для CRM, трекеров и арбитражной инфраструктуры это особенно дорого.
Ещё одна частая ошибка — тащить в форму тяжелую логику из модели. В Filament лучше держать UI тонким: валидация, отображение, простые трансформации. Бизнес-правила — в сервисах или доменном слое, иначе любое изменение формы начинает ломать не только админку, но и запись данных.
Если Filament используется как операционная панель, а не как витрина, он окупается быстро. Но сначала сделай ресурсы скучными, предсказуемыми и узкими — именно это потом экономит недели поддержки.
Если в проекте Filament “вроде бы уже стоит”, а дальше начинаются костыли, обычно проблема не в пакете. Проблема в том, что ресурс собирают как набор красивых форм, а не как слой управления данными. Отсюда дубли полей, лишние запросы и страницы, которые невозможно сопровождать без боли.
Перед тем как добавлять новый Resource, проверь базу:
— какие поля реально нужны оператору;
— какие действия можно вынести в отдельный Action;
— где нужен RelationManager, а где достаточно таблицы с фильтром;
— какие поля должны быть read-only, чтобы не плодить ошибки.
Если этого нет, Filament быстро превращается в конструктор случайных экранов.
Отдельно смотри на авторизацию. Policies и scopes должны определять доступ до рендера интерфейса, а не после клика по кнопке. Иначе у тебя “красивый” экран, который показывает лишние строки, лишние кнопки и лишние ожидания у команды поддержки. Для CRM, трекеров и арбитражной инфраструктуры это особенно дорого.
Ещё одна частая ошибка — тащить в форму тяжелую логику из модели. В Filament лучше держать UI тонким: валидация, отображение, простые трансформации. Бизнес-правила — в сервисах или доменном слое, иначе любое изменение формы начинает ломать не только админку, но и запись данных.
Если Filament используется как операционная панель, а не как витрина, он окупается быстро. Но сначала сделай ресурсы скучными, предсказуемыми и узкими — именно это потом экономит недели поддержки.
Octane ускоряет Laravel не магией, а ценой дисциплины в коде и окружении
Octane полезен там, где приложение много раз выполняет один и тот же bootstrap: меньше повторной инициализации, меньше лишней работы на каждый запрос. Но вместе со скоростью он приносит главный риск — состояние, которое живёт дольше одного HTTP-запроса.
Есть наблюдение которое стоит проверить: если в приложении есть глобальные синглтоны, статические кэши, мутируемые сервисы или «удобные» вспомогательные переменные в контейнере, Octane быстро превращает это в баги. То, что в FPM сбрасывалось после запроса, здесь может протечь в следующий запрос.
Перед включением проверь:
— нет ли записи в статические свойства из request scope;
— не хранится ли пользовательский контекст в singleton-сервисах;
— не мутируются ли объекты, которые должны пересоздаваться;
— очищаются ли слушатели, очереди, буферы и временные коллекции.
Для теста возьми один и тот же сценарий с разными пользователями подряд. Если ответы начинают «помнить» чужие данные — проблема не в Octane, а в lifecycle приложения. Он просто делает её видимой. ⚠️
Хорошая практика простая: всё, что зависит от запроса, держи в scoped-объектах или передавай явно. Тогда Octane даст ускорение без сюрпризов.
Octane полезен там, где приложение много раз выполняет один и тот же bootstrap: меньше повторной инициализации, меньше лишней работы на каждый запрос. Но вместе со скоростью он приносит главный риск — состояние, которое живёт дольше одного HTTP-запроса.
Есть наблюдение которое стоит проверить: если в приложении есть глобальные синглтоны, статические кэши, мутируемые сервисы или «удобные» вспомогательные переменные в контейнере, Octane быстро превращает это в баги. То, что в FPM сбрасывалось после запроса, здесь может протечь в следующий запрос.
Перед включением проверь:
— нет ли записи в статические свойства из request scope;
— не хранится ли пользовательский контекст в singleton-сервисах;
— не мутируются ли объекты, которые должны пересоздаваться;
— очищаются ли слушатели, очереди, буферы и временные коллекции.
Для теста возьми один и тот же сценарий с разными пользователями подряд. Если ответы начинают «помнить» чужие данные — проблема не в Octane, а в lifecycle приложения. Он просто делает её видимой. ⚠️
Хорошая практика простая: всё, что зависит от запроса, держи в scoped-объектах или передавай явно. Тогда Octane даст ускорение без сюрпризов.
PHP ломается не там, где синтаксис, а где типы и границы входных данных
В реальных проектах большинство багов в PHP сидят в одном из трёх мест: вход пришёл не того типа, строка внезапно пустая, массив оказался ассоциативным вместо списка. Самый дешёвый способ ловить это — не доверять данным из request, env, queue payload и внешних API по умолчанию.
Минимальный чек-лист:
— включайте strict_types там, где это не ломает легаси;
— валидируйте форму данных до бизнес-логики;
— не смешивайте “null значит нет значения” и “пустая строка значит пусто”;
— для массивов проверяйте не только наличие ключа, но и ожидаемую структуру;
— на границе домена приводите типы явно, а не через неявные касты.
Отдельная ловушка — array functions и сравнения. В PHP "0", 0, false и "" легко начинают жить одной жизнью, если использовать loose comparison. Для фильтров, флагов и идентификаторов это источник тихих ошибок, которые тесты часто не ловят с первого прохода.
Если нужно одно правило на каждый проект: данные можно принять как угодно, но внутрь домена они должны попасть уже нормализованными. Тогда PHP перестаёт удивлять в проде и начинает вести себя предсказуемо.
В реальных проектах большинство багов в PHP сидят в одном из трёх мест: вход пришёл не того типа, строка внезапно пустая, массив оказался ассоциативным вместо списка. Самый дешёвый способ ловить это — не доверять данным из request, env, queue payload и внешних API по умолчанию.
Минимальный чек-лист:
— включайте strict_types там, где это не ломает легаси;
— валидируйте форму данных до бизнес-логики;
— не смешивайте “null значит нет значения” и “пустая строка значит пусто”;
— для массивов проверяйте не только наличие ключа, но и ожидаемую структуру;
— на границе домена приводите типы явно, а не через неявные касты.
Отдельная ловушка — array functions и сравнения. В PHP "0", 0, false и "" легко начинают жить одной жизнью, если использовать loose comparison. Для фильтров, флагов и идентификаторов это источник тихих ошибок, которые тесты часто не ловят с первого прохода.
Если нужно одно правило на каждый проект: данные можно принять как угодно, но внутрь домена они должны попасть уже нормализованными. Тогда PHP перестаёт удивлять в проде и начинает вести себя предсказуемо.
This media is not supported in your browser
VIEW IN TELEGRAM
Google выпустил Android 17
Android получил встроенную Gemini с функциями автоматизации задач, конспектирования браузера и редактирования медиа. Обновление принесло новый интерфейс Bubble, двухкамерную запись и игровой режим для складных телефонов. Критический момент: Gemini Intelligence требует Gemini Nano v3 и минимум 12 ГБ RAM, что ограничивает аудиторию премиум-девайсов. Это создаёт потенциал для таргетинга криптооффера на узкий сегмент владельцев флагманов, готовых пл…
➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-android-17
🧠 Ещё больше инсайтов → в канале AFF.top
Android получил встроенную Gemini с функциями автоматизации задач, конспектирования браузера и редактирования медиа. Обновление принесло новый интерфейс Bubble, двухкамерную запись и игровой режим для складных телефонов. Критический момент: Gemini Intelligence требует Gemini Nano v3 и минимум 12 ГБ RAM, что ограничивает аудиторию премиум-девайсов. Это создаёт потенциал для таргетинга криптооффера на узкий сегмент владельцев флагманов, готовых пл…
➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-android-17
🧠 Ещё больше инсайтов → в канале AFF.top
Laravel Octane ускоряет приложение, но ломает привычки обычного PHP-FPM
Octane держит приложение в памяти, поэтому код перестаёт жить по модели «запрос пришёл — процесс умер». Это сразу бьёт по местам, где раньше можно было безнаказанно создавать singleton с состоянием, кешировать что угодно в свойствах и не думать о сбросе между запросами.
Первое правило: всё, что хранит данные запроса, пользователя или локальные вычисления, не должно жить в статике и в глобальных синглтонах. Иначе один запрос тихо протечёт в следующий. Особенно это заметно в сервисах, логгерах, контекстах авторизации и кастомных фасадах.
Второе: любые подключения и ресурсы нужно проверять на повторное использование. PDO, curl, файловые дескрипторы, клиенты к внешним API — если они не рассчитаны на долгую жизнь, получите странные зависания и утечки памяти. В Octane полезно смотреть не только на скорость ответа, но и на рост памяти под нагрузкой.
Третье: очистка состояния после запроса — не формальность. Если пакет или ваш код меняют контейнер, кэшируют конфиг в рантайме или держат локальный кеш в property, нужен явный reset-хук. Для самописных компонентов это обычно дешевле, чем потом ловить «призрачные» баги.
Хорошая привычка: тестируйте приложение под несколькими последовательными запросами в одном процессе. Если поведение меняется от запроса к запросу — это не оптимизация, а утечка состояния.
Octane ускоряет только те проекты, где код готов к долгой жизни процесса. Сначала уберите состояние из мест, где ему не место, и лишь потом включайте ускорение.
Octane держит приложение в памяти, поэтому код перестаёт жить по модели «запрос пришёл — процесс умер». Это сразу бьёт по местам, где раньше можно было безнаказанно создавать singleton с состоянием, кешировать что угодно в свойствах и не думать о сбросе между запросами.
Первое правило: всё, что хранит данные запроса, пользователя или локальные вычисления, не должно жить в статике и в глобальных синглтонах. Иначе один запрос тихо протечёт в следующий. Особенно это заметно в сервисах, логгерах, контекстах авторизации и кастомных фасадах.
Второе: любые подключения и ресурсы нужно проверять на повторное использование. PDO, curl, файловые дескрипторы, клиенты к внешним API — если они не рассчитаны на долгую жизнь, получите странные зависания и утечки памяти. В Octane полезно смотреть не только на скорость ответа, но и на рост памяти под нагрузкой.
Третье: очистка состояния после запроса — не формальность. Если пакет или ваш код меняют контейнер, кэшируют конфиг в рантайме или держат локальный кеш в property, нужен явный reset-хук. Для самописных компонентов это обычно дешевле, чем потом ловить «призрачные» баги.
Хорошая привычка: тестируйте приложение под несколькими последовательными запросами в одном процессе. Если поведение меняется от запроса к запросу — это не оптимизация, а утечка состояния.
Octane ускоряет только те проекты, где код готов к долгой жизни процесса. Сначала уберите состояние из мест, где ему не место, и лишь потом включайте ускорение.
PHP-проект ломается не в коде, а в мелочах, которые не проверяют в CI
Чаще всего проблемы всплывают не в контроллерах, а в границах проекта: автозагрузка, конфиги, env, кэш, права на файлы. Если это не зафиксировано в чек-листе, баги уезжают на прод и выглядят как «магия».
Держите базовый набор проверок:
— composer install без сюрпризов: lock-файл в репозитории, vendor не коммитят
— phpunit гоняет не только happy path, но и пустые входы, исключения, граничные значения
— .env не является единственным источником истины: важные настройки должны быть валидированы
— кэш конфигов и роутов очищается и собирается в том же порядке, что и на сервере
Ещё одна типовая дыра — несовместимость пакетов. Один composer update может незаметно сломать события, middleware или сериализацию. Поэтому перед мерджем полезно смотреть дерево зависимостей и проверять, нет ли пакета, который тянет за собой неожиданный контракт. Это особенно важно в Laravel-сборках с кучей мелких расширений.
Если нужен простой фильтр качества, ищите не «красивый код», а повторяемость: проект должен подниматься с нуля, тесты — проходить без ручных правок, а окружение — собираться одинаково на любой машине.
Чаще всего проблемы всплывают не в контроллерах, а в границах проекта: автозагрузка, конфиги, env, кэш, права на файлы. Если это не зафиксировано в чек-листе, баги уезжают на прод и выглядят как «магия».
Держите базовый набор проверок:
— composer install без сюрпризов: lock-файл в репозитории, vendor не коммитят
— phpunit гоняет не только happy path, но и пустые входы, исключения, граничные значения
— .env не является единственным источником истины: важные настройки должны быть валидированы
— кэш конфигов и роутов очищается и собирается в том же порядке, что и на сервере
Ещё одна типовая дыра — несовместимость пакетов. Один composer update может незаметно сломать события, middleware или сериализацию. Поэтому перед мерджем полезно смотреть дерево зависимостей и проверять, нет ли пакета, который тянет за собой неожиданный контракт. Это особенно важно в Laravel-сборках с кучей мелких расширений.
Если нужен простой фильтр качества, ищите не «красивый код», а повторяемость: проект должен подниматься с нуля, тесты — проходить без ручных правок, а окружение — собираться одинаково на любой машине.
Laravel ломается не на роуте, а на небрежной сборке проекта
За неделю в репах чаще всего всплывает не «сложный баг», а набор мелких ошибок, которые потом выстреливают в проде.
— Смешивают бизнес-логику с контроллерами: в итоге тестировать нечего, а правки цепляют лишние места.
— Не разделяют
— Пишут запросы к БД прямо в шаблонах и middleware: это быстро только до первого рефакторинга.
— Игнорируют очереди для тяжёлых задач: письма, вебхуки, генерация файлов и синхронизации начинают тормозить пользовательский поток.
— Не фиксируют контракты для внешних интеграций: меняется формат ответа — и ломается половина сценариев.
Есть наблюдение которое стоит проверить: если после изменения одной фичи приходится править три слоя приложения, архитектура уже просит разделения.
Для Laravel это обычно решается просто:
• тонкий контроллер;
• явный сервис или action;
• отдельные DTO/requests;
• очереди для асинхронщины;
• тест на критичный сценарий, а не на «всё подряд».
Если проект начал «пахнуть» комбайном, не лечите его новым пакетом. Сначала разрежьте ответственность по слоям — это дешевле, чем потом чинить каскадный отказ.
За неделю в репах чаще всего всплывает не «сложный баг», а набор мелких ошибок, которые потом выстреливают в проде.
— Смешивают бизнес-логику с контроллерами: в итоге тестировать нечего, а правки цепляют лишние места.
— Не разделяют
FormRequest, сервисы и модели: валидация, трансформация и сохранение живут в одном классе.— Пишут запросы к БД прямо в шаблонах и middleware: это быстро только до первого рефакторинга.
— Игнорируют очереди для тяжёлых задач: письма, вебхуки, генерация файлов и синхронизации начинают тормозить пользовательский поток.
— Не фиксируют контракты для внешних интеграций: меняется формат ответа — и ломается половина сценариев.
Есть наблюдение которое стоит проверить: если после изменения одной фичи приходится править три слоя приложения, архитектура уже просит разделения.
Для Laravel это обычно решается просто:
• тонкий контроллер;
• явный сервис или action;
• отдельные DTO/requests;
• очереди для асинхронщины;
• тест на критичный сценарий, а не на «всё подряд».
Если проект начал «пахнуть» комбайном, не лечите его новым пакетом. Сначала разрежьте ответственность по слоям — это дешевле, чем потом чинить каскадный отказ.
This media is not supported in your browser
VIEW IN TELEGRAM
Армения заблокирует онлайн-казино для получающих пособия
Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 20% дохода, обязала казино добавить кнопку самозапрета. Сайты, не подчинившиеся требованиям, будут заблокированы — технология реализации неясна. Проблемы с платёжками неизбежны. Криптоказино, вероятно, останутся без контроля, что открывает новый канал для залива трафика.
➡️ Читайте на сайте: https://aff.top/blog/armeniia-zablokiruet-onlain-kazino-dlia-poluchaiuschikh-posobiia
🧠 Ещё больше инсайтов → в канале AFF.top
Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 20% дохода, обязала казино добавить кнопку самозапрета. Сайты, не подчинившиеся требованиям, будут заблокированы — технология реализации неясна. Проблемы с платёжками неизбежны. Криптоказино, вероятно, останутся без контроля, что открывает новый канал для залива трафика.
➡️ Читайте на сайте: https://aff.top/blog/armeniia-zablokiruet-onlain-kazino-dlia-poluchaiuschikh-posobiia
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В DeepSeek добавили распознавание изображений
DeepSeek запустил бета-версию распознавания изображений — функция доступна бесплатно прямо в чате. Работает нестабильно, но для базовых задач подходит: например, проверить, есть ли на креативе узнаваемая знаменитость в нужном гео. Платная подписка не нужна.
➡️ Читайте на сайте: https://aff.top/blog/v-deepseek-dobavili-raspoznavanie-izobrazhenii
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek запустил бета-версию распознавания изображений — функция доступна бесплатно прямо в чате. Работает нестабильно, но для базовых задач подходит: например, проверить, есть ли на креативе узнаваемая знаменитость в нужном гео. Платная подписка не нужна.
➡️ Читайте на сайте: https://aff.top/blog/v-deepseek-dobavili-raspoznavanie-izobrazhenii
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
📡 Запустили AFF.TOP — медиа про арбитраж, ИИ и вайб-кодинг
Разбираем новости из мира ИИ, тренды вайб-кодинга, инсайды индустрии арбитража — без воды и продаж курсов.
👉 Подписаться на канал AFF.TOP
Разбираем новости из мира ИИ, тренды вайб-кодинга, инсайды индустрии арбитража — без воды и продаж курсов.
👉 Подписаться на канал AFF.TOP
Почему PHPUnit ломает доверие к тестам чаще, чем сам код
Есть наблюдение которое стоит проверить: тесты начинают врать не из-за фреймворка, а из-за привычек команды.
— Сначала ловят только happy path и забывают про границы: пустые значения, null, дубли, неверные статусы.
— Потом прячут логику в моки: тест проходит, а реальная интеграция с сервисом уже рассыпается.
— Затем делают один большой тест на всё: он медленный, хрупкий и не показывает, где именно сломалось.
Рабочий подход проще: тестируй поведение, а не внутренности; выноси в отдельные кейсы правила валидации, авторизации и расчётов; моки используй только там, где внешний мир реально мешает. Если тест зависит от случайности, времени или порядка выполнения — он уже кандидат на переписывание 🧪
Ещё один фильтр качества: тест должен отвечать на вопрос «что сломается для пользователя», а не «какой метод вызвался первым». Когда это правило нарушают, тестовый набор разрастается, но уверенности не добавляет.
Сначала очисти тесты от лишних зависимостей, потом добейся коротких и именованных сценариев — именно они переживают и рефакторинг, и смену команды.
Есть наблюдение которое стоит проверить: тесты начинают врать не из-за фреймворка, а из-за привычек команды.
— Сначала ловят только happy path и забывают про границы: пустые значения, null, дубли, неверные статусы.
— Потом прячут логику в моки: тест проходит, а реальная интеграция с сервисом уже рассыпается.
— Затем делают один большой тест на всё: он медленный, хрупкий и не показывает, где именно сломалось.
Рабочий подход проще: тестируй поведение, а не внутренности; выноси в отдельные кейсы правила валидации, авторизации и расчётов; моки используй только там, где внешний мир реально мешает. Если тест зависит от случайности, времени или порядка выполнения — он уже кандидат на переписывание 🧪
Ещё один фильтр качества: тест должен отвечать на вопрос «что сломается для пользователя», а не «какой метод вызвался первым». Когда это правило нарушают, тестовый набор разрастается, но уверенности не добавляет.
Сначала очисти тесты от лишних зависимостей, потом добейся коротких и именованных сценариев — именно они переживают и рефакторинг, и смену команды.
7 признаков, что PHP-пакет лучше не тянуть в прод, даже если он «популярен»
Есть наблюдение которое стоит проверить: у многих инцидентов причина не в Laravel или Symfony, а в одном сомнительном пакете из Composer.
— Нет тестов под свои кейсы. Если пакет покрывает только happy path, вы оплачиваете будущий баг своим продом.
— Слишком много магии. Хелперы, глобальные состояния, автоконфиг «сам всё подхватит» — потом сложно понять, где сломалось.
— Нет явного контракта API. Если названия методов, типы и поведение читаются только через исходники, интеграция будет хрупкой.
— Репозиторий живёт, но не дышит: issue закрываются без объяснений, PR висят, README обещает больше, чем код.
— Пакет тянет лишние зависимости. Для трекера, CRM или арбитражной обвязки это быстро превращается в конфликт версий и лишний вес.
— Нет стратегии совместимости. Если автор меняет поведение без миграций и deprecation-цикла, обновление всегда лотерея.
Перед установкой проверьте три вещи: лицензия, качество тестов, состав зависимостей. И ещё одно: можно ли заменить пакет тонким адаптером вокруг своего кода.
Если пакет не объясняет свои границы — лучше не делать его центром архитектуры.
Есть наблюдение которое стоит проверить: у многих инцидентов причина не в Laravel или Symfony, а в одном сомнительном пакете из Composer.
— Нет тестов под свои кейсы. Если пакет покрывает только happy path, вы оплачиваете будущий баг своим продом.
— Слишком много магии. Хелперы, глобальные состояния, автоконфиг «сам всё подхватит» — потом сложно понять, где сломалось.
— Нет явного контракта API. Если названия методов, типы и поведение читаются только через исходники, интеграция будет хрупкой.
— Репозиторий живёт, но не дышит: issue закрываются без объяснений, PR висят, README обещает больше, чем код.
— Пакет тянет лишние зависимости. Для трекера, CRM или арбитражной обвязки это быстро превращается в конфликт версий и лишний вес.
— Нет стратегии совместимости. Если автор меняет поведение без миграций и deprecation-цикла, обновление всегда лотерея.
Перед установкой проверьте три вещи: лицензия, качество тестов, состав зависимостей. И ещё одно: можно ли заменить пакет тонким адаптером вокруг своего кода.
Если пакет не объясняет свои границы — лучше не делать его центром архитектуры.
This media is not supported in your browser
VIEW IN TELEGRAM
Google заставляет махать руками перед камерой
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
Composer ломается не на install, а на мелочах вокруг него — вот чек-лист
Если в проекте Composer ведёт себя «странно», проверь базу: • composer.json без лишних platform-ограничений • composer.lock под версионным контролем • vendor не коммитится • в CI и локально один и тот же PHP и ext-* набор.
Дальше идут типовые ошибки: • ставят пакеты через require без понимания конфликтов semver • забывают, что scripts могут запускать код • игнорируют autoload-dev и получают мусор в тестах • тащат в проект deprecated-пакеты, а потом лечат симптомы, а не причину. Здесь помогает не магия, а дисциплина зависимостей.
Отдельно проверь автозагрузку: PSR-4 должен совпадать с реальными namespace и путями, а classmap — не разрастаться без нужды. Если сборка тормозит, смотрят на количество пакетов, лишние post-install скрипты и то, не тянет ли один «удобный» пакет половину экосистемы.
Вывод простой: Composer — это не менеджер пакетов, а контракт между кодом, окружением и CI. Чем раньше вы фиксируете правила в composer.json и lock-файле, тем меньше сюрпризов в проде.
Если в проекте Composer ведёт себя «странно», проверь базу: • composer.json без лишних platform-ограничений • composer.lock под версионным контролем • vendor не коммитится • в CI и локально один и тот же PHP и ext-* набор.
Дальше идут типовые ошибки: • ставят пакеты через require без понимания конфликтов semver • забывают, что scripts могут запускать код • игнорируют autoload-dev и получают мусор в тестах • тащат в проект deprecated-пакеты, а потом лечат симптомы, а не причину. Здесь помогает не магия, а дисциплина зависимостей.
Отдельно проверь автозагрузку: PSR-4 должен совпадать с реальными namespace и путями, а classmap — не разрастаться без нужды. Если сборка тормозит, смотрят на количество пакетов, лишние post-install скрипты и то, не тянет ли один «удобный» пакет половину экосистемы.
Вывод простой: Composer — это не менеджер пакетов, а контракт между кодом, окружением и CI. Чем раньше вы фиксируете правила в composer.json и lock-файле, тем меньше сюрпризов в проде.