вторник, 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. Запись специально повисит вверху до сентября. Но, если дело пойдет, можно будет заказать продление ;)

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

[prog.c++] Вопрос к читателям: интересна ли кому-нибудь статья о деталях реализации asio_thread_pool диспетчера?

Мы вчера выкатили so_5_extra-1.0.2 с реализацией нового диспетчера на базе Asio. В этой самой реализации получилось интересное, как мне кажется, использование фишек С++, включая наследование, шаблоны и даже thread_local переменные. Причем "интересное" именно в плане использования возможностей языка. Специфика SObjectizer-а, конечно же, есть, но скорее как фон и условия, для которых пришлось искать решение.

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

Посему у меня к читателям блога пара вопросов:

  1. Будет ли интересен кому-нибудь такой рассказ вообще? Не хочется тратить несколько дней работы на то, что прочитает 10-15 человек.
  2. Если же статья все-таки кому-то интересна, то где бы вам было бы удобнее ее видеть: у меня в блоге или на Хабре? Место публикации важно потому, что, во-первых, от этого зависит стиль и подробность изложения, а так же, во-вторых, удобство комментирования и качество комментариев. В принципе, с точки зрения величины аудитории я бы нацеливался на Хабр. Но если у многих моих читателей к Хабру отношение негативное, то проще будет написать статью для блога.

В общем, прошу не счесть за труд и высказать свое мнение. Можно и пожелания по будущему тексту (например, на что сделать акцент, чтобы статья была интереснее для вас). Комментарии можно оставлять в блоге или в G+. Ну или там, где я еще размещу ссылки на этот пост (типа Facebook-а или LinkedIn-а).

На 2017.09.22 17:55 "за" проголосовало только три человека, это мало для того, чтобы браться за написание статьи.

понедельник, 18 сентября 2017 г.

[prog.c++14] Мечты сбываются: задышала реализация диспетчера, которая может использовать пользовательские классы нитей

В рамках работ над новой версией so_5_extra разрабатывается asio_thread_pool-диспетчер. Это диспетчер, в котором на пуле потоков запускаются методы asio::io_service::run(), и агенты, которые привязаны к такому диспетчеру, отрабатывают свои события на этих же рабочих потоках. По сути, диспетчеризацией событий для таких агентов занимается asio::io_service. Что должно дать возможность агентам просто и прозрачно выполнять и IO-операции, и обработку прикладных сообщений не задумываясь о том контексте, на котором они работают (ноги у этого всего растут вот отсюда).

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

Ну, например, если вы хотите использовать какую-то специфическую для ОС функциональность, недоступную через std::thread. Скажем, если вам нужно назначить собственные pthread_attr_t перед запуском рабочей нити. Это не такая уж и экзотическая ситуация. Например, если вы создаете большое количество нитей в приложении, то можете захотеть уменьшить размер стека для них, т.к. размер по умолчанию для вашей задачи может быть слишком большой.

Так вот, этот новый asio_thread_pool показал, что подобный фокус вполне себе работает. И выглядит это как-то вот так:

// Definition of traits to be used with asio_thread_pool.
struct my_disp_traits
{
   // Actual type of thread to be used.
   using thread_type = my_pthread_t;
};
...
   // Create dispatcher for ring of agents.
   auto disp = asio_tp::create_private_disp<my_disp_traits>(
         coop.environment(),
         "asio_tp",
         std::move(disp_params) );

Стоить определить в traits-ах для диспетчера имя класса, который следует использовать вместо std::thread, и asio_thread_pool начнет использовать данный класс.

Любопытные последствия могут быть у этого эксперимента. У меня уже давно есть мысль о том, чтобы добавить возможность такой кастомизации ко всем штатным диспетчерам SO-5. И, поскольку эксперимент оказался удачным, такая возможность может воплотиться в реальность в SO-5.5.20, работа над которой должна начаться вот прямо после фиксации so_5_extra-1.0.2. А это означает, что реализации штатных диспетчеров вынужденно станут шаблонными. Что заметно уменьшит количество .cpp-файлов в исходниках SObjectizer-а. Что будет означать еще одним большой шаг в сторону header-only версии SO-5. При этом header-only -- это вовсе не самоцель. Но чем больше будет в SO-5 кастомизаций через шаблоны, тем ближе к header-only окажется реализация.

Под катом простейшая реализация my_pthread_t, набросанная на коленке за 15 минут...

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

[prog.humour] Маленький фрагмент трудовых будней :)

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

Зачем я его показываю? Наверное, чтобы было понятно, что короткие идентификаторы -- это не про меня ;)

templatetypename Traits = default_traits_t >
inline private_dispatcher_handle_t
create_private_disp(
   //! SObjectizer Environment to work in.
   environment_t & env,
   //! Value for creating names of data sources for
   //! run-time monitoring.
   const std::string & data_sources_name_base,
   //! Parameters for the dispatcher.
   disp_params_t disp_params )
   {
      const auto io_svc_ptr = disp_params.io_service();
      if( !io_svc_ptr )
//FIXME: must be replaced by SO_5_THROW_EXCEPTION!
         throw std::invalid_argument( "io_service is not set in disp_params" );

      if( !disp_params.thread_count() )
         disp_params.thread_count( default_thread_pool_size() );

      using so_5::stats::activity_tracking_stuff::create_appropriate_disp;
      auto disp = create_appropriate_disp<
            // Type of result pointer.
            private_dispatcher_t,
            // Actual type of dispatcher without thread activity tracking.
            impl::real_private_dispatcher_t<
                  Traits,
                  impl::dispatcher_skeleton_without_thread_activity_tracking_t >,
            // Actual type of dispatcher with thread activity tracking.
            impl::real_private_dispatcher_t<
                  Traits,
                  impl::dispatcher_skeleton_with_thread_activity_tracking_t > >(
         // Args for create_appropriate_disp.
         env,
         disp_params,
         // Args for real_private_dispatcher_t constructors.
         env,
         data_sources_name_base,
         disp_params );

      return { disp.release() };
   }

PS. Код еще на альфа-стадии.

вторник, 12 сентября 2017 г.

[prog] А что, кстати говоря, с хайпом вокруг Haskell?

Сегодня довелось наткнуться на довольно старую презентацию Engineering Large Projects in Haskell: A Decade of FP at Galois и подумалось, что еще несколько лет назад хайп вокруг Haskell-я был достаточно заметным. А что сейчас? Поутих? Или это просто мне на глаза больше ничего подобного не попадается?

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