[prog.c++11] Пример использования C++ных шаблонов для сериализации/десериализации MQ-шных сообщений

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

[prog.web] Нужно быстро прокачаться в области разработки web-приложений. Как?

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

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

Итак, нужно очень быстро прокачать свои знания в области разработки Web-приложений. Не сложных, для которых не нужно привлекать J2EE и пр. ынтерпрайзную кухню.

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

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

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

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

PS. Web-разработкой никогда всерьез не занимался. Некоторое общее представление было, даже когда-то приходилось делать несложные cgi. Но за последние пару лет, когда с головой ушел в разработку SO-5, все это благополучно выветрилось и забылось.

[prog.thoughts] Чуть подробнее про разработку приложений с использованием акторов

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

[prog] Поясните про использование CMake, пожалуйста

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

Первый непонятный момент. Допустим, есть простая ситуация: Linux и всего два компилятора -- gcc и clang. Мне нужно пользоваться то тем, то другим. При этом компилироваться как в release-режиме, так и в debug. Правильно ли я понимаю, что каноническим решением является вот такое:

cd ~/develop/my-project
mkdir build_gcc_release
cd build_gcc_release
cmake -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=Release ..
cd ..
mkdir build_gcc_debug
cd build_gcc_debug
cmake -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=Debug ..
mkdir build_clang_release
cd build_clang_release
cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release ..
cd ..
mkdir build_clang_debug
cd build_clang_debug
cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Debug ..

---

Второй непонятный момент. Допустим, мне нужно использовать три внешних проекта (p1, p2, p3), у которых сборка делается через CMake. При этом я хочу, чтобы результаты компиляции всех трех подпроектов (т.е. исполнимые файлы и so-ки) сбрасывались в одни и те же каталоги. Т.е. вместо того, чтобы иметь что-то вроде p1/build/lib b p1/build/bin, p2/build/lib и p2/build/bin, p3/build/lib и p3/build/bin, я хочу иметь my-project/build/lib и my-project/build/bin.

Правильно ли я понимаю, что в этом случае у меня получается что-то вроде:

cd ~/develop/my-project
wget https://p1.home/download/p1-some-ver.tar.gz
tar -xf p1-some-ver.tar.gz
cd p1-some-ver
mkdir build_gcc_release
cd build_gcc_relese
cmake -DCMAKE_INSTALL_PREFIX=~/develop/my-project/build -DCMAKE_BUILD_TYPE=Release ..
make install
cd ../..

wget https://p3.home/download/p2-some-ver.tar.gz
tar -xf p2-some-ver.tar.gz
cd p2-some-ver
mkdir build_gcc_release
cd build_gcc_relese
cmake -DCMAKE_INSTALL_PREFIX=~/develop/my-project/build -DCMAKE_BUILD_TYPE=Release ..
make install
cd ../..

...

Т.е. я создаю compiler-specific makefiles для каждого из подпроектов, но при этом для всех подпроектов указываю общее значение CMAKE_INSTALL_PREFIX?

[prog.c++] C++ библиотеки для реализации HTTP-сервера

Слегка пробежался по нескольким спискам современных C++ библиотек в поисках тех из них, которые позволили бы реализовать встроенный в приложение HTTP-сервер. Как мне показалось, внимания заслуживают следующие варианты:

https://github.com/cpp-netlib/cpp-netlib

https://github.com/matt-42/silicon

https://github.com/civetweb/civetweb

Плюс еще и https://github.com/corvusoft/restbed, который, в отличие от трех предыдущих, под двойной лицензией.

Upd. https://github.com/splunk/pion

Если таки возникнет острая необходимость встраивать HTTP в плюсовое приложение, то в первую очередь буду смотреть в сторону cpp-netlib и CivetWeb. Они на меня произвели наиболее благоприятное впечатление.

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

ЗЫ. Есть еще и C++ REST SDK от самого Microsoft-а. Но как-то не торкнуло.

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

[prog.thoughts] Реализации Actor Model для C++: нужны ли? И если нужны, то какие?

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

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

[prog.mqtt] Особенности работы wildcard-ов в именах MQTT-шных топиков

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

Метасимвол '#' заменяет любое количество элементов в имени топика. Т.е. подписка на foo/# будет получать сообщения из топиков foo/, foo/bar, foo/bar/baz и т.д.

При этом подписка на foo/# будет приводить так же к получению сообщений из топика foo. Внезапно.

Дело в том, что согласно спецификации MQTT, метасимвол '#' распространяется так же и на родительский элемент: The multi-level wildcard represents the parent and any number of child levels. Т.к. в имени foo/# родительский элемент -- это foo, поэтому топик с именем foo попадает под фильтр foo/#.

Как по мне, так есть здесь что-то корявенькое, ну да ладно. Вполне ожидаемо фильтр # обеспечивает подписку на любой топик. Будь то foo, foo/, foo/bar, foo/bar/, foo/bar/baz и т.д.

А вот фильтр /# работает уже не так. Сообщения из тем foo, foo/, foo/bar и пр. подобных он отслеживать не будет. Тогда как из тем /, /foo, /foo/, /foo/bar и т.д. -- будет. Описание этой особенности удалось отыскать только в одном источнике от IBM. Что не удивительно, т.к. MQTT -- это детище инженеров IBM, а инженерная культура разработчиков из IBM временами производит странное впечатление ;)

С метасимволом '+', который заменяет всего один элемент в имени топика, все гораздо проще. Если есть фильтр foo/+, то он будет отслеживать топики foo/, foo/bar, foo/baz и т.д., но не будет отслеживать топики foo, foo/bar/baz и т.д.

Ну и в довершение. Вот это вот все разные топики: foo, /foo, foo/, /foo/, /foo//.

И, кстати говоря, подряд идущих слешей может быть сколько угодно: ///3/// или ////4////. Причем при работе с такими именами топиков спецификация MQTT запрещает объединять идущие подряд слеши в один. Хотя как по мне, логики здесь гораздо больше, чем в ситуациях с foo/# и foo :)