[prog.thoughts] Пара докладов про управление зависимостями в C++ и небольшое послесловие к ним

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

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

Мне же, однако, подходы на базе централизованых хранилищ пакетов, будь то conan.io (в ближайшем будущем conan-central), hunter или cppan.org не очень нравятся. Точнее говоря, я не верю, что это окажется достаточно жизнеспособным из-за разных причин. Во-первых, в C++ все очень разобщено, поэтому слабо верится в то, что народ массово начнет концентироваться вокруг какого-то одного центрального репозитория C++ных проектов. Во-вторых, кто и с какой радости должен будет оплачивать сей банкет? Хостинг 100500 непонятных проектов и кучи версий для них -- это накладные расходы, которые кто-то должен оплачивать. Что-то в мире C++ мне не видится организации, которая взяла бы на себя бремя этих накладных расходов. Тем более, что почти что все уже живет на ресурсах типа GitHub, BitBucket или SourceForge.

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

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

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

В этих случаях, как мне кажется, плохо работают обе составляющие централизованного подхода (положенного в основу canon/hunter/cppan):

1. Центральное хранилище опубликованных пакетов. Поскольку для работы с X@R1 кто-то должен быть создать соответствующий пакет и опубликовать его в этом хранилище. Потом это же нужно будет проделать с X@R2 и т.д. При том, что вряд ли хорошо засирать центральное хранилище промежуточными пакетами. Как и делать собственное зекало этого центрального хранилища для того, чтобы засирать его локально.
2. Централизованное хранилище загруженных на локальную машину пакетов. Поскольку если X@R1 и X@R2 мне нужны только для проекта Y, да и то в какой-то временной ветке Y, то не есть хорошо сохранять X@R1 и X@R2 там же, где хранятся нормальные стабильные версии чего-то вроде Boost-а или ICU.

Имхо, для таких случаев хорошо работает подход, который мы используем в своем MxxRu::externals:

• во-первых, MxxRu::externals сам забирает исходники стороннего компонента оттуда, где эти исходники лежат. Например, лежит Boost в tar.bz2 на SourceForge -- оттуда его и заберем. А исходники spdlog от конкретного коммита есть в git-е на GitHub-е -- ну значит вытянем их через git с GitHub-а. Таким образом для того, чтобы сделать свой пакет доступным для пользователей, не нужно предпринимать каких-то серьезных усилий. Можно даже свой тарбол не делать, если кроме GitHub-а ни на что мозгов не хватает, то достаточно просто теги в своем репозитории создавать, GitHub сам для них тарбол доступным для загрузки сделает. Ну а если нужно забирать какие-то промежуточные версии собственных компонентов из закрытых репозиториев внутри своей организации, то тут вообще никаких проблем нет, ничего дополнительно поднимать не нужно (речь про локальный инстанс того же Conan-а);
• во-вторых, загруженные зависимости кладутся только в локальный рабочий каталог. Поэтому, если моему проекту Y потребовался сперва X@R1, а затем X@R2, то исходники X@R1 и X@R2 никуда за пределы рабочего каталога Y не уйдут. И, соответственно, когда я удалю этот рабочий каталог, то автоматически исчезнет и весь "мусор" , который был с этим связан.

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

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

[prog] Очередная статья про SObjectizer для Хабра: будет ли интересен разбор примера machine_control?

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

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

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

В общем, если кому-то интересна такая статья, то дайте об этом знать: либо в комментариях, либо через +1 в G+, либо через лайки в FB и LinkedIn (где я размещу ссылки на этот пост).

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

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

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

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

Пираты Карибского моря: Мертвецы не рассказывают сказки (Pirates of the Caribbean: Dead Men Tell No Tales, 2017). Прекрасный образец того, как нужно делать развлекательный киноаттракцион: выключаешь мозги, откидываешься в кресле и понеслась! Ну и да, все деньги на экране, и это видно.

Перестрелка (Free Fire, 2016). Фильм специфический, наверняка понравится не всем. Но я получил большое удовольствие от просмотра.

Берлинский синдром (Berlin Syndrome, 2017). Ну очень неторопливо. Иногда хочется включить его на 1.25 или 1.5 скорости. Однако, именно неторопливость помноженная на предельную обыденность и составляет в итоге уникальную, тягостную, но сильную атмосферу этой картины.

Три для до весны (2017). Понравилось, как снято. Для российского кинематографа более чем достойно. Хотя в сюжетной линии с главным злодеем НКВД-шником авторы перестарались.

Без тормозов (À fond, 2016). Незамысловато, местами туповато, но смешно и весело.

Столик №19 (Table 19, 2017). Хорошая смесь специфического юмора, из-за которого нужно внимательно ловить каждую реплику, и сентиментальной драмы. Сдобренной отличной актерской игрой и работой оператора.

Похищение (Kidnap, 2017). Добротно. Хороший напряженный триллер.

Ирис (Iris, 2016). В целом неплохо. Но правда не понял, за счет чего: сюжета или присутствия красивой актрисы в главной роли ;)

Семейное ограбление (Mes trésors, 2017). Нормальная французская комедия. Не шедевр, но и потраченного времени не жалко.

Комик (The Comedian, 2016). Фильм можно смотреть, если нет неприятия стендапа вообще и жесткого пошлого юмора в частности.

Время псов (The Hunter's Prayer, 2017). Странная картина. Вроде бы актеров подобрали. Вроде как динамику создали. Вроде как и постреляли вдоволь. А вот не торкает особо.

Мелкие преступления (Small Crimes, 2017). Ждал большего. Фильм оставил впечатление какого-то сумбура, в котором события активно переплетаются, но непонятно почему и из-за чего. Хотя нужно начислить дополнительные очки за отсутствие хэппи-энда.

Пробуждение Зодиака (Awakening the Zodiac, 2017). Довольно посредственно. Хотя посмотреть можно, только не нужно ждать ничего, хотя бы отдаленно напоминающего замечательный "Зодиак" Дэвида Финчера от 2007-го года.

Лжец, Великий и Ужасный (The Wizard of Lies, 2017). Пример того, как авторы взяли потенциально очень крутую тему, но не смогли донести до зрителя ощущение того, что главный герой фильма повинен в создании самой большой финансовой пирамиде в истории.

Кухня. Последняя битва (2017). Средней руки российская комедия. Местами смешная. С отличной картинкой. Белорусской аудитории отдельно сильно понравится маленький проезд по "Коленьке".

---

Ну а эти две картины находятся просто вне всякой критики, т.к. днище было пробито с огромной силой и на невероятную глубину.

Чужой: Завет (Alien: Covenant, 2017). Это так плохо и маразматично, что я даже не могу увязать этот фильм с первыми тремя "Чужими". Ну вот есть уникальная вселенная "Чужих", показанная в первых трех фильмах. Ее даже не смогли испортить странной четвертой частью. А "Прометей" и "Чужой: Завет", особенно "Чужой: Завет", ну никак у меня не увязываются со знаменитой серией. Это какое-то совсем другое кино, совсем про других монстров и совсем про других людей. Можно было бы о "Чужом: Завет" порассуждать именно как о совершенно другой истории. Но происходящее на экране настолько тупо и неинтересно, что нет смысла это делать.

Форсаж 8 (The Fate of the Furious, 2017). Это какой-то красочный киноаттракцион, но непонятно для какой аудитории. Может быть для 10-летних детей. Как это можно всерьез смотреть взрослым людям просто не представляю.

[flame] Образ современного ИТ-шника в РБ: "это молодой человек, владеющий иностранным языком, ..."

Цитата из официоза про встречу руководства моей альма-матер с представителями ИТ-шных компаний города:

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

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

Пожалуй, это все, что нужно знать про развитие ИТ в РБ.

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

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

Итого, как мне видится дальнейшее развитие истории:

• хорошо, если государство будет заинтересовано в экспорте жопочасов местных ИТ-шников. Ну, такая же статья экспорта, как и калийные удобрения. Только ресурсы здесь остаются и, благодаря своим деньгам, хоть как-то оживляют внутренний рынок товаров и услуг. Как-то страшно думать, во что это все превратится, если государство таки решит зарезать курочку, ибо кушать ну очень хочется, а ее и так слишком долго жалели;
• поскольку основной вид деятельности в местном ИТ -- это аутсорс, то желающим "войти-в-Ойти" и чувствовать себя там нормально, прежде всего нужно делать упор на изучение иностранных языков (лучше нескольких). А так же на развитие soft skills и грамотной продажи самого себя. Умение программировать из года в год будет становиться все менее и менее важным профилирующим навыком. В том числе и потому, что само массовое программирование все больше и больше требует умения быстро склеить что-то из уже готовых компонентов, нежели знаний и способностей создать что-то новое и нетривиальное. Кроме того, в аутсорс же отдается не только программирование, но и куча сопутствующих активностей: бизнес-аналитика, тестирование, управление проектами, техническая документация, как минимум. Тут умение программировать вообще не обязательно;
• уровень привлекательности ИТ-отрасти в плане доходов будет определяться коньюктурой мирового рынка. Не хочу сказать, что ЗП в отрасли упадут вот прямо завтра или послезавтра. Но то, что когда-нибудь это произойдет, поскольку ту же самую работу вполне себе хорошо будут делать юноши и девушки из Вьетнама или Венесуэлы, но стоить это будет в 10 раз дешевле, и тогда никакие способности, установившиеся связи и имеющийся опыт не сделают белорусских ИТ-шников настолько ценными, чтобы платить нам в 10 раз больше. На глобальном-то рынке. Так что современным молодым людям, владеющим иностранными языками, и зарабатывающим по паре-тройки тысяч долларов в месяц, полезно помнить, что этот уровень зарплат обеспечивается не какими-то их уникальными особенностями. А вот такой нынешней ситуацией на рынке.

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

[flame] Егор Бугаенко в DevZen подкасте (послешоу)

Дослушал таки послешоу подкаста DevZen, в котором участвовал Егор Бугаенко. Впечатления сильно двойственные.

Первые минут 40-50 тов.Бугаенко говорил весьма толково. Если убрать излишнюю категоричность и метафоричность, то получается вменяемый рассказ от вменяемого человека о том, в каких условиях ему приходится работать и как он с этим справляется.

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

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

---

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

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

• "Не будут нанимать фрилансера с соседней улицы". Речь шла о том, что ситуация меняется и наступает время, когда нанимать будут не по знакомству или по соседству, а исходя из рыночных реалий. Мол, если такой же спец есть в Китае за меньшие деньги, то брать соседа в Сан-Франциско не будут. Отчасти это так, но все не так просто. Даже не будем рассматривать основную причину, т.е. неравенство доходов в разных концах мира. Ситуация станет сильно другой, когда за одну и ту же работу в США и в Малайзии начнут платить сравнимые деньги. Но есть еще такая вещь, как репутация. Нанять фрилансера в Интернете вовсе не значит гарантировать себе результат. По факту может быть такое, что дешевле было бы нанять соседа задорого, но быть уверенным в том, что работа будет сделано качественно и в срок. В принципе, за примерами далеко не нужно ходить. На рынке стоматологических услуг уже не первый десяток лет услуги предлагают и одиночки, и мелкие кабинеты, и небольшие поликлиники и большие клиники. Только вот мы же не бежим к самому дешевому врачу. Или, скажем, если вам приходилось сталкиваться с ремонтом и вы хотели найти хорошего плиточника, вы же не выбирали самое дешевое предложение в газете частных объявлений. Да и сам Бугаенко признался, что клиенты к нему приходят из-за его репутации, хотя услуги его компании, по его же словам, обходятся недешево. Так что этот тезис ну очень спорен. Хотя с тем, что рынок становится глобальным, и что конкурировать нужно будет с поставщиками таких же услуг из разных концов света, спорить не приходится, это уже свершившийся факт;
• "Над ними стоит менеджмент, который ничего не делает". Речь про то, что работу работают узкие специалисты (вроде программистов или продавцов), а менеджмент просто паразитирует на их работе. Ну тут можно только посочувствовать человеку, который сталкивался только с таким менеджментом. Дебилы, лентяи, карьеристы и просто случайные люди встречаются везде. И среди программистов, и среди менеджеров. Конечно, когда менеджером становиться дебил-карьерист, то последствия могут быть тяжелыми. Но, тем не менее, ни один сложный и большой проект не способен завершиться успешно без менеджмента. Как бы вы лично к менеджменту не относились, это так. Ну и когда вы сами станете менеджерами и начнете нести ответственность за результат, тогда лучше поймете, делает ли менеджер что-нибудь или нет;
• "Любой менеджмент должен быть заменен тулзами". Речь про то, что различного рода программы и программые системы, завязанные на правильные методологии, способны устранить промежуточное звено в виде менеджмента. Что не так. Если отбросить категорию "менеджеров", которые занимаются только расстановкой точек в MS Project-е и сбором отчетов о ежедневной загруженности, или же являются всего лишь точкой коммуникаций между руководством и исполнителями, то менеджмент -- он же про работу с людьми. Создание условий для людей, учет их мнений и пожеланий, обучение, решение их проблем, предотвращение конфликтов, устранение последствий конфликтов и т.д. Кто-то всерьез хочет переложить работу с людьми на автоматические тулзы? Ну вперед, чё :)

А вообще, есть замечательная книга Игоря Ашманова "Жизнь внутри пузыря". Там есть целая глава про магов. Так вот, когда я слушаю рассказы Бугаенко про ООП или про то, куда должна двигаться методология разработки программных проектов, я вспоминаю этих самых магов из книжки Ашманова. Чего и вам желаю ;)

[prog] Интересный момент при проектировании round-robin mbox-а.

Работаю над такой штукой для SObjectizer-а как round-robin mbox. Т.е. почтовый ящик, на который могут подписаться N агентов, но доставка сообщений к ним будет осуществляться по очереди, т.е. сперва первому агенту, затем второму, затем третьему и т.д. Эта штука должна быть удобной, например, при реализации балансировки нагрузки, когда требующие обработки сообщения отсылаются в один и тот же mbox, а распределяться они будут при этом на N агентов-воркеров, прозрачным для отправителя образом.

Подобные вещи и раньше можно было делать, но вручную. А теперь есть возможность предоставить round-robin mbox прямо "из коробки".

Однако, в процессе продумывания реализации round-robin mbox-а обнаружилась неожиданная засада. Дело в том, что в mbox-ах есть такая штука, как delivery filters, т.е. фильтры, которые определяют, имеет ли смысл доставлять конкретное сообщение до конкретного получателя.

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

Чем же мешают фильтры доставки в round-robin mbox-е?

Как в принципе должен работать round-robin mbox? У него должен быть список подписчиков на каждый тип сообщения. В этом списке должен быть явно отмечен текущий элемент -- тот подписчик, которому должно быть доставлено следующее сообщение. Когда сообщение приходит, оно отсылается этому подписчику, после чего текущим элементом становится следующий подписчик (ну или первый, если мы дошли до конца). Все просто.

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

Вырисовываются следующие варианты:

1. Просто выбросить этот экземпляр сообщения. Т.е. текущему агенту в списке сообщение не доставляется (что естественно, т.к. фильтр запрещает доставку) и не делается попытка доставить сообщение следующему агенту в списке. Текущим становится следующий агент в списке (или первый, если достигли конца списка).
2. Попытаться выбрать другого получателя. Т.е. сразу перейти к следующему агенту и спросить его фильтр доставки. Потом к следующему и т.д. до тех пор, пока получатель не будет найден. Может быть вообще ничего не найдем, но тогда данный экземпляр сообщения просто выбрасывается.
3. Тупой запрет на использование фильтров доставки в случае round-robin mbox-а. Тогда проблемы нет в принципе.
4. Update. Объединить все фильтры доставки в один комбо-фильтр. Когда появляется сообщение, оно сперва пропускается через этот комбо-фильтр (т.е. через все фильтры). И только если комбо-фильтр пропускает сообщение, только тогда оно доставляется текущему получателю.

Лично я пока склоняюсь к первому варианту. Логика такая: round-robin предполагает, что пытаемся доставлять по очереди. Сейчас очередь у агента X. Если X отказывается принимать сообщение, то он все равно свою очередь использовал и для следующего сообщения очередь перейдет к другому получателю.

Вот только не уверен, что это не будет сбивать пользователей с толку. Кто что думает?

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

Кстати, попутно еще один вопрос: а кроме round-robin еще какие-нибудь политики доставки для N агентов кому-нибудь нужны/интересны?

[prog.flame] Егор Бугаенко в DevZen подкасте

Есть в Рунете такой подкаст: DevZen. Я его практически никогда не слушаю. За исключением некоторых отдельных случаев: один раз там обсуждали именно что мой пост в моем блоге, один раз там говорили про модный и молодежный взгляд на ООП вообще и ООП в C++ в частности, один раз обсуждали акторов в C++, один раз послушал фрагмент DevZen с участием Григория Демченко и пара выпусков про Лондон и стартапы. Хотя ссылки, которые там накидывают в комментариях стараюсь просматривать, бо временами встречается интересное.

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

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