DevMan

Потому что это не те кавычки

или никаких или ` такие для названий столбцов и таблиц.

' и " это для строк

Воспользуйтесь актуальной официальной версией курса, там всё уже разложено по полочкам.

Компаний много. Проектов много. Руководителей много.

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

И если вам на тостере все скажут "да не нужно никому ВО", а руководитель проекта скажет "нет ВО - досвидания", вы его скриншотами с тостера не переубедите.

Идите к ним напрямую и спрашивайте при трудоустройстве.

Если вы уже используете xdebug, то ставьте брейкпоинт и смотрите трейс в дебаггере.
Попробуйте поработать в какой-то приличной IDE типа PHPStorm, PHPEd или других.

Кешировать. Для этого и редис подойдет, и мемкеш. А лучше сразу упасть на hazelcast или apache ignite. Во первых, они распределенные, во вторых, работают с кучей языков, в третьих, при должной сноровке их можно накачать данными заранее, в четвертых, за ними вообще можно спрятать любую базу, ОРМ или поисковик. В результате, будете работать только через кеш, который будет в нужные моменты вываливать или сохранять данные пачками.

Я (Петя ) пробовал так:
1. Удалил свой проект локально усебя на компе.
2. Клонировал проект Васи с гитхаба себе на комп.
3. git checkout хэш_8_го_коммита_Васи

Вот в этот момент случился detached HEAD.

5. git remote set-url origin url_на_репозиторий_Пети.git

Не нужно, т.к. шаг 2 уже это сделал.

Как сделать?

Зависит от того, как вы решите поступить с историей. Есть несколько вариантов:
- выкинуть два ненужных коммита совсем и переписать историю начная с этого места. Для этого на шаге 3 нужно было сделать git reset --hard хэш_8_го_коммита_Васи, а при пуше в репозиторий пушить с ключом -f

- откатить два ненужных коммита, оставив их в истории. Для этого на шаге 3 нужно было сделать

git revert хэш_10_го_коммита; git revert хэш_9_го_коммита

- родить новую ветку от 8-го коммита и разрабатывать дальше в ней. Для этого на шаге 3 нужно было сделать

git checkout хэш_8_го_коммита_Васи -b имя_новой_ветки

Ну и дальше в IDEA при попытке: VCS --> Commit... --> Commit and push... получаю сообщение "The Git repository C:\project2018wm is in the detached HEAD state"

В вашем текущем состоянии я бы сделал следующее:

git stash
git checkout master # или имя ветки в которой были 8 хороших коммитов
действия из выбранного варианта из перечисленных выше
git stash pop

200 рублей в год за домен это дорого?
Там все просто - заходите на сайт, регистрируйтесь, крупная кнопка "Купить домен" или что-то подобное написано. Вводите имя домена, если он свободен, то предлагают оплатить.
Это не сложнее чем в интернет-магазине любой товар покупать.

Чем крута: лаконичностью. Решены болячки джавы (множественное наследование, стирание типов, метапрограммирование). Мощная система типов с поддержкой ко- и контрвариантности. Синтаксис позволяет писать DSL.

Почему стоит учить: как минимум для расширения кругозора.

Где применяется: бекенд, фронтенд, десктоп, Андроид.

С чем едят: чаще всего с akka и spark.

Сложность в: нужно немного повернуть мозги.

Почему стоит пересесть: не стоит. Серьезно. Пересесть ради пересесть плохая мотивация. Пересесть нужно когда у вас появится интерес к функциональному программированию.

Outline это контур элемента с внешней его стороны, то есть сразу за border. В отличие от border он никак не влияет на элементы, их ширину и расположение. Ключевое слово inset в свойстве outline: inset 100px green; устанавливает этот контур в виде псевдотрехмерной рамки за счёт осветления правой и нижней границ и затемнения левой и верхней относительно указанного цвета. Ширина 100px, цвет зелёный.

Баг создаёт свойство outline-offset: -125px;, которое задаёт смещение контура. При положительном значении контур будет расширяться во все стороны. А при отрицательном будет сжиматься внутрь элемента.

Спецификация CSS Basic User Interface Module Level 3 в статусе рекомендации говорит о том, что контур элемента со свойством outline-offset при отрицательном значении не должен становиться меньше, чем двукратная вычисляемая ширина контура. То есть если в примере у нас размеры элемента 100x100 пикселей и контур задан у нас шириной 100px, то при outline-offset: -125px; он должен сжаться внутрь элемента на 125px со всех сторон, а спецификация визуально ограничивает сжатие до outline-offset: -50px; (по 50px внутрь с каждой стороны элемента). То есть контур должен просто сойтись вместе со всех сторон, образуя квадрат в нашем случае и насколько больше не ставь отрицательное значение, больше он сжиматься не должен. Но реализация в браузерах не учитывает это поведение и выдаёт непонятные фигуры, если отрицательное значение слишком большое.

https://www.w3.org/TR/css-ui-3/#outline-offset


Поведение при отрицательном outline-offset должно быть как на гифке. Если дальше уменьшать значение, ничего меняться не должно.

Писать тесты для реакта сложно и мучительно. Стоит посмотреть на тесты разработчиков и почерпнуть нужные идеи https://github.com/reactphp/http/tree/master/tests

Мультимастер СУБД - это такая замечательная штука, которую все хотят и ни у кого пока не получилось.
Потому что есть такая штука как CAP теорема, весьма мешающая сделать серебряную пулю.

Ладно, ближе к делу.
Самая большая проблема с автоматическим failover СУБД - решить, что уже пора переключаться. Для чего необходимо выяснить, а что вообще происходит, не развалилась ли сеть, не вернётся ли через пару секунд мастер обратно - если в сети в результате окажется два мастера, то нет никакого разумного способа определить, где данные актуальны. Худшее что можно представить - это split brain: когда часть приложений ходит в один мастер, часть в другой и данные стремительно расходятся в разные стороны. Есть такая байка про гуглдиск "у нас всё отказоустойчиво, все данные хранятся в 4 экземплярах. Правда, у нас была авария и мы теперь понятий не имеем, какая из копий актуальная"
Переключение мастера на 90% - решение административное и человеческое. Автоматика же добавляет головной боли. Зачастую - больше головной боли, чем без неё. Особенно если железо адекватное серверное, которое "вдруг" выпадает очень редко.

Обычно автоматики нет, и есть детальная инструкция по переключению мастера БД, по которой и в ночи можно переключиться.

Если всё ещё хочется походить по граблям - посмотрите patroni. Есть пара кластеров с ним на поддержке, при наличии мониторинга особых проблем не припоминаю. До split brain по крайней мере не придумал как довести, вроде все варианты прикрыты. В худшем случае в readonly уходит.