Nick Murzin

Запросы query-buldera:

//достаем категории для главной
$categories = Category::where('display_home', 1)->get('id', 'name', 'slug');

//сюда будем схоронять посты, которые не должны повторяться
$posts_exclude = collection();

//для каждой категории
foreach ($categories as $category) {
	
	$posts_array[$category->title] = Post:: //ищем посты,
		whereHas('categories', function ($q) use ($category) { //у которых категория
			$q->where('id', $category->id); // одна из найденных для главной,
		})
		->whereNotIn('id', $posts_exclude->pluck('id')) // и постов нет в исключаемых
		->get('id', 'title', 'slug'); // только с нужными полями
	$posts_exclude->merge($posts_array[$category->id]); // добавили найденные посты в коллекцию с исключаемыми
}

Затем уже выводим массив с постами (псевдокод, это надо в блейд переписать):

<ul>
foreach ($posts_array as $category => $posts) {
	<li>
		$category //ключ основного массива - название категории 
		<ul>
		foreach ($posts as $post) { //значение элементов основного массива - набор постов из категории
			<li>$post->title</li>
		}
		</ul>
	</li>
}
</ul>

То есть, получаем n+1 запрос, где n - количество категорий.
Это в query-builder style. Можно, в принципе, написать один raw-запрос, но это уже за пределами топика.
Сложный одиночный query-builder запрос, полагаю, можно написать, но не вижу смысла, т.к. он будет не поддерживаемый. Да и закешить это всё можно, так что не в быстродействии дело.

p.s: Код негде проверить, писал по памяти. Надеюсь, ход мысли понятен

1. Классический матанализ (вузовский). База для всех следующих дисциплин.
   
2. Комбинаторика. База для теории вероятности.
   
3. Теория вероятности. Прямо база для азартных игр.
   
4. Теория графов. Понадобится в теории игр, необязательно изучать углубленно.
   
5. Теория игр. Прекрасные лекции есть у Савватеева.
   

Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

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

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

https://github.com/symfony/symfony-demo

о компоненте узнал из вашего вопроса, довольно интересный.

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

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

полистав пример тестового приложения понял что статусы хранятся в поле marking у сущности https://github.com/lyrixx/SFLive-Paris2016-Workflo...
поле имеет тип json_array. надо бы запустить этот тестовый проект, погонять. например для меня пока не очевидно как сделать фильтрацию сущностей по этому статусу, неужели отдельное поле/я добавлять и в подписчиках его менять.

также можно полистать исходники самого бандла, вот например метод для смены статуса https://github.com/symfony/workflow/blob/master/Wo...

На бэкенде: делаете rest-api с помощью Laravel.
На фронтенде: берете реакт + редакс и разрабатываете приложение, которое будет общаться бэком через АПИ.

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

По пунктам, что нужно знать и уметь:

• неистово учиться и гуглить
  
• сетевые технологии, на уровне маршрутизации, TCP/IP, DNS, SMTP и остальных протоколов начиная с 3 уровня модели OSI
  
• сетевые операционные системы (преимущественно семейства Linux) на уровне автоматизирования установки, обновления, настройки безопасности и мониторинга
  
• системы виртуализации (Xen, OpenVZ) и контейнеризации (Docker, Vagrant)
  
• настраивать сервера и мигрировать конфигурации, например перейти с Apache на Nginx, или с PHP на HHVM
  
• Chef
  
• Puppet
  
• Ansible
  
• Capistrano
  
• VCS
  
• AWS/OpWorks/CloudFormation/CodeDeploy, OpenStack
  
• Munin/Logstash/Kibana и другие связки для мониторинга
  
• Continuous delivery
  
• Программировать на Bash, Ruby, Python, Go, Perl, уметь понимать конфиги на самых экзотических языках, например YAML
  
• TDD
  
• продукты hashicorp
  
• автоматизировать создание и восстановление бэкапов баз данных
  
• масштабировать приложения по горизонтали (настраивать балансировщики, реверс-проксирование, шардинг и репликацию в базах)
  
• рассчитывать и оптимизировать издержки на поддержание инфраструктуры приложений
  
• видеть будущее инфраструктуры приложения и компании, двигать инфраструктуру в это будущее
  

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

Нужен спец по ООП и UML, который работал в своё время с MVC!

Наблюдаю тут несостыковку. Обычно когда говорят о UML - вот все эти вещи вроде контроллеров и т.д. расписываются на уровне компонентов. В UML обычно описывают только доменную логику, то есть то что важно.

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

Если вы хотите по UML фигачить (не понятно зачем правда, но это уже ваше дело), то имеет смысл брать какую ORM заточенную под ОО-first (по сути Doctrine2 из ныне существующих) и там уже развлекаться. Там профит будет.

p.s. забудьте об этой бесполезной для бэкэнда аббревиатуре MVC. Пока вы "проектируете контроллеры" - толку от него нет (ну то есть пока у вас логика работы с данными в контроллере).

Читаю GOF, Зандстру и т.п.

Почитайте Applying UML and Patterns - Craig Larman - замечательная книга. Еще дядю боба можете почитать (про SOLID). Если вас интересуют темы проектирования то это будет полезно. Еще раз уж заговорили о проектировании логики предметной области - Эрик Эванса - Предметно ориентированное проектирование.

Задача 1

1) композиция всегда лучше наследования
2) наследование нужно для того что бы организовать подтипы. Если у вас есть сущности которые по своей природе требуют наследование - то можно. А так - лучше его избегать. ООП как бы не про наследование вообще.
3) интерфейсы нужны для того что бы организовать инверсию зависимости и/или полиморфизм подтипов. У Лармана можете почитать про protected variations для того что бы понять зачем их юзать.

Задача 2

В UML отношения между типами очень легко и просто отображаются:

- Base[classname] - wrappers для обеспечения ровного обновления самого Yii в дальнейшем, не обращайте внимания.

Как это не обращать внимания если вы делаете UML ради UML? Пока я не увидел ничего от ООП на вашей диаграмке. Есть структуры данных с публичными пропертями, есть... контроллеры (внезапно) которые мутируют состояние этих структур.... Это не ООП - это процедурное программирование с классами.

для такой простой задачи я пилю UML исключительно в целях тренинга

Пока это выглядит как впустую потраченное время, поскольку вы выбрали не лучший инструмент (yii) что бы тренироваться проектировать ОО решения.

Я рекомендовал бы вам:

- Разобраться что такое ООП на самом деле (это не про инкапсуляцию. полиморфизм и уже тем более не про наследование ибо все это было еще до ООП и все это кроме наследования является важными принципами структурного программирования). Это про сокрытие состояния и управление зависимостями (связанность, coupling & coheasion у Лармана)
- Взять более подходящие для проектирования ОО решений инструменты (какой-нибудь модный нынче Laravel + Doctrine2)
- если хотите продолжать баловатся с Yii сделайте так, что бы логика предметной области ничегошеньки не знала о Yii, тогда вообще не нужно будет заниматься этими Base* классами. Почитайте про Row Data Gateway (это по сути предшевственник ActiveRecord) а именно как оно использовалось в контексте модели предметной области.

Есть ли под это паттерн?

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

Оригинальная книга по GoF в этом плане так себе, сейчас лучше смотреть в сторону Head First Design Patterns Ну и помимо паттернов нужно разобраться с общими принципами такими как закон деметры, SOLID, GRASP и т.д. Тогда понимание всего будет более системным.

Но у меня вопрос, как люди становятся этими самыми спикерами?

Берешь и выступаешь. Подаешь заявки на различные митапы, конференции. На митапах вообще без проблем, на конференциях могут попросить "демку" выступления, ну мол выступить перед коммисией (заодно фидбэк получить).

Собственно никакой магии. Либо просто случайно кто-то попросит что-то в духе "слушай, может выступишь?" либо сам.

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

Тем более по фронтэнду. Там сейчас ситуация такая что большинство не очень опытные разработчики. И что-то интересное им рассказать и полезное более чем легко.

вы путаете инверсию контроля и инверсию зависимости. Давайте по порядку кратенько.

Зачем нам нужны контроллеры или различные представления данных

Зачем нам в принципе контроллер? Что он делает? Для упрощения не будет воспринимать контроллер как "один объект" и вместо этого представим себе его как целый слой. Так же заменим слово "модель" словом "приложение".

Задача контроллера - принять и обработать запрос и выдать ответ. По сути в контексте WEB наш HTTP запрос и ответ это представление, которое хочет получить клиент (браузер, мобильное приложение, SPA, что угодно). HTTP - это интерфейс пользователя (UI) для нашего web-приложения.

Например что бы независеть от реализации клиента и что бы было удобно мы передаем даты в формате iso 8601 (пример: 2016-07-14T19:40:12Z). Это удобно что бы быть независимым от реализации клиента или сервера. Но это не удобно для нашего приложения. В приложении скорее всего нам удобнее всего работать с объектом типа DateTime. То есть приложение использует абсолютно другое представление.

Мы могли бы прямо в приложении конвертить DateTime в iso 8601 но тогда мы делаем наше приложение привязанным к одному конкретному представлению, которое хочет получить клиент. К примеру по каким-нибудь причинам известным только темным богам, вам вдруг понадобится быстро прикрутить интеграцию с другим сервисом и те же данные гонять уже в RFC2822. И стало быть уже приложению нужно париться о еще одном представлении.

Мы могли бы сделать какие-то адаптеры у приложения, и дергать их в зависимости от потребностей, но тогда опять же наше приложение все еще знает о представлении, которое ему собственно не нужно. То есть у нас есть зависимость приложения от его UI что... похоже на "не лучшую идею". И тут на помощь приходит Inversion of Control.

Что такое Inversion of Control

Тут название само говорит за себя. Допустим у нас был объект A который дергал объект B, причем объект A по сути и не должен ничего знать об объекте B потому то это не его дело. Принцип инверсии контроля говорит нам о том, что в таких ситуациях именно B должно вызывать A, таким образом меняя направление потока управления. Это позволяет нам уменьшить связанность и повысить зацепление компонентов нашей системы. Так же сделав это у нас может появиться объект C который так же будет дергать объект A. Если говорить о UI - мы просто можем сделать несколько реализаций UI.

То есть если еще упростить - фреймворк должен дергать ваш код, а не код дергать код фреймворка. Тем самым мы снижаем связанность одного от другого.

Роутер и контроллеры как реализация UI

Что бы отвязать приложение от логики формирования представления, вынесем это все в отдельный "слой" и назовем этот слой - контроллеры. Точнее это будет как цепочка адаптеров. Один адаптер (фронт-контроллер по сути) получает Request и делает какие-нибудь вещи с ним. Например проверяет можем ли мы вообще делать подобный запрос. Другой адаптер вызывает роутер и выясняет какой дальше адаптер вызвать. Если следующий адаптер не вызван - надо вернуть 404-ую ошибку. Если же все пошло хорошо - мы вызываем еще один адаптер, который уже будет конвертировать HTTP запрос в какое-то действие приложения (вызов метода приложения по сути).

Так а инверсия зависимости это что?

Инверсия зависимости - очень похожа на инверсию контроля но действует чуть по другому. Проще всего будет вглянуть на картинку:



стрелочка зависимости на первой фигуре выходит за пределы нашего "модуля" и залазит в "чужой", тем самым наш модуль становится зависимым от другого модуля. Яркий пример - у нас есть например SwiftMailer для отправки почты. Нашему коду нужен просто способ отправлять сообщения, а SwiftMailer просто конкретная реализация.

Если мы не хотим завязываться на SwiftMailer, и дать возможность в будущем изменить способ отправки почты, мы можем в рамках нашего модуля объявить интерфейс а в другом модуле уже его реализовать с применением SwiftMailer. Для упрощение под модулями мы можем понимать неймспейсы например.

Нужно ли соблюдать принцип инверсии зависимости в случае контроллеров?

Нет. Контроллеру нужна конкретная реализация какой-то части нашего приложения (ибо приложение главнее UI-ки), иначе в них нет особо смысла. И наше приложение вообще не должно париться о том что есть какие-то там контроллеры.

будет ли правильным передавать зависимости в роутинге

Это уже вопрос реализации IoC. Конкретно вы хотите получить что-то вроде Dependency Injection. Вы можете забрать зависимости из аргументов метода экшена. или аргументов конструктора контроллера.... или просто использовать контейнер зависимостей внутри контроллера.... это совершенно не важно. Контроллеры это то место где высокая связанность на компоненты фреймворка более чем допустимы.

С другой стороны у вас теперь роутинг совмещает обязанность маршрутизации и разруливания зависимостей. Сами понимаете что это как-то нарушает прицип единой ответственности. Этим может заниматься Controller Resolver какой-нибудь.

давайте так, есть два вида задач:

- CPU bound - различные алгоритмы, математика, кодирование/декодирование/шифрование... словом все что нагружает процессор.
- I/O bound - собственно когда у нас идет множество операций с вводом/выводом, где-то 90% задач связанных с WEB и серверной разработкой.

Для CPU bound стоит использовать языки вроде Си, Rust, Dlang, Go и т.д. Словом языки которые компилируются в эффективный машинный код.

Для I/O bound - Go, NodeJS, Erlang, Java.... да в принципе не важно какой язык, главное что бы использовались неблокируемые вызовы и отсутствовали блокировки.

Еще есть очереди задач, горизонтальное масштабирование и т.д. Архитектура и алгоритмы используемые в системе влияет часто намного сильнее нежели языки программирования.

Какие языки лучше использовать для этого? Какие не использовать?

Никаких ограничений, только здравый смысл. То есть врядли мы будем писать сложную математику на node.js, но задач связанных с этим намного меньше. Так же никто не говорит о том что систему нужно писать строго на одном языке. Нынче модно использовать микросервисы, каждый из которых может быть реализован на своем языке и со своей базой данных, идеально подходящих для конкретной задачи.

Еще не стоит забывать о алгоритмах. Они тоже должны быть оптимальны. Например взять простую задачу - кластеризация меток на карте. Представьте что у вас в базе миллион объектов, которые мы должны выводить на карте. Поскольку делать подобное на клиенте будет проблематично - мы должны делать это на сервере и возвращать на клиент ровно столько данных сколько ему нужно.

И на таких объемах даже если бы мы взял Си, если наш алгоритм имеет сложность O(N^2) то как бы ничего тут особо не поделать. И так и так медленно будет. А вот если мы возьмем какие-либо алгоритмы имеющие сложность O(NLogN) то уже возможно что алгоритм этот можно хоть на php/python/ruby имплементить. Так например у меня этот алгоритм реализован на Java и не самым эффективным образом. Справляется.

Еще влияет скорость разработки (всякие ruby/python/node в этом плане хороши), стоимость поддержки (Си поддерживать сильно дороже чем Go например, хотя всегда можно написать все настолько плохо что проще выкинуть чем поддерживать), стоимость разработчиков.... Скажем найти дешевых сильных разработчиков на Go или Rust будет весьма проблематично.

Так же не стоит забывать что сервера нынче стоят не так дорого. Иногда бизнесу проще доплатить за еще десяток серверов нежели писать все на плюсах.

Собственно главное правило высоконагруженных систем - нагрузочное тестирование а потом уже оптимизации

Конкретные примеры кода тестов приведены в примерах приложений раз и два.

Так же есть неплохое видео об этом (смотреть на 2х скорости).