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

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

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

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

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

[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 доступен далеко не всегда.

[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.

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

В этот раз решил взять в Питер большой чОрный зеркальный фотоаппарат и пару чОрных объективов к нему: 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кг), и совсем другая цена.