Маленькое пояснение: если у дескриптора сокета выставлен флаг O_NONBLOCK, то операционная система не будет ждать появления новых соединений или данных. Сервер будет представлять из себя бесконечный цикл, в котором постоянно будут проверяться состояния дескрипторов (готов к чтению или записи). Это разруливается через механизмы select/epoll. (<a href="http://habrahabr.ru/post/111357/">мультиплексирование</a>). Способ по проще - при новом соединение вынести его обработку в отдельный поток. Вот собственно и вся магия. Все эти средства, как это не удивительно, есть и в php. Но писать демоны на php то еще удовольствие.
0) сборка проекта вынесена в CI сервер (прогон тестов включен), который и занимается всей рутиной.
1) vagrant. Настроить базовое окружение и юзать его всем членам команды. Это не работает только в очень редких кейсах.
2) для этого есть devel и develN сервер, на который все изменения деплоятся автоматически по пушу в репозиторий (дальше по ступенькам уже вручную идет запуск процесса деплоя)
3) вот тут не понятно. Лично у меня нету проблем ни с ключами ни с сертификатами.
rozhik, не могли бы вы пояснить? Как-то же люди живут и без этих извращений с сетевыми дисками и т.д. Добиться того, что у каждого разработчика будет одинаковое окружение достаточно просто. Интегрироваться разработчики тоже могу достаточно часто через GIT. Что еще нужно?
интенсивная откладка/дебаг обычно происходят локально. Если же баг воспроизводится только на сервере, а такое бывает крайне редко, делается отдельная ветка, делается много много коммитов и потом, когда бак пофикшен просто все сквошится в один коммит и переносится в мастер.
опять же тут приведена информация только для функций для работы с массивами. Причем сложность различается для некоторых функций в зависимости от того что вы используете (обычный массив, объект имплементящий ArrayAccess или же SplFixedArray и т.д. Информация почти по всем функциям так или иначе есть, но она сильно разрознена. В самой документации сложность алгоритмов описана только для вещей вроде similar_text и т.д. Именно полный список вы вряд-ли найдете.
Это как раз таки правильно. Перед деплоем вы на своей машине или через CI сервер или еще как ставите все зависимости и одним жирным архивом передаете все на целевой сервер.
Не повиснет. Во первых нода считывает данные не одним куском а по мере поступления пакетов. Причем делает она это сразу для всех соединений паралельно. В плане потребления памяти, да. Если у вас много клиентов сразу пошлют 4 метра JSON данных то будет грустно, но это маловероятный сценарий. Даже 100 килобайт это уже не так часто. Файлы же bodyparse сразу сбрасывает на файловую систему, так что это так же не проблема.
у вас по сути через post отправляется json, так что я вообще не вижу смысла использовать считывание тела запроса по кускам. Да и express сам умеет обрабатывать тело запроса.
app.use(express.bodyParser());
app.post('/', function(request, response){
// вернет то что послал пользователь
response.send(request.body);
});
Если у вас уже используется bodyParser, то естественно что события data/end у вас не сработают, так как они срабатывают ДО того как дело дойдет до вашей функции poster.
Ну раньше (во времена PHP4) инкапсуляция заключалась только в том, что вы могли объединить методы в классы, но все проперти и методы оставались при этом публичными, что нарушает принципы инкапсуляции.
Возможно я вас не правильно понимаю, но трейты никак вам не помогут решить эту проблему. Наоборот, они только добавят проблем. Если вы говорите о том, что вам не нравится дублирование кода при работе с query buiilder, то тогда я с вами не соглашусь. Это дублирование — нормальное явление. Намного хуже когда люди пытаются писать какой-то один базовый метод и его дополнять (скажем метод возвращает querybuilder и потом на него докидываются еще штуки). Пусть уж код дублируется, зато его будет удобно изменять. Вещи, которые реально бесит постоянно копировать, допустим штуки вида removed=true для выборок проще запихнуть в фильтры доктрины.
Единственный реально живой кейс для трейтов — добавление какого-то функционала дополнительного. Например, добавление какого-либо дополнительного функционала. Скажем логирование. Причем с этим спокойно можно справиться применив декораторы. Если честно я пока не могу предложить реального примера, где трейты реально нужны. По сути это просто копи-пэйст кода на уровне среды исполнения. Ну и еще маленький минус, нормально покрывать тестами функционал реализованный с использованием декораторов довольно легко, чего нельзя сказать о трейтах.
К слову да. Так же рекомендую тамошний раздел «практикум». Для начала очень даже неплохо будет. + есть возможность посмотреть чужие реализации этих заданий.
я по началу как-то и не читал книг. Ну как, полистал какую-то php для чайников или что-но на подобии, уже не вспомню… в основном все методом тыка и по документации. Книги были уже значительно позже, когда захотелось приобщиться к штукам типа agile, tdd, побольше узнать о паттернах и т.д.
Ну и так же как минус трейтов — они плохо покрываются тестами. Не зря же в silex отказались от трейтов и заменили их на serviceprovider (хотя вроде как поддержка трейтов была оставлена)
мое личное мнение — ar это плохо. да, это легко реализуемо, но есть свои минусы: какого черта мои модели могут знать что-либо о том, как они хранятся в базе? Использование ar автоматически завязывает всю логику работы приложения на ваши модели, а именно на интерфейс предоставляемый трейтами/базовым классом. Согласитесь, это не слишком интересно. Намного интереснее паттер data mapper, с использованием прокси объектов для ленивой подгрузки связанных данных. Когда у вас есть ваши маленькое модельки и менеджеры записей/репозитории. В этом случае моделям без разницы где и как они хранятся, а логика приложения не завязана на конкретную реализацию слоя для работы с базой данных, а только на интерфейс ваших репозиториев.
hell0w0rd, можете привести абстрактный пример того, где трейты по вашему будут полезны (в контексте queryBuilder)?
