Евгений Алёшин

Я проникся ООП когда писал одну программулину в процедурном стиле и внезапно понял что не могу разобрать свой собственный код, написанный вчера. Потратил на рефакторинг 12 часов и после этого код стал больше похож на английский язык, чем на непонятный набор букв, точек, цифр и скобочек. Так что в идеале нужна практическая задача на чистом языке, без фреймворков.
Раз речь о PHP, попробуйте написать свою ORM. Простейший построитель запросов для CRUD, но универсальный. Как минимум наследование точно поймёте.
По паттернам я сейчас толкового курса сходу не нашёл, но не переоценивайте их значимость. Лучше почитайте (посмотрите видео) о том, что такое SOLID.
Когда придёт понимание что такое наследование и зачем оно нужно, тогда можно и про паттерны почитать, но как по мне, реально интересен только Одиночка. Все остальные это просто правильные способы применить наследование, и выглядят довольно очевидными.

Ландшафт можно сгенерировать так, например https://www.playfuljs.com/realistic-terrain-in-130...
А для карт есть фреймворк leaflet.js

Но я бы карты всё же генерировал заранее в каком-либо трехмерном редакторе, там больше возможностей. https://www.blendernation.com/2019/04/01/generatin...

А потом - резал на тайлы и показывал бы через Leaflet.

Функция str_pad дополняет входную строку до нужной длины любым символом, слева и/или справа.

Этого достаточно для решения поставленной задачи.

$resultArray = [];

for ($i = 1; $i <= 9999; $i++) {
  $resultArray[] = str_pad($i, 4, '0', STR_PAD_LEFT);
}

var_dump($resultArray);

пояснение функции

str_pad(
  $i,           // текущее число (оно будет приведено к строке автоматически)
  4,            // дополнить до 4-х символов
  '0',          // нулями
  STR_PAD_LEFT  // слева
)

С циклом, надеюсь, знакомы.

вопрос какой-то странный, берешь фетч, получаешь ответ, диспетчишь экшен с результатом, и у тебя данные в сторе, твои компоненты подписаны на стор и мапают его куски на пропсы твоего компонента, дальше авторерендер

var action = {
  type: 'ADD_USER',
  user: {name: 'Dan'}
};

// Assuming a store object has been created already
store.dispatch(action);

Свойство background перекрывает свойство background-size. Попробуйте вместо background указывать background-image.

Как вариант, прописать каждому сайту алиас на стили и js

<VirtualHost *:80>
        DocumentRoot "/var/www/sites/site1"
        ServerName "site1.ru"

        Alias /styles /var/www/sites/styles
        Alias /js /var/www/sites/js
</VirtualHost>

<VirtualHost *:80>
        DocumentRoot "/var/www/sites/site2"
        ServerName "site2.ru"

        Alias /styles /var/www/sites/styles
        Alias /js /var/www/sites/js
</VirtualHost>

На абстрактный ответ мог бы ответить абстрактно, но отвечу с вариантами.
В зависимости от задачи, я опишу не для сервисов или больших сайтов\ресурсов.
Советую так же прочесть вот эту статью: frontender.info/building-a-better-responsive-website

Обычно использую bootstrap, который дополняю своими стилями, к примеру, сразу удаляю\перекрываю .row с его -15px margin'ом по сторонам, добавляю класс padding-0 для убирания в некоторых блоках padding'a у col- (который стандартно по 15px).

Стандартно учитываю разрешения - HD, ноутбучное 1366 и свое чуть меньше 1366 (у меня пуск справа:) ), 1024-960 - старые мониторы и нетбуки, смотрю в диапазоне 768px-960 для некоторых планшетов и телефонов, и меньше 768 для телефонов. Тут дизайн один, через media onlyscreen убираем с загрузки ненужные части.
Если все сверстано правильно и добавлены везде классы, то сайт будет полностью адаптивным.
Для тестов меньше 768px проверяю через iphone 5 и старенький android-телефон. (Через Toggle Device mode в Google Chrome получаешь очень сильно разительные результаты в сравнении с устройством - браузеры то другие, хотя большие косяки всплывают сразу.)
Тут кстати еще (мобильная) кросс-браузерность очень тонкий вопрос. Стиль у каждого браузера свой, особенно у всяких элементов типа input, так что тоже требует проверки и состояний тоже (placeholder, цвет текста в поле).

Нужно ли это? Безусловно - на любом сайте, в любой отрасли половина трафика с мобильных устройств, это уже стандарт качества, на мой взгляд:)

Недавно отвечал в соседней теме. Скопировал сюда.

1. Айдишник можно использовать на странице один раз. Два и более раза — это уже не валидно. Поэтому, если понадобится переделать сайт по схеме «три колонки → блок от края до края → снова три колонки» на одной странице, этот кусок кода придется полностью переписывать.

2. На один элемент можно повесить только один айдишник, а классов на один элемент можно повесить много. Получается, если вешать стили на id, мы лишаемся гибкости.

3. У айдишников слишком высокий вес селектора. Если вам понадобится контекстно перестилить что-то внутри колонки, то вероятнее всего вы впишите в селектор айдишник и потом, чтобы обнулить овверрайд или сделать новый, вам придется использовать этот же айдишник (или поставить другой). Классами перебить селектор с айдишником не получится — не хватит веса. Айдишник будет множиться в css-ке и реффакторить становится всё сложнее.

Поэтому выводы: 1) никогда не вешать на айдишники стили; 2) если нет выбора, писать селектор так: div[id="left"] {...} — этот селектор медленнее, чем селектор по классу, но и вес у него на равне с классом. Т.е. это меньшее зло, чем айдишник в стилях.