вторник, 29 декабря 2020 г.

[prog.c++] RESTinio-0.6.13: последний большой релиз в 2020-ом и, возможно, вообще последний в рамках ветки 0.6

Состоялся очередной релиз RESTinio: версия 0.6.13, в которой таки были реализованы идеи по выстраиванию обработчиков запросов в цепочки (по аналогии с ExpressJS-овскими middleware). Подробнее про новшества версии 0.6.13 я собираюсь рассказать в отдельной статье на Хабре. Кто не хочет ждать, тот может заглянуть в нашу документацию.

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

В пользу того, чтобы перестать развивать ветку 0.6 и начать делать новую 0.7 говорит несколько факторов (порядок их перечисления случаен):

  • в RESTinio уже накопилось несколько моментов, которые требуют переделки (какие-то из них прямо в коде помечены как FIXME). А эта переделка невозможна без слома текущего API;
  • до сих пор в RESTinio поддерживался только http/1.1. Думаю, чтобы двигаться дальше нужно добавлять в RESTinio и http/2, и http/3. А на такую мультпротокольность RESTinio не был расчитан. Непонятно, можно ли уместить поддержку мультипротокольности в существующую архитектуру и API RESTinio. Поэтому проще заниматься этим вопросом без оглядки на совместимость с предыдущими версиями RESTinio;
  • поддержка цепочек обработчиков, которая появилась в 0.6.13, распространяется только на синхронные обработчики. А хочется иметь такую же и для цепочек асинхронных обработчиков. Но придумать как это сделать в рамках версии 0.6 у меня не получилось. Есть смутная идея, но она требует изменения API;
  • сейчас RESTinio сперва полностью загружает в память входящий запрос и лишь затем вызывает обработчик для него. Хочется добавить режим работы, в котором RESTinio сможет отдавать входящий запрос на обработку частями, без предварительного накопления всего содержимого запроса;
  • один из важнейших факторов: лежащая в качестве базы RESTinio внешняя библиотека http-parser осталась без сопровождения. Поэтому в RESTinio парсер HTTP нужно заменить на что-то. Либо на другую готовую стороннюю библиотеку, либо на свой собственный велосипед. Такая замена существенно изменит список зависимостей для RESTinio, а это уже точно ведет к переходу к следующему номеру в версии.

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

Сколько времени это займет и когда можно ждать 0.7.0 не могу сказать. Вряд ли раньше весны 2021-го.

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

Сразу хочу сказать по поводу поддержки клиента в RESTinio. Без внешнего финансирования мы не сможем поднять эту тему. Так что если кто-то использует RESTinio на работе и хотел бы с помощью RESTinio обслуживать не только входящие, но и исходяще соединения, то рассмотрите, пожалуйста, возможность заказать такую доработку RESTinio у нас. Цена вопроса, думаю, будет где-то в районе 3.5-6k USD.


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

Если кто-то хочет помочь в развитии RESTinio, то на данный момент одним из самых больших подспорьев для нас является распространение информации о RESTinio. Каждое упоминание RESTinio в Интернете (Facebook, LinkedIn, Reddit-е, HackerNews, Twitter, Slack, Telegram и т.д.) поддерживает нашу мотивацию и желание развивать RESTinio дальше.

суббота, 12 декабря 2020 г.

[prog.c++] Думаю как добавить в RESTinio что-то похоже на middleware из Express.js

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

В общем, если кто-то интересуется развитием RESTinio, то милости прошу: https://github.com/Stiffstream/restinio/discussions/140

ЗЫ. За подобие английского прощу не бить, это лучшее, на что способны Google-Translate в паре с Grammarly в настоящее время ;)

среда, 2 декабря 2020 г.

[prog.c++] SObjectizer-5 десять лет! Мой субъективный взгляд на его прошлое и настоящее

В октябре 2010-го года начались работы над SObjectizer-5. Что означает, что SObjectizer-5 развивается уже десять лет.

Немаленький срок.

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

Вот о чем пойдет речь:

Подробности под катом (букв очень много)...

вторник, 1 декабря 2020 г.

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

Напоминание: вначале идут фильмы/сериалы, которые понравились больше, в конце же те, которые понравились меньше или вообще не понравились.

Бонусом в конце идет поток лучей понятно чего в адрес Нолановского "Довода".

Прекрасная эпоха (La Belle Époque, 2019). Отличное кино. Но, может быть, будет не так интересно для зрителей моложе 40 (не говоря уже про зрителей моложе 30).

День курка (Boss level, 2019). Бюджетная и камерная вариация на тему "Грани будущего" и "Дня сурка". Но бодренько. Так что мне зашло очень хорошо.

Легендарное ограбление (Vault, 2019). Своеобразно снят. И эта своеобразная манера съемки может кого-то оттолкнуть от просмотра. Сама история интересная, но как-то уныло рассказано. В общем, так себе кино. Но на безрыбье может и сойти.

Ребекка (Rebecca, 2020). Картинка отличная, просто услада для глаз. Визуально все сделано очень хорошо. Но вот за сюжетом следить было не интересно, сопереживания никто из героев не вызвал, сплошная скукота.


Отдельных слов заслуживает Довод (Tenet, 2020) Кристофера Нолана. Общее впечатление можно передать одной фразой: "Хочешь почувствовать себя идиотом? Посмотри "Довод"!"

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

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

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

Напоминание: вначале идут фильмы/сериалы, которые понравились больше, в конце же те, которые понравились меньше или вообще не понравились.

Фильмы

Афера века (El robo del siglo, 2020). Аргентинская картина, поэтому стилистика совершенно не похожа ни на европейское, ни на голливудское кино. Плюс интересная история. Так что посмотрел с удовольствием.

Прощай (Adiós, 2019). Испанская криминальная драма. Посмотрел с интересом. Странная вариация на тему социальной чернухи в стиле соцреализма, но с неизбежным хэппи-эндом.

Сериалы

Пацаны (The Boys, 2020). Второй сезон мне зашел даже лучше, чем первый. Местами ронял челюсть на пол от восторга. И, в отличии от первого сезона, здесь они поставили хорошую точку в конце истории. Естественно, с толстым намеком на продолжение, но сюжетную линию, начатую в первом сезоне, довели до логического итога, а не оборвали где-то посередине, за что авторам отдельное спасибо.

Банды Лондона (Gangs of London, 2020). Первый сезон. За жесть, кровь и кишки твердая пятерка. А вот сюжет, поведение неврастенических персонажей и мотивацию героев... Как будто все это сделали по остаточному принципу в довесок к экшену.

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

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

Напоминание: вначале идут фильмы/сериалы, которые понравились больше, в конце же те, которые понравились меньше или вообще не понравились.

Одиссея (L'odyssée, 2016). Посмотрел с большим интересом и удовольствием. Но может это потому, что когда-то в детстве с восторгом смотрел "Подводную одиссею команды Кусто" в "Клубе путешественников". Не знаю, насколько интересен фильм будет для тех, кто мало знает про Жака-Ива Кусто.

Лекарство от здоровья (A Cure for Wellness, 2017). Очень красиво снято. Некоторые планы просто вызывают восторг. Но вот сюжет и развязка меня лично разочаровали.

Полицейский седан (Crown Vic, 2019). Мог бы стать неплохим фильмом в духе чернушного перестроичного соцреализма конца 1980-х. Но оказался слишком скучным и затянутым.

Чистая кожа (Cleanskin, 2012). Мне показалось, что это какая-то дипломная работа выпускника заштатного фильмостроительного ПТУ. В который непонятно как удалось затянуть Шона Бина и Шарлотту Рэмплинг. Можно не смотреть.

Запретная зона (2020). Дебильный фильм с дебильным сценарием и дебильными персонажами, совершающими дебильные поступки.

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

Напоминание: вначале идут фильмы/сериалы, которые понравились больше, в конце же те, которые понравились меньше или вообще не понравились.

Дело Коллини (Der Fall Collini, 2019). Мне показалось, что фильм посредственный и потенциально интересная тема не была должным образом раскрыта. Но зато с удовольствием посмотрел на Франко Неро, который настоящей глыбой выделялся на фоне молодых актеров.

Переводчики (Les traducteurs, 2019). Лично меня не впечатлило: было скучновато и объяснение происходящего в конце фильма меня не убедило. Но посмотреть можно.

Поезд в Пусан 2: Полуостров (Bando, 2020). Жалкое паразитирование на успехе первого фильма. Любители фильмов для зомби могут глянуть, но только "ради галочки".

Агент Ева (Ava, 2020). Еще одна попытка заснять "Джона Уика в юбке", по типу "Взрывной блондинки". Но, в отличии от "Взрывной блондинки", где был драйв под качественно подобранный саундтрек, здесь же получились сопливые сопли с каким-то унылым и неестественно выглядящим экшеном. Смело можно не смотреть.

пятница, 27 ноября 2020 г.

[life.memories] Тридцать лет в программизме

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

понедельник, 23 ноября 2020 г.

[soft.process] Погружение в Agile: заметки на полях. О какой документации говорят Agile-коучи?

Очередное наблюдение по ходу погружения в тему Agile. В Agile-манифесте есть постулат: "Работающий продукт важнее исчерпывающей документации".

И вот я сталкиваюсь с тем, что Agile-коучи, рассказывая об Agile, интерпретируют его как-то так (не дословно, но общий смысл сохранен):

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

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

Т.е. суть старых подходов, которым противопоставляется Agile, в том, что на i-ой стадии мы максимально подробно прорабатываем и исчерпывающе документируем требования к тому, что будет делаться на (i+1)-ой стадии. Т.е. сперва документация, потом работа согласно этой документации. Из-за чего (i+1) стадия в условном водопаде физически невозможна, если нет исчерпывающей документации.

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

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

Так вижу.

пятница, 20 ноября 2020 г.

[soft.process] Погружение в Agile: записки на полях. В Agile под гибкостью понимается вовсе не свобода внутри проектной команды

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

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

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

А если сказать более грубо, но более точно, то "agile" -- это про гибкость в удовлетворении заказчика.

Образно выражаясь, до появления Agile исполнитель с заказчиком договаривались, после чего исполнитель исчезал с радаров и принимался делать то, о чем договорился. А заказчик остался в одиночестве ждать, пока ему принесут результат. Время от времени заказчика кормили завтраками и ему оставалось только надеяться, что все будет хорошо.

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

И вот в конце-концов заказчику доставляют результат и наступает одно большое удовлетворение. Или не большое. Или неудовлетворение. Но одно. И сразу.

Этого мало. А ждать этого приходится слишком долго.

И вот тут весь такой в белом Agile позволяет сделать удовлетворение растянутым во времени. Сегодня удовлетворили чуть-чуть, через неделю еще чуть-чуть, через две недели еще чуть-чуть. Клиент ощущает постоянно внимание к своей персоне.

Результаты показываются по чуть-чуть. Более того, по другому-то и нельзя. Ибо что будет в финале толком никто не знает, т.к. изначально договаривались только о том, что конкретика будет определяться по мере следования.

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

Именно это и подразумевается под "гибкостью" в Agile. Если вдруг заказчик решил, что удовлетворить его могут только перламутровые пуговицы, то мы гибко к этому приспособимся и удовлетворим заказчика по-новому.

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

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


Прошу простить мне мою отсталость в отношении Agile. В последний раз плотно с этой темой приходилось сталкиваться где-то в 2013-ом. Затем работать можно было так, как удобно, а не как модно-молодежно. Так что приход церкви святого Agile со SCRUM-ом в виде пророка остался за кадром :)

четверг, 19 ноября 2020 г.

[prog.flame] В этих наших Интернетиках уже начали закапывать Rust?

Как я могу видеть, новость о том, что экспериментальный браузерный движок Servo, который долгое время был флагманской разработкой на Rust-е, передан под крыло Linux Foundation, вызвала разговоры о том, что к Rust-у постепенно приближается северный пушной зверек. Типа сперва Mozilla выгнала команду разработчиков Rust-а на мороз, теперь вот Servo отправили в могильник. И светлое будущее, о котором так много говорили растофанаты, неизбежно сменяется унылым настоящим с беспросветными перспективами...

Мое отношение к ситуации вокруг Rust-а после всего, что происходит с Mozilla, можно выразить известным афоризмом: Rust рискует простудится на наших похоронах.

Или, другими словами, Rust скорее всего переживет многих, кто ждет его смерти. Как это уже случилось с COBOL-ом и Fortran-ом.

Да, Rust лишается хорошей крыши. И вряд ли обретет другую такую же.

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

Кто-то, наверное, может сказать, что по сравнению с Python-ом того же Ruby и нет. Но по факту, всего трем-четырем языкам довелось получить популярность и распространенность, которая есть у Python-а (в их число входят, наверное, еще чистый C, Java и JavaScript). Все остальный вынуждены довольствоваться лишь долей той распространенности, которой обладает Python.

Так что если со временем популярность и распространенность Rust-а окажется на уровне нынешней популярности и распространенности Ruby, то Rust спокойно проживет еще не одно десятилетие.


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

Во-первых, это величина хайпа, который все еще сопровождает Rust. Я ничего подобного не могу припомнить со времен пришествия Java. Но там-то были миллионы долларов, целенаправлено вложенных Sun-ом в маркетинг. В случае же с Rust-ом хайп генерируют восторженные пользователи. И это странно. Ну не может быть у Rust-а такой армии активно использующих его программистов. Большая часть раздувателей хайпа -- это просто сочувствующие, не написавшие на Rust-е ничего сложнее очередного HelloWorld-а.

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

Во-вторых, это ниша применения Rust-а.

Да, вероятно, Rust -- это лучшая замена чистого C и даже C++ на данный момент. Проблема, однако, в том, что сама ниша применения C и C++ в последние годы сужается. И это правильно. Так что, в перспективе, для массового софтостроения Rust так же (не)нужен, как и C++.

Поэтому полагаю, что для многих Rust является отдушиной после мира Java, C#, Python-а, JavaScript-а и Ruby. Которые либо не слишком быстрые, либо слишком тяжелые (в плане run-time). И Rust у этих людей вызывает восторг потому, что пока что не видно хорошего, простого и удобного языка с GC, который бы компилировался в нативный код и не требовал бы таскать за собой многомегабайтные JVM/.NET.

Таким языком мог бы в свое время стать D. Но не стал.

Зато таким становится Go. Хотя Go все-таки пока слишком убог и не нравится тем, кто привык к традиционному ООП, полноценным генерикам (шаблонам) и синтаксическому сахару.

В общем, думаю, что если бы на данный момент были полноценные и кросс-платформенные условные JavaNative, C# Native или KotlinNative, то и интерес к Rust-у со стороны нынешних JavaScript-еров и Python-истов был бы гораздо меньше.

А вообще, вот этот пост почти что двухлетней давности еще не утратил своей актуальности ;)

среда, 18 ноября 2020 г.

[life] Пора возвращаться в поле зрения радаров?

Промежуточная отметка в истории, начатой три месяца назад (предшествующие серии: раз, два).

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

Еще не ожидал, что все происходящее у нас сейчас настолько сильно будет напоминать брожение умов интеллектуалов и интеллигенции времен перестройки в СССР. Когда все ощущали себя пупом Земли и центром Мира, выкрикивали лозунги "Партия, дай порулить!", точно знали как жить, а потом едва-едва выживали в 90-е.

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

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

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

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

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

Так что постепенно пытаюсь вернуться в FB и VK.

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

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

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

Но делайте это, пожалуйста, без меня.

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

Сам постараюсь про политику ничего не писать. Работа, хобби, увлечения. Да просто о жизни... Есть же целая куча тем для нормального общения.

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

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


PS. Будут ли выходить кинообзоры не знаю. Я тут в последнее время заметок о просмотренных фильмах особо не делал. Да и смотреть как-то было нечего.

[prog.c++] Обработка событий агента с учетом приоритетов в SObjectizer: нужно, не нужно, если нужно, то как именно?

Этот пост служит предложением к разговору о том, что и как может быть добавлено в SObjectizer. Или о том, что не нужно добавлять.

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

Сейчас появилась возможность вплотную заняться данным issue. Хотя с этой темой не так все просто.

Суть проблемы в том, что в SObjectizer-5 все события у агентов равноприоритетны. Т.е. если агенту отсылаются сообщения вот в таком порядке: msg_A, msg_B и msg_C, то обрабатываться эти сообщения будут в таком же порядке.

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

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

Получается, что у кого-то из пользователей SObjectizer есть потребность в приоритизированной обработке сообщений для одного агента. Которую либо нужно удовлетворить в самом SObjectizer (или в so5extra), либо нужно показать, как этого же эффекта достичь без допиливания SObjectizer-а под себя.

Пока есть более-менее свободное время хочется либо закрыть issue 17 добавлением в SO-5/so5extra новой функциональности, либо написанием примера (примеров) с демонстрацией получения искомого результата имеющимися средствами.

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

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

пятница, 13 ноября 2020 г.

[wow] Хочешь попасть в Лабораторию Касперского? Изучай SObjectizer! :)

Сам офигел когда увидел:

Цинк (не знаю, как долго будет актуальным).

четверг, 12 ноября 2020 г.

[prog.c++] Библиотека RESTinio обновилась до версии 0.6.12

RESTinio продолжает развиваться. Выкатили версию 0.6.12. В этой версии появились возможности для более жесткого контроля за тем, что приходит от клиента. Что может помочь в случае, если написанный на базе RESTinio сервис смотрит напрямую в Интернет, а не прячется за каким-то proxy-сервером.

Если кому-то интересны потроха RESTinio, то на Хабре опубликована свежая статья о том, как новая функциональность включается/выключается посредством C++ных шаблонов.

По поводу дальнейшего развития RESTinio можно сказать следующее: соображения о том, куда двигаться дальше, есть. Часть озвучивалась ранее, часть нет (как из суеверия, так и из недостаточной проработки). Но тут нужно понимать простую вещь: RESTinio напрямую нам денег не приносит, поэтому что-то новое в RESTinio появляется только тогда, когда у нас находятся для этого и время, и возможности. Се ля ви.

В завершение хочу сказать спасибо всем, кто выбрал и использует RESTinio. Вы ведь могли предпочесть что-то другое, но сделали правильный выбор ;) За что вам большое спасибо.

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

понедельник, 9 ноября 2020 г.

[work.memories] Понастальгировал читая статью про интерфейсы SCADA-систем

Свежая статья на Хабре под названием "Что не так с интерфейсами SCADA-систем" всколыхнула давно забытые воспоминания...

Картинка из хабровской статьи

Прошло уже 20 лет как я ушел из темы АСУТП, а люди продолжают рисовать "красивые" мнемосхемы в графических редакторах, подкладывать итоговый битмап в качестве фона, поверх которого уже отрисовывается оперативная информация.

Дело в том, что когда в первой половине 90-х в нашем местном КБ системного программирования руководитель отдела АСУТП Аркадий Косарев задумал сделать принципиально новую объектно-ориентированную SCADA систему, одним из требований к ней было использование векторных, а не растровых мнемосхем. Как раз потому, что уже в 1994-ем было понятно, что будут экраны разных разрешений и перерисовывать одно и то же для 640x480 и 1024x768 не вариант.

Как раз под этот проект Косарев собрал в своем отделе сильную команду, в которую вошли и несколько молодых специалистов, включая меня. И эта команда в итоге сделала SCADA Objectizer (реинкарнацией которого и является SObjectizer).

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

[life.sport] Маленькое послесловие к завершившимся велосипедным гранд-турам

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

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

На Тур де Франс и Джире победители общего зачета определились лишь в последний(!) соревновательный день. И на Вуэльте в последний соревновательный день идущий на второй позиции Карапас таки успешно атаковал Роглича и сумел финишировать на этапе на 20 секунд раньше своего соперника, но этого не хватило. Разрыв между первым и вторым местом на Вуэльте в результате составил всего 24 секунды. Всего 24 секунды после трех недель гонок! Кстати, разрыв на Туре ~50 секунд, на Джире ~40 секунд. Во всех трех гонках между первым и вторым местом меньше минуты.

В общем, феноменальный год.

Теперь бы дождаться следующего...

Пожелаю всем спортсменам, болельщикам, а так же читателям мого блога здоровья. Берегите себя!

четверг, 5 ноября 2020 г.

[books.management] Прочитал давеча книжицу от Додо Пицца про Додо Пиццу

Некоторое время назад заказали пару пицц с доставкой из местной "Додо Пицца". В доставку нам вложили и книжицу "Додо книга. Как прыгать выше головы, ловить волну, двигать горы и менять мир"

Сначала она где-то валялась без дела, а вот давеча попалась на глаза и, в условиях добровольной самоизоляции, я ее таки прочитал. Благо времени на это много не потребуется, ибо текста там не так уж много, а объема добавляют картинки и специфическое оформление.

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

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

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

понедельник, 2 ноября 2020 г.

[work] Маэстро художественного слова в ИТ

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

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

Такие люди в нашем ИТ-шном мире очень ценны, поскольку они, как никто другой, могут "ездить по ушам" заказчика. Если нужно созвать совещание, на котором будут самые высокие представители договаривающихся сторон, то без подобных разговорчивых людей не обойтись. Уболтают любого. Или если нужно написать маркетинговую статью о том, как в нашем непростом и постоянно меняющемся мире, где никто не защищен от проблемы X новая мегатехнология Y от вендора Z станет настоящим спасением. Причем так, что ничего конкретного ни о X, ни о Y сказано не будет, но зато останется впечатление, что вендор Z -- это вот прямо молодцы.

У меня есть ощущение, что у них в голове сложилась какая-то огромная, очень сложная картина мира. Покрытая плотным туманом.

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

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

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

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

пятница, 30 октября 2020 г.

[life.business] Несколько слов о "спиральной динамике" вообще и о графомании ее апологета Максима Цепкова в частности

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

Источник изображения здесь

Клер Грейвз, его теория, спиральная динамика поверх теории Грейвза

вторник, 27 октября 2020 г.

[work] Наткнулся тут на невероятное...

В поисках информации о "спиральной динамике" нашел такого автора на vc.ru: Максим Цепков. А среди его статей ознакомился вот с этой: "Реальность цифрового мира: проекты делает некомпетентная команда". И вот в этой статье практически сходу споткнулся о пару-тройку моментов, которые заставили всерьез задуматься о том, а не сказочный ли пишет все эти буквы? Уж простите мне мой французский, но запись в блог сразу после прочтения, еще под свежими впечатлениями.

Итак, цитата:

Получается, что нам нужно делать проекты некомпетентной командой. В то время в любом учебнике по менеджменту написано: обязательным условием для успеха проекта является компетентная команда, поэтому определите, какие компетентные специалисты вам нужны, найдите их и привлеките к проекту. Это оказывается невозможным. Как можно ли в таких условиях успешно делать проекты?

Оказывается, для этого уже давно есть методы. Первые из них появились, естественно, в IT как раз тогда, когда было осознанно, что регламенты и правила не работают, а ключевым фактором успеха является человеческий фактор. Об этом есть классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

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

Что меня здесь смущает?

Первое. Agile и персоналки. Если я правильно помню, то первопроходцы Agile делали приснопамятную систему расчета компенсаций для Крайслера в 1993-1999 годах как раз таки не для персоналок вообще, а для мейнфреймов. Могу ошибаться, поэтому если кто-то владеет информацией лучше меня, то поправте плиз.

Далее, период развития интереса к Agile, начиная с появления Agile Manifesto -- это уже нулевые годы. Когда у персоналок был не то, чтобы приход. Они уже давно пришли. А приход тогда как раз был у Web-а. И именно в конце 1990-х и начале нулевых стартовал и нарастал массовый переход от десктопа к Web-у. В условиях когда не было ни толком развитых Web-технологий, ни опытных Web-разработчиков, зато спрос на Web-разработку был сумасшедший. Так если уж благодаря чему-то Agile и взлетел, так это благодаря Web-разработке.

Второе. Что-то мне трудно припомнить, чтобы в 1990-е в России после распада оборонки квалифицированные инженеры массово уходили в айтишники. При том, что как раз в оборонке до 1990-х огромное количество разработчиков и трудилось. А потом осталось без куска хлеба. В прямом смысле. И поэтому уже существующие профессиональные кадры разбегались и выживали кто как может: кто-то уехал, кто-то переквалифицировался на бух- и складской учет (dBase/FoxBase/Clarion, а затем и 1C с Галактикой и Ко), кто-то ушел в преподавание, кто-то смог уйти в сисадмины (в банках в то время был большой спрос), кто-то тупо торговал широпотребом на рынке.

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

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

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

[prog.c++] Особенность aggregate initialization в современном C++, о которой я и не подозревал

Некоторое время назад попробовал разобраться с тем, как работает трюк, описанный в статье "Reflection in C++14". И очень долго тупил и не понимал, как же так получается, что попытки увеличивать количество параметров в выражении aggregate initialization ведут к должному результату... Т.е. сперва делается T{a1}, затем T{a1, a2}, затем T{a1, a2, a3} и т.д. И останавливается это все на aN, где N и есть количество полей в структуре T.

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

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

#include <iostream>

struct Demo {
    int a_;
    int b_;
    int c_;
    int d_;
};

std::ostream & operator<<(std::ostream & to, const Demo & d) {
    return (to << '(' << d.a_ << ',' << d.b_ << ',' << d.c_ << ',' << d.d_ << ')');
}

int main() {
    {
        Demo d{};
        std::cout << "First: " << d << std::endl;
    }
    {
        Demo d{10};
        std::cout << "Second: " << d << std::endl;
    }
    {
        Demo d{104215};
        std::cout << "Third: " << d << std::endl;
    }
}

Вот уж, что называется, век живи, век учись, а помрешь все равно дураком ;)

среда, 21 октября 2020 г.

[prog.c++] json_dto-0.2.11 released

json_dto is a thin wrapper around RapidJSON library we wrote several years ago. It's surprising for us that this small bicycle is used by someone outside our team. Sometimes users show us use-cases we just weren't thinking about. And we add new features to json_dto to fulfill expectations.

The last updates to json_dto add a possibility to customize formatting of (de)serialized values by specifying custom Reader_Writers. For example let's imagine that we have a struct with a `std::map<std::uint32_t, int>` field:

struct example_data {
   std::map<std::uint32_tint> m_weights;
   ...
};

It's impossible to write a simple (de)serialization code for example_data in the form:

struct example_data {
   std::map<std::uint32_tint> m_weights;
   ...

   template<typename Io> void json_io(Io & io) {
      io & json_dto::mandatory("weights", m_weights)
         ...
         ;
   }
};

because RapidJSON expects string values as keys, but json_dto (de)serializes `std::uint32_t` as integers. And the naive implementation of `json_io` shown above leads to run-time error during serialization.

Now json_dto allows to use custom formatters for fields to be (de)serialized:

struct simple_reader_writer {
   // Those methods will be used for (de)serializing of map's keys.
   void read(
      json_dto::mutable_map_key_t<std::uint32_t> & key,
      const rapidjson::Value & from) {
      ... // Deserializing key from a string.
   }
   void write(
      const json_dto::mutable_map_key_t<std::uint32_t> & key,
      rapidjson::Value & to,
      rapidjson::MemoryPoolAllocator<> & allocator) {
      ... // Serializing key as a string.
   }

   // Those methods will be used for (de)serializing of map's values.
   void read(
      int & v,
      const rapidjson::Value & from) {
      json_dto::read_json_value(v, from); // Just reuse json_dto.
   }
   void write(
      const int & v,
      rapidjson::Value & to,
      rapidjson::MemoryPoolAllocator<> & allocator) {
      json_dto::write_json_value(v, to, allocator); // Just reuse json_dto.
   }
};

struct example_data {
   std::map<std::uint32_tint> m_weights;
   ...

   template<typename Io> void json_io(Io & io) {
      io & json_dto::mandatory(
              // Explicit specification of custom Reader_Writer for that field.
              // The usage of apply_to_content_t tells that custom formatter
              // should be applied to every item of the container.
              json_dto::apply_to_content_t<simple_reader_writer>{},
              "weights", m_weights)
         ...
         ;
   }
};

So now keys of `example_data::m_weights` will be (de)serialized as strings.

But custom Reader_Writers allow to go further. Let's imaging that `example_data` contains yet another `std::map<uint32_t, int>`:

struct example_data {
   std::map<std::uint32_tint> m_weights;
   std::map<std::uint32_tint> m_colors;
   ...
};

where keys of `example_data::m_colors` should be represented in the form `#xxxxxx`, where `xxxxxx` is hexadecimal representation.

We can create another custom Reader_Writer:

struct color_hex_reader_writer {
   // Those methods will be used for (de)serializing of map's keys.
   void read(
      json_dto::mutable_map_key_t<std::uint32_t> & key,
      const rapidjson::Value & from) {
      ... // Deserializing key from a string.
   }
   void write(
      const json_dto::mutable_map_key_t<std::uint32_t> & key,
      rapidjson::Value & to,
      rapidjson::MemoryPoolAllocator<> & allocator) {
      ... // Serializing key as a string.
   }

   // Those methods will be used for (de)serializing of map's values.
   void read(
      int & v,
      const rapidjson::Value & from) {
      json_dto::read_json_value(v, from); // Just reuse json_dto.
   }
   void write(
      const int & v,
      rapidjson::Value & to,
      rapidjson::MemoryPoolAllocator<> & allocator) {
      json_dto::write_json_value(v, to, allocator); // Just reuse json_dto.
   }
};

and use it for (de)serialization of `example_data::m_colors`:

struct example_data {
   std::map<std::uint32_tint> m_weights;
   std::map<std::uint32_tint> m_colors;
   ...

   template<typename Io> void json_io(Io & io) {
      io & json_dto::mandatory(
              json_dto::apply_to_content_t<simple_reader_writer>{},
              "weights", m_weights)
         & json_dto::mandatory(
              json_dto::apply_to_content_t<color_hex_reader_writer>{},
              "colors", m_colors)
         ...
         ;
   }
};

The full working example can be seen here.

PS. I don't like to answer questions like "Is json_dto better than nlohmann::json, cereal or any other similar library?" We started to use RapidJSON several years ago and we didn't know about many of the JSON-libraries well known today. At some time we decided to simplify our marriage with RapidJSON and wrote json_dto. Since then it's easier for us to continue to use json_dto than to switch to any other library. So if you are happy with nlohmann::json there is no need to see for something else. But if you have to stay out of nlohmann::json for any reason there is json_dto ;)

PPS. We love reinventing bikes and we know how to do it: RESTinio and SObjectizer are also out of our garage.

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

[prog.c++] The follow-up for "What's new in rotor v0.09" article

There is a new article "What's new in rotor v0.09" that tells several things about yet another C++ actor framework named "rotor". As for me it's a good example of how different implementations of Actor Model could be. And it's a good reason to write some words about SObjectizer's features to show how the same things were addressed a long time ago.

Before I start, it's necessary to note that some of the decisions described below are rather philosophical than technical ones. It also means that some decisions taken from philosophical standpoints had a significant impact on technical aspects of SObjectizer's internals and API, and on applications built on top of the SObjectizer.

четверг, 8 октября 2020 г.

[prog.c++] Наш RESTinio упомянули в докладе про I/O Objects из Networking TS на CppCon2020

При просмотре доклада "The Networking TS from Scratch: I/O Objects" от Robert Leahy уронил челюсть на пол при появлении вот этого слайда:

Отрадно. Не зря, выходит.

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

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

[prog.c++] Смешанные впечатления от трюка с dont_deduce

Несколько дней назад на Reddit-е появилась ссылка на статью dont_deduce<T>. Если кто не читал, но итересуется различными плохоосвещенными закутками языка C++, то рекомендую. Станет понятно, зачем в C++20 появился шаблон std::type_identity.

На меня знакомство с трюком dont_deduce/type_identity произвело двойственное впечатление.

С одной строны, интересно было о нем узнать. Никогда о подобных вещах не задумывался, а тут такое! :)

Но, с другой стороны, C++ вполне обоснованно критикуют за то, что в C++ часто и бесконтрольно происходит автоматическая конвертация типов. Начиная от (может быть) безобидных преобразований из int в float/double и заканчивая неявным вызовом конструкторов классов с единственным параметром (как, например, конструирование std::string из строкового литерала). А применение трюка dont_deduce/type_identity, как по мне, есть не что иное, как целенаправленное закладывание в код этих самых неявных преобразований типов. О которых другой программист, использующий ваши API, скорее всего, даже не будет знать.

Так что я бы лично предпочел бы получить от компилятора ошибку о том, что он не может вывести шаблон функции т.к. один параметр имеет тип Vec3<float>, а второй -- int. Чтобы поправить код и явным образом вписать константу 1f вместо 1.

Возможно, трюк dont_deduce/type_identity может применяться в коде шаблонных функций/классов. В котором приходится хардкодить константы (типа явно описываемых в коде единичек или ноликов). Но в современном C++ есть же всякие decltype, чтобы легко определить какой тип должны иметь захардкоженные константы, так что серьезной проблемы из-за неприменения dont_deduce/type_identity я не вижу.

Итого: если кто-то не в курсе что такое dont_deduce/type_identity, то ознакомиться с вышеозначенной статьей полезно. Но вот наскольо оправданно будет применение этого трюка на практике... Это большой вопрос.

суббота, 3 октября 2020 г.

[life] Осенью в Гомеле зацвел каштан

Нынешний 2020 год продолжает удивлять и подкидывать вещи, которые раньше видеть не доводилось.

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

Просто афигеть.

20201002-IMG_20201002_150108

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

А тут второе цветение дерева, с которого еще не осыпались созревшие каштаны.

Просто афигеть.

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

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

среда, 30 сентября 2020 г.

[prog.opensource] c-smile собирает средства на перевод sciter в OpenSource

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

Так вот, уже много лет c-smile делает в одиночку проект sciter. Это встраиваемый HTML/CSS движок, который может использоваться для разработки легковесных GUI-интерфейсов на базе Web-технологий.

Оказывается, в середине сентября c-smile открыл на Kikstarter-е компанию по сбору средств для перевода sciter в категорию OpenSource: Open Source Sciter Engine.

Хоть сам я sciter-ом никогда не пользовался, но, как по мне, начинание хорошее. Посему делюсь информацией. Может кто захочет поддержать деятельность c-smile своим трудовым рублем.

суббота, 26 сентября 2020 г.

[prog.thoughts.c++] Очередная рефлексия о том, куда движется C++ и по пути ли мне с ним...

Так уж получается, что в последний месяц работать получается немного, зато много думается о разном и разнообразом. В том числе о том, остается ли для C++ место под Солнцем в современном мире. И, если остается, то какое и где (гусарам молчать!).

Данный пост появился под влиянием нескольких факторов.

суббота, 19 сентября 2020 г.

[life] Мои краткие впечатления об интервью Юрия Дудя авторов канала NEXTA

Посмотрел сие творение. Просто чтобы не случилось "Пастернака не читал, но осуждаю".

Общее впечатление: один "малолетний дебил" (с) берет интервью у пары других "малолетних дебилов". При этом с дебильностью Дудя посоперничать может разве что упоротость Степана Путило.

На моменте, когда Дудь говорит "Выяснилось, что люди, судя по всему, антисемиты... Я чего-то не ожидал, что я могу такое в центре Европы услышать. Тем более в П-О-О-О-Л-Ь-Ш-Е!!!" пришлось даже сделать паузу. Антисемитизм у поляков? Как такое может быть вообще? Ведь никогда такого не было, а вот опять... ДБ (лавров.jpg).

ИМХО, лучшей реакцией властей РБ на этот фильм был бы его показ без купюр по белорусскому ТВ. В прайм-тайм. С утренним повтором на следующий день.

пятница, 18 сентября 2020 г.

[life] Месяц вне радаров и это явно не последний месяц

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

Сейчас я еще более уверен в том, что события развивались бы по известному уже сценарию даже если бы Лукашенко на выборах набрал бы всего лишь 51% голосов. Цифры не важны, важен сам факт того, что победу одержал АГЛ. Просто официально зафиксированные 80% сделали задачу протестных кукловодов немного проще.

Сейчас я еще более уверен в том, что происходящие события -- это прямая аналогия не с украинским майданом 2014-го, а с позднеперестроечным СССР и раздербаниванием СССР посредством удачного использования сложившихся тогда условий. При этом неполживые dev.by/onliner.by/tut.by выглядят прямо как "Огонёк" Коротича в 1980-х.

Целью же всей движухи является установление такой власти, при которой нужные люди смогут отнять и переделить имеющиеся в РБ ресурсы.

Это и является основной причиной происходящего. Плюс сюда же и геополитические интересы отдельных игроков, включая желание поднасрать на границах РФ.

А результаты выборов -- это лишь повод. Тщательно подготовленный надо сказать. Но лишь грамотно использованный повод.

Общество, действительно, расколото. Самым ярким признаком служит активное использование БЧБ-флагов протестующими.

Столь активное использование БЧБ-символики я лично рационально объяснить не могу.

Один из худших вариантов, почему такое происходит, -- это смена поколений. Т.е. постепенно те, кто вырос на советской историографии уходят, на смену приходит поколение, для которого БНР -- это, оказывается, полноценное государство; Польша -- лепши сябр, который всячески заботился о белорусском и украинском населении своих всходних кресов, отрывая последнее у поляков и отдавая белоруссам/украинцам; коллаборация с фашистами в ВОВ -- борьба на независимость; деятельность Рады БНР в изгнании значит больше, чем все развитие ССБР/БССР в рамках Советского Союза; принятие БЧБ-символики Верховным советом БССР перед распадом СССР -- более демократичное действо, чем возврат к красно-зеленому флагу посредством всенародного референдума.

Ну что ж, если это так, то значит историческая реальность становится вот такой.

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

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

Но даже если все будет проходить по мирному сценарию и активные протесты таки стихнут спустя 2-3 месяца, сформировавшийся раскол никуда не денется. Люди перестанут шляться по городам с БЧБ-флагами, но настроения останутся на десятилетия и будут проявляться в разговорах на кухнях, как это было во времена СССР. Только сейчас к этому добавятся и соцсети с мессенджерами. Так что питательный протестный бульон никуда не денется, только бурлить он будет уже на медленном огне. До следующей точки бифуркации.

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

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

Ну пока на этом все. Пожалуйста, сохраняйте благоразумие и берегите себя.

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

четверг, 17 сентября 2020 г.

[prog.c++] Эволюция развития новой фичи в json_dto: от простого к сложному, а затем к менее сложному

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

Пару слов о json_dto для тех, кто не в курсе что это

Библиотека json_dto была создана нами года 4.5 назад для упрощения работы с JSON посредством RapidJSON. Если делать (де)сериализацию собственных структур с использованием API RapidJSON, то получаются большие портянки кода. Что не есть хорошо: требует много времени и отнимает много сил и внимания. Мы же взяли за основу идею из Boost.Serialization и сделали небольшую обертку над RapidJSON, которая позволяет описывать (де)сериализацию практически в декларативном виде. Например:

вторник, 8 сентября 2020 г.

[software.lavrov.jpg] Что я имею сказать по поводу призывов использовать Boost Software License

Данный пост навеян вот этим обсуждением на Reddit-е: "Why You Should Use the Boost Software License", которое сосредоточено вокруг вокруг одноименного поста в блоге Peter Dimov. Суть в том, что BSL не требует перечислять использованную библиотеку под лицензией BSL при распространении конечного продукта, сделанного на базе этой библиотеки.

Т.е. если есть продукт P, в котором используются библиотека X под лицензией MIT и библиотека Y под лицензией BSL, то про библиотеку X где-то в продукте P упоминать нужно обязательно, тогда как про Y можно и не упоминать.

Поэтому Peter Dimov (и не только он, но и скажем, Vinnie Falco, автор Boost.Beast-а) призывают разработчиков использовать для своих открытых проектов именно BSL.

На эту тему имею сказать две вещи.

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

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


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

PS. Все вышесказанное является мнением человека, который угрохал туеву хучу собственного времени и собственных средств на разработку и продвижение OpenSource библиотек.

воскресенье, 30 августа 2020 г.

[life.photo] Вероятно, это будет мое лучшее фото в 2020-ом году

20200829-IMG_20200829_175546_2

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

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

[work.management] Интересное видео про менеджмент и организацию эффективного производства (и не только производства)

Давно не постил в блог видео, но вот это заслуживает того, чтобы попасть в склерозник.

Как говорится, "эх, если бы я об этом знал раньше..." Теперь-то знаю. Но ошибки прошлого не исправить :(

А тем, кто еще не знает, но что-то начинает подозревать, имеет смысл посмотреть.

PS. Особенно меня порадовали моменты про мотивацию (денежная мотивация работает, но недолго) и KPI (тут же вспомнилось, что о подобном и сам писал когда-то).

четверг, 20 августа 2020 г.

[prog.c++] Незапланированный, но показательный релиз RESTinio

Сегодня была зафиксирована очередная версия RESTinio: 0.6.10. В ней только одно нововведение, но зато оно показательно.

Пару дней назад пользователь открыл issue на GitHub, в котором попросил возможность сделать так, чтобы экземпляр asio::ssl::context можно было разделять между RESTinio-сервером и другими частями приложения. Что изначально в RESTinio предусмотренно не было.

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

Мораль сей басни: если вы что-то хотите видеть в RESTinio, то дайте нам об этом знать. Попробуем решить вопрос.

Да, и это касается не только RESTinio ;)

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

[life] В связи с кризисом в нашей стране исчезну с радаров

Думаю, что многие знают, что в Беларуси сейчас очень серьезный кризис, результатом которого вполне может стать смена власти. Ситуация весьма сложная и неоднозначная. Если кто-то вне РБ составляет впечатление о происходящем у нас по информации из прозападных СМИ или постам в соцсетях, где можно увидеть многотысячные митинги/шествия людей под бчб-флагами, то могу заверить, что на самом деле здесь все не так однозначно. И даже если эти митинги одномоментно собирают пусть миллион человек по всей стране, то это безусловно много. Но не нужно забывать, что вне транслируемых митингов остается еще более восьми миллионов человек, у которых есть собственное мнение. И это мнение может быть прямо противоположным раскручиваемому в информационном мейнстриме.

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

Попробую пояснить почему так думаю.

четверг, 13 августа 2020 г.

[prog.c++] My view of the near (and not so) future of the RESTinio project

Now, after the official release of RESTinio-0.6.9, it's a good time to share some thoughts about the near (and not only near) future of the RESTinio project.

It is worth noting that the text below is only my point of view. This point of view can change over time.

This text is split into two parts. The first part tells about rather practical things that I want to see in the upcoming releases of RESTinio. The second part is more philosophical and intended for the discussion about the role of RESTinio in the modern C++ landscape.

Part One. What I want to have in RESTinio 0.6 and what could be seen in 0.7?

суббота, 1 августа 2020 г.

[prog.thoughts] Какой способ информирования об ошибках мне бы хотелось иметь для написания надежного кода?

Много лет занимаюсь разработкой софта, который должен работать в режиме 24/7 и, зачастую, под приличной нагрузкой. Это не mission-critical софт, скорее business-critical. Т.е. если будет глючить и падать, то никто не умрет. Так что писать "пуленепробиваемый" и "не убиваемый" кода пока не приходилось. Тем не менее, нестабильная работа написанного нами софта -- это авралы, стрессы, неприятности с клиентами. Понятное дело, что никому такое не нужно.

В связи с этим при написании кода меня регулярно терзает мысль "а насколько он надежен?" Мысль понятная и вопрос вполне себе по теме. Но вот ответ на этот вопрос далеко не всегда очевиден.

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

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

пятница, 31 июля 2020 г.

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

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

Фильмы

Офицер и шпион (J'accuse, 2019). Мне понравилось, посмотрел с удовольствием.

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

Форпост (The Outpost, 2020). На мой взгляд весьма достойный военный фильм.

Гори, гори ясно (Brightburn, 2019). В принципе, идея мне понравилась. Вот что было бы, если бы Супермен оказался бы плохишом. Но подвело то, что в фильме всего одна звездная актриса, Элизабет Бэнкс, однако, главным-то героем должна была бы быть не она. Так что оттягивание внимания от пацана с суперспособностями на единственную звезду сделало фильм менее интересным, чем он мог бы быть.

Темное наследие (Inheritance, 2020). Ну так себе. По ходу просмотра очень быстро начинают возникать вопросы "А почему так-то?", а затем и желание воскликнуть "Не верю". Еще больше этих вопросов и реплик "Не верю", остается после просмотра. Так что по итогу впечатление остается "ну так себе".

Всегда верен (Semper Fi, 2019). Купился на хороший трейлер и ожидал напряженный и динамичный фильм про побег из тюрьмы. Но оказалось, что того самого побега в фильме всего 1/5 часть времени. В лучшем случае. Все остальное что-то вроде мелодрамы. В общем, вполне можно и не смотреть.

Призраки войны (Ghosts of War, 2020). Начинался как заштатный фильм ужасов на тему призраков в антураже Второй Мировой. Ближе к финалу авторы замутили твист. Который, как мне показалось, на пользу совсем не пошел. И уж лучше бы фильм оставался заштатным фильмом ужасов на тему призраков в антураже Второй Мировой.

Мой создатель (Archive, 2020). Ну очень нудное кино. Ну очень нудное. Ну очень. Насколько нудное и усыпляющее, что даже финальный твист вызывает скорее раздражение, нежели удивление.

Бессмертная гвардия (The Old Guard, 2020). Редкая бредятина по отдаленным мотивам "Горца". С кучей соплей и чрезмерной толерастией, из-за чего сопли временами оказываются даже не розовыми, а голубыми.

Сериалы

Пацаны (The Boys, 2019), первый сезон. Мне хорошо зашло. Не смотря на то, что фильм типа про супергероев. Немного огорчило то, что это не попытка рассказать завершенную историю в минисериале, а явно всего лишь первый сезон, за которым обязательно пойдут продолжения с теми же персонажами. Поэтому последняя серия оставила впечатление "вот вам вот какая промежуточная развязка, а все самое интересное вас еще ждет впереди".

Голова (The Head), первый сезон. Посмотреть можно. Но развязка оказалась несколько предсказуемой.

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

суббота, 25 июля 2020 г.

[prog.c++] Пример использования шаблонов для создания C-шных коллбэков из методов C++-ных классов

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

Итак, есть известная чисто-С-шная библиотека http_parser, которую много кто использует (в том числе и мы в RESTinio). Для работы с ней нужно создать у себя в программе экземпляр типа http_parser и экземпляр типа http_parser_settings. Где http_parser_settings должен содержать набор указателей на С-шные коллбэки, которые будут вызываться во время парсинга HTTP-сообщений.

Возникла задача сделать так, чтобы коллбэками для http_parser выступали нестатические методы C++ ного класса.

Решалась эта задача в два этапа.

воскресенье, 19 июля 2020 г.

[prog.c++] Продолжение истории про parent/child и удаление child-а из метода самого child-а

Около месяца назад в блоге была заметка, в которой показывалась схема с классами parent и child. Класс parent владел экземпляром child, а child в своем методе мог вызвать у parent-а метод replace_child, во время которого текущий child уничтожался. Т.е. получалось, что объект, метод которого сейчас работает, уничтожается прямо внутри этого работающего сейчас метода.

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

Все-таки вот такое:

void child::some_method()
{
   ... // Some actions.

   delete this// The last action of the method.
}

можно контролировать лишь в самых тривиальных случаях. А по мере того, как some_method усложняется и/или погружается куда-то ниже в стек вызовов, вероятность возникновения use after free стремительно приближается к единице. И можно быть уверенным, что в один прекрасный момент use after free таки произойдет.

Под катом небольшой рассказ о схеме, которая была применена для того, чтобы сохранить режим взаимодействия parent и child, но при этом защититься от use after free.

среда, 1 июля 2020 г.

[prog.flame] Может уже и пришло время закапывать C++, но пока он позволяет в коде выписывать ABNF грамматики...

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

Иногда складывается впечатление, что эти стенания повсюду. Особенно на профильных ресурсах, типа Reddit, LOR, RSDN (может и на Хабре, но до Хабра сейчас просто уже руки не доходят).

Финальным гвоздем стали очередные вбросы в Telegram канале C++ Russia от известного своим праздным звездежом хаскелиста Александра Гранина, у которого, походу, второй натурой стал троллинг C++а и C++ников. С традиционным уже участием на C++ Russia с докладом про функциональщину.

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

В тоже самое время этот самый современный C++, в который, как искренне верят неасиляторы, напихали всякой ненужной чуйни, лично мне позволяет в декларативном виде записывать в коде ABNF грамматики из RFC по HTTP/1.1.

Причем это даже не самый еще современный C++, а всего лишь C++14.

И что-то мне подсказывает, что сделать подобное на каких-то "типа альтернативах" C++ будет не так уж и просто. Особенно с учетом накладных расходов в run-time. Если вообще возможно.

Ну а вот и сам упомянутый фрагмент. Который отвечает за парсинг содержимого HTTP-заголовка Transfer-Encoding согласно спецификации.

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

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

Фильмы

В погоне за ветром (Ride Like a Girl, 2019). Отлично снятый байопик. Добрый, жизнеутверждающий. Мне понравился.

Идеальный дворец Фердинанда Шеваля (L'incroyable histoire du facteur Cheval, 2018). Странный фильм про странного человека. Снят хорошо. Но смотреть тяжело. История рассказана трогательная, хотя и очень печальная.

Афера в Майами (Wasp Network, 2019). Просто удивительно, как из такой интересной и многослойной истории получилось такое унылое и затянутое непонятно что. Хорошо хоть, что снято красиво.

Отверженные (Les misérables, 2019). У фильма высокие оценки, но мне было смотреть не интересно. Ни сюжет не зацепил, ни актеры. А операторская работа так вообще раздражала. Сложилось ощущение, что фильм ценен разве что за остросоциальную тему, но вовсе не как художественное произведение.

Сериалы

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

Обвиняемый (Presunto culpable, 2018). Начал смотреть из-за исключительно красивого видеоряда в трейлере. Ну и досматривал тоже исключительно из-за работы оператора. Сам по себе сериал туфта, все события из 13 серий можно было бы запросто уместить в 3-4 и получилось бы динамичнее и напряженнее. Но вот работа оператора -- это что-то. В некоторых местах картинку хотелось останавливать и печатать, чтобы на стену повесить. Компоновка кадров, работа со светом и даже разумное использование светосильной оптики вызывает мое почтение.

Ночной администратор (The Night Manager, 2015). Актеры хорошие, на них приятно смотреть. А вот сам фильм не зацепил.

среда, 24 июня 2020 г.

[prog.c++] Максимальное значение времени, которое можно передать в std::condition_variable::wait_for

Метод std::condition_variable::wait_for в качестве одного из параметров получает время ожидания срабатывания condition_variable. На cppreference.com этот параметр называется rel_time. И про его значение сказано следующее:

an object of type std::chrono::duration representing the maximum time to spend waiting. Note that rel_time must be small enough not to overflow when added to std::chrono::steady_clock::now().

Ok. Значит значение rel_time не должно быть таким, чтобы вызвать переполнение, когда его суммируют с std::chrono::steady_clock::now(). Но каким же оно тогда может быть?

В принципе, можно предположить, что максимально допустимое значение для rel_time может быть получено таким нехитрым способом:

std::chrono::steady_clock::time_point::max() - std::chrono::steady_clock::now()

Т.е. оно не должно быть больше разницы между самой большой меткой времени, которую можно выразить в std::chrono::steady_clock, и текущей меткой времени.

Вроде бы так. Но не все так просто, ведь мы же в мире C++.

Вот программка, которую я написал для того, чтобы проверить, какое значение rel_time можно подсунуть в wait_for и получить при этом ожидаемое поведение wait_for. Ее суть в том, что она пытается брать сперва большое значение rel_time, а затем постепенно уменьшает это значение. Если же значение rel_time слишком большое, то wait_for может завершать свою работу сразу же, вообще без ожидания.

Так вот под Windows и VC++19 (и под FreeBSD и clang) получается вполне себе ожидаемый результат:

wait_time: 9222236437359ms, days: 1
wait for: 1001ms

А вот под Linux-ом и GCC/clang меня ждет неожиданное открытие:

wait_time: 9223171751593ms, days: 1
wait for: 0ms
wait_time: 9136771751593ms, days: 1001
wait for: 0ms
wait_time: 9050371751593ms, days: 2001
wait for: 0ms
wait_time: 8963971751593ms, days: 3001
wait for: 0ms
wait_time: 8877571751593ms, days: 4001
wait for: 0ms
wait_time: 8791171751593ms, days: 5001
wait for: 0ms
... skipped
wait_time: 7840771751592ms, days: 16001
wait for: 0ms
wait_time: 7754371751592ms, days: 17001
wait for: 0ms
wait_time: 7667971751592ms, days: 18001
wait for: 0ms
wait_time: 7581571751592ms, days: 19001
wait for: 1000ms

Т.е. мало того, что нельзя просто взять разность между (time_point::max() - time_point::now()) и для безопасности отнять оттуда какую-то разумную дельту (вроде 24 часов). Эту самую дельту нужно сделать весьма большой.

Почему так -- я хз. Вероятно какие-то фокусы трансформации вызова condition_variable::wait_for в POSIX-овый вызов. Но вот на практике довелось в это стукнуться.

PS. Зачем может потребоваться задавать большие значения для rel_time? Бывают случаи, когда либо пользователь задает время ожидания какого-то события, либо же нужно ждать "когда рак на горе свиснет". И если мы хотим время ожидания представить в программе всего одним значением std::chrono::duration, которое можно будет просто без дополнительных проверок отдать в condition_variable::wait_for (или не делать отдельно вызовы condition_variable::wait и condition_variable::wait_for), то нужно понимать, какая именно величина будет означать "когда рак на горе свиснет".

понедельник, 22 июня 2020 г.

[prog.c++] Релиз SObjectizer-5.7.1 и so5extra-1.4.1

Нашлось время и ресурсы запилить новые версии SObjectizer и so5extra.

В SObjectizer-5.7.1 реализовано несколько полезных нововведений и исправлено несколько косяков, которые пока еще не проявлялись.

Одно из самых важных изменений в SObjectizer-5.7.1 -- это возможность назначать лимиты для сообщений по умолчанию:

class demo final : public so_5::agent_t
{
public:
   demo(context_t ctx)
      : so_5::agent_t{ctx
         + limit_then_drop<msg_A>(100u)
         + limit_then_abort<msg_B>(10u)
         // That limit will be used for all other messages.
         + limit_then_drop<any_unspecified_message>(50u)
         }
   {}

   void so_define_agent() override
   {
      // Explicitly defined limit will be used.
      so_subscribe_self().event([](mhood_t<msg_A> cmd) {...});

      // A new limit object will be created for msg_C here.
      so_subscribe_self().event([](mhood_t<msg_C> cmd) {...});
   }
};

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

Второе полезное нововведение в SO-5.7.1 -- это шаблонная функция make_agent_ref, которая позволяет гарантировать нужное время жизни указателя на агента, если этот указатель приходится отдавать в какой-нибудь коллбэк:

class io_performer final : public so_5::agent_t
{
   asio::io::tcp::socket connection_;
   std::array<std::byte, 4096> input_buffer_;

   void handle_incoming_data(std::size_t bytes_transferred) {...}

   void on_some_event(mhood_t<some_msg> cmd)
   {
      // It's time to read some data.
      connection_.async_read_some(asio::buffer(input_buffer_),
         [self=so_5::make_agent_ref(this)]
         (const asio::error_code & ec, std::size_t bytes_transferred)
         {
            if(!ec)
               self->handle_incoming_data(bytes_transferred);
         });
   }
   ...
};

Полный перечень нововведений и изменений в SO-5.7.1 можно найти здесь.

В so5extra-1.4.1 был добавлен новый тип диспетчера: asio_one_thread.

Этот диспетчер использует отдельную рабочую нить, на которой запускается io_context::run и на которой обслуживаются как I/O-операции, так и события привязанных к этому диспетчеру агентов.

По своей логике работы asio_one_thread очень похож на asio_thread_pool диспетчер, но имеет более простую реализацию. И он более удобен в использовании, когда все I/O-операции нужно "прибить" к одному контексту.

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


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