Михаил

Ну вот представьте: мошенник Вася выпустил корневой самоподписанный сертификат. А затем подписал им цепочку до фишингового сайта mmoney.com
Пользователь Петя зашел на сайт, получил всю цепочку сертификатов, включая корневой сертификат; цепочка, разумеется, валидна. И ввел данные своей кредитки, будучи уверен что имеет дело с нормальным сайтом.

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

А зачем вам учебный материал по спрингу на котлине?

Весь учебный материал по спрингу актуален для котлина. Переложить Java на Kotlin - даже не просто, а очень просто (даже IntelliJ IDEA умеет автоматически конвертировать Java в Kotlin). Поэтому берите Java и не мучайтесь (все равно при использовании котлина и спринга джаву знать необходимо т.к. постоянно будете натыкаться на джавовские библиотеки)

SELECT * FROM table WHERE group = 1 ORDER BY value DESC LIMIT 1

UPDATE base SET test = IFNULL(:test, test)

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

Сделать это можно на любом языке - от C++ до Javascript, под любой популярный язык найдется библиотека для разработки игр (и вероятнее всего не одна).

Unity - вполне вариант. Насколько знаю, позволяет делать игры как для десктопа, так и для мобильных платформ.
Если хочется чего-то менее монструозного (ближе к "настоящему" программированию, а не "конструктору") - то я бы рекомендовал посмотреть Kotlin. Это официальный язык для разработки под андроид и он же прекрасно будет работать на десктопе. Лично я "щупал" связку Kotlin + libGDX, меня вполне устроило.

Ну так вы полностью правы. Как работает Cookie.

1. Сервер отсылает заголовок Set-Cookie браузеру
   
2. Вместе с заголовком сервер отсылает страницу.
   
3. Получив заголовок Set-Cookie браузер сохраняет "печеньку" у себя.
   
4. При следующем запросе страницы с этого сайта браузер к запросу присоединяет заголовок Cookie, в котором передает сохраненные "печеньки".
   
5. В ответе сервер снова может прислать Set-Cookie, тогда будет добавлена или обновлена имеющаяся "печенька".
   

Таким образом, в вашем случае достаточно не переходить по ссылке еще раз, а нажать F5 - язык переключится.

Вообще, для решения вашей проблемы я бы брал язык из URL и только если его там нет - из "печеньки". Тогда переход на страницу с нужным языком переключал бы его сразу (так как значение в URL имеет приоритет) и сохранял в cookie для последующих запросов.

Любая PCI-е. Все версии протокола PCI-e совместимы между собой. Количество линий и версия PCI-e не важны, работать будет "по минимальному". Если возьмете карту PCI-e 3.0 x8 - она будет работать в режиме PCI-e 2.0 x8 (так как версию ограничивает материнская плата, а количество линий - видеокарта. Оставшиеся 8 линий просто не будут использоваться)

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

Можно попробовать декомпилятор (например jad). Но декомпилятор не восстановит исходных код полностью. И в сложном классе разобраться все равно будет проблематично. А если исходный код написан еще и не на Java, а на другом JVM-языке (Scala, Kotlin, Groovy и т.д.), то это добавит еще головной боли.

Если строго следовать принципам SOLID, а именно SRP (принцип единственной ответственности), то задачей контроллера является презентовать какую-то часть приложения в виде HTTP endpoint (в частном случае REST).

Собственно логика не должна находиться в контроллере, потому что способы обращения к этой логике (через HTTP, Service Bus, Telegram, Discord, периодический вызов по крону и т.д.) ортогональны собственно бизнес-логике.

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

Прочитать Git Book

Конкретно в вашем случае: git reset --hard
ВНИМАНИЕ! Эта команда уничтожит все изменения в незакоммиченных файлах.

Проблему решил удивительным шаманством.

Была загружена Windows c SSD
Выполнил netsh int ipv4 uninstall
Перезагрузил
Выполнил netsh int ipv4 install
Перезагрузил
Заработало.
Перезагрузил Windows c HDD (через UEFI) - тоже работает.

Совершенно не понимаю как и почему эти две копии винды влияют друг на друга.

Интерфейс не должен решать за потребителя - что используется, что не используется. Поэтому вариантов тут на самом деле такие:

1. Убрать. Вполне нормальный вариант, если это просто общая часть специализированных DAO.
   
2. Реализовать (используется - не используется это неважно)
   
3. Дополнить его параметрами, позволяющими потребителю решать что он хочет получить - конкретную страницу, весь список, задавать опции сортировки и т.д., то есть убрать необходимость в специализированных методах.
   

Потому что компьютер делает то что вы ему сказали, а не то что вы от него хотите :)

Пусть account = 100
тогда, если x=10
account = 100 + 10 = 110

затем, если x = -5
account = 110 - (-5) = ?

А если бы, допустим, в у нас был отдельный интерфейс IMove, то мы смогли бы реализовать его в каком угодно модуле/компоненте, например в условном File, ведь мы можем переместить файл. Так же и с ISleep, мало ли что может уснуть, начиная от операционной системы или потока выполнения, заканчивая персонажем в тамагочи.

Неверно. IMove (точнее будет назвать Movable) имеет смысл в контексте какой-то предметной области. И перемещение файла, перемещение спрайта, перемещение трехмерного объекта, перемещение руки робота - все это разные перемещения. Соответственно и интерфейсы будут разные (расположенные в разных модулях, даже если будут называться одинаково), например:

filesystem.Movable
graphics.2d.Movable
graphics.3d.Movable
servo.Movable

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

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