Большинство объяснений машинного обучения начинаются с нейронов, весов или градиентного спуска. Но есть одна деталь, без которой вся эта конструкция вообще не работает.
Откуда модель вообще узнаёт, что ошиблась?
Именно с этого, как мне кажется, и стоит начинать изучение машинного обучения.
В новой части книги я попытался объяснить это максимально просто и без фраз вроде "нейросеть сама обучается". Разбираем, что такое ошибка, почему она превращается в loss-функцию, зачем вообще нужны MSE и Log Loss, и как несколько строк математики становятся тем самым сигналом, который заставляет модель становиться лучше. Loss-функции являются центральным механизмом обучения современных моделей машинного обучения.
Если давно хотели понять, что происходит "под капотом" современных AI-моделей – буду рад, если почитаете.
Хотел сделать крутую онлайн игру. Расскажу где всё пошло не так
Идея была простая до безобразия. Браузерная змейка но с живыми соперниками. Canvas, websocket, Node.js. Всё это я более-менее знал, казалось делов на пару выходных.
Первый день вообще огонь. Змейка ползает, еду ест, растёт, цвета красивые. Думаю ну всё, осталось только игроков подключить.
Ага.
Синхронизация это ад
Подключил websocket, запустил два браузера на одной машине, вроде видят друг друга. Отлично. Добавил искусственную задержку 50мс чтобы проверить как будет на реальной сети.
Всё сломалось.
У одного игрока змейка уже повернула, у второго она ещё летит прямо. Столкновения каждый клиент считает сам по своей картинке мира. Один видит что убил соперника, второй видит что убил он. Оба правы по своей логике.
Полез гуглить. Нашёл что это называется authoritative server, client-side prediction, lag compensation. Понял что я вообще не туда смотрел когда проектировал. Думал займёт вечер. Потратил месяц и всё равно сделал через одно место.
Лобби которое я не планировал
Ок, физику перенёс на сервер. Теперь надо чтобы игроки могли найти друг друга, подождать, начать игру. Звучит как мелочь.
Это не мелочь.
Ожидание, старт, игра, конец, переиграть — каждое состояние надо синхронизировать. И самое весёлое это когда один игрок просто закрыл вкладку в середине партии. Что показывать второму? Кто победил? Как засчитать? Три вечера только на обработку разрывов соединения.
Читер за пять минут
Дал поиграть другу. Через пять минут он открыл консоль и начал отправлять серверу произвольные координаты. Змейка телепортировалась куда хочет. Я вообще не думал об этом когда писал архитектуру.
Что по итогу
Игра работает. Можно найти соперника и сыграть партию. Но код это такой клубок что я боюсь его открывать.
Главное что понял: онлайн игра это не игра плюс немного сетевого кода. Это совсем другая задача где сеть и есть основная сложность. Я недооценил это раз в десять минимум.
Код выложу на GitHub как разберу этот клубок. Пока стыдно показывать.
Кто делал нормальный мультиплеер в браузере, как решали синхронизацию? Потому что мои костыли мне самому не нравятся.
Поддержка amoCRM может дать крутое решение, не описанное в документации, но оно не будет работать, потому что это ненастоящее решение.
Без негатива, но интересно, как это вообще могло произойти? У первого сотрудника поддержки была другая версия документации или на первой линии отвечает нейронка под галюнами?
Если же первый ответ дала нейронка, значит есть серьезные проблемы с памятью. Такое случается, например, когда векторную базу бездумно забиваешь огромным количеством документов, еще и схожих по смыслу.
За свою карьеру я успел попробовать Java, Python и ещё кучу всяких языков.
У каждого есть свои сильные стороны, ни один из них нельзя назвать "лучшим" для всех задач. Но заметил одну забавную вещь: спустя какое-то время я снова возвращаюсь к PHP.
Наверное, потому что за много лет он стал для меня чем-то вроде дома. Открыл проект – и всё такое родное )). Не нужно перестраивать мышление, вспоминать особенности экосистемы или синтаксиса.
В общем, в какой-то момент эта мысль показалась настолько забавной, что я решил сделать небольшую музыкальную пародию на известную песню (старый хит 70х) – только про PHP и разработчиков, которые "ушли, но вернулись".
Без холиваров, без попыток доказать, что какой-то язык лучше других. Просто немного самоиронии и хорошего настроения.
WT Max v.0.2.0. - библиотека для интеграции с Joomla
Обновление Joomla-библиотеки для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.
Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max, у которого так же состоялся релиз 0.2.0. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.
v.0.2.0. Что нового?
Подключена новая версия API-хоста:platform-api2.max.ru. Для корректной работы ваших чат-ботов и мини-приложений до 19 июля 2026 необходимо перенаправить HTTP-запросы с домена platform-api.max.ru на platform-api2.max.ru, а также добавить сертификат Минцифры в список доверенных. Как это сделать - ссылка на инструкция внизу поста. ‼️Если этого не сделать - вы получите уведомление об ошибке соединения и неверном сертификате.
Расширена публичная API-поверхность. Обновлены и дополнены методы для работы с чатами и сообщениями (включая новые сценарии по ссылкам на чат и выборке по query-id сообщения). Удалены устаревшие методы.
Обновлён набор публичных JSON-схем. Добавлены и синхронизированы схемы для новых и изменённых endpoint-ов. Эти схемы - снимки реальных ответов API Max, так как мы прекрасно знаем, что документация и реальное API может отличаться порой очень и очень значительно.
Обновление документации. README, стартовые руководства, референсы и описания сущностей/пэйлоадов приведены к текущему API-уровню.
Заряжаемся перед Робозоном: решаем задачу и погружаемся в атмосферу хакатона от Ozon Tech
«Подумаешь, коробка», — скажете вы. И правда, что может быть проще коробки… когда она одна. А что насчёт миллионов коробок? Бесконечный поток товаров, текущий по сортировочному центру. Конвейеры, сканеры, роботы — элементы сложной логистической системы — направляют и упорядочивают этот поток. И от разработчиков, от их способности создавать эффективные алгоритмы обработки товаров и устранять узкие места зависит, насколько быстро и безошибочно будут двигаться коробки.
Не верите? Тогда попробуйте сами решить задачку из серии «не дай конвейеру захлебнуться коробками».
Представьте: в логистическом центре два конвейера, 1 и 2, сливаются в один основной — конвейер 3, ведущий к сканеру штрихкодов. Поток на линии 1 — 1000 товаров в час, на линии 2 — 500 товаров в час. Сканер на линии 3 обрабатывает до 2000 товаров в час. Но вот беда: в точке слияния конвейеров товары сталкиваются, что приводит к затору. Датчики фиксируют «аварию», система постоянно делает микроостановки, поэтому реальная пропускная способность линии 3 падает до 1100 товаров в час.
Вам поручили придумать решение, которое поможет устранить заторы. Что вы выберете?
А. Увеличить скорость линии 3 до 2500 товаров в час, чтобы она моментально «выдёргивала» товары из точки слияния.
Б. Установить на линиях 1 и 2 логику «светофора» (накопительные буферы), пуская товары пачками по очереди.
В. Ускорить линию 2, чтобы её поток «проскакивал» в окна между товарами с линии 1.
Уверены в своём решении? Тогда проверьте его правильность под спойлером.
Вариант А кажется хорошим решением, но на деле не спасёт ситуацию. Запас по скорости на линии 3 есть и так (2000 > суммарных 1500), и если ускорить принимающий конвейер ещё больше, товары просто будут ехать по нему с большими просветами, но коробки с линий 1 и 2 всё равно будут приходить в точку слияния одновременно и застревать.
Вариант В не только не устранит заторы, но может и усугубить проблему: товары будут сталкиваться на ещё большей скорости, увеличивая риск повреждений.
Вариант Б — единственно верный в данной ситуации. Искусственное притормаживание потоков для формирования управляемых «пачек» (плотный поток с линии 1, затем пауза и сброс товаров с линии 2) повышает общую скорость системы, убирая хаос и микроостановки. Парадоксально, не правда ли?
Ладно, это была всего лишь разминка. Настоящие сложные задачи мы приберегли для хакатона Робозон с призовым фондом 15 000 000 рублей.
конструкция автоматизированного сортировщика товаров сортировочного центра;
интеллектуальная роботизированная система сортировки товаров.
Робозон стартовал 2 июля, регистрация продлится до 23:59 11 июля. Хакатон пройдёт в два этапа. Первый завершится 2 августа, и 11 августа будут известны финалисты. Во второй этап пройдут по 5 лучших команд из каждого трека, чтобы до 6 сентября доработать свои решения и побороться за победу на очной защите 12 сентября в Москве. Победителей наградят 13 сентября на конференции E-CODE.
Ещё больше информации о правилах участия, призах и даже подсказки, кого стоит набирать в команды для разных треков, — на сайте ozon-robozon.ru.
Участвуйте в хакатоне — пусть инженерная мысль помогает управлять многомиллионным потоком товаров.
Решил я значит попробовать вайбкодинг всерьез. Не поиграться, а реально взять рабочую задачу и пройти от идеи до переноса, почти без ручного написания кода.
Взял небольшой pet-проект: утилита для мониторинга изменений в директории с уведомлениями в Telegram. Задача понятная, ограниченная, без хитрой бизнес-логики. Первые два дня были магией. Описываешь что хочешь, получаешь код, он работает. Скорость ощущается раза в три выше обычной. На третий день начались проблемы. Модель начала путаться в контексте проекта. Предлагала решения которые противоречили тому что уже было написано двумя часами ранее. Пришлось самому держать в голове всю архитектуру и постоянно напоминать что куда подключено. К концу недели понял главное: вайбкодинг не убирает необходимость понимать что происходит. Он убирает необходимость это печатать. Если не понимаешь архитектуру, инструмент начинает строить что-то своё, и разбираться потом дольше чем написать самому.
Утилиту довёл до конца. Работает. Но половину кода всё равно переписал руками.
Кто использует вайбкодинг в реальных проектах, как решаете проблему с контекстом на больших задачах?
1 июля мы провели вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2.
В рамках вебинара я, Андрей Жуйков, амбассадор компании «Диасофт», рассказал о ключевых возможностях Digital Q.DataBase 18.2 — масштабном обновлении, направленном на развитие совместимости с корпоративными СУБД и упрощение миграции существующих систем.
Изменения коснулись Microsoft SQL Server-направления: расширена поддержка T-SQL, Service Broker, CLR-сборок, механизма CDC, а также появилась служба отчётов Digital Q.DataBase, совместимая с SQL Server Reporting Services (SSRS).
Отдельное внимание уделено Oracle-направлению: расширена поддержка Oracle-совместимых пакетов, курсоров и Bind-переменных, улучшена работа JDBC-драйвера, доработаны средства миграции Oracle-объектов, а также появилась новая технология автоматизированного перевода Oracle Forms в современные приложения.
На вебинаре рассмотрим ключевые изменения релиза, покажем их практическое применение и расскажем, как новые возможности помогают ускорить миграцию корпоративных систем и снизить затраты на переход на российскую СУБД.
В программе:
🔹 Обзор Digital Q.DataBase 18.2 Ключевые изменения релиза. Развитие совместимости с Microsoft SQL Server и Oracle. Новые возможности для миграции корпоративных систем.
🔹 Новая версия CDC Обновлённый механизм Change Data Capture. Новый веб-интерфейс управления. Сценарии применения и преимущества.
🔹 Новые возможности миграции и совместимости Расширение совместимости с Microsoft SQL Server. Новые Oracle-пакеты и развитие Oracle-диалекта. Поддержка CLR-сборок. Развитие Service Broker.
🔹 Служба отчётов Digital Q.DataBase Аналог SQL Server Reporting Services (SSRS). Поддержка RDL-отчётов. Формирование отчётов в HTML и PDF.
🔹 Новая технология перевода Oracle Forms Автоматизированный перевод Oracle Forms в современные приложения. Архитектура решения. Демонстрация технологии.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа
Docker используется везде: от локальной разработки до production. Фокус лабы — не на запоминании команд, а на понимании. Вы пройдёте путь от первого контейнера до настройки сетей и данных — своими руками. После лабы сможете уверенно обсуждать контейнеризацию с разработчиками, DevOps и архитекторами.
25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.
5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)
Два часа потерял из-за того, что не написал один хендлер
Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.
Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.
Payment failed
И всё. Telegram не говорит что именно не так.
Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.
Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.
Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.
Уже хотел идти спать, случайно наткнулся на строчку в документации:
Your bot must reply to this query in 10 seconds
Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.
У меня хендлера для этого не было вообще. Бот просто молчал.
Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.
🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?
19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.
📐 Проверенная методология FPF + TDD в основе каждого блока.
Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.
Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂
AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.
Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост
Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.
Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.
И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».
Тамагочи в терминале
Что это
team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.
team new – и у вас есть напарник-стажер и живая команда.
Дальше вы его растите от стажера до CTO.
Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.
Почему это тамагочи, а не просто игра
Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.
Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.
Это питомец, который ждет. И портится без вас.
Дилеммы из реальных споров
Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.
И часть инцидентов подтягивается из живого бэклога вопросов нашего сообщества. То есть в игру попадают дилеммы, которые реально обсуждали практикующие тимлиды, а не выдуманные кейсы из учебника.
Как сыграть
Никакой установки. Открываете терминал и печатаете team:
Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.
Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.
Что представляет собой книга
Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.
Её можно использовать как:
офлайн-версию курса для повторения материала;
удобный конспект при выполнении практических заданий;
справочник для быстрого повторения основных конструкций SQL.
Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.
Для кого она будет полезна
Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:
студентов IT-специальностей;
начинающих разработчиков;
будущих аналитиков данных;
тестировщиков;
всех, кто хочет разобраться в основах работы с реляционными базами данных.
Бесплатный доступ
Книга распространяется бесплатно.
Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.
Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.
Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.
На Бирже заказов Инфостарта опубликована новая подборка задач по 1С. В списке за неделю - внедрение «1С:Управление торговлей», обмены с бухгалтерией, настройка УПД и ЭДО, интеграция с Битрикс, подготовка технического задания на драйвер связи и другие работы.
В этой подборке — заказы, размещенные с 24 июня по 1 июля. На этой неделе в подборку вошли задачи для специалистов по «1С:Управление торговлей», «1С:Комплексной автоматизации», ЭДО, УПД, обменам с бухгалтерией, интеграциям с Битрикс и разработке решений на платформе 1С.
Биржа заказов Инфостарта помогает быстро найти исполнителя под задачу по 1С - от консультации и небольшой доработки до внедрения, настройки обменов, интеграции с внешними сервисами или сопровождения системы.
Формат подходит и заказчикам, которым нужен специалист под конкретную задачу, и исполнителям, которые хотят выбирать проекты по стеку, объему работ и срокам.
На площадке доступны:
0% комиссии — расчеты напрямую с подрядчиком;
исполнители разного масштаба — от одного разработчика до ИТ-команды;
Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.
Посмотрим на одно из предупреждений статического анализатора PVS-Studio:
V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250
Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.
Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.
Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.
Если вы тоже хотите минимизировать ошибки в своих проектах, сделайте статический анализ частью регулярного процесса, а поможет с этим PVS-Studio.
🤖 🤖 🤖 К счастью или сожалению, ИИ-инструменты стали нормой в сфере разработки софта. И если раньше ещё был некоторый скепсис, что «стрельнет» эта штука или нет, то теперь очевидно — либо вы освоите ИИ-инструменты, либо вы пойдёте на мороз.
Фишка ИИ заключается в том, что с ним достаточно легко получить какой-то результат, который в ряде случаев будет уместным. Однако добиться нужного результата нужного качества — достаточно сложно.
И тут у нас есть три пути:
1) Двигаться маленькими шагами, задавая ожидаемый результат ИИ-агенту. В данном случае агент полностью полагается на ваше руководство и вашу постановку и выполняет исключительно работу руками. До текущего момента я использовал именно эту технику и был вполне доволен.
2) Полагаться на итерации и самопроверку. Этот подход рекламируют разработчики ИИ-сервисов, когда вы задаёте финальную точку, а дальше ИИ-агент генерит много кода, выполняет самопроверку, удаляет большую часть, генерит её снова и так по кругу, пока не получится нужный результат. На демках это в целом работает, в реальных проектах — большие сомнения. Ну и те самые мемчики, когда разработчик тратит на токены больше, чем он зарабатывает в месяц.
3) Идеологом третьего подхода является Мэтт Покок (Matt Pocock), который предлагает технику разработки, основанную на скилах, которые сначала опрашивают тебя обо всех нюансах проекта, потом готовят документ, содержащий доменное знание. После этого разбивает задачу на маленькие таски и выполняет их, основываясь на доменное знание. Т.е. что-то из мира TDD, DDD и прочих техник.
Мне в своё время не очень зашло TDD в силу инверсии принципа разработки, которым я всегда работал. Но после ознакомления с тем, как предлагает работать Мэтт, кажется, эта штука может работать.
Cобственно, на этой неделе разбирал, как он предполагает работать, знакомился с его репозиторием скилов и дальше буду пробовать — https://github.com/mattpocock/skills
Листая на C++ Reference список принятых в C++29 фичей, увидел в нем пропозал с знакомым названием, «Thread attributes» (P2019R9). И, оказалось, действительно, я уже читал этот пропозал 4 года назад, но не в 9-й его редакции, а в самой первой. 4 года понадобилось комитету по стандартизации, чтобы принять пустячный пропозал, позволяющий задать имя и размер стека потока при его создании — востребованную фичу, реализованную в куче библиотек C++.
void f();
int main() {
// Такой вид задания атрибутов предлагался в первой ревизии
std::jthread P2019R1(
f, std::thread_name("Worker"),
std::thread_stack_size(512*1024));
// А такой приняли 8 ревизий спустя
std::jthread P2019R9(
std::thread::name_hint("Worker"),
std::thread::stack_size_hint(512*1024), f);
}
Не безумие ли это? И сколько действительно правильных пропозалов не вошло в C++ лишь по той причине, что их автор не был готов 4 года подряд защищать свое предложение, отвечая на все мелкие придирки различных подкомитетов?
Облачный сервис с безграничными возможностями: Бот или не бот - вот в чем вопрос.
Друзьям и коллегам, привет!
Недавно опубликовал на Хабр новую статью с разбором моего Web3-мессенджера. В ней описал личный кейс: как внедрить децентрализованные Web3 технологии и монетизировать внутренние функции приложения без подключения классических платежных систем. Почитать можно здесь: https://habr.com/ru/articles/1052088/
Дополняя тему мессенджера, хочу поделиться нововведением, которое значительно расширило возможности моего приложения. Надеюсь это будет полезно и другим разработчикам.
Создав так называемых "юзер-ботов" (user-bots), я снабдил платформу дополнительными функциями. В моей реализации такой "Бот" - это полноценный внешний сервис, который имеет точку входа - Endpoint на стороннем облаке и строгий протокол взаимодействия через его API.
В таких популярных приложениях как Telegram или WhatsApp, боты представляют собой отдельные сущности, которые привязываются к основному аккаунту пользователя. Кстати, вопреки расхожему мнению, один аккаунт в Telegram может создать через BotFather не безграничное число ботов, а строго до 20 штук (до 40 для Premium-пользователей).
В своей архитектуре я пошел совершенно другим путем. В моей схеме "Бот" по своей сути - это тот же самый пользователь, только виртуальный. Такой подход позволяет в любой момент переключить обычного юзера в бота и наоборот одним кликом.
пример бота реализующего сервис загрузки музыкального контента артиста на радио
Хотя при таком методе не получится создать «армию ботов» на один аккаунт. На каждого бота придется заводить новый. Но с точки зрения безопасности и чистоты архитектуры плюсы очевидны:
Полный контроль и безопасность окружения: бот изолирован и работает строго в рамках правил реального пользователя.
Защита от фишинга: это минимизирует риски мошенничества, делая бота реальным, полноценным аккаунтом, а не простой сервисной записью в базе данных.
Готовая монетизация: в профиле каждого пользователя уже прописаны платежные данные в виде Web3-кошелька. Соответственно, они автоматически доступны и боту, если тот реализует платные услуги.
РЕАЛИЗАЦИЯ НА БЭКЕНДЕ
Ниже упрощенный код класса реализующий передачу сообщений на Endpoint:
public async Task<string> ExecuteCommand(string cmd, string uid, string token, string url)
{
using var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = new ("Bearer", token);
var body = new StringContent(JsonConvert.SerializeObject(new { data = cmd, user_id = uid }), Encoding.UTF8, "application/json");
var res = await client.PostAsync(url, body);
var json = JObject.Parse(await res.Content.ReadAsStringAsync());
return json["success"]?.Value<bool>() == true
? json["data"]?.ToString()
: $"Error: {json["error"]}";
}
Используя описанную концепцию, можно в теории реализовать любой сервис не изменяя при этом основное приложение. Всё что нужно сделать, построить бот!
Очевидно, что для практического применения такого подхода необходимо обеспечить высокий уровень безопасности: внедрить защиту от SSRF (через валидацию URL и фильтрацию локальных хостов), настроить лимиты для предотвращения DoS-атак (проверяя размер заголовков и длину полученной строки), и так далее.
