Николай Егоров

Чтобы была поддержка в IE svg спрайта из внешнего файла нужно использовать полифилы https://github.com/jonathantneal/svg4everybody или https://github.com/Keyamoon/svgxuse

1. Отдельными приложениями.
2. Папками в проекте.

Listener — слушатель одного или более событий, некий такой атомарный исполнитель. Не знает на что он подписан, но легко управляется через конфигурацию. Если разные слушает — нужно самому логику разделения обработки писать.
Subscriber — подписчик имеет реализацию интерфейса SubscriberInterface с методом getSubscribedEvents(), то есть сам объект слушателя знает, на что он подписан и какие методы какие события будут отрабатывать

По сути одно и тоже, но такая разница иногда пригождается. Иногда нужно иметь контроль снаружи, иногда наоборот.

Теги — отдельный механизм контейнера. Проставляя тег на набор сервисов — мы во время компиляции контейнера можем достать помеченные определенным тегом сервисы и заинжектить в др сервис (очень часто используется мной например), отсортировать по допатрибутам или сделать любую иную логику
https://symfony.com/doc/current/service_container/...
Ну например есть десяток сервисов, которые обрабывают каждый свой тип файла, еще и лежат в разных бандлах. Как получить их в одной фабрике? Правильно — проставить им тег, в компиляторе приложения достать все и в фабрику засунуть. При появлении нового сервиса с тегом - он автоматом будет в фабрике.

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

В начальном варианте Вы пытаетесь встроить форму, а не наследовать её. В этом случае поля были бы доступны для вывода так: form.commonFields.titleLink.

Вашу задачу наследования решает именно второй вариант

.container {
   > .div{
      font-size: 16px;
   }
}
//или
.container {
   & > .div{
      font-size: 16px;
   }
}

Итак, поразбирался-покопался сам - для симфони есть Sonata - несколько больших бандлов для создания админки. В том числе там есть функционал схожий с RBAC.

Но само решение спорное:
1. Sonata слабо развивается, и выглядит брошенной
2. Чем сложнее становится логика в проекте - тем меньше помогают (и начинают мешать) решения из коробки
3. Сами разработчики Симфони рекомендуют использовать Voters

Вот такие дела.

P.S. Официальная документация по Sonata устарела, и по ней её не поставить. Мне помогло это руководство с хабра.

    Привет!
    Про возраст - забей париться и никого не слушай на тему того кто и кем должен быть во столько и столько.
Я работал в одной крупной конторе и однажды к нам пришел мужичок лет за 40 на джуна. С нуля. В команду 20-30 летних. Ему было сложно вписаться в коллектив, но никто его не троллил, не избегал и т.д. Ему захотелось попробовать что-то новое и все получилось отлично. Стартанул он очень хорошо и за год с небольшим добрался до тим-лида. Если есть желание и интерес - все получится. За бугром люди и 40 и в 50 легко приходят в новую профессию. Это у нас есть такой стереотип, что после 30 ты нафиг никому не нужен. Вздор.
    Лично я тоже пришел в айти сферу в 27, и ушел в веб разработку. Full-Stack PHP Developer себя называю. Тоже есть пунктик "учиться учиться учиться". Поэтому. Просто учиться - бестолку. Это тоже самое, что в сериалы смотреть или в игры играть. Времяпровождение. Интересно - да, полезно - совсем чуть-чуть, сделает ли программистом - нет. Без практики все вылетает из головы довольно быстро. В голове остается лишь знание "ага, это по силам понять, я как-то врубался в это уже, но что-то нифига не помню...." =)
    Очень вводят заблуждения все эти высказывания о том, что надо учить и что должен знать программист в определенном возрасте, на определенной ступени профессионализма и т.д. 99% - тоже вздор =) Зачем нужно знать паттерны программирования? Чтоб выбрать хорошее решение при проектировании сложного кода, например. А будешь ли ты этим заниматься вообще? Для того, чтоб делать сайты, при чем довольно сложные, вполне достаточно въехать что такое MVC, и использовать какой-нибудь популярный фреймворк. Надо ли знать алгоритмы? Тоже зависит от рода деятельности. Мне за почти 10 лет веб-дева это знание ни разу не пригодилось, хотя работал над реально оч. большими и тяжелыми проектами. Есть люди, которые удачно продают себя на апворке за $50-60 в час называя себя веб-программистами и специализируясь исключительно на Вордпрессе. То есть по факту не кодят, а собирают сайты из конструктора, допиливая темплейты из html/css/php ( минимум php ).
    Очень важно найти свою специализацию. Что больше нравится - backend или frontend и найти удобные и комфортные для себя инструменты. Если бэкэнд - именно PHP - попробовать Laravel, Yii2, Symfony. Почувстовать что твое, что комфортно. Если фронт - пощупать Vue, Angular, React. Стоит выбрать "свой" инструмент и прокачиваться в нем. Маленькая заметка на тему PHP. Есть гораздо более удобные языки для разработки. "Голый" PHP - это для фанатиков. Сейчас современный PHP - это уже конструктор, где приложение собирается из чужих пакетов. Но самому с нуля на нем что-то делать - не очень =) Попробуй Python для бэкэнда для сравнения ( Django или Flask ). Совсем другое ощущение от разработки. Если бы я раньше попробовал, то за PHP не брался бы. Но на фрилансе заказов на PHP все же сильно больше. Python еще хорош тем, что сфер применения намного больше. Еще варианты для бэка - Ruby (RoR), Go набирает популярность, Java, C# и т.д. Выбирать следует из того, куда больше тянет - в офисную работу или во фриланс, я считаю.
    Очень важно поработать в команде. В замкнутой среде не с чем сравнить свои успехи, не у кого подсмотреть реальные рабочие решения и т.д. Всегда будет оставаться какая-то не уверенность - а что если мое решение не хорошее? Насколько я профи? Работа в команде быстро показывает, что идеальных кодеров нет и каждое решение хорошо в определенных ситуациях.

Разошелся =) Мог бы еще накатать, но и так уже слишком много букв и пора мне в оффлайн =)
Удачи, все получится.

1.

$(window).resize(function () {
  if ($(window).width() < 576) {
    myMap.setCenter([57.767265, 40.925358]);
  }
});

2.

function myFunction(x) {
  if (x.matches) { // If media query matches
    myMap.setCenter([57.767265, 40.925358]);
  } 
}

var x = window.matchMedia("(max-width: 576px)")
myFunction(x) // Call listener function at run time
x.addListener(myFunction) // Attach listener function on state changes

Есть демо проект с набором best practies от авторов Symfony

https://github.com/symfony/demo

какие паттерны применяются чаще всего на практике и где

Сразу отмечу, что все это чисто мое имхо, которое может не совпадать с мнением окружающих. В контексте фронтенда обычно все довольно просто. По моим наблюдениям в среднем сайте могут иметь смысл:

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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