Александр

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

1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.

3. ansible, gitlab-ci

4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

5. никак. Она с докерами никак не дружит.

6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

> Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

Совсем высокоуровнего - да, так.

Опа

PHP поддерживает сравнение объектов DateTimeInterface напрямую, в данном случае стоит пользоваться именно этим:

$format = 'd.m.Y H:i';
$tz = new DateTimeZone('UTC');

$d1 = DateTimeImmutable::createFromFormat($format, '01.01.2019 15:24', $tz);
$d2 = DateTimeImmutable::createFromFormat($format, '02.01.2019 13:56', $tz);

$newer = $d1 >= $d2 ? $d1 : $d2;
echo $newer->format(DATE_ATOM);

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

Сложно. Невозможно. Сложно. Не стоит.

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

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

Если хочешь заниматься чисто фронтом, то про "сделать сайт" просто забудь, кроме статических сайтов-визиток.
Если хочешь клепать говносайты для невзыскательных клиентов - учи вродпресс.
Если хочешь делать нормальные сайты с фронтом на реакте - то кроме фронта учи пхп, mysql и ларавель. Но про "сделать сайт" придется на годик забыть

Полагаю это связано с переводом часов. Now - после 30 октября, а created - ДО

Тут перебор циклом, но не while() и не for() — может, прокатит?

// случайные:
const myArray = [...Array(3)]
  .map(
    row => 
      [...Array(3)]
      .map(
        el => Math.floor(Math.random() * 10)
      )
  )
;

// диагональ, где оба индекса равны:
const diagonal = myArray
  .map(
    (row, rowIndex) => 
      row
      .map(
        (el, elIndex) => rowIndex === elIndex ? 1 : 0
      )
  )
;

валидацию нужно делать и на клиенте (для отзывчивости, да и нечего гонять невалидные данные по сети), и на сервере (собственно для проверки).

Удивительно, как люди машут на себя хвостом уже в 37. С другой стороны, тут и 30-летние нытики не редкость.

По теме: в веб не идите ни в коем случае.
Идите в 1С, например, у меня есть много примеров ребят под 40, которые быстро подхватили эту тему и добились в ней успеха.

И добавьте себе пункт «Повзрослеть», я как будто малолетнего вайтишного студента прочитал (вру, не читал). Просто поразительно, как к 37-ми можно так инфантильно относиться к своей жизни и, в частности, к своим знаниям.

Это самовызывающаяся функция

Потому что childNodes это не только дочерние тэги внутри элемента. Это и текст внутри элемента. В вашем случае каждый перенос строки это отдельная нода. Если сделать так, то будет как вы хотите:

<div id='row'><div class='col-tm'>apple</div><div class='col-tm'>banana</div><div class='col-tm'>cranberry</div></div>

Для получения HTMLCollection есть метод children и тогда текст без тэгов внутри элемента учитываться не будет:

var elem_apple = first_column.children[0];

$data = [
   [
      'Name' => 'Alex',
      'Age' => '26',
   ],
   [
      'Name' => 'Alex2',
      'Age' => '20',
   ],
];