О блоге

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

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

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

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

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

[prog.flame] А вот мне интересно, как бы вы отреагировали если бы на собеседовании...

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

У меня есть сильное подозрение, что вы будете плодить код, от которого пришедшие на ваше место будут плеваться. И, вероятно всего, вполне оправдано.

На что соискатель бы вам ответил:

Меньше всего меня колышет судьба человека, которого возьмут кодить вместо меня.

Мне вот интересно, кто бы из читателей блога дал бы согласие взять такого соискателя в свою команду (в свой коллектив)?

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

[prog.c++.idiotic] Вот вы программируете на C++ в 2022-ом и не знаете, что ваши причендалы в опасности

LOR-овские ысперды на линии:

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

[open-source.sad-humour] Идея о том, как заставить платить за поддержку и развитие OpenSource проекта

Навеяно вот этим, и вот этой статьей на Хабре: Что происходит с лицензиями в open source.

Современная ситуация, действительно, несколько странная и, на мой взгляд, не нормальная. Мир все больше и больше зависит от OpenSource, но вот платить за его развитие хотят и могут не только лишь все. Точнее мало кто вообще это делает.

И если для крупного OpenSource, масштаба GCC или KDE, все еще не так печально (как мне кажется), то вот для мелких OpenSource-проектов с условной тысячей звезд на GitHub-е и несколькими десятками внедрений хоть сколько-нибудь радужных перспектив нет от слова совсем.

К чему-то это в конце-концов приведет, но вот к чему и когда? ХЗ.

Однако, по поводу тяпницы, да еще и дня программиста (да-да, сегодня тяпница-тринадцатое, наш неформальный праздник!) позволю себе поделиться одной странной идеей.

Года три назад помогали одному клиенту привести в чувство старую программулину. У которой не было никаких тестов.

Ну т.е. вообще никаких. Ни unit-тестов, ни каких-либо тестовых скриптов, ни каких-либо тестовых/имитационных стендов. Вообще Н-И-Ч-Е-Г-О.

Признаться, я такого с 1990-х не видел.

Внесение изменений в код было похоже на ходьбу по минному полю :)

Тогда-то я очень хорошо понял, что полностью доступные исходники -- это всего лишь полдела. Но когда у тебя вообще нет тестов (даже так: когда тестов нет ВООБЩЕ), то заниматься сопровождением кода становится ну очень грустно. А был бы проект больше и сложнее, то и невозможно.

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

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

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

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

[prog.thoughts] Теряет ли сеньор свою сеньористость если кардинально меняет свой технологический стек

В одном из срачей на LOR-е возникло столкновение мнений: один участник спора высказался в духе, что сеньор при переходе с одного языка программирования на другой окажется уже не сеньором, а миддлом в лучшем случае. Другой же возражал и говорил, что сеньористось, если она настоящая сеньористость, никуда не исчезает.

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

[prog.c++] Еще один связанный с многопоточностью баг

Обычно стараюсь писать многопоточный код на базе SObjectizer-а, но не всегда есть такая возможность, иногда приходится колупаться с голыми нитями, mutex-ами и condition_variable. Давеча, как раз довелось взяться за голые нити и, естественно, допустил глупую ошибку, которую пришлось в течении часа отлавливать.

Итак, есть объект acquisition_manager, который владеет несколькими acquisition_thread. Передача информации между acquisition_manager и acquisition_thread происходит через объекты gate: для каждого acquision_thread создается своей gate, ссылка на который отдается в конструктор acquision_thread.

Периодически acquision_manager наполняет объекты gate параметрами, после чего дает сигнал acquision_thread выполнить нужную работу и поместить в gate результаты, а когда acquisition_thread завершает свою часть работы, то acquisition_manager забирает результаты из все того же объекта gate.

Для взаимодействия между acquisition_manager и acquisition_thread у класса acquisition_thread есть методы: