воскресенье, 3 июля 2022 г.

[prog.c++] Сперва набросал черновик класса с фоновой рабочей нитью, а потом понял, что не все так просто

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

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

Итак, было предложено что-то вроде вот этого:

понедельник, 27 июня 2022 г.

[quote] В склерозник: разница между мастерством и искусностью по версии Сирила Паркинсона

Когда-то в молодости, вскоре после окончания универа, повезло прочитать замечательную книгу Сирила Норткота Паркинсона "Законы Паркинсона". Книга сатирическая, но как в любой шутке там только доля шутки. Если кто не читал еще, то крайне рекомендую.

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

И тут вы должны задать себе фундаментальный вопрос: что такое искусность и мастерство? Чем эти качества отличаются одно от другого? Как заурядный служащий подымается наверх? И есть ли у него такая возможность?

Прежде всего - чем характеризуется мастерство? Умением сделать что-нибудь достаточно сложное. А искусность - это умение сделать что-нибудь сложное чужими руками. Музыканту достаточно его мастерства, дирижеру нужна еще и искусность.

Думаю, что тем людям, которые сейчас стоят перед решением продолжать ли им совершенствоваться в своей профессии или же идти в менеджмент (а это уже подразумевает переучивание на другую профессию) стоит ответить самим себе: что для вас важнее? Совершенствование вашего мастерства? Желание стать искусным?

четверг, 23 июня 2022 г.

[prog.c++.flame] Увидел на Хабре код, от которого меня лично слегка передергивает

Заглянул на Хабре в статью "Оптимизация GUI на Qt" (сам не знаю почему, т.к. на Qt уже очень давно не программировал). Увидел там пример кода... Это как раз образчик кода, от которого меня передергивает после многих десятилетий в программизме и опыта приведения в чувство чужих копролитов.

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

среда, 22 июня 2022 г.

[prog.management] Утащу к себе текст чужого поста из LinkedIn. Про влияние удаленки на проектные команды во времена COVID-а

Текст найден в LinkedIn вот здесь: цинк. Автор процитированного ниже Константин Владимиров:

Журнал Nature опубликовал прекрасное исследование об эффектах удалёнки. Исследовалось примерно 70000 сотрудников Microsoft.

The effects of remote work on collaboration among information workers

Там аккуратным научным языком изложено всё, о чём я кричал с 2020-го. Удалёнка имеет тактические плюсы, но за коротким подъёмом продуктивности следует спад коммуникации, дробление команд и потеря связности коллективов. После чего -- долгосрочное падение продуктивности.

От себя хочется добавить: после года удалёнки собрать большую мультикоманду заново уже очень сложно.

Допустим у нас есть 60 человек разбитые на 6 команд по 10 человек (скажем три команды разной разработки, а также валидация, аналитики, инфраструктура). Тогда при переходе на удалёнку вы через год получите примерно такой эффект:

(1) Общение между тремя командами разработки прекратится вообще. Всем очень повезёт если останется общение внутри команд (значит там были лидеры которые не дали сгнить хотя бы внутренней коммуникации). Никто в первой команде разработки не будет знать что делает вторая и как дела у третьей. Никакие специальные усилия не помогут: такие вещи как реальное состояние дел в разработке никто не оглашает на формальных митингах, этим делятся вполголоса у кофемашины. Больше кросс-командных удалённых митингов означает больше трескотни и больше спящих на этих митингах человек.
(2) Конструктивное взаимодействие между разработчиками и валидаторами может остаться только при личных контактах. Оно будет минимальным.
(3) Точно также прекратится конструктивное взаимодействие между разработчиками и аналитиками.
(4) Команда инфраструктуры замкнётся в себе и содержательно помогать другим командам оттуда будут разве что по старому знакомству.
(5) Никто не будет знать новых членов команд в том числе своей команды. Их ramp-up будет практически невозможен, т.к. в нём никто не будет заинтересован.

И самое плохое в таком состоянии то, что потом из него будет очень сложно собрать коллектив заново, потому что да, хождение в офис это принуждение и неудобство. Ваши же ключевые люди вам потом скажут "ну я же эффективен на удалёнке, вот баги хорошо решаю, не хочу обратно". А без них офис будет уже не тот. И гниение продолжится.


От себя добавлю вот что. Если мне не изменяет слероз, то Джо Армстронг, родитель языка программирования Erlang, считал одним из ключевых факторов успеха разработки софта для AXD301 то, что всю проектную команду удалось собрать в одном месте. Тем самым решив проблему эффективной коммуникации между разработчиками. Если кто-то не в курсе про AXD301 (а это прям-таки икона успешного успеха для Erlang-а), то вот здесь есть ссылки на разное по этой теме.

пятница, 17 июня 2022 г.

[work.open-source.anger] А давайте подсчитаем чужие деньги или почему не стоит смотреть зубы дареному коню

По случаю тяпницы позволю себе тригернуться на комментарий к последней статье о SObjectizer на Хабре. Вот этот комментарий:

Ещё б документация была б хорошая, а не вот это месиво доксигена. Ну и в туториалах на gh кросс-ссылки и вычитку английского, а то встречаются там местами штуки типа "бесплатных функций" (free functions).

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

среда, 15 июня 2022 г.

[work.self.promotion] Опытный велосипедостроитель открыт для заказчиков из РБ/РФ

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

И постоянно строил велосипеды, которые тут же шли в работу. За счет чего приобрел специфический опыт и навыки.

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

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

Открыт для предложений в виде контракта между заказчиком и СтифСтрим. Варианты войти наемным сотрудником в штат клиента на данный момент не рассматриваются.

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

Связаться со мной можно через eao197 на gmail тчк com. Если кому-то интересен профиль на LinkedIn, то вот.


Дабы не быть голословным по поводу опыта создания велосипедов вот несколько примеров "из недавнего":

  • timertt. С++ библиотека для поддержки таймеров. Реализует механизмы timer_wheel, timer_list и timer_heap. Позволяет поддерживать большое количество (миллионы и десятки миллионов) активных таймеров. С 2014-го года используется в SObjectizer.
  • so5extra. Набор прибамбасов для SObjectizer-а, вроде дополнительных типов диспетчеров, mbox-ов и пр.
  • easy_parser в составе RESTinio, который представляет из себя реализацию PEG-парсера на С++ных шаблонах и constexpr-функциях (в рамках C++14) Подробнее в основной документации или вот этих статьях: раз и два.
  • MxxRu::externals. Велосипед, который мы с 2016-го года используем для управления зависимостями в собственных C++-проектах. В отличии от conan, vcpkg и пр., он не требует предварительного опакечивания зависимостей. Ознакомиться можно здесь или здесь. Кстати говоря, MxxRu -- это также мой старый собственный велосипед (документация здесь).

Упомяну также arataga. Хоть это и не инструмент для разработчика, но лисапед, сделанный практически в одиночку под специфические условия.

Кому-то я известен по проектам SObjectizer и RESTinio. Эти все создано с моим непосредственным участием и под моим руководством.

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


Буду признателен, если вы сможете поделиться ссылкой на этот пост в своих соцсетях и/или распространить среди своих профессиональных контактов.

[prog.c++.sobjectizer] Обновленная версия моей самой первой статьи на Хабре

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

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

Так что вот: SObjectizer: что это, для чего это и почему это выглядит именно так? Взгляд из 2022-го.

Удивительными для меня оказались две вещи:

  • насколько мало изменений пришлось внести в текст исходной статьи. Не смотря на то, что SO-5.6/5.7 очень сильно в некоторых деталях отличаются от описанной шесть лет назад версии 5.5, потребовалось сделать всего несколько небольших правок в примерах кода. И вообще не пришлось ничего менять в описании ключевых аспектов. Т.е. за шесть лет эволюции что-то поменялось лишь в частностях, но осталось точно таким же в целом. Что просто здорово. Это дает надежду на то, что не смотря на развитие SObjectizer-5 уже на протяжении двенадцати лет, потенциал для дальнейшей эволюции у SObjectizer-5 еще есть;
  • насколько сложно оказалось написать послесловия. Потому, что я публично рассказываю в Рунете о SObjectizer, минимум, года с 2014-го, если не с 2013-го. И путь популяризации SObjectizer-а (если это вообще можно так назвать) отнюдь не был усыпан лепестками роз. Хотелось сказать и об этом, но, видимо, еще не пришло время, когда я мог бы спокойно об этом говорить. Поэтому послесловие вышло таким, каким вышло.

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

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

Просто в этот раз хотелось сконцентироваться на другом: проект живет уже больше двадцати лет. И пока у меня есть желание и возможность им заниматься. Поэтому проект все еще живет и все еще движется вперед.

Как оно будет дальше никому не ведомо. Два предыдущих года лучше всего показали как все (буквально все) может прекратиться в один прекрасный момент. Так что загадывать бесполезно.

Пока проект развивается. И это главное. Чего, собственно, от всей души желаю всем коллегам-велосипедостроителям, которые пилят свои собственные sobjectizer-ы и restinio не смотря ни на что. Просто потому, что могут и верят в полезность того, что делают. Не смотря ни на что, включая временную невостребованность и обливание известной субстанцией от доброжелательных всезнаек-всеумеек.

четверг, 9 июня 2022 г.

[prog.humour] В очередной раз пришло время штудировать собственную же документацию

Работаю над новой фичей. Для этого пришлось погрузиться в документацию по SObjectizer, в раздел по специфической и не самой тривиальной функциональности.

Документацию это писал сам, но уже не помню когда и как, поэтому читаю вообще как какой-то чужой текст.

Главная мысль: "Блин, надо бы основные моменты законспектировать..." :)

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

PS. За качество английского прошу не бить, пианист играет как умеет, google translate с grammarly на пару не смогли сделать лучше :)))

понедельник, 6 июня 2022 г.

[prog.work.humour] Баян, но прекрасный

FB напомнил запись от 2016-го года. Она и тогда была баяном, но за все это время своей актуальности не утратила:

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

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

пятница, 3 июня 2022 г.

[prog.c++.flame] Пример C++ного кода встретил в LinkedIn и в очередной раз убедился, что C++ придуман экспертами для экспертов

В ленте LinkedIn наткнулся на пост из категории "что делает этот код?". Разместившие этот пост товарищи заявили, что они типа работают на переднем краю и заинтересованы в C++Ninjas. Т.е., как я понимаю, им нужны крутые разработчики.

Код же вот такой:

#include <iostream>
#include <utility>
#include <tuple>

template<typename... Args>
void do_all(Args &&... args) {
    auto do_one = [count = sizeof...(args)](auto && arg) mutable {
        std::cout << arg;
        --count > 0 ? std::cout << "," : std::cout << "\n";
        return std::ignore;
    };

    (do_one(std::forward<Args>(args)) = ...);
}

int main() {
    do_all(123456789);
    return 0;
}

По горячим следам я начал писать пост о том, что если пытаться искать C++разработчиков, умеющих в такой код, то и будут найдены именно те, которые именно такой код и будут писать...

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

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

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

среда, 1 июня 2022 г.

[business.wow] Поиск клиентов через секс?

Каким-то чудным ветром занесло меня на запись лекции некого бизнес-тренера, личностного коуча и вот это вот все. Лекция для других бизнес-тренеров/коучей/вот-это-вот-все на тему того как искать и работать с клиентами.

На моменте рассказа о том, как искать клиентов звучит следующее:

"... Как я еще нахожу? Это через сферу досуга, наслаждения. Для меня это искусство, это секс, путешествия..."

Секс?

Для поиска клиентов?

Чего-то я явно не знаю о бизнесе :(


Комментариев под видео с лекцией нет, поэтому даже не знаю, заметил ли вообще это слово в лекции кто-то кроме меня :)

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

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

Фильмы

Глубже (2020). Кино специфическое, как и предыдущие работы Михаила Сегала. Но я посмотрел с удовольствием и мне зашло.

Ускользающий человек (Yucheitalja, 2020). Очень даже ничего. Бодренько. Однако, если вы с трудом отличаете одно корейское лицо от другого, то смотреть будет сложновато.

Diabolik (2021). Непонятно кому пришло в голову в XXI-ом веке сделать что-то в стиле "Фантомаса" и "Джеймса Бонда" из 1960-х, но смотрится это прикольно. А на фоне выходящего сейчас киношлака так и довольно достойно.

Святым тут не место (There Are No Saints, 2022). Суровый и жестокий фильм, с прилично сделанными экшен-сценами. Но вот между этими самыми экшен-сценами все настолько уныло и печально, что в фильме нет ни драйва, ни нерва, ни сопереживания кому-либо из героев.

Операция «Мясной фарш» (Operation Mincemeat, 2021). Снято красиво. Просмотр какого-то серьезного негатива не вызывает, но и не торкает. Да и сама история рассказана так, что остаются вопросы о том, а чья же основная заслуга в успехе описанной в фильме операции.

Фантастические твари: Тайны Дамблдора (Fantastic Beasts: The Secrets of Dumbledore, 2022). Откровенно слабое кино. Затянутое и скучное. Смотреть можно разве что тем, кто хочет узнать продолжение истории.

Затерянный город (The Lost City, 2022). Мне не зашло. Может быть в переводе потерялся весь юмор, может быть уже забыл (или не смотрел) фильмы, которые хотели обстебать в "Затерянном городе", может не в курсе повесточки, над которой пытались иронизировать, может быть неприятно было видеть Сандру Буллок, у которой практически никакой мимики на лице не было... Может быть и все вместе. В общем, мне не зашло.

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

Лулу и Бриггс (Dog, 2021). Унылая тягомотина ни о чем.

Сериалы

Триггер (первый и второй сезоны). Посмотрел с интересом и, по большей части, с удовольствием. Хорошее впечатление немного испортило то, что в последние две серии второго сезона налили уже слишком много соплей. А так все достаточно бодренько.

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


Несколько дополнительных слов по поводу "Операции 'Мясной фарш'".

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

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

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

Ну и отдельно доставило то, что несмотря на присутствующий в фильме пафос, складывается ощущение, что основная заслуга в том, что высшее командование Германии поверило в высадку англичан в Греции, принадлежит не разрабатывавшим операцию "Мясной фарш" англичанам. А высокопоставленным немецким офицерам разведки, которые были против Гитлера и, зная про дезу, все-таки доложили Гитлеру именно то, что было нужно англичанам. В общем, а кто же настоящий-то герой?

среда, 25 мая 2022 г.

[prog.history] Пара баек от Вальтера Брайта на тему жизы

Нашел прикольное на просторах Интернета, решил поделиться. Обе байки от Вальтера Брайта.

Байка первая:

Компилятор Optimum C обошел все остальные компиляторы в бенчмарке в одной журнальной статье потому, что Optimum C обнаружил [посредством анализа потоков данных, eao197] мертвый код бенчмарке и просто выбросил этот мертвый код. Автор статьи ничего не спросил у меня [т.е. у В.Брайта, eao197] и посчитал, что это баг, поэтому дал плохую оценку компилятору.

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

Байка вторая, про ошибку с маркетингом:

Мы распространяли исходный код [стандартной, eao197] библиотеки вместе с компилятором, совершенно бесплатно. Но ни один из обзорщиков не обратил на это внимания. В один прекрасный день Borland начал распространять исходники своей библиотеки (за исключением того, что относилось к поддержке чисел с плавающей запятой) за дополнительные деньги. Это сразу же упомянули в заголовке следующей статьи со сравнением компиляторов. Но не указали, что полные исходники всей библиотеки, включая поддержку чисел с плавающей запятой, входят в состав нашего компилятора.

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

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

PS. Для тех, кто не знает: Вальтер Брайт -- это автор известных в прошлом компиляторов Zortech C++ и Digital Mars C++, а сейчас он более знаменит своим языком D.

[prog.c++] В склерозник: ссылки на тему std::launder

В процессе копания темы передачи C++ объектов через разделяемую память возникли подозрения, что где-то мы с placement new работаем не корректно. Пришлось погрузиться в изучение std::launder.

Все, что связано с std::launder для меня какая-то мутная тема, с которой никогда толком не связывался. А тут пришлось. И выяснилось, что толковой информации не так, чтобы много.

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

Если нарою что-то еще, то дополню список.

понедельник, 23 мая 2022 г.

[work] Не, я так себя продать бы не смог

Сегодняшнее из LinkedIn-овской ленты:

Я бы так сам про себя не смог.

Тем более, что своего YouTube-канала у меня-то и нет :(

Да и 100% покрытие юнит-тестами не считаю ни достоинством, ни самоцелью.

В общем, продажник из меня еще тот. OpenSource проекты продать не смог. Вряд ли и самого себя продам. Тем более в такой красочной обертке ;)

Хотя в связи с проблемами прохождения платежей из EU в BY вопрос продажи собственных могзов в РБ/РФ становится все более актуальным. Но, если все продолжит идти по плохому сценарию, то будет отдельный рекламный пост (проплаченный мной, естественно).

суббота, 21 мая 2022 г.

[prog.c++] На github-е обнаружился проект, написанный на базе SObjectizer. Написанный не мной ;)

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

Вот давеча я совершенно случайно обнаружил на GitHub-е проект, который был написан с использованием SObjectizer: https://github.com/WinterLab-Berlin/LabNet.

Прикольно. Любопытно посмотреть как совершенно незнакомые тебе люди программируют на твоем инструменте :)

Но что меня все еще удивляет и сильно радует, так это то, что в очередной раз кто-то взял SObjectizer, самостоятельно разобрался, самостоятельно сделал работающий проект и ни разу не обратился за помощью.


Прошу простить мне эту минутку самопиара, но, блин, за последние лет 8 я столько раз слышал в свой адрес "ты делаешь образцовое нинужно, которым никто не пользуется", то промолчать и не поделиться радостью не смог :)

среда, 18 мая 2022 г.

[prog;work;life] Уже двадцать лет занимаюсь проектом SObjectizer

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

Релиз приурочен к двадцатилетию проекта SObjectizer: самая первая версия SObjectizer-4 была сделана в апреле 2002-го года, а уже в мае 2002-го SO-4 начал использоваться для разработки софта.

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

Сейчас же нет ни сил, ни желания, ни настроения делать это.

Тем не менее, рад, что пройден такой путь. Проект живет, проект используется.

Огорчен тем, что не смог сделать SObjectizer популярным. Поэтому имею лишь то, что имею.

Для меня главной целью работы над SObjectizer-ом было создание продукта, за который не стыдно. Это получилось. Об остальном остается только сожалеть, но сожаление неконструктивно.

Основное чувство сейчас -- это большая усталость.

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

Про будущее проекта сейчас загадывать что-либо бессмысленно, последние несколько месяцев лишний раз доказали актуальность мудрости "Хочешь рассмешить Господа Бога -- расскажи ему о своих планах."

В общем, первые двадцать лет позади. Посмотрим, что будет дальше. Самому интересно :)

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

Большое спасибо всем, кто рискнул попробовать SObjectizer в своих проектах. Знаю, что не все остались этим опытом довольны, но все-таки надеюсь, что положительного опыта было больше.


PS. Если кому-то интересно почитать какую-то развернутую ретроспективу, то можно глянуть пост, посвященный 10-летию развития SObjectizer-5. Все основные моменты уже были описаны там.

понедельник, 16 мая 2022 г.

[prog.flame] А вот мне интересно, как бы вы отреагировали если бы на собеседовании...

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

У меня есть сильное подозрение, что вы будете плодить код, от которого пришедшие на ваше место будут плеваться. И, вероятно всего, вполне оправдано.

На что соискатель бы вам ответил:

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

Мне вот интересно, кто бы из читателей блога дал бы согласие взять такого соискателя в свою команду (в свой коллектив)?

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

суббота, 14 мая 2022 г.

[prog.c++.idiotic] Вот вы программируете на C++ в 2022-ом и не знаете, что ваши причендалы в опасности

LOR-овские ысперды на линии:

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

пятница, 13 мая 2022 г.

[open-source.sad-humour] Идея о том, как заставить платить за поддержку и развитие OpenSource проекта

Навеяно вот этим, и вот этой статьей на Хабре: Что происходит с лицензиями в open source.

Современная ситуация, действительно, несколько странная и, на мой взгляд, не нормальная. Мир все больше и больше зависит от OpenSource, но вот платить за его развитие хотят и могут не только лишь все. Точнее мало кто вообще это делает.

И если для крупного OpenSource, масштаба GCC или KDE, все еще не так печально (как мне кажется), то вот для мелких OpenSource-проектов с условной тысячей звезд на GitHub-е и несколькими десятками внедрений хоть сколько-нибудь радужных перспектив нет от слова совсем.

К чему-то это в конце-концов приведет, но вот к чему и когда? ХЗ.

Однако, по поводу тяпницы, да еще и дня программиста (да-да, сегодня тяпница-тринадцатое, наш неформальный праздник!) позволю себе поделиться одной странной идеей.

Года три назад помогали одному клиенту привести в чувство старую программулину. У которой не было никаких тестов.

Ну т.е. вообще никаких. Ни unit-тестов, ни каких-либо тестовых скриптов, ни каких-либо тестовых/имитационных стендов. Вообще Н-И-Ч-Е-Г-О.

Признаться, я такого с 1990-х не видел.

Внесение изменений в код было похоже на ходьбу по минному полю :)

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

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

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

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

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

среда, 11 мая 2022 г.

[prog.thoughts] Теряет ли сеньор свою сеньористость если кардинально меняет свой технологический стек

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

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

суббота, 7 мая 2022 г.

[prog.c++] Еще один связанный с многопоточностью баг

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

Итак, есть объект acquisition_manager, который владеет несколькими acquisition_thread. Передача информации между acquisition_manager и acquisition_thread происходит через объекты gate: для каждого acquision_thread создается своей gate, ссылка на который отдается в конструктор acquision_thread.

Периодически acquision_manager наполняет объекты gate параметрами, после чего дает сигнал acquision_thread выполнить нужную работу и поместить в gate результаты, а когда acquisition_thread завершает свою часть работы, то acquisition_manager забирает результаты из все того же объекта gate.

Для взаимодействия между acquisition_manager и acquisition_thread у класса acquisition_thread есть методы:

пятница, 6 мая 2022 г.

[open.source] Простите, что-то меня триггернуло нипадецки

Сегодня увидел на RSDN:

цинк. Речь идет о наследии Сергея Садовникова, который ушел из жизни от ковида два года назад.

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

Попробую не скатываться в русский матерный и кратко поделюсь личным опытом.

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

Это нифига не сработало. Никто не хотел (и не хочет) ничего платить (было всего лишь одно или два исключения).

Мы попытались двигать один из продуктов под двойной лицензией. Со стоимостью лицензии на одного пользователя всего в 80USD за год.

Это нифига не сработало. Никто не хотел ничего платить.

В конце-концов в 2021-ом году я пустился на совсем уж вынужденный шаг и стал просить у крупных компаний спонсорской помощи на развитие OpenSource. Хотя бы в размере 200USD в год.

Это нифига не сработало.

Соответственно, мы делали и, местами, еще делаем собственный OpenSource исключительно за собственный счет.

На энтузиазме.

И когда этот энтузиазм иссякнет или, скажем, я уйду из жизни так же внезапно, как и Сергей Садовников, то и наши OpenSource проекты повиснут в воздухе. И, не исключено, что кто-то на каком-то профильном форуме напишет "вот вам и опенсорц от энтузиастов", но уже про SObjectizer или RESTinio.

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


На правах проплаченной рекламы: возможно кому-то пригодятся услуги паталогического велосипедостроителя и хронического программиста-камиказде, в анамнезе которого есть SObjectizer, RESTinio, json-dto и arataga. Как говорится, друг все еще интересуется...

понедельник, 2 мая 2022 г.

[work] А что на рынке труда в РФ сейчас и в ближайшем будущем?

Тут друг интересуется (с): нужен ли в текущих условиях кому-то из российских заказчиков хронический программист-камикадзе с врожденным синдромом велосипедостроителя?

Можно предположить, что России сейчас в области ИТ нужно будет много чего своего. Именно своего. Всякого-разного, но своего. От больших банковских систем до мелочей типа grep. Вроде спрос на толковых программистов должен был бы быть.

С другой стороны, можно предположить и то, что в РФ сейчас освободится некоторое количество рабочих рук, которые раньше работали на западных заказчиков, но эти самые западные заказчики будут сворачивать свое присутствие (как из-за санкций, так и из-за ухудшения ситуации на самом Западе).

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

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

PS. Вопрос пока больше гипотетический, нежели практический, но кто ж знает, не встанет ли он ребром уже через пару-тройку недель :(

Upd. Изначально вопрос был гипотетический, но он довольно резво начинает обретать практическую направленность, т.к. уже обозначаются проблемы с получением USD из-за границы на наш текущий счет.

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

Традиционно в начале перечислены фильмы/сериалы, которые понравились больше. А в конце -- откровенный шлак, который можно и не смотреть вовсе.

Но, в данном конкретном случае, можно вообще ничего не смотреть. За исключением "Анчартед", да и тот под большим вопросом.

Бонусом в конце поста идет мое личное мнение по поводу недавно вышедшего российского "Мистер Нокаут".

Фильмы

Анчартед: На картах не значится (Uncharted, 2022). Про игру, по мотивам которой снят фильм, ничего не знаю. Как кино же получился неплохой приключенческий аттракцион для детей от 6 до 12 лет. Ну или для веселого семейного просмотра.

Скорая (Ambulance, 2022). Тупо и неинтересно. Плюс чрезмерное увлечение клиповым монтажом из-за чего местами следить за картинкой было тяжело и переключения планов откровенно раздражали и утомляли.

Бэтмен (The Batman, 2022). Унылое мрачное говно ни о чем.

Сериалы

Тот, кто убивает — Узник тьмы (Den som dræber - Fanget af mørket, сезоны 2019 и 2021). Первый сезон смотреть было интересно до последней серии. Последняя же серия в первом сезоне выглядит откровенно халтурно. Второй сезон более нудный и скучный, чем первый. Финал второго сезона, по традиции, слили.

Топи (2021). Редкой укуренности шняга. Главная мысль при просмотре: "Как? Ну вот как на это кто-то выделил деньги? И как в этом всем кто-то согласился участвовать?"


Отдельно хочется отправить тугую струю известной субстанции авторам откровенного высера под названием Мистер Нокаут про выдающегося советского боксера Валерия Попенченко. Это настолько дерьмовое дерьмо, что я даже досмотреть не смог, ниасилил.

Дело в том, что мне повезло в детстве прочитать книгу Попенченко "И вечно бой". А после попытки просмотра "Мистер Нокаут" нашел ее в Интернете и перечитал.

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

Что явно намекает, что Попенченко был, мягко говоря, далеко не дурак.

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

Короче, к чему я это все?

К тому, что в реальной жизни Валерий Попенченко был умнее половины съемочной группы "Мистера Нокаут" вместе взятой. А может и всей съемочной группы. Но в фильме он был показан каким-то откровенным идиотом, главным раздражителем для которого является кличка "Пельмень".

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

В общем, не смотреть ни в коем случае.

А чего бы я лично пожелал "Мистеру Нокауту", так это того, чтобы BadCommedian проехался по сему высеру так же, как он это сделал по "Движению вверх".

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

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

Традиционно в начале перечислены фильмы/сериалы, которые понравились больше. А в конце -- откровенный шлак, который можно и не смотреть вовсе.

Фильмы

Человек-паук: Нет пути домой (Spider-Man: No Way Home, 2021). Очень круто сделанный очередной кино-аттракцион для любителей супергероев из "вселенной Марвел". Строго для поклонников жанра. Ставлю так высоко в списке просто потому, что реально круто сделан.

Грабитель банков (A Viszkis, 2017). Мне зашло. Но, скорее всего лишь потому, что это европейское кино, которое по стилистике сильно отличается от голливудского. И еще потому, что в фильме нет положительного главного героя. В целом же рекомендовать его сложно, т.к. это не "драйвовый боевик", а довольно таки неспешная биографическая драма.

7 ящиков (7 cajas, 2012). Интересно было посмотреть как снимают кино на совсем другом конце Земли. В общем-то неплохо снимают, хотя уровень конечно далеко не тот. Но тут хотя бы историю рассказали, за развитием которой было интересно наблюдать.

Проект "Адам" (The Adam Project, 2022). Незамысловатое кино для семейного просмотра с детьми младшего школьного возраста.

Черный краб (Svart krabba, 2022). В принципе, смотреть было интересно. Но после просмотра осталось ощущение, что с сюжетом авторы сильно недоработали и не удосужились раскрыть предысторию происходящего на экране. За что фильму очень жирный минус.

Внезапная удача (Windfall, 2022). Пара хороших актеров, интересная задумка, но очень нудное и скучное воплощение, да еще и финал оказался "несколько предсказуем" (с). В общем, на случай, когда смотреть больше нечего.

Под прицелом (First Date, 2020). Хорошая задумка, но что-то не получилось и в целом фильм производит впечатление "ну так, на троечку". Лично мне не понравился подбор актеров, такое ощущение, что создатели угадали с подбором исполнителей всего лишь на одну-две роли, а действующих персонажей там гораздо больше.

Игра теней (Blacklight, 2022). Откровенная халтура. Смело можно не смотреть.

Падение луны (Moonfall, 2022). Днищенское дно. Полный бред, пресыщенный пафосом. Даже спецэффекты вызвали неоднозначное впечатление: где-то все OK, а где-то съемки на фоне хромакея просто бросаются в глаза.

Сериалы

Каштановый человечек (The Chestnut Man, 2021). Мне понравилось. Интересно и динамично.

Джонатан Стрендж и мистер Норрелл (Jonathan Strange & Mr Norrell, 2015). Интересно, отличный подбор актеров. Но все-таки этот сериал для любителей жанра фэнтези.

Карамора (2022). Красочно. Кровь, кишки, сиськи. Все очень бодренько, скучать не приходится. Но, по факту, редкостная дрянь.

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

Традиционно в начале перечислены фильмы/сериалы, которые понравились больше. А в конце -- откровенный шлак, который можно и не смотреть вовсе.

Фильмы

Аллея кошмаров (Nightmare Alley, 2021). Сильно двойственные впечатления. С одной стороны, просто шикарная картинка, отлично играющие актеры, стройный сюжет, в котором все логично проистекает одно из другого. Но, с другой стороны, происходящее не цепляет, а весь сюжет быстро оказывается "несколько предсказуем" (с). Поэтому смотреть приятно, но не интересно, а уж как-то сопереживать происходящему так и вообще не хочется.

Этика долга (2022). Хорошо снято, смотреть интересно. Но! Во-первых, это нифига не комедия. Это тяжелый и трагичный фильм. Во-вторых, на экране творится жесть. Не в плане обилия крови и жестокости, а в плане того, что все развивается от плохого к худшему. И мне сложно рекомендовать его к просмотру, особенно чувствительным натурам.

Грань времени (Synchronic, 2019). Скучновато. Бюджетненько. Но, в общем-то, не так уж и плохо, по нынешним-то временам.

Пылающее море (Nordsjøen, 2021). Примитивно, прямолинейно и предсказуемо. Но, местами, снято красиво.

Одинокий волк (Clean, 2020). Атмосферно, но затянуто ну просто неимоверно. Тот случай, когда содержимое 1.5 часов фильма можно было бы вместить в 15-минутную короткометражку. Смотреть такое или нет решать каждому самостоятельно, но я бы посоветовал обратить внимание на данное кино разве что если больше смотреть вообще нечего.

Код 355 (The 355, 2022). Кому-то очень хочется снимать типа эпичные типа боевики про то, как некий чисто бабский батальон спасает весь мир. Вот и очередная потуга на эту тему. Снято красиво, но воспринимать всерьез происходящее на экране невозможно.

King’s Man: Начало (The King's Man, 2021). Редкая бредятина. Да еще и занудная до безобразия: ни тебе динамики, ни тебе юмора. А уж вольная интерпретация реальных исторических событий, так вообще выглядит как контрольное изнасилование мозга. В общем, не тыкать в это даже трехметровой палкой!

Сериалы

Двойник (Counterpart, 2018, второй сезон). Если первый сезон понравился, то второй стоит смотреть обязательно, т.к. он расставляет все точки над сюжетными линиями, начатыми в первом сезоне. Однако, как и в первом, последние три-четыре серии превратили все происходящее в подобие сопливой мелодрамы. Если же первый сезон не понравился, то нет смысла смотреть второй, он такой же, как и первый.

Архив 81 (Archive 81, 2022, первый сезон). Не понравилось. Затянуто, неинтересно и не страшно.

четверг, 28 апреля 2022 г.

[life] Очередная сотня дней в этой странной истории

Эту историю я когда-то озвучивал в FB, но т.к. в FB я появляюсь редко и практически в режиме read-only, то повторю ее в блоге.

Если мне не изменяет склероз, то Yandex.Music стал пользоваться в 2019-ом. И не сразу, но обратил внимание на то, что у "Плейлист дня" есть счетчик. И что этот счетчик то растет, то сбрасывается.

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

Начал этот эксперимент.

Довел счетчик где-то до значения 330.

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

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

Посему в октябре 2020 эксперимент возобновился. И желаемый результат был успешно достигнут через год, в октябре 2021-го.

Потом встал вопрос: и что дальше?

Дальше решил продолжать, но уже не ставя никаких рубежей. Просто интересно было посмотреть, куда это все заведет.

Завело вот к рубежу в 600 дней.

Честно говоря, особо говорить об этом не хотелось. Но кто знает, как будут развиваться события дальше? Будет ли возможность еще слушать Yandex.Music? Будет ли еще Yandex.Music? Будет ли еще доступ к Интернету? Буду ли я сам вообще?

Поэтому зафиксирую текущий результат. Пусть даже без единички у очередного круглого числа.

вторник, 26 апреля 2022 г.

[prog.c++] Столкнулся с неудобством при использовании vcpkg

Очень долгое время придерживался подхода, когда в C++ном проекте исходники всех зависимостей включаются прямо в дерево каталогов самого проекта.

Возьмем, для примера, наш проект arataga (его рассматривать интереснее, чем RESTinio или so5extra, т.к. это не библиотека, а вполне себе законченное приложение, хоть и небольшое). Сам проект содержит всего два подкаталога с исходниками:

arataga/
`- arataga/  # Здесь сами исходники проекта.
`- tests/    # Здесь исходники тестов.

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

воскресенье, 17 апреля 2022 г.

[life.music] Что-то типа дыбра на тему аудиофилии

Чуть больше года назад начал публиковать заметки, посвященные попыткам найти на Aliexpress хорошие, но недорогие наушники. Сегодня будет очередная часть, что-то вроде сборной солянки наблюдений и "открытий", сделанных за последние несколько месяцев.

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

воскресенье, 10 апреля 2022 г.

[life] Присутствие в соцсетях на данный момент

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

Сегодня речь пойдет про соцсети в которых я когда-то присутствовал.

В Twitter даже и не заглядываю.

В LinkedIn иногда заглядываю в костюме химзащиты. Но, как правило, это заканчивается тем, что отписываюсь от очередных людей из списка контактов.

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

Регулярно захожу в VK. Так уж получилось, что часть людей, которых я лично не знал, но на которых был подписан в FB чтобы читать разное на тему истории/литературы/политики/и-всякого-разного перебралась в VK. Так что если со временем в VK переедут и другие френды, то надобности в FB и не останется.

Иногда в VK делаю мелкие посты, но до той активности, которая была в FB еще месяца два назад, нет и близко.

Связаться со мной, если вдруг это кому-то потребуется, можно через LinkedIn/FB/VK. Найти можно по моему традиционному никнейму: eao197. Например, vk.com/eao197.

суббота, 9 апреля 2022 г.

[prog.flame] На тему понятности кода

У меня достаточно специфическое отношение к такому занятию, как "программирование". Для многих разработчиков целью является лишь решение поставленной задачи. Грубо говоря, если нужно взять картинки вот отсюда, добавить на них вот это вот и отобразить вот там, и написанная программа все это делает, то цель полностью достигнута.

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

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

Изучаю демо-программу, входящую в состав одного очень известного открытого проекта.

Встречаю в коде функции длиной в 300+ строк вот такой вот фрагмент (все на чистой ламповой Сишечке):

четверг, 7 апреля 2022 г.

[prog.c++] Продолжение темы про передачу C++объектов через shared memory. Промежуточные выводы

Сама тема была обозначена здесь.

После штудирования найденной в Интернете информации сложилось следующее впечатление: если нам нужно передавать через shared-memory объекты небольшого фиксированного размера, то самый простой и надежный способ -- это использовать на стороне процесса-консьюмера memcpy чтобы скопировать содержимое объекта из shared memory в локальную память процесса-консьюмера.

Т.е., допустим, у нас есть некий тип Data:

struct Data {
  int a_;
  long b_;
  short c_;
};

В процессе-продюсере мы используем placement new для размещения Data в shared memory:

auto * memory_block = allocate_block_in_shmem(sizeof(Data));
auto * d = new(memory_block) Data();
d->a_ = 0;
...

На стороне же процесса-консьюмера мы используем memcpy:

auto * memory_block = obtain_valid_pointer_to_block_in_shmem(...);
Data d;
std::memcpy(d, memory_block, sizeof(Data));
std::cout << d.a_ << std::endl; // Тут нет UB.

Очевидно, что таким способом через shared memory могут передаваться только trivially copyable объекты.

Это то, в чем я сейчас на 100% уверен (с поправкой на то, что могу и ошибаться).

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

среда, 6 апреля 2022 г.

[kubuntu] Мне кажется или в Kubuntu таки 20.04 заметно улучшился рендеринг шрифтов?

Только что обновил свой основной рабочий ноубук с Kubuntu 18.04 до 20.04. И мне показалось, что в 20.04 рендеринг шрифтов заметно улучшился. Текст на экране (14", FullHD) стал выглядеть более четким.

Это только мне так кажется или кто-то из читателей блога пересаживался на Ubuntu/Kubuntu 20.04 и наблюдал такой же эффект?

Заодно еще такой вопрос: если мне не изменяет склероз, то в этом апреле должна выйти следующая LTS для Ubuntu/Kubuntu, 22.04. Насколько разумно обновляться с 20.04 на 22.04 в течении месяца-двух после выхода 22.04? Может имеет смысл подождать полгодика-год?

А то я тут, похоже, на 18.04 слишком долго просидел, надо было, наверное, на 20.04 переходить пораньше. Но мешали старые воспоминания о Linux-ах, в которых было стремно обновляться до свежих релизов из-за сырости оных.

понедельник, 4 апреля 2022 г.

[wow] Wargaming сворачивает бизнесы в РФ и РБ, закрывает свою студию в Минске

Ощущение того, что мы накануне грандиозного шухера, начинает смещаться в сторону того ощущения, что грандиозный шухер уже начался.

Новость на русском на сайте sputnik: тыц.

Подозреваю, что рынок труда в РБ начнет тясти (если уже не, просто я тут закуклился в своей провинции, не имею представления как оно там, у центре-то).

Отдельно доставляет количество лайков на этой новости в LinkedIn (скриншот как раз оттуда). Доставляет, но не удивляет.

четверг, 31 марта 2022 г.

[prog.c++] Почти что актуальное про работу с C++ объектами в разделяемой памяти

В текущем проекте для передачи данных между процессами используется разделяемая память (она же shared-memory, реализованная посредством memory-mapped files).

В основном через эту память передаются большие объемы "сырых" данных. Так что особой надобности размещать в shared-memory каких-то С++ных объектов пока не было. За исключением простого заголовка, который предшествует этим самым "сырым" данным.

Однако, на горизонте начинает маячить сценарий, при котором через shared memory может потребоваться передавать небольшие и (пока?) несложные C++ные объекты с управляющей информацией.

И тут на глаза попадается свежая статья на Хабре: Динамические структуры в shared-памяти. Любопытный подход к проблеме там описан.

В код упомянутой в статье библиотеки особо не вникал, просто просмотрел бегло по диагонали. Качеством кода не впечатлился. Но задумался о чем-то подобном.

Однако, как я понимаю, в рамках C++17 нет легальных способов взять указатель на какую-то последовательность байт в разделяемой памяти и сказать, что это вот такой-то C++ный объект. Поскольку все это сродни вот такому трюку:

пятница, 25 марта 2022 г.

[внезапно] Аутсорсинговый ИТ-бизнес в постсоветских странах -- это компрадорство?

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

Например, термин "компрадор" и сопутствующий ему "компрадорская буржуазия".

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

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

четверг, 24 марта 2022 г.

[links] В склерозник: список публично доступных RTSP стримингов

Вот в этом issue на GitHub-е много всякого. Что-то протухло за давностью лет, что-то вполне себе доступно.

Там же дан и такой совет по поиску на Google: inurl:/mjpg/video.mjpg

среда, 23 марта 2022 г.

[prog.c++] Набиваю шишки с nlohmann::json и uniform initialization syntax

В проекте, который наша маленькая компания сейчас делает под заказ, до недавнего времени использовалась связка из RapidJSON и json_dto. Использовалась буквально в паре-тройке мест и в минимальном объеме.

Но вот пришла необходимость задействовать в проекте JSON более плотно, как основное средство для обмена разнообразной информацией между сущностями в программе. Для чего в проекте RapidJSON и json_dto были заменены на nlohmann::json. Выбран был nlohmann::json поскольку потребовался именно что удобный C++ный DSL для формирования JSON-значений.

До этого у меня опыта работы с nlohmann::json не было, поэтому не удивительно, что умудрился наступить на грабли, обусловленные как самим nlohmann::json, так и C++ным uniform initialization syntax, так и моим дилетантизмом в этой области. О чем сегодня и попробую рассказать.

понедельник, 21 марта 2022 г.

[work.hr] Позволю и я себе негатив в адрес HR-ов

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

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

Однако, в прошлом году сам оказался в ситуации которая заставила несколько пересмотреть свое отношение к "нормальности" HR-ов.

В попытке найти финансирование для нашего OpenSource я связывался с HR-ами нескольких компаний (и только потому, что на сайте этих компаний не было координат маркетинговых отделов). Связывался через LinkedIn, описывал кто я и что я, почему беспокою, просил дать координаты кого-нибудь из маркетинга или переслать мою просьбу кому-нибудь, в чьем ведении могут отказаться такого рода вопросы.

И не получал вообще никаких ответов.

Даже вежливого отказа в стиле "извините, но я не могу предоставить вам такого рода информацию".

HR-ы тупо морозились и исчезали с радаров.

Ну да ладно, то дело прошлое, да еще и не связанное напрямую с основными обязанностями HR-ов.

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

И что?

А ничего, девушка как будто мой ответ и не получала.

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

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

суббота, 19 марта 2022 г.

[prog.c++] В слерозник: отличная шпаргалка по fmtlib

Зафиксирую в блоге на случай, если потом придется искать: https://hackingcpp.com/cpp/libs/fmt.html. Отличная шпаргалка по fmtlib с примерами использования и возможностью экспериментировать прямо в он-лайне.

пятница, 4 марта 2022 г.

[life] По поводу текущего момента или режим тишины не может длиться вечно

То, что происходит сейчас между Россией и Украиной -- это трагедия, масштаб которой сложно осознать, а тяжесть грядущих последствий трудно спрогнозировать.

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

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

Но.

Жизнь есть жизнь. Она у меня одна. И ее невозможно поставить на паузу.

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

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

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

понедельник, 28 февраля 2022 г.

[life] Режим тишины на ближайшее время

Записей в блоге в ближайшее время не будет. Вообще. Ни по каким темам.

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

Жизнь одна, так что берегите себя. Все проходит, пройдет и это.

понедельник, 21 февраля 2022 г.

[prog.c++] Еще о возможных направлениях развития SObjectizer

Давеча поймал себя на том, что работы над SObjectizer-5.6 начались где-то приблизительно в это время три года назад, в феврале 2019.

То событие было довольно таки знаковым, т.к. с 2014-го года развивалась ветка 5.5, в которой не было серьезных ломающих изменений и переход на новые версии в рамках ветки 5.5 происходил практически безболезненно. И после 4.5 лет сохранения совместимости между версиями SObjectizer мы таки решились эту совместимость поломать. Как в плане API самого SObjectizer-а, так и в плане минимальных требований к стандарту C++.

Формально говоря, ветка 5.7 сломала совместимость с веткой 5.6. Но, по сути, 5.7 -- это все тот же SO-5.6, с минимальными косметическими изменениями в именовании пары функций. Так что можно сказать, SO-5.6 продолжает свое развитие уже на протяжении трех лет подряд, просто сейчас под именем SO-5.7.

Неожиданно быстро пролетевшие три года поступательного развития -- это серьезно. Это такой срок, который позволяет задуматься о том, что можно было пойти на выделение ветки 5.8, в которой за счет отказа от 100% совместимости с 5.6/5.7 можно было бы добавить что-то новое и полезное. Что-то, что вряд ли получится сделать в рамках API версий 5.6/5.7.

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

четверг, 17 февраля 2022 г.

понедельник, 14 февраля 2022 г.

[prog.c++] Мои пять копеек про тестовое задание от Network Optix (по мотивам срачей на Хабре и RSDN)

Сперва была статья на Хабре "Мои собеседования '2021 (C++ developer)", потом один кусочек из нее процитировали на RSDN:

Домашнее задание, написать эффективный TCP-сервер с определенными требованиями. Код должен быть покрыт юнит-тестами. Раньше TCP-сервера писать не приходилось, потратил три дня почти full-time, отослал результат. Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных. Оценил что на исправление замечаний может уйти еще N часов. Забил.

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

Клиентское приложение устанавливает TCP-соединение и передает строки, разделенные символом перевода строки “\n”.
Сервер должен считать их хеш-суммы (тип суммы — на выбор кандидата) и отправлять их обратно в HEX-виде, также завершая каждую сумму символом перевода строки.
Клиентские запросы должны обрабатываться параллельно, в случае достаточного количества параллельных соединений должны быть загружены все ядра CPU.
Сервер должен работать эффективно — не потреблять лишней памяти и отправлять хэш-суммы по мере их готовности.
Входные строки могут быть неограниченной длины.
Для реализации сетевой части сервера можно использовать любую удобную вам библиотеку из числа стандартных пакетов репозитория Ubuntu 16. Сервер также должен собираться и работать на Ubuntu 16.
На модули приложения должны быть написаны unit-тесты.

Сейчас не буду вдаваться в то, уместно ли в 2021-2022 давать тестовые задания соискателям. Как и не буду говорить про впечатления от RSDN-овского срача. Лучше я этому посвящу отдельный пост.

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

среда, 9 февраля 2022 г.

[prog.c++] Вспомнил давеча про aragata

Где-то с год назад мы открыли разработку под названием arataga. Это был прокси-сервер, который делали под специфические запросы, но который остался невостребованным. Немного о том, что, как и почему можно прочитать в посте годичной давности.

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

Когда открывали arataga в январе 2021-го это был всего лишь работающий прототип, протестировать который под реальной нагрузкой у нас не было возможности.

Но вот в апреле-мае 2021 такая возможность появилась.

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

О том, что было сделано в arataga по следам натурных испытаний мы даже рассказали в виде статьи на Хабре. А потом еще и сделали презентацию на тему arataga (вот она на slideshare, а отсюда ее можно взять в PDF). Так что, если кому-то интересно, то можно ознакомиться.

Я же позволю себе в этом посте опубликовать две картинки. Это скриншоты, которые я делал во время испытаний на реальном трафике.

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

Интересные циферки можно увидеть: в каждом из экземпляров старого прокси работает больше 4K нативных тредов. Это то, к чему приводит использование модели thread-per-connection. Причем это еще слабо нагруженный сервер, доводилось видеть картинки, когда в каждом экземпляре работало более чем по 13K тредов и более...

Вторая картинка -- это загрузка того же сервера, но уже с работающим на нем новым aragata.


Решение открыть arataga до сих пор считаю правильным. Хотя дивидендов нам это пока никаких не принесло.

Тем не менее, пусть лежит в открытом доступе. Отличный пример того, что мы можем делать. И как мы это можем делать. Вдруг когда-то да и стрельнет.

четверг, 3 февраля 2022 г.

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

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

Фильмы

Громкая связь (2018) и Обратная связь (2020). Смотрел эти фильмы в первый раз, один за одним. Отличное кино. "Громкая связь", будучи ремейком итальянского "Идеальные незнакомцы", мне показался более душевным и человечным, чем итальянский первоисточник. "Обратная связь", местами, ощущается чуть скучнее, но местами оказывается более трогательным. Оба фильма рекомендую к просмотру тем, кому нравится творчество "Квартета И".

Черный ящик (Boîte noire, 2021). Интересное кино, мне зашло. Финал, правда, не удивил. Но и не разочаровал.

Охотники за привидениями: Наследники (Ghostbusters: Afterlife, 2021). Мне понравилось. Как показалось, в фильме очень хорошо передан дух оригинальных фильмов из 80-х.

Летчик (2021). Первые 2/3 фильма смотреть было интересно. Оставшаяся треть все испортила. Особенно финальная сцена.

Вальдо (Last Looks, 2021). Какая-то невнятная муть. За сюжетными линиями не уследил, мотивацию героев не понял, что к чему и почему не разобрать. Актерская игра, как мне показалось, присутствует только у Мэла Гибсона, да и тот явно дурачится.

Сериалы

Аркейн (Arcane: League of Legends, 2021, первый сезон). Красиво нарисован. И смотреть интересно, даже если про игру, по мотивам которой сериал сделан, даже и не знаешь ничего. Портит впечатление лишь то, что первый сезон закончился не точкой, и даже не многоточием, а жирной такой запятой, мол, не переключайтесь, все самое интересное еще впереди.

Двойник (Counterpart, 2017, первый сезон). Смотреть было интересно, возможно, главным образом из-за хороших актеров. Несколько подпортило впечатление то, что последние три-четыре серии превратили все происходящее в подобие сопливой мелодрамы. А также то, что большой жирной точки в конце не получилось, всего лишь запятая для того, чтобы заставить посмотреть следующий сезон.

Банши (Banshee, 2013, первый сезон). Отличное кино, кто хочет на время выключить мозги и посмотреть экшОн с кровь-кишки-расп*дорасило и вот этим вот всем. Правда, так и не понял, хочу ли я после всего этого смотреть второй сезон.

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

Вне конкурса

Битва при Чосинском водохранилище (Zhang jin hu, 2021). Это качественно сделанная агитка для внутреннего пользования. Как по мне, так достойно уважения: великая страна может позволить себе снимать идеологически правильное кино про знаковые события своей истории. В СССР стоило делать именно такое кино вместо всяких "Гу-Га" и им подобных.

вторник, 25 января 2022 г.

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

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

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

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

понедельник, 24 января 2022 г.

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

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

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

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

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

среда, 12 января 2022 г.

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

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

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

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

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

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

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

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

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

вторник, 11 января 2022 г.

[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 уже оброс достаточно большой функциональностью, теперь акцент следовало бы сместить в сторону большей кастомизируемости и дальнейшему повышению надежности и предсказуемости.

понедельник, 3 января 2022 г.

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

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

Фильмы

Не смотрите наверх (Don't Look Up, 2021). Отличное кино. Возможно, лучше из того, что выходило в 2021. Однако, т.к. я не в курсе происходящего в США, то подозреваю, что до меня дошла только четверть заложенных в фильм смыслов и отсылок. Например, мне показалось, что Питер Ишвел в фильме -- это собирательный образ Стива Джобса, Тима Кука и Билла Гейтса (может и еще кого-то, вроде Безоса и Маска). Наверняка, остальные персонажи также с кого-то списаны, но просто я не в курсе. Добавлю еще, что сам по себе фильм кому-то может и не зайти из-за того, что это гротеск, где вещи специально доведены до апупея и апупеоза.

Гранит (2021). Такое ощущение, что смотришь спиноф "Туриста". Но "Турист", как по мне, интереснее.

Месть земли (Feng bao, 2021). Китайцы скоро смогут перелюнуть Голливуд в таком жанре, как сказочные фильмы-катастрофы. Вот только компьютерную графику подтянуть. А так получилось весьма бодренько и эпичненько. Но, местами, очень смешно: столько пафоса и пропаганды (в хорошем смысле слова), что выросший в СССР может воспринимать это только как комедию.

Обитель зла: Раккун-Сити (Resident Evil: Welcome to Raccoon City, 2021). Откровенная халтура. Глянуть можно разве что если больше смотреть нечего.

Сериалы

Алиби (2018). Ну такое себе. По ходу просмотра кажется, что герои только и делают, что жрут, пьют и трахаются. После просмотра остается странное ощущение: вроде бы достаточно трагичные вещи в фильме происходят, люди умирают, людей убивают, а все это подается в комедийной и несерьезной манере. Любители русского кино могут посмотреть.

Море Спокойствия (Goyoui bada, 2021). Первые семь серий смотреть было интересно, хотя зачастую и казалось, что в фильме вместо корейцев снимаются эстонцы. Очень уж затянуто, приходилось смотреть на скорости 1.25. А вот последняя серия перечеркнула все положительные впечатления от предыдущих серий. Настолько бездарно все спустить в унитаз еще нужно было суметь.