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

Наверное около года, может чуть меньше, пытаюсь следить за публикациями, которые анонсируются на reddit/r/cpp и в сообществе Meeting C++. Понятное дело, что читаю далеко не все, что там проскакивает, но некоторое впечатление о тенденциях складывается...

И впечатление складывается такое, что слишком много говорится о языке, о каких-то тонких моментах, о каких-то извращенных решениях для каких-то изощренных проблем... Ну вот, из совсем недавнего, просто приведу несколько показательных ссылок: "Writing Good C++ By Default, in the STL", "Using templates and lambdas to make a safe copyable polymorphic wrapper" и "C++ Language Support for Pattern Matching and Variants".

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

[prog.flame] Даешь хостинг веб-магазинчиков на "Малинке"!

Все нижеследующее следует рассматривать как тяпничный бред, попытку чуток расслабиться, отвлечься от работы с документаций и помечтать о благословенных временах, когда нативные приложения рулят и бибикают :)

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

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

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

[business] Проблемы разработки программного продукта под двойной лицензией

Доводилось ли кому-нибудь из читателей заниматься организацией разработки программного продукта под двойной лицензией (т.е. GPL-лицензия для OpenSource и коммерческая лицензия для закрытых проектов)?

Очень бы хотелось пообщаться на эту тему. В частности, как к подобным проектам относятся ресурсы вроде GitHub, BitBucket, SourceForge?

Ну и вообще интересен опыт в подобной области (как свой, так и чужой, так что ссылки на какие-нибудь статьи/блог-посты/обсуждения всячески приветствуются).

Общаться можно в комментариях к этой теме или по почте eao197 на гмайле точка ком.

---

Upd. На BitBucket есть этот вопрос в FAQ-е:

Q. I consider dual-licencing one of my open source projects.
I also consider starting other open source projects but with a commercial license.

Is it ok to host these projects on BitBucket for free?

A. Of course! Whether you have a paid or free accont, you can host whatever kind of project you'd like.

If you want the long form legalease version, check out our End User Agreement.

Upd2. На GitHub-е на прямой вопрос ответили, что это возможно и покупать приватную репу не нужно:

Q. Is it possible to create a project with dual-license on GitHub (one license is GPL, another one is commercial license)?
A. It certainly is possible, just make sure you list them both clearly in your license and/or README file.
Q. Does it require purchasing some commercial service from GitHub? Or is it possible for ordinary project with just one public repository?
A. Nope. You can host any code with any license on a public repository. You only need to pay if you want to have private repositories.

[prog.c++11] Релиз SObjectizer-5.5.15

Состоялся релиз версии 5.5.15 проекта SObjectizer. Более подробная информация о релизе представлена в новости на SourceForge.

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

Серьезных планов на добавление чего-то нового в SO-5 нет. Может быть будет проведена работа по оптимизации thread_pool-диспетчеров. Может быть будет сделана версия однопоточного SObjectizer-а (т.е. будет всего один диспетчер с одной рабочей нитью, эта же рабочая нить будет обслуживать и таймеры). Но приоритеты у этих доработок низкие.

Более высокий приоритет у таких задач, как документирование, создание новых презентаций для серии Dive into SObjectizer-5 (кстати, вторая часть, посвященная состояниям агентов, была переработана), демонстрация возможностей SObjectizer (в частности, в планах есть разработка примера использования SO-5.5 в GUI-приложения с обменом сообщениями между агентами и остальными частями приложения через mchain-ы).

Кроме того, есть мысли по поводу реинкарнации в новом обличье таких важных подпроектов, как sysconf (сборка большого приложения из отдельных DLL, что-то вроде заточенной под SObjectizer системы плагинов) и gemont (сбор и распространение наружу мониторинговой информации из SObjectizer-овского приложения). Многолетняя практика использования SObjectizer для разработки приложений 24x7 показала, что с двумя этими подпроектами создание и эксплуатация сложных программных систем выглядит совсем иначе, чем без sysconf и gemont.

В общем, работы на ближайшие 2-3 месяца выше крыши. Так что продолжим двигаться дальше.

[prog.c++11.sobjectizer] И еще несколько слов о примере intercom_statechart

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

Пример с домофоном оказался интересным не только с точки зрения ИКА. Он так же показывает пару других особенностей SObjectizer, которые по-отдельности могут вызывать вопросы у людей, привыкших к реализации Actor Model в Erlang/Akka или C++ Actor Framework. И которые, наверное, раздувают объем кода агентов в тривиальных примерах, вроде простейшего ping-pong-а. Но которые, на мой взгляд, оказываются чрезвычайно полезными в более-менее сложном и приближенном к реальной жизни коде.

Вот об этих вещах и хочется поговорить отдельно.

[blog.life] Вместо дыбра

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

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

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

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

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

Еще один забавный фактор связан с тем, что читая обсуждения на профильных ресурсах, где тусуются и обмениваются мнениями ИТ-шники, у меня складывается впечатление, что вменяемых людей в он-лайне остается все меньше и меньше. Может это уже я впал в старческий маразм, может, на самом деле, количество малолетних идиотов зашкаливает... Но временами читаешь такое, что просто поражаешься. Кажется, что накал идиотии в околопрограммерских темах достиг такого уровня, что проще просто не обращать на него внимания. Чем, скажем, писать еще один пост с объяснением различий между кодами возврата и исключениями, с разбором причин, по которым checked exceptions из Java оказались не так хороши на практике, чем это предполагалось. В общем, сейчас в Интернетах кто-то неправ гораздо чаще, чем пару лет назад. Но сил доказывать это уже нет :)

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

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

[prog.c++11] Второй релиз-кандидат SObjectizer-5.5.15

Зафиксирован второй релиз-кандидат версии 5.5.15 проекта SObjectizer.

Взять 5.5.15-rc2 можно из репозитория (либо Svn на SourceForge, либо Git на GitHub).

В реализации SObjectizer добавлен принудительный вызов обработчиков выхода из состояния при дерегистрации агента. Добавлены соответствующие тесты. Добавлен еще один пример blinking_led.

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

Походу, более-менее понятна дата релиза. Если успею с документацией, то 20-го или 21-го января. Если не успею, тогда уже на следующей неделе (27-го или 28-го).

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

[prog.c++11] Предварительный качественный итог сравнения производительности SO-5 и CAF

Николай Шмаков проделал большую работу по сравнению производительности SObjectizer (v.5.5.14.1) и C++ Actor Framework (v.0.14.4). Пока тесты проведены на 3-х бенчмарках, взятых из CAF-а, и одного бенчмарка из SO-5. Cо временем, надеюсь, еще пара бенчмарков из SO-5 будет добавлена. Предварительные же результаты оказались занимательными.

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

А вот что для нас самих оказалось очень удивительно, так это отсутствие отставания SO-5 от CAF в скорости обмена сообщениями между акторами/агентами. Казалось бы, данная процедура в SO-5 имеет кучу накладных расходов (механизм подписок, поиск обработчиков в состояниях агента и т.д.)... Но на практике мы либо идем вровень с CAF-ом, либо заметно его опережаем, либо опережаем ну очень уж сильно (скажем, в таком тривиальном кейсе, как ping-pong). Так что в плане производительности механизма доставки сообщений ситуация прямо противоположна: если вам нужно перекачивать максимум сообщений в секунду, то SO-5 будет лучшим выбором, чем CAF (в том числе и за счет большого набора диспетчеров в SO-5, что позволяет распределять агентов по рабочим нитям более гибко).

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

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

PS. Кстати на счет понятности прикладного кода. Наверняка это мои личные заморочки, но CAF-овские акторы легко воспринимаются пока они очень простые (т.е. уровня "получил сообщение, отослал сообщение"). Но стоит логике агента чуток усложниться, как разбираться с логикой его поведения становится сложнее. В SO-5 с этим обратная ситуация: понять работу простого агента бывает сложнее, чем более навороченного агента.