Василий Банников

Заходить нужно туда куда вам интересно.
ИБ это настолько широкий в различных интерпретациях термин, что сначала его вам нужно узко переопределить.
Формально ИБ это работа в первую очередь документарного характера, например описание процедур приведения системы в соответствие с законом о защите персональных данных, или в соответствие с требованиями к гостайне, банковской тайне и т.д.
В этой плоскости, ИБ вообще не техническая специальность, требующая некоторых специальных технических знаний. Это документы.
Есть другая интерпретация данного термина, это тестирование на проникновение, защита приложений, защита сетей, т.е. практическая безопасность сервисов, приложений, хранилищ данных, сетей, каналов передачи и т.д.
Эта интерпретация как правило не имеет прозрачной системы обучения, не стандартизирована и очень очень широкая.

Например защита каналов передачи данных, это и физическая защита, и инженерная с точки зрения строительства, и сетевые администраторы с VNP тоннелями, и системные администраторы с https, и математики с шифрованием, и физики с квантовыми эффектами. А еще это куча административных мер, по защите проекта прокладки канала, поскольку в проект могут быть внесены не санкционированные изменения, и проверка реальных работ по прокладке, проектным, а еще различное лицензирование на данные работы и оборудование и т.д. и т.п.

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

Потому что принято публичными делать именно свойства, а не поля.

В этом возрасте стоит сделать упор на сарафанное радио. Возможно, сайт нужен кому-то из родителей, родственников, знакомых родителей и т.д. и т.п.

почитайте Все говнокодеры?

У меня есть 3 сущности User, Mentor и Student. Mentor и User имеют связь один к одному, Student и User тоже имеют связь один к одному.

Возможно у Вас не 3 сущности, а 2. User (имя, дата рождения, и тд. ) и Role (User, Mentor, Student).

Также и них должны быть одинаковые Id. То есть когда мы хотим добавить объект Mentor, уже должен быть объект User с таким же Id. Также и со Student.

Бред.

ID - это синтетический ключ. Некое искусственное уникальное поле назначение которого однозначно идентифицировать строку в базе. Строить на его базе какую либо логику нельзя.

Я просто новичок в Entity Framework

Проблема не в том что Вы новичок в EF, а в том что Вы новичок в проектировании БД.

Для начала разберитесь в связях (как они реализуются, для чего используются и тд. ), а потом уже разбирайтесь с EF.

Почитайте - тут хорошо всё расписано.
С точки зрения архитектуры БД, если есть отношение один-к-одному, то возможно есть смысл объединить данные в одну таблицу.

Здравствуйте. Существует несколько ситуаций, когда желательно разделение определения класса или метода:

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

При работе с использованием автоматически создаваемого источника код можно добавлять в класс без повторного создания файла источника. Visual Studio использует этот подход при создании форм Windows Forms, кода оболочки веб-службы и т. д. Можно создать код, который использует эти классы, без необходимости изменения файла, созданного в Visual Studio.

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

Разделяемые методы особенно полезны для настройки автоматически созданного кода. Они позволяют зарезервировать имя и сигнатуру метода, чтобы автоматически созданный код мог вызвать метод, а разработчик мог сам решить, реализовывать этот метод или нет. Как и разделяемые классы, разделяемые методы позволяют организовать совместную работу автоматически созданного кода и кода, созданного человеком, без дополнительных затрат во время выполнения.
Источник: https://docs.microsoft.com/ru-ru/dotnet/csharp/pro...

Итак, спасибо Евгению Глебову за комментарии. Теперь всё стало понятно.

Защита с помощью заголовка (и соответствующей технологии) X-XSS-Protection скомпрометирована и создаёт ложное ощущение защищённости. В любом из режимов 0 или 1; mode=block реализуемы XS-атаки.

Разработчикам рекомендовано:
- явно отключить защиту, установив директиву 0,
- перейти к использованию защиты, используя заголовок Content-Security-Policy,
- самостоятельно обеспечить защиту сайта от XSS-атак.

Язык сам по себе - просто инструмент. F# позволяет писать программы в более функциональном стиле, чем C#, но возможности их не отличаются, и под капотом будут одни и те же инструкции MSIL.

Привет! Если домен тематический, а в вашем случае это так, то конечно лучше оставить текущий домен, и сделать редизайн всего сайта. Так же важно учесть, что вам нужно сделать редиректы со сторах страниц на новые, если вы будите менять url страниц. Если не будите, то важно, чтобы контент был одинаковым. Что я имею в ввиду
1 старая ссылка типа site.com/php_development - тут у вас инфа по разработке на php
2 новый сайт ссылка такая же site.com/php_development но инфа у вас о разработке например на java - и контент там будет про java - это будет нерелевантно для поиска

Простой в реализации метод: держите отрезки в каждом элементе отсортированными и непересекающимеся (если два отрезка пересекаются - объедените их).

Далее при запросе пройдитесь по списку и для каждого элемента бинпоиском найдите самый правый отрезок, начало которого левее запроса. Проверьте, лежит ли запрос в отрезке. Это будет чуть быстрее наивного метода, но все-равно пройдется по многим элементам списка зря.

Если же список очень длинный, а ответ ожидается маленький, то есть более быстрый метод. Но он сложный в реализации. Нужно реализовать персистентное дерево поиска. Можно его реализовать на основе персистентного дерева отрезков. Это такая структура, в которую можно добавлять элементы, и удалять их за O(log n). Также можно обходить все элементы за O(log n + (их количество)). Кроме того, сохраняются все версии дерева после каждой операции и общее количество памяти будет O(к log n), где к - количество операций.

Эта структура будет использоватся для хранения предподсчитанных ответов. Если все ваши отрезки нарисовать на одной прямой, то она разобъется на O(n) отрезков, все точки которого будут давать один и тот же ответ при запросе. Мы эти все ответы компактно сохраним.

Используем метод сканирующей прямой. Нанесите все границы всех отрезков на одну прямую, пометив их как начало или конец (и какому элементу списка они соответствуют). Если пройтись по этой прямой слева на право, то будут происходить события - отрезки откроются (новый элемент добавляется в ответ) или отрезки закроются (элемент из ответа удалится). Поддерживая текущий ответ в персистентной структуре мы сильно экономим память. Удобно в качестве начал отрезка брать их координаты, а в качестве конца - координаты концов+1. В таком виде все границы отрезков будут точками, а не числами.

Итак, создайте массив из структур {координата, это начало или конец, номер элемента}. Отсортируйте по координате, потом по флагу начала. Потом пройдитесь по ней и при обработке начала отрезка - добавляйте номер элемента в персистентное дерево. При обработке конца - удаляйте элемент из дерева. Так же перед обработкой каждого элемента запишите в массив-ответ: {предыдущая координата, текущая координата, ссылка на текущую версию персистентного дерева}, если предыдущая координата строго меньше текущей. Этот массив-ответ будет хранить все возможные отрезки с различными наборами ответов в виде {координата начала, координата конца, ответ}.

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

Это решение требует O(n log n) памяти (где n - количество всех отрезков) и O(n log n) времени на предподсчет и O( log n + (ответ)) времени на обработку ответа.

Более простое решение, где ответы считаются так же сканирующей прямой, но сохраняются просто в виде списков, а не версий персистентного дерева, может требовать O(n^2) памяти. Но будет работать быстрее, конечно.