понедельник, 1 марта 2021 г.

[work] У stiffstream есть пара свободных рук. Моих свободных рук

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

В последние 7 лет занимался развитием таких открытых проектов, как SObjectizer/so5extra, RESTinio, json_dto. Что включало в себя выбор функциональности для нового релиза, проектирование, реализация, тестирование, документирование, реагирование на issues и какой-никакой PR (более 50 статей на Хабре с 2016-го года + выступления на конференциях CoreHard C++ и C++ Russia).

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

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

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

В последние годы специализировался на велосипедостроении. Уровень мастерства в этом занятии можно оценить по easy_parser и easy_parser_router из RESTinio (на то, как это воплощено в коде, посмотреть можно здесь и здесь).

Составить впечатление о качестве моего кода можно здесь (timertt), здесь (so5extra) или здесь (atrataga). Именно эти разработки были сделаны практически в одиночку.

Могу сопровождать код документацией (см. Wiki для SObjectizer и so5extra, статьи на Хабре). Предполагаю, что умею связно излагать мысли в письменном виде, но это не точно.

Если кому-то интересно посмотреть на мое более развернутое резюме, то проще всего заглянуть в мой профиль на LinkedIn.

Чем я могу быть полезен вашему проекту и/или вашей компании:

  • в качестве консультанта по C++ или "играющего тренера" для вашей C++ной команды, если в ней мало опытных C++ников: проведение code review, объяснение почему тот или иной код опасен, прививание команде навыков написания более-менее идеоматического C++ кода (в том числе с учетом возможностей modern C++);
  • в качестве самостоятельного и автономного субконтрактора, который может создать для вас прототип нового решения и/или привести в нормальное состояние кусок старой кодовой базы;
  • в качестве члена проектной команды, работающего удаленно.

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

Рейт от 20 до 35 USD в час в зависимости от проекта. Чем ответственнее проект, чем более требовательны вы к гарантийным обязательствам, чем короче сроки, тем дороже.

Заранее предупрежу о своих недостатках чтобы не отнимать друг у друга время:

  • английский язык на уровне "читаю и перевожу со словарем" (как-то так). Вот уж чего не дадено, того не дадено;
  • не отношусь к числу тех, кто умеет все и берется за все. Если я чего-то не знаю или в чем-то не разбираюсь, то сразу говорю об этом. Вам решать готовы ли вы оплачивать мое погружение в нужную вам тему;
  • к работе подхожу вдумчиво и основательно. Из-за этого вы можете столкнуться с большим потоком уточняющих вопросов с моей стороны, а прогнозы по срокам работ могут иметь весьма широкий диапазон;
  • предпочитаю находить компромиссы и могу продолжать конструктивное общение даже в ситуациях, когда на исполнителя на повышенных тонах в нецензурной форме пытаются повесить всех собак, но политкорректностью не отличаюсь и рублю правду матку не взирая на лица и звания;
  • если вам нужен кто-то энергичный и способный резво махать шашкой в экстремальных условиях, то я вам точно не подойду. Когда случается пожар, все носятся с горящей жопой и никто не знает куда бежать, за что хвататься, то на вопрос "Ты ж программист, так какого хрена, а?" вы услышите от меня разве что "Дайте мне спокойно подумать";
  • обладаю специфическим чувством юмора, чрезмерной самоиронией и несерьезным отношением к самому себе;
  • врожденный NIH-синдром.

Если описанное выше вас устраивает, то связаться со мной можно через Telegram/WhatsUp/Viber по номеру +375-29-536-32-25 или по почте eao197 на stiffstream тчк com (более оперативно я доступен по eao197 на gmail).

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

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

Фильмы

Дьявол в деталях (The Little Things, 2021). Если бы не очень уже специфическая (я бы даже сказал укуренная) манера повествования, то мне бы даже могло очень понравится. А так просто неплохой фильм получился, можно посмотреть.

Охотник на монстров (Monster hunter, 2020). Да, тупо. Да, фэнтези. Но бодренько и красочно. На фоне выходящего в последнее время шлака даже ничего себе так. Хотя, конечно, далеко не первая "Обитель Зла".

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

Зависнуть в Палм-Спрингс (Palm Springs, 2020). Еще одна итерация вокруг темы "Дня сурка". Вполне можно посмотреть.

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

Остров фантазий (Fantasy Island, 2020). Средней паршивости. Есть ощущение, что не хватило бюджета для создания нормальной картинки в нужных местах.

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

Афера Оливера Твиста (Twist, 2021). Низкобюджетный и низкопробный английский телефильм, после просмотра которого возникает один вопрос: как туда удалось затащить Майкла Кейна?

Огонь (2020). Редкая по накалу идиотии очередная попытка снять "наш ответ Голливуду". Местами вроде как и нормально, но местами такая муть (вроде родов в автобусе на горящем мосту), что можно убить себя фейспалмами. Ну и картинка пожаров такая, что у авторов фильма невольно хочется спросить: "А вы когда-нибудь хотя бы у костра среднего размера пробовали постоять?"

Сериал

Фортитьюд (Fortitude, первый сезон). Первые 2/3 смотреть было интересно. Но финал первого сезона как-то совсем уж уныло и бездарно слили. Поэтому желания смотреть последующие сезоны не возникло.

четверг, 25 февраля 2021 г.

[prog.flame] Тесты как показатель качества?

Сегодня хочется поговорить об одном найденом на просторах Twitter-а высказывании:

В FB уже немного обстебал это изречение. Но тема поднята такая, которую можно обсудить и вполне себе серьезно.

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

Итак:

Качество -- это оценка ценности некоторого изделия.

Тест -- это оценка пригодности некоторого изделия к выполнению своей основной функции (одной из функций).

Соответственно, качество и тесты -- это про разное.

А теперь позвольте растечься мыслею по древу...

среда, 10 февраля 2021 г.

[prog.c++] Куда не заглянешь, везде чего-нить да унюхаешь...

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

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

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

Приведу пару свежих примеров.

понедельник, 8 февраля 2021 г.

[soft.process] Погружение в Agile: так есть ли в этом всем смысл?

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

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

Итак, Agile есть и он работает. Действительно.

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

вторник, 2 февраля 2021 г.

[soft.business] Послесловие к неудачной попытке найти внешнее финансирование для RESTinio/SObjectizer/so5extra

На данный момент история с поиском финансирования закончилась ничем. Развитие наших OpenSource-проектов приостановлено. Попробуем поднакопить средства на заказной разработке/консультациях, чтобы затем вернуться к работам над RESTinio/SObjectizer/so5extra.

А в этом послесловии просто расскажу на что был расчет когда писался пост о поиске внешнего финансирования, может кому-то пригодится наш опыт.

Суть в том, что у SObjectizer-а и у RESTinio совершенно разные ситуации.

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

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

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

Добавим сюда еще и то, что для успешной конкуренции с аналогичными проектами RESTinio очень желательно было бы иметь поддержку не только http/1.1, но и хотя бы http/2.

И если уж менять http-parser на что-то другое, то можно было бы под этим соусом добавить в RESTinio и http/2. А если получится, то и заложить возможность последующего добавления http/3.

Сложно сказать, во что бы это все вылилось по трудозатратам. Но по первым впечатлениям, от 3 до 5 месяцев это могло бы занять. Тут нужно учитывать, что мы стараемся тщательно тестировать RESTinio, писать примеры и расширять документацию. Это такая работа, которая может быть не видна, но которая должна быть выполнена, и которая занимает изрядное время. Поэтому если кому-то кажется, что 3-5 месяца для написания собственной поддержки http/1.1 и http/2 -- это слишком много, то мне лишь остается позавидовать вашей производительности и трудолюбию.

Итого, если начать работы над RESTinio-0.7 сейчас и вести их не отрываясь ни на что другое, то выкатить новую версию получится лишь где-то к лету 2021-го.

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

Мы встали перед выбором: либо заняться заказной разработкой и остановить развитие RESTinio на какое-то время, либо же поискать внешние вложения.

Остановка развития RESTinio выглядела слишком рискованно. Сперва RESTinio будет заморожен на 5-6 месяцев, затем в течении еще 3-5 месяцев будет вестись разработка новой версии с релизом RESTinio-0.7 где-то через год... Отличная перспектива чтобы закопать проект.

Поэтому мы решились на поиск внешнего финансирования.

Фактически, мы пошли с протянутой рукой. Мол, сами мы не местные, помогите кто чем может.

Варианты с платной техподдержкой и "рекламными услугами" были выбраны по следующим причинам:

1. В РБ (да и в РФ) нельзя просто так взять и внести деньги на счет коммерческой структуры. Поступление денег должно быть оформлено договором. Лучше всего, если это договор на оказание каких-то услуг или на выполнение каких-то работ. Техподдержка и "рекламные услуги" как раз и являются теми формами договорных отношений, которые позволяют нам получать деньги ровно за то, что мы и делаем. И не требуют от нас ничего больше, за исключением оформления некоторого количества дополнительных бумажек раз в квартал (в виде актов по выполненным работам).

2. Суммы мы выбрали такие, которые крупные (и даже не очень крупные) компании могут выложить не задумываясь. Грубо говоря, в компании с несколькими тысячами сотрудников 150USD в квартал отдел маркетинга может запросто потратить просто "на скрепки". Мы надеялись, что сумма в 600USD в год для крупного производителя софта будет достаточно мизерной для того, чтобы ответственные люди могли дать добро на помощь нашим открытым проектам не заморачиваясь на то, что мы можем дать взамен.

Если же называть вещи своими именами, то мы рассчитывали на благотворительность.

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

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

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

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

PS. Если какая-то компания хочет вложиться в разработку RESTinio/SObjectizer/so5extra (например, хочет поиметь какую-то специфическую функциональность), то давайте пообщаемся на eao197 на gmail тчк com. Можно обсуждать различные варианты сотрудничества.

воскресенье, 31 января 2021 г.

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

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

Охота на Санту (Fatman, 2020). Мне лично зашел ну очень хорошо. Показалось, что это очень тонкий стеб на сугубо американские темы. Но некоторые из них оказались понятны даже мне (например, поручение сборки панелей для нового самолета эльфам).

Неадекватные люди 2 (2020). По сравнению с другим современным российским кино так прямо отличный фильм. Но к первой части имеет косвенное отношение.

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

Не входи (The Owners, 2020). При хорошей идее и даже старательных попытках ее воплощения авторы явно недокрутили. Так что нормально не вышло. Мне показалось, что слишком уж много странных и нелогично ведущих себя персонажей, плюс некоторые линию сюжета толком не были объяснены. Если уж совсем нечего смотреть, то можно глянуть, но ждать многого не следует.

Чудо-женщина: 1984 (Wonder Woman 1984, 2020). До просмотра ожидал две вещи: что на Галь Гадот в бронелифчике будет приятно смотреть и что от сюжета не следует чего-либо ждать. Не обманулся. Но к этому совершенно неожиданно добавился совершенно дешманский уровень спецэффектов. Что превратило кино в откровенный отстой. И даже красота Галь Гадот ничего не смогла с этим поделать.

Монстры, созданные человеком (Monsters of Man, 2020). Затянутый и откровенно дешевый. Но, как это не странно, производит более хорошее впечатление, чем гораздо более дорогой фильм "Смертельная зона" от Netflix (см.ниже).

Плохие парни навсегда (Bad Boys for Life, 2020). Начало было довольно пристойным и даже вселяло надежду на нормальное кино, но вторая половина фильма скатилось в такое редкостное говно, по сравнению с которым даже болливудские боевики смотрятся почти как документальные.

Смертельная зона (Outside the Wire, 2021). Редкостная дрянь. А деньги на визуальные эффекты, такое ощущение, тупо распилили.

понедельник, 25 января 2021 г.

[soft.business] Ищу финансирование для развития RESTinio/SObjectizer/so5extra

Наша совсем маленькая компания stiffstream на протяжении нескольких лет делает такие OpenSource инструменты для С++ как:

  • RESTinio: встраиваемый HTTP/WebSocket сервер, ориентированный на эффективную асинхронную обработку входящих HTTP-запросов;
  • SObjectizer/so5extra: реализация Actor Model, Publish-Subscribe и Communicating Sequential Processes, существенно упрощающая разработку сложных многопоточных приложений.

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

К сожалению, кризис 2020-го ударил и по нам. Наши собственные финансовые ресурсы для развития RESTinio и SObjectizer/so5extra практически исчерпаны.

Поэтому мы приостанавливаем работы над этими проектами на неопределенный срок.

UPD. На данный момент история с поиском финансирования закончилась ничем. Развитие наших OpenSource-проектов пока приостановлено. Мы попробуем поднакопить средства на заказной разработке/консультациях, чтобы затем вернуться к работам над RESTinio/SObjectizer/so5extra. Кому интересно, вот послесловие к этой затее.

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

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

[prog.c++] Текущие хотелки по SObjectizer/so5extra

Две недели назад был пост о том, что хотелось бы поиметь в RESTinio. Попытаюсь сформулировать что-то подобное и в отношении SObjectizer+so5extra.

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

На данный момент я вижу два направления, в рамках которых можно произвести НИОКР и, если в сухом остатке получится приемлемый результат, перенести результаты исследований в SObjectizer.


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

Суть в том, что сейчас агенты в SObjectizer-е работают в соответствии с push-моделью.

Это значит, что когда вы отсылаете сообщение в mbox, то обычный mbox запихивает заявку на обработку сообщения в очередь событий агента. Рано или поздно дело доходит до обработки этой заявки: диспетчер владеет очередью событий и именно диспетчер извлекает очередную заявку из этой очереди. При этом mbox, который сформировал заявку, не знает когда именно это произойдет.

Push-модель проста, понятна, эффективна и подходит для огромного количества случаев.

Однако бывают моменты, когда агенту выгоднее использовать pull-модель.

Первый сценарий, который можно закрыть посредством pull-модели -- это поддержка приоритетов для заявок (см. недавнюю статью на Habr-е на эту тему). Причем такая поддержка, которая бы позволила использовать приоритеты заявок совместно с базовыми штатными диспетчерами SObjectizer-а, которые изначально для этого вообще не предназначались (например, one_thread, active_obj, active_group, thread_pool, а также asio_thread_pool и asio_one_thread из so5extra).

Второй сценарий -- это еще одно возможное решение проблемы producer-consumer, которое давеча обсуждалось в issue на GitHub-е. Идея в том, что специализированный mbox собирает отосланные в него сообщения, но не сразу отсылает сообщения в очереди событий агентов, а хранит у себя до тех пор, пока какой-то из consumer-ов не освободится и не обратиться за следующим сообщением. В этом случае pull-модель выглядит предпочтительнее push-модели.

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

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

Четвертый сценарий -- это возможность сделать поддержку чего-то вроде selective receive (например, по аналогии с механизмом Stash из Akka). Правда, я не уверен, что это действительно реализуемо. Но, думается, что pull-модель предоставляет здесь несколько больше шансов на успех, нежели push-модель.

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


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

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

Временами это не есть хорошо. Например, если пользователь хочет создать 100500 агентов, привязанных к active_obj-диспетчеру (т.е. работающих на собственных рабочих нитях), но при этом желает ограничить размер стека для каждой из рабочих нитей всего 32KiB. Работай пользователь напрямую с POSIX threads у него была бы такая возможность. А вот штатные диспетчеры не позволяют это сделать.

Другой сценарий: пользователь хочет поиграться с приоритетами рабочих нитей. Например, создать one_thread-диспетчер с высоким приоритетом рабочей нити. И thread_pool-диспетчер с низкоприоритетными рабочими нитями. Опять же, на чистом POSIX threads API это можно было бы сделать. А через штатные диспетчеры SO-5 -- нет.

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

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

Нужно сказать, что диспетчеры asio_one_thread и asio_thread_pool из so5extra позволяют в свойствах диспетчера задать тип для рабочей нити. Так что эти два диспетчера позволяют пользователю реализовывать рабочие нити вручную со всеми нужными свойствами, тогда как основная внутренняя логика работы диспетчера остается на нашей (т.е. мейнтенеров SO-5) совести.

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


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

Так что если вы хотели бы видеть что-то в SObjectizer-е, что могло бы облегчить вам вашу работу, то скажите об этом нам. Например, через issues или discussions на GitHub-е.

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


Наверное, немного странно записывать хотелки когда вопрос о финансировании работ для наших OpenSource проектов еще не решен. И непонятно когда мы сможем вернуться к работе над RESTinio/SObjectizer.

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

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

[work.opensource.c++] arataga: что это вообще и зачем мы публикуем это в OpenSource?

arataga -- это работающий прототип socks5+http/1.1 прокси сервера, который мы в прошлом году разрабатывали для одного из наших клиентов. К сожалению, этот прототип остался невостребованным. Ну а чтобы не пропадать добру и самопиара ради, мы решили открыть его исходники.

Как все развивалось

Дело было так: с 2019-го года мы работали с заказчиком, который эксплуатировал у себя некий старый прокси-сервер. Весьма старый, написанный с применением модели thread-per-connection, да еще и оставшийся без сопровождения. Собственно, мы как раз и занимались его доработкой под нужды заказчика.

Где-то к концу весны 2020-го стало понятно, что больше ничего хорошего из этого прокси-сервера не выжать. Что нужно его заменять на что-то новое, написанное с нуля или же переделанное готовое (типа nginx или envoy после обработки напильником).

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

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

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

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

Зачем нужно было делать arataga?

У заказчика были следующие и, как мне представляется, местами весьма специфические условия:

четверг, 21 января 2021 г.

[life] Никто не знал, а я тормоз :)

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

Суть в том, что я с детства считал себя человеком, который думает быстро. Не знаю, с чем это связано. Может быть с тем, что сложные предметы в школе давались легко. Может быть потому, что если начинал заниматься чем-то, что мне нравилось, то быстро прогрессировал. Может быть на меня сильное впечатление произвела фраза Юлия Цезаря "Veni, vidi, vici". Вот не знаю.

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

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

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

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

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

Внезапно (c), да.

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

Самое трудное при таком подходе -- это как-то прервать процесс размышления на волнующую тему. Особенно когда какая-то внезапная мысль приходит посреди ночи. Готовых и 100% работающих рецептов пока нет. Были бы, поделился бы.

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

Какой вывод из всего сказанного?

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

суббота, 9 января 2021 г.

[prog.c++] Пару слов про позиционирование RESTinio и основные хотелки для RESTinio на 2021-й

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

ИМХО, уже пришла пора более точно определиться с позиционированием RESTinio в экосистеме C++. Это раньше RESTinio был молодой и мало кому известной разработкой. Сейчас же ситуация меняется, мы уже не молоды ;)

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

Мне представляется, что RESTinio уникален тем, что под одной крышей здесь собрано:

  • простота использования RESTinio для каких-то очевидных и понятных действий. Так, чтобы получить запрос и пройтись по списку HTTP-полей, не нужно выписывать вручную процедуры чтения данных из сокета;
  • гибкая настройка RESTinio под условия пользователя. Захотел пользователь применять Boost.Log для логирования? Нет проблем, RESTinio позволяет написать адаптер и RESTinio будет логировать свои действия с помощью этого адаптера. Или, например, захотел пользователь запускать вместе с RESTinio на io_context еще и какие-то свои сетевые операции... Опять же, нет проблем;
  • набор инструментов, которые позволяют применять RESTinio для каких-то нетривиальных сценариев. Например, средства работы с HTTP-заголовками используются в arataga даже для исходящих HTTP-запросов.

Что делает RESTinio хорошим выбором для ситуаций, когда разработчику нужно что-то сильно повыше уровнем, чем Boost.Beast, но при этом хочется иметь гораздо больший контроль за происходящим, чем в oat++ или cpp-httplib.

Отличный пример такой задачи, на мой взгляд, -- это прокси-сервер типа arataga. На Boost.Beast его делать будет слишком хлопотно. А oat++/cpp-httplib вряд ли дадут доступ к своим потрохам.

Именно в этом направлении, думаю, и стоит развивать RESTinio дальше.

Т.е., RESTinio должен быть выше уровнем, чем Boost.Beast, но ниже, чем oat++ и cpp-httplib. Но при этом средствами RESTinio продвинутый разработчик с небольшими усилиями должен уметь создать для себя что-то похожее на oat++/cpp-httplib, но заточенное под специфические требования конкретной прикладной задачи.

Или же, в более лаконичной форме:

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

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


Теперь попробую обозначить несколько приоритетов в предполагаемом развитии RESTinio в 2021-ом году.

Во-первых, это замена http_parser на что-то другое. Конечно же, хочется иметь собственную реализацию, которая бы a) сделала RESTinio полностью header-only библиотекой, и b) поддерживала бы различные тонкие моменты в HTTP-протоколе (вроде chunk extensions). Если это не получится, то рассмотреть и внедрить какую-то готовую альтернативную реализацию (llhttp, picohttpparser, что-то еще).

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

В-третьих, добавление поддержки http/2. Пока RESTinio жестко завязана на работу со всего лишь один протокол. От этого нужно уходить, т.к. рано или поздно, http/2 и http/3 вытеснят http/1.1. И если в 2021-ом получится изменить RESTinio так, чтобы в нем поддерживалось сразу два протокола, то это откроет отличную возможность добавить со временем еще и http/3, а может и еще что-нибудь.

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

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


Если кого-то интересует перечень встраиваемых HTTP-серверов для C++, то выглядит он приблизительно так (перечисление в случайном порядке): RESTinio, Boost.Beast, cpp-httplib, http_backend, Pistache, RestBed, served, C++ REST SDK, proxygen, Simple-Web-Server, drogon, oat++

суббота, 2 января 2021 г.

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

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

Фильмы

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

Отряд Фокстрот (Foxtrot Six, 2019). Неожиданно бодренький, хотя и дешевый, околофантастический боевик из Индонезии. До "Рейда", конечно же, не дотягивает, но если хочется отключить мозги и посмотреть бескомпромиссное и динамичное рубилово-мочилово, то достойный вариант на нынешнем безрыбье.

Честный вор (Honest Thief, 2020). Все средненько и предсказуемо. Вполне можно и посмотреть, когда ничего лучше нет. Жалко только, что местами спецэффекты были сделаны совсем уж убого и дешево.

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

Новые мутанты (The New Mutants, 2020). Любители серии про "Людей Икс" могут глянуть, конечно. Но лучше не стоит, ничего хорошего в фильме нет, как по мне. А уж зачем туда притянули лесбийские отношения...

Ритм-секция (The Rhythm Section, 2020). Редкая дрянь несмотря на неплохих актеров в главной роли и, местами, отличную работу оператора. Смело можно не смотреть.

Гренландия (Greenland, 2020). Муть полная. Да и на удивление убогие и дешманские спецэффекты для фильма-катастрофы такого масштаба.

Сериалы

Смог полностью отсмотреть два сериала:

Мандалорец (второй сезон). Достойное продолжение первого сезона. По декорациям в некоторых сериях казалось, что даже гораздо круче первого сезона. Тут явно тот случай, когда сериалом по мотивам "Звездных войн" занялись люди, искренне любящие "Звездные войны". Так что настоящим продолжением оригинальной трилогии, определенно, является этот сериал, а не три полнометражных говноаттракциона с Дэйзи Ридли в главной роли. Ну и плюс "Изгой один". Соответственно, любителям первых трех фильмов можно смело рекомендовать к просмотру.

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

И еще два досмотреть не смог, осилив по 3-4 первые серии:

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

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


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


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

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

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