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

О блоге

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

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

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

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

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

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

суббота, 30 мая 2015 г.

[prog.flame] Забавно, когда в качестве доказательства приводят неважно написанный C-шный код

В обсуждении релиза SObjectizer-5.5.5 на LOR-е в очередной раз всплыла идея о том, что приложение на акторах нужно писать на Erlang-е, а не на C++. И уж если производительности будет недостаточно, то тогда переписать узкие места на C в виде NIF-ов/драйверов:

Я и предложил нивелировать разрыв между C++, в данном случае, и чистым Erlang'ом с помощью NIF'ок, драйверов и пр. Ибо это элементарно проще, а по производительности будет идти ноздря в ноздрю с С++.

Идея не новая. Одна из вещей, которая серьезно портит эту идею, состоит в том, что писать нормальный и корректный код на C не просто. Как по мне, как гораздо сложнее, чем на C++. Ну да суть не столько в том, что C++ удобнее для написания надежного софта, чем C. А в том, какого качества C-шный код будут производить на свет обычные Erlang-еры, которые C видят лишь время от времени?

Собственно, приведенный на LOR-е код является тому подтверждением...

пятница, 29 мая 2015 г.

[prog.c++11] Пример уменьшения многословности в SObjectizer-5

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

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

четверг, 28 мая 2015 г.

[work] Из личного опыта подготовки презентаций...

Хорошую презентацию, содержащую только текст на 30-ти слайдах, невозможно подготовить за два дня. Да и вряд ли можно за три.

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

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

[prog] Erlang-style мониторы и супервизоры -- это хорошо, но не ими одними :)

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

[prog.c++11] SObjectizer-5.5 compared to C++ Actor Framework

There are two points of view from which a comparison could be made:

  1. Top-level view on the purposes of each frameworks and primary targets of framework’s developers.
  2. Low-level view on implemented features and technical details of the implementations.

From the top-level point of view it is obvious that each frameworks have different roots and it seems that authors have different targets.