О блоге

Более тридцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

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

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

Вы художник? Бармен или музыкант? Или, может быть, коллекционер? Плотник или столяр? Кузнец или слесарь? Владеете маленьким магазинчиком или управляете большим производством? Реставрируете старинные часы или просто починяете примус? Всю жизнь занимаетесь своим любимым делом и хотели бы иметь фото на память?

Предлагаю сделать портрет в обстановке, связанной с вашей работой или увлечением. Абсолютно бесплатно. Очень уж мне нравится фотографировать людей в их естественной среде. Происходить это может так...

[prog.c++] Всегда удивляюсь, когда вижу имена членов класса без суффиксов/префиксов

Данный пост навеян фрагментом кода из свежей статьи на хабре "Анатомия граблей", а именно вот этим фрагментом кода:

class Foo {     int value; public:     Foo(int value) { // параметр затеняет поле class         value = value; // ничего не делает, присваивает параметр самому себе     } };

Честно говоря, мне дико видеть, что кто-то до сих пор использует имена членов класса без специальных префиксов/суффиксов. Вроде как очень и очень старый прием, которым я сам пользуюсь с середины 1990-х и который не только делает код читабельнее, но и защищает от подобных ошибок.

У меня бы было написано так:

class Foo {     int m_value; public:     Foo(int value) { // параметр ничего не затеняет         m_value = value;     } };

И подобная опечатка сразу бы оказалась видна.

Но если уж префиксы или суффиксы для членов класса оскорбляют ваше чувство прекрасного, то возьмите за правило обращаться к ним через this->:

class Foo {     int value; public:     Foo(int value) { // параметр затеняет поле class         this->value = value; // ничего не затеняет     } };

Тем паче, что обращение this-> зачастую бывает необходимо при написании кода шаблонов (например, когда шаблон класса наследуется от шаблона класса и обращается к унаследованным из базового класса членам/методам).

PS. Самая странная система именования членов классов, которую доводилась видеть, была такой:

class Demo { public:   int a; // Открытый член класса без префикса или суффикса. protected:   int _b; // А вот защищенные и закрытые члены с префиксом. private:   int _c; };

PPS. Касательно самой статьи "Анатомия граблей": она позиционируется как сборник C++ных граблей из области игростроя. Но практически все из описанного мне доводилось видеть в разнообразных проектах, которые к игрострою не имели никакого отношения. И какие-то из них (вроде выхода за границы статических массивов) не имеют дешевых решений, увы. По поводу же той части статьи, которая касается контроля за ресурсами и ручной работы с malloc/free, то слишком мало конкретики (плюс есть у меня подозрение, что в игрострое собирается публика, которой очень и очень фиолетово качество кода, но не факт, что подозрение верное).

[life.cinema] Очередной кинообзор (2026/08)

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

Фильмы

Кривые линии господа ("God's Crooked Lines" или "Los renglones torcidos de Dios", 2021). Однозначно самое интересное из увиденного за последнее время. Некоторые твисты ну очень классные. Правда, чтобы разобраться в том, что же было показано, пришлось гуглить. И результат поисков не то, чтобы меня порадовал, лично я увидел в кино совсем другой сюжет (чисто детективный, без сильной привязки к психиатрии).

Человек-паук: Новый день (Spider-Man: Brand New Day, 2026). Очень круто сделанный очередной кино-аттракцион для любителей супергероев из "вселенной Марвел". Строго для поклонников жанра.

Чокнутые (Riff Raff, 2024). Отличное кино, получил удовольствие от просмотра. Но мои вкусы несколько специфичны, поэтому сразу предупреждаю, что зайдет оно не всем.

Колония (Gunche, 2026). Если понравился "Поезд в Пусан" от этого же режиссера, то можно смотреть и "Колонию".

Замри (Don't Move, 2024). Ничего не ждал, но этот оказался вполне себе добротным фильмом. Далеко не шедевр, но смотреть было интересно и никакого отрицательного послевкусия не осталось.

Соулм8йт (Soulm8te, 2026). В принципе, снято очень даже неплохо. Но все портит абсолютная предсказуемость происходящего на экране.

Шёпот за окном (The Whisper Man, 2026). Хорошие актеры и неплохой сюжет, но когда начинаешь вдумываться в происходящее, то возникает слишком много белых пятнышек, которые непонятно как объяснить. Поэтому невольно задаешься вопросом "а не втирают ли нам здесь какую-то дичь?"

Коллектор ("The Dept Collector" или "Khon Dueat Thuang Khaen", 2026). В принципе неплохой боевик. Местами предсказуемый, местами не очень, местами впадающий в какую-то Санта-Барбару. Но мне показался несколько затянутым.

Последний дом (The Last House, 2026). Даже не смотря на то, что это фантастика, в некоторые моменты настолько не верится, что это напрочь убивает всю идею происходящего на экране и сильно портит впечатление от фильма.

Точка замерзания (Dead of Winter, 2025). Хорошие актеры, хорошо играют. Но в происходящее на экране не верится от слова совсем.

Та, что сбежала: История Кары Робинсон (The Girl Who Escaped: The Kara Robinson Story, 2026). Очень и очень бюджетно, что сказывается как на картинке, так и на актерской игре -- такое впечатление, что играет одна лишь главная героиня, а всех остальных набрали из массовки по объявлению. В общем, можно смело пройти мимо.

Семь снайперов (Seven Snipers, 2026). Редкая фигня не смотря на наличие хороших (в прошлом) актеров. Не тратить на это время ни в коем случае!

Сериалы

Парижская полиция 1910 (Paris Police 1910, 2026). Отличное продолжение отличного сериала.

Убийства в Оре ("Åre Murders" или "The Åremorden", первый сезон, 2025). Не смотря на то, что всего пять небольших по хронометражу серий, типичная сериальная затянутость все равно ощущается. Но именно к детективной составляющей претензий нет, у каждого расследования неожиданная развязка.

Лаки (Lucky, первый сезон, 2026). Ждал много большего, по факту же очень и очень средний уровень, может быть даже пониже среднего. Плюс традиционная сериальная затянутость, пару серий точно можно было бы выбросить.

Шугар (Sugar, второй сезон, 2026). Первый сезон был любопытный. А вот во втором ничего заслуживающего внимания нет. Пожалуй, единственное его достоинство -- это качественно сделанная картинка и несколько хорошо играющих свои роли актеров.

Подразделение специального назначения ("Elite Force" или "G.I.G.N", первый сезон, 2026). Ждешь жесткий боевик про крутых спецназовцев, получаешь какую-то унылую мелодраму.

Фильм вне категории

Майкл (Michael, 2026). Здесь разочаровало все -- начиная от сюжета и даже визуального ряда до попыток станцевать так же, как Майкл Джексон. Такое ощущение, что после Богемской рапсодии и РокетМена захотелось повторить тот же трюк с еще одной музыкальной суперзвездой. И, что самое страшное, это получилось с таким очень и очень никаким фильмом.

[life.memories] Ответ "А я не знаю" от преподавателя в университете

Посмотрел недавно ролик "Разбираем популярные манипуляции квантовых психологов. Алексей Семихатов и Виктория Шиманская" на YouTube (на RuTube пока нет, но, может быть, появится на этом канале). Очень понравился мне там момент в районе 41-й минуты, когда Семихатов сказал, что роль учителя в том, чтобы показать как вообще можно размышлять над сложной проблемой.

В этой связи (речь про хороших учителей) мне вспомнилось как на первом курсе универа я задал одному из преподавателей какой-то вопрос связанный с особенностью конкретного языка программирования и преподаватель просто ответил мне "а я не знаю".

Для меня это был шок и разрыв шаблона.

Потому что 10 лет до этого в школе нас натаскивали на то, что ты должен знать. Математические выражения, физические законы, химические формулы, исторические даты и вот это вот все. Ты либо знаешь и молодец, либо не знаешь и "садись, два!"

А тут раз, и "а я не знаю". От преподавателя. Который затем на сессии у тебя будет требовать знаний. Но который здесь и сейчас не может ответить на вопрос по предмету, который он же тебе и преподает.

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

И вот это вот осознание что не знать чего-то здесь и сейчас -- это нормально и естественно -- стало для меня откровением в далеком 1990-ом году. Именно не знать, а не подзабыть и вовремя не вспомнить. Невозможно знать все даже в теме, которой ты занимаешься много лет. Всегда можно столкнуться с собственным незнанием. И если такое произошло, то следует просто воспринять это как должное, разобраться в предмете и узнать что-то новое (даже если вскоре забудешь за ненадобностью).

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

[prog.sarcasm] Если долго сидеть на берегу, то можно увидеть как Erlang-еры...

...переписывают свой софт на Rust:

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Это слова Макса Лапшина, одного из самых известных пользователей Erlang-а в Рунете (ссылки на пару статей которого были даже у меня в блоге). Он же и автор мема о том, что писать на С++ -- это выгребать корки по утрам.

Сколько было в прошлом разговоров о том, насколько хорош Erlang и насколько Erlang подходит и для таких задач, где, казалось бы, C++у самое место, а не одному из самых медленных динамически-типизированных языков. И все это для того, чтобы в итоге отказаться от Erlang-а в пользу нативного компилируемого языка, прямого конкурента С++ по производительности и ресурсоемкости.

Upd.В этой теме на LOR-е еще прекрасное добавилось от Лапшина (это ответ на вопрос уперся ли Erlang в потолок производительности):

Во все потолки, какие можно было.
И производительность, и количество библиотек, и количество людей и всё прочее.
Когда стало ясно, что прийдется самому руками писать QUIC, тут я слегка устал от эрланга.
О перфомансе вида «принять 10 000 камер» и речи не идет, причем если бы не медленный сторадж, новый код можно поковырять и до 20 тыс (просто это не нужно).

При всем моем уважении к Erlang-у и людям, которые его создали, но такие факторы, как "производительность" и "количество людей", как по мне, так были очевидны много-много лет назад.

---

Если говорить серьезно, то когда вам повезло работать на проекте в течении 10-15-20 и более лет, то у вас есть возможность наблюдать за тем, как принятые вами же решения, которые когда-то давно казались крутыми и удачными, через годы не просто перестают такими быть, а нуждаются в замене на что-то, что сейчас кажется крутым и удачным (и далее по рекурсии).

[life.audiophile] Неожиданно приятное открытие в VE Megatron

Несколько лет назад попал ко мне в руки USB-ЦАП Megatron от Venture Electronics (хороший обзор на него можно посмотреть здесь: YouTube или RuTube). Попасть-то попал, но большую часть времени лежал без дела. По звуку с ним все OK, но требует, зараза, высокоомные наушники. Мои вкладыши на 300ом приходится слушать на минимальной громкости.

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

А вот буквально на днях случайно выяснилось, что по 3.5mm разъему Megatron поддерживает гарнитуру!

И это решило проблему, с которой мне приходилось мириться на протяжении многих месяцев. А именно: на работе я подключаю к компьютеру USB-ЦАП чтобы слушать музыку в наушниках. Но когда возникает необходимость рабочего созвона через какой-то мессенджер или Zoom/Telemost, то приходится переключаться на гарнитуру, которая втыкается в 3.5mm разъем компьютера. И это переключение я регулярно забываю делать. Не говоря уже о том, что сама по себе эта необходимость раздражает.

Но, к счастью, Megatron делает все эти манипуляции ненужными. Достаточно в 3.5mm разъем Megatron-а воткнуть наушники с гарнитурой, в 4.4mm (или 2.5mm) разъем -- наушники для музыки, а сам Megatron по USB подключить к компьютеру. И все. Слушаешь себе спокойно музыку (хоть из локального хранилища, хоть со стримминга), а когда нужно созвониться, то просто берешь другие наушники, подключенные к тому же самому Megatron-у и все.

PS. Почему для музыки и для созвонов разные наушники? Ну просто так получатеся, что дорогие динамики я не ставлю в наушники с гарнитурным кабелем. Эти кабеля не самые надежные и за пару-тройку лет выходят из строя (а то и раньше, тут как повезет с качеством самого гарнитурного блока). А менять кабель все-таки спокойнее, когда ты знаешь, что динамики дешевые и если случайно повредишь при разборке наушников, то сильно обидно не будет.