mayton2019

При данной постановке - безразлично где хранить. Можешь их писать в текстовый файл в формате даты + IP адреса.
Можешь писать в БД. Никто не скажет где здесь оптимум.

Пока ты сам не придумаешь какие запросы будут по этому хранилищу. И как долго ты согласен ждать выдачи
ответа. Вот с этого момента уже можно обсуждать Базы или форматы бигдаты.

Асинхронное программирование не обязано соотвествовать структурному. Ты предполагаешь
что код исполняется сверху-вниз как в Pascal. Но он выполняется в соответствии с тем как
срабатывают отложенные функции. Вот когда SELECT вернет данные - тогда и твой чек-поинт "1" будет
напечатан.

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

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

Из параллелизма есть задача параллельного умножения двух больших матриц. Очень популярная
и многократно обсужденная почти во всех It-ресурсах.

И второй смысл - это просто знать способы распараллеливания медленно работающих задач.

Современные фреймворки - тяготеют к тому чтобы разработчик не встречался с задачей конкуренции.
Яркий пример - акторные фреймворки (Akka, Storm). А в задачах биг-даты - практически все
сводятся к map-reduce и если ты хорошо сделал partitioning для своих таблиц или файлов то тебе вообще
ничего делать не надо. Фреймворк сам позаботится. Добавляй только ему ресурсы (процессоры или ноды).

И любые задачи массовой обработки файлов и сетевых событий - автоматом поднимают проблему мультиптоточки.

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

Тоесть если будешь решать практические задачи - бери настоящие а не высосанные из пальца.

Есть два варианта.

Классифицировать все хотелки от пользователя и превратить их в набор формочек например

Count: ___
Names: ___

И транслировать их в фиксированные запросы типа

SELECT * FROM database WHERE count > _ AND Name IN (___,___)

И второй вариант - дать пользователю конструктор запросов. Чтоб пользователь как-бы мышкой
накликал набор предикатов-фильтров. Я не специалист в PHP, но в Java например такие конструкторы
(билдеры) выглядят вот так https://www.jooq.org/ или так querydsl.com

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

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

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

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

Если гуглить по ключевому слову С++ socket server то обычно находят приложение клиент-сервер
который по TCP/IP передает текстовые сообщения. Я считаю что это - минималистичный мессенджер.
Вот бери его и думай как развивать дальше.

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

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

Почитай про GraphQL https://graphql.org/ . Многим - нравится. Можно декларировать гетерогенные структуры и типы данных.

В ООП существует 2 правильных пути расширения функционала.

1) Наследование. Ты делаешь базовый контроллер с какими-то общими функциями. И другие контроллеры просто наследуются от базового. Наследование всегда красиво выглядит на диаграмме классов. Такое и приятно показывать на презетнациях. И заказчик доволен. Недостаток наследования - иногда в наследника попадает то что не нужно. И в этом случае наследование нужно просто дробить на большее число уровней. 2-3-4 и так далее.
2) Композиция. Ты включаешь внутрь одного контроллера один или несколько функционалов от других контроллеров. Композиция не имеет пределов вообще. Можно композировать что угодно и с чем угодно. Композицию используют даже люди которые на знают ООП. И не на ООП языках. Просто у них для этого есть другие названия.

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

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

Попробуй денормализовать ВСЕ и слить ВСЕ в один сет документов. И эти документы положи в ElasticSearch.
Это - коробочное решение сегодня для любого текстового поиска. Работает быстро. Пропорционально числу
вычислительных nodes. Чем больше nodes в кластере - тем быстрее ищет.

Непонятно что такое "Файловая система Linux". Это какой-то фасад за которым стоит вполне себе конкретная
реализация (ext4, xfs). И не все из них поддерживают растягивание размера на ходу. XFS например - поддерживает.

Я ищу какое-нибудь приложение, утилиту или скрипт, который поможет мне автоматически исправлять имена файлов.

Коробочного решения скорее всего не будет. Тут слишком много всякой специфики. Не напасешся правил.

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

Второй блок странно выглядит. Когда я рисовал схемы (более 20 лет назад) в ВУЗах было принято
обозначение ввода данных внутри паралелограмма.

Бочка-набок - это типичное обозначение из очередей сообщений (Message Queues) но в данном
случае это было-бы неправильно. Работа MQ - это бесконечный процесс и тогда надо как-то обозначить
что процессинг и вывод тоже бесконечный. А у нас стоит явный СТОП алгоритма.

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

Сам термин взлом здесь не применим. НС оперируют нечеткой логикой поэтому никакого взлома
нет. Есть просто детерминированное поведение выхода в зависимости от входа.

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