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

О блоге

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

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

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

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

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

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

понедельник, 12 ноября 2018 г.

[prog.thoughts] Под впечатлением от свежей статьи про Rust на Хабре

Просмотрел только что свежую статью на Хабре про Rust: Приемы обобщенного в Rust: как мы переводили Exonum с Iron на actix-web.

Похоже, я могу понять, почему к Rust-у такое внимание. И от кого это внимание исходит. Если всю жизнь программировал на Python, Ruby, JavaScript или даже Go, то в один прекрасный момент динамическая типизация и невысокая скорость исполнения может основательно подзадолбать.

Захочется чего-нибудь нативного, очень шустрого, мощного и выразительного. Но что выбрать? Старый и замшелый C++, про который столько страшилок рассказывают, и в котором экосистема застряла в 1990-х? Вряд ли.

Может быть Ada? Или какой-нибудь Eiffel? Сильно вряд ли. Про них мало кто знает. Eiffel вообще платный (но есть GPL-ная версия) и где он сейчас непонятно. Ada вроде как жива и развивается, но модным и молодежным этот язык точно назвать нельзя. Да и у сегодняшней молодежи попытка изучить Ada может вызвать стойкий рвотный рефлекс, особенно если всю жизнь программировал на чем-то вроде JavaScript-а.

Можно еще и D. Но его популярность и распространенность колеблется где-то возле статпогрешности.

Вот и остается Rust. Который был построен на базе всех популярных страшилок и хайпов 2000-х годов. ФП во все поля, ООП сосет, безопасное многопоточное программирование (на самом деле нет), отсутствие и GC и утечек памяти, иммутабельность by default, ...

Так что почему на Rust переходят люди с Python/Ruby/JS и даже с C# или Java, мне вполне понятно.

Только вот глядя на более-менее практичные примеры кода на Rust я не понимаю двух вещей:

Во-первых, какой смысл сейчас разрабатывать прикладное ПО на Rust-е или C++? Ну т.е. такое, которое решает проблемы конечных пользователей. Зачем писать на Rust или C++ очередной HTTP-сервер, MQ-брокер, СУБД или компилятор я могу понять. Не понятно, зачем на Rust-е делать что-то прикладное, типа взяли данные отсюда, проверили, преобразовали, сохранили в БД, отдали вот сюда.

Ну вот, действительно, какой смысл? Порог входа в язык высокий. Код, который будет разрабатываться, особой читабельностью отличаться не будет. Посадить на проект какого-то "индуса" заместо выбывшего "индуса" не получится. Поскольку язык безопасный, с кучей проверок к run-time, по производительности он будет побыстрее, наверное, Java и .NET-а, но не на порядки. Да и вряд ли в разы быстрее, скорее на десяток-другой процентов, да и то вопрос. Экосистема еще только формируется и наполняется библиотеками...

Во-вторых, зачем C++ника пересаживаться на Rust? Не, я понимаю, что ФП во все поля, ванильные трайты вместо утиных шаблонов, синтаксические макросы, компилятор бьет по рукам, cargo и все дела... Но блин, в Rust-овом коде будет все тоже самое, что и в C++ном: лес из абстракций и обобщенных конструкций, построенных каким-то сумрачным гением. Так что в красивой обертке матерый C++ник обнаружит все тот же говнокод, наполненный трехэтажными шаблонами, с которым ему и так приходится иметь дело постоянно. И еще непонятно, какой из них ближе к криптограммам ;)


В общем, в очередной раз можно пожалеть, что D не взлетел. Сперва он появился слишком рано, когда еще не было надобности в шустром, но безопасном нативном языке с GC. Всех вполне устраивали Java с JVM и C# с .NET. Плюс к тому, затеяли переход от D1 к D2 и профукали момент, когда выстрелил Go в контейнерах, где нужна и скорость и отсутствие тяжелых ран-таймов.

Да и сейчас авторы D, как мне кажется, продолжают думать, что основные конкуренты для них -- это C и C++ (ну, может быть еще и Rust). Тогда как на мой взгляд, основные конкуренты для D -- это Go и грядущие Kotlin/Native, Scala/Native, Crystal, Nim и т.д. И вот эта неправильная оценка ситуации приведет к очередному профуканому шансу. Вместо betterC нужно в D другими вещами заниматься, имхо.

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

пятница, 9 ноября 2018 г.

[prog.thoughts] Впечатление после нескольких докладов с HighLoad++ 2018

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

Но вот действительно, такое ощущение, что есть "строительные блоки" (nginx, kafka, redis, clickhouse, docker, kubernetes и т.д.) и есть "здания", которые строятся из этих "строительных блоков". При этом и производство "строительных блоков", и построение "зданий" на их основе называется разработкой. Хотя, как по мне, разработка nginx-а и разработка решения на базе nginx-а -- это разные вещи.

Причем, что особенно доставляет, в разработке конечных решений на базе "строительных блоков" деньги были, есть и будут. Тогда как из разработки "строительных блоков" деньги уходят. Ибо, как сказал один из докладчиков: "Мы не хотим башлять вендорам, поэтому мы любим OpenSource" (за точность цитаты не ручаюсь, но смысл передан точно (c)).


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

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

среда, 7 ноября 2018 г.

[prog.c++] SObjectizer-5.5.23 и so_5_extra-1.2.0

Мы все-таки добрались до релиза SObjectizer-5.5.23 и so_5_extra-1.2.0. Ничего нового по сравнению с тем, что описывалось ранее, в SObjectizer/so_5_extra не попало. Разве что специально удостоверились в том, что SObjectizer может собираться под Android посредством свежих Android NDK (проверялось на r18b).

Официальный анонс можно найти на странице проекта.

Свежую версию SObjectizer-а можно взять либо из секции Files, либо с GitHub-зеркала.

Свежую версию so_5_extra можно взять из секции Files (внутри архивов с именами so_5_extra-1.2.0-full уже находятся все внешние зависимости, включая SO-5, Asio и т.д.).

Пользуясь случаем хочу сказать большое спасибо всем, кто не только помог нам с этим релизом. И вообще всем, кто проявлял интерес к SObjectizer-у на протяжении всех этих лет. Ваше внимание и ваша помощь очень и очень сильно нам помогала. Большое спасибо еще раз.

Уже многократно говорил, но повторю еще раз: SO-5.5 развивается уже более четырех лет. Это большой срок, за это время SObjectizer обзавелся многими вещами, о некоторых из которых мы даже и подумать не могли в свое время. С некоторой ретроспективой интересующиеся могут ознакомиться в свежей статье на Хабре: "Четыре года развития SObjectizer-5.5. Как SObjectizer изменился за это время?"

Видимо, эволюция SO-5.5 подходит к своему логическому завершению. На ближайшее время у нас в планах:

  • подружить so_5_extra с CMake. Хотелось сделать это в рамках 1.2.0, но CMake в очередной раз порадовал своей простотой и понятностью. Пришлось отложить;
  • подружить so_5_extra с Boost.Asio. Сейчас so_5_extra работает только со standalone версией Asio, надо бы поддержать еще и Boost.Asio, как мы это сделали в RESTinio в свое время;
  • добавить в so_5_extra возможности для тестирования агентов. Что-то вроде инструментария для упрощения написания unit-тестов для агентов (с использованием агентов).

По поводу последнего пункта пока много непонятностей. Вероятно, для поддержки тестирования агентов потребуется сделать еще и SO-5.5.24. Будем посмотреть. Но вообще мы уже смотрим в сторону SObjectizer-5.6, где мы выбросим накопившийся в SO-5.5 старый хлам и перейдем на C++14.

В общем, работы полно. Если у кого-то есть хотелки/пожелания -- высказывайте, будем рассматривать их самым внимательным образом и, по возможности, воплощать в жизнь.

Ну а если кто-то найдет возможным поделиться в Интернетах своим опытом работы с SObjectizer-ом, то это будет просто неоценимое подспорье для нас. Нам очень не хватает публично доступных success stories. А предоставить их можете только вы. Так что если кто-то может или хочет сказать в наш адрес пару добрых слов, то самое время сделать это ;) Подробности можно обсудить по почте (eao197 на gmail точка com).

В общем, еще раз спасибо. Пробуйте SObjectizer, делитесь своими впечатлениями, высказывайте нам свои замечания. Вместе мы сделаем SObjectizer лучше. Достаточно просто посмотреть на то, что уже было сделано.

воскресенье, 4 ноября 2018 г.

[prog.c++] Кратко про C++ CoreHard Autumn 2018 (+слайды моего доклада)

Вчера с краткосрочным визитом посетил наш славный Минск. Целью визита стало посещение очередной конференции по языку C++: CoreHard Autumn 2018. В том числе и в качестве докладчика.

Конференцией был впечатлен. Порядка 300 участников, от вида полностью заполненного зала на вступительном докладе захватывало дух. Организаторы большие молодцы, за проведение столь масштабного мероприятия им огромное спасибо! Если события продолжат развиваться такими темпами, то через пару лет C++ CoreHard может сравняться с C++Russia по масштабам и значимости.

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

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

А вот она же на SlideShare.


Так получилось, что в 2017 я прочел четыре разных доклада, и в этом, 2018-ом году, так же состоялось четыре разных доклада. Чувствую, что это перебор. С подготовкой доклада к этому CoreHard-у уже возникли сложности. Посему нужно будет подумать, стоит ли в следующем году заявляться на конференции так часто... Тем не менее, если кому-то интересно послушать о том, что мы делаем и для чего мы делаем, то я бы с удовольствием выступил бы перед заинтересованной аудиторией (с расширенной версией доклада, который я делал на митапе в Питере).

пятница, 2 ноября 2018 г.

[prog.memories] Беглый взгляд на эволюцию SObjectizer-5.5 за прошедшие четыре года

Первый релиз SObjectizer-а в рамках ветки 5.5 состоялся чуть больше 4-х лет назад, в начале октября 2014-го. На следующей неделе планируется релиз версии 5.5.23, которая может стать финальной в рамках ветки 5.5.

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

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

Не стоит. Берите лучше то, что есть. Не нравится вам SObjectizer -- возьмите что-нибудь другое. Тот же CAF или QP/C++. Выбор есть. Полагаю, этот выбор будет всяко лучше повторения хотя бы части пути, который мы уже прошли. И, прошу не забывать, что речь идет не только о том, чтобы придумать и запрограммировать. Но и о том, чтобы отладить, задокументировать и донести ваше творение до других людей. Которые, возможно, думают, что лучше они сами что-нибудь на коленке слепят.

Итак, вот список с ссылками на соответствующие разделы документации. Список не полный, включал в него только самые знаковые изменения/нововведения. Этот список еще предстоит переосмыслить, отранжировать и преобразовать в статью. Но, надеюсь, общее впечатление можно составить.

Да, и в этом списке нет того, что вошло в состав so_5_extra.