вторник, 1 января 2030 г.

О блоге

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

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

понедельник, 31 декабря 2029 г.

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

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

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

четверг, 7 сентября 2017 г.

[prog.actors] Хотите решить задачу с помощью акторов? Спросите меня как! :)

После того, как мне довелось разным людям в разных местах рассказывать про Модель Акторов вообще и про SObjectizer в частности, сложилось впечатление, что продвижению Модели Акторов в массы препятствует две вещи:

  1. Отсутствие понимания того, что такое Модель Акторов вообще. Это, на самом-то деле, совсем не проблема. Очевидно, что всего на свете знать нельзя, а объяснить основные принципы работы Модели Акторов можно буквально на пальцах (что, кстати говоря, подтверждается практикой).
  2. Отсутствие понимания того, как эту самую Модель Акторов, принципы которой можно объяснить на пальцах, применить для решения практических задач.

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

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

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

Зачем это нужно мне? Очевидно, что мои цели исключительно корыстные ;) Прежде всего мне нужен материал, на основе которого можно было бы убедительно рассказывать людям о том, где применение Модели Акторов уместно, а где нет. Кстати говоря, неуместность применения Модели Акторов -- это актуальный вопрос. Бывает, что люди слушая про Модель Акторов теряют представление о том, что данная модель применима далеко не всегда. И хорошо бы уметь вовремя различать, где имеет смысл брать акторов, а где этого делать не нужно. Так же мне полезно прикидывать, насколько наш SObjectizer пригоден для решения тех или иных задач. Опыт показывает, что это сильно идет на пользу SObjectizer-у. А т.к. сам SObjectizer распространяется под BSD-лицензией (бездвоздме т.е. даром), то это пойдет на пользу и всем, кто воспользуется SObjectizer-ом.

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

В общем, если есть задачка и желание ее обсудить, то милости прошу. Описывайте свои задачки в комментариях к этой заметке (можно в G+), либо по почте eao197 на gmail тчк com, либо со мной можно связаться через FB, LinkedIn или Habrhabr.

PS. Запись специально повисит вверху до сентября. Но, если дело пойдет, можно будет заказать продление ;)

вторник, 27 июня 2017 г.

[prog.c++] Практически динамически-типизированное программирование

Давеча, занимаясь примером для демонстрации Asio-инфраструктуры для SObjectizer из нового проекта so_5_extra, написал фрагмент C++кода, в котором практически не фигурировали имена конкретных типов. Буквально возникло впечатление, что программирую на каком-то динамически-типизированном языке (правда, с излишне многословным синтаксисом). Кому интересно посмотреть немного C++14-того хардкора милости прошу под кат.

понедельник, 26 июня 2017 г.

[prog.c++] so_5_extra-1.0.0 и so-5.5.19.2

Мы выпустили первую версию своего нового проекта поверх SObjectizer -- so_5_extra версии 1.0.0.

В этой версии в so_5_extra доступны:

  • so_5::extra::env_infrastructures::asio::simple_not_mtsafe -- реализация однопоточной инфраструктуры SObjectizer-а на базе Asio. Т.е. с использованием этой инфраструктуры и Asio, и SObjectizer смогут работать на одной и той же рабочей нити;
  • so_5::extra::mboxes::round_robin -- специальный mbox, который доставляет сообщения поочередно каждому из N агентов, подписанных на это сообщение;
  • so_5::extra::shutdowner -- небольшой инструмент для упрощения операции завершения работы в больших приложениях.

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

Документацию по проекту можно найти в Wiki. Если из документации чего-то не понятно или что-то в ней не описано, то не сочтите за труд, дайте нам знать. Улучшим, расширим и углубим :)

Проект header-only. Если захочется собрать тесты и примеры самостоятельно, то придется воспользоваться Ruby и Mxx_ru. Зависимости так же подтягиваются через MxxRu::externals. Но в секции Files есть архивы с именами вида so_5_extra-1.0.0-full.tar.xz, в которых уже все зависимости присутствуют. Поэтому можно брать *-full.tar.xz архив, распаковывать, прописывать в INCLUDE путь к so_5_extra-1.0.0/dev и пробовать.

Работоспособность проверялась под Linux-ом (gcc 5.4 и 7.1, clang 3.7 и 4.8) и Windows (gcc 5.2-7.1, VC++ 14.0 и 15.0). На всякий случай выставлять -Werror при работе с so_5_extra не советуем, т.к. и gcc, и clang очень сильно ругаются на потроха Asio.

В планах у нас добавление еще нескольких фич в so_5_extra. Следующие версии будут выходить по мере добавления новых фич. В том числе в планах и simple_mtsafe-инфраструктура для Asio, но приоритет у этой задачи не самый высокий. Если кому-то нужна thread-safe реализация Asio-инфраструктуры для SO-5, то дайте знать. Постараемся повысить приоритет.

Обращаем внимание, что so_5_extra распространяется под двойной лицензией: GNU Affero GPL для OpenSource применения, и коммерческая лицензия для использования в закрытых проектах. Если кому-то интересна коммерческая лицензия, то пишите на info at stiffstream dot com, там цена вопроса порядка $40 за одного разработчика в год.

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

пятница, 23 июня 2017 г.

[prog.c++.flame] Взять бы, да и закрыть Boost...

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

Вот просто взять и закрыть. Что вошло в Boost, то пусть там и остается.

А вот всем остальным нужно учиться жить без Boost-а.

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

Да и смысл Boost-а в настоящее время от меня ускользает. 17 лет назад Boost был полигоном для обкатки того, что хотелось бы включить в стандарт. Boost.Thread, Boost.SharedPtr, Boost.Optional и все такое. Ну OK, тогда это было актуально, когда работа над стандартами C++ велась не слишком быстро.

Но сейчас-то? Какой смысл в Boost-е кроме как в централизованной сборке относительно небольшого количества C++ных библиотек, которые совместно тестируется перед релизом? Ну кроме протекционизма?

Кстати о протекционизме. Вот есть в Boost-е библиотеки Boost.Test, Boost.Log, Boost.Format. Для которых существуют не менее достойные, мягко говоря, аналоги в виде Catch, Spdlog и Fmtlib. С какой стати старые и неудобные монстры, вроде Boost.Test и Boost.Log, должны иметь преференции в современном мире перед теми библиотеками, которые в Boost не входят? Ведь не так уж и редко от сторонних аналогов люди отказываются потому, что дальше Boost-а и не заглядывают. Но даже если и заглядывают, то иногда предпочитают Boost, потому что Boost к проекту уже подключен, а подтаскивание еще одной библиотеки в C++ный проект -- это боль для многих.

В общем, Карфаген должен быть разрушен Boost сделал свое дело, Boost должен уйти.

PS. Пост написан под влиянием боли, которая появляется, когда в зависимостях кросс-платформенного проекта оказывается достаточно свежая версия Boost-а.

четверг, 22 июня 2017 г.

[prog.c++] Если разрабатывать REST-сервисы на C++, то как должен выглядеть "инструмент мечты"?

Допустим, вам нужно разработать RESTful сервис на C++. Не будем сейчас вступать в религиозные споры на тему того, зачем, когда и кому в здравом уме это может потребоваться. Ну мало ли ;) Может нужно выставить REST API для старого легаси-кода, которому 20 лет и который никто с C++ переписывать не будет. Может нужна высокая эффективность и низкое потребление ресурсов. Может нужно сделать это для военки на Эльбрусах какой-то экзотической платформы, для которой нормального качества компиляторы есть только для C и C++. Может еще что-то, включая упоротость и мазохизм :)

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

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

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

Может вы уже используете что-то и вас в этом что-то сильно не устраивает? Что?

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