Flying

Укажите полный путь к исполняемому файлу php, например /usr/local/php или где он у вас расположен.

Если список типов у вас статический - замените EntryType на наследуемые entities через discriminator map, количество запосов это не снизит, но снизит количество join'ов и таблиц. Вот здесь можно подробнее почитать про него на русском.

А вообще судя по задаче у вас основная работа идёт не на уровне строк таблиц, а на уровне их анализа, Doctrine в этом случае - не лучшее решение т.к. задача больше про построение запросов, а не про удобную работу с сильно связанными данными. Тот же Excel с этим справится гораздо лучше :)

Поскольку entities по определению должны быть очень лёгкими объектами - здесь можно рассмотреть несколько вариантов решения:

1. Наиболее корректным будет вариант использования Doctrine event listener'а который будет слушать событие postLoad и производить локализацию. Что именно и как локализовывать - можно решить несколькими путями:
   1. Дать entity самой решать как это сделать и позволить event listener'у просто передавать ей объект-переводчик (Translator в случае Symfony). Чтобы понять надо ли передавать переводчик - стоит определить отдельный интерфейс, какой-нибудь TranslatableEntityInterface
      
   2. Указать event listener'у что переводить, к примеру через кастомные аннотации, решение более сложное, но более гибкое
      
   
   
2. Можно дать возможность entity дёргать какой-нибудь известный и доступный ей метод из которого она будет получать объект-переводчик, к примеру это может быть какой-нибудь StaticTranslatorProvider со статическим методом getTranslator(). В целом не очень хорошая идея, но работать будет
   
3. Можно не трогать entities вообще, а запрашивать локализацию непосредственно во внешнем коде. В целом плохой вариант, но тоже возможный
   

В своём описании вы не указали работаете ли вы только на ноутбуке или планируете использовать отдельный монитор, а ноутбук - в качестве второго экрана. Это важно т.к. в случае использования отдельного монитора (а для дизайнера это явно лучший выбор) существенно снижаются требования по качеству экрана самого ноутбука, а именно в нём в вашем случае будет основная загвоздка: для профессиональной работы с цветом вам необходим экран c покрытием sRGB максимально близким к 100% + возможность откалибровать экран ноутбука. Это решаемые задачи, но с отдельными мониторами эти задачи решаются существенно проще, да и работать с макетами (особенно широкоформатными) вам будет в этом случае намного комфортнее.

Если же вы предпочитаете работать исключительно на ноутбуке - вы не указали предпочтения по диагонали экрана и критичности для вас наличия hi dpi экрана (т.е. достаточно ли для вас разрешения 1920x1080 или же необходимо иметь 2560x1440 / 3840x2160).

В остальном я бы предложил вам обращать внимание на следующие моменты:

• дискретная видеокарта т.к. тот же Photoshop в новых версиях весьма интенсивно использует для работы видеокарту, а в случае встроенной вы будете отдавать для этих задач общую память что снижает эффективность работы. Посмотрите вот эту статью Adobe на предмет требований и списка совместимых карт.
  
• память - от 16Gb + возможность расширения (свободные слоты). Последние чипсеты поддерживают в некоторых моделях и до 64Gb, но такие модели стоят недёшево. До 32 Gb вполне поддерживают и чипсеты 3-4 летней давности
  
• память + быстрый SSD в вашем случае скорее всего будет важнее чем топовый процессор т.к. вы не занимаетесь 3D рендером, так что обращайте внимание на количество / расширяемость памяти и объём / скорость SSD диска. По поводу скорости - стоит смотреть review предварительно отобранных вами кандидатов, например на notebookcheck. Не забывайте что если есть вариант взять подходящий вам по остальным параметрам ноутбук, но с HDD - можно взять его и поменять HDD на SSD
  

Возможности расширяемости конфигурации обычно предоставляют "профессиональные" линейки ноутбуков (то что называют Mobile Workstations, к примеру Lenovo ThinkPad P series, Dell Precision и т.п.), но они как правило не соответствуют вашему требованию о "лаконичном дизайне" которому соответствуют лёгкие ноутбуки типа Dell XPS, но в них о расширяемости конфигурации речь уже не идёт, только если подбирать подходящий по параметрам. Поэтому вам стоит определиться какой из аспектов для вас важнее - это даст подсказку в каких линейках искать кандидатов. Затем выбираете shortlist по тому же Яндекс.Маркет и идёте читать обзоры по ним на Notebookcheck или другой подобный ресурс. Финально, если есть возможность, потом идёте в магазин чтобы пощупать выбранные варианты вживую и тогда принимаете решение.

Успехов!

Unit of Work - это паттерн определяющий логическую транзакцию т.е. атомарную синхронизацию изменений в объектах, помещённых в объект UoW с хранилищем (базой данных).

Если обратиться к исходному описанию этого паттерна у Мартина Фаулера - то видно что объект, реализующий этот паттерн отвечает за накопление информации о том какие объекты входят в транзакцию и каковы их изменния относительно исходных значений в хранилище. Основная работа производится в методе commit() который отвечает за вычисление изменений в сохранённых в UoW объектах и синхронизацию этих изменений с хранилищем (базой данных).

Паттерн Unit of Work как правило не является полностью самостоятельным, он обычно тесно связан с паттерном Identity Map, задача которого - сохранение карты созданных объектов, взятых из хранилища с тем чтобы гарантировать что одна единица информации из хранилища представлена ровно одним экземпляром объекта данных в приложении. Это позволяет избежать конфликтов изменений т.к. не допускает ситуации когда два объекта, представляющих один и тот же элемент данных в хранилище, изменены по-разному. Информация из Identity Map используется в методе commit() паттерна Unit of Work для вычисления разницы между исходными данными и накопленными изменениями.

Поскольку для вычисления разницы (и, соответственно, определения того что и каким образом должно быть изменено в хранилище) необходимо знать какие данные и как именно хранятся в объектах - как правило необходима также реализация паттерна Metadata Mapping, описывающего связь между содержимым хранилища (к примеру таблицами и столбцами базы данных) и классами / свойствами объектов.

Также, если данные в хранилище не являются независимыми (к примеру связи между таблицами в базе данных) - может потребоваться реализации ряда паттернов, отвечающих за сохранение информации о связях между данными (это паттерны раздела Object-Relational Structural Patterns в каталоге паттернов).

Подводя итог: сам по себе Unit of Work довольно прост в своём внешнем интерфейсе, но реализация его корректной работы требует предоставления множества дополнительных данных, поэтому миниатюрных примеров привести не могу.

Если говорить о PHP - то лучшей реализацией этих паттернов на PHP безусловно является Doctrine ORM. В частности в разделе Working with Objects документации Doctrine можно найти хорошее описание и множество примеров использования паттернов, описанных выше.

$subject = "23456/10000";
echo preg_replace('/^(\d{2})(\d{2})/','\1.\2',$subject);

У вас потенциально две ошибки в приведённом коде:

1. В качестве возвращаемоног типа вы указываете \Collection, тогда как коллекции Doctrine - это \Doctrine\Common\Collections\Collection
2. Ваш код не создаёт эту коллекцию, соответственно если это не entity созданная самой Doctrine при загрузке данных из базы - значение $meta - null. Корректный подход - это либо инициализировать коллекции в конструкторе:

public function __construct() {
  $this->meta = new ArrayCollection(); // где ArrayCollection это \Doctrine\Common\Collections\ArrayCollection
}

либо непосредственно в методе:

public function getMeta() : Collection
{
    if (!$this->meta) {
        $this->meta = new ArrayCollection();
    }
    return $this->meta;
}

В современных браузерах задача решается нативно через IntersectionObserver, для более старых есть polyfill.

asort, arsort, uasort

Если вкратце - то средствами CSS возможности сделать это нет и не будет, по крайней мере в обозримом будущем.

По поводу причин рекомендую почтитать вот этот ответ на SO, вот это обсуждение рабочей группы CSS и общую позицию CSS working group по этому и похожим функциям в CSS.

Решение которое можно применить в современных браузерах - это IntersectionObserver. Поддерживается в Firefox и Chrome, для остальных есть polyfill. Здесь можно посмотреть демку, здесь - её описание.

Ответы на ваши вопросы, очевидно, кроются в исходниках Doctrine:
Видно что поведение метода clear() зависит от того какую из сторон ассоциации вы очищаете. Также видно что если вы работаете с owner side ассоциации - то Doctrine создаёт новый snapshot.

Из кода методов getInsertDiff и getDeleteDiff видно что вычисление разницы происходит через сравнение snapshot'а с текущим содержимым коллекци, так что очевидно что в случае создания нового snapshot'а разница будет пустым массивом.

Проверить, вызывает ли сама Symfony метод clear() проще всего, поставив там точку останова.