mayton2019

как тогда работают БД?

Пускай Ораклисты меня поправят но по моему DBMS Oracle не использует потоки. По крайней мере
на уровне терминологии и документации все составные части Oracle - это процессы PMON, SMON, DBW...
И пользовательские сессии тоже представлены процессами. По крайней мере отстрел пользовательских
сессий через orakill / kill тоже привязан архитектуре процессов.

или у БД своя файловая система?

Да Oracle может использовать ФС ext3/4 например или работать поверх технологии ASM (это 2-в-1 и менеджер
томов и кластерная ФС) но мне кажется что к сути вопроса это не относится.

По старой памяти у меня в голове крутится параметр FILESYSTEMIO_OPTIONS, он отвечает за тип I/O
операций которые DBMS будет использовать. Там кажется ASYNC, DIRECT и их комбинации. Вобщем
почитай тоже по этому вопросу.

К протоколу FTP данная проблема вообще не имеет отношения. Собственно он свою задачу выполнил.
Трафик отдал. Но дисковое хранилище внезапно откатилось взад. У нас такое было когда мы покупали
в одном банке RedHat виртуалки для работы программистов. И было такое что в течение дня ты работаешь.
Не успел закоммитить. И на следующий день получаешь - "день сурка". Все файлы как будто вернулись во
вчерашний день.

Пишите письма в техподдержку BEGET. Прикладывайте скриношты и логи. FileZilla тут скорее всего не поможет
т.к. она является таким-же ftp клиентом как и консольный ftp к примеру.

Вы пишете что мучаетесь 3 года? Вот это терпение! За это время вы просто могли попробовать
альтернативный хостинг в пилотном режиме и просто убедиться что проблема откатов файлов исчезла.

В it так часто бывает. Иногда не стоит тратить миллиарды усилий на доказательство наличия бага.
Можно просто поменять условия и баг исчезнет.

Резко поменять. Еще резче. Вот такая вот она - инженерия современного It.

Я не уверен что стоит вообще искать идеальное решение. Особенно для 800 точек. Задача
пахнет комбинаторной со всеми вытекающими.

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

Для малого числа точек (8) можно построить выпуклую оболочку. И попробовать прикладывать
первую грань параллелепипеда к каждой грани выпуклой оболочки. А оставшиеся грани мы можем
получить вращением параллелепипеда до тех пор пока bounding volume не будет минимален.
Учитывая дискретность выпуклой оболочки, поворот тоже может быть дискретным. Например там
проверить штук 20 углов. Вот как-то так.

Я вот так делал. Работает быстрее чем стандартная сериализация. Но есть задача.
Ты сам должен реализовать сохранение всех полей класса во внешний файл
(ObjectOutput). Можно через операции над байтами.

Еще сложнее реализовать чтение. Т.к. нужно различать неинициализированные
состояния полей. Например у студанта есть дата рождения но имя еще не задано.
Тоесть надо придумать как в файл писать признак null для поля name.

public class Student implements Externalizable {
    
    private String name;
    private LocalDate birthday;

    @Override
    public void writeExternal(ObjectOutput out) throws IOException {
        // TODO:
    }

    @Override
    public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
        // TODO:
    }
}

Есть коробочная библиотека Kryo которая это делает в более автоматическом режиме.
Но я так понимаю что автор очень хотел сам вручную поразвлекаться.

В каждой ide есть свои способы подключения артифактов. Я чаще использовал maven-based project.
И чтоб добавить кастомную зависимость я ее устанавливал в локальный maven folder.

$ mvn install:install-file ....

И после этого библиотека была видна как group:artifact:version coordinates.

При данной постановке - безразлично где хранить. Можешь их писать в текстовый файл в формате даты + 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) Композиция. Ты включаешь внутрь одного контроллера один или несколько функционалов от других контроллеров. Композиция не имеет пределов вообще. Можно композировать что угодно и с чем угодно. Композицию используют даже люди которые на знают ООП. И не на ООП языках. Просто у них для этого есть другие названия.

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