О блоге

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

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

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

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

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

[prog.flame.c++] Внезапное продолжение темы константности. Мои пять копеек к статье "const all the things" от Arthur O'Dwyer

Вчера написал небольшой блог пост с примером собственного стремления использовать const и иммутабельность как можно чаще. А сегодня на Reddit-е обнаружил ссылку на статью "const all the things" от Arthur O'Dwyer. Которая на ту же самую тему. И несколько противоречит моим предпочтениям.

Статья крайне толковая, очень рекомендую к ознакомлению.

Однако, как мне показалось, она написана с точки зрения человека, который пишет новый код. Если же попробовать взглянуть на те же самые аспекты немного с другой стороны, то по двум пунктам я с O'Dwyer-ом не соглашусь.

[prog] Деформация на почве иммутабельности

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

При программировании на C++ это выражается в том, что стараюсь по максимуму все объявлять const-ом и делать мелкие вспомогательные функции, которые не содержат внутри себя изменяемых переменных (это нужно для того, чтобы уменьшить количество переменных там, где эти мелкие функции затем вызываются).

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

Вот сегодня, например, попал на ревью такой код (схематично, к реальности имеет отношение только структура):

[prog.c++] Очень приятно. Да и не пустяк это вовсе

Простите, что опять про SObjectizer, но таки чертовки приятно:

Один из тех моментов в которые осознаешь, что все было не зря.

Кстати говоря, ребята, которые реализовали ту систему управления сценическим оборудованием, не особо афишируют для какого именно театра она была сделана. Мне же "по блату" намекнули и я до сих пор в нехилом апупении пребываю :) Вот даже и предполагать не мог где в итоге окажется частичка моих трудов.

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

Первый момент связан с тем, что мы, разработчики SObjectizer-а, практически не знаем кто, где, как и для чего SObjectizer применяет. Информация до нас если и долетает, то случайно и, что называется, задним числом. Что, в принципе, понятно: лицензия пермиссивная, можно брать и использовать, ни у кого разрешения спрашивать не нужно, ставить кого-то в известно необязательно.

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

Исключение пока что было только одно: более-менее приличное количество вопросов касательно SObjectizer-а назадавал один разработчик из Италии. А вот наши суровые парни, походу, сами во всем разбираются :)

Особенно сильно доставляют случаи, когда на меня выходят с вопросом из категории "нам вот такого вот не хватало, мы переделали кой-чего в потрохах SObjectizer-а и теперь хотим еще попробовать извратиться вот так вот, как думаете, получится?"

[prog.c++] Послесловие к релизу SObjectizer-5.7.3 и so5extra-1.5.0. С оглядкой на 20-летие проекта SObjectizer

Давеча удалось выкатить новые релизы для SObjectizer-а и сопутствующего ему проекта so5extra. Не могу сказать, что релизы знаковые, новых фич не так уж много. Но радует сам факт того, все-таки получилось обновить SO-5/so5extra (после безнадеги 2020-го и, особенно, 2021-го, годов).

Подробную информацию о том, что вошло в SO-5.7.3 можно найти здесь, а о том, что вошло в so5extra-1.5.0 -- здесь. Ничего революционного. Просто реализуются хотелки, которые накапливаются по мере использования SObjectizer разными людьми в разных условиях.

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

[prog.c++] В каком направлении можно было бы развивать SObjectizer, если бы представилась такая возможность

Если представится возможность продолжить работу над SObjectizer-ом, то там есть несколько направлений, в которые было бы интересно и полезно углубиться.

---

Например, одно из направлений -- это повышение уровня гарантий, которые SObjectizer предоставляет разработчикам. В частности, более строгое и формальное определение моментов и условий, в которых SObjectizer вынужден прерывать работу приложения через std::abort/std::terminate. А также проработка вариантов, которые бы позволили SObjectizer-у уменьшить количество случаев обращения к std::abort/std::terminate.

К сожалению, текущая реализация SObjectizer не всегда может восстановиться после ошибок и лучшее, что может сделать SObjectizer, дабы не оказаться в непонятно каком состоянии -- это вызвать std::abort (или std::terminate).

Когда SObjectizer применяется на server-side, это неприятно, но не сильно критично. Но вот при разработке GUI приложений такое поведение снижает коэффициент спокойного сна гораздо сильнее.

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

---

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

В этом направлении так же было бы интересно поработать. У меня нет желания адаптировать SObjectizer к задачам жесткого реального времени, да и сам по себе SObjectizer-5 к этому вряд ли пригоден. Но даже вне задач реального времени предсказуемый расход ресурсов может быть полезен. Например, в приложении возникает bad_alloc и нужно откатиться в какое-то безопасное состояние. При таком откате успешность других new, даже для маленьких по размеру объектов, не гарантируется, поэтому хотелось бы иметь возможность обмениваться сообщениями между какой-то группой агентов без скрытых где-то в потрохах new.

---

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