[life.books] Коротко о четырех книгах, которые я пытался прочитать в последнее время

Можно сказать, что это очередной книгообзор. На этот раз о четырех книгах в одном посте. Сперва о двух, которые я не дочитал. Затем о двух, которые прочитал и получил удовольствие.

Первая книга -- "Просто гениально" за авторством Уильяма Тейлора.

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

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

Вторая книга -- "Покер лжецов" Майкла Льюиса.

Просто оказалась не моя тема. В книге рассказывается о том, что происходило на Уолл-стрит с конца 1970-х и начала 1980-х. Рассказывается, в основном, о людях, но с сильной привязкой к финансовым механизмам, которые работали в то время. Но, поскольку в торговле ценными бумагами я вообще ничего не понимаю, то не понимаю и контекста, внутри которого происходят описываемые автором события. Без такого понимания читать просто не интересно. Но вообще книга написана живым, может быть местами грубоватым, языком. Так что если кто-то знаком с рынком облигаций, то ему книга может быть покажется интересной. Я же не дочитал и до половины.

Третья книга -- "«Do not disturb». Записки отельера". Автор Юнис Теймурханлы.

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

Наконец, четвертая книга -- "Ген директора" Владимира Моженкова.

Просто отличная книга. Все четко, по делу, без воды, хождения по кругу и лишних соплей. Тем, кто собирается открывать свое дело или же пытается чем-то управлять, имеет смысл прочесть. Какие-то моменты могут конкретно зацепить. Например, меня зацепил момент, связанный как раз с чтением книг. Автор рассказывал, как он прививал в своей компании привычку к чтению. И как затем начал спрашивать "Ну вот ты прочитал, а что применил? Ничего? Так зачем читал?". Я вроде как чего-то по менеджменту читал. Но не скажу, что применял. Скорее читал для того, чтобы лучше понимать происходящее и расширить свой кругозор. Поэтому такой вопрос "в лоб" меня самого застал врасплох :)

[prog.c++] Пересмотр приоритетов для SO-5.5.20

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

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

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

Если же кому-то возможность использовать собственные нити вместо std::thread нужна уже сейчас или в обозримом будущем, то дайте нам знать. Если это реально кому-то нужно, то приоритет мы поднимем и такую функциональность реализуем. Но хочу, чтобы было понятно: в SO-5 сейчас и так уже достаточно фич. Просто так добавлять туда очередную фичу просто "шоб было" a) не интересно и b) не выгодно. Все-таки мы делаем SO-5 за свои и тратить свои ресурсы на то, что останется лежать мертвым грузом -- это сомнительная идея.

Так что если вам что-то нужно в SO-5, то найдите способ сказать нам об этом (например, в комментариях к этой заметке, а еще лучше по email: info at stiffstream dot com или eao197 at stiffstream dot com, или на мой gmail-овый ящик). То, что нужно реальным или потенциальным пользователям, мы будем добавлять в SO-5.

Пока же в работах над версией 5.5.20 мы попробуем сосредоточиться на том, что может [не]существенно изменить подходы к использованию SO-5 и агентов. В частности это может быть:

• более простая и тесная интеграция mchain-ов и агентов. Суть в том, чтобы сообщение, которое кто-то отсылает в mchain, могло поступать напрямую конкретному агенту. Тем самым mchain работал бы как естественный механизм overload control. Подробнее это описано здесь;
• эта фича сейчас под вопросом до тех пор, пока не появятся какие-то дополнительные типы mchain-ов (например, в рамках so_5_extra). Когда будут разные типы mchain-ов, с разной логикой поведения, тогда будет лучше понятно, можно ли сделать универсальную интеграцию агента с разнотипными mchain-ами.
• возможность каскадировать mbox-ы. Это выглядит актуальным в связи с появлением новых типов mbox-ов в so_5_extra. Например, может быть MPMC-mbox, одним из подписчиков которого будет collecting_mbox, а подписчиком collecting_mbox-а может быть round-robin mbox, подписчиком которого могут быть mchain-ы. Сейчас подписчиком mbox-а можно сделать только агента и это не позволяет выстраивать подобные цепочки без использования промежуточных агентов. Может быть такая возможность каскадирования mbox-ов поможет, например, в реализации реактивного программирования поверх SO-5;
  • разбирательство с текущим механизмом доставки сообщений показало, что эту функциональность сложно сделать без слома API. Делать такой слом в ветке 5.5 неразумно (следует сохранять совместимость в рамках релизов 5.5.*). А выделять версию 5.6 только ради одной фичи -- это преждевременно;
• какое-то приближение к идее сессионных типов. Это когда сценарий взаимодействия между агентами описывается на уровне типов: сперва в одну сторону может пойти сообщение request, а обратно может прийти либо response, либо timeout, а затем может пойти только finish, но не request. Либо же это может быть какое-то приближение к типизированным mbox-ам и/или агентам. Опять же, прямо на уровне типов описывается, какие воздействия воспринимаются mbox-ом/агентом. Данная тема поднималась ранее;
• какие-то инструменты для упрощения тестирования агентов. Этот вопрос задавали на последней C++ CoreHard. И он действительно актуален, т.к. тестирование агентов, которые общаются с внешним миром через асинхронные сообщения -- это не просто. Но в данной теме еще и конь не валялся.

В общем, пока вот такие приоритеты. Опять же повторюсь, если будут какие-то конкретные предложения (вроде идеи с мутабельными сообщениями или возможности проверить существование подписки), то мы их внимательно рассмотрим. И, с большой вероятностью, реализуем. Так что есть более чем реальная возможность повлиять на развитие SO-5.

[life] Ну, с юбилеем!

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

Вот такая вот история. Капиталист с грустью отмечает столетний юбилей Великой Октябрьской социалистической революции...

С праздником!

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

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

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

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

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

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

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

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

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

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