Непонятно, чем автора не устроило банальное асимметричное шифрование из того же openssl или там GnuPG, а обменяться открытыми ключами можно было бы так же через QR-код. И гонять сообщения хоть через ту же банальную почту.
Ну как говорится, если вами заинтересуются люди из соответствующих служб, то никакое шифрование не поможет, если у них будет подход к тушке.
TL;DR Тема фронта и тамошних фреймворков слишком далека от меня, но из того что я понял, автор умудрился пережить операцию, потерять кошку, не скурвиться и продолжить работу над фреймворком. Могу только пожелать здоровья, удачи в дальнейшей работе и посочувствовать потере питомца. ЗЫ. "практически нет внешних зависимостей" - зачастую это одно из свойств фрейморков. Напрягает, когда более-менее простая вещь тащит за собой 100500 зависимых пакетов из которых дай Бог использует процентов 10.
С неприязнью вспоминаю 7-ю 1С-ку. Ради которой приходилось городить костыли с терминал-сервером. Но это моё отношение как админа сети в те времена. Хотя сами 1С-ники ничего особо плохого про неё не говорили, благо куча однокурсников ушла по тем стопам. Ну а с выходом 8-ки как понимаю и проблем таких не осталось.
А вот про SAP как раз читал всякое и понял, что ну очень недружелюбная система.
Ну т.е. ты придумал какое-то своё, удобное лично тебе, определение инкапсуляции и на его основе бодро воюешь с ООП. Ну что, удобно, правда попахивает шизофренией.
"я что-то говорил про некую «идеальную инкапсуляцию в не-ООП языках»,
Ну ты так упирал именно на ООП, хотя инкапсуляция возможна не только в ООП.
"зато про ООП — это на каждом столбе написано."
Пример?
"Во-вторых, какой-нибудь идрис вас буквально заставит описать тип для температуры, а потом не скомпилирует передачу -300 извне."
Ты не можешь регулировать то что тебе придёт снаружи. Так что проверки будут, как и обработка ошибочного ввода. Как ты не описывай тип, из порта в/в ты читаешь порток байт которые тебе придётся преобразовать в свой тип. А в случае прихода мусора как-то это обработать и как-то на это отреагировать. И никакой компилятор не гарантирует тебе отсутствие сбоя оборудования.
"В-третьих, обработка ошибок может быть конвенциональной, например, в эрланге процесс упадет и супервизор его перезапустит с последней увиденной температурой, которую он смог обработать, без участия в том программиста."
У тебя датчик навернулся и гонит мусор. Будем на каждый цикл чтения перезапускать процесс? Впрочем это не важно, у тебя так или иначе будет обработка ошибок.
В любом случае, покажи общепринятое формальное определение инкапсуляции где возврат ошибки и обработка ошибок являются нарушением инкапсуляции?
Непонятно, как без обработки ошибок реализовать инициализацию типа Temperature из пользовательских данных в не-ООП языках? Ну вот читаем показания датчика через порт и оттуда внезапно прилетели условные -300 градусов. И что с этим будем делать, в рамках некой идеальной инкапсуляции в не-ООП языках?
Когда программисту нечего делать, то он придумывает свой собственный язык программирования и свой собственный язык описания данных. Сам так же делал. И до сих пор в голове крутится свой собственный ЯП ОН с БДиШ. Но то больше хобби чем решение задач.
А вообще, чтобы создавать новый ЯП ОН, нужна некая свежая и крутая конЪ-цепция, как в своё время было с Rust. В противном случае это либо самоудовлетворение либо трата чужих денег.
Интересно. Как я понял, косяк в протоколе OpenWire. Но что если наружу торчит какой-нибудь AMQP? Или вообще STOMP? Можно ли как-нибудь заставить брокер создать требуемый объект?
Непонятно, чем автора не устроило банальное асимметричное шифрование из того же openssl или там GnuPG, а обменяться открытыми ключами можно было бы так же через QR-код.
И гонять сообщения хоть через ту же банальную почту.
Ну как говорится, если вами заинтересуются люди из соответствующих служб, то никакое шифрование не поможет, если у них будет подход к тушке.
Из всего представленного многообразия, знаком только Cyfral. Видать остальные до Владика не добрались.
TL;DR
Тема фронта и тамошних фреймворков слишком далека от меня, но
из того что я понял, автор умудрился пережить операцию, потерять кошку, не скурвиться и продолжить работу над фреймворком.
Могу только пожелать здоровья, удачи в дальнейшей работе и посочувствовать потере питомца.
ЗЫ. "практически нет внешних зависимостей" - зачастую это одно из свойств фрейморков.
Напрягает, когда более-менее простая вещь тащит за собой 100500 зависимых пакетов из которых дай Бог использует процентов 10.
Во, кстати да, с этой точки зрения 1С похожа на секту 😁
С неприязнью вспоминаю 7-ю 1С-ку. Ради которой приходилось городить костыли с терминал-сервером. Но это моё отношение как админа сети в те времена.
Хотя сами 1С-ники ничего особо плохого про неё не говорили, благо куча однокурсников ушла по тем стопам.
Ну а с выходом 8-ки как понимаю и проблем таких не осталось.
А вот про SAP как раз читал всякое и понял, что ну очень недружелюбная система.
Если бы еще в OpenIDE вернули возможность включать классический вид или запилили бы соответствубщий плагин, то цены бы не было.
Причем иут Rust, если вызывается syscall, , а syscall на вход принимает int?
Это именно првндение Linux, а не Rust.
Автор статьи посмел посягнуть на священную корову.
За такую ересь его могут придать костру.
Ну т.е. ты придумал какое-то своё, удобное лично тебе, определение инкапсуляции и на его основе бодро воюешь с ООП. Ну что, удобно, правда попахивает шизофренией.
"я что-то говорил про некую «идеальную инкапсуляцию в не-ООП языках»,
Ну ты так упирал именно на ООП, хотя инкапсуляция возможна не только в ООП.
"зато про ООП — это на каждом столбе написано."
Пример?
"Во-вторых, какой-нибудь идрис вас буквально заставит описать тип для температуры, а потом не скомпилирует передачу -300 извне."
Ты не можешь регулировать то что тебе придёт снаружи. Так что проверки будут, как и обработка ошибочного ввода. Как ты не описывай тип, из порта в/в ты читаешь порток байт которые тебе придётся преобразовать в свой тип. А в случае прихода мусора как-то это обработать и как-то на это отреагировать. И никакой компилятор не гарантирует тебе отсутствие сбоя оборудования.
"В-третьих, обработка ошибок может быть конвенциональной, например, в эрланге процесс упадет и супервизор его перезапустит с последней увиденной температурой, которую он смог обработать, без участия в том программиста."
У тебя датчик навернулся и гонит мусор. Будем на каждый цикл чтения перезапускать процесс?
Впрочем это не важно, у тебя так или иначе будет обработка ошибок.
В любом случае, покажи общепринятое формальное определение инкапсуляции где возврат ошибки и обработка ошибок являются нарушением инкапсуляции?
Непонятно, как без обработки ошибок реализовать инициализацию типа Temperature из пользовательских данных в не-ООП языках?
Ну вот читаем показания датчика через порт и оттуда внезапно прилетели условные -300 градусов. И что с этим будем делать, в рамках некой идеальной инкапсуляции в не-ООП языках?
Когда программисту нечего делать, то он придумывает свой собственный язык программирования и свой собственный язык описания данных.
Сам так же делал. И до сих пор в голове крутится свой собственный ЯП ОН с БДиШ.
Но то больше хобби чем решение задач.
А вообще, чтобы создавать новый ЯП ОН, нужна некая свежая и крутая конЪ-цепция, как в своё время было с Rust. В противном случае это либо самоудовлетворение либо трата чужих денег.
Заменить встроенный в Спринг брокер через STOMP прокладку.
Интересно.
Как я понял, косяк в протоколе OpenWire.
Но что если наружу торчит какой-нибудь AMQP? Или вообще STOMP? Можно ли как-нибудь заставить брокер создать требуемый объект?
Главное, что то правильный, демократический и свободный паяльник, а не какой-то там диктатроский.
1С это русский Кобол. Хрен когда умрёт, как и проекты на нём.
Причём тут "обиженка" если Джетбрейнсы тупо заблокировали работу из РФ?
Для GCC и CLang'а кто-то подобное делал?
Походу невозможно быть более жадным ублюдком чем Амазон.
UPD. А не, можно. Вон, ниже пишут, что у Яндекса тоже берут за 3xx/4xx.
Т.е. получается, что зная имя чьего-то существующего бакета я могу тупо его заддосить и подставить владельца на серьёзные траты?
Б - безопасность.