Booba Yo, ну я бы делал общие таблицы, а с тем кому, что и как раздавать - это вопросы к API: он и данные как нужно отфильтрует, и ненужного никому не отдаст.
Akina, да нет никакого сигнала. ведущий задает вопрос и кто первый догадался - тот и нажимает. Можно нажимать по ходу вопроса и тогда все могут начать нажимать после ключевого слова, а там уже и пинги/задержки будут влиять.
Хочется уменьшить ситуации: "ну я же жал первее!" и "во всем пинг виноват!"...
Akina, да, я думал про некий аналог калибровки, чтобы вычислить задержку/пинг/разницу между сервером и клиентом. Думаю, что если добавить к этому еще одну временную метку, которая будет означать начало раунда можно будет выводить точное время отклика с начала раунда. Пока буду реализовывать в эту сторону..
ThunderCat, это понятно, поэтому есть и обычная скорость, замеренная на сервере. Вообще, нечестных игроков оставляем за скобками, т.к. следить за ними задачи не стоит.
Мария, ну на самом деле правильно думали, делимое можно вынести и за CASE.
Будет что-то типа:
SELECT 10/CASE WHEN 1 = 1 THEN 2 WHEN 2 = 2 THEN 5 ELSE 1 END AS tmp FROM DUAL;
Но это так, кустарное решение. Если логика будет сложнее - то лучше обращаться либо к функциям, либо заводить таблицы-справочники, либо использовать какое-то промежуточное решение между этими двумя.
Без конкретики сложно сказать. Если задают вопросы - значит что-то непонятное им с них спрашивают.
Если вопросы остаются после разъяснения - то что-то не так с сотрудниками.
Я подозреваю, что дело в документации (всегда в ней) - тогда нужно выносить это все в отдельный отдел, а к отделам приставлять своего специалиста, который будет знать как что делать и будет разбираться в специфике работы отдела.
Мне нравится стек React + WebApi(C#) + Identity(Keycloak) + DB (Postgre).
Смотрите в сторону Open Source, сейчас много чего (из сервисов) можно установить себе на сервер в один клик.
Добавлю, что по итогам совещания формируется список обговоренных этапов и краткие итоги, затем это все рассылается участникам и закрепляется подписью заинтересованных лиц.
Конечно, и в таком протоколе можно изворотливо описывать ситуации, но обычно ни у кого не стоит намерения кого-то обязательно "опрокинуть".
Любая служба безопасности (экономическая, информационная) - это отдельная реальность, даже не параллельная. Иногда принимаются такие решения, что их не понять человеческим мозгом. Причем, на местном уровне, обычно ребята все нормальные: где в цепочке к головному офису они обрастают щупальцами и меняют мировоззрение мне лично вообще непонятно)
inneks, посмотрите какие-нибудь сканеры уязвимостей. Знаю, что серверную часть проверяют MaxPatrol: он заходит на сервера, собирает данные по установленному ПО, лезет куда-то к себе в БД,выдает список уязвимостей по ПО и как их "лечить" в форме громадной портянки с данными. Возможно, что он и с рабочими станциями работает.
Если чисто по ошибке говорить, то SWITCH в данном случае является областью видимости и внутри него нельзя объявлять переменные с одинаковым именем.
Если хотите объявлять одни и те же переменные внутри CASE, то просто создайте еще один локальный Scope, добавив фигурные скобки.
Как-то так:
switch(characterChoose)
{
case 0: {
int PlayerDamage = 50;
int PlayerHealth = 150;
int PlayerResist = 25;
break;
}
}
А таски где прилетают? Вроде как во всех трекерах есть функция "Зависит от", где указывается другая задача, без которой ну никак эту не закрыть. А далее как воркфлоу настроен: иногда бывает так, что задача не переходит в выполнение, пока задача (от которой зависит таска) не перейдет в merged.
Само собой что деление на features принято для того, чтобы меньше кода между собой переплеталось, а то смысла вообще никакого...
"Умные мысли преследовали его, но он был быстрее..."
Без уточнения задачи это вообще не имеет никакого смысла.
Чем вас не устраивает обычный SELECT?
Где вам нужно пробежать по строкам? В функции/процедуре БД? В каком-то стороннем приложении?
OCCASS OCCASSOVICH, да. Иначе, зная эндпоинт, можно будет править любые посты, не являясь автором этого поста, просто отправляя POST-запросы на этот эндпоинт.
Обычно, если у вас есть разделение на клиент и АПИ, то с запросом посылают JWT-токен, в котором есть вся нужная информация. АПИ перед работой с БД, подтверждает валидность токена, парсит его и достает доступы, сравнивает их с каким-то эталоном и правит пост или же возвращает ответ "доступ запрещен".
И тут уже не важно, что на клиенте: пока не прикрепишь к своему запросу валидный токен - изменить пост не получится.
Александр, пускайте специально обученных людей со специально созданными правами доступа в специально созданную схему БД. Пусть работают через GUI клиенты...
Зависит от решаемых задач, конечно.