mayton2019

Правильный ответ - нет. Функционал регулярок - это найти и указать найденное. Вы можете посмотреть как работает Pattern/Matcher в паре. Они просто находят группы выражений и указывают пальцем дескыть вот здесь матчинг подошел.

Но есть API языков программирования такой как String::replace который позволяет с ИСПОЛЬЗОВАНИЕМ
регулярок найти-и-заменить одной операцией.

Но данную конкретную операцию - капитализацию первой буквы в Java-строке я-бы сделал просто через substring() и toUpper(). Это будет по времени в сотни раз быстрее т.к. мы не будем вовлекать в процесс компилляцию паттерна регулярок. Грубо говоря если ты решил пальнуть по птичкам - то бери рогатку. Пушка тебе не нужна.

Не все MicroSD-шки одинаковые. Есть понятие класс скорости. У них на корпусе написано в кружочке:

class(4)

например.

Эту карточку выкинь. Она тебе не подходит. И купи классом повыше.

В топике - правильно пишут. Не надо жадничать. Покупай нормальный товар а не по цене мусора.

Надо читать полный прейскурант продаваемых Яндексом виртуалов. Я думаю что гарантии по скорости и доступности ssd блинчиков просто учтены в цене на саму виртуалку. И надо просто доплатить денег.

У вас у всех в коридоре висит идеальный ваттметр. Электросчетчик. Заменяйте его показания с включенным ПК за интервал времени и заменяйте с выключенным. Дальше - школьная арифметика.

По надежности рантайма - хорошо идёт Erlang. Он способен накатывать патчи без ребута приложения. Его даже не рекомендуют запускать в докере т.к. его преимущества теряются из-за контейнера.

По надежности языка разработки - согласен с предыдущими ораторами насчет Ады. Но насчет перспектив - я ХЗ. Не знаю как там для современной разработки.

Современная восходящая звезда надёжности фазы компилляции - это Rust. Его изначально создавали с целью фиксить дефекты С++. Просто на основании опыта накопленного в Mozilla. И на основании анализа уязвимостей из тех которые уже были внедрены в код Мозиллы из за фундаментальных дефектов языка С++.

Тема интересная. Находится на стыке развития систем распознающих образы и обще-человеческой медицины.

Защитить - скорее всего можно. Только после этого фото станет недоступным для человеческого восприятия. Простые фильтры дисторсии (distort), бочка, подушка, кручение (twirl). Просто какие-то варпы, которые изменяют пропорции лица, например вытягивают глаза и прочее - могут сломать систему поисков по совпадению.

Но если вы решили играть в кошки-мышки с государством то ничего у вас не выйдет. Вас все равно поймают. А дистортнутые фотографии в вашей соц-сети просто будут вызывать удивление и подозрение.

Может если вы не хотите чтоб вас искали - то лучше наверное вообще ничего не публиковать.

Поэтому диклеймер - интерес этого топика - исключительно академический.

На алгоритмической сложности стоит вся современная криптография (https-соединения в браузере) и криптовалюты. Все они сегодня работают и существуют только потому что есть алгоритмы которые работают в одну сторону легко и быстро (нанесение электронной цифровой подписи) а в обратку - настолько туго и бесконечног долго что сама по себе генерация лже-подписи становится невыгодной злоумышленнику просто по временнЫм затратам.

А если говорить простыми словами то все подмножество алгоритмов делится на константные O(1) - это поиск в хеш-табличке. Логарифмические O(Log n) - это поиск в дереве или сортированной коллекции. Линейные - любой поиск в произвольнйо коллекции O(n). И дальше идут полиномиальные (это всегда цикл в цикле) экспоненциальные O(exp n). Здесь начинается криптография. И комбинаторные, в формулу которых входит факториал от N или еще апроксимируется O(n^n). Последние как-раз и создают тот самый класс нерешаемых наукой алгоритмов для которых пытаются строить квантовые устройства работающие совсем на других физических принципах.

В изменениях размера картинки действительно нет никакого смысла.
Кроме тех случаев когда у вас обучающая выборка - имеет разные размеры картинок. Тогда надо придумать какой-то общий усреднённый размер и масштабировать все картинки перед обучением. Делать это можно на лету или в оффлайне.

С градациями серого - может быть подвох. Разные формулы перевода вектора RGB-> Grayscale могут давать разный результат. Тут надо понимать что мы хотим получить. Просто усреднение по всем каналам. Или по формуле человеческого зрения где зеленый канал имеет наивысший коэффициент. В этом случае влияние зеленых шумов будет сильнее на результат.

Я не специалист в MySQL но обычно транзакция заканчивается командой commit.
Проверь где ты явно завершаешь (фиксируешь транзакцию) или у тебя в свойствах соединения должен быть включен авто-коммит. Хотя авто-коммит это плохой вариант если ты удаляешь много строк.

Здесь заложена потенциальная ошибка гонок. Главный и дочерний потоки не синхронизируются через объекты синхронизации. Это означает что если дочерний объект тупанул в фазе например JIT компилляции то главный его не будет ждать и завершит приложение. И мы можем (теоретически) не увидеть даже следов работы дочернего потока. Искусственные паузы sleep() не являются механизмом синхронизации и их не стоит использовать для той цели которую хочет достичь автор. Нужен нормальный join. Или ожидание финала ThreadPool.

1) Что такое data? Почему ты названия классов пишешь с маленькой буквы? Это вроде бы пустяк но это раздражает читающего твой код. Возникает подозрение об ошибке или о некорректной копи-пасте.
2) Очень сложно понять что ты хотел получить на выходе. Нарисуй образец желаемого документа в Json и тебе помогут быстрее.

Я думаю если автор сможет спрогнозировать например следующее число из какого-нибудь SecuredRandomGenetator - то весь мир криптографии вздрогнет.

Неважно там... нейросеть или просто какие-то стат-методы. Это будет прорыв покруче этих ваших взломов SHA-1.

Вобщем цена этой задачи - как минимум премия по теории чисел.

В третьей строке лога приведена ссылка на решение проблемы.

slf4j - это просто переходник. За ним стоит обычно любая имплементация. Например эта.

group: 'org.slf4j', name: 'slf4j-simple', version: '1.7.30'

Подключи ее в артифакты проекта.

Нужно понять от кого автор защищается. От лоха - да это прокатит.

1) Если диск будут смотреть специалисты - они увидят подозрительную разность в физическом объёме диске и доступное место на фейковом диске.

2) Я пока себе не представляю алгоритм. Симметричная криптография нигде не хранит ключ. Поэтому реализовать этот выбор фейковая-нефейковая мне пока не представляется никак возможным. Просто в случае кривого пароля у вас не поднимется никакая ОС.

А хранения пароля для проверки - противоречит тому о чем я писал выше.

Это видимо учебная задача. Практического смысла параллелизма здесь мало.

Обычная дисковая подсистема на домашнем ноутбуке состоит из 1 HDD/SDD. И он не параллелится. Тоесть это такое жлобское устройство которое в 1 момент времени может обслуживать чтение и запись 1 блока файловой системы (или сектора или кластера неважно). Поэтому параллелизм толком ничего не дает. Однако если у вас какие-то RAID массивы или сеть хранения данных то она может обеспечить такие действия.

Что еще в задаче плохо.

while(!InputFile.eof())
    {
      getline(InputFile, tmpString);
    }

Непонятно что здесь происходит? Перемотка в конец файла? Почему так дорого? Почему мы должны каждый раз получать строки? Ведь нам нужна только последняя? Может надо было взять первую? Вобщем непонятно.

Вот если-бы автор решал задачи наподобие map-reduce где работают с большими файлами тогда параллелизм был бы понятен. Там чтение блока файла чередуется в вычислениями.

Здесь вычисления - мелкие. И большая часть процессорного времени зря сгорит в старт-стопах потоков и в финальном join потоков (которые я кстати не вижу).

Тут наверное OpenCV не надо. Просто замерять цвета нескольких точек в течение 3-5 секунд (как фотик наводит резкость) и брать их среднее значение.

Этот алгоритм прост - как автомат Калашникова. А все что простое - работает быстро. Как будет работать OpenCV на Raspberri мне даже страшно представить. Скорее всего плохо т.к. OpenCV проектировалась сразу для сильного железа а Распберри это больше игрушка для энтузиастов чем платформа для видое-обработки.

Это Груви? Как это вообще скомпилировалось? Справа что стоит? Символ или строка?

value = value.replace(' ','');