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

О блоге

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

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

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

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

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

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

среда, 22 ноября 2017 г.

[prog.c++] Шаблоны против копипасты 7: вывод нужных типов из указателей на методы

В коде решения для Highload Cup-а Коли Гродзицкого обнаружился интересный способ использования C++ных шаблонов для того, чтобы избавится от копипасты. Насколько я понимаю, суть проблемы была в следующем:

Есть класс database_t, который нужно наполнить экземплярами структур user_t, location_t и visit_t. Структуры же эти вычитываются из JSON-файлов. Т.е. есть файлик вроде users_1.json, из которого нужно прочитать все JSON-объекты, преобразовать их в экземпляры user_t и запихнуть все эти экземпляры в database_t. Тоже самое нужно сделать с visits_1.json (структуры visit_t) и locations_1.json (структуры location_t).

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

[prog.c++] Что и как следует улучшить в CMake-овских скриптах для SObjectizer?

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

Что вам мешало в существующих CMake-скриптах для SO-5?

Чего вам не хватает в существующих CMake-скриптах для SO-5?

Что вам хотелось бы видеть в CMake-скриптах для SO-5?

К счастью, сами-то мы не настоящие сварщики пользуемся CMake, поэтому нам самим сложно судить о том, насколько удобны или неудобны существующие скрипты. Соответственно, нужна помощь тех, кто попробовал воспользоваться CMake для SO-5 и столкнулся с какими-либо сложностями/проблемами/недостатками.

понедельник, 20 ноября 2017 г.

[prog.thoughts] В догонку к докладу на GECon-2017

В презентации к докладу на GECon-2017 почти 90 слайдов. При этом довелось выбросить еще с десяток слайдов, которые могли бы сделать изложение более интересным и плавным, что ли. Все-таки временные рамки в 40 минут на доклад дали о себе знать.

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

В общем, если кто-то заинтересуется такой лекцией, то дайте знать. Я сам пока не очень понимаю, зачем это лично мне (наверное, просто потому, что могу). Но, если будут интересные идеи, то почему бы и не сотворить что-нибудь? В конце-концов, не думаю, что у нас в РБ так уж много действующих C++ разработчиков, использующих C++ на протяжении 25 лет.

[prog] Краткие впечатления от участия в GECon-2017

18-го ноября 2017-го в Гомеле EPAM провел очередную большую и бесплатную ИТ-конференцию GECon-2017. Для нашего небольшого города событие, прямо скажем, далеко не рядовое. Мне довелось поучаствовать в конференции в качестве докладчика (насколько я понял, в качестве единственного не-EPAM-овского докладчика).

20171120-112042-DSCF8919

В целом мне очень понравилось. В этом году мне довелось поучаствовать в нескольких конференциях, могу сказать, что подготовка к GECon-у была одной из самых серьезных. Может быть даже жестче и строже, чем подготовка к C++Russia. Так что в качестве результата сомневаться не приходилось изначально. На фоне этого мне даже удивительно, что на конференцию заявилось всего 300 человек, а не в 2-3 раза больше. Высокий уровень подготовки, докладчики, имеющие опыт работы на очень серьезных проектах, бесплатность и место проведения прям в центре Гомеля... Как по мне, так глупо упускать шанс принять участие в таком мероприятии.

Огромный пласт положительных эмоций связан с тем, что на конференции довелось встретить много своих бывших коллег. Даже не ожидал, насколько их много. И насколько приятно пообщаться с людьми, с которыми был съеден не один пуд соли. Собственно, и свой доклад я читал практически "для своих": было ощущение, что процентов 70% слушателей доклада составляли те, кто либо работал со мной, либо просто знает меня.

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

Слайды доклада лежат здесь. Ссылку на видео добавлю когда организаторы конференции зальют видео выступлений на какой-нибудь публичный ресурс.

Однако, мне показалось, что есть несколько моментов, которые могли бы сделать конференцию еще круче, интереснее и полезнее.

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

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

Во-вторых, мне показалось, что регламент докладов, пауз и перерывов на обед был неудачным. Тайм-слот для докладов на 1 час -- это правильно. 40 минут на сам доклад, затем 20 минут на вопросы -- это очень удобно. По-моему и для докладчика, и для слушателей. Но вот потом нужно делать совсем небольшой перерыв, скажем, минут 10, не больше. Чтобы можно было обменяться контактами с тем, кто тебя заинтересовал. И занять место на следующем докладе. Со всего одним перерывом на обед (кофе-брейк). Причем сделать длинный кофе-брейк надо было так, чтобы людям никуда не нужно было уходить. Чтобы все общение проходило на относительно небольшом пятачке.

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


В завершении же хочу поблагодарить компанию ЕПАМ и ее сотрудников, причастных к проведению GECon-а: большое спасибо за вашу работу. Для нашего города и нашего ИТ-сообщества GECon-2017 стал, пожалуй, самым ярким и масштабным событием года.

пятница, 17 ноября 2017 г.

[prog.c++.thoughts] Какой вклад в сложность C++ вносит борьба с самой сложностью C++?

Давеча один из интересующихся SObjectizer-ом пользователей задал вопрос: а можно ли использовать в SO-5 в качестве обработчиков сообщений const-методы? Вопрос оказался, что называется, внезапным. Мы используем SO-5 в разработке софта уже лет семь (как раз где-то в конце 2010 первые стабильные версии SO-5 пошли в дело, если мне не изменяет склероз). Но ни разу нам не пришлось столкнуться с тем, чтобы обработчик сообщения следовало бы пометить модификатором const. Видимо, это потому, что обработчики сообщений в подавляющем большинстве случаев меняют состояние агента, поэтому не было смысла использовать const-методы в качестве обработчиков. А тут новый человек, другие задачи, другой взгляд на решение этих задач. И const-методы оказались нужны.

Ну, OK. Какие проблемы, будем делать.

Только вот как это сделать так, чтобы трудоемкость и сопровождаемость получившегося решения не зашкалила? Речь идет о том, чтобы преобразовать 6-7 методов вот такого формата:

templateclass RESULT, class ARG, class AGENT >
subscription_bind_t &
event(
   RESULT (AGENT::*pfn)( ARG ),
   thread_safety_t thread_safety = not_thread_safe );

которые живут в SO-5 давно, и используются повсеместно.

Нужно было получить методы, которые бы могли принять как RESULT(AGENT::*pfn)(ARG), так и RESULT(AGENT::*pfn)(ARG) const.

Простейший вариант, который приходит в голову -- это тупое дублирование: