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

О блоге

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

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

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

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

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

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

пятница, 24 мая 2019 г.

[prog.work] Пару слов о релизе SObjectizer-5.6

На этой неделе состоялся релиз мажорной версии SObjectizer-5.6.0. Об этом я уже много где писал, в том числе и в статье на Хабре. Так что вновь проговаривать одно и то же не буду.

Скажу лишь, что работа над 5.6.0 заняла намного больше времени, чем планировалось изначально. Тут сказалась и недооценка объема задач. И необходимость отвлечения на решение вопросов с другими продуктами нашей небольшой компании. "Забота о качестве" -- это простые слова. Но дорогие. Поверьте, мы заботимся о качестве того, что делаем.

Анонс релиза опять доставил массу "радостных" впечатлений от "почитателей" в Рунете. Вроде бы уже не первый год все это происходит, но все равно привыкнуть не получается.

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

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

Пара слов о том, что можно ожидать от нас дальше.

Видимо, в разработке SObjectizer-а наступит небольшая пауза. Есть вещи, которые не успели войти в релиз 5.6.0 и мы к ним обязательно вернемся. Но сейчас наблюдается большая волна интереса к другой нашей разработке, RESTinio. И там образовалась некоторая нехватка рабочих рук. Так что на некоторое время мы сосредоточимся на RESTinio. А потом вернемся к SObjectizer-у.

По ходу дела постараюсь написать несколько статей для Хабра с рассказом о том, что можно сделать с помощью SObjectizer-а. В частности, давно чешутся руки написать о примере make_pipeline (о том, как сделать вот такое декларативное определение конвейера обработки данных). И о том, как SObjectizer можно было бы подружить с каким-нибудь GUI-фреймворком. Надеюсь, что в ближайший месяц-полтора "из под пера" что-нибудь да выйдет.

Тем не менее, если у кого-то возникнут вопросы к SObjectizer-у или пожелания/предложения, то сразу же давайте нам знать. Исправлять проблемы постараемся максимально оперативно. Ко всем конструктивным идеям и предложениям обязательно прислушаемся.

Ну а в общем, что еще сказать? Что смогли, то сделали. SObjectizer-5.6.0 уже здесь. Пользуйтесь на здоровье!

суббота, 18 мая 2019 г.

[prog.c++] Еще один любопытный баг на стыке многопоточности и ООП

Появился повод рассказать об еще одной гримасе многопоточности: на днях был найден и исправлен любопытный баг, в котором вроде бы корректная работа с многопоточностью наложилась на особенности реализации ООП.

Итак, обнаружилось, что один из тестов время от времени падает с диагностикой "pure virtual method called". Разбирательство показало, что проблема проявляется в коде, который похож вот на этот (лишние детали убраны, дабы не можно было рассказывать только о сути проблемы):

class data_owner_t {
public:
   virtual void update() = 0;
   ...
};

class data_repository_t {
   std::mutex lock_;
   some_container_t<data_owner_t *> owners_;
   ...
public:
   void add(data_owner_t & owner) {
      std::lock_guard lock{lock_};
      owners_.insert(&owner);
   }

   void remove(data_owner_t & owner) {
      std::lock_guard lock{lock_};
      owners_.erase(&owner);
   }

   void update_all() {
      std::lock_guard lock{lock_};
      for(auto * p : owners_)
         p->update();
   }
   ...
};

Виртуальный метод здесь всего один -- это data_owner_t::update. Вызывается он только внутри data_repository_t::update_all, в цикле, перебирающем всех зарегистрированных owner-ов. Значит в какой-то момент времени внутри data_repository_t оказывается невалидный указатель на owner-а. Но как и почему?

среда, 15 мая 2019 г.

[work.thoughts] Теплое чувство внутри, большое видится на расстоянии и периодическое удивление...

...тому, что наши разработки кто-то берет и использует.

Работаю сейчас над сопроводительными материалами к очередному релизу SObjectizer-а. Для чего перечитываю статью Павла Вайнермана "Если проект «Театр», используй акторов…", в которой речь идет об опыте применения SObjectizer-а для управления сценическим оборудованием в театре. И вот на чтении вот этого фрагмента меня вдруг "пробивает":

Был разработан «проигрыватель сценариев» который создаёт группу специальных акторов и запускает их в работу. Мы разработали два вида акторов: акторы-исполнители, предназначенные для выполнения задания для конкретного штанкета и актор-координатор, который распределяет задания между исполнителями. Причём акторы-исполнители создаются по мере необходимости, если в момент очередной команды не находится свободного. За создание и поддержание пула акторов-исполнителей отвечает актор-координатор. В итоге управление выглядит примерно следующим образом:

  • оператор загружает сценарий;
  • «перелистывает» его до нужной повестки (обычно просто идёт подряд);
  • в нужный момент нажимает кнопку «приготовиться» по которой актору-координатору присылаются команда (сообщение) по каждому штанкету входящему в текущую повестку с параметрами движения;
  • актор-координатор смотрит свой пул свободных акторов-исполнителей, берёт свободного (если нет создаёт нового) и передаёт ему задание (номер штанкеты и параметры движения);
  • каждый актор-исполнитель получив задание начинает отрабатывать команду «приготовиться». Т.е. подключает двигатель и переходит в режим ожидания команды «поехали»;
  • когда настаёт время, оператор подаёт команду «поехали»;
  • команда «поехали» приходит координатору. Он рассылает её всем своим задействованным в текущий момент исполнителями и они начинают «исполнение».

Тут стоит отметить, что в повестке встречаются дополнительные параметры. Например начать движение с задержкой N секунд или начинать движение только после отдельной специальной команды оператора. Поэтому список состояний у каждого актора-исполнителя достаточно большой: «готов к выполнению очередной команды», «готов к движению», «задержка движения», «ожидание команды оператора», «движение», «исполнение завершено», «сбой в работе».

Почему-то именно при перечитывании этого фрагмента до меня внезапно (с) дошло, что вообще-то говоря, выбор SObjectizer-а для реализации этого всего был вовсе не обязательным. И это мягко говоря.

В принципе мы, разработчики, с пиететом относимся к инструментам от больших компаний. И это нормально. Если небезосновательное мнение, что в больших софтверных компаниях, вроде Google, Facebook, Amazon, Microsoft, Яндекс, Лаборатория Касперского и т.д., оказываются очень квалифицированные разработчики. Которым, при этом, создают отличные условия для концентрации именно на разработке софта.

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

Поэтому нет ничего удивительного, когда разработчики берут proxygen от Facebook или Abseil от Google. Просто потому, что это инструменты от Facebook-а и Google. Само их применение в проектах компаний таких масштабов уже служит неким знаком качества.

А вот когда для выполнения непростого и ответственного проекта выбирается кустарная разработка от никому неизвестной провинциальной конторы, грубо говоря, каких-то "Рогов и копыт", то вот это доставляет. И вызывает теплое чувство внутри.

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

При этом, хоть описанный в статье проект далек от сложности и критичности от, скажем, системы управления Boeing 737 Max, но это вовсе не "Hello, World". Мягко говоря. И не вебня уровня какого-нибудь Интернет-форума, в котором недоступность или ограниченная функциональность в течении десятков минут не страшна от слова совсем. Вполне себе реальное оборудование и стоимость отказа в неподходящий момент высокая. И разработчики сочли возможным использовать наш продукт, посчитав его достаточно качественным, зрелым и обеспеченным должной поддержкой.

А ведь запросто могли и не счесть. Но сочли. И вот когда осознание этого факта догоняет (а догоняет-то не сразу), то что-то в голове щелкает. До дрожи в коленках ;) Не зря, получается, мы все это делали. Не зря.

Ну и отдельно хочется сказать спасибо всем innovator-ам и early adopter-ам, которые рискуют выбирать наши продукты на свой страх и риск. То, что вы делаете доказывает, что есть таки смысл в том, что делаем мы.

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

[prog.c++] Обновили RESTinio до версии 0.4.9

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

Пару слов о текущем статусе разработки RESTinio.

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

Поэтому если перед кем-то стоит выбор брать RESTinio в работу или не брать, то ответ, на наш взгляд, очевиден: конечно же брать. Без поддержки мы вас не оставим :)

Попутно просьба поделиться своими впечатлениям тех, кто смотрел на RESTinio и не выбрал его. Почему? Чего не хватило? Что отпугнуло?

Эта информация сильно поможет нам сделать RESTinio еще лучше и практичнее.

Так же не могу не дать ссылку на свежую статью на Хабре о том, как можно использовать архитектурные особенности RESTinio для длительной обработки запросов: "RESTinio — это асинхронный HTTP-сервер. Асинхронный".

суббота, 4 мая 2019 г.

[work.flame] Увидел прекрасный список требований к соискателям. Не могу не прокомментировать

Вот этот пост в FB. Для тех, кому лень ходить в FB (или кого там нет, а такие счастливые люди, надеюсь, еще есть), процитирую его здесь полностью:

Чем дальше, тем больше в потенциальных сотрудниках ценим не опыт, а софт-скилы.
Опыт редко помогает, а вот отсутствие определенных качеств - почти гарантия, что коллектив их отторгнет или сами испугаются.
Вспомнила навскидку 8 таких.
И нет, я не считаю, что это качества топ-менеджмента. Мне кажется, что это качества любого человека, который либо стал, либо имеет потенциал стать профессионалом.

1. Способность разбираться (вот надо проанализировать кучу логов - человек найдет чем, даже если этого никогда не делал, разучит grep или научится виртуозно владеть Notepad++)
2. Отсутствие "нас этому не учили" позиции. И умение учиться. В современном мире, особенно когда ты делаешь что-то новое, никого никогда ничему не учили. Надо самому быть готовым учиться. И это нормально, когда рекламщик для своей работы изучает pandas, а программист - UX построения отчетов.
3. Личный тайм-менеджмент. Умение управлять своим временем, ресурсами, результатами. Чтобы без этих "ой, я увлекся" или "ой, я неправильно расставил приоритеты".
4. Грамотная и структурированная письменная речь. Это прямо must, мы живем в мире текстовых коммуникаций. Неспособность внятно выражать свои мысли в письменной форме - бич современного общества.
5. Понимание слова "результат". Это когда вы не считаете результатом "я кодил" или "я делал" или "я занимался". Когда вы считаете своим результатом - конечный результат, а не "свою маленькую делянку".
6. Амбиции. Я не понимаю и не люблю людей, которым все равно, чем они занимаются, лишь бы платили. Имхо это какой-то начальный уровень развития. Не понимаю и не люблю людей, которых не интересуют достижения команды, в которой они работают. У нас ежемесячное подведение итогов по компании - самое популярное мероприятие у сотрудников.
7. Здравый смысл. Не знаю как измерять. Но это общее понимание того, нафига ты что-то делаешь. Это частота задавания себе вопросов "а зачем?", "а как добиться того же самого, но попроще". Это когда ты не оправдываешь идиотизм ситуации или баги тем, что "так исторически сложилось" или "так было написано в ТЗ".
8. Способность "отвечать за базар". Грубая фраза, но очень важная. Это когда ты можешь человеку доверять. Потому что если он сказал "я разберусь", то ты уверен, что он не забудет и либо разберется, либо придет и скажет "ну слушай, там вот такая история, нужна помощь". И если он сказал "будет к вечеру", то к вечеру у тебя либо будет результат, либо до вечера ты узнаешь, что его не будет. Но уж точно тебе не придется писать на следующий день "ну что там?".
UPD 9. Отсутствие стеснения задавать вопросы. Когда у человека чувство собственного достоинства связано с тем, как он выглядит в глазах других, а не с реальными результатами - они стесняются задавать вопросы.

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

Ну и еще не могу не удержаться и не упомянуть, что у автора этого списка предшествующая запись в FB имеет вот такое содержание:

ОЧЕНЬ ищем iOS разработчика и QA инженера. Прям измучились в поиске людей с инженерной жилкой.

С инженерной жилкой. Надеюсь, далее у меня получится показать, почему это самое "с инженерной жилкой" не очень хорошо уживается с пунктами из вышеперечисленного перечня.