Кирилл

Добавить контроллер с RequestMapping = /profile

@RequestMapping("/profile")
public class ProfileController {
    
    @GetMapping("/{id}")
    public ModelAndView profileById(@PathVariable String id) {
        final ModelAndView model = new ModelAndView("profile");     
        /* do something */
        return model;
    }
}

Берите время по конкретному часовому поясу.
У меня в примере время по UTC, чтобы не париться)
https://jsfiddle.net/webirus/o8v2exc0/

Ревертни изменения и добавь папку ".idea" в .gitignore.

Это то же самое, что:

function activation(x) {
  if( x >= 0.5) {
    return 1;
  } else {
    return 0;
  }
}

Подробнее посмотрите про стрелочные функции и тернарный оператор.

Линейная алгебра и мат. анализ в объеме 1 курса СПБГу или МГУ. Этого за глаза хватит для 95% алгоритмов.

А вообще, если вы в 10 классе, изучайте просто программу вперед.

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

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

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

Я не хочу сказать, что все эти гофы и солиды не имеют смысла, они созданы для того, чтобы для начала просто с ними ознакомиться, отложить в подсознание и... благополучно забыть! Но потом, когда вдруг что-то писал и внезапно осенило: Да это же паттерн медиатор/обсервер/репозиторий/anyPattern! Вот тут и пригодится та самая книга трёх танкистов и собаки, которая просто направит в нужное русло, объяснит остальное, что не успел понять сам, и т. п.

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

Но, я пока что таких людей не видел...

Всё дело в том, что this в A.foo ссылается не на A, а на инстанс B. А поиск метода идёт по цепочке прототипов, начиная сверху, поэтому до A.bar никогда не доходит.
Рассуждать, логично это или нет, бессмысленно - это просто так и нужно принять такое поведение, понять его и использовать.

И нет, в Java и C++ поведение не такое. Вообще, в javascript наследование прототипное и есть закидоны особенности с контекстом вызова, поэтому привычное из других языков понимание ООП в нём не всегда работает.

Возможно вам нужен CORS

ng-show и ng-hide это так называемые "функции" которые работают с стилем "display" используемого элемента. Работают они следующим образом:
Атрибутом к элементу ставите например ng-show="test()".
test(); - это функция, которая будет возвращать либо true, либо false.
Эти значения и будут говорить о том, будет ли отображен элемент или нет.
Например:

<div ng-show="test()"></div>

$scope.test = function(){
return true;
}

В таком случае div будет отображаться, а если функция test() вернет false, стилю display данного блока будет присвоено значение "none". и отображаться оно не будет

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

Но на практике бывает иначе. Поэтому, если можете пройти туториал на любом из сайтов (реакта/ангуляра) - пытайтесь сделать что-то посложнее. Рано или поздно понимание того, что азы нужно подтягивать придет, но при этом уже будет сколько-то монет в кармане + не потеряется мотивация программировать.

P.S. да, это вредный совет.

npm install bower -g на отлично прошел

Это вы установили bower глобально.

Для запуска шаблона, вам наверняка нужно:
1) npm install
2) bower install
3) далее, то что написано в доке, может быть gulp build, например.

Почитайте про инъекцию зависимостей.

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

А суть паттернов в двух словах - свести к минимуму кол-во изменений существующего кода при добавлении новой функциональности.

Еще про SOLID принципы почитайте, тоже будет полезно.

Вы, простите, много видели программистов 1С, работающих на языке программирования 1С без 1С? Я - ни одного. Закрытый "клуб по интересам", который генерит такие велосипеды, что диву даешься.
Закрытый язык программирования никто не будет учить, на закрытом фреймворке никто работать не будет, даже если будут обучать. Для чего его учить, время тратить? Чтобы потом иметь возможность устроиться только в компанию Х? Потеря сообщества - это смерть любой технологии, любого языка, любой ОС.
Была такая замечательная ось - OS/2. То, что она замечательная, я знаю не понаслышке - все-таки два года проработал под ней. Погубило ее как раз отсутствие поддержки - не было софта, не было программистов, не было сообщества - все постепенно разбегались кто куда. Где нынче OS/2 - да никто и не вспомнит. А отдал бы IBM ее в опен сорс - глядишь, нашлись бы пара-тройка энтузиастов.
Продавать продукт невыгодно - его можно продать один раз. Гораздо выгоднее продавать поддержку - ее можно продавать постоянно.