Алексей Уколов

Текущая общепринятая практика это редирект в https на 80м порту и HSTS на 443м. Использование HSTS приводит к тому, что клиент никогда не будет использовать HTTP с сайтом, даже если явно указать http в URL. Дополнительно, можно отправить домен в список HSTS preload В США практика официально закреплена в документе The HTTPS-Only Standard, обязательном для правительственных агентств, в нем есть отдельное упоминание что:

Allowing HTTP connections for the sole purpose of redirecting clients to HTTPS connections is acceptable and encouraged. HSTS headers must specify a max-age of at least 1 year.

.

т.е. разрешать подключения к 80му порту с целью редиректа не толко допустимо, но и желательно.

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

Незачем пытаться охватить все веб-серверы. Для урока авторы, видимо, решили, что «сойдёт и так» – на примере одного из популярных, Apache.

Вы уже переросли песочницу тех уроков и знаете другие варианты. Значит, сумеете понять и перенести правила из .htaccess в конфиг NGINX. С помощью Google, SO и Habr.QnA )

Популярен паттерн "front controller" — когда веб-сервер конфигурят, чтобы все запросы падали только на корневой /index.php, а там уже логика внутри PHP узнавала запрошенный URL /section1/page2 и отдавала соответствующий ответ. Такие решения универсальны относительно веб-сервера.

Файл .htaccess иногда кладут в проект, потому, что это легкий невидимый файл, который не помешает. Но поможет понять ожидаемое поведение веб-сервера. Конфиги NGINX лежат отдельно от проекта, поэтому их не прилагают. Хотя иногда приводят пример в документации.

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

Как там в 2010?

как мартышка ковыряешься с проставлением типов (а иногда это и не особо очевидно), а потом оказывается что какой-нибудь популярный плагин (условный слайдер) в твоей экосистеме - не типизирован. Ручками писать? Потрошить внутренности плагина? Искать аналог?

Это уж как вам удобно. Вам в большинстве случаев понадобится типизировать от стороннего плагина несколько, а то и один метод и пару аргументов. Не хотите ручками? Идём на https://www.typescriptlang.org/dt/search/ и ищем готовое. А в большинстве случаев достаточно создать файлик типа modules.d.ts и там прописать строчку declare module 'ldapjs-type-parsers';, где подставить имя пакета, для которого нет типов.

Вопрос звучит как "уговорите меня использовать TypeScript". В общем вас никто не заставляет. Если лично вам неудобно, то пишите на JS.
P.S. Я уже молчу про удобство рефакторинга ))

Если потребуется делать join с одним из параметров внутри JSON, то это и будет показывать, что в данном варианте так делать не нужно.
Если ни при каких обстоятельствах не возникнет ситуации, что потребуется разбирать JSON, чтобы связать данные таблиц, то храните JSON.

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

async function() {
  let result = null;

  while (1) {
    result = await fetch(...);

    if (result тот, который нужен) {
      break;
    }

    await new Promise(r => setTimeout(r, 5000));
  }

  return result;
}

Возможно, у вас просто не было приватных свойств.
Вывод чистого var_dump() в версиях PHP 8.2.0RC4, 8.1.7, 8.0.20, 7.4.30, 5.6.40:

object(Test)#1 (2) {
  ["name":"Test":private]=>
  string(16) "Васенька"
  ["age"]=>
  int(43)
}

Вывод var_dump() с установленным xdebug:

class Test#1 (2) {
  private $name =>
  string(16) "Васенька"
  public $age =>
  int(43)
}

Моё мнение - если тебе смысл переменной не очевиден, то нужно делать полноценное имя переменной.

Короткое, например, имеет смысл для параметра в лямбде (array.filter(x => x % 2 === 0)) или в какой-нибудь функции наподобие

function sum(a, b) {
 return a+b;
}

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

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

Экономить ресурс нажатий на кнопки клавиатуры не надо, как и не надо экономить буквы на экране.

https://php.watch/versions/8.2/mbstring-qprint-bas...

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

Самый надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

# клонируем репозиторий в соседний каталог
# иначе придётся использовать ключ --force
git clone --no-local . ../clonerepo/
# переходим в свежий клон
cd ../clonerepo
# чистим
git filter-repo --path "path/to/file" --invert-paths
# проверим что файл исчез
git log --oneline --name-status -- "path/to/file"

Коммиты в гите неизменяемые, но мы можем их пересоздать заново. Фактически получится новый репозиторий, но сохранится история. Всем участникам проекта придётся клонировать новый проект заново.