О блоге

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

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

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

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

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

[prog.c++.flame^humour] Как хорошо, что я IDE не пользуюсь и не знаю, что такое бывает ;)

Подсмотренно в ТГ-чатике:

Ссылка: тыц, там же можно отследить и весь контекст.

Таки да, давным-давно работаю в gVim-е без плагинов. Вроде как полет все еще нормальный. Но я и не знаю, что именно упустил :)

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

А вот если бы программировал на C#, Kotlin и, особенно, на Java, то вряд ли бы без IDE обошелся.

На счет Rust-а не знаю. Язык более строгий и легче поддается парсингу со стороны IDE, если я все правильно понимаю, так что IDE может быть удобна в случае Rust-а. Но, как я слышал, многие пользуются Rust-ом и без помощи IDE.

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

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

Фильмы

Смотрите, как они бегут (See How They Run, 2022). Если черные комедии могут быть ироничными, то это вот тот самый случай. Кино, конечно же, специфическое. Но мне зашло, посмотрел с большим удовольствием.

В эфире (On the Line, 2022). Мне понравилось. Но только смотреть нужно до самого конца, каким бы невероятным не казалось повествование в середине.

Битва при Логнтане (Danger Close: The Battle of Long Tan, 2019). Средней руки военный фильм. Хотя на фоне современного киношлака выглядит вполне себе достойно. Доколупаться можно было бы до батальных сцен, т.к. меня a) не сильно впечатлили спецэффекты и b) атакующих вьетнамцев не стоило выставлять такими уж картинно несущимися навстречу неминуемой смерти идиотами.

Очень плохие парни (Big Bad Wolves, 2013). Не зашло мне это кино. В нем рассказывается о таких страшных вещах, в которые даже вдумываться не хочется, но снято это все как комедия. Черным комедиям есть место, но здесь, как по мне, грань разумного была оставлена далеко позади.

Покерфейс (Poker Face, 2022). Так себе кино. Как говорится, замах на рубль, удар на копейку: вроде бы завязка была многообещающей, а развязка оказалась вообще никакой.

Корабль в Пусан (Neukdaesanyang, 2022). Прежде всего это кино не имеет никакого отношения к отличному "Поезд в Пусан" с зомби. Здесь другие монстры, не зомби. Мог бы стать нормальным представителем жанра "кишки, кровь, расп*дорасило", если бы кровь в этом "кино" была бы похожа на кровь, а не на гранатовый сок.

Шесть минут до получночи (Six Minutes to Midnight, 2020). Картинка годная, содержание -- говно.

Наблюдающий (Watcher, 2022). Унылое и скучное говно.

Сериалы

Миссис Уилсон (Mrs Wilson, 2018). В кино рассказана очень интересная история, за которой хочется следить. Поэтому мне фильм зашел настолько, что даже не хочется обсуждать все остальное.

Игра на выживание (второй сезон). Если первый сезон понравился, то можно глянуть и второй. Есть шансы не разочароваться. Но мизерные. Я разочаровался. Если же первый сезон не понравился, то второй можно и не начинать.

[prog.c++] Погрузился в изучение Dear ImGui и вот что любопытно...

Возникла необходимость поверхностно освоить необычный (для меня лично) оконный фреймворк Dear ImGUI.

Очень прикольная штука.

Я в свое время имел опыт работы с GUI. Причем начиная от MS-DOS, в котором мы сами рисовали подобие Windows-овских окошек/менюшек/кнопочек/пр. в графическом режиме посредством Borland-овской BGI. И заканчивая работой с Qt и MFC, по дороге пройдя через стадию прямой работы с API MS-Windows и IBM OS/2 Presentation Manager, и даже делая какие-то свои библиотеки-обертки вокруг этих самых API. Кроме Qt и MFC доводилось знакомиться и с wxWidgets (тогда еще wxWindows), и с FOX Toolkit, и с FLTK (и даже со Swing-ом в Java). В общем, какое-то представление о том, как делается "традиционный" GUI, у меня когда-то было.

Но вот Dear ImGui, который реализует идею Immediate Mode GUI (акронимом чего и является IMGUI), -- это какой-то совсем другой зверь, диковинный и непривычный.

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

Однако, на написание поста толкнуло совсем другое впечатление.

Вроде как Dear ImGui вообще рисует все само: менюшки, окошки с заголовками и без, кнопочки, выпадающие списки и пр., и пр. -- это же все не имеет никакого отношения к нативным контролам конкретной ОС или оконного окружения.

И, что удивительно, пользователей Dear ImGui, судя по их скриншотам, коих предоставлено уже немало, эта "ненативность" внешнего вида не волнует от слова совсем.

Удивительно это для меня потому, что доводилось читать немало споров про выбор GUI-фреймворка для кроссплатформенных приложений и одним из требований (или одной из претензий) к существующим инструментам было то, что рисуемые GUI-фреймворком контролы визуально отличаются от нативных (т.е. родных для ОС).

Типа, вот Qt -- да, хороший фреймворк, но на такой-то платформе его кнопки отличаются от родных. И т.д., и т.п.

Я таких претензий никогда особо не понимал. Как по мне, так GUI-интерфейс должен быть продуманным и удобно заточенным под задачу. А само GUI-приложение должно быть отзывчивым. И если это так, что внешний вид контролов в GUI-приложении -- это уже мелочь.

И вот погружаясь в Dear ImGui с удивлением обнаруживаю, что есть люди, которые разделяют мои взгляды. Они просто берут Dear ImGui и решают свои насущные задачи. Не сильно беспокоясь о том, что сделанная в Dear ImGui программа отличается по внешнему виду от сделанной в wxWidgets или Qt.

Таки здравый смысл еще где-то остался. Что не может не радовать.

[prog] Что-то странное: появилось желание сделать реализацию MQTT v5 :)

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

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

Так что если мне задать вопрос "а над какой задачей было бы интересно поработать?", то я зависну на некоторое время и вряд ли смогу дать вменяемый ответ. А невменяемый мог бы звучать как "ни над какой" ;)

Но вот просматривая спецификацию MQTT подумал, что как раз сделать свою реализацию MQTT v5 было бы интересно. Причем как клиентскую, так и серверную.

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

Еще подумалось вот что: в конце 2016-го и начале 2017-ого мы в "СтифСтрим" решали какой еще открытый продукт родить, чтобы иметь в своем портфолио что-то кроме SObjectizer-а. И основных идей было две: либо какой-то MQ-шный брокер, либо встраиваемый в C++ приложения HTTP-сервер.

И мне сейчас кажется, что если бы спецификация MQTT v5 была доступна уже тогда, то, возможно, RESTinio бы и не случилось бы. Мог бы быть какой-то MQ-шный брокер на C++ на базе SObjectizer-а. Но тогда MQTT v5 еще не было, а делать свой брокер намного более простого MQTT v3 на фоне уже существовавших тогда альтернатив не выглядело перспективной затеей.

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

[prog.flame;humour] А ведь на самом деле интересно где же доказательства, что .NET и Java с GC лучше, чем Rust?

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

Вот, кстати, вспомнился еще один момент, который забавляет, когда Rust начинают противопоставлять Java и .NET-у.

Ведь в Rust-е же, по сути, такая же система управления памятью, как и в C++. Есть автоматическая память. Есть динамическая. В динамической есть аналог unique_ptr (Box), есть аналог shared_ptr (Rc, Arc).

Да, Rust следит за тем, чтобы вы корректно работали со своей памятью. Но ведь система не меняется. Либо ограниченное скоупом время жизни (автоматические переменные, Box), либо подсчет ссылок (Rc, Arc).

Но где же аргументы со стороны языков с GC о том, что подсчет ссылок -- это удар по производительности? Где убедительные бенчмарки, которые показывают, что стоимость аллокации в языке с GC -- это всего лишь инкремент одного указателя на вершину хипа? Где упоминание такой фундаментальной проблемы, как фрагментация памяти (которой, как все знают, подвержены поголовно все программы на C++)? Где напоминание о таком волшебном средстве, как compacting GC?

Где, где все те срачи, в которых сторонники Java и C# так яростно убеждали нас, что GC гораздо лучше для управления памятью, чем ручная работа? И не только с точки зрения безопасности. Но и с точки зрения производительности.

А?