NeKt0

Открыл вопрос и из монитора хлынул поток воды, так что сразу к вопросам:

Какое оборудование (модели) ставить на уровень доступа, распределения?

Да Микроты ставьте, если прокачаться хотите. В качестве свитчей - HP, например. Можно и D-Link, не слушайте диванных кукаретиков.

Как делать - 4 коммутатора на все устройства (в шкафу), или же по одному на этажах и центральный в серверную?

Всё в шкаф, чтоб потом не бегать по этажам и не искать причину поломки.

Как нарезать vlan? По этажам? По кабинетах?

По кабинетам геморройно, я бы вообще ничего не делал, сеть-то маленькая.

Так и не знаю делать ли интернет розетки или нет)

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

А, да, и AD бы всё-таки настроить и DNS с DHCP на Windows Server зарулить.

Результат на JQuery: https://codepen.io/semzhukov/pen/ZEzPyVM

потому что в строке

let products = obj.data

вы по сути в products вставляете ссылку на obj.data

а в строке

products = []

вы заменяете эту ссылку на другую

при этом содержимое

obj.data

тоже ссылка, и она остается прежней.

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

ЗЫ: был несколько невнимателен, не достиг моего мозга последний абзац вашего вопроса. Ответили вы верно.

for (var i = 0; i < thumbnails.length; i++) {
  thumbnails[i].addEventListener('click', function () { // Корень проблемы здесь.
    // Ты обьявляешь (не вызываешь!) в цикле анонимную функцию. При создании эта функция получает
    // ссылку на внешнее лексическое окружение, которым, в данном случае, является тело цикла for.
    // Когда функция вызывается, в своем лексическом окружении i она не находит, и продолжает поиск
    // во внешнем. К моменту вызова, цикл завершен, и i в его лексическом окружении равна thumbnails.length
    fullPhoto.src = photos[i];
  });
}

Решал некоторое время назад похожую задачу и использовал вот такую библиотеку https://www.react-simple-maps.io/
Там и карта простая, и маркеры можно кастомные выводить, и географию до границ США ограничить

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

Что такое

Новый тип данных symbol - это попытка ввести уникальные идентификаторы. Все крутится вокруг функции Symbol. Это не конструктор в полном смысле слова, с new ее использовать не получится. Это скорее маленькая фабрика. Она просто возвращает новый символ каждый раз. Это важно. Каждый раз новый. В качестве аргумента можно передать строку, но она используется только для отладки.
Symbol() === Symbol() // false

Что такое глобальный символ? Какой еще реестр?

Есть Symbol.for(), это еще один метод, который не просто возвращает символ, но и сохраняет информацию о том, для какого параметра он создавался. Внешне логика работы напоминает хеширование - для разных параметров символы получаются разные, а для одинаковых - одинаковые.

Symbol.for('my-string') === Symbol.for('my-string') // true
Symbol.for('my-string') === Symbol.for('another-string') // false

Зачем это надо?

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

• В качестве ключа для доступа к свойству объекта. Грубо говоря вместо obj[key] использовать obj[some-magic-unique-key]. Позволяет избежать коллизии этих самых ключей если вы расширяете существующий объект из сторонней библиотеки. На практике встречается не очень часто, особенно в небольших проектах, но по всей видимости это - причина появления символов в языке.
  
• Некоторая иллюзия приватных свойств. Символы по-своему работают с циклами и многими методами, связанными со свойствами объекта, становясь невидимыми для них. В результате можно разделить "все свойства с обычными ключами" и "все свойства с ключами-символами". А еще можно запутать код до безобразия.
  
• Также, пользуясь предыдущей мыслью, можно сделать что-то вроде метаданных для любого объекта, которые опять же не сломают существующий код, но могут быть использованы для хранения какой-то информации и мередачи ее между отдельными модулями. Штука довольно интересная.
  

Здравствуйте.
Технологий взлома уйма.
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCTS.
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:

GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';

И т.п. По принципу "Разделяй и властвуй."
4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций.
Пример:

$DB->select('SELECT * FROM tbl WHERE a=? AND b=?', $a, $b);

5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты.
6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).

www.chartjs.org/samples/latest