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

О блоге

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

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

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

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

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

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

вторник, 7 ноября 2017 г.

[prog.actors] Хотите решить задачу с помощью акторов? Спросите меня как! :)

После того, как мне довелось разным людям в разных местах рассказывать про Модель Акторов вообще и про SObjectizer в частности, сложилось впечатление, что продвижению Модели Акторов в массы препятствует две вещи:

  1. Отсутствие понимания того, что такое Модель Акторов вообще. Это, на самом-то деле, совсем не проблема. Очевидно, что всего на свете знать нельзя, а объяснить основные принципы работы Модели Акторов можно буквально на пальцах (что, кстати говоря, подтверждается практикой).
  2. Отсутствие понимания того, как эту самую Модель Акторов, принципы которой можно объяснить на пальцах, применить для решения практических задач.

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

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

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

Зачем это нужно мне? Очевидно, что мои цели исключительно корыстные ;) Прежде всего мне нужен материал, на основе которого можно было бы убедительно рассказывать людям о том, где применение Модели Акторов уместно, а где нет. Кстати говоря, неуместность применения Модели Акторов -- это актуальный вопрос. Бывает, что люди слушая про Модель Акторов теряют представление о том, что данная модель применима далеко не всегда. И хорошо бы уметь вовремя различать, где имеет смысл брать акторов, а где этого делать не нужно. Так же мне полезно прикидывать, насколько наш SObjectizer пригоден для решения тех или иных задач. Опыт показывает, что это сильно идет на пользу SObjectizer-у. А т.к. сам SObjectizer распространяется под BSD-лицензией (бездвоздме т.е. даром), то это пойдет на пользу и всем, кто воспользуется SObjectizer-ом.

Зачем это нужно вам? Ну мало ли :) Может вы хотите убедиться, какая все-таки гадость, эта ваша Модель Акторов, а вот вы молодец, когда придумали свое решение без использования акторов ;) Или может вы правда ломаете голову над чем-то и не прочь бы посоветоваться с умным человеком простофилей, который готов тратить свое время бесплатно. Ну или вам просто захотелось пообщаться ;)

В общем, если есть задачка и желание ее обсудить, то милости прошу. Описывайте свои задачки в комментариях к этой заметке (можно в G+), либо по почте eao197 на gmail тчк com, либо со мной можно связаться через FB, LinkedIn или Habrhabr.

PS. Запись специально повисит вверху до сентября. Но, если дело пойдет, можно будет заказать продление ;)

вторник, 17 октября 2017 г.

[prog.wtf] Городские легенды про "гения, из-за которого мы все просрали..."

Прочитал вот это: We fired our top talent. Best decision we ever made. Захотелось высказаться.

Всю мою карьеру меня преследует опасение, что я слишком увлекаюсь велосипедостроением. Действительно, из моих рук в разное время выходили: собственный текстовый редактор, собственная оконная библиотека (две), собственная объектная СУБД (две), собственная система сборки (много, включая одну, для которой был сделан свой язык программирования), собственный векторный графический редактор. Ну и это не говоря про SObjectizer. В общем, повелосипедил я изрядно.

Ну что уж тут поделать, не нравятся мне задачи, где нужно комбинировать готовые компоненты. Есть такой недостаток. Зато у меня получается сделать что-то из ничего. Иногда в буквальном смысле. Иногда чужими руками (это я сейчас про тот же SObjectizer-5 и RESTinio).

Добавим сюда еще и неприятную предрасположенность к рефлексии и самокопанию, и получается, что довольно-таки часто мне приходится самому перед собой отчитываться о том, а не страдаю ли я откровенной херней? И не пора ли принять какое-то сильнодействующее лекарство от NIH syndrome...

Что меня в таких сеансах самокопания всегда спасало, так это то, что практически все велосипеды доводились не просто до работоспособного состояния. Они потом еще и работали. Иногда годами. Иногда серьезно развиваясь и видоизменяясь. Уж не знаю, чего это стоило тем коллегам, которым приходилось мои творения использовать, но факт оставался фактом: велосипеды быстро достигали работоспособного состояния и в таком состоянии старательно поддерживались.

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

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

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

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

PPS. Таки да, это явная и неприкрытая джинса. Проплачена мной :)

воскресенье, 15 октября 2017 г.

[prog.c++] Кратко о прошедшей конференции C++ CoreHard Autumn 2017

Если кратко, то было круто. За что огромное спасибо и организаторам, и коллегам-докладчикам, и посетителям!

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

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

Для конференции мы подготовили приз за самый оригинальный вопрос. Вот такой:

20171002-142120-DSCF8632

Чистой воды хэнд-мейд и самый что ни есть эксклюзив ;) Сделанный настоящим мастером Антоном Хандожко под заказ по индивидуальному эскизу. И, понятное дело, приз нашел своего обладателя:

20171014-183036-DSC_9751

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

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

Ну и напоследок еще раз выскажу благодарность сообществу corehard.by, которое умудряется проводить такие крутые и нужные мероприятия. Ребята вы прям ну очень крутые, спасибо за то, что вы делаете!

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

[prog.c++] Конференция C++ CoreHard Autumn 2017 уже завтра

Завтра, 14-го октября, в Минске пройдет очередная конференция для C++ разработчиков "C++ CoreHard Autumn 2017". Stiffstream там будет представлен сразу тремя выступлениями.

Во-первых, большим докладом "Actors for fun and profit", в котором я буду рассказывать о том, как понять, принесет ли Модель Акторов вашему проекту fun и profit, или же вы поимеете неприятности на свою голову. Кстати говоря, у нас заготовлен специальный памятный, очень аутентичный приз за лучший вопрос докладчику, так что не упустите свой шанс! ;)

Во-вторых, двумя блиц-докладами. Первый блиц-доклад будет посвящен restinio, нашему инструменту для встраивания http/websocket сервера в C++ приложение. Благо очередная версия, 0.3, в которую мы добавли поддержку websocket-ов и некоторые другие вкусности, уже стабилизировалась и мы активно верстаем документацию для того, чтобы сделать публичный релиз уже в начале следующей недели. Второй блиц-доклад будет про MxxRu::externals. Это та простая система управления зависимостями, которой мы успешно пользуемся уже более полутора лет. И которая отличается от conan-ов, hunter-ов, cppan-ов, vcpkg и пр. отсутствием надобности каких-либо централизованных репозиториев пакетов и какого-либо специального оформления этих самых пакетов.

Программа этой конференции выглядит очень вкусно. Есть несколько докладов, которые я сам жду с большим интересом. Среди них доклады Григория Демченко и Максима Хижинского, но не только. Плюс возможность пообщаться с очень интересными и умными людьми в живую. Так что если кто-то еще не решил, идти или не идти, то пора принять единственно правильное решение: идти!

Ну а для тех, кто не сможет физически поприсутствовать в Минске, будет доступна он-лайн трансляция всех докладов. Стримы уже можно найти на странице конференции.

среда, 11 октября 2017 г.

[prog.c++] Давайте говорить dependency manager for C++ вместо package manager for C++?

Why is the committee not in charge of a build system and a package manager?

Почитал эту тему на reddit-е. Показалось, что у некоторых красноглазых линуксоидов личностей, особенно из мира Linux и OSS, какая-то идиосинкразия на термин package manager. Они прям начинают исходить на говно при попытке обсудить package manager для отдельного языка программирования (не важно, будет ли это C++, Rust, Ruby или Haskell). Ибо package manager -- это неотъемлимая часть их теплого и уютненького дистрибутива Linux-а. А все, что вне этого есть ересь и блуд.

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

Ну чтож, мир нужно воспринимать как он есть. Посему, раз существуют подобные "седые горлопаны, мудрые как эпос"(с), то имеет смысл перестать в разговорах про управление зависимостями в C++ употреблять термин package manager. Предлагаю использовать термин dependency manager. И пусть никто не уйдет обиженным: C++ разработчики будут использовать dependency manager для того, чтобы разруливать зависимости для своего кода, а ярые защитники пакетных менеджеров затем будут опакечивать результаты работы C++ разработчиков посредством своих любимых package manager-ов.