Купил электронный ценник за 250 ₽ и получил не «дешёвый E-INK», а полноценный reverse engineering-пакет: коррозия, нестандартный протокол, новый nRF52832 и ноль документации.

Что внутри по факту:
— плата с BLE-чипом nRF52832
— экран на E-INK
— прошивка, которая живёт в своей маленькой вселенной
— связь, которую нельзя «просто посмотреть в мануале», потому что мануала нет

Дальше начинается нормальная инженерка:
1) вскрыть железо
2) понять, где питание, где UART/SWD, где память
3) залезть в RAM через GDB
4) не спалить экран и плату по дороге
5) довести дисплей до жизни на Zephyr RTOS

Самое вкусное — это не «завёл экран», а то, что после пары убитых ценников появился рабочий стек. И да, в конце вместо демо на hello world автор выкатил Мандельброта. Потому что если уже ковырять ритейл-железо, то хотя бы с пользой 😈

Один месяц согласований = +50% к стоимости проекта.

Не магия. Просто классическая инженерная математика: чем позже фиксируешь архитектуру, тем дороже любая правка.

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

Где вырос чек:
1. Повторный разбор уже обсуждённых решений.
2. Перепланирование задач и сдвиг в календаре.
3. Переключение людей с новой работы на возврат к старой.
4. Риск-буфер, который подрядчик закладывает на «а вдруг ещё допилят».

Вывод простой: стоимость проекта растёт не только от кода. Она растёт от пауз между согласованием и реализацией. ⏱️

Если решение затрагивает ПДн, интеграции или нестандартную логику — фиксируйте требования до старта разработки. Иначе экономия на этапе обсуждения превращается в переплату на этапе сборки.

Потребность в SEO — это не «давайте ускорим сайт» и не «сделаем новый sitemap». Это ответ на вопрос: что именно мешает бизнесу забирать органику сейчас.

Если смотреть по-взрослому, у проблемы есть 3 слоя:

1. Симптом
«Падает трафик», «не индексируются страницы», «JS-рендер ломает выдачу».

2. Промежуточное решение
«Пересоберём robots.txt», «добавим prerender», «обновим sitemap.xml».

3. Истинная потребность
«Поисковик не видит и не переобходит нужные URL в пределах crawl budget»
или
«страницы попадают в индекс, но не ранжируются из-за плохой структуры и дублей».

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

Правильный вопрос для technical SEO:
что надо изменить в системе, чтобы бот:
- дошёл до нужных URL,
- не тратил бюджет на мусор,
- получил корректный HTML/рендер,
- и отдал страницу в индекс без потерь?

Пока нет ответа на этот вопрос, любые правки — это не стратегия, а косметика. Проверять надо на логах, coverage, server response и фактическом поведении бота. ✅

Поколение «Approve» — это не про AI, а про узкое место в delivery.

Команда действительно начала писать код быстрее. Но фича не стала выходить быстрее. Почему? Потому что bottleneck сместился в review, интеграцию и проверку. Код-генерация ускорилась, а вот стоимость ошибки выросла: больше диффов, больше скрытой логики, больше ручной валидации.

Что это значит на практике:
- 10 минут на генерацию → 2 часа на ревью
- «рабочий» код без тестов = долг по качеству
- ускорение разработки без изменения процесса просто раздувает очередь

Мы переписали проект не потому, что старый «не работал». Он работал. Но работал на старом throughput. Новый режим требует другой архитектуры процесса: меньше hero-coding, больше контрактов, тестов, строгих чекпойнтов 🧪

AI в разработке — это не ускоритель на магистрали. Это турбина, которая легко сжигает слабое шасси. Если approve-цикл не пересобран, выигрыш в скорости превращается в рост риска.

WordPress на OpenLiteSpeed vs классический LEMP — без маркетинга, только метрики.

Смотрели не “ощущения”, а:
— RPS
— latency
— TTFB
— CPU / RAM
— поведение под нагрузкой до 500 одновременных пользователей

Что важно для SEO-инфры:
1. TTFB — это не абстрактная “скорость”, а первая точка, где сервер начинает влиять на crawl budget и UX.
2. Под нагрузкой разница между стеком видна не в среднем значении, а в хвостах: p95/p99 latency.
3. Если сервер упирается в CPU или память, WordPress начинает деградировать раньше, чем это видно в обычном бенчмарке.

Практический вывод: сравнивать нужно не “какой стек быстрее”, а где он держит стабильный TTFB под реальной нагрузкой и как ведёт себя при всплесках трафика. Иначе цифры красивые, а на проде — просадка в ответах и лишняя нагрузка на краулер. 🔧

1. Выкатить ни какую он-лайн конфу я естесвенно не выкатил, потерпите

2. После прошлого видео (тык) мой канал теперь имеет юзер @PO_YICA_BRAL

3. Держите вечернее видео, я нажрусь и спать

Чото надо ещё сказать? Ну, можно лишь добавить Настя #MelBet верни деньги, не играй с огнём, со мной лучше не ссориться. Спасибо.

P.S. Бабка-то, похоже, не своей..... см. видео!

С уважением, Иванов Е.Ю!

🎁 РОЗЫГРЫШ $2000 ОТ SERG ACCS

🥇 1 место — $1000
🥈 2 место — $700
🥉 3 место — $300

Как участвовать:
1️⃣ Подпишитесь на канал
2️⃣ Нажмите «✅ Участвую»
3️⃣ Получите 1 стартовый билет

Больше билетов:
🛒 Покупки — минимум 1 билет, далее +1 за каждые полные $50 реальной оплаты. Максимум — 50.
👥 Рефералы — +5 за первую подходящую покупку друга и +1 за каждые накопленные $100 его покупок. Максимум — 50.

Общий максимум — 100 билетов.
Чем больше билетов, тем выше шанс. Даже 1 билет участвует.

Призы начислим на баланс в боте SERG ACCS.

Итоги 15.09. Всем удачи! 🔥

Формы — это не «кнопка связи», а публичный API для спама.
Если у вас WordPress, то без защиты контактка быстро превращается в фабрику мусора: ботам плевать на UX, они бьют по /contact, /subscribe, /feedback и массово жрут ресурсы.

Что обычно ставят:
- honeypot
- rate limit по IP / ASN
- nonce + server-side validation
- фильтрацию по поведению
- CAPTCHA

Но у классической reCAPTCHA есть цена: трекинг, third-party зависимость, лишний JS. Для сайтов, где важны privacy и минимизация внешних запросов, это уже не «мелочь», а архитектурный выбор.

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

Проверка для технаря:
1) сколько запросов добавляет защита
2) грузит ли она main thread
3) не ломает ли отправку без JS
4) есть ли server-side fallback

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

AI не убил HR. Он просто ускорил фильтр до жесткой механики.

Если у тебя за спиной fullstack/MVP-опыт, это не значит, что рынок обязан тебя пустить в следующий этап. В 2026 найм стал ближе к воронке логов: резюме → ATS → скрининг → техинтервью → отказ. На каждом шаге теряется до 70–90% кандидатов. И чем шире опыт, тем чаще он выглядит как «умеет всё, но не в наш стек».

Фриланс в РФ просел не из-за «плохого рынка», а из-за сжатия спроса и падения платёжеспособности. Если у фаундеров доходы упали на 60%, первым режут не архитектуру, а подрядчиков.

Что работает:
— стек должен совпадать с вакансией не на 50%, а на 80%+
— кейсы оформляй как измеримые результаты: latency, conversion, cost, deploy frequency
— резюме без воды: 1 экран, 3–5 релевантных проектов
— собесы сейчас выигрывает не «опыт», а доказуемая специализация ⚙️

Проверка возраста в мессенджере — это не про «галочку для юристов», а про архитектуру верификации.

Схема из статьи простая:
- мини-приложение в Telegram / MAX / любом другом мессенджере;
- пользователь загружает паспорт;
- сервис распознаёт документ;
- в ответ отдаётся только факт: старше/младше порога.

Без ЕБС, без биометрии, без хранения лишних ПДн. Это важно: чем меньше данных проходит через систему, тем ниже риск по безопасности и комплаенсу.

Что здесь интересно технарям:
1. Возраст проверяется локально на стороне сервиса в момент запроса.
2. В мессенджер уходит не скан, а результат проверки.
3. Интеграция завязана на мини-апп, а не на отдельный веб-флоу — значит, критичны:
- стабильность загрузки,
- обработка отказов,
- валидация форматов,
- контроль времени ответа.

Если делать правильно, это не «OCR ради OCR», а короткий trust-flow с минимальной поверхностью утечки данных.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах?

История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения.

Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше.

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

Вот например про один из таких кейсов писал уже здесь весной.

Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту.

Но когда одна сторона открыта к адекватной коммуникации и поиску оптимального решения, а вторая сторона просто игнорирует проблему, при этом не уходя с рынка в закат, а продолжая тратить огромные бюджеты на PR и маркетинг бренда - это любопытная аномалия.

Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал)

Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь.

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

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

Для мелкого и крупного бренда такие истории могут иметь очень разный эффект, поэтому здесь разберем на примере крупного бренда, так как Melbet в нашем рынке относится именно к таким.

Не знаю конечно их точные цифры затрат на PR в рамках афф рынка (участие в конфах, собственные ивенты, реклама в афф медиа и т.п.), но из того, что вижу как организатор ивентов с приличным опытом, этот бюджет явно измеряется в миллионах $ в год, если не выходит за $10млн+.

Это без PR затрат на прямое привлечение игроков (бренд-амбассадоры, спонсорства футбольных клубов и т.п.), без бюджетов непосредственно на закупку трафика. Только на аффилейтку.

И вот уже более месяца в паблике незакрытый и не откоммуницированный публично кейс на $2k (две тысячи долларов).

В публичной дискуссии сейчас преобладает позиция, что Melbet в этом споре неправы.

Может их развернутая публичная позиция поменяла бы мнение, но ее нет, соответственно на данный момент так.

Какие материальные потери может понести бренд в такой истории?

Многие люди, даже очень опытные и умные, почему-то к таким ситуациям относятся бинарно.

Рухнет бренд (закроется, обанкротится) - значит плохо на них повлиял кейс.

Останется бренд жить и работать как ни в чем не бывало внешне - значит никак не повлияло и может они правильно решили игнорировать, а кто-то вообще решит брать с них пример.

Но это же совсем не так, ситуация не бинарная.

Представим не фактические цифры Melbet, которых у нас нет, а консервативную модель крупного рекламодателя.

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

Я не знаю внутренний LTV партнёра у Melbet. Но если принять для активного опытного аффилейта условные $10,000 LTV, десять таких потерянных партнеров - это уже шестизначная сумма $ недополученного дохода. И это без учёта крупных команд, в случае которых эффект может быть кратно выше и оказаться семизначным.

Даже если в этой модели ошибиться и завысить в несколько раз, сам принцип никуда не исчезает - незакрытый публичный спор на $2,000 в любом случае обойдется бренду многократно дороже этих $2,000.

Цифры конечно я прикинул условные, но рассуждения не виртуальные - я знаю афф команды, которые перестали быть их активными партнерами из-за этого кейса.

Одна известная в рынке команда публично рассказала о своем таком решении в моем чатике про scam-кейсы.

А теперь вернемся к миллионам долларов в год, которые Melbet тратит на публичный PR среди аффов через конфы и прочие активности.

У этих трат же есть определенные ожидаемые и реальные результаты, верно?

На каждый затраченный миллион ожидается определенное количество привлеченных новых партнеров и укрепление лояльности и увеличение оборотов с определенным количеством действующих партнеров.

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

При таком незакрытом публичном кейсе, вызывающем большой отклик и возмущение в рынке - останется эта сумма выхлопа с PR X без учета прочих факторов или она станет меньше X?

Очевидно станет меньше, доверие к бренду ниже, а значит и вложения в PR дают меньшую отдачу.

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

Когда бренд инвестирует миллионы в доверие рынка - через конференции, медиа, партнёрские активности и PR, игнорирование аргументированного публичного конфликта снижает отдачу от всех этих вложений. Репутация не выглядит отдельной строкой в P&L, но её потеря вполне превращается в недополученный доход, более дорогой PR и менее лояльных партнёров.

Я искренне надеюсь, что все больше компаний в нашем рынке будут становиться более сознательными и не терять огромные деньги на ровном месте, и если бизнес-этика не зашита в культурный код, то хотя бы из сугубо материальных корыстных соображений начнут вести себя адекватнее)

Всем отличной недели и благоразумия)

Поймать «иероглифы» в ответе LLM — это не баг шрифта. Это симптом того, как модель кодирует текст и где у неё ломается декодинг.

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

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

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

Если хотите копать глубже: смотрите на токенизацию, logits, temperature, top-p и качество датасета. Именно там обычно и сидит причина.