Александр

У меня периодически возникает одна и таже задача - очень быстро искать нужный текст в логах. Логи большие. Могут быть по терабайту. Россыпь файлов типа

application/log-2023-02-16-12-30.log
application/log-2023-01.gz

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

Вот есть сделать предложение - создать утилиту igrep (index-grep) которая при первом пуске - быстро проиндексирует по датам и словам.
И при полседующих будет искать быстро. И диапазон учитывать например.

Классический греп не подходит. Он все равно ищет линейно. Не учитывая даты. А мне надо так.

$ igrep time=-12h level=ERROR Tomcat Network Error
Вот. Здесь я как-бы захотел поискать все события за 12 часов назад уровня ошибки и содержащие
два ключевых слова.

Сами файлы обычно внутри структурированы так. Это почти всегда шаблон.
2023-02-16T00:00:01,000 [Info] Server started.
Есть метка времени. Уровень события. И текст события. Много-строчники (стектрейсы) можно соединять в одну строку. О длине самих файлов - ничего не известно. Могут быть от мелких (дневных) до архивов.

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

UPD.

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

К слову я ничего не придумал. Немного замкнутый круг получается. Самый простой и надеждый способ - все таки использовать мнемонические фразы из стандартного bip39. Эти фразы выжечь у себя татуировкой на руке или блин заказать себе жетон на шею с гравировкой. Или как Киану Ривзу прошить в мозг под гипнозом. Вобщем нужно такое хранилище чтоб.... ну короче лучше сейфа и бумагами я пока ничего не придумал. Звучит смешно но бумага оказывается надежнее чем жесткие диски сидюки и кассеты стриммера.

Археологи подтвердят.

Это как в автомобиле. Если что-то застучало или загремело - срочно на СТО. Учитывая что это HDD механического типа - далее ситуация будет ухудшаться. Я-бы сделал сразу полный бекап всего. Чтоб потом не плакать слезами. И в ремонт.

Бизнес должен понимать что вы ему предлагаете. По сути эту идею можно продвинуть только под соусом разработки новой фичи. В противном случае у вас будет сильное непонимание. Все что вы предлагаете - это NFR. Не-функциональные требования. Шестая версия дотнет. Асинки. Обжекты. Бизнес не понимает как ему это дальше продавать.

Я-бы сказал что просто так взять всё и переписать - это гиблое дело. Пойдут баги и бизнес попросит либо срочно исправлять либо откатить это назад до старой версии. Это - фиаско. Очень часто бывает так что старый и плохой код завязывается на какое-то странное поведение API которое плохо документировано и чёрт-пойми-как-работает. Но работает. Я много таких аномалий видел. И ты его исправляешь по фень-шую как должно быть и становится ... (!) еще хуже. Особенно большая беда с мультипоточкой и интеграцией например с операционкой или сторонними нативными либами.

Если вы имеете силы и смелость - то пишите план (желательно на пол-года) на рефакторинг. Шаг-за шагом. Сначала - покрытие всего тестами. Потом миграция версий тоже мелкими шажками. И все это (!) параллельно с разработкой новой фичи которую бизнес одобрит. Только так.

А попробуй так

System.out.println(applicationContext.getBean(ConnectionPool.class));

Это сложная тема. Это вам - не арканоид написать. Чтоб правильно сталкивать объекты - надо представить как-бы они сталкивались в реальном мире. И я думаю что тут даже десятка параметров недостаточно чтобы описать какое это столкновение. Столкнуть два бильярдных шарика - это одно. А два мешка с песком - это другое. Или шарик с мешком.

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

Из практики я не встречал в жизни такой задачи где-бы проектирование было с нуля и до конца.
Бизнес меняется. Постоянно появляются новые услуги. И под них растет база. Я-бы на твоём месте
не стал-бы упарываться вопросом именно проектирования базы. Я-бы доверился итеративному
процессу наподобие scrum-agile. Делаешь первую версию БД. Показываешь демо. Потом снова
итерации. Я надеюсь с командой alter table ты знаком? Ну и прекрасно. Значить в любую
табличку можешь внести изменения. Табличка это не железо-бетон. Если надо - пределай.

Если ты нашел в интернете нечто и хочешь под него что-то спроектировать в БД - тогда
экспертом по бизнесу являешся ты. И ты должен сам себе задать вопросы. Какие данные
будут лежать? Ключи и атрибуты.? Как они связаны.? Тут появляются связи один-ко-много или много-ко-много.
Это концептуальный уровнь. И на физическом уровне могут появится индексы. Партишены.

Если ты не знаешь какие сущности там будут лежать - то пойди от бизнес-кейсов. Например кейс.
Человек хочет сделать заказ. Или еще другой кейс. Человек пришел оплатить заказ.
Оплатил. Попользовался неделю. Потом ему что-то не подошло и он потребовал возврат.
Из кейсов сразу появляются сущности. Клиент. Заказ. Склад. Платеж. Фидбек. Flow товара по магазинам
и складам. И так далее.

Если начнешь делать - делай по минималке. Лучше сделать меньше но самодостаточно чем поначинать
тысячу сущностей и бросить их.

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

Попробуй понаблюдать сетевой трафик через tcpdump/wireshark.

И попробуй активировать DEBUG логгирование для библиотеки org.apache.hc.client5 (я думаю что ты ее используешь хотя по исходнику неочевидно). Попробуй в отладке посмотреть на MultipartEntityBuilder. Есть ли у него toString() ? И что там?

Так нет же запрета создать массив из ArrayList

ArrayList<Object>[] list = new ArrayList[5];
for (int i = 0; i < 5; i++) {
   list[i] = new ArrayList<Object>();
}
list[0].add(new Integer(1));
list[0].add(new String("2"));
list[1].add(new Float(5.0));

как и ArrayList из массивов

ArrayList<Integer[]> list = new ArrayList<Integer[]>();

В конфиге сквида параметр tcp_outgoing_address.

Вариант хранения всех файлов в облаке с монтированием локально по WebDAV вам не подойдёт? Винда умеет WebDAV-хранилища монтировать как локальный диск.

Почитайте "Тайм-менеджмент для системных администраторов" Томаса Лимончелли. Хорошая книга, и отчасти даёт ответы на вопрос "как организовать приём и обработку пользовательских заявок".

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

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

Начать продвижение в массы тикетницы можно с молодёжи. Они более обучаемы, им легче разобраться с интерфейсами. Когда народ поймёт, что заявки через тикетницу выполняются быстрее, то сарафанное радио это постепенно разнесёт по всей конторе.

И главное оружие админа -- это вежливость :-)

-- У меня там проблема такая-то и такая-то!
-- Извините, я сейчас занят такой-то проблемой. Создайте, пожалуйста, заявку, а то меня сейчас отвлекут, и я про ваш вопрос забуду.

Ну и медленно, но неуклонно гнуть процесс именно к этому. Чтобы мысль "заведёная заявка а) выполняется и б) быстро, а озвученная на бегу в коридоре выполняется либо медленно либо забывается" постепенно дошла до всех.

С новыми пользователями ещё проще, их можно сразу подсаживать на эту схему, мотивируя тем, что "у нас так принято, так построен процесс, вот тут инструкция, почитайте, пожалуйста. Если будут вопросы -- готов ответить".

С одной стороны понятно, что вам совсем не интересно решать задачи саппорта, а интереснее повозиться с серверами, но с другой стороны, без организации процесса вам нормально возиться с серверами не дадут, будут постоянно дёргать. Поэтому простроение процесса саппорта и в ваших интересах тоже.

Что бы меньше иметь проблем (меньше компонентов и надстроек, меньше проблем), если хостовой машинкой необходимо иметь виндоус:
1. я бы не использовал Docker Desktop, удалил бы его (всё равно он использует WSL)
2. установил бы докер как сервис в WSL2, например как тут https://dev.to/bowmanjd/install-docker-on-windows-...
3. Монтировал бы линукс пути без всяких W:\\src
4. с windows подсистема линукс вроде бы доступна на smb share \\wsl
5. рассмотрел бы переход на линукс или хотя бы отдельно виртуалка под разработку.

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

Просьба очень странная. Даже невозможно нормального ответить.
Авторов обычно трое. Шилдт. Эккель. И Хорстман. Все пишут про Java. Примерно
одно и тоже. Но поскольку ты очень занятой и тебе времени не хватает - то я тебе
не советую читать ничего. Работай и задавай вопросы здесь. Когда появится желание
читать - выбери жестко одну тему. Например рефлексия. И читай только про нее.
Вот так.

Технология называется NAT.