Про "служебные адреса" не совсем так. Их не существует на самом деле, это кто-то из пользователей решил что "а давайте будем использовать 0xdead" для сжигания. Это мог быть любой другой набор цифр, так же как многие используют 0x0000 для этого. Можете отправлять на 0x0001 и т.д., будет тот-же эффект. Это просто очевидно несуществующий адрес.
А для создания контрактов не использует адрес вообще, т.к. это не 0x0000 а вообще ничего (null).
Я как-то ездил в Китай у меня были проблемы с доступом в интернет несмотря на то что я подготовился с VPN и купил сразу несколько. Каждый новый VPN работает минут 15-30 до того как будет заблокирован. Видимо DPI так работает. На следующий день, правда, есть шанс что какой-то из заблокированных VPN оживет.
Но главная проблема не в этом, а в том что даже если у тебя есть работающий VPN то внешний интернет почти бесполезен из-за скорости. Как в модемные времена было, каждую страницу ждешь по паре минут. Это сразу отбивает желание. Но на базовые коммуникации, типа e-mail, telegram и пр. хватает.
А у вас есть данные по популярности Cucumber vs Spock Framework для BDD? Может быть я не прав, но мне кажется что Spock более популярен, но вы упомянули лишь Cucumber
Наверное я неправильно выразился. Я не имел ввиду что проекты не должны иметь проблем. Разве что в идеале, который не достижим.
Я про то что монорепа это костыль для проектов с проблемами в архитектуре. Наверное можно решать проблемы этим костылем, Яндекс же решает.
Я говорю что про то что не вижу причины осознанно полагаться на такой костыль. И считаю что лучше стремится к исправлению проблем, а не заметанию их под диван. Что, конечно же, не отметает тот факт что в легаси проектах проблемы все равно накопились.
Все что вы описали это же и есть проблемы в архитектуре? Такого не должно быть в нормальном проекте. Я понимаю что в легаси проекте и кровавом интерпрайзе так иногда бывает и приходится с этим жить. Но тем не менее, монорепа это не не решение а заметание под диван.
Ну вот, вы же сами согласны что "так и нужно делать с точки зрения кода".
У каждого сервиса обычно свой API для взаимодействия, мне даже непонятно как можно так сделать чтобы они были настолько неделимы. Быть зависимостью да (= требовать в проде "версию API не менее"), но иметь размазанную фичу это что-то странное имхо
Если у вас фича размазана по 10 сервисам то наверное это значит что с архитектурой что-то не то? и забинтовано монорепой что-бы выглядело что так и надо
Это наверное зависит от законов и исторических протоколов каждой страны. Но в общем, насколько я понимаю, это сводится к тому что продавец отправляет банку "мне дали вашу карту НОМЕР + ДАТА + КОД на ИМЯ + АДРЕС, вы подтверждаете перевод нам $99 в течении 30 дней?" И банк отвечает ДА или НЕТ. Если ДА то можно считать что адрес более менее правильный. Если НЕТ то может быть что угодно, в том числе что у банка плохое настроение. Или денег нет. А может быть адрес не правилен. И вряд ли им банк скажет что именно не так. А как банк умеет сверять адрес в разном написании это уже его проблемы и риски.
Я не знаю с чего вы взяли что в этом случае у Apple возникнут вопросы. Вы же согласились что текст нужно трактовать как "адрес карты совпадает с адресом где зарегистрирована компания". В вашем случае все совпало и значил проблем нет.
Если вы введете неправильный адрес (не тот который вы сообщили банку для привязки карты) то платеж не пройдет. Но это зависит от банка, наверняка есть банки которые толком не проверяю.
Регион банка, кстати, не имеет значения. Поэтому что карта привязывается к адресу компании, и этот адрес может быть где угодно, в том числе в другом регионе. И даже в другой стране.
Корутины тоже потребляют пропорционально количеству одновременно обрабатываемых данных
Наверное мы делали что-то не так, но из коробки у нас так не получилось.
И утверждение ... я вижу сомнительным.
Я рассказал свой опыт переписывания реальной высоконагруженной системы на разные архитектуры. Зачем бы я вам врал?
У вам может быть другая архитектура приложения, другие задачи, другая нагрузка и другие компетенции команды, поэтому ваш опыт может отличаться. Лучше напишите об это, это будет полезней для всех.
В США при оплате картой спрашивают адрес, или как минимум индекс. Даже последнего может быть достаточно чтобы заметить что карта не совпадает с адресом указанным при регистрации.
Похоже на упущенное обратное давление (backpressure) либо некорректную отмену...
Да, вы правильно заметили основной посыл моего коментария
Вы хотите сказать, что все эти лямбды не потребляют памяти и никак не нагружают gc?
Потребляют, но пропорционально количеству одновременно обрабатываемых данных.
Каналы же как раз для этой цели сделаны.
Да, именно про это я и написал. Что после переписывания на каналы заработало гораздо быстрее. Но все это было все еще в 7 раз медленней тупого кода на Reactor. К этому времени код с корутинами стал выглядеть совсем страшно и весь смысл корутин пропал раз все равно каналы. Было решено переписать на стандартные потоки.
Про "служебные адреса" не совсем так. Их не существует на самом деле, это кто-то из пользователей решил что "а давайте будем использовать 0xdead" для сжигания. Это мог быть любой другой набор цифр, так же как многие используют
0x0000для этого. Можете отправлять на0x0001и т.д., будет тот-же эффект. Это просто очевидно несуществующий адрес.А для создания контрактов не использует адрес вообще, т.к. это не
0x0000а вообще ничего (null).Я как-то ездил в Китай у меня были проблемы с доступом в интернет несмотря на то что я подготовился с VPN и купил сразу несколько. Каждый новый VPN работает минут 15-30 до того как будет заблокирован. Видимо DPI так работает. На следующий день, правда, есть шанс что какой-то из заблокированных VPN оживет.
Но главная проблема не в этом, а в том что даже если у тебя есть работающий VPN то внешний интернет почти бесполезен из-за скорости. Как в модемные времена было, каждую страницу ждешь по паре минут. Это сразу отбивает желание. Но на базовые коммуникации, типа e-mail, telegram и пр. хватает.
А у вас есть данные по популярности Cucumber vs Spock Framework для BDD? Может быть я не прав, но мне кажется что Spock более популярен, но вы упомянули лишь Cucumber
Наверное я неправильно выразился. Я не имел ввиду что проекты не должны иметь проблем. Разве что в идеале, который не достижим.
Я про то что монорепа это костыль для проектов с проблемами в архитектуре. Наверное можно решать проблемы этим костылем, Яндекс же решает.
Я говорю что про то что не вижу причины осознанно полагаться на такой костыль. И считаю что лучше стремится к исправлению проблем, а не заметанию их под диван. Что, конечно же, не отметает тот факт что в легаси проектах проблемы все равно накопились.
Все что вы описали это же и есть проблемы в архитектуре? Такого не должно быть в нормальном проекте. Я понимаю что в легаси проекте и кровавом интерпрайзе так иногда бывает и приходится с этим жить. Но тем не менее, монорепа это не не решение а заметание под диван.
Ну вот, вы же сами согласны что "так и нужно делать с точки зрения кода".
У каждого сервиса обычно свой API для взаимодействия, мне даже непонятно как можно так сделать чтобы они были настолько неделимы. Быть зависимостью да (= требовать в проде "версию API не менее"), но иметь размазанную фичу это что-то странное имхо
Если у вас фича размазана по 10 сервисам то наверное это значит что с архитектурой что-то не то? и забинтовано монорепой что-бы выглядело что так и надо
А Шаг 3 точно имеет смысл делать на каждой машине? Может это можно на роутере это настроить один раз для всех?
Это наверное зависит от законов и исторических протоколов каждой страны. Но в общем, насколько я понимаю, это сводится к тому что продавец отправляет банку "мне дали вашу карту НОМЕР + ДАТА + КОД на ИМЯ + АДРЕС, вы подтверждаете перевод нам $99 в течении 30 дней?" И банк отвечает ДА или НЕТ. Если ДА то можно считать что адрес более менее правильный. Если НЕТ то может быть что угодно, в том числе что у банка плохое настроение. Или денег нет. А может быть адрес не правилен. И вряд ли им банк скажет что именно не так. А как банк умеет сверять адрес в разном написании это уже его проблемы и риски.
Я не знаю с чего вы взяли что в этом случае у Apple возникнут вопросы.
Вы же согласились что текст нужно трактовать как "адрес карты совпадает с адресом где зарегистрирована компания". В вашем случае все совпало и значил проблем нет.
Если вы введете неправильный адрес (не тот который вы сообщили банку для привязки карты) то платеж не пройдет. Но это зависит от банка, наверняка есть банки которые толком не проверяю.
Вы вводите адрес карты при оплате как поле "billing address"
Я уверен что это ошибки перевода и правильно было бы "адрес карты совпадает с адресом где зарегистрирована компания".
Нормальный банк такой платеж не пропустит. Выдаст ошибку что адрес не совпал с тем что у них в базе.
Регион банка, кстати, не имеет значения. Поэтому что карта привязывается к адресу компании, и этот адрес может быть где угодно, в том числе в другом регионе. И даже в другой стране.
Так как я же про это и написал, что вы сами указываете это в форме оплаты. Если вы ввели другой адрес - банк не проведет платеж.
Ну вот значит они хотят главную карту компании, выданную на основной адрес.
Адрес в номере карты конечно не задан, хотя бы потому что банк без проблем позволяет менять адрес уже выданной карты.
Наверное мы делали что-то не так, но из коробки у нас так не получилось.
Я рассказал свой опыт переписывания реальной высоконагруженной системы на разные архитектуры. Зачем бы я вам врал?
У вам может быть другая архитектура приложения, другие задачи, другая нагрузка и другие компетенции команды, поэтому ваш опыт может отличаться. Лучше напишите об это, это будет полезней для всех.
В США при оплате картой спрашивают адрес, или как минимум индекс. Даже последнего может быть достаточно чтобы заметить что карта не совпадает с адресом указанным при регистрации.
Да, вы правильно заметили основной посыл моего коментария
Потребляют, но пропорционально количеству одновременно обрабатываемых данных.
Да, именно про это я и написал. Что после переписывания на каналы заработало гораздо быстрее. Но все это было все еще в 7 раз медленней тупого кода на Reactor. К этому времени код с корутинами стал выглядеть совсем страшно и весь смысл корутин пропал раз все равно каналы. Было решено переписать на стандартные потоки.