О блоге

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[prog] Проблема нумерации: so_5_extra-5.5.19-1.0 или so_5_extra-1.0-5.5.19 или...?

В очередной раз столкнулся с одной из неразрешимых проблем в программировании: выборе названия :) Точнее, не названия, а системы нумерации, но это даже сложнее :(

У нас на финальную стадию подготовки к релизу вышла дополнительная библиотека для SObjectizer-а под названием so_5_extra. Сейчас в нее входят три компонента: однопоточный вариант SObjectizer Environment на базе Asio (немного об этом здесь), готовая реализация round-robin mbox-а и специальная штука под названием shutdowner, которая предназначена для обработки некоторых сценариев завершения больших приложений. Со временем состав so_5_extra будет еще расширяться, но для первого релиза нам показалось достаточно этих трех. Все это уже работает и протестировано, но нужно еще написать какую-то вводно-обзорную документацию.

Неожиданной сложностью оказался выбор системы нумерации версий для so_5_extra. Традиционный semver, вроде so_5_extra-1.0.0, здесь не очень подходит потому, что версии so_5_extra планируется плотно синхронизировать с версиями SObjectizer-а. Поскольку so_5_extra в своей реализации очень активно использует знание того, что и как выполняется в конкретной версии SObjectizer. Поэтому версия so_5_extra-1.0.0, которая была сделана для SObjectizer-5.5.19, не обязательно будет работать с SObjectizer-5.5.18 или SObjectizer-5.5.20. В обратном направлении, кстати, тоже работает. SObjectizer так же допиливается под нужды so_5_extra. Например, вместе с первой версией so_5_extra мы опубликуем и SObjectizer-5.5.19.2, в который добавлено несколько фич для работы so_5_extra.

Поэтому хочется иметь какую-то систему нумерации, в которой номера версий so_5_extra были каким-то боком увязаны друг с другом. Но, при этом, чтобы допускалась некоторая свобода. Например, может быть so_5_extra-1.0.0, которая выпущена для SO-5.5.19.2, но затем появляется SO-5.5.19.3, из-за которой менять номер для so_5_extra не нужно. С другой стороны, может быть so_5_extra-1.0.1, ради которой не нужно менять номер версии SO-5.5.19.2.

В результате я сейчас всерьез рассматриваю следующие варианты системы нумерации:

1. so_5_extra-5.5.19-1.0. С тем, чтобы впоследствии можно было использовать номера вида so_5_extra-5.5.19-1.0.12, so_5_extra-5.5.19-1.2.39, so_5_extra-5.5.20-1.0 и т.д. Тут, правда, возникает вопрос: как между собой соотносятся, скажем so_5_extra-5.5.19-1.2.39 и so_5_extra-5.5.20-1.0.0? На который у меня пока ответа нет;
2. so_5_extra-1.0-5.5.19. С последующим развитием в сторону so_5_extra-1.2.39-5.5.19, so_5_extra-2.0-5.5.19 и т.д.
3. Просто тупо совместить нумерацию so-5 и so_5_extra. Т.е. если есть so-5.5.19.2, то и есть so_5_extra-5.5.19.2. Если есть so_5_extra-5.5.20.34, то есть и so-5.5.20.34. Хотя этот вариант мне нравится меньше всего.

Посему вопрос к читателям: что вас меньше испугает и запутает? so_5_extra-5.5.19-1.0.0 или so_5_extra-1.0.0-5.5.19?

[business.book] Кратко о книге "Великие по собственному выбору" Джима Коллинза и Мортена Хансена

Закончил читать книгу "Великие по собственному выбору". Один из авторов которой, Джим Коллинз, отметился серией бестселлеров "Построенные навечно" (мне не понравилось), "От хорошего к великому" (не читал), "Как гибнут великие" (хотел бы прочесть, но нигде не продают ее электронную версию). Теперь вот следующая книга в этой серии, на этот раз в соавторстве с Мортеном Хансеном.

Первые страниц 200 занимает обсуждение результата анализа нескольких компаний, разделенных на пары. Первой компанией в паре была компания, показавшая до 2002-го года результат, в 10 раз превосходящий средний по своей отрасли. Второй в паре была компания, которая очень похожа по размерам, истории и целям, но которая не смогла добиться успеха в тех же самых временных рамках.

Авторы книги утверждают, что они обнаружили несколько общих черт, которые присущи выдающимся компаниям (которые в книге называются 10-кратники). Несколько общих принципов, которые, по мнению авторов книги, привели компании 10-кратники к тем самым выдающимся результатам. Соответственно, на первых 200-х страницах обсуждаются эти принципы, то по отдельности, то вместе.

Завершающие 100 страниц -- это рассказ о том, как само исследование проводилось. Эту часть книги я не читал, только слегка просмотрел. Как по мне, завершающая треть книги может быть интересна только тем, кто сам собирается провести какое-то подобное исследование.

Мои впечатления следующие:

• первые 2/3 книги читаются легко и интересно, много примеров из разных областей. Воды не много, хотя и не обошлось без типичной англосаксонской манеры неоднократно повторять одно и то же на разные лады. Так что если ничего из Коллинза раньше не читали, смело можно взять и познакомиться с творчеством автора;
• некоторые моменты, о которых лично я имел несколько другое мнение, заставляют задуматься о том, а насколько вообще авторы книги понимают специфику определенных прикладных областей и правильно ли они интерпретируют обнаруженные ими в процессе исследования факты. Например, рассказ о том, как Microsoft относилась к разработке OS/2 для IBM и как Microsoft "подстраховалась" от рыночной неудачи OS/2 продолжая работу над своей ОС Windows. Если читатель более-менее в курсе истории отношений Microsoft-а и IBM, а так же в курсе истории развития OS/2 и причин неудачи OS/2 на рынке, то у него могут возникнуть возражения против точки зрения авторов книги (у меня, например, возникли). Соответственно, ловишь себя на мысли, что есть есть несостыковочка здесь, то может она не одна такая? И насколько тогда можно доверять выводам авторов?
• у меня сложилось ощущение, что ключевыми факторами, на которых авторы книги пытались заострить внимание читателей, являются: здравый смысл, последовательность и дисциплина. Что очень сильно, на мой взгляд, пересекается с ключевыми факторами из "Живой компании" Ари де Гиуса. А раз так, то смело можно обойтись чтением "Живой компании" вместо "Великие по собственному выбору".

Так что, если вы пока еще не прочитали "Живую компанию" и, например, "Управление жизненным циклом корпорации" Ицхака Адизеса, то лучше сперва прочесть эти две книги, а не "Великие по собственному выбору". Ну а если это все уже прочитано, но хочется прочитать что-нибудь именно из Коллинза, то тогда можно и "Великие по собственному выбору" осилить. Хуже точно не будет.

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

[prog.c++] В очередной раз про Rust. О том, почему до сих пор меня Rust не прельстил

На C++ я программирую уже давно. Лет 25 точно. Не могу сказать, что знаю C++ хорошо, но, наверное, хорошо знаю, как использовать C++ так, чтобы не было мучительно больно. Тем не менее, не могу не признать, что C++ уже весьма стар, сложен и противоречив. Хоть программировать на нем в последнее время становится удобнее, но есть серьезные родовые травмы, которые будут постоянно отравлять жизнь C++ разработчикам. Посему лично я был бы не прочь со временем сменить C++ на что-то более современное, удобное и безопасное.

На мой взгляд, из того, что сейчас существует для разработки из нативных языков без GC, самой реальной и серьезной альтернативой для C++ является язык Rust. Так же мне кажется, что Rust -- это всерьез и надолго. Как много Rust переманит именно C-шников и C++-ников -- это отдельный вопрос, думаю, что изрядное количество Rust-программистов будут составлять те, кто пришел в Rust не из мира C/C++, а из мира безопасных языков с GC и, вероятно, из мира функциональщины.

Сам я пока в Rust всерьез не вложился и причины тому вовсе не какие-то идеологические, а весьма прозаические. Мы с коллегами пытаемся создать бизнес вокруг инструментария для программистов. Что именно начнет приносить нам деньги -- продажа продуктов, продажа коммерческих лицензий, обучение, консалтинг, заказная разработка или что-то другое -- это выяснится со временем. Поскольку у нас большой опыт в C++, то сейчас мы концентрируемся именно на инструментарии для C++. Ибо здесь есть рынок: по некоторым оценкам количество C++ разработчиков в мире насчитывает более 3 миллионов человек, накоплена огромная кодовая база на C++, которая никогда не будет переписана на других языках, да и новые проекты на C++, пусть не часто, но начинают (и выбор C++ в качестве языка реализации нового проекта в современных условиях вполне имеет смысл). Так что в области C++ есть и какой-никакой рынок, и нам есть что на нем предложить.

А вот для Rust-а такого рынка, насколько я могу судить, пока еще нет. Вроде как есть какой-то совсем небольшой спрос на Rust-разработчиков, но вряд ли сейчас найдется много желающих покупать коммерческие библиотеки для Rust-а, или коммерческие лицензии на такие библиотеки. Да и вряд ли кто-то будет готов платить за консультации по Rust-у или за обучение Rust-у разработчиков, переходящих на Rust с других языков программирования. Думаю, что не ошибусь, если скажу, что не смотря на весь хайп вокруг Rust-а, реальное присутствие Rust-а в коммерческой разработке ПО в мире находится где-то на уровне статпогрешности. Посему достаточно емкого рынка инструментария для Rust-а еще просто нет. Может через 3-5 лет такой рынок сложится и достигнет достаточного объема, чтобы на нем можно было бы зарабатывать. Но сейчас это не так.

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

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