mayton2019

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

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

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

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

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

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

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

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

Я вижу следующие пути оптимизации.
1) Мемоизировать (запомнить в массив) хотя-б первую сотню чисел. Тогда например для 120 чиссла
все считать не надо и можно делать перемотку вперед. Или мемоизировать с шагом. Тоже экономия.

2) Можно попробовать считать через золотое сечение (приближенно) если этого достаточно для
ответа.

3) Можно отказаться от java в пользу С++/GMP библиотек. Возможно расчет суммы будет быстрее.

Но вообще фибоначчи действительно не параллелится. В этом главная проблема.

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

Они и будут максимально непохожие поскольку принадлежат к разным кластерам.

Возможно есть лучшее решение. Но это вполне мне кажется приемлемое.

Не существует общих методик проверки БД на валидность. Только пользователь (бухгалтер)
может сказать рабочая БД или нет.

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

Применяйте этот скрипт автоматически. Сделайте штук 10 таких скриптов и метрика будет
например 80% от всех скриптов дали зеленый свет.

Есть учебные БД для машинного обучения
https://www.kaggle.com/
https://datasetsearch.research.google.com/

Я не уверен что их можно считать БД. Для них обычно нет строгой нормализации.

Еще в GitHub я находил разные семплы вроде учебных NorthWind e.t.c.

Делать скриншот с видео - скорее всего неправильно. Скрин будет иметь шумы.
А видео обычно имеет свойство компенсации шумов если изучать не один кадр а несколько.
И особенно важно если съемка была в движении.

Обычно настраивают JAVA_HOME - это корень дистрибутива.
CLASSPATH - это там где лежит lib/*.jar и
PATH - это где bin/ и все выполнимые приложения из
комплекса JDK.

Первую настраивать не обязательно. Обычно это просто для удобства переключения между
дистрибутивами. А две другие соотв идут как зависимость от хоума.

Седжвик делает упор на алгоритмы. Вот и читай про алгоритмы. Сортировки. Поиск. Алгоритмы на графах.

Или ты думаешь что документация по Java раскрывает тебе графовые алгоритмы?
Бери содержание и смотри.

Файлы должны синхронизироваться в двунаправленном порядке (не зеркало).

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

Да. Поступать можно. Современный программист для сайтов e-commerce не претендует на особые
знания. Умеешь складывать и считать процент - этого достаточно.

Если будешь искать потом углубления - то подучишь потом. А так последние 10 лет это почти гумантиврная
специальность и софт-скиллы требуются в основном гуманитарные. Умение разговаривать. Знание английского.
Скрам-аджайл - это все гуманитарщина.

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

int f(int a, int b) {
    return a + b;
}
void _end(void) {};

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

И трюки которые работали в ассемблере могут не работать для языков где есть агрессивная
оптимизация.

Вот допустим изучу я ассемблер и C, как будто это самое легкое из всего.

Это - вершина айсберга.

Если ты начнешь изучать например ассемблер для x86, то это целая история изменений. 16/32/64 регистры
и наборы команд для векторизации. Я-бы сказал что это все очень затягивает и это автоматически
вовлекает новые области знаний такие как - железо, микро-контроллеры, сети.

Далее может быть направления - системотехника и безопасность. Далее - оптимизация (параллелизм
и конкуренция).

Тоесть на самом деле нельзя сказать что я вот "изучу С" и положу книгу на полку. Это - как и зучить
современную физику. У тебя всегда будут открытые вопросы. И их число будет только расти.

Вобщем удачи.

Хм. Да похоже AWS.S3 действительно не поддерживает откат бакета в прошлое.
Но если рассматривать S3 как протокол поверх обычной файловой истемы
(Minio+BTRFS/ZFS) то вы можете задачу отката переформулировать в терминах
конкретной файловой системы. Там - это коробоная фича.

Я тоже думал над этим вопросом.

Я думаю что можно оценить влияние ИИ на текст как близость текста к учебному датасету.
И чем ближе ответ ИИ к учебке - тем с большей вероятностью он создан ИИ.

И чем дальше - тем он более нестандартный и очеловеченный

Как видите, для ответа на вопрос вам придется потрудиться. Как минимум собрать всю библиотеку Гуттенберга,
всю Британскую Энциклопедию, Фейсбук, Stackover e.t.c. :)

Инкапсуляция не имеет никакого отношения к хакерам.

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

Торрент файл очень хорошо защищен от повреждений. Даже лучше чем дистрибутивы просто на сайтах.

И по протоколу, когда скачивание полностью завершено, все торрент-клиенты еще раз проверяют
целостность скачанного и если хотя-бы 1 бит не совпадает по контрольной сумме то закачка будет
продолжаться бесконечно пока сумма не совпадет.

Поэтому совершенно непонятно чего автор решил что он теряет пакеты?