ЦОДы и искусственный интеллект требуют колоссального количества электроэнергии - и желательно дешёвой. Согласно генеральной схеме размещения объектов электроэнергетики в нашей стране, планируется ввод внушительного объёма генерирующих мощностей(порядка 47 ГВт).

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

Привет, Хабр! У всех нас есть хобби, а выходные — самое время поговорить о своих! Не только о проектах, ИИ и о том, когда этот пузырь лопнет. Я 22 года играю на электрогитарах, и захотелось написать об этом статью — такой путеводитель по своему гитарному пути, учитывая, что в коллекцию недавно попал инструмент 1976 года выпуска.

Вспомнилось: как‑то я спросил у одного из своих техлидов, почему он так допоздна сидит и по‑прежнему что‑то пишет, создаёт свои пет‑проекты. Он ответ: «Это же моя первая любовь». Вот, наверное, про гитары я скажу так же.

Какие книги помогли мне перестать «тушить пожары» и начать управлять командой?

Как и многие инженеры – я никогда не хотел стать руководителем.  Как мне кажется, это процесс прошел со мной по инерции – сначала вырос как эксперт, потом доверили поуправлять проектами по поставке ТСО, затем уже отвечать за технологическое развитие компании и параллельно побыть директором дочернего общества.  Однозначно скажу, глядя сейчас на все то, что было сделано – ошибок было очень много, как и в плане управления проектной деятельностью (планирование, графики, бюджет, риски) так и в создании крепких команд.  И прочитай я книги из списка ниже раньше – уж точно сделал бы их меньше.

Меня на днях спрашивали: «А зачем я книгу написал?» Или: «Я слышал, что вы книгу написали, а о чём она?» Вопросы были разные, по большей части — с искренним любопытством, но и без ядовитых не обошлось — куда же без них! В моём личном топе — «А тебя заставили?» и «Ты решил всё бросить и уволиться?». Конечно, нет.

Сразу стоит сказать, что книгу нельзя назвать экспертной, т. е. посвящённой математическому моделированию, программированию или управлению проектами. И нельзя её назвать автобиографической, хотя я и рассказал много историй в художественной манере.

Книга — про философию и подход к делу, карьере и работе и (пафосно) — к жизни. Про то, что, на мой взгляд, остаётся неизменным, несмотря на технологический прогресс, ИИ и оцифровку всего и вся. Ещё раз взглянуть на те качества, которыми мы все обладаем, — инженеры, программисты, одним словом, творцы.

Если кто-то, прочитав книгу, прислушается и у него получится или, наоборот, не допустит моих ошибок, — то я считаю, что преуспел. А если и нет, то хотя бы пережил интересное приключение.

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

Как обучить работе с тренажёрами АЭС группу из 30 человек в Индийском технологическом институте Бомбея (IIT Bombay), если половина аудитории впервые слышит про атомную энергетику, а другая половина уже готова моделировать аварийные ситуации?

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

Но гладко было только на бумаге. На практике пришлось решать целый ряд задач:

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

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

Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.

В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.

Привет всем!

Ко мне часто обращаются молодые инженеры с вопросом: «А зачем вообще идти в аспирантуру?» Я обычно рассказываю, какие плюсы и минусы есть у такого шага — как учёба прокачивает навыки, помогает упорядочить знания и освоить грамотную постановку экспериментов. Но выбор каждому нужно делать самому, стоит ли прокачивать такие навыки или нет.

И вот во время одного такого разговора, погрузившись в воспоминания о собственных научных делах, я случайно наткнулся в интернете на хакатон. И угадайте, по какой теме? По диагностике асинхронных электродвигателей — прямо в точку! Своего рода - мой незакрытый гештальт во время собственного обучения.

Решили с товарищем поучаствовать. Правда, мы были вдвоём, а в команде могло быть до 9 человек. Спойлер: мы не взяли первое место и даже не попали в шорт‑лист из 9 команд — заняли 16‑е место из 35.

Да, это не история про успех, а про опыт — тот самый, который, как известно, «сын ошибок трудных». Главный урок прост: да, быть экспертом и действовать в одиночку — это неплохо. Но настоящая суперсила — в команде!

А теперь — обо всём по порядку…

В первой статье я уже говорил о своей любви к компьютерным играм — что, в общем‑то, неудивительно. Но всерьёз, вплоть до создания собственных небольших прототипов (так называемых демок), я занялся этим только в довольно зрелом возрасте — где‑то с 2021 года и до сих пор. Всё началось с того, что я открыл для себя мир Java: для моих программистских навыков он оказался на удивление простым. Ну и да, про 2 млн устройств — это, конечно, избитая шутка. Больше всего в разработке приложений на JavaFX меня впечатлила простота реализации: приложения получаются легко и быстро. Конечно, можно допустить ошибки, и тогда производительность окажется низкой. Но я по‑прежнему считаю, что это очень удобная технология для создания настольных приложений.

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

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

Эта статья продолжает цикл воспоминаний разработчика тренажёрных комплексов. Несколько лет назад наша команда столкнулась с задачей создания эмулятора автоматизированной системы управления технологическим процессом (АСУ ТП) для одной из тепловых электростанций. Задача выглядела стандартной и несложной: воспроизвести логику контроллеров, разработать мнемосхемы и запустить модель.

Однако реальность внесла свои коррективы. Исходных данных не хватало, сроки были крайне ограниченными, ресурсов недостаточно, а первая версия интерфейса HMI, созданная на собственном проверенном, но морально устаревшем инструменте проектирования, не соответствовала требуемым характеристикам производительности и масштабирования.

Цель настоящей публикации — поделиться опытом разработки эмуляторов АСУ для учебных тренажёрных комплексов, рассмотреть типы симуляций, привести пример архитектуры подобного решения, коснуться используемых технологий и языков программирования, описать часто возникающие трудности и предложить способы их преодоления.

Никогда не предполагал, что погружусь в математическое моделирование, компьютерные симуляции и прочие непростые материи. В планах было создавать компьютерные игры, грезил о том, чтобы играть тяжёлый металл — но уж никак не создавать какие‑то цифровые двойники. Однако жизнь, как выясняется, не то, чтобы сложнее, чем думалось, но куда интереснее. А может, просто страннее? Впрочем, это не важно.

Наверное, мой путь покажется довольно стандартным. Школа – университет – работа. Попробую немного рассказать про каждый из этих этапов.