dtony: требуют так как в рунете сейчас распространен подход "classic web app", когда бекенд занимается генерацией html кода. Со временем, в любом случае, смещение произойдет в сторону разделения бекенда и фронтенда. Сегодня иногда встречается, что ищут бекендера для RESTful api, ничего из фронтенда не требуют, но пока что редко конечно. Наверное для бекендера лучше вложиться в чтение rfc2616 (http), rfc6749 (oauth 2.0), rfc6455 (websocket), поизучать что-то в области асинхронного программирования и посмотреть фреймворки для реализации stateless серверов и фреймворки/компоненты для реализации stateful серверов, на том языке/платформе с которым планируете работать. В недалеком будущем, будете специалистом на вес золота.
А так придется пилить какие-нибудь убогие интернет-магазины с убогим кодом в убогой веб студии, за убогую зарплату.
P/S завидую вам, по поводу английского, я вот могу только читать и то далеко не всё, хотя не многим наверное вас младше, мне 25.
Ерунда. Достаточно просто нормально настроить веб-сервер. В nginx например проксировать запрос к php-fpm если только location ~ \.php$ а статику отдавать напрямую.
Станислав Макаров: ну это понятно, я так же делал, чтобы равномерно распределять файлы по директориям, но это в контексте одного сервера. А хотелось бы видеть пример шардинга по хешу на много серверов. Вот вы сами сказали, что решардинг дорогая операция, а в вашем подходе, делать его придется каждый раз когда добавляется новая нода. Это одна из проблем. Также все сервера разные по своим характеристикам. На одной машине может быть объем жесткого диска в 1ТБ, а на другой 500ГБ. Представьте, что на машине с 500ГБ занятно все дисковое пространство, а на машине с 1ТБ его еще полно, но ваш алгоритм по хешу высчитывает, что вот этот конкретный файл нужно сохранить на машину с 500ГБ, но там уже нет места, что делать?
Есть еще пласт проблем, связанный с вашим подходом. Поэтому я думаю, что его никто не использует.
Станислав Макаров: я честно мало что понял из ваших ответов, но думаю что на практике это не будет нормально работать. Обсуждаем мы систему с большими объемами данных, иначе нет смысла вообще все это изобретать. Я бы посмотрел на систему, где используется описанный вами подход. Я такой реально вообще никогда не видел и даже не представляю, как это сделать, чтобы не было кучи разных проблем. Я реально рабочих подходов в бою видел всего два:
1. Сетевая файловая система https://ru.wikipedia.org/wiki/Network_File_System
2. Много независимых серверов для статики, файлы на них заливаются рандомно (или по некому алгоритму), приложение перестает записывать данные на сервера на которых исчерпывается объем жесткого диска и только читает с них. Каждый сервер висит на своем поддомене. В базе вместе со всей метаинформацией сохраняется и номер сервера, на котором располагается файл. Яркий пример - Вконтакте.
Первый вариант проще, но говорят начинаются проблемы, когда возрастает траффик, так как канал между удаленной файловой системой и серверами на которых работает приложение забивается и отдача статики начинает тормозить.
Второй вариант сложнее в реализации (нужно писать свой код), но пишут что работает хорошо, так как нет узкого места, сервера статики получаются распределенными и никак ни от чего не зависят, в отличии от первого варианта.
Станислав Макаров: ну хорошо, тогда расскажите, как приложению получить доступ к файлу на конкретном шарде. И как делать решардинг, когда в кластер добавляется новая нода. И что будет, если по хешу этот файл нужно сохранить на конкретную ноду, но на этой ноде уже полностью занят жесткий диск?
Есть примеры крупных проектов, где файлы шардятся по нодам используя описанный вами подход?
Расскажите тогда сразу, как шардить на несколько серверов. В бд хранить номер шарда (сервера) и локальный путь к файлу? В приложении выбирать только те шарды, на которых достаточно места для хранения файла?
Сергей Протько: в модель буду писать. В контроллерах будет получение данных от модели и передача их во вью. Некоторая бизнес-логика может уходить в компоненты или еще куда-нибудь, если говорить в контексте Yii.
Прошу внимательнее. В качестве примера я выбрал Yii второй версии. Привел пример. И задал четкий вопрос. Вот он
> Можно ли это назвать юнит-тестированием или это всё же интеграционное тестирование?
И далее спросил. Критичен ли тот факт, что в процессе тестирования одного метода, неявно тестируются и некоторые другие методы системы. Я хотел выяснить нужно ли всегда в юнит-тестах мокать все зависимости или нет. Если нужно, тогда почему разработчики Yii посчитали по другому?
Я задал четкий вопрос, на который вы к сожалению дали ответ из которого ничего не понятно.
matperez: Ну я об этом и пишу, что замокав поиск пользователя, смысла от такого теста не будет, потому что логика метода LoginForm::login() очень проста. И думаю, что здесь нужно чувствовать грань, когда писать юнит-тесты, а когда интеграционные и в целом не разделять их на две разные группы.
Спасибо, я это все знаю. Мне интересно, в каких типах тестов вы тогда предлагаете проверять, что аутентификация действительно работает верно с настоящими данными правильными/неправильными логинами/паролями. В чистом юнит-тесте это проверить нельзя, остается либо интеграционый либо функциональный. Я хочу выяснить немного другое, грань, где лучше писать юнит-тесты, а где интеграционные. Я думаю, что писать на каждый тестируемый метод и юнит тест и интеграционный тест это слишком затратно по времени. И зачастую является бесполезной тратой времени. Ниже пример.
Я могу замокать LoginForm::getUser() и сделать чтобы он сразу отдавал правильные данные. Но я думаю, что от такого юнит-теста пользы нет, потому что, если замокать LoginForm::getUser(), то в методе LoginForm::login() по-сути и нечего проверять, так как логика его работы крайне проста. Я думаю разработчики Yii исходили примерно из таких же соображений. И поэтому написали здесь интеграционный тест. Просто потому, что юнит-тест здесь не имеет смысла.
Я расчитывал получить ответ, примерно следующего содержания, что в некоторых ситуациях лучше написать на тестируемый метод интеграционный тест, а в некоторых юнит тест, предварительно оценив ситуацию. И то, что User::findByUsername() будет тестироваться два раза в разных тестах - это не критично и вполне нормальная практика.
Вы действительно видите какой-либо смысл писать на LoginForm::login() чистый юнит-тест ?
des1roer: фреймворк для создания веб-приложений от майкрософт. Больше ничего о нем сказать не могу, потому что читал туториал и писал свой говнокод на нем в далеком 2003, когда мне было 13 лет. Пол жизни уже прошло с того момента, помню только, что делал гостевую книгу :)
des1roer: Да. Тем же, чем и обычно. Пишут серверную логику, работают с базой данных. Вы просто на бекенде в контроллере не рендерите вьюху, а отдаете данные например в JSON формате.
des1roer: Нет, angular это не сахар над js. Да, это чистый фронтенд фреймворк. Он избавляет от прямой работы с DOM. Все изменения сделанные в модели (model), автоматически отображаются во вью (view) и наоборот. Благодяря этому, вы пишите только логику приложения. Эту логику легко покрыть юнит-тестами.
Если вы писали когда-либо с помощью библиотеки jQuery или на ванильном js, то должны понимать, что в итоге получается каша из DOM и собственно логики. Angular берет работу с DOM на себя, оставляя за вами только написание логики приложения.
Да php фреймворки умеют генерировать готовый html. Но суть то заключается в разделении зон ответственности. Чтобы всё было разложенно по полкам. Чтобы клиентская и серверная части могли разрабатываться независимо друг от друга. Чтобы фронтенд программист не вникал, как и что там работает на сервере, ему достаточно только знать, как запросить с этого сервера данные. И не более того. Ему не нужно знать о php вообще ничего. Тоже самое серверному программисту, совершенно фиолетово, какие там юзер-интерфейсы пишет фронтенд программист, он только знает, что ему нужно реализовать возможность работы с данными (get/post/put/delete) и идти пить пиво.
des1roer: Yii 2 из коробки предлагает возможность по созданию RESTful Api www.yiiframework.com/doc-2.0/guide-rest-quick-star... . Отличие в том, что RESTful сервер предоставляет исключительно данные, он не занимается генерацией html-кода. На AngularJS вы пишите клиент, который эти данные будет потреблять. Тем самым вы четко разделяете зоны ответственности.
Алексей Инклюдер: Так сделано в любом фреймворке, где одна точка входа в приложение index.php. Указывается правило, чтобы всё, что не является реальным файлом обрабатывалось index.php, а приложение уже само разруливает, что нужно вывалить пользователю в ответ на этот роут.