Михаил

Считайте что вам выйдет эффективнее:

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

Для меня решающим вопросом был бы вопрос цены за 1 мощный или 2 менее мощных сервера. При примерном равенстве (даже если 2 сервера немного дороже) - я бы выбрал один сервер.

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

https://www.php.net/manual/ru/features.commandline...

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

Если же речь идет о том чтобы "попробовать" - то задача разбивается на этапы:
1. Разобраться как делать то что ты хочешь вручную (как запускать, останавливать, конфигурировать серверы и т.д.)
2. Автоматизировать это на любом языке программирования
3. Сделать веб-морду для управления серверами (опять же на любом языке программирования с использованием любого из множества фреймворков), опираясь на автоматизацию сделанную в п.2.
4. Развивать эту систему, добавляя в нее новые функции (учет времени, тарификация и т.д.)

Тут вариантов у вас несколько:
1. Размещение у российского хостера, в русском ДЦ. Проблем с оплатой нет, проблем с доступом из России и из-за рубежа пока нет. Но есть риск, что начнут рвать связь до России и доступ к вашему сайту как минимум ухудшится/замедлится. Или вообще исчезнет.
2. Размещение у российского хостера, в зарубежном ДЦ (в частности в США). Проблем с оплатой нет, риски потерять доступ тоже есть. Только на этот раз есть риск потерять доступ к серверу из России. Либо США могут начать "выдавливать" российские компании, что может вынудить закрыть зарубежный ДЦ.
3. Размещение у зарубежного хостера, в зарубежном ДЦ. Самый, на мой взгляд, безопасный вариант в плане доступа, но возможны проблемы с оплатой. Поэтому нужно выбирать "отказоустойчивого" хостера. Либо с возможностью оплаты криптовалютой, либо китайскую компанию. Но опять же есть риски колебаний валютных курсов, сложностей с техподдержкой и т.п.

"Серебряной пули" тут, как мне видится, нет. Придется взвешивать риски, что критически важно, а где их можно допустить. Если вопрос доступа к сервису критически важен - возможно придется держать резервный сервер в другом ДЦ и/или у другого хостера.

Еще стоит учесть риски с доменом. При усилении санкционного режима могут начать разделегировать домены, зарегистрированные на граждан России. Так что регистратора домена тоже нужно выбирать с учетом этого риска.

Так он же вам английским по консоли пишет что не знает что такое index, вот проблемная функция:

function autoWrite() {
    // Script
    mainContainer.innerText = text.slice(0, index);
    index++;

    if(index > text.length - 1) {
        index = 0;
    }

    // Text Style
    mainContainer.style.color = '#414141';

}

Подозреваю что вы забыли определить глобальную переменную index (хотя глобальные переменные - зло).

UPD: поправил. https://jsfiddle.net/xjas4u6r/
Упреждая следующий вопрос: innerText не понимает HTML-тегов.

Это реализуется на любом языке программирования. Товары, новости и пр. сохраняются в БД. Код сайта читает данные из БД и отображает их пользователю. Другой код (админка) предоставляет инструменты редакторам/администраторам/менеджерам для добавления/редактирования/удаления данных в БД.

10000 часов до мастерства.

Но 8 часов в день, считая еще плюсом время на учебу - это очень тяжко. Отдыхать тоже нужно, так что обязательно планируйте время на сон (7-8 часов минимум), физические тренировки (дома или в зале) и просто отдых. Так что, посчитаем 4 часа в день. Если заниматься и по субботам тоже, то можно планировать 300 дней в год. Итого 1200 часов в год, 3000 часов до окончания университета. Это вполне хороший запас времени. Я думаю что за это время вполне можно добраться до мидла.

Теперь о том кто же такой мидл, чему учиться. Ключевое понятие - самостоятельность. Джуниору нужна точная постановка задачи - сделай так. И он переводит с русского (или английского) языка на язык программирования. По сути это близко к понятию "кодер". Джуниор может очень хорошо знать язык, технологии, писать прекрасные программы. Но пока он не принимает самостоятельные решения - он остается джуном.
Мидл умеет принимать собственные решения в пределах своего модуля. Тут уже начинаются основы проектирования: SOLID, KISS, YAGNI, MVC, MVP и т.п. страшные слова. Главный критерий - практика. Поэтому я бы советовал реализовывать в качестве практики какой-нибудь долгоиграющий проект. Это даст важную практику работы "вдолгую", позволит ощутить такую радость как "сопровождение". И сразу же учиться применять стандартные для вашего стека инструменты, будь то composer, npm, gradle и др. Обязательно git. Обязательно приучать себя писать тесты (юнит-тесты, функциональные и интеграционные) - это будет большим плюсом в дальнейшем. Плюсом читать умные книги и сразу же применять то что в них написано на практике. Это в первую очередь "Программист-прагматик", "Идеальный программист", "Чистый код", "Чистая архитектура", что-нибудь по TDD. Плюсом документацию по выбранным технологиям. Несмотря на то что это скучно, в документации часто можно найти важные нюансы, которые редко встречаются в других источниках. Документацию можно заменить хорошими книгами по той же теме. Но тут сложно советовать абстрактно, не зная какой стек вы выбрали.

Суть в том, что браузер использует JavaScript для формирования страницы. Если нужно скачать только данные - то найти запрос, который браузер шлет в бэкэнд и скачать данные им (там будет JSON или что-то подобное)

Если нужно скачать сайт прямо с оформлением - то проще всего написать небольшую программу, которая запустит реальный браузер (chrome точно так можно, насчет firefox не уверен) в автоматическом режиме и может имитировать в нем любые действия пользователя. См. chromedriver. Если ничего не путаю, то Selenium такое умеет.

Эти подходы не только для крупных проектов, они вообще для любых проектов.

1. БД обновляется через миграции. То есть, вы пишете SQL-скрипты, которые нужно выполнить в БД (создание новых таблиц, новых колонок, добавление записей в справочные таблицы, удаление ненужных более колонок и т.д.), а система миграции (вот не в курсе есть ли такая у WP, но совершенно точно есть у более продвинутых Laravel/Doctrine) контролирует что скрипты миграций были выполнены (и выполнены в правильном порядке). Можно скрипты прокатывать и руками, но в таком случае всегда есть вероятность ошибки.
   
2. Разделение исходного кода и собранного кода. У вас есть исходный код и работает разработчик с исходным кодом проекта. Тут путаница возникает в том числе потому, что у PHP исходный код и исполняемый код - суть одно и тоже. Но концептуально разделять это стоит. После того как исходный код написан, выполняется сборка (в частности на этом этапе отрабатывают SCSS/gulp/webpack и т.п. инструменты) и получается код для загрузки на сервер. Поэтому задача "поменять цвет кнопки" решается изменением одной строчки в исходном коде, затем пересборкой и перезаливкой собранного кода на сервер
   
3. Пересборку и перезаливку можно делать вручную. Но лучше если этим будет заниматься CI-сервер. Бесплатно CI предоставляет, например, гитлаб. Насчет гитхаба/битбакета не в курсе, не интересовался. Суть в том, что при изменении исходного кода в репозитории, автоматически (или вручную) запускается некоторый процесс (pipeline), выполняющий сборку-тестирование-деплой новой версии. Разумеется, чтобы это все работало сначала придется потрудиться, разобраться, написать нужные скрипты и конфиги. Но для большого проекта это незаменимый инструмент.
   

Это зависит от того как организована система хранения. Может получиться так, что искать по хэшу она будет быстрее чем по обычному числу т.к., например, может использоваться quad tree или octree. Если использовать число, то старшие биты будут плюс-минус одинаковы, что приведет к тому что данные скопятся в одной из веток дерева, а другие будут пустыми. А если дерево еще и распределенное - это будет означать что данные неравномерно распределены по нодам. Хэш такую проблему решает сразу. Для гита вероятность коллизий хэша пренебрежимо мала, практически нулевая.

В случае гитхаба, вероятно, данные хранятся в гит-репозитории. Поэтому хэш коммита в ссылке - естественное и логичное решение. Насчет фиддла сказать не могу - но в принципе тоже, скорее всего, что-то аналогичное, только закодировано не в 16-ричную систему, а в 32-ричную (5 * 8 = 40 бит)

Плюс хэш можно генерировать независимо от хранилища (по содержимому + времени, например). А для генерации последовательных идентификаторов нужно обращаться в систему хранения, которая должна следить за их уникальностью и, таким образом, может стать "узким местом".