Daria Motorina

$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 - тогда данные не пропадут при удалении контейнера.

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

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

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

Так вот, это - еще хуже. Для начала, часть ошибок этот код все равно не отловит. Но это даже не самое главное. Главное - что вот это вот "Файл не найден" не имеет ни малейшего смысла. Пользователю оно ничего не скажет. А программист о нем не узнает. А если и узнает, то ничего не поймет! Какой файл? Где не найден? По какой причине? Системное сообщение об ошибке содержит массу бесценной информации помогающей идентифицировать ошибку, сообщая нам где она произошла, какой файл не найден, по какой причине не найден. Выдавать вместо этого огрызок "файл не найден" - это мазохизм.

И вот тут мы должны произвести натуральную революцию в неокрепшем детском мозгу: сообщение об ошибке не твой враг, а твой друг! И надо добиваться его появления всеми возможными способами! В том числе и выпиливанием бессмысленных проверок. Проверку можно ставить только если у нас есть сценарий обработки ошибки: к примеру, вместо этого файла мы можем заинклюдить какой-то другой, дефолтный. Тогда да - проверка имеет смысл. Но если это самый обычный инклюд, который всегда должен быть на своем месте, то его отсутствие обязано вызывать ошибку! Чтобы она была сразу показана на дев сервере и тут же исправлена. Чтобы она была записана в лог на продакшене и тут же исправлена.

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.

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

нельзя создать объект из интерфейса

затем, что корневой каталог имеет свойство меняться.
да и dirname(__FILE__) прекрасно заменяется на __DIR__

В общем, вот такой конфиг завелся :

version: '2.0'
services:
    rabbitmq:
        image: rabbitmq:3-management-alpine
        container_name: rabbitmq
        volumes:
            - ./.docker/rabbitmq/etc/:/etc/rabbitmq/
            - ./.docker/rabbitmq/data/:/var/lib/rabbitmq/
            - ./.docker/rabbitmq/logs/:/var/log/rabbitmq/
        ports:
            - "5672:5672"
            - "15672:15672"
    nginx:
        image: nginx:latest
        ports:
            - "8000:80"
        # монтируем директории, слева директории на основной машине, справа - куда они монтируются в контейнере
        volumes:
            - ./hosts:/etc/nginx/conf.d
            - ./www:/var/www
            - ./logs:/var/log/nginx
        links:
            - php
    php:
        # у нас свой образ для PHP, указываем путь к нему и говорим что его надо собрать
        build: ./images/php
        links:
            - mysql
            - rabbitmq
        volumes:
            - ./www:/var/www
    mysql:
        image: mariadb
        ports:
            - "3306:3306"
        volumes:
            - ./mysql:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: secret
        environment:
            PMA_HOST: mysql
            MYSQL_USERNAME: root
            MYSQL_ROOT_PASSWORD: secret

Далее ставим плагин , дающий возможность изучать происходящее в кролике используя браузерный UI.
Для этого заходим в контейнер docker exec -it rabbitmq bash
Ставим плагин rabbitmq-plugins enable rabbitmq_management
Можно убедиться , что все установлено rabbitmq-plugins list
Нам покажут список установленных плагинов.
После заходим по адресу localhost:15672 (пароль-логин , по умолчанию guest).

Кролик готов! :)

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

""" – ошибка, должно быть "\"" или '"'
"\" – ошибка, должно быть "\\"
и все такое

Все приватные данные выносятся в конфиг. Конфиг исключается из под контроля git. Пример конфига со звёздочками вместо данных кладется в репозиторий.

В качестве конфига может использоваться обычный *.java класс.