Алексей Скобкин

pveversion -v

Pagekit

Есть российские ОС на базе Linux, по сути - пересборка общеизвестных дистрибутивов, иногда с достаточно глубокой переработкой. Самый известный и долгоживущий - AltLinux: www.altlinux.ru Стоит учитывать следующие факторы:

- не всё ПО имеет аналоги под Linux. Многие программы, особенно написанные в российском госсекторе, работают только под Windows. Некоторые из них удастся запустить под wine (программа под Linux, эмулирующая Windows API), но далеко не все
- потребуется переучивать IT-персонал: системных администраторов, суппортов
- потребуется переучивать пользователей. В силу зачастую низкой компьютерной грамотности пользователей даже незначительное изменение интерфейса может сильно затруднить их работу
- под Linux есть достаточно качественный аналог MS Office - Openoffice/Libreoffice. Но для сложных документов совместимость может быть неполной

Советую делать переход постепенно, сначала отработать на небольшом подразделении. И, вероятно, для какого-то специфичного ПО несколько машин с Windows всё-таки придётся оставить.

Разница из-за различных методик сбора данных. Рейтинг TIOBE строится на подсчете количества поисковых запросов, содержащих название языка (https://ru.wikipedia.org/wiki/Индекс_TIOBE). Github, полагаю, ориентируется на количество коммитов в проекты, написанные на соответствующих ЯП. Stackoverflow, скорее всего, ориентируется на теги.

Особо зацикливаться на эти рейтинги, честно говоря, не вижу нужды; максимум, на что они годны - это служить аргументом в разных фаллометрических баталиях на тему "ЯП1 vs ЯП2". В реальной жизни лучше ориентироваться на количество/качество предлагаемых вакансий (если хочется программировать профессионально) или на личные предпочтения (если хочется программировать "для души").

когда бандл большой но не на столько чтоб делать 2 бандла

Читаем symfony best practice - у вас должен быть всегда только один бандл. AppBundle. Все остальные варианты бандлов - только для самодостаточных вещей, которые вы хотите реюзать между проектами. Причем как правило "в бандл" заранее не стоит это заварачивать а уже когда будет видно что получилось что-то реюзабельное.

Далее, разделение по функциональности - дело хорошее. Вот только не стоит забывать, что контроллеры к приложению имеют весьма посредственное отношение, это просто UI. Имеет смысл разделять по слоям/зонам ответственности + по функционалу. так у нас может быть такая структура:

Controller
    User
       UserController
Entity
   - User
       - UserProfile
       - UserCredentials
       - User
       - UserRepository (только интерфейс)
   - Downloads
       - какие-то сущности

Словом, делайте так, как вам удобно. Но лучше пусть в одной директории будет 10 файлов, чем если бы у нас было 5 директорий и по 1-2 файла в каждом.

Переменные принято объявлять в начале файла (и не важно класс это или просто файл с функциями)

А каковы границы тут ?

А тут никто никуда не ходит вообще. У вас есть скоуп функции и наружу вы ходить не можете. Вы можете снаружи прокидывать нужные переменные в скоуп вашего замыкания (use ($tax, &$total)). То есть вы просто даете вашему замыканию попользоваться этими переменными.

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

p.s.
Но в вашем случае в этом нет ровным счетом никакого смысла. Если вам надо просто сумму посчитать - вам стоит использовать функцию array_reduce, правда тогда придется изменить еще и способ, как вы храните ваши "продукты". А еще вот эта штука:

$pricePerItem = constant(__CLASS__ . "::PRICE_" .
                    strtoupper($product));

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

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

Налоговые каникулы для IT ИП действуют не во всех регионах. Если заниматься серьезно, и выводить серьезные суммы, то можете привлечь внимание соответствующих органов, тем более что незаконное предпринимательство у нас наказуемо. С ИП головной боли не много, уплата налогов головной болью не является, сейчас все автоматизировано сервисами типа Эльбы и Мое Дело.

Не забыли добавить аннотацию к классу?
@ORM\HasLifecycleCallbacks()