О блоге

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

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

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

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

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

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

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

Фильмы

Поехавшая (2023). Хорошее, доброе кино. Меня, правда, местами раздражал клиповый монтаж (когда некоторые сцены слишком короткие), но удовольствия от просмотра это не испортило.

Ренфилд (Renfield, 2023). Нормальный такой образчик жанра "треш, угар" + "кишки, кровь, раз3.14дорасило". В качестве развлекательного аттракциона для просмотра с отключенными мозгами мне зашло. Но я и любитель такого жанра.

Горизонт в огне (Couleurs de l'incendie, 2022). Сказочка для взрослых (или не очень). Но зато очень красиво снятая.

Переводчик (The Covenant, 2023). Средней руки военный боевик с хэппи-эндом. На меня произвел не самые лучшие впечатления (хотя сделан добротно) т.к. от Гая Ричи ждешь большего. Ну и странно смотреть сказочку про спасение отдельно взятого коллаборанта после того, как американцы сбежали из Афганистана и оставили там без какой-либо помощи десятки тысяч подобных коллаборантов.

Подземелья и драконы: Честь среди воров (Dungeons & Dragons: Honor Among Thieves, 2023). Наверное, неплохой вариант для семейного просмотра с детьми младшего школьного возраста, особенно если они знакомы с настолкой "Dungeons & Dragons".

Экзорцист Ватикана (The Pope's Exorcist, 2023). Далеко не шедевр, но вполне себе крепкий образчик жанра. Так что любители фильмов про изгнание демонов могут смело смотреть: нового ничего не увидите, но и плеваться вряд ли будете.

Мизантроп (To Catch A Killer, 2023). Потенциально интересная история, которая была очень скучно и невнятно рассказана. Да еще и зачем-то приправлена повесточкой. Вот серьезно, не понимаю, что бы изменилось в фильме, если бы этого акцента на повесточке не было бы.

Мать (The Mother, 2023). Первая половина фильма, где и сосредоточен основной экшОн, откровенно слабая, но ее хотя бы можно смотреть. Вторая же половина редкостная муть. Смело можно пройти мимо этого фильма.

Сериалы

Перри Мейсон (Perry Mason, первый сезон, 2020). Снято красиво, актеры играют хорошо. Пожалуй, первый сериал после отсмотренного пару месяцев назад "Больница Никербокер", который по техническому исполнению и уровню погружения в происходящее может сравниться с "больницей". Но вот при попытке связать логически происходящие на экране события слишком уж часто возникает ощущение "ну что за фигня!" Что испортило впечатление от "Перри Мейсон" настолько, что второй сезон даже и не захотелось смотреть.

Мосгаз. Последнее дело Черкасова (2023). Не рекомендую. Даже тем, кому предыдущие сезоны "Мосгаза" зашли. Слишком уж много моментов, когда остается только риторически вопрошать "Ну как же так?"

Калейдоскоп (Kaleidoscope, первый сезон, 2023). Было пару прикольных моментов, которые мне понравились. Но в целом редкостная хрень.

[work] Заказчик открыл вакансию на проекте в котором я принимаю участие

Наш заказчик, компания VisionSmarts, разрабатывает новый продукт в области видеонаблюдения и IoT. Ключевой особенностью этого продукта является то, что конфигурация и логика обработки программируется на языке Python, что дает возможность гибкой настройки под различные условия и сценарии использования.

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

Проект включает в себя задачи по анализу видео- и аудио-данных, инфраструктурную часть по сбору этих данных и организации их обработки, UI-часть в нескольких вариантах (Desktop, Web). Я занимаюсь инфраструктурной частью и здесь уже пройден некоторый путь. А вот UI-часть находится на ранней стадии своего развития и именно в этом направлении сейчас лежит основной объем работ.

Под развитие UI и возможностей по скриптованию на Python компания VisionSmarts и открыла вакансию:

C++ VIDEO SURVEILLANCE & HOME AUTOMATION (WITH SOME PYTHON)

Разработка ведется на C++ (стандарт C++17) и Python. В качестве основных задействованных библиотек FFMPEG, SDL, Dear ImGui, SObjectizer, WebSockets++ и кастомная библиотека для поддержки такого понятия как "shared variables" и организации UI поверх Dear ImGui (в том числе и для remote UI). Для Web-интерфейса применяется WASM и emscripten. Текущие платформы Linux и Windows.

От себя добавлю, что поскольку проект исследовательский, то подразумевается большой объем самостоятельной работы. Задачи описываются "крупными мазками", т.е. обозначается проблема, для которой нужно найти и предложить решение, затем это решение нужно реализовать и протестировать. Что, кроме способности работать самостоятельно, требует еще и высокой квалификации, и ответствености.

Самостоятельность + ответственность требуются еще и потому, что проект разрабатывается небольшими силами: на пике над проектом работало до трех человек (включая меня) и сам заказчик. Значительную часть времени проектом занимался я один.

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

Специально подчеркну, что вакансия открыта у заказчика, а не у нас, обсуждать условия (в том числе и уровень оплаты) нужно непосредственно с VisualSmarts. Ну и стоит обратить внимание на вот эти важные моменты в описании вакансии:

• We are based in Belgium but you can be anywhere in the world (except countries currently hit with international sanctions).
• This is for a remote, part-time, freelance job. Only independent developers and small employee-owned firms please.

PS. Я сам в этом проекте уже почти два года, большей частью в качестве part-time разработчика.

[prog] Ошибочность ощущения что стал меньше ошибаться :)))

Когда я начал программировать, а было это уже давным-давно, то главным впечатлением было "как же много мы, люди, ошибаемся". Про древнее высказывание "Errare humanum est" уже тогда был наслышан, но не подозревал, насколько это верно :)

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

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

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

Сразу же приходит понимание, что это самое ощущение есть не что иное, как очередная ошибка.

Errare humanum est, короче говоря.

Так и живем ;)

[prog.c++] Так вот на счет AVChannelLayout...

...в качестве дополнения к этому посту: Хочется странного: особое отношение C++ного компилятора к структурам, объявленным как extern "C". Попробую вспомнить особенность перехода с FFMPEG 4.4 на FFMPEG 5.1, связанную с AVChannelLayout.

В текущем проекте нужно снимать видео/аудио потоки с камер посредством FFMPEG. В случае с аудио потоками бывает нужно один из них воспроизводить. Так же может потребоваться какие-то из них записывать (если записывать, то вместе с видео).

Приходить аудио может в разных форматах (благо FFMPEG отличается всеядностью), а вот для воспроизведения должен использоваться зафиксированный в коде формат. Для записи также должен использоваться зафиксированный в коде формат, но (ЕМНИП) не такой, как для воспроизведения.

Кроме того, снятые AVFrame протаскиваются через цепочку SObjectizer-овских агентов и i-й агент в цепочке, в принципе, может не иметь всей информации об исходном потоке и его состоянии. Т.е. агент, который напрямую дергает FFMPEG, обнаруживает разрыв и переподключение к камере (соответственно, у него пересоздаются AVCodecContext-ы), а вот последующие агенты могут информацию о переподключениях не получить и не узнать, что новые AVFrame содержат аудио-данные уже в другом формате.

В общем, говоря про код, есть две задачки: a) передать конфигурацию агентам, которые занимаются перекодированием аудио-данных (для воспроизведения или записи) и b) проверять формат аудио-данных в очередном AVFrame чтобы поймать момент внезапной смены формата (если таковая смена вообще происходит).

Для этого была сделана простая структурка, содержащая минимум полей: channel_layout в виде единственного std::int64_t, sample_fmt в виде AVSampleFormat и sample_rate в виде обычного int-а. В общем, тривиальный POD тип с constexpr-конструктором. Экземпляры этого типа используются и для того, чтобы зафиксировать формат аудио для воспроизведения/записи, и для того, чтобы сохранить информацию о параметрах текущего аудио-потока.

Благодаря тому, что описание формата можно было объявлять как constexpr константу, то в нескольких местах кода были сделаны static_assert-ы, для того, чтобы в compile-time проверять, что написанный под определенный аудио-формат код остается актуальным (т.е. если где-то описание формата вдруг поменяли, а код не поправили, то это будет обнаружено компилятором).

Все это хорошо работало потому, что в FFMPEG 4.4 количество и расположение аудио-каналов описывалось, по сути, единственным целым числом -- channel_layout. Иногда этот channel_layout мог быть нулевым (т.е. не заданным явно), тогда значение channel_layout можно было вывести на основании значения nb_channels.

Но вот в FFMPEG 5.1 целочисленное поле channel_layout задеприкейтили (но хотя бы поддерживают), и ввели новый тип данных AVChannelLayout, который является совокупностью из channel_layout+nb_channel из FFMPEG 4.4, но не только. Экземпляр AVChannelLayout теперь может содержать и дополнительную информацию. В том числе и информацию, которая расположена в динамической памяти, т.е. в AVChannelLayout может лежать и вполне себе владеющий указатель.

Поскольку сейчас AVChannelLayout -- это отнюдь не простая структура, то пришлось менять существующий в проекте тип, описывающий формат аудио. Т.е. поле channel_layout типа std::int64_t нужно было заменить на ch_layout типа AVChannelLayout.

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

[linux.kde] Способ восстановления после сбоя в Kubuntu 22.04 и KDE Plasma 5.24.7

Продолжение темы, начавшейся около месяца назад: [linux.kde.help-wanted] Столкнулся с проблемой в Kubuntu 22.04 и KDE Plasma 5.24.7.

Насколько я смог понять, проблема в падении kwin_x11.

Соответственно, чтобы восстановиться без перезагрузки системы нужно выполнить:

systemctl restart --user plasma-kwin_x11.service

Если есть возможность запустить kconsole, то это можно сделать прямо в сбойнувшей сессии. Если же такой возможности нет, то тогда по Ctrl+Shift+F2 заходим на другой терминал, логинимся и уже пробуем сделать это в новой сессии.

Так же, если через Ctrl+Shift+F2 зашли с другого терминала, то можно сделать:

DISPLAY=:0 kwin_x11 --replace

Только потом придется держать вход с этого другого терминала открытым :( Так что лучше все-таки, если сработает systemctl.

PS. Выяснить это удалось благодаря чистому везению. Однажды kwin_x11 сбойнул так, что KDE умудрился его рестартовать и сформировать отчет о сбое для отправки в KDE. Вот как раз в этом отчете получилось увидеть kwin_x11, ну а дальше поиск в Интернете... Как мне удалось понять, в Kubuntu 22.04 этот самый kwin_x11 сбоит у многих, я не один такой счастливчик. Остается надеятся, что пофиксят рано или поздно.