Это самый красивый интерфейс калькулятора для сложения 4 положительных и 6 отрицательных чисел, что мне встречался. И даже с функцией изменения количества слагаемых.
Если только для себя и своих - Matrix, свой сервер можно не ставить, если доверяешь публичному. Выбрать можно любой сервер, где политика поведения устраивает. Клиентов полно, вменяемо функционирует. HTTP(S), а значит, никаких болей с портами.
Другая альтернатива - Jabber, он потерял популярность, но все ещё шевелится. С клиентами и функционалом посложнее, сетевые порты и мобильные клиенты - боль.
Tox - это прямо на случай, когда отрезаны все средства. Аудио\Видео звонки есть, но лагают. Чат норм, мобильный клиент норм. Боль для обычной жизни(но необходимость для теневой) - нет вменяемого публичного идентификатора, потому без внешнего способа связи для передачи ID связаться с собеседником нереально.
Большая часть остальных доступных мессенджеров - проприетарный WebRTC на сервер мессенджера, не отличающиеся друг от друга и непонятно как монетизирующиеся.
А еще на верном пути к #include <algorithm>, и обезжиренному RAII, и функциональным типам.
Поразительно, как с развитием Go, давно известные и в других местах обкатанные концепции изобретаются заново с использованием урезанного базового функционала.
А вот потрудились бы написать статью, как все-таки покупать б\у видеокарты, как проверять, как торговаться, то вызвали бы больше доверия к себе, как продавцам нового оборудования.
Спасибо за обстоятельный отчет. Притарил статью в карман.
А всё программное хозяйство в одну машину запихано или на разных хостах? Как собственно интеграция и начальная конфигурация непосредственно железа происходит? Хост-система настроена вручную штатными средствами или какие Ansible, Chef, Puppet?
Я вот смотрю в сторону построения своей home lab, но приправленной распределенной структурой - 4 ноутбука разной степени паршивости хочу объединить в кластер, с автоматическим развертыванием базового образа OS, поверх него уже накатывать k8s и прочие контейнеры.
Требование - взял любой ноут, ребутнул его в пользовательскую систему - у тебя мобильная станция, попользовался, ребутнул назад в PXE - нода вернулась в кластер, k8s смасштабировался.
Теоретическая подготовка пока привела к Warewulf, DRBL, oneSIS и похожим системам построения вычислительных кластеров. Cockpit и CosyStack в очереди на оценку пригодности.
А какие типовые задачи с LeetCode для Lead или Principal Software Engineer вы предлагаете на собеседовании?
У Leetcode есть минус для подобной подготовки — сервис показывает тест, на котором упало решение. Это приучает к безнаказанности, ведь цена ошибки на собеседовании или в настоящей рабочей задаче выше. Поэтому я советую писать код, который пройдёт проверку с первого, максимум со второго раза.
В Яндексе рабочие задачи должны решаться с первого раза?
Кто в производственном процессе выполняет декомпозицию бизнес-требований до задач уровня LeetCode с описанием входных и выходных данных и лимитов по ресурсам?
Относительно статьи, автор предлагает использовать встроенную в HDR контент информацию о transfer characteristic и peak luminance чтобы скомпенсировать визуальное влияние яркости на цветность. Преимущества каждый определяет для себя, но у меня сомнения, что этот способ применим для другого типа контента. Анимация все-таки не содержит световых перепадов, и тут скорее 10-битный формат HDR поспособствует более плавным цветовым градиентам без лесенок. В сложно-освещенных сценах насыщение цвета в ущерб полутонам сделает картинку чрезмерно искусственной.
HDR - это не про цвет и насыщенность, а про свет и яркость. Точнее, соотношение яркости темного и светлого в одном кадре, и диапазон градаций между ними.
В HDR контенте указывается диапазон яркости и степень градации, в зависимости от формата контента как для все потока в целом, так и для каждого кадра. Оборудование использует эти данные для непосредственного отображения как задумано, или для всяких конверсий на лету. И наибольших визуальный эффект HDR контент на HDR оборудовании (до 1000 нит) будут иметь кадры с очень яркими и очень темными областями одновременно, в таких кадрах яркие области не окажутся выжженными добела, а в тенях - останется достаточно уровней для мелких деталей.
При отображение на LDR(обычно, впрочем, пишут SDR от Standard Dynamic Range, 100-300 нит) контент будет отображаться как бы блеклым из-за некорректного отсечения яркостной компоненты. Штатная конвертация предполагает сжимание динамического диапазона с использованием разных линейных или нелинейных преобразований, что приводит к сглаживанию детализации в тенях и\или выжженным ярким областям.
А какая добавочная ценность у OpenDAL для проектов не в экосистеме Apache?
Отрицая родные SDK и переизобретая реализации конкретных сервисов, OpenDAL сразу становится отстающим по функционалу от родных SDK.
Как максимально общий интерфейс взаимодействия, он же сводится к минимальному общему функционалу, а все особенности и локальные улучшения становятся или неподдерживаемыми, или протекающими абстракциями.
Нет ничего хуже для интегрированного приложения, как использовать единый общий интерфейс, с костылями под каждый сервис на уровне приложения. Вместо N зависимостей от SDK, получаем N+1, и хорошо еще если вообще можно какой-никакой доступ в нижним слоям получить и напрямую в SDK присунуть требуемое.
Проще уж проектное архитектурное решение принять, привнести в проект стандартную зависимость от конкретных официальных SDK, и реализовать диктуемые конкретными требованиями проекта интерфейсы абстракций, учитывая в первую очередь нужды продукта, а не цель общности абстракции.
Применимы ли озвученные рекомендации по атомизации процессов к линейному менеджменту? Они с одной стороны - сотрудники со своими задачами, с другой - менеджеры, ответственные за оптимизацию нижележащих процессов.
Как в многоуровневой структуре происходит анализ и улучшение организации? Сверху вниз на один уровень детализации, или С-уровень обязан разобраться в бизнес-процессах и назначить исполнителей?
Использовать DRY, опираясь на реализацию - приводит к описанным проблемам. Использовать DRY, опираясь на контракт и выделяя абстракции как наиболее стабильные части - находится за пределами бытового понимания.
А 'на офисном ПК под Windows 10 (апрель 2024)' это как? Мои устройства с 4Гб оперативной памяти уже в пролете для современного веба? А Acer Aspire One с 1Гб?
ТОЛЬКО браузер без вкладок вроде легко отжирает 2,5Гб. При открытии сайта - своп и запись сотен мелких кэш файлов убивают остаток ресурсов. Чем таким занято нативное приложение, чтобы, ничего не выполняя, столько памяти использовать. Откуда борьба за миллисекунды бенчмарков, если браузер загружается 30 секунд, а потом каждый сайт в нем еще по пол-минуты, а после 5 вкладок, начинает выгружать фоновые. О видео речи даже не идет - аппаратное декодирование новых форматов убивает старые девайсы быстрее нехватки памяти.
И вот все вроде хорошо. Да только в реальной жизни Kafka, Spark и Hadoop живет где-то там, в королевстве кривых платформ корпоративного разлива, администрируются выделенной командой, и настроены согласно их, этой команды, представлениям о прекрасном.
И при попытке использовать эти сервисы, проблема не в том, как контейнеры локально поднять, или пакеты в виртуальное окружение питона установить, а, скорее, в том, чтобы затолкать в свой нормально выглядящий скрипт обработки поддержку stage-развертывания, Kerberos аутентификации, и автосинхронизацию схем топиков, ибо дата продюсеры имеют обыкновение, без объявления, ломать формат сообщений.
И после фарширования скрипта обработки всем этим хозяйством, еще и неплохо уметь его локально запускать для тестов. И воспроизвести локально тот же Kerberos уже не так просто....
Концептуально похоже на 20-летний уже как ISO стандарт-расширение ISO IEC 14496 по хранению и передаче трехмерных сцен как параметров объектов в формате MP4 файлов. Дальше нескольких научных работ это не ушло. Скорее всего по причине отсутствия как раз вменяемого способа такие сцены показывать и создавать.
А как две разные архитектуры выглядят для софта? Надо отдельные ОС иметь для каждого ядра, или в сейчас можно тот же Linux собрать в мультиплатформу ARM+Risc-v? А планировщик задач как работать может в таких условиях? В десктопных Intel E+P ядра отрывают голову планировщику. А тут аж архитектуры разные. Ну и ядра не то чтобы мощные для трансляции инструкций на лету.
А 'отличный' проект. Позволить скриптам с администраторскими правами скачать с неизвестного сервера какие-то непонятные исполняемые файлы и почти 3 гигабайта архив, и распаковать это все прямо в свою систему с выключенными сервисами безопасности. Антивирус тоже нужно отключать? Почему-то не упомянуто.
Нет бы выложить описание и документацию, что, где как и почему подменяется. Менее подозрительно было бы, и более полезно знать.
Сэкономлю пару кликов: в архиве всякие медиа файлы, куски Office 2010 включая Project и Visio, россыпь исполняемых файлов из разных проектов по смене внешнего вида Windows, патчи реестра, батники и PowerShell скрипты, чтобы все это смотать.
Выглядит максимально подозрительно уже, и крайне рисково в целом на перспективу.
Но работа проведена грандиозная, что есть, то есть.
Небольшой веб-сервис c OpenAPI UI, предоставляет просто API, и взаимодействует с несколькими другими API. OpenAPI 3.0 нам было достаточно. Внешние сервисы: Swagger 2 или OpenAPI 3.0 тоже. API Клиент не предполагает распространение, и скорее для внутренних нужд и тестирования сервиса, однако для внешних сервисов хозяева сервисов клиенты не предоставляют.
Главные требования к выбору генератора - API Spec First, чтобы фокусироваться на контракте, а не на коде; изоляция сгенерированного кода от реализации в целях проверки совместимости типов и декларации интерфейса; минимальное количество ручной работы по выполнению тривиальный операций преобразования форматов; Язык - Python, Сервер приложений не важен, лишь бы было четкое разделение, где свой код, где генерированный.
Стандартным генератором я бы назвал https://github.com/swagger-api/swagger-codegen. Выглядит достаточно официальным, предлагает генераторы для сервера и клиента. Вот к нему основная претензия в неочевидном мусоре. Генерируется куча всего, развалено как попало, да еще и как jar файл распространяется. Без экосистемы разработки на Java было крайне нетривиально его запустить в CI/CD, а интегрировать в Python package структуру проекта оказалось неподъемно. Какое-то оно оказалось, Java-style что ли...
После активного поиска и в целом разочарования по серверным генераторам, пришли к https://github.com/spec-first/connexion, с ним необычно, что генерации серверного кода нет вообще, и фреймворк реализует весь бойлерплейт на лету в рантайме, но вменяемая и тривиальная интеграция через operationID атрибут нас устроила. Имеем API Spec файл, который при сборке подсовывается в connexion и это все запускает с guvicorn. Если какие-то контракты не соблюдены - на старте ругается на несоответствие схемы и реализации.
С генерацией клиента оказалось проще, но интереснее Альтернатив полно.
Разные команды у нас используют OpenAPI чуть-чуть по-своему, и неограниченные генераторами иногда публикуют некорректные спецификации. Как первый попавшийся генератор, который минималистичный и изолированный: https://github.com/openapi-generators/openapi-python-client. Буквально 3 файла для импорта в собственно приложение и всё. 3 из 5 клиентов до сих пор генерируем этим генератором.
А вот для двух других сервисов, openapi-python-client создает некорректный код клиента или просто валится с ошибкой парсинга, и никаких шансов изменить спецификацию. Так пришли к https://github.com/Azure/autorest, который смог успешно прожевать, хотя и ругаясь предупреждениями. Пришлось отключить строгую проверку типов, но в целом нас устроило. Целиком не мигрировали на autorest из-за лени и нежелания трогать то, что работает.
И все эти прекрасные цифровые финансовые инструменты никак не снижают цену за товар, при оплате здесь и сейчас, целиком и в наиболее удобной форме. Тот же пример с телефоном за 10к. Если он на ценнике 10к, а с кредитом 10к+1к процентов, а с BNPL - на ценнике 11к и без переплат, то как я могу купить телефон за 10к не используя ненужные мне финансовые инструменты, и не оплачивая тот сервис, которым не пользуюсь. Ну и непонятно в этом случае, куда пойдет эта лишняя тысяча, если я полностью оплатил покупке сразу без сплитов.
Для меня это выглядит, как разгон инфляции, ибо кол-во долговых обязательств начинает превышать скорость производства ценности.
Какой оригинальный подход - измерять перспективность новой версии формата через количество строк и уровней вложенности.
Вот чего OpenAPI не хватает, так это строгости, чтобы запретить некорректные интерфейсы. А для этого стоит попробовать уйти от абстрактных JSON схем на каждом углу, и уделить больше времени дизайну собственно архитектуры API и ключевых деталей.
Генераторы тоже головную боль создают. 3.1 не всеми поддерживается вообще. 3.0 поддерживается как попало, и не весь функционал спецификации приводит к корректно сгенерированном коду.
Для серверной части пока только Connexion достоин внимания. Клиентская часть - autorest.
А стандартный генератор производит лишний мусор, который ни интегрировать, ни изолировать в проекте нельзя.
Это самый красивый интерфейс калькулятора для сложения 4 положительных и 6 отрицательных чисел, что мне встречался. И даже с функцией изменения количества слагаемых.
Если только для себя и своих - Matrix, свой сервер можно не ставить, если доверяешь публичному. Выбрать можно любой сервер, где политика поведения устраивает. Клиентов полно, вменяемо функционирует. HTTP(S), а значит, никаких болей с портами.
Другая альтернатива - Jabber, он потерял популярность, но все ещё шевелится. С клиентами и функционалом посложнее, сетевые порты и мобильные клиенты - боль.
Tox - это прямо на случай, когда отрезаны все средства. Аудио\Видео звонки есть, но лагают. Чат норм, мобильный клиент норм. Боль для обычной жизни(но необходимость для теневой) - нет вменяемого публичного идентификатора, потому без внешнего способа связи для передачи ID связаться с собеседником нереально.
Большая часть остальных доступных мессенджеров - проприетарный WebRTC на сервер мессенджера, не отличающиеся друг от друга и непонятно как монетизирующиеся.
А еще на верном пути к #include <algorithm>, и обезжиренному RAII, и функциональным типам.
Поразительно, как с развитием Go, давно известные и в других местах обкатанные концепции изобретаются заново с использованием урезанного базового функционала.
Но за статью плюс, полезная.
А вот потрудились бы написать статью, как все-таки покупать б\у видеокарты, как проверять, как торговаться, то вызвали бы больше доверия к себе, как продавцам нового оборудования.
Спасибо за обстоятельный отчет. Притарил статью в карман.
А всё программное хозяйство в одну машину запихано или на разных хостах? Как собственно интеграция и начальная конфигурация непосредственно железа происходит? Хост-система настроена вручную штатными средствами или какие Ansible, Chef, Puppet?
Я вот смотрю в сторону построения своей home lab, но приправленной распределенной структурой - 4 ноутбука разной степени паршивости хочу объединить в кластер, с автоматическим развертыванием базового образа OS, поверх него уже накатывать k8s и прочие контейнеры.
Требование - взял любой ноут, ребутнул его в пользовательскую систему - у тебя мобильная станция, попользовался, ребутнул назад в PXE - нода вернулась в кластер, k8s смасштабировался.
Теоретическая подготовка пока привела к Warewulf, DRBL, oneSIS и похожим системам построения вычислительных кластеров. Cockpit и CosyStack в очереди на оценку пригодности.
А какие типовые задачи с LeetCode для Lead или Principal Software Engineer вы предлагаете на собеседовании?
В Яндексе рабочие задачи должны решаться с первого раза?
Кто в производственном процессе выполняет декомпозицию бизнес-требований до задач уровня LeetCode с описанием входных и выходных данных и лимитов по ресурсам?
Относительно статьи, автор предлагает использовать встроенную в HDR контент информацию о transfer characteristic и peak luminance чтобы скомпенсировать визуальное влияние яркости на цветность. Преимущества каждый определяет для себя, но у меня сомнения, что этот способ применим для другого типа контента. Анимация все-таки не содержит световых перепадов, и тут скорее 10-битный формат HDR поспособствует более плавным цветовым градиентам без лесенок. В сложно-освещенных сценах насыщение цвета в ущерб полутонам сделает картинку чрезмерно искусственной.
HDR - это не про цвет и насыщенность, а про свет и яркость. Точнее, соотношение яркости темного и светлого в одном кадре, и диапазон градаций между ними.
В HDR контенте указывается диапазон яркости и степень градации, в зависимости от формата контента как для все потока в целом, так и для каждого кадра. Оборудование использует эти данные для непосредственного отображения как задумано, или для всяких конверсий на лету. И наибольших визуальный эффект HDR контент на HDR оборудовании (до 1000 нит) будут иметь кадры с очень яркими и очень темными областями одновременно, в таких кадрах яркие области не окажутся выжженными добела, а в тенях - останется достаточно уровней для мелких деталей.
При отображение на LDR(обычно, впрочем, пишут SDR от Standard Dynamic Range, 100-300 нит) контент будет отображаться как бы блеклым из-за некорректного отсечения яркостной компоненты. Штатная конвертация предполагает сжимание динамического диапазона с использованием разных линейных или нелинейных преобразований, что приводит к сглаживанию детализации в тенях и\или выжженным ярким областям.
А какая добавочная ценность у OpenDAL для проектов не в экосистеме Apache?
Отрицая родные SDK и переизобретая реализации конкретных сервисов, OpenDAL сразу становится отстающим по функционалу от родных SDK.
Как максимально общий интерфейс взаимодействия, он же сводится к минимальному общему функционалу, а все особенности и локальные улучшения становятся или неподдерживаемыми, или протекающими абстракциями.
Нет ничего хуже для интегрированного приложения, как использовать единый общий интерфейс, с костылями под каждый сервис на уровне приложения. Вместо N зависимостей от SDK, получаем N+1, и хорошо еще если вообще можно какой-никакой доступ в нижним слоям получить и напрямую в SDK присунуть требуемое.
Проще уж проектное архитектурное решение принять, привнести в проект стандартную зависимость от конкретных официальных SDK, и реализовать диктуемые конкретными требованиями проекта интерфейсы абстракций, учитывая в первую очередь нужды продукта, а не цель общности абстракции.
Применимы ли озвученные рекомендации по атомизации процессов к линейному менеджменту? Они с одной стороны - сотрудники со своими задачами, с другой - менеджеры, ответственные за оптимизацию нижележащих процессов.
Как в многоуровневой структуре происходит анализ и улучшение организации? Сверху вниз на один уровень детализации, или С-уровень обязан разобраться в бизнес-процессах и назначить исполнителей?
Спасибо за статью.
Почему при прохождении гравитационной волны, влекущей изменение метрики пространства-времени, электромагнитная волна не меняется вместе с метрикой?
Волна же в этом же пространстве-времени находится, значит сжатия-растяжения на нее влияют как на саму метрику. Откуда возникает сдвиг фаз?
Использовать DRY, опираясь на реализацию - приводит к описанным проблемам. Использовать DRY, опираясь на контракт и выделяя абстракции как наиболее стабильные части - находится за пределами бытового понимания.
А 'на офисном ПК под Windows 10 (апрель 2024)' это как? Мои устройства с 4Гб оперативной памяти уже в пролете для современного веба? А Acer Aspire One с 1Гб?
ТОЛЬКО браузер без вкладок вроде легко отжирает 2,5Гб. При открытии сайта - своп и запись сотен мелких кэш файлов убивают остаток ресурсов. Чем таким занято нативное приложение, чтобы, ничего не выполняя, столько памяти использовать. Откуда борьба за миллисекунды бенчмарков, если браузер загружается 30 секунд, а потом каждый сайт в нем еще по пол-минуты, а после 5 вкладок, начинает выгружать фоновые. О видео речи даже не идет - аппаратное декодирование новых форматов убивает старые девайсы быстрее нехватки памяти.
И вот все вроде хорошо. Да только в реальной жизни Kafka, Spark и Hadoop живет где-то там, в королевстве кривых платформ корпоративного разлива, администрируются выделенной командой, и настроены согласно их, этой команды, представлениям о прекрасном.
И при попытке использовать эти сервисы, проблема не в том, как контейнеры локально поднять, или пакеты в виртуальное окружение питона установить, а, скорее, в том, чтобы затолкать в свой нормально выглядящий скрипт обработки поддержку stage-развертывания, Kerberos аутентификации, и автосинхронизацию схем топиков, ибо дата продюсеры имеют обыкновение, без объявления, ломать формат сообщений.
И после фарширования скрипта обработки всем этим хозяйством, еще и неплохо уметь его локально запускать для тестов. И воспроизвести локально тот же Kerberos уже не так просто....
Концептуально похоже на 20-летний уже как ISO стандарт-расширение ISO IEC 14496 по хранению и передаче трехмерных сцен как параметров объектов в формате MP4 файлов. Дальше нескольких научных работ это не ушло. Скорее всего по причине отсутствия как раз вменяемого способа такие сцены показывать и создавать.
А где вы берете весь этот узко-специализированный софт? Он же обычно для сертифицированных сервисных центров и распространяется по закрытым каналам.
А как две разные архитектуры выглядят для софта? Надо отдельные ОС иметь для каждого ядра, или в сейчас можно тот же Linux собрать в мультиплатформу ARM+Risc-v? А планировщик задач как работать может в таких условиях? В десктопных Intel E+P ядра отрывают голову планировщику. А тут аж архитектуры разные. Ну и ядра не то чтобы мощные для трансляции инструкций на лету.
А 'отличный' проект. Позволить скриптам с администраторскими правами скачать с неизвестного сервера какие-то непонятные исполняемые файлы и почти 3 гигабайта архив, и распаковать это все прямо в свою систему с выключенными сервисами безопасности. Антивирус тоже нужно отключать? Почему-то не упомянуто.
Нет бы выложить описание и документацию, что, где как и почему подменяется. Менее подозрительно было бы, и более полезно знать.
Сэкономлю пару кликов: в архиве всякие медиа файлы, куски Office 2010 включая Project и Visio, россыпь исполняемых файлов из разных проектов по смене внешнего вида Windows, патчи реестра, батники и PowerShell скрипты, чтобы все это смотать.
Выглядит максимально подозрительно уже, и крайне рисково в целом на перспективу.
Но работа проведена грандиозная, что есть, то есть.
Мой случай следующий:
Небольшой веб-сервис c OpenAPI UI, предоставляет просто API, и взаимодействует с несколькими другими API. OpenAPI 3.0 нам было достаточно. Внешние сервисы: Swagger 2 или OpenAPI 3.0 тоже. API Клиент не предполагает распространение, и скорее для внутренних нужд и тестирования сервиса, однако для внешних сервисов хозяева сервисов клиенты не предоставляют.
Главные требования к выбору генератора - API Spec First, чтобы фокусироваться на контракте, а не на коде; изоляция сгенерированного кода от реализации в целях проверки совместимости типов и декларации интерфейса; минимальное количество ручной работы по выполнению тривиальный операций преобразования форматов; Язык - Python, Сервер приложений не важен, лишь бы было четкое разделение, где свой код, где генерированный.
Стандартным генератором я бы назвал https://github.com/swagger-api/swagger-codegen. Выглядит достаточно официальным, предлагает генераторы для сервера и клиента. Вот к нему основная претензия в неочевидном мусоре. Генерируется куча всего, развалено как попало, да еще и как jar файл распространяется. Без экосистемы разработки на Java было крайне нетривиально его запустить в CI/CD, а интегрировать в Python package структуру проекта оказалось неподъемно. Какое-то оно оказалось, Java-style что ли...
После активного поиска и в целом разочарования по серверным генераторам, пришли к https://github.com/spec-first/connexion, с ним необычно, что генерации серверного кода нет вообще, и фреймворк реализует весь бойлерплейт на лету в рантайме, но вменяемая и тривиальная интеграция через operationID атрибут нас устроила. Имеем API Spec файл, который при сборке подсовывается в connexion и это все запускает с guvicorn. Если какие-то контракты не соблюдены - на старте ругается на несоответствие схемы и реализации.
С генерацией клиента оказалось проще, но интереснее Альтернатив полно.
Разные команды у нас используют OpenAPI чуть-чуть по-своему, и неограниченные генераторами иногда публикуют некорректные спецификации. Как первый попавшийся генератор, который минималистичный и изолированный: https://github.com/openapi-generators/openapi-python-client. Буквально 3 файла для импорта в собственно приложение и всё. 3 из 5 клиентов до сих пор генерируем этим генератором.
А вот для двух других сервисов, openapi-python-client создает некорректный код клиента или просто валится с ошибкой парсинга, и никаких шансов изменить спецификацию. Так пришли к https://github.com/Azure/autorest, который смог успешно прожевать, хотя и ругаясь предупреждениями. Пришлось отключить строгую проверку типов, но в целом нас устроило. Целиком не мигрировали на autorest из-за лени и нежелания трогать то, что работает.
И все эти прекрасные цифровые финансовые инструменты никак не снижают цену за товар, при оплате здесь и сейчас, целиком и в наиболее удобной форме. Тот же пример с телефоном за 10к. Если он на ценнике 10к, а с кредитом 10к+1к процентов, а с BNPL - на ценнике 11к и без переплат, то как я могу купить телефон за 10к не используя ненужные мне финансовые инструменты, и не оплачивая тот сервис, которым не пользуюсь. Ну и непонятно в этом случае, куда пойдет эта лишняя тысяча, если я полностью оплатил покупке сразу без сплитов.
Для меня это выглядит, как разгон инфляции, ибо кол-во долговых обязательств начинает превышать скорость производства ценности.
Какой оригинальный подход - измерять перспективность новой версии формата через количество строк и уровней вложенности.
Вот чего OpenAPI не хватает, так это строгости, чтобы запретить некорректные интерфейсы. А для этого стоит попробовать уйти от абстрактных JSON схем на каждом углу, и уделить больше времени дизайну собственно архитектуры API и ключевых деталей.
Генераторы тоже головную боль создают. 3.1 не всеми поддерживается вообще. 3.0 поддерживается как попало, и не весь функционал спецификации приводит к корректно сгенерированном коду.
Для серверной части пока только Connexion достоин внимания. Клиентская часть - autorest.
А стандартный генератор производит лишний мусор, который ни интегрировать, ни изолировать в проекте нельзя.