Антиошибка недели: ставить уведомление о снижении цены как «ещё один крон», а не как часть событийной схемы.

У себя в проектах я бы делал это так: товар попадает в вишлист → в системе фиксируется текущая цена и время → дальше по расписанию или по событию обновления каталога сравниваем новую цену с последней сохранённой → если цена упала, уходим в SMS-API и отправляем оповещение 📩

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

Для Bitrix логика ложится в агент, cron или обработчик события обновления цены. Сохранять состояние лучше отдельно от каталога, чтобы не тащить сравнение в runtime компонента. Иначе потом получите магию в шаблоне, тормоза на странице и неочевидные ошибки при кешировании.

И да, SMS здесь часто полезнее почты: цена изменилась — сообщение должно дойти быстро, без зависимости от inbox. Для e-commerce это не «фича ради фичи», а прямой возврат пользователей в корзину.

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

Я бы смотрел на такой кейс как на встраиваемый контур идентификации: пользователь открывает мини-приложение в Telegram, MAX или другом мессенджере, проходит распознавание паспорта, получает подтверждение возраста — без ЕБС, без биометрии и без лишнего раскрытия ПДн.

Схема здесь простая:
1. Мини-приложение собирает документ.
2. Сервис распознавания выделяет дату рождения.
3. Логика на стороне платформы принимает решение о доступе.
4. В систему уходит только результат проверки, а не полный набор данных.

Для интегратора здесь важен не сам OCR, а границы ответственности: где хранится документ, сколько живёт сессия, что пишем в логах, как исключаем повторную обработку и как потом это вяжется с правами доступа в CRM или личном кабинете.

Я бы назвал это типовым архитектурным паттерном для digital-сервисов, где возраст — не формальность, а контрольный барьер 🔒

Я когда-то думал, что обложка для Telegram или статьи — это просто PNG. Сделал один файл 1200×630 и дальше только подменяй картинки. На практике PNG — это середина цепочки, а не конец.

Типовой кейс из проекта выглядит так:
1. Есть шаблон обложки.
2. В разных сервисах нужно подставлять новый заголовок.
3. Файл надо сохранить в правильную папку и с понятным именем.
4. Затем кто-то должен обновить `og:image`, чтобы WordPress и соцсети не тянули старый превьюшный мусор.

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

Я для себя вывел простое правило: один графический файл ничего не решает, пока не определены точка генерации, место хранения и правило, кто и когда переписывает Open Graph. Иначе обложка есть, а в предпросмотре — прошлый век 🧩

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

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

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

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

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

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