Daria Motorina

Стилизовать нативное окно подписки браузера невозможно.

Однако вы можете сделать собственное окно подписки (свестав и стилизовав его по своему усмотрению) и затем, с помощью Notifications API вызывать нативное окно подписки.

По такой схеме работают многие коммерческие сервисы пуш-уведомлений.

1. Протокол mailto: (линк) и параметры:

• subject – тема письма;
  
• body – текст письма;
  
• cc – копия письма;
  
• bcc – скрытая копия письма;
  

2. Google Forms
3. Свой/сторонний обработчик форм.

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

вначале читай описание протоколо soap, потом php библиотеки soap. Можно использовать её в чистом виде, но лучше через обертку вроде https://docs.laminas.dev/laminas-soap/

Понятия master и slave имеют смысл только в контексте репликации. Нет репликации - нет мастера.

Папка на диске Д названа русскими буквами? Вот и результат, я уже давно отвык держать проекты в папках с именами кириллицей, теперь ваша очередь.

PHPmailer никак не зависит от мамп/опенсервер/ etc.

https://ospanel.io/docs/#smtp и указываете данные своего smtp (хоть любого сервиса, хоть локально поднимите).
или укажите сохранять письма в папку, а в настойках PHPmailer не используйте smtp.

$a = 1;
echo -$a;

Нельзя просто так взять и просто проверить, да?)

Да, отделяем абстракцию от реализации.

"Для программистов" вряд ли существуют, по крайней мере в том виде, в котором Вы себе представляете. Я говорю о

например что его гложит в javascript'е, с чем затык, почему не получается

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

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

Вопрос профессионального выгорания особо остро стоит у программистов - тут я соглашусь, специфика такая. Но это не значит, что для лечения нужно быть с головы до ног погруженным в IT. Высококвалифицированному психотерапевту изучить особенности профессионального выгорания программистов от а до я не составит труда за неделю-другую, и для этого ему совсем не нужно знать javascript)

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

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

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

3. ansible, gitlab-ci

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

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

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

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

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