О блоге

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

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

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

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

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

[prog.c++] Написал функцию с десятью(!) аргументами...

...и понимаю, что ничего хорошего в этом нет, но и лучшего решения не придумывается.

Вот как это выглядит:

Мое чувство прекрасного ущемлено и требует сатисфакции, но ничего лучше не придумывается :(

Проблема в том, что все аргументы обязательные. И когда они передаются в функцию вот так, то компилятор бьет по рукам когда что-то не указано (или указано что-то лишнее). А это полезно, поскольку код все еще активно меняется и параметров становится то больше, то меньше.

Была мысль посмотреть в сторону builder pattern. Но в C++ этот самый builder будет многословным. Плюс к тому придется делать проверки а все ли обязательные параметры заданы (а они все обязательные). Что негативно скажется на объеме builder-а. Посему не вариант.

Видимо, следует объединить несколько аргументов в разные структуры. Скажем, argv_0, python_log_collector, py_config и python_lib_path в одну, а ***_arena, params, shutdown_notificator и ***_interaction_points в другую. Но все равно это будет вести к распуханию вспомогательного кода, причем особой пользы от этого вспомогательного кода на данный момент не будет. Разве что это окажется задел на перспективу.

В общем к чему я это: рекомендации лучших собаководов о том, какой код clean, а какой нет, -- это, конечно, хорошо. Пока не сталкиваешься с суровой реальностью ;) В которой не знаешь как сделать лучше, а тратить время на эстетические изыски не вариант.

[prog.python.wtf] Понадобилось мне давеча разобраться с Python-овским io... И как-то оно что-то неожиданно непонятно. Вот совсем

В C++ приложение встраивается Python чтобы исполнять Python-вский скрипт прямо внутри приложения. Потребовалось сделать так, чтобы все, что Python-овский скрипт печатает в sys.stdout, отправлялось в C++ную часть.

Стал разбираться с Python-овским io.

Несколько раз проштудировал описание io в стандартной документации.

Мало что понял.

Что удивило. Т.к. пока читаешь, то вроде бы и буквы все понятные, и в слова понятные они складываются. А вот что к чему и почему... Все никак.

Гуглил, читал Stackoverflow, много думал :)

Но просветление не приходило.

Даже в исходники CPython заглянул, чтобы понять, как же вся эта кухня с IOBase, RawIOBase, BufferedIOBase и TextIOBase работает.

В общем, пришел к выводу, что мне нужен стандартный io.TextIOWrapper. В конструктор ему передается экземпляр стандартного io.BufferedWriter. А уже в конструктор io.BufferedWriter в качестве параметра raw передается экземпляр моего класса, наследника io.RawIOBase. Что-то вроде:

[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.

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