О блоге

Более двадцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

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

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

Вы художник? Бармен или музыкант? Или, может быть, коллекционер? Плотник или столяр? Кузнец или слесарь? Владеете маленьким магазинчиком или управляете большим производством? Реставрируете старинные часы или просто починяете примус? Всю жизнь занимаетесь своим любимым делом и хотели бы иметь фото на память?

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

[prog.flame] И еще раз про Rust. Как я к Rust-у отношусь на самом деле

Судя по статистике посещений, недавние посты про Rust (№1, №2 и №3) продолжают привлекать к себе внимание. И, к сожалению, у некоторых альтернативно одаренных личностей складывается впечатление, что я пытаюсь гнобить Rust. Поэтому нужно расставить все точки над ё.

[prog.c++] Вторая статья про демо-проект Shrimp

Мы подготовили и опубликовали вторую статью про свой демо-проект Shrimp, наглядно показывающий, как может выглядеть более-менее реальное приложение на RESTinio и SObjectizer (ну и на C++17): "Развиваем Shrimp: контролируем параллельные запросы, логируем через spdlog и еще…".

Вторая статья описывает результат следующей итерации вокруг Shrimp-а. Мы кое-что доработали напильником и устранили шероховатости, которые были в самой первой версии Shrimp-а. Интересно было добавлять команду на принудительный сброс содержимого кэша в Shrimp-е. За счет удобного механизма роутинга запросов в RESTinio добавить обработку еще одного URL в HTTP-сервере -- это буквально дело нескольких минут. Правда, реализация реакции на эту команду в агенте transform_manager заняла больше времени, но и там отложенные сообщения, которые есть в SObjectizer-е, сильно помогли и упростили работу.

По результатам первых двух итераций над Shrimp-ом у нас уже обозначился набор фич, которые было бы полезно добавить как в RESTinio, так и в SObjectizer. Что-то уже пошло в работу (и даже нашло свое воплощение в RESTinio-0.4.7), до чего-то руки дойдут как только, так сразу. Если вы сами хотели бы увидеть что-то в RESTinio и/или SObjectizer-е, то дайте знать, к конструктивным соображениям мы всегда прислушиваемся и стараемся их воплотить. Ярчайший пример -- это добавление в SObjectizer мутабельных сообщений, идея которых возникла при обсуждении возможностей SObjectizer-а в кулурах C++Russia 2017. В том же Shrimp-е практически весь обмен данными между агентами выполняется как раз посредством мутабельных сообщений.

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

В общем, планы на ближайшее время есть. Осталось воплотить их в жизнь. Чем мы, собственно говоря, и займемся.

[prog.c++] Довелось столкнуться со странной структурой данных: и очередь, и multimap.

В рамках следующей итерации над демо-проектом Shrimp постарались закрыть несколько "косяков" самой первой, простейшей версии Shrimp-а. В частности, в простейшей версии Shrimp-а были возможны ситуации, когда пришедшие практически одновременно одинаковые запросы шли в параллельную обработку. Т.е., если мы получаем запрос "demo.jpg?op=resize&max=1024" и следом еще один такой же, то операция трансформации картинки demo.jpg к размеру 1024px могла быть запущена дважды.

Происходило это потому, что Shrimp проверял наличие уже трансформированной картинки в своем кэше. Если ее в кэше нет, то при наличии свободных worker-ов запрос сразу же шел в обработку. Получили запрос для demo.jpg, увидели, что в кэше результата нет, отдали на трансформацию. Результат трансформации еще не пришел, а у нас уже еще один запрос для demo.jpg. Поскольку трансформированной картинки в кэше, ожидаемо, нет, то отдаем запрос на обработку. И получаем, что одна и так же картинка трансформируется параллельно несколькими воркерами. Что не есть хорошо.

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

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

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

[prog.c++] RESTinio v.0.4.7

Мы выпустили очередную версию своей легковесной C++ библиотеки для встраивания асинхронного HTTP/WebSocket сервера в C++ приложения: RESTinio v.0.4.7. В этой версии мы реализовали первую пачку улучшений по следам использования RESTinio в Shrimp-е. Дальше будет больше :)

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

Взять RESTinio можно с BitBucket-а или с github-а. Пользователи vcpkg могут установить себе RESTinio через vcpkg install restinio

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

[prog.c++] Первая статья про Shrimp -- наш демо-проект для RESTinio и SObjectizer

Мы сегодня выкатили на Хабр первую статью о демо-проекте на базе RESTinio и SObjectizer-а: "Shrimp: масштабируем и раздаем по HTTP картинки на современном C++ посредством ImageMagic++, SObjectizer и RESTinio". Нам показалось, что такая задачка отлично показывает сценарий, при котором может потребоваться:

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

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

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

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