Андрей Сальников: в идеале ангуляр должен использоваться в контексте SPA, то есть о сервере вообще ничего не должен знать. Но смешивать тоже можно, только непонятно зачем.
vasIvas: но все же раскроете свою мысль менее сумбурно, особенно часть про общение через контроллер (и что тут странного, везде так реалиовано, а контроллер и есть медиатор)
vasIvas: какая задумка? О чем вы? К чему пример с яблоками?
Имхо вы слишком много загоняетесь по довольно обычным вещам. MVC/HMVC/etc это еще не архитектура. Архитектура это SOLID, GRASP, слоеная архитектура... А знать имена шаблонов и т.д. это еще не разбираться в архитектурных штуках.
Стоимость грамотной архитектуры - избыточность. В реально жизни обычно идут на уступки и устраняют излишнюю избыточность. Вот и все.
yiicoder: ну у меня реакт используется не по собственной прихоти, а потому что так решил разработчик который изначально был на проекте и потом свалил. В целом там было очень много архитектурных промашек и еще и монга в качестве основной базы (что хуже чем писать демоны на php, хотя бывают исключения).
1) php-pm - вполне себе норм. Единственное что я бы не стал ему доверять на 100% и мастер процесс всеравно бы еще для надежности под контроль супервизора поместил. Я уже давно хочу чуть чуть попдравить его что бы мастер процесс занимался только управлением процессами, а хэндлинг запросов тогда можно было бы спокойно вынести в отдельные воркеры и распаралелить, тогда риски сократились бы а профита было бы еще больше (скажем разбор multipart запросов вынести в отдельные воркеры что бы не лочить обработку запросов). В целом же довольно неплохой способ повысить RPS.
2) То что экстеншен для монги на чистом PHP особо разницы не должно давать - PHP работает быстро, а большая часть времени работы - межпроцессорное взаимодействие через сокеты, все же основное там всеравно написано на Си (сокеты, селекты и т.д.)
Ну PR как бы есть, и он вроде бы местами адекватный, хотя надо тестить. Я просто заводил отдельный процесс воркер и там парсил запросы, тогда можно использовать ворах готовых библиотек для разбора мультипарт запросов и в принципе выплевывать назад нормальный запрос, и скейлить это удобно.
index0h: почему топором то? В PHP корутины скажем можно уже сейчас писать, в node.js только с трансляцией. Это я как пример. В общем и целом и там и там event-loop, и там и там libuv/libev можно юзать (и react это подхватит). У меня есть опыт работы так же и с PHP-PM, и там риски вообще минимальны - чисто управление процессами сделано в виде демона, в воркерах же просто бутстрапится фреймворк и сбрасывается после каждого запроса, то есть нагрузка на сервер в принципе такая же, RPS можно нехило поднять.
John Smith: ну как бы с не свежего дебиана на не свежий дебиан, у меня пакет ПО не такой уж и большой и в принципе одинаковый, а все что нужно по работе в виртуалках.
А так - это чисто психологическое. С тем от чего я ждал прирост производительности оно мне не помогло, а вот насколько быстрее стала работать система я заметил только после того как понадобилось загрузиться с HDD. А SSD был хороший.
John Smith: AMD норм, если не для програмухи а для игрушек и графики. С этим оно работает очень хорошо за вполне себе приемлимую стоимость. Вот компилировать что-то лучше на интелах, или серваки держать. Тут у них конкурентов нет.
Что до SSD - на самом деле я когда пересаживался с HDD на SSD разницы не почувствовал, пока через неделю не пересел обратно на HDD... к хорошему быстро привыкаешь.
p.s. сам со своими сражаюсь... Ввел свод правил:
- скоуп (а соотвественно и ивенты системные. и ватчеры) можно юзать только в link директивы
- логики в link директиве быть не должно, у каждой директивы должен быть контроллер
- контроллер состояния (юзаем uiRouter) должен быть максимально тонким и по сути его вообще не должно быть
Еще надо придумать чтото для того что бы люди дробили UI на директивы и уже можно будет жить.
John Smith: нет, я говорил что разницы между shdd и hdd не особо есть. Особенно когда размер кэша всего 8 гигов, хватает только для системы. Скажем есть возможность сравнить с shdd где кэш расширен до 32 гигов и там ощутимый прирост производительности. Сам же сижу на ssd только.
vasIvas: не совсем, вы вообще не должны переопределять методы со знаком доллара - это системное API.
ngModelController предоставляет вам два массива функций - parsers и formatters. Первый нужен для того что бы привести viewValue в modelValue (например трансформация строки в Date объект), второй - что бы проделать обратную операцию. Вы собственно должны просто добавить свою функцию в этот массив. Читайте документацию к ngModelController. Так между прочим работают все приличные компоненты для работы с формами - предоставляют API трансформаций значений.
если вас мучают какие-то вопросы по поводу директив - посмотрите на полимер, это пример того чем должны быть директивы и к чему нужно стремиться (web components).
Николай: AMD дешевле при сопостовимой мощности. Для автокадов и архикадов норм. Скажем какой-нибудь FX будет сильно мощьнее i3 при той же стоимости. Проблем же с перегревами и прочим я лично за ними не наблюдал.
Что до SSD - ну как бы да, но это только если у вас куча сьемок или чего еще грузится. В целом если проект не большой то в процессе работы архикады будут мало на диск писать/читать.
Вадим: ну в таком случае проверяйте еще и на длину. Поставьте в валидаторе проверку, мол если minlength значение уже зареджектил, не ресетить значение. Опять же всю необходимую информацию вам предоставляет ngModel.
vasIvas: вы пишите только ng-input-lock, так как input предоставляет вам angular, а еще предоставляет ng-model со своим ngModelController, в котором реализована вся логика по биндингу значений между DOM и моделью. То есть в вашей директиве ng-input-lock мы только добавляем валидаторы в ngModel и работаем только через него, не делая ничего с DOM. При невалидном значении мы просим ngModel выставить значение модели. Тогда ваша директива будет работать с любыми кастомными инпутами.
Кирилл Казаков: я к тому что jquery-modern скорее всего это jquery2. Откройте файл и там в первых строчках обычно информация имеется о том что и с чем едят.
ГЛЕБ ГЛЕБОВ: ну как бы так оно обычно и бывает. Есть один большой фильтр, и в нем есть куча маленьких контролов. Каждый контрол обрабатывает свой кусочек фильтра и отвечает только за него. По изменению через контроллер родительской директивы (большой фильтр) сообщается о том что мы поменяли значение, и большая директива может дернуть какой-то метод-колбэк аля onUpdate({filters: aggregatedFilters}); Как-то так. А в контроллере у нас простая функция updateList которая принимает на вход эти самые фильтры и передает в сервис. А что дальше происходит нас уже не особо парит.
А дип-вотч это плохо, это такое вот решение влоб когда надо сделать быстро и без разницы на качество и поддерживаемость. Хорошо подходит для прототипирования.
DarthJS: лучше - что бы убрать зависимость от scope. Если не использовать scope напрямую (по сути это довольно внутренняя штука которую юзать можно только в link директив), то перестаешь гарадить вотчеры и начинаешь делать нормальный MVC.
Что до "редко пользуется" - у вас выборка не репрезентативна. Между прочим это рекомендация есть даже в angular-styleguide
ГЛЕБ ГЛЕБОВ: откуда взялся огромный ватчер? Где? В директивах он не нужен, в контроллере нет скоупа и нечему ватчить, вам надо по изменению любого фильтра дергать метод контроллера. Никаких deep-watch-ей (если у вас в $scope.$watch третий аргумент выставлен в true - что-то явно пошло не так с вашей архитектурой).
