О блоге

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

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

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

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

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

[work] Открыт для сотрудничества в качестве C++ разработчика

В виде (суб)контракта с нашей компанией СтифСтрим.

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

Самостоятельно погружаюсь в проблему, нахожу решение, кодирую, тестирую, документирую. Если нужно обучаю. Если нужно сопровождаю и поддерживаю. Если нужно выступаю в качестве евангелиста (см. список публикаций на Хабре).

Работаю не быстро, но качественно, беру недорого.

Оценить мой уровень можно, например, про проекту aragata, реализованному мной практически в одиночку. Код можно увидеть на GitHub-е, на Хабре есть две статьи о том, что это и как работает: вводная статья и описание сделанных по результатам нагрузочных испытаний оптимизаций + вот этот пост.

В качестве дополнительных примеров: timertt (+ документация), so5extra (+ документация) -- эти проекты так же написанные мной самостоятельно.

Связаться со мной можно через eao197 на gmail тчк com. Если кому-то интересен профиль на LinkedIn, то вот.

---

Это сообщение повисит какое-то время вверху. Потом будет видно, имеет ли смысл пытаться дальше оставаться в C++.

[life.cinema] Очередной кинообзор (2023/11)

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

Фильмы

Zillion. Клуб твоих грез (Zillion, 2022). Мне зашло. И снято хорошо, и история рассказана отлично, следить за происходящим интересно. Но, как по мне, на главную женскую роль нужно было брать актрису помоложе.

Продавцы боли (Pain Hustlers, 2023). Неплохо.

Создатель (The Creator, 2023). Сказочка для детей. Но снято настолько красочно и убедительно, что все недостатки можно простить. Даже удивительно, что Голливуд смог в такую красивую фантастическую картинку.

Миссия невыполнима: Смертельная расплата. Часть первая (Mission: Impossible - Dead Reckoning Part One, 2023). Как обычно, отлично снятый красочный аттракцион. Но, гораздо, гораздо более скучный и унылый, чем любая из предыдущих частей.

Телохранитель на фрилансе (Freelance, 2023). Милое кино с откровенным стебом на весь жанр приключенческого боевика. Чтобы получить удовольствие ни в коем случае нельзя относится к происходящему на экране всерьез.

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

Чужак (Farang, 2023). В принципе, неплохой боевик с мордобоем. Но слишком уж много в нем драмы и соплей, сократили бы хронометраж минут на 10-15, стало бы еще лучше.

Последний наёмник (In the Land of Saints and Sinners, 2023). Простенькая и неторопливая история с минимумом экшена и откровенно халтурными спецэффектами.

Опасный соблазн (Fatale, 2020). Красиво. Но очень уж затянуто, да и развязка какая-то убогая.

Убийца (The Killer, 2023). Прикольно рассказанная история. Но после просмотра остается стойкое ощущение "вы нам втираете какую-то дичь!", что очень и очень сильно портит впечатление от кино.

Украсть Рафаеля (Criminali si diventa, 2021). Откровенная халтура, в которой половина снимавшихся даже играть толком не пыталась.

Фантом из прошлого (L'uomo sulla strada, 2022). Во-первых, это никакой не триллер, а унылая сопливая драма. Во-вторых, это такая муть, на которую лучше не тратить свое время.

Сериалы

Химера (первый сезон, 2022). Динамично, красочно. Следить за происходящим интересно. Но вот кому-то из героев сопереживать не хочется, такое ощущение, что положительных героев там практически и нет. Ну и местами все происходящее выглядит ну очень уж сказочно.

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

Коммандос (Commandos, первый сезон, 2020). Тот самый случай, когда неплохую, в сущности, историю, которую можно было бы рассказать за четыре серии, растянули на десять(!!!). Чем напрочь убили все то хорошее, что в этом кино могло бы быть.

Прощай, любимая (первый сезон, 2014). У меня лично оставил впечатление откровенной халтуры, так что рекомендую просто пройти мимо.

[prog.c++.flame] Насколько эффективно реализована split_path в C++ REST SDK от Microsoft?

Для многих анонимных экспертов, громогласно и авторитетно заявляющих о том, что C++у не место в современном мире, может быть удивительно, но C++ применяется в Web-е не так уж и редко. Может и не напрямую в Web-е, но вот для отдачи JSON-ов и прочей дряни в RESTful-микросервисной архитектуре C++ используется регулярно. И C++ных фреймворков для этих целей, разной степени продвинутости, можно сходу назвать с полдюжины (а если подумать-повспоминать, то и еще больше).

Не мне анализировать причины этого, т.к. я, так уж получилось, лицо заинтересованное и мне выгодно, чтобы C++ применялся в такого рода проектах еще активнее.

Но, полагаю, одна из причин -- это эффективность.

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

Ну а раз эффективность -- это одна из причин использовать C++, то, полагаю, C++ные фреймворки для поддержки HTTP/REST, должны бы подходить к этому аспекту с тщанием, ведь так?

Ага, я тоже так думал.

Пока не довелось заглянуть в потроха C++ REST SDK от самого Microsoft.

[prog.oop] Что-то я не понял пассаж Барбары Лисков из её статьи от 1987-го года...

Сама статья "Data Abstraction and Hierarchy (OOPSLA ‘87 Addendum to the Proceedings)", раздел "6.2. Multiple Implementations" (стр.16):

It is often useful to have multiple implementations of the same type. For example, for some matrices we use a sparse representation and for others a nonsparse representation. Furthermore, it is sometimes desirable to use objects of the same type but different representations within the same program.

Object-oriented languages appear to allow users to simulate multiple implementations with inheritance. Each implementation would be a subclass of another class that implements the type. This latter class would probably be virtual; for example, there would be a virtual class implementing matrices, and subclasses implementing sparse and nonsparse matrices.

Using inheritance in this way allows us to have several implementations of the same type in use within the same program, but it interferes with type hierarchy. For example, suppose we invent a subtype of matrices called extended-matrices. We would like to implement extended-matrices with a class that inherits from matrices rather than from a particular implementation of matrices, since this would allow us to combine it with either matrix implementation. This is not possible, however. Instead, the extended-matrix class must explicitly state in its program text that it is a subclass of sparse or nonsparse matrices.

The problem arises because inheritance is being used for two different things: to implement a type and to indicate that one type is a subtype of another. These uses should be kept separate. Then we could have what we really want: two types (matrix and extended-matrix), one a subtype of the other, each having several implementations, and the ability to combine the implementations of the subtype with those of the supertype in various ways.

Что в моем вольном переводе на русском языке звучит так:

Часто бывает необходимо иметь несколько реализаций одного типа. Например, для некоторых матриц мы используем разреженное представление, а для других обычное. Более того, иногда бывает нужно использовать в программе объекты одного типа, но с разными реализациями.

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

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

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

Так вот, я не понимаю почему Барбара Лисков сделала утверждение, что в рамках ООЯ мы не можем отнаследовать "расширенную матрицу" просто от класса "матрица" забив на существование подклассов "разреженная матрица" и "обычная матрицы", которые также наследуются от класса "матрица".

Очень смущает, что статья от 1987-го года, и там в списке литературы нет ни одной ссылки на описание таких языков программирования, как Eiffel (1986) и C++ (1985). Есть упоминание разве что SmallTalk, но в SmallTalk, насколько я помню, вообще не было понятия "абстрактный базовый тип" (или "интерфейс" в Java-подобных языках). Тогда как и в Eiffel, и в C++ понятие "абстрактного (базового) типа" как раз есть и в Eiffel/C++ мы запросто можем решить озвученную проблему имея просто абстрактный тип matrix и отнаследованный от него абстрактный тип extened_matrix.

И, как мне кажется, появление в Eiffel/C++ (а потом и в их наследниках) понятия "абстрактный (базовый) тип" как раз и позволило получить то самое разделение, о котором и говорила Барбара: отношение наследования абстрактных базовых типов как раз определяет отношение "тип является подтипом другого", тогда как наследник, реализующий абстрактный базовый тип, предоставляет реализацию. И таких реализаций может быть несколько. И они могут комбинироваться в произвольных вариациях до тех пор, пока мы манипулируем именно базовыми абстрактными типами.

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

[life.work.memories] Вспомнилось про уход из "Интервэйла" и про один из факторов, толкнувших к открытию собственной компании...

На неделе увидел в LinkedIn пост ув.тов.Сергея Шуринова о том, что он находится в поисках новой работы. Сергей в "Интервэйле" прошел схожий с моим путь: от разработчика до директора департамента разработки и внедрения ПО.

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

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

Уходить в аутсорсинговую компанию, вроде ЕПАМ или БелИБА, на роль ресурсного менеджера не хотелось, хотя, наверное, такую возможность можно было реализовать.

Но хотелось оставаться именно в продуктовой разработке. Там своя специфика, своя культура. В том числе и культура разработки.

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

Но переезжать куда-то не хотелось, поэтому и был выбран путь в сторону собственного "маленького свечного заводика". Не, ну правда, велосипедостроитель я или где? Раз нет здесь подходящего места работы, так почему бы не создать его самому? ;)

Кстати говоря, вспомнилась еще одна штука. Если не ошибаюсь, то большая половина всех мои коллег, составлявших костяк гомельского филиала "Интервэйла" в 2001-2004 годах (когда здесь все начиналось с абсолютного нуля), со временем попробовали открыть собственные связанные с разработкой ПО бизнесы. Ну, может быть, за исключением 2-3 человек. Результаты, понятное дело, у всех были разные, но попробовало подавляющее большинство. Включая меня.

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

Как раз то, что нужно, чтобы "перестать работать на дядю, и открыть собственное дело". Но как раз то, что многим мешает полноценно встроится в большую бюрократизированную структуру с отлаженными процессами :)

---

На счет "говноменеджера". Когда-то давно запостил здесь заметку про переход из разработки в менеджмент. Спустя год использованный в ней термин "говноменеджер" акционеры мне припомнили. Шутки юмора они такие -- не всем понятные.