На PHP можно писать всё тоже самое, что на питон и руби. Не вводите людей в заблуждение. Демоны на PHP пишут. PHP-PM https://github.com/php-pm/php-pm позволяет любой php-фреймворк поднять как демон с несколькими воркерами. А работает он поверх ReactPHP reactphp.org который является аналогом node.js платформы в мире PHP. Кроме того, PHP 7 производительнее и питона и руби blogerator.ru/page/php-7-kritikujte-dalshe-a-my-bu...
Не пишите, о языке, знания о котором у вас уже давно устарели.
Дмитрий Макаров: Да я уже узнал. В яндексе пишут код, загружают его на тестовый сервер и там уже проверяют как это работает в браузере и прогоняют функциональные тесты. Так сделано из-за того что, нужно много всего настраивать, чтобы поднять проект локально.
Дмитрий Макаров: Я знаком с этим всем. Это подходит только для юнит-тестирования. Я же спрашивал, как локально проверить результат в браузере и писать функциональные тесты. Ни что из выше вами перечисленного, в этом вообще никак не поможет.
Так я думаю, что в этой сервисной архитектуре, можно же сделать какую-то систему сборки. Есть у нас сервис яндекс.фотки, с зависимостью от яндекс.паспорт, мы вытягиваем репозиторий с проектом яндекс.фотки и собираем сервис, в результате чего, нам доставляются необходимые зависимости для этого сервиса.
Тестовые сервера, для разработки это всё не работает. Там что-то вечно будет падать/не работать/ломаться и работа встанет. Пусть тестовые сервера используются для того, для чего они предназначены.
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() чистый юнит-тест ?