TPC & UDP, Redis, NATS, kafka, итд.
Везде где есть потокавая передача данных можно использовать как транспорт. Главное формат общения был запрос ответа был под стандартом.
Для критиков "зачем это на Linux": COM — это универсальное ABI для кросс-языкового объектно-ориентированного взаимодействия. На текущий момент встроенные средства Linux и OSX такое ABI определяют только для обычных функций в стиле C.
Мы успешно применяем COM для взаимодействия кода на C# с объектно-ориентированным кодом на C++. За счёт встроенного рефкаунтинга время жизни объектов прозрачно регулируется, ABI даёт переносимость между платформами.
В частности посредством COM сделан новый бэкэнд под OSX для AvaloniaUI, других вменяемых способов сделать слой интеграции с ObjC просто нет. А тут clang-овский ARC обеспечивает интеграцию рефкаунтинга C++ и ObjC, а COM обеспечивает интеграцию C++ и C#.
А вообще смысл статьи в том, что в любой команде программистов должен быть Lead Programmer, который и будет задавать какие технологии все будут использовать и следить за тем, чтоб все придерживались единого стека технологий и стандартов кода.
Как говорил Наполеон Бонапарт: лучше когда армией командует один плохой генерал, чем 20 хороших :)
Намного быстрее обратиться к переменной напрямую, чем предварительно передавать ее значение через стек. Имеется ввиду, стек процессора, который используется компиляторами для передачи параметров функций.
Что за бред я только что прочитал?
Передача значения через стек — это стандартная процедура, выполняемая миллионы раз в секунду. Да и не обязательно передача аргументов выполняется именно через стек. Например, в архитектуре x86_64 первые энцать аргументов передаются через регистры процессора. Зависит, конечно, от используемого ABI.
Обращение к переменной напрямую — весьма вероятный cache miss со всеми вытекающими.
Обращение к переменной в стеке — никаких промахов, т.к. стек с очень большой вероятностью закэширован.
В связи с этим, прошу свободно мыслящих людей высказать свое аргументированное мнение на вопросы:
поддерживаете ли вы введение экспериментальных функций super() и stop_globals()?
Я не свободно мыслящий, т.к. ограничен в своих размышлениях объективной реальностью. Но таки отвечу: не поддерживаю.
Ибо после введения таких функций в «большом синем слоне» что-нибудь неминуемо отвалится. Вы можете навскидку перечислить модули, использующие глобальные переменные для своей работы? Я вот нет.
что думаете о вышеописанной идее в целом?
Я вам расскажу старый анекдот.
Приходит молодой сисадмин к старому и опытному, и говорит:
— Хочу, чтобы пользователи не нажимали на вот эту кнопку. Какую программу лучше использовать, чтобы они не смогли это сделать?
Старый сисадмин вздохнул и ответил:
— Просто собери их всех и скажи: «кто нажмет на вот эту вот кнопку — пооткусываю пальцы». И кусачки покажи.
Мораль сей басни такова: технические средства решения проблемы не обязательно лучшие. Иногда гораздо лучше работают административные меры или банальная дисциплина.
Нету. Именно по этой причине для не которых вещей использую именно яндекс-диск.
Один из сценариев использования, которые я счел полезными для себя:
Все пароли храню в keepass (для него есть клиенты под все платформы). Долгое время data-файл keepass хранил в папочке, которая синхронизировалась через dropbox, Сейчас пришел к другой схеме, которая показалось чуть более удобной и не требует установленного dropbox-клиента:
Использую для keepass небольшой плагин позволяющий работать с базой паролей через webdav (или если не получается, то с последней закэшированной). Из популярных облачных клиентов без танцев с бубном только яндекс диск заработал. Очень удобно.
TPC & UDP, Redis, NATS, kafka, итд.
Везде где есть потокавая передача данных можно использовать как транспорт. Главное формат общения был запрос ответа был под стандартом.
https://moleculer.services/docs/0.12/transporters.html
Для критиков "зачем это на Linux": COM — это универсальное ABI для кросс-языкового объектно-ориентированного взаимодействия. На текущий момент встроенные средства Linux и OSX такое ABI определяют только для обычных функций в стиле C.
Мы успешно применяем COM для взаимодействия кода на C# с объектно-ориентированным кодом на C++. За счёт встроенного рефкаунтинга время жизни объектов прозрачно регулируется, ABI даёт переносимость между платформами.
Шарповую обёртку генерим средствами SharpGenTools.
В частности посредством COM сделан новый бэкэнд под OSX для AvaloniaUI, других вменяемых способов сделать слой интеграции с ObjC просто нет. А тут clang-овский ARC обеспечивает интеграцию рефкаунтинга C++ и ObjC, а COM обеспечивает интеграцию C++ и C#.
Соорудил базовый заголовок с описанием IUnknown, реализацию ComPtr и ComObject и поехали. Дальше определяем набор интерфейсов и можно прозрачно их использовать из кода на C# как родные.
Как говорил Наполеон Бонапарт: лучше когда армией командует один плохой генерал, чем 20 хороших :)
Что за бред я только что прочитал?
Передача значения через стек — это стандартная процедура, выполняемая миллионы раз в секунду. Да и не обязательно передача аргументов выполняется именно через стек. Например, в архитектуре x86_64 первые энцать аргументов передаются через регистры процессора. Зависит, конечно, от используемого ABI.
Обращение к переменной напрямую — весьма вероятный cache miss со всеми вытекающими.
Обращение к переменной в стеке — никаких промахов, т.к. стек с очень большой вероятностью закэширован.
Я не свободно мыслящий, т.к. ограничен в своих размышлениях объективной реальностью. Но таки отвечу: не поддерживаю.
Ибо после введения таких функций в «большом синем слоне» что-нибудь неминуемо отвалится. Вы можете навскидку перечислить модули, использующие глобальные переменные для своей работы? Я вот нет.
Я вам расскажу старый анекдот.
Приходит молодой сисадмин к старому и опытному, и говорит:
— Хочу, чтобы пользователи не нажимали на вот эту кнопку. Какую программу лучше использовать, чтобы они не смогли это сделать?
Старый сисадмин вздохнул и ответил:
— Просто собери их всех и скажи: «кто нажмет на вот эту вот кнопку — пооткусываю пальцы». И кусачки покажи.
Мораль сей басни такова: технические средства решения проблемы не обязательно лучшие. Иногда гораздо лучше работают административные меры или банальная дисциплина.
Один из сценариев использования, которые я счел полезными для себя:
Все пароли храню в keepass (для него есть клиенты под все платформы). Долгое время data-файл keepass хранил в папочке, которая синхронизировалась через dropbox, Сейчас пришел к другой схеме, которая показалось чуть более удобной и не требует установленного dropbox-клиента:
Использую для keepass небольшой плагин позволяющий работать с базой паролей через webdav (или если не получается, то с последней закэшированной). Из популярных облачных клиентов без танцев с бубном только яндекс диск заработал. Очень удобно.