Как говорилось на одной известной картинке: «но зачем?»
Все примеры, которые я видел, применения по делу, не требовали обязательного вызова всех методов. Как правило речь идет о вызове лишь части методов, иногда они даже бывают взаимоисключающие.
По моему никаких уроков «рынок» не извлек.
Та же Visa максимум что смогла, это выпустить QIWI Wallet. По сути, еще одну предоплаченую карту, которых и так уже сотни. Т.е. вместо использования своего счета в банке, я должен: положи деньги на QIWI, положи деньги на «Тройку», положи деньги на счет мобильного и т.д.
Google и Apple пытаются, что-то делать в правильном направлении, но дальше США не высовываются.
По уму, получается сертификат на server.com с правом подписи на поддомены. Генерируются ключ+сертификат на localhost.server.com и загружается на токен (лучше на каждый токен свой, но можно и один на все, тогда право подписи не нужно). Сам токен реализует вебвервер. Никаких левых сертификатов в truststore, ключ никак не извлечь из системы.
1. Это не прокси, это веб сервер.
2. Корневой сертификат будет на любом компьютере на котором используется данное ПО. Т.е. если это банк клиент, то у всех клиентов банка.
Разработчики скромно умолчали, что надо будет делать клиентам которые используют данный ключ, чтобы добавить сертификат. И откуда возьмется сам веб сервер, как будет запускаться и т.д…
Подмененный бинарник опасен только для этой системы. А украденный сертификат, позволяет атаковать удаленную систему.
1. Спуфим DNS и подменяем localhost.server.com с 127.0.0.1, на IP нашего сервера.
2. Приватный ключ к сертификату у нас уже есть, поднимаем свой сервер и может пытаться атаковать браузер клиента.
Для локального веб сервера HTTPS нужен не только сертификат, но и еще и приватный ключ от этого сертификата.
Вы его открыто храните в системе и не паритесь?
Нет, контракт обязателен к исполнению. Гарантом по сделке выступает биржа и она берет с участников гарантийное обеспечение на случай форс мажора. Если одна из сторон не выполнит свою часть сделки, это сделает биржа, и сама будет разбираться со стороной отказавшейся от обязательств. Т.е. штрафные санкции со стороны биржи обязательно последуют.
Форвард — это обязательство для обоих сторон, для одной продать для другой купить.
Есть опцион — это право (купить или продать) для одной стороны и обязанность для другой стороны (продать или купить) по указанной цене, если первая сторона захочет. Вот тут уже можно «заказать» цену покупки валюты и можно отказаться от сделки если на рынке курс выгодней. Но за это надо будет сразу заплатить премию.
Нужно сказать самое простое, «фьючерс» от английского «фьюч» («future») — «будущее», «форвард» — тоже понятно, что это то, что впереди. Возникновение всех этих вещей относится… Ну, действительно, считается, что первые форвардные контракты заключались где-то в Древней Греции, в Древнем Риме и пользовались ими финикийцы, как одни из самых развитых торговцев. В принципе, торговля и привела к появлению этого инструментария, в первую очередь, торговля товарами, потому что люди были заинтересованы застраховать как-то себя.
Там нет «переплаты» как таковой. Он может получиться даже дешевле текущей рыночной цены. https://geektimes.ru/company/itinvest/blog/265442/
Это по новой версии ПДД. По старой водитель был вправе рассчитывать на то что остальные участники дорожного движения соблюдают правила.
А вообще, это какое-то пустопорожнее теоретизирование. Все равно тут нет никого кто хорошо бы разбирался в ПДД США и был бы знаком с прецедентами в похожих случаях..
Когда код лежит в одном модуле, то классы легко могут ссылаться друг на друга и никто это не контролирует. А когда код разнесен по модулям, компилятор проверит, что код использует классы из библиотек на которые указанан зависимость.
Это следует из первого пункта: пусть у нас пока utils и logger независимы. И некий модуль использует только logger. Потом после маленького апдейта logger, в нем заюзали один метод из utils и все ClassNotFoundException после апдейта готов.
Для библиотеки из 3-х классов, это не актуально конечно, но для более серькзных вещей жизненный цикл релизов будет выглядеть криво.
Вот у нас есть есть 2 библиоткеки utils:1.0 и logger:1.0. Мы нашли неприятный баг в utils, быстро зафиксали его и надо зарелизить. Плюс у нас есть один готовый чейндж в logger и один ожидающий реализации для релиза logger:1.1.
И у нас получается выбор: релизить только utils:1.1, забив на то что мы еще получаем полурелизный logger в VCS теге. Или делать предрелиз logger:1.1/2. Оба варианта не смертельны, но кривоваты с т.з. жизненного цикла.
Раз уж мы подняли эту тему, объясните что вы получили сэкономив один модуль?
Столько антипаттернов и все из-за желания сэкономить пару модулей.
Разнеся код по разным модулям, мы гарантируем прозрачность зависимостей между ними.
Если они действительно независимы — то это будет проверено на уровне компилятора. Если есть зависимость, то она будет явно прописана и видна в pom.xml.
Подключая только одну библиотеку, никогда нельзя быть уверенным, что зависимость на другую не потребуется.
Все примеры, которые я видел, применения по делу, не требовали обязательного вызова всех методов. Как правило речь идет о вызове лишь части методов, иногда они даже бывают взаимоисключающие.
Та же Visa максимум что смогла, это выпустить QIWI Wallet. По сути, еще одну предоплаченую карту, которых и так уже сотни. Т.е. вместо использования своего счета в банке, я должен: положи деньги на QIWI, положи деньги на «Тройку», положи деньги на счет мобильного и т.д.
Google и Apple пытаются, что-то делать в правильном направлении, но дальше США не высовываются.
По уму, получается сертификат на server.com с правом подписи на поддомены. Генерируются ключ+сертификат на localhost.server.com и загружается на токен (лучше на каждый токен свой, но можно и один на все, тогда право подписи не нужно). Сам токен реализует вебвервер. Никаких левых сертификатов в truststore, ключ никак не извлечь из системы.
2. Корневой сертификат будет на любом компьютере на котором используется данное ПО. Т.е. если это банк клиент, то у всех клиентов банка.
Разработчики скромно умолчали, что надо будет делать клиентам которые используют данный ключ, чтобы добавить сертификат. И откуда возьмется сам веб сервер, как будет запускаться и т.д…
1. Спуфим DNS и подменяем localhost.server.com с 127.0.0.1, на IP нашего сервера.
2. Приватный ключ к сертификату у нас уже есть, поднимаем свой сервер и может пытаться атаковать браузер клиента.
Вы его открыто храните в системе и не паритесь?
Можно в конце концов купить своп и перенести дату. Наиболее продвинутые банки даже сами предоставляют такую услугу.
Форвард — это обязательство для обоих сторон, для одной продать для другой купить.
Есть опцион — это право (купить или продать) для одной стороны и обязанность для другой стороны (продать или купить) по указанной цене, если первая сторона захочет. Вот тут уже можно «заказать» цену покупки валюты и можно отказаться от сделки если на рынке курс выгодней. Но за это надо будет сразу заплатить премию.
Все валютного риска нет, цена фиксирована заранее.
Правда надо понимать, что если в YYY курс будет выгоднее, то вы все равно обязаны будете совершить сделку по ранее указанному курсу.
Там нет «переплаты» как таковой. Он может получиться даже дешевле текущей рыночной цены. https://geektimes.ru/company/itinvest/blog/265442/
В данном случае автор делает их мухи слона.
А вообще, это какое-то пустопорожнее теоретизирование. Все равно тут нет никого кто хорошо бы разбирался в ПДД США и был бы знаком с прецедентами в похожих случаях..
Людей которые ездят по встречке, такими мелочами не напугать.
Пассаж насчет количества приложений я вообще не понял. Вы же пишете некую общую библиотеку. Какая разница сколько приложений его используют?
Я не говорил, что нельзя, я говорю что это не проверяется автоматически и можно забыть.
Вот у нас есть есть 2 библиоткеки utils:1.0 и logger:1.0. Мы нашли неприятный баг в utils, быстро зафиксали его и надо зарелизить. Плюс у нас есть один готовый чейндж в logger и один ожидающий реализации для релиза logger:1.1.
И у нас получается выбор: релизить только utils:1.1, забив на то что мы еще получаем полурелизный logger в VCS теге. Или делать предрелиз logger:1.1/2. Оба варианта не смертельны, но кривоваты с т.з. жизненного цикла.
Раз уж мы подняли эту тему, объясните что вы получили сэкономив один модуль?
Если они действительно независимы — то это будет проверено на уровне компилятора. Если есть зависимость, то она будет явно прописана и видна в pom.xml.