Когда имеют дело с анализом машинного обучения - то смотрят обычно на графики.
Вот ты говоришь - эффективнее. Значит у тебя где-то в коде должна быть величина
эффективности и эта величина должна участвовать в алгоритме в роли фитнеса или
в роли какого то подкрпепляющего воздействия.
Твой код скорее всего никто не будет смотреть и запускать. Это too much для хабр
формата. Но ты должен предоставить вопрос так чтобы было понятно где ты ошибся.
Иначе выглядит как будто ты много-много нафантазировал или тебе ЧятЖПТ написал
а мы должны тут провести аудит.
Ты будешь играть в викторину? Почему ты не распечатаешь нам на экране стектрейс?
Process finished with exit code 1 - это следствие. Это код завршения процесса ОС.
Но причина не в нем. А причина как раз в исключении которое ты не посмотрел.
И не показал.
На самом деле это вопрос не простой. Он очень дискуссионный. Потому что есть очень много
разных ситуаций и контрактов которые столило-бы обсудить.
Поэтому я не сгласен МТС банк.
В реальном мире микро-сервисы и прочие сервисы лагают. Могут выдавать HTTP 40*, 50* ошибки
и все подниматсься из балансеров с рассинхроном или просто видеть старые данные.
Кирилл Красин, я думаю что хеширование на 100% закрывает все вопросы к тебе со стороны аудита.
Технические нюасны типа - а можно ли полным перебором по словарю имен найти емеил
и хеш - не будут звучать в повестке проверяющих органов.
Они попросят логи. Ты покажешь им что в логах никакого емейла нет. И на этом все.
По формуле вероятностей тут будет произведение верятности коллизии sha1 и md5 на твоем объеме данных.
Тоесть если раньше она была например 0.00000001 то в произведении будет соотвественно нулей после
зяпятой еще больше. И это уже - космос. Вероятнее тебя скушает акула чем такая коллизия выскочит.
Да. Нужно смотреть какие возможности у API-s всех участников SAGA.
Если некоторые из них работают по принципу queue, то мы ничего не поделаем.
Надо на уровне бизнеса договариваться обо всех возможных ситуациях.
Мой опыт подсказывает что программист сам не в состоянии принять
правильное решение на все-все случаи.
Atrial, актуальное на рынке - это сложно. Надо смотреть по вакансиям. И кроме того это актуальное
каждые 3-5 лет меняется. Вот были актуальные block-chains, internet of things, bigdata. Сейчас уже
вроде не актуальные. Я-бы не стал вобщем идеализировать рынок.
Во всех аудиоредакторах есть пороговое шумопонижение. Попробуй его. Там еще должны
быть параметры чувствительности по времени срабатывания. Тоесть короткие звуки
(удары диктофона об стол) можно тоже как-то давить хотя я тут точно не уверен.
Из софта я названий не помню. Давно я на такое смотрел. Уж лет 10 прошло. SoundForge? Cubase?
Часть из этого может стоить денег.
Покупать тебе сразу лицензию на Cubase не стоит. Поищи знакомого звуковика с софтом
чтоб попробовать на его десктопе что-то сделать. Будет ли польза - ХЗ. Надо
много пробовать.
Вот ты говоришь - эффективнее. Значит у тебя где-то в коде должна быть величина
эффективности и эта величина должна участвовать в алгоритме в роли фитнеса или
в роли какого то подкрпепляющего воздействия.
Твой код скорее всего никто не будет смотреть и запускать. Это too much для хабр
формата. Но ты должен предоставить вопрос так чтобы было понятно где ты ошибся.
Иначе выглядит как будто ты много-много нафантазировал или тебе ЧятЖПТ написал
а мы должны тут провести аудит.