Даже добавить нечего 🍰🥧🍨🫖

С пятницей!

#mems

📚 С небольшим опозданием, Энди Павло опубликовал свой ежегодный отчет о прошедших событиях в мире СУБД. Концовка статьи получилась очень "ламповой"💡. Остается какое-то светлое чувство в сердце 🏮, а так же небольшая обидка на то, что мирок РФ в области СУБД и мир США почти не пересекаются. Таков наш путь... 🌌

Товарищи сделали свой подробный разбор этой статьи, поэтому не думаю, что стоит повторяться.

Всем советую почитать оригинал. А ниже я отмечу некоторые фразы, которые затронули лично меня

Hydra and PostgresML went bust in 2025 (see Deaths section), so they're out of the game

Что тут сказать, проекты с интеграцией ML фишек в СУБД провалились. Это было от части предсказуемо. Интересно как дипломники 2026/27 годов будет выкручиваться, т.к. множество работ именно по связанным с этими СУБД тематикам 😊

If 2023 was the year every DBMS added a vector index, then 2025 was the year that every DBMS added support for Anthropic's Model Context Protocol (MCP)

Это для меня некое открытие 🤯. Я совершенно упустил этот тренд. Разработчики СУБД предоставили API для LLM в свои продукты. Интересная идея. Как заметил Энди это потенциальная угроза безопасности, поэтому подход КликХауса, который дал доступ только на чтение, выглядит весьма надежным.

HeavyDB → Nvidia
The death of Voltron and sort-of acquihire of HeavyDB seem to continue the trend of the inviability of GPU-accelerated databases.

Количество проектов с интеграцией DBMS+GPU сокращаются на конец 2025 года, но само направление перспективное. Сам Энди ожидает в 2026 году новых стартапов на этом поприще. Я тоже считаю, что идейка это неплохая. Просто время не то. Майнинговый бум всё испортил, а сейчас еще и дефицит чипов памяти, который опять скажется на рентабельности подобных подходов. Короче, ждем... ⏰

📚За новогодние праздники ничего интересного на Хабре по базам данных не было. Разве что можно отметить маркетинговую статью от PostgresPro: Каким будет энтерпрайз-СУБД в эпоху ИИ.

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

За последние 2 недели всё чаще попадаются статьи, комментарии людей, которые хейтят ИИ. Вот мол, спросил у ИИ одно, а получил какую-то фигню, а не ответ. Ай-яй-яй, плохой ИИ 🤬. Отменяем 🙅‍♂️Всё в том же духе.

Я использую ИИ в своей преподавательской и исследовательской деятельности довольно часто. ИИ прекрасно умеет набрасывать информацию по любой теме. Да, она может быть неактуальной или местами неверной, но это не важно. Гораздо проще "посеять" готовую информацию, чем потратить часы на поиск чего-то в гугле или книгах🥵.

Достаточно соблюдать правила безопасности и всё будет хорошо 😉

Можно и фейерверками не небо расстрелять, а себя 🎉💥➡️🍑 .
Таких видосов во всяких "тиктоках", VK клипах тьма.
Берегите себя ✋🤚

Современная реальность. Ничего тут не поделать

С пятницей!

#mems

📚 Помните я публиковал свою статью на Хабре?

Так вот, мне народ подсказал, а почему бы её не перевести на английский язык и не опубликовать на западных медиа ресурсах? Действительно, подумал я. Перевод статьи - это дело второе, а главное, на какой платформе?

Очевидным решением является - Medium

Но, он заблокирован на территории РФ. Я понимаю, что для настоящих айтишников нет преград, но всё же. Второй минус, это огромная текучка материала. Я полистал ленту по тегу #database и понял, что в день публикуется порядка 30 статей разной степени качества. Поэтому решил поискать что-то еще.

ИИ предложил мне несколько вариантов и я выбрал платформу hashnode.

Она вроде относительная молодая и больше ориентирована на блогеров. Думаю для начала сойдёт.

Итог, моя статья на английском языке🤪❗❗

p.s. будут замечания по тексту или формату, пишите

📚 Продолжим чтение коммерческих статей, которые обещают нам светлое будущее! На этот раз статья от основателя компании Turso, её ген.дира Glauber Costa, "ИИ-агенты открывают новые возможности для масштабирования баз данных"

Пропущу вступление и сразу к сути, товарищ Глаубер и его команда разработали open-source альтернативу СУБД SQLite и назвали её turso. Написали всё на Rust и обвесили ее модными и современными фичами. Такими как:

1. Распределенность и глобальные реплики
2. Бессерверный/сетевой доступ (HTTP API)
3. Ветвление (Branching) как в Git
4. Встроенная аутентификация и безопасность
5. Автоматическое резервное копирование и HA

Проект выглядит интересным. Надо будет какой-нибудь НИР сделать по ней. Интересно её протестировать о понять перспективы.

📚 Разработчик баз данных ClickHouse привлекает $400 млн и приобретает стартап Langfuse, занимающийся наблюдением за искусственным интеллектом

Только недавно подводили итоги 2025 года, где ClickHouse привлек 350 млн долларов за целый год 👀! А тут, не прошло и месяца, а уже +400 🍋на счету (еще наверное минус налоги, но это не важно) 🤑. Неплохо начался год у коллег 💪

По поводу покупки:

Компания приобретает стартап Langfuse, разработавший opensource-инструмент для мониторинга больших языковых моделей. Его ПО помогает отслеживать работу LLM-приложений и анализировать причины «галлюцинаций».
...
Langfuse использует базу данных ClickHouse для хранения собираемой телеметрии LLM. После приобретения компания ClickHouse улучшит интеграцию между двумя продуктами.

Мне нравится такой подход 👍. Зачем выстраивать дружеские взаимоотношения к малыми компаниями, если их можно просто купить? В духе американского рынка 🎣🎏

p.s. оказывается есть об этом новость на Хабре.

🔥 Alibaba представила open-source интеграцию DuckDB — AP-движок для аналитических запросов прямо в MySQL

Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.

Проект доступен полностью в open source — разработчики и компании могут использовать, модифицировать и внедрять эту технологию самостоятельно, без привязки к облачным сервисам.

🛠 Как это работает:

DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через INPLACE / INSTANT или COPY - механизмы
- Многопоточная конвертация таблиц

📊 Производительность:

На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
• DuckDB: 15.31 сек (в 1648 раз быстрее!)
• InnoDB: 25 234.31 сек

🌐 Исходный код и документация:

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

👉 Репозиторий и подробная документация

#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub

Выжидание не самая лучшая тактика...

С пятницей!

#mems

📚 Database Trends and Applications Magazine: December 2025/January 2026 Issue

❗️Тема номера: Флагманы управления данными на 2026

Дисклеймер: традиционно разбираю только небольшой набор статей.

➡️Survey:Tracking the Diversification and Decentralization Revolution in Databases

Опрос посвящён текущим тенденциям и вызовам в области баз данных. И так:

📊Разнообразие и децентрализация

Организации не отказываются от существующих систем (например, Oracle), но активно расширяют экосистему. Большинство респондентов также используют SQL Server (59%), MySQL (45%), PostgreSQL (40%) и облачные решения (Amazon RDS — 28%). Где-то на задворках MongoDB

Забавно, что ИТ-ландшафт опрошенных компаний представляют различные реляционные СУБД. О NoSQL почти ничего не написали. Поставили только MongoDB ради приличия...

🤖 Спрос на интеграцию с ИИ

Более половины опрошенных стремятся к тесной интеграции баз данных с фреймворками машинного обучения и ИИ. Нехватка квалифицированных кадров для таких инициатив (52%) — ключевое препятствие.

Чем это напоминает хайп вокруг GO. Разработчики на GO буквально год или 2 назад могли смело претендовать на ЗП 200% и выше процентов от среднего по рынку. И эти ЗП давали. Сейчас такая же песня с ИИ-специалистами. Деньгами их осыпают весьма щедро! Думаю этот тренд сохранится еще несколько лет.

⚡️ Проблемы производительности

Производительность БД остаётся больной темой: 62% сталкиваются с проблемами ежемесячно или чаще, что напрямую влияет на продуктивность и доходы компаний.

☁️ Планы по переходу в облако

Сейчас 45% БД размещены локально, 37% — в облаке. В течение 3–5 лет доля облачных баз данных, по прогнозам, вырастет до 53%, а локальных — сократится до 30%. Однако гибридные среды останутся нормой.

Для РФ не могу сказать, что это статистика актуальна, ну, может быть.

🚧 Нехватка навыков

Помимо дефицита экспертов по ИИ, 24% организаций испытывают нехватку даже в базовых навыках управления базами данных, что усугубляется растущим разнообразием технологий.

Разработчики и администраторы по прежнему актуальные профессии.

➡️ Information Management Trends in the Year Ahead
Разберем тренды. Спойлер: все тренды связаны с ИИ

1. Демократизация ИИ. ИИ-инструментария станет еще больше и он будет более доступный для всех сотрудников компании.
2. Предметные AI-агенты: Появятся автономные агенты, глубоко обученные для конкретных отраслей (например, здравоохранения или логистики), которые будут самостоятельно управлять, очищать и оптимизировать данные.
3. Цифровая рабочая сила: AI-агенты станут полноценными «сотрудниками» в организационной структуре компании, будут участвовать в проектах и вносить свой вклад.

Роботы начинают захватывать мир! Предвесники Скайнет (с)

➡️When the Cloud Comes Home: What DBAs Need to Know About Cloud Repatriation

Статья рассказывает о феномене репатриации из облака (cloud repatriation) — обратном перемещении рабочих нагрузок из публичного облака обратно в локальную инфраструктуру

Основные причины возврата данных "домой":
💵 Непредвиденные расходы:
⚡️ Производительность и задержки (Latency):
🛡 Контроль и соответствие нормам (Compliance):

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

📚Решил немного полисать книжку
Основы инженерии данных: как создавать надёжные системы обработки данных, 2024 год, ISBN 978-601-08-4116-1

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

Data Engineer строит “фабрику данных” и отвечает за то, чтобы она работала.

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

Инженерия данных — дисциплина про построение и эксплуатацию надёжных систем обработки данных

❇️Общее впечатление от книги
Впечатление двойственное. С одной стороны, книга аккуратно раскладывает профессию на жизненный цикл и фоновые процессы и даёт много здравых идей, а с другой, она говорит языком архитектуры и принципов, высоких материй и т.п. Мне бы хотелось больше “бытового” уровня: типовых кейсов, ошибок, компромиссов и примеров решений. Получается, что ты понимаешь слова и фразы, но не всегда очевидно, а зачем это знать? В итоге книга оставляет хорошую теоретическую рамку, но требует параллельной практики или примеров, иначе легко запутаться.

Короче, мне нужна книга "Инженерия данных для чайников" 🤓. Есть такая? 🤪

p.s. конечно можно на курсы сходить, но это совсем другая история

❇️Выделю несколько тезисов

👉 Жизненный цикл инженерии данных: Это центральная концепция книги, включающая пять стадий: генерация, хранение, поглощение, преобразование и предоставление данных. Эти 5 стадий сквозят через всю книгу.

👉 Принципы «качественной» архитектуры: Хорошая система должна быть масштабируемой, слабосвязанной, безопасной и экономически оптимизированной (FinOps).

👉 Технологии выбирают после архитектуры

👉 Эволюция хранения и поглощения: Разбираются различия между пакетной и потоковой обработкой, а также современные концепции хранилищ (Data Lake, Data Warehouse, Data Lakehouse)

👉 Понимание источников (схема, форматы, время события, ограничения прод-систем) заранее задаёт границы качества и SLA всего конвейера

👉 Хранение — ключевой архитектурный рычаг: lake/warehouse/lakehouse, compute–storage, кеширование и экономические компромиссы.

👉 Моделирование и трансформации превращают данные в продукт: выбор модели (Кимбалл/Инмон/Data Vault и др.), управляемые конвейеры ETL/ELT и контроль производительности запросов

👉 Безопасность и приватность — сквозной процесс: начинать нужно с людей и процедур (least privilege, управление учётками/секретами), затем — технологии (шифрование, патчи, мониторинг).

👉 Будущее смещается к real-time и “данным в продукте”: меньше ручных отчётов, больше автоматизированных действий и потоковых контуров.

🤯 Понавыдумавали кучу терминов, Data Engineer, Data Warehouse Analyst, DataOps, Data Scientist. И еще сборку Data Quality. Жесть какая-то 🤬. Кто за что отвечает знают только в БигТехе. В остальных компаниях всё это размывается на 2-3-х человек.

📚 NoSQL vs SQL in 2026: Why We Moved Back to Postgres After 4 Years of MongoDB Flexibility

Статья с Medium*, так еще за "пейволом". Придется вам поверить мне на слово 😅

Суть статьи: Жили-жили мы на MongoDB 4 года. Наворотили кучу сервисов и превратили данные в настоящий хаус 🐣.
Пример

// Found in production, January 2024
{ email: "sarah@company.com", signup_date: "2023-01-15" }
{ emailAddress: "john@test.io", signupDate: "Jan 15, 2023", signUpDate: null }
{ mail: "alex@startup.co", created: 1673740800, active: 1 }
{ contact_email: "maria@corp.com", created: "2023-01-15T00:00:00Z", active: true, isActive: true }

Куча разных полей с email.

Накопили кучу техдолга и вместо того, чтобы "причесать" данные в MongoDB решили от нее отказаться в пользу PostgreSQL. Конец 🤯.

Такое ощущение, что это статья из 2017 года, которая появилась только сейчас. Сама ситуация банальная 🥱.
MongoDB плохая, т.к. разработчики не ограничены схемой данных и каждый творит, что хочет. Зачем нам такая свобода? 🤷‍♂️ Срочно вернуть схему данных и жесткие ограничения! ASAP! 😡

По мне звучит как детский сад. 🐥
Я понимаю, когда люди принимают осознанное решение при миграции с MongoDB на PostgreSQL. Основная причина - это люди и DBA в частности.

DBA на PostgreSQL начти - в разы проще, чем на MongoDB. Всё сводится к тому, что не хватает компетентных людей, которые могут "приготовить" MongoDB надлежащим образом ☹️.

Грустно как-то. Я в свое время очень хотел стать настоящим спецом по MongoDB, но после их ухода их РФ 🚪 бросил эту идею .

*заблокирована на территории РФ

Каникулы еще не закончились, поэтому продолжайте наслаждаться!

С пятницей!

#mems

Просто оставлю это здесь.
Гифка зачётная 😊

📚Что такое реплики чтения и когда их следует использовать

Уже не первый раз мне попадаются статьи с ресурса https://www.devx.com, но они все какие-то странные и бессмысленные 🚮. Текущая статья примерно в такой же духе.

Текста много. Смысл в тексте тоже есть. Но всё какое-то абстрактное, все выводы банальны 🐣 и после прочтения у меня в голове новых знаний и понимания не появляется 😶‍🌫️.

Многие ругаются, что сейчас народ статьи пишет с ИИ 👯‍♀️. В статье больше ИИ текста, чем текста человека 🤖. Тут ситуация другая. Если я попрошу ИИ рассказать мне о "читающих репликах", то он мне напишет в разы интереснее текст 😀.

Может у меня уже пошла профдеформация какая-то. Не знаю. Подобные тексты я более упоминать не буду. В этот раз поделился мнением... 😑🙂‍↕️

p.s Руководство по выбору между базами данных SQL и NoSQL. Еще одно подтверждение. Заголовок же классный! Провоцирует на чтение. Но после прочитанного полное разочарование. На какой это уровень читателя расчитан я не поманию. Бросаю читать этот ресурс. Хорош...😑

💬 3-4 февраля 2026, прошла 26-ая конференция iFin-2026.

Крупнейший форум по электронным финансам в России с 2001 года🔝. Исключительно оффлайн-формат.

✅ Пока опишу общее впечатление. Более детальный разбор сделаю позже.

Напомню, что основная направленность конференции -

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

Я туда хожу последние лет 10 с целью узнать о трендах банковских услуг и продуктов и составить понимание куда всё движется.

Из нового организаторы решили поставить сделать дополнительные "круглые столы" в середине мероприятия. Я побывал на обоих

Круглый стол №1. «Будущее ДБО: эволюция ожиданий клиентов vs технологические возможности»
Круглый стол №2. «Инфраструктура, ориентированная на клиента: как ИТ влияет на эффективность обслуживания»

Темы то классные, но с таймингом организаторы не угадали ⌛️. Дали 40 минут и позвал по 6-7 участников. Каждый взял слово на 2-3 минуты и стол закончился. Даже вопросов никто не успел задать. Все это превратилось в короткое интервью с одним вопросом, что вы думаете о <тема круглого стола>. Конец 🏁.

🫤 - итог

✅ О стендах

Группа Астра
Они впервые на этом форуме. Притащили "макет" машины баз данных Tantor XData. Внутри этой чудесной коробки почти ничего не было. Сплошные заглушки 🫥. Но смотрелось красиво 🥹! Спору нет. Жаль, что не было тех.специалистов, а были только маркетологи. Но я от них словил несколько тезисов, которые еще надо будет подтвердить.

👉 XData работает на процессорах Baikal-S и такие мышины выходят дешевле и даже лучше аналогичных сборок на Intel/AMD.
👉 Разработчики процессоров Baikal-S наладили производство в Китае, поэтому поставки идут полным ходом
👉 Из-за переоринтирования производства с Тайваня на Китай пришлось серьезно переработать архитектуру процессоров. За пару лет ребята справились.
👉 Тантор считает, что их решение "на глову" лучше аналогов от Скалы-Р и PostgresProMachine. Пруфов нет.

Мобиус Безопасность
Спецы ИБ, которые работают в банковской сфере. Но примечательны они своими промо и видеороликами 🎦. Просто гляньте их оф.сайт. Сделали прикольный видос с огромным красно-черным инопланетным пауком 🕷🕸! Смотрится реально круто 👍! Если бы они сделали какой-то мерч с ним, хотя бы футболки, блин, это был бы разрыв для всего форума 👕! Но... не та это конфа...ой, не та 😑. Из прикольного мерча был только тюлень в шапке от наших БазальтСПО (AltLinux). Эххх 🤷‍♂️

Больше и отметить нечего. Глаз особо не за что не зацепился 👁

Пока на этом всё. Сделаю обзор по докладам позже...

С началом нового учебного семестра!

За каждым великим человеком есть кто-то в его тени...

С пятницей!

#mems

📚Memory wall: что это и почему важно для индустрии хранения данных
Мне понравилась статья! 😎

Она хорошо написана и погружает читателя в мир аппаратных средств хранения информации. КЭШ процессора (L1,L1,L3), RAM, SSD, NAS(SAS), S3. Здорово, что автор обо всем этом пишет, но хотелось бы глубины 🌊. Наверное в формат одной хабр-статьи не влезет всё. Хорошо бы прочитать по подробнее про каждый вид хранения. Можно развернуться на целый цикл. 🌀

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

Подождем. Может кто-то отважится 😉

⚡️ В один прекрасный момент мне сразу на глаза попались две статьи:

1️⃣ Мысли вслух. Протоколы и механизмы синхронизации транзакций в распределённом вычислительном кластере СУБД

Это философский этюд в жанре «а что если мы сделаем распределённую СУБД, которая ведёт себя как монолит, но не разваливается». Хммм 🤨.
Автор аккуратно размышляет про 2PC, прокси, парсинг SQL и детерминизм, периодически натыкаясь на фундаментальные законы физики, CAP-теорему и здравый смысл - и каждый раз честно признавая, что да, быстро, надёжно и распределённо одновременно всё-таки нельзя. Но почему бы и не помечтать... 😇

2️⃣ Разбираемся в функциональных зависимостях БД
Автор спокойно и вежливо объясняет, что если в проектируйте из разряда «студент → кафедра», то вы уже одной ногой в аду аномалий 🤔. Также подчёркивается, что функциональные зависимости - это не то, что случайно получилось в данных, а то, что изначально задумал архитектор. Правда, в реальной жизни все не так 🙃.

Я как раз уже в 14-ый раз 🤯😳 переписываю свой доклад для PG.Conf.Russia на этот счет. Ловлю себя на мысли, что очень не хватает какой-то современной литературы по проектированию баз данных. У PostgresPro есть современный учебник и демо базу они недавно обновили, но на этом всё. Больше ничего такого нет.

Периодически смотрю западные "книжные магазины" 😎 и там литературы по моделированию схем баз данных довольно много 📚. Каждый год книги 3-5 выходит. А то и больше📖. По хорошему надо бы скупить все эти книжки, почитать и вычленить из них что-то новое, чего нет в нашей "отечественной школе" 🏫.

❗️Прекрасная тема для доклада на PG.Conf.Academy в 2027 году. Доклад на этот году у меня уже есть 😁

🚧 ОФФТОП🚧 

📚 В Госдуме заявили, что россиянам «вредно» мечтать о зарплате в 1 млн рублей

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

Эта публикация прекрасна во всей красе 🤬! Нельзя даже помечтать в 2026 году о ЗП 1 млн рублей 💔

❇️Немного рассуждений

Сразу скажу, что людей со своим бизнесом я брать в расчет не буду, хотя налоговое бремя в этом году стало тяжелее. Добиться ЗП для себя любимого 🥰 в 1 млн.рублей стало в разы сложнее 🤔. Факт. 👊

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

Если вы работайте на одну компанию, то получить в ней должность с ЗП в 1 млн - это великое достижение 🏆! Респект вам 🥳! Скорей всего это руководящая должность (я не знаю примера, чтобы какой-нибудь высококлассный инженер получал столько). За это придется платить высоким уровнем ответственности 🕴 и стресса 😱.

Вариант попроще добиться желаемой ЗП стал возможен после ковида и популяризации удаленки. Люди смело устраивались в несколько компаний, скажем в 3-4 штуки, на простые позиции программистов/специалистов и суммарно можно было получать 1 млн рублей в месяц без проблем 😎.
Тут минусы немного другие, и основной из них - это время ⏰. Рабочий день уже не 8 часов, а все 12, а то и больше. Перегрузка на лицо. Зато 🍋 в кармане.

Я сам пошел по второму сценарию. У меня несколько работ (больше 4-х), но доход ниже заветного 🍋. Чтобы преодолеть эту планку мне нужно еще 3 доп.работы 🤯. Мой рабочий график уже вышел за 68 часов в неделю. Брать на себя ЕЩЕ доп.активности - это путь подорвать здоровье 🤕🤧.

Признаюсь, порой очень хочется хотя бы несколько месяцев получать на карту 1 млн.рублей 😌🤤. Просто ради "лычки" для самого себя🎖.

Зафиналю пост небольшим анонсом. Начиная с 24 февраля мой рабочий график преподавания будет выглядеть так:

Вторник - курс Redis/Valkey - записывайтесь пока есть места!
Среда - лекция/семинар в МАИ / МГТУ им.Баумана
Четверг - лекция/семинар в МФТИ каф БИТ
Пятница - лекция/семинар в МФТИ каф блокчейн

Только в понедельник у меня одна основная работа и более ничего. Отдых 💥