[work] Небольшое подведение итогов 2018-го

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

Выпущен ряд версий библиотеки RESTinio: 0.4.1, 0.4.3, 0.4.4, 0.4.5.1, 0.4.7 и 0.4.8. К сожалению, осенью работы над RESTinio пришлось заморозить из-за ограниченности наших ресурсов. В 2019-ом развитие RESTinio собираемся продолжить.

На базе RESTinio мы сделали две небольшие демонстрашки. Первая -- это shrimp-demo, маленький игрушечный сервис для раздачи отмасштабированых картинок (на русском языке эта разработка описывалась в серии статей на Хабре: №1, №2, №3).

Вторая -- это реализация примера из доклада Винни Фалько (автор Boost.Beast) на CppCon-2018, но средствами RESTinio: Beast-vs-RESTinio. Если кто-то всерьез считает, что Boost.Beast -- это удобный инструмент для прикладной разработки, то найдите время, сходите о ссылке и посмотрите своими глазами. Очень надеюсь, что ваше мнение поменяется (ну или хотя бы ваша уверенность несколько пошатнется).

Потихонечку начинает ощущаться, что наша работа над RESTinio дает свои плоды. В частности, RESTinio привели в пример в MS-овском блоге на msdn.microsoft.com.

---

В этом году получилось сделать всего больших релиза SObjectizer-а и so_5_extra: SObjectizer 5.5.21 and so_5_extra 1.0.4, SObjectizer 5.5.22 and so_5_extra 1.1.0, SObjectizer 5.5.23 and so_5_extra 1.2.0. Версию 5.5.24 в 2018 опубликовать не успели, работа по документированию заняла гораздо больше времени, чем ожидалось (и еще не закончена, к сожалению).

Не смотря на то, что релизов SObjectizer-а было немного, радует то, что в 2018-ом году в SObjectizer добавлялись только те фичи, которые сформировались на основании опыта использования SObjectizer-а в разработке софта, на базе потребностей разработчиков. Так что в этом году в SO-5 мы добавляли не свои собственные хотелки или фичи, нужные для маркетинговых сравнений с другими аналогичными продуктами. А только то, что нужно было на практике.

Касательно практической применимости RESTinio и SObjectizer-а по итогам 2018-го года можно сказать разве что следующее: оба эти продукта применяются, применяются даже шире, чем нам об этом известно. Но о том, что нам известно, мы не можем рассказывать. Так что публично доступных success stories в 2018-ом не прибавилось. Надеюсь, в 2019-ом ситуация поменяется.

---

Было сделано три доклада на C++ных конференциях: C++ CoreHard Spring 2018, C++Russia 2018, C++ CoreHard Autumn 2018. Мне сложно судить, но, кажется, все три зашли достаточно хорошо.

Так же, благодаря Анастасии Казаковой из JetBrians, был сделан большой доклад на митапе в Питере.

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

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

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

• небольшая серия статей о том, как подружить асинхронную работу RESTinio и асинхронную работу libcurl: №1, №2, №3. Даже если вам не нужен RESTinio, в этих статьях показана асинхронная работа с libcurl, а этой информации в нормальном объеме и вменяемом виде, как оказалось, в Интернетах не так много;
• "Давайте заглянем SObjectizer-у под капот". Пусть не самое детальное, но все-таки описание того, из чего состоит SObjectizer и как он работает;
• статья с рассказом об иерархических конечных автоматах вообще и о том, что и как из возможностей ИКА можно использовать в SObjectizer-е.

Серию статей про shrimp-demo уже упоминал, еще можно дать ссылку на текстовую версию доклада с C++ CoreHard Autumn 2018 про акторов, CSP и task-based подходы.

---

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

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

[prog.flame] Эх, если бы с многопоточностью все было так просто...

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

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

[prog.humour] Открыл статью о Rust, увидел пример кода, закрыл статью о Rust-е ;)

Иногда мне кажется, что у наиболее активных растоманов какой-то стокгольмский синдром в терминальной стадии :) Вот, например, свежая статья о Rust-а на Хабре: "Так ли страшен Rust, как его малюют", автор которой, будучи C#-разработчиком, активно защищает Rust в различных хабрасрачах.

Так вот, автор сперва приводит пример кода на Rust-е:

let mut guess = String::new(); io::stdin().read_line(&mut guess)     .expect("Failed to read line"); let guess: u32 = guess.trim().parse()     .expect("Please type a number!"); println!("You guessed: {}", guess);

А потом говорит, что можно сделать существенно проще и приводит вот такой аналог:

let mut guess = String::new(); io::stdin().read_line(&mut guess)?; let guess: u32 = guess.trim().parse()?; println!("You guessed: {}", guess);

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

При том, что оба примера -- это попытка записать вот такой двустрочник на C#:

var number = int.Parse(Console.ReadLine()); Console.WriteLine($"You guessed: {number}");

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

---

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

[blog] Happy Birthday My Blog - 10!

Вот так, тихо и незаметно, подкрался десятилетний юбилей моего маленького блога. Десять лет назад здесь появилась сразу пара первых заметок (#1, #2).

[management.flame] "Ад своими руками" или "не читайте до обеда советских газет"

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

Но давеча был опубликована очередная статья этого автора под названием "Ад своими руками". Статья уже набрала почти 60K просмотров и 130 комментариев и, полагаю, это еще не предел.

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

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

Вот так же и автор вышеупомянутой статьи. Сперва он внятно и толково описывает то, что было сделано, к каким последствиям это привело, как с этим пытались бороться. Читаешь и понимаешь, что умный человек пишет. А потом следует вывод, от которого просто выпадаешь в осадок:

Когда руководителя начинают слушать, то оказывается, что ему нечего сказать.

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

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

Это невозможно комментировать. Умными и опытными людьми на тему управления организациями написаны серьезные и толстенные толмуды. Кому интересно, почитайте книги Генри Минцберга на тему менеджмента.

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

• руководителям приходится принимать решения в условиях гораздо большей неопределенности, чем обычные сотрудники могут себе представить;
• внимание руководителя постоянно разрывается между стратегическими (долгосрочными) и тактическими (краткосрочными) задачами. Плюс есть огромное количество других как производственных, так и непроизводственных проблем, которые так же отвлекают внимание на себя;
• решения приходится принимать в постоянно меняющихся условиях. То, что вчера было объективно актуально и что следовало делать, сегодня может оказаться уже никому не нужно (смена обстоятельств, появление новых продуктов/игроков на рынке, потеря клиентов, форс-мажоры и пр.);
• на принятие решений могут оказывать воздействия шкурные и сиюминутные интересы. Как собственные интересы руководителя, так и интересы групп влияния, в орбиту которых попадает руководитель;
• на принятие решений могут оказывать влияние заблуждения или недостаточные знания как самого руководителя, так и людей, на мнения/рекомендации которых руководитель полагается. Например, модно сейчас применять Agile или Stack ranking -- значит нужно попробовать применить;
• людям свойственно ошибаться. В том числе и руководителям.

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

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

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

Печально то, что в результате тех 60K просмотров статьи "Ад своими руками" наверняка найдется некоторое количество читателей, которые воспримут вывод автора всерьез и не подвергнут этот вывод критическому осмыслению.

[prog.c++] Поддержка unit-тестирования для агентов в SObjectizer-е начинает дышать!

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

Важная штука: средства для тестирования агентов будут входить прямо в состав SObjectizer-5.5. Это значит, что в их реализации нам придется ориентироваться на какое-то подмножество C++11, что нас не радует. Но, думаю, возможность писать тестовые сценарии для агентов без необходимости ставить себе какой-нибудь so_5_extra, сделает SObjectizer привлекательнее для тех, кто еще кипятит не решился сделать выбор в пользу SObjectizer-а (и кого, может быть, смущает двойное лицензирование so_5_extra).

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

Тем не менее, отрадно.

[work.thoughts] Мимоходом про высшее профильное образование для программистов

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

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

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

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

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

Так вот о роли высшего образования вообще и профильного высшего образования в частности.

С точки зрения работодателя наличие высшего образования у соискателя означает то, что соискатель a) способен вписаться в рамки достаточно жесткой системы и b) способен обучаться в рамках этой самой системы. Т.е., говоря совсем просто: если у человека хватило мозгов закончить технический ВУЗ, то высоки шансы, что у него хватит мозгов для нормальной работе на производстве.

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

Но вот если говорить о полезности именно профильного высшего образования для программистов, то я могу сказать за себя: почему лично я рад тому, что мне повезло в свое время получить именно профильное образование (а у меня была специальность 22.04 "Программное обеспечение ВТ и АС", в дипломе значится профессия "инженер-программист").

Рад я тому, что во время учебы в ВУЗе у нас была уникальная конкурентно-дружеская атмосфера. Особенно на первых курсах универа.

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

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

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

[life.memories] К 25-летию DOOM-а

Говорят, что давеча стукнуло 25 лет знаменитому DOOM-у: Reflections on DOOM's Development. Ну а раз так, то невозможно не вспомнить это знаковое явление давно минувшего прошлого.

Сам я с DOOM-ом познакомился или в конце 1994-го или уже в 1995-ом. Причем, как мне помнится, сперва я прошел DOOM2. А затем уже, из спортивного интереса, и первый DOOM. А потом и все add-on-ы к ним, которые попадали мне в руки. До рисования собственных уровней дело не дошло, хотя какой-то редактор уровней мы раздобыли.

В соревнованиях по DOOM-у я не участвовал. Да и их в нашей местности в 1995-96, наверное, и не было еще. Потом про соревнования слышал и кто-то из моих коллег по аспирантуре даже пытался в них участвовать, но мне это уже было не интересно. Так что на каком уровне я сам играл не могу сказать. Но когда несколько раз прошел DOOM-у, то развлекался следующим образом: запускал DOOM, затем с помощью чит-кодов переходил на нужный мне уровень и начинал проходить его начиная с одним пистолетом, поднимая остальное оружие уже на самом уровне. Первый DOOM я так прошел полностью. Во втором DOOM-е добрался до 17-го, что ли уровня, и все. Там уже с одним пистолетом против толпы монстров не попрешь.

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

Играл на уровне сложности ultra-violence, без чит-кодов.

Вообще, в то время я был большим фанатом стрелялок от первого лица. Но вот другие игры на движке DOOM-а, вроде Hexen или Heretic, мне не зашли.

Зато потом появился Duke Nukem. А еще чуть позже сделанный на его движке Redneck Rampage. Правда, Duke Nukem был не первой стрелялкой, в которой можно было поднимать ствол вверх или опускать вниз. Первой такой стрелялкой был Jedi Knight по мотивам вселенной Звездных Войн. Вроде как Jedi Knight прошел совсем незаметно на фоне DOOM-ов и Duke Nukem, но это была очень хорошо сделанная игра, атмосферная, в которой даже световым мечом можно было противников рубать (и не только рубать, но и отражать выстрелы врагов).

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

А жирную точку в увлечениях шутерами поставила такая малоизвестная стрелялка, как NAM. Написана она была на движке Duke Nukem-а и в конце 1990-х это выглядело уже архаично, конечно же. Но атмосфера, которая возникала в игре была просто какой-то невероятной. Такого я больше нигде не видел. Какой-то уровень начинался вообще с того, что открывалась дверь приземлившегося на опушке джунглей вертолета и по тебе начинали палить со всех сторон. Не успеваешь моргнуть глазом, как ты уже труп. Нужно было сходу брать ноги в руки и бежать со всех сил, да еще по ковбойски стреляя в возникающих то тут, то там врагов. Ну а хождение по ночным джунглям -- это вообще отдельная история. Только вот пройти полностью NAM не удалось. Застрял на каком-то уровне и все. Несколько дней тыкался, тыкался. А потом раз, и отвернуло от шутеров. Навсегда :)

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

[prog.c++] Fast formatted input в C++: есть ли и нужен ли кому-нибудь?

Внезапная, что называется, тема. В обсуждении нового стандарта Фортрана на LOR-е всплыло такое интересное достоинство языка Фортран, как высокая скорость его стандартного форматированного ввода/вывода (из-за адекватности некоторых персонажей хоть сколько-нибудь конкретные цифры удалось получить только на шестой странице обсуждения).

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

int x, y;
char comma;
std::cin >> x >> comma >> y;

а, например, вот так:

fastinput::read(std::cin, "{},{}", x, y);

Или, если нужно прочитать значения в шестнадцатиричном формате:

fastinput::read(std::cin, "{:x},{:x}", x, y);

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

Причем акцент здесь на том, чтобы быстро разбирать большие объемы информации в текстовом виде, без учета локалей и пр., включая, возможно и UTF-8.

Или в мире C++ с такими задачами мало кто сталкивается? А когда сталкиваются, то просто делают свои велосипеды, которые на публике никогда не показываются?

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

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

Мотылек (Papillon, 2017). Не ожидал. Начал просмотр со скепсисом, но был очень сильно и приятно удивлен. И история хорошая, и рассказана мастерски, и никаких перегибов в розовые сопли или чернушный жесткач не было. Определенно лучший из просмотренных за месяц.

Король вне закона (Outlaw King, 2018). Уж не знаю, как там с историзмом обстоит, но мне понравилось. А качественно сделанные батальные сцены по нынешним временам так вообще приятно удивили.

Фантастические твари: Преступления Грин-де-Вальда (Fantastic Beasts: The Crimes of Grindelwald, 2018). В принципе, очень достойное продолжение и первых "Фантастических тварей", и всей киновселенной Гарри Поттера в целом. Визуальная составляющая выше всяких похвал. Но, как мне показалось, немного скучновато и нудновато, первые "Фантастические твари" были динамичнее.

Поиск (Searching, 2018). Очень даже неплохо. Нужно только набраться терпения пока последняя треть фильма не начнется.

Багровая мята (Peppermint, 2018). Двойственные ощущения. С одной стороны, вроде бы и экшен есть. Но, с другой стороны, этого экшена не так много, как хотелось бы. Да и хрупкая женщина в роли супер-пупер ниндзя -- это так себе идея.

Веном (Venom, 2018). Отличная картинка и, местами, динамичный экшен. Но мозги при просмотре включать категорически не рекомендуется. Смотреть можно разве что ради видеоряда.

Кин (Kin, 2018). Не понятно, что это было. Для детского кино слишком взрослый. Для взрослого -- слишком детский. Местами вполне себе ничего, местами занудно и не интересно. Ни то, ни се.

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

Придержи тьму (Hold the Dark, 2018). Снято, конечно, классно. Но ведь ни черта не понятно!

[prog.c++] Unit-тестирование агентов в SObjectizer: вторая итерация

Продолжение темы, начатой здесь. Кому не интересно, можно смело не читать.

[prog.c++] Первый набросок инструментов unit-тестирования агентов в SObjectizer

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

Кому интересно посмотреть и пообсуждать -- милости прошу под кат.

[prog.c++] Работа над средствами тестирования агентов в SObjectizer начинается

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

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

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

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

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

Но если кто-то сможет поделится примерами своих агентов и мыслями о том, как вам было бы удобно ваши агенты тестировать, то это будет очень большим подспорьем в работе. Можно и не публично, а в приватной переписке (eao197 на stiffstream тчк com или eao197 на gmail тчк com).

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

[life] Пара моментов, которые обращают на себя внимание в общественном транспорте в последние год-полтора

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

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

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

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

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

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

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

Вот этот момент с пробитыми талонами -- он очень показателен для иллюстрации экономической ситуации в стране.

[work;life] Наглядная демонстрация того, "почему нельзя изнасиловать женщину в толпе?"

Если кто-то не знает этого бородатого анекдота, то ответ на вопрос "Почему нельзя изнасиловать женщину в толпе?" очень прост: "Потому, что толпа замучает советами". Наглядное подтверждение этому можно увидеть в недавней теме на LOR-е: "как вырасти из junior".

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

Кстати говоря, это же отличная демонстрация еще двух вещей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ conan create . demo/testing

This is equivalent to:

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

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

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

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

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

---

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

A Brief Introduction Into Finite State Machines

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

Advanced Finite State Machines And Their Features

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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