Привет. Три года не был на пикабу, но от решил поделиться очередным пет-проектом.
Предыстория - увидел на ютубе как кто-то сделал модель города в виде ascii и продаёт доступ к демке. Решил попробовать повторить. Движок умеет рендерить примитивы, освещение и текстуры. В качестве вторых рук использовал Qwen3.8 27b, запущенный локально. Никаких облачных ИИ не использовал. Демка вместе с исходниками доступна на гитхабе - https://tyzegt.github.io/ascii3d/
Проект написан на js, открывается в браузере, ничего лишнего не требует.
Планировал за вечер доделать систему ответов. Но не справился. Работал над системой ответов и внезапно всплыл неприятный момент: 1) История сообщений грузятся динамически пачками по Х сообщений. Каждое соообщение может ссылаться на какое-то сообщение из истории переписки. 2) Сообщение на которое ссылается текущее сообщение может не быть загружено. В этом случае его нужно подгрузить. Иначе приложение будет думать, что сообщение удалено:
И тут самый сок. За что я не люблю Flutter/мобильную разработку - это за то, что нельзя просто взять и загрузить то, что недостает:
Начались пляски с бубном на тему того как же оптимальней подгрузить эти недостающие сообщения. Перепробовал разные методы, самый оптимальный (на мой взгляд) - загружать допсообщения в момент, когда грузятся основные сообщения.
Ничего умнее и оптимальнее придумать не смог. Другие вариант подгрузки приводят к ожиданиям из-за обращения к БД в следующем кадре; А еще они приводят к хитровымудренным схемам перестройки интерфейска, что мне совсем не понравилось (работы там и без этого хватает).
Ранее писал что буду переделывать систему вывода таймстемпов т.к. в ней были выявлены ошибки. Переделал:
1/3
Таймстемпы теперь всегда в правом нижнем углу
Также состояние доставки перенес в самый правый угол сообщения.
Сейчас сообщения-ответы на сообщения отправляются, приходят и нормально выводятся. Проблем не должно быть.
Далее берусь за работу над контекстым меню сообщений (это когда жмешь на сообщение и возникает меню с вариантами действий). Вот его нужно добить и можно будет редактировать сообщения :)
После контекстного меню буду думать над загрузкой медиа на сервер (для обмена файлами). По идее серверная часть уже реализована, нужно бы научить приложение загружать медиа на сервер и обрабатывать ошибки загрузки :)
Вроде интерфейс получается. Вспомнил первые наброски интерфейса:
Примерно так он выглядит сейчас:
-- По вечерам разрабатываю сервис для общения на Go & Flutter. Кому интересно, можете подписаться куда-нибудь на меня, попробуете его в числе первых. Постепенно буду продолжать делиться успехами разработки сервиса.
Примеры кода в серии — на C#/.NET, потому что так написан наш прод. Но всё описанное — про механику Telegram, а не про язык: то же самое собирается на Node, Python или Go без изменений. Собственно, ради этой переносимой механики статья и написана.
О чём статья? Мы вайб-кодингом построили мост из Telegram в Google Meet, Zoom и другие сервисы видеовстреч — и набили все шишки, которые можно набить о miniapp при разработке бизнес-приложения. В этой статье — четыре реальных лайфхака, которые стопроцентно пригодятся вам при написании любого бизнес-приложения на Telegram miniapp. Вот некоторые из них:
готовый блок правил для памяти агента — ограничения веб-движка Telegram плюс требования каталогов (копируется в CLAUDE.md как есть);
функция «где я?» — платформа и режим, без которой каждая страница будет полем чудес;
туннель с первого дня — приём, который превращает деплой-на-каждый-чих в итерации по секундам;
как хранить состояние между вызовами бота, miniapp и внешним браузером;
бот, который «звонит» как телефон;
и другие;
А это вся серия:
Часть 1 (вы здесь) — история продукта и честный вердикт Telegram как платформе для бизнес-приложений: что дёшево, что больно, что прописать агенту до первой строчки кода.
Часть 2 — механизм сессий: как передать параметры из инлайн-бота в miniapp, а потом прочитать их во внешнем браузере; аутентификация, обратная связь в чат и как не словить бан за редактирование сообщений.
Часть 3 — UX-хаки: бот, который «звонит» как телефон, онбординг-воронка одним JSON-файлом и почему ссылки надо готовить до клика.
С чего всё началось
Звонки в Telegram работают — но именно как звонки: голос, видео, положил трубку. Встречи — другой жанр, и он в Telegram почти не развит. А вот в Google Meet и Zoom вокруг встречи выросла целая экосистема: транскрибация, AI-саммари, запись, расширения, интеграции с календарями и CRM. Когда разговор рабочий — хочется именно встречу, со всем этим обвесом.
Но переписка-то живёт в Telegram: там группа с коллегами, там клиент, которому «удобнее в телеге». И каждый раз, когда переписка дозревает до «давай голосом», начинается ритуал: открыть Google Meet или Zoom, создать встречу, скопировать ссылку, вернуться в чат, вставить, объяснить, куда нажимать.
Идея была наглая в своей простоте: пусть ссылку создаёт бот. Прямо в чате, одной кнопкой, в том сервисе, который доступен и у меня, и у собеседника. Так появился GoosleeBot — мост из Telegram в мир видеовстреч: Google Meet, Zoom, Teams, Jitsi, FaceTime и далее по списку.
Дальше был чистый вайб-кодинг: агент, промпты, итерации. Цифры такие: первый MVP — Google Meet, Zoom и Jitsi — был готов за два дня и честно доказал, что идея работает. А потом были четыре недели доводки. И вот что важно: главным расходом времени был не код — код агент пишет быстро. Время съело множество сценариев, которые пришлось охватить и протестировать: два собеседника или группа, первый звонок или сотый, подключён ли у автора провайдер, iOS или десктоп, свой чат или чужой — и каждую комбинацию надо прогнать руками в настоящем Telegram.
Именно поэтому статья устроена не как «смотрите, какие мы молодцы», а как список вещей, которые я бы прописал агенту в память до первой строчки кода. Потому что главный урок такой: Telegram — отличная платформа для продуктивити-приложений, но её веб-движок — не браузер, а Bot API — не REST-бэкенд. Если агент этого не знает, он уверенно нагенерит красивое неработающее.
Как это выглядит для пользователя
1/4
Сценарий: в любом чате вызываешь бота, жмёшь кнопку — бот создаёт комнату у доступного провайдера и кладёт в чат кнопку «Присоединиться». Если собеседник не реагирует — бот умеет «позвонить»: слать сообщение-звонок с повтором, как настоящий входящий вызов (как это сделано — в третьей статье серии, там простой и наглый трюк).
Ни один участник не устанавливает ничего нового. В этом вся ставка: дистрибуция через чат — фича Telegram, которой нет ни у одной «нормальной» платформы.
Правила, которые нужно прописать агенту в память до старта
Это центральная часть статьи. Если вы вайб-кодите под Telegram — скопируйте этот блок в CLAUDE.md / system prompt агента как есть. Каждое правило оплачено часами отладки «а почему на айфоне не так».
Блок А. Веб-движок Telegram — не браузер
Никогда не использовать `100vh`. Только `viewportStableHeight` / CSS-переменную `var(--tg-viewport-height)` и подписку на событие `viewportChanged`. Что сломается: на iOS низ страницы уедет под панель, на Android клавиатура «сожмёт» экран и разложит вёрстку.
Никаких `window.open` и `target="\_blank"`. Только `Telegram.WebApp.openLink()` для внешних ссылок и `openTelegramLink()` для внутренних. Что сломается: на части клиентов клик молча не сделает ничего.
Никаких `alert` / `confirm` / `prompt`. Только `showAlert` / `showConfirm` / `showPopup`. Что сломается: то же самое — молчание вместо диалога, причём не везде, а «у некоторых пользователей», что хуже.
Не полагаться на cookies для авторизации в miniapp. Webview теряет их непредсказуемо. Авторизация — токеном, переданным явно (заголовок или параметр). Что сломается: пользователь «разлогинивается» между открытиями, а вы неделю ищете несуществующий баг на сервере.
`localStorage` — это кэш, а не хранилище. Всё важное — на сервере (или в `CloudStorage`). Что сломается: состояние пользователя внезапно обнулится, и вы об этом не узнаете.
Навигация «назад» — через `BackButton` Telegram, а не через history браузера. Что сломается: системная кнопка «назад» на Android закроет miniapp целиком вместо возврата на шаг.
Первым делом на каждой странице — определить, где ты: платформа и режим (miniapp или обычный браузер). От этого ветвятся CSS и поведение. Функция ниже.
Всё, по чему пользователь кликает, должно быть готово до клика. Привычная веб-схема «клик → сервер обработал → сформировал URL → редирект» в Telegram не работает: переадресации нет. Конечный URL должен лежать в кнопке уже в момент её отрисовки — то есть всю «нагрузку редиректа» надо вычислить заранее (подробный разбор — в третьей статье).
Тестировать минимум на трёх клиентах: iOS, Android, Desktop. Это три разных webview с разным рендером и разным поведением. «Работает у меня на десктопе» — это ноль из трёх.
Блок Б. Требования публикации — с первого дня, а не «потом отполируем»
У каталогов (и у самого Telegram, и у витрин miniapp-ов) есть требования к приложению. Переделывать под них готовый продукт — самая дорогая работа в проекте. Поэтому в память агента, жёстко:
Мультиязычность с первого экрана. Ни одной строки текста в разметке — всё через локаль-файлы. Язык пользователя приходит сам: `initDataUnsafe.user.language\_code`. Добавить второй язык в проект, где строки зашиты в вёрстку, — это переписать проект
Тема — только через `themeParams`. Все цвета — из CSS-переменных `--tg-theme-\*`, тёмная и светлая темы обязательны, подписка на `themeChanged`. Ни одного захардкоженного цвета. Что сломается: белый текст на белом фоне у половины аудитории — и отказ каталога.
Каталог проверяет: языки, обе темы, все платформы. Это требования релиза, а не полировка. Агент должен считать их частью definition of done каждой страницы.
Функция «где я?» — обязательный первый кирпич
Одна и та же страница у нас открывается на iOS, Android, десктопе — и иногда просто в браузере (пользователь скопировал ссылку). CSS и поведение различаются во всех четырёх случаях, поэтому первым в проекте появился вот такой помощник:
CSS. Отступы под шапку/низ, safe area на iOS, реакция на клавиатуру на Android — всё вешается на классы `plt-\*`.
Редиректы. После OAuth-авторизации у Google мобильного пользователя надо вернуть в Telegram диплинком `tg://`, а десктопного — обычным `https`-редиректом на страницу. Перепутаешь — получишь либо зависший браузер, либо выброшенного из миниаппа пользователя.
Заглушка для «не-Telegram». Если `initData` пуст — это не miniapp, и вместо приложения показываем страницу «откройте через бота».
Мелочь? Мелочь. Но без неё каждая страница превращается в поле чудес.
Лайфхак: туннель с первого дня
Telegram не умеет «localhost»: и webhook бота, и URL miniapp-а должны быть публичными HTTPS-адресами. Поэтому первым инструментом в проекте — раньше базы, раньше CI — должен стать туннель: ngrok, cloudflared, dev tunnels в Visual Studio — что угодно, дающее постоянный публичный адрес на вашу локальную машину.
Рабочий цикл получается такой: бот и miniapp настроены на адрес туннеля, код правится локально с hot reload, а проверяешь — в настоящем Telegram на настоящем телефоне, сразу. Без туннеля каждая итерация — это деплой; с туннелем — секунды. Помните про количество сценариев, которое съело четыре недели? Без туннеля это были бы не недели.
Вердикт: Telegram как платформа для продуктивити-приложений
Что дёшево — неприлично дёшево:
Дистрибуция. Продукт распространяется пересылкой кнопки в чат. Ноль установок, ноль лендингов на старте: собеседник видит кнопку — собеседник уже пользователь.
Аутентификация из коробки. Telegram сам подписывает данные пользователя и отдаёт их miniapp-у. Не нужно ни регистрации, ни паролей, ни «войти через Google» — нужно только правильно проверить подпись (об этом — вся вторая статья).
Inline-механика. Бот работает в любом чате, даже там, где его нет в участниках. Это и есть «мост»: продукт живёт внутри чужих разговоров, а не ждёт пользователей у себя.
Realtime — работает, и его нужно делать. Мы сомневались, взлетит ли SignalR (WebSocket) внутри telegram-webview. Взлетел: полноценный хаб с группами живёт в бою на всех платформах. Обновление статуса звонка прилетает в miniapp мгновенно, без перезагрузок. Fallback на polling мы держим — но как страховку, а не как основной канал. Если ваш агент предлагает «давай просто поллинг каждую секунду» — не соглашайтесь, соединение честно работает.
Что больно:
Зоопарк клиентов. iOS, Android, Desktop, web — четыре разных Telegram с разным webview. Отсюда правило №9 и функция «где я?».
Веб-движок с характером. Весь блок А выше — это его портрет.
Требования каталогов. Языки и темы — не опция. Кто узнаёт об этом в конце разработки, тот переписывает вёрстку.
Из скучного: приём апдейтов от Telegram у нас переключается флагом между webhook и polling — удобно для отладки, и это всё, что стоит знать об этой теме.
Итого: если ваш продукт — про коммуникацию, координацию или «сделать что-то не выходя из чата», Telegram даёт фору любой платформе. Плата за это — дисциплина по отношению к webview. Дисциплину можно делегировать: просто отдайте агенту правила из этой статьи.
Что дальше в серии
Часть 2 — про самое неочевидное. Инлайн-кнопка в чате — одна на всех участников, и открывает она просто ссылку. Как передать в miniapp параметры конкретного звонка? Как понять, кто именно нажал, и не дать себя обмануть? Как вернуть ответ из miniapp обратно в чат? И отдельная ловушка: часть флоу неизбежно уходит во внешний браузер (например, OAuth-авторизация у Google) — а там переменные miniapp не работают вовсе, и из контекста Telegram остаётся только то, что вы сами положили в URL. Расскажу про механизм сессий, который закрывает всё это разом — причём это не трюк для проброса параметров, а полноценный серверный аналог сессии: типизированное хранилище значений, на котором держится вся серверная логика звонка. Бонус: как редактировать сообщения в чате асинхронной очередью и не словить бан от Bot API.
Часть 3 — про фокусы. Как заставить бота «звонить» — с повторными уведомлениями, как настоящий входящий вызов (спойлер: удаляем и переотправляем сообщение). Почему ссылки нужно готовить заранее — и это не про классическое «пре-генерите URL»: в обычном вебе вы кликаете, сервер обрабатывает запрос, формирует ссылку и делает переадресацию — в Telegram эта схема не работает в принципе, редиректа нет, и всю «нагрузку редиректа» приходится вычислять заранее, до клика. Как провести пользователя по продукту JSON-файлом вместо онбординг-движка: скрипт-чат, который печатает, показывает слайды и пишет воронку в аналитику.
Всё описанное написано для Telegram, но в большей части справедливо и для MAX — механика ботов, miniapp и сессий там строится по тем же принципам. Если есть желание сделать адаптацию под MAX и российские сервисы видеовстреч — велком в личку.
Покрыть инструкциями все кейсы - цель, которая на стадии формирования в данный момент, но вы всегда можете задать вопрос на github, который на данный момент не освещен в документации (не забывайте добавить метку `question`) или в комментариях к постам.
Позже добавлю инструкцию по запуску с Traefik и подробнее опишу настройку уже самого DNS.
А еще docker-сборки релизов теперь сразу будут загружаться в DockerHub (в будущем планирую публиковать еще и в реестах GitHub и Yandex.Cloud для лучшей доступности, т.к. в некоторых регионах сейчас провайдерами блокируется доступ к DockerHub).
Все также ведется работа над проектом, сейчас изучаются вопросы связанные с мониторингом. А именно изучаю какие метрики важны для надежного мониторинга.
Модели OpenAI во время тестов вышли из-под контроля: они создали скрытый форум во внутреннем менеджере пакетов, где обменивались найденными уязвимостями, координировали атаки и делегировали задачи друг другу. В итоге они проникли на платформу Hugging Face, а количество сообщений на их «форуме» достигло сотен тысяч. В OpenAI назвали это переломным моментом и признали, что необходима полностью автоматизированная защита от таких автономных атак
Еще больше информации в моих каналах MAX и телеграмм
Всем привет, меня зовут Сергей Па́токин, и здесь я расскажу историю про свои 18 карат невезения и участие в научной конференции.
В декабре 2020 года произошло событие, которого более пятидесяти лет ждали криптографы, журналисты и люди, добровольно изучающие переписку серийного убийцы.
Был расшифрован Z340 – один из четырёх известных шифров Зодиака, орудовавшего в конце шестидесятых годов.
С задачей справились три программиста-энтузиаста из разных стран:
Дэвид Оранчак из США;
Сэм Блейк из Австралии;
Ярл Ван Эйке из Бельгии.
Они не представляли одну государственную лабораторию и не располагали секретным суперкомпьютером. Просто три человека объединили знания, разработали необходимые инструменты и решили задачу, которая десятилетиями считалась практически неприступной.
Оригинальный шифр Z340
Z340. Триста сорок символов, несколько десятилетий попыток и три программиста, которым никто не объяснил, что подобные проекты лучше оставить на старшие курсы.
В расшифрованном тексте находилось обращение к полиции и рассуждения самого убийцы. Зодиак писал о том, что не боится казни, и продолжал поддерживать образ человека, которому известно нечто недоступное остальным.
До этого был расшифрован только Z408 – первое большое криптографическое послание Зодиака. Его разгадали ещё в 1969 году. В нём автор сообщал, что любит убивать людей, потому что это весело.
Мысль достаточно простая. Для её передачи потребовалось более четырёхсот символов и полвека внимания к личности автора.
Оставшиеся шифры продолжали сопротивляться анализу.
И вот спустя более пятидесяти лет нашлись люди, которые смогли расшифровать один из них.
О расшифровке Z340 я узнал почти сразу.
К тому моменту я уже хорошо знал биографию Зодиака, историю его преступлений, писем и публичной игры с полицией и газетами. Разумеется, я знал и о его шифрах.
Новость меня невероятно вдохновила.
Я подумал:
Смогли они – смогу и я.
На тот момент я только поступил в университет и учился на первом курсе направления «Информатика и вычислительная техника» в филиале МГТУ имени Баумана.
Я был начинающим программистом, но уже достаточно уверенно владел языками программирования и представлял алгоритмы, которые можно было реализовать для анализа другого шифра Зодиака – Z13.
Возможно, самого важного из оставшихся.
Шифр Z13
Z13 – предположительно, имя Зодиака. Всего тринадцать символов.
В сопровождавшем шифр письме Зодиак утверждал, что внутри содержится его настоящее имя.
В другой истории для решения проблемы было бы достаточно узнать имя человека и увидеть его лицо. В моей сначала требовалось расшифровать тринадцать символов, а затем каким-то образом доказать, что полученное имя действительно настоящее.
Проблема заключалась именно в длине шифра.
Для сравнения: в Z340 было триста сорок символов.
Если после расшифровки длинного сообщения получается связный текст с предложениями и устойчивым смыслом, можно с достаточно высокой уверенностью предположить, что решение найдено.
Если результатом тринадцати символов должно стать имя, вариантов становится почти бесконечно много.
Имя может быть настоящим или вымышленным, полным или сокращённым. Оно может содержать ошибку, псевдоним или дополнительный знак. Кроме того, Зодиак мог солгать.
Это предположение не требовало особенно смелой научной гипотезы.
Поэтому главная сложность состояла не в том, чтобы получить варианты расшифровки. Главная сложность – понять, что среди них есть правильный.
Я осознавал это с самого начала.
Но решил двигаться от малого: реализовать несколько возможных алгоритмов, выделить подходящие варианты и постепенно сокращать пространство поиска.
Научный проект
Весной 2021 года в университете проходила ежегодная научная конференция.
Я решил, что дешифратор Z13 станет отличной темой для проекта, пришёл на кафедру и записался.
Тема быстро стала известна среди моих однокурсников. Люди подходили, задавали вопросы, интересовались историей Зодиака и тем, каким образом я собираюсь анализировать шифр.
Я с энтузиазмом рассказывал о задумке, алгоритмах и перспективах проекта.
Постепенно о работе начали говорить преподаватели и другие сотрудники университета. На фоне стандартных студенческих разработок попытка расшифровать имя одного из самых известных неустановленных серийных убийц действительно привлекала внимание.
Первая программа
Для проекта я разработал две программы.
Первая выполняла полный перебор возможных вариантов расшифровки латинского текста.
Теоретически она гарантированно должна была обнаружить правильную последовательность – при условии, что эта последовательность вообще находилась внутри выбранного пространства поиска.
Проблема была лишь в количестве вариантов.
Полностью выполнить такой перебор на доступном мне оборудовании было невозможно из-за ограничений вычислительной мощности и памяти. Даже если бы программа завершила работу, она выдала бы огромное количество результатов, среди которых всё равно требовалось определить единственно правильный.
Но сам факт того, что нужная комбинация гарантированно присутствует среди результатов, представлялся мне интересным. Поэтому программу я реализовал как демонстрацию метода.
Технически это была конструкция с многократной вложенностью циклов.
Моя первая и, вероятно, единственная программа, в которой каждый новый уровень вложенности выглядел как ещё одна дверь, за которой находилась следующая дверь.
Код первой программы
Полный перебор. Для завершения требовались несколько тысяч лет или примерно 1,21 гигаватта.
База имён и фамилий
Вторая программа была более практичной.
Она работала с базами реальных имён и фамилий.
Готовой подходящей базы у меня не было, поэтому я начал формировать её самостоятельно. В первую очередь собирал распространённые имена и фамилии жителей США, поскольку именно там действовал Зодиак. Затем начал расширять выборку, добавляя варианты из других стран.
Имена и фамилии хранились отдельно.
Это позволяло проверять разные комбинации:
имя;
фамилию;
имя и фамилию вместе;
сокращённые варианты;
перестановки;
преобразования каждой части по отдельности.
В результате я собрал несколько тысяч имён и фамилий вручную, потому что бюджет проекта состоял из энтузиазма, свободного времени и крышек, которые университет почему-то не принимал.
Значительную часть информации приходилось искать, проверять, приводить к единому формату и вручную добавлять в локальную базу.
Я не просто написал алгоритм. Я своими силами формировал данные, на которых он должен был работать.
Фрагмент локальной базы имён и фамилий
Часть локальной базы. Несколько тысяч имён и фамилий, собранных вручную.
Первым делом я проверял сравнительно простые варианты:
прямую подстановку;
шифр Цезаря с различными смещениями;
перестановки символов;
несколько вариантов преобразования алфавита;
комбинации имён и фамилий;
сопоставление структуры повторяющихся знаков.
Постепенно я объединил несколько алгоритмов в одной программе. Она брала записи из базы, преобразовывала их разными способами и сравнивала получившиеся последовательности со структурой Z13.
Совпадений я не получил.
Ни одного.
Ни по одному из реализованных алгоритмов.
Это не было расшифровкой, но тоже представляло собой результат.
Несколько тысяч распространённых имён, несколько тысяч фамилий, различные комбинации и базовые алгоритмы не дали даже убедительного кандидата.
Это могло означать, что либо Зодиак использовал более сложный принцип шифрования, либо записал имя нестандартным способом, либо внутри вообще находилось не имя.
Был и ещё один вариант: Зодиак мог намеренно создать строку, не имеющую однозначного решения, а затем объявить, что спрятал в ней свою личность.
Для человека, который годами кормил прессу загадками, это выглядело вполне последовательно.
В дальнейшем я планировал приобрести более крупную официальную базу имён и фамилий. Она позволила бы расширить поиск и перейти от самостоятельно собранной выборки к более серьёзному массиву данных.
Для этого требовалась поддержка университета.
Выступление на конференции
Весной на научной конференции я подробно представил свою работу.
Рассказал об истории шифров Зодиака, принципах шифрования, расшифровке Z340 и особенностях Z13.
Объяснил, почему малое количество символов не упрощает задачу, а делает проверку результата почти невозможной.
Показал обе программы:
полный перебор;
систему анализа реальных имён и фамилий.
Продемонстрировал принцип их работы, рассказал о собранной базе данных, перечислил проверенные алгоритмы и обозначил дальнейшие направления исследования.
У меня не было готовой расшифровки.
У меня была сложная нерешённая задача, собственные программные инструменты, несколько тысяч собранных записей, результаты проверки гипотез и план развития проекта.
То есть исследовательская работа.
Слушателей проект заинтересовал. На фоне остальных выступлений тема выглядела необычно.
Мой научный руководитель – заведующий кафедрой и одновременно один из членов жюри – посмотрел на меня с некоторым сожалением.
Результаты конференции ещё не объявили, но мне уже начали объяснять, что я учусь только на первом курсе, что впереди будет много других проектов и что расстраиваться не следует.
Обычно человека утешают после объявления результатов.
Меня это несколько озадачило.
Научная объективность
Первые три места заняли проекты, связанные с разработкой типовых телеметрических приборов.
Темы этих проектов студентам рекомендовали преподаватели кафедры. Сами приборы были нужны кафедре.
Пока я самостоятельно искал способ решить нерешённую задачу, другим участникам уже выдали задание, указали направление и поставили маркер над конечной точкой. Оставалось только не свернуть по дороге исследовать ближайшую пещеру.
Проекты кафедры решали задачи кафедры, получали поддержку кафедры и затем оценивались представителями кафедры.
Наука иногда удивляет совпадениями.
Победившие работы опубликовали в университетском журнале. Кафедра получила необходимые ей разработки, студенты получили места, а система – ожидаемый результат.
Но не расшифровал же
Во время объявления результатов заведующий кафедрой снова отдельно упомянул мой проект.
И произнёс фразу, которую я запомнил навсегда:
Да, ты пытаешься расшифровать шифр. Но не расшифровал же.
Тогда я подумал:
Вот так да. Если бы я уже расшифровал имя Зодиака, вероятно, представлял бы результат в Гарварде.
Чтобы работа первого курса считалась достаточно успешной, мне следовало окончательно решить одну из самых известных криптографических загадок XX века.
Желательно за несколько месяцев, на домашнем компьютере и с базой данных, собранной вручную.
После этого можно было бы конкурировать с прибором, техническое задание для которого заранее подготовила кафедра.
Возможно.
Заведующий кафедрой снова сказал, что проект хороший, но я нахожусь только на первом курсе и у меня всё впереди.
Остальные участники, насколько я помню, тоже не успели состариться в стенах университета.
Просто у их проектов был более прямой маршрут к результату.
Так закончилась моя история про 18 карат невезения.
Что было дальше
Свою идею я не бросил.
Я лишь отложил её и позднее периодически возвращался к проекту по мере развития искусственного интеллекта и появления новых методов обработки данных.
Технологии постепенно давали возможности, которых у меня не было весной 2021 года.
Можно было расширять базы, использовать статистические модели, анализировать вероятности, искать закономерности и проверять значительно больше гипотез.
Но первая конференция дала мне отдельный результат, не связанный с криптографией.
Я понял, что научная среда не всегда продвигает неизвестное. Неизвестность неудобна: она не гарантирует готового устройства, публикации и результата к установленной дате.
Настоящая исследовательская задача может закончиться отрицательным результатом. Может потребовать годы. Может вообще не иметь однозначного решения.
Именно поэтому она является исследовательской задачей.
Но для победы на конференции значительно надёжнее разработать то, что уже ждут в соседнем кабинете.
С Зодиаком всё было проще.
Он хотя бы не притворялся, что играет честно.
---
К Z13 я ещё вернусь – уже с современными моделями, более крупными базами и методами, которых у меня не было в 2021 году.
Если вам интересны исследования в области программирования, искусственного интеллекта, или же просто безумные истории разработчика, который в силовой броне стремится в форбс (тяжело, шумно, но уверенно тащу ядер-колу на продажу), подписывайтесь. Здесь будут и другие мои проекты. В том числе расскажу про свою разработку видеоигр.
Какие методы вы бы проверили на тринадцати символах в первую очередь?
У каждого, даже самого жесткого синьора, бывали моменты, когда мозг во время ночного дедлайна просто уходил в глухую несознанку. Это то самое чувство, когда ты готов проклясть создателей языка и переписать всю архитектуру проекта, а проблема в итоге решается одной забытой точкой с запятой.
Давайте устроим в комментариях вечер откровений и самоиронии. Какой был ваш самый эпичный, глупый или абсурдный косяк, над которым вы бились часами, а дело оказалось в полной ерунде? Или Вы идеальны?)
Продолжаю работу над своим пет-проектом. В первой версии оказывается плохо работали запросы к внешним DNS при запросе внешних зон. Исправил этот баг, и бонусом добавил возможность указать несколько upstream серверов (они опрашиваются параллельно и отдается первый успешный ответ).
Поправил запуск через docker. Там не совпадал порты по умолчанию с портами указанными в инструкции по запуску, если не передать переменную окружения с нужным портом.
Теперь при запуске схема базы обновится автоматически и не потребуется прописывать `docker compose exec ...`
Самое крупное изменение - SOA записи. Теперь при создании доменной зоны можно ввести refresh, retry и expire параметры, а при запросе SOA будет возвращать соответствующий ответ. Т.е. вручную не нужно прописывать SOA записи в зоне, но нужно прописать `ns.<zone>.` записи для корректной работы (но об этом позже).
При удалении доменной зоны теперь не остается в базе "висячих" записей.
Еще обновил работу кэширования и теперь удаленные доменные зоны не висят в кэше.
Настроил CI/CD процессы и автоматизировал выгрузку релизов в DockerHob. А еще поправил запуск тестов в пайплайнах, т.к. они по факту вообще не запускались 😬
Запланировано
В первую очередь хочу добавить автоматическое создание ns. записей при создании зоны т.к. SOA ответы будут уже содержать такие данные (не очень хорошо, что их по факту нет).
Не все приложение сейчас покрыто логами а если и покрыто, то в разнобой (где-то через пакет log а в других местах используется slog).
К логам, я считаю, стоит добавить и возможность мониторить сервис, поэтому добавлю метод /metrics для возможности собрать метрики в Prometheus. Выделю отдельный мультиплексер для возможности разделения доменных имен метрик и REST, чтобы можно было не светить метриками во внешние сети.
Дополнительно
Этот проект не стал одним из артефактов потерявшихся пет-проектов. Все благодаря инструментам, которые помогают не терять контекст проекта даже через месяц отлучения.
Если интересно какие инструменты для планирования я использую - маякните в комментах. Если будет интересно, то расскажу про них и в целом про то что у меня развернуто на локалхосте.
