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

не могу создать новую базу в идее, создается схема

Наоборот.

CREATE SCHEMA is a synonym for CREATE DATABASE

https://dev.mysql.com/doc/refman/8.0/en/create-dat...

Symlink

Ну написано же - некий Lumu считает, что там malware, все остальные 88 провайдеров данных так не считают. Скорее всего они просто перестраховываются.

VirusTotal имеет ложные срабатывания, поскольку использует несколько ПО для проверки ссылки. Всего один антивир посчитал это вирусом, скорее всего ошибка.

PHP Mailer уже по сути бекенд.

Но вообще ТЗ конечно потрясное. С учетом что щас есть львиная доля "магазинов" в виде сайтов-визиток и "пишите нам в месенджеры" - то в целом какой то "магазин" можно сделать.

year.length === undefined
undefined < 2 === false
(year.length = 3) === 3 >> true
return Math.ceil(...)

Забудем что принципиально хранить пароли - плохая практика, но так как задача уже такова что хранение вынужденное то:
1. шифровать логины и пароли (весь набор данных, не имеющих смысл друг без друга, лучше хранить сериализованными в одном поле, особенно когда от задачи к задачи поля меняются, т.е. логин пароль почта api key, gpg ключи шифрования и т.п. пусть это будет свободная json строчка, за ее анализ отвечает клиентская часть приложения)
2. ключом/паролем, который не хранится в базе данных (он должен являться частью бакэнда, т.е. в том месте где на бакэнде хранятся настройки подключения к внутренним сервисам либо отдельное место хранения) - при разделении работ между людьми (обслуживать базы могут другие люди, чем те кто имеет доступ к бакэнду) чувствительные данные не утекут легко.
3. логируй все, т.е. показал пароль - сохрани в специальном логе (в базе или файлах уже вопрос организации работ) - кто, когда, с какой машины, что получил
4. когда показываешь пароль на клиентской машине, повторно запрашивай авторизацию (чтобы не использовалась автосохраненная), важный момент, это исключит кражу данных уже на стороне клиента, очень мало кто правильно организует рабочее место (это просто неудобно и дорого).

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

Для скиллов необходимо указать уровень (junior/middle e.t.c).
И не стоит писать много скилов. Иначе складывается впечатление что
кандидат - многостаночник и эникейщик.

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

Английский надо поднимать хотя-бы до буквы B.

Далее. Не для резюме. Для вопросов-ответов. Вот если ты написал что есть базовые знания back-end.
То ты должен быть готов рассказать архитектуру вашего backend. И перечислить стек технологий.
И нарисовать диаграммы. Тоесть любое дополнение или случайное слово в резюме будет
поводом для "поговорить". Поэтому если ты точно-точно имел базовые знания - то расскажешь.
Если нет - то лучше убери это слово.

Очень странный вопрос.
144hz, 60hz - это способность монитора обновлять картинку (сколько раз за секнуду).
FPS - это сколько кадров успела подготовить видеокарта.

144FPS на мониторе 60hz вы не увидите.
60FPS на мониторе 144hz будут точно такие же, как и на мониторе 60Hz.

У тебя get вызывает сам себя, поэтому стек кончился и приехали.

При слиянии веток будет конфликт и вы сможете решить какие изменения оставить, а какие убрать

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

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

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