[prog.flame] И вот для этого стоило осваивать Хаскелл?

Люди сообщают с мест:

Компания называется Restaumatic, Польша. Пишем сервисы для ресторанов: заказ еды, системы скидок, сайты, вот это вот все. Обычный web, CRUD, фронтенд на PureScript, бэкенд на Haskell. На самом деле, переписываем потихоньку эту функциональность с RoR и добавляем новую.

Цинк: cpp_stm_free: монадическая STM библиотека для параллельного программирования.

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

Мне, например, нравится использовать C++ в вещах, связанных с низким или более-менее низким уровнем. Протоколы какие-нибудь реализовывать, устройствами какими-нибудь управлять, писать ядра СУБД или MQ-брокеров, ресурсы экономить (выжимать тактики из битиков, как кто-то когда-то хорошо сказал). Но это прежде всего потому, что сами эти задачи мне нравятся. А C++ оказался весьма хорошо приспособлен для таких задач.

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

А тут Web-приложение с бэкэндом на Хаскелле, которое суть складской учет, который во времена оные отлично покрывали dBase-ами и Clipper-ами... Нужно, наверное, очень сильно любить Хаскелл ;)

PS. Интересно было бы лет через 5-10 узнать, чем все закончилось. А то вспоминается пример Sociomantic-а, в котором когда-то выбрали в качестве языка реализации D1, а потом столкнулись с тем, что есть большая и работающая кодовая база на D1, который уже никому не нужен, и есть совсем другой D2, который с D1 не совместим ни на уровне языка, ни на уровне библиотек. Но там хотя бы выбор шустрого D был оправдан требованиями к скорости реакции. Ради чего выбирать Хаскелл для рядового Web-приложения -- это вопрос.

[prog.c++] В августе буду выступать на митапе St.Petersburg C++ User Group

Благодаря Анастасии Казаковой из JetBrians в августе, 23-го числа (четверг), выступлю в Питере на митапе тамошней C++ User Group с докладом "Акторы в C++: взгляд старого практикующего актородела". Все подробности и возможность зарегистрироваться на митап вот здесь.

Этот доклад будет квинтэссенцией из моих предыдущих докладов на CoreHard C++ и C++ Russia. Предыдущие доклады были сильно ограничены по времени: всего сорок минут на само выступление + 10-15 минут на вопросы. Здесь же будет практически часовое выступление, в процессе которого я постараюсь затронуть основные моменты, связанные с акторами в C++. Т.е. что такое Модель Акторов вообще и почему к ней сейчас такой интерес. Имеет ли смысл использовать акторы в C++ (да, имеет, но не всегда). Какие особенности накладывает C++ при этом. Что есть готового для C++ вообще, почему это настолько сильно отличается друг от друга. Ну и немного про SObjectizer, конечно. В общем, то, что раньше приходилось растягивать на 3-4 отдельных доклада в этот раз будет выдано в рамках одного рассказа, без лишней воды и философствований.

В общем, приходите, должно быть интересно. По крайней мере можно будет посмотреть на меня живьем и задать какой-нибудь неудобный вопрос в лицо. Вроде того, почему я такой муд так сильно не люблю Rust Java, пора ли закапывать С++ и есть ли жизнь в ИТ после сорока ;)

[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-а что-то полезное не только нам самим.