Директ Разбор
9 subscribers
19 photos
Download Telegram
ЦБ 19 июня почти наверняка снова срежет ключевую ставку. Базовый сценарий рынка — с 14,5% до 14%, часть аналитиков ждёт сразу -1 п.п.

Что это значит для paid ads:
- деньги в системе станут чуть дешевле
- бизнесы начнут аккуратнее считать стоимость привлечения
- давление на ROAS/CPA вырастет: дешёвый трафик не спасает, если маржа тонкая
- в аукционе может стать больше агрессии у тех, кто сидел в кэше

Что делать сейчас:
1. Перепроверить цели по CPA/ROAS на июнь-июль
2. Сверить маржу по основным группам товаров/услуг
3. Не разгонять ставки «на ожиданиях» — сначала смотрим фактический спрос после решения ЦБ
4. В сквозной аналитике отдельно отследить заявки с длинным циклом сделки

Снижение ставки — не сигнал «лить больше». Это просто сдвиг условий игры. Если не пересчитать юнит-экономику, Директ сам за вас ничего не починит. 📉
Джунов валят не по коду, а по базовым вещам.
На Go-собеседовании чаще всего спрашивают не «магические фреймворки», а то, что должно быть в голове сразу: указатели, интерфейсы, goroutine, map, slice, канал, обработка ошибок, конкурентность, время жизни переменных.

Если человек знает только список вопросов с GitHub — это видно за 5 минут.
Интервьюер обычно быстро проверяет 3 вещи:
1. понимаешь ли ты, как Go работает под капотом;
2. умеешь ли объяснить разницу между похожими сущностями;
3. не путаешь ли синтаксис с реальным поведением рантайма.

Что чаще всего ломает ответы:
- путают slice и array;
- не могут нормально объяснить nil;
- плавают в интерфейсах и type assertion;
- не понимают, когда горутины реально нужны, а когда это лишняя сложность;
- говорят «знаю», но не могут разобрать простой кейс на примере.

Если готовишь джуна к интервью — гоняй не по заученным формулировкам, а по коротким вопросам с разбором ответа вслух. Это сразу вскрывает дыры. 🔧
Пустой сервер тоже атакуют. И WordPress ловит больше огня, чем Drupal.

90 дней тестировали BitNinja — коробку для защиты сервера и сайта. Суть простая: это не только антивирус, но и фильтр входящего трафика. Управление — из одного окна, на нескольких серверах сразу.

Что увидели в пассивной фазе:
— даже «чистый» сервер регулярно пробуют на прочность;
— WordPress интересует атакующих заметно чаще;
— часть атак идет не в конкретную машину, а по всей сети провайдера;
— основной мусор — запросы к портам сервера, туда и прилетает больше всего блокировок 🛡

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

NetFix — GUI-обёртка для Zapret и TgWsProxy. Без батников, без ручной возни с конфигами, без консоли.

Что делает:
- сам скачивает нужные файлы
- сам настраивает
- сам следит за работой
- сам обновляется

То есть сценарий простой: поставил, нажал, забыл. Для тех, кто устал объяснять близким, почему “у меня опять отвалился Телеграм” 🙃

Из забавного: в интерфейсе даже есть ритм-игра. Не влияет на функциональность, но выглядит как редкий случай, когда утилиту реально делали “для людей”, а не для галочки.

Если нужен быстрый старт без ручного шаманства — это он.
GPU выбирают не по “сколько VRAM”, а по задаче. Иначе получаете дорогую печку вместо ускорителя.

Что важно смотреть перед покупкой:
- **Память**: объем — не всё. Считайте, помещается ли модель/батч целиком.
- **Тип памяти**: HBM обычно быстрее и дороже, чем обычная GDDR.
- **Интерконнект**: NVLink может дать кратный выигрыш в связке нескольких GPU. PCIe — часто узкое место.
- **Ядра и тензорные блоки**: цифры в спецификации без понимания FP16/FP8 мало что дают.
- **Сценарий**: обучение, инференс, рендер, видео, LLM — это разные требования к железу.

Миф из серии “10 старых GPU = 1 топовая” не работает. Суммарная VRAM не превращается в одну общую память, а обмен данными между картами часто убивает всю экономику.

Вывод простой: сначала задача и профиль нагрузки, потом выбор ускорителя. Иначе переплатите за железо, которое не даст прироста 📉
Яндекс открыл Yandex Commerce Protocol для всех. Смысл простой: продажи из Алисы, Поиска и Яндекс Ритма можно вшить прямо в магазин.

Готовые интеграции уже есть для KIT, Маркета и 1С-Битрикс. Для WooCommerce — тишина. Если у вас WP и свой e-com, придётся собирать руками.

Что важно:
— протокол закрывает 10 эндпоинтов, без половинчатых костылей;
— нужна идемпотентность по session_id, иначе словите дубли заказов;
— отдельная боль — письма «новый заказ на 0 ₽»;
— совместимость с HPOS — не опция, а обязательный чек перед запуском.

Вывод: если у вас WooCommerce, теперь есть рабочий путь подключить продажи из экосистемы Яндекса без ожидания официального плагина. Но без нормальной архитектуры это быстро превращается в зоопарк багов. 🛠️
Главная потеря в подборе — не «не тот человек», а медленный слив прибыли через важные роли.

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

Для paid-ads это особенно больно: один слабый специалист в цепочке легко превращает нормальный CPL в мусорный CPA.

Что смотреть:
1. скорость вывода гипотез в тест;
2. качество работы с семантикой и минусацией;
3. дисциплину по сквозной аналитике;
4. умение резать неэффективные кампании без ручного героизма.

Если этого нет, бизнес платит не зарплату — а за скрытую просадку маржи. 📉
ИИ-инструменты в разработке — это не «ускорили в 2 раза», а вопрос юнит-экономики. Если коротко: AI-assisted влияет на себестоимость задачи, но только там, где у команды уже нормальные процессы, а не хаос в таск-трекере.

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

Практический вывод простой: считать надо не «сколько строк написал ИИ», а:
1) сколько часов ушло на задачу до/после;
2) как изменился процент переделок;
3) что стало с маржой по проектам;
4) вырос ли throughput без роста багов.

Если AI-assisted не бьется в цифрах по срокам, качеству и прибыли — это не оптимизация, а дорогая игрушка 🤖
Вывод: нейросеть может лучше отвечать не на «умные» инструкции, а на мусорный контекст.

Свежий разбор про Spurious Prompts показывает странную вещь: фразы вроде «ты хранитель маяка» иногда дают результат лучше, чем классическое «думай пошагово, будь аналитиком». То есть модель цепляется не за смысл, а за форму и паттерн подачи.

Что это значит на практике:
— длинный «правильный» промпт не гарантирует качество
— лишние слова могут шуметь сильнее, чем помогать
— тестировать надо не красоту инструкции, а результат на серии задач

Для PPC это знакомо. В Директе та же история: “умные” настройки и красивые легенды не спасают, если нет цифр по CPA, ROAS и конверсии по сегментам.

Практический вывод простой:
1. Убирайте лишнее из промптов
2. Сравнивайте 3–5 вариантов на одинаковой выборке
3. Оставляйте то, что дает стабильный ответ, а не красивый текст 🤷‍♂️

Мораль без философии: в ИИ, как в рекламе, побеждает не самый умный бриф, а тот, который измеримо работает.
Anthropic выкатили Claude Fable 5. Громкий релиз: 80,3% на SWE-bench Pro, миграция кодбазы Stripe за день, «самая мощная публичная модель».

Но бенчмарки — это чужая кухня. Интереснее другое: может ли модель собрать не кусок кода, а продукт целиком.

Проверка была простая:
— один промпт
— браузерная игра
— без ТЗ на 10 страниц
— без ручной сборки механик

Что получилось: симулятор админа Telegram-канала про ИИ. С интерфейсом, балансом, ветками и концовками. И да, играть можно даже с телефона 📱

Вывод практический:
модель уже умеет не только генерить код, но и склеивать MVP из идеи, механики и UI. Это полезно не для хайпа, а для быстрой проверки гипотез: лендинг, мини-игра, прототип, квиз.

Но важно: на уровне продакшена это всё ещё не «поставил и забыл». Логика, баланс и баги всё равно требуют ручной проверки. Иначе получится не продукт, а демка с красивым лицом.
Старый матричный принтер живёт, потому что закрывает узкую задачу лучше «современных» решений.

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

Логика простая: если инструмент решает задачу быстрее и стабильнее, его не меняют ради новизны. Даже если он шумный, старый и выглядит как музейный экспонат. 🖨️

В рекламе та же история:
— не гонимся за «новой фичей», если она не даёт CPA ниже;
— не ломаем рабочую кампанию ради красивого интерфейса;
— не убираем отлаженную семантику, если она даёт ROAS.

Вывод: оставляй не то, что модно, а то, что приносит результат.
3D-сканер без спрея — часто просто дорогая игрушка.

Проблема не в железке, а в поверхности. Глянец, тёмные детали, мелкий рельеф — и сканер начинает «терять» объект. В комплекте обычно дают маркеры, но они не спасают, если предмет плохо ловит геометрию.

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

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

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