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

[work.f*ck] О трудоемкости/стоимости SObjectizer-а на простом примере

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

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

среда, 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++ все-таки больше инфраструктурный язык, писать на нем бизнес-логику, конечно, можно. Но дорого.