О блоге

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

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

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

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

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

[prog] И еще раз об обозримости task-based подхода

В докладе "Actors vs CSP vs Tasks..." на C++ CoreHard Autumn 2018 (видео тут, текстовая версия тут) я сказал, что когда код пишется с использованием task-based подхода, то обозримость у этого кода получается так себе. А несколько дней назад на Reddit-е всплыла ссылка на статью под названием "Modern dining philosophers". В которой как раз демонстрируется несколько подходов к решению известной задачи "обедающие философы". Но все эти подходы используют task-и.

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

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

В общем, сходите, почитайте статью. Она не новая, вышла в конце декабря 2018-го, ссылка на нее только недавно на глаза попалась. И не очень маленькая, полчаса времени, минимум, выделить придется. Составьте собственное впечатление. А будет желание -- поделитесь впечатлением в комментариях.

PS. Я думаю написать статью с разбором решения этой же задачи на базе SObjectizer-овских агентов. Кому интересно подобное "сравнение" (хотя это не будет чистой воды сравнением), не пожалейте времени поставить плюсадынку или лайк. Чем больше оных наберется, тем быстрее появится моя статья.

[prog.thoughts] "C++ vs others" через призму "поддерживающих" и "подрывных" технологий

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

Контекст продиктован вот этой замечательной книгой: "Дилемма инноватора: Как из-за новых технологий погибают сильные компании". Одна из идей, которая лежит в ее основе, такова: есть "поддерживающие" технологии, которые плавно и постепенно улучшают качество уже существующих товаров/услуг/сервисов. А есть "подрывные" технологии, которые сразу после своего появления на свет не могут составить конкуренцию уже существующим технологиям. Поэтому "подрывные" технологии сперва используются в каких-то маргинальных рыночных нишах, там обкатываются, совершенствуются, постепенно проникают на старые рынки и вытесняют оттуда технологии, которые считались устоявшимися.

[prog.c++] О чем не нужно забывать бросаясь какашками в C++

Конец 2018-го года и начало 2019-го сопровождалось каким-то невиданным количеством критики в адрес языка C++. Что лично у меня, как нехило вложившегося в разработку инструментария для C++, вызвало тяжелые ощущения. Как-то не очень приятно, когда на полянку, которую ты много лет тщательно расчищал и облагораживал, какие-то странные люди вываливают несколько тележек дерьма, а потом еще и начинают радостно разбрасывать его во все стороны.

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

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

[prog.f*ck] Самый унылый релиз SObjectizer-а. И его последствия. Пока непонятные

Намедни мы выпустили очередную версию SObjectizer-а. И, пожалуй, на анонс этой версии была самая унылая реакция. Когда я начинал писать этот пост, на Reddit-е анонс SO-5.5.24 набрал всего 2 очка при 60% upvotes. И там был всего один вопрос про сравнение с CAF-ом, ответ на который изначально заминусовали. Собственно, показатели посещаемости сайта и загрузок в этот раз ничем не лучше.

[prog.thoughts] "За*бало" как основная причина хайпа вокруг Rust?

Поводом к написанию данной заметки стали комментарии от ув.тов Сергея Скороходова, свежая запись в блоге ув.тов.kaa.python про социальные факторы и Rust, а так же ссылка на эту статейку, найденную на Hacker News.