Dmitry Bay

Что нужно сделать ДО переезда в обяательном порядке:
Разобраться с кабельным хозяйством в новом офисе.
Заманчиво, конечно, ВСЁ сделать до переезда, но вопрос с проводами решать в работающем офисе - совсем печально. А при переезде (который подобен половинке пожара :) и освоении нового офиса - ещё и менять/перенастраивать серверные решения - боюсь просто разрваться придётся.

Выяснить - что есть в новом офисе. Планируется ли там ремонт или переезжаете в существующий.
Если ремонт - требуйте в рамках ремонта новкю СКС. Из расчёта "1 раб.место о 2х порта СКС (RJ-45) на 4 кв.м офисной площади (кабинетов)" Не ведитесь на существующее количество сотрудников и "утверждённые рассадки". Сколько я их перевидел на 30 лет - все расползались за пол-года после въезда в новый офис :)

WiFi в новом офисе - планируется ли? Тогда - Плюс порты скс в коридорах, за фальш-пгтолком.
Для видеонаблюдения порты СКС и ЛВС...

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

Место для серверной выбить. На пару 19" шкафов. С возможностью поставить ещё пару. Плюс шкаф ИБП. Т.е. - квадратов от 20. Мощности электрические выбить. Про дублировнные кондеи в серверной с зимним пакетом до -30 не забыть
Помимо кабнета для сисадмина - нужна отдельная кладовка

Будет ли ВЭРС для бесперебойного питания всех компв в здании?

А вообще-то даже Техническое Задание (документ, описывающее, что вообще надо сделать) для нового офиса - это документ на пару десятков страниц...
И ТЗ на ИТ-инфраструктуру - ещё столько же...
Теоретически - ТЗ пишутся Заказчиком. Чаще - Исполнителем на базе информации от Заказчика.
Потом ТЗ роняются на потенциальных исполнителей.

Я с трудом представляю, как документ такого объёма в рамках этого сайта обсуждать, хотя понаписал их в жизни не мало...

Никто ниче не банит. Оплачиваю через icloud

Имеет смысл делать обновление, если все работает нормально?

В идеальной вселенной со сферическими конями, где обновление происходит одной кнопкой - конечно, имеет.
В нашей же вселенной, где обновление может что-то сломать и занять неопределённое количество времени, а необновление может привести ко взлому или поломке с непредсказуемыми последствиями, ответить на вопрос "имеет ли смысл" заранее невозможно.
Обычно делают бэкап, пытаются обновиться и дальше уже исходя из количества и серьёзности возникших проблем, либо их решают, либо откатываются.

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

Всё именно так, как сказал товарищ rPman в комментарии: по умолчанию мак во время стандартного сна просыпается периодически, гонит сетевой трафик и считает что-то по мелочи. Проверьте настройки энергосбережения и сна - вроде где-то там эта фича отключается и можно включить полноценный сон.

Никак. С кодом после минификации не надо никак работать. Минифицированный код предназначен для доставки его по сети максимально быстро на клиент. Для изменения кода вам следует вносить изменения в исходный код и уже только потом его минифицировать, а не наоборот. Если исходного кода нет - то пропускаете через любой деобфускатор и вручную восстанавливаете исходный код. Ну или пишете сами с нуля то же самое.

почитайте например про НСДИ (https://habr.com/ru/articles/562722/), РАНР (https://habr.com/ru/news/806591/)....

Смену способа хеширования пароля вы можете провернуть только при участии каждого пользователя, в два этапа.
1 этап.
Делаете патч в функцию авторизации.
Когда пользователь авторизуется, проверяете, что заполнено поле по хешу новой функции.
Если оно заполнено по новой функции, то все проверки верности пароля проводите с ней, поле старой функции игнорируете.

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

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

перевод игры лежит в отдельном файле(например json и хранит в себе каждую строчку текста, которая применяется в игре), и потом в коде запрашивать нужную строку из файла и брать от туда значение текста для последующего применения на сцене

Да, так оно и работает.

или есть способы попроще

Проще уже некуда.

Kwork
FL.ru
Профи.ру
ХедХантер,
Авито
Фриланс чаты в ТГ

...из наших вроде всё

Нанять программиста.

Тренироваться и решать реальные задачи. От простого к сложному. Рисуете схему алгоритма, далее делаете декомпозицию вниз до самого простого и понятного вам элемента. Ну и далее реализуете поэтапно начиная с простых элементов и затем переходя к более сложным.