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

[prog.c++] Реинкарнация procxx под именем procyy

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

https://github.com/eao197/procyy

Этот форк лежит, в общем-то в том же виде, в котором и procxx. Никаких тестов, продвинутых примеров, проектных файлов для CMake или чего-нибудь еще. Как взял, так и оставил :)

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

Нет и планов добавить procyy в conan, vcpkg, hunter или какой-нибудь другой менеджер зависимостей. Лично мне это не нужно, а если кому-то нужно, тот пусть и берет на себя все эти заботы. Простите.

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

среда, 4 марта 2020 г.

[prog.c++.actors] Обновленная версия презентации "Actor Model and C++: what, why and how?"

Обновил свою презентацию более чем трехлетней давности. Поскольку что-то в ней уже устарело за это время. А что-то все еще актуально. Так же добавил в презентацию ссылки на малоизвестные широкой публике разработки actor-zeta и rotor. Ну не CAF-ом же единым, в конце-концов...

Так же эта презентация доступна на SlideShare, а PDF-ку отдельно можно скачать с SourceForge.

Я сделал пост на Reddit-е и у себя в LinkedIn. Если кто-то сочтет возможным опубликовать ссылку на SlideShare еще на каких-то ресурсах, то это будет здорово.

[prog.c++.actors] Довелось еще раз посмотреть в сторону CAF

Решился намедни обновить свою старую уже презентацию Actor Model and C++: what, why and how?, поскольку за прошедшее время многое уже изменилось. И, наверное, впервые с 2016-го года еще раз посмотрел в сторону главной на данный момент реализации модели акторов для C++, библиотеке CAF (она же C++ Actor Framework).

Несколько прифигел.

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

Во-вторых, похоже, уже нет шансов хоть как-то побороться с CAF-ом за популярность в C++ мире. Больше двух тысяч звезд на github-е против шести десяков (именно десятков) у SObjectizer-а. На HackerNews посты про CAF собирают под сотню поинтов, тогда как аналогичные для SObjectizer-а -- в лучшем случае 2-3 поинта.

Что называется, почувствуйте разницу.

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

Собственно, вывод из этого простой: никогда SObjectizer не станет популярным и широко востребованным инструментом среди C++ников.

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

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

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

Так что постараемся сохранить небольшой размер и сложность SObjectizer-а. А создание комбайна на все случаи жизни оставим разработчикам CAF-а.

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

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

При этом я ни в коем случае не говорю о том, что подход разработчиков CAF-а плох. Возможно, он намного лучше моего. И у множества людей, выбравших CAF, нет никаких проблем. Может это как раз передовой подход, который либо уже стал мейнстримом в C++, либо станет в ближайшее время. А я этого не понимаю в силу своей замшелости и зашоренности.

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

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

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

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


Надеюсь, что обновленную версию "Actor Model and C++: what, why and how?" получится опубликовать сегодня во второй половине дня.

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

[prog.c++] Есть желание реинкарнировать библиотеку procxx

Тут такое дело... Жила-была себе небольшая, простая в реализации и симпатичная C++11 библиотека procxx для запуска дочерних процессов в Unix-ах. Мы нашли её года четыре назад и несколько раз за это время использовали то тут, то там. И даже отослали автору какие-то PR.

Давеча потребовалось использовать procxx еще раз и в ее реализации обнаружились некоторые фатальные недостатки. Для устранения которых потребовалось существенно ператрахнуть (с) потроха procxx. И вот теперь, когда новая реализация procxx задышала, возник вопрос: а что с этим делать дальше?

Проект procxx выглядит заброшеным. В репозиторий несколько лет ничего не коммитили, на issue нет реакции. Сам автор, судя по его мизерной активности на github-е, переключился на Rust. Так что, в принципе, можно было бы сделать pull-request для procxx, но смысла в этом я лично не вижу. Тем более, что подобный вопрос я открыл в качестве issue, но никакой реакции пока не последовало (вполне ожидаемо).

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

Поэтому есть желание реинкарнировать procxx.

Но т.к. автор ничего на эту тему не сказал, то мне стремно использовать procxx в названии моего форка. Было желание назвать обновленную версию procxxrv (от procxx-revisited) или procxx-ng (от procxx-new-generation). Но с такими названиями получается, что я как бы пытаюсь заработать очки на популярности старой procxx. Что не есть хорошо.

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

Посмотреть на то, что есть в procxx-revisited на данный момент можно здесь (ветка revisited). Любые конструктивные замечания/предложения, естественно, приветствуются.