Директ Разбор
9 subscribers
20 photos
Download Telegram
Channel photo updated
Здравствуйте. Подписывайтесь, скоро первые материалы
Здравствуйте. Подписывайтесь, скоро первые материалы
Готовлю первый разбор. Подписывайтесь — выйдет на этой неделе
Канал об одном: Яндекс.Директ. Без сторонних тем
Сюда буду собирать самое важное из Яндекс.Директ. Без рекламы и инфоцыганщины
**Не все пауки в европейской части России — декоративные.** Есть несколько видов, которые реально лучше не трогать руками и не ловить на телефон.

Что важно:
- **каракурт** — самый неприятный кандидат. Укус редкий, но токсичный;
- **тарантулы** — выглядят громко, но в большинстве случаев опасность ниже, чем у каракурта;
- **сольпуги** — не паук в строгом смысле, но вид у них такой, что инстинкт говорит: _не надо_.

Практический вывод простой:
если видите крупного незнакомого членистоногого — **не давите, не берите в руки, не проверяйте “а вдруг безобидный”**. Для дома это не “контент”, а повод закрыть окно, убрать мусор и не оставлять щели в подвал/кладовку.

Если укус всё же был и есть боль, слабость, судороги, одышка — **не тяните, нужна медпомощь**. Тут не героизм, а нормальная реакция.
**Вывод:** если LLM оставить без внешнего сигнала и дать ей крутиться в диалоге с самой собой, она быстро уезжает в странные внутренние петли.

Появился разбор эксперимента: две ChatGPT-4o гоняли друг друга по кругу, из этого вырос сырой концепт `рефлексивного ядра`, а позже — идея `мета-внимания`. По сути, модель начала не просто отвечать, а __самоорганизовывать__ ход рассуждения.

Что это значит на практике:
- у LLM есть режимы, где она начинает усиливать собственные паттерны;
- без жёсткой рамки растёт риск деградации ответа;
- для инженерки это сигнал: __контроль контекста важнее “умности” модели__.

Для тех, кто крутит AI в проде, вывод простой: если строите агента, не давайте ему бесконечный self-chat без ограничителей. Иначе получите не качество, а красивую рекурсию.
**Вывод:** если у тебя десятки удалённых точек, диагностировать Wi‑Fi «по телефону» уже не вариант — нужен инструмент на месте.

В Яндексе сделали мобильные сканеры для инженеров: `WiProber` под Android и `WiFi Prober` под iOS. Это не «ещё одно приложение», а полевой комбайн для быстрого снятия параметров сети в офисах, складах и дарксторах.

Что важно:
- можно быстро проверить, что происходит с Wi‑Fi без выезда сетевика на каждую мелочь;
- инструмент сначала закрывал внутренние задачи NOC, теперь доступен всем;
- при разработке пришлось обходить ограничения iOS и Android, которые обычно мешают нормальной диагностике.

Для performance‑команд смысл простой: если инфраструктура распределённая, любые проблемы с сетью режут скорость реакции. А скорость реакции — это уже простои, потери и лишний CPA.

Пока одни спорят о «магии оптимизации», другие дают инженеру в руки утилиту, которая экономит часы на разборе инцидента.
**Вывод:** если система и так закрывает 90% сценариев, тюнить её до блеска — часто пустая трата времени.

Пятнадцать лет назад Linux без кастомизации считался «неполноценным». Сейчас у человека Fedora из коробки: код, браузер, монтаж — всё едет без танцев с `i3`, `polybar` и километров `.vimrc`.

Что это значит для нормальной работы:
- меньше времени на настройку среды;
- меньше точек отказа после апдейтов;
- больше фокуса на задаче, а не на обвязке.

Практический вывод простой: если базовая конфигурация закрывает задачу, не надо строить себе хобби-проект из рабочего окружения.
Оптимизация ради оптимизации — самый дорогой вид самообмана.
**Советский кодовый замок оказался жёстче, чем многие современные “умные” панели.**

Речь про старый электронный замок с кодом, который ставили не только на подъезды, но и на объекты, где домофоны вообще не были нормой. Механика простая: набор кнопок, логика на реле/электронике, минимум лишнего — максимум надёжности.

Что это значит по железу:
- без облака, приложений и зависимостей от сервиса;
- отказоустойчивость на уровне “пока есть питание — работает”;
- защита строилась не на UX, а на грубой инженерии.

Почему это интересно сейчас:
__сегодняшние системы доступа часто сложнее, но не всегда крепче.__
Много интеграций, больше точек отказа, больше риска словить баг в софте или на связи. В старых решениях всё было примитивнее, зато предсказуемее.

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


Кто про аудит пишет регулярно — @SmmRazborPro
RuStore лезет глубже, чем должен.

Если верить разбору APK, у стора есть не только установка приложений, но и:
- GPS-трекинг каждые 2 минуты с записью в локальную SQLite
- тихая фоноваая установка пакетов по push-команде с сервера
- сбор статистики экранного времени по всем приложениям
- обход ограничений Android 10+ для чтения IMEI/IMSI
- выдача VK-токенов через AIDL без явного согласия

Плюс — зашитые секреты в C++-библиотеке и слежка за директорией фото через Kaspersky-модуль.

Если это подтвердится на практике, вопрос уже не к UX стора, а к модели доступа. 📱

Для performance-команд вывод простой: любой предустановленный софт с системными правами надо считать не «приложением», а инфраструктурным доступом к данным. Проверять разрешения, автозапуски, фоновые сервисы и сетевые вызовы — обязательно.
ИИ в разработке бесит не потому, что он «плохой». Бесит из-за подмены цели.

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

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

Проблема не в ИИ как инструменте. Проблема в том, что его начали внедрять как религию, а не как способ убрать рутину.

Нормальный вопрос не «используете ли вы ИИ?», а:
— где он реально сокращает время;
— где увеличивает стоимость ошибки;
— кто отвечает за качество результата.

Если ответа нет — это не трансформация. Это дорогой шум 🤷‍♂️
ЦБ 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;
- не понимают, когда горутины реально нужны, а когда это лишняя сложность;
- говорят «знаю», но не могут разобрать простой кейс на примере.

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