Друзья, поздравляю вас с Новым 2026 годом 🎄✨
Пусть он начнётся без критических инцидентов 🚨, внезапных «падений продакшена» ❌ и срочных правок в последний момент. Желаю, чтобы системы работали стабильно ⚙️, решения принимались осознанно 🧠, а технический долг постепенно сокращался 📉 — без авралов и выгорания.

Пусть в новом году будет больше понятных архитектур 🏗, аккуратных конфигов 📄 и задач, которые действительно развивают 🚀. Желаю, чтобы обучение приносило удовольствие 📚, новые технологии ложились в голову без боли 💡, а сложные проблемы решались не за счёт нервов, а за счёт опыта и спокойствия 😌.

Спасибо, что читаете этот блог 🙌, делитесь мыслями и находите здесь что-то полезное для себя. В 2026 году желаю нам всем больше здравого инженерного подхода 🧩 и удовольствия от того, что мы делаем 😊. С Новым годом 🎉 — пусть он будет стабильным, продуктивным и технологически чистым!

2025: длинная дистанция без иллюзий
Коротко о главном
2025 год оказался не годом достижений, а годом выживания и пересборки. Без громких побед, зато с большим объёмом честной внутренней работы: переосмысление профессии, денег, здоровья и собственных ожиданий. Если описывать его одной метафорой — это был бег с препятствиями без зрителей и аплодисментов.
Работа и рынок
Конец 2024 года я встретил увольнением и пятью месяцами поиска работы. За это время рынок труда показал себя во всей красе: он сломан, перегрет и абсолютно не гуманен к соискателю. Поиск работы превратился в отдельную профессию: курсы по алгоритмам, soft skills, работа с карьерными коучами и постоянная правка резюме. Результат — 1–2 собеседования в неделю вместо привычных 1–2 в день.
Эффект «импортозамещения» закончился: деньги в IT кончились, неключевые проекты закрылись, а рынок окончательно стал рынком работодателя. Когда финансовая подушка начала стремительно таять, я вернулся к очевидному: за плечами 20 лет системного администрирования.
Попытка вернуться в профессию выглядела сюрреалистично. Вакансии сисадминов напоминали цирк с грустными клоунами: от кандидата требуется всё, платить готовы почти ничего. Школы, больницы, государственные учреждения — текучка, завалы и выжженная земля. Один визит в поликлинику как кандидата, скорее для расширения кругозора, окончательно убедил меня: на таком месте можно застрять на годы, разгребая чужие ошибки.
В итоге я нашёл компанию, где работаю сейчас. Она занимается продажей и обслуживанием банковского оборудования. Я пришёл как связист по Asterisk. Около 500 абонентов, до меня — пять разных специалистов, каждый оставил после себя собственный почерк. Горы Perl-скриптов, криво переписанных на bash, неиспользуемый код и отсутствие целостной архитектуры. Цветущий сад я не вырастил, но значительную часть мусора удалось вывезти.
Что удалось сделать
1. Голосовое меню Asterisk и интеграция с Bitrix24. Третья попытка оказалась удачной. Базовый принцип — ни один звонок не должен пропадать. Сколько проживёт текущая версия, покажет время.
2. Оптимизация телефонии: отключены два оператора связи и половина телефонных номеров, которые фактически не использовались, но стабильно съедали бюджет.
3. OfeliaMerge — отдельный проект и утилита для конвертации cron-задач из bash-формата в формат Ofelia при миграции серверов.
Отдельным открытием стал процесс найма разработчиков изнутри. На одну вакансию за день может прийти до полутора тысяч резюме. Сначала автоматическая фильтрация по ключевым словам через AI, затем живое общение и отбор самых сильных кандидатов. Рынок работодателя без иллюзий.
Здоровье
Со здоровьем всё было тяжело. Головные боли преследовали весь год: ощущение, будто в голову несколько раз в день забивают гвоздь. Проблема оказалась сосудистой. После смены нескольких неврологов я нашёл цефалголога, и назначенное лечение наконец дало ощутимый эффект.
С сентября по декабрь — почти непрерывные ОРВИ. Только восстановишься — снова сляжешь. К вечеру состояние было таким, будто весь день разгружал вагоны. Плюс удаление зуба и регулярные визиты в аптеки. Этот год наглядно показал: здоровье — это не фон, а полноценный проект, требующий внимания и ресурсов.
Финансы
Финансово 2025 год прошёл под словом «апож». Финансовая подушка была полностью израсходована за время поиска работы. Портфель на фондовом рынке из-за последних геополитических событий превратился в сверхдолгосрочную инвестицию на 20–30 лет.
Криптопортфель показал минус 70 процентов за год — около 3000 долларов. Убыток пока бумажный, выходить из позиций я не стал.
С переходом на новую работу доход снизился примерно в три раза, а расходы остались прежними. Пришлось провести аудит: отключить неиспользуемые подписки, оптимизировать траты, перейти на более дешёвые решения. Итог — жизнь по средствам.
Финансовые цели на 2026 год простые и приземлённые:
1. Финансовая подушка безопасности.
2. Отпуск.
3. Наращивание криптопортфеля.
Системное администрирование
Из программиста я снова стал системным администратором. В работе — Asterisk, FreeBSD, ZFS, Debian, Zabbix.

FreeBSD оказалась отдельным испытанием. Она похожа на Linux ровно до первого серьёзного шага в сторону, а дальше начинаются собственные правила игры: свои ключи, свои подходы, свои грабли. Docker нет, вместо него — Jail. NodeJS пришлось собирать из исходников. Зато ZFS из коробки — мощь: снапшоты, кеширование, сжатие. Если бы не лицензия, эта файловая система давно стала бы стандартом де-факто.
DevOps
Основная система готовится к переезду в Kubernetes, поэтому год прошёл под знаком k8s. Я прошёл два курса и много практиковался. Kubernetes не столько сложный, сколько объёмный. Чтобы повторить возможности docker-compose даже на одной ноде, требуется минимум 1–2 месяца обучения, а также время и терпение.
Параллельно я поработал с Ansible и написал плейбук для первичной настройки Debian, познакомился со стеком Prometheus и Grafana и сделал демопроект для мониторинга WordPress. В сравнении с Zabbix связка Prometheus + Grafana показалась мне более гибкой и удобной.
Впереди — Terraform. Поднимать десятки серверов вручную желания нет.
Программирование
Фронтенд на текущей работе не нужен. Основной фокус — бэкенд и чат-боты для Bitrix24. Asterisk оказался куда сложнее, чем кажется: 25 лет разработки продукта и четыре разных программных интерфейса.
Я прошёл курсы по NodeJS и NestJS, прочитал книгу В. И. Светлакова «Архитектура бэкенда». Рост как специалиста ощущается отчётливо: от проблем с синтаксисом — к вопросам архитектуры и проектирования.
Я познакомился с очередями сообщений через RabbitMQ, следующим шагом для меня станет Kafka. Параллельно я изучал разные языки программирования: прошёл курс по Haskell и хочу попробовать Rust, C и C++. В конце года решил повторить использование SQL — отчёты по АТС быстро показывают пробелы в знаниях.
Сильное влияние на моё восприятие программирования оказали книги Тейта Брюса «Семь языков за семь недель» и «Код. Тайный язык информатики» Чарльза Петцольда. Они расширяют взгляд на Computer Science и заставляют иначе смотреть на привычные технологии.
Искусственный интеллект
В 2025 году я осознанно начал разбираться в AI. Раньше использовал его поверхностно, теперь понимаю, насколько плохо знал возможности инструментов. В 2026 году планирую идти глубже и использовать их более системно.
English
Летом я закрыл уровень B1+. Для текущей работы этого достаточно: документацию читаю, обучающие видео понимаю. Главное осознание — офлайн-курсы дают лишь небольшую часть результата, остальное обеспечивают самостоятельная практика и дисциплина.
Хобби, культура и отдых
Музыка осталась важной частью жизни. Домашний звук вышел на новый уровень, концерты и живые выступления по-прежнему радуют. Было много книг, спектаклей, экскурсий и лекций. Этот блок я намеренно оставляю кратким — он про эмоции и впечатления, а не про отчёты.
Итог
2025 год стал для меня годом тихой, но важной внутренней работы. Без показных побед, зато с честным взглядом на себя, свои ограничения и реальные возможности. Я выхожу из него не идеальным и не успешным по чек-листу, но более устойчивым и собранным. А значит, всё происходившее имело смысл.

P.S. Сделал ментальную карту планов на 2026 год

Прошла первая неделя нового года. Итоги я подвёл, планы составил (см. прошлый пост) и, как говорил Леонид Ильич Брежнев: «Наши цели ясны, задачи определены. За работу, товарищи!».
В первую неделю нового года я решил заняться двумя вещами: изучить Rust и попробовать написать собственный язык программирования.

Почему Rust?

Что-то низкоуровневое я хотел изучить давно. Есть миф, что «настоящие программисты пишут только на C, C++ и ассемблере». Конечно, это не так.
Современный разработчик чаще пишет фичи, чем работает с железом. Он скорее водитель, чем механик. Но понимание того, как всё устроено внутри, всё равно даёт серьёзное преимущество.
Я посмотрел несколько видео про Rust.
«Язык Rust и функциональное программирование» https://www.youtube.com/watch?v=1Q3hGTqbH8Q
Главная мысль простая и очень здравая: лучшего языка не существует — есть язык под конкретный контекст. Функциональные языки вроде Elixir и Erlang отлично подходят для распределённых систем и бизнес-логики, но начинают проигрывать на тяжёлом парсинге и больших объёмах данных. В таких случаях уже уместен Rust: высокая производительность, контроль над памятью и заимствованные из функционального программирования идеи — ценой более высокого порога входа. На практике выигрывает гибридный подход: логика остаётся на высокоуровневых языках, а вычислительно нагруженные части реализуются на системных.

«OR: Rust без иллюзий» https://www.youtube.com/watch?v=sKNLaQtN7OA
Это прагматичный разбор без хайпа. Rust даёт безопасность памяти, строгий компилятор и хороший туллинг, но платой становятся сложная эргономика, медленная компиляция и непростая работа с unsafe-кодом и асинхронностью. Часто он уступает Go по скорости разработки. Вывод тот же: язык вторичен, первичны архитектура, работа с памятью и понимание операционных систем. Rust стоит изучать осознанно — как инструмент под конкретные задачи, а не как универсальный ответ на всё.
Я за гибридный подход. В Node.js без проблем встраиваются нативные модули на Rust, плюс есть WebAssembly, который тоже можно писать на нём. Если коротко: Rust — снайперская винтовка, Node.js — автомат Калашникова. Каждый хорош на своём месте.
Я уже начал изучать Rust. Пока курсы либо слишком поверхностные, либо слишком хардкорные. На данный момент больше всего зашли:

— https://metanit.com/rust/tutorial/
— https://rustlings.rust-lang.org/ - упражнения с починкой кода
— https://doc.rust-lang.org/book - официальный Rust Book

Зачем мне свой язык программирования?

На работе у меня горы кода на Asterisk, написанные задолго до меня. Формально всё работает, но любая правка превращается в археологические раскопки.
Основная проблема — мёртвый код: функции, которые никто не вызывает.
В идеале задача выглядит просто: построить граф вызовов и удалить всё, что не используется. Попытки решить это с помощью регулярных выражений не взлетели — код не только мёртвый, но ещё и битый. В этот момент и пришли на ум формальные грамматики и AST (Abstract Syntax Tree — абстрактное синтаксическое дерево).

Нашёл хорошее видео «Пишем свой язык программирования с нуля»
https://www.youtube.com/watch?v=iQHj1JWOLzA
Видео показывает, как и зачем на практике создают языки программирования: от реальных историй с DSL (Domain-Specific Language — предметно-ориентированный язык) в продакшене до базовой теории компиляции — лексера, парсера, AST и семантики — и её применения. Автор пошагово разрабатывает простой язык Kek: описывает грамматику, генерирует парсер с помощью ANTLR ([https://www.antlr.org/](https://www.antlr.org/)), добавляет выражения, переменные, условия, циклы и функции, а затем компилирует всё в WebAssembly, честно разбирая возникающие ограничения и баги.
Общий вывод простой: если правила становятся сложнее if-else, пора думать о грамматике и парсере, а не о костылях.

Написание собственного языка — не магия. Вся теория известна давно, инструменты тоже есть: ANTLR, LLVM ([https://llvm.org/](https://llvm.org/)). Самое сложное здесь — не реализация, а экосистема. Моя задача куда проще: взять конкретный код, убрать всё лишнее и получить чистую, понятную базу. Посмотрим, что из этого выйдет.

Началась первая рабочая неделя.

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

Решается это тоже просто: звонки сохраняются в базе данных, а программа сопоставляет номер клиента и номер менеджера обычным SQL‑запросом.

Начал писать программу, используя Asterisk Gateway Interface (AGI). И довольно быстро стало понятно, что без AGI SQL‑запрос из АТС вообще не вызвать — напрямую Астериск с базой не разговаривает.

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

Первое — логирование. Я решил писать все вызовы скрипта в собственный лог. Но внезапно оказалось, что данные не пишутся в файл. То ли права, то ли путь, то ли глобальные переменные — несколько часов бился в эту стену. В итоге плюнул и стал писать в лог Asterisk. С ним, как ни странно, никаких проблем не возникло.

Вторая боль — деплой.

Скрипт я разрабатываю на своём компьютере под Windows, а запускаться он должен на АТС под FreeBSD, в конкретной папке и с конкретными правами. Подключиться к серверу просто так нельзя — нужен сертификат. В результате я подставлял сертификаты, писал bash‑скрипт, который делает несколько разных настроек, чтобы мой код на FreeBSD вообще стартовал. Несколько часов ушло на то, чтобы по факту… скопировать и переименовать файл.

Самое смешное, что я думал: основной проблемой будет SQL‑запрос к MySQL. Использовал библиотеку mysql2 (https://www.npmjs.com/package/mysql2) — и тут всё завелось без единого сюрприза.

По вечерам изучал Rust.

Все курсы по Rust делятся на две крайности: либо для совсем новичков (что такое циклы, условия и переменные), либо сразу для матерых профессионалов — многопоточность, мультипроцессорные системы и прочая тяжёлая артиллерия. А мне нужно что‑то среднее.

Нашёл отличный курс «Программирование на Rust» (https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e). Лектор хорошо и подробно объясняет, постоянно сравнивает Rust с другими языками. Но есть нюанс — почти нет практики. А концепции в Rust хитрые, и без большого количества практики они просто не укладываются.

В какой‑то момент я поймал себя на вопросе: а почему вообще Rust?

Ответ для себя сформулировал такой: для расширения кругозора и понимания низкоуровневого программирования. И тут важно — низкоуровневое программирование не равно Rust. Полез дальше, нашёл лекции по C/C++ — буду осваивать их.

Да, Rust стоит на плечах C++, да, многие проблемы он реально решил. Но «упарываться» в Rust ради Rust я точно не собираюсь.

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

Про рабочие инциденты и обучение

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

Оптимизация телефонии

На работе у меня продолжается эпопея с оптимизацией телефонии.

Решил отключить ставшие ненужными телефонные номера. И, как это часто бывает, вместе с ненужными отключил очень даже нужные.

Самое интересное: крупный зелёный оператор официально отключает номера в течение 30 дней, но два нужных номера отключили уже через пару часов после официального письма.

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

Это были не критичные входящие номера, а номера из пула исходящих. Пул просто сократился с 18 до 16. Пользователи этого не заметили, никаких жалоб не поступало.

Тем не менее поволновался я изрядно.

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

Изучение C и низкого уровня

Параллельно начал изучать C и иду по курсу «Добрый, добрый C/C++ с Сергеем Балакиревым» на Stepik
https://stepik.org/course/193691/syllabus

Курс рассчитан на новичков, но при этом хорошо сбалансирован: без примитивности и без перегруза. Главное — много практики.

Прошёл пока около 10%, но уже достаточно глубоко погрузился в форматеры функций printf() и scanf(). С непривычки они даются непросто. Интересно, что похожий синтаксис спецификаторов используется и в современном Go.

Если кто-то считает, что C устарел — это не так. Он по‑прежнему жив и активно используется. По сути, C — это высокоуровневая обёртка над ассемблером, поэтому под микроконтроллеры до сих пор пишут именно на нём, и без понимания работы «железа» на низком уровне там не обойтись.

Отдельно для себя смотрю канал Olga Pavlova
https://www.youtube.com/@olgapavlova

После этого особенно хорошо видно, что USB и Wi‑Fi — далеко не простые протоколы.

Для меня это стало входом в совершенно новый мир низкоуровневого программирования.

Практика SQL

Также прошёл курс по SQL:
https://sql-academy.org/

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

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

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

Итог

В итоге всё это хорошо укладывается в одну картину: работа регулярно подкидывает неожиданные ситуации, а обучение помогает спокойнее к ним относиться и лучше понимать, что происходит под капотом. Чем глубже разбираешься в инструментах — от телефонии до C и SQL, — тем меньше сюрпризов и тем увереннее чувствуешь себя в повседневной инженерной рутине.

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

1. Как «умер» сервер бэкапов и почему мониторинг умер вместе с ним

Сначала «умер» сервер резервного копирования АТС Asterisk. Причём умер хитро: пинг есть, а всё остальное — нет. Попытки реанимации ни к чему не привели, поэтому принял волевое решение — переустановить систему с нуля.
Резервное копирование телефонии у нас устроено не самым тривиальным образом: бэкапы делаются через ZFS‑снапшоты файловой системы. Из снапшота можно восстановиться обратно — не быстро и не просто, но можно.
Есть нюанс: чтобы получить ZFS‑снапшоты на клиенте, ZFS должен быть и там. Раньше ZFS был корнем системы, теперь — просто отдельный пул. Нашёл рабочую инструкцию по установке ZFS на Debian 12 — «Install ZFS On Debian 12» https://blog.programster.org/install-zfs-on-debian-12, установил ZFS, настроил Zrepl — утилиту, которая вытягивает снапшоты с сервера. В итоге получил снапшоты за последний месяц.
И тут всплыла проблема мониторинга. Как узнать о недоступности сервера как можно раньше?
Раньше скрипт мониторинга создания снапшотов жил… на самом сервере бэкапов. Сервер умер — мониторинг умер вместе с ним. Классика.
Решение напрашивалось само собой: выносить мониторинг в Zabbix. Архитектура у него простая — центральный сервер и агенты на хостах, которые собирают метрики (CPU, память, сеть и т.д.). Обычно этого хватает, чтобы понять, что серверу плохо.
Но метрика «есть ли свежий ZFS‑снапшот» из коробки не поставляется. Пришлось добавить свою.
В Zabbix есть механизм пользовательских параметров (https://www.zabbix.com/documentation/2.0/ru/manual/config/items/userparameters) — можно самому описать метрику и определить скрипт, который возвращает её значение. В моём случае это проверка наличия свежего снапшота. На сервере Zabbix я повесил триггер: если снапшота нет или данных нет вообще (читай — сервер умер), значит пора бить во все колокола.
Посмотрим, как это покажет себя в бою.

2. Ночные обзвоны инженеров и иллюзия надёжности

Вторая проблема — сервис ночного обзвона дежурных. АТС звонит инженеру, зачитывает заявку и фиксирует его ответ. При этом сервисная система наивно уверена, что звонок всегда будет совершен.
А реальность, как обычно, сложнее: АТС может не дозвониться по тысяче причин.
Здесь я тоже решил «обмазаться» мониторингом через Zabbix, но уже другим способом. Не Zabbix собирает метрики, а скрипт сам отправляет их в Zabbix через zabbix_sender.
Например, если ночной звонок инженеру успешно отправлен:

zabbix_sender -z 192.168.0.1 -s "asterisk" -k call.ok -o 1

В чём разница с первым кейсом: там проверка идёт регулярно, а здесь звонки могут быть, а могут и не быть — и это нормально.
Но копнув глубже, выяснилось неприятное: АТС не возвращает в скрипт ошибку, если звонок реально не состоялся. Чтобы отследить факт реального звонка, нужно использовать AGI (Asterisk Gateway Interface), а это уже серьёзная переработка кода сервисной системы.
Мои метрики по факту мониторят результат работы скрипта, а не саму АТС. Не идеально, но всё же лучше, чем ничего.

3. Про обучение, ожидания и реальность

Прошёл тренажёр по SQL на sql-academy.org. Думал, сейчас ещё и сертификат дадут — но сертификаты только за деньги. Бизнес, ничего личного.
В итоге прошёл курс без сертификата. И, честно говоря, это вообще не проблема. Главное — знания. SQL я заметно подтянул: даты, аналитические функции, группировки, подзапросы — со всем этим теперь чувствую себя гораздо увереннее. Пробелы ещё есть, значит есть куда расти.
С курсом «Добрый, добрый C/C++ с Сергеем Балакиревым» вышло разочарование. Курс хороший, но он для новичков. Менять местами два числа и подробно разбирать if и while — занятно, но этот уровень я уже давно прошёл.
Поэтому переключился на «C++ базовый курс» на YouTube — https://www.youtube.com/playlist?list=PL3BR09unfgciJ1_K_E914nohpiOiHnpsK. Он как раз для тех, у кого C++ не первый язык. Курс хвалят, посмотрим.
Заодно глянул видео Антона Полухина «Незаменимый C++» — https://www.youtube.com/watch?v=LZflL44SVVY. Автор жжёт и пепелит: показывает, где C++ используется (спойлер — почти везде), и почему он выигрывает по производительности. Но честно говорит и о проблемах: высокий порог входа и вопросы безопасности. Отдельно хорошо объясняет, почему компилятору Rust до компилятора C++ ещё далеко — C++ компиляторы 30 лет пишут всем миром и оптимизируют огромное количество очень специфических кейсов.

P.S.
Во вторник у меня был день рождения — исполнилось 47 лет. Время летит всё быстрее, но с годами приходит спокойствие и понимание: многие ситуации уже видел, через многое прошёл и примерно знаешь, куда смотреть, когда что-то снова начинает ломаться.

Чем дальше работаешь инженером, тем чаще ловишь себя на простой мысли: поверхностных знаний уже недостаточно. Хочется понимать, как всё устроено внутри — от памяти и указателей до архитектуры приложений. Этот текст — заметки из очередной попытки копнуть чуть глубже.
Продолжил изучение низкоуровневого программирования.
Начал смотреть курс по C++:
https://www.youtube.com/playlist?list=PL3BR09unfgciJ1_K_E914nohpiOiHnpsK
Курс хороший, но объективно сложный. Он рассчитан на студентов МФТИ — победителей олимпиад, с сильной базой по C и математике. Уже первая домашка — вычислительная геометрия и пересечение трёхмерных треугольников. Вычислительная геометрия — точно не мой конёк.
При этом курс мне понравился. Преподаватель умеет объяснять сложные вещи просто и интересно — редкое качество. Поэтому сейчас смотрю его в «радио‑режиме»: для понимания общей теоретической базы, без попыток всё сразу воспроизвести на практике.
Отдельно зашла лекция про указатели. Особенно цитата:
«C++ может убить вашего котёнка, даже если у вас нет этого котёнка».
Очень наглядно про работу с памятью: можно освободить больше, чем у тебя вообще было.
Низкоуровневое программирование я бросать не собираюсь, но буду искать курс более адекватный моему уровню. Задача простая: понять базовые концепции и написать небольшой проект. Упарываться в хардкор на годы вперёд цели нет. Это обучение — для расширения инженерного кругозора.
Инженер, который ничего не изучает и ни в чём не разбирается, — мёртвый инженер.
Поэтому решил реализовать мечту детства — написать компьютерную игру. Остановился на классической игре «Память». Есть поле с карточками: можно открыть только две, если они совпали — пара исчезает. Игра простая, мегапроект не нужен.
В качестве движка выбрал Phaser:
https://phaser.io/
Пока изучаю плейлист «Phaser 3 Game Tutorial – Solitaire»:
https://www.youtube.com/playlist?list=PLmcXe0-sfoSh1o3fm-_2JOod-wRUxnqb_
И вот тут началось самое интересное. Игра простая, а вопросов сразу вагон:
как организовать конечный автомат состояний? какая будет система событий или команд? где проходит граница между логикой и рендерингом?
Решил, что игру буду делать под Telegram. И тут всплыли вопросы деплоя: как поднять сервер с игрой на Angie со SSL, как правильно подключить её к Telegram, как всё это обслуживать.
Заодно захотелось попробовать Claude. А как его настроить? А как встроить в процесс разработки?
В итоге парадоксальная ситуация: игра примитивная, а чтобы получить законченное решение, нужно приложить неожиданно много усилий. И, пожалуй, в этом и есть главный урок.
В итоге я в очередной раз убедился: такие эксперименты ценны не столько результатом, сколько тем, что они вскрывают по ходу дела. Даже простой проект довольно быстро показывает, где знаний не хватает, где инструменты упираются, а где архитектура начинает давать сбои. Поэтому я и продолжаю этим заниматься — спокойно, без спешки и иллюзий, воспринимая такие задачи как нормальную часть инженерного роста.

От дебага звонка до собственной игры в Telegram. Иногда кажется, что рабочий день - это просто череда мелких задач. А
потом внезапно понимаешь: ты уже три часа дебажишь звонок, который «не
идёт».

Asterisk и звонок напрямую
На работе столкнулся с занятной историей. Не мог позвонить на сотовый
номер по определённому транку. Перебрал параметры, покрутил настройки
- тишина.

В какой-то момент нашёл простое, но неожиданное решение для
тестирования: звонить прямо из командной строки.

 bash
asterisk -rx "channel originate SIP/89876543210@beeline application Playback demo-congrats"

Команда инициирует вызов и проигрывает файл. Никакой магии - просто
прямой вызов в Asterisk.

В итоге всё-таки дозвонился. Иногда лучший способ понять, что происходит
внутри, --- убрать всё лишнее и пойти напрямую.

Бэкап виртуальной машины в Proxmox
Ещё одна хитрая задача --- виртуальная машина в Proxmox с двумя дисками:
системный (Debian) и большой диск под бэкапы (scsi1). Нужно было сделать
резервную копию только системного диска.

Решение оказалось элегантным: остановить ВМ, временно удалить второй
диск из конфигурации, выполнить обычный бэкап через vzdump, а затем
вернуть диск обратно.

 bash
qm stop 100
qm set 100 --delete scsi1
vzdump 100 --mode stop --storage local --compress zstd
qm set 100 --scsi1 san01_lun1:0.0.1.scsi-3600000000000000000e0000000040001
qm start 100

В архив попадёт только первый диск. Минимум шаманства - максимум
контроля.

Memento mori - игра для Telegram
Параллельно начал делать свою HTML5‑игру для Telegram. Назвал её
«Memento mori».
Это небольшая казуальная игра на тренировку памяти: открываешь пары
карточек и стараешься уложиться в минимальное число ходов. Решил сделать
её в готической эстетике --- вампиры, скелеты, мрачная палитра. Почему
бы и нет.
Когда декомпозировал задачу, понял масштаб.

Что нужно собрать
- Telegram‑бот для запуска Mini App.
- Backend с авторизацией через Telegram и хранением пользователей и
результатов.
- Frontend с двумя сценами и игровым полем на Phaser.
- Лендинг для тех, кто зайдёт не из Telegram.
- CI/CD через GitLab, Docker Compose и SSL.
- Claude AI для помощи в разработке.
По отдельности всё выглядит просто. Вместе - уже задача со звёздочкой.

И самое забавное: взаимодействие с игровым движком - процентов десять
от общего объёма работ. Основное время уходит на инфраструктуру,
авторизацию, деплой и окружение.
Фронтенд и бэкенд решил писать на Next.js - один репозиторий, проще
отлаживать и поддерживать.

С Phaser поразбирался отдельно. Для React он ощущается как чёрный ящик.
Всё рисуется на Canvas. А Canvas - это просто растровое полотно:
браузер не знает ни про кнопки, ни про спрайты. Есть только картинка.
Нужно изменить сцену - перерисовываешь всё целиком.

Если нужно из React «достучаться» до игры - используешь ref.
Если из Phaser передать что-то наружу - EventEmitter.
Очень напоминает работу с фреймами в старые добрые времена.

Пока показать из кода особо нечего - только репозиторий:
https://gitlab.com/orion55/memento
Но картинки для двух уровней уже сгенерировал с помощью ChatGPT.

Чем дальше вникаю, тем яснее вижу: игра - это не про спрайты. Это про
архитектуру, окружение и десятки маленьких решений, которые должны
сойтись в одну систему. Дорогу осилит идущий.