mayton2019

На самом деле никто в QNA не знает какие вопросы тебе надо решать. И для кого эта линия L2?
Физлица? Или корпоративные клиенты? Отсюда также непонятно зачем тебе .... чить Линукс.

Скорее всего у тебя будет инструкция. Нам будет написано как отвечать и куда переключать клиентов.
У тебя скорее всего будет сайт типа базы знаний по провайдеру. Там будет вся информация.

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

За упаковку ресурсов отвечает плагин maven-resources-plugin. По умолчанию он включен всегда.
Он является частью общего конвейера сборки и реагирует на process-resources phase.
Его наверное можно отключить настройкой этих реакций. Но я не советую. Скорее всего
вы сломаете логику работы программного продукта.

Если вы разработчик - создайте отдельн бранч где удалите все ресурсы и попробуйте с ним поработать.

Если у вас есть jar то вы можете его перепаковать просто удалив ресурсы.

Обычно для конкатенации строк используют не сложение а специальный билдер.

Вместо
String hhh = new String("qwe");

пишут
StringBuilder sb = new StringBuilder("qwe");

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

Можно попробовать расширять текстовый запрос по такой формуле

вов => "вов OR wow"

Здесь преобразования достаточно простые.

По поводу world of warcraft => warcraft я не согласен. Это вообще другая игра, поэтому и результат поиска будет не верный. Хотя это на откуп автору. Если его база содержит только игры последних лет то пускай комбинирует слова через or.

Хранить можно все что угодно. Это нормально. Другое дело что перед процессингом
документа очень желательно прогнать антивирусом каждый файл хотя-б один раз.

С точки зрения современной инфо-безопасности docx является опасным. Макросы...
И даже если вы не будете открывать этот файл в Windows а только в pHPOffice - все
равно подстраховаться надо.

Коробочное решение удаленного доступа - это 99% SSH. Настроил и компилируй себе в командной строке.

Но спешу заметить что если ты вздумал ходить домой с работы то это сразу - security issue.
Я не знаю какая инфо-безопасность у вас и откуда ты вообще собрался ходить но практически
все утечки и кражи информации начинаются именно с твоего сценария.

Задача декомпозируется на 3 подзадачи.
1) Выбрать список строк из json
2) Перевести
3) Вставить перевод обратно.

По пункту (1), (3) есть API JSON path, Json Document или ему подобный. Почти для всех языков это уже решенная задача.

По пункту 2 лучше взять онлайн Rest API машинного перевода. Например от Google.

Очень сумбурно автор описал. Многое из контекста непонятно. Вроде сам решил применить Postgres.
Ну ОК. Решил так решил.

И как по ПК можно выбрать 100 записей? Сделать 100 запросов? Или это не-ПК? Непонятно.

Вообще ни один производитель СУБД ничего не пишет про отклики. Это можно обсуждать
например в контексте приложения redis/web-server/dbms и там что-то придумывать и обосновывать.
Отклик - это сложная сумма которая состоит из множества слагаемых и не всегда БД там главная.

Вообще сама идея или само обоснование NoSQL (AWS Dynamo,. Azure Cosmos DB) идет как раз
от гарантий что вендор будет давать пропускную способность и отклик пропорционально вашей
оплате. Вы покупаете условно например какое-то количество RU (Request-Units) и все облако начинает
подстраиваться под вас таким образом чтобы соблюдать рост и независимость от размера данных.

Все что касается других (single-node, standalone) систем то они обычно быстро достигают пика
либо на диске либо на сети и после этого уже про отклик нельзя ничего говорить. Даже вкупе
с индексом все равно есть определенная деградация. И вы очень смелый человек если
сразу стали что-то стали чертить на базе реляционной системы.

Вообще если вы решили обсуждать например системную архитектуру то можно отбросить БД
и зайти со стороны философии и требований. Например лет 20 назад мы все знали что дисковая
подсистема на основе 1 магнитного диска обеспечивала скорость поиска блока в 15 мс.
Это так называемый random seek. И эта величина очень долго стоит как стена. Не
двигается особо даже для современных HDD. Механика чорт ее дери...

Для поиска любой записи в индексе вам надо сделать 4-5 seek по диску при условии что
мы диск полностью заполнили. Тоесть получается что быстрее чем 55 милисекунд мы не можем
гарантировать поиск записи по ПК для БД на магнитном носителе. Про SSD тоже можно
порассуждать. И в контексте бенчмарков в самом неблагоприятном состоянии.
Диск может быть заполнен на 99% например по размеру. Почему нет? Всяко бывает.

Вот так. Философски рассуждая мы можете вообще начать разговор. А уже какая там БД.
Tarantool, Cassandra, LevelDB это уже как-бы детали к системной архитектуре.

Ты задаешь вопросы в основном по абстрактным классам. А в них обычно нет ничего интересного.
И размер буфера это как раз особенности реализации в наследнике.

Для буферизации InputStream можно использовать такую обертку.

BufferedInputStream strm = new BufferedInputStream(new FileInputStream("file"), 128 * 1024);

Попробуй так:

create table "mytab"("COL" text, "CamelCase" text);

Автор мне кажется ты решаешь две разных задачи.
Первое - кольцевой буфер. Его не надо сортировать и его API
обычно очень простой. Это блокирующие push/pop или там атомарный
peek или проверка на пустоту. Они работают быстро и в этом их преимущество.

Если ты задумал очереди с приоритетами то посмотри например пирамиду (heap).

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

Разумеется можно формировать любые таблицы и документы. Только к ним нужно
относится с большим подозрением и проверять все в том числе и цифры.
При таком double-check я думаю что ИИ автоматизация теряет смысл.

Уж лучше формировать отчетность теми средствами как вы делали раньше.

А AI можете использовать для генерации писем.

Например x1y1z1=c1, а x2y2z2=c2

Вы не можете проверить саму формулу. Ее смысл не вытекает ниоткуда. По краейней мере для вас.
Об этом писал Курт Гёдель. Формула корректна потому что она нам дана таковой.

Но вы можете как тестировщик проверить ее реализацию. Обычными тестами или тестами свойств.
Property-Based-Testing (PBT)

Для PBT обычно вы подаете на вход рандомные значения и проверяете что выполняется какой-то
инвариант. Например если формула дает площать фигуры - то площать всегда не отрицательная.
Или Например если это площать круга - то она всегда будет меньше например площади
описанного квадрата. Это грубая проверка но она позволяет по крайней мере очень быстро
доказать что нет грубой ошибки.

Какие конкретно придумать свойства для тестирования - это ваша задача. Спросите бизнес.
Например если вы тестируете банковский кредит то инвариантом должна быть прибыль.
Тоесть при любых допустимых параметрах выгода от кредита должна быть в пользу банка.
Это КМК самый лучший инвариант что можно придумать.

Если типы данных у вас - вещественные то все формулы в тестировании проверяются не на точное
совпадение а с допуском (эпсилон) который вы описываете в asserts:

assert ( x * y * z == c, ε = 0.000001 )

для всей области определения x,y,z

В качестве фреймворков для Java/Scala есть соотвественно jqwik, scalacheck

Я-бы свел обе фигуры к объединению трапеций. Это легко сделать обходя все точки.
После чего булевы операции можно делать над трапециями.
Результат - снова объединить в фигуру.

Я думаю можно. Но действительно ли вам нужна нейросеть? Может Elastic Search или Sphinx
закроют все потребности?

А нейросети обычно выдают не точные а вероятностные ответы. И если с текстом еще хорошо
то с цифрами там могут быть сильные неточности. Поэтому как бухгалтерия это точно не пройдет.

Эту задачу можно начать просто с описи всего инвентаря в Excel файл.
Возможно на этом этапе будет достаточно учета.

В современном Excel можно и искать и фильтровать по колонкам достаточно удобно.
Если в БД появится потребность вести нормализацию и справочнники - то тогда
этот Excel уже пригодится как raw материал для загрузки в реляционные БД
или какие-то коробочные системы учета.

Но начать все равно нужно с ручной работы по фиксации всего в один файл.
Я-бы даже мог начать с текстового файла с разделителями. Он потом и в Эксцель зайдет.

Хочу напомнить что такие системы как ClickHouse ориентированы не на одиночные события
а на стриминг. Тоесть вы должны не просто логгировать а желательно просто потоком лить
много событий. Батч-режим вставки в кликхаус - это и есть ее оптимальный режим.

Вставка по 1 строке например раз в несколько секунд с фиксацией - будет не благоприятным
режимом работы для кликхауса. И наверное с плохим КПД. Подумайте о том что может
стоит все таки писать логи классическим способом и по истечении времени например
сбрасывать пачку к аналитические хранилища.

Приложение JD-Gui поможет тебе анализировать (декодировать) байткод class files.

https://java-decompiler.github.io/

Если речь идет о криптографии (дешифрование) то это отдельная тема. Но мне кажется
что тут пока не доказано применение шифрования. И это во много раз сложнее
чем декодирование.