Сергей Анисимов

Использую docker-compose file version 2

Создаем вручную сеть
docker network create myglobalnetwork

Описание сети добавить в каждый файл

networks:
  mynetwork:
    external:
      name: myglobalnetwork

Сервисам задаем алиасы для сетей по которым контейнеры будут общаться

services:
  nginx:
    build: ./nginx
    networks:
      mynetwork:
        aliases:
          - nginx.mynetwork
  postgres:
    build: ./postgres
    networks:
      mynetwork:
        aliases:
          - postgres.mynetwork

Здесь nginx.mynetwork и postgres.mynetwork являются внутренними dns адресами контейнеров

Access denied for user 'yii2user'@'localhost' (using password: YES)'

База вас слушает и слышит. И ей не нравится как вы представились.
Проверяйте, есть ли таковой пользователь, точно ли у него такой пароль.

Зачем разные части одного проекта помещать в отдельные ветки? Кажется, у вас неправильное представление смысла веток, которые используется в Git'е. Ветка в этой DCVS -- это всего лишь указатель на состояние рабочего каталога. И реализовать Work Flow, описанный вами на ветках Git'а не то чтобы сложновато, но зачем и для чего мучить бедный Git, который при каждом

git checkout
будет вам разворачивать поддерево то одного проекта в ваш рабочий каталог, то другого. Это во-первых, жутко неоптимально с точки зрения той же производительности, а во-вторых вы так совсем запутаетесь, тем более раз вы ещё включили в рабочий процесс слияния между этими ветками. Конфликтов слияния и трудностей таким образом можно достигнуть множество. Пожалуйста, обратите внимание на работающие подходы, используемые для разработки с использованием Git:

Если в ваших частях проекта выражена очень разная функциональность, то можно создать два отдельных репозитория (к примеру, fronted и backend), а затем, при необходимости, соединить их в один Git-суперрепозиторий в качестве его подмодулей.

Если одна часть -- зависимость от другой, то следует подключить эту зависимость submodule'ем или вообще поддеревом (см. главу 6.7. из книги Скотта Чакона - Pro Git).

Если это всё же монолитный проект, имеющий две части, например, первая часть содержит реализацию логики приложения в "./src/core", а вторая -- пользовательский интерфейс в "./src/ui", то их и вовсе не нужно разделять.

Необходимо config/main.php добавить

'container' => [
        'definitions' => [
            \yii\db\pgsql\ColumnSchema::class => [
                'class' => \yii\db\pgsql\ColumnSchema::class,
                'disableJsonSupport' => true,
            ],
        ],
    ],

Главная проблема - с чего начать? Можете подсказать как лучше все это организовать, какое ПО может пригодиться?

Ну вообще, на мой взгляд всё просто.
Пишем простенький интерфейс, который позволит выбрать файл с видео и загрузить на сервер (хватит даже PHP), на сервере с помощью ffmpeg вытаскиваем звук и отправляем обратно пользователю.
Свистоперделки можно прикрутить уже позже.

Если речь идёт о частном случае данной команды - то ответ довольно прост и легко ищется в исходных текстах. Вот как проверяется возможность запуска команды миграции, как видно - здесь используется метод canExecute(), посмотрев в который можно заметить что он контролируется флагом --no-interaction. Более того, банально вызвав help по этой команде можно было бы увидеть ответ на свой вопрос написанный прямым текстом:

Or you can also execute the migration without a warning message which you need to interact with:

    bin/console doctrine:migrations:migrate --no-interaction

Если же речь идёт об общем подходе к тому как запускать консольные команды которые требуют пользовательского ввода - то здесь ответ довольно находится в документации Symfony. Если посмотреть в исходные тексты ConsoleTester о котором говорится в этом разделе, то видно что основная идея - использование специального input'а. Таким образом решение становится довольно простым:

1. Получаем и клонируем Kernel
   
2. Создаём новый консольный Application
   
3. Создаём и конфигурируем ArrayInput
   
4. Запускаем приложение с нужным нам input'ом
   

Весь основной код для этого можно, очевидным образом, подсмотреть в bin/console самой Symfony.

Прочитать соответствующий RFC https://tools.ietf.org/html/rfc6455 чтобы понять, как происходит рукопожатие и какие байты в переданном сообщении за что отвечают. После этого будет понятно как написать реализацию. Я досконально уже не помню, но фактически от клиента приходит обычный http запрос с определенными заголовками, сервер разбирает этот запрос и если всё ок, то сохраняет открытое соединение в массив, если нет, то отправляет соответствующий ответ и закрывает соединение. Дальше по открытому соединению начинает сыпаться поток байтов от клиента их нужно разбирать, чтобы понять длину сообщения, сами данные переданные в фрейме, закончился фрейм или еще нет и тому подобное. Обратно также кодировать данные в поток байтов и отправлять по открытому соединению. Каждый байт в переданном фрейме несет определенный смысл. Обо всем этом подробно написано в RFC, но на английском. Вообще это хорошо примерно понимать как работает, но глупо писать такую низкоуровневую реализацию, когда есть готовые. Такие вещи развивают и поддерживают годами. Вы же не пишите HTTP серверы, а берете готовые вроде nginx и тому подобное.

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

Как сделать, что бы на стороне клиента, один websocket отвечал за сообщения, другой за статьи. (Или за эти два действия отвечает один websocket, тогда как мне на сервере это различать).

Вебсокет это низкоуровневая штука, для передачи потока байтов от клиента на сервер, в отличии например от HTTP, где есть заголовки и тело сообщения. Поверх вебсокета нужно делать еще один протокол или самописный или выбрать один из готовых. Это проще говоря, то как выглядят ваши фреймы (сообщения), которые вы отправляете с клиента на сервер и назад. Например клиент может отправлять такой фрейм:

["id", "controller/action", {param1: value1, param2: value2}]

в ответ получать
["id", "OK"]
если запрос был обработан успешно или
["id", "ERR", {error: "action not found"}]
если произошла ошибка. По переданному id в массиве, можно понимать, к какому запросу относится ответ.
Для уведомлений (событий) сервер может отправлять клиентам что-то такое
["user_added", {user: {...}}]
и т.д. Этот протокол необходимо придумать самому или выбрать из готовых (популярных пока нет) и написать его реализацию (клиентскую и серверную часть) или опять же взять уже готовую.

После того, как такой протокол будет написан, делаешь тоже самое, что делают обычные PHP фреймворки, пишешь роутер, который будет разбирать твои сообщения, понимать к какому контроллеру идет обращение, к какому экшену и вызывать его. В экшене уже будешь делать свои вызовы к базе данных.

Но это уже всё должно быть, просто возьми real-time фреймворк. Там за тебя написали и websocket сервер и протокол поверх него и экшены уже есть. Всё низкоуровневое уже готово. Бери и пиши приложение. В nodejs самый популярный это например https://github.com/socketio/socket.io, а в php я не знаю, но уверен, что тоже есть что-то популярное.

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

Ну так скрипт всё верно отрабатывает, вы в каждой итерации перезаписываете значение.

Если вы пляшете от . prc, то в каждой итерации вам нужно подниматься к родителю .parent('. gr_field') и в нём находить свои блоки и подставлять значения. Что-то типа

this.parent('. gr_field').find('.byn_').html(someValue)
this.parent('. gr_field').find('. rur_').html(someValue)
и тд.

ну и оптимизировать - this.parent('. gr_field') вынести в переменную.

Как-то так:
https://codepen.io/vitaliy_kirenkov/pen/daoWMP

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

Еще он хочет пошаговый алгоритм создания сайта. Возможно в итоге фиксед прайс захочет по каждому шагу, а не за проект в целом. Тоже в принципе норм. Ведь если заплатит полную сумму за проект, потом попросит залить его на хостинг, оптимизировать фоточки, еще чего придумает - уже сложней будет договариваться за доп.оплату, ведь он же считает что он уже заплатил за норм.результат, а оптимизированные его(!) фоточки и передача сайта на хостинг это считается частью закрытия проекта. Так что в данном случае Вы в выигрыше, если всё опишете подробно и с эстимейтами по времени/деньгам. И да, в т.ч. оптимизация графики и заливка на хостинг.
Мне например, за перенос вордпресс сайта с хостинга на хостинг 35 баксов оплатили. При этом чувак, который это попросил, не для себя делал, и с клиента себе 20 баксов тоже получил. А так, если делаешь сайт, по сути заливка на хостинг и оптимизацию графики вроде и не считают чем-то, за что надо отдельно платить...

В английском языке артикль играет очень важную роль
a proposal это не просто предложение, а это то, что самое важное в его словах на чём следует сконцентрироваться
Тоесть, выделен термин, общепринятый:
https://www.beewits.com/web-design-proposal/

От вас требуется составить Оферту (от англ. гл. offer - предлагаю)
https://en.wikipedia.org/wiki/Proposal_(business) или бизнес предложение не иначе.
https://ru.wikipedia.org/wiki/Оферта (РУС)
https://uk.wikipedia.org/wiki/Оферта (UA)

В ответ вы получаете или не плоучаете Акцепт https://ru.wikipedia.org/wiki/Акцепт

Оферта имеет юридическую силу

По сути он хочет платить по частям за каждый этап
Сейчас готов предложить фикс за прототип

А репликация бд за бугор нарушает ФЗ-152? (Нет). Чтение с локального, запись на удаленный.

Проще всего это сделать с помощью сценариев, например:

$model = new Feedback;
if ( --условие-- ) {
    $model->scenario = Feedback::SCENARIO_GUEST;
}

в моделе:

[['username', 'password', 'email'], 'required', 'on' => self::SCENARIO_GUEST]

и т.д.