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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 есть методы: