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

О блоге

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

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

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

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

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

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

среда, 21 августа 2019 г.

[work.sadness] Поддержку Mercurial удаляют с BitBucket-а. Полностью. Что в этом самое плохое?

Вчера получил письмо счастья от Atlassian, в котором говорится об удалении поддержки Mercurial-а и всех Mercurial-репозиториев с BitBucket-а к 1-му июня 2020-го года:

After much consideration, we've decided to remove Mercurial support from Bitbucket Cloud and the API. Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020.

Полный текст этого печального анонса можно увидеть здесь.

Свое первое возмущение по этому поводу я уже высказал вчера в грубой форме в FB. Но это все лирика. Физика в том, что "just a business". Atlassian владеет BitBucket-ом, вкладывает в его поддержку свои деньги и имеет полное право делать то, что им выгодно, наплевав на мнение 1% своих пользователей. Тем более тех пользователей, которые пользуются этим сервисом бесплатно.

Но если приглушить эмоции, то самое плохое в этом то, что Atlassian тупо удалит все Mercurial репозитории, включая все, что там было, вроде issues, Wiki, артефактов в секции downloads и т.д. Т.е. исчезнет не только код, но и вся сопутствующая база знаний, которая была накоплена вокруг кода.

И вот эта сторона решения Atlassian-а мне непонятна. Хостинг исходных текстов -- это специфическая тема. Люди прибегают к подобным хостерам (будь то GitHub, BitBucket, SourceForge, GitLab или еще что-то) как раз для того, чтобы сделать результаты своих трудов доступным для всех желающих на долгое время. Какой-нибудь древний проект на SourceForge, который уже 15 лет не развивается, все равно доступен и информация оттуда может быть получена даже если автор этого проекта уже давным-давно от проекта отошел (а может автора уже и в живых нет).

Именно в этом ценность открытых хостингов. Я сегодня могу столкнуться с какой-то специфической проблемой, поиск решения которой может привести к старому issue на заброшенном проекте, где проблема и ее возможные решения обсуждаются. Это возможно и такое время от времени происходит, особенно если к тебе на суппорт попадает какое-нибудь древнее легаси. Но возможно это благодаря тому, что хостеры вроде SourceForge или GitHub продолжают хранить проекты, которые давным давно умерли.

В конце-концов, для OpenSource основной смысл хостеров типа SourceForge и GitHub именно в том, что там хранится все, что когда-то там было создано.

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

И вот этого вот решения я понять не могу.

Экономически не выгодно вам пилить поддержку Hg в своей хостинговой платформе? OK. Перестаньте это делать. Переведите все существующие Hg проекты на BitBucket-е в режим read-only. Пусть все, что люди ранее сделали на вашей платформе... Нет, даже не так, а вот так: все, что люди ранее сделали на ВАШЕЙ платформе останется доступным для всех желающих.

Понятно, что даже на саппорт read-only репозиториев придется тратить какие-то деньги. И если это для Atlassian-а настолько серьезные деньги, то можно было бы ограничить время существования read-only репозиториев. Скажем, всего 5 лет. Потом навечно в /dev/null. Но хотя бы в течении этих пяти лет ссылки на репозитории, issues, Wiki, тарболлы и пр., которые в невероятном количестве раскиданы по всему Интернету, будут оставаться валидными.

PS. Ну вот честно не могу даже вообразить себе степень эффективности менеджеров Atlassian-а, принявших решение тупо убить проекты с Hg репозиториями вместо того, чтобы перевести их в read-only mode. Хотя бы лет на пять. Какой-то, блин, контрольный самострел в голову.

понедельник, 19 августа 2019 г.

[prog.flame.c++] Dropbox выставляет свою Djinni на мороз

Кстати говоря, в делах и заботах упустил из виду вот эту публикацию: (Не очень) скрытые издержки общей кодовой базы iOS и Android

Между тем штука значимая.

Я вот несколько лет то тут, то там рассказываю про такую область применения C++, как написание "ядра" кросс-платформенных приложений. Типа того, что бизнес-логика пишется на плюсах, а GUI и какие-то штуки по интеграции с системно-зависимыми сервисами на родных для платформы языках (вроде Java на Android-е, Objective-C/Swift на iOS, C++ или .NET на Windows).

И в качестве примера приводил разработку Djinni от Dropbox-а.

А вот, оказалось, что Dropbox такой подход к кроссплатформенности запарил и они от него отказались.

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

Остальные же причины, в частности, про оверхед пользовательских фреймворков и библиотек, вызывают недоумение. Никто не заставлял Dropbox делать свою собственную библиотеку для работы с Json в С++. Очень похоже на NIH-синдром и его последствия.

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

суббота, 17 августа 2019 г.

[comp.notebooks] Минутка дыбра: продолжение истории про выбор ноутбука

Развитие темы, начатой на прошлой неделе. Я прислушался к мнению уважаемых френдов, которые сказали, что FullHD разрешение -- это уже вчерашний день и нужно что-то принципиально получше. В итоге приобрел 15.6" ноутбук с UHD разрешением (3840x2160): Asus X570UD. Если кому-то интересно почитать о моих текущих впечатлениях, то милости прошу под кат.

пятница, 16 августа 2019 г.

[prog.flame] Ну не могу не утащить великолепную цитату в склерозник. Про RAII в виде создания процессов

Ну прекрасно же! Просто прекрасно. Ни добавить, ни убавить.

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

Взято отсюда. Это человек решил вступить в спор о том, чего не хватает в чистом С, в частности об отсутствии в C классов и RAII.

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

среда, 14 августа 2019 г.

[prog.c++] Быть или не быть tls_inspector-у в RESTinio? И если быть, то каким?

В комментариях к одной из статей про RESTinio на Хабре прозвучала идея сделать объект tls_inspector для проверки TLS-ных подключений. И не только проверки, но и просто извлечения из сертификата клиента различной полезной для сервера информации.

Дошли руки заняться этой темой. Но есть ощущение, что блин получился комом. Если кому-то интересно, то суть я попытался описать здесь: https://github.com/Stiffstream/restinio/issues/44
Там же можно высказать и свое "фи". Хотя его можно высказать и прямо здесь ;)