Askar Fuzaylov: вы можете добавить MongoDB к примеру, и там хранить агрегированные выборки, что бы поиск можно было организовать норм. Ну или переходите на PostgreSQL, где есть поддержка массивов и json.
ummahusla: param в этом случае - функция которую возвращает mystery. Собственно вы ее вызываете с каким-то аргументом, получаете число и прибавляете bonus.
Евгений Петров: такие задачки обычно на собесах дают, многие "фронтэндеры" допустим не знает почему и как это работает. Мне тоже нравится давать людям задачки на каррирование, но не такие стремные.
Юрий Ярош: ну когда такие задачи ставятся - то да, но это не покрывает и одного процента задач) Это специфика работы. Если производительность - критична как фича проекта, то что поделать...
Юрий Ярош: воу воу, вы давно с PHP работали? Если брать PHP 5.6 то он достаточно быстр что бы писать на нем что-то сложное. Он не медленне Python и уж явно быстрее Ruby. А на всякие там PyPy/jRuby (которая к слову никогда не будет поспевать за канонической реализацией) есть HHVM да и PHP7 на подходе, который будет уже раза в два быстрее 5.6.
Что до сишных модулей для пыха - да без проблем. Можно на си писать, можно на зефире, можно на Rust. Но как по мне это 0.1% случаев, когда нужно делать что-то в виде расширения. В остальных случаях - архитектурные решения и только. Скажем взять узкое место приложения и переписать его на go - это тоже архитектурное решение.
А если со старта проекта целиться на удиторию в n миллионов в день (прочитайте описание вопроса, там нет такого и близко) и тратить кучу времени на микрооптимизации, нанимать спецов за дофига денег, то шанс про*бать полимеры увеличивается с каждым днем.
Нужно как-то себя ограничивать в стремлении программировать ради программирования, и лучше побыстрее предоставить клиенту MVP. А там уже плясать дальше.
Kokaas: тот который вы знаете или под который можно спокойно найти разработчиков. Я бы сказал любой подойдет, но так как я php-шник то сами понимаете на какой язык я буду намекать. Единственное что скажу - какой бы язык не взяли, не пишите с нуля. Возьмите хотя бы фреймворки или отдельные компоненты.
Kokaas: крупный проект - понятие относительно. Для меня все что больше 10К человекочасов я уже воспринимаю как что-то большое. А есть проекты на сотни тысяч, миллионы человекочасов
Юрий Ярош: почему же? PHP лучше ноды подходит для подобного. Как раз в силу схожести объектной модели с Java/C#.
Что до "не для мелкого бизнеса" - не факт. Скажем если мы пишем на PHP и используем Symfony2, то нам доступны готовые решения для организации проекта с использованием CQRS, нормальных доменных моделей, тестов и т.д.
В целом я согласен, что CQRS не для новичков. Но это довольно универсальная архитектура. Она по сути не подходит только в условиях многопоточных приложений с высокой конкурентностью ну и в случаях когда команда должна быть совмещена с запросом (например аналог array_pop через CQRS сделать не выйдет).
А причины по котором в опенсурсе этого нет те же, по которым там нет ничего толкового для собственного развития в плане DDD и т.д. Уровень разработок обычно ниже.
xmoonlight: ну идея вроде бы и верна... но меня сильно смущает "дерево наследования". По идее можно и без наследования обойтись. Наследование позволяет лишь сократить объем дублирования кода. А в контексте PHP наследование только для этого и нужно, полиморфизма ж полноценного нет.
В целом же, у Боба Мартина хорошая трактовка была в каком-то из выступлений. Мол помимо объектов и обмена сообщениями между ними, у ООП самая большая сила заключается как раз таки в последних двух буквах SOLID.
Юрий Ярош: где именно SOA + CQRS - не скажу. Да я даже не могу подсказать ни одного open-source проекта где CQRS используется полноценно, обычно эти вещи используют в дорогих и больших проектах, которые никто и никогда не будет выкидывать на гитхаб. Есть что-то типа проектов для обучения, например https://github.com/qandidate-labs/broadway но опять же это только пример применения концепции.
phpus: что значит "новые"? Ну да, MVC сформулировали раньше чем многие шаблоны (конец 70-х), но и всем этим "новым" паттернам уже лет 20. Большая часть принципов SOLID была сформулирована еще в конце 80-х. Новые.
То что вы пытаетесь использовать шаблоны проектирования при отсутствии всякого понимания "зачем это нужно" это лично ваша проблема. Есть принципы ООП, есть GRSAP, который пытается с колокольни SOLID объяснить откуда взялись шаблоны проектирования и почему именно так а не иначе... И самое грустное, что вот эти основы в принципе можно поднять с нуля за пару тройку месяцев. Но люди могут годами писать говнокод и не париться.
Kokaas: на бэкэнде это все не столь важно, особенно в контексте "умирающего PHP". Поскольку ваше приложение живет, грубо говоря, в пределах одного запроса, все это MVC сводится к следующему:
- формируем объект агрегирующий данные по запросу (можно вооружиться Symfony/HttpKernel)
- решаем что от нас хотят по этому запросу, то бишь ресолвим контроллер
- контроллер передает просьбу что-то сделать сервисному слою, сконвертировав данные из формата запроса в тот формат, который ест наше приложение
- сервисный слой делает логику и возвращает какой-то результат.
- контроллер собирает то что нам надо для ответа и формирует ответ... ну и отправляет это дело. То есть передает данные во View layer, а там уже что происходит совсем не важно. Мы там можем шаблончики рендерить, или JSON сериализацию делать...
Скажем HMVC в этом контексте просто позволяет из view layer формировать эдакие под-запросы. То есть так же формируется объект с данными по запросу, так же дергается фронт контроллер, ресолвится действие и формируется ответ, который затем выводится на страницу в нужном месте.
Kokaas:
1) не SAO а SOA, Service Oriented Architecture. Грубо говоря соль в том что бы одно большое приложение разделить на кучу маленьких, которые общаются между собой. Скажем в контексте интернет магазина, админка одно приложение, сервер авторизации пользователей - другое, каталог - третье ну и т.д. Эта штука спасает на реально больших проектах.
2) CQRS - основная соль разделение ответственности на запись и чтение. Это позволяет полностью разделить логику работы с данными на модель для записи и для чтения, упростить логику хранения данных и логику работы приложения в целом. Если к этому добавить Event Sourcing то мы бонусом получаем еще и полную историю изменений (скажем правки цен для продуктов) в виде логирования действий пользователя. Это как минимум полезно для админки. Ну и да, CORS это архитектурный шаблон в пределах одного приложения, оно прекрасно сочитается с SOA.
3) MVC это UI паттерн и на бэкэнде популярен он благодаря такой штуке как RoR, которая популяризировала эту концепцию. В итоге миллионы хомячков орут на право на лево про MVC не понимая что это такое и почему это круто. А если есть понимание зачем это нужно и почему именно так а не иначе, становится проще ориентироваться во всех этих MVC/MVVM/MVP/HMVC/etc. Если вы не знаете принципов SOLID или там банально принципов ООП, то загоняться по таким вещам как разделение логики представления от логики приложения за счет введения дополнительного слоя вам еще рано осознавать. Хотя на практике применять можно. На бэкэнде это все намного проще в плане организации.
