О блоге

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

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

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

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

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

[prog.history] Между тем COBOL-у исполняется 60 лет и исчезать он никуда не собирается

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

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

Свежая статья на тему COBOL-а: "COBOL turns 60: Why it will outlive us all"

А я нескромно дам ссылочку на аналогичную запись из этого блога, написанную к 50-летию COBOL-а. Там ряд интересных фактов приведен. Ряд из которых, наверное, продолжает оставаться актуальным до сих пор.

[prog.facepalm] Никогда такого не было и вот опять: Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.

Ну вот как же задалбывают горе-программисты, которые проповедуют вот такие взгляды:

Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.

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

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

В-третьих, если вы пишете прикладную программу, близкую к системной в плане управления ресурсами (веб-сервер, сервер БД), то у вас и так весьма особенные нужды в выделении памяти. Часто используются пулы, маппинг файлов/анонимной памяти прямо от системы. Куча в первую очередь интересна "совсем прикладным" программам, которым нехватка ресурсов неинтересна.

Уже столько раз эта тема поднималась, в том числе и мной в этом блоге (пример), что уже нет сил расписывать контраргументы в очередной раз.

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

Так что особого энтузиазма по поводу светлого будущего софтостроения я не питаю :(

[prog.memories] Vim, Ruby, Mxx_ru -- пятнадцать лет в пути...

Когда-то давно, в сентябре 2009-го года здесь появилась первая заметка про мое знакомство с ViM, Ruby и появление Mxx_ru: ViM, Ruby, Mxx_ru – пять лет в пути! Часть первая: Mxx_ru (вот вторая часть). Спустя пять лет вышло продолжение истории: Vim, Ruby, Mxx_ru -- десять лет в пути... И вот, спустя еще пять лет, можно написать очередную часть этой истории.

---

Итак, ViM. Все еще мой основной редактор для написания кода. Пользуюсь им и под Windows, и под Linux, и под FreeBSD. Под Linux-ом, кстати говоря, ViM как-то заметно шустрее работает.

Назвать себя продвинутым пользователем ViM-а не могу, знаю и применяю лишь некий базовый набор команд. Подозреваю, что лет 10 назад я знал про ViM гораздо больше. Но многие знания были утеряны за время менеджерства. Ну и сейчас программирование занимает далеко не 100% моего времени, так что надобности сильно погружаться в дебри ViM-а нет.

Тем не менее, с полной уверенностью могу сказать сейчас про себя: 15 years with Vim and steel learning :) And happy Vimmming!

---

Раздел второй, Ruby. В последний раз что-то более-менее серьезное писал на Ruby когда в начале 2016-го года добавлял в Mxx_ru поддержку работы с зависимостями (под условным названием MxxRu::externals). С тех пор пишу разве что небольшие одноразовые программки на выброс.

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

---

Раздел третий, Mxx_ru. Чем больше приходится иметь дел с CMake, тем больше радуюсь, что у меня есть Mxx_ru. Но, боюсь, радоваться мне остается недолго. В C++20 приняли какую-то (пока) неведомую для меня хрень в виде хитровывернутых модулей. Ну оно-то понятно, как можно в C++ добавить что-то понятное, простое и удобное? Очевидно, что никак. Такого не бывает, все должно быть через боль и страдания, это же C++...

Так вот, когда поддержка модулей появится в основных мейнстримовых компиляторах (т.е. VC++, GCC, clang), то придется делать выбор: либо допиливать Mxx_ru до поддержки C++ных модулей, либо полностью уходить с Mxx_ru.

И если год-два назад я был уверен, что серьезно ничего менять в Mxx_ru не буду, то теперь, после регулярного траха с CMake я уже не так уверен. Ибо выбирая между CMake и переделкой Mxx_ru мне уже не кажется, что разработка Mxx_ru-2.0 -- это рисковано, долго и дорого.

Так что если не найдется какая-то гораздо более вменяемая альтернатива CMake (в виде какого-нибудь Meson-а или GN), то вполне возможен сценарий появления на свет Mxx_ru-2.0.

---

Ну вот как-то так. 15 лет развития какой-то истории -- это совсем немало. Точно могу сказать, что затевая Mxx_ru в августе 2004-го года я вообще не надеялся на то, что этот инструмент проживет столько лет. Теперь уже и самому стало очень интересно, будет ли через пять лет продолжение. И если будет, то какое именно?

Жизнь покажет.

[prog.c++] Проверки на noexcept "для бедных"

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

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

В C++11 в этом направлении сделали важный шаг: добавили в язык спецификатор noexcept. Так что теперь из прототипа функции можно узнать о том, что она исключений не бросает.

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

void some_complex_class::cleanup() noexcept {    cleanup_part_one();    try {       cleanup_part_two();       cleanup_part_three();    }    catch(...) {} // Just ignore exceptions.    cleanup_part_four(); }

Можно легко накосячить.

[prog.c++] Небольшое, но важное обновление для SObjectizer-а.

Мы обновили SObjectizer до версии 5.6.1. Изменений совсем мало, просто дошли руки сделать фичу, которая не попала в релиз 5.6.0 из-за недостатка ресурсов при подготовке ветки 5.6. Но зато это первая версия, которая была разработана на GitHub после того, как Atlassian заявил о запланированном удалении Hg-репозиториев с BitBucket-а. Так что теперь дальнейшее развитие SObjectizer-а и so5extra будет происходить на GitHub-е, а SouceForge будет служить зеркалом для тарболлов.

Ну и по поводу дальнейшего развития SObjectizer-а нужно сказать важную вещь: в SObjectizer/so5extra мы реализовали практически все, что нам хотелось. Больше никаких серьезных нововведений не планируется. Мелкие дополнения и исправления будут время от времени вноситься, но появления больших фич, вроде msg_tracing-а, наверное, можно не ждать. Мы пока и сами не знаем, чего такого-этакого в SObjectizer можно (и нужно) добавить.

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

Ну, например, время от времени высказывается сожаление о том, что SObjectizer завязан на реализацию многопоточности из C++ной стандартной библиотеки. Т.е. на std::thread, std::mutex и вот это вот все.

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

Еще одно возможное направление развития -- это попытка адаптировать SObjectizer под нужды систем реального времени. В частности, введение таких механизмов в работу SObjectizer-а, которые бы не использовали динамическую память (либо использовали бы ее только во время старта). Но и здесь такая же ситуация: без конкретного "заказчика" ввязываться в такую серьезную переделку мы не готовы.

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

Сообщить нам о том, чтобы вы хотели видеть в SObjectizer-е можно через Issues на GitHub, соответствующую Google-группу, Feature Requests на SourceForge. Так же, напомню, что наша компания осуществляет поддержку SObjectizer-а и so5extra (как и других наших продуктов). Так что если вы хотели бы иметь кастомизированную версию SObjectizer-а под свои нужды или вам нужна наша помощью в разработке вашего продукта, то с нами всегда можно договориться ;)