mayton2019

Данная задача не решается в рамках CrudRepository.

Архитектурно. Для крупных систем если кто-то хочет искать произвольный текст (fuzzy text search) по вводимому выражению наподобие гугло-поиска специально подключается Apache Lucene или ELK stack. В него реплицируется искомая табличка и далее уже по этой реплике выполняются все текстовые сёрчи.

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

Попробуй замени запрос на такой

@Query("select a from Advertisements a")

Если отработает ОК - то добавляй по одному предикату. Последовательно найдешь какой неправильно написан.

Есть опенсорцная библиотека Tesseract. Как обращаться к ней напрямую из Python я не знаю. Но возможность такая должна быть. Убежден.

ext4 не поддерживает объединение в логические тома. Если-бы при устанвке был использовал LVM (хотя это боян еще тот) или файловые системы такие как BtrFs, Zfs тогда эту операцию можно было-бы провести. Конечно обязательно проконсультиоровавшись с знакомым сисадмином. Тут основная беда в том что это опасные операции и необратимые. Любая ошибка - и ваши данные потеряны причем на многих разделах сразу.

А так... подключите /dev/sda4 просто как папку например /video и используйте.

При такой постановке - действительно ничего нельзя сделать. Просто он не предназначен для таких операций. Но хотя-бы первый раз его надо затянуть в базу. И всегда там хранить эти данные и там-же обрабатывать.

Если писать под Windows то наверное лучше брать .Net - фреймворки. Они более нативные и как следствие
имеют богаче возможности конкретно под Винду.

Java сегмент разработки UI не захватила. Я сужу по количеству вакансий. И сегодня нужно быть очень смелым и дерзким чтобы что-то писать на десктоп под Java.

Хотя есть альтернативные направления (Android) но я к сожалению не специалист в нем и как там - не знаю.

В 99% случаев программисты являются пользователями чужого кода. А для этого им не нужно погружаться в имплементацию. По хорошему нужно понять назначение библиотеки. Ее API. И посмотреть модульные тест-кейсы как она тестируется. Там будет очевидно применение.

Поэтому автору не нужно разбирать код. Тем более что для современных проектов код перевалил за сотни мегабайт (на минуточку Война и Мир занимает едва-ли 5 мегабайт) и изучать его весь безсмысленно.

По конкретно формату mkv. Это аналог xml только бинарный. Его не надо крякать или ломать или реверс-инжинерить код. Это совершенно открытый формат. Его спецификация опубликована. И чтение ее даст больше пользы чем ковыряние кода. Поймешь спеку - и сразу будет понятно что код делает.

Значит до того как автор начал что-то мерять. Обычно такая задача ставиться в поиске узких мест в приложении. В данном конкретном случае - узкое место это работа с cout. Ее надо устранить и заменить на работу с файлами. Или просто уменьшить объем трафика который пройдет через cout. Вообще нет особого смысла так часто печатать что-то на консоль. Всё равно человек глазами так быстро не видит. Бешеный скрол экрана не имеет смысла кроме того еще и потребляет ценные мега-флопы.

Вообще непонятно зачем тебе /tmp и /archive задача вполне себе решается на базе той структуры что уже есть.
Тебе-же не надо хранить всю историю ответов от "рождества Христова"? Текущий response сравнивай на "лету".

Здесь главный и ключевой вопрос - собирается ли автор разрабатывать своё ПО. Это один путь. Он тяжелый и нудный. Тем что нужно сеть обучать на базе своих фотографий. И есть второй вариант - просто купить готовое решение на базе SaaS решений которые уже продаются. Это совсем другой путь. Но там результат может быть быстрее.

Если знать реальные ограничения на бизнес-данные то может оказаться что массив-массивов тоже не нужен и всё сводится к матрице фиксированного размера. Также таплы и кортежи фиксированого размера формулой сводятся вообще к массиву одномерному.
int get(vector<int> v, row, column, elem)

Новиков - Дискретная Математика для программистов.
Оре - Теория Графов (это классика которую все должны были зубрить в универе)

Очень сильно не нравится эти игры с разрядностью char.

sizeof(key) / sizeof(char)

Код на С++ написан гетерогенно по отношению к длине символа. Тоесть предполагается что если он будет 1 байт то будет одна логика а если 2 байта то другая. Это очень серъезный gap в архитектуре и его надо обсуждать. Вообще шифрующие алгоритмы пишутся на байтах а не на символах. И оптимизируются соотвественно. Библиотеки CryptoApi и OpenSSL будут в помощь. Надо опираться на них а не на кустарные складыватели по модулю два которые к шифрованию не имеют отношения.

Безсмысленно изучать в Java-технологиях всё подрят. Вы утонете. Сегодня библиотек и фреймворков настолько много что вам хватит до конца жизни. С практической точки зрения полезно изучать Spring Boot и все дочерние технологии в этом домене. Так вы с гарантией пройдете 80% собеседований. Но еще лучше открыть местную газету и почитать открытые вакансии в вашем регионе. И целенаправленно узнать что требуется.

Мне кажется самый надежный вариант - распечатать в файл. В виде картинок. И показывать из приложения картинки. Так хоть есть гарантия что формулы и графики сохрянят пропорции и не потеряются. Все остальные конвертеры - могут что-то сломать или потерять.

Можно посмотреть ассемблерный выхлоп для обоих вариантов. diff между двумя ассемблерами прояснит суть проблемы.

В Groovy и Scala есть возможность делать переносы без кавычек в каждой строке. Это так называемые multiline. В Java тоже запланирован JEP не помню в какой версии.