О блоге

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

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

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

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

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

[prog.thoughts] Несколько слов о попытке спроектировать транспорт для SObjectizer-а на базе ZeroMQ

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

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

[prog.flame] Вещи, которые мне не понравились при знакомстве с ZeroMQ

После недели штудирования и обдумывания "0MQ - The Guide" попробую зафиксировать несколько вещей, которые мне не понравились в ZeroMQ. А в следующем посте я попробую рассказать о текущих соображениях на тему применения ZeroMQ для построения распределенных SObjectizer-приложений. Так что сегодняшний рассказ может быть интересен более широкому кругу читателей.

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

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

Disclaimer. Я не буду рассказывать об азах ZeroMQ. Поэтому, если вы со спецификой ZeroMQ не знакомы, то написанное ниже может быть для вас непонятно. Поэтому я могу посоветовать найти время и хотя бы поверхностно познакомиться с двумя первыми главами из "0MQ - The Guide" (под названиями "Chapter 1 - Basics" и "Chapter 2 - Sockets and Patterns", хотя может хватить и только первой главы).

[prog.flame] Удалось более четко сформулировать свое отношение к ZeroMQ

Штудируя 0MQ - The Guide в конце-концов поймал себя на том, что по ходу усвоения материала я думаю не о том, как использовать ZeroMQ в тех или иных сценариях, а о том, что мне в ZeroMQ не нравится и почему мне не хочется использовать ZeroMQ.

Т.е. глядя на ZeroMQ я вижу не достоинства, а недостатки (возможно, чисто субъективные).

Это, блин, нехороший знак. Хотя претензии к ZeroMQ "математически выразить" (с) еще не могу, на осмысление своих претензий к ZeroMQ требуется время.

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

[smartphones] Кто из производителей смартфонов регулярно выкатывает обновления для своих телефонов?

Хочу обратиться с внезапным вопросам к тем моим читателям, которые находятся в теме смартфонов на Android-е. Есть ли нормальные производители смартфонов, которые регулярно выкатывают обновления программной начинки для своих телефонов? Особенно если это не топовые модели, а более-менее бюджетные, за $100-150-$200?

Вот у меня двухлетний Samsung J200, который работает на Android 5.1.1. И что-то я не припомню, чтобы для него приходили обновления от Samsung-а. Обновления для установленных приложений, вроде GMail, приходят. А вот для самой системы... Вряд ли такое имело место быть.

Поскольку я далек от темы смартфонов (телефон для меня -- это прежде всего звонки, мобильный Интернет и, временами, навигация на местности), то не в курсе, есть ли производители, которые после выпуска своей модели на рынок регулярно выпускают софтварные обновления и, может быть, даже позволяют обновить версию Android-а на аппарате. Или же нормальной практикой является выпустить модель с актуальной на тот момент версией Android-а на борту, а потом забить на ее сопровождение?

[prog] Два абзаца из zguide, которые отлично передают текущие ощущения от ZeroMQ

Очередное прекрасное в ØMQ - The Guide:

The basic request-reply pattern (a REQ client socket doing a blocking send/receive to a REP server socket) scores low on handling the most common types of failure. If the server crashes while processing the request, the client just hangs forever. If the network loses the request or the reply, the client hangs forever.

Request-reply is still much better than TCP, thanks to ZeroMQ's ability to reconnect peers silently, to load balance messages, and so on. But it's still not good enough for real work. The only case where you can really trust the basic request-reply pattern is between two threads in the same process where there's no network or separate server process to die.

Т.е. один из основных шаблонов взаимодействия в ZeroMQ, REQ-REP, на самом деле кривой и не подходит для использования в реальной работе.

И вот так по ходу чтения всего zguide получается: читаешь-читаешь, в голове закрадывается мысль -- "Да это же шляпа какая-то!" А чуть ниже это чуть ли не открытым текстом пишут. Мол, это не работает в таких-то и таких-то ситуациях, нужно использовать более сложные шаблоны... Но после знакомства с этими более сложным шаблоном привлекательность ZeroMQ начинает блекнуть. Тем более, что по ходу дальнейшего чтения опять начинает закрадываться мысль -- "Да это же шляпа какая-то!" :)