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

О блоге

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

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

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

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

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

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

вторник, 28 февраля 2017 г.

[business.book] Проглотил залпом "Доставляя счастье" Тони Шей

Буквально за пару вечеров прочел книгу Тони Шей "Доставляя счастье". Книга о том, как человек с детства пробовал разное, потом оказался в мире ИТ, создал LinkExchange, продал ее Microsoft-у, стал миллионером, венчурным инвестором, затем вложил все, что было в Zappos и не прогадал.

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

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

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

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

[prog.thoughts] Moveable-сообщения для взаимодействия агентов в SObjectizer?

После доклада на C++ Russia 2017 возник интересный вопрос из зала. Речь о том, что сейчас в SO-5 все сообщения (но не сигналы) доставляются как динамически создаваемые объекты. Т.е. за вызовом send<Msg>(...); скрывается сперва new Msg, а затем уже передача указателя на этот экземпляр во все нужные очереди заявок. Основная причина для того, чтобы так делать в том, что у нас возможно доставка сообщения как режиме 1:1, так и в режиме 1:N. И в случае с 1:N мы либо имеем один динамически созданный экземпляр со счетчиком ссылок, либо были бы вынуждены копировать экземпляр сообщения для каждого получателя (что, имхо, гораздо хуже в общем случае).

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

И вопрос из зала состоял в том, а можно ли для случаев, когда используется только лишь взаимодействие 1:1, сделать такую оптимизацию, чтобы send приводил не к вызову new, а к выполнению move-операции. Т.е., чтобы содержимое сообщения мувилось бы куда-то в очередь получателя без дополнительного new.

В текущей реализации механизма доставки сообщений такой подход с moveable-сообщениями, вероятно, не сделать. Но я обещал подумать на эту тему.

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

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

В общем, если тема moveable-сообщений для взаимодействия 1:1 (а может даже и 1:N) кому-то интересно, то дайте знать. Либо в комментариях к этой заметке (можно в G+), либо по почте eao197 на gmail тчк com или info на stiffstream тчк com, либо со мной можно связаться через FB, LinkedIn или Habrhabr.

воскресенье, 26 февраля 2017 г.

[life.work] Мои личные и субъективные впечатления от C++ Russia 2017

Сегодня утром вернулся из Москвы, с конференции C++ Russia 2017, на которой даже умудрился выступить с докладом (отдельное спасибо организаторам конференции за предоставленную возможность, надеюсь, обедню никому не испортил). С физической точки зрения поездка оказалась сложной и выматывающей, так что растекаться мыслею по древу просто нет сил. Посему несколько личных и субъективных впечатлений. Рассказов о докладах и других технических подробностей не будет.

20170226-123808-DSCF5970

среда, 22 февраля 2017 г.

[work.throughts] Что делать со сравнениями SObjectizer и C++ Actor Framework?

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

Суть вот в чем: при обсуждениях SO-5 на публике рано или поздно, в той или иной форме, но всплывает вопрос о том, а чем же SO-5 отличается от CAF? (Ну, или в несколько другой формулировке: чем SO-5 лучше CAF?). Но если три года назад ответ на этот вопрос был интересен мне самому и было какое-то желание участвовать в разговорах на эту тему, то теперь и вопрос нисколько не интересен, и желания отвечать на него нет.

Как по мне, SObjectizer и CAF -- это совершенно разные продукты. У них разная история, разные цели, разные способы достижения этих целей и разные подходы к развитию, да и к самой разработке. Объединяет их одно: оба фреймворка предоставляют реализации Модели Акторов для C++. Но как раз таки эта единственная общая черта и приводит к интересу публики: мол, если и то, и другое реализует Модель Акторов, то в чем именно различия?

Вопрос резонный. Еще более резонно то, что он адресуется нам, как разработчикам SObjectizer, а не авторам CAF-а. Ведь CAF пропиарен намного сильнее, в мире C++ о CAF-е знают очень многие, чего нельзя сказать про SObjectizer. Ну и поскольку спрашивающий, как правило, знает про CAF, но не знает про SObjectizer, то естественно, он думает, что это SObjectizer пытается угнаться за CAF-ом и именно нам, как разработчикам SObjectizer, нужно объяснять что к чему. Чем же так плох CAF, что нужен еще и какой-то SObjectizer?

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

Во-первых, есть ощущение, что проведение таких сравнений -- это пустая трата времени. Мне бы хотелось, чтобы читатели понимали, что время -- это невосполнимый ресурс. Времени на разработку SObjectizer нужно гораздо больше, чем есть у нас в наличии. И отнимать его часть на то, чтобы проштудировать куски документации по CAF, просмотреть примеры, сделать какие-то выводы, затем проверить эти выводы в каких-то экспериментах... Ну очень и очень жалко этого времени, ибо полезный выхлоп, по ощущениям, совсем небольшой. Ну напишем мы в очередной раз, что в SO-5 всего один вид акторов, есть диспетчеры, но нет распределености, в отличии от. Ну и что?

Во-вторых, вступая в такие разговоры мы как бы соглашаемся на то, что SO-5 является аутсайдером по отношению к CAF-у. Что, на мой взгляд, сильно не так. Ну и когда ты слышишь от стороннего разработчика "Если вам нужно что-то работающее, берите лучше SObjectizer", то убеждаешься в этом еще раз.

Поэтому я склоняюсь к тому, чтобы перестать делать какие-то сравнения между SO-5 и CAF-ом. И, соответственно, перестать отвечать на вопросы о том, чем SO-5 лучше CAF и наоборот. Вместо этого, имхо, гораздо продуктивнее будет переводить разговоры в такую плоскость: "Расскажите, какого рода проблема перед вами стоит и я попробую рассказать, как вы сможете решить ее с помощью SObjectizer. Ну или объясню, почему в вашем случае SObjectizer не будет хорошим выбором".

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

В общем, есть большое желание не принимать участия в каких-либо сравнениях CAF-а с SObjectizer-ом (равно как и с другими реализациями). Но, блин, нет уверенности, что это правильно.

PS. Мы пробовали заслать на awesome-cpp PR с информацией о SObjectizer. Но его не приняли. Может быть, одного PR от аффилированных лиц было недостаточно. Поэтому буду признателен, если кто-нибудь из читателей найдет время дабы сделать PR, например, вот с таким текстом:

[SObjectizer](https://sourceforge.net/projects/sobjectizer) - A small framework with implementations of Actor, Pub/Sub and CSP models. [BSD]

воскресенье, 19 февраля 2017 г.

[prog.thoughts] Несколько соображений на тему "А о чем же Модель Акторов?"

В конце своего доклада на C++ CoreHard Winter 2017 я сказал о том, что если кто-то ждет высокой производительности от универсальных акторных фреймворков, то это напрасно. И добавил, что SObjectizer -- это не про производительность, а про другое. Подразумевая при этом не только SObjectizer, но и вообще реализации Модели Акторов, включая Erlang и Akka. C CAF-ом ситуация, имхо, чутка другая -- они сами говорят про high performance, ну и флаг им в руки, ибо замеры говорят сами за себя ;)

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