Да и вообще концепция refapp кажется бестолковой.

типа того. но interest_name - это строка в utf-8, а самих интересов может быть десятки.
т.е. надо уметь для всех пользователей очень быстро уметь строить пересечения их интересов, а самое главное - компактно их хранить.

Решения из top10 использовали битмапы для этого. Варианты на деревьях жрали много памяти.

А зачем они вообще могут быть нужны? Т.е. смотришь на них и возникают мысли: "да, но у меня этого нет, а то что реально стоило бы осветить как раз нет"

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

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

Ребята всем привет. Может я не по адресу но ищу информацию о правильном управлении демо версиями для корпоративных продуктов в SAAS. Как создавать, какие должны быть демо, в каком формате и с какими данными предоставлять демо клиенту, как хранить и делать бекапы. У кого нибудь есть информация об этом? Или хотя бы направление в каких ресурсах искать? Заранее благодарен.

В продолжение темы технологий Microsoft, свежая новость:
https://twitter.com/gvanrossum/status/1326932991566700549?s=19

Это было не все, оказывается:
https://twitter.com/Grady_Booch/status/1327710551774904320?s=19

Коллеги, а в случае микросервисной архитектуры, какие варианты есть формирования общего реестра API?
Есть компоненты, у каждого есть сваггер. Есть ли решения, позволяющие собрать их в одном месте?
Конечно можно всё запихнуть на одну страницу конфы, но думается, что можно сделать лучше. xD

А зачем общий реестр?

Я так понял, что это шутка...

Есть API Management

Вот одно из хороших решений https://cloud.google.com/apigee

интересно, а что за фитчи c++ использовали победили, что им удалось обойти других , если не смотреть вот на то замедление , что дает gc. Может использовали SIMD?в  джаве ведь это нельзя. только если сам компилятор поймет где они нужны.

Привет.
OpenAPI + Postman?

Народ поголовно использовал битмапы для представления набора интересов. А дальше на помощь приходят popcount и simd

@TitanUser Сейчас OpenAPI развёрнут для каждого микросервиса в отдельности. Конечно используются разные ПО для прокидывания запросов, вроде postman.
Но вопрос в том, как в рамках одной команды/компонента макросистемы указать все доступные API её сервисов.
Для того, чтобы была единая точка входа для внутренних разработчиков к списку API.

Задокументируйте их просто и дайте ссылки

Уже сделано.

Или у вас каждый день новый сервис создается?