dasdasdsadas, не хотите ходить в БД на чтение при каждом запросе - не используейте JPA. Возьмите, например, JOOQ - с ним вы можете делать UPDATE полей, которые вам пристали в запросе, не читая предварительно всю запись.
У вас очень абстрактный вопрос. Конкретное же решение зависит от конкретных условий проекта. Если у вас 1000 запросов в час - лишнее чтение из БД вам глубоко безразлично. Если у вас 1000 запросов в секунду - будете оптимизировать везде где можно.
Точно также можно хранить количество заходов в $_SESSION (тогда будет считаться для каждого пользователя), в $_COOKIE (для каждого браузера), в БД, в localStorage браузера (это уже Javascript), да в общем-то где угодно.
Вася Пупкин, не бывает таких сервисов, которые не воспримут адрес 10.0.0.0, вы их совершенно напрасно боитесь. Это полностью нормальный IP-адрес. Вы же не думаете что в интернете встречаются всякие адреса, условно: 16.147.32.14, находящийся в подсети 16.0.0.0/8?
А насчет домашнего оборудования: у меня микротик с заводскими настройками прихапал себе адрес 192.168.88.1 и начал раздавать по DHCP пул 192.168.88.0/24 в локальную сеть. Я это, конечно, могу переконфигурировать - но зачем, если все работает? А что если у какого-нибудь удаленщика на домашнем роутере окажется не 192.168.1.*, а 192.168.10.*?
xunterr, нет, не обязательно. Вполне можно сделать одну реализацию (используя те же generic-и) для всех сущностей. Но как правило, рано или поздно вылезут специфичные операции с конкретными сущностями и все равно придется делать реализацию репозитория под конкретную сущность.
Что значит "как только ответ приходит 200"?
Если приложение после 500 ответа перестает обрабатывать данные, значит оно перестает и посылать запросы на сервер. Как тогда оно может получить 200 без запроса?
А вообще задача напоминает больше обработку очереди сообщений. Лучше бы это делать на на HTTP-запросах, а на чем-то предназначенном для очередей - та же Kafka, RabbitMQ и подобных.
calculator212, ну как сказать проигрывает. В 2019 и 2020 Leela выиграла чемпионат по компьютерным шахматам, два раза брала кубок (в том числе обыграв стокфиш в финале со счетом 5,5 : 4,5). Может быть текущая версия Стокфиша и сильнее Лилы, но то что Лила одна из сильнейших шахматных программ (и наверняка обыграет чемпиона мира) - это факт.
Полный перебор в шахматах тоже невозможен. Но в шахматах значительно проще сформулировать оценочную функцию. Потому что в го один камень, добавленный где-то в углу доски может изменить ход борьбы в другой части доски через 50 и более ходов. На такую глубину перебором (с учетом размера доски) считать практически невозможно. Поэтому "традиционные" оценочные функции в го до применения нейросетей играли слабо. А в шахматах - вполне справлялись с задачей победить чемпиона мира.
Другой вопрос - можно ли нейросеть научить играть в дурака? Потому что, в отличие от шахмат, это игра с неполной информацией. Насчет этого ничего сказать не могу. Возможно стоит попробовать.
А почему для шахмат нет смысла в нейросети? Вроде есть очень сильные программы, в которых используются именно нейросетки, аналогично го. Например Leela Chess Zero
ReasonerNum2, во-первых я слышу разделение на "обучение" и "программирование". И они как-то странно противопоставлены. На самом деле у программиста это разделение скорее условное: учишься через практику, практикуя чему-то учишься. Чтение книг (теория) мало полезно без практики, которая помогает уложить знания в голове.
И вот тут у меня возникает ощущение, что теоретические знания до конца не уложились, не "обкатаны", а вы пытаетесь идти дальше, к "больше чем какие-то простые программки". В какой-то момент не хватает базы, возникает непонимание "где я и что я здесь делаю?" и обучение становится сложным. Сложность порождает дальнейшее непонимание, что приводит к закручиванию "спирали". Если это так, то это признак того что нужно вернуться на несколько шагов назад.
Вообще, программирование это про постепенность. Это про возможность делать даже большое проект небольшими шагами. Написал маленькую функцию, запустил, убедился что работает. Написал следующую функцию.
Про возможность движения маленькими шагами очень хорошо написал Кент Бек в книге "Экстремальное программирование. Разработка через .... Он пишет, что можно двигаться быстро, когда вы чувствуете уверенность, но в ситуации неуверенности (а изучение любой новой темы - это ситуация неуверенности, уверенность приходит с практикой) - лучше двигаться маленькими шагами. Движение маленькими шагами порождает меньше стресса и в конце-концов формирует ту самую уверенность.
Еще у Эндрю Ханта и Дэйва Томаса я встречал такое упражнение как "ката". По аналогии с боевыми искусствами (где "ката" - это комплекст движений, которые боец оттачивает до идеального исполнения), "ката" - это некоторая задача, которую программист решает раз за разом. Это не про решение задачи (решение уже найдено и известно), это про тренировку. Решая одну и ту же задачу раз за разом до состояния "могу написать эту программу не приходя в сознание" закрепляются навыки, формируется уверенность. Да, в какой-то мере это скучно. А иногда в процессе решения "ката" приходит неожиданная мысль - это можно сделать иначе.
Не обязательно использовать "ката". Но изученные темы надо отрабатывать, желательно самому придумать и решить какие-нибудь задания. Изучили массивы? Сделайте 3-5 программ на эту тему. Изучили наследование? Сделайте 3-5 программ про это. И тогда обучение следующим темам, приемам программирования не будет слишком сложным. А если все-таки оказалось слишком - то это признак что где-то какой-то необходимый шаг пропущен. И нужно сначала сделать его, а не пытаться "заставить себя" или "взять нахрапом".
ReasonerNum2, окей. А теперь давайте перенесемся к моменту потери интереса. Вот недавно было интересно что-то делать (С++, Питон, сайт и т.д.). И вот наступает то что вы назвали "перегоранием". Какие в этот момент эмоции? Что вообще в этот момент происходит с удовольствием от программирования?
P.S. Ответ прочитаю и напишу свой уже, видимо, завтра.
Вам, чтобы файл запускался в первую очередь нужен атрибут Main-Class