пятница, 16 ноября 2018 г.

[prog.flame] Мои субъективные ощущения от vcpkg и Conan

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

Итак, поделюсь своими ощущениями от знакомства с двумя менеджерами зависимостей для C++. Это vcpkg от Microsoft-а и Conan, который сейчас находится под крылом JFrog. При этом сам я не пользуюсь в своих проектах ни одним, ни другим. И исхожу из своего опыта создания и сопровождения пакетов для этих менеджеров.

среда, 14 ноября 2018 г.

[prog.thoghts] А можно еще неполиткорректное высказывание в адрес Conan?

А именно: есть ощущение, что Conan существует не для решения проблем разработчиков, а для привлечения клиентов к сервисам JFrog.

Возможно, я сильно не прав. Но вот на третий день попыток освоить и изучить Conan у меня пока именно такое ощущение. И подталкивают меня к этому три фактора.

Фактор первый. Происхождение и развитие Conan-а. Если правильно помню, то сперва был biicode. Который некие чуваки, кажется, из Испании, пытались позиционировать как сервис для управления зависимостями в C++. Причем сервис как бизнес. Тема вполне ожидаемо не взлетела. Что не удивительно в наш век бесплатного OpenSource-инструментария. Далее biicode приказал долго жить, а на его руинах начал развиваться проект Conan. Который, имхо, ждала бы судьба biicode, если бы команду разработчиков Conan-а не взяла на борт JFrog.

Фактор второй. Conan пытается угодить всем. Могу ошибаться, но изначально Conan, как и его предтеча, biicode, был заточен под CMake. Но потом в Conan-е от завязки исключительно на CMake отошли и сейчас в документации к Conan говорится, что Conan перпендикулярен системам сборки. Мол, задача Conan-а только подтащить к вам на машину нужные вам артефакты, а дальше вы любитесь с этими артефактами любым удобным для вас способом. Хоть с CMake, хоть с Autotools, хоть еще с чем-нибудь.

Что лично мне непонятно от слова совсем: какой толк в "централизованном" репозитории зависимостей, если там перемешаны зависимости с разными системами сборки. Скажем, у меня в проекте Waf, а из Conan-а я беру три артифакта, первый из которых завязан на CMake, второй на GNU Makefiles, а третий на SCons. И что с этим винигретом мне потом делать? В этом плане подход vcpkg, hunter-а, build2 и buckaroo лично мне представляется гораздо более логичным и практичным.

Зато "всеядность" Conan-а на 100% оправдывается, если целью является привлечение как можно большего числа пользователей к JFrog Artifactory. Чтобы затем часть из них стала платными пользователями.

Ведь мир C++ неоднороден, CMake пока любим и используем не всеми. Значит, если Conan будет поддерживать только CMake (как тот же vcpkg), то круг потенциальных клиентов резко сужается. Поэтому нужно сделать Conan привлекательным и для тех, кто CMake пока еще не пользуется. Какая в итоге будет выгода пользователям Conan-а -- это другой вопрос, главный вопрос -- это сколько пользователей прибегут на сервисы JFrog-а.

Фактор третий. Есть ощущение, что проект развивается, что называется "без руля и без ветрил". Т.е. JFrog взял команду Conan-а на борт, а дальше дал им карт бланш и простую цель: сделайте так, чтобы ваш Conan приводил C++ников на наши сервисы. Как вы это будете делать никого ниипет не интересует, важен результат. Вот команда и творит хер знает что.

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

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

PS. В общем, продолжаю погружаться в чан с говном в Conan. Раз уж взялся за то, чтобы сделать пакеты для Conan, нужно довести до логического завершения. Либо таки сделать. Либо обосновать раз и навсегда, почему пакеты Conan-а вместе с Conan-ом стройными рядами идут в /dev/null. И потом, наверное, напишу свое нелицеприятное мнение о vcpkg и Conan-е.

вторник, 13 ноября 2018 г.

[prog.fuck] И еще про Conan и его документацию. Моя думалка сломалась

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

The previous create approach using test_package subfolder, is not strictly necessary, though very strongly recommended. If we didn’t want to use the test_package functionality, we could just write our recipe ourselves or use the conan new command without the -t. command line argument.

$ mkdir mypkg && cd mypkg
$ conan new Hello/0.1

This will create just the conanfile.py recipe file. Now we can create our package:

$ conan create . demo/testing

This is equivalent to:

$ conan export . demo/testing
$ conan install Hello/0.1@demo/testing --build=Hello

Команды conan new и conan create делают разные вещи? Вы серьезно?

Что означает "Hello/0.1" в conan new понять несложно. Но блин, что должно означать demo/testing в команде conan create?

Команда conan create эквивалентна команде conan export, о которой еще не было и речи, плюс еще и conan install, которая, как следует из ранее прочитанного, должна откуда-то загрузить пакет. Блин, по какой такой логике create получается эквивалентом export+install?

Ну хорошо, пусть сумрачный гений авторов Conan-а дошел до того, что create=export+install. Но, блин, куда делается export? И откуда делается install? Ведь Conan с каким-то сервером должен общаться. С каким именно, почему про это пока еще вообще ничего не было сказано?


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

Ровно тоже самое можно сказать и о разработке другого инструментария для программистов. Бл*дь, да другие навыки нужны для этого, другой взгляд на мир, другой способ мышления.

Не верите? Ну посмотрите на тот же самый git Conan. Его явно делали люди, которым не нужно разрабатывать инструментарий. Вот вообще. Это еще со времен biicode было видно. И уж тем более, нельзя этим людям документацию писать.


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

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

PS. А авторов альтернативных решений, вроде build2 или Buckaroo, после более плотного знакомства с Conan-ом, стал уважать еще больше. Хоть и думаю, что build2 не взлетит из-за своей оригинальности, а Buckaroo из-за привязки к Java для своей работы.

[prog] Очередной подход к Conan

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

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

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

Т.е. общее впечатление от conan-овской документации: куча разрозненных частных деталей из которых читатель сам должен сформировать общую картину.

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

Неужели это так сложно?

Попутно у меня просьба: если вы встретитесь с подобными косяками в нашей документации к SObjectizer/so_5_extra и RESTinio, то не сочтите за труд, дайте нам знать. Обязательно постараемся исправить.

понедельник, 12 ноября 2018 г.

[prog.thoughts] Под впечатлением от свежей статьи про Rust на Хабре

Просмотрел только что свежую статью на Хабре про Rust: Приемы обобщенного в Rust: как мы переводили Exonum с Iron на actix-web.

Похоже, я могу понять, почему к Rust-у такое внимание. И от кого это внимание исходит. Если всю жизнь программировал на Python, Ruby, JavaScript или даже Go, то в один прекрасный момент динамическая типизация и невысокая скорость исполнения может основательно подзадолбать.

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

Может быть Ada? Или какой-нибудь Eiffel? Сильно вряд ли. Про них мало кто знает. Eiffel вообще платный (но есть GPL-ная версия) и где он сейчас непонятно. Ada вроде как жива и развивается, но модным и молодежным этот язык точно назвать нельзя. Да и у сегодняшней молодежи попытка изучить Ada может вызвать стойкий рвотный рефлекс, особенно если всю жизнь программировал на чем-то вроде JavaScript-а.

Можно еще и D. Но его популярность и распространенность колеблется где-то возле статпогрешности.

Вот и остается Rust. Который был построен на базе всех популярных страшилок и хайпов 2000-х годов. ФП во все поля, ООП сосет, безопасное многопоточное программирование (на самом деле нет), отсутствие и GC и утечек памяти, иммутабельность by default, ...

Так что почему на Rust переходят люди с Python/Ruby/JS и даже с C# или Java, мне вполне понятно.

Только вот глядя на более-менее практичные примеры кода на Rust я не понимаю двух вещей:

Во-первых, какой смысл сейчас разрабатывать прикладное ПО на Rust-е или C++? Ну т.е. такое, которое решает проблемы конечных пользователей. Зачем писать на Rust или C++ очередной HTTP-сервер, MQ-брокер, СУБД или компилятор я могу понять. Не понятно, зачем на Rust-е делать что-то прикладное, типа взяли данные отсюда, проверили, преобразовали, сохранили в БД, отдали вот сюда.

Ну вот, действительно, какой смысл? Порог входа в язык высокий. Код, который будет разрабатываться, особой читабельностью отличаться не будет. Посадить на проект какого-то "индуса" заместо выбывшего "индуса" не получится. Поскольку язык безопасный, с кучей проверок к run-time, по производительности он будет побыстрее, наверное, Java и .NET-а, но не на порядки. Да и вряд ли в разы быстрее, скорее на десяток-другой процентов, да и то вопрос. Экосистема еще только формируется и наполняется библиотеками...

Во-вторых, зачем C++ника пересаживаться на Rust? Не, я понимаю, что ФП во все поля, ванильные трайты вместо утиных шаблонов, синтаксические макросы, компилятор бьет по рукам, cargo и все дела... Но блин, в Rust-овом коде будет все тоже самое, что и в C++ном: лес из абстракций и обобщенных конструкций, построенных каким-то сумрачным гением. Так что в красивой обертке матерый C++ник обнаружит все тот же говнокод, наполненный трехэтажными шаблонами, с которым ему и так приходится иметь дело постоянно. И еще непонятно, какой из них ближе к криптограммам ;)


В общем, в очередной раз можно пожалеть, что D не взлетел. Сперва он появился слишком рано, когда еще не было надобности в шустром, но безопасном нативном языке с GC. Всех вполне устраивали Java с JVM и C# с .NET. Плюс к тому, затеяли переход от D1 к D2 и профукали момент, когда выстрелил Go в контейнерах, где нужна и скорость и отсутствие тяжелых ран-таймов.

Да и сейчас авторы D, как мне кажется, продолжают думать, что основные конкуренты для них -- это C и C++ (ну, может быть еще и Rust). Тогда как на мой взгляд, основные конкуренты для D -- это Go и грядущие Kotlin/Native, Scala/Native, Crystal, Nim и т.д. И вот эта неправильная оценка ситуации приведет к очередному профуканому шансу. Вместо betterC нужно в D другими вещами заниматься, имхо.

Жаль D. На данный момент это единственный язык, на котором хочется что-нибудь написать, когда C++ в очередной раз подзадалбывает.

пятница, 9 ноября 2018 г.

[prog.thoughts] Впечатление после нескольких докладов с HighLoad++ 2018

Вчера представилась возможность краем уха прослушать несколько докладов с HighLoad++ 2018 (анонсы открытых трансляций можно найти здесь). Поймал себя на том, что разработка "нагруженных систем", о которых говорят докладчики, в моем понимании не столько разработка, сколько сборка. Ну или строительство из готовых компонентов. Тут уж кому какой термин больше нравится, никаких отрицательных коннотаций ни в первый, ни во второй вариант я не вкладывал.

Но вот действительно, такое ощущение, что есть "строительные блоки" (nginx, kafka, redis, clickhouse, docker, kubernetes и т.д.) и есть "здания", которые строятся из этих "строительных блоков". При этом и производство "строительных блоков", и построение "зданий" на их основе называется разработкой. Хотя, как по мне, разработка nginx-а и разработка решения на базе nginx-а -- это разные вещи.

Причем, что особенно доставляет, в разработке конечных решений на базе "строительных блоков" деньги были, есть и будут. Тогда как из разработки "строительных блоков" деньги уходят. Ибо, как сказал один из докладчиков: "Мы не хотим башлять вендорам, поэтому мы любим OpenSource" (за точность цитаты не ручаюсь, но смысл передан точно (c)).


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

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

среда, 7 ноября 2018 г.

[prog.c++] SObjectizer-5.5.23 и so_5_extra-1.2.0

Мы все-таки добрались до релиза SObjectizer-5.5.23 и so_5_extra-1.2.0. Ничего нового по сравнению с тем, что описывалось ранее, в SObjectizer/so_5_extra не попало. Разве что специально удостоверились в том, что SObjectizer может собираться под Android посредством свежих Android NDK (проверялось на r18b).

Официальный анонс можно найти на странице проекта.

Свежую версию SObjectizer-а можно взять либо из секции Files, либо с GitHub-зеркала.

Свежую версию so_5_extra можно взять из секции Files (внутри архивов с именами so_5_extra-1.2.0-full уже находятся все внешние зависимости, включая SO-5, Asio и т.д.).

Пользуясь случаем хочу сказать большое спасибо всем, кто не только помог нам с этим релизом. И вообще всем, кто проявлял интерес к SObjectizer-у на протяжении всех этих лет. Ваше внимание и ваша помощь очень и очень сильно нам помогала. Большое спасибо еще раз.

Уже многократно говорил, но повторю еще раз: SO-5.5 развивается уже более четырех лет. Это большой срок, за это время SObjectizer обзавелся многими вещами, о некоторых из которых мы даже и подумать не могли в свое время. С некоторой ретроспективой интересующиеся могут ознакомиться в свежей статье на Хабре: "Четыре года развития SObjectizer-5.5. Как SObjectizer изменился за это время?"

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

  • подружить so_5_extra с CMake. Хотелось сделать это в рамках 1.2.0, но CMake в очередной раз порадовал своей простотой и понятностью. Пришлось отложить;
  • подружить so_5_extra с Boost.Asio. Сейчас so_5_extra работает только со standalone версией Asio, надо бы поддержать еще и Boost.Asio, как мы это сделали в RESTinio в свое время;
  • добавить в so_5_extra возможности для тестирования агентов. Что-то вроде инструментария для упрощения написания unit-тестов для агентов (с использованием агентов).

По поводу последнего пункта пока много непонятностей. Вероятно, для поддержки тестирования агентов потребуется сделать еще и SO-5.5.24. Будем посмотреть. Но вообще мы уже смотрим в сторону SObjectizer-5.6, где мы выбросим накопившийся в SO-5.5 старый хлам и перейдем на C++14.

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

Ну а если кто-то найдет возможным поделиться в Интернетах своим опытом работы с SObjectizer-ом, то это будет просто неоценимое подспорье для нас. Нам очень не хватает публично доступных success stories. А предоставить их можете только вы. Так что если кто-то может или хочет сказать в наш адрес пару добрых слов, то самое время сделать это ;) Подробности можно обсудить по почте (eao197 на gmail точка com).

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

воскресенье, 4 ноября 2018 г.

[prog.c++] Кратко про C++ CoreHard Autumn 2018 (+слайды моего доклада)

Вчера с краткосрочным визитом посетил наш славный Минск. Целью визита стало посещение очередной конференции по языку C++: CoreHard Autumn 2018. В том числе и в качестве докладчика.

Конференцией был впечатлен. Порядка 300 участников, от вида полностью заполненного зала на вступительном докладе захватывало дух. Организаторы большие молодцы, за проведение столь масштабного мероприятия им огромное спасибо! Если события продолжат развиваться такими темпами, то через пару лет C++ CoreHard может сравняться с C++Russia по масштабам и значимости.

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

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

А вот она же на SlideShare.


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

пятница, 2 ноября 2018 г.

[prog.memories] Беглый взгляд на эволюцию SObjectizer-5.5 за прошедшие четыре года

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

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

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

Не стоит. Берите лучше то, что есть. Не нравится вам SObjectizer -- возьмите что-нибудь другое. Тот же CAF или QP/C++. Выбор есть. Полагаю, этот выбор будет всяко лучше повторения хотя бы части пути, который мы уже прошли. И, прошу не забывать, что речь идет не только о том, чтобы придумать и запрограммировать. Но и о том, чтобы отладить, задокументировать и донести ваше творение до других людей. Которые, возможно, думают, что лучше они сами что-нибудь на коленке слепят.

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

Да, и в этом списке нет того, что вошло в состав so_5_extra.

четверг, 1 ноября 2018 г.

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

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

Черный 47-й (Black '47). Отличный фильм. Даже удивительно, что снят на Западе. Такое ощущение, что картина сделана в лучших традициях соцреализма: ну очень уж ярко изобличает пороки капитализма.

Операция «Финал» (Operation Finale, 2018). Неплохо. Не шедевр, но неплохо.

Подслушанное (Sit ting fung wan, 2009). Несмотря на специфику китайского кино оказалось вполне себе смотрибельно.

Шпион, который меня кинул (The Spy Who Dumped Me, 2018). Так себе. Можно глянуть если нравятся дурацкие комедии или больше смотреть нечего.

Ночь идет за нами (The Night Comes for Us, 2018). Попытка сделать боевик с таким же крутым мочиловом, как и в "Рэйде". С теми же актерами в составе. Получилось сильно не очень. Смысла в происходящем на экране вообще не уловил. Местами скучно. Местами видна постановочность боев. Но местами мочилово таки получилось, а уж кровавость происходящего (расчлененка, кишки, мозги и вот это вот все) даже меня удивила.

Ремнант: Всё ещё вижу тебя (I Still See You, 2018). Начало было более-менее, но к финалу фильм полностью разочаровал.

среда, 31 октября 2018 г.

[prog.c++] Вторая бета-версия SObjectizer-5.5.23 и so_5_extra-1.2.0

Зафиксирована вторая бета-версия для SObjectizer-5.5.23 и so_5_extra-1.2.0. Загрузить их можно отсюда: so-5.5.23-beta2.zip и so_5_extra-1.2.0-beta2.zip (либо so_5_extra-1.2.0-beta2-full.zip).

Был исправлен просчет, допущенный при подготовке первой версии: нововведение, конверты с сообщениями, не дружили с фильтрами доставки (посыпаю голову пеплом, тупо забыл про интеграцию с фильтрами доставки). Сейчас это исправлено. Но при этом поменялся интерфейс класса envelope_t. Теперь в нем вместо двух hook-методов всего один: access_hook()

virtual void access_hook(
   access_context_t context,
   handler_invoker_t & invoker) noexcept = 0;

Метод access_hook() вызывается всегда, когда нужно получить доступ к содержимому конверта. Если конверт готов предоставить доступ, то конверт должен вызвать invoker.invoke() и передать туда ссылку на содержимое (тут все осталось как и прежде).

А вот контекст, в котором вызывается access_hook(), теперь определяется перечислением access_context_t. На данный момент в нем определены следующие варианты: handler_found (содержимое конверта нужно для вызова обработчика сообщения), transformation (содержимое конверта должно быть преобразовано в другое представление, например, в результате limit_then_transform) и inspection (содержимое конверта должно быть проанализировано, например, фильтром доставки). Со временем, возможно, список вариантов будет расширен.

Собственно, это главные изменения в so-5.5.23-beta2. Соответствующим образом были изменены нужные части в so_5_extra-1.2.0 и обновлена документация в Wiki проекта.

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

четверг, 25 октября 2018 г.

[prog.c++] Первая версия документации по новым фичам грядущего релиза SObjectizer-5.5.23 и so_5_extra-1.2.0

Появилась первая версия документации по новым возможностям новых версий SObjectizer и so_5_extra:

[so-5.5 In-depth - Enveloped Messages]
[so5extra 1.2 Proxy Mbox]
[so5extra 1.2 Revocable Messages]
[so5extra 1.2 Revocable Timers]
[so5extra 1.2 Just Envelope]
[so5extra 1.2 Sending of Envelopes]
[so5extra 1.2 Time-Limited Message Delivery]

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

Про низкое качество английского можно не говорить. С этим и так все понятно :(

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

Сам релиз ожидается в начале ноября. Хотелось бы к концу следующей недели. Но есть шансы не успеть, т.к. третьего ноября очередной C++ CoreHard, где я буду выступать с докладом "Actors vs CSP vs Tasks" (в роли К.О.) и подготовка к выступлению украдет какую-то часть времени. Поэтому более вероятен релиз уже после C++ CoreHard.

Первая бета-версия уже доступна для загрузки (so-5.5.23-beta1.zip и so_5_extra-1.2.0-beta1.zip), можно брать и пробовать. За время, прошедшее после фиксации первой бетой ничего нового в SO/so_5_extra не попало.

вторник, 23 октября 2018 г.

[prog.c++.wow] Неужели в C++ завезут pattern-matching?

Предложение уже сформировано: p1260p0: Pattern Matching.

Например, чтобы разобраться с содержимым объекта variant<int, float> можно написать вот так:

inspect (v) {
   <int> i: cout << "got int: " << i;
   <float> f: cout << "got float: " << f;
}

Желающих посмотреть больше примеров адресую в пропозал, там всего-то 16-ть страничек.

Если примут, да еще и в C++20, то это будет мегакруто.

Upd. Еще одно аналогичное предложение, которое, по слухам, имеет даже больше шансов: p1308r0: Pattern Matching.

пятница, 19 октября 2018 г.

[prog.c++] Стали доступны первые бета-версии SObjectizer-5.5.23 и so_5_extra-1.2.0

Сегодня были зафиксированы первые бета-версии наших проектов SObjectizer и so_5_extra. Загрузить их можно отсюда: so-5.5.23-beta1.zip и so_5_extra-1.2.0-beta1.zip (либо so_5_extra-1.2.0-beta1-full.zip).

Подробнее об нововведениях рассказывается в очередной статье на Хабре.

Со сроками официально релиза пока так: ориентировочно релиз состоится в первой декаде ноября. Если успеем раньше, выкатим раньше. Но там еще много работы, в том числе и по документированию, и по проверке сборки под Android с помощью Google-овского NDK и еще разных мелочей (и не мелочей). Так что первая декада ноября выглядит более реалистично.

В общем, если кому-то интересно, что в SObjectizer-е происходит, то смотрим, делимся впечатлениями и соображениями. Пока еще есть время и возможность повлиять на то, что попадет в SO-5.5.23 и so_5_extra-1.2.0.

четверг, 18 октября 2018 г.

[prog.c++] В склерозник: легковесная C++11 библиотека для работы с разделяемой памятью

На reddit-е увидел анонс header-only библиотеки mio, предоставляющей средства работы с memory-mapped-file IO. Решил зафиксировать ссылку на нее в склерозник, ибо несколько месяцев назад изучал, что из готового для этих целей есть в мире C++. И получалось, что самое толковое было только в Boost-е. Но Boost -- это достаточно тяжелая зависимость. А здесь легковесная кросс-платформенная библиотека без внешних зависимостей вообще. Под MIT-лицензией.

среда, 17 октября 2018 г.

[life.work] Старпёрское/стартаперское брюзжание на счет скорости течения времени

Забавно: когда ты начинаешь делать какую-то фичу, когда идет непредсказуемый и мучительный процесс выдумывания и проработки/переработки, то нормально, полноценно работать удается не больше 3-4 часов в день. Ну просто тяжело заставлять мозги напряженно скрипеть больше. Да и если заставить, то пользы все равно нет. Хорошие идеи возникают непредсказуемо и неожиданно, как правило, когда ты вообще отвлекся на что-то другое.

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

Зато на поздних стадиях, когда уже основное сделано и идет доводка, рабочее время пролетает стремительно. Вот новый тест нужно сделать. Сделал. Вот нужно комментарий расширить и дополнить примерами. Расширил, дополнил. Увидел косячек в реализации. Исправил. Оба-на! А уже обед. После обеда не успел оглянуться, а уже из офиса пора уходить. Куда улетает время просто не замечаешь.

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

Причем чем старше становишься, тем больше скорость течения времени пугает.

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

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

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

вторник, 16 октября 2018 г.

[prog.c++.sobjectizer] Сбылась мечта идиота: можно сделать отчеты о доставке сообщения до получателя.

Версии SO-5.5.23 и so_5_extra-1.2.0 уже начинают дышать полной грудью. В SO-5.5.23 был реализован новый механизм, который позволяет вкладывать сообщение в некий "конверт". Внутри SObjectizer-а доставка идет уже для всего конверта с вложенным в него сообщением. Сообщение из конверта достается либо когда сообщение доставлено до получателя. Либо когда сообщение по какой-то причине преобразуется из одного представления в другое (например, так происходит в случае использования limit_then_transform). Причем под "доставлено до получателя" означает не только то, что получатель извлек сообщение из очереди, но и то, что у получателя был найден обработчик для этого типа сообщения. Т.е. сообщение реально доставлено, а не просто взято из очереди.

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

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

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

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

суббота, 13 октября 2018 г.

[prog.c++] В склерозник: самодельный аналог std::apply для C++11

Когда-то давно по материалам из Интернета сделал собственный аналог функции std::apply из C++17, но для C++11. Для тех счастливчиков, которые никогда не сталкивались с std::apply или его аналогами скажу, что std::apply позволяет вызвать нужную вам функцию, передав в нее содержимое имеющегося у вас std::tuple. Т.е. фокус в том, чтобы распаковать содержимое std::tuple в набор аргументов вызываемой функции.

В C++11 для такого трюка не было вообще никаких готовых инструментов. В C++14 уже появился std::index_sequence, на базе которого основная магия и происходит. Ну а в C++17 уже есть std::apply. Но мне в свое время нужно было именно для C++11, поэтому и появилась реализация call_by_tuple. Появилась и так и валяется у меня на винте. Время от времени ее приходится искать. И, для того, чтобы искать было проще, решил ее код опубликовать в склерозникблоге.

Поиграться в он-лайн компиляторе с моим вариантом call_by_tuple можно на wandbox-е. Исходный текст этого же примера с реализацией call_by_tuple под катом.

пятница, 12 октября 2018 г.

[prog.flame] Более развернуто про неприятие писанины Тонского

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

четверг, 11 октября 2018 г.

[prog] Почему мне нравится наш подход к управлению зависимостями в C++ проектах

Управление зависимостями для C++ сейчас, к счастью, горячая тема. На слуху vcpkg, conan, build2, buckaroo и др. Но мы вот уже 2.5 года используем собственный велосипед, MxxRu::externals. И сегодня я попробую на простом примере показать, почему этот подход нам нравится больше всего.

[prog.flame] Этот Тонский порвался

Интернетик принес свежий перл от Никиты Тонского: "Нас, как инженеров, не должно волновать что нужно бизнесу или юзерам.."

У меня вот на радаре литературное творчество этого почему-то широко известного эээ лидера мнений давно присутствует. И, складывается ощущение, что в приличном обществе нельзя ссылать на индекс TIOBE в разговоре про востребованность языков программирования. А теперь еще и нельзя ссылаться на мнение Тонского о разработке софта.

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

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

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

PPS. Кстати, месяц и не более 1M RUR -- это не для красного словца, это блин, из окружающей действительности. И 1M RUR -- это общая цена за все, а не чистая зарплата одного инженера. О чем инженеры, как правило, даже не задумываются.

вторник, 9 октября 2018 г.

[blog] Нужно как-то реагировать на закрытие G+

В последние несколько лет я активно использовал G+ для небольших заметок, которые писались быстро, под влиянием момента и на которые не хотелось создавать целую запись в блоге. G+ был не самым лучшим инструментом, но он хотя бы был. И был, наверное, единственной вменяемой альтернативой ВКонтактам и Facebook-ам, которые, на мой взгляд, совсем не предназначены для обмена мнениями на технические и профессиональные темы.

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

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

Посему, если кто-то читал меня через G+, то приходите в FB, я там под своим фирменным ником: eao197.

Прекрасно понимаю тех, кому совсем не нравится идея тусоваться в FB ради чтения моих заметок. Собственно, мне самому совсем не нравится идея писать в FB то, что я публиковал в G+. Но что поделать, мир меняется вот в эту сторону... Будем приспосабливаться.

пятница, 5 октября 2018 г.

[prog.thoughts] Продолжение темы будущих версий SObjectizer-а. Обозримое будущее (на 2018/10)

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

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

понедельник, 1 октября 2018 г.

[prog.thoughts] Будет ли SObjectizer-6? И, если, то каким и когда?

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

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

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

Змей с тысячей порезов (Le serpent aux mille coupures, 2017). Далеко не шедевр. Но смотреть его интересно хотя бы потому, что в европейских фильмах стилистика совсем другая. А уж на фоне красочно снятого маразма (вроде голливудских "Мэг: Монстр глубины" или нового "Хищника"), так вообще просто отдохновение.

Отель "Артемида" (Hotel Artemis, 2018). Мне понравилось, хотя, как мне думается, зайдет не всем.

Калибр (Calibre, 2018). На удивление достойный фильм от Netflix-а. Только нужно понимать, что это не столько триллер, сколько драма. Ибо изначально очевидно, что для главных героев все закончится плохо, вопрос лишь в том, насколько плохо и как быстро это произойдет.

Убийца 2. Против всех (Scario 2: Soldado). В принципе, получше, чем первый фильм, в котором для меня осталась не понятой роль главной героини. Но и продолжение нельзя назвать шедевром, т.к. раздражает некоторая тягомотность и, местами, несостыковки в происходящем.

Мэг: Монстр глубины (The Mag, 2018). Маразматичность происходящего просто зашкаливает. Так что смотреть этот фильм можно разве что ради картинки, которая, временами, просто шикарная.

Офисный беспредел (Office Uprising, 2018). Вроде бы хорошая задумка и местами знатный стеб, но не хватило трешовости. Какая-то лайт-версия получилась там, где должен быть отборнейший треш и угар.

Хищник (The Predator, 2018). По сравнению с этой, мягко говоря, херней, последнее более-менее вменяемое продолжение серии, фильм "Хищники" от 2010 года с Эдрианом Броуди, выглядит просто шедевром, а самый первый "Хищник" с Арнольдом предстает как что-то невероятное и недостижимое. Может быть авторы нового "Хищника" пытались сделать полный треш и угар, и смотреть их "творение" можно разве что в изрядном подпитии... Может быть. Но мне кажется, что и это у них не получилось.

воскресенье, 30 сентября 2018 г.

[work] Свободная касса! (C++/Rust/D)

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

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

Специализируемся мы на C++. У нас большой опыт разработки на этом языке. Благодаря чему умеем писать на С++ без боли, чтобы ничего не текло и не падало.

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

Если качество нашего кода вас устраивает и вы хотите, чтобы аналогичного качества код был и у вас в проекте, то давайте пообщаемся на предмет взаимовыгодного сотрудничества. Пишите на info [at] stiffstream.com. Можно и напрямую мне: eao197 [at] stiffstream.com или eao197 [at] gmail.com.

PS. Хотя наш основной инструмент -- это C++, но язык Rust нам так же симпатичен. Как и язык D. Поэтому если вы ищете Rust- или D-разработчиков, которых на рынке и так практически нет, то почему бы вам не попробовать посотрудничать с нами?

суббота, 29 сентября 2018 г.

[prog] О каждом пожалеешь! О каждом...

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

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

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

Пара-тройка примеров из SO-5.

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

Когда-то все сообщения должны были наследоваться от message_t. Для автора фремворка это очевидно, для пользователей не очевидно и требует лишних телодвижений. Давайте сделаем возможным отсылку объекта произвольного типа. Ok. Сделали через неявное оборачивание в объект-наследник message_t. С тех пор, как только нужно получить доступ к содержимому сообщения, приходится разбираться, имеем ли мы обычного наследника message_t или же у нас обертка вокруг пользовательского типа. Ну и да, может у нас вообще сигнал, а не сообщение.

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

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


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

Трамвай… Бабка наклоняется ко мне — Вот ты такая красивая, милая, такая замечательная. … Небось, даёшь-то не всем ?: Я — Да что вы, бабушка! Как можно? Конечно, не всем! Старушка со вздохом: — О каждом пожалеешь О КАЖДОМ!

пятница, 21 сентября 2018 г.

[prog.thoughts] Мнение пациента с хроническим NIH-синдромом: плюсы и минусы самодельного внутреннего инструментария

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

Как бы то ни было, так уж случилось, что за время своей работы в ИТ мне довелось создать несколько инструментов для разработчиков, которые использовались для создания прикладного софта. Созданный на базе моих инструментов работал годами и годами же находился на сопровождении. Ну, скажем, в 2002-ом году мной были сделаны первая версия SObjectizer-4 и встраиваемая ООСУБД ObjESSty, на базе которых затем был сделан агрегатор SMS/USSD сообщений. Этот агрегатор, как оказалось, до сих пор работает, прокачивает пару тройку десятков миллионов сообщений в сутки, что дает более полумиллиарда сообщений в месяц. Часть компонентов все еще работают именно на SO-4 и ObjESSty. Часть компонентов была написана уже на SObjectizer-5. Но, опять же, возраст этих "новых" компонентов так же измеряется годами.

Да, все это был софт, про который нигде не рассказывали, с ним не сталкиваются миллионы пользователей напрямую, как это происходит с продуктами известных компаний, вроде Microsoft, Google, Yandex и иже с ними. Так что вам, читатель, решать, интересно ли вам мнение велосипедостроителя, работавшего в noname-компаниях и принимавшего участие в проектах, о которых вы никогда не слышали и не услышите.

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

вторник, 18 сентября 2018 г.

[prog.c++] Let's talk about hierarchical finite state machines and their support in SObjectizer-5.5

Finite state machine is a probably one of most basic and widespread thing in software development. Finite state machines (FSM) are actively used in many areas. For example in such niches as SCADA- and telecom systems FSM are used almost everywhere.

In this article we will try to speak about hierarchical FSM. And then we will try to take a look at FSM's support in SObjectizer-5. SObjectizer is one of a few OpenSource and live "actor" frameworks for C++ and actors in SObjectizer are FSMs. We will speak why SObjectizer's actors are FSMs and which capabilities they have.

A Brief Introduction Into Finite State Machines

It is hard to explain in a shot article such big topics as automata theory in general and finite state machines in particular. Because of that an basic understanding of these topics are required from a reader.

Advanced Finite State Machines And Their Features

There are several "advanced features" of FSM which significantly simplify usage of FSM. Let's talk about them briefly.

Disclaimer: if a reader has a good knowledge of UML's statechart diagrams then he or she doesn't find anything new here.

[work.thoughts] Люди, действительно, главный ресурс. Печально, когда это не так

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

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

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

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

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

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

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

четверг, 13 сентября 2018 г.

[prog.flame] Beast-vs-RESTinio or is Boost.Beast really good for solving simple tasks?

It seems that after inclusion of Beast C++ framework in Boost the Boost.Beast is regarded as the only right way to work with HTTP in modern C++. Maybe it is because some C++ developers know only Boost and look for libraries in Boost only. Some even don't know that there is something else except Boost.Beast (like CROW, Pistache, RestBed, served, C++REST SDK, POCO and so on).

And there also is a strong opinion that any library from Boost is the best in its class. For some Boost libraries it is just true. But now Boost has more than 100 libraries inside. It is hard to belive that all of them are exceptionaly useful, easy to use, well documented and maintained well...

Boost.Beast looks like a high-quality library. It just a bright example of C++ masterpiece. But there is a problem: it is too low-level. If you need to solve a simple task you have to write a lot of code on top of Boost.Beast.

To show this we reimplemented a simple example from Vinnie Falco's (he is Beast's author) talk at CppCon-2018 (code and slides can be found here) by using RESTinio library.

The repository with our implementation can be found here: https://bitbucket.org/sobjectizerteam/beast-cppcon2018-vs-restinio

We think that Boost.Beast is a great building block for something really complex (like high-performant HTTP server or client) or for something high-level and user-friendly (like that). But if you have to create a simple RESTful API or simple HTTP-service then it is better to look for something more simple and expressive. We hope our code shows this.

вторник, 11 сентября 2018 г.

[prog.flame] Взгляд на Akka глазами разработчика SObjectizer-а

Некоторое время назад от читателя в комментариях поступила просьба сравнить SObjectizer и Akka. Попытался вдумчиво подойти к этому вопросу. Ибо тут было над чем подумать, т.к. на первый взгляд, сам факт такого сравнения достаточно странный. Как будто сравниваются апельсины с помидорами, просто на том основании, что и то, и другое можно съесть. Действительно, вряд ли у кого-то будет стоять выбор между C++ и SObjectizer-ом и Scala/Java и Akka. Скорее сперва выбирается язык/платформа, потом уже фреймворк для этого языка/платформы. Так что с точки зрения практики более уместным было бы сравнивать SObjectizer и CAF с QP/C++ в рамках C++. Или Akka и Vert.x в рамках JVM.

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

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

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

понедельник, 10 сентября 2018 г.

[prog.c++] Видео с митапа в Питере

Стало доступно видео моего выступления на митапе St. Petersburg C++ User Group с докладом "Акторы в C++: взгляд старого практикующего актородела":

Презентацию можно скачать в виде PDF-ки отсюда, либо же просмотреть на SlideShare или на Google Docs.

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

PS. Так же можно договорится, чтобы я подъехал в офис вашей компании и сделал подобный, но более подробный, доклад про SObjectizer.

суббота, 8 сентября 2018 г.

[life.photo] Впечатления от посещения "Гранд Макет Россия"

В этот раз в Питере удалось посетить уникальное место -- музей "Гранд Макет Россия". Место, от которого захватывает дух.

20180824-161412-DSC_0422

Сравнимые ощущения у меня были давным-давно в детстве, когда в первый раз попал в Севастопольскую панораму. Там возникло такое же удивление: "Как?!!! Как все это возможно?"

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

пятница, 7 сентября 2018 г.

[life.work; humour] А что вы знаете про генеральский эффект? ;)

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

Вчера проявление этого эффекта я сам мог наблюдать на примере LinkedIn.

воскресенье, 2 сентября 2018 г.

[life.craftmanship] Видео про изготовление классических гитар

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

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

В общем, наверное лучшее из пока увиденных, это вот этот ролик:

Правда, он почти на 50 минут. Так что если кто-то хочет более компактную версию, то вот этот сделан качественно и с душой:

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


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

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

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

Подошло время очередного кинообзора. На этот раз совсем коротенького, ибо смотреть было и нечего, и некогда. А часть фильмов, которые я начинал смотреть, например, "Кодекс Готти", "Хот-дог" и "Ты водишь", досмотреть не удалось либо из-за занудности, либо из-за маразматичности происходящего.

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

Апгрейд (Upgrade, 2018). Вот этот фильм приятно порадовал. Не ожидал ничего хорошего, но оказалось на удивление динамично, бодренько и смотрибельно.

Голубая игуана (Blue Iguana, 2018). На мой взгляд (повторюсь: на мой взгляд) получилось нормальная криминальная комедия. Немного наивная, местами предсказуемая, но при этом обладающая достаточной укуренностью, чтобы понравится мне.

22 мили (Mile 22, 2018). Не понравилось. На экране творится какой-то несуразный бред, а перестрелок и экшена недостаточно, чтобы все это затмить. Единственный светлый момент -- это то, что русские всех сделали :)

суббота, 1 сентября 2018 г.

[prog.actors] Прочитал тут небольшую брошюрку "Designing Reactive Systems" от разработчиков Akka

Разработчики Akka время от времени публикуют небольшие книжонки полурекламного-полуобучающего содержания. Одна из них, а именно "Designing Reactive Systems" оказалась вполне себе даже ничего. Если кто-то имеет самое поверхностное впечатление о Модели Акторов и хочет погрузиться в тему чуть-чуть глубже, дабы понять, нужно ли вообще в Модель Акторов вкладываться или нет, эта брошюра вполне может оказаться полезной. Тем более, что не смотря на обычный изрядный налет маркетингового бла-бла-бла, она действительно дает нормальное и понятное описание достоинств аторов в практическом плане. Без теоретизирования и ухода в абстрактный Computer Science.

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

Так что еще раз повторюсь, брошюра на удивление толковая. По крайней мере большая ее часть. Так что если кто-то только слышал краем уха про акторов, но хочет получить чуть более развернутое представление, то вполне можно эту книжку прочитать. Благо она небольшая и бесплатная. И хоть ее написали люди, плотно работающие с JVM, привязки к Java/Scala в ней нет. То, что там описано, сохраняет актуальность вне зависимости от языка программирования.

PS. Хотя упор на дерево супервизоров -- это не есть характерная особенность Модели Акторов. Можно и по-другому, SObjectizer тому наглядная демонстрация. А в низкоуровневых языках, таких как C++, польза от супервизоров вообще сомнительна.

среда, 29 августа 2018 г.

[prog.c++] SObjectizer: планы на ближайшее будущее и вопросы к заинтересованным читателям

Есть у меня стойкое ощущение, что не смотря на блог, статьи на Хабре, выступления на конференциях и пр., SObjectizer, как инструмент, недостаточно раскручен и известен даже в русскоязычном C++ сообществе. Не говоря уже про англоязычное. В связи с этим на ближайшие пару месяцев (минимум) приоритеты в работах над SObjectizer-ом смещаются в сторону пиара. Т.е. в первую очередь пойдет работа над статьями, презентациями и пр. вещами, которые позволят увеличить publicity. А доработки самого SObjectizer-а будут выполняться по остаточному принципу.

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

Тем не менее, если кому-то чего-то в SObjectizer-е не хватает и вы хотели бы это получить в ближайшей перспективе, а не через три-четыре месяца, то обозначьте свои хотелки явным образом, пожалуйста. Сделать это можно либо через Feature Requests на SourceForge, в Issues на GitHub-е или напрямую мне на email (eao197 на гмайл ком).

В принципе, аналогичная просьба есть и по поводу статей/презентаций, которые мы будем делать в эти ближайшие пару месяцев. Может быть есть какая-то тема, которую бы вы хотели, чтобы мы осветили подробнее. Например, работу с состояниями агентов в SObjectizer-е, запуск нескольких экземпляров SObjectizer-а в одном приложении и т.д., и т.п. Оставляйте свои заявки и это нам поможет подготовить материалы, которые будут полезны именно вам. Оставить заявку можно либо здесь, либо через email (eao197 на гмайл ком).

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

Ну а если кто-то сможет поделиться своей success story, то это будет вообще супер.

PS. А может кому-то хотелось бы видеть SObjectizer (с кооперациями агентов, mbox-ами, диспетчерами, message limits и вот этим вот всем) для другого языка программирования. Какого-нибудь Rust-а, Go, Kotlin-а, Swift-а и т.п.?


На всякий случай продублирую разные свои контакты. Проще и надежнее всего со мной связаться по почте: eao197 на гмайл ком. Так же я есть на LinkedIn, в Facebook-е и на Habr-е. В принципе, через ник eao197 меня можно найти и в Skype, но в последнее время я не часто пользуюсь компом c Windows и Skype, так что через Skype доступен далеко не всегда.

вторник, 28 августа 2018 г.

[life.work] Некоторые впечатления от митапа в Питере

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

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

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

Сложно сказать, какие результаты это выступление принесет нам в долгосрочной перспективе. В краткосрочной мы уже получили неожиданный результат: Павел Бегунков нашел время и сделал небольшое ревью кода SObjectizer-а, указав нам ряд мест, где можно почистить код и поднять производительность. Сейчас с этим как раз и разбираюсь. Многие из косяков имеют древнюю историю и восходят ко временам 2010-го и начала 2011-го годов, когда поддержка C++0x/11 в компиляторах только-только начала появляться и нам приходилось действовать по старинке. Как раз отличный повод все это почистить и выпустить обновленную версию SObjectizer-а.

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

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

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

Поэтому мой совет тем компаниям, которые владеют подобными инструментами и не знают, что теперь с этим делать: избавляйтесь от доморощенных решений. Если только вы не Google, Facebook, Amazon или Yandex.

Есть готовые фреймворки для C++. Не нравится вам SObjectizer -- возьмите C++ Actor Framework, QP/C++ или что-то другое. Если вы не очень представляете себе, что такое наш SObjectizer, какими возможностями он обладает и что с его помощью можно сделать, то пригласите нас рассказать об этом. Я могу подъехать и сделать доклад о SObjectizer-а. Хоть короткий, как на этом питерском митапе, хоть более расширенный и углубленный.

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

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

PS. Слайды доклада можно найти на SlideShare, в Google Docs или в виде PDF-ки на SourceForge.

понедельник, 27 августа 2018 г.

[life.photo] Пичалько...

20180822-141725-DSC_0018

В этот раз решил взять в Питер большой чОрный зеркальный фотоаппарат и пару чОрных объективов к нему: 40mm/2.0 для общих планов и 85mm/1.4 для репортажно-портреного стрит-фото. Думал пройтись по Невскому, поснимать тамошних уличных музыкантов и просто гродских сумашедших фриков, коих в местах большого скопления народа обычно целая уйма. Но врожденная запасливость заставила взять, на всякий случай, еще и старый добрый 50mm/1.4D. Хоть и делал это скрепя сердцем, т. к. лишний груз, лишний объем и т. д.

В первый выход в город вооружился 40mm и 85mm объективами. И где-то после первых 50 кадров, сделанных на 40mm-объектив, случайно обнаруживаю, что какие-то кадры оказываются пересвеченными. А т. к. чОрной зеркалкой не пользовался уже давно, то сразу не понял, в чем дело. Может встроенный экспонометр врет на ярком солнце, может режим экспозамера выставлен неудачно. В общем, что-то идет не так, но вот что, почему и что делать дальше – не понятно.

Перепробовал разное. Но, в итоге, пришел к выводу, что на 40mm-объективе начал барахлить репетитор диафрагмы. На части кадров срабатывает и тогда с экспозицией все ОК. А иногда не срабатывает. Тогда получается, что кадр снимается на полностью открытой «дырке» и пересвет просто жутчайший. Если это действительно проблема в объективе, то это не весело. Объектив «нетрадиционный» – мануальный Voigtlander, зверь в наших краях крайне редкий. Хорошо, если в Гомеле или Минске найдется сервис, который сможет взяться за его ремонт.

В итоге получилось что: взятый «на всякий случай» «полтинник» оказался основным объективом, который я использовал чуть ли не в 90% случаев. Пройтись по Невскому в самое интересное, вечернее, время в этот раз не удалось, поэтому 85-mm «портретник» пролежал без дела.

Самое страшное – это то, что изначально я хотел брать только один объектив, именно Voigtlander. И вот взял бы я его, без какой-либо замены, и чтобы потом делал?

PS. Фулфреймовая никоновская зеркалка даже со старым пластиковым 50mm/1.4D (который и достаточно компактный, и достаточно легкий) – это нифига не тревэл камера. Вот Fujifilm x30 – вот это настоящая трэвел камера. И маленькая, и легкая, и диапазон фокусных расстояний у встроенного зума подходящий, и меньше боится влаги/пыли. Но вот качество изображений, особенно на ISO выше 400 – это просто ахтунг какой-то. У зеркалки со светосильны фиксом огромная фора в качестве изображений. Однако, если захочется приблизится по универсальности к x30, то это нужно уже будет говорить про зум из категории 24-70mm/2.8. А это уже и совсем другие габариты, и совсем другой вес (если я правильно помню, будет что-то около 2кг), и совсем другая цена.

вторник, 21 августа 2018 г.

[life.work] В Питере пить? ;)

Отбываю в Питер делать доклад на митапе St. Petersburg C++ User Group. Пробуду в Питере несколько дней. Совмещу приятное с полезным. Слайды же доклада опубликую на SlideShare уже на следующей неделе, после возвращения домой.

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

[prog.c++] RESTinio обновился до версии 0.4.8

У нас очередной релиз. Наша легковесная C++14 библиотека для встраивания асинхронного HTTP/WebSocket сервера в C++ приложения, RESTinio, обновилась до версии 0.4.8. Изменений не так много, но среди них можно выделить одно весьма важное: нотификаторы для операций записи.

Почему нотификаторы важны? Потому что когда фреймворк для вашего же удобства скрывает от вас всю механику операций ввода-вывода, то вы не знаете, когда именно часть вашего ответа клиенту будет записана в сокет. А это знание может потребоваться, если вы отсылаете большой ответ порциями и вам нужно выстроить эти порции в очередь, чтобы отправлять следующую порцию лишь после того, как уйдет предыдущая. Ну вот, скажем, нужно вам отдать 500MiB порциями по 5MiB, как вам это сделать? Отдать RESTinio все эти 500MiB сразу и пускай RESTinio с ними сам разбирается? А что, если вам нужно отдавать по 500MiB не одному клиенту, а сотне клиентов, или тысяче клиентов?

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

Минималистичный пример использования нотификаторов:

#include <restinio/all.hpp>
#include <iostream>

int main()
{
  restinio::run(
    restinio::on_this_thread<>()
      .port(8080)
      .address("localhost")
      .request_handler([](auto req) {
        return req->create_response()
                 .set_body("Hello, World!")
                 .done( /* Notificator goes here */
                   [](const auto & ec ){
                     std::cout << "Sending response status: " << ec << std::endl;
                   });
      }));

  return 0;
}

Более актуальный пример можно найти в репозитории RESTinio.

В общем, не стесняемся, берем, пробуем, пользуемся, делимся впечатлениями. Любая конструктивная критика, соображения и предложения всячески приветствуются. Так же приветствуются лайки, плюсадынки и решары :) Кому не лень, можно плюсануть соответствующую тему на Reddit-е.

суббота, 18 августа 2018 г.

[life.business] Странные впечатления от одного видео и некоторая рефлексия на тему бизнеса

На LinkedIn попалась на глаза ссылка вот на это видео:

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

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

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

Вообще говоря, размышляя по поводу всей этой хрени вокруг стартапов, подъемов инвестиций и пр. модной лабуды, поймал себя на мысли, что в моем случае занятие бизнесом -- это не попытки выстроить что-то масштабируемое (по типу того, что сделал Рэй Крок с McDonald's) и даже не попытки удовлетворить массовый спрос на что-то. Это скорее попытки научиться продавать тот набор знаний и умений, которым располагает наша команда. Мы не выводим на рынок новый офисный пакет и не выстраиваем очередную розничную сеть продуктовых магазинов, не делаем новый инновационный продукт, который перевернет ваши представления о чем-то. Наша задача -- рассказать о том, что среди множества подрядчиков, задачей которых является эффективная продажа жопочасов криворуких недоучек, есть маленькая команда, которая берет и делает. Осталась самая малость -- научится делать это хорошо.

пятница, 17 августа 2018 г.

[prog.c++] Завершение(?) серии статей про Shrimp на Хабре

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

среда, 15 августа 2018 г.

[prog.c++] Про попытку изобразить strong typedef из подручных средств

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

пятница, 10 августа 2018 г.

[prog.c++] json_dto-0.2.6: небольшое, но довольно важное обновление

Мы сегодня зафиксировали свежую версию 0.2.6 своей легковесной библиотеки json_dto. Там одна новая фича, но, думается, достаточно важная для определенных сценариев работы с JSON-документами.

Дело в том, что мы json_dto делали для себя, для ситуаций, когда JSON-документ хранил внутри единственный сериализованный объект. Т.е. мы имели дело с JSON-документами вида: {"field":...}. А вот на днях один из пользователей json_dto обратил наше внимание на ситуацию, когда JSON-документ представляет из себя вектор из объектов. Т.е. что-то вроде: [{"field":...}, {"field":...}, {"field":...}]. В такой ситуации json_dto оказывался бесполезным.

Этот же пользователь поделился своими соображениями о том, как он бы хотел использовать json_dto в такой ситуации. Он бы хотел иметь возможность написать json_dto::from_json<std::vector<Data>>(json_document) и чтобы результатом был экземпляр std::vector с объектами типа Data внутри.

Собственно, именно это мы и добавили в версию 0.2.6. Теперь можно писать вот так:

#include <json_dto/pub.hpp>

#include <iostream>
#include <algorithm>

struct data_t {
   std::string m_key;
   int m_value;

   template<typename Json_Io>
   void json_io(Json_Io & io) {
      io & json_dto::mandatory("key", m_key)
         & json_dto::mandatory("value", m_value);
   }
};

int main() {
   const std::string json_data{
      R"JSON(
         [{"key":"first", "value":32},
          {"key":"second", "value":15},
          {"key":"third", "value":80}]
      )JSON"
   };

   auto data = json_dto::from_json< std::vector<data_t> >(json_data);
   std::sort(data.begin(), data.end(),
      [](const auto & a, const auto & b) { return a.m_value < b.m_value; });

   std::cout << "Sorted data: " << json_dto::to_json(data) << std::endl;
}

И получать при этом вполне ожидаемый результат:

Sorted data: [{"key":"second","value":15},{"key":"first","value":32},{"key":"third","value":80}]

В общем, кто хочет легко и удобно работать с JSON-ом, то не стесняемся, берем json_dto, пользуемся, делимся впечатлениями. Взять json_dto можно на BitBucket-е или на GitHub-e (со временем версия 0.2.6 подтянется и на vcpkg).

Кстати говоря, с теми, кому json_dto интересен, можно было бы обсудить вот еще что: в принципе, в описанном выше сценарии вовсе необязательно работать только с std::vector<Data>. Запросто может быть использован и std::deque<Data>, std::list<Data> или даже std::array<Data, N>. Если кому-то хотелось бы видеть в json_dto поддержку и других STL-левских контейнеров, а не только std::vector, то дайте нам знать. Постараемся эту поддержку добавить. Ну а если это никому не интересно, то пусть все остается как есть.

среда, 1 августа 2018 г.

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

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

Миссия невыполнима: Последствия (Mission: Impossible - Fallout, 2018). Качественно выполненный аттракцион. Заходишь в кинозал, выключаешь мозги и наслаждаешься красочно сделанным зрелищем. Вполне в духе и на уровне предыдущих частей.

От семьи не убежишь (La ch'tite famille, 2018). Очередная добротная французская комедия с Дени Буном. В которой, местами, видно, что Дени не просто хороший комик, но и хороший актер.

Дыши во мгле (Dans la brume, 2018). Оказалось очень даже неплохо. Не ожидал.

Великий уравнитель 2 (The Equalizer 2, 2018). В принципе, тоже самое, что и в первой части. Только более занудно. Совсем без юмора. И финальная разборка унылая.

Шпионская игра (The Catcher Was a Spy, 2018). Удивительное дело: взяли за основу интересную историю, подтянули хороших актеров, сняли профессионально. А получилось неинтересно с невнятным финалом.

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

Хмарочос (Небоскреб, Skyscraper, 2018). Редкая бредятина. Не смотреть ни в коем случае.

суббота, 28 июля 2018 г.

[prog.memories] Хороший текст был написан почти три года назад. Есть на что оглянуться

В процессе подготовки к митапу в Питере пересматриваю свои старые материалы в поисках того, что можно переиспользовать в докладе. Дошел вот до этой заметки, написанной в августе 2015-го года, т.е. без малого три года назад: It's all about in-process message dispatching или...

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

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

среда, 25 июля 2018 г.

[prog.flame] И вот для этого стоило осваивать Хаскелл?

Люди сообщают с мест:

Компания называется Restaumatic, Польша. Пишем сервисы для ресторанов: заказ еды, системы скидок, сайты, вот это вот все. Обычный web, CRUD, фронтенд на PureScript, бэкенд на Haskell. На самом деле, переписываем потихоньку эту функциональность с RoR и добавляем новую.

Цинк: cpp_stm_free: монадическая STM библиотека для параллельного программирования.

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

Мне, например, нравится использовать C++ в вещах, связанных с низким или более-менее низким уровнем. Протоколы какие-нибудь реализовывать, устройствами какими-нибудь управлять, писать ядра СУБД или MQ-брокеров, ресурсы экономить (выжимать тактики из битиков, как кто-то когда-то хорошо сказал). Но это прежде всего потому, что сами эти задачи мне нравятся. А C++ оказался весьма хорошо приспособлен для таких задач.

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

А тут Web-приложение с бэкэндом на Хаскелле, которое суть складской учет, который во времена оные отлично покрывали dBase-ами и Clipper-ами... Нужно, наверное, очень сильно любить Хаскелл ;)

PS. Интересно было бы лет через 5-10 узнать, чем все закончилось. А то вспоминается пример Sociomantic-а, в котором когда-то выбрали в качестве языка реализации D1, а потом столкнулись с тем, что есть большая и работающая кодовая база на D1, который уже никому не нужен, и есть совсем другой D2, который с D1 не совместим ни на уровне языка, ни на уровне библиотек. Но там хотя бы выбор шустрого D был оправдан требованиями к скорости реакции. Ради чего выбирать Хаскелл для рядового Web-приложения -- это вопрос.

понедельник, 23 июля 2018 г.

[prog.c++] В августе буду выступать на митапе St.Petersburg C++ User Group

Благодаря Анастасии Казаковой из JetBrians в августе, 23-го числа (четверг), выступлю в Питере на митапе тамошней C++ User Group с докладом "Акторы в C++: взгляд старого практикующего актородела". Все подробности и возможность зарегистрироваться на митап вот здесь.

Этот доклад будет квинтэссенцией из моих предыдущих докладов на CoreHard C++ и C++ Russia. Предыдущие доклады были сильно ограничены по времени: всего сорок минут на само выступление + 10-15 минут на вопросы. Здесь же будет практически часовое выступление, в процессе которого я постараюсь затронуть основные моменты, связанные с акторами в C++. Т.е. что такое Модель Акторов вообще и почему к ней сейчас такой интерес. Имеет ли смысл использовать акторы в C++ (да, имеет, но не всегда). Какие особенности накладывает C++ при этом. Что есть готового для C++ вообще, почему это настолько сильно отличается друг от друга. Ну и немного про SObjectizer, конечно. В общем, то, что раньше приходилось растягивать на 3-4 отдельных доклада в этот раз будет выдано в рамках одного рассказа, без лишней воды и философствований.

В общем, приходите, должно быть интересно. По крайней мере можно будет посмотреть на меня живьем и задать какой-нибудь неудобный вопрос в лицо. Вроде того, почему я такой муд так сильно не люблю Rust Java, пора ли закапывать С++ и есть ли жизнь в ИТ после сорока ;)