Just.Doit

вообще я этого не говорил + я поменял немного мнение после плотной работы с питоном там в целом можно и jit и статические типы на практике мало кто этим пользуется и от того юзать это геморой тк корнеркейсы всплывают, заводится с трудом и тп. в итоге подавляющая часть экосистемы без типов и на интерпретаторе я если честно в шоке какое дегродство в питоне в плане нормальной разработки правда в следующей версии планируют добавить jit в стандарт имплементацию рантайма но появилось желание поскорее дропнуть это говно следующий кандидат это TS тк у нас это дефолт язык для того что мы сейчас пишем. Надеюсь, прокомментирует каждый пост там слишком лоулевел дебри и слишком с++ специфик я в этой хуйне не разбираюсь и не особо хочу разбираться на текущем этапе моей карьеры я бы сказал что у тебя очень специфичная ниша браузерной с++ разработки, и ГолдРобот просто может не понимать твоего контекста тк для невго все что быстрее джавы уже классно и перформанс, а глубже можно без нужды не разбираться еще хочу отметить что ГолдРоботу скидывают конкретный код и конкретные проблемы уже 3ий раз. а он никак не может объяснить как в его мире эти проблемы решаются. только кококо - надо все замокать

это невозможно протестировать, чел ты выще предложил простестировать последовательность, так? но ты тестируешь на конкретном прогоне. может у тебя там такой код что он на твоей и тестовой машине проходит в такой последовательности в 99.99999% случаев. и вот у тебя все зеленое но на самом деле дедлок возможен в этом и суть я согласен с тезисом что тестирование канкаренси ничем принципиально не отличается от тестирования однопоточного кода если очень абстрактно рассуждать. ты покрывая тестами однопоточный код тоже не можешь гарантировать что логика гарантированно корректная в многопотоке просто уровень проблем и количество возможностей и инвариантов кратно возрастают. настолько сильно возрастает сложность что все тестировать просто нет смысла. в лучшем случае какие-то отедльные сценарии и то в высокой долей недостоверности зеленого теста.

это и является ThreadSafeBank класс ну допустим там есть мутекс и мы проверили что он поднимается но чел написал чтение остатка на счете перед мутексом, и вот твой тест все тестирует. и даже бизнесовый flaky тест прогнан 1кк раз. вроде все хорошо потом штука запускается на арм процессоре и все идет в разьеб потому что гарантии на это чтение не было. ты опять не понял( ну ты вообще предлагаешь детали имплементации тестировать как дефолт подход что как бы говорит о твоем уровне

Так так так Ты намекаешь что с тестами однопоточных программ как-то по другому? на высоком уровне абстракции - нет но в канкаренси гораздо выше вероятность рандомных срабатываний и гораздо больше инвариантов, в этом плане оно сильно отличается от синхронного последовательного кода, где огромное количество инвариантов невозможны из-за гарантий последовательного выполнения и ты в целом можешь перебрать инварианты и протестировать их без особых сюрпризов и без особых навыков.

я писал код с подобными моками он позволяет засетапить некоторые инварианты и проверить их более менее достоверно но он опять не дает никаких гарантий кроме тех которые ты докажешь на бумаге, тк даже то что ты протестил и тест зеленый - может быть стечением обстоятельств я подозреваю что когда у тебя брейкпоинты - код работает совсем другим образом, тк кучи перестановок и оптимизаций будут отключены. более того, сами машинные инструкции могут быть переставлены ЦПУ

ну вот выше конкретной код покажи как надо ну твой подход что ты сначала должен понять как написать тред безопасный код, потом его имплементировать и потом проверить имплементацию написанного. собственной это мой поинт и был - ты не можешь протестировать поведение кода на то что он тред-безопасный сам по себе, ты можешь только это проанализировать, ты можешь протестировать тред-безопасную конкретную имплементацию, залехая в кишки имплементации метода. и в конце концов ты протестишь некоторые инварианты, но твой код все еще может быть не тред безопасным потому что твоя имплементация не корректная и ты протестировал ее кишки (мутексы замокал и тп) но не сам метод, и там гдето скрылось одно чтение без барьера и будет тебе ебать весь метод вон как грофух описывает. про что и речь собственно собственно нихуя не понял ты и пошел выебываться ты тож не понял про что толкуем? давайте на конкретном примере Есть вот класс Bank у него есть методы: def moneyPutByAmt(account, amount): Error | OK def transfer(fromAccount, toAccount, amount): Error | OK def getAccountBalance(account): Int известно что все эти методы могут хуяриться в параллель как угодно как написать тест чтобы проверить их потокобезопасность?

Ну обмаж свой первый пример мютексом. Посмотри на него. И возможно поймешь. А если не поймешь, напиши сюда, ребята объяснят. чел речь не про то как написать корректный код речь про то что ты говоришь что можно легко такой код протестить как ты будешь его тестить?

Тест должен проверять не "работает" или "не работает", а то что поведение ожидаемо, и результат совпадает. Почему мне это объяснять то нужно вообще? Если ты тестируешь трейд сейфети, то ты и будешь покрывать тестами отсутствие дата рейсов. А не то что оно скомпилилось. Внезапно, примитивы синхронизации можно мокнуть. Заменить и подменить в тесте. Так же как и источники проблем, по типу сокетов и таймеров, для воспроизведения реального кейса. Это не считая хотя бы попросту кланговских санитайзеров, которые не идеальны, но очень хорошо упрощают жизнь. Твоя идея того что внезапно std::mutex отьебнет на какой-то платформе, или компиляторе, конечно, революционная, я такое даже представить себе не мог. Но думаю если стандартные примитивы не работают на платформе, то проблема некорректной работы с ними, будет уже наименьшей из моих головных проблем. Такое делает один из моих коллег переодически, я же ебал в рот это по причинам которые изначально написал. В большинстве задач у нас это либо оверкил, либо усложняет код настолько, что он превращается в неподдерживаемое легаси сразу после релиза, к сожалению. попытаюсь объяснить тупенькому вот у тебя есть код в мейн треде var isReady = false var a = 0 var b = 0 и далее запускаются 2 треда Тhread1: var a = 1 var b = 1 var isReady = true Thread2: while(!isReady) { sleep(1) } print(a, b) Ожидаемое поведение - второй поток напишет (1, 1) Как это протестировать? могу для тебя на мутексах написать. там тоже есть конкаренси проблемы которые я хз как ты будешь тестить другой пример есть инициализационный код (мейн тред) var accountA = 100 var accountB = 0 и в два и более потока хуярятся операции перевода с одного аккаунта на другой потипу: if (accountA>= 100) accountB+= 100 как ты протестируешь такой код? как напишешь тест?

ты вообще не о том, дурачок

ты когданить пробовал покрыть тестами датарейсы или рейскондишн? ну ты же плюсовик. у вас там UB везде, так? но ты можешь часто на конкретном компиляторе, на конкретной платформе заюзать UB которое будет работать 100% корректно. но это тем не менее UB вот тут также я хз как объяснить что канкаренси поведение протестировать невозможно без целой лекции на тему

ну ты сколько не тестируй это не даст гарантий что завтра на процессоре М123 или версии платформы джава100500 не ебанется по причине того что код не корректный ну я согласен что в теории ты можешь протестировать 1 миллион разных вариантов окружения (по нагрузке, по компиляторам, по платформе, по цпу, по ос и тп) но это уже не целесообразно просто Unsafe это за пределами спеки, а вот https://openjdk.org/jeps/193 как раз спека. Вообще хорошо что много хитроебства становится частью стандарта, как тот же байткод ЖВМ. хм. а хули тогда чел говорит что этого в спеке нет а из документации - пост дога ли, даже не дока оффициальная какая-то Unsafe это за пределами спеки, а вот https://openjdk.org/jeps/193 как раз спека. Вообще хорошо что много хитроебства становится частью стандарта, как тот же байткод ЖВМ. то что ты скинул не содержит ни слова про эти 2 семантики

напишу тредсейф обертку чтобы были h-b отношения с корректными инвариантами хотя лучше просто не буду юзать это говно (библиотеку) по возможности Не обязательно полю быть volatile, иногда переменная может быть библиотечная например, что делать будешь? ебать эти ебоклаки еще и за пределы спеки вышли нахуй вообще спека нужна тогда блять да только вот когда возникнет проблема уровня "надо пойти посмотреть сорцы, понять как работает и возможно запатчить либу" чел даже не поймет что такое возможно и будет засыпать код рандомными костылями или переписываниями пока проблема не уйдет или все не забьют на нее

Пиши код с минимумом точек синхронизации, конкарент-агностик вещами (типо го/корутин или реактивщины), пиши чистые функции и будет тебе счастье. По факту в энтерпрайзе вся параллельщина заключается в том чтобы форкнуться на N I/O за данными а потом awaitAll чтобы собрать модельку и кинуть на другой слой. CPU параллелизм я в своей промышленной практике не встречал. бтв дико плюсую низкоуровневые примитивы почти не нужны только если ты не ебошишь высокооптимизированный HFT и делаешь это почему-то на джаве

Это правда пишет наш немецкий разработчик? готов спорить что ты в этом обосрешься с подливой

сложно начать думать в терминах не что будет, а что может быть в канкаренси проблема в том что невозможно протестировать. тк вещи вероятностные и могут давать сбоящий вариант только при определенной нагрузке или раз в 1млн случаев можно только доказать теоретически. ну либо забить на сбоящие случаи если последствия не критичные встречаешься постоянно, тк базовые вещи есть везде - 2 конкуретных запроса - надо понимать что может быть. не обязательно в коде асинхронно писать. в принципе любые 2 процесса происходящие одновременно могут конфликтовать для джавы базу важно знать в любом случае как бы можно быть спринг-девелопером и жить себе спокойно, но компетентный разраб должен хотябы базу понять, чтобы понять что могут быть прорблемы и надо обратится к канкаренси гуру. я видел очень много примеров когда челы не понимают и обращаются к переменным из разных потоков которые даже volatile не обозначены, не понимают что такое thread safe и тп. если ты написал объект - ты должен понимать из каких потоков он может быть вызван и что при этом может происходить

а в чем проблема что перекатывается все приложение? это делается без простоев, green-blue deployment, просто процесс обновления инстансов в чем сложность или проблема? я спорю с тем что микросервисы это единственный путь решения обозначенных тобой проблем и тем что монолит сам по себе является их причиной, также как с тем что "очевдино" что МС решают их эффективно - не факт что решает вообще - то что ты пишешь решается и в монолите, это менее популярно и меньше готовых наработок, но это лишь вопрос популярности и готовности экосистемы, а не неразрешимости проблем с использованием монолита - большинство проблем которые решают МС это организационные проблемы так что применимость и оправданность МС сильно зависит от размера отдела разработки, а не от технических требований

ну запускаешь и они работают также как у одного микросервиса несколько инстансов ты можешь делать модули в монолите точно также независимыми я про что и толкую. ничто не мешает тебе делать зависимые микросервисы и независимые модули монолита. вопрос не в сервисах а в модульности

чето ты хуйню поришь если у тебя встал 1 инстанс монолита - все остальные работают если у тебя встал микросеврис - если они написаны через жопу - встали все зависимые микросервисы ну и "в эксплуатации и поддержке" выигрывают только если у тебя хотябы 5+ команд если у тебя 1-2 команды мионолит выигрывает в эксплуатации и поддержке вот это настоящий признак вора в законе конеш

Какое кресло выбрать чтобы геморрой не беспокоил? никакое надо к практологу сходить и больше двигаться не из технических зачастую из оргструктурных обычно ну какбудто ты не видел микроговно которое падает если другой сервис недосутпен и если он залочился - оно падает тоже и так по цепочке точно также как ничто не мешает написать монолит так что ты ожидаешь что другие модули/компоненты сбоят и у тебя этот кейс обрабатывается

эм почему тебя это ебет? ты спрашиваешь по учебнику вопросы? может стоит не хуйню спрашивать а что-то похожее на реальные проблемы? в смысле можно так уже дохуя кто делает транслируется в чатгпт все автоматом и выдается на тот же монитор уже слышал кулстори от коллег кто натоклнулся на такое

ну сейм щит когда ты руками будешь вводить че теперь, ставить арч линукс и 3 слоя защиты от всех возможных рисков? как блять так че за общие слова ты сказал браузер хранит в открытом виде где инфа как это хранится как именно инфостиллер работает в плане паролехранилки хрома? беглый гуглине: https://superuser.com/questions/146742/how-does-google-chrome-store-passwords на винде зашифровано на маке тоже https://security.stackexchange.com/questions/254692/safe-or-unsafe-to-store-passwords-in-chrome-on-macos кароче я хз о чем ты блять говоришь то что нет мастер пароля? а нахуя? если ты из под винды это юзаешь и подразумеваешь атаку на винду - тогда какая разница спросит у тебя винда мастер пароль и потом заиспользует или возьмет свой внутренний ключ и его заиспользует. уровень безопастности почти идентичный единственное что тебя защитит это физический ключ но я ебал ходить везде с флешкой, я не член алькаиды чтобы какие-то повышенные риски иметь

Особенно у хромиума крутая автозаполнялка все в открытом виде хранит кинь линк где прочитать про это

ставишь туда заполнялку паролей ну а вообще у тебя доступ до паролей то есть, вводишь как обычно на новом устройстве. не понял в чем у тебя проблема

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

никто этого не может гарантировать, как и то что твой пароль не логируется где либо ты можешь смело полагать что твой пароль на пд будет доступен админу пд или любому кому он решит слить базу пд