Rustam Azizov

Так а вы не подумали, что не стоит пытаться съесть такой кусок? Если вы новичок, то вам из всего того что на learn.javascript нужно от силы 20-25%. Какие, нафиг, map'ы, set'ы? Вы знаете где вы их будете применять? - нет, а зачем тогда вы из СЕЙЧАС изучаете? Ваш потолок на данный момент:
(1) функции, массивы, работа с DOM.
Где брать практику? Делайте сайты, ек макарек! Я постоянно пишу эту цитату, она идеальна и универсальна:
"Это как очки, вы сами поймете, когда они вам нужны". Тут так же, если вы понимаете, что вы не можете применить рекурсию или зацикливание - не применяйте. Делайте то что можете. Слайдеры\попапы\анимации простые, дальше больше. От того что вы прочли весь learn.javascript и забыли все через день - толку НОЛЬ. Как я уже сказать, все что вам нужно - см. пункт (1)

UPD.
На ютубе Дмитрий Лаврик хорошо объясняет все, подробно и разжевывая.

Собрать приложение под другую платформу можно с помощью команды publish

dotnet publish

с указанием правильного runtime. Например:

dotnet publish -c Release --framework netcoreapp2.0 --runtime osx-x64

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

Как сделать сервер отказоустойчивым?

Если только 1 сервер, то это единая точка отказа. Т.е. упал сервер приложения - упал сайт. Упал сервер БД - упал сайт. И даже такая, казалось бы, незначительная часть потери фунциональности как отвалившиеся assets (CSS, JS, изображения) - сайтом становится невозможно пользоваться - обычно приводят к отплыву 99.99% пользователей сайта.

Нужно добиваться уменьшения количества точек отказа в системе. То есть должна быть соответствующая инфраструктура (допустим, на основе k8s). К примеру, отказал некоторый компонент (узел), а на его место моментально поднимается его замена. Не откликается одна реплика БД - переключается на другую.

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

Защита от DoS - отдельная непростая тема.

Добавлено
И забыл упомянуть такую важную вещь, как мониторинг всевозможных параметров. Со стороны это может условно выглядеть как Центр Управления Полетов (куча мониторов с графиками). Без телеметрии никуда не деться.

window.addEventListener('resize', handleResize);
handeResize - ваша функция

Предположим, что БД Тостера хранит пароли в открытом виде. Предположим, что недобросовестный сотрудник унёс с работы дамп и продал на хакерском форуме. Теперь у покупателя есть имена пользователей, адреса их электронной почты и пароли. Для 90% пользователей пароль к Тостеру будет совпадать как с паролем к почтовому ящику, так и ко всем остальным ресурсам, зарегистрированным на ту же почту или тот же никнейм, вплоть до интернет-банкинга. А значит покупатель получит к ним ко всем доступ. Вот это и называется "утекла база".

Что означаете «утекла база»?

Это значит что данные содержащиеся в базе получил тот кому они не предназначались.

прошу описать вкратце возможный процесс взлома и как хеширование помогает в данном случае

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

Поэтому пароли в базе данных хранить нельзя! И все нормальные сервисы вроде Тостера не хранят пароли в базе.
Но сервису то нужно как-то аутентифицировать пользователя.
Если в базе хранится пароль - все просто. Пользователь отправил Тостеру пароль, тот проверил, что он совпадает с хранящимся в базе, и все - пользователь подтвержден.
А если пароли хранить нельзя?
Для этого используется хэширование.
В базе данных Тостера хранится не пароль, а хэш пароля - например пользователь Вася создал пароль qwerty, Тостер вычисляет хэш этого пароля -d8578edf8458ce06fbc5bb76a58c5ca4 и сохраняет его в базу данных.
Для того чтобы зайти на Тостер Вася отправляет ему свой пароль - qwerty, Тостер вычисляет его хэш и сравнивает хэш с тем что хранится в базе данных. Если они совпадают - пользователь подтвержден.

В итоге пароли в базе не хранятся, и если злоумышленник скопирует базу себе ( база утекла) он не будет знать паролей пользователя. И не сможет под именем Васи зайти на тТостер.
Все что знает злоумышленник это хэш - d8578edf8458ce06fbc5bb76a58c5ca4

Ну вот примерно так если коротко, и очень упрощенно.

Хэширование никак не защищает содержимое базы и не мешает утечке базы - оно защищает от утечки паролей и только.

и как хеширование помогает в данном случае

Все очень просто.

Вы стырили чей-то кейс с документами. Открываете его, перебираете бумаги и среди них находите металлическую коробочку, в которой что-то шуршит, но ключей к ней у Вас нет. Как ее открыть? Либо перебором имеющихся ключей и попыткой снять отпечаток у хозяина (подбор паролей и социальная инженерия) либо попыткой сломать ее, распилить, раздавить (прямой перебор). Подбор паролей сработает (может быть) если владелец лох, а возможность сломать оценивается прочностью металла (стойкостью шифра).
Пароль не хранится в БД. В БД хранится некий цифровой код, который получается из строки пароля с помощью неких вычислений - это собственно и есть хэширование - получение однозначной связи между текстом и цифровым кодом (хэшем), причем обратной связи НЕТ. То есть, по тексту можно получить хэш, но по хэшу текст получить невозможно (если это не так, значит алгоритм взломан).
Для проверки пароля считается хэш от полученной от пользователя строки, если совпали - все, вуаля.
Хотя утечка БД с открытыми данными даже и без паролей - крайне пренеприятная вещь.

var str = "1234567890";
var e, r = /.{4}/g; // одно-единственное регулярное выражение
while(e=r.exec(str)) {
	console.log(e[0]);
	r.lastIndex -= 3;
}