ruboss
Вашим самым нагруженным сервисом будет бд. 1к rps запросов разделить это задача. Что бы это сделать нужно точно знать что за задачи будут выполнятся.
На LAMP стеке даже не думайте про то, что сервер будет один.
Ваша ошибка в том, что вы ожидаете конкретный ответ здесь, не давая полный список требований.(40 страниц это вполне ок). Очень рекомегдую нанять программиста (синьйора), для составления тз.
romy4
Пробовал. Собственно и в чем проблема?)) Нагруженный сервис как правило бд, а не система бизнес логики. 10к процессов спокойно могут сожрать цпу, но это не сравнимо с нагрузками на io жесткого диска, даже ssd.
oculos
Это дико медленная операция. Не дай вам бог в нагруженной крупной бд в 2 утра обнаружить тысячи 20 секундных запросов с этим. Для рэндома: выбираем список id их рэндомим на пхп и уже по полученному результату делаем полную выборку. Не стоит ушатывать бд потому что это просто.
dimon119
Switch это нетипизированное сравнение. За свою практику много раз сталкивался с неуместным использованием этой конструкции. Ее можно юзать, но очень осторожно.
regretful
Ужасная с точки зрения безопасности и тестирования orm. Магия на магии и магией поганяет. Для крупных проектов это может стать самоубийственной практикой.
Пропаганда статики на статике, это приводит к бесконтрольной связности проекта, с его развитием получается сттуация: для мелких правок необходимо сделать изменения в половине проекта.
Дока... б***ь обработка пользвательского ввод в моделях. Это путь в никуда. Я не спорю для мелких говнопроэктиков покатит, но не для чегото серьезного.
Посмотрите доктрину. Посмотрите symfony, silex.
Денис
Скажу честно, в моей практике do-while потребовался 1 или 2 раза. На счет создания переменных согласен, но фреймворк решает задачи инфраструктуры, а ваш проэкт - задачи вашего бизнеса. И для бизнеса обычно дешевле обходится быстро развиваемый и легко поддерживаемый код, чем сверх производительный, но при этом не саппортабельный.
У меня есть проектик ko-ko-ko/assert цель которого валидация входных аргументов простых типов в каждом методе внутри. он ужасен, dry вы***н во все щели, но эта штука очень производительная. Дык вот я молчу про создание переменной, даже присвоение недопустимо долго! Веду к тому, что это вспомпгательный проект ни как не решающий задачи бизнеса, но у него и нет бизнест тробований, только технические. Так же и фреймворк, он решает другие задачи.
Кодстайл и основные требований к коду - это не то место, где возможна демократия. PSR-5, который обсуждается публично не утвержден и тянется с августа 2013.
Было довольно забавное обсуждение: как трактовать var int? https://github.com/phpDocumentor/fig-standards/iss...
Мнения разделились на 2 лагеря, обсуждалось это дело с февраля по сентябрь. ~9 месяцев, Карл! В итоге PSR-5 не ставит требований по жесткому, или мягкому соответствию типов, указанных в докблоке.
В правилах написания кода не должно быть демократии (глупостей там тоже не должно быть). Для больших команд разработчиков, как показывает практика - чем жестче требования - тем лучше.
65536 Собственно и что?))
Я не являюсь core-dev-ом из Symfony Request. У них свои правила, более мягкие. У меня - более жесткие.
Вот вы просто прочитайте первую строку кода, что привели. Если вам в ней все понятно, прозрачно и очевидно - здорово, рад за вас.
Если же вытираете капельки крови из глаз - тогда пользуйтесь правилами, что я описал выше. Прочитать про них можете ...барабанная дробь... выше))
Например первая строка в случае жестких требований:
do {
// ...
$position = strpos($path, $baseUrl);
} while (($last > $index) && ($position > 0));
Зачем в оригинале идет сравнение и с false и с 0, я так и не вкурил.
65536
while (expr) предполагает выражение с булевым результатом. Если делать с ($row = ...) получаем неявное преобразование типов. Неявное преобразование лучше исключать от слова "совсем".
Arris > _опечатки_ вида (0 = $value).
любой, уважающий себя ide должен подсвечивать это как ошибку. А автор закоммитивший сие - в угол на гречку.
Но, так как == и != и присвоения в условиях запрещены - жесткой необходимости предохраняться от подобных ошибок кодстайлом не вижу.
Иван Тимофеевич
php-fpm - это реализация fast cgi интерфейса для интерпретатора.
mod_php - это модуль для apache, со встроенным интерпретатором.
Вещи это принципиально разные, но интерпретатор как правило используется один и тот же, подтягивается как динамическая библиотека.
Вячеслав Юрьевич я чп-шник, предоставляю услуги (поэтому самый точный ответ на вопрос где - в Украине), работаю с php 8-ой год.
Это не юношеский максимализм)) Это правила, написанные кровью и потом.
Так уж получается, что php - это язык быстрых решений, но что бы писать безопасный, тестируемый, расширяемый и производительный код приходится принимать жесткие меры.
Arris > строгому сравнению добавлю крайне полезный стиль сравнения...
Тут бабка на двое гадала))
1) ($value === 0) читается как: проверяемая переменная $value должна соответствовать 0.
2) (0 === $value) читается как: 0 должен соответствовать проверяемой переменной $value.
Мне больше по душе первый вариант, но явных проблем во втором я тоже не вижу. Посему как требование выставлять его не совсем стоит. Что так, что сяк - это ок.
65536 > а за is_numeric(strpos( предусматривается казнь?
Почему же?))
При получении из Request объекта и базовой валидации через is_numeric - это вполне ок, просто далее идет обязательный каст в float/int, которые уже будут браздить просторы. Правда для int > 0 лучше использовать ctype_digit.
sim3x > если в пхп-иде есть возможность проверить кодстайл автоматом, то лучше поставить пункт с проверкой кодстайла вначале - так быстрее можно будет вернуть код на доработку ватору
Так обычно и делается.
Arris > А чем кошерно заменять while ($row = ... ) ?
$row = ...;
while(!is_null($row)) {
...
$row = ...;
}
> даже если я гарантированно знаю, что сравниваю два integer'а - все равно писать $i === $j ?
Верно. Работая в команде вы можете поручиться только за себя. Другой программист будет решать свою задачу и может накосячить, просто забыв, что у него есть несоответствие типов.
Цена этого запрета на порядки ниже профита, который он дает.
> и совсем отказаться от контролируемого приведения типов?
не путайте мягкое и соленое. Привидение типов - это ок, только оно обязательно должно быть ЯВНЫМ.
> а если операнды заведомо однотипны?
В этом случае тоже пишем ===, или !==. Еще раз, цена этого запрета очень низкая, по сравнению с профитом. Код не пишется один раз и на всегда, он рефакторится и расширяется, зачем прописывать кучу преобразований и проверок, если достаточно делать неявное приведение типов? Так и будет написано. Потом добавится еще тип, и в один прекрасный момент у вас в одном условии могут быть int, float и string. Да, оно как-то будет работать, но опять же - это говнокод.
65536 Вы все верно поняли. Не типизированные проверки запрещены. in_array и тому подобные методы тоже с обязательной проверкой типа. Например strpos($a, $b) может вернуть как 0, так и false, что значит принципиально разные вещи: подстрока начинается с нулевого символа, или подстрока не найдена вовсе соответственно.
jacksparrow Для крупных проектов характерно использование одних и тех же моделей в разных контекстах. Как следствие - ваша модель спокойно за весь процесс выполнения может гулять по всему проекту - это нормально. Но проблема AR в том, что помимо данных по всему проекту гуляет еще и подключение к БД. Как следствие - непосредственно работа с одной, или несколькими таблицами может происходить вообще где угодно. По сути это размазывает работу с БД (не с моделью, как объектом данных) по всему проекту.
Паттерн Repository явно разделяет:
- Entity (иногда называют моделью) - это объект данных, все что он умеет - это содержать в себе данные и бросать исключения, если вы туда каку запихиваете.
- Repository - объект для работы с БД и Entity.
Entity может абсолютно спокойно гулять по всему проекту, это просто обертка над данными, не более того. Но вот работа с БД у вас сконцентрирована в одном месте - Repository.
Как полезная фича - репозиторий может работать по интерфейсу, тогда Entity можно создавать разные под каждый конкретный случай бизнес логики вашего проекта. Это вносит серьезную гибкость.
Для тестирования компонент, работающих с Repository все, что нужно сделать - это замокать Repository и проверять, что в него влетает правильное Entity.
В случае с AR - это на порядки сложнее потому, что нужно проверять не только объект данных, но и работу с БД для каждого случая (можно конечно мокать драйвер БД, но попробовав это сделать вы поймете, что где-то свернули не туда). Для AR тестировать создание и запись модельки в внешней компоненте - тоже весело, вам придется в этой самой компоненте делать кучу вспомогательных методов, а потом их же мокать, что тоже хреновенькая практика.
Если AR модель реально "толстая" (содержит в себе бизнес логику) - будьте готовы к тому, что она рано, или поздно станет "божественным" объектом, умеющим во все. Это плохо потому, что малейшее ее изменение может привести к не предсказуемым последствиям.
В случае Repository проблем будет на порядки меньше потому, что репозиторий работает ТОЛЬКО с БД и Entity, он не содержит в себе бизнес логики, вообще.
----
Я не спорю, AR для маленьких проектов с простенькими CRUD-ами вполне норм, но опять же, с ростом проекта - проблемы будут расти экспоненциально.
Под БД берите MySQL и не парьтесь.
Под ферймворк - смотрите Silex, либо таки лучше Symfony. У первого порог вхождения маленький, второй - на порядки мощнее, но и порог вхождения повыше.
это я понял, собственно разница во времени загрузки как раз потому и происходит, что вы картинку подгружаете в момент наведения, а не до того. css - это один из вариантов решить проблему, учитывая, что вы показали меню - там динамика расчетов картинок никому не нужна.
