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

О блоге

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

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

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

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

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

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

вторник, 16 января 2018 г.

[prog.flame] Яркий пример того, за что мне не нравятся упоротые Rust-оманы

Буквально квинтэссенция здесь: "Rust2018: back to the roots" (перевод на русский можно найти на Хабре: "Rust: «Назад к корням»"). Ярчайшая иллюстрация, на мой взгляд, вот эта фраза:

Starting a new systems project in 2019 that uses C or C++ should make everybody raise their eyebrows and not the other way around.

Ну, т.е., желание начать новый проект в области системщины в 2019 на C или на C++ должен вызывать только удивление и недоумение. Никак не иначе.

Что мне здесь не нравится?

Не нравится то, что упоротые Rust-оманы ставят своей целью вытеснить C++ (далее речь пойдет только про C++, поскольку судьба чистого C меня мало волнует).

Предлагаю вдуматься в это. Целью приверженцев нового ЯП является борьба с уже существующим языком. Не создание софта на своем любимом языке, не решение проблем пользователей (или проблем инфраструктуры), не расширение спектра библиотек и инструментов для своего языка. А то, чтобы другим языком никто не пользовался.

Как по мне, так это просто звиздец.

C++ далеко не самый лучший язык программирования. Его использование связано с кучей проблем. Но он здесь. Он давно здесь. На C++ создано столько всего, накоплено столько всего готового, что просто так взять и отказаться от C++ в пользу чего-то другого не получится. Даже в самых влажных мечтах. Поэтому сама цель -- "не должно быть причин начинать новый проект на C++ в 2019" -- она маразматическая. Ну и чего хорошего можно ждать от движения, у которого маразматическая цель?


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

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

Ну и еще любителям Rust-а я предлагаю проделать такой мысленный эксперимент: проходит буквально пару лет, какая-нибудь компания, вроде Facebook-а или Amazon-а делает очередного конкурента C++ и Rust. Например, доводит до ума D с режимом betterC. Или выпускает safe C++, из которого выбросили совместимость с C, добавив безопасную работу с памятью, с мощными концептами, мегашустрой компиляцией и другими плюшками. И этот новый конкурент взял и взлетел. А его приверженцы начали компанию за то, чтобы в 2023-м году ни у кого не было причин начинать новый проект на Rust. Хорошо вы себя будете чувствовать, владея собственной кодовой базой на никому уже не нужном Rust-е?

воскресенье, 14 января 2018 г.

[prog] Пара вещей, которые сильно удивили меня давеча

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


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

Не понимаю я вот чего: какие задачи позволяют разработчику тупо сидеть и педалить код часами напролет, лишь изредка отвлекаясь на изучение документации и митинги?

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

Добавлю еще один важный фактор. Не отвлекаться на почту или какие-то другие входящие воздействия было просто до начала 2000-х, когда Интернета не было даже по dial-up-у. Но уже лет 10, если не больше, практически не бывает того, чтобы ты часа полтора подряд работал в текстовом редакторе и ни на что больше не отвлекался. Даже когда работаешь дома в одиночестве.

Вспоминается всего пара типов задач, с которыми доводилось сталкиваться, и которые позволяют работать в режиме "думать некогда, код педалить нужно". Во-первых, это формошлепство. Когда тебе нужно сделать десяток форм с несколькими десятками контролов на каждой, плюс какая-то первичная валидация данных в этих контролах. Вот тогда думать особо не о чем, нужно просто накидывать контролы на форму и записывать получение/сохранение данных. Во-вторых, это преобразование данных из одного представления в другое. Например, приходит к тебе сообщение X с полями m1, m2, m3 и m4. А тебе нужно отдать сообщение Y, в котором должны быть X.m1 и X.m4. Обе задачи очень похожи и обе, как мне думается, являются частными случаями задач автоматизации документооборота.

Если Crossover специализируется на такого рода задачах, тогда все становится на свои места.


Вторая вещь -- это новость на opennet-е об очередном факапе с npm. Опять выкосили несколько мелких пакетов, которые оказались в зависимостях у кучи других проектов. В частности, удалили пакет require-from-string в исходниках которого буквально пара десятков строк.

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

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

суббота, 13 января 2018 г.

[prog.c++] Тема с упрощением "асинхронных операций" в SObjectizer начинает дышать...

Данный пост продолжает тему, затронутую в двух декабрьских постах "Попытка упростить работу с отложенными сообщениями в SO-5" и "Еще одна попытка упростить работу с отложенными сообщениями в SO-5". В результате длительного и напряженного выкуривания бамбука удалось придумать, как же это все должно выглядеть. И уже начала дышать одна из реализаций. Кому интересно, милости прошу под кат. Для тех же, кто не интересуется SObjectizer-ом и C++ными наворотами, ничего интересного в данном посте не будет. Извините.

среда, 10 января 2018 г.

[prog.c++] Мой доклад приняли на C++Russia 2018

Собственно, вот: "Акторы на C++: стоило ли оно того?" Только акторы в докладе будут присутствовать постольку-поскольку, просто как некий фон, демонстрирующий особенности "предметной области". В основном же речь будет идти о C++. О том, насколько C++ помогал в разработке, где и когда мешал. Как менялся C++ и как это сказывалось. И как сказывалось то, что где-то C++ не менялся. Как изменилось отношение к C++ за прошедшие 15 лет и как это повлияло на нашу работу.

В общем, это будет доклад не про SObjectizer, а про то, что "С++, конечно, та еще субстанция, но конфетку-то сделать можно" ;)

понедельник, 8 января 2018 г.

[prog] Не Boost-ом единым...

Разведка донесла, что в slack-канале Boost-а проскочила ссылка на RESTinio-0.4. В ответ на что Винни Фалько, автор Boost.Beast, запостил ссылку на этот issue с предложением задействовать Boost.Beast в реализации RESTinio. И добавил к этой ссылке фразу: "The old "boost bad" canard."

Хочется сказать, что Винни не прав. В том, что мы не стали делать RESTinio на базе Boost.Beast, нет никакого подтекста из категории "Boost -- говно". Попробую объяснить, почему мы не хотим добавлять Boost.Beast в зависимости к RESTinio. Хотя такая идея нами обсуждалась где-то в мае или июне 2017-го, когда стало известно о сроках проведения review для включения Beast-а в Boost.

Первая причина в том, что С++разработчики, как уж сложилось, делятся на тех, кто использует Boost, и на тех, кто Boost не использует. Нам сейчас не важно, по каким причинам кто-то не использует Boost. Важно, что такой факт имеет место быть. И что разработчиков, которые не используют Boost, не так уж и мало. Пусть даже таких, грубо говоря, всего 10%, но это все равно не 0%. Следовательно, если мы сделаем RESTinio на базе Boost.Beast, то эти разработчики просто не будут рассматривать RESTinio. Для нас эти разработчики, как потенциальные пользователи, будут потеряны. Тогда как если RESTinio не будет иметь Boost в зависимостях, то RESTinio смогут использовать и те, кто применяет Boost, и те, кто держится от Boost-а подальше.

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

Вторая причина в том, что Beast берет на себя слишком много. Закладываясь на Beast мы лишаем себя значительной части контроля над тем, что происходит с вводом-выводом и парсингом HTTP-протокола. Тогда как http-parser из nodejs (как и picohttpparser) в этом смысле гораздо менее требовательные. Это позволяет нам, например, встраивать контроль за тайм-аутами операций. И еще, к примеру, у нас остается возможность дать разработчикам выбор между HTTP-парсерами: сейчас поддерживается только nodejs-овский http-parser, но если будут пожелания от пользователей, то мы можем добавить альтернативы. Тот же picohttpparser. Или даже какой-то кастомный, заточенный под одну конкретную задачу.

Т.е. контролируя почти все, что связано с вводом выводом и обработкой прочитанных/записываемых блоков данных, мы имеем большую гибкость. А так же свободу развернуть RESTinio в нужном нам и нашим пользователям направлении. Тогда как с Boost.Beast мы такой гибкости не видим.

Подчеркну еще раз. Мы уже обсуждали тему перевода RESTinio на базу Beast-а. И коллективно решили, что это не в наших интересах. У разработчика Boost.Beast своя задача. У нас своя.

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

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

Можно ли в RESTinio совместить то, что хотим мы, с тем, что закладывалось в сам Beast? Может быть и можно. Хотя, как нам представляется, не просто. И, если бы мы начинали делать RESTinio сейчас, после релиза Boost-1.66, вопрос реализации RESTinio на базе Beast-а можно было бы рассматривать более внимательно. Но начали мы делать RESTinio сильно раньше. И переходить на Beast сейчас, с учетом всего вышесказанного, вряд ли разумно.


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