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

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

А тут никто никуда не ходит вообще. У вас есть скоуп функции и наружу вы ходить не можете. Вы можете снаружи прокидывать нужные переменные в скоуп вашего замыкания (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()

нижнее подчеркивание у функции убираем и все уже чуть получше.

В целом же названия надо делать осмысленными. То есть если не знаем как что назвать, просто формулируем что мы хотим сделать (на английском языке), и исходя из этого уже выдумываем названия:

// calculate sum
$sum = calculateSum(); 
// generate report for premium users
$sum = generateReport(new PremiumUsersSpecification());

как-то так. Ну а что как, у меня такие правила:

- константы - SCREAMING_SNAKE_CASE
- названия объектов - UpperCamelCase
- названия переменных, методов, функций и т.д. - lowerCamelCase
- таблички/поля в бд, json, yml - snake_case

Зарплата - это последний критерий, о котором я бы думал, уходя в болото битрикса.

Ведь тот же метод $em->persist(...); мы используем и для обновления записи.

Вообще-то нет. По умолчанию persist используется для того, что бы добавить сущность в UnitOfWork. Вызывая его доктрина начинает разбираться, нам надо просто замерджить сущность в текущий UoW или добавить ее в очередь на вставку.

Вызывать persist при обновлении не нужно вовсе, можно обойтись merge, и только если у нас используется политика отслеживания изменений deferred-explicit, но это нужно в очень редких случаях. Например когда в рамках одного запроса мы должны загрузить из базы сотню-другую сущностей а обновить одну. В этом плане данная политика отслеживания изменений сильно ускоряет работу UoW, так как мы явно указываем за какими сущностями нам следить (сложность алгоритма UoW - O(N), так что чем меньше N тем быстрее работает). Единственное НО - это сильно усложняет работу с entity manager (по хорошему em должен быть только в репозитории), и в принципе ломает красивую концепцию persistence ignorance, так что использовать ее нужно только тогда, когда есть проблемы с производительностью UoW.

через каждые 30 насколько изменится скорость переноса?

Да, это ускорит работу. Единственное что, если вы занимаетесь вставкой большого количества объектов, имеет смысл после каждого flush делать clear, отчищать unit-of-work, поскольку вставленные сущности будут крутиться в нем, и после каждого flush их количество будет увеличиваться и скорость будет падать.

«сокса» это socks5?
curl --socks5 127.0.0.1:1080 http://ifconfig.me
где 127.0.0.1:1080 — адрес socks5
Либо замените ifconfig.me на https://ip.lindon.pw, если первый вдруг не отвечает(у него такое случается), но со вторым просьба не злоупотреблять, это мой собственный сервер и я его больше для себя и таких проверок держу(обратите внимание, что у меня https, а не http)

Ну, во первых это проблема не fos_rest, а сериализатора. По умолчанию jms используется в fos_rest.

В гугле по запросу "jms_serializer naming_strategy" вы найдёте эту ссылку https://github.com/schmittjoh/JMSSerializerBundle/...
Пройдя по которой вы обнаружите следующий кусок конфига

property_naming:
    id: ~
    strategy: camel_case|identical
    camel_case:
        separator: _
        lower_case: true|false
    enable_annotation: true|false
    enable_cache: true|false

Удачи!

string date ( string $format [, int $timestamp = time() ] )

Поскольку вы неправильно используете функцию date(), сравниваются просто строки. Строки сравниваются посимвольно. Ноль меньше, чем два, поэтому сравнение немедленно возвращает true.

Правильно сравнивать даты так:

$first = DateTime::createFromFormat('d.m.Y', '01.01.2016');
$second = DateTime::createFromFormat('d.m.Y', '25.12.2015');
var_dump($first < $second);

Или так:

var_dump(strtotime('01.01.2016') < strtotime('25.12.2015'));